A media session lives alongside the player that it manages. You should create
and initialize a media session in the
onCreate() method of the activity or
service that owns the media session and its associated player.
Initialize the media session
A newly-created media session has no capabilities. You must initialize the session by performing these steps:
- Set flags so that the media session can receive callbacks from media controllers and media buttons.
- Create and initialize an instance of
PlaybackStateCompatand assign it to the session. The playback state changes throughout the session, so we recommend caching the
- Create an instance of
MediaSessionCompat.Callbackand assign it to the session (more on callbacks below).
In order for media buttons to work
when your app is newly initialized (or stopped), its
contain a play action matching the intent that the media button sends. This is
ACTION_PLAY is assigned to the session state during
initialization. For more information, see Responding to Media
Maintain the playback state and metadata
There are two classes that represent the state of a media session.
class describes the current operational state of the player. This includes:
- The transport state (whether the player is playing/paused/buffering, etc.)
- The player position
- The valid controller actions that can be handled in the present state
class describes the material that is playing:
- The name of the artist, album, and track
- The track duration
- Album artwork for display on the lock screen. The image is a bitmap with a maximum size of 320x320dp (if larger, it's scaled down).
- An instance of
ContentUristhat points to a larger version of the artwork
The player state and metadata can change over the life of a media session. Every time the state or metadata changes, you must use the corresponding builder for each class,
MediaMetadataCompat.Builder(), and then pass the new instance to the media session by calling
To reduce overall memory consumption from these frequent operations, it's a good idea to create the builders once and to reuse them throughout the life of the session.
Interested in playback states? See the
Media session lock screens
Starting with Android 4.0 (API level 14) the system can access a media session's playback state and metadata. This is how the lock screen can display media controls and artwork. The behavior varies depending on the Android version.
In Android 4.0 (API level 14) and greater, the background of the lock screen displays your album artwork - but only if the media session metadata includes a background bitmap.
In Android 4.0 (API level 14) through Android 4.4 (API level 19), when a media session is active and the media session metadata includes a background bitmap the lock screen automatically displays transport controls.
In Android 5.0 (API level 21) or greater the system does not provide transport controls on the lock screen. Instead, you should use a MediaStyle notification to display transport controls.
Media session callbacks
The main media session callback methods are
This is where you add the code that controls your player.
Since you instantiate and set the session's callback at runtime (in
onCreate()), your app can define alternative callbacks that use different players and choose the appropriate callback/player combination depending on the device and/or system level. You can change the player without changing the rest of the app. For example, you could use ExoPlayer when running on Android 4.1 (API level 16) or greater and use
MediaPlayer on earlier systems.
Besides controlling the player and managing the media session state transitions, callbacks also enable and disable features of your app and control the way it interacts with other apps and the device hardware. (See Handling Changes in Audio Output).
The implementation of the media session callback methods depends on the structure of your app. See the separate pages that describe how to use callbacks in audio apps and video apps, describe how the callbacks should be implemented for each kind of app.