بازیابی بازخورد از برنامه ها، بازیابی بازخورد از برنامه ها
با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
برخی از برنامه‌ها می‌توانند به‌صورت حالت‌های برنامه کلیددار به EMM بازخورد ارسال کنند. یک وضعیت برنامه کلیددار از یک شناسه (کلید)، پیام متناظر (اختیاری)، داده‌های قابل خواندن توسط ماشین (اختیاری)، وضعیت شدت، و مهر زمانی تشکیل شده است. برای ارسال آنها، یک برنامه باید با کتابخانه Enterprise Jetpack ادغام شود.
یک برنامه فقط می تواند هر دقیقه یک بار اولین بازخورد فوری را ارسال کند. بازخورد ایجاد شده در طول دوره خنک شدن در صف قرار می گیرد و با پایان دوره خنک شدن به طور کلی ارسال می شود. به عنوان مثال، وقتی بازخورد 3 بار در [t=0s;10s;15s] با یک دوره خنک شدن 1 دقیقه ایجاد می شود: اولین بازخورد فوری در [t=0s]، بازخورد دوم و سوم در [t= ارسال می شود. دهه 60].
به‌عنوان یک EMM، می‌توانید از داده‌های وضعیت‌های برنامه کلیددار استفاده کنید تا سرپرستان فناوری اطلاعات را با برنامه‌های نصب‌شده در دستگاه‌ها و نمایه‌های مدیریت‌شده به‌روز نگه دارید. نمونه ای از نحوه عملکرد این کار در نمایش بازخورد به شرکت ها توضیح داده شده است.
فعال کردن گزارش های دستگاه
برنامه‌ها وضعیت‌های برنامه کلیددار را بر اساس هر دستگاه ارسال می‌کنند. ایالات در گزارش های دستگاه گنجانده شده است. برای فعال کردن گزارش برای یک دستگاه:
وضعیت های برنامه کلیدی را در گزارش های دستگاه مشاهده کنید
گزارش های دستگاه در قالب منابع دستگاه موجود است. حالت‌های برنامه کلیددار بر اساس نام بسته در بخش گزارش برنامه گروه‌بندی می‌شوند، همانطور که در مثال زیر نشان داده شده است:
شدت وضعیت: INFO نشان دهنده یک پیام آموزنده است. به عنوان مثال اگر یک پیکربندی مدیریت شده با موفقیت تنظیم شود. ERROR نشان می دهد که شرکت باید برای اصلاح یک مشکل اقدام کند. به عنوان مثال، اگر یک پیکربندی مدیریت شده تنظیم نشد.
message
یک رشته اختیاری که جزئیات مربوط به وضعیت برنامه را ارائه می دهد. به توسعه دهندگان برنامه توصیه می شود که این قسمت را به عنوان پیامی برای کاربر در نظر بگیرند.
data
یک رشته اختیاری که جزئیات قابل خواندن توسط رایانه را در مورد وضعیت برنامه به EMM ها ارائه می دهد. به‌عنوان مثال، مقداری که یک سرپرست فناوری اطلاعات می‌تواند در کنسول شما در برابر آن پرس و جو کند، مانند «به من اطلاع بده اگر داده‌های هشدار باتری < 10 باشد».
createTime
مهر زمانی که نشان‌دهنده زمان ایجاد وضعیت برنامه در دستگاه است.
lastUpdateTime
مهر زمانی که آخرین به‌روزرسانی وضعیت برنامه در دستگاه را نشان می‌دهد.
نمایش بازخورد برنامه به شرکت ها
برنامه ها به دلایل مختلفی می توانند بازخورد ارسال کنند. با این حال، رایج‌ترین مورد استفاده برای ارسال حالت‌های برنامه کلیددار، ارائه بازخورد درباره پیکربندی‌های مدیریت‌شده است. به عنوان مثال:
در باطن، از ApplicationPolicy برای ارسال تنظیمات به برنامه استفاده می کنید.
برنامه سعی می کند تنظیمات را اعمال کند. برای هر پیکربندی، برنامه یک وضعیت برنامه کلیددار را ارسال می کند که وضعیت آن را نشان می دهد (به عنوان مثال، یک پیام تأیید یا اعلان خطا).
برای مشاهده این حالت‌های برنامه کلیددار، یک گزارش دستگاه را بازیابی می‌کنید.
کنسول EMM شما با استفاده از اطلاعات حالت‌های برنامه کلیدی، وضعیت پیکربندی‌های مدیریت شده را به روشی کاربرپسند نمایش می‌دهد.
به مدیران فناوری اطلاعات در مورد خطاها هشدار دهید
یک وضعیت برنامه کلیدی با ERROR شدید نشان می‌دهد که سازمان باید برای اصلاح یک مشکل اقدامی انجام دهد. EMMها باید همیشه سازمان‌ها را از طریق کنسول EMM یا وسایل دیگر در مورد خطاها آگاه کنند. برای مثال، کنسول EMM شما می‌تواند داشبورد خطا را نمایش دهد که به بازخورد یک دستگاه معین دارای خطا پیوند می‌دهد.
اگر یک وضعیت خطا تصحیح شود، برنامه یک وضعیت پیگیری را با همان کلید وضعیت خطای اصلی و شدت به روز شده INFO ارسال می‌کند. EMM ها باید همیشه به محض تصحیح یک خطا، سازمان ها را مطلع کنند. به عنوان مثال، خطا را از داشبورد خطای کنسول خود حذف کنید یا آن را به عنوان حل شده علامت بزنید.
تاریخ آخرین به‌روزرسانی 2025-01-18 بهوقت ساعت هماهنگ جهانی.
[null,null,["تاریخ آخرین به‌روزرسانی 2025-01-18 بهوقت ساعت هماهنگ جهانی."],[[["\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,["Some 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\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\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\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\nAlert 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."]]
