page.title=Migration @jd:body

Quickview

Understand the differences between GCM and C2DM.
Learn how to migrate an app from C2DM to GCM.

In this document

Historical Overview
How is GCM Different from C2DM?
Migrating Your Apps
1. Client changes
2. Server changes

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 Android 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 ID 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 helper libraries (client and server) to make writing your code easier.

Migrating Your Apps

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

Client changes

Migration is simple! The only change required in the application is replacing the email account passed in the sender parameter of the registration intent with the project ID generated when signing up for the new service. For example:

Intent registrationIntent = new Intent("com.google.android.c2dm.intent.REGISTER");
// sets the app name in the intent
registrationIntent.putExtra("app", PendingIntent.getBroadcast(this, 0, new Intent(), 0));
registrationIntent.putExtra("sender", senderID);
startService(registrationIntent);

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.