open class MediaController : Closeable
Allows an app to interact with an active or a
MediaSessionService which would provide . Media buttons and other commands can be sent to the session.
MediaController objects are thread-safe.
Topics covered here:
When a controller is created with the
SessionToken for a
MediaSessionService (i.e. session token type is
SessionToken#TYPE_LIBRARY_SERVICE), the controller binds to the service for connecting to a
MediaSession in it.
MediaSessionService will provide a session to connect.
When a controller connects to a session,
MediaSession.SessionCallback#onConnect(MediaSession, MediaSession.ControllerInfo) will be called to either accept or reject the connection. Wait
ControllerCallback#onConnected(MediaController, SessionCommandGroup) or
ControllerCallback#onDisconnected(MediaController) for the result.
When the connected session is closed, the controller will receive
When you're done, use #close() to clean up resources. This also helps session service to be destroyed when there's no controller associated with it.
Controlling the MediaSession in the same processWhen you control the
SessionPlayer, it's recommended to use them directly rather than creating
MediaController. However, if you need to use
MediaControllerin the same process, be careful not to block session callback executor's thread. Here's an example code that would never return due to the thread issue.
<code>// Code runs on the main thread. MediaSession session = new MediaSession.Builder(context, player) .setSessionCallback(sessionCallback, Context.getMainExecutor(context)).build(); MediaController controller = new MediaController.Builder(context) .setSessionToken(session.getToken()) .setControllerCallback(Context.getMainExecutor(context), controllerCallback) .build(); // This will hang and never return. controller.play().get();</code>When a session gets a command from a controller, the session's
MediaSession.SessionCallback#onCommandRequestwould be executed on the session's callback executor to decide whether to ignore or handle the incoming command. To do so, the session's callback executor shouldn't be blocked to handle the incoming calls. However, if you call ListenableFuture#get on the thread for the session callback executor, then your call wouldn't be executed and never return.
To avoid such issue, don't block the session callback executor's thread. Creating a dedicated thread for the session callback executor would be helpful. See Executors#newSingleThreadExecutor for creating a new thread.
Interface for listening to change in activeness of the
Holds information about the way volume is handled for this session.
Requests that the connected
Releases this object, and disconnects from the session.
Gets the cached allowed commands from
Gets the duration of the current media item, or
Get the current playback info for this session.