Media Router Framework – Part 2 – MediaRouteProvider
Articles Blog

Media Router Framework – Part 2 – MediaRouteProvider

name is Lisa Wray and I’m a Developer
Advocate at Google. Today I’m going to talk
about MediaRouteProvider. In the last episode, we talked
about the Android Support Library MediaRouter. That was the first part of
our series on the Media Router Framework, the API
for any Android app to cast its content via
supported media routes to remote devices. In this episode I’m going
to cover MediaRouteProvider. A MediaRouteProvider can be
used by other applications to control media content
playback equipment such as TVs, stereos, and home
theater components. If you are device manufacturer
then this DevByte is for you. Makers of media devices
can publish their products as media routes on Android by
implementing their own MRPs. The providers can then be
plugged into the framework and presented to any
Android application that supports media routes. This approach
allows applications to control content
playback equipment without knowing the specific and
possibly proprietary interfaces to manufacturers’
playback equipment. A sample implementation
of MediaRouteProvider is the Google Cast
SDK, which allows apps to cast content to Google
Cast-compatible receiver devices, such as Chromecast. If you’ve use one, you
know how satisfying it is to cast a video
from your mobile device to the big screen. First, an important note,
the media route framework we’re examining here is the one
in the Support Library, which means it is backward compatible
with Android 2.1 and above. It supersedes the media
router classes in the Android framework, meaning
should not use them. Use the classes in the v7
Media Router Library, instead. So how do we get started? Subclass MediaRouteProvider
and the constructor we register one or
more media routes was using a media
route descriptor. Each route needs
control intent filters. These filters tell
applications that use your route what types
of features are supported, including playback controls
that play, pause, rewind, fast forward, et cetera;
queuing features or playlist management; and
session features, meaning Android device to playback
device connection management. You can also set many other
capabilities of the route, such as the playback
type, which can be remote playback
or secondary output. The media type can
be audio or video. The volume can be
fixed or variable. And intent filters
we just discussed define playback controls such
as basic controls, queuing, and session management. Next, you need to implement
a route controller class that extends MediaRouteProvider,
RouteController. This class handles the
actual media control requests from other applications
supported by your route. Anything you defined
in your intent filters including playback
controls, queueing, and session features. This RouteController
class acts as the wrapper for the proprietary interface to
your media playback equipment. This is where the magic happens. Your implementation will depend
on your specific media device. And finally, it
should be instantiated in this helpful named method
onCreateRouteController of your MediaRouteProvider. Next is the service wrapper. To enable other applications
to use the provider, a MediaRouteProvider should
be wrapped in a service. To do this, extend the
MediaRouteProvider service class and provide an instance
of your MediaRouteProvider from within the class. You can make a
media route provider private within the scope of
an app by simply calling media route [? add ?] provider,
no service needed. But in this example, we’ll
make the MediaRouteProvider available to all
apps on the device. To do this, our
application must declare in the manifest a
service declaration for the MediaRouteProvider with
an intent filter for Android media MediaRouteProvider
service. This service is the same
one we just looked at. Finally, the
provider should watch for changes to the
discovery requests by implementing
onDiscoveryRequestChanged. In this method, we kick off
an update of the media routes the provider describes by
finding the routes that satisfy the new criteria specified
by the current request. To publish them we create a new
MediaRouteProvider descriptor with information about each
route and call setDescriptor again. This notifies the currently
registered callback. And this process usually
happens asynchronously. If you are a manufacturer
of media playback devices or you work with one, the
MediaRouteProvider is for you. Android devices everywhere can
be casting to your MRP shortly. Please take a look at
the docs and sample code and get started. My name is Lisa Wray. Thanks for watching.

6 thoughts on “Media Router Framework – Part 2 – MediaRouteProvider

  1. This episode of #DevBytes is from @Lisa Wray. Learn why and how to implement a MediaRouteProvider in this second part of our series on the Media Router Framework.

    To learn more:

    Media Router Framework – Part 2 – MediaRouteProvider

  2. Hi, this API looks VERY promising, but why doesn't the sample MediaRouteProvider appear in the youtube app ?

  3. with the information that this video has given me i cannot even get a simple hello world. does anyone know what piece of information i am missing(I have read through the links).

  4. Is it possible to cast the device screen using Media Route Provider? I' creating a casting device using Raspberry PI. I'm able to cast the media files, but not the device screen.

  5. I have found sample code from Gitt but after connecting my phone with TV using HDMI cable the Sample is able to play separate video on my TV but when my closing app and starting again ,it's not playing video, it just mirroring . if i switch off and switch on again my TV then it's working . Can you help me out for this issue.(


Leave a Reply

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

Back To Top