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.

An app can only send the first immediate feedback 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.

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 for an enterprise. In Step 5, include STATUS_REPORT in enabledNotificationTypes.
  2. For each device, update the device policy: set StatusReportingSettings.applicationReportsEnabled to true.

You can now use the Pub/Sub API to get device report notifications. Or, to review a device’s latest report at any time, call devices.get().

View keyed app states in device reports

Device reports are available in the form of device resources. Keyed app states are grouped by package name in the application report 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 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 for an app.
  2. In the backend, you use 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.