From b478b10f34a9fa9c6b42f54047eb9e77111a16c7 Mon Sep 17 00:00:00 2001 From: Scott Main Date: Mon, 12 Aug 2013 09:57:24 -0700 Subject: Revert "Doc change: collapse key fix." To resolve conflict. I'll fix it all later. This reverts commit 53d9628d080aa7339b724a994607022c5386a566. --- docs/html/google/gcm/adv.jd | 367 +++++----------- docs/html/google/gcm/ccs.jd | 769 ++++------------------------------ docs/html/google/gcm/client.jd | 649 +--------------------------- docs/html/google/gcm/gcm.jd | 705 ++++++++++++++++++++++++++----- docs/html/google/gcm/gs.jd | 497 ++++++++++++++++++++-- docs/html/google/gcm/http.jd | 618 --------------------------- docs/html/google/gcm/notifications.jd | 137 ++---- docs/html/google/gcm/server.jd | 448 +++++--------------- docs/html/google/google_toc.cs | 23 +- docs/html/images/gcm/CCS-ack.png | Bin 55599 -> 0 bytes docs/html/images/gcm/GCM-arch.png | Bin 26618 -> 0 bytes 11 files changed, 1429 insertions(+), 2784 deletions(-) delete mode 100644 docs/html/google/gcm/http.jd delete mode 100644 docs/html/images/gcm/CCS-ack.png delete mode 100644 docs/html/images/gcm/GCM-arch.png diff --git a/docs/html/google/gcm/adv.jd b/docs/html/google/gcm/adv.jd index 567b12cbb60c..136062408e9f 100644 --- a/docs/html/google/gcm/adv.jd +++ b/docs/html/google/gcm/adv.jd @@ -22,12 +22,7 @@ page.title=GCM Advanced Topics
  • Automatic Retry Using Exponential Back-Off
    • -
  • Unregistration -
      -
    1. Why you should rarely unregister
      2. -
    2. How unregistration works
      3. -
    -
    • +
  • How Unregistration Works
  • Send-to-Sync vs. Messages with Payload
    1. Send-to-sync messages
      2. @@ -36,8 +31,7 @@ page.title=GCM Advanced Topics
  • Setting an Expiration Date for a Message
    • -
  • Receiving Messages from -Multiple Senders
    • +
  • Receiving Messages from Multiple Senders
    • @@ -48,56 +42,17 @@ Multiple Senders

    Lifetime of a Message

    -

    When a 3rd-party server posts a message to GCM and receives a message ID back, -it does not mean that the message was already delivered to the device. Rather, it -means that it was accepted for delivery. What happens to the message after it is -accepted depends on many factors.

    +

    When a 3rd-party server posts a message to GCM and receives a message ID back, it does not mean that the message was already delivered to the device. Rather, it means that it was accepted for delivery. What happens to the message after it is accepted depends on many factors.

    +

    In the best-case scenario, if the device is connected to GCM, the screen is on, and there are no throttling restrictions (see Throttling), the message will be delivered right away.

    +

    If the device is connected but idle, the message will still be +delivered right away unless the delay_while_idle flag is set to true. Otherwise, it will be stored in the GCM servers until the device is awake. And that's where the collapse_key flag plays a role: if there is already a message with the same collapse key (and registration ID) stored and waiting for delivery, the old message will be discarded and the new message will take its place (that is, the old message will be collapsed by the new one). However, if the collapse key is not set, both the new and old messages are stored for future delivery.

    -

    In the best-case scenario, if the device is connected to GCM, the screen is on, -and there are no throttling restrictions (see Throttling), -the message will be delivered right away.

    +

    Note: There is a limit on how many messages can be stored without collapsing. That limit is currently 100. If the limit is reached, all stored messages are discarded. Then when the device is back online, it receives a special message indicating that the limit was reached. The application can then handle the situation properly, typically by requesting a full sync.

    -

    If the device is connected but idle, the message will still be -delivered right away unless the delay_while_idle flag is set to true. -Otherwise, it will be stored in the GCM servers until the device is awake. And -that's where the collapse_key flag plays a role: if there is already -a message with the same collapse key (and registration ID) stored and waiting for -delivery, the old message will be discarded and the new message will take its place -(that is, the old message will be collapsed by the new one). However, if the collapse -key is not set, both the new and old messages are stored for future delivery. -Collapsible messages are also called send-to-sync messages.

    - -

    Note: There is a limit on how many messages can -be stored without collapsing. That limit is currently 100. If the limit is reached, -all stored messages are discarded. Then when the device is back online, it receives -a special message indicating that the limit was reached. The application can then -handle the situation properly, typically by requesting a full sync. -

    -Likewise, there is a limit on how many collapse_keys you can have for -a particular device. GCM allows a maximum of 4 different collapse keys to be used -by the GCM server per device -any given time. In other words, the GCM server can simultaneously store 4 different -send-to-sync messages, each with a different collapse key. If you exceed this number -GCM will only keep 4 collapse keys, with no guarantees about which ones they will be. -See Send-to-sync messages for more information. -

    - -

    If the device is not connected to GCM, the message will be stored until a -connection is established (again respecting the collapse key rules). When a connection -is established, GCM will deliver all pending messages to the device, regardless of -the delay_while_idle flag. If the device never gets connected again -(for instance, if it was factory reset), the message will eventually time out and -be discarded from GCM storage. The default timeout is 4 weeks, unless the -time_to_live flag is set.

    - -

    Finally, when GCM attempts to deliver a message to the device and the -application was uninstalled, GCM will discard that message right away and -invalidate the registration ID. Future attempts to send a message to that device -will get a NotRegistered error. See -How Unregistration Works for more information.

    -

    Although is not possible to track the status of each individual message, the -Google APIs Console stats are broken down by messages sent to device, messages -collapsed, and messages waiting for delivery.

    +

    If the device is not connected to GCM, the message will be stored until a connection is established (again respecting the collapse key rules). When a connection is established, GCM will deliver all pending messages to the device, regardless of the delay_while_idle flag. If the device never gets connected again (for instance, if it was factory reset), the message will eventually time out and be discarded from GCM storage. The default timeout is 4 weeks, unless the time_to_live flag is set.

    + +

    Finally, when GCM attempts to deliver a message to the device and the application was uninstalled, GCM will discard that message right away and invalidate the registration ID. Future attempts to send a message to that device will get a NotRegistered error. See How Unregistration Works for more information.

    +

    Although is not possible to track the status of each individual message, the Google APIs Console stats are broken down by messages sent to device, messages collapsed, and messages waiting for delivery.

    Throttling

    To prevent abuse (such as sending a flood of messages to a device) and @@ -119,112 +74,107 @@ belonging to a non-throttled category by GCM for network and battery efficiency reasons.

    Keeping the Registration State in Sync

    -

    Whenever the application registers as described in -Implementing GCM Client, -it should save the registration ID for future use, pass it to the -3rd-party server to complete the registration, and keep track of -whether the server completed the registration. If the server fails -to complete the registration, it should try again or unregister from GCM.

    - +

    Whenever the application receives a com.google.android.c2dm.intent.REGISTRATION intent with a registration_id extra, it should save the ID for future use, pass it to the 3rd-party server to complete the registration, and keep track of whether the server completed the registration. If the server fails to complete the registration, it should try again or unregister from GCM.

    There are also two other scenarios that require special care:

    -

    When an application is updated, it should invalidate its existing registration -ID, as it is not guaranteed to work with the new version. Because there is no -lifecycle method called when the application is updated, the best way to achieve -this validation is by storing the current application version when a registration -ID is stored. Then when the application is started, compare the stored value with -the current application version. If they do not match, invalidate the stored data -and start the registration process again.

    - -

    Similarly, you should not save the registration ID when an application is -backed up. This is because the registration ID could become invalid by the time -the application is restored, which would put the application in an invalid state -(that is, the application thinks it is registered, but the server and GCM do not -store that registration ID anymore—thus the application will not get more -messages).

    +

    When an application is updated, it should invalidate its existing registration ID, as it is not guaranteed to work with the new version. Because there is no lifecycle method called when the application is updated, the best way to achieve this validation is by storing the current application version when a registration ID is stored. Then when the application is started, compare the stored value with the current application version. If they do not match, invalidate the stored data and start the registration process again.

    + +

    Similarly, you should not save the registration ID when an application is backed up. This is because the registration ID could become invalid by the time the application is restored, which would put the application in an invalid state (that is, the application thinks it is registered, but the server and GCM do not store that registration ID anymore—thus the application will not get more messages).

    Canonical IDs

    -

    On the server side, as long as the application is behaving well, everything -should work normally. However, if a bug in the application triggers multiple -registrations for the same device, it can be hard to reconcile state and you might -end up with duplicate messages.

    -

    GCM provides a facility called "canonical registration IDs" to easily -recover from these situations. A canonical registration ID is defined to be the ID -of the last registration requested by your application. This is the ID that the -server should use when sending messages to the device.

    -

    If later on you try to send a message using a different registration ID, GCM -will process the request as usual, but it will include the canonical registration -ID in the registration_id field of the response. Make sure to replace -the registration ID stored in your server with this canonical ID, as eventually -the ID you're using will stop working.

    +

    On the server side, as long as the application is behaving well, everything should work normally. However, if a bug in the application triggers multiple registrations for the same device, it can be hard to reconcile state and you might end up with duplicate messages.

    +

    GCM provides a facility called "canonical registration IDs" to easily recover from these situations. A canonical registration ID is defined to be the ID of the last registration requested by your application. This is the ID that the server should use when sending messages to the device.

    +

    If later on you try to send a message using a different registration ID, GCM will process the request as usual, but it will include the canonical registration ID in the registration_id field of the response. Make sure to replace the registration ID stored in your server with this canonical ID, as eventually the ID you're using will stop working.

    Automatic Retry Using Exponential Back-Off

    -

    When registration or unregistration fails, the app should retry the failed operation.

    -

    In the simplest case, if your application attempts to register and GCM is not a -fundamental part of the application, the application could simply ignore the error -and try to register again the next time it starts. Otherwise, it should retry the -previous operation using exponential back-off. In exponential back-off, each time -there is a failure, it should wait twice the previous amount of time before trying -again. If the register (or unregister) operation was synchronous, it could be retried -in a simple loop. However, since it is asynchronous, the best approach is to schedule -a {@link android.app.PendingIntent} to retry the operation. - -

    Unregistration

    - -

    This section explains when you should unregister in GCM and what happens -when you do.

    - -

    Why you should rarely unregister

    - -

    A registration ID (regID) represents a particular Android application running -on a particular device. You should only need to unregister in rare cases, such as -if you want an app to stop receiving messages, or if you suspect that the regID has -been compromised. In general, though, once an app has a regID, you shouldn't need -to change it.

    - -

    In particular, you should never unregister your app as a mechanism for -logout or for switching between users, for the following reasons:

    +

    When the application receives a com.google.android.c2dm.intent.REGISTRATION intent with the error extra set as SERVICE_NOT_AVAILABLE, it should retry the failed operation (register or unregister).

    +

    In the simplest case, if your application just calls register and GCM is not a fundamental part of the application, the application could simply ignore the error and try to register again the next time it starts. Otherwise, it should retry the previous operation using exponential back-off. In exponential back-off, each time there is a failure, it should wait twice the previous amount of time before trying again. If the register (or unregister) operation was synchronous, it could be retried in a simple loop. However, since it is asynchronous, the best approach is to schedule a pending intent to retry the operation. The following steps describe how to implement this in the MyIntentService example used above:

    +
      +
    1. Create a random token to verify the origin of the retry intent: -
        -
      • A regID maps an app to a device. It isn't associated with a particular - logged in user. If you unregister and then re-register, GCM may return the same - ID or a different ID—there's no guarantee either way.
        • - -
      • Unregistration may take up to 5 minutes to propagate.
        • -
      • After unregistration, re-registration may again take up to 5 minutes to -propagate. During this time messages may be rejected due to the state of being -unregistered, and after all this, messages may still go to the wrong user.
        • -
      +
      private static final String TOKEN =
+        Long.toBinaryString(new Random().nextLong());
+
      +
    2. Change the handleRegistration() method so it creates the pending intent when appropriate:
      3. + +
      ...
+if (error != null) {
+ if ("SERVICE_NOT_AVAILABLE".equals(error)) {
+   long backoffTimeMs = // get back-off time from shared preferences
+   long nextAttempt = SystemClock.elapsedRealtime() + backoffTimeMs;
+   Intent retryIntent = new Intent("com.example.gcm.intent.RETRY");
+   retryIntent.putExtra("token", TOKEN);
+   PendingIntent retryPendingIntent =
+       PendingIntent.getBroadcast(context, 0, retryIntent, 0);
+   AlarmManager am = (AlarmManager)   
+       context.getSystemService(Context.ALARM_SERVICE);
+   am.set(AlarmManager.ELAPSED_REALTIME, nextAttempt, retryPendingIntent);
+   backoffTimeMs *= 2; // Next retry should wait longer.
+   // update back-off time on shared preferences
+ } else {
+   // Unrecoverable error, log it
+   Log.i(TAG, "Received error: " + error);
+}
+...
      +

      The back-off time is stored in a shared preference. This ensures that it is persistent across multiple activity launches. The name of the intent does not matter, as long as the same intent is used in the following steps.

      + +
    3. Change the onHandleIntent() method adding an else if case for the retry intent:
      4. + +
      ...
+} else if (action.equals("com.example.gcm.intent.RETRY")) {
+    String token = intent.getStringExtra("token");
+    // make sure intent was generated by this class, not by a malicious app
+    if (TOKEN.equals(token)) {
+        String registrationId = // get from shared properties
+        if (registrationId != null) {
+        // last operation was attempt to unregister; send UNREGISTER intent again
+    } else {
+        // last operation was attempt to register; send REGISTER intent again
+    }
+}
+...
      + +
    4. Create a new instance of MyReceiver in your activity:
      5. + +
      private final MyBroadcastReceiver mRetryReceiver = new MyBroadcastReceiver();
+
      -

      The solution is to manage your own mapping between users, the regID, and -individual messages:

      +
    5. In the activity's onCreate() method, register the new instance to receive the com.example.gcm.intent.RETRY intent: + 
      ...
+IntentFilter filter = new IntentFilter("com.example.gcm.intent.RETRY");
+filter.addCategory(getPackageName());
+registerReceiver(mRetryReceiver, filter);
+...
      -
        -
      • Your app server should maintain a mapping between the current user -and the regID. This should include information about which user is supposed to -receive a particular message.
        • -
      • The app running on the device should check to ensure that messages it -receives match the logged in user.
        • -
      +

      Note: You must dynamically create a new instance of the broadcast receiver since the one defined by the manifest can only receive intents with the com.google.android.c2dm.permission.SEND permission. The permission com.google.android.c2dm.permission.SEND is a system permission and as such it cannot be granted to a regular application.

      +
      6. -

      How unregistration works

      +
    6. In the activity's onDestroy() method, unregister the broadcast receiver:
      7. -

      An application can be automatically unregistered after it is uninstalled from -the device. However, this process does not happens right away, as Android does not -provide an uninstall callback. What happens in this scenario is as follows:

      +
      unregisterReceiver(mRetryReceiver);
      +
    +

    How Unregistration Works

    +

    There are two ways to unregister a device from GCM: manually and automatically.

    +

    An Android application can manually unregister itself by issuing a com.google.android.c2dm.intent.UNREGISTER intent, which is useful when the application offers a logoff feature (so it can unregister on logoff and register again on logon). See the Architectural Overview for more discussion of this topic. This is the sequence of events when an application unregisters itself:

    +
      +
    1. The application issues a com.google.android.c2dm.intent.UNREGISTER intent, passing the package name as an extra.
      2. +
    2. When the GCM server is done with the unregistration, it sends a com.google.android.c2dm.intent.REGISTRATION intent with the unregistered extra set.
      3. +
    3. The application then must contact the 3rd-party server so it can remove the registration ID.
      4. +
    4. The application should also clear its registration ID. +
      5. +
    +

    An application can be automatically unregistered after it is uninstalled from the device. However, this process does not happens right away, as Android does not provide an uninstall callback. What happens in this scenario is as follows:

    1. The end user uninstalls the application.
    2. The 3rd-party server sends a message to GCM server.
    3. The GCM server sends the message to the device.
      4. -
    4. The GCM client receives the message and queries Package Manager about -whether there are broadcast receivers configured to receive it, which returns -false. +
    5. The GCM client receives the message and queries Package Manager about whether there are broadcast receivers configured to receive it, which returns false.
    6. The GCM client informs the GCM server that the application was uninstalled.
    7. The GCM server marks the registration ID for deletion.
      8. @@ -234,16 +184,9 @@ whether there are broadcast receivers configured to receive it, which returns
    -

    Note: The GCM client is the Google Cloud -Messaging framework present on the device.

    +

    Note: The GCM client is the Google Cloud Messaging framework present on the device.

    -

    Note that it might take a while for the registration ID be completely removed -from GCM. Thus it is possible that messages sent during step 7 above gets a valid -message ID as response, even though the message will not be delivered to the device. -Eventually, the registration ID will be removed and the server will get a -NotRegistered error, without any further action being required from -the 3rd-party server (this scenario happens frequently while an application is -being developed and tested).

    +

    Note that it might take a while for the registration ID be completely removed from GCM. Thus it is possible that messages sent during step 7 above gets a valid message ID as response, even though the message will not be delivered to the device. Eventually, the registration ID will be removed and the server will get a NotRegistered error, without any further action being required from the 3rd-party server (this scenario happens frequently while an application is being developed and tested).

    Send-to-Sync vs. Messages with Payload

    @@ -253,45 +196,17 @@ being developed and tested).

  • By default, it is stored by GCM for 4 weeks.
    • -

    But despite these similarities, messages can behave very differently depending -on their particular settings. One major distinction between messages is whether -they are collapsed (where each new message replaces the preceding message) or not -collapsed (where each individual message is delivered). Every message sent in GCM -is either a "send-to-sync" (collapsible) message or a "message with -payload" (non-collapsible message). These concepts are described in more -detail in the following sections.

    +

    But despite these similarities, messages can behave very differently depending on their particular settings. One major distinction between messages is whether they are collapsed (where each new message replaces the preceding message) or not collapsed (where each individual message is delivered). Every message sent in GCM is either a "send-to-sync" (collapsible) message or a "message with payload" (non-collapsible message). These concepts are described in more detail in the following sections.

    Send-to-sync messages

    -

    A send-to-sync (collapsible) message is often a "tickle" that tells -a mobile application to sync data from the server. For example, suppose you have -an email application. When a user receives new email on the server, the server -pings the mobile application with a "New mail" message. This tells the -application to sync to the server to pick up the new email. The server might send -this message multiple times as new mail continues to accumulate, before the application -has had a chance to sync. But if the user has received 25 new emails, there's no -need to preserve every "New mail" message. One is sufficient. Another -example would be a sports application that updates users with the latest score. -Only the most recent message is relevant, so it makes sense to have each new -message replace the preceding message.

    - -

    The email and sports applications are cases where you would probably use the -GCM collapse_key parameter. A collapse key is an arbitrary -string that is used to collapse a group of like messages when the device is offline, -so that only the most recent message gets sent to the client. For example, -"New mail," "Updates available," and so on

    -

    GCM allows a maximum of 4 different collapse keys to be used by the GCM server -at any given time. In other words, the GCM server can simultaneously store 4 -different send-to-sync messages per device, each with a different collapse key. -For example, Device A can have A1, A2, A3, and A4. Device B can have B1, B2, B3, -and B4, and so on. If you exceed this number GCM will only keep 4 collapse keys, with no -guarantees about which ones they will be.

    +

    A send-to-sync (collapsible) message is often a "tickle" that tells a mobile application to sync data from the server. For example, suppose you have an email application. When a user receives new email on the server, the server pings the mobile application with a "New mail" message. This tells the application to sync to the server to pick up the new email. The server might send this message multiple times as new mail continues to accumulate, before the application has had a chance to sync. But if the user has received 25 new emails, there's no need to preserve every "New mail" message. One is sufficient. Another example would be a sports application that updates users with the latest score. Only the most recent message is relevant, so it makes sense to have each new message replace the preceding message.

    + +

    The email and sports applications are cases where you would probably use the GCM collapse_key parameter. A collapse key is an arbitrary string that is used to collapse a group of like messages when the device is offline, so that only the most recent message gets sent to the client. For example, "New mail," "Updates available," and so on

    +

    GCM allows a maximum of 4 different collapse keys to be used by the GCM server at any given time. In other words, the GCM server can simultaneously store 4 different send-to-sync messages, each with a different collapse key. If you exceed this number GCM will only keep 4 collapse keys, with no guarantees about which ones they will be.

    Messages with payload

    -

    Unlike a send-to-sync message, every "message with payload" -(non-collapsible message) is delivered. The payload the message contains can be -up to 4kb. For example, here is a JSON-formatted message in an IM application in -which spectators are discussing a sporting event:

    +

    Unlike a send-to-sync message, every "message with payload" (non-collapsible message) is delivered. The payload the message contains can be up to 4kb. For example, here is a JSON-formatted message in an IM application in which spectators are discussing a sporting event:

    {
   "registration_id" : "APA91bHun4MxP5egoKMwt2KZFBaFUH-1RYqx...",
@@ -302,42 +217,19 @@ which spectators are discussing a sporting event:
    
   },
 }
    -

    A "message with payload" is not simply a "ping" to the -mobile application to contact the server to fetch data. In the aforementioned IM -application, for example, you would want to deliver every message, because every -message has different content. To specify a non-collapsible message, you simply -omit the collapse_key parameter. Thus GCM will send each message -individually. Note that the order of delivery is not guaranteed.

    - -

    GCM will store up to 100 non-collapsible messages. After that, all messages -are discarded from GCM, and a new message is created that tells the client how -far behind it is. The message is delivered through a regular -com.google.android.c2dm.intent.RECEIVE intent, with the following -extras:

    +

    A "message with payload" is not simply a "ping" to the mobile application to contact the server to fetch data. In the aforementioned IM application, for example, you would want to deliver every message, because every message has different content. To specify a non-collapsible message, you simply omit the collapse_key parameter. Thus GCM will send each message individually. Note that the order of delivery is not guaranteed.

    +

    GCM will store up to 100 non-collapsible messages. After that, all messages are discarded from GCM, and a new message is created that tells the client how far behind it is. The message is delivered through a regular com.google.android.c2dm.intent.RECEIVE intent, with the following extras:

    -

    The application should respond by syncing with the server to recover the -discarded messages.

    +

    The application should respond by syncing with the server to recover the discarded messages.

    Which should I use?

    -

    If your application does not need to use non-collapsible messages, collapsible -messages are a better choice from a performance standpoint, because they put less -of a burden on the device battery. However, if you use collapsible messages, remember that -GCM only allows a maximum of 4 different collapse keys to be used by the GCM server -per device at any given time. You must not exceed this number, or it could cause -unpredictable consequences.

    +

    If your application does not need to use non-collapsible messages, collapsible messages are a better choice from a performance standpoint, because they put less of a burden on the device battery.

    Setting an Expiration Date for a Message

    -

    The Time to Live (TTL) feature lets the sender specify the maximum lifespan -of a message using the time_to_live parameter in the send request. -The value of this parameter must be a duration from 0 to 2,419,200 seconds, and -it corresponds to the maximum period of time for which GCM will store and try to -deliver the message. Requests that don't contain this field default to the maximum -period of 4 weeks.

    +

    The Time to Live (TTL) feature lets the sender specify the maximum lifespan of a message using the time_to_live parameter in the send request. The value of this parameter must be a duration from 0 to 2,419,200 seconds, and it corresponds to the maximum period of time for which GCM will store and try to deliver the message. Requests that don't contain this field default to the maximum period of 4 weeks.

    Here are some possible uses for this feature:

    Background

    -

    GCM will usually deliver messages immediately after they are sent. However, -this might not always be possible. For example, the device could be turned off, -offline, or otherwise unavailable. In other cases, the sender itself might request -that messages not be delivered until the device becomes active by using the -delay_while_idle flag. Finally, GCM might intentionally delay messages -to prevent an application from consuming excessive resources and negatively -impacting battery life.

    - -

    When this happens, GCM will store the message and deliver it as soon as it's -feasible. While this is fine in most cases, there are some applications for which -a late message might as well never be delivered. For example, if the message is -an incoming call or video chat notification, it will only be meaningful for a -small period of time before the call is terminated. Or if the message is an -invitation to an event, it will be useless if received after the event has ended.

    - -

    Another advantage of specifying the expiration date for a message is that GCM -will never throttle messages with a time_to_live value of 0 seconds. -In other words, GCM will guarantee best effort for messages that must be delivered -"now or never." Keep in mind that a time_to_live value of -0 means messages that can't be delivered immediately will be discarded. However, -because such messages are never stored, this provides the best latency for -sending notifications.

    - +

    GCM will usually deliver messages immediately after they are sent. However, this might not always be possible. For example, the device could be turned off, offline, or otherwise unavailable. In other cases, the sender itself might request that messages not be delivered until the device becomes active by using the delay_while_idle flag. Finally, GCM might intentionally delay messages to prevent an application from consuming excessive resources and negatively impacting battery life.

    +

    When this happens, GCM will store the message and deliver it as soon as it's feasible. While this is fine in most cases, there are some applications for which a late message might as well never be delivered. For example, if the message is an incoming call or video chat notification, it will only be meaningful for a small period of time before the call is terminated. Or if the message is an invitation to an event, it will be useless if received after the event has ended.

    +

    Another advantage of specifying the expiration date for a message is that GCM will never throttle messages with a time_to_live value of 0 seconds. In other words, GCM will guarantee best effort for messages that must be delivered "now or never." Keep in mind that a time_to_live value of 0 means messages that can't be delivered immediately will be discarded. However, because such messages are never stored, this provides the best latency for sending notifications.

    Here is an example of a JSON-formatted request that includes TTL:

     {
@@ -384,23 +256,9 @@ sending notifications.
    
 
 
 
    Receiving Messages from Multiple Senders
    
-
-
    GCM allows multiple parties to send messages to the same application. For
-example, suppose your application is an articles aggregator with multiple
-contributors, and you want each of them to be able to send a message when they
-publish a new article. This message might contain a URL so that the application
-can download the article. Instead of having to centralize all sending activity in
-one location, GCM gives you the ability to let each of these contributors send
-its own messages.
    
-
-
    To make this possible, all you need to do is have each sender generate its own
-project number. Then include those IDs in the sender field, separated by commas,
-when requesting a registration. Finally, share the registration ID with your
-partners, and they'll be able to send messages to your application using their
-own authentication keys.
    
-
    This code snippet illustrates this feature. Senders are passed as an intent
-extra in a comma-separated list:
    
-
+
    GCM allows multiple parties to send messages to the same application. For example, suppose your application is an articles aggregator with multiple contributors, and you want each of them to be able to send a message when they publish a new article. This message might contain a URL so that the application can download the article. Instead of having to centralize all sending activity in one location, GCM gives you the ability to let each of these contributors send its own messages.
    
+
    To make this possible, all you need to do is have each sender generate its own project number. Then include those IDs in the sender field, separated by commas, when requesting a registration. Finally, share the registration ID with your partners, and they'll be able to send messages to your application using their own authentication keys.
    
+
    This code snippet illustrates this feature. Senders are passed as an intent extra in a comma-separated list:
    
 
    Intent intent = new Intent(GCMConstants.INTENT_TO_GCM_REGISTRATION);
 intent.setPackage(GSF_PACKAGE);
 intent.putExtra(GCMConstants.EXTRA_APPLICATION_PENDING_INTENT,
@@ -411,3 +269,4 @@ ontext.startService(intent);
  
    
 
 
    Note that there is limit of 100 multiple senders.
    
+ 
diff --git a/docs/html/google/gcm/ccs.jd b/docs/html/google/gcm/ccs.jd
index 244278eba72d..0cadbd245c16 100644
--- a/docs/html/google/gcm/ccs.jd
+++ b/docs/html/google/gcm/ccs.jd
@@ -1,96 +1,93 @@
-page.title=GCM Cloud Connection Server (XMPP)
+page.title=GCM Cloud Connection Server
 @jd:body
 
 
 
-
    Note: To try out this feature, sign up using
-this form.
    
+
    Note: To try out this feature, sign up using this form.
    
 
-
    The GCM Cloud Connection Server (CCS) is a connection server based on XMPP.
-CCS allows 3rd-party app servers (which you're
-responsible for implementing) to communicate
-with Android devices by  establishing a persistent TCP connection with Google
-servers using the XMPP protocol. This communication is asynchronous and bidirectional.
    
-
    You can continue to use the HTTP request mechanism to send messages to GCM
-servers, side-by-side with CCS which uses XMPP. Some of the benefits of CCS include:
    
+
    The GCM Cloud Connection Server (CCS) allows third party servers to communicate with Android devices by  establishing a persistent TCP connection with Google servers using the XMPP protocol. This communication is asynchronous and bidirectional.
    
+
    You can continue to use the HTTP request mechanism to send messages to GCM servers, side-by-side with CCS which uses XMPP. Some of the benefits of CCS include:
    
 
 
-
    The upstream messaging (device-to-cloud) feature of CCS is part of the Google
-Play services platform. Upstream messaging is available through the
-
-{@code GoogleCloudMessaging}
-APIs. For examples, see
-Implementing an XMPP-based App Server.
    
+
    The upstream messaging (device-to-cloud) feature of CCS is part of the Google Play services platform. Upstream messaging is available through the {@code GoogleCloudMessaging} APIs. To use upstream messaging and the new streamlined registration process, you must set up the Google Play services SDK.
    
 
-
    Note: See
-Implementing GCM Server for a list of all the message
-parameters and which connection server(s) supports them.
    
+
    Note: For an example of an XMPP server, see GCM Server.
+
+
    CCS vs. GCM HTTP
    
+
+
    CCS messaging differs from GCM HTTP messaging in the following ways:
    
+
+
    This document describes how to use CCS. For general concepts and information on how to use GCM HTTP, see the GCM Architectural Overview.
    
 
 
    How to Use CCS
    
 
-
    GCM Cloud Connection Server (CCS) is an XMPP endpoint, running on
-{@code http://gcm.googleapis.com} port 5235.
    
+
    GCM Cloud Connection Server (CCS) is an XMPP endpoint, running on {@code http://gcm.googleapis.com} port 5235.
    
 
-
    CCS requires a Transport Layer Security (TLS) connection. That means the  XMPP
-client must initiate a TLS connection.
-For example in Java, you would call {@code setSocketFactory(SSLSocketFactory)}.
    
+
    CCS requires a Transport Layer Security (TLS) connection. That means the  XMPP client must initiate a TLS connection.
+For example in smack, you would call {@code setSocketFactory(SSLSocketFactory)}, similar to “old style SSL” XMPP connections and https.
    
 
-
    CCS requires a SASL PLAIN authentication mechanism using
-{@code <your_GCM_Sender_Id>@gcm.googleapis.com} (GCM sender ID) and the
-API key as the password, where the sender ID and API key are the same as described
-in Getting Started.
    
+
    CCS requires a SASL PLAIN authentication mechanism using {@code <your_GCM_Sender_Id>@gcm.googleapis.com} (GCM sender ID) and the API key as the password, where the sender ID and API key are the same as described in Getting Started.
    
 
 
     You can use most XMPP libraries to interact with CCS.
    
 
-
    Authentication
    
+
    Sending messages
    
 
 
    The following snippets illustrate how to perform authentication in CCS.
    
 
    Client
    
@@ -111,13 +108,13 @@ in Getting Started.
    
 
    Client
    
 
    <auth mechanism="PLAIN"
 xmlns="urn:ietf:params:xml:ns:xmpp-sasl">MTI2MjAwMzQ3OTMzQHByb2plY3RzLmdjbS5hb
+mRyb2lkLmNvbQAxMjYyMDAzNDc5FzNAcHJvamVjdHMtZ2EtLmFuZHJvaWQuY29tAEFJe
 mFTeUIzcmNaTmtmbnFLZEZiOW1oekNCaVlwT1JEQTJKV1d0dw==</auth>
 
    
-
 
    Server
    
 
    <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl"/>
    
 
-
    Message Format
    
+
    Message Format
    
 
    CCS uses normal XMPP <message> stanzas. The body of the message must be:
 
    
 
    @@ -126,42 +123,25 @@ mFTeUIzcmNaTmtmbnFLZEZiOW1oekNCaVlwT1JEQTJKV1d0dw==</auth>
 </gcm>
 
    
 
-
    The JSON payload for server-to-device is similar to what the GCM http endpoint
-uses, with these exceptions:
    
+
    The JSON payload for server-to-device is similar to what the GCM http endpoint uses, with these exceptions:
    
 
-
    For each device message your app server receives from CCS, it needs to send
-an ACK message.
-It never needs to send a NACK message. If you don't send an ACK for a message,
-CCS will just resend it.
+
    For each message a device sends to the server, you need to send an ACK message. You never need to send a NACK message. If you don't send an ACK for a message, CCS will just resend it.
 
    
-
    CCS also sends an ACK or NACK for each server-to-device message. If you do not
-receive either, it means that the TCP connection was closed in the middle of the
-operation and your server needs to resend the messages. See
-Flow Control for details.
+
    CCS also sends an ACK or NACK for each server-to-device message. If you do not receive either, it means that the TCP connection was closed in the middle of the operation and your server needs to resend the messages.
 
    
 
-
    Note: See
-Implementing GCM Server for a list of all the message
-parameters and which connection server(s) supports them.
    
+
    Message Examples
    
 
-
    Request format
    
-
-
    Here is an XMPP stanza containing the JSON message from a 3rd-party app server to CCS:
+
    Here is an XMPP stanza containing the JSON message from a 3rd-party server to CCS:
 
 
    
 
    <message id="">
@@ -180,15 +160,7 @@ parameters and which connection server(s) supports them.
    
 </message>
 
    
 
-
    Response format
    
-
-
    A CCS response can have 3 possible forms. The first one is a regular 'ack'
-message. But when the response contains an error, there are 2
-different forms the message can take, described below.
    
-
-
    ACK message
    
-
-
    Here is an XMPP stanza containing the ACK/NACK message from CCS to 3rd-party app server:
+
    Here is an XMPP stanza containing the ACK/NACK message from CCS to 3rd-party server:
 
    
 
    <message id="">
   <gcm xmlns="google:mobile:data">
@@ -199,138 +171,24 @@ different forms the message can take, described below.
    
   }
   </gcm>
 </message>
-
    
-
-
    NACK message
    
-
-
    A NACK error is a regular XMPP message in which the {@code message_type} status
-message is "nack". A NACK message contains:
    
-
-
-
    Below are some examples.
    
-
-
    Bad registration:
    
-
    <message>
-  <data:gcm xmlns:data="google:mobile:data">
-  {
-    "error":"BAD_REGISTRATION",  // error code
-    "message_id":"msgId1",
-    "from":"PA91bHFOtaQGSwupt5l1og",
-    "message_type":"nack"
-  }
-  </data:gcm>
-</message>
    
-
-
    Invalid "time to live":
    
-
-
    <message>
-  <data:gcm xmlns:data="google:mobile:data">
-  {
-     "error":"InvalidJson : INVALID_TTL : Invalid value (-1) for \"time_to_live\": must be between 0 and \"2419200\"\n",
-     "message_id":"msgId1",
-     "from":"APA91bHFOtaQGSwupt5l1og",
-     "message_type":"nack"
-  }
-  </data:gcm>
-</message>
    
 
-
    JSON type error:
    
-
-
    <message>
-  <data:gcm xmlns:data="google:mobile:data">
+<message id="">
+  <gcm xmlns="google:mobile:data">
   {
-     "error":"InvalidJson : JSON_TYPE_ERROR : Field \"delay_while_idle\" must be a JSON java.lang.Boolean: not-boolean-user-supplied-value\n",
-     "message_id":"msgId1",
-     "from":"APA91bHFOtaQGSwupt5l1og",
-     "message_type":"nack"
+      "from":"REGID",
+      "message_id":"m-1366082849205"
+      "error": ERROR_CODE,
+      "message_type":"nack"
   }
-  </data:gcm>
-</message>
    
-
-
-
    The following table lists some of the more common NACK error codes.
    
-
-
    
-  Table 1. NACK error codes.
    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
    Error CodeDescription
    {@code BAD_REGISTRATION}The device has a registration ID, but it's invalid.
    {@code DEVICE_UNREGISTERED}The device is not registered.
    {@code INTERNAL_SERVER_ERROR}The server encountered an error while trying to process the request.
    {@code SERVICE_UNAVAILABLE}The CCS connection server is temporarily unavailable, try again later
-(using exponential backoff, etc.).
    {@code BAD_ACK}The ACK message is improperly formed.
    {@code AUTHENTICATION_FAILED}This is a 401 error indicating that there was an error authenticating the sender account.
    {@code INVALID_TTL}There was an error in the supplied "time to live" value.
    {@code JSON_TYPE_ERROR}There was an error in the supplied JSON data type.
    
-
-
    Stanza error
    
-
-
    You can also get a stanza error in certain cases.
-A stanza error contains:
    
-
-
    For example:
    
-
-
    <message id="3" type="error" to="123456789@gcm.googleapis.com/ABC">
-  <gcm xmlns="google:mobile:data">
-     {"random": "text"}
   </gcm>
-  <error code="400" type="modify">
-    <bad-request xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
-    <text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas">
-      InvalidJson: JSON_PARSING_ERROR : Missing Required Field: message_id\n
-    </text>
-  </error>
 </message>
 
    
 
+
    Upstream Messages
    
 
-
    Upstream Messages
    
+
    Using CCS and the GoogleCloudMessaging API, you can send messages from a user's device to the cloud.
    
 
-
    Using CCS and the
-
-{@code GoogleCloudMessaging}
-API, you can send messages from a user's device to the cloud.
    
-
-
    Here is how you send an upstream message using the
-
-{@code GoogleCloudMessaging}
-API. For a complete example, see Implementing GCM Client:
    
+
    Here is how you send an upstream message using the GoogleCloudMessaging API. For a complete example, see Getting Started:
    
 
 
    GoogleCloudMessaging gcm = GoogleCloudMessaging.get(context);
 String GCM_SENDER_ID = "Your-Sender-ID";
@@ -340,15 +198,12 @@ Bundle data = new Bundle();
 // Bundle data consists of a key-value pair
 data.putString("hello", "world");
 // "time to live" parameter
-// This is optional. It specifies a value in seconds up to 4 weeks.
 int ttl = [0 seconds, 4 weeks]
 
 gcm.send(GCM_SENDER_ID + "@gcm.googleapis.com", id, ttl, data);
 
    
 
-
    This call generates the necessary XMPP stanza for sending the upstream message.
-The message goes from the app on the device to CCS to the 3rd-party app server.
-The stanza has the following format:
    
+
    This call generates the necessary XMPP stanza for sending the upstream message. The message goes from the app on the device to CCS to the 3rd-party server. The stanza has the following format:
    
 
 
    <message id="">
   <gcm xmlns="google:mobile:data">
@@ -364,8 +219,7 @@ The stanza has the following format:
    
   </gcm>
 </message>
    
 
-
    Here is the format of the ACK expected by CCS from 3rd-party app servers in
-response to the above message:
    
+
    Here is the format of the ACK expected by CCS from 3rd-party servers in response to the above message:
    
 
 
    <message id="">
   <gcm xmlns="google:mobile:data">
@@ -377,478 +231,13 @@ response to the above message:
    
   </gcm>
 </message>
    
 
-
    Flow Control
    
 
-
    Every message sent to CCS receives either an ACK or a NACK response. Messages
-that haven't received one of these responses are considered pending. If the pending
-message count reaches 1000, the 3rd-party app server should stop sending new messages
-and wait for CCS to acknowledge some of the existing pending messages as illustrated in
-figure 1:
    
+
    Flow Control
    
 
-
+
    Every message sent to CCS receives either an ACK or a NACK response. Messages that haven't received one of these responses are considered pending. If the pending message count reaches 1000, the 3rd-party server should stop sending new messages and wait for CCS to acknowledge some of the existing pending messages.
    
 
-
    
-  Figure 1. Message/ack flow.
-
    
+
    Conversely, to avoid overloading the 3rd-party server, CCS will stop sending if there are too many unacknowledged messages. Therefore, the 3rd-party server should "ACK" received messages as soon as possible to maintain a constant flow of incoming messages. The aforementioned pending message limit doesn't apply to these ACKs. Even if the pending message count reaches 1000, the 3rd-party server should continue sending ACKs to avoid blocking delivery of new messages.
    
 
-
    Conversely, to avoid overloading the 3rd-party app server, CCS will stop sending
-if there are too many unacknowledged messages. Therefore, the 3rd-party app server
-should "ACK" upstream messages, received from the client application via CCS, as soon as possible
-to maintain a constant flow of incoming messages. The aforementioned pending message limit doesn't
-apply to these ACKs. Even if the pending message count reaches 1000, the 3rd-party app server
-should continue sending ACKs for messages received from CCS to avoid blocking delivery of new
-upstream messages.
    
-
-
    ACKs are only valid within the context of one connection. If the connection is
-closed before a message can be ACKed, the 3rd-party app server should wait for CCS
-to resend the upstream message before ACKing it again. Similarly, all pending messages for which an
-ACK/NACK was not received from CCS before the connection was closed should be sent again.
+
    ACKs are only valid within the context of one connection. If the connection is closed before a message can be ACKed, the 3rd-party server should wait for CCS to resend the message before ACKing it again.
 
    
 
-
    Implementing an XMPP-based App Server
    
-
-
    This section gives examples of implementing an app server that works with CCS.
-Note that a full GCM implementation requires a client-side implementation, in
-addition to the server. For more information, see 
-Implementing GCM Client.
-
-
    Java sample using the Smack library
    
-
-
    Here is a sample app server written in Java, using the
-Smack library.
    
-
-
    import org.jivesoftware.smack.ConnectionConfiguration;
-import org.jivesoftware.smack.ConnectionConfiguration.SecurityMode;
-import org.jivesoftware.smack.ConnectionListener;
-import org.jivesoftware.smack.PacketInterceptor;
-import org.jivesoftware.smack.PacketListener;
-import org.jivesoftware.smack.XMPPConnection;
-import org.jivesoftware.smack.XMPPException;
-import org.jivesoftware.smack.filter.PacketTypeFilter;
-import org.jivesoftware.smack.packet.DefaultPacketExtension;
-import org.jivesoftware.smack.packet.Message;
-import org.jivesoftware.smack.packet.Packet;
-import org.jivesoftware.smack.packet.PacketExtension;
-import org.jivesoftware.smack.provider.PacketExtensionProvider;
-import org.jivesoftware.smack.provider.ProviderManager;
-import org.jivesoftware.smack.util.StringUtils;
-import org.json.simple.JSONValue;
-import org.json.simple.parser.ParseException;
-import org.xmlpull.v1.XmlPullParser;
-
-import java.util.HashMap;
-import java.util.Map;
-import java.util.Random;
-import java.util.logging.Level;
-import java.util.logging.Logger;
-
-import javax.net.ssl.SSLSocketFactory;
-/**
- * Sample Smack implementation of a client for GCM Cloud Connection Server.
- *
- * <p>For illustration purposes only.
- */
-public class SmackCcsClient {
-
-  Logger logger = Logger.getLogger("SmackCcsClient");
-
-  public static final String GCM_SERVER = "gcm.googleapis.com";
-  public static final int GCM_PORT = 5235;
-
-  public static final String GCM_ELEMENT_NAME = "gcm";
-  public static final String GCM_NAMESPACE = "google:mobile:data";
-
-  static Random random = new Random();
-  XMPPConnection connection;
-  ConnectionConfiguration config;
-
-  /**
-   * XMPP Packet Extension for GCM Cloud Connection Server.
-   */
-  class GcmPacketExtension extends DefaultPacketExtension {
-    String json;
-
-    public GcmPacketExtension(String json) {
-      super(GCM_ELEMENT_NAME, GCM_NAMESPACE);
-      this.json = json;
-    }
-
-    public String getJson() {
-      return json;
-    }
-
-    @Override
-    public String toXML() {
-      return String.format("<%s xmlns=\"%s\">%s</%s>", GCM_ELEMENT_NAME,
-          GCM_NAMESPACE, json, GCM_ELEMENT_NAME);
-    }
-
-    @SuppressWarnings("unused")
-    public Packet toPacket() {
-      return new Message() {
-        // Must override toXML() because it includes a <body>
-        @Override
-        public String toXML() {
-
-          StringBuilder buf = new StringBuilder();
-          buf.append("<message");
-          if (getXmlns() != null) {
-            buf.append(" xmlns=\"").append(getXmlns()).append("\"");
-          }
-          if (getLanguage() != null) {
-            buf.append(" xml:lang=\"").append(getLanguage()).append("\"");
-          }
-          if (getPacketID() != null) {
-            buf.append(" id=\"").append(getPacketID()).append("\"");
-          }
-          if (getTo() != null) {
-            buf.append(" to=\"").append(StringUtils.escapeForXML(getTo())).append("\"");
-          }
-          if (getFrom() != null) {
-            buf.append(" from=\"").append(StringUtils.escapeForXML(getFrom())).append("\"");
-          }
-          buf.append(">");
-          buf.append(GcmPacketExtension.this.toXML());
-          buf.append("</message>");
-          return buf.toString();
-        }
-      };
-    }
-  }
-
-  public SmackCcsClient() {
-    // Add GcmPacketExtension
-    ProviderManager.getInstance().addExtensionProvider(GCM_ELEMENT_NAME,
-        GCM_NAMESPACE, new PacketExtensionProvider() {
-
-      @Override
-      public PacketExtension parseExtension(XmlPullParser parser)
-          throws Exception {
-        String json = parser.nextText();
-        GcmPacketExtension packet = new GcmPacketExtension(json);
-        return packet;
-      }
-    });
-  }
-
-  /**
-   * Returns a random message id to uniquely identify a message.
-   *
-   * <p>Note:
-   * This is generated by a pseudo random number generator for illustration purpose,
-   * and is not guaranteed to be unique.
-   *
-   */
-  public String getRandomMessageId() {
-    return "m-" + Long.toString(random.nextLong());
-  }
-
-  /**
-   * Sends a downstream GCM message.
-   */
-  public void send(String jsonRequest) {
-    Packet request = new GcmPacketExtension(jsonRequest).toPacket();
-    connection.sendPacket(request);
-  }
-
-  /**
-   * Handles an upstream data message from a device application.
-   *
-   * <p>This sample echo server sends an echo message back to the device.
-   * Subclasses should override this method to process an upstream message.
-   */
-  public void handleIncomingDataMessage(Map<String, Object> jsonObject) {
-    String from = jsonObject.get("from").toString();
-
-    // PackageName of the application that sent this message.
-    String category = jsonObject.get("category").toString();
-
-    // Use the packageName as the collapseKey in the echo packet
-    String collapseKey = "echo:CollapseKey";
-    @SuppressWarnings("unchecked")
-    Map<String, String> payload = (Map<String, String>) jsonObject.get("data");
-    payload.put("ECHO", "Application: " + category);
-
-    // Send an ECHO response back
-    String echo = createJsonMessage(from, getRandomMessageId(), payload, collapseKey, null, false);
-    send(echo);
-  }
-
-  /**
-   * Handles an ACK.
-   *
-   * <p>By default, it only logs a {@code INFO} message, but subclasses could override it to
-   * properly handle ACKS.
-   */
-  public void handleAckReceipt(Map<String, Object> jsonObject) {
-    String messageId = jsonObject.get("message_id").toString();
-    String from = jsonObject.get("from").toString();
-    logger.log(Level.INFO, "handleAckReceipt() from: " + from + ", messageId: " + messageId);
-  }
-
-  /**
-   * Handles a NACK.
-   *
-   * <p>By default, it only logs a {@code INFO} message, but subclasses could override it to
-   * properly handle NACKS.
-   */
-  public void handleNackReceipt(Map<String, Object> jsonObject) {
-    String messageId = jsonObject.get("message_id").toString();
-    String from = jsonObject.get("from").toString();
-    logger.log(Level.INFO, "handleNackReceipt() from: " + from + ", messageId: " + messageId);
-  }
-
-  /**
-   * Creates a JSON encoded GCM message.
-   *
-   * @param to RegistrationId of the target device (Required).
-   * @param messageId Unique messageId for which CCS will send an "ack/nack" (Required).
-   * @param payload Message content intended for the application. (Optional).
-   * @param collapseKey GCM collapse_key parameter (Optional).
-   * @param timeToLive GCM time_to_live parameter (Optional).
-   * @param delayWhileIdle GCM delay_while_idle parameter (Optional).
-   * @return JSON encoded GCM message.
-   */
-  public static String createJsonMessage(String to, String messageId, Map<String, String> payload,
-      String collapseKey, Long timeToLive, Boolean delayWhileIdle) {
-    Map<String, Object> message = new HashMap<String, Object>();
-    message.put("to", to);
-    if (collapseKey != null) {
-      message.put("collapse_key", collapseKey);
-    }
-    if (timeToLive != null) {
-      message.put("time_to_live", timeToLive);
-    }
-    if (delayWhileIdle != null && delayWhileIdle) {
-      message.put("delay_while_idle", true);
-    }
-    message.put("message_id", messageId);
-    message.put("data", payload);
-    return JSONValue.toJSONString(message);
-  }
-
-  /**
-   * Creates a JSON encoded ACK message for an upstream message received from an application.
-   *
-   * @param to RegistrationId of the device who sent the upstream message.
-   * @param messageId messageId of the upstream message to be acknowledged to CCS.
-   * @return JSON encoded ack.
-   */
-  public static String createJsonAck(String to, String messageId) {
-    Map<String, Object> message = new HashMap<String, Object>();
-    message.put("message_type", "ack");
-    message.put("to", to);
-    message.put("message_id", messageId);
-    return JSONValue.toJSONString(message);
-  }
-
-  /**
-   * Connects to GCM Cloud Connection Server using the supplied credentials.
-   *
-   * @param username GCM_SENDER_ID@gcm.googleapis.com
-   * @param password API Key
-   * @throws XMPPException
-   */
-  public void connect(String username, String password) throws XMPPException {
-    config = new ConnectionConfiguration(GCM_SERVER, GCM_PORT);
-    config.setSecurityMode(SecurityMode.enabled);
-    config.setReconnectionAllowed(true);
-    config.setRosterLoadedAtLogin(false);
-    config.setSendPresence(false);
-    config.setSocketFactory(SSLSocketFactory.getDefault());
-
-    // NOTE: Set to true to launch a window with information about packets sent and received
-    config.setDebuggerEnabled(true);
-
-    // -Dsmack.debugEnabled=true
-    XMPPConnection.DEBUG_ENABLED = true;
-
-    connection = new XMPPConnection(config);
-    connection.connect();
-
-    connection.addConnectionListener(new ConnectionListener() {
-
-      @Override
-      public void reconnectionSuccessful() {
-        logger.info("Reconnecting..");
-      }
-
-      @Override
-      public void reconnectionFailed(Exception e) {
-        logger.log(Level.INFO, "Reconnection failed.. ", e);
-      }
-
-      @Override
-      public void reconnectingIn(int seconds) {
-        logger.log(Level.INFO, "Reconnecting in %d secs", seconds);
-      }
-
-      @Override
-      public void connectionClosedOnError(Exception e) {
-        logger.log(Level.INFO, "Connection closed on error.");
-      }
-
-      @Override
-      public void connectionClosed() {
-        logger.info("Connection closed.");
-      }
-    });
-
-    // Handle incoming packets
-    connection.addPacketListener(new PacketListener() {
-
-      @Override
-      public void processPacket(Packet packet) {
-        logger.log(Level.INFO, "Received: " + packet.toXML());
-        Message incomingMessage = (Message) packet;
-        GcmPacketExtension gcmPacket =
-            (GcmPacketExtension) incomingMessage.getExtension(GCM_NAMESPACE);
-        String json = gcmPacket.getJson();
-        try {
-          @SuppressWarnings("unchecked")
-          Map<String, Object> jsonObject =
-              (Map<String, Object>) JSONValue.parseWithException(json);
-
-          // present for "ack"/"nack", null otherwise
-          Object messageType = jsonObject.get("message_type");
-
-          if (messageType == null) {
-            // Normal upstream data message
-            handleIncomingDataMessage(jsonObject);
-
-            // Send ACK to CCS
-            String messageId = jsonObject.get("message_id").toString();
-            String from = jsonObject.get("from").toString();
-            String ack = createJsonAck(from, messageId);
-            send(ack);
-          } else if ("ack".equals(messageType.toString())) {
-            // Process Ack
-            handleAckReceipt(jsonObject);
-          } else if ("nack".equals(messageType.toString())) {
-            // Process Nack
-            handleNackReceipt(jsonObject);
-          } else {
-            logger.log(Level.WARNING, "Unrecognized message type (%s)",
-                messageType.toString());
-          }
-        } catch (ParseException e) {
-          logger.log(Level.SEVERE, "Error parsing JSON " + json, e);
-        } catch (Exception e) {
-          logger.log(Level.SEVERE, "Couldn't send echo.", e);
-        }
-      }
-    }, new PacketTypeFilter(Message.class));
-
-
-    // Log all outgoing packets
-    connection.addPacketInterceptor(new PacketInterceptor() {
-      @Override
-      public void interceptPacket(Packet packet) {
-        logger.log(Level.INFO, "Sent: {0}",  packet.toXML());
-      }
-    }, new PacketTypeFilter(Message.class));
-
-    connection.login(username, password);
-  }
-
-  public static void main(String [] args) {
-    final String userName = "Your GCM Sender Id" + "@gcm.googleapis.com";
-    final String password = "API Key";
-
-    SmackCcsClient ccsClient = new SmackCcsClient();
-
-    try {
-      ccsClient.connect(userName, password);
-    } catch (XMPPException e) {
-      e.printStackTrace();
-    }
-
-    // Send a sample hello downstream message to a device.
-    String toRegId = "RegistrationIdOfTheTargetDevice";
-    String messageId = ccsClient.getRandomMessageId();
-    Map<String, String> payload = new HashMap<String, String>();
-    payload.put("Hello", "World");
-    payload.put("CCS", "Dummy Message");
-    payload.put("EmbeddedMessageId", messageId);
-    String collapseKey = "sample";
-    Long timeToLive = 10000L;
-    Boolean delayWhileIdle = true;
-    ccsClient.send(createJsonMessage(toRegId, messageId, payload, collapseKey,
-        timeToLive, delayWhileIdle));
-  }
-}
    
-
    Python sample
    
-
-
    Here is an example of a CCS app server written in Python. This sample echo
-server sends an initial message, and for every upstream message received, it sends
-a dummy response back to the application that sent the upstream message. This
-example illustrates how to connect, send, and receive GCM messages using XMPP. It
-shouldn't be used as-is on a production deployment.
    
-
-
    -#!/usr/bin/python
-import sys, json, xmpp, random, string
-
-SERVER = 'gcm.googleapis.com'
-PORT = 5235
-USERNAME = "Your GCM Sender Id"
-PASSWORD = "API Key"
-REGISTRATION_ID = "Registration Id of the target device"
-
-unacked_messages_quota = 1000
-send_queue = []
-
-# Return a random alphanumerical id
-def random_id():
-  rid = ''
-  for x in range(8): rid += random.choice(string.ascii_letters + string.digits)
-  return rid
-
-def message_callback(session, message):
-  global unacked_messages_quota
-  gcm = message.getTags('gcm')
-  if gcm:
-    gcm_json = gcm[0].getData()
-    msg = json.loads(gcm_json)
-    if not msg.has_key('message_type'):
-      # Acknowledge the incoming message immediately.
-      send({'to': msg['from'],
-            'message_type': 'ack',
-            'message_id': msg['message_id']})
-      # Queue a response back to the server.
-      if msg.has_key('from'):
-        # Send a dummy echo response back to the app that sent the upstream message.
-        send_queue.append({'to': msg['from'],
-                           'message_id': random_id(),
-                           'data': {'pong': 1}})
-    elif msg['message_type'] == 'ack' or msg['message_type'] == 'nack':
-      unacked_messages_quota += 1
-
-def send(json_dict):
-  template = ("<message><gcm xmlns='google:mobile:data'>{1}</gcm></message>")
-  client.send(xmpp.protocol.Message(
-      node=template.format(client.Bind.bound[0], json.dumps(json_dict))))
-
-def flush_queued_messages():
-  global unacked_messages_quota
-  while len(send_queue) and unacked_messages_quota > 0:
-    send(send_queue.pop(0))
-    unacked_messages_quota -= 1
-
-client = xmpp.Client('gcm.googleapis.com', debug=['socket'])
-client.connect(server=(SERVER,PORT), secure=1, use_srv=False)
-auth = client.auth(USERNAME, PASSWORD)
-if not auth:
-  print 'Authentication failed!'
-  sys.exit(1)
-
-client.RegisterHandler('message', message_callback)
-
-send_queue.append({'to': REGISTRATION_ID,
-                   'message_id': 'reg_id',
-                   'data': {'message_destination': 'RegId',
-                            'message_id': random_id()}})
-
-while True:
-  client.Process(1)
-  flush_queued_messages()
    
diff --git a/docs/html/google/gcm/client.jd b/docs/html/google/gcm/client.jd
index df357a270309..7604932aa383 100644
--- a/docs/html/google/gcm/client.jd
+++ b/docs/html/google/gcm/client.jd
@@ -1,663 +1,24 @@
-page.title=Implementing GCM Client
+page.title=GCM Client
 page.tags="cloud","push","messaging"
 @jd:body
 
 
 
-
    A GCM client is a GCM-enabled app that runs on an Android device. To write your
-client code, we recommend that you use the
-
-{@code GoogleCloudMessaging} APIs.
-The client helper library that was offered in previous versions of GCM still works,
-but it has been superseded by the more efficient
-
-{@code GoogleCloudMessaging} APIs.
    
-
-
    A full GCM implementation requires both a client implementation and a server
-implementation. For more
-information about implementing the server side, see 
-Implementing GCM Server.
    
-
-
    The following sections walk you through the steps involved in writing a GCM
-client-side application. Your client app can be arbitrarily complex, but at bare
-minimum, a GCM client app must include code to register (and thereby get a
-registration ID), and a broadcast receiver to receive messages sent by GCM.
-
    
-
-
    Step 1: Set Up Google Play Services
    
-
-
    To write your client application, use the
-
-{@code GoogleCloudMessaging} API.
-To use this API, you must set up your project to use the Google Play services SDK,
-as described in Setup Google Play
-Services SDK.
    
-
-
    Caution: When you add the Play Services library to
-your project, be sure to add it with resources, as described in
-
-Setup Google Play Services SDK. The key point is that you must
-reference the library—simply adding a {@code .jar} file to
-your Eclipse project will not work. You must follow the directions
-for referencing a library, or your app won't be able to access
-the library's resources, and it won't run properly.
-If you're using Android Studio, this is the string to add to the
-{@code dependency} section of your application's {@code build.gradle} file:
    
-
-
    dependencies {
-   compile: "com.google.android.gms:play-services:3.1.+"
-}
-
    
-
-
-
    Step 2: Edit Your Application's Manifest
    
-
-
    Add the following to your application's manifest:
    
-
-
-
    Here are excerpts from a sample manifest that supports GCM:
    
-
-
    -<manifest package="com.example.gcm" ...>
-
-    <uses-sdk android:minSdkVersion="8" android:targetSdkVersion="17"/>
-    <uses-permission android:name="android.permission.INTERNET" />
-    <uses-permission android:name="android.permission.GET_ACCOUNTS" />
-    <uses-permission android:name="android.permission.WAKE_LOCK" />
-    <uses-permission android:name="com.google.android.c2dm.permission.RECEIVE" />
-
-    <permission android:name="com.example.gcm.permission.C2D_MESSAGE"
-        android:protectionLevel="signature" />
-    <uses-permission android:name="com.example.gcm.permission.C2D_MESSAGE" />
-
-    <application ...>
-        <receiver
-            android:name=".GcmBroadcastReceiver"
-            android:permission="com.google.android.c2dm.permission.SEND" >
-            <intent-filter>
-                <action android:name="com.google.android.c2dm.intent.RECEIVE" />
-                <category android:name="com.example.gcm" />
-            </intent-filter>
-        </receiver>
-        <service android:name=".GcmIntentService" />
-    </application>
-
-</manifest>
-
    
-
-
     Step 3: Write Your Application
    
-
-
    Finally, write your application. This section features a sample client
-application that illustrates how to use the
-
-{@code GoogleCloudMessaging} APIs. The sample consists of a main activity
-({@code DemoActivity}), a {@link android.support.v4.content.WakefulBroadcastReceiver}
-({@code GcmBroadcastReceiver}), and an {@link android.app.IntentService}
-({@code GcmIntentService}). You can find the complete source code for this sample at the
-open source site.
    
-
-
    Note the following:
    
-
-
-
-
    Check for Google Play Services APK
    
-
-
    As described in 
-Setup Google Play Services SDK, apps that rely on the Play Services SDK
-should always check the device for a compatible Google Play services APK before
-accessing Google Play services features. In the sample app this check is done in
-two places: in the main activity's {@code onCreate()} method, and in its
-{@code onResume()} method. The check in {@code onCreate()} ensures that the app
-can't be used without a successful check. The check in {@code onResume()} ensures
-that if the user returns to the running app through some other means, such as
-through the back button, the check is still performed. If the
-device doesn't have a compatible Google Play services APK, your app can call
-{@code GooglePlayServicesUtil.getErrorDialog()} to allow users to download the
-APK from the Google Play Store or enable it in the device's system settings.
-For example:
    
-
-
    private final static int PLAY_SERVICES_RESOLUTION_REQUEST = 9000;
-...
-@Override
-public void onCreate(Bundle savedInstanceState) {
-    super.onCreate(savedInstanceState);
-
-    setContentView(R.layout.main);
-    mDisplay = (TextView) findViewById(R.id.display);
-
-    context = getApplicationContext();
-
-    // Check device for Play Services APK.
-    if (checkPlayServices()) {
-        // If this check succeeds, proceed with normal processing.
-        // Otherwise, prompt user to get valid Play Services APK.
-        ...
-    }
-}
-
-// You need to do the Play Services APK check here too.
-@Override
-protected void onResume() {
-    super.onResume();
-    checkPlayServices();
-}
-
-/**
- * Check the device to make sure it has the Google Play Services APK. If
- * it doesn't, display a dialog that allows users to download the APK from
- * the Google Play Store or enable it in the device's system settings.
- */
-private boolean checkPlayServices() {
-    int resultCode = GooglePlayServicesUtil.isGooglePlayServicesAvailable(this);
-    if (resultCode != ConnectionResult.SUCCESS) {
-        if (GooglePlayServicesUtil.isUserRecoverableError(resultCode)) {
-            GooglePlayServicesUtil.getErrorDialog(resultCode, this,
-                    PLAY_SERVICES_RESOLUTION_REQUEST).show();
-        } else {
-            Log.i(TAG, "This device is not supported.");
-            finish();
-        }
-        return false;
-    }
-    return true;
-}
    
-
-
    Register for GCM
    
-
    An Android application needs to register with GCM servers before it can receive
-messages. When an app registers, it receives a registration ID, which it can then
-store for future use. In the following snippet the {@code onCreate()} method in the sample app's
-main activity checks to see if the app is already registered with GCM and with
-the server:
    
-
-
    /**
- * Main UI for the demo app.
- */
-public class DemoActivity extends Activity {
-
-    public static final String EXTRA_MESSAGE = "message";
-    public static final String PROPERTY_REG_ID = "registration_id";
-    private static final String PROPERTY_APP_VERSION = "appVersion";
-    private final static int PLAY_SERVICES_RESOLUTION_REQUEST = 9000;
-
-    /**
-     * Substitute you own sender ID here. This is the project number you got
-     * from the API Console, as described in "Getting Started."
-     */
-    String SENDER_ID = "Your-Sender-ID";
-
-    /**
-     * Tag used on log messages.
-     */
-    static final String TAG = "GCMDemo";
-
-    TextView mDisplay;
-    GoogleCloudMessaging gcm;
-    AtomicInteger msgId = new AtomicInteger();
-    SharedPreferences prefs;
-    Context context;
-
-    String regid;
-
-    @Override
-    public void onCreate(Bundle savedInstanceState) {
-        super.onCreate(savedInstanceState);
+
    A GCM client is a GCM-enabled app that runs on an Android device. To write your client code, we recommend that you use the new {@code GoogleCloudMessaging} APIs. The client helper library that was offered in previous versions of GCM still works, but it has been superseded by the more efficient {@code GoogleCloudMessaging} APIs.
    
 
-        setContentView(R.layout.main);
-        mDisplay = (TextView) findViewById(R.id.display);
+
    A full GCM implementation requires both a client implementation and a server-side implementation. For a step-by-step guide to creating a complete sample implementation that includes both client and server, see Getting Started. 
    
 
-        context = getApplicationContext();
-
-        // Check device for Play Services APK. If check succeeds, proceed with
-        //  GCM registration.
-        if (checkPlayServices()) {
-            gcm = GoogleCloudMessaging.getInstance(this);
-            regid = getRegistrationId(context);
-
-            if (regid.isEmpty()) {
-                registerInBackground();
-            }
-        } else {
-            Log.i(TAG, "No valid Google Play Services APK found.");
-        }
-    }
-...
-}
    
-
-
    The app calls {@code getRegistrationId()} to see whether there is an existing
-registration ID stored in shared preferences:
    
-
-
    /**
- * Gets the current registration ID for application on GCM service.
- * <p>
- * If result is empty, the app needs to register.
- *
- * @return registration ID, or empty string if there is no existing
- *         registration ID.
- */
-private String getRegistrationId(Context context) {
-    final SharedPreferences prefs = getGCMPreferences(context);
-    String registrationId = prefs.getString(PROPERTY_REG_ID, "");
-    if (registrationId.isEmpty()) {
-        Log.i(TAG, "Registration not found.");
-        return "";
-    }
-    // Check if app was updated; if so, it must clear the registration ID
-    // since the existing regID is not guaranteed to work with the new
-    // app version.
-    int registeredVersion = prefs.getInt(PROPERTY_APP_VERSION, Integer.MIN_VALUE);
-    int currentVersion = getAppVersion(context);
-    if (registeredVersion != currentVersion) {
-        Log.i(TAG, "App version changed.");
-        return "";
-    }
-    return registrationId;
-}
-...
-/**
- * @return Application's {@code SharedPreferences}.
- */
-private SharedPreferences getGCMPreferences(Context context) {
-    // This sample app persists the registration ID in shared preferences, but
-    // how you store the regID in your app is up to you.
-    return getSharedPreferences(DemoActivity.class.getSimpleName(),
-            Context.MODE_PRIVATE);
-}
    
-
-
    If the registration ID doesn't exist or the app was updated,
-{@code getRegistrationId()} returns an empty string
-to indicate that the app needs to get a new regID. {@code getRegistrationId()} calls
-the following method to check the app version:
    
-
-
    /**
- * @return Application's version code from the {@code PackageManager}.
- */
-private static int getAppVersion(Context context) {
-    try {
-        PackageInfo packageInfo = context.getPackageManager()
-                .getPackageInfo(context.getPackageName(), 0);
-        return packageInfo.versionCode;
-    } catch (NameNotFoundException e) {
-        // should never happen
-        throw new RuntimeException("Could not get package name: " + e);
-    }
-}
    
-
-
-
    If there isn't a valid existing registration ID, {@code DemoActivity} calls the
-following {@code registerInBackground()} method to register. Note that because the GCM
-methods {@code register()} and {@code unregister()} are blocking, this has to
-take place on a background thread. This sample uses {@link android.os.AsyncTask}
-to accomplish this:
    
-
-
    -/**
- * Registers the application with GCM servers asynchronously.
- * <p>
- * Stores the registration ID and app versionCode in the application's
- * shared preferences.
- */
-private void registerInBackground() {
-    new AsyncTask() {
-        @Override
-        protected String doInBackground(Void... params) {
-            String msg = "";
-            try {
-                if (gcm == null) {
-                    gcm = GoogleCloudMessaging.getInstance(context);
-                }
-                regid = gcm.register(SENDER_ID);
-                msg = "Device registered, registration ID=" + regid;
-
-                // You should send the registration ID to your server over HTTP,
-                // so it can use GCM/HTTP or CCS to send messages to your app.
-                // The request to your server should be authenticated if your app
-                // is using accounts.
-                sendRegistrationIdToBackend();
-
-                // For this demo: we don't need to send it because the device
-                // will send upstream messages to a server that echo back the
-                // message using the 'from' address in the message.
-
-                // Persist the regID - no need to register again.
-                storeRegistrationId(context, regid);
-            } catch (IOException ex) {
-                msg = "Error :" + ex.getMessage();
-                // If there is an error, don't just keep trying to register.
-                // Require the user to click a button again, or perform
-                // exponential back-off.
-            }
-            return msg;
-        }
-
-        @Override
-        protected void onPostExecute(String msg) {
-            mDisplay.append(msg + "\n");
-        }
-    }.execute(null, null, null);
-    ...
-    /**
-     * Sends the registration ID to your server over HTTP, so it can use GCM/HTTP
-     * or CCS to send messages to your app. Not needed for this demo since the
-     * device sends upstream messages to a server that echoes back the message
-     * using the 'from' address in the message.
-     */
-    private void sendRegistrationIdToBackend() {
-      // Your implementation here.
-    }
-}
    
-
-
    After registering, the app calls {@code storeRegistrationId()} to store the
-registration ID in shared preferences for future use. This is just one way of
-persisting a regID. You might choose to use a different approach in your app:
    
-
-
    /**
- * Stores the registration ID and app versionCode in the application's
- * {@code SharedPreferences}.
- *
- * @param context application's context.
- * @param regId registration ID
- */
-private void storeRegistrationId(Context context, String regId) {
-    final SharedPreferences prefs = getGCMPreferences(context);
-    int appVersion = getAppVersion(context);
-    Log.i(TAG, "Saving regId on app version " + appVersion);
-    SharedPreferences.Editor editor = prefs.edit();
-    editor.putString(PROPERTY_REG_ID, regId);
-    editor.putInt(PROPERTY_APP_VERSION, appVersion);
-    editor.commit();
-}
    
-
-
    Send a message
    
-
    When the user clicks the app's Send button, the app sends an
-upstream message using the
-
-{@code GoogleCloudMessaging} APIs. In order to receive the upstream message,
-your server should be connected to CCS. You can use one of the demo servers in
-Implementing an XMPP-based App Server to run the sample and connect
-to CCS.
    
-
-
    public void onClick(final View view) {
-    if (view == findViewById(R.id.send)) {
-        new AsyncTask() {
-            @Override
-            protected String doInBackground(Void... params) {
-                String msg = "";
-                try {
-                    Bundle data = new Bundle();
-                        data.putString("my_message", "Hello World");
-                        data.putString("my_action",
-                                "com.google.android.gcm.demo.app.ECHO_NOW");
-                        String id = Integer.toString(msgId.incrementAndGet());
-                        gcm.send(SENDER_ID + "@gcm.googleapis.com", id, data);
-                        msg = "Sent message";
-                } catch (IOException ex) {
-                    msg = "Error :" + ex.getMessage();
-                }
-                return msg;
-            }
-
-            @Override
-            protected void onPostExecute(String msg) {
-                mDisplay.append(msg + "\n");
-            }
-        }.execute(null, null, null);
-    } else if (view == findViewById(R.id.clear)) {
-        mDisplay.setText("");
-    }
-}
    
-
-
    Receive a message
    
-
-
    As described above in Step 2, the app includes a
-{@link android.support.v4.content.WakefulBroadcastReceiver} for the com.google.android.c2dm.intent.RECEIVE
-intent. A broadcast receiver is the mechanism GCM uses to deliver messages. When {@code onClick()}
-calls {@code gcm.send()}, it triggers the broadcast receiver's {@code onReceive()}
-method, which has the responsibility of making sure that the GCM message gets handled.
    
-
    A {@link android.support.v4.content.WakefulBroadcastReceiver} is a special type of
-broadcast receiver that takes care of
-creating and managing a
-
-partial wake lock for your app.
-It passes off the work of processing the GCM message to a
-{@link android.app.Service} (typically an
-{@link android.app.IntentService}), while ensuring that the device does not
-go back to sleep in the transition. If you don't hold a wake lock while transitioning
-the work to a service, you are effectively allowing the device to go back to sleep before
-the work completes. The net result is that the app might not finish processing
-the GCM message until some arbitrary point in the future, which is not what you want.
    
-
-
    Note: Using {@link android.support.v4.content.WakefulBroadcastReceiver}
-is not a requirement. If you have a relatively simple app that doesn't require
-a service, you can intercept the GCM message in a regular {@link android.content.BroadcastReceiver}
-and do your processing there. Once you get the intent that GCM passes into
-your broadcast receiver's {@code onReceive()} method, what you do with it
-is up to you.
    
-
-
    This snippet starts {@code GcmIntentService} with the method
-{@link android.support.v4.content.WakefulBroadcastReceiver#startWakefulService startWakefulService()}.
-This method is comparable to {@link android.content.Context#startService startService()}, except that
-the {@link android.support.v4.content.WakefulBroadcastReceiver} is holding a
-wake lock when the service starts. The intent that is passed with
-{@link android.support.v4.content.WakefulBroadcastReceiver#startWakefulService startWakefulService()}
-holds an extra identifying the wake lock:
    
-
-
-
    public class GcmBroadcastReceiver extends WakefulBroadcastReceiver {
-    @Override
-    public void onReceive(Context context, Intent intent) {
-        // Explicitly specify that GcmIntentService will handle the intent.
-        ComponentName comp = new ComponentName(context.getPackageName(),
-                GcmIntentService.class.getName());
-        // Start the service, keeping the device awake while it is launching.
-        startWakefulService(context, (intent.setComponent(comp)));
-        setResultCode(Activity.RESULT_OK);
-    }
-}
    
-
-
    The intent service shown below does the actual work of handling the GCM
-message. When the service is finished, it calls
-{@link android.support.v4.content.WakefulBroadcastReceiver#completeWakefulIntent GcmBroadcastReceiver.completeWakefulIntent()}
-to release the wake lock. The
-{@link android.support.v4.content.WakefulBroadcastReceiver#completeWakefulIntent completeWakefulIntent()}
-method has as its parameter the same intent that was
-passed in from the {@link android.support.v4.content.WakefulBroadcastReceiver}.
-
    
-
-
    This snippet processes the GCM message based on message type, and posts the
-result in a notification. But what you do with GCM messages in your app is up to
-you—the possibilities are endless. For example, the message might be a ping,
-telling the app to sync to a server to retrieve new content, or it might be a
-chat message that you display in the UI.
    
-
-
    -public class GcmIntentService extends IntentService {
-    public static final int NOTIFICATION_ID = 1;
-    private NotificationManager mNotificationManager;
-    NotificationCompat.Builder builder;
-
-    public GcmIntentService() {
-        super("GcmIntentService");
-    }
-
-    @Override
-    protected void onHandleIntent(Intent intent) {
-        Bundle extras = intent.getExtras();
-        GoogleCloudMessaging gcm = GoogleCloudMessaging.getInstance(this);
-        // The getMessageType() intent parameter must be the intent you received
-        // in your BroadcastReceiver.
-        String messageType = gcm.getMessageType(intent);
-
-        if (!extras.isEmpty()) {  // has effect of unparcelling Bundle
-            /*
-             * Filter messages based on message type. Since it is likely that GCM
-             * will be extended in the future with new message types, just ignore
-             * any message types you're not interested in, or that you don't
-             * recognize.
-             */
-            if (GoogleCloudMessaging.
-                    MESSAGE_TYPE_SEND_ERROR.equals(messageType)) {
-                sendNotification("Send error: " + extras.toString());
-            } else if (GoogleCloudMessaging.
-                    MESSAGE_TYPE_DELETED.equals(messageType)) {
-                sendNotification("Deleted messages on server: " +
-                        extras.toString());
-            // If it's a regular GCM message, do some work.
-            } else if (GoogleCloudMessaging.
-                    MESSAGE_TYPE_MESSAGE.equals(messageType)) {
-                // This loop represents the service doing some work.
-                for (int i=0; i<5; i++) {
-                    Log.i(TAG, "Working... " + (i+1)
-                            + "/5 @ " + SystemClock.elapsedRealtime());
-                    try {
-                        Thread.sleep(5000);
-                    } catch (InterruptedException e) {
-                    }
-                }
-                Log.i(TAG, "Completed work @ " + SystemClock.elapsedRealtime());
-                // Post notification of received message.
-                sendNotification("Received: " + extras.toString());
-                Log.i(TAG, "Received: " + extras.toString());
-            }
-        }
-        // Release the wake lock provided by the WakefulBroadcastReceiver.
-        GcmBroadcastReceiver.completeWakefulIntent(intent);
-    }
-
-    // Put the message into a notification and post it.
-    // This is just one simple example of what you might choose to do with
-    // a GCM message.
-    private void sendNotification(String msg) {
-        mNotificationManager = (NotificationManager)
-                this.getSystemService(Context.NOTIFICATION_SERVICE);
-
-        PendingIntent contentIntent = PendingIntent.getActivity(this, 0,
-                new Intent(this, DemoActivity.class), 0);
-
-        NotificationCompat.Builder mBuilder =
-                new NotificationCompat.Builder(this)
-        .setSmallIcon(R.drawable.ic_stat_gcm)
-        .setContentTitle("GCM Notification")
-        .setStyle(new NotificationCompat.BigTextStyle()
-        .bigText(msg))
-        .setContentText(msg);
-
-        mBuilder.setContentIntent(contentIntent);
-        mNotificationManager.notify(NOTIFICATION_ID, mBuilder.build());
-    }
-}
    
-
-
    Running the Sample
    
-
-
    To run the sample:
    
-
-
      
-  
    1. Follow the instructions in Getting Started to get your sender ID and
-  API key.
      2. 
-  
    2. Implement your client app, as described in this document. You can find the complete source
-  code for the client app at the open source site.
      3. 
-  
    3. Run one of the demo servers (Java or Python) provided in
-Implementing an XMPP-based App Server. Whichever demo server you
- choose, don't forget to edit its code before running it to supply
-your sender ID and API key.
-
      4. 
-
-
    
-
-
    Viewing Statistics
    
-
-
    To view  statistics and any error messages for your GCM applications:
    
-
      
-  
    1.  Go to the Developer Console.
      2. 
-  
    2. Login with your developer account.
-  
      You will see a page that has a list of all of your apps.
      3. 
-  
    3.  Click on the "statistics" link next to the app for which you
-want to view GCM stats.
-  
      Now you are on the statistics page.
       
      4. 
-  
    4. Go to the drop-down menu and select the GCM metric you want to view.
-  
      5. 
-
    
-
    Note: Stats on the Google API Console are not
-enabled for GCM. You must use the Developer Console.
    
+
    
 
 
diff --git a/docs/html/google/gcm/gcm.jd b/docs/html/google/gcm/gcm.jd
index 3c80b5f9ae5f..ceb82b03702b 100644
--- a/docs/html/google/gcm/gcm.jd
+++ b/docs/html/google/gcm/gcm.jd
@@ -1,23 +1,48 @@
-page.title=Overview
+page.title=GCM Architectural Overview
 @jd:body
 
 
    
 
    
 
+
    Quickview
    
+
+
      
+
    • Get an introduction to key GCM terms and concepts.
      • 
+
    • Learn the basic features of a GCM application.
      • 
+
    • Understand the role of the 3rd-party application server, and how to send messages and process results.
      • 
+
    
+
+
 
    In this document
    
 
 
      
-  
    1. Key Concepts
      2. 
-  
    2. Architectural Overview
      3. 
-  
    3. Lifecycle Flow
+  
    4. Introduction 
      5. 
+  
    5. Architectural Overview
+    
        
+      
      1. Lifecycle Flow
        2. 
+        
          
+          
        1. Enable GCM
          2. 
+          
        2. Send a message
          3. 
+          
        3. Receive a message
          4. 
+        
        
+      
      2. What Does the User See?
        3. 
+    
      
+  
      6. 
+  
    6. Role of  the 3rd-party Application Server
     
        
-      
      1. Enable GCM
        2. 
-      
      2. Send a message
        3. 
-      
      3. Receive a message
        4. 
+      
      4. Sending Messages
+        
          
+          
        1. Request format
          2. 
+          
        2. Response format
          3. 
+        
        
+      
        5. 
     
      
+    
    7. Viewing Statistics
   
      8. 
 
    
 
+
+
 
    
 
    
 
@@ -25,15 +50,24 @@ page.title=Overview
 developers  send data from servers to their Android applications on  Android
 devices, and upstream messages from the user's device back to the cloud.
 This could be a lightweight message telling the Android application
-that there is new data to be fetched from the server (for instance, a "new email"
-notification informing the application that it is out of sync with the back end),
-or it could be a message containing up to 4kb of payload
+that there is new data to be fetched from the server (for instance, a movie
+uploaded by a friend), or it could be a message containing up to 4kb of payload
 data (so apps like instant messaging can consume the message directly). The GCM
 service handles all aspects  of queueing of messages and delivery to the target
 Android application running  on the target device.
    
+
+
    GCM introduces GCM Cloud Connection Server (CCS), which you can use
+in tandem with GCM HTTP service/endpoint/APIs.
+CCS uses XMPP, and it offers asynchronous, bidirectional
+messaging. For more information, see
+GCM Cloud Connection Server.
+  
   
 
     To jump right into using GCM with your Android
-  applications, see Getting Started.
    
+  applications, see the instructions in Getting Started.
    
+
+
+
    Introduction
    
 
 
    Here are the primary characteristics of Google Cloud 
 Messaging (GCM):
    
@@ -41,11 +75,9 @@ Messaging (GCM):
    
 
-
-
    Key Concepts
    
-
+
    Architectural Overview
    
+
    This section gives an overview of how GCM works. 
    
 
    This table summarizes the key terms and concepts involved in GCM. It is
 divided into these categories:
    
 
 
-
    
-  Table 1. GCM components and credentials.
    
-
 
-    
-    
+    
+    
-    
+    
-    
-    
+    
-    
+    
-    
+    
@@ -136,8 +158,7 @@ which would cause delivery errors.
   
-    
+    
@@ -146,46 +167,25 @@ server that gives the application server authorized access to Google services.
 The API key is included in the header of POST requests  that send messages.
 
-
    
   
    
     Components
   
    
   
    Client AppThe GCM-enabled Android application that is running on a
-    device. This must be a 2.2 Android device that has Google Play Store installed, and it must
-have at least one logged in Google account if the device is running a version
-lower than Android 4.0.4. Alternatively, for testing you can use an emulator
-running Android 2.2 with Google APIs.Mobile DeviceThe device that is running an Android application that uses
+GCM. This must be a 2.2 Android device that has Google Play Store installed, and it must
+have at least one logged in Google account if the device is running a version lower than Android 4.0.4. Alternatively, for testing you can use an emulator running Android 2.2 with Google APIs.
   
    
   
    
     3rd-party Application ServerAn application server that you write as part of implementing
-GCM. The 3rd-party application server sends data to an
-Android application on the device via the GCM connection server.An application server that  developers  set up as part of implementing
+GCM in their applications. The 3rd-party application server sends data to an
+Android application on the device via the GCM server.
   
    
   
    GCM Connection ServersThe Google-provided servers involved in taking messages from the 3rd-party
+    GCM ServersThe Google servers involved in taking messages from the 3rd-party
 application server and sending them to the device. 
   
    
   
    CredentialsCredentials
   
    
   
    
     Sender IDA project number you acquire from the API console, as described in
-Getting Started. The sender
-ID is used in the registration process to identify a
-3rd-party application server that is permitted to send messages to the device.A project number you acquire from the API console, as described in Getting Started. The sender
+ID is used in the registration process to identify an
+Android application that is permitted to send messages to the device.
   
    
   
    
     Application ID
     The Android application that is registering to receive messages. The Android application
-is identified by the package name from the manifest.
+is identified by the package name from the manifest.
 This  ensures that the messages are targeted to the correct Android application.
   
    
   
    
   
    
     Google User AccountFor GCM to work, the mobile device must include at least one Google
-account if the device is running a version lower than Android 4.0.4.For GCM to work, the mobile device must include at least one Google account if the device is running a version lower than Android 4.0.4.
   
    
   
    
     Sender Auth Token
   
    
-
-
    Architectural Overview
    
-
-
    A GCM implementation includes a Google-provided
-connection server, a 3rd-party app server that interacts with the connection
-server, and a GCM-enabled client app running on an Android device:
    
-
-
+  
+    Notification Key
+    Part of the user notifications feature, which provides a mapping between a user and instances of an app running on multiple devices owned by the user. The {@code notification_key} is the token that GCM uses to fan out notifications to all devices whose registration IDs are associated with the key. For more discussion of this topic, see User Notifications.
+  
 
-
    
-  Figure 1. GCM Architecture.
-
    
+
+    Notification Key Name
+    Part of the user notifications feature. The {@code notification_key_name} is a name or identifier (can be a username for a 3rd-party app) that is unique to a given user. It is used by third parties to group together registration IDs for a single user. For more discussion of this topic, see User Notifications.
+  
 
-
    This is how these components interact:
    
-
+
 
-
    Lifecycle Flow
    
+
    Lifecycle Flow
    
 
 
+
+
    Example
    
+
+
    Here is a sample client application that illustrates how to use the {@code GoogleCloudMessaging} APIs. The sample consists of a main activity ({@code DemoActivity}) and a broadcast receiver ({@code GcmBroadcastReceiver}). You can use this client sample code in conjunction with the server code shown in Writing the Server Code.
    
+
+
    Note the following:
    
+
+
+
+
    Registering
    
+
    An Android application needs to register with GCM servers before it can receive messages. So in its {@code onCreate()} method, {@code DemoActivity} checks to see whether the app is registered with GCM and with the server:
    
+
+
    /**
+ * Main UI for the demo app.
+ */
+public class DemoActivity extends Activity {
+
+    public static final String EXTRA_MESSAGE = "message";
+    public static final String PROPERTY_REG_ID = "registration_id";
+    private static final String PROPERTY_APP_VERSION = "appVersion";
+    private static final String PROPERTY_ON_SERVER_EXPIRATION_TIME =
+            "onServerExpirationTimeMs";
+    /**
+     * Default lifespan (7 days) of a reservation until it is considered expired.
+     */
+    public static final long REGISTRATION_EXPIRY_TIME_MS = 1000 * 3600 * 24 * 7;
+
+    /**
+     * Substitute you own sender ID here.
+     */
+    String SENDER_ID = "Your-Sender-ID";
+
+    /**
+     * Tag used on log messages.
+     */
+    static final String TAG = "GCMDemo";
+
+    TextView mDisplay;
+    GoogleCloudMessaging gcm;
+    AtomicInteger msgId = new AtomicInteger();
+    SharedPreferences prefs;
+    Context context;
+
+    String regid;
+
+    @Override
+    public void onCreate(Bundle savedInstanceState) {
+        super.onCreate(savedInstanceState);
+
+        setContentView(R.layout.main);
+        mDisplay = (TextView) findViewById(R.id.display);
+
+        context = getApplicationContext();
+        regid = getRegistrationId(context);
+
+        if (regid.length() == 0) {
+            registerBackground();
+        }
+        gcm = GoogleCloudMessaging.getInstance(this);
+    }
+...
+}
    
+
+
    The app calls {@code getRegistrationId()} to see whether there is an existing registration ID stored in shared preferences:
    
+
+
    /**
+ * Gets the current registration id for application on GCM service.
+ * <p>
+ * If result is empty, the registration has failed.
+ *
+ * @return registration id, or empty string if the registration is not
+ *         complete.
+ */
+private String getRegistrationId(Context context) {
+    final SharedPreferences prefs = getGCMPreferences(context);
+    String registrationId = prefs.getString(PROPERTY_REG_ID, "");
+    if (registrationId.length() == 0) {
+        Log.v(TAG, "Registration not found.");
+        return "";
+    }
+    // check if app was updated; if so, it must clear registration id to
+    // avoid a race condition if GCM sends a message
+    int registeredVersion = prefs.getInt(PROPERTY_APP_VERSION, Integer.MIN_VALUE);
+    int currentVersion = getAppVersion(context);
+    if (registeredVersion != currentVersion || isRegistrationExpired()) {
+        Log.v(TAG, "App version changed or registration expired.");
+        return "";
+    }
+    return registrationId;
+}
+
+...
+
+/**
+ * @return Application's {@code SharedPreferences}.
+ */
+private SharedPreferences getGCMPreferences(Context context) {
+    return getSharedPreferences(DemoActivity.class.getSimpleName(), 
+            Context.MODE_PRIVATE);
+}
    
+
+
    If the registration ID doesn't exist, or the app was updated, or the registration ID has expired, {@code getRegistrationId()} returns an empty string to indicate that the app needs to get a new regID. {@code getRegistrationId()} calls the following methods to check the app version and whether the regID has expired:
    
+
+
    /**
+ * @return Application's version code from the {@code PackageManager}.
+ */
+private static int getAppVersion(Context context) {
+    try {
+        PackageInfo packageInfo = context.getPackageManager()
+                .getPackageInfo(context.getPackageName(), 0);
+        return packageInfo.versionCode;
+    } catch (NameNotFoundException e) {
+        // should never happen
+        throw new RuntimeException("Could not get package name: " + e);
+    }
+}
+
+/**
+ * Checks if the registration has expired.
+ *
+ * <p>To avoid the scenario where the device sends the registration to the
+ * server but the server loses it, the app developer may choose to re-register
+ * after REGISTRATION_EXPIRY_TIME_MS.
+ *
+ * @return true if the registration has expired.
+ */
+private boolean isRegistrationExpired() {
+    final SharedPreferences prefs = getGCMPreferences(context);
+    // checks if the information is not stale
+    long expirationTime =
+            prefs.getLong(PROPERTY_ON_SERVER_EXPIRATION_TIME, -1);
+    return System.currentTimeMillis() > expirationTime;
+}
    
+
+
+
    If there isn't a valid existing registration ID, {@code DemoActivity} calls the following {@code registerBackground()} method to register. Note that because GCM methods are blocking, this has to take place on a background thread. This sample uses {@link android.os.AsyncTask} to accomplish this:
    
+
+
    +/**
+ * Registers the application with GCM servers asynchronously.
+ * <p>
+ * Stores the registration id, app versionCode, and expiration time in the 
+ * application's shared preferences.
+ */
+private void registerBackground() {
+    new AsyncTask() {
+        @Override
+        protected String doInBackground(Void... params) {
+            String msg = "";
+            try {
+                if (gcm == null) {
+                    gcm = GoogleCloudMessaging.getInstance(context);
+                }
+                regid = gcm.register(SENDER_ID);
+                msg = "Device registered, registration id=" + regid;
+
+                // You should send the registration ID to your server over HTTP,
+                // so it can use GCM/HTTP or CCS to send messages to your app.
+
+                // For this demo: we don't need to send it because the device
+                // will send upstream messages to a server that echo back the message
+                // using the 'from' address in the message.
+
+                // Save the regid - no need to register again.
+                setRegistrationId(context, regid);
+            } catch (IOException ex) {
+                msg = "Error :" + ex.getMessage();
+            }
+            return msg;
+        }
+
+        @Override
+        protected void onPostExecute(String msg) {
+            mDisplay.append(msg + "\n");
+        }
+    }.execute(null, null, null);
+}
    
+
+
    After registering, the app calls {@code setRegistrationId()} to store the registration ID in shared preferences for future use:
    
+
+
    /**
+ * Stores the registration id, app versionCode, and expiration time in the
+ * application's {@code SharedPreferences}.
+ *
+ * @param context application's context.
+ * @param regId registration id
+ */
+private void setRegistrationId(Context context, String regId) {
+    final SharedPreferences prefs = getGCMPreferences(context);
+    int appVersion = getAppVersion(context);
+    Log.v(TAG, "Saving regId on app version " + appVersion);
+    SharedPreferences.Editor editor = prefs.edit();
+    editor.putString(PROPERTY_REG_ID, regId);
+    editor.putInt(PROPERTY_APP_VERSION, appVersion);
+    long expirationTime = System.currentTimeMillis() + REGISTRATION_EXPIRY_TIME_MS;
+
+    Log.v(TAG, "Setting registration expiry time to " +
+            new Timestamp(expirationTime));
+    editor.putLong(PROPERTY_ON_SERVER_EXPIRATION_TIME, expirationTime);
+    editor.commit();
+}
    
+
+
    Sending a message
    
+
    When the user clicks the app's Send button, the app sends an upstream message using the new {@code GoogleCloudMessaging} APIs. In order to receive the upstream message, your server should be connected to CCS. You can use the code shown in Writing the Server Code as a sample XMPP client to connect to CCS.
    
+
+
    public void onClick(final View view) {
+    if (view == findViewById(R.id.send)) {
+        new AsyncTask() {
+            @Override
+            protected String doInBackground(Void... params) {
+                String msg = "";
+                try {
+                    Bundle data = new Bundle();
+                    data.putString("hello", "World");
+                    String id = Integer.toString(msgId.incrementAndGet());
+                    gcm.send(SENDER_ID + "@gcm.googleapis.com", id, data);
+                    msg = "Sent message";
+                } catch (IOException ex) {
+                    msg = "Error :" + ex.getMessage();
+                }
+                return msg;
+            }
+
+            @Override
+            protected void onPostExecute(String msg) {
+                mDisplay.append(msg + "\n");
+            }
+        }.execute(null, null, null);
+    } else if (view == findViewById(R.id.clear)) {
+        mDisplay.setText("");
+    } 
+}
    
+
+
    As described above in Step 1, the app includes a broadcast receiver for the com.google.android.c2dm.intent.RECEIVE intent. This is the mechanism GCM uses to deliver messages. When {@code onClick()} calls {@code gcm.send()}, it triggers the broadcast receiver's {@code onReceive()} method, which has the responsibility of handling the GCM message. In this sample the receiver's {@code onReceive()} method calls {@code sendNotification()} to put the message into a notification:
    
+
+
    /**
+ * Handling of GCM messages.
+ */
+public class GcmBroadcastReceiver extends BroadcastReceiver {
+    static final String TAG = "GCMDemo";
+    public static final int NOTIFICATION_ID = 1;
+    private NotificationManager mNotificationManager;
+    NotificationCompat.Builder builder;
+    Context ctx;
+    @Override
+    public void onReceive(Context context, Intent intent) {
+        GoogleCloudMessaging gcm = GoogleCloudMessaging.getInstance(context);
+        ctx = context;
+        String messageType = gcm.getMessageType(intent);
+        if (GoogleCloudMessaging.MESSAGE_TYPE_SEND_ERROR.equals(messageType)) {
+            sendNotification("Send error: " + intent.getExtras().toString());
+        } else if (GoogleCloudMessaging.MESSAGE_TYPE_DELETED.equals(messageType)) {
+            sendNotification("Deleted messages on server: " +
+                    intent.getExtras().toString());
+        } else {
+            sendNotification("Received: " + intent.getExtras().toString());
+        }
+        setResultCode(Activity.RESULT_OK);
+    }
+
+    // Put the GCM message into a notification and post it.
+    private void sendNotification(String msg) {
+        mNotificationManager = (NotificationManager)
+                ctx.getSystemService(Context.NOTIFICATION_SERVICE);
+
+        PendingIntent contentIntent = PendingIntent.getActivity(ctx, 0,
+                new Intent(ctx, DemoActivity.class), 0);
+
+        NotificationCompat.Builder mBuilder =
+                new NotificationCompat.Builder(ctx)
+        .setSmallIcon(R.drawable.ic_stat_gcm)
+        .setContentTitle("GCM Notification")
+        .setStyle(new NotificationCompat.BigTextStyle()
+        .bigText(msg))
+        .setContentText(msg);
+
+        mBuilder.setContentIntent(contentIntent);
+        mNotificationManager.notify(NOTIFICATION_ID, mBuilder.build());
+    }
+}
    
+
+
    Writing the Server Code
    
+
+
    Here is an example of a CCS server written in Python. You can use this in conjunction with the sample client code shown above. This sample echo server sends an initial message, and for every upstream message received, it sends a dummy response back to the application that sent the upstream message. This example illustrates how to connect,
+send, and receive GCM messages using XMPP. It shouldn't be used as-is
+on a production deployment. For examples of HTTP-based servers, see GCM Server.
    
+
+
    +#!/usr/bin/python
+import sys, json, xmpp, random, string
+
+SERVER = 'gcm.googleapis.com'
+PORT = 5235
+USERNAME = ''
+PASSWORD = ''
+REGISTRATION_ID = ''
+
+unacked_messages_quota = 1000
+send_queue = []
+
+# Return a random alphanumerical id
+def random_id():
+  rid = ''
+  for x in range(8): rid += random.choice(string.ascii_letters + string.digits)
+  return rid
+
+def message_callback(session, message):
+  global unacked_messages_quota
+  gcm = message.getTags('gcm')
+  if gcm:
+    gcm_json = gcm[0].getData()
+    msg = json.loads(gcm_json)
+    if not msg.has_key('message_type'):
+      # Acknowledge the incoming message immediately.
+      send({'to': msg['from'],
+            'message_type': 'ack',
+            'message_id': msg['message_id']})
+      # Queue a response back to the server.
+      if msg.has_key('from'):
+        # Send a dummy echo response back to the app that sent the upstream message.
+        send_queue.append({'to': msg['from'],
+                           'message_id': random_id(),
+                           'data': {'pong': 1}})
+    elif msg['message_type'] == 'ack' or msg['message_type'] == 'nack':
+      unacked_messages_quota += 1
+
+def send(json_dict):
+  template = ("<message><gcm xmlns='google:mobile:data'>{1}</gcm></message>")
+  client.send(xmpp.protocol.Message(
+      node=template.format(client.Bind.bound[0], json.dumps(json_dict))))
+
+def flush_queued_messages():
+  global unacked_messages_quota
+  while len(send_queue) and unacked_messages_quota > 0:
+    send(send_queue.pop(0))
+    unacked_messages_quota -= 1
+
+client = xmpp.Client('gcm.googleapis.com', debug=['socket'])
+client.connect(server=(SERVER,PORT), secure=1, use_srv=False)
+auth = client.auth(USERNAME, PASSWORD)
+if not auth:
+  print 'Authentication failed!'
+  sys.exit(1)
+
+client.RegisterHandler('message', message_callback)
+
+send_queue.append({'to': REGISTRATION_ID,
+                   'message_id': 'reg_id',
+                   'data': {'message_destination': 'RegId',
+                            'message_id': random_id()}})
+
+while True:
+  client.Process(1)
+  flush_queued_messages()
    
 
-
      
-  
    1. Decide which Google-provided GCM connection server you want to use—
-  HTTP or XMPP (CCS). GCM connection servers
-take messages from a 3rd-party application
-server (written by you) and send them to a GCM-enabled Android application (the
-"client app," also written by you) running on a device. 
      2. 
-  
    2. Implement an application server (the "3rd-party application server") to interact
-with your chosen GCM connection server. The app server sends data to a
-GCM-enabled Android client application via the GCM connection server. For more
-information about implementing the server side, see 
-Implementing GCM Server.
      3. 
-
    3. Write your client app. This is the GCM-enabled Android application that runs
-on a device. See Implementing GCM Client for more information.
      4. 
-
    
 
 
diff --git a/docs/html/google/gcm/http.jd b/docs/html/google/gcm/http.jd
deleted file mode 100644
index b8d8659d941e..000000000000
--- a/docs/html/google/gcm/http.jd
+++ /dev/null
@@ -1,618 +0,0 @@
-page.title=GCM HTTP Connection Server
-@jd:body
-
-
-
-
    This document describes the GCM HTTP connection server. Connection servers
-are the Google-provided servers that take messages from the 3rd-party
-application server and sending them to the device.
    
-
-
-
-
    Note: See
-Implementing GCM Server for a list of all the message
-parameters and which connection server(s) supports them.
    
-
-
-
    Authentication
    
-
-
    To send a  message, the application server issues a POST request to
-https://android.googleapis.com/gcm/send.
    
-
    A  message request is made of 2 parts: HTTP header and HTTP body.
    
-
-
    The HTTP header must contain the following headers:
    
-
-
-
    For example:
-
    
-
    Content-Type:application/json
-Authorization:key=AIzaSyB-1uEai2WiUapxCs2Q0GZYzPu7Udno5aA
-
-{
-  "registration_ids" : ["APA91bHun4MxP5egoKMwt2KZFBaFUH-1RYqx..."],
-  "data" : {
-    ...
-  },
-}
    
-
    
-  
    Note: If Content-Type is omitted, the format
-is assumed to be plain text.
    
-
    
-
-
    The HTTP body content depends on whether you're using JSON or plain text.
-See
-Implementing GCM Server for a list of all the
-parameters your JSON or plain text message can contain.
    
-
-
-  
    Request Format
    
-  
    Here is the smallest possible request (a message without any parameters and
-just one recipient) using JSON:
    
-  
    { "registration_ids": [ "42" ] }
    
-
-  
    And here the same example using plain text:
    
-  
    registration_id=42
    
-
-  
     Here is a message with a payload and 6 recipients:
    
-  
    { "data": {
-    "score": "5x1",
-    "time": "15:10"
-  },
-  "registration_ids": ["4", "8", "15", "16", "23", "42"]
-}
    
-  
    Here is a message with all optional fields set and 6 recipients:
    
-  
    { "collapse_key": "score_update",
-  "time_to_live": 108,
-  "delay_while_idle": true,
-  "data": {
-    "score": "4x8",
-    "time": "15:16.2342"
-  },
-  "registration_ids":["4", "8", "15", "16", "23", "42"]
-}
    
-  
    And here is the same message using plain-text format (but just 1 recipient):  
    
-
-  
    collapse_key=score_update&time_to_live=108&delay_while_idle=1&data.score=4x8&data.time=15:16.2342&registration_id=42
-  
    
-
-
    Note: If your organization has a firewall
-that restricts the traffic to or
-from the Internet, you need to configure it to allow connectivity with GCM in order for
-your Android devices to receive messages.
-The ports to open are: 5228, 5229, and 5230. GCM typically only uses 5228, but
-it sometimes uses 5229 and 5230. GCM doesn't provide specific IPs, so you should allow
-your firewall to accept outgoing connections to all IP addresses
-contained in the IP blocks listed in Google's ASN of 15169.
    
-
-
-
-
    Response format
    
-
-
    There are two possible outcomes when trying to send a message:
    
-
-
-
    When the message is processed successfully, the HTTP response has a 200 status
-and the body contains more information about the status of the message
-(including possible errors). When the request is rejected,
-the HTTP response contains a non-200 status code (such as 400, 401, or 503).
    
-
-
    The following table summarizes the statuses that the HTTP response header might
-contain. Click the troubleshoot link for advice on how to deal with each type of
-error.
    
-
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-
    ResponseDescription
    200Message was processed successfully. The response body will contain more
-details about the message status, but its format will depend whether the request
-was JSON or plain text. See Interpreting a success response
-for more details.
    400Only applies for JSON requests.
-Indicates that the request could not be parsed as JSON, or it contained invalid
-fields (for instance, passing a string where a number was expected). The exact
-failure reason is described in the response and the problem should be addressed
-before the request can be retried.
    401There was an error authenticating the sender account.
-Troubleshoot
    5xxErrors in the 500-599 range (such as 500 or 503) indicate that there wa
-an internal error in the GCM server while trying to process the request, or that
-the server is temporarily unavailable (for example, because of timeouts). Sender
-must retry later, honoring any Retry-After header included in the
-response. Application servers must implement exponential back-off.
-Troubleshoot
    
-
-
    Interpreting a success response
    
-
    When a JSON request is successful (HTTP status code 200), the response body
-contains a JSON object with the following fields:
    
-
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-
    FieldDescription
    multicast_idUnique ID (number) identifying the multicast message.
    successNumber of messages that were processed without an error.
    failureNumber of messages that could not be processed.
    canonical_idsNumber of results that contain a canonical registration ID. See
-Advanced Topics for more discussion of this topic.
    resultsArray of objects representing the status of the messages processed. The
-objects are listed in the same order as the request (i.e., for each registration
-ID in the request, its result is listed in the same index in the response) and
-they can have these fields:
    
-      
      
-        
    • message_id: String representing the message when it was
-successfully processed.
      • 
-        
    • registration_id: If set,  means that GCM processed the
-message but it has another canonical registration ID for that device, so sender
-should replace the IDs on future requests (otherwise they might be rejected).
-This field is never set if there is an error in the request.
-        
      • 
-        
    • error: String describing an error that occurred while
-processing the message for that recipient. The possible values are the same as
-documented in the above table, plus "Unavailable"  (meaning GCM servers
-were busy and could not process the message for that  particular recipient, so
-it could be retried).
      • 
-    
    
-
    If the value of failure and canonical_ids is 0, it's
-not necessary to parse the remainder of the response. Otherwise, we recommend
-that you iterate through the results field and do the following for each object
-in that list:
    
-
-
-
    When a plain-text request is successful (HTTP status code 200), the response
-body contains 1 or 2 lines in the form of key/value pairs.
-The first line is always available and its content is either id=ID of
-sent message or Error=GCM error code. The second
-line, if available,
-has the format of registration_id=canonical ID. The second
-line is optional, and it can only be sent if the first line is not an error. We
-recommend handling the plain-text response in a similar way as handling the
-JSON response:
    
-
-
-
    Interpreting an error response
    
-
    Here are the recommendations for handling the different types of error that
-might occur when trying to send a message to a device:
    
-
-
    
-
    Missing Registration ID
    
-
    Check that the request contains a registration ID (either in the
-registration_id parameter in a plain text message, or in the
-registration_ids field in JSON).
-
    Happens when error code is MissingRegistration.
    
-
-
    Invalid Registration ID
    
-
    Check the formatting of the registration ID that you pass to the server. Make
-sure it matches the registration ID the phone receives in the
-com.google.android.c2dm.intent.REGISTRATION intent and that you're
-not truncating it or adding additional characters.
-
    Happens when error code is InvalidRegistration.
    
-
-
    Mismatched Sender
    
-
    A registration ID is tied to a certain group of senders. When an application
-registers for GCM usage, it must specify which senders are allowed to send messages.
-Make sure you're using one of those when trying to send messages to the device.
-If you switch to a different sender, the existing registration IDs won't work.
-Happens when error code is MismatchSenderId.
    
-
-
    Unregistered Device
    
-
    An existing registration ID may cease to be valid in a number of scenarios, including:
-
      
-  
    • If the application manually unregisters by issuing a
-
-com.google.android.c2dm.intent.UNREGISTER
-intent.
      • 
-  
    • If the application is automatically unregistered, which can happen
-(but is not guaranteed) if the user uninstalls the application.
      • 
-  
    • If the registration ID expires. Google might decide to refresh registration
-IDs. 
      • 
-  
    • If the application is updated but the new version does not have a broadcast
-receiver configured to receive com.google.android.c2dm.intent.RECEIVE
-intents.
      • 
-
    
-For all these cases, you should remove this registration ID from the 3rd-party
-server and stop using it to send
-messages.
-
    Happens when error code is NotRegistered.
    
-
-
    Message Too Big
    
-  
    The total size of the payload data that is included in a message can't
-exceed 4096 bytes. Note that this includes both the size of the keys as well
-as the values.
-
    Happens when error code is MessageTooBig.
    
-
-
    Invalid Data Key
    
-
    The payload data contains a key (such as from or any value
-prefixed by google.) that is used internally by GCM in the
-com.google.android.c2dm.intent.RECEIVE Intent and cannot be used.
-Note that some words (such as collapse_key) are also used by GCM
-but are allowed in the payload, in which case the payload value will be
-overridden by the GCM value.
-
    
-Happens when the error code is InvalidDataKey.
    
-
-
    Invalid Time To Live
    
-  
    The value for the Time to Live field must be an integer representing
-a duration in seconds between 0 and 2,419,200 (4 weeks). Happens when error code
-is InvalidTtl.
-
    
-
-  
    Authentication Error
    
-  
    The sender account that you're trying to use to send a message couldn't be
-authenticated. Possible causes are: 
      
-
    • Authorization header missing or with invalid syntax.
      • 
-
    • Invalid project number sent as key.
      • 
-
    • Key valid but with GCM service disabled.
      • 
-
    • Request originated from a server not whitelisted in the Server Key IPs.
      • 
-
-
    
-Check that the token you're sending inside the Authorization header
-is the correct API key associated with your project. You can check the validity
-of your API key by running the following command:
    
-
-
    # api_key=YOUR_API_KEY
-
-# curl --header "Authorization: key=$api_key" --header Content-Type:"application/json" https://android.googleapis.com/gcm/send  -d "{\"registration_ids\":[\"ABC\"]}"
    
-
-
-
-If you receive a 401 HTTP status code, your API key is not valid. Otherwise you
-should see something like this:
    
-
-
    -{"multicast_id":6782339717028231855,"success":0,"failure":1,"canonical_ids":0,"results":[{"error":"InvalidRegistration"}]}
-
    
-If you want to confirm the validity of a registration ID, you can do so by
-replacing "ABC" with the registration ID.
-
    
-Happens when the HTTP status code is 401.
-
-  
    Timeout
    
-
-
    The server couldn't process the request in time. You should retry the
-same request, but you MUST obey the following requirements:
-
-
      
-
-
    • Honor the Retry-After header if it's included in the response
-from the GCM server.
      • 
-
-
-
    • Implement exponential back-off in your retry mechanism. This means an
-exponentially increasing delay after each failed retry (e.g. if you waited one
-second before the first retry, wait at least two second before the next one,
-then 4 seconds and so on). If you're sending multiple messages, delay each one
-independently by an additional random amount to avoid issuing a new request for
-all messages at the same time.
      • 
-
-
-Senders that cause problems risk being blacklisted.
-
      
-Happens when the HTTP status code is between 501 and 599, or when the
-error field of a JSON object in the results array is Unavailable.
-
    
-
-
    Internal Server Error
    
-
-
    
-The server encountered an error while trying to process the request. You
-could retry the same request (obeying the requirements listed in the Timeout
-section), but if the error persists, please report the problem in the
-android-gcm group.
-
    
-Happens when the HTTP status code is 500, or when the error field of a JSON
-object in the results array is InternalServerError.
-
    
-
-
    Invalid Package Name
    
-
-
    
-A message was addressed to a registration ID whose package name did not match
-the value passed in the request. Happens when error code is
-InvalidPackageName.
-
    
-
    
-
-
    Example responses
    
-
    This section shows a few examples of responses indicating messages that were
-processed successfully. See Request Format for
-the requests these responses are based on.
    
-
     Here is a simple case of a JSON message successfully sent to one recipient
-without canonical IDs in the response:
    
-
    { "multicast_id": 108,
-  "success": 1,
-  "failure": 0,
-  "canonical_ids": 0,
-  "results": [
-    { "message_id": "1:08" }
-  ]
-}
    
-
-
    Or if the request was in plain-text format:
    
-
    id=1:08
-
    
-
-
    Here are JSON results for 6 recipients (IDs 4, 8, 15, 16, 23, and 42 respectively)
-with 3 messages successfully processed, 1 canonical registration ID returned,
-and 3 errors:
    
-
    { "multicast_id": 216,
-  "success": 3,
-  "failure": 3,
-  "canonical_ids": 1,
-  "results": [
-    { "message_id": "1:0408" },
-    { "error": "Unavailable" },
-    { "error": "InvalidRegistration" },
-    { "message_id": "1:1516" },
-    { "message_id": "1:2342", "registration_id": "32" },
-    { "error": "NotRegistered"}
-  ]
-}
-
    
-
     In this example:
    
-
-
    Or if just the 4th message above was sent using plain-text format:
    
-
    Error=InvalidRegistration
-
    
-
    If the 5th message above was also sent using plain-text format:
    
-
    id=1:2342
-registration_id=32
-
    
-
-
-
    Implementing an HTTP-Based App Server
    
-
-
    This section gives examples of implementing an app server that works with the
-GCM HTTP connection server. Note that a full GCM implementation requires a
-client-side implementation, in addition to the server.
-
-
-
    Requirements
    
-
    For the web server:
    
-
-
    For the Android application:
    
-
-
-
    Setting Up GCM
    
-
    Before proceeding with the server and client setup, it's necessary to register
-a Google account with the Google API Console, enable Google Cloud Messaging in GCM,
-and obtain an API key from the 
-Google API Console.
    
-
    For instructions on how to set up GCM, see Getting Started.
    
-
-
-
    Setting Up an HTTP Server
    
-
    This section describes the different options for setting up an HTTP server.
    
-
-
    Using a standard web server
    
-
    To set up the server using a standard, servlet-compliant web server:
    
-
      
-  
    1. From the open source site,
-download the following directories: gcm-server,
-samples/gcm-demo-server, and samples/gcm-demo-appengine.
      
-
-
-  
    2. In a text editor, edit the samples/gcm-demo-server/WebContent/WEB-INF/classes/api.key and replace the existing text with the API key obtained above.
      3. 
-  
    3. In a shell window, go to the samples/gcm-demo-server directory.
      4. 
-  
    4. Generate the server's WAR file by running ant war:
      5. 
-
-  
      $ ant war
-
-Buildfile:build.xml
-
-init:
-   [mkdir] Created dir: build/classes
-   [mkdir] Created dir: dist
-
-compile:
-   [javac] Compiling 6 source files to build/classes
-
-war:
-     [war] Building war: dist/gcm-demo.war
-
-BUILD SUCCESSFUL
-Total time: 0 seconds
-
      
-
-  
    5. Deploy the dist/gcm-demo.war to your running server. For instance, if you're using Jetty, copy gcm-demo.war to the webapps directory of the Jetty installation.
      6. 
-  
    6. Open the server's main page in a browser. The URL depends on the server you're using and your machine's IP address, but it will be something like http://192.168.1.10:8080/gcm-demo/home, where gcm-demo is the application context and /home is the path of the main servlet.
-
-  
      7. 
-
    
-
    Note: You can get the IP by running ifconfig on Linux or MacOS, or ipconfig on Windows. 
    
-
-
     You server is now ready.
    
-
-
    Using App Engine for Java
    
-
-
    To set up the server using a standard App Engine for Java:
    
-
      
-  
    1. Get the files from the open source
-site, as described above.
      
-  
      2. 
-  
    2. In a text editor, edit
-samples/gcm-demo-appengine/src/com/google/android/gcm/demo/server/ApiKeyInitializer.java
-and replace the existing text with the API key obtained above.
-
-  
      Note: The API key value set in that class will
-be used just once to create a persistent entity on App Engine. If you deploy
-the application, you can use App Engine's Datastore Viewer to change
-it later.
      
-
-  
      3. 
-  
    3. In a shell window, go to the samples/gcm-demo-appengine directory.
      4. 
-  
    4. Start the development App Engine server by ant runserver,
-using the -Dsdk.dir to indicate the location of the App Engine SDK
-and -Dserver.host to set your server's hostname or IP address:
      5. 
-
-
      -$ ant -Dsdk.dir=/opt/google/appengine-java-sdk runserver -Dserver.host=192.168.1.10
-Buildfile: gcm-demo-appengine/build.xml
-
-init:
-    [mkdir] Created dir: gcm-demo-appengine/dist
-
-copyjars:
-
-compile:
-
-datanucleusenhance:
-  [enhance] DataNucleus Enhancer (version 1.1.4) : Enhancement of classes
-  [enhance] DataNucleus Enhancer completed with success for 0 classes. Timings : input=28 ms, enhance=0 ms, total=28 ms. Consult the log for full details
-  [enhance] DataNucleus Enhancer completed and no classes were enhanced. Consult the log for full details
-
-runserver:
-     [java] Jun 15, 2012 8:46:06 PM com.google.apphosting.utils.jetty.JettyLogger info
-     [java] INFO: Logging to JettyLogger(null) via com.google.apphosting.utils.jetty.JettyLogger
-     [java] Jun 15, 2012 8:46:06 PM com.google.apphosting.utils.config.AppEngineWebXmlReader readAppEngineWebXml
-     [java] INFO: Successfully processed gcm-demo-appengine/WebContent/WEB-INF/appengine-web.xml
-     [java] Jun 15, 2012 8:46:06 PM com.google.apphosting.utils.config.AbstractConfigXmlReader readConfigXml
-     [java] INFO: Successfully processed gcm-demo-appengine/WebContent/WEB-INF/web.xml
-     [java] Jun 15, 2012 8:46:09 PM com.google.android.gcm.demo.server.ApiKeyInitializer contextInitialized
-     [java] SEVERE: Created fake key. Please go to App Engine admin console, change its value to your API Key (the entity type is 'Settings' and its field to be changed is 'ApiKey'), then restart the server!
-     [java] Jun 15, 2012 8:46:09 PM com.google.appengine.tools.development.DevAppServerImpl start
-     [java] INFO: The server is running at http://192.168.1.10:8080/
-     [java] Jun 15, 2012 8:46:09 PM com.google.appengine.tools.development.DevAppServerImpl start
-     [java] INFO: The admin console is running at http://192.168.1.10:8080/_ah/admin
-
      
-
-  
    5. Open the server's main page in a browser. The URL depends on the server
-you're using and your machine's IP address, but it will be something like
-http://192.168.1.10:8080/home, where /home
-is the path of the main servlet.
      6. 
-
-  
      Note: You can get the IP by running ifconfig
-on Linux or MacOS, or ipconfig on Windows.
      
-
-
    
-
     You server is now ready.
    
diff --git a/docs/html/google/gcm/notifications.jd b/docs/html/google/gcm/notifications.jd
index 4b5a78c059ee..df171cfea52d 100644
--- a/docs/html/google/gcm/notifications.jd
+++ b/docs/html/google/gcm/notifications.jd
@@ -14,15 +14,14 @@ page.title=User Notifications
 
    In this document
    
 
 
      
-  
    1. Request Format
      2. 
-  
    2. Generate a Notification Key
      3. 
-  
    3. Add Registration IDs
      4. 
-  
    4. Remove Registration IDs
      5. 
-  
    5. Send Upstream Messages
      6. 
-  
    6. Response Formats
-    
        
-      
      1. Create/add/remove operations
-      
      2. Send operations
+  
      3. What are User Notifications? 
        4. 
+  
      4. Examples
+    
          
+      
        1. Generate a notification key
          2. 
+      
        2. Add registration IDs
          3. 
+      
        3. Remove registration IDs
          4. 
+      
        4. Send upstream messages
          5. 
+      
        5. Response formats
          6. 
     
        
   
        5. 
 
      
@@ -39,51 +38,32 @@ page.title=User Notifications
 
 
      Note: To try out this feature, sign up using this form.
      
 
+
      The upstream messaging (device-to-cloud) feature described in this document is part of the Google Play services platform. Upstream messaging is available through the GoogleCloudMessaging APIs. To use upstream messaging and the new streamlined registration process, you must set up the Google Play services SDK.
      
 
-
      With user notifications, 3rd-party app servers can send a single message to
-multiple instance of an app running on devices owned by a single user. This feature
-is called user notifications. User notifications make it possible for every
-app instance that a user owns to reflect the latest messaging state. For example:
      
+
      What are User Notifications?
      
 
-  
        
-  
      • If a message has been handled on one device, the GCM message on the other
-devices are dismissed. For example, if a user has handled a calendar notification
-on one device, the notification will go away on the user's other devices.
        • 
-
-  
      • If a message has not been delivered yet to a device and but it has been handled,
-the GCM server removes it from the unsent queue for the other devices.
        • 
+
        Third party servers can send a single message to multiple instance of an app running on devices owned by a single user. This feature is called user notifications. User notifications make it possible for every app instance that a user owns to reflect the latest messaging state. For example:
        
 
-  
      • Likewise, a device can send messages to the {@code notification_key}, which
-is the token that GCM uses to fan out notifications to all devices whose
-registration IDs are associated with the key.
        • 
+  
          
+  
        • If a message has been handled on one device, the GCM message on the other devices are dismissed. For example, if a user has handled a calendar notification on one device, the notification will go away on the user's other devices.
          • 
+  
        • If a message has not been delivered yet to a device and but it has been handled, the GCM server removes it from the unsent queue for the other devices.
          • 
+  
        • Likewise, a device can send messages to the {@code notification_key}, which is the token that GCM uses to fan out notifications to all devices whose registration IDs are associated with the key.
          • 
 
        
 
-
        The way this works is that during registration, the 3rd-party server requests
-a {@code notification_key}. The {@code notification_key} maps a particular user
-to all of the user's associated registration IDs (a regID represents a particular
-Android application running on a particular device). Then instead of sending one
-message to one regID at a time, the 3rd-party server can send a message to to the
-{@code notification_key}, which then sends the message to all of the user's regIDs.
        
-
-
        Note: A notification dismissal message is like any
-other upstream message, meaning that it will be delivered to the other devices that
-belong to the specified {@code notification_key}. You should design your app to
-handle cases where the app receives a dismissal message, but has not yet displayed
-the notification that is being dismissed. You can solve this by caching the dismissal
-and then reconciling it with the corresponding notification.
+
        The way this works is that during registration, the 3rd-party server requests a {@code notification_key}. The {@code notification_key} maps a particular user to all of the user's associated registration IDs (a regID represents a particular Android application running on a particular device). Then instead of sending one message to one regID at a time, the 3rd-party server can send a message to to the {@code notification_key}, which then sends the message to all of the user's regIDs.
        
+
+
        Note: A notification dismissal message is like any other upstream message, meaning that it will be delivered to the other devices that belong to the specified {@code notification_key}. You should design your app to handle cases where the app receives a dismissal message, but has not yet displayed the notification that is being dismissed. You can solve this by caching the dismissal and then reconciling it with the corresponding notification.
 
        
 
-
        You can use this feature with either the XMPP (CCS) or
-HTTP connection server.
        
+
        You can use this feature with either the new GCM Cloud Connection Server (CCS), or the older GCM HTTP server.
        
+
 
+
        Examples
        
 
-
        The examples below show you how to perform generate/add/remove operations,
-and how to send upstream messages. For generate/add/remove operations, the
-message body is JSON.
        
+
        The examples in this section show you how to perform generate/add/remove operations, and how to send upstream messages. For generate/add/remove operations, the message body is JSON.
        
 
-
        Request Format
        
-
        To send a  message, the application server issues a POST request to
-https://android.googleapis.com/gcm/notification.
        
+
        Request format
        
+
        To send a  message, the application server issues a POST request to https://android.googleapis.com/gcm/notification.
        
 
 
        Here is the HTTP request header you should use for all create/add/remove operations:
        
 
@@ -92,22 +72,12 @@ Header : "project_id": <projectID>
 Header: "Authorization", "key=API_KEY"
    -

    Generate a Notification Key

    +

    Generate a notification key

    -

    This example shows how to create a new notification_key for a -notification_key_name called appUser-Chris. -The {@code notification_key_name} is a name or identifier (can be a username for -a 3rd-party app) that is unique to a given user. It is used by third parties to -group together registration IDs for a single user. Note that notification_key_name -and notification_key are unique to a group of registration IDs. It is also -important that notification_key_name be uniquely named per app in case -you have multiple apps for the same project ID. This ensures that notifications -only go to the intended target app.

    +

    This example shows how to create a new notification_key for a notification_key_name called appUser-Chris. The {@code notification_key_name} is a name or identifier (can be a username for a 3rd-party app) that is unique to a given user. It is used by third parties to group together registration IDs for a single user. Note that notification_key_name and notification_key are unique to a group of registration IDs. It is also important that notification_key_name be uniquely named per app in case you have multiple apps for the same project ID. This ensures that notifications only go to the intended target app.

    -

    A create operation returns a token (notification_key). Third parties -must save this token (as well as its mapping to the notification_key_name) -to use in subsequent operations:

    +

    A create operation returns a token (notification_key). Third parties must save this token (as well as its mapping to the notification_key_name) to use in subsequent operations:

    request:
 { 
@@ -116,14 +86,11 @@ to use in subsequent operations:
    
    "registration_ids": ["4", "8", "15", "16", "23", "42"]
 }
    -

    Add Registration IDs

    +

    Add registration IDs

    -

    This example shows how to add registration IDs for a given notification key. -The maximum number of members allowed for a {@code notification_key} is 10.

    +

    This example shows how to add registration IDs for a given notification key. The maximum number of members allowed for a {@code notification_key} is 10.

    -

    Note that the notification_key_name is not strictly required for -adding/removing regIDs. But including it protects you against accidentally using -the incorrect notification_key.

    +

    Note that the notification_key_name is not strictly required for adding/removing regIDs. But including it protects you against accidentally using the incorrect notification_key.

    request:
 { 
@@ -133,7 +100,7 @@ the incorrect notification_key.
    
    "registration_ids": ["4", "8", "15", "16", "23", "42"]
 }
    -

    Remove Registration IDs

    +

    Remove registration IDs

    This example shows how to remove registration IDs for a given notification key:

    request:
@@ -144,14 +111,9 @@ the incorrect notification_key.
    
    "registration_ids": ["4", "8", "15", "16", "23", "42"]
 }
    -

    Send Upstream Messages

    +

    Send upstream messages

    -

    To send an upstream (device-to-cloud) message, you must use the - -{@code GoogleCloudMessaging} API. Specifying a {@code notification_key} as the target -for an upstream message allows a user on one device to send a message to other -devices in the notification group—for example, to dismiss a notification. -Here is an example that shows targeting a {@code notification_key}:

    +

    To send an upstream (device-to-cloud) message, you must use the GoogleCloudMessaging API. Specifying a {@code notification_key} as the target for an upstream message allows a user on one device to send a message to other devices in the notification group—for example, to dismiss a notification. Here is an example that shows targeting a {@code notification_key}:

    GoogleCloudMessaging gcm = GoogleCloudMessaging.get(context);
 String to = NOTIFICATION_KEY;
@@ -163,21 +125,17 @@ data.putString("hello", "world");
 gcm.send(to, id, data);
    -

    This call generates the necessary XMPP stanza for sending the message. The -Bundle data consists of a key-value pair.

    +

    This call generates the necessary XMPP stanza for sending the message. The Bundle data consists of a key-value pair.

    -

    For a complete example, see Implementing GCM Client. +

    For a complete example, see Getting Started. -

    Response Formats

    +

    Response formats

    -

    This section shows examples of the responses that can be returned for -notification key operations.

    +

    This section shows examples of the responses that can be returned for notification key operations.

    -

    Create/add/remove operations

    +
    Response for create/add/remove operations
    -

    When you make a request to create a {@code notification_key} or to add/remove its -regIDs, a successful response always returns the notification_key. -his is the {@code notification_key} you will use for sending messages:

    +

    When you make a request to create a {@code notification_key} or to add/remove its the wayregIDs, a successful response always returns the notification_key. This is the {@code notification_key} you will use for sending messages:

    HTTP status: 200
 { 
@@ -185,23 +143,18 @@ his is the {@code notification_key} you will use for sending messages:
    
 }
    -

    Send operations

    +
    Response for send operations
    -

    For a send operation that has a {@code notification_key} as its target, the -possible responses are success, partial success, and failure.

    +

    For a send operation that has a {@code notification_key} as its target, the possible responses are success, partial success, and failure.

    -

    Here is an example of "success"—the {@code notification_key} has 2 regIDs -associated with it, and the message was successfully sent to both of them:

    +

    Here is an example of "success"—the {@code notification_key} has 2 regIDs associated with it, and the message was successfully sent to both of them:

    {
   "success": 2,
   "failure": 0
 }
    -

    Here is an example of "partial success"—the {@code notification_key} has -3 regIDs associated with it. The message was successfully send to 1 of the regIDs, -but not to the other 2. The response message lists the regIDs that failed to -receive the message:

    +

    Here is an example of "partial success"—the {@code notification_key} has 3 regIDs associated with it. The message was successfully send to 1 of the regIDs, but not to the other 2. The response message lists the regIDs that failed to receive the message:

    {
   "success":1,
@@ -212,9 +165,7 @@ receive the message:
    
   ]
 }
    -

    In the case of failure, the response has HTTP code 503 and no JSON. When a message -fails to be delivered to one or more of the regIDs associated with a {@code notification_key}, -the 3rd-party server should retry.

    +

    In the case of failure, the response has HTTP code 503 and no JSON. When a message fails to be delivered to one or more of the regIDs associated with a {@code notification_key}, the 3rd-party server should retry.

    diff --git a/docs/html/google/gcm/server.jd b/docs/html/google/gcm/server.jd index b5e6b480d057..92a1531cdbb4 100644 --- a/docs/html/google/gcm/server.jd +++ b/docs/html/google/gcm/server.jd @@ -1,34 +1,36 @@ -page.title=Implementing GCM Server +page.title=GCM Server @jd:body
    -

    The server side of GCM consists of 2 components:

    - -

    -

    Here are the basic steps you follow to implement your 3rd-party app server:

    +

    This document gives examples of GCM server-side code for HTTP. For an example of an XMPP server (Cloud Connection Server), see Getting Started. Note that a full GCM implementation requires a client-side implementation, in addition to the server. For a complete working example that includes client and server-side code, see Getting Started. + +

    Requirements

    +

    For the web server:

    +

    For the Android application:

    + +

    Setting Up GCM

    +

    Before proceeding with the server and client setup, it's necessary to register a Google account with the Google API Console, enable Google Cloud Messaging in GCM, and obtain an API key from the Google API Console.

    +

    For instructions on how to set up GCM, see Getting Started.

    -

    A full GCM implementation requires both a client implementation and a server -implementation. For more -information about implementing the client side, see -Implementing GCM Client.

    -

    Choosing a GCM Connection Server

    +

    Setting Up an HTTP Server

    +

    This section describes the different options for setting up an HTTP server.

    +

    Using a standard web server

    +

    To set up the server using a standard, servlet-compliant web server:

    +
      +
    1. From the open source site, download the following directories: gcm-server, samples/gcm-demo-server, and samples/gcm-demo-appengine.

      -

      Currently GCM provides two connection servers: -HTTP and CCS (XMPP). You can use them -separately or in tandem. CCS messaging differs from GCM HTTP messaging in the following ways:

      -
        -
      • Upstream/Downstream messages -
          -
        • GCM HTTP: Downstream only: cloud-to-device.
          • -
        • CCS: Upstream and downstream (device-to-cloud, cloud-to-device).
          • -
        -
        • -
      • Asynchronous messaging -
          -
        • GCM HTTP: 3rd-party app servers send messages as HTTP POST requests and -wait for a response. This mechanism is synchronous and causes the sender to block -before sending another message.
          • -
        • CCS: 3rd-party app servers connect to Google infrastructure using a -persistent XMPP connection and send/receive messages to/from all their devices -at full line speed. CCS sends acknowledgment or failure notifications (in the -form of special ACK and NACK JSON-encoded XMPP messages) asynchronously.
          • -
        -
        • -
      • JSON -
          -
        • GCM HTTP: JSON messages sent as HTTP POST.
          • -
        • CCS: JSON messages encapsulated in XMPP messages.
          • -
        -
        • -
      +
    2. In a text editor, edit the samples/gcm-demo-server/WebContent/WEB-INF/classes/api.key and replace the existing text with the API key obtained above.
      3. +
    3. In a shell window, go to the samples/gcm-demo-server directory.
      4. +
    4. Generate the server's WAR file by running ant war:
      5. + + 
      $ ant war
 
-
      Role of the 3rd-party Application Server
      
+Buildfile:build.xml
 
-
      Before you can write client Android applications that use the GCM feature, you must
-have an  application server that meets the following criteria:
      
+init:
+   [mkdir] Created dir: build/classes
+   [mkdir] Created dir: dist
 
-
        
-  
      • Able to communicate with your client.
        • 
-  
      • Able to  fire off properly formatted requests to the GCM server.
        • 
-  
      • Able to handle requests and resend them as needed, using
-exponential back-off.
        • 
-  
      • Able to store the API key and client registration IDs. The
-API key is included in the header of POST requests that send
-messages.
        • 
- 
      • Able to store the API key and client registration IDs.
        • 
- 
      • Able to generate message IDs to uniquely identify each message it sends.
        • 
-
      
+compile:
+   [javac] Compiling 6 source files to build/classes
 
-
      Sending Messages
      
+war:
+     [war] Building war: dist/gcm-demo.war
 
-
      Here is the general sequence of events that occurs when a 3rd-party application
-server sends a message:
      
-
        
-  
      1. The application server sends a message to GCM servers.
        2. 
-  
      2. Google enqueues and stores the message in case the device is offline.
        3. 
-  
      3. When the device is online, Google sends the message to the device.
        4. 
-  
      4. On the device, the system broadcasts the message to the specified Android
-application via Intent broadcast with proper permissions, so that only the targeted
-ndroid application gets the message. This wakes the Android application up.
-The Android application does not need to be running beforehand to receive the message.
        5. 
-  
      5. The Android application processes the message. 
        6. 
+BUILD SUCCESSFUL
+Total time: 0 seconds
+
      + +
    5. Deploy the dist/gcm-demo.war to your running server. For instance, if you're using Jetty, copy gcm-demo.war to the webapps directory of the Jetty installation.
      6. +
    6. Open the server's main page in a browser. The URL depends on the server you're using and your machine's IP address, but it will be something like http://192.168.1.10:8080/gcm-demo/home, where gcm-demo is the application context and /home is the path of the main servlet. + +
    +

    Note: You can get the IP by running ifconfig on Linux or MacOS, or ipconfig on Windows.

    -

    The following sections describe the basic requirements for -sending messages.

    +

    You server is now ready.

    -

    Target

    -

    Required. When your app server sends a message in GCM, it must specify a target.

    -

    For HTTP you must specify the target as one of:

    - -

    For CCS (XMPP):

    - -

    Payload

    -

    Optional. If you are including a payload in the message, you use the data -parameter to include the payload. This applies for both HTTP and CCS.

    - -

    Message parameters

    - -

    The following table lists the parameters that a 3rd-party app server might -include in the JSON messages it sends to a connection server. See the "Where Supported" -column for information about which connection servers support that particular -parameter.

    - -

    - Table 1. Message parameters.

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    FieldDescriptionWhere Supported
    toIn CCS, used in place of registration_ids to specify the -recipient of a message. Its value must be a registration ID. -The value is a string. Required.CCS
    message_idIn CCS, uniquely identifies a message in an XMPP connection. The value is a -string that uniquely identifies the associated message. The value is a string. Required.CCS
    message_typeIn CCS, indicates a special status message, typically sent by the system. -However, your app server also uses this parameter to send an 'ack' or 'nack' -message back to the CCS connection server. For more discussion of this topic, see -Cloud Connection Server. The value is a string. Optional.CCS
    registration_idsA string array with the list of devices (registration IDs) receiving the -message. It must contain at least 1 and at most 1000 registration IDs. To send a -multicast message, you must use JSON. For sending a single message to a single -device, you could use a JSON object with just 1 registration id, or plain text -(see below). A request must include a recipient—this can be either a -registration ID, an array of registration IDs, or a {@code notification_key}. -Required.HTTP
    notification_keyA string that maps a single user to multiple registration IDs associated -with that user. This allows a 3rd-party server to send a single message to -multiple app instances (typically on multiple devices) owned by a single user. -A 3rd-party server can use {@code notification_key} as the target for a message -instead of an individual registration ID (or array of registration IDs). The maximum -number of members allowed for a {@code notification_key} is 10. For more discussion -of this topic, see User Notifications. Optional. -HTTP. This feature is supported in CCS, but you use it by -specifying a notification key in the "to" field.
    collapse_keyAn arbitrary string (such as "Updates Available") that is used -to collapse a group of like messages -when the device is offline, so that only the last message gets sent to the -client. This is intended to avoid sending too many messages to the phone when it -comes back online. Note that since there is no guarantee of the order in which -messages get sent, the "last" message may not actually be the last -message sent by the application server. Collapse keys are also called -send-to-sync messages. -
    -Note: GCM allows a maximum of 4 different collapse keys to be -used by the GCM server -at any given time. In other words, the GCM server can simultaneously store 4 -different send-to-sync messages per device, each with a different collapse key. -If you exceed -this number GCM will only keep 4 collapse keys, with no guarantees about which -ones they will be. See Advanced Topics for more -discussion of this topic. Optional.    		CCS, HTTP
    dataA JSON object whose fields represents the key-value pairs of the message's -payload data. If present, the payload data it will be -included in the Intent as application data, with the key being the extra's name. -For instance, "data":{"score":"3x1"} would result in an intent extra -named score whose value is the string 3x1. -There is no limit on the number of key/value pairs, though there is a limit on -the total size of the message (4kb). The values could be any JSON object, but we -recommend using strings, since the values will be converted to strings in the GCM -server anyway. If you want to include objects or other non-string data types -(such as integers or booleans), you have to do the conversion to string yourself. -Also note that the key cannot be a reserved word (from or any word -starting with google.). To complicate things slightly, there are -some reserved words (such as collapse_key) that are technically -allowed in payload data. However, if the request also contains the word, the -value in the request will overwrite the value in the payload data. Hence using -words that are defined as field names in this table is not recommended, even in -cases where they are technically allowed. Optional.CCS, HTTP
    delay_while_idleIf included, indicates that the message should not be sent immediately -if the device is idle. The server will wait for the device to become active, and -then only the last message for each collapse_key value will be -sent. The default value is false, and must be a JSON boolean. Optional.CCS, HTTP
    time_to_liveHow long (in seconds) the message should be kept on GCM storage if the -device is offline. Optional (default time-to-live is 4 weeks, and must be set as -a JSON number).CCS, HTTP
    restricted_package_nameA string containing the package name of your application. When set, messages -will only be sent to registration IDs that match the package name. Optional. - HTTP
    dry_runIf included, allows developers to test their request without actually -sending a message. Optional. The default value is false, and must -be a JSON boolean. - HTTP
    - -

    If you want to test your request (either JSON or plain text) without delivering -the message to the devices, you can set an optional HTTP or JSON parameter called -dry_run with the value true. The result will be almost -identical to running the request without this parameter, except that the message -will not be delivered to the devices. Consequently, the response will contain fake -IDs for the message and multicast fields.

    - -

    Plain text (HTTP only)

    - -

    If you are using plain text instead of JSON, the message fields must be set as -HTTP parameters sent in the body, and their syntax is slightly different, as -described below: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    FieldDescription
    registration_idMust contain the registration ID of the single device receiving the message. -Required.
    collapse_keySame as JSON (see previous table). Optional.
    data.<key>Payload data, expressed as parameters prefixed with data. and -suffixed as the key. For instance, a parameter of data.score=3x1 would -result in an intent extra named score whose value is the string -3x1. There is no limit on the number of key/value parameters, though -there is a limit on the total size of the message. Also note that the key cannot -be a reserved word (from or any word starting with -google.). To complicate things slightly, there are some reserved words -(such as collapse_key) that are technically allowed in payload data. -However, if the request also contains the word, the value in the request will -overwrite the value in the payload data. Hence using words that are defined as -field names in this table is not recommended, even in cases where they are -technically allowed. Optional.
    delay_while_idleShould be represented as 1 or true for -true, anything else for false. Optional. The default -value is false.
    time_to_liveSame as JSON (see previous table). Optional.
    restricted_package_nameSame as JSON (see previous table). Optional. -
    dry_runSame as JSON (see previous table). Optional. -
    - -

    Receiving Messages

    - -

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

    +

    Using App Engine for Java

    +

    To set up the server using a standard App Engine for Java:

      -
    1. The system receives the incoming message and extracts the raw key/value -pairs from the message payload, if any.
      2. -
    2. The system passes the key/value pairs to the targeted Android application -in a com.google.android.c2dm.intent.RECEIVE Intent as a set of -extras.
      3. -
    3. The Android application extracts the raw data -from the com.google.android.c2dm.intent.RECEIVE Intent -by key and processes the data.
      4. +
    4. Get the files from the open source site, as described above.

      +
      5. +
    5. In a text editor, edit samples/gcm-demo-appengine/src/com/google/android/gcm/demo/server/ApiKeyInitializer.java and replace the existing text with the API key obtained above. + +

      Note: The API key value set in that class will be used just once to create a persistent entity on App Engine. If you deploy the application, you can use App Engine's Datastore Viewer to change it later.

      + +
      6. +
    6. In a shell window, go to the samples/gcm-demo-appengine directory.
      7. +
    7. Start the development App Engine server by ant runserver, using the -Dsdk.dir to indicate the location of the App Engine SDK and -Dserver.host to set your server's hostname or IP address:
      8. + +
      +$ ant -Dsdk.dir=/opt/google/appengine-java-sdk runserver -Dserver.host=192.168.1.10
+Buildfile: gcm-demo-appengine/build.xml
+
+init:
+    [mkdir] Created dir: gcm-demo-appengine/dist
+
+copyjars:
+
+compile:
+
+datanucleusenhance:
+  [enhance] DataNucleus Enhancer (version 1.1.4) : Enhancement of classes
+  [enhance] DataNucleus Enhancer completed with success for 0 classes. Timings : input=28 ms, enhance=0 ms, total=28 ms. Consult the log for full details
+  [enhance] DataNucleus Enhancer completed and no classes were enhanced. Consult the log for full details
+
+runserver:
+     [java] Jun 15, 2012 8:46:06 PM com.google.apphosting.utils.jetty.JettyLogger info
+     [java] INFO: Logging to JettyLogger(null) via com.google.apphosting.utils.jetty.JettyLogger
+     [java] Jun 15, 2012 8:46:06 PM com.google.apphosting.utils.config.AppEngineWebXmlReader readAppEngineWebXml
+     [java] INFO: Successfully processed gcm-demo-appengine/WebContent/WEB-INF/appengine-web.xml
+     [java] Jun 15, 2012 8:46:06 PM com.google.apphosting.utils.config.AbstractConfigXmlReader readConfigXml
+     [java] INFO: Successfully processed gcm-demo-appengine/WebContent/WEB-INF/web.xml
+     [java] Jun 15, 2012 8:46:09 PM com.google.android.gcm.demo.server.ApiKeyInitializer contextInitialized
+     [java] SEVERE: Created fake key. Please go to App Engine admin console, change its value to your API Key (the entity type is 'Settings' and its field to be changed is 'ApiKey'), then restart the server!
+     [java] Jun 15, 2012 8:46:09 PM com.google.appengine.tools.development.DevAppServerImpl start
+     [java] INFO: The server is running at http://192.168.1.10:8080/
+     [java] Jun 15, 2012 8:46:09 PM com.google.appengine.tools.development.DevAppServerImpl start
+     [java] INFO: The admin console is running at http://192.168.1.10:8080/_ah/admin
+
      + +
    8. Open the server's main page in a browser. The URL depends on the server you're using and your machine's IP address, but it will be something like http://192.168.1.10:8080/home, where /home is the path of the main servlet.
      9. + +

      Note: You can get the IP by running ifconfig on Linux or MacOS, or ipconfig on Windows.

      +
    +

    You server is now ready.

    + -

    See the documentation for each connection server for more detail on how it -handles responses.

    diff --git a/docs/html/google/google_toc.cs b/docs/html/google/google_toc.cs index 7f76c1242ad3..999c44e1734e 100644 --- a/docs/html/google/google_toc.cs +++ b/docs/html/google/google_toc.cs @@ -123,27 +123,24 @@ Google Cloud Messaging