Les fournisseurs de solutions de gestion de la mobilité en entreprise (EMM) proposent des solutions aux organisations pour gérer les appareils Android et les applications qui y sont installées. Ces solutions sont généralement disponibles sous forme de consoles Web, appelées consoles EMM. Utiliser un fournisseur EMM console, les administrateurs informatiques effectuent des tâches de gestion des appareils et des applications organisation.
Les applications ciblant les entreprises peuvent envoyer des commentaires aux EMM sous la forme de : les états d'application appariés. Les EMM peuvent récupérer des données d'état d'application clés grâce à des API, qu'ils peuvent ensuite afficher dans leur console EMM. Ce canal de communication permet aux administrateurs informatiques de recevoir des commentaires sur l'état des applications installées sur les appareils qu'ils gèrent.
Par exemple, une application de client de messagerie peut utiliser des états d'application à clé pour confirmer qu'un le compte a bien été configuré, signaler les erreurs de synchronisation ou envoyer autres mises à jour de statut que le développeur de l'application juge appropriées.
Composants d'un état d'application à clé
Un état d'application associé comprend les éléments suivants:
- Clé:identifiant unique de l'état de l'application. 100 caractères maximum.
- Message:message facultatif décrivant l'état de l'application. Maximum : 1 000 caractères. Remarque: Généralement, la durée des messages doit être nettement plus courte.
- Données:valeur facultative lisible par l'ordinateur destinée aux EMM pour permettre aux administrateurs informatiques
pour configurer des alertes ou des filtres en fonction de cette valeur. Par exemple, un administrateur informatique peut
Configurez une alerte si le champ de données est
battery_percentage < 10
. Maximum : 1 000 caractères. - Gravité : gravité de l'état de l'application. Les valeurs autorisées sont les suivantes :
SEVERITY_ERROR
etSEVERITY_INFO
(par défaut). Définir uniquement la gravité surSEVERITY_ERROR
les conditions d'erreur réelles qu'une organisation doit prendre des mesures pour corriger. - Horodatage : lorsqu'un état d'application à clé est défini, il est automatiquement envoyé avec en millisecondes depuis l'epoch.
Envoyer des commentaires sur les configurations gérées
Si votre application est compatible avec les configurations gérées, nous vous recommandons d'envoyer des états d'application clés afin d'informer les administrateurs informatiques de la l'état des configurations qu'ils définissent. L'exemple de workflow suivant décrit une façon de le faire.
- Les administrateurs informatiques utilisent leur console EMM pour définir et envoyer des configurations gérées pour
Une application installée sur un appareil entièrement géré
ou dans un profil professionnel.
Exemple :
- Volume : '50 %'
- Devise : "USDD"
- L'application tente d'appliquer les configurations. Le volume a bien été réglé à 50%, mais le code de devise n'est pas valide et ne peut être appliqué.
- En fonction de l'état de chaque configuration, l'application définit un état d'application à clé.
Chaque état d'application associé à une clé contient une clé unique et un message contenant les détails
de l'état. Nous vous recommandons de faire correspondre la clé des configurations gérées lorsque cela est possible.
Exemple :
Clé Message Gravité Code temporel volume
Définir sur 50% SEVERITY_INFO
1554461130
currency
Devise "USDD" non reconnu SEVERITY_ERROR
1554461130
- Le fournisseur EMM récupère les états d'application avec clé définis par l'application et affiche
dans sa console EMM. Exemple :
Configuration État Action requise Durée Volume Définir sur 50% Non 5 avril 2019 10:45:30 Devise ERREUR: Devise "USDD" non reconnu. Oui 5 avril 2019 10:45:30 Le fournisseur EMM doit également signaler explicitement tout état de réception avec
SEVERITY_ERROR
à l'administrateur informatique. Les administrateurs informatiques peuvent consulter les informations de leur console EMM prendre des mesures pour corriger les erreurs dans les configurations qu'ils définissent.
Signaler des erreurs résolues
Une fois l'erreur résolue, envoyez immédiatement un état de suivi de l'application à empêcher les EMM d'afficher le message d'erreur indéfiniment. Ce suivi doit inclure:
- La même clé dans le message d'erreur initial.
- Gravité
SEVERITY_INFO
qui indique que l'état n'est pas en état d'erreur et n'a pas obliger l'organisation à prendre des mesures supplémentaires.
Ajouter la prise en charge des états d'application associés à votre application
Les étapes ci-dessous décrivent comment intégrer des états d'application clés à votre application.
Étape 1: Ajoutez le dépôt Maven de Google à votre fichier settings.gradle
Ajoutez le dépôt Maven de Google comme emplacement de dépôt dans le fichier settings.gradle
de votre projet.
, comme indiqué ci-dessous:
dependencyResolutionManagement { repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS) repositories { google() } }
Étape 2: Ajoutez la bibliothèque de commentaires de l'entreprise au fichier build.gradle
au niveau du module
Ajoutez la dépendance suivante à build.gradle
au niveau du module
:
dependencies { implementation 'androidx.enterprise:enterprise-feedback:1.0.0' }
Étape 3: Récupérez une instance de KeyedAppStatesReporter
Dans votre méthode onCreate()
, récupérez et stockez une instance de
KeyedAppStatesReporter
Cela permet de créer un canal de communication entre votre application et les fournisseurs EMM.
Kotlin
val reporter = KeyedAppStatesReporter.create(context)
Java
KeyedAppStatesReporter reporter = KeyedAppStatesReporter.create(context);
Étape 4: Créez une collection d'états d'application associés
Suivez les bonnes pratiques décrites ci-dessous lorsque vous créez des états d'application clés:
- N'incluez jamais d'informations permettant d'identifier personnellement l'utilisateur dans un état. Les états d'applications clés ne sont pas adapté aux données sensibles.
- Conserver les états d'application clés dans les limites définies dans
MAX_KEY_LENGTH
,MAX_MESSAGE_LENGTH
, etMAX_DATA_LENGTH
. - Un seul appel
setStates
ousetStatesImmediate
est limité à 300 Ko au total (environ un tiers du total pouvant être stocké par jour). Si vous la dépassez, le comportement n'est pas défini. - Ne définissez la gravité d'un état que sur
SEVERITY_ERROR
si une condition existe et qu'une organisation doit prendre des mesures pour la corriger. - Lorsque vous envoyez un état d'application contenant des erreurs, assurez-vous d'envoyer également un lorsque les erreurs sont résolues, afin que l'EMM puisse arrêter de signaler des erreurs dans leur console.
- Pour l'état de suivi, utilisez la même
key est la valeur
d'état initial qui a renvoyé l'erreur et défini la gravité sur
SEVERITY_INFO
L'extrait de code ci-dessous crée une collection d'états d'application associés:
Kotlin
val states = hashSetOf(KeyedAppState.builder() .setKey("key") .setSeverity(KeyedAppState.SEVERITY_INFO) .setMessage("message") .setData("data") .build())
Java
Collectionstates = new HashSet<>(); states.add(KeyedAppState.builder() .setKey("key") .setSeverity(KeyedAppState.SEVERITY_INFO) .setMessage("message") .setData("data") .build());
Étape 5: Définissez les états de l'application à clé
setStates()
envoie immédiatement les états d'application associés à l'application Play Store (nom du package:
com.android.vending
) s'il est installé sur l'appareil, de même que les administrateurs de
appareil ou profil professionnel.
Kotlin
keyedAppStatesReporter.setStates(states)
Java
keyedAppStatesReporter.setStates(states);