تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
بعض التطبيقات قادرة على إرسال الملاحظات إلى موفِّري إدارة الخدمات الجوّالة للمؤسسات (EMM) في شكل تطبيق مستنِد إلى البيانات
الحالات. تتكوّن حالة التطبيق الأساسية من معرّف فريد (مفتاح).
الرسالة المقابلة (اختيارية)، البيانات التي يمكن للآلة قراءتها (اختيارية)، مستوى الخطورة
والحالة والطابع الزمني. لإرسالها، يجب دمج التطبيق مع
مكتبة 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) حول حالة التطبيق. على سبيل المثال، قيمة يمكن لمشرف تكنولوجيا المعلومات طلب البحث عنها في وحدة التحكّم، مثل "إرسال إشعار إليّ إذا كانت بيانات البطارية_warning < 10 بوصة.
stateTimestampMillis
الطابع الزمني (بالمللي ثانية) الذي يشير إلى تاريخ آخر تعديل لحالة التطبيق على الجهاز
lastUpdatedTimestampMillis
الطابع الزمني (بالمللي ثانية) الذي يشير إلى وقت آخر حالة تم فيها تحميل التطبيق باستخدام المفتاح على الجهاز
عرض ملاحظات التطبيق للمؤسسات
يمكن للتطبيقات إرسال ملاحظات لأسباب مختلفة. ومع ذلك، فإن الاستخدام الأكثر شيوعًا
بالنسبة إلى إرسال حالات التطبيق الأساسية، هو تقديم ملاحظات حول الحسابات المُدارة
الإعدادات. على سبيل المثال:
يستخدم أحد مشرفي تكنولوجيا المعلومات وحدة تحكّم إدارة الخدمات الجوّالة للمؤسسات (EMM) من أجل ضبط الإعدادات المُدارة لأحد التطبيقات.
يحاول التطبيق تطبيق الإعدادات. بالنسبة لكل تهيئة، يتجاهل التطبيق
يرسل حالة التطبيق الأساسية إلى حالته (على سبيل المثال، رسالة تأكيد
رسالة أو إشعار خطأ).
باستخدام معلومات من حالات التطبيق الأساسية، تعرض وحدة تحكّم إدارة الخدمات الجوّالة للمؤسسات (EMM)
حالة عمليات الضبط المُدارة بطريقة سهلة الاستخدام.
تنبيه مشرفي تكنولوجيا المعلومات بالأخطاء
تشير حالة التطبيق الرئيسية ذات الخطورة ERROR إلى أنّ المؤسسة على حاجة إلى اتخاذ
الإجراءات من أجل تصحيح مشكلة. على إدارة الخدمات الجوّالة للمؤسسات (EMM) تنبيه المؤسسات دائمًا
إلى الأخطاء، إما من خلال وحدة التحكم في إدارة الخدمات الجوّالة للمؤسسات (EMM) أو وسائل أخرى. على سبيل المثال،
قد تعرض وحدة التحكم في إدارة الخدمات الجوّالة للمؤسسات (EMM) لوحة بيانات بالخطأ ترتبط بالملاحظات
الجهاز المعين الذي يحتوي على أخطاء.
إذا تم تصحيح حالة خطأ، يرسل التطبيق حالة متابعة باستخدام المفتاح نفسه.
كحالة الخطأ الأصلية وتعديل درجة الخطورة INFO. على موفِّري إدارة الخدمات الجوّالة للمؤسسات (EMM)
دائمًا إعلام المؤسسات فور تصحيح الخطأ. على سبيل المثال:
قم بإزالة الخطأ من لوحة بيانات الخطأ بوحدة التحكم أو ضع علامة عليه كـ تم حله.
تاريخ التعديل الأخير: 2025-08-31 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-08-31 (حسب التوقيت العالمي المتفَّق عليه)"],[[["\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."]]
