Envoyer des commentaires sur l'application aux fournisseurs EMM

Les fournisseurs de gestion de la mobilité en entreprise (EMM) proposent aux organisations des solutions permettant de 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. À l'aide d'une console EMM, les administrateurs informatiques effectuent des tâches de gestion des appareils et des applications pour le compte de leur organisation.

Les applications ciblant les entreprises peuvent envoyer des commentaires aux EMM sous la forme d'états d'application appariés. Les API permettent aux EMM de récupérer des données d'état de l'application associées, 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 associés pour confirmer qu'un compte a bien été configuré, signaler les erreurs de synchronisation ou envoyer toute autre mise à jour d'état que le développeur de l'application juge appropriée.

Composants d'un état d'application à clé

Un état d'application à clé 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. 1 000 caractères maximum. Remarque: En règle générale, les messages doivent être beaucoup plus courts.
• Données:valeur facultative lisible par un ordinateur destinée aux EMM et permettant aux administrateurs informatiques de configurer des alertes ou des filtres en fonction de la valeur. Par exemple, un administrateur informatique peut configurer une alerte si le champ de données battery_percentage < 10. 1 000 caractères maximum.
• Severity (Gravité) : niveau de gravité de l'état de l'application. Les valeurs autorisées sont SEVERITY_ERROR et SEVERITY_INFO (par défaut). Ne définissez la gravité sur SEVERITY_ERROR que pour les conditions d'erreur réelles qu'une organisation doit corriger.
• Code temporel : lorsqu'un état d'application à clé est défini, il est automatiquement envoyé avec un horodatage exprimé 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é afin de mettre à jour les administrateurs informatiques sur l'état des configurations qu'ils ont définies. L'exemple de workflow suivant décrit une façon de procéder.

1. 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"
2. L'application tente d'appliquer les configurations. Le volume a bien été défini sur 50%, mais le code de devise n'est pas valide et ne peut pas être appliqué.
3. En fonction de l'état de chaque configuration, l'application définit un état d'application à clé. Chaque état d'application à clé contient une clé unique et un message avec les détails de l'état. Dans la mesure du possible, nous vous recommandons de faire correspondre la clé de configuration gérée. Par exemple :

   Clé	Message	Niveau	Code temporel
   volume	Définir sur 50%	SEVERITY_INFO	1554461130
   currency	Devise "USDD" non reconnue	SEVERITY_ERROR	1554461130

4. Le fournisseur EMM récupère les états d'application à clé définis par l'application et les affiche dans sa console EMM. Par exemple :

   Configuration	État	Action requise	Durée
   Volume	Définir sur 50%	Non	5 avril 2019 ; 10:45:30
   Devise	ERREUR: La devise "USDD" n'est pas reconnue.	Oui	5 avril 2019 ; 10:45:30

   Le fournisseur EMM doit également signaler explicitement les états reçus avec SEVERITY_ERROR à l'administrateur informatique. Les administrateurs informatiques peuvent consulter ces informations dans leur console EMM et corriger les erreurs dans les configurations qu'ils ont définies.

Signaler des erreurs résolues

Une fois l'erreur résolue, envoyez immédiatement un état de suivi de l'application pour empêcher les fournisseurs EMM d'afficher le message d'erreur indéfiniment. Cet état de suivi doit inclure:

• Même clé que le message d'erreur initial
• Une gravité de SEVERITY_INFO, qui indique que l'état n'est pas dans une condition d'erreur et ne nécessite aucune autre action de l'organisation.

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é dans 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 Enterprise Feedback au fichier build.gradle au niveau du module

Ajoutez la dépendance suivante au fichier build.gradle au niveau du module:

dependencies {
    implementation 'androidx.enterprise:enterprise-feedback:1.0.0'
}

Étape 3: Obtenez une instance de KeyedAppStatesReporter

Dans votre méthode onCreate(), récupérez et stockez une instance de KeyedAppStatesReporter. Cela permet d'établir un canal de communication entre votre application et les fournisseurs EMM.

val reporter = KeyedAppStatesReporter.create(context)

KeyedAppStatesReporter reporter = KeyedAppStatesReporter.create(context);

Étape 4: Créez une collection d'états d'application appariés

Suivez les bonnes pratiques décrites ci-dessous lorsque vous créez des états d'application appariés:

• N'incluez jamais d'informations permettant d'identifier personnellement l'utilisateur dans un état. Les états d'application clé ne sont pas adaptés aux données sensibles.
• Conservez les états d'application associés dans les limites définies dans MAX_KEY_LENGTH, MAX_MESSAGE_LENGTH et MAX_DATA_LENGTH.
• Un seul appel setStates ou setStatesImmediate est limité à 300 Ko au total (environ un tiers de la quantité totale pouvant être stockée par jour). Si vous dépassez cette valeur, le comportement sera indéfini.
• Ne définissez la gravité d'un état sur SEVERITY_ERROR que s'il existe une condition qu'une organisation doit corriger.
• Lorsque vous envoyez un état d'application contenant des erreurs, veillez également à envoyer un état de suivi une fois les erreurs résolues afin que l'EMM puisse cesser de les signaler dans sa console.
• Pour l'état de suivi, utilisez la même clé que l'état initial ayant renvoyé l'erreur et définissez le niveau de gravité sur SEVERITY_INFO.

L'extrait de code ci-dessous crée une collection d'états d'application appariés:

    val states = hashSetOf(KeyedAppState.builder()
             .setKey("key")
             .setSeverity(KeyedAppState.SEVERITY_INFO)
             .setMessage("message")
             .setData("data")
             .build())
    

    Collection states = 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é

La méthode setStates() envoie immédiatement les états de l'application associés à l'application Play Store (nom du package : com.android.vending) si elle est installée sur l'appareil, ainsi qu'à tous les administrateurs de l'appareil ou du profil professionnel.

keyedAppStatesReporter.setStates(states)

keyedAppStatesReporter.setStates(states);

Tester les états de l'application à clé