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)
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
We base the cache quotas on usage stats on the device. These stats,
however, can contain entries from apps which are no longer installed.
In this case, we skip its calculation and log a warning. This patch
removes the warning aspect of it, because it is a legitimate case.
Change-Id: I2a6a797966bfee007515735308535a5dcc118f03
Fixes: 36649802
Test: Manual
Probably won't fix anything but this assert is in queue()
but not queueAtFront() and inserting a task twice is Really Bad.
Bug: 36139852
Test: ¯\_(ツ)_/¯
Change-Id: Ida0f829eecfdd46c17c36b816528c49d12b7cf29
