Migration

Android Cloud to Device Messaging (C2DM) is deprecated. The C2DM service will continue to be maintained in the short term, but C2DM will accept no new users, and it will grant no new quotas. C2DM developers are strongly encouraged to move to Google Cloud Messaging (GCM). GCM is the next generation of C2DM.

This document is addressed to C2DM developers who are moving to GCM. It describes the differences between GCM and C2DM, and explains how to migrate existing C2DM apps to GCM.

Historical Overview

C2DM was launched in 2010 to help Android apps send data from servers to their applications. Servers can tell apps to contact the server directly, to fetch updated application or user data. The C2DM service handles all aspects of queueing of messages and delivery to the target application running on the target device.

GCM replaces C2DM. The focus of GCM is as follows:

• Ease of use. No sign-up forms.
• No quotas.
• GCM and C2DM stats are available through the Developer Console.
• Battery efficiency.
• Rich set of new APIs.

How is GCM Different from C2DM?

GCM builds on the core foundation of C2DM. Here is what's different:

Simple API Key

To use the GCM service, you need to obtain a Simple API Key from Google APIs console page. For more information, see Getting Started. Note that GCM only accepts Simple API Key—using ClientLogin or OAuth2 tokens will not work.

Sender ID

In C2DM, the Sender ID is an email address. In GCM, the Sender ID is a project number that you acquire from the API console, as described in Getting Started.

JSON format

GCM HTTP requests support JSON format in addition to plain text. For more information, see the Architectural Overview.

Multicast messages

In GCM you can send the same message to multiple devices simultaneously. For example, a sports app wanting to deliver a score update to fans can now send the message to up to 1000 registration IDs in the same request (requires JSON). For more information, see the Architectural Overview.

Multiple senders

Multiple parties can send messages to the same app with one common registration ID. For more information, see Advanced Topics.

Time-to-live messages

Apps like video chat and calendar apps can send expiring invitation events with a time-to-live value between 0 and 4 weeks. GCM will store the messages until they expire. A message with a time-to-live value of 0 will not be stored on the GCM server, nor will it be throttled. For more information, see Advanced Topics.

Messages with payload

Apps can use "messages with payload" to deliver messages of up to 4 Kb. This would be useful in a chat application, for example. To use this feature, simply omit the collapse_key parameter and messages will not be collapsed. GCM will store up to 100 messages. If you exceed that number, all messages will be discarded but you will receive a special message. If an application receives this message, it needs to sync with the server. For more information, see Advanced Topics.

Canonical registration ID

There may be situations where the server ends up with 2 registration IDs for the same device. If the GCM response contains a registration ID, simply replace the registration ID you have with the one provided. With this feature your application doesn't need to send the device ID to your server anymore. For more information, see Advanced Topics.

GCM also provides client and server helper libraries to make writing your code easier.

Relationship between C2DM and GCM

C2DM and GCM are not interoperable. For example, you cannot post notifications from GCM to C2DM registration IDs, nor can you use C2DM registration IDs as GCM registration IDs. From your server-side application, you must keep track of whether a registration ID is from C2DM or GCM and use the proper endpoint.

As you transition from C2DM to GCM, your server needs to be aware of whether a given registration ID contains an old C2DM sender or a new GCM project number. This is the approach we recommend: have the new app version (the one that uses GCM) send a bit along with the registration ID. This bit tells your server that this registration ID is for GCM. If you don't get the extra bit, you mark the registration ID as C2DM. Once no more valid registration IDs are marked as C2DM, you can complete the migration.

Migrating Your Apps

This section describes how to move existing C2DM apps to GCM.

Client changes

Migration is simple! Just re-register the client app for your target GCM-enabled platform. For example, see Register for GCM

After receiving a response from GCM, the registration ID obtained must be sent to the application server. When doing this, the application should indicate that it is sending a GCM registration ID so that the server can distinguish it from existing C2DM registrations.

Server changes

When the application server receives a GCM registration ID, it should store it and mark it as such.

Sending messages to GCM devices requires a few changes:

• The request should be sent to a new endpoint: https://android.googleapis.com/gcm/send.
• The Authorization header of the request should contain the API key generated during sign up. This key replaces the deprecated ClientLogin Auth token.

For example:

Content-Type:application/json
Authorization:key=AIzaSyB-1uEai2WiUapxCs2Q0GZYzPu7Udno5aA

{
  "registration_id" : "APA91bHun4MxP5egoKMwt2KZFBaFUH-1RYqx...",
  "data" : {
    "Team" : "Portugal",
    "Score" : "3",
    "Player" : "Varela",
  },
}

For a detailed discussion of this topic and more examples, see the Architectural Overview.

Eventually, once enough users of your application have migrated to the new service, you might want to take advantage of the new JSON-formatted requests that give access to the full set of features provided by GCM.