[MUSIC PLAYING]
JAMES ROMO: As an Android TV developer,
you dedicate time and effort to create a great watching
experience for your users.
Currently, with Google Cast, users
are able to cast to Android TV to watch their content
and use the phone's control playback.
While this provides users with an easy way
to quickly jump right into their content,
we also want them to be able to control their TV with a remote
like we're all accustomed to.
Cast Connect bridges this gap to a native experience,
allowing users to cast directly into your native and your TV
app.
Then they can either pick up the remote
or use their phone to continue to interact.
Hi.
I'm James Romo from the Nest Partner engineering team,
and I'm going to tell you about Cast Connect, the solution
to seamlessly combine Cast with Android TV
to bring your app to the modern Cast experience.
A web receiver is an HTML JavaScript app
that runs on Cast devices, such as Chromecast and Google Nest
Hub.
Senders are an Android or iOS app, Chrome browser,
or voice with assistant which triggers connections
to Cast devices.
Before Cast Connect, if you use your phone or voice
to cast to Android TV, your content
would play on the web receiver.
You would then be forced to return your phone
to continue browse content instead of using the Android TV
remote.
The goal of Cast Connect is to combine
the best of both worlds.
It allows users to easily start a session
with their voice or mobile device
and continue to control the experience with a remote
to easily re-engage with your Android TV app.
Let's take a look at how to add Cast Connect to your app.
To prepare for Cast Connect, your Android TV app
will need to use Jetpack AndroidX
and must also be integrated with MediaSession
to provide playback data, including metadata and playback
state.
Wire up basic callbacks such as play, pause,
and seek, and specify your supported actions.
To enable support for Cast Connect,
you'll need to pull in the new play-services-cast-tv library,
which includes all the Cast Connect APIs.
You also need to provide the Android TV package name
and register Android TV test device in the Cast developer
console so your native app can properly be launched.
In addition, your Android iOS and Chrome Center apps
will need to set the flag to enable Cast Connect, which I'll
show you how to use shortly.
Next, let's take a look at what you
need to do for MediaSession, which
is the basis for Cast Connect.
When your playback state changes,
you'll need to make sure it's reflected
with the PlaybackStateCompat.
Using a builder, set the state and available actions
for your MediaSession.
These actions are available with the PlaybackStateCompat
and can be customized depending on the type of media
being played.
The playback state is used to drive the UI
and to tell your players the available playback
actions and their expanding controller and media
controller.
Alternatively, if you're using ExoPlayer,
you can use the MediaSessionConnector
to automatically track the playback state instead
of tracking changes manually.
Additionally, you'll need to set the metadata
for the content currently playing on your media session.
Cast Connect will use this information for all the Cast
Center UI.
MediaSession callbacks are used to respond
to media actions triggered by Cast Connect in response
to sender actions, remote buttons, and voice commands.
Once you receive a callback, such as play, pause, or seek,
you'll need to update your MediaSession
and perform these actions on your player.
The key idea for Cast Connect is to maintain your existing
functionality by sending the same media
status that a web receiver would normally provide.
If set up properly, your centers will
receive the exact same data from the Android TV app
so that you'll not need to make any additional changes
besides enabling Cast Connect support.
This media status is generated automatically
by pulling properties from the MediaSession,
as well as additional customizations
through modifiers, which I'll talk about later.
Next, let's take a look at the Senders.
The main change you need to make on the Sender side
is simply declaring that they are
compatible with a native Android TV app.
This can be accomplished on Android
by setting the Android receiver compatible flag
to true on the launch options on the Android Sender.
On the iOS sender, this is done by setting
the same field on the GCK launch options
which are then set on the GCK cast context.
This same field is also available on the Cast options
on the Chrome Sender.
If the Android receiver compatible is not
set when you cast an Android TV, it
will open the normal receiver instead of opening
your native Android TV app.
Now that we have the setup complete on the Senders, let's
dive into what's needed to add Cast Connect to your Android TV
app.
First, you'll need to add the launch and load actions
to your Android manifest.
The launch action lets Android TV know that you
support the Cast protocol.
You'll want to put this action in the first activity that you
want to load when a session is first launched,
such as your app home screen.
The load action is required so that your Android TV
app is able to handle your load requests coming
from your senders.
These actions are usually handled
in your play activity, or another activity
that you use to handle your deep links.
When you create a MediaSession, you'll
need to specify the current MediaSession
token to the mediaManager so it knows
where to send the commands and get the media status.
When you release the media session
due to inactive playback, you should set a null token
to the MediaManager.
Here's an example of properly handling the load intent
in a player activity.
On Create, you'll want to set the MediaLoadCommandCallback
to handle the load events.
I'll talk about that more in a second.
In both the onCreate and onNewIntent,
you should handle the intents that
are being fired towards see if they are
load intents from the Cast SDK.
Using the MediaManager, you can check
this intent using onNewIntent to see if it's
coming from Cast Connect.
If it is, simply return early, and it'll
be passed the MediaLoadCommandCallback,
and onLoad will trigger when the intent has been been parsed.
If not, continue handling your non-cast intent
like you normally would.
Here's a simple example of that MediaLoadCommandCallback
we set previously.
As you can see, the onNewIntent onLoad
takes in the MediaLoadRequestData object,
which is the same kind of load request
you would normally get on your web receiver
and contains the same information.
Parse the load request like usual,
passing the information to your player
to start playback, and set the data on your media manager.
And it's that simple.
You should now have your content playing natively
on your Android TV device.
Next, let's take a look at handling Cast-specific media
commands.
Previously, you saw how to set up your media session
to handle simple actions like play, pause, and seek.
However, the Cast SDK has more advanced features
that MediaSession doesn't cover.
MediaCommandCallback handles cast
specific actions, such as setting tracks
for captions in different audio languages and the ability
to skip ads.
Using the info passing these callbacks,
you can perform these actions on your player.
Additionally, you may have noticed that MediaSession
doesn't cover everything your app needs to do
to apply your business logic.
Since the MediaStatus is the foundation of the cast
protocol, ports the playback status to the senders,
and is generated from MediaSession,
it needs to be further customized
to reflect the Cast-specific properties.
You can use modifiers from the MediaManager
to overwrite fields, provide app-specific details,
such as live or ads data, and provide any custom data
that your web receiver would usually
provide to your senders.
These modifiers can be set once and will
persist and be applied on top of every media status sent out
until they're removed.
Additionally, Cast Connect provides
a MediaStatusInterceptor, which allows for one last chance
to check and set the values on the MediaStatus
before it's sent over the wire.
Common situations might be debugging, logging,
adding analytics, and other business specific tasks.
Next, let's take a look at the features of Cast Connect.
We are proud to announce that Cast Connect supports
our existing cast features, including tracks, queuing, ads,
and live.
One new feature that's supported is the ability
to fall back to web receiver when a device attempts
to connect to the Android TV device
using a launch request checker.
Android TV is historically a mostly single user experience,
while Cast can be used by multiple users at once.
There may be situations where the Cast Sender user doesn't
match the Android TV user and the Android TV app
is unable to switch on the fly or deliver the same content
from a different user.
In these cases, the checker is able to check the credentials
of the user attempting to connect to Android TV
and, instead, open the web receiver.
If your Android TV app needs to be
able to decide whether to launch the native app or the web
receiver, depending on the user credentials,
you'll need to set the Launch Request
Checker in your ReceiverOptionsProvider.
In this checker, you can override
the checkLaunchRequestSupport method.
If it returns true, the native Android TV app
will continue launching.
But if it returns false, your web receiver
will be launched instead.
In this method, you're provided with a launch request,
which includes the credentials data that your sender provided.
Depending on your app, you can allow or disallow
anonymous users, check credentials
depending on the platform, and reject or allow
the launch credentials if they don't meet your conditions.
This allows for a ton of flexibility
to let your apps perform the way you want them to.
And that covers the basics of Cast Connect
and how to add this exciting new feature
to your existing Android TV and Cast apps.
Be sure to check out our documentation, samples,
and code labs for more information.
And subscribe to our announcements
to get the most up to date information about Cast.
Thanks, and happy casting.
[MUSIC PLAYING]