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
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
- Actually include check for fling
- Base left or right side on starting position instead of current position
Test: Long quick swipe PIP from opposite edge of screen -> no longer minimizes
Bug:35358628
Change-Id: I7cd62b94943afe28b89a8bcb0e0cab58bc0841a9
dumpStackTraces originally checked this. This only happens when a silent
ANR is triggerred on a process name not in NATIVE_STACKS_OF_INTEREST.
Bug: 36414311
Bug: 36652737
Test: manual
Change-Id: I24402fb2ef2e08482f866dc1086ce83c1365d7ec
