{Cloud to device messaging}

Android Cloud to Device Messaging (C2DM) is a service that helps developers send data from servers to their applications on Android devices. The service provides a simple, lightweight mechanism that servers can use to tell mobile applications to contact the server directly, to fetch updated application or user data. The C2DM service handles all aspects of queuing of messages and delivery to the target application running on the target device.

CHARACTERISTICS OF ANDROID CLOUD TO DEVICE MESSAGING (C2DM)

Primary characteristics of C2DM are:

1. It allows third-party application servers to send lightweight messages to their Android applications. The messaging service is not designed for sending a lot of user content via the messages. Rather, it should be used to tell the application that there is new data on the server, so that the application can fetch it.
2. An application on an Android device doesn’t need to be running to receive messages. The system will wake up the application via Intent broadcast when the the message arrives, as long as the application is set up with the proper broadcast receiver and permissions.
3. It uses an existing connection for Google services. This requires users to set up their Google account on their mobile devices.

ARCHITECTURAL OVERVIEW

Cloud to Device Messaging includes key terms and concepts which can be classified in to two divisions. They are:

1. Components
2. Credentials

Credentials

The IDs and tokens that are used in different stages of C2DM to ensure that all parties have been authenticated, and that the message is going to the correct place.

Sender ID

An email account associated with the application’s developer. The sender ID is used in the registration process to identify a Android application that is permitted to send messages to the device. This ID is typically role-based rather than being a personal account—- for example, my-app@gmail.com

Application ID

It is the id of an application that is registering to receive messages. The application is identified by the package name from the manifest. This ensures that the messages are targeted to the correct application.

Registration ID

An ID issued by the C2DM servers to the Android application that allows it to receive messages. Once the application has the registration ID, it sends it to the third-party application server, which uses it to identify each device that has registered to receive messages for a given application. In other words, a registration ID is tied to a particular application running on a particular device. Google User Accountfor C2DM to work, the mobile device must include at least one logged in Google account.

Sender Auth Token

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

LIFE CYCLE OF CLOUD TO DEVICE MESSAGING

Here are the primary processes involved in cloud-to-device messaging:

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

   Following are the sequence of events that occurs when an Android application running on a mobile device registers to receive messages:

   1. The first time the application needs to use the messaging service, it fires off a registration Intent to a C2DM server.

   This registration Intent includes the sender ID (that is, the account authorized to send messages to the application, which is typically the email address of an account set up by the application’s developer), and the application ID.

   1. The C2DM server broadcasts a Intent which gives the application a registration ID.

   The application stores this ID for later use. Google may periodically refresh the registration ID, so the application is designed with the understanding that the REGISTRATIONntent may be called multiple times.

   1. To complete the registration, the application sends the registration ID to the application server. The application server typically stores the registration ID in a database.

   The registration ID lasts until the application explicitly unregisters itself, or until Google refreshes the registration ID for your application.

   Sending a Message

   For an application server to send a message, the following things must be in place:

   • The application has a registration ID that allows it to receive messages for a particular device.
   • The Registration Id is stored at the Application Server.

   There is one more thing that needs to be in place for the application server to send messages: a Client Login authorization token. The Client Login token authorizes the application server to send messages to a particular Android application. An application server has one Client Login token for a particular 3rd party app, and multiple registration IDs. Each registration ID represents a particular device that has registered to use the messaging service for a particular 3rd party app.

   Here is the sequence of events that occurs when the application server sends a message:

   1. The application server sends a message to C2DM servers.
   2. Google queues and stores the message in case the device is inactive.
   3. When the device is online, Google sends the message to the device.
   4. On the device, the system broadcasts the message to the specified application via Intent broadcast with proper permissions, so that only the targeted application gets the message. This wakes the application up. The application does not need to be running beforehand to receive the message.
   5. The application processes the message. If the application is doing non-trivial processing, you may want to grab a wake lock and do any processing in a Service.

   An application can unregister C2DM if it no longer wants to receive messages.

   Receiving 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 the incoming message and extracts the raw key/value pairs from the message payload.
   2. The system passes the key/value pairs to the targeted Android application in a Intent as a set of extras.
   3. The Android application extracts the raw data from the Intent by key and processes the data.