# Retrieve feedback from apps Some apps are capable of sending feedback to EMMs in the form of **keyed app states** . A keyed app state is made up of a unique identifier (key), corresponding message (optional), machine-readable data (optional), severity status, and timestamp. To send them, an app needs to integrate with the [Enterprise Jetpack library](https://developer.android.com/reference/androidx/enterprise/feedback/package-summary). An 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\]. As an EMM, you can use the data from keyed app states to keep IT admins up-to-date with the apps installed on managed devices and profiles. An example of how this might work is described in [Display feedback to enterprises](https://developers.google.com/android/management/app-feedback#display_app_feedback_to_enterprises). ## Enable device reports Apps send keyed app states on a per-device basis. The states are included in device reports. To enable reporting for a device: 1. Follow the instructions for setting up [Pub/Sub notifications](https://developers.google.com/android/management/notifications) for an enterprise. In [Step 5](https://developers.google.com/android/management/notifications#5_update_enterprise_to_support_notifications), include [`STATUS_REPORT`](https://developers.google.com/android/management/reference/rest/v1/enterprises#NotificationType) in `enabledNotificationTypes`. 2. For each device, update the device policy: set [`StatusReportingSettings.applicationReportsEnabled`](https://developers.google.com/android/management/reference/rest/v1/enterprises.policies#statusreportingsettings) to `true`. You can now [use the Pub/Sub API to get device report notifications](https://developers.google.com/android/management/notifications#6_use_the_pubsub_api_to_get_notifications). Or, to review a device's latest report at any time, call [`devices.get()`](https://developers.google.com/android/management/reference/rest/v1/enterprises.devices/get). ## View keyed app states in device reports Device reports are available in the form of [device resources](https://developers.google.com/android/management/reference/rest/v1/enterprises.devices). Keyed app states are grouped by package name in the [application report](https://developers.google.com/android/management/reference/rest/v1/enterprises.devices#applicationreport) section, as shown in the example below: { "applicationReports":[ { "packageName": "pkg1", "versionCode": 101, "keyedAppStates":[ { "key": "key1", "severity": INFO, "message": "message1", "data": "data1", "createTime": "2018-10-01T15:01:22.027623745Z", "lastUpdateTime": "2018-10-02T15:01:23.045123456Z" } ] } ] } Each [keyed app state](https://developers.google.com/android/management/reference/rest/v1/enterprises.devices#KeyedAppState) contains the following: | Field | Description | |---|---| | `key` | The unique key identifying the state. | | `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. | | `message` | An optional string providing details about the app state. App developers are advised to treat this field as a user-facing message. | | `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 \< 10". | | `createTime` | The timestamp indicating when the app state was created on the device. | | `lastUpdateTime` | Timestamp indicating when the app state was last updated on the device. | ## Display app feedback to enterprises Apps can send feedback for a variety of reasons. However, the most common use case for sending keyed app states is to provide feedback about managed configurations. For example: 1. An IT admin uses your EMM console to [set managed configurations](https://developers.google.com/android/management/managed-configurations-iframe) for an app. 2. In the backend, you use [ApplicationPolicy](https://developers.google.com/android/management/reference/rest/v1/enterprises.policies#ApplicationPolicy) to send the configurations to the app. 3. 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). 4. To view these keyed app states, you retrieve a device report. 5. Using information from the keyed app states, your EMM console displays the status of the managed configurations in a user-friendly way. ### Alert IT admins to errors A keyed app state with severity `ERROR` indicates the organization needs to take action in order to correct a problem. EMMs should **always** alert organizations to errors, either through their EMM console or other means. For example, your EMM console could display an error dashboard that links to the feedback for a given device with errors. If an error state is corrected, the app will send a follow-up state with the same key as the original error state and an updated severity of `INFO`. EMMs should **always** inform organizations as soon as an error is corrected. For example, remove the error from your console's error dashboard or mark it as resolved. > [!IMPORTANT] > **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.