Add unit tests to verify that bug has been fixed.
Re-enable testGetConnectionOwnerUid() unit tests in presubmit. These
were disabled due to test flakiness caused by expected failures passing
as a result of other sockets on the system. This is fixed by checking
that failures do not have the UID of the calling process instead of
INVALID_UID since previously some Qualcomm telephony sockets were
causing lookup successes.
Test: atest InetDiagSocketTest#testGetConnectionOwnerUid
Test: ls -1 /proc/<pid of system_server>/fd | wca
Test: atest --generate-new-metrics 200 InetDiagSocketTest#testGetConnectionOwnerUid
To verify flakes have been cleaned up.
Bug: 141603906
Bug: 141459241
Change-Id: Ib76674f10e4bd24952c557bac7b9c65fba42fdb2
Merged-In: Ib76674f10e4bd24952c557bac7b9c65fba42fdb2
(cherry picked from commit 59940afb16)
Clean cherry pick.
Our restriction if it has finished was too strict before,
let's loosen it to call whenever the animation has actually
finished not when it reached the final value
Fixes: 142189043
Test: atest SystemUITests
Change-Id: Ic8a252316346782b485b25d0f5d5458b30511f09
Bug: 140715166
Test: I56dc6e9865c2701746c95ea584bcc70fe4d62a6c
AnimatedImageDrawable, when created from a ByteBuffer, needs to get a
pointer to the JNI interface in order to read the ByteBuffer (or
byte[]). But the AnimatedImageThread is not attached to the JVM. Attach
it as necessary.
Change-Id: I51b69b5b70f8c5865d5e5ed065e42267fa556202
Merged-In: I51b69b5b70f8c5865d5e5ed065e42267fa556202
(cherry picked from commit a7ec12f7ef)
TelephonyScanManager may sometimes encounter a race condition where
Telephony sends it the first scan result before it has saved the
returned scan ID. This causes a crash in the app that's requesting the
scan.
To fix this, synchronize on mScanInfo while requesting the network scan
so that the handler in TelephonyScanManager will wait for the scan ID to
be saved before processing the first message from Telephony.
Bug: 142068098
Test: manual
Change-Id: I0b2b4c6dc749e21641843818293941704ed870a6
Also listen for changes to user setup rather than device provisioned
Bug: 140748928
Test: manual with custom SUW apk
Change-Id: Iabab489269d3dbfafd150a919020ac7921e45768
am: 67e7268757 -s ours
am skip reason: change_id I0680034ed9315aa2c05282524d48faaed066ebd0 with SHA1 5136eefeb3 is in history
Change-Id: If638f3a41362dbbc07b101df3ddd9d51c2dfb103
am: 9ec959b8f3 -s ours
am skip reason: change_id I0680034ed9315aa2c05282524d48faaed066ebd0 with SHA1 09843a687b is in history
Change-Id: I8cb6a74fb003c359cf81f5dbf84d77f675dd5b5c
am: d3618f8275 -s ours
am skip reason: change_id I0680034ed9315aa2c05282524d48faaed066ebd0 with SHA1 5136eefeb3 is in history
Change-Id: I84e294f2e9e192cfaf1c62cab4b05a1e8b5df7db
am: 3b8c4743f6 -s ours
am skip reason: change_id I0680034ed9315aa2c05282524d48faaed066ebd0 with SHA1 5136eefeb3 is in history
Change-Id: I5ad32c66fa4502e232b802241789977252ddec8e
Auto allows for setup deferral, so keycode presses for HOME should
propagate to the application layer when user setup is in progress.
Bug: 140787161
Test: KEYCODE_HOME should trigger an intent with Intent.CATEGORY_HOME
Change-Id: I05751f93c44405b28f93789e6f8e6cf0a3f34524
Merged-In: I05751f93c44405b28f93789e6f8e6cf0a3f34524
Signed-off-by: Julius D'souza <jdsouza@google.com>
It's possible for a service to do a start/stop foreground and cause a
couple of things to happen:
NotificationManagerService will enqueue a EnqueueNotificationRunnable,
post a PostNotificationRunnable (for the startForeground), and then also
enqueue a CancelNotificationRunnable. There is some racy behavior here
in that the cancel runnable can get triggered in between enqueue and
post runnables. If the cancel happens first, then
NotificationListenerServices will never get the message.
This behavior is technically allowed, however for foreground services we
want to ensure that there is a minmum amount of time that notification
listeners are aware of the foreground service so that (for instance) the
FGS notification can be shown.
This CL does two things to mitigate this problem:
1. Introduce checking in the CancelNotificationRunnable such that it
will not cancel until after PostNotificationRunnable has finished
executing.
2. Introduce a NotificationLifetimeExtender method that will allow a
lifetime extender to manage the lifetime of a notification that has been
enqueued but not inflated yet.
Bug: 119041698
Test: atest NotificationManagerServiceTest
Test: atest ForegroundServiceNotificationListenerTest
Change-Id: I0680034ed9315aa2c05282524d48faaed066ebd0
Merged-In: I0680034ed9315aa2c05282524d48faaed066ebd0
