بازیابی بازخورد از برنامه ها، بازیابی بازخورد از برنامه ها
با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
برخی از برنامه‌ها می‌توانند به‌صورت حالت‌های برنامه کلیددار به EMM بازخورد ارسال کنند. یک وضعیت برنامه کلیددار از یک شناسه (کلید)، پیام متناظر (اختیاری)، داده‌های قابل خواندن توسط ماشین (اختیاری)، وضعیت شدت، و مهر زمانی تشکیل شده است. برای ارسال آنها، یک برنامه باید با کتابخانه Enterprise Jetpack ادغام شود.
به‌عنوان یک EMM، می‌توانید از داده‌های وضعیت‌های برنامه کلیددار استفاده کنید تا سرپرستان فناوری اطلاعات را با برنامه‌های نصب‌شده در دستگاه‌ها و نمایه‌های مدیریت‌شده به‌روز نگه دارید. نمونه ای از نحوه عملکرد این کار در نمایش بازخورد به شرکت ها توضیح داده شده است.
فعال کردن گزارش های دستگاه
برنامه‌ها وضعیت‌های برنامه کلیددار را بر اساس هر دستگاه ارسال می‌کنند. قبل از اینکه هر یک از حالت‌های برنامه کلیددار از هر یک از برنامه‌های موجود در دستگاه پذیرفته شود، باید گزارش‌های دستگاه را برای یک دستگاه فعال کنید. تا زمانی که این خط‌مشی در دستگاه به‌روزرسانی نشود، هر حالت برنامه کلیددار نادیده گرفته می‌شود و برای همیشه از بین می‌رود. گزارش های دستگاه را قبل از تکمیل ثبت نام دستگاه، در اولین فرصت ممکن در فرآیند ثبت نام فعال کنید. این تضمین می‌کند که بازخورد برنامه تولید شده در حین ثبت‌نام دستگاه را دریافت می‌کنید و هیچ حالت برنامه کلیدی از بین نمی‌رود.
devices.update() را فراخوانی کنید، policy.deviceReportPolicy را روی "deviceReportEnabled" تنظیم کنید.
بازیابی گزارش های دستگاه
چندین راه برای بازیابی گزارش دستگاه وجود دارد:
برای بازیابی گزارش‌های دستگاه همراه با سایر اعلان‌ها، با enterprises.pullNotificationSet() تماس بگیرید. در پاسخ، هر deviceReportUpdateEvent یک گزارش دستگاه را نشان می دهد.
برای بازیابی یک گزارش دستگاه به روز شده با آخرین وضعیت های برنامه کلیددار برای یک دستگاه مشخص شده، با devices.get() تماس بگیرید.
برای وادار کردن دستگاه به آپلود آخرین وضعیت های برنامه، با devices.forceReportUpload() تماس بگیرید. این روش گزارشی را آپلود می‌کند که حاوی هرگونه تغییر در وضعیت‌های برنامه در دستگاه از زمان ایجاد آخرین گزارش است.
مشاهده حالت های برنامه کلیددار
گزارش های دستگاه بخشی از منابع دستگاه هستند. گزارش‌ها شامل یک شی 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 ها ارائه می دهد. به‌عنوان مثال، مقداری که یک سرپرست فناوری اطلاعات می‌تواند در کنسول شما در برابر آن پرس و جو کند، مانند «به من اطلاع بده اگر داده‌های هشدار باتری < 10 باشد».
stateTimestampMillis
مهر زمانی (بر حسب میلی ثانیه) که نشان می دهد آخرین بار چه زمانی وضعیت برنامه در دستگاه به روز شده است.
lastUpdatedTimestampMillis
مُهر زمانی (بر حسب میلی ثانیه) که نشان می‌دهد دستگاه آخرین بار چه زمانی برنامه کلیددار را آپلود کرده است.
نمایش بازخورد برنامه به شرکت ها
برنامه ها به دلایل مختلفی می توانند بازخورد ارسال کنند. با این حال، رایج‌ترین مورد استفاده برای ارسال حالت‌های برنامه کلیددار، ارائه بازخورد درباره پیکربندی‌های مدیریت‌شده است. به عنوان مثال:
برنامه سعی می کند تنظیمات را اعمال کند. برای هر پیکربندی، برنامه یک وضعیت برنامه کلیددار را ارسال می کند که وضعیت آن را نشان می دهد (به عنوان مثال، یک پیام تأیید یا اعلان خطا).
کنسول EMM شما با استفاده از اطلاعات حالت‌های برنامه کلیدی، وضعیت پیکربندی‌های مدیریت شده را به روشی کاربرپسند نمایش می‌دهد.
به مدیران فناوری اطلاعات در مورد خطاها هشدار دهید
یک وضعیت برنامه کلیدی با ERROR شدید نشان می‌دهد که سازمان باید برای اصلاح یک مشکل اقدامی انجام دهد. EMMها باید همیشه سازمان‌ها را از طریق کنسول EMM یا وسایل دیگر در مورد خطاها آگاه کنند. برای مثال، کنسول EMM شما می‌تواند داشبورد خطا را نمایش دهد که به بازخورد یک دستگاه معین دارای خطا پیوند می‌دهد.
اگر وضعیت خطا تصحیح شود، برنامه یک وضعیت پیگیری را با همان کلید وضعیت خطای اصلی و شدت به‌روزشده INFO ارسال می‌کند. EMM ها باید همیشه به محض تصحیح یک خطا، سازمان ها را مطلع کنند. به عنوان مثال، خطا را از داشبورد خطای کنسول خود حذف کنید یا آن را به عنوان حل شده علامت بزنید.
تاریخ آخرین به‌روزرسانی 2025-08-29 بهوقت ساعت هماهنگ جهانی.
[null,null,["تاریخ آخرین به‌روزرسانی 2025-08-29 بهوقت ساعت هماهنگ جهانی."],[[["\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."]]
