일부 앱은 키 지정 앱 형태로 EMM에 의견을 보낼 수 있습니다.
상태가 될 수 있습니다. 키가 있는 앱 상태는 고유 식별자 (키)로 구성되며,
해당 메시지 (선택사항), 컴퓨터가 읽을 수 있는 데이터 (선택사항), 심각도
확인할 수 있습니다 이러한 파일을 보내려면 앱이
Enterprise Jetpack 라이브러리
EMM은 주요 앱 상태의 데이터를 사용하여 IT 관리자가 계속
앱을 최신 버전으로 유지합니다. 예시
기업에 의견 표시에 설명되어 있습니다.
기기 보고서 사용 설정
앱은 기기별로 키 앱 상태를 전송합니다. 주요 앱 상태 이전
기기에 설치된 앱에서 수락된 경우 기기를 사용 설정해야 합니다.
보고서를 생성할 수 있습니다. 기기에서 정책이 업데이트될 때까지 모든 키 앱은
상태가 무시되고 영원히 사라집니다. 다음 날짜 이전에 기기 보고서 사용 설정
최대한 빨리 기기 등록 완료
프로세스입니다 이렇게 하면 기기 중에 생성된 앱 피드백을 받을 수 있습니다.
키 지정된 앱 상태가 손실되지 않습니다.
기기 보고서는 기기 리소스의 일부입니다. 보고서에는 appState가 포함됩니다.
기기 또는 직장 프로필에 설치된 각 앱 (패키지)에 대한 객체를 정의합니다.
지정된 패키지의 키가 지정된 앱 상태 (keyedAppState)가 다음에 나열됩니다.
appState 객체를 반환합니다.
{"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"}}}
키가 지정된 각 앱 상태는 다음과 같은 항목을 포함합니다.
필드
설명
key
상태를 식별하는 고유 키입니다.
severity
상태의 심각도: INFO은 정보 메시지를 나타냅니다. 예를 들어 관리 구성이 성공적으로 설정된 경우입니다. ERROR는 기업에서 문제를 해결하기 위해 조치를 취해야 함을 나타냅니다. 예를 들어 관리 구성을 설정할 수 없는 경우입니다.
message
앱 상태에 관한 세부정보를 제공하는 문자열입니다(선택사항). 앱 개발자는 이 필드를 사용자 대상 메시지로 처리하는 것이 좋습니다.
data
EMM에 컴퓨터가 읽을 수 있는 앱 상태 세부정보를 제공하는 문자열입니다(선택사항). 예를 들어 IT 관리자가 콘솔에서 쿼리할 수 있는 값(예: 'Battery_warning data < 10").
stateTimestampMillis
앱 상태가 기기에서 마지막으로 업데이트된 시간을 나타내는 타임스탬프 (밀리초)입니다.
lastUpdatedTimestampMillis
기기에서 키 앱 상태를 마지막으로 업로드한 시점을 나타내는 타임스탬프 (밀리초)입니다.
기업에 앱 의견 표시
앱에서 여러 가지 이유로 의견을 보낼 수 있습니다. 그러나 가장 일반적인 용도는
주요 앱 상태를 전송하는 경우
구성할 수 있습니다 예를 들면 다음과 같습니다.
[null,null,["최종 업데이트: 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."]]
