GCM 3.0 rafraîchir un jeton d'inscription est-il nécessaire?

le jeton d'inscription ne devrait pas se rafraîchir après redémarrage, mais il y a d'autres situations où il pourrait se rafraîchir, donc vous devez le gérer.

avec L'API mise à jour, vous avez besoin d'implémenter un InstanceIDListenerService afin de gérer les rafraîchissements token comme illustré dans le google-services # android#gcm exemple d'application

    /**
     * Called if InstanceID token is updated. This may occur if the security of
     * the previous token had been compromised. This call is initiated by the
     * InstanceID provider.
     */
    // [START refresh_token]
    @Override
    public void onTokenRefresh() {
        // Fetch updated Instance ID token and notify our app's server of any changes (if applicable).
        Intent intent = new Intent(this, RegistrationIntentService.class);
        startService(intent);
    }

concernant les autres situations où le rafraîchissement du jeton peut se produire.

• Vérifier https://developers.google.com/cloud-messaging/server-ref#error-codes Enregistrée de l'Appareil description de l'erreur:

Un enregistrement existant jeton peut cesser d'être valable dans un certain nombre de les scénarios, y compris:

- Si le client apparaît avec GCM.

- Si l'application client est automatiquement enregistrées, ce qui peut se produire si l'utilisateur désinstalle l'application. Par exemple, sur iOS, si les APNS Service De Feedback déclaré le jeton APNS invalide.

- Si le token d'Enregistrement expire (par exemple, Google pourrait décider de rafraîchir les tokens d'enregistrement, ou le token APNS a expiré pour iOS appareil.)

- Si l'application client est mise à jour mais que la nouvelle version n'est pas configurée pour recevoir des messages.

dans tous ces cas, supprimez ce jeton d'enregistrement de l'application serveur et arrêtez de l'utiliser pour envoyer des messages.

• Comme par https://stackoverflow.com/a/16839326/313113 (à partir de EDIT 04.24.2014) il semble qu'il y ait un bug lorsque l'utilisateur met à niveau l'application et que vous envoyez une notification en même temps lorsque la mise à niveau se produit, le token n'est pas enregistré, donc vous devez vous inscrire à nouveau après une mise à niveau de l'application. (je ne sais pas si c'est toujours le cas)
• rafraîchissements des tokens après une opération de sauvegarde / restauration
• la documentation à maintien de L'État D'immatriculation dans Sync recommande même de rafraîchir périodiquement les tokens à partir du serveur, pour des raisons de sécurité:

pour protéger l'application client et le serveur d'application de potentiel malveillant réutilisation des tokens d'enregistrement, vous devriez lancer périodiquement token actualisation à partir du serveur. Lorsque le rafraîchissement du jeton d'enregistrement GCM est lancé depuis le côté serveur, l'application cliente doit gérer un tokenRefreshed message avec le client/serveur d'enregistrement GCM poignée de main

Voir la référence de L'API pour plus d'informations sur l'identité et la procédure de rafraîchissement des tokens.

EDIT: consultez les InstanceID docs car cela montre comment gérer le rafraîchissement des tokens. https://developers.google.com/instance-id/ et https://developers.google.com/instance-id/guides/android-implementation

ce n'est pas très clair d'un serveur PoV imho.

https://developers.google.com/cloud-messaging/registration#keeping-the-registration-state-in-sync nous avons

Pour protéger le client application et serveur d'application à partir de la réutilisation malveillante potentielle des tokens d'enregistrement, vous devriez périodiquement initier le rafraîchissement des tokens à partir du serveur. Lorsque le rafraîchissement du token d'enregistrement GCM est initié du côté du serveur, l'application client doit gérer un message tokenRefreshed avec la poignée de main client/serveur d'enregistrement GCM. Voir la référence de L'API pour plus d'informations sur l'identité et la procédure de rafraîchissement des tokens.

Hmm, il n'y a pas de lien pour la référence de L'API-donc en regardant l'api du serveur ici https://developers.google.com/cloud-messaging/server-ref#interpret-downstream nous avons un canonical_ids champ

Nombre de résultats qui contiennent canonique enregistrement jeton. Voir l'aperçu des inscriptions pour plus de détails sur ce sujet.

et results champ

chaîne optionnelle spécifiant le jeton d'enregistrement canonique de l'application client à laquelle le message a été traité et envoyé. L'expéditeur doit utiliser cette valeur comme jeton d'enregistrement pour les demandes futures. Sinon, les messages pourraient être rejetés.

côté client, nous avons le nouveau https://developers.google.com/android/reference/com/google/android/gms/iid/InstanceIDListenerService.html#onTokenRefresh()

Appelée lorsque le système détermine que les jetons doivent être actualisées. L'application doit appeler getToken () et envoyer les tokens à toutes les applications serveur. Cela ne sera pas appelé très souvent, il est nécessaire pour la rotation des clés et de gérer les cas spéciaux. Le système va étouffer l'événement de rafraîchissement sur tous les appareils pour éviter de surcharger les serveurs d'application avec des mises à jour de token.

donc la façon dont vous initiez le rafraîchissement des tokens depuis le serveur me dépasse! Mais en réponse à votre question-oui, vous avez encore besoin de gérer le côté client rafraîchir token!

EDIT: intéressant de lire traitement des changements D'identification d'enregistrement dans Google Cloud Messagerie sur Android