Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Einige Apps sind in der Lage, Feedback in Form von verschlüsselten Apps an EMMs zu senden.
Bundesländer. Ein verschlüsselter App-Status besteht aus einer eindeutigen Kennung (Schlüssel),
entsprechende Nachricht (optional), maschinenlesbare Daten (optional), Schweregrad
Status und Zeitstempel. Um sie zu senden, muss eine App in das
Enterprise Jetpack-Bibliothek
Das erste sofortige Feedback kann von einer App nur einmal pro Minute gesendet werden. Während der Wartezeit generiertes Feedback wird in die Warteschlange gestellt und nach Ablauf der Wartezeit zusammen gesendet. Wenn Feedback beispielsweise dreimal um [t=0s;10s;15s] mit einer Wartezeit von 1 Minute dreimal generiert wird, wird das erste sofortige Feedback um [t=0s], das zweite und dritte um [t=60s] gesendet.
Als EMM können Sie die Daten aus codierten App-Status nutzen, um die IT-Administratoren
die auf verwalteten Geräten und Profilen installierten Apps auf dem neuesten Stand sind. Beispiel
Weitere Informationen dazu finden Sie unter Feedback anzeigen
Unternehmen.
Geräteberichte aktivieren
Apps senden schlüsselbasierte App-Status auf Gerätebasis. Die Bundesstaaten sind in
Geräteberichten. So aktivieren Sie die Berichterstellung für ein Gerät:
Geräteberichte stehen in Form von Geräteressourcen zur Verfügung.
Schlüsselbasierte App-Status werden wie im folgenden Beispiel im Abschnitt Anwendungsbericht nach Paketnamen gruppiert:
Der eindeutige Schlüssel zur Identifizierung des Status.
severity
Der Schweregrad des Status: INFO zeigt eine informative Meldung an. Beispiel: Eine verwaltete Konfiguration wurde festgelegt. ERROR gibt an, dass das Unternehmen Maßnahmen ergreifen muss, um ein Problem zu beheben. Beispiel: Eine verwaltete Konfiguration konnte nicht festgelegt werden.
message
Ein optionaler String, der Details zum App-Status enthält. App-Entwicklern wird empfohlen, dieses Feld als Nachricht für Nutzer zu behandeln.
data
Ein optionaler String, der für EMMs computerlesbare Details zum App-Status bereitstellt. Beispiel: Ein Wert, den ein IT-Administrator in Ihrer Konsole abfragen könnte, wie z. B. „notify me if the battery_warning data < 10".
createTime
Der Zeitstempel, der angibt, wann der App-Status auf dem Gerät erstellt wurde.
lastUpdateTime
Zeitstempel, der angibt, wann der App-Status zuletzt auf dem Gerät aktualisiert wurde.
Unternehmen Feedback zur App anzeigen
Apps können Feedback aus verschiedenen Gründen senden. Am häufigsten werden jedoch
ist das Senden von verschlüsselten App-Zuständen sinnvoll,
Konfigurationen. Beispiel:
Im Back-End verwenden Sie ApplicationPolicy.
um die Konfigurationen
an die App zu senden.
Die Anwendung versucht, die Konfigurationen anzuwenden. Für jede Konfiguration
sendet einen verschlüsselten App-Status, der seinen Status angibt (z. B. eine Bestätigung
Fehlermeldung oder Fehlermeldung).
Wenn Sie diese verschlüsselten App-Status aufrufen möchten, rufen Sie einen Gerätebericht ab.
Anhand von Informationen aus den codierten App-Zuständen werden in Ihrer EMM-Konsole
der verwalteten Konfigurationen
auf nutzerfreundliche Weise an.
IT-Administratoren über Fehler informieren
Der verschlüsselte App-Status mit dem Schweregrad ERROR weist darauf hin, dass das Unternehmen
um ein Problem zu beheben. EMM-Anbieter sollten Unternehmen immer benachrichtigen.
entweder über die EMM-Konsole
oder auf andere Weise auf Fehler zu schließen. Beispiel: Ihre
In der EMM-Konsole kann ein Fehler-Dashboard angezeigt werden, das mit dem Feedback für einen
auf einem bestimmten Gerät mit Fehlern.
Wenn ein Fehlerstatus behoben wurde, sendet die App einen Follow-up-Status mit dem
denselben Schlüssel wie der ursprüngliche Fehlerstatus und der aktualisierte Schweregrad INFO. EMM-Anbieter
sollte Unternehmen immer informieren, sobald ein Fehler behoben wurde. Für
entfernen Sie den Fehler aus dem Fehler-Dashboard der Konsole oder markieren Sie ihn als
behoben.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Benötigte Informationen nicht gefunden","missingTheInformationINeed","thumb-down"],["Zu umständlich/zu viele Schritte","tooComplicatedTooManySteps","thumb-down"],["Nicht mehr aktuell","outOfDate","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Problem mit Beispielen/Code","samplesCodeIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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."]]
