Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Một số ứng dụng có thể gửi phản hồi cho dịch vụ EMM dưới dạng ứng dụng khoá
các trạng thái. Trạng thái ứng dụng có khoá được tạo thành từ một giá trị nhận dạng duy nhất (khoá),
thông báo tương ứng (không bắt buộc), dữ liệu mà máy có thể đọc (không bắt buộc), mức độ nghiêm trọng
trạng thái và dấu thời gian. Để gửi các đường liên kết này, ứng dụng cần tích hợp với
Thư viện Jetpack dành cho doanh nghiệp.
Trong vai trò EMM, bạn có thể dùng dữ liệu từ các trạng thái ứng dụng có khoá để giúp quản trị viên CNTT
cập nhật các ứng dụng được cài đặt trên hồ sơ và thiết bị được quản lý. Ví dụ
về cách hoạt động của tính năng này được mô tả trong phần Hiển thị phản hồi cho doanh nghiệp.
Bật tính năng báo cáo trên thiết bị
Các ứng dụng gửi trạng thái ứng dụng đã khoá trên cơ sở từng thiết bị. Trước bất kỳ trạng thái nào của ứng dụng được khoá
được chấp nhận từ bất kỳ ứng dụng nào trên thiết bị, bạn cần bật thiết bị
báo cáo cho một thiết bị. Cho đến khi chính sách này được cập nhật trên thiết bị, mọi ứng dụng có khoá
các trạng thái sẽ bị bỏ qua và bị mất vĩnh viễn. Bật tính năng báo cáo thiết bị trước
hoàn tất quy trình đăng ký thiết bị càng sớm càng tốt trong quá trình đăng ký
của chúng tôi. Điều này đảm bảo rằng bạn nhận được phản hồi về ứng dụng được tạo trong khi thiết bị
đăng ký và không mất trạng thái ứng dụng đã khoá.
Gọi devices.update(),
đặt policy.deviceReportPolicy thành "deviceReportEnabled".
Truy xuất báo cáo thiết bị
Có một số cách để truy xuất báo cáo thiết bị:
Để truy xuất báo cáo thiết bị cùng với các thông báo khác, hãy gọi
enterprises.pullNotificationSet().
Trong phản hồi, mỗi deviceReportUpdateEvent biểu thị một báo cáo thiết bị.
Để truy xuất báo cáo thiết bị được cập nhật với trạng thái ứng dụng có khoá mới nhất cho một
thiết bị được chỉ định, hãy gọi devices.get().
Để buộc thiết bị tải lên các trạng thái mới nhất của ứng dụng, hãy gọi
devices.forceReportUpload().
Phương thức này tải một báo cáo lên chứa mọi thay đổi về trạng thái ứng dụng trên
thiết bị kể từ khi báo cáo cuối cùng được tạo.
Xem trạng thái của ứng dụng được khoá
Báo cáo thiết bị là một phần của tài nguyên thiết bị. Báo cáo có một appState
cho mỗi ứng dụng (gói) được cài đặt trên thiết bị hoặc trong hồ sơ công việc của thiết bị.
Các trạng thái ứng dụng đã khoá (keyedAppState) của một gói nhất định được liệt kê trong
đối tượng appState như trong ví dụ dưới đây:
{"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"}}}
Mỗi trạng thái của ứng dụng được khoá đều chứa những nội dung sau:
Trường
Mô tả
key
Khoá duy nhất xác định trạng thái.
severity
Mức độ nghiêm trọng của trạng thái: INFO cho biết một thông báo chứa nhiều thông tin. Ví dụ: nếu đặt thành công một cấu hình được quản lý. ERROR cho biết doanh nghiệp cần hành động để khắc phục sự cố. Ví dụ: Nếu không thiết lập được một cấu hình được quản lý.
message
Chuỗi không bắt buộc cung cấp thông tin chi tiết về trạng thái ứng dụng. Các nhà phát triển ứng dụng nên xem trường này là một thông báo dành cho người dùng.
data
Một chuỗi không bắt buộc cung cấp thông tin chi tiết mà máy tính có thể đọc được cho đội ngũ EMM về trạng thái ứng dụng. Ví dụ: một giá trị mà quản trị viên CNTT có thể truy vấn trong bảng điều khiển của bạn, chẳng hạn như "thông báo cho tôi nếu dữ liệu Battery_warning < 10".
stateTimestampMillis
Dấu thời gian (tính bằng mili giây) cho biết thời điểm gần đây nhất trạng thái ứng dụng được cập nhật trên thiết bị.
lastUpdatedTimestampMillis
Dấu thời gian (tính bằng mili giây) cho biết thời điểm gần đây nhất thiết bị tải lên trạng thái của ứng dụng có khoá.
Hiển thị phản hồi về ứng dụng cho doanh nghiệp
Các ứng dụng có thể gửi ý kiến phản hồi vì nhiều lý do. Tuy nhiên, việc sử dụng phổ biến nhất
Trường hợp gửi trạng thái ứng dụng được khoá là cung cấp phản hồi về
. Ví dụ:
Ứng dụng sẽ cố gắng áp dụng các cấu hình. Đối với mỗi cấu hình, ứng dụng
gửi trạng thái ứng dụng được khoá cho biết trạng thái của ứng dụng (ví dụ: xác nhận
thông báo lỗi).
Bảng điều khiển EMM (quản lý thiết bị di động doanh nghiệp) sẽ hiển thị thông tin từ các trạng thái ứng dụng có khoá
trạng thái của các cấu hình được quản lý theo cách thân thiện với người dùng.
Thông báo cho quản trị viên CNTT về lỗi
Trạng thái ứng dụng có khoá với mức độ nghiêm trọng ERROR cho biết tổ chức cần phải thực hiện
để khắc phục sự cố. Dịch vụ EMM (quản lý thiết bị di động doanh nghiệp) phải luôn cảnh báo cho các tổ chức
lỗi, thông qua bảng điều khiển EMM (quản lý thiết bị di động doanh nghiệp) hoặc các phương thức khác. Ví dụ:
Bảng điều khiển EMM (quản lý thiết bị di động doanh nghiệp) có thể hiển thị trang tổng quan về lỗi liên kết đến phản hồi về một
thiết bị cụ thể có lỗi.
Nếu trạng thái lỗi được sửa, ứng dụng sẽ gửi trạng thái theo dõi bằng cùng một khoá
làm trạng thái lỗi ban đầu và mức độ nghiêm trọng đã cập nhật là INFO. EMM nên
luôn thông báo cho tổ chức ngay khi sửa lỗi. Ví dụ:
hãy xoá lỗi đó khỏi trang tổng quan về lỗi trên bảng điều khiển hoặc đánh dấu lỗi là đã được giải quyết.
[[["Dễ hiểu","easyToUnderstand","thumb-up"],["Giúp tôi giải quyết được vấn đề","solvedMyProblem","thumb-up"],["Khác","otherUp","thumb-up"]],[["Thiếu thông tin tôi cần","missingTheInformationINeed","thumb-down"],["Quá phức tạp/quá nhiều bước","tooComplicatedTooManySteps","thumb-down"],["Đã lỗi thời","outOfDate","thumb-down"],["Vấn đề về bản dịch","translationIssue","thumb-down"],["Vấn đề về mẫu/mã","samplesCodeIssue","thumb-down"],["Khác","otherDown","thumb-down"]],["Cập nhật lần gần đây nhất: 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."]]
