of removing/adding the view.
Adding/removing the car status bar via window manager causes issues if
trying to do too quickly since the calls are asynchronous. So if the
status bar is under the process of being removed when we want to show
the status bar, it will throw a BadTokenException because not all of the
references have been cleaned up.
Bug: 142272085
Test: manual
Change-Id: Ia0f46ba4f7582aaadd24dd885788609f027fa156
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
Add CODE_RETRY_ON_IMS_WITHOUT_RTT for the IMS stack to indicate to
Telephony that a call should be retried without RTT enabled.
Bug: 141963475
Test: manual
Change-Id: Ic3aa8856e98d8c34fd98462d71834e69b857eda4
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
There will be a helper in the BluetoothCodecStatus to check whether the
codec config is matched the selectable array. It uses 3 smaller helpers
to confirm the codec config has none (wildcard matching), or one and only
one value for the audio feeding parameters.
Besides, this CL also adds a helper to compare whether two codec configs
are similar or not, and uses NONE values as wildcard.
Bug: 131147224
Bug: 133719424
Test: atest -t BluetoothInstrumentationTests:com.android.bluetooth.a2dp
Change-Id: I7d8f1a16b8358c440841801d95471b2d010739ec
Merged-In: I7d8f1a16b8358c440841801d95471b2d010739ec
(cherry picked from commit f1936c3423)
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
