Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Algunas apps pueden enviar comentarios a EMM en forma de apps con clave
estados. El estado de una app con clave consta de un identificador único (clave)
mensaje correspondiente (opcional), datos aptos para la lectura automática (opcional), gravedad
estado y marca de tiempo. Para enviarlos, una app debe integrarse con el
Biblioteca de Enterprise Jetpack.
Como EMM, puedes usar los datos de los estados de app con clave para mantener a los administradores de TI
actualizada con las apps instaladas en los perfiles y dispositivos administrados. Ejemplo
en Cómo mostrar comentarios a empresas, se describe cómo podría funcionar este proceso.
Habilitar los informes de dispositivos
Las apps envían estados de la app con clave por dispositivo. Antes de cualquier estado de app con clave
desde cualquiera de las apps del dispositivo, debes habilitarlo
informes para un dispositivo. Hasta que se actualice la política en el dispositivo, todas las apps con clave
estados se ignoran y se pierden para siempre. Habilita los informes de dispositivos antes
completar la inscripción del dispositivo lo antes posible
el proceso de administración de recursos. De esta manera, se garantiza que recibas los comentarios de la app generados durante el dispositivo
la inscripción y que no se pierdan los estados de la app con clave.
Llamada a devices.update(),
Estableciendo policy.deviceReportPolicy en "deviceReportEnabled".
Recupera informes de dispositivos
Existen varias formas de recuperar un informe de dispositivo:
Para recuperar informes del dispositivo junto con otras notificaciones, llama
enterprises.pullNotificationSet()
En la respuesta, cada deviceReportUpdateEvent denota un informe de dispositivo.
Para recuperar un informe de dispositivo actualizado con los últimos estados de la app con clave de un
dispositivo especificado, llama a devices.get().
Para forzar a un dispositivo a subir los últimos estados de la app, llama a
devices.forceReportUpload()
Este método sube un informe que contiene los cambios en los estados de la app en la
dispositivo desde que se generó el último informe.
Ver estados de la app con clave
Los informes de dispositivos forman parte de los recursos de estos. Los informes incluyen un appState
para cada app (paquete) instalada en el dispositivo o en su perfil de trabajo.
Los estados de la app con clave (keyedAppState) para un paquete determinado se enumeran en
appState, como en el siguiente ejemplo:
{"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"}}}
Cada estado de app con clave contiene lo siguiente:
Campo
Descripción
key
La clave única que identifica el estado.
severity
La gravedad del estado INFO indica un mensaje informativo. Por ejemplo, si se establece correctamente una configuración administrada. ERROR indica que la empresa debe tomar medidas para corregir un problema. Por ejemplo, si no se pudo establecer una configuración administrada.
message
Una cadena opcional que proporciona detalles sobre el estado de la app. Se recomienda a los desarrolladores de apps que traten este campo como un mensaje para el usuario.
data
Es una cadena opcional que proporciona detalles legibles por computadora a los EMM sobre el estado de la app. Por ejemplo, un valor que un administrador de TI podría consultar en tu consola, como "notify me if the Battery_warning data < 10".
stateTimestampMillis
Es la marca de tiempo (en milisegundos) que indica cuándo se actualizó el estado de la app por última vez en el dispositivo.
lastUpdatedTimestampMillis
Es la marca de tiempo (en milisegundos) que indica la última vez que el dispositivo subió los estados de la app con clave.
Muestra comentarios sobre la app a las empresas
Las apps pueden enviar comentarios por varios motivos. Sin embargo, el uso más común
para enviar estados de app con clave es proporcionar comentarios sobre la actividad
parámetros de configuración. Por ejemplo:
La app intenta aplicar las configuraciones. Para cada configuración, la app
envía un estado de app con clave que indica su estado (por ejemplo, una confirmación
o una notificación de error).
Usando información de los estados de la app con clave, tu consola de EMM muestra la
y el estado de las configuraciones administradas
de una forma fácil de usar.
Alerta a los administradores de TI sobre errores
Un estado de app con clave y gravedad ERROR indica que la organización debe
una acción para corregir un problema. Los EMM siempre deben alertar a las organizaciones
a errores, ya sea a través de su consola de EMM o de otros medios. Por ejemplo, tu
La consola de EMM podría mostrar un panel de errores que se vincula con los comentarios de una
un dispositivo determinado con errores.
Si se corrige un estado de error, la app envía un estado de seguimiento con la misma clave.
como el estado de error original y una gravedad actualizada de INFO. Los EMM deben
siempre informa a las organizaciones tan pronto como se corrija un error. Por ejemplo:
quitarlo del panel de errores de tu consola o marcarlo como resuelto.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Falta la información que necesito","missingTheInformationINeed","thumb-down"],["Muy complicado o demasiados pasos","tooComplicatedTooManySteps","thumb-down"],["Desactualizado","outOfDate","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Problema con las muestras o los códigos","samplesCodeIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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."]]