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.
Một ứng dụng chỉ có thể gửi phản hồi tức thì đầu tiên mỗi phút một lần. Các ý kiến phản hồi được tạo trong khoảng thời gian chờ sẽ được đưa vào hàng đợi và gửi toàn bộ khi khoảng thời gian chờ kết thúc. Ví dụ: khi phản hồi được tạo 3 lần tại [t=0s;10s;15s] với khoảng thời gian chờ là 1 phút: phản hồi tức thì đầu tiên sẽ được gửi vào thời điểm [t=0s], phản hồi thứ hai và thứ ba tại [t=60s].
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ị. Các tiểu bang được bao gồm trong
báo cáo thiết bị. Cách bật tính năng báo cáo cho một thiết bị:
Xem trạng thái ứng dụng được khoá trong báo cáo thiết bị
Báo cáo thiết bị có sẵn dưới dạng tài nguyên thiết bị.
Các trạng thái ứng dụng chính được nhóm theo tên gói trong phần báo cáo ứng dụng, như minh hoạ trong ví dụ bên dưới:
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".
createTime
Dấu thời gian cho biết thời điểm tạo trạng thái ứng dụng trên thiết bị.
lastUpdateTime
Dấu thời gian cho biết thời điểm cập nhật trạng thái ứng dụng gần đây nhất trên thiết bị.
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ụ:
Một quản trị viên CNTT dùng bảng điều khiển EMM của bạn để
đặt cấu hình được quản lý
cho một ứng dụng.
Trong phần phụ trợ, bạn sử dụng ApplicationPolicy
để gửi cấu hình đến ứng dụng.
Ứ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).
Để xem các trạng thái ứng dụng có khoá này, bạn hãy truy xuất báo cáo thiết bị.
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 khắc phục, ứng dụng sẽ gửi trạng thái theo dõi cùng với
khoá giống như trạng thái lỗi ban đầu và mức độ nghiêm trọng cập nhật của INFO. EMM
phải luôn thông báo cho tổ chức ngay khi sửa lỗi. Cho
Ví dụ: xoá lỗi khỏi trang tổng quan về lỗi của 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: 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."]]
