# Overview

The Cast SDK allows a user to select streaming audio-visual content using a
*Sender* , and play it on (or cast it to) another device known as the *Receiver*,
while controlling playback using the Sender.

The term *Sender* refers to an app that plays the role of controller
for the Cast session. A Sender initiates the Cast session and manages the user's
interaction with the content.

There are many kinds of Senders, including mobile apps and Google Chrome web
apps, as well as virtual control surfaces on touch-enabled Google Home devices.
The media controls in the Chrome web browser function as a Sender, as does
Google Assistant itself.

The term *Receiver* refers to an app running on a Cast-enabled device that is
responsible for responding to Sender commands and for conveying streaming
content from an online streaming service to the Cast-enabled device. Examples of
Cast-enabled Receiver devices include Chromecasts, smart televisions, smart
screens, and smart speakers.

The Cast SDK also supports multiple Senders connecting to a Cast session. For
instance, one Sender could start a session on a Receiver and another Sender
could join the same session to control playback, load new content, or queue more
content for later.

## App components and architecture

Google Cast supports Sender app development for
[Android](https://developers.google.com/cast/docs/android_sender/integrate),
[iOS](https://developers.google.com/cast/docs/ios_sender/integrate), and
[Cast-supported web platforms](https://developers.google.com/cast/docs/web_sender), such as Google Chrome.

A Receiver app runs on a Cast-enabled device, examples of which include:

- A Chromecast connected to a high-definition television or sound system.
- A Cast-enabled television.
- A Cast-enabled smartscreen.
- A Cast-enabled Android device, such as Android TV.

> [!NOTE]
> **Note:** The Cast protocol is platform-independent, so a particular site or service's Cast Senders may run on any supported platforms (Web, iOS, Android) and interact with the corresponding Cast Receiver running on Web or Android. Receivers (except for the Default Receiver) are registered using a distinct app ID, which is used to 'key' the corresponding Sender apps to that Receiver. This mechanism prevents a Sender from attaching to and controlling Receivers other than those that share the same app ID.

![High-level Cast architecture](https://developers.google.com/static/cast/images/cast_interaction_diagram.png)

A Sender controls media playback on a Receiver using
[Media Playback Messages](https://developers.google.com/cast/docs/reference/messages) defined by the SDK. If
an app use case requires sending data that is not formally defined in the
standard Media Playback Messages, you may use the `customData` field provided by
several message types to pass ancillary data.

There are two basic Cast app development scenarios:

1. An end-to-end Cast-based solution. In this scenario, the developer must build both the Sender app and two Receiver apps: an Android TV Receiver and a Web Receiver (more on this below).
2. A Cast-enabled Sender app that can cast content (a screen or a multimedia stream) to Google's default Cast Receiver, which is called the Default Media Receiver. In this scenario, the developer only needs to build one app, the Sender. The Default Media Receiver is useful for learning and very limited playback scenarios. It is not practical for receivers that require custom business logic, credentials, rights management, or analytics.

## The Google Cast SDK

The Google Cast SDK is made up of several
[Cast API libraries](https://developers.google.com/cast/docs/reference). Along with the APIs, there are two
kinds of documentation:

- API guides that orient you in how to use the APIs with [sample code](https://developers.google.com/cast/docs/sample_apps) demonstrating Cast features, and
- [Codelab tutorials](https://developers.google.com/cast/codelabs) that instruct you in the process of developing specific kinds of Cast apps.

The Cast APIs are divided according to platform and Cast app type.
[Table 1](https://developers.google.com/cast/docs/overview#apidocs_table) contains links to the guides for the various Cast
APIs.

| Platform | Sender | Receiver |
|:---:|:---:|:---:|
| Android | [Android Sender apps](https://developers.google.com/cast/docs/android_sender/integrate) | [Android TV Receiver Overview](https://developers.google.com/cast/docs/android_tv_receiver) |
| Web | [Web Sender apps](https://developers.google.com/cast/docs/web_sender/integrate) | [Web Receiver Overview](https://developers.google.com/cast/docs/web_receiver) |
| iOS | [iOS Sender apps](https://developers.google.com/cast/docs/ios_sender/integrate) | n/a |
[*Table 1: Cast SDK Guides*]

### Types of Sender Apps

Sender Apps can run on three platforms:

- Web
- Android
- iOS

Although the choice of Sender type will likely be driven largely by the
Sender platforms that you intend to support, it's important to know the
capabilities and limitations of each type of Sender (see
[Table 3](https://developers.google.com/cast/docs/overview#sender_comparison_table)).

| Capability | Android Sender | iOS Sender | Web Sender |
|---|:---:|:---:|:---:|
| Ad breaks and companion ads within a media stream | Yes | Yes | Yes |
| Styled text tracks | Yes | Yes | Yes |
| Group, style and activate media tracks | Yes | Yes | Yes |
| Autoplay and Queueing (edit, reorder, update) | Yes | Yes | Yes |
| Custom channels | Yes | Yes | Yes |
| Custom actions | Yes | Yes | Yes |
| Full Cast UI, including controller and minicontroller | Yes | Yes | No |
| Intent to Join | Yes | No | No |
[*Table 3: Senders Comparison*]

### Types of Receiver apps

Receiver apps handle communication between the Sender app and the Cast device.
There are two main types of Receiver: the **Web Receiver** and the **Android TV
Receiver**. You are expected to provide a Web Receiver at a minimum, and
encouraged to provide an Android TV Receiver to maximize the user's experience
with your application.

There are three types of Web Receiver, each with a distinct set of qualities and
capabilities:

- The **Custom Receiver**, which allows for custom logic, branding and modification of controls.
- The **Styled Media Receiver**, which allows for customized branding.
- The **Default Receiver**, which is the most basic type. This does not allow for any customization, and is not suitable for production apps.

In addition to the capabilities provided by the Custom Receiver, the Android TV
Receiver provides [Cast Connect](https://developers.google.com/cast/docs/android_tv_receiver), a set of
capabilities that provide a native experience for your users, seamlessly
combining Cast with Android TV.

[Table 2](https://developers.google.com/cast/docs/overview#receivers_comparison_table) highlights the capabilities of the
different types of Receivers.

|   | Android TV Receiver | Custom Receiver | Styled Media Receiver (SMR) | Default Media Receiver |
|---|:---:|:---:|:---:|:---:|
| Platform |||||
| Android-based (Java/Kotlin) | Yes | No | No | No |
| Web-based (HTML5) | No | Yes | Yes | Yes |
| Requirements |||||
| Must be registered | Yes | Yes | Yes | No |
| Capabilities |||||
| HLS and DASH media playback | Yes | Yes | Yes | Yes |
| Support for touch controls | Yes | Yes | Yes | Yes |
| Handles voice commands from Assistant-enabled devices | Yes | Yes | Yes | Yes |
| Customizable visual style and branding | Yes | Yes | Yes | No |
| Handles custom messages | Yes | Yes | No | No |
| [Cast Connect](https://developers.google.com/cast/docs/android_tv_receiver) | Yes | No | No | No |
[*Table 2: Receivers Comparison*]

The choice between the three Web Receiver options depends on which
[media types](https://developers.google.com/cast/docs/media) the app needs to support, the degree of UI
customization required, and any custom logic requirements.

> [!WARNING]
> **Warning:** To integrate the Cast API into your app, your app needs to use a [media format supported by Cast](https://developers.google.com/cast/docs/media), such as HLS or DASH. If your app requires an unsupported media format, you will not be able to integrate Cast into your app.

#### Determine which type of Web Receiver to build

Provided your app can integrate with Cast, use the following prompts to
determine which type of Web Receiver you should build:

|---|---|---|
| Create a Custom Receiver if: |||
| The app requires one or more of the following special capabilities: <br /> - Styling not provided by the Styled Media Receiver - Modifications to the touch controls - Authorization or authentication - Receiver analytics - DRM license delivered separately from the manifest - Pre-, mid-, or post-advertising - Any other custom Receiver functionality or custom JavaScript logic | OR | |---| | - The app requires custom styling | | AND | | - The styling capabilities of the Styled Media Receiver are insufficient | |

|---|
| Create a Styled Media Receiver if: |
| |---| | - The app requires custom styling | | AND | | - The styling capabilities of the Styled Media Receiver are sufficient | | AND | | - The app does not require any of the special capabilities listed above | |

|---|
| Use the Default Media Receiver if: |
| |---| | - The media format is supported | | AND | | - The app does not require custom styling | | AND | | - The app does not require any of the special capabilities listed above | |