Develop Reference

Can expired registration tokens be valid again?

My question is this I implementing a system to clear our servers of expired GCM registration tokens.
Once a registrationID is rejected by GCM as not registered or expired can it ever become valid again ? For APNS in iOS this can occur, but it cannot happen for GCM correct?
Once a client updates its registration tokens with GCM and our servers try to send notifications downstream it can receive a result with a canonical ID listing the new registration ID. How long is the old registration ID valid?

Yes. Once the token expires, a different valid token takes it's place --
triggering onTokenRefresh() on the corresponding client's side. It's actually expected for the developers to immediately remove the expired token from where they keep it, and replace it with the new one.
Canonical IDs are AFAIK, no longer used.

registring on gcm multiple time from same device will generate multiple id or same and multiple users on same device

I want to know If I am registering my android app multiple time on gcm from same device will I get different registration id each time or the same one once registered?
Coming onto my second problem which is as below
if user1 logs out and user2 logs in the app on the same device. Now suppose a notification for user1 is sent from the server. Will the user2 get that notification or not if yes then how can it be avoided?
if user1 is logged in the app but user2 re-installs the app and logs in but server still thinks that user1 is logged in that device hence when we send the notification to user1 it will be delivered to user2. How can these be handled?
if my andriod app tries to register multiple time on gcm, will it get
different registration id or the same one?

AFAIK, this will be handled by GCM but as stated in this forum the solution would be to filter them on the client side. Your GCM notification should pass on which user it is for. Then in your onReceive method you should check who is currently logged in.
For your last question, according to the documentation - Registering:Client Apps
If a bug in the client app triggers multiple registrations for the same device, it can be hard to reconcile state and the client app might end up with duplicate messages.
Implementing canonical IDs can help you more easily recover from these situations. A canonical registration ID is the registration token of the last registration requested by the client app . This is the ID that the server should use when sending messages to the device.
If you try to send a message using an old registration token, GCM will process the request as usual, but it will include the canonical ID in the registration_id field of the response. Make sure to replace the registration token stored in your server with this canonical ID, as eventually the old registration token will stop working.

registrationID lifecycle for gcm

I wonder what is the lifecycle of registrationId(device_token)
e.g eD3Fa1yVqx8:APA91bH5gNrC-jhUqaoRwyFLfD2ik4NXwCXohwhm_9CM5hnY9wFwUAOiO_O12Or-dm60sUqy9gN2ZW6mw5i90RyNhb-zHilvtcJczPjZoQlm_4lKNKDejC_1_xiqmYoZnSxaFfVqSA1d
How to handle the situation if it's changed?

As far as the information on the official docs goes, there is no information about the token being changed by Google. However you should change it periodically.
Quoting https://developers.google.com/cloud-messaging/registration#automatic-retry-using-exponential-back-off
Keeping the Registration State in Sync
To protect the client app and app server from potential malicious
re-use of registration tokens, you should periodically initiate token
refresh from the server. When GCM registration token refresh is
initiated from server side, the client app must handle a
tokenRefreshed message with the GCM registration client/server
handshake.

I faced some situations where Registration ID changed. But, i don't know how and when.
So, to handle these situations i updated my app to send Registration ID every time the app is launched. I sent Registration ID with device id and check my database if the registration id changed i updated it.

How to stack or group Registration IDs while using GCM?

I just started to use Google Cloud Messaging and read about User Notifications.
According to this link, all the devices owned by a particular user will be notified at once.
In my case, a particular user is identified by his/her user_id and the database would look like this:
[user_id] [gcm_registration_id]
As per the demo, on the application side this registration_id is stored as persistent data.
What happens if the user uninstalls the app and the persistent data is gone?
Will I get the same Registration ID for the same App on the same device once the user re-installs the app?
Will Google invalidate these Registration IDs after some time?

will I get the same registration_id for the same app on the same
device once the user reinstalls the app?
YES. Reg id chnages in two cases. Either your app will register OR Google refreshes the Registration ID. SO until any one cases executes your are fine with old reg id.
By any chance google invalidates these registration_ids after some
time?
YES. Google refreshes the registration ID. GCM gives you the idea about handleing of updated registartion ID.
Handle updated id on client side
If the registration is successful, the GCM server broadcasts a com.google.android.c2dm.intent.REGISTRATION intent which gives the Android application a registration ID.
The Android application should store this ID for later use (for instance, to check on onCreate() if it is already registered). Note that Google may periodically refresh the registration ID, so you should design your Android application with the understanding that the com.google.android.c2dm.intent.REGISTRATION intent may be called multiple times. Your Android application needs to be able to respond accordingly.

Actually the answer you accepted is not entirely correct.
I tested the case of un-installing and re-installing an app on a device, and in some cases you could get a different registration ID.
There are two cases :
You install an app, register to GCM and get a registration ID.
You un-install app
Your server sends a few messages to that registration ID, until you get a NotRegistered error from GCM (I believe you'll get that error only from the 2nd message you send).
You re-install the app
You receive a new registration ID when app register to GCM
If you now send a message with the old registration ID, it will still work, but you'll get the new registration ID in the response as canonical registration ID.
You install an app, register to GCM and get a registration ID.
You un-install app
The server doesn't send anything to that registration ID while the app is un-installed.
You re-install the app
You receive the same registration ID when app registers to GCM

Would device registration id of C2DM expires?

Well, I know that the registration id of server would expire. However, how about the device registration id?
If yes, how do the server and client know about that?
Now I just simply save the id into database and assume it would never change.
Btw, is the registration id of server associated with the device registration id? Why the tutorial from the internet store them in the pair

Short answer is Yes, as stated here.
The application should store this ID for later use. Note that Google may periodically refresh the registration ID, so you should design your application with the understanding that the REGISTRATION Intent may be called multiple times. Your application needs to be able to respond accordingly.
Basically what would have to happen is that your application needs some sort of communication with your server to notify it that it received a new id. What you could do is when the app receives a registration id, store it on some remote database along with some additional unique information about that device (or user credentials if app has authentication). When Google decides to change the registration id, just update the previous entry on the remote db with the new id. Then when your server needs to push a message to some device, it matches the device to an up-to-date registration id in the database and uses that id to push the notification.