| 92dea33bfebed04533264b06e036d04cc16b9608 |
|
02-Feb-2017 |
Jaewan Kim <jaewan@google.com> |
Simplify the media button handling logic
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
/frameworks/base/services/core/java/com/android/server/media/AudioPlaybackMonitor.java
|