Not needed anymore, since the bug was found to be in the binder driver.
This reverts commit 9afb1fc495aa132c4a5e3a5beca408597ab1bb09.
Change-Id: I3891866f6e30a3f3391df8005e56bf9b9777b3a6
(cherry picked from commit ab5523f3372b9e36911aa25a8247f0a2fa16543a)
Make sure that KeyButtonDrawable centers its child layers in case
they aren't the same size (like menu).
Test: visual
Change-Id: I10cbbac2f74288c3ca570d48ac23a1101dbab4e0
Fixes: 34102319
(cherry picked from commit 5b3b485593934f852b6e4193b9f1e0f492b674b6)
handleCancel() can be called before we start backing up any particular
package, therefore we need to properly handle log messages in that case.
Bug: 36638539
Test: manual
Change-Id: Ic96e2fbad5c0a79640a3419d187e8b5e4d265de3
(cherry picked from commit 519a87db8fabb49f299aa384aeb5cfe4dfedf907)
Test: cts-tradefed run cts-dev -m CtsViewTestCases -t android.view.textclassifier.cts.TextClassificationManagerTest
Tests have been written on the native side.
Bug: 35416389
Change-Id: If2de73391e1a343e0dc7698039ad1464cedfbf08
Right now it is always used with cacheLock. In the future, we will be
adding optimizations to reduce cacheLock contention by only holding it
when updating the cache.
This change is non-functional and doesn't change the current locking
contract
Test: Manual + AccountManagerServiceTest
Bug: 36485175
Change-Id: Iebc437463958d33b32fc1273a84680c22ac60825
These intents should only be broadcast by the System Service, so
register them as protected broadcast.
Bug: 36655814
Test: Build with go/aog/355397, verify in logcat that no non-protected
broadcast error gets thrown when
android.net.wifi.action.PASSPOINT_OSU_PROVIDERS_LIST intent
is broadcasted
Change-Id: I57849d0decef407624cac380a0f12f5428e0f1de
Adding new permission for changing accessibility volume
to allow system UI to change it. Also providing audio
manager with a whitelist of bound accessibility service
uids so it can allow servics to change the volume.
Bug: 36569297
Test: Adding CTS test in linked CL.
Change-Id: I4f327e3a251fc3780c5957f41217c2ef5bb8b16e
Here's the new media handling logic.
1. If the foreground app consumes the media key event
(Activity.onKeyDown/Up() or Activity.setMediaController()),
we stop here.
2. Find the media app whose AudioPlaybackConfiguration becomes
PLAYER_STATE_STARTED lastly across the boot. The media app is the app
with the media session.
- If its session is still alive, send the media key event
to the media session.
- If its session has been released but the session set the media
button receiver, send the media key event through the media button
receiver.
- If it has multiple media sessions, pick the media session whose
PlaybackState matches with the AudioPlaybackConfiguration's player
state.
3. Stop here. Don't try revive any other app.
This approach has two limitations.
1. If an app has multiple AudioPlaybackConfigurations and/or
media sessions, the MediaSessionService may pick the wrong media
session to send media key events.
2. If an app with a media session plays sound effects differently from
the SoundPool class, the MediaSessionService would consider the app
as the lastly played media app.
Bug: 33032080
Test: Manual tests as follows
1. Checked that the lastly played app receives the media key events
although the app's media session doesn't report its playback state.
2. Checked that the lastly played app receives the media key events
although the app's media session is released.
3. Checked that the lastly played app doesn't receive the media key
events if its playback is remote.
Change-Id: I1fd6f9eee0750da4dea9fcc7401fdb1c3f249a72
