اعتبارًا من عام 2026، ولضمان اتّساق نموذج التطوير الثابت الأساسي واستقرار المنصة في النظام المتكامل، سننشر رمز المصدر في مشروع Android مفتوح المصدر (AOSP) في الربعَين الثاني والرابع. لبناء مشروع Android مفتوح المصدر والمساهمة فيه، استخدِم android-latest-release. سيشير فرع بيان android-latest-release دائمًا إلى أحدث إصدار تم نشره في مشروع Android مفتوح المصدر. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في مشروع Android مفتوح المصدر.

تستخدم Google تكنولوجيا الذكاء الاصطناعي لترجمة المحتوى إلى لغتك المفضّلة، وقد تتضمّن بعض الأخطاء.

مستند تعريف معايير التوافق مع Android 17

1. مقدمة

يسرد هذا المستند المتطلبات التي يجب استيفاؤها لكي تكون الأجهزة متوافقة مع Android 17.

يتم استخدام الكلمات "يجب" و"يجب ألا" و"مطلوب" و"يجب" و"يجب ألا" و"يُستحسن" و"لا يُستحسن" و"مقترَح" و"يجوز" و "اختياري" وفقًا لمعيار IETF المحدّد في RFC2119.

في هذا المستند، يشير مصطلح "مطوّر الجهاز" أو "المطوّر" إلى الشخص أو المؤسسة التي تطوّر حلاً للأجهزة أو البرامج يعمل بنظام التشغيل Android 17. "تنفيذ الجهاز" أو "التنفيذ" هو حل الأجهزة/البرامج الذي تم تطويره.

لكي تُعدّ الأجهزة متوافقة مع Android 17، يجب أن تستوفي عمليات تنفيذ الأجهزة المتطلبات الواردة في "تعريف التوافق" هذا، بما في ذلك أي مستندات مضمّنة بالإشارة إليها.

في حال كان هذا التعريف أو اختبارات البرامج الموضّحة في الفقرة 10 غير واضحة أو غامضة أو غير مكتملة، تقع على عاتق مطوّر الجهاز مسؤولية ضمان التوافق مع عمليات التنفيذ الحالية.

لهذا السبب، يُعد مشروع Android المفتوح المصدر المرجع والتنفيذ المفضّل لنظام Android. ننصح بشدة مصنّعي الأجهزة بأن يستندوا في عمليات التنفيذ إلى أقصى حد ممكن إلى الرمز المصدر "الأصلي" المتاح من "مشروع Android المفتوح المصدر". على الرغم من أنّه يمكن نظريًا استبدال بعض المكوّنات بتنفيذات بديلة، ننصح بشدة بعدم اتّباع هذه الممارسة، لأنّ اجتياز اختبارات البرنامج سيصبح أكثر صعوبة. يتحمّل المنفِّذ مسؤولية ضمان التوافق السلوكي الكامل مع عملية التنفيذ العادية لنظام Android، بما في ذلك مجموعة أدوات اختبار التوافق وغيرها. أخيرًا، يُرجى العِلم أنّ هذا المستند يحظر بشكل صريح بعض عمليات استبدال المكوّنات وتعديلها.

العديد من المراجع المرتبطة في هذا المستند مستمدّة بشكل مباشر أو غير مباشر من حزمة تطوير البرامج لنظام Android، وستكون متطابقة وظيفيًا مع المعلومات الواردة في مستندات حزمة تطوير البرامج هذه. في أي حالات يتعارض فيها "مستند تعريف التوافق" أو "مجموعة أدوات اختبار التوافق" مع مستندات حزمة تطوير البرامج (SDK)، تُعتبر مستندات حزمة تطوير البرامج هي المرجع الموثوق. تُعدّ أي تفاصيل فنية واردة في المراجع المرتبطة في جميع أنحاء هذا المستند جزءًا من تعريف التوافق هذا.

‫1.1 بنية المستند

‫1.1.1. المتطلبات حسب نوع الجهاز

يحتوي القسم 2 على جميع المتطلبات التي تنطبق على نوع جهاز محدّد. يتم تخصيص كل فقرة فرعية من القسم 2 لنوع جهاز معيّن.

جميع المتطلبات الأخرى التي تنطبق على مستوى العالم على أي عمليات تنفيذ لأجهزة Android مُدرَجة في الأقسام التي تلي الفقرة 2. يُشار إلى هذه المتطلبات باسم "المتطلبات الأساسية" في هذا المستند.

‫1.1.2. معرّف المتطلبات

يتم تعيين معرّف المتطلبات للمتطلبات الإلزامية.

يتم تعيين المعرّف لمتطلبات MUST فقط.
المتطلبات التي يُنصح بها بشدة يتم وضع علامة [SR] عليها، ولكن لا يتم تعيين رقم تعريف لها.
يتألف المعرّف من : معرّف نوع الجهاز - معرّف الحالة - معرّف المتطلبات (مثلاً C-0-1).

يتم تحديد كل معرّف على النحو التالي:

معرّف نوع الجهاز (يمكنك الاطّلاع على مزيد من المعلومات في 2. أنواع الأجهزة)
- C: أساسي (المتطلبات التي يتم تطبيقها على جميع عمليات تنفيذ أجهزة Android)
- H: جهاز Android محمول
- T: جهاز تلفزيون Android
- ج: عملية إعداد Android Automotive
- W: Android Watch implementation
- علامة التبويب: تنفيذ الأجهزة اللوحية التي تعمل بنظام التشغيل Android
رقم تعريف الحالة
- عندما يكون الشرط غير مشروط، يتم ضبط رقم التعريف هذا على 0.
- عندما يكون الشرط مشروطًا، يتم تعيين الرقم 1 للشرط الأول، ثم يتم زيادة الرقم بمقدار 1 ضمن القسم نفسه ونوع الجهاز نفسه.
معرّف المتطلبات
- يبدأ هذا المعرّف من 1 ويزيد بمقدار 1 ضمن القسم نفسه والشرط نفسه.

‫1.1.3. معرّف المتطلبات في القسم 2

تتضمّن أرقام تعريف المتطلبات في القسم 2 جزأين. يتوافق الرقم الأول مع معرّف قسم كما هو موضّح أعلاه. يحدّد الجزء الثاني شكل الجهاز والمتطلبات الخاصة بشكل الجهاز.

معرّف القسم متبوعًا بمعرّف المتطلب الموضّح أعلاه

يتألف المعرّف في القسم 2 مما يلي: معرّف القسم / معرّف نوع الجهاز - معرّف الشرط - معرّف المتطلبات (مثلاً 7.4.3/A-0-1).

2. أنواع الأجهزة

يوفّر "مشروع Android المفتوح المصدر" حزمة برامج يمكن استخدامها مع مجموعة متنوعة من أنواع الأجهزة وأحجامها. لتعزيز الأمان على الأجهزة، من المتوقّع أن يتم تنفيذ حزمة البرامج، بما في ذلك أي نظام تشغيل بديل أو تنفيذ بديل للنواة، في بيئة آمنة كما هو موضّح في القسم 9 وفي مواضع أخرى ضمن مستند تعريف معايير التوافق (CDD) هذا. تتوفّر بعض أنواع الأجهزة التي تتضمّن منظومة متكاملة لتوزيع التطبيقات أفضل نسبيًا.

يوضّح هذا القسم أنواع الأجهزة هذه، بالإضافة إلى المتطلبات والتوصيات الإضافية التي تنطبق على كل نوع من أنواع الأجهزة.

يجب أن تستوفي جميع عمليات تنفيذ أجهزة Android التي لا تنتمي إلى أي من أنواع الأجهزة الموضّحة جميع المتطلبات الواردة في الأقسام الأخرى من "تعريف التوافق".

‫2.1 إعدادات الجهاز

للاطّلاع على الاختلافات الرئيسية في إعدادات الأجهزة حسب نوع الجهاز، راجِع المتطلبات الخاصة بالجهاز الواردة في هذا القسم.

2.2. متطلبات الأجهزة الجوّالة

يشير جهاز Android المحمول باليد إلى تنفيذ جهاز Android يتم استخدامه عادةً عن طريق حمله باليد، مثل مشغّل mp3 أو هاتف أو جهاز لوحي.

يتم تصنيف عمليات تنفيذ أجهزة Android على أنّها أجهزة محمولة إذا استوفت جميع المعايير التالية:

أن يكون مزوّدًا بمصدر طاقة يتيح التنقّل، مثل البطارية
أن يكون حجم الشاشة القُطري الفعلي ضمن النطاق من 4 إلى 8 بوصات
أن تتضمّن واجهة إدخال تعمل باللمس

المتطلبات الإضافية الواردة في بقية هذا القسم خاصة بتطبيقات الأجهزة الجوّالة التي تعمل بنظام التشغيل Android.

2.2.1. الأجهزة

عمليات تنفيذ الأجهزة المحمولة:

‫[7.1.1.1/H-0-1] يجب أن يتضمّن الجهاز شاشة واحدة على الأقل متوافقة مع Android، ويبلغ قياسها 2.2 بوصة على الأقل من الحافة القصيرة و3.4 بوصة من الحافة الطويلة.
‫[7.1.1.3/H-SR-1] يُنصح بشدة بتوفير وسيلة للمستخدمين لتغيير حجم العرض (كثافة الشاشة).
‫[7.1.1.1/H-0-2] يجب أن يتيح الجهاز إنشاء الصور باستخدام وحدة معالجة الرسومات (GPU) في مخازن مؤقتة للرسومات بحجم لا يقل عن أعلى دقة لأي شاشة مدمجة.
‫[7.1.1.1/H-0-3]^* يجب أن يتم ربط كل شاشة UI_MODE_NORMAL يتم توفيرها للتطبيقات التابعة لجهات خارجية بمساحة عرض فعلية غير محجوبة لا تقل عن 2.2 بوصة على الحافة القصيرة و3.4 بوصة على الحافة الطويلة.
[7.1.1.3/H-0-1]^* يجب ضبط DENSITY_DEVICE_STABLE على% 92 أو أكثر من الكثافة الفعلية المادية للشاشة المعنية.

إذا كانت عمليات تنفيذ الأجهزة المحمولة باليد تتضمّن إمكانية استخدام Vulkan، يجب أن تستوفي ما يلي:

[7.1.4.2/H-1-1] يجب استيفاء المتطلبات المحدّدة في الملف الشخصي Android Baseline 2021.

إذا كانت عمليات تنفيذ الأجهزة المحمولة تعلن عن توفير أي واجهة التطبيق الثنائية (ABI) لنظام 64 بت (مع أو بدون أي واجهة التطبيق الثنائية (ABI) لنظام 32 بت) وتعرض false لقيمة ActivityManager.isLowRamDevice()، فإنها:

[7.1.4.2/H-2-1] يجب أن تتوافق الأجهزة مع الإصدار 1.1 من Vulkan أو الإصدارات الأحدث.

إذا كانت عمليات تنفيذ الأجهزة المحمولة تدّعي توفير شاشات بنطاق عالي الديناميكية من خلال Configuration.isScreenHdr()، يجب أن تستوفي ما يلي:

[7.1.4.5/H-1-1] يجب الإعلان عن إتاحة استخدام الإضافات EGL_EXT_gl_colorspace_bt2020_pq وEGL_EXT_surface_SMPTE2086_metadata وEGL_EXT_surface_CTA861_3_metadata وVK_EXT_swapchain_colorspace وVK_EXT_hdr_metadata.

عمليات تنفيذ الأجهزة المحمولة:

‫[7.1.4.6/H-0-1] يجب الإبلاغ عما إذا كان الجهاز يتوافق مع إمكانية إنشاء ملفات تعريف لوحدة معالجة الرسومات من خلال إحدى سمات النظام graphics.gpu.profiler.support.

إذا كانت عمليات تنفيذ الأجهزة المحمولة تعلن عن التوافق من خلال إحدى خصائص النظام graphics.gpu.profiler.support، يجب أن تستوفي ما يلي:

[7.1.4.6/H-1-1] يجب أن يتم عرض بيانات تتبُّع بتنسيق Protobuf كناتج، وتكون هذه البيانات متوافقة مع مخطط عدّادات وحدة معالجة الرسومات ومراحل العرض في وحدة معالجة الرسومات المحدّدة في مستندات Perfetto.
[7.1.4.6/H-1-2] يجب إرسال قيم متوافقة لعدّادات وحدة معالجة الرسومات في الجهاز وفقًا لحزمة gpu counter trace الأولية.
[7.1.4.6/H-1-3] يجب عرض قيم متوافقة لمراحل العرض في وحدة معالجة الرسومات بالجهاز وفقًا لبروتوكول حزمة تتبُّع مراحل العرض.
[7.1.4.6/H-1-4] يجب تسجيل نقطة تتبُّع GPU Frequency بالتنسيق المحدّد: power/gpu_frequency.

عمليات تنفيذ الأجهزة المحمولة:

‫[7.1.5/H-0-1] يجب أن يتضمّن دعمًا لوضع توافق التطبيقات القديمة كما هو موضّح في رمز المصدر المفتوح لنظام التشغيل Android. أي أنّه يجب ألا تغيّر عمليات تنفيذ الأجهزة المشغّلات أو الحدود التي يتم عندها تفعيل وضع التوافق، ويجب ألا تغيّر سلوك وضع التوافق نفسه.
‫[7.2.1/H-0-1] يجب أن يتضمّن دعمًا لتطبيقات محرر أسلوب الإدخال (IME) التابعة لجهات خارجية.
[7.2.3/H-0-2] يجب إرسال كل من حدث الضغط العادي والطويل لوظيفة "الرجوع" (KEYCODE_BACK) إلى التطبيق الذي يعمل في المقدّمة. يجب ألا يستهلك النظام هذه الأحداث، ويمكن أن يتم تشغيلها من خارج جهاز Android (مثل لوحة مفاتيح خارجية متصلة بجهاز Android).
[7.2.3/H-0-3] يجب توفير وظيفة "الشاشة الرئيسية" على جميع الشاشات المتوافقة مع Android التي توفّر الشاشة الرئيسية.
[7.2.3/H-0-4] يجب توفير وظيفة "الرجوع" على جميع الشاشات المتوافقة مع Android ووظيفة "التطبيقات الحديثة" على شاشة واحدة على الأقل من الشاشات المتوافقة مع Android.
‫[7.2.4/H-0-1] يجب أن يتيح إدخال البيانات باستخدام شاشة اللمس.
‫[7.2.4/H-SR-1] يُنصح بشدة بتشغيل تطبيق المساعدة الذي يختاره المستخدم، أي التطبيق الذي ينفّذ VoiceInteractionService أو نشاط يتعامل مع ACTION_ASSIST عند الضغط مع الاستمرار على KEYCODE_MEDIA_PLAY_PAUSE أو KEYCODE_HEADSETHOOK إذا كان النشاط في المقدّمة لا يتعامل مع أحداث الضغط مع الاستمرار هذه.
‫[7.3.1/H-SR-1] يُنصح بشدة بتضمين مقياس تسارع ثلاثي المحاور.

إذا كانت عمليات تنفيذ الأجهزة المحمولة باليد تتضمّن مقياس تسارع ثلاثي المحاور، يجب أن تستوفي ما يلي:

‫[7.3.1/H-1-1] يجب أن يكون الجهاز قادرًا على تسجيل الأحداث بتردد لا يقل عن 100 هرتز.

إذا كانت عمليات تنفيذ الأجهزة المحمولة تتضمّن جهاز استقبال GPS/GNSS وتُبلغ التطبيقات عن الإمكانية من خلال علامة الميزة android.hardware.location.gps، فإنّها:

[7.3.3/H-2-1] يجب إرسال قياسات GNSS فور العثور عليها، حتى إذا لم يتم بعد إرسال موقع جغرافي محسوب من نظام تحديد المواقع العالمي (GPS) أو نظام GNSS.
[7.3.3/H-2-2] يجب أن يتم تسجيل نطاقات زائفة لنظام GNSS ومعدلات النطاقات الزائفة، والتي تكون كافية لاحتساب الموقع الجغرافي في نطاق 20 مترًا والسرعة في نطاق 0.2 متر في الثانية، وذلك بنسبة% 95 على الأقل من الوقت، في ظروف السماء المفتوحة بعد تحديد الموقع الجغرافي، وأثناء الثبات أو الحركة بمعدل تسارع أقل من 0.2 متر في الثانية المربعة.

إذا كانت عمليات تنفيذ الأجهزة المحمولة باليد تتضمّن جيروسكوبًا ثلاثي المحاور، يجب أن:

[7.3.4/H-3-1] يجب أن يكون الجهاز قادرًا على تسجيل الأحداث بتردد لا يقل عن 100 هرتز.
‫[7.3.4/H-3-2] يجب أن يكون الجهاز قادرًا على قياس التغييرات في الاتجاه بمعدّل يصل إلى 1000 درجة في الثانية.

عمليات تنفيذ الأجهزة المحمولة التي يمكنها إجراء مكالمة صوتية والإشارة إلى أي قيمة أخرى غير PHONE_TYPE_NONE في getPhoneType:

[7.3.8/H] يجب أن يتضمّن أداة استشعار التقارب.

عمليات تنفيذ الأجهزة المحمولة:

[7.3.11/H-SR-1] يُنصح بشدة بتوفير دعم لمستشعر تحديد الوضعية مع 6 درجات حرية.

إذا كانت عمليات تنفيذ الأجهزة المحمولة تتيح الاتصال بشبكة بيانات الجوّال، يجب أن تستوفي ما يلي:

[7.4.1/H-1-1] يجب الإفصاح عن علامة ميزة android.hardware.telephony.data.

عمليات تنفيذ الأجهزة المحمولة التي تتضمّن إمكانية استخدام بلوتوث منخفض الطاقة:

[7.4.3/H-SR-1] يُنصح بشدة بتوفير إمكانية تمديد طول حزمة بيانات بلوتوث منخفض الطاقة.

ملاحظة: سيصبح هذا الشرط [7.4.3/H-SR-1] إلزاميًا في إصدار مستقبلي من Android.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية استخدام المعيار 802.11 (Wi-Fi)، يجب أن:

[7.4.2.4/H-1-1] يجب أن يتضمّن دعمًا لمعيار Wi-Fi Passpoint.

إذا كانت الأجهزة تتوافق مع بروتوكول Wi-Fi Neighbor Awareness Networking (NAN) من خلال تعريف PackageManager.FEATURE_WIFI_AWARE وبروتوكول Wi-Fi Location (وقت الاستجابة لطلب Wi-Fi) من خلال تعريف PackageManager.FEATURE_WIFI_RTT، فإنّها:

‫[7.4.2.5/H-1-1] يجب أن يتم عرض النطاق بدقة في حدود +/- متر واحد عند عرض النطاق الترددي 160 ميغاهرتز عند النسبة المئوية الـ 68 (كما هو محسوب باستخدام دالة التوزيع التراكمي)، و+/- مترَين عند عرض النطاق الترددي 80 ميغاهرتز عند النسبة المئوية الـ 68، و+/- 4 أمتار عند عرض النطاق الترددي 40 ميغاهرتز عند النسبة المئوية الـ 68، و+/- 8 أمتار عند عرض النطاق الترددي 20 ميغاهرتز عند النسبة المئوية الـ 68 على مسافات 10 سم و1 متر و3 أمتار و5 أمتار، كما هو ملاحظ من خلال WifiRttManager#startRanging Android API.
[7.4.2.5/H-SR-1] يُنصح بشدة بالإبلاغ عن النطاق بدقة في حدود +/- متر واحد عند نطاق ترددي 160 ميغاهرتز عند الشريحة المئوية التسعين (كما هو محسوب باستخدام دالة التوزيع التراكمي)، وفي حدود +/- مترَين عند نطاق ترددي 80 ميغاهرتز عند الشريحة المئوية التسعين، وفي حدود +/- 4 أمتار عند نطاق ترددي 40 ميغاهرتز عند الشريحة المئوية التسعين، وفي حدود +/- 8 أمتار عند نطاق ترددي 20 ميغاهرتز عند الشريحة المئوية التسعين على مسافات 10 سم، كما تم رصدها من خلال واجهة برمجة التطبيقات WifiRttManager#startRanging لنظام التشغيل Android.

يُنصح بشدة باتّباع خطوات إعداد القياس المحدّدة في معايرة الاستشعار عن القرب.

إذا كانت عمليات تنفيذ الأجهزة المحمولة باليد تتوافق مع بروتوكول "رصد التقارب عبر شبكة Wi-Fi" (PD) الذي يشار إليه من خلال البيان PackageManager.FEATURE_WIFI_RTT وعرض قيمة غير فارغة من WifiRttManager#getProximityDetectionCharacteristics()، يجب استيفاء ما يلي:

[7.4.2.6/H-1-1] إذا كانت الأجهزة تعلن عن إمكانية استخدام معدل نقل بيانات بتردد 160 ميغاهرتز، يجب أن تستخدم معدل نقل بيانات بتردد 160 ميغاهرتز لقياسات تحديد المدى.
‫[7.4.2.6/H-1-2] عند استخدام معيار IEEE 802.11az، يجب أن تعرض الأجهزة النطاق بدقة عند النسبة المئوية الـ 68 (يتم احتسابها باستخدام دالة التوزيع التراكمي) على مسافات 10 سم و1 متر و3 أمتار و5 أمتار كما هو موضّح من خلال WifiRttManager#startContinuousRanging واجهة برمجة التطبيقات Android API:
- ‫+/-0.5 متر عند معدل نقل بيانات بتردد 160 ميغاهرتز
- ‫+/-1 متر عند نطاق ترددي يبلغ 80 ميغاهرتز
- ‫‎+/-2 متر عند نطاق ترددي يبلغ 40 ميغاهرتز
- ‎+/-4 متر عند نطاق ترددي يبلغ 20 ميغاهرتز
[7.4.2.6/H-1-3] عند استخدام معيار IEEE 802.11mc، يجب أن تعرض الأجهزة النطاق بدقة عند النسبة المئوية الـ 68 (يتم احتسابها من خلال دالة التوزيع التراكمي) على مسافات 10 سم و1 متر و3 أمتار و5 أمتار كما هو موضّح من خلال واجهة برمجة التطبيقات WifiRttManager#startContinuousRanging Android:
- ‫‎+/-2 متر عند نطاق ترددي يبلغ 80 ميغاهرتز
- ‫+/-4 متر عند نطاق ترددي يبلغ 40 ميغاهرتز
- ‎+/-8 متر عند نطاق ترددي يبلغ 20 ميغاهرتز
[7.4.2.6/H-SR-1] عند استخدام معيار IEEE 802.11az، يُنصح بشدة بأن تعرض الأجهزة النطاق بدقة عند النسبة المئوية التسعين (يتم احتسابها باستخدام دالة التوزيع التراكمي) على مسافة 10 سم، كما هو موضّح من خلال واجهة برمجة التطبيقات WifiRttManager#startContinuousRanging Android:
- ‫+/-0.5 متر عند معدل نقل بيانات بتردد 160 ميغاهرتز
- ‫+/-1 متر عند نطاق ترددي يبلغ 80 ميغاهرتز
- ‫‎+/-2 متر عند نطاق ترددي يبلغ 40 ميغاهرتز
- ‎+/-4 متر عند نطاق ترددي يبلغ 20 ميغاهرتز
[7.4.2.6/H-SR-2] عند استخدام معيار IEEE 802.11mc، يُنصح بشدة بأن تعرض الأجهزة النطاق بدقة عند النسبة المئوية التسعين (يتم احتسابها من خلال دالة التوزيع التراكمي) على مسافة 10 سم، كما هو موضح من خلال واجهة برمجة التطبيقات WifiRttManager#startContinuousRanging Android:
- ‫‎+/-2 متر عند نطاق ترددي يبلغ 80 ميغاهرتز
- ‫+/-4 متر عند نطاق ترددي يبلغ 40 ميغاهرتز
- ‎+/-8 متر عند نطاق ترددي يبلغ 20 ميغاهرتز

تتضمّن شروط الامتثال توفّر خط رؤية واضح بين الجهازَين، وبيئة اختبار مفتوحة تتضمّن الحد الأدنى من العواكس القريبة للحد من المسارات المتعددة، وعدم وجود أشخاص يتحرّكون حول الأجهزة أثناء الاختبار للحد من الاختلافات في القنوات.

يُنصح بشدة باتّباع خطوات إعداد القياس المحدّدة في معايرة الاستشعار عن القرب.

إذا كانت الأجهزة المحمولة تتوافق مع بروتوكول "رصد التقارب" (PD) عبر Wi-Fi من خلال تعريف PackageManager.FEATURE_WIFI_PD و"الموقع الجغرافي" عبر Wi-Fi (وقت الاستجابة لرحلة Wi-Fi ذهابًا وإيابًا) من خلال تعريف PackageManager.FEATURE_WIFI_RTT، فإنّها:

‫[7.4.2.10/H-1-1] يجب استخدام معدل نقل بيانات بتردد 160 ميغاهرتز على الأقل.
[7.4.2.10/H-1-2] يجب أن تعرض النطاق بدقة في حدود ‎+/-0.25 متر عند نطاق ترددي يبلغ 160 ميجاهرتز عند النسبة المئوية الـ 68 (كما يتم احتسابها باستخدام دالة التوزيع التراكمي)، وذلك كما يتم رصدها من خلال واجهة برمجة التطبيقات WifiRttManager#startRanging لنظام التشغيل Android.

يُنصح بشدة باتّباع خطوات إعداد القياس المحدّدة في معايرة الاستشعار عن القرب.

إذا كانت عمليات تنفيذ الأجهزة المحمولة تعرّف FEATURE_BLUETOOTH_LE، فإنّها:

‫[7.4.3/H-1-3] يجب قياس إزاحة الإرسال والاستعاضة عنها لضمان أن يكون متوسط قوة الإشارة المستلَمة (RSSI) عبر البلوتوث المنخفض الطاقة (BLE) هو ‎-50 ديسيبل ميلي واط ±15 ديسيبل على مسافة متر واحد من جهاز مرجعي يرسل البيانات بمعدل ADVERTISE_TX_POWER_HIGH.
‫[7.4.3/H-1-4] يجب قياس إزاحة الإرسال وتعويضها لضمان أن يكون متوسط قوة الإشارة المستلَمة (RSSI) بتقنية Bluetooth منخفضة الطاقة (BLE) هو ‎-50 ديسيبل ميلي واط ±15 ديسيبل عند إجراء عملية فحص من جهاز مرجعي موضوع على مسافة متر واحد وبث الإشارة بمعدل ADVERTISE_TX_POWER_HIGH.

إذا كانت عمليات تنفيذ الأجهزة المحمولة باليد تتضمّن كاميرا واحدة على الأقل مواجهة للخلف، يجب أن تستوفي ما يلي:

[7.5.1/H-1-1] يجب أن تبلغ درجة الدقة 2 ميغابكسل على الأقل.

إذا كانت عمليات تنفيذ الأجهزة المحمولة باليد تتضمّن جهاز كاميرا منطقيًا يعرض قائمة بالإمكانات باستخدام CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA، يجب أن:

[7.5.4/H-1-1] يجب أن يكون مجال الرؤية العادي (FOV) هو الإعداد التلقائي، ويجب أن يتراوح بين 50 و درجة.

عمليات تنفيذ الأجهزة المحمولة:

‫[7.6.1/H-0-1] يجب أن تتوفّر مساحة تخزين غير متطايرة بسعة 4 غيغابايت على الأقل لبيانات التطبيق الخاصة (المعروفة أيضًا باسم قسم /data).
[7.6.1/H-0-2] يجب أن تعرض القيمة "true" في ActivityManager.isLowRamDevice() عندما تكون سعة الذاكرة المتاحة للنواة ومساحة المستخدم أقل من 1 غيغابايت.

إذا كانت عمليات تنفيذ الأجهزة المحمولة تعلن عن توافقها مع واجهة ثنائية التطبيق (ABI) ذات 32 بت فقط:

‫[7.6.1/H-1-1] يجب أن تبلغ سعة الذاكرة المتاحة للنواة ومساحة المستخدم 416 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم دقة إطارات تصل إلى qHD (مثل FWVGA).
[7.6.1/H-2-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 592 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم دقة إطارات تصل إلى HD+‎ (مثل HD وWSVGA).
‫[7.6.1/H-3-1] يجب أن تبلغ سعة الذاكرة المتاحة للنواة ومساحة المستخدم 896 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم دقة تصل إلى FHD (مثل WSXGA+) في مخزن الإطارات.
‫[7.6.1/H-4-1] يجب أن تبلغ سعة الذاكرة المتاحة للنواة ومساحة المستخدم 1344 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم دقة تصل إلى QHD (مثل QWXGA).

إذا كانت عمليات تنفيذ الأجهزة المحمولة تعلن عن توافقها مع أي واجهة التطبيق الثنائية (ABI) بحجم 64 بت (مع أو بدون أي واجهة التطبيق الثنائية (ABI) بحجم 32 بت):

‫[7.6.1/H-5-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 816 ميغابايت على الأقل إذا كان العرض التلقائي يستخدم دقة إطارات الفيديو تصل إلى qHD (مثل FWVGA).
‫[7.6.1/H-6-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 944 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم دقة إطارات تصل إلى HD+ (مثل HD وWSVGA).
‫[7.6.1/H-7-1] يجب أن تبلغ سعة الذاكرة المتاحة للنواة ومساحة المستخدم 1280 ميغابايت على الأقل إذا كان العرض التلقائي يستخدم دقة إطارات تصل إلى FHD (مثل WSXGA+).
‫[7.6.1/H-8-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 1824 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم دقة إطارات فيديو تصل إلى QHD (مثل QWXGA).

يُرجى العِلم أنّ "الذاكرة المتاحة للنواة ومساحة المستخدم" المذكورة أعلاه تشير إلى مساحة الذاكرة المتوفّرة بالإضافة إلى أي ذاكرة مخصّصة مسبقًا لمكوّنات الأجهزة، مثل الراديو والفيديو وما إلى ذلك، والتي لا تخضع لتحكّم النواة في عمليات تنفيذ الأجهزة.

إذا كانت عمليات تنفيذ الأجهزة المحمولة تتضمّن ذاكرة متاحة للنواة ومساحة المستخدمين تبلغ 1 غيغابايت أو أقل، فإنّها:

[7.6.1/H-9-1] يجب الإفصاح عن علامة الميزة android.hardware.ram.low.
[7.6.1/H-9-2] يجب أن تتضمّن مساحة تخزين غير متطايرة بسعة 1.1 غيغابايت على الأقل لتخزين البيانات الخاصة بالتطبيق (المعروفة أيضًا باسم قسم "/data").

إذا كانت عمليات تنفيذ الأجهزة المحمولة تتضمّن أكثر من 1 غيغابايت من الذاكرة المتاحة للنواة ومساحة المستخدم، يجب أن تستوفي ما يلي:

‫[7.6.1/H-10-1] يجب أن تتوفّر مساحة تخزين غير متطايرة لا تقل عن 4 غيغابايت لبيانات التطبيقات الخاصة (المعروفة أيضًا باسم قسم "/data").
يجب الإعلان عن علامة الميزة android.hardware.ram.normal.

إذا كانت عمليات تنفيذ الأجهزة المحمولة تتضمّن ذاكرة متاحة للنواة ومساحة المستخدم تبلغ 2 غيغابايت أو أكثر وتقل عن 4 غيغابايت، يجب أن:

[‫7.6.1/H-SR-1] يُنصح بشدة بعدم توفير مساحة مستخدمين إلا لنظام 32 بت (سواء للتطبيقات أو رموز النظام)

إذا كانت عمليات تنفيذ الأجهزة المحمولة تتضمّن أقل من 2 غيغابايت من الذاكرة المتاحة للنواة ومساحة المستخدم، فإنّها:

[7.6.1/H-1-1] يجب ألا تتوافق الحزمة إلا مع واجهة تطبيق ثنائية واحدة (إما 64 بت فقط أو 32 بت فقط).

عمليات تنفيذ الأجهزة المحمولة:

‫[7.6.2/H-0-1] يجب ألا توفّر التطبيقات مساحة تخزين مشتركة أصغر من 1 غيغابايت.
[7.7.1/H] يجب أن يتضمّن منفذ USB متوافقًا مع وضع الأجهزة الطرفية.

إذا كانت عمليات تنفيذ الأجهزة المحمولة باليد تتضمّن منفذ USB مع جهاز تحكّم يعمل في وضع الجهاز الطرفي، يجب أن تستوفي ما يلي:

‫[7.7.1/H-1-1] يجب تنفيذ واجهة برمجة التطبيقات Android Open Accessory (AOA).

إذا كانت عمليات تنفيذ الأجهزة المحمولة باليد تتضمّن منفذ USB يتيح وضع المضيف، يجب أن:

[7.7.2/H-1-1] يجب تنفيذ فئة صوت USB على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

عمليات تنفيذ الأجهزة المحمولة:

[7.8.1/H-0-1] يجب أن يتضمّن الجهاز ميكروفونًا.
‫[7.8.2/H-0-1] يجب أن يتضمّن جهاز العرض منفذ إخراج صوت وأن يوضّح android.hardware.audio.output.

إذا كانت عمليات تنفيذ الأجهزة المحمولة قادرة على استيفاء جميع متطلبات الأداء اللازمة لتوفير وضع الواقع الافتراضي وتتضمّن إمكانية استخدامه، يجب أن:

[7.9.1/H-1-1] يجب الإفصاح عن علامة الميزة android.hardware.vr.high_performance.
[7.9.1/H-1-2] يجب تضمين تطبيق ينفّذ android.service.vr.VrListenerService ويمكن تفعيله من خلال تطبيقات الواقع الافتراضي باستخدام android.app.Activity#setVrModeEnabled.

إذا كانت عمليات تنفيذ الأجهزة المحمولة تتضمّن منفذًا واحدًا أو أكثر من منافذ USB-C في وضع المضيف وتنفّذ (فئة صوت USB)، بالإضافة إلى المتطلبات الواردة في القسم 7.7.2، يجب أن تستوفي ما يلي:

[7.8.2.2/H-1-1] يجب توفير ربط البرامج التالي لرموز HID:

الوظيفة	عمليات التعيين	السياق	السلوك
A	صفحة استخدام HID: 0x0C استخدام HID: 0x0CD مفتاح النواة: `KEY_PLAYPAUSE` مفتاح Android: `KEYCODE_MEDIA_PLAY_PAUSE`	تشغيل الوسائط	الإدخال: ضغطة قصيرة الإخراج: التشغيل أو الإيقاف المؤقت
		تشغيل الوسائط	الإدخال: الضغط مع الاستمرار على الإخراج: تشغيل الأمر الصوتي يتم إرسال: `android.speech.action.VOICE_SEARCH_HANDS_FREE` إذا كان الجهاز مقفلًا أو كانت شاشته مطفأة، ويتم إرسال `android.speech.RecognizerIntent.ACTION_WEB_SEARCH` في الحالات الأخرى
		مكالمة واردة	الإدخال: ضغطة قصيرة الإخراج: قبول المكالمة
		مكالمة واردة	الإدخال: الضغط مع الاستمرار على الإخراج: رفض المكالمة
		مكالمة جارية	الإدخال: ضغطة قصيرة على الإخراج: إنهاء المكالمة
		مكالمة جارية	الإدخال: الضغط مع الاستمرار على الإخراج: كتم صوت الميكروفون أو إعادة صوته
B	صفحة استخدام HID: 0x0C استخدام HID: 0x0E9 مفتاح النواة: `KEY_VOLUMEUP` مفتاح Android: `VOLUME_UP`	تشغيل الوسائط، مكالمة جارية	الإدخال: الضغط لفترة قصيرة أو طويلة على الإخراج: زيادة مستوى صوت النظام أو سماعة الرأس
C	صفحة استخدام HID: 0x0C استخدام HID: 0x0EA مفتاح النواة: `KEY_VOLUMEDOWN` مفتاح Android: `VOLUME_DOWN`	تشغيل الوسائط، مكالمة جارية	الإدخال: الضغط لفترة قصيرة أو طويلة على الإخراج: خفض مستوى صوت النظام أو سماعة الرأس
D	صفحة استخدام HID: 0x0C استخدام HID: 0x0CF مفتاح النواة: `KEY_VOICECOMMAND` مفتاح Android: `KEYCODE_VOICE_ASSIST`	الكل. يمكن تشغيلها في أي مثيل.	الإدخال: الضغط لفترة قصيرة أو طويلة الإخراج: تشغيل الطلب الصوتي

[7.8.2.2/H-1-2] يجب أن يتم تشغيل ACTION_HEADSET_PLUG عند إدخال قابس، ولكن فقط بعد أن يتم تعداد واجهات الصوت ونقاط النهاية عبر USB بشكل صحيح من أجل تحديد نوع الجهاز الطرفي المتصل.

عند رصد أنواع طرفية صوت USB 0x0302، يتم تنفيذ ما يلي:

[7.8.2.2/H-2-1] يجب بث Intent ACTION_HEADSET_PLUG مع ضبط الإضافة "microphone" على 0.

عند رصد أنواع طرفيات الصوت عبر USB 0x0402، يتم إجراء ما يلي:

‫[7.8.2.2/H-3-1] يجب بث Intent ACTION_HEADSET_PLUG مع ضبط الإضافة "microphone" على 1.

عند استدعاء واجهة برمجة التطبيقات AudioManager.getDevices() أثناء توصيل جهاز USB خارجي، سيحدث ما يلي:

[7.8.2.2/H-4-1] يجب إدراج جهاز من النوع AudioDeviceInfo.TYPE_USB_HEADSET والدور isSink() إذا كان حقل نوع طرفية الصوت عبر USB هو 0x0302.
‫[7.8.2.2/H-4-2] يجب إدراج جهاز من النوع AudioDeviceInfo.TYPE_USB_HEADSET والدور isSink() إذا كان حقل نوع طرفية الصوت عبر USB هو 0x0402.
[7.8.2.2/H-4-3] يجب إدراج جهاز من النوع AudioDeviceInfo.TYPE_USB_HEADSET والدور isSource() إذا كان حقل نوع طرفية الصوت عبر USB هو 0x0402.
‫[7.8.2.2/H-4-4] يجب إدراج جهاز من النوع AudioDeviceInfo.TYPE_USB_DEVICE والدور isSink() إذا كان حقل نوع طرفية الصوت عبر USB هو 0x603.
[7.8.2.2/H-4-5] يجب إدراج جهاز من النوع AudioDeviceInfo.TYPE_USB_DEVICE والدور isSource() إذا كان حقل نوع طرفية الصوت عبر USB هو 0x604.
‫[7.8.2.2/H-4-6] يجب إدراج جهاز من النوع AudioDeviceInfo.TYPE_USB_DEVICE والدور isSink() إذا كان حقل نوع طرفية الصوت عبر USB هو 0x400.
[7.8.2.2/H-4-7] يجب إدراج جهاز من النوع AudioDeviceInfo.TYPE_USB_DEVICE والدور isSource() إذا كان حقل نوع طرفية الصوت عبر USB هو 0x400.
[7.8.2.2/H-SR-1] يُنصح بشدة عند توصيل جهاز طرفي صوتي بمنفذ USB-C بإجراء تعداد لأوصاف USB وتحديد أنواع المحطات الطرفية وبث Intent ACTION_HEADSET_PLUG في أقل من 1000 مللي ثانية.

بالنسبة إلى عمليات تنفيذ الأجهزة المحمولة التي تحدّد android.hardware.audio.output وandroid.hardware.microphone، اطّلِع على متطلبات وقت الاستجابة من الجهاز إلى السحابة الإلكترونية (TTL) ووقت الاستجابة من السحابة الإلكترونية إلى الجهاز (RTL) في القسم 5.6.

المشغّل الرنان الخطي (LRA) هو نظام زنبركي أحادي الكتلة يتضمّن ترددًا رنانًا سائدًا تتحرك فيه الكتلة في اتجاه الحركة المطلوبة.

إذا كانت عمليات تنفيذ الأجهزة المحمولة باليد تتضمّن مشغّلاً رنّانًا خطيًا واحدًا على الأقل للأغراض العامة 7.10، فإنّها:

[7.10/H] يجب وضع موضع المشغّل بالقرب من المكان الذي يتم عادةً حمل الجهاز أو لمسه باليدين.
[7.10/H] يجب أن يتم تحريك المشغّل اللمسي على المحور X (من اليسار إلى اليمين) في الاتجاه الطبيعي للجهاز.

إذا كانت عمليات تنفيذ الأجهزة المحمولة باليد تتضمّن مشغّلاً لمسياً للأغراض العامة وهو مشغّل رنين خطي (LRA) على المحور X، يجب أن:

‫[7.10/H] يجب أن يكون التردد الرنيني لمشغّل الرنين الخطي على المحور X أقل من 200 هرتز.

إذا كانت عمليات تنفيذ الأجهزة المحمولة تتّبع عملية ربط الثوابت الحسية، فإنّها:

[7.10/H]^* يجب التحقّق من حالة التنفيذ من خلال تشغيل واجهتَي برمجة التطبيقات android.os.Vibrator.areAllEffectsSupported() وandroid.os.Vibrator.arePrimitivesSupported().
[7.10/H]^* يجب إجراء تقييم الجودة للمتغيرات الحسية.
[7.10/H]^* يجب التحقّق من إعدادات التوافق الاحتياطية للعناصر الأساسية غير المتوافقة وتعديلها إذا لزم الأمر، وذلك على النحو الموضّح في إرشادات التنفيذ الخاصة بالثوابت.

2.2.2. وسائط متعددة

يجب أن تتوافق عمليات تنفيذ الأجهزة المحمولة مع صيغ ترميز الصوت وفك ترميزه التالية وأن توفّرها للتطبيقات التابعة لجهات خارجية:

‫[5.1/H-0-1] AMR-NB
‫[5.1/H-0-2] AMR-WB
‫[5.1/H-0-3] ملف تعريف MPEG-4 AAC (برنامج الترميز AAC LC)
‫[5.1/H-0-4] ملف تعريف MPEG-4 HE AAC (برنامج ترميز AAC+)
‫[5.1/H-0-5] ترميز AAC ELD (ترميز AAC المحسّن ذو التأخير المنخفض)

‫[5.1/H-0-6] ترميز MPEG-D USAC مع ترميز MPEG-D DRC (ترميز AAC عالي الكفاءة الموسّع)

يجب أن تتوافق عمليات تنفيذ الأجهزة المحمولة مع تنسيقات ترميز الفيديو التالية وأن تتيحها للتطبيقات التابعة لجهات خارجية:

‫[5.2/H-0-1] H.264 AVC
‫[5.2/H-0-2] VP8
‫[5.2/H-0-3] AV1

يجب أن تتوافق آليات التنفيذ على الأجهزة المحمولة مع تنسيقات ترميز الفيديو التالية وأن تتيحها للتطبيقات التابعة لجهات خارجية:

‫[5.3/H-0-1] H.264 AVC
‫[5.3/H-0-2] H.265 HEVC
‫[5.3/H-0-3] MPEG-4 SP
[5.3/H-0-4] VP8
‫[5.3/H-0-5] VP9
‫[5.3/H-0-6] AV1

2.2.3. برامج

عمليات تنفيذ الأجهزة المحمولة:

[3.2.3.1/H-0-1] يجب أن يتضمّن تطبيقًا يتعامل مع أغراض ACTION_GET_CONTENT وACTION_OPEN_DOCUMENT وACTION_OPEN_DOCUMENT_TREE وACTION_CREATE_DOCUMENT على النحو الموضّح في مستندات حزمة SDK، وأن يوفّر للمستخدم إمكانية الوصول إلى بيانات موفّر المستندات باستخدام واجهة برمجة التطبيقات DocumentsProvider.

[3.2.3.1/H-0-2] يجب أن يتم التحميل المُسبَق لتطبيق واحد أو أكثر أو لمكوّنات خدمة تتضمّن معالج intent، وذلك لجميع أنماط intent filter العامة المحدّدة من خلال intents التطبيقات التالية المدرَجة هنا.

ملاحظة: ستتضمّن صفحة "أهداف التطبيقات الشائعة" الهدف الإلزامي الجديد android.settings.VPN_APP_EXCLUSION_SETTINGS.

[3.2.3.1/H-SR-1] يُنصح بشدة بتثبيت تطبيق للبريد الإلكتروني مسبقًا يمكنه التعامل مع أغراض ACTION_SENDTO أو ACTION_SEND أو ACTION_SEND_MULTIPLE لإرسال رسالة إلكترونية.

‫[3.4.1/H-0-1] يجب توفير تنفيذ كامل لواجهة برمجة التطبيقات android.webkit.Webview.

[3.4.2/H-0-1] يجب أن يتضمّن تطبيقًا مستقلاً للمتصفّح لاستخدام المستخدمين العام في تصفّح الويب.

[3.8.1/H-0-1] يجب تنفيذ مشغّل تطبيقات تلقائي يتيح تثبيت التطبيقات المصغّرة داخل التطبيقات.

‫[3.8.1/H-SR-1] يُنصح بشدة بتنفيذ مشغّل تلقائي يتيح تثبيت اختصارات وwidgetFeatures وعناصر واجهة مستخدم داخل التطبيق.
[3.8.1/H-SR-2] يُنصح بشدة بتنفيذ مشغّل تطبيقات تلقائي يتيح الوصول السريع إلى الاختصارات الإضافية التي توفّرها تطبيقات الجهات الخارجية من خلال واجهة برمجة التطبيقات ShortcutManager.
‫[3.8.1/H-SR-3] يُنصح بشدة بتضمين تطبيق مشغّل تلقائي يعرض شارات لرموز التطبيقات.

[3.8.2/H-SR-1] يُنصح بشدة بإتاحة أدوات التطبيقات التابعة لجهات خارجية.

‫[3.8.2/H-0-1] يجب أن يتيح استخدام التطبيقات المصغّرة التابعة لجهات خارجية.

[3.8.3/H-0-1] يجب السماح لتطبيقات الجهات الخارجية بإرسال إشعارات إلى المستخدمين بشأن الأحداث المهمة من خلال فئتَي واجهة برمجة التطبيقات Notification وNotificationManager.
‫[3.8.3/H-0-2] يجب أن يتيح الجهاز تلقّي إشعارات غنية.
‫[3.8.3/H-0-3] يجب أن يتيح الجهاز عرض الإشعارات المنبثقة.
[3.8.3/H-0-4] يجب أن يتضمّن لوحة الإشعارات، ما يتيح للمستخدم التحكّم مباشرةً (مثل الرد أو تأجيل الإشعار أو تجاهله أو حظره) في الإشعارات من خلال إمكانية الوصول التي يوفّرها المستخدم، مثل أزرار الإجراءات أو لوحة التحكّم كما هو موضّح في مشروع Android المفتوح المصدر (AOSP).
[3.8.3/H-0-5] يجب عرض الخيارات المقدَّمة من خلال RemoteInput.Builder setChoices() في مركز الإشعارات.
[3.8.3/H-SR-1] يُنصح بشدة بعرض الخيار الأول المقدَّم من خلال RemoteInput.Builder setChoices() في مركز الإشعارات بدون تفاعل إضافي من المستخدم.
‫[3.8.3/H-SR-2] يُنصح بشدة بعرض جميع الخيارات المقدَّمة من خلال RemoteInput.Builder setChoices() في مركز الإشعارات عندما يوسّع المستخدم جميع الإشعارات في مركز الإشعارات.
[3.8.3.1/H-SR-1] يُنصح بشدة بعرض الإجراءات التي تم ضبط Notification.Action.Builder.setContextual على true بشكل مضمّن مع الردود التي يعرضها Notification.Remoteinput.Builder.setChoices.
‫[3.8.4/H-SR-1] يُنصح بشدة بتنفيذ إجراء "المساعدة" من خلال مساعد على الجهاز.

إذا كانت عمليات تنفيذ الأجهزة المحمولة تتوافق مع إشعارات MediaStyle، يجب أن تستوفي ما يلي:

[3.8.3.1/H-SR-2] يُنصح بشدة بتوفير أداة تحكّم للمستخدم (مثل أداة تبديل الإخراج) يمكن الوصول إليها من واجهة مستخدم النظام وتتيح للمستخدمين التبديل بين مسارات الوسائط المتاحة المناسبة (مثل أجهزة Bluetooth والمسارات التي يتم توفيرها إلى MediaRouter2Manager) عندما ينشر تطبيق إشعارًا من النوع MediaStyle يتضمّن الرمز المميز MediaSession.

يمكن الترويج لإشعار التحديث المباشر الخاص بأحد التطبيقات عندما يستوفي التطبيق جميع خصائص الترويج. يُشار إلى هذا النوع من الإشعارات باسم "إشعار التحديث الفوري المُروَّج له" في هذا المستند. يجب أن تعرض عمليات تنفيذ الأجهزة المحمولة إشعار التحديث الفوري المُروَّج له بشكل بارز وفقًا للمتطلبات التالية.

إذا كانت عمليات تنفيذ الأجهزة الجوّالة تتضمّن المستوى 36.1 من واجهة برمجة التطبيقات أو مستوى أحدث، فإنّها:

[3.8.3.1/H-0-1] يجب عرض إشعار "تحديث مباشر" مُروَّج له في مكان بارز على شاشة القفل.
[3.8.3.1/H-0-12] يجب أن يظهر في أعلى حزمة الإشعارات الإشعار العائم وفوق الإشعارات الملوّنة (حيث setColorized هو true) عندما يظهر الإشعار الترويجي بالتحديثات الفورية بين الإشعارات الأخرى.
- قد يحدّد ترتيب تسلسل "الإشعارات المحسّنة بالتحديثات الفورية" المعروضة في مركز الإشعارات وشاشة القفل عندما يكون أكثر من تطبيق واحد مؤهلاً لتلقّي "إشعار محسّن بتحديث فوري".
[‫3.8.3.1/H-0-2] يجب عرض إشعار "تغطية مباشرة مقترَحة" في الحالة الموسّعة.
[3.8.3.1/H-0-3] يجب عدم توفير وسيلة تتيح للمستخدم تصغير الإشعار الموسّع أعلاه.
[3.8.3.1/H-0-4] يجب عرض الأنماط الأساسية (الخط الغامق والمائل والتسطير) لمحتوى النص في "إشعار التحديث المباشر الترويجي"، كما هو مقدَّم من خلال StyleSpan أو UnderlineSpan.
[3.8.3.1/H-0-5] يجب عرض عناصر الإجراءات العادية فقط (من خلال Notification.Action)، ويجب إخفاء عناصر الإجراءات غير العادية، مثل مربّعات الإدخال وأزرار الرد والإجراءات السياقية (من خلال addRemoteInput() وsetContextual()) في إشعار "آخر الأخبار" الترويجي، حتى إذا كان الإشعار يتضمّنها.
[3.8.3.1/H-0-6] يجب عرض تمثيل مضغوط، يُشار إليه أيضًا باسم شريحة الحالة في مستندات حزمة تطوير البرامج (SDK)، لإشعار بتحديث مباشر مُروَّج له يجب أن يتضمّن Notification.getSmallIcon().
- [3.8.3.1/H-0-7] الحقول الأخرى اختيارية في التمثيل المكثّف، ولكن عندما يكون من الممكن توسيع التمثيل المكثّف، يجب عرض Notification.getShortCriticalText() إذا كان متوفّرًا، أو Notification.when إذا لم يكن Notification.getShortCriticalText متوفّرًا.
- [3.8.3.1/H-0-8] عند توفّر أكثر من إشعار واحد بشأن "التغطية المباشرة للأخبار"، يجب عرض إشعار واحد على الأقل في شريط الحالة كتمثيل مضغوط.
- [3.8.3.1/H-0-9] يجب إما عرض الإشعار المرتبط (الخيار المفضّل) أو فتح التطبيق المرتبط (من خلال Notification.contentIntent) عند نقر المستخدم على التمثيل المضغوط.
- [3.8.3.1/H-0-13] يجب عرض كل المحتوى نفسه في الإشعار المرتبط كما هو متاح في مركز الإشعارات.
[3.8.3.1/H-0-10] يجب توفير وسيلة للمستخدمين لإيقاف العرض الترويجي لإشعارات التطبيقات الفردية وتفعيله.
[3.8.3.1/H-0-11] يجب عرض جميع "إشعارات المعلومات الحية" بشكل صحيح، بما في ذلك على سبيل المثال لا الحصر "إشعارات المعلومات الحية" غير الترويجية التي لا تستوفي أو تستوفي جزئيًا فقط خصائص الترويج. يجب عرض هذه الإشعارات غير الترويجية في حالة غير ترويجية.

إذا كانت عمليات تنفيذ الأجهزة التي تتضمّن مفتاح التنقّل الخاص بوظيفة "التطبيقات الحديثة" كما هو موضّح بالتفصيل في القسم 7.2.3 تغيّر الواجهة، يجب أن تستوفي ما يلي:

‫[3.8.3/H-1-1] يجب تنفيذ سلوك تثبيت الشاشة وتوفير قائمة إعدادات للمستخدم لتفعيل الميزة أو إيقافها.

إذا كانت عمليات تنفيذ الأجهزة المحمولة تتيح إجراء "المساعدة"، يجب أن تستوفي ما يلي:

[3.8.4/H-SR-2] يُنصح بشدة باستخدام الضغط مع الاستمرار على المفتاح HOME كإجراء تفاعلي مخصّص لتشغيل تطبيق المساعدة على النحو الموضّح في الفقرة 7.2.3. يجب أن يتم تشغيل تطبيق المساعدة الذي يختاره المستخدم، أي التطبيق الذي ينفّذ VoiceInteractionService، أو نشاط يعالج الغرض ACTION_ASSIST.

إذا كانت عمليات تنفيذ الأجهزة المحمولة تتوافق مع conversation notifications وتصنّفها في قسم منفصل عن الإشعارات التنبيهية وغير التنبيهية الصامتة، فإنّها:

[3.8.4/H-1-1]^* يجب عرض إشعارات المحادثات قبل الإشعارات الأخرى، باستثناء إشعارات الخدمات التي تعمل في المقدّمة بشكل مستمر والإشعارات التي تتضمّن importance:high.

إذا كانت عمليات تنفيذ أجهزة Android المحمولة باليد تتوافق مع شاشة القفل، يجب أن تستوفي ما يلي:

[3.8.10/H-1-1] يجب عرض الإشعارات على شاشة القفل، بما في ذلك نموذج إشعار الوسائط.

إذا كانت عمليات تنفيذ الأجهزة المحمولة باليد تتيح قفل شاشة آمنًا، يجب أن تستوفي ما يلي:

‫[3.9/H-1-1] يجب تنفيذ النطاق الكامل لسياسات إدارة الأجهزة المحدّدة في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

إذا كانت عمليات تنفيذ الأجهزة المحمولة تتضمّن توافقًا مع واجهات برمجة التطبيقات ControlsProviderService وControl وتسمح للتطبيقات التابعة لجهات خارجية بنشر عناصر تحكّم في الأجهزة، يجب أن تستوفي ما يلي:

‫[3.8.16/H-1-1] يجب التعريف بعلامة الميزة android.software.controls وضبطها على true.
[3.8.16/H-1-2] يجب توفير تلميحات مرئية للمستخدم تتيح له إضافة أدوات التحكم المفضّلة في الأجهزة وتعديلها واختيارها وتشغيلها من أدوات التحكم التي تسجّلها تطبيقات الجهات الخارجية من خلال واجهتَي برمجة التطبيقات ControlsProviderService وControl.
[3.8.16/H-1-3] يجب توفير إمكانية الوصول إلى عنصر التحكّم هذا خلال ثلاث تفاعلات من مشغّل التطبيقات التلقائي.
‫[3.8.16/H-1-4] يجب أن يتم عرض اسم ورمز كل تطبيق تابع لجهة خارجية يوفّر عناصر تحكّم من خلال واجهة برمجة التطبيقات ControlsProviderService، بالإضافة إلى أي حقول محدّدة توفّرها واجهات برمجة التطبيقات Control، وذلك بدقة في عنصر التحكّم الخاص بالمستخدم.
[3.8.16/H-1-5] يجب توفير تلميحات مرئية للمستخدم لإيقاف أدوات التحكم بالجهاز التي لا تتطلّب المصادقة والمحدّدة في التطبيق، وذلك من أدوات التحكم التي تسجّلها التطبيقات التابعة لجهات خارجية من خلال واجهة برمجة التطبيقات ControlsProviderService وواجهة برمجة التطبيقات Control Control.isAuthRequired.
[3.8.16/H-1-6] يجب أن تعرض عمليات تنفيذ الجهاز التلميحات المرئية للمستخدم بدقة على النحو التالي:
- إذا تم ضبط config_supportsMultiWindow=true على الجهاز وكان التطبيق يعرّف البيانات الوصفية META_DATA_PANEL_ACTIVITY في بيان ControlsProviderService، بما في ذلك ComponentName لنشاط صالح (على النحو المحدّد في واجهة برمجة التطبيقات)، يجب أن يضمّن التطبيق النشاط المذكور في أداة تسهيل الاستخدام هذه.
- إذا لم يعرض التطبيق البيانات الوصفية META_DATA_PANEL_ACTIVITY، يجب أن يعرض الحقول المحدّدة كما توفّرها واجهة برمجة التطبيقات ControlsProviderService بالإضافة إلى أي حقول محدّدة توفّرها واجهات برمجة التطبيقات Control.
[3.8.16/H-1-7] إذا كان التطبيق يعرّف البيانات الوصفية META_DATA_PANEL_ACTIVITY، يجب أن يجتاز الإعداد المحدّد في [3.8.16/H-1-5] باستخدام EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS عند تشغيل النشاط المضمّن.

في المقابل، إذا لم تتضمّن عمليات تنفيذ الأجهزة المحمولة عناصر التحكّم هذه، فإنّها:

‫[3.8.16/H-2-1] يجب الإبلاغ عن null لواجهتَي برمجة التطبيقات ControlsProviderService وControl.
[3.8.16/H-2-2] يجب الإفصاح عن علامة الميزة android.software.controls وضبطها على false.

إذا لم يتم تنفيذ عمليات الأجهزة الجوّالة في وضع قفل المهمة، عند نسخ المحتوى إلى الحافظة، سيحدث ما يلي:

[3.8.17/H-1-1] يجب عرض تأكيد للمستخدم بأنّه تم نسخ البيانات إلى الحافظة (مثل صورة مصغّرة أو تنبيه "تم نسخ المحتوى"). بالإضافة إلى ذلك، يُرجى تضمين إشارة هنا توضّح ما إذا كان سيتم مزامنة بيانات الحافظة على جميع الأجهزة.

عمليات تنفيذ الأجهزة المحمولة:

[3.10/H-0-1] يجب أن يتيح الجهاز استخدام خدمات تسهيل الاستخدام التابعة لجهات خارجية.
[3.10/H-SR-1] يُنصح بشدة بتثبيت خدمات تسهيل الاستخدام مسبقًا على الجهاز، على أن تكون هذه الخدمات مماثلة أو تتجاوز في وظائفها خدمات "الوصول عبر مفتاح تحويل" وTalkBack (بالنسبة إلى اللغات التي يتوافق معها محرّك تحويل النص إلى كلام المثبَّت مسبقًا)، وذلك على النحو الموضّح في مشروع TalkBack المفتوح المصدر.
[3.11/H-0-1] يجب أن يتيح الجهاز تثبيت محركات تحويل النص إلى كلام تابعة لجهات خارجية.
‫[3.11/H-SR-1] يُنصح بشدة بتضمين محرك تحويل النص إلى كلام يتوافق مع اللغات المتوفرة على الجهاز.
[3.13/H-SR-1] يُنصح بشدة بتضمين مكوّن واجهة مستخدم "الإعدادات السريعة".

إذا كانت عمليات تنفيذ الأجهزة المحمولة التي تعمل بنظام التشغيل Android تتضمّن إعلانًا عن إتاحة FEATURE_BLUETOOTH أو FEATURE_WIFI، فإنّها:

‫[3.16/H-1-1] يجب أن يتيح الجهاز المساعد إمكانية إقران الأجهزة.

إذا كانت وظيفة التنقّل متوفّرة كإجراء مستند إلى الإيماءات على الشاشة:

عمليات تنفيذ الأجهزة المحمولة:

‫[3.20.1/H-0-1] يجب استيفاء جميع متطلبات "بث الصوت في مساعد Google".

[7.2.3/H] يجب ألا يزيد ارتفاع منطقة التعرّف على الإيماءات الخاصة بوظيفة "الصفحة الرئيسية" عن 32 وحدة بكسل مستقلة الكثافة من أسفل الشاشة.

إذا كانت عمليات تنفيذ الأجهزة المحمولة توفّر وظيفة تنقّل كإيماءة من أي مكان على الحافتين اليسرى واليمنى للشاشة:

‫[7.2.3/H-0-1] يجب أن يكون عرض مساحة الإيماءات الخاصة بوظيفة التنقّل أقل من 40 وحدة بكسل مستقلة الكثافة على كل جانب. يجب أن يبلغ عرض مساحة الإيماءة 24 وحدة بكسل مستقلة عن الكثافة تلقائيًا.

إذا كانت عمليات تنفيذ الأجهزة المحمولة باليد تتيح استخدام شاشة قفل آمنة وتتضمّن ذاكرة بسعة 2 غيغابايت أو أكثر متاحة للنواة ومساحة المستخدم، يجب أن تستوفي ما يلي:

‫[3.9/H-1-2] يجب الإفصاح عن إمكانية استخدام الملفات الشخصية المُدارة من خلال علامة الميزة android.software.managed_users.

إذا كانت عمليات تنفيذ أجهزة Android المحمولة تعلن عن إمكانية استخدام الكاميرا من خلال android.hardware.camera.any، عليها استيفاء ما يلي:

[7.5.4/H-1-1] يجب الالتزام بنية android.media.action.STILL_IMAGE_CAMERA وandroid.media.action.STILL_IMAGE_CAMERA_SECURE وتشغيل الكاميرا في وضع الصور الثابتة كما هو موضّح في حزمة تطوير البرامج (SDK).
[7.5.4/H-1-2] يجب أن يلتزم android.media.action.VIDEO_CAMERA بالنية في تشغيل الكاميرا في وضع الفيديو كما هو موضّح في حزمة تطوير البرامج (SDK).

إذا كان تطبيق الإعدادات الخاص بتنفيذ الجهاز يوفّر وظيفة تقسيم باستخدام ميزة "تضمين الأنشطة"، يجب أن:

[3.2.3.1/ H-1-1] يجب أن يتضمّن التطبيق نشاطًا يعالج الغرض Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY عندما تكون وظيفة التقسيم مفعّلة. يجب أن تكون "النشاط" محمية بواسطة android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK، ويجب أن تبدأ نشاط Intent الذي تم تحليله من Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.

إذا كانت عمليات تنفيذ الأجهزة تسمح للمستخدمين بإجراء مكالمات من أي نوع،

[7.4.1.2/H-0-1] يجب الإفصاح عن علامة الميزة android.software.telecom.

[7.4.1.2/H-0-2] يجب تنفيذ إطار عمل الاتصالات.

‫2.2.4. الأداء والطاقة

‫[8.1/H-0-1] وقت استجابة ثابت للإطار: يجب ألا يحدث تأخير في عرض اللقطات أو عدم اتساق في وقت استجابة اللقطات أكثر من 5 مرات في الثانية، ويجب أن يكون أقل من مرة واحدة في الثانية.
[8.1/H-0-2] زمن استجابة واجهة المستخدم: يجب أن تضمن عمليات تنفيذ الأجهزة تجربة مستخدم بزمن انتقال منخفض من خلال تمرير قائمة تضم 10,000 إدخال على القائمة على النحو المحدّد في مجموعة اختبار التوافق (CTS) لنظام التشغيل Android في أقل من 36 ثانية.
‫[8.1/H-0-3] تبديل المهام: عند تشغيل عدة تطبيقات، يجب أن يستغرق إعادة تشغيل تطبيق سبق تشغيله أقل من ثانية واحدة.

عمليات تنفيذ الأجهزة المحمولة:

[8.2/H-0-1] يجب ضمان أداء كتابة تسلسلية لا يقل عن 5 ميغابايت/ثانية.
‫[8.2/H-0-2] يجب ضمان أداء كتابة عشوائية بسرعة 0.5 ميغابايت في الثانية على الأقل.
‫[8.2/H-0-3] يجب ضمان أداء قراءة تسلسلية لا يقل عن 15 ميغابايت في الثانية.
[8.2/H-0-4] يجب ضمان أداء قراءة عشوائية بسرعة 3.5 ميغابايت في الثانية على الأقل.

إذا كانت عمليات تنفيذ الأجهزة المحمولة باليد تتضمّن ميزات لتحسين إدارة طاقة الجهاز مضمّنة في AOSP أو توسّع الميزات المضمّنة في AOSP، يجب أن تستوفي ما يلي:

[8.3/H-1-1] يجب توفير وسيلة تتيح للمستخدم تفعيل ميزة "توفير شحن البطارية" وإيقافها.
[8.3/H-1-2] يجب توفير إمكانية للمستخدم لعرض جميع التطبيقات المستثناة من وضعي "تطبيقات وضع الاستعداد" و"قيلولة" و"وضع توفير الطاقة".

عمليات تنفيذ الأجهزة المحمولة:

[8.4/H-0-1] يجب توفير ملف تعريف طاقة لكل مكوّن يحدّد قيمة استهلاك التيار لكل مكوّن من مكوّنات الجهاز ومعدّل استنزاف البطارية التقريبي الذي تسبّبه المكوّنات بمرور الوقت، وذلك على النحو الموضّح في موقع "مشروع مفتوح المصدر لنظام Android".
[8.4/H-0-2] يجب عرض جميع قيم استهلاك الطاقة بوحدة ميلي أمبير في الساعة (mAh).
[8.4/H-0-3] يجب عرض استهلاك طاقة وحدة المعالجة المركزية (CPU) لكل معرّف UID خاص بكل عملية. يستوفي "مشروع Android المفتوح المصدر" هذا الشرط من خلال تنفيذ وحدة النواة uid_cputime.
[8.4/H-0-4] يجب إتاحة معلومات استهلاك الطاقة هذه لمطوّر التطبيق من خلال أمر shell adb shell dumpsys batterystats.
[8.4/H] يجب أن يتم تحديد مصدر استهلاك الطاقة على أنّه مكوّن الجهاز نفسه إذا تعذّر تحديد مصدر استهلاك الطاقة على أنّه تطبيق.

إذا كانت عمليات تنفيذ الأجهزة المحمولة تتضمّن شاشة أو إخراج فيديو، يجب أن تستوفي ما يلي:

[8.4/H-1-1] يجب الالتزام بنية android.intent.action.POWER_USAGE_SUMMARY وعرض قائمة إعدادات توضّح استهلاك الطاقة هذا.

عمليات تنفيذ الأجهزة المحمولة:

[8.5/H-0-1] يجب توفير عنصر تحكّم للمستخدم يتيح له الاطّلاع على جميع التطبيقات التي تتضمّن إما خدمات نشطة تعمل في المقدّمة أو مهام بدأها المستخدم، بما في ذلك مدة كل من هذه الخدمات منذ بدء تشغيلها على النحو الموضّح في مستند حزمة SDK.
[8.5/H-0-2]يجب توفير عنصر تحكّم للمستخدم لإيقاف تطبيق يشغّل خدمة تعمل في المقدّمة أو مهمة بدأها المستخدم.

‫2.2.5. نموذج الأمان

عمليات تنفيذ الأجهزة المحمولة:

‫[9/H-0-1] يجب الإفصاح عن ميزة android.hardware.security.model.compatible.
[9.1/H-0-1] يجب السماح للتطبيقات التابعة لجهات خارجية بالوصول إلى إحصاءات الاستخدام من خلال إذن android.permission.PACKAGE_USAGE_STATS وتوفير آلية يمكن للمستخدم الوصول إليها لمنح أو إبطال إذن الوصول إلى هذه التطبيقات استجابةً للغرض android.settings.ACTION_USAGE_ACCESS_SETTINGS.

إذا كانت عمليات تنفيذ الأجهزة المحمولة باليد تتضمّن تطبيقًا تلقائيًا لدعم VoiceInteractionService، يجب أن:

[9.1/H-0-2] يجب عدم منح ACCESS_FINE_LOCATION كإذن تلقائي لهذا التطبيق.

يجب أن توضّح عمليات تنفيذ الأجهزة أنّها متوافقة مع android.software.credentials وأن تستوفي ما يلي:

‫[9/H-0-2] يجب الالتزام android.settings.CREDENTIAL_PROVIDER بالسماح باختيار مقدّم خدمة مفضّل في Credential Manager. سيتم تفعيل مقدّم الخدمة هذا لميزة "الملء التلقائي"، وسيكون أيضًا الموقع الجغرافي التلقائي لحفظ بيانات الاعتماد الجديدة التي يتم إدخالها من خلال واجهة Credential Manager.
‫[9/H-0-3] يجب أن يتيح الجهاز استخدام مزوّدَي بيانات اعتماد متزامنين على الأقل، ويجب أن يوفّر للمستخدمين إمكانية تفعيل المزوّدين أو إيقافهم في تطبيق "الإعدادات".
[9.5/H-1-1] تمت إزالة هذا الشرط في Android 16.

عمليات تنفيذ الأجهزة المحمولة:

[9.11/H-0-2] يجب أن يتم الاحتفاظ بنسخة احتياطية من تنفيذ مخزن المفاتيح في بيئة تنفيذ معزولة.
[9.11/H-0-3] يجب أن تتضمّن عمليات تنفيذ لخوارزميات التشفير RSA وAES وECDSA وHMAC ووظائف التجزئة MD5 وSHA-1 وSHA-2 لتوفير الدعم المناسب للخوارزميات المتوافقة مع نظام Android Keystore في منطقة معزولة بشكل آمن عن الرمز البرمجي الذي يتم تنفيذه على النواة وما فوقها. يجب أن يحظر العزل الآمن جميع الآليات المحتملة التي قد يصل من خلالها رمز kernel أو رمز مساحة المستخدم إلى الحالة الداخلية للبيئة المعزولة، بما في ذلك الوصول المباشر إلى الذاكرة (DMA). يستوفي "المشروع المفتوح المصدر لنظام Android" ‏ (AOSP) هذا الشرط باستخدام تنفيذ Trusty، ولكن يمكن أيضًا استخدام حل آخر يستند إلى ARM TrustZone أو تنفيذ آمن تمت مراجعته من جهة خارجية ويستند إلى برنامج مراقبة الأجهزة الافتراضية.
[9.11/H-0-4] يجب إجراء مصادقة شاشة القفل في بيئة التنفيذ المعزولة، ولا يُسمح باستخدام المفاتيح المرتبطة بالمصادقة إلا عند نجاحها. يجب تخزين بيانات اعتماد شاشة القفل بطريقة لا تسمح إلا لبيئة التنفيذ المعزولة بإجراء مصادقة شاشة القفل. يوفّر مشروع Android مفتوح المصدر الأساسي طبقة تجريد الأجهزة (HAL) في Gatekeeper وTrusty، ويمكن استخدامهما لاستيفاء هذا الشرط.
[9.11/H-0-5] يجب أن تتوافق مع مصادقة المفتاح حيث يكون مفتاح التوقيع الخاص بالمصادقة محميًا بواسطة أجهزة آمنة ويتم التوقيع في أجهزة آمنة. يجب منع استخدام مفاتيح توقيع شهادة التصديق كمعرّفات دائمة للأجهزة.

ملاحظة: لاستيفاء هذا الشرط، يجب مشاركة مفتاح التصديق نفسه لرمز تخزين تعريفي معيّن ما لم يتم إنتاج 100,000 وحدة على الأقل من رمز التخزين التعريفي هذا. إذا تم إنتاج أكثر من 100,000 وحدة من رمز التخزين التعريفي هذا، يمكن استخدام مفتاح مختلف لكل مجموعة من 100,000 وحدة بعد ذلك. بدلاً من ذلك، يمكن استخدام حلّ Remote Key Provisioning لتوفير مفاتيح تصديق قصيرة الأمد للجهاز.

يُرجى العِلم أنّه إذا تم إطلاق إصدار لجهاز على إصدار سابق من Android، سيتم إعفاء هذا الجهاز من شرط توفُّر مخزن مفاتيح يستند إلى بيئة تنفيذ معزولة ويتيح إثبات صحة المفتاح، ما لم يعلن الجهاز عن توفُّر ميزة android.hardware.fingerprint التي تتطلّب مخزن مفاتيح يستند إلى بيئة تنفيذ معزولة.

عندما تتيح عمليات تنفيذ الأجهزة المحمولة قفل شاشة آمنًا، فإنّها:

[9.11/H-1-1] يجب أن يسمح الجهاز للمستخدم باختيار أقصر مهلة لإيقاف الشاشة، أي فترة الانتقال من حالة فتح القفل إلى حالة قفل الشاشة، على أن تكون 15 ثانية أو أقل.
[9.11/H-1-2] يجب توفير وسيلة للمستخدم لإخفاء الإشعارات وإيقاف جميع أشكال المصادقة باستثناء المصادقة الأساسية الموضّحة في ‫9.11.1 شاشة القفل الآمنة. يستوفي نظام التشغيل AOSP هذا الشرط من خلال "وضع التأمين".

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة قفل آمنة وتشمل وكيلًا معتمدًا واحدًا أو أكثر، والذي ينفّذ واجهة برمجة التطبيقات TrustAgentService للنظام، فإنّها:

[9.11.1/H-1-1] يجب أن يطلب الجهاز من المستخدم إثبات هويته باستخدام إحدى طرق المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) بشكل متكرّر أكثر من مرّة كل 72 ساعة.

إذا كانت عمليات تنفيذ الأجهزة الجوّالة تتضمّن شاشة قفل آمنة وتشمل وكيلًا معتمَدًا واحدًا أو أكثر يستدعي واجهة برمجة التطبيقات TrustAgentService.grantTrust() للنظام باستخدام العلامة FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE، فإنّها:

[9.11.1/H-1-1] يجب استدعاء TrustManagerService.revokeTrust() بعد أيّ من الحالتين التاليتين:
- يجب أن يكون الحد الأقصى 24 ساعة من تاريخ منح الثقة.
- فترة عدم نشاط لمدة 8 ساعات

إذا كانت عمليات تنفيذ الأجهزة المحمولة تتضمّن عدة مستخدمين ولم يتم الإفصاح عن علامة الميزة android.hardware.telephony، فإنّها:

[9.5/H-2-1] يجب أن تتوافق مع الملفات الشخصية المحظورة، وهي ميزة تتيح لأصحاب الأجهزة إدارة المستخدمين الإضافيين وإمكاناتهم على الجهاز. باستخدام الملفات الشخصية المقيّدة، يمكن لمالكي الأجهزة إعداد بيئات منفصلة بسرعة ليستخدمها مستخدمون آخرون، مع إمكانية إدارة قيود أكثر تفصيلاً في التطبيقات المتوفّرة في تلك البيئات.

إذا كانت عمليات تنفيذ الأجهزة المحمولة تتضمّن مستخدمين متعدّدين وتحدّد علامة الميزة android.hardware.telephony، فإنّها:

[9.5/H-3-1] يجب ألا يتيح استخدام الملفات الشخصية المقيدة، ولكن يجب أن يتوافق مع تنفيذ عناصر التحكّم في AOSP للسماح للمستخدمين الآخرين بالوصول إلى المكالمات الصوتية والرسائل القصيرة أو حظر ذلك.
[‫9.5/H-4-1] تمت إزالة هذا الشرط في الإصدار 16 من نظام التشغيل Android.
[‫9.5/H-4-2] تمت إزالة هذا الشرط في نظام التشغيل Android 16.

حظر المشاركة من خلال الإعدادات

توفّر "الإعدادات المقيدة" للمستخدم تحذيرات مرئية وتطلب منه تأكيدًا لمنح الأذونات لكل تطبيق من التطبيقات التالية:

أن يتم تثبيته بعد تنزيله من خلال تطبيق (مثل تطبيق مراسلة أو متصفّح) غير تطبيق "متجر التطبيقات" الذي تحدّده PackageManager على أنّه PACKAGE_DOWNLOADED_FILE.
أن يتم تثبيته من ملف محلي (على سبيل المثال، تم تحميل التطبيق بشكل جانبي) يتم تحديده من خلال PackageManager على أنّه PACKAGE_SOURCE_LOCAL_FILE.

أي من الأذونات المفروضة والمعرّفات المرتبطة بها والمدرَجة في [9.8/H-0-5] أدناه

ويتم تصنيف هذه التطبيقات على أنّها "تطبيقات مشمولة" في ما يتعلّق بالمتطلبات المدرَجة في هذا القسم.

عمليات تنفيذ الجهاز:

[9.8/H-0-1] يجب تنفيذ "الإعدادات المحظورة" كما هو موضّح أعلاه لما يلي:
- الأذونات الخاصة
  - تسهيل الاستخدام (AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE)
  - برنامج تلقّي الإشعارات الصوتية (AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS)
  - تطبيقات مشرف الجهاز (Manifest.permission.BIND_DEVICE_ADMIN)
  - العرض فوق التطبيقات الأخرى (AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW)
  - إذن الوصول إلى بيانات الاستخدام (AppOpsManager.OPSTR_GET_USAGE_STATS)
- الأدوار (التطبيقات التلقائية)
  - ‫Dialer‏ (‎RoleManager.ROLE_DIALER)
  - رسالة قصيرة (RoleManager.ROLE_SMS)
- أذونات التشغيل
  - مدة تشغيل الرسائل القصيرة (Manifest.permission_group.SMS)
‫[9.8/H-0-2] يجب تفعيل "الإعدادات المحظورة" كإعداد تلقائي، ويُنصح بشدة بعدم توفير أي وسيلة تتيح للمستخدم إيقاف "الإعدادات المحظورة" لجميع التطبيقات.
‫[9.8/H-0-3] يجب التأكّد من الحصول على تأكيد المستخدم لكل تطبيق خاضع للتغطية قبل منح أي من الأذونات المفروضة.
‫[9.8/H-0-4] يجب السماح فقط بالحصول على تأكيد المستخدم لتفعيل الإعدادات المحظورة من صفحة AppInfo الخاصة بالتطبيق المشمول باستخدام واجهة برمجة التطبيقات EnhancedConfirmationManager.
‫[9.8/H-0-5] يُنصح بشدة بالتكامل مع EnhancedConfirmationManager واستدعائه لجميع الأذونات الخاصة، وذلك لتحديد ما إذا كانت إعدادات مقيّدة بشكل ديناميكي.
- المنبّهات والتذكيرات: AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
- الوصول إلى كل الملفات: AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
- العرض فوق التطبيقات الأخرى: AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
- تثبيت التطبيقات غير المعروفة: AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
- إدارة الوسائط: AppOpsManager.OPSTR_MANAGE_MEDIA
- تعديل إعدادات النظام: AppOpsManager.OPSTR_WRITE_SETTINGS
- نافذة ضمن النافذة: AppOpsManager.OPSTR_PICTURE_IN_PICTURE
- تشغيل الشاشة: AppOpsManager.OPSTR_TURN_SCREEN_ON
- الإشعارات بملء الشاشة: AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
- التحكّم في شبكة Wi-Fi: AppOpsManager.OPSTR_CHANGE_WIFI_STATE
- تسهيل الاستخدام: AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
- برنامج تلقّي الإشعارات: AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
- إذن الوصول إلى بيانات الاستخدام: AppOpsManager.OPSTR_GET_USAGE_STATS
- مشرف الجهاز: Manifest.permission.BIND_DEVICE_ADMIN
- عدم الإزعاج: Manifest.permission.MANAGE_NOTIFICATIONS

يتيح نظام التشغيل Android من خلال واجهة برمجة التطبيقات VoiceInteractionService آلية آمنة لرصد الكلمات المهمة بشكل دائم بدون عرض مؤشر على استخدام الميكروفون، كما يتيح رصد طلبات البحث بشكل دائم بدون عرض مؤشر على استخدام الميكروفون أو الكاميرا.

إذا كانت عمليات تنفيذ الأجهزة المحمولة تتيح استخدام System API HotwordDetectionService أو آلية أخرى لرصد الكلمات المحفّزة بدون إشارة إلى إمكانية الوصول إلى الميكروفون، عليها استيفاء ما يلي:

[‫9.8/H-1-1] يجب التأكّد من أنّ خدمة رصد الكلمات المحفّزة يمكنها نقل البيانات إلى النظام أو ContentCaptureService أو خدمة التعرّف على الكلام على الجهاز التي أنشأتها SpeechRecognizer#createOnDeviceSpeechRecognizer() فقط.
‫[9.8/H-1-2] يجب التأكّد من أنّ خدمة رصد الكلمات المحفّزة لا يمكنها نقل بيانات الصوت من الميكروفون أو البيانات المستمدّة منه إلى خادم النظام إلا من خلال واجهة برمجة التطبيقات HotwordDetectionService أو إلى ContentCaptureService من خلال واجهة برمجة التطبيقات ContentCaptureManager.
[‫9.8/H-1-3] يجب عدم تقديم صوت من الميكروفون لمدة تزيد عن 30 ثانية لطلب فردي يتم تنشيطه من خلال الجهاز إلى خدمة رصد الكلمات الرئيسية.
[9.8/H-1-4] يجب عدم توفير صوت مخزّن مؤقتًا من الميكروفون أقدم من 8 ثوانٍ لطلب فردي إلى خدمة اكتشاف الكلمات المهمة.
‫[9.8/H-1-5] يجب عدم تزويد خدمة التفاعل الصوتي أو جهة مشابهة ببيانات صوتية مخزّنة مؤقتًا من الميكروفون أقدم من 30 ثانية.
‫[9.8/H-1-6] يجب ألا يسمح الجهاز بنقل أكثر من 100 بايت من البيانات (باستثناء بث الصوت) من خدمة رصد الكلمات المحفّزة عند كل نتيجة ناجحة لرصد الكلمة المحفّزة.
‫[9.8/H-1-7] يجب ألا تسمح بإرسال أكثر من 5 بتات من البيانات خارج خدمة رصد الكلمات المحفّزة في كل نتيجة سلبية للكلمة المحفّزة.
‫[9.8/H-1-8] يجب ألا تسمح إلا بنقل البيانات من خدمة رصد الكلمات المحفّزة عند تلقّي طلب التحقّق من صحة الكلمة المحفّزة من خادم النظام.
‫[9.8/H-1-9] يجب ألا يسمح بتوفير خدمة رصد الكلمات المحفّزة من خلال تطبيق يمكن للمستخدم تثبيته.
[‫9.8/H-1-10] يجب ألا تظهر في واجهة المستخدم بيانات كمية حول استخدام الميكروفون من خلال خدمة رصد العبارات المحفّزة.
‫[9.8/H-1-11] يجب تسجيل عدد البايتات المضمّنة في كل عملية نقل من خدمة رصد الكلمات المحفّزة للسماح لباحثي الأمان بفحصها.
‫[9.8/H-1-12] يجب توفير وضع تصحيح الأخطاء الذي يسجّل المحتوى الأولي لكل عملية نقل من خدمة رصد الكلمات المحفّزة للسماح لباحثي الأمان بفحصها.
[9.8/H-1-14] يجب عرض مؤشر الميكروفون، كما هو موضح في القسم 9.8.2، عند إرسال نتيجة كلمة مفتاح ناجحة إلى خدمة التفاعل الصوتي أو جهة مشابهة.
‫[9.8/H-1-15] يجب التأكّد من أنّ عمليات بث الصوت التي يتم توفيرها عند الحصول على نتائج صحيحة للكلمة المفتاح يتم إرسالها في اتجاه واحد من خدمة رصد الكلمة المفتاح إلى خدمة التفاعل الصوتي.
[‫9.8/H-SR-1] يُنصح بشدة بإعلام المستخدمين قبل ضبط تطبيق كمقدّم لخدمة رصد الكلمات المحفّزة.
‫[9.8/H-SR-2] يُنصح بشدة بعدم السماح بنقل البيانات غير المنظَّمة خارج خدمة رصد الكلمات المحفّزة.
‫[9.8/H-SR-3] يُنصح بشدة بإعادة تشغيل العملية التي تستضيف خدمة رصد الكلمات المحفّزة مرة واحدة على الأقل كل ساعة أو كل 30 حدثًا من أحداث التشغيل بواسطة الأجهزة، أيهما أقرب.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن تطبيقًا يستخدم واجهة برمجة التطبيقات للنظام HotwordDetectionService، أو آلية مشابهة لرصد الكلمات المحفّزة بدون الإشارة إلى استخدام الميكروفون، يجب أن يستوفي التطبيق ما يلي:

‫[9.8/H-2-1] يجب تقديم إشعار صريح للمستخدم بشأن كل عبارة من عبارات الكلمات الرئيسية الساخنة المتوافقة.
‫[9.8/H-2-2] يجب عدم الاحتفاظ ببيانات الصوت الخام أو البيانات المستمدّة منها من خلال خدمة رصد الكلمات المحفّزة.
‫[9.8/H-2-3] يجب عدم إرسال أي بيانات صوتية أو بيانات يمكن استخدامها لإعادة إنشاء الصوت (كليًا أو جزئيًا) أو محتوى صوتي غير ذي صلة بالكلمة المحفّزة نفسها من خدمة رصد الكلمات المحفّزة، باستثناء إرسالها إلى ContentCaptureService أو خدمة التعرّف على الكلام على الجهاز فقط.

إذا كانت عمليات تنفيذ الأجهزة المحمولة تتوافق مع System API VisualQueryDetectionService أو آلية أخرى لرصد طلبات البحث بدون الإشارة إلى إذن الوصول إلى الميكروفون و/أو الكاميرا، يجب أن:

‫[9.8/H-3-1] يجب التأكّد من أنّ خدمة رصد طلبات البحث لا يمكنها نقل البيانات إلا إلى النظام أو ContentCaptureService أو خدمة التعرّف على الكلام على الجهاز فقط (التي أنشأتها SpeechRecognizer#createOnDeviceSpeechRecognizer()).
[9.8/H-3-2] يجب ألا يسمح بنقل أي معلومات صوتية أو معلومات فيديو خارج VisualQueryDetectionService، باستثناء ContentCaptureService أو خدمة التعرّف على الكلام على الجهاز فقط.
‫[9.8/H-3-3] يجب عرض إشعار للمستخدم في واجهة مستخدم النظام عندما يرصد الجهاز نية المستخدم في التفاعل مع تطبيق "المساعد الرقمي" (مثلاً، من خلال رصد وجود المستخدم عبر الكاميرا).
‫[9.8/H-3-4] يجب عرض مؤشر ميكروفون وعرض طلب البحث الذي تم رصده في واجهة المستخدم بعد رصد طلب البحث مباشرةً.
[9.8/H-3-5] يجب ألا يسمح بتوفير خدمة رصد طلبات البحث المرئية من خلال تطبيق يمكن للمستخدم تثبيته.

إذا كانت عمليات تنفيذ الأجهزة المحمولة تعرّف android.hardware.microphone، فإنّها:

[9.8.2/H-4-1] يجب عرض مؤشر الميكروفون عندما يصل تطبيق إلى بيانات الصوت من الميكروفون، ولكن ليس عندما يصل إلى الميكروفون فقط HotwordDetectionService أو SOURCE_HOTWORD أو ContentCaptureService أو التطبيقات التي تؤدي الأدوار المحدّدة في الفقرة 9.1 مع معرّف مستند تعريف معايير التوافق (CDD) [C-4-X].
[9.8.2/H-4-2] يجب عرض قائمة بالتطبيقات الحديثة والنشطة التي تستخدم الميكروفون، وذلك باستخدام البيانات التي يتم عرضها من PermissionManager.getIndicatorAppOpUsageData()، بالإضافة إلى أي رسائل تحديد مصدر مرتبطة بها.
[9.8.2/H-4-3] يجب عدم إخفاء مؤشر الميكروفون للتطبيقات التابعة للنظام التي تتضمّن واجهات مستخدم مرئية أو تتطلّب تفاعلاً مباشرًا من المستخدم.
[9.8.2/H-4-4] يجب عرض قائمة بالتطبيقات "المستخدَمة مؤخرًا" و"النشطة" التي تستخدم الميكروفون، وذلك وفقًا لما يتم عرضه من خلال PermissionManager.getIndicatorAppOpUsageData()، بالإضافة إلى أي رسائل تحديد مصدر مرتبطة بها.

إذا كانت عمليات تنفيذ الأجهزة المحمولة تعرّف android.hardware.camera.any، فإنّها:

[9.8.2/H-5-1] يجب عرض مؤشر الكاميرا عندما يصل أحد التطبيقات إلى بيانات الكاميرا المباشرة، ولكن ليس عندما تصل التطبيقات التي لديها الأدوار المحدّدة في الفقرة 9.1 إلى الكاميرا فقط، مع معرّف متطلبات توافق الأجهزة [C-4-X].
[9.8.2/H-5-2] يجب عرض التطبيقات الحديثة والنشطة التي تستخدم الكاميرا كما هو موضح في PermissionManager.getIndicatorAppOpUsageData()، بالإضافة إلى أي رسائل تحديد مصدر مرتبطة بها.
[9.8.2/H-5-3] يجب عدم إخفاء مؤشر الكاميرا لتطبيقات النظام التي تتضمّن واجهات مستخدم مرئية أو تتطلّب تفاعلاً مباشرًا من المستخدم.

عندما يصل تطبيق غير تابع للنظام ويعمل في المقدّمة إلى الموقع الجغرافي الدقيق لجهاز، يفعل الجهاز ما يلي:

[9.8.8/H-6-1] يجب عرض مؤشر مرئي للمستخدم.

‫التشغيل المتحقّق منه هي ميزة تضمن سلامة برنامج الجهاز. إذا كانت عمليات تنفيذ الأجهزة تتيح هذه الميزة، فإنّها:

[9.10/H-1-1] يجب التحقّق من جميع الأقسام للقراءة فقط التي تم تثبيتها أثناء تسلسل بدء تشغيل Android، ويجب أن يتضمّن ملخّص VBMeta جميع هذه الأقسام التي تم التحقّق منها في عملية الحساب.

‫2.2.6. التوافق مع أدوات وخيارات المطوّرين

عمليات تنفيذ الأجهزة المحمولة (* لا ينطبق على الأجهزة اللوحية):

[6.1/H-0-1]* يجب أن يتيح تنفيذ أمر shell cmd testharness.

عمليات تنفيذ الأجهزة المحمولة:

Perfetto
- [6.1/H-0-2] يجب أن يعرض /system/bin/perfetto ملفًا ثنائيًا لمستخدم shell يتوافق سطر الأوامر الخاص به مع مستندات perfetto.
- [6.1/H-0-3] يجب أن يقبل ملف perfetto الثنائي كمدخل إعدادات protobuf تتوافق مع المخطط المحدّد في مستندات perfetto.
- [6.1/H-0-4] يجب أن يكتب ملف perfetto الثنائي كناتج عملية تتبُّع protobuf يتوافق مع المخطط المحدّد في مستندات perfetto.
- [6.1/H-0-5] يجب توفير مصادر البيانات الموضّحة في مستندات perfetto على الأقل، وذلك من خلال ملف perfetto الثنائي.
- [6.1/H-0-6] يجب تفعيل البرنامج الخفي الذي يتتبّع perfetto تلقائيًا (خاصية النظام persist.traced.enable).

‫2.2.7. فئة أداء أجهزة الوسائط المحمولة

أجرينا تغييرات كبيرة على بنية متطلبات فئة "أداء الوسائط". بدءًا من المستوى 37 من واجهة برمجة التطبيقات، أضفنا المستويات الجديدة 1 و10 و20 و37. لقد خفّفنا أيضًا من تعقيد المتطلبات من خلال الرجوع إلى صفحة قياسات فئة أداء الوسائط التي توضّح بالتفصيل كل متطلب يتم قياسه حسب مستوى MPC.

راجِع الفقرة 7.11 للتعرّف على تعريف فئة أداء الوسائط وتعريف فئة أداء الوسائط لجميع المقاييس.

2.2.7.1. الوسائط

إذا كانت عمليات تنفيذ الأجهزة المحمولة تعرض قيمة غير صفرية للسمة android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS، يجب أن:

يجب استيفاء جميع متطلبات الوسائط المدرَجة في القسم 2.2.7.1 من مستند تعريف التوافق مع Android 17 بما يتوافق مع مستوى فئة أداء الوسائط المعلَن للجهاز.
‫[5.1/H-1-1] يجب الإعلان عن الحد الأقصى لعدد جلسات فك ترميز الفيديو للأجهزة التي يمكن تشغيلها بشكل متزامن في أي مجموعة برامج ترميز من خلال الطريقتَين CodecCapabilities.getMaxSupportedInstances() وVideoCapabilities.getSupportedPerformancePoints() المتوافقتَين مع مستوى فئة أداء الوسائط المعلَن عنه للجهاز.
‫[5.1/H-1-2] يجب أن تتوافق مع جلسات فك ترميز الفيديو على مستوى الجهاز (AVC أو HEVC أو VP9 أو AV1 أو الإصدارات الأحدث)، ومع الحالات المتزامنة وانخفاض عدد اللقطات في الثانية بما يتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.1/H-1-3] يجب الإعلان عن الحد الأقصى لعدد جلسات ترميز الفيديو باستخدام الأجهزة التي يمكن تشغيلها بشكل متزامن في أي مجموعة برامج ترميز من خلال طريقتَي CodecCapabilities.getMaxSupportedInstances() وVideoCapabilities.getSupportedPerformancePoints() المتوافقتَين مع مستوى فئة أداء الوسائط المعلَن للجهاز.
‫[5.1/H-1-4] يجب أن تتوافق مع جلسات برنامج ترميز الفيديو للأجهزة (AVC أو HEVC أو VP9 أو AV1 أو الإصدارات الأحدث)، والعمليات المتزامنة، وإطارات الفيديو التي تم إسقاطها بما يتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.1/H-1-5] يجب الإعلان عن الحد الأقصى لعدد جلسات ترميز وفك ترميز الفيديو المتزامنة للأجهزة في أي مجموعة برامج ترميز من خلال الطريقتَين CodecCapabilities.getMaxSupportedInstances() وVideoCapabilities.getSupportedPerformancePoints() المتوافقتَين مع مستوى فئة أداء الوسائط الذي تم الإعلان عنه للجهاز.
‫[5.1/H-1-6] يجب أن يتيح الجهاز جلسات برنامج ترميز الفيديو وبرنامج فك ترميز الفيديو على مستوى الجهاز (AVC أو HEVC أو VP9 أو AV1 أو الإصدارات الأحدث)، بالإضافة إلى مثيلات متزامنة وعمليات إسقاط إطارات تتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.1/H-1-7] يجب أن يكون هناك تأخير في تهيئة برنامج الترميز لجلسة ترميز فيديو بدقة 1080p أو أقل لجميع برامج ترميز الفيديو المستندة إلى الأجهزة عند التحميل بما يتوافق مع مستوى فئة أداء الوسائط الذي تم تحديده للجهاز.
‫[5.1/H-1-8] يجب أن يكون هناك تأخير في بدء تشغيل الترميز عند معدل نقل بيانات يبلغ 128 كيلوبت في الثانية أو أقل في جلسة ترميز الصوت لجميع برامج ترميز الصوت عندما تكون قيد الاستخدام بما يتوافق مع مستوى فئة أداء الوسائط الذي تم الإعلان عنه للجهاز.
‫[5.1/H-1-9] يجب أن يتيح الجهاز تشغيل جلستَين لفك ترميز الفيديو باستخدام أجهزة آمنة (AVC أو HEVC أو VP9 أو AV1 أو الإصدارات الأحدث) مع إمكانية تجاهل اللقطات بما يتوافق مع مستوى فئة أداء الوسائط الذي تم الإعلان عنه للجهاز.
[‫5.1/H-1-10] يجب أن تتوافق مع 3 جلسات لبرنامج فك ترميز الفيديو غير الآمن على مستوى الجهاز، بالإضافة إلى جلسة واحدة لبرنامج فك ترميز الفيديو الآمن على مستوى الجهاز (4 جلسات إجمالاً) (AVC أو HEVC أو VP9 أو AV1 أو الإصدارات الأحدث)، والدقّات، وعمليات إسقاط الإطارات التي تتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.1/H-1-11] يجب توفير برنامج ترميز آمن لكل برنامج ترميز للأجهزة AVC أو HEVC أو VP9 أو AV1 يتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.1/H-1-12] يجب أن يكون هناك وقت استجابة لتهيئة برنامج الترميز لجلسة فك ترميز فيديو بدقة 1080p أو أقل لجميع برامج فك ترميز الفيديو على الأجهزة عندما يكون الجهاز تحت الحمل الذي يتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.1/H-1-13] يجب أن يكون هناك تأخير في بدء تشغيل الترميز لجميع برامج فك ترميز الصوت عند معدل نقل بيانات يبلغ 128 كيلوبت في الثانية أو أقل، وذلك عندما يكون الجهاز تحت الحمل الذي يتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.1/H-1-14] يجب أن يتوافق مع ملف تعريف برنامج ترميز AV1 وميزاته وطريقة عرضه بما يتوافق مع فئة أداء الوسائط المحدّدة للجهاز.
‫[5.1/H-1-15] يجب أن يتضمّن الجهاز برنامج ترميز فيديو واحدًا على الأقل للأجهزة المتوافقة مع دقة 4K60 بما يتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
[5.1/H-1-16] يجب أن يتضمّن الجهاز برنامج ترميز فيديو واحدًا على الأقل للأجهزة المتوافقة مع دقة 4K60 بما يتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
[5.1/H-1-17] يجب أن يتضمّن الجهاز برنامج ترميز صور للأجهزة واحدًا على الأقل متوافقًا مع الملف الشخصي للمرجع لـ AVIF بما يتوافق مع مستوى فئة أداء الوسائط الذي تم الإعلان عنه للجهاز.
‫[5.1/H-1-18] يجب أن يتوافق مع برنامج ترميز AV1 الذي يستوفي متطلبات معدل نقل البيانات والإطارات في الثانية والدقة بما يتوافق مع مستوى فئة أداء الوسائط المعلَن للجهاز.
‫[5.1/H-1-19] يجب أن يتيح الجهاز 3 مثيلات من جلسات برنامج ترميز الفيديو وبرنامج فك ترميز الفيديو للأجهزة (AVC أو HEVC أو VP9 أو AV1 أو الإصدارات الأحدث) بدقة 10 بت (HDR)، وأن يتيح عدد اللقطات في الثانية وعدد اللقطات التي تم إسقاطها بما يتوافق مع مستوى فئة أداء الوسائط الذي تم الإعلان عنه للجهاز.
‫[5.1/H-1-20] يجب أن تتوافق مع ميزة Feature_HdrEditing لجميع برامج ترميز AV1 وHEVC المضمّنة في الجهاز والمتوافقة مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.1/H-1-21] يجب أن تتوافق جميع برامج فك ترميز الفيديو للأجهزة (AVC أو HEVC أو VP9 أو AV1 أو الإصدارات الأحدث) مع FEATURE_DynamicColorAspect بما يتوافق مع مستوى فئة أداء الوسائط الذي تم الإعلان عنه في الجهاز.
‫[5.1/H-1-22] يجب أن يتيح الجهاز ترميز محتوى الفيديو وفك ترميزه وتعديله باستخدام وحدة معالجة الرسومات وعرضه بنسبة عرض إلى ارتفاع عمودية تتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
[5.2/H-2-1] إذا كان تصميم الجهاز يتوافق مع برامج ترميز AVC أو HEVC المستنِدة إلى الأجهزة، يجب أن يستوفي الحد الأدنى من مستوى الجودة المستهدَف المحدّد من خلال منحنيات معدل تشويه برنامج ترميز الفيديو لهذين البرنامجين، بما يتوافق مع مستوى فئة أداء الوسائط المعلَن للجهاز.

‫[5.2/H-2-2] يجب أن تتوافق مع MMAP على مسار السماعة الذي يتوافق مع مستوى فئة أداء الوسائط المحدّد في الجهاز.

‫[5.3/H-1-1] يجب استيفاء متطلبات أداء جلسة الفيديو ومتطلبات انخفاض عدد اللقطات في الثانية < 0x0A>المناسبة لمستوى فئة أداء الوسائط الذي تم الإعلان عنه للجهاز.
‫[5.3/H-1-2] يجب استيفاء متطلبات الأداء المتعلقة بتغيير درجة دقة الفيديو المناسبة لمستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.6/H-1-1] يجب استيفاء متطلبات وقت الاستجابة عند النقر لتشغيل الصوت بما يتوافق مع مستوى فئة أداء الوسائط المعلَن عنه للجهاز.
‫[5.6/H-1-2] يجب استيفاء متطلبات وقت استجابة الصوت ذهابًا وإيابًا بما يتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.6/H-1-3] يجب استيفاء متطلبات الصوت بدقة 24 بت بما يتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.6/H-1-4] يجب أن تتوافق الأجهزة مع أجهزة صوت USB بأربعة قنوات أو أكثر تتوافق مع مستوى فئة أداء الوسائط المحدّد في الجهاز.
‫[5.6/H-1-5] يجب أن تتوافق الأجهزة مع أجهزة MIDI المتوافقة مع الفئة، ويجب أن تحدّد علامة ميزة MIDI المتوافقة مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.6/H-1-9] يجب أن يتيح الجهاز دمج 12 قناة على الأقل بما يتوافق مع مستوى فئة أداء الوسائط المحدّد في الجهاز.

‫[5.6/H-3-1] يجب أن يكون الجهاز قادرًا على التبديل بين تشغيل الموجات الجيبية بدون حدوث نقص في مخازن الصوت المؤقتة التي تتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.6/H-3-2] يجب استيفاء متطلبات قنوات إخراج جهاز الصوت عبر USB المتوافقة مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.6/H-3-3] يجب استيفاء متطلبات قنوات إدخال جهاز الصوت عبر USB المناسبة لمستوى فئة أداء الوسائط المحدّد للجهاز.

[5.6/H-SR-1] يُنصح بشدة بتوفير إمكانية دمج قنوات الصوت بما يتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.7/H-1-2] يجب أن تتوافق مع MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL مع إمكانات فك التشفير المتوافقة مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.12/H-1-2] يجب استيفاء متطلبات تنسيق الألوان لأجهزة ترميز AV1 وHEVC بما يتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.12/H-1-3] يجب الإعلان عن إتاحة استخدام الإضافة EXT_YUV_target المناسبة لمستوى فئة أداء الوسائط المحدّد للجهاز.
‫[7.1.4/H-1-1] يجب استيفاء متطلبات وحدة معالجة العرض (DPU) التي تتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.

‫2.2.7.2. الكاميرا

إذا كانت عمليات تنفيذ الأجهزة المحمولة تعرض قيمة غير صفرية للسمة android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS، يجب أن تستوفي ما يلي:

يجب استيفاء متطلبات الكاميرا الواردة في القسم 2.2.7.2 من مستند تعريف التوافق لنظام التشغيل Android 17 المتعلّقة بمستوى فئة أداء الوسائط المحدّد للجهاز.

‫[7.5/H-1-1] يجب أن تستوفي الكاميرا الأساسية الخلفية متطلبات دقة الوضوح وتسجيل الفيديو التي تتوافق مع مستوى فئة أداء الوسائط المعلَن للجهاز.
‫[7.5/H-1-2] يجب أن تستوفي الكاميرا الأمامية الرئيسية متطلبات الدقة وتسجيل الفيديو المتوافقة مع مستوى فئة أداء الوسائط المعلَن للجهاز.
‫[7.5/H-1-3] يجب أن تتوافق مع متطلبات السمة android.info.supportedHardwareLevel المقابلة لمستوى فئة أداء الوسائط المحدّد للجهاز.
[7.5/H-1-4] يجب أن تتوافق CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME مع الكاميرات الأساسية المتوافقة مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[7.5/H-1-5] يجب استيفاء متطلبات وقت الاستجابة لالتقاط صور JPEG باستخدام Camera2 بما يتوافق مع مستوى فئة أداء الوسائط المعلَن للجهاز.
[7.5/H-1-6] يجب أن تستوفي متطلبات وقت الاستجابة عند بدء تشغيل camera2 التي تتوافق مع مستوى فئة أداء الوسائط الذي تم الإعلان عنه للجهاز.
‫[7.5/H-1-8] يجب استيفاء متطلبات التقاط الصور بالكاميرا بتنسيق RAW المناسبة لمستوى فئة أداء الوسائط المحدّد للجهاز.
[7.5/H-1-9] يجب استيفاء متطلبات التقاط الفيديو عالي السرعة باستخدام الكاميرا الأساسية الخلفية بما يتوافق مع مستوى فئة أداء الوسائط المعلَن للجهاز.
‫[7.5/H-1-10] يجب استيفاء الحد الأدنى لمتطلبات نسبة التكبير/التصغير المناسبة لمستوى فئة أداء الوسائط المحدّد للجهاز.
‫[7.5/H-1-11] يجب تنفيذ البث المتزامن من الأمام والخلف على الكاميرات الأساسية التي تتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
[7.5/H-1-12] يجب أن تتوافق الكاميرا الخلفية الأساسية مع ميزة تثبيت الفيديو بما يتوافق مع مستوى فئة أداء الوسائط الذي تم الإعلان عنه للجهاز.
‫[7.5/H-1-13] يجب أن تتوافق الكاميرا الخلفية الأساسية مع إمكانية LOGICAL_MULTI_CAMERA المناسبة لمستوى فئة أداء الوسائط الذي تم الإعلان عنه للجهاز.
[7.5/H-1-14] يجب أن تتوافق مع إمكانية STREAM_USE_CASE لكل من الكاميرا الأمامية الأساسية والكاميرا الخلفية الأساسية بما يتوافق مع مستوى فئة أداء الوسائط الذي تم الإعلان عنه للجهاز.
‫[7.5/H-1-15] يجب أن تتيح الكاميرات الأساسية التي تتوافق مع فئة أداء الوسائط المحدّدة للجهاز استخدام إضافات "الوضع الليلي" من خلال كل من CameraX وCamera2.
‫[7.5/H-1-16] يجب أن تتوافق الكاميرات الأساسية مع إمكانية DYNAMIC_RANGE_TEN_BIT المناسبة لمستوى فئة أداء الوسائط الذي تم الإعلان عنه للجهاز.
[7.5/H-1-17] يجب أن تتوافق الكاميرات الأساسية مع ميزات التعرّف على الوجوه بما يتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[7.5/H-1-18] يجب أن تتوافق الكاميرات الخلفية والأمامية الأساسية مع JPEG_R بما يتوافق مع مستوى فئة أداء الوسائط الذي تم الإعلان عنه للجهاز.
‫[7.5/H-1-19] يجب أن تتوافق الكاميرا الخلفية الأساسية مع CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION بما يتوافق مع مستوى فئة أداء الوسائط الذي تم الإعلان عنه للجهاز.
‫[7.5/H-1-20] يجب أن تعرض كاميرا الجهاز الخلفية الأساسية وكاميرا الجهاز الأمامية الأساسية JPEG_R تلقائيًا في تطبيق الكاميرا الأصلي بما يتوافق مع مستوى فئة أداء الوسائط الذي تم الإعلان عنه للجهاز.

[7.5/H-1-21] يجب أن يتضمّن الجهاز كاميرا واحدة على الأقل مواجهة للأمام أو كاميرا مواجهة للخلف تتوافق مع مستوى فئة أداء الوسائط الذي تم الإعلان عنه للجهاز.

‫2.2.7.3. الأجهزة

إذا كانت عمليات تنفيذ الأجهزة الجوّالة تعرض القيمة 20 لـ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS، يعني ذلك أنّها:

‫[7.1.1.1/H-1-1] يجب أن تكون دقة الشاشة 1080p على الأقل.
‫[7.1.1.3/H-1-1] يجب أن تبلغ كثافة الشاشة 400 نقطة لكل بوصة على الأقل.
‫[7.6/H-1-1] يجب أن تتوفّر مساحة 5.12 غيغابايت على الأقل للنواة كما هو موضّح في android.app.ActivityManager.MemoryInfo.

إذا كانت عمليات تنفيذ الأجهزة المحمولة تعرض قيمة غير صفرية للسمة android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS، يجب أن:

يجب استيفاء متطلبات الأجهزة الواردة في 2.2.7.3 المناسبة لمستوى فئة أداء الوسائط الذي تم الإفصاح عنه للجهاز.

إذا كانت عمليات تنفيذ الأجهزة المحمولة تعرض قيمة غير صفرية للسمة android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS، يجب أن:

[7.1.1.1/H-1-1] تم تخطّي هذا العنصر عمدًا.
‫[7.1.1.1/H-2-1] يجب أن تتوافق درجة دقة الشاشة مع مستوى فئة أداء الوسائط المحدّد للجهاز.
[7.1.1.3/H-1-1] تم تخطّي هذا العنصر عمدًا.
‫[7.1.1.3/H-2-1] يجب أن تتوافق كثافة الشاشة مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[7.1.1.3/H-3-1] يجب أن تتوافق مع متطلبات العرض بنطاق عالي الديناميكية (HDR) التي تتوافق مع مستوى فئة أداء الوسائط المحدَّد للجهاز.
[7.6.1/H-1-1] تم تخطّي هذا العنصر عمدًا.
[7.6.1/H-2-1] يجب استيفاء متطلبات الذاكرة التي تتوافق مع فئة أداء الوسائط المحدّدة للجهاز.

‫2.2.7.4. الأداء

يجب استيفاء متطلبات الأداء الواردة في القسم 2.2.7.4 من مستند تعريف التوافق لنظام التشغيل Android 17 المتعلّقة بفئة أداء الوسائط المحدّدة للجهاز.

‫[8.2/H-1-1] يجب ضمان أداء الكتابة التسلسلية بما يتوافق مع مستوى فئة أداء الوسائط المعلَن عنه للجهاز.
‫[8.2/H-1-2] يجب التأكّد من توفُّر أداء كتابة عشوائية يتوافق مع مستوى فئة أداء الوسائط المعلَن عنه للجهاز.
‫[8.2/H-1-3] يجب ضمان أداء القراءة التسلسلية بما يتوافق مع مستوى فئة أداء الوسائط المعلَن عنه في الجهاز.
‫[8.2/H-1-4] يجب التأكّد من توفّر أداء قراءة عشوائية يتوافق مع مستوى فئة أداء الوسائط المعلَن عنه في الجهاز.
‫[8.2/H-1-5] يجب ضمان أداء متوازٍ للقراءة والكتابة المتسلسلتَين يتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.

‫2.2.7.5. الرسومات

إذا كانت عمليات تنفيذ الأجهزة المحمولة تعرض قيمة غير صفرية للسمة android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS، يجب أن:

‫[7.1.4.1/H-1-2] يجب أن تتوافق مع إضافات EGL المطلوبة التي تتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[7.1.4.1/H-1-3] يجب أن تتوافق مع ميزات Vulkan المطلوبة التي تتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.

‫2.3. متطلبات التلفزيون

يشير جهاز Android Television إلى تنفيذ جهاز Android يمثّل واجهة ترفيهية لاستهلاك الوسائط الرقمية والأفلام والألعاب والتطبيقات و/أو البث التلفزيوني المباشر للمستخدمين الذين يجلسون على بُعد حوالي ثلاثة أمتار (أي "واجهة مستخدم مريحة" أو "واجهة مستخدم على بُعد ثلاثة أمتار").

يتم تصنيف عمليات تنفيذ أجهزة Android على أنّها تلفزيون إذا استوفت جميع المعايير التالية:

توفير آلية للتحكّم عن بُعد في واجهة المستخدم المعروضة على الشاشة التي قد تبعد ثلاثة أمتار عن المستخدم
أن يتضمّن شاشة عرض مدمجة يزيد طولها القطري عن 24 بوصة أو أن يتضمّن منفذ إخراج فيديو، مثل VGA أو HDMI أو DisplayPort أو منفذ لاسلكي للعرض

المتطلبات الإضافية الواردة في بقية هذا القسم خاصة بتنفيذ Android Television على الأجهزة.

‫2.3.1. الأجهزة

عمليات تنفيذ أجهزة التلفزيون:

[7.2.2/T-0-1] يجب أن يتيح استخدام لوحة الاتجاهات.
[7.2.3/T-0-1] يجب توفير وظيفتَي "الصفحة الرئيسية" و"رجوع".
[7.2.3/T-0-2] يجب إرسال كل من حدثَي الضغط العادي والضغط مع الاستمرار لوظيفة "الرجوع" (KEYCODE_BACK) إلى التطبيق الذي يعمل في المقدّمة.
[7.2.6.1/T-0-1] يجب أن تتضمّن دعمًا لأدوات التحكّم في الألعاب وأن تحدّد علامة الميزة android.hardware.gamepad.
[7.2.7/T] يجب توفير جهاز تحكّم عن بُعد يتيح للمستخدمين الوصول إلى التنقّل غير المستند إلى اللمس وإدخال مفاتيح التنقّل الأساسية.

إذا كانت عمليات تنفيذ أجهزة التلفزيون تتضمّن جيروسكوبًا ثلاثي المحاور، يجب أن:

[7.3.4/T-1-1] يجب أن يكون الجهاز قادرًا على تسجيل الأحداث بتردد لا يقل عن 100 هرتز.
[7.3.4/T-1-2] يجب أن يكون الجهاز قادرًا على قياس التغييرات في الاتجاه بمعدّل يصل إلى 1000 درجة في الثانية.

عمليات تنفيذ أجهزة التلفزيون:

‫[7.4.3/T-0-1] يجب أن يتوافق الجهاز مع البلوتوث والبلوتوث منخفض الطاقة.
[7.6.1/T-0-1] يجب أن تتوفّر مساحة تخزين غير متطايرة بسعة 4 غيغابايت على الأقل لبيانات التطبيق الخاصة (المعروفة أيضًا باسم قسم "/data").

إذا كانت عمليات تنفيذ أجهزة التلفزيون تتضمّن منفذ USB متوافقًا مع وضع المضيف، يجب أن:

‫[7.5.3/T-1-1] يجب أن يتضمّن الجهاز إمكانية توصيل كاميرا خارجية عبر منفذ USB هذا، ولكن ليس من الضروري أن تكون الكاميرا متصلة دائمًا.

إذا كانت عمليات تنفيذ أجهزة التلفزيون 32 بت:

‫[7.6.1/T-1-1] يجب أن تكون الذاكرة المتاحة لنواة النظام ومساحة المستخدم 896 ميغابايت على الأقل في حال استخدام أي من الكثافات التالية:
- ‫400 نقطة لكل بوصة أو أكثر على الشاشات الصغيرة أو العادية
- xhdpi أو أعلى على الشاشات الكبيرة
- tvddpi أو أعلى على الشاشات الكبيرة جدًا

في حال كانت عمليات تنفيذ أجهزة التلفزيون بتنسيق 64 بت:

‫[7.6.1/T-2-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 1280 ميغابايت على الأقل في حال استخدام أي من الكثافات التالية:
- ‫400 نقطة لكل بوصة أو أكثر على الشاشات الصغيرة أو العادية
- xhdpi أو أعلى على الشاشات الكبيرة
- tvddpi أو أعلى على الشاشات الكبيرة جدًا

عمليات تنفيذ أجهزة التلفزيون:

[7.8.1/T] يجب أن يتضمّن ميكروفونًا.
[7.8.2/T-0-1] يجب أن يتضمّن الجهاز منفذ إخراج صوت وأن يعرّف android.hardware.audio.output.

‫2.3.2. وسائط متعددة

يجب أن تتوافق عمليات تنفيذ أجهزة التلفزيون مع صيغ ترميز الصوت وفك ترميزه التالية وأن توفّرها للتطبيقات التابعة لجهات خارجية:

‫[5.1/T-0-1] ملف تعريف MPEG-4 AAC (برنامج الترميز AAC LC)
‫[5.1/T-0-2] ملف تعريف MPEG-4 HE AAC (برنامج الترميز AAC+)
‫[5.1/T-0-3] AAC ELD (ترميز AAC المحسّن ذو التأخير المنخفض)

[5.1/T-0-4] MPEG-D USAC with MPEG-D DRC (Extended High Efficiency AAC)

يجب أن تتوافق عمليات تنفيذ أجهزة التلفزيون مع تنسيقات ترميز الفيديو التالية وأن تتيحها للتطبيقات التابعة لجهات خارجية:

‫[5.2/T-0-1] H.264
[5.2/T-0-2] VP8
‫[5.2/T-0-3] AV1

عمليات تنفيذ أجهزة التلفزيون:

[5.2.2/T-SR-1] يُنصح بشدة بتوفير إمكانية ترميز فيديوهات بدقة 720p و1080p باستخدام H.264 بمعدل 30 لقطة في الثانية.

‫[5.3.3/T-0-1] MPEG-4 SP
‫[5.3.4/T-0-2] H.264 AVC
‫[5.3.5/T-0-3] H.265 HEVC
‫[5.3.6/T-0-4] VP8
[5.3.7/T-0-5] VP9
‫[5.3.1/T-0-6] MPEG-2
‫[5.3.2/T-0-7] AV1

يجب أن تتوافق عمليات تنفيذ أجهزة التلفزيون مع فك ترميز MPEG-2، كما هو موضّح بالتفصيل في القسم 5.3.1، بمعدلات لقطات الفيديو العادية ودرجات الدقة التي تصل إلى ما يلي:

‫[5.3.1/T-1-1] دقة عالية 1080p بمعدل 29.97 لقطة في الثانية مع الملف التعريفي الرئيسي عالي المستوى
‫[5.3.1/T-1-2] دقة عالية 1080i بمعدل 59.94 لقطة في الثانية مع الملف التعريفي الرئيسي عالي المستوى يجب أن يزيلوا التشابك من فيديوهات MPEG-2 المتشابكة ويتيحوها للتطبيقات الخارجية.

يجب أن تتيح عمليات تنفيذ أجهزة التلفزيون فك ترميز H.264، كما هو موضّح بالتفصيل في القسم 5.3.4، بمعدلات عرض لقطات الفيديو العادية ودرجات الدقة التي تصل إلى ما يلي:

‫[5.3.4/T-1-1] دقة عالية 1080p بمعدل 60 إطارًا في الثانية مع Baseline Profile
‫[5.3.4/T-1-2] دقة عالية 1080p بمعدل 60 إطارًا في الثانية مع Main Profile
‫[5.3.4/T-1-3] دقة عالية 1080p بمعدل 60 إطارًا في الثانية مع High Profile Level 4.2

يجب أن تتوافق عمليات تنفيذ أجهزة التلفزيون التي تتضمّن برامج فك ترميز H.265 مع فك ترميز H.265، كما هو موضّح بالتفصيل في القسم 5.3.5، وذلك بمعدّلات عرض لقطات الفيديو العادية وبدرجات دقة تصل إلى ما يلي:

‫[5.3.5/T-1-1] دقة عالية 1080p بمعدل 60 إطارًا في الثانية مع المستوى 4.1 من الملف الرئيسي

إذا كانت عمليات تنفيذ أجهزة التلفزيون التي تتضمّن برامج فك ترميز H.265 للأجهزة متوافقة مع فك ترميز H.265 وملف فك ترميز UHD، فإنّها:

[5.3.5/T-2-1] يجب أن تتوافق مع ملف تعريف فك الترميز بدقة UHD بمعدل 60 إطارًا في الثانية مع ملف تعريف Main10 Level 5 Main Tier

يجب أن تتوافق عمليات تنفيذ أجهزة التلفزيون مع فك ترميز VP8، كما هو موضّح بالتفصيل في القسم 5.3.6، بمعدلات لقطات الفيديو العادية ودرجات الدقة التي تصل إلى ما يلي:

‫[5.3.6/T-1-1] ملف فك الترميز بدقة 1080p عالية الوضوح وبسرعة 60 لقطة في الثانية

يجب أن تتوافق عمليات تنفيذ أجهزة التلفزيون التي تتضمّن برامج ترميز VP9 مع فك ترميز VP9، كما هو موضّح بالتفصيل في القسم 5.3.7، وذلك بمعدّلات عرض إطارات الفيديو القياسية ودقّات تصل إلى ما يلي:

‫[5.3.7/T-1-1] دقة عالية 1080p بمعدل 60 لقطة في الثانية مع الملف الشخصي 0 (عمق الألوان 8 بت)

إذا كانت عمليات تنفيذ أجهزة التلفزيون التي تتضمّن برامج فك ترميز VP9 للأجهزة تتوافق مع فك ترميز VP9 وملف تعريف فك الترميز بدقة UHD، يجب أن تستوفي ما يلي:

[5.3.7/T-2-1] يجب أن تتوافق مع ملف تعريف فك الترميز بدقة UHD بمعدل 60 إطارًا في الثانية مع ملف التعريف 0 (عمق الألوان 8 بت).
[5.3.7/T-SR1] يُنصح بشدة بتوفير ملف تعريف فك ترميز UHD بمعدل 60 إطارًا في الثانية مع ملف التعريف 2 (عمق الألوان 10 بت).

عمليات تنفيذ أجهزة التلفزيون:

[5.5/T-0-1] يجب أن يتضمّن الجهاز إمكانية التحكّم في مستوى الصوت الرئيسي للنظام وتخفيض مستوى صوت الإخراج الرقمي على منافذ الإخراج المتوافقة، باستثناء إخراج الصوت المضغوط (حيث لا يتم فك ترميز الصوت على الجهاز).

إذا كانت عمليات تنفيذ أجهزة التلفزيون لا تتضمّن شاشة عرض مدمجة، ولكنها تتيح بدلاً من ذلك شاشة عرض خارجية متصلة عبر HDMI، فإنّها:

[5.8/T-0-1] يجب ضبط وضع إخراج HDMI على أعلى دقة لتنسيق البكسل المحدّد الذي يتوافق مع معدّل التحديث 50 هرتز أو 60 هرتز للشاشة الخارجية، وذلك حسب معدّل تحديث الفيديو في المنطقة التي يتم بيع الجهاز فيها.
[5.8/T-SR-1] يُنصح بشدة بتوفير أداة اختيار معدّل تحديث HDMI يمكن للمستخدم ضبطها.
[5.8] يجب ضبط معدّل تحديث وضع إخراج HDMI على 50 هرتز أو 60 هرتز، حسب معدّل تحديث الفيديو في المنطقة التي يتم بيع الجهاز فيها.

‫[5.8/T-1-1] يجب أن تتوافق مع معيار HDCP 2.2.

إذا كانت عمليات تنفيذ أجهزة التلفزيون لا تتوافق مع فك ترميز UHD، ولكنها تتوافق بدلاً من ذلك مع شاشة عرض خارجية متصلة عبر HDMI، فإنّها:

[5.8/T-2-1] يجب أن تتوافق مع معيار HDCP 1.4

‫2.3.3. برامج

عمليات تنفيذ أجهزة التلفزيون:

[3/T-0-1] يجب الإفصاح عن الميزتَين android.software.leanback وandroid.hardware.type.television.
[3.2.3.1/T-0-1] يجب التحميل المُسبَق لتطبيق واحد أو أكثر أو لمكوّنات خدمة تتضمّن معالج intent، وذلك لجميع أنماط intent filter العامة المحدّدة من خلال أهداف التطبيقات التالية المدرَجة هنا.
[3.4.1/T-0-1] يجب توفير تنفيذ كامل لواجهة برمجة التطبيقات android.webkit.Webview.

إذا كانت عمليات تنفيذ أجهزة Android Television تتوافق مع شاشة القفل، يجب أن:

[3.8.10/T-1-1] يجب عرض الإشعارات على شاشة القفل، بما في ذلك نموذج إشعار الوسائط.

عمليات تنفيذ أجهزة التلفزيون:

‫[3.8.14/T-SR-1] يُنصح بشدة بتوفير وضع النوافذ المتعددة في وضع "نافذة ضمن النافذة" (PIP).
[3.10/T-0-1] يجب أن يتيح الجهاز استخدام خدمات تسهيل الاستخدام التابعة لجهات خارجية.
[3.10/T-SR-1] يُنصح بشدة بتثبيت خدمات تسهيل الاستخدام مسبقًا على الجهاز، على أن تكون هذه الخدمات مماثلة أو تتجاوز في وظائفها خدمات "الوصول عبر مفتاح تحويل" وTalkBack (باللغات التي يتوافق معها محرّك تحويل النص إلى كلام المثبّت مسبقًا)، وذلك على النحو الموضّح في مشروع TalkBack المفتوح المصدر.

إذا كانت عمليات تنفيذ أجهزة التلفزيون تتيح ميزة android.hardware.audio.output، يجب أن:

‫[3.11/T-SR-1] يُنصح بشدة بتضمين محرّك تحويل النص إلى كلام يتوافق مع اللغات المتوفرة على الجهاز.
[3.11/T-1-1] يجب أن يتيح تثبيت محركات تحويل النص إلى كلام التابعة لجهات خارجية.

يسهّل إطار عمل إدخال بيانات تلفزيون Android (TIF) عملية عرض المحتوى المباشر على أجهزة Android Television. توفّر TIF واجهة برمجة تطبيقات عادية لإنشاء وحدات إدخال تتحكّم في أجهزة Android Television.

عمليات تنفيذ أجهزة التلفزيون:

[3/T-0-2] يجب الإفصاح عن ميزة النظام الأساسي android.software.live_tv.
[3/T-0-3] يجب أن تتوافق مع جميع واجهات برمجة التطبيقات الخاصة بإطار عمل إدخال التلفزيون (TIF) كي يتمكّن المستخدم من تثبيت تطبيق يستخدم هذه الواجهات وخدمة إدخالات مستندة إلى إطار عمل إدخال التلفزيون (TIF) من جهة خارجية واستخدامهما على الجهاز.

يجمع إطار عمل موالف التلفزيون على Android (TF) بين معالجة المحتوى المباشر من موالف التلفزيون والمحتوى المتدفّق من بروتوكول الإنترنت (IP) على أجهزة Android Television. يوفّر إطار عمل Tuner Framework واجهة برمجة تطبيقات عادية لإنشاء خدمات إدخال تستخدم Android Television Tuner.

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع Tuner، فإنّها:

[3/T-1-1] يجب أن تتوافق مع جميع واجهات برمجة التطبيقات في Tuner Framework، بحيث يمكن تثبيت أي تطبيق يستخدم واجهات برمجة التطبيقات هذه واستخدامه على الجهاز.

‫2.3.4. الأداء والطاقة

‫[8.1/T-0-1] وقت استجابة ثابت للإطار: يجب ألا يحدث تأخير في عرض اللقطات أو عدم اتساق في وقت استجابة اللقطات أكثر من 5 لقطات في الثانية، ويجب أن يكون أقل من لقطة واحدة في الثانية.
[8.2/T-0-1] يجب ضمان أداء كتابة تسلسلي لا يقل عن 5 ميغابايت/ثانية.
[8.2/T-0-2] يجب ضمان أداء كتابة عشوائية لا يقل عن 0.5 ميغابايت/ثانية.
[8.2/T-0-3] يجب ضمان أداء قراءة تسلسلي لا يقل عن 15 ميغابايت/ثانية.
[8.2/T-0-4] يجب ضمان أداء قراءة عشوائية لا يقل عن 3.5 ميغابايت/ثانية.

إذا كانت عمليات تنفيذ أجهزة التلفزيون تتضمّن ميزات لتحسين إدارة طاقة الجهاز مضمّنة في AOSP أو توسّع الميزات المضمّنة في AOSP، يجب أن تستوفي ما يلي:

[8.3/T-1-1] يجب توفير إمكانية للمستخدم لتفعيل ميزة توفير شحن البطارية وإيقافها.

إذا كانت أجهزة التلفزيون لا تحتوي على بطارية، يجب أن:

[8.3/T-1-2] يجب تسجيل الجهاز كجهاز بدون بطارية كما هو موضّح في دعم الأجهزة التي لا تعمل بالبطارية.

إذا كانت أجهزة التلفزيون تتضمّن بطارية، يجب أن:

[8.3/T-1-3] يجب توفير إمكانية وصول المستخدم لعرض جميع التطبيقات المستثناة من وضعَي "تطبيقات وضع الاستعداد" و"قيلولة" و"وضع توفير الطاقة".

عمليات تنفيذ أجهزة التلفزيون:

[8.4/T-0-1] يجب توفير ملف تعريف طاقة لكل مكوّن يحدّد قيمة استهلاك التيار لكل مكوّن من مكوّنات الجهاز ومعدّل استنزاف البطارية التقريبي الذي تسبّبه المكوّنات بمرور الوقت، وذلك على النحو الموضّح في موقع "مشروع Android المفتوح المصدر".
[8.4/T-0-2] يجب تسجيل جميع قيم استهلاك الطاقة بوحدة ميلي أمبير في الساعة (mAh).
[8.4/T-0-3] يجب أن يتم تسجيل استهلاك طاقة وحدة المعالجة المركزية (CPU) لكل معرّف UID خاص بكل عملية. يستوفي "مشروع مفتوح المصدر لنظام Android" هذا الشرط من خلال تنفيذ وحدة النواة uid_cputime.
[8.4/T] يجب أن يتم تحديد مصدر استهلاك الطاقة على أنّه مكوّن الجهاز نفسه إذا تعذّر تحديد مصدر استهلاك الطاقة على أنّه تطبيق.
[8.4/T-0-4] يجب إتاحة معلومات استخدام الطاقة هذه لمطوّر التطبيق من خلال الأمر adb shell dumpsys batterystats في واجهة الأوامر.

‫2.3.5. نموذج الأمان

عمليات تنفيذ أجهزة التلفزيون:

[9/T-0-1] يجب الإفصاح عن ميزة android.hardware.security.model.compatible.

إذا كانت عمليات تنفيذ أجهزة التلفزيون تتضمّن تطبيقًا تلقائيًا لدعم VoiceInteractionService، يجب أن:

[9.1/T-0-1] يجب عدم منح ACCESS_FINE_LOCATION كإعداد تلقائي لهذا التطبيق.

عمليات تنفيذ أجهزة التلفزيون:

[9.11/T-0-1] يجب أن يتم الاحتفاظ بنسخة احتياطية من تنفيذ ملف تخزين المفاتيح في بيئة تنفيذ معزولة.
[9.11/T-0-2] يجب أن تتضمّن عمليات تنفيذ لخوارزميات التشفير RSA وAES وECDSA وHMAC، ودوال التجزئة MD5 وSHA-1 ومجموعة SHA-2، وذلك لتوفير الدعم المناسب للخوارزميات المتوافقة مع نظام Android Keystore في منطقة معزولة بشكل آمن عن الرمز البرمجي الذي يتم تنفيذه على النواة وما فوقها. يجب أن يحظر العزل الآمن جميع الآليات المحتملة التي قد يصل من خلالها رمز kernel أو رمز مساحة المستخدم إلى الحالة الداخلية للبيئة المعزولة، بما في ذلك الوصول المباشر إلى الذاكرة (DMA). يستوفي مشروع Android المفتوح المصدر (AOSP) هذا الشرط باستخدام تنفيذ Trusty، ولكن هناك خيارات بديلة أخرى، مثل حلّ آخر يستند إلى ARM TrustZone أو تنفيذ آمن راجعه طرف ثالث لعزل مناسب يستند إلى برنامج مراقبة الأجهزة الافتراضية.
‫[9.11/T-0-3] يجب إجراء مصادقة شاشة القفل في بيئة تنفيذ معزولة، ولا يُسمح باستخدام المفاتيح المرتبطة بالمصادقة إلا عند نجاحها. يجب تخزين بيانات اعتماد شاشة القفل بطريقة لا تسمح إلا لبيئة التنفيذ المعزولة بإجراء مصادقة شاشة القفل. يوفر مشروع Android مفتوح المصدر طبقة تجريد الأجهزة (HAL) في Gatekeeper وTrusty، ويمكن استخدامهما لاستيفاء هذا الشرط.
‫[9.11/T-0-4] يجب أن تتوافق مع مصادقة المفتاح حيث يكون مفتاح التوقيع الخاص بالمصادقة محميًا بواسطة أجهزة آمنة ويتم التوقيع في أجهزة آمنة. يجب منع استخدام مفاتيح توقيع شهادة التصديق كمعرّفات دائمة للأجهزة.

ملاحظة: لاستيفاء هذا الشرط، يجب مشاركة مفتاح التصديق نفسه لرمز تخزين تعريفي معيّن ما لم يتم إنتاج 100,000 وحدة على الأقل من رمز التخزين التعريفي هذا. إذا تم إنتاج أكثر من 100,000 وحدة من رمز التخزين التعريفي هذا، يمكن استخدام مفتاح مختلف لكل مجموعة من 100,000 وحدة بعد ذلك. بدلاً من ذلك، يمكن استخدام حلّ Remote Key Provisioning لتوفير مفاتيح تصديق قصيرة الأمد للجهاز.

في حال كانت عمليات تنفيذ أجهزة التلفزيون تتيح شاشة قفل آمنة، يجب أن تستوفي ما يلي:

[9.11/T-1-1] يجب أن يسمح الجهاز للمستخدم باختيار مهلة السكون للانتقال من حالة إلغاء القفل إلى حالة القفل، مع حد أدنى مسموح به للمهلة يصل إلى 15 ثانية أو أقل.

إذا كانت عمليات تنفيذ أجهزة التلفزيون تتضمّن عدة مستخدمين ولم يتم الإفصاح عن علامة الميزة android.hardware.telephony، فإنّها:

[9.5/T-2-1] يجب أن تتوافق الأجهزة مع الملفات الشخصية المحظورة، وهي ميزة تتيح لمالكي الأجهزة إدارة المستخدمين الإضافيين وإمكاناتهم على الجهاز. باستخدام الملفات الشخصية المقيّدة، يمكن لمالكي الأجهزة إعداد بيئات منفصلة بسرعة ليستخدمها مستخدمون آخرون، مع إمكانية إدارة قيود أكثر تفصيلاً في التطبيقات المتوفّرة في تلك البيئات.

إذا كانت عمليات تنفيذ أجهزة التلفزيون تتضمّن مستخدمين متعدّدين وتحدّد علامة الميزة android.hardware.telephony، فإنّها:

[9.5/T-3-1] يجب ألا تتوافق الأجهزة مع الملفات الشخصية المحظورة، ولكن يجب أن تتوافق مع تنفيذ AOSP لعناصر التحكّم التي تتيح للمستخدمين الآخرين الوصول إلى المكالمات الصوتية والرسائل القصيرة أو حظرها.

إذا كانت عمليات تنفيذ أجهزة التلفزيون تعرّف android.hardware.microphone، يجب أن تستوفي ما يلي:

[9.8.2/T-4-1] يجب عرض مؤشر الميكروفون عندما يصل تطبيق إلى البيانات الصوتية من الميكروفون، ولكن ليس عندما يصل إلى الميكروفون فقط HotwordDetectionService أو SOURCE_HOTWORD أو ContentCaptureService أو التطبيقات التي تؤدي الأدوار المحدّدة في القسم 9.1 أذونات مع معرّف توافق CDD C-3-X.
[9.8.2/T-4-2] يجب عدم إخفاء مؤشر الميكروفون لتطبيقات النظام التي تتضمّن واجهات مستخدم مرئية أو تتطلّب تفاعلاً مباشرًا من المستخدم.

إذا كانت عمليات تنفيذ أجهزة التلفزيون تعرّف android.hardware.camera.any، يجب أن تستوفي ما يلي:

[9.8.2/T-5-1] يجب عرض مؤشر الكاميرا عندما يصل تطبيق إلى بيانات الكاميرا المباشرة، ولكن ليس عندما تصل تطبيقات إلى الكاميرا فقط إذا كانت هذه التطبيقات تحمل الأدوار المحدّدة في القسم 9.1 "الأذونات" مع معرّف مستند تعريف التوافق [C-3-X].
[9.8.2/T-5-2] يجب عدم إخفاء مؤشر الكاميرا لتطبيقات النظام التي تتضمّن واجهات مستخدم مرئية أو تفاعلاً مباشرًا مع المستخدم.

‫2.3.6. التوافق مع أدوات وخيارات المطوّرين

عمليات تنفيذ أجهزة التلفزيون:

Perfetto
- [6.1/T-0-1] يجب توفير /system/bin/perfetto ملف ثنائي لمستخدم shell يتوافق سطر الأوامر الخاص به مع مستندات perfetto.
- [6.1/T-0-2] يجب أن يقبل ملف perfetto الثنائي كإدخال إعدادات protobuf تتوافق مع المخطط المحدّد في مستندات perfetto.
- [6.1/T-0-3] يجب أن يكتب ملف perfetto الثنائي كناتج تتبُّع protobuf يتوافق مع المخطط المحدّد في مستندات perfetto.
- [6.1/T-0-4] يجب توفير مصادر البيانات الموضّحة في مستندات perfetto على الأقل، وذلك من خلال ملف perfetto الثنائي.
- [6.1/T-0-5] يجب تفعيل البرنامج الخفي الذي تم تتبُّعه في perfetto تلقائيًا (سمة النظام persist.traced.enable).

‫2.4. متطلبات الساعة

يشير جهاز Android Watch إلى تنفيذ جهاز Android مصمَّم ليتم ارتداؤه على الجسم، ربما على المعصم.

يتم تصنيف عمليات تنفيذ أجهزة Android على أنّها ساعة إذا استوفت جميع المعايير التالية:

أن تتضمّن شاشة يتراوح طول قطرها الفعلي بين 1.1 و2.5 بوصة
أن يتضمّن آلية يمكن ارتداؤها على الجسم

المتطلبات الإضافية الواردة في بقية هذا القسم خاصة بتنفيذ Android Watch على الأجهزة.

2.4.1. الأجهزة

طُرق استخدام أجهزة الساعات الذكية:

[7.1.1.1/W-0-1] يجب أن يتضمّن الجهاز شاشة يتراوح حجم قطرها المادي بين 1.1 و2.5 بوصة.
[7.2.3/W-0-1] يجب أن تتوفّر للمستخدم وظيفة "الصفحة الرئيسية" ووظيفة "رجوع" باستثناء الحالات التي تكون فيها في UI_MODE_TYPE_WATCH.
‫[7.2.4/W-0-1] يجب أن يتيح إدخال البيانات عبر شاشة اللمس.
‫[7.3.1/W-SR-1] يُنصح بشدة بتضمين مقياس تسارع ثلاثي المحاور.

إذا كانت عمليات تنفيذ أجهزة Watch تتضمّن جهاز استقبال GPS/GNSS وتُبلغ التطبيقات عن الإمكانية من خلال علامة الميزة android.hardware.location.gps، فإنّها:

[7.3.3/W-1-1] يجب إرسال قياسات GNSS فور العثور عليها، حتى إذا لم يتم بعد إرسال الموقع الجغرافي المحسوب من نظام تحديد المواقع العالمي (GPS) أو نظام GNSS.
[7.3.3/W-1-2] يجب أن يتم عرض نطاقات زائفة لنظام GNSS ومعدلات النطاقات الزائفة، والتي تكون كافية لاحتساب الموقع الجغرافي في نطاق 20 مترًا والسرعة في نطاق 0.2 متر في الثانية، وذلك بنسبة% 95 على الأقل من الوقت، في ظروف السماء المفتوحة بعد تحديد الموقع الجغرافي، سواء كان الجهاز ثابتًا أو يتحرّك بمعدّل تسارع أقل من 0.2 متر في الثانية المربعة.

إذا كانت عمليات تنفيذ أجهزة Watch تتضمّن جيروسكوب ثلاثي المحاور، يجب أن تستوفي ما يلي:

‫[7.3.4/W-2-1] يجب أن يكون الجهاز قادرًا على قياس التغييرات في الاتجاه بما يصل إلى 1000 درجة في الثانية.

إذا كانت عمليات تنفيذ أجهزة الساعات تتوافق مع إمكانية الاتصال ببيانات شبكة الجوّال، يجب أن تستوفي الشروط التالية:

[7.4.1/W-1-1] يجب الإفصاح عن ميزة android.hardware.telephony.data.

طُرق استخدام أجهزة الساعات الذكية:

[7.4.3/W-0-1] يجب أن تتوافق مع تقنية البلوتوث.
‫[7.6.1/W-0-1] يجب أن تتوفّر مساحة تخزين غير متطايرة لا تقل عن 1 غيغابايت لتخزين البيانات الخاصة بالتطبيق (المعروفة أيضًا باسم قسم "‎/data").
‫[7.6.1/W-0-2] يجب أن تتوفّر ذاكرة بسعة 416 ميغابايت على الأقل للنواة ومساحة المستخدم.
[7.8.1/W-0-1] يجب أن يتضمّن الجهاز ميكروفونًا.
[7.8.2/W] قد يتضمّن ميزة إخراج الصوت.

‫2.4.2. وسائط متعددة

ما مِن متطلبات إضافية.

‫2.4.3. برامج

طُرق استخدام أجهزة الساعات الذكية:

[3/W-0-1] يجب الإفصاح عن الميزة android.hardware.type.watch.
[3/W-0-2] يجب أن تتوافق مع uiMode = UI_MODE_TYPE_WATCH.
[3.2.3.1/W-0-1] يجب التحميل المُسبَق لتطبيق واحد أو أكثر أو لمكوّنات خدمة تتضمّن معالج intent، وذلك لجميع أنماط intent filter العامة التي تحدّدها تطبيقات intent التالية المدرَجة هنا.

طُرق استخدام أجهزة الساعات الذكية:

‫[3.8.4/W-SR-1] يُنصح بشدة بتضمين مساعد على الجهاز للتعامل مع إجراء المساعدة.

مشاهدة عمليات تنفيذ الجهاز التي تحدّد علامة الميزة android.hardware.audio.output

[3.10/W-1-1] يجب أن تتوافق مع خدمات تسهيل الاستخدام التابعة لجهات خارجية.
[3.10/W-SR-1] يُنصح بشدة بالتحميل مسبقًا لخدمات تسهيل الاستخدام على الجهاز، على أن تكون هذه الخدمات مماثلة أو تتجاوز وظائف خدمات "الوصول عبر مفتاح تحكّم" وTalkBack (بالنسبة إلى اللغات التي يتوافق معها محرّك تحويل النص إلى كلام المثبَّت مسبقًا) كما هو موضّح في مشروع TalkBack المفتوح المصدر.

إذا كانت عمليات تنفيذ أجهزة الساعات تعرض الميزة android.hardware.audio.output، فإنّها:

‫[3.11/W-SR-1] يُنصح بشدة بتضمين محرك تحويل النص إلى كلام يتوافق مع اللغات المتوفرة على الجهاز.
[3.11/W-0-1] يجب أن يتيح تثبيت محركات تحويل النص إلى كلام تابعة لجهات خارجية.

‫2.4.4. الأداء والطاقة

إذا كانت عمليات تنفيذ أجهزة Watch تتضمّن ميزات لتحسين إدارة طاقة الجهاز مضمّنة في AOSP أو توسّع الميزات المضمّنة في AOSP، يجب أن تستوفي ما يلي:

[8.3/W-SR-1] يُنصح بشدة بتوفير إمكانية وصول المستخدم لعرض جميع التطبيقات المستثناة من وضع "استعداد التطبيق" ووضع توفير الطاقة "وضع السكون".
[8.3/W-SR-2] يُنصح بشدة بتوفير إمكانية للمستخدمين لتفعيل ميزة "توفير شحن البطارية" وإيقافها.

طُرق استخدام أجهزة الساعات الذكية:

[8.4/W-0-1] يجب توفير ملف تعريف طاقة لكل مكوّن يحدّد قيمة استهلاك التيار لكل مكوّن من مكوّنات الجهاز ومعدّل استهلاك البطارية التقريبي الذي تسبّبه المكوّنات بمرور الوقت، وذلك على النحو الموضّح في موقع "مشروع Android المفتوح المصدر".
[8.4/W-0-2] يجب تسجيل جميع قيم استهلاك الطاقة بوحدة ميلي أمبير في الساعة (mAh).
[8.4/W-0-3] يجب عرض استهلاك طاقة وحدة المعالجة المركزية (CPU) لكل معرّف UID خاص بكل عملية. يستوفي "مشروع مفتوح المصدر لنظام Android" هذا الشرط من خلال تنفيذ وحدة النواة uid_cputime.
[8.4/W-0-4] يجب أن يتيح الجهاز للمطوّر إمكانية الاطّلاع على بيانات استهلاك الطاقة من خلال الأمر adb shell dumpsys batterystats في واجهة سطر الأوامر.
[8.4/W] يجب أن يتم تحديد مصدرها على أنّه مكوّن الجهاز نفسه إذا تعذّر تحديد مصدرها على أنّه تطبيق.

‫2.4.5. نموذج الأمان

طُرق استخدام أجهزة الساعات الذكية:

[9/W-0-1] يجب الإفصاح عن ميزة android.hardware.security.model.compatible.

إذا كانت عمليات تنفيذ أجهزة الساعات تتضمّن تطبيقًا تلقائيًا لدعم VoiceInteractionService، يجب أن:

[9.1/W-0-1] يجب عدم منح ACCESS_FINE_LOCATION كإذن تلقائي لهذا التطبيق.

إذا كانت عمليات تنفيذ أجهزة Watch تتضمّن تعدُّد المستخدمين ولم يتم الإفصاح عن علامة الميزة android.hardware.telephony، فإنّها:

[9.5/W-1-1] يجب أن تتوافق الأجهزة مع الملفات الشخصية المحظورة، وهي ميزة تتيح لمالكي الأجهزة إدارة المستخدمين الإضافيين وإمكاناتهم على الجهاز. باستخدام الملفات الشخصية المقيّدة، يمكن لمالكي الأجهزة إعداد بيئات منفصلة بسرعة ليستخدمها مستخدمون آخرون، مع إمكانية إدارة قيود أكثر تفصيلاً في التطبيقات المتوفّرة في تلك البيئات.

إذا كانت عمليات تنفيذ Watch device تتضمّن عدة مستخدمين وتعلن عن علامة الميزة android.hardware.telephony، فإنّها:

[9.5/W-2-1] يجب ألا يتيح استخدام الملفات الشخصية المحظورة، ولكن يجب أن يتوافق مع تنفيذ عناصر التحكّم في AOSP للسماح للمستخدمين الآخرين بالوصول إلى المكالمات الصوتية والرسائل القصيرة أو حظرهم من ذلك.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة قفل آمنة وتشمل وكيلًا معتمدًا واحدًا أو أكثر، ينفّذ واجهة برمجة التطبيقات TrustAgentService System API، فإنّها:

[9.11.1/W-1-1] يجب أن يطلب النظام من المستخدم إثبات هويته باستخدام إحدى طرق المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) بشكل متكرر أكثر من مرة واحدة كل 72 ساعة على الأقل كل 336 ساعة (14 يومًا).

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة قفل آمنة وتشمل وكيلًا معتمَدًا واحدًا أو أكثر، ويتم استدعاء واجهة برمجة التطبيقات TrustAgentService.grantTrust() للنظام باستخدام العلامة FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE، فإنّها:

[9.11.1/W-2-1] يجب استيفاء الشروط التالية لاستدعاء grantTrust() باستخدام هذه العلامة:
- أن يكون الجهاز متصلاً بجهاز أساسي محمول قريب مزوّد بشاشة قفل خاصة به
- أثبت المستخدم هويته باستخدام شاشة القفل أو المقاييس الحيوية من الفئة 3 خلال آخر 30 ثانية.
[9.11.1/W-2-2] يجب ضبط حالة الجهاز على TrustState.TRUSTABLE عندما تتم إزالة الجهاز القابل للارتداء من المعصم أو الجسم ولم يلغِ TrustAgent حالة الثقة.

‫2.5. متطلبات السيارات

يشير تنفيذ Android Automotive إلى وحدة رئيسية في مركبة تعمل بنظام التشغيل Android لجزء من النظام و/أو وظائف الترفيه والمعلومات أو كلها.

يتم تصنيف عمليات تنفيذ أجهزة Android على أنّها Automotive إذا كانت تتضمّن الميزة android.hardware.type.automotive أو تستوفي جميع المعايير التالية.

أن تكون مدمجة كجزء من مركبة آلية أو قابلة للتوصيل بها
استخدام شاشة في صف مقعد السائق كشاشة عرض أساسية

المتطلبات الإضافية الواردة في بقية هذا القسم خاصة بتنفيذ Android Automotive على الأجهزة.

2.5.1. الأجهزة

عمليات تنفيذ أجهزة السيارات:

[7.1.1.1/A-0-1] يجب أن تتضمّن شاشة لا يقل حجمها القطري عن 6 بوصات.
[7.1.1.1/A-0-2] يجب أن يتضمّن الجهاز تصميمًا بحجم شاشة يبلغ 750 وحدة بكسل مستقلة عن الكثافة × 480 وحدة بكسل مستقلة عن الكثافة على الأقل.
[7.1.1.1/A-0-3] يجب أن يتيح الجهاز إنشاء تركيبات باستخدام وحدة معالجة الرسومات (GPU) لمخازن مؤقتة للرسومات لا تقل سعتها عن أعلى دقة لأي شاشة مدمجة.

إذا كانت عمليات تنفيذ أجهزة Automotive تتوافق مع ميزة "استخدام عدة مستخدمين في الوقت نفسه" (حيث يمكن لعدة مستخدمي Android التفاعل مع الجهاز في الوقت نفسه، ويستخدم كل منهم شاشته الخاصة عند تفعيل config_multiuserVisibleBackgroundUsers)، يجب أن تستوفي ما يلي:

[7.1.1.1/A-1-1] يجب أن تتضمّن شاشة منفصلة بحجم قطري يبلغ 6 بوصات على الأقل لكل منطقة مخصّصة للركاب في الشاشة الرئيسية. يجب وضع العلامة CarOccupantZoneManager.DISPLAY_TYPE_MAIN لكل منطقة مخصّصة للركاب.
[7.1.1.1/A-1-2] يجب أن يتضمّن الجهاز تصميمًا بحجم شاشة لا يقل عن 750 وحدة بكسل مستقل الكثافة × 480 وحدة بكسل مستقل الكثافة لكل شاشة عرض رئيسية.

إذا كانت عمليات تنفيذ أجهزة Automotive تتوافق مع OpenGL ES 3.1، يجب أن تستوفي ما يلي:

[7.1.4.1/A-0-1] يجب الإعلان عن توفّر OpenGL ES 3.1 أو إصدار أحدث.
[7.1.4.1/A-0-2] يجب أن تتوافق مع Vulkan 1.1.
‫[7.1.4.1/A-0-3] يجب أن تتضمّن أداة تحميل Vulkan وأن تصدّر جميع الرموز.

إذا كانت عمليات تنفيذ أجهزة Automotive تتضمّن إتاحة Vulkan، يجب أن تستوفي ما يلي:

[7.1.4.2/A-1-1] يجب استيفاء المتطلبات المحدّدة في الملف الشخصي الأساسي لنظام Android لعام 2021.

إذا كانت عمليات تنفيذ أجهزة Automotive تدّعي إتاحة شاشات بنطاق عالي الديناميكية من خلال Configuration.isScreenHdr()، يجب أن تستوفي ما يلي:

[7.1.4.5/A-1-1] يجب أن تعلن عن توفيرها الدعم للامتدادات EGL_EXT_gl_colorspace_bt2020_pq وEGL_EXT_surface_SMPTE2086_metadata وEGL_EXT_surface_CTA861_3_metadata وVK_EXT_swapchain_colorspace وVK_EXT_hdr_metadata.

عمليات تنفيذ أجهزة السيارات:

‫[7.1.4.6/A-0-1] يجب الإبلاغ عما إذا كان الجهاز يتوافق مع إمكانية إنشاء ملفات تعريف لوحدة معالجة الرسومات من خلال سمة نظام graphics.gpu.profiler.support.

إذا كانت عمليات تنفيذ أجهزة Automotive تعلن عن إتاحة ميزة <0x0A>graphics.gpu.profiler.support من خلال إحدى سمات النظام، يجب أن تستوفي ما يلي:

[7.1.4.6/A-1-1] يجب أن يتم عرض تقرير كناتج يتضمّن عملية تتبُّع بتنسيق Protobuf تتوافق مع مخطط عدّادات وحدة معالجة الرسومات ومراحل العرض في وحدة معالجة الرسومات المحدّدة في مستندات Perfetto.
[7.1.4.6/A-1-2] يجب إرسال قيم متوافقة لعدّادات وحدة معالجة الرسومات في الجهاز وفقًا بروتوكول حزمة gpu counter trace.
[7.1.4.6/A-1-3] يجب عرض قيم متوافقة لمراحل العرض في وحدة معالجة الرسومات بالجهاز وفقًا لحزمة بروتوكول تتبُّع مراحل العرض.
[7.1.4.6/A-1-4] يجب عرض نقطة تتبُّع "تردد وحدة معالجة الرسومات" بالتنسيق المحدّد: power/gpu_frequency.

عمليات تنفيذ أجهزة السيارات:

[7.1.5/A-0-1] يجب أن يتضمّن دعمًا لوضع التوافق مع التطبيقات القديمة كما هو مطبَّق في رمز المصدر المفتوح لنظام Android. أي أنّه يجب ألا تغيّر عمليات تنفيذ الجهاز المشغّلات أو الحدود التي يتم عندها تفعيل وضع التوافق، ويجب ألا تغيّر سلوك وضع التوافق نفسه.

عمليات تنفيذ أجهزة السيارات:

‫[7.1.7/A-0-1] يجب ضبط الشاشات الثانوية في مجال رؤية السائق على FLAG_PRIVATE.
‫[7.2.3/A-0-1] يجب توفير وظيفة "الصفحة الرئيسية"، ويجوز توفير وظيفتَي "رجوع" و"التطبيقات الحديثة".
[7.2.3/A-0-2] يجب إرسال كل من حدث الضغط العادي والضغط لفترة طويلة على زر الرجوع (KEYCODE_BACK) إلى التطبيق الذي يعمل في المقدّمة.
[7.3/A-0-1] يجب تنفيذ GEAR_SELECTION وNIGHT_MODE وPERF_VEHICLE_SPEED وPARKING_BRAKE_ON والإبلاغ عنها.
[7.3/A-0-2] يجب أن تكون قيمة العلامة NIGHT_MODE متوافقة مع وضع النهار/الليل في لوحة البيانات، ويجب أن تستند إلى بيانات أداة استشعار الضوء المحيط. قد تكون أداة استشعار الضوء المحيط الأساسية هي نفسها مقياس الضوء.
[7.3/A-0-3] يجب توفير حقل معلومات إضافية عن جهاز الاستشعار TYPE_SENSOR_PLACEMENT كجزء من SensorAdditionalInfo لكل جهاز استشعار يتم توفيره.
[7.3/A-SR1] MAY dead reckon Location by fusing GPS/GNSS with additional sensors. إذا تم احتساب الموقع الجغرافي باستخدام التقدير التقريبي، يُنصح بشدة بتنفيذ أنواع المستشعرات و/أو معرّفات خصائص المركبة المستخدَمة وإعداد تقارير بشأنها.
[7.3/A-0-4] يجب عدم ربط بيانات الموقع الجغرافي المطلوبة من خلال LocationManager#requestLocationUpdates() بالخريطة.
‫[7.3.1/A-0-4] يجب أن يتوافق مع نظام إحداثيات مستشعر السيارة في Android.
[7.3/A-SR-1] يُنصح بشدة بتضمين مقياس تسارع ثلاثي المحاور وجيروسكوب ثلاثي المحاور.
[7.3/A-SR-2] يُنصح بشدة بتنفيذ تقرير TYPE_HEADING المستشعر.

[7.3/A-1-1] يجب ضبط قيمة العلامة NIGHT_MODE بشكل متسق مع وضع النهار/الليل في لوحة البيانات على جميع الشاشات، بما في ذلك شاشات المقاعد الخلفية.

إذا كانت عمليات تنفيذ أجهزة Automotive تتضمّن مقياس تسارع، يجب أن:

[7.3.1/A-1-1] يجب أن يكون الجهاز قادرًا على تسجيل الأحداث بتردد لا يقل عن 100 هرتز.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس تسارع ثلاثي المحاور، يجب أن:

‫[7.3.1/A-SR-1] يُنصح بشدة بتنفيذ أداة الاستشعار المركّبة لمقياس التسارع ذي المحاور المحدودة.

إذا كانت عمليات تنفيذ أجهزة Automotive تتضمّن مقياس تسارع بأقل من 3 محاور، يجب أن:

[7.3.1/A-1-3] يجب تنفيذ TYPE_ACCELEROMETER_LIMITED_AXES sensor وإعداد تقارير عنه.
[7.3.1/A-1-4] يجب تنفيذ جهاز استشعار TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED والإبلاغ عنه.

إذا كانت عمليات تنفيذ أجهزة Automotive تتضمّن جيروسكوبًا، يجب أن:

‫[7.3.4/A-2-1] يجب أن يكون الجهاز قادرًا على تسجيل الأحداث بتردد لا يقل عن 100 هرتز.
[7.3.4/A-2-3] يجب أن يكون الجهاز قادرًا على قياس التغييرات في الاتجاه بمعدّل يصل إلى 250 درجة في الثانية.
[7.3.4/A-SR-1] يُنصح بشدة بضبط نطاق قياس الجيروسكوب على +/-250 dps لتحقيق أعلى درجة دقة ممكنة.

إذا كانت عمليات تنفيذ أجهزة Automotive تتضمّن جيروسكوبًا ثلاثي المحاور، يجب أن تستوفي ما يلي:

‫[7.3.4/A-SR-2] يُنصح بشدة بتنفيذ المستشعر المركّب لجيروسكوب محدود المحاور.

إذا كانت عمليات تنفيذ أجهزة Automotive تتضمّن جيروسكوبًا بأقل من 3 محاور، يجب أن:

[7.3.4/A-4-1] يجب تنفيذ جِهَازُ اسْتِشْعَارْ TYPE_GYROSCOPE_LIMITED_AXES وإعداد تقرير عنه.
[7.3.4/A-4-2] يجب تنفيذ جِهَازُ اسْتِشْعَارْ TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED والإبلاغ عنه.

إذا كانت عمليات تنفيذ أجهزة Automotive تتضمّن جهاز استقبال GPS/GNSS، ولكنها لا تتضمّن إمكانية الاتصال بالبيانات المستندة إلى شبكة الجوّال، فإنّها:

‫[7.3.3/A-3-1] يجب تحديد الموقع الجغرافي في المرة الأولى التي يتم فيها تشغيل جهاز استقبال نظام تحديد المواقع العالمي (GPS) أو نظام GNSS أو بعد 4 أيام أو أكثر في غضون 60 ثانية.
[7.3.3/A-3-2] يجب استيفاء معايير وقت الإصلاح الأول كما هو موضح في 7.3.3/C-1-2 و7.3.3/C-1-6 لجميع طلبات تحديد الموقع الجغرافي الأخرى (أي الطلبات التي لا يتم إرسالها للمرة الأولى على الإطلاق أو بعد 4 أيام أو أكثر). يتم عادةً استيفاء المتطلبات 7.3.3/C-1-2 في المركبات التي لا تتوفّر فيها إمكانية الاتصال بالبيانات المستندة إلى شبكة الجوّال، وذلك باستخدام توقّعات مدارية لنظام GNSS يتم احتسابها على جهاز الاستقبال، أو باستخدام آخر موقع جغرافي معروف للمركبة مع إمكانية التقدير التقريبي للمسافة المقطوعة لمدة 60 ثانية على الأقل بدقة موضع تستوفي 7.3.3/C-1-3، أو باستخدام مزيج من كليهما.

إذا كانت عمليات تنفيذ أجهزة السيارات تتضمّن مستشعر TYPE_HEADING، فإنّها:

[7.3.4/A-4-3] يجب أن يكون الجهاز قادرًا على تسجيل الأحداث بتردد لا يقل عن 1 هرتز.
[7.3.4/A-SR-3] يُنصَح بشدة بتسجيل الأحداث بمعدّل تكرار يبلغ 10 هرتز على الأقل.
يجب أن يكون ذلك بالنسبة إلى الشمال الحقيقي.
يجب أن يكون هذا الإجراء متاحًا حتى عندما تكون المركبة متوقفة.
يجب أن تكون درجة الدقة درجة واحدة على الأقل.

عمليات تنفيذ أجهزة السيارات:

[7.4.3/A-0-1] يجب أن يتوافق الجهاز مع البلوتوث، ويُفضّل أن يتوافق مع البلوتوث منخفض الطاقة.
[7.4.3/A-0-2] يجب أن تتوافق عمليات تنفيذ Android Automotive مع ملفات تعريف البلوتوث التالية:
- إجراء المكالمات الهاتفية عبر ملف "بدون لمس الجهاز" (HFP)
- تشغيل الوسائط عبر نمط توزيع الصوت المتقدّم (A2 DP)
- التحكّم في تشغيل الوسائط من خلال نمط التحكم عن بُعد (AVRCP)
- مشاركة جهات الاتصال باستخدام ملف الوصول إلى دفتر العناوين (PBAP)
‫[7.4.3/A-SR-1] يُنصح بشدة بتوفير ملف الوصول إلى الرسائل (MAP) إذا كان الجهاز يضم منطقة السائق.

[7.4.3/A-1-1] يجب أن يكون الاختبار مستقلاً وألا يتداخل مع تجربة المستخدمين الآخرين في استخدام البلوتوث.

عمليات تنفيذ أجهزة السيارات:

[7.4.5/A] يجب أن تتضمّن إمكانية الاتصال بالبيانات عبر شبكة الجوّال.
[7.4.5/A] يمكن استخدام الثابت System API NetworkCapabilities#NET_CAPABILITY_OEM_PAID للشبكات التي يجب أن تكون متاحة لتطبيقات النظام.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة راديو AM/FM للبث وتوفير الوظيفة لأي تطبيق، يجب أن تستوفي ما يلي:

[7.4/A-1-1] يجب الإعلان عن إتاحة FEATURE_BROADCAST_RADIO.

الكاميرا الخلفية هي كاميرا موجّهة إلى الخارج ويمكن وضعها في أي مكان في المركبة، وتكون موجّهة إلى خارج مقصورة المركبة، أي أنّها تصوّر المشاهد على الجانب البعيد من هيكل المركبة، مثل كاميرا الرجوع إلى الخلف.

تشير الكاميرا الأمامية إلى كاميرا مواجهة للمستخدم يمكن وضعها في أي مكان في المركبة وتكون مواجهة لداخل مقصورة المركبة، أي أنها تلتقط صورًا للمستخدم، مثلاً لعقد مؤتمرات عبر الفيديو والتطبيقات المشابهة.

عمليات تنفيذ أجهزة السيارات:

‫[7.5/A-SR-1] يُنصح بشدة بتضمين كاميرا واحدة أو أكثر موجّهة إلى الخارج.
قد يتضمّن كاميرا واحدة أو أكثر موجّهة للمستخدم.
‫[7.5/A-SR-2] يُنصح بشدة بتوفير إمكانية البث المتزامن من عدة كاميرات.

إذا كانت عمليات تنفيذ أجهزة السيارات تتضمّن كاميرا واحدة على الأقل مواجهة للعالم الخارجي، يجب أن تستوفي هذه الكاميرا ما يلي:

‫[7.5/A-1-1] يجب أن يكون اتجاه الكاميرا بحيث يتوافق البُعد الأطول مع مستوى X-Y لمحاور أجهزة الاستشعار في Android Automotive.
‫[7.5/A-SR-3] يُنصح بشدة بأن تتضمّن أجهزة الواقع الافتراضي أو الواقع المعزّز تركيزًا ثابتًا أو أجهزة ذات عمق مجال ممتد (EDOF).
‫[7.5/A-1-2] يجب أن تكون الكاميرا الأساسية المواجهة للخارج هي الكاميرا المواجهة للخارج التي تحمل رقم تعريف الكاميرا الأدنى.

إذا كانت عمليات تنفيذ أجهزة السيارات تتضمّن كاميرا واحدة على الأقل مواجهة للمستخدم، يجب استيفاء ما يلي بالنسبة إلى هذه الكاميرا:

‫[7.5/A-2-1] يجب أن تكون الكاميرا الأساسية المواجهة للمستخدم هي الكاميرا المواجهة للمستخدم التي تحمل أصغر رقم تعريف.
يجب أن يكون اتجاهها بحيث يتوافق البُعد الأطول للكاميرا مع مستوى X-Y لمحاور أجهزة الاستشعار في Android Automotive.

إذا كانت عمليات تنفيذ أجهزة Automotive تتضمّن كاميرا يمكن الوصول إليها من خلال واجهة برمجة التطبيقات android.hardware.Camera أو android.hardware.camera2، يجب أن تستوفي ما يلي:

‫[7.5/A-3-1] يجب الالتزام بمتطلبات الكاميرا الأساسية الواردة في القسم 7.5.

إذا كانت عمليات تنفيذ أجهزة Automotive تتضمّن كاميرا لا يمكن الوصول إليها من خلال واجهة برمجة التطبيقات android.hardware.Camera أو android.hardware.camera2، يجب أن تستوفي ما يلي:

[7.5/A-4-1] يجب أن يكون المحتوى متاحًا من خلال خدمة تابعة لنظام التشغيل "نظام العرض الموسّع".

إذا كانت عمليات تنفيذ أجهزة Automotive تتضمّن كاميرا واحدة أو أكثر يمكن الوصول إليها من خلال خدمة "نظام العرض الموسّع"، يجب أن تستوفي هذه الكاميرا ما يلي:

‫[7.5/A-5-1] يجب عدم تدوير معاينة الكاميرا أو عكسها أفقيًا.
‫[7.5/A-SR-4] يُنصَح بشدة أن تكون درجة الدقة 1.3 ميغابكسل على الأقل.

إذا كانت عمليات تنفيذ أجهزة السيارات تتضمّن كاميرا واحدة أو أكثر يمكن الوصول إليها من خلال كل من خدمة "نظام العرض الموسّع" وواجهة برمجة التطبيقات android.hardware.Camera أو android.hardware.Camera2، يجب أن تستوفي هذه الكاميرا ما يلي:

‫[7.5/A-6-1] يجب عرض معرّف الكاميرا نفسه.

إذا كانت عمليات تنفيذ أجهزة Automotive توفّر واجهة برمجة تطبيقات خاصة بالكاميرا، يجب أن تستوفي ما يلي:

‫[7.5/A-7-1] يجب تنفيذ واجهة برمجة تطبيقات الكاميرا هذه باستخدام android.hardware.camera2 API أو Extended View System API.

عمليات تنفيذ أجهزة السيارات:

‫[7.6.1/A-0-1] يجب أن تتوفّر مساحة تخزين غير متطايرة لا تقلّ عن 4 غيغابايت لبيانات التطبيق الخاصة (قسم /data).
‫[7.6.1/A] يجب تنسيق قسم البيانات لتحسين الأداء وإطالة عمر التخزين المؤقت (على سبيل المثال، باستخدام نظام الملفات f2fs).

إذا كانت عمليات تنفيذ أجهزة Automotive توفّر مساحة تخزين خارجية مشتركة من خلال جزء من مساحة التخزين الداخلية غير القابلة للإزالة، يجب أن تستوفي ما يلي:

[7.6.1/A-SR-1] يُنصح بشدة بتقليل الحمل الزائد الناتج عن عمليات الإدخال/الإخراج في عمليات التخزين الخارجي، مثلاً باستخدام SDCardFS.

[7.6.1/A-1-1] يجب أن تتضمّن كل نسخة من نظام التشغيل Android Automotive OS (AAOS) ذاكرة بسعة 4 غيغابايت على الأقل لكل مستخدم Android متزامن، وذلك من مساحة التخزين غير المتطايرة المتاحة لبيانات التطبيقات الخاصة (قسم /data).

إذا كانت عمليات تنفيذ أجهزة Automotive تعمل بنظام 64 بت:

[7.6.1/A-2-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 816 ميغابايت على الأقل لكل شاشة عرض رئيسية في حال استخدام أي من الكثافات التالية:
- ‫280 نقطة لكل بوصة أو أقل على الشاشات الصغيرة/العادية
- ldpi أو أقل على الشاشات الكبيرة جدًا
- mdpi أو أقل على الشاشات الكبيرة
‫[7.6.1/A-2-2] يجب أن تبلغ سعة الذاكرة المتاحة للنواة ومساحة المستخدم 944 ميغابايت على الأقل لكل شاشة عرض رئيسية في حال استخدام أي من الكثافات التالية:
- xhdpi أو أعلى على الشاشات الصغيرة/العادية
- hdpi أو أعلى على الشاشات الكبيرة
- mdpi أو أعلى على الشاشات الكبيرة جدًا
‫[7.6.1/A-2-3] يجب أن تبلغ سعة الذاكرة المتاحة للنواة ومساحة المستخدم 1280 ميغابايت على الأقل لكل شاشة عرض رئيسية في حال استخدام أي من الكثافات التالية:
- ‫400 نقطة في البوصة أو أكثر على الشاشات الصغيرة/العادية
- xhdpi أو أعلى على الشاشات الكبيرة
- tvddpi أو أعلى على الشاشات الكبيرة جدًا
‫[7.6.1/A-2-4] يجب أن تبلغ سعة الذاكرة المتاحة للنواة ومساحة المستخدم 1824 ميغابايت على الأقل لكل شاشة عرض رئيسية في حال استخدام أي من الكثافات التالية:
- ‫560 نقطة لكل بوصة أو أكثر على الشاشات الصغيرة/العادية
- ‫400 نقطة في البوصة أو أكثر على الشاشات الكبيرة
- xhdpi أو أعلى على الشاشات الكبيرة جدًا

عمليات تنفيذ أجهزة السيارات:

[7.7.1/A] يجب أن يتضمّن منفذ USB متوافقًا مع وضع الأجهزة الطرفية.

إذا كانت عمليات تنفيذ أجهزة Automotive تتضمّن منفذ USB مع وحدة تحكّم تعمل في وضع الجهاز الطرفي، يجب أن تستوفي ما يلي:

‫[7.7.1/A-1-1] يجب تنفيذ واجهة برمجة التطبيقات Android Open Accessory (AOA).

إذا كانت عمليات تنفيذ أجهزة Automotive تتضمّن منفذ USB يتيح وضع المضيف، يجب أن:

‫[7.7.2/A-1-1] يجب تنفيذ فئة الصوت عبر USB على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

عمليات تنفيذ أجهزة السيارات:

[7.8.1/A-0-1] يجب أن يتضمّن ميكروفونًا.

عمليات تنفيذ أجهزة السيارات:

‫[7.8.2/A-0-1] يجب أن يتضمّن الجهاز منفذ إخراج صوتي وأن يعرّف android.hardware.audio.output.

[7.8.2/A-1-1] يجب أن يتضمّن كل شاشة عرض رئيسية مصدر إخراج الصوت لأنظمة تعدُّد المستخدمين المتزامنة.
[7.8.2/A-1-2] يجب أن تتضمّن منطقة الصوت الخاصة بالسائق مكبّر الصوت العام في المقصورة. يمكن لمنطقة الراكب الأمامي مشاركة منطقة الصوت الخاصة بالسائق أو استخدام مصدر إخراج صوت خاص بها.

عند استدعاء واجهة برمجة التطبيقات AudioManager.getDevices() أثناء توصيل جهاز USB خارجي، سيحدث ما يلي:

[7.8.2.2/A-1-1] يجب إدراج جهاز من النوع AudioDeviceInfo.TYPE_USB_HEADSET والدور isSink() إذا كان حقل نوع طرفية الصوت عبر USB هو 0x0302.
[7.8.2.2/A-1-2] يجب إدراج جهاز من النوع AudioDeviceInfo.TYPE_USB_HEADSET والدور isSink() إذا كان حقل نوع طرفية الصوت عبر USB هو 0x0402.
[7.8.2.2/A-1-3] يجب إدراج جهاز من النوع AudioDeviceInfo.TYPE_USB_HEADSET والدور isSink() إذا كان حقل نوع طرفية الصوت عبر USB هو 0x0603.
[7.8.2.2/A-1-4] يجب إدراج جهاز من النوع AudioDeviceInfo.TYPE_USB_HEADSET والدور isSink() إذا كان حقل نوع طرفية الصوت عبر USB هو 0x0400.

‫2.5.2. وسائط متعددة

يجب أن تتوافق عمليات تنفيذ أجهزة السيارات مع صيغ ترميز الصوت وفك ترميزه التالية وأن توفّرها للتطبيقات التابعة لجهات خارجية:

‫[5.1/A-0-1] ملف تعريف MPEG-4 AAC (برنامج الترميز AAC LC)
‫[5.1/A-0-2] ملف تعريف MPEG-4 HE AAC (برنامج الترميز AAC+)
‫[5.1/A-0-3] AAC ELD (برنامج ترميز AAC المحسّن ذو التأخير المنخفض)

‫[5.1/A-0-4] MPEG-D USAC مع MPEG-D DRC (ترميز AAC عالي الكفاءة الموسّع)

يجب أن تتوافق عمليات تنفيذ أجهزة السيارات مع تنسيقات ترميز الفيديو التالية وأن توفّرها للتطبيقات التابعة لجهات خارجية:

‫[5.2/A-0-1] H.264 AVC
‫[5.2/A-0-2] VP8

يجب أن تتوافق عمليات تنفيذ أجهزة السيارات مع تنسيقات ترميز الفيديو التالية وأن تتيحها للتطبيقات التابعة لجهات خارجية:

‫[5.3/A-0-1] H.264 AVC
[5.3/A-0-2] MPEG-4 SP
[5.3/A-0-3] VP8
‫[5.3/A-0-4] VP9

يُنصح بشدة بأن تتوافق تطبيقات أجهزة السيارات مع فك ترميز الفيديو التالي:

‫[5.3/A-SR-1] H.265 HEVC

[5.5.3/A-1-1] يجب تحديد منحنيات مستوى صوت متطابقة لجميع مجموعات بث إخراج الصوت التي يتم ربطها بمجموعة مستوى الصوت نفسها على النحو المحدّد في ملف إعدادات نظام الصوت في السيارة.

‫2.5.3. برامج

عمليات تنفيذ أجهزة السيارات:

[3/A-0-1] يجب الإفصاح عن الميزة android.hardware.type.automotive.
[3/A-0-2] يجب أن تتوافق مع uiMode = UI_MODE_TYPE_CAR.
[3/A-0-3] يجب أن تتوافق مع جميع واجهات برمجة التطبيقات المتاحة للجميع في مساحة الاسم android.car.*.

إذا كانت عمليات تنفيذ أجهزة Automotive توفّر واجهة برمجة تطبيقات خاصة باستخدام android.car.CarPropertyManager مع android.car.VehiclePropertyIds، يجب أن تستوفي ما يلي:

[3/A-1-1] يجب عدم منح امتيازات خاصة لتطبيقات النظام عند استخدام هذه الخصائص، أو منع التطبيقات التابعة لجهات خارجية من استخدام هذه الخصائص.
[3/A-1-2] يجب عدم تكرار إحدى سمات المركبة المتوفّرة في حزمة تطوير البرامج (SDK).

عمليات تنفيذ أجهزة السيارات:

[3.2.1/A-0-1] يجب أن تتوافق مع جميع ثوابت الأذونات وأن تفرضها على النحو الموضّح في صفحة مرجع أذونات السيارات.
[3.2.3.1/A-0-1] يجب التحميل مسبقًا لتطبيق واحد أو أكثر أو لمكوّنات خدمة تتضمّن معالج intent، وذلك لجميع أنماط intent filter العامة المحدّدة من خلال intents التطبيقات التالية المدرَجة هنا.
[3.2.3.1/A-0-2] يجب أن يتضمّن الجهاز تطبيقًا يتعامل مع أغراض ACTION_GET_CONTENT وACTION_OPEN_DOCUMENT وACTION_OPEN_DOCUMENT_TREE وACTION_CREATE_DOCUMENT كما هو موضّح في مستندات حزمة SDK، وأن يوفّر للمستخدم إمكانية الوصول إلى بيانات موفّر المستندات باستخدام واجهة برمجة التطبيقات DocumentsProvider.

إذا كان تطبيق إعدادات تنفيذ أجهزة السيارات يوفّر وظيفة مقسّمة، باستخدام ميزة تضمين الأنشطة، فإنّه:

[3.2.3.1/A-1-1] يجب أن يتضمّن التطبيق نشاطًا يعالج الغرض Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY عند تفعيل وظيفة التقسيم. يجب أن يكون النشاط محميًا بواسطة android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK، ويجب أن يبدأ نشاط Intent الذي تم تحليله من Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.
‫[3.4.1/A-0-1] يجب توفير تنفيذ كامل لواجهة برمجة التطبيقات android.webkit.Webview.

[3.8/A-1-1] يجب تنفيذ قائمة UserRestrictions المحدّدة مسبقًا التالية للمستخدمين الثانويين الكاملين الذين ليسوا المستخدمين الحاليين في المقدّمة، ولكن لديهم إذن الوصول إلى واجهة المستخدم على الشاشة المخصّصة لهم. قائمة UserRestrictions هي DISALLOW_CONFIG_LOCALE وDISALLOW_CONFIG_BLUETOOTH وDISALLOW_BLUETOOTH وDISALLOW_CAMERA_TOGGLE وDISALLOW_MICROPHONE_TOGGLE.
[3.8/A-1-2] يجب عدم السماح للمستخدمين الثانويين الكاملين الذين ليسوا المستخدمين الحاليين في المقدّمة ولكن لديهم إذن الوصول إلى واجهة المستخدم على الشاشة المخصّصة لهم بتغيير وضع النهار/الليل أو اللغة أو التاريخ أو الوقت أو المنطقة الزمنية أو ميزات ألوان الشاشة (بما في ذلك "السطوع" و"الإضاءة الليلية" و"الرفاهية الرقمية" بالأبيض والأسود و"تقليل الألوان الساطعة") لأي مستخدم آخر من خلال "الإعدادات" أو من خلال واجهة برمجة تطبيقات.

عمليات تنفيذ أجهزة السيارات:

‫[3.8.3/A-0-1] يجب عرض الإشعارات التي تستخدم واجهة برمجة التطبيقات Notification.CarExtender عند طلبها من قِبل تطبيقات تابعة لجهات خارجية.
[3.8.4/A-SR-1] يُنصح بشدة بتنفيذ مساعد على الجهاز للتعامل مع إجراء المساعدة.

إذا كانت عمليات تنفيذ أجهزة Automotive تتضمّن زر الضغط والتحدّث، يجب أن تستوفي الشروط التالية:

[3.8.4/A-1-1] يجب استخدام ضغطة قصيرة على زر الضغط والتحدّث كإجراء تفاعلي مخصّص لتشغيل تطبيق المساعدة الذي يختاره المستخدم، أي التطبيق الذي ينفّذ VoiceInteractionService.

عمليات تنفيذ أجهزة السيارات:

[3.8.3.1/A-0-1] يجب أن تعرض حزمة تطوير البرامج (SDK) الموارد بشكل صحيح على النحو الموضّح في مستندات Notifications on Automotive OS.
[3.8.3.1/A-0-2] يجب عرض PLAY وMUTE لإجراءات الإشعارات بدلاً من تلك المقدَّمة من خلال Notification.Builder.addAction()
[3.8.3.1/A] يجب أن تقيّد استخدام مهام الإدارة المتقدّمة، مثل عناصر التحكّم في كل قناة إشعارات. يمكن استخدام إمكانية الوصول إلى واجهة المستخدم لكل تطبيق لتقليل عناصر التحكّم.

إذا كانت عمليات تنفيذ أجهزة Automotive تتوافق مع خصائص User HAL، يجب أن تستوفي ما يلي:

[3.9.3/A-1-1] يجب تنفيذ جميع سمات مراحل نشاط المستخدم: INITIAL_USER_INFO وSWITCH_USER وCREATE_USER وREMOVE_USER.

عمليات تنفيذ أجهزة السيارات:

[3.14/A-0-1] يجب أن يتضمّن الجهاز إطار عمل لواجهة المستخدم يتيح للتطبيقات التابعة لجهات خارجية استخدام واجهات برمجة التطبيقات الخاصة بالوسائط على النحو الموضّح في القسم 3.14.
[3.14/A-0-2] يجب أن تسمح للمستخدم بالتفاعل بأمان مع تطبيقات الوسائط أثناء القيادة.
[3.14/A-0-3] يجب أن يتيح التطبيق إجراء CAR_INTENT_ACTION_MEDIA_TEMPLATE النية الضمنية مع CAR_EXTRA_MEDIA_PACKAGE الإضافي.
[3.14/A-0-4] يجب توفير تلميحات مرئية للانتقال إلى نشاط الإعدادات المفضّلة في تطبيق وسائط، ولكن يجب تفعيله فقط عندما لا تكون "قيود تجربة المستخدم في السيارة" سارية.
[3.14/A-0-5] يجب عرض رسائل الخطأ التي تحدّدها تطبيقات الوسائط، ويجب أن تتوافق مع الإضافات الاختيارية ERROR_RESOLUTION_ACTION_LABEL وERROR_RESOLUTION_ACTION_INTENT.
[3.14/A-0-6] يجب أن تتضمّن التطبيقات التي تتيح البحث ميزة البحث داخل التطبيق.
[3.14/A-0-7] يجب الالتزام بتعريفات CONTENT_STYLE_BROWSABLE_HINT وCONTENT_STYLE_PLAYABLE_HINT عند عرض التسلسل الهرمي MediaBrowser.

عمليات تنفيذ أجهزة السيارات:

[3.14/A-0-8] يجب الإعلان عن علامة الميزة android.software.car.templates_host.
[3.14/A-0-9] يجب الإعلان عن علامة الميزة com.android.car.background_audio_while_driving.
[3.14/A-0-10] يجب الإعلان عن علامة الميزة android.software.car.templates_host.media.

إذا كانت عمليات تنفيذ أجهزة Automotive تتضمّن تطبيق مشغّل تطبيقات تلقائيًا، يجب أن تستوفي ما يلي:

[3.14/A-1-1] يجب أن يتضمّن خدمات الوسائط وأن يفتحها باستخدام الغرض CAR_INTENT_ACTION_MEDIA_TEMPLATE.

عمليات تنفيذ أجهزة السيارات:

[3.8/A] يجوز تقييد طلبات التطبيق بالانتقال إلى وضع ملء الشاشة على النحو الموضّح في immersive documentation.
[3.8/A] يجوز إبقاء شريط الحالة وشريط التنقّل مرئيين في جميع الأوقات.
[3.8/A] يجوز أن تقيّد التطبيق من طلب تغيير الألوان خلف عناصر واجهة مستخدم النظام، وذلك لضمان أن تكون هذه العناصر مرئية بوضوح في جميع الأوقات.

عمليات تنفيذ أجهزة السيارات:

‫[7.1.1/A-0-1] يجب الإعلان عن علامة الميزة android.software.car.display_compatibility.

أثناء تشغيل التطبيقات في المقدّمة باستخدام ميزة android.software.car.display_compatibility أو التطبيقات بدون ميزة android.hardware.type.automotive، يجب استيفاء ما يلي في أجهزة السيارات:

‫[7.1.1/A-1-1] يجب توفير وظيفة "الرجوع".

إذا كانت عمليات تنفيذ أجهزة Automotive تسمح للمستخدمين بإجراء مكالمات من أي نوع، يجب أن تستوفي ما يلي:

[7.4.1.2/A-1-1] يجب الإعلان عن مفتاح تبديل أوضاع الميزات android.software.telecom.

[7.4.1.2/A-1-2] يجب تنفيذ إطار عمل الاتصالات.

‫2.5.4. الأداء والطاقة

[8.1/A-0-1] وقت استجابة ثابت للإطار: يجب ألا يحدث تأخير في عرض اللقطات أو عدم اتساق في وقت استجابة اللقطات أكثر من 5 مرات في الثانية، ويجب أن يكون أقل من مرة واحدة في الثانية.
[8.1/A-0-2] زمن استجابة واجهة المستخدم: يجب أن تضمن عمليات تنفيذ الأجهزة تجربة مستخدم ذات وقت استجابة منخفض من خلال تمرير قائمة تضم 10,000 إدخال على القائمة على النحو المحدّد في مجموعة اختبار التوافق (CTS) لنظام Android في أقل من 36 ثانية.
‫[8.1/A-0-3] تبديل المهام عند تشغيل عدة تطبيقات، يجب أن تستغرق إعادة تشغيل تطبيق سبق تشغيله أقل من ثانية واحدة.

عمليات تنفيذ أجهزة السيارات:

[8.2/A-0-1] يجب تسجيل عدد وحدات البايت التي تمت قراءتها وكتابتها في وحدة التخزين غير المتطايرة لكل معرّف مستخدم (UID) خاص بكل عملية، وذلك حتى تكون الإحصاءات متاحة للمطوّرين من خلال واجهة برمجة التطبيقات للنظام android.car.storagemonitoring.CarStorageMonitoringManager. يستوفي "مشروع مفتوح المصدر لنظام Android" هذا الشرط من خلال وحدة النواة uid_sys_stats.
[8.2/A-0-2] يجب ضمان أداء كتابة تسلسلي يبلغ 5 ميغابايت/ثانية على الأقل.
[8.2/A-0-3] يجب ضمان أداء كتابة عشوائية يبلغ 0.5 ميغابايت/ثانية على الأقل.
[8.2/A-0-4] يجب ضمان أداء قراءة تسلسلية لا يقل عن 15 ميغابايت/ثانية.
[8.2/A-0-5] يجب ضمان أداء قراءة عشوائية لا يقل عن 3.5 ميغابايت/ثانية.

إذا كانت عمليات تنفيذ أجهزة Automotive تعرض قيمة android.os.Build.VERSION_CODES.U أو أكبر بالنسبة إلى android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS، فإنّها:

[8.2/A-1-1] يجب ضمان أداء كتابة تسلسلي يبلغ 150 ميغابايت في الثانية على الأقل.
[8.2/A-1-2] يجب ضمان أداء كتابة عشوائية لا يقل عن 10 ميغابايت/ثانية.
[8.2/A-1-3] يجب ضمان أداء قراءة تسلسلي يبلغ 250 ميغابايت في الثانية على الأقل.
[8.2/A-1-4] يجب ضمان أداء قراءة عشوائية لا يقل عن 100 ميغابايت في الثانية.
[8.2/A-1-5] يجب ضمان أداء متوازٍ ومتسلسل للقراءة والكتابة مع أداء قراءة بمقدار ضعفَي أداء الكتابة وبمعدّل 50 ميغابايت في الثانية على الأقل.
[8.3/A-1-3] يجب أن يتوافق مع وضع المرآب.
[8.3/A] يجب أن يكون الجهاز في "وضع المرآب" لمدة 15 دقيقة على الأقل بعد كل رحلة ما لم:
- تم استنزاف شحن البطارية.
- لا تتم جدولة أي مهام غير نشطة.
- يخرج السائق من "وضع المرآب".
[8.4/A-0-1] يجب توفير ملف تعريف طاقة لكل مكوّن يحدّد قيمة استهلاك التيار لكل مكوّن من مكوّنات الجهاز ومعدّل استنزاف البطارية التقريبي الذي تسبّبه المكوّنات بمرور الوقت كما هو موضّح في موقع "مشروع مفتوح المصدر لنظام Android".
[8.4/A-0-2] يجب عرض جميع قيم استهلاك الطاقة بوحدة ميلي أمبير في الساعة (mAh).
[8.4/A-0-3] يجب أن يتم تسجيل استهلاك طاقة وحدة المعالجة المركزية (CPU) لكل معرّف UID خاص بكل عملية. يستوفي "مشروع Android المفتوح المصدر" هذا الشرط من خلال تنفيذ وحدة النواة uid_cputime.
[8.4/A] يجب أن يتم تحديد مصدر استهلاك الطاقة على أنّه مكوّن الجهاز نفسه إذا تعذّر تحديد مصدر استهلاك الطاقة على أنّه تطبيق.
‫[8.4/A-0-4] يجب إتاحة معلومات استهلاك الطاقة هذه لمطوّر التطبيق من خلال أمر adb shell dumpsys batterystats في واجهة سطر الأوامر.

‫2.5.5. نموذج الأمان

إذا كانت عمليات تنفيذ أجهزة Automotive تتيح استخدام عدة مستخدمين، يجب أن تستوفي ما يلي:

‫[9.5/A-1-1] يجب عدم السماح للمستخدمين بالتفاعل مع مستخدم النظام بدون واجهة مستخدم أو التبديل إليه، باستثناء توفير الجهاز.
[9.5/A-1-2] يجب التبديل إلى مستخدم ثانوي قبل BOOT_COMPLETED.
‫[9.5/A-1-3] يجب أن يتيح إنشاء مستخدم ضيف حتى عند بلوغ الحد الأقصى لعدد المستخدمين على الجهاز.

إذا كانت عمليات تنفيذ أجهزة Automotive تتوافق مع System API VisualQueryDetectionService أو آلية أخرى لرصد طلبات البحث بدون إشارة إلى الوصول إلى الميكروفون و/أو الكاميرا، فإنّها:

[9.8/A-1-1] يجب التأكّد من أنّ خدمة رصد الطلبات يمكنها نقل البيانات إلى النظام أو ContentCaptureService أو خدمة التعرّف على الكلام على الجهاز (التي أنشأتها SpeechRecognizer#createOnDeviceSpeechRecognizer()) فقط.
[9.8/A-1-2] يجب ألا يسمح بنقل أي معلومات صوتية أو معلومات فيديو إلى خارج VisualQueryDetectionService، باستثناء نقلها إلى ContentCaptureService أو خدمة التعرّف على الكلام على الجهاز فقط.
‫[9.8/A-1-3] يجب عرض إشعار للمستخدم في واجهة مستخدم النظام عندما يرصد الجهاز نية المستخدم في التفاعل مع تطبيق "المساعد الرقمي" (مثل رصد وجود المستخدم من خلال الكاميرا).
[9.8/A-1-4] يجب عرض مؤشر للميكروفون وعرض طلب البحث الذي تم رصده في واجهة المستخدم فور رصد طلب البحث.
[9.8/A-1-5] يجب ألا يسمح بتوفير خدمة رصد طلبات البحث المرئية من خلال تطبيق يمكن للمستخدم تثبيته.

إذا كانت عمليات تنفيذ أجهزة Automotive تعرّف android.hardware.microphone، عليها استيفاء ما يلي:

[9.8.2/A-1-1] يجب عرض مؤشر الميكروفون عندما يصل تطبيق إلى بيانات الصوت من الميكروفون، ولكن ليس عندما يصل إلى الميكروفون فقط HotwordDetectionService أو SOURCE_HOTWORD أو ContentCaptureService أو التطبيقات التي لديها الأدوار المحدّدة في الفقرة 9.1 مع معرّف CDD [C-4-X].
[9.8.2/A-1-2] يجب عدم إخفاء مؤشر الميكروفون لتطبيقات النظام التي تتضمّن واجهات مستخدم مرئية أو تتطلّب تفاعلاً مباشرًا من المستخدم.
[9.8.2/A-1-3] يجب توفير عنصر تحكّم للمستخدم لتفعيل الميكروفون أو إيقافه في تطبيق "الإعدادات".

إذا كانت عمليات تنفيذ أجهزة Automotive تعرّف android.hardware.camera.any، عليها استيفاء ما يلي:

[9.8.2/A-2-1] يجب عرض مؤشر الكاميرا عندما يصل تطبيق إلى بيانات الكاميرا المباشرة، ولكن ليس عندما تصل التطبيقات التي لديها الأدوار المحدّدة في القسم 9.1 "الأذونات" إلى الكاميرا فقط، مع معرّف مستند تعريف الجهاز [C-4-X].
[9.8.2/A-2-2] يجب عدم إخفاء مؤشر الكاميرا لتطبيقات النظام التي تتضمّن واجهات مستخدم مرئية أو تفاعلاً مباشرًا مع المستخدم.
[‫9.8.2/A-2-3] يجب توفير عنصر تحكّم للمستخدم لتفعيل الكاميرا أو إيقافها في تطبيق "الإعدادات".
[9.8.2/A-2-4] يجب عرض التطبيقات الحديثة والنشطة التي تستخدم الكاميرا كما هو موضح في PermissionManager.getIndicatorAppOpUsageData()، بالإضافة إلى أي رسائل تحديد مصدر مرتبطة بها.

عمليات تنفيذ أجهزة السيارات:

[9/A-0-1] يجب الإفصاح عن ميزة android.hardware.security.model.compatible.
[9.11/A-0-1] يجب أن يتم الاحتفاظ بنسخة احتياطية من تنفيذ مخزن المفاتيح في بيئة تنفيذ معزولة.
[9.11/A-0-2] يجب أن تتضمّن عمليات تنفيذ لخوارزميات التشفير RSA وAES وECDSA وHMAC، ودوال التجزئة MD5 وSHA-1 وSHA-2، وذلك لتوفير الدعم المناسب للخوارزميات المتوافقة مع نظام Android Keystore في منطقة معزولة بشكل آمن عن الرمز البرمجي الذي يتم تنفيذه على النواة وما فوقها. يجب أن يحظر العزل الآمن جميع الآليات المحتملة التي قد يصل من خلالها رمز kernel أو رمز مساحة المستخدم إلى الحالة الداخلية للبيئة المعزولة، بما في ذلك الوصول المباشر إلى الذاكرة (DMA). يستوفي "المشروع المفتوح المصدر لنظام Android" ‏ (AOSP) هذا الشرط باستخدام تنفيذ Trusty، ولكن يمكن أيضًا استخدام حل آخر يستند إلى ARM TrustZone أو تنفيذ آمن تمت مراجعته من جهة خارجية ويستند إلى برنامج مراقبة الأجهزة الافتراضية.
[9.11/A-0-3] يجب إجراء مصادقة شاشة القفل في بيئة التنفيذ المعزولة، ولا يُسمح باستخدام المفاتيح المرتبطة بالمصادقة إلا عند نجاحها. يجب تخزين بيانات اعتماد شاشة القفل بطريقة لا تسمح إلا لبيئة التنفيذ المعزولة بإجراء مصادقة شاشة القفل. يوفّر مشروع Android مفتوح المصدر الأساسي طبقة تجريد الأجهزة (HAL) في Gatekeeper وTrusty، ويمكن استخدامهما لاستيفاء هذا الشرط.
‫[9.11/A-0-4] يجب أن يتيح التصديق على المفتاح حيث يكون مفتاح التوقيع الخاص بالتصديق محميًا بواسطة أجهزة آمنة ويتم التوقيع في أجهزة آمنة. يجب منع استخدام مفاتيح توقيع شهادة التصديق كمعرّفات دائمة للأجهزة.

ملاحظة: لاستيفاء هذا الشرط، يجب مشاركة مفتاح التصديق نفسه لرمز تخزين تعريفي معيّن ما لم يتم إنتاج 100,000 وحدة على الأقل من رمز التخزين التعريفي هذا. إذا تم إنتاج أكثر من 100,000 وحدة من رمز التخزين التعريفي هذا، يمكن استخدام مفتاح مختلف لكل مجموعة من 100,000 وحدة بعد ذلك. بدلاً من ذلك، يمكن استخدام حلّ Remote Key Provisioning لتوفير مفاتيح تصديق قصيرة الأمد للجهاز.

عمليات تنفيذ أجهزة السيارات:

[9.14/A-0-1] يجب حظر الرسائل الواردة من الأنظمة الفرعية للمركبة في إطار عمل Android (مثل السماح فقط بأنواع الرسائل ومصادر الرسائل المسموح بها).
[9.14/A-0-2] يجب أن يوفّر نظام المراقبة الحماية من هجمات حجب الخدمة التي تنفّذها إطارات عمل Android أو التطبيقات التابعة لجهات خارجية. ويحمي ذلك من إغراق شبكة المركبة ببرامج ضارة تتسبب في حدوث خلل في الأنظمة الفرعية للمركبة.

‫2.5.6. التوافق مع أدوات وخيارات المطوّرين

عمليات تنفيذ أجهزة السيارات:

Perfetto
- [6.1/A-0-1] يجب توفير /system/bin/perfetto ملف ثنائي لمستخدم shell يتوافق سطر الأوامر الخاص به مع مستندات perfetto.
- [6.1/A-0-2] يجب أن يقبل ملف perfetto الثنائي كمدخل إعدادات protobuf تتوافق مع المخطط المحدّد في مستندات perfetto.
- [6.1/A-0-3] يجب أن يكتب ملف perfetto الثنائي كناتج عملية تتبُّع protobuf يتوافق مع المخطط المحدّد في مستندات perfetto.
- [6.1/A-0-4] يجب توفير مصادر البيانات الموضّحة في مستندات perfetto على الأقل، وذلك من خلال ملف perfetto الثنائي.
- [6.1/A-0-5] يجب تفعيل البرنامج الخفي الذي يتتبّع الأخطاء في Perfecto تلقائيًا (خاصية النظام persist.traced.enable).

‫2.6. متطلبات الجهاز اللوحي

يشير الجهاز اللوحي الذي يعمل بنظام التشغيل Android إلى تنفيذ جهاز Android يستوفي عادةً جميع المعايير التالية:

يتم استخدامه عن طريق الإمساك به بكلتا اليدين.
لا يتضمّن تصميمًا صدفيًا أو قابلاً للتحويل.
يتم توصيل لوحات المفاتيح الخارجية المستخدمة مع الجهاز من خلال اتصال عادي (مثل USB أو بلوتوث).
أن يكون مزوّدًا بمصدر طاقة يتيح التنقّل، مثل البطارية
أن يكون حجم شاشة العرض أكبر من 7 بوصات وأقل من 18 بوصة، ويتم قياسه قطريًا.

تتضمّن عمليات تنفيذ الأجهزة اللوحية متطلبات مشابهة لعمليات تنفيذ الأجهزة المحمولة. يتم الإشارة إلى الاستثناءات بعلامة النجمة (*) في القسم المعنيّ ويتم إدراجها كمرجع في هذا القسم.

2.6.1. الأجهزة

الجيروسكوب

إذا كانت عمليات تنفيذ الأجهزة اللوحية تتضمّن جيروسكوبًا ثلاثي المحاور، يجب أن:

[7.3.4/Tab-1-1] يجب أن يكون الجهاز قادرًا على قياس التغييرات في الاتجاه بمعدّل يصل إلى 1,000 درجة في الثانية.

الحد الأدنى من الذاكرة ومساحة التخزين (الفقرة 7.6.1)

إنّ كثافات الشاشة المُدرَجة للشاشات الصغيرة/العادية في متطلبات الأجهزة المحمولة لا تنطبق على الأجهزة اللوحية.

وضع الواقع الافتراضي (الفقرة 7.9.1)

الأداء العالي للواقع الافتراضي (الفقرة 7.9.2)

لا تنطبق متطلبات الواقع الافتراضي على الأجهزة اللوحية.

‫2.6.2. نموذج الأمان

المفاتيح وبيانات الاعتماد (الفقرة 9.11)

يُرجى الرجوع إلى القسم [9.11].

إذا كانت عمليات تنفيذ الجهاز اللوحي تتضمّن عدة مستخدمين ولا تحدّد علامة الميزة android.hardware.telephony، فإنّها:

[9.5/T-1-1] يجب أن تتوافق الأجهزة مع الملفات الشخصية المحظورة، وهي ميزة تتيح لمالكي الأجهزة إدارة مستخدمين إضافيين وإمكاناتهم على الجهاز. باستخدام الملفات الشخصية المقيّدة، يمكن لمالكي الأجهزة إعداد بيئات منفصلة بسرعة ليستخدمها مستخدمون آخرون، مع إمكانية إدارة قيود أكثر تفصيلاً في التطبيقات المتوفّرة في تلك البيئات.

إذا كانت عمليات تنفيذ الأجهزة اللوحية تتضمّن مستخدمين متعدّدين وتحدّد علامة الميزة android.hardware.telephony، عليها استيفاء ما يلي:

[‫9.5/T-2-1] يجب ألا يتيح استخدام الملفات الشخصية المحظورة، ولكن يجب أن يتوافق مع تنفيذ AOSP لعناصر التحكّم التي تتيح للمستخدمين الآخرين الوصول إلى المكالمات الصوتية والرسائل القصيرة أو حظرها.

‫2.6.2. برامج

[3.2.3.1/Tab-0-1] يجب التحميل المُسبَق لتطبيق واحد أو أكثر أو لمكوّنات خدمة تتضمّن معالج أهداف، وذلك لجميع أنماط فلاتر الأهداف العامة المحدّدة من خلال أهداف التطبيقات التالية المدرَجة هنا.

3- برامج

‫3.1. توافق واجهة برمجة التطبيقات المُدارة

بيئة تنفيذ رمز بايت Dalvik المُدارة هي الوسيلة الأساسية لتشغيل تطبيقات Android. واجهة برمجة التطبيقات (API) لنظام التشغيل Android هي مجموعة من واجهات نظام Android الأساسي المتاحة للتطبيقات التي تعمل في بيئة وقت التشغيل المُدارة.

عمليات تنفيذ الجهاز:

[C-0-1] يجب توفير عمليات تنفيذ كاملة، بما في ذلك جميع السلوكيات الموثّقة، لأي واجهة برمجة تطبيقات موثّقة يتم عرضها من خلال حزمة تطوير البرامج (SDK) لنظام التشغيل Android أو أي واجهة برمجة تطبيقات مزيّنة بعلامة "‎@SystemApi" في رمز المصدر العلوي لنظام التشغيل Android.
[C-0-2] يجب أن تتوافق/تحتفظ بجميع الفئات والطرق والعناصر المرتبطة بها التي تم وضع علامة عليها باستخدام التعليق التوضيحي TestApi (@TestApi).
[C-0-3] يجب عدم حذف أي واجهات برمجة تطبيقات مُدارة أو تغيير واجهات برمجة التطبيقات أو توقيعاتها أو الانحراف عن السلوك الموثّق أو تضمين عمليات غير فعّالة، إلا في الحالات التي يسمح بها تعريف التوافق هذا على وجه التحديد.
[C-0-4] يجب أن تظل واجهات برمجة التطبيقات متوفرة وتعمل بشكل معقول، حتى عند حذف بعض ميزات الأجهزة التي يتضمّن Android واجهات برمجة تطبيقات لها. راجِع الفقرة 7 لمعرفة المتطلبات المحدّدة لهذا السيناريو.
[C-0-5] يجب ألا تسمح التطبيقات التابعة لجهات خارجية باستخدام واجهات غير متوفرة في حزمة SDK، ويُقصد بها الطرق والحقول في حِزم لغة Java التي تقع في مسار فئة التمهيد في مشروع Android مفتوح المصدر (AOSP)، والتي لا تشكّل جزءًا من حزمة SDK العامة. ويشمل ذلك واجهات برمجة التطبيقات التي تم تزيينها بالتعليق التوضيحي @hide ولكن ليس بالتعليق التوضيحي @SystemAPI، كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) وأعضاء الفئات الخاصة والمحدودة بنطاق الحزمة.
[C-0-6] يجب أن يتم شحنها مع كل واجهة غير تابعة لحزمة تطوير البرامج (SDK) في قوائم الحظر نفسها التي يتم توفيرها من خلال علامات القائمة المؤقتة وقائمة الحظر في مسار prebuilts/runtime/appcompat/hiddenapi-flags.csv لمستوى واجهة برمجة التطبيقات المناسب في مشروع AOSP.
[C-0-7] يجب أن تتوافق مع آلية التعديل الديناميكي لإعدادات التوقيع لإزالة الواجهات غير المتوفّرة في حزمة SDK من قائمة محظورة من خلال تضمين إعدادات التوقيع في أي حزمة APK، باستخدام المفاتيح العامة الحالية المتوفّرة في مشروع Android مفتوح المصدر (AOSP).

ومع ذلك، فإنّ:
- يجب نقل واجهة برمجة التطبيقات المخفية إلى قائمة الرفض أو حذفها من جميع القوائم المحظورة، وذلك في حال عدم توفّر واجهة برمجة التطبيقات المخفية أو تنفيذها بشكل مختلف على الجهاز.
- يجب إضافة واجهة برمجة التطبيقات المخفية إلى أي من القوائم المحظورة، إذا لم تكن واجهة برمجة التطبيقات المخفية متوفرة في AOSP.

[C-0-8] يجب ألا يتيح تثبيت التطبيقات التي تستهدف مستوى واجهة برمجة تطبيقات أقل من 24 26.

3.1.1. إضافات Android

يتيح نظام التشغيل Android توسيع مساحة واجهة برمجة التطبيقات المُدارة لمستوى معيّن من واجهات برمجة التطبيقات من خلال تعديل إصدار الإضافة لهذا المستوى. تعرض واجهة برمجة التطبيقات android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) إصدار الإضافة من apiLevel المقدَّم، إذا كانت هناك إضافات لمستوى واجهة برمجة التطبيقات هذا.

عمليات تنفيذ أجهزة Android:

[C-0-1] يجب التحميل المُسبَق لتنفيذ AOSP لكل من المكتبة المشترَكة ExtShared والخدمات ExtServices بإصدارات أكبر من أو تساوي الحد الأدنى من الإصدارات المسموح بها لكل مستوى من مستويات واجهة برمجة التطبيقات. على سبيل المثال، يجب أن تتضمّن عمليات تنفيذ الأجهزة التي تعمل بالإصدار 7.0 من نظام التشغيل Android والمستوى 24 لواجهة برمجة التطبيقات الإصدار 1 على الأقل.
[C-0-2] يجب ألا تعرض إلا رقم إصدار صالح للامتداد تم تعريفه بواسطة مشروع AOSP.
[C-0-3] يجب أن تتوافق مع جميع واجهات برمجة التطبيقات المحدّدة في إصدارات الإضافة التي تعرضها android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) بالطريقة نفسها التي تتوافق بها مع واجهات برمجة التطبيقات المُدارة الأخرى، وذلك وفقًا للمتطلبات الواردة في الفقرة 3.1.

3.1.2. مكتبة Android

بسبب إيقاف Apache HTTP client نهائيًا، يجب أن تتضمّن عمليات التنفيذ على الأجهزة ما يلي:

[C-0-1] يجب عدم وضع مكتبة org.apache.http.legacy في مسار التمهيد.
[C-0-2] يجب إضافة مكتبة org.apache.http.legacy إلى مسار فئة التطبيق فقط عندما يستوفي التطبيق أحد الشروط التالية:
- يستهدف المستوى 28 أو أقل من واجهة برمجة التطبيقات.
- تُعلن في ملف البيان عن حاجتها إلى المكتبة من خلال ضبط السمة android:name للعنصر <uses-library> على القيمة org.apache.http.legacy.

يتوافق تطبيق AOSP مع هذه المتطلبات.

3.2. توافق واجهة برمجة التطبيقات غير الصارم

بالإضافة إلى واجهات برمجة التطبيقات المُدارة الواردة في الفقرة 3.1، يتضمّن نظام التشغيل Android أيضًا واجهة برمجة تطبيقات "ناعمة" مهمة لا تعمل إلا في وقت التشغيل، وذلك في شكل عناصر مثل الأهداف والأذونات والجوانب المشابهة لتطبيقات Android التي لا يمكن فرضها في وقت تجميع التطبيق.

3.2.1. الأذونات

[C-0-1] على مطوّري الأجهزة توفير جميع ثوابت الأذونات وفرضها على النحو الموضّح في صفحة مرجع الأذونات. يُرجى العِلم أنّ الفقرة 9 تتضمّن قائمة بمتطلبات إضافية ذات صلة بنموذج أمان Android.

‫3.2.2. مَعلمات الإنشاء

تتضمّن واجهات برمجة التطبيقات في Android عددًا من الثوابت في فئة android.os.Build المخصّصة لوصف الجهاز الحالي.

[C-0-1] لتوفير قيم متسقة وذات مغزى على مستوى عمليات التنفيذ على الأجهزة، يتضمّن الجدول أدناه قيودًا إضافية على تنسيقات هذه القيم التي يجب أن تتوافق معها عمليات التنفيذ على الأجهزة.

المَعلمة	التفاصيل
VERSION.RELEASE	يمثّل هذا الحقل إصدار نظام Android الذي يتم تنفيذه حاليًا، وذلك بتنسيق يمكن للمستخدمين قراءته. يجب أن يحتوي هذا الحقل على إحدى قيم السلسلة المحدّدة في سلاسل الإصدارات المسموح بها لنظام التشغيل Android 17.
VERSION.SDK	يمثّل هذا الحقل إصدار نظام التشغيل Android الذي يتم تنفيذه حاليًا، وذلك بتنسيق يمكن الوصول إليه من خلال الرمز البرمجي للتطبيق التابع لجهة خارجية. في نظام التشغيل Android 17، يجب أن يحتوي هذا الحقل على القيمة الصحيحة 17_INT.
VERSION.SDK&lowbar;INT	يمثّل هذا الحقل إصدار نظام التشغيل Android الذي يتم تنفيذه حاليًا، وذلك بتنسيق يمكن الوصول إليه من خلال الرمز البرمجي للتطبيق التابع لجهة خارجية. في Android 17، يجب أن يحتوي هذا الحقل على القيمة الصحيحة 17&lowbar;INT.
VERSION.INCREMENTAL	قيمة يختارها مطوّر الجهاز لتحديد الإصدار المحدّد من نظام Android الذي يتم تنفيذه حاليًا، وذلك بتنسيق يمكن للمستخدمين قراءته. ويجب عدم إعادة استخدام هذه القيمة في إصدارات مختلفة يتم توفيرها للمستخدمين النهائيين. يُستخدَم هذا الحقل عادةً للإشارة إلى رقم الإصدار أو معرّف تغيير نظام التحكّم بالمصادر الذي تم استخدامه لإنشاء الإصدار. يجب أن تكون قيمة هذا الحقل قابلة للترميز كـ ASCII قابل للطباعة من 7 بت وأن تتطابق مع التعبير العادي `^[^ :\/~]+$`.
ألعاب ألواح	قيمة يختارها مطوّر الجهاز لتحديد الأجهزة الداخلية المحدّدة التي يستخدمها الجهاز، وذلك بتنسيق يمكن قراءته. من الاستخدامات المحتملة لهذا الحقل الإشارة إلى المراجعة المحدّدة للوحة التي تشغّل الجهاز. يجب أن تكون قيمة هذا الحقل قابلة للترميز باستخدام ASCII ذي 7 بتات وأن تتطابق مع التعبير العادي `^[a-zA-Z0-9_-]+$`.
العلامة التجارية	قيمة تعكس اسم العلامة التجارية المرتبط بالجهاز كما يعرفه المستخدمون النهائيون. يجب أن يكون بالتنسيق القابل للقراءة ويجب أن يمثّل الشركة المصنّعة للجهاز أو العلامة التجارية للشركة التي يتم تسويق الجهاز بموجبها. يجب أن تكون قيمة هذا الحقل قابلة للترميز باستخدام ASCII ذي 7 بت وأن تتطابق مع التعبير العادي `^[a-zA-Z0-9_-]+$`.
SUPPORTED&lowbar;ABIS	اسم مجموعة التعليمات (نوع وحدة المعالجة المركزية + اصطلاح ABI) للرمز البرمجي الأصلي راجِع الفقرة 3.3. توافق واجهة برمجة التطبيقات الأصلية
SUPPORTED&lowbar;32&lowbar;BIT&lowbar;ABIS	اسم مجموعة التعليمات (نوع وحدة المعالجة المركزية + اصطلاح ABI) للرمز البرمجي الأصلي راجِع الفقرة 3.3. توافق واجهة برمجة التطبيقات الأصلية
SUPPORTED&lowbar;64&lowbar;BIT&lowbar;ABIS	اسم مجموعة التعليمات الثانية (نوع وحدة المعالجة المركزية + اصطلاح واجهة التطبيق الثنائية (ABI)) للرمز البرمجي الأصلي راجِع الفقرة 3.3. توافق واجهة برمجة التطبيقات مع التطبيقات الأصلية
CPU&lowbar;ABI	اسم مجموعة التعليمات (نوع وحدة المعالجة المركزية + اصطلاح ABI) للرمز البرمجي الأصلي راجِع الفقرة 3.3. توافق واجهة برمجة التطبيقات الأصلية
CPU&lowbar;ABI2	اسم مجموعة التعليمات الثانية (نوع وحدة المعالجة المركزية + اصطلاح واجهة التطبيق الثنائية (ABI)) للرمز البرمجي الأصلي راجِع الفقرة 3.3. توافق واجهة برمجة التطبيقات مع التطبيقات الأصلية
الجهاز	قيمة يختارها مطوّر الجهاز تحتوي على الاسم التطويري أو الاسم الرمزي الذي يحدّد إعداد ميزات الأجهزة والتصميم الصناعي للجهاز. يجب أن تكون قيمة هذا الحقل قابلة للترميز باستخدام ASCII ذي 7 بت وأن تتطابق مع التعبير العادي `^[a-zA-Z0-9_-]+$`. يجب ألا يتغيّر اسم الجهاز هذا خلال عمر المنتج.
FINGERPRINT	سلسلة تحدّد هذا الإصدار بشكل فريد. يجب أن تكون قابلة للقراءة بشكل معقول. يجب أن يتبع هذا النموذج: $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) على سبيل المثال: acme/myproduct/ mydevice:17/LMYXX/3359:userdebug/test-keys يجب ألا تتضمّن البصمة الرقمية مسافات بيضاء. يجب أن تكون قيمة هذا الحقل قابلة للترميز باستخدام ASCII ذي 7 بت.
الأجهزة	اسم الجهاز (من سطر أوامر النواة أو /proc) ويجب أن تكون قابلة للقراءة بشكل معقول. يجب أن تكون قيمة هذا الحقل قابلة للترميز باستخدام ASCII ذي 7 بت وأن تتطابق مع التعبير العادي `^[a-zA-Z0-9_-]+$`.
HOST	سلسلة تحدّد بشكل فريد المضيف الذي تم إنشاء الإصدار عليه، وذلك بتنسيق يمكن للمستخدم قراءته. لا توجد متطلبات بشأن التنسيق المحدّد لهذا الحقل، باستثناء أنّه يجب ألا يكون فارغًا أو سلسلة فارغة ("").
رقم التعريف	معرّف يختاره مطوّر الجهاز للإشارة إلى إصدار معيّن، ويكون بتنسيق يمكن قراءته. يمكن أن يكون هذا الحقل هو نفسه android.os.Build.VERSION.INCREMENTAL، ولكن يجب أن تكون القيمة ذات دلالة كافية للمستخدمين النهائيين للتمييز بين إصدارات البرامج. يجب أن تكون قيمة هذا الحقل قابلة للترميز باستخدام ASCII ذي 7 بت وأن تتطابق مع التعبير العادي `^[a-zA-Z0-9._-]+$`.
الشركة المصنّعة	الاسم التجاري للمصنّع الأصلي للجهاز (OEM) الخاص بالمنتج لا توجد متطلبات بشأن التنسيق المحدّد لهذا الحقل، باستثناء أنّه يجب ألا تكون قيمته فارغة أو السلسلة الفارغة ("")، ويجب ألا يتغيّر هذا الحقل خلال مدة توفّر المنتج.
SOC&lowbar;MANUFACTURER	تمثّل هذه السمة اسم العلامة التجارية للشركة المصنّعة لنظام التشغيل الأساسي على الرقاقة (SOC) المستخدَم في المنتج. يجب أن تستخدم الأجهزة التي تحمل اسم الشركة المصنّعة نفسها لنظام SOC القيمة الثابتة نفسها. يُرجى التواصل مع الشركة المصنّعة لنظام SOC للحصول على الثابت الصحيح الذي يجب استخدامه. يجب أن تكون قيمة هذا الحقل قابلة للترميز باستخدام ASCII المكوّن من 7 بت، ويجب أن تتطابق مع التعبير العادي `^([0-9A-Za-z ]+)`، ويجب ألّا تبدأ أو تنتهي بمسافة بيضاء، ويجب ألّا تكون مساوية للقيمة "unknown". يجب ألا يتغير هذا الحقل خلال مدة توفّر المنتج.
SOC&lowbar;MODEL	تمثّل هذه السمة اسم طراز نظام التشغيل الأساسي على شريحة (SOC) المستخدَم في المنتج. يجب أن تستخدم الأجهزة التي تتضمّن طراز SOC نفسه القيمة الثابتة نفسها. يُرجى التواصل مع الشركة المصنّعة لنظام SOC للحصول على الثابت الصحيح الذي يجب استخدامه. يجب أن تكون قيمة هذا الحقل قابلة للترميز بتنسيق ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي `^([0-9A-Za-z ._/+-]+)$`، ويجب ألّا تبدأ أو تنتهي بمسافة بيضاء، ويجب ألّا تكون مساوية للقيمة "unknown". يجب ألا يتغير هذا الحقل خلال مدة توفّر المنتج.
MODEL	قيمة يختارها مطوّر الجهاز تتضمّن اسم الجهاز كما يعرفه المستخدم النهائي. يجب أن يكون هذا الاسم هو نفسه الاسم الذي يتم تسويق الجهاز وبيعه للمستخدمين النهائيين بموجبه. لا توجد متطلبات بشأن التنسيق المحدّد لهذا الحقل، باستثناء أنّه يجب ألا تكون قيمته فارغة أو السلسلة الفارغة (""). يُنصح بشدة بعدم تغيير قيمة هذا الحقل خلال فترة توفّر المنتج.
المنتج	قيمة يختارها مصنّع الجهاز تتضمّن الاسم التطويري أو الاسم الرمزي للمنتج المحدّد (وحدة حفظ المخزون) الذي يجب أن يكون فريدًا ضمن العلامة التجارية نفسها. يجب أن يكون قابلاً للقراءة من قِبل الإنسان، ولكن ليس بالضرورة أن يكون مخصّصًا للعرض من قِبل المستخدمين النهائيين. يجب أن تكون قيمة هذا الحقل قابلة للترميز باستخدام ASCII ذي 7 بتات وأن تتطابق مع التعبير العادي `^[a-zA-Z0-9_-]+$`. يجب ألا يتغيّر اسم المنتج هذا خلال فترة صلاحيته.
ODM&lowbar;SKU	قيمة اختيارية يختارها مطوّر الجهاز وتحتوي على رمز التخزين التعريفي (SKU) المستخدَم لتتبُّع إعدادات معيّنة للجهاز، مثل أي أجهزة ملحقة مضمّنة مع الجهاز عند بيعه. يجب أن تكون قيمة هذا الحقل قابلة للترميز باستخدام ASCII ذي 7 بت وأن تتطابق مع التعبير العادي `^([0-9A-Za-z.,_-]+)$`.
SERIAL	يجب أن تعرض القيمة "UNKNOWN".
العلامات	تمثّل هذه السمة قائمة قيم مفصولة بفاصلة من العلامات اختارها مطوّر الجهاز لتحديد الإصدار بشكل أكبر. يجب أن تكون العلامات قابلة للترميز بتنسيق ASCII ذي 7 بت وأن تتطابق مع التعبير العادي `^[a-zA-Z0-9._-]+`، ويجب أن تتضمّن إحدى القيم المتوافقة مع إعدادات التوقيع الثلاثة الشائعة لمنصة Android: release-keys وdev-keys وtest-keys.
الوقت	قيمة تمثّل الطابع الزمني لوقت حدوث الإنشاء.
النوع	قيمة يختارها منفِّذ الجهاز لتحديد إعدادات وقت التشغيل للنسخة. يجب أن يحتوي هذا الحقل على إحدى القيم التي تتوافق مع إعدادات وقت التشغيل الثلاثة الشائعة لنظام Android: user أو userdebug أو eng.
المستخدم	اسم أو معرّف المستخدم (أو المستخدم الآلي) الذي أنشأ الإصدار لا توجد متطلبات بشأن التنسيق المحدّد لهذا الحقل، باستثناء أنّه يجب ألا تكون قيمته فارغة أو السلسلة الفارغة ("").
SECURITY&lowbar;PATCH	قيمة تشير إلى مستوى رمز تصحيح الأمان لإصدار معيّن. يجب أن يشير ذلك إلى أنّ الإصدار ليس عرضة بأي شكل من الأشكال لأي من المشاكل الموضّحة في نشرة أمان Android العامة المحدّدة. يجب أن يكون بالتنسيق [YYYY-MM-DD]، وأن يتطابق مع سلسلة محدّدة موثّقة في نشرة أمان Android العامة أو في إشعار أمان Android، مثل "2015-11-01".
BASE&lowbar;OS	قيمة تمثّل المَعلمة FINGERPRINT للإصدار الذي يكون مطابقًا لهذا الإصدار من جميع النواحي باستثناء تصحيحات الأمان الواردة في "نشرة أمان Android العلنية". ويجب أن تعرض القيمة الصحيحة، وإذا لم يكن هناك إصدار، يجب أن تعرض سلسلة فارغة ("").
BOOTLOADER	قيمة يختارها مطوّر الجهاز لتحديد إصدار برنامج الإقلاع الداخلي المحدّد المستخدَم في الجهاز، وذلك بتنسيق يمكن لشخص عادي قراءته. يجب أن تكون قيمة هذا الحقل قابلة للترميز باستخدام ASCII ذي 7 بت وأن تتطابق مع التعبير العادي `^[a-zA-Z0-9._-]+$`.
getRadioVersion()	يجب أن تكون القيمة التي تعرضها هذه السمة هي قيمة يختارها مطوّر الجهاز وتحدّد إصدار الراديو/المودم الداخلي المستخدَم في الجهاز، ويجب أن تكون بالتنسيق الذي يمكن للمستخدمين قراءته. إذا لم يكن الجهاز مزوّدًا بأي جهاز راديو/مودم داخلي، يجب أن يعرض القيمة NULL. يجب أن تكون قيمة هذا الحقل قابلة للترميز باستخدام ASCII ذي 7 بت وأن تتطابق مع التعبير العادي `^[a-zA-Z0-9._-,]+$`.
getSerial()	يجب أن يكون (أو يعرض) رقمًا تسلسليًا للأجهزة، ويجب أن يكون متاحًا وفريدًا على مستوى الأجهزة التي تحمل MODEL وMANUFACTURER نفسيهما. يجب أن تكون قيمة هذا الحقل قابلة للترميز باستخدام ASCII ذي 7 بت وأن تتطابق مع التعبير العادي `^[a-zA-Z0-9]+$`.
STRONGBOX&lowbar;MANUFACTURER	الاسم التجاري للشركة المصنّعة لشريحة StrongBox المستخدَمة في المنتج يوفّر مورّد StrongBox الثابت الصحيح. يجب أن تستخدم الأجهزة التي لديها المورّد نفسه لـ StrongBox القيمة الثابتة نفسها. يجب أن تتطابق قيمة هذا الحقل مع التعبير العادي `^([0-9A-Za-z ]+)`، ويجب ألا تكون مساوية للقيمة "unsupported". يجب ألا يتغيّر هذا الحقل خلال مدة توفّر المنتج.
STRONGBOX&lowbar;MODEL	اسم طراز شريحة StrongBox المستخدَمة في المنتج: يوفّر مورّد StrongBox الثابت الصحيح. يجب أن تستخدم الأجهزة التي لديها مورّد StrongBox نفسه القيمة الثابتة نفسها. يجب أن تتطابق قيمة هذا الحقل مع التعبير العادي `^([0-9A-Za-z ._/+-]+)$`، ويجب ألا تكون مساوية للقيمة "unsupported". يجب ألا يتغير هذا الحقل خلال مدة توفّر المنتج.

‫3.2.3. توافق النية

‫3.2.3.1. أهداف التطبيق الشائعة

تسمح رسائل Intent في Android لمكوّنات التطبيق بطلب وظائف من مكوّنات Android الأخرى. يتضمّن مشروع Android الأساسي قائمة بالتطبيقات التي تنفّذ العديد من أنماط الأهداف لتنفيذ إجراءات شائعة.

عمليات تنفيذ الجهاز:

[C-SR-1] يُنصح بشدة بالتحميل مسبقًا لتطبيق واحد أو أكثر أو مكونات الخدمة مع معالج intent، وذلك لجميع أنماط intent filter العامة المحددة من خلال intents التطبيقات التالية المدرَجة هنا، وتقديم تنفيذ الطلب، أي استيفاء توقعات المطوّر بشأن intents التطبيقات الشائعة هذه كما هو موضح في حزمة تطوير البرامج (SDK).

يُرجى الرجوع إلى القسم 2 للاطّلاع على نوايا التطبيق الإلزامية لكل نوع من أنواع الأجهزة.

‫3.2.3.2. حلّ النية

[C-0-1] بما أنّ Android نظام أساسي قابل للتوسيع، يجب أن تسمح عمليات تنفيذ الأجهزة بتجاوز كل نمط من أنماط الأهداف المشار إليها في الفقرة 3.2.3.1 باستثناء الإعدادات، من خلال تطبيقات تابعة لجهات خارجية. تسمح عملية التنفيذ المسبق لنظام التشغيل Android المفتوح المصدر بذلك تلقائيًا.
[C-0-2] يجب ألا يمنح مطوّرو الأجهزة امتيازات خاصة لتطبيقات النظام عند استخدام أنماط الأهداف هذه، أو يمنعوا التطبيقات التابعة لجهات خارجية من الربط بهذه الأنماط والتحكّم فيها. ويشمل هذا الحظر على وجه التحديد، على سبيل المثال لا الحصر، إيقاف واجهة المستخدم "أداة الاختيار" التي تتيح للمستخدم الاختيار بين تطبيقات متعددة تتعامل جميعها مع نمط الغرض نفسه.
[C-0-3] يجب أن توفّر عمليات تنفيذ الأجهزة واجهة مستخدم تتيح للمستخدمين تعديل النشاط التلقائي للأهداف.
ومع ذلك، قد توفّر عمليات تنفيذ الأجهزة أنشطة تلقائية لأنماط URI معيّنة (مثل http://play.google.com) عندما يوفّر النشاط التلقائي سمة أكثر تحديدًا لعنوان URI الخاص بالبيانات. على سبيل المثال، يكون نمط intent filter الذي يحدّد معرّف الموارد المنتظم للبيانات "http://www.android.com" أكثر تحديدًا من نمط intent الأساسي للمتصفّح الذي يخصّ "http://‎".

يتضمّن نظام التشغيل Android أيضًا آلية تتيح للتطبيقات التابعة لجهات خارجية تحديد سلوك موثوق به تلقائي لربط التطبيقات لأنواع معيّنة من أغراض معرّفات الموارد المنتظمة (URI) على الويب. عندما يتم تحديد مثل هذه الإعلانات الموثوقة في أنماط intent filter في التطبيق، يجب أن تتضمّن عمليات تنفيذ الأجهزة ما يلي:

[C-0-4] يجب محاولة التحقّق من صحة أي فلاتر أهداف من خلال تنفيذ خطوات التحقّق المحدّدة في مواصفات روابط التنقل إلى مواد العرض الرقمية كما هو موضّح في "مدير الحِزم" في "مشروع Android المفتوح المصدر" الأساسي.
[C-0-5] يجب محاولة التحقّق من صحة فلاتر intent أثناء تثبيت التطبيق وتعيين جميع فلاتر intent لمعرّفات الموارد المنتظمة التي تم التحقّق من صحتها بنجاح كمعالجات تلقائية للتطبيق لمعرّفات الموارد المنتظمة الخاصة بها.
يمكن ضبط فلاتر أهداف معرّفات الموارد المنتظمة (URI) المحدّدة كمعالجات تلقائية للتطبيقات لمعرّفات الموارد المنتظمة (URI) الخاصة بها، إذا تم التحقّق منها بنجاح ولكن تعذّر التحقّق من فلاتر معرّفات الموارد المنتظمة (URI) الأخرى المرشّحة. إذا كان تنفيذ الجهاز يتيح ذلك، يجب أن يوفّر للمستخدم عمليات إلغاء مناسبة لكل نمط من أنماط معرّفات الموارد المنتظمة (URI) في قائمة الإعدادات.
يجب أن يوفّر للمستخدم عناصر تحكّم في روابط التطبيقات لكل تطبيق في "الإعدادات" على النحو التالي:
- [C-0-6] يجب أن يتمكّن المستخدم من إلغاء السلوك التلقائي لروابط التطبيقات بشكل شامل، وذلك لتحديد ما إذا كان سيتم فتح التطبيق دائمًا أو السؤال في كل مرة أو عدم فتحه مطلقًا، ويجب أن ينطبق ذلك على جميع فلاتر الأهداف لمعرّفات الموارد الموحّدة المرشّحة بالتساوي.
- [C-0-7] يجب أن يتمكّن المستخدم من الاطّلاع على قائمة بفلاتر أهداف معرّف الموارد المنتظم المرشّح.
- قد يتيح تنفيذ الجهاز للمستخدم إمكانية تجاهل فلاتر الأهداف الخاصة بمعرّف الموارد المنتظم (URI) المرشّح التي تم التحقّق منها بنجاح، وذلك على أساس كل فلتر هدف.
- [C-0-8] يجب أن يوفّر تنفيذ الجهاز للمستخدمين إمكانية عرض فلاتر الأهداف الخاصة بمعرّف الموارد المنتظم (URI) المرشّح وتجاوزها إذا كان تنفيذ الجهاز يسمح بنجاح بعض فلاتر الأهداف الخاصة بمعرّف الموارد المنتظم (URI) المرشّح مع تعذُّر البعض الآخر.

‫3.2.3.3. مساحات أسماء Intent

[C-0-1] يجب ألا تتضمّن عمليات تنفيذ الأجهزة أي مكوّن Android يلتزم بأي أنماط أهداف أو أنماط أهداف بث جديدة تستخدم ACTION أو CATEGORY أو أي سلسلة مفاتيح أخرى في مساحة الاسم android.* أو com.android.*.
[C-0-2] يجب ألا يدرج مطوّرو الأجهزة أي مكوّنات Android تتوافق مع أي أنماط جديدة للأهداف أو أهداف البث باستخدام ACTION أو CATEGORY أو أي سلسلة مفاتيح أخرى في مساحة حزمة تابعة لمؤسسة أخرى.
[C-0-3] يجب ألا يغيّر مطوّرو الأجهزة أو يوسّعوا أيًا من أنماط الأهداف المذكورة في الفقرة 3.2.3.1.
قد تتضمّن عمليات تنفيذ الأجهزة أنماط أهداف تستخدم مساحات أسماء مرتبطة بوضوح وبشكل ظاهر بمؤسساتها. ويشبه هذا الحظر الحظر المحدّد لفئات لغة Java في الفقرة 3.6.

‫3.2.3.4. Broadcast Intents

تعتمد التطبيقات التابعة لجهات خارجية على المنصة لبث نوايا معيّنة لإعلامها بالتغييرات في بيئة الأجهزة أو البرامج.

عمليات تنفيذ الجهاز:

[C-0-1] يجب بث نوايا البث العام المدرَجة هنا استجابةً لأحداث النظام المناسبة كما هو موضّح في مستندات حزمة تطوير البرامج (SDK). يُرجى العلم أنّ هذا الشرط لا يتعارض مع الفقرة 3.5، إذ تم توضيح القيود المفروضة على التطبيقات التي تعمل في الخلفية في مستندات حزمة SDK أيضًا. بالإضافة إلى ذلك، تخضع بعض أغراض البث لشرط توفّر دعم الأجهزة، فإذا كان الجهاز يتيح الأجهزة اللازمة، يجب أن يبث الأغراض وأن يوفّر السلوك المتوافق مع مستندات حزمة تطوير البرامج (SDK).

‫3.2.3.5. Conditional Application Intents

يتضمّن نظام التشغيل Android إعدادات تتيح للمستخدمين طريقة سهلة لاختيار تطبيقاتهم التلقائية، مثل الشاشة الرئيسية أو الرسائل القصيرة.

ويجب أن توفّر عمليات تنفيذ الأجهزة قائمة إعدادات مشابهة وأن تكون متوافقة مع نمط فلتر الأهداف وطُرق واجهة برمجة التطبيقات الموضّحة في مستندات حزمة تطوير البرامج (SDK) على النحو التالي.

إذا كان تقرير عمليات تنفيذ الأجهزة android.software.home_screen، يعني ذلك ما يلي:

[C-1-1] يجب أن يلتزم بتنفيذ الغرض من طلب android.settings.HOME_SETTINGS لعرض قائمة إعدادات التطبيق التلقائي للشاشة الرئيسية.

إذا كان تقرير عمليات تنفيذ الأجهزة android.hardware.telephony.calling، يعني ذلك ما يلي:

[C-2-1] يجب توفير قائمة إعدادات تستدعي الغرض android.provider.Telephony.ACTION_CHANGE_DEFAULT لعرض مربّع حوار لتغيير تطبيق SMS التلقائي.
[C-2-2] يجب أن يلتزم الجهاز بطلب android.telecom.action.CHANGE_DEFAULT_DIALER لعرض مربّع حوار يتيح للمستخدم تغيير تطبيق "الهاتف" التلقائي.
- يجب استخدام واجهة المستخدم لتطبيق "الهاتف" التلقائي الذي يختاره المستخدم للمكالمات الواردة والصادرة، باستثناء مكالمات الطوارئ التي سيتم إجراؤها باستخدام تطبيق "الهاتف" المثبَّت مسبقًا.
[C-2-3] يجب أن يستجيب الجهاز لطلب android.telecom.action.CHANGE_PHONE_ACCOUNTS لتوفير إمكانية للمستخدمين من أجل ضبط ConnectionServices المرتبط PhoneAccounts، بالإضافة إلى حساب PhoneAccount تلقائي سيستخدمه مقدّم خدمة الاتصالات لإجراء المكالمات الصادرة. تستوفي عملية التنفيذ في AOSP هذا الشرط من خلال تضمين قائمة "خيارات حسابات الاتصال" ضمن قائمة إعدادات "المكالمات".
[C-2-4] يجب أن يسمح android.telecom.CallRedirectionService للتطبيق الذي يتضمّن دور android.app.role.CALL_REDIRECTION.
[C-2-5] يجب توفير عنصر تحكّم للمستخدم لاختيار تطبيق لديه الدور android.app.role.CALL_REDIRECTION.
[C-2-6] يجب أن يلتزم التطبيق بطلبات android.intent.action.SENDTO وandroid.intent.action.VIEW وأن يوفّر نشاطًا لإرسال رسائل SMS وعرضها.
[C-SR-1] يُنصح بشدة بتنفيذ الأهداف android.intent.action.ANSWER وandroid.intent.action.CALL وandroid.intent.action.CALL_BUTTON وandroid.intent.action.VIEW وandroid.intent.action.DIAL باستخدام تطبيق لوحة الاتصال مثبَّت مسبقًا يمكنه التعامل مع هذه الأهداف وتوفير التنفيذ كما هو موضّح في حزمة تطوير البرامج (SDK).

إذا كان تقرير عمليات تنفيذ الأجهزة android.hardware.nfc.hce، يعني ذلك ما يلي:

[C-3-1] يجب أن يستجيب الجهاز لطلب android.settings.NFC_PAYMENT_SETTINGS لعرض قائمة إعدادات التطبيق التلقائي للدفع بدون تلامس الأجهزة.
[C-3-2] يجب أن يستجيب الجهاز لطلب android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT لإظهار نشاط يفتح مربّع حوار يطلب من المستخدم تغيير خدمة محاكاة البطاقة التلقائية لفئة معيّنة كما هو موضّح في حزمة تطوير البرامج (SDK).

إذا كان تقرير عمليات تنفيذ الأجهزة android.hardware.nfc، يعني ذلك ما يلي:

[C-4-1] يجب أن تتوافق مع ملفات Intent التالية: android.nfc.action.NDEF_DISCOVERED وandroid.nfc.action.TAG_DISCOVERED وandroid.nfc.action.TECH_DISCOVERED، وذلك لعرض نشاط يستوفي توقعات المطوّرين بشأن ملفات Intent هذه كما هو موضّح في حزمة SDK.

إذا كان تقرير عمليات تنفيذ الأجهزة android.hardware.bluetooth، يعني ذلك ما يلي:

[C-5-1] يجب الاستجابة للغرض ‎'android.bluetooth.adapter.action.REQUEST_ENABLE'‎ وعرض نشاط نظام للسماح للمستخدم بتفعيل البلوتوث.
[C-5-2] يجب أن يستجيب الجهاز لطلب 'android.bluetooth.adapter.action.REQUEST_DISCOVERABLE' وأن يعرض نشاطًا على النظام يطلب تفعيل وضع العثور على الجهاز.

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع ميزة "عدم الإزعاج"، فإنّها:

[C-6-1] يجب تنفيذ نشاط يستجيب للغرض ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS، والذي يجب أن يكون نشاطًا يتيح للمستخدم منح التطبيق إذن الوصول إلى إعدادات سياسة "عدم الإزعاج" أو رفضه، وذلك في عمليات التنفيذ التي تستخدم UI_MODE_TYPE_NORMAL.

إذا كانت عمليات تنفيذ الأجهزة تسمح للمستخدمين باستخدام أساليب إدخال تابعة لجهات خارجية على الجهاز، يجب أن تستوفي ما يلي:

[C-7-1] يجب توفير آلية يمكن للمستخدم الوصول إليها لإضافة أساليب إدخال تابعة لجهات خارجية وضبطها استجابةً للنية android.settings.INPUT_METHOD_SETTINGS.

في حال كانت عمليات تنفيذ الأجهزة تتوافق مع خدمات تسهيل الاستخدام التابعة لجهات خارجية، يجب أن:

[C-8-1] يجب الالتزام android.settings.ACCESSIBILITY_SETTINGS بالنية في توفير آلية يمكن للمستخدم الوصول إليها لتفعيل خدمات تسهيل الاستخدام التابعة لجهات خارجية وإيقافها إلى جانب خدمات تسهيل الاستخدام المحمَّلة مسبقًا.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة استخدام ميزة Wi-Fi Easy Connect وتوفّر الوظيفة للتطبيقات التابعة لجهات خارجية، يجب أن تستوفي ما يلي:

[C-9-1] يجب تنفيذ واجهات برمجة التطبيقات الخاصة بـ Intent Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK).

إذا كانت عمليات تنفيذ الأجهزة توفّر وضع "توفير البيانات"، يجب أن:

[C-10-1] يجب توفير واجهة مستخدم في الإعدادات تتعامل مع الغرض Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS، ما يتيح للمستخدمين إضافة تطبيقات إلى القائمة المسموح بها أو إزالتها منها.

إذا لم توفّر عمليات تنفيذ الأجهزة وضع "توفير البيانات"، عليها استيفاء ما يلي:

[C-11-1] يجب أن يتضمّن التطبيق نشاطًا يتعامل مع الغرض Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS ، ولكن يجوز تنفيذه كعملية غير فعّالة.

إذا كانت عمليات تنفيذ الأجهزة تعلن عن إتاحة الكاميرا من خلال android.hardware.camera.any، يجب أن تستوفي ما يلي:

[C-12-3] يجب أن يتم التعامل مع تطبيقات Android المثبَّتة مسبقًا فقط والسماح لها بالتعامل مع النوايا التالية MediaStore.ACTION_IMAGE_CAPTURE وMediaStore.ACTION_IMAGE_CAPTURE_SECURE وMediaStore.ACTION_VIDEO_CAPTURE على النحو الموضّح في مستند حزمة تطوير البرامج (SDK).

إذا كان تقرير عمليات تنفيذ الأجهزة android.software.device_admin، يعني ذلك ما يلي:

[C-13-1] يجب أن يتم تنفيذ الغرض android.app.action.ADD_DEVICE_ADMIN من استدعاء واجهة مستخدم لإرشاد المستخدم خلال عملية إضافة مشرف الجهاز إلى النظام (أو السماح له برفض ذلك).
[C-13-2] يجب أن تتوافق مع أغراض android.app.action.PROVISION_MANAGED_PROFILE وandroid.app.action.SET_NEW_PARENT_PROFILE_PASSWORD وandroid.app.action.SET_NEW_PASSWORD وandroid.app.action.START_ENCRYPTION، وأن تتضمّن نشاطًا لتنفيذ هذه الأغراض على النحو الموضّح في حزمة تطوير البرامج (SDK) هنا.

إذا كانت عمليات تنفيذ الأجهزة تعرّف علامة الميزة android.software.autofill، فإنّها:

[C-14-1] يجب تنفيذ واجهات برمجة التطبيقات AutofillService وAutofillManager بالكامل والالتزام بتنفيذ الغرض android.settings.REQUEST_SET_AUTOFILL_SERVICE لعرض قائمة إعدادات التطبيق التلقائية لتفعيل ميزة "الملء التلقائي" وإيقافها وتغيير خدمة "الملء التلقائي" التلقائية للمستخدم.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن تطبيقًا مثبَّتًا مسبقًا أو تريد السماح لتطبيقات تابعة لجهات خارجية بالوصول إلى إحصاءات الاستخدام، يجب أن تستوفي ما يلي:

[C-SR-2] يُنصح بشدة بتوفير آلية يمكن للمستخدم الوصول إليها لمنح إذن الوصول إلى إحصاءات الاستخدام أو إبطاله استجابةً للغرض android.settings.ACTION_USAGE_ACCESS_SETTINGS للتطبيقات التي تحدّد إذن android.permission.PACKAGE_USAGE_STATS.

إذا كانت عمليات تنفيذ الأجهزة تهدف إلى عدم السماح لأي تطبيقات، بما في ذلك التطبيقات المثبَّتة مسبقًا، بالوصول إلى إحصاءات الاستخدام، عليها اتّباع ما يلي:

[C-15-1] يجب أن يظل هناك نشاط يتعامل مع نمط الغرض android.settings.ACTION_USAGE_ACCESS_SETTINGS ولكن يجب تنفيذه كعملية غير فعّالة، أي أن يكون له سلوك مكافئ كما لو تم رفض وصول المستخدم.

إذا كانت عمليات تنفيذ الأجهزة تعرض روابط تؤدي إلى الأنشطة المحدّدة من خلال AutofillService_passwordsActivity في "الإعدادات" أو روابط تؤدي إلى كلمات مرور المستخدمين من خلال آلية مشابهة، عليها استيفاء ما يلي:

‫[C-16-1] يجب عرض هذه الروابط لجميع خدمات الملء التلقائي المثبَّتة.

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع VoiceInteractionService وكان هناك أكثر من تطبيق واحد يستخدم واجهة برمجة التطبيقات هذه مثبّتًا في الوقت نفسه، يجب أن تستوفي ما يلي:

[C-18-1] يجب الالتزام بتنفيذ الغرض من android.settings.ACTION_VOICE_INPUT_SETTINGS لعرض قائمة إعدادات التطبيق التلقائي الخاصة بالإدخال الصوتي والمساعدة.

إذا كانت عمليات تنفيذ الأجهزة تُبلغ عن الميزة android.hardware.audio.output، عليها استيفاء ما يلي:

[C-SR-3] يُنصح بشدة بتوفير نشاط للتعامل مع الأهداف android.intent.action.TTS_SERVICE وandroid.speech.tts.engine.INSTALL_TTS_DATA وandroid.speech.tts.engine.GET_SAMPLE_TEXT على النحو الموضّح في حزمة SDK هنا.

يتوافق نظام التشغيل Android مع شاشات التوقف التفاعلية التي كانت تُعرف سابقًا باسم Dreams. تتيح شاشات التوقف للمستخدمين التفاعل مع التطبيقات عندما يكون الجهاز الموصّل بمصدر طاقة في وضع الخمول أو عند توصيله بقاعدة شحن. عمليات تنفيذ الأجهزة:

يجب أن تتضمّن إمكانية استخدام شاشات الاستراحة وأن توفّر خيار إعدادات للمستخدمين لتفعيل شاشات الاستراحة استجابةً للطلب android.settings.DREAM_SETTINGS.

إذا كانت عمليات تنفيذ الأجهزة تعرض android.hardware.nfc.uicc أو android.hardware.nfc.ese، فإنّها:

[C-19-1] يجب تنفيذ واجهة برمجة التطبيقات NfcAdapter.ACTION_TRANSACTION_DETECTED Intent (باسم "EVT_TRANSACTION" كما هو محدّد في المواصفات الفنية الصادرة عن جمعية GSM‏ TS.26 - متطلبات هواتف NFC).

‫3.2.4. الأنشطة على شاشات العرض الثانوية/المتعددة

إذا كانت عمليات تنفيذ الأجهزة تسمح بتشغيل أنشطة Android العادية على أكثر من شاشة واحدة، يجب أن:

[C-1-1] يجب ضبط علامة الميزة android.software.activities_on_secondary_displays.
[C-1-2] يجب ضمان توافق واجهة برمجة التطبيقات بشكل مشابه لتوافق نشاط يتم تشغيله على الشاشة الأساسية.
[C-1-3] يجب أن يتم عرض النشاط الجديد على الشاشة نفسها التي تم تشغيله منها، وذلك عند تشغيل النشاط الجديد بدون تحديد شاشة مستهدَفة من خلال واجهة برمجة التطبيقات ActivityOptions.setLaunchDisplayId().
[C-1-4] يجب إيقاف جميع الأنشطة عند إزالة شاشة تحمل العلامة Display.FLAG_PRIVATE.
[C-1-5] يجب إخفاء المحتوى بشكل آمن على جميع الشاشات عندما يكون الجهاز مقفلاً باستخدام شاشة قفل آمنة، ما لم يوافق التطبيق على العرض في أعلى شاشة القفل باستخدام واجهة برمجة التطبيقات Activity#setShowWhenLocked().
يجب أن يتضمّن android.content.res.Configuration الذي يتوافق مع تلك الشاشة ليتم عرضه، ويعمل بشكل صحيح، ويحافظ على التوافق في حال تم تشغيل نشاط على شاشة ثانوية.

إذا كانت عمليات تنفيذ الأجهزة تسمح بتشغيل أنشطة Android العادية على شاشات العرض الثانوية وكانت إحدى شاشات العرض الثانوية تتضمّن العلامة android.view.Display.FLAG_PRIVATE:

[C-3-1] يجب أن يتمكّن مالك الشاشة والنظام والأنشطة المعروضة عليها فقط من تشغيلها. يمكن للجميع تشغيل التطبيق على شاشة عرض تتضمّن العلامة android.view.Display.FLAG_PUBLIC.

‫3.3. توافُق واجهة برمجة التطبيقات الأصلية

يصعب ضمان توافق الرموز البرمجية الأصلية. لهذا السبب، يجب على مطوّري الأجهزة الالتزام بما يلي:

[C-SR-1] يُنصح بشدة باستخدام عمليات تنفيذ المكتبات المدرَجة أدناه من "مشروع Android المفتوح المصدر".

‫3.3.1. واجهات التطبيق الثنائية

يمكن لرمز Dalvik البايت المُدار استدعاء الرمز البرمجي الأصلي المتوفّر في ملف .apk للتطبيق كملف .so بتنسيق ELF تم تجميعه لبنية أجهزة الجهاز المناسبة. بما أنّ الرموز البرمجية الأصلية تعتمد بشكل كبير على تكنولوجيا المعالج الأساسية، يحدّد Android عددًا من واجهات التطبيق الثنائية (ABI) في Android NDK.

عمليات تنفيذ الجهاز:

[C-0-1] يجب أن يكون متوافقًا مع واحد أو أكثر من واجهات التطبيق الثنائية (ABI) في Android NDK المحدّدة.
[C-0-2] يجب أن يتضمّن دعمًا لتشغيل الرمز في البيئة المُدارة من أجل استدعاء الرموز البرمجية الأصلية، وذلك باستخدام دلالات Java Native Interface (JNI) العادية.
[C-0-3] يجب أن يكون الجهاز متوافقًا مع المصدر (أي متوافقًا مع العناوين) ومتوافقًا مع الرمز الثنائي (بالنسبة إلى واجهة التطبيق الثنائية) مع كل مكتبة مطلوبة في القائمة أدناه.
[C-0-5] يجب أن يقدّم الجهاز تقريرًا دقيقًا عن واجهة التطبيق الثنائية (ABI) الأصلية المتوافقة مع الجهاز، وذلك من خلال المَعلمات android.os.Build.SUPPORTED_ABIS وandroid.os.Build.SUPPORTED_32_BIT_ABIS وandroid.os.Build.SUPPORTED_64_BIT_ABIS، وكلّ منها عبارة عن قائمة بواجهات التطبيق الثنائية مفصولة بفواصل ومرتّبة من الأكثر تفضيلاً إلى الأقل تفضيلاً.
[C-0-6] يجب الإبلاغ، من خلال المَعلمات المذكورة أعلاه، عن مجموعة فرعية من قائمة واجهات التطبيق الثنائية (ABI) التالية، ويجب عدم الإبلاغ عن أي واجهة تطبيق ثنائية غير مدرَجة في القائمة.
- ‫armeabi (لم يعُد هذا الخيار متاحًا كهدف في NDK)
- armeabi-v7a
- arm64-v8a
- x86
- x86-64
- riscv64
[C-0-7] يجب إتاحة جميع المكتبات التالية التي توفّر واجهات برمجة تطبيقات أصلية للتطبيقات التي تتضمّن رموزًا برمجية أصلية:
- libaaudio.so (دعم الصوت الأصلي في AAudio)
- libamidi.so (إتاحة MIDI الأصلية، إذا تم الإعلان عن الميزة android.software.midi كما هو موضّح في القسم 5.9)
- libandroid.so (التوافق مع أنشطة Android الأصلية)
- libc (مكتبة C)
- libcamera2ndk.so
- libdl (رابط ديناميكي)
- libEGL.so (إدارة مساحة عرض OpenGL الأصلية)
- libGLESv1_CM.so (OpenGL ES 1.x)
- libGLESv2.so (OpenGL ES 2.0)
- libGLESv3.so (OpenGL ES 3.x)
- libicui18n.so
- libicuuc.so
- libjnigraphics.so
- liblog (تسجيل البيانات على Android)
- libmediandk.so (إتاحة واجهات برمجة تطبيقات الوسائط الأصلية)
- libm (مكتبة الرياضيات)
- libneuralnetworks.so (Neural Networks API)
- libOpenMAXAL.so (دعم OpenMAX AL 1.0.1)
- libOpenSLES.so (التوافق مع الصوت OpenSL ES 1.0.1)
- libRS.so
- libstdc++‎ (الحد الأدنى من التوافق مع C++)
- libvulkan.so (Vulkan)
- libz (ضغط Zlib)
- واجهة JNI
[C-0-8] يجب عدم إضافة أو إزالة الوظائف العامة للمكتبات الأصلية المذكورة أعلاه.
[C-0-9] يجب إدراج المكتبات الإضافية غير التابعة لمشروع Android المفتوح المصدر (AOSP) والتي يتم عرضها مباشرةً للتطبيقات التابعة لجهات خارجية في /vendor/etc/public.libraries.txt.
[C-0-10] يجب عدم عرض أي مكتبات أصلية أخرى تم تنفيذها وتوفيرها في مشروع AOSP كمكتبات نظام للتطبيقات التابعة لجهات خارجية التي تستهدف مستوى واجهة برمجة التطبيقات 24 أو أعلى لأنّها محجوزة.
[C-0-11] يجب تصدير جميع رموز الدوال الخاصة بإصدار OpenGL ES 3.1 وحزمة Android الإضافية، كما هو محدّد في NDK، من خلال مكتبة libGLESv3.so. يُرجى العِلم أنّه يجب توفُّر جميع الرموز، ولكن يقدّم القسم 7.1.4.1 وصفًا أكثر تفصيلاً للمتطلبات المتعلقة بالحالات التي يُتوقّع فيها التنفيذ الكامل لكل وظيفة مقابلة.
[C-0-12] يجب تصدير رموز الدوال الأساسية في Vulkan 1.1، بالإضافة إلى الإضافات VK_KHR_surface وVK_KHR_android_surface وVK_KHR_swapchain وVK_KHR_maintenance1 وVK_KHR_get_physical_device_properties2 من خلال مكتبة libvulkan.so. يُرجى العِلم أنّه يجب توفُّر جميع الرموز، ويقدّم القسم 7.1.4.2 وصفًا أكثر تفصيلاً للمتطلبات المتعلقة بالحالات التي يُتوقّع فيها التنفيذ الكامل لكل دالة من الدوال المقابلة.
يجب أن يتم إنشاؤها باستخدام الرمز المصدر وملفات العناوين المتوفرة في مشروع Android المفتوح المصدر.

يُرجى العِلم أنّ إصدارات Android المستقبلية قد تتضمّن دعمًا لواجهات ABI إضافية.

‫3.3.2. توافق الرمز البرمجي الأصلي ARM بنظام 32 بت

إذا كانت عمليات تنفيذ الأجهزة تشير إلى توافقها مع واجهة armeabi الثنائية، فإنّها:

[C-3-1] يجب أيضًا أن يتوافق مع armeabi-v7a وأن يبلِّغ عن توافقه، لأنّ armeabi مخصّص فقط للتوافق مع التطبيقات القديمة.

إذا كانت عمليات تنفيذ الأجهزة تشير إلى إتاحة واجهة armeabi-v7a الثنائية، فإنّ التطبيقات التي تستخدم هذه الواجهة الثنائية:

[C-2-1] يجب تضمين الأسطر التالية في /proc/cpuinfo، ويجب عدم تغيير القيم على الجهاز نفسه، حتى عندما تتم قراءتها بواسطة واجهات ABI أخرى.
- ‫Features:، متبوعًا بقائمة بأي ميزات اختيارية لوحدة المعالجة المركزية ARMv7 يتوافق معها الجهاز.
- CPU architecture:، متبوعًا بعدد صحيح يصف أعلى بنية ARM متوافقة مع الجهاز (مثلاً، "8" للأجهزة التي تستخدم ARMv8).
[C-2-2] يجب إتاحة العمليات التالية دائمًا، حتى في حال تنفيذ واجهة التطبيق الثنائية (ABI) على بنية ARMv8، إما من خلال توفير وحدة معالجة مركزية متوافقة أو من خلال محاكاة البرامج:
- تعليمات SWP وSWPB
- عمليات الحواجز CP15ISB وCP15DSB وCP15DMB
[C-2-3] يجب أن يتضمّن دعمًا لملحق Advanced SIMD (المعروف أيضًا باسم NEON).

‫3.4. توافق الويب

‫1.4.3. توافق WebView

إذا كانت عمليات تنفيذ الأجهزة توفّر تنفيذًا كاملاً لواجهة برمجة التطبيقات android.webkit.Webview، فإنّها:

[C-1-1] يجب الإبلاغ عن android.software.webview.
[C-1-2] يجب استخدام إصدار مشروع Chromium من مشروع Android مفتوح المصدر الأساسي على فرع Android 17 لتنفيذ واجهة برمجة التطبيقات android.webkit.WebView.
[C-1-3] يجب أن يكون تنسيق سلسلة وكيل المستخدم التي تعرضها WebView للتطبيقات التي تستهدف المستوى 36 أو مستوى أقل من حزمة تطوير البرامج (SDK) على النحو التالي:

Mozilla/5.0 (Linux; Android $(VERSION); \[$(MODEL)\] \[Build/$(BUILD)\]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- يجب أن تكون قيمة السلسلة $(VERSION) هي نفسها قيمة android.os.Build.VERSION.RELEASE.
- قد تكون السلسلة $(MODEL) فارغة، ولكن إذا لم تكن فارغة، يجب أن تتضمّن القيمة نفسها التي تتضمّنها android.os.Build.MODEL.
- يمكن حذف "Build/$(BUILD)"، ولكن في حال تضمينه، يجب أن يكون السلسلة $(BUILD) هي نفسها قيمة android.os.Build.ID.
- يجب أن تكون قيمة السلسلة $(CHROMIUM_VER) هي إصدار Chromium في مشروع Android المفتوح المصدر.
- يمكن أن تحذف عمليات تنفيذ الأجهزة كلمة "الجهاز الجوّال" من سلسلة وكيل المستخدم.
يجب أن يتيح مكوّن WebView أكبر عدد ممكن من ميزات HTML5، وفي حال إتاحة الميزة، يجب أن يتوافق مع مواصفات HTML5.
[C-1-4] يجب عرض المحتوى المقدَّم أو محتوى عنوان URL البعيد في عملية منفصلة عن التطبيق الذي ينشئ WebView. ويجب على عملية العرض المنفصلة تحديدًا أن يكون لديها أذونات أقل، وأن يتم تشغيلها باستخدام رقم تعريف مستخدم منفصل، وألا يكون لديها إذن بالوصول إلى دليل بيانات التطبيق، وألا يكون لديها إذن بالوصول المباشر إلى الشبكة، وأن يكون لديها إذن بالوصول إلى الحد الأدنى من خدمات النظام المطلوبة عبر Binder فقط. يتوافق تطبيق WebView في AOSP مع هذا الشرط.

ملاحظة: إذا كانت عمليات تنفيذ الجهاز 32 بت أو تعرّف علامة الميزة android.hardware.ram.low، تكون معفاة من C-1-4.

[C-1-5] يجب أن يكون تنسيق سلسلة وكيل المستخدم التلقائية التي تعرضها WebView للتطبيقات التي تستهدف المستوى 37 من حزمة SDK أو المستويات الأحدث على النحو التالي:
```
Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) ; wv)
AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0
$(CHROMIUM_MAJOR_VER).0.0.0 Mobile Safari/537.36
```
- يجب أن تكون قيمة السلسلة $(VERSION) هي القيمة الثابتة 10.
- يجب أن تكون السلسلة $(MODEL) هي الحرف الثابت K.
- يجب أن تكون قيمة السلسلة $(CHROMIUM_MAJOR_VER) هي الإصدار الرئيسي من Chromium في مشروع Android Open Source Project.
- يمكن أن تحذف عمليات تنفيذ الأجهزة كلمة "الجهاز الجوّال" من سلسلة وكيل المستخدم.

‫3.4.2. توافق المتصفّح

إذا كانت عمليات تنفيذ الأجهزة تتضمّن تطبيق متصفّح مستقلًا لتصفّح الويب بشكل عام، يجب أن تستوفي ما يلي:

[C-1-1] يجب أن تتوافق مع كل واجهات برمجة التطبيقات المرتبطة بـ HTML5:
[C-1-2] يجب أن تتوافق مع webstorage API من HTML5/W3C ويُفضّل أن تتوافق مع IndexedDB API من HTML5/W3C. يُرجى العِلم أنّ هيئات معايير تطوير الويب تتجه إلى تفضيل IndexedDB على Webstorage، لذا من المتوقّع أن يصبح IndexedDB مكوّنًا مطلوبًا في إصدار مستقبلي من Android.
قد يتم تضمين سلسلة وكيل مستخدم مخصّصة في تطبيق "المتصفّح" المستقل.
يجب أن يتيح تطبيق المتصفّح المستقل أكبر قدر ممكن من ميزات HTML5 (سواء كان يستند إلى تطبيق WebKit Browser الأساسي أو بديل تابع لجهة خارجية).

ومع ذلك، إذا لم تتضمّن عمليات تنفيذ الأجهزة تطبيق متصفّح مستقل، يجب أن تستوفي ما يلي:

[C-2-1] يجب أن تظلّ الأداة متوافقة مع أنماط النية العلنية الموضّحة في الفقرة 3.2.3.1.

‫3.5. توافُق سلوك واجهة برمجة التطبيقات

عمليات تنفيذ الجهاز:

[C-0-9] يجب التأكّد من تطبيق توافق سلوك واجهة برمجة التطبيقات على جميع التطبيقات المثبَّتة ما لم يتم حظرها كما هو موضّح في القسم 3.5.1.
[C-0-10] يجب عدم استخدام أسلوب القائمة المسموح بها الذي يضمن توافق سلوك واجهة برمجة التطبيقات فقط مع التطبيقات التي يختارها مطوّرو الأجهزة.

يجب أن تتوافق سلوكيات كل نوع من أنواع واجهات برمجة التطبيقات (المدارة والناعمة والأصلية والويب) مع التنفيذ المفضّل لمشروع Android المفتوح المصدر. في ما يلي بعض الجوانب المحدّدة التي يجب مراعاتها عند تحديد مدى التوافق:

‫[C-0-1] يجب ألا تغيّر الأجهزة سلوك أو دلالات أي غرض عادي.
[C-0-2] يجب ألا تغيّر الأجهزة دورة الحياة أو دلالات دورة الحياة لنوع معيّن من مكونات النظام (مثل الخدمة أو النشاط أو ContentProvider أو غير ذلك).
[C-0-3] يجب ألا تغيّر الأجهزة دلالات أحد الأذونات العادية.
يجب ألا تغيّر الأجهزة القيود المفروضة على التطبيقات التي تعمل في الخلفية. وعلى وجه التحديد، بالنسبة إلى التطبيقات التي تعمل في الخلفية:
- [C-0-4] يجب أن تتوقف عن تنفيذ عمليات معاودة الاتصال التي يسجّلها التطبيق لتلقّي النتائج من GnssMeasurement وGnssNavigationMessage.
- [C-0-5] يجب أن يتم الحدّ من معدّل تكرار التحديثات التي يتم توفيرها للتطبيق من خلال فئة واجهة برمجة التطبيقات LocationManager أو طريقة WifiManager.startScan().
- [C-0-6] إذا كان التطبيق يستهدف المستوى 25 أو أعلى من واجهة برمجة التطبيقات، يجب ألّا يسمح بتسجيل أدوات استقبال البث لعمليات البث الضمنية لغايات Android العادية في بيان التطبيق، ما لم تتطلّب غاية البث إذن "signature" أو "signatureOrSystem" protectionLevel أو كانت ضمن قائمة الإعفاء.
- [C-0-7] إذا كان التطبيق يستهدف المستوى 25 أو أعلى من واجهة برمجة التطبيقات، يجب إيقاف خدمات التطبيق التي تعمل في الخلفية، تمامًا كما لو كان التطبيق قد استدعى طريقة stopSelf() الخاصة بالخدمات، ما لم يتم وضع التطبيق في قائمة السماح المؤقتة للتعامل مع مهمة مرئية للمستخدم.
- [C-0-8] إذا كان التطبيق يستهدف المستوى 25 أو مستوى أحدث لواجهة برمجة التطبيقات، يجب أن يحرر التطبيق عمليات التنشيط التي يحتفظ بها.
[C-0-11] يجب أن تعرض الأجهزة موفّري الأمان التاليين كأول سبع قيم في المصفوفة من خلال طريقة Security.getProviders()، بالترتيب المحدّد وبالأسماء المحدّدة (كما تعرضها طريقة Provider.getName()) والفئات، ما لم يعدّل التطبيق القائمة من خلال insertProviderAt() أو removeProvider(). يمكن أن تعرض الأجهزة مزوّدين إضافيين بعد قائمة المزوّدين المحدّدة أدناه.
1. ‫AndroidNSSP - android.security.net.config.NetworkSecurityConfigProvider
2. ‫AndroidOpenSSL - com.android.org.conscrypt.OpenSSLProvider
3. ‫CertPathProvider - sun.security.provider.CertPathProvider
4. ‫AndroidKeyStoreBCWorkaround - android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
5. BC - com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
6. ‫HarmonyJSSE - com.android.org.conscrypt.JSSEProvider
7. ‫AndroidKeyStore - android.security.keystore.AndroidKeyStoreProvider

يُرجى العِلم أنّ القائمة أعلاه ليست شاملة. تختبر "مجموعة أدوات اختبار التوافق" (CTS) أجزاءً مهمة من النظام الأساسي للتأكّد من توافقه مع السلوكيات، ولكن ليس كل الأجزاء. يتحمّل المطوّر مسؤولية ضمان التوافق السلوكي مع "مشروع Android المفتوح المصدر". لهذا السبب، على مطوّري الأجهزة استخدام الرمز المصدر المتاح من خلال "مشروع مفتوح المصدر لنظام Android" حيثما أمكن ذلك، بدلاً من إعادة تنفيذ أجزاء كبيرة من النظام.

‫3.5.1. قيود التطبيق

إذا كانت عمليات تنفيذ الأجهزة تنفّذ آلية خاصة لتقييد التطبيقات (مثل تغيير أو تقييد سلوكيات واجهة برمجة التطبيقات الموضّحة في حزمة تطوير البرامج) وكانت هذه الآلية أكثر تقييدًا من حزمة التطبيقات المقيدة في وضع الاستعداد، عليها استيفاء ما يلي:

[C-1-1] يجب السماح للمستخدم بالاطّلاع على قائمة التطبيقات المحظورة.
[C-1-2] يجب توفير إمكانية للمستخدم لتفعيل أو إيقاف جميع القيود الخاصة بكل تطبيق.
[C-1-3] يجب عدم تطبيق هذه القيود الخاصة تلقائيًا بدون دليل على حدوث سلوك غير سليم في صحة النظام، ولكن يجوز تطبيق القيود على التطبيقات عند رصد سلوك غير سليم في صحة النظام، مثل عمليات التنشيط التي لا تنتهي، والخدمات التي تعمل لفترة طويلة، وغيرها من المعايير. يمكن لمصنّعي الأجهزة تحديد المعايير، ولكن يجب أن تكون مرتبطة بتأثير التطبيق في سلامة النظام. يجب عدم استخدام معايير أخرى لا تتعلّق بشكل مباشر بصحة النظام، مثل عدم رواج التطبيق في السوق.
[C-1-4] يجب عدم تطبيق هذه القيود الخاصة تلقائيًا على التطبيقات عندما يوقف المستخدم قيود التطبيقات يدويًا، ويجوز اقتراح تطبيق هذه القيود الخاصة على المستخدم.
[C-1-5] يجب إبلاغ المستخدمين في حال تطبيق هذه القيود الخاصة على أحد التطبيقات تلقائيًا. يجب تقديم هذه المعلومات خلال فترة 24 ساعة قبل تطبيق هذه القيود الخاصة.
[C-1-6] يجب أن تعرض القيمة "صحيح" للطريقة ActivityManager.isBackgroundRestricted()‎ لأي طلبات من واجهة برمجة التطبيقات من أحد التطبيقات.
[C-1-7] يجب عدم حظر التطبيق الذي يستخدمه المستخدم بشكل صريح والذي يظهر في المقدّمة.
[C-1-8] يجب تعليق هذه القيود الخاصة على التطبيق عندما يبدأ المستخدم في استخدام التطبيق بشكل صريح، ما يجعله التطبيق الأهم في المقدّمة.
[C-1-10] يجب توفير مستند أو موقع إلكتروني متاح للجميع وواضح يصف كيفية تطبيق القيود الخاصة. يجب أن يكون هذا المستند أو الموقع الإلكتروني قابلاً للربط من مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android، ويجب أن يتضمّن ما يلي:
- شروط تفعيل القيود الخاصة
- ما هي القيود التي يمكن فرضها على التطبيق وكيفية فرضها؟
- كيف يمكن استثناء تطبيق من هذه القيود؟
- كيف يمكن للتطبيق طلب إعفاء من القيود الخاصة، إذا كان يتيح هذا الإعفاء للتطبيقات التي يمكن للمستخدم تثبيتها؟

إذا كان التطبيق مثبَّتًا مسبقًا على الجهاز ولم يستخدمه أي مستخدم بشكل صريح لأكثر من 30 يومًا، يتم استثناء [C-1-3] و[C-1-5].

إذا كانت عمليات تنفيذ الأجهزة توسّع قيود التطبيقات التي يتم تنفيذها في مشروع Android مفتوح المصدر (AOSP)، يجب أن:

[C-2-1]يجب اتّباع عملية التنفيذ الموضّحة في هذا المستند.

‫3.5.2. إسبات التطبيق

إذا كانت عمليات تنفيذ الأجهزة تتضمّن ميزة "وضع التطبيق في السبات" المضمّنة في مشروع Android مفتوح المصدر (AOSP) أو توسّع الميزة المضمّنة في مشروع Android مفتوح المصدر (AOSP)، يجب أن تستوفي ما يلي:

[C-1-1] يجب استيفاء جميع المتطلبات الواردة في القسم 3.5.1 باستثناء [C-1-6] و[C-1-3].
[C-1-2] يجب ألا يتم تطبيق القيود على التطبيق للمستخدم إلا عند توفّر دليل على أنّ المستخدم لم يستخدم التطبيق لفترة زمنية معيّنة. ننصح بشدة بأن تكون هذه المدة شهرًا واحدًا أو أكثر. يجب أن يتم تحديد الاستخدام من خلال تفاعل المستخدم الصريح عبر واجهة برمجة التطبيقات UsageStats#getLastTimeVisible()‎ أو أي شيء يؤدي إلى خروج التطبيق من حالة الإيقاف الإجباري، بما في ذلك عمليات ربط الخدمات وعمليات ربط موفّر المحتوى وعمليات البث الصريحة وما إلى ذلك، والتي سيتم تتبُّعها من خلال واجهة برمجة تطبيقات جديدة UsageStats#getLastTimeAnyComponentUsed().
[C-1-3] يجب ألا يتم تطبيق القيود التي تؤثر في جميع مستخدمي الجهاز إلا عند توفّر دليل على أنّ أي مستخدم لم يستخدِم الحزمة لفترة زمنية معيّنة. ننصح بشدة بأن تكون هذه المدة شهرًا واحدًا أو أكثر.
[C-1-4] يجب ألا يؤدي إلى عدم استجابة التطبيق لأهداف النشاط أو عمليات ربط الخدمات أو طلبات موفّر المحتوى أو عمليات البث الواضحة.

تستوفي ميزة "وضع التطبيق في سبات" في AOSP المتطلبات المذكورة أعلاه.

‫3.6. مساحات أسماء واجهة برمجة التطبيقات

يتّبع نظام التشغيل Android اصطلاحات مساحة الاسم الخاصة بالحزمة والفئة المحدّدة في لغة البرمجة Java. لضمان التوافق مع التطبيقات التابعة لجهات خارجية، يجب ألا يجري مطوّرو الأجهزة أي تعديلات محظورة (يُرجى الاطّلاع على ما يلي) على مساحات أسماء الحِزم هذه:

java.*
javax.*
sun.*
android.*
androidx.*
com.android.*

أي أنّها:

[C-0-1] يجب عدم تعديل واجهات برمجة التطبيقات المتاحة للجميع على نظام Android الأساسي من خلال تغيير أي توقيعات للطرق أو الفئات، أو من خلال إزالة الفئات أو حقول الفئات.
[C-0-2] يجب عدم إضافة أي عناصر مكشوفة بشكل علني (مثل الفئات أو الواجهات أو الحقول أو الطرق إلى الفئات أو الواجهات الحالية) أو واجهات برمجة التطبيقات Test أو System إلى واجهات برمجة التطبيقات في مساحات الأسماء المذكورة أعلاه. "العنصر المعروض بشكل علني" هو أي بنية غير مزيّنة بعلامة "@hide" كما هو مستخدَم في رمز المصدر العلوي لنظام Android.

يجوز لمطوّري الأجهزة تعديل التنفيذ الأساسي لواجهات برمجة التطبيقات، ولكن يجب أن تستوفي هذه التعديلات الشروط التالية:

[C-0-3] يجب ألا تؤثر في السلوك المحدّد وتوقيع لغة Java لأي واجهات برمجة تطبيقات متاحة للجميع.
[C-0-4] يجب عدم الإعلان عنها أو عرضها بأي شكل آخر للمطوّرين.

ومع ذلك، يجوز لمطوّري الأجهزة إضافة واجهات برمجة تطبيقات مخصّصة خارج مساحة الاسم العادية لنظام Android، ولكن يجب أن تستوفي واجهات برمجة التطبيقات المخصّصة ما يلي:

[C-0-5] يجب ألا يكون في مساحة اسم تملكها مؤسسة أخرى أو تشير إليها. على سبيل المثال، يجب ألا يضيف مطوّرو الأجهزة واجهات برمجة تطبيقات إلى مساحة الاسم com.google.* أو مساحة اسم مشابهة، ويجب أن تقتصر إضافة هذه الواجهات على Google فقط. وبالمثل، يجب ألا تضيف Google واجهات برمجة تطبيقات إلى مساحات الأسماء الخاصة بالشركات الأخرى.
[C-0-6] يجب أن يتم تجميعها في مكتبة Android مشترَكة حتى لا تتأثر التطبيقات التي تستخدمها صراحةً (من خلال آلية <uses-library>) بزيادة استخدام الذاكرة لواجهات برمجة التطبيقات هذه.

يجوز لمصنّعي الأجهزة إضافة واجهات برمجة تطبيقات مخصّصة بلغات أصلية خارج واجهات برمجة التطبيقات في حزمة تطوير البرامج الأصلية (NDK)، ولكن يجب أن تستوفي واجهات برمجة التطبيقات المخصّصة الشروط التالية:

[C-1-1] يجب ألا يكون في مكتبة NDK أو مكتبة تملكها مؤسسة أخرى على النحو الموضّح هنا.

إذا اقترح أحد مطوّري الأجهزة تحسين أحد أسماء نطاقات الحِزم المذكورة أعلاه (مثل إضافة وظيفة جديدة مفيدة إلى واجهة برمجة تطبيقات حالية أو إضافة واجهة برمجة تطبيقات جديدة)، على المطوّر الانتقال إلى source.android.com وبدء عملية المساهمة في التغييرات والرموز البرمجية وفقًا للمعلومات الواردة في هذا الموقع الإلكتروني.

يُرجى العِلم أنّ القيود الواردة أعلاه تتوافق مع الاتفاقيات المعيارية لتسمية واجهات برمجة التطبيقات في لغة البرمجة Java، ويهدف هذا القسم ببساطة إلى تعزيز هذه الاتفاقيات وجعلها ملزمة من خلال تضمينها في تعريف التوافق هذا.

‫3.7. التوافق مع وقت التشغيل

عمليات تنفيذ الجهاز:

[C-0-1] يجب أن تتوافق مع تنسيق Dalvik Executable (DEX) الكامل ومواصفات وتركيبات Dalvik bytecode.
[C-0-2] يجب ضبط أوقات تشغيل Dalvik لتخصيص الذاكرة وفقًا لمنصة Android الأصلية، وكما هو محدّد في الجدول التالي. (راجِع الفقرة 7.1.1 للتعرّف على تعريفات حجم الشاشة وكثافة الشاشة).
يجب استخدام Android RunTime (ART)، وهو التنفيذ المرجعي المسبق لتنسيق Dalvik التنفيذي، ونظام إدارة الحِزم المرجعي.
يجب إجراء اختبارات التشويش في أوضاع تنفيذ مختلفة وتصاميم مستهدَفة لضمان ثبات وقت التشغيل. يمكنك الرجوع إلى JFuzz وDexFuzz في الموقع الإلكتروني لمشروع مفتوح المصدر لنظام Android.

يُرجى العِلم أنّ قيم الذاكرة المحدّدة أدناه تُعدّ قيمًا دنيا، ويجوز لعمليات تنفيذ الأجهزة تخصيص المزيد من الذاكرة لكل تطبيق.

تنسيق الشاشة	كثافة الشاشة	الحد الأدنى لذاكرة التطبيق
ساعة Android	‫120 نقطة لكل بوصة (ldpi)	‫32 ميغابايت
	‫140 نقطة في البوصة (140dpi)
	‫160 نقطة لكل بوصة (mdpi)
	180 نقطة في البوصة (180dpi)
	‫200 نقطة لكل بوصة (200 نقطة لكل بوصة)
	‫213 نقطة لكل بوصة (tvdpi)
	‫220 نقطة في البوصة (220 نقطة في البوصة)	‫36 ميغابايت
	‫240 نقطة في البوصة (hdpi)
	280 نقطة في البوصة (280dpi)
	320 نقطة لكل بوصة (xhdpi)	‫48 ميغابايت
	360 نقطة في البوصة (360dpi)	‫48 ميغابايت
	‫400 نقطة لكل بوصة (400dpi)	‫56 ميغابايت
	420 نقطة لكل بوصة (420dpi)	‫64 ميغابايت
	480 نقطة لكل بوصة (xxhdpi)	‫88 ميغابايت
	‫560 نقطة في البوصة (560dpi)	‫112 ميغابايت
	640 نقطة لكل بوصة (xxxhdpi)	‫154 ميغابايت
صغير/عادي	‫120 نقطة لكل بوصة (ldpi)	‫32 ميغابايت
	‫140 نقطة في البوصة (140dpi)
	‫160 نقطة لكل بوصة (mdpi)
	180 نقطة في البوصة (180dpi)	‫48 ميغابايت
	‫200 نقطة لكل بوصة (200 نقطة لكل بوصة)
	‫213 نقطة لكل بوصة (tvdpi)
	‫220 نقطة في البوصة (220 نقطة في البوصة)
	‫240 نقطة في البوصة (hdpi)
	280 نقطة في البوصة (280dpi)
	320 نقطة لكل بوصة (xhdpi)	‫80 ميغابايت
	360 نقطة في البوصة (360dpi)	‫80 ميغابايت
	‫400 نقطة لكل بوصة (400dpi)	‫96 ميغابايت
	420 نقطة لكل بوصة (420dpi)	‫112 ميغابايت
	480 نقطة لكل بوصة (xxhdpi)	‫128 ميغابايت
	‫560 نقطة في البوصة (560dpi)	‫192 ميغابايت
	640 نقطة لكل بوصة (xxxhdpi)	‫256 ميغابايت
كبير	‫120 نقطة لكل بوصة (ldpi)	‫32 ميغابايت
	‫140 نقطة في البوصة (140dpi)	‫48 ميغابايت
	‫160 نقطة لكل بوصة (mdpi)	‫48 ميغابايت
	180 نقطة في البوصة (180dpi)	‫80 ميغابايت
	‫200 نقطة لكل بوصة (200 نقطة لكل بوصة)
	‫213 نقطة لكل بوصة (tvdpi)
	‫220 نقطة في البوصة (220 نقطة في البوصة)
	‫240 نقطة في البوصة (hdpi)
	280 نقطة في البوصة (280dpi)	‫96 ميغابايت
	320 نقطة لكل بوصة (xhdpi)	‫128 ميغابايت
	360 نقطة في البوصة (360dpi)	‫160 ميغابايت
	‫400 نقطة لكل بوصة (400dpi)	‫192 ميغابايت
	420 نقطة لكل بوصة (420dpi)	‫228 ميغابايت
	480 نقطة لكل بوصة (xxhdpi)	‫256 ميغابايت
	‫560 نقطة في البوصة (560dpi)	‫384 ميغابايت
	640 نقطة لكل بوصة (xxxhdpi)	‫512 ميغابايت
كبير جدًا	‫120 نقطة لكل بوصة (ldpi)	‫48 ميغابايت
	‫140 نقطة في البوصة (140dpi)	‫80 ميغابايت
	‫160 نقطة لكل بوصة (mdpi)	‫80 ميغابايت
	180 نقطة في البوصة (180dpi)	‫96 ميغابايت
	‫200 نقطة لكل بوصة (200 نقطة لكل بوصة)
	‫213 نقطة لكل بوصة (tvdpi)
	‫220 نقطة في البوصة (220 نقطة في البوصة)
	‫240 نقطة في البوصة (hdpi)
	280 نقطة في البوصة (280dpi)	‫144 ميغابايت
	320 نقطة لكل بوصة (xhdpi)	‫192 ميغابايت
	360 نقطة في البوصة (360dpi)	‫240 ميغابايت
	‫400 نقطة لكل بوصة (400dpi)	‫288 ميغابايت
	420 نقطة لكل بوصة (420dpi)	‫336 ميغابايت
	480 نقطة لكل بوصة (xxhdpi)	‫384 ميغابايت
	‫560 نقطة في البوصة (560dpi)	‫576 ميغابايت
	640 نقطة لكل بوصة (xxxhdpi)	‫768 ميغابايت

‫3.8. توافق واجهة المستخدم

‫3.8.1. مشغّل التطبيقات (الشاشة الرئيسية)

يتضمّن Android تطبيقًا لتشغيل التطبيقات (الشاشة الرئيسية) ويتيح استخدام تطبيقات تابعة لجهات خارجية بدلاً من تطبيق تشغيل التطبيقات (الشاشة الرئيسية) على الجهاز.

إذا كانت عمليات تنفيذ الأجهزة تسمح للتطبيقات التابعة لجهات خارجية باستبدال الشاشة الرئيسية للجهاز، يجب أن:

[C-1-1] يجب الإفصاح عن ميزة النظام الأساسي android.software.home_screen.
[C-1-2] يجب عرض العنصر AdaptiveIconDrawable عندما يستخدم تطبيق تابع لجهة خارجية العلامة <adaptive-icon> لتوفير الرمز الخاص به، ويتم استدعاء طُرق PackageManager لاسترداد الرموز.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مشغّلاً تلقائيًا يتيح تثبيت اختصارات داخل التطبيق، يجب أن تستوفي ما يلي:

[C-2-1] يجب الإبلاغ عن true في ShortcutManager.isRequestPinShortcutSupported().
[C-2-2] يجب توفير إمكانية طلب موافقة المستخدم قبل إضافة اختصار طلبته التطبيقات من خلال طريقة ShortcutManager.requestPinShortcut() في واجهة برمجة التطبيقات.
[C-2-3] يجب أن تتوافق مع الاختصارات المثبّتة والاختصارات الديناميكية والثابتة كما هو موضّح في صفحة "اختصارات التطبيقات".

في المقابل، إذا كانت عمليات تنفيذ الأجهزة لا تتيح تثبيت الاختصارات داخل التطبيق، يجب أن تستوفي ما يلي:

[C-3-1] يجب الإبلاغ عن false في ShortcutManager.isRequestPinShortcutSupported().

إذا كانت عمليات تنفيذ الأجهزة تنفّذ مشغّلاً تلقائيًا يوفّر وصولاً سريعًا إلى الاختصارات الإضافية التي توفّرها التطبيقات التابعة لجهات خارجية من خلال واجهة برمجة التطبيقات ShortcutManager، يجب أن تستوفي ما يلي:

[C-4-1] يجب أن تتوافق مع جميع ميزات الاختصارات الموثّقة (مثل الاختصارات الثابتة والديناميكية وتثبيت الاختصارات) وأن تنفّذ بالكامل واجهات برمجة التطبيقات لفئة ShortcutManager.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن تطبيق مشغّل تلقائيًا يعرض شارات لرموز التطبيقات، يجب أن تستوفي ما يلي:

[C-5-1] يجب الالتزام بطريقة واجهة برمجة التطبيقات NotificationChannel.setShowBadge(). بعبارة أخرى، اعرض تلميحات مرئية مرتبطة برمز التطبيق إذا تم ضبط القيمة على true، ولا تعرض أي نظام شارات لرموز التطبيقات عندما تكون القيمة false في جميع قنوات الإشعارات الخاصة بالتطبيق.
يجوز تجاوز شارات رموز التطبيقات باستخدام نظام الشارات الخاص بالمصنّع عندما تشير التطبيقات التابعة لجهات خارجية إلى إمكانية استخدام نظام الشارات الخاص بالمصنّع من خلال استخدام واجهات برمجة التطبيقات الخاصة بالمصنّع، ولكن يجب استخدام الموارد والقيم المتوفّرة من خلال واجهات برمجة التطبيقات الخاصة بشارات الإشعارات الموضّحة في حزمة تطوير البرامج (SDK)، مثل واجهة برمجة التطبيقات Notification.Builder.setNumber() وواجهة برمجة التطبيقات Notification.Builder.setBadgeIconType().

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع رموز أحادية اللون، يجب أن تستوفي هذه الرموز الشروط التالية:

[C-6-1] يجب استخدامها فقط عندما يفعّلها المستخدم بشكل صريح (على سبيل المثال، من خلال الإعدادات أو قائمة اختيار الخلفية).

‫3.8.2. التطبيقات المصغَّرة

يتيح نظام التشغيل Android استخدام أدوات التطبيقات التابعة لجهات خارجية من خلال تحديد نوع مكوّن وواجهة برمجة تطبيقات ودورة حياة ذات صلة تتيح للتطبيقات عرض "أداة تطبيق" للمستخدم النهائي.

في حال كانت عمليات تنفيذ الأجهزة تتوافق مع أدوات التطبيقات التابعة لجهات خارجية، يجب أن تستوفي ما يلي:

[C-1-1] يجب الإفصاح عن إمكانية استخدام ميزة النظام الأساسي android.software.app_widgets.
[C-1-2] يجب أن يتضمّن دعمًا مدمجًا لعناصر واجهة المستخدم في التطبيقات وأن يوفّر عناصر واجهة مستخدم تتيح للمستخدمين إضافة عناصر واجهة المستخدم في التطبيقات وتكوينها ومعاينتها وإزالتها وعرضها وتغيير حجمها، ما لم يكن هناك ما يدعو إلى القلق بشأن سلامة المستخدم (مثل تشتيت انتباه السائق).

[C-1-3] يجب أن يكون الجهاز قادرًا على عرض التطبيقات المصغّرة التي تبلغ أبعادها 4 × 4 ضمن حجم الشبكة العادي. يمكنك الاطّلاع على إرشادات تصميم التطبيقات المصغّرة في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android للحصول على التفاصيل.

[C-1-4] يجب أن تتيح عرض معاينات التطبيقات المصغّرة التي يتم إنشاؤها ديناميكيًا.
[C-1-5] يجب أن تتوفّر للمستخدم إمكانية الموافقة على المعاينة قبل إضافة أداة طلبتها التطبيقات من خلال AppWidgetManager.requestPinAppWidget().
[C-1-6] يجب أن يتيح تثبيت التطبيقات المصغّرة داخل التطبيق.
[C-1-7] يجب الإبلاغ عن true مقابل AppWidgetManager.html.isRequestPinAppWidgetSupported().

قد تتيح عرض تطبيقات مصغّرة على شاشة القفل.

إذا كانت عمليات تنفيذ الأجهزة تتيح استخدام أدوات التطبيقات التابعة لجهات خارجية وتثبيت الاختصارات داخل التطبيقات، يجب أن تستوفي ما يلي:

[C-2-1] يجب الإبلاغ عن true في AppWidgetManager.html.isRequestPinAppWidgetSupported().
[C-2-2] يجب أن تتضمّن إمكانية وصول المستخدم التي تطلب منه الموافقة قبل إضافة اختصار طلبته التطبيقات من خلال طريقة AppWidgetManager.requestPinAppWidget() API.

‫3.8.3. الإشعارات

يتضمّن نظام التشغيل Android واجهات برمجة التطبيقات Notification وNotificationManager التي تتيح لمطوّري التطبيقات التابعة لجهات خارجية إرسال إشعارات إلى المستخدمين بشأن الأحداث المهمة وجذب انتباههم باستخدام مكوّنات الأجهزة (مثل الصوت والاهتزاز والضوء) وميزات البرامج (مثل مركز الإشعارات وشريط النظام) في الجهاز.

‫3.8.3.1. عرض الإشعارات

إذا كانت عمليات تنفيذ الأجهزة تسمح للتطبيقات الخارجية بإرسال إشعارات إلى المستخدمين بشأن الأحداث المهمة، يجب أن تستوفي ما يلي:

‫[C-1-1] يجب أن يتيح تلقّي الإشعارات التي تستخدم ميزات الأجهزة، كما هو موضّح في مستندات حزمة تطوير البرامج (SDK)، وبقدر الإمكان مع أجهزة التنفيذ. على سبيل المثال، إذا كان تنفيذ الجهاز يتضمّن جهاز اهتزاز، يجب أن يتم تنفيذ واجهات برمجة التطبيقات الخاصة بالاهتزاز بشكل صحيح. إذا كان أحد الأجهزة لا يتضمّن أجهزة، يجب تنفيذ واجهات برمجة التطبيقات ذات الصلة على أنّها عمليات غير نشطة. يمكنك الاطّلاع على مزيد من التفاصيل حول هذا السلوك في الفقرة 7.
[C-1-2] يجب عرض جميع الموارد (الرموز وملفات الصور المتحركة وما إلى ذلك) المقدَّمة في واجهات برمجة التطبيقات أو في دليل أسلوب الرموز في شريط الحالة/النظام بشكلٍ صحيح، على الرغم من أنّه يجوز توفير تجربة مستخدم بديلة للإشعارات تختلف عن تلك التي يوفّرها التنفيذ المرجعي لنظام التشغيل Android المفتوح المصدر.
[C-1-3] يجب الالتزام بالسلوكيات الموضّحة في واجهات برمجة التطبيقات لتعديل الإشعارات وإزالتها وتجميعها وتنفيذها بشكل صحيح.
[C-1-4] يجب توفير السلوك الكامل لواجهة برمجة التطبيقات NotificationChannel الموثّق في حزمة SDK.
[C-1-5] يجب توفير وسيلة للمستخدم لحظر إشعارات تطبيق معيّن تابع لجهة خارجية وتعديلها على مستوى كل قناة وحزمة تطبيق.
[C-1-6] يجب أيضًا توفير أداة تحكّم للمستخدم لعرض قنوات الإشعارات المحذوفة.
[C-1-7] يجب عرض جميع الموارد (الصور والملصقات والرموز وما إلى ذلك) المقدَّمة من خلال Notification.MessagingStyle بشكل صحيح إلى جانب نص الإشعار بدون تفاعل إضافي من المستخدم. على سبيل المثال، يجب عرض جميع الموارد، بما في ذلك الرموز المقدَّمة من خلال android.app.Person، في محادثة جماعية تم ضبطها من خلال setGroupConversation.
[C-SR-1] يُنصح بشدة بتوفير وسيلة للمستخدم للتحكّم في الإشعارات التي يتم عرضها للتطبيقات التي تم منحها إذن "خدمة الاستماع إلى الإشعارات". يجب أن تكون الدقة بحيث يتمكّن المستخدم من التحكّم في أنواع الإشعارات التي يتم نقلها إلى كل مستمع من مستمعي الإشعارات. يجب أن تتضمّن الأنواع الإشعارات "المحادثات" و"التنبيه" و"الصامتة" و "الجارية المهمة".
[C-SR-2] يُنصح بشدة بتوفير وسيلة للمستخدمين لتحديد التطبيقات التي سيتم استبعادها من إرسال أي إشعار إلى أي مستمع إشعارات محدّد.
[C-SR-3] يُنصح بشدة بعرض أداة تحكّم تلقائيًا للمستخدم لحظر إشعارات تطبيق معيّن تابع لجهة خارجية على مستوى كل قناة وحزمة تطبيق بعد أن يرفض المستخدم هذا الإشعار عدة مرات.
يجب أن يتيح عرض الإشعارات الغنية بصريًا.
يجب عرض بعض الإشعارات ذات الأولوية الأعلى كتنبيهات.
يجب أن يتضمّن وسيلة تحكّم للمستخدم لتأجيل الإشعارات.
يمكن أن تدير MAY فقط مستوى رؤية التطبيقات التابعة لجهات خارجية وتوقيت إرسالها إشعارات إلى المستخدمين بشأن الأحداث المهمة، وذلك للحدّ من مشاكل السلامة، مثل تشتيت انتباه السائق.

يتيح الإصدار 11 من نظام التشغيل Android استخدام إشعارات المحادثات، وهي إشعارات تستخدم MessagingStyle وتوفّر معرّف اختصار جهات اتصال منشور.

عمليات تنفيذ الجهاز:

[C-SR-4] يُنصح بشدة بتجميع وعرض conversation notifications قبل الإشعارات غير المتعلقة بالمحادثات، باستثناء إشعارات الخدمات التي تعمل في المقدّمة بشكل مستمر وإشعارات importance:high.

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع conversation notifications، وكان التطبيق يوفّر البيانات المطلوبة لـ bubbles، فإنّه:

[C-SR-5] يُنصح بشدة بعرض هذه المحادثة كفقاعة. تستوفي عملية التنفيذ في AOSP هذه المتطلبات باستخدام واجهة مستخدم النظام و"الإعدادات" و"مشغّل التطبيقات" التلقائية.

في حال كانت عمليات تنفيذ الأجهزة تتيح الإشعارات المنسّقة، يجب أن:

[C-2-1] يجب استخدام الموارد نفسها تمامًا كما هو موفّر من خلال فئة Notification.Style لواجهة برمجة التطبيقات وفئاتها الفرعية لعناصر الموارد المعروضة.
يجب أن يعرض كل عنصر من عناصر الموارد (مثل الرمز والعنوان ونص الملخّص) المحدّد في فئة واجهة برمجة التطبيقات Notification.Style وفئاتها الفرعية.

الإشعارات العاجلة هي إشعارات يتم عرضها للمستخدم فور وصولها بشكل مستقل عن السطح الذي يتفاعل معه المستخدم. في حال كانت عمليات تنفيذ الأجهزة تتيح الإشعارات المنبثقة، يجب أن تستوفي ما يلي:

[C-3-1] يجب استخدام عرض الإشعارات المنبثقة والموارد كما هو موضّح في فئة واجهة برمجة التطبيقات Notification.Builder عند عرض الإشعارات المنبثقة.
[C-3-2] يجب عرض الإجراءات المقدَّمة من خلال Notification.Builder.addAction() مع محتوى الإشعار بدون تفاعل إضافي من المستخدم على النحو الموضّح في حزمة تطوير البرامج (SDK).

‫3.8.3.2. خدمة تلقّي الإشعارات الصوتية

يتضمّن نظام التشغيل Android واجهات برمجة التطبيقات NotificationListenerService التي تسمح للتطبيقات (بعد أن يفعّلها المستخدم بشكل صريح) بتلقّي نسخة من جميع الإشعارات عند نشرها أو تعديلها.

عمليات تنفيذ الجهاز:

[C-0-1] يجب تعديل الإشعارات بالكامل بشكل صحيح وفوري في جميع الخدمات المثبَّتة والمفعَّلة من قِبل المستخدم، بما في ذلك أي وجميع البيانات الوصفية المرفقة بكائن الإشعار.
[C-0-2] يجب أن يستجيب snoozeNotification() لطلب البيانات من واجهة برمجة التطبيقات، وأن يغلق الإشعار ويُجري عملية ردّ بعد مدة الغفوة المحدّدة في طلب البيانات من واجهة برمجة التطبيقات.

إذا كانت عمليات تنفيذ الأجهزة توفّر للمستخدم إمكانية تأجيل الإشعارات، يجب أن:

[C-1-1] يجب أن تعكس حالة الإشعار المؤجّل بشكل صحيح من خلال واجهات برمجة التطبيقات العادية، مثل NotificationListenerService.getSnoozedNotifications().
[C-1-2] يجب توفير أداة التحكم هذه للمستخدمين لتأجيل الإشعارات الواردة من كل تطبيق مثبَّت تابع لجهة خارجية، ما لم تكن هذه الإشعارات واردة من خدمات مستمرة أو تعمل في المقدّمة.

‫3.8.3.3. وضع "عدم الإزعاج" / وضع الأولوية

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع ميزة "عدم الإزعاج" (المعروفة أيضًا باسم "وضع الأولوية")، يجب أن تستوفي ما يلي:

[C-1-1] يجب أن يعرض الجهاز قواعد "عدم الإزعاج" التلقائية التي أنشأتها التطبيقات إلى جانب القواعد التي أنشأها المستخدم والقواعد المحدّدة مسبقًا، وذلك عندما يوفّر الجهاز للمستخدم وسيلة لمنح التطبيقات التابعة لجهات خارجية أو رفض منحها إذن الوصول إلى إعدادات سياسة "عدم الإزعاج".
[C-1-3] يجب الالتزام بقيم suppressedVisualEffects التي تم تمريرها مع NotificationManager.Policy، وإذا ضبط أحد التطبيقات أيًا من العلامتَين SUPPRESSED_EFFECT_SCREEN_OFF أو SUPPRESSED_EFFECT_SCREEN_ON، يجب أن يشير إلى المستخدم بأنّه تم إيقاف التأثيرات المرئية في قائمة إعدادات "عدم الإزعاج".

‫3.8.3.4. حماية الإشعارات الحساسة

تشمل معلومات الإشعارات الحسّاسة محتوًى مثل كلمات المرور الصالحة لمرة واحدة ورموز التأكيد الصالحة لمرة واحدة ورموز المصادقة أو إعادة الضبط المشابهة التي يمكن أن تظهر في الإشعارات للمستخدمين.

[C-1-1] يجب إخفاء معلومات الإشعارات الحسّاسة عند نقلها إلى خدمات الاستماع إلى الإشعارات، ما لم تكن خدمة الاستماع إحدى الخدمات التالية:
- تطبيقات النظام الموقَّعة التي تحمل قيمة uid < 10000
- واجهة مستخدِم النظام
- محارة
- تطبيق الجهاز المصاحب المحدّد (المحدّد بواسطة CompanionDeviceManager)
- دور SYSTEM_AUTOMOTIVE_PROJECTION
- دور SYSTEM_NOTIFICATION_INTELLIGENCE
- دور HOME

يُعد تنفيذ NotificationAssistantServices في AOSP مثالاً على استيفاء هذه المتطلبات. يمكنك الاطّلاع على android.ext.services.notification للحصول على مثال.

‫4.8.3. واجهات برمجة التطبيقات الخاصة بالمساعدة

يتضمّن نظام التشغيل Android واجهات برمجة التطبيقات الخاصة بالمساعد للسماح للتطبيقات بتحديد مقدار المعلومات التي تتم مشاركتها مع المساعد على الجهاز من السياق الحالي.

إذا كانت عمليات تنفيذ الأجهزة تتيح إجراء "المساعدة"، فإنّها:

[C-2-1] يجب أن يوضّح للمستخدم النهائي بوضوح متى تتم مشاركة السياق، وذلك من خلال إحدى الطريقتَين التاليتَين:
- في كل مرة يصل فيها التطبيق المساعد إلى السياق، سيتم عرض ضوء أبيض حول حواف الشاشة لمدة تزيد عن مدة سطوع الضوء في تطبيق Android Open Source Project أو تساويهما.
- بالنسبة إلى تطبيق المساعد المثبَّت مسبقًا، يجب توفير تلميحات مرئية للمستخدم لا تتطلّب أكثر من خطوتَي تنقّل للوصول إلى قائمة إعدادات تطبيق المساعد وإدخال الصوت التلقائي، ومشاركة السياق فقط عندما يستدعي المستخدم تطبيق المساعد بشكل صريح من خلال كلمة مفتاحية أو مفتاح تنقّل خاص بالمساعدة.

[C-2-1] يجب مشاركة السياق مع تطبيق المساعدة فقط عندما يستدعي المستخدم التطبيق بشكل صريح من خلال مفتاح التنقّل الخاص بالمساعدة أو كلمة مفتاحية أو نقطة دخول أخرى محدّدة.

[C-2-2] يجب أن يؤدي التفاعل المحدّد لتشغيل تطبيق المساعدة على النحو الموضّح في الفقرة 7.2.3 إلى تشغيل تطبيق المساعدة الذي اختاره المستخدم، أي التطبيق الذي ينفّذ VoiceInteractionService أو نشاط يعالج الغرض ACTION_ASSIST.

‫3.8.5. التنبيهات والإشعارات المؤقتة

يمكن للتطبيقات استخدام واجهة برمجة التطبيقات Toast لعرض سلاسل قصيرة غير مشروطة للمستخدم النهائي تختفي بعد فترة وجيزة، واستخدام واجهة برمجة التطبيقات لنوع النافذة TYPE_APPLICATION_OVERLAY لعرض نوافذ التنبيهات كتراكب على التطبيقات الأخرى.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة أو إخراج فيديو، يجب أن تستوفي ما يلي:

[C-1-1] يجب توفير وسيلة تحكّم للمستخدم لحظر تطبيق من عرض نوافذ تنبيه تستخدم TYPE_APPLICATION_OVERLAY. يتوافق تطبيق AOSP مع هذا الشرط من خلال توفير عناصر تحكّم في مركز الإشعارات.
[C-1-2] يجب الالتزام بواجهة برمجة التطبيقات Toast وعرض إشعارات Toast من التطبيقات للمستخدمين النهائيين بطريقة واضحة جدًا.

‫3.8.6. المظاهر

يوفّر نظام التشغيل Android "السمات" كآلية لتطبيق الأنماط على مستوى تطبيق أو نشاط بأكمله.

يتضمّن نظام التشغيل Android مجموعة من أنماط "Holo" و "Material" المحدّدة التي يمكن لمطوّري التطبيقات استخدامها إذا كانوا يريدون مطابقة مظهر وخصائص تصميم Holo كما هو محدّد في حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة أو إخراج فيديو، يجب أن تستوفي ما يلي:

[C-1-1] يجب عدم تغيير أي من سمات مظهر Holo المتاحة للتطبيقات.
[C-1-2] يجب أن يتوافق مع مجموعة سمات "Material"، ويجب ألّا يغيّر أيًا من سمات Material أو مواد العرض التي يتم عرضها للتطبيقات.
[C-1-3] يجب إما ضبط عائلة الخط "sans-serif" على Roboto الإصدار 2.x للغات التي تتوافق مع Roboto، أو توفير وسيلة تتيح للمستخدم تغيير الخط المستخدَم لعائلة الخط "sans-serif" إلى Roboto الإصدار 2.x للغات التي تتوافق مع Roboto.
[C-1-4] يجب إنشاء لوحات ألوان ديناميكية كما هو محدّد في مستندات AOSP الخاصة بـ Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (راجِع android.theme.customization.system_palette وandroid.theme.customization.theme_style).
[C-1-5] يجب إنشاء لوحات ألوان ديناميكية باستخدام أنماط نسق الألوان المذكورة في مستندات Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (راجِع android.theme.customization.theme_styles)، وهي TONAL_SPOT وVIBRANT وEXPRESSIVE وSPRITZ وRAINBOW وFRUIT_SALAD وMONOCHROMATIC.

"لون المصدر" المستخدَم لإنشاء لوحات ألوان ديناميكية عند إرسالها مع android.theme.customization.system_palette (كما هو موضّح في Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES).
[C-1-6] يجب أن تتضمّن قيمة صفاء CAM16 تبلغ 5 أو أكثر.
- يجب أن يتم استخلاصها من الخلفية عبر com.android.systemui.monet.ColorScheme#getSeedColors، التي توفّر ألوان مصدر متعددة صالحة للاختيار من بينها.
- يجب استخدام القيمة 0xFF1B6EF3 إذا لم يستوفِ أي من الألوان المقدَّمة متطلبات لون المصدر المذكورة أعلاه.

يتضمّن Android أيضًا مجموعة مظاهر "الإعدادات التلقائية للجهاز" باعتبارها مجموعة من الأنماط المحدّدة التي يمكن لمطوّري التطبيقات استخدامها إذا كانوا يريدون أن تتطابق مع شكل ومظهر مظهر الجهاز كما يحدّده منفّذ الجهاز.

يمكن أن تعدّل عمليات تنفيذ الجهاز سمات المظهر التلقائي للجهاز المتاحة للتطبيقات.

يتيح نظام التشغيل Android مظهرًا مختلفًا يتضمّن أشرطة نظام شفافة، ما يسمح لمطوّري التطبيقات بملء المساحة خلف شريطَي الحالة والتنقّل بمحتوى تطبيقاتهم. لضمان توفير تجربة متسقة للمطوّرين في هذا الإعداد، من المهم الحفاظ على نمط رمز شريط الحالة في جميع عمليات تنفيذ الأجهزة المختلفة.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شريط حالة النظام، يجب أن:

[C-2-1] يجب استخدام اللون الأبيض لرموز حالة النظام (مثل قوة الإشارة ومستوى البطارية) والإشعارات الصادرة عن النظام، ما لم يشِر الرمز إلى حالة إشكالية أو يطلب تطبيق شريط حالة فاتحًا باستخدام العلامة WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS.
[C-2-2] يجب أن تغيّر عمليات تنفيذ أجهزة Android لون رموز حالة النظام إلى الأسود (للحصول على التفاصيل، يُرجى الرجوع إلى R.style) عندما يطلب أحد التطبيقات شريط حالة فاتحًا.

‫3.8.7. خلفيات متحركة

يحدّد نظام التشغيل Android نوعًا من المكوّنات وواجهة برمجة تطبيقات ودورة حياة ذات صلة تتيح للتطبيقات عرض "خلفيات متحركة" واحدة أو أكثر للمستخدم النهائي. خلفيات الشاشة المتحركة هي رسومات متحركة أو أنماط أو صور مشابهة تتضمّن إمكانات إدخال محدودة وتظهر كخلفية شاشة خلف التطبيقات الأخرى.

يُعدّ الجهاز مزوّدًا بمكونات مادية قادرة على تشغيل الخلفيات المتحركة بشكل موثوق إذا كان بإمكانه تشغيل جميع الخلفيات المتحركة بدون أي قيود على الوظائف وبمعدل عرض لقطات معقول بدون أي آثار سلبية على التطبيقات الأخرى. إذا تسبّبت القيود في الأجهزة في تعطُّل الخلفيات و/أو التطبيقات أو حدوث خلل فيها أو استهلاك وحدة المعالجة المركزية أو طاقة البطارية بشكل مفرط أو تشغيلها بمعدلات عرض إطارات منخفضة بشكل غير مقبول، يُعتبر الجهاز غير قادر على تشغيل الخلفية المتحركة. على سبيل المثال، قد تستخدم بعض الخلفيات المتحركة سياق OpenGL 2.0 أو 3.x لعرض محتواها. لن تعمل الخلفية المتحركة بشكل موثوق على الأجهزة التي لا تتوافق مع سياقات OpenGL المتعددة، لأنّ استخدام الخلفية المتحركة لسياق OpenGL قد يتعارض مع التطبيقات الأخرى التي تستخدم أيضًا سياق OpenGL.

يجب أن تتضمّن عمليات تنفيذ الأجهزة التي يمكنها تشغيل الخلفيات المتحركة بشكل موثوق كما هو موضح أعلاه خلفيات متحركة.

في حال تنفيذ الخلفيات المتحركة على الأجهزة، يجب أن تستوفي ما يلي:

[C-1-1] يجب إرسال تقرير عن علامة ميزة النظام الأساسي android.software.live_wallpaper.

‫3.8.8. التبديل بين الأنشطة

يتضمّن رمز المصدر العلوي لنظام التشغيل Android شاشة النظرة العامة، وهي واجهة مستخدم على مستوى النظام للتبديل بين المهام وعرض الأنشطة والمهام التي تم الوصول إليها مؤخرًا باستخدام صورة مصغّرة للحالة الرسومية للتطبيق في اللحظة التي أغلق فيها المستخدم التطبيق آخر مرة.

يمكن أن تؤدي عمليات تنفيذ الأجهزة التي تتضمّن مفتاح التنقّل الخاص بوظيفة "التطبيقات الحديثة" على النحو الموضّح بالتفصيل في الفقرة 7.2.3 إلى تغيير الواجهة.

إذا كانت عمليات تنفيذ الأجهزة التي تتضمّن مفتاح التنقّل الخاص بوظيفة "التطبيقات الحديثة" كما هو موضّح بالتفصيل في القسم 7.2.3 تغيّر الواجهة، عليها استيفاء ما يلي:

‫[C-1-1] يجب أن يتيح عرض 7 أنشطة على الأقل.
يجب أن يعرض على الأقل عناوين 4 أنشطة في المرة الواحدة.
يجب عرض لون التمييز والرمز وعنوان الشاشة في "الملفات الحديثة".
يجب عرض أداة إغلاق ("x")، ولكن يمكن تأخير ذلك إلى أن يتفاعل المستخدم مع الشاشات.
يجب توفير اختصار للتبديل بسهولة إلى النشاط السابق.
يجب أن يؤدي ذلك إلى تشغيل إجراء التبديل السريع بين آخر تطبيقَين تم استخدامهما عند النقر مرّتين على مفتاح وظيفة "التطبيقات الحديثة".
يجب أن يؤدي الضغط مع الاستمرار على مفتاح وظائف "التطبيقات الحديثة" إلى تفعيل وضع النوافذ المتعددة في وضع تقسيم الشاشة، إذا كان متاحًا.
قد يتم عرض العناصر الحديثة المرتبطة كمجموعة تتحرك معًا.
[C-SR-1] يُنصح بشدة باستخدام واجهة مستخدم Android الأصلية (أو واجهة مشابهة تستند إلى الصور المصغّرة) لشاشة النظرة العامة.

‫3.8.9. إدارة الإدخال

يتضمّن Android دعمًا لإدارة الإدخال ودعمًا لمحرّرات طرق الإدخال التابعة لجهات خارجية.

[C-1-1] يجب الإفصاح عن ميزة النظام الأساسي android.software.input_methods وإتاحة واجهات برمجة التطبيقات الخاصة بمحرّك طرق الإدخال (IME) على النحو المحدّد في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

‫3.8.10. وحدة تحكّم الوسائط على شاشة القفل

تم إيقاف واجهة برمجة التطبيقات Remote Control Client API نهائيًا في الإصدار 5.0 من نظام التشغيل Android، وتم استبدالها بنموذج إشعار الوسائط الذي يتيح لتطبيقات الوسائط الدمج مع عناصر التحكّم في التشغيل المعروضة على شاشة القفل.

‫3.8.11. شاشات الاستراحة (المعروفة سابقًا باسم Dreams)

راجِع الفقرة 3.2.3.5 لمعرفة إعدادات نية ضبط شاشات التوقف.

‫3.8.12. الموقع الجغرافي

إذا كانت عمليات تنفيذ الأجهزة تتضمّن أداة استشعار للأجهزة (مثل نظام تحديد المواقع العالمي (GPS)) يمكنها توفير إحداثيات الموقع الجغرافي، يجب أن تستوفي ما يلي:

‫[C-1-2] يجب عرض الحالة الحالية للموقع الجغرافي في قائمة "الموقع الجغرافي" ضمن "الإعدادات".
[C-1-3] يجب عدم عرض أوضاع الموقع الجغرافي في قائمة "الموقع الجغرافي" ضمن "الإعدادات".

‫3.8.13. الرموز الموحّدة والخط

يتيح نظام التشغيل Android استخدام رموز الإيموجي المحدّدة في Unicode 10.0.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة أو إخراج فيديو، يجب أن تستوفي ما يلي:

[C-1-1] يجب أن يكون قادرًا على عرض رموز الإيموجي هذه في شكل رسومات ملوّنة.
[C-1-2] يجب أن يتضمّن ما يلي:
- خط Roboto 2 بأوزان مختلفة، مثل sans-serif-thin وsans-serif-light وsans-serif-medium وsans-serif-black وsans-serif-condensed وsans-serif-condensed-light للغات المتوفّرة على الجهاز
- تغطية كاملة لمعيار Unicode 7.0 للغات اللاتينية واليونانية والسيريلية، بما في ذلك نطاقات Latin Extended A وB وC وD، وجميع الرموز الرسومية في حزمة رموز العملات لمعيار Unicode 7.0.
[C-1-3] يجب عدم إزالة أو تعديل NotoColorEmoji.tff في صورة النظام. (يمكن إضافة خط إيموجي جديد لتجاوز الإيموجي في NotoColorEmoji.tff)
يجب أن تتوافق مع رموز الإيموجي التي تمثّل لون البشرة والعائلات المتنوعة على النحو المحدّد في التقرير الفني رقم 51 الصادر عن Unicode.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن محرر أسلوب إدخال، يجب أن تستوفي ما يلي:

يجب توفير طريقة إدخال للمستخدم لهذه الرموز التعبيرية.

يتيح نظام التشغيل Android عرض خطوط ميانمار. تتوفّر في ميانمار عدة خطوط غير متوافقة مع Unicode، تُعرف باسم "Zawgyi"، لعرض لغات ميانمار.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة اللغة البورمية، يجب أن:

[C-2-1] يجب عرض النص بخط متوافق مع Unicode تلقائيًا، ويجب عدم ضبط خط غير متوافق مع Unicode كخط تلقائي إلا إذا اختاره المستخدم في أداة اختيار اللغة.
‫[C-2-2] يجب أن يتوافق مع خط Unicode وخط غير متوافق مع Unicode إذا كان الجهاز يتيح استخدام خط غير متوافق مع Unicode. يجب ألا يزيل الخط غير المتوافق مع Unicode أو يستبدل خط Unicode.
[C-2-3] يجب عرض النص بخط غير متوافق مع Unicode فقط في حال تحديد رمز لغة يتضمّن رمز البرنامج النصي Qaag (مثلاً، my-Qaag). لا يمكن استخدام أي رموز أخرى للغات أو المناطق وفقًا لمعيار ISO (سواء كانت مخصّصة أو غير مخصّصة أو محجوزة) للإشارة إلى خط غير متوافق مع Unicode في ميانمار. ويمكن لمطوّري التطبيقات ومؤلفي صفحات الويب تحديد my-Qaag كرمز اللغة المحدّد كما يفعلون مع أي لغة أخرى.

‫3.8.14. نوافذ متعدّدة

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية عرض أنشطة متعدّدة في الوقت نفسه، يجب أن تستوفي ما يلي:

[C-1-1] يجب تنفيذ أوضاع النوافذ المتعدّدة هذه وفقًا لسلوك التطبيقات وواجهات برمجة التطبيقات الموضّحة في مستندات دعم وضع النوافذ المتعدّدة الخاصة بحزمة تطوير البرامج(SDK) لنظام التشغيل Android، واستيفاء المتطلبات التالية:
[C-1-2] تمت إزالة هذا الشرط في Android 16.
[C-1-3] يجب عدم توفير وضع تقسيم الشاشة أو وضع النافذة الحرة إذا كان ارتفاع الشاشة أقل من 440 وحدة بكسل مستقلة الكثافة وعرض الشاشة أقل من 440 وحدة بكسل مستقلة الكثافة.
[C-1-4] يجب ألا يتم تغيير حجم النشاط ليصبح أصغر من 220 وحدة بكسل مستقلة الكثافة في أوضاع النوافذ المتعددة باستثناء وضع "نافذة ضمن النافذة".

[C-1-5] يجب عرض المهام التي تتضمّن السمة selfMovable بدرجة عتامة كاملة، مع توفير زخرفة مميّزة وثابتة، مثل شريط العنوان، وطريقة لإغلاق هذه المهام من خلال الزخارف الثابتة.

يجب أن تتوافق عمليات تنفيذ الأجهزة التي تتضمّن حجم شاشة xlarge مع وضع النافذة الحرة.

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع أوضاع النوافذ المتعدّدة ووضع تقسيم الشاشة، يجب أن تستوفي ما يلي:

[C-2-2] يجب اقتصاص النشاط المثبَّت في وضع النوافذ المتعددة على الشاشة المقسّمة، ولكن يجب عرض بعض محتواه إذا كان تطبيق "مشغّل التطبيقات" هو النافذة المركّز عليها.
[C-2-3] يجب الالتزام بالقيم المعلَن عنها AndroidManifestLayout_minWidth وAndroidManifestLayout_minHeight لتطبيق مشغّل التطبيقات التابع لجهة خارجية وعدم تجاهل هذه القيم أثناء عرض بعض محتوى النشاط المثبَّت.

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع أوضاع النوافذ المتعددة ووضع "نافذة ضمن النافذة" للنوافذ المتعددة، يجب أن تستوفي ما يلي:

[C-3-1] يجب تشغيل الأنشطة في وضع النوافذ المتعددة "نافذة ضمن النافذة" عندما يكون التطبيق:
- استهداف المستوى 26 من واجهة برمجة التطبيقات أو المستويات الأعلى والإفصاح عن android:supportsPictureInPicture
- يستهدف المستوى 25 أو أقل لواجهة برمجة التطبيقات ويحدّد كلاً من android:resizeableActivity وandroid:supportsPictureInPicture.
[C-3-2] يجب عرض الإجراءات في SystemUI على النحو المحدّد من خلال نشاط PIP الحالي باستخدام واجهة برمجة التطبيقات setActions().
[C-3-3] يجب أن تتوافق مع نسب العرض إلى الارتفاع الأكبر من أو تساوي 1:2.39 والأصغر من أو تساوي 2.39:1، كما هو محدّد في نشاط "نافذة ضمن النافذة" من خلال واجهة برمجة التطبيقات setAspectRatio().
[C-3-4] يجب استخدام KeyEvent.KEYCODE_WINDOW للتحكّم في نافذة وضع "صورة داخل صورة"، وإذا لم يتم تنفيذ وضع "صورة داخل صورة"، يجب أن يكون المفتاح متاحًا للنشاط في المقدّمة.
[C-3-5] يجب توفير وسيلة تحكّم للمستخدم لحظر تطبيق من العرض في وضع "نافذة ضمن النافذة"، ويستوفي تطبيق AOSP هذا الشرط من خلال توفير عناصر تحكّم في مركز الإشعارات.
[C-3-6] يجب تخصيص الحدّ الأدنى التالي للعرض والارتفاع لنافذة "الصورة داخل الصورة" عندما لا يحدّد التطبيق أي قيمة للسمتَين AndroidManifestLayout_minWidth وAndroidManifestLayout_minHeight:
- يجب أن تخصّص الأجهزة التي تم ضبط Configuration.uiMode فيها على قيمة أخرى غير UI_MODE_TYPE_TELEVISION الحد الأدنى للعرض والارتفاع وهو 108 وحدة بكسل مستقلة عن الكثافة.
- يجب أن تخصّص الأجهزة التي تم ضبط Configuration.uiMode فيها على UI_MODE_TYPE_TELEVISION عرضًا لا يقل عن 240 وحدة بكسل مستقلة عن الكثافة وارتفاعًا لا يقل عن 135 وحدة بكسل مستقلة عن الكثافة.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن أكثر من مساحة عرض واحدة متوافقة مع Android وتتيح هذه المساحات للتطبيقات، يجب أن تستوفي ما يلي:

[C-4-1] يجب أن يتيح وضع النوافذ المتعددة.

في حال توفُّر أوضاع النوافذ المتعدّدة في عمليات تنفيذ الأجهزة، يجب أن تتضمّن ما يلي:

[C-5-1] يجب تنفيذ الإصدار الصحيح من Window Manager Extensions API level كما هو موضّح في WindowManager الإضافات.

‫3.8.15. صورة مقطوعة للشاشة

يتوافق نظام التشغيل Android مع ميزة "الفتحة على الشاشة" كما هو موضّح في مستند حزمة تطوير البرامج (SDK). تحدّد واجهة برمجة التطبيقات DisplayCutout منطقة على حافة الشاشة قد لا تكون متاحة للتطبيق بسبب صورة مقطوعة للشاشة أو شاشة منحنية على الحواف.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن فتحات عرض مقطوعة، يجب أن تستوفي ما يلي:

[C-1-5] يجب ألا يحتوي على فتحات إذا كانت نسبة العرض إلى الارتفاع في الجهاز 1.0 (1:1).
[C-1-2] يجب ألا يحتوي على أكثر من فتحة واحدة لكل حافة.
[C-1-3] يجب الالتزام بعلامات صورة مقطوعة للشاشة التي يضبطها التطبيق من خلال واجهة برمجة التطبيقات WindowManager.LayoutParams كما هو موضّح في حزمة تطوير البرامج (SDK).
[C-1-4] يجب عرض قيم صحيحة لجميع مقاييس القطع المحدّدة في واجهة برمجة التطبيقات DisplayCutout.

‫3.8.16. أدوات التحكّم بالجهاز

يتضمّن Android واجهات برمجة التطبيقات ControlsProviderService وControl للسماح للتطبيقات التابعة لجهات خارجية بنشر عناصر تحكّم في الأجهزة تتيح للمستخدمين معرفة الحالة واتخاذ إجراءات بسرعة.

راجِع القسم 2_2_3 لمعرفة المتطلبات الخاصة بالأجهزة.

‫3.8.17. الحافظة

عمليات تنفيذ الجهاز:

[C-0-1] يجب عدم إرسال بيانات الحافظة إلى أي مكوّن أو نشاط أو خدمة أو عبر أي اتصال بالشبكة بدون إجراء صريح من المستخدم (مثل الضغط على زر في التراكب) أو الإشارة إلى أنّه سيتم إرسال المحتوى، باستثناء الخدمات المذكورة في ‫9.8.6 "التقاط المحتوى والبحث داخل التطبيقات".

إذا كانت عمليات تنفيذ الأجهزة تنشئ معاينة مرئية للمستخدم عند نسخ المحتوى إلى الحافظة لأي عنصر ClipData يحتوي فيه ClipData.getDescription().getExtras() على android.content.extra.IS_SENSITIVE، يجب أن تستوفي ما يلي:

[C-1-1] يجب إخفاء المعاينة المرئية للمستخدم

يستوفي التنفيذ المرجعي لنظام التشغيل AOSP متطلبات الحافظة هذه.

‫3.8.18. زر مشاركة الموقع الجغرافي

زر مشاركة الموقع الجغرافي هو أحد عناصر في واجهة المستخدم في Android التي يمكن لمطوّري التطبيقات تضمينها في تطبيقاتهم للحصول على إذن تحديد الموقع الجغرافي الدقيق لجلسة هذا التطبيق.

عمليات تنفيذ الجهاز:

[C-0-1] يجب عدم إضافة خيارات التخصيص المقدَّمة لمطوّري التطبيقات لزر مشاركة الموقع الجغرافي أو تعديلها أو إزالتها.

‫3.9. إدارة الجهاز

يتضمّن نظام التشغيل Android ميزات تتيح لتطبيقات التحكّم في سياسة الجهاز تنفيذ وظائف إدارة الجهاز على مستوى النظام، مثل فرض سياسات كلمات المرور أو محو البيانات عن بُعد، وذلك من خلال واجهات برمجة التطبيقات الخاصة بأداة إدارة سياسة الجهاز.

‫3.9.1. إدارة الجهاز

‫3.9.1.1. توفير الجهاز للمالك

إذا كانت عمليات تنفيذ الأجهزة تعرّف android.software.device_admin، فإنّها:

[C-1-1] يجب أن يتيح تسجيل أداة تحكّم في سياسة الجهاز (DPC) باعتبارها تطبيقًا لمالك الجهاز على النحو الموضّح أدناه:
- عندما لا يتضمّن تنفيذ الجهاز المستخدمين أو بيانات المستخدمين، سيحدث ما يلي:
  - [C-1-5] يجب تسجيل تطبيق DPC كتطبيق "مالك الجهاز" أو تفعيل تطبيق DPC لاختيار ما إذا كان سيصبح تطبيق "مالك الجهاز" أو تطبيق "مالك الملف الشخصي"، إذا كان الجهاز يتيح استخدام تقنية الاتصال القريب المدى (NFC) من خلال علامة الميزة android.hardware.nfc وتلقّى رسالة NFC تتضمّن سجلاً بنوع MIME MIME_TYPE_PROVISIONING_NFC.
  - [C-1-8] يجب إرسال الغرض ACTION_GET_PROVISIONING_MODE بعد بدء عملية توفير الجهاز للمالك، ليتمكّن تطبيق DPC من اختيار ما إذا كان سيصبح مالك الجهاز أو مالك الملف الشخصي، وذلك استنادًا إلى قيم android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES، ما لم يكن من الممكن تحديد خيار واحد صالح فقط من السياق.
  - [C-1-9] يجب إرسال الغرض ACTION_ADMIN_POLICY_COMPLIANCE إلى تطبيق "مالك الجهاز" إذا تم إعداد "مالك الجهاز" أثناء عملية الإعداد بغض النظر عن طريقة الإعداد المستخدَمة. يجب ألا يتمكّن المستخدم من المتابعة في "معالج الإعداد" إلى أن ينتهي تطبيق "مالك الجهاز".
- عندما يتضمّن تنفيذ الجهاز مستخدمين أو بيانات مستخدمين، فإنّه:
  - [C-1-7] يجب عدم تسجيل أي تطبيق لوحدة التحكّم بسياسة الجهاز (DPC) كتطبيق مالك الجهاز بعد الآن.
[C-1-2] تمت إزالة هذا الشرط في Android 15.
[C-2-1] تمت إزالة هذا الشرط في Android 15.
[C-2-2] تمت إزالة هذا الشرط في Android 15.
[C-2-3] تمت إزالة هذا الشرط في Android 15.

‫3.9.1.2. توفير الملف الشخصي المُدار

إذا كانت عمليات تنفيذ الأجهزة تعرّف android.software.managed_users، فإنّها:

[C-1-1] يجب الإفصاح عن android.software.device_admin وتنفيذ واجهات برمجة التطبيقات التي تتيح لتطبيق "وحدة التحكّم بسياسة الجهاز" (DPC) أن يصبح مالك ملف عمل جديد.
[C-1-2] تمت إزالة هذا الشرط في Android 16.
[C-1-3] يجب توفير إمكانات الاستخدام التالية للمستخدمين ضمن "الإعدادات" للإشارة إلى الحالات التي تم فيها إيقاف وظيفة نظام معيّنة من خلال "وحدة التحكّم في سياسة الجهاز" (DPC):
- رمز متسق أو وسيلة أخرى لتسهيل الاستخدام (مثل رمز المعلومات في AOSP) للإشارة إلى أنّ إعدادًا معيّنًا محظور من قِبل مشرف الجهاز
- رسالة شرح موجز، كما يقدّمها "مشرف الجهاز" من خلال setShortSupportMessage.
- رمز تطبيق "سياسة إدارة الجهاز"
[C-1-4] يجب تشغيل معالج الغرض ACTION_PROVISIONING_SUCCESSFUL في ملف العمل إذا تم إنشاء مالك ملف شخصي عند بدء عملية الإعداد من خلال الغرض android.app.action.PROVISION_MANAGED_PROFILE وكانت وحدة التحكّم في سياسة الجهاز قد نفّذت المعالج.
[C-1-5] يجب إرسال البث ACTION_PROFILE_PROVISIONING_COMPLETE إلى وحدة التحكّم بسياسة الجهاز في ملف العمل عند بدء عملية الإعداد من خلال الغرض android.app.action.PROVISION_MANAGED_PROFILE.
[C-1-6] يجب إرسال الغرض ACTION_GET_PROVISIONING_MODE بعد بدء عملية توفير مالك الملف الشخصي، ليتمكّن تطبيق DPC من اختيار ما إذا كان سيصبح مالك الجهاز أو مالك الملف الشخصي، إلا في حال بدء عملية التوفير من خلال الغرض android.app.action.PROVISION_MANAGED_PROFILE.
[C-1-7] يجب إرسال الغرض ACTION_ADMIN_POLICY_COMPLIANCE إلى ملف العمل عند إنشاء "مالك الملف الشخصي" أثناء عملية الإعداد بغض النظر عن طريقة الإعداد المستخدَمة، باستثناء الحالات التي يتم فيها بدء عملية الإعداد من خلال الغرض android.app.action.PROVISION_MANAGED_PROFILE. يجب ألا يتمكّن المستخدم من المتابعة في "معالج الإعداد" إلى أن ينتهي تطبيق Profile Owner.
[C-1-8] يجب إرسال البث ACTION_MANAGED_PROFILE_PROVISIONED إلى DPC في الملف الشخصي عند إنشاء "مالك الملف"، بغض النظر عن طريقة التوفير المستخدَمة.

‫3.9.2. إتاحة الملفات الشخصية المُدارة

إذا كانت عمليات تنفيذ الأجهزة تعرّف android.software.managed_users، فإنّها:

[C-1-1] يجب أن تتوافق مع الملفات الشخصية المُدارة من خلال واجهات برمجة التطبيقات android.app.admin.DevicePolicyManager.
[C-1-2] يجب السماح بإنشاء ملف عمل واحد فقط.
[C-1-3] يجب استخدام شارة رمز (مشابهة لشارة العمل في المصدر العلوي لنظام التشغيل AOSP) لتمثيل التطبيقات والأدوات المُدارة وعناصر واجهة المستخدم الأخرى التي تتضمّن شارات، مثل "التطبيقات الحديثة والإشعارات".
[C-1-4] يجب عرض رمز إشعار (مشابه لشارة AOSP الأصلية) للإشارة إلى أنّ المستخدم يتواجد داخل تطبيق ملف شخصي مُدار.
[C-1-5] يجب عرض إشعار مؤقت يشير إلى أنّ المستخدم في الملف الشخصي المُدار عند تنبيه الجهاز (ACTION_USER_PRESENT) وفي حال كان التطبيق الذي يتم تشغيله في المقدّمة ضمن الملف الشخصي المُدار.
[C-1-6] في حال توفّر ملف شخصي مُدار، يجب عرض تلميحات مرئية في "أداة اختيار" Intent للسماح للمستخدم بإعادة توجيه Intent من ملف شخصي مُدار إلى المستخدم الأساسي أو العكس، إذا كان ذلك مفعّلاً من خلال "وحدة التحكّم في سياسة الجهاز".
[C-1-7] في حال توفّر ملف شخصي مُدار، يجب توفير عناصر تحكّم المستخدم التالية لكل من المستخدم الأساسي والملف الشخصي المُدار:
- تدوين سجلات الاستخدام منفصلة عن استخدام البطارية والموقع الجغرافي وبيانات الجوّال وسعة التخزين المطلوب استخدامها للمستخدِم الأساسي والملف الشخصي المُدار
- إدارة تطبيقات VPN المثبَّتة بشكل مستقل ضمن المستخدم الأساسي أو ملف العمل
- إدارة التطبيقات المثبَّتة بشكل مستقل ضمن المستخدِم الأساسي أو الملف الشخصي المُدار
- إدارة الحسابات بشكل مستقل ضمن الملف الشخصي للمستخدم الأساسي أو الملف المُدار
[C-1-8] يجب التأكّد من أنّ تطبيقات الاتصال وجهات الاتصال والمراسلة المثبّتة مسبقًا يمكنها البحث عن معلومات المتصل والاطّلاع عليها من ملف العمل (إذا كان متوفّرًا) إلى جانب تلك المعلومات من الملف الشخصي الأساسي، وذلك إذا سمح بذلك تطبيق "وحدة التحكّم في سياسة الجهاز".
[C-1-9] يجب التأكّد من استيفاء جميع متطلبات الأمان السارية على جهاز تم تفعيل ميزة "المستخدمون المتعدّدون" عليه (راجِع الفقرة 9.5)، حتى إذا لم يتم احتساب الملف الشخصي الخاضع للإدارة كمستخدم آخر بالإضافة إلى المستخدم الأساسي.
[C-1-10] يجب التأكّد من حفظ بيانات لقطة الشاشة في مساحة تخزين ملف العمل عند أخذ لقطة شاشة باستخدام نافذة topActivity تتضمّن تركيزًا (النافذة التي تفاعل معها المستخدم آخر مرة من بين جميع الأنشطة) وتنتمي إلى تطبيق ملف عمل.
[C-1-11] يجب عدم التقاط أي محتوى آخر من الشاشة (شريط النظام أو الإشعارات أو أي محتوى خاص بالملف الشخصي) باستثناء نافذة/نوافذ تطبيق ملف العمل عند حفظ لقطة شاشة في ملف العمل (لضمان عدم حفظ بيانات الملف الشخصي في ملف العمل).

في حال تضمين عمليات تنفيذ الأجهزة للتعريفين android.software.managed_users وandroid.software.secure_lock_screen، يجب أن تستوفي ما يلي:

[C-2-1] يجب أن تتيح إمكانية تحديد اجتماع منفصل على شاشة القفل يستوفي المتطلبات التالية لمنح إذن الوصول إلى التطبيقات التي تعمل في ملف شخصي مُدار فقط.
- يجب أن تلتزم عمليات تنفيذ الأجهزة بطلب DevicePolicyManager.ACTION_SET_NEW_PASSWORD وتعرض واجهة لإعداد بيانات اعتماد منفصلة لشاشة القفل خاصة بملف العمل المُدار.
- يجب أن تستخدم بيانات اعتماد شاشة القفل للملف الشخصي المُدار آليات تخزين وإدارة بيانات الاعتماد نفسها التي يستخدمها الملف الشخصي الرئيسي، كما هو موضّح في موقع "مشروع Android المفتوح المصدر" الإلكتروني.
- يجب أن تنطبق سياسات كلمات المرور الخاصة بوحدة التحكّم في سياسة الجهاز (DPC) على بيانات اعتماد شاشة القفل للملف الشخصي المُدار فقط، ما لم يتم استدعاء مثيل DevicePolicyManager الذي تم عرضه بواسطة getParentProfileInstance.
عند عرض جهات الاتصال من ملف العمل في سجل المكالمات المثبَّت مسبقًا وواجهة المستخدم أثناء المكالمة والإشعارات بشأن المكالمات الجارية والمكالمات الفائتة وتطبيقات جهات الاتصال والمراسلة، يجب أن يتم تمييزها بالشارة نفسها المستخدَمة للإشارة إلى تطبيقات ملف العمل.

‫3.9.3. دعم المستخدمين المُدارين

إذا كانت عمليات تنفيذ الأجهزة تعرّف android.software.managed_users، فإنّها:

[C-1-1] يجب توفير تلميحات مرئية للمستخدم لتسجيل الخروج من الحساب الحالي والعودة إلى مستخدِم أساسي في جلسة تعدُّد المستخدمين عندما تعرض isLogoutEnabled الرمز true. يجب أن يكون عنصر التحكّم في واجهة المستخدم متاحًا من شاشة القفل بدون الحاجة إلى فتح قفل الجهاز.

إذا كانت عمليات تنفيذ الأجهزة تعرّف android.software.device_admin وتوفّر عنصر تحكّم للمستخدم على الجهاز لإضافة مستخدمين ثانويين إضافيين، عليها استيفاء ما يلي:

[C-SR-1] يُنصح بشدة بعرض إفصاحات الموافقة نفسها الخاصة بـ "مالك الجهاز" في AOSP التي تم عرضها في المسار الذي بدأه android.app.action.PROVISION_MANAGED_DEVICE، قبل السماح بإضافة حسابات في "المستخدم الثانوي" الجديد، ليفهم المستخدمون أنّ الجهاز مُدار.

‫3.9.4. متطلبات دور إدارة سياسات الأجهزة

إذا كانت عمليات تنفيذ الأجهزة تعرّف android.software.device_admin، فإنّها:

[C-1-1] يجب أن يتيح دور إدارة سياسات الأجهزة على النحو المحدّد في القسم 9.1. يمكن تحديد التطبيق الذي يتولّى دور إدارة سياسات الجهاز من خلال ضبط config_devicePolicyManagement على اسم الحزمة. يجب أن يتبع اسم الحزمة نقطتان رأسيتان (:) وشهادة التوقيع، ما لم يكن التطبيق محمَّلاً مسبقًا.

في حال عدم تحديد اسم حزمة config_devicePolicyManagement كما هو موضح أعلاه، سيحدث ما يلي:

[C-2-1] يجب أن تتيح عمليات تنفيذ الأجهزة توفيرها بدون تطبيق لصاحب دور إدارة سياسة الجهاز (يوفر مشروع AOSP تنفيذًا مرجعيًا).

إذا تم تحديد اسم حزمة config_devicePolicyManagement كما هو موضح أعلاه:

[C-3-1] يجب تثبيت التطبيق على جميع الملفات الشخصية للمستخدم.
[C-3-2] يمكن أن تحدّد عمليات تنفيذ الأجهزة تطبيقًا يعدّل حامل دور إدارة سياسة الجهاز قبل توفير الجهاز من خلال ضبط config_devicePolicyManagementUpdater.

في حال تحديد اسم حزمة config_devicePolicyManagementUpdater كما هو موضح أعلاه:

‫[C-4-1] يجب أن يكون التطبيق مثبَّتًا مسبقًا على الجهاز.
[C-4-2] يجب أن ينفّذ التطبيق فلتر أهداف يحلّ android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER.

‫3.9.5. إطار عمل حلّ المشاكل المتعلّقة بسياسات الجهاز

إذا كانت عمليات تنفيذ الأجهزة تعرّف android.software.device_admin، فإنّها:

[C-1-1] يجب حلّ تعارضات سياسات الأجهزة على النحو الموضّح في إطار عمل حلّ تعارضات سياسات الأجهزة.

‫3.10. تسهيل الاستخدام

يوفر نظام التشغيل Android طبقة تسهيل استخدام تساعد المستخدمين الذين يعانون من عجز على التنقّل في أجهزتهم بسهولة أكبر. بالإضافة إلى ذلك، يوفّر نظام التشغيل Android واجهات برمجة تطبيقات للمنصة تتيح تنفيذ خدمات مخصّصة لتسهيل الاستخدام لتلقّي عمليات ردّ الاتصال بشأن أحداث المستخدم والنظام وإنشاء آليات بديلة لتقديم الملاحظات، مثل تحويل النص إلى كلام، والتجاوب الحسّي، والتنقّل باستخدام كرة التعقب أو لوحة التحكم.

في حال كانت عمليات تنفيذ الأجهزة تتوافق مع خدمات تسهيل الاستخدام التابعة لجهات خارجية، يجب أن:

[C-1-1] يجب توفير تنفيذ لإطار عمل تسهيل الاستخدام في Android على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK) الخاصة بواجهات برمجة التطبيقات المتعلقة بتسهيل الاستخدام.
[C-1-2] يجب إنشاء أحداث تسهيل الاستخدام وتقديم AccessibilityEvent المناسب إلى جميع عمليات التنفيذ المسجّلة AccessibilityService كما هو موضّح في حزمة تطوير البرامج (SDK).
[C-1-4] يجب توفير تلميحات مرئية للمستخدمين للتحكّم في خدمات تسهيل الاستخدام التي تحدّد AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON. يُرجى العِلم أنّه بالنسبة إلى عمليات تنفيذ الأجهزة التي تتضمّن شريط تنقّل في النظام، يجب أن تتيح للمستخدم خيار إضافة زر في شريط التنقّل الخاص بالنظام للتحكّم في هذه الخدمات.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن خدمات تسهيل الاستخدام مثبَّتة مسبقًا، يجب أن تستوفي ما يلي:

[C-2-1] يجب تنفيذ خدمات تسهيل الاستخدام المثبَّتة مسبقًا كتطبيقات متوافقة مع ميزة "التشغيل المباشر" عند تشفير مساحة تخزين البيانات باستخدام ميزة "التشفير المستند إلى الملفات" (FBE).
يجب توفير آلية في عملية الإعداد الجاهز للاستخدام تتيح للمستخدمين تفعيل خدمات تسهيل الاستخدام ذات الصلة، بالإضافة إلى خيارات لتعديل حجم الخط وحجم الشاشة وإيماءات التكبير.

‫3.11. تحويل النص إلى كلام

يتضمّن نظام التشغيل Android واجهات برمجة تطبيقات تتيح للتطبيقات الاستفادة من خدمات تحويل النص إلى كلام (TTS)، كما تتيح لمقدّمي الخدمات توفير عمليات تنفيذ لخدمات تحويل النص إلى كلام.

إذا كانت عمليات تنفيذ الأجهزة تُبلغ عن الميزة android.hardware.audio.output، فإنّها:

‫[C-1-1] يجب أن تتوافق مع واجهات برمجة التطبيقات لإطار عمل تحويل النص إلى كلام في Android.

إذا كانت عمليات تنفيذ الأجهزة تتيح تثبيت محركات تحويل النص إلى كلام تابعة لجهات خارجية، يجب أن تستوفي ما يلي:

[C-2-1] يجب توفير إمكانية وصول للمستخدم تتيح له اختيار محرّك تحويل النص إلى كلام لاستخدامه على مستوى النظام.

‫3.12. لا ينطبق

‫3.13. الإعدادات السريعة

يوفر نظام التشغيل Android مكوّن واجهة مستخدم "الإعدادات السريعة" الذي يتيح الوصول السريع إلى الإجراءات التي يتم استخدامها بشكل متكرر أو التي تكون مطلوبة بشكل عاجل.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن أحد مكونات واجهة المستخدم الخاصة بـ "الإعدادات السريعة" وتتيح استخدام "الإعدادات السريعة" التابعة لجهات خارجية، يجب أن تستوفي ما يلي:

[C-1-1] يجب أن تسمح للمستخدم بإضافة أو إزالة المربّعات المقدَّمة من خلال واجهات برمجة التطبيقات quicksettings من تطبيق خارجي.
[C-1-2] يجب عدم إضافة مربّع تلقائيًا من تطبيق خارجي مباشرةً إلى "الإعدادات السريعة".
[C-1-3] يجب عرض جميع المربّعات التي أضافها المستخدم من تطبيقات تابعة لجهات خارجية بجانب مربّعات الإعدادات السريعة التي يوفّرها النظام.

‫3.14. واجهة مستخدم الوسائط

إذا كانت عمليات تنفيذ الأجهزة تتضمّن تطبيقات غير مفعّلة صوتيًا (يُشار إليها باسم "التطبيقات") تتفاعل مع تطبيقات تابعة لجهات خارجية من خلال MediaBrowser أو MediaSession، يجب أن تستوفي التطبيقات ما يلي:

[C-1-2] يجب عرض الرموز التي تم الحصول عليها من خلال getIconBitmap() أو getIconUri() والعناوين التي تم الحصول عليها من خلال getTitle() بوضوح كما هو موضح في MediaDescription. قد يتم تقصير العناوين للامتثال للوائح السلامة (مثل تشتيت انتباه السائق).
[C-1-3] يجب عرض رمز التطبيق التابع لجهة خارجية عند عرض المحتوى المقدَّم من هذا التطبيق.
[C-1-4] يجب أن يسمح التطبيق للمستخدم بالتفاعل مع التدرّج الهرمي الكامل MediaBrowser. يمكن أن تحظر الوصول إلى جزء من التسلسل الهرمي للامتثال للوائح السلامة (مثل تشتيت انتباه السائق)، ولكن يجب ألا تمنح معاملة تفضيلية استنادًا إلى المحتوى أو مقدّم المحتوى.
[C-1-5] يجب اعتبار النقر مرّتين على KEYCODE_HEADSETHOOK أو KEYCODE_MEDIA_PLAY_PAUSE بمثابة KEYCODE_MEDIA_NEXT بالنسبة إلى MediaSession.Callback#onMediaButtonEvent.

‫3.15. التطبيقات الفورية

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع "التطبيقات الفورية"، يجب أن تستوفي المتطلبات التالية:

[C-1-1] يجب ألا تُمنح "التطبيقات الفورية" إلا الأذونات التي تم ضبط قيمة android:protectionLevel على "instant".
[C-1-2] يجب ألا تتفاعل التطبيقات الفورية مع التطبيقات المثبَّتة من خلال النوايا الضمنية إلا في حال استيفاء أحد الشروط التالية:
- يتم عرض فلتر نمط الأهداف الخاص بالمكوّن ويتضمّن CATEGORY_BROWSABLE
- يجب أن يكون الإجراء أحد الإجراءات ACTION_SEND أو ACTION_SENDTO أو ACTION_SEND_MULTIPLE
- يتم عرض الهدف بشكل صريح باستخدام android:visibleToInstantApps
[C-1-3] يجب ألا تتفاعل التطبيقات الفورية بشكل صريح مع التطبيقات المثبَّتة إلا إذا تم عرض المكوّن من خلال android:visibleToInstantApps.
[C-1-4] يجب ألا ترى التطبيقات المثبَّتة تفاصيل حول التطبيقات الفورية على الجهاز ما لم يتصل التطبيق الفوري بالتطبيق المثبَّت بشكل صريح.
يجب أن توفّر عمليات تنفيذ الأجهزة إمكانات المستخدم التالية للتفاعل مع التطبيقات الفورية. يستوفي AOSP المتطلبات باستخدام واجهة مستخدم النظام والإعدادات والمشغّل التلقائيين. عمليات تنفيذ الجهاز:
- [C-1-5] يجب توفير أداة للمستخدم تتيح له عرض التطبيقات الفورية المحفوظة مؤقتًا على الجهاز وحذفها لكل حزمة تطبيق على حدة.
- [C-1-6] يجب توفير إشعار مستمر للمستخدم يمكن تصغيره أثناء تشغيل تطبيق فوري في المقدّمة. يجب أن يتضمّن إشعار المستخدم هذا أنّ "التطبيقات الفورية" لا تتطلّب التثبيت، وأن يوفّر للمستخدم وسيلة تتيح له الانتقال إلى شاشة معلومات التطبيق في "الإعدادات". بالنسبة إلى "التطبيقات الفورية" التي يتم تشغيلها من خلال نوايا الويب، كما هو محدّد باستخدام نية تم ضبط الإجراء فيها على Intent.ACTION_VIEW وبمخطط "http" أو "https"، يجب أن يتيح عنصر تحكّم إضافي للمستخدم عدم تشغيل "التطبيق الفوري" وفتح الرابط المرتبط به باستخدام متصفّح الويب الذي تم ضبطه، إذا كان المتصفّح متاحًا على الجهاز.
- [C-1-7] يجب السماح بالوصول إلى "التطبيقات الفورية" من وظيفة "التطبيقات الحديثة" إذا كانت هذه الوظيفة متاحة على الجهاز.
[C-1-8] يجب التحميل المُسبَق لتطبيق واحد أو أكثر أو لمكوّنات الخدمة مع معالج أهداف للأهداف المُدرَجة في حزمة تطوير البرامج (SDK) هنا وإتاحة الأهداف للتطبيقات الفورية.

‫3.16. إقران الأجهزة المصاحبة

يتيح نظام التشغيل Android إمكانية إقران الأجهزة المصاحبة لإدارة عملية الربط مع الأجهزة المصاحبة بشكل أكثر فعالية، كما يوفّر واجهة برمجة التطبيقات CompanionDeviceManager لتتمكّن التطبيقات من الوصول إلى هذه الميزة.

إذا كانت عمليات تنفيذ الأجهزة تتيح ميزة إقران الأجهزة المرافقة، يجب أن تستوفي ما يلي:

[C-1-1] يجب الإفصاح عن علامة الميزة FEATURE_COMPANION_DEVICE_SETUP.
[C-1-2] يجب التأكّد من تنفيذ واجهات برمجة التطبيقات في حزمة android.companion بشكل كامل.
[C-1-3] يجب توفير وسائل تتيح للمستخدم اختيار/تأكيد توفّر جهاز مصاحب وجاهزيته للتشغيل، ويجب أن تستخدم هذه الوسائل الرسالة نفسها المستخدَمة في مشروع Android مفتوح المصدر (AOSP) بدون إضافة أو تعديل.

3.17. التطبيقات ذات الاستهلاك المكثّف للموارد

إذا كانت عمليات تنفيذ الأجهزة تعرّف الميزة FEATURE_CANT_SAVE_STATE، فإنّها:

[C-1-1] يجب أن يكون هناك تطبيق مثبَّت واحد فقط يحدّد cantSaveState يعمل في النظام في كل مرة. إذا ترك المستخدم تطبيقًا من هذا النوع بدون الخروج منه بشكل صريح (على سبيل المثال، من خلال الضغط على زر الرجوع إلى الشاشة الرئيسية أثناء ترك نشاط نشط في النظام، بدلاً من الضغط على زر الرجوع بدون أن تتبقّى أي أنشطة نشطة في النظام)، يجب أن تعطي عمليات تنفيذ الجهاز الأولوية لهذا التطبيق في ذاكرة الوصول العشوائي (RAM) كما تفعل مع العناصر الأخرى التي يُتوقّع أن تظل قيد التشغيل، مثل الخدمات التي تعمل في المقدّمة. عندما يكون هذا التطبيق يعمل في الخلفية، يمكن للنظام تطبيق ميزات إدارة الطاقة عليه، مثل فرض قيود على وحدة المعالجة المركزية والوصول إلى الشبكة.
[C-1-2] يجب توفير عنصر واجهة مستخدم لاختيار التطبيق الذي لن يشارك في آلية الحفظ/الاستعادة العادية للحالة عند تشغيل المستخدم تطبيقًا ثانيًا تم تعريفه باستخدام السمة cantSaveState.
[C-1-3] يجب عدم تطبيق تغييرات أخرى في السياسة على التطبيقات التي تحدّد cantSaveState، مثل تغيير أداء وحدة المعالجة المركزية أو تغيير أولوية الجدولة.

إذا لم تحدّد عمليات تنفيذ الأجهزة الميزة FEATURE_CANT_SAVE_STATE، فإنّها:

[C-1-1] يجب تجاهل السمة cantSaveState التي تحدّدها التطبيقات، ويجب عدم تغيير سلوك التطبيق استنادًا إلى هذه السمة.

‫3.18. جهات الاتصال

يتضمّن نظام التشغيل Android واجهات برمجة تطبيقات Contacts Provider للسماح للتطبيقات بإدارة معلومات جهات الاتصال المخزّنة على الجهاز. عادةً ما تتم مزامنة بيانات جهات الاتصال التي يتم إدخالها مباشرةً على الجهاز مع خدمة ويب، ولكن قد يتم أيضًا تخزين البيانات محليًا على الجهاز فقط. يُشار إلى جهات الاتصال المخزّنة على الجهاز فقط باسم جهات الاتصال المحلية.

تكون بيانات RawContacts "مرتبطة بـ" أو "مخزّنة في" حساب عندما يتطابق عمودا ACCOUNT_NAME وACCOUNT_TYPE لجهات الاتصال الأولية مع حقلي Account.name وAccount.type المقابلين للحساب.

حساب محلي تلقائي: حساب مخصّص لجهات الاتصال الأولية التي يتم تخزينها على الجهاز فقط ولا تكون مرتبطة بحساب في AccountManager، ويتم إنشاؤها باستخدام قيم null للأعمدة ACCOUNT_NAME وACCOUNT_TYPE.

حساب محلي مخصّص: حساب لجهات الاتصال الأولية المخزّنة على الجهاز فقط وغير المرتبطة بحساب في AccountManager، ويتم إنشاؤه بقيم غير فارغة لكل من العمودين ACCOUNT_NAME وACCOUNT_TYPE.

عمليات تنفيذ الجهاز:

[C-SR-1] يُنصح بشدة بعدم إنشاء حسابات محلية مخصّصة.

إذا كانت عمليات تنفيذ الأجهزة تستخدم حسابًا محليًا مخصّصًا:

[C-1-1] يجب أن تعرض الدالة ACCOUNT_NAME الخاصة بالحساب المحلي المخصّص القيمة ContactsContract.RawContacts.getLocalAccountName
[C-1-2] يجب أن تعرض الدالة ACCOUNT_TYPE، الخاصة بالحساب المحلي المخصّص، القيمة ContactsContract.RawContacts.getLocalAccountType.
[C-1-3] يجب إدراج جهات الاتصال الأولية التي يتم إدراجها بواسطة تطبيقات تابعة لجهات خارجية بدون تحديد حساب في حساب جهات الاتصال التلقائي للجهاز. إذا كان حساب جهات الاتصال التلقائي هو DEFAULT_ACCOUNT_STATE_LOCAL أو DEFAULT_ACCOUNT_STATE_NOT_SET، يجب تخزين جهات الاتصال الأولية هذه في الحساب المحلي المخصّص.
[C-1-4] يجب عدم إزالة جهات الاتصال الأولية التي تم إدراجها في الحساب المحلي المخصّص عند إضافة حسابات أو إزالتها.
[C-1-5] يجب أن تؤدي عمليات الحذف التي يتم تنفيذها على الحساب المحلي المخصّص إلى إزالة جهات الاتصال الأولية على الفور (كما لو تم ضبط المَعلمة CALLER_IS_SYNCADAPTER على "صحيح")، حتى إذا تم ضبط المَعلمة CALLER_IS_SYNCADAPTER على "خطأ" أو لم يتم تحديدها.

حسابات شرائح SIM: حسابات لجهات الاتصال الأولية التي يتم نسخها من واحدة أو أكثر من شرائح SIM الفعلية المُدرَجة في الجهاز والتي لا تكون مرتبطة بحساب في AccountManager

عمليات تنفيذ الجهاز:

في حال استخدام عمليات تنفيذ الأجهزة لحسابات SIM:

[C-1-6] يجب إرجاع حسابات شرائح SIM بحلول ContactsContract.SimContacts.getSimAccounts.

‫3.18.2. أداة اختيار جهات الاتصال المضمّنة في النظام

يتضمّن Android أداة اختيار جهات الاتصال في النظام التي تتيح للتطبيقات الوصول إلى معلومات محدودة عن جهات الاتصال بدون الحاجة إلى أذونات وصول واسعة النطاق.

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع جهات اتصال Android، يجب أن:

[C-1-1] يجب تنفيذ "أداة اختيار جهات الاتصال في النظام" (com.android.contactspicker) للتطبيقات التي تستهدف المستوى 37 من واجهة برمجة التطبيقات أو المستويات الأعلى.
[C-1-2] يجب تنفيذ الغرض Intent.ACTION_PICK_CONTACTS.

‫3.19. إعدادات اللغة

عمليات تنفيذ الجهاز:

[C-0-1] يجب عدم توفير أي تلميحات مرئية للمستخدمين لاختيار معالجة اللغة حسب الجنس في اللغات التي لا تتيح ترجمات حسب الجنس. يمكنك الاطّلاع على مراجع نحوية لمزيد من المعلومات.

‫3.20. التجارب المستندة إلى المساعد الرقمي

يتيح إطار عمل تطوير مساعد Android التحكّم في تطبيقات Android باستخدام الصوت. باستخدام "مساعد Google"، يمكن للمستخدمين استخدام صوتهم لتشغيل التطبيقات وتنفيذ المهام والوصول إلى المحتوى وغير ذلك.

بالنسبة إلى هذا القسم، يُرجى الرجوع إلى التصنيفات التالية لعمليات تنفيذ الأجهزة المتخصّصة:

مستوى الصوت الثابت: الجهاز ذو مستوى الصوت الثابت هو جهاز يتضمّن عناصر تحكّم في مستوى الصوت ولكنّه يمنع التطبيقات من تغيير مستوى بث الصوت باستخدام طرق AudioManager العادية (مثل سيارات Android Automotive OS).
مستوى الصوت الكامل: الجهاز الذي يعمل بمستوى الصوت الكامل هو الجهاز الذي يكون مستوى صوته مضبوطًا على مستوى كامل وغير مخفّض ولا يمكن التحكّم فيه من خلال البرامج (على سبيل المثال، تلفزيون مزوّد بمكبّرات صوت خارجية).
مستوى الصوت الفردي: الجهاز ذو مستوى الصوت الفردي هو جهاز يربط جميع تدفقات الصوت بتدفق مستوى صوت فردي، ما يؤدي إلى تأثير تعديلات مستوى الصوت في جميع تدفقات الصوت بشكل موحّد (مثل التلفزيون).

3.20.1. متطلبات بث الصوت للمساعد

تطبيق لديه إذن MANAGE_ASSISTANT_AUDIO:

[C-0-1] يجب السماح بتغيير مستوى صوت STREAM_ASSISTANT آليًا.

إذا لم تحدّد عمليات تنفيذ الأجهزة android.hardware.type.watch، ولم تكن ذات مستوى صوت ثابت أو مستوى صوت واحد أو مستوى صوت كامل، فإنّها:

[C-1-1] يجب تنفيذ STREAM_ASSISTANT كبث صوتي منفصل ويجب عدم ربطه بأي بث آخر.
[C-1-2] يجب التأكّد من أنّ مستوى صوت تشغيل الصوت باستخدام AudioAttributes مع USAGE_ASSISTANT يتم التحكّم فيه من خلال STREAM_ASSISTANT.
[C-1-3] يجب التأكّد من أنّه بالنسبة إلى سماعة رأس بلوتوث معيّنة، يظل مؤشر مستوى الصوت STREAM_ASSISTANT كما هو عندما تنتقل سماعة الرأس بين ملفات تعريف الصوت A2DP وHFP.
[C-1-4] يجب منع أي بث آخر غير STREAM_ASSISTANT من تغيير مستوى صوت STREAM_ASSISTANT أو مستوى التخفيف المطبَّق على تشغيل USAGE_ASSISTANT، أثناء نشاط MODE_ASSISTANT_CONVERSATION.
[C-1-5] يجب تغيير مستوى صوت بث STREAM_ASSISTANT فقط وعدم تغيير مستويات صوت أي بث آخر عند ضبط مستوى الصوت باستخدام مفاتيح مستوى الصوت في الجهاز أو الجهاز الطرفي (مثل سماعة رأس تعمل بالبلوتوث) وعند استيفاء الشروط التالية:
- MODE_ASSISTANT_CONVERSATION مفعّلة، و
- لا يتوفّر تخصيص خاص بالتطبيق أو تشغيل نشط عن بُعد.
‫[C-1-6] يجب أن تعكس واجهة المستخدم أي تغيير في مستوى صوت "مساعد Google".

‫3.21. ميزات مزامنة الأجهزة المساعدة المتوافقة

يتضمّن Android إمكانية استخدام ميزات مزامنة البيانات على الأجهزة المصاحبة.

في حال توفُّر ميزة مزامنة "وضع عدم الإزعاج" في عمليات تنفيذ الأجهزة، يجب أن تستوفي ما يلي:

[C-1-1] يجب تنفيذ واجهة برمجة التطبيقات ContextualModeManager#isModeSyncSupported().
[C-1-2] يجب مزامنة الإعداد الذي يشير إلى تفعيل ميزة "عدم الإزعاج" من خلال القناة الآمنة CompanionDeviceManager باستخدام تنسيق بيانات متوافق مع عملية التنفيذ التلقائية CompanionDeviceManagerService.
[C-1-3] يجب تفعيل هذه المزامنة إذا عرضت ContextualModeManager#isModeSyncEnabled() القيمة true.

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع ميزة مزامنة "وضع الطيران"، يجب أن تستوفي ما يلي:

[C-1-4] يجب مزامنة الإعداد الذي يشير إلى أنّ "وضع الطيران" مفعّل من خلال قناة CompanionDeviceManager الآمنة باستخدام تنسيق بيانات متوافق مع عملية التنفيذ التلقائية CompanionDeviceManagerService.
[C-1-5] يجب تفعيل هذه المزامنة في حال تفعيل Settings.Global.AIRPLANE_MODE_SYNC.

4. توافُق حِزم التطبيقات

عمليات تنفيذ الأجهزة:

[C-0-1] يجب أن يكون الجهاز قادرًا على تثبيت ملفات Android ".apk" وتشغيلها كما تم إنشاؤها باستخدام أداة "aapt" المضمّنة في حزمة تطوير البرامج (SDK) الرسمية لنظام التشغيل Android.
- بما أنّ الشرط أعلاه قد يكون صعبًا، يُنصح بأن تستخدم عمليات تنفيذ الأجهزة نظام إدارة الحِزم المرجعي في مشروع AOSP.

[C-0-2] يجب أن يتيح التحقّق من صحة ملفات "‎.apk" باستخدام الإصدار 3.2 من مخطّط توقيع حِزم APK والإصدار 3.1 من مخطّط توقيع حِزم APK والإصدار 3 من مخطّط توقيع حِزم APK والإصدار 2 من مخطّط توقيع حِزم APK وتوقيع JAR.

[C-0-3] يجب ألا يتم توسيع نطاق أي من تنسيقات .apk أو بيان Android أو رمز Dalvik البايت أو رمز RenderScript البايت بطريقة تمنع تثبيت هذه الملفات وتشغيلها بشكل صحيح على الأجهزة المتوافقة الأخرى.
[C-0-4] يجب ألا تسمح التطبيقات الأخرى غير "برنامج التثبيت التلقائي" الحالي للحزمة بإلغاء تثبيت التطبيق بدون أي تأكيد من المستخدم، كما هو موضّح في حزمة تطوير البرامج (SDK) للإذن DELETE_PACKAGE. الاستثناءات الوحيدة هي تطبيق التحقّق من حِزم النظام الذي يتعامل مع الغرض PACKAGE_NEEDS_VERIFICATION وأداة إدارة مساحة التخزين التي تتعامل مع الغرض ACTION_MANAGE_STORAGE.
[C-0-5] يجب أن يتضمّن تطبيقك نشاطًا يعالج الغرض android.settings.MANAGE_UNKNOWN_APP_SOURCES.
[C-0-6] يجب عدم تثبيت حِزم التطبيقات من مصادر غير معروفة، إلا إذا كان التطبيق الذي يطلب التثبيت يستوفي جميع المتطلبات التالية:
- يجب أن يوضّح الإذن REQUEST_INSTALL_PACKAGES أو أن تكون قيمة android:targetSdkVersion مضبوطة على 24 أو أقل.
- يجب أن يكون المستخدم قد منح التطبيق الإذن بتثبيت تطبيقات من مصادر غير معروفة.
يجب توفير تلميحات مرئية للمستخدمين لمنح الإذن بتثبيت التطبيقات من مصادر غير معروفة أو إبطاله لكل تطبيق، ولكن يمكن اختيار تنفيذ ذلك كعملية غير نشطة وعرض RESULT_CANCELED للرمز startActivityForResult()، إذا كان تنفيذ الجهاز لا يريد السماح للمستخدمين بهذا الخيار. ومع ذلك، حتى في مثل هذه الحالات، يجب أن يوضّحوا للمستخدم سبب عدم توفّر هذا الخيار.
[C-0-7] يجب عرض مربّع حوار تحذيري يتضمّن سلسلة التحذير المقدَّمة من خلال واجهة برمجة التطبيقات PackageManager.setHarmfulAppWarning الخاصة بالنظام للمستخدم قبل تشغيل نشاط في تطبيق تم تصنيفه على أنّه قد يكون ضارًا من خلال واجهة برمجة التطبيقات PackageManager.setHarmfulAppWarning نفسها الخاصة بالنظام.
يجب توفير وسيلة للمستخدمين تتيح لهم اختيار إلغاء تثبيت تطبيق أو تشغيله من خلال مربّع حوار التحذير.
‫[C-0-8] يجب توفير دعم لنظام الملفات التزايدي كما هو موضّح هنا.
[C-0-9] يجب أن يتيح التحقّق من ملفات ‎ .apk باستخدام الإصدار 4 من مخطّط توقيع حِزم APK والإصدار 4.1 من مخطّط توقيع حِزم APK.

5. التوافق مع الوسائط المتعددة

عمليات تنفيذ الجهاز:

[C-0-1] يجب أن تتوافق مع تنسيقات الوسائط وبرامج الترميز والتشفير وأنواع الملفات وتنسيقات الحاويات المحدّدة في القسم 5.1 لكل برنامج ترميز وتشفير تم الإعلان عنه بواسطة MediaCodecList.
[C-0-2] يجب الإفصاح عن برامج الترميز وفك الترميز المتاحة للتطبيقات الخارجية والإبلاغ عنها من خلال MediaCodecList.
[C-0-3] يجب أن يكون الجهاز قادرًا على فك ترميز جميع التنسيقات التي يمكنه ترميزها وإتاحتها للتطبيقات التابعة لجهات خارجية. ويشمل ذلك جميع حزم البيانات التي تنشئها برامج الترميز، والملفات الشخصية التي يتم الإبلاغ عنها في CamcorderProfile.

عمليات تنفيذ الجهاز:

يجب أن يهدف إلى الحد الأدنى من وقت استجابة الترميز، أي
- يجب ألا تستهلك المخازن المؤقتة للإدخال وتخزّنها، وأن تعرض المخازن المؤقتة للإدخال فقط بعد معالجتها.
- يجب عدم الاحتفاظ بالمخازن المؤقتة التي تم فك ترميزها لمدة أطول من المدة المحددة في المعيار (مثل SPS).
- يجب ألا يتم الاحتفاظ بالمخازن المؤقتة المشفرة لمدة أطول من المدة التي تتطلبها بنية GOP.

يتم توفير جميع برامج الترميز المدرَجة في القسم أدناه كتطبيقات برمجية في تطبيق Android المفضّل من "مشروع Android مفتوح المصدر".

يُرجى العِلم أنّ Google أو Open Handset Alliance لا تقدّمان أي إقرار بأنّ برامج الترميز هذه لا تخضع لبراءات اختراع تابعة لجهات خارجية. ننصح الأشخاص الذين ينوون استخدام رمز المصدر هذا في منتجات الأجهزة أو البرامج بأنّ عمليات تنفيذ هذا الرمز، بما في ذلك في البرامج المفتوحة المصدر أو البرامج المجانية، قد تتطلّب الحصول على تراخيص براءات الاختراع من الجهات المعنية.

5.1. برامج ترميز الوسائط

5.1.1. ترميز الصوت

يمكنك الاطّلاع على مزيد من التفاصيل في 5.1.3. تفاصيل برامج ترميز الصوت

إذا كانت عمليات تنفيذ الأجهزة تعرّف android.hardware.microphone، يجب أن تتوافق مع ترميز تنسيقات الصوت التالية وأن توفّرها للتطبيقات التابعة لجهات خارجية:

‫[C-1-1] PCM/WAVE
[C-1-2] FLAC
[C-1-3] Opus

‫[C-1-4] MPEG-D USAC مع MPEG-D DRC (تنسيق AAC عالي الكفاءة الموسّع)

يجب أن تتوافق جميع برامج الترميز الصوتي مع ما يلي:

‫[C-3-1] إطارات صوتية بترتيب البايت الأصلي بتنسيق PCM‏ 16 بت من خلال واجهة برمجة التطبيقات android.media.MediaCodec

عند ترميز الصوت بتنسيق MPEG-D USAC باستخدام MPEG-D DRC (برنامج ترميز AAC عالي الكفاءة الموسّع):

[C-3-2] يجب أن تحتوي جميع تدفقات البتات على مجموعات البيانات الوصفية المتوافقة مع ملف تعريف التحكّم في مستوى الصوت MPEG-D أو ملف تعريف التحكّم في النطاق الديناميكي MPEG-D، المستوى 1 أو أعلى، وفقًا للمعيار ISO/IEC 23003-4.

‫5.1.2. فك ترميز الصوت

يمكنك الاطّلاع على مزيد من التفاصيل في 5.1.3. تفاصيل برامج ترميز الصوت

إذا كانت عمليات تنفيذ الأجهزة تعلن عن توافقها مع ميزة android.hardware.audio.output، يجب أن تتوافق مع فك ترميز تنسيقات الصوت التالية:

‫[C-1-1] ملف تعريف MPEG-4 AAC (ملف تعريف AAC LC)
‫[C-1-2] ملف تعريف MPEG-4 HE AAC (AAC+)
‫[C-1-3] ملف تعريف MPEG-4 HE AACv2 (تنسيق AAC+ المحسّن)
‫[C-1-4] AAC ELD (ترميز AAC المحسّن بزمن انتقال منخفض)
‫[C-1-5] FLAC
‫[C-1-6] MP3
‫[C-1-7] MIDI
[C-1-8] Vorbis
‫[C-1-9] PCM/WAVE بما في ذلك تنسيقات الصوت عالي الدقة التي تصل إلى 24 بت ومعدل بيانات في الملف الصوتي يبلغ 192 كيلوهرتز و8 قنوات يُرجى العِلم أنّ هذا الشرط ينطبق على فك التشفير فقط، ويُسمح للجهاز بتقليل عدد العيّنات وتقليل عدد القنوات الصوتية أثناء مرحلة التشغيل.
‫[C-1-10] Opus
‫[C-1-11] xHE-AAC (ملف تعريف HE AAC الموسّع وفقًا لمعيار ISO/IEC 23003-3، والذي يتضمّن ملف تعريف USAC الأساسي وملف تعريف التحكّم في النطاق الديناميكي وفقًا لمعيار ISO/IEC 23003-4)

‫[C-1-12] الإصدار 1.0 من IAMF الذي يحتوي على دفقات صوتية مرمّزة بتنسيق AAC أو FLAC أو Opus أو PCM

إذا كانت عمليات تنفيذ الأجهزة تتيح فك ترميز مخازن الإدخال بتنسيق AAC الخاصة بعمليات البث المتعدد القنوات (أي أكثر من قناتَين) إلى تنسيق PCM من خلال برنامج فك ترميز الصوت AAC التلقائي في واجهة برمجة التطبيقات android.media.MediaCodec، يجب توفير ما يلي:

[C-2-1] يجب إجراء عملية فك الترميز بدون خفض عدد القنوات (على سبيل المثال، يجب فك ترميز بث AAC 5.0 إلى خمس قنوات PCM، ويجب فك ترميز بث AAC 5.1 إلى ست قنوات PCM).
[C-2-2] يجب أن تكون البيانات الوصفية للنطاق الديناميكي على النحو المحدّد في "التحكّم في النطاق الديناميكي (DRC)" في المعيار ISO/IEC 14496-3، وأن تكون مفاتيح android.media.MediaFormat DRC مخصّصة لضبط السلوكيات المرتبطة بالنطاق الديناميكي لبرنامج ترميز الصوت. تم طرح مفاتيح AAC DRC في الإصدار 21 من واجهة برمجة التطبيقات، وهي: KEY_AAC_DRC_ATTENUATION_FACTOR وKEY_AAC_DRC_BOOST_FACTOR وKEY_AAC_DRC_HEAVY_COMPRESSION وKEY_AAC_DRC_TARGET_REFERENCE_LEVEL وKEY_AAC_ENCODED_TARGET_LEVEL.
[C-SR-1] يُنصح بشدة بأن تستوفي جميع برامج فك ترميز الصوت AAC المتطلبات C-2-1 وC-2-2 المذكورة أعلاه.

عند فك ترميز صوت USAC، يكون MPEG-D (ISO/IEC 23003-4):

[C-3-1] يجب تفسير البيانات الوصفية الخاصة بمستوى الصوت وDRC وتطبيقها وفقًا للمستوى 1 من ملف تعريف التحكّم في النطاق الديناميكي MPEG-D DRC.
[C-3-2] يجب أن يعمل برنامج الترميز وفقًا للإعدادات المحدّدة باستخدام المفتاحَين android.media.MediaFormatKEY_AAC_DRC_TARGET_REFERENCE_LEVEL وKEY_AAC_DRC_EFFECT_TYPE التاليَين.

برامج فك الترميز بتنسيقات MPEG-4 AAC وHE AAC وHE AACv2:

قد تتيح MAY التحكّم في مستوى الصوت والنطاق الديناميكي باستخدام ملف تعريف التحكّم في النطاق الديناميكي ISO/IEC 23003-4.

في حال توفّر معيار ISO/IEC 23003-4 وتوفّر البيانات الوصفية لكل من ISO/IEC 23003-4 وISO/IEC 14496-3 في دفق بت تم فك ترميزه، سيتم تطبيق ما يلي:

يجب أن تكون الأولوية للبيانات الوصفية ISO/IEC 23003-4.

يجب أن تتوافق جميع برامج فك ترميز الصوت مع ما يلي:

‫[C-6-1] إطارات صوتية بتنسيق PCM‏ 16 بت بترتيب البايت الأصلي من خلال واجهة برمجة التطبيقات android.media.MediaCodec

إذا كانت عمليات تنفيذ الأجهزة تتيح فك ترميز مخازن الإدخال AAC الخاصة بعمليات البث المتعدد القنوات (أي أكثر من قناتَين) إلى PCM من خلال برنامج فك ترميز الصوت AAC التلقائي في واجهة برمجة التطبيقات android.media.MediaCodec، يجب توفير ما يلي:

[C-7-1] يجب أن يكون التطبيق قادرًا على ضبط إعدادات فك الترميز باستخدام المفتاح KEY_MAX_OUTPUT_CHANNEL_COUNT للتحكّم في ما إذا كان سيتم خلط المحتوى لإنتاج صوت استريو (عند استخدام القيمة 2) أو سيتم إخراج الصوت باستخدام عدد القنوات الأصلي (عند استخدام قيمة تساوي هذا العدد أو أكبر منه). على سبيل المثال، سيؤدي استخدام القيمة 6 أو أكبر إلى إعداد برنامج ترميز لإخراج 6 قنوات عند إدخال محتوى 5.1.
[C-7-2] عند فك الترميز، يجب أن يعلن برنامج فك الترميز عن قناع القناة المستخدَم في تنسيق الإخراج باستخدام المفتاح KEY_CHANNEL_MASK، وذلك باستخدام الثوابت android.media.AudioFormat (مثال: CHANNEL_OUT_5POINT1).

جميع الأجهزة المحمولة أو اللوحية التي تتضمّن تأثيرًا صوتيًا مكانيًا، وجميع أجهزة السيارات وأجهزة التلفزيون:

[C-8-1] يجب أن يتيح فك ترميز الإصدار 1.0 من تنسيق IAMF الذي يتضمّن بثًا صوتيًا مرمّزًا بتنسيق AAC أو FLAC أو Opus أو PCM، ويجب أن يوفّر برنامج فك ترميز IAMF من خلال واجهة برمجة التطبيقات android.media.MediaCodec.
[C-8-2] يجب التأكّد من أنّ برنامج فك ترميز IAMF يلتزم بقناع القناة المستخدَم لضبطه من خلال المفتاح KEY_CHANNEL_MASK، وذلك باستخدام الثوابت android.media.AudioFormat مثل CHANNEL_OUT_5POINT1.
[C-8-3] يجب التأكّد من أنّ برنامج فك ترميز IAMF يعلن عن قناع القناة النشط في تنسيق الإخراج من خلال المفتاح KEY_CHANNEL_MASK، باستخدام ثوابت android.media.AudioFormat مثل CHANNEL_OUT_5POINT1.

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع برامج ترميز الصوت غير برنامج ترميز الصوت AAC التلقائي، وكانت قادرة على إخراج صوت متعدد القنوات (أي أكثر من قناتين) عند إدخال محتوى مضغوط متعدد القنوات، يجب استيفاء ما يلي:

[C-SR-2] يُنصح بشدة بأن يكون برنامج الترميز قابلاً للضبط من خلال التطبيق باستخدام الترميز مع المفتاح KEY_MAX_OUTPUT_CHANNEL_COUNT للتحكّم في ما إذا كان سيتم خلط المحتوى إلى ستيريو (عند استخدام القيمة 2) أو إخراجه باستخدام العدد الأصلي للقنوات (عند استخدام قيمة تساوي هذا العدد أو أكبر منه). على سبيل المثال، سيؤدي استخدام القيمة 6 أو أكبر إلى إعداد برنامج ترميز لإخراج 6 قنوات عند إدخال محتوى 5.1.
‫[C-SR-3] عند فك الترميز، يُنصح بشدة بأن يعلن برنامج فك الترميز عن قناع القناة المستخدَم في تنسيق الإخراج باستخدام المفتاح KEY_CHANNEL_MASK، وذلك باستخدام الثوابت android.media.AudioFormat (مثال: CHANNEL_OUT_5POINT1).

5.1.3. تفاصيل برامج ترميز الصوت

التنسيق/برنامج الترميز	التفاصيل	أنواع الملفات/تنسيقات الحاويات التي يجب توفيرها
G.711 μ-law وA-law	إتاحة المحتوى الأحادي/الاستيريو/5.1 الذي تم أخذ عينات منه بمعدل 8 كيلوهرتز	‫WAVE ‏(‎.wav)
ملف تعريف MPEG-4 AAC (AAC LC)	إتاحة المحتوى أحادي/ثنائي/5.0/5.1 القنوات مع معدّلات بيانات في الملف الصوتي تتراوح بين 8 و48 كيلوهرتز	3GPP‏ (‎.3gp) MPEG-4 ‏(‎.mp4،‏ ‎.m4a) ملف ADTS AAC الأولي (لا يمكن استخدام ADIF) ‫MPEG-TS (.ts، لا يمكن البحث فيه، فك الترميز فقط) ‫Matroska‏ (‎.mkv، فك التشفير فقط)
ملف تعريف MPEG-4 HE AAC (AAC+)	إتاحة المحتوى الأحادي/الاستيريو/5.0/5.1 بمعدّلات بيانات في الملف الصوتي تتراوح بين 16 و48 كيلوهرتز.	3GPP‏ (‎.3gp) MPEG-4 ‏(‎.mp4،‏ ‎.m4a)
‫MPEG-4 HE AACv2 الملف الشخصي (enhanced AAC+)	إتاحة المحتوى الأحادي/الاستيريو/5.0/5.1 بمعدّلات بيانات في الملف الصوتي تتراوح بين 16 و48 كيلوهرتز.	3GPP‏ (‎.3gp) MPEG-4 ‏(‎.mp4،‏ ‎.m4a)
‫AAC ELD (الترميز المتقدّم للصوت مع تأخير منخفض محسّن)	يتوافق مع المحتوى الأحادي/الاستيريو بمعدّلات بيانات في الملف الصوتي تتراوح بين 16 و48 كيلوهرتز.	3GPP‏ (‎.3gp) MPEG-4 ‏(‎.mp4،‏ ‎.m4a)
USAC MPEG-D USAC مع MPEG-D DRC (برنامج الترميز المتقدّم للصوت عالي الكفاءة والموسّع)	فك التشفير: إتاحة المحتوى الأحادي/الاستيريو بمعدّلات بيانات في الملف الصوتي عادية تتراوح بين 7.35 و48 كيلوهرتز الترميز: يتوافق مع المحتوى الأحادي أو الاستيريو بمعدّلات بيانات في الملف الصوتي تبلغ 44.1 و48 كيلوهرتز.	MPEG-4 ‏(‎.mp4،‏ ‎.m4a)
AMR-NB	من 4.75 إلى 12.2 كيلوبت في الثانية، مع أخذ عيّنات بمعدّل 8 كيلوهرتز	3GPP‏ (‎.3gp)
AMR-WB	9 معدّلات تتراوح بين 6.60 كيلوبت في الثانية و23.85 كيلوبت في الثانية، مع أخذ عيّنات بمعدّل 16 كيلوهرتز، كما هو محدّد في AMR-WB، برنامج الترميز الصوتي ذو النطاق العريض والمعدّل التكيفي المتعدد	3GPP‏ (‎.3gp)
FLAC	يجب أن يتوافق كل من أداة الترميز وأداة فك الترميز مع وضعَي الصوت الأحادي والاستيريو على الأقل. يجب أن تتوافق مع معدّلات بيانات تصل إلى 192 كيلوهرتز، كما يجب أن تتوافق مع دقة 16 بت و24 بت. يجب أن تتوفّر إمكانية معالجة بيانات الصوت بتنسيق FLAC وبدقة 24 بت مع إعدادات الصوت بنقطة عائمة.	FLAC ‏(‎.flac) ‫MPEG-4 ‏(‎.mp4 و‎.m4a، فك التشفير فقط) ‫Matroska‏ (‎.mkv، فك التشفير فقط)
MP3	صوت أحادي/استيريو بمعدل نقل بيانات ثابت أو متغير يتراوح بين 8 و320 كيلوبت في الثانية	MP3 ‏(‎.mp3) ‫MPEG-4 ‏(‎.mp4 و‎.m4a، فك التشفير فقط) ‫Matroska‏ (‎.mkv، فك التشفير فقط)
MIDI	النوعان 0 و1 من ملفات MIDI الإصداران 1 و2 من DLS ‫XMF وMobile XMF التوافق مع تنسيقات نغمات الرنين RTTTL/RTX وOTA وiMelody	النوع 0 و1 (‎.mid و‎.xmf و‎.mxmf) RTTTL/RTX ‏(‎.rtttl و‎.rtx) iMelody ‏(‎.imy)
Vorbis	فك التشفير: إمكانية استخدام المحتوى الأحادي والثنائي والقنوات 5.0 و5.1 بمعدلات أخذ عينات تبلغ 8000 و12000 و16000 و24000 و48000 هرتز التشفير: إمكانية استخدام المحتوى الأحادي والثنائي بمعدلات أخذ عينات تبلغ 8000 و12000 و16000 و24000 و48000 هرتز	Ogg (.ogg) ‫MPEG-4 ‏(‎.mp4 و‎.m4a، فك التشفير فقط) Matroska‏ (‎.mkv) Webm ‏(‎.webm)
PCM/WAVE	يجب أن يتوافق برنامج ترميز PCM مع ترميز PCM الخطي بمعدل 16 بت و16 بت عائم. يجب أن يتيح برنامج استخراج بيانات WAVE استخدام PCM خطي بمعدّل 16 بت و24 بت و32 بت، بالإضافة إلى معدّل 32 بت (بمعدّلات تصل إلى الحد الأقصى للأجهزة). يجب أن تتوافق معدّلات البيانات في الملف الصوتي مع النطاق من 8 كيلوهرتز إلى 192 كيلوهرتز.	‫WAVE ‏(‎.wav)
Opus	فك الترميز: إمكانية استخدام المحتوى الأحادي والثنائي والقنوات 5.0 و5.1 بمعدّلات أخذ عيّنات تبلغ 8000 و12000 و16000 و24000 و48000 هرتز الترميز: إمكانية استخدام المحتوى الأحادي والثنائي بمعدّلات أخذ عيّنات تبلغ 8000 و12000 و16000 و24000 و48000 هرتز	Ogg (.ogg) ‫MPEG-4 ‏(‎.mp4 و‎.m4a، فك التشفير فقط) Matroska‏ (‎.mkv) Webm ‏(‎.webm)

‫5.1.4. ترميز الصور

يمكنك الاطّلاع على مزيد من التفاصيل في 5.1.6. تفاصيل برامج ترميز الصور

يجب أن تتوافق عمليات تنفيذ الأجهزة مع ترميز الصور التالي:

‫[C-0-1] JPEG
[C-0-2] PNG
‫[C-0-3] WebP
‫[C-0-4] AVIF
- يجب أن تتوافق الأجهزة مع BITRATE_MODE_CQ والملف الشخصي للمرجع.

إذا كانت عمليات تنفيذ الأجهزة تتيح ترميز HEIC من خلال android.media.MediaCodec لنوع الوسائط MIMETYPE_IMAGE_ANDROID_HEIC، يجب أن تستوفي ما يلي:

[C-1-1] يجب توفير برنامج ترميز HEVC مُسارع بالأجهزة يتوافق مع BITRATE_MODE_CQ وضع التحكّم في معدّل نقل البيانات، HEVCProfileMainStill الملف الشخصي وحجم الإطار 512 × 512 بكسل.

‫5.1.5. فك ترميز الصور

يمكنك الاطّلاع على مزيد من التفاصيل في 5.1.6. تفاصيل برامج ترميز الصور

يجب أن تتوافق عمليات تنفيذ الأجهزة مع ترميز الصور التالي:

‫[C-0-1] JPEG
[C-0-2] GIF
‫[C-0-3] PNG
[C-0-4] BMP
‫[C-0-5] WebP
[C-0-6] Raw
‫[C-0-7] AVIF (الملف الشخصي للمرجع)

في حال توفّر إمكانية فك ترميز فيديو HEVC في عمليات تنفيذ الأجهزة، يجب أن:

[C-1-1] يجب أن يتيح فك ترميز صور HEIF (HEIC).

برامج ترميز الصور التي تتوافق مع تنسيق عالي العمق (9 بت أو أكثر لكل قناة):

[C-2-1] يجب أن يتيح إخراج تنسيق مكافئ 8 بت إذا طلب التطبيق ذلك، على سبيل المثال، من خلال ARGB_8888 config الخاص بـ android.graphics.Bitmap.

5.1.6. تفاصيل برامج ترميز الصور

التنسيق/برنامج الترميز	التفاصيل	أنواع الملفات/تنسيقات الحاويات المتوافقة
JPEG	Base+progressive	JPEG‏ (‎.jpg)
GIF		GIF ‏(‎.gif)
PNG		PNG‏ (‎.png)
BMP		BMP‏ (‎.bmp)
تنسيق WebP		WebP ‏(‎.webp)
عناوين أوّلية		ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
HEIF	صورة أو مجموعة صور أو تسلسل صور	HEIF‏ (‎.heif)،‏ HEIC‏ (‎.heic)
AVIF (الملف الشخصي للمرجع)	صورة، مجموعة صور، الملف الشخصي للمرجع لتسلسل الصور	حاوية HEIF‏ (‎.avif)

أدوات ترميز وفك ترميز الصور المتاحة من خلال واجهة برمجة التطبيقات MediaCodec

[C-1-1] يجب أن تتوافق مع تنسيق الألوان المرن YUV420 8:8:8 (COLOR_FormatYUV420Flexible) من خلال CodecCapabilities.
[C-SR-1] يُنصح بشدة بتوفير تنسيق الألوان RGB888 لوضع Surface.
[C-1-3] يجب أن تتوافق مع أحد تنسيقات الألوان YUV420 8:8:8 المسطّحة أو شبه المسطّحة على الأقل: COLOR_FormatYUV420PackedPlanar (أي ما يعادل COLOR_FormatYUV420Planar) أو COLOR_FormatYUV420PackedSemiPlanar (أي ما يعادل COLOR_FormatYUV420SemiPlanar). ويُنصح بشدة بأن تتوافق مع كليهما.

5.1.7. برامج ترميز الفيديو

للحصول على جودة مقبولة لبث الفيديو على الويب وخدمات مؤتمرات الفيديو، يجب أن تستخدم عمليات تنفيذ الأجهزة برنامج ترميز VP8 للأجهزة يستوفي المتطلبات.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن برنامج ترميز أو فك ترميز للفيديو:

[C-1-1] يجب أن تتوافق برامج ترميز الفيديو مع أحجام bytebuffer للإخراج والإدخال التي تستوعب أكبر إطار مضغوط وغير مضغوط ممكن وفقًا للمعيار والإعدادات، ولكن بدون تخصيص مساحة أكبر من اللازم.
‫[C-1-2] يجب أن تتوافق برامج ترميز الفيديو وفك ترميزه مع تنسيقات الألوان المرنة YUV420 8:8:8 (COLOR_FormatYUV420Flexible) من خلال CodecCapabilities.
[C-1-3] يجب أن تتوافق برامج ترميز الفيديو وفك ترميزه مع تنسيق ألوان YUV420 8:8:8 المسطّح أو شبه المسطّح على الأقل: COLOR_FormatYUV420PackedPlanar (ما يعادل COLOR_FormatYUV420Planar) أو COLOR_FormatYUV420PackedSemiPlanar (ما يعادل COLOR_FormatYUV420SemiPlanar). ويُنصح بشدة بأن تتوافق مع كليهما.
[C-SR-1] يُنصح بشدة بأن تتوافق برامج الترميز وفك الترميز للفيديوهات مع تنسيق ألوان YUV420 8:8:8 مسطّح أو شبه مسطّح محسّن للأجهزة (YV12 أو NV12 أو NV21 أو تنسيق مكافئ محسّن من المورّد).
‫[C-1-5] يجب أن تتوافق برامج ترميز الفيديو التي تتوافق مع تنسيق عالي العمق في عدد البتات (أكثر من 9 بتات لكل قناة) مع إخراج تنسيق مكافئ من 8 بتات إذا طلب التطبيق ذلك. يجب أن يتوفّر ذلك من خلال توفير تنسيق ألوان YUV420 8:8:8 عبر android.media.MediaCodecInfo.

إذا كانت عمليات تنفيذ الأجهزة تعلن عن توفّر ملفات تعريف HDR من خلال Display.HdrCapabilities، يجب أن تستوفي ما يلي:

[C-2-1] يجب أن تتوافق مع تحليل البيانات الوصفية الثابتة ذات تنسيق HDR ومعالجتها.

إذا كانت عمليات تنفيذ الأجهزة تعلن عن إتاحة ميزة "التحديث الداخلي" من خلال FEATURE_IntraRefresh في فئة MediaCodecInfo.CodecCapabilities، عليها:

‫[C-3-1] يجب أن تتوافق مع فترات إعادة التحميل في النطاق من 10 إلى 60 إطارًا، وأن تعمل بدقة ضمن% 20 من فترة إعادة التحميل المضبوطة.

ما لم يحدّد التطبيق خلاف ذلك باستخدام مفتاح التنسيق KEY_COLOR_FORMAT، يجب أن تتضمّن عمليات تنفيذ أداة فك ترميز الفيديو ما يلي:

[C-4-1] يجب أن يكون تنسيق الألوان التلقائي هو التنسيق المحسَّن للعرض على الأجهزة في حال ضبطه باستخدام إخراج Surface.
[C-4-2] يجب أن يكون تنسيق الألوان YUV420 8:8:8 هو التنسيق التلقائي الذي تم تحسينه لقراءة وحدة المعالجة المركزية (CPU) في حال تم ضبطه على عدم استخدام إخراج Surface.

بالنسبة إلى عمليات تنفيذ الأجهزة التي تتضمّن برنامج ترميز أو فك ترميز للفيديو:

[C-5-1] يجب أن تتضمّن برامج فك ترميز الفيديو التي تستخدم تكنولوجيا ترميز من عام 2003 أو أحدث (مثل AV1 أو AVC أو HEVC أو VP8 أو VP9 أو VVC) ما يلي:
- أن تتوافق مع الحد الأدنى للحجم وهو 144 × 144 بكسل
- يمكنك الإعلان عن هذه الميزة من خلال واجهة برمجة التطبيقات VideoCapabilities API، مثل الطريقتَين getSupportedWidths() وgetSupportedHeightsFor().
‫[C-5-2] يجب أن تستوفي برامج ترميز الفيديو التي تستخدم تكنولوجيا ترميز من عام 2003 أو إصدار أحدث (مثل AV1 أو AVC أو HEVC أو VP8 أو VP9 أو VVC) ما يلي:
- يجب أن يكون الحدّ الأدنى لحجم Support Surface هو ما يلي لكل برنامج ترميز:
  - AVC: 160x160 px
  - ‫VP8 وHEVC وVP9 (في حال توفّر برنامج الترميز): 160×160 بكسل
  - ‫AV1 (في حال توفّر برنامج الترميز): 256x256 بكسل
- يمكن أن تنتج بثًا للبيانات بحجم إطار أكبر من الحد الأدنى، شرط أن يتم ترميز الحجم المناسب باستخدام معلومات مستطيل الاقتصاص.

‫5.1.8. قائمة برامج ترميز الفيديو

التنسيق/برنامج الترميز	التفاصيل	أنواع الملفات/تنسيقات الحاويات التي يجب توفيرها
H.263		3GPP‏ (‎.3gp) MPEG-4 ‏(‎.mp4) ‫Matroska‏ (‎.mkv، فك التشفير فقط)
H.264 AVC	يمكنك الاطّلاع على الفقرة 5.2 و5.3 للحصول على التفاصيل.	3GPP‏ (‎.3gp) MPEG-4 ‏(‎.mp4) ‫MPEG-2 TS ‏(ts.، لا يمكن البحث فيه) ‫Matroska‏ (‎.mkv، فك التشفير فقط)
‫H.265 HEVC	يمكنك الاطّلاع على الفقرة 5.3 للحصول على التفاصيل.	MPEG-4 ‏(‎.mp4) ‫Matroska‏ (‎.mkv، فك التشفير فقط)
MPEG-2	الجودة الرئيسية	‫MPEG2-TS ‏(ts.، لا يمكن البحث فيه) ‫MPEG-4 ‏(‎.mp4، فك التشفير فقط) ‫Matroska‏ (‎.mkv، فك التشفير فقط)
MPEG-4 SP		3GPP‏ (‎.3gp) MPEG-4 ‏(‎.mp4) ‫Matroska‏ (‎.mkv، فك التشفير فقط)
VP8	يمكنك الاطّلاع على الفقرة 5.2 و5.3 للحصول على التفاصيل.	WebM ‎(.webm) Matroska‏ (‎.mkv)
VP9	يمكنك الاطّلاع على الفقرة 5.3 للحصول على التفاصيل.	WebM ‎(.webm) Matroska‏ (‎.mkv)
AV1	راجِع الفقرة 5.2 والفقرة 5.3 للحصول على التفاصيل.	MPEG-4 ‏(‎.mp4) ‫Matroska‏ (‎.mkv، فك التشفير فقط)

5.1.9. أمان برامج ترميز الوسائط

يجب أن تضمن عمليات تنفيذ الأجهزة التوافق مع ميزات أمان برامج الترميز الخاصة بالوسائط كما هو موضّح أدناه.

يتضمّن Android دعمًا لواجهة برمجة التطبيقات OMX، وهي واجهة برمجة تطبيقات متعددة المنصات لتسريع الوسائط المتعددة، بالإضافة إلى Codec 2.0، وهي واجهة برمجة تطبيقات لتسريع الوسائط المتعددة ذات الحمل المنخفض.

إذا كانت عمليات تنفيذ الأجهزة تتيح الوسائط المتعددة، يجب أن تستوفي ما يلي:

[C-1-1] يجب توفير دعم لبرامج ترميز الوسائط إما من خلال واجهات برمجة تطبيقات OMX أو Codec 2.0 (أو كليهما) كما هو الحال في "مشروع مفتوح المصدر لنظام Android"، ويجب عدم إيقاف أو التحايل على وسائل الحماية الأمنية. ولا يعني ذلك تحديدًا أنّه يجب أن يستخدم كل برنامج ترميز إما واجهة برمجة التطبيقات OMX أو Codec 2.0، بل يجب أن تتوفّر إمكانية استخدام إحدى هاتين الواجهتين على الأقل، ويجب أن تتضمّن إمكانية استخدام واجهات برمجة التطبيقات المتاحة إجراءات الحماية الأمنية المتوفّرة.
[C-SR-1] يُنصح بشدة بتضمين دعم Codec 2.0 API.

في حال عدم توفّر واجهة برمجة التطبيقات Codec 2.0 في عمليات تنفيذ الأجهزة، يجب:

[C-2-1] يجب أن يتضمّن برنامج الترميز/فك الترميز المتوافق مع OMX من "مشروع Android المفتوح المصدر" (إذا كان متاحًا) لكل تنسيق ونوع وسائط (برنامج ترميز أو فك ترميز) متوافق مع الجهاز.
‫[C-2-2] برامج الترميز التي تبدأ أسماؤها بـ "OMX.google." يجب أن تستند إلى رمز المصدر الخاص بمشروع مفتوح المصدر لنظام Android.
[C-SR-2] يُنصح بشدة بتشغيل برامج الترميز OMX في عملية ترميز لا يمكنها الوصول إلى برامج تشغيل الأجهزة باستثناء أدوات ربط الذاكرة.

في حال توفير عمليات تنفيذ الأجهزة لواجهة برمجة التطبيقات Codec 2.0، يجب أن:

[C-3-1] يجب تضمين برنامج الترميز Codec 2.0 المناسب من "مشروع Android المفتوح المصدر" (في حال توفّره) لكل تنسيق ونوع وسائط (برنامج ترميز أو فك ترميز) متوافق مع الجهاز.
[C-3-2] يجب أن تستضيف برامج الترميز Codec 2.0 في عملية برامج الترميز، كما هو موضّح في مشروع مفتوح المصدر لنظام Android، وذلك لإتاحة منح إذن الوصول إلى برامج الترميز بشكل أكثر تحديدًا.
‫[C-3-3] برامج الترميز التي تبدأ أسماؤها بـ "c2.android." يجب أن تستند إلى رمز المصدر الخاص بمشروع مفتوح المصدر لنظام Android.

‫5.1.10. تحديد خصائص برامج ترميز الوسائط

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع برامج ترميز الوسائط، يجب أن:

[C-1-1] يجب عرض القيم الصحيحة لتوصيف برامج الترميز الخاصة بالوسائط من خلال واجهة برمجة التطبيقات MediaCodecInfo.

ويشمل ذلك على وجه الخصوص:

‫[C-1-2] برامج الترميز التي تبدأ أسماؤها بـ "OMX". يجب استخدام واجهات برمجة التطبيقات OMX ويجب أن تتوافق الأسماء مع إرشادات التسمية الخاصة بـ OMX IL.
‫[C-1-3] برامج الترميز التي تبدأ أسماؤها بـ "c2." يجب استخدام Codec 2.0 API وأن تتضمّن أسماء تتوافق مع إرشادات التسمية في Codec 2.0 لنظام التشغيل Android.
‫[C-1-4] برامج الترميز التي تبدأ أسماؤها بـ "OMX.google." أو "c2.android." يجب ألا يتم تصنيفها على أنّها خاصة بمورّد أو أنّها تستخدم تسريع الأجهزة.
[C-1-5] يجب عدم تصنيف برامج الترميز التي يتم تشغيلها في عملية برنامج ترميز (مورّد أو نظام) يمكنها الوصول إلى برامج تشغيل الأجهزة بخلاف أدوات تخصيص الذاكرة وأدوات الربط على أنّها برامج فقط.
‫[C-1-6] يجب تصنيف برامج الترميز غير المتوفّرة في "مشروع Android مفتوح المصدر" أو غير المستندة إلى الرمز المصدر في هذا المشروع على أنّها برامج ترميز خاصة بمورّد.
‫[C-1-7] يجب تصنيف برامج الترميز التي تستخدم ميزة "تسريع الأجهزة" على أنّها تستخدم هذه الميزة.
‫[C-1-8] يجب ألا تكون أسماء برامج الترميز مضلِّلة. على سبيل المثال، يجب أن تتيح برامج الترميز التي تحمل الاسم "أدوات فك الترميز" فك الترميز، كما يجب أن تتيح برامج الترميز التي تحمل الاسم "أدوات الترميز" الترميز. يجب أن تتوافق برامج الترميز التي تتضمّن أسماؤها تنسيقات وسائط مع هذه التنسيقات.

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع برامج ترميز الفيديو:

[C-2-1] يجب أن تنشر جميع برامج ترميز الفيديو بيانات عدد اللقطات في الثانية القابل للتحقيق للأحجام التالية إذا كان برنامج الترميز يتيحها:

	الدقة العادية (جودة منخفضة)	الدقة العادية (جودة عالية)	دقة عالية - 720p	دقة عالية - 1080p	دقة فائقة
دقة الفيديو	‫176 × 144 بكسل (H263 وMPEG2 وMPEG4) ‫352 × 288 بكسل (برنامج الترميز MPEG4 وH263 وMPEG2) ‫320 × 180 بكسل (VP8، VP8) ‫320 × 240 بكسل (أخرى)	‫704 × 576 بكسل (H263) ‫640 × 360 بكسل (VP8 وVP9) ‫640 × 480 بكسل (برنامج ترميز MPEG4) ‫720 × 480 بكسل (غير ذلك، AV1)	‫1408 × 1152 بكسل (H263) ‫1280 × 720 بكسل (أخرى، AV1)	‫1920 × 1080 بكسل (باستثناء MPEG4 وAV1)	‫3840 × 2160 بكسل (HEVC وVP9 وAV1)

‫[C-2-2] يجب أن تنشر برامج ترميز الفيديو التي يتم تصنيفها على أنّها مسرَّعة على الأجهزة معلومات حول نقاط الأداء. يجب أن تتضمّن كل منها قائمة بجميع نقاط الأداء العادية المتوافقة (المدرَجة في واجهة برمجة التطبيقات PerformancePoint)، ما لم تكن مشمولة بنقطة أداء عادية أخرى متوافقة.
بالإضافة إلى ذلك، يجب أن تنشر نقاط الأداء الموسّع إذا كانت تتيح أداءً مستدامًا للفيديو بخلاف أحد المعايير المدرَجة.

5.2. ترميز الفيديو

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع أي برنامج ترميز فيديو وتتيحه للتطبيقات التابعة لجهات خارجية، وتم ضبط
MediaFormat.KEY_BITRATE_MODE على BITRATE_MODE_VBR لكي يعمل برنامج الترميز في وضع معدل نقل البيانات المتغيّر، يكون معدل نقل البيانات المرمَّز على النحو التالي، طالما أنّه لا يؤثر في الحد الأدنى لجودة الفيديو :

يجب ألا يتجاوز معدّل نقل البيانات خلال فترة زمنية محددة% 15 من معدّل نقل البيانات بين فواصل الإطارات الكاملة (I-frame).
يجب ألا تتجاوز نسبة الزيادة في معدّل نقل البيانات% 100 خلال فترة ثانية واحدة.

إذا كانت عمليات تنفيذ الأجهزة تتيح أي برنامج ترميز فيديو وتجعله متاحًا للتطبيقات التابعة لجهات خارجية، وتم ضبط MediaFormat.KEY_BITRATE_MODE على BITRATE_MODE_CBR لكي يعمل برنامج الترميز في وضع معدّل نقل البيانات الثابت، يكون معدّل نقل البيانات المرمَّز على النحو التالي:

يُنصح بشدة بعدم تجاوز معدّل نقل البيانات المستهدف بنسبة ‎15% خلال فترة زمنية متغيرة تبلغ ثانية واحدة.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة عرض مدمجة بقطر لا يقل عن 2.5 بوصة أو تتضمّن منفذ إخراج فيديو أو تعلن عن إتاحة كاميرا من خلال علامة الميزة android.hardware.camera.any، يجب أن تستوفي ما يلي:

[C-1-1] يجب أن يتضمّن دعم برنامج ترميز فيديو واحد على الأقل من VP8 أو H.264، وأن يتيحه للتطبيقات التابعة لجهات خارجية.
يجب أن يتوافق مع برامج ترميز الفيديو VP8 وH.264، وأن يتيحها للتطبيقات التابعة لجهات خارجية.

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع أي من برامج ترميز الفيديو H.264 أو VP8 أو VP9 أو HEVC وتتيحها للتطبيقات التابعة لجهات خارجية، يجب أن تستوفي ما يلي:

[C-2-1] يجب أن تتوافق مع معدّلات نقل البيانات القابلة للضبط بشكل ديناميكي.
يجب أن تتوافق مع عدد اللقطات المتغيّر في الثانية، ويجب أن يحدّد برنامج ترميز الفيديو مدة اللقطة الآنية استنادًا إلى الطوابع الزمنية لمخازن البيانات المدخلة، وأن يخصّص سعة التخزين المؤقت للبيانات استنادًا إلى مدة اللقطة.

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع برنامج ترميز الفيديو MPEG-4 SP وتتيحه للتطبيقات التابعة لجهات خارجية، يجب أن:

يجب أن يتيح معدلات نقل بيانات قابلة للضبط بشكل ديناميكي لبرنامج الترميز المتوافق.

إذا كانت عمليات تنفيذ الأجهزة توفّر برامج ترميز فيديو أو صور مسرَّعة للأجهزة، وتتيح استخدام كاميرا واحدة أو أكثر من الكاميرات الخارجية أو القابلة للتوصيل والمتاحة من خلال واجهات برمجة التطبيقات android.camera:

[C-4-1] يجب أن تتوافق جميع برامج ترميز الفيديو والصور المسرَّعة للأجهزة مع ترميز اللقطات من كاميرات الأجهزة.
يجب أن يتيح ترميز اللقطات من الكاميرات المضمّنة في الجهاز من خلال جميع برامج ترميز الفيديو أو الصور.

إذا كانت عمليات تنفيذ الأجهزة توفّر ترميز HDR، يجب أن:

[C-SR-1] يُنصح بشدة بتوفير إضافة لواجهة برمجة التطبيقات الخاصة بالترميز والتغيير السلسَين لتحويل المحتوى من تنسيق HDR إلى تنسيق SDR.

5.2.1. H.263

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع برامج ترميز H.263 وتتيحها للتطبيقات التابعة لجهات خارجية، يجب أن تستوفي ما يلي:

[C-1-1] يجب أن تتوافق مع درجة الدقة QCIF (176 x 144) باستخدام المستوى 45 من الملف الشخصي للمرجع. درجة دقة SQCIF اختيارية.

5.2.2. H.264

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع برنامج الترميز H.264، يجب أن:

[C-1-1] يجب أن يتوافق مع المستوى 3 من ملف Baseline Profile. ومع ذلك، فإنّ التوافق مع ASO (ترتيب الشرائح العشوائي) وFMO (ترتيب وحدات الماكرو المرن) وRS (الشرائح المكررة) هو أمر اختياري. علاوةً على ذلك، للحفاظ على التوافق مع أجهزة Android الأخرى، يُنصح بعدم استخدام ASO وFMO وRS في الملف الشخصي للمرجع من قِبل برامج الترميز.
[C-1-2] يجب أن تتوافق مع ملفات تعريف ترميز الفيديو بدقة عادية (SD) الواردة في الجدول التالي.
يجب أن يتوافق مع مستوى الملف الشخصي الرئيسي 4.
يجب أن تتوافق مع ملفات ترميز الفيديو العالي الدقة (HD) كما هو موضّح في الجدول التالي.

إذا كانت عمليات تنفيذ الأجهزة تشير إلى إمكانية ترميز فيديوهات بدقة 720p أو 1080p باستخدام برنامج الترميز H.264 من خلال واجهات برمجة التطبيقات الخاصة بالوسائط، فإنّها:

[C-2-1] يجب أن تتوافق مع ملفات الترميز الشخصية في الجدول التالي.

	الدقة العادية (جودة منخفضة)	الدقة العادية (جودة عالية)	دقة عالية - 720p	دقة عالية - 1080p
دقة الفيديو	‫320 × 240 بكسل	‫720 × 480 بكسل	‫1280 × 720 بكسل	‫‎1920 x 1080 بكسل
عدد اللقطات في الثانية في الفيديو	‫20 لقطة في الثانية	30 إطارًا في الثانية	30 إطارًا في الثانية	30 إطارًا في الثانية
معدّل نقل بيانات الفيديو	‫384 كيلوبت في الثانية	‫2 ميغابت في الثانية	‫4 ميغابت في الثانية	‫10 ميغابت في الثانية

‫5.2.3. VP8

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع ترميز VP8، يجب أن:

[C-1-1] يجب أن تتوافق مع ملفات تعريف ترميز الفيديو بدقة عادية.
يجب أن تتوافق مع ملفات ترميز الفيديو التالية العالية الدقة (HD).
‫[C-1-2] يجب أن يتيح كتابة ملفات Matroska WebM.
يجب توفير برنامج ترميز VP8 للأجهزة يفي بمتطلبات ترميز الأجهزة في مشروع WebM RTC، وذلك لضمان جودة مقبولة لخدمات بث الفيديو على الويب ومؤتمرات الفيديو.

إذا كانت عمليات تنفيذ الأجهزة تتيح ترميز VP8 للفيديوهات بدقة 720p أو 1080p من خلال واجهات برمجة التطبيقات الخاصة بالوسائط، فإنّها:

[C-2-1] يجب أن تتوافق مع ملفات الترميز الشخصية في الجدول التالي.

	الدقة العادية (جودة منخفضة)	الدقة العادية (جودة عالية)	دقة عالية - 720p	دقة عالية - 1080p
دقة الفيديو	‫320 × 180 بكسل	‫640 × 360 بكسل	‫1280 × 720 بكسل	‫‎1920 x 1080 بكسل
عدد اللقطات في الثانية في الفيديو	30 إطارًا في الثانية	30 إطارًا في الثانية	30 إطارًا في الثانية	30 إطارًا في الثانية
معدّل نقل بيانات الفيديو	‫800 كيلوبت في الثانية	‫2 ميغابت في الثانية	‫4 ميغابت في الثانية	‫10 ميغابت في الثانية

‫5.2.4. VP9

في حال توفّر برامج ترميز VP9 في عمليات تنفيذ الأجهزة، يجب أن:

‫[C-1-2] يجب أن يتوافق مع المستوى 3 من Profile 0.
‫[C-1-1] يجب أن يتيح كتابة ملفات Matroska WebM.
[C-1-3] يجب إنشاء بيانات CodecPrivate.
يجب أن تتوافق مع ملفات تعريف فك الترميز عالية الدقة كما هو موضّح في الجدول التالي.
[C-SR-1] يُنصح بشدة بتوفير إمكانية فك ترميز ملفات تعريف HD كما هو موضح في الجدول التالي في حال توفّر أداة ترميز للأجهزة.

	دقة عادية	دقة عالية - 720p	دقة عالية - 1080p	دقة فائقة
دقة الفيديو	‫720 × 480 بكسل	‫1280 × 720 بكسل	‫‎1920 x 1080 بكسل	‫3840 × 2160 بكسل
عدد اللقطات في الثانية في الفيديو	30 إطارًا في الثانية	30 إطارًا في الثانية	30 إطارًا في الثانية	30 إطارًا في الثانية
معدّل نقل بيانات الفيديو	‫1.6 ميغابت في الثانية	‫4 ميغابت في الثانية	5 ميغابت في الثانية	20 ميغابت في الثانية

إذا كانت عمليات تنفيذ الأجهزة تدّعي إتاحة استخدام Profile 2 أو Profile 3 من خلال واجهات برمجة التطبيقات الخاصة بالوسائط:

إنّ إتاحة تنسيق 12 بت هي أمر اختياري.

‫5.2.5. H.265

في حال توفّر برنامج الترميز H.265 في عمليات تنفيذ الأجهزة، يجب أن:

[C-1-1] يجب أن تتوافق مع "المستوى 3 من الملف الشخصي الرئيسي" بدقة تصل إلى 512 × 512.
[C-SR-1] يُنصح بشدة بتوفير ملف تعريف SD بدقة 720 × 480 وملفات تعريف الترميز عالية الدقة كما هو موضّح في الجدول التالي في حال توفّر برنامج ترميز للأجهزة.

	دقة عادية	دقة عالية - 720p	دقة عالية - 1080p	دقة فائقة
دقة الفيديو	‫720 × 480 بكسل	‫1280 × 720 بكسل	‫‎1920 x 1080 بكسل	‫3840 × 2160 بكسل
عدد اللقطات في الثانية في الفيديو	30 إطارًا في الثانية	30 إطارًا في الثانية	30 إطارًا في الثانية	30 إطارًا في الثانية
معدّل نقل بيانات الفيديو	‫1.6 ميغابت في الثانية	‫4 ميغابت في الثانية	5 ميغابت في الثانية	20 ميغابت في الثانية

‫5.2.6. AV1

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع ترميز AV1، يجب أن تستوفي ما يلي:

[C-1-1] يجب أن تتوافق مع "الملف الشخصي الرئيسي"، بما في ذلك المحتوى بدقة 8 بت و10 بت.
[C-1-2] يجب نشر بيانات الأداء، أي إعداد تقارير عن بيانات الأداء من خلال واجهات برمجة التطبيقات getSupportedFrameRatesFor() أو getSupportedPerformancePoints() لدرجات الدقة المتوافقة في الجدول أدناه.
‫[C-1-3] يجب قبول البيانات الوصفية ذات تنسيق HDR وإخراجها إلى دفق البتات

إذا كان برنامج ترميز AV1 يستخدم ميزة تسريع الأجهزة، سيتم:

[C-2-1] يجب أن يتوافق مع ما يصل إلى ملف تعريف ترميز HD1080p المضمّن في الجدول أدناه:

	دقة عادية	دقة عالية - 720p	دقة عالية - 1080p	دقة فائقة
دقة الفيديو	‫720 × 480 بكسل	‫1280 × 720 بكسل	‫‎1920 x 1080 بكسل	‫3840 × 2160 بكسل
عدد اللقطات في الثانية في الفيديو	30 إطارًا في الثانية	30 إطارًا في الثانية	30 إطارًا في الثانية	30 إطارًا في الثانية
معدّل نقل بيانات الفيديو	5 ميغابت في الثانية	‫8 ميغابت في الثانية	16 ميغابت في الثانية	‫50 ميغابت في الثانية

‫5.3. فك ترميز الفيديو

في حال كانت عمليات تنفيذ الأجهزة متوافقة مع برامج الترميز VP8 أو VP9 أو H.264 أو H.265 أو AV1، يجب أن تستوفي ما يلي:

[C-1-1] يجب أن تتوافق مع التبديل الديناميكي لدقة الفيديو وعدد اللقطات في الثانية من خلال واجهات برمجة التطبيقات العادية لنظام التشغيل Android ضمن البث نفسه لجميع برامج الترميز VP8 وVP9 وH.264 وH.265 وAV1 في الوقت الفعلي وبدقة تصل إلى الحد الأقصى الذي يتيحه كل برنامج ترميز على الجهاز.

‫5.3.1. MPEG-2

في حال توفُّر برامج ترميز MPEG-2 في عمليات تنفيذ الأجهزة، يجب أن:

[C-1-1] يجب أن يتوافق مع "الملف الشخصي الرئيسي" عالي المستوى.

‫5.3.2. H.263

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع برامج فك ترميز H.263، يجب أن:

[C-1-1] يجب أن يتوافق مع المستوى 30 من الملف الشخصي للمرجع (دقة CIF وQCIF وSQCIF بمعدّل 30 لقطة في الثانية و384 كيلوبت في الثانية) والمستوى 45 (دقة QCIF وSQCIF بمعدّل 30 لقطة في الثانية و128 كيلوبت في الثانية).

‫5.3.3. MPEG-4

إذا كانت عمليات تنفيذ الأجهزة تتضمّن برامج ترميز MPEG-4، يجب أن:

[C-1-1] يجب أن يتوافق مع المستوى 3 من الملف الشخصي البسيط.

5.3.4. H.264

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع برامج فك ترميز H.264، يجب أن:

[C-1-1] يجب أن يتوافق مع "الملف الرئيسي" بالمستوى 3.1 و"الملف الشخصي للمرجع". إنّ التوافق مع ASO (ترتيب الشرائح العشوائي) وFMO (ترتيب وحدات الماكرو المرن) وRS (الشرائح المكرّرة) هو أمر اختياري.
[C-1-2] يجب أن يكون الجهاز قادرًا على فك ترميز الفيديوهات التي تتضمّن ملفات تعريف بدقة عادية (SD) مدرَجة في الجدول التالي وتم ترميزها باستخدام الملف الشخصي للمرجع وMain Profile Level 3.1 (بما في ذلك 720p30).
يجب أن يكون الجهاز قادرًا على فك ترميز الفيديوهات باستخدام ملفات تعريف الدقة العالية (HD) كما هو موضّح في الجدول التالي.

إذا كان الارتفاع الذي تعرضه الطريقة Display.getSupportedModes() يساوي دقة الفيديو أو أكبر منها، يجب أن تتضمّن عمليات تنفيذ الجهاز ما يلي:

[C-2-1] يجب أن تتوافق مع ملفات فك ترميز الفيديو بدقة 720p عالية الدقة الواردة في الجدول التالي.
‫[C-2-2] يجب أن تتوافق مع ملفات تعريف فك ترميز الفيديو بدقة 1080p عالية الوضوح الواردة في الجدول التالي.

	الدقة العادية (جودة منخفضة)	الدقة العادية (جودة عالية)	دقة عالية - 720p	دقة عالية - 1080p
دقة الفيديو	‫320 × 240 بكسل	‫720 × 480 بكسل	‫1280 × 720 بكسل	‫‎1920 x 1080 بكسل
عدد اللقطات في الثانية في الفيديو	30 إطارًا في الثانية	30 إطارًا في الثانية	‫60 لقطة في الثانية	‫30 لقطة في الثانية (‫60 لقطة في الثانية^{تلفزيون})
معدّل نقل بيانات الفيديو	‫800 كيلوبت في الثانية	‫2 ميغابت في الثانية	‫8 ميغابت في الثانية	20 ميغابت في الثانية

5.3.5. ‫H.265 (HEVC)

في حال توفّر برنامج الترميز H.265 في عمليات تنفيذ الأجهزة، يجب أن:

[C-1-1] يجب أن تتوافق مع المستوى 3 من الملف الرئيسي وفئة SD الرئيسية لفك ترميز الفيديو، كما هو موضّح في الجدول التالي.
يجب أن تتوافق مع ملفات تعريف فك الترميز عالية الدقة كما هو موضّح في الجدول التالي.
‫[C-1-2] يجب أن تتوافق الأجهزة مع ملفات فك الترميز عالية الدقة كما هو موضّح في الجدول التالي في حال توفّر برنامج فك ترميز للأجهزة.

إذا كان الارتفاع الذي تعرضه الطريقة Display.getSupportedModes() يساوي درجة دقة الفيديو أو أكبر منها، يجب اتّخاذ الإجراءات التالية:

‫[C-2-1] يجب أن تتوافق عمليات تنفيذ الأجهزة مع ترميز واحد على الأقل من H.265 أو VP9 لملفات تعريف 720 و1080 وUHD.

	الدقة العادية (جودة منخفضة)	الدقة العادية (جودة عالية)	دقة عالية - 720p	دقة عالية - 1080p	دقة فائقة
دقة الفيديو	‫352 × 288 بكسل	‫720 × 480 بكسل	‫1280 × 720 بكسل	‫‎1920 x 1080 بكسل	‫3840 × 2160 بكسل
عدد اللقطات في الثانية في الفيديو	30 إطارًا في الثانية	30 إطارًا في الثانية	30 إطارًا في الثانية	‫30/60 لقطة في الثانية (60 لقطة في الثانية^{تلفزيون مزوّد ببرنامج ترميز H.265})	‫60 لقطة في الثانية
معدّل نقل بيانات الفيديو	600 كيلوبت في الثانية	‫1.6 ميغابت في الثانية	‫4 ميغابت في الثانية	5 ميغابت في الثانية	20 ميغابت في الثانية

إذا كانت عمليات تنفيذ الأجهزة تدّعي إتاحة ملف تعريف HDR من خلال واجهات برمجة التطبيقات الخاصة بالوسائط:

[C-3-1] يجب أن تقبل عمليات تنفيذ الأجهزة البيانات الوصفية المطلوبة ذات تنسيق HDR من التطبيق، وأن تتيح استخراج البيانات الوصفية المطلوبة ذات تنسيق HDR وإخراجها من دفق البتات و/أو الحاوية.
[C-3-2] يجب أن تعرض عمليات تنفيذ الأجهزة المحتوى بتكنولوجيا HDR بشكل صحيح على شاشة الجهاز أو على منفذ إخراج فيديو عادي (مثل HDMI).

‫5.3.6. VP8

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع ترميز VP8، يجب أن:

[C-1-1] يجب أن تتوافق مع ملفات تعريف فك ترميز الدقة العادية في الجدول التالي.
يجب استخدام برنامج ترميز VP8 للأجهزة يستوفي المتطلبات.
يجب أن تتوافق مع ملفات تعريف فك الترميز عالية الدقة في الجدول التالي.

إذا كان الارتفاع الذي تعرضه الطريقة Display.getSupportedModes() يساوي درجة دقة الفيديو أو أكبر منها، يجب اتّباع ما يلي:

[C-2-1] يجب أن تتوافق عمليات تنفيذ الأجهزة مع ملفات 720p الشخصية الواردة في الجدول التالي.
[C-2-2] يجب أن تتوافق عمليات تنفيذ الأجهزة مع ملفات 1080p الشخصية الواردة في الجدول التالي.

	الدقة العادية (جودة منخفضة)	الدقة العادية (جودة عالية)	دقة عالية - 720p	دقة عالية - 1080p
دقة الفيديو	‫320 × 180 بكسل	‫640 × 360 بكسل	‫1280 × 720 بكسل	‫‎1920 x 1080 بكسل
عدد اللقطات في الثانية في الفيديو	30 إطارًا في الثانية	30 إطارًا في الثانية	‫30 لقطة في الثانية (‫60 لقطة في الثانية^{تلفزيون})	‫30 (60 لقطة في الثانية^{تلفزيون})
معدّل نقل بيانات الفيديو	‫800 كيلوبت في الثانية	‫2 ميغابت في الثانية	‫8 ميغابت في الثانية	20 ميغابت في الثانية

5.3.7. VP9

في حال توفّر برامج ترميز VP9 في عمليات تنفيذ الأجهزة، يجب أن:

[C-1-1] يجب أن تتوافق الأجهزة مع ملفات تعريف فك ترميز الفيديو بدقة عادية (SD) كما هو موضّح في الجدول التالي.
يجب أن تتوافق مع ملفات تعريف فك الترميز عالية الدقة كما هو موضّح في الجدول التالي.

في حال كانت عمليات تنفيذ الأجهزة تتوافق مع ترميز VP9 وبرنامج فك ترميز للأجهزة:

[C-2-1] يجب أن تتوافق مع ملفات تعريف فك الترميز بدقة عالية (HD) كما هو موضّح في الجدول التالي.

[C-3-1] يجب أن تتوافق عمليات تنفيذ الأجهزة مع ترميز واحد على الأقل من VP9 أو H.265 للملفات الشخصية بدقة 720 و1080 وUHD.

	الدقة العادية (جودة منخفضة)	الدقة العادية (جودة عالية)	دقة عالية - 720p	دقة عالية - 1080p	دقة فائقة
دقة الفيديو	‫320 × 180 بكسل	‫640 × 360 بكسل	‫1280 × 720 بكسل	‫‎1920 x 1080 بكسل	‫3840 × 2160 بكسل
عدد اللقطات في الثانية في الفيديو	30 إطارًا في الثانية	30 إطارًا في الثانية	30 إطارًا في الثانية	‫30 لقطة في الثانية (^{تلفزيون مزوّد ببرنامج ترميز VP9}: 60 لقطة في الثانية)	‫60 لقطة في الثانية
معدّل نقل بيانات الفيديو	600 كيلوبت في الثانية	‫1.6 ميغابت في الثانية	‫4 ميغابت في الثانية	5 ميغابت في الثانية	20 ميغابت في الثانية

في حال ادّعت عمليات تنفيذ الأجهزة أنّها تتوافق مع VP9Profile2 أو VP9Profile3 من خلال واجهات برمجة تطبيقات الوسائط CodecProfileLevel:

إنّ إتاحة تنسيق 12 بت هي أمر اختياري.

إذا كانت عمليات تنفيذ الأجهزة تدّعي إتاحة ملف تعريف HDR (VP9Profile2HDR وVP9Profile2HDR10Plus وVP9Profile3HDR وVP9Profile3HDR10Plus) من خلال واجهات برمجة التطبيقات الخاصة بالوسائط:

[C-4-1] يجب أن تقبل عمليات تنفيذ الأجهزة البيانات الوصفية المطلوبة ذات النطاق العالي الديناميكية (KEY_HDR_STATIC_INFO لجميع ملفات تعريف النطاق العالي الديناميكية، بالإضافة إلى ‎KEY_HDR10_PLUS_INFO لملفات تعريف HDR10Plus) من التطبيق. ويجب أيضًا أن تتوافق مع استخراج البيانات الوصفية المطلوبة ذات تنسيق HDR من حزمة البيانات و/أو الحاوية وإخراجها.
[C-4-2] يجب أن تعرض عمليات تنفيذ الأجهزة المحتوى بتكنولوجيا HDR بشكل صحيح على شاشة الجهاز أو على منفذ إخراج فيديو عادي (مثل HDMI).

5.3.8. Dolby Vision

إذا كانت عمليات تنفيذ الأجهزة تعلن عن إتاحة برنامج فك ترميز Dolby Vision من خلال HDR_TYPE_DOLBY_VISION، عليها استيفاء ما يلي:

[C-1-1] يجب توفير أداة استخراج متوافقة مع تقنية Dolby Vision.
‫[C-1-2] يجب أن يعرض الجهاز محتوى Dolby Vision بشكل صحيح إما على شاشة الجهاز أو على شاشة خارجية متصلة عبر منفذ إخراج فيديو عادي (مثل HDMI).
[C-1-3] يجب ضبط معرّف المسار للطبقات الأساسية المتوافقة مع الإصدارات السابقة (إذا كانت متوفرة) ليكون هو نفسه معرّف المسار للطبقة المدمجة بتقنية Dolby Vision.

5.3.9. AV1

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع ترميز AV1 وتتيحه للتطبيقات التابعة لجهات خارجية، يجب أن تستوفي ما يلي:

[C-1-1] يجب أن تتوافق مع "الملف الشخصي الرئيسي"، بما في ذلك المحتوى بدقة 8 بت و10 بت.

إذا كانت عمليات تنفيذ الأجهزة توفّر دعمًا لبرنامج الترميز AV1 مع برنامج فك ترميز مزوّد بميزة تسريع الأجهزة، يجب أن تستوفي ما يلي:

[C-2-1] يجب أن يكون الجهاز قادرًا على فك ترميز ملفات الفيديو بدقة 720p عالية الدقة على الأقل من الجدول أدناه عندما يكون الارتفاع الذي تعرضه الطريقة Display.getSupportedModes() مساويًا أو أكبر من 720p.
[C-2-2] يجب أن يكون الجهاز قادرًا على فك ترميز ملفات الفيديو بدقة 1080p عالية الدقة على الأقل من الجدول أدناه عندما يكون الارتفاع الذي تعرضه الطريقة Display.getSupportedModes() مساويًا أو أكبر من 1080p.

	دقة عادية	دقة عالية - 720p	دقة عالية - 1080p	دقة فائقة
دقة الفيديو	‫720 × 480 بكسل	‫1280 × 720 بكسل	‫‎1920 x 1080 بكسل	‫3840 × 2160 بكسل
عدد اللقطات في الثانية في الفيديو	30 إطارًا في الثانية	30 إطارًا في الثانية	30 إطارًا في الثانية	30 إطارًا في الثانية
معدّل نقل بيانات الفيديو	5 ميغابت في الثانية	‫8 ميغابت في الثانية	16 ميغابت في الثانية	‫50 ميغابت في الثانية

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع ملف تعريف HDR من خلال واجهات برمجة التطبيقات الخاصة بالوسائط، فإنّها:

‫[C-3-1] يجب أن يتيح استخراج البيانات الوصفية ذات تنسيق HDR وإخراجها من دفق البتات و/أو الحاوية.
‫[C-3-2] يجب أن يعرض الجهاز المحتوى بتكنولوجيا HDR بشكل صحيح على شاشة الجهاز أو على منفذ إخراج فيديو عادي (مثل HDMI).

5.4. تسجيل الصوت

على الرغم من أنّ بعض المتطلبات الموضّحة في هذا القسم تم إدراجها على أنّها SHOULD منذ الإصدار 4.3 من نظام التشغيل Android، من المخطّط أن يتم تغييرها إلى MUST في تعريف التوافق للإصدارات المستقبلية. يُنصح بشدة بأن تستوفي أجهزة Android الحالية والجديدة هذه المتطلبات المُدرَجة على أنّها متطلبات يُفضَّل استيفاؤها، وإلا لن تتمكّن من تحقيق التوافق مع Android عند الترقية إلى الإصدار المستقبلي.

‫5.4.1. تسجيل الصوت الخام ومعلومات الميكروفون

إذا كانت عمليات تنفيذ الأجهزة تعرّف android.hardware.microphone، فإنّها:

[C-1-1] يجب السماح بتسجيل محتوى الصوت الخام لأي بث INPUT من النوع AudioRecord أو AAudio يتم فتحه بنجاح. يجب أن تتوفّر الخصائص التالية كحدّ أدنى:
- التنسيق: Linear PCM، ‏16 بت
- معدّلات البيانات في الملف الصوتي: 8000 و11025 و16000 و44100 و48000 هرتز
- القنوات: أحادية
- مصادر الصوت: DEFAULT أو MIC أو CAMCORDER أو VOICE_RECOGNITION أو VOICE_COMMUNICATION أو UNPROCESSED أو VOICE_PERFORMANCE ينطبق ذلك أيضًا على إعدادات Input Presets المكافئة في AAudio، مثل AAUDIO_INPUT_PRESET_CAMCORDER.
يجب السماح بتسجيل المحتوى الصوتي الأولي الذي يتضمّن الخصائص التالية:
- التنسيق: Linear PCM، ‏16 بت و24 بت
- معدّلات أخذ العيّنات: 8000 و11025 و16000 و22050 و24000 و32000 و44100 و48000 هرتز
- القنوات: عدد القنوات يساوي عدد الميكروفونات على الجهاز
‫[C-1-2] يجب تسجيل الصوت بمعدّلات بيانات أعلى بدون زيادة معدّل البيانات.
‫[C-1-3] يجب تضمين فلتر مناسب لتنعيم الحواف عند تسجيل معدّلات أخذ العيّنات المذكورة أعلاه مع خفض معدّل أخذ العيّنات.
يجب أن تسمح هذه الفئة بتسجيل محتوى صوتي خام بجودة راديو AM وجودة DVD، ما يعني توفُّر الخصائص التالية:
- التنسيق: Linear PCM،‏ 16 بت
- معدّلات أخذ العيّنات: 22050 أو 48000 هرتز
- القنوات: استيريو
[C-1-4] يجب أن يلتزم الجهاز بواجهة برمجة التطبيقات MicrophoneInfo وأن يملأ المعلومات بشكل صحيح عن الميكروفونات المتاحة على الجهاز التي يمكن للتطبيقات الخارجية الوصول إليها من خلال واجهة برمجة التطبيقات AudioManager.getMicrophones() ، وذلك لتسجيل الصوت النشط باستخدام MediaRecorder.AudioSources DEFAULT أو MIC أو CAMCORDER أو VOICE_RECOGNITION أو VOICE_COMMUNICATION أو UNPROCESSED أو VOICE_PERFORMANCE. إذا كانت عمليات تنفيذ الأجهزة تسمح بالتقاط محتوى صوتي أولي بجودة راديو AM أو DVD، يجب أن تستوفي ما يلي:
‫[C-2-1] يجب التسجيل بدون زيادة معدّل أخذ العيّنات بأي نسبة أعلى من 16000:22050 أو 44100:48000.
[C-2-2] يجب أن يتضمّن فلترًا مناسبًا لتنعيم الحواف عند إجراء أي عملية زيادة أو تقليل في عدد العيّنات.

5.4.2. تسجيل الصوت للتعرّف عليه

إذا كانت عمليات تنفيذ الأجهزة تعرّف android.hardware.microphone، فإنّها:

[C-1-1] يجب تسجيل مصدر الصوت android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION بمعدل بيانات 44100 أو 48000.
[C-1-2] يجب، بشكلٍ تلقائي، إيقاف أي معالجة صوتية لتقليل الضوضاء عند تسجيل بث صوتي من مصدر الصوت AudioSource.VOICE_RECOGNITION.
[C-1-3] يجب، بشكلٍ تلقائي، إيقاف أي تحكّم تلقائي في مستوى الصوت عند تسجيل بث صوتي من مصدر الصوت AudioSource.VOICE_RECOGNITION.
يجب أن تعرض خصائص السعة مقابل التردد المسطحة تقريبًا في نطاق التردد المتوسط: تحديدًا ±3 ديسيبل من 100 هرتز إلى 4000 هرتز لكل ميكروفون مستخدَم لتسجيل مصدر الصوت الخاص بميزة "التعرّف على الصوت".
[C-SR-1] يُنصح بشدة بأن تعرض مستويات السعة في نطاق التردد المنخفض، وتحديدًا من ±20 ديسيبل من 30 هرتز إلى 100 هرتز مقارنةً بنطاق التردد المتوسط لكل ميكروفون مستخدَم لتسجيل مصدر الصوت الخاص بالتعرّف على الصوت.
[C-SR-2] يُنصح بشدة بعرض مستويات السعة في نطاق التردد العالي: تحديدًا من ±30 ديسيبل من 4000 هرتز إلى 22 كيلو هرتز مقارنةً بنطاق التردد المتوسط لكل ميكروفون مستخدَم لتسجيل مصدر الصوت الخاص بالتعرّف على الصوت.
يجب ضبط حساسية إدخال الصوت بحيث يؤدي مصدر نغمي جيبي بتردد 1000 هرتز يتم تشغيله بمستوى ضغط صوت (SPL) يبلغ 90 ديسيبل (يتم قياسه بجانب الميكروفون) إلى استجابة مثالية تبلغ 2500 RMS ضمن نطاق يتراوح بين 1770 و3530 لعينات 16 بت (أو -22.35 ديسيبل ±3 ديسيبل على المقياس الكامل لعينات النقطة العائمة/الدقة المزدوجة) لكل ميكروفون مستخدَم لتسجيل مصدر الصوت الخاص بالتعرّف على الصوت.
يجب أن تسجّل دفق الصوت الخاص بالتعرّف على الصوت، وذلك لكي تتتبّع مستويات سعة PCM بشكل خطي التغييرات في مستوى ضغط الصوت (SPL) للإدخال على مدى نطاق 30 ديسيبل على الأقل من -18 ديسيبل إلى +12 ديسيبل بالنسبة إلى 90 ديسيبل SPL عند الميكروفون.
يجب أن تسجّل بث الصوت الخاص بميزة "التعرّف على الصوت" مع تشويه توافقي إجمالي (THD) أقل من% 1 عند مستوى إدخال يبلغ 90 ديسيبل SPL عند 1 كيلو هرتز في الميكروفون.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن تكنولوجيات android.hardware.microphone وإلغاء الضوضاء (أو خفضها) التي تم ضبطها للتعرّف على الكلام، يجب أن تستوفي ما يلي:

[C-2-1] يجب أن تسمح واجهة برمجة التطبيقات android.media.audiofx.NoiseSuppressor بالتحكّم في هذا التأثير الصوتي.
[C-2-2] يجب أن تحدّد قيمة الحقل AudioEffect.Descriptor.uuid بشكلٍ فريد كل عملية تنفيذ لتكنولوجيا كتم الضوضاء.

5.4.3. تسجيل اللقطات لإعادة توجيه التشغيل

يتضمّن الصف android.media.MediaRecorder.AudioSource مصدر الصوت REMOTE_SUBMIX.

في حال تضمين عمليات تنفيذ الأجهزة كلاً من android.hardware.audio.output وandroid.hardware.microphone، يجب أن تستوفي ما يلي:

[C-1-1] يجب تنفيذ مصدر الصوت REMOTE_SUBMIX بشكل صحيح حتى يتمكّن التطبيق عند استخدام واجهة برمجة التطبيقات android.media.AudioRecord للتسجيل من مصدر الصوت هذا، من التقاط مزيج من جميع مصادر الصوت باستثناء ما يلي:
- AudioManager.STREAM_RING
- AudioManager.STREAM_ALARM
- AudioManager.STREAM_NOTIFICATION

5.4.4. إلغاء الصدى

إذا كانت عمليات تنفيذ الأجهزة تعرّف android.hardware.microphone، فإنّها:

يجب تنفيذ تكنولوجيا إلغاء الصدى الصوتي (AEC) التي تم ضبطها للاتصال الصوتي وتطبيقها على مسار الالتقاط عند الالتقاط باستخدام AudioSource.VOICE_COMMUNICATION.

إذا كانت عمليات تنفيذ الأجهزة توفّر ميزة "إلغاء الصدى الصوتي" التي يتم إدراجها في مسار الصوت الملتقط عند اختيار AudioSource.VOICE_COMMUNICATION، يجب أن تستوفي ما يلي:

[C-SR-1] [C-1-1] يُنصح بشدة يجب الإفصاح عن ذلك من خلال طريقة واجهة برمجة التطبيقات AcousticEchoCanceler AcousticEchoCanceler.isAvailable() التي تعرض القيمة true.

[C-1-2] يجب أن يعكس تفعيل ميزة AEC في مسار الصوت لأجهزة غير الساعات الذكية من خلال طريقة AcousticEchoCanceler API AcousticEchoCanceler.getEnabled، التي يجب أن تعرض true عند التفعيل، وfalse عند الإيقاف.

ننصح بشدة باستخدام [C-SR-2] [C-SR-1] للسماح بالتحكّم في هذا التأثير الصوتي باستخدام واجهة برمجة التطبيقات AcousticEchoCanceler.
يُنصح بشدة باستخدام [C-SR-3] [C-SR-2] لتحديد كل عملية تنفيذ لتكنولوجيا AEC بشكل فريد من خلال الحقل AudioEffect.Descriptor.uuid.

5.4.5. التسجيل المتزامن

إذا كانت عمليات تنفيذ الأجهزة تعرّف android.hardware.microphone، يجب أن تنفّذ عملية الالتقاط المتزامن كما هو موضّح في هذا المستند. وعلى وجه التحديد:

[C-1-1] يجب السماح لخدمة تسهيل الاستخدام بالوصول إلى الميكروفون في الوقت نفسه الذي يصل فيه تطبيق آخر إلى الميكروفون باستخدام أي AudioSource، وذلك من خلال التقاط الصوت باستخدام AudioSource.VOICE_RECOGNITION.
[C-1-2] يجب السماح لتطبيق مثبَّت مسبقًا بدور "مساعد" بالوصول إلى الميكروفون في الوقت نفسه مع تطبيق واحد على الأقل يسجّل باستخدام أي AudioSource باستثناء AudioSource.VOICE_COMMUNICATION أو AudioSource.CAMCORDER.
[C-1-3] يجب إيقاف تسجيل الصوت لأي تطبيق آخر، باستثناء خدمة مخصّصة لتسهيل الاستخدام، أثناء تسجيل تطبيق باستخدام AudioSource.VOICE_COMMUNICATION أو AudioSource.CAMCORDER. ومع ذلك، عندما يسجّل تطبيق مكالمة صوتية باستخدام AudioSource.VOICE_COMMUNICATION، يمكن لتطبيق آخر تسجيل المكالمة الصوتية إذا كان تطبيقًا ذا امتيازات (مثبَّتًا مسبقًا) ولديه الإذن CAPTURE_AUDIO_OUTPUT.
[C-1-4] إذا كانت هناك تطبيقات متعدّدة تسجّل الصوت في الوقت نفسه ولم يكن أي منها يعرض واجهة مستخدم في المقدّمة، سيتم توجيه الصوت إلى التطبيق الذي بدأ التسجيل مؤخرًا.

‫5.5. تشغيل الصوت

يتضمّن نظام التشغيل Android إمكانية السماح للتطبيقات بتشغيل الصوت من خلال جهاز إخراج الصوت الطرفي كما هو محدّد في الفقرة 7.8.2.

5.5.1. تشغيل الصوت الخام

إذا كانت عمليات تنفيذ الأجهزة تعرّف android.hardware.audio.output، فإنّها:

[C-1-1] يجب أن يسمح الجهاز بتشغيل محتوى صوتي غير معدَّل يتضمّن الخصائص التالية:
- تنسيقات المصدر: Linear PCM، و16 بت، و8 بت، وfloat
- القنوات: أحادية، استيريو، إعدادات صالحة لقنوات متعددة تتضمّن 8 قنوات كحدّ أقصى
- معدّلات أخذ العيّنات (بالهرتز):
  - ‫8000 و11025 و16000 و22050 و24000 و32000 و44100 و48000 في إعدادات القنوات المذكورة أعلاه
  - ‫96000 في وضعَي الصوت الأحادي والاستيريو

‫5.5.2. المؤثرات الصوتية

يوفر نظام التشغيل Android واجهة برمجة تطبيقات لتأثيرات الصوت لعمليات تنفيذ الأجهزة.

إذا كانت عمليات تنفيذ الأجهزة تعرّف الميزة android.hardware.audio.output، عليها استيفاء ما يلي:

[C-1-1] يجب أن تتوافق مع عمليات التنفيذ EFFECT_TYPE_EQUALIZER وEFFECT_TYPE_LOUDNESS_ENHANCER التي يمكن التحكّم فيها من خلال الفئات الفرعية Equalizer وLoudnessEnhancer من AudioEffect.
‫[C-1-2] يجب أن تتوافق مع تنفيذ واجهة برمجة التطبيقات الخاصة بأداة العرض المرئي، ويمكن التحكّم فيها من خلال الفئة Visualizer.
[C-1-3] يجب أن يتيح تنفيذ EFFECT_TYPE_DYNAMICS_PROCESSING الذي يمكن التحكّم فيه من خلال الفئة الفرعية AudioEffect DynamicsProcessing.
[C-1-4] يجب أن تتوافق التأثيرات الصوتية مع الإدخال والإخراج بنقطة عائمة، وذلك عند عرض نتائج التأثيرات في مسار معالجة الصوت في إطار العمل. يشير ذلك إلى المؤثرات الصوتية النموذجية التي يتم إدخالها أو المؤثرات المساعدة، مثل معادل الصوت. يُنصح بشدة باستخدام سلوك مكافئ عندما لا تكون نتائج التأثير مرئية من خلال مسار الصوت في إطار العمل، مثل التأثيرات التي تتم معالجتها لاحقًا أو التأثيرات التي يتم تفريغها.
[C-1-5] يجب التأكّد من أنّ المؤثرات الصوتية تتوافق مع قنوات متعددة تصل إلى عدد قنوات الخلاط المعروف أيضًا باسم FCC_LIMIT، وذلك عند إرجاع نتائج التأثير إلى مسار الصوت في إطار العمل. يشير ذلك إلى التأثيرات النموذجية التي يتم إدراجها أو التأثيرات المساعدة، ولكنّه يستثني التأثيرات الخاصة، مثل خفض عدد القنوات أو زيادته أو تأثيرات التجسيم التي تغيّر عدد القنوات. يُنصح باستخدام السلوك المكافئ عندما لا تكون التأثيرات مرئية من خلال مسار بيانات الصوت في إطار العمل، مثل التأثيرات التي تتم معالجتها بعد التسجيل أو التأثيرات التي تتم معالجتها خارج الجهاز.
يجب أن تتوافق مع عمليات تنفيذ EFFECT_TYPE_BASS_BOOST وEFFECT_TYPE_ENV_REVERB وEFFECT_TYPE_PRESET_REVERB وEFFECT_TYPE_VIRTUALIZER التي يمكن التحكّم فيها من خلال الفئات الفرعية AudioEffect، أي BassBoost وEnvironmentalReverb وPresetReverb وVirtualizer.
[C-SR-1] يُنصح بشدة بتوفير تأثيرات في الفاصلة العائمة والقنوات المتعددة.

5.5.3. مستوى صوت الإخراج

عمليات تنفيذ أجهزة السيارات:

يجب السماح بضبط مستوى صوت كل بث صوتي بشكل منفصل باستخدام نوع المحتوى أو الاستخدام المحدّد في AudioAttributes واستخدام الصوت في السيارة كما هو محدّد بشكل علني في android.car.CarAudioManager.

5.5.4. تخفيف حِمل وحدة الصوت

في حال توفير عمليات تنفيذ الأجهزة تشغيل الصوت المخفَّف، يجب أن تتضمّن ما يلي:

[C-SR-1] يُنصح بشدة باقتطاع المحتوى الصوتي الذي يتم تشغيله بدون انقطاع بين مقطعين بالتنسيق نفسه عندما يحدّد ذلك واجهة برمجة التطبيقات AudioTrack gapless وحاوية الوسائط الخاصة بـ MediaPlayer.
[C-SR-2] يُنصح بشدة بتنفيذ ميزة "تشغيل المحتوى بدون اتصال بالإنترنت" للتنسيقات AAC وMP3 وOPUS وPCM.

إذا كانت عمليات تنفيذ الأجهزة تعلن عن إتاحة إيقاف تحميل MMAP PCM (يتم الإعلان عن ذلك من خلال منفذ مختلط يتضمّن علامات تحتوي على AUDIO_OUTPUT_FLAG_COMPRESS_OFFLOAD وAUDIO_OUTPUT_FLAG_MMAP_NOIRQ)، فإنّها:

[C-1-1] يجب أن تتوافق مع AUDIO_FORMAT_PCM_16_BIT على الأقل، بمعدّل 44.1 كيلوهرتز و48 كيلوهرتز للصوت الاستيريو والأحادي.
[C-1-2] يجب أن يكون حجم المخزن المؤقت قادرًا على تخزين ما لا يقل عن 5 ثوانٍ من الصوت بمعدل 48 كيلوهرتز استيريو PCM 16 بت لكل عينة.

5.5.5. مَعلمات التشغيل

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع PlaybackParams API، ستكون معلَمات التشغيل:

‫[C-1-1] يجب أن تتوافق مع السرعات بين 0.5 و2.0 مع درجة صوت تبلغ 1.0.

‫5.6. وقت استجابة الصوت

وقت استجابة الصوت هو التأخير الزمني الذي يحدث أثناء مرور إشارة صوتية عبر النظام. تعتمد العديد من فئات التطبيقات على معدلات تأخير منخفضة لتحقيق تأثيرات صوتية في الوقت الفعلي.

لأغراض هذا القسم، استخدِم التعريفات التالية:

وقت استجابة الإخراج الفاصل الزمني بين كتابة تطبيق لإطار بيانات مرمز بتنسيق PCM وعرض الصوت المقابل في البيئة باستخدام محوّل طاقة على الجهاز فقط أو مغادرة الإشارة للجهاز عبر منفذ وإمكانية ملاحظتها خارجيًا
وقت استجابة الإخراج البارد الوقت بين بدء بث الإخراج ووقت عرض الإطار الأول استنادًا إلى الطوابع الزمنية، عندما يكون نظام إخراج الصوت غير مستخدَم من قِبل أي برنامج حاليًا وتم إيقاف تشغيله قبل الطلب
وقت استجابة الناتج المتواصل وقت الاستجابة الناتج عن عرض اللقطات اللاحقة، بعد أن يبدأ الجهاز في تشغيل الصوت
وقت استجابة الإدخال الفاصل الزمني بين وقت عرض الصوت من خلال البيئة إلى الجهاز في محوّل طاقة على الجهاز فقط أو إدخال إشارة إلى الجهاز عبر منفذ ووقت قراءة تطبيق لإطار البيانات المقابل المرمّز بتنسيق PCM.
فقدان البيانات الجزء الأوّلي من إشارة الإدخال الذي لا يمكن استخدامه أو غير متوفّر.
وقت استجابة الإدخال البارد الوقت بين بدء البث وتلقّي أول إطار صالح، عندما يكون نظام إدخال الصوت غير نشط وتم إيقاف تشغيله قبل الطلب
وقت استجابة الإدخال المتواصل وقت الاستجابة للإدخال في اللقطات اللاحقة، أثناء تسجيل الجهاز للصوت
وقت الاستجابة المتواصل بين الجهازين مجموع وقت استجابة الإدخال المتواصل ووقت استجابة الإخراج المتواصل بالإضافة إلى فترة تخزين مؤقت واحدة تتيح فترة التخزين المؤقت للتطبيق وقتًا لمعالجة الإشارة ووقتًا للحد من فرق الطور بين تدفقات الإدخال والإخراج.
واجهة برمجة التطبيقات OpenSL ES PCM buffer queue مجموعة واجهات برمجة التطبيقات ذات الصلة بترميز PCM في OpenSL ES ضمن Android NDK
AAudio native audio API مجموعة واجهات برمجة التطبيقات AAudio ضمن حزمة تطوير البرامج الأصلية (NDK) لنظام التشغيل Android
الطابع الزمني هي زوج يتألف من موضع إطار نسبي ضمن بث ووقت تقديري لدخول هذا الإطار إلى مسار معالجة الصوت أو خروجه منه على نقطة النهاية المرتبطة. راجِع أيضًا AudioTimestamp.
glitch انقطاع مؤقت أو قيمة عيّنة غير صحيحة في إشارة الصوت، ويحدث ذلك عادةً بسبب نقص في المخزن المؤقت للإخراج أو زيادة في المخزن المؤقت للإدخال أو أي مصدر آخر للتشويش الرقمي أو التناظري.
متوسط الانحراف المطلق (MAD) متوسط القيمة المطلقة للانحرافات عن المتوسط لمجموعة من القيم
وقت استجابة النقر إلى إصدار الصوت (TTL)، كما يتم قياسه باستخدام أداة CTS Verifier، هو الوقت الفاصل بين النقر على الشاشة وسماع الصوت الناتج عن هذا النقر على مكبّر الصوت. يتم حساب هذا المتوسط على مدار 5 قياسات باستخدام واجهة برمجة تطبيقات الصوت الأصلية AAudio للإخراج.
وقت الاستجابة الكامل (RTL)، كما يتم قياسه باستخدام CTS Verifier، هو متوسط وقت الاستجابة المستمر على مدار 5 قياسات، ويتم قياسه على مسار إعادة توجيه يعيد إرسال الناتج إلى الإدخال، وذلك باستخدام واجهة برمجة التطبيقات الأصلية AAudio.

مسارات الاسترجاع هي:
- مكبّر الصوت/الميكروفون: مكبّر صوت مدمج إلى ميكروفون مدمج
- الوضع التناظري: مقبس تناظري مقاس 3.5 ملم ومحوّل إعادة توجيه
- USB: محوّل من USB إلى 3.5 ملم ومحوّل loopback أو واجهة صوت USB وكابلات loopback
‫FEATURE_AUDIO_LOW_LATENCY تم الإعلان عن ميزة android.hardware.audio.low_latency.
‫FEATURE_AUDIO_PRO تم الإعلان عن ميزة android.hardware.audio.pro.
MPC. فئة أداء الوسائط
وقت استجابة تتبُّع حركة الرأس تمثّل هذه السمة الوقت الذي يستغرقه رصد التغيير في الصوت الناتج عن حركة الرأس، وذلك بدءًا من رصد وحدة قياس القصور الذاتي (IMU) لحركة الرأس وحتى رصد محوّلات الطاقة في سماعات الرأس لهذا التغيير.

عمليات تنفيذ الجهاز:

[C-0-1] يجب التأكّد من أنّه عند استدعاء تطبيق android.media.AudioManager.setCommunicationDevice() باستخدام device متوافق (مثل سمّاعات الرأس السلكية أو مكبّرات الصوت أو سمّاعات الأذن المدمجة أو سمّاعات الرأس USB)، يتم استدعاء android.media.AudioManager.OnCommunicationDeviceChangedListener.onCommunicationDeviceChanged() مع جهاز الصوت هذا في غضون 1500 ملي ثانية من عرض true عند استدعاء setCommunicationDevice().

إذا كانت عمليات تنفيذ الأجهزة تعرّف android.hardware.audio.output، يجب أن تستوفي أو تتجاوز المتطلبات التالية:

[C-1-1] تمت إزالة هذا الشرط في Android 15.
‫[C-1-2] وقت استجابة الإخراج البارد يبلغ 500 مللي ثانية أو أقل.
‫[C-1-3] يجب أن يستغرق فتح بث إخراج باستخدام AAudioStreamBuilder_openStream() أقل من 1,000 مللي ثانية.
[C-1-4] يجب أن تكون معدّلات الكمون المحسوبة للذهاب والعودة استنادًا إلى الطوابع الزمنية للإدخال والإخراج التي تعرضها AAudioStream_getTimestamp في حدود 200 مللي ثانية من معدّل الكمون المقاس للذهاب والعودة في AAUDIO_PERFORMANCE_MODE_NONE وAAUDIO_PERFORMANCE_MODE_LOW_LATENCY للسماعات ومجموعات سماعات الرأس السلكية واللاسلكية.
[C-SR-1] تمت إزالة هذا الشرط في Android 15.
[C-SR-2] تمت إزالة هذا الشرط في الإصدار Android 15.
[C-SR-4] تمت إزالة هذا الشرط في Android 15.
[C-SR-5] تمت إزالة هذا الشرط في Android 15.
[C-SR-6] تمت إزالة هذا الشرط في Android 15.
[C-SR-7] تمت إزالة هذا الشرط في Android 15.
[C-2-1] تمت إزالة هذا الشرط في Android 15.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن android.hardware.microphone، يجب أن تستوفي متطلبات إدخال الصوت التالية:

[C-3-1] تمت إزالة هذا الشرط في Android 15.
‫[C-3-2] وقت استجابة الإدخال البارد يبلغ 500 مللي ثانية أو أقل.
‫[C-3-3] يجب ألا يستغرق فتح مصدر بيانات باستخدام AAudioStreamBuilder_openStream() أقل من 1,000 مللي ثانية.
[C-SR-8] تمت إزالة هذا الشرط في Android 15.
[C-SR-11] تمت إزالة هذا الشرط في الإصدار 15 من نظام التشغيل Android.
[C-SR-12] تمت إزالة هذا الشرط في Android 15.

يحدّد الجدول التالي متطلبات الكتابة من اليمين إلى اليسار لتطبيقات الأجهزة المحمولة المحدّدة في 2.2.1 التي تحدّد android.hardware.audio.output وandroid.hardware.microphone.

الجهاز والبيانات	RTT (بالمللي ثانية)	MAD (بالمللي ثانية)	مسارات الاسترجاع
حمل الكاميرا يدويًا	200	25	مكبّر الصوت/الميكروفون، مقبس صوت تناظري 3.5 ملم (إذا كان متوافقًا)، منفذ USB (إذا كان متوافقًا)
‫MPC 37 والإصدارات الأحدث	65	10	مسار واحد على الأقل
>= MPC_T (13) MPC 33 إلى MPC 36	80	15	مسار واحد على الأقل
FEATURE_AUDIO_LOW_LATENCY	50	10	مسار واحد على الأقل
FEATURE_AUDIO_PRO	25	5	مسار واحد على الأقل
FEATURE_AUDIO_PRO	20	5	تناظري (في حال توفّره)
FEATURE_AUDIO_PRO	25	5	USB (في حال عدم توفّر إشارة تناظرية)

يحدّد الجدول التالي متطلبات TTL لعمليات تنفيذ الأجهزة المحمولة كما هو محدّد في 2.2.1 التي تحدّد android.hardware.audio.output وandroid.hardware.microphone.

الجهاز والبيانات	مدة البقاء (بالملّي ثانية)
حمل الكاميرا يدويًا	250
‫MPC 37 والإصدارات الأحدث	65
>= MPC_T (13) MPC 33 إلى MPC 36	80
‫MPC_S (12) MPC 31	100
FEATURE_AUDIO_PRO	80

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة spatial audio مع تتبُّع حركة الرأس وتحدّد العلامة PackageManager.FEATURE_AUDIO_SPATIAL_HEADTRACKING_LOW_LATENCY، يجب أن تستوفي ما يلي:

‫[C-4-1] يجب أن يكون الحد الأقصى لوقت استجابة تتبُّع الرأس لتحديث الصوت أقل من 300 مللي ثانية.

‫5.7. بروتوكولات الشبكة

يجب أن تتوافق عمليات تنفيذ الأجهزة مع بروتوكولات شبكة الوسائط لتشغيل الصوت والفيديو على النحو المحدّد في مستندات حزمة تطوير البرامج (SDK) لنظام Android.

بالنسبة إلى كل برنامج ترميز وتنسيق حاوية يجب أن يتوافق معه تنفيذ الجهاز، يجب أن يتضمّن تنفيذ الجهاز ما يلي:

[C-1-1] يجب أن يتوافق مع برنامج الترميز أو الحاوية عبر HTTP وHTTPS.
[C-1-2] يجب أن تتوافق مع أشكال مقاطع الوسائط المقابلة كما هو موضّح في جدول أشكال مقاطع الوسائط أدناه عبر مسودة بروتوكول البث المباشر وفق بروتوكول HTTP، الإصدار 7.
[C-1-3] يجب أن تتوافق مع تنسيقات حمولة RTSP المقابلة كما هو موضّح في جدول RTSP أدناه. للاطّلاع على الاستثناءات، يُرجى الرجوع إلى الحواشي السفلية للجدول في القسم 5.1.

تنسيقات شرائح الوسائط

أشكال الشرائح	المراجع	برامج الترميز المتوافقة المطلوبة
MPEG-2 Transport Stream	ISO 13818	برامج ترميز الفيديو: H264 AVC MPEG-4 SP MPEG-2 راجِع الفقرة 5.1.8 للاطّلاع على تفاصيل حول H264 AVC وMPEG2-4 SP وMPEG-2. برامج ترميز الصوت: الترميز المتقدّم للصوت (AAC) راجِع الفقرة 5.1.3 للحصول على تفاصيل حول ترميز AAC وأشكاله المختلفة.
ملف AAC مع إطارات ADTS وعلامات ID3	ISO 13818-7	يمكنك الاطّلاع على الفقرة 5.1.1 لمزيد من التفاصيل حول ترميز AAC وأشكاله المختلفة.
WebVTT	WebVTT

أشكال الشرائح

المراجع

برامج الترميز المتوافقة المطلوبة

MPEG-2 Transport Stream

ISO 13818

برامج ترميز الفيديو:

H264 AVC
MPEG-4 SP
MPEG-2

راجِع الفقرة 5.1.8 للاطّلاع على تفاصيل حول H264 AVC وMPEG2-4 SP
وMPEG-2.

برامج ترميز الصوت:

الترميز المتقدّم للصوت (AAC)

راجِع الفقرة 5.1.3 للحصول على تفاصيل حول ترميز AAC وأشكاله المختلفة.

ملف AAC مع إطارات ADTS وعلامات ID3

ISO 13818-7

يمكنك الاطّلاع على الفقرة 5.1.1 لمزيد من التفاصيل حول ترميز AAC وأشكاله المختلفة.

WebVTT

‫RTSP (RTP وSDP)

اسم الملف الشخصي	المراجع	برامج الترميز المتوافقة المطلوبة
H264 AVC	RFC 6184	راجِع الفقرة 5.1.8 للحصول على تفاصيل حول H264 AVC
MP4A-LATM	RFC 6416	يمكنك الاطّلاع على الفقرة 5.1.3 لمزيد من التفاصيل حول ترميز AAC وأشكاله المختلفة.
H263-1998	RFC 3551 RFC 4629 RFC 2190	راجِع الفقرة 5.1.8 للحصول على تفاصيل حول H263
H263-2000	RFC 4629	راجِع الفقرة 5.1.8 للحصول على تفاصيل حول H263
AMR	RFC 4867	راجِع الفقرة 5.1.3 للحصول على تفاصيل حول AMR-NB
AMR-WB	RFC 4867	راجِع الفقرة 5.1.3 للحصول على تفاصيل حول AMR-WB
MP4V-ES	RFC 6416	راجِع الفقرة 5.1.8 للحصول على تفاصيل حول MPEG-4 SP
mpeg4-generic	RFC 3640	يمكنك الاطّلاع على الفقرة 5.1.3 لمزيد من التفاصيل حول ترميز AAC وأشكاله المختلفة.
MP2T	RFC 2250	راجِع MPEG-2 Transport Stream ضمن HTTP Live Streaming للحصول على التفاصيل.

‫5.8. Secure Media

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع إخراج الفيديو الآمن ويمكنها توفير مساحات آمنة، فإنّها:

[C-1-1] يجب الإعلان عن توفير الدعم لـ Display.FLAG_SECURE.

إذا كانت عمليات تنفيذ الأجهزة تعلن عن توفّر Display.FLAG_SECURE وتتيح بروتوكول عرض شاشة لاسلكي، عليها استيفاء ما يلي:

[C-2-1] يجب تأمين الرابط باستخدام آلية تشفير قوية، مثل HDCP 2.x أو إصدار أحدث، للشاشات المتصلة من خلال بروتوكولات لاسلكية، مثل Miracast.

إذا كانت عمليات تنفيذ الأجهزة تعلن عن إتاحة Display.FLAG_SECURE وإتاحة شاشة عرض خارجية متصلة بسلك، عليها استيفاء ما يلي:

‫[C-3-1] يجب أن تتوافق جميع شاشات العرض الخارجية المتصلة عبر منفذ سلكي يمكن للمستخدم الوصول إليه مع الإصدار 1.2 أو إصدار أحدث من بروتوكول HDCP.

5.9. الواجهة الرقمية للآلات الموسيقية (MIDI)

إذا كانت عمليات تنفيذ الأجهزة تشير إلى توفّر الميزة android.software.midi من خلال الفئة android.content.pm.PackageManager، فإنّها:

[C-1-1] يجب أن تتوافق مع MIDI عبر جميع عمليات نقل الأجهزة المتوافقة مع MIDI والتي توفّر اتصالاً عامًا غير متوافق مع MIDI، حيث تكون عمليات النقل هذه:
- وضع مضيف USB، الفقرة 7.7
- ‫MIDI عبر بلوتوث منخفض الطاقة الذي يعمل في دور مركزي، الفقرة 7.4.3
[C-1-2] يجب أن تتوافق مع نقل برامج MIDI بين التطبيقات (أجهزة MIDI الافتراضية)
[C-1-3] يجب تضمين libamidi.so (إتاحة MIDI الأصلية)
يجب أن تتوافق مع وضع الأجهزة الطرفية MIDI عبر USB، الفقرة 7.7

‫5.10. Professional Audio

إذا كانت عمليات تنفيذ الأجهزة تشير إلى إتاحة الميزة android.hardware.audio.pro من خلال فئة android.content.pm.PackageManager، يجب أن تستوفي الشروط التالية:

[C-1-1] يجب الإبلاغ عن إتاحة الميزة android.hardware.audio.low_latency.
[C-1-2] يجب استيفاء متطلبات وقت الاستجابة في FEATURE_AUDIO_PRO على النحو المحدّد في القسم 5.6 وقت استجابة الصوت .
[C-1-3] يجب أن يتضمّن منفذ USB أو منافذ USB متوافقة مع وضع مضيف USB ووضع جهاز USB الطرفي.
[C-1-4] يجب الإبلاغ عن إتاحة الميزة android.software.midi.
[C-1-5] يجب استيفاء متطلبات وقت استجابة الصوت عبر USB باستخدام واجهة برمجة التطبيقات AAudio native audio وAAUDIO_PERFORMANCE_MODE_LOW_LATENCY.
[C-1-6] يجب أن يكون وقت استجابة الإخراج البارد 200 ملي ثانية أو أقل.
[C-1-7] يجب أن يكون وقت استجابة الإدخال البارد 200 ملي ثانية أو أقل.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقبس صوت رباعي الموصلات مقاس 3.5 ملم، يجب أن:

[C-2-2] يجب الالتزام بالقسم مواصفات الأجهزة الجوّالة (المقبس) من مواصفات سماعات الرأس السلكية (الإصدار 1.1).

إذا كانت عمليات تنفيذ الأجهزة لا تتضمّن مقبس صوت 3.5 ملم بأربعة موصلات وتتضمّن منفذًا أو منافذ USB متوافقة مع وضع مضيف USB، يجب أن تستوفي ما يلي:

‫[C-3-1] يجب تنفيذ فئة الصوت عبر USB.

‫5.11. التقاط الصور التي لم تتم معالجتها

يتيح نظام التشغيل Android تسجيل الصوت غير المعالَج من خلال مصدر الصوت android.media.MediaRecorder.AudioSource.UNPROCESSED. في OpenSL ES، يمكن الوصول إلى هذا الإعداد المُسبَق باستخدام SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

إذا كانت عمليات تنفيذ الأجهزة تهدف إلى توفير مصدر صوت غير معالج وإتاحته للتطبيقات التابعة لجهات خارجية، عليها استيفاء ما يلي:

[C-1-1] يجب الإبلاغ عن التوافق من خلال السمة android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.
[C-1-2] يجب أن تعرض خصائص سعة مقابل التردد مسطّحة تقريبًا في نطاق التردد المتوسط: تحديدًا ±10 ديسيبل من 100 هرتز إلى 7000 هرتز لكل ميكروفون مستخدَم لتسجيل مصدر الصوت غير المعالج.
[C-1-3] يجب أن تعرض مستويات السعة في نطاق التردد المنخفض، وتحديدًا من ±20 ديسيبل من 5 هرتز إلى 100 هرتز مقارنةً بنطاق التردد المتوسط لكل ميكروفون مستخدَم لتسجيل مصدر الصوت غير المعالج.
[C-1-4] يجب أن تعرض مستويات السعة في نطاق التردد العالي: تحديدًا من ±30 ديسيبل من 7000 هرتز إلى 22 كيلوهرتز مقارنةً بنطاق التردد المتوسط لكل ميكروفون مستخدَم لتسجيل مصدر الصوت غير المعالج.
[C-1-5] يجب ضبط حساسية إدخال الصوت بحيث يؤدي مصدر نغمي جيبي بتردد 1000 هرتز يتم تشغيله بمستوى ضغط صوتي (SPL) يبلغ 94 ديسيبل إلى استجابة بقيمة متوسط الجذر التربيعي (RMS) تبلغ 520 لعينات 16 بت (أو -36 ديسيبل من المقياس الكامل لعينات النقطة العائمة/الدقة المزدوجة) لكل ميكروفون مستخدَم لتسجيل مصدر الصوت غير المعالج.
[C-1-6] يجب أن تبلغ نسبة الإشارة إلى الضوضاء (SNR) 60 ديسيبل أو أكثر لكل ميكروفون مستخدَم لتسجيل مصدر الصوت غير المعالج. (بينما يتم قياس نسبة الإشارة إلى الضوضاء على أنّها الفرق بين مستوى ضغط الصوت البالغ 94 ديسيبل ومستوى ضغط الصوت المكافئ للضوضاء الذاتية، مع ترجيح A).
[C-1-7] يجب أن يكون إجمالي التشوه التوافقي (THD) أقل من 1% عند 1 كيلو هرتز ومستوى ضغط صوتي يبلغ 90 ديسيبل عند كل ميكروفون مستخدَم لتسجيل مصدر الصوت غير المعالج.
[C-1-8] يجب ألا تتضمّن أي معالجة أخرى للإشارات (مثل التحكّم التلقائي في مستوى الصوت أو فلتر الترددات العالية أو إلغاء الصدى) في المسار باستثناء مضاعف المستوى لضبط المستوى على النطاق المطلوب. وبعبارة أخرى:
- [C-1-9] إذا كانت هناك أي معالجة للإشارة في البنية لأي سبب، يجب إيقافها وعدم إضافة أي تأخير أو زمن انتقال إضافي إلى مسار الإشارة.
- [C-1-10] يجب ألا يؤدي مضاعف المستوى، مع السماح بوجوده في المسار، إلى حدوث تأخير أو بطء في مسار الإشارة.

يتم إجراء جميع قياسات مستوى ضغط الصوت (SPL) بجانب الميكروفون الخاضع للاختبار مباشرةً. في حال توفّر إعدادات ميكروفون متعدّدة، تنطبق هذه المتطلبات على كل ميكروفون.

إذا كانت عمليات تنفيذ الأجهزة تعرّف android.hardware.microphone ولكنها لا تتيح مصدر الصوت غير المعالج، عليها اتّباع ما يلي:

[C-2-1] يجب أن تعرض null لطريقة AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) API، للإشارة بشكل صحيح إلى عدم التوافق.
[C-SR-1] لا تزال موصى بها بشدة لاستيفاء أكبر عدد ممكن من متطلبات مسار الإشارة لمصدر التسجيل غير المعالج.

‫5.12 فيديو بنطاق عالي الديناميكية

يتوافق نظام التشغيل Android 13 مع تقنيات HDR كما هو موضح في مستند قادم.

تنسيق البكسل

إذا كان برنامج فك ترميز الفيديو يعلن عن توافقه مع COLOR_FormatYUVP010، يعني ذلك ما يلي:

[C-1-1] يجب أن يتوافق مع تنسيق P010 للقراءة من وحدة المعالجة المركزية (ImageReader وMediaImage وByteBuffer). في نظام التشغيل Android 13، تم تخفيف القيود المفروضة على تنسيق P010 للسماح بخطوة عشوائية لمستويَي Y وUV.
[C-1-2] يجب أن يكون من الممكن أن تأخذ وحدة معالجة الرسومات عيّنات من مخزن الإخراج P010 (عند تخصيصه باستخدام GPU_SAMPLING). يتيح ذلك استخدام ميزة تركيب الصور على وحدة معالجة الرسومات وميزة ربط درجات الألوان المخصّصة من خلال التطبيقات.

إذا كان برنامج ترميز الفيديو يعلن عن إمكانية استخدام COLOR_Format32bitABGR2101010، يعني ذلك ما يلي:

[C-2-1] يجب أن يتوافق مع تنسيق RGBA_1010102 لسطح الإخراج القابل للقراءة من خلال وحدة المعالجة المركزية (إخراج ByteBuffer).

إذا كان برنامج ترميز الفيديو يعلن عن توافقه مع COLOR_FormatYUVP010، يعني ذلك أنّه:

[C-3-1] يجب أن يتوافق مع تنسيق P010 لسطح الإدخال والإدخال القابل للكتابة على وحدة المعالجة المركزية (ImageWriter وMediaImage وByteBuffer).

إذا كان برنامج ترميز الفيديو يعلن عن توافقه مع COLOR_Format32bitABGR2101010، يعني ذلك أنّه:

[C-4-1] يجب أن يتوافق مع تنسيق RGBA_1010102 لسطح الإدخال والإدخال القابل للكتابة على وحدة المعالجة المركزية (ImageWriter وByteBuffer). ملاحظة: ليس على برامج الترميز إجراء أي تحويل بين منحنيات النقل المختلفة.

متطلبات التقاط صور HDR

في ما يتعلق بجميع برامج ترميز الفيديو التي تتوافق مع ملفات HDR الشخصية، وعمليات تنفيذ الأجهزة:

[C-5-1] يجب عدم افتراض أنّ البيانات الوصفية بتنسيق HDR دقيقة. على سبيل المثال، قد يحتوي الإطار المرمّز على وحدات بكسل تتجاوز مستوى الإضاءة القصوى، أو قد لا يكون المدرّج التكراري ممثلاً للإطار.
يجب تجميع البيانات الوصفية الديناميكية بتنسيق HDR لإنشاء بيانات وصفية ثابتة بتنسيق HDR مناسبة لعمليات البث المرمّزة، ويجب إخراجها في نهاية كل جلسة ترميز.

في حال كانت عمليات تنفيذ الأجهزة تتيح تسجيل المحتوى بنطاق عالي الديناميكية باستخدام واجهات برمجة التطبيقات CamcorderProfile، يجب استيفاء ما يلي:

[C-6-1] يجب أن يتيح الجهاز تسجيل المحتوى بنطاق عالي الديناميكية من خلال واجهات برمجة التطبيقات Camera2 API أيضًا.
‫[C-6-2] يجب أن تتوافق الأجهزة مع برنامج ترميز فيديو واحد على الأقل يتم تسريعه بواسطة الأجهزة لكل تقنية HDR متوافقة.
‫[C-6-3] يجب أن تتوافق مع ميزة تسجيل HLG (كحد أدنى).
‫[C-6-4] يجب أن يتيح الجهاز كتابة البيانات الوصفية الخاصة بتنسيق HDR (إذا كانت تنطبق على تكنولوجيا HDR) في ملف الفيديو الذي تم التقاطه. بالنسبة إلى AV1 وHEVC وDolbyVision، يعني ذلك تضمين البيانات الوصفية في دفق البت المرمّز.
[C-6-5] يجب أن تتوافق مع P010 وCOLOR_FormatYUVP010.
‫[C-6-6] يجب أن تتوافق مع ميزة "تحويل النطاق العالي الديناميكية إلى نطاق عادي الديناميكية" في برنامج فك الترميز التلقائي المُسّرع للأجهزة للملف الشخصي الذي تم التقاطه. بعبارة أخرى، إذا كان الجهاز قادرًا على تسجيل محتوى HEVC بتنسيق HDR10+‎، يجب أن يكون برنامج فك ترميز HEVC التلقائي قادرًا على فك ترميز البث المسجّل بتنسيق SDR.

متطلبات تعديل فيديوهات HDR

إذا كانت عمليات تنفيذ الأجهزة تتضمّن برامج ترميز فيديو تتيح تعديل محتوى HDR، يجب أن:

يجب استخدام الحد الأدنى من وقت الاستجابة لإنشاء البيانات الوصفية الخاصة بنطاق HDR عندما لا تكون متوفرة، ويجب التعامل بسلاسة مع الحالات التي تكون فيها البيانات الوصفية متوفرة لبعض اللقطات وليس للبعض الآخر. يجب أن تكون هذه البيانات الوصفية دقيقة (على سبيل المثال، تمثّل ذروة الإضاءة الفعلية والمدرّج التكراري للإطار).

إذا كان تنفيذ الجهاز يتضمّن برامج ترميز متوافقة مع FEATURE_HdrEditing، يجب أن تستوفي برامج الترميز هذه ما يلي:

[C-7-1] يجب أن يتوافق مع ملف واحد على الأقل من ملفات HDR.
‫[C-7-2] يجب أن تتوافق برامج الترميز مع FEATURE_HdrEditing لجميع ملفات HDR الشخصية التي يتم الإعلان عنها من خلال برنامج الترميز هذا. بعبارة أخرى، يجب أن تتوافق مع إنشاء بيانات وصفية بتنسيق HDR في حال عدم توفّرها لجميع ملفات HDR الشخصية المتوافقة التي تستخدم بيانات وصفية بتنسيق HDR.
[C-7-3] يجب أن تتوافق مع تنسيقات إدخال برنامج ترميز الفيديو التالية التي تحافظ بشكل كامل على إشارة HDR التي تم فك ترميزها:
- RGBA_1010102 (الموجودة في منحنى النقل المستهدف) لكل من سطح الإدخال وByteBuffer ويجب الإعلان عن توفّر COLOR_Format32bitABGR2101010.

إذا كان تنفيذ الجهاز يتضمّن برامج ترميز متوافقة مع FEATURE_HdrEditing، يجب أن يستوفي الجهاز ما يلي:

[C-7-4] يجب الإعلان عن إمكانية استخدام إضافة EXT_YUV_target OpenGL.

متطلبات شاشة HDR

إذا تلقّت عمليات تنفيذ الأجهزة محتوى مخزّنًا مؤقتًا مشفّرًا باستخدام ADATASPACE_TRANSFER_HLG، وتم إرسال هذا المحتوى إلى شاشة العرض من خلال SurfaceControl.Transaction#setBuffer، ستنفّذ ما يلي:

[C-8-1] يجب اتّباع توصية اللون الأبيض في الرسومات الواردة في المعيار BT. 2408-7، وعرض المحتوى بما لا يزيد عن 4.926 مرة من محتوى النطاق الديناميكي العادي (SDR).

6. التوافق مع أدوات وخيارات المطوّرين

6.1. أدوات مطوّري البرامج

عمليات تنفيذ الجهاز:

[C-0-1] يجب أن تتوافق مع "أدوات مطوّري تطبيقات Android" المتوفّرة في حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
Android Debug Bridge‏ (adb)
[C-0-2] يجب أن تتوافق مع أداة تصحيح الأخطاء عبر منفذ USB (adb) كما هو موضّح في حزمة تطوير البرامج (SDK) لنظام التشغيل Android وأوامر shell المتوفّرة في مشروع Android مفتوح المصدر (AOSP)، والتي يمكن أن يستخدمها مطوّرو التطبيقات، بما في ذلك dumpsys وcmd stats وSimpleperf.
[C-0-11] يجب أن يتيح استخدام أمر shell cmd testharness. قد يتم إعفاء عمليات ترقية تنفيذ الأجهزة من إصدار Android أقدم بدون وحدة بيانات ثابتة من المتطلّب C-0-11.
[C-0-3] يجب عدم تغيير تنسيق أو محتوى أحداث نظام الجهاز (batterystats وdiskstats وfingerprint وgraphicsstats وnetstats وnotification وprocstats) التي يتم تسجيلها من خلال الأمر dumpsys.
[C-0-10] يجب تسجيل الأحداث التالية بدون حذف أي منها وإتاحتها لأمر shell cmd stats وفئة واجهة برمجة التطبيقات StatsManager System.
- ActivityForegroundStateChanged
- AnomalyDetected
- AppBreadcrumbReported
- AppCrashOccurred
- AppStartOccurred
- BatteryLevelChanged
- BatterySaverModeStateChanged
- BleScanResultReceived
- BleScanStateChanged
- ChargingStateChanged
- DeviceIdleModeStateChanged
- ForegroundServiceStateChanged
- GpsScanStateChanged
- InputDeviceUsageReported
- JobStateChanged
- KeyboardConfigured
- KeyboardSystemsEventReported
- PluggedStateChanged
- PressureStallInformation
- ScheduledJobStateChanged
- ScreenStateChanged
- SyncStateChanged
- SystemElapsedRealtime
- TouchpadUsage
- UidProcessStateChanged
- WakelockStateChanged
- WakeupAlarmOccurred
- WifiLockStateChanged
- WifiMulticastLockStateChanged
- WifiScanStateChanged
[C-0-4] يجب أن يكون برنامج adb الخفي على الجهاز غير نشط تلقائيًا، ويجب توفير آلية يمكن للمستخدم الوصول إليها لتفعيل Android Debug Bridge.
[C-0-5] يجب أن يتيح الجهاز تصحيح أخطاء adb الآمن. يتضمّن نظام التشغيل Android إمكانية استخدام adb الآمن. تتيح ميزة "adb الآمن" استخدام أداة adb على الأجهزة المضيفة المعروفة التي تمت مصادقتها.
[C-0-6] يجب توفير آلية تسمح بالاتصال بأداة adb من جهاز مضيف. وعلى وجه التحديد:

إذا كانت عمليات تنفيذ الأجهزة التي لا تتضمّن منفذ USB تتيح وضع الأجهزة الطرفية، يجب أن تستوفي ما يلي:

[C-3-1] يجب تنفيذ adb عبر شبكة المنطقة المحلية (مثل Ethernet أو Wi-Fi).
[C-3-2] يجب توفير برامج تشغيل لنظام التشغيل Windows 7 و8 و10، ما يتيح للمطوّرين الاتصال بالجهاز باستخدام بروتوكول adb.

إذا كانت عمليات تنفيذ الأجهزة تتيح اتصالات adb بجهاز مضيف عبر شبكة Wi-Fi أو إيثرنت، يجب أن تستوفي ما يلي:

[C-4-1] يجب أن تعرض الطريقة AdbManager#isAdbWifiSupported() القيمة true.

إذا كانت عمليات تنفيذ الأجهزة تتيح اتصالات adb بجهاز مضيف عبر شبكة Wi-Fi أو Ethernet، وتتضمّن كاميرا واحدة على الأقل، فإنّها:

[C-5-1] يجب أن تعرض الطريقة AdbManager#isAdbWifiQrSupported() القيمة true.
خدمة مراقبة تصحيح الأخطاء في Dalvik (ddms)
- [C-0-7] يجب أن تتوافق مع جميع ميزات ddms كما هو موضّح في حزمة تطوير البرامج (SDK) لنظام التشغيل Android. بما أنّ أداة ddms تستخدم أداة adb، يجب أن يكون خيار إتاحة أداة ddms غير مفعّل تلقائيًا، ولكن يجب إتاحتها عندما يفعّل المستخدم أداة Android Debug Bridge، كما هو موضّح أعلاه.
SysTrace
- [C-0-9] يجب أن تتوافق مع أداة systrace على النحو الموضّح في حزمة تطوير البرامج (SDK) لنظام التشغيل Android. يجب أن تكون أداة Systrace غير نشطة تلقائيًا، ويجب توفير آلية يمكن للمستخدم الوصول إليها لتفعيلها.
Perfetto
- [C-SR-1] يُنصح بشدة بعرض /system/bin/perfetto ملف ثنائي لمستخدم shell يتوافق سطر الأوامر الخاص به مع مستندات Perfetto.
- [C-SR-2] يُنصح بشدة بقبول ملف perfetto الثنائي كإدخال لإعدادات protobuf المتوافقة مع المخطط المحدّد في مستندات perfetto.
- [C-SR-3] يُنصح بشدة باستخدام ملف perfetto الثنائي لكتابة تتبُّع protobuf كناتج يتوافق مع المخطط المحدّد في مستندات perfetto.
- [C-SR-4] يُنصح بشدة بتوفير مصادر البيانات الموضّحة في مستندات perfetto من خلال ملف perfetto الثنائي على الأقل.
Low Memory Killer
- [C-0-12] يجب كتابة LMK_KILL_OCCURRED_FIELD_NUMBER Atom في سجل statsd عند إنهاء تطبيق بواسطة Low Memory Killer.
وضع مفعِّل الاختبار

إذا كانت عمليات تنفيذ الأجهزة تتيح أمر shell cmd testharness وتشغّل cmd testharness enable، يجب أن تستوفي ما يلي:
- [C-2-1] يجب إرجاع true مقابل ActivityManager.isRunningInUserTestHarness()
- [C-2-2] يجب تنفيذ "وضع مفعّل الاختبار" كما هو موضّح في مستندات "وضع مفعّل الاختبار".
معلومات عن عمل وحدة معالجة الرسومات

عمليات تنفيذ الجهاز:
- [C-0-13] يجب تنفيذ أمر shell dumpsys gpu --gpuwork لعرض بيانات عمل وحدة معالجة الرسومات المجمّعة التي تم إرجاعها من نقطة تتبُّع النواة power/gpu_work_period، أو عدم عرض أي بيانات إذا كانت نقطة التتبُّع غير متاحة. يكون تنفيذ AOSP frameworks/native/services/gpuservice/gpuwork/.

إذا كانت عمليات تنفيذ الأجهزة تُبلغ عن إمكانية استخدام الإصدار 1.0 من Vulkan أو إصدار أحدث من خلال علامات الميزات android.hardware.vulkan.version، فإنّها:

[C-1-1] يجب توفير وسيلة تتيح لمطوّر التطبيق تفعيل/إيقاف طبقات تصحيح أخطاء وحدة معالجة الرسومات (GPU).
[C-1-2] يجب، عند تفعيل طبقات تصحيح أخطاء وحدة معالجة الرسومات، تعداد الطبقات في المكتبات التي توفّرها الأدوات الخارجية (أي التي لا تشكّل جزءًا من النظام الأساسي أو حزمة التطبيق) والموجودة في الدليل الأساسي للتطبيقات القابلة للتصحيح من أجل إتاحة طريقتَي واجهة برمجة التطبيقات vkEnumerateInstanceLayerProperties() وvkCreateInstance().

إذا ضبطت عمليات تنفيذ الأجهزة سمتَي النظام graphics.gpu.profiler.support وgraphics.gpu.profiler.support.gpu_frequency على true، عليها إجراء ما يلي:

[C-6-1] يجب تسجيل نقطة تتبُّع "معدّل تكرار وحدة معالجة الرسومات" بالتنسيق power/gpu_frequency المحدّد، كما هو موضّح في power.proto.

إذا ضبطت عمليات تنفيذ الأجهزة سمتَي النظام graphics.gpu.profiler.support وgraphics.gpu.profiler.support.gpu_counters على true، فإنّها:

[C-7-1] يجب توفير أداة Perfetto لإنتاج البيانات لمصدر بيانات باسم gpu.counters، يمكن طلب البحث فيه باستخدام: perfetto --query.
[C-7-2] يجب الإبلاغ عن أوصاف عدّادات وحدة معالجة الرسومات بما يتوافق مع بروتوكول حزمة تتبُّع عدّادات وحدة معالجة الرسومات.
[C-7-3] يجب تسجيل قيم متوافقة لعدّادات وحدة معالجة الرسومات (GPU) بالجهاز وفقًا لبروتوكول حزمة تتبُّع عدّادات وحدة معالجة الرسومات.
[C-7-4] يجب تسجيل الأوصاف النصية لجميع عدّادات وحدة معالجة الرسومات المفعَّلة بدون طابع زمني في تتبُّع perfetto.
[C-7-6] يجب توفير مجموعة تلقائية غير فارغة من عدّادات أداء وحدة معالجة الرسومات لأغراض تحديد المشاكل، وذلك على النحو المحدّد في GpuCounterSpec#select_by_default.
- يجب أن يكون من الممكن تفعيل جميع العدادات التلقائية هذه في الوقت نفسه.
- ويجب أن تُرسِل جميعها قيمًا إلى Perfetto عند تفعيلها.
[C-7-7] يجب أن تعرض الأداة استخدام وحدة معالجة الرسومات لعداد واحد على الأقل تم اختياره تلقائيًا، وذلك باستخدام GpuCounterSpec#select_by_default.

إذا ضبطت عمليات تنفيذ الأجهزة سمتَي النظام graphics.gpu.profiler.support وgraphics.gpu.profiler.support.gpu_counters.period على true، عليها استيفاء ما يلي:

[C-8-1] يجب الالتزام counter_period_ns بمعدّل أخذ العيّنات لعدّادات وحدة معالجة الرسومات. يجب أن يكون معدّل أخذ العينات المتوافق 1 ملي ثانية أو أسرع.
[C-SR-5] يُنصح بشدة بأن تتوافق مع معدّل أخذ عيّنات يبلغ 0.2 مللي ثانية أو أقل.

إذا ضبطت عمليات تنفيذ الأجهزة سمتَي النظام graphics.gpu.profiler.support وgraphics.gpu.profiler.support.gpu_counters.groups على true، عليها استيفاء ما يلي:

[C-9-1] يجب أن يتضمّن كل من مجموعات عدّادات وحدة معالجة الرسومات التالية عدّادًا واحدًا على الأقل، كما هو محدّد في GpuCounterSpec: COMPUTE وFRAGMENTS وMEMORY وPRIMITIVES وVERTICES.

إذا ضبطت عمليات تنفيذ الأجهزة كلاً من سمتَي النظام graphics.gpu.profiler.support وgraphics.gpu.profiler.support.gpu_counters.groups على true، وكان الجهاز متوافقًا مع تتبُّع الأشعة، يجب أن تستوفي ما يلي:

[C-10-1] يجب أن يتضمّن العداد المجموعة RAY_TRACING.

إذا ضبطت عمليات تنفيذ الأجهزة سمتَي النظام graphics.gpu.profiler.support وgraphics.gpu.profiler.support.gpu_counters.zeroes_optimization على true، عليها استيفاء ما يلي:

[C-11-1] ضِمن جلسة تتبُّع Perfetto نفسها، يجب ألا تعرض عدّادات وحدة معالجة الرسومات قيمًا صفرية إلا إذا كانت القيمة المُبلغ عنها السابقة أو اللاحقة غير صفرية.

إذا ضبطت عمليات تنفيذ الأجهزة سمتَي النظام graphics.gpu.profiler.support وgraphics.gpu.profiler.support.render_stages على true، عليها استيفاء ما يلي:

[C-12-1] يجب توفير أداة إنشاء بيانات Perfetto لمصدر بيانات باسم gpu.renderstages، يمكن طلب البحث فيه باستخدام perfetto --query.
[C-12-2] يجب إعداد تقارير تتضمّن قيمًا متوافقة لمراحل العرض على وحدة معالجة الرسومات باتّباع نموذج أوّلي لحدث مرحلة العرض على وحدة معالجة الرسومات.

إذا ضبطت عمليات تنفيذ الأجهزة سمتَي النظام graphics.gpu.profiler.support وgraphics.gpu.profiler.support.render_stages.queue_submit على true، عليها استيفاء ما يلي:

[C-13-1] يجب أن يرسل برنامج تشغيل Vulkan حدث تتبُّع Perfetto لكل طلب إرسال إلى قائمة انتظار Vulkan، وذلك وفقًا لمواصفات رسالة حدث Vulkan API.
- يجب أن يحتوي هذا الحدث على submission_id فريد ومتزايد بشكل رتيب يتطابق مع submission_id في حدث مرحلة العرض على وحدة معالجة الرسومات المقابل.

‫6.2. خيارات المطوّرين

يتضمّن نظام التشغيل Android إمكانية ضبط الإعدادات المتعلّقة بتطوير التطبيقات.

يجب أن توفّر عمليات تنفيذ الأجهزة تجربة متّسقة لخيارات المطوّرين، ويجب أن:

[C-0-1] يجب أن يستجيب android.settings.APPLICATION_DEVELOPMENT_SETTINGS لغرض عرض الإعدادات ذات الصلة بتطوير التطبيقات. يخفي تطبيق Android الأساسي قائمة "خيارات المطوّرين" تلقائيًا، ويتيح للمستخدمين تشغيلها بعد النقر سبع (7) مرات على عنصر القائمة الإعدادات > معلومات عن الجهاز > رقم الإصدار.
[C-0-2] يجب إخفاء "خيارات المطوّرين" تلقائيًا.
[C-0-3] يجب توفير آلية واضحة لا تمنح معاملة تفضيلية لتطبيق تابع لجهة خارجية على حساب تطبيق آخر من أجل تفعيل "خيارات المطوّرين". يجب تقديم مستند أو موقع إلكتروني متاح للجميع يوضّح كيفية تفعيل "خيارات المطوّرين". يجب أن يكون هذا المستند أو الموقع الإلكتروني قابلاً للربط من مستندات حزمة تطوير البرامج (SDK) لنظام Android.
يجب أن يتضمّن إشعارًا مرئيًا مستمرًا للمستخدم عند تفعيل "خيارات المطوّرين" وعندما تكون سلامة المستخدم موضع قلق.
يجوز لـ MAY أن يقيّد مؤقتًا إمكانية الوصول إلى قائمة "خيارات المطوّرين" من خلال إخفاء القائمة أو إيقافها بصريًا، وذلك لتجنُّب تشتيت الانتباه في الحالات التي تكون فيها سلامة المستخدم موضع قلق.

7. توافُق الأجهزة

إذا كان الجهاز يتضمّن مكوّن أجهزة معيّنًا يتضمّن واجهة برمجة تطبيقات (API) خاصة بالمطوّرين الخارجيين:

[C-0-1] يجب أن يتضمّن تنفيذ الجهاز واجهة برمجة التطبيقات هذه على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

إذا كانت إحدى واجهات برمجة التطبيقات في حزمة SDK تتفاعل مع أحد مكونات الأجهزة التي يُذكر أنّها اختيارية، ولم يكن الجهاز يتضمّن هذا المكوّن:

[C-0-2] يجب أن تظل تعريفات الفئات الكاملة (كما هو موثّق في حزمة SDK) لواجهات برمجة التطبيقات الخاصة بالمكوّنات معروضة.
[C-0-3] يجب تنفيذ سلوكيات واجهة برمجة التطبيقات على أنّها عمليات غير فعّالة بطريقة معقولة.
‫[C-0-4] يجب أن تعرض طرق واجهة برمجة التطبيقات قيمًا فارغة حيثما تسمح بذلك مستندات حزمة تطوير البرامج (SDK).
[C-0-5] يجب أن تعرض طرق واجهة برمجة التطبيقات عمليات لا تفعل شيئًا للفئات التي لا تسمح مستندات حزمة تطوير البرامج (SDK) بقيم فارغة لها.
[C-0-6] يجب ألا تعرض طرق واجهة برمجة التطبيقات استثناءات غير موثّقة في مستندات حزمة تطوير البرامج (SDK).
[C-0-7] يجب أن تعرض عمليات تنفيذ الأجهزة معلومات دقيقة عن إعدادات الأجهزة بشكل متّسق من خلال طريقتَي getSystemAvailableFeatures() وhasSystemFeature(String) في فئة android.content.pm.PackageManager لملف مرجعي للإصدار نفسه.

من الأمثلة النموذجية على الحالات التي تنطبق فيها هذه المتطلبات واجهة برمجة التطبيقات الخاصة بالهاتف: حتى على الأجهزة غير الهاتفية، يجب تنفيذ واجهات برمجة التطبيقات هذه كعمليات غير فعّالة معقولة.

‫7.1. العرض والرسومات

يتضمّن نظام التشغيل Android تسهيلات تضبط تلقائيًا أصول التطبيقات وتصميمات واجهة المستخدم بما يتناسب مع الجهاز لضمان تشغيل التطبيقات التابعة لجهات خارجية بشكل جيد على مجموعة متنوعة من شاشات الأجهزة وإعداداتها. شاشة متوافقة مع Android هي شاشة عرض تنفّذ جميع السلوكيات وواجهات برمجة التطبيقات الموضّحة في نظرة عامة على توافق الشاشة في "مطوّرو تطبيقات Android"، وفي هذا القسم (7.1) والأقسام الفرعية منه، بالإضافة إلى أي سلوكيات إضافية خاصة بنوع الجهاز وموثّقة في القسم 2 من هذا المستند.

عمليات تنفيذ الجهاز:

[C-0-1] يجب، بشكلٍ تلقائي، عرض تطبيقات الجهات الخارجية على شاشات متوافقة مع Android فقط.

يتم تحديد الوحدات المشار إليها في المتطلبات الواردة في هذا القسم على النحو التالي:

الحجم الفعلي للقطر المسافة بالبوصة بين زاويتين متقابلتين من الجزء المضاء من الشاشة
الكثافة عدد وحدات البكسل التي يشملها مدى أفقي أو عمودي خطي يبلغ بوصة واحدة، ويتم التعبير عنه بوحدات البكسل لكل بوصة (ppi أو dpi). عند إدراج قيم النقاط لكل بوصة (ppi) والنقاط في البوصة (dpi)، يجب أن تندرج النقاط في البوصة الأفقية والعمودية ضمن النطاق المُدرَج.
نسبة العرض إلى الارتفاع نسبة وحدات البكسل في البُعد الأطول إلى البُعد الأقصر للشاشة على سبيل المثال، إذا كانت الشاشة تعرض 480 × 854 بكسل، ستكون نسبة العرض إلى الارتفاع 854 / 480 = 1.779، أو حوالي "16:9".
بكسل مستقل الكثافة (dp) وحدة بكسل افتراضية تمّت تسويتها لتناسب كثافة شاشة تبلغ 160. بالنسبة إلى كثافة d وعدد وحدات البكسل p، يتم احتساب عدد وحدات البكسل المستقلة الكثافة dp على النحو التالي: dp = (160 / d) * p.

‫7.1.1. إعدادات الشاشة

7.1.1.1. حجم الشاشة وشكلها

يتيح إطار عمل واجهة مستخدم Android مجموعة متنوعة من أحجام تنسيقات الشاشة المنطقية المختلفة، كما يتيح للتطبيقات الاستعلام عن حجم تنسيق الشاشة للإعداد الحالي من خلال Configuration.screenLayout باستخدام SCREENLAYOUT_SIZE_MASK وConfiguration.smallestScreenWidthDp.

عمليات تنفيذ الجهاز:

[C-0-1] يجب عرض حجم التنسيق الصحيح Configuration.screenLayout على النحو المحدّد في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android. على وجه التحديد، يجب أن تعرض عمليات تنفيذ الأجهزة أبعاد الشاشة الصحيحة بوحدات البكسل المستقلة عن الكثافة (dp) على النحو التالي:
- يجب أن يكون حجم الشاشة في الأجهزة التي تم ضبط Configuration.uiMode على أي قيمة أخرى غير UI_MODE_TYPE_WATCH، والتي تعرض حجم small لـ Configuration.screenLayout، ‏426 بكسل مستقل الكثافة × 320 بكسل مستقل الكثافة على الأقل.
- يجب أن يكون حجم normal الذي تعرضه الأجهزة لـ Configuration.screenLayout هو 480 dp x 320 dp على الأقل.
- يجب أن تبلغ أبعاد Configuration.screenLayout على الأقل 640 بكسل مستقل الكثافة × 480 بكسل مستقل الكثافة في الأجهزة التي تعرض حجم large.
- يجب أن يكون حجم Configuration.screenLayout الذي تعرضه الأجهزة xlarge بمقدار 960 وحدة بكسل مستقلة عن الكثافة × 720 وحدة بكسل مستقلة عن الكثافة على الأقل.
[C-0-2] يجب أن يلتزم الجهاز بشكل صحيح ببيان التطبيقات عن توافقها مع أحجام الشاشات من خلال السمة <supports-screens> في AndroidManifest.xml، كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) لنظام Android.
قد تتضمّن شاشات متوافقة مع Android بزوايا دائرية.

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع الشاشات التي يمكنها استخدام إعدادات الحجم UI_MODE_TYPE_NORMAL واستخدام شاشات عرض فعلية ذات زوايا مستديرة لعرض هذه الشاشات، يجب أن تستوفي ما يلي:

[C-1-1] يجب التأكّد من استيفاء شرط واحد على الأقل من الشروط التالية لكل شاشة عرض:
- يجب أن يكون نصف قطر الزوايا الدائرية أقل من أو يساوي 38 وحدة بكسل مستقلة عن الكثافة.
- عندما يتم تثبيت مربّع بحجم 18 وحدة بكسل مستقل الكثافة × 18 وحدة بكسل مستقل الكثافة في كل ركن من أركان الشاشة المنطقية، يظهر بكسل واحد على الأقل من كل مربّع على الشاشة.
يجب أن تتضمّن إمكانية وصول المستخدم إلى وضع العرض بزوايا مستطيلة.

إذا كانت عمليات تنفيذ الأجهزة لا تتوافق إلا مع إعداد لوحة المفاتيح NO_KEYS، وكانت تهدف إلى الإبلاغ عن التوافق مع إعداد وضع واجهة المستخدم UI_MODE_TYPE_NORMAL، عليها الالتزام بما يلي:

[C-4-1] يجب أن يكون حجم التصميم، باستثناء أي فتحات عرض، 596 وحدة بكسل مستقلة عن الكثافة × 384 وحدة بكسل مستقلة عن الكثافة أو أكثر.

للحصول على تفاصيل حول التنفيذ الصحيح لواجهات برمجة التطبيقات الخاصة بالإضافات أو التطبيقات المصغّرة، يُرجى الرجوع إلى المستندات المتاحة للجميع في Window Manager Jetpack.

[C-4-1] تمت إزالة هذا الشرط في Android 15.

‫7.1.1.2. نسبة العرض إلى الارتفاع على الشاشة

تمت إزالة هذا القسم في Android 14.

‫7.1.1.3. كثافة الشاشة

يحدّد إطار عمل واجهة المستخدم في Android مجموعة من الكثافات المنطقية العادية لمساعدة مطوّري التطبيقات في استهداف موارد التطبيقات.

عمليات تنفيذ الأجهزة:

[C-0-1] يجب الإبلاغ عن إحدى كثافات إطار عمل Android المُدرَجة في DisplayMetrics من خلال واجهة برمجة التطبيقات DENSITY_DEVICE_STABLE ويجب أن تكون هذه القيمة ثابتة لكل شاشة عرض فعلية. ومع ذلك، قد يعرض الجهاز قيمة مختلفة DisplayMetrics.density وفقًا لتغييرات إعدادات العرض التي يجريها المستخدم (مثل حجم العرض) بعد عملية التشغيل الأولية.
يجب أن تحدّد كثافة إطار عمل Android العادي الأقرب عدديًا إلى الكثافة الفعلية للشاشة، أو قيمة يمكن ربطها بقياسات مجال الرؤية الزاوي المكافئ نفسها لجهاز محمول.

إذا كانت عمليات تنفيذ الأجهزة توفّر إمكانية تغيير حجم العرض على الجهاز، يجب أن تستوفي ما يلي:

[C-1-1] يجب ألا يتم توسيع العرض بمقدار أكبر من 1.5 مرة DENSITY_DEVICE_STABLE أو إنتاج حد أدنى فعّال لأبعاد الشاشة أصغر من 320 وحدة بكسل مستقلة عن الكثافة (أي ما يعادل مؤهّل الموارد sw320dp)، أيهما يحدث أولاً.
[C-1-2] يجب ألا يتم تصغير حجم العرض إلى أقل من 0.85 مرة من DENSITY_DEVICE_STABLE.
لضمان سهولة الاستخدام وتناسق أحجام الخطوط، يُنصح بتوفير خيارات القياس التالية في "الإعلانات على الشبكة الأصلية" (مع الالتزام بالحدود المحدّدة أعلاه):
- صغير: 0.85x
- القيمة التلقائية: 1x (مقياس العرض الأصلي)
- كبير: 1.15x
- أكبر: 1.3x
- الأكبر 1.45x

‫7.1.2. مقاييس الإعلانات الصورية

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشات متوافقة مع Android أو مخرجات فيديو إلى شاشات متوافقة مع Android، يجب أن تستوفي ما يلي:

[C-1-1] يجب عرض قيم صحيحة لجميع مقاييس العرض المتوافقة مع Android والمحدّدة في واجهة برمجة التطبيقات android.util.DisplayMetrics.

إذا لم تتضمّن عمليات تنفيذ الأجهزة شاشة مدمجة أو إخراج فيديو، يجب أن تستوفي ما يلي:

[C-2-1] يجب أن تعرض قيمًا صحيحة للشاشة المتوافقة مع Android على النحو المحدّد في واجهة برمجة التطبيقات android.util.DisplayMetrics لـ view.Display التلقائي المحاكى.

‫7.1.3. اتجاه الشاشة

عمليات تنفيذ الجهاز:

[C-0-1] يجب أن توضّح الأجهزة اتجاهات الشاشة المتوافقة معها (android.hardware.screen.portrait و/أو android.hardware.screen.landscape)، ويجب أن توضّح اتجاهًا واحدًا على الأقل. على سبيل المثال، يجب أن يعرض الجهاز الذي يحتوي على شاشة ثابتة الاتجاه في الوضع الأفقي، مثل التلفزيون أو الكمبيوتر المحمول، القيمة android.hardware.screen.landscape فقط.
[C-0-2] يجب عرض القيمة الصحيحة لاتجاه الجهاز الحالي عند طلبها من خلال واجهات برمجة التطبيقات android.content.res.Configuration.orientation أو android.view.Display.getOrientation() أو غيرها.

إذا كانت عمليات تنفيذ الأجهزة تتيح كلا اتجاهَي الشاشة، يجب أن:

[C-1-1] تمت إزالة هذا الشرط في الإصدار Android 16.
[C-1-2] يجب عدم تغيير حجم الشاشة أو كثافتها عند تغيير اتجاهها.
يمكن اختيار الاتجاه العمودي أو الأفقي كإعداد تلقائي.

‫7.1.4. تسريع الرسومات الثنائية والثلاثية الأبعاد

7.1.4.1. OpenGL ES

عمليات تنفيذ الجهاز:

[C-0-1] يجب أن تحدّد بشكل صحيح إصدارات OpenGL ES المتوافقة (1.1 و2.0 و3.0 و3.1 و3.2) من خلال واجهات برمجة التطبيقات المُدارة (مثل طريقة GLES10.getString()) وواجهات برمجة التطبيقات الأصلية.
[C-0-2] يجب أن تتضمّن دعمًا لجميع واجهات برمجة التطبيقات المُدارة وواجهات برمجة التطبيقات الأصلية المتوافقة مع كل إصدار من إصدارات OpenGL ES التي تم تحديدها على أنّها متوافقة.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة أو إخراج فيديو، يجب أن تستوفي ما يلي:

[C-1-1] يجب أن تتوافق مع OpenGL ES 1.1 و2.0 و3.0 و3.1، كما هو موضح بالتفصيل في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
[C-SR-1] تمت إزالة هذا الشرط في Android 15.
يجب أن يتوافق مع OpenGL ES 3.2.

يتم تقسيم اختبارات dEQP الخاصة بـ OpenGL ES إلى عدد من قوائم الاختبارات، ولكل منها تاريخ أو رقم إصدار مرتبط. ويمكن العثور عليها في شجرة المصدر لنظام Android على الرابط external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt. يشير الجهاز المتوافق مع OpenGL ES على مستوى تم الإبلاغ عنه ذاتيًا إلى أنّه يمكنه اجتياز اختبارات dEQP في جميع قوائم الاختبارات من هذا المستوى والمستويات السابقة.

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع أي من إصدارات OpenGL ES، يجب أن تستوفي ما يلي:

[C-2-1] يجب الإبلاغ من خلال واجهات برمجة التطبيقات المُدارة وواجهات برمجة التطبيقات الأصلية في OpenGL ES عن أي إضافات أخرى تم تنفيذها في OpenGL ES، ويجب عدم الإبلاغ عن سلاسل الإضافات التي لا تتوافق معها.
[C-2-2] يجب أن تتوافق مع الإضافات EGL_KHR_image وEGL_KHR_image_base وEGL_ANDROID_image_native_buffer وEGL_ANDROID_get_native_client_buffer وEGL_KHR_wait_sync وEGL_KHR_get_all_proc_addresses وEGL_ANDROID_presentation_time وEGL_KHR_swap_buffers_with_damage وEGL_ANDROID_recordable وEGL_ANDROID_GLES_layers.
[C-2-3] يجب الإبلاغ عن الحد الأقصى لإصدار اختبارات dEQP في OpenGL ES المتوافقة من خلال علامة الميزة android.software.opengles.deqp.level.
[C-2-4] يجب أن يتوافق على الأقل مع الإصدار 132383489 (من 1 آذار (مارس) 2020) كما هو موضّح في علامة الميزة android.software.opengles.deqp.level.
[C-2-5] يجب اجتياز جميع اختبارات dEQP الخاصة بـ OpenGL ES في قوائم الاختبارات بين الإصدار 132383489 والإصدار المحدّد في علامة الميزة android.software.opengles.deqp.level، وذلك لكل إصدار متوافق من OpenGL ES.
[C-SR-2] يُنصح بشدة بتوفير دعم للإضافتين EGL_KHR_partial_update وOES_EGL_image_external.
يجب أن يتم الإبلاغ بدقة عن أي تنسيق لضغط النسيج متوافق مع طريقة getString()، وهو عادةً ما يكون خاصًا بالمورّد.
يجب أن تتوافق مع الإضافتين EGL_IMG_context_priority وEGL_EXT_protected_content.

إذا كانت عمليات تنفيذ الأجهزة تعلن عن التوافق مع OpenGL ES 3.0 أو 3.1 أو 3.2، يجب أن تستوفي ما يلي:

[C-3-1] يجب تصدير رموز الدالات المتوافقة مع هذه الإصدارات بالإضافة إلى رموز دالات OpenGL ES 2.0 في مكتبة libGLESv2.so.
[C-SR-3] يُنصح بشدة بتوفير دعم للإضافة OES_EGL_image_external_essl3.

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع OpenGL ES 3.2، يجب أن:

[C-4-1] يجب أن يتوافق الجهاز مع حزمة OpenGL ES Android Extension Pack بالكامل.

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع حزمة إضافات Android في OpenGL ES بالكامل، يجب أن تستوفي ما يلي:

[C-5-1] يجب تحديد إمكانية التوافق من خلال علامة الميزة android.hardware.opengles.aep.

إذا كانت عمليات تنفيذ الأجهزة توفّر إمكانية استخدام الإضافة EGL_KHR_mutable_render_buffer، يجب أن تستوفي ما يلي:

[C-6-1] يجب أيضًا أن تتوافق مع الإضافة EGL_ANDROID_front_buffer_auto_refresh.

‫7.1.4.2. Vulkan

يتوافق نظام التشغيل Android مع Vulkan، وهي واجهة برمجة تطبيقات متوافقة مع عدة أنظمة أساسية وتتطلّب موارد قليلة، وهي مخصّصة للرسومات الثلاثية الأبعاد العالية الأداء.

في حال توفُّر OpenGL ES 3.1 في عمليات تنفيذ الأجهزة، يجب أن:

[C-SR-1] يُنصح بشدة بتضمين دعم Vulkan 1.3.
[C-4-1] يجب ألا يتوافق مع إصدار مختلف من Vulkan (أي يجب أن يكون الجزء المختلف من إصدار Vulkan الأساسي صفرًا).

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة أو إخراج فيديو، يجب أن تستوفي ما يلي:

[C-SR-2] يُنصح بشدة بتضمين دعم Vulkan 1.3.

يتم تقسيم اختبارات dEQP في Vulkan إلى عدد من قوائم الاختبارات، ولكل منها تاريخ/إصدار مرتبط. ويمكن العثور عليها في شجرة المصدر لنظام Android على الرابط external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt. يشير الجهاز المتوافق مع Vulkan على مستوى تم الإبلاغ عنه ذاتيًا إلى أنّه يمكنه اجتياز اختبارات dEQP في جميع قوائم الاختبارات من هذا المستوى والمستويات السابقة.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية استخدام Vulkan، يجب أن:

[C-1-1] يجب عرض قيمة العدد الصحيح الصحيحة باستخدام علامتَي الميزة android.hardware.vulkan.level وandroid.hardware.vulkan.version.
[C-1-2] يجب تعداد VkPhysicalDevice واحدة على الأقل لواجهة برمجة التطبيقات الأصلية Vulkan vkEnumeratePhysicalDevices().
[C-1-3] يجب تنفيذ واجهات برمجة التطبيقات Vulkan 1.1 بالكامل لكل VkPhysicalDevice تم تعدادها.
[C-1-4] يجب تعداد الطبقات المضمّنة في المكتبات المجمّعة من رموز برمجية أصلية التي تحمل الاسم libVkLayer*.so في دليل المكتبات المجمّعة من رموز برمجية أصلية الخاص بحزمة التطبيق، وذلك من خلال واجهات برمجة التطبيقات الأصلية vkEnumerateInstanceLayerProperties() وvkEnumerateDeviceLayerProperties().

[C-1-5] يجب عدم تعداد الطبقات التي توفّرها المكتبات خارج حزمة التطبيق، أو توفير طرق أخرى لتتبُّع واجهة برمجة التطبيقات Vulkan أو اعتراضها، ما لم يتم ضبط السمة android:debuggable في التطبيق على true أو ضبط البيانات الوصفية com.android.graphics.injectLayers.enable على true ، باستثناء طبقات OEM والمنصة وفقًا لمستندات تنفيذ Vulkan.

[C-1-6] يجب الإبلاغ عن جميع سلاسل الإضافات المتوافقة من خلال واجهات برمجة التطبيقات الأصلية في Vulkan، ويجب عدم الإبلاغ عن سلاسل الإضافات غير المتوافقة.

[C-1-7] يجب أن تتوافق مع الإضافات التالية:
- VK_EXT_present_mode_fifo_latest_ready
- VK_KHR_present_wait2
- VK_KHR_android_surface
- VK_KHR_incremental_present
- VK_KHR_present_id
- VK_KHR_present_id2
- VK_KHR_surface
- VK_KHR_swapchain

[C-1-8] يجب الإبلاغ عن الحد الأقصى لإصدار "اختبارات dEQP" في Vulkan المتوافق من خلال علامة الميزة android.software.vulkan.deqp.level.
[C-1-9] يجب أن تتوافق على الأقل مع الإصدار 132317953 (اعتبارًا من 1 آذار (مارس) 2019) كما هو موضّح في علامة الميزة android.software.vulkan.deqp.level.
[C-1-10] يجب اجتياز جميع اختبارات dEQP في Vulkan في قوائم الاختبارات بين الإصدار 132317953 والإصدار المحدّد في علامة الميزة android.software.vulkan.deqp.level.
[C-1-11] يجب عدم إدراج إضافات VK_KHR_video_queue أو VK_KHR_video_decode_queue أو VK_KHR_video_encode_queue ضمن الميزات المتوافقة.

[C-SR-3] يُنصح بشدة بتوفير الإضافات التالية:
- VK_EXT_present_timing
- VK_GOOGLE_display_timing
- VK_KHR_driver_properties

[C-1-12] يجب عدم إدراج دعم الإضافة VK_KHR_performance_query.
[C-SR-4] يُنصَح بشدة بتلبية المتطلبات المحدّدة في الملف الشخصي لمعيار Android الأساسي لعام 2022.
[C-SR-5] يُنصح بشدة بتوفير الدعم VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory وVK_EXT_global_priority.
[C-SR-6] يُنصح بشدة باستخدام SkiaVk مع HWUI.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية استخدام Vulkan، يجب أن:

[C-SR-8] يُنصح بشدة بعدم تعديل برنامج Vulkan loader.
[C-1-14] يجب عدم تعداد إضافات جهاز Vulkan من النوع "KHR" أو "GOOGLE" أو "ANDROID" ما لم يتم تضمين هذه الإضافات في علامة الميزة android.software.vulkan.deqp.level.

إذا لم تتضمّن عمليات تنفيذ الأجهزة إمكانية استخدام Vulkan 1.0، يجب أن:

[C-2-1] يجب عدم الإفصاح عن أي من مفاتيح إيقاف أو تفعيل ميزات Vulkan (مثل android.hardware.vulkan.level وandroid.hardware.vulkan.version).
[C-2-2] يجب عدم تعداد أي VkPhysicalDevice لواجهة برمجة التطبيقات Vulkan الأصلية vkEnumeratePhysicalDevices().

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية استخدام Vulkan 1.1 وتعلن عن أي من علامات ميزات Vulkan الموضّحة هنا أو إصدار أحدث، يجب أن تستوفي ما يلي:

[C-3-1] يجب أن يتيح دعم أنواع SYNC_FD وVK_ANDROID_external_memory_android_hardware_buffer وامتدادهما.
[C-SR-7] يُنصح بشدة بإتاحة الإضافة VK_KHR_external_fence_fd للتطبيقات التابعة لجهات خارجية والسماح للتطبيق بتصدير حمولة السياج الجغرافي واستيرادها من واصفات ملفات POSIX كما هو موضح هنا.

‫7.1.4.3. RenderScript

عمليات تنفيذ الجهاز:

[C-0-1] يجب أن تتوافق مع Android RenderScript، كما هو موضّح بالتفصيل في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

‫7.1.4.4. تسريع الرسومات الثنائية الأبعاد

يتضمّن نظام التشغيل Android آلية تتيح للتطبيقات الإعلان عن أنّها تريد تفعيل تسريع الأجهزة للرسومات الثنائية الأبعاد على مستوى التطبيق أو النشاط أو النافذة أو العرض، وذلك من خلال استخدام علامة بيان android:hardwareAccelerated أو طلبات مباشرة من واجهة برمجة التطبيقات.

عمليات تنفيذ الجهاز:

[C-0-1] يجب تفعيل ميزة "تسريع الأجهزة" تلقائيًا، ويجب إيقافها إذا طلب المطوّر ذلك من خلال ضبط android:hardwareAccelerated="false" أو إيقافها مباشرةً من خلال واجهات برمجة التطبيقات الخاصة بـ Android View.
‫[C-0-2] يجب أن يكون السلوك متوافقًا مع مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android بشأن تسريع الأجهزة.

يتضمّن نظام التشغيل Android عنصر TextureView يتيح للمطوّرين دمج مواد عرض OpenGL ES التي يتم تسريعها على مستوى الأجهزة مباشرةً كأهداف للعرض في بنية واجهة المستخدم.

عمليات تنفيذ الجهاز:

[C-0-3] يجب أن تتوافق مع واجهة برمجة التطبيقات TextureView، ويجب أن يكون سلوكها متوافقًا مع التنفيذ المتوافق مع إصدار Android.

‫7.1.4.5. شاشات العرض ذات التدرّج اللوني الواسع

إذا كانت عمليات تنفيذ الأجهزة تدّعي إتاحة شاشات ذات نطاق ألوان واسع من خلال Configuration.isScreenWideColorGamut()، يجب أن تستوفي ما يلي:

[C-1-1] يجب أن تتضمّن شاشة تمت معايرتها من حيث الألوان.
‫[C-1-2] يجب أن تتضمّن شاشة تغطي مجموعة الألوان sRGB بالكامل في مساحة CIE 1931 xyY.
‫[C-1-3] يجب أن يتضمّن الجهاز شاشة يكون نطاق ألوانها بمساحة% 90 على الأقل من DCI-P3 في مساحة CIE 1931 xyY.
[C-1-4] يجب أن يتوافق الجهاز مع OpenGL ES 3.1 أو 3.2 وأن يعرضه بشكل صحيح.
[C-1-5] يجب الإعلان عن إمكانية استخدام الإضافات EGL_KHR_no_config_context وEGL_EXT_pixel_format_float وEGL_KHR_gl_colorspace وEGL_EXT_gl_colorspace_scrgb وEGL_EXT_gl_colorspace_scrgb_linear وEGL_EXT_gl_colorspace_display_p3 وEGL_EXT_gl_colorspace_display_p3_linear وEGL_EXT_gl_colorspace_display_p3_passthrough.
[C-SR-1] يُنصح بشدة بتوفير GL_EXT_sRGB.

في المقابل، إذا كانت عمليات تنفيذ الأجهزة لا تتوافق مع شاشات الألوان ذات النطاق الواسع، فإنّها:

[C-2-1] يجب أن تغطي 100% أو أكثر من مساحة ألوان sRGB في مساحة ألوان CIE 1931 xyY، على الرغم من أنّ نطاق ألوان الشاشة غير محدّد.

‫7.1.5. وضع التوافق مع التطبيقات القديمة

يحدّد نظام التشغيل Android "وضع التوافق" الذي يعمل فيه إطار العمل في وضع مكافئ لحجم الشاشة "العادي" (عرض 320 وحدة بكسل مستقلة الكثافة) لصالح التطبيقات القديمة التي لم يتم تطويرها لإصدارات Android القديمة التي تسبق ميزة استقلالية حجم الشاشة.

‫7.1.6. تقنية الشاشة

يتضمّن نظام Android الأساسي واجهات برمجة تطبيقات تتيح للتطبيقات عرض رسومات غنية على شاشة متوافقة مع Android. يجب أن تتوافق الأجهزة مع جميع واجهات برمجة التطبيقات هذه على النحو المحدّد في حزمة تطوير البرامج (SDK) لنظام التشغيل Android، ما لم يُسمح بذلك تحديدًا في هذا المستند.

جميع شاشات الأجهزة المتوافقة مع Android:

‫[C-0-1] يجب أن يكون الجهاز قادرًا على عرض رسومات ملوّنة بدقة 16 بت.
يجب أن تتوافق مع الشاشات التي يمكنها عرض رسومات ملوّنة بدقة 24 بت.
[C-0-2] يجب أن يكون الجهاز قادرًا على عرض الصور المتحركة.
[C-0-3] يجب أن تتراوح نسبة العرض إلى الارتفاع بالبكسل (PAR) بين 0.9 و1.15. أي أنّ نسبة عرض البكسل إلى ارتفاعه يجب أن تكون مربّعة تقريبًا (1.0) مع هامش خطأ يتراوح بين %10 و%15.

‫7.1.7. الشاشات الثانوية

يتيح نظام التشغيل Android استخدام شاشات ثانوية متوافقة مع Android لتفعيل إمكانات مشاركة الوسائط وواجهات برمجة التطبيقات للمطوّرين من أجل الوصول إلى الشاشات الخارجية.

إذا كانت عمليات تنفيذ الأجهزة تتيح شاشة خارجية إما عبر اتصال سلكي أو لاسلكي أو اتصال بشاشة إضافية مدمجة، فإنّها:

[C-1-1] يجب تنفيذ خدمة النظام وواجهة برمجة التطبيقات DisplayManager على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

7.2. أجهزة إدخال بيانات

عمليات تنفيذ الجهاز:

[C-0-1] يجب أن يتضمّن آلية إدخال، مثل شاشة تعمل باللمس أو تنقّل غير مستند إلى اللمس، للتنقّل بين عناصر واجهة المستخدم.

‫7.2.1. لوحة المفاتيح

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية استخدام تطبيقات محرّر أسلوب الإدخال (IME) التابعة لجهات خارجية، يجب أن تستوفي ما يلي:

[C-1-1] يجب الإفصاح عن علامة الميزة android.software.input_methods.
[C-1-2] يجب تنفيذ Input Management Framework بالكامل
[C-1-3] يجب أن يتضمّن لوحة مفاتيح برمجية مثبَّتة مسبقًا.

عمليات تنفيذ الجهاز:

[C-0-1] يجب ألا يتضمّن لوحة مفاتيح خارجية لا تتطابق مع أحد التنسيقات المحدّدة في android.content.res.Configuration.keyboard (لوحة مفاتيح QWERTY أو لوحة مفاتيح ذات 12 مفتاحًا).
يجب أن تتضمّن عمليات تنفيذ إضافية للوحة مفاتيح افتراضية.
قد يتضمّن لوحة مفاتيح خارجية.

‫7.2.2. التنقّل بدون لمس

يتوافق نظام التشغيل Android مع لوحة المفاتيح الاتجاهية وكرة التتبّع والعجلة كآليات للتنقّل بدون لمس.

عمليات تنفيذ الجهاز:

[C-0-1] يجب عرض القيمة الصحيحة لـ android.content.res.Configuration.navigation.

إذا كانت عمليات تنفيذ الأجهزة تفتقر إلى وسائل التنقّل غير اللمسية، يجب أن:

[C-1-1] يجب توفير آلية بديلة معقولة لواجهة المستخدم تتيح اختيار النص وتعديله، وتكون متوافقة مع محركات إدارة الإدخال. يتضمّن التنفيذ المتاح المصدر لنظام التشغيل Android آلية اختيار مناسبة للاستخدام مع الأجهزة التي لا تتضمّن أدوات إدخال للتنقّل بدون لمس.

‫7.2.3. مفاتيح التنقل

إنّ وظائف الشاشة الرئيسية والتطبيقات الحديثة والرجوع، التي يتم توفيرها عادةً من خلال التفاعل مع زر مخصّص أو جزء مميّز من شاشة اللمس، ضرورية لنموذج التنقّل في Android، وبالتالي، فإنّ عمليات تنفيذ الأجهزة:

[C-0-1] يجب توفير وسيلة تتيح للمستخدم تشغيل التطبيقات المثبَّتة التي تتضمّن نشاطًا تم ضبط <intent-filter> على ACTION=MAIN و CATEGORY=LAUNCHER أو CATEGORY=LEANBACK_LAUNCHER في عمليات تنفيذ تطبيقات أجهزة التلفزيون. يجب أن تكون وظيفة "الصفحة الرئيسية" هي الآلية التي تتيح للمستخدم الاستفادة من هذه الميزة.
يجب توفير أزرار لوظيفتَي "التطبيقات المستخدَمة مؤخرًا" و"الرجوع".

في حال توفُّر وظائف "الشاشة الرئيسية" أو "التطبيقات الحديثة" أو "الرجوع"، يجب أن:

[C-1-1] يجب أن يكون الوصول إلى المحتوى ممكنًا من خلال إجراء واحد (مثل النقر أو النقر المزدوج أو الإيماءة) عندما يكون أيّ منها متاحًا.
[C-1-2] يجب تقديم إشارة واضحة إلى الإجراء الفردي الذي سيؤدي إلى تشغيل كل وظيفة. وتشمل الأمثلة على ذلك عرض رمز مرئي مطبوع على الزر، أو عرض رمز برنامج على جزء شريط التنقّل من الشاشة، أو توجيه المستخدم خلال عرض توضيحي تفصيلي خطوة بخطوة أثناء تجربة الإعداد عند إخراج الجهاز من العلبة.

عمليات تنفيذ الجهاز:

[C-SR-1] يُنصح بشدة بعدم توفير آلية الإدخال لوظيفة القائمة لأنّها أصبحت قديمة ويُفضّل استخدام شريط الإجراءات بدلاً منها منذ الإصدار 4.0 من نظام التشغيل Android.
[C-SR-2] يُنصح بشدة بتوفير جميع وظائف التنقّل على أنّها قابلة للإلغاء. يُعرَّف الإجراء "قابل للإلغاء" بأنّه قدرة المستخدم على منع تنفيذ وظيفة التنقّل (مثل الانتقال إلى الشاشة الرئيسية أو الرجوع أو غير ذلك) إذا لم يتم رفع الإصبع عن الشاشة بعد تجاوز حدّ معيّن.

إذا كانت عمليات تنفيذ الأجهزة توفّر وظيفة "القائمة"، عليها استيفاء ما يلي:

[C-2-1] يجب عرض زر القائمة الكاملة للإجراءات عندما لا تكون القائمة المنبثقة الخاصة بالقائمة الكاملة للإجراءات فارغة ويكون شريط الإجراءات مرئيًا.
[C-2-2] يجب عدم تعديل موضع النافذة المنبثقة الخاصة بقائمة الخيارات الإضافية التي تظهر عند النقر على زر الخيارات الإضافية في شريط الإجراءات، ولكن يجوز عرض النافذة المنبثقة الخاصة بقائمة الخيارات الإضافية في موضع معدَّل على الشاشة عند عرضها من خلال النقر على وظيفة "القائمة".

إذا لم توفّر عمليات تنفيذ الأجهزة وظيفة "القائمة"، يجب أن تتضمّن ما يلي لضمان التوافق مع الإصدارات السابقة:

[C-3-1] يجب أن توفّر الأجهزة وظيفة "القائمة" للتطبيقات عندما تكون قيمة targetSdkVersion أقل من 10، وذلك إما من خلال زر خارجي أو مفتاح برنامج أو إيماءات. يجب أن تكون وظيفة "القائمة" هذه متاحة ما لم يتم إخفاؤها مع وظائف التنقّل الأخرى.

إذا كانت عمليات تنفيذ الأجهزة توفّر وظيفة "المساعدة"، عليها استيفاء ما يلي:

[C-4-1] يجب أن تكون وظيفة "المساعد" متاحة من خلال إجراء واحد (مثل النقر أو النقر مرّتين أو الإيماءة) عندما تكون مفاتيح التنقّل الأخرى متاحة.
[C-SR-3] يُنصح بشدة باستخدام الضغط مع الاستمرار على وظيفة زر HOME باعتبارها طريقة التفاعل المحدّدة.

إذا كانت عمليات تنفيذ الأجهزة تستخدم جزءًا مميزًا من الشاشة لعرض مفاتيح التنقّل، يجب أن تستوفي ما يلي:

[C-5-1] يجب أن تستخدم مفاتيح التنقّل جزءًا مميزًا من الشاشة لا يمكن للتطبيقات الوصول إليه، ويجب ألا تحجب أو تتداخل بأي شكل من الأشكال مع الجزء المتاح للتطبيقات من الشاشة.
[C-5-2] يجب إتاحة جزء من الشاشة للتطبيقات التي تستوفي المتطلبات المحدّدة في الفقرة 7.1.1.
[C-5-3] يجب الالتزام بالعلامات التي يضبطها التطبيق من خلال طريقة View.setSystemUiVisibility() في واجهة برمجة التطبيقات، وذلك لإخفاء هذا الجزء المميّز من الشاشة (المعروف أيضًا باسم شريط التنقّل) بشكل صحيح كما هو موضّح في حزمة تطوير البرامج (SDK).

إذا كانت وظيفة التنقّل متوفّرة كإجراء مستند إلى الإيماءات على الشاشة:

[C-6-1] يجب استخدام WindowInsets#getMandatorySystemGestureInsets() للإبلاغ عن منطقة التعرّف على إيماءة "الصفحة الرئيسية" فقط.
[C-6-2] يجب عدم اعتراض الإيماءات التي تبدأ داخل مستطيل استبعاد تقدّمه التطبيقات التي تعمل في المقدّمة من خلال View#setSystemGestureExclusionRects()، ولكن خارج WindowInsets#getMandatorySystemGestureInsets()، لوظيفة التنقّل طالما أنّ مستطيل الاستبعاد مسموح به ضمن الحد الأقصى للاستبعاد المحدّد في مستندات View#setSystemGestureExclusionRects().
[C-6-3] يجب إرسال حدث MotionEvent.ACTION_CANCEL إلى التطبيق الذي يعمل في المقدّمة عند بدء اعتراض اللمسات لإجراء إيماءة نظام، إذا سبق أن تم إرسال حدث MotionEvent.ACTION_DOWN إلى التطبيق الذي يعمل في المقدّمة.
[C-6-4] يجب توفير وسيلة تتيح للمستخدم التبديل إلى التنقّل المستند إلى الأزرار على الشاشة (على سبيل المثال، في "الإعدادات").
يجب توفير وظيفة "الشاشة الرئيسية" من خلال التمرير سريعًا من الحافة السفلية للشاشة إلى أعلاها في الاتجاه الحالي للشاشة.
يجب توفير وظيفة "التطبيقات الحديثة" من خلال التمرير سريعًا للأعلى مع الاستمرار في الضغط قبل رفع الإصبع، وذلك من المنطقة نفسها التي يتم منها تنفيذ إيماءة "الصفحة الرئيسية".
يجب ألا تتأثر الإيماءات التي تبدأ ضمن WindowInsets#getMandatorySystemGestureInsets() بمستطيلات الاستبعاد التي يوفّرها التطبيق الذي يعمل في المقدّمة من خلال View#setSystemGestureExclusionRects().

إذا تم توفير وظيفة تنقّل من أي مكان على الحافتين اليمنى واليسرى للاتجاه الحالي للشاشة:

‫[C-7-1] يجب أن تكون وظيفة التنقّل هي "رجوع"، ويجب توفيرها من خلال التمرير السريع من الحافتين اليمنى واليسرى للشاشة في اتجاهها الحالي.
[C-7-2] في حال توفير لوحات نظام مخصّصة يمكن التمرير سريعًا عليها على الحافتين اليمنى أو اليسرى، يجب وضعها ضمن الثلث العلوي من الشاشة مع توفير إشارة مرئية واضحة وثابتة تشير إلى أنّ السحب سيؤدي إلى استدعاء اللوحات المذكورة أعلاه، وبالتالي لن يتم الرجوع إلى الخلف. يمكن للمستخدم ضبط لوحة النظام بحيث تظهر أسفل الثلث العلوي من حواف الشاشة، ولكن يجب ألا تستخدم لوحة النظام أكثر من ثلث الحواف.
[C-7-3] عندما يضبط التطبيق الذي يعمل في المقدّمة أيًا من العلامات View.SYSTEM_UI_FLAG_IMMERSIVE أو View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY أو WindowInsetsController.BEHAVIOR_DEFAULT أو WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE، يجب أن يكون سلوك التمرير السريع من الحواف مطابقًا لما تم تنفيذه في AOSP، وهو موضّح في حزمة SDK.
[C-7-4] عندما يكون التطبيق الذي يظهر في المقدّمة قد تم ضبطه على أحد الخيارات التالية: View.SYSTEM_UI_FLAG_IMMERSIVE أو View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY أو WindowInsetsController.BEHAVIOR_DEFAULT أو WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE، يجب إخفاء لوحات النظام المخصّصة القابلة للتمرير السريع إلى أن يعرض المستخدم أشرطة النظام (المعروفة أيضًا باسم شريطَي التنقّل والحالة) أو يزيل تعتيمها، كما هو موضّح في مشروع Android المفتوح المصدر (AOSP).

في حال توفير وظيفة التنقّل للخلف وألغى المستخدم إيماءة الرجوع، سيحدث ما يلي:

يجب استدعاء [C-8-1] OnBackInvokedCallback.onBackCancelled().
[C-8-2] يجب عدم استدعاء OnBackInvokedCallback.onBackInvoked().
[C-8-3] يجب عدم إرسال الحدث KEYCODE_BACK.

إذا تم توفير وظيفة التنقّل للخلف ولكن لم يتم تسجيل OnBackInvokedCallback في التطبيق الذي يعمل في المقدّمة، سيحدث ما يلي:

يجب أن يوفّر النظام رسمًا متحركًا للتطبيق الذي يعمل في المقدّمة يشير إلى أنّ المستخدم سيعود إلى الخلف، كما هو موضّح في مشروع Android مفتوح المصدر (AOSP).

إذا كانت عمليات تنفيذ الأجهزة توفّر إمكانية استخدام واجهة برمجة التطبيقات للنظام setNavBarMode للسماح لأي تطبيق نظام لديه الإذن android.permission.STATUS_BAR بضبط وضع شريط التنقّل، يجب أن:

[C-9-1] يجب توفير دعم للرموز المناسبة للأطفال أو التنقّل المستند إلى الأزرار كما هو موضّح في رمز AOSP.

‫7.2.4. الإدخال عبر شاشة اللمس

يتوافق Android مع مجموعة متنوعة من أنظمة إدخال المؤشر، مثل الشاشات التي تعمل باللمس ولوحات اللمس وأجهزة إدخال اللمس الوهمي. ترتبط عمليات تنفيذ الأجهزة المستندة إلى شاشة اللمس بشاشة عرض، ما يمنح المستخدم انطباعًا بأنّه يتفاعل مباشرةً مع العناصر الظاهرة على الشاشة. بما أنّ المستخدم يلمس الشاشة مباشرةً، لا يتطلّب النظام أي وسائل مساعدة إضافية للإشارة إلى العناصر التي يتم التفاعل معها.

عمليات تنفيذ الجهاز:

يجب أن يتضمّن نظام إدخال مؤشر من نوع ما (إما شبيهًا بالماوس أو باللمس).
يجب أن يتيح استخدام المؤشرات التي يتم تتبّعها بشكل مستقل تمامًا.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة تعمل باللمس (لمسة واحدة أو أكثر) على شاشة أساسية متوافقة مع Android، يجب أن تستوفي ما يلي:

[C-1-1] يجب عرض TOUCHSCREEN_FINGER لحقل Configuration.touchscreen في واجهة برمجة التطبيقات.
[C-1-2] يجب الإبلاغ عن علامات الميزات android.hardware.touchscreen وandroid.hardware.faketouch.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة تعمل باللمس يمكنها تتبُّع أكثر من لمسة واحدة على شاشة أساسية متوافقة مع Android، يجب أن تستوفي ما يلي:

[C-2-1] يجب عرض علامات الميزات المناسبة android.hardware.touchscreen.multitouch وandroid.hardware.touchscreen.multitouch.distinct وandroid.hardware.touchscreen.multitouch.jazzhand التي تتوافق مع نوع شاشة اللمس المحدّدة على الجهاز.

إذا كانت عمليات تنفيذ الأجهزة تعتمد على جهاز إدخال خارجي، مثل الماوس أو كرة التتبُّع (أي عدم لمس الشاشة مباشرةً) للإدخال على شاشة أساسية متوافقة مع Android وتستوفي متطلبات اللمس الزائف الواردة في القسم 7.2.5، يجب أن:

[C-3-1] يجب عدم الإبلاغ عن أي علامة ميزة تبدأ بـ android.hardware.touchscreen.
[C-3-2] يجب الإبلاغ عن android.hardware.faketouch فقط.
[C-3-3] يجب إدخال القيمة TOUCHSCREEN_NOTOUCH في حقل واجهة برمجة التطبيقات Configuration.touchscreen

‫7.2.5. Fake Touch Input

توفّر واجهة اللمس الوهمي نظام إدخال للمستخدم يحاكي مجموعة فرعية من إمكانات شاشة اللمس. على سبيل المثال، يمكن استخدام ماوس أو جهاز تحكّم عن بُعد لتحريك المؤشر على الشاشة، ما يتيح للمستخدم محاكاة اللمس، ولكن يجب أولاً توجيه المؤشر أو التركيز عليه ثم النقر. يمكن أن تتوافق العديد من أجهزة الإدخال، مثل الماوس ولوحة اللمس والماوس الهوائي المستند إلى الجيروسكوب والمؤشر المستند إلى الجيروسكوب وعصا التحكم ولوحة اللمس المتعددة اللمس، مع التفاعلات التي تحاكي اللمس. يتضمّن نظام التشغيل Android الثابت android.hardware.faketouch الخاص بالميزات، والذي يتوافق مع جهاز إدخال عالي الدقة غير مزوّد بشاشة تعمل باللمس (يعتمد على المؤشر)، مثل الماوس أو لوحة اللمس، ويمكنه محاكاة الإدخال المستند إلى اللمس بشكل مناسب (بما في ذلك إتاحة الإيماءات الأساسية)، ويشير إلى أنّ الجهاز يتيح مجموعة فرعية محاكاة من وظائف الشاشة التي تعمل باللمس.

إذا لم تتضمّن عمليات تنفيذ الأجهزة شاشة تعمل باللمس ولكنها تتضمّن نظام إدخال آخر للمؤشر يريدون إتاحته، عليهم اتّباع ما يلي:

يجب الإفصاح عن توفّر علامة الميزة android.hardware.faketouch.

إذا كانت عمليات تنفيذ الأجهزة تعلن عن توفّر android.hardware.faketouch، عليها استيفاء ما يلي:

[C-1-1] يجب عرض موضعَي X وY المطلقَين على الشاشة لموقع المؤشر وعرض مؤشر مرئي على الشاشة.
[C-1-2] يجب الإبلاغ عن حدث اللمس باستخدام رمز الإجراء الذي يحدّد تغيير الحالة الذي يحدث على المؤشر عندما يتحرّك المؤشر للأعلى أو للأسفل على الشاشة.
‫[C-1-3] يجب أن يتيح الجهاز الضغط مع الاستمرار على مؤشر ثم رفعه عن عنصر على الشاشة، ما يتيح للمستخدمين محاكاة النقر على عنصر على الشاشة.
[C-1-4] يجب أن يتيح الجهاز تنفيذ الإجراءات التالية: الضغط على المؤشر، ورفع المؤشر، والضغط على المؤشر ثم رفعه في المكان نفسه على عنصر في الشاشة خلال مدة زمنية محددة، ما يتيح للمستخدمين محاكاة النقر المزدوج على عنصر في الشاشة.
‫[C-1-5] يجب أن يتيح الجهاز الضغط بالمؤشر على أي نقطة عشوائية على الشاشة، ثم تحريك المؤشر إلى أي نقطة عشوائية أخرى على الشاشة، ثم رفع المؤشر، ما يتيح للمستخدمين محاكاة عملية السحب باللمس.
[C-1-6] يجب أن يتيح الجهاز الضغط مع الاستمرار على المؤشر ثم السماح للمستخدمين بنقل العنصر بسرعة إلى موضع مختلف على الشاشة ثم رفع المؤشر عن الشاشة، ما يتيح للمستخدمين تحريك العنصر بسرعة على الشاشة.

إذا كانت عمليات تنفيذ الأجهزة تعلن عن إتاحة android.hardware.faketouch.multitouch.distinct، فإنّها:

[C-2-1] يجب الإعلان عن إتاحة android.hardware.faketouch.
[C-2-2] يجب أن يتيح تتبُّعًا مميزًا لعمليتَي إدخال أو أكثر مستقلتَين باستخدام المؤشر.

إذا كانت عمليات تنفيذ الأجهزة تعلن عن إتاحة android.hardware.faketouch.multitouch.jazzhand، فإنّها:

[C-3-1] يجب الإعلان عن إتاحة android.hardware.faketouch.
[C-3-2] يجب أن يتيح تتبُّع 5 إدخالات مؤشر أو أكثر بشكل مستقل تمامًا.

‫7.2.6. التوافق مع ذراع التحكّم في الألعاب

‫7.2.6.1. عمليات ربط الأزرار

عمليات تنفيذ الجهاز:

[C-1-1] يجب أن يكون الجهاز قادرًا على ربط أحداث HID بثوابت InputEvent المقابلة كما هو موضّح في الجداول أدناه. يستوفي تنفيذ Android في المصدر هذا الشرط.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن وحدة تحكّم أو يتم شحنها مع وحدة تحكّم منفصلة في العلبة توفّر وسائل لإدخال جميع الأحداث المدرَجة في الجداول أدناه، يجب أن تستوفي ما يلي:

[C-2-1] يجب الإعلان عن علامة الميزة android.hardware.gamepad

زرّ	استخدام HID²	زر Android
A¹	0x09 0x0001	KEYCODE_BUTTON_A (96)
B¹	0x09 0x0002	KEYCODE_BUTTON_B (97)
X¹	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y¹	0x09 0x0005	KEYCODE_BUTTON_Y (100)
لوحة التحكم للأعلى¹ لوحة التحكم للأسفل¹	0x01 0x0039³	AXIS_HAT_Y⁴
لوحة التحكم لليسار1 لوحة التحكم لليمين¹	0x01 0x0039³	AXIS_HAT_X⁴
زر الكتف الأيسر¹	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
زر الكتف الأيمن¹	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
النقر على عصا التحكّم اليسرى¹	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
النقر على عصا التحكّم اليمنى¹	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
رجوع¹	0x0c 0x0224	KEYCODE_BACK (4)

‫1 KeyEvent

‫2 يجب الإفصاح عن استخدامات HID المذكورة أعلاه ضمن CA لوحة الألعاب (0x01 0x0005).

‫3 يجب أن يكون لهذا الاستخدام حد أدنى منطقي يبلغ 0، وحد أقصى منطقي يبلغ 7، وحد أدنى فعلي يبلغ 0، وحد أقصى فعلي يبلغ 315، ووحدات بالدرجات، وحجم تقرير يبلغ 4. يتم تعريف القيمة المنطقية على أنّها الدوران في اتجاه عقارب الساعة بعيدًا عن المحور العمودي. على سبيل المثال، تمثّل القيمة المنطقية 0 عدم الدوران والضغط على زرّ الاتجاه للأعلى، بينما تمثّل القيمة المنطقية 1 دورانًا بمقدار 45 درجة والضغط على كلّ من زرّ الاتجاه للأعلى ولليسار.

‫4 MotionEvent

عناصر التحكّم التناظرية¹	استخدام HID	زر Android
زر التشغيل الأيسر	0x02 0x00C5	AXIS_LTRIGGER
زر التشغيل الأيمن	0x02 0x00C4	AXIS_RTRIGGER
ذراع التحكّم اليسرى	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
ذراع التحكّم اليمنى	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

‫1 MotionEvent

‫7.2.7. التحكم عن بعد

راجِع الفقرة 2.3.1 لمعرفة المتطلبات الخاصة بالأجهزة.

‫7.3. أجهزة الاستشعار

إذا كانت عمليات تنفيذ الأجهزة تتضمّن نوعًا معيّنًا من أجهزة الاستشعار يتضمّن واجهة برمجة تطبيقات (API) مقابلة للمطوّرين الخارجيين، يجب أن تتضمّن عملية تنفيذ الجهاز واجهة برمجة التطبيقات هذه على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK) لنظام Android ومستندات Android Open Source حول أجهزة الاستشعار.

عمليات تنفيذ الجهاز:

[C-0-1] يجب أن يتم الإبلاغ بدقة عن توفّر أجهزة الاستشعار أو عدم توفّرها وفقًا لفئة android.content.pm.PackageManager.
[C-0-2] يجب عرض قائمة دقيقة بأجهزة الاستشعار المتوافقة من خلال SensorManager.getSensorList() والطرق المشابهة.
[C-0-3] يجب أن تتصرف بشكل معقول مع جميع واجهات برمجة التطبيقات الأخرى الخاصة بأجهزة الاستشعار (على سبيل المثال، من خلال عرض true أو false حسب الاقتضاء عندما تحاول التطبيقات تسجيل أدوات معالجة الأحداث، وعدم استدعاء أدوات معالجة الأحداث الخاصة بأجهزة الاستشعار عندما لا تكون أجهزة الاستشعار المقابلة متوفرة، وما إلى ذلك).

إذا كانت عمليات تنفيذ الأجهزة تتضمّن نوعًا معيّنًا من أدوات الاستشعار يتضمّن واجهة برمجة تطبيقات مقابلة للمطوّرين الخارجيين، يجب أن تستوفي ما يلي:

[C-1-1] يجب تسجيل جميع قياسات المستشعر باستخدام قيم النظام الدولي للوحدات (المترية) المناسبة لكل نوع من المستشعرات على النحو المحدّد في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
[C-1-2] يجب إرسال بيانات جهاز الاستشعار بحد أقصى لوقت الاستجابة يبلغ 100 ملي ثانية + 2 * sample_time في حالة بث بيانات جهاز الاستشعار بحد أقصى لوقت الاستجابة المطلوب يبلغ 0 ملي ثانية عندما يكون معالج تطبيقات نشطًا. لا يشمل هذا التأخير أي تأخيرات في الفلترة.
[C-1-3] يجب إرسال عيّنة المستشعر الأولى في غضون 400 ملي ثانية + 2 * sample_time من تفعيل المستشعر. من المقبول أن تبلغ دقة هذه العيّنة 0.
[C-1-4] بالنسبة إلى أي واجهة برمجة تطبيقات تشير مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android إلى أنّها مستشعر مستمر، يجب أن توفّر عمليات تنفيذ الأجهزة بشكل مستمر عينات بيانات دورية يجب أن يكون فيها تفاوت أقل من %3، ويُعرَّف التفاوت بأنّه الانحراف المعياري للفرق بين قيم الطوابع الزمنية المُسجَّلة بين الأحداث المتتالية.
[C-1-5] يجب التأكّد من أنّ بث بيانات أحداث المستشعر يجب ألا يمنع وحدة المعالجة المركزية للجهاز من الانتقال إلى حالة تعليق أو الاستيقاظ من حالة تعليق.
[C-1-6] يجب إرسال وقت الحدث بالنانو ثانية كما هو محدّد في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android، ما يمثّل الوقت الذي وقع فيه الحدث وتمت مزامنته مع ساعة SystemClock.elapsedRealtimeNano().
[C-SR-1] يُنصح بشدة أن يكون خطأ مزامنة الطابع الزمني أقل من 100 مللي ثانية، ويجب أن يكون خطأ مزامنة الطابع الزمني أقل من 1 مللي ثانية.
عند تفعيل عدّة مستشعرات، يجب ألا يتجاوز استهلاك الطاقة مجموع استهلاك الطاقة الذي أبلغ عنه كل مستشعر على حدة.

القائمة أعلاه ليست شاملة، ويجب اعتبار السلوك الموثّق لحزمة تطوير البرامج (SDK) لنظام التشغيل Android ومستندات Android المفتوحة المصدر حول أجهزة الاستشعار مرجعًا موثوقًا.

[C-1-6] يجب ضبط دقة غير صفرية لجميع أجهزة الاستشعار، والإبلاغ عن القيمة باستخدام طريقة Sensor.getResolution() في واجهة برمجة التطبيقات.

بعض أنواع المستشعرات مركّبة، ما يعني أنّه يمكن استخلاصها من البيانات التي يقدّمها مستشعر واحد أو أكثر. (وتشمل الأمثلة مستشعر الاتجاه ومستشعر التسارع الخطي).

عمليات تنفيذ الجهاز:

يجب تنفيذ أنواع أدوات الاستشعار هذه، عندما تتضمّن أدوات الاستشعار المادية المطلوبة مسبقًا كما هو موضّح في أنواع أدوات الاستشعار.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن أداة استشعار مركّبة، يجب أن:

‫[C-2-1] يجب تنفيذ أداة الاستشعار على النحو الموضّح في مستندات Android Open Source حول أدوات الاستشعار المركّبة.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن نوعًا معيّنًا من أجهزة الاستشعار يتضمّن واجهة برمجة تطبيقات مقابلة للمطوّرين الخارجيين، وكان جهاز الاستشعار يعرض قيمة واحدة فقط، يجب أن تتضمّن عمليات تنفيذ الأجهزة ما يلي:

[C-3-1] يجب ضبط الدقة على 1 للمستشعر وإرسال القيمة باستخدام طريقة واجهة برمجة التطبيقات Sensor.getResolution().

إذا كانت عمليات تنفيذ الأجهزة تتضمّن نوعًا معيّنًا من أجهزة الاستشعار التي تتوافق مع SensorAdditionalInfo#TYPE_VEC3_CALIBRATION وكان جهاز الاستشعار متاحًا للمطوّرين الخارجيين، عليهم:

[C-4-1] يجب ألا تتضمّن البيانات المقدَّمة أي معلَمات معايرة ثابتة ومحدَّدة من المصنع.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مجموعة من مقياس تسارع ثلاثي المحاور أو جهاز استشعار جيروسكوب ثلاثي المحاور أو جهاز استشعار مغناطيسي، تكون على النحو التالي:

[C-SR-2] يُنصح بشدة بضمان ثبات الموضع النسبي لمقياس التسارع والجيروسكوب ومقياس المغناطيسية، بحيث تظل محاور أجهزة الاستشعار متوافقة ومتسقة مع نظام إحداثيات أجهزة الاستشعار في جميع حالات تحويل الجهاز المحتملة (مثل الأجهزة القابلة للطي).

‫7.3.1. مقياس التسارع

عمليات تنفيذ الجهاز:

[C-SR-1] يُنصح بشدة بتضمين مقياس تسارع ثلاثي المحاور.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس تسارع، يجب أن:

[C-1-1] يجب أن يكون الجهاز قادرًا على تسجيل الأحداث بمعدّل تكرار يبلغ 50 هرتز على الأقل.
[C-1-3] يجب أن يتوافق مع نظام إحداثيات مستشعر Android كما هو موضّح بالتفصيل في واجهات برمجة التطبيقات لنظام Android.
[C-1-4] يجب أن يكون الجهاز قادرًا على قياس التسارع الناتج عن السقوط الحر حتى أربعة أضعاف gravity(4g) أو أكثر على أي محور.
[C-1-5] يجب أن تبلغ درجة الدقة 12 بت على الأقل.
[C-1-6] يجب أن يكون الانحراف المعياري أقل من أو يساوي 0.05 م/ث^2، حيث يجب احتساب الانحراف المعياري لكل محور على أساس العيّنات التي تم جمعها على مدار 3 ثوانٍ على الأقل بأسرع معدّل أخذ عيّنات.
يجب أن يتم تسجيل الأحداث بمعدّل 200 هرتز على الأقل.
يجب أن تكون درجة الدقة 16 بت على الأقل.
يجب معايرته أثناء الاستخدام إذا تغيرت الخصائص على مدار دورة الحياة، ويجب تعويضه، ويجب الاحتفاظ بمعلمات التعويض بين عمليات إعادة تشغيل الجهاز.
يجب أن يكون مزوّدًا بمُعدِّل حرارة.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس تسارع ثلاثي المحاور، يجب أن:

[C-2-1] يجب تنفيذ جهاز استشعار TYPE_ACCELEROMETER وإعداد تقرير عنه.
[C-SR-4] يُنصح بشدة بتنفيذ TYPE_SIGNIFICANT_MOTIONأداة الاستشعار المركّبة.
[C-SR-5] يُنصح بشدة بتنفيذ مستشعر TYPE_ACCELEROMETER_UNCALIBRATED وإعداد تقارير عنه. ننصح بشدة أجهزة Android باستيفاء هذا الشرط لتتمكّن من الترقية إلى إصدار النظام الأساسي المستقبلي الذي قد يصبح فيه هذا الشرط إلزاميًا.
يجب تنفيذ أجهزة الاستشعار المركّبة TYPE_SIGNIFICANT_MOTION وTYPE_TILT_DETECTOR وTYPE_STEP_DETECTOR وTYPE_STEP_COUNTER كما هو موضّح في مستند حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس تسارع بأقل من 3 محاور، يجب أن:

[C-3-1] يجب تنفيذ جهاز استشعار TYPE_ACCELEROMETER_LIMITED_AXES وإعداد تقرير عنه.
[C-SR-6] يُنصح بشدة بتنفيذ TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED sensor وإعداد تقارير عنه.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس تسارع ثلاثي المحاور وأي من أجهزة الاستشعار المركّبة TYPE_SIGNIFICANT_MOTION أو TYPE_TILT_DETECTOR أو TYPE_STEP_DETECTOR أو TYPE_STEP_COUNTER:

[C-4-1] يجب أن يكون مجموع استهلاك الطاقة أقل من 4 ملّي واط في جميع الأوقات.
يجب أن يكون كل منهما أقل من 2 ملّي واط و0.5 ملّي واط عندما يكون الجهاز في حالة ديناميكية أو ثابتة.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس تسارع ثلاثي المحاور وجيروسكوب ثلاثي المحاور، يجب أن تستوفي ما يلي:

[C-5-1] يجب تنفيذ أدوات الاستشعار المركّبة TYPE_GRAVITY وTYPE_LINEAR_ACCELERATION.
[C-SR-7] يُنصح بشدة بتنفيذ TYPE_GAME_ROTATION_VECTOR أداة الاستشعار المركّبة.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس تسارع ثلاثي المحاور ومستشعر جيروسكوب ثلاثي المحاور ومستشعر مقياس المغناطيسية، يجب أن تستوفي ما يلي:

[C-6-1] يجب تنفيذ أداة استشعار مركّبة TYPE_ROTATION_VECTOR.

‫7.3.2. مقياس المغناطيسية

عمليات تنفيذ الجهاز:

‫[C-SR-1] يُنصح بشدة بتضمين مقياس مغناطيسي ثلاثي المحاور (بوصلة).

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس مغناطيسية ثلاثي المحاور، يجب أن تستوفي ما يلي:

[C-1-1] يجب تنفيذ أداة الاستشعار TYPE_MAGNETIC_FIELD.
[C-1-2] يجب أن يكون الجهاز قادرًا على تسجيل الأحداث بمعدّل تكرار يبلغ 10 هرتز على الأقل، ويجب أن يسجّل الأحداث بمعدّل تكرار يبلغ 50 هرتز على الأقل.
[C-1-3] يجب أن يتوافق مع نظام إحداثيات مستشعر Android كما هو موضّح بالتفصيل في واجهات برمجة التطبيقات لنظام Android.
[C-1-4] يجب أن يكون الجهاز قادرًا على قياس المجال المغناطيسي بين ‎-900 µT و‎+900 µT على كل محور قبل التشبع.
[C-1-5] يجب أن تكون قيمة إزاحة الحديد الصلب أقل من 700 µT، ويجب أن تكون القيمة أقل من 200 µT، وذلك عن طريق وضع مقياس المغناطيسية بعيدًا عن المجالات المغناطيسية الديناميكية (الناتجة عن التيار) والثابتة (الناتجة عن المغناطيس).
‫[C-1-6] يجب أن تكون درجة الدقة مساوية لـ 0.6 µT أو أعلى.
[C-1-7] يجب أن يتيح الجهاز إجراء المعايرة والتعويض على الإنترنت عن انحراف الحديد الصلب، وأن يحتفظ بمعلمات التعويض بين عمليات إعادة تشغيل الجهاز.
[C-1-8] يجب تطبيق تعويض الحديد اللين، ويمكن إجراء المعايرة أثناء الاستخدام أو أثناء إنتاج الجهاز.
[C-1-9] يجب أن يكون الانحراف المعياري محسوبًا على أساس كل محور من العيّنات التي تم جمعها على مدار فترة لا تقل عن 3 ثوانٍ بأسرع معدّل أخذ عيّنات، وألا يزيد عن 1.5 µT، ويجب ألا يزيد الانحراف المعياري عن 0.5 µT.
[C-1-10] يجب تنفيذ TYPE_MAGNETIC_FIELD_UNCALIBRATED المستشعر.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس مغناطيسية ثلاثي المحاور ومقياس تسارع وجيروسكوب ثلاثي المحاور، يجب أن تستوفي ما يلي:

[C-2-1] يجب تنفيذ أداة استشعار مركّبة TYPE_ROTATION_VECTOR.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس مغناطيسية ثلاثي المحاور ومقياس تسارع، يجب أن:

قد يتم تنفيذ أداة الاستشعار TYPE_GEOMAGNETIC_ROTATION_VECTOR.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس مغناطيسية ثلاثي المحاور ومقياس تسارع ومستشعر TYPE_GEOMAGNETIC_ROTATION_VECTOR، يجب أن تستوفي ما يلي:

‫[C-3-1] يجب أن يكون استهلاك الطاقة أقل من 10 ملّي واط.
يجب أن يكون استهلاك الطاقة أقل من 3 ملّي واط عند تسجيل المستشعر في وضع الدفعات بمعدّل 10 هرتز.

‫7.3.3. نظام تحديد المواقع العالمي (GPS)

عمليات تنفيذ الجهاز:

[C-SR-1] يُنصح بشدة بتضمين جهاز استقبال GPS/GNSS.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن جهاز استقبال GPS/GNSS وتُبلغ التطبيقات عن الإمكانية من خلال علامة الميزة android.hardware.location.gps، فإنّها:

[C-1-1] يجب أن تتوافق مع مخرجات الموقع الجغرافي بمعدّل 1 هرتز على الأقل عند طلبها عبر LocationManager#requestLocationUpdate.
[C-1-2] يجب أن يكون الجهاز قادرًا على تحديد الموقع الجغرافي في ظروف السماء المفتوحة (إشارات قوية، وتعدد مسارات ضئيل، ودقة تحديد الموقع الأفقي (HDOP) أقل من 2) في غضون 10 ثوانٍ (وقت سريع لتحديد الموقع الجغرافي لأول مرة)، وذلك عند الاتصال بشبكة إنترنت بسرعة بيانات تبلغ 0.5 ميغابت في الثانية أو أكثر. يتم استيفاء هذا الشرط عادةً باستخدام شكل من أشكال تقنية نظام تحديد المواقع العالمي (GPS) أو نظام الملاحة العالمي عبر الأقمار الصناعية (GNSS) بمساعدة أو بتوقّع، وذلك لتقليل وقت تحديد الموقع الجغرافي باستخدام نظام تحديد المواقع العالمي (GPS) أو نظام الملاحة العالمي عبر الأقمار الصناعية (GNSS) (تتضمّن بيانات المساعدة الوقت المرجعي والموقع الجغرافي المرجعي والمدار الفلكي/الساعة للقمر الصناعي).
- [C-1-6] بعد إجراء عملية حسابية للموقع الجغرافي، يجب أن تحدّد عمليات تنفيذ الجهاز الموقع الجغرافي في السماء المفتوحة في غضون 5 ثوانٍ عند إعادة تشغيل طلبات الموقع الجغرافي، وذلك لمدة تصل إلى ساعة بعد عملية حساب الموقع الجغرافي الأولية، حتى عندما يتم تقديم الطلب اللاحق بدون اتصال بيانات و/أو بعد إعادة التشغيل.
في ظروف السماء المفتوحة بعد تحديد الموقع الجغرافي، سواء كنت ثابتًا أو تتحرّك بتسارع أقل من متر واحد في الثانية المربّعة:
- [C-1-3] يجب أن يكون الجهاز قادرًا على تحديد الموقع الجغرافي في نطاق 20 مترًا، والسرعة في نطاق 0.5 متر في الثانية، وذلك بنسبة% 95 على الأقل من الوقت.
- [C-1-4] يجب تتبُّع 8 أقمار صناعية على الأقل من مجموعة واحدة وإرسال بياناتها في الوقت نفسه عبر GnssStatus.Callback.
- يجب أن يكون الجهاز قادرًا على تتبُّع 24 قمرًا صناعيًا على الأقل في الوقت نفسه من مجموعات متعددة (مثل نظام تحديد المواقع العالمي (GPS) وقمر واحد على الأقل من أقمار Glonass أو Beidou أو Galileo).
[C-SR-2] يُنصح بشدة بمواصلة تقديم نواتج الموقع الجغرافي العادية لنظام تحديد المواقع العالمي (GPS) أو نظام الملاحة العالمي عبر الأقمار الصناعية (GNSS) من خلال واجهات برمجة التطبيقات الخاصة بمزوّد خدمة الموقع الجغرافي لنظام GNSS أثناء مكالمة هاتفية للطوارئ.
‫[C-SR-3] يُنصح بشدة بإرسال بيانات قياسات نظام GNSS من جميع الأبراج الفضائية التي يتم تتبّعها (كما هو موضّح في رسائل GnssStatus)، باستثناء نظام SBAS.
[C-SR-4] يُنصح بشدة بالإبلاغ عن AGC وعدد مرات قياس GNSS.
[C-SR-5] يُنصح بشدة بالإبلاغ عن جميع تقديرات الدقة (بما في ذلك الاتجاه والسرعة والارتفاع) كجزء من كل موقع جغرافي لنظام تحديد المواقع العالمي (GPS) أو نظام GNSS.
[C-SR-6] يُنصح بشدة بالإبلاغ عن قياسات GNSS فور العثور عليها، حتى إذا لم يتم بعد الإبلاغ عن الموقع الجغرافي المحسوب من نظام تحديد المواقع العالمي (GPS) أو نظام GNSS.
[C-SR-7] يُنصح بشدة بالإبلاغ عن النطاقات الزائفة لنظام GNSS ومعدلات النطاقات الزائفة التي تكون كافية لاحتساب الموقع الجغرافي في حدود 20 مترًا والسرعة في حدود 0.2 متر في الثانية، وذلك بنسبة% 95 على الأقل من الوقت، في ظروف السماء المفتوحة بعد تحديد الموقع الجغرافي، سواء كان الجهاز ثابتًا أو يتحرّك بمعدّل تسارع أقل من 0.2 متر في الثانية المربعة.

‫7.3.4. الجيروسكوب

عمليات تنفيذ الجهاز:

[C-SR-1] يُنصح بشدة بتضمين مستشعر جيروسكوب.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن جيروسكوبًا، يجب أن تستوفي ما يلي:

[C-1-1] يجب أن يكون الجهاز قادرًا على تسجيل الأحداث بمعدّل تكرار يبلغ 50 هرتز على الأقل.
[C-1-4] يجب أن تكون درجة الدقة 12 بت أو أكثر.
[C-1-5] يجب أن يكون مزوّدًا بمُعدِّل حرارة.
[C-1-6] يجب معايرته وتعويضه أثناء الاستخدام، ويجب الاحتفاظ بمعلمات التعويض بين عمليات إعادة تشغيل الجهاز.
[C-1-7] يجب ألا يتجاوز التباين 1e-7 rad^2 / s^2 لكل هرتز (التباين لكل هرتز، أو rad^2 / s). يُسمح بأن يختلف التباين مع معدّل أخذ العيّنات، ولكن يجب أن يكون مقيّدًا بهذه القيمة. بعبارة أخرى، إذا قست تباين الجيروسكوب بمعدل أخذ عينات يبلغ 1 هرتز، يجب ألا يتجاوز 1e-7 rad^2/s^2.
‫[C-SR-2] يُنصح بشدة بأن يكون خطأ المعايرة أقل من 0.01 راديان/ثانية عندما يكون الجهاز ثابتًا في درجة حرارة الغرفة.
[C-SR-3] يُنصح بشدة أن تكون درجة الدقة 16 بت أو أكثر.
يجب أن يتم تسجيل الأحداث بمعدّل 200 هرتز على الأقل.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن جيروسكوبًا ثلاثي المحاور، يجب أن:

[C-2-1] يجب تنفيذ أداة الاستشعار TYPE_GYROSCOPE.
‫[C-SR-4] يُنصح بشدة بتنفيذ TYPE_GYROSCOPE_UNCALIBRATED المستشعر.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن جيروسكوبًا بأقل من 3 محاور، يجب أن:

[C-3-1] يجب تنفيذ جهاز استشعار TYPE_GYROSCOPE_LIMITED_AXES وإعداد تقرير عنه.
[C-SR-5] يُنصح بشدة بتنفيذ مستشعر TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED وإعداد تقارير عنه.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن جيروسكوبًا ثلاثي المحاور ومستشعر تسارع ومستشعر مقياس مغناطيسي، يجب أن:

[C-4-1] يجب تنفيذ أداة استشعار مركّبة TYPE_ROTATION_VECTOR.

[C-5-1] يجب تنفيذ أدوات الاستشعار المركّبة TYPE_GRAVITY وTYPE_LINEAR_ACCELERATION.
[C-SR-6] يُنصح بشدة بتنفيذ أداة الاستشعار المركّبة TYPE_GAME_ROTATION_VECTOR.

‫7.3.5. مقياس الضغط الجوي

عمليات تنفيذ الجهاز:

‫[C-SR-1] يُنصح بشدة بتضمين مقياس ضغط جوي (جهاز استشعار ضغط الهواء المحيط).

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياسًا للضغط الجوي، يجب أن:

[C-1-1] يجب تنفيذ جهاز استشعار TYPE_PRESSURE وتقديم تقرير عنه.
[C-1-2] يجب أن يكون الجهاز قادرًا على عرض الأحداث بمعدّل 5 هرتز أو أكثر.
[C-1-3] يجب أن يكون مزوّدًا بمُعدِّل حرارة.
‫[C-SR-2] يُنصح بشدة أن يكون الجهاز قادرًا على تسجيل قياسات الضغط في النطاق من 300 هكتوباسكال إلى 1100 هكتوباسكال.
يجب أن تبلغ الدقة المطلقة 1 هكتوباسكال.
يجب أن تبلغ الدقة النسبية 0.12 هكتوباسكال على مدى 20 هكتوباسكال (أي ما يعادل دقة تبلغ مترًا واحدًا على مدى تغيُّر يبلغ 200 متر عند مستوى سطح البحر).

عمليات تنفيذ الأجهزة التي تعرّف خاصية النظام sensor.barometer.high_quality.implemented:

[C-2-1] يجب أن تعرض القياسات في نطاق يتراوح بين 300 هكتوباسكال و1100 هكتوباسكال، مع دقة مطلقة تبلغ ‎+/- 1 هكتوباسكال.
[C-2-2] يجب أن تبلغ الدقة النسبية 0.15 هكتوباسكال على مدى 100 هكتوباسكال، أي ما يعادل دقة تبلغ مترًا واحدًا تقريبًا على مدى تغيير يبلغ 1, 000 متر تقريبًا عند مستوى سطح البحر.
‫[C-2-3] يجب أن يكون الضغط الجوي ثابتًا في نطاق ‎+/- 0.5 hPa عندما ينقر المستخدم على الجهاز أو يضغط عليه أو يعصره.
‫[C-2-4] يجب أن يكون مستقرًا في نطاق ‎+/- 0.15 hPa عندما يمشي المستخدم حاملاً الجهاز في يده أو في جيبه.
[C-2-5] يجب عدم تنعيمها بثابت زمني يزيد عن 300 مللي ثانية لعمليات التفعيل التي تزيد عن 5 هرتز، ويجب ألا يتسرّب التنعيم بين عمليات تفعيل أداة الاستشعار.
[C-2-6] يجب أن يكون مستقرًا في نطاق ‎+/- 0.15 hPa عند تعرّضه للإضاءة اليومية والترددات اللاسلكية الصادرة عن مصادر شائعة، مثل البلوتوث أو الاتصال بشبكة الجوّال أو شبكة Wi-Fi.

‫7.3.6. مقياس درجة الحرارة

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس حرارة محيطة (جهاز استشعار الحرارة)، يجب أن تستوفي ما يلي:

[C-1-1] يجب تحديد SENSOR_TYPE_AMBIENT_TEMPERATURE لجهاز استشعار درجة الحرارة المحيطة، ويجب أن يقيس جهاز الاستشعار درجة الحرارة المحيطة (في الغرفة أو مقصورة المركبة) من المكان الذي يتفاعل فيه المستخدم مع الجهاز بالدرجات المئوية.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن أداة استشعار لقياس درجة الحرارة غير المحيطة، مثل درجة حرارة وحدة المعالجة المركزية، يجب أن تستوفي ما يلي:

[C-2-1] يجب عدم تحديد SENSOR_TYPE_AMBIENT_TEMPERATURE لجهاز استشعار الحرارة.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مستشعرًا لمراقبة درجة حرارة الجلد، يجب أن تستوفي ما يلي:

[C-SR-1] يُنصح بشدة بتوفير واجهة برمجة التطبيقات PowerManager.getThermalHeadroom.

‫7.3.7. مقياس الضوء

قد تتضمّن عمليات تنفيذ الأجهزة مقياس ضوء (أداة استشعار الضوء المحيط).

‫7.3.8. أداة استشعار التقارب

قد تتضمّن عمليات تنفيذ الأجهزة أداة استشعار التقارب.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن أداة استشعار التقارب ولا تعرض سوى قراءة ثنائية "قريب" أو "بعيد"، يجب أن تستوفي ما يلي:

‫[C-1-1] يجب قياس مدى قرب عنصر في الاتجاه نفسه الذي تتخذه الشاشة. أي أنّ مستشعر التقارب يجب أن يكون موجّهًا لرصد الأجسام القريبة من الشاشة، لأنّ الغرض الأساسي من هذا النوع من المستشعرات هو رصد الهاتف أثناء استخدام المستخدم له. إذا كانت عمليات تنفيذ الجهاز تتضمّن مستشعر تقارب بأي اتجاه آخر، يجب ألا يكون متاحًا من خلال واجهة برمجة التطبيقات هذه.
[C-1-2] يجب أن تتضمّن دقة بت واحد أو أكثر.
[C-1-3] يجب استخدام 0 سنتيمتر للقراءة القريبة و5 سنتيمترات للقراءة البعيدة.
[C-1-4] يجب عرض الحد الأقصى للنطاق والدقة البالغَين 5.

‫7.3.9. أجهزة استشعار عالية الدقة

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مجموعة من أدوات الاستشعار ذات الجودة الأعلى على النحو المحدّد في هذا القسم، وتتيحها للتطبيقات التابعة لجهات خارجية، عليها استيفاء ما يلي:

[C-1-1] يجب تحديد الإمكانية من خلال علامة الميزة android.hardware.sensor.hifi_sensors.

إذا كانت عمليات تنفيذ الأجهزة تعرّف android.hardware.sensor.hifi_sensors، عليها استيفاء ما يلي:

[C-2-1] يجب أن يحتوي على أداة استشعار TYPE_ACCELEROMETER التي:
- يجب أن يتراوح نطاق القياس بين ‎-8g و‎+8g على الأقل، ويُنصح بشدة أن يتراوح نطاق القياس بين ‎-16g و‎+16g على الأقل.
- يجب أن تبلغ درجة دقة القياس 2048 LSB/g على الأقل.
- يجب أن يكون الحدّ الأدنى لتردّد القياس 12.5 هرتز أو أقل.
- يجب أن يكون الحد الأقصى لعدد مرات القياس 400 هرتز أو أكثر؛ يجب أن يتوافق مع SensorDirectChannel RATE_VERY_FAST.
- يجب ألا يتجاوز تشويش القياس 400 μg/√Hz.
- يجب تنفيذ شكل غير مُفعِّل لهذا المستشعر مع إمكانية التخزين المؤقت لما لا يقل عن 3000 حدث من أحداث المستشعر.
- يجب ألا يزيد استهلاك الطاقة في عملية تجميع البيانات عن 3 ملّي واط.
- [C-SR-1] يُنصح بشدة أن يكون عرض نطاق القياس عند 3 ديسيبل بنسبة% 80 على الأقل من تردد نيكويست، وأن يكون طيف الضوضاء البيضاء ضمن عرض النطاق هذا.
- يجب أن يكون معدّل التغيّر العشوائي في التسارع أقل من 30 μg √Hz عند اختباره في درجة حرارة الغرفة.
- يجب أن يكون التغيّر في الانحياز مقارنةً بدرجة الحرارة ≤ +/- 1 مغ/درجة مئوية.
- يجب أن يكون الانحراف عن الخط المستقيم لأفضل ملاءمة ≤ 0.5%، وتغيُّر الحساسية مقابل درجة الحرارة ≤ 0.03%/درجة مئوية.
- يجب أن تبلغ حساسية المحور المتقاطع أقل من % 2.5 وأن يكون التغيّر في حساسية المحور المتقاطع أقل من% 0.2 في نطاق درجة حرارة تشغيل الجهاز.
[C-2-2] يجب أن يتضمّن TYPE_ACCELEROMETER_UNCALIBRATED يستوفي متطلبات الجودة نفسها التي يستوفيها TYPE_ACCELEROMETER.
[C-2-3] يجب أن يحتوي على أداة استشعار TYPE_GYROSCOPE التي:
- يجب أن يتراوح نطاق القياس بين 1000- و1000+ وحدة في الثانية على الأقل.
- يجب أن تبلغ دقة القياس 16 LSB/dps على الأقل.
- يجب أن يكون الحدّ الأدنى لتردّد القياس 12.5 هرتز أو أقل.
- يجب أن يكون الحد الأقصى لعدد مرات القياس 400 هرتز أو أكثر؛ يجب أن يتوافق مع SensorDirectChannel RATE_VERY_FAST.
- يجب ألا يتجاوز التشويش في القياس 0.014&°/s/√Hz.
- [C-SR-2] يُنصح بشدة أن يكون عرض نطاق قياس 3 ديسيبل بنسبة% 80 على الأقل من تردد نيكويست، وأن يكون طيف الضوضاء البيضاء ضمن عرض النطاق هذا.
- يجب أن يكون معدّل المشي العشوائي أقل من ‎0.001&°/s √Hz عند اختباره في درجة حرارة الغرفة.
- يجب أن يكون التغيّر في الانحياز مقارنةً بدرجة الحرارة ≤ +/- 0.05&°/ s / °C.
- يجب أن يكون التغيّر في الحساسية مقارنةً بدرجة الحرارة ≤ 0.02% / درجة مئوية.
- يجب أن يكون للانحراف غير الخطي لأفضل خط مناسب قيمة ≤ 0.2%.
- يجب أن تبلغ كثافة الضوضاء فيه ‎≤ 0.007&°/s/√Hz.
- يجب أن يكون خطأ المعايرة أقل من 0.002 راديان/ثانية في نطاق درجة الحرارة من 10 إلى 40 درجة مئوية عندما يكون الجهاز ثابتًا.
- يجب أن تكون حساسية الجاذبية أقل من 0.1&°/s/g.
- يجب أن تبلغ حساسية المحور المتقاطع أقل من % 4.0 وأن يكون تفاوت حساسية المحور المتقاطع أقل من% 0.3 في نطاق درجة حرارة تشغيل الجهاز.
[C-2-4] يجب أن يحتوي على TYPE_GYROSCOPE_UNCALIBRATED يستوفي متطلبات الجودة نفسها التي يستوفيها TYPE_GYROSCOPE.
[C-2-5] يجب أن يحتوي على أداة استشعار TYPE_GEOMAGNETIC_FIELD التي:
- يجب أن يتضمّن نطاق قياس بين 900- و900+ ميكرو تسلا على الأقل.
- يجب أن تبلغ درجة دقة القياس 5 LSB/uT على الأقل.
- يجب أن يكون الحدّ الأدنى لتكرار القياس 5 هرتز أو أقل.
- يجب أن يكون الحد الأقصى لعدد مرات القياس 50 هرتز أو أكثر.
- يجب ألا يتجاوز التشويش في القياس 0.5 ميكرو تسلا.
[C-2-6] يجب أن تتضمّن TYPE_MAGNETIC_FIELD_UNCALIBRATED بالجودة نفسها المطلوبة في TYPE_GEOMAGNETIC_FIELD، بالإضافة إلى ما يلي:
- يجب تنفيذ شكل غير مفعّل من هذا المستشعر مع إمكانية تخزين مؤقت لما لا يقل عن 600 حدث من أحداث المستشعر.
- [C-SR-3] يُنصح بشدة بأن يتضمّن الطيف الضوضائي الأبيض نطاقًا من 1 هرتز إلى 10 هرتز على الأقل عندما يكون معدّل إعداد التقارير 50 هرتز أو أعلى.
[C-2-7] يجب أن يحتوي على أداة استشعار TYPE_PRESSURE تعمل على:
- يجب أن يتراوح نطاق القياس بين 300 و1100 هكتوباسكال على الأقل.
- يجب أن تبلغ دقة القياس 80 LSB/hPa على الأقل.
- يجب أن يكون الحدّ الأدنى لتردّد القياس 1 هرتز أو أقل.
- يجب أن يكون الحد الأقصى لعدد مرات القياس 10 هرتز أو أكثر.
- يجب ألا يتجاوز مستوى التشويش في القياس 2 باسكال لكل جذر هرتز.
- يجب تنفيذ شكل غير مفعّل من أداة الاستشعار هذه مع إمكانية التخزين المؤقت لما لا يقل عن 300 حدث من أحداث أداة الاستشعار.
- يجب أن يكون استهلاك الطاقة في عملية تجميع البيانات لا يزيد عن 2 ملّي واط.
[C-2-8] يجب أن يحتوي على مستشعر TYPE_GAME_ROTATION_VECTOR.
[C-2-9] يجب أن يحتوي على أداة استشعار TYPE_SIGNIFICANT_MOTION تعمل على:
- يجب ألا يزيد استهلاك الطاقة عن 0.5 ملّي واط عندما يكون الجهاز ثابتًا، وعن 1.5 ملّي واط عندما يكون الجهاز متحركًا.
[C-2-10] يجب أن يحتوي الجهاز على أداة استشعار TYPE_STEP_DETECTOR تعمل على النحو التالي:
- يجب تنفيذ شكل غير مفعّل من أداة الاستشعار هذه مع إمكانية التخزين المؤقت لما لا يقل عن 100 حدث من أحداث أداة الاستشعار.
- يجب ألا يزيد استهلاك الطاقة عن 0.5 ملّي واط عندما يكون الجهاز ثابتًا، وعن 1.5 ملّي واط عندما يكون الجهاز متحركًا.
- يجب ألا يزيد استهلاك الطاقة في عملية تجميع البيانات عن 4 ملّي واط.
[C-2-11] يجب أن يحتوي على مستشعر TYPE_STEP_COUNTER الذي:
- يجب ألا يزيد استهلاك الطاقة عن 0.5 ملّي واط عندما يكون الجهاز ثابتًا، وعن 1.5 ملّي واط عندما يكون الجهاز متحركًا.
[C-2-12] يجب أن يحتوي على أداة استشعار TILT_DETECTOR تعمل على النحو التالي:
- يجب ألا يزيد استهلاك الطاقة عن 0.5 ملّي واط عندما يكون الجهاز ثابتًا، وعن 1.5 ملّي واط عندما يكون الجهاز متحركًا.
[C-2-13] يجب أن يكون الطابع الزمني للحدث نفسه الذي تم تسجيله بواسطة مقياس التسارع والجيروسكوب ومقياس المغناطيسية في نطاق 2.5 ملي ثانية من بعضها البعض. يجب أن يكون الطابع الزمني للحدث الفعلي نفسه الذي تم تسجيله بواسطة مقياس التسارع والجيروسكوب في نطاق 0.25 مللي ثانية من بعضهما البعض.
[C-2-14] يجب أن تتضمّن أحداث مستشعر الجيروسكوب طوابع زمنية تستند إلى الوقت نفسه الذي يستند إليه نظام الكاميرا الفرعي، وأن يكون الخطأ في حدود 1 ملي ثانية.
[C-2-15] يجب أن يتم تسليم العيّنات إلى التطبيقات في غضون 5 ملي ثانية من وقت توفّر البيانات على أي من أجهزة الاستشعار المادية المذكورة أعلاه للتطبيق.
[C-2-16] يجب ألا يزيد استهلاك الطاقة عن 0.5 ملّي واط عندما يكون الجهاز ثابتًا و2.0 ملّي واط عندما يكون الجهاز متحركًا عند تفعيل أي مجموعة من أجهزة الاستشعار التالية:
- SENSOR_TYPE_SIGNIFICANT_MOTION
- SENSOR_TYPE_STEP_DETECTOR
- SENSOR_TYPE_STEP_COUNTER
- SENSOR_TILT_DETECTORS
[C-2-17] قد يتضمّن الجهاز مستشعر TYPE_PROXIMITY، ولكن في حال توفّره، يجب أن تتوفّر فيه سعة تخزين مؤقت لا تقل عن 100 حدث من أحداث المستشعر.

يُرجى العِلم أنّ جميع متطلبات استهلاك الطاقة الواردة في هذا القسم لا تشمل استهلاك الطاقة في معالج التطبيقات. ويشمل ذلك الطاقة التي تستهلكها سلسلة أدوات الاستشعار بأكملها، أي أداة الاستشعار وأي دوائر كهربائية مساعدة وأي نظام مخصّص لمعالجة بيانات أدوات الاستشعار وما إلى ذلك.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية استخدام المستشعر مباشرةً، يجب أن تستوفي ما يلي:

[C-3-1] يجب الإفصاح بشكل صحيح عن إمكانية استخدام أنواع القنوات المباشرة ومستوى معدّلات التقارير المباشرة من خلال واجهتَي برمجة التطبيقات isDirectChannelTypeSupported وgetHighestDirectReportRateLevel.
‫[C-3-2] يجب أن يتوافق مع نوع واحد على الأقل من نوعَي القنوات المباشرة لأدوات الاستشعار لجميع أدوات الاستشعار التي تعلن عن توافقها مع القناة المباشرة لأدوات الاستشعار.
- TYPE_HARDWARE_BUFFER
- TYPE_MEMORY_FILE
يجب أن يتيح تسجيل الأحداث من خلال القناة المباشرة لأداة الاستشعار الخاصة بأداة الاستشعار الأساسية (النوع غير المفعِّل) من الأنواع التالية:
- TYPE_ACCELEROMETER
- TYPE_ACCELEROMETER_UNCALIBRATED
- TYPE_GYROSCOPE
- TYPE_GYROSCOPE_UNCALIBRATED
- TYPE_MAGNETIC_FIELD
- TYPE_MAGNETIC_FIELD_UNCALIBRATED

‫7.3.10. أجهزة استشعار المقاييس الحيوية

للحصول على معلومات أساسية إضافية حول قياس أمان فتح قفل الجهاز باستخدام المقاييس الحيوية، يُرجى الاطّلاع على مستندات قياس أمان المقاييس الحيوية.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة قفل آمنة، يجب أن تستوفي ما يلي:

يجب أن يتضمّن جهاز استشعار للمقاييس الحيوية

يمكن تصنيف أجهزة استشعار المقاييس الحيوية على أنّها الفئة 3 (قوية سابقًا).

الفئة 2 (المعروفة سابقًا باسم ضعيفة) أو الفئة 1 (المعروفة سابقًا باسم مريحة) استنادًا إلى معدلات قبول عمليات الانتحال والتزوير، وإلى أمان مسار المقاييس الحيوية. يحدّد هذا التصنيف الإمكانات التي يجب أن يتوافق معها مستشعر القياسات الحيوية مع النظام الأساسي والتطبيقات التابعة لجهات خارجية. يجب أن تستوفي أجهزة الاستشعار متطلبات إضافية كما هو موضّح أدناه إذا كانت تريد أن يتم تصنيفها على أنّها الفئة 1 أو الفئة 2 أو الفئة 3. تتضمّن المقاييس الحيوية من الفئة 2 والفئة 3 إمكانات إضافية كما هو موضّح أدناه.

إذا كانت عمليات تنفيذ الأجهزة تتيح استخدام جهاز استشعار المقاييس الحيوية لتطبيقات تابعة لجهات خارجية من خلال android.hardware.biometrics.BiometricManager وandroid.hardware.biometrics.BiometricPrompt وandroid.provider.Settings.ACTION_BIOMETRIC_ENROLL، يجب أن تستوفي ما يلي:

[C-4-1] يجب استيفاء متطلبات الفئة 3 أو الفئة 2 من المقاييس الحيوية على النحو المحدّد في هذا المستند.
[C-4-2] يجب التعرّف على كل اسم مَعلمة محدّد كثابت في فئة المصادِقات والالتزام به وبأي مجموعات منه. في المقابل، يجب ألا يتم قبول أو التعرّف على ثوابت الأعداد الصحيحة التي يتم تمريرها إلى الطريقتَين canAuthenticate(int) وsetAllowedAuthenticators(int) غير تلك الموضّحة كثوابت عامة في Authenticators وأي مجموعات منها.
[C-4-3] يجب تنفيذ الإجراء ACTION_BIOMETRIC_ENROLL على الأجهزة التي تتضمّن مقاييس حيوية من الفئة 3 أو الفئة 2. يجب أن يعرض هذا الإجراء نقاط دخول التسجيل للمقاييس الحيوية من الفئة 3 أو من الفئة 2 فقط.
[C-4-4] يجب أن تسمح التطبيقات بإضافة محتوى مخصّص إلى BiometricPrompt باستخدام تنسيقات عرض المحتوى PromptContentView. يجب عدم توسيع نطاق أشكال عرض المحتوى للسماح بالصور أو الروابط أو المحتوى التفاعلي أو أشكال الوسائط الأخرى التي ليست جزءًا من واجهة برمجة التطبيقات BiometricPrompt. يمكن إجراء تعديلات على الشكل لا تغيّر هذا المحتوى أو تحجبه أو تقطعه (مثل تغيير الموضع والحشو والهوامش والطباعة).

في حال كانت عمليات تنفيذ الأجهزة تتيح استخدام المقاييس الحيوية غير النشطة، يجب أن تستوفي ما يلي:

[C-5-1] يجب أن تتطلّب الخدمة تلقائيًا خطوة تأكيد إضافية (مثل الضغط على زر).
[C-SR-1] يُنصح بشدة بتوفير إعداد يتيح للمستخدمين تجاهل إعدادات التطبيق المفضّلة وطلب خطوة تأكيد مصاحبة دائمًا.
[C-SR-2] يُنصح بشدة بتأمين إجراء التأكيد بحيث لا يمكن أن يتم خداعه من خلال اختراق نظام التشغيل أو النواة. على سبيل المثال، يعني ذلك أنّه يتم توجيه إجراء التأكيد المستند إلى زر فعلي من خلال دبوس إدخال/إخراج للأغراض العامة (GPIO) مخصّص للإدخال فقط في عنصر آمن (SE) لا يمكن تشغيله بأي وسيلة أخرى غير الضغط على زر فعلي.
[C-5-2] يجب أيضًا تنفيذ سير عمل مصادقة ضمنية (بدون خطوة تأكيد) يتوافق مع setConfirmationRequired(boolean)، والذي يمكن للتطبيقات ضبطه لاستخدامه في عمليات تسجيل الدخول.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن عدة مستشعرات للمقاييس الحيوية، يجب أن تستوفي ما يلي:

[C-7-1] يجب أيضًا حظر جميع المقاييس الحيوية الأخرى من فئة مقاييس حيوية أقل عندما تكون إحدى المقاييس الحيوية في حالة حظر (أي تكون المقاييس الحيوية غير مفعّلة إلى أن يفتح المستخدم القفل باستخدام المصادقة الأساسية) أو حظر مؤقت (أي تكون المقاييس الحيوية غير مفعّلة مؤقتًا إلى أن ينتظر المستخدم فترة زمنية) بسبب كثرة المحاولات الفاشلة. في حال الحظر المرتبط بمدة زمنية، يجب أن يكون وقت الانتظار للتحقّق من المقاييس الحيوية هو الحد الأقصى لوقت الانتظار لجميع المقاييس الحيوية في الحظر المرتبط بمدة زمنية.
[C-SR-12] يُنصح بشدة عند قفل المقاييس الحيوية (أي يتم إيقاف المقاييس الحيوية إلى أن يفتح المستخدم القفل باستخدام طريقة المصادقة الأساسية) أو قفلها لفترة زمنية محددة (أي يتم إيقاف المقاييس الحيوية مؤقتًا إلى أن ينتظر المستخدم فترة زمنية) بسبب كثرة المحاولات غير الناجحة، بأن يتم أيضًا قفل جميع المقاييس الحيوية الأخرى من فئة المقاييس الحيوية نفسها. في حال حدوث حظر مؤقت، يُنصح بشدة بأن يكون وقت التراجع للمصادقة باستخدام المقاييس الحيوية هو الحد الأقصى لوقت التراجع لجميع المقاييس الحيوية في الحظر المؤقت.
[C-7-2] يجب أن تطلب المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) من المستخدم لإعادة ضبط عدّاد الحظر الخاص بميزة المصادقة البيومترية التي تم حظرها. قد يُسمح باستخدام المقاييس الحيوية من الفئة 3 لإعادة ضبط عدّاد الحظر لمقياس حيوي محظور من الفئة نفسها أو من فئة أدنى. يجب عدم السماح باستخدام المقاييس الحيوية من الفئة 2 أو الفئة 1 لإكمال عملية إعادة ضبط قفل أي مقاييس حيوية.
[C-SR-3] يُنصح بشدة بأن تتطلّب المصادقة تأكيد مقياس حيوي واحد فقط (على سبيل المثال، إذا كان الجهاز يتضمّن مستشعرات لبصمة الإصبع والوجه، يجب إرسال onAuthenticationSucceeded بعد تأكيد أي منهما).

لكي تسمح عمليات تنفيذ الأجهزة للتطبيقات الخارجية بالوصول إلى مفاتيح KeyStore، يجب أن تستوفي الشروط التالية:

[C-6-1] يجب استيفاء متطلبات الفئة 3 المحدّدة في هذا القسم أدناه.
[C-6-2] يجب عرض المقاييس الحيوية من الفئة 3 فقط عندما تتطلّب المصادقة BIOMETRIC_STRONG، أو عندما يتم استدعاء المصادقة باستخدام CryptoObject.

إذا أرادت عمليات تنفيذ الأجهزة التعامل مع أداة استشعار المقاييس الحيوية على أنّها الفئة 1 (المعروفة سابقًا باسم الراحة)، عليها استيفاء الشروط التالية:

[C-1-1] يجب أن يكون معدّل القبول الخاطئ أقل من %0.002.
[C-1-2] يجب الإفصاح عن أنّ هذا الوضع قد يكون أقل أمانًا من رقم التعريف الشخصي أو النقش أو كلمة المرور القوية، ويجب أن يتم تعداد مخاطر تفعيله بوضوح، إذا كانت معدّلات قبول الانتحال والتزوير أعلى من% 7 وفقًا لما تم قياسه باستخدام بروتوكولات اختبار المقاييس الحيوية في Android.
[C-1-9] يجب أن يطلب الجهاز من المستخدم إدخال طريقة المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) بعد عدم تجاوز عشرين محاولة خاطئة، وألا يقلّ وقت الانتظار عن تسعين ثانية للتحقّق من المقاييس الحيوية، حيث تكون المحاولة الخاطئة هي المحاولة التي تتضمّن جودة التقاط مناسبة (BIOMETRIC_ACQUIRED_GOOD) ولا تتطابق مع المقاييس الحيوية المسجّلة.
[C-SR-4] يُنصح بشدة بتقليل العدد الإجمالي للمحاولات غير الناجحة لإثبات الهوية باستخدام المقاييس الحيوية المحدّدة في [C-1-9] إذا كانت معدلات قبول التزييف وانتحال الهوية أعلى من% 7 وفقًا لما تقيسه بروتوكولات اختبار المقاييس الحيوية في Android.
[C-1-3] يجب وضع حدّ لعدد محاولات التحقّق من الهوية باستخدام المقاييس الحيوية، حيث تكون المحاولة غير الناجحة هي المحاولة التي تتضمّن جودة التقاط كافية (BIOMETRIC_ACQUIRED_GOOD) ولا تتطابق مع المقاييس الحيوية المسجّلة.
[C-SR-5] يُنصح بشدة بوضع حدّ لعدد محاولات التحقّق من الهوية باستخدام المقاييس الحيوية، بحيث لا تتجاوز 5 محاولات خاطئة خلال 30 ثانية على الأقل، وذلك وفقًا للحد الأقصى لعدد المحاولات الخاطئة المحدّد في [C-1-9]، حيث تُعرَّف المحاولة الخاطئة بأنّها محاولة ذات جودة التقاط مناسبة (BIOMETRIC_ACQUIRED_GOOD) لا تتطابق مع مقياس حيوي مسجّل.
[C-SR-6] يُنصح بشدة بأن تتضمّن بيئة التنفيذ الموثوقة جميع منطق الحدّ من معدّل الاستخدام.
[C-1-10] يجب إيقاف المقاييس الحيوية بعد أن يتم تفعيل التراجع عن المصادقة الأساسية لأول مرة كما هو موضح في [C-0-2] من القسم 9.11.
[C-1-11] يجب أن يكون معدّل قبول الانتحال والتزوير أقل من %30، مع (1) معدّل قبول الانتحال والتزوير لأنواع أدوات الهجوم باستخدام العروض التقديمية (PAI) من المستوى A أقل من %30، و(2) معدّل قبول الانتحال والتزوير لأنواع أدوات الهجوم باستخدام العروض التقديمية (PAI) من المستوى B أقل من %40، وذلك وفقًا لما تحدّده بروتوكولات اختبار المقاييس الحيوية في Android.
[C-1-4] يجب منع إضافة مقاييس حيوية جديدة بدون إنشاء سلسلة ثقة أولاً من خلال مطالبة المستخدم بتأكيد بيانات اعتماد الجهاز الحالية أو إضافة بيانات اعتماد جديدة (رقم تعريف شخصي أو نقش أو كلمة مرور) يتم تأمينها بواسطة بيئة التنفيذ الموثوقة (TEE). يوفّر تنفيذ "مشروع Android المفتوح المصدر" الآلية اللازمة في إطار العمل لإجراء ذلك.
[C-1-5] يجب إزالة جميع بيانات المقاييس الحيوية التي يمكن التعرّف منها على المستخدم بشكل كامل عند إزالة حساب المستخدم (بما في ذلك من خلال إعادة الضبط على الإعدادات الأصلية) أو عند إزالة طريقة المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور).
[C-1-6] يجب الالتزام بالعلامة الفردية الخاصة بالمقاييس الحيوية (مثل DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT أو DevicePolicymanager.KEYGUARD_DISABLE_FACE أو DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
[C-1-7] يجب أن يطلب الجهاز من المستخدم إكمال عملية المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) مرة واحدة كل 24 ساعة أو أقل.
[C-1-8] يجب أن تطلب من المستخدم إكمال عملية المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) أو المصادقة باستخدام المقاييس الحيوية من الفئة 3 (قوية) بعد حدوث أيّ مما يلي:
- فترة مهلة عدم النشاط لمدة 4 ساعات
- 3 محاولات فاشلة للمصادقة باستخدام المقاييس الحيوية
- تتم إعادة ضبط مدة المهلة عند عدم النشاط وعدد محاولات المصادقة غير الناجحة بعد أي تأكيد ناجح لبيانات اعتماد الجهاز.
[C-SR-7] يُنصح بشدة باستخدام المنطق الوارد في إطار العمل الذي يوفّره "مشروع مفتوح المصدر لنظام Android" لفرض القيود المحدّدة في [C-1-7] و[C-1-8] على الأجهزة الجديدة.
[C-SR-8] يُنصح بشدة بأن يكون معدّل الرفض الخاطئ أقل من %10، وذلك وفقًا لما يتم قياسه على الجهاز.
[C-SR-9] يُنصح بشدة أن يكون وقت الاستجابة أقل من ثانية واحدة، ويتم قياسه من وقت رصد المقاييس الحيوية إلى وقت فتح قفل الشاشة، وذلك لكل مقياس حيوي تم تسجيله.
[C-1-12] يجب ألا تزيد نسبة قبول عمليات الانتحال والتزوير عن %40 لكل نوع من أدوات الهجوم باستخدام العرض التقديمي (PAI)، وذلك وفقًا لما تحدّده بروتوكولات اختبار المقاييس الحيوية في Android.
[C-SR-13] يُنصح بشدة بأن يكون معدّل قبول عمليات الانتحال والتزوير أقل من %30 لكل نوع من أدوات هجمات الانتحال، وذلك وفقًا لما تحدّده بروتوكولات اختبار المقاييس الحيوية في Android.
[C-SR-8] يُنصح بشدة بأن يكون معدّل الرفض الخاطئ أقل من %10، وذلك وفقًا لما يتم قياسه على الجهاز.
‫[C-1-15] يجب أن تسمح للمستخدمين بإزالة عمليات تسجيل بيانات بيومترية فردية أو متعددة.
‫[C-SR-14] يُنصح بشدة بالإفصاح عن فئة المقاييس الحيوية لأداة استشعار المقاييس الحيوية والمخاطر المرتبطة بتفعيلها.
[C-SR-17] يُنصح بشدة بتنفيذ واجهات AIDL الجديدة (مثل IFace.aidl وIFingerprint.aidl).

إذا أرادت عمليات تنفيذ الأجهزة تصنيف أداة استشعار المقاييس الحيوية على أنّها الفئة 2 (المعروفة سابقًا باسم ضعيفة)، عليها استيفاء الشروط التالية:

[C-2-1] يجب استيفاء جميع متطلبات الفئة 1 أعلاه.
[C-2-2] يجب أن يكون معدّل قبول عمليات الانتحال والتزوير أقل من %20، مع (1) معدّل قبول عمليات الانتحال والتزوير لأنواع أدوات الهجوم باستخدام العروض التقديمية (PAI) من المستوى A أقل من %20، و(2) معدّل قبول عمليات الانتحال والتزوير لأنواع أدوات الهجوم باستخدام العروض التقديمية (PAI) من المستوى B أقل من %30، وذلك وفقًا لما تحدّده بروتوكولات اختبار المقاييس الحيوية في Android.
[C-SR-15] يُنصح بشدة بأن لا تتجاوز نسبة قبول عمليات الانتحال 20% لكل نوع من أدوات الهجوم باستخدام العرض التقديمي (PAI)، وذلك وفقًا لما تحدده بروتوكولات اختبار المقاييس الحيوية في Android.
[C-2-3] يجب إجراء مطابقة المقاييس الحيوية في بيئة تنفيذ معزولة خارج مساحة المستخدم أو النواة في نظام التشغيل Android، مثل بيئة التنفيذ الموثوقة (TEE)، على شريحة تتضمّن قناة آمنة إلى بيئة التنفيذ المعزولة أو على جهاز افتراضي محمي يستوفي المتطلبات الواردة في الفقرة 9.17.
[C-2-4] يجب تشفير جميع البيانات التي يمكن التعرّف منها على الهوية والمصادقة عليها باستخدام التشفير، وذلك لضمان عدم إمكانية الحصول عليها أو قراءتها أو تعديلها خارج بيئة التنفيذ المعزولة أو شريحة إلكترونية تتضمّن قناة آمنة إلى بيئة التنفيذ المعزولة كما هو موضّح في إرشادات التنفيذ على موقع مشروع مفتوح المصدر لنظام Android أو جهاز افتراضي محمي يتحكّم فيه مراقب الأجهزة الافتراضية الذي يستوفي المتطلبات الواردة في الفقرة 9.17.
‫[C-2-5] بالنسبة إلى المقاييس الحيوية المستندة إلى الكاميرا، أثناء إجراء المصادقة أو التسجيل باستخدام المقاييس الحيوية:
- يجب تشغيل الكاميرا في وضع يمنع قراءة أو تعديل إطارات الكاميرا خارج بيئة التنفيذ المعزولة أو شريحة ذات قناة آمنة إلى بيئة التنفيذ المعزولة أو جهاز افتراضي محمي يتحكّم فيه برنامج مراقبة الأجهزة الافتراضية الذي يستوفي المتطلبات الواردة في الفقرة 9.17.
- بالنسبة إلى حلول الكاميرا الواحدة التي تستخدم ألوان الأحمر والأخضر والأزرق، يمكن أن تكون إطارات الكاميرا قابلة للقراءة خارج بيئة التنفيذ المعزولة من أجل إتاحة عمليات مثل المعاينة للتسجيل، ولكن يجب ألا تكون قابلة للتغيير.
[C-2-6] يجب عدم السماح للتطبيقات التابعة لجهات خارجية بالتمييز بين عمليات تسجيل البيانات البيومترية الفردية.
[C-2-7] يجب ألا تسمح بالوصول غير المشفّر إلى بيانات المقاييس الحيوية التي يمكن التعرّف من خلالها على الهوية أو أي بيانات مشتقة منها (مثل عمليات التضمين) إلى معالج التطبيقات خارج سياق بيئة التنفيذ الموثوقة (TEE) أو الجهاز الافتراضي المحمي الذي يتحكّم فيه برنامج Hypervisor الذي يستوفي المتطلبات الواردة في الفقرة 9.17. لا يتم استثناء الأجهزة التي تم إطلاقها على الإصدار 9 من نظام التشغيل Android أو الإصدارات الأقدم من [C-2-7] عند ترقيتها.
[C-2-8] يجب أن يتضمّن الجهاز مسار معالجة آمنًا لا يسمح باختراق نظام التشغيل أو النواة لإدخال البيانات مباشرةً بهدف المصادقة بشكل زائف على أنّها بيانات المستخدم.

ملاحظة: إذا تم إطلاق عمليات تنفيذ الأجهزة على الإصدار 9 من نظام التشغيل Android أو إصدار أقدم ولم يكن بإمكانها استيفاء المتطلبات [C-2-8] من خلال تحديث برنامج النظام، يجوز إعفاؤها من المتطلبات.
[C-SR-10] يُنصح بشدة بتضمين ميزة "رصد النشاط" لجميع أساليب المقاييس الحيوية وميزة "رصد الانتباه" لمقاييس الوجه الحيوية.
[C-2-9] يجب إتاحة أداة استشعار المقاييس الحيوية للتطبيقات التابعة لجهات خارجية.

إذا أرادت عمليات تنفيذ الأجهزة التعامل مع أداة استشعار المقاييس الحيوية على أنّها الفئة 3 (المعروفة سابقًا باسم قوية)، عليها استيفاء ما يلي:

[C-3-1] يجب استيفاء جميع متطلبات الفئة 2 المذكورة أعلاه، باستثناء [C-1-7] و[C-1-8].
[C-3-2] يجب أن يتضمّن تنفيذًا لمخزن مفاتيح مستند إلى الأجهزة.
[C-3-3] يجب ألا يزيد معدّل قبول عمليات الانتحال عن %7، مع استيفاء الشرطَين التاليَين: (1) ألا يزيد معدّل قبول عمليات الانتحال باستخدام أدوات هجوم العرض التقديمي (PAI) من الفئة A عن %7، و(2) ألا يزيد معدّل قبول عمليات الانتحال باستخدام أدوات هجوم العرض التقديمي من الفئة B عن %20، وذلك وفقًا لما تحدّده بروتوكولات اختبار المقاييس الحيوية في Android.
‫[C-3-4] يجب أن تطلب المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) من المستخدم مرة واحدة كل 72 ساعة أو أقل.
[C-3-5] يجب إعادة إنشاء معرّف المصادقة لجميع المقاييس الحيوية من الفئة 3 المتوافقة مع الجهاز في حال إعادة تسجيل أي منها.
[C-3-6] يجب تفعيل مفاتيح مخزن المفاتيح المحمي بالمقاييس الحيوية للتطبيقات التابعة لجهات خارجية.
[C-SR-16] يُنصح بشدة بأن يكون معدّل قبول عمليات الانتحال والتزوير أقل من % 7 لكل نوع من أدوات الهجوم باستخدام العرض التقديمي (PAI)، وذلك وفقًا لما تحدّده بروتوكولات اختبار المقاييس الحيوية في Android.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن أداة استشعار بصمة الإصبع تحت الشاشة (UDFPS)، يجب أن تستوفي ما يلي:

[C-SR-11] يُنصح بشدة بتجنُّب تداخل مساحة اللمس الخاصة بأداة استشعار بصمة الإصبع تحت الشاشة (UDFPS) مع التنقُّل باستخدام ثلاثة أزرار (وهو ما قد يحتاج إليه بعض المستخدمين لأغراض تسهيل الاستخدام).

‫7.3.11. مستشعر الوضع

عمليات تنفيذ الجهاز:

قد تتوافق مع مستشعر الوضع الذي يتيح 6 درجات من الحرية.

إذا كانت عمليات تنفيذ الأجهزة تتيح استخدام أداة استشعار الوضع مع 6 درجات من الحرية، يجب أن تستوفي ما يلي:

[C-1-1] يجب تنفيذ TYPE_POSE_6DOF جهاز استشعار وإعداد تقرير عنه.
[C-1-2] يجب أن تكون أكثر دقة من متّجه الدوران وحده.

‫7.3.12. مستشعر زاوية المفصلة

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع أداة استشعار زاوية المفصلة، يجب أن:

[C-1-1] يجب تنفيذ TYPE_HINGE_ANGLE وإعداد تقرير عنه.
[C-1-2] يجب أن يتيح الجهاز قراءتَين على الأقل بين 0 و360 درجة (بما في ذلك 0 و360 درجة).
[C-1-3] يجب أن تعرض أداة استشعار getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE) wakeup.

‫7.3.13. IEEE 802.1.15.4 (النطاق الفائق العرض)

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية استخدام معيار 802.1.15.4 وتتيح هذه الوظيفة لتطبيق تابع لجهة خارجية، يجب أن تستوفي ما يلي:

[C-1-2] يجب الإبلاغ عن علامة ميزة الأجهزة android.hardware.uwb.
[C-1-3] يجب أن تتوافق مع جميع مجموعات الإعدادات التالية (مجموعات محددة مسبقًا من مَعلمات FIRA UCI) المحددة في تنفيذ AOSP.
- ‫CONFIG_ID_1: إرسال أحادي الاتجاه محدّد من FiRa STATIC STS DS-TWR، الوضع المؤجّل، فاصل زمني للإرسال يبلغ 240 مللي ثانية.
- CONFIG_ID_2: تحديد نطاق STATIC STS DS-TWR من جهاز واحد إلى عدة أجهزة وفقًا لمعيار FiRa، الوضع المؤجّل، فاصل تحديد النطاق 200 مللي ثانية. حالة الاستخدام النموذجية: يتفاعل الهاتف الذكي مع العديد من الأجهزة الذكية.
- ‫CONFIG_ID_3: هي نفسها CONFIG_ID_1، باستثناء أنّه لا يتم تسجيل بيانات زاوية الوصول (AoA).
- ‫CONFIG_ID_4: هي نفسها CONFIG_ID_1، باستثناء أنّه يتم تفعيل وضع أمان P-STS.
- ‫CONFIG_ID_5: هي نفسها CONFIG_ID_2، باستثناء أنّه يتم تفعيل وضع أمان P-STS.
- ‫CONFIG_ID_6: هي نفسها CONFIG_ID_3، ولكن مع تفعيل وضع أمان P-STS.
- ‫CONFIG_ID_7: كما هو الحال في CONFIG_ID_2، باستثناء أنّه يتم تفعيل وضع مفتاح التحكم الفردي في P-STS.
[C-1-4] يجب توفير وسيلة تحكّم للمستخدم تتيح له تبديل حالة تشغيل/إيقاف راديو UWB.
[C-1-5] يجب فرض أن تحمل التطبيقات التي تستخدم موجات الراديو النطاق الفائق العرض الإذن UWB_RANGING (ضمن مجموعة الأذونات NEARBY_DEVICES).

يساعد اجتياز اختبارات المطابقة والشهادات ذات الصلة التي تحدّدها المؤسسات المعيارية، بما في ذلك FIRA وCCC وCSA، في ضمان عمل معيار 802.1.15.4 بشكل صحيح.

‫7.3.14. أجهزة الاستشعار المخصّصة

للمساعدة في توفير تجربة مميّزة، قد تتضمّن عمليات تنفيذ الأجهزة مستشعرات إضافية لا يشملها نظاما التشغيل Android أو Wear OS، ويمكن للتطبيقات المحمَّلة مسبقًا الوصول إليها.

بالنسبة إلى أدوات الاستشعار هذه، يكون معرّف أداة الاستشعار:

[C-0-1] يجب أن تكون القيمة أكبر من 65536.

إذا كان المستشعر المخصّص مخصّصًا لأغراض متعلّقة بالصحة أو اللياقة البدنية، يجب أن يستوفي ما يلي:

[C-0-2] يجب أن تكون محمية إما بإذن من المنصة أو بإذن من النظام.

‫7.4 اتصال البيانات

‫7.4.1. الاتصالات الهاتفية

يشير مصطلح "الاتصال الهاتفي" المستخدَم في واجهات برمجة تطبيقات Android وفي هذا المستند تحديدًا إلى الأجهزة المرتبطة بإجراء المكالمات الصوتية وإرسال الرسائل القصيرة، أو إنشاء بيانات الجوّال عبر شبكة جوّال (مثل GSM أو CDMA أو LTE أو NR). يمكن لجهاز يتيح استخدام "الاتصال الهاتفي" أن يقدّم بعضًا من خدمات المكالمات والمراسلة والبيانات أو جميعها بما يتناسب مع المنتج.

يمكن استخدام Android على الأجهزة التي لا تتضمّن أجهزة اتصال هاتفي. وهذا يعني أنّ نظام التشغيل Android متوافق مع الأجهزة غير الهواتف.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن خدمات الهاتف عبر GSM أو CDMA، يجب أن تستوفي ما يلي:

[C-1-1] يجب الإفصاح عن علامة الميزة android.hardware.telephony وعلامات الميزات الفرعية الأخرى وفقًا للتكنولوجيا.
[C-1-2] يجب توفير الدعم الكامل لواجهة برمجة التطبيقات الخاصة بهذه التكنولوجيا.
يجب السماح بجميع أنواع خدمات شبكة الجوّال المتاحة (الجيل الثاني والثالث والرابع والخامس وما إلى ذلك) أثناء مكالمات الطوارئ (بغض النظر عن أنواع الشبكات التي تم ضبطها من خلال SetAllowedNetworkTypeBitmap()).

إذا لم تتضمّن عمليات تنفيذ الأجهزة أجهزة اتصال هاتفي، يجب أن:

[C-2-1] يجب تنفيذ واجهات برمجة التطبيقات الكاملة كعمليات غير فعّالة.

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع بطاقات eUICC أو شرائح eSIM/شرائح SIM المضمّنة وتتضمّن آلية خاصة لإتاحة وظائف شريحة eSIM للمطوّرين التابعين لجهات خارجية، يجب أن تستوفي ما يلي:

[C-3-1] يجب الإفصاح عن android.hardware.telephony.euicc علامة الميزة.

إذا لم تضبط عمليات تنفيذ الأجهزة سمة النظام ro.telephony.iwlan_operation_mode على legacy، فإنّها:

[C-4-1] يجب عدم إرسال NETWORK_TYPE_IWLAN عبر NetworkRegistrationInfo#getAccessNetworkTechnology() عندما يتم إرسال NetworkRegistrationInfo#getTransportType() على أنّه TRANSPORT_TYPE_WWAN لنسخة NetworkRegistrationInfo نفسها.

إذا كانت عمليات تنفيذ الأجهزة تتيح عملية تسجيل واحدة في نظام IP Multimedia Subsystem (IMS) لكل من ميزات خدمة الاتصالات الهاتفية عبر الوسائط المتعددة (MMTEL) وخدمة الاتصالات التفاعلية (RCS)، وكان من المتوقّع أن تستوفي متطلبات مشغّل شبكة الجوّال بشأن استخدام عملية تسجيل واحدة في نظام IMS لجميع حركة بيانات إشارات IMS، يجب أن تستوفي ما يلي:

[C-5-1] يجب الإعلان عن علامة الميزة android.hardware.telephony.ims وتقديم تنفيذ كامل لواجهة برمجة التطبيقات ImsService API لكل من MMTEL وUser Capability Exchange API.
[C-5-2] يجب الإفصاح عن علامة الميزة android.hardware.telephony.ims.singlereg وتوفير عملية تنفيذ كاملة لواجهة برمجة التطبيقات SipTransport API وواجهة برمجة التطبيقات GbaService API ومؤشرات الحامل المخصّص باستخدام IRadio 1.6 HAL، وتوفير الخدمة من خلال خادم الإعداد التلقائي (ACS) أو آلية أخرى خاصة لتوفير الخدمة باستخدام IMS Configuration API.

إذا كانت عمليات تنفيذ الأجهزة تُبلغ عن ميزة "android.hardware.telephony"، فيجب استيفاء ما يلي:

[C-6-1] يجب أن تؤدي SmsManager#sendTextMessage وSmsManager#sendMultipartTextMessage إلى إجراء مكالمات مقابلة إلى CarrierMessagingService لتوفير وظيفة المراسلة النصية. يجب أن يؤدي استخدام SmsManager#sendMultimediaMessage وSmsManager#downloadMultimediaMessage إلى إجراء مكالمات مماثلة إلى CarrierMessagingService لتوفير وظائف رسائل الوسائط المتعددة.
[C-6-2] يجب أن يستخدم التطبيق المحدّد من خلال android.provider.Telephony.Sms#getDefaultSmsPackage واجهات برمجة التطبيقات SmsManager عند إرسال رسائل SMS وMMS واستلامها. يستوفي تنفيذ AOSP المرجعي في packages/apps/Messaging هذا الشرط.
[C-6-3] يجب أن يتيح التطبيق الذي يستجيب إلى Intent#ACTION_DIAL إدخال رموز طلب عشوائية بالتنسيق *#*#CODE#*#* وأن يؤدي إلى إطلاق بث TelephonyManager#ACTION_SECRET_CODE مطابق.
[C-6-4] يجب أن يستخدم التطبيق الذي يستجيب لطلب Intent#ACTION_DIAL VoicemailContract.Voicemails#TRANSCRIPTION لعرض نص البريد الصوتي المرئي للمستخدمين إذا كان يتيح تحويل البريد الصوتي المرئي إلى نص.
[C-6-5] يجب عرض جميع SubscriptionInfo التي تتضمّن معرّفات UUID للمجموعة المكافئة كاشتراك واحد في جميع عناصر واجهة المستخدم الظاهرة للمستخدمين والتي تعرض معلومات شريحة SIM وتتيح التحكّم فيها. وتشمل الأمثلة على هذه الميزات واجهات الإعدادات التي تتطابق مع Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS أو EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS.
[C-6-6] يجب عدم عرض أو السماح بالتحكّم في أي SubscriptionInfo يتضمّن معرّف UUID للمجموعة غير فارغ وبتًا انتهازيًا في أي عناصر مرئية للمستخدم تتيح ضبط إعدادات شريحة SIM أو التحكّم فيها.

إذا كانت تقارير عمليات تنفيذ الجهاز تتضمّن الميزة android.hardware.telephony وتوفّر شريط حالة النظام، يجب استيفاء ما يلي:

[C-7-1] يجب اختيار اشتراك نشط تمثيلي لمعرّف UUID لمجموعة معيّن لعرضه للمستخدم في أي أدوات توفّر معلومات عن حالة شريحة SIM. وتشمل الأمثلة على هذه العناصر رمز إشارة شبكة الجوّال في شريط الحالة أو مربّع الإعدادات السريعة.
[C-SR-1] يُنصح بشدة باختيار الاشتراك التمثيلي ليكون اشتراك البيانات النشط ما لم يكن الجهاز في مكالمة صوتية، وفي هذه الحالة يُنصح بشدة بأن يكون الاشتراك التمثيلي هو اشتراك الصوت النشط.

إذا كانت عمليات تنفيذ الأجهزة تُبلغ عن ميزة "android.hardware.telephony"، فيجب استيفاء ما يلي:

[C-6-7] يجب أن يكون الجهاز قادرًا على فتح الحد الأقصى لعدد القنوات المنطقية (20 قناة إجمالاً) واستخدامها في الوقت نفسه لكل بطاقة UICC وفقًا للمواصفة الفنية ETSI TS 102 221.
[C-6-8] يجب عدم تطبيق أي من السلوكيات التالية على تطبيقات مشغّلي شبكات الجوّال النشطة (على النحو المحدّد في TelephonyManager#getCarrierServicePackageName) تلقائيًا أو بدون تأكيد صريح من المستخدم:
- إبطال إذن الوصول إلى الشبكة أو وضع حدود له
- إبطال الأذونات
- تقييد تنفيذ التطبيقات في الخلفية أو المقدّمة بما يتجاوز ميزات إدارة الطاقة الحالية المضمّنة في مشروع Android مفتوح المصدر (AOSP)
- إيقاف التطبيق أو إلغاء تثبيته

إذا كانت عمليات تنفيذ الجهاز تعرض الميزة android.hardware.telephony وتم إيقاف جميع الاشتراكات غير المؤقتة النشطة التي تشترك في رقم تعريف فريد عالمي للمجموعة، أو تمت إزالتها فعليًا من الجهاز، أو تم وضع علامة "مؤقتة" عليها، فإنّ الجهاز:

[C-8-1] يجب إيقاف جميع الاشتراكات الانتهازية النشطة المتبقية في المجموعة نفسها تلقائيًا.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن خدمة GSM الهاتفية ولكن ليس خدمة CDMA الهاتفية، يجب أن:

[C-9-1] يجب عدم تعريف PackageManager#FEATURE_TELEPHONY_CDMA.
[C-9-2] يجب عرض IllegalArgumentException عند محاولة ضبط أي أنواع شبكات 3GPP2 في أقنعة بتات نوع الشبكة المفضّل أو المسموح به.
[C-9-3] يجب أن تعرض الدالة TelephonyManager#getMeid سلسلة فارغة.

إذا كانت عمليات تنفيذ الأجهزة تتيح استخدام بطاقات eUICC مع منافذ وملفات شخصية متعددة، يجب أن تستوفي ما يلي:

[C-10-1] يجب الإفصاح عن علامة الميزة android.hardware.telephony.euicc.mep.

في حال كانت عمليات تنفيذ الأجهزة تتيح الاتصال بشبكة بيانات الجوّال، يجب أن:

[C-SR-11] يُنصح بشدة بتضمين android.hardware.telephony.data في البيان.

إذا كان تقرير عمليات تنفيذ الأجهزة android.hardware.telephony.data، يعني ذلك ما يلي:

[C-12-1] يجب أن يتيح الجهاز إجراء اتصالَين متزامنين على الأقل بشبكة بيانات الجوّال، مثل سياقات PDP واتصالات PDN واتصالات DN.

7.4.1.1. التوافق مع ميزة حظر الأرقام

في حال تضمين عمليات تنفيذ الأجهزة ميزة android.hardware.telephony.calling، يجب أن تستوفي ما يلي:

[C-1-1] يجب أن يتضمّن دعمًا لحظر الأرقام
[C-1-2] يجب تنفيذ BlockedNumberContract والواجهة المقابلة لبرمجة التطبيقات بالكامل على النحو الموضّح في مستندات حزمة تطوير البرامج.
[C-1-3] يجب حظر جميع المكالمات والرسائل الواردة من رقم هاتف في BlockedNumberProvider بدون أي تفاعل مع التطبيقات. الاستثناء الوحيد هو عندما يتم رفع الحظر مؤقتًا كما هو موضح في مستندات حزمة SDK.
[C-1-4] يجب الكتابة إلى مقدّم سجلّ المكالمات على النظام الأساسي لمكالمة محظورة، ويجب فلترة المكالمات التي تتضمّن BLOCKED_TYPE من عرض سجلّ المكالمات التلقائي في تطبيق برنامج الاتصال المثبَّت مسبقًا.
[C-1-5] يجب عدم إرسال رسالة إلى مقدّم خدمة الاتصال الهاتفي بشأن رسالة محظورة.
[C-1-6] يجب تنفيذ واجهة مستخدم لإدارة الأرقام المحظورة، يتم فتحها باستخدام النية التي تعرضها الطريقة TelecomManager.createManageBlockedNumbersIntent().
[C-1-7] يجب ألا تسمح الأجهزة للمستخدمين الثانويين بعرض الأرقام المحظورة أو تعديلها، لأنّ نظام Android الأساسي يفترض أنّ المستخدم الأساسي لديه إمكانية التحكّم الكامل في خدمات الاتصال الهاتفي، وهي مثيل واحد على الجهاز. يجب إخفاء جميع عناصر واجهة المستخدم ذات الصلة بالحظر عن المستخدمين الثانويين، ويجب الالتزام بقائمة المستخدمين المحظورين.
يجب نقل الأرقام المحظورة إلى موفّر الخدمة عند تحديث الجهاز إلى الإصدار 7.0 من نظام التشغيل Android.
يجب توفير وسيلة تحكّم للمستخدم لعرض المكالمات المحظورة في تطبيق الاتصال المثبَّت مسبقًا.

‫7.4.1.2. Telecom API

إذا كانت عمليات تنفيذ الأجهزة تحدّد android.hardware.microphone و android.hardware.audio.output ولم تحدّد android.hardware.type.television، فإنّها:

[C-0-1] يجب الإعلان عن علامة الميزة android.software.telecom.
[C-0-2] يجب تنفيذ إطار عمل الاتصالات.

إذا كان تقرير عمليات تنفيذ الأجهزة android.hardware.telephony.calling، يعني ذلك ما يلي:

[C-1-1] يجب أن تتوافق مع واجهات برمجة التطبيقات ConnectionService الموضّحة في حزمة تطوير البرامج (SDK).
[C-1-2] يجب عرض مكالمة واردة جديدة وتوفير إمكانية للمستخدم لقبول المكالمة الواردة أو رفضها عندما يكون المستخدم في مكالمة جارية تم إجراؤها من خلال تطبيق تابع لجهة خارجية لا يتيح ميزة التعليق المحدّدة عبر CAPABILITY_SUPPORT_HOLD.
[C-1-3] يجب أن يتضمّن التطبيق فئة InCallService.
[C-SR-1] يُنصح بشدة بإشعار المستخدم بأنّ الرد على مكالمة واردة سيؤدي إلى إنهاء المكالمة الجارية.

يتوافق تطبيق AOSP مع هذه المتطلبات من خلال عرض إشعار عائم يُعلم المستخدم بأنّ الرد على مكالمة واردة سيؤدي إلى إنهاء المكالمة الأخرى.
[C-SR-2] يُنصح بشدة بتثبيت تطبيق الاتصال التلقائي مسبقًا والذي يعرض إدخالاً في سجل المكالمات واسم تطبيق تابع لجهة خارجية في سجل المكالمات عندما يضبط التطبيق التابع لجهة خارجية مفتاح EXTRA_LOG_SELF_MANAGED_CALLS الإضافي في PhoneAccount على true.
[C-SR-3] يُنصَح بشدة بمعالجة أحداث KEYCODE_MEDIA_PLAY_PAUSE وKEYCODE_HEADSETHOOK الخاصة بسماعة الرأس الصوتية لواجهات برمجة التطبيقات android.telecom على النحو التالي:
- Call Connection.onDisconnect() عند رصد ضغطة قصيرة على حدث رئيسي أثناء مكالمة جارية.
- يتم استدعاء Connection.onAnswer() عند رصد ضغطة قصيرة على حدث المفتاح أثناء مكالمة واردة.
- يتم استدعاء Connection.onReject() عند رصد ضغطة مع الاستمرار على حدث رئيسي أثناء مكالمة واردة.
- تبديل حالة كتم صوت CallAudioState

7.4.1.3. تخفيف حِمل رسالة التحقّق من الاتصال NAT-T على شبكة الجوّال

عمليات تنفيذ الجهاز:

يجب أن تتضمّن إمكانية تخفيف الحِمل لرسالة تحقّق من الاتصال بالشبكة الخلوية.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية تخفيف الحِمل لميزة "رسالة تحقّق من الاتصال" عبر شبكة الجوّال وتتيح هذه الوظيفة للتطبيقات الخارجية، يجب أن:

‫[C-1-1] يجب أن تتوافق مع واجهة برمجة التطبيقات SocketKeepAlive.
‫[C-1-2] يجب أن يتيح الجهاز فتح خانة واحدة على الأقل لإبقاء الاتصال نشطًا بشكل متزامن عبر شبكة الجوّال.
[C-1-3] يجب أن يتيح أكبر عدد ممكن من خانات رسائل التحقّق من الاتصال الخلوي المتزامنة التي يتيحها Cellular Radio HAL.
[C-SR-1] يُنصح بشدة بتوفير ثلاث خانات على الأقل لإبقاء الاتصال نشطًا عبر شبكة الجوّال لكل مثيل راديو.

إذا لم تتضمّن عمليات تنفيذ الأجهزة إمكانية إيقاف ميزة "إبقاء الاتصال نشطًا" عبر شبكة الجوّال، يجب أن:

[C-2-1] يجب أن تعرض القيمة ERROR_UNSUPPORTED.

‫7.4.2. معيار IEEE 802.11 (لشبكات Wi-Fi)

عمليات تنفيذ الجهاز:

يجب أن يتضمّن دعمًا لشكل واحد أو أكثر من أشكال 802.11.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية استخدام معيار 802.11 وتتيح هذه الوظيفة لتطبيق تابع لجهة خارجية، يجب أن تستوفي ما يلي:

[C-1-1] يجب تنفيذ واجهة برمجة تطبيقات Android المقابلة.
[C-1-2] يجب الإبلاغ عن علامة ميزة الأجهزة android.hardware.wifi.
[C-1-3] يجب تنفيذ واجهة برمجة التطبيقات للبث المتعدد على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK).
[C-1-4] يجب أن يتيح الجهاز استخدام نظام أسماء النطاقات ذي البث المتعدد (mDNS) ويجب ألا يصفّي حِزم mDNS (224.0.0.251 أو ff02::fb) في أي وقت أثناء التشغيل، بما في ذلك عندما تكون الشاشة غير نشطة، ما لم يكن قفل البث المتعدد غير مفعّل ويتم تصفية الحِزم بواسطة "تصفية حِزم التطبيقات" (APF). ولا يُشترط أن تستوفي الحِزم أي عمليات mDNS تطلبها التطبيقات حاليًا من خلال واجهات برمجة التطبيقات NsdManager. ومع ذلك، يجوز للجهاز فلترة حِزم mDNS إذا كان ذلك ضروريًا للبقاء ضمن نطاقات استهلاك الطاقة التي تتطلّبها المتطلبات التنظيمية السارية في السوق المستهدَف.
[C-1-5] يجب عدم اعتبار طلب استدعاء طريقة واجهة برمجة التطبيقات WifiManager.enableNetwork() مؤشرًا كافيًا لتبديل Network النشط حاليًا والذي يتم استخدامه تلقائيًا في زيارات التطبيق ويتم عرضه من خلال طرق واجهة برمجة التطبيقات ConnectivityManager مثل getActiveNetwork وregisterDefaultNetworkCallback. بمعنى آخر، يجوز لهم إيقاف إمكانية الوصول إلى الإنترنت التي يوفّرها أي مزوّد شبكة آخر (مثل بيانات الجوّال) فقط إذا تمكّنوا من إثبات أنّ شبكة Wi-Fi توفّر إمكانية الوصول إلى الإنترنت.
[C-1-6] يُنصح بشدة بأن يتم، عند استدعاء طريقة واجهة برمجة التطبيقات ConnectivityManager.reportNetworkConnectivity()، إعادة تقييم إمكانية الوصول إلى الإنترنت على Network، وبعد أن يحدّد التقييم أنّ Network الحالي لم يعُد يوفّر إمكانية الوصول إلى الإنترنت، يتم التبديل إلى أي شبكة أخرى متاحة (مثل بيانات الجوّال) توفّر إمكانية الوصول إلى الإنترنت.
[C-1-7] يجب أن يتم اختيار عنوان MAC المصدر ورقم التسلسل لإطارات طلب الفحص بشكل عشوائي، مرة واحدة في بداية كل عملية فحص، عندما يكون الجهاز غير متصل.
‫[C-1-8] يجب استخدام عنوان MAC واحد متسق (يجب عدم تغيير عنوان MAC بشكل عشوائي في منتصف عملية البحث).
‫[C-1-9] يجب تكرار رقم تسلسل طلبات البحث كالمعتاد (بالترتيب) بين طلبات البحث في عملية الفحص.
[C-1-10] يجب أن يتم اختيار رقم تسلسل طلب الفحص عشوائيًا بين آخر طلب فحص لعملية مسح وأول طلب فحص لعملية المسح التالية.
[C-SR-1] يُنصح بشدة بتوزيع عنوان MAC المصدر المستخدَم بشكل عشوائي في جميع عمليات التواصل بين الأجهزة الطرفية ونقطة الوصول أثناء الربط وبعده.
- يجب أن يستخدم الجهاز عنوان MAC عشوائيًا مختلفًا لكل SSID (اسم نطاق مؤهّل بالكامل لشبكة Passpoint) يتواصل معه.
- يجب أن يوفّر الجهاز للمستخدم خيارًا للتحكّم في العشوائية لكل معرّف SSID (اسم المجال المؤهّل بالكامل لشبكة Passpoint) مع خيارات غير عشوائية وعشوائية، ويجب ضبط الوضع التلقائي لعمليات ضبط شبكة Wi-Fi الجديدة على أن تكون عشوائية.
[C-SR-2] يُنصح بشدة باستخدام معرّف BSSID عشوائي لأي نقطة وصول يتم إنشاؤها.
- يجب أن يكون عنوان MAC عشوائيًا ويتم الاحتفاظ به لكل SSID يستخدمه نقطة الوصول.
- قد يوفّر الجهاز للمستخدم خيارًا لإيقاف هذه الميزة. في حال توفّر خيار من هذا النوع، يجب تفعيل العشوائية تلقائيًا.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة وضع توفير الطاقة في شبكة Wi-Fi على النحو المحدّد في معيار IEEE 802.11، يجب أن تستوفي ما يلي:

يجب إيقاف وضع توفير الطاقة في شبكة Wi-Fi عندما يحصل تطبيق على قفل WIFI_MODE_FULL_HIGH_PERF أو قفل WIFI_MODE_FULL_LOW_LATENCY عبر واجهات برمجة التطبيقات WifiManager.createWifiLock() وWifiManager.WifiLock.acquire() ويكون القفل نشطًا.
‫[C-3-2] يجب أن يكون متوسط وقت الاستجابة لرحلة الذهاب والعودة بين الجهاز ونقطة وصول أثناء وضع قفل Wi-Fi ذي وقت الاستجابة المنخفض (WIFI_MODE_FULL_LOW_LATENCY) أقل من وقت الاستجابة أثناء وضع قفل Wi-Fi ذي الأداء العالي (WIFI_MODE_FULL_HIGH_PERF).
[C-SR-3] يُنصح بشدة بتقليل وقت استجابة الإرسال والاستقبال عبر شبكة Wi-Fi عندما يتم الحصول على قفل وقت الاستجابة المنخفض (WIFI_MODE_FULL_LOW_LATENCY) ويصبح ساريًا.

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع شبكة Wi-Fi وتستخدمها للبحث عن الموقع الجغرافي، عليها استيفاء ما يلي:

[C-2-1] يجب توفير وسيلة تتيح للمستخدم تفعيل/إيقاف قراءة القيمة من خلال طريقة WifiManager.isScanAlwaysAvailable في واجهة برمجة التطبيقات.

‫7.4.2.1. اتصال Wi-Fi مباشر

عمليات تنفيذ الجهاز:

يجب أن يتضمّن دعمًا لتقنية اتصال Wi-Fi مباشر (شبكة Wi-Fi من جهاز إلى جهاز).

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية استخدام اتصال Wi-Fi مباشر، يجب أن:

[C-1-1] يجب تنفيذ واجهة برمجة التطبيقات المتوافقة مع نظام التشغيل Android على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK).
[C-1-2] يجب الإبلاغ عن ميزة الأجهزة android.hardware.wifi.direct.
[C-1-3] يجب أن يتيح الجهاز التشغيل العادي لشبكة Wi-Fi.
[C-1-4] يجب أن تتوافق مع عمليات Wi-Fi واتصال Wi-Fi مباشر في الوقت نفسه.
[C-SR-1] يُنصح بشدة باختيار عنوان MAC المصدر بشكل عشوائي لجميع اتصالات Wi-Fi مباشر التي يتم إنشاؤها حديثًا.

‫7.4.2.2. إعداد رابط مباشر عبر شبكة Wi-Fi

عمليات تنفيذ الجهاز:

يجب أن تتضمّن دعمًا لإعداد رابط مباشر عبر شبكة Wi-Fi (TDLS) كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة TDLS وتم تفعيل TDLS من خلال واجهة برمجة التطبيقات WiFiManager، فإنّها:

[C-1-1] يجب الإعلان عن إتاحة TDLS من خلال WifiManager.isTdlsSupported.
يجب استخدام TDLS فقط عندما يكون ذلك ممكنًا ومفيدًا.
يجب أن يتضمّن بعض الإرشادات ولا يستخدم TDLS عندما يكون أداؤه أسوأ من المرور عبر نقطة وصول لاسلكية.

‫7.4.2.3. Wi-Fi Aware

عمليات تنفيذ الجهاز:

يجب أن يتضمّن دعمًا لـ Wi-Fi Aware.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة استخدام Wi-Fi Aware وتوفير الوظائف للتطبيقات التابعة لجهات خارجية، يجب أن تستوفي ما يلي:

[C-1-1] يجب تنفيذ واجهات برمجة التطبيقات WifiAwareManager على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK).
[C-1-2] يجب الإفصاح عن علامة الميزة android.hardware.wifi.aware.
‫[C-1-3] يجب أن يتيح الجهاز عمليات Wi-Fi وWi-Fi Aware في الوقت نفسه.
[C-1-4] يجب أن يتم بشكل عشوائي تغيير عنوان واجهة إدارة Wi-Fi Aware كل 30 دقيقة على الأكثر وعندما تكون خدمة Wi-Fi Aware مفعّلة، ما لم تكن عملية تحديد نطاق Aware جارية أو مسار بيانات Aware نشطًا (لا يُتوقّع أن يتم التغيير بشكل عشوائي طالما أنّ مسار البيانات نشط).

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة استخدام Wi-Fi Aware وخدمة "الموقع الجغرافي عبر Wi-Fi" على النحو الموضّح في الفقرة 7.4.2.5 وتتيح هذه الوظائف للتطبيقات التابعة لجهات خارجية، يجب أن تستوفي ما يلي:

[C-2-1] يجب تنفيذ واجهات برمجة التطبيقات التي تتيح البحث عن الأجهزة القريبة: setRangingEnabled وsetMinDistanceMm وsetMaxDistanceMm وonServiceDiscoveredWithinRange.

‫7.4.2.4. Wi-Fi Passpoint

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية استخدام المعيار 802.11 (Wi-Fi)، يجب أن:

يجب أن تتضمّن إمكانية استخدام Wi-Fi Passpoint.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية استخدام Wi-Fi Passpoint، يجب أن تستوفي ما يلي:

[C-1-2] يجب تنفيذ واجهات برمجة التطبيقات ذات الصلة بمعيار Passpoint WifiManager كما هو موضح في مستندات حزمة تطوير البرامج (SDK).
‫[C-1-3] يجب أن يتوافق مع معيار IEEE 802.11u، وتحديدًا ما يتعلق باكتشاف الشبكة واختيارها، مثل خدمة الإعلانات الشاملة (GAS) وبروتوكول طلب شبكة الوصول (ANQP).
[C-1-4] يجب الإفصاح عن علامة الميزة android.hardware.wifi.passpoint.
[C-1-5] يجب اتّباع عملية التنفيذ في مشروع AOSP للعثور على شبكات Passpoint ومطابقتها وربطها.
[C-1-6] يجب أن تتوافق مع المجموعة الفرعية التالية على الأقل من بروتوكولات توفير الأجهزة كما هو محدّد في الإصدار 2 من معيار Passpoint الصادر عن تحالف Wi-Fi: مصادقة EAP-TTLS وSOAP-XML.
‫[C-1-7] يجب معالجة شهادة خادم AAA كما هو موضح في مواصفات Hotspot 2.0 الإصدار 3.
‫[C-1-8] يجب أن يتيح للمستخدم التحكّم في عملية توفير الجهاز من خلال أداة اختيار شبكة Wi-Fi.
‫[C-1-9] يجب الحفاظ على إعدادات Passpoint ثابتة عند إعادة التشغيل.
[C-SR-1] يُنصح بشدة بتوفير ميزة قبول الأحكام والشروط.
[C-SR-2] يُنصح بشدة بتوفير ميزة "معلومات المكان".

في حال توفُّر مفتاح تحكّم عالمي لإيقاف Passpoint، يجب أن تتضمّن عمليات التنفيذ ما يلي:

[C-3-1] يجب تفعيل Passpoint تلقائيًا.

‫7.4.2.5. الموقع الجغرافي عبر شبكة Wi-Fi (المدة بين نقطتَي البداية والنهاية لشبكة Wi-Fi)

عمليات تنفيذ الجهاز:

يجب أن تتضمّن إمكانية استخدام الموقع الجغرافي عبر Wi-Fi.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة ميزة "الموقع الجغرافي عبر شبكة Wi-Fi" وإتاحة الوظيفة للتطبيقات التابعة لجهات خارجية، يجب أن تستوفي ما يلي:

[C-1-1] يجب تنفيذ واجهات برمجة التطبيقات WifiRttManager على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK).
[C-1-2] يجب الإفصاح عن علامة الميزة android.hardware.wifi.rtt.
‫[C-1-3] يجب اختيار عنوان MAC المصدر بشكل عشوائي لكل سلسلة RTT يتم تنفيذها عندما لا تكون واجهة Wi-Fi التي يتم تنفيذ RTT عليها مرتبطة بنقطة وصول.
[C-1-4] يجب أن تكون دقيقة في حدود مترَين عند نطاق ترددي يبلغ 80 ميجاهرتز عند الشريحة المئوية رقم 68 (كما هو محسوب باستخدام دالة التوزيع التراكمي).
[C-SR-1] يُنصح بشدة بالإبلاغ عن الموقع الجغرافي بدقة تصل إلى 1.5 متر عند نطاق ترددي يبلغ 80 ميغاهرتز عند النسبة المئوية الـ 68 (كما هو محسوب باستخدام دالة التوزيع التراكمي).

‫7.4.2.6. تخفيف حِمل رسالة تحقّق من الاتصال لشبكة Wi-Fi

عمليات تنفيذ الجهاز:

يجب أن تتضمّن إمكانية إيقاف تحميل Wi-Fi keepalive.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية إيقاف ميزة "إبقاء Wi-Fi نشطًا" وتتيح هذه الوظيفة للتطبيقات التابعة لجهات خارجية، يجب أن تستوفي ما يلي:

[C-1-1] يجب أن تتوافق مع واجهة برمجة التطبيقات SocketKeepAlive.
‫[C-1-2] يجب أن يتيح الجهاز ثلاث فترات متزامنة على الأقل لإبقاء الاتصال نشطًا عبر شبكة Wi-Fi

إذا لم تتضمّن عمليات تنفيذ الأجهزة إمكانية إيقاف ميزة "إبقاء Wi-Fi نشطًا"، يجب أن:

[C-2-1] يجب أن تعرض ERROR_UNSUPPORTED.

‫7.4.2.7. Wi-Fi Easy Connect (بروتوكول توفير المتطلبات اللازمة للأجهزة)

عمليات تنفيذ الجهاز:

يجب أن تتضمّن دعمًا لميزة Wi-Fi Easy Connect (بروتوكول DPP).

[C-1-1] يجب أن تعرض الدالة WifiManager#isEasyConnectSupported()‎ القيمة true.

‫7.4.2.8. التحقّق من صحة شهادة خادم شبكة Wi-Fi في المؤسسة

في حال عدم التحقّق من صحة شهادة خادم Wi-Fi أو عدم ضبط اسم نطاق خادم Wi-Fi، يجب أن تتضمّن عمليات تنفيذ الأجهزة ما يلي:

[C-SR-1] يُنصح بشدة بعدم توفير خيار للمستخدم لإضافة شبكة Wi-Fi خاصة بالمؤسسة يدويًا في تطبيق "الإعدادات".

‫7.4.2.9. الثقة في أول استخدام (TOFU)

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع ميزة "الوثوق عند الاستخدام لأول مرة" (TOFU) وتسمح للمستخدم بتحديد إعدادات WPA/WPA2/WPA3-Enterprise، يجب أن تستوفي ما يلي:

[C-4-1] يجب توفير خيار للمستخدم لاختيار استخدام TOFU.

‫7.4.2.10. رصد الأجهزة القريبة عبر شبكة Wi-Fi (تحديد المسافة بين الأجهزة القريبة)

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية استخدام ميزة "رصد الأجهزة القريبة عبر شبكة Wi-Fi"، يجب أن تستوفي ما يلي:

[C-1-1] يجب أن تتضمّن دعم رصد الأجهزة القريبة.
[C-1-2] يجب الإفصاح عن علامة الميزة android.hardware.wifi.rtt.
[C-1-3] يجب أن تعرض الطريقة WifiRttManager#getProximityDetectionCharacteristics() قيمة غير فارغة.
[C-1-4] يجب تنفيذ واجهات برمجة التطبيقات الخاصة بميزة WifiRttManager لتحديد المدى بشكل مستمر.
‫[C-1-5] يجب أن تتوافق مع عمليات Wi-Fi و"رصد التقارب عبر Wi-Fi" في الوقت نفسه.
[C-1-6] يجب أن تكون الدقة في حدود مترَين عند نطاق ترددي يبلغ 80 ميغاهرتز عند النسبة المئوية الـ 68 (كما يتم احتسابها باستخدام دالة التوزيع التراكمي).
[C-1-7] يجب إجراء تحديد المدى باستخدام تقنية Proximity Detection (PD) في أعلى نطاق تردد متاح (6 غيغاهرتز أو 5 غيغاهرتز أو 2.4 غيغاهرتز) باستخدام الحد الأقصى لعرض النطاق الترددي المتاح حسب ترتيب الأولوية التالي: 160 ميغاهرتز و80 ميغاهرتز و40 ميغاهرتز و20 ميغاهرتز.
[C-SR-1] يُنصح بشدة بالإبلاغ عن الموقع الجغرافي بدقة ضمن نطاق 1.5 متر عند نطاق ترددي يبلغ 80 ميجاهرتز عند النسبة المئوية الـ 68 (كما هو محسوب باستخدام دالة التوزيع التراكمي).
‫[C-SR-2] يُنصح بشدة بتوفير نطاق 802.11az NTB.

‫7.4.3. بلوتوث

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع ملف Bluetooth Audio، يجب أن:

يجب أن تتوافق مع برامج ترميز الصوت المتقدّمة وبرامج ترميز صوت البلوتوث (مثل LDAC).

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع ملفات تعريف HFP وA2DP وAVRCP، يجب أن:

يجب أن يتيح ربط 5 أجهزة متصلة على الأقل.

إذا كانت عمليات تنفيذ الأجهزة تعرّف ميزة android.hardware.vr.high_performance ، عليها استيفاء ما يلي:

‫[C-1-1] يجب أن يتوافق مع الإصدار 4.2 من البلوتوث ومع ميزة "تمديد طول بيانات البلوتوث منخفض الطاقة" (Bluetooth LE Data Length Extension).

يتضمّن Android إمكانية استخدام البلوتوث والبلوتوث المنخفض الطاقة.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية استخدام البلوتوث وBluetooth Low Energy، يجب أن تستوفي ما يلي:

[C-2-1] يجب الإفصاح عن ميزات النظام الأساسي ذات الصلة (android.hardware.bluetooth وandroid.hardware.bluetooth_le على التوالي) وتنفيذ واجهات برمجة التطبيقات الخاصة بالنظام الأساسي.
يجب تنفيذ ملفات تعريف البلوتوث ذات الصلة، مثل A2DP وAVRCP وOBEX وHFP وما إلى ذلك، حسب ما يناسب الجهاز.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية استخدام البلوتوث المنخفض الطاقة (BLE)، يجب أن تستوفي ما يلي:

[C-3-1] يجب الإفصاح عن ميزة الجهاز android.hardware.bluetooth_le.
[C-3-2] يجب تفعيل واجهات برمجة التطبيقات المستندة إلى GATT (ملف تعريف السمات العامة) الخاصة بتقنية Bluetooth، وذلك على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK) وفي android.bluetooth.
[C-3-3] يجب عرض القيمة الصحيحة لـ BluetoothAdapter.isOffloadedFilteringSupported() للإشارة إلى ما إذا كان قد تم تنفيذ منطق الفلترة لفئات واجهة برمجة التطبيقات ScanFilter.
[C-3-4] يجب الإبلاغ عن القيمة الصحيحة لـ BluetoothAdapter.isMultipleAdvertisementSupported() للإشارة إلى ما إذا كان يتم توفير ميزة "الإعلان عن الطاقة المنخفضة".
[C-3-5] يجب تنفيذ مهلة لعنوان خاص قابل للحل (RPA) لا تزيد عن 15 دقيقة وتغيير العنوان عند انتهاء المهلة لحماية خصوصية المستخدم عندما يستخدم الجهاز تقنية البلوتوث المنخفض الطاقة (BLE) بشكل نشط في البحث أو الإعلان. لمنع الهجمات المستندة إلى التوقيت، يجب أيضًا أن تكون فواصل المهلة عشوائية بين 5 و15 دقيقة.
يجب أن تتيح نقل منطق الفلترة إلى مجموعة شرائح البلوتوث عند تنفيذ ScanFilter API.
يجب أن يتيح نقل عملية المسح الضوئي المجمَّع إلى مجموعة شرائح البلوتوث.
يجب أن يتيح عرض إعلانات متعددة مع 4 مساحات إعلانية على الأقل.

في حال كانت عمليات تنفيذ الأجهزة تتوافق مع تقنية بلوتوث منخفض الطاقة وتستخدمها للبحث عن الموقع الجغرافي، يجب أن تستوفي ما يلي:

[C-4-1] يجب توفير وسيلة تتيح للمستخدم تفعيل/إيقاف قراءة القيمة من خلال System API BluetoothAdapter.isBleScanAlwaysAvailable().

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية استخدام بلوتوث منخفض الطاقة و"الملف الشخصي لسماعات الأذن الطبية"، كما هو موضّح في إمكانية استخدام الصوت في سماعات الأذن الطبية من خلال بلوتوث منخفض الطاقة، يجب أن تستوفي ما يلي:

[C-5-1] يجب عرض true لـ BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة استخدام البلوتوث أو البلوتوث المنخفض الطاقة، يجب أن تستوفي ما يلي:

[C-6-1] يجب حظر الوصول إلى أي بيانات وصفية للبلوتوث (مثل نتائج البحث) يمكن استخدامها لتحديد الموقع الجغرافي للجهاز، ما لم يجتاز التطبيق الذي يطلب الوصول إلى البيانات بنجاح عملية التحقّق من إذن android.permission.ACCESS_FINE_LOCATION استنادًا إلى حالته الحالية في المقدّمة أو الخلفية.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة استخدام البلوتوث أو البلوتوث المنخفض الطاقة، ولم يتضمّن بيان التطبيق إقرارًا من المطوّر بأنّه لا يستمد الموقع الجغرافي من البلوتوث، سيتم تطبيق ما يلي:

[C-6-2] يجب حصر إذن الوصول إلى البلوتوث من خلال android.permission.ACCESS_FINE_LOCATION.

إذا كانت عمليات تنفيذ الأجهزة تعرض true لواجهة برمجة التطبيقات BluetoothAdapter.isLeAudioSupported()، فإنّها:

[C-7-1] يجب أن يتيح استخدام عميل البث الأحادي.
[C-7-2] يجب أن تتوافق مع الطبقة الفيزيائية 2M.
‫[C-7-3] يجب أن يتيح الجهاز استخدام الإعلانات الموسّعة بتقنية Bluetooth منخفضة الطاقة.
‫[C-7-4] يجب أن يتيح الجهاز ربط جهازي CIS على الأقل في مجموعة CIG.
[C-7-5] يجب تفعيل عميل البث الأحادي BAP ومنسّق مجموعة CSIP وخادم MCP ووحدة تحكّم VCP وخادم CCP في الوقت نفسه.
[C-SR-1] يُنصح بشدة بتفعيل عميل البث الأحادي HAP.

إذا كانت عمليات تنفيذ الأجهزة تعرض true لواجهة برمجة التطبيقات BluetoothAdapter.isLeAudioBroadcastSourceSupported()، فإنّها:

[C-8-1] يجب أن تتوافق مع رابطَي BIS على الأقل في BIG.
[C-8-2] يجب تفعيل مصدر بث BAP ومساعد بث BAP في الوقت نفسه.
[C-8-3] يجب أن تتوافق مع الإعلانات الدورية منخفضة الطاقة (LE).

إذا كانت عمليات تنفيذ الأجهزة تعرض true لواجهة برمجة التطبيقات BluetoothAdapter.isLeAudioBroadcastAssistantSupported()، فإنّها:

‫[C-9-1] يجب أن تتوافق مع PAST (نقل مزامنة الإعلانات الدورية).
[C-9-2] يجب أن يتيح الجهاز إعلانات LE الدورية.

إذا كانت عمليات تنفيذ الأجهزة تعرّف FEATURE_BLUETOOTH_LE، فإنّها:

[C-10-1] يجب أن تكون قياسات RSSI ضِمن نطاق ‎+/-9 ديسيبل بالنسبة إلى% 95 من القياسات على مسافة متر واحد من جهاز مرجعي يرسل إشارات عند مستوى ADVERTISE_TX_POWER_HIGH في بيئة خط البصر.
[C-10-2] يجب تضمين تصحيحات Rx/Tx لتقليل الانحرافات لكل قناة بحيث تكون القياسات على كل قناة من القنوات الثلاث، وعلى كل هوائي (في حال استخدام هوائيات متعددة)، في نطاق +/-3 ديسيبل من بعضها البعض بنسبة% 95 من القياسات.

إذا كانت عمليات تنفيذ الأجهزة تعرّف FEATURE_BLUETOOTH_LE_CHANNEL_SOUNDING، فإنّها:

[C-11-1] يجب الإبلاغ عن علامة ميزة الجهاز android.hardware.bluetooth_le.channel_sounding.
[C-11-2] يجب عرض النطاق بدقة في حدود ‎+/- 0.5 متر عند المعدّل المئوي التسعين، وذلك وفقًا لما يتم حسابه باستخدام دالة التوزيع التراكمي، وعلى مسافة متر واحد.

إذا كانت عمليات تنفيذ الأجهزة تعرّف FEATURE_BLUETOOTH_LE، فإنّها:

[C-SR-2] يُنصح بشدة بقياس قيمة الإزاحة في الإشارة المستلَمة وتعويضها لضمان أن يكون متوسط قوة الإشارة المستلَمة (RSSI) عبر البلوتوث المنخفض الطاقة (BLE) هو ‎-60 ديسيبل ±10 ديسيبل على مسافة متر واحد من جهاز مرجعي يرسل الإشارة عند ADVERTISE_TX_POWER_HIGH، مع توجيه الأجهزة بحيث تكون على "مستويات متوازية" وتكون الشاشات متجهة إلى الاتجاه نفسه.
[C-SR-3] يُنصح بشدة بقياس إزاحة الإرسال والتعويض عنها لضمان أن يكون متوسط قوة الإشارة المستلَمة (RSSI) عبر البلوتوث منخفض الطاقة (BLE) هو ‎-60 ديسيبل (dBm) +/-10 ديسيبل عند إجراء عملية البحث من جهاز مرجعي موضوع على مسافة متر واحد ويبث عند ADVERTISE_TX_POWER_HIGH، حيث يتم توجيه الأجهزة بحيث تكون على "مستويات متوازية" مع توجيه الشاشات في الاتجاه نفسه.

يُنصح بشدة باتّباع خطوات إعداد القياس المحدّدة في متطلبات معايرة بيانات الحضور.

‫7.4.4. اتصالات المجال القريب

عمليات تنفيذ الجهاز:

يجب أن يتضمّن جهاز إرسال واستقبال وأجهزة ذات صلة بتقنية الاتصال القصير المدى (NFC).
[C-0-1] يجب تنفيذ واجهات برمجة التطبيقات android.nfc.NdefMessage وandroid.nfc.NdefRecord حتى إذا لم تتضمّن دعمًا لاتصال المجال القريب (NFC) أو الإفصاح عن ميزة android.hardware.nfc، لأنّ الفئات تمثّل تنسيقًا لعرض البيانات مستقل عن البروتوكول.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن أجهزة NFC وتخطّط لإتاحتها للتطبيقات التابعة لجهات خارجية، عليها استيفاء ما يلي:

[C-1-1] يجب الإبلاغ عن ميزة android.hardware.nfc من خلال الطريقة android.content.pm.PackageManager.hasSystemFeature().
يجب أن يكون الجهاز قادرًا على قراءة رسائل NDEF وكتابتها باستخدام معايير NFC التالية كما هو موضّح أدناه:
[C-1-2] يجب أن يكون الجهاز قادرًا على العمل كقارئ/كاتب NFC Forum (على النحو المحدّد في المواصفات الفنية NFCForum-TS-DigitalProtocol-1.0 الصادرة عن NFC Forum) من خلال معايير NFC التالية:
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NfcF (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- أنواع علامات NFC Forum‏ 2 و3 و4 و5 (المحدّدة من قِبل NFC Forum)
[C-SR-1] يُنصح بشدة أن يكون الجهاز قادرًا على قراءة رسائل NDEF وكتابتها، بالإضافة إلى البيانات الأولية، وذلك باستخدام معايير NFC التالية. يُرجى العِلم أنّه على الرغم من أنّ معايير NFC مُحدّدة على أنّها يُنصَح بها بشدة، من المخطّط أن يتم تغييرها إلى معايير إلزامية في تعريف التوافق لإصدار مستقبلي. هذه المعايير اختيارية في هذا الإصدار، ولكن سيتم فرضها في الإصدارات المستقبلية. ننصح بشدة الأجهزة الحالية والجديدة التي تعمل بهذا الإصدار من Android باستيفاء هذه المتطلبات الآن حتى تتمكّن من الترقية إلى إصدارات المنصة المستقبلية.
[C-1-13] يجب إجراء عملية بحث عن جميع التقنيات المتوافقة أثناء تفعيل وضع البحث عن أجهزة NFC.
يجب أن يكون الجهاز في وضع رصد NFC أثناء تنشيطه مع تفعيل الشاشة وفتح قفلها.
يجب أن يكون الجهاز قادرًا على قراءة الرمز الشريطي وعنوان URL (في حال ترميزه) الخاصين بمنتجات Thinfilm NFC Barcode.

يُرجى العِلم أنّ الروابط المتاحة للجميع غير متوفّرة لمواصفات JIS وISO وNFC Forum المذكورة أعلاه.

يتوافق نظام التشغيل Android مع وضع وظيفة محاكاة البطاقة المُضيفة (HCE) عبر تقنية NFC.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مجموعة شرائح وحدة التحكّم في NFC التي تتيح HCE (لبروتوكول NfcA و/أو NfcB) وتتيح توجيه معرّف التطبيق (AID)، فإنّها:

[C-2-1] يجب عرض قيمة ثابتة للميزة android.hardware.nfc.hce.
[C-2-2] يجب أن تتوافق مع واجهات برمجة التطبيقات NFC HCE على النحو المحدّد في حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مجموعة شرائح خاصة بوحدة التحكّم في NFC تتوافق مع HCE لبروتوكول NfcF، وتنفّذ الميزة للتطبيقات التابعة لجهات خارجية، فإنّها:

[C-3-1] يجب عرض قيمة ثابتة للميزة android.hardware.nfc.hcef.
[C-3-2] يجب تنفيذ واجهات برمجة التطبيقات لمحاكاة بطاقة NFC-F على النحو المحدّد في حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة استخدام تقنية NFC بشكل عام كما هو موضّح في هذا القسم، وتتيح استخدام تقنيات MIFARE (مثل MIFARE Classic وMIFARE Ultralight وNDEF على MIFARE Classic) في دور القراءة والكتابة، فإنّها:

[C-4-1] يجب تنفيذ واجهات برمجة التطبيقات المتوافقة مع Android على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
[C-4-2] يجب الإبلاغ عن الميزة com.nxp.mifare من خلال الطريقة android.content.pm.PackageManager.hasSystemFeature(). يُرجى العِلم أنّ هذه الميزة ليست من ميزات Android العادية، وبالتالي لا تظهر كثابتة في الفئة android.content.pm.PackageManager.

‫7.4.5. بروتوكولات إنشاء الشبكات وواجهات برمجة التطبيقات

7.4.5.1. الحد الأدنى من إمكانات الشبكة

عمليات تنفيذ الجهاز:

[C-0-1] يجب أن يتضمّن دعمًا لشكل واحد أو أكثر من أشكال ربط البيانات بالشبكة. على وجه التحديد، يجب أن تتضمّن عمليات تنفيذ الأجهزة إمكانية استخدام معيار واحد على الأقل للبيانات قادر على نقل 200 كيلوبت في الثانية أو أكثر. تشمل الأمثلة على التقنيات التي تستوفي هذا الشرط كلاً من EDGE وHSPA وEV-DO و802.11g وEthernet وBluetooth PAN.
يجب أن يتضمّن أيضًا إمكانية استخدام معيار واحد على الأقل من معايير البيانات اللاسلكية الشائعة، مثل 802.11 (Wi-Fi)، عندما يكون معيار الشبكات المادية (مثل Ethernet) هو اتصال البيانات الأساسي.
يمكن تنفيذ أكثر من شكل واحد من أشكال ربط البيانات.

‫7.4.5.2. ‫IPv6

عمليات تنفيذ الجهاز:

[C-0-2] يجب أن يتضمّن الجهاز حزمة شبكة IPv6 وأن يتيح الاتصال عبر IPv6 باستخدام واجهات برمجة التطبيقات المُدارة، مثل java.net.Socket وjava.net.URLConnection، بالإضافة إلى واجهات برمجة التطبيقات الأصلية، مثل مقابس AF_INET6.
[C-0-3] يجب تفعيل بروتوكول IPv6 تلقائيًا.
يجب التأكّد من أنّ الاتصال عبر IPv6 موثوق به مثل IPv4، على سبيل المثال:
[C-0-4] يجب الحفاظ على إمكانية الاتصال ببروتوكول IPv6 في وضع "السكون".
[C-0-5] يجب ألا يؤدي الحدّ من المعدّل إلى فقدان الجهاز إمكانية الاتصال عبر الإصدار السادس من بروتوكول الإنترنت (IPv6) على أي شبكة متوافقة مع IPv6 تستخدم مدة صلاحية إعلانات الموجه (RA) لا تقل عن 180 ثانية.
[C-0-6] يجب توفير اتصال مباشر بشبكة IPv6 لتطبيقات الجهات الخارجية عند الاتصال بشبكة IPv6، بدون أي شكل من أشكال ترجمة العناوين أو المنافذ على الجهاز. يجب أن تعرض كل من واجهات برمجة التطبيقات المُدارة، مثل Socket#getLocalAddress أو Socket#getLocalPort، وواجهات برمجة التطبيقات الخاصة بحزمة تطوير البرامج الأصلية (NDK)، مثل getsockname() أو IPV6_PKTINFO، عنوان IP والمنفذ المستخدَمَين فعليًا لإرسال الحِزم واستلامها على الشبكة، واللذين يظهران كعنوان IP ومنفذ المصدر لخوادم الإنترنت (الويب).

يعتمد مستوى توافق IPv6 المطلوب على نوع الشبكة، كما هو موضّح في المتطلبات التالية.

إذا كانت عمليات تنفيذ الأجهزة تتيح شبكة Wi-Fi، يجب أن تستوفي ما يلي:

‫[C-1-1] يجب أن يتيح الجهاز التشغيل المزدوج والتشغيل عبر IPv6 فقط على شبكة Wi-Fi.

في حال توفير عمليات تنفيذ الأجهزة لشبكة إيثرنت، يجب أن تتضمّن ما يلي:

‫[C-2-1] يجب أن يتيح الجهاز التشغيل المزدوج والتشغيل باستخدام IPv6 فقط على شبكة Ethernet.

في حال توفُّر بيانات شبكة الجوّال في عمليات تنفيذ الأجهزة، يجب أن:

[C-3-1] يجب أن يتيح الجهاز تشغيل IPv6 (شبكة IPv6 فقط وربما شبكة مزدوجة) على شبكة الجوّال.

إذا كانت عمليات تنفيذ الأجهزة تتيح استخدام أكثر من نوع شبكة واحد (مثل شبكة Wi-Fi وبيانات الجوّال)، يجب أن تستوفي ما يلي:

[C-4-1] يجب استيفاء المتطلبات المذكورة أعلاه في الوقت نفسه على كل شبكة عندما يكون الجهاز متصلاً في الوقت نفسه بأكثر من نوع شبكة واحد.

7.4.5.3. المداخل المشروط الوصول إليها

يشير المدخل المشروط الوصول إليه إلى شبكة تتطلّب تسجيل الدخول من أجل الوصول إلى الإنترنت.

إذا كانت عمليات تنفيذ الأجهزة توفّر تنفيذًا كاملاً لـ android.webkit.Webview API، يجب أن تستوفي ما يلي:

[C-1-1] يجب توفير تطبيق بوابة أسيرة للتعامل مع الغرض ACTION_CAPTIVE_PORTAL_SIGN_IN وعرض صفحة تسجيل الدخول إلى البوابة الأسيرة، وذلك عن طريق إرسال هذا الغرض، عند استدعاء System API ConnectivityManager#startCaptivePortalApp(Network, Bundle).
[C-1-2] يجب أن يتم رصد المدخل المشروط الوصول إليه وإتاحة تسجيل الدخول من خلال تطبيق المدخل المشروط الوصول إليه عندما يكون الجهاز متصلاً بأي نوع من الشبكات، بما في ذلك شبكة الجوّال أو شبكة Wi-Fi أو شبكة Ethernet أو البلوتوث.
[C-1-3] يجب أن يتيح تسجيل الدخول إلى مداخل مشروطة الوصول إليها باستخدام نظام أسماء النطاقات بنص غير مرمّز عندما يكون الجهاز مضبوطًا على استخدام وضع التدقيق الصارم لنظام أسماء النطاقات الخاص.
[C-1-4] يجب استخدام نظام أسماء نطاقات مشفّر وفقًا لمستندات حزمة تطوير البرامج (SDK) الخاصة بـ android.net.LinkProperties.getPrivateDnsServerName وandroid.net.LinkProperties.isPrivateDnsActive لجميع حركة بيانات الشبكة التي لا تتواصل بشكل صريح مع مدخل مشروط الوصول إليه.
[C-1-5] يجب التأكّد من أنّه أثناء تسجيل دخول المستخدم إلى بوابة أسيرة، تكون الشبكة التلقائية التي تستخدمها التطبيقات (كما يتم عرضها من خلال ConnectivityManager.getActiveNetwork وConnectivityManager.registerDefaultNetworkCallback والتي تستخدمها تلقائيًا واجهات برمجة تطبيقات Java للشبكات، مثل java.net.Socket، وواجهات برمجة التطبيقات الأصلية، مثل connect()) هي أي شبكة أخرى متاحة توفّر إمكانية الوصول إلى الإنترنت، إذا كانت متاحة.

‫7.4.6. إعدادات المزامنة

عمليات تنفيذ الجهاز:

[C-0-1] يجب أن يكون إعداد المزامنة التلقائية الرئيسي مفعَّلاً تلقائيًا لكي تعرض الطريقة getMasterSyncAutomatically() القيمة "true".

‫7.4.7. توفير البيانات

إذا كانت عمليات تنفيذ الأجهزة تتضمّن اتصالاً محدودًا، تكون على النحو التالي:

[C-SR-1] يُنصح بشدة بتوفير وضع توفير البيانات.

إذا كانت عمليات تنفيذ الأجهزة توفّر وضع "توفير البيانات"، يجب أن:

[C-1-1] يجب أن تتوافق مع جميع واجهات برمجة التطبيقات في فئة ConnectivityManager على النحو الموضّح في مستندات حزمة تطوير البرامج

إذا لم توفّر عمليات تنفيذ الأجهزة وضع "توفير البيانات"، عليها استيفاء ما يلي:

[C-2-1] يجب عرض القيمة RESTRICT_BACKGROUND_STATUS_DISABLED عند إدخال ConnectivityManager.getRestrictBackgroundStatus()
[C-2-2] MUST NOT broadcast ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

‫7.4.8. العناصر الآمنة

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع عناصر آمنة متوافقة مع Open Mobile API وتتيحها للتطبيقات التابعة لجهات خارجية، عليها استيفاء ما يلي:

[C-1-1] يجب إدراج جميع قارئات العناصر الآمنة المتاحة من خلال واجهة برمجة التطبيقات android.se.omapi.SEService.getReaders().
[C-1-2] يجب الإفصاح عن علامات الميزات الصحيحة من خلال android.hardware.se.omapi.uicc للجهاز الذي يحتوي على عناصر آمنة مستندة إلى بطاقة UICC، android.hardware.se.omapi.ese للجهاز الذي يحتوي على عناصر آمنة مستندة إلى eSE، android.hardware.se.omapi.sd للجهاز الذي يحتوي على عناصر آمنة مستندة إلى بطاقة SD.

‫7.4.9. النطاق الفائق العرض (UWB)

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة معيار 802.1.15.4 وتوفير الوظيفة لتطبيق تابع لجهة خارجية، يجب أن تستوفي ما يلي:

[C-1-1] يجب تنفيذ واجهة برمجة تطبيقات Android المقابلة في android.uwb.
[C-1-2] يجب الإبلاغ عن علامة ميزة الأجهزة android.hardware.uwb.
‫[C-1-3] يجب أن تتوافق مع جميع ملفات تعريف النطاق الفائق العرض (UWB) ذات الصلة المحدّدة في تنفيذ Android.
[C-1-4] يجب توفير وسيلة تحكّم للمستخدم تتيح له تبديل حالة تشغيل/إيقاف راديو UWB.
[C-1-5] يجب فرض حصول التطبيقات التي تستخدم تقنية النطاق الفائق العرض (UWB) على إذن UWB_RANGING (ضمن مجموعة أذونات NEARBY_DEVICES).
[C-SR-1] يُنصح بشدة باجتياز اختبارات التوافق والشهادات ذات الصلة التي تحدّدها المؤسسات المعيارية، بما في ذلك FIRA وCCC وCSA.
[C-1-6] يجب التأكّد من أنّ قياسات المسافة تقع ضمن نطاق ‎+/-15 سم بالنسبة إلى% 95 من القياسات في بيئة خط البصر على مسافة متر واحد في غرفة غير عاكسة.
[C-1-7] يجب التأكّد من أنّ متوسط قياسات المسافة على بُعد متر واحد من الجهاز المرجعي يقع ضمن النطاق [0.75 متر، 1.25 متر]، حيث يتم قياس المسافة الحقيقية من الحافة العلوية للجهاز قيد الاختبار.
[C-SR-2] يُنصح بشدة باتّباع خطوات إعداد القياس الموضّحة في متطلبات معايرة الحضور.

‫7.5. كاميرات

إذا كانت عمليات تنفيذ الأجهزة تتضمّن كاميرا واحدة على الأقل، يجب أن تستوفي ما يلي:

[C-1-1] يجب الإفصاح عن علامة الميزة android.hardware.camera.any.
[C-1-2] يجب أن يكون بإمكان التطبيق تخصيص 3 RGBA_8888 صور نقطية في الوقت نفسه بحجم الصور التي تنتجها أداة استشعار الكاميرا ذات أعلى دقة على الجهاز، وذلك أثناء فتح الكاميرا لغرض المعاينة الأساسية والتقاط الصور الثابتة.
[C-1-3] يجب التأكّد من أنّ تطبيق الكاميرا التلقائي المثبَّت مسبقًا الذي يعالج الأهداف MediaStore.ACTION_IMAGE_CAPTURE أو MediaStore.ACTION_IMAGE_CAPTURE_SECURE أو MediaStore.ACTION_VIDEO_CAPTURE هو المسؤول عن إزالة الموقع الجغرافي للمستخدم من البيانات الوصفية للصورة قبل إرسالها إلى التطبيق المستلِم عندما لا يتضمّن التطبيق المستلِم ACCESS_FINE_LOCATION.

[C-1-6] يجب تصنيف كل نوع من أنواع أجهزة الكاميرا باستخدام الحقل CameraCharacteristics.INFO_DEVICE_TYPE على أنّه BUILT_IN أو EXTERNAL أو VIRTUAL. يجب أيضًا تصنيف كل لقطة من مخرجات الكاميرا باستخدام الحقل CaptureResult.INFO_DEVICE_TYPE.
من المهم بشكل خاص التأكّد من تصنيف CaptureResult.INFO_DEVICE_TYPE بشكل صحيح في الحالات التي تتم فيها إعادة ربط معرّف الكاميرا بشكل ديناميكي بمصدر كاميرا مختلف.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن كاميرا واحدة على الأقل، وكان تطبيق الكاميرا المثبَّت مسبقًا يعالج الأهداف MediaStore.ACTION_MOTION_PHOTO_CAPTURE أو MediaStore.ACTION_MOTION_PHOTO_CAPTURE_SECURE، يجب أن:

[C-1-4] يجب التأكّد من أنّه عند التعامل مع هذه الأهداف، يزيل تطبيق الكاميرا المثبَّت مسبقًا الموقع الجغرافي للمستخدم من البيانات الوصفية للصورة قبل إرسالها إلى التطبيقات المستلِمة التي لا تتضمّن ACCESS_FINE_LOCATION.
[C-1-5] يجب التأكّد من أنّ الصورة المتحركة التي تم إرجاعها تستخدم مواصفات تنسيق "الصورة المتحركة" 1.0.

في حال توفُّر إمكانية إخراج HDR 10-bit في عمليات تنفيذ الأجهزة، يجب أن تتضمّن ما يلي:

‫[C-2-1] يجب أن تتوافق جميع أجهزة الكاميرا التي تتيح إخراج 10 بت مع ملف تعريف HLG HDR على الأقل.
‫[C-2-2] يجب أن يتيح الجهاز إخراج بيانات بعمق 10 بت لكل من الكاميرا الخلفية الأساسية أو الكاميرا الأمامية الأساسية.
[C-SR-1] يُنصح بشدة بأن تتوافق الكاميرات الأساسية مع إخراج 10 بت.
[C-2-3] يجب أن تتوافق جميع الكاميرات الفرعية المادية التي يمكنها استخدام BACKWARD_COMPATIBLE ضمن كاميرا منطقية واحدة مع ملفات تعريف HDR نفسها، كما يجب أن تتوافق الكاميرا المنطقية نفسها مع ملفات تعريف HDR نفسها.

بالنسبة إلى أجهزة الكاميرا المنطقية التي تتوافق مع فيديو 10 بت بنطاق عالي الديناميكية (HDR) وتستخدم واجهة برمجة التطبيقات android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO، يجب أن تستوفي ما يلي:

[C-3-1] يجب أن يتيح التبديل بين جميع الكاميرات المادية المتوافقة مع الإصدارات السابقة من خلال عنصر التحكّم CONTROL_ZOOM_RATIO في الكاميرا المنطقية.

‫7.5.1. الكاميرا الخلفية

الكاميرا الخلفية هي كاميرا تواجه العالم وتصوّر المشاهد على الجانب البعيد من الجهاز، مثل الكاميرا التقليدية. وفي الأجهزة المحمولة، تكون الكاميرا الخلفية على جانب الجهاز المقابل للشاشة.

عمليات تنفيذ الجهاز:

يجب أن يتضمّن كاميرا خلفية.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن كاميرا واحدة على الأقل مواجهة للخلف، يجب أن تستوفي ما يلي:

[C-1-1] يجب الإبلاغ عن علامة الميزة android.hardware.camera و android.hardware.camera.any.

~~[C-1-2] يجب أن تبلغ درجة الدقة 2 ميغابكسل على الأقل.~~

يجب أن تتضمّن الكاميرا ميزة التركيز التلقائي للأجهزة أو البرامج (بدون أن يلاحظها برنامج التطبيق).
قد تحتوي على أجهزة تركيز ثابت أو أجهزة EDOF (عُمق مجال موسّع).
قد تتضمّن فلاشًا.

إذا كانت الكاميرا تتضمّن فلاشًا:

[C-2-1] يجب ألا يضيء مصباح الفلاش أثناء تسجيل مثيلandroid.hardware.Camera.PreviewCallback على مساحة عرض لمعاينة الكاميرا، ما لم يفعّل التطبيق الفلاش صراحةً من خلال تفعيل السمتَين FLASH_MODE_AUTO أو FLASH_MODE_ON لكائن Camera.Parameters. يُرجى العِلم أنّ هذا القيد لا ينطبق على تطبيق كاميرا النظام المضمّن في الجهاز، بل ينطبق فقط على التطبيقات التابعة لجهات خارجية التي تستخدم Camera.PreviewCallback.

‫7.5.2. الكاميرا الأمامية

الكاميرا الأمامية هي كاميرا موجّهة نحو المستخدم تُستخدَم عادةً لتصوير المستخدم، مثلاً في مؤتمرات الفيديو والتطبيقات المشابهة. وفي الأجهزة المحمولة، تكون الكاميرا الأمامية على الجانب نفسه من الجهاز الذي تظهر عليه الشاشة.

عمليات تنفيذ الجهاز:

قد تتضمّن كاميرا أمامية.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن كاميرا واحدة على الأقل مواجهة للشاشة، يجب أن تستوفي ما يلي:

[C-1-1] يجب الإبلاغ عن علامة الميزة android.hardware.camera.any و android.hardware.camera.front.
[C-1-2] يجب أن تكون درجة الدقة VGA (640x480 بكسل) على الأقل.
[C-1-3] يجب عدم استخدام الكاميرا الأمامية كإعداد تلقائي لواجهة برمجة التطبيقات الخاصة بالكاميرا، ويجب عدم ضبط واجهة برمجة التطبيقات على اعتبار الكاميرا الأمامية هي الكاميرا الخلفية التلقائية، حتى إذا كانت الكاميرا الوحيدة على الجهاز.
[C-1-4] يجب أن تكون معاينة الكاميرا معكوسة أفقيًا بالنسبة إلى الاتجاه الذي يحدّده التطبيق عندما يطلب التطبيق الحالي صراحةً تدوير شاشة الكاميرا من خلال استدعاء الطريقة android.hardware.Camera.setDisplayOrientation(). في المقابل، يجب أن تكون المعاينة معكوسة على طول المحور الأفقي التلقائي للجهاز عندما لا يطلب التطبيق الحالي بشكل صريح تدوير شاشة الكاميرا من خلال استدعاء الطريقة android.hardware.Camera.setDisplayOrientation().
[C-1-5] يجب عدم عرض صورة ثابتة أو بث فيديو مطابقَين للصورة النهائية التي تم التقاطها والتي تم إرجاعها إلى عمليات رد الاتصال في التطبيق أو حفظها في مساحة تخزين الوسائط.
[C-1-6] يجب أن تعكس الصورة المعروضة في العرض بعد الالتقاط بالطريقة نفسها التي تعكس بها دفق صورة معاينة الكاميرا.
قد تتضمّن الكاميرات الأمامية ميزات (مثل التركيز التلقائي والفلاش وما إلى ذلك) متاحة للكاميرات الخلفية كما هو موضّح في الفقرة 7.5.1.

إذا كانت عمليات تنفيذ الأجهزة قابلة للتدوير من قِبل المستخدم (مثل التدوير تلقائيًا باستخدام مقياس تسارع أو يدويًا من خلال بيانات أدخلها المستخدم):

[C-2-1] يجب أن يتم عكس معاينة الكاميرا أفقيًا بالنسبة إلى اتجاه الجهاز الحالي.

‫7.5.3. الكاميرا الخارجية

الكاميرا الخارجية هي كاميرا يمكن توصيلها أو فصلها فعليًا عن الجهاز في أي وقت، ويمكن توجيهها إلى أي اتجاه، مثل كاميرات USB.

عمليات تنفيذ الجهاز:

قد تتضمّن دعمًا لكاميرا خارجية غير متصلة دائمًا.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية استخدام كاميرا خارجية، يجب أن تتضمّن ما يلي:

[C-1-1] يجب الإفصاح عن علامة ميزة النظام الأساسي android.hardware.camera.external وandroid.hardware camera.any.
[C-1-2] يجب أن يتوافق الجهاز مع فئة فيديو USB (الإصدار 1.0 أو إصدار أحدث) إذا كانت الكاميرا الخارجية تتصل من خلال منفذ مضيف USB.
‫[C-1-3] يجب اجتياز اختبارات CTS للكاميرا باستخدام جهاز كاميرا خارجية فعلية متصل. تتوفّر تفاصيل اختبار مجموعة أدوات اختبار التوافق (CTS) للكاميرا على source.android.com.
يجب أن تتوافق مع عمليات ضغط الفيديو، مثل MJPEG، لتفعيل نقل تدفقات غير مشفّرة عالية الجودة (أي تدفقات صور أولية أو مضغوطة بشكل مستقل).
قد يتيح استخدام كاميرات متعددة.
قد يتيح ترميز الفيديو المستند إلى الكاميرا.

في حال توفّر ترميز الفيديو المستند إلى الكاميرا:

[C-2-1] يجب أن يكون الجهاز قادراً على الوصول إلى بث متزامن غير مشفّر / MJPEG (بدقة QVGA أو أعلى).

7.5.4. سلوك Camera API

يتضمّن Android حزمتَي واجهات برمجة تطبيقات للوصول إلى الكاميرا، وهما واجهة برمجة التطبيقات الأحدث android.hardware.camera2 التي تتيح للتطبيق التحكّم في الكاميرا على مستوى أدنى، بما في ذلك عمليات نقل البيانات الفعّالة بدون نسخ، وعمليات نقل البيانات المتسلسلة أو المتدفقة، وعناصر التحكّم في كل إطار من حيث التعريض والزيادة ومكاسب توازن اللون الأبيض وتحويل الألوان وإزالة التشويش والحدة وغير ذلك.

تم وضع علامة الإيقاف النهائي على حزمة واجهة برمجة التطبيقات القديمة، android.hardware.Camera، في الإصدار 5.0 من نظام التشغيل Android، ولكن من المفترض أن تظل متاحة للتطبيقات. يجب أن تضمن عمليات تنفيذ أجهزة Android استمرار توفّر واجهة برمجة التطبيقات على النحو الموضّح في هذا القسم وفي حزمة تطوير البرامج (SDK) لنظام Android.

يجب أن تتوفّر في كلتا واجهتَي برمجة التطبيقات جميع الميزات المشتركة بين الفئة android.hardware.Camera المتوقّفة نهائيًا والحزمة android.hardware.camera2 الأحدث، وأن تكون الميزات متطابقة من حيث الأداء والجودة. على سبيل المثال، مع الإعدادات المكافئة، يجب أن تكون سرعة التركيز التلقائي ودقته متطابقتَين، ويجب أن تكون جودة الصور الملتقطة هي نفسها. لا يُشترَط أن تتطابق السرعة أو الجودة في الميزات التي تعتمد على الدلالات المختلفة لواجهتَي برمجة التطبيقات، ولكن يجب أن تتطابق بأكبر قدر ممكن.

يجب أن تنفّذ عمليات تنفيذ الأجهزة السلوكيات التالية لواجهات برمجة التطبيقات ذات الصلة بالكاميرا، وذلك لجميع الكاميرات المتاحة. عمليات تنفيذ الجهاز:

[C-0-1] يجب استخدام android.hardware.PixelFormat.YCbCr_420_SP لمعاينة البيانات المقدَّمة إلى عمليات رد الاتصال في التطبيق عندما لم يسبق للتطبيق استدعاء android.hardware.Camera.Parameters.setPreviewFormat(int).
[C-0-2] يجب أن يكون التنسيق NV21 أيضًا عند تسجيل تطبيق مثيلاً android.hardware.Camera.PreviewCallback واستدعاء النظام الطريقة onPreviewFrame() وتنسيق المعاينة YCbCr_420_SP، والبيانات في byte[] التي تم تمريرها إلى onPreviewFrame(). أي أنّ NV21 يجب أن يكون التنسيق التلقائي.
[C-0-3] يجب أن تتوافق الكاميرات الأمامية والخلفية في android.hardware.Camera مع تنسيق YV12 (كما هو موضّح في الثابت android.graphics.ImageFormat.YV12) لمعاينة الكاميرا. (قد يستخدم برنامج ترميز الفيديو والكاميرا أي تنسيق بكسل أصلي، ولكن يجب أن يتوافق الجهاز مع التحويل إلى YV12.)
[C-0-4] يجب أن تتوافق مع تنسيقي android.hardware.ImageFormat.YUV_420_888 وandroid.hardware.ImageFormat.JPEG كناتجَين من خلال واجهة برمجة التطبيقات android.media.ImageReader لأجهزة android.hardware.camera2 التي تعلن عن إمكانية REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE في android.request.availableCapabilities.
[C-0-5] يجب أن يظل الجهاز ينفّذ واجهة برمجة التطبيقات الخاصة بالكاميرا الكاملة المضمّنة في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android، بغض النظر عمّا إذا كان الجهاز يتضمّن ميزة التركيز التلقائي للأجهزة أو إمكانات أخرى. على سبيل المثال، يجب أن تستدعي الكاميرات التي لا تتضمّن ميزة التركيز التلقائي أي مثيلات android.hardware.Camera.AutoFocusCallback مسجّلة (على الرغم من أنّ ذلك لا صلة له بالكاميرا التي لا تتضمّن ميزة التركيز التلقائي). يُرجى العِلم أنّ هذا ينطبق على الكاميرات الأمامية، فعلى سبيل المثال، على الرغم من أنّ معظم الكاميرات الأمامية لا تتوافق مع التركيز التلقائي، يجب أن يتم "تزييف" عمليات معاودة الاتصال لواجهة برمجة التطبيقات كما هو موضّح.
[C-0-6] يجب أن يتعرّف على كل اسم مَعلمة محدّد كثابت وأن يلتزم به في الفئة android.hardware.Camera.Parameters والفئة android.hardware.camera2.CaptureRequest. في المقابل، يجب ألا تنفّذ الأجهزة أو تتعرّف على الثوابت النصية التي يتم تمريرها إلى طريقة android.hardware.Camera.setParameters() بخلاف تلك الموثّقة كثوابت في android.hardware.Camera.Parameters. أي أنّ عمليات تنفيذ الجهاز يجب أن تتوافق مع جميع معلَمات الكاميرا العادية إذا كان الجهاز يتيح ذلك، ويجب ألا تتوافق مع أنواع معلَمات الكاميرا المخصّصة. على سبيل المثال، يجب أن تتوافق عمليات تنفيذ الأجهزة التي تتيح التقاط الصور باستخدام تقنيات التصوير بنطاق عالي الديناميكية (HDR) مع مَعلمة الكاميرا Camera.SCENE_MODE_HDR.
[C-0-7] يجب الإبلاغ عن مستوى التوافق المناسب باستخدام السمة android.info.supportedHardwareLevel كما هو موضّح في حزمة تطوير البرامج (SDK) لنظام التشغيل Android، والإبلاغ عن علامات ميزات إطار العمل المناسبة.
يجب أيضًا أن يوضّح [C-0-8] إمكانات الكاميرا الفردية android.hardware.camera2 من خلال android.request.availableCapabilities السمة ويوضّح علامات الميزات المناسبة، ويجب تحديد علامة الميزة إذا كان أي من أجهزة الكاميرا المرفقة يتوافق مع الميزة.
[C-0-9] يجب أن يبث Camera.ACTION_NEW_PICTURE intent كلما تم التقاط صورة جديدة بالكاميرا وتمت إضافة إدخال الصورة إلى مستودع الوسائط.
[C-0-10] يجب بث الغرض Camera.ACTION_NEW_VIDEO عندما تسجّل الكاميرا فيديو جديدًا وتتم إضافة إدخال الصورة إلى مستودع الوسائط.
[C-0-11] يجب أن تكون جميع الكاميرات التي يمكن الوصول إليها من خلال واجهة برمجة التطبيقات android.hardware.Camera التي تم إيقافها نهائيًا قابلة للوصول أيضًا من خلال واجهة برمجة التطبيقات android.hardware.camera2.
[C-0-12] يجب التأكّد من عدم تعديل مظهر الوجه، بما في ذلك على سبيل المثال لا الحصر، تعديل شكل الوجه أو درجة لون بشرة الوجه أو تنعيم بشرة الوجه لأي واجهة برمجة تطبيقات android.hardware.camera2 أو android.hardware.Camera.
[C-SR-1] بالنسبة إلى الأجهزة التي تتضمّن كاميرات RGB متعددة متجاورة وموجّهة في الاتجاه نفسه، يُنصح بشدة بتوفير جهاز كاميرا منطقي يعرض الإمكانية CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA، ويتألف من جميع كاميرات RGB الموجّهة في هذا الاتجاه كأجهزة فرعية مادية.

إذا كانت عمليات تنفيذ الأجهزة توفّر واجهة برمجة تطبيقات خاصة بالكاميرا لتطبيقات الجهات الخارجية، يجب أن تستوفي ما يلي:

[C-1-1] يجب تنفيذ واجهة برمجة تطبيقات الكاميرا هذه باستخدام واجهة برمجة التطبيقات android.hardware.camera2.
يمكن تقديم علامات المورّدين و/أو الإضافات إلى واجهة برمجة التطبيقات android.hardware.camera2.

إذا كانت عمليات تنفيذ الأجهزة تضبط مسار الكاميرا التابع لجهة خارجية ليكون متوافقًا مع مسار الكاميرا المدمجة للكاميرا الأمامية الأساسية والكاميرا الخلفية الأساسية، عليها اتّباع ما يلي:

[C-2-1] يجب الإعلان عن سمة النظام ro.camera.default_app_social_media_parity_enabled.

‫7.5.5. اتجاه الكاميرا

إذا كانت عمليات تنفيذ الأجهزة تتضمّن كاميرا أمامية أو خلفية، يجب أن تستوفي هذه الكاميرات ما يلي:

[C-1-1] يجب أن يكون اتجاه الكاميرا بحيث يتوافق البُعد الأطول للكاميرا مع البُعد الأطول للشاشة. أي عندما يكون الجهاز في الوضع الأفقي، يجب أن تلتقط الكاميرات الصور في الوضع الأفقي. وينطبق ذلك بغض النظر عن الاتجاه الطبيعي للجهاز، أي أنّه ينطبق على الأجهزة التي يكون اتجاهها الأساسي أفقيًا وكذلك الأجهزة التي يكون اتجاهها الأساسي عموديًا.

يُستثنى من هذا الشرط الأجهزة التي تستوفي أيًا من المعايير التالية:
- يجب أن يتضمّن الجهاز شاشات ذات أشكال متغيرة، مثل الشاشات القابلة للطي أو الشاشات المزودة بمفصلات، وأن ينتقل الجهاز من الوضع العمودي الأساسي إلى الوضع الأفقي الأساسي (أو العكس) عند تغيير حالة الطي أو المفصلة.
- عمليات تنفيذ الأجهزة التي لا يمكن للمستخدم تدويرها، مثل أجهزة السيارات

‫7.6. الذاكرة ومساحة التخزين

‫7.6.1. الحد الأدنى من الذاكرة ومساحة التخزين

عمليات تنفيذ الجهاز:

[C-0-1] يجب أن يتضمّن إدارة التنزيل التي يمكن للتطبيقات استخدامها لتنزيل ملفات البيانات، ويجب أن تكون قادرة على تنزيل ملفات فردية بحجم 100 ميغابايت على الأقل إلى موقع "ذاكرة التخزين المؤقت" التلقائي.

‫7.6.2. مساحة التخزين المشتركة للتطبيقات

عمليات تنفيذ الجهاز:

[C-0-1] يجب توفير مساحة تخزين يمكن للتطبيقات مشاركتها، ويُشار إليها أيضًا باسم "مساحة التخزين الخارجية المشتركة" أو "مساحة التخزين المشتركة للتطبيقات" أو مسار Linux "/sdcard" الذي يتم تركيبها عليه.
[C-0-2] يجب أن يتم ضبطه على وحدة تخزين مشتركة يتم تركيبها تلقائيًا، أي "بدون أي إعدادات إضافية"، بغض النظر عمّا إذا كانت وحدة التخزين مدمجة في أحد مكونات وحدة التخزين الداخلية أو في وسيط تخزين قابل للإزالة (مثل فتحة بطاقة Secure Digital).
[C-0-3] يجب ربط وحدة تخزين التطبيق المشتركة مباشرةً بمسار Linux sdcard أو تضمين رابط رمزي لنظام التشغيل Linux من sdcard إلى نقطة الربط الفعلية.
[C-0-4] يجب تفعيل ميزة "التخزين المحصور" تلقائيًا لجميع التطبيقات التي تستهدف المستوى 29 أو أعلى من واجهة برمجة التطبيقات، باستثناء الحالة التالية:
- عندما يطلب التطبيق إذن android:requestLegacyExternalStorage="true" في البيان.
[C-0-5] يجب إخفاء البيانات الوصفية للموقع الجغرافي، مثل علامات EXIF لنظام تحديد المواقع العالمي (GPS)، المخزَّنة في ملفات الوسائط عند الوصول إلى هذه الملفات من خلال MediaStore، باستثناء الحالات التي يملك فيها التطبيق الذي يجري الاتصال إذن ACCESS_MEDIA_LOCATION.

يمكن أن تستوفي عمليات تنفيذ الأجهزة المتطلبات المذكورة أعلاه باستخدام أي مما يلي:

مساحة تخزين قابلة للإزالة يمكن للمستخدم الوصول إليها، مثل فتحة بطاقة Secure Digital (SD).
جزء من وحدة التخزين الداخلية (غير القابلة للإزالة) كما هو موضّح في "المشروع المفتوح المصدر لنظام Android" ‏ (AOSP)

إذا كانت عمليات تنفيذ الأجهزة تستخدم مساحة تخزين قابلة للإزالة لاستيفاء المتطلبات المذكورة أعلاه، يجب أن تستوفي ما يلي:

[C-1-1] يجب تنفيذ تحذير في واجهة المستخدم على شكل إشعار مؤقت أو نافذة منبثقة لتنبيه المستخدم عندما لا يكون هناك وسيط تخزين مُدرَج في الفتحة.
[C-1-2] يجب أن يتضمّن وسيط تخزين منسَّقًا بتنسيق FAT (مثل بطاقة SD) أو أن يوضّح على العلبة والمواد الأخرى المتوفرة عند الشراء أنّه يجب شراء وسيط التخزين بشكل منفصل.

إذا كانت عمليات تنفيذ الأجهزة تستخدم جزءًا من مساحة التخزين غير القابلة للإزالة لاستيفاء المتطلبات المذكورة أعلاه، يجب أن:

يجب استخدام تطبيق AOSP لميزة "مشاركة التطبيقات مع الفريق الداخلي" في وحدة التخزين.
قد تتم مشاركة مساحة التخزين مع البيانات الخاصة بالتطبيق.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB يتيح وضع الجهاز الطرفي USB، يجب أن تستوفي ما يلي:

[C-3-1] يجب توفير آلية للوصول إلى البيانات في مساحة التخزين المشتركة الخاصة بالتطبيق من جهاز كمبيوتر مضيف.
يجب عرض المحتوى من كلا مسارَي التخزين بشفافية من خلال خدمة "ماسح الوسائط" في Android وandroid.provider.MediaStore.
يمكن استخدام وحدة تخزين USB، ولكن يُفضَّل استخدام بروتوكول نقل الوسائط لتلبية هذا الشرط.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB مع وضع جهاز USB الطرفي وتتوافق مع بروتوكول نقل الوسائط، يجب أن تستوفي ما يلي:

يجب أن يكون متوافقًا مع المرجع المضيف لبروتوكول نقل الوسائط (MTP) على Android، وهو تطبيق "نقل الملفات في Android".
يجب الإبلاغ عن فئة جهاز USB بقيمة 0x00.
يجب أن يتم الإبلاغ عن اسم واجهة USB باسم "MTP".

‫7.6.3. وحدة تخزين قابلة للاستخدام

إذا كان من المتوقّع أن يكون الجهاز جوّالاً بطبيعته على عكس التلفزيون، تكون عمليات تنفيذ الجهاز كما يلي:

[C-SR-1] يُنصح بشدة بتنفيذ ميزة "وحدة التخزين القابلة للنقل" في موقع جغرافي ثابت على المدى الطويل، لأنّ فصلها عن طريق الخطأ قد يؤدي إلى فقدان البيانات أو تلفها.

إذا كان منفذ جهاز التخزين القابل للإزالة في مكان ثابت على المدى الطويل، مثل داخل حجرة البطارية أو غطاء واقٍ آخر، يجب أن تتضمّن عمليات تنفيذ الجهاز ما يلي:

[C-SR-2] يُنصح بشدة بتنفيذ ميزة وحدة التخزين القابلة للاستخدام.

‫7.7. USB

التعريفات

وضع مضيف USB هو عندما يعمل تنفيذ الجهاز كمضيف USB، ويوفر الطاقة على الناقل، ويتواصل مع الأجهزة الطرفية.
يحدث وضع جهاز USB، المعروف أيضًا باسم وضع الجهاز الطرفي، عندما يعمل تنفيذ الجهاز كجهاز USB طرفي، ويتصل بمضيف عبر منفذ المنبع، ويستجيب لطلبات المضيف.
منفذ USB هو آلية لتوفير اتصال USB، سواء كان مقبس USB فعليًا أو واجهة غير عادية (على سبيل المثال، دبابيس توصيل).

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB، يجب أن:

يجب أن يتيح وضع "جهاز USB".
يجب أن يتيح وضع مضيف USB.
يجب أن يتيح إيقاف إشارات البيانات عبر USB.

‫7.7.1. وضع "جهاز USB"

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB متوافقًا مع وضع الجهاز الطرفي :

[C-1-1] يجب أن يكون المنفذ قابلاً للتوصيل بمضيف USB يحتوي على منفذ USB من النوع A أو النوع C.
[C-1-2] يجب عرض القيمة الصحيحة iSerialNumber في واصف جهاز USB وفقًا للمعيار من خلال android.os.Build.SERIAL.
‫[C-1-3] يجب أن يرصد الجهاز الشواحن بقدرة 1.5 أمبير و3.0 أمبير وفقًا لمعيار مقاومة النوع C، ويجب أن يرصد التغييرات في الإعلان إذا كان متوافقًا مع منفذ USB من النوع C.

[C-SR-1] يجب أن يستخدم المنفذ عامل الشكل micro-B أو micro-AB أو USB من النوع C. ننصح بشدة بأن تستوفي أجهزة Android الحالية والجديدة هذه المتطلبات لتتمكّن من الترقية إلى إصدارات المنصة المستقبلية.

[C-SR-2] يجب أن يكون المنفذ في أسفل الجهاز (وفقًا للاتجاه الطبيعي) أو يجب تفعيل تدوير الشاشة في جميع التطبيقات (بما في ذلك الشاشة الرئيسية)، وذلك لضمان عرض الشاشة بشكل صحيح عند توجيه الجهاز بحيث يكون المنفذ في الأسفل. يُنصح بشدة بأن تستوفي أجهزة Android الحالية والجديدة هذه المتطلبات لكي تتمكّن من الترقية إلى إصدارات المنصة المستقبلية.
[C-SR-3] يجب أن يتيح الجهاز سحب تيار بقوة 1.5 أمبير أثناء إرسال إشارة صوتية عالية السرعة وحركة البيانات كما هو محدّد في مواصفات شحن البطارية عبر USB، الإصدار 1.2. ننصح بشدة بأن تستوفي أجهزة Android الحالية والجديدة هذه المتطلبات لتتمكّن من الترقية إلى إصدارات المنصة المستقبلية.
[C-SR-4] يُنصح بشدة بعدم توفير طرق شحن خاصة تعدّل جهد Vbus إلى ما يتجاوز المستويات التلقائية، أو تغيّر أدوار المصدر/المستقبل، لأنّ ذلك قد يؤدي إلى حدوث مشاكل في التشغيل التفاعلي مع الشواحن أو الأجهزة التي تتوافق مع طرق USB Power Delivery العادية. على الرغم من أنّ هذا الإجراء يُصنّف على أنّه "يُنصح به بشدة"، قد نَشترط في إصدارات Android المستقبلية أن تتوافق جميع الأجهزة التي تتضمّن منفذًا من النوع C بشكل كامل مع شواحن النوع C العادية.
[C-SR-5] يُنصح بشدة بتوفير ميزة الشحن الفائق السرعة لتبديل أدوار البيانات والطاقة عند توفير منفذ USB من النوع C ووضع مضيف USB.
يجب أن تتوافق مع معيار الشحن الفائق السرعة للشحن بجهد عالٍ، وأن تتوافق مع الأوضاع البديلة، مثل عرض المحتوى على شاشة خارجية.
يجب تنفيذ واجهة برمجة التطبيقات (API) ومواصفات Android Open Accessory (AOA) على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB وتنفّذ مواصفات AOA، فإنّها:

[C-2-1] يجب الإفصاح عن إمكانية استخدام ميزة الأجهزة android.hardware.usb.accessory.
‫[C-2-2] يجب أن يتضمّن فئة التخزين الكبير عبر USB السلسلة "android" في نهاية سلسلة وصف الواجهة iInterface الخاصة بالتخزين الكبير عبر USB

‫7.7.2. وضع مستضيف USB

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB متوافقًا مع وضع المضيف، يجب أن:

[C-1-1] يجب تنفيذ واجهة برمجة التطبيقات لمضيف USB في Android على النحو الموضّح في حزمة تطوير البرامج (SDK) لنظام التشغيل Android، ويجب الإفصاح عن إمكانية استخدام ميزة الأجهزة android.hardware.usb.host.
[C-1-2] يجب توفير إمكانية ربط أجهزة USB الطرفية العادية. يجب أن تتضمّن إحدى المعلومات التالية:
- أن يتضمّن منفذ USB من النوع C أو أن يكون مزوّدًا بكابلات تحوّل منفذًا خاصًا بالجهاز إلى منفذ USB من النوع C (جهاز USB من النوع C).
- أن يتضمّن منفذ USB من النوع A أو أن يتم شحنه مع كابلات تحوّل منفذًا خاصًا بالجهاز إلى منفذ USB من النوع A
- منفذ micro-AB USB على الجهاز فقط، والذي من المفترض أن يتم شحنه مع كابل متوافق مع منفذ USB من النوع A العادي
[C-1-3] يجب ألا يتم شحن الجهاز مع محوّل يحوّل من منافذ USB من النوع A أو micro-AB إلى منفذ USB من النوع C (مقبس).
[C-SR-1] يُنصح بشدة بتنفيذ فئة صوت USB على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
يجب أن يتيح شحن جهاز USB الطرفي المتصل أثناء وضع المضيف، وأن يعلن عن تيار مصدر لا يقل عن 1.5 أمبير على النحو المحدّد في قسم "معلمات الإنهاء" من مواصفات كابل وموصل USB من النوع C، الإصدار 1.2 لموصلات USB من النوع C أو باستخدام نطاق تيار الإخراج لمنفذ الشحن السفلي (CDP) على النحو المحدّد في مواصفات شحن بطارية USB، الإصدار 1.2 لموصلات Micro-AB.
يجب تنفيذ معايير USB من النوع C وتوفير الدعم لها.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB يتيح وضع المضيف وفئة صوت USB، يجب أن:

[C-2-1] يجب أن يتوافق الجهاز مع فئة USB HID.
[C-2-2] يجب أن يتيح رصد حقول بيانات HID التالية وتعيينها المحدّدة في جداول استخدام USB HID وطلب استخدام الأوامر الصوتية إلى الثوابت KeyEvent كما هو موضّح أدناه:
- صفحة الاستخدام (0xC) معرّف الاستخدام (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
- صفحة الاستخدام (0xC) معرّف الاستخدام (0x0E9): KEYCODE_VOLUME_UP
- صفحة الاستخدام (0xC) رقم تعريف الاستخدام (0x0EA): KEYCODE_VOLUME_DOWN
- صفحة الاستخدام (0xC) معرّف الاستخدام (0x0CF): KEYCODE_VOICE_ASSIST

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB يتيح وضع المضيف وStorage Access Framework (SAF)، فإنّها:

[C-3-1] يجب أن يتعرّف على أي أجهزة متصلة عن بُعد باستخدام بروتوكول نقل الوسائط (MTP) وأن يتيح الوصول إلى محتواها من خلال أغراض ACTION_GET_CONTENT وACTION_OPEN_DOCUMENT وACTION_CREATE_DOCUMENT.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB متوافقًا مع وضع المضيف ومنفذ USB من النوع C، يجب أن تستوفي ما يلي:

[C-4-1] يجب تنفيذ وظيفة "الطاقة المزدوجة الدور" (DRP) على النحو المحدّد في مواصفات USB Type-C (القسم 4.5.1.3.3). بالنسبة إلى منافذ DRP، على الأجهزة التي تتضمّن مقبس صوت 3.5 ملم، قد يكون رصد مصدر طاقة USB (وضع المضيف) متوقفًا تلقائيًا، ولكن يجب أن يتمكّن المستخدم من تفعيله.
[C-SR-2] يُنصح بشدة بتوفير دعم DisplayPort.
- يجب أن تتوافق مع معدّلات نقل البيانات USB SuperSpeed.
- يُنصح بشدة باستخدامها لتوفير ميزة Power Delivery لتبديل أدوار البيانات والطاقة.
[C-SR-3] يُنصح بشدة بعدم توفير وضع "ملحق محوّل الصوت" كما هو موضّح في الملحق A من مواصفات كابل وموصل USB من النوع C، الإصدار 1.2.
يجب تنفيذ نموذج Try.* الأنسب لشكل الجهاز. على سبيل المثال، يجب أن يطبّق الجهاز المحمول نموذج Try.SNK.

‫7.7.3. الشحن السريع بمعيار USB

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB من النوع C، يجب أن تستوفي ما يلي:

[C-SR-1] يُنصح بشدة بتنفيذ فئة موصّل USB من النوع C في النواة وتنفيذ العُقد اللازمة التي تصف اتصالات USB من النوع C وأدوار الطاقة والبيانات. يُرجى الرجوع إلى مستندات Android USB Type-C لمعرفة تفاصيل التنفيذ.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB من النوع C وتتيح توصيل الطاقة، فإنّها:

[C-SR-2] يُنصح بشدة بتنفيذ جميع العُقد التي تصف الشحن السريع بمعيار USB. يُرجى الرجوع إلى مستندات Android USB PD لمعرفة تفاصيل التنفيذ.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB من النوع C وتتيح استخدام أوضاع بديلة، يجب أن تستوفي ما يلي:

[C-SR-3] يُنصح بشدة بتنفيذ "الأوضاع البديلة" والخصائص ذات الصلة بالهوية في فئة موصّل USB من النوع C في النواة. يُرجى الرجوع إلى مستندات Android USB Type-C لمعرفة تفاصيل التنفيذ.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB من النوع C وتتيح وضع Thunderbolt 3 البديل، يجب أن تستوفي ما يلي:

[C-SR-4] يُنصح بشدة بتنفيذ إمكانية إلغاء الوضع البديل الحالي من خلال فئة موصّل النوع C.

‫7.8. الصوت

‫7.8.1. الميكروفون

إذا كانت عمليات تنفيذ الأجهزة تتضمّن ميكروفونًا، يجب أن تستوفي ما يلي:

[C-1-1] يجب عرض ثابت ميزة android.hardware.microphone.
[C-1-2] يجب استيفاء متطلبات التسجيل الصوتي الواردة في الفقرة 5.4.
[C-1-3] يجب استيفاء متطلبات وقت استجابة الصوت المحدّدة في الفقرة 5.6.
[C-SR-1] يُنصح بشدة بتوفير إمكانية تسجيل الصوت القريب من نطاق الموجات فوق الصوتية على النحو الموضّح في الفقرة 7.8.3.

إذا كانت عمليات تنفيذ الأجهزة لا تتضمّن ميكروفونًا، يجب أن:

[C-2-1] يجب عدم عرض قيمة ثابتة للميزة android.hardware.microphone.
[C-2-2] يجب تنفيذ واجهة برمجة التطبيقات لتسجيل الصوت كعمليات غير فعّالة على الأقل، وذلك وفقًا للفقرة 7.

‫7.8.2. إخراج الصوت

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مكبّر صوت أو منفذ مصدر إخراج الصوت/متعدّد الوسائط لجهاز طرفي لإخراج الصوت، مثل مقبس صوت رباعي الموصلات بطول 3.5 ملم أو منفذ وضع مضيف الناقل التسلسلي العالمي (USB) باستخدام فئة صوت الناقل التسلسلي العالمي (USB)، يجب أن تستوفي ما يلي:

[C-1-1] يجب عرض ثابت ميزة android.hardware.audio.output.
[C-1-2] يجب استيفاء متطلبات تشغيل الصوت الواردة في الفقرة 5.5.
[C-1-3] يجب استيفاء متطلبات وقت استجابة الصوت المحدّدة في الفقرة 5.6.
‫[C-SR-1] يُنصح بشدة بتوفير إمكانية تشغيل الصوت القريب من نطاق الموجات فوق الصوتية على النحو الموضّح في الفقرة 7.8.3.

إذا لم تتضمّن عمليات تنفيذ الأجهزة مكبّر صوت أو مصدر إخراج الصوت، يجب أن:

[C-2-1] يجب عدم الإبلاغ عن ميزة android.hardware.audio.output.
[C-2-2] يجب تنفيذ واجهات برمجة التطبيقات ذات الصلة بإخراج الصوت كعمليات غير فعّالة على الأقل.

لأغراض هذا القسم، "منفذ الإخراج" هو واجهة مادية مثل مقبس صوت 3.5 ملم أو HDMI أو منفذ وضع المضيف USB مع فئة صوت USB. لا يُعدّ توفير مصدر إخراج الصوت عبر بروتوكولات مستندة إلى الراديو، مثل Bluetooth أو Wi-Fi أو شبكة الجوّال، بمثابة تضمين "منفذ إخراج".

‫7.8.2.1. منافذ الصوت التناظرية

لكي تكون سماعات الرأس وملحقات الصوت الأخرى متوافقة مع مقبس الصوت 3.5 ملم في جميع أنحاء منظومة Android المتكاملة، إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذًا واحدًا أو أكثر من منافذ الصوت التناظرية، يجب أن تستوفي ما يلي:

[C-SR-1] يُنصح بشدة بتضمين منفذ صوت واحد على الأقل من منافذ الصوت ليكون مقبس صوت 3.5 ملم بـ 4 موصلات.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقبس صوت رباعي الموصلات مقاس 3.5 ملم، يجب أن:

‫[C-1-1] يجب أن يتيح الجهاز تشغيل الصوت على سمّاعات الرأس الاستيريو والسمّاعات الاستيريو المزوّدة بميكروفون.
‫[C-1-2] يجب أن تتوافق الأجهزة مع مقابس الصوت TRRS بترتيب دبابيس CTIA.
[C-1-3] يجب أن يتيح رصد نطاقات المعاوقة المكافئة الثلاثة التالية بين الميكروفون وموصلات التأريض على قابس الصوت وربطها برموز المفاتيح:
- 70 أوم أو أقل: KEYCODE_HEADSETHOOK
- من 210 إلى 290 أوم: KEYCODE_VOLUME_UP
- من 360 إلى 680 أوم: KEYCODE_VOLUME_DOWN
[C-1-4] يجب أن يتم تشغيل ACTION_HEADSET_PLUG عند إدخال القابس، ولكن فقط بعد أن تلامس جميع نقاط التوصيل الموجودة على القابس الأجزاء ذات الصلة على المقبس.
[C-1-5] يجب أن يكون الجهاز قادرًا على توفير جهد كهربائي خارج يبلغ 150 ملي فولت ±% 10 على الأقل عند مقاومة سماعة تبلغ 32 أوم.
[C-1-6] يجب أن يتراوح جهد انحياز الميكروفون بين 1.8 فولت و2.9 فولت.
[C-1-7] يجب أن يرصد الجهاز نطاق المعاوقة المكافئة التالي بين موصّلي الميكروفون والأرضي في قابس الصوت وأن يربطه برمز المفتاح:
- من 110 إلى 180 أوم: KEYCODE_VOICE_ASSIST
[C-SR-2] يُنصح بشدة بتوفير مقابس صوتية متوافقة مع ترتيب دبابيس OMTP.
[C-SR-3] يُنصح بشدة بتوفير إمكانية تسجيل الصوت من سمّاعات رأس ستيريو مزوّدة بميكروفون.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقبس صوت 3.5 ملم بأربعة موصلات وتتيح استخدام ميكروفون، وتبث android.intent.action.HEADSET_PLUG مع ضبط قيمة الميكروفون الإضافي على 1، فإنّها:

[C-2-1] يجب أن يتيح رصد الميكروفون على ملحق الصوت الموصّل.

‫7.8.2.2. منافذ الصوت الرقمي

راجِع القسم 2.2.1 لمعرفة المتطلبات الخاصة بالجهاز.

‫7.8.3. الموجات فوق الصوتية القريبة

النطاق الصوتي القريب من الموجات فوق الصوتية هو النطاق من 18.5 كيلوهرتز إلى 20 كيلوهرتز.

عمليات تنفيذ الجهاز:

يجب الإبلاغ بشكل صحيح عن إتاحة إمكانية الصوت القريب من الموجات فوق الصوتية من خلال واجهة برمجة التطبيقات AudioManager.getProperty على النحو التالي:

إذا كانت قيمة PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND هي "true"، يجب أن تستوفي مصادر الصوت VOICE_RECOGNITION وUNPROCESSED المتطلبات التالية:

‫[C-1-1] يجب ألا يقل متوسط استجابة طاقة الميكروفون في النطاق من 18.5 كيلو هرتز إلى 20 كيلو هرتز عن 15 ديسيبل مقارنةً بالاستجابة عند 2 كيلو هرتز.
‫[C-1-2] يجب ألا تقل نسبة الإشارة إلى الضوضاء غير المرجّحة للميكروفون في نطاق التردد من 18.5 كيلو هرتز إلى 20 كيلو هرتز بالنسبة إلى نغمة بتردد 19 كيلو هرتز عند مستوى -26 ديسيبل عن 50 ديسيبل.

إذا كانت قيمة PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND هي "true":

[C-2-1] يجب ألا يقل متوسط استجابة السمّاعة في نطاق التردد من 18.5 كيلو هرتز إلى 20 كيلو هرتز عن 40 ديسيبل تحت الاستجابة عند 2 كيلو هرتز.

‫7.8.4. سلامة الإشارة

عمليات تنفيذ الجهاز:

يجب توفير مسار إشارة صوتية خالٍ من الأخطاء لكل من تدفقات الإدخال والإخراج على الأجهزة المحمولة، وذلك على النحو المحدّد بعدم حدوث أي أخطاء تم قياسها خلال اختبار لمدة دقيقة واحدة لكل مسار. اختبِر باستخدام OboeTester "اختبار الأخطاء المبرمَج".

يتطلّب الاختبار مفتاح إلكتروني لتكرار الصوت، يتم استخدامه مباشرةً في مقبس 3.5 ملم، و/أو مع محوّل من منفذ USB-C إلى 3.5 ملم. يجب اختبار جميع مصادر إخراج الصوت.

يتوافق OboeTester حاليًا مع مسارات AAudio، لذا يجب اختبار المجموعات التالية بحثًا عن أخطاء باستخدام AAudio:

وضع الأداء	المشاركة	معدّل البيانات في الملف الصوتي	في قنوات	Out Chans
LOW_LATENCY	EXCLUSIVE	UNSPECIFIED	1	2
LOW_LATENCY	EXCLUSIVE	UNSPECIFIED	2	1
LOW_LATENCY	مشترك	UNSPECIFIED	1	2
LOW_LATENCY	مشترك	UNSPECIFIED	2	1
NONE	مشترك	48000	1	2
NONE	مشترك	48000	2	1
NONE	مشترك	44100	1	2
NONE	مشترك	44100	2	1
NONE	مشترك	16000	1	2
NONE	مشترك	16000	2	1

يجب أن يستوفي البث الموثوق المعايير التالية المتعلقة بنسبة الإشارة إلى الضوضاء (SNR) والتشويه التوافقي الكلي (THD) لموجة جيبية بتردد 2000 هرتز.

محوّل الطاقة	THD	SNR
مكبّر الصوت الأساسي المدمج، ويتم قياسه باستخدام ميكروفون مرجعي خارجي	أقل من %3.0	‫>= 50 ديسيبل
الميكروفون الأساسي المُدمَج، ويتم قياسه باستخدام مكبّر صوت مرجعي خارجي	أقل من %3.0	‫>= 50 ديسيبل
مقابس تناظرية مدمجة مقاس 3.5 ملم، تم اختبارها باستخدام محوّل loopback	أقل من %1	‫‎>= 60 ديسيبل
محوّلات USB المرفقة مع الهاتف، تم اختبارها باستخدام محوّل loopback	أقل من %1.0	‫‎>= 60 ديسيبل

7.9. الواقع الافتراضي

يتضمّن نظام التشغيل Android واجهات برمجة تطبيقات ومرافق لإنشاء تطبيقات "الواقع الافتراضي" (VR)، بما في ذلك تجارب الواقع الافتراضي عالية الجودة على الأجهزة الجوّالة. يجب أن تنفّذ الأجهزة هذه الواجهات والسلوكيات بشكل سليم، كما هو موضّح بالتفصيل في هذا القسم.

‫7.9.1. وضع الواقع الافتراضي

يتوافق نظام التشغيل Android مع وضع الواقع الافتراضي، وهي ميزة تعالج العرض المجسّم للإشعارات وتوقف مكوّنات واجهة مستخدم النظام أحادية العين أثناء تركيز تطبيق الواقع الافتراضي على المستخدم.

‫7.9.2. وضع الواقع الافتراضي - أداء عالٍ

إذا كانت عمليات تنفيذ الأجهزة تتيح وضع الواقع الافتراضي، يجب أن:

[C-1-1] يجب أن تتضمّن وحدتا معالجة مركزية مادية على الأقل.
[C-1-2] يجب الإفصاح عن ميزة android.hardware.vr.high_performance.
[C-1-3] يجب أن يتوافق الجهاز مع وضع الأداء المستدام.
[C-1-4] يجب أن يتوافق الجهاز مع OpenGL ES 3.2.
[C-1-5] يجب أن تتوافق مع android.hardware.vulkan.level 0.
يجب أن تتوافق مع الإصدار 1 أو الإصدارات الأحدث من android.hardware.vulkan.level.
[C-1-6] يجب تنفيذ EGL_KHR_mutable_render_buffer و EGL_ANDROID_front_buffer_auto_refresh و EGL_ANDROID_get_native_client_buffer و EGL_KHR_fence_sync و EGL_KHR_wait_sync و EGL_IMG_context_priority و EGL_EXT_protected_content و EGL_EXT_image_gl_colorspace، وعرض الإضافات في قائمة إضافات EGL المتاحة.
[C-1-8] يجب تنفيذ GL_EXT_multisampled_render_to_texture2 وGL_OVR_multiview وGL_OVR_multiview2 وGL_EXT_protected_textures، وعرض الإضافات في قائمة إضافات GL المتاحة.
[C-SR-1] يُنصح بشدة بتنفيذ GL_EXT_external_buffer و GL_EXT_EGL_image_array و GL_OVR_multiview_multisampled_render_to_texture، وعرض الإضافات في قائمة إضافات GL المتاحة.
‫[C-SR-2] يُنصح بشدة بتوفير إمكانية استخدام Vulkan 1.1.
[C-SR-3] يُنصح بشدة بتنفيذ VK_ANDROID_external_memory_android_hardware_buffer و VK_GOOGLE_display_timing و VK_KHR_shared_presentable_image وعرضها في قائمة إضافات Vulkan المتاحة.
[C-SR-4] يُنصح بشدة بعرض مجموعة واحدة على الأقل من قوائم انتظار Vulkan التي تحتوي فيها flags على كل من VK_QUEUE_GRAPHICS_BIT وVK_QUEUE_COMPUTE_BIT، وأن تكون قيمة queueCount هي 2 على الأقل.
[C-1-7] يجب أن يكون بإمكان وحدة معالجة الرسومات والشاشة مزامنة الوصول إلى المخزن المؤقت الأمامي المشترك، وذلك لضمان عرض محتوى الواقع الافتراضي بمعدل 60 إطارًا في الثانية مع سياقَي عرض بالتناوب بين العينين بدون أي تشوّهات مرئية.
[C-1-9] يجب توفير دعم AHardwareBuffer للعلامات AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER وAHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA وAHARDWAREBUFFER_USAGE_PROTECTED_CONTENT كما هو موضّح في NDK.
[C-1-10] يجب توفير إمكانية استخدام AHardwareBufferمع أي مجموعة من علامات الاستخدام AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT وAHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE وAHARDWAREBUFFER_USAGE_PROTECTED_CONTENT مع التنسيقات التالية على الأقل: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM وAHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM وAHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM وAHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
[C-SR-5] يُنصح بشدة بتوفير إمكانية تخصيص AHardwareBuffers بأكثر من طبقة واحدة وعلامات وتنسيقات محددة في C-1-10.
‫[C-1-11] يجب أن تتوافق مع فك ترميز H.264 بدقة 3840 × 2160 على الأقل بمعدل 30 إطارًا في الثانية، مع ضغط بمعدل 40 ميغابت في الثانية (أي ما يعادل 4 حالات بدقة 1920 × 1080 بمعدل 30 إطارًا في الثانية وبسرعة 10 ميغابت في الثانية أو حالتين بدقة 1920 × 1080 بمعدل 60 إطارًا في الثانية وبسرعة 20 ميغابت في الثانية).
‫[C-1-12] يجب أن يتوافق مع HEVC وVP9، ويجب أن يكون قادرًا على فك ترميز 1920 × 1080 على الأقل بمعدل 30 لقطة في الثانية مضغوطة بمعدل 10 ميغابت في الثانية في المتوسط، ويجب أن يكون قادرًا على فك ترميز 3840 × 2160 بمعدل 30 لقطة في الثانية بمعدل 20 ميغابت في الثانية (أي ما يعادل 4 حالات من 1920 × 1080 بمعدل 30 لقطة في الثانية بمعدل 5 ميغابت في الثانية).
[C-1-13] يجب أن تتوافق مع واجهة برمجة التطبيقات HardwarePropertiesManager.getDeviceTemperatures وأن تعرض قيمًا دقيقة لدرجة حرارة الجلد.
‫[C-1-14] يجب أن يتضمّن شاشة مدمجة، ويجب أن تكون درجة الدقة 1920 × 1080 على الأقل.
[C-SR-6] يُنصح بشدة أن تكون دقة العرض 2560 × 1440 على الأقل.
‫[C-1-15] يجب أن يتم تعديل الشاشة بمعدّل 60 هرتز على الأقل أثناء وضع الواقع الافتراضي.
[C-1-17] يجب أن تتوافق الشاشة مع وضع الثبات المنخفض الذي يبلغ ثباته 5 ملي ثانية أو أقل، ويُعرَّف الثبات بأنّه مقدار الوقت الذي ينبعث فيه الضوء من البكسل.
‫[C-1-18] يجب أن يتوافق الجهاز مع الإصدار 4.2 من البلوتوث ومعيار Bluetooth LE Data Length Extension الفقرة 7.4.3.
[C-1-19] يجب أن يتيح الجهاز عرض نوع القناة المباشرة والإبلاغ عنه بشكل صحيح لجميع أنواع المستشعرات التلقائية التالية:
- TYPE_ACCELEROMETER
- TYPE_ACCELEROMETER_UNCALIBRATED
- TYPE_GYROSCOPE
- TYPE_GYROSCOPE_UNCALIBRATED
- TYPE_MAGNETIC_FIELD
- TYPE_MAGNETIC_FIELD_UNCALIBRATED
[C-SR-7] يُنصح بشدة بتوفير TYPE_HARDWARE_BUFFER لنظام القنوات المباشرة لجميع أنواع القنوات المباشرة المذكورة أعلاه.
[C-1-21] يجب استيفاء المتطلبات المتعلقة بالجيروسكوب ومقياس التسارع ومقياس المغناطيسية في android.hardware.hifi_sensors، كما هو محدّد في الفقرة 7.3.9.
[C-SR-8] يُنصح بشدة بتوفير ميزة android.hardware.sensor.hifi_sensors.
[C-1-22] يجب ألا يتجاوز وقت استجابة الحركة من البداية إلى النهاية 28 ملي ثانية.
[C-SR-9] يُنصح بشدة أن يكون وقت استجابة الحركة من البداية إلى النهاية أقل من 20 مللي ثانية.
[C-1-23] يجب أن تتوفّر نسبة الإطار الأول، وهي النسبة بين سطوع وحدات البكسل في الإطار الأول بعد الانتقال من اللون الأسود إلى الأبيض وسطوع وحدات البكسل البيضاء في الحالة الثابتة، بنسبة %85 على الأقل.
[C-SR-10] يُنصح بشدة أن تكون نسبة الإطار الأول %90 على الأقل.
يمكن توفير نواة حصرية للتطبيق الذي يعمل في المقدّمة، ويمكن إتاحة استخدام واجهة برمجة التطبيقات Process.getExclusiveCores لعرض أرقام نوى وحدة المعالجة المركزية الحصرية للتطبيق الذي يعمل في المقدّمة.

في حال توفّر النواة الحصرية، يجب أن تستوفي النواة الشروط التالية:

[C-2-1] يجب ألا يسمح بتشغيل أي عمليات أخرى في مساحة المستخدم (باستثناء برامج تشغيل الأجهزة التي يستخدمها التطبيق)، ولكن يجوز أن يسمح بتشغيل بعض عمليات النواة حسب الضرورة.

‫7.10. تقنية اللمس

قد تتضمّن الأجهزة التي يمكن حملها باليد أو ارتداؤها مشغّلاً حسّيًا للأغراض العامة، وهو متاح للتطبيقات لأغراض تشمل جذب الانتباه من خلال نغمات الرنين والمنبّهات والإشعارات، بالإضافة إلى تقديم ملاحظات عامة عند اللمس.

إذا لم تتضمّن عمليات تنفيذ الأجهزة مشغّلاً لمسياً عام الأغراض، يجب أن تستوفي ما يلي:

[7.10/C] MUST return false for Vibrator.hasVibrator().

إذا كانت عمليات تنفيذ الأجهزة تتضمّن على الأقل مشغّلاً واحدًا من هذا النوع من المشغّلات اللمسية العامة، يجب أن تستوفي ما يلي:

[C-1-1] يجب أن تعرض القيمة "صحيح" لـ Vibrator.hasVibrator().
يجب عدم استخدام مشغّل لمس دوّار غير مركزي (ERM) (هزاز).
يجب تنفيذ جميع الثوابت العامة لردود الفعل اللمسية الواضحة في android.view.HapticFeedbackConstants وهي (CLOCK_TICK وCONTEXT_CLICK وKEYBOARD_PRESS وKEYBOARD_RELEASE وKEYBOARD_TAP وLONG_PRESS وTEXT_HANDLE_MOVE وVIRTUAL_KEY وVIRTUAL_KEY_RELEASE وCONFIRM وREJECT وGESTURE_START وGESTURE_END).
يجب تنفيذ جميع الثوابت العامة الخاصة باللمسات الواضحة في android.os.VibrationEffect، أي (EFFECT_TICK وEFFECT_CLICK وEFFECT_HEAVY_CLICK وEFFECT_DOUBLE_CLICK) وجميع الثوابت العامة الممكنة PRIMITIVE_* الخاصة باللمسات الغنية في android.os.VibrationEffect.Composition، أي (CLICK وTICK وLOW_TICK وQUICK_FALL وQUICK_RISE وSLOW_RISE وSPIN وTHUD). قد لا تكون بعض هذه العناصر الأساسية، مثل LOW_TICK وSPIN، ممكنة إلا إذا كان جهاز الاهتزاز يتيح استخدام ترددات منخفضة نسبيًا.
يجب اتّباع إرشادات ربط الثوابت العامة في android.view.HapticFeedbackConstants بثوابت android.os.VibrationEffect المقترَحة، مع علاقات السعة المقابلة.
يجب استخدام عمليات الربط الثابتة الحسية المرتبطة هذه.
يجب اتّباع تقييم الجودة لواجهات برمجة التطبيقات createOneShot() وcreateWaveform().
يجب التأكّد من أنّ نتيجة واجهة برمجة التطبيقات العامة android.os.Vibrator.hasAmplitudeControl() تعكس إمكانات جهاز الاهتزاز بشكل صحيح.
يجب التحقّق من إمكانات قابلية التوسّع في السعة من خلال تنفيذ android.os.Vibrator.hasAmplitudeControl().

إذا كانت عمليات تنفيذ الأجهزة تتّبع عملية ربط الثوابت الحسية، فإنّها:

يجب التحقّق من حالة التنفيذ من خلال تشغيل واجهات برمجة التطبيقات android.os.Vibrator.areAllEffectsSupported() وandroid.os.Vibrator.arePrimitivesSupported().
يجب إجراء تقييم للجودة للمتغيرات الحسية.
يجب التحقّق من إعدادات التوافق مع الإصدارات السابقة وتعديلها إذا لزم الأمر بالنسبة إلى العناصر الأساسية غير المتوافقة، وذلك على النحو الموضّح في إرشادات التنفيذ الخاصة بالثوابت.
يجب توفير دعم احتياطي للحدّ من مخاطر الفشل كما هو موضّح هنا.

‫7.11. فئة أداء الوسائط

يمكن الحصول على فئة أداء الوسائط لتنفيذ الجهاز من خلال واجهة برمجة التطبيقات android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS. يتم تحديد متطلبات فئة أداء الوسائط لكل إصدار من إصدارات Android بدءًا من الإصدار R (الإصدار 30). تشير القيمة الخاصة 0 إلى أنّ الجهاز ليس من فئة أداء الوسائط.

إذا كانت عمليات تنفيذ الأجهزة تعرض قيمة غير صفرية لـ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS، يجب أن:

[C-1-1] يجب أن تعرض على الأقل القيمة android.os.Build.VERSION_CODES.R.
[C-1-2] يجب أن يكون الجهاز المحمول مزودًا بهذه الميزة.
[C-1-3] يجب استيفاء جميع متطلبات "فئة أداء الوسائط" الموضّحة في الفقرة 2.2.7.

بعبارة أخرى، لا يتم تحديد فئة أداء الوسائط في Android T إلا للأجهزة المحمولة التي تعمل بالإصدار T أو S أو R.

راجِع الفقرة 2.2.7 لمعرفة المتطلبات الخاصة بالأجهزة.

8. الأداء والطاقة

تُعد بعض معايير الأداء والطاقة الدنيا ضرورية لتجربة المستخدم، كما أنّها تؤثر في الافتراضات الأساسية التي يضعها المطوّرون عند تطوير تطبيق.

‫8.1. اتّساق تجربة المستخدم

يمكن توفير واجهة مستخدم سلسة للمستخدم النهائي إذا توفّرت بعض المتطلبات الدنيا لضمان عدد اللقطات في الثانية ثابت وأوقات استجابة للتطبيقات والألعاب. قد تتضمّن عمليات تنفيذ الأجهزة، وفقًا لنوع الجهاز، متطلبات قابلة للقياس بشأن وقت استجابة واجهة المستخدم وتبديل المهام، كما هو موضّح في القسم 2.

‫8.2. أداء الوصول إلى ملفات الإدخال والإخراج

يسمح توفير أساس مشترك لأداء متسق في الوصول إلى الملفات في مساحة تخزين البيانات الخاصة بالتطبيق (قسم /data) لمطوّري التطبيقات بوضع توقعات مناسبة تساعدهم في تصميم برامجهم. قد تتضمّن عمليات تنفيذ الأجهزة، حسب نوع الجهاز، متطلبات معيّنة موضّحة في القسم 2 لعمليات القراءة والكتابة التالية:

أداء الكتابة التسلسلية: يتم قياسها من خلال كتابة ملف بحجم 256 ميغابايت باستخدام مخزن مؤقت للكتابة بحجم 10 ميغابايت.
أداء الكتابة العشوائية: يتم قياسها من خلال كتابة ملف بحجم 256 ميغابايت باستخدام مخزن مؤقت للكتابة بحجم 4 كيلوبايت.
أداء القراءة التسلسلية: يتم قياسها من خلال قراءة ملف بحجم 256 ميغابايت باستخدام ذاكرة تخزين مؤقت للكتابة بحجم 10 ميغابايت.
أداء القراءة العشوائية: يتم قياسها من خلال قراءة ملف بحجم 256 ميغابايت باستخدام ذاكرة تخزين مؤقت للكتابة بحجم 4 كيلوبايت.

8.3. أوضاع توفير الطاقة

إذا كانت عمليات تنفيذ الأجهزة تتضمّن ميزات لتحسين إدارة طاقة الجهاز المضمّنة في مشروع Android المفتوح المصدر (AOSP) (مثل "حزمة تطبيقات وضع الاستعداد" و"قيلولة") أو توسّع الميزات لتطبيق قيود أكثر صرامة من حزمة تطبيقات وضع الاستعداد "المقيّدة"، يجب أن تستوفي ما يلي:

[C-1-1] يجب عدم الانحراف عن تنفيذ AOSP في ما يتعلق بتشغيل وصيانة وخوارزميات التنشيط واستخدام إعدادات النظام العامة أو DeviceConfig لوضعَي "توفير الطاقة"، أي "وضع الاستعداد للتطبيق" و"وضع السكون".
[C-1-2] يجب عدم الانحراف عن تنفيذ AOSP لاستخدام الإعدادات العامة أو DeviceConfig لإدارة تقييد المهام والمنبّه والشبكة للتطبيقات في كل حزمة في وضع "استعداد التطبيق".
[C-1-3] يجب عدم الانحراف عن تنفيذ AOSP لعدد حِزم وضع التطبيق في وضع الاستعداد المستخدَمة لوضع التطبيق في وضع الاستعداد.
[C-1-4] يجب تنفيذ حِزم وضع "استعداد التطبيق" ووضع "السكون" كما هو موضّح في إدارة الطاقة.
[C-1-5] يجب أن تعرض true القيمة PowerManager.isPowerSaveMode() عندما يكون الجهاز في وضع توفير الطاقة.
[C-1-6] يجب توفير إمكانية للمستخدم لعرض جميع التطبيقات المستثناة من وضعي توفير الطاقة "تطبيقات وضع الاستعداد" و"قيلولة" أو أي تحسينات للبطارية، ويجب تنفيذ الغرض ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS لطلب السماح لأحد التطبيقات بتجاهل تحسينات البطارية.
[C-SR-1] يُنصح بشدة بتوفير إمكانية للمستخدمين لتفعيل ميزة "توفير شحن البطارية" وإيقافها.
[C-SR-2] يُنصح بشدة بتوفير إمكانية للمستخدم لعرض جميع التطبيقات المستثناة من وضعَي "استعداد التطبيق" و"توفير الطاقة" (Doze).

إذا كانت عمليات تنفيذ الأجهزة توسّع ميزات إدارة الطاقة المضمَّنة في مشروع Android المفتوح المصدر (AOSP) وكان هذا التوسيع يفرض قيودًا أكثر صرامة من حزمة تطبيقات وضع الاستعداد النادرة، يُرجى الرجوع إلى الفقرة 3.5.1.

بالإضافة إلى أوضاع توفير الطاقة، يمكن أن تنفّذ أجهزة Android أيًا من حالات الطاقة الأربع الخاصة بالسكون أو جميعها، وذلك على النحو المحدّد في "واجهة الضبط المتقدّم والطاقة" (ACPI).

إذا كانت عمليات تنفيذ الأجهزة تنفّذ حالات الطاقة S4 على النحو المحدّد في ACPI، عليها استيفاء ما يلي:

[C-1-1] يجب ألا يتم الانتقال إلى هذه الحالة إلا بعد أن يتّخذ المستخدم إجراءً صريحًا لوضع الجهاز في حالة غير نشطة (مثل إغلاق غطاء يشكّل جزءًا ماديًا من الجهاز أو إيقاف تشغيل مركبة أو تلفزيون) وقبل أن يعيد المستخدم تنشيط الجهاز (مثل فتح الغطاء أو إعادة تشغيل المركبة أو التلفزيون).

إذا كانت عمليات تنفيذ الأجهزة تنفّذ حالات الطاقة S3 على النحو المحدّد في ACPI، فإنّها:

[C-2-1] يجب استيفاء المتطلبات الواردة في الفقرة C-1-1 أعلاه، أو يجب الدخول في حالة S3 فقط عندما لا تحتاج تطبيقات الجهات الخارجية إلى موارد النظام (مثل الشاشة ووحدة المعالجة المركزية).

في المقابل، يجب الخروج من حالة S3 عندما تحتاج تطبيقات تابعة لجهات خارجية إلى موارد النظام، كما هو موضح في حزمة SDK هذه.

على سبيل المثال، بينما تطلب التطبيقات التابعة لجهات خارجية إبقاء الشاشة مضاءة من خلال FLAG_KEEP_SCREEN_ON أو إبقاء وحدة المعالجة المركزية قيد التشغيل من خلال PARTIAL_WAKE_LOCK، يجب ألا ينتقل الجهاز إلى حالة S3 إلا إذا اتّخذ المستخدم إجراءً صريحًا لوضع الجهاز في حالة غير نشطة، كما هو موضّح في C-1-1. في المقابل، عند تشغيل مهمة تنفّذها تطبيقات تابعة لجهات خارجية من خلال JobScheduler أو عند إرسال رسالة من مراسلة Firebase السحابية إلى تطبيقات تابعة لجهات خارجية، يجب أن يخرج الجهاز من حالة S3 ما لم يضعه المستخدم في حالة غير نشطة. هذه ليست أمثلة شاملة، إذ تنفّذ AOSP إشارات تنبيه شاملة تؤدي إلى التنبيه من هذه الحالة.

‫8.4. محاسبة استهلاك الطاقة

يوفّر تدوين سجلات الاستخدام وإعداد التقارير عن استهلاك الطاقة بشكل أكثر دقة لمطوّر تطبيقات الحوافز والأدوات اللازمة لتحسين نمط استخدام الطاقة في التطبيق.

عمليات تنفيذ الجهاز:

[C-SR-1] يُنصح بشدة بتوفير ملف تعريف طاقة لكل مكوّن يحدّد قيمة استهلاك التيار لكل مكوّن من مكونات الجهاز ومعدّل استنزاف البطارية التقريبي الذي تسببه المكونات بمرور الوقت كما هو موثّق في موقع "مشروع Android المفتوح المصدر".
[C-SR-2] يُنصح بشدة بتسجيل جميع قيم استهلاك الطاقة بوحدة ميلي أمبير في الساعة (mAh).
[C-SR-3] يُنصح بشدة بالإبلاغ عن استهلاك طاقة وحدة المعالجة المركزية لكل معرّف مستخدم (UID) خاص بكل عملية. يستوفي "مشروع مفتوح المصدر لنظام Android" هذا الشرط من خلال تنفيذ وحدة النواة uid_cputime.
[C-SR-4] يُنصح بشدة بإتاحة معلومات استهلاك الطاقة هذه من خلال الأمر adb shell dumpsys batterystats في واجهة سطر الأوامر لمطوّر التطبيق.
يجب أن يكون السبب هو مكوّن الجهاز نفسه إذا تعذّر تحديد التطبيق المسؤول عن استهلاك الطاقة.

‫8.5. الأداء المتّسق

يمكن أن يتفاوت الأداء بشكل كبير في التطبيقات التي تعمل لفترة طويلة وتتطلّب أداءً عاليًا، إما بسبب التطبيقات الأخرى التي تعمل في الخلفية أو بسبب تقييد سرعة وحدة المعالجة المركزية نتيجةً لحدود درجة الحرارة. يتضمّن نظام التشغيل Android واجهات برمجية آلية، وبالتالي عندما يكون الجهاز متوافقًا، يمكن للتطبيق الذي يظهر في المقدّمة أن يطلب من النظام تحسين تخصيص الموارد للتعامل مع هذه التقلبات.

عمليات تنفيذ الجهاز:

[C-0-1] يجب أن يتم الإبلاغ عن إتاحة "وضع الأداء المستدام" بدقة من خلال طريقة واجهة برمجة التطبيقات PowerManager.isSustainedPerformanceModeSupported().
يجب أن يتوافق مع "وضع الأداء المستدام".

في حال كانت عمليات تنفيذ الأجهزة تتيح "وضع الأداء المستدام"، يجب أن:

[C-1-1] يجب أن يوفّر الجهاز للتطبيق الذي يعمل في المقدّمة أعلى مستوى أداء لمدة 30 دقيقة على الأقل، وذلك عندما يطلب التطبيق ذلك.
[C-1-2] يجب أن يلتزم Window.setSustainedPerformanceMode() وغيره من واجهات برمجة التطبيقات ذات الصلة.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن نواتَين أو أكثر لوحدة المعالجة المركزية، يجب أن تستوفي ما يلي:

يجب توفير نواة حصرية واحدة على الأقل يمكن للتطبيق الأهم في المقدّمة حجزها.

إذا كانت عمليات تنفيذ الأجهزة تتيح حجز نواة حصرية واحدة لأهم تطبيق يعمل في المقدّمة، يجب أن:

[C-2-1] يجب إعداد تقارير من خلال طريقة واجهة برمجة التطبيقات Process.getExclusiveCores() عن أرقام تعريف النوى الحصرية التي يمكن حجزها من خلال التطبيق الذي يعمل في المقدّمة.
[C-2-2] يجب ألا يسمح بأي عمليات في مساحة المستخدم باستثناء برامج تشغيل الأجهزة التي يستخدمها التطبيق للتشغيل على النوى الحصرية، ولكن يجوز السماح بتشغيل بعض عمليات النواة حسب الضرورة.

إذا كانت عمليات تنفيذ الأجهزة لا تتوافق مع النواة الحصرية، يجب أن:

[C-3-1] يجب عرض قائمة فارغة من خلال طريقة Process.getExclusiveCores() في واجهة برمجة التطبيقات.

‫8.6. الحدود القصوى لذاكرة التطبيقات

سيتم فرض قيود على مقدار ذاكرة الوصول العشوائي الديناميكية (DRAM) المستخدَمة لكل عملية تطبيق فردية من خلال MemoryLimiter، وهو مكوّن جديد من ActivityManagerService، وحدود الذاكرة التلقائية للتطبيقات، والتي يتم استخلاصها من الذاكرة الفعلية المتاحة. وينطبق هذا القيد على جميع الذاكرة المخصّصة ضمن عملية التطبيق، ما يضمن عمل الحدود كأحد السلوكيات التعاقدية المهمة مع مطوّري التطبيقات.

عمليات تنفيذ الجهاز:

[C-0-1] يجب عدم استخدام أي طرق أو قوائم سماح أو سياسات لتجاوز حدود ذاكرة وقت التشغيل المحدّدة للتطبيقات.

9. توافُق نموذج الأمان

عمليات تنفيذ الجهاز:

[C-0-1] يجب تنفيذ نموذج أمان متوافق مع نموذج أمان نظام Android الأساسي على النحو المحدّد في مستند مرجع الأمان والأذونات ضمن واجهات برمجة التطبيقات في مستندات مطوّري برامج Android.
[C-0-2] يجب أن يتيح تثبيت التطبيقات الموقَّعة ذاتيًا بدون الحاجة إلى أي أذونات أو شهادات إضافية من أي جهات خارجية أو سلطات.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن بيانًا عن الميزة android.hardware.security.model.compatible، فإنّها:

[C-1-1] يجب أن تتوافق مع المتطلبات الواردة في الأقسام الفرعية التالية.

‫9.1. الأذونات

عمليات تنفيذ الجهاز:

[C-0-1] يجب أن يتوافق مع نموذج أذونات Android ونموذج أدوار Android على النحو المحدّد في مستندات مطوّري Android. وعلى وجه التحديد، يجب أن تفرض هذه التطبيقات كل إذن ودور محدّدَين كما هو موضح في مستندات حزمة SDK، ولا يجوز حذف أي أذونات أو أدوار أو تغييرها أو تجاهلها.
يمكن إضافة أذونات إضافية، بشرط ألا تكون سلاسل معرّفات الأذونات الجديدة في مساحة الاسم android.\*.
[C-0-2] يجب ألا يتم منح الأذونات التي تتضمّن protectionLevelPROTECTION_FLAG_PRIVILEGED إلا للتطبيقات المثبَّتة مسبقًا في مسارات ذات امتيازات خاصة ضمن صورة النظام (بالإضافة إلى ملفات APEX) وأن تكون ضمن المجموعة الفرعية من الأذونات المدرَجة في القائمة البيضاء لكل تطبيق. يستوفي تنفيذ AOSP هذا الشرط من خلال قراءة الأذونات المدرَجة في القائمة البيضاء لكل تطبيق من الملفات في المسار etc/permissions/ والالتزام بها، واستخدام المسار system/priv-app كمسار ذي امتيازات خاصة.
[C-SR-1] يُنصح بشدة بمنح الأذونات التي تتضمّن protectionLevel بقيمة PROTECTION_SIGNATURE لأحد الخيارَين التاليَين فقط:
- التطبيقات المثبَّتة مسبقًا على صورة النظام (بالإضافة إلى ملفات APEX)
- التطبيقات المُدرَجة في القائمة المسموح بها مع الأذونات المسموح بها إذا لم تكن مضمّنة في صورة النظام
ملاحظة: يستوفي تنفيذ AOSP هذا الشرط من خلال قراءة الأذونات المدرَجة في القائمة المسموح بها لكل تطبيق والالتزام بها من الملفات في المسار etc/permissions/.

الأذونات التي لها مستوى حماية خطير هي أذونات التشغيل. تطلب التطبيقات التي تتضمّن targetSdkVersion > 22 هذه الأذونات في وقت التشغيل.

عمليات تنفيذ الجهاز:

[C-0-3] يجب عرض واجهة مخصّصة للمستخدم ليقرّر ما إذا كان سيمنح أذونات التشغيل المطلوبة، ويجب أيضًا توفير واجهة للمستخدم لإدارة أذونات التشغيل.
[C-0-5] يجب عدم منح أي أذونات وقت التشغيل للتطبيقات إلا في الحالات التالية:
- يتم تثبيتها عند شحن الجهاز، و
- يمكن الحصول على موافقة المستخدم قبل أن يستخدم التطبيق الإذن،
أو
- يتم منح أذونات وقت التشغيل بموجب سياسة منح الأذونات التلقائية أو عند الحصول على دور في النظام الأساسي.
[C-0-6] يجب منح الإذن android.permission.RECOVER_KEYSTORE فقط لتطبيقات النظام التي تسجّل "وكيل استرداد" آمنًا بشكل صحيح. يتم تعريف "عامل الاسترداد" المحمي بشكل صحيح على أنّه برنامج على الجهاز تتم مزامنته مع وحدة تخزين خارجية بعيدة، ومزوّد بأجهزة آمنة توفّر حماية مماثلة أو أقوى من تلك الموضّحة في خدمة Google Cloud Key Vault لمنع هجمات القوة العمياء على عامل معرفة شاشة القفل.

عمليات تنفيذ الجهاز:

[C-0-7] يجب الالتزام بخصائص إذن تحديد الموقع الجغرافي على Android عندما يطلب تطبيق بيانات الموقع الجغرافي أو النشاط البدني من خلال واجهة برمجة تطبيقات Android العادية أو آلية خاصة. وتشمل هذه البيانات على سبيل المثال لا الحصر ما يلي:
- الموقع الجغرافي للجهاز (مثل خط العرض وخط الطول) كما هو موضح في الفقرة 9.8.8
- المعلومات التي يمكن استخدامها لتحديد موقع الجهاز أو تقديره (مثل معرّف SSID أو BSSID أو معرّف الخلية أو موقع الشبكة التي يتصل بها الجهاز)
- النشاط البدني للمستخدم أو تصنيف النشاط البدني

على وجه التحديد، يجب أن تتضمّن عمليات تنفيذ الأجهزة ما يلي:

[C-0-8] يجب الحصول على موافقة المستخدم للسماح لأحد التطبيقات بالوصول إلى بيانات الموقع الجغرافي أو بيانات نشاط المستخدم.
[C-0-9] يجب منح إذن التشغيل للتطبيق الذي لديه إذن كافٍ فقط، كما هو موضّح في حزمة SDK. على سبيل المثال، تتطلّب الدالة TelephonyManager#getServiceState الإذن android.permission.ACCESS_FINE_LOCATION.

الاستثناءات الوحيدة لخصائص إذن تحديد الموقع الجغرافي على Android المذكورة أعلاه هي للتطبيقات التي لا تصل إلى بيانات الموقع الجغرافي لاستنتاج موقع المستخدم أو تحديده، وتحديدًا:

عندما تملك التطبيقات إذن RADIO_SCAN_WITHOUT_LOCATION
لأغراض إعداد الجهاز وضبطه، حيث تحتفظ تطبيقات النظام بإذنَي NETWORK_SETTINGS أو NETWORK_SETUP_WIZARD

يمكن وضع علامة "مقيّد" على الأذونات لتغيير سلوكها.

[C-0-10] يجب عدم منح التطبيق الأذونات التي تحمل العلامة hardRestricted إلا في الحالات التالية:
- ملف APK لأحد التطبيقات في قسم تطبيقات النظام
- يمنح المستخدم دورًا مرتبطًا بأذونات hardRestricted لتطبيق.
- يمنح برنامج التثبيت الإذن hardRestricted لأحد التطبيقات.
- تم منح التطبيق الإذن hardRestricted على إصدار Android أقدم.
[C-0-11] يجب أن تحصل التطبيقات التي لديها إذن softRestricted على إذن وصول محدود فقط، ويجب ألّا تحصل على إذن وصول كامل إلا بعد إضافتها إلى القائمة المسموح بها كما هو موضّح في حزمة تطوير البرامج (SDK)، حيث يتم تحديد إذن الوصول الكامل والمحدود لكل إذن softRestricted (على سبيل المثال، READ_EXTERNAL_STORAGE).
[C-0-12] يجب عدم توفير أي دوال مخصّصة أو واجهات برمجة تطبيقات لتجاوز قيود الأذونات المحدّدة في واجهتَي برمجة التطبيقات setPermissionPolicy وsetPermissionGrantState.
[C-0-13] يجب استخدام واجهات برمجة التطبيقات AppOpsManager لتسجيل وتتبُّع كل عملية وصول آلي إلى البيانات المحمية بأذونات خطيرة من أنشطة وخدمات Android.
[C-0-14] يجب عدم منح الأدوار إلا للتطبيقات التي تتضمّن وظائف تستوفي متطلبات الدور.
[C-0-15] يجب عدم تحديد أدوار مكرّرة أو وظائف مجموعة فرعية من الأدوار المحدّدة من خلال النظام الأساسي.

إذا كانت الأجهزة تتضمّن أجهزة استشعار بيانات تعرض مقاييس حيوية متعلقة بالصحة، مثل معدّل نبضات القلب أو درجة حرارة الجلد، يجب أن تستوفي هذه المقاييس الحيوية ما يلي:

[C-0-16] يجب أن تكون محمية بأذونات النظام الأساسي من android.permission-group.HEALTH، إذا كان هناك إذن مطابق في HealthPermissions.
[C-0-17] يجب أن يكون الوصول إلى نوع البيانات المطلوب محميًا بإذن نظام مخصّص في حال عدم توفّر إذن منصة يطابق نوع البيانات المطلوب. (مثلاً، ELECTROCARDIOGRAM.)

إذا كانت الأجهزة تعرض android.software.managed_users، يعني ذلك أنّها:

[C-1-1] يجب ألا يتم منح الأذونات التالية تلقائيًا من قِبل المشرف:
- الموقع الجغرافي (ACCESS_BACKGROUND_LOCATION، ACCESS_COARSE_LOCATION، ACCESS_FINE_LOCATION)
- الكاميرا (CAMERA)
- الميكروفون (RECORD_AUDIO)
- جهاز استشعار الجسم (BODY_SENSORS)
- الصحة (HealthPermissions)
- النشاط البدني (ACTIVITY_RECOGNITION)

إذا كانت الأجهزة تعرض android.software.managed_users، يعني ذلك أنّها:

[C-1-1] يجب ألا يتم منح الأذونات التالية تلقائيًا من قِبل المشرف:
- الموقع الجغرافي (ACCESS_BACKGROUND_LOCATION، ACCESS_COARSE_LOCATION، ACCESS_FINE_LOCATION)
- الكاميرا (CAMERA)
- الميكروفون (RECORD_AUDIO)
- جهاز استشعار الجسم (BODY_SENSORS)
- النشاط البدني (ACTIVITY_RECOGNITION)

إذا كانت عمليات تنفيذ الأجهزة توفّر للمستخدمين تلميحات مرئية لاختيار التطبيقات التي يمكنها الرسم فوق تطبيقات أخرى باستخدام نشاط يعالج الغرض ACTION_MANAGE_OVERLAY_PERMISSION، يجب أن تستوفي ما يلي:

[C-2-1] يجب التأكّد من أنّ جميع الأنشطة التي تتضمّن فلاتر الأهداف الخاصة بالهدف ACTION_MANAGE_OVERLAY_PERMISSION تعرض شاشة واجهة المستخدم نفسها، بغض النظر عن التطبيق الذي بدأ النشاط أو أي معلومات يقدّمها.

إذا كان تقرير عمليات تنفيذ الأجهزة android.software.device_admin، يعني ذلك ما يلي:

[C-3-1] يجب عرض بيان إخلاء مسؤولية أثناء إعداد الجهاز المُدار بالكامل (إعداد مالك الجهاز) يوضّح أنّ مشرف تكنولوجيا المعلومات سيتمكّن من السماح للتطبيقات بالتحكّم في إعدادات الهاتف، بما في ذلك الميكروفون والكاميرا والموقع الجغرافي، مع توفير خيارات للمستخدم لمواصلة الإعداد أو الخروج منه، ما لم يوقف المشرف إمكانية التحكّم في الأذونات على الجهاز.

إذا كانت عمليات تنفيذ الأجهزة تثبّت مسبقًا أي حِزم تتضمّن أيًا من أدوار واجهة مستخدِم النظام Intelligence أو System Ambient Audio Intelligence أو System Audio Intelligence أو System Notification Intelligence أو System Text Intelligence أو System Visual Intelligence، يجب أن تستوفي الحِزم ما يلي:

[C-4-1] يجب استيفاء جميع المتطلبات الموضّحة في ما يخص عمليات تنفيذ الأجهزة في الأقسام 9.8.6. بيانات على مستوى نظام التشغيل والبيانات المحيطة و9.8.15 عمليات تنفيذ Sandboxed API

‫9.2 المعرّف الفريد وعزل العمليات

عمليات تنفيذ الجهاز:

‫[C-0-1] يجب أن تتوافق مع نموذج الحماية في تطبيقات Android، حيث يتم تشغيل كل تطبيق بمعرّف UID فريد بنمط Unix وفي عملية منفصلة.
[C-0-2] يجب أن يتيح تشغيل تطبيقات متعددة باستخدام معرّف مستخدم Linux نفسه، بشرط أن تكون التطبيقات موقَّعة ومصمَّمة بشكل سليم، كما هو موضّح في مرجع الأمان والأذونات.

‫9.3. أذونات نظام الملفات

عمليات تنفيذ الجهاز:

[C-0-1] يجب أن يتوافق مع نموذج أذونات الوصول إلى الملفات في Android على النحو المحدّد في مرجع الأمان والأذونات.

‫9.4. بيئات التنفيذ البديلة

يجب أن تحافظ عمليات تنفيذ الأجهزة على اتساق نموذج الأمان والأذونات في Android، حتى إذا كانت تتضمّن بيئات وقت التشغيل التي تنفّذ التطبيقات باستخدام بعض البرامج أو التكنولوجيا الأخرى غير تنسيق Dalvik Executable أو الرمز البرمجي الأصلي. وبعبارة أخرى:

[C-0-1] يجب أن تكون بيئات التشغيل البديلة تطبيقات Android، ويجب أن تلتزم بنموذج أمان Android العادي، كما هو موضّح في مكان آخر في القسم 9.
[C-0-2] يجب عدم منح أوقات التشغيل البديلة إذن الوصول إلى الموارد المحمية بأذونات لم يتم طلبها في ملف AndroidManifest.xml لوقت التشغيل من خلال آلية <uses-permission>.
[C-0-3] يجب ألا تسمح بيئات التشغيل البديلة للتطبيقات باستخدام الميزات المحمية بأذونات Android المحصورة على تطبيقات النظام.
[C-0-4] يجب أن تلتزم بيئات التشغيل البديلة بنموذج وضع الحماية في Android، ويجب ألا تعيد التطبيقات المثبَّتة باستخدام بيئة تشغيل بديلة استخدام وضع الحماية لأي تطبيق آخر مثبَّت على الجهاز، إلا من خلال آليات Android العادية لمعرّف المستخدم المشترَك وشهادة التوقيع.
[C-0-5] يجب ألا يتم تشغيل أوقات التشغيل البديلة مع الوصول إلى البيئات المعزولة الخاصة بتطبيقات Android الأخرى أو منح هذا الوصول أو الحصول عليه.
[C-0-6] يجب ألا يتم تشغيل أوقات التشغيل البديلة مع أي امتيازات خاصة بالمستخدم المتميّز (الجذر) أو أي معرّف مستخدم آخر، كما يجب ألا يتم منح هذه الامتيازات أو الحصول عليها من تطبيقات أخرى.
[C-0-7] عند تضمين ملفات .apk لأوقات تشغيل بديلة في صورة نظام عمليات الأجهزة، يجب توقيعها باستخدام مفتاح يختلف عن المفتاح المستخدَم لتوقيع التطبيقات الأخرى المضمّنة في عمليات الأجهزة.
‫[C-0-8] عند تثبيت التطبيقات، يجب أن تحصل بيئات التشغيل البديلة على موافقة المستخدم على أذونات Android التي يستخدمها التطبيق.
[C-0-9] عندما يحتاج تطبيق إلى استخدام أحد موارد الجهاز التي يتوفّر لها إذن Android مطابق (مثل الكاميرا ونظام تحديد المواقع العالمي (GPS) وما إلى ذلك)، يجب أن يُعلم وقت التشغيل البديل المستخدم بأنّ التطبيق سيتمكّن من الوصول إلى هذا المورد.
[C-0-10] عندما لا تسجّل بيئة وقت التشغيل إمكانات التطبيق بهذه الطريقة، يجب أن تُدرِج بيئة وقت التشغيل جميع الأذونات التي تحتفظ بها عند تثبيت أي تطبيق يستخدم بيئة وقت التشغيل هذه.
يجب أن تثبّت أوقات التشغيل البديلة التطبيقات من خلال PackageManager في مساحات معزولة منفصلة لنظام Android (معرّفات مستخدمي Linux وما إلى ذلك).
قد توفّر أوقات التشغيل البديلة بيئة اختبارية واحدة على Android مشتركة بين جميع التطبيقات التي تستخدم وقت التشغيل البديل.

‫9.5. إتاحة استخدام الجهاز من قِبل عدة مستخدمين

يتضمّن نظام التشغيل Android إمكانية استخدام عدة مستخدمين، ويوفّر إمكانية عزل المستخدمين بشكل كامل واستنساخ ملفات شخصية للمستخدمين مع عزل جزئي (أي ملف شخصي إضافي واحد للمستخدم من النوع android.os.usertype.profile.CLONE).

يمكن أن تتيح عمليات تنفيذ الأجهزة ميزة تعدد المستخدمين، ولكن لا يُنصح بذلك إذا كانت تستخدم وسائط قابلة للإزالة كمساحة تخزين خارجية أساسية.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية استخدام عدة مستخدمين، يجب أن:

[C-1-2] يجب أن يتم تنفيذ نموذج أمان متوافق مع نموذج أمان نظام Android الأساسي المحدّد في مستند مرجع الأمان والأذونات في واجهات برمجة التطبيقات لكل مستخدم.
[C-1-3] يجب أن تتضمّن مساحة تخزين منفصلة ومعزولة للتطبيقات المشترَكة (المعروفة أيضًا باسم أدلة /sdcard) لكل مثيل من المستخدمين.
[C-1-4] يجب التأكّد من أنّ التطبيقات التي يملكها مستخدم معيّن ويشغّلها بالنيابة عنه لا يمكنها عرض الملفات التي يملكها أي مستخدم آخر أو قراءتها أو الكتابة فيها، حتى إذا تم تخزين بيانات كلا المستخدمَين على وحدة تخزين أو نظام ملفات واحد.
[C-1-5] يجب تشفير محتوى بطاقة SD عند تفعيل ميزة "استخدام عدة مستخدمين" باستخدام مفتاح مخزَّن فقط على وسائط غير قابلة للإزالة ولا يمكن الوصول إليها إلا من خلال النظام، وذلك في حال كانت عمليات تنفيذ الأجهزة تستخدم وسائط قابلة للإزالة لواجهات برمجة التطبيقات الخاصة بوحدة التخزين الخارجية. وبما أنّ ذلك سيجعل الوسائط غير قابلة للقراءة بواسطة الكمبيوتر المضيف، يجب أن تتضمّن عمليات تنفيذ الأجهزة إمكانية التبديل إلى بروتوكول نقل الوسائط (MTP) أو نظام مشابه لتوفير إمكانية وصول أجهزة الكمبيوتر المضيفة إلى بيانات المستخدم الحالي.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية استخدام عدة مستخدمين، فإنّه بالنسبة إلى جميع المستخدمين باستثناء المستخدمين الذين تم إنشاؤهم خصيصًا لتشغيل مثيلَين متزامنين من التطبيق نفسه، يجب أن يستوفوا ما يلي:

[C-2-1] يجب أن تتضمّن مساحات تخزين منفصلة ومعزولة للتطبيقات المشترَكة (المعروفة أيضًا باسم /sdcard) لكل مثيل مستخدم.
[C-2-2] يجب التأكّد من أنّ التطبيقات التي يملكها مستخدم معيّن ويتم تشغيلها نيابةً عنه لا يمكنها عرض الملفات التي يملكها أي مستخدم آخر أو قراءتها أو الكتابة فيها، حتى إذا تم تخزين بيانات كلا المستخدمَين على وحدة تخزين أو نظام ملفات واحد.

يمكن أن تنشئ عمليات تنفيذ الأجهزة ملفًا شخصيًا إضافيًا واحدًا للمستخدم من النوع android.os.usertype.profile.CLONE مقابل المستخدم الأساسي (ومقابل المستخدم الأساسي فقط) بغرض تشغيل مثيلَين مزدوجَين للتطبيق نفسه. وتتشارك هذه المثيلات المزدوجة مساحة تخزين معزولة جزئيًا، ويتم عرضها للمستخدم النهائي في مشغّل التطبيقات في الوقت نفسه، كما تظهر في طريقة العرض نفسها للتطبيقات الحديثة. على سبيل المثال، يمكن استخدام ذلك للسماح للمستخدم بتثبيت نسختَين منفصلتَين من تطبيق واحد على جهاز مزوّد بشريحتَي SIM.

إذا كانت عمليات تنفيذ الأجهزة تنشئ ملف مستخدم إضافيًا كما هو موضّح أعلاه، يجب أن:

[C-3-1] يجب ألا يوفّر الملف الشخصي الإضافي للمستخدم إمكانية الوصول إلا إلى مساحة التخزين أو البيانات التي يمكن أن يصل إليها ملف المستخدم الرئيسي أو التي يملكها هذا الملف الشخصي الإضافي للمستخدم مباشرةً.
[C-3-2] يجب ألا يكون هذا الملف هو ملف العمل.
[C-3-3] يجب أن تتضمّن أدلة بيانات التطبيقات الخاصة المعزولة من حساب المستخدم الرئيسي.
[C-3-4] يجب عدم السماح بإنشاء ملف مستخدم إضافي إذا تم توفير "مالك الجهاز" (راجِع القسم 3.9.1) أو السماح بتوفير "مالك الجهاز" بدون إزالة ملف المستخدم الإضافي أولاً.

إذا كانت عمليات تنفيذ الأجهزة تنشئ ملف مستخدم إضافيًا كما هو موضّح أعلاه، يجب أن:

[C-4-1] يجب السماح للتطبيقات الخاصة بالمستخدم الأساسي على الجهاز بمعالجة النوايا التالية الواردة من الملف الإضافي:
- Intent.ACTION_VIEW
- Intent.ACTION_SENDTO
- Intent.ACTION_SEND
- Intent.ACTION_EDIT
- Intent.ACTION_INSERT
- Intent.ACTION_INSERT_OR_EDIT
- Intent.ACTION_SEND_MULTIPLE
- Intent.ACTION_PICK
- Intent.ACTION_GET_CONTENT
- MediaStore.ACTION_IMAGE_CAPTURE
- MediaStore.ACTION_VIDEO_CAPTURE
[C-4-2] يجب أن يرث جميع قيود المستخدمين في سياسة الجهاز وrestrictions(list below) المحدّدة التي لا تخص المستخدمين والمطبّقة على المستخدم الأساسي للجهاز في ملف المستخدم الإضافي هذا.
[C-4-3] يجب السماح فقط بكتابة جهات الاتصال من هذا الملف الشخصي الإضافي من خلال الأغراض التالية:
[C-4-4] يجب ألا يتم تشغيل عمليات مزامنة جهات الاتصال للتطبيقات التي تعمل في ملف المستخدم الإضافي هذا.
[C-4-5] يجب ألا تسمح إلا للتطبيقات في الملف الإضافي التي تتضمّن نشاطًا خاصًا بمشغّل التطبيقات بالوصول إلى جهات الاتصال التي يمكن لملف المستخدم الرئيسي الوصول إليها.

إذا كانت عمليات تنفيذ الأجهزة تنشئ ملف المستخدم الإضافي المذكور أعلاه، وتتضمّن كاميرا واحدة على الأقل، وكان تطبيق الكاميرا المثبَّت مسبقًا يتعامل مع الأهداف MediaStore.ACTION_MOTION_PHOTO_CAPTURE أو MediaStore.ACTION_MOTION_PHOTO_CAPTURE_SECURE، يجب أن تستوفي ما يلي:

[C-5-1] يجب أن تسمح التطبيقات الخاصة بالمستخدم الأساسي بمعالجة هذه الأهداف الناشئة من ملف المستخدم الإضافي هذا.

‫9.6. تحذير بشأن الرسائل القصيرة برسوم إضافية

يتيح نظام التشغيل Android تحذير المستخدمين من أي رسالة قصيرة برسوم إضافية صادرة. الرسائل القصيرة برسوم إضافية هي رسائل نصية يتم إرسالها إلى خدمة مسجَّلة لدى مشغّل شبكة جوّال، وقد يتم تحصيل رسوم من المستخدم مقابلها.

إذا كانت عمليات تنفيذ الأجهزة تعلن عن توفّر android.hardware.telephony، عليها استيفاء ما يلي:

[C-1-1] يجب تحذير المستخدمين قبل إرسال رسالة SMS إلى أرقام محدّدة بتعبيرات عادية معرَّفة في ملف /data/misc/sms/codes.xml على الجهاز. يوفر "المشروع المفتوح المصدر لنظام Android" (AOSP) إصدارًا يستوفي هذا الشرط.

‫9.7. ميزات الأمان

يجب أن تضمن عمليات تنفيذ الأجهزة التوافق مع ميزات الأمان في كل من النواة والنظام الأساسي كما هو موضّح أدناه.

يتضمّن وضع الحماية في Android ميزات تستخدم نظام التحكّم الإلزامي في الوصول (MAC) المستند إلى Security-Enhanced Linux (SELinux)، ووضع الحماية seccomp، وميزات أمان أخرى في نواة Linux. عمليات تنفيذ الجهاز:

[C-0-1] يجب الحفاظ على التوافق مع التطبيقات الحالية، حتى عند تنفيذ SELinux أو أي ميزات أمان أخرى أسفل إطار عمل Android.
[C-0-2] يجب ألا تتضمّن واجهة مستخدم مرئية عند رصد انتهاك أمني وحظره بنجاح من خلال ميزة الأمان التي تم تنفيذها أسفل إطار عمل Android، ولكن يجوز أن تتضمّن واجهة مستخدم مرئية عند حدوث انتهاك أمني لم يتم حظره وأدّى إلى استغلال ناجح.
[C-0-3] يجب ألا يتم السماح للمستخدم أو مطوّر التطبيق بضبط إعدادات SELinux أو أي ميزات أمان أخرى تم تنفيذها أسفل إطار عمل Android.
[C-0-4] يجب ألا يسمح بتطبيق يمكنه التأثير في تطبيق آخر من خلال واجهة برمجة تطبيقات (مثل Device Administration API) بضبط سياسة تؤدي إلى عدم التوافق.
[C-0-5] يجب تقسيم إطار عمل الوسائط إلى عمليات متعددة حتى يمكن منح إذن الوصول لكل عملية بشكل أكثر تحديدًا على النحو الموضّح في موقع "مشروع Android المفتوح المصدر".
‫[C-0-6] يجب تنفيذ آلية حماية التطبيقات في النواة تسمح بفلترة طلبات النظام باستخدام سياسة قابلة للإعداد من البرامج المتعددة مؤشرات الترابط. يستوفي مشروع Android المفتوح المصدر هذا الشرط من خلال تفعيل seccomp-BPF مع مزامنة مجموعة سلاسل العمليات (TSYNC) على النحو الموضّح في قسم "إعدادات النواة" من source.android.com.

تُعد ميزات سلامة النواة والحماية الذاتية جزءًا لا يتجزأ من أمان Android. عمليات تنفيذ الجهاز:

‫[C-0-7] يجب تنفيذ آليات الحماية من فائض سعة المخزن المؤقت لمكدس النواة. ومن الأمثلة على هذه الآليات CC_STACKPROTECTOR_REGULAR وCONFIG_CC_STACKPROTECTOR_STRONG.
[C-0-8] يجب تنفيذ إجراءات حماية صارمة لذاكرة النواة، بحيث يكون الرمز القابل للتنفيذ للقراءة فقط، والبيانات للقراءة فقط غير قابلة للتنفيذ وغير قابلة للكتابة، والبيانات القابلة للكتابة غير قابلة للتنفيذ (على سبيل المثال، يجب تفعيل كل من rodata وCONFIG_STRICT_KERNEL_RWX).
[C-0-9] يجب تنفيذ عملية التحقّق من الحدود الثابتة والديناميكية لحجم العناصر التي يتم نسخها بين مساحة المستخدم ومساحة النواة (مثل CONFIG_HARDENED_USERCOPY) على الأجهزة التي تم شحنها في الأصل مع مستوى واجهة برمجة التطبيقات 28 أو إصدار أحدث.
[C-0-10] يجب عدم تنفيذ مساحة تخزين في مساحة المستخدم عند التنفيذ في وضع النواة (على سبيل المثال، PXN للأجهزة أو المحاكي من خلال CONFIG_CPU_SW_DOMAIN_PAN أو CONFIG_ARM64_SW_TTBR0_PAN) على الأجهزة التي تم شحنها في الأصل بالمستوى 28 لواجهة برمجة التطبيقات أو أعلى.
[C-0-11] يجب عدم قراءة أو كتابة بيانات في مساحة ذاكرة المستخدم في النواة خارج واجهات برمجة التطبيقات العادية للوصول إلى usercopy (مثل PAN للأجهزة أو المحاكي عبر CONFIG_CPU_SW_DOMAIN_PAN أو CONFIG_ARM64_SW_TTBR0_PAN) على الأجهزة التي تم شحنها في الأصل بمستوى واجهة برمجة التطبيقات 28 أو أعلى.
[C-0-12] يجب تنفيذ ميزة "عزل جداول صفحات النواة" إذا كان الجهاز عرضة للثغرة الأمنية CVE-2017-5754 على جميع الأجهزة التي تم شحنها في الأصل مع المستوى 28 من واجهة برمجة التطبيقات أو مستوى أعلى (مثل CONFIG_PAGE_TABLE_ISOLATION أو CONFIG_UNMAP_KERNEL_AT_EL0).
[C-0-13] يجب تنفيذ إجراءات تقوية التنبؤ بالتفرّع إذا كان الجهاز عرضة للثغرة CVE-2017-5715 على جميع الأجهزة التي تم شحنها في الأصل مع المستوى 28 لواجهة برمجة التطبيقات أو أعلى (مثل CONFIG_HARDEN_BRANCH_PREDICTOR).
[C-SR-1] يُنصح بشدة بإبقاء بيانات النواة التي تتم كتابتها فقط أثناء عملية الإعداد، مع وضع علامة القراءة فقط عليها بعد عملية الإعداد (مثلاً، __ro_after_init).
[C-SR-2] يُنصح بشدة بتوزيع تخطيط رمز النواة والذاكرة بشكل عشوائي، وتجنُّب التعرض لأي مخاطر قد تؤدي إلى اختراق التوزيع العشوائي (مثل CONFIG_RANDOMIZE_BASE مع إنتروبيا برنامج التحميل عبر /chosen/kaslr-seed Device Tree node أو EFI_RNG_PROTOCOL).
[C-SR-3] يُنصح بشدة بتفعيل ميزة "سلامة تدفق التحكّم" (CFI) في النواة لتوفير حماية إضافية ضد هجمات إعادة استخدام الرموز البرمجية (مثل CONFIG_CFI_CLANG وCONFIG_SHADOW_CALL_STACK).
[C-SR-4] يُنصح بشدة بعدم إيقاف ميزة "التحقّق من سلامة تدفق التحكّم" (CFI) أو ميزة "مكدّس استدعاء الظل" (SCS) أو ميزة "تنظيف تجاوز سعة الأعداد الصحيحة" (IntSan) في المكوّنات التي تم تفعيلها فيها.
[C-SR-5] يُنصح بشدة بتفعيل ميزات CFI وSCS وIntSan لأي مكونات إضافية في مساحة المستخدم حساسة للأمان، كما هو موضّح في CFI وIntSan.
[C-SR-6] يُنصح بشدة بتفعيل عملية إعداد الحزمة في النواة لمنع استخدام المتغيرات المحلية غير المهيأة (CONFIG_INIT_STACK_ALL أو CONFIG_INIT_STACK_ALL_ZERO). ويجب أيضًا ألا تفترض عمليات تنفيذ الأجهزة القيمة التي يستخدمها المترجم البرمجي لتهيئة المتغيرات المحلية.
[C-SR-7] يُنصح بشدة بتفعيل عملية إعداد الذاكرة المؤقتة في النواة لمنع استخدام عمليات تخصيص الذاكرة المؤقتة غير المعدّة (CONFIG_INIT_ON_ALLOC_DEFAULT_ON)، ويجب عدم افتراض القيمة التي تستخدمها النواة لإعداد عمليات التخصيص هذه.

إذا كانت عمليات تنفيذ الأجهزة تستخدم نواة Linux يمكنها توفير دعم SELinux، فإنّها:

[C-1-1] يجب تنفيذ SELinux.
[C-1-2] يجب ضبط SELinux على وضع التنفيذ العام.
[C-1-3] يجب ضبط جميع النطاقات في وضع التنفيذ. لا يُسمح بأي نطاقات في الوضع المتساهل، بما في ذلك النطاقات الخاصة بجهاز أو مورّد.

[C-1-4] يجب عدم:
- تعديل قواعد neverallow المتوفّرة في مجلد system/sepolicy أو حذفها أو استبدالها، والمقدَّمة في مشروع Android مفتوح المصدر (AOSP) الأساسي
- تنفيذ عمليات غير AOSP (مثل الخدمات الخاصة بالمورّدين أو مصنّعي التصميم الأصليين) في نطاقات SELinux الخاصة بنظام التشغيل AOSP (النطاقات التي تحتوي على السمة coredomain)
- ضع تصنيفًا لأنواع SELinux الخاصة بمنصة AOSP (الأنواع التي لا تتضمّن السمتَين vendor_file_type أو odm_file_type) على الملفات أو الأدلة غير التابعة لمشروع AOSP (مثل تلك الموجودة في الأقسام /vendor أو /odm).
- تعيين سياقات الخصائص المحدّدة في AOSP لخصائص النظام الخاصة بالمورّد أو الشركة المصنّعة للتصميم الأصلي (ODM)
يجب أن تتوافق السياسة مع جميع قواعد neverallow المتوفّرة لكل من نطاقات SELinux في AOSP والنطاقات الخاصة بالجهاز أو المورّد.

[C-1-5] يجب تشغيل التطبيقات التابعة لجهات خارجية التي تستهدف مستوى واجهة برمجة التطبيقات 28 أو أعلى في بيئات وضع الحماية SELinux لكل تطبيق مع فرض قيود SELinux على كل تطبيق في دليل البيانات الخاصة بكل تطبيق.
يجب الاحتفاظ بسياسة SELinux التلقائية المتوفّرة في المجلد system/sepolicy في مشروع Android المفتوح المصدر، وإضافة المزيد إلى هذه السياسة فقط لتوفير إعدادات خاصة بالجهاز.

في حال استخدام عمليات تنفيذ الأجهزة لنواة أخرى غير Linux أو Linux بدون SELinux، يجب استيفاء ما يلي:

[C-2-1] يجب استخدام نظام تحكّم إلزامي في الوصول يكون مكافئًا لنظام SELinux.

إذا كانت عمليات تنفيذ الأجهزة تستخدم أجهزة إدخال/إخراج يمكنها الوصول المباشر إلى الذاكرة، يجب أن تستوفي ما يلي:

[C-SR-9] يُنصح بشدة بعزل كل جهاز إدخال/إخراج قادر على الوصول المباشر إلى الذاكرة (DMA)، باستخدام وحدة إدارة الإدخال/الإخراج (IOMMU) (مثل ARM SMMU).

يتضمّن Android ميزات متعددة للدفاع العميق تشكّل جزءًا لا يتجزأ من أمان الجهاز. بالإضافة إلى ذلك، يركّز Android على الحدّ من الفئات الرئيسية للأخطاء الشائعة التي تساهم في رداءة الجودة والأمان.

للحدّ من أخطاء الذاكرة، يجب أن تتضمّن عمليات تنفيذ الأجهزة ما يلي:

[C-SR-10] يُنصح بشدة باختبارها باستخدام أدوات رصد أخطاء الذاكرة في مساحة المستخدم، مثل MTE لأجهزة ARMv9 أو HWASan لأجهزة ARMv8+ أو ASan لأنواع الأجهزة الأخرى.
[C-SR-11] يُنصح بشدة باختبارها باستخدام أدوات رصد أخطاء ذاكرة النواة، مثل KASAN (CONFIG_KASAN وCONFIG_KASAN_HW_TAGS لأجهزة ARMv9 وCONFIG_KASAN_SW_TAGS لأجهزة ARMv8 أو CONFIG_KASAN_GENERIC لأنواع الأجهزة الأخرى).
[C-SR-12] يُنصح بشدة باستخدام أدوات رصد أخطاء الذاكرة، مثل MTE وGWP-ASan وKFENCE، في مرحلة الإنتاج.

في حال استخدام عمليات تنفيذ الأجهزة لبيئة تنفيذ موثوقة (TEE) تستند إلى Arm TrustZone، يجب أن تستوفي ما يلي:

[C-SR-13] يُنصح بشدة باستخدام بروتوكول عادي لمشاركة الذاكرة بين Android وبيئة التنفيذ الموثوقة (TEE)، مثل Arm Firmware Framework for Armv8-A (FF-A).
[C-SR-14] يُنصح بشدة بتقييد التطبيقات الموثوق بها بحيث لا يمكنها الوصول إلا إلى الذاكرة التي تمت مشاركتها معها بشكل صريح من خلال البروتوكول المذكور أعلاه. إذا كان الجهاز يتيح مستوى استثناء Arm S-EL2، يجب أن يفرضه مدير القسم الآمن. وفي ما عدا ذلك، يجب أن يفرض نظام التشغيل TEE هذا الإجراء.

تتضمّن تكنولوجيا "أمان الذاكرة" تكنولوجيا تقلّل من احتمالية حدوث فئات الأخطاء التالية بنسبة عالية (> 90%) في التطبيقات التي تستخدم خيار البيان android:memtagMode:

فائض سعة المخزن المؤقت في الذاكرة الرئيسية
استخدام بعد انتهاء الفترة المجانية
تحرير مزدوج
wild free (free of a non-malloc pointer)

عمليات تنفيذ الجهاز:

[C-SR-15] يُنصح بشدة بضبط ro.arm64.memtag.bootctl_supported.

في حال ضبط عمليات تنفيذ الأجهزة لسمة النظام ro.arm64.memtag.bootctl_supported على "صحيح"، يجب أن تستوفي ما يلي:

[C-3-1] يجب أن تسمح السمة arm64.memtag.bootctl بقبول قائمة قيم مفصولة بفاصلة للقيم التالية، مع تطبيق التأثير المطلوب عند إعادة التشغيل التالية:
- memtag: تم تفعيل إحدى تكنولوجيات أمان الذاكرة الموضّحة أعلاه
- ‫memtag-once: تم تفعيل إحدى تقنيات "أمان الذاكرة" المحدّدة أعلاه بشكل مؤقت، ويتم إيقافها تلقائيًا عند إعادة التشغيل التالية
- ‫memtag-off: تم إيقاف تكنولوجيا "أمان الذاكرة" على النحو المحدّد أعلاه
‫[C-3-2] يجب أن تسمح واجهة المستخدم للمستخدم بتعيين arm64.memtag.bootctl.
[C-3-3] يجب السماح لأي عملية بقراءة arm64.memtag.bootctl.
[C-3-4] يجب ضبط arm64.memtag.bootctl على الحالة المطلوبة حاليًا عند بدء التشغيل، ويجب أيضًا تعديل السمة إذا كان تنفيذ الجهاز يسمح بتعديل الحالة بدون تغيير سمة النظام.
[C-SR-16] يُنصح بشدة بعرض إعدادات المطوّرين التي تضبط memtag-once وتعيد تشغيل الجهاز. باستخدام برنامج إقلاع متوافق، يستوفي مشروع مفتوح المصدر لنظام Android المتطلبات أعلاه من خلال بروتوكول برنامج إقلاع MTE.

إذا كان الجهاز يعرّف android.hardware.telephony، ويتوافق مع إمكانية الراديو CAPABILITY_USES_ALLOWED_NETWORK_TYPES_BITMASK، ويتضمّن مودمًا خلويًا متوافقًا مع اتصالات الجيل الثاني، يجب أن يتضمّن تنفيذ الجهاز ما يلي:

[C-SR-17] يُنصح بشدة بتوفير إمكانية للمستخدمين لإيقاف شبكة الجيل الثاني (2G) وتفعيلها.
[C-SR-18] يُنصح بشدة بعدم تجاهل إمكانية إيقاف شبكة الجيل الثاني وتفعيلها من خلال أي كيان جهاز آخر باستثناء مشرف الجهاز باستخدام UserManager.DISALLOW_CELLULAR_2G.
[C-SR-19] يُنصح بشدة بإجراء مكالمة إلى TelephonyManager.setAllowedNetworkTypesForReason مع ذكر السبب ALLOWED_NETWORK_TYPES_REASON_ENABLE_2G لتحقيق هذا المطلب.
[C-SR-20] يُنصح بشدة بتحديد ما إذا كان مودم شبكة الجوّال يتيح استخدام شبكة الجيل الثاني من خلال الاتصال بالرقم TelephonyManager.getSupportedRadioAccessFamily. لمزيد من التفاصيل، يُرجى الاطّلاع على مقالة إيقاف شبكة الجيل الثاني (2G).

‫9.8. الخصوصية

‫9.8.1. سجلّ الاستخدام

يخزِّن نظام التشغيل Android سجلّ خيارات المستخدم ويديره من خلال UsageStatsManager.

عمليات تنفيذ الجهاز:

[C-0-1] يجب الحفاظ على فترة تخزين معقولة لسجلّ المستخدم هذا.
[C-SR-1] يُنصح بشدة بالاحتفاظ بفترة الاحتفاظ بالبيانات لمدة 14 يومًا كما هو محدّد تلقائيًا في تطبيق AOSP.

يخزِّن نظام التشغيل Android أحداث النظام باستخدام StatsLog المعرّفات، ويدير هذا السجلّ من خلال StatsManager وواجهة برمجة التطبيقات IncidentManager للنظام.

عمليات تنفيذ الجهاز:

[C-0-2] يجب أن يتضمّن فقط الحقول التي تم وضع علامة DEST_AUTOMATIC عليها في بلاغ عن حادثة الذي تم إنشاؤه بواسطة فئة System API IncidentManager.
[C-0-3] يجب عدم استخدام معرّفات أحداث النظام لتسجيل أي حدث آخر غير ما هو موضح في مستندات StatsLog حزمة تطوير البرامج (SDK). إذا تم تسجيل أحداث نظام إضافية، يجوز أن تستخدم معرّف عنصر مختلفًا في النطاق بين 100,000 و200,000.

‫9.8.2. جارٍ التسجيل

عمليات تنفيذ الجهاز:

[C-0-1] يجب عدم تحميل مكوّنات البرامج مسبقًا أو توزيعها خارج الصندوق إذا كانت ترسل المعلومات الخاصة بالمستخدم (مثل ضغطات المفاتيح والنص المعروض على الشاشة وتقرير الأخطاء) إلى خارج الجهاز بدون موافقة المستخدم أو بدون إشعارات واضحة ومستمرة.
[C-0-2] يجب عرض تحذير للمستخدم والحصول على موافقة صريحة منه للسماح بتسجيل أي معلومات حساسة معروضة على شاشة المستخدم في كل مرة يتم فيها تفعيل جلسة لتسجيل الشاشة أو بثها من خلال MediaProjection.createVirtualDisplay() أو واجهات برمجة التطبيقات الخاصة.
[C-0-3] يجب عرض إشعار مستمر للمستخدم أثناء تفعيل ميزة مشاركة الشاشة أو تسجيلها. يستوفي AOSP هذا الشرط من خلال عرض رمز إشعار بنشاط مستمر في الخلفية في شريط الحالة.
[C-SR-1] يُنصح بشدة بعرض تحذير للمستخدم يتضمّن الرسالة نفسها تمامًا التي تم تنفيذها في AOSP، ولكن يمكن تغييرها طالما أنّ الرسالة تحذّر المستخدم بوضوح من أنّه يتم تسجيل أي معلومات حساسة تظهر على شاشة المستخدم.
[C-0-4] تمت إزالة هذا الشرط في Android 16.

عمليات تنفيذ الجهاز:

[C-0-7] يجب عدم تسجيل أو عرض أو بث معلومات حساسة، مثل:
- محتوى الإشعارات الحسّاسة المُدرَج في الفقرة 3.8.3.4 "حماية الإشعارات الحسّاسة"
- نوافذ نشاط التطبيق التي تحتوي على كلمات مرور صالحة لمرة واحدة
- المحتوى الحسّاس، مثل اسم المستخدم وكلمة المرور ومعلومات بطاقة الائتمان

إذا كانت عمليات تنفيذ الأجهزة تتضمّن وظائف في النظام تعمل على التقاط المحتوى المعروض على الشاشة و/أو تسجيل بث الصوت الذي يتم تشغيله على الجهاز بطريقة أخرى غير System API ContentCaptureService، أو أي وسائل خاصة أخرى موضّحة في القسم 9.8.6 بيانات على مستوى نظام التشغيل والبيانات المحيطة، يجب أن تستوفي ما يلي:

[C-1-1] يجب عرض إشعار بنشاط مستمر في الخلفية للمستخدم عند تفعيل هذه الوظيفة وعندما تكون عملية التسجيل أو الالتقاط نشطة.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مكونًا مفعَّلاً فور إخراجه من العلبة، وقادرًا على تسجيل الصوت المحيط و/أو تسجيل الصوت الذي يتم تشغيله على الجهاز لاستنتاج معلومات مفيدة حول سياق المستخدم، يجب أن تستوفي ما يلي:

[C-2-1] يجب عدم تخزين الصوت الخام المسجَّل أو أي تنسيق يمكن تحويله مرة أخرى إلى الصوت الأصلي أو نسخة طبق الأصل تقريبًا في وحدة تخزين دائمة على الجهاز فقط أو إرساله خارج الجهاز، إلا بموافقة المستخدم الصريحة.

يشير "مؤشر الميكروفون" إلى طريقة عرض على الشاشة تكون مرئية باستمرار للمستخدم ولا يمكن حجبها، ويفهم المستخدمون منها أنّ الميكروفون قيد الاستخدام(من خلال نص أو لون أو رمز فريد أو مزيج من هذه العناصر).

يشير "مؤشر الكاميرا" إلى طريقة عرض على الشاشة تكون مرئية باستمرار للمستخدم ولا يمكن حجبها، ويفهم المستخدمون أنّ الكاميرا قيد الاستخدام (من خلال نص أو لون أو رمز فريد أو مزيج من هذه العناصر).

بعد عرض الثانية الأولى، يمكن أن يتغيّر المؤشر بصريًا، مثلاً، يصبح أصغر، وليس مطلوبًا أن يظهر كما تم عرضه وفهمه في الأصل.

يمكن دمج مؤشر الميكروفون مع مؤشر الكاميرا المعروض بشكل نشط، بشرط أن تشير النصوص أو الرموز أو الألوان إلى المستخدم بأنّه قد بدأ استخدام الميكروفون.

قد يتم دمج مؤشر الكاميرا مع مؤشر الميكروفون المعروض بشكل نشط، بشرط أن تشير النصوص أو الرموز أو الألوان إلى المستخدم بأنّه قد بدأ استخدام الكاميرا.

إذا كانت عمليات تنفيذ الأجهزة تعرّف android.hardware.microphone، فإنّها:

[C-SR-1] يُنصح بشدة بعرض مؤشر الميكروفون عندما يصل تطبيق إلى بيانات الصوت من الميكروفون، ولكن ليس عندما يصل إلى الميكروفون فقط "HotwordDetectionService" أو "SOURCE_HOTWORD" أو "ContentCaptureService" أو التطبيقات التي لديها الأدوار المحدّدة في القسم 9.1 "الأذونات" مع معرّف توافق تعريف الجهاز [C-3-X].
[C-SR-2] يُنصح بشدة بعرض قائمة التطبيقات الحديثة والنشطة التي تستخدم الميكروفون، وذلك وفقًا لما تم إرجاعه من PermissionManager.getIndicatorAppOpUsageData()، بالإضافة إلى أي رسائل تحديد مصدر مرتبطة بها.
[C-SR-3] يُنصح بشدة بعدم إخفاء مؤشر الميكروفون للتطبيقات التابعة للنظام التي تتضمّن واجهات مستخدم مرئية أو تتطلّب تفاعلاً مباشرًا من المستخدم.

إذا كانت عمليات تنفيذ الأجهزة تعرّف android.hardware.camera.any، فإنّها:

[C-SR-4] يُنصح بشدة بعرض مؤشر استخدام الكاميرا عندما يصل تطبيق إلى بيانات الكاميرا المباشرة، ولكن ليس عندما تصل تطبيقات تحمل الأدوار المحددة في القسم 9.1 "الأذونات" مع معرّف CDD [C-3-X] إلى الكاميرا فقط.
[C-SR-5] يُنصح بشدة بعرض التطبيقات الحديثة والنشطة التي تستخدم الكاميرا كما هو معروض من PermissionManager.getIndicatorAppOpUsageData()، بالإضافة إلى أي رسائل تحديد مصدر مرتبطة بها.
[C-SR-6] يُنصح بشدة بعدم إخفاء مؤشر الكاميرا للتطبيقات التابعة للنظام التي تتضمّن واجهات مستخدم مرئية أو تتطلّب تفاعلاً مباشرًا من المستخدم.

‫9.8.3. إمكانية الاتصال

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB يتيح وضع الجهاز الطرفي USB، يجب أن تستوفي ما يلي:

[C-1-1] يجب عرض واجهة مستخدم تطلب موافقة المستخدم قبل السماح بالوصول إلى محتوى وحدة التخزين المشتركة عبر منفذ USB.

‫9.8.4. حركة بيانات الشبكة

عمليات تنفيذ الجهاز:

[C-0-1] يجب أن يتم تثبيت مسبقًا لشهادات الجذر نفسها في متجر مراجع التصديق (CA) الموثوق بها من النظام، كما هو موضّح في مشروع Android مفتوح المصدر.
[C-0-2] يجب أن يتم شحن الجهاز مع متجر فارغ لمراجع التصديق الجذرية الخاصة بالمستخدم.
[C-0-3] يجب عرض تحذير للمستخدم يشير إلى أنّه قد تتم مراقبة حركة بيانات الشبكة، وذلك عند إضافة شهادة مرجع تصديق جذر خاصة بالمستخدم.

إذا تم توجيه حركة بيانات الجهاز من خلال شبكة VPN، ستكون عمليات تنفيذ الجهاز على النحو التالي:

[C-1-1] يجب عرض تحذير للمستخدم يشير إلى أحد الخيارَين التاليَين:
- قد يتم رصد حركة بيانات الشبكة هذه.
- يتم توجيه حركة بيانات الشبكة هذه من خلال تطبيق VPN المحدّد الذي يوفّر شبكة VPN.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن آلية مفعَّلة تلقائيًا عند إخراج الجهاز من العلبة، وتعمل على توجيه زيارات بيانات الشبكة عبر خادم وكيل أو بوابة شبكة VPN (على سبيل المثال، التحميل المُسبَق لخدمة VPN مع منح الإذن android.permission.CONTROL_VPN)، يجب أن تستوفي ما يلي:

[C-2-1] يجب طلب موافقة المستخدم قبل تفعيل هذه الآلية، إلا إذا تم تفعيل شبكة VPN من خلال "وحدة التحكّم في سياسة الجهاز" باستخدام DevicePolicyManager.setAlwaysOnVpnPackage()، وفي هذه الحالة، لا يحتاج المستخدم إلى تقديم موافقة منفصلة، ولكن يجب إعلامه فقط.

إذا كانت عمليات تنفيذ الأجهزة توفّر للمستخدمين إمكانية تفعيل وظيفة "شبكة VPN قيد التشغيل دائمًا" في تطبيق شبكة VPN تابع لجهة خارجية، يجب أن تستوفي ما يلي:

[C-3-1] يجب إيقاف إمكانية استخدام هذه الميزة للتطبيقات التي لا تتوافق مع خدمة "شبكة VPN دائمة التشغيل" في ملف AndroidManifest.xml من خلال ضبط السمة SERVICE_META_DATA_SUPPORTS_ALWAYS_ON على false.

‫9.8.5. معرّفات الأجهزة

عمليات تنفيذ الجهاز:

[C-0-1] يجب منع التطبيقات من الوصول إلى الرقم التسلسلي للجهاز، ورقم IMEI/MEID، والرقم التسلسلي لشريحة SIM، ومعرّف المشترك الدولي في خدمات الجوّال (IMSI)، حيثما ينطبق ذلك، ما لم يستوفِ أحد المتطلبات التالية:
- هو تطبيق مشغّل شبكة جوّال موقَّع تم التحقّق منه من قِبل الشركات المصنّعة للأجهزة.
- تم منحها الإذن READ_PRIVILEGED_PHONE_STATE.
- يتمتّع بامتيازات مشغّل شبكة الجوّال على النحو المحدّد في امتيازات مشغّل شبكة الجوّال في بطاقة UICC.
- أن يكون مالك جهاز أو مالك ملف شخصي تم منحه إذن READ_PHONE_STATE.
- (لرقم تسلسلي لبطاقة SIM أو رقم ICCID فقط) يجب أن يستوفي متطلبات اللوائح التنظيمية المحلية التي تفرض على التطبيق رصد التغييرات في هوية المشترك.

‫9.8.6. أداة الحماية على مستوى نظام التشغيل والبيانات المحيطة

يتيح نظام التشغيل Android، من خلال واجهات برمجة التطبيقات الخاصة بالنظام، آلية تتيح عمليات تنفيذ الأجهزة تسجيل البيانات الحساسة التالية:

النصوص والرسومات المعروضة على الشاشة، بما في ذلك على سبيل المثال لا الحصر، الإشعارات وبيانات المساعدة من خلال AssistStructure APIوأنشطة التقاط مخزن الشاشة وتسجيل محتوى شاشة الجهاز
بيانات الوسائط، مثل الصوت أو الفيديو، التي يسجّلها الجهاز أو يشغّلها
أحداث الإدخال (مثل المفاتيح والماوس والإيماءات والصوت والفيديو وتسهيل الاستخدام)
أي شاشة أو بيانات أخرى يتم إرسالها عبر AugmentedAutofillService إلى النظام
أي شاشة أو بيانات أخرى يمكن الوصول إليها من خلال واجهات برمجة التطبيقات Content Capture
أي بيانات تطبيقات يتم تمريرها إلى النظام من خلال واجهة برمجة التطبيقات AppSearchManager ويمكن الوصول إليها من خلال AppSearchGlobalManager.query
أي نص أو بيانات أخرى يتم إرسالها عبر TextClassifier API إلى خدمة System TextClassifier، أي إلى خدمة تابعة لنظام التشغيل لفهم معنى النص، بالإضافة إلى إنشاء الإجراءات التالية المتوقّعة استنادًا إلى النص.
البيانات التي يتم فهرستها من خلال تنفيذ AppSearch على المنصة، بما في ذلك على سبيل المثال لا الحصر، النصوص أو الرسومات أو بيانات الوسائط أو البيانات المشابهة الأخرى
البيانات الصوتية التي يتم الحصول عليها نتيجة استخدام SpeechRecognizer#onDeviceSpeechRecognizer() من خلال تنفيذ أداة التعرّف على الكلام.
بيانات الصوت التي يتم الحصول عليها في الخلفية (بشكل مستمر) من خلال AudioRecord أو SoundTrigger أو واجهات برمجة تطبيقات أخرى خاصة بالصوت، ولا تؤدي إلى ظهور مؤشر مرئي للمستخدم
بيانات الكاميرا التي يتم الحصول عليها في الخلفية (بشكل مستمر) من خلال CameraManager أو واجهات برمجة تطبيقات أخرى خاصة بالكاميرا، ولا تؤدي إلى ظهور مؤشر مرئي للمستخدم

أي بيانات يتم تسجيلها من خلال DynamicInstrumentationEventService

إذا كانت عمليات تنفيذ الأجهزة تجمع أو تشارك أيًا من البيانات الحسّاسة المذكورة أعلاه، عليها: بدون إشارة واضحة ومستقلة إلى نية المستخدم أو مؤشر خصوصية مرئي للمستخدم، يجب معالجة البيانات في بيئة تنفيذ محمية. هذه البيئة:

[C-1-1] يجب تشفير جميع هذه البيانات عند تخزينها في الجهاز أو أثناء نقلها. يمكن إجراء هذا التشفير باستخدام ميزة "التشفير المستند إلى الملفات" في نظام Android أو أي من برامج التشفير المُدرَجة على أنّها الإصدار 26 من واجهة برمجة التطبيقات أو الإصدارات الأحدث كما هو موضّح في Cipher SDK.
[C-1-2] يجب عدم الاحتفاظ بنسخة احتياطية من البيانات الأولية أو المشفرة باستخدام الاحتفاظ بنسخة احتياطية من البيانات في جهاز Android أو أي طرق أخرى للاحتفاظ بنسخة احتياطية للبيانات الحسّاسة، كما هو موضّح أعلاه.

[C-1-3] يجب عدم إرسال هذه البيانات خارج الجهاز إلا في إحدى الحالات التالية:
- عندما يبدأ المستخدم بشكل صريح في إجراء عملية حسابية معيّنة ^* في كل مرة تتم فيها مشاركة البيانات.
- عند استخدام آلية للحفاظ على الخصوصية، مثل تقنيات الخصوصية التفاضلية، مثل RAPPOR أو الحسابات الموحَّدة السرية
- عند معالجة البيانات في بيئة تنفيذ محمية تحميها من مقدّم الخدمة والبنية الأساسية، مثل عدم توفّر إذن وصول للمشرف، والجهاز الافتراضي السري، وإثبات صحة البيانات عن بُعد، وعدم إمكانية نقل البيانات الخاصة، وإيقاف التسجيل، وإخفاء عنوان IP، والتشفير
  - يجب أن يوفّر أي تنفيذ يستخدم هذه الطريقة وسيلة للمستخدمين لإيقافها.

[C-1-3] يجوز معالجة البيانات من خلال بيئة سحابية أساسية موثوقة للحوسبة تحميها من مقدّم الخدمة والبنية الأساسية (على سبيل المثال، عدم توفّر إذن وصول للمشرف، وآلة افتراضية سرية، وإثبات صحة عن بُعد، وعدم إرسال البيانات الخاصة، وإيقاف التسجيل، وإخفاء عنوان IP، والتشفير). أي عملية تنفيذ تستخدم هذه الطريقة:
- يجب توفير وسيلة للمستخدمين لإيقاف الميزة، و
- يجب توفير طريقة للمستخدمين لإنشاء سجلّات شاملة يسهل الوصول إليها وتوضّح بالتفصيل عملية إدخال البيانات وإخراجها من البيئة.

[C-1-4] يجب عدم ربط هذه البيانات بأي هوية مستخدم (مثل Account) على الجهاز، إلا بموافقة المستخدم الصريحة في كل مرة يتم فيها الربط.

[C-1-4] يجوز عرض هذه البيانات على مساحات عرض واجهة المستخدم التي يملكها النظام.

[C-1-5] يجب عدم مشاركة ربط هذه البيانات بأي هوية مستخدم (مثل Account)، إلا بموافقة المستخدم الصريحة في كل مرة تتم فيها المشاركة في كل مرة يتم فيها الربط، وإلا لن يتم نقل الربط إلى مكونات نظام التشغيل الأخرى التي لا تلتزم بالمتطلبات الموضّحة في القسم الحالي (‫9.8.6 البيانات على مستوى نظام التشغيل والبيانات المحيطة)، في كل مرة تتم فيها المشاركة. ما لم يتم إنشاء هذه الوظيفة كواجهة برمجة تطبيقات لحزمة تطوير البرامج (SDK) لنظام التشغيل Android (AmbientContext،HotwordDetectionService).
[C-1-6] يجب توفير وسيلة للمستخدمين لمحو هذه البيانات التي تجمعها عملية التنفيذ أو الوسائل الخاصة عند تخزين البيانات بأي شكل على الجهاز أو في بيئة السحابة الإلكترونية لقاعدة الحوسبة الموثوقة. إذا اختار المستخدم محو البيانات، يجب إزالة جميع البيانات السابقة التي تم جمعها.

[C-1-7] يجب توفير وسيلة للمستخدم لإيقاف عرض البيانات التي يتم جمعها من خلال AppSearch أو وسائل خاصة على منصة Android (مثل مشغّل التطبيقات).

[C-1-8] يجب توفير طريقة لإنشاء سجلّات شاملة وسهلة الاستخدام تتضمّن تفاصيل حول دخول البيانات إلى البيئة وخروجها منها.
[C-1-9] يجب ألا يكون لديه إمكانية الوصول المباشر إلى الإنترنت.
[C-1-10] يجوز عرض واجهة المستخدم عن بُعد ما دام أنّه لا يتم إظهار أي بيانات لحزمة APK المضيفة التي تعرض واجهة المستخدم.
[C-1-11] يجب إبقاء الخدمات منفصلة عن مكوّنات النظام الأخرى (على سبيل المثال، عدم ربط الخدمة أو مشاركة أرقام تعريف العمليات مع عمليات التنفيذ غير الموجودة في بيئة التنفيذ المحمية).
[C-1-12] يجب ألا يُسمح بمغادرة البيانات الحسّاسة إلا في الحالات التالية:
- أن يبدأ المستخدم عملية المشاركة بشكلٍ صريح* لإجراء عملية حسابية محدّدة في كل مرة تتم فيها مشاركة البيانات
- استخدام آلية للحفاظ على الخصوصية (مثل تقنيات الخصوصية التفاضلية، مثل RAPPOR أو الحسابات الموحّدة السرية)
[C-1-13] يجب ألا تسمح إلا باستخراج البيانات الحسّاسة من خلال:
- خدمة تابعة لنظام التشغيل مُدرَجة في القائمة المسموح بها في خدمة نظام PCCSandbox وتستوفي متطلبات بيئة التنفيذ المحمية (9.8.6)، أو
- حزمة APK لبوابة "نظام الحوسبة الخاصة" (PCC) المحدّدة (الموضّحة في الفقرة 9.8.15)
[C-1-14] يجب عدم إجراء عمليات احتياطية على السحابة الإلكترونية للبيانات المستنتَجة من البيانات الحسّاسة ما لم يتم تشفيرها بشكل تام بين الأطراف (على سبيل المثال، باستخدام Android Backup Service).

[C-SR-1] يُنصح بشدة بعدم طلب إذن الوصول إلى الإنترنت.
[C-SR-2] يُنصح بشدة بعدم الوصول إلى الإنترنت إلا من خلال واجهات برمجة التطبيقات المنظَّمة التي تستند إلى عمليات تنفيذ مفتوحة المصدر ومتاحة للجميع.
[C-SR-4] يُنصح بشدة بتنفيذها باستخدام واجهة برمجة التطبيقات (API) لحزمة تطوير البرامج (SDK) لنظام التشغيل Android أو مستودع مفتوح المصدر مشابه تملكه الشركة المصنّعة الأصلية للأجهزة (OEM)، و / أو تنفيذها في بيئة معزولة (راجِع القسم 9.8.15 حول عمليات تنفيذ Sandboxed API).

إذا كانت عمليات تنفيذ الأجهزة تتضمّن خدمة تنفّذ System API ContentCaptureService أو AppSearchManager.index أو DynamicInstrumentationEventService أو أي خدمة خاصة أخرى تجمع البيانات على النحو الموضّح أعلاه، يجب أن تستوفي ما يلي:

[C-2-1] يجب ألا تسمح الأجهزة للمستخدمين باستبدال الخدمات بتطبيق أو خدمة يمكن للمستخدم تثبيتها، ويجب أن تسمح فقط للخدمات المثبَّتة مسبقًا بجمع هذه البيانات.
[C-2-2] يجب ألا تسمح بأي تطبيقات أخرى غير آلية الخدمات المثبَّتة مسبقًا بالتقاط هذه البيانات.
[C-2-3] يجب توفير وسيلة واضحة وسهلة الاستخدام للمستخدم لإيقاف الخدمات.
[C-2-4] يجب عدم إغفال توفير وسائل تحكّم للمستخدمين لإدارة أذونات Android التي تحتفظ بها الخدمات، ويجب اتّباع نموذج أذونات Android كما هو موضّح في الفقرة 9.1. الإذن

[C-SR-3] يُنصح بشدة بإبقاء الخدمات منفصلة عن مكونات النظام الأخرى (على سبيل المثال، عدم ربط الخدمة أو مشاركة أرقام تعريف العمليات) باستثناء ما يلي:
- الاتصال الهاتفي وجهات الاتصال وواجهة مستخدم النظام والوسائط

‫9.8.7. الوصول إلى الحافظة

عمليات تنفيذ الجهاز:

[C-0-1] يجب عدم عرض بيانات مقتطعة من الحافظة (مثلاً، من خلال واجهة برمجة التطبيقات ClipboardManager ) ما لم يكن تطبيق الجهة الخارجية هو طريقة الإدخال التلقائية أو التطبيق الذي يتم التركيز عليه حاليًا.
[C-0-2] يجب محو بيانات الحافظة بعد 60 دقيقة على الأكثر من آخر مرة تم فيها وضع البيانات في الحافظة أو قراءتها منها.

‫9.8.8. الموقع الجغرافي

يتضمّن الموقع الجغرافي معلومات في فئة الموقع الجغرافي على Android( مثل خطوط الطول والعرض والارتفاع)، بالإضافة إلى المعرّفات التي يمكن تحويلها إلى موقع جغرافي. يمكن أن يكون الموقع الجغرافي دقيقًا مثل نظام تحديد المواقع العالمي التفاضلي (DGPS) أو غير دقيق مثل المواقع الجغرافية على مستوى البلد (مثل الموقع الجغرافي لرمز البلد - MCC - رمز البلد على الأجهزة الجوّالة).

في ما يلي قائمة بأنواع المواقع الجغرافية التي تستمد الموقع الجغرافي للمستخدم بشكل مباشر أو يمكن تحويلها إلى الموقع الجغرافي للمستخدم. هذه القائمة ليست شاملة، ولكن يجب استخدامها كمثال على المعلومات التي يمكن استنتاجها بشكل مباشر أو غير مباشر من الموقع الجغرافي:

نظام تحديد المواقع العالمي (GPS) / نظام GNSS/نظام DGPS/نظام PPP
- نظام تحديد المواقع العالمي أو نظام الملاحة العالمي عبر الأقمار الصناعية أو نظام تحديد المواقع العالمي التفاضلي
- ويشمل ذلك أيضًا "قياسات GNSS الأولية" و"حالة GNSS".
  - يمكن استخلاص الموقع الجغرافي الدقيق من قياسات GNSS الأولية
التقنيات اللاسلكية التي تتضمّن معرّفات فريدة، مثل:
- نقاط وصول Wi-Fi (عنوان MAC أو BSSID أو الاسم أو SSID)
- البلوتوث/BLE (عنوان MAC أو معرّف مجموعة الخدمات الأساسية (BSSID) أو الاسم أو معرّف مجموعة الخدمات (SSID))
- النطاق الفائق العرض (MAC أو BSSID أو الاسم أو SSID)
- معرّف برج الاتصالات (الجيل الثالث والرابع والخامس وما إلى ذلك، بما في ذلك جميع تقنيات مودم الاتصالات المستقبلية التي تتضمّن معرّفات فريدة)

للحصول على مرجع أساسي، اطّلِع على واجهات برمجة التطبيقات في Android التي تتطلّب أذونات ACCESS_FINE_Location أو ACCESS_COARSE_Location.

عمليات تنفيذ الجهاز:

[C-0-1] يجب عدم تفعيل/إيقاف إعدادات الموقع الجغرافي للجهاز وإعدادات البحث عن شبكات Wi-Fi/البلوتوث بدون موافقة صريحة من المستخدم أو بدون أن يبدأ المستخدم ذلك.
[C-0-2] يجب توفير أداة تحكّم للمستخدم تتيح له الوصول إلى المعلومات ذات الصلة بالموقع الجغرافي، بما في ذلك طلبات الموقع الجغرافي الأخيرة والأذونات على مستوى التطبيق واستخدام البحث عن شبكات Wi-Fi أو أجهزة البلوتوث لتحديد الموقع الجغرافي.
[C-0-3] يجب التأكّد من أنّ التطبيق الذي يستخدم واجهة برمجة التطبيقات Emergency Location Bypass API LocationRequest.setLocationSettingsIgnored() هو جلسة طوارئ بدأها المستخدم (مثل الاتصال بالرقم 911 أو إرسال رسالة نصية إلى الرقم 911). ومع ذلك، بالنسبة إلى Automotive، يجوز للمركبة بدء جلسة طوارئ بدون تفاعل المستخدم النشط في حال رصد حادث (مثل استيفاء متطلبات نظام eCall).
[C-0-4] يجب الحفاظ على إمكانية واجهات برمجة التطبيقات الخاصة بتجاوز إعدادات الموقع الجغرافي في حالات الطوارئ لتجاوز إعدادات الموقع الجغرافي للجهاز بدون تغيير الإعدادات.
[C-0-5] يجب جدولة إشعار لتذكير المستخدم بعد أن يصل تطبيق يعمل في الخلفية إلى بيانات موقعه الجغرافي باستخدام إذن ACCESS_BACKGROUND_LOCATION.

عندما يصل تطبيق غير تابع للنظام ويعمل في المقدّمة إلى الموقع الجغرافي الدقيق لجهاز، سيحدث ما يلي:

[C-SR-1] يُنصح بشدة بعرض مؤشر مرئي للمستخدم.

‫9.8.9. التطبيقات المثبّتة

لا يمكن لتطبيقات Android التي تستهدف المستوى 30 أو مستوى أعلى من واجهة برمجة التطبيقات الاطّلاع على تفاصيل حول التطبيقات الأخرى المثبَّتة بشكل تلقائي (راجِع إذن الوصول إلى الحِزم في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android).

عمليات تنفيذ الجهاز:

[C-0-1] يجب ألا يتم عرض تفاصيل أي تطبيق مثبّت آخر لأي تطبيق يستهدف المستوى 30 أو مستوى أعلى لواجهة برمجة التطبيقات، إلا إذا كان التطبيق قادرًا بالفعل على الاطّلاع على تفاصيل التطبيق المثبّت الآخر من خلال واجهات برمجة التطبيقات المُدارة. ويشمل ذلك، على سبيل المثال لا الحصر، التفاصيل التي تعرضها أي واجهات برمجة تطبيقات مخصّصة أضافها مطوّر الجهاز أو يمكن الوصول إليها من خلال نظام الملفات.
[C-0-2] يجب عدم منح أي تطبيق إذن الوصول للقراءة أو الكتابة إلى الملفات في أي دليل مخصّص خاص بالتطبيق تابع لتطبيق آخر ضمن وحدة التخزين الخارجية. الاستثناءات الوحيدة هي كما يلي:
- سلطة مقدم مساحة التخزين الخارجية (مثل تطبيقات DocumentsUI)
- تنزيل موفّر يستخدم سلطة موفّر "عمليات التنزيل" لتنزيل الملفات إلى مساحة تخزين التطبيق
- تطبيقات بروتوكول نقل الوسائط (MTP) الموقّعة من المنصة والتي تستخدم الإذن المميز ACCESS_MTP لتفعيل نقل الملفات إلى جهاز آخر
- يمكن للتطبيقات التي تثبّت تطبيقات أخرى ولديها إذن INSTALL_PACKAGES الوصول إلى أدلة "obb" فقط بغرض إدارة ملفات بيانات APK الموسّعة.

‫9.8.10. تقرير أخطاء الاتصال

إذا كانت عمليات تنفيذ الأجهزة تتضمّن علامة الميزة android.hardware.telephony، عليها استيفاء ما يلي:

[C-1-1] يجب إتاحة إنشاء تقارير أخطاء الاتصال من خلال BUGREPORT_MODE_TELEPHONY باستخدام BugreportManager.
[C-1-2] يجب الحصول على موافقة المستخدم في كل مرة يتم فيها استخدام BUGREPORT_MODE_TELEPHONY لإنشاء تقرير، ويجب عدم مطالبة المستخدم بالموافقة على جميع الطلبات المستقبلية من التطبيق.
[C-1-3] يجب عدم إرجاع التقرير الذي تم إنشاؤه إلى التطبيق الذي يطلب التقرير بدون موافقة صريحة من المستخدم.
[C-1-4] يجب أن تحتوي التقارير التي يتم إنشاؤها باستخدام BUGREPORT_MODE_TELEPHONY على المعلومات التالية على الأقل:
- TelephonyDebugService dump
- TelephonyRegistry dump
- WifiService dump
- ConnectivityService dump
- عرض لنموذج CarrierService لحزمة الاتصال (إذا كانت مرتبطة)
- مخزن مؤقت لسجل الراديو
- SubscriptionManagerService dump
[C-1-5] يجب ألّا تتضمّن التقارير التي يتم إنشاؤها ما يلي:
- أي نوع من المعلومات غير المرتبطة مباشرةً بتصحيح أخطاء الاتصال
- أي نوع من سجلّات الزيارات أو الملفات الشخصية التفصيلية للتطبيقات/الحِزم التي يثبّتها المستخدم (لا بأس بمعرّفات UID، ولكن لا يُسمح بأسماء الحِزم).
قد تتضمّن معلومات إضافية غير مرتبطة بأي هوية مستخدم. (مثل سجلات المورّدين).

إذا كانت عمليات تنفيذ الأجهزة تتضمّن معلومات إضافية (مثل سجلات المورّدين) في تقارير الأخطاء وكان لتلك المعلومات تأثير على الخصوصية أو الأمان أو البطارية أو مساحة التخزين أو الذاكرة، يجب أن:

[C-SR-1] يُنصح بشدة بأن يكون إعداد المطوّرين غير مفعّل تلقائيًا. تستوفي عملية التنفيذ المرجعية في مشروع AOSP هذا الشرط من خلال توفير الخيار Enable verbose vendor logging في إعدادات المطوّرين لتضمين سجلّات إضافية خاصة بالجهاز من المورّدين في تقارير الأخطاء.

‫9.8.11. مشاركة كتل البيانات

يتيح نظام التشغيل Android للتطبيقات المساهمة في إنشاء كتل بيانات يمكن مشاركتها مع مجموعة محددة من التطبيقات، وذلك من خلال BlobStoreManager.

إذا كانت عمليات تنفيذ الأجهزة تتيح استخدام وحدات البيانات المشتركة على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK)، فإنّها:

[C-1-1] يجب عدم مشاركة وحدات البيانات الثنائية الكبيرة الخاصة بالتطبيقات بما يتجاوز ما كان من المفترض السماح به (أي نطاق الوصول التلقائي وأوضاع الوصول الأخرى التي يمكن تحديدها باستخدام BlobStoreManager.session#allowPackageAccess() أو BlobStoreManager.session#allowSameSignatureAccess() أو BlobStoreManager.session#allowPublicAccess()). ويجب عدم تعديلها. يستوفي التنفيذ المرجعي لنظام التشغيل AOSP هذه المتطلبات.
[C-1-2] يجب عدم إرسال تجزئات البيانات الآمنة من الجهاز أو مشاركتها مع تطبيقات أخرى (تُستخدم هذه التجزئات للتحكّم في الوصول إلى البيانات).

‫9.8.12. Music Recognition

يتيح نظام التشغيل Android، من خلال System API MusicRecognitionManager، آلية تتيح عمليات تنفيذ الأجهزة طلب التعرّف على الموسيقى، وذلك عند توفّر تسجيل صوتي، كما يتيح تفويض عملية التعرّف على الموسيقى إلى تطبيق يتمتع بامتيازات وينفّذ واجهة برمجة التطبيقات MusicRecognitionService.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن خدمة تنفّذ واجهة برمجة التطبيقات System API MusicRecognitionManager أو أي خدمة خاصة تبث بيانات صوتية كما هو موضح أعلاه، يجب أن تستوفي ما يلي:

[C-1-1] يجب فرض أن يكون لدى المتصل بـ MusicRecognitionManager إذن MANAGE_MUSIC_RECOGNITION
[C-1-2] يجب فرض أن يطبِّق تطبيق واحد مثبَّت مسبقًا للتعرّف على الموسيقى MusicRecognitionService.
[C-1-3] يجب ألا تسمح للمستخدمين باستبدال MusicRecognitionManagerService أو MusicRecognitionService بتطبيق أو خدمة يمكن للمستخدم تثبيتها.
[C-1-4] يجب التأكّد من أنّه عند وصول MusicRecognitionManagerService إلى تسجيل الصوت وإعادة توجيهه إلى التطبيق الذي ينفّذ MusicRecognitionService، يتم تتبُّع إذن الوصول إلى الصوت من خلال استدعاءات AppOpsManager.noteOp / startOp.

في حال كانت عمليات تنفيذ MusicRecognitionManagerService أو MusicRecognitionService على الأجهزة تخزِّن أي بيانات صوتية تم تسجيلها، يجب أن:

[C-2-1] يجب عدم تخزين أي بيانات صوتية أولية أو بصمات صوتية على القرص بأي شكل من الأشكال، أو في الذاكرة لمدة تزيد عن 14 يومًا.
[C-2-2] يجب عدم مشاركة هذه البيانات خارج MusicRecognitionService، إلا بموافقة صريحة من المستخدم في كل مرة تتم فيها المشاركة.

‫9.8.13. SensorPrivacyManager

إذا كانت عمليات تنفيذ الأجهزة توفّر للمستخدم أداة برمجية لإيقاف إدخال الكاميرا و/أو الميكروفون في عملية تنفيذ الجهاز، يجب أن:

[C-1-1] يجب أن تعرض الطريقة ذات الصلة في واجهة برمجة التطبيقات supportsSensorToggle() القيمة "true" بدقة.
[C-1-2] يجب أن يتم عرض عنصر تحكّم غير قابل للإغلاق للمستخدم عندما يحاول تطبيق الوصول إلى ميكروفون أو كاميرا محظورَين، ويجب أن يوضّح عنصر التحكّم هذا أنّ المستشعر محظور ويتطلّب اختيار مواصلة الحظر أو إزالته، وذلك وفقًا لتنفيذ AOSP الذي يستوفي هذا الشرط.
[C-1-3] يجب ألا يتم تمرير سوى بيانات فارغة (أو وهمية) للكاميرا والصوت إلى التطبيقات وألا يتم عرض رمز خطأ بسبب عدم تفعيل المستخدم للكاميرا أو الميكروفون من خلال عنصر التحكّم الذي يتم عرضه وفقًا للبند [C-1-2] أعلاه.

‫9.8.14. لا ينطبق

‫9.8.15. عمليات تنفيذ "نظام الحوسبة الخاصة" و"تطبيق البوابة"

يوفّر Android، من خلال مجموعة من واجهات برمجة التطبيقات الخاصة بالميزات المفوضة، آلية لمعالجة البيانات الآمنة على مستوى نظام التشغيل والبيانات المحيطة. يمكن تفويض عملية المعالجة هذه إلى حزمة APK مثبَّتة مسبقًا تتضمّن إذن وصول مميّزًا وإمكانات تواصل محدودة، وتُعرف باسم "تنفيذ واجهة برمجة التطبيقات المحمية".

يُنصح بشدة باستخدام إطار عمل "نظام الحوسبة الخاصة" (PCC) الموضّح أدناه في عمليات تنفيذ الأجهزة التي تتضمّن تطبيقات تنفّذ معالجة على الجهاز للبيانات الحساسة الموضّحة في القسم 9.8.6 (بيانات على مستوى نظام التشغيل وبيانات محيطة).

أي مكوّنات لتنفيذ Sandboxed API في بيئة PCC:

[C-0-1] يجب عدم طلب إذن الوصول إلى الإنترنت.

يجب تعريف [C-0-1] باستخدام السمة android:isPrivateComputeCoreProcess="true" في تعريف البيان.

[C-0-2] يجب ألا يتم الوصول إلى الإنترنت إلا من خلال واجهات برمجة تطبيقات منظَّمة تستند إلى عمليات تنفيذ مفتوحة المصدر متاحة للجميع تستخدم آليات تحافظ على الخصوصية، أو بشكل غير مباشر من خلال واجهات برمجة تطبيقات حزمة تطوير البرامج (SDK) لنظام Android. يتم تعريف آلية الحفاظ على الخصوصية بأنّها "الآليات التي تسمح بالتحليل المجمّع فقط وتمنع مطابقة الأحداث المسجّلة أو النتائج المشتقة مع المستخدمين الفرديين"، وذلك لمنع إمكانية فحص أي بيانات لكل مستخدم (على سبيل المثال، يتم تنفيذها باستخدام تكنولوجيا الخصوصية التفاضلية مثل RAPPOR).

[C-0-2] يجب أن يكون مُحمَّلاً مسبقًا على صورة نظام الجهاز.

[C-0-3] يجب إبقاء الخدمات منفصلة عن مكوّنات النظام الأخرى (مثلاً، عدم ربط الخدمة أو مشاركة أرقام تعريف العمليات مع عمليات التنفيذ التي لا تعمل كمعرّف UID خاص بمزوّد خدمة الدفع). باستثناء ما يلي:
- الاتصال الهاتفي وجهات الاتصال وواجهة مستخدم النظام والوسائط
[C-0-4] يجب ألا تسمح الأجهزة للمستخدمين باستبدال الخدمات بتطبيق أو خدمة يمكن للمستخدم تثبيتها.
[C-0-5] يجب ألا يسمح إلا للخدمات المثبَّتة مسبقًا التي يعيّنها المصنّع الأصلي للجهاز (الذي لديه دور نظام مناسب محدّد في "خدمة نظام إدارة PCC")، والتي لديها الأذونات المناسبة، بجمع هذه البيانات. ما لم تكن إمكانية الاستبدال مضمّنة في AOSP (مثل تطبيقات المساعد الرقمي) البيانات المحيطة الحسّاسة كما هو موضّح في القسم 9.8.6
[C-0-6] يجب ألا تسمح بأي تطبيقات أخرى غير آلية الخدمات المثبَّتة مسبقًا بالتقاط هذه البيانات. ما لم يتم تنفيذ إمكانية الالتقاط هذه باستخدام واجهة برمجة تطبيقات Android SDK.
[C-0-7] يجب توفير إمكانية للمستخدم لإيقاف الخدمات.
[C-0-8] يجب عدم إغفال توفير إمكانية للمستخدم لإدارة أذونات Android التي تحتفظ بها الخدمات واتّباع نموذج أذونات Android كما هو موضّح في الفقرة 9.1. الإذن

[C-0-9] يجب أن يتم تشغيلها في عملية مخصّصة باستخدام معرّف فريد (UID) تحدّده البنية الأساسية، ويكون منفصلاً عن عملية التطبيق الرئيسية والمكوّنات الأخرى التي تعمل في وضع الحماية.

يجب أن يتم توجيه أي وصول إلى الشبكة تتطلبه مكونات بيئة "حزمة خدمات الخصوصية" من خلال حزمة APK مخصّصة تعمل كتطبيق بوابة "حزمة خدمات الخصوصية". المكوّنات المحدّدة:

[C-1-1] يجب منح الإذن المميز android.permission.PROVIDE_PRIVATE_COMPUTE_SERVICES. يصنّف هذا الإذن التطبيق كتطبيق بوابة PCC.
[C-1-2] يجب أن يكون رمز المصدر متاحًا للتحقّق منه بشكل علني.
[C-1-3] يجب استخدام آليات الحفاظ على الخصوصية لأي عملية نقل بيانات خارج الجهاز، كما هو موضّح في الفقرة 9.8.6
[C-1-4] يجب أن يتيح وضع التدقيق في إطار عمل "ميزة الحفاظ على الخصوصية"، والذي يتضمّن تسجيل طلبات الشبكة ونقاط نهاية الخادم وغيرها من البيانات ذات الصلة بالتحقّق من سلوك الحفاظ على الخصوصية عند تفعيلها.

‫9.8.16. بيانات الصوت والكاميرا المستمرة

إذا كانت عمليات تنفيذ الأجهزة تسجّل أيًا من البيانات الموضّحة في الفقرة 9.8.2 أو الفقرة 9.8.6، وإذا كانت عمليات التنفيذ هذه تستخدم بيانات الصوت التي يتم الحصول عليها في الخلفية (بشكل مستمر) من خلال AudioRecord أو SoundTrigger أو واجهات برمجة تطبيقات أخرى خاصة بالصوت، أو بيانات الكاميرا التي يتم الحصول عليها في الخلفية (بشكل مستمر) من خلال CameraManager أو واجهات برمجة تطبيقات أخرى خاصة بالكاميرا، يجب أن تستوفي ما يلي:

[C-0-1] يجب فرض مؤشر مطابق (الكاميرا و/أو الميكروفون كما هو موضح في القسم 9.8.2 التسجيل)، إلا في الحالات التالية:
- يتم منح هذا الإذن في عملية تنفيذ ضمن بيئة معزولة (راجِع القسم 9.8.15 حول عملية تنفيذ واجهة برمجة التطبيقات ضمن بيئة معزولة)، وذلك من خلال حزمة تتضمّن أحد الأدوار التالية أو أكثر: System UI Intelligence أو System Ambient Audio Intelligence أو System Audio Intelligence أو System Notification Intelligence أو System Text Intelligence أو System Visual Intelligence.
- يتم تنفيذ عملية الوصول من خلال وضع الحماية، ويتم تنفيذها وفرضها من خلال آليات في مشروع AOSP (HotwordDetectionService وWearableSensingService وVisualQueryDetector).
- يتم الوصول إلى الصوت لأغراض متعلقة بتسهيل الاستخدام من خلال تطبيق "المساعِد الرقمي" الذي يوفّر SOURCE_HOTWORD كمصدر للصوت.
- يتم تنفيذ عملية الوصول من خلال النظام باستخدام رمز مفتوح المصدر.
[C-SR-1] يُنصح بشدة بطلب موافقة المستخدم على كل وظيفة تستخدم هذه البيانات، ويجب أن تكون هذه الوظيفة غير مفعّلة تلقائيًا.
[C-SR-2] يُنصح بشدة بتطبيق المعاملة نفسها (أي اتّباع القيود الموضّحة في البنود 9.8.2 التسجيل و9.8.6 بيانات نظام التشغيل والبيانات المحيطة و9.8.15 عمليات تنفيذ واجهات برمجة التطبيقات المحمية و9.8.16 البيانات المستمرة للصوت والكاميرا) على بيانات الكاميرا الواردة من جهاز قابل للارتداء عن بُعد.

إذا كانت عمليات تنفيذ الأجهزة تتلقّى بيانات الكاميرا أو الميكروفون من جهاز قابل للارتداء عن بُعد ويتم الوصول إلى البيانات بشكل غير مشفّر خارج نظام التشغيل Android أو عملية تنفيذ معزولة أو وظيفة معزولة أنشأتها WearableSensingManager، يجب أن تستوفي ما يلي:

[C-1-1] يجب أن يشير إلى جهاز قابل للارتداء بعيد لعرض مؤشر إضافي عليه.

إذا كانت الأجهزة توفّر إمكانية التفاعل مع تطبيق "مساعد رقمي" بدون الكلمة الرئيسية المحدّدة (إما من خلال معالجة طلبات البحث العامة من المستخدمين أو تحليل حضور المستخدمين من خلال الكاميرا)، فإنّها:

[C-2-1] يجب التأكّد من أنّ الحزمة التي تتضمّن الدور android.app.role.ASSISTANT توفّر عملية التنفيذ هذه.
[C-2-2] يجب التأكّد من أنّ عملية التنفيذ هذه تستخدم واجهات برمجة التطبيقات HotwordDetectionService و/أو VisualQueryDetectionService لنظام التشغيل Android.

‫9.8.17. Telemetry

يخزِّن نظام التشغيل Android سجلّات النظام والتطبيقات باستخدام واجهات برمجة التطبيقات StatsLog. تتم إدارة هذه السجلات من خلال واجهات برمجة التطبيقات StatsManager التي يمكن أن تستخدمها تطبيقات النظام المزوّدة بأذونات مميّزة.

توفّر StatsManager أيضًا طريقة لجمع البيانات المصنّفة على أنّها حساسة للخصوصية من الأجهزة التي تتضمّن آلية للحفاظ على الخصوصية. على وجه الخصوص، تتيح واجهة برمجة التطبيقات StatsManager::query إمكانية طلب البحث عن فئات المقاييس المحظورة المحدّدة في StatsLog.

أي عملية تنفيذ تستعلم عن المقاييس المحظورة وتجمعها من StatsManager:

[C-0-1] يجب أن يكون التطبيق/التنفيذ الوحيد على الجهاز وأن يحمل إذن READ_RESTRICTED_STATS.
[C-0-2] يجب إرسال بيانات القياس عن بُعد وسجلّ الجهاز فقط باستخدام آلية تحافظ على الخصوصية. يتم تعريف آلية الحفاظ على الخصوصية بأنّها "الآليات التي تسمح بالتحليل المجمّع فقط وتمنع مطابقة الأحداث المسجّلة أو النتائج المستخلَصة مع المستخدمين الفرديين"، وذلك لمنع إمكانية فحص أي بيانات خاصة بكل مستخدم (على سبيل المثال، يتم تنفيذها باستخدام تكنولوجيا الخصوصية التفاضلية مثل RAPPOR).
[C-0-3] يجب عدم ربط هذه البيانات بأي هوية مستخدم (مثل الحساب) على الجهاز.
[C-0-4] يجب عدم مشاركة هذه البيانات مع مكونات نظام التشغيل الأخرى التي لا تلتزم بالمتطلبات الموضّحة في القسم الحالي (9.8.17. القياس عن بُعد).
[C-0-5] يجب توفير وسيلة تحكّم للمستخدمين تتيح لهم تفعيل/إيقاف جمع بيانات القياس عن بُعد التي تحافظ على الخصوصية واستخدامها ومشاركتها.
[C-0-6] يجب توفير إمكانية للمستخدم لمحو البيانات التي يجمعها التنفيذ إذا كانت البيانات مخزّنة بأي شكل على الجهاز. إذا اختار المستخدم محو البيانات، يجب إزالة جميع البيانات المخزَّنة حاليًا على الجهاز.
[C-0-7] يجب الإفصاح عن تنفيذ البروتوكول الأساسي للحفاظ على الخصوصية في مستودع مفتوح المصدر.
[C-0-8] يجب فرض سياسات نقل البيانات خارج الجهاز في هذا القسم للتحكّم في جمع البيانات ضمن فئات المقاييس المحظورة المحدّدة في StatsLog.

‫9.8.18. خصوصية الوظائف المستندة إلى وكيل

عمليات تنفيذ الجهاز:

[C-0-1] يجب التأكّد من أنّ أي مكونات تنفّذ AppFunctions لديها إذن EXECUTE_APP_FUNCTIONS أو EXECUTE_APP_FUNCTIONS_SYSTEM، وأنّها محمّلة مسبقًا على الجهاز.
[C-0-2] يجب ألا يتم استدعاء AppFunction إلا كنتيجة مباشرة لإجراء صريح من المستخدم، ويجب أن يوضّح ذلك للمستخدم التطبيق الذي يتم استدعاؤه والإجراء الأساسي الذي سيتم تنفيذه داخل هذا التطبيق.
[C-0-3] يجب عدم توجيه طلب تطبيق تابع لجهة خارجية أو تعديله للعثور على AppFunctions أو تنفيذها، ما لم يتم استيفاء الشرطَين [C-0-1] و[C-0-2].
[C-0-4] يجب ألا تسمح باستخدام البيانات الحساسة على مستوى نظام التشغيل أو البيانات المحيطة (كما هو محدّد في 9.8.6 حماية البيانات الحساسة على مستوى نظام التشغيل والبيانات المحيطة) أو مشتقاتها من قِبل مكوّنات النظام لإنشاء تنبيهات أو تحديد مَعلمات لها، إلا إذا كانت مكوّنات النظام تعمل في بيئة تنفيذ محمية كما هو محدّد في 9.8.6.

المصطلح الأساسي: يُعرَّف مصطلح "تذكير" بأنّه نقطة دخول يتم إنشاؤها بشكل استباقي إلى تطبيق من مساحة عرض في النظام، ويتم بدءها بدون إجراء مباشر من المستخدم يسبقها. تُقدّم التنبيهات اقتراحات أو إرشادات للمستخدم لاتّخاذ إجراء معيّن بدون تقييد حرية الاختيار.

‫9.9. تشفير البيانات المخزَّنة

يجب أن تستوفي جميع الأجهزة متطلبات القسم 9.9.1. يُعفى من متطلبات الفقرتين 9.9.2 و9.9.3 الأجهزة التي تم إطلاقها بمستوى واجهة برمجة تطبيقات أقدم من مستوى واجهة برمجة التطبيقات الوارد في هذا المستند، ويجب بدلاً من ذلك أن تستوفي متطلبات الفقرة 9.9 من مستند "تعريف التوافق مع Android" الذي يتوافق مع مستوى واجهة برمجة التطبيقات الذي تم إطلاق الجهاز به.

‫9.9.1. التشغيل المباشر

عمليات تنفيذ الجهاز:

[C-0-1] يجب تنفيذ واجهات برمجة التطبيقات لوضع التشغيل المباشر حتى إذا كانت لا تتيح تشفير البيانات المخزّنة.
[C-0-2] يجب أن يظل يتم بث Intent ACTION_LOCKED_BOOT_COMPLETED وIntent ACTION_USER_UNLOCKED للإشارة إلى التطبيقات المتوافقة مع "الوضع المباشر" بأنّ مواقع التخزين المشفرة على الجهاز (DE) والمواقع المشفرة باستخدام بيانات الاعتماد (CE) متاحة للمستخدم.

‫9.9.2. متطلبات التشفير

عمليات تنفيذ الجهاز:

[C-0-1] يجب تشفير بيانات التطبيق الخاصّة (القسم /data)، بالإضافة إلى قسم مساحة التخزين المشتركة للتطبيق (القسم /sdcard) إذا كان جزءًا دائمًا وغير قابل للإزالة من الجهاز.
[C-0-2] يجب تفعيل تشفير تخزين البيانات تلقائيًا عند إكمال المستخدم تجربة الإعداد الجاهز للاستخدام.
[C-0-3] يجب استيفاء متطلبات تشفير تخزين البيانات المذكورة أعلاه من خلال تنفيذ إحدى طريقتَي التشفير التاليتَين:
- التشفير على مستوى الملفات (FBE) وتشفير البيانات الوصفية كما هو موضّح في الفقرة 9.9.3.1
- التشفير على مستوى الحظر لكل مستخدم، كما هو موضّح في الفقرة 9.9.3.2

‫9.9.3. طُرق التشفير

إذا كانت عمليات تنفيذ الجهاز مشفَّرة، فإنّها:

[C-1-1] يجب أن يتم التشغيل بدون مطالبة المستخدم بتقديم بيانات الاعتماد، وأن يسمح للتطبيقات المتوافقة مع ميزة "التشغيل المباشر" بالوصول إلى مساحة التخزين المشفرة على الجهاز (DE) بعد بث الرسالة ACTION_LOCKED_BOOT_COMPLETED.
[C-1-2] يجب عدم السماح بالوصول إلى مساحة تخزين بيانات الاعتماد المشفّرة (CE) إلا بعد استيفاء الشرطين التاليين:
- يفتح المستخدم قفل الجهاز باستخدام طريقة مصادقة أساسية (مثل كلمة المرور أو النقش أو رقم التعريف الشخصي).
- يتم بثّ الرسالة ACTION_USER_UNLOCKED.
[C-1-13] يجب عدم توفير أي طريقة لفتح وحدة التخزين المحمية بواسطة CE بدون بيانات الاعتماد التي يقدّمها المستخدم أو مفتاح استرداد مسجّل أو تنفيذ ميزة "استئناف عند إعادة التشغيل" التي تستوفي المتطلبات الواردة في الفقرة 9.9.4.
[C-1-4] يجب استخدام ميزة "التشغيل المتحقَّق منه".

‫9.9.3.1. التشفير على مستوى الملفات مع تشفير البيانات الوصفية

في حال استخدام عمليات تنفيذ الأجهزة ميزة "التشفير على مستوى الملفات" مع ميزة "تشفير البيانات الوصفية"، يجب استيفاء ما يلي:

[C-1-5] يجب تشفير محتوى الملفات والبيانات الوصفية لنظام الملفات باستخدام AES-256-XTS أو Adiantum. يشير AES-256-XTS إلى معيار التشفير المتقدّم (AES) الذي يبلغ طول مفتاح التشفير فيه 256 بت، ويتم تشغيله في وضع XTS، ويبلغ الطول الكامل للمفتاح 512 بت.يشير Adiantum إلى Adiantum-XChaCha12-AES، كما هو محدّد في https://github.com/google/adiantum. البيانات الوصفية لنظام الملفات هي بيانات مثل أحجام الملفات والملكية والأوضاع والسمات الموسّعة (xattrs).
[C-1-6] يجب تشفير أسماء الملفات باستخدام AES-256-CBC-CTS أو AES-256-HCTR2 أو Adiantum.
[C-1-12] إذا كان الجهاز يتضمّن تعليمات معيار التشفير المتقدّم (AES) (مثل "إضافات التشفير" في ARMv8 على الأجهزة المستندة إلى ARM أو AES-NI على الأجهزة المستندة إلى x86)، يجب استخدام خيارات AES المذكورة أعلاه لتشفير اسم الملف ومحتوى الملف وبيانات نظام الملفات الوصفية، وليس Adiantum.
[C-1-13] يجب استخدام دالة اشتقاق مفتاح قوية من ناحية التشفير وغير قابلة للعكس (مثل HKDF-SHA512) لاشتقاق أي مفاتيح فرعية مطلوبة (مثل المفاتيح الخاصة بكل ملف) من مفتاحَي CE وDE. تعني عبارة "قوي تشفيريًا وغير قابل للعكس" أنّ وظيفة اشتقاق المفتاح تتضمّن قوة أمان تبلغ 256 بت على الأقل وتعمل كمجموعة وظائف عشوائية زائفة على مدخلاتها.
[C-1-14] يجب عدم استخدام مفاتيح أو مفاتيح فرعية لتشفير الملفات (FBE) نفسها لأغراض تشفير مختلفة (مثل التشفير واشتقاق المفاتيح، أو لخوارزميتَي تشفير مختلفتَين).
[C-1-15] يجب التأكّد من أنّ جميع أجزاء محتوى الملف المشفّر غير المحذوفة في مساحة التخزين الثابتة قد تم تشفيرها باستخدام مجموعات من مفتاح التشفير ومتجه التهيئة (IV) الذي يعتمد على كل من الملف والإزاحة داخل الملف. بالإضافة إلى ذلك، يجب أن تكون جميع هذه المجموعات مميزة، إلا في الحالات التي يتم فيها التشفير باستخدام أجهزة تشفير مضمّنة لا تتوافق إلا مع طول متّجه تهيئة يبلغ 32 بت.
[C-1-16] يجب التأكّد من أنّ جميع أسماء الملفات المشفّرة غير المحذوفة والمخزَّنة بشكل دائم في أدلة مختلفة قد تم تشفيرها باستخدام مجموعات مختلفة من مفتاح التشفير ومتّجه التهيئة (IV).
[C-1-17] يجب التأكّد من أنّ جميع وحدات بيانات نظام الملفات المشفّرة على مساحة التخزين الدائمة مشفّرة باستخدام مجموعات مميزة من مفتاح التشفير ومتجه التهيئة (IV).
المفاتيح التي تحمي مساحات تخزين CE وDE وبيانات تعريف نظام الملفات:
- [C-1-7] يجب أن تكون مرتبطة بشكل مشفَّر بـ Keystore مستند إلى الأجهزة. يجب ربط مخزن المفاتيح هذا بميزة "التشغيل المتحقّق منه" وبجذر الثقة للأجهزة.
- [C-1-8] يجب ربط مفاتيح CE ببيانات اعتماد شاشة قفل المستخدم.
- ‫[C-1-9] يجب ربط مفاتيح CE بكلمة مرور تلقائية عندما لا يحدّد المستخدم بيانات اعتماد شاشة القفل.
- [C-1-10] يجب أن تكون المفاتيح فريدة ومميّزة، أي ألا يتطابق مفتاح تشفير المحتوى (CE) أو مفتاح فك التشفير (DE) الخاص بأي مستخدم مع مفاتيح تشفير المحتوى أو فك التشفير الخاصة بأي مستخدم آخر.
- [C-1-11] يجب استخدام التشفيرات وأطوال المفاتيح والأوضاع المتوافقة إلزاميًا.
- [C-1-12] يجب محو البيانات بشكل آمن أثناء فتح قفل برنامج الإقلاع وإغلاقه كما هو موضّح هنا.
يجب أن تكون التطبيقات الأساسية المثبَّتة مسبقًا (مثل المنبّه والهاتف والمراسلة) متوافقة مع ميزة "التشغيل المباشر".

يوفّر مشروع Android مفتوح المصدر الأساسي عملية تنفيذ مفضّلة للتشفير على مستوى الملفات استنادًا إلى ميزة التشفير "fscrypt" في نواة Linux، ولتشفير البيانات الوصفية استنادًا إلى ميزة "dm-default-key" في نواة Linux.

‫9.9.3.2. التشفير على مستوى الحظر لكل مستخدم

إذا كانت عمليات تنفيذ الأجهزة تستخدم التشفير على مستوى الكتل لكل مستخدم، يجب أن:

[C-1-1] يجب توفير إمكانية استخدام عدة مستخدمين كما هو موضّح في القسم 9.5.
[C-1-2] يجب توفير أقسام لكل مستخدم، إما باستخدام أقسام أولية أو وحدات تخزين منطقية.
[C-1-3] يجب استخدام مفاتيح تشفير فريدة ومميّزة لكل مستخدم لتشفير أجهزة الحظر الأساسية.
‫[C-1-4] يجب استخدام AES-256-XTS للتشفير على مستوى الحظر لأقسام المستخدم.
المفاتيح التي تحمي الأجهزة المشفّرة على مستوى الحظر لكل مستخدم:
- [C-1-5] يجب أن يكون مرتبطًا بشكل مشفَّر بـ Keystore مستند إلى الأجهزة. يجب ربط مخزن المفاتيح هذا بميزة "التشغيل المتحقّق منه" وبجذر الثقة للأجهزة.
- [C-1-6] يجب أن تكون مرتبطة ببيانات اعتماد شاشة القفل الخاصة بالمستخدم المعنيّ.

يمكن تنفيذ التشفير على مستوى الحظر لكل مستخدم باستخدام ميزة "dm-crypt" في نواة Linux على الأقسام الخاصة بكل مستخدم.

‫9.9.4. استئناف التشغيل عند إعادة التشغيل

تتيح ميزة "استئناف عمل التطبيقات بعد إعادة تشغيل الجهاز" فتح مساحة تخزين بيانات الاعتماد (CE) لجميع التطبيقات، بما في ذلك التطبيقات التي لا تتوافق بعد مع ميزة "التشغيل المباشر"، وذلك بعد إعادة التشغيل التي يتم إجراؤها من خلال تحديث عبر الأثير (OTA). تتيح هذه الميزة للمستخدمين تلقّي إشعارات من التطبيقات المثبَّتة بعد إعادة التشغيل.

يجب أن يستمر تنفيذ ميزة "استئناف التشغيل عند إعادة التشغيل" في ضمان أنّه عندما يقع الجهاز في أيدي مهاجم، يصعب على هذا المهاجم استرداد بيانات المستخدم المشفرة باستخدام بيانات اعتماد، حتى إذا كان الجهاز قيد التشغيل وتم فتح قفل مساحة التخزين المشفرة باستخدام بيانات الاعتماد وفتح المستخدم قفل الجهاز بعد تلقّي تحديث عبر الأثير. لتعزيز مقاومة الهجمات الداخلية، نفترض أيضًا أنّ المهاجم يمكنه الوصول إلى مفاتيح التوقيع المشفرة للبث.

وعلى وجه التحديد:

[C-0-1] يجب ألا يكون من الممكن قراءة بيانات التشفير من جهة العميل حتى بالنسبة إلى المهاجم الذي يملك الجهاز فعليًا، والذي لديه الإمكانات والقيود التالية:
- يمكن استخدام مفتاح التوقيع الخاص بأي بائع أو شركة لتوقيع الرسائل العشوائية.
- يمكن أن يؤدي إلى تلقّي الجهاز لتحديث عبر الأثير.
- يمكن تعديل طريقة عمل أي أجهزة (معالج تطبيقات، تثبيت ذاكرة ROM، وما إلى ذلك) باستثناء ما هو موضّح أدناه، ولكن يتضمّن هذا التعديل تأخيرًا لمدة ساعة واحدة على الأقل وإعادة تشغيل تؤدي إلى محو محتويات ذاكرة الوصول العشوائي.
- لا يمكن تعديل طريقة عمل الأجهزة المقاومة للتلاعب (مثل Titan M).
- يتعذّر قراءة ذاكرة الوصول العشوائي (RAM) للجهاز المباشر.
- لا يمكن الحصول على بيانات اعتماد المستخدم (رقم التعريف الشخصي أو النقش أو كلمة المرور) أو التسبّب في إدخالها بأي طريقة أخرى.

على سبيل المثال، سيكون تصميم الجهاز الذي يتضمّن جميع الأوصاف الواردة هنا ومتوافقًا معها متوافقًا مع [C-0-1].

‫9.10. سلامة الجهاز

تضمن المتطلبات التالية توفُّر الشفافية بشأن حالة سلامة الجهاز. عمليات تنفيذ الجهاز:

[C-0-1] يجب أن يتم الإبلاغ بشكل صحيح من خلال طريقة System API PersistentDataBlockManager.getFlashLockState() عما إذا كانت حالة برنامج الإقلاع تسمح بتثبيت صورة النظام.
[C-0-2] يجب أن تتوافق مع ميزة "التشغيل المتحقّق منه" لضمان سلامة الجهاز.

إذا تم إطلاق عمليات تنفيذ الأجهزة بدون توفير إمكانية "التشغيل المتحقّق منه" في إصدار سابق من Android ولم يكن من الممكن إضافة إمكانية استخدام هذه الميزة من خلال تحديث برنامج النظام، يجوز إعفاؤها من هذا الشرط.

[C-1-1] يجب الإفصاح عن علامة ميزة المنصة android.software.verified_boot.
‫[C-1-2] يجب إجراء عملية التحقّق في كل تسلسل تشغيل.
‫[C-1-3] يجب بدء عملية التحقّق من مفتاح أمان ثابت للأجهزة يمثّل أساس الثقة، ثم الانتقال إلى قسم النظام.
[C-1-4] يجب تنفيذ كل مرحلة من مراحل التحقّق للتأكّد من سلامة جميع وحدات البايت في المرحلة التالية وصحتها قبل تنفيذ الرمز في المرحلة التالية.
[C-1-5] يجب استخدام خوارزميات تحقّق بقوة الخوارزميات الحالية التي توصي بها NIST لخوارزميات التجزئة (SHA-256) وأحجام المفاتيح العامة (RSA-2048).
[C-1-6] يجب ألا يسمح الجهاز بإكمال عملية التشغيل عند تعذُّر إثبات صحة النظام، إلا إذا وافق المستخدم على محاولة التشغيل على أي حال، وفي هذه الحالة، يجب عدم استخدام البيانات من أي وحدات تخزين لم يتم إثبات صحتها.
[C-1-7] يجب ألا يسمح بتعديل الأقسام التي تم التحقّق منها على الجهاز إلا إذا فتح المستخدم برنامج التشغيل بشكل صريح.
[C-1-8] يجب استخدام مساحة تخزين مقاومة للتلاعب: لتخزين ما إذا كان برنامج التشغيل قد تم إلغاء قفله. تعني مساحة التخزين المقاومة للتلاعب أنّه يمكن لبرنامج Bootloader رصد ما إذا تم التلاعب بمساحة التخزين من داخل نظام Android.
[C-1-9] يجب أن يطلب الجهاز من المستخدم تأكيدًا ماديًا أثناء استخدامه قبل السماح بالانتقال من وضع قفل برنامج الإقلاع إلى وضع فتح قفل برنامج الإقلاع.
[C-1-10] يجب تنفيذ ميزة الحماية من الرجوع إلى إصدار أقدم للأقسام التي يستخدمها Android (مثل أقسام التشغيل والنظام) واستخدام مساحة تخزين مقاومة للتلاعب لتخزين البيانات الوصفية المستخدَمة لتحديد الحد الأدنى المسموح به من إصدار نظام التشغيل.
[C-1-11] يجب محو جميع بيانات المستخدمين بشكل آمن أثناء فتح برنامج الإقلاع وقفله، وذلك وفقًا للبند 9.12. حذف البيانات (بما في ذلك قسم بيانات المستخدم وأي مساحات NVRAM).
[C-1-14] يجب التحقّق من التوقيع مرة واحدة على الأقل في كل عملية تشغيل للحِزم المدرَجة في القائمة المسموح بها والتي تم إدراجها على أنّها require-strict-signature في إعدادات النظام.
[C-SR-2] يُنصح بشدة بالتحقّق من جميع ملفات APK الخاصة بالتطبيقات ذات الامتيازات باستخدام سلسلة ثقة تستند إلى الأقسام المحمية من خلال ميزة "التمهيد المُتحقّق منه".
[C-SR-3] يُنصح بشدة بالتحقّق من أي عناصر قابلة للتنفيذ يتم تحميلها بواسطة تطبيق ذي امتيازات من خارج ملف APK الخاص به (مثل الرمز الذي يتم تحميله ديناميكيًا أو الرمز المجمَّع) قبل تنفيذها، أو يُنصح بشدة بعدم تنفيذها على الإطلاق.
يجب تنفيذ ميزة الحماية من الرجوع إلى إصدار أقدم لأي مكوّن يتضمّن برامج ثابتة مستمرة (مثل المودم والكاميرا)، ويجب استخدام مساحة تخزين مقاومة للتلاعب لتخزين البيانات الوصفية المستخدَمة في تحديد الحد الأدنى للإصدار المسموح به.

يوفر مشروع Android المفتوح المصدر (AOSP) عملية تنفيذ مفضّلة لهذه الميزة في مستودع external/avb/، ويمكن دمجها في برنامج التشغيل المستخدَم لتحميل Android.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية التحقّق من محتوى الملف على أساس كل صفحة، يجب أن تستوفي ما يلي:

‫[C-2-1] إتاحة إمكانية التحقّق من صحة محتوى الملف بشكل مشفّر بدون قراءة الملف بأكمله
[C-2-2] يجب ألا يسمح بتنفيذ طلبات القراءة على ملف محمي عندما لا يتم التحقّق من صحة المحتوى المقروء وفقًا لما ورد في [C-2-1] أعلاه.
[C-2-4] يجب أن تعرض الدالة المجموع الاختباري للملف في O(1) للملفات المفعّلة.

إذا تم إطلاق عمليات تنفيذ الأجهزة بدون إمكانية التحقّق من محتوى الملفات باستخدام مفتاح موثوق به على إصدار Android أقدم، ولم يكن من الممكن إضافة دعم لهذه الميزة من خلال تحديث برنامج النظام، يجوز إعفاء هذه الأجهزة من هذا الشرط. يوفّر مشروع Android مفتوح المصدر الأساسي عملية تنفيذ مفضّلة لهذه الميزة استنادًا إلى ميزة fs-verity في نواة Linux.

‫9.11. المفاتيح وبيانات الاعتماد

يتيح نظام Android Keystore لمطوّري التطبيقات تخزين مفاتيح التشفير في حاوية واستخدامها في عمليات التشفير من خلال KeyChain API أو Keystore API. عمليات تنفيذ الجهاز:

[C-0-1] يجب السماح باستيراد أو إنشاء 8,192 مفتاحًا على الأقل.
[C-0-2] يجب أن تتضمّن مصادقة شاشة القفل فاصلًا زمنيًا بين المحاولات غير الناجحة. إذا كان n هو عدد المحاولات الفاشلة، يجب ألا يقلّ الفاصل الزمني عن 30 ثانية إذا كان 9 < n < 30. بالنسبة إلى n > 29، يجب أن تكون قيمة الفاصل الزمني 30*2^floor((n-30)/10) ثانية على الأقل أو 24 ساعة على الأقل، أيهما أصغر.
يجب عدم وضع حدّ لعدد المفاتيح التي يمكن إنشاؤها.

عندما يتيح تنفيذ الجهاز استخدام شاشة قفل آمنة، يجب أن يستوفي ما يلي:

[C-1-1] يجب أن يتم الاحتفاظ بنسخة احتياطية من تنفيذ ملف تخزين المفاتيح في بيئة تنفيذ معزولة.

[C-1-2] يجب أن تتضمّن عمليات تنفيذ خوارزميات التشفير RSA وAES وECDSA وECDH (في حال توفُّر IKeyMintDevice) و3DES وHMAC ودوال التجزئة MD5 وSHA-1 وSHA-2 خوارزميات التشفير ودوال التجزئة المطلوبة من خلال إصدار IKeyMintDevice أو IKeymasterDevice المتوافق لتوفير الدعم بشكلٍ سليم للخوارزميات المتوافقة مع نظام Android Keystore في منطقة معزولة بشكلٍ آمن عن الرمز البرمجي الذي يتم تنفيذه على النواة وما فوقها.

يجب أن تحظر ميزة العزل الآمن جميع الآليات المحتملة التي يمكن من خلالها أن يصل رمز kernel أو رمز مساحة المستخدم إلى الحالة الداخلية للبيئة المعزولة، بما في ذلك الوصول المباشر إلى الذاكرة (DMA).

يستوفي "مشروع Android المفتوح المصدر" (AOSP) هذا الشرط باستخدام تنفيذ Trusty، ولكن هناك خيارات بديلة أخرى، مثل حلّ آخر يستند إلى ARM TrustZone أو تنفيذ آمن تمت مراجعته من قِبل جهة خارجية ويستند إلى عزل مناسب باستخدام برنامج مراقبة الأجهزة الافتراضية.

[C-1-3] يجب إجراء مصادقة شاشة القفل في بيئة التنفيذ المعزولة، ولا يُسمح باستخدام المفاتيح المرتبطة بالمصادقة إلا عند نجاحها. يجب تخزين بيانات الاعتماد على شاشة القفل بطريقة لا تسمح إلا لبيئة التنفيذ المعزولة بإجراء مصادقة شاشة القفل. يوفر مشروع Android مفتوح المصدر (AOSP) طبقة تجريد الأجهزة (HAL) في Gatekeeper وTrusty، ويمكن استخدامهما لاستيفاء هذا الشرط.
[C-1-4] يجب أن تتوافق مع مصادقة المفتاح حيث يكون مفتاح التوقيع الخاص بالمصادقة محميًا بواسطة أجهزة آمنة ويتم التوقيع في أجهزة آمنة. يجب منع استخدام مفاتيح توقيع شهادة التصديق كمعرّفات دائمة للأجهزة.

ملاحظة: لاستيفاء هذا الشرط، يجب مشاركة مفتاح التصديق نفسه لرمز تخزين تعريفي معيّن ما لم يتم إنتاج 100,000 وحدة على الأقل من رمز التخزين التعريفي هذا. إذا تم إنتاج أكثر من 100,000 وحدة من رمز التخزين التعريفي هذا، يمكن استخدام مفتاح مختلف لكل مجموعة من 100,000 وحدة بعد ذلك. بدلاً من ذلك، يمكن استخدام حلّ Remote Key Provisioning لتوفير مفاتيح تصديق قصيرة الأمد للجهاز.

‫[C-1-5] يجب أن يسمح للمستخدم باختيار مهلة السكون للانتقال من حالة فتح القفل إلى حالة قفل الشاشة، مع توفير مهلة دنيا تصل إلى 15 ثانية. قد لا تتضمّن أجهزة السيارات التي تقفل الشاشة عند إيقاف تشغيل وحدة التحكم الرئيسية أو تبديل المستخدم إعدادات مهلة السكون.
[C-1-6] يجب أن يتوافق مع الإصدار 3.0 من IKeymasterDevice أو الإصدارات الأحدث، أو الإصدار 1 من IKeyMintDevice أو الإصدارات الأحدث.

[C-SR-1] يُنصح بشدة بفرض حد أدنى للفاصل الزمني بين المحاولات الفاشلة الفريدة لطرق المصادقة الأساسية (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور)، وذلك استنادًا إلى ما يلي:

عدد المحاولات غير الناجحة الفريدة	الحدّ الأدنى لمهلة الانتظار
0-4	0
5	دقيقة واحدة
6	5 دقائق
7	‫15 دقيقة
8	30 دقيقة
9	‫90 دقيقة
10	4 ساعات
11	12 ساعة
12	24 ساعة
13	4 أيام
14	13 يومًا
15	41 يومًا
16	‫123 يومًا
17	سنة واحدة
18	‫3 سنوات
19	9 سنوات

‫9.11.1. تأمين قفل الجهاز والمصادقة والأجهزة الافتراضية

يتّبع تطبيق AOSP نموذج مصادقة متدرّجًا، حيث يمكن دعم المصادقة الأساسية المستندة إلى عامل المعرفة إما من خلال مقياس حيوي ثانوي قوي أو من خلال طُرق ثالثية أضعف.

عمليات تنفيذ الجهاز:

[C-SR-1] يُنصح بشدة بتحديد إحدى الطرق التالية فقط كطريقة مصادقة أساسية:
- رقم تعريف شخصي عددي
- كلمة مرور أبجدية رقمية
- نمط تمرير سريع على شبكة من 3 × 3 نقاط بالضبط
يُرجى العِلم أنّ طرق المصادقة المذكورة أعلاه يُشار إليها في هذا المستند على أنّها طرق المصادقة الأساسية المقترَحة.
[C-0-1] يجب الحدّ من عدد محاولات المصادقة الأساسية الفاشلة.
[C-SR-5] يُنصح بشدة بتطبيق حدّ أقصى يبلغ 20 محاولة فاشلة للمصادقة الأساسية، وفي حال موافقة المستخدمين على الميزة وتفعيلها، يجب إجراء "إعادة الضبط على الإعدادات الأصلية" بعد تجاوز الحدّ الأقصى لعدد محاولات المصادقة الأساسية الفاشلة.

إذا كانت عمليات تنفيذ الأجهزة تضبط رقم تعريف شخصي رقميًا كطريقة المصادقة الأساسية المقترَحة، يجب استيفاء ما يلي:

[C-SR-6] يُنصح بشدة بأن يتكوّن رقم التعريف الشخصي من 6 أرقام على الأقل، أو ما يعادل 20 بت من البيانات العشوائية.
‫[C-SR-7] يُنصح بشدة بعدم السماح بإدخال رقم التعريف الشخصي تلقائيًا بدون تفاعل المستخدم إذا كان طوله أقل من 6 أرقام، وذلك لتجنُّب الكشف عن طول رقم التعريف الشخصي.

إذا أضافت عمليات تنفيذ الأجهزة طرق المصادقة الأساسية المقترَحة أو عدّلتها واستخدمت طريقة مصادقة جديدة كوسيلة آمنة لقفل الشاشة، يجب أن تستوفي طريقة المصادقة الجديدة ما يلي:

[C-2-1] يجب أن تكون طريقة مصادقة المستخدم على النحو الموضّح في اشتراط مصادقة المستخدم لاستخدام المفتاح.

إذا أضافت عمليات تنفيذ الأجهزة طرق مصادقة أو عدّلتها لفتح قفل الشاشة استنادًا إلى سر معروف واستخدمت طريقة مصادقة جديدة ليتم التعامل معها كطريقة آمنة لقفل الشاشة، يجب استيفاء ما يلي:

[C-3-1] يجب أن يكون حجم البيانات العشوائية لأقصر طول مسموح به للإدخالات أكبر من 10 بت.
[C-3-2] يجب أن يكون الحد الأقصى للإنتروبيا لجميع المدخلات الممكنة أكبر من 18 بت.
[C-3-3] يجب ألا تحل طريقة المصادقة الجديدة محل أي من طرق المصادقة الأساسية الموصى بها (أي رقم التعريف الشخصي أو النقش أو كلمة المرور) التي تم تنفيذها وتوفيرها في مشروع Android مفتوح المصدر (AOSP).
[C-3-4] يجب إيقاف طريقة المصادقة الجديدة عندما يضبط تطبيق "وحدة التحكّم في سياسة الجهاز" (DPC) سياسة متطلبات كلمة المرور من خلال DevicePolicyManager.setRequiredPasswordComplexity() باستخدام ثابت تعقيد أكثر تقييدًا من PASSWORD_COMPLEXITY_NONE أو من خلال طريقة DevicePolicyManager.setPasswordQuality() باستخدام ثابت أكثر تقييدًا من PASSWORD_QUALITY_BIOMETRIC_WEAK.
[C-3-5] يجب أن تعود طرق المصادقة الجديدة إلى طرق المصادقة الأساسية المقترَحة (أي رقم التعريف الشخصي أو النمط أو كلمة المرور) مرة واحدة كل 72 ساعة أو أقل، أو أن توضّح للمستخدم أنّ بعض البيانات لن يتم الاحتفاظ بنسخة احتياطية منها للحفاظ على خصوصية بياناته.

إذا أضافت عمليات تنفيذ الأجهزة طرق المصادقة الأساسية المقترَحة أو عدّلتها لفتح قفل الشاشة واستخدام طريقة مصادقة جديدة تستند إلى المقاييس الحيوية ليتم اعتبارها طريقة آمنة لقفل الشاشة، يجب أن تستوفي الطريقة الجديدة ما يلي:

[C-4-1] يجب استيفاء جميع المتطلبات الموضّحة في الفقرة 7.3.10 للفئة 1 (المعروفة سابقًا باسم الراحة).
[C-4-2] يجب توفير آلية احتياطية لاستخدام إحدى طرق المصادقة الأساسية الموصى بها والتي تستند إلى سر معروف.
يجب إيقاف [C-4-3] وعدم السماح إلا بالمصادقة الأساسية الموصى بها لفتح قفل الشاشة عندما يضبط تطبيق "وحدة التحكّم في سياسة الجهاز" (DPC) سياسة ميزة قفل الشاشة من خلال استدعاء الطريقة DevicePolicyManager.setKeyguardDisabledFeatures()، مع أي من العلامات الحيوية المرتبطة (مثل KEYGUARD_DISABLE_BIOMETRICS أو KEYGUARD_DISABLE_FINGERPRINT أو KEYGUARD_DISABLE_FACE أو KEYGUARD_DISABLE_IRIS).

إذا لم تستوفِ طرق المصادقة بالمقاييس الحيوية متطلبات الفئة 3 (المعروفة سابقًا باسم قوية) كما هو موضّح في الفقرة 7.3.10:

[C-5-1] يجب إيقاف الطريقتين إذا كان تطبيق "وحدة التحكّم في سياسة الجهاز" (DPC) قد ضبط سياسة جودة متطلبات كلمة المرور من خلال DevicePolicyManager.setRequiredPasswordComplexity()‎ باستخدام مجموعة تعقيد أكثر تقييدًا من PASSWORD_COMPLEXITY_LOW أو باستخدام طريقة DevicePolicyManager.setPasswordQuality()‎ مع ثابت جودة أكثر تقييدًا من PASSWORD_QUALITY_BIOMETRIC_WEAK.
[C-5-2] يجب أن يُطلب من المستخدم إكمال عملية المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) كما هو موضّح في [C-1-7] و[C-1-8] في الفقرة 7.3.10.
[C-5-3] يجب عدم التعامل مع الطرق على أنّها شاشة قفل آمنة، ويجب أن تستوفي المتطلبات التي تبدأ بـ C-8 في هذا القسم أدناه.

إذا أضافت عمليات تنفيذ الأجهزة طرق المصادقة أو عدّلتها لفتح شاشة القفل، وكانت طريقة المصادقة الجديدة تستند إلى رمز مميّز مادي أو الموقع الجغرافي، يجب استيفاء ما يلي:

[C-6-1] يجب أن تتضمّن آلية احتياطية لاستخدام إحدى طرق المصادقة الأساسية الموصى بها والتي تستند إلى سر معروف وتستوفي المتطلبات التي تؤهّلها لأن تُعامل على أنّها شاشة قفل آمنة.
[C-6-2] يجب إيقاف الطريقة الجديدة وعدم السماح إلا بإحدى طرق المصادقة الأساسية الموصى بها لفتح قفل الشاشة عندما يضبط تطبيق "وحدة التحكّم في سياسات الجهاز" (DPC) السياسة باستخدام أحد الخيارَين التاليَين:
- الطريقة DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS)
- الطريقة DevicePolicyManager.setPasswordQuality() التي تتضمّن ثابت جودة أكثر تقييدًا من PASSWORD_QUALITY_NONE.
- الطريقة DevicePolicyManager.setRequiredPasswordComplexity() التي تتضمّن مجموعة أكثر صرامة من PASSWORD_COMPLEXITY_NONE.
[C-6-3] يجب أن يُطلب من المستخدم إثبات هويته باستخدام إحدى طرق المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) مرة واحدة على الأقل كل 4 ساعات أو أقل. عندما يستوفي الرمز المميّز الفعلي متطلبات عمليات تنفيذ TrustAgent في C-X، يتم بدلاً من ذلك تطبيق قيود المهلة المحدّدة في [C-9-5].
[C-6-4] يجب ألا يتم التعامل مع الطريقة الجديدة على أنّها شاشة قفل آمنة، ويجب أن تلتزم بالقيود الواردة في القسم C-8 أدناه.

[C-7-1] يجب أن يتضمّن الجهاز إشارة واضحة في قائمة الإعدادات وعلى شاشة القفل عندما يتم تأجيل قفل الجهاز أو عندما يمكن فتح قفله باستخدام عوامل موثوقة. على سبيل المثال، يستوفي AOSP هذا الشرط من خلال عرض وصف نصي لـ "إعداد القفل التلقائي" و "القفل الفوري باستخدام زر التشغيل" في قائمة الإعدادات ورمز مميّز على شاشة القفل.
[C-7-2] يجب احترام جميع واجهات برمجة التطبيقات الخاصة بوكيل الثقة وتنفيذها بالكامل في الفئة DevicePolicyManager، مثل الثابت KEYGUARD_DISABLE_TRUST_AGENTS.
[C-7-3] يجب عدم تنفيذ وظيفة TrustAgentService.addEscrowToken() بالكامل على جهاز يُستخدم كجهاز شخصي أساسي (مثل جهاز محمول باليد)، ولكن يجوز تنفيذ الوظيفة بالكامل على الأجهزة التي تتم مشاركتها عادةً (مثل Android TV أو جهاز Automotive).
[C-7-4] يجب تشفير جميع الرموز المميّزة المخزّنة التي أضافها TrustAgentService.addEscrowToken().
[C-7-5] يجب عدم تخزين مفتاح التشفير أو رمز الإيداع على الجهاز نفسه الذي يتم فيه استخدام المفتاح. على سبيل المثال، يُسمح باستخدام مفتاح مخزّن على هاتف لفتح قفل حساب مستخدم على تلفزيون. بالنسبة إلى أجهزة السيارات، لا يُسمح بتخزين رمز الإيداع على أي جزء من المركبة.
[C-7-6] يجب إبلاغ المستخدم بالآثار الأمنية قبل تفعيل الرمز المميز للاسترداد من أجل فك تشفير وحدة تخزين البيانات.
[C-7-7] يجب توفير آلية احتياطية لاستخدام إحدى طرق المصادقة الأساسية المقترَحة.
[C-7-9] يجب أن يُطلب من المستخدم إكمال إحدى طرق المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النمط أو كلمة المرور) كما هو موضّح في [C-1-7] و[C-1-8] في الفقرة 7.3.10، ما لم تكن سلامة المستخدم (مثل تشتيت انتباه السائق) مصدر قلق.
[C-7-10] يجب ألا يتم التعامل معه على أنّه شاشة قفل آمنة، ويجب أن يلتزم بالقيود الواردة في القسم C-8 أدناه.
[C-7-11] يجب عدم السماح لـ TrustAgents على الأجهزة الشخصية الأساسية (مثل الأجهزة المحمولة) بفتح قفل الجهاز، ولا يمكن استخدامها إلا لإبقاء الجهاز الذي تم فتح قفله في حالة عدم القفل لمدة تصل إلى 4 ساعات كحد أقصى. يتوافق التنفيذ التلقائي لواجهة TrustManagerService في "مشروع Android مفتوح المصدر" مع هذا الشرط.
[C-7-12] يجب استخدام قناة اتصال آمنة من ناحية التشفير (مثل UKEY2) لتمرير رمز الإيداع من جهاز تخزين إلى جهاز الاختبار.

إذا أضافت عمليات تنفيذ الأجهزة طرق مصادقة أو عدّلتها لفتح شاشة القفل التي ليست شاشة قفل آمنة كما هو موضّح أعلاه، واستخدمت طريقة مصادقة جديدة لفتح Keyguard، يجب استيفاء ما يلي:

[C-8-1] يجب إيقاف الطريقة الجديدة عندما يضبط تطبيق "وحدة التحكّم في سياسة الجهاز" (DPC) سياسة جودة كلمة المرور من خلال الطريقة DevicePolicyManager.setPasswordQuality() مع ثابت جودة أكثر تقييدًا من PASSWORD_QUALITY_NONE أو من خلال الطريقة DevicePolicyManager.setRequiredPasswordComplexity() مع ثابت تعقيد أكثر تقييدًا من PASSWORD_COMPLEXITY_NONE.
[C-8-2] يجب ألا يعيدوا ضبط مؤقتات انتهاء صلاحية كلمات المرور التي تم ضبطها بواسطة DevicePolicyManager.setPasswordExpirationTimeout().
[C-8-3] يجب ألا يتم توفير واجهة برمجة تطبيقات يمكن للتطبيقات التابعة لجهات خارجية استخدامها لتغيير حالة القفل.

إذا كانت عمليات تنفيذ الأجهزة تسمح للتطبيقات بإنشاء شاشات عرض افتراضية ثانوية ولا تتيح أحداث الإدخال المرتبطة بها، مثل تلك التي تتم عبر VirtualDeviceManager، فإنّها:

[C-9-1] يجب قفل شاشات العرض الثانوية الافتراضية هذه عندما تكون شاشة العرض التلقائية للجهاز مقفلة، وفتح قفل شاشات العرض الثانوية الافتراضية هذه عندما تكون شاشة العرض التلقائية للجهاز غير مقفلة.

إذا كانت عمليات تنفيذ الأجهزة تسمح للتطبيقات بإنشاء شاشات عرض افتراضية ثانوية وتتيح أحداث الإدخال المرتبطة بها، مثل تلك التي تتم من خلال VirtualDeviceManager، يجب أن تستوفي ما يلي:

‫[C-10-1] يجب أن تتوافق مع حالات قفل منفصلة لكل جهاز افتراضي
[C-10-2] تمت إزالة هذا الشرط في Android 16.
[C-10-3] تمت إزالة هذا الشرط في نظام التشغيل Android 16.
[C-10-4] يجب قفل جميع الشاشات عندما يبدأ المستخدم عملية الحظر، بما في ذلك عبر أداة الحظر التي يجب توفيرها للأجهزة المحمولة (راجِع الفقرة 2.2.5[9.11/H-1-2])
[C-10-5] يجب توفير نُسخ منفصلة من الأجهزة الافتراضية لكل مستخدم
‫[C-10-6] يجب إيقاف بث التطبيقات على النحو الموضّح في DevicePolicyManager.setNearbyAppStreamingPolicy.
[C-10-7] تمت إزالة هذا الشرط في الإصدار Android 16.
[C-10-11] يجب إيقاف واجهة مستخدم المصادقة على الأجهزة الافتراضية، بما في ذلك إدخال عامل المعرفة وطلب المقاييس الحيوية
[C-10-12] تمت إزالة هذا الشرط في Android 16.
[C-10-13] يجب عدم استخدام حالة قفل الجهاز الافتراضي كإذن مصادقة للمستخدم مع نظام Android Keystore. يمكنك الاطّلاع على KeyGenParameterSpec.Builder.setUserAuthentication*.
[C-10-14] يجب توفير أداة تحكّم للمستخدمين تتيح مشاركة الحافظة بين الأجهزة قبل مشاركة بيانات الحافظة بين الأجهزة المادية والأجهزة الافتراضية، وذلك في حال كان الجهاز يتيح استخدام حافظة مشتركة.
[C-10-15] يجب عرض إشعارات عند الوصول إلى بيانات الحافظة على كلّ من الجهاز الذي تم الوصول منها إلى البيانات والجهاز الذي تم نسخ البيانات منه إلى الحافظة.

عندما تسمح عمليات تنفيذ الأجهزة للمستخدم بنقل عامل المعرفة الخاص بالمصادقة الأساسية من جهاز مصدر إلى جهاز مستهدف، مثلاً لإعداد الجهاز المستهدف في البداية، يجب أن تستوفي ما يلي:

[C-11-1] يجب تشفير عامل المعرفة بضمانات حماية مشابهة لتلك الموضّحة في ورقة المعلومات الفنية حول الأمان الخاصة بخدمة Google Cloud Key Vault عند نقل عامل المعرفة من الجهاز المصدر إلى جهاز الاختبار بحيث لا يمكن فك تشفير عامل المعرفة عن بُعد أو استخدامه لفتح قفل أي من الجهازَين عن بُعد.
[C-11-2] يجب أن يطلب الجهاز المصدر من المستخدم تأكيد عامل المعرفة الخاص بالجهاز المصدر قبل نقل عامل المعرفة إلى الجهاز المستهدف.
‫[C-11-3] يجب أن يطلب الجهاز المستهدف الذي لا يتضمّن أي عامل معرفة تم ضبطه للمصادقة الأساسية من المستخدم تأكيد عامل المعرفة الذي تم نقله على الجهاز المستهدف قبل ضبط عامل المعرفة هذا كعامل معرفة أساسي للمصادقة على الجهاز المستهدف وقبل إتاحة أي بيانات تم نقلها من جهاز مصدر.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة قفل آمنة وتشمل وكيل ثقة واحدًا أو أكثر، وتستدعي واجهة برمجة التطبيقات TrustAgentService.grantTrust() System مع العلامة FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE، فإنّها:

[C-12-1] يجب عدم استدعاء grantTrust() مع العلامة إلا عند الاتصال بجهاز فعلي قريب مزوّد بشاشة قفل خاصة به، وعندما يثبت المستخدم هويته من خلال شاشة القفل هذه. يمكن للأجهزة القريبة استخدام آليات الرصد على المعصم أو أثناء الحمل بعد أن يفتح المستخدم قفل الجهاز لمرة واحدة لاستيفاء شرط مصادقة المستخدم.
[C-12-2] يجب أن يضع تنفيذ الجهاز في حالة TrustState.TRUSTABLE عندما يتم إيقاف تشغيل الشاشة (مثل الضغط على زر أو انتهاء مهلة العرض) ولم يلغِ TrustAgent الثقة. يستوفي AOSP هذا الشرط.
[C-12-3] يجب ألا يتم نقل الجهاز من الحالة TrustState.TRUSTABLE إلى الحالة TrustState.TRUSTED إلا إذا كان TrustAgent لا يزال يمنح الثقة استنادًا إلى المتطلبات الواردة في [C-12-1].

[C-12-4] يجب استدعاء TrustManagerService.revokeTrust() إذا كانت عمليات التنفيذ لا تستخدم تحديد المدى الدقيق والآمن من ناحية التشفير على النحو المحدّد في [C-12-5]:
- بعد 24 ساعة كحد أقصى من منح الثقة، أو
- بعد مرور 8 ساعات من عدم النشاط
- إذا كانت عمليات التنفيذ لا تستخدم تحديد المدى الدقيق والآمن من ناحية التشفير على النحو المحدّد في [C-12-5]، عندما يتم فقدان الاتصال الأساسي بالجهاز المادي القريب.

[C-12-5] يجب أن تستخدم عمليات التنفيذ التي تعتمد على تحديد المدى الآمن والدقيق لاستيفاء متطلبات [C-12-4] أحد الحلول التالية:
- عمليات التنفيذ باستخدام النطاق الفائق العرض (UWB):
  - يجب استيفاء متطلبات التوافق والشهادة والدقة والمعايرة الخاصة بتقنية النطاق الفائق العرض (UWB) الموضّحة في 7.4.9.
  - يجب استخدام أحد أوضاع أمان P-STS المدرَجة في 7.4.9.
- عمليات التنفيذ التي تستخدم ميزة "الاتصال المباشر بمحطات لاسلكية مجاورة" عبر Wi-Fi:
  - يجب أن يستوفي متطلبات الدقة الواردة في 2.2.1 [7.4.2.5/H-SR-1]، وأن يستخدم النطاق الترددي 160 ميغاهرتز (أو أعلى)، وأن يتّبع خطوات إعداد القياس المحدّدة في معايرة الاستشعار عن القرب.
  - يجب استخدام Secure LTF كما هو محدّد في IEEE 802.11az.

إذا كانت عمليات تنفيذ الأجهزة تسمح للتطبيقات بإنشاء شاشات عرض افتراضية ثانوية وتتيح أحداث الإدخال المرتبطة بها، مثل تلك التي تتم من خلال VirtualDeviceManager، ولم يتم وضع علامة VIRTUAL_DISPLAY_FLAG_SECURE على شاشات العرض، فإنّها:

[C-13-8] يجب حظر بدء الأنشطة التي تتضمّن السمة android:canDisplayOnRemoteDevices أو البيانات الوصفية android.activity.can_display_on_remote_devices التي تم ضبطها على "false" على الجهاز الافتراضي.
[C-13-9] يجب حظر الأنشطة التي لا تتيح البث بشكل صريح والتي تشير إلى أنّها تعرض محتوى حسّاسًا، بما في ذلك من خلال SurfaceView#setSecure وFLAG_SECURE، من بدء التشغيل على الجهاز الافتراضي.

إذا كانت عمليات تنفيذ الأجهزة تتيح حالات طاقة منفصلة للشاشة من خلال DeviceStateManager وتتيح حالات قفل منفصلة للشاشة من خلال KeyguardDisplayManager، يجب أن تستوفي ما يلي:

[C-SR-2] يُنصح بشدة باستخدام بيانات اعتماد تستوفي المتطلبات المحدّدة في القسم 9.11.1 أو بيانات اعتماد بيومترية تستوفي على الأقل مواصفات الفئة 1 المحدّدة في القسم 7.3.10 للسماح بفتح القفل بشكل مستقل عن شاشة الجهاز التلقائية.
[C-SR-3] يُنصح بشدة بفرض قيود على فتح الشاشة المنفصلة من خلال مهلة عرض محدّدة.
[C-SR-4] يُنصح بشدة بالسماح للمستخدم بقفل جميع الشاشات على مستوى العالم من خلال وضع "الحظر" من الجهاز المحمول الأساسي.

‫9.11.2. StrongBox

يتيح نظام Android Keystore لمطوّري التطبيقات تخزين مفاتيح التشفير في معالج آمن مخصّص بالإضافة إلى بيئة التنفيذ المعزولة الموضّحة أعلاه. يُطلق على هذا المعالج الآمن المخصّص اسم StrongBox. تحدّد المتطلبات من C-1-3 إلى C-1-11 أدناه المتطلبات التي يجب أن يستوفيها الجهاز ليكون مؤهلاً كجهاز StrongBox.

عمليات تنفيذ الأجهزة التي تتضمّن معالجًا آمنًا مخصّصًا:

[C-SR-1] يُنصح بشدة بتوفير إمكانية استخدام StrongBox. من المرجّح أن يصبح استخدام StrongBox شرطًا في إصدار مستقبلي.

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع StrongBox، يجب أن:

[C-1-1] يجب الإفصاح عن FEATURE_STRONGBOX_KEYSTORE.
‫[C-1-2] يجب توفير جهاز آمن مخصّص يُستخدم لتخزين مفاتيح التشفير وضمان مصادقة المستخدم بشكل آمن. يمكن استخدام الأجهزة المخصّصة الآمنة لأغراض أخرى أيضًا.
‫[C-1-3] يجب أن تتضمّن وحدة معالجة مركزية منفصلة لا تشارك أي ذاكرة تخزين مؤقت أو ذاكرة وصول عشوائي ديناميكية (DRAM) أو معالجات مساعدة أو موارد أساسية أخرى مع معالج التطبيقات (AP).
[C-1-4] يجب التأكّد من أنّ أي أجهزة طرفية تتم مشاركتها مع معالج التطبيقات لا يمكنها تغيير معالجة StrongBox بأي شكل من الأشكال، أو الحصول على أي معلومات من StrongBox. يجوز لموفّر خدمة الدفع إيقاف إمكانية الوصول إلى StrongBox أو حظرها.
[C-1-5] يجب أن يتضمّن ساعة داخلية بدقة معقولة (‎+/- 10%) محصّنة ضد التلاعب بها من خلال نقطة الوصول.
[C-1-6] يجب أن يتضمّن مولّد أرقام عشوائية حقيقية ينتج ناتجًا غير متوقّع وموزّعًا بشكل منتظم.
[C-1-7] يجب أن تتوفّر فيها مقاومة للتلاعب، بما في ذلك مقاومة الاختراق المادي والتشويش.
‫[C-1-8] يجب أن تتوفّر فيها مقاومة القنوات الجانبية، بما في ذلك مقاومة تسريب المعلومات عبر القنوات الجانبية المتعلقة بالطاقة والتوقيت والإشعاع الكهرومغناطيسي والإشعاع الحراري.
[C-1-9] يجب أن يتضمّن مساحة تخزين آمنة تضمن سرية المحتوى وسلامته وأصالته واتساقه وحداثته. يجب ألا يكون التخزين قابلاً للقراءة أو التغيير، إلا بما تسمح به واجهات برمجة التطبيقات StrongBox.

لإثبات الامتثال للمتطلبات من [C-1-3] إلى [C-1-9]، يجب أن تتضمّن عمليات تنفيذ الأجهزة ما يلي:

[C-1-10] يجب أن تتضمّن الأجهزة الأجهزة التي تم اعتمادها وفقًا لملف حماية الدوائر المتكاملة الآمنة BSI-CC-PP-0084-2014 أو BSI-CC-PP-0117-2022، أو التي تم تقييمها من خلال مختبر اختبار معتمد على المستوى الوطني يشتمل على تقييم الثغرات الأمنية التي قد تؤدي إلى هجمات عالية الخطورة وفقًا لمعايير التطبيق المشترك لإمكانية تنفيذ الهجمات على البطاقات الذكية.
[C-1-11] يجب أن يتضمّن البرنامج الثابت الذي يتم تقييمه من خلال مختبر اختبار معتمد على المستوى الوطني تقييمًا لنقاط الضعف التي قد تؤدي إلى هجمات محتملة عالية وفقًا لمعايير التطبيق المشتركة لاحتمال الهجوم على البطاقات الذكية.
‫[C-SR-2] يُنصح بشدة بتضمين الأجهزة التي تم تقييمها باستخدام معيار أمان، ومستوى ضمان التقييم (EAL) 5، مع إضافة AVA_VAN.5. من المرجّح أن تصبح شهادة EAL 5 شرطًا أساسيًا في إصدار مستقبلي.
[C-SR-3] يُنصح بشدة بتوفير مقاومة للهجمات الداخلية (IAR)، ما يعني أنّه لا يمكن لأي شخص من الداخل لديه إذن بالوصول إلى مفاتيح توقيع البرامج الثابتة إنشاء برامج ثابتة تؤدي إلى تسريب أسرار StrongBox أو تجاوز متطلبات الأمان الوظيفي أو السماح بالوصول إلى بيانات المستخدمين الحسّاسة بأي طريقة أخرى. الطريقة المقترَحة لتنفيذ IAR هي السماح بتحديثات البرامج الثابتة فقط عند تقديم كلمة مرور المستخدم الأساسي من خلال IAuthSecret HAL.

‫9.11.3. بيانات اعتماد الهوية

يتم تحديد نظام بيانات اعتماد الهوية وتحقيقه من خلال تنفيذ جميع واجهات برمجة التطبيقات في حزمة android.security.identity.*. تسمح واجهات برمجة التطبيقات هذه لمطوّري التطبيقات بتخزين مستندات تعريف المستخدم واستردادها. عمليات تنفيذ الجهاز:

[C-SR-1] يُنصح بشدة بتنفيذ نظام بيانات اعتماد الهوية.

في حال تنفيذ أنظمة بيانات اعتماد الهوية على الأجهزة، يجب أن تتضمّن ما يلي:

[C-1-1] يجب أن تعرض الطريقة IdentityCredentialStore#getInstance() قيمة غير فارغة.
[C-1-2] يجب تنفيذ نظام بيانات اعتماد الهوية (مثل واجهات برمجة التطبيقات android.security.identity.*) باستخدام رمز يتواصل مع تطبيق موثوق به في منطقة معزولة بشكل آمن عن الرمز الذي يتم تنفيذه على النواة وما فوقها. يجب أن يحظر العزل الآمن جميع الآليات المحتملة التي قد يصل من خلالها رمز kernel أو رمز مساحة المستخدم إلى الحالة الداخلية للبيئة المعزولة، بما في ذلك الوصول المباشر إلى الذاكرة (DMA).
[C-1-3] يجب تنفيذ عمليات التشفير اللازمة لتنفيذ نظام بيانات اعتماد الهوية (مثل واجهات برمجة التطبيقات android.security.identity.*) بالكامل في التطبيق الموثوق به، ويجب ألا تغادر مواد المفتاح الخاص بيئة التنفيذ المعزولة أبدًا إلا إذا كانت مطلوبة تحديدًا من خلال واجهات برمجة التطبيقات ذات المستوى الأعلى (مثل طريقة createEphemeralKeyPair()).
[C-1-4] يجب تنفيذ التطبيق الموثوق به بطريقة لا تتأثر فيها خصائص الأمان (على سبيل المثال، لا يتم إصدار بيانات الاعتماد إلا عند استيفاء شروط التحكّم في الوصول، ولا يمكن إنشاء رموز MAC لبيانات عشوائية) حتى إذا كان Android يتصرف بشكل غير سليم أو تم اختراقه.

يوفّر مشروع Android المفتوح المصدر (AOSP) نموذجًا مرجعيًا لتطبيق موثوق به (libeic) يمكن استخدامه لتنفيذ نظام "مستند تعريف الهوية".

‫9.12. حذف البيانات

جميع عمليات تنفيذ الأجهزة:

[C-0-1] يجب توفير آلية للمستخدمين لإجراء "إعادة الضبط على الإعدادات الأصلية".
[C-0-2] يجب حذف جميع البيانات في نظام ملفات بيانات المستخدمين عند إجراء "إعادة الضبط على الإعدادات الأصلية".
[C-0-3] يجب حذف البيانات بطريقة تستوفي معايير الصناعة ذات الصلة، مثل معيار NIST SP800-88، عند إجراء "إعادة ضبط المصنع".
[C-0-4] يجب أن يتم تشغيل عملية "إعادة الضبط على الإعدادات الأصلية" المذكورة أعلاه عند استدعاء واجهة برمجة التطبيقات DevicePolicyManager.wipeData() من خلال تطبيق "وحدة التحكّم بسياسة الجهاز" الخاص بالمستخدم الأساسي.
قد يوفّر خيارًا سريعًا لمحو البيانات لا ينفّذ سوى محوًا منطقيًا للبيانات.

‫9.13. وضع التشغيل الآمن

يوفر نظام التشغيل Android "وضع التشغيل الآمن" الذي يتيح للمستخدمين تشغيل الجهاز في وضع لا يسمح إلا بتشغيل تطبيقات النظام المثبّتة مسبقًا، ويتم فيه إيقاف جميع التطبيقات التابعة لجهات خارجية. يوفّر هذا الوضع، المعروف باسم "وضع التشغيل الآمن"، للمستخدم إمكانية إلغاء تثبيت التطبيقات التابعة لجهات خارجية التي قد تتسبّب بضرر.

تتضمّن عمليات تنفيذ الأجهزة ما يلي:

[C-SR-1] يُنصح بشدة بتنفيذ "وضع التشغيل الآمن".

في حال تنفيذ الأجهزة "وضع التشغيل الآمن"، يجب أن تستوفي ما يلي:

[C-1-1] يجب أن يوفّر الجهاز للمستخدم خيارًا للدخول إلى "وضع التشغيل الآمن" بطريقة لا يمكن مقاطعتها من خلال التطبيقات التابعة لجهات خارجية المثبَّتة على الجهاز، إلا إذا كان التطبيق التابع لجهة خارجية هو وحدة تحكّم في سياسة الجهاز وتم ضبط العلامة UserManager.DISALLOW_SAFE_BOOT على "صحيح".
[C-1-2] يجب أن يوفّر الوضع الآمن للمستخدم إمكانية إلغاء تثبيت أي تطبيقات تابعة لجهات خارجية.
يجب أن يوفّر للمستخدم خيارًا للدخول إلى "الوضع الآمن" من قائمة التشغيل باستخدام سير عمل يختلف عن سير عمل التشغيل العادي.

‫9.14. عزل أنظمة المركبات

من المتوقّع أن تتبادل أجهزة Android Automotive البيانات مع الأنظمة الفرعية المهمة في المركبة باستخدام طبقة تجريد الأجهزة في المركبة لإرسال الرسائل وتلقّيها عبر شبكات المركبة، مثل ناقل CAN.

يمكن تأمين عملية تبادل البيانات من خلال تنفيذ ميزات الأمان أسفل طبقات إطار عمل Android لمنع التفاعل الضار أو غير المقصود مع الأنظمة الفرعية هذه.

‫9.15. خطط الاشتراك

تشير "خطط الاشتراك" إلى تفاصيل خطة علاقة الفوترة التي يقدّمها مشغّل شبكة جوّال من خلال SubscriptionManager.setSubscriptionPlans().

جميع عمليات تنفيذ الأجهزة:

[C-0-1] يجب عرض خطط الاشتراك فقط في تطبيق مشغّل شبكة الجوّال الذي قدّمها في الأصل.
[C-0-2] يجب عدم الاحتفاظ بنسخة احتياطية أو تحميل خطط الاشتراك عن بُعد.
[C-0-3] يجب السماح فقط بعمليات التجاوز، مثل SubscriptionManager.setSubscriptionOverrideCongested()، من تطبيق مشغّل شبكة الجوّال الذي يقدّم حاليًا خطط اشتراك صالحة.

‫9.16. نقل بيانات التطبيق

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية نقل البيانات من جهاز إلى آخر ولا تقتصر على بيانات التطبيق التي يتم نسخها إلى ما تم ضبطه من قِبل مطوّر التطبيق في ملف البيان من خلال السمة android:fullBackupContent، فإنّها:

[C-1-1] يجب عدم بدء عمليات نقل بيانات التطبيق من الأجهزة التي لم يضبط فيها المستخدم طريقة مصادقة أساسية كما هو موضّح في ‫9.11.1 قفل الشاشة والمصادقة الآمنة.
[C-1-2] يجب تأكيد عملية المصادقة الأساسية على الجهاز المصدر بشكل آمن، والتأكّد من نية المستخدم لنسخ البيانات على الجهاز المصدر قبل نقل أي بيانات.
[C-1-3] يجب استخدام مصادقة مفتاح الأمان للتأكّد من أنّ الجهاز المصدر والجهاز المستهدف في عملية نقل البيانات من جهاز إلى آخر هما جهازان شرعيان من أجهزة Android وبرنامج الإقلاع فيهما مقفل.
[C-1-4] يجب ألا يتم نقل بيانات التطبيق إلا إلى التطبيق نفسه على جهاز الاختبار، مع اسم الحزمة وشهادة التوقيع نفسها.
[C-1-5] يجب عرض إشارة في قائمة الإعدادات تفيد بأنّه تم نقل البيانات من الجهاز المصدر إلى الجهاز الجديد. يجب ألا يتمكّن المستخدم من إزالة هذا المؤشر.

‫9.17. ‫Android Virtualization Framework

تسمح واجهات برمجة التطبيقات (APIs) الخاصة بإطار عمل المحاكاة الافتراضية لنظام Android (AVF) (android.system.virtualmachine.*) للتطبيقات بإنشاء أجهزة افتراضية (VM) محمية (pVM) وغير محمية (non-pVM) على الجهاز، والتي يتم تحميلها وتشغيلها كملفات ثنائية أصلية كحمولة.

إذا ضبطت عمليات تنفيذ الأجهزة FEATURE_VIRTUALIZATION_FRAMEWORK على true، ستكون:

[C-1-1] يجب التأكّد من أنّ android.system.virtualmachine.VirtualMachineManager.getCapabilities() تعرض إحدى القيم التالية:
- CAPABILITY_PROTECTED_VM
- CAPABILITY_NON_PROTECTED_VM
- CAPABILITY_NON_PROTECTED_VM | CAPABILITY_PROTECTED_VM

‫9.18. التحقق من مطوّر البرامج

عمليات تنفيذ الأجهزة التي تحدّد مستوى واجهة برمجة التطبيقات 36.1 أو مستوى أعلى:

قد تتضمّن دعمًا لخدمة التحقّق من المطوّرين للتأكّد من أنّ التطبيقات صادرة عن مطوّر معروف.

عمليات تنفيذ الأجهزة التي تحدّد مستوى واجهة برمجة التطبيقات 36.1 أو أعلى وتضبط أداة التحقّق الخاصة بالمطوّرين من خلال تحديد config_developerVerificationServiceProviderPackageName في config.xml:

[9.18/C-1-1] يجب استدعاء android.content.pm.verify.developer.DeveloperVerifierService الذي تم ضبطه مع كل عملية تثبيت لحزمة تطبيق، بما في ذلك عمليات التثبيت الجديدة وتحديثات التطبيقات الحالية.

عمليات تنفيذ الأجهزة التي تحدّد مستوى واجهة برمجة التطبيقات 36.1 أو مستوى أعلى:

يمكن أن يضبط MAY أيضًا مفوّضًا لضبط السياسة النشطة من خلال تحديد config_developerVerificationPolicyDelegatePackageName في config.xml.

في حال ضبط أداة التحقّق الخاصة بالمطوّر، يجب أن تتضمّن عمليات تنفيذ الأجهزة ما يلي:

‫[9.18/C-2-1] يجب ألا يسمح إلا لأداة التحقّق من المطوّر أو المفوّض الذي تم إعداده بتحديد سياسة التثبيت على النحو المحدّد في android.content.pm.PackageInstaller.

إذا تم استدعاء أداة التحقّق كجزء من جلسة تثبيت حزمة، يجب أن تنفّذ الأجهزة ما يلي:

[9.18/C-3-1] يجب منع تثبيت حزمة تطبيق في الحالات التالية:
- يتعذّر إثبات هوية المطوِّر أثناء عملية التثبيت.
- يتم ضبط سياسة التحقّق من هوية المطوِّر لجلسة التثبيت على أي قيمة أخرى غير DEVELOPER_VERIFICATION_POLICY_NONE.
- ما لم ينطبق أي من البندين 9.18/C-3-2 أو 9.18/C-3-3.

[9.18/C-3-2] يجب عدم منع تثبيت حزمة تطبيق بغض النظر عن السياسة أو حالة التحقّق في الحالات التالية:
- يتم تثبيت الحزمة من خلال أداة Android Debug Bridge (ADB).
- الحزمة هي أداة التحقّق التي أعدّها المطوّر أو أداة التثبيت.

[9.18/C-3-3] يجب ألا يمنع الجهاز تثبيت حزمة تطبيق عند استيفاء جميع الشروط التالية:
- تم ضبط السياسة على DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_WARN أو DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_OPEN.
- يتم تسجيل حالة التحقّق على أنّها غير مكتملة.
- يشير برنامج التثبيت إلى أنّ المستخدم طلب صراحةً مواصلة عملية التثبيت من خلال إرسال DEVELOPER_VERIFICATION_USER_RESPONSE_INSTALL_ANYWAY.

قد يسمح بتثبيت حزمة تطبيق بغض النظر عن السياسة أو حالة التحقّق من عمليات التثبيت التي يبدأها مالك الجهاز على جهاز مُدار أو مالك الملف الشخصي على ملف شخصي مُدار، ولكن يُنصح بشدة بمنع عمليات التثبيت كما هو موضّح في 9.18/C-3-1.

10. اختبار توافق البرامج

يجب أن تجتاز عمليات تنفيذ الأجهزة جميع الاختبارات الموضّحة في هذا القسم. ومع ذلك، يُرجى العِلم أنّه لا توجد حزمة اختبار برامج شاملة تمامًا. لهذا السبب، يُنصح بشدة مصنّعي الأجهزة بإجراء أقل عدد ممكن من التغييرات على التنفيذ المرجعي والمفضّل لنظام Android المتاح من "مشروع مفتوح المصدر لنظام Android". سيؤدي ذلك إلى تقليل خطر حدوث أخطاء تؤدي إلى عدم التوافق وتتطلّب إعادة العمل والتحديثات المحتملة للأجهزة.

‫10.1. مجموعة أدوات اختبار التوافق

عمليات تنفيذ الجهاز:

[C-0-1] يجب اجتياز مجموعة أدوات اختبار التوافق (CTS) لنظام التشغيل Android المتاحة من "مشروع Android المفتوح المصدر"، وذلك باستخدام برنامج الشحن النهائي على الجهاز.
[C-0-2] يجب ضمان التوافق في حالات الغموض في مجموعة اختبار التوافق (CTS) وفي أي عمليات إعادة تنفيذ لأجزاء من رمز المصدر المرجعي.

تم تصميم مجموعة اختبار التوافق (CTS) ليتم تشغيلها على جهاز فعلي. وكما هو الحال مع أي برنامج، قد يحتوي CTS على أخطاء. سيتم إصدار إصدارات مختلفة من مجموعة اختبار التوافق بشكل مستقل عن تعريف التوافق هذا، وقد يتم إصدار مراجعات متعددة من مجموعة اختبار التوافق لنظام التشغيل Android 17.

عمليات تنفيذ الجهاز:

‫[C-0-3] يجب اجتياز أحدث إصدار من مجموعة أدوات اختبار التوافق (CTS) المتوفّر عند اكتمال برنامج الجهاز.
يجب استخدام التنفيذ المرجعي في شجرة Android مفتوحة المصدر قدر الإمكان.

‫10.2. أداة التحقّق في مجموعة أدوات اختبار التوافق (CTS)

يتم تضمين أداة CTS Verifier في مجموعة اختبار التوافق، وهي مصمّمة ليستخدمها مشغّل بشري لاختبار الوظائف التي لا يمكن اختبارها باستخدام نظام آلي، مثل الأداء السليم للكاميرا وأجهزة الاستشعار.

عمليات تنفيذ الجهاز:

[C-0-1] يجب تنفيذ جميع حالات التحقّق السارية في أداة التحقّق من توافق CTS بشكل صحيح.

يحتوي تطبيق CTS Verifier على اختبارات للعديد من أنواع الأجهزة، بما في ذلك بعض الأجهزة الاختيارية.

عمليات تنفيذ الجهاز:

[C-0-2] يجب اجتياز جميع الاختبارات الخاصة بالمكونات المادية المتوفرة في الجهاز، على سبيل المثال، إذا كان الجهاز مزودًا بمقياس تسارع، يجب أن ينفّذ بشكل صحيح حالة اختبار مقياس التسارع في CTS Verifier.

يمكن تخطّي أو حذف حالات الاختبار للميزات التي تم تصنيفها على أنّها اختيارية في "مستند تعريف التوافق".

[C-0-2] يجب أن يتم تشغيل أداة CTS Verifier بشكل صحيح على كل جهاز وكل إصدار، كما هو موضّح أعلاه. ومع ذلك، بما أنّ العديد من الإصدارات متشابهة جدًا، لا يُتوقّع من مطوّري الأجهزة تشغيل أداة CTS Verifier بشكل صريح على الإصدارات التي تختلف فقط بطرق بسيطة. وعلى وجه التحديد، يمكن أن تستغني عمليات تنفيذ الأجهزة التي تختلف عن عملية تنفيذ اجتازت اختبار CTS Verifier فقط من خلال مجموعة اللغات المضمّنة والعلامة التجارية وما إلى ذلك عن اختبار CTS Verifier.

11. البرامج القابلة للتحديث

[C-0-1] يجب أن تتضمّن عمليات تنفيذ الأجهزة آلية لاستبدال نظام التشغيل بأكمله. ولا يشترط أن تنفّذ الآلية ترقيات "مباشرة"، أي قد يكون من الضروري إعادة تشغيل الجهاز. يمكن استخدام أي طريقة، شرط أن تتمكّن من استبدال كل البرامج المثبّتة مسبقًا على الجهاز. على سبيل المثال، أي من الطرق التالية سيستوفي هذا الشرط:
- عمليات التنزيل "عبر شبكة غير سلكية (OTA)" مع التحديث بلا إنترنت من خلال إعادة التشغيل
- التحديثات "المربوطة" عبر USB من جهاز كمبيوتر مضيف
- التحديثات "بلا إنترنت" من خلال إعادة التشغيل والتحديث من ملف على وحدة تخزين قابلة للإزالة
[C-0-2] يجب أن تتيح آلية التحديث المستخدمة إجراء التحديثات بدون محو بيانات المستخدم. أي أنّ آلية التحديث يجب أن تحافظ على البيانات الخاصة بالتطبيق والبيانات المشترَكة للتطبيق. يُرجى العِلم أنّ برنامج Android الأساسي يتضمّن آلية تحديث تستوفي هذا الشرط.
[C-0-3] يجب توقيع التحديث بالكامل، ويجب أن تتحقّق آلية التحديث على الجهاز فقط من التحديث والتوقيع باستخدام مفتاح عام مخزَّن على الجهاز.
[C-SR-1] يُنصح بشدة باستخدام آلية التوقيع لتجزئة التحديث باستخدام SHA-256 والتحقّق من صحة التجزئة باستخدام المفتاح العام من خلال خوارزمية ECDSA NIST P-256.

إذا كانت عمليات تنفيذ الجهاز تتضمّن إمكانية استخدام اتصال بيانات غير محدود، مثل 802.11 أو ملف تعريف شبكة المنطقة الشخصية (PAN) عبر البلوتوث، فإنّها:

[C-1-1] يجب أن يتيح تنزيل تحديثات عبر الأثير (OTA) مع إمكانية التحديث بلا إنترنت من خلال إعادة التشغيل.

يجب أن تتحقّق عمليات تنفيذ الأجهزة من أنّ صورة النظام متطابقة ثنائيًا مع النتيجة المتوقّعة بعد إجراء تحديث عبر الأثير. إنّ تنفيذ تحديثات OTA المستندة إلى الحظر في "مشروع Android المفتوح المصدر"، والذي تمت إضافته منذ الإصدار 5.1 من Android، يستوفي هذا الشرط.

يجب أيضًا أن تتوافق عمليات تنفيذ الأجهزة مع تحديثات النظام من النوع أ/ب. تنفّذ حزمة AOSP هذه الميزة باستخدام طبقة تجريد الأجهزة (HAL) الخاصة بالتحكّم في عملية التشغيل.

إذا تم رصد خطأ في تنفيذ جهاز بعد طرحه ولكن خلال فترة عمره المعقولة المحدّدة بالتشاور مع فريق توافق Android، وكان هذا الخطأ يؤثر في توافق تطبيقات الجهات الخارجية، سيتم اتّخاذ الإجراءات التالية:

[C-2-1] على مطوّر الجهاز تصحيح الخطأ من خلال توفير تحديث للبرنامج يمكن تطبيقه وفقًا للآلية الموضّحة أعلاه.

يتضمّن نظام التشغيل Android ميزات تتيح لتطبيق "مالك الجهاز" (في حال توفّره) التحكّم في تثبيت تحديثات النظام. إذا كان النظام الفرعي لتحديث النظام للأجهزة يبلغ عن android.software.device_admin، يعني ذلك ما يلي:

[C-3-1] يجب تنفيذ السلوك الموضّح في فئة SystemUpdatePolicy.

12. سجلّ التغييرات في المستند

بدءًا من Android 16، لن يتم الاحتفاظ بسجلّ تغييرات بشكل منفصل. يتم تمييز جميع التغييرات من الإصدار السابق داخل هذا المستند.

13. التواصل معنا

يمكنك الانضمام إلى منتدى توافق Android وطرح أسئلة للحصول على توضيحات أو الإبلاغ عن أي مشاكل تعتقد أنّ المستند لا يغطّيها.

مستند تعريف معايير التوافق مع Android 17 تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

1. مقدمة

‫1.1 بنية المستند

‫1.1.1. المتطلبات حسب نوع الجهاز

‫1.1.2. معرّف المتطلبات

‫1.1.3. معرّف المتطلبات في القسم 2

2. أنواع الأجهزة

‫2.1 إعدادات الجهاز

2.2. متطلبات الأجهزة الجوّالة

2.2.1. الأجهزة

2.2.2. وسائط متعددة

2.2.3. برامج

‫2.2.4. الأداء والطاقة

‫2.2.5. نموذج الأمان

حظر المشاركة من خلال الإعدادات

‫2.2.6. التوافق مع أدوات وخيارات المطوّرين

‫2.2.7. فئة أداء أجهزة الوسائط المحمولة

2.2.7.1. الوسائط

‫2.2.7.2. الكاميرا

‫2.2.7.3. الأجهزة

‫2.2.7.4. الأداء

‫2.2.7.5. الرسومات

‫2.3. متطلبات التلفزيون

‫2.3.1. الأجهزة

‫2.3.2. وسائط متعددة

‫2.3.3. برامج

‫2.3.4. الأداء والطاقة

‫2.3.5. نموذج الأمان

‫2.3.6. التوافق مع أدوات وخيارات المطوّرين

‫2.4. متطلبات الساعة

2.4.1. الأجهزة

‫2.4.2. وسائط متعددة

‫2.4.3. برامج

‫2.4.4. الأداء والطاقة

‫2.4.5. نموذج الأمان

‫2.5. متطلبات السيارات

2.5.1. الأجهزة

‫2.5.2. وسائط متعددة

‫2.5.3. برامج

‫2.5.4. الأداء والطاقة

‫2.5.5. نموذج الأمان

‫2.5.6. التوافق مع أدوات وخيارات المطوّرين

‫2.6. متطلبات الجهاز اللوحي

2.6.1. الأجهزة

‫2.6.2. نموذج الأمان

‫2.6.2. برامج

3- برامج

‫3.1. توافق واجهة برمجة التطبيقات المُدارة

3.1.1. إضافات Android

3.1.2. مكتبة Android

3.2. توافق واجهة برمجة التطبيقات غير الصارم

3.2.1. الأذونات

‫3.2.2. مَعلمات الإنشاء

‫3.2.3. توافق النية

‫3.2.3.1. أهداف التطبيق الشائعة

‫3.2.3.2. حلّ النية

‫3.2.3.3. مساحات أسماء Intent

‫3.2.3.4. Broadcast Intents

‫3.2.3.5. Conditional Application Intents

‫3.2.4. الأنشطة على شاشات العرض الثانوية/المتعددة

‫3.3. توافُق واجهة برمجة التطبيقات الأصلية

‫3.3.1. واجهات التطبيق الثنائية

‫3.3.2. توافق الرمز البرمجي الأصلي ARM بنظام 32 بت

‫3.4. توافق الويب

‫1.4.3. توافق WebView

‫3.4.2. توافق المتصفّح

‫3.5. توافُق سلوك واجهة برمجة التطبيقات

‫3.5.1. قيود التطبيق

‫3.5.2. إسبات التطبيق

‫3.6. مساحات أسماء واجهة برمجة التطبيقات

‫3.7. التوافق مع وقت التشغيل

‫3.8. توافق واجهة المستخدم

‫3.8.1. مشغّل التطبيقات (الشاشة الرئيسية)

‫3.8.2. التطبيقات المصغَّرة

‫3.8.3. الإشعارات

‫3.8.3.1. عرض الإشعارات

‫3.8.3.2. خدمة تلقّي الإشعارات الصوتية

‫3.8.3.3. وضع "عدم الإزعاج" / وضع الأولوية

‫3.8.3.4. حماية الإشعارات الحساسة

‫4.8.3. واجهات برمجة التطبيقات الخاصة بالمساعدة

مستند تعريف معايير التوافق مع Android 17