DevBytes: Media Router Framework – Part 1 – Media Router API

DevBytes: Media Router Framework – Part 1 – Media Router API

[MUSIC PLAYING] Hello, my name is Fred Chung,
developer advocate at Google. This is the first of a two-part
DevByte series covering the Android media router
framework in the support library. It has become increasingly
common for users to stream movies or play
music from their tablets or smart phones. In the living
room, for instance, you may want to make use
of those external speakers or Wi-Fi displays to enjoy
your personal library of media content. Android offers a flexible media
router framework for any apps to cast media content to
support its external devices for playback. In this episode, we are
going to talk about the media router, which is a
mediation layer for apps to cast media content
to supported devices. The paths to these devices
are known as media routes. At a high level,
the media router offers APIs to render
the cast buttons, discover and select media
routes, [? preread ?] the capabilities of
the routes, and control remote playback via an
intent-based protocol. In the next episode,
we are going to explore media
route providers, which is a component that
encapsulates the underlying communication between Android
and external media devices. Device manufacturers can
implement their own MRPs in order to publish themselves
as media routes on Android. For example, Chromecast
has implemented an MRP in the Google
Cast SDK through which apps can integrate with. With this architecture,
apps are essentially decoupled from underlying
transport implementations of the media routes. We’re going to look at some
implementation details. But before doing that,
I wanted to call out that the media router
framework we are focusing here is in the support library,
which means that it is backward compatible with
Android 2.1 and above. And let’s not mix it up with
the media router in the Android framework. To initiate media
routing, the user would click on the Cast
button, which typically is placed on the action bar. Through the button,
the user would be able to select a media route,
disconnect from the route, control playback on a
connected route, and so on. One way to add the Cast
button in the action bar is to add an action provider
manual item pointing to the class media
route action provider. Then, in the menu
initialization code, associate menu item
action provider with a media route
selector object. Route selector is
basically a filter for media route capabilities. An app can specify categories
of media routes and points it can work with. The framework uses the
selector to present only the appropriate
media routes to the user. For example, if an app asks
for video streaming capability, the system won’t present
audio-only media routes to the user. There are several
predefined categories, including remote playback, audio
streaming, and video streaming. Of course, custom ones can
also be defined by the MRPs. Let’s have a look at the
initialization of the media router object, which maintains
the overall state of media routing. Once you’ve gotten a reference
to the singleton media router object, you want to register
the media router callback, which provides events on
media route changes, such as route selections,
modifications, and volume changes. Have a look at the API
reference for details. In this code snippet, the
particular callback flag causes the system to
immediately discover available media routes. Keep in mind that route
discovery may involve network calls, and therefore
you should be diligent in removing a callback
when the route discovery is no longer needed in your app. I also want to point out that
if you’re using fragments, another option is to use
Media Route Discovery Fragments, which gives you
the same hooks for callback registration. Once a media route is
selected by the user, the app can begin issuing
remote playback controls to the endpoint. The indications
are asynchronous, which makes sense considering
media endpoints may be remote. The media router
framework defines an intent-based protocol
for basic playback controls, such as Play, Pause, or Seek. You can find your definitions of
the action and extra parameters in the media control
intent class. This snippet illustrates
the indication of basic remote playback where
first, it constructs an intent with proper action
in category values as well as the
[? URI ?] of the media. It then checks if the
selected route is capable handling such request. It finally fires off the intent. The framework will
report the results of the invocation via the
asynchronous callback. While not included
in this snippet, of it is good practice to
account for situations where remote playback is not
possible, in which case your app should fall back
to the local playback. That’s it for an
overview of media router from an app casting prospective. Have a look at the
docs and samples, and stay tuned for the episode
on media route providers. Thanks for watching
and happy casting.


2 thoughts on “DevBytes: Media Router Framework – Part 1 – Media Router API”

  • Android Developers says:

    Today's episode of #DevBytes is from @Fred Chung. He explains how to cast media content to secondary devices.  Also refer to the Media Router developer guide at 

    In an upcoming episode (Part 2), we'll cover how media consumption device manufacturers can enable media route support on Android. Stay tuned.

    DevBytes: Media Router Framework – Part 1 – Media Router API


Leave a Reply

Your email address will not be published. Required fields are marked *