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.
Un'app può inviare il primo feedback immediato soltanto una volta al minuto. I feedback generati durante il periodo di assestamento verranno messi in coda e inviati completamente al termine di questo periodo. Ad esempio, quando il feedback viene generato 3 volte a [t=0s;10s;15s] con un periodo di attesa di 1 minuto: il primo feedback immediato verrà inviato a [t=0s], il secondo e il terzo feedback a [t=60s].
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 nella sezione Mostra feedback a
aziendali.
Attiva i report sui dispositivi
Le app inviano gli stati con chiavi in base al dispositivo. Gli stati sono inclusi in
report sui dispositivi. Per attivare i report per un dispositivo:
Visualizzazione degli stati delle app con chiave nei report sui dispositivi
I report sui dispositivi sono disponibili sotto forma di risorse per dispositivi.
Gli stati delle app con chiave vengono raggruppati per nome del pacchetto nella sezione report applicazione, come mostrato nell'esempio seguente:
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".
createTime
Il timestamp che indica quando è stato creato lo stato dell'app sul dispositivo.
lastUpdateTime
Timestamp che indica la data dell'ultimo aggiornamento dello stato dell'app sul dispositivo.
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:
Nel backend, utilizzi ApplicationPolicy
per inviare le configurazioni all'app.
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).
Per visualizzare questi stati delle app con chiave, recupera un report sul dispositivo.
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
stessa chiave dello stato di errore originale e con una gravità aggiornata pari a INFO. EMM
devono sempre informare le organizzazioni non appena viene corretto un errore. Per
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 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."]]