Best Practices: Android’s Cloud to Device Messaging Service (C2DM)

Android Developers should be aware that there is an alternative to regularly polling a server for app updates.  Since the introduction of Android 2.2 (API level 8), developers have been able to leverage the Cloud To Device Messaging (C2DM) service, which allows a server to “push” messages to a specific client.

If you think about it, if the applications on a given device were constantly performing background polling, the drain on the device’s battery life could be extreme.  And the drain would increase as multiple apps take their turn polling.  There needs to be a balance struck to ensure a suitable compromise between fresh data and the resulting power drains.

C2DM allows the Android Developer to have the server notify the device with a message to indicate that an update or new data is available.  This eliminates the need for background polling, and results in increased efficiency.  If we were to use a metaphor, instead of constantly calling Mom for news from home, now Mom can call us when there is something she needs to share.  While Mom might like having us call all the time, the second method is far more efficient.

So how doesC2DM work?

Devices use C2DM when the Android Development team implements Intents and Broadcast Receivers. This means that the application on the Android device doesn’t need to be running to get the messages.  The server, meanwhile, has the job of transmitting these messages, which t does by utilizing the C2DM service.

Within each device, the C2DM service maintains an open TCP/IP connection, which allows it to instantaneously transmit information when needed. This service is responsible for maintaining and restarting the connection, queuing messages, and resending messages that were not received.

Limitations of C2DM

For all of the positives found with C2DM, don’t assume that it is a blanket replacement for background polling. It is ideally suited in scenarios where only one device (or a small, identifiable group of devices) needs to be updated at a given time – as with email.

C2DM’s real-time nature of each push makes it suited for updates that are going to be delivered at a sporadic rate.  But keep in mind that there are no guarantees of successful message delivery.  Latency and delivery order are also unpredictable.  Thus, if your message is critical or is time-sensitive, don’t rely on C2DM.  Moreover, developers at Unbounded Solutions recommend the implementation of a traditional background polling activity at relatively long intervals to ensure delivery of all data.

With messages limited to 1024 bytes, clearly they can’t carry much in the way of a payload.  A great work around to that is to have the message send information to instruct the client app to query the server.  Once that action is started, the server can send the larger amount of data directly.

C2DM is centered around existing Google services and it requires Google Play to be installed on the device.  Of course, you will need to have a Google account, and for that account to be properly configured.

Presently, all new C2DM accounts receive a development quota which is capped at 200,000 messages per day. If your production requirements demand more than that limit, you can request an increase from Google.  Information on how to do that is included in the confirmation email you’ll receive from Google.

Sign Up to Use C2DM

As hinted at above, developers must sign up with google to access the C2DM service.  You can begin that process and see the terms of service at this URL:

During registration, you’ll be asked to estimate the number of messages you expect to send on a daily basis, as well as your estimate of the peak number of queries per seconds.  If you expect to need more than the 200,000 messages allotted by default, keep in mind that the C2DM team will use this information when they gran larger quotas.

Additionally, you will need to provide the application package’s name as well as three email addresses.  The addresses needed include one to be used as a role account to authenticate with the C2DM server and which will send the messages from your server.  A second email address is needed as an escalation address form urgent issues.  The third address is a simple contact email address.

The authentication role email account should be a Google account used specifically for use with the C2DM service. It is strongly advised that you create a new account for this purpose as it will be used for providing all of the authentication details to Google.

After you receive the confirmation message indicating that your account has been enable and ready to send C2DM messages, you can now update the application to register itself with the C2DM service along with each device upon which it will run.

Register Devices with the C2DM Server

Your application must first register each installed instance of it with the C2DM service in order to get C2DM messages.  You can so this by adding a uses-permission node to your manifest:

<uses-permission android:name="" />

Developers should also define and request a signature-level permission which will restrict the receipt of C2DM messages targeted at your application only to applications signed with the same key:

<permission android:name="com.example.myapp.permission.C2D_MESSAGE"
            android:protectionLevel="signature" />
<uses-permission android:name="com.example.myapp.permission.C2D_MESSAGE" />

Registering an application for C2DM messaging is a three-step process, as indicated in the diagram below:

C2DM App Registration Process for Android

Sending C2DM Messages to Devices

Once you’ve recorded a particular device’s registration ID on your server, it’s possible for it to transmit messages to that device, as outlined in the image below:

Transmitting messages with C2DM for Android

Your server transmits a message to the C2DM service using POST requests to  Each message that includes the following parameters:

registration_id—This is the address of the targeted device and application pair.

collapse_key—When the target device is offline or unavailable, intended messages transmitted will be queued.

data.[key]—Payload data delivered in the form of key/value pairs. Each pair will then be passed into your application as extras within the C2DM Message Intent, using the keys you have specified. As we mentioned above, each C2DM message is limited to 1024 bytes.  That means that your payload data must be kept to the bare minimum—generally you’ll only want to provide information necessary for the client to perform an efficient lookup.

delay_while_idle—Messages transmitted to a device will be sent as quickly as possible by default.  However, by setting this parameter to true, Android developers may delay the transmission until the device is active.

In addition to the POST parameters, you must include a header with a Google ClientLogin auth token with a cookie which has to be associated with the Android C2DM service.

We hope that this gives you a basic understanding of what you can do with the C2DM service, as well as the limitations of the concept.  If you’ve found it useful, please share this post across your social networks, and if you have questions or comments on this topic, please add them to the comments section below.

Leave a Comment

Your email address will not be published. Required fields are marked *