Source of deadlock between PlayerBase.mLock and
PlaybackActivityMonitor.mPlayerLock:
android.media.MediaPlayer.release()
> android.media.PlayerBase.baseRelease()
> synchronized (mLock)
> com.android.server.audio.PlaybackActivityMonitor.releasePlayer()
> synchronized(mPlayerLock)
and:
com.android.server.audio.PlaybackActivityMonitor.unmutePlayersForCall()
> synchronized (mPlayerLock)
> android.media.PlayerProxy.setVolume()
> android.media.PlayerBase$IPlayerWrapper.setVolume()
> android.media.PlayerBase.baseSetVolume()
> synchronized (mLock)
playerSetVolume()
Since system_server can have its own players, the calls to
AudioService from PlayerBase can be synchronous, hence the
deadlock.
The fix consists in never holding the lock in PlayerBase
while calling into AudioService.
Refactor the playstate update into a method used for
start / stop / pause.
Bug: 72294559
Test: see bug
Change-Id: I6451aa3bf19a0365472ba007b116a9e6151ab33e
Synchronize changes to mIPlayerShell after release of corresponding
player.
Flush binder commands when a player is released, in AudioService
and in the clients that have an AudioPlaybackCallback implementation.
Do the same in MediaSessionService, which directly implements
the IPlaybackConfigDispatcher interface, without going through
the AudioPlaybackCallback registration and notification
mechanisms.
Test: adb shell /system/bin/write_sine_callback -m2 -pl
Bug: 65450109
Change-Id: I2f0697e0e164283284ce30d2cc736c4f8df270c4
Add player types for playback activity monitoring:
- AAudio
- hardware sources
- proxy for external players
Fix some declarations that do not follow coding guidelines
Test: n/a
Bug: 62027849
Change-Id: I14088a071a296fa8d342b36b550f1dc4e3388653
Add API for VideoView to select whether it uses audio focus during
playback, and how.
Add support for AudioAttributes
Test: cts-tradefed run cts -m CtsWidgetTestCases -t android.widget.cts.VideoViewTest
Bug 30955183
Bug 30258418
Change-Id: I581d32c79c78b8197ded2319e0d5bfdc35b93c5e
PlayerProxy is a wrapper on IPlayer for system components
to control players.
Test: use vendor/google_toolbox/team/audio/cmds/ClPlaybackActivity
Bug 30258418
Change-Id: I6a40290c7f711fc0242597a5c016fc71cb4baa10
An AudioPlaybackConfiguration contains an IPlayer
interface for system control of a player. It is not
exposed to non-system signature components.
AudioService, through PlaybackActivityMonitor, is monitoring
the death of the IPlayer so the matching player can get
unregistered in case it meets its maker.
Test: use vendor/google_toolbox/team/audio/cmds/ClPlaybackActivity
Bug: 30258418
Change-Id: Ibf3bceba91882ff16bffbf1219c55a1f89ccb13f
Make beginning of player tracking synchronous, init uid/pid/piid
on the server side, and return the piid.
Anonymize configurations in the getter of active configurations
when the client isn't privileged.
Test: run cts -m CtsMediaTestCases -t android.media.cts.AudioPlaybackConfigurationTest
Bug: 30955183
Change-Id: I1610ae0067fd26d297057663352e679c8963a2d7
Define new player types to describe the two types of AudioPlayer
in OpenSL ES: those with a buffer queue source, those that
play from a given URI or FD.
Add a warning in the interface description of AudioService
that changes should be reflected in the native interface too.
Test: make, NDK tests to follow
Bug: 30955183
Change-Id: I7b530ea6e3b13f238f662ce8b9612e7df574a9c5
AudioService keeps track of status of implementations of PlayerBase.
AudioService's PlaybackActivityMonitor maintains a list of
playback configurations for each PlayerBase, and a list
of clients that want to receive updates about the playback.
Playback activity clients can query the playback configuration
of the system through AudioManager, or register a callback
for updates. For clients with MODIFY_AUDIO_ROUTING permission
(system), the playback configurations contain more information
about each player (player type, uid, pid, state), and can see
all players, not just the "active" ones. The act of stripping
off data about the players that is not supposed to be seen
by non-system clients, is referred to as "anonymization". It
is implemented in system server, so no system data is ever
sent to playback activity clients without system permission.
More information about the AudioPlaybackConfiguration is
available in the SystemApi (uid, pid, player type, player state).
Test: run cts -m CtsMediaTestCases -t android.media.cts.AudioPlaybackConfigurationTest
Bug: 30955183
Change-Id: I85997594c0378216419f5f0fdaa0714996fd3573
