Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Alcune app sono in grado di inviare feedback ai provider EMM sotto forma di app con chiave
stati. Uno stato dell'app con chiave è costituito da un identificatore univoco (chiave),
messaggio corrispondente (facoltativo), dati leggibili dalla macchina (facoltativo), gravità
lo stato attuale e il timestamp. Per inviarli, un'app deve integrarsi con
Libreria Enterprise Jetpack.
In qualità di EMM, puoi utilizzare i dati provenienti dagli stati delle app con chiave per mantenere gli amministratori IT.
con le app installate sui dispositivi e sui profili gestiti. Esempio
di come funziona questa procedura è descritto nell'articolo Mostrare il feedback alle aziende.
Attiva i report sui dispositivi
Le app inviano gli stati con chiavi in base al dispositivo. Prima di qualsiasi stato dell'app con chiave
sono accettati da una qualsiasi delle app presenti sul dispositivo, devi attivare il dispositivo
report per un dispositivo. Fino a quando il criterio non viene aggiornato sul dispositivo, tutte le app con chiave
vengono ignorati e persi definitivamente. Attiva i report sui dispositivi prima
completare la registrazione dei dispositivi, il prima possibile durante la registrazione
e il processo di sviluppo. In questo modo ti assicuri di ricevere feedback sull'app generati durante il dispositivo
registrazione e che gli stati dell'app con chiave non vadano persi.
Chiama il numero devices.update(),
impostazione policy.deviceReportPolicy su "deviceReportEnabled".
Recuperare i report sui dispositivi
Esistono diversi modi per recuperare un report sul dispositivo:
Per recuperare i report sui dispositivi insieme ad altre notifiche, chiama
enterprises.pullNotificationSet()
Nella risposta, ogni deviceReportUpdateEvent indica la segnalazione di un dispositivo.
Per recuperare un report dispositivo aggiornato con gli ultimi stati delle app con chiave per un
dispositivo specificato, chiama devices.get().
Per forzare il caricamento degli ultimi stati dell'app su un dispositivo, chiama
devices.forceReportUpload()
Questo metodo carica un report contenente eventuali modifiche agli stati dell'app nella
dispositivo da quando è stato generato l'ultimo report.
di Gemini Advanced.
Visualizza stati delle app con chiave
I report sui dispositivi fanno parte delle risorse dei dispositivi. I report includono un appState
per ogni app (pacchetto) installata sul dispositivo o nel relativo profilo di lavoro.
Gli stati dell'app con chiave (keyedAppState) per un determinato pacchetto sono elencati in
Oggetto appState, come nell'esempio seguente:
{"result":{"kind":"androidenterprise#device","report":{"appState":[{"keyedAppState":[{"severity":"severityError","data":"user","message":"Username or password are incorrect","key":"account","stateTimestampMillis":"1556206406926"}],"packageName":"com.google.android.feedbacktestapp"}],"lastUpdatedTimestampMillis":"1556206407685"},"androidId":"32714368a0ad8ad5","managementType":"managedProfile","policy":{"deviceReportPolicy":"deviceReportEnabled"}}}
Ogni stato dell'app con chiave contiene quanto segue:
Campo
Descrizione
key
La chiave univoca che identifica lo stato.
severity
La gravità dello stato: INFO indica un messaggio informativo. Ad esempio, se una configurazione gestita è stata impostata correttamente. ERROR indica che l'azienda deve intervenire per risolvere un problema. ad esempio se non è stato possibile impostare una configurazione gestita.
message
Una stringa facoltativa che fornisce dettagli sullo stato dell'app. Consigliamo agli sviluppatori di app di considerare questo campo come un messaggio rivolto agli utenti.
data
Una stringa facoltativa che fornisce agli EMM dettagli leggibili dal computer sullo stato dell'app. Ad esempio, un valore su cui un amministratore IT può eseguire una query nella tua console, come "Avvisami se i dati della batteria_warning < 10".
stateTimestampMillis
Il timestamp (in millisecondi) che indica l'ultimo aggiornamento dello stato dell'app sul dispositivo.
lastUpdatedTimestampMillis
Il timestamp (in millisecondi) che indica quando il dispositivo ha caricato l'ultimo stato dell'app con chiave.
Mostra il feedback sulle app alle aziende
Le app possono inviare feedback per diversi motivi. Tuttavia, l'uso più comune
l'invio di stati delle app con chiavi è fornire feedback sugli
configurazioni. Ad esempio:
L'app tenta di applicare le configurazioni. Per ogni configurazione,
invia uno stato dell'app con chiave che ne indica lo stato (ad esempio, una conferma
un messaggio di errore o una notifica di errore).
Utilizzando le informazioni provenienti dagli stati delle app con chiave, la console EMM visualizza
delle configurazioni gestite in modo intuitivo.
Avvisa gli amministratori IT di errori
Uno stato dell'app con chiave e gravità ERROR indica che l'organizzazione deve eseguire
per correggere un problema. I provider EMM devono sempre avvisare le organizzazioni
agli errori, tramite la console EMM o altri mezzi. Ad esempio,
La console EMM potrebbe mostrare una dashboard degli errori che rimanda al feedback per un
un determinato dispositivo con errori.
Se uno stato di errore viene corretto, l'app invia uno stato di follow-up con la stessa chiave
come stato di errore originale e con una gravità aggiornata pari a INFO. I provider EMM devono
Informa sempre le organizzazioni non appena viene corretto un errore. Ad esempio:
rimuovi l'errore dalla dashboard degli errori della console o contrassegnalo come risolto.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Mancano le informazioni di cui ho bisogno","missingTheInformationINeed","thumb-down"],["Troppo complicato/troppi passaggi","tooComplicatedTooManySteps","thumb-down"],["Obsoleti","outOfDate","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Problema relativo a esempi/codice","samplesCodeIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-08-31 UTC."],[[["\u003cp\u003eKeyed app states allow apps to send feedback to EMMs, offering insights into app status and managed configuration outcomes on devices.\u003c/p\u003e\n"],["\u003cp\u003eEMMs need to enable device reports to receive keyed app states, ensuring data is collected and no feedback is lost.\u003c/p\u003e\n"],["\u003cp\u003eDevice reports containing keyed app states can be retrieved through various API calls for monitoring app behavior and managed configuration status.\u003c/p\u003e\n"],["\u003cp\u003eKeyed app states provide valuable information, including severity level, timestamps, and optional messages or machine-readable data, enabling EMMs to display meaningful feedback to IT admins.\u003c/p\u003e\n"],["\u003cp\u003eEMMs should prioritize alerting IT admins to errors indicated by keyed app states and ensure timely updates when errors are resolved to facilitate efficient device management and troubleshooting.\u003c/p\u003e\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\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 enterprises](#display_app_feedback_to_enterprises).\n\nEnable device reports\n---------------------\n\nApps send keyed app states on a per-device basis. Before any keyed app states\nare accepted from any of the apps on the device, you need to enable the device\nreports for a device. Until the policy is updated on the device, any keyed app\nstates are ignored and lost forever. Enable device reports **before**\ncompleting device enrollment, as early as possible in the enrollment\nprocess. This ensures that you receive app feedback generated during device\nenrollment and that no keyed app states are lost.\n\n- Call [`devices.update()`](/android/work/play/emm-api/v1/devices/update), setting `policy.deviceReportPolicy` to `\"deviceReportEnabled\"`.\n\nRetrieve device reports\n-----------------------\n\nThere are several ways to retrieve a device report:\n\n- To retrieve device reports along with other notifications, call [`enterprises.pullNotificationSet()`](/android/work/play/emm-api/v1/enterprises/pullNotificationSet). In the response, each `deviceReportUpdateEvent` denotes a device report.\n- To retrieve a device report updated with the latest keyed app states for a specified device, call [`devices.get()`](/android/work/play/emm-api/v1/devices/get).\n- To force a device to upload the latest app states, call [`devices.forceReportUpload()`](/android/work/play/emm-api/v1/devices/forceReportUpload). This method uploads a report containing any changes in app states on the device since the last report was generated.\n\n| **Note:** You can call [`devices.forceReportUpload()`](/android/work/play/emm-api/v1/devices/forceReportUpload) up to three times every 24 hours for a given device. Typically, the device uploads app feedback at least once per day. Calling `devices.forceReportUpload()` triggers the device to upload app feedback as soon as possible. The device requires connectivity to ensure timely app feedback delivery. Keep in mind that method uses time, data, and battery on the device. Therefore, limit your usage of this method to infrequent actions that require timely delivery of app feedback.\n\nView keyed app states\n---------------------\n\nDevice reports are a part of device resources. Reports include an `appState`\nobject for each app (package) installed on the device or in its work profile.\nKeyed app states (`keyedAppState`) for a given package are listed in\n`appState` object, like in the example below: \n\n {\n \"result\":{\n \"kind\":\"androidenterprise#device\",\n \"report\":{\n \"appState\":[\n {\n \"keyedAppState\":[\n {\n \"severity\":\"severityError\",\n \"data\":\"user\",\n \"message\":\"Username or password are incorrect\",\n \"key\":\"account\",\n \"stateTimestampMillis\":\"1556206406926\"\n }\n ],\n \"packageName\":\"com.google.android.feedbacktestapp\"\n }\n ],\n \"lastUpdatedTimestampMillis\":\"1556206407685\"\n },\n \"androidId\":\"32714368a0ad8ad5\",\n \"managementType\":\"managedProfile\",\n \"policy\":{\n \"deviceReportPolicy\":\"deviceReportEnabled\"\n }\n }\n }\n\nEach keyed app states contains 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| `stateTimestampMillis` | The timestamp (in milliseconds) indicating when the app state was last updated on the device. |\n| `lastUpdatedTimestampMillis` | The timestamp (in milliseconds) indicating when the device last uploaded keyed app states. |\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/work/play/emm-api/managed-configurations#specify_managed_configurations) for an app.\n2. In the backend, you [send the configurations to the app](/android/work/play/emm-api/managed-configurations#apply_managed_configurations).\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](#retrieve_device_reports).\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 send a follow-up state with the same key\nas the original error state and an updated severity of `INFO`. EMMs should\n**always** inform organizations as soon as an error is corrected. For example,\nremove the error from your console's error dashboard or mark it as resolved.\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."]]