Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Certaines applications peuvent envoyer des commentaires aux EMM sous la forme d'applications clés
de sortie. Un état d'application à clé est constitué d'un identifiant unique (clé),
message correspondant (facultatif), données lisibles par un ordinateur (facultatif), niveau de gravité
l'état et le code temporel. Pour les envoyer, une application doit s'intégrer
Bibliothèque Enterprise Jetpack
Une application ne peut envoyer les premiers commentaires immédiats qu'une fois toutes les minutes. Les commentaires générés pendant la période d'attente sont mis en file d'attente et envoyés en totalité à la fin de cette période. Par exemple, lorsqu'un commentaire est généré trois fois à [t=0s;10s;15s] avec une période d'attente d'une minute, le premier retour immédiat est envoyé à [t=0s], le deuxième et le troisième retour à [t=60s].
En tant qu'EMM, vous pouvez utiliser les données des états d'application clés pour que les administrateurs informatiques
des applications installées sur les profils et appareils gérés. Exemple
de fonctionnement est décrit dans la section Afficher un commentaire pour
pour les entreprises.
Activer les rapports sur les appareils
Les applications envoient des états d'application clés pour chaque appareil. Les états sont inclus dans
rapports sur les appareils. Pour activer la création de rapports pour un appareil:
Afficher les états d'application clés dans les rapports sur les appareils
Les rapports sur les appareils sont disponibles sous la forme de ressources relatives aux appareils.
Les états d'application clés sont regroupés par nom de package dans la section Rapport sur les applications, comme illustré dans l'exemple ci-dessous:
La gravité de l'état: INFO indique un message informatif. (par exemple, si une configuration gérée est correctement définie). ERROR indique que l'entreprise doit prendre des mesures pour corriger un problème. (par exemple, si une configuration gérée n'a pas pu être définie).
message
Chaîne facultative fournissant des détails sur l'état de l'application. Nous recommandons aux développeurs d'applications de traiter ce champ comme un message visible par l'utilisateur.
data
Chaîne facultative qui fournit aux fournisseurs EMM des détails lisibles par ordinateur sur l'état de l'application. Par exemple, une valeur qu'un administrateur informatique peut interroger dans votre console, telle que "notify me if the battery_warning data < 10".
createTime
Code temporel indiquant quand l'état de l'application a été créé sur l'appareil.
lastUpdateTime
Code temporel indiquant la date et l'heure de la dernière mise à jour de l'état de l'application sur l'appareil.
Diffuser des commentaires sur l'application auprès des entreprises
Les applications peuvent envoyer des commentaires pour diverses raisons. Toutefois, l'utilisation la plus courante
l'envoi d'états d'application clés est de fournir des commentaires sur les
de configuration. Exemple :
Dans le backend, vous utilisez ApplicationPolicy.
pour envoyer les configurations à l'application.
L'application tente d'appliquer les configurations. Pour chaque configuration, l'application
envoie un état d'application à clé indiquant son état (par exemple, une confirmation
(message ou notification d'erreur).
Pour afficher ces états d'application associés, vous devez récupérer un rapport sur les appareils.
À partir des informations des états d'application à clé, votre console EMM affiche les
l'état des configurations gérées de manière conviviale.
Alerter les administrateurs informatiques en cas d'erreurs
Un état d'application associé au niveau de gravité ERROR indique que l'organisation doit effectuer
l’action afin de corriger
un problème. Les EMM doivent toujours alerter les organisations
aux erreurs, via leur console EMM ou par d'autres moyens. Par exemple, votre
La console EMM peut afficher un tableau de bord des erreurs lié aux commentaires
un appareil donné avec des erreurs.
Si un état d'erreur est corrigé, l'application envoie un état de suivi avec la
la même clé que l'état d'erreur d'origine et une sévérité mise à jour de INFO. Fournisseurs EMM
doivent toujours informer les organisations dès qu'une erreur est corrigée. Pour
Par exemple, supprimez l'erreur du tableau de bord des erreurs de votre console ou marquez-la comme
résolu.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2024/09/11 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2024/09/11 (UTC)."],[[["\u003cp\u003eKeyed app states provide feedback from apps to EMMs, encompassing an identifier, optional message and data, severity, and timestamps.\u003c/p\u003e\n"],["\u003cp\u003eApps utilize the Enterprise Jetpack library to send keyed app states, adhering to a cooldown period for immediate feedback.\u003c/p\u003e\n"],["\u003cp\u003eEMMs leverage keyed app states to monitor app status on managed devices, accessible via device reports requiring enabled Pub/Sub notifications and application reports.\u003c/p\u003e\n"],["\u003cp\u003eDevice reports contain keyed app states categorized by package name, revealing app status details like severity, messages, and timestamps.\u003c/p\u003e\n"],["\u003cp\u003eEMMs should display app feedback to IT admins, especially highlighting errors and resolutions, potentially through dashboards and alerts.\u003c/p\u003e\n"]]],["Apps use keyed app states to send feedback to EMMs, comprising a unique key, message, data, severity, and timestamp. Apps integrate via the Enterprise Jetpack library and are limited to sending immediate feedback once per minute. EMMs can access this data in device reports by enabling `STATUS_REPORT` notifications and setting `applicationReportsEnabled`. Device reports contain keyed app states grouped by package, allowing IT admins to monitor app status and managed configurations. EMMs must alert admins to `ERROR` states and inform them when errors are resolved.\n"],null,["# Retrieve feedback from apps\n\nSome apps are capable of sending feedback to EMMs in the form of **keyed app\nstates** . A keyed app state is made up of a unique identifier (key),\ncorresponding message (optional), machine-readable data (optional), severity\nstatus, and timestamp. To send them, an app needs to integrate with the\n[Enterprise Jetpack library](https://developer.android.com/reference/androidx/enterprise/feedback/package-summary).\n\nAn app can only send the first [immediate feedback](https://developer.android.com/reference/androidx/enterprise/feedback/KeyedAppStatesReporter#setStatesImmediate(java.util.Collection%3Candroidx.enterprise.feedback.KeyedAppState%3E,androidx.enterprise.feedback.KeyedAppStatesCallback)) once every minute. Feedback generated during the cooldown period will be queued and sent altogether when the cooldown period ends. For example, when feedback is generated 3 times at \\[t=0s;10s;15s\\] with a cooldown period of 1 minute: the first immediate feedback will be sent at \\[t=0s\\], the second and third feedback at \\[t=60s\\].\n\nAs an EMM, you can use the data from keyed app states to keep IT admins\nup-to-date with the apps installed on managed devices and profiles. An example\nof how this might work is described in [Display feedback to\nenterprises](#display_app_feedback_to_enterprises).\n\nEnable device reports\n---------------------\n\nApps send keyed app states on a per-device basis. The states are included in\ndevice reports. To enable reporting for a device:\n\n1. Follow the instructions for setting up [Pub/Sub notifications](/android/management/notifications) for an enterprise. In [Step 5](/android/management/notifications#5_update_enterprise_to_support_notifications), include [`STATUS_REPORT`](/android/management/reference/rest/v1/enterprises#NotificationType) in `enabledNotificationTypes`.\n2. For each device, update the device policy: set [`StatusReportingSettings.applicationReportsEnabled`](/android/management/reference/rest/v1/enterprises.policies#statusreportingsettings) to `true`.\n\nYou can now [use the Pub/Sub API to get device report notifications](/android/management/notifications#6_use_the_pubsub_api_to_get_notifications).\nOr, to review a device's latest report at any time, call [`devices.get()`](/android/management/reference/rest/v1/enterprises.devices/get).\n\nView keyed app states in device reports\n---------------------------------------\n\nDevice reports are available in the form of [device resources](/android/management/reference/rest/v1/enterprises.devices).\nKeyed app states are grouped by package name in the [application report](/android/management/reference/rest/v1/enterprises.devices#applicationreport) section, as shown in the example below: \n\n {\n \"applicationReports\":[\n {\n \"packageName\": \"pkg1\",\n \"versionCode\": 101,\n \"keyedAppStates\":[\n {\n \"key\": \"key1\",\n \"severity\": INFO,\n \"message\": \"message1\",\n \"data\": \"data1\",\n \"createTime\": \"2018-10-01T15:01:22.027623745Z\",\n \"lastUpdateTime\": \"2018-10-02T15:01:23.045123456Z\"\n }\n ]\n }\n ]\n }\n\nEach [keyed app state](/android/management/reference/rest/v1/enterprises.devices#KeyedAppState)\ncontains the following:\n\n| Field | Description |\n|------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| `key` | The unique key identifying the state. |\n| `severity` | The severity of the state: `INFO` indicates an informative message. For example if a managed configuration is set successfully. `ERROR` indicates the enterprise needs to take action to correct a problem. For example, if a managed configuration failed to set. |\n| `message` | An optional string providing details about the app state. App developers are advised to treat this field as a user-facing message. |\n| `data` | An optional string providing computer-readable details to EMMs about the app state. For example, a value that an IT admin could query against in your console, such as \"notify me if the battery_warning data \\\u003c 10\". |\n| `createTime` | The timestamp indicating when the app state was created on the device. |\n| `lastUpdateTime` | Timestamp indicating when the app state was last updated on the device. |\n\nDisplay app feedback to enterprises\n-----------------------------------\n\nApps can send feedback for a variety of reasons. However, the most common use\ncase for sending keyed app states is to provide feedback about managed\nconfigurations. For example:\n\n1. An IT admin uses your EMM console to [set managed configurations](/android/management/managed-configurations-iframe) for an app.\n2. In the backend, you use [ApplicationPolicy](/android/management/reference/rest/v1/enterprises.policies#ApplicationPolicy) to send the configurations to the app.\n3. The app attempts to apply the configurations. For each configuration, the app sends a keyed app state indicating its status (for example, a confirmation message or error notification).\n4. To view these keyed app states, you retrieve a device report.\n5. Using information from the keyed app states, your EMM console displays the status of the managed configurations in a user-friendly way.\n\n### Alert IT admins to errors\n\nA keyed app state with severity `ERROR` indicates the organization needs to take\naction in order to correct a problem. EMMs should **always** alert organizations\nto errors, either through their EMM console or other means. For example, your\nEMM console could display an error dashboard that links to the feedback for a\ngiven device with errors.\n\nIf an error state is corrected, the app will send a follow-up state with the\nsame key as the original error state and an updated severity of `INFO`. EMMs\nshould **always** inform organizations as soon as an error is corrected. For\nexample, remove the error from your console's error dashboard or mark it as\nresolved.\n| **Tip:** Add support for IT admins to mute a specific error in case an app fails to correctly update an error state after the error is resolved."]]