Google Cast for audio devices support only audio playback. This guide describes how to optimize Cast applications for audio-only devices and take advantage of the reduced demands on memory, CPU, and network bandwidth utilization.
An app that supports Google Cast for audio must take the following into consideration:
The first step in developing a Cast application to support Google Cast for audio is to develop a Cast application for audio-video, and make sure that it runs on a Chromecast. This document assumes you have developed and tested such an app.
An app may support both audio-video and audio-only devices. It needs to know when it is casting to one versus the other and take measures to ensure the best user experience under the given scenario.
For example, dual video and audio apps (like local/NAS file playback applications) should enable casting to audio-only devices in order to support playing audio files, but the app should not allow the user to send video files to the audio-only device. The app can use the device capabilities APIs for senders described below to determine the content appropriate for the device.
To support Google Cast for audio, your app must do the following:
Support audio-only: streaming music and audio files, radio, etc. The media streamed to the Web Receiver app must not be a video stream. Also, avoid streaming graphics and images to improve application launch time and memory usage. See Memory usage guidelines, below.
Run as expected on a Cast for audio device as well as a regular Chromecast.
Your app can know whether it is running on an audio-only device by virtue of the device capabilities APIs, available from the device itself or through the sender or receiver APIs.
The CAST-DEVICE-CAPABILITIES HTTP header provided by the Cast device during application launch describes the device capabilities. The device sends a request with this header to the server hosting the Web Receiver app. The header for an audio-only device describes the device capabilities with CAST-DEVICE-CAPABILITIES: {"display_supported":false}.
When your server receives the request from the device, you can use the information in this header to redirect the request to the Web Receiver app which is optimized for audio devices.
Web Receiver APIYou can get the same device capabilities object by calling CastReceiverManager.getDeviceCapabilities() when the Web Receiver app is loaded.
See Device capabilities for more information.
Sender APIsEach of the Cast sender APIs has the device capabilities information as well. These let your sender app determine which kind of media to send to the receiver. If your app supports both audio and video, it can avoid sending video content to audio-only devices. Also, your app can control the volume using the method most appropriate for the device, as described in the Design Checklist. See the following device capabilities APIs for senders:
Web Receiver apps running on audio devices must manage memory usage as follows:
For most Google Cast for audio devices, the sender application controls the device's full volume range, not just the audio source input volume, as with a Chromecast device. This means the volume change increments must be smaller for audio-only applications. See the following documents for guidelines on providing volume control in your app:
Google Cast for audio devices may have their own playback controls (such as buttons, remotes). These use the media playback messages defined for the urn:x-cast:com.google.cast.media namespace, as described in Media Playback Messages, to control playback on the receiver application. Your receiver application must support these media playback messages to support the device's playback controls.
Also, your sender app should support the Messages from receiver to sender so that if the user changes the media state with the device controls, your sender app can receive a status message from the receiver and update the UI accordingly.
Device displayA Google Cast for audio device may have an LCD screen on the device or a device-specific control application that displays media metadata. Your receiver app must provide this metadata for all audio tracks and ensure it is in sync with the content currently playing to ensure the metadata displays appropriately on the display. If the application is using custom metadata, it must also provide the standard audio metadata (track name, artist name, album title, etc.) as described for each platform below.
The receiver gets the metadata from the sender when it loads the media. In your sender app, with the command to load the media on the receiver, you must specify the fields described below so that the metadata will display on the Google Cast for audio device. Use the following APIs:
Android MediaMetadata withMEDIA_TYPE_MUSIC_TRACK and:
iOS GCKMediaMetadata with GCKMediaMetadataType GCKMediaMetadataTypeMusicTrack and:
Chrome MediaInfo with MusicTrackMediaMetadata and:
If the Cast app manages a media queue on the receiver or in the cloud, the Web Receiver must broadcast any media status updates using the urn:x-cast:com.google.cast.media namespace so that all senders will be synchronized.
You must register your Google Cast for audio device for testing and register your app to support Google Cast for audio devices, by using the Google Cast SDK Developer Console.
For unpublished apps, such as those used for testing, you must also select the option to support audio-only devices in order for the app to discover audio-only devices.
Note: Some currently-registered Music & Audio applications may have been enabled with support for Google Cast for Audio automatically when this feature was launched. Review your app's settings in the Google Cast SDK Developer Console to be sure it is represented appropriately. Google Cast for Audio 2.0Google Cast for Audio (GC4A) 2.0 is the next generation Cast audio platform designed to target low memory devices, to expand the ecosystem of devices that can stream your content. Because GC4A 2.0 targets audio platforms, the web API set is reduced to align with displayless devices. GC4A 2.0 is rolling out to new and existing speakers that support cast.
Testing and DebuggingAs all supported speakers will be transitioning to GC4A 2.0, it's important that audio app developers test their apps on GC4A 2.0. You can test your Cast app for GC4A 2.0 on any of the GC4A 2.0 devices listed here.
GC4A 2.0 does not support Chrome Remote Debugger. If you want to debug your app, Google recommends using the Cast Debug Logger.
Available GC4A 2.0 DevicesThis is a non-comprehensive list of GC4A 2.0 devices:
Testing of all the app features on GC4A 2.0 is recommended. Be sure to include testing of playing all media types (podcasts, streams, etc), pausing, scrubbing, skipping, changing playlists, stopping, and reconnecting Cast.
Supported APIsGC4A 2.0 supports the following APIs:
SW_SECURE_CRYPTO) is supportedAES-CBC decryptionGC4A 2.0 does not support:
While Cast Receiver applications are expected to be universal for all cast devices, it can sometimes be helpful to identify which device you are running on. GC4A 2.0 Devices can be identified using the user agent string.
CrKey/ and a version. Ex: CrKey/1.68.000001.Castlite/ and a version. Ex: Castlite/1.0.Please contact gc4a-support-external@google.com if you need help setting up for testing, or are unable to use a Bose speaker.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3