- max 1000 registration IDs per multicast message
- max 1 million subscribers per app
- max 2KB payload
- max 20 members per device group
- group name should be unique per user
- HTTP: Downstream only, cloud-to-device up to 4KB of data.
- XMPP (CCS): Upstream and downstream (device-to-cloud, cloud-to-device), up to 4 KB of data.
- Max connections allowed per XMPP sender is 1000
- Max outstanding messages per XMPP connection is 100
- Max pending upstream messages is 100
- Max 1 day disconnect time
- ACKing is required
- Max 20 unacke'd upstream messages (w/ TTL != 0)
- Max payload size is 4KB
- Limit of 100 multiple senders
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.
Note: There is a limit of 100 messages that can be stored without collapsing. If the limit is reached, all stored messages are discarded. 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 from the app server.
To prevent abuse (such as sending a flood of messages to a device) and to optimize for the overall network efficiency and battery life of devices, GCM may throttle messages based on the messages-sent rate for a particular application per device. Because of this, an application may encounter additional message delivery latency when it sends a large number of messages to the same device within a short period of time.