Messaging between the cloud and the device (Cloud to Device Messaging)

Messaging between the cloud and an Android device (C2DM) is a service that allows developers to send data from servers to applications on Android devices. The service provides a simple and easy mechanism that servers can use to inform mobile applications about the connection with the server directly to receive application updates or user data. The C2DM service manages all aspects of message queuing and delivery to the target application running on the target device.

Characteristics of the Android service C2DM

Key Features of C2DM:

1. It allows third-party application servers to send small messages to their Android applications. The messaging service is not intended to send a large amount of user data through messages. On the contrary, it should be used to tell the application that there is new data on the server and that the application can pick it up.
2. An application on an Android device does not need to be launched to receive messages. The system will launch the application through the target broadcast when a message arrives if the application is installed with the appropriate broadcast receiver and permissions.
3. It uses an existing connection for Google services. This requires users to set up a Google account on their mobile devices.

Architecture Overview

Messaging between the cloud and the device includes key terms and concepts that can be classified into two divisions. It:

1. Components
2. Credentials

Credentials

Identifiers and tokens that are used at various stages of C2DM to ensure that all parties are authorized and that the message is routed to the right place.

Sender ID

This is the email account associated with the application developer. The sender ID is used during the registration process to identify an Android application that is allowed to send messages to the device. This identifier is usually based on a role, not a personal account, for example, my-app@gmail.com

Application ID

This is the identifier of the application that registers to receive messages. An application is identified by the name of the package from the manifest. This ensures that the messages are aimed at the correct application.

Registration ID

An identifier issued by C2DM Android servers to the application, allowing it to receive messages. As soon as the application receives the registration identifier, it sends it to a third-party application server, which uses it to identify each device that has registered to receive messages for this application. In other words, the registration identifier is tied to a specific application running on a specific device. For a Google account for C2DM to work, your mobile device must have at least one authorized Google account.

Sender Auth Token

ClientLoginAuth is a token that is stored on a third-party application server and gives the application server authorized access to Google services. The token is included in the POST header of requests that send messages.

C2DM Life Cycle

The main processes used in messaging between the cloud and the device:

1. Enabling C2DM: An Android application running on a mobile device registers to receive messages.
2. Sending a message: a third-party application server sends messages to the device.
3. Receiving a message: An Android application receives a message from a C2DM server.

Enabling C2DM

The following is the sequence of events that occur when an Android application running on a mobile device is registered to receive messages:

1. The first time the application is to use the messaging service, it sends a C2DM registration request to the server.
   This registration request includes the sender ID (this is an account authorized to send messages to the application, which is usually the email address of the account configured by the application developer) and the application ID.
2. The C2DM server broadcasts a request that gives the application a registration identifier.
   The application stores this identifier for future reference. Google may periodically update the registration identifier, so the application is designed with the fact that the registration intent can be called up several times.
3. To complete the registration, the application sends the registration identifier to the application server. An application server typically stores a registration identifier in a database.
   The registration identifier is valid until the application itself cancels the registration or until Google updates the registration identifier for your application.

Message sending

In order for the application server to send messages, the following conditions must be met:

1. The application has a registration identifier that allows it to receive messages for a specific device.
2. The registration identifier is stored on the application server.

There is one more condition that is necessary for the application server to send messages: Client Login authorization token. Client Login token authorizes the application server to send messages to a specific Android application. The application server has one Client Login token for a specific third-party application and several registration identifiers. Each registration identifier represents a specific device that has registered to use the messaging service for a particular third-party application.

The sequence of events that occur when the application server sends a message:

1. The application server sends a C2DM message to the servers.
2. Google queues and saves a message if the device is inactive.
3. If the device is online, Google sends a message to the device.
4. On the device, the system broadcasts the message to a specific application through the target broadcast with the appropriate permissions, so that only the target application will receive the message. This launches the application. The application does not require a preliminary launch to receive a message.
5. The application processes the message. If the application performs non-trivial processing, you may want to use wake lock and do any processing in the service.

An application may unregister C2DM if it no longer needs to receive messages.

Receive message

This is the sequence of events that occurs when an Android application running on a mobile device receives a message:

1. The system receives an incoming message and extracts the raw key / value pairs from the message.
2. The system passes the key / value pairs to the target Android application in the request (in a Intent) as a set of additional parameters.
3. An Android application retrieves raw data from a request (intent) by key and processes the data.