Google Play génère des notifications, appelées notifications EMM, en réponse à divers événements affectant une entreprise. Par exemple, lorsqu'une application est approuvée, le système envoie une notification ProductApprovalEvent.
Les notifications EMM sont associées à un compte de service d'entreprise (ESA) spécifique. En tant qu'EMM, vous pouvez configurer votre console pour afficher des alertes ou des messages aux administrateurs informatiques d'entreprise en fonction des notifications que vous recevez.
Les notifications EMM sont envoyées via Google Cloud Pub/Sub. Pour en savoir plus sur la configuration des notifications Pub/Sub, consultez les sections Présentation des abonnements et Guide pour les abonnés Pull.
Pour vérifier que vous avez bien configuré votre système afin de recevoir des notifications EMM de Google Play et de récupérer le nom du sujet Cloud Pub/Sub auquel vous devez connecter votre abonnement, appelez Enterprises.sendTestPushNotification.
L'envoi d'une notification de test permet de valider votre intégration EMM au service Google Cloud Pub/Sub pour l'entreprise. Si les notifications EMM sont correctement configurées, l'API renvoie les éléments suivants:
{
topic_name: "/projects/project-name/topics/play-work-012345",
message_id: "128976912439"
}
Notifications pull
Google Cloud Pub/Sub est compatible avec deux mécanismes de notification différents: pull et push. Toutefois, seules les notifications pull sont recommandées. L'approche pull ne nécessite aucune configuration de serveur externe et fonctionne avec des services d'analyse de l'environnement (ESA) créés manuellement et de manière automatisée. Un autre avantage des notifications pull est qu'elles ne nécessitent que peu ou pas de maintenance supplémentaire de la part de vos clients. Utilisez Enterprises.pullNotificationSet et Enterprises.acknowledgeNotificationSet pour recevoir et confirmer les notifications EMM sur des connexions sortantes de longue durée.
Lorsque vous appelez Enterprises.pullNotificationSet, nous vous recommandons de laisser requestMode sur sa valeur par défaut (waitForNotifications). Cela oblige la requête à attendre qu'une ou plusieurs notifications soient présentes avant de renvoyer une réponse. Si aucune notification n'est présente après un certain temps, la requête renvoie une liste de notifications vide, après quoi vous pouvez réessayer.
Une fois les notifications reçues, appelez Enterprises.acknowledgeNotificationSet pour vous assurer que les mêmes notifications ne seront pas renvoyées la prochaine fois que vous appellerez Enterprises.pullNotificationSet.
Vous pouvez également définir requestMode sur returnImmediately lorsque vous appelez Enterprises.pullNotificationSet. Vous recevrez immédiatement une réponse à la requête, contenant les notifications en attente ou une liste vide en l'absence de notifications. Cette option requestMode peut être utile lorsque vous testez initialement l'implémentation de vos notifications.
Exemples de notifications EMM
Voici quelques exemples d'événements et des types de notifications qu'ils génèrent:
Remarque:Les types de notifications suivants sont obsolètes : ProductApprovalEvent, AppUpdateEvent, NewPermissionsEvent, AppRestrictionsSchemaChangeEvent, ProductAvailabilityChangeEvent et NewDeviceEvent. Pour AppUpdateEvent, vous devez utiliser le mode de mise à jour à priorité élevée conformément à nos recommandations.
| Description | Notification |
|---|---|
| Une notification de test est demandée via l' API EMM Google Play. Vous devez envoyer une notification de test pour vérifier que votre système peut recevoir les notifications publiées par Google Play et pour connaître le nom du sujet utilisé pour toutes les notifications associées à Google Play. | TestPushNotification |
Un appareil nouvellement provisionné est prêt à être géré par l'API EMM Google Play. Vous pouvez maintenant appeler des API qui nécessitent le deviceId de l'appareil (Installations, par exemple) et des API qui renvoient une ressource Appareils. Cette notification n'est envoyée qu'une fois que le premier compte est provisionné sur un appareil géré.
OBSOLÈTE
| NewDeviceEvent |
| Un administrateur marque une application comme approuvée ou non approuvée dans la Google Play Console d'entreprise. OBSOLÈTE | ProductApprovalEvent
|
| Une installation en attente sur un appareil expire. Par exemple, une demande d'installation push est acceptée, mais l'appareil n'est pas accessible pendant plusieurs jours. L'installation ne peut donc pas être confirmée. Le système envoie une notification d'expiration de l'installation. | InstallFailureEvent
|
| Une nouvelle version d'une application est publiée. La mise à jour est disponible pour un ou plusieurs appareils, mais pas nécessairement tous. OBSOLÈTE | AppUpdateEvent
|
| Une mise à jour d'application nécessite une nouvelle autorisation devant être approuvée par l'administrateur pour qu'une mise à jour ou une nouvelle installation puisse avoir lieu. Cette notification est envoyée lorsque l'ensemble d'autorisations accepté par l'application diffère de celui des autorisations demandées par l'application. OBSOLÈTE | NewPermissionsEvent |
| Une nouvelle version d'une application est publiée. Elle inclut un schéma de configuration gérée nouveau ou modifié. Lorsqu'un développeur importe un nouvel APK, Google Play compare le schéma du fichier manifeste à celui de la version précédente de l'application. Si le schéma a changé, les entreprises qui ont approuvé l'application sont informées. OBSOLÈTE | AppRestrictionsSchemaChangeEvent |
| Une application disponible devient indisponible, ou une application indisponible est de nouveau ajoutée à Google Play. La disponibilité de l'application change si un développeur l'annule ou si elle est supprimée de Google Play. La disponibilité change également si une application indisponible est de nouveau ajoutée à Google Play. OBSOLÈTE | ProductAvailabilityChangeEvent |