The preferred architecture for an audio app is a client/server design. The player and its media session are implemented inside a
MediaBrowserService, and the UI and media controller live inside an Android activity along with a
MediaBrowserService provides two main features:
- When you use a
MediaBrowserService, other components and applications with a
MediaBrowsercan discover your service, create their own media controller, connect to your media session, and control the player. This is how Wear OS and Android Auto Applications gain access to your media application.
- It is also provides an optional browsing API. Applications don't have to use this feature. The browsing API lets clients query the service and build out a representation of its content hierarchy, which might represent playlists, a media library, or some other kind of collection.
Note: As is the case with media session and
media controller, the recommended implementation of media browser services and
media browsers are the classes
which are defined in the
media-compat support library.
They replace earlier versions of the
MediaBrowser that were introduced in API 21. For
brevity, the terms "MediaBrowserService" and "MediaBrowser" refer to instances
- Building a Media Browser Service
- How to create a media browser service that contains a media session, manage client connections, and become a foreground service while playing audio.
- Building a Media Browser Client
- How to create a media browser client activity that contains a UI and media controller, and connect and communicate with a media browser service.
- Media Session Callbacks
- Describes how the media session callback methods manage the media session, media browser service, and other app components like notifications and broadcast receivers.
- This GitHub sample shows how to implement a media app that allows background playback of audio, and provides a media library that is exposed to other apps.