Working with a Media Session
A media session coexists with the player it manages. You should create and initialize the media session in the activity or service's onCreate() method, and hold the media session and its associated player object.
Note: The best practice for writing media applications is to use the media-compat library. In this article, "media session" refers to an instance of MediaSessionCompat, and "media controller" refers to an instance of MediaControllerCompat.
Initialize the media session
A newly created media session has no compatibility. You must initialize the media session by following these steps:
Set the flag so that the media session can receive callback functions from media controllers and media buttons.
Create and initialize a PlaybackStateCompat instance and add it to the session. The playback state accompanies the media session throughout, so we recommend caching the PlaybackStateCompat.Builder for reuse.
Create an instance of MediaSessionCompat.Callback and add it to the session.
You should create and initialize the media session in the activity or service's onCreate method, and hold the session object.
In order for a media button to work properly when your app is initialized (or stopped), its PlaybackState must contain playback events to match the intent sent by the media button. That's why the identity of ACTION_PLAY is assigned to the state of the session during initialization. For more information, see Responding to Media Buttons.
Maintain the playback state and metadata
There are two classes here that represent the state of the media session
The PlaybackStateCompat class describes the state of the current player operation. It contains:
Transport status (whether the player is playing/pausing/cache, etc.)
the player's position
Controller events for which the current state can be handled
The MediaMetadataCompat class describes the data source that the player is playing:
The name of the artist, album and track
track duration
The album art displayed when the screen is locked. The cover image is a bitmap with a maximum size of 320X320dp (if the image is larger, it will be compressed)
An instance of ContentUris points to a later version of the album.
The state and metadata of the player can change the life cycle of a media session. Each time state or metadata changes, you must create a new instance using the appropriate builder PlaybackStateCompat.Builder() or MediaMetadataCompat.Builder() and pass the instance to the media session via setPlaybackState() or setMetaData(). To reduce the overall memory consumed by these frequent operations, it is a good idea to reuse builders throughout the lifetime of the media session once they are created.
If you are interested in playback state, see PlaybackStateCompat.
Media session lock screens
Starting with Android 4.0 (API level 14), the system has access to the playback state and metadata of the media session. That's why the media controls and cover are displayed when the screen is locked. However, this display also depends on the Android version.
Album artwork
On Android 4.0 (API 14) or higher, album art is displayed in the background after the lock screen - it is only possible to include a background bitmap in the metadata of the media session.
Transport controls
Between Android 4.0 (API 14) and Android 4.4 (API 19), this teleporter was automatically displayed when the screen was locked when a media session was active and its metadata contained a background bitmap.
On Android 5.0 (API 21) or higher, the system does not support transferring control when the screen is locked. Instead, you should use a MediaStyle notification to display the teleporter.
Media session callbacks
The main media session callback methods are onPlay(), onPause() and onStop(). Add these codes to control your player.
During runtime (in onCreate()) once the media session's callbacks are initialized and set, your app can define different callback methods to use different players and choose the appropriate callback/player based on the device or system level combine. You can change the player without changing the rest of the app. For example, you can use ExoPlayer on systems running Android 4.1 or higher, and MediaPlayer on Android systems prior to 4.1.
In addition to controlling the player and managing the state of the media session, callback methods can also enable and disable the application's functionality, as well as control how it interacts with other applications and device hardware (see Handler Changes in Audio Output).
The implementation of the media session callback methods depends on the application's architecture. See the separate documentation describing how to use callbacks in audio and video applications and how each type of application should implement callbacks.