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.
Una app solo puede enviar los primeros comentarios inmediatos una vez por minuto. Los comentarios que se generen durante el período de inactividad se agregarán a la cola y se enviarán por completo cuando este finalice. Por ejemplo, cuando los comentarios se generan 3 veces en [t=0s;10s;15s] con un período de inactividad de 1 minuto, el primer comentario inmediato se enviará a las [t=0s], el segundo y el tercero a los [t=60s].
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
de cómo podría funcionar esto se describe en Mostrar comentarios a
empresariales.
Habilitar los informes de dispositivos
Las apps envían estados de la app con clave por dispositivo. Los estados se incluyen en
informes de dispositivos. Para habilitar los informes en un dispositivo, haz lo siguiente:
Cómo ver estados de apps con clave en los informes de dispositivos
Los informes de dispositivos están disponibles como recursos de dispositivos.
Los estados de la app con clave se agrupan por nombre de paquete en la sección del informe de la aplicación, como se muestra en el siguiente ejemplo:
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".
createTime
Es la marca de tiempo que indica cuándo se creó el estado de la app en el dispositivo.
lastUpdateTime
Marca de tiempo que indica cuándo se actualizó por última vez el estado de la app en el dispositivo.
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:
En el backend, usas ApplicationPolicy
para enviar la configuración a la app.
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).
Para ver estos estados de app con clave, debes recuperar un informe del dispositivo.
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 enviará un estado de seguimiento con el
la misma clave que el estado de error original y una gravedad actualizada de INFO. EMM
informar siempre a las organizaciones tan pronto como se corrija un error Para
ejemplo, quita el error del panel de errores de tu consola o márcalo 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: 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."]]