Figure 810: Google Chromecast
A popular target for MediaRouter, in some countries, is Chromecast, Google’s
lightweight streaming media player for televisions and other HDMI displays.
Originally, Chromecast was a “closed box”, with no official support for third-party
apps (and active work to block unofficial support). In early 2014, though,
Google finally opened up Chromecast to developers.
This chapter covers what it takes to enable an Android app to “cast” content to a Chromecast, possibly as part of a broader external display strategy.
In addition to the core chapters, you should read
the chapter on MediaRouter
before reading this chapter.
You will see two terms used in this chapter and in the online literature regarding all of this: Chromecast and “Google Cast”. Despite the similarities in their names, these are fairly distinct items.
Chromecast, as noted earlier in this chapter, is a streaming media receiver, sold by Google under their own brand.
Figure 810: Google Chromecast
It plugs into an HDMI port of a television or similar display, plus uses micro USB for supplying power.
However, rather than other streaming media receivers, that use Bluetooth or IR (infrared) peripherals for controlling the playback, Chromecast appears to use WiFi, designed to be controlled by a smartphone, tablet, or Chrome Web browser.
Chromecast itself runs its own OS, apparently a hybrid of Android and ChromeOS.
Google Cast can be thought of as a control protocol for Google Cast-enabled receivers. Through a Google-supplied SDK (or other means), Google Cast client apps (“senders”) can direct a Google Cast-enabled receiver to play, pause, rewind, fast-forward, etc. a stream.
Google Cast could, in theory, be “baked into” displays (such as a television), in addition to being supported by dedicated media receivers like the Chromecast.
Google Cast does assume that, in general, the media receiver runs its own OS and is capable of playing streaming media without ongoing assistance from the Google Cast client. Hence, the client is not “locked into” having to keep feeding content to the Google Cast client, allowing the user to go off and do other things with that client while playback is going on.
Chromecast goes to sleep if it detects that it is plugged into a television or monitor that is turned off (or perhaps even not accepting input from the HDMI port the Chromecast is using). While it is in this sleep mode, it may not appear as an available route. You may need to keep the display active to allow Chromecast to work properly. A 720p-capable pico projector, such as the Vivitek Qumi series, can be a handy way to have a test display for Chromecast (or for live video media routes) at your development station, without the bulk of another monitor, if you have a handy surface to project upon.
Also, note that a Chromecast “uses Google’s DNS regardless of what you have defined locally”, according to a Google engineer. That will preclude you from using any local domains on an organization’s own DNS server, without some tricky firewall configuration to route Google DNS requests to the in-house DNS server. Similarly, you cannot use machine names as pseudo-domain names, the way you might be able to using a regular Web browser.
Chromecast offers up remote playback media routes and works with RemotePlaybackClient,
as is discussed in the chapter on MediaRouter. The sample app
for RemotePlaybackClient was tested on a Chromecast.
If you want greater control than is offered via RemotePlaybackClient, though,
you can use the Cast SDK. This SDK is part
of the Play Services framework, not part of Android itself. It also works solely
with Google Cast devices, of which Chromecast is the only known example, whereas
other sorts of devices are able to publish remote playback media routes. Hence,
using the Cast SDK will tie you to Google Cast — and some of its restrictions,
both technical and legal — but will give you greater developer control over the
behavior of both the Google Cast device and your app.
This chapter will focus on the Cast SDK. See
the chapter on MediaRouter for coverage of RemotePlaybackClient.
There are three major components to the Google Cast environment:
The sender app is responsible for allowing the user to choose some media to play, then to control the actual playback (pause, start, stop, rewind, fast-forward, etc.).
The details of how to choose some media will depend heavily on the nature of the sender app. For example, a subscription-based streaming video service, such as Netflix, would allow the user to browse and search eligible content hosted by Netflix itself. Netflix presumably has its own Web service APIs that its own sender app would use for this purpose, and it is up to Netflix to offer a sensible UI for choosing a piece of media to watch.
Passing a reference (e.g., URL) to the receiver, and issuing control commands,
will either be handled by RemotePlaybackClient (on Android) or via a Google-supplied
SDK (for Android, iOS, or Chrome Web apps).
The details of how a receiver is implemented is up to the manufacturer of the Google Cast-enabled device. In the case of Chromecast, it is a version of the Chrome Web browser. In principle, the implementation could be anything; in practice, it is likely that the same basic software stack will be used, courtesy of licensing Google Cast technology from Google for streaming media devices.
Official Google Cast receiver software comes in three flavors: default, styled, and custom.
The default receiver is what you get by default, as you might have guessed. If you do nothing else, your sender will be communicating with the default receiver. In effect, the default receiver is a specific Chrome Web app, running on the Chrome browser inside of the Chromecast, that is responsible for playback of your chosen media.
Other than providing the URLs to the media, plus requests to pause, start, stop, etc. the playback, you have no control over the default receiver, particularly from a look-and-feel standpoint.
A styled receiver is one where you, the developer, supply light branding information that is applied to what otherwise is the default receiver, such as a logo.
Whereas using the default receiver requires no explicit registration with Google, using the styled receiver does require you to register your sender app with Google, at which point you will be able to provide a URL pointing to a CSS file that contains the custom styles.
If you would rather replace the default receiver functionality with your own, either to offer more functionality, or to consume media types that may require additional configuration (e.g., DRM), you can create a custom receiver. This, in effect, is a Chrome Web app, where you provide not only CSS, but the HTML and JavaScript as well. This is substantially more complicated, and it requires registration with Google (as with the styled receiver). However, you have far greater control over what appears on the television.
The list of supported media types is likely to change over time. At present, Google Cast-enabled devices are supposed to support major media types, such as:
Using the Cast SDK to develop for Google Cast devices has a fair number of dependencies… and not just dependencies on particular libraries.
If you are going to be using the default receiver, and you do not need to have debugging access to the device (e.g., to examine JavaScript logs from the Web rendering engine on the Google Cast device), you are welcome to develop your apps independently.
However, if you will use a styled or custom receiver, or you wish to gain debugging access to the device, you will need to register with Google.
This process will involve you agreeing to some terms of service (see below), along with paying a $5 registration fee.
The Google Cast SDK has separate Developer Terms of Service from anything else. If you are going to use the Google Cast SDK, you will be expected to agree to these terms as part of the registration processes. You are strongly encouraged to review these terms with qualified legal counsel. Failure to comply with the terms may cause your app (or, more accurately, your styled or custom receivers) to “be de-registered”, presumably meaning that it will no longer work.
These terms contain some curious clauses, worth discussing with your attorney, including a requirement to adhere to a massive design checklist, controlling the look-and-feel of your sender and receiver. This includes a specific requirement for the precise icon to be used for initiating communications with the Google Cast receiver. Those agreeing to these terms are also barred from doing things that might allow others to display content on a Google Cast receiver without using the SDK or breaking through any access controls on the Google Cast device (e.g., creating an exploit that roots it).
While registering your device is optional, it may be handy for custom receivers, so that you can debug your custom HTML and JavaScript that is being rendered by the Google Cast device.
First, you should configure your device to publish its serial number to Google when it checks for Google Cast software updates. For the Chromecast, this involves using whatever means you used to configure the Chromecast in the first place for your network (e.g., the Chromecast Android app). There should be an option for “Send this Chromecast’s serial number when checking for updates” — in the Chromecast Android app, this will be in the “Share Data” section of the device’s settings screen.
Once you have registered as a Cast SDK developer, the Google Cast SDK Developer Console will have an option for you to “Add New Device”. You will need the Google Cast device’s serial number — in the case of the Chromecast, this is etched on the underside of the device.
Note that it may take some time before your device registration will be complete, as the device will not find out about the registration until it checks for another update, and there does not appear to be a way to trigger this. Hence, you may need to wait a few hours. You will know that you have access once you can successfully connect, via a Web browser, to port 9222 on the IP address of the Google Cast device. For the Chromecast, the easiest way to get that IP address is through your Chromecast configuration tool (e.g., the Chromecast Android app). Note that the Web page may not be much (e.g., “Inspectable WebContents”), but it will not return a 404 or similar error code.
If you wish to use a styled or custom receiver, you will also need to register your application, in the same Cast SDK Console area. This will be covered in a future edition of this book.
You will need the Google Play Services SDK, which you may have used already for other portions of the Play Services framework, such as GCM, Maps V2, and so on.
You will also need the same mediarouter Android library project covered in
the chapter on MediaRouter, along with its dependencies
(e.g., the support-v4 library and the appcompat library).
The Play Services SDK (and its dependencies) is all that you need to write Cast SDK applications. However, Google has also published the Cast Companion Library (CCL), containing a lot of helper code to make it a bit easier for you to write apps that adhere to the design checklist
Coverage of the Cast SDK, including sample apps, will be added to this chapter in a future edition of this book.