تعريف التوافق مع Android 13

1. المقدّمة

يوضِّح هذا المستند المتطلبات التي يجب استيفاؤها لتصبح الأجهزة متوافقة مع Android 13.

ينطبق استخدام "يجب" و"يجب ألا" و"مطلوب" و"SHALL" و"SHALL NOT" و"SHOULD" و"SHOULD NOT" و"RECOMMENDED" و"MAY" و "OPTIONAL" على معيار مجموعة مهندسي شبكة الإنترنت (IETF) المحدَّد في RFC2119.

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

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

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

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

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

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

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

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

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

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

يتم تعيين معرّف الطلب لمتطلبات "يجب".

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

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

• رقم تعريف نوع الجهاز (يمكنك الاطّلاع على مزيد من المعلومات في 2. أنواع الأجهزة)
  • ج: الأساسية (المتطلبات التي يتم تطبيقها على جميع عمليات تنفيذ أجهزة Android)
  • H: جهاز Android محمول
  • T: جهاز تلفزيون Android
  • A: تنفيذ نظام التشغيل Android Automotive
  • W: استخدام ساعة Android Watch
  • علامة التبويب: استخدام جهاز 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 على أنّها "أجهزة محمولة باليد" إذا استوفت جميع المعايير التالية:

• يجب أن يتوفّر لديك مصدر طاقة يتيح التنقّل، مثل البطارية.
• أن يكون حجم الشاشة القطري 3.3 بوصة (أو 2.5 بوصة لتنفيذ الأجهزة التي يتم شحنها إلى المستوى 29 من واجهة برمجة التطبيقات أو مستوى أقدم) إلى 8 بوصة.

تتعلق المتطلبات الإضافية في بقية هذا القسم بعمليات تنفيذ الأجهزة المحمولة بنظام Android.

ملاحظة: يتم وضع علامة * على المتطلبات التي لا تنطبق على أجهزة Android اللوحية.

2.2.1. الأجهزة

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

• يجب أن يحتوي [7.1.1.1/H-0-1] على شاشة واحدة على الأقل متوافقة مع Android وتفي بجميع المتطلبات الموضّحة في هذا المستند.

• [7.1.1.3/H-SR-1] يُنصَح باستخدامها بشدة لإتاحة إمكانية تغيير حجم العرض (كثافة الشاشة) للمستخدمين.

• [7.1.1.1/H-0-2] يجب أن يتوافق مع تركيب وحدة معالجة الرسومات للوحدات الاحتياطية للرسومات، بحجم لا يقل عن أعلى درجة دقة لأي شاشة مُدمَجة.

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

• [7.1.1.1/H-1-1]* يجب أن تجعل الشاشة المنطقية المتاحة للتطبيقات التابعة للجهات الخارجية بمسافة لا تقل عن 2 بوصة على الحواف القصيرة و2.7 بوصة على الحواف الطويلة. وقد تُستثنى من هذا الشرط الأجهزة التي تم شحنها إلى المستوى 29 من واجهة برمجة تطبيقات Android أو مستوى أقدم.

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

• [7.1.1.1/H-2-1]* يجب أن تجعل الشاشة المنطقية المتاحة للتطبيقات التابعة للجهات الخارجية على الأقل 2.7 بوصة على الحواف القصيرة. وقد تُستثنى من هذا الشرط الأجهزة التي تم شحنها إلى المستوى 29 من واجهة برمجة تطبيقات Android أو مستوى أقدم.

إذا طالبت عمليات تنفيذ الأجهزة المحمولة باليد بتوافقها مع أنظمة العرض ذات النطاق الديناميكي العالي من خلال 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] يجب أن يتم الإبلاغ عنه كنتائج لأثر أوّلي يتوافق مع مخطط عدّادات وحدة معالجة الرسومات ومراحل عرض وحدة معالجة الرسومات المحدّدة في مستندات Perfetto.
• [7.1.4.6/H-1-2] يجب أن يتم الإبلاغ عن قيم مطابقة لعدّات وحدة معالجة الرسومات في الجهاز، وذلك باتّباع نموذج تتبُّع عدّاد وحدة معالجة الرسومات (gpu).
• [7.1.4.6/H-1-3] يجب أن يتم الإبلاغ عن قيم مطابقة لمراحل عرض وحدة معالجة الرسومات في الجهاز بعد نموذج تتبع مرحلة العرض.
• [7.1.4.6/H-1-4] يجب أن يتم الإبلاغ عن نقطة تتبُّع لمعدّل تكرار وحدة معالجة الرسومات على النحو المحدّد في التنسيق: 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 (نظام تحديد المواقع العالمي (GPS)) وتُبلغ التطبيقات عن إمكانات الميزة من خلال الإبلاغ عن الميزة android.hardware.location.gps، سيتم إجراء ما يلي:

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

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

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

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

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

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

• [7.3.11/H-SR-1] مقترحان بشدة لدعم أداة استشعار الوضعية مع 6 درجات من الحرية.
• [7.4.3/H] يجب أن يتوفر التوافق مع Bluetooth وBluetooth LE.

إذا كانت الأجهزة تتوافق مع بروتوكول الاتصال بشبكة Wi-Fi المجاورة (NAN) من خلال الإعلان عن PackageManager.FEATURE_WIFI_AWARE وعرض الموقع الجغرافي لشبكة Wi-Fi (الوقت ذهابًا وإيابًا عبر شبكة Wi-Fi والمراسلة النصية في الوقت الفعلي) من خلال الإعلان عن السمة PackageManager.FEATURE_WIFI_RTT، سيتم إجراء ما يلي:

• [7.4.2.5/H-1-1] يجب أن يبلغ النطاق بدقة في نطاق يتراوح بين 6 و1/2 في المئة في نطاق 5 متر و5 متر في نطاق ترددي يصل إلى 1.8 متر في النطاق الترددي 160 ميغاهرتز في النطاق المئوي 68 ميغاهرتز (وفقًا لحسابات دالة التوزيع التراكمي)، في نطاق تردد يبلغ 80 ميغاهرتز عند النطاق الترددي 68 ميغاهرتز، +/-4 متر عند النطاق الترددي 40 ميغاهرتز.

• [7.4.2.5/H-SR-1] ننصح بشدة بأن يتم قياس نطاق البيانات من 9.5 في المئة في نطاق 1/1، عند نطاق 0 في المئة بنطاق ترددي يتراوح من 0 إلى 9 سم في نطاق 0.5 في المئة ونطاقه في نطاق +/-1 ميغاهرتز عند النطاق المئوي 160 ميغاهرتز (وفقًا لحساب الدالة التراكمية)، ومقياس نطاق Wi-Fi 0 في المئة عند نطاق ترددي يبلغ 90 ميغاهرتز عند نطاق تردد يبلغ 90 ميغاهرتز.

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

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

• يجب أن يتضمّن [7.5.4/H-1-1] مجال رؤية عاديًا (FOV) تلقائيًا ويجب أن يتراوح بين 50 و95 درجة.

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

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

في حال كانت عمليات تنفيذ الأجهزة المحمولة تشير إلى توافق واجهة التطبيق الثنائية (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 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم درجات دقة للمخزن المؤقت للإطارات تصل إلى QUD (على سبيل المثال، 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 ميغابايت إذا كانت الشاشة التلقائية تستخدم درجات دقة مخزن مؤقت للإطارات تصل إلى QUD (على سبيل المثال، QWXGA).

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

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

• [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] يجب أن يتوافق مع واجهة ABI واحدة فقط (إما 64 بت فقط أو 32 بت فقط).

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

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

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

• [7.7.1/H-1-1] يجب أن يتم تنفيذ واجهة برمجة تطبيقات "ملحق Android المفتوح" (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:

الوظيفة	عمليات التعيين	السياق	السُلوك
جيم	صفحة استخدام HID: 0x0C استخدام HID: 0x0CD مفتاح النواة: KEY_PLAYPAUSE مفتاح Android: KEYCODE_MEDIA_PLAY_PAUSE	تشغيل الوسائط	الإدخال: ضغط قصير الإخراج: تشغيل أو إيقاف مؤقت
			الإدخال: اضغط مع الاستمرار الإخراج: تشغيل الطلب الصوتي عمليات الإرسال: android.speech.action.VOICE_SEARCH_HANDS_FREE إذا كان الجهاز مقفلاً أو شاشته مغلقة. يتم إرسال android.speech.RecognizerIntent.ACTION_WEB_SEARCH بخلاف ذلك
		مكالمة واردة	الإدخال: ضغط قصير الإخراج: قبول المكالمة
			الإدخال: ضغط مع الاستمرار الإخراج: رفض المكالمة
		مكالمة جارية	الإدخال: ضغط قصير الإخراج: إنهاء المكالمة
			الإدخال: الضغط مع الاستمرار الإخراج: كتم صوت الميكروفون أو إعادته
مليار	صفحة استخدام 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 في أقل من 1,000 مللي ثانية.

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

• يجب أن يكون وقت الاستجابة المستمر ذهابًا وإيابًا [5.6/H-1-1] 500 مللي ثانية أو أقل من 5 قياسات، مع متوسط انحراف مطلق أقل من 50 ملي ثانية، عبر مسارات البيانات التالية: "مكبّر الصوت إلى الميكروفون"، محوِّل استرجاع 3.5 ملم (إذا كان متوافقًا)

• [5.6/H-1-2] يجب أن يبلغ متوسط وقت استجابة "النقر للنغمة" 500 مللي ثانية أو أقل من 5 قياسات على الأقل عبر مسار بيانات مكبّر الصوت إلى الميكروفون.

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

• [7.10/H]* يجب عدم استخدام كتلة دوّارة غريبة الأطوار (ERM) مشغّلة باللمس (هزّاز).
• [7.10/H]* يجب أن يكون موضع تشغيل المشغّل بالقرب من المكان الذي يتم فيه عادةً مسك الجهاز أو لمسه باليد.
• [7.10/H]* يجب تنفيذ جميع الثوابت العامة لكل اللمسات الواضحة في android.view.HapticFeedbackConstants تحديدًا (CLOCK_TICK وCONTEXT_نقرة وKEYBOARD_PRESS وKEYBOARD_Release وKEYBOARD_TAP وLOW_TEXT_PRESS
• [7.10/H]* يجب تنفيذ جميع الثوابت العامة لللمس الواضح في android.os.VibrationEffect على سبيل المثال (للمؤثرات_TICK، مؤثرات_النقرة، مؤثرات عرض الشاشة، ومؤثراتPRIMITIVE_* وقد يكون بعض هذه العوامل الأساسية، مثل LOW_TICK وSPIN، ممكنًا فقط إذا كان الهزّاز يتيح استخدام الترددات المنخفضة نسبيًا.

• [7.10/H]* يجب اتّباع الإرشادات المتعلقة بتعيين الثوابت العامة في android.view.HapticFeedbackConstants الثابتة في android.os.VibrationEffect، مع علاقات السعة المقابلة.

• [7.10/H]* يجب اتّباع تقييم الجودة لواجهات برمجة التطبيقات createOneShot() وcreateWaveform() لواجهات برمجة التطبيقات.

• يجب التحقّق [7.10/H]* من أنّ نتيجة واجهة برمجة التطبيقات android.os.Vibrator.hasAmplitudeControl() المتاحة للجميع تعكس إمكانيات الهزّاز بشكل صحيح.

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

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

• يجب تحريك [7.10/H]* للمشغّل باللمس على المحور "س" (من اليسار إلى اليمين) في الاتجاه العمودي.

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

• [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.2/H-0-1] H.264 AVC
• [5.2/H-0-2] VP8

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

• [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

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]* يجب أن يتم تحميل تطبيق أو مكوّن خدمة واحدًا أو أكثر مسبقًا باستخدام معالج أهداف، وذلك لجميع أنماط فلاتر الأهداف العامة التي تحدّدها أغراض التطبيقات التالية والمدرَجة هنا.
• [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-SR-1] يُنصح بشدة بأن يتم استخدام مشغّل تشغيل تلقائي يتيح تثبيت الاختصارات والتطبيقات المصغّرة والميزات المصغَّرة داخل التطبيق.
• [3.8.1/H-SR-2] يُنصح بشدة بتنفيذ مشغّل تشغيل تلقائي يوفّر إمكانية الوصول السريع إلى الاختصارات الإضافية التي توفّرها التطبيقات التابعة لجهات خارجية من خلال واجهة برمجة التطبيقات ShortcutManager.
• [3.8.1/H-SR-3] يُنصح بشدة بتضمين تطبيق مشغّل افتراضي يعرض شارات لرموز التطبيقات.
• [3.8.2/H-SR-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] على مركز للإشعارات يوفر للمستخدم إمكانية التحكم المباشر في الإشعارات (على سبيل المثال، الرد أو التأجيل أو الإزالة أو الحظر) من خلال ميزات المستخدم مثل أزرار الإجراءات أو لوحة التحكم كما هو موضح في 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] يُنصَح باستخدامها بشدة لإتاحة إمكانية وصول المستخدم (على سبيل المثال، أداة تبديل المخرجات) التي يمكن الوصول إليها من واجهة مستخدم النظام، والتي تسمح للمستخدمين بالتبديل بين مسارات الوسائط المتاحة المناسبة (على سبيل المثال، أجهزة البلوتوث والمسارات المتوفّرة في النطاق MediaRouter2Manager) عندما ينشر أحد التطبيقات إشعارًا MediaStyle يتضمّن MediaSession.

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

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

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

• [3.8.4/H-1-1]* يجب أن يعرض إشعارات المحادثات قبل الإشعارات غير المتعلقة بالمحادثة، باستثناء الإشعارات المستمرة لتلك الخدمة التي تعمل في المقدّمة وإشعارات important: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-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-1 أو تجاوزها (للغات المتوافقة مع محرّك تحويل النص إلى كلام المثبّت مسبقًا) على النحو المقدَّم في مشروع TalkBack المفتوح المصدر.
• [3.11/H-0-1] يجب أن يتيح تثبيت محركات تحويل النص إلى كلام التابعة لجهات خارجية.
• [3.11/H-SR-1] يُنصَح بشدة بتضمين محرّك TTS يتوافق مع اللغات المتاحة على الجهاز.
• [3.13/H-SR-1] يُنصح بشدة بتضمين مكون واجهة مستخدم الإعدادات السريعة.

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

• [3.16/H-1-1] يجب أن تتوافق مع ميزة إقران الجهاز المصاحب.

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

• [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_PARAM_DEEP_LINK_ACTIVITY عند تفعيل وظيفة التقسيم. يجب أن يكون النشاط محميًا بواسطة android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK، ويجب أن يبدأ نشاط Intent الذي تم تحليله من Settings#EXTRA_SETTINGS_DOCUMENTDED_DEEP_LINK_INTENT_URI.

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

• [8.1/H-0-1] وقت استجابة عرض ثابت: يجب ألا يحدث وقت استجابة غير متسق أو تأخير في عرض الإطارات أكثر من 5 إطارات في الثانية، ويجب أن يقل عن 1 إطار في الثانية.
• [8.1/H-0-2] وقت استجابة واجهة المستخدم: يجب أن تضمن عمليات تنفيذ الأجهزة حصول المستخدم على وقت استجابة سريع من خلال تمرير قائمة تضم 10 آلاف إدخال من القائمة على النحو المحدّد في "مجموعة أدوات اختبار التوافق مع Android" (CTS) في أقل من 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] يجب أن تبلغ عن استهلاك طاقة وحدة المعالجة المركزية وفقًا للمعرّف الفريد لكل عملية. يلبي "المشروع المفتوح المصدر لنظام 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.
  • قد تُستثنى بعض التطبيقات من أن يتم إيقافها أو أن يتم إدراجها ضِمن هذه التطبيقات حتى الآن، كما هو موضّح في مستند حزمة تطوير البرامج (SDK).

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

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

• [9.1/H-0-1] يجب أن يسمح للتطبيقات التابعة لجهات خارجية بالوصول إلى إحصاءات الاستخدام من خلال إذن android.permission.PACKAGE_USAGE_STATS وتوفير آلية يمكن للمستخدمين الوصول إليها لمنح أو إبطال أذونات الوصول إلى هذه التطبيقات استجابة لنية android.settings.ACTION_USAGE_ACCESS_SETTINGS.

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

• [9.11/H-0-2] يجب إجراء نسخ احتياطي لتنفيذ ملف تخزين المفاتيح باستخدام بيئة تنفيذ معزولة.
• يجب أن يتضمن [9.11/H-0-3] تطبيقات لخوارزميات التشفير RSA وAES وECDSA وHMAC، بالإضافة إلى وظائف تجزئة MD5 وSHA1 وعائلة SHA-2 للتوافق بشكل مناسب مع خوارزميات نظام Android Keystore في منطقة معزولة بشكل آمن عن الرمز الذي يعمل على النواة والإصدارات الأحدث. يجب أن تحظر ميزة العزل الآمن جميع الآليات المحتملة التي يمكن من خلالها وصول رمز النواة أو رمز مساحة المستخدم إلى الحالة الداخلية للبيئة المعزولة، بما في ذلك قانون الأسواق الرقمية. يفي "المشروع المفتوح المصدر لنظام Android" (AOSP) بهذا الشرط من خلال استخدام تنفيذ Trusty، غير أنّ الخيارات البديلة هي أحد الحلول البديلة المستندة إلى ARM TrustZone أو إحدى الجهات الخارجية التي تمت مراجعتها بشكل آمن ومستند إلى برنامج Hypervisor (مراقب الأجهزة الظاهرية).
• يجب أن ينفِّذ [9.11/H-0-4] مصادقة شاشة القفل في بيئة التنفيذ المعزولة، ولا يسمح باستخدام المفاتيح المرتبطة بالمصادقة إلا عند نجاح هذه العملية. يجب تخزين بيانات اعتماد شاشة القفل بطريقة تسمح لبيئة التنفيذ المعزولة فقط بإجراء مصادقة شاشة القفل. يوفّر "المشروع المفتوح المصدر لنظام Android" طبقة استخلاص أجهزة Gatekeeper ونظام Trusty اللذَين يمكن استخدامهما لاستيفاء هذا الشرط.
• [9.11/H-0-5] يجب أن يتوافق مع مصادقة المفتاح حيث يكون مفتاح توقيع المصادقة محميًا باستخدام أجهزة آمنة ويتم التوقيع في أجهزة آمنة. يجب مشاركة مفاتيح توقيع المصادقة على عدد كبير بما يكفي من الأجهزة لمنع استخدام المفاتيح كمعرّفات للأجهزة. وتتمثّل إحدى طرق استيفاء هذا الشرط في مشاركة مفتاح المصادقة نفسه ما لم يتم إنتاج 100,000 وحدة على الأقل من رمز تخزين تعريفي معيّن. في حال إنتاج أكثر من 100,000 وحدة من رمز التخزين التعريفي، قد يتم استخدام مفتاح مختلف لكل 100,000 وحدة.
• يجب أن يفصح الإصدار [9/H-0-1] عن ميزة "android.hardware.security.model.com".

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

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

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

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

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

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

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

يتيح Android، من خلال واجهة برمجة تطبيقات VoiceInteractionService، آلية رصد الكلمة المفتاح التي تكون قيد التشغيل دائمًا والآمنة، بدون الحاجة إلى مؤشر الوصول إلى الميكروفون.

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

• [9.8/H-1-1] يجب التأكد من أن خدمة الكشف عن الكلمة المفتاح لا يمكنها نقل البيانات إلا إلى النظام أو ContentCaptureService
• [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-SR-1] يُوصى بشدة بإبلاغ المستخدمين قبل إعداد تطبيق كمقدم لخدمة اكتشاف الكلمة المفتاح.
• [9.8/H-SR-2] يُوصى بشدة بمنع نقل البيانات غير المنظَّمة خارج خدمة كشف الكلمات المفتاح.
• [9.8/H-SR-3] يُوصى بشدة بإعادة تشغيل العملية التي تستضيف خدمة اكتشاف الكلمة المفتاح مرة واحدة على الأقل كل ساعة أو كل 30 حدثًا لتشغيل الجهاز، أيهما يحدث أولاً.

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

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

إذا كانت عمليات تنفيذ الأجهزة المحمولة تشير إلى 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()، إلى جانب أي رسائل تحديد مرتبطة بها.

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

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

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

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

• [6.1/H-0-1]* يجب أن يتوافق مع أمر الغلاف cmd testharness.

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

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

2.2.7. صف أداء الوسائط المحمولة

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

2.2.7.1. الوسائط

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

• أن يستوفي متطلبات الوسائط المدرَجة في القسم 2.2.7.1 في Android 12 CDD

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

• [5.1/H-1-1] يجب الإعلان عن الحد الأقصى لعدد جلسات برنامج فك ترميز الفيديوهات على الأجهزة التي يمكن تشغيلها بشكل متزامن في أي مجموعة من برامج الترميز من خلال طريقتَي CodecCapabilities.getMaxSupportedInstances() وVideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-2] يجب أن يتوفر في 6 حالات لجلسات برنامج فك ترميز الفيديو على الجهاز (AVC أو HEVC أو VP9 أو AV1 أو أحدث) في أي مجموعة برامج ترميز يتم تشغيلها بدرجة دقة 1080p بسرعة 30 لقطة في الثانية.
• [5.1/H-1-3] يجب الإعلان عن الحد الأقصى لعدد جلسات برنامج ترميز الفيديو على الأجهزة التي يمكن تشغيلها بالتزامن في أي تركيبة من برامج الترميز عبر طريقتَي CodecCapabilities.getMaxSupportedInstances() وVideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-4] يجب أن يتوفر في 6 نسخ من جلسات برنامج ترميز الفيديو على الجهاز (AVC أو HEVC أو VP9 أو AV1 أو أحدث) في أي مجموعة برامج ترميز يتم تشغيلها بالدقة 1080p بسرعة 30 لقطة في الثانية.
• [5.1/H-1-5] يجب الإعلان عن الحد الأقصى لعدد جلسات برنامج ترميز الفيديو والأجهزة التي يمكن تشغيلها بالتزامن في أي تركيبة من برامج الترميز عبر طريقتَي CodecCapabilities.getMaxSupportedInstances() وVideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-6] يجب أن يتوفّر في 6 نسخ من برنامج فك ترميز الفيديو على الجهاز وجلسات ترميز الفيديوهات على الأجهزة (AVC أو HEVC أو VP9 أو AV1 أو الإصدارات الأحدث) في أي مجموعة برامج ترميز يتم تشغيلها بالتزامن بدقة 1080p بسرعة 30 لقطة في الثانية.
• [5.1/H-1-7] يجب أن يبلغ وقت استجابة إعداد برنامج الترميز 40 ملي ثانية أو أقل لجلسة ترميز الفيديو بدقة 1080p أو أقل لجميع برامج ترميز الفيديو للأجهزة عندما يكون قيد التحميل. يُعرَّف التحميل هنا على أنه جلسة متزامنة لتحويل ترميز الفيديو بين 1080p و720p باستخدام برامج ترميز الفيديو للأجهزة بالإضافة إلى إعداد تسجيل الصوت والفيديو بدقة 1080p. بالنسبة إلى برنامج ترميز Dolby Vision، يجب أن يبلغ وقت استجابة إعداد برنامج الترميز 50 ملي ثانية أو أقل.
• [5.1/H-1-8] يجب أن يبلغ وقت استجابة إعداد برنامج الترميز 30 ملي ثانية أو أقل لجلسة ترميز صوتي بمعدل 128 كيلوبت في الثانية أو بمعدل نقل بيانات أقل لجميع برامج ترميز الصوت عندما تكون قيد التحميل. يُعرَّف التحميل هنا على أنّه جلسة متزامنة لتحويل ترميز الفيديو بين 1080p و720p باستخدام برامج ترميز الفيديو على الأجهزة بالإضافة إلى إعداد تسجيل الصوت والفيديو بدقة 1080p.
• [5.1/H-1-9] يجب أن يتوفر في نسختين لجلسات فك ترميز فيديو الأجهزة الآمنة (AVC أو HEVC أو VP9 أو AV1 أو أحدث) في أي مجموعة برامج ترميز يتم تشغيلها بالدقة 1080p بسرعة 30 لقطة في الثانية.
• [5.1/H-1-10] يجب أن يتم توفير 3 جلسات لجلسات فك ترميز الفيديوهات على الأجهزة غير الآمنة مع جلسة واحدة لجلسة فك ترميز الفيديوهات على الأجهزة الآمنة (إجمالي 4 مثيلات) (AVC أو HEVC أو VP9 أو AV1 أو أحدث) في أي مجموعة برامج ترميز يتم تشغيلها بالتزامن بدقة 1080p بسرعة 30 لقطة في الثانية.
• [5.1/ H-1-11] يجب أن يتوافق مع برنامج فك ترميز آمن لكل برنامج فك ترميز AVC أو HEVC أو VP9 أو AV1 على الجهاز.
• [5.1/H-1-12] يجب أن يبلغ وقت استجابة إعداد برنامج الترميز 40 ملي ثانية أو أقل لجلسة فك ترميز الفيديوهات بدقة 1080p أو أقل لجميع برامج فك ترميز الفيديوهات على الأجهزة عندما تكون قيد التحميل. يُعرف التحميل هنا على أنه جلسة متزامنة لتحويل ترميز الفيديو بين 1080p و720p باستخدام برامج ترميز الفيديو للأجهزة بالإضافة إلى إعداد تشغيل الصوت والفيديو بدقة 1080p. بالنسبة إلى برنامج ترميز Dolby Vision، يجب أن يبلغ وقت استجابة إعداد برنامج الترميز 50 ملي ثانية أو أقل.
• [5.1/H-1-13] يجب أن يبلغ وقت استجابة إعداد برنامج الترميز 30 ملي ثانية أو أقل لجلسة فك ترميز الصوت بمعدل 128 كيلوبت في الثانية أو أقل لجميع برامج فك ترميز الصوت عندما تكون قيد التحميل. يُعرَّف التحميل هنا على أنّه جلسة متزامنة لتحويل ترميز الفيديو بين 1080p و720p باستخدام برامج ترميز الفيديو على الأجهزة بالإضافة إلى إعداد تشغيل الصوت والفيديو بدقة 1080p.
• [5.1/H-1-14] يجب أن يتوافق مع برنامج فك ترميز الأجهزة AV1 الرئيسي 10، المستوى 4.1.
• [5.1/H-SR-1] يُوصى بها بشدة لإتاحة استخدام Film Grain مع برنامج فك ترميز أجهزة AV1.
• يجب أن يحتوي [5.1/H-1-15] على برنامج فك ترميز فيديو واحد على الأقل يتوافق مع 4K60.
• يجب أن يتوفّر في الأجهزة [5.1/H-1-16] برنامج ترميز فيديو واحد على الأقل متوافق مع دقة 4K60.
• [5.3/H-1-1] يجب ألا يتم إسقاط أكثر من إطار واحد خلال 10 ثوانٍ (أي أقل من 0.167 في المئة من انخفاض اللقطات) في جلسة فيديو بدقة 1080p بمعدّل 60 لقطة في الثانية قيد التحميل. يُعرف التحميل على أنّه جلسة متزامنة لتحويل ترميز الفيديو بين 1080p و720p باستخدام برامج ترميز الفيديو على الأجهزة، بالإضافة إلى تشغيل الصوت بتنسيق AAC بسرعة 128 كيلوبت في الثانية وبسرعة 128 كيلوبت في الثانية.
• [5.3/H-1-2] يجب ألا يتم إسقاط أكثر من إطار واحد خلال 10 ثوانٍ أثناء تغيير درجة دقة الفيديو في جلسة فيديو بمعدّل 60 لقطة في الثانية أثناء التحميل. يُعرف التحميل على أنّه جلسة متزامنة لتحويل ترميز الفيديو فقط تتراوح بين 1080p و720p باستخدام برامج ترميز الفيديو على الأجهزة، بالإضافة إلى تشغيل الصوت بتنسيق AAC بسرعة 128 كيلوبت في الثانية وبسرعة 128 كيلوبت في الثانية.
• [5.6/H-1-1] يجب أن يكون وقت استجابة النقر للنغمات 80 مللي ثانية أو أقل باستخدام اختبار النقر للنغمات في OboeTester أو اختبار CTS Verifier انقر للنغمات.
• [5.6/H-1-2] يجب أن يكون وقت استجابة الصوت ذهابًا وإيابًا 80 ملي ثانية أو أقل عبر مسار بيانات واحد متوافق على الأقل.
• [5.6/H-1-3] يجب أن يتوافق مع صوت أكبر من أو يساوي 24 بت لإخراج صوت استيريو يزيد عن مقابس صوت 3.5 ملم في حال توفّرها ومع الصوت عبر USB إذا كان ذلك متاحًا من خلال مسار البيانات بالكامل لإعدادات البث ووقت الاستجابة المنخفض. لإعداد وقت الاستجابة المنخفض، يجب أن يستخدم التطبيق AAudio في وضع معاودة الاتصال بوقت الاستجابة المنخفض. بالنسبة إلى إعدادات البث، يجب أن يستخدم التطبيق مقطعًا صوتيًا Java. في كل من إعدادات وقت الاستجابة المنخفض والبث، يجب أن يقبل حوض إخراج HAL إما AUDIO_FORMAT_PCM_24_BIT أو AUDIO_FORMAT_PCM_24_BIT_PACKED أو AUDIO_FORMAT_PCM_32_BIT أو AUDIO_FORMAT_PCM_FLOAT لتنسيق الإخراج المستهدف.
• [5.6/H-1-4] يجب أن يتوافق مع أكثر من = 4 أجهزة صوت USB (تُستخدم هذا بواسطة وحدات التحكم في DJ لمعاينة الأغاني.)
• [5.6/H-1-5] يجب أن تتوافق مع أجهزة MIDI المتوافقة مع الفئة وأن تعلن عن علامة ميزة MIDI.
• [5.7/H-1-2] يجب أن يكون متوافقًا مع MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL مع إمكانات فك تشفير المحتوى الواردة أدناه.

الحد الأدنى لحجم العينة	4 مبيبايت
الحد الأدنى لعدد العيّنات الفرعية: H264 أو HEVC	32
الحد الأدنى لعدد العيّنات الفرعية - VP9	9
الحدّ الأدنى لعدد العيّنات الفرعية: AV1	288
الحد الأدنى لحجم ذاكرة التخزين المؤقت للعينة الفرعية	1 مبيبايت
الحد الأدنى لحجم المخزن المؤقت العام للعملات المشفّرة	500 كيبيبايت
الحد الأدنى لعدد الجلسات المتزامنة	30
الحد الأدنى لعدد المفاتيح في كل جلسة	20
الحد الأدنى لإجمالي عدد المفاتيح (جميع الجلسات)	80
الحد الأدنى لإجمالي عدد مفاتيح DRM (جميع الجلسات)	6
حجم الرسالة	16 كيبيبايت
اللقطات غير المشفّرة في الثانية	60 لقطة في الثانية

2.2.7.2. الكاميرا

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

• يجب أن يفي بمتطلبات الكاميرا الواردة في القسم 2.2.7.2 في android 12.

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

• [7.5/H-1-1] يجب أن تحتوي على كاميرا خلفية أساسية بدقة لا تقل عن 12 ميغابكسل تتيح التقاط الفيديو بمعدل 4k بسرعة 30 لقطة في الثانية. الكاميرا الخلفية الأساسية هي الكاميرا الخلفية التي تتضمّن معرّفًا أدنى للكاميرا.
• [7.5/H-1-2] يجب أن تتوفر كاميرا أمامية رئيسية ذات دقة لا تقل عن 5 ميغابكسل، وتتيح التقاط فيديو بدقة 1080p بسرعة 30 لقطة في الثانية. الكاميرا الأمامية الأساسية هي الكاميرا الأمامية التي لديها معرف أدنى للكاميرا.
• [7.5/H-1-3] يجب أن تكون السمة android.info.supportedHardwareLevel متوافقة مع FULL أو أفضل مع الكاميرا الأساسية الخلفية وLIMITED أو أفضل للكاميرا الأساسية الأمامية.
• [7.5/H-1-4] يجب أن يتوافق مع CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME لكلتا الكاميرتين الأساسيتين.
• [7.5/H-1-5] يجب أن يكون وقت استجابة الالتقاط بتنسيق JPEG في الكاميرا2 < 1,000 ملي ثانية للحصول على درجة دقة 1080p وفقًا لما تم تحديده من خلال اختبار أداء كاميرا CTS في ظل ظروف الإضاءة (3000 كيلوبايت) لكلتا الكاميرا الأساسية.
• [7.5/H-1-6] يجب أن يكون وقت استجابة بدء تشغيل Camera2 (فتح الكاميرا لإطار المعاينة الأول) أقل من 500 مللي ثانية كما تم قياسه من خلال اختبار أداء كاميرا CTS في ظل ظروف الإضاءة في تكنولوجيا المعلومات (3000 كيلوبايت) لكلتا الكاميرتين الأساسيتين.
• [7.5/H-1-8] يجب أن يتوافق مع CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW وandroid.graphics.ImageFormat.RAW_SENSOR للكاميرا الخلفية الأساسية.
• [7.5/H-1-9] يجب أن تتوفر كاميرا أساسية خلفية متوافقة مع 720p أو 1080p بسرعة 240 لقطة في الثانية.
• [7.5/H-1-10] يجب أن يكون الحد الأدنى ZOOM_RATIO أقل من 1.0 للكاميرات الأساسية في حالة وجود كاميرا ذات ألوان غامرة موسّعة تتجه نحو نفس الاتجاه.
• [7.5/H-1-11] يجب تنفيذ بث مباشر متزامن للخلفية على الكاميرات الأساسية.
• [7.5/H-1-12] يجب أن يتوافق مع CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION للكاميرا الخلفية الأساسية.
• [7.5/H-1-13] يجب أن يتوافق مع إمكانية استخدام LOGICAL_MULTI_CAMERA في الكاميرا الخلفية الأساسية في حال توفُّر أكثر من كاميرا خلفية واحدة مزوّدة بنموذج أحمر أخضر أزرق.
• [7.5/H-1-14] يجب أن يتوافق مع ميزة "STREAM_USE_CASE" لكل من الكاميرا الأمامية والخلفية الأساسية.

2.2.7.3. الأجهزة

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

• أن يستوفي متطلبات الأجهزة المذكورة في android 12 CDD القسم 2.2.7.3.

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

• [7.1.1.1/H-2-1] يجب أن تكون دقة الشاشة 1080p على الأقل.
• [7.1.1.3/H-2-1] يجب أن تبلغ كثافة الشاشة 400 نقطة لكل بوصة على الأقلّ.
• [7.6.1/H-2-1] يجب أن تتوفّر ذاكرة فعلية بسعة 8 غيغابايت على الأقل.

2.2.7.4. الأداء

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

• أن يستوفي متطلبات الأداء المذكورة في القسم 2.2.7.4 في Android 12 CDD

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

• [8.2/H-1-1] يجب أن يضمن أداء كتابة تسلسلي لا يقل عن 125 ميغابايت/ثانية.
• [8.2/H-1-2] يجب أن يضمن أداء كتابة عشوائي لا يقل عن 10 ميغابايت/ثانية.
• [8.2/H-1-3] يجب أن يضمن أداء قراءة تسلسلي لا يقل عن 250 ميغابايت/ثانية.
• [8.2/H-1-4] يجب أن يضمن أداء قراءة عشوائي لا يقل عن 40 ميغابايت/ثانية.

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

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

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

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

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

2.3.1. الأجهزة

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

• [7.2.2/T-0-1] يجب أن يتوافق مع D-pad.
• [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] يجب أن تكون قادرة على قياس تغييرات الاتجاه بما يصل إلى 1,000 درجة في الثانية.

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

• [7.4.3/T-0-1] يجب أن يتوافق مع Bluetooth وBluetooth LE.
• يجب أن تتوفّر مساحة تخزين غير متغيّرة في [7.6.1/T-0-1] (أي قسم "/data") على الأقل على مساحة تخزين تبلغ 4 غيغابايت على الأقل

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

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

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

• [7.6.1/T-1-1] يجب أن يكون حجم الذاكرة المتاحة للنواة ومساحة المستخدم 896 ميغابايت على الأقل في حال استخدام أي من الكثافات التالية:

  • 400 نقطة لكل بوصة أو أعلى على الشاشات الصغيرة أو العادية
  • xhdpi أو أعلى على الشاشات الكبيرة
  • tvdpi أو أعلى على الشاشات الكبيرة جدًا

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

• [7.6.1/T-2-1] يجب أن يكون حجم الذاكرة المتاحة للنواة ومساحة المستخدم 1280 ميغابايت على الأقل في حال استخدام أي من الكثافات التالية:

  • 400 نقطة لكل بوصة أو أعلى على الشاشات الصغيرة أو العادية
  • xhdpi أو أعلى على الشاشات الكبيرة
  • tvdpi أو أعلى على الشاشات الكبيرة جدًا

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

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

• يجب أن يتضمّن [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.2/T-0-1] H.264
• [5.2/T-0-2] VP8

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

• [5.2.2/T-SR-1] يُنصح بشدة باعتماد ترميز H.264 للفيديوهات بدقة 720p و1080p بمعدّل 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

يجب أن تدعم عمليات تنفيذ أجهزة التلفزيون فك ترميز 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 لقطة في الثانية مع الملف الشخصي الأساسي
• [5.3.4/T-1-2] دقة عالية تبلغ 1080p بمعدّل 60 لقطة في الثانية مع الملف الشخصي الرئيسي
• [5.3.4/T-1-3] دقة عالية تبلغ 1080p بمعدل 60 لقطة في الثانية مع المستوى 4.2 من الملفات الشخصية العالية

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

• [5.3.5/T-1-1] دقة عالية تبلغ 1080p بمعدل 60 لقطة في الثانية مع مستوى الملف الشخصي الرئيسي 4.1

إذا كانت عمليات تنفيذ أجهزة التلفزيون باستخدام برامج فك ترميز أجهزة H.265 تتيح فك ترميز H.265 والملف الشخصي لفك ترميز المحتوى بدقة فائقة، سيتم إجراء ما يلي:

• [5.3.5/T-2-1] يجب أن يتوافق مع الملف الشخصي لفك ترميز المحتوى بدقة فائقة بسرعة 60 لقطة في الثانية مع الملف الشخصي من المستوى 5 الرئيسي في Main10

يجب أن تدعم عمليات تنفيذ أجهزة التلفزيون فك ترميز 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 والملف الشخصي لفك ترميز المحتوى بدقة فائقة، سيتم إجراء ما يلي:

• [5.3.7/T-2-1] يجب أن يتوافق مع الملف الشخصي لفك ترميز المحتوى بدقة فائقة بسرعة 60 لقطة في الثانية بالملف الشخصي 0 (عمق ألوان 8 بت).
• [5.3.7/T-SR1] يُنصح بشدة بإتاحة الملف الشخصي لفك ترميز المحتوى بدقة فائقة بسرعة 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 هرتز، استنادًا إلى معدّل تحديث الفيديو للمنطقة التي يتمّ بيع الجهاز فيها.

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

• [5.8/T-1-1] يجب أن يتوافق مع الإصدار 2.2 من HDCP.

إذا كانت عمليات تنفيذ أجهزة التلفزيون لا تتيح فك ترميز المحتوى بدقة فائقة، ولكنّها بدلاً من ذلك تتوافق مع شاشة عرض خارجية متصلة عبر 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] يجب أن يتم تحميل تطبيق أو مكوّن خدمة واحدًا أو أكثر مسبقًا باستخدام معالج أهداف، وذلك لجميع أنماط فلاتر الأهداف العامة المحدّدة في أهداف التطبيق التالية المُدرجة هنا.
• [3.4.1/T-0-1] يجب أن يتم تنفيذ واجهة برمجة تطبيقات android.webkit.Webview بشكل كامل.

إذا كانت عمليات تنفيذ أجهزة Android TV تتوافق مع شاشة القفل، سيتم إجراء ما يلي:

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

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

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

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

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

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

• [3.12/T-0-1] يجب أن يتوافق مع "إطار عمل إدخال التلفزيون".

2.3.4 الأداء والقوة

• [8.1/T-0-1] وقت استجابة الإطار بشكل منتظم: يجب ألا يحدث وقت استجابة غير متسق أو تأخير في عرض الإطارات أكثر من 5 إطارات في الثانية، ويجب أن يقل عن 1 إطار في الثانية.
• [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 ميغابايت/ثانية.

إذا كانت عمليات تنفيذ أجهزة التلفزيون تتضمّن ميزات لتحسين إدارة طاقة الجهاز التي يتم تضمينها في "المشروع مفتوح المصدر لنظام Android" (AOSP) أو لتوسيع الميزات المضمّنة في "المشروع مفتوح المصدر لنظام Android" (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] يجب أن تبلغ عن استهلاك طاقة وحدة المعالجة المركزية وفقًا للمعرّف الفريد لكل عملية. يلبي "المشروع المفتوح المصدر لنظام Android" المتطلّبات من خلال تطبيق وحدة نواة uid_cputime.
• [8.4/T] يجب أن يُنسب إلى مكوِّن الجهاز نفسه إذا لم تتمكن من عزو استخدام طاقة مكونات الجهاز إلى أحد التطبيقات.
• [8.4/T-0-4] يجب أن يتيح استخدام هذا الطاقة من خلال أمر Shell adb shell dumpsys batterystats لمطوِّر التطبيق.

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

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

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

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

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

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

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

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

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

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

إذا كانت عمليات تنفيذ أجهزة التلفزيون تشير إلى 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 الأذونات التي تتضمّن معرّف CDD [C-3-X].
• [9.8.2/T-5-2] يجب ألا يخفي مؤشر الكاميرا لتطبيقات النظام التي لها واجهات مستخدم مرئية أو تفاعل مباشر من المستخدم.

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

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

• مثال:
  • يجب أن يعرض [6.1/T-0-1] برنامجًا ثنائيًا /system/bin/perfetto لمستخدم واجهة الأوامر الذي يتوافق مع مستندات Perfetto.
  • [6.1/T-0-2] يجب قبول البرنامج الثنائي للأداء كإدخال إعداد نموذج أوّلي يتوافق مع المخطط المحدّد في مستندات الأداء.
  • [6.1/T-0-3] يجب أن يكتب البرنامج الثنائي للأداء كبيانات تتبع أوّلية يتوافق مع المخطط المحدّد في مستندات الأداء.
  • يجب أن يوفّر [6.1/T-0-4] من خلال البرنامج الثنائي الثنائي على الأقل مصادر البيانات الموضّحة في مستندات Perfetto.

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] يُنصح بشدة بتضمين مقياس تسارع ثلاثي المحاور.

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

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

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

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

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

• [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] يجب أن يتم تحميل تطبيق أو مكوّن خدمة واحدًا أو أكثر مسبقًا باستخدام معالج أهداف، وذلك لجميع أنماط فلاتر الأهداف العامة التي تحدّدها أغراض التطبيقات التالية الواردة هنا.

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

• [3.8.4/W-SR-1] يُوصى بشدة بتفعيل مساعد Google على الجهاز للتعامل مع إجراء المساعدة.

ساعات تنفيذ الأجهزة التي تشير إلى علامة ميزة 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] يُنصَح بشدة بتضمين محرّك TTS يتوافق مع اللغات المتاحة على الجهاز.

• [3.11/W-0-1] يجب أن يتيح تثبيت محركات تحويل النص إلى كلام التابعة لجهات خارجية.

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

إذا كانت عمليات تنفيذ أجهزة الساعة تتضمّن ميزات لتحسين إدارة طاقة الجهاز مضمّنة في 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] يجب أن يبلغ عن استهلاك طاقة وحدة المعالجة المركزية وفقًا للمعرّف الفريد لكل عملية. يلبي "المشروع المفتوح المصدر لنظام Android" المتطلّبات من خلال تطبيق وحدة نواة uid_cputime.
• [8.4/W-0-4] يجب أن يتيح استخدام هذا الطاقة من خلال أمر Shell adb shell dumpsys batterystats لمطوِّر التطبيق.
• [8.4/W] يجب أن يُنسب إلى مكوِّن الجهاز نفسه إذا لم تتمكن من عزو استخدام طاقة مكونات الجهاز إلى أحد التطبيقات.

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

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

• [9/W-0-1] يجب أن يذكر ميزة android.hardware.security.model.compatible.

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

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

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

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

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

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

تُصنَّف عمليات تنفيذ أجهزة Android على أنّها سيارات في حال تضمّن السمة 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.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] قد يحتمَل احتمال الموقع الجغرافي من خلال دمج GPS/GNSS مع أدوات استشعار إضافية. إذا تم احتساب الموقع الجغرافي، يُنصَح بشدة بتطبيق أنواع أداة الاستشعار المقابلة و/أو معرّفات خصائص المركبات المستخدَمة والإبلاغ عنها.

• [7.3/A-0-4] يجب ألا يتطابق الموقع الجغرافي المطلوب عبر LocationManager#requestLocationUpdates() مع الخريطة.

• [7.3.1/A-0-4] يجب أن يتوافق مع نظام الإحداثيات لأجهزة استشعار السيارة من Android.

• [7.3/A-SR-1] يُنصح بـ strongLY_RECOMMENDED لتضمين مقياس تسارع ثلاثي المحاور جيروسكوب ثلاثي المحاور.

• [7.3/A-SR-2] يتم اقتراحها strongLY_RECOMMENDED لاستخدام أداة استشعار TYPE_HEADING والإبلاغ عنها.

إذا كانت عمليات تنفيذ أجهزة 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 تتضمّن مقياس تسارع، سيحدث ما يلي:

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

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

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

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

• [7.3.1/A-1-3] يجب استخدام أداة استشعار TYPE_ACCELEROMETER_LIMITED_AXES والإبلاغ عنها.
• [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 بكسل في الثانية لزيادة درجة الدقة الممكنة إلى أقصى حد.

إذا كانت عمليات تنفيذ أجهزة 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 والإبلاغ عنها.

إذا كانت عمليات تنفيذ أجهزة السيارات تتضمّن جهاز استقبال نظام تحديد المواقع العالمي (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] strongLY_RECOMMENDED للإبلاغ عن الأحداث التي تصل مدتها إلى 10 هرتز على الأقل
• يجب أن يكون في إشارة إلى الشمال الحقيقي.
• يجب أن تكون متاحة حتى عندما تكون المركبة لا تزال غير ثابتة.
• يجب أن تبلغ درجة الدقة درجة واحدة على الأقل.

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

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

• [7.4.3/A-SR-1] يُوصى بها بشدة لإتاحة الملف الشخصي للوصول إلى الرسائل (MAP).

• [7.4.5/A] يجب أن تتوفّر إمكانية اتصال البيانات المستنِدة إلى شبكة الجوّال.

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

كاميرا الرؤية الخارجية هي كاميرا تصور مشاهد خارج الجهاز، مثل كاميرا الرؤية الخلفية.

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

• يجب أن تشمل كاميرا واحدة أو أكثر للعرض الخارجي.

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

• [7.5/A-1-1] يجب ألا تتوفر كاميرات للمشاهدة من الخارج يمكن الوصول إليها عبر واجهات برمجة تطبيقات كاميرا Android، ما لم تتوافق مع المتطلبات الأساسية للكاميرا.

• [7.5/A-SR-1] يُنصح بشدة بعدم تدوير معاينة الكاميرا أو عكسها أفقيًا.

• [7.5/A-SR-2] يُنصح بشدة بتصويرها بدرجة دقة لا تقل عن 1.3 ميغابكسل.

• يجب أن يحتوي الجهاز إما على جهاز ذي تركيز ثابت أو EDOF (عمق مجال ممتد).

• قد يتم تنفيذ التركيز التلقائي للجهاز أو التركيز التلقائي للبرامج في برنامج تشغيل الكاميرا.

إذا كانت عمليات تنفيذ أجهزة السيارات تتضمّن كاميرا واحدة أو أكثر من كاميرات المراقبة الخارجية، وتحميل خدمة نظام الرؤية الخارجية (EVS)، عندئذٍ بالنسبة إلى مثل هذه الكاميرا، سيتم إجراء ما يلي:

• [7.5/A-2-1] يجب ألا يتم تدوير معاينة الكاميرا أو عكسها أفقيًا.

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

• قد يشتمل على كاميرا واحدة أو أكثر متاحة لتطبيقات الجهات الخارجية.

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

• [7.5/A-3-1] يجب أن يتم الإبلاغ عن علامة الميزة android.hardware.camera.any.
• [7.5/A-3-2] يجب ألا يتم التعريف عن الكاميرا باعتبارها كاميرا نظام.
• قد تتوافق مع الكاميرات الخارجية الموضّحة في القسم 7.5.3.
• قد تتضمن ميزات (مثل التركيز التلقائي، وغيرها) المتوفرة للكاميرات الخلفية كما هو موضح في القسم 7.5.1.

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

• يجب أن يتضمّن [7.6.1/A-0-1] ما لا يقل عن 4 غيغابايت من مساحة التخزين غير المتطايرة المتاحة للبيانات الخاصة للتطبيق (أي قسم "/data").

• [7.6.1/A] يجب تنسيق قسم البيانات لتحسين الأداء وإطالة العمر على مساحة تخزين الفلاش، على سبيل المثال باستخدام نظام الملفات f2fs.

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

• [7.6.1/A-SR-1] يُنصح بشدة بتقليل النفقات العامة لوحدات الإدخال والإخراج (I/O) على العمليات التي يتم إجراؤها على وحدة التخزين الخارجية، مثلاً من خلال استخدام SDCardFS.

إذا كانت عمليات تنفيذ أجهزة 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 أو أعلى على الشاشات الكبيرة
  • tvdpi أو أعلى على الشاشات الكبيرة جدًا

• [7.6.1/A-2-4] يجب أن يكون حجم الذاكرة المتاحة للنواة ومساحة المستخدم 1824 ميغابايت على الأقل في حال استخدام أي من الكثافات التالية:

  • 560 نقطة لكل بوصة أو أعلى على الشاشات الصغيرة أو العادية
  • 400 نقطة لكل بوصة أو أكثر على الشاشات الكبيرة
  • xhdpi أو أعلى على الشاشات الكبيرة جدًا

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

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

• [7.7.1/A] يجب أن يحتوي على منفذ USB يتوافق مع وضع الأجهزة الملحقة.

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

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

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

• يجب أن يتضمّن [7.8.2/A-0-1] إخراجًا صوتيًا ويشير إلى android.hardware.audio.output.

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.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

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] يجب أن يتم تحميل تطبيق أو مكوّن خدمة واحدًا أو أكثر مسبقًا باستخدام معالج أهداف، وذلك لجميع أنماط فلاتر الأهداف العامة المحدّدة في أهداف التطبيق التالية المُدرجة هنا.

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

• [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] يجب أن تعرض "تشغيل" و"كتم الصوت" لإجراءات الإشعارات بدلاً من الإجراءات المقدمة من خلال Notification.Builder.addAction()
• [3.8.3.1/أ] يجب أن يحظر استخدام مهام الإدارة الغنية، مثل عناصر التحكم في القناة لكل إشعار. قد تستخدم خصائص واجهة المستخدم لكل تطبيق لتقليل عناصر التحكم.

إذا كانت عمليات تنفيذ أجهزة Automotive تتيح خصائص 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 إجراء Intent ضمني مع العنصر 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.

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

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

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

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

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

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

• يجب أن يُبلغ [8.2/A-0-1] عن عدد وحدات البايت التي تمت قراءتها وكتابتها في مساحة تخزين غير متغيّرة وفقًا للمعرّف الفريد لكل عملية، وبالتالي تتوفّر الإحصاءات للمطوّرين من خلال System API android.car.storagemonitoring.CarStorageMonitoringManager. يلبي "المشروع المفتوح المصدر لنظام Android" المتطلّبات من خلال وحدة نواة uid_sys_stats.
• [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] يجب أن تبلغ عن استهلاك طاقة وحدة المعالجة المركزية وفقًا للمعرّف الفريد لكل عملية. يلبي "المشروع المفتوح المصدر لنظام Android" المتطلّبات من خلال تطبيق وحدة نواة uid_cputime.
• [8.4/A] يجب أن يُنسب إلى مكوِّن الجهاز نفسه إذا لم تتمكن من إسناد استخدام طاقة مكونات الجهاز إلى أحد التطبيقات.
• [8.4/A-0-4] يجب إتاحة هذا الاستخدام للطاقة من خلال أمر Shell 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] يجب أن يوفر إمكانية إنشاء مستخدم ضيف حتى عند الوصول إلى الحد الأقصى لعدد المستخدمين على الجهاز.

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

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

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

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

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

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

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

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

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

• مثال:
  • [6.1/A-0-1] يجب أن يعرض /system/bin/perfetto برنامجًا ثنائيًا لمستخدم واجهة الأوامر الذي يتوافق مع مستندات الأداء.
  • [6.1/A-0-2] يجب قبول البرنامج الثنائي للأداء كإدخال إعداد نموذج أوّلي يتوافق مع المخطط المحدّد في مستندات الأداء.
  • [6.1/A-0-3] يجب أن يكتب البرنامج الثنائي للأداء كبيانات تتبع أوّلية يتوافق مع المخطط المحدّد في مستندات الأداء.
  • يجب أن يوفّر [6.1/A-0-4] من خلال البرنامج الثنائي الثنائي على الأقل مصادر البيانات الموضّحة في مستندات Perfetto.

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

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

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

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

2.6.1. الأجهزة

الجيروسكوب

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

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

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

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

وضع جهاز USB الملحق (القسم 7.7.1)

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

• [7.7.1/Tab] قد يتم تنفيذ واجهة برمجة تطبيقات ملحق Android المفتوح (AOA).

وضع الواقع الافتراضي (القسم 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 لعناصر التحكم لتفعيل /إيقاف المستخدمين الآخرين من الوصول إلى المكالمات الصوتية والرسائل القصيرة SMS.

2.6.2 البرامج

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

3. البرامج

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

بيئة تنفيذ رمز بايت Dalvik المُدار هي الأداة الأساسية لتطبيقات Android. واجهة برمجة تطبيقات Android (API) هي مجموعة واجهات نظام 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 ومتاحة في مسار فئة التشغيل في AOSP والتي لا تشكل جزءًا من حزمة SDK المتاحة للجميع. يشمل ذلك واجهات برمجة التطبيقات المزيّنة بالتعليق التوضيحي @hide وليس بالسمة @SystemAPI، كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) وأعضاء الفئة الخاصة والخاصة بالحزمة.

• يجب تضمين [C-0-6] مع كل واجهة ليست متوفرة في حزمة SDK ضمن القوائم المحظورة نفسها التي تم توفيرها من خلال العلامات المؤقتة وقائمة الحظر في مسار prebuilts/runtime/appcompat/hiddenapi-flags.csv لفرع مستوى واجهة برمجة التطبيقات المناسب في AOSP.

• يجب أن يتوافق [C-0-7] مع آلية الضبط الموقَّع للتحديث الديناميكي لإزالة الواجهات التي لا تتضمّن حزمة SDK من قائمة محظورة، وذلك عن طريق تضمين إعدادات مُوقَّعة في أي حزمة APK، باستخدام المفاتيح العامة الحالية المتوفّرة في بروتوكول AOSP.

  ومع ذلك:

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

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، تؤدي عمليات تنفيذ الأجهزة إلى ما يلي:

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

إنّ عملية تنفيذ بروتوكول AOSP تستوفي هذه المتطلّبات.

3.2. التوافق مع Soft API

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

3.2.1. الأذونات

• [C-0-1] يجب أن تتيح أدوات تنفيذ الأجهزة إمكانية استخدام جميع العناصر الثابتة للأذونات وفرضها على النحو الموضَّح في الصفحة المرجعية للأذونات. تجدر الإشارة إلى أنّ القسم 9 يسرد المتطلّبات الإضافية المتعلّقة بنموذج الأمان في Android.

3.2.2. مَعلمات الإصدار

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

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

المَعلمة	التفاصيل
الإصدار.إصدار	تمثّل هذه السمة إصدار نظام Android قيد التنفيذ حاليًا، بتنسيق يمكن للمستخدمين قراءته. يجب أن يحتوي هذا الحقل على إحدى قيم السلسلة المحدّدة في سلاسل الإصدارات المسموح بها لنظام التشغيل Android 13.
VERSION.SDK	تمثّل هذه السمة إصدار نظام Android قيد التنفيذ حاليًا، بتنسيق يمكن الوصول إليه من خلال رمز تطبيق تابع لجهة خارجية. بالنسبة إلى نظام التشغيل Android 13، يجب أن يحتوي هذا الحقل على القيمة العددية 13_INT.
VERSION.SDK_INT	تمثّل هذه السمة إصدار نظام Android قيد التنفيذ حاليًا، بتنسيق يمكن الوصول إليه من خلال رمز تطبيق تابع لجهة خارجية. بالنسبة إلى نظام التشغيل Android 13، يجب أن يحتوي هذا الحقل على القيمة العددية 13_INT.
نسخة مكمّلة	يشير ذلك المصطلح إلى قيمة يختارها مقدِّم الجهاز الذي يخصّص الإصدار المحدّد لنظام Android قيد التنفيذ حاليًا، بتنسيق يمكن للمستخدمين قراءته. ويجب عدم إعادة استخدام هذه القيمة للإصدارات المختلفة المتاحة للمستخدمين. ومن الاستخدامات المعتادة لهذا الحقل الإشارة إلى رقم الإصدار أو معرّف تغيير التحكّم في المصدر الذي تم استخدامه لإنشاء الإصدار. يجب أن تكون قيمة هذا الحقل قابلة لترميز ASCII المكوّن من 7 بت القابل للطباعة وأن تتطابق مع التعبير العادي "^[^ :\/~]+$.
ألعاب ألواح	يشير ذلك المصطلح إلى قيمة يختارها القائم على تنفيذ الجهاز وتحدِّد الجهاز الداخلي المحدَّد الذي يستخدمه الجهاز، بتنسيق يمكن للمستخدمين قراءته. ومن الاستخدامات المحتملة لهذا الحقل الإشارة إلى المراجعة المحددة للّوحة التي تشغِّل الجهاز. يجب أن تكون قيمة هذا الحقل قابلة لترميز ASCII المكوّن من 7 بت وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9_-]+$".
العلامة التجارية	قيمة تعكس اسم العلامة التجارية المرتبطة بالجهاز كما هو معروف للمستخدمين النهائيين. يجب أن يكون بتنسيق يمكن للمستخدمين قراءته، وأن يمثّل الشركة المصنّعة للجهاز أو العلامة التجارية للشركة التي يتم تسويق الجهاز بموجبها. يجب أن تكون قيمة هذا الحقل قابلة لترميز ASCII المكوّن من 7 بت ومتطابقة مع التعبير العادي "^[a-zA-Z0-9_-]+$".
مواد العرض المتوافقة	تمثّل هذه السمة اسم مجموعة التعليمات (نوع وحدة المعالجة المركزية + اصطلاح ABI) للرمز البرمجي الأصلي. راجع القسم 3.3. التوافق مع واجهة برمجة التطبيقات الأصلية:
مدعومة_32_BIT_ABIS	تمثّل هذه السمة اسم مجموعة التعليمات (نوع وحدة المعالجة المركزية + اصطلاح ABI) للرمز البرمجي الأصلي. راجع القسم 3.3. التوافق مع واجهة برمجة التطبيقات الأصلية:
SUPPORTED_64_BIT_ABIS	تمثّل هذه السمة اسم مجموعة التعليمات الثانية (نوع وحدة المعالجة المركزية (CPU) + نمط ABI) للرموز البرمجية الأصلية. راجع القسم 3.3. التوافق مع واجهة برمجة التطبيقات الأصلية:
وحدة المعالجة المركزية (CPU_ABI)	تمثّل هذه السمة اسم مجموعة التعليمات (نوع وحدة المعالجة المركزية + اصطلاح ABI) للرمز البرمجي الأصلي. راجع القسم 3.3. التوافق مع واجهة برمجة التطبيقات الأصلية:
وحدة معالجة مركزية (CPU_ABI2)	تمثّل هذه السمة اسم مجموعة التعليمات الثانية (نوع وحدة المعالجة المركزية (CPU) + نمط ABI) للرموز البرمجية الأصلية. راجع القسم 3.3. التوافق مع واجهة برمجة التطبيقات الأصلية:
جهاز	يشير ذلك المصطلح إلى قيمة يختارها مقدِّم الجهاز تتضمّن اسم التطوير أو الاسم الرمزي الذي يحدّد إعدادات ميزات الأجهزة والتصميم الصناعي للجهاز. يجب أن تكون قيمة هذا الحقل قابلة لترميز ASCII المكوّن من 7 بت ومتطابقة مع التعبير العادي "^[a-zA-Z0-9_-]+$". ويجب ألا يتغيّر اسم الجهاز هذا خلال فترة استخدام المنتج.
طباعة الأصابع	سلسلة تعرّف هذا الإصدار بشكل فريد. ويجب أن يكون النص مقروءًا بشكل معقول يجب أن يتّبع هذا النموذج: $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.edition)/$(رقم التعريف)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) على سبيل المثال: acme/myproduct/ mydevice:13/LMYXX/3359:userdebug/test-keys يجب ألا يتضمن الملف المرجعي مسافات بيضاء. يجب أن تكون قيمة هذا الحقل قابلة لترميز ASCII 7 بت.
الأجهزة	اسم الجهاز (من سطر أوامر kernel أو /proc). ويجب أن يكون النص مقروءًا بشكل معقول. يجب أن تكون قيمة هذا الحقل قابلة لترميز ASCII المكوّن من 7 بت وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9_-]+$".
المضيف	تمثّل هذه السمة سلسلة تحدِّد بشكل فريد المضيف الذي تم إنشاء الإصدار عليه، بتنسيق يمكن للمستخدمين قراءته. وما مِن متطلبات بشأن التنسيق المحدّد لهذا الحقل، باستثناء ما يجب ألا تكون فارغة أو السلسلة الفارغة ("").
رقم التعريف	يشير هذا المصطلح إلى معرّف يختاره القائم على تنفيذ الجهاز للإشارة إلى إصدار معيّن، بتنسيق يمكن للمستخدمين قراءته. يمكن أن يكون هذا الحقل مماثلاً للحقل android.os.Build.VERSION.INCREMENTAL، ولكن يجب أن يكون قيمة ذات دلالة كافية للمستخدمين النهائيين للتمييز بين إصدارات البرامج. يجب أن تكون قيمة هذا الحقل قابلة لترميز ASCII المكوّن من 7 بت ومتطابقة مع التعبير العادي "^[a-zA-Z0-9._-]+$".
شركة مصنّعة	تمثّل هذه السمة الاسم التجاري للمصنّع الأصلي للجهاز (OEM) للمنتج. ما مِن متطلبات بشأن التنسيق المحدّد لهذا الحقل، باستثناء ما يجب ألا تكون قيمة فارغة أو السلسلة الفارغة (""). ويجب ألا يتغيّر هذا الحقل خلال فترة استخدام المنتج.
شركة SOC_MANUFACTURER	تمثّل هذه السمة الاسم التجاري للشركة المصنّعة للنظام الأساسي على الرقاقة (SOC) المستخدَم في المنتج. يجب استخدام القيمة الثابتة نفسها على الأجهزة التي صنّعتها شركة SOC نفسها. يُرجى طلب الرقم الثابت الصحيح لاستخدامه. يجب أن تكون قيمة هذا الحقل قابلة للترميز بتنسيق ASCII المكوّن من 7 بت، ويجب أن تتطابق مع التعبير العادي “^([0-9A-Za-z ]+)”، ويجب ألّا تبدأ أو تنتهي بمسافة بيضاء، ويجب ألا تكون مساوية لـ "غير معروف". ويجب ألا يتغيّر هذا الحقل خلال عمر المنتج.
SOC_MODEL	تمثّل هذه السمة اسم طراز النظام الأساسي على شريحة (SOC) المستخدمة في المنتج. يجب أن تستخدم الأجهزة التي لها نموذج SOC نفسه القيمة الثابتة نفسها. يُرجى طلب الرقم الثابت الصحيح لاستخدامه. يجب أن تكون قيمة هذا الحقل قابلة للترميز بتنسيق ASCII المكوّن من 7 بت وتطابق التعبير العادي “^([0-9A-Za-z ._/+-]+)$”، ويجب ألّا تبدأ أو تنتهي بمسافة بيضاء، ويجب ألا تكون مساوية لقيمة "غير معروف". ويجب ألا يتغيّر هذا الحقل خلال فترة استخدام المنتج.
النموذج	يشير ذلك المصطلح إلى قيمة يختارها أداة تنفيذ الجهاز وتحتوي على اسم الجهاز الذي يعرفه المستخدم النهائي. ويجب أن يكون هذا الاسم هو نفسه الذي يتم بموجبه تسويق الجهاز وبيعه للمستخدمين النهائيين. وما مِن متطلبات بشأن التنسيق المحدّد لهذا الحقل، باستثناء ما يجب ألا تكون قيمة فارغة أو السلسلة الفارغة (""). ويجب ألا يتغيّر هذا الحقل خلال عمر المنتج.
المنتج	يشير ذلك المصطلح إلى قيمة يختارها القائم على تنفيذ الجهاز تحتوي على اسم التطوير أو اسم الرمز البرمجي للمنتج المحدّد (SKU)، والذي يجب أن يكون فريدًا ضمن العلامة التجارية نفسها. يجب أن يكون سهل القراءة للمستخدم، ولكن ليس بالضرورة أن يشاهده المستخدمون النهائيون. يجب أن تكون قيمة هذا الحقل قابلة لترميز ASCII المكوّن من 7 بت وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9_-]+$". ويجب ألا يتغيّر اسم المنتج هذا خلال فترة استخدام المنتج.
ODM_SKU	هي قيمة اختيارية يتم اختيارها من قِبل أداة تنفيذ الجهاز، وتحتوي على رمز التخزين التعريفي (SKU) المستخدَم لتتبُّع إعدادات معيّنة للجهاز، مثل أي أجهزة ملحقة يتم تضمينها مع الجهاز عند بيعه. يجب أن تكون قيمة هذا الحقل قابلة لترميز ASCII المكوّن من 7 بت وأن تتطابق مع التعبير العادي ^([0-9A-Za-z.,_-]+)$.
الرقم التسلسلي	يجب عرض "UNKNOWN"
العلامات	تمثّل هذه السمة قائمة مفصولة بفواصل من العلامات التي يختارها القائم على تنفيذ الجهاز والتي تميّز الإصدار بشكل أكبر. يجب أن تكون العلامات قابلة للترميز بتنسيق ASCII المكوّن من 7 بت وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9._-]+"، ويجب أن تحتوي على إحدى القيم المقابلة لإعدادات التوقيع الثلاثة النموذجية على نظام Android الأساسي، وهي: مفاتيح الإصدار ومفاتيح المطوّرين ومفاتيح الاختبار.
الوقت	قيمة تمثّل الطابع الزمني لوقت حدوث الإصدار.
مطبوع	يشير ذلك المصطلح إلى قيمة يختارها أداة تنفيذ الجهاز لتحديد إعدادات وقت تشغيل الإصدار. يجب أن يحتوي هذا الحقل على إحدى القيم المقابلة للإعدادات الثلاثة النموذجية لوقت تشغيل Android، وهي: المستخدم أو userdebug أو eng.
مستخدم	تمثّل هذه السمة اسم المستخدم أو رقم تعريفه (أو المستخدم المبرمَج) الذي أنشأ الإصدار. وما مِن متطلبات بشأن التنسيق المحدّد لهذا الحقل، باستثناء أنّه يجب ألا تكون قيمة فارغة أو السلسلة الفارغة ("").
تصحيح_الأمان	قيمة تشير إلى مستوى رمز تصحيح الأمان لإصدار معيّن. ويجب أن يشير ذلك إلى أنّ الإصدار ليس معرّضًا بأي شكل من الأشكال لأيٍّ من المشاكل الموضّحة من خلال نشرة الأمن العام من Android المخصّصة. ويجب أن يكون بالتنسيق [YYYY-MM-DD]، وأن يتطابق مع سلسلة محدّدة موثَّقة في نشرة الأمان العام على Android أو في تقرير أمان Android، على سبيل المثال "2015-11-01".
نظام التشغيل BASE_OS	قيمة تمثل المعلمة FINGERPrint الخاصة بالإصدار والتي تتطابق مع هذا الإصدار باستثناء رموز التصحيح المقدَّمة في "نشرة الأمان العام" من Android. يجب أن يتم الإبلاغ عن القيمة الصحيحة، وفي حال عدم توفّر مثل هذا الإصدار، يجب الإبلاغ عن سلسلة فارغة ("").
BOOTLOADER	يشير ذلك المصطلح إلى قيمة يختارها أداة تنفيذ الجهاز وتحدِّد إصدار برنامج الإقلاع الداخلي المحدَّد والمستخدَم في الجهاز، بتنسيق يمكن للمستخدمين قراءته. يجب أن تكون قيمة هذا الحقل قابلة لترميز ASCII المكوّن من 7 بت ومتطابقة مع التعبير العادي "^[a-zA-Z0-9._-]+$".
getRadioVersion()	يجب أن تكون (تكون أو تعرض) قيمة يختارها منفذ تنفيذ الجهاز لتحديد إصدار الراديو/المودم الداخلي المحدّد والمستخدَم في الجهاز، بتنسيق يمكن للمستخدمين قراءته. إذا لم يتضمن الجهاز أي راديو/مودم داخلي ، يجب أن يعرض "خالٍ". يجب أن تكون قيمة هذا الحقل قابلة لترميز ASCII المكوّن من 7 بت وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9._-,]+$".
getSerial()	يجب أن يكون رقمًا تسلسليًا للأجهزة، على أن يكون متاحًا وفريدًا على جميع الأجهزة التي تستخدم MODEL وMANUFACTURER نفسهما. يجب أن تكون قيمة هذا الحقل قابلة لترميز ASCII المكوّن من 7 بت ومتطابقة مع التعبير العادي "^[a-zA-Z0-9]+$".

3.2.3. التوافق مع الأهداف

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

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

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

• [C-SR-1] يُنصح بشدة بتحميل تطبيق أو مكوّن خدمة واحد أو أكثر باستخدام معالج أهداف، وذلك لجميع أنماط فلاتر الأهداف العامة المحدّدة في أهداف التطبيق التالية المُدرَجة هنا، وتوفير عملية التنفيذ، أي تلبية توقّعات المطوّر بشأن الأهداف الشائعة للتطبيق كما هو موضّح في حزمة 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) للبيانات. على سبيل المثال، يكون نمط فلتر الأهداف الذي يحدّد عنوان URI للبيانات "http://www.android.com" أكثر تحديدًا من نمط الغرض الأساسي في المتصفّح لـ "http:// ".

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

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

3.2.3.3. مساحات أسماء الأهداف

• [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. نوايا البث

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

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

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

3.2.3.5. عناصر Intent للتطبيق المشروطة

يشمل Android إعدادات توفّر للمستخدمين طريقة سهلة لاختيار التطبيقات التلقائية، على سبيل المثال للشاشة الرئيسية أو الرسائل القصيرة SMS.

يجب أن تتضمّن عمليات تنفيذ الأجهزة قائمة إعدادات مشابهة وأن تكون متوافقة مع نمط فلتر الأهداف وطرق واجهة برمجة التطبيقات الموضّحة في مستندات حزمة تطوير البرامج (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 هدف عرض مربّع حوار لتغيير التطبيق التلقائي للرسائل القصيرة.

• [C-2-2] يجب أن ينفّذ android.telecom.action.CHANGE_DEFAULT_DIALER هدف عرض مربّع حوار للسماح للمستخدم بتغيير تطبيق "الهاتف" التلقائي.

  • يجب استخدام واجهة المستخدم التلقائية لتطبيق "الهاتف" التي اختارها المستخدم للمكالمات الواردة والصادرة باستثناء مكالمات الطوارئ التي قد تستخدم تطبيق "الهاتف" المثبَّت مسبقًا.

• [C-2-3] يجب أن يفي android.telecom.action.متجر_PHONE_ACCOUNTS بهدف توفير إمكانية ضبط إعدادات حساب ConnectionServices المرتبط بخدمة PhoneAccounts، بالإضافة إلى حساب تلقائي على الهاتف الذي سيستخدمه مقدِّم خدمة الاتصالات لإجراء مكالمات صادرة. يفي تنفيذ 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 ويجب أن يقدّم نشاطًا لإرسال/عرض الرسائل القصيرة.

• [C-SR-1] يُنصَح باستخدامها بشكل كبير مع مراعاة android.intent.action.ANSWER وandroid.intent.action.CALL وandroid.intent.action.CALL_button وandroid.intent.action.VIEW وandroid.intent.action.DIAL وهما يتيحان تنفيذ الأهداف التي يمكن استخدامها في عمليات التنفيذ ضِمن التطبيقات التي يتم تحميلها مُسبقًا في تطبيق android.intent.action.DIAL.

في حال أبلغت عمليات تنفيذ الأجهزة عن 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] هذه الأهداف android.nfc.action.NDEF_DISCOVERED وandroid.nfc.action.TAG_DISCOVERED وandroid.nfc.action.TECH_DISCOVERED لعرض نشاط يلبّي توقعات المطوّرين لهذه الأهداف على النحو الموضّح في حزمة 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 نشاطًا يمكن للمستخدم من خلاله منح أو رفض وصول التطبيق إلى إعدادات سياسة DND.

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

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

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

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

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

• [C-9-1] يجب أن تنفّذ Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI واجهات برمجة تطبيقات Intent كما هو موضّح في مستندات حزمة تطوير البرامج (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_POLICY و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] يجب أن تعرض هذه الروابط لجميع خدمات الملء التلقائي المثبَّتة.

• [ج-17-1] [نقل إلى 2.2.3]

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع 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.

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 للتطبيق كملف ELF .so الذي تم تجميعه من أجل بنية الأجهزة المناسبة للجهاز. ونظرًا لاعتماد الرمز الأصلي بدرجة كبيرة على تكنولوجيا المعالج الأساسي، يُحدِّد Android عددًا من واجهات التطبيق الثنائية (ABI) في Android NDK.

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

• يجب أن يكون [C-0-1] متوافقًا مع واجهة برمجة تطبيقات Android NDK محددة أو أكثر.
• [C-0-2] يجب أن يشمل توافقًا مع الرموز البرمجية التي يتم تشغيلها في البيئة المُدارة لاستدعاء الرموز البرمجية الأصلية، باستخدام دلالات واجهة Java الأصلية (JNI) العادية.
• يجب أن يكون [C-0-3] متوافقًا مع المصدر (أي متوافق مع العنوان) ومتوافقًا مع النظام الثنائي (بالنسبة إلى واجهة التطبيق الثنائية (ABI)) مع كل مكتبة مطلوبة في القائمة أدناه.
• يجب أن يُبلِغ [C-0-5] بدقة عن واجهة التطبيق الثنائية (ABI) الأصلية التي يتوافق معها الجهاز، وذلك من خلال مَعلمات android.os.Build.SUPPORTED_ABIS وandroid.os.Build.SUPPORTED_32_BIT_ABIS وandroid.os.Build.SUPPORTED_64_BIT_ABIS، وتكون كل واجهة من واجهات التطبيق الثنائية (ABI) المفصولة بفواصل مرتّبة من الأكثر إلى الأقل تفضيلاً.

• يجب استخدام المَعلمات أعلاه في [C-0-6] للإبلاغ عن مجموعة فرعية من قائمة واجهات التطبيق الثنائية (ABI) التالية ويجب ألا تُبلِغ عن أيّ واجهات تطبيقات ثنائية (ABI) غير مدرَجة في القائمة.

  • armeabi (لم تعُد متاحة كهدف من قِبل NDK)
  • armeabi-v7a
  • arm64-v8a
  • x86
  • x86-64

• [C-0-7] يجب أن يجعل جميع المكتبات التالية التي توفّر واجهات برمجة التطبيقات الأصلية متاحة للتطبيقات التي تتضمّن رموزًا برمجية أصلية:

  • libaaudio.so (التوافق مع الصوت الأصلي)
  • libamedi.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 (مكتبة الرياضيات)
  • libneralnetworks.so (واجهة برمجة التطبيقات للشبكات العصبية)
  • 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] يجب أن يسرد المكتبات الإضافية التي لا تتوافق مع بروتوكول AOSP والمتوفّرة مباشرةً لتطبيقات تابعة لجهات خارجية في /vendor/etc/public.libraries.txt.

• [C-0-10] يجب ألا تعرض التطبيقات التابعة لجهات خارجية التي تستهدف المستوى 24 من واجهة برمجة التطبيقات أو مستوى أعلى أي مكتبات أصلية أخرى يتم تنفيذها وتقديمها في AOSP كمكتبات نظام، وذلك في حال كانت هذه المكتبات محجوزة.

• [C-0-11] يجب تصدير جميع رموز الدوال OpenGL ES 3.1 وAndroid Extension Pack على النحو المحدَّد في NDK، من خلال مكتبة libGLESv3.so. تجدر الإشارة إلى أنّه على الرغم من ضرورة وجود جميع الرموز، يصف القسم 7.1.4.1 بمزيد من التفصيل المتطلبات المتعلّقة بالموعد المتوقّع للتنفيذ الكامل لكل دالة من الدوال المتجاوبة.

• [C-0-12] يجب تصدير رموز الدوال لرموز دالة Vulkan 1.0 الأساسية بالإضافة إلى الإضافات 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 قد تتيح استخدام المزيد من استراتيجيات A/A.

3.3.2 التوافق مع الرموز البرمجية المستندة إلى معالجات ARM 32 بت

في حال أبلغت عمليات تنفيذ الأجهزة عن توافق واجهة التطبيق الثنائية (ABI) مع armeabi، سيتم إجراء ما يلي:

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

في حال أبلغت عمليات تنفيذ الأجهزة عن توافُق واجهة التطبيق الثنائية (armeabi-v7a) للتطبيقات التي تستخدم واجهة التطبيق الثنائية هذه، سيتم إجراء ما يلي:

• يجب تضمين الأسطر التالية في /proc/cpuinfo في [C-2-1]، ويجب ألا تغيّر القيم على الجهاز نفسه، حتى عند قراءتها بواسطة واجهات تطبيقات ثنائية (ABI) أخرى.

  • Features:، يليها قائمة بأي ميزات اختيارية لوحدة المعالجة المركزية (CPU) ARMv7 يوفّرها الجهاز.
  • CPU architecture:، يليه عدد صحيح يصف أعلى بنية ARM المتوافقة للجهاز (مثل "8" للأجهزة التي تعمل بمعالجات ARMv8).

• [C-2-2] يجب دائمًا توفير العمليات التالية، حتى في حال تنفيذ واجهة ABI على بنية ARMv8، سواء من خلال دعم وحدة المعالجة المركزية الأصلية أو من خلال محاكاة البرامج:

  • تعليمات محو بيانات المستخدم وميزة SWPB
  • عمليات حاجز CP15ISB وCP15DSB وCP15DMB.

• [C-2-3] يجب أن يتوافق مع الإضافة Advanced SIMD (المعروفة أيضًا باسم NEON).

3.4. التوافق مع الويب

3.4.1. التوافق مع WebView

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

• [C-1-1] يجب الإبلاغ عن android.software.webview.
• يجب استخدام إصدار مشروع Chromium في [C-1-2] من المشروع المفتوح المصدر لنظام Android في فرع Android 13 لتنفيذ واجهة برمجة التطبيقات android.webkit.WebView.

• [C-1-3] يجب أن تكون سلسلة وكيل المستخدم التي تم الإبلاغ عنها من خلال WebView بالتنسيق التالي:

  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. ويجب أن تستوفي عملية تنفيذ بروتوكول AOSP في WebView هذا الشرط.

يُرجى العِلم أنّه إذا كانت عمليات تنفيذ الأجهزة بنظام 32 بت أو تشير إلى علامة الميزة android.hardware.ram.low، سيتم استثناء هذه العلامات من C-1-3.

3.4.2 توافُق المتصفّح

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

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

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

• [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] يجب ألا تغيّر الأجهزة دلالات دورة الحياة أو دورة الحياة الخاصة بنوع معيّن من مكوّنات النظام (مثل Service وActivityProvider، وما إلى ذلك).
• [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. قيود التطبيق

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

• [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].

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

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

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

في حال كانت عمليات تنفيذ الأجهزة تتضمّن "إسبات التطبيق" المضمّن في "مشروع أمان التطبيقات (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] يجب ألا تتم إضافة أي عناصر معروضة بشكل علني (مثل الفئات أو الواجهات أو الحقول أو الطرق إلى فئات أو واجهات حالية) أو اختبار أو واجهات برمجة تطبيقات النظام إلى واجهات برمجة التطبيقات في مساحات الاسم المذكورة أعلاه. و "العنصر المكشوف للجميع" هو أي بنية غير مزيّنة بعلامة "@إخفاء" كما هي مستخدَمة في رمز المصدر الرئيسي لنظام التشغيل 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 التنفيذي بالكامل (DEX) ومواصفات رمز البايت Dalvik والدلالات الدلالية.

• [C-0-2] يجب أن يضبط بيئات تشغيل Dalvik لتخصيص الذاكرة وفقًا لنظام Android الأساسي، ووفقًا لما هو محدّد في الجدول التالي. (راجع القسم 7.1.1 للاطلاع على تعريفات حجم الشاشة وكثافة الشاشة).

• يجب استخدام "وقت تشغيل Android" (ART)، والتنفيذ المرجعي لتنسيق Dalvik التنفيذي، ونظام إدارة الحزمة الخاص بعملية تنفيذ المرجع.

• "ينبغي" إجراء اختبارات الإخفاق في ظل أوضاع التنفيذ والبُنى الأساسية المستهدفة المختلفة لضمان ثبات بيئة التشغيل. يمكنك الرجوع إلى JFuzz وDexFuzz في "مشروع Android المفتوح" الإلكتروني.

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

تنسيق الشاشة	كثافة الشاشة	الحد الأدنى لذاكرة التطبيق
ساعة Android	120 نقطة لكل بوصة (ldpi)	32 ميغابايت
	140 نقطة لكل بوصة (140 نقطة لكل بوصة)
	160 نقطة لكل بوصة (mdpi)
	180 نقطة لكل بوصة (180 نقطة لكل بوصة)
	200 نقطة لكل بوصة (200 نقطة لكل بوصة)
	213 نقطة لكل بوصة (tvdpi)
	220 نقطة لكل بوصة (220 نقطة لكل بوصة)	36 ميغابايت
	240 نقطة لكل بوصة (hdpi)
	280 نقطة لكل بوصة (280 نقطة لكل بوصة)
	320 نقطة لكل بوصة (xhdpi)	48 ميغابايت
	360 نقطة لكل بوصة (360 نقطة لكل بوصة)
	400 نقطة لكل بوصة (400 نقطة لكل بوصة)	56 ميغابايت
	420 نقطة لكل بوصة (420 نقطة لكل بوصة)	64 ميغابايت
	480 نقطة لكل بوصة (xxhdpi)	88 ميغابايت
	560 نقطة لكل بوصة (560 نقطة لكل بوصة)	112 ميغابايت
	640 نقطة لكل بوصة (xxxhdpi)	154 ميغابايت
صغيرة/عادية	120 نقطة لكل بوصة (ldpi)	32 ميغابايت
	140 نقطة لكل بوصة (140 نقطة لكل بوصة)
	160 نقطة لكل بوصة (mdpi)
	180 نقطة لكل بوصة (180 نقطة لكل بوصة)	48 ميغابايت
	200 نقطة لكل بوصة (200 نقطة لكل بوصة)
	213 نقطة لكل بوصة (tvdpi)
	220 نقطة لكل بوصة (220 نقطة لكل بوصة)
	240 نقطة لكل بوصة (hdpi)
	280 نقطة لكل بوصة (280 نقطة لكل بوصة)
	320 نقطة لكل بوصة (xhdpi)	80 ميغابايت
	360 نقطة لكل بوصة (360 نقطة لكل بوصة)
	400 نقطة لكل بوصة (400 نقطة لكل بوصة)	96 ميغابايت
	420 نقطة لكل بوصة (420 نقطة لكل بوصة)	112 ميغابايت
	480 نقطة لكل بوصة (xxhdpi)	128 ميغابايت
	560 نقطة لكل بوصة (560 نقطة لكل بوصة)	192 ميغابايت
	640 نقطة لكل بوصة (xxxhdpi)	256 ميغابايت
كبير	120 نقطة لكل بوصة (ldpi)	32 ميغابايت
	140 نقطة لكل بوصة (140 نقطة لكل بوصة)	48 ميغابايت
	160 نقطة لكل بوصة (mdpi)
	180 نقطة لكل بوصة (180 نقطة لكل بوصة)	80 ميغابايت
	200 نقطة لكل بوصة (200 نقطة لكل بوصة)
	213 نقطة لكل بوصة (tvdpi)
	220 نقطة لكل بوصة (220 نقطة لكل بوصة)
	240 نقطة لكل بوصة (hdpi)
	280 نقطة لكل بوصة (280 نقطة لكل بوصة)	96 ميغابايت
	320 نقطة لكل بوصة (xhdpi)	128 ميغابايت
	360 نقطة لكل بوصة (360 نقطة لكل بوصة)	160 ميغابايت
	400 نقطة لكل بوصة (400 نقطة لكل بوصة)	192 ميغابايت
	420 نقطة لكل بوصة (420 نقطة لكل بوصة)	228 ميغابايت
	480 نقطة لكل بوصة (xxhdpi)	256 ميغابايت
	560 نقطة لكل بوصة (560 نقطة لكل بوصة)	384 ميغابايت
	640 نقطة لكل بوصة (xxxhdpi)	512 ميغابايت
كبير جدًا	120 نقطة لكل بوصة (ldpi)	48 ميغابايت
	140 نقطة لكل بوصة (140 نقطة لكل بوصة)	80 ميغابايت
	160 نقطة لكل بوصة (mdpi)
	180 نقطة لكل بوصة (180 نقطة لكل بوصة)	96 ميغابايت
	200 نقطة لكل بوصة (200 نقطة لكل بوصة)
	213 نقطة لكل بوصة (tvdpi)
	220 نقطة لكل بوصة (220 نقطة لكل بوصة)
	240 نقطة لكل بوصة (hdpi)
	280 نقطة لكل بوصة (280 نقطة لكل بوصة)	144 ميغابايت
	320 نقطة لكل بوصة (xhdpi)	192 ميغابايت
	360 نقطة لكل بوصة (360 نقطة لكل بوصة)	240 ميغابايت
	400 نقطة لكل بوصة (400 نقطة لكل بوصة)	288 ميغابايت
	420 نقطة لكل بوصة (420 نقطة لكل بوصة)	336 ميغابايت
	480 نقطة لكل بوصة (xxhdpi)	384 ميغابايت
	560 نقطة لكل بوصة (560 نقطة لكل بوصة)	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 مع التطبيقات المصغّرة التابعة لجهات خارجية من خلال تحديد نوع المكوِّن وواجهة برمجة التطبيقات المقابلة ودورة الحياة التي تسمح للتطبيقات بعرض "AppWidget" للمستخدم النهائي.

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

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

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

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

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] يُنصح بشدة بإظهار رغبة المستخدم تلقائيًا في حظر إشعار تطبيق معيّن تابع لجهة خارجية لكل قناة وعلى مستوى حزمة تطبيق بعد أن يرفض المستخدم هذا الإشعار عدة مرات.
• يجب أن يكون متوافقًا مع الإشعارات الغنية.
• يجب تقديم بعض الإشعارات ذات الأولوية الأعلى كإشعارات تنبيهية.
• يجب أن يملك المستخدم القدرة على تأجيل الإشعارات.
• قد تدير التطبيقات التابعة لجهات خارجية مستوى الوصول وتوقيت الإشعارات فقط، حيث يمكن للتطبيقات التابعة لجهات خارجية إرسال إشعارات إلى المستخدمين بالأحداث المهمة، وذلك للحدّ من مشاكل السلامة مثل مصادر تشتيت السائق.

يوفِّر Android 11 إمكانية تلقّي إشعارات المحادثات، وهي إشعارات تستخدم 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. وضع "عدم الإزعاج"/وضع الأولوية DND

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

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

3.8.4 واجهات برمجة تطبيقات المساعدة

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

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

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

3.8.5 التنبيهات والإشعارات

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

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

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

• [C-1-2] يجب أن يلتزم بـ Toast API وأن يعرض Toasts من التطبيقات إلى المستخدمين النهائيين بطريقة واضحة للغاية.

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 version 2.x للغات التي يدعمها Roboto، أو توفير إمكانية تغيير الخط المستخدَم في مجموعة خطوط "sans-serif" إلى الإصدار 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

  يُستخدم "لون المصدر" لإنشاء لوحات درجات ألوان ديناميكية عند إرسالها باستخدام 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 نوع المكوّنات وواجهة برمجة التطبيقات ومراحل النشاط المقابلة التي تسمح للتطبيقات بعرض "الخلفيات المتحركة" واحدة أو أكثر للمستخدم النهائي. الخلفيات المتحركة هي الرسوم المتحركة أو الأنماط أو الصور المشابهة ذات إمكانات الإدخال المحدودة التي يتم عرضها كخلفية خلف التطبيقات الأخرى.

تُعتبر الأجهزة قادرة على تشغيل الخلفيات المتحركة بشكل موثوق إذا كان يمكنها تشغيل جميع الخلفيات المتحركة، بدون قيود على الوظائف، وبمعدل عرض إطارات معقول بدون تأثيرات سلبية في التطبيقات الأخرى. إذا تسببت القيود في الأجهزة في تعطُّل الخلفيات و/أو التطبيقات أو تعطُّل وظائفها أو استهلاكها بشكلٍ مفرط في وحدة المعالجة المركزية (CPU) أو طاقة البطارية أو تشغيلها بمعدّلات إطارات منخفضة بشكلٍ غير مقبول، سيُعتبر الجهاز غير قادر على تشغيل خلفية متحركة. فمثلاً، قد تستخدم بعض الخلفيات المتحركة سياق 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 أنشطة في المرة الواحدة.
• [C-1-2] يجب أن ينفذ سلوك تثبيت الشاشة ويوفر للمستخدم قائمة إعدادات لتبديل الميزة.
• "ينبغي" عرض لون التمييز أو الرمز أو عنوان الشاشة في العناصر الأخيرة.
• يجب عرض خاصية الإغلاق ("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-blue، sans-serif-مكثفed،sans-serif-condensed-light للغات المتوفرة على الجهاز.
  • يتضمّن Unicode 7.0 تغطية كاملة للّغات اللاتينية واليونانية والسيريلية، بما في ذلك النطاقات اللاتينية الموسَّعة A وB وC وD، وجميع الرموز الرسومية في كتلة رموز العملة بترميز Unicode 7.0.
• [C-1-3] يجب ألا يزيل أو يعدل NotoColorEmoji.tff في صورة النظام. (يمكن إضافة خط رموز تعبيرية جديد لإلغاء الرموز التعبيرية في NotoColorEmoji.tff)
• يجب أن تكون متوافقة مع درجة لون البشرة والرموز التعبيرية المتنوعة المناسبة للعائلات على النحو المحدّد في تقرير Unicode رقم 51.

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

• يجب أن يتم توفير أسلوب إدخال للمستخدم لهذه الرموز التعبيرية.

يتيح نظام Android عرض خطوط ميانمار. تستخدم ميانمار العديد من الخطوط غير المتوافقة مع Unicode، والمعروفة باسم "Zawgyi"، لعرض لغات ميانمار.

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

• [C-2-1] يجب عرض نص بخط متوافق مع يونيكود كخيار تلقائي، ويجب عدم ضبط الخطوط غير المتوافقة مع يونيكود كخط تلقائي إلّا إذا اختار المستخدم ذلك في أداة اختيار اللغة
• يجب استخدام خط يونيكود وخط غير متوافق مع يونيكود إذا كان خطّ غير متوافق مع يونيكود متوافقًا مع الجهاز. يجب ألا يزيل الخط غير المتوافق مع Unicode أو يستبدل خط Unicode.
• [C-2-3] يجب عرض نص بخط غير متوافق مع يونيكود فقط في حال تحديد رمز لغة برمز النص Qaag (مثل my-Qag). لا يمكن استخدام أي رموز مناطق أو لغات أخرى وفقًا لمعايير ISO (سواءً كانت معيَّنة أو غير معيَّنة أو محجوزة) للإشارة إلى خطوط غير متوافقة مع يونيكود في ميانمار. وبإمكان مطوّري التطبيقات ومؤلفي صفحات الويب تحديد my-Qaag كرمز لغة مخصّص كما هو الحال مع أي لغة أخرى.

3.8.14 نوافذ متعددة

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

• [C-1-1] يجب تنفيذ أوضاع النوافذ المتعددة هذه وفقًا لسلوكيات التطبيقات وواجهات برمجة التطبيقات الموضّحة في مستندات دعم وضع النوافذ المتعددة في Android SDK واستيفاء المتطلبات التالية:
• يجب أن يلتزم [C-1-2] بحزمة android:resizeableActivity التي تم ضبطها من خلال تطبيق في ملف AndroidManifest.xml كما هو موضّح في حزمة تطوير البرامج (SDK) هذه.
• [C-1-3] يجب ألا يوفر وضع تقسيم الشاشة أو وضع الشكل الحر إذا كان ارتفاع الشاشة أقل من 440 وحدة بكسل مستقلة الكثافة (dp) وكان عرض الشاشة أقل من 440 بكسل مستقل الكثافة
• [C-1-4] يجب عدم تغيير حجم النشاط إلى حجم أصغر من 220 بكسل مستقل الكثافة في أوضاع النوافذ المتعددة في أوضاع النوافذ المتعددة.
• يجب أن تتوافق عمليات تنفيذ الأجهزة بحجم الشاشة 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، على النحو المحدّد في نشاط نافذة ضمن النافذة (PIP) من خلال واجهة برمجة تطبيقات setAspectRatio().
• [C-3-4] يجب استخدام KeyEvent.KEYCODE_WINDOW للتحكّم في نافذة PIP، وإذا لم يتم تنفيذ وضع PIP، يجب أن يتوفّر المفتاح للنشاط الذي يتم تنفيذه في المقدّمة.
• [C-3-5] يجب أن تتوفر للمستخدم قدرة على حظر عرض تطبيق في وضع نافذة ضمن النافذة (PIP)، كما أنّ تنفيذ AOSP يلبي هذا الشرط من خلال وجود عناصر تحكم في مركز الإشعارات.

• يجب تخصيص الحدّ الأدنى التالي للعرض والارتفاع في نافذة ضمن النافذة (PIP) في [C-3-6] عندما لا يعرض أحد التطبيقات أي قيمة للسمة AndroidManifestLayout_minWidth وAndroidManifestLayout_minHeight:

  • يجب أن يتم تخصيص حد أدنى للعرض والارتفاع يبلغ 108 وحدة بكسل مستقلة الكثافة في الأجهزة التي تم ضبطها على قيمة Configuration.uiMode غير UI_MODE_TYPE_TELEVISION.
  • يجب أن يتم تخصيص الحدّ الأدنى للعرض الذي يبلغ 240 بكسل مستقل الكثافة (dp) والحدّ الأدنى للارتفاع 135 بكسل مستقل الكثافة في الأجهزة التي تم ضبط قيمة Configuration.uiMode فيها على UI_MODE_TYPE_TELEVISION.

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.9. إدارة الجهاز

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

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

• [C-1-1] يجب أن يفصح عن android.software.device_admin.
• [C-1-2] يجب توفير إمكانية إدارة حسابات مالكي الأجهزة على النحو الموضّح في الفقرة 3.9.1 والفقرة 3.9.1.1.

3.9.1 توفير المتطلبات اللازمة للأجهزة

3.9.1.1 توفير المتطلبات اللازمة لمالك الجهاز

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

• [C-1-1] يجب إتاحة تسجيل برنامج Device Policy (DPC) باعتباره تطبيق مالك الجهاز كما هو موضح أدناه:
  • في حال عدم ضبط بيانات المستخدمين ولا المستخدمين، يتم:
    • [C-1-5] يجب تسجيل تطبيق وحدة التحكّم بسياسة الجهاز (DPC) كتطبيق "مالك الجهاز" أو تفعيل تطبيق DPC لاختيار ما إذا كنت مالك الجهاز أو مالك ملف شخصي في حال أعلن الجهاز عن توفّر "الاتصالات القريبة المدى" (NFC) من خلال علامة الميزة android.hardware.nfc وتلقّى رسالة NFC تحتوي على سجلّ من نوع MIME MIME_TYPE_PROVISIONING_NFC.
    • [C-1-8] يجب إرسال هدف ACTION_GET_PROVISIONING_أوضاع بعد تفعيل توفير المتطلبات اللازمة لمالك الجهاز حتى يتمكّن تطبيق وحدة التحكّم بسياسة الجهاز من اختيار مالك الجهاز أو مالك ملف شخصي بناءً على قيم android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES، ما لم يتم تحديده من السياق بأنّه يتوفّر خيار واحد صالح فقط.
    • [C-1-9] يجب أن يتم إرسال هدف ACTION_ADMIN_POLICY_COMPLIANCE إلى تطبيق "مالك الجهاز" في حال تم إنشاء "مالك الجهاز" أثناء توفير المتطلبات اللازمة بغض النظر عن طريقة توفير المتطلبات اللازمة. يجب ألا يكون المستخدم قادرًا على المتابعة في "معالج الإعداد" حتى ينتهي تطبيق "مالك الجهاز".
  • عندما يشتمل تنفيذ الجهاز على بيانات مستخدمين أو مستخدمين، يتم:
    • [C-1-7] يجب ألا يتم بعد الآن تسجيل أي تطبيق لوحدة التحكّم بسياسة الجهاز (DPC) باعتباره تطبيق مالك الجهاز.
• يجب أن يعرض [C-1-2] إشعار إفصاح مناسبًا (على النحو الموضّح في "المراسلة عبر الإنترنت على Google" (AOSP)) وأن يحصل على موافقة إيجابية من المستخدم النهائي قبل ضبط التطبيق كمالك الجهاز، ما لم يتم ضبط الجهاز آليًا لـ الوضع التجريبي للبيع بالتجزئة قبل تفاعل المستخدم النهائي على الشاشة.

إذا كانت عمليات تنفيذ الأجهزة تشير إلى android.software.device_admin، ولكنها تتضمّن أيضًا حلاً مملوكًا لإدارة الأجهزة وتوفّر آلية لترويج تطبيق تم إعداده في الحل الخاص به باعتباره "مالك الجهاز مكافئًا" لـ "مالك الجهاز" العادي كما تتعرّف عليه واجهات برمجة التطبيقات DevicePolicyManager القياسية في Android، فإنها:

• [C-2-1] يجب أن تتوفّر عملية للتحقّق من أنّ التطبيق المحدّد الذي يتم الترويج له ينتمي إلى حل مشروع لإدارة أجهزة المؤسسة وتم إعداده في حل خاص بالشركة للحصول على حقوق تعادل "مالك الجهاز".
• يجب أن يعرض [C-2-2] بيان الإفصاح عن موافقة مالك الجهاز (AOSP) نفسه كما في المسار الذي بدأه android.app.action.PROVISION_MANAGED_DEVICE قبل تسجيل تطبيق وحدة التحكّم بسياسة الجهاز (DPC) باعتباره "مالك الجهاز".
• [C-2-3] يجب ألا يتم ترميز الموافقة أو منع استخدام تطبيقات مالك الجهاز الأخرى.

3.9.1.2 توفير المتطلبات اللازمة للملف الشخصي المُدار

إذا كانت عمليات تنفيذ الأجهزة تشير إلى android.software.managed_users، سيتم ما يلي:

• [C-1-1] يجب تنفيذ واجهات برمجة التطبيقات التي تسمح لتطبيق وحدة التحكم بسياسة الجهاز (DPC) بأن يصبح مالكًا لملف شخصي مُدار جديد.

• [C-1-2] يجب أن تتوافق عملية توفير المتطلبات اللازمة للملف الشخصي المُدار (المسار الذي تبدأه وحدة التحكّم بسياسة الجهاز (DPC) باستخدام android.app.action.PROVISION_MANAGED_PROFILE) أو من خلال النظام الأساسي) وشاشة الموافقة وتجربة المستخدم مع عملية تنفيذ AOSP.

• يجب أن يوفّر [C-1-3] الخصائص التالية للمستخدم ضمن "الإعدادات" للإبلاغ للمستخدم عند إيقاف إحدى وظائف النظام من قِبل "وحدة التحكّم بسياسة الجهاز" (DPC):

  • يشير هذا المصطلح إلى رمز متّسق أو غير ذلك من خصائص المستخدمين (مثل رمز معلومات AOSP) التي يتم استخدامها لتحديد الحالات التي يقيّد فيها أحد مشرفي الجهاز إعدادًا معيّنًا.
  • هذه رسالة شرح موجزة يوفّرها مشرف الجهاز من خلال setShortSupportMessage.
  • رمز تطبيق وحدة التحكّم بسياسة الجهاز (DPC).

• [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 بعد تفعيل توفير المتطلبات اللازمة لمالك الملف الشخصي حتى يتمكّن تطبيق وحدة التحكّم بسياسة الجهاز من اختيار ما إذا كنت مالكًا للجهاز أو مالكًا لملف شخصي إلا عندما يتم تفعيل إدارة الحسابات من خلال الغرض android.app.action.PROVISION_MANAGED_PROFILE.

• [C-1-7] يجب إرسال هدف ACTION_ADMIN_POLICY_COMPLIANCE إلى ملف العمل عند إنشاء "مالك الملف الشخصي" أثناء توفير المتطلبات اللازمة بصرف النظر عن طريقة توفير المتطلبات اللازمة، إلا إذا تم تفعيل إدارة الحسابات من خلال الغرض android.app.action.PROVISION_MANAGED_PROFILE. يجب ألا يتمكن المستخدم من المتابعة في "معالج الإعداد" إلى أن يتم الانتهاء من تطبيق "مالك الملف الشخصي".

• [C-1-8] يجب إرسال ACTION_MANAGED_PROFILE_PROVISIONED إلى وحدة التحكّم بسياسة الجهاز للملف الشخصي عند إنشاء مالك الملف الشخصي، بغض النظر عن طريقة توفير المتطلبات اللازمة.

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) ووقت تنشيطه (ACTION_USER_PRESENT) وكان التطبيق الذي يعمل في المقدّمة ضمن الملف الشخصي المُدار.
• [C-1-6] عند وجود ملف شخصي مُدار، يجب أن يُظهر عنصر خصائص مرئية في "أداة اختيار Intent" للسماح للمستخدم بإعادة توجيه الهدف من الملف الشخصي المُدار إلى المستخدم الأساسي أو العكس، إذا فعّلته "وحدة التحكّم بسياسة الجهاز".
• [C-1-7] عند وجود ملف شخصي مُدار، يجب أن يعرض الخصائص التالية للمستخدم لكل من المستخدم الأساسي والملف الشخصي المُدار:
  • فصل المستخدم الأساسي عن بيانات البطارية والموقع الجغرافي وبيانات الجوّال واستخدام مساحة التخزين، بالإضافة إلى حساب المستخدم الأساسي والملف الشخصي المُدار
  • الإدارة المستقلة لتطبيقات الشبكة الافتراضية الخاصة المثبَّتة ضمن ملف المستخدم الأساسي أو الملف الشخصي المُدار.
  • إدارة مستقلة للتطبيقات المثبّتة ضمن المستخدم الأساسي أو الملف الشخصي المُدار.
  • إدارة مستقلة للحسابات داخل الملف الشخصي المُدار للمستخدم أو الملف الشخصي المُدار.
• [C-1-8] يجب التأكّد من أنّ برامج الاتصال وجهات الاتصال وتطبيقات المراسلة المثبَّتة مسبقًا يمكنها البحث عن معلومات المتصل والبحث عنها من الملف الشخصي المُدار (إن وُجد) إلى جانب المعلومات الواردة في الملف الشخصي الأساسي، إذا سمحت "وحدة التحكّم في سياسة الجهاز" بذلك.
• [C-1-9] يجب أن يضمن استيفاء هذا الجهاز لجميع متطلبات الأمان السارية على الأجهزة التي تم فيها تفعيل عدة مستخدمين (راجِع القسم 9.5)، حتى لو لم يتم احتساب الملف الشخصي المُدار كمستخدم آخر إلى جانب المستخدم الأساسي.

إذا كانت عمليات تنفيذ الأجهزة تشير إلى android.software.managed_users وandroid.software.secure_lock_screen، سيتم تطبيق ما يلي:

• [C-2-1] يجب أن يتيح إمكانية تحديد شاشة قفل منفصلة تستوفي المتطلبات التالية لمنح إذن الوصول فقط إلى التطبيقات التي تعمل في ملف شخصي مُدار.
  • يجب أن تراعي عمليات تنفيذ الأجهزة هدف DevicePolicyManager.ACTION_SET_NEW_PASSWORD وتعرض واجهة لإعداد بيانات اعتماد منفصلة لشاشة القفل للملف الشخصي المُدار.
  • يجب أن تستخدم بيانات اعتماد شاشة القفل للملف الشخصي المُدار آليات تخزين بيانات الاعتماد وإدارتها نفسها المستخدمة في الملف الشخصي الرئيسي، على النحو الموضَّح في موقع المشروع المفتوح المصدر لنظام Android.
  • يجب أن تنطبق سياسات كلمة المرور في وحدة التحكّم بسياسة الجهاز على بيانات اعتماد شاشة القفل للملف الشخصي المُدار فقط ما لم يتم استدعاؤها من خلال مثال DevicePolicyManager الذي يعرضه getParentProfileInstance
• عند عرض جهات الاتصال من الملف الشخصي المُدار في سجلّ المكالمات المثبَّت مسبقًا وواجهة المستخدم أثناء المكالمة والإشعارات التي لا تزال قيد التقدّم أو المكالمات الفائتة وجهات الاتصال وتطبيقات المراسلة، يجب أن تتم إضافة الشارة إلى التطبيقات نفسها المستخدَمة للإشارة إلى تطبيقات الملف الشخصي المُدارة.

3.9.3 دعم المستخدمين المُدار

إذا كانت عمليات تنفيذ الأجهزة تشير إلى android.software.managed_users، سيتم ما يلي:

• يجب أن يوفّر [C-1-1] إمكانية تسجيل الخروج من المستخدم الحالي والعودة إلى المستخدم الأساسي في جلسة متعددة المستخدمين عندما يعرض isLogoutEnabled true. يجب أن يتمكن المستخدم من الوصول إلى ميزاته من شاشة القفل دون فتح قفل الجهاز.

إذا كانت عمليات تنفيذ الأجهزة تشير إلى android.software.device_admin وتتيح للمستخدم إمكانية إضافة مستخدمين ثانويين آخرين على الجهاز، سيتم إجراء ما يلي:

• [C-SR-1] يُنصَح باستخدامها بشدة لعرض بيانات الإفصاح نفسها التي تم عرضها لمالك الجهاز والتي تم عرضها خلال العملية التي بدأها android.app.action.PROVISION_MANAGED_DEVICE، قبل السماح بإضافة الحسابات إلى حساب "المستخدم الثانوي" الجديد، حتى يعرف المستخدمون أنّ الجهاز مُدار.

3.9.4 متطلبات دور "إدارة سياسات الأجهزة"

في حال حدوث تقرير android.software.device_admin أو android.software.managed_users لعمليات تنفيذ الجهاز، سيتم ما يلي:

• [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.10. تسهيل الاستخدام

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

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

• [C-1-1] يجب أن يتم تنفيذ إطار عمل تسهيل الاستخدام في Android على النحو الموضَّح في مستندات حزمة SDK Accessibility APIs.
• يجب أن ينشئ [C-1-2] أحداث تسهيل الاستخدام ويقدّم AccessibilityEvent المناسب لجميع عمليات تنفيذ AccessibilityService المُسجَّلة كما هو موثَّق في حزمة SDK.
• [C-1-4] يجب أن يتيح للمستخدم التحكّم في خدمات تسهيل الاستخدام التي تشير إلى AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_button. تجدر الإشارة إلى أنّه بالنسبة إلى عمليات تنفيذ الأجهزة التي تتضمّن شريط تنقُّل داخل النظام، يجب أن تتيح للمستخدم إمكانية استخدام زر في شريط التنقّل بالنظام للتحكّم في هذه الخدمات.

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

• [C-2-1] يجب تنفيذ خدمات تسهيل الاستخدام هذه المثبَّتة مسبقًا على أنّها تطبيقات Direct Boot Aware عند تشفير تخزين البيانات باستخدام ميزة "التشفير المستند إلى الملف" (FBE).
• توفير آلية في مسار الإعداد غير المألوف للمستخدمين لتفعيل خدمات تسهيل الاستخدام ذات الصلة، بالإضافة إلى خيارات لضبط حجم الخط وحجم العرض وإيماءات التكبير.

3.11. تحويل النص إلى كلام

يشتمل Android على واجهات برمجة تطبيقات تتيح للتطبيقات استخدام خدمات تحويل النص إلى كلام وتسمح لمقدمي الخدمات بتوفير عمليات تنفيذ خدمات تحويل النص إلى كلام.

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

• [C-1-1] يجب أن يتوافق مع واجهات برمجة التطبيقات إطار عمل تحويل النص إلى كلام في Android.

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

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

3.12. إطار عمل إدخال التلفزيون

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

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

• [C-1-1] يجب أن يعلن عن ميزة المنصة android.software.live_tv.
• [C-1-2] يجب أن يتوافق مع جميع واجهات TIF API، وبالتالي يمكن تثبيت واستخدام أي تطبيق يستخدم واجهات برمجة التطبيقات هذه وخدمة الإدخالات المستندة إلى TIF التابعة لجهات خارجية على الجهاز.

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] يجب ألا تتفاعل التطبيقات الفورية مع التطبيقات المثبّتة باستخدام أهداف ضمنية ما لم ينطبق أي مما يلي:
  • تم الكشف عن فلتر نمط intent للمكوِّن ويحتوي على 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] يجب أن يسمح بتشغيل التطبيقات الفورية بالوصول إليه من دالة "Recents" (الأحدث) إذا كانت وظيفة "الأخيرة" متاحة على الجهاز.

• [C-1-8] يجب تحميل تطبيق أو مكوّن خدمة واحدًا أو أكثر مسبقًا باستخدام معالج intent للأهداف المدرجة في حزمة SDK هنا وإظهار الأهداف للتطبيقات الفورية.

3.16. إقران الجهاز المصاحب

يتيح نظام التشغيل Android إمكانية إقران الأجهزة المصاحبة بشكل أكثر فعالية بإدارة عملية الربط بالأجهزة المصاحبة، كما يوفّر واجهة برمجة التطبيقات CompanionDeviceManager للتطبيقات للوصول إلى هذه الميزة.

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

• [C-1-1] يجب أن يفصح عن علامة الميزة FEATURE_COMPANION_DEVICE_SETUP .
• [C-1-2] يجب أن يتأكد من تنفيذ واجهات برمجة التطبيقات في حزمة android.companion بشكل كامل.
• [C-1-3] يجب أن يوفر للمستخدم خصائص المستخدم لاختيار/التأكد من أن الجهاز المصاحب قيد التشغيل.

3.17. تطبيقات ثقيلة الوزن

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

• يجب أن يتضمّن [C-1-1] تطبيقًا واحدًا مثبّتًا يحدّد cantSaveState قيد التشغيل في النظام في كل مرة. إذا غادر المستخدم هذا التطبيق بدون الخروج منه بشكل صريح (على سبيل المثال، بالضغط على الصفحة الرئيسية أثناء مغادرة النظام النشط، بدلاً من الضغط على الزر للخلف بدون إبقاء أي أنشطة نشطة في النظام)، يجب بالنسبة إلى عمليات تنفيذ الجهاز أن تمنح هذا التطبيق الأولوية في ذاكرة الوصول العشوائي (RAM)، كما هي الحال مع المهام الأخرى التي من المتوقّع أن تظل قيد التشغيل، مثل الخدمات التي تعمل في المقدّمة. عند تشغيل هذا التطبيق في الخلفية، سيظل بإمكان النظام تطبيق ميزات إدارة الطاقة عليه، مثل تقييد الوصول إلى وحدة المعالجة المركزية (CPU) والشبكة.
• [C-1-2] يجب أن تتوفر ميزة واجهة المستخدم لاختيار التطبيق الذي لن يشارك في آلية الحفظ/الاستعادة في الحالة العادية بعد تشغيل المستخدم لتطبيق ثانٍ تم الإعلان عنه باستخدام السمة cantSaveState.
• [C-1-3] يجب ألا يتم تطبيق تغييرات أخرى في السياسة على التطبيقات التي تحدّد cantSaveState، مثل تغيير أداء وحدة المعالجة المركزية (CPU) أو تغيير أولويات الجدولة.

إذا لم تشير عمليات تنفيذ الأجهزة إلى الميزة FEATURE_CANT_SAVE_STATE، سيتم:

• [C-1-1] يجب أن يتجاهل سمة cantSaveState التي ضبطتها التطبيقات ويجب ألا تغيّر سلوك التطبيق استنادًا إلى تلك السمة.

3.18. جهات اتصال Google

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

RawContacts "مرتبطة" أو "مخزنة" في حساب عندما يتطابق عمودا ACCOUNT_NAME وACCOUNT_TYPE جهات الاتصال الأولية مع حقلَي Account.name وAccount.type المقابل للحساب.

حساب محلي تلقائي: حساب لجهات الاتصال الأولية المخزّنة على الجهاز فقط وغير المرتبطة بحساب في AccountManager، والتي يتم إنشاؤها باستخدام القيم خالية للعمودَين 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] يجب إدراج جهات الاتصال الأولية التي يتم إدراجها من خلال تطبيقات الجهات الخارجية باستخدام الحساب المحلي التلقائي (أي من خلال ضبط قيم فارغة في ACCOUNT_NAME وACCOUNT_TYPE) إلى الحساب المحلي المخصص.
• [C-1-4] يجب عدم إزالة جهات الاتصال الأولية المدرجة في الحساب المحلي المخصص عند إضافة الحسابات أو إزالتها.
• [C-1-5] عند حذف العمليات على الحساب المحلي المخصّص، يجب أن تتم إزالة جهات الاتصال الأولية فورًا (كما لو تم ضبط معلَمة CALLER_IS_SYNCADAPTER على "صحيح")، حتى إذا تم ضبط معلَمة CALLER\_IS\_SYNCADAPTER على "خطأ" أو لم يتم تحديدها.

4. توافق حزمة التطبيقات

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

• يجب أن يكون لدى [C-0-1] إمكانية تثبيت ملفات .apk وتشغيلها على نظام Android كما تم إنشاؤه بواسطة أداة "aapt" المضمّنة في حزمة تطوير البرامج (SDK) الرسمية لنظام التشغيل Android.

  • بما أنّ الشرط أعلاه قد يمثّل تحديًا، ننصح عمليات تنفيذ الأجهزة باستخدام نظام إدارة الحزم الخاص بتنفيذ مرجع AOSP.

• يجب أن يتيح [C-0-2] إثبات ملكية ملفات " .apk" باستخدام الإصدار 3.1 من "مخطط توقيع حِزم APK" والإصدار 3 من مخطّط توقيع حِزم APK والإصدار 2 من مخطّط توقيع حِزم APK وتوقيع JAR.

• [C-0-3] يجب ألا يوسّع نطاق تنسيقات الترميز .apk أو بيان Android أو Dalvik bytecode أو 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.

ملاحظة: قد تُستثنى من هذه المتطلبات عمليات تنفيذ الأجهزة التي تم شحنها إلى الإصدار 10 من نظام التشغيل Android أو الإصدارات الأقدم والتي لا يمكنها استيفاء المتطلبات [C-0-8] و[C-0-9] من خلال تحديث برنامج النظام.

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-3-1] إطارات صوت PCM أصلية 16 بت من خلال واجهة برمجة التطبيقات android.media.MediaCodec.

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-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile، والذي يتضمّن ملف USAC Baseline Profile وISO/IEC 23003-4 للتحكم في النطاق الديناميكي)
• [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

إذا كانت عمليات تنفيذ الأجهزة تتيح فك ترميز المخازن المؤقتة لإدخالات AAC الخاصة بالبث المتعدد القنوات (أي أكثر من قناتَين) إلى PCM من خلال أداة فك ترميز الصوت التلقائية AAC في واجهة برمجة التطبيقات android.media.MediaCodec API، يجب استخدام ما يلي:

• [C-2-1] يجب تنفيذ عملية فك الترميز بدون إعادة المزج (على سبيل المثال، يجب فك ترميز مجموعة بث بتنسيق 5.0 AAC إلى خمس قنوات من PCM، ويجب فك ترميز مجموعة بث بتنسيق 5.1 AAC إلى ست قنوات من PCM).
• [C-2-2] يجب أن تكون البيانات الوصفية للنطاق الديناميكي كما هو موضّح في "التحكّم في النطاق الديناميكي (DRC)" في المعيار ISO/IEC 14496-3، ومفاتيح DRC في android.media.MediaFormat لضبط السلوكيات ذات الصلة بالنطاق الديناميكي في برنامج فك ترميز الصوت. تم تقديم مفاتيح 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] يُنصح بشدة باستيفاء المتطلبات C-2-1 وC-2-2 أعلاه من خلال جميع برامج فك ترميز الصوت AAC.

عند فك ترميز صوت USAC، تنسيق MPEG-D (ISO/IEC 23003-4):

• [C-3-1] يجب تفسير البيانات الوصفية لكلٍّ من ارتفاع الصوت وجمهورية الكونغو الديمقراطية وتطبيقها وفقًا للمستوى 1 من ملف التحكم في النطاق الديناميكي في MPEG-D DRC.
• [C-3-2] يجب أن يعمل برنامج فك الترميز وفقًا لإعدادات الضبط مع مفتاحَي android.media.MediaFormat التاليَين: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL وKEY_AAC_DRC_EFFECT_TYPE.

برامج فك ترميز الملف الشخصي MPEG-4 AAC وHE AAC وHE AACv2:

• قد تتوفّر إمكانية التحكّم في مستوى ارتفاع الصوت والنطاق الديناميكي باستخدام ملف التعريف الديناميكي للتحكم في النطاق الديناميكي وفقًا لمعيار 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 API، يجب استخدام العناصر التالية:

• [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).

إذا كانت عمليات فك ترميز الصوت على الأجهزة تتوافق مع برامج فك ترميز الصوت غير برنامج فك ترميز الصوت 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. تفاصيل برامج ترميز الصوت

التنسيق/برنامج الترميز	التفاصيل	أنواع الملفات/تنسيقات الحاويات المطلوبة
ملف MPEG-4 AAC الشخصي (AAC LC)	يمكن استخدام المحتوى الأحادي/استيريو/5.0/5.1 بمعدّلات أخذ العيّنات العادية من 8 إلى 48 كيلوهرتز.	3GPP (.3gp) MPEG-4 (.mp4 و .m4a) تنسيق AAC الأولي لـ 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 الملف الشخصي (تحسين AAC+ )	يمكن استخدام المحتوى الأحادي/استيريو/5.0/5.1 بمعدّلات أخذ العيّنات العادية من 16 إلى 48 كيلوهرتز.	3GPP (.3gp) MPEG-4 (.mp4 و .m4a)
AAC ELD (معيار AAC منخفض ومحسّن)	يمكن استخدام المحتوى الأحادي/استيريو مع معدّلات أخذ العيّنات العادية من 16 إلى 48 كيلوهرتز.	3GPP (.3gp) MPEG-4 (.mp4 و .m4a)
الولايات المتحدة الأمريكية (USAC)	يمكن استخدام المحتوى الأحادي/استيريو مع معدّلات أخذ العيّنات العادية من 7.35 إلى 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 كيلوبت في الثانية (CBR) أو معدل نقل بيانات متغير (VBR)	MP3 ‏(‎.mp3) MPEG-4 (.mp4 و .m4a وفك الترميز فقط) Matroska (.mkv، فك الترميز فقط)
MIDI	نوعا MIDI 0 و1. الإصدار 1 و2 من DLS. XMF وMobile XMF. إتاحة تنسيقات نغمات الرنين RTTTL/RTX وOTA وiMelody	اكتب 0 و1 (.mid و .xmf و .mxmf) RTTTL/RTX (.rtttl و .rtx) iMelody (.imy)
فوربيس	فك الترميز: التوافق مع المحتوى الأحادي والاستيريو و5.0 و5.1 بمعدلات أخذ العينات 8000 و12000 و16000 و24000 و48000 هرتز. الترميز: يتيح استخدام المحتوى الأحادي و الاستيريو مع معدّلات العيّنات 8000 و12000 و12000	Ogg (.ogg) MPEG-4 (.mp4 و .m4a وفك الترميز فقط) Matroska (.mkv) Webm (.webm)
تضمين نبضي مشفر (PCM)/موجة (موجة)	يجب أن يتوافق برنامج ترميز 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 و12000 و8000 و12000 هرتز.	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

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع ترميز 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

إذا كانت عمليات تنفيذ الأجهزة تتيح فك ترميز فيديو HEVC، يجب أن يتوافق فك ترميز صورة HEIF (HEIC) مع: * [C-1-1].

برامج فك ترميز الصور التي تدعم تنسيقًا عاليًا البت (أكثر من 9 وحدات بت لكل قناة):

• يجب أن يتيح [C-2-1] إخراج تنسيق مكافئ بتنسيق 8 بت إذا طلبه التطبيق، على سبيل المثال، من خلال إعدادات ARGB_8888 في android.graphics.Bitmap.

5.1.6. تفاصيل برامج ترميز الصور

التنسيق/برنامج الترميز	التفاصيل	أنواع الملفات/تنسيقات الحاويات المتوافقة
صور JPEG	أساسي+تدريجي	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)

برنامج ترميز الصور وفكّ الترميز الظاهرَين من خلال واجهة برمجة التطبيقات MediaCodec

• [C-1-1] يجب أن يتوافق مع YUV420 8:8:8 بتنسيق الألوان المرنة (COLOR_FormatYUV420Flexible) حتى CodecCapabilities.

• [C-SR-1] يُنصَح بشدة بأن يتوافق مع تنسيق الألوان RGB888 في وضع "سطح الإدخال"

• [C-1-3] يجب أن يتيح استخدام تنسيق واحد على الأقل من تنسيق الألوان المسطحة أو شبه المسطحة YUV420 بتنسيق الألوان 8:8:8: COLOR_FormatYUV420PackedPlanar (ما يعادل COLOR_FormatYUV420Planar) أو COLOR_FormatYUV420PackedSemiPlanar (ما يعادل COLOR_FormatYUV420SemiPlanar). يُنصح بشدة بأن يتيح استخدامهما كلاهما.

5.1.7. برامج ترميز الفيديو

• للحصول على جودة مقبولة لخدمات بث الفيديو على الويب ومؤتمرات الفيديو، يجب أن تستخدم عمليات تنفيذ الأجهزة برنامج ترميز VP8 للأجهزة يستوفي المتطلبات.

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

• [C-1-1] يجب أن تتيح برامج ترميز الفيديو أحجام وحدات بايت المدخلات والمخرجات التي تتوافق مع أكبر إطار ممكن مضغوطًا وغير مضغوط وفقًا لما يحدده المعيار والضبط، ولكن ليس بشكل عام أيضًا.

• [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.

في حال أعلنت عمليات تنفيذ الأجهزة عن توفّر الملف الشخصي بنطاق عالي الديناميكية من خلال 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) في حال ضبطه على عدم استخدام مخرج السطح.

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، فك الترميز فقط)
نموذج الفيديو 8 (VP8)	راجِع القسم 5.2 و5.3 لمعرفة التفاصيل.	WebM (.webm) Matroska (.mkv)
نموذج الفيديو 9 (VP9)	راجِع القسم 5.3 لمعرفة التفاصيل.	WebM (.webm) Matroska (.mkv)

5.1.9. أمان برنامج ترميز الوسائط

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

يتيح Android الدعم لـ OMX، وهي واجهة برمجة تطبيقات لتسريع الوسائط المتعددة عبر الأنظمة الأساسية، بالإضافة إلى Codec 2.0، وهي واجهة برمجة تطبيقات لتسريع الوسائط المتعددة تعمل بسرعة منخفضة.

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

• [C-1-1] يجب أن يتم توفير الدعم لبرامج ترميز الوسائط إما من خلال واجهات برمجة التطبيقات OMX أو Codec 2.0 (أو كليهما) كما في "المشروع المفتوح المصدر لنظام Android" وعدم إيقاف إجراءات الحماية الأمنية أو التحايل عليها. وهذا لا يعني على وجه التحديد أنّ كل برنامج ترميز يجب أن يستخدم OMX أو Codec 2.0 API، بل يجب أن يتوفّر فقط دعم واجهة واحدة على الأقل من واجهات برمجة التطبيقات هذه، ويجب أن يشمل التوافق مع واجهات برمجة التطبيقات المتاحة وسائل الحماية الأمنية المتوفّرة.
• [C-SR-1] يُنصَح بشدة بتضمين إمكانية استخدام واجهة برمجة التطبيقات Codec 2.0 API

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

• يجب أن يتضمّن [C-2-1] برنامج ترميز برنامج OMX المقابل من "المشروع المفتوح المصدر لنظام Android" (إذا كان متاحًا) لكل تنسيق ونوع وسائط (برنامج ترميز أو برنامج فك ترميز) متوافق مع الجهاز.
• [C-2-2] برامج الترميز التي تبدأ أسماؤها بـ "OMX.google" إلى رمز مصدر "المشروع المفتوح المصدر" على Android
• [C-SR-2] يُنصح بشدة بتشغيل برامج ترميز برامج OMX في عملية ترميز لا تتيح الوصول إلى برامج تشغيل الأجهزة غير برامج تصميم الخرائط باستخدام الذاكرة.

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

• يجب أن يشتمل [C-3-1] على برنامج ترميز البرنامج المقابل للإصدار 2.0 من "المشروع المفتوح المصدر لنظام Android" (إذا كان متاحًا) لكل تنسيق ونوع وسائط (برنامج ترميز أو برنامج فك ترميز) متوافق مع الجهاز.
• [C-3-2] يجب أن يحتوي على برامج ترميز البرنامج Codec 2.0 ضمن عملية ترميز البرامج كما هو منصوص عليه في "مشروع Android Open Source" (مشروع مفتوح المصدر لنظام 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] يجب أن تنشر جميع برامج ترميز الفيديو بيانات قابلة للتحقيق في عدد اللقطات في الثانية بالأحجام التالية إذا كان برنامج الترميز متوافقًا:

	SD (جودة منخفضة)	SD (جودة عالية)	دقة عالية - 720 بكسل	دقة عالية - 1080 بكسل	دقة فائقة
دقة الفيديو	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 بكسل (غير ذلك)	1408 × 1152 بكسل (H263) 1280 × 720 بكسل (غير ذلك)	1920 × 1080 بكسل (بخلاف MPEG4)	3840 × 2160 بكسل (HEVC وVP9)

• [C-2-2] يجب على برامج ترميز الفيديو التي يتم تصنيفها كأجهزة مسرَّعة نشر معلومات حول نقاط الأداء. يجب أن تتضمن كل قائمة بجميع نقاط الأداء العادية المتوافقة (المدرجة في واجهة برمجة تطبيقات PerformancePoint)، ما لم تكن مشمولة بنقطة أداء عادية أخرى متوافقة.
• بالإضافة إلى ذلك، يُفترض أن تنشر نقاط أداء إضافية إذا كانت تدعم أداء فيديو مستدامًا بخلاف الأداء القياسي المذكور.

5.2. ترميز الفيديو

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

• ينبغي ألا يزيد معدل نقل البيانات عن نافذتين منزلقتين عن معدل نقل البيانات بين الفواصل الزمنية داخل الإطار (I-frame).
• من المفترض ألا يتجاوز معدل نقل البيانات نسبة 100% خلال نافذة منبثقة تبلغ ثانية واحدة.

إذا كانت تصاميم الأجهزة تتضمّن شاشة شاشة مضمَّنة لا يقل طولها عن 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] يجب أن تتوافق جميع برامج تشفير الفيديو والصور مع الأجهزة المسرّعة مع ترميز الإطارات من كاميرات الأجهزة.
• "يجب أن يكون" متوافقًا مع إطارات الترميز من كاميرات الأجهزة من خلال جميع برامج ترميز الفيديو أو الصور.

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

• [C-SR-1] يُنصح بشدة بتوفير مكوّن إضافي لواجهة برمجة تطبيقات التحويل السلس لتحويل الترميز من تنسيق HDR إلى تنسيق SDR.

5.2.1. بروتوكول H.263

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

• [C-1-1] يجب أن يتوافق مع المستوى 45 للملف الشخصي الأساسي.
• يجب أن يتوافق مع معدلات نقل البيانات القابلة للضبط ديناميكيًا لبرنامج الترميز المتوافق.

5.2.2. H.264

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

• [C-1-1] يجب أن يتوافق مع المستوى 3 للملف الشخصي الأساسي. ومع ذلك، فإن دعم ASO (ترتيب الشرائح العشوائي) وFMO (الترتيب المرن للكتلة الفائقة) وRS (الشرائح المتكررة) اختياري. علاوة على ذلك، للحفاظ على التوافق مع أجهزة Android الأخرى، يُنصح بعدم استخدام ASO وFMO وRS في "الملف الشخصي الأساسي" بواسطة برامج الترميز.
• [C-1-2] يجب أن يتوافق مع ملفات ترميز الفيديو ذات الدقة العادية (SD) في الجدول التالي.
• يجب أن يتوافق مع المستوى 4 للملف الشخصي الرئيسي.
• يجب أن يتوافق مع ملفات ترميز الفيديو ذات الدقة العالية (HD) كما هو موضّح في الجدول التالي.

إذا كانت عمليات التنفيذ على الأجهزة تفيد بترميز H.264 للفيديوهات بدقة 720p أو 1080p من خلال واجهات برمجة تطبيقات الوسائط، سيتم إجراء ما يلي:

• [C-2-1] يجب أن يتوافق مع ملفات الترميز الشخصية في الجدول التالي.

	دقة عادية (جودة منخفضة)	دقة عادية (جودة عالية)	دقة عالية - 720 بكسل	دقة عالية - 1080 بكسل
دقة الفيديو	320 × 240 بكسل	720 × 480 بكسل	1280 × 720 بكسل	1920 × 1080 بكسل
عدد اللقطات في الثانية للفيديو	20 لقطة في الثانية	30 إطارًا في الثانية	30 إطارًا في الثانية	30 إطارًا في الثانية
معدّل نقل بيانات الفيديو	384 كيلوبت في الثانية	2 ميغابت في الثانية	‫4 ميغابت في الثانية	‫10 ميغابت في الثانية

5.2.3. نموذج الفيديو 8 (VP8)

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

• [C-1-1] يجب أن يتوافق مع ملفات ترميز الفيديو بدقة عادية.
• يجب أن يتوافق مع ملفات ترميز الفيديو ذات الدقة العالية (HD) التالية.
• [C-1-2] يجب أن يتيح كتابة ملفات Matroska WebM.
• يجب توفير برنامج ترميز VP8 للأجهزة يستوفي متطلبات ترميز أجهزة RTC لمشروع WebM، لضمان جودة مقبولة لخدمات بث الفيديو على الويب وخدمات مؤتمرات الفيديو.

إذا كانت عمليات تنفيذ الأجهزة تفيد بترميز VP8 للفيديوهات بدقة 720p أو 1080p من خلال واجهات برمجة تطبيقات الوسائط، سيتم إجراء ما يلي:

• [C-2-1] يجب أن يتوافق مع ملفات الترميز الشخصية في الجدول التالي.

	دقة عادية (جودة منخفضة)	دقة عادية (جودة عالية)	دقة عالية - 720 بكسل	دقة عالية - 1080 بكسل
دقة الفيديو	320 × 180 بكسل	640 × 360 بكسل	1280 × 720 بكسل	1920 × 1080 بكسل
عدد اللقطات في الثانية للفيديو	30 إطارًا في الثانية	30 إطارًا في الثانية	30 إطارًا في الثانية	30 إطارًا في الثانية
معدّل نقل بيانات الفيديو	800 كيلوبت في الثانية	2 ميغابت في الثانية	‫4 ميغابت في الثانية	‫10 ميغابت في الثانية

5.2.4. نموذج الفيديو 9 (VP9)

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

• [C-1-2] يجب توفير الملف الشخصي 0 المستوى 3.
• [C-1-1] يجب أن يتيح كتابة ملفات Matroska WebM.
• [C-1-3] يجب أن ينشئ بيانات Codecprivate.
• "يُفترض" أن تتيح استخدام الملفات الشخصية لفك ترميز المحتوى بدقة عالية كما هو موضّح في الجدول التالي.
• يوصى بشدة بأن تتيح [C-SR-1] استخدام الملفات الشخصية لفك ترميز المحتوى بدقة عالية كما هو موضّح في الجدول التالي في حال توفُّر برنامج ترميز للأجهزة.

	الدقة العادية	دقة عالية - 720 بكسل	دقة عالية - 1080 بكسل	دقة فائقة
دقة الفيديو	720 × 480 بكسل	1280 × 720 بكسل	1920 × 1080 بكسل	3840 × 2160 بكسل
عدد اللقطات في الثانية للفيديو	30 إطارًا في الثانية	30 إطارًا في الثانية	30 إطارًا في الثانية	30 إطارًا في الثانية
معدّل نقل بيانات الفيديو	1.6 ميغابت في الثانية	‫4 ميغابت في الثانية	‫5 ميغابت في الثانية	20 ميغابت في الثانية

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

• يتوفّر الدعم لتنسيق 12 بت بشكلٍ اختياري.

5.2.5. بروتوكول H.265

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

• [C-1-1] يجب أن يتوافق مع المستوى 3 للملف الشخصي الرئيسي.
• يجب أن يتوافق مع ملفات الترميز العالية الدقة كما هو موضّح في الجدول التالي.
• يُنصَح بشدة بأن تكون [C-SR-1] متوافقة مع الملفات الشخصية لترميز المحتوى بدقة عالية، كما هو موضّح في الجدول التالي في حال توفّر برنامج ترميز للأجهزة.

	الدقة العادية	دقة عالية - 720 بكسل	دقة عالية - 1080 بكسل	دقة فائقة
دقة الفيديو	720 × 480 بكسل	1280 × 720 بكسل	1920 × 1080 بكسل	3840 × 2160 بكسل
عدد اللقطات في الثانية للفيديو	30 إطارًا في الثانية	30 إطارًا في الثانية	30 إطارًا في الثانية	30 إطارًا في الثانية
معدّل نقل بيانات الفيديو	1.6 ميغابت في الثانية	‫4 ميغابت في الثانية	‫5 ميغابت في الثانية	20 ميغابت في الثانية

5.3. فك ترميز الفيديو

في حال كانت عمليات تنفيذ الأجهزة تتوافق مع برامج ترميز VP8 أو VP9 أو H.264 أو H.265، سيتم إجراء ما يلي:

• [C-1-1] يجب أن يتيح التبديل بين درجة دقة الفيديو وعدد اللقطات في الثانية من خلال واجهات برمجة تطبيقات Android العادية ضمن البث نفسه لجميع برامج الترميز VP8 وVP9 وH.264 وH.265 في الوقت الفعلي وبدرجة الدقة القصوى المسموح بها في كل برنامج ترميز على الجهاز.

5.3.1. MPEG-2

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع برامج فك ترميز MPEG-2، سيتم إجراء ما يلي:

• [C-1-1] يجب أن يتوافق مع المستوى العالي للملف الشخصي الرئيسي.

5.3.2 بروتوكول H.263

إذا كانت عمليات تنفيذ الأجهزة متوافقة مع برامج فك ترميز H.263، سيتم إجراء ما يلي:

• [C-1-1] يجب أن يتوافق مع المستوى 30 والمستوى 45 للملف الشخصي الأساسي.

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) المدرجة في الجدول التالي والمرمّزة باستخدام الملف الشخصي الأساسي والمستوى 3.1 من الملف الشخصي الرئيسي (بما في ذلك 720p30).
• "يجب أن تكون قادرًا على فك ترميز الفيديوهات" باستخدام الملفات الشخصية ذات الدقة العالية (HD) كما هو موضَّح في الجدول التالي.

إذا كان الارتفاع الذي تم الإبلاغ عنه من خلال طريقة Display.getSupportedModes() مساويًا لدرجة دقة الفيديو أو أكبر منه، تكون عمليات تنفيذ الأجهزة:

• [C-2-1] يجب أن يتوافق مع الملفات الشخصية لفك ترميز الفيديو بدقة عالية تبلغ 720p في الجدول التالي.
• [C-2-2] يجب أن يتوافق مع الملفات الشخصية لفك ترميز الفيديو بدقة عالية 1080p في الجدول التالي.

	دقة عادية (جودة منخفضة)	دقة عادية (جودة عالية)	دقة عالية - 720 بكسل	دقة عالية - 1080 بكسل
دقة الفيديو	320 × 240 بكسل	720 × 480 بكسل	1280 × 720 بكسل	1920 × 1080 بكسل
عدد اللقطات في الثانية للفيديو	30 إطارًا في الثانية	30 إطارًا في الثانية	60 لقطة في الثانية	30 لقطة في الثانية (60 لقطة في الثانية^التلفزيون)
معدّل نقل بيانات الفيديو	800 كيلوبت في الثانية	2 ميغابت في الثانية	‫8 ميغابت في الثانية	20 ميغابت في الثانية

5.3.5. ‫H.265 (HEVC)

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

• [C-1-1] يجب أن تتوافق مع المستوى الرئيسي للملف الشخصي الرئيسي من المستوى 3 والملفات الشخصية لفك ترميز الفيديوهات بدقة عادية كما هو موضّح في الجدول التالي.
• "يُفترض" أن تتيح استخدام الملفات الشخصية لفك ترميز المحتوى بدقة عالية كما هو موضّح في الجدول التالي.
• [C-1-2] يجب أن يتوافق مع الملفات الشخصية لفك ترميز المحتوى بدقة عالية كما هو موضّح في الجدول التالي في حال توفُّر برنامج لفك ترميز الأجهزة.

إذا كان الارتفاع الذي تم الإبلاغ عنه من خلال Display.getSupportedModes() يساوي أو أكبر من درجة دقة الفيديو، يجب عندها:

• [C-2-1] يجب أن تتيح عمليات تنفيذ الأجهزة استخدام ملف واحد على الأقل من فك ترميز H.265 أو VP9 للملفات الشخصية ذات الجودة الفائقة 720 و1080 والدقة الفائقة.

	دقة عادية (جودة منخفضة)	دقة عادية (جودة عالية)	دقة عالية - 720 بكسل	دقة عالية - 1080 بكسل	دقة فائقة
دقة الفيديو	352 × 288 بكسل	720 × 480 بكسل	1280 × 720 بكسل	1920 × 1080 بكسل	3840 × 2160 بكسل
عدد اللقطات في الثانية للفيديو	30 إطارًا في الثانية	30 إطارًا في الثانية	30 إطارًا في الثانية	30/60 لقطة في الثانية (60 لقطة في الثانية^التلفزيون باستخدام فك ترميز أجهزة H.265)	60 لقطة في الثانية
معدّل نقل بيانات الفيديو	600 كيلوبت في الثانية	1.6 ميغابت في الثانية	‫4 ميغابت في الثانية	‫5 ميغابت في الثانية	20 ميغابت في الثانية

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

• [C-3-1] يجب أن تقبل عمليات تنفيذ الأجهزة البيانات الوصفية المطلوبة ذات تنسيق HDR من التطبيق، فضلاً عن إتاحة استخراج وإخراج البيانات الوصفية ذات تنسيق HDR المطلوبة من البث البت و/أو الحاوية.
• [C-3-2] يجب أن تعرض عمليات تنفيذ الأجهزة محتوى النطاق العالي الديناميكية بشكل صحيح على شاشة الجهاز أو على منفذ إخراج الفيديو العادي (مثل HDMI).

5.3.6. نموذج الفيديو 8 (VP8)

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

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

إذا كان الارتفاع كما هو موضح من خلال الطريقة Display.getSupportedModes() يساوي أو أكبر من درجة دقة الفيديو، يجب عندها:

• [C-2-1] يجب أن تتوافق عمليات تنفيذ الأجهزة مع ملفات شخصية بدقة 720p في الجدول التالي.
• [C-2-2] يجب أن تتيح عمليات تنفيذ الأجهزة استخدام ملفات شخصية بدقة 1080p في الجدول التالي.

	دقة عادية (جودة منخفضة)	دقة عادية (جودة عالية)	دقة عالية - 720 بكسل	دقة عالية - 1080 بكسل
دقة الفيديو	320 × 180 بكسل	640 × 360 بكسل	1280 × 720 بكسل	1920 × 1080 بكسل
عدد اللقطات في الثانية للفيديو	30 إطارًا في الثانية	30 إطارًا في الثانية	30 لقطة في الثانية (60 لقطة في الثانية^التلفزيون)	30 (60 لقطة في الثانية^التلفزيون)
معدّل نقل بيانات الفيديو	800 كيلوبت في الثانية	2 ميغابت في الثانية	‫8 ميغابت في الثانية	20 ميغابت في الثانية

5.3.7. نموذج الفيديو 9 (VP9)

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

• [C-1-1] يجب أن يتوافق مع الملفات الشخصية لفك ترميز الفيديوهات بدقة عادية كما هو موضّح في الجدول التالي.
• "يُفترض" أن تتيح استخدام الملفات الشخصية لفك ترميز المحتوى بدقة عالية كما هو موضّح في الجدول التالي.

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

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

إذا كان الارتفاع الذي تم الإبلاغ عنه من خلال Display.getSupportedModes() يساوي أو أكبر من درجة دقة الفيديو، يجب عندها:

• [C-3-1] يجب أن تتيح عمليات تنفيذ الأجهزة استخدام حل واحد على الأقل من فك ترميز VP9 أو H.265 للملفات الشخصية 720 و1080 وUHD.

	دقة عادية (جودة منخفضة)	دقة عادية (جودة عالية)	دقة عالية - 720 بكسل	دقة عالية - 1080 بكسل	دقة فائقة
دقة الفيديو	320 × 180 بكسل	640 × 360 بكسل	1280 × 720 بكسل	1920 × 1080 بكسل	3840 × 2160 بكسل
عدد اللقطات في الثانية للفيديو	30 إطارًا في الثانية	30 إطارًا في الثانية	30 إطارًا في الثانية	30 لقطة في الثانية (60 لقطة في الثانية^التلفزيون باستخدام فك ترميز أجهزة VP9)	60 لقطة في الثانية
معدّل نقل بيانات الفيديو	600 كيلوبت في الثانية	1.6 ميغابت في الثانية	‫4 ميغابت في الثانية	‫5 ميغابت في الثانية	20 ميغابت في الثانية

إذا ادّعت عمليات تنفيذ الأجهزة أنّها تتيح VP9Profile2 أو VP9Profile3 من خلال واجهات برمجة تطبيقات الوسائط 'CodecProfileLevel:

• يتوفّر الدعم لتنسيق 12 بت بشكلٍ اختياري.

إذا ادّعت عمليات تنفيذ الأجهزة أنّها تتيح ملف شخصي بنطاق عالي الديناميكية (VP9Profile2HDR، VP9Profile2HDR10Plus، VP9Profile3HDR، VP9Profile3HDR10Plus) من خلال واجهات برمجة تطبيقات الوسائط:

• [C-4-1] يجب أن تقبل عمليات تنفيذ الأجهزة البيانات الوصفية المطلوبة بتقنية HDR (KEY_HDR_STATIC_INFO لجميع الملفات الشخصية بتقنية HDR، وكذلك "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] يجب أن يتوافق مع الملف الشخصي 0، بما في ذلك محتوى 10 بت.

5.4. تسجيل الصوت

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

5.4.1. معلومات تسجيل الصوت والميكروفونات الأولية

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

• [C-1-1] يجب أن يسمح بالتقاط المحتوى الصوتي الأولي لأي بث AudioRecord أو AAudio INPUT يتم فتحه بنجاح. يجب على الأقل توفُّر الخصائص التالية:

  • التنسيق: PCM خطي، 16 بت
  • معدّلات أخذ العيّنات: 8000، 11025، 16000، 44100، 48,000 هرتز
  • القنوات: أحادي
  • مصادر الصوت: DEFAULT أو MIC أو CAMCORDER أو VOICE_RECOGNITION أو VOICE_COMMUNICATION أو UNPROCESSED أو VOICE_PERFORMANCE. ينطبق ذلك أيضًا على الإعدادات المسبقة للإدخال المكافئة في AAudio، على سبيل المثال، AAUDIO_INPUT_PRESET_CAMCORDER.

• "يجب السماح" بالتقاط المحتوى الصوتي الأوّلي الذي يتضمّن الخصائص التالية:

  • التنسيق: PCM الخطي، 16 بت و24 بت
  • معدلات أخذ العينات: 8000، 11025، 16000، 22050، 24000، 32,000، 44100، 48,000 هرتز
  • القنوات: عدد القنوات الذي يساوي عدد الميكروفونات على الجهاز

• [C-1-2] يجب أن يتم التقاطها بمعدلات عينة أعلى من دون زيادة العينات.

• يجب أن يشتمل [C-1-3] على فلتر مناسب للانزلاق عند تسجيل معدلات العينة المذكورة أعلاه باستخدام العينات المنخفضة.

• "ينبغي" السماح بالتقاط جودة راديو AM وDVD للمحتوى الصوتي الأولي، الأمر الذي يعني الخصائص التالية:

  • التنسيق: PCM خطي، 16 بت
  • معدلات أخذ العينات: 22050، 48000 هرتز
  • القنوات: استيريو

• يجب أن يلتزم [C-1-4] بواجهة برمجة تطبيقات MicrophoneInfo وأن يملأ بشكل صحيح المعلومات المتعلّقة بالميكروفونات المتاحة على الجهاز التي يمكن الوصول إليها من خلال التطبيقات التابعة لجهات خارجية عبر AudioManager.getMicrophones() واجهة برمجة التطبيقات لـ AudioRecord النشطة باستخدام 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 هرتز لكل عينة عائمة تبلغ ترددها على مستوى 90 ديسيبل (SPL) عند قياس مستوى ضغط الصوت (SPL) بقياس 90 ديسيبل (أو ما يعادله بالعملة المحلية)، ويتم الحصول على استجابة مثالية بمعدّل RMS 2500 في نطاق يتراوح بين 1770 و3530 عينة عائمة لكل عينة عائمة أو 35 بت على مستوى عينة عائمة.

• يجب تسجيل البث الصوتي لميزة "التعرّف على الصوت" كي يتتبّع مستوى اتساع صوت PCM خطيًا تغيير مستوى الصوت SPL الخطي بما يزيد عن 30 ديسيبل ويتراوح من -18 ديسيبل إلى +12 ديسيبل re 90 ديسيبل من مستوى الصوت المنخفض في الميكروفون.

• "يجب" تسجيل البث الصوتي لميزة "التعرّف على الصوت" مع تشوّه إجمالي

إذا رصدت عمليات تنفيذ الأجهزة تكنولوجيا 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 API للتسجيل من مصدر الصوت هذا، يتم تسجيل مزيج من كل عمليات البث الصوتي باستثناء ما يلي:

  • 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] يتم الإجراء strongLY_RECOMMENDED للإبلاغ عن ذلك من خلال AcousticEchoCanceler طريقة واجهة برمجة التطبيقات AcousticEchoCanceler.isavailable()
• [C-SR-2] تُستخدَم strongLY_RECOMMENDED للسماح بالتحكّم في هذا التأثير الصوتي باستخدام واجهة برمجة التطبيقات AcousticEchoCanceler.
• يتم ضبط [C-SR-3] على strongLY_RECOMMENDED لتحديد كل عملية تنفيذ لتقنية AEC بشكل فريد من خلال الحقل AudioEffect.Descriptor.uuid.

5.4.5. التقاط متزامن

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

• [C-1-1] يجب أن يسمح بالوصول المتزامن إلى الميكروفون عن طريق خدمة إمكانية الوصول الالتقاط باستخدام AudioSource.VOICE_RECOGNITION والتقاط تطبيق واحد على الأقل مع أي AudioSource.
• [C-1-2] يجب أن يسمح تطبيق مثبَّت مسبقًا بالوصول إلى الميكروفون بشكل متزامن مع دور "مساعد Google" وتطبيق واحد على الأقل يلتقط المحتوى باستخدام أي AudioSource باستثناء AudioSource.VOICE_COMMUNICATION أو AudioSource.CAMCORDER.
• [C-1-3] يجب أن يكتم صوت التقاط الصوت لأي تطبيق آخر، باستثناء خدمة مخصصة لتسهيل الاستخدام، بينما يلتقط أحد التطبيقات باستخدام AudioSource.VOICE_COMMUNICATION أو AudioSource.CAMCORDER. ومع ذلك، عند تسجيل تطبيق من خلال AudioSource.VOICE_COMMUNICATION، يمكن لتطبيق آخر تسجيل المكالمة الصوتية إذا كان تطبيقًا ذا امتياز (مثبَّت مسبقًا) وتم منحه الإذن CAPTURE_AUDIO_OUTPUT.
• [C-1-4] إذا كان هناك تطبيقان أو أكثر لالتقاط الصوت بشكل متزامن وإذا لم يكن أيٌّ من التطبيقَين يتضمّن واجهة مستخدم في الأعلى، فإن التطبيق الذي بدأ في التقاط الصوت الأخير يتلقى.

5.4.6. مستويات اكتساب الميكروفون [تم النقل إلى 5.4.2]

5.5. تشغيل الصوت

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

5.5.1. تشغيل الصوت الأولي

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

• [C-1-1] يجب أن يسمح بتشغيل المحتوى الصوتي الأولي الذي يتضمن الخصائص التالية:

  • تنسيقات المصدر: PCM الخطي، 16 بت، 8 بت، عائم
  • القنوات: إعدادات صالحة لقنوات متعدّدة تشمل أحاديًا واستيريو مع ما يصل إلى 8 قنوات
  • معدّلات أخذ العينات (بالهرتز):
    • 8000 و11025 و16000 و22050 و24000 و32000 و44100 و48,000 في إعدادات القناة المذكورة أعلاه
    • 96000 في وضع أحادي وستيريو

5.5.2 التأثيرات الصوتية

يوفر Android واجهة برمجة تطبيقات للتأثيرات الصوتية لعمليات تنفيذ الأجهزة.

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

• يجب أن يتوافق [C-1-1] مع تطبيقَي EFFECT_TYPE_EQUALIZER وEFFECT_TYPE_LOUDNESS_ENHANCER اللذين يمكن التحكّم فيهما من خلال الفئتَين الفرعيتَين AudioEffect (التأثيرات الصوتية) Equalizer وLoudnessEnhancer.
• [C-1-2] يجب أن يتيح تنفيذ واجهة برمجة تطبيقات العروض المرئية، ويمكن التحكّم فيها من خلال فئة Visualizer.
• [C-1-3] يجب أن يتيح تنفيذ EFFECT_TYPE_DYNAMICS_PROCESSING الذي يمكن التحكّم فيه من خلال الفئة الفرعية AudioEffect DynamicsProcessing.
• يجب أن تتوافق مع عمليات التنفيذ 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 API وحاوية الوسائط في MediaPlayer.

5.6. وقت استجابة الصوت

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

استخدِم التعريفات التالية لأغراض هذا القسم:

• وقت استجابة الناتج. الفاصل الزمني بين وقت كتابة أحد التطبيقات لإطار بيانات بترميز PCM ووقت عرض الصوت المناسب للبيئة في محوّل إشارات على الجهاز أو خروج الإشارة من الجهاز عبر منفذ ويمكن ملاحظته خارجيًا.
• وقت استجابة الإخراج البارد. المدة بين بدء بث الناتج ووقت العرض التقديمي للإطار الأول استنادًا إلى الطوابع الزمنية، عندما يكون نظام الإخراج الصوتي غير مستخدَم حاليًا ويتم إيقافه قبل تقديم الطلب.
• وقت استجابة الإخراج المستمر. وقت استجابة الإخراج للإطارات اللاحقة بعد تشغيل الجهاز للصوت
• وقت استجابة الإدخال: الفاصل الزمني بين وقت ظهور الصوت من خلال البيئة في الجهاز في محوّل الطاقة على الجهاز أو دخول الإشارة إلى الجهاز عبر المنفذ ووقت قراءة التطبيق للإطار المقابل من بيانات PCM المرمّزة.
• فقدان الإدخال. الجزء الأولي من إشارة إدخال غير قابلة للاستخدام أو غير متاحة.
• وقت استجابة الإدخال البارد. الوقت بين بدء البث ووقت تلقّي أول إطار صالح، عندما يكون نظام الإدخال الصوتي غير نشِط لفترة قصيرة قبل إرسال الطلب
• وقت استجابة الإدخال المستمر. وقت استجابة الإدخال للإطارات اللاحقة، بينما يلتقط الجهاز الصوت.
• وقت استجابة الذهاب والعودة المستمر. مجموع وقت استجابة الإدخال المستمر بالإضافة إلى وقت استجابة الإخراج المستمر بالإضافة إلى فترة مخزن مؤقت واحد. تتيح فترة المخزن المؤقت الوقت الذي يحتاجه التطبيق لمعالجة الإشارة والوقت اللازم للتطبيق للتخفيف من فرق المرح بين مصادر الإدخال والإخراج.
• واجهة برمجة تطبيقات قائمة انتظار المخزن المؤقت لـ OpenSL ES PCM. مجموعة واجهات برمجة التطبيقات OpenSL ES ذات الصلة بـ PCM ضمن Android NDK.
• واجهة برمجة التطبيقات للصوت الأصلي: مجموعة واجهات برمجة تطبيقات AAudio ضمن Android NDK.
• الطابع الزمني: يشير ذلك المصطلح إلى زوج يتكوّن من موضع نسبي للإطار ضمن بث مباشر والوقت المقدَّر للدخول إلى مسار معالجة الصوت أو مغادرته في نقطة النهاية المرتبطة. راجِع أيضًا AudioTimestamp.
• glitch يشير ذلك المصطلح إلى انقطاع مؤقت أو قيمة عيّنة غير صحيحة في الإشارة الصوتية، ويحدث ذلك عادةً بسبب تجاوز المخزن المؤقت للمخرجات أو تجاوز المخزن المؤقت للإدخال أو أي مصدر آخر للضوضاء الرقمية أو التناظرية.
• متوسط الانحراف المطلق. يشير ذلك المصطلح إلى متوسط القيمة المطلقة للانحرافات عن المتوسط لمجموعة من القيم.
• وقت استجابة النقر للنغمة. الفترة الزمنية بين النقر على الشاشة ووقت سماع نغمة نتيجة النقر على السماعة.

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

• [C-1-1] يتم عرض الطابع الزمني للمخرجات من خلال AudioTrack.getTimestamp وAAudioStream_getTimestamp بدقة تصل إلى +/- 2 ملي ثانية.

• [C-1-2] يصل وقت استجابة الناتج البارد إلى 500 مللي ثانية أو أقل.

• [C-1-3] يجب أن يستغرق فتح مصدر بيانات الناتج باستخدام AAudioStreamBuilder_openStream() أقل من 1,000 مللي ثانية.

إذا أشارت عمليات تنفيذ الأجهزة إلى أنّ android.hardware.audio.output موصى بها بشدة لاستيفاء المتطلبات التالية أو تجاوزها:

• [C-SR-1] يبلغ وقت استجابة الإخراج البارد 100 مللي ثانية أو أقل عبر مسار بيانات المتحدث.

• [C-SR-2] يبلغ وقت استجابة النقر للنغمة 80 مللي ثانية أو أقل.

• [C-SR-4] الطابع الزمني للمخرجات التي يتم عرضها بواسطة AudioTrack.getTimestamp وAAudioStream_getTimestamp بدقة تصل إلى +/- 1 ملي ثانية.

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

• [C-SR-5] يُنصح بشدة بالإبلاغ عن وقت الاستجابة البطيء للمحتوى الصوتي من خلال الإعلان عن علامة الميزة android.hardware.audio.low_latency.
• [C-SR-6] يُنصح بشدة بتلبية متطلبات وقت الاستجابة السريع للصوت عبر AAudio API.
• [C-SR-7] ننصح بشدة بالتأكّد من أنّ القيمة التي يعرضها AAudioStream_getFramesPerBurst() أقل من أو تساوي القيمة التي يعرضها android.media.AudioManager.getProperty(String) لمفتاح الموقع AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER لمصادر البيانات التي تعرض AAUDIO_PERFORMANCE_MODE_LOW_LATENCY من AAudioStream_getPerformanceMode().

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

• [C-2-1] يجب ألا يُبلِغ عن توفير الصوت في وقت الاستجابة المنخفض.

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

• [C-3-1] تحديد الخطأ في الطوابع الزمنية للإدخال، على النحو الذي يعرضه AudioRecord.getTimestamp أو AAudioStream_getTimestamp، إلى +/- 2 ملي ثانية. يشير "خطأ" هنا إلى الانحراف عن القيمة الصحيحة.

• [C-3-2] وقت استجابة الإدخال البارد يبلغ 500 مللي ثانية أو أقل.

• [C-3-3] يجب أن يستغرق فتح مصدر بيانات إدخال باستخدام AAudioStreamBuilder_openStream() أقل من 1,000 مللي ثانية.

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

• [C-SR-8] يبلغ وقت استجابة الإدخال البارد 100 مللي ثانية أو أقل عبر مسار بيانات الميكروفون.

• [C-SR-11] الحدّ من الخطأ في الطوابع الزمنية للإدخال، على النحو الذي يعرضه AudioRecord.getTimestamp أو AAudioStream_getTimestamp، إلى +/- 1 ملي ثانية

إذا كانت عمليات تنفيذ الأجهزة تشير إلى android.hardware.audio.output وandroid.hardware.microphone، سيتم تطبيق ما يلي:

• [C-SR-12] يُنصح بشدة أن يكون لها متوسط وقت استجابة مستمر للذهاب وعودة يبلغ 50 مللي ثانية أو أقل من 5 قياسات، مع متوسط انحراف مطلق أقل من 10 مللي ثانية، عبر مسار واحد متوافق على الأقل.

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. برامج ترميز الصوت: الترميز المتقدّم للصوت يمكنك مراجعة القسم 5.1.3 للحصول على تفاصيل حول الترميز المتقدّم للصوت والخيارات المضمّنة فيه.
الترميز المتقدّم للصوت مع إطارات ADTS وعلامات رقم التعريف 3 (ID3)	ISO 13818-7	يمكنك مراجعة القسم 5.1.1 للحصول على تفاصيل حول الترميز المتقدّم للصوت والصيغ المختلفة منه.
WebVTT	WebVTT

بروتوكول النقل في الوقت الفعلي (RTP)، أو بروتوكول البث المباشر على الإنترنت (SDP)

اسم الملف الشخصي	المَراجع	توفُّر برنامج ترميز مطلوب
H264 AVC	RFC 6184	راجِع الفقرة 5.1.8 للاطّلاع على تفاصيل حول H264 AVC.
MP4A-LATM	RFC 6416	يمكنك الاطّلاع على القسم 5.1.3 للحصول على تفاصيل حول الترميز المتقدّم للصوت والخيارات المضمّنة فيه.
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 عامة	RFC 3640	يمكنك الاطّلاع على القسم 5.1.3 للحصول على تفاصيل حول الترميز المتقدّم للصوت والخيارات المضمّنة فيه.
MP2T	RFC 2250	يُرجى الاطّلاع على MPEG-2 Transport Stream ضمن HTTP Live Streaming لمزيد من التفاصيل.

5.8. الوسائط الآمنة

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

• [C-1-1] يجب أن يعلن عن دعمه لـ Display.FLAG_SECURE.

إذا كانت عمليات تنفيذ الأجهزة تشير إلى توافقها مع Display.FLAG_SECURE ومتوافقة مع بروتوكول الشاشة اللاسلكية، سيتم إجراء ما يلي:

• [C-2-1] يجب تأمين الرابط باستخدام آلية تشفير قوية مثل HDCP 2.x أو أعلى للشاشات المتصلة عبر البروتوكولات اللاسلكية مثل Miracast.

إذا تبيّن عمليات تنفيذ الأجهزة أنّها متوافقة مع "Display.FLAG_SECURE" وتتوافق مع شاشة خارجية سلكية، سيتم إجراء ما يلي:

• [C-3-1] يجب أن يتوافق مع بروتوكول HDCP 1.2 أو الإصدارات الأحدث مع جميع الشاشات الخارجية المتصلة من خلال منفذ سلكي يمكن للمستخدم الوصول إليه.

5.9. الواجهة الرقمية للآلات الموسيقية (MIDI)

إذا أبلغت عمليات تنفيذ الأجهزة عن دعم الميزة android.software.midi من خلال فئة android.content.pm.PackageManager، سيتم إجراء ما يلي:

• [C-1-1] يجب أن يتوافق مع MIDI في جميع عمليات نقل الأجهزة التي تتضمّن MIDI والتي توفّر لها إمكانية اتصال عام غير MIDI، وذلك في الحالات التالية:

  • وضع مضيف USB، القسم 7.7
  • دور MIDI عبر Bluetooth LE في دور مركزي، القسم 7.4.3

• [C-1-2] يجب أن يتوافق مع نقل برامج MIDI بين التطبيقات (أجهزة MIDI الافتراضية)

• [C-1-3] يجب أن يتضمن libamedi.so (دعم MIDI الأصلي)

• "التوافق مع أجهزة MIDI" عبر وضع الجهاز الملحق بمنفذ USB، القسم 7.7

5.10. صوت احترافي

في حال إبلاغ عمليات تنفيذ الأجهزة عن توافق "android.hardware.audio.pro" من خلال الفئة android.content.pm.PackageManager، سيتم إجراء ما يلي:

• [C-1-1] يجب الإبلاغ عن دعم الميزة android.hardware.audio.low_latency.
• يجب أن يتوفّر وقت استجابة الصوت ذهابًا وإيابًا بشكل متواصل في [C-1-2]، كما هو موضّح في القسم وقت استجابة الصوت 5.6 بمعدّل 25 ملي ثانية أو أقل عبر مسار واحد متوافق على الأقل.
• [C-1-3] يجب أن يشتمل على منافذ USB تدعم وضع مضيف USB ووضع ملحق USB.
• [C-1-4] يجب الإبلاغ عن إتاحة الميزة android.software.midi.
• يجب أن يلبّي [C-1-5] وقت الاستجابة ومتطلبات صوت USB باستخدام واجهة برمجة التطبيقات AAudio asset audio وAAUDIO_PERFORMANCE_MODE_LOW_LATENCY.
• [C-1-6] يجب أن يبلغ وقت استجابة إخراج الصوت البارد 200 ملّي ثانية أو أقل.
• [C-1-7] يجب أن يبلغ وقت استجابة إدخال "البارد" 200 ملّي ثانية أو أقل.
• [C-1-8] يجب أن يبلغ متوسط وقت استجابة "النقر للنغمات" 80 مللي ثانية أو أقل على الأقل من 5 قياسات عبر مسار بيانات المتحدث على الميكروفون.
• [C-SR-1] يُنصح بشدة باستيفاء أوقات الاستجابة على النحو المحدّد في القسم 5.6 وقت استجابة الصوت البالغ 20 مللي ثانية أو أقل وأكثر من 5 قياسات مع متوسط انحراف مطلق أقل من 5 مللي ثانية عبر مسار المتحدث إلى الميكروفون.
• [C-SR-2] يُنصَح باستخدامها بشدة لاستيفاء متطلبات Pro Audio لضمان وقت استجابة الصوت ذهابًا وإيابًا بشكل مستمر، ووقت الاستجابة للإدخال على البارد ومتطلبات إخراج الصوت على البارد ومتطلبات وقت الاستجابة وصوت USB باستخدام واجهة برمجة تطبيقات AAudio original audio عبر مسار MMAP.

• [C-SR-3] يُوصى بها بشدة لتوفير مستوى ثابت من أداء وحدة المعالجة المركزية عندما يكون الصوت نشطًا ويختلف حِمل وحدة المعالجة المركزية (CPU). ومن المفترض أن يتم اختبار ذلك باستخدام تطبيق Android SynthMark. يستخدم SynthMark أداة توليف برامج تعمل على إطار عمل صوتي محاكى يقيس أداء النظام. اطّلِع على مستندات SynthMark للحصول على شرح لمقاييس الأداء. يجب تشغيل تطبيق SynthMark باستخدام خيار "الاختبار التلقائي" وتحقيق النتائج التالية:

  • Voicemark.90 >= 32 صوتًا
  • timemark.fixed.little <= 15 مللي ثانية
  • timemark.dynamic.little <= 50 ميللي ثانية

• يجب تقليل دقة ساعة الصوت وانحرافها بالنسبة إلى الوقت القياسي.

• يجب تقليل تغيُّر ساعة الصوت إلى أدنى حد ممكن مقارنةً بوحدة المعالجة المركزية (CPU) CLOCK_MONOTONIC عندما يكون كلاهما نشطًا.

• يجب تقليل وقت استجابة الصوت عبر محوّلات الطاقة على الجهاز.

• "يجب" تقليل وقت استجابة الصوت عبر صوت USB الرقمي.

• "يجب" توفير قياسات وقت استجابة الصوت في جميع المسارات.

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

• يجب ألا تحدث أخطاء في الصوت عند الاستخدام العادي في وقت الاستجابة الذي تم الإبلاغ عنه.

• يجب ألا يكون هناك أي فارق في وقت الاستجابة بين القنوات.

• يجب تقليل وقت استجابة MIDI في جميع عمليات النقل.

• يجب تقليل تغيُّر وقت استجابة MIDI أثناء التحميل (عدم الاستقرار) في جميع عمليات النقل.

• يجب أن يتم توفير طوابع زمنية دقيقة لـ MIDI في جميع عمليات النقل.

• يجب تقليل ضوضاء الإشارة الصوتية عبر المحوّلات على الجهاز، بما في ذلك الفترة التي تلي التشغيل على البارد مباشرةً.

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

• "ينبغي" التعامل مع استدعاءات إكمال المخزن المؤقت للصوت جانبَي الإدخال والإخراج لنقاط النهاية المقابلة في سلسلة المحادثات نفسها عندما يكون كلاهما نشطًا، وإدخال استدعاء الإخراج فورًا بعد العودة من استدعاء الإدخال. أو إذا لم يكن من الممكن معالجة عمليات الاستدعاء في سلسلة المحادثات نفسها، أدخِل معاودة الاتصال للإخراج بعد وقت قصير من إدخال استدعاء الإدخال للسماح للتطبيق في الوقت نفسه بين جانبي الإدخال والإخراج.

• "ينبغي" تقليل فرق الطور بين التخزين المؤقت للصوت HAL وجانبَي الإدخال والإخراج لنقاط النهاية المقابلة.

• يجب تقليل وقت استجابة اللمس.

• يجب تقليل تغيُّر وقت استجابة اللمس عند التحميل (عدم الاستقرار).

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

• [C-SR-4] يُنصَح بشدة بالإبلاغ عن إتاحة الميزة android.hardware.audio.pro من خلال الفئة android.content.pm.PackageManager.

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

• يجب أن يكون لـ [C-2-1] متوسط وقت الاستجابة المستمر للصوت ذهابًا وإيابًا، كما هو محدّد في القسم 5.6 وقت الاستجابة الصوتي، والذي يبلغ 20 ملي ثانية أو أقل، وأكثر من 5 قياسات ذات متوسط انحراف مطلق أقل من 5 ملي ثانية عبر مسار مقبس الصوت باستخدام مفتاح إلكتروني بديل للاسترجاع الصوتي.
• [C-SR-5] يُنصح بشدة بالامتثال للفقرة مواصفات الأجهزة الجوّالة (المقبس) في مواصفات سماعات الرأس السلكية (الإصدار 1.1).

إذا لم تتضمن عمليات تنفيذ الجهاز مقبس صوت مقاس 4 موصّلات مقاس 3.5 ملم وتضمين منافذ USB تتوافق مع وضع مضيف USB، ينطبق ما يلي:

• [C-3-1] يجب تنفيذ فئة الصوت على USB.
• [C-3-2] يجب أن يكون لها متوسط وقت استجابة الصوت المستمر ذهابًا وإيابًا خلال 25 مللي ثانية أو أقل، وأكثر من 5 قياسات مع متوسط الانحراف المطلق أقل من 5 مللي ثانية عبر منفذ وضع مضيف USB باستخدام فئة صوت USB. (يمكن قياس ذلك باستخدام محوّل مزوّد بمنفذ USB-3.5 ملم ومفتاح إلكتروني لتكرار الصوت أو باستخدام واجهة USB الصوتية مع كابلات توصيل الإدخالات بالمخرجات).
• [C-SR-6] يُنصَح باستخدامها بشدة لإتاحة عمليات الإدخال/الإخراج المتزامنة بما يصل إلى 8 قنوات في كل اتجاه ومعدل عينة بتردد 96 كيلوهرتز وعمق 24 بت أو 32 بت عند استخدامها مع أجهزة USB الصوتية الملحقة التي تستوفي هذه المتطلبات أيضًا.
• [C-SR-7] يُنصَح باستخدامها بشكل كبير لاستيفاء هذه المجموعة من المتطلبات باستخدام AAudio asset Audio API على مسار MMAP.

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

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

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 ديسيبل لديك استجابة بدرجة حاصلة على 520 ديسيبل للعينات العائمة (أو -36 ديسيبل) لكل عينة عائمة/عينة لم يتم معالجتها وفقًا للمقياس الكامل لكل مصدر عائم أو مزدوج.

• يجب أن تبلغ نسبة الإشارة إلى الضوضاء [C-1-6] (SNR) 60 ديسيبل أو أعلى لكل ميكروفون يُستخدَم لتسجيل مصدر الصوت الذي لم تتم معالجته. (في حين يُقاس SNR كفرق بين مستوى SPL الذي يبلغ 94 ديسيبل وما يعادلها من صوت SPL للضوضاء الذاتية، بمقياس A).

• يجب أن يكون مستوى التشوّه التوافقي الكلي (THD) في [C-1-7] أقل من 1% لمستوى إدخال يبلغ 1 كيلوهرتز عند مستوى إدخال SPL 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. فيديو HDR

يتوافق Android 13 مع تقنيات النطاق العالي الديناميكية كما هو موضّح في المستند القادم.

تنسيق Pixel

إذا كان برنامج فك ترميز الفيديو يعلن عن توفّر Color_FormatYUVP010، يجب عندها:

• [C-1-1] يجب أن يتوافق مع التنسيق P010 لقراءة وحدة المعالجة المركزية (ImageReader، MediaImage، ByteBuffer). في نظام التشغيل Android 13، تم التخفيف من حدة P010 لإتاحة خطوة عشوائية للمستوى Y والأشعة فوق البنفسجية.

• [C-1-2] يجب أن يتمكن المخزن المؤقت للمخرجات P010 من أخذ عيّنات من وحدة معالجة الرسومات (عند تخصيصه باستخدام وحدة معالجة الرسومات GPU_SAMPLING). ويتيح ذلك إمكانية تكوين وحدة معالجة الرسومات وتعيين الدرجات اللونية المخصصة بواسطة التطبيقات.

إذا كان برنامج فك ترميز الفيديو يعلن عن توافق Color_Format32bitABGR2101010، ينطبق ما يلي:

• [C-2-1] يجب أن يتوافق مع تنسيق RGBA_1010102 لسطح الإخراج وقابل للقراءة بواسطة وحدة المعالجة المركزية (CPU) (إخراج ByteBuffer).

إذا أعلن برنامج ترميز فيديو عن توافقه مع Color_FormatYUVP010، يجب إجراء ما يلي:

• [C-3-1] يجب أن يتوافق مع التنسيق P010 لسطح الإدخال والإدخال القابل للكتابة على وحدة المعالجة المركزية (ImageWriter وMediaImage وByteBuffer).

ملاحظة: في نظام التشغيل Android 13، تم التخفيف من استخدام P010 للسماح بخطوات عشوائية على مستوى Y وUV. (قد يتم تحسين تنسيق P010 هذا ويكون مختلفًا عن تنسيق Camera2 P010.)

إذا أعلن برنامج ترميز فيديو عن توافقه مع Color_Format32bitABGR2101010، ينطبق ما يلي:

• [C-4-1] يجب أن يتوافق مع تنسيق RGBA_1010102 لسطح الإدخال والإدخال القابل للكتابة على وحدة المعالجة المركزية (CPU) (ImageWriter، ByteBuffer). ملاحظة: لا يلزم استخدام التحويل بين منحنيات النقل المختلفة في برامج الترميز.

متطلبات الالتقاط بتقنية HDR

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

• [C-5-1] يجب ألا يفترض أن البيانات الوصفية ذات تنسيق HDR دقيقة. على سبيل المثال، قد يحتوي الإطار المُرمّز على وحدات بكسل تتجاوز أعلى مستوى للإضاءة، أو قد لا يمثل المدرج التكراري الإطار.

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

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

• [C-6-1] يجب أن يتيح التقاط الصور باستخدام تقنية HDR من خلال واجهات برمجة تطبيقات Camera2.

• [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] يجب أن يتوافق مع تعيين نغمة النطاق العالي الديناميكية (HDR) إلى النطاق العادي الديناميكية (SDR) في برنامج فك الترميز التلقائي الذي يتم تسريعه باستخدام الأجهزة للملف الشخصي الذي تم التقاطه. بمعنى آخر، إذا كان بإمكان الجهاز التقاط ترميز HDR10+ HEVC، يجب أن يكون بإمكان برنامج فك ترميز HEVC التلقائي فك ترميز البث الذي تم التقاطه بتنسيق SDR.

متطلبات تعديل النطاق العالي الديناميكية (HDR)

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

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

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

• [C-7-1] يجب أن يتوافق مع ملف شخصي واحد على الأقل بتقنية HDR.

• [C-7-2] يجب أن تتيح ميزة FEATURE_HdrEditing لكل الملفات الشخصية للنطاق العالي الديناميكية المعلَن عنها من خلال برنامج الترميز هذا. بمعنى آخر، يجب أن تتيح هذه البرامج إنشاء بيانات وصفية بتنسيق HDR عندما لا تكون متوفرة في جميع الملفات الشخصية ذات النطاق العالي الديناميكية (HDR) المتوافقة والتي تستخدم بيانات وصفية بتنسيق HDR.

• [C-7-3] يجب أن يتوافق مع تنسيقات الإدخال التالية في برامج ترميز الفيديو التي تحافظ بالكامل على إشارة HDR المفكوك ترميزها:

  • إنّ النموذج RGBA_1010102 (المتوفّر حاليًا في منحنى النقل المستهدَف) لكلّ من سطح الإدخال وByteBuffer ويجب أن يعلن عن توافقه مع Color_Format32bitABGR2101010.

إذا كان تنفيذ الجهاز يتضمن برامج ترميز تتوافق مع FEATURE_HdrEditing، الجهاز:

• [C-7-4] يجب الإعلان عن دعم إضافة OpenGL EXT_YUV_target.

6. التوافق بين أدوات المطوّرين وخياراتهم

6.1. أدوات المطوّرين

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

• [C-0-1] يجب أن يتوافق مع أدوات مطوّري برامج Android المتوفرة في حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

• Android Debug Bridge (adb)

  • يجب أن يتوافق [C-0-2] مع أداة adb كما هو موثَّق في حزمة تطوير البرامج (SDK) لنظام التشغيل Android وأوامر Shell المتوفّرة في AOSP والتي يمكن لمطوّري التطبيقات استخدامها، بما في ذلك dumpsys cmd stats
  • [C-0-11] يجب أن يتوافق مع أمر الغلاف cmd testharness. قد تُعفى عملية ترقية عمليات تنفيذ الأجهزة من إصدار Android سابق بدون حظر بيانات مستمر من الإصدار C-0-11.
  • [C-0-3] يجب ألا يتم تغيير تنسيق أحداث نظام الجهاز أو محتوياتها (بطارية أو قرص تخزين بيانات أو بصمة إصبع أو رسومات إحصاءات أو netstats أو إشعارات أو برامج Procstats) التي يتم تسجيلها من خلال الأمر dumpsys.
  • يجب أن يسجّل [C-0-10] الأحداث التالية بدون حذف، وأن يتيح الوصول إلى الأحداث التالية وإتاحتها لأمر Shell cmd stats وفئة StatsManager System API.
    • تم تغيير حالة ActivityForegroundState.
    • تم رصد قيمة شاذة
    • تم الإبلاغ عن مسار تنقل التطبيق
    • حدث AppCrashOccurred
    • حدث AppStartOccurred
    • تم تغيير مستوى البطارية
    • البطاريةSaverModeStateChanged
    • تم تلقّي نتيجة BleScanResult
    • BleScanStateChanged
    • تم تغيير حالة الشحن
    • DeviceIdleModeStateChanged
    • .ForegroundServiceStateChanged
    • GpsScanStateChanged
    • تم تغيير JobState
    • plgedStateChanged
    • scheduleJobStateChanged
    • تم تغيير حالة الشاشة
    • SyncStateChanged
    • SystemEboundedRealtime (الوقت الفعلي للنظام)
    • UidProcessStateChanged
    • تم تغيير حالة WakelockState
    • حدث منبّه الصباح
    • تم تغيير حالة WifiLockState
    • تم تغيير حالة WifiMulticastLock
    • تم تغيير حالة Wi-FiScanState
  • يجب أن يكون البرنامج الخفي لـ Adb من جهة الجهاز غير نشط تلقائيًا في [C-0-4] ويجب أن تتوفّر آلية يمكن للمستخدمين الوصول إليها لتفعيل Android DebugBridge.
  • [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 أو إيثرنت، وتتضمّن كاميرا واحدة على الأقل، سيتم إجراء ما يلي:

  • [C-5-1] يجب أن تتضمن طريقة AdbManager#isAdbWifiQrSupported() إرجاع true.

• خدمة Dalvik Debug Monitor (ddms)

  • يجب أن يتوافق [C-0-7] مع جميع ميزات نظام إدارة البيانات (ddms) كما هو موثّق في حزمة تطوير البرامج (SDK) لنظام التشغيل Android. بما أنّ نظام dms يستخدِم أداة adb، يُفترَض أن يكون التوافق مع نظام ddms غير نشط تلقائيًا، ولكن يجب أن يكون متوافقًا عندما يفعِّل المستخدم جسر Android Debug Bridge، على النحو الوارد أعلاه.

• تتبُّع النظام (SysTrace)

  • [C-0-9] يجب أن يتوافق مع أداة تتبُّع النظم كما هو موثّق في حزمة تطوير البرامج (SDK) لنظام التشغيل Android. يجب أن يكون Systrace غير نشط بشكل افتراضي ويجب أن تكون هناك آلية يمكن للمستخدم الوصول إليها لتفعيل Systrace.

• Perfetto

  • [C-SR-1] يُنصح بشدة بعرض برنامج ثنائي /system/bin/perfetto لمستخدم واجهة المستخدم الذي يتوافق مع cmdline مع مستندات Perfetto.
  • [C-SR-2] يُنصح بشدة بقبول البرنامج الثنائي Perfetto كإدخال إعداد نموذج أوّلي يتوافق مع المخطط المحدّد في مستندات الأداء.
  • [C-SR-3] يُنصَح بشدة باستخدام برنامج Perfetto الثنائي كمخرج لعملية تتبُّع أولية يتوافق مع المخطّط المحدّد في مستندات الأداء.
  • [C-SR-4] يُنصَح بشدة بتقديمها من خلال برنامج Perfetto الثنائي على الأقل مع مصادر البيانات الموضّحة في مستندات Perfetto

• قاتل الذاكرة المنخفضة

  • [C-0-12] يجب كتابة LMK_KILL_OCCURRED_FIELD_NUMBER Atom في سجلّ الإحصائيات عند إنهاء أحد التطبيقات بسبب انخفاض الذاكرة الخالية.

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

  • [C-2-1] يجب عرض true للطلب ActivityManager.isRunningInUserTestHarness()
  • [C-2-2] يجب تنفيذ "وضع مفعِّل الاختبار" كما هو موضّح في مستندات "وضع حزام الاختبار".

• معلومات عمل وحدة معالجة الرسومات

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

  • [C-0-13] يجب تنفيذ أمر واجهة الأوامر dumpsys gpu --gpuwork لعرض بيانات عمل وحدة معالجة الرسومات المجمّعة التي تعرضها نقطة تتبُّع النواة power/gpu_work_period، أو عرض أي بيانات إذا كانت نقطة التتبع غير متاحة. إنّ عملية تنفيذ AOSP هي frameworks/native/services/gpuservice/gpuwork/

إذا أشارت عمليات تنفيذ الأجهزة إلى أنّها تتوافق مع Vulkan 1.0 أو الإصدارات الأحدث من خلال علامات الميزات في android.hardware.vulkan.version، سيتم إجراء ما يلي:

• [C-1-1] يجب أن يوفر وظيفة لمطوّر التطبيق لتفعيل/إيقاف طبقات تصحيح أخطاء وحدة معالجة الرسومات.
• [C-1-2] عند تفعيل طبقات تصحيح أخطاء وحدة معالجة الرسومات، يجب تعداد الطبقات في المكتبات التي توفِّرها الأدوات الخارجية (أي ليست جزءًا من النظام الأساسي أو حزمة التطبيق) المتوفّرة في الدليل الأساسي للتطبيقات التي يمكن تصحيح الأخطاء بها لإتاحة استخدام vkEnumerateInstanceLayerProperties() وvkCreateInstance() في طرق واجهة برمجة التطبيقات.

6.2. خيارات المطوّرين

يتيح Android للمطورين تهيئة الإعدادات المتعلقة بتطوير التطبيقات.

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

• يجب أن يلتزم [C-0-1] برغبة android.settings.APPLICATION_DEVELOPMENT_SETTINGS لعرض الإعدادات المتعلقة بتطوير التطبيقات. تُخفي عملية التنفيذ التي يتم تنفيذها في Android قائمة "خيارات المطوّرين" تلقائيًا وتمكِّن المستخدمين من تشغيل "خيارات المطوّرين" بعد الضغط على سبع (7) مرات في الإعدادات > لمحة عن الجهاز > عنصر القائمة رقم الإصدار.
• [C-0-2] يجب أن تخفي خيارات المطوّرين تلقائيًا.
• يجب أن يوفّر [C-0-3] آلية واضحة لا تقدّم معاملة تفضيلية لتطبيق تابع لجهة خارجية بدلاً من تطبيق آخر لتفعيل "خيارات المطوّرين". يجب أن توفّر مستندًا أو موقعًا إلكترونيًا مرئيًا للجميع يوضّح كيفية تفعيل "خيارات المطوّرين". يجب أن يكون هذا المستند أو الموقع الإلكتروني قابلاً للربط من مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
• "يجب أن يكون هناك إشعار مرئي مستمر للمستخدم" عند تفعيل "خيارات المطوّرين" ويكون سلامة المستخدم موضع قلق
• وقد نحدّ مؤقتًا من الوصول إلى قائمة "خيارات المطوّرين" من خلال إخفاء القائمة أو إيقافها بشكل مرئي لتجنُّب تشتيت الانتباه في الحالات التي تكون فيها أمان المستخدم قلقة.

7. توافُق الأجهزة

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

• [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، يجب تنفيذ واجهات برمجة التطبيقات والسلوكيات هذه بشكل صحيح في عمليات تنفيذ الأجهزة، كما هو موضَّح في هذا القسم.

يتم تعريف الوحدات المُشار إليها من خلال المتطلّبات في هذا القسم على النحو التالي:

• الحجم القطري الفعلي. المسافة بالبوصة بين زاويتين متقابلتين للجزء المضيء من الشاشة.
• نقاط لكل بوصة (dpi). عدد وحدات البكسل التي يضمها مدى خطي أفقيًا أو رأسي يبلغ 1". عند إدراج قيم النقاط لكل بوصة، يجب أن تكون القيم الأفقية والعمودية لكل بوصة ضمن النطاق.
• نسبة العرض إلى الارتفاع نسبة وحدات البكسل للبعد الأطول إلى البعد الأقصر للشاشة. على سبيل المثال، ستكون الشاشة المعروضة بمقاس 480×854 بكسل 854/480 = 1.779 أو 16:9 تقريبًا.
• وحدة بكسل مستقلة الكثافة (dp) وحدة البكسل الافتراضية تمت تسويتها إلى شاشة تبلغ 160 نقطة لكل بوصة، ويتم احتسابها على النحو التالي: بكسل = dps * (الكثافة/160).

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 dp x 320 dp.
  • يجب أن تتضمّن الأجهزة التي يبلغ حجمها normal لكل Configuration.screenLayout 480 بكسل مستقل الكثافة × 320 بكسل مستقل الكثافة على الأقل
  • يجب أن تتضمّن الأجهزة التي يبلغ حجمها large لكل Configuration.screenLayout 640 بكسل مستقل الكثافة × 480 بكسل مستقل الكثافة على الأقل
  • يجب أن تتضمّن الأجهزة التي يبلغ حجمها xlarge لـ Configuration.screenLayout دقة لا تقل عن 960 بكسل مستقل الكثافة × 720 بكسل مستقل الكثافة (dp).

• يجب أن يتوافق [C-0-2] مع دعم التطبيقات المذكور بشكل صحيح لأحجام الشاشات من خلال السمة <supports-screens> في ملف AndroidManifest.xml، كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

• قد يحتوي على الشاشات المتوافقة مع Android ذات الزوايا المستديرة.

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

• [C-1-1] يجب أن يضمن استيفاء أحد المتطلبات التالية على الأقل:

  • نصف قطر الزوايا المستديرة أقل من أو يساوي 38 وحدة بكسل مستقلة الكثافة.
  • عند تثبيت مربّع بحجم 15 بكسل مستقل الكثافة × 15 بكسل مستقل الكثافة في كل زاوية من زوايا الشاشة المنطقية، يظهر على الشاشة وحدة بكسل واحدة على الأقل من كل مربّع.

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

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

• [C-2-1] يجب أن يستخدم أحدث إصدار ثابت متاح من extensions API أو الإصدار الثابت من sidecar API لاستخدامه في مكتبة Window Manager Jetpack.

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

• [C-3-1] يجب أن يبلغ التطبيق عن موضع المفصل أو الجزء غير المرئي أو حدوده أو حالته من خلال الإضافات أو واجهات برمجة تطبيقات الصورة الجانبية.

لمعرفة تفاصيل عن التنفيذ الصحيح لواجهات برمجة التطبيقات للإضافة أو الإضافة، يُرجى الاطّلاع على المستندات العامة الخاصة بـ Window Manager Jetpack.

7.1.1.2. نسبة عرض إلى ارتفاع الشاشة

على الرغم من عدم فرض قيود على نسبة العرض إلى الارتفاع للشاشة الفعلية على الشاشات المتوافقة مع Android، يجب أن تستوفي نسبة العرض إلى الارتفاع للعرض المنطقي حيث يتم عرض التطبيقات التابعة لجهات خارجية، والتي يمكن اشتقاقها من قيم الارتفاع والعرض التي تم الإبلاغ عنها من خلال واجهات برمجة التطبيقات والإعدادات في view.Display، أن تستوفي نسبة العرض إلى الارتفاع المتطلبات التالية:

• [C-0-1] عمليات تنفيذ الأجهزة التي تم ضبط Configuration.uiMode فيها على UI_MODE_TYPE_NORMAL يجب أن تكون قيمة نسبة العرض إلى الارتفاع فيها أقل من أو تساوي 1.86 (تقريبًا 16:9)، إلا في حال استيفاء التطبيق لأحد الشروط التالية:

  • أعلن التطبيق أنّه يتيح زيادة نسبة العرض إلى الارتفاع للشاشة من خلال قيمة البيانات الوصفية android.max_aspect.
  • يشير التطبيق إلى أنّه يمكن تغيير حجمه من خلال السمة android:resizeableActivity.
  • يستهدف التطبيق المستوى 24 من واجهة برمجة التطبيقات أو المستويات الأعلى، ولا يشير إلى سمة android:maxAspectRatio تحدّ من نسبة العرض إلى الارتفاع المسموح بها.

• [C-0-3] عمليات تنفيذ الأجهزة التي تم ضبط Configuration.uiMode فيها على UI_MODE_TYPE_WATCH يجب ضبط قيمة نسبة العرض إلى الارتفاع فيها على 1.0 (1:1).

7.1.1.3. كثافة الشاشة

يحدِّد إطار عمل واجهة المستخدم على نظام التشغيل Android مجموعة من الكثافات المنطقية العادية لمساعدة مطوّري التطبيقات على استهداف موارد التطبيقات.

• [C-0-1] وفقًا للإعدادات التلقائية، يجب أن تُبلغ عمليات تنفيذ الأجهزة عن كثافات إطار عمل Android واحدة فقط المذكورة في DisplayMetrics من خلال DENSITY_DEVICE_STABLE واجهة برمجة التطبيقات ويجب ألا تتغير هذه القيمة في أي وقت. ومع ذلك، قد يُبلغ الجهاز عن كثافة عشوائية مختلفة وفقًا للتغييرات التي أجراها المستخدم على إعدادات الشاشة التي تم ضبطها بعد التشغيل المبدئي.

• يجب أن تحدِّد عمليات تنفيذ الأجهزة كثافة إطار عمل Android العادية الأقرب رقميًا إلى الكثافة الفعلية للشاشة، ما لم تكن الكثافة المنطقية تزيد حجم الشاشة المبلّغ عنه إلى أقل من الحد الأدنى المتوافق. إذا كانت الكثافة العادية لإطار عمل Android الأقرب رقميًا من الكثافة الفعلية تؤدي إلى حجم شاشة أصغر من أصغر حجم شاشة متوافق متوافق (320 بكسل مستقل الكثافة)، يجب أن تسجّل عمليات تنفيذ الأجهزة ثاني أقل كثافة عادية لإطار عمل Android.

إذا كانت هناك إمكانية لتغيير حجم عرض الجهاز:

• [C-1-1] يجب ألا يزيد حجم العرض عن 1.5 مرة من الكثافة الأصلية، أو إنشاء حد أدنى فعّال لبُعد الشاشة يقل عن 320 بكسل مستقل الكثافة (أي ما يعادل مؤهِّل الموارد sw320dp)، أيهما أقرب.
• [C-1-2] يجب ألا يتم تصغير حجم العرض عن الكثافة الأصلية بمقدار 0.85 مرة.
• لضمان سهولة الاستخدام وأحجام الخطوط المتسقة، ننصح بتوفير التحجيم التالي لخيارات "الإعلانات المدمجة مع المحتوى" (مع الالتزام بالحدود الموضَّحة أعلاه)
  • صغيرة: 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 API للعنصر التلقائي الذي تمت محاكاته 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] يجب أن يتوافق مع الاتجاه الديناميكي للتطبيقات إما في الاتجاه العمودي أو الأفقي للشاشة. وهذا يعني أنّ الجهاز يجب أن يلتزم بطلب التطبيق بخصوص اتجاه معيّن للشاشة.
• [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 كما هو موضّح ومفصَّل في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
• [C-SR-1] يُوصى بها بشدة لإتاحة استخدام OpenGL ES 3.1.
• يجب أن تتوافق مع OpenGL ES 3.2.

يتم تقسيم اختبارات OpenGL ES dEQP إلى عدد من قوائم الاختبار، لكل منها تاريخ/إصدار مرتبط بها. وتتوفّر هذه البيانات في شجرة مصادر Android على external/deqp/android/cts/main/glesXX-main-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] يجب أن يبلغ الحد الأقصى لإصدار اختبارات OpenGL ES dEQP المتوافقة من خلال علامة ميزة android.software.opengles.deqp.level.
• [C-2-4] يجب أن يتوافق على الأقل مع الإصدار 132383489 (اعتبارًا من 1 آذار (مارس) 2020) كما هو موضّح في علامة الميزة android.software.opengles.deqp.level.
• يجب أن يجتاز [C-2-5] جميع اختبارات OpenGL ES dEQP في قوائم الاختبار بين الإصدار 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 بالكامل.

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع حزمة إضافات 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.

يتم تقسيم اختبارات Vulkan dEQP إلى عدد من قوائم الاختبار، لكل منها تاريخ أو إصدار مرتبط بها. وتتوفّر هذه البيانات في شجرة مصادر Android على external/deqp/android/cts/main/vk-main-YYYY-MM-DD.txt. ويشير الجهاز الذي يتوافق مع Vulkan على المستوى الذي يتم الإبلاغ عنه ذاتيًا إلى أنّه بإمكانه اجتياز اختبارات dEQP في جميع قوائم الاختبارات من هذا المستوى والمستويات الأقدم.

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

• [C-1-1] يجب أن تُبلغ عن قيمة العدد الصحيح الصحيحة باستخدام علامتَي الميزة android.hardware.vulkan.level وandroid.hardware.vulkan.version.
• [C-1-2] يجب تعداد VkPhysicalDevice واحد على الأقل لواجهة Vulkan Native API vkEnumeratePhysicalDevices() .
• يجب أن تنفيذ [C-1-3] واجهات برمجة تطبيقات Vulkan 1.0 بشكل كامل لكل VkPhysicalDevice معد.
• [C-1-4] يجب تعداد الطبقات، المضمّنة في المكتبات الأصلية المسماة libVkLayer*.so في دليل المكتبة الأصلية لحزمة التطبيق، من خلال واجهات برمجة تطبيقات Vulkan الأصلية vkEnumerateInstanceLayerProperties() وvkEnumerateDeviceLayerProperties().
• [C-1-5] يجب عدم تعداد الطبقات التي توفّرها المكتبات خارج حزمة التطبيق، أو توفير طرق أخرى لتتبُّع أو اعتراض واجهة برمجة تطبيقات Vulkan، ما لم يتم ضبط السمة android:debuggable على أنّها true.
• [C-1-6] يجب الإبلاغ عن جميع سلاسل الإضافات التي تتوافق معها عبر واجهات برمجة تطبيقات Vulkan الأصلية، وفي المقابل يجب ألا تبلغ عن سلاسل الإضافات التي لا تتوافق معها بشكل صحيح.
• [C-1-7] يجب أن يتوافق مع الإضافات VK_KHR_surface وVK_KHR_android_surface وVK_KHR_swapchain وVK_KHR_incremental_present.
• [C-1-8] يجب أن يبلغ الحد الأقصى لإصدار اختبارات dEQP من Vulkan المتوافقة من خلال علامة الميزة android.software.vulkan.deqp.level.
• [C-1-9] يجب أن يتوافق على الأقل مع الإصدار 132317953 (اعتبارًا من 1 آذار (مارس) 2019) كما هو موضّح في علامة الميزة android.software.vulkan.deqp.level.
• [C-1-10] يجب أن يجتاز جميع اختبارات Vulkan dEQP في قوائم الاختبار بين الإصدار 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_KHR_driver_properties وVK_GOOGLE_display_timing
• يجب أن تكون متوافقة مع VkPhysicalDeviceProtectedMemoryFeatures وVK_EXT_global_priority.
• [C-1-12] يجب ألا تعداد التوافق مع الإضافة VK_KHR_performance_query.
• [C-SR-4] يُنصَح باستخدامها بشدة لاستيفاء المتطلبات المحدّدة في ملف Android Baseline 2021 الشخصي.

إذا لم تكن عمليات تنفيذ الأجهزة متوافقة مع 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.

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 API، كما يجب أن يتّبع سلوكًا متّسقًا في عملية تنفيذ 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 والمتوافقة مع نظام التشغيل 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 لعمليات تنفيذ أجهزة التلفزيون. يجب أن تكون الدالة Home الآلية لهذه الوظيفة التي يمكن لهذا المستخدم الوصول إليها.
• يجب توفير أزرار لوظيفة "الأخيرة" و"الرجوع".

إذا تم توفير وظيفتَي "الصفحة الرئيسية" و"الأخيرة" و"رجوع"، سيتم ما يلي:

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

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

• يُنصَح بشدة بعدم توفير آلية الإدخال لوظيفة القائمة [C-SR-1] لأنّه تم إيقافها نهائيًا لصالح شريط الإجراءات بدءًا من نظام التشغيل Android 4.0.

• [C-SR-2] يُنصح بشدة بتوفير جميع وظائف التنقل كعناصر قابلة للإلغاء. تشير كلمة "ملغاة" إلى قدرة المستخدم على منع تنفيذ وظيفة التنقّل (مثل العودة إلى الصفحة الرئيسية أو الرجوع إلى الصفحة السابقة أو ما إلى ذلك) في حال عدم تجاوز الحدّ الأدنى المطلوب لوظيفة التمرير السريع.

إذا كانت عمليات تنفيذ الجهاز توفر وظيفة القائمة، فإنها:

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

إذا لم توفّر عمليات تنفيذ الجهاز وظيفة "القائمة"، لتحقيق التوافق مع الأنظمة القديمة، يجب أن يتيح [C-3-1] استخدام وظيفة "القائمة" للتطبيقات عندما تكون قيمة "targetSdkVersion" أقل من 10، إما عن طريق زر فعلي أو مفتاح برنامج أو الإيماءات. يجب أن تكون وظيفة القائمة هذه متاحة ما لم تكن مخفية مع وظائف التنقل الأخرى.

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

• [C-4-1] يجب إتاحة وظيفة المساعدة من خلال إجراء واحد (مثل النقر أو النقر مرّتين أو الإيماءة) عندما تكون مفاتيح التنقل الأخرى متاحة.
• [C-SR-3] يُنصح بشدة باستخدام الضغط مع الاستمرار على وظيفة الصفحة الرئيسية كهذا التفاعل المحدد.

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

• [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] إذا تم توفير لوحات نظام مخصصة قابلة للتمرير السريع على الحواف اليسرى أو اليمنى، يجب وضعها في الجزء العلوي 1/3 من الشاشة مع إشارة مرئية واضحة ومستمرة إلى أن السحب سيؤدي إلى استدعاء اللوحات المذكورة أعلاه، وبالتالي ليس "رجوع". قد تتم تهيئة لوحة نظام من قِبل المستخدم بحيث تصبح أسفل الجزء العلوي أو الثالث من حواف الشاشة، ولكن يجب ألا تستخدم لوحة النظام أطول من ثلث حافة الشاشة.
• [C-7-3] عندما يحتوي التطبيق الذي تعمل في المقدّمة على العلامة View.SYSTEM_UI_FLAG_IMMERSIVE أو View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY أو WindowInsetsController.BEHAVIOR_DEFAULT أو WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_WIP_documenting في التطبيق على النحو التالي: View.SYSTEM_UI_FLAG_IMMERSIVE أو View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT أو WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_WIP_documenting (SYSTEM_UI_FLAG_IMMERSIVE_STICKY) في التطبيقات التي تعمل في المقدّمة
• [C-7-4] عندما يكون لدى التطبيق الذي يعمل في المقدّمة إما View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT أو WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_WIBARS_BY]

إذا تم توفير وظيفة الرجوع إلى الصفحة السابقة وألغى المستخدم إيماءة الرجوع، عليك إجراء ما يلي:

• [C-8-1] يجب الاتصال بـ OnBackInvokedCallback.onBackCancelled().
• [C-8-2] OnBackInvokedCallback.onBackInvoked() يجب ألّا يتم الاتصال به.
• [C-8-3] يجب عدم إرسال الحدث KEYCODE_BACK.

إذا تم توفير وظيفة "الانتقال إلى الخلف" ولكن لم يتم تسجيل OnBackInvokedCallback في تطبيق المقدّمة، يجب عندها:

• "يجب أن يوفّر النظام" صورة متحركة للتطبيق الذي تعمل في المقدّمة تشير إلى عودة المستخدم، كما هو مذكور في 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. الإدخال باللمس الزائف

توفّر واجهة اللمس الزائفة نظام إدخال للمستخدم يتعامل مع مجموعة فرعية من إمكانيات الشاشة التي تعمل باللمس تقريبًا. على سبيل المثال، الماوس أو جهاز التحكم عن بُعد الذي يقود المؤشر على الشاشة يقترب اللمس، ولكنه يتطلب من المستخدم الإشارة أولاً أو التركيز ثم النقر. يمكن استخدام تفاعلات اللمس الزائفة بين العديد من أجهزة الإدخال، مثل الماوس ولوحة اللمس والماوس الهوائي المستنِد إلى الجيروسكوب ومؤشر الجيروسكوب وذراع التحكّم ولوحة اللمس المتعددة اللمسات. يتضمّن 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^2	زر Android
أ^1	0x09 0x0001	KEYCODE_button_A (96)
ب^1	0x09 0x0002	KEYCODE_button_B (97)
X^1	0x09 0x0004	KEYCODE_button_X (99)
ش^1	0x09 0x0005	KEYCODE_button_Y (100)
لوحة التحكّم^1 لوحة التحكّم^1	0x01 0x0039^3	AXIS_HAT_Y^4
لوحة التحكّم اليسرى1 لوحة التحكّم اليمنى^1	0x01 0x0039^3	AXIS_HAT_X^4
زر الكتف الأيسر^1	0x09 0x0007	KEYCODE_button_L1 (102)
زر الكتف الأيمن^1	0x09 0x0008	KEYCODE_button_R1 (103)
النقر على الذراع اليسرى^1	0x09 0x000E	KEYCODE_button_THUMBL (106)
النقر بزر الماوس الأيمن^1	0x09 0x000F	KEYCODE_button_THUMBR (107)
رجوع^1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 يجب الإفصاح عن استخدامات الواجهة البشرية (HID) أعلاه داخل لوحة الألعاب CA (0x01 0x0005).

3 يجب أن يكون لهذا الاستخدام حد أدنى منطقي يبلغ 0، وحد أقصى منطقي يبلغ 7، والحد الأدنى المادي بمقدار 0، والحد الأقصى المادي من 315، ووحدات بالدرجات، وحجم التقرير 4. يتم تعريف القيمة المنطقية على أنها الدوران في اتجاه عقارب الساعة بعيدًا عن المحور الرأسي. فعلى سبيل المثال، القيمة المنطقية 0 لا تمثل أي دوران ويتم الضغط على الزر لأعلى، بينما تمثل القيمة المنطقية 1 دورانًا بمقدار 45 درجة، ويتم الضغط على مفتاحي لأعلى واليسار.

4 MotionEvent

عناصر التحكّم التناظرية^1	استخدام أجهزة 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. أدوات الاستشعار

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

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

• [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] يجب ألا يمنع بث أحداث أداة الاستشعار وحدة المعالجة المركزية (CPU) من دخول حالة التعليق أو التنشيط من حالة التعليق.
• [C-1-6] يجب الإبلاغ عن وقت الحدث بالنانوثانية كما هو محدّد في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android، ما يمثّل وقت وقوع الحدث ومزامنته مع ساعة SystemClock.ebounddRealtimeNano() .
• [C-SR-1] يُوصى بشدة بأن يكون خطأ مزامنة الطابع الزمني أقل من 100 مللي ثانية، ويُفترض أن يكون خطأ مزامنة الطابع الزمني أقل من مللي ثانية.
• عند تفعيل عدة أجهزة استشعار، يجب ألا يتجاوز استهلاك الطاقة إجمالي استهلاك الطاقة الذي تم الإبلاغ عنه لكل أداة استشعار فردية.

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

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

• [C-1-6] يجب ضبط درجة دقة غير صفرية لجميع أجهزة الاستشعار، والإبلاغ عن القيمة من خلال طريقة واجهة برمجة التطبيقات Sensor.getResolution().

تكون بعض أنواع أجهزة الاستشعار مركَّبة، ما يعني أنّه يمكن اشتقاقها من البيانات المقدَّمة من جهاز استشعار آخر أو أكثر. (تشمل الأمثلة أداة استشعار الاتجاه وأداة استشعار التسارع الخطّي).

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

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

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

• [C-2-1] يجب تثبيت أداة الاستشعار كما هو موضّح في مستندات Android المفتوحة المصدر حول أجهزة الاستشعار المركّبة.

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

• [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] قادرًا على القياس من السقوط الحر إلى أربعة أضعاف الجاذبية(4 غرام) أو أكثر على أي محور.
• [C-1-5] يجب أن تصل درجة الدقة إلى 12 بت على الأقل.
• يجب أن يكون للانحراف المعياري [C-1-6] انحراف معياري لا يزيد عن 0.05 م/ث^، حيث يجب حساب الانحراف المعياري على أساس كل محور في العينات التي تم جمعها خلال مدة لا تقل عن 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] تكون strongLY_RECOMMENDED لاستخدامها في استخدام أداة استشعار TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED والإبلاغ عنها.

في حال تضمّنت عمليات تنفيذ الأجهزة مقياس تسارع ثلاثي المحاور وتم تنفيذ أي من أدوات الاستشعار المركّبة 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 ميكرومتر و+900 ميكرو طن على كل محور قبل تشبعه.
• يجب أن تكون قيمة إزاحة الحديد الصلب أقل من 700 ميكرو طن في [C-1-5]، ويجب أن تكون قيمتها أقل من 200 ميكرومتر، عن طريق وضع مقياس المغناطيسية بعيدًا عن المجالات المغناطيسية الديناميكية (المستحثة حاليًا) والثابتة (الناتجة عن المغناطيس).
• يجب أن تكون دقة الشاشة [C-1-6] مساوية أو أكثر كثافة من 0.6 ميكرومتر.
• يجب أن يتيح [C-1-7] المعايرة والتعويض على الإنترنت من انحياز الحديد والإبقاء على معلمات التعويض بين عمليات إعادة تشغيل الجهاز.
• [C-1-8] يجب تطبيق التعويض باستخدام الحديد الليّن، ويمكن إجراء المعايرة إمّا أثناء الاستخدام أو أثناء إنتاج الجهاز.
• يجب أن يكون للانحراف المعياري [C-1-9] انحراف معياري محسوب على أساس كل محور استنادًا إلى العيّنات التي تم جمعها على مدى 3 ثوانٍ على الأقل في أسرع معدّل لأخذ العينات، ويجب ألا يزيد عن 1.5 ميكرومتر. ويجب ألا يزيد الانحراف المعياري عن 0.5 ميكرو طن.
• [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 (GNSS) وتُبلغ التطبيقات عن هذه الإمكانية من خلال علامة ميزة android.hardware.location.gps، سيتم إجراء ما يلي:

• يجب أن يوفّر [C-1-1] نتائج الموقع الجغرافي بمعدّل لا يقل عن 1 هرتز عند طلبه عبر LocationManager#requestLocationUpdate.
• [C-1-2] يجب أن يتمكن من تحديد الموقع في ظروف السماء المفتوحة (إشارات قوية، مسارات متعددة بسيطة، بروتوكول HDOP أقل من 2) في غضون 10 ثوانٍ (أسرع وقت لإصلاح المشكلة لأول مرة)، عند الاتصال بسرعة بيانات بسرعة 0.5 ميغابت في الثانية أو أعلى. يتم تلبية هذا الشرط عادةً من خلال استخدام أحد أشكال تقنية GPS المستندة إلى نظام تحديد المواقع العالمي (GPS)/نظام GNSS المدعوم أو المتوقع لتقليل وقت قفل نظام تحديد المواقع العالمي (GPS)/نظام GNSS (تشمل بيانات المساعدة الوقت المرجعي)، والموقع المرجعي، وساعة القمر الصناعي المؤقت.
  • [C-1-6] بعد إجراء عملية حسابية للموقع الجغرافي، يجب أن تحدد عمليات تنفيذ الأجهزة موقعه الجغرافي في مكان مفتوح خلال 5 ثوانٍ من إعادة تشغيل طلبات الموقع الجغرافي بعد ساعة من الحساب الأولي للموقع الجغرافي، حتى إذا تم تقديم الطلب اللاحق بدون اتصال بيانات و/أو بعد دورة الطاقة.

• في ظروف السماء المفتوحة بعد تحديد الموقع، أثناء كونك ثابتًا أو تتحرك بسرعة أقل من متر واحد في الثانية المربعة من التسارع:

  • يجب أن يتمكن جهاز [C-1-3] من تحديد الموقع الجغرافي في نطاق 20 مترًا، وأن تزيد سرعته عن 0.5 متر في الثانية، أي ما لا يقل عن 95% من الوقت.
  • [C-1-4] يجب أن يتم في الوقت نفسه التتبُّع وإعداد التقارير من خلال GnssStatus.Callback 8 أقمار صناعية على الأقل من مجموعة نجوم واحدة.
  • ينبغي أن تكون قادرًا على تتبع ما لا يقل عن 24 قمرًا صناعيًا في وقت واحد، من مجموعات نجمية متعددة (على سبيل المثال، نظام تحديد المواقع العالمي (GPS) + واحد على الأقل من أقمار "غلوناس"، وبيدو، وغاليليو).

• [C-SR-2] يُوصى بشدة بمواصلة تقديم مخرجات الموقع الجغرافي العادية لنظام تحديد المواقع العالمي (GPS)/ GNSS (نظام تحديد المواقع العالمي (GPS)) من خلال واجهة برمجة تطبيقات مقدِّم خدمة الموقع من 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 بعد تحديد الموقع الجغرافي عندما تكون ثابتة أو تتحرك بسرعة أقل من 0.2 متر في الثانية المربعة، وأن تبلغ السرعة في نطاق 0.2 متر في الثانية على الأقل 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 per Hz (التباين لكل هرتز، أو 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] يتم strongLY_RECOMMENDED لاستخدام جهاز استشعار 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] يُنصح بشدة بأن تكون قادرًا على الإبلاغ عن قياسات الضغط في النطاق من 300hPa إلى 1100hPa.
• "ينبغي" الحصول على دقة مطلقة تبلغ 1hPa.
• يجب أن تكون الدقة نسبية تبلغ 0.12hPa أعلى من نطاق 20hPa (أي ما يعادل حوالي 1 متر من التغيير على مستوى سطح البحر) تقريبًا.

7.3.6. مقياس درجة الحرارة

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

• [C-1-1] يجب أن يحدّد SENSOR_TYPE_AMBIENT_TEMPERATURE لأداة استشعار الحرارة المحيطة ويجب أن تقيس أداة الاستشعار درجة الحرارة في البيئة المحيطة (كابينة الغرفة/المركبة) من المكان الذي يتفاعل فيه المستخدم مع الجهاز بالدرجات المئوية.

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

• [C-2-1] يجب ألا تحدّد SENSOR_TYPE_AMBIENT_TEMPERATURE لجهاز استشعار الحرارة.

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

• يُنصَح بشدة بأن تكون [C-SR-1] متوافقة مع واجهة برمجة التطبيقات PowerManager.getThermalHeadroom.

7.3.7. مقياس ضوء

• وقد تشمل إجراءات استخدام الجهاز مقياس ضوء (أداة استشعار الضوء المحيط).

7.3.8 أداة استشعار التقارب

• وقد تتضمن عمليات تنفيذ الأجهزة أداة استشعار التقارب.

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

• [C-1-1] يجب أن يقيس مسافة جسم في نفس اتجاه الشاشة. وهذا يعني أنّه يجب أن يكون جهاز استشعار التقارب موجَّهًا لاكتشاف أي أجسام قريبة من الشاشة، لأنّ الغرض الأساسي من هذا النوع من أجهزة الاستشعار هو رصد هاتف يستخدمه المستخدم. إذا كانت عمليات تنفيذ الأجهزة تتضمّن أداة استشعار التقارب بأي اتجاه آخر، يجب ألا تكون متاحة عبر واجهة برمجة التطبيقات هذه.
• [C-1-2] يجب أن يكون بدقة 1 بت أو أكثر.
• [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" ينطبق عليه ما يلي:

  • يجب أن يتراوح نطاق القياس بين -8 غرام و+8 غرام على الأقل، ويُنصَح بشدة بأن يتراوح نطاق القياس بين -16 غرام و+16 غرام على الأقل.
  • يجب أن تكون درجة دقة القياس لا تقل عن 2048 LSB/غرام.
  • يجب أن يكون الحد الأدنى لتكرار القياس 12.5 هرتز أو أقل.
  • يجب أن يبلغ الحد الأقصى لتردد القياس 400 هرتز أو أعلى، ويجب أن يكون متوافقًا مع جهاز الاستشعار المباشر RATE_VERY_FAST.
  • يجب أن يكون هناك تشويش في القياس ليس أعلى من 400 ميكروغرام/توفِّر ترددًا هرتز.
  • يجب استخدام نموذج لا يعتمد على التنشيط من هذا المستشعر مع قدرة على التخزين المؤقت لما لا يقل عن 3000 حدث استشعار.
  • يجب أن يكون استهلاك الطاقة بالدفعة أقل من 3 ميغاواط.
  • [C-SR-1] يُنصح بشدة بأن يتضمّن معدل نقل بيانات قياس 3dB بمعدّل لا يقل عن 80% من تردد Nyquist، وطيف ضوضاء أبيض ضمن هذا النطاق الترددي.
  • من المفترض أن يتم إجراء تسارع عشوائي للمشي أقل من 30 ميكروغرام ©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 هرتز أو أعلى، ويجب أن يكون متوافقًا مع جهاز الاستشعار المباشر RATE_VERY_FAST.
  • يجب أن يكون هناك تشويش في قياس حالة الجهاز لا يزيد عن 0.014 درجة/ثانية/وإعادة هرتز.
  • [C-SR-2] يُنصح بشدة بأن يتضمّن معدل نقل بيانات قياس 3dB بمعدّل لا يقل عن 80% من تردد Nyquist، وطيف ضوضاء أبيض ضمن هذا النطاق الترددي.
  • يجب أن يكون معدّل المشي العشوائي أقلّ من 0.001 درجة/ثانية ©Hz تم اختباره في درجة حرارة الغرفة.
  • يُفترض أن يكون هناك تغيُّر في الانحياز مقارنةً بدرجة الحرارة التي تبلغ ≤ +/- 0.05 درجة/ ثانية / درجة مئوية.
  • من المفترض أن يتغيّر مستوى الحساسية مقارنةً بدرجة الحرارة التي تقل عن 0.02% / درجة مئوية.
  • يُفترض أن يحتوي الخط غير الخطي على أفضل ملائمة، وهو ≤ 0.2%.
  • من المفترض أن تكون كثافة الضوضاء 0.007 درجة/ثانية/وإعادة هرتز أو أقل.
  • من المفترض أن يحدث خطأ في المعايرة يقل عن 0.002 راد/ثانية عندما تتراوح درجة الحرارة بين 10 و40 درجة مئوية عندما يكون الجهاز ثابتًا.
  • يجب أن تكون حساسية g-g أقل من 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 وحدة uT.

• يجب أن يتضمّن [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 Pa/fill هرتز.
  • يجب استخدام نموذج لا يعتمد على التنشيط من هذا المستشعر مع قدرة على التخزين المؤقت لما لا يقل عن 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] على كل اسم مَعلمة يتم تحديده على أنّه ثابت في فئة Authenticators وأي مجموعات منها. في المقابل، يجب ألا يتم الالتزام بثوابت الأعداد الصحيحة التي تم تمريرها إلى طريقتَي canAuthenticate(int) وsetAllowedAuthenticator(int) غير تلك الموثَّقة كثوابت عامة في Authenticator وأي مجموعات منها.
• [C-4-3] يجب تنفيذ إجراء ACTION_BIOMETRIC_ENROLL على الأجهزة التي تحتوي على مقاييس حيوية من الفئة 3 أو الفئة 2 يجب أن يعرض هذا الإجراء فقط نقاط دخول التسجيل للمقاييس الحيوية من الفئة 3 أو الفئة 2.

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

• [C-5-1] يجب أن تتطلب خطوة تأكيد إضافية تلقائيًا (مثلاً، الضغط على زر).
• [C-SR-1] يُوصى بشدة بأن تحتوي على إعداد يسمح للمستخدمين بتجاوز تفضيل التطبيق ويتطلب دائمًا خطوة تأكيد مصاحبة.
• [C-SR-2] يُوصى بشدة بتأمين إجراء التأكيد بحيث لا يمكن انتحال صفة أي نظام تشغيل أو اختراق بالنواة. وهذا يعني مثلاً أنّ إجراء التأكيد القائم على زر مادي يتم توجيهه من خلال دبوس للإدخال/الإخراج (GPIO) المخصّص للإدخال فقط للأغراض العامة (GPIO) للعنصر الآمن (SE) الذي لا يمكن تمريره باستخدام أي وسيلة أخرى غير الضغط على الزر الفعلي.
• [C-5-2] يجب أيضًا تنفيذ مسار مصادقة ضمنية (بدون خطوة التأكيد) يقابل setConfirmationrequired(boolean)، والذي يمكن للتطبيقات ضبطه للاستخدام في مسارات تسجيل الدخول.

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

• [C-SR-3] يُنصح بشدة بطلب تأكيد مقياس حيوي واحد فقط لكل عملية مصادقة (على سبيل المثال، في حال توفّر كلّ من بصمة الإصبع وأدوات استشعار الوجه على الجهاز، يجب إرسال onAuthenticationSucceeded بعد تأكيد أي منهما).

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

• يجب أن يستوفي [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] ننصح بشدة بفرض قيود على محاولات الحدّ من المعدّل لمدة لا تقل عن 30 ثانية بعد خمس محاولات خاطئة للتحقّق باستخدام المقاييس الحيوية في الحدّ الأقصى لعدد المحاولات غير الصحيحة لكل [C-1-9]، عندما تكون الفترة التجريبية الخاطئة واحدة ذات جودة تسجيل كافية (BIOMETRIC_ACQUIRED_GOOD) لا تتطابق مع المقاييس الحيوية المسجَّلة.
• [C-SR-6] يُنصح بشدة باعتماد جميع أسباب تقييد المعدّل في بيئة التنفيذ الموثوقة (TEE).
• [C-1-10] يجب إيقاف المقاييس الحيوية عند تشغيل التراجع عن المصادقة الأساسية لأول مرة كما هو موضح في [C-0-2] من القسم 9.11.
• [C-1-11] يجب أن يكون معدل قبول المحتال والانتحال لا يزيد عن 30%، في حال (1) مقياس قبول الانتحال والاحتيال لأنواع أدوات الهجوم (PAI) من المستوى أ التي لا يزيد عن 30%، و (2) معدل قبول المحتال ومستوى قبول المحتال من المستوى B PAI، حيث لا يزيد هذا المعدل عن Android 40.
• [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 ساعة أو أقل. ملاحظة: عند ترقية الأجهزة التي تعمل بالإصدار 9 من نظام التشغيل Android أو الإصدارات الأقدم، يجب أن تواجه المستخدم تحديًا للحصول على المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي والنقش وكلمة المرور) مرة كل 72 ساعة أو أقل.
• [C-1-8] يجب أن يطلب المستخدم إجراء المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) أو المقاييس الحيوية من الفئة 3 (strong) بعد أحد الإجراءات التالية:
  • مهلة عدم النشاط لمدة 4 ساعات
  • 3 محاولات فاشلة لمصادقة المقاييس الحيوية
  • وتتم إعادة ضبط مهلة عدم النشاط وعدد عمليات المصادقة التي تعذّر إجراؤها بعد إجراء أي تأكيد ناجح لبيانات اعتماد الجهاز. ملاحظة: قد يتم استثناء أجهزة الترقية التي تم إطلاقها على الإصدار 9 من نظام التشغيل Android أو الإصدارات الأقدم من نظام التشغيل C-1-8.
• [C-SR-7] يُنصَح باستخدام المنطق في إطار العمل المقدَّم من "المشروع المفتوح المصدر لنظام Android" لفرض القيود المحدَّدة في [C-1-7] و[C-1-8] على الأجهزة الجديدة.
• [C-SR-8] يُنصح بشدة بأن يكون معدّل الرفض الخاطئ أقل من 10% عند قياسها على الجهاز.
• [C-SR-9] يُنصح بشدة بأن يكون وقت الاستجابة أقل من ثانية واحدة، والتي يتم قياسها من وقت رصد المقاييس الحيوية إلى أن يتم فتح قفل الشاشة، لكل مقياس حيوي مسجَّل.

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

• يجب أن يستوفي [C-2-1] جميع متطلبات الفئة 1 أعلاه.

• [C-2-2] يجب أن يكون معدل قبول المحتال والانتحال لا يزيد عن 20%، وذلك من خلال (1) مقياس قبول محاكاة ومحتال لأنواع مختلفة من أدوات الهجوم في العرض التقديمي من المستوى أ (PAI) لا يزيد عن 20%، و (2) معدل قبول محاكاة ومحتال من الأنواع من المستوى B PAI، لا يزيد عن 30% من البروتوكول Bid.

• [C-2-3] يجب أن تُجري مطابقة المقاييس الحيوية في بيئة تنفيذ معزولة خارج مساحة مستخدم Android أو مساحة kernel، مثل بيئة التنفيذ الموثوقة (TEE)، أو على شريحة ذات قناة آمنة لبيئة التنفيذ المعزولة.

• يجب أن يكون لدى [C-2-4] جميع البيانات التي يمكن التعرّف عليها والمصادق عليها بطريقة مشفّرة ويتعذّر الحصول عليها أو قراءتها أو تغييرها خارج بيئة التنفيذ المعزولة أو شريحة ذات قناة آمنة لبيئة التنفيذ المعزولة كما هو موثّق في إرشادات التنفيذ على موقع "المشروع المفتوح المصدر لنظام Android".

• [C-2-5] بالنسبة إلى المقاييس الحيوية المستندة إلى الكاميرا، عند إجراء المصادقة أو التسجيل باستخدام المقاييس الحيوية:

  • يجب تشغيل الكاميرا في وضع يمنع قراءة إطارات الكاميرا أو تغييرها خارج بيئة التنفيذ المعزولة أو شريحة ذات قناة آمنة لبيئة التنفيذ المعزولة.
  • بالنسبة إلى حلول الكاميرا الأحادية اللون الأحمر والأخضر والأزرق، يمكن أن تكون إطارات الكاميرا قابلة للقراءة خارج بيئة التنفيذ المعزولة لدعم العمليات، مثل معاينة التسجيل، ولكن يجب ألا تكون قابلة للتغيير.

• [C-2-6] يجب ألا يتم تفعيل التطبيقات التابعة لجهات خارجية للتمييز بين عمليات تسجيل المقاييس الحيوية الفردية.

• [C-2-7] يجب ألا يسمح بالوصول غير المشفر إلى بيانات المقاييس الحيوية التي تحدد الهوية أو أي بيانات مستمدة منها (مثل التضمينات) إلى "معالج التطبيقات" خارج سياق بيئة التنفيذ الموثوقة (TEE). يُرجى العلم أنّ ترقية الأجهزة التي تم إطلاقها تعمل بالإصدار 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) لا يزيد عن 7% من 7%، و(2) معدّل قبول محاكاة واحتيال لنوعَين من المستوى B PAI لا يزيد عن 20% في البروتوكول الاختبار المحتال من Android.
• [C-3-4] يجب أن يطلب المستخدم إجراء المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) مرة كل 72 ساعة أو أقل.
• [C-3-5] يجب إعادة إنشاء رقم تعريف Authenticator لجميع المقاييس الحيوية من الفئة 3 المتوافقة على الجهاز في حال إعادة تسجيل أي منها.
• [C-3-6] يجب تفعيل مفاتيح تخزين المفاتيح المستنِدة إلى مقاييس حيوية للتطبيقات التابعة لجهات خارجية.

إذا كانت عمليات تنفيذ الجهاز تحتوي على أداة استشعار بصمة الإصبع أسفل الشاشة (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_HINGLE_ANGLE والإبلاغ عنه.
• [C-1-2] يجب أن يدعم قراءتين على الأقل بين 0 و360 درجة (أي تشمل 0 و360 درجة).
• [C-1-3] يجب أن يعرض جهاز استشعار الاستيقاظ لـ getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

7.3.13. معيار IEEE 802.1.15.4 [تم النقل إلى الإصدار 7.4.9]

7.4. إمكانية اتصال البيانات

7.4.1. الاتصالات الهاتفية

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

• قد يتم استخدام 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 على "قديم"، سيتم ما يلي:

• [C-4-1] يجب ألا يتم الإبلاغ عن "NETWORK_TYPE_IWLAN" عبر NetworkRecordInfo#getAccessNetworkTechnology() عند الإبلاغ عن NetworkRecordInfo#getTransportType() كـ "TRANSPORT_TYPE_WWAN" لمثيل NetworkInfo نفسه.

إذا كانت عمليات تنفيذ الأجهزة تتيح تسجيل نظام فرعي للوسائط المتعددة (IMS) لعنوان IP واحد لكل من ميزات خدمة الاتصال الهاتفي المتعدد الوسائط (MMTEL) وميزات خدمة الاتصالات التفاعلية (RCS)، ومن المتوقّع أن تكون متوافقة مع متطلبات مشغّل شبكة الجوّال بشأن استخدام تسجيل واحد لنظام الرسائل الإلكترونية المتعددة (IMS) لجميع حركة بيانات إشارات الرسائل الفورية:

• [C-5-1] يجب أن يفصح عن علامة الميزة android.hardware.telephony.ims وينفّذ بشكل كامل واجهة برمجة تطبيقات ImsService API لكل من MMTEL وRCS User Capability Exchange API.
• يجب أن يفصح [C-5-2] عن علامة ميزة android.hardware.telephony.ims.singlereg وأن توفّر تنفيذًا كاملاً لـ SipTransport API، وGbaService API، وإشارات الحامل المخصصة باستخدام IRadio 1.6 HAL، وتوفير المتطلبات اللازمة من خلال خادم الإعداد التلقائي (ACS) أو آلية أخرى خاصة بتوفير المتطلبات اللازمة باستخدام واجهة برمجة تطبيقات إعداد IMS.

إذا كانت عمليات تنفيذ الأجهزة تعرض ميزة "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 عند إرسال الرسائل القصيرة ورسائل الوسائط المتعددة واستلامها. يفي تنفيذ مرجع AOSP في الحزم/التطبيقات/المراسلة بهذا الشرط.
• [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] يُنصح بشدة باختيار اشتراك تمثيلي اشتراك بيانات نشِط ما لم يكن الجهاز في مكالمة صوتية يُنصح بشدة بأن يكون الاشتراك التمثيلي هو اشتراك Voice النشِط.

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

• يجب أن يكون [C-6-7] قادرًا على فتح واستخدام الحد الأقصى في الوقت نفسه من القنوات المنطقية (إجمالي 20 قناة) لكل UICC وفقًا لمعيار ETSI TS 102 221.
• [C-6-8] يجب ألا يطبّق أي من السلوكيات التالية على تطبيقات مشغّل شبكة الجوّال النشطة (وفقًا لما حدّده "TelephonyManager#getCarrierServicePackageName") تلقائيًا أو بدون تأكيد صريح من المستخدم:
  • إبطال الوصول إلى الشبكة أو تقييده
  • إبطال الأذونات
  • فرض قيود على عمليات تنفيذ التطبيقات التي تعمل في الخلفية أو التي تعمل في المقدّمة بشكل يتجاوز ميزات إدارة الطاقة الحالية المضمّنة في AOSP
  • إيقاف التطبيق أو إلغاء تثبيته

إذا كانت عمليات تنفيذ الأجهزة تُبلِغ عن ميزة android.hardware.telephony وجميع الاشتراكات النشطة غير الانتهازية التي تتشارك المعرّف الفريد العالمي (UUID) في مجموعة أو تم إيقافها أو إزالتها فعليًا من الجهاز أو تم وضع علامة عليها كفرصة للتحسين، سيترتب على الجهاز تنفيذ ما يلي:

• [C-8-1] يجب أن يوقِف تلقائيًا كل الاشتراكات الفرصة النشطة المتبقية في المجموعة نفسها.

إذا كانت عمليات تنفيذ الأجهزة تتضمن اتصالات هاتفية عبر بروتوكول GSM لكن لا تشتمل على اتصال هاتفي عبر CDMA، فإنها:

• [C-9-1] يجب ألا يفصح عن PackageManager#FEATURE_TELEPHONY_CDMA.
• يجب إرسال IllegalArgumentException عند محاولة ضبط أي نوع من أنواع شبكات 3GPP2 على أقنعة بتات مفضّلة أو مسموح بها من نوع الشبكة [C-9-2].
• [C-9-3] يجب أن تعرض سلسلة فارغة من TelephonyManager#getMeid.

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

• [C-10-1] يجب أن تشير إلى علامة ميزة android.hardware.telephony.euicc.mep.

7.4.1.1. التوافق مع حظر الأرقام

إذا أبلغت عمليات تنفيذ الأجهزة عن ميزة "android.hardware.telephony.calling"، سيتم ما يلي:

• [C-1-1] يجب أن يتضمن إمكانية حظر الأرقام
• [C-1-2] يجب أن يستخدم BlockedNumberContract وواجهة برمجة التطبيقات المقابلة بشكل كامل كما هو موضّح في مستندات حزمة تطوير البرامج (SDK).

• [C-1-3] يجب حظر جميع المكالمات والرسائل من رقم هاتف في "BlockNumberProvider" بدون أي تفاعل مع التطبيقات. الاستثناء الوحيد هو عندما يتم رفع حظر الرقم مؤقتًا كما هو موضح في مستندات حزمة SDK.

• [C-1-4] يجب الكتابة إلى موفِّر خدمة سجلّ المكالمات في النظام الأساسي لإجراء مكالمة محظورة ويجب فلترة المكالمات التي تتضمّن BLOCKED_TYPE من عرض سجلّ المكالمات التلقائي في تطبيق برنامج الاتصال المثبَّت مسبقًا.

• [C-1-5] يجب ألّا يتواصل مع مقدِّم خدمات الاتصال الهاتفي عن رسالة محظورة.

• [C-1-6] يجب تنفيذ واجهة مستخدم لإدارة الأرقام المحظورة، والتي يتم فتحها بهدف العرض باستخدام الطريقة TelecomManager.createManageBlockedNumbersIntent().

• [C-1-7] يجب ألا يسمح للمستخدمين الثانويين بعرض الأرقام المحظورة أو تعديلها على الجهاز حيث يفترض نظام Android الأساسي أن المستخدم الأساسي يتمتع بالتحكم الكامل في خدمات الاتصال الهاتفي، في حالة واحدة، على الجهاز. يجب إخفاء جميع واجهات المستخدم ذات الصلة التي تؤدي إلى حظر الوصول إلى المستخدمين الثانويين، مع احترام القائمة المحظورة.

• يجب نقل الأرقام المحظورة إلى المزود عند تحديث الجهاز إلى Android 7.0.

• يجب أن يوفر للمستخدم إمكانية عرض المكالمات المحظورة في تطبيق الاتصال المثبت مسبقًا.

7.4.1.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 على النحو التالي:

  • يمكنك طلب الرقم Connection.onDisconnect() عند رصد ضغطة قصيرة على الحدث الرئيسي أثناء مكالمة جارية.
  • اطلب الرقم Connection.onAnswer() عند رصد ضغطة قصيرة على الحدث الرئيسي أثناء مكالمة واردة.
  • يمكنك الاتصال بالرقم Connection.onReject() عند رصد ضغطة طويلة على الحدث الرئيسي أثناء مكالمة واردة.
  • تبديل حالة كتم صوت جهاز CallAudioState

7.4.1.3. نقل البيانات من شبكة NAT-T Keepalive

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

• يجب أن تشتمل هذه السياسة على إمكانية نقل بيانات رسالة التحقّق من الاتصال على شبكة الجوّال.

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

• [C-1-1] يجب أن يتوافق مع واجهة برمجة تطبيقات SocketKeepAlive.
• [C-1-2] يجب أن يتوافق مع خانة واحدة على الأقل رسالة التحقّق من الاتصال المتزامنة عبر شبكة الجوّال.
• [C-1-3] يجب أن يتوافق مع العديد من خانات الاتصال بشبكة الجوّال المتزامنة التي تتوافق مع طبقة تجريد الأجهزة (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] يجب أن ينفذ multicast API كما هو موضح في مستندات حزمة SDK.
• [C-1-4] يجب أن يتوافق مع نظام أسماء النطاقات ذي البث المتعدد (mDNS) ويجب ألا يصف حزم mDNS (224.0.0.251) في أي وقت من التشغيل، بما في ذلك:
  • حتى عندما لا تكون الشاشة في حالة نشطة.
  • لعمليات تنفيذ أجهزة Android TV، حتى عندما يكون الجهاز في حالة الطاقة في وضع الاستعداد.
• [C-1-5] يجب ألا يتعامل مع طلب طريقة واجهة برمجة التطبيقات WifiManager.enableNetwork() كمؤشر كافٍ لتبديل طريقة الدفع النشطة حاليًا Network التي يتم استخدامها تلقائيًا لعدد زيارات التطبيقات ويتم عرضها من خلال ConnectivityManager طرق واجهة برمجة التطبيقات مثل getActiveNetwork وregisterDefaultNetworkCallback. بمعنى آخر، يجوز لها فقط إيقاف الوصول إلى الإنترنت الذي يوفره أي مزوّد شبكة آخر (على سبيل المثال، بيانات الجوّال) إذا نجح في التحقق من أن شبكة Wi-Fi توفر الوصول إلى الإنترنت.
• [C-1-6] يُنصح بها بشدة عند الحاجة إلى استخدام ConnectivityManager.reportNetworkConnectivity() طريقة واجهة برمجة التطبيقات، يجب إعادة تقييم الاتصال بالإنترنت على Network وبعد أن يحدّد التقييم أنّ "Network" الحالي لم يعد يوفّر الاتصال بالإنترنت، يمكنك التبديل إلى أي شبكة أخرى متاحة (مثل بيانات الجوّال) توفّر الاتصال بالإنترنت.
• [C-1-7] يجب أن عشوائيًا عنوان MAC للمصدر ورقم تسلسل إطارات طلب الفحص، مرة في بداية كل عملية فحص، بينما يكون STA غير متصل.
• [C-1-8] يجب استخدام عنوان MAC واحد متسق (يجب ألا يتم ترتيب عنوان MAC عشوائيًا في منتصف عملية الفحص).
• [C-1-9] يجب تكرار رقم تسلسل طلب التحقيق كالمعتاد (بالتسلسل) بين طلبات التحقيق في الفحص.
• [C-1-10] يجب أن يتم ترتيب رقم تسلسل طلب التحقيق عشوائيًا بين آخر طلب فحص وأول طلب فحص لعملية الفحص التالية.
• [C-SR-1] يُنصح بشدة بأن يتم عشوائيًا عنوان MAC المصدر المستخدَم في جميع اتصالات STA بنقطة وصول (AP) أثناء الإقران والربط.
  • يجب أن يستخدم الجهاز عنوان MAC عشوائيًا مختلفًا لكل معرِّف SSID (FQDN لنقطة مرور) يتصل به.
  • يجب أن يوفّر الجهاز للمستخدم خيارًا للتحكُّم في التوزيع العشوائي حسب SSID (FQDN for Passpoint) من خلال خيارات غير عشوائية وعشوائية، كما يجب أن يضبط الوضع التلقائي لإعدادات Wi-Fi الجديدة ليتم التوزيع عشوائيًا عليه.
• [C-SR-2] يُنصَح بشدة باستخدام معرّف مجموعة خدمات الأساسية (BSSID) عشوائيًا لأي نقطة وصول يتم إنشاؤها.
  • يجب اختيار عنوان MAC عشوائيًا واستمراره حسب SSID الذي تستخدمه AP.
  • قد يوفر الجهاز للمستخدم خيارًا لتعطيل هذه الميزة. في حال توفير مثل هذا الخيار، يجب تفعيل التوزيع العشوائي تلقائيًا.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن توافقًا مع وضع توفير الطاقة عبر شبكة 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 وتستخدم شبكة 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 Direct معًا.
• [C-SR-1] يُنصَح بشدة باستخدام عنوان MAC المصدر عشوائيًا لجميع اتصالات Wi-Fi Direct التي تم تشكيلها حديثًا.

7.4.2.2. إعداد رابط مباشر عبر أنفاق شبكة Wi-Fi

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

• يجب أن تتم إتاحة إعداد الربط المباشر عبر نفق Wi-Fi (TDLS) كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن توافقًا مع TDLS وTDLS من خلال WiFiManager API، فإنّها:

• [C-1-1] يجب أن يعلن عن توفّر TDLS من خلال WifiManager.isTdlsSupported.
• "يجب" استخدام "TDL" فقط عندما يكون ذلك ممكنًا ومفيدًا.
• يجب أن يكون لديك بعض الإرشادات وألّا تستخدم الاتصال القصير المدى (TDLS) عندما يكون أداؤه أسوأ من الانتقال عبر نقطة وصول Wi-Fi.

7.4.2.3. التعرُّف على شبكة Wi-Fi

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

• يجب أن تتوافق مع خدمة 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 في الوقت نفسه.
• [C-1-4] يجب أن يتم توزيع عنوان واجهة إدارة Wi-Fi Aware عشوائيًا على فترات زمنية لا تزيد عن 30 دقيقة وعندما تكون خدمة Wi-Fi Aware مفعّلة إلا إذا كانت عملية النطاق الواعي قيد التشغيل أو كان مسار البيانات في خدمة Aware نشطًا (لن يكون التوزيع العشوائي متوقعًا ما دام مسار البيانات نشطًا).

وفي حال كانت عمليات تنفيذ الأجهزة تتضمّن توافقًا مع "Wi-Fi" و"الموقع الجغرافي لشبكات Wi-Fi" كما هو موضَّح في القسم 7.4.2.5 ويعرض هذه الوظائف على تطبيقات تابعة لجهات خارجية، سيتم الالتزام بما يلي:

• [C-2-1] يجب تنفيذ واجهات برمجة التطبيقات الخاصة بميزة "اكتشاف المواقع الجغرافية": setRangingEnabled، وsetMinSpaceMm، وsetMaxScopeMm ، وonServiceDiscoveredWithinRange.

7.4.2.4. نقطة مرور Wi-Fi

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع معيار 802.11 (Wi-Fi)، سيتم ما يلي:

• [C-1-1] يجب أن يتوافق مع نقطة مرور Wi-Fi.
• [C-1-2] يجب تنفيذ واجهات برمجة تطبيقات WifiManager ذات الصلة بنقطة المرور كما هو موضّح في مستندات حزمة تطوير البرامج (SDK).
• [C-1-3] يجب أن يتوافق مع معيار IEEE 802.11u، الذي يرتبط تحديدًا باكتشاف الشبكة واختيارها، مثل خدمة الإعلانات العامة (GAS) وبروتوكول طلب بحث شبكة الوصول (ANQP).
• [C-1-4] يجب أن يعلن عن علامة ميزة android.hardware.wifi.passpoint.
• يجب أن يتّبع [C-1-5] تنفيذ AOSP لاكتشاف شبكات نقطة المرور ومطابقتها وربطها.
• يجب أن يتوافق [C-1-6] على الأقل مع المجموعة الفرعية التالية من بروتوكولات توفير المتطلبات اللازمة للأجهزة على النحو المحدَّد في Wi-Fi Alliance Passpoint R2: مصادقة EAP-TTLS وSOAP-XML.
• [C-1-7] يجب أن يعالج شهادة خادم AAA كما هو موضح في مواصفات Hotspot 2.0 R3.
• [C-1-8] يجب أن يتيح تحكُّم المستخدم في توفير المتطلبات اللازمة من خلال "أداة اختيار شبكة Wi-Fi".
• [C-1-9] يجب أن تظل إعدادات نقطة المرور مستمرة في جميع عمليات إعادة التشغيل.
• [C-SR-1] يُنصَح باستخدامها بشدة لإتاحة ميزة قبول الأحكام والشروط
• [C-SR-2] يُوصى بها بشدة لدعم ميزة معلومات المكان.

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

• [C-3-1] يجب تفعيل "نقطة المرور" تلقائيًا.

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 التي يتم تنفيذ هذه الميزة عليها غير مرتبطة بنقطة وصول.
• [C-1-4] يجب أن تكون دقيقة في نطاق مترين وبنطاق نقل بيانات 80 ميغاهرتز عند النسبة المئوية 68 (وفقًا لحساب دالة التوزيع التراكمي).
• [C-SR-1] يُنصح بشدة بالإبلاغ عن ذلك بدقة في نطاق 1.5 متر في نطاق ترددي يبلغ 80 ميغاهرتز عند الشريحة المئوية 68 (وفقًا لحساب دالة التوزيع التراكمي).

7.4.2.6. إيقاف نقل بيانات شبكة Wi-Fi Keepalive

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

• يجب أن يشمل ذلك الدعم لنقل بيانات رسالة التحقُّق من الاتصال بشبكة Wi-Fi.

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

• [C-1-1] يجب أن يتوافق مع واجهة برمجة تطبيقات SocketKeepAlive.
• [C-1-2] يجب أن يتوافق مع ما لا يقل عن ثلاث خانات متزامنة للحفاظ على الاتصال عبر Wi-Fi.

إذا لم تكن عمليات تنفيذ الجهاز تتضمّن توافقًا مع نقل بيانات رسالة التحقُّق من الاتصال بشبكة Wi-Fi، سيؤدي ذلك إلى:

• [C-2-1] يجب أن يعرض ERROR_UNSUPPORTED.

7.4.2.7. الاتصال السهل عبر Wi-Fi (بروتوكول توفير المتطلبات اللازمة للأجهزة)

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

• يجب أن يتوافق مع بروتوكول Wi-Fi Easy Connect (DPP).

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

• [C-1-1] يجب أن تتضمن الطريقة WifiManager#isEasyConnectSupported() تعرض الطريقة true.

7.4.2.8. التحقُّق من شهادة خادم Wi-Fi للمؤسسات

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

• [C-SR-1] يُنصح بشدة بعدم توفير خيار إضافة Enterprise Wi-Fi Network يدويًا إلى تطبيق "الإعدادات".

7.4.2.9. الثقة عند الاستخدام الأول (TOFU)

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع الثقة عند الاستخدام الأول (TOFU) وتسمح للمستخدم بتحديد إعدادات WPA/WPA2/WPA3-Enterprise، يجب اتخاذ الإجراءات التالية:

• [C-4-1] يجب أن يوفر للمستخدم خيارًا لتحديد استخدام TOFU.

7.4.3. البلوتوث

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع الملف الشخصي لـ Bluetooth Audio:

• يجب أن تتوافق مع برامج ترميز الصوت المتقدّمة وبرامج ترميز الصوت عبر البلوتوث (مثل LDAC) مع A2DP.

إذا كانت تطبيقات الأجهزة تتيح استخدام HFP وA2DP وAVRCP، سيتم ما يلي:

• يجب أن يتوافق مع إجمالي 5 أجهزة متصلة على الأقل.

إذا تضمّنت عمليات تنفيذ الأجهزة ميزة android.hardware.vr.high_performance، سيتم ما يلي:

• [C-1-1] يجب أن يتوافق مع Bluetooth 4.2 وBluetooth LE Data Length.

يتيح Android استخدام البلوتوث والبلوتوث منخفض الطاقة.

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

• يجب أن يفصح [C-2-1] عن ميزات المنصة ذات الصلة (android.hardware.bluetooth وandroid.hardware.bluetooth_le على التوالي) وتنفيذ واجهات برمجة تطبيقات النظام الأساسي.
• يجب تنفيذ الملفات الشخصية ذات الصلة عبر البلوتوث، مثل A2DP وAVRCP وOBEX وHFP وما إلى ذلك، وفقًا لما يتناسب مع الجهاز.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية استخدام Bluetooth Low Energy (BLE)، سيتم إجراء ما يلي:

• يجب أن يُعلِن [C-3-1] عن ميزة الأجهزة "android.hardware.bluetooth_le".
• [C-3-2] يجب تفعيل واجهات برمجة التطبيقات للبلوتوث المستندة إلى GATT (الملف الشخصي للسمات العامة) كما هو موضّح في مستندات حزمة SDK وandroid.Bluetooth.
• [C-3-3] يجب الإبلاغ عن القيمة الصحيحة لـ BluetoothAdapter.isOffloadedFilteringSupported() للإشارة إلى ما إذا كان منطق الفلترة لفئات واجهة برمجة التطبيقات ScanFilter قد تم تنفيذه.
• [C-3-4] يجب الإبلاغ عن القيمة الصحيحة للسمة BluetoothAdapter.isMultipleAdvertisementSupported() للإشارة إلى ما إذا كان مسموحًا بالإعلانات منخفضة الطاقة.
• [C-3-5] يجب تنفيذ مهلة لا تزيد عن 15 دقيقة لعنوان خاص قابل للتحليل، مع تدوير العنوان عند انتهاء المهلة لحماية خصوصية المستخدم عندما يستخدم الجهاز تقنية BLE لفحصها أو لعرض إعلانات عليها. لمنع هجمات التوقيت، يجب أيضًا توزيع الفواصل الزمنية بشكل عشوائي تتراوح بين 5 و15 دقيقة.
• يجب أن يتوافق مع إلغاء تحميل منطق الفلترة إلى مجموعة شرائح البلوتوث عند تنفيذ ScanFilter API.
• يجب أن يتيح تحميل المسح المجمَّع إلى شريحة البلوتوث.
• يجب أن يدعم الإعلان المتعدد في 4 خانات على الأقل.

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

• [C-4-1] يجب أن يتيح للمستخدم تفعيل/إيقاف القيمة المقروءة من خلال BluetoothAdapter.isBleScanAlwaysAvailable() System API.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن توافقًا مع Bluetooth LE وHearing Aids على النحو الموضّح في Hearing Aid Audio Support باستخدام Bluetooth LE، ينطبق ما يلي:

• [C-5-1] يجب عرض true لـ BluetoothAdapter.getProfileProxy(context, Listener, BluetoothProfile.HEARING_AID).

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

• [C-6-1] يجب حظر الوصول إلى أي بيانات وصفية خاصة بالبلوتوث (مثل نتائج البحث) يمكن استخدامها لمعرفة الموقع الجغرافي للجهاز، ما لم يجتَز التطبيق صاحب الطلب عملية فحص إذن android.permission.ACCESS_FINE_LOCATION استنادًا إلى حالة المقدّمة/الخلفية الحالية.

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

• [C-6-2] يجب حظر الوصول إلى البلوتوث خلف android.permission.ACCESS_FINE_LOCATION.

إذا كانت عمليات تنفيذ الأجهزة تعرض true لواجهة برمجة تطبيقات BluetoothAdapter.isLeAudioSupported()، سيتم عندها:

• [C-7-1] يجب أن يتوافق مع برنامج البث الأحادي.
• [C-7-2] يجب أن يدعم 2 مليون PHY.
• [C-7-3] يجب أن يتوافق مع LE Extended Advertising.
• [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 من القياسات على مسافة 1 متر من جهاز مرجعي ينقله في ADVERTISE_TX_POWER_HIGH في بيئة خط الرؤية.
• يجب أن يشتمل [C-10-2] على تصحيحات Rx/Tx لتقليل الانحرافات لكل قناة بحيث تكون القياسات في كل قناة من القنوات الثلاث وعلى كل من الهوائيات (في حال استخدام عدة هوائيات) ضمن نطاق +/-3 ديسيبل من بعضها البعض بنسبة 95% من القياسات.
• [C-SR-2] يُنصح بشدة بقياس قيمة معادلة Rx وتعويضها للتأكّد من أنّ القيمة المتوسطة لمعيار BLE RSSI تبلغ -60 ديسيبل ملي واط +/-10 ديسيبل على مسافة 1 متر من جهاز مرجعي يتم نقله في ADVERTISE_TX_POWER_HIGH، حيث تكون الأجهزة موجَّهة على "مستويات متوازية" مع توجيه الشاشات نفسها.
• [C-SR-3] يُنصح بشدة بقياس قيمة معادلة الصوت Tx وتعويضها للتأكّد من أنّ القيمة المتوسطة لخلاصة RSSI بتقنية BLE -60 ديسيبل ملي واط +/-10 ديسيبل عند البحث عن الجهاز المرجعي على مسافة 1 متر أثناء الإرسال في ADVERTISE_TX_POWER_HIGH، حيث تكون الأجهزة موجَّهة على "المستوى المتوازي"

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

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

• [C-SR-4] يُنصَح باستخدامها بشدة لتقديم الدعم في ما يلي:
  • LE 2 مليون
  • LE Codec PHY
  • إضافة LE Advertising
  • الإعلانات الدورية
  • 10 مجموعات إعلانية على الأقل
  • ما لا يقل عن 8 اتصالات متزامنة منخفضة الطاقة (LE). يمكن أن يكون كل رابط في أدوار طوبولوجيا الاتصال.
  • خصوصية طبقة رابط LE
  • حجم "حل القائمة" لا يقل عن 8 إدخالات

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 (وفقًا للمواصفات الفنية لمنتدى NFC) NFCForum-TS-DigitalProtocol-1.0) من خلال معايير NFC التالية:
  • NFCA (ISO14443-3A)
  • NFCB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • أنواع علامات منتدى NFC 1 و2 و3 و4 و5 (يحدّدها منتدى NFC)

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

• [C-1-13] يجب إجراء استطلاع لكل التكنولوجيات المتوافقة أثناء استخدام وضع اكتشاف NFC.

• يجب أن يكون في وضع الاكتشاف عبر تقنية NFC عندما يكون الجهاز نشطًا مع كون الشاشة نشطة وفتح قفل الشاشة.

• أن يتمكّن من قراءة الرمز الشريطي وعنوان URL (إذا كانا مشفّرين) لمنتجات الرمز الشريطي لتقنية NFC في Thinfilm

تجدر الإشارة إلى أنّ الروابط المتاحة للجميع لا تتوفّر لمواصفات منتدى JIS وISO وNFC المذكورة أعلاه.

يتيح Android استخدام وضع محاكاة بطاقة مضيف NFC (HCE).

إذا كانت عمليات تنفيذ الجهاز تتضمّن مجموعة شرائح لوحدة تحكُّم NFC متوافقة مع تقنية HCE (لرموز NfcA و/أو NfcB) وتتوافق مع ميزة توجيه معرّف التطبيق (AID)، يجب إجراء ما يلي:

• [C-2-1] يجب أن يبلغ عن ثابت خاصية android.hardware.nfc.hce.
• يجب أن يتوافق [C-2-2] مع واجهات برمجة تطبيقات NFC HCE كما هو محدد في حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

إذا كانت عمليات تنفيذ الجهاز تتضمّن مجموعة شرائح لوحدة تحكُّم في NFC قادرة على استخدام وظيفة HCE في الترميز NfF، وتم تفعيل هذه الميزة على تطبيقات تابعة لجهات خارجية، سيتم إجراء ما يلي:

• [C-3-1] يجب أن يبلغ عن ثابت خاصية android.hardware.nfc.hcef.
• يجب أن ينفِّذ [C-3-2] واجهات برمجة تطبيقات محاكاة بطاقة NfcF على النحو المحدّد في حزمة تطوير البرامج (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 وإيثرنت ورقم 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" (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 وعرض صفحة تسجيل الدخول إلى المدخل المشروط الوصول إليه، من خلال إرسال هذا الغرض، عند طلب واجهة برمجة تطبيقات النظام ConnectivityManager#startCaptivePortalApp(Network, Bundle).
• [C-1-2] يجب إجراء الكشف عن المداخل المقيدة وتوفير إمكانية تسجيل الدخول من خلال تطبيق المدخل المشروط عند توصيل الجهاز بأي نوع من أنواع الشبكات، بما في ذلك الشبكة الخلوية/الجوّالة أو WiFi أو 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 كما هو موضّح في مستندات حزمة تطوير البرامج (SDK)

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

• [C-2-1] يجب أن تعرض القيمة RESTRICT_BACKGROUND_STATUS_DISABLED في ConnectivityManager.getRestrictBackgroundStatus()
• [C-2-2] يجب ألا يتم بثه 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 للجهاز المزود بعناصر آمنة مستندة إلى الدقة العادية.

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% من القياسات في بيئة خط الرؤية على مسافة 1 متر في غرفة غير عاكسة.
  • يجب أن يضمن [C-1-7] أن يكون متوسط قياسات المسافة على بُعد متر واحد من الجهاز المرجعي في نطاق [0.75 متر أو 1.25 متر]، حيث يتم قياس مسافة الأرض من الحافة العلوية من الحافة العلوية من الجزء العلوي وإمالتها بمقدار 45 درجة.
  • [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 في التطبيق المستلِم.

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

• [C-2-1] يجب أن يتوافق مع ملف شخصي بتقنية HLG HDR على الأقل لكل جهاز كاميرا يتوافق مع إخراج 10 بت.
• [C-2-2] يجب أن يتوفر إخراج 10 بت إما للكاميرا الخلفية الأساسية أو الأمامية الأساسية.
• [C-SR-1] يُنصح بشدة باعتماد مخرجات 10 بت لكلتا الكاميرتين الأساسيتين.
• [C-2-3] يجب أن يتوافق مع ملفات HDR نفسها لكل الكاميرات الفرعية الفعلية المتوافقة مع BACKWARD_COMPATIBLE في الكاميرا المنطقية، والكاميرا المنطقية نفسها.

بالنسبة إلى أجهزة الكاميرات المنطقية التي تتيح ميزة "فيديو 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. كاميرا خارجية

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

• وقد يتضمن ذلك دعمًا لكاميرا خارجية ليست بالضرورة متصلة دائمًا.

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

• يجب أن يفصح [C-1-1] عن العلامة الخاصة بميزات المنصة android.hardware.camera.external وandroid.hardware camera.any.
• [C-1-2] يجب أن يتوافق مع فئة الفيديو عبر USB (UVC 1.0 أو الإصدارات الأحدث) في حال اتصال الكاميرا الخارجية من خلال منفذ مضيف USB.
• [C-1-3] يجب اجتياز اختبارات CTS للكاميرا باستخدام جهاز كاميرا خارجي متصل. تتوفّر تفاصيل اختبار CTS للكاميرا على source.android.com.
• "يجب أن تكون متوافقة" مع عمليات ضغط الفيديو مثل MJPEG، وذلك لنقل عمليات البث غير المرمّزة بجودة عالية (أي مجموعات بث الصور الأولية أو المضغوطة بشكل مستقل).
• قد تتوافق مع عدة كاميرات.
• قد يتم دعم ترميز الفيديو المستند إلى الكاميرا.

إذا كان ترميز الفيديو المستند إلى الكاميرا متوافقًا:

• [C-2-1] يجب أن تتوفّر إمكانية الوصول إلى البث المتزامن غير المرمّز / MJPEG (QVGA أو بدرجة دقة أعلى) من خلال تطبيق الجهاز.

7.5.4. سلوك واجهة برمجة التطبيقات للكاميرا

يشتمل Android على حزمتَين من واجهة برمجة التطبيقات للوصول إلى الكاميرا، وهما واجهة برمجة التطبيقات android.hardware.camera2 الجديدة التي تعرض للتطبيق التحكّم في الكاميرا على مستوى أقل، بما في ذلك تدفقات البث/الانفجار الفعال بدون نسخ، وعناصر التحكّم في كل إطار، للضوء والاكتساب، وزيادة توازن اللون الأبيض، وتحويل الألوان، وإزالة التشويش، وزيادة الحدة، وغير ذلك.

تم وضع علامة إيقاف حزمة واجهة برمجة التطبيقات القديمة، android.hardware.Camera، على أنها متوقفة في الإصدار Android 5.0، ولكن ستظل متاحة للتطبيقات لاستخدامها. يجب أن تضمن عمليات تنفيذ أجهزة 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، ويتم تمرير بيانات البايت[] إلى onPreviewFrame(). بمعنى آخر، يجب أن يكون NV21 هو الإعداد التلقائي.
• يجب أن يتوافق [C-0-3] مع تنسيق YV12 (كما يُشار إليه في الثابت android.graphics.ImageFormat.YV12) في معاينات الكاميرا لكلّ من الكاميرا الأمامية والخلفية من أجل android.hardware.Camera. (قد يستخدم برنامج ترميز الفيديو والكاميرا في الجهاز أيّ تنسيق بكسل أصلي، ولكن يجب أن يتيح تنفيذ الجهاز التحويل إلى YV12).
• يجب أن يتوافق [C-0-4] مع android.hardware.ImageFormat.YUV_420_888 و android.hardware.ImageFormat.JPEG كمخرجات من خلال واجهة برمجة التطبيقات android.media.ImageReader API على أجهزة 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 عند التقاط صورة جديدة بواسطة الكاميرا وإضافة إدخال الصورة إلى متجر الوسائط.
• [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.

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] مع مساحة التخزين المشتركة المُثبَّتة تلقائيًا، بعبارات أخرى "خارج الصندوق"، بغض النظر عمّا إذا كانت مساحة التخزين مُنفَّذة على أحد مكوّنات وحدة التخزين الداخلية أو على وسيط تخزين قابل للإزالة (مثل فتحة بطاقة رقمية آمنة).
• [C-0-3] يجب تثبيت مساحة التخزين المشتركة للتطبيق مباشرةً على مسار Linux sdcard أو تضمين رابط رمزي لنظام التشغيل Linux من sdcard إلى نقطة التثبيت الفعلية.
• [C-0-4] يجب تفعيل التخزين الفرعي تلقائيًا لجميع التطبيقات التي تستهدف المستوى 29 من واجهة برمجة التطبيقات أو المستويات الأعلى، باستثناء الحالات التالية:
  • عندما طلب التطبيق android:requestLegacyExternalStorage="true" في ملف البيان الخاص به
• يجب [C-0-5] إخفاء البيانات الوصفية للمواقع الجغرافية، مثل علامات Exif لنظام تحديد المواقع العالمي (GPS)، التي يتم تخزينها في ملفات الوسائط عند الوصول إلى هذه الملفات من خلال MediaStore، إلا إذا كان تطبيق الاتصال لديه إذن ACCESS_MEDIA_LOCATION.

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

• وحدة تخزين قابلة للإزالة ويمكن للمستخدمين الوصول إليها، مثل فتحة بطاقة رقمية آمنة (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.

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] يجب أن يستخدم المنفذ شكل جهاز USB مصغر-B أو Micro-AB أو من النوع C. يُنصَح بشدة بأن تستوفي أجهزة Android الحالية والجديدة هذه المتطلبات حتى يكون بإمكانهم الترقية إلى إصدارات الأنظمة الأساسية المستقبلية.
• [C-SR-2] يجب أن يكون المنفذ في الجزء السفلي من الجهاز (وفقًا للاتجاه الطبيعي) أو تمكين تدوير شاشة البرنامج لجميع التطبيقات (بما في ذلك الشاشة الرئيسية)، بحيث يتم رسم الشاشة بشكل صحيح عندما يتم توجيه الجهاز مع المنفذ في الأسفل. يُنصَح بشدة باستيفاء هذه المتطلبات على أجهزة Android الحالية والجديدة حتى تتمكن هذه الأجهزة من الترقية إلى إصدارات الأنظمة الأساسية المستقبلية.
• [C-SR-3] يجب توفير إمكانية رسم تيار بقوة 1.5 أمبير أثناء اهتزاز HS وحركة المرور كما هو محدد في مواصفات شحن بطارية USB، النسخة 1.2. يُنصَح بشدة بأن تستوفي أجهزة Android الحالية والجديدة هذه المتطلبات حتى يكون بإمكانهم الترقية إلى إصدارات الأنظمة الأساسية المستقبلية.
• [C-SR-4] يُنصح بشدة بعدم استخدام طرق الشحن الخاصة التي تعمل على تعديل الجهد الكهربائي للجهد الكهربائي (Vbus) بما يتجاوز المستويات التلقائية، أو تغيير أدوار الحوض/المصدر على هذا النحو، وقد يؤدي ذلك إلى حدوث مشاكل في إمكانية التشغيل التفاعلي مع الشواحن أو الأجهزة التي تتوافق مع طرق "تسليم الطاقة عبر USB" العادية. يُشار إلى ذلك باسم "مقترَح بشدة"، ولكنّنا في إصدارات Android المستقبلية قد نطلب أن تتيح جميع الأجهزة من النوع C إمكانية التشغيل التفاعلي الكامل مع أجهزة الشحن العادية من النوع C.
• [C-SR-5] يُنصح بشدة بإتاحة وظيفة "الشحن الفائق" للبيانات وتبديل أدوار الطاقة عند توافقهما مع وضع مضيف USB من النوع C ومنفذ USB.
• "يجب أن" يوفّر ذلك "تسليم الطاقة" لشحن الجهد العالي وإتاحة الأوضاع البديلة مثل العرض الخارجي.
• يجب تنفيذ واجهة برمجة تطبيقات "الملحق المفتوح لنظام Android" (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 الطرفية العادية. بمعنى آخر، يجب أن:
  • توفّر منفذ من النوع C أو منفذ على الجهاز مع كابلات تتوافق مع منفذ خاص على الجهاز مع منفذ USB عادي من النوع C (جهاز USB من النوع C)
  • توفّر منفذ من النوع A على الجهاز أو منفذ مزوّد بكابلات لتعديل منفذ خاص في الجهاز مع منفذ USB عادي من النوع A
  • توفّر منفذ Micro-AB على الجهاز يجب أن يتم شحنه مزودًا بكابل يتوافق مع منفذ من النوع A القياسي.
• [C-1-3] يجب ألا يتم شحنه مع محوّل يحوّل من منافذ USB من النوع A أو منافذ ميكرو-AB إلى منفذ من النوع C (وعاء).
• [C-SR-1] يُنصَح بشدة بتطبيق USB audio class كما هو موثّق في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
• يجب أن يتم توفير شحن جهاز USB الطرفي المتصل أثناء وضع المضيف، والإعلان عن مصدر تيار لا يقل عن 1.5 أمبير على النحو الموضح في قسم "معلمات الإنهاء" في مراجعة مواصفات كابل USB من نوع C ومواصفات الموصل 1.2 لموصلات USB من نوع C أو استخدام النطاق الحالي لإخراج منفذ الشحن السريع(CDP) على النحو الموضح في مواصفات موصّل USB من نوع AB-C.
• "يجب" تنفيذ معايير USB من نوع C واعتمادها.

إذا كانت عمليات تنفيذ الجهاز تتضمّن منفذ USB متوافق مع وضع المضيف وفئة صوت USB، سيتم إجراء ما يلي:

• [C-2-1] يجب أن يتوافق مع فئة USB HID.
• يجب أن يتيح [C-2-2] رصد وربط حقول بيانات HID التالية المحدّدة في جداول استخدام واجهة USB HID وطلب استخدام أوامر Voice مع KeyEvent الثابت على النحو التالي:
  • معرِّف استخدام صفحة الاستخدام (0xC) (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • معرّف استخدام صفحة الاستخدام (0xC) (0x0E9): KEYCODE_VOLUME_UP
  • معرِّف استخدام صفحة الاستخدام (0xC) (0x0EA): KEYCODE_VOLUME_DOWN
  • معرّف استخدام صفحة الاستخدام (0xCF) (0x0CF): KEYCODE_VOICE_ASSIST

إذا كانت عمليات تنفيذ الجهاز تتضمن منفذًا USB يتوافق مع وضع المضيف وإطار عمل الوصول إلى مساحة التخزين (SAF)، سيتم إجراء ما يلي:

• يجب أن يتعرّف [C-3-1] على أي أجهزة بروتوكول نقل الوسائط (MTP) المتصلة عن بُعد ويتيح الوصول إلى محتواها من خلال الأهداف ACTION_GET_CONTENT وACTION_OPEN_DOCUMENT وACTION_CREATE_DOCUMENT. .

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

• [C-4-1] يجب أن تنفذ وظيفة "منفذ الدور المزدوج" على النحو المحدّد في مواصفات USB من النوع C (الفقرة 4.5.1.3.3). بالنسبة إلى منافذ الدور المزدوجة، يمكن أن يتم إيقاف ميزة "اكتشاف حوض USB" (وضع المضيف) تلقائيًا في الأجهزة التي تتضمّن مقبس صوت مقاس 3.5 ملم، ولكن يجب أن يتمكّن المستخدم من تفعيلها.
• [C-SR-2] يُنصَح بشدة بأن يتوافق مع DisplayPort، ويجب أن يتوافق مع معدلات البيانات الفائقة السرعة (USB) وننصحك بشدة بإتاحة توصيل الطاقة لتبديل أدوار البيانات والطاقة.
• [C-SR-3] يُنصح بشدة بعدم إتاحة وضع ملحق مهايئ الصوت كما هو موضّح في الملحق "أ" حول المراجعة 1.2 لمواصفات كابل وموصّل USB من نوع C.
• يجب تنفيذ نموذج Try.* الأكثر ملاءمة لعامل شكل الجهاز. على سبيل المثال، "ينبغي" أن يستخدم جهاز محمول باليد نموذج Try.SNK.

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. لا يُعد دعم إخراج الصوت عبر البروتوكولات المستندة إلى الراديو، مثل البلوتوث أو WiFi أو الشبكة الخلوية، مؤهلاً بما في ذلك "منفذ إخراج".

7.8.2.1. منافذ الصوت التناظرية

ولكي تتوافق عمليات التنفيذ مع سمّاعات الرأس وملحقات الصوت الأخرى التي تستخدم مقبس صوت مقاس 3.5 ملم في منظومة Android المتكاملة، يجب مراعاة ما يلي في حال توفُّر منفذ صوت تناظري واحد أو أكثر:

• [C-SR-1] يُنصح بشدة بتضمين منفذ واحد على الأقل من منافذ الصوت ليكون مقبس صوت بأربعة موصّلات مقاس 3.5 ملم.

إذا كانت عمليات تنفيذ الأجهزة تحتوي على مقبس صوت مقاس 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] يُنصح بشدة بإتاحة تسجيل الصوت من سماعات استريو مع ميكروفون.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقبس صوت مقاس 4 موصّلات مقاس 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 على "صحيح"، يجب استيفاء المتطلبات التالية في مصدرَي الصوت 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 صحيحة:

• [C-2-1] يجب ألا تقل استجابة مكبّر الصوت عند 18.5 كيلوهرتز إلى 20 كيلوهرتز عن 40 ديسيبل أسفل الاستجابة عند 2 كيلوهرتز.

7.8.4. سلامة الإشارة

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

• يجب توفير مسار إشارة صوتية خالية من أي خلل لكل من مجموعات بث الإدخال والمخرجات على الأجهزة المحمولة باليد، وذلك من خلال عدم وجود أعطال يتم قياسها أثناء اختبار مدته دقيقة واحدة لكل مسار. أجرِ الاختبار باستخدام أداة اختبار OboeTester : "اختبار أعطال مبرمَجة".

يتطلب الاختبار استخدام مفتاح إلكتروني لاسترجاع الصوت يُستخدَم مباشرةً في مقبس 3.5 ملم و/أو مع محوّل مزوّد بمنفذَي USB-C إلى 3.5 ملم. يجب اختبار جميع منافذ إخراج الصوت.

يتيح تطبيق OboeTester حاليًا استخدام المسارات الصوتية AAudio، لذا ينبغي اختبار التركيبات التالية للتأكد من خلوها من الأخطاء الفنية باستخدام AAudio:

وضع الأداء	المشاركة	معدّل النسبة المئوية خارج العينة	في تشان	ترانيم الفرقعة
وقت استجابة سريع	حصري	غير محدّد	1	2
وقت استجابة سريع	حصري	غير محدّد	2	1
وقت استجابة سريع	مشترك	غير محدّد	1	2
وقت استجابة سريع	مشترك	غير محدّد	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 هرتز جيب.

محوّل طاقة	60	معدّل الضوضاء الديناميكي
مكبّر صوت أساسي مدمج، يتم قياسه باستخدام ميكروفون مرجعي خارجي	< 3.0%	>= 50 ديسيبل
ميكروفون أساسي مدمج، يتم قياسه باستخدام مكبّر صوت مرجعي خارجي	< 3.0%	>= 50 ديسيبل
مقابس تناظرية مدمجة مقاس 3.5 ملم، تم اختبارها باستخدام محوّل استرجاعي	أقل من %1	>= 60 ديسيبل
محوّلات USB المرفقة مع الهاتف، وتم اختبارها باستخدام محوّل الاسترجاع	< 1.0%	>= 60 ديسيبل

7.9 الواقع الافتراضي

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

7.9.1. وضع الواقع الافتراضي

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

7.9.2. وضع الواقع الافتراضي - أداء عالي

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

• [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، وعرض الإضافات المتاحة في القائمة.
• [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] يُنصَح باستخدامها بشدة لإتاحة تخصيص AHardwareBuffer مع أكثر من طبقة واحدة وعلامات وتنسيق محدّد في C-1-10
• [C-1-11] يجب أن يتيح فك ترميز H.264 بمعدّل لا يقل عن 3840 × 2160 ميغابت في الثانية بمعدّل 30 لقطة في الثانية، مضغوطًا إلى 40 ميغابت في الثانية في المتوسط (ما يعادل 4 مثيلات من 1920 × 1080 بمعدّل 30 لقطة في الثانية - 10 أو مثالَين بمعدّل 1920 ميغابت في الثانية).
• [C-1-12] يجب أن يتوافق مع HEVC وVP9، ويجب أن يكون قادرًا على فك الترميز بمعدّل لا يقل عن 1920 × 0 ميغابت في الثانية بمعدل 0 × 0 ميغابت في الثانية بمعدل 30 × 0 ميغابت في الثانية و30 لقطة في الثانية مضغوطة إلى متوسط 10 ميغابت في الثانية، ومن المفترض أن يكون قادرًا على فك الترميز 3840 × 2160 بمعدل 30 لقطة في الثانية
• [C-1-13] يجب أن يتوافق مع واجهة برمجة تطبيقات HardwarePropertiesManager.getDeviceTemperatures ويعرض قيمًا دقيقة لدرجة حرارة الجلد.
• [C-1-14] يجب أن يحتوي على شاشة مضمّنة، ويجب أن تبلغ درجة دقته 1920 × 1080 على الأقل.
• [C-SR-6] يُنصح بشدة بأن تكون درجة دقة العرض بها لا تقل عن 2560 × 1440.
• [C-1-15] يجب أن يتم تحديث الشاشة بتردد 60 هرتز على الأقل أثناء استخدام وضع الواقع الافتراضي (VR).
• [C-1-17] يجب أن تكون الشاشة متوافقة مع وضع التدرُّب المنخفض لمدة تقل عن 5 ملي ثانية أو أقل، وذلك يعني أنّ مقدار الاستمرارية هو مقدار الوقت الذي تنبعث منه وحدة البكسل الضوء.
• [C-1-18] يجب أن يتوافق مع Bluetooth 4.2 وBluetooth LE Data Length الفقرة 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 لعرض أرقام نوى وحدة المعالجة المركزية (CPU) التي تقتصر على التطبيق الذي يعمل في المقدّمة.

إذا كان الدعم الحصري متاحًا، فإن الطريقة الأساسية:

• [C-2-1] يجب ألا يسمح بتشغيل أي عمليات أخرى في مساحة المستخدم عليه (باستثناء برامج تشغيل الأجهزة التي يستخدمها التطبيق)، ولكن قد يسمح بتشغيل بعض عمليات kernel حسب الضرورة.

7.10. أجهزة تعمل باللمس

يُرجى الاطّلاع على الفقرة 2.2.1 لمعرفة المتطلبات الخاصة بالأجهزة.

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. أوضاع توفير الطاقة

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

• [C-1-1] يجب ألا يحيد عن تنفيذ AOSP في ما يتعلق بخوارزميات التشغيل والصيانة والتنشيط واستخدام إعدادات النظام العامة أو DeviceConfig وضعي توفير الطاقة في وضع الاستعداد للتطبيقات والقيلولة.
• [C-1-2] يجب ألا تنحرف عن تنفيذ AOSP لاستخدام الإعدادات العامة أو DeviceConfig لإدارة تقييد المهام والمنبّه والشبكة للتطبيقات في كل مجموعة من أجل وضع الاستعداد للتطبيقات.
• [C-1-3] يجب ألا ينحرف عن تنفيذ AOSP في ما يتعلق بعدد حزم App Standby المستخدَمة في App Standby.
• [C-1-4] يجب تنفيذ حزم تطبيقات الاستعداد للتطبيقات وميزة "القيلولة" كما هو موضّح في إدارة الطاقة.
• [C-1-5] يجب عرض true لمدة PowerManager.isPowerSaveMode() عندما يكون الجهاز في وضع توفير الطاقة.
• [C-1-6] يجب أن تتوفر للمستخدم قدرة على عرض جميع التطبيقات المستثناة من وضعَي توفير الطاقة في وضع الاستعداد لاستخدام التطبيقات وتقنية القيلولة أو أي تحسينات للبطارية ويجب أن تنفّذ نية ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS أن تطلب من المستخدم السماح لتطبيق بتجاهل تحسينات البطارية.
• [C-SR-1] يُنصَح باستخدامها بشدة لإتاحة إمكانية تفعيل ميزة "توفير شحن البطارية" وإيقافها للمستخدمين.
• [C-SR-2] يُنصَح باستخدامها بشدة لتمكين المستخدمين من عرض جميع التطبيقات المستثناة من وضعَي "تطبيقات الاستعداد" و"القيلولة" لتوفير الطاقة.

إذا كانت عمليات تنفيذ الأجهزة توسِّع ميزات إدارة الطاقة التي يتم تضمينها في AOSP وتطبّق تلك الإضافة قيودًا أكثر صرامة من مجموعة بيانات Rare App Standby (مجموعة أدوات Rare App Standby)، يمكنك الرجوع إلى الفقرة 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 أو تشغيل وحدة المعالجة المركزية (CPU) من خلال PARTIAL_WAKE_LOCK، يجب ألا يدخل الجهاز في حالة S3 إلا إذا اتخذ المستخدم إجراءً صريحًا، كما هو موضّح في C-1-1، لوضع الجهاز في حالة غير نشط. وبالعكس، عند تشغيل مهمة تنفّذها التطبيقات التابعة لجهات خارجية من خلال Jobscheduler أو تسليم خدمة المراسلة عبر السحابة الإلكترونية من Firebase إلى تطبيقات تابعة لجهات خارجية، يجب أن يخرج الجهاز من حالة S3 ما لم يضع المستخدم الجهاز في حالة غير نشطة. هذه ليست أمثلة شاملة، وينفذ AOSP إشارات استيقاظ شاملة من هذه الحالة.

8.4. محاسبة استهلاك الطاقة

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

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

• [C-SR-1] يُنصح بشدة بتوفير ملف تعريفي للطاقة لكل مكوّن يحدّد قيمة الاستهلاك الحالية لكل مكوّن من مكونات الجهاز واستنزاف البطارية التقريبي الناتج عن هذه المكونات بمرور الوقت كما هو موضّح في موقع "مشروع مفتوح المصدر لنظام Android".
• [C-SR-2] يُنصح بشدة بالإبلاغ عن جميع قيم استهلاك الطاقة بالمللي أمبير في الساعة (mAh).
• [C-SR-3] يُنصح بشدة بالإبلاغ عن استهلاك طاقة وحدة المعالجة المركزية (CPU) حسب المُعرّف الفريد لكل عملية. يستوفي "المشروع المفتوح المصدر لنظام Android" المتطلبات من خلال تنفيذ وحدة kernel uid_cputime.
• [C-SR-4] يُنصح بشدة بإتاحة استخدام الطاقة هذا من خلال أمر Shell adb shell dumpsys batterystats لمطوّر التطبيق.
• يجب أن يُنسب إلى مكون الجهاز نفسه إذا لم يتمكن من إسناد استخدام الطاقة لمكوِّن الجهاز إلى أحد التطبيقات.

8.5. الأداء المتسق

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

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

• [C-0-1] يجب الإبلاغ بدقة عن دعم "وضع الأداء المستدام" من خلال طريقة واجهة برمجة التطبيقات PowerManager.isSustainedPerformanceModeSupported().

• يجب أن يتوافق مع "وضع الأداء المستدام".

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

• [C-1-1] يجب أن يتم توفير مستوى أداء ثابت للتطبيق الذي يعمل في المقدّمة لمدة 30 دقيقة على الأقل عندما يطلبه التطبيق.
• [C-1-2] يجب أن يلتزم بواجهة برمجة تطبيقات Window.setSustainedPerformanceMode() وواجهات برمجة التطبيقات الأخرى ذات الصلة.

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

• "ينبغي" توفير وحدة أساسية واحدة حصرية على الأقل يمكن حجزها بواسطة التطبيق الذي يعمل في المقدّمة.

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

• [C-2-1] يجب أن يُبلغ عبر طريقة واجهة برمجة التطبيقات Process.getExclusiveCores() أرقام تعريف النواة الحصرية التي يمكن حجزها من خلال التطبيق الذي يعمل في المقدّمة.
• [C-2-2] يجب ألا يسمح بتشغيل أي عمليات خاصة بمساحة المستخدم باستثناء برامج تشغيل الأجهزة التي يستخدمها التطبيق على النوى الحصرية، ولكن قد يسمح بتشغيل بعض عمليات kernel حسب الضرورة.

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

• [C-3-1] يجب عرض قائمة فارغة من خلال طريقة واجهة برمجة التطبيقات Process.getExclusiveCores().

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] يجب منح الأذونات التي تتضمّن protectionLevel بقيمة PROTECTION_FLAG_PRIVILEGED يجب ألا يتم منح الأذونات إلا للتطبيقات المثبَّتة مسبقًا في المسارات المميّزة لصورة النظام (وكذلك ملفات APK) وأن تكون ضمن المجموعة الفرعية من الأذونات المُدرَجة في القائمة المسموح بها صراحةً لكل تطبيق. تستوفي عملية تنفيذ AOSP هذا الشرط من خلال قراءة واستخدام أذونات السماح لكل تطبيق من الملفات في المسار المسموح به واعتماده كأذونات وصول إلى كل تطبيق في المسار المسموح بهetc/permissions/.system/priv-app

أما الأذونات التي لها مستوى حماية من الخطورة، فهي أذونات التشغيل. تطلب التطبيقات التي يكون حجمها targetSdkVersion > 22 الوصول إليها في وقت التشغيل.

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

• يجب أن يعرض [C-0-3] واجهة مخصّصة للمستخدم لتحديد ما إذا كان يريد منح أذونات التشغيل المطلوبة، كما يجب توفير واجهة للمستخدم لإدارة أذونات التشغيل.
• يجب أن يتضمّن [C-0-4] عملية تنفيذ واحدة فقط لواجهتَي المستخدم. إذا كان تنفيذ الجهاز متوافقًا مع جهاز مصاحب، من الممكن أن يوفر الجهاز المصاحب واجهة إضافية.

• [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. على سبيل المثال، تتطلب TechnicalManager#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] يجب ألا يحدد الأدوار المكررة أو الوظيفية الكاملة للأدوار المحددة بواسطة المنصة.

إذا أبلغت الأجهزة عن 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] يجب عرض بيان إخلاء مسؤولية أثناء عملية إعداد الجهاز المُدار بالكامل (إعداد مالك الجهاز) يفيد بأنّ مشرف تكنولوجيا المعلومات سيتمكّن من السماح للتطبيقات بالتحكّم في الإعدادات على الهاتف، بما في ذلك الميكروفون والكاميرا والموقع الجغرافي، مع إتاحة خيارات للمستخدم لمواصلة الإعداد أو الخروج من الإعداد ما لم يوقف المشرف التحكّم في الأذونات على الجهاز.

في حال تثبيت عمليات تنفيذ على الجهاز مسبقًا لأي حِزم تحمل أيًا من أدوار System UI Intelligence أو System Ambient Audio Intelligence أو System Audio Intelligence أو System Notification Intelligence أو System Text Intelligence أو System Visual Intelligence، ستكون الحِزم:

• يجب أن يستوفي [C-4-1] جميع المتطلبات الموضّحة لعمليات تنفيذ الأجهزة في القسم "9.8.6 تسجيل المحتوى".
• [C-4-2] يجب ألا يكون لديه إذن android.permission.INTERNET. وأكثر صرامة من تلك المقترحة بشدة في الفقرة 9.8.6.
• [C-4-3] يجب ألا يتم الربط بالتطبيقات الأخرى، باستثناء تطبيقات النظام التالية: البلوتوث وجهات الاتصال والوسائط والاتصال الهاتفي وSystemUI والمكونات التي توفر واجهات برمجة تطبيقات الإنترنت.وهذا أكثر صرامة من التطبيقات الموصى بها بشدة الواردة في الفقرة 9.8.6.

9.2. المعرّف الفريد وعزل العمليات

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

• [C-0-1] يجب أن يتوافق مع نموذج وضع الحماية لتطبيقات Android، والذي يتم فيه تشغيل كل تطبيق كمعرّف فريد فريد على نظام Unixstyle وفي عملية منفصلة.
• [C-0-2] يجب أن يتيح تشغيل تطبيقات متعددة باستخدام رقم تعريف مستخدم Linux نفسه، بشرط أن يتم توقيع التطبيقات وإنشائها بشكل صحيح، على النحو المحدّد في مرجع الأمان والأذونات.

9.3. أذونات نظام الملفات

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

• [C-0-1] يجب أن يتوافق مع نموذج أذونات الوصول إلى ملفات Android على النحو المحدّد في مرجع الأمان والأذونات.

9.4. بيئات التنفيذ البديلة

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

• [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) أو السماح بإدارة مالك الجهاز بدون إزالة الملف الشخصي الإضافي للمستخدم أولاً.

9.6. تحذير بشأن الرسائل القصيرة برسوم إضافية

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

إذا كانت عمليات تنفيذ الأجهزة تشير إلى توافقها مع android.hardware.telephony، سيحدث ما يلي:

• [C-1-1] يجب تحذير المستخدمين قبل إرسال رسالة SMS إلى الأرقام التي تم تحديدها من خلال التعبيرات العادية المحدّدة في ملف /data/misc/sms/codes.xml على الجهاز. يوفر المشروع المفتوح المصدر لنظام Android التنفيذ الذي يفي بهذا المطلب.

9.7. ميزات الأمان

يجب أن تضمن عمليات تنفيذ الأجهزة الامتثال لميزات الأمان في كل من النواة والنظام الأساسي كما هو موضَّح أدناه.

يتضمن "وضع الحماية لنظام التشغيل Android" ميزات تستخدم نظام Linux المعزز للأمان (SELinux) الخاص بالتحكم الإلزامي في الوصول (MAC) ووضع الحماية seccomp وميزات الأمان الأخرى في نواة Linux. عمليات تنفيذ الأجهزة:

• [C-0-1] يجب الحفاظ على التوافق مع التطبيقات الحالية، حتى عند تنفيذ SELinux أو أي ميزات أمان أخرى تحت إطار عمل Android.
• يجب ألا يكون لدى [C-0-2] واجهة مستخدم مرئية عند رصد انتهاك أمني وحظره بنجاح من خلال ميزة الأمان التي يتم تنفيذها أسفل إطار عمل Android، ولكن قد تظهر واجهة مستخدم مرئية عند حدوث انتهاك أمني غير محظور أدى إلى نجاح الاستغلال.
• [C-0-3] يجب ألا تجعل SELinux أو أي ميزات أمان أخرى تم تنفيذها أسفل إطار عمل Android قابلة للتهيئة للمستخدم أو مطوّر التطبيق.
• [C-0-4] يجب ألا يسمح لتطبيق يمكن أن يؤثر على تطبيق آخر من خلال واجهة برمجة التطبيقات (مثل واجهة برمجة التطبيقات لإدارة الأجهزة) في ضبط سياسة تعطل التوافق.
• يجب أن يقسّم [C-0-5] إطار عمل الوسائط إلى عمليات متعددة ليكون من الممكن منح إمكانية الوصول بشكل أكثر تحديدًا لكل عملية كما هو موصوف في موقع "مشروع مفتوح المصدر لنظام Android".
• يجب أن ينفذ [C-0-6] آلية وضع حماية لتطبيق kernel تتيح تصفية طلبات النظام باستخدام سياسة قابلة للتهيئة من البرامج المتعددة السلاسل. يلبي "المشروع المفتوح المصدر لنظام Android" هذا الشرط من خلال تفعيل seccomp-BPF من خلال مزامنة سلسلة المحادثات (TSYNC) كما هو موضّح في قسم "ضبط Kernel" على source.android.com.

تعتبر ميزات سلامة النواة والحماية الذاتية جزءًا لا يتجزأ من أمان Android. عمليات تنفيذ الأجهزة:

• [C-0-7] يجب تنفيذ آليات الحماية من تجاوز سعة المخزن المؤقت لحزمة kernel. ومن أمثلة هذه الآليات CC_STACKPROTECTOR_REGULAR وCONFIG_CC_STACKPROTECTOR_STRONG.
• [C-0-8] يجب تنفيذ إجراءات حماية صارمة في ذاكرة النواة عندما يكون الرمز التنفيذي للقراءة فقط، والبيانات المخصصة للقراءة فقط غير قابلة للتنفيذ وغير قابلة للكتابة، والبيانات القابلة للكتابة غير قابلة للتنفيذ (مثل CONFIG_DEBUG_RODATA أو CONFIG_STRICT_KERNEL_RWX).
• يجب أن ينفِّذ [C-0-9] فحص حدود حجم الكائن الثابت والديناميكي للتحقّق من النُسخ بين مساحة المستخدم ومساحة kernel-space (مثل CONFIG_HARDENED_USERCOPY) على الأجهزة التي يتم شحنها في الأصل باستخدام المستوى 28 من واجهة برمجة التطبيقات أو أعلى.
• [C-0-10] يجب ألا يتم تنفيذ ذاكرة مساحة المستخدم عند التنفيذ في وضع kernel (مثل PXN للأجهزة، أو التي تتم محاكاتها عبر CONFIG_CPU_SW_DOMAIN_PAN أو CONFIG_ARM64_SW_TTBR0_PAN) على الأجهزة التي يتم الشحن فيها في الأصل باستخدام المستوى 28 من واجهة برمجة التطبيقات أو المستويات الأعلى.
• [C-0-11] يجب ألا تتم قراءة أو كتابة ذاكرة مساحة المستخدم في النواة خارج واجهات برمجة التطبيقات للوصول العادي إلى نسخة المستخدم (مثل رقم الحساب الدائم للأجهزة أو التي تتم محاكاتها عبر 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] يُنصح بشدة بالاحتفاظ ببيانات kernel التي تتم كتابتها فقط أثناء وضع علامة للقراءة فقط بعد الإعداد (على سبيل المثال __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] يُنصح بشدة بعدم إيقاف ميزة Control-Flow Integrity (CFI) أو حزمة Shadow Call Stack (SCS) أو Integer Overflow Sanitization (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 والنطاقات الخاصة بالأجهزة/المورّدين.
• [C-1-5] يجب تشغيل تطبيقات الجهات الخارجية التي تستهدف المستوى 28 من واجهة برمجة التطبيقات أو المستوى الأعلى في أماكن وضع الحماية SELinux لكل تطبيق مع فرض قيود SELinux على كل تطبيق على دليل البيانات الخاص بكل تطبيق.
• "يجب أن" يتم الاحتفاظ بسياسة SELinux التلقائية المتوفّرة في مجلد "النظام/sepolicy" ضِمن "مشروع مفتوح المصدر لنظام Android" الرئيسية، ولا يتم إضافتها إلا إلى هذه السياسة من أجل عملية الإعداد الخاصة بالأجهزة.

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

• [C-2-1] يجب استخدام نظام إلزامي للتحكم في الوصول يعادل نظام SELinux.

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

• [C-SR-9] يُنصح بشدة بعزل كل جهاز إدخال/إخراج متوافق مع قانون الأسواق الرقمية، باستخدام وحدة 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 أو أنواع أخرى من الأجهزة).
• [C-SR-12] يُنصح بشدة باستخدام أدوات اكتشاف أخطاء الذاكرة في إنتاج مثل MTE وGWP-ASan وKFENCE.

في حال كانت عمليات تنفيذ الجهاز تستخدم بيئة التنفيذ الموثوقة (TEE) المستندة إلى Arm TrustZone، سيتم إجراء ما يلي:

• [C-SR-13] يُنصَح بشدة باستخدام بروتوكول عادي لمشاركة الذاكرة، بين Android وTEE، مثل Arm Firmware Groups for Armv8-A (FF-A).
• [C-SR-14] يُنصح بشدة بقصر التطبيقات الموثوق بها على الوصول إلى الذاكرة التي تمت مشاركتها معها صراحةً عبر البروتوكول أعلاه. إذا كان الجهاز متوافقًا مع مستوى استثناء Arm S-EL2، يجب فرض ذلك من خلال مدير الأقسام الآمن. بخلاف ذلك، ينبغي أن يتم فرض ذلك من خلال نظام التشغيل TEE OS.

9.8. الخصوصية

9.8.1. سجلّ الاستخدام

يخزِّن Android سجلّ خيارات المستخدم ويدير هذا السجلّ من خلال UsageStatsManager.

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

• [C-0-1] يجب أن يحتفظ بفترة احتفاظ معقولة بسجلّ المستخدمين هذا.
• [C-SR-1] يُنصَح بشدة بالحفاظ على فترة الاحتفاظ بالبيانات التي تبلغ 14 يومًا وفقًا للإعدادات التلقائية في عملية تنفيذ بروتوكول AOSP.

يخزِّن Android أحداث النظام باستخدام معرّفات StatsLog، ويدير هذه السجلّ من خلال StatsManager وIncidentManager System API.

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

• يجب أن يتضمّن [C-0-2] فقط الحقول الموضوع عليها علامة DEST_AUTOMATIC في تقرير الحوادث الذي تم إنشاؤه من خلال فئة System API IncidentManager.
• [C-0-3] يجب ألا يستخدم معرِّفات أحداث النظام لتسجيل أي حدث آخر غير ما هو موضح في مستندات حزمة تطوير البرامج (SDK) StatsLog. إذا تم تسجيل أحداث إضافية للنظام، قد تستخدم هذه الأحداث معرّف Atom مختلفًا في النطاق بين 100,000 و200,000.

9.8.2. يتم التسجيل

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

• [C-0-1] يجب ألا يتم مسبقًا تحميل أو توزيع مكونات البرامج خارج الصندوق والتي ترسل معلومات المستخدم الخاصة (مثل ضغطات المفاتيح أو النص المعروض على الشاشة أو تقرير الأخطاء) خارج الجهاز بدون موافقة المستخدم أو الإشعارات المستمرة الواضحة.
• يجب أن يعرض [C-0-2] ويحصل على موافقة صريحة من المستخدم تسمح بالتقاط أي معلومات حساسة يتم عرضها على شاشة المستخدم عند تفعيل بث الشاشة أو تسجيل الشاشة من خلال MediaProjection أو واجهات برمجة التطبيقات التابعة لنا. يجب ألا يتيح للمستخدمين إمكانية إيقاف عرض موافقة المستخدم في المستقبل.
• يجب أن يتلقّى [C-0-3] إشعارًا مستمرًا للمستخدم أثناء تفعيل بث الشاشة أو تسجيل الشاشة. يلبي AOSP هذا الشرط من خلال إظهار رمز إشعار مستمر في شريط الحالة.

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

• [C-1-1] يجب إرسال إشعار إلى المستخدم باستمرار عند تفعيل هذه الوظيفة وتسجيلها بشكل نشط.

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

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

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

يشير "مؤشر الكاميرا" إلى ما يظهر على الشاشة، يظهر للمستخدم باستمرار ولا يمكن حجبه، ويدرك أنّ هذه الكاميرا قيد الاستخدام (من خلال نص فريد أو لون أو رمز أو مزيج آخر من ذلك).

بعد عرض الثانية الأولى، يمكن أن يتغير المؤشر بصريًا، مثل أن يصبح أصغر، ولا يُشترط أن يظهر على أنّه تم تقديمه وفهمه في الأصل.

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

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

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

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

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

• [C-SR-4] يُنصح بشدة بعرض مؤشر الكاميرا عند وصول أحد التطبيقات إلى بيانات الكاميرا المباشرة، ولكن ليس عند وصول التطبيقات التي تملك الأدوار المذكورة في الفقرة 9.1 إلى الكاميرا فقط [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] يجب شحنه مع متجر CA جذر مستخدم فارغ.
• يجب أن يعرض [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، من خلال System API ContentCaptureService أو AugmentedAutofillService أو AppSearchGlobalManager.query، أو من خلال وسائل ملكية أخرى، آلية لعمليات تنفيذ الأجهزة من أجل تسجيل التفاعلات التالية مع بيانات التطبيقات بين التطبيقات والمستخدم:

• النصوص والرسومات المعروضة على الشاشة، بما في ذلك على سبيل المثال لا الحصر، الإشعارات وبيانات المساعدة من خلال واجهة برمجة التطبيقات AssistStructure
• بيانات الوسائط، مثل الصوت أو الفيديو، التي تم تسجيلها أو تشغيلها بواسطة الجهاز.
• أحداث الإدخال (مثل المفتاح والماوس والإيماءات والصوت والفيديو وأدوات تسهيل الاستخدام).
• أي أحداث أخرى يوفّرها تطبيق ما للنظام من خلال واجهة برمجة تطبيقات Content Capture أو واجهة برمجة التطبيقات AppSearchManager أو واجهة برمجة تطبيقات خاصة بخدمة Android وواجهة برمجة تطبيقات خاصة بها
• أي نص أو بيانات أخرى يتم إرسالها من خلال TextClassifier API إلى "أداة تصنيف النص" في النظام، أي إلى خدمة النظام لفهم معنى النص، بالإضافة إلى إنشاء الإجراءات التالية المتوقّعة استنادًا إلى النص.
• البيانات المفهرسة من خلال النظام الأساسي AppSearch، بما في ذلك على سبيل المثال لا الحصر النصوص أو الرسومات أو بيانات الوسائط أو غيرها من البيانات المشابهة.

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

• [C-1-1] يجب تشفير جميع هذه البيانات عند تخزينها في الجهاز. وقد يتم إجراء هذا التشفير باستخدام ميزة "التشفير المستند إلى ملفات Android" أو أيّ من رموز الترميز المُدرَجة على أنّها الإصدار 26 من واجهة برمجة التطبيقات أو الإصدارات الأحدث الموضّحة في Cipher SDK.
• [C-1-2] يجب ألا يتم الاحتفاظ بنسخة احتياطية من البيانات الأولية أو المشفرة باستخدام طرق الاحتفاظ بنسخة احتياطية من البيانات في جهاز Android أو أي طريقة أخرى للاحتفاظ بنسخة احتياطية.
• [C-1-3] يجب أن يتم فقط إرسال جميع هذه البيانات وسجلّ الجهاز باستخدام آلية الحفاظ على الخصوصية. يتم تعريف آلية الحفاظ على الخصوصية على أنّها "تلك التي تسمح فقط بالتحليل بشكل مجمّع وتمنع مطابقة الأحداث المسجّلة أو النتائج المشتقة للمستخدمين الفرديين". لمنع أي بيانات لكل مستخدم من التدقيق فيها (على سبيل المثال، تنفيذها باستخدام تكنولوجيا خصوصية تفاضلية، مثل RAPPOR).
• [C-1-4] يجب ألا تربط هذه البيانات بأي هوية مستخدم (مثل Account) على الجهاز، إلا بموافقة صريحة من المستخدم في كل مرة يتم فيها ربط البيانات.
• [C-1-5] يجب ألا تتم مشاركة هذه البيانات مع مكوّنات نظام التشغيل الأخرى التي لا تتوافق مع المتطلبات الموضّحة في الفقرة الحالية (9.8.6 تسجيل المحتوى)، إلّا بموافقة صريحة من المستخدم في كل مرة تتم فيها مشاركة هذه البيانات.
• [C-1-6] يجب أن يتمكّن المستخدم من محو البيانات التي تجمعها "ContentCaptureService" أو وسيلة الملكية إذا تم تخزين البيانات بأي شكل من الأشكال على الجهاز.
• يجب أن يتيح [C-1-7] للمستخدم إيقاف عرض البيانات في نظام Android الأساسي، مثل مشغّل التطبيقات، والتي يتم جمعها عبر AppSearch أو وسائل مملوكة.
• [C-SR-1] يُنصح بشدة بعدم طلب إذن INTERNET.
• [C-SR-2] يُنصح بشدة بالاتصال بالإنترنت من خلال واجهات برمجة التطبيقات المنظَّمة المستنِدة إلى تطبيقات مفتوحة المصدر ومتاحة للجميع.

إذا كانت عمليات تنفيذ الأجهزة تشمل خدمة تنفِّذ واجهة برمجة التطبيقات System API ContentCaptureService أو AppSearchManager.index أو أي خدمة خاصة تسجّل البيانات كما هو موضّح أعلاه، سيتم اتخاذ الإجراءات التالية:

• [C-2-1] يجب ألا يسمح للمستخدمين باستبدال الخدمات بتطبيق أو خدمة قابلة للتثبيت من قِبل المستخدم، كما يجب أن يسمح فقط للخدمات المثبتة مسبقًا بالحصول على هذه البيانات.
• [C-2-2] يجب ألا تسمح لأي تطبيقات أخرى غير آلية الخدمات المثبَّتة مسبقًا بالحصول على مثل هذه البيانات.
• [C-2-3] يجب أن تتوفر قدرة المستخدم على إيقاف الخدمات.
• [C-2-4] يجب ألا يتم إغفال قدرة المستخدم على إدارة أذونات Android التي تحتفظ بها الخدمات واتّباع نموذج أذونات Android على النحو الموضّح في الفقرة 9.1. الإذن.

• [C-SR-3] يُنصح بشدة بفصلها عن مكونات النظام الأخرى(مثل عدم ربط الخدمة أو معرّفات عمليات المشاركة)، باستثناء ما يلي:

  • الاتصالات الهاتفية وجهات الاتصال وواجهة مستخدم النظام والوسائط

يوفر Android، من خلال SpeechRecognizer#onDeviceSpeechRecognizer() إمكانية التعرف على الكلام على الجهاز، بدون إشراك الشبكة. يجب أن يتّبع أي استخدام لأداة SpeechRecognizer على الجهاز السياسات الموضّحة في هذا القسم.

9.8.7. الوصول إلى الحافظة

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

• [C-0-1] يجب ألا يعرض بيانات مقطوعة من الحافظة (على سبيل المثال، عبر واجهة برمجة تطبيقات ClipboardManager) ما لم يكن التطبيق التابع لجهة خارجية هو أداة IME التلقائية أو التطبيق الذي يتم التركيز عليه حاليًا.
• [C-0-2] يجب محو بيانات الحافظة بعد 60 دقيقة كحد أقصى من وضعها في حافظة أو قراءتها من الحافظة.

9.8.8. الموقع الجغرافي

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

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

• GPS/GNSS/DGPS/PPP
  • حل تحديد المواقع العالمي أو نظام التنقل العالمي عبر الأقمار الصناعية أو حل تحديد المواقع العالمي التفاضلي
  • يشمل ذلك أيضًا قياسات GNSS الأولية وحالة GNSS.
    • يمكن استنتاج الموقع الدقيق من قياسات GNSS الأولية.
• التكنولوجيات اللاسلكية التي تتضمّن معرّفات فريدة، مثل:
  • نقاط وصول WiFi (MAC أو BSSID أو Name أو SSID)
  • بلوتوث/BLE (MAC أو BSSID أو الاسم أو SSID)
  • النطاق الفائق العرض (MAC) أو معرِّف مجموعة الخدمات الأساسية (BSSID) أو الاسم أو SSID)
  • معرِّف البرج الخلوي (3G، 4G، 5G...، بما في ذلك جميع تقنيات المودم الخلوية المستقبلية التي لها معرّفات فريدة)

كنقطة مرجعية أساسية، يمكنك الاطّلاع على واجهات برمجة تطبيقات Android التي تتطلّب أذونات ACCESS_FINE_Location أو ACCESS_COARSE_Location.

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

• [C-0-1] يجب ألا يتم تفعيل/إيقاف إعدادات الموقع الجغرافي للجهاز وإعدادات البحث عن شبكات Wi-Fi/البلوتوث بدون موافقة صريحة من المستخدم أو بدء المستخدم.
• [C-0-2] يجب أن يوفر للمستخدم إمكانية الوصول إلى المعلومات المتعلقة بالموقع، بما في ذلك طلبات الموقع الأخيرة والأذونات على مستوى التطبيق واستخدام البحث عن شبكات Wi-Fi/البلوتوث لتحديد الموقع.
• يجب أن يتأكد [C-0-3] من أنّ التطبيق الذي يستخدم واجهة برمجة التطبيقات "واجهة برمجة التطبيقات لتجاوز الموقع في حالات الطوارئ" [LocationRequest.setLocationSettingsSettingsignored()] هي جلسة طوارئ يبدأها المستخدم (مثل الاتصال برقم 911 أو إرسال رسالة نصية إلى 911). في المقابل، بالنسبة إلى السيارات، يمكن أن تبدأ مركبة جلسة طوارئ بدون تفاعل مستخدم نشط في حال رصد حادث سير أو حادث سير (لتلبية متطلبات eCall مثلاً).
• [C-0-4] يجب أن تحافظ هذه السياسة على قدرة واجهة برمجة التطبيقات Virtual Location Bypass API على تجاوز إعدادات الموقع الجغرافي للجهاز بدون تغيير الإعدادات.
• [C-0-5] يجب تحديد موعد إرسال إشعار يذكّر المستخدم بعد وصول أحد التطبيقات في الخلفية إلى الموقع الجغرافي باستخدام إذن [ACCESS_BACKGROUND_LOCATION].

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
  • تفريغ TelephonyRegistry
  • تفريغ WifiService
  • تفريغ ConnectivityService
  • ملف تفريغ للمثيل CarrierService الخاص بحزمة الاتصال (إذا كان مرتبطًا)
  • مخزن مؤقت لسجلات الراديو
• [C-1-5] يجب ألا يتضمن ما يلي في التقارير التي تم إنشاؤها:
  • يشير ذلك المصطلح إلى أي نوع من المعلومات غير المرتبطة مباشرةً بتصحيح أخطاء الاتصال.
  • أي نوع من سجلات حركة بيانات التطبيقات التي يثبّتها المستخدم أو الملفات الشخصية التفصيلية للتطبيقات/الحزم المثبَّتة من قِبل المستخدم (لا بأس بالمعرّفات الفريدة، بينما أسماء الحزم غير مسموح بها).
• وقد تتضمن معلومات إضافية غير مرتبطة بأي هوية مستخدم. (مثل سجلات المورّدين).

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

• [C-SR-1] يُوصى بشدة بإيقاف إعداد المطوّرين تلقائيًا. ويفي تنفيذ مرجع AOSP هذا من خلال توفير الخيار Enable verbose vendor logging في إعدادات المطوّرين لتضمين سجلات مورّد إضافية خاصة بالجهاز في تقارير الأخطاء.

9.8.11. مشاركة وحدات تخزين البيانات الثنائية الكبيرة

يسمح Android من خلال BlobStoreManager للتطبيقات بالمساهمة بالملفات الثنائية الكبيرة (BLOB) في النظام لمشاركتها مع مجموعة محدّدة من التطبيقات.

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

• [C-1-1] يجب عدم مشاركة وحدات تخزين البيانات الثنائية التي تنتمي إلى تطبيقات بخلاف ما تريد السماح به (مثل نطاق الوصول التلقائي وأوضاع الوصول الأخرى التي يمكن تحديدها باستخدام BlobStoreManager.session#allowPackageAccess() أو BlobStoreManager.session#allowSameSignature() أو MU#BlobStoreManager. يلبي تنفيذ مرجع 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] يجب التأكّد من أنّه يتم تتبُّع الوصول إلى الصوت من خلال استدعاءات AppOpsManager.noteOp / startOp عندما تصل MusicRecognitionManagerService إلى سجلّ الصوت ويعيد توجيهه إلى التطبيق الذي ينفّذ MusicRecognitionService

إذا تم تخزين أي بيانات صوتية تم تسجيلها في عمليات تنفيذ الأجهزة في MusicRecognitionManagerService أو MusicRecognitionService على الجهاز، سيتم اتخاذ الإجراءات التالية:

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

9.8.13. مدير الخصوصية في جهاز الاستشعار

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

• [C-1-1] يجب أن تعرض القيمة "true" بدقة لطريقة واجهة برمجة التطبيقات supportsSensorToggle() ذات الصلة.
• [C-1-2] عندما يحاول أحد التطبيقات الوصول إلى ميكروفون أو كاميرا محظورَين، يجب أن يقدّم للمستخدم عناصر وظيفية لا يمكن إغلاقها وتشير بوضوح إلى أنّ أداة الاستشعار محظورة وتتطلب اختيار مواصلة الحظر أو إزالة الحظر وفقًا لسياسة AOSP التي تستوفي هذا الشرط.
• [C-1-3] يجب أن يمرّر فقط إلى التطبيقات بيانات كاميرا وصوت فارغة (أو مزيّفة) وعدم الإبلاغ عن رمز خطأ بسبب عدم تشغيل المستخدم للكاميرا أو الميكروفون من خلال وظائف المستخدم الموضّحة وفقًا للإرشادات [C-1-2] أعلاه.

9.9. تشفير مساحة تخزين البيانات

يجب أن تستوفي جميع الأجهزة متطلبات الفقرة 9.9.1. يتم استثناء الأجهزة التي يتم تشغيلها على مستوى واجهة برمجة تطبيقات قبل المستوى الوارد في هذا المستند من متطلبات الفقرتين 9.9.2 و9.9.3، بدلاً من ذلك، يجب أن تستوفي الأجهزة المتطلبات الواردة في الفقرة 9.9 من مستند تعريف التوافق مع Android المرتبطة بمستوى واجهة برمجة التطبيقات الذي تم تشغيل الجهاز عليه.

9.9.1. التشغيل المباشر

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

• [C-0-1] يجب أن تنفذ واجهات برمجة تطبيقات وضع التشغيل المباشر حتى إذا لم تكن تدعم تشفير مساحة التخزين.

• [C-0-2] يجب أن يستمر بث Intents من ACTION_LOCKED_BOOT_COMPLETED و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.

ملاحظة: إنّ عمليات تنفيذ الأجهزة التي تم شحنها إلى المستوى 28 من واجهة برمجة التطبيقات أو مستوى أقدم ولا تستوفي المتطلبات الواردة في الإصدار 9.9.2 من خلال تحديث برامج النظام، يجب أن تستوفي المتطلبات الواردة في الفقرة 9.9 من مستند تعريف التوافق مع Android المتوافقة مع مستوى واجهة برمجة التطبيقات الذي تم شحن الجهاز عليه.

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 إلى معيار التشفير المتقدم مع مفتاح تشفير 256 بت، ويتم تشغيله في وضع XTS، والطول الكامل للمفتاح هو 512 بت. يشير مصطلح "Adiantum" إلى Adiantum-XChaCha12-AES، كما هو موضَّح على الرابط https://github.com/google/adiantum. بيانات التعريف لنظام الملفات عبارة عن بيانات مثل أحجام الملفات والملكية والأوضاع والسمات الموسعة (xattrs).
• [C-1-6] يجب أن يشفّر أسماء الملفات باستخدام AES-256-CBC-CTS أو 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) الذي يعتمد على كل من الملف والإزاحة داخل الملف. علاوة على ذلك، يجب أن تكون جميع هذه المجموعات فريدة، إلا إذا كان يتم التشفير باستخدام أجهزة التشفير المضمّن التي لا تتوافق إلا مع طول IV يبلغ 32 بت.
• [C-1-16] يجب أن يتأكد أن جميع أسماء الملفات المشفرة التي لم يتم حذفها على مساحة التخزين الدائمة في الأدلة المختلفة قد تم تشفيرها باستخدام تركيبات مختلفة من مفتاح التشفير ومتّجه الإعداد (IV).

• [C-1-17] يجب أن يتأكّد من أنّ جميع كتل البيانات الوصفية لنظام الملفات المشفّرة على مساحة التخزين الدائمة تم تشفيرها باستخدام تركيبات مختلفة من مفتاح التشفير ومتّّجه الإعداد (IV).

• المفاتيح التي تحمي مناطق التخزين المتوفرة في أوروبا والشرق الأوسط وأفريقيا والبيانات الوصفية لنظام الملفات:

  • [C-1-7] يجب أن يكون مرتبطًا بالتشفير بوحدة تخزين مفاتيح مدعومة بالأجهزة. يجب أن يرتبط ملف تخزين المفاتيح هذا بالتشغيل المتحقَّق منه وجذر الثقة لأجهزة الجهاز.
  • [C-1-8] يجب ربط مفاتيح CE ببيانات اعتماد شاشة القفل لدى المستخدم.
  • [C-1-9] يجب ربط مفاتيح CE برمز مرور تلقائي في حال عدم تحديد المستخدم لبيانات اعتماد شاشة القفل.
  • [C-1-10] يجب أن يكون فريدًا ومتميزًا، بعبارة أخرى لا يتطابق مفتاح CE أو DE للمستخدم مع مفتاح CE أو DE لأي مستخدم آخر.
  • [C-1-11] يجب أن يستخدم رموز التشفير وأطوال المفاتيح والأوضاع المتوافقة بشكل إلزامي.
  • يجب محو بيانات [C-1-12] بأمان أثناء فتح قفل برنامج الإقلاع وقفله على النحو الموضّح هنا.

• ينبغي أن تنشئ تطبيقات أساسية مثبتة مسبقًا (مثل المنبه والهاتف والمراسلة) التشغيل المباشر على دراية بذلك.

يوفر المشروع المفتوح المصدر لنظام Android التنفيذ الأمثل للتشفير المستند إلى الملفات استنادًا إلى ميزة تشفير "fscrypt" لنواة Linux، وتشفير البيانات الوصفية استنادًا إلى ميزة نواة Linux "dm-default-key".

ملاحظة: إنّ عمليات تنفيذ الأجهزة التي تم شحنها إلى المستوى 28 من واجهة برمجة التطبيقات أو مستوى أقدم ولا تستوفي المتطلبات الواردة في الإصدار 9.9.3 من خلال تحديث برامج النظام يجب أن تستوفي المتطلبات الواردة في الفقرة 9.9 من مستند تعريف التوافق مع Android المتوافقة مع مستوى واجهة برمجة التطبيقات الذي تم شحن الجهاز من خلاله.

9.9.3.2. التشفير على مستوى الحظر لكل مستخدم

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

• [C-1-1] يجب أن يتيح دعم المستخدمين المتعددين كما هو موضح في الفقرة 9.5.
• [C-1-2] يجب توفير أقسام لكل مستخدم، إما باستخدام أقسام أولية أو وحدات تخزين منطقية.
• [C-1-3] يجب أن يستخدم مفاتيح تشفير فريدة ومميزة لكل مستخدم لتشفير أجهزة الحظر الأساسية.

• [C-1-4] يجب استخدام AES-256-XTS لتشفير أقسام المستخدم على مستوى الحظر.

• المفاتيح التي تحمي الأجهزة المشفَّرة على مستوى الحظر لكل مستخدم:

  • [C-1-5] يجب أن يكون مرتبطًا بالتشفير بوحدة تخزين مفاتيح مدعومة بالأجهزة. يجب أن يرتبط ملف تخزين المفاتيح هذا بالتشغيل المتحقَّق منه وجذر الثقة لأجهزة الجهاز.
  • [C-1-6] يجب أن يكون مرتبطًا ببيانات اعتماد شاشة القفل الخاصة بالمستخدم.

يمكن تنفيذ التشفير على مستوى الحظر لكل مستخدم باستخدام ميزة نواة Linux "dm-crypt" عبر الأقسام لكل مستخدم.

9.9.4. الاستئناف عند إعادة التشغيل

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

ويجب أن يستمر تنفيذ ميزة Resume-on-إعادة التشغيل لضمان أنه عندما يسقط الجهاز بيد المهاجم، يكون من الصعب جدًا على هذا المهاجم استرداد بيانات المستخدم المشفرة من خلال CE. حتى إذا كان الجهاز قيد التشغيل، وتم إلغاء قفل وحدة تخزين CE، وإلغاء قفل الجهاز بعد تلقي اتصال عبر الهواء. لمقاومة الهجمات الداخلية، نفترض أيضًا أن المهاجم سيحصل على إمكانية الوصول إلى بث مفاتيح التوقيع المشفّرة.

ونخصّ بالذكر الشرط التالي:

• [C-0-1] يجب ألا تكون وحدة تخزين CE قابلة للقراءة حتى للمهاجم الذي يمتلك الجهاز فعليًا ولديه هذه الإمكانيات والقيود:

  • يمكنه استخدام مفتاح التوقيع الخاص بأي مورّد أو شركة لتوقيع رسائل عشوائية.
  • قد يتسبب في استلام الجهاز للتحديث الهوائي (OTA).
  • يمكن تعديل تشغيل أي جهاز (AP أو flash أو غير ذلك) باستثناء ما هو موضح أدناه، ولكن يتضمّن هذا التعديل تأخيرًا لمدة ساعة على الأقل ودورة طاقة تدمر محتويات ذاكرة الوصول العشوائي.
  • لا يمكن تعديل عملية تشغيل الأجهزة المقاومة للتلاعب (مثل Titan M).
  • لا يمكن قراءة ذاكرة الوصول العشوائي للجهاز المباشر.
  • لا يمكن الحصول على بيانات اعتماد المستخدم (رقم التعريف الشخصي أو النقش أو كلمة المرور) أو تتسبب في إدخالها بأي طريقة أخرى.

على سبيل المثال، سيكون تنفيذ الجهاز الذي ينفّذ جميع الأوصاف الواردة هنا ويلتزم بها متوافقًا مع [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-SR-1] في حال وجود عدة شرائح منفصلة في الجهاز (مثل الراديو أو معالج صور متخصص)، يُنصَح بشدة بإجراء عملية تشغيل كل شريحة من هذه الشرائح للتحقّق من كل مرحلة بعد التشغيل.
• [C-1-8] يجب استخدام مساحة تخزين يمكن التلاعب بها: لتخزين ما إذا كان برنامج الإقلاع غير مقفَل. تعني مساحة التخزين التي تظهر التلاعب في الجهاز أنّ برنامج الإقلاع يمكنه رصد ما إذا كان قد تمّ التلاعب بمساحة التخزين من داخل Android أم لا.
• [C-1-9] يجب أن يطلب المستخدم أثناء استخدام الجهاز تأكيدًا فعليًا قبل السماح بالانتقال من وضع قفل برنامج الإقلاع إلى وضع فتح قفل برنامج الإقلاع.
• [C-1-10] يجب توفير ميزة الحماية من العودة إلى الإصدارات السابقة على الأقسام التي يستخدمها Android (مثل التشغيل وأقسام النظام) واستخدام مساحة تخزين تظهر عند التلاعب لتخزين البيانات الوصفية المستخدَمة لتحديد الحدّ الأدنى المسموح به لإصدار نظام التشغيل.
• [C-1-11] يجب أن يمحو جميع بيانات المستخدم بأمان أثناء فتح قفل برنامج الإقلاع وقفله، وفقًا لما ورد في "9.12". حذف البيانات" (بما في ذلك قسم بيانات المستخدمين وأي مساحات ذاكرة NVRAM).
• [C-SR-2] يُنصَح بشدة بالتحقّق من جميع ملفات APK للتطبيقات المميزة التي تتضمن سلسلة من الثقة مبنيّة على جذور ضمن أقسام محمية بميزة "التشغيل المتحقّق منه"
• [C-SR-3] يُنصح بشدة بالتحقّق من أي عناصر قابلة للتنفيذ تم تحميلها من خلال تطبيق يحظى بامتيازات خاصة من خارج ملف APK الخاص به (مثل الرموز البرمجية التي يتم تحميلها ديناميكيًا أو الرموز المجمّعة) قبل تنفيذها أو ننصح بشدة بعدم تنفيذها على الإطلاق.
• يجب تنفيذ الحماية من العودة إلى الحالة السابقة لأي مكوّن يتضمّن برامج ثابتة دائمة (مثل المودم والكاميرا)، كما يجب استخدام مساحة تخزين تظهر عند رصد التلاعب بهدف تخزين البيانات الوصفية المستخدَمة لتحديد الحدّ الأدنى المسموح به للإصدار.

إذا سبق أن تم إطلاق عمليات تنفيذ الأجهزة بدون التوافق مع الإصدارات من C-1-8 إلى C-1-11 على إصدار سابق من Android وتعذّرت إتاحة هذه المتطلبات في تحديث برنامج النظام، قد يتم إعفاؤها من المتطلبات.

يوفّر "المشروع المفتوح المصدر لنظام Android" الأساسي التنفيذ المفضّل لهذه الميزة في مستودع external/avb/ الذي يمكن دمجه في برنامج الإقلاع المستخدَم لتحميل Android.

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

• [C-0-3] يجب أن يتيح التحقق من محتوى الملف بطريقة مشفّرة مقابل مفتاح موثوق به بدون قراءة الملف بأكمله.
• [C-0-4] يجب ألا تسمح بنجاح طلبات القراءة في الملف المحمي عند عدم التحقق من المحتوى المقروء مقابل مفتاح موثوق به.

إذا سبق أن تم تشغيل عمليات تنفيذ الأجهزة بدون إمكانية التحقّق من محتوى الملف مقابل مفتاح موثوق به في إصدار Android سابق وتعذّرت إتاحة هذه الميزة من خلال تحديث لبرامج النظام، قد يتم إعفاؤها من هذا الشرط. يوفّر المشروع المفتوح المصدر لنظام Android التنفيذ المفضَّل لهذه الميزة استنادًا إلى ميزة fs-verity في Linux kernel.

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

• [C-SR-4] يُنصَح باستخدامها بشدة لإتاحة واجهة برمجة التطبيقات للحماية من ميزة "التأكيد على Android".

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

• [C-3-1] يجب الإبلاغ عن true لواجهة برمجة تطبيقات ConfirmationPrompt.isSupported().

• [C-3-2] يجب أن يتأكّد من أنّ الرمز البرمجي الذي يتم تشغيله في نظام التشغيل Android، بما في ذلك النواة الضارة أو غير ذلك، لا يمكنه إنشاء استجابة إيجابية بدون تفاعل من المستخدم.

• [C-3-3] يجب أن يتأكّد المستخدم من تمكّن المستخدم من مراجعة الرسالة المطلوبة والموافقة عليها حتى في حال تعرُّض نظام التشغيل Android، بما في ذلك النواة، للاختراق.

9.11. المفاتيح وبيانات الاعتماد

يتيح نظام تخزين مفاتيح Android لمطوّري التطبيقات إمكانية تخزين مفاتيح التشفير في إحدى الحاويات واستخدامها في عمليات التشفير من خلال KeyChain API أو واجهة برمجة تطبيقات Keystore. عمليات تنفيذ الأجهزة:

• [C-0-1] يجب أن يسمح باستيراد 8192 مفتاحًا أو إنشاؤه على الأقل.
• [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 وSHA1 وSHA-2 للتوافق بشكل صحيح مع الخوارزميات المتوافقة مع نظام Android Keystore في منطقة معزولة بشكل آمن عن رمز kerدل الخوارزمية. يجب أن تحظر ميزة العزل الآمن جميع الآليات المحتملة التي يمكن من خلالها وصول رمز النواة أو رمز مساحة المستخدم إلى الحالة الداخلية للبيئة المعزولة، بما في ذلك قانون الأسواق الرقمية. استوفى "المشروع المفتوح المصدر لنظام Android" (AOSP) هذا الشرط من خلال استخدام تنفيذ TrustZone، إلا أنّ الخيارات البديلة هي أحد الحلول البديلة المستنِدة إلى بروتوكول ARM TrustZone أو إحدى جهات خارجية التي تمت مراجعتها بشكل آمن ومستند إلى برنامج Hypervisor (مراقب الأجهزة الظاهرية).
• يجب أن يجري [C-1-3] مصادقة شاشة القفل في بيئة التنفيذ المعزولة، ولا يسمح باستخدام المفاتيح المرتبطة بالمصادقة إلا عند نجاح الإجراء. يجب تخزين بيانات اعتماد شاشة القفل بطريقة تسمح لبيئة التنفيذ المعزولة فقط بإجراء مصادقة شاشة القفل. يوفّر "المشروع المفتوح المصدر لنظام Android" طبقة استخراج أجهزة (HAL) من برنامج بوابة حماية (HAL) وطبقة أمان موثوقة (Trusty)، واللذَين يمكن استخدامهما لاستيفاء هذا الشرط.
• [C-1-4] يجب أن يتيح مصادقة المفتاح حيث يكون مفتاح توقيع المصادقة محميًا باستخدام أجهزة آمنة ويتم التوقيع في أجهزة آمنة. يجب مشاركة مفاتيح توقيع المصادقة على عدد كبير بما يكفي من الأجهزة لمنع استخدام المفاتيح كمعرّفات للأجهزة. ولتحقيق هذا الشرط، يمكنك مشاركة مفتاح المصادقة نفسه، ما لم يتم إنتاج 100,000 وحدة على الأقل من رمز تخزين تعريفي معيّن. في حال إنتاج أكثر من 100,000 وحدة من رمز التخزين التعريفي، قد يتم استخدام مفتاح مختلف لكل 100,000 وحدة.

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

• [C-1-5] يجب أن يسمح للمستخدم باختيار مهلة السكون للانتقال من الحالة التي تم فتحها إلى حالة القفل، مع ضبط حد أدنى مسموح به للمهلة يصل إلى 15 ثانية. قد لا يتم ضبط "مهلة النوم" على أجهزة السيارات التي تقفل الشاشة عند إيقاف الوحدة الرئيسية أو عند تبديل المستخدم.
• يجب أن يتيح [C-1-6] استخدام أي مما يلي:
  • IKeymasterDevice 3.0،
  • IKeymasterDevice 4.0،
  • IKeymasterDevice 4.1،
  • الإصدار 1 من IKeyMintDevice،
  • الإصدار 2 من IKeyMintDevice.
• [C-SR-1] يُنصح بشدة بأن يتوافق مع الإصدار 1 من IKeyMintDevice.

9.11.1. شاشة القفل الآمنة والمصادقة والأجهزة الافتراضية

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

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

• [C-SR-1] يُنصح بشدة بضبط طريقة واحدة فقط مما يلي كطريقة المصادقة الأساسية:
  • رقم تعريف شخصي رقمي
  • كلمة مرور أبجدية رقمية
  • نمط تمرير سريع على شبكة من نقاط 3×3 بالضبط

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

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

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

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

• [C-3-1] يجب أن يكون قصور أقصر طول مسموح به من المدخلات أكبر من 10 بت.
• [C-3-2] يجب أن يكون الحد الأقصى لقصور جميع المدخلات الممكنة أكبر من 18 بت.
• [C-3-3] يجب ألا تحلّ طريقة المصادقة الجديدة محلّ أي طريقة من طرق المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) التي تم تنفيذها وتقديمها في بروتوكول AOSP.
• [C-3-4] يجب إيقاف طريقة المصادقة الجديدة عندما يضبط تطبيق "وحدة التحكّم بسياسة الجهاز" (DPC) سياسة متطلبات كلمة المرور من خلال DevicePolicyManager.setrequiredPasswordComplexity() مع إجراء تعديلات أكثر تقييدًا من password_COMPLEXITY_NONE أو باستخدام طريقة DevicePolicyManager.setPasswordquality() تكون أكثر تقييدًا من طريقة DevicePolicyManager.setrequiredPasswordComplexity.
• [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 أدناه.

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

• يجب أن يحتوي [C-7-1] على مؤشر واضح في قائمة الإعدادات وعلى شاشة القفل عند تأجيل قفل الجهاز أو عند إتاحة إمكانية فتح قفل الجهاز بواسطة الوكلاء المعتمدين. على سبيل المثال، تستوفي ميزة AOSP هذا الشرط من خلال عرض وصف نصي "لإعداد القفل تلقائيًا" و "القفل الفوري لزر التشغيل" في قائمة الإعدادات ورمز مميز على شاشة القفل.
• يجب أن يلتزم [C-7-2] بجميع واجهات برمجة التطبيقات للوكيل الموثوق به وينفّذها بالكامل في الفئة DevicePolicyManager، مثل الثابت KEYGUARD_DISABLE_TRUST_AGENTS.
• [C-7-3] يجب ألا ينفّذ بشكل كامل وظيفة TrustAgentService.addEscrowToken() على جهاز يُستخدم كجهاز شخصي أساسي (مثلاً محمول باليد)، ولكن قد يُنفِّذ الميزة بالكامل على الأجهزة التي تتم مشاركتها عادةً (مثل Android TV أو جهاز سيارات).
• [C-7-4] يجب أن يشفّر كل الرموز المميّزة المخزَّنة التي أضافها TrustAgentService.addEscrowToken().
• [C-7-5] يجب عدم تخزين مفتاح التشفير أو رمز الضمان على الجهاز نفسه الذي يُستخدَم فيه المفتاح. على سبيل المثال، يُسمح لمفتاح مخزَّن على هاتف بإلغاء قفل حساب مستخدم على التلفزيون. بالنسبة إلى أجهزة السيارات، لا يُسمح بتخزين الرمز المميّز للضمان على أي جزء من المركبة.
• [C-7-6] يجب أن يُبلغ المستخدم بتداعيات الأمان قبل تفعيل الرمز المميّز للضمان لفك تشفير مساحة تخزين البيانات.
• [C-7-7] يجب أن تتوفّر به آلية احتياطية لاستخدام إحدى طرق المصادقة الأساسية المقترَحة.
• [C-7-8] يجب أن يطلب المستخدم إجراء إحدى طرق المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) مرة واحدة على الأقل كل 72 ساعة أو أقل إلا إذا كان على سلامة المستخدم (مثل تشتيت انتباه السائق)
• [C-7-9] يجب أن يطلب المستخدم إجراء إحدى طرق المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) على النحو الموضّح في [C-1-7] و[C-1-8] في الفقرة 7.3.10، ما لم يكن هناك مخاوف متعلقة بأمان المستخدم (على سبيل المثال، تشتيت انتباه السائق).
• [C-7-10] يجب ألا يتم التعامل معه كشاشة قفل آمنة ويجب أن يتّبع القيود الواردة في C-8 أدناه.
• [C-7-11] يجب ألا يسمح لموظّفي الدعم الموثوق بهم على الأجهزة الشخصية الأساسية (مثل حمل الجهاز باليد) بفتح قفل الجهاز ولا يمكنهم استخدامه إلا للاحتفاظ بالجهاز الذي سبق أن تم فتح قفله في حالة فتح القفل لمدة تصل إلى 4 ساعات كحد أقصى. ويستوفي التنفيذ التلقائي لـ TrustManagerService في AOSP هذا الشرط.
• [C-7-12] يجب أن يستخدم قناة اتصال آمنة من ناحية التشفير (مثل UKEY2) لتمرير رمز الضمان من جهاز التخزين إلى الجهاز المستهدف.

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

• [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] يجب قطع اتصال جميع الأجهزة الافتراضية عند انتهاء مهلة عدم النشاط
• [C-10-3] يجب أن تتضمن مهلة عدم النشاط
• [C-10-4] يجب أن يقفل جميع الشاشات عندما يبدأ المستخدم إلغاء التأمين، بما في ذلك من خلال تكاليف المستخدم المتعلقة بالإغلاق المطلوبة للأجهزة المحمولة (راجع الفقرة 2.2.5[9.11/H-1-2])
• [C-10-5] يجب أن تتوفّر لكل مستخدم مثيلات منفصلة للأجهزة الافتراضية.
• [C-10-6] يجب أن يوقِف إنشاء أحداث الإدخال المرتبطة عبر VirtualDeviceManager عندما يُشار إليه بواسطة DevicePolicyManager.setNearbyAppStreamingPolicy
• [C-10-7] يجب استخدام حافظة منفصلة لكل جهاز افتراضي فقط (أو إيقاف الحافظة للأجهزة الافتراضية)
• [C-10-11] يجب إيقاف واجهة المستخدم للمصادقة على الأجهزة الافتراضية، بما في ذلك إدخال عامل المعرفة وطلب المقاييس الحيوية
• [C-10-12] يجب أن تقيّد الأهداف التي تبدأ من جهاز افتراضي للعرض على الجهاز الافتراضي نفسه فقط
• [C-10-13] يجب ألا تستخدم حالة قفل الجهاز الافتراضي كتفويض لمصادقة المستخدم من خلال نظام تخزين مفاتيح Android. يمكنك الاطّلاع على KeyGenParameterSpec.Builder.setUserAuthentication*.

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

• [C-11-1] يجب تشفير عامل المعرفة باستخدام ضمانات الحماية المشابهة لتلك الموضّحة في التقرير الموجز حول خدمة Google Cloud Key Vault عند نقل عامل المعرفة من الجهاز المصدر إلى الجهاز المستهدف كي لا يمكن فك تشفير عامل المعرفة عن بُعد أو استخدامه لفتح قفل أي من الجهازَين عن بُعد.
• [C-11-2] يجب أن تطلب من المستخدم في الجهاز المصدر تأكيد عامل المعرفة للجهاز المصدر قبل نقل عامل المعرفة إلى الجهاز المستهدف.
• [C-11-3] يجب أن تطلب من المستخدم على الجهاز المستهدَف الذي يفتقر إلى أيّ عامل معرفة أساسي معيّن

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة قفل آمنة وتتضمّن وكيل ثقة واحدًا أو أكثر، يتصل ذلك بواجهة TrustAgentService.grantTrust() System API التي تحمل علامة 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()
  • بعد مرور 24 ساعة كحد أقصى من منح الثقة، أو
  • بعد مرور فترة عدم النشاط لمدة 8 ساعات
  • إذا لم تكن عمليات التنفيذ تستخدم التشفير الآمن والدقيق في نطاق زمني محدّد في [C-12-5]، عند فقدان الاتصال الأساسي بالجهاز الفعلي القريب.
• [C-12-5] في عمليات التنفيذ التي تعتمد على نطاقات آمنة ودقيقة لتلبية متطلبات [C-12-4]، يجب استخدام أحد الحلول التالية:
  • عمليات التنفيذ باستخدام النطاق الفائق العرض (UWB):
    • يجب أن يستوفي الجهاز متطلبات المطابقة والاعتماد والدقة والمعايرة للنطاق الفائق العرض (UWB) الموضّحة في 7.4.9.
    • يجب استخدام أحد أوضاع أمان P-STS الواردة في 7.4.9.
  • عمليات التنفيذ التي تم إجراؤها باستخدام شبكة Wi-Fi العالمية للوعي بشبكة Wi-Fi (NAN):
    • يجب أن تستوفي متطلبات الدقة الواردة في 2.2.1 [7.4.2.5/H-SR-1]، وأن تستخدم معدل نقل بيانات بتردد 160 ميغاهرتز (أو أعلى)، واتّبِع خطوات إعداد القياس المحدّدة في معايرة تواجد الأفراد في المنزل.
    • يجب استخدام "الدعم الطويل الأمد (LTF) الآمن" على النحو المحدّد في IEEE 802.11az.

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

• [C-13-8] يجب حظر الأنشطة التي تتضمن السمة android:canDisplayOnRemoteDevices أو البيانات الوصفية android.activity.can_display_on_remote_devices على "خطأ" لمنع تشغيلها على الجهاز الافتراضي.
• [C-13-9] يجب حظر الأنشطة التي لا تفعّل البث بشكل صريح والتي تشير إلى أنّها تعرض محتوًى حسّاسًا، بما في ذلك من خلال SurfaceView#setSecure أو FLAG_SECURE أو SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS، من بدء تشغيلها على الجهاز الافتراضي.

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

• [C-SR-2] يُنصح بشدة باستخدام متطلبات استيفاء بيانات الاعتماد المحدّدة في الفقرة 9.11.1 أو اجتماع المقاييس الحيوية على الأقل من مواصفات الفئة 1 المحدّدة في الفقرة 7.3.10 للسماح بفتح القفل بشكل مستقل من شاشة الجهاز التلقائية.
• [C-SR-3] يُوصى بشدة بتقييد فتح قفل شاشة العرض المنفصلة من خلال مهلة عرض محددة.
• [C-SR-4] يُنصَح باستخدامها بشدة للسماح للمستخدم بقفل جميع الشاشات على مستوى العالم من خلال الإغلاق من الجهاز المحمول الأساسي.

9.11.2. جهاز strongBox

يتيح نظام تخزين مفاتيح Android لمطوّري التطبيقات تخزين مفاتيح التشفير في معالج آمن ومخصَّص بالإضافة إلى بيئة التنفيذ المعزولة المذكورة أعلاه. يُطلق على هذا المعالج الآمن المخصص اسم "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] يجب أن يتأكد من عدم تمكّن أي أجهزة ملحقة تمت مشاركتها مع AP من تغيير عملية معالجة StrongBox بأي شكل من الأشكال، أو الحصول على أي معلومات من StrongBox. وقد تؤدي AP إلى إيقاف الوصول إلى StrongBox أو حظره.

• يجب أن يحتوي [C-1-5] على ساعة داخلية بدقة معقولة (+-10%) محصنة من التلاعب بواسطة AP.

• يجب أن يحتوي [C-1-6] على منشئ أرقام عشوائية حقيقي ينتج عنه مخرجات موزّعة بشكل موحّد وغير متوقعة.

• يجب أن يكون لدى [C-1-7] مقاومة للتلاعب، بما في ذلك مقاومة الاختراق الجسدي والأعطال.

• يجب أن يكون لدى [C-1-8] مقاومة من قنوات جانبية، بما في ذلك مقاومة تسرُّب المعلومات من خلال الطاقة والتوقيت والإشعاع الكهرومغناطيسي والقنوات الجانبية للإشعاع الحراري.

• يجب أن يوفّر [C-1-9] مساحة تخزين آمنة تضمن سرية المحتوى وسلامته وأصالةه واتساقه وحداثته. يجب ألا تكون وحدة التخزين قابلة للقراءة أو التغيير باستثناء ما تسمح به واجهات برمجة تطبيقات StrongBox.

• للتحقّق من الامتثال لمعيار [C-1-3] إلى [C-1-9]، يجب تنفيذ ما يلي:

  • يجب أن يشتمل [C-1-10] على الأجهزة المعتمدة وفقًا لملف تعريف حماية IC الآمن BSI-CC-PP-0084-2014 أو التي تم تقييمها من خلال مختبر اختباري معتمَد على المستوى المحلي. وهو يشمل تقييمًا للثغرة الأمنية "احتمالية الهجوم المرتفع" وفقًا للمعايير المشتركة لاحتمالية الهجوم على البطاقات الذكية.
  • [C-1-11] يجب أن يشتمل على البرامج الثابتة التي يتم تقييمها من خلال مختبر معتمَد على المستوى الوطني يدمج تقييمًا للثغرات الأمنية المحتملة في الهجوم وفقًا لتطبيق المعايير المشتركة لاحتمالية الهجوم على البطاقات الذكية.
  • [C-SR-2] يُنصح بشدة بتضمين الأجهزة التي يتم تقييمها باستخدام "هدف أمان" و"مستوى ضمان التقييم" (EAL) 5، بالاستناد إلى AVA_VAN.5. من المحتمل أن تصبح شهادة EAL 5 شرطًا في إصدار مستقبلي.
  • [C-SR-3] يُنصح بشدّة بتوفير مقاومة للهجمات الداخلية، ما يعني أنّ المحلّل الداخلي الذي لديه إمكانية الوصول إلى مفاتيح توقيع البرامج الثابتة لا يمكنه إنتاج برامج ثابتة تتسبّب في تسرُّب حِزم StrongBox لسرية أسرار الحِزمة أو تجاوز متطلبات الأمان الوظيفية أو إتاحة الوصول إلى بيانات المستخدمين الحسّاسة. والطريقة المقترحة لتنفيذ IAR هي عدم السماح بتحديثات البرامج الثابتة إلا عند تقديم كلمة مرور المستخدم الأساسي عبر بروتوكول IAuthSecret HAL.

9.11.3. بيانات اعتماد الهوية

يتم تحديد نظام بيانات الاعتماد الهوية وتحقيقه من خلال تنفيذ جميع واجهات برمجة التطبيقات في حزمة android.security.identity.*. تسمح واجهات برمجة التطبيقات هذه لمطوّري التطبيقات بتخزين مستندات هوية المستخدم واستردادها. عمليات تنفيذ الأجهزة:

• يُوصى بشدة [C-SR-1] بتنفيذ "نظام بيانات اعتماد الهوية".

في حال استخدام عمليات تنفيذ الأجهزة لـ Identity Credential System، سيتم ما يلي:

• [C-1-1] يجب أن تعرض قيمة غير خالية لطريقة IdentityCredentialStore#getInstance()

• [C-1-2] يجب أن يستخدم نظام بيانات اعتماد الهوية (مثل واجهات برمجة تطبيقات android.security.identity.*) مع رمز يتصل بتطبيق موثوق به في منطقة معزولة بشكل آمن عن الرمز الذي يعمل على النواة والإصدارات الأحدث. يجب أن تحظر ميزة العزل الآمن جميع الآليات المحتملة التي يمكن من خلالها وصول رمز النواة أو رمز مساحة المستخدم إلى الحالة الداخلية للبيئة المعزولة، بما في ذلك قانون الأسواق الرقمية.

• [C-1-3] يجب تنفيذ عمليات التشفير اللازمة لتطبيق "نظام بيانات اعتماد الهوية" (مثل واجهات برمجة تطبيقات android.security.identity.*) بالكامل في التطبيق الموثوق به، ويجب ألا تغادر مادة المفتاح الخاص بيئة التنفيذ المعزولة ما لم يكن ذلك مطلوبًا تحديدًا من خلال واجهات برمجة التطبيقات ذات المستوى الأعلى (مثل طريقة createEphemeralKeypair()).

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

يوفّر "المشروع المفتوح المصدر لنظام Android" التنفيذ المرجعي لتطبيق موثوق به (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 البيانات مع الأنظمة الفرعية للمركبات المهمة، وذلك من خلال استخدام HAL للمركبات لإرسال الرسائل واستلامها عبر شبكات المركبات مثل حافلات CAN.

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

9.15. خطط الاشتراك

تشير "خطط الاشتراك" إلى تفاصيل خطة علاقة الفوترة التي يوفّرها مشغّل شبكة الجوّال من خلال SubscriptionManager.setSubscriptionPlans().

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

• [C-0-1] يجب إرجاع خطط الاشتراك إلى تطبيق مشغّل شبكة الجوّال الذي قدّمها في الأصل فقط.
• [C-0-2] يجب عدم الاحتفاظ بنسخة احتياطية من خطط الاشتراك أو تحميلها عن بُعد.
• يجب أن يسمح [C-0-3] بعمليات الإلغاء فقط، مثل SubscriptionManager.setSubscriptionOverrideCongested()، من تطبيق مشغّل شبكة الجوّال الذي يوفر حاليًا خطط اشتراك صالحة.

9.16. نقل بيانات التطبيق

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

• [C-1-1] يجب ألا يبدأ عمليات نقل بيانات التطبيقات من الأجهزة التي لم يضبط المستخدم مصادقة أساسية عليها كما هو موضّح في 9.11.1 قفل الشاشة الآمنة والمصادقة.
• يجب أن يؤكّد [C-1-2] المصادقة الأساسية بشكل آمن على الجهاز المصدر وأن يؤكّد نية المستخدم في نسخ البيانات على الجهاز المصدر قبل نقل أي بيانات.
• [C-1-3] يجب استخدام المصادقة على مفتاح الأمان للتأكّد من أنّ كل من الجهاز المصدر والجهاز المستهدف في عملية النقل من جهاز إلى جهاز جهازان صالحان يعملان بنظام التشغيل Android ويتضمّنان برنامج إقلاع مقفَل.
• [C-1-4] يجب نقل بيانات التطبيق فقط إلى التطبيق نفسه على الجهاز المستهدف، باستخدام اسم الحزمة وشهادة التوقيع نفسيهما.
• يجب أن يظهر في [C-1-5] إشارة إلى أنّ الجهاز المصدر يحتوي على بيانات تم نقلها من خلال عملية نقل بيانات من جهاز إلى آخر في قائمة الإعدادات. ويجب ألا يتمكّن المستخدم من إزالة هذه الإشارة.

9.17. إطار عمل المحاكاة الافتراضية على Android

إذا كان الجهاز يتوافق مع واجهات برمجة تطبيقات إطار عمل المحاكاة الافتراضية على Android (android.system.virtualmachine.*)، سينفّذ مضيف Android ما يلي:

• يجب أن يتوافق [C-1-1] مع جميع واجهات برمجة التطبيقات المحدّدة في حزمة android.system.virtualmachine.*.
• [C-1-2] يجب ألا يُعدّل نظام التشغيل Android SELinux ونموذج الإذن لإدارة الأجهزة الافتراضية المحمية.
• [C-1-3] يجب ألا يعدل القواعد الموجودة ضمن النظام/السياسة المتوفر في مشروع Android مفتوح المصدر (AOSP) أو يحذفها أو يحل محلها، ويجب أن تجمع السياسة مع جميع قواعد "Neverallow" الحالية
• [C-1-4] يجب ألا يسمح باستخدام رمز غير موثوق به (مثل تطبيقات الجهات الخارجية) لإنشاء جهاز افتراضي محمي وتشغيله. ملاحظة: قد يتغير ذلك في إصدارات Android المستقبلية.
• [C-1-5] يجب ألا يسمح للجهاز الافتراضي المحمي بتنفيذ رمز برمجي ليس جزءًا من صورة المصنع أو من تحديثاته. يجب عدم السماح بتشغيل أي محتوى لا يشمله برنامج "التشغيل المُتحقَّق منه من Android" (مثل الملفات التي تم تنزيلها من الإنترنت أو البيانات من مصدر غير معروف) في "جهاز افتراضي محمي".

إذا كان الجهاز يوفِّر دعمًا لواجهات برمجة تطبيقات إطار عمل المحاكاة الافتراضية لنظام التشغيل Android (android.system.virtualmachine.*)، فإنّ أي مثيل لجهاز افتراضي محمي:

• [C-2-1] يجب أن يتمكن من تشغيل جميع أنظمة التشغيل المتوفرة في واجهة برمجة التطبيقات الافتراضية في جهاز افتراضي محمي.
• [C-2-2] يجب ألا يسمح للجهاز الافتراضي المحمي بتشغيل نظام تشغيل لم يتم توقيعه من قِبل جهة تنفيذ الجهاز أو مورّد نظام التشغيل.
• [C-2-3] يجب ألا يسمح لجهاز افتراضي محمي بتنفيذ البيانات كرمز برمجي (على سبيل المثال، SELinux أبدًا لا تسمح بـ execmem).
• [C-2-4] يجب ألا يعدّل أو يحذف أو يستبدل قواعد nonallow الحالية في النظام/sepolicy/microdroid المقدَّم في "المشروع المفتوح المصدر لنظام Android" (AOSP).
• [C-2-5] يجب تنفيذ آليات الدفاع المتعمق للجهاز الافتراضي المحمي (مثل SELinux للأجهزة الافتراضية) حتى مع أنظمة التشغيل غير المجهرية.
• [C-2-6] يجب أن يضمن أن برامج pVM الثابتة ترفض التشغيل إذا لم تتمكن من التحقق من الصورة الأولية.
• [C-2-7] يجب أن تضمن رفض برامج pVM الثابتة للتشغيل في حال تم اختراق سلامة المثيل.img.

إذا أتاح الجهاز استخدام واجهات برمجة تطبيقات إطار عمل المحاكاة الافتراضية على Android (android.system.virtualmachine.*)، سينفّذ برنامج Hypervisor (مراقب الأجهزة الظاهرية) ما يلي:

• [C-3-1] يجب ألا يسمح لأي جهاز افتراضي (pVM) بالوصول إلى صفحة تابعة لكيان آخر (مثل جهاز افتراضي (PVM) آخر أو برنامج Hypervisor (مراقب الأجهزة الظاهرية)) ما لم يشاركه مالك الصفحة صراحةً. ويشمل ذلك الجهاز الافتراضي (VM) الخاص بالمضيف. وينطبق ذلك على عمليات الوصول إلى كل من وحدة المعالجة المركزية (CPU) ومنطقة السوق المحددة.
• [C-3-2] يجب حجب بيانات الصفحة بعد استخدامها بواسطة جهاز افتراضي وقبل إرجاعها إلى المضيف (على سبيل المثال، تلف الجهاز).
• [C-3-3] يجب التأكّد من تحميل برامج pVM الثابتة وتنفيذها قبل أي رمز في جهاز افتراضي (pVM).
• [C-3-4] يجب أن يتأكد من أنّه لا يمكن الحصول على النسخة المخفية الوجهة والإصدارات المخصّصة لمثيل الجهاز الافتراضي (PVM) إلا من خلال هذا المثيل تحديدًا.

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

• [C-4-1] يجب ألا يتم توفير وظائف لجهاز افتراضي يتيح تجاوز نموذج أمان Android.

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

• يجب أن يتوافق [C-5-1] مع التجميع المعزول لتحديث وقت تشغيل ART.

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

• [C-6-1] يجب أن جذر سلسلة DICE في نقطة لا يمكن للمستخدم تعديلها، حتى على الأجهزة غير المقفلة. (للتأكد من عدم انتحاله).
• [C-6-2] يجب استخدام DICE بشكل صحيح، أي توفير القيم الصحيحة

10. اختبار توافق البرامج

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

10.1. مجموعة أدوات اختبار التوافق

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

• يجب أن يجتاز [C-0-1] مجموعة اختبار التوافق مع Android (CTS) المتاحة من المشروع المفتوح المصدر لنظام Android، باستخدام برنامج الشحن النهائي على الجهاز.

• يجب أن يضمن [C-0-2] التوافق في حالات الغموض في CTS وأي إعادة تنفيذ لأجزاء من رمز المصدر المرجعي.

تم تصميم CTS للتشغيل على جهاز فعلي. مثل أي برنامج، قد تحتوي CTS على أخطاء. سيتم إصدار إصدار CTS بشكل مستقل عن تعريف التوافق هذا، وقد يتم إصدار عدة مراجعات من CTS لنظام التشغيل Android 13.

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

• [C-0-3] يجب أن يجتاز أحدث إصدار من CTS متاح عند اكتمال برنامج الجهاز.

• يجب استخدام تنفيذ المرجع في شجرة البرامج المفتوحة المصدر لنظام Android بقدر الإمكان.

10.2. أداة التحقّق من CTS

تكون أداة CTS Verifier مضمَّنة في "حزمة اختبار التوافق"، وهي مصمّمة لتشغيلها من قِبل عامل تشغيل لاختبار الوظائف التي لا يمكن اختبارها من خلال نظام آلي، مثل الأداء الصحيح للكاميرا وأجهزة الاستشعار.

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

• [C-0-1] يجب أن ينفّذ بشكل صحيح جميع الحالات السارية في أداة التحقق من CTS.

تُجري CTS Verifier اختبارات للعديد من أنواع الأجهزة، بما في ذلك بعض الأجهزة الاختيارية.

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

• [C-0-2] يجب أن يجتاز جميع اختبارات الأجهزة المتوفرة لديه. على سبيل المثال، إذا كان الجهاز يتضمن مقياس تسارع، يجب أن ينجز حالة اختبار مقياس التسارع في جهاز التحقق من CTS بشكل صحيح.

يمكن تخطي أو حذف حالات اختبار الميزات المُشار إليها في مستند تعريف التوافق هذا.

• [C-0-2] يجب أن يعمل كل جهاز وكل إصدار بشكل صحيح مع أداة CTS Verifier، كما هو موضّح أعلاه. مع ذلك، وبما أنّ العديد من الإصدارات متشابهة إلى حدّ كبير، لا يُتوقع من مُنفذي الأجهزة تشغيل أداة CTS Verifier بشكل صريح على إصدارات لا تختلف سوى في طرق تافهة. على وجه التحديد، عمليات تنفيذ الأجهزة التي تختلف عن التنفيذ الذي اجتاز أداة CTS Verifier فقط من خلال مجموعة اللغات المضمّنة والعلامات التجارية وما إلى ذلك، قد يتم حذف اختبار CTS Verifier.

11. برامج قابلة للتحديث

• [C-0-1] يجب أن تتضمّن عمليات تنفيذ الأجهزة آلية لاستبدال برامج النظام بالكامل. لا تحتاج الآلية إلى إجراء ترقيات "مباشرة"، أي قد تكون إعادة تشغيل الجهاز مطلوبة. يمكن استخدام أي طريقة، بشرط أن تحل محل البرنامج المثبت مسبقًا على الجهاز بالكامل. على سبيل المثال، ستلبي أي من الأساليب التالية هذا المطلب:

  • عمليات تنزيل "عبر شبكة غير سلكيّة" (OTA)" مع التحديث بلا اتصال بالإنترنت عن طريق إعادة التشغيل
  • يتم تحديث "Tethered" عبر USB من جهاز كمبيوتر مضيف.
  • يتم تحديث "وضع عدم الاتصال بالإنترنت" من خلال إعادة التشغيل والتحديث من ملف على وحدة تخزين قابلة للإزالة.

• [C-0-2] يجب أن تتيح آلية التحديث المستخدَمة التحديثات بدون حجب بيانات المستخدمين. ويعني هذا أنّ آلية التحديث يجب أن تحتفظ بالبيانات الخاصة للتطبيقات والبيانات التي تتم مشاركتها مع التطبيقات. تجدر الإشارة إلى أنّ برامج Android الرئيسية تتضمن آلية تحديث تستوفي هذا الشرط.

• [C-0-3] يجب توقيع التحديث بأكمله كما يجب أن تتأكّد آلية التحديث على الجهاز من التحديث والتوقيع لمفتاح عام مخزَّن على الجهاز.

• [C-SR-1] يُنصَح بشدة باستخدام آلية التوقيع لتجزئة التحديث باستخدام خوارزمية SHA-256 والتحقق من صحة التجزئة وفقًا للمفتاح العام باستخدام P-256 وفقًا لمعيار ECDSA.

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

• [C-1-1] يجب إتاحة عمليات التنزيل عبر الهواء مع التحديث بلا اتصال بالإنترنت عن طريق إعادة التشغيل.

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

يجب أيضًا أن تتوافق عمليات تنفيذ الأجهزة مع تحديثات نظام A/B. ينفذ AOSP هذه الميزة باستخدام عنصر التحكم في التشغيل HAL.

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

• [C-2-1] يجب على أداة تنفيذ الجهاز تصحيح الخطأ من خلال تحديث برنامج متاح يمكن تطبيقه وفقًا للآلية الموضّحة للتو.

يشتمل Android على ميزات تتيح لتطبيق "مالك الجهاز" (إذا كان متوفرًا) للتحكّم في تثبيت تحديثات النظام. إذا أبلغ النظام الفرعي لتحديث النظام للأجهزة عن android.software.device_admin عندها، سيتم:

• يجب أن ينفِّذ [C-3-1] السلوك الموضّح في الفئة SystemUpdatePolicy.

12. سجل التغييرات في المستند

في ما يلي ملخص للتغييرات التي تم إجراؤها على "تعريف التوافق" في هذا الإصدار:

‫4 أكتوبر 2023

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

• 2.2.5. نموذج الأمان:

  عرض النسخة السابقة

  • [9.8/H-1-14] يجب عرض مؤشر الميكروفون، كما هو موضح في القسم 9.8.2 [9.8/C-3-1]، عند إرسال نتيجة ناجحة للكلمة المفتاح إلى الصوت.

• 2.2.7.1 الوسائط:

  عرض النسخة السابقة

  • [5.1/H-1-7] يجب أن يبلغ وقت استجابة إعداد برنامج الترميز 40 ملي ثانية أو أقل لجلسة ترميز الفيديو بدقة 1080p أو أقل لجميع برامج ترميز الفيديو للأجهزة عندما يكون قيد التحميل. يُعرَّف التحميل هنا على أنه جلسة متزامنة لتحويل ترميز الفيديو بين 1080p و720p باستخدام برامج ترميز الفيديو للأجهزة بالإضافة إلى إعداد تسجيل الصوت والفيديو بدقة 1080p. بالنسبة إلى برنامج ترميز Dolby Vision، يجب أن يبلغ وقت استجابة إعداد برنامج الترميز 50 ملي ثانية أو أقل.

  • [5.1/H-1-12] يجب أن يبلغ وقت استجابة إعداد برنامج الترميز 40 ملي ثانية أو أقل لجلسة فك ترميز الفيديوهات بدقة 1080p أو أقل لجميع برامج فك ترميز الفيديوهات على الأجهزة عندما تكون قيد التحميل. يُعرف التحميل هنا على أنه جلسة متزامنة لتحويل ترميز الفيديو بين 1080p و720p باستخدام برامج ترميز الفيديو للأجهزة بالإضافة إلى إعداد تشغيل الصوت والفيديو بدقة 1080p. بالنسبة إلى برنامج ترميز Dolby Vision، يجب أن يبلغ وقت استجابة إعداد برنامج الترميز 50 ملي ثانية أو أقل.

  • [5.1/H-1-13] يجب أن يبلغ وقت استجابة إعداد برنامج الترميز 30 ملي ثانية أو أقل لجلسة فك ترميز الصوت بمعدل 128 كيلوبت في الثانية أو أقل لجميع برامج فك ترميز الصوت عندما تكون قيد التحميل. يُعرَّف التحميل هنا على أنّه جلسة متزامنة لتحويل ترميز الفيديو بين 1080p و720p باستخدام برامج ترميز الفيديو على الأجهزة بالإضافة إلى إعداد تشغيل الصوت والفيديو بدقة 1080p.

7.4. إمكانية اتصال البيانات

• 7.4.1.1. التوافق مع حظر الأرقام:

  عرض النسخة السابقة

  إذا أبلغت عمليات تنفيذ الأجهزة عن ميزة "android.hardware.telephony.calling"، سيتم ما يلي:

• 7.4.1.2. واجهة برمجة تطبيقات الاتصالات:

  عرض النسخة السابقة

  في حال أبلغت عمليات تنفيذ الأجهزة عن android.hardware.telephony.calling، سينطبق التالي على:

9.11. المفاتيح وبيانات الاعتماد

• 9.11.2. StrongBox:

  عرض النسخة السابقة

  يتوفر عبر IAuthSecret HAL.

  تمت إزالة تطبيق IAR سيصبح أحد متطلبات "الضروري" في Android 14.

26 حزيران (يونيو) 2023

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

• 2.2.1. الأجهزة

  • المتطلبات التي تمت إزالتها 7.2.3/H-0-5، 7.2.3/H-0-6، 7.2.3/H-0-7

  • تعديل آخر:

    عرض النسخة السابقة

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

• 2.5.1. الأجهزة

  عرض النسخة السابقة

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

  • [7.6.1/A-1-1] يجب أن يكون حجم الذاكرة المتاحة للنواة ومساحة المستخدم 512 ميغابايت على الأقل في حال استخدام أي من الكثافات التالية:

    • 280 نقطة لكل بوصة أو أقل على الشاشات الصغيرة أو العادية
    • ldpi أو أقل على الشاشات الكبيرة جدًا
    • mdpi أو أقل على الشاشات الكبيرة

  • [7.6.1/A-1-2] يجب أن يكون حجم الذاكرة المتاحة للنواة ومساحة المستخدم 608 ميغابايت على الأقل في حال استخدام أي من الكثافات التالية:

    • xhdpi أو أعلى على الشاشات الصغيرة/العادية
    • hdpi أو أعلى على الشاشات الكبيرة
    • mdpi أو أعلى على الشاشات الكبيرة جدًا

  • [7.6.1/A-1-3] يجب أن يكون حجم الذاكرة المتاحة للنواة ومساحة المستخدم 896 ميغابايت على الأقل في حال استخدام أي من الكثافات التالية:

    • 400 نقطة لكل بوصة أو أعلى على الشاشات الصغيرة أو العادية
    • xhdpi أو أعلى على الشاشات الكبيرة
    • tvdpi أو أعلى على الشاشات الكبيرة جدًا

  • [7.6.1/A-1-4] يجب أن يكون حجم الذاكرة المتاحة للنواة ومساحة المستخدم 1344 ميغابايت على الأقل في حال استخدام أي من الكثافات التالية:

    • 560 نقطة لكل بوصة أو أعلى على الشاشات الصغيرة أو العادية
    • 400 نقطة لكل بوصة أو أكثر على الشاشات الكبيرة
    • xhdpi أو أعلى على الشاشات الكبيرة جدًا

‫3. البرامج

• 3.2.3.5. عناصر Intent للتطبيق المشروطة

  عرض النسخة السابقة

  إذا أبلغت عمليات تنفيذ الأجهزة عن android.hardware.telephony.calling android.hardware.telephony:

‫7. توافُق الأجهزة

• 7.4. إمكانية اتصال البيانات

  عرض النسخة السابقة

  متطلبات معايرة الحضور:

‫9. توافق نموذج الأمان

• 9.1 الأذونات

  عرض النسخة السابقة

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

  • [C-0-5] يجب ألا يمنح أي أذونات تشغيل للتطبيقات المثبَّتة مسبقًا ما لم:

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

    أو

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

• 9.11. المفاتيح وبيانات الاعتماد

  • تمت إزالة المتطلبات [C-13-10] و9.11.4.

20 آذار (مارس) 2023

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

• 2.2.3. البرامج

  عرض النسخة السابقة

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

  • يجب أن يحتوي [C-17-13.2.3.1/ H-1-1] على نشاط يعالج نية Settings#ACTION_SETTINGS_DOCUMENT_DEEP_LINK_ACTIVITY عندما تكون وظيفة التقسيم مفعَّلة. يجب أن يكون النشاط محميًا بواسطة android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK، ويجب أن يبدأ نشاط Intent الذي تم تحليله من Settings#EXTRA_SETTINGS_DOCUMENTDED_DEEP_LINK_INTENT_URI.

  إنهاء المتطلبات الجديدة

• 2.3.2 وسائط متعددة

  عرض النسخة السابقة

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

  • [5.3.7/T-2-1SR1] يُنصح بشدة باعتماد الملف الشخصي لفك ترميز المحتوى بدقة فائقة بسرعة 60 لقطة في الثانية مع الملف الشخصي 2 (عمق الألوان 10 بت).

• 2.5.1. الأجهزة

  عرض النسخة السابقة

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

  • [7.3/A-0-1SR1] قد تتأثّر الموقع الجغرافي من خلال دمج نظام تحديد المواقع العالمي (GPS)/نظام GNSS مع أدوات استشعار إضافية. إذا تم احتساب الموقع الجغرافي، يُنصَح بشدة بتطبيق أنواع أداة الاستشعار المقابلة و/أو معرّفات خصائص المركبات المستخدَمة والإبلاغ عنها.

  • [7.3/A-0-20-4] يجب ألا تتطابق الموقع الجغرافي المطلوب عبر LocationManager#requestLocationUpdates() مع الخريطة.

‫3. البرامج

• 3.18. جهات الاتصال

  عرض النسخة السابقة

  حساب تلقائي لجهات الاتصال الجديدة: يوفّر "مقدِّم خدمات جهات الاتصال" واجهات برمجة التطبيقات لإدارة إعداد الحساب التلقائي عند إنشاء جهة اتصال جديدة.

  في حال تحميل تطبيق جهات الاتصال مسبقًا على الجهاز، سيعمل تطبيق جهات الاتصال المحمَّل مسبقًا على:

  • [C-2-1] يجب أن يتعامل مع intent ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT لإطلاق واجهة مستخدم لاختيار الحساب وحفظ الإعداد في "مقدِّم جهات الاتصال" عند اختيار حساب.

  • يجب أن يلتزم [C-2-2] بإعدادات الحساب التلقائية عند التعامل مع Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT في ContactsContracts.Contacts.CONTENT_TYPE وContactsContract.RawContacts.CONTENT_TYPE من خلال اختيار الحساب في البداية.

  إنهاء المتطلبات الجديدة

• 3.2.3.5. عناصر Intent للتطبيق المشروطة

  عرض النسخة السابقة

  [تم النقل إلى الإصدار 2.2.3]

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

  • [C-17-1] يجب أن يكون له نشاط يعالج Settings#ACTION_SETTINGS_DOCUMENT_DEEP_LINK_ACTIVITY عند تفعيل وظيفة التقسيم. يجب أن يكون النشاط محميًا بواسطة android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK، ويجب أن يبدأ نشاط Intent الذي تم تحليله من Settings#EXTRA_SETTINGS_DOCUMENTDED_DEEP_LINK_INTENT_URI.

  إنهاء المتطلبات الجديدة

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

• 6.1. أدوات المطوّرين

  عرض النسخة السابقة

  • قرد
    • [C-0-8] يجب أن يشتمل على إطار عمل Monkey جعله متاحًا للاستخدام في التطبيقات.

‫7. توافُق الأجهزة

• 7.3.13. معيار IEEE 802.1.15.4 (UWB)

  عرض النسخة السابقة

  [تم النقل إلى الإصدار 7.4.9]

  إذا كانت عمليات تنفيذ الأجهزة تشمل التوافق مع 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-1-6] يُنصح بشدة باجتياز اختبارات المطابقة والشهادات ذات الصلة التي تحدّدها المؤسسات العادية، بما في ذلك FIRA وCCC وCSA.

  إنهاء المتطلبات الجديدة

• 7.4.1. الاتصالات الهاتفية

  عرض النسخة السابقة

  في حال كانت عمليات تنفيذ الأجهزة تتضمن الاتصال الهاتفي GSM أو CDMAبالإبلاغ عن ميزة 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 عند إرسال الرسائل القصيرة ورسائل الوسائط المتعددة واستلامها. يفي تنفيذ مرجع AOSP في الحزم/التطبيقات/المراسلة بهذا الشرط.
  • [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 أو التحكّم فيها.

  في حال تضمين اتصال هاتفي من خلال بروتوكول GSM أو CDMAفي عمليات تنفيذ الجهاز، يجب الإبلاغ عن ميزة android.hardware.telephony وتقديم شريط حالة للنظام، يجب عندها:

  • [C-6-7-1] يجب اختيار اشتراك تمثيلي نشط لرقم تعريف مستخدم فردي (UUID) لمجموعة معيّنة من أجل عرضه للمستخدم في أي ميزات توفِّر معلومات عن حالة شريحة SIM. تشمل الأمثلة على هذه الخصائص رمز إشارة الشبكة الخلوية في شريط الحالة أو مربع الإعدادات السريعة.
  • [C-SR-1] يُنصح بشدة باختيار اشتراك تمثيلي اشتراك بيانات نشِط ما لم يكن الجهاز في مكالمة صوتية يُنصح بشدة بأن يكون الاشتراك التمثيلي هو اشتراك Voice النشِط.

  في حال كانت عمليات تنفيذ الأجهزة تتضمن الاتصال الهاتفي GSM أو CDMAبالإبلاغ عن ميزة android.hardware.telephony، يجب:

  • [C-6-87] يجب أن تكون قادرة على فتح واستخدام الحد الأقصى لعدد القنوات المنطقية (إجمالي 20 قناة) في الوقت نفسه لكل واجهة UICC وفقًا للإصدار ETSI TS 102 221.
  • [C-6-108] يجب ألّا يطبّق أي من السلوكيات التالية على تطبيقات مشغّل شبكة الجوّال النشطة (على النحو المحدَّد من قِبل TelephonyManager#getCarrierServicePackageName) تلقائيًا أو بدون تأكيد صريح من المستخدم:
    • إبطال الوصول إلى الشبكة أو تقييده
    • إبطال الأذونات
    • فرض قيود على عمليات تنفيذ التطبيقات التي تعمل في الخلفية أو التي تعمل في المقدّمة بشكل يتجاوز ميزات إدارة الطاقة الحالية المضمّنة في AOSP
    • إيقاف التطبيق أو إلغاء تثبيته

  في حال تضمين نظام GSM أو CDMA للاتصال الهاتفيبالإبلاغ عن ميزة android.hardware.telephony وتم إيقاف جميع الاشتراكات غير الانتهازية التي تتشارك في معرّف فريد عالمي (UUID) لمجموعة أو إزالتها فعليًا من الجهاز أو وضع علامة عليها كفرصة للتحسين، سيتم تنفيذ ما يلي على الجهاز:

  • [C-78-1] يجب أن يوقِف تلقائيًا جميع الاشتراكات المتاحة النشطة المتبقية في المجموعة نفسها.

  إذا كانت عمليات تنفيذ الأجهزة تتضمن اتصالات هاتفية عبر بروتوكول GSM لكن لا تشتمل على اتصال هاتفي عبر CDMA، فإنها:

  • [C-89-1] يجب ألّا تعلن عن PackageManager#FEATURE_TELEPHONY_CDMA.
  • [C-89-2] يجب استخدام IllegalArgumentException عند محاولة ضبط أي نوع من أنواع شبكات 3GPP2 على أقنعة بتات من نوع الشبكة المفضّلة أو المسموح بها.
  • [C-89-3] يجب أن تعرض سلسلة فارغة من TelephonyManager#getMeid.

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

  • [C-1110-1] يجب أن تشير إلى علامة android.hardware.telephony.euicc.mep الميزة.

• 7.4.9. النطاق الفائق العرض (UWB)

  عرض النسخة السابقة

  في حال إبلاغ عمليات تنفيذ الأجهزة عن توفُّر الميزة android.hardware.uwb من خلال android.content.pm.PackageManager فئة، في حال كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية التوافق مع 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-16] يجب أن تكون قياسات المسافة ضمن +/-15 سم بالنسبة إلى 95% من القياسات في بيئة خط الرؤية على مسافة 1 متر في غرفة غير عاكسة.
  • [C-1-27] يجب أن يتأكد من أن متوسط قياسات المسافة على متر واحد من الجهاز المرجعي يكون في نطاق [0.75 متر أو 1.25 متر]، حيث يتم قياس مسافة الأرض من الحافة العلوية من الحافة العلوية من طرف الشاشة لتوجيهها نحو الأعلى وإمالتها بمقدار 45 درجة.
  • [C-SR-2] يُنصَح بشدة باتّباع خطوات إعداد القياس الموضحة في متطلبات معايرة الحضور.

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

  إنهاء المتطلبات الجديدة

• 7.8.2.2. منافذ الصوت الرقمية

  عرض النسخة السابقة

  لكي يتم التوافق مع سماعات الرأس وملحقات الصوت الأخرى التي تستخدم موصِّلات USB-C وتنفيذ (فئة USB Audio) على منظومة Android المتكاملة على النحو المحدّد في مواصفات سمّاعات الرأس USB (Android).

19 تشرين الأول (أكتوبر) 2022

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

• 2.2.3 البرامج

  عرض النسخة السابقة

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

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

‫3. البرامج

• 3.2.3.5. عناصر Intent للتطبيق المشروطة

  عرض النسخة السابقة

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

  • يجب أن يكون لدى [C-17-1] نشاط يعالج الغرض من إعداد Settings#ACTION_SETTINGS_DOCUMENT_DEEP_LINK_ACTIVITY عندما تكون وظيفة التقسيم مفعَّلة. يجب أن يكون النشاط محميًا بواسطة android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK، كما يجب أن يبدأ نشاط Intent الذي تم تحليله من Settings#EXTRA_SETTINGS_DOCUMENTDED_DEEP_LINK_INTENT_URI.

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

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

• 3.4.1 التوافق مع Webview

  عرض النسخة السابقة

  • [C-1-4]يجب عرض المحتوى المقدَّم أو محتوى عنوان URL البعيد في عملية مختلفة عن التطبيق الذي ينشئ مثيلاً لمكوّن WebView. وعلى وجه التحديد، يجب أن تحصل عملية العارض المنفصل على امتيازات أقل، وتعمل كمعرّف مستخدم منفصل، ولا يمكنها الوصول إلى دليل بيانات التطبيق، ولا يمكنها الوصول مباشرةً إلى الشبكة، ولا يمكنها الوصول إلا إلى الحد الأدنى من خدمات النظام المطلوبة من خلال Binder. يستوفي هذا الشرط الذي نفَّذته بروتوكول AOSP في WebView لهذا الشرط.

‫7. توافُق الأجهزة

• 7.4.2 IEEE 802.11 (لشبكات Wi-Fi)

  عرض النسخة السابقة

  إذا كانت عمليات تنفيذ الأجهزة تتضمّن توافقًا مع وضع توفير الطاقة عبر شبكة Wi-Fi على النحو المحدّد في معيار IEEE 802.11، سيتم إجراء ما يلي:

  • [C-3-1] يجب إيقاف وضع توفير الطاقة بشبكة Wi-Fi عندما يتم اكتشاف WIFI_MODE_FULL_HIGH_PERF قفل أو WIFI_MODE_FULL_LOW_LATENCY قفل عبر WifiManager.createWifiLock() وWifiManager.WifiLock.acquire()

• 7.4.3 البلوتوث

  عرض النسخة السابقة

  إذا كانت عمليات تنفيذ الأجهزة تتضمّن توافقًا مع تقنية Bluetooth Low Energy (BLE)، سيتم إجراء ما يلي:

  • [C-3-5] يجب تنفيذ مهلة لا تزيد عن 15 دقيقة للعنوان الخاص القابل للتحليل، مع تدوير العنوان عند انتهاء المهلة لحماية خصوصية المستخدم عندما يستخدم الجهاز تقنية BLE لفحصها أو لعرض الإعلانات. لمنع هجمات التوقيت، يجب أيضًا توزيع الفواصل الزمنية بشكل عشوائي تتراوح بين 5 و15 دقيقة.

• 7.5.5 اتجاه الكاميرا

  عرض النسخة السابقة

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

  • [C-1-1] يجب أن يكون موجهًا بحيث يتوافق بُعد الكاميرا الطويل مع البعد الطويل للشاشة. أي أنّه عند تثبيت الجهاز في الاتجاه الأفقي، يجب أن تلتقط الكاميرات الصور في الاتجاه الأفقي. ويسري ذلك بغض النظر عن الاتجاه الطبيعي للجهاز، أي ينطبق على الأجهزة الأساسية ذات الوضع الأفقي، وكذلك على الأجهزة ذات الاتجاه الرأسي الأساسي.

  تُستثنى من الشرط أعلاه الأجهزة التي تستوفي جميع المعايير التالية:

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

  إنهاء المتطلبات الجديدة

‫9. توافق نموذج الأمان

• المفاتيح وبيانات الاعتماد 9.11

  عرض النسخة السابقة

  عندما يكون تنفيذ الجهاز متوافقًا مع شاشة قفل آمنة:

  • [C-1-6] يجب أن يتوافق مع IKeymasterDevice 4.0 أو IKeymasterDevice 4.1 أو الإصدار 1 من IKeyMintDevice أو الإصدار 2 من IKeyMintDevice.

• 9.17 إطار عمل المحاكاة الافتراضية لنظام التشغيل Android

  عرض النسخة السابقة

  إذا كان الجهاز يتوافق مع واجهات برمجة التطبيقات (API) الخاصة بإطار عمل المحاكاة الافتراضية لنظام التشغيل Android (android.system.virtualmachine.*)، سينفّذ مضيف Android ما يلي:

  • [C-1-3] يجب ألا يعدل القواعد أو يحذفها أو يستبدلها أبدًا

  إذا نفِّذ الجهاز توافقًا مع واجهات برمجة التطبيقات (API) لإطار عمل المحاكاة الافتراضية لنظام التشغيل Android (android.system.virtualmachine.*)، سيتم عندها تنفيذ أي مثيل للجهاز الافتراضي المحمي:

  • [C-2-4] يجب ألا يعدّل أو يحذف أو يستبدل قواعد "Neverallow" الموجودة ضمن النظام/sepolicy/microdroid المقدَّم في "المشروع المفتوح المصدر لنظام Android" (AOSP).

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

  • [C-6-2] يجب استخدام DICE بشكل صحيح، أي توفير القيم الصحيحة ولكن قد لا تضطر إلى الانتقال إلى هذا المستوى من التفاصيل.

15 آب (أغسطس) 2022

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

• 2.2.1 الأجهزة: يتم إجراء تغييرات على متطلبات الأجهزة على النحو التالي.

  • أجهزة الإدخال:

    عرض النسخة السابقة

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

    • [7.2.3/H-0-5] يجب استدعاء OnBackInvokedCallback.onBackStarted() في النافذة التي يتم التركيز عليها الحالية عند بدء إيماءة الرجوع أو الضغط على زر الرجوع (KEYCODE_BACK) لأسفل.
    • [7.2.3/H-0-6] يجب الاتصال بـ OnBackInvokedCallback.onBackInvoked() عند الالتزام بإيماءة الرجوع أو عند رفع إصبعك عن الزر "رجوع".
    • يجب أن يتصل [7.2.3/H-0-7] بـ OnBackInvokedCallback.onBackCancelled() عندما لا يتم تنفيذ إيماءة الرجوع أو يتم إلغاء حدث KEYCODE_BACK.

    إنهاء المتطلبات الجديدة

    إذا كانت الأجهزة تتوافق مع بروتوكول الاتصال بشبكة Wi-Fi المجاورة (NAN) من خلال الإعلان عن PackageManager.FEATURE_WIFI_AWARE وعرض الموقع الجغرافي لشبكة Wi-Fi (الوقت ذهابًا وإيابًا عبر شبكة Wi-Fi والمراسلة النصية في الوقت الفعلي) من خلال الإعلان عن السمة PackageManager.FEATURE_WIFI_RTT، سيتم إجراء ما يلي:

    • [7.4.2.5/H-1-1] يجب أن يبلغ النطاق بدقة في نطاق يتراوح بين 6 و1/2 متر في نطاق تردد يتراوح من 6.5 متر في نطاق 5 متر و-1 متر عند نطاق ترددي 160 ميغاهرتز في النطاق المئوي 68 ميغاهرتز (وفقًا لحسابات دالة التوزيع التراكمي)، في نطاق تردد يتراوح من 80 ميغاهرتز ونطاق ترددي 80 ميغاهرتز ونطاق نقل بيانات يبلغ 4 ميغاهرتز عند نطاق 40 ميغاهرتز.

    • [7.4.2.5/H-SR] يُنصَح بشدة بأن يتم الإبلاغ عن النطاق الترددي 8 في المئة بنطاق يتراوح بين +/-1 متر عند نطاق 0 في المئة من النطاق الترددي +/-1 ميغاهرتز عند النطاق المئوي 160 ميغاهرتز (وفقًا لحسابات دالة التوزيع التراكمي)، في معدّل نقل البيانات بتردد 80 ميغاهرتز عند الشريحة المئوية التسعين (+/-4 ميغاهرتز) عند نطاق ترددي يبلغ 4 ميغاهرتز.

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

    إنهاء المتطلبات الجديدة

  • وقت استجابة الصوت:

    عرض النسخة السابقة

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

    • يجب أن يكون للمسار [5.6/H-1-1] متوسط وقت استجابة رحلات ذهاب وعودة متواصل (يبلغ مدّة الاستجابة 500)، 800 مللي ثانية أو أقل من 5 قياسات، مع متوسط انحراف مطلق أقل من 50 100 مللي ثانية، عبر البيانات التالية: "إعادة مكبّر الصوت إلى الميكروفون". يجب توفُّر مسار واحد على الأقل.

    • [5.6/H-1-1] يجب أن يبلغ متوسط وقت استجابة "النقر للنغمة" 500 مللي ثانية أو أقل من 5 قياسات على الأقل عبر مسار بيانات مكبّر الصوت إلى الميكروفون.

    إنهاء المتطلبات الجديدة

  • مصادر الإدخال الملموسة:

    عرض النسخة السابقة

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

    • [7.10/H]* يجب عدم استخدام كتلة دوّارة غريبة الأطوار (ERM) مشغّلة باللمس (هزّاز).
    • [7.10/H]* يجب أن يكون موضع تشغيل المشغّل بالقرب من المكان الذي يتم فيه عادةً مسك الجهاز أو لمسه باليد.
    • [7.10/H]* يجب تنفيذ جميع الثوابت العامة لكل اللمسات الواضحة في android.view.HapticFeedbackConstants تحديدًا (CLOCK_TICK وCONTEXT_نقرة وKEYBOARD_PRESS وKEYBOARD_Release وKEYBOARD_TAP وLOW_TEXT_PRESS
    • [7.10/H]* يجب تنفيذ كل الثوابت العامة لكل من اللمسات الواضحة التي تعمل باللمس في android.os.VibrationEffect على سبيل المثال (رسوم_TICK، ومرة_click، ومرة_HEAVY_click ومؤثر_DOUBLE_نقرة) كل الثوابت العامة للتقنية الماسية الواضحة. PRIMITIVE_* } وقد لا يكون ممكنًا استخدام بعض هذه الأساسيات، مثل LOW_TICK وSPIN، إلا إذا كان الهزّاز يتيح عمل الترددات المنخفضة نسبيًا.

    • [7.10/H]* يجب اتّباع الإرشادات المتعلقة بتعيين الثوابت العامة في android.view.HapticFeedbackConstants مع ثوابت android.os.VibrationEffect المقترَحة، مع علاقات السعة المقابلة.

    إنهاء المتطلبات الجديدة

    • [7.10/H]* يجب استخدام هذه الثوابت الملموسة المرتبطة في عمليات التعيين.

    • يجب التحقّق [7.10/H]* من أنّ نتيجة واجهة برمجة التطبيقات android.os.Vibrator.hasAmplitudeControl() المتاحة للجميع تعكس إمكانيات الهزّاز بشكل صحيح.

    إنهاء المتطلبات الجديدة

    • [7.10/H]* يجب التحقق من إمكانات قابلية التوسع للسعة من خلال تشغيل android.os.Vibrator.hasAmplitudeControl().

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

    • يجب تحريك [7.10/H]* للمشغّل باللمس على المحور "س" (من اليسار إلى اليمين) في الاتجاه العمودي.

    • [7.10/H]* يجب التحقّق من الإعدادات الاحتياطية للمعايير الأساسية غير المتوافقة وتعديلها إذا لزم الأمر، كما هو موضّح في إرشادات التنفيذ الخاصة بالثوابت.

    • [7.10/H]* يجب توفير دعم احتياطي للتخفيف من مخاطر الإخفاق كما هو موضّح هنا.

• 2.2.3 البرامج:

  • رموز معلومات قديمة حول الأجهزة:

    عرض النسخة السابقة

    • [3.8.16/H-1-5] يجب أن يوفر للمستخدم إمكانية إيقاف التطبيق المخصص للمصادقة البسيطة على الأجهزة من عناصر التحكم المسجَّلة بواسطة التطبيقات التابعة لجهات خارجية من خلال واجهة برمجة التطبيقات ControlsProviderService وControl Control.isAuthRequired.

  • إشعارات MediaStyle:

    عرض النسخة السابقة

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

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

• 2.2.4 الأداء والتشغيل: متطلبات جديدة للتطبيقات التي تعمل في الخدمات التي تعمل في المقدّمة.

  عرض النسخة السابقة

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

  • [8.5/H-0-1] يجب أن يوفر للمستخدمين في قائمة "الإعدادات" إمكانية إيقاف تطبيق يشغِّل خدمة تعمل في المقدّمة وعرض جميع التطبيقات التي تحتوي على خدمات تعمل في المقدّمة، ومدة كل خدمة من هذه الخدمات منذ بدئها كما هو موضح في مستند SDK.
    • قد تُستثنى بعض التطبيقات من أن يتم إيقافها أو أن يتم إدراجها ضِمن هذه التطبيقات حتى الآن، كما هو موضّح في مستند حزمة تطوير البرامج (SDK).

  إنهاء المتطلبات الجديدة

• 2.2.7.1 الوسائط: تعديلات على قسم "وسائط المتطلبات التي يتم تداولها باليد" على النحو التالي:

  عرض النسخة السابقة

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

  • [5.1/H-1-1] يجب الإعلان عن الحد الأقصى لعدد جلسات برنامج فك ترميز الفيديوهات على الأجهزة التي يمكن تشغيلها بشكل متزامن في أي مجموعة من برامج الترميز من خلال طريقتَي CodecCapabilities.getMaxSupportedInstances() وVideoCapabilities.getSupportedPerformancePoints().
  • [5.1/H-1-2] يجب أن يتوفر في 6 حالات لجلسات برنامج فك ترميز الفيديو على الجهاز (AVC أو HEVC أو VP9 أو AV1 أو أحدث) في أي مجموعة برامج ترميز يتم تشغيلها بدرجة دقة 1080p بسرعة 30 لقطة في الثانية.
  • [5.1/H-1-3] يجب الإعلان عن الحد الأقصى لعدد جلسات برنامج ترميز الفيديو على الأجهزة التي يمكن تشغيلها بالتزامن في أي تركيبة من برامج الترميز عبر طريقتَي CodecCapabilities.getMaxSupportedInstances() وVideoCapabilities.getSupportedPerformancePoints().
  • [5.1/H-1-4] يجب أن يتوفر في 6 نسخ من جلسات برنامج ترميز الفيديو على الجهاز (AVC أو HEVC أو VP9 أو AV1 أو أحدث) في أي مجموعة برامج ترميز يتم تشغيلها بالدقة 1080p بسرعة 30 لقطة في الثانية.
  • [5.1/H-1-5] يجب الإعلان عن الحد الأقصى لعدد جلسات برنامج ترميز الفيديو والأجهزة التي يمكن تشغيلها بالتزامن في أي تركيبة من برامج الترميز عبر طريقتَي CodecCapabilities.getMaxSupportedInstances() وVideoCapabilities.getSupportedPerformancePoints().
  • [5.1/H-1-6] يجب أن يتوفّر في 6 نسخ من برنامج فك ترميز الفيديو على الجهاز وجلسات ترميز الفيديوهات على الأجهزة (AVC أو HEVC أو VP9 أو AV1 أو الإصدارات الأحدث) في أي مجموعة برامج ترميز يتم تشغيلها بالتزامن بدقة 1080p بسرعة 30 لقطة في الثانية.
  • [5.1/H-1-7] يجب أن يبلغ وقت استجابة إعداد برنامج الترميز 40 ملي ثانية أو أقل لجلسة ترميز الفيديو بدقة 1080p أو أقل لجميع برامج ترميز الفيديو للأجهزة عندما يكون قيد التحميل. يُعرَّف التحميل هنا على أنه جلسة متزامنة لتحويل ترميز الفيديو بين 1080p و720p باستخدام برامج ترميز الفيديو للأجهزة بالإضافة إلى إعداد تسجيل الصوت والفيديو بدقة 1080p.
  • [5.1/H-1-8] يجب أن يبلغ وقت استجابة إعداد برنامج الترميز 30 ملي ثانية أو أقل لجلسة ترميز صوتي بمعدل 128 كيلوبت في الثانية أو بمعدل نقل بيانات أقل لجميع برامج ترميز الصوت عندما تكون قيد التحميل. يُعرَّف التحميل هنا على أنّه جلسة متزامنة لتحويل ترميز الفيديو بين 1080p و720p باستخدام برامج ترميز الفيديو على الأجهزة بالإضافة إلى إعداد تسجيل الصوت والفيديو بدقة 1080p.
  • [5.1/H-1-9] يجب أن يتوفر في نسختين لجلسات فك ترميز فيديو الأجهزة الآمنة (AVC أو HEVC أو VP9 أو AV1 أو أحدث) في أي مجموعة برامج ترميز يتم تشغيلها بالدقة 1080p بسرعة 30 لقطة في الثانية.
  • [5.1/H-1-10] يجب أن يتم توفير 3 جلسات لجلسات فك ترميز الفيديوهات على الأجهزة غير الآمنة مع جلسة واحدة لجلسة فك ترميز الفيديوهات على الأجهزة الآمنة (إجمالي 4 مثيلات) (AVC أو HEVC أو VP9 أو AV1 أو أحدث) في أي مجموعة برامج ترميز يتم تشغيلها بالتزامن بدقة 1080p بسرعة 30 لقطة في الثانية.
  • [5.1/ H-1-11] يجب أن يتوافق مع برنامج فك ترميز آمن لكل برنامج فك ترميز AVC أو HEVC أو VP9 أو AV1 على الجهاز.
  • [5.1/H-1-12] يجب أن يبلغ وقت استجابة إعداد برنامج فك ترميز الفيديو 40 ملي ثانية أو أقل.
  • [5.1/H-1-13] يجب أن يبلغ وقت استجابة إعداد برنامج فك ترميز الصوت 30 ملي ثانية أو أقل.
  • [5.1/H-1-14] يجب أن يتوافق مع برنامج فك ترميز الأجهزة AV1 الرئيسي 10، المستوى 4.1.
  • [5.1/H-SR] يُنصح بشدة باستخدام ميزة "تحبب الأفلام" مع برنامج فك ترميز أجهزة AV1.
  • يجب أن يحتوي [5.1/H-1-15] على برنامج فك ترميز فيديو واحد على الأقل يتوافق مع 4K60.
  • يجب أن يتوفّر في الأجهزة [5.1/H-1-16] برنامج ترميز فيديو واحد على الأقل متوافق مع دقة 4K60.
  • [5.3/H-1-1] يجب ألا يتم إسقاط أكثر من إطار واحد خلال 10 ثوانٍ (أي أقل من 0.167 في المئة من انخفاض اللقطات) في جلسة فيديو بدقة 1080p بمعدّل 60 لقطة في الثانية قيد التحميل. يُعرف التحميل على أنّه جلسة متزامنة لتحويل ترميز الفيديو بين 1080p و720p باستخدام برامج ترميز الفيديو على الأجهزة، بالإضافة إلى تشغيل الصوت بتنسيق AAC بسرعة 128 كيلوبت في الثانية وبسرعة 128 كيلوبت في الثانية.
  • [5.3/H-1-2] يجب ألا يتم إسقاط أكثر من إطار واحد خلال 10 ثوانٍ أثناء تغيير درجة دقة الفيديو في جلسة فيديو بمعدّل 60 لقطة في الثانية أثناء التحميل. يُعرف التحميل على أنّه جلسة متزامنة لتحويل ترميز الفيديو فقط تتراوح بين 1080p و720p باستخدام برامج ترميز الفيديو على الأجهزة، بالإضافة إلى تشغيل الصوت بتنسيق AAC بسرعة 128 كيلوبت في الثانية وبسرعة 128 كيلوبت في الثانية.
  • [5.6/H-1-1] يجب أن يكون وقت استجابة النقر للنغمات 80 مللي ثانية أو أقل باستخدام اختبار النقر للنغمات في OboeTester أو اختبار CTS Verifier انقر للنغمات.
  • [5.6/H-1-2] يجب أن يكون وقت استجابة الصوت ذهابًا وإيابًا 80 ملي ثانية أو أقل عبر مسار بيانات واحد متوافق على الأقل.
  • [5.6/H-1-3] يجب أن يتوافق مع صوت أكبر من أو يساوي 24 بت لإخراج صوت استيريو يزيد عن مقابس صوت 3.5 ملم في حال توفّرها ومع الصوت عبر USB إذا كان ذلك متاحًا من خلال مسار البيانات بالكامل لإعدادات البث ووقت الاستجابة المنخفض. لإعداد وقت الاستجابة المنخفض، يجب أن يستخدم التطبيق AAudio في وضع معاودة الاتصال بوقت الاستجابة المنخفض. بالنسبة إلى إعدادات البث، يجب أن يستخدم التطبيق مقطعًا صوتيًا Java. في كل من إعدادات وقت الاستجابة المنخفض والبث، يجب أن يقبل حوض إخراج HAL إما AUDIO_FORMAT_PCM_24_BIT أو AUDIO_FORMAT_PCM_24_BIT_PACKED أو AUDIO_FORMAT_PCM_32_BIT أو AUDIO_FORMAT_PCM_FLOAT لتنسيق الإخراج المستهدف.
  • [5.6/H-1-4] يجب أن يتوافق مع أكثر من = 4 أجهزة صوت USB (تُستخدم هذا بواسطة وحدات التحكم في DJ لمعاينة الأغاني.)
  • [5.6/H-1-5] يجب أن تتوافق مع أجهزة MIDI المتوافقة مع الفئة وأن تعلن عن علامة ميزة MIDI.
  • [5.7/H-1-2] يجب أن يكون متوافقًا مع MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL مع إمكانات فك تشفير المحتوى الواردة أدناه.

  الحد الأدنى لحجم العينة	4 مبيبايت
  الحد الأدنى لعدد العيّنات الفرعية: H264 أو HEVC	32
  الحد الأدنى لعدد العيّنات الفرعية - VP9	9
  الحدّ الأدنى لعدد العيّنات الفرعية: AV1	288
  الحد الأدنى لحجم ذاكرة التخزين المؤقت للعينة الفرعية	1 مبيبايت
  الحد الأدنى لحجم المخزن المؤقت العام للعملات المشفّرة	500 كيبيبايت
  الحد الأدنى لعدد الجلسات المتزامنة	30
  الحد الأدنى لعدد المفاتيح في كل جلسة	20
  الحد الأدنى لإجمالي عدد المفاتيح (جميع الجلسات)	80
  الحد الأدنى لإجمالي عدد مفاتيح DRM (جميع الجلسات)	6
  حجم الرسالة	16 كيبيبايت
  اللقطات غير المشفّرة في الثانية	60 لقطة في الثانية

  إنهاء المتطلبات الجديدة

• 2.2.7.2 الكاميرا: تعديلات على متطلبات الكاميرا في فئة أداء الوسائط.

  عرض النسخة السابقة

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

  • [7.5/H-1-1] يجب أن تحتوي على كاميرا خلفية أساسية بدقة لا تقل عن 12 ميغابكسل تتيح التقاط الفيديو بمعدل 4k بسرعة 30 لقطة في الثانية. الكاميرا الخلفية الأساسية هي الكاميرا الخلفية التي تتضمّن معرّفًا أدنى للكاميرا.
  • [7.5/H-1-2] يجب أن تتوفر كاميرا أمامية رئيسية ذات دقة لا تقل عن 5 ميغابكسل، وتتيح التقاط فيديو بدقة 1080p بسرعة 30 لقطة في الثانية. الكاميرا الأمامية الأساسية هي الكاميرا الأمامية التي لديها معرف أدنى للكاميرا.
  • [7.5/H-1-3] يجب أن يتوافق مع السمة android.info.supportedHardwareLevel على أنّه FULL أو أفضل لكلتا الكاميرتين الأساسيتين.
  • [7.5/H-1-4] يجب أن يتوافق مع CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME لكلتا الكاميرتين الأساسيتين.
  • [7.5/H-1-5] يجب أن يكون وقت استجابة الالتقاط بتنسيق JPEG في الكاميرا2 < 1,000 ملي ثانية للحصول على درجة دقة 1080p وفقًا لما تم تحديده من خلال اختبار أداء كاميرا CTS في ظل ظروف الإضاءة (3000 كيلوبايت) لكلتا الكاميرا الأساسية.
  • [7.5/H-1-6] يجب أن يكون وقت استجابة بدء تشغيل Camera2 (فتح الكاميرا لإطار المعاينة الأول) أقل من 500 مللي ثانية كما تم قياسه من خلال اختبار أداء كاميرا CTS في ظل ظروف الإضاءة في تكنولوجيا المعلومات (3000 كيلوبايت) لكلتا الكاميرتين الأساسيتين.
  • [7.5/H-1-8] يجب أن يتوافق مع CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW وandroid.graphics.ImageFormat.RAW_SENSOR للكاميرا الخلفية الأساسية.
  • [7.5/H-1-9] يجب أن تتوفر كاميرا أساسية خلفية متوافقة مع 720p أو 1080p بسرعة 240 لقطة في الثانية.
  • [7.5/H-1-10] يجب أن يكون الحد الأدنى ZOOM_RATIO أقل من 1.0 للكاميرات الأساسية في حالة وجود كاميرا ذات ألوان غامرة موسّعة تتجه نحو نفس الاتجاه.
  • [7.5/H-1-11] يجب تنفيذ بث مباشر متزامن للخلفية على الكاميرات الأساسية.
  • [7.5/H-1-12] يجب أن يتوافق مع CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION لكل من الكاميرا الأمامية والخلفية الأساسية.
  • [7.5/H-1-13] يجب أن يتوافق مع إمكانية استخدام LOGICAL_MULTI_CAMERA للكاميرات الأساسية في حال توفُّر أكثر من كاميرا واحدة بنموذج أحمر أخضر أزرق (RGB) متجهة نحو الاتجاه نفسه.
  • [7.5/H-1-14] يجب أن يتوافق مع ميزة "STREAM_USE_CASE" لكل من الكاميرا الأمامية والخلفية الأساسية.

  إنهاء المتطلبات الجديدة

• 2.2.7.3 الأجهزة: تعديلات على متطلبات "فئة أداء الوسائط" الخاصة بالأجهزة.

  عرض النسخة السابقة

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

  • [7.1.1.1/H-2-1] يجب أن تكون دقة الشاشة 1080p على الأقل.
  • [7.1.1.3/H-2-1] يجب أن تبلغ كثافة الشاشة 400 نقطة لكل بوصة على الأقلّ.
  • [7.6.1/H-2-1] يجب أن تتوفّر ذاكرة فعلية بسعة 8 غيغابايت على الأقل.

  إنهاء المتطلبات الجديدة

• 2.2.7.4 الأداء: تعديلات على فئة الأداء الإعلامي لتحسين الأداء.

  عرض النسخة السابقة

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

  • [8.2/H-1-1] يجب أن يضمن أداء كتابة تسلسلي لا يقل عن 125 ميغابايت/ثانية.
  • [8.2/H-1-2] يجب أن يضمن أداء كتابة عشوائي لا يقل عن 10 ميغابايت/ثانية.
  • [8.2/H-1-3] يجب أن يضمن أداء قراءة تسلسلي لا يقل عن 250 ميغابايت/ثانية.
  • [8.2/H-1-4] يجب أن يضمن أداء قراءة عشوائي لا يقل عن 40 ميغابايت/ثانية.

  إنهاء المتطلبات الجديدة

• 2.5.1 الأجهزة: تعديلات على متطلبات مقياس التسارع الثلاثي المحاور والجيروسكوب ثلاثي المحاور، بالإضافة إلى متطلبات كاميرا الرؤية الخارجية.

  عرض النسخة السابقة

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

  • [7.3.1/A-0-4] يجب أن يتوافق مع نظام الإحداثيات لأجهزة استشعار السيارة من Android.
  • [7.3/A-SR] يُنصح بـ strongLY_RECOMMENDED لتضمين مقياس تسارع ثلاثي المحاور وجيروسكوب ثلاثي المحاور.
  • [7.3/A-SR] يتم اقتراحها strongLY_RECOMMENDED لاستخدام أداة استشعار TYPE_HEADING والإبلاغ عنها.

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

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

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

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

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

  • [7.3.1/A-1-3] يجب استخدام أداة استشعار TYPE_ACCELEROMETER_LIMITED_AXES والإبلاغ عنها.
  • [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] يُنصح بشدة بضبط نطاق قياس الجيروسكوب ليكون +/-250 بكسل في الثانية لزيادة درجة الدقة الممكنة إلى أقصى حد.

  إنهاء المتطلبات الجديدة

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

  • [7.3.4/A-SR] يُنصح بشدة بتطبيق أداة الاستشعار المركّبة على الجيروسكوب المحاور المحدودة.

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

  • [7.3.4/A-4-1] يجب استخدام أداة استشعار TYPE_GYROSCOPE_LIMITED_AXES والإبلاغ عنها.
  • [7.3.4/A-4-2] يجب استخدام أداة استشعار TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED والإبلاغ عنها.

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

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

  إنهاء المتطلبات الجديدة

  كاميرا الرؤية الخارجية هي كاميرا تلتقط صورًا لمشاهد خارج الجهاز، مثل كاميرا الرؤية الخلفية كاميرا السيارة .

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

  • [7.5.5/A-SR] يُنصح بشدة بتوجيهها بحيث يتوافق بُعد الكاميرا الطويل مع الأفق.

  • يجب أن يتوافق مع إطار عمل مزامنة Android.

  • قد يتم تنفيذ التركيز التلقائي للجهاز أو التركيز التلقائي للبرامج في برنامج تشغيل الكاميرا.

  إذا كانت عمليات تنفيذ أجهزة السيارات تتضمّن كاميرا واحدة أو أكثر من كاميرات المراقبة الخارجية، وتحميل خدمة نظام الرؤية الخارجية (EVS)، عندئذٍ بالنسبة إلى مثل هذه الكاميرا، سيتم إجراء ما يلي:

  • [7.5/A-2-1] يجب ألا يتم تدوير معاينة الكاميرا أو عكسها أفقيًا.

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

  • قد يشتمل على كاميرا واحدة أو أكثر متاحة لتطبيقات الجهات الخارجية.

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

  • [7.5/A-3-1] يجب أن يتم الإبلاغ عن علامة الميزة android.hardware.camera.any.
  • [7.5/A-3-2] يجب ألا يتم التعريف عن الكاميرا باعتبارها كاميرا نظام.
  • قد تتوافق مع الكاميرات الخارجية الموضّحة في القسم 7.5.3.
  • قد تتضمّن ميزات (مثل ميزة "التركيز التلقائي" وغيرها) المتوفّرة للكاميرات الخلفية كما هو موضّح في القسم 7.5.1.

  إنهاء المتطلبات الجديدة

• 2.5.5 نموذج الأمان: متطلبات جديدة للحصول على أذونات الوصول إلى الكاميرا للأجهزة الخاصة بالسيارات.

  عرض النسخة السابقة

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

  • [9.8.2/A-2-1] يجب أن يعرض مؤشر الكاميرا عند وصول تطبيق إلى بيانات الكاميرا المباشرة، ولكن ليس عندما يتم الوصول إلى الكاميرا من خلال التطبيقات التي تمتلك الأدوار المذكورة في القسم 9.1 الأذونات بمعرّف CDD [C-3-X].

  • [9.8.2/A-2-2] يجب ألا يخفي مؤشر الكاميرا لتطبيقات النظام التي لها واجهات مستخدم مرئية أو تفاعل مباشر من المستخدم.

  إنهاء المتطلبات الجديدة

• 2.6.1 متطلبات الأجهزة اللوحية: الأجهزة: تعديل على متطلبات حجم شاشة الجهاز اللوحي

  عرض النسخة السابقة

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

  • أن يكون حجم عرض الشاشة أكبر من 7 بوصة وأقل من 18 بوصة، ويتم قياسه قطريًا.

  مقاس الشاشة

  • [7.1.1.1/Tab-0-1] يجب أن يتراوح نطاق الشاشة بين 7 و18 بوصة.

‫3. البرامج

• 3.2.2 إنشاء معلَمات: تم تعديل أحرف ASCII في getSerial().

  عرض النسخة السابقة

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

  المَعلمة	التفاصيل
  getSerial()	يجب أن يكون رقمًا تسلسليًا للأجهزة، على أن يكون متاحًا وفريدًا على جميع الأجهزة التي تستخدم MODEL وMANUFACTURER نفسهما. يجب أن تكون قيمة هذا الحقل قابلة لترميز ASCII المكوّن من 7 بت وأن تتطابق مع التعبير العادي “^[a-zA-Z0-9]+$”.

• 3.2.3.5 أهداف التطبيق المشروطة: تعديل على متطلبات عناصر نية التطبيق المشروطة.

  عرض النسخة السابقة

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

  • [C-17-1] يجب أن يكون لديه نشاط يعالج نية Settings#ACTION_SETTINGS_ البارزة_DEEP_LINK_ACTIVITY عند تفعيل وظيفة التقسيم. يجب أن يكون النشاط محميًا بواسطة android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK، ويجب أن يبدأ نشاط Intent الذي تم تحليله من Settings#EXTRA_SETTINGS_DOCUMENTDED_DEEP_LINK_INTENT_URI.

  إنهاء المتطلبات الجديدة

• 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-9] يجب الإبلاغ عن جميع أحداث القيود المفروضة على الملكية هذه من خلال UsageStats.

  • [C-1-10] يجب أن يقدم مستندًا أو موقعًا إلكترونيًا عامًا وواضحًا يصف كيفية تطبيق قيود الملكية. يجب أن يكون هذا المستند أو موقع الويب قابلاً للربط من مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android، كما يجب أن يتضمنا ما يلي:

    • شروط تشغيل القيود المفروضة على الملكية
    • تعريف أحد التطبيقات وطريقة حظره
    • كيفية استثناء تطبيق من هذه القيود
    • كيف يمكن لتطبيق طلب إعفاء من القيود المفروضة على الملكية إذا كان يتيح هذا الاستثناء للتطبيقات التي يمكن للمستخدم تثبيتها.

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

  إنهاء المتطلبات الجديدة

• 3.8.1 مشغّل التطبيقات (الشاشة الرئيسية): تعديلات على توافق monochrome/adaptive-icon

  عرض النسخة السابقة

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

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

  إنهاء المتطلبات الجديدة

• 3.8.2 التطبيقات المصغّرة: تتيح لك هذه الصفحة إجراء تحديث لظهور التطبيقات المصغّرة التابعة لجهات خارجية في "مشغّل التطبيقات".

  عرض النسخة السابقة

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

  • يجب أن يشتمل [C-1-2] على دعم مضمّن لـ AppWidgets وأن يعرض ميزات واجهة المستخدم لإضافة أدوات AppWidget وإعدادها وعرضها وإزالتها مباشرةً من "مشغّل التطبيقات".

• 3.8.3.1 عرض الإشعارات: توضيح تعريف إشعارات التنبيه.

  عرض النسخة السابقة

  إشعارات التنبيه هي إشعارات يتم تقديمها إلى المستخدم عندما تأتي بشكل مستقل عن المساحة التي يظهر عليها.

• 3.8.3.3 DND (عدم الإزعاج) / "وضع الأولوية": تعديل لتضمين "وضع الأولوية" في متطلبات وضع "عدم الإزعاج" (DND)

  عرض النسخة السابقة

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

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

• 3.8.6 المظاهر: متطلبات جديدة للوحات درجات الألوان الديناميكية

  عرض النسخة السابقة

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

  • [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

    يُستخدم "لون المصدر" لإنشاء لوحات درجات ألوان ديناميكية عند إرسالها باستخدام android.theme.customization.system_palette (كما هو موثَّق في Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES).

  • [C-1-6] يجب أن تكون قيمة كثافة اللون CAM16 5 أو أكبر.

    • يجب أن يتم اشتقاقها من الخلفية عبر com.android.systemui.monet.ColorScheme#getSeedColors، والتي توفّر عدة ألوان مصدر صالحة لاختيار لون منها.

    • يجب استخدام القيمة 0xFF1B6EF3، إذا لم يستوفِ أي من الألوان المقدّمة متطلبات لون المصدر المذكورة أعلاه.

  إنهاء المتطلبات الجديدة

• 3.8.17 الحافظة: تمت إضافة قسم للمتطلبات الجديدة للمحتوى المتوفّر في الحافظة.

  عرض النسخة السابقة

  3.8.17 الحافظة

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

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

  إذا كانت عمليات تنفيذ الجهاز تؤدي إلى إنشاء معاينة مرئية للمستخدم عند نسخ المحتوى إلى الحافظة لأي عنصر ClipData حيث يحتوي ClipData.getDescription().getExtras() على android.content.extra.IS_SENSITIVE، سيتم اتخاذ الإجراءات التالية:

  • [C-1-1] يجب إخفاء المعاينة المرئية للمستخدم

  يفي تنفيذ مرجع AOSP هذه بمتطلبات الحافظة.

  إنهاء المتطلبات الجديدة

• 3.9.1.1 إدارة حسابات مالكي الجهاز: تعديلات على متطلبات توفير المتطلبات اللازمة لمالك الجهاز.

  عرض النسخة السابقة

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

  • [C-1-1] يجب إتاحة تسجيل برنامج Device Policy (DPC) باعتباره تطبيق مالك الجهاز كما هو موضح أدناه:
    • في حال عدم ضبط بيانات المستخدمين أو في عملية تنفيذ الجهاز، يتم ما يلي:
      • [C-1-5] يجب تسجيل تطبيق وحدة التحكّم بسياسة الجهاز (DPC) باعتباره تطبيق "مالك الجهاز" أو تفعيل تطبيق DPC لاختيار ما إذا كنت مالك الجهاز أو مالك ملف شخصي في حال أعلن الجهاز عن توفّر "الاتصالات القريبة المدى" (NFC) من خلال علامة الميزة android.hardware.nfc وتلقّى رسالة NFC تحتوي على سجلّ من نوع MIME MIME_TYPE_PROVISIONING_NFC.
      • [C-1-8] يجب إرسال هدف ACTION_GET_PROVISIONING_mode بعد تفعيل توفير المتطلبات اللازمة لمالك الجهاز حتى يتمكن تطبيق وحدة التحكّم بسياسة الجهاز من اختيار ما إذا كان يريد أن يصبح مالك الجهاز أو مالك ملف شخصي، بناءً على قيم android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES، ما لم يتم تحديده من السياق بأنّه يتوفّر خيار واحد صالح فقط. (على سبيل المثال، لتوفير المتطلبات اللازمة استنادًا إلى تقنية NFC التي لا تتوفّر فيها ميزة إدارة حسابات مالك الملف الشخصي).
      • [C-1-9] يجب أن يتم إرسال هدف ACTION_ADMIN_POLICY_COMPLIANCE إلى تطبيق "مالك الجهاز" في حال تم إنشاء "مالك الجهاز" أثناء توفير المتطلبات اللازمة بغض النظر عن طريقة توفير المتطلبات اللازمة. يجب ألا يكون المستخدم قادرًا على المتابعة في "معالج الإعداد" حتى ينتهي تطبيق "مالك الجهاز".
    • عندما تتضمّن عملية تنفيذ الجهاز بيانات مستخدمين أو مستخدمِين، يتم إجراء ما يلي:
      • [C-1-7] يجب ألا يتم بعد الآن تسجيل أي تطبيق لوحدة التحكّم بسياسة الجهاز (DPC) باعتباره تطبيق مالك الجهاز.
  • يجب أن يعرض [C-1-2] إشعار إفصاح مناسبًا (كما هو مُشار إليه في AOSP) وأن يحصل على موافقة إيجابية من المستخدم النهائي قبل ضبط التطبيق كمالك الجهاز، ما لم يتم إعداد الجهاز آليًا للوضع التجريبي للبيع بالتجزئة قبل تفاعل المستخدم على الشاشة. يتطلب ذلك اتخاذ بعض الإجراءات التأكيدية قبل عملية توفير المتطلبات اللازمة للجهاز أو أثناءها. يمكن أن تكون الموافقة من خلال إجراء من جانب المستخدم أو باستخدام بعض الوسائل الآلية، ولكن يجب عرض إشعار الإفصاح المناسب (على النحو المُشار إليه في "مشروع الخدمات الجوّالة للمؤسسات") قبل بدء توفير المتطلبات اللازمة لمالك الجهاز. بالإضافة إلى ذلك، إنّ آلية موافقة مالك الجهاز الآلي المستخدمة (من قِبل المؤسسات) في توفير المتطلبات اللازمة لمالك الجهاز يجب ألا تتداخل مع تجربة الاستخدام خارج الصندوق للاستخدام خارج المؤسسات.
  • [C-1-3] يجب ألا تشفير الموافقة أو منع استخدام تطبيقات مالك الجهاز الأخرى.

  إذا كانت عمليات تنفيذ الأجهزة تشير إلى android.software.device_admin، ولكنها تتضمّن أيضًا حلاً لإدارة الجهاز مالك الجهاز" وتوفّر آلية لترويج تطبيق تم إعداده في الحل الخاص به باعتباره "مالك الجهاز مكافئًا" لـ "مالك الجهاز" العادي كما تتعرّف عليه واجهات برمجة التطبيقات DevicePolicyManager العادية في Android، فإنها:

  • [C-2-1] يجب أن تتوفّر عملية للتحقّق من أنّ التطبيق المحدّد الذي يتم الترويج له ينتمي إلى حل مشروع لإدارة أجهزة المؤسسة وتم إعداده في حل خاص بالشركة للحصول على حقوق تعادل "مالك الجهاز".
  • يجب أن يعرض [C-2-2] بيان الإفصاح عن موافقة مالك الجهاز (AOSP) نفسه كما في المسار الذي بدأه android.app.action.PROVISION_MANAGED_DEVICE قبل تسجيل تطبيق وحدة التحكّم بسياسة الجهاز (DPC) باعتباره "مالك الجهاز".
  • [C-2-3] يجب ألا يتم ترميز الموافقة أو منع استخدام التطبيقات الأخرى التابعة لمالكي الجهاز.
  • قد يتم تثبيت بيانات المستخدمين على الجهاز قبل تسجيل تطبيق وحدة التحكّم بسياسة الجهاز (DPC) كـ "مالك الجهاز".

• 3.9.4 متطلبات دور إدارة الأجهزة: تمت إضافة قسم لمتطلبات دور إدارة الأجهزة.

  عرض النسخة السابقة

  3.9.4 متطلبات دور "إدارة سياسات الأجهزة"

  في حال حدوث تقرير android.software.device_admin أو android.software.managed_users لعمليات تنفيذ الجهاز، سيتم ما يلي:

  • [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.18 جهات الاتصال: إضافة معلومات لجهات الاتصال الجديدة.

  عرض النسخة السابقة

  حساب تلقائي لجهات الاتصال الجديدة: يوفّر "مقدِّم خدمات جهات الاتصال" واجهات برمجة التطبيقات لإدارة إعداد الحساب التلقائي عند إنشاء جهة اتصال جديدة.

  في حال تحميل تطبيق جهات الاتصال مسبقًا على الجهاز، سيعمل تطبيق جهات الاتصال المحمَّل مسبقًا على:

  • [C-2-1] يجب أن يتعامل مع intent ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT لإطلاق واجهة مستخدم لاختيار الحساب وحفظ الإعداد في "مقدِّم جهات الاتصال" عند اختيار حساب.

  • يجب أن يلتزم [C-2-2] بإعدادات الحساب التلقائية عند التعامل مع Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT في ContactsContracts.Contacts.CONTENT_TYPE وContactsContract.RawContacts.CONTENT_TYPE من خلال اختيار الحساب في البداية.

  إنهاء المتطلبات الجديدة

‫4. توافق حزمة التطبيق

• 4. توافق حزم التطبيقات: تحديثات على إصدار مخطط توقيع APK.

  عرض النسخة السابقة

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

  • يجب أن يتيح [C-0-2] إثبات ملكية ملفات " .apk" باستخدام الإصدار 3.1 من مخطّط توقيع حِزم APK والإصدار 3 من مخطّط توقيع حِزم APK والإصدار 2 من مخطّط توقيع حِزم APK وتوقيع JAR.

  • يجب أن يتيح [C-0-9] إثبات ملكية ملفات .apk باستخدام الإصدار 4 من مخطّط توقيع حِزم APK و الإصدار 4.1 من مخطّط توقيع حِزم APK .

‫5. التوافق مع الوسائط المتعددة

• 5.1.2 فك ترميز الصوت: تمت إضافة متطلبات جديدة لبرامج فك الترميز القادرة على إصدار صوت عبر قنوات متعدّدة.

  عرض النسخة السابقة

  إذا كانت عمليات تنفيذ الأجهزة تتيح فك ترميز المخازن المؤقتة لإدخالات AAC الخاصة بالبث المتعدد القنوات (أي أكثر من قناتَين) إلى PCM من خلال أداة فك ترميز الصوت التلقائية AAC في واجهة برمجة التطبيقات android.media.MediaCodec API، يجب استخدام العناصر التالية:

  • [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).

  إذا كانت عمليات فك ترميز الصوت على الأجهزة تتوافق مع برامج فك ترميز الصوت غير برنامج فك ترميز الصوت AAC التلقائي ويمكنها بث محتوى صوتي متعدد القنوات (أي أكثر من قناتَين) عند إدخال محتوى مضغوط ومتعدد القنوات:

  • [C-SR] يُنصَح بشدة بأن يكون التطبيق قادرًا على ضبطه باستخدام فك الترميز باستخدام المفتاح KEY_MAX_OUTPUT_CHANNEL_COUNT للتحكّم في ما إذا كان يتم تحويل المحتوى إلى صوت استيريو (عند استخدام القيمة 2) أو عند إخراجه باستخدام العدد الأصلي للقنوات (عند استخدام قيمة تساوي ذلك الرقم أو أكبر منه). على سبيل المثال، ستؤدي القيمة 6 أو أعلى إلى تهيئة برنامج فك الترميز لإخراج 6 قنوات عند إدخال المحتوى بالإصدار 5.1.
  • [C-SR] عند فك الترميز، يُنصَح بشدة باستخدام أداة فك الترميز للإعلان عن قناع القناة المُستخدَم في تنسيق الناتج من خلال مفتاح KEY_CHANNEL_MASK، وذلك باستخدام ثوابت android.media.AudioFormat (مثال: CHANNEL_OUT_5POINT1).

  إنهاء المتطلبات الجديدة

• 5.4.1 المعلومات الأولية حول التقاط الصوت والميكروفون: تعديلات على مصادر الصوت المتوافقة مع مصادر إدخال الصوت

  عرض النسخة السابقة

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

  • يجب أن يسمح [C-1-1] بالتقاط المحتوى الصوتي غير المنسّق الذي يتضمن الخصائص التالية بالنسبة إلى أي بث تم فتحه بنجاح من خلال AudioRecord أو AAudio INPUT. على الأقل، يجب توفُّر الخصائص التالية:

    • التنسيق: PCM خطي، 16 بت
    • معدّلات أخذ العيّنات: 8000، 11025، 16000، 44100، 48,000 هرتز
    • القنوات: أحادي
    • مصادر الصوت: DEFAULT أو MIC أو CAMCORDER أو VOICE_RECOGNITION أو VOICE_COMMUNICATION أو UNPROCESSED أو VOICE_PERFORMANCE. ينطبق ذلك أيضًا على الإعدادات المسبقة للإدخال المكافئة في AAudio، على سبيل المثال، AAUDIO_INPUT_PRESET_CAMCORDER.
    • [C-1-4] يجب أن يلتزم بواجهة برمجة تطبيقات MicrophoneInfo ويملأ المعلومات الصحيحة للميكروفونات المتاحة على الجهاز التي يمكن الوصول إليها من خلال التطبيقات التابعة للجهات الخارجية عبر AudioManager.getMicrophones() واجهة برمجة التطبيقات، لتسجيل الصوت النشط باستخدام MediaRecorder.AudioSources DEFAULT أو MIC أو CAMCORDER أو VOICE_RECOGNITION أو VOICE_COMMUNICATION أو UNPROCESSED أو VOICE_PERFORMANCE. والميكروفونات النشطة حاليًا التي يمكن الوصول إليها من خلال التطبيقات التابعة لجهات خارجية عبر واجهات برمجة التطبيقات AudioRecord.getActiveMicrophones() وMediaRecorder.getActiveMicrophones().

• 5.4.2 الالتقاط للتعرف على الصوت: تم تحديث متطلبات البث الصوتي لميزة التعرف على الصوت ومتطلبات إضافية لمستويات كسب الميكروفون.

  عرض النسخة السابقة

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

  • "يجب" تسجيل البث الصوتي لميزة "التعرّف على الصوت" بتردد مسطّح تقريبًا مقابل خصائص التردّد الصوتي، وتحديدًا، بتردد أقل من 3 ديسيبل، بدءًا من 100 هرتز إلى 4,000 هرتز.
  • "يجب تسجيل" البث الصوتي لميزة "التعرّف على الصوت" مع ضبط حساسية الإدخال بحيث يؤدي مصدر طاقة يبلغ 90 ديسيبل على مستوى 1000 هرتز إلى الحصول على رمز المتوسط العائم 2,500 للعينات ذات 16 بت.

  • يجب أن تظهر خصائص اتساع مسطّح تقريبًا مقابل تردد التردد في نطاق التردد المتوسط: تحديدًا + 3 ديسيبل من 100 هرتز إلى 4000 هرتز لكل ميكروفون وكل ميكروفون يُستخدم لتسجيل مصدر صوت ميزة التعرف على الصوت.
  • يُنصَح بشدة بأن تكون الأجهزة [C-SR] مُوصى بها بشدة بأن تعرض مستويات الشدّة في نطاق التردد المنخفض، خاصةً من 20 ديسيبل بدءًا من 20 ديسيبل بدءًا من 30 هرتز إلى 100 هرتز مقارنةً بنطاق التردّد الصوتي لكل ميكروفون يُستخدَم في تسجيل مصدر صوت التعرّف على الصوت.
  • يُنصَح بشدة بأن تكون الأجهزة الصوتية [C-SR] مُوصى بها بشدة بأن تعرض مستويات الشدّة في نطاق التردد العالي: على وجه التحديد من + 30 ديسيبل بدءًا من 4000 هرتز إلى 22 كيلوهرتز مقارنةً بنطاق التردد المتوسط لكل ميكروفون يُستخدم لتسجيل مصدر الصوت لميزة "التعرّف على الصوت".
  • يجب ضبط حساسية إدخال الصوت مسبقًا على أن يتم استخدام مصدر نغمة جيبية بتردد 1000 هرتز لكل عينة عائمة تبلغ ترددها على مستوى 90 ديسيبل (SPL) عند قياس مستوى ضغط الصوت (SPL) بقياس 90 ديسيبل (أو ما يعادله بالعملة المحلية)، ويتم الحصول على استجابة مثالية بمعدّل RMS 2500 في نطاق يتراوح بين 1770 و3530 عينة عائمة لكل عينة عائمة أو 35 بت على مستوى عينة عائمة.

  إنهاء المتطلبات الجديدة

• 5.4.6 مستويات اكتساب الميكروفون: تم نقل المتطلبات الخاصة بمستويات اكتساب الميكروفون إلى القسم 5.4.2.

  عرض النسخة السابقة

  5.4.6. مستويات اكتساب الميكروفون [تم نقلها إلى 5.4.2]

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

  • يجب أن تتوفّر خصائص اتساع مسطّح تقريبًا مقابل تردد التردد في نطاق متوسط التردد: تحديدًا + 3 ديسيبل تتراوح من 100 هرتز إلى 4000 هرتز لكل ميكروفون يُستخدَم في تسجيل مصدر الصوت لميزة "التعرّف على الصوت".
  • يُنصَح بشدة بأن تكون الأجهزة [C-SR] مُوصى بها بشدة بأن تعرض مستويات الشدّة في نطاق التردد المنخفض، خاصةً من 20 ديسيبل بدءًا من 5 هرتز إلى 100 هرتز مقارنةً بنطاق التردّد المتوسط لكل ميكروفون يُستخدَم في تسجيل مصدر الصوت لميزة "التعرّف على الصوت".
  • يُنصَح بشدة بأن تكون الأجهزة [C-SR] موصى بها بشدة بأن تعرض مستويات السعة في نطاق التردد العالي: على وجه التحديد من + 30 ديسيبل من 4000 هرتز إلى 22 كيلوهرتز مقارنةً بنطاق التردد المتوسط لكل ميكروفون يُستخدم لتسجيل مصدر الصوت لميزة "التعرّف على الصوت".
  • يجب ضبط حساسية إدخال الصوت بحيث ينتج عن مصدر نغمة جيبية بتردد 1000 هرتز يتم تشغيله عند مستوى ضغط الصوت 90 ديسيبل (SPL) استجابة بنسبة RMS تبلغ 2500 للعينات ذات 16 بت (أو -22.35 ديسيبل لعينات ميكروفون عائمة/مزدوجة لكل مصدر صوتي يتم استخدامه لكل نقطة عائمة/مزدوجة)

• 5.5.4 إزالة تحميل الصوت: تعديلات على متطلبات التشغيل عند إزالة الصوت.

  عرض النسخة السابقة

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

  • [C-SR] يُنصح بشدة بقطع المحتوى الصوتي غير القابل للفتح بين مقطعَين بالتنسيق نفسه عند تحديدهما من خلال AudioTrack gapless API وحاوية الوسائط في MediaPlayer.

• 5.6 وقت استجابة الصوت: تعديلات على متطلبات وقت استجابة الصوت

  عرض النسخة السابقة

  استخدِم التعريفات التالية لأغراض هذا القسم:

  • عدم استقرار الإخراج البارد. التباين بين القياسات المنفصلة لقيم وقت استجابة الإخراج البارد.
  • عدم استقرار الإدخال البارد. التباين بين القياسات المنفصلة لقيم وقت استجابة الإدخال البارد.

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

  • [C-1-2] وقت استجابة ناتج بارد يبلغ 500 مللي ثانية أو أقل.
  • [C-1-3] إنّ فتح مصدر بيانات الناتج باستخدام AAudioStreamBuilder_openStream() يجب أن يستغرق أقل من 1,000 ملّي ثانية.

  إذا أشارت عمليات تنفيذ الأجهزة إلى أنّ android.hardware.audio.output موصى بها بشدة لاستيفاء المتطلبات التالية أو تجاوزها:

  • [C-SR] يبلغ وقت استجابة الإخراج البارد 100 مللي ثانية أو أقل عبر مسار بيانات المتحدث. ننصح بشدة باتّباع هذه المتطلبات الآن على الأجهزة الحالية والجديدة التي تعمل بنظام التشغيل Android. في أي إصدار مستقبلي من النظام الأساسي، سنحتاج إلى أن يكون وقت استجابة إخراج الصوت البارد 200 ملي ثانية أو أقل كما يجب.
  • [C-SR] الحدّ من عدم استقرار الإخراج البارد.

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

  • [C-3-2] وقت استجابة الإدخال البارد يبلغ 500 مللي ثانية أو أقل.
  • [C-3-3] إنّ فتح مصدر بيانات إدخال باستخدام AAudioStreamBuilder_openStream() يجب أن يستغرق أقل من 1,000 ملّي ثانية.

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

  • [C-SR] يبلغ وقت استجابة الإدخال البارد 100 مللي ثانية أو أقل عبر مسار بيانات الميكروفون. ننصح بشدة باتّباع هذه المتطلبات الآن على الأجهزة الحالية والجديدة التي تستخدم هذا الإصدار من Android. وفي إصدار النظام الأساسي المستقبلي، سنطلب أن يكون وقت استجابة الإدخال البارد 200 ملي ثانية أو أقل كما يجب.

  • [C-SR] وقت استجابة إدخال مستمر يبلغ 30 مللي ثانية أو أقل.
  • [C-SR] تقليل عدم استقرار الإدخال البارد.

• 5.10 مقطع صوتي احترافي: تعديلات على متطلبات وقت استجابة الصوت لتقديم الدعم الصوتي الاحترافي.

  عرض النسخة السابقة

  في حال إبلاغ عمليات تنفيذ الأجهزة عن توافق "android.hardware.audio.pro" من خلال الفئة android.content.pm.PackageManager، سيتم إجراء ما يلي:

  • يجب أن يتوفّر في [C-1-2] وقت استجابة الصوت ذهابًا وإيابًا بشكل متواصل، على النحو المحدّد في القسم وقت استجابة الصوت 5.6 بمقدار 25 مللي ثانية أو أقل ويجب أن يبلغ 10 مللي ثانية أو أقل عبر مسار واحد متوافق على الأقل.
  • يجب أن يلبّي [C-1-5] وقت الاستجابة ومتطلبات صوت USB باستخدام واجهة برمجة التطبيقات AAudio Audio API وAAUDIO_PERFORMANCE_MODE_LOW_LATENCY.
  • [C-1-8] يجب أن يبلغ متوسط وقت استجابة "النقر للنغمات" 80 مللي ثانية أو أقل عبر 5 قياسات على الأقل عبر مسار بيانات المتحدث إلى الميكروفون.
  • [C-SR] يُنصح بشدة بتوفير مستوى ثابت من أداء وحدة المعالجة المركزية عندما يكون الصوت نشطًا ويختلف حِمل وحدة المعالجة المركزية (CPU). ويجب اختبار هذه البيانات باستخدام تطبيق Android SynthMark. يستخدم SynthMark أداة توليف برامج يتم تشغيلها على إطار عمل محاكاة الصوت الذي يقيس أداء النظام. اطّلِع على مستندات SynthMark للحصول على شرح لمقاييس الأداء. يجب تشغيل تطبيق SynthMark باستخدام خيار "الاختبار الآلي" وتحقيق النتائج التالية: * voicemark.90 >= 32 voice * playlistmark.fixed.little <= 15 ملّي ثانية * Timemark.dynamic.little <= 50 ملّي ثانية
  • يجب أن يكون وقت الاستجابة من الإدخال باللمس إلى إخراج الصوت أقل من أو يساوي 40 ملي ثانية.

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

  • يجب أن يكون متوسط وقت الاستجابة المستمر للصوت ذهابًا وإيابًا في [C-2-1]، كما هو محدّد في القسم 5.6 وقت الاستجابة الصوتي، 20 ملي ثانية أو أقل وأكثر من 5 قياسات مع متوسط انحراف مطلق أقل من 5 ملي ثانية عبر مسار مقبس الصوت باستخدام مفتاح إلكتروني بديل.

• 5.12 HDR Video: تمت إضافة قسم جديد لمتطلبات فيديو HDR.

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

• 6.1 أدوات المطوّرين: تعديلات على متطلبات الاتصال ومتطلبات نواة وحدة معالجة الرسومات

  عرض النسخة السابقة

  إذا كانت عمليات تنفيذ الأجهزة تتيح اتصالات adb بجهاز مضيف عبر شبكة Wi-Fi أو إيثرنت، سيتم إجراء ما يلي:

  • [C-4-1] يجب أن تتضمن طريقة AdbManager#isAdbWifiSupported() إرجاع true.

  إذا كانت عمليات تنفيذ الأجهزة تتيح اتصالات أداة Adb بجهاز مضيف عبر شبكة Wi-Fi أو إيثرنت، وتتضمّن كاميرا واحدة على الأقل:

  • [C-5-1] يجب أن تعرض طريقة AdbManager#isAdbWifiQrSupported() true.

  • معلومات عمل وحدة معالجة الرسومات

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

    • [C-6-1] يجب تنفيذ أمر واجهة الأوامر dumpsys gpu --gpuwork لعرض بيانات عمل وحدة معالجة الرسومات المجمّعة التي تعرضها نقطة تتبُّع النواة power/gpu_work_period، أو عرض أي بيانات إذا كانت نقطة التتبّع غير متاحة. إنّ عملية تنفيذ AOSP هي frameworks/native/services/gpuservice/gpuwork/

  إنهاء المتطلبات الجديدة

‫7. توافُق الأجهزة

• 7.1.4.1 OpenGL ES: تعديل للإضافات المقترَحة.

  عرض النسخة السابقة

  إذا كانت عمليات تنفيذ الأجهزة تتوافق مع أي من إصدارات OpenGL ES، سيتم إجراء ما يلي:

  • يجب أن تكون متوافقة مع الإضافتَين EGL_IMG_context_priority وEGL_EXT_protected_content.

  إنهاء المتطلبات الجديدة

• 7.1.4.2 Vulkan: تحديثات للإصدار المتوافق مع Vulkan

  عرض النسخة السابقة

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

  • [SR] يُنصَح بشدة بتضمين الدعم في Vulkan 1.3. Vulkan 1.1
  • يجب ألا يكون متوافقًا مع إصدار Vulkan Variant (أي يجب أن يكون جزء الصيغة من الإصدار Vulkan الأساسي صفرًا).

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

  • [SR] يُنصَح بشدة بتضمين الدعم في Vulkan 1.3. Vulkan 1.1

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

  • يجب أن يتوافق مع VkPhysicalDeviceProtectedMemoryFeatures وVK_EXT_global_priority.
  • [C-1-12] يجب ألا يتعداد الإضافة VK_KHR_performance_query.
  • يُنصَح بشدة بأن يستوفي [C-SR] المتطلبات المحدّدة في ملف Android Baseline 2021 الشخصي.

• 7.2.3 مفاتيح التنقل:

  عرض النسخة السابقة

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

  • [C-SR] يُنصَح بشدة بتقديم جميع وظائف التنقّل يمكن إلغاؤها. تشير كلمة "ملغاة" إلى قدرة المستخدم على منع تنفيذ وظيفة التنقّل (مثل العودة إلى الصفحة الرئيسية أو الرجوع إلى الصفحة السابقة أو ما إلى ذلك) في حال عدم تجاوز الحدّ الأدنى المطلوب لوظيفة التمرير السريع.

  إنهاء المتطلبات الجديدة

  إذا تم توفير وظيفة الرجوع إلى الصفحة السابقة وألغى المستخدم إيماءة الرجوع، عليك إجراء ما يلي:

  • [C-8-1] يجب الاتصال بـ OnBackInvokedCallback.onBackCancelled().
  • [C-8-2] OnBackInvokedCallback.onBackInvoked() يجب ألّا يتم الاتصال به.
  • [C-8-3] يجب عدم إرسال الحدث KEYCODE_BACK.

  إذا تم توفير وظيفة "الانتقال إلى الخلف" ولكن لم يتم تسجيل OnBackInvokedCallback في تطبيق المقدّمة، يجب عندها:

  • "يجب أن يوفّر النظام" صورة متحركة للتطبيق الذي تعمل في المقدّمة تشير إلى عودة المستخدم، كما هو مذكور في AOSP.

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

  • يجب أن يوفّر [C-9-1] الدعم للرموز المناسبة للأطفال أو التنقّل المستند إلى الأزرار على النحو الوارد في رمز AOSP.

  إنهاء المتطلبات الجديدة

• 7.3.1 مقياس التسارع: تعديلات على متطلبات أدوات الاستشعار لمقاييس التسارع.

  عرض النسخة السابقة

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

  • [C-1-2] يجب تنفيذ أداة استشعار TYPE_ACCELEROMETER والإبلاغ عنها.
  • [SR] ننصح بشدة بتشغيل جهاز الاستشعار المركّب TYPE_SIGNIFICANT_MOTION.
  • [SR] يُنصَح بشدة بتنفيذ أداة الاستشعار TYPE_ACCELEROMETER_UNCALIBRATED والإبلاغ عنها. ونحن ننصح بشدة أجهزة Android باستيفاء هذه المتطلبات حتى يتسنى لها الترقية إلى إصدار النظام الأساسي المستقبلي الذي قد يصبح مطلوبًا فيه.
  • يجب تنفيذ المستشعرات المُركّبة TYPE_SIGNIFICANT_MOTION أو TYPE_TILT_DETECTOR أو TYPE_STEP_DETECTOR أو TYPE_STEP_COUNTER كما هو موضّح في مستند حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

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

  • [C-2-1] يجب استخدام أداة استشعار TYPE_ACCELEROMETER والإبلاغ عنها.
  • [C-SR] يُنصَح بشدة باستخدام أداة الاستشعار المركّبة "TYPE_SIGNIFICANT_MOTION".
  • [C-SR] يُنصَح بشدة باستخدام أداة استشعار 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] ننصح بـ strongLY_RECOMMENDED لاستخدام أداة استشعار TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED والإبلاغ عنها.

  إنهاء المتطلبات الجديدة

  في حال تضمّنت عمليات تنفيذ الأجهزة مقياس تسارع ثلاثي المحاور وتم تنفيذ أي من أدوات الاستشعار المركّبة TYPE_SIGNIFICANT_MOTION أو TYPE_TILT_DETECTOR أو TYPE_STEP_DETECTOR أو TYPE_STEP_COUNTER:

  • [C-4-1] يجب أن يكون مجموع استهلاك الطاقة دائمًا أقل من 4 ميغاواط.

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

  • [C-5-1] يجب أن يستخدم أدوات الاستشعار المركّبة TYPE_GRAVITY وTYPE_LINEAR_ACCELERATION.

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

  • [C-6-1] يجب تشغيل جهاز استشعار مركّب TYPE_ROTATION_VECTOR.

• 7.3.4 الجيروسكوب: تعديلات على متطلبات أدوات الاستشعار في الجيروسكوب.

  عرض النسخة السابقة

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

  • يجب أن يتمكّن [C-1-1] من الإبلاغ عن الأحداث التي تصل ترددها إلى 50 هرتز على الأقل.
  • [C-1-4] يجب أن تصل درجة الدقة إلى 12 بت أو أكثر.
  • [C-1-5] يجب تعويض درجة الحرارة فيه.
  • يجب معايرة [C-1-6] وتعويضه أثناء الاستخدام، مع الحفاظ على معلَمات التعويض بين عمليات إعادة تشغيل الجهاز.
  • يجب أن يحتوي [C-1-7] على تباين لا يزيد عن 1e-7 rad^2 / s^2 per Hz (التباين لكل هرتز، أو rad^2 / s). يُسمح بأن يختلف التباين مع معدل أخذ العينات، ولكن يجب أن يكون مقيدًا بهذه القيمة. بعبارة أخرى، إذا قمت بقياس تباين الجيروسكوب بمعدل أخذ عينات 1 هرتز، فيجب ألا يزيد عن 1e-7 rad^2/s^2.
  • [C-SR] يُنصح بشدة بأن تكون درجة خطأ المعايرة أقل من 0.01 راد/ثانية عندما يكون الجهاز ثابتًا في درجة حرارة الغرفة.
  • [C-SR] يُنصح بشدة بأن تكون درجة الدقة 16 بت أو أكثر.
  • "يجب" الإبلاغ عن الأحداث التي تصل ترددها إلى 200 هرتز على الأقل.

  إنهاء المتطلبات الجديدة

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

  • [C-2-1] يجب تشغيل جهاز استشعار TYPE_GYROSCOPE.

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

  • [C-3-1] يجب استخدام أداة استشعار TYPE_GYROSCOPE_LIMITED_AXES والإبلاغ عنها.
  • [C-SR] ننصح بـ strongLY_RECOMMENDED لاستخدام أداة استشعار TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED والإبلاغ عنها.

  إنهاء المتطلبات الجديدة

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

  • [C-4-1] يجب تشغيل جهاز استشعار مركّب TYPE_ROTATION_VECTOR.

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

  • [C-5-1] يجب أن يستخدم أدوات الاستشعار المركّبة TYPE_GRAVITY وTYPE_LINEAR_ACCELERATION.

• 7.3.10 أجهزة الاستشعار الحيوية: تعديلات على متطلبات أدوات الاستشعار الخاصة بأجهزة الاستشعار الحيوية.

  عرض النسخة السابقة

  يمكن تصنيف أجهزة الاستشعار الحيوية على أنّها الفئة 3 (المعروفة سابقًا باسم قوية) أو الفئة 2 (المعروفة سابقًا باسم ضعيفة) أو الفئة 1 (المعروفة سابقًا باسم الملاءمة) استنادًا إلى معدّلات قبول الانتحال والاحتيال، وعلى أمان مسار المقاييس الحيوية. ويحدِّد هذا التصنيف الإمكانات التي يجب أن تستخدمها أداة الاستشعار الحيوية مع المنصة ومع تطبيقات الجهات الخارجية. يجب أن تستوفي أجهزة الاستشعار متطلبات إضافية كما هو موضّح أدناه إذا كانت تريد تصنيفها ضمن الفئة 1 أو الفئة 2 أو الفئة 3. تُصنّف أجهزة الاستشعار على أنّها من الفئة 1 تلقائيًا، وتحتاج إلى استيفاء متطلبات إضافية كما هو موضّح أدناه إذا أردت تصنيفها على أنّها من الفئة 2 أو الفئة 3. تحصل المقاييس الحيوية من الفئة 2 والفئة 3 على إمكانات إضافية كما هو موضَّح أدناه.

  إذا كانت عمليات تنفيذ الأجهزة تريد التعامل مع أحد أجهزة استشعار المقاييس الحيوية على أنها من الفئة 1 (المعروفة سابقًا باسم مستوى الراحة)، يتم اتخاذ الإجراءات التالية:

  • [C-1-11] يجب أن يكون معدل قبول المحتال والانتحال لا يزيد عن 30%، في حال (1) مقياس قبول الانتحال والاحتيال لأنواع أدوات الهجوم (PAI) من المستوى أ التي لا يزيد عن 30%، و (2) معدل قبول المحتال ومستوى قبول المحتال من المستوى B PAI، حيث لا يزيد هذا المعدل عن Android 40.

  إنهاء المتطلبات الجديدة

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

  • [C-2-2] يجب أن يكون معدل قبول النماذج المحتالة والاحتيالية لا يزيد عن 20%، مع (1) (1) معدّل قبول للمحتال والخداع لمحتال من الأنواع التي لا يزيد عددها عن %20 من أدوات هجوم على العرض التقديمي من المستوى أ (PAI)، و(2) معدّل قبول محتال ومحتال من الأنواع من المستوى B PAI، على ألّا يزيد هذا المعدل عن 3، كما تم قياسه.

  إذا كانت عمليات تنفيذ الأجهزة تريد التعامل مع أداة استشعار المقاييس الحيوية على أنها من الفئة 3 (المعروفة سابقًا باسم قوية)، فإنها:

  • [C-3-3] يجب أن يكون معدل قبول المحتال والسلوك المحتال لا يزيد عن 7%، في حال (1) معدّل قبول محاكاة واحتيال لأنواع أدوات هجوم العرض التقديمي من المستوى أ (PAI) لا يزيد عن 7%، و(2) معدّل قبول محاكاة وخادع من المستوى B PAI، لا يزيد عن 20% في مقياس Android. .

• 7.3.13 IEEE 802.1.15.4 (UWB): تمت إضافة قسم متطلبات جديد للنطاق الفائق العرض (UWB).

  عرض النسخة السابقة

  7.3.13. IEEE 802.1.15.4 (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-1-6] يُنصح بشدة باجتياز اختبارات المطابقة والشهادات ذات الصلة التي تحدّدها المؤسسات العادية، بما في ذلك FIRA وCCC وCSA.

  إنهاء المتطلبات الجديدة

• 7.4.1 الاتصال الهاتفي: تعديلات على متطلبات الاتصال الهاتفي لإعدادات الاتصال الهاتفي لبروتوكول GSM وCDMA واستخدام شبكة الجوّال.

  عرض النسخة السابقة

  إذا كانت طُرق تنفيذ الأجهزة تتوافق مع واجهات برمجة التطبيقات (eUICC) أو شرائح eSIM أو شرائح SIM المضمّنة، وتتضمّن آلية خاصة لإتاحة وظائف eSIM للمطورين التابعين لجهات خارجية، ينطبق عليهم ما يلي:

  • [C-3-1] يجب أن يعلن عن علامة android.hardware.telephony.euicc الخاصة بميزة. تقديم تنفيذ كامل EuiccManager API.

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

  • [C-6-1] يجب أن يؤدي استخدام SmsManager#sendTextMessage وSmsManager#sendMultipartTextMessage إلى إجراء استدعاءات مقابلة إلى CarrierMessagingService لتوفير وظيفة المراسلة النصية. يجب أن يؤدي استخدام SmsManager#sendMultimediaMessage وSmsManager#downloadMultimediaMessage إلى إجراء استدعاءات مقابلة إلى CarrierMessagingService لتوفير وظيفة مراسلة الوسائط المتعددة.
  • [C-6-2] يجب أن يستخدم التطبيق المعيَّن من خلال android.provider.Telephony.Sms#getDefaultSmsPackage واجهات برمجة التطبيقات SmsManager عند إرسال الرسائل القصيرة ورسائل الوسائط المتعددة واستلامها. يفي تنفيذ مرجع AOSP في الحزم/التطبيقات/المراسلة بهذا الشرط.
  • [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 أو التحكّم فيها.

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

  • يجب أن يختار [C-6-7] اشتراكًا نشِطًا توضيحيًا لرقم تعريف مستخدم فردي (UUID) معيّن لمجموعة لعرضه للمستخدم في أي وظائف توفِّر معلومات عن حالة شريحة SIM. تشمل الأمثلة على هذه الخصائص رمز إشارة الشبكة الخلوية في شريط الحالة أو مربع الإعدادات السريعة.
  • [C-SR] يُنصَح بشدة بأن يكون الاشتراك التمثيلي اشتراكًا في خدمة البيانات النشطة ما لم يكن الجهاز في مكالمة صوتية، حيث يُنصح بشدة بأن يكون الاشتراك التمثيلي هو اشتراك Google Voice النشط.

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

  • يجب أن يكون [C-6-8] قادرًا على فتح واستخدام الحد الأقصى في الوقت نفسه من القنوات المنطقية (إجمالي 20 قناة) لكل UICC وفقًا للمعيار ETSI TS 102 221.
  • [C-6-10] يجب ألا يطبّق أي من السلوكيات التالية على تطبيقات مشغّل شبكة الجوّال النشطة (وفقًا لما حدّده "TelephonyManager#getCarrierServicePackageName") تلقائيًا أو بدون تأكيد صريح من المستخدم:
    • إبطال الوصول إلى الشبكة أو تقييده
    • إبطال الأذونات
    • فرض قيود على عمليات تنفيذ التطبيقات التي تعمل في الخلفية أو التي تعمل في المقدّمة بشكل يتجاوز ميزات إدارة الطاقة الحالية المضمّنة في AOSP
    • إيقاف التطبيق أو إلغاء تثبيته

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

  • [C-7-1] يجب أن يوقِف تلقائيًا جميع الاشتراكات الفرصة النشطة المتبقية في المجموعة نفسها

  إذا كانت عمليات تنفيذ الأجهزة تتضمن اتصالات هاتفية عبر بروتوكول GSM لكن لا تشتمل على اتصال هاتفي عبر CDMA، فإنها:

  • [C-8-1] يجب ألا يفصح عن PackageManager#FEATURE_TELEPHONY_CDMA.
  • يجب إرسال IllegalArgumentException عند محاولة ضبط أي نوع من أنواع شبكات 3GPP2 على أقنعة بتات مفضّلة أو مسموح بها من نوع الشبكة [C-8-2].
  • [C-8-3] يجب عرض سلسلة فارغة من TelephonyManager#getMeid.

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

  • [C-11-1] يجب أن تشير إلى علامة ميزة android.hardware.telephony.euicc.mep.

  إنهاء المتطلبات الجديدة

• 7.4.1.1 التوافق مع حظر الأرقام: تعديلات على متطلبات حظر الأرقام.

  عرض النسخة السابقة

  إذا أبلغت عمليات تنفيذ الأجهزة عن android.hardware.telephony feature، سيؤدي ذلك إلى:

  • [C-1-4] يجب ألّا يتواصل مع موفِّر خدمة سجلّ المكالمات في النظام الأساسي لإجراء مكالمة محظورة.

  • [C-1-4] يجب الكتابة إلى موفِّر خدمة سجلّ المكالمات في النظام الأساسي لإجراء مكالمة محظورة ويجب فلترة المكالمات التي تتضمّن BLOCKED_TYPE من عرض سجلّ المكالمات التلقائي في تطبيق برنامج الاتصال المثبَّت مسبقًا.
  • يجب أن تتوفر للمستخدم إمكانية عرض المكالمات المحظورة في تطبيق برنامج الاتصال المثبّت مسبقًا.

  إنهاء المتطلبات الجديدة

• 7.4.1.3 Cellular NAT-T Keepalive Offload: قسم جديد لعمليات نقل البيانات الخلوية NAT-T Keepalive.

  عرض النسخة السابقة

  7.4.1.3. نقل البيانات من شبكة NAT-T Keepalive

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

  • يجب أن تشتمل هذه السياسة على إمكانية نقل بيانات رسالة التحقّق من الاتصال على شبكة الجوّال.

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

  • [C-1-1] يجب أن يتوافق مع واجهة برمجة تطبيقات SocketKeepAlive.
  • [C-1-2] يجب أن يتوافق مع خانة واحدة على الأقل رسالة التحقّق من الاتصال المتزامنة عبر شبكة الجوّال.
  • [C-1-3] يجب أن يتوافق مع العديد من خانات الاتصال بشبكة الجوّال المتزامنة التي تتوافق مع طبقة تجريد الأجهزة (HAL) اللاسلكي الخلوية.
  • [C-SR] يُنصَح بشدّة بأن يتيح استخدام ثلاث خانات على الأقل للحفاظ على الاتصال الخلوي في كل مثيل لاسلكي.

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

  • [C-2-1] يجب عرض ERROR_UNSUPPORTED.

  إنهاء المتطلبات الجديدة

• 7.4.2.5 الموقع الجغرافي لشبكة Wi-Fi (وقت الذهاب والعودة إلى شبكة Wi-Fi): تعديلات على دقة الموقع الجغرافي لشبكة Wi-Fi

  عرض النسخة السابقة

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

  • [C-1-4] يجب أن تكون دقيقة في نطاق مترين وبنطاق نقل بيانات 80 ميغاهرتز عند النسبة المئوية 68 (وفقًا لحساب دالة التوزيع التراكمي).
  • [C-SR] يُنصَح بشدة بالإبلاغ عن ذلك بدقة في نطاق 1.5 متر في نطاق ترددي يبلغ 80 ميغاهرتز عند الشريحة المئوية 68 (وفقًا لحسابات دالة التوزيع التراكمي).

  إنهاء المتطلبات الجديدة

• 7.4.2.6 إيقاف تحميل بيانات تطبيق Keepalive لشبكة Wi-Fi: تم تعديل البيانات لإضافة متطلبات نقل بيانات رسالة التحقُّق من الاتصال بشبكة الجوّال.

  عرض النسخة السابقة

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

  • يجب أن يشمل ذلك الدعم لنقل بيانات رسالة التحقُّق من الاتصال بشبكة Wi-Fi.

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

  • [C-1-1] يجب أن يتوافق مع واجهة برمجة تطبيقات SocketKeepAlive.
  • [C-1-2] يجب أن يتوافق مع ما لا يقل عن ثلاث خانات متزامنة للبقاء على الاتصال عبر Wi-Fi
    ومنفذ واحد على الأقل للتحقق من الاتصال عبر شبكة الجوّال.

  إذا لم تكن عمليات تنفيذ الجهاز تتضمّن توافقًا مع نقل بيانات رسالة التحقُّق من الاتصال بشبكة Wi-Fi، سيؤدي ذلك إلى:

  • [C-2-1] يجب أن يعرض ERROR_UNSUPPORTED.

• 7.4.2.9 موثوقية الاستخدام الأول (TOFU): تمت إضافة قسم "الثقة في متطلبات الاستخدام الأول".

  عرض النسخة السابقة

  7.4.2.9 الثقة عند الاستخدام الأول (TOFU)

  إذا كانت عمليات تنفيذ الأجهزة تتوافق مع معيار الثقة عند الاستخدام الأول (TOFU) وتسمح للمستخدم بتحديد إعدادات WPA/WPA2/WPA3-Enterprise، ينطبق عليها ما يلي:

  • [C-4-1] يجب أن يوفر للمستخدم خيارًا لتحديد استخدام TOFU.

  إنهاء المتطلبات الجديدة

• 7.4.3 البلوتوث: يمكنك تعديل متطلبات البلوتوث.

  عرض النسخة السابقة

  إذا كانت عمليات تنفيذ الأجهزة تتوافق مع الملف الشخصي لـ Bluetooth Audio:

  • يجب أن تتوافق مع برامج ترميز الصوت المتقدّمة وبرامج ترميز الصوت عبر البلوتوث (مثل LDAC) مع A2DP.

  إذا كانت عمليات تنفيذ الأجهزة تعرض true لواجهة برمجة تطبيقات BluetoothAdapter.isLeAudioSupported()، سيتم عندها:

  • [C-7-1] يجب أن يتوافق مع برنامج البث الأحادي.
  • [C-7-2] يجب أن يدعم 2 مليون PHY.
  • [C-7-3] يجب أن يتوافق مع LE Extended Advertising.
  • [C-7-4] يجب أن يدعم اتصالَي CIS على الأقل في CIG.
  • [C-7-5] يجب تفعيل عميل البث الأحادي BAP، ومنسق مجموعة CSIP، وخادم MCP، ووحدة تحكم VCP، وخادم CCP في آن واحد.
  • [C-SR] يُنصح بشدة بتفعيل برنامج 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 من القياسات على مسافة 1 متر من جهاز مرجعي ينقله في ADVERTISE_TX_POWER_HIGH في بيئة خط الرؤية.
  • يجب أن يشتمل [C-10-2] على تصحيحات Rx/Tx لتقليل الانحرافات لكل قناة بحيث تكون القياسات في كل قناة من القنوات الثلاث وعلى كل من الهوائيات (في حال استخدام عدة هوائيات) ضمن نطاق +/-3 ديسيبل من بعضها البعض بنسبة 95% من القياسات.
  • [C-SR] يُنصح بشدة بقياس معادلة Rx وتعويضها للتأكّد من أنّ القيمة المتوسطة لترميز BLE RSSI تبلغ -60 ديسيبل ملي واط +/-10 ديسيبل على مسافة 1 متر من جهاز مرجعي ينقل البيانات في ADVERTISE_TX_POWER_HIGH، حيث تكون الأجهزة موجَّهة على "مستويات متوازية" مع توجيه الشاشات نفسها.
  • [C-SR] يُنصح بشدة بقياس معادلة Tx وتعويضها لضمان أن تبلغ قيمة متوسط BLE RSSI -60 ديسيبل ملي واط +/-10 ديسيبل عند المسح الضوئي من جهاز مرجعي يتم نقله على بُعد متر واحد ويتم إرساله في "ADVERTISE_TX_POWER_HIGH"، حيث تكون الأجهزة موجَّهة بحيث تكون في "المستوى المتوازي" مع الشاشات المواجهة لها

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

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

  • [C-SR] يُنصَح بشدة بتقديم الدعم في ما يلي:
    • LE 2 مليون
    • LE Codec PHY
    • إضافة LE Advertising
    • الإعلانات الدورية
    • 10 مجموعات إعلانية على الأقل
    • ما لا يقل عن 8 اتصالات متزامنة منخفضة الطاقة (LE). يمكن أن يكون كل رابط في أدوار طوبولوجيا الاتصال.
    • خصوصية طبقة رابط LE
    • حجم "حل القائمة" لا يقل عن 8 إدخالات

  إنهاء المتطلبات الجديدة

• 7.4.9 النطاق الفائق العرض (UWB): تمت إضافة قسم متطلبات أجهزة النطاق الفائق العرض (UWB).

  عرض النسخة السابقة

  7.4.9 النطاق الفائق العرض (UWB)

  في حال إبلاغ عمليات تنفيذ الأجهزة عن توافق ميزة android.hardware.uwb من خلال الفئة android.content.pm.PackageManager، سيتم عندها:

  • [C-1-1] يجب أن تكون قياسات المسافة ضمن +/-15 سم بالنسبة إلى 95% من القياسات في بيئة خط الرؤية على مسافة 1 متر في غرفة غير عاكسة.
  • يجب أن يضمن [C-1-2] أن يكون متوسط قياسات المسافة على بُعد متر واحد من الجهاز المرجعي في نطاق [0.75 متر أو 1.25 متر]، حيث يتم قياس مسافة الأرض من الحافة العلوية من الحافة العلوية من الجزء العلوي وإمالتها بمقدار 45 درجة.

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

  إنهاء المتطلبات الجديدة

• 7.5 الكاميرات: تعديلات على متطلبات إمكانية إخراج 10 بت بنطاق عالي الديناميكية (HDR).

  عرض النسخة السابقة

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

  • [C-2-1] يجب أن يتوافق مع ملف شخصي بتقنية HLG HDR على الأقل لكل جهاز كاميرا يتوافق مع إخراج 10 بت.
  • [C-2-2] يجب أن يتوفر إخراج 10 بت إما للكاميرا الخلفية الأساسية أو الأمامية الأساسية.
  • [C-SR] يُنصح بشدة بإتاحة الإخراج 10 بت لكلتا الكاميرتين الأساسيتين.
  • [C-2-3] يجب أن يتوافق مع ملفات HDR نفسها لكل الكاميرات الفرعية الفعلية المتوافقة مع BACKWARD_COMPATIBLE في الكاميرا المنطقية، والكاميرا المنطقية نفسها.

  بالنسبة إلى أجهزة الكاميرات المنطقية التي تتيح ميزة "فيديو 10 بت بنطاق HDR"، يتم تفعيل android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO واجهة برمجة تطبيقات:

  • [C-3-1] يجب أن يتيح التبديل بين جميع الكاميرات الفعلية المتوافقة مع الأنظمة القديمة من خلال عنصر التحكّم CONTROL_ZOOM_RATIO في الكاميرا المنطقية.

  إنهاء المتطلبات الجديدة

• 7.7.2 وضع مضيف USB: مراجعات لمنافذ ذات دورَين

  عرض النسخة السابقة

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

  • [C-4-1] يجب أن تنفذ وظيفة "منفذ الدور المزدوج" على النحو المحدّد في مواصفات USB من النوع C (الفقرة 4.5.1.3.3). بالنسبة إلى منافذ الدور المزدوجة، يمكن أن يتم تلقائيًا إيقاف ميزة "اكتشاف حوض USB" (وضع المضيف) على الأجهزة التي تتضمّن مقبس صوت مقاس 3.5 ملم، ولكن يجب أن يتمكّن المستخدم من تفعيلها.

• 7.11 Media Performance Class: تم التعديل لتضمين Android T.

  عرض النسخة السابقة

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

  • يجب أن يستوفي [C-1-3] جميع متطلبات "فئة أداء الوسائط" الموضّحة في القسم 2.2.7.

  بمعنى آخر، لا يتم تحديد فئة أداء الوسائط في Android T إلا للأجهزة المحمولة باليد من الإصدار T أو S أو R.

  إنهاء المتطلبات الجديدة

  راجِع القسم 2.2.7 للاطّلاع على المتطلبات الخاصة بالأجهزة.

‫9. توافق نموذج الأمان

• 9.1 الأذونات: يمكنك توسيع نطاق المسارات المقبولة للقوائم المسموح بها للأذونات الخاصة بالتطبيقات المثبَّتة مسبقًا إلى ملفات APEX.

  عرض النسخة السابقة

  • [C-0-2] الأذونات التي تتضمن protectionLevel من PROTECTION_FLAG_PRIVILEGED يجب ألا يتم منح الأذونات إلا للتطبيقات المثبَّتة مسبقًا في المسارات المميّزة لصورة النظام (بالإضافة إلى ملفات APK) وأن تكون ضمن المجموعة الفرعية من الأذونات المدرَجة في القائمة المسموح بها صراحةً لكل تطبيق. وتستوفي عملية تنفيذ AOSP هذا الشرط من خلال قراءة الأذونات المُدرَجة في القائمة المسموح بها لكل تطبيق والمسار المتاحetc/permissions/ واتّباعه.system/priv-app

• 9.7 ميزات الأمان: تعديلات على متطلبات الإعداد للحفاظ على سلامة النواة

  عرض النسخة السابقة

  تعتبر ميزات السلامة والحماية الذاتية في Kernel جزءًا لا يتجزأ من أمان Android. عمليات تنفيذ الأجهزة:

  • [C-SR] يُنصَح بشدة بتفعيل إعداد تسلسل استدعاء الدوال البرمجية في النواة لمنع استخدام المتغيّرات المحلية غير المهيأة (CONFIG_INIT_STACK_ALL أو CONFIG_INIT_STACK_ALL_ZERO). بالإضافة إلى ذلك، يجب ألا تفترض عمليات تنفيذ الأجهزة القيمة التي يستخدمها برنامج التحويل البرمجي لإعداد العناوين المحلية.

  إنهاء المتطلبات الجديدة

• 9.8.7 الخصوصية: الوصول إلى الحافظة: يمكنك محو بيانات الحافظة تلقائيًا بعد 60 دقيقة من نشاط القص أو النسخ/اللصق لحماية خصوصية المستخدم.

  عرض النسخة السابقة

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

  • [C-0-1] يجب ألا يعرض بيانات مقطوعة من الحافظة (على سبيل المثال، عبر واجهة ClipboardManager API) ما لم يكن تطبيق التابع لجهة خارجية هو أداة IME التلقائية أو هو التطبيق محل التركيز حاليًا.
  • [C-0-2] يجب محو بيانات الحافظة بعد 60 دقيقة كحد أقصى من وضعها في حافظة أو قراءتها من الحافظة آخر مرة.

• المفاتيح وبيانات الاعتماد 9.11: تعديلات على متطلبات شاشة القفل الآمنة، بما في ذلك إضافة ECDH و3DES إلى خوارزميات التشفير.

  عرض النسخة السابقة

  عندما يكون تنفيذ الجهاز متوافقًا مع شاشة قفل آمنة:

  • يجب أن يتضمّن [C-1-2] تطبيقات لترميز RSA وAES وECDSA وECDH (في حال توافق IKeyMintDevice) وخوارزميات التشفير 3DES وHMAC ووظائف التجزئة MD5 وSHA1 وSHA-2 للتوافق بشكل صحيح مع خوارزميات نظام تخزين مفاتيح Android المتوافقة أعلى من يجب أن تحظر ميزة العزل الآمن جميع الآليات المحتملة التي يمكن من خلالها وصول رمز النواة أو رمز مساحة المستخدم إلى الحالة الداخلية للبيئة المعزولة، بما في ذلك قانون الأسواق الرقمية. استوفى "المشروع المفتوح المصدر لنظام Android" (AOSP) هذا الشرط من خلال استخدام تنفيذ TrustZone، إلا أنّ الخيارات البديلة هي أحد الحلول البديلة المستنِدة إلى بروتوكول ARM TrustZone أو إحدى جهات خارجية التي تمت مراجعتها بشكل آمن ومستند إلى برنامج Hypervisor (مراقب الأجهزة الظاهرية).

• 9.11.1 "شاشة القفل الآمنة" و"المصادقة والأجهزة الافتراضية": تمت إضافة قسم لمتطلبات الأجهزة الافتراضية وعمليات نقل المصادقة.

  عرض النسخة السابقة

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

  • [C-6-3] يجب أن يطلب المستخدم إجراء إحدى طرق المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) مرة واحدة على الأقل كل 4 ساعات أو أقل. عندما يستوفي رمز مميّز مادي متطلبات عمليات تنفيذ TrustAgent في لغة C-X، يتم تطبيق قيود المهلة المحدّدة في C-9-5 بدلاً من ذلك.

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

  • [C-9-1] يجب قفل شاشات العرض الافتراضية الثانوية هذه عند قفل الشاشة التلقائية للجهاز، وفتح قفل هذه الشاشات الافتراضية الثانوية عندما تكون الشاشة التلقائية للجهاز غير مقفلة.

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

  • [C-10-1] يجب إتاحة حالات القفل المنفصلة لكل جهاز افتراضي
  • [C-10-2] يجب قطع اتصال جميع الأجهزة الافتراضية عند انتهاء مهلة عدم النشاط
  • [C-10-3] يجب أن تتضمن مهلة عدم النشاط
  • [C-10-4] يجب أن يقفل جميع الشاشات عندما يبدأ المستخدم إلغاء التأمين، بما في ذلك من خلال تكاليف المستخدم المتعلقة بالإغلاق المطلوبة للأجهزة المحمولة (راجع الفقرة 2.2.5[9.11/H-1-2])
  • [C-10-5] يجب أن تتوفّر لكل مستخدم مثيلات منفصلة للأجهزة الافتراضية.
  • [C-10-6] يجب أن يوقِف إنشاء أحداث الإدخال المرتبطة عبر VirtualDeviceManager عندما يُشار إليه بواسطة DevicePolicyManager.setNearbyAppStreamingPolicy
  • [C-10-7] يجب استخدام حافظة منفصلة لكل جهاز افتراضي فقط (أو إيقاف الحافظة للأجهزة الافتراضية)
  • [C-10-11] يجب إيقاف واجهة المستخدم للمصادقة على الأجهزة الافتراضية، بما في ذلك إدخال عامل المعرفة وطلب المقاييس الحيوية
  • [C-10-12] يجب أن تقيّد الأهداف التي تبدأ من جهاز افتراضي للعرض على الجهاز الافتراضي نفسه فقط
  • [C-10-13] يجب ألا تستخدم حالة قفل الجهاز الافتراضي كتفويض لمصادقة المستخدم من خلال نظام تخزين مفاتيح Android. يمكنك الاطّلاع على KeyGenParameterSpec.Builder.setUserAuthentication*.

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

  • [C-11-1] يجب تشفير عامل المعرفة باستخدام ضمانات الحماية المشابهة لتلك الموضّحة في التقرير الموجز حول خدمة Google Cloud Key Vault عند نقل عامل المعرفة من الجهاز المصدر إلى الجهاز المستهدف كي لا يمكن فك تشفير عامل المعرفة عن بُعد أو استخدامه لفتح قفل أي من الجهازَين عن بُعد.
  • [C-11-2] يجب أن تطلب من المستخدم في الجهاز المصدر تأكيد عامل المعرفة للجهاز المصدر قبل نقل عامل المعرفة إلى الجهاز المستهدف.
  • [C-11-3] يجب أن تطلب من المستخدم على الجهاز المستهدَف الذي يفتقر إلى أيّ عامل معرفة أساسي معيّن

  إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة قفل آمنة وتتضمّن وكيل ثقة واحدًا أو أكثر، يتصل ذلك بواجهة TrustAgentService.grantTrust() System API التي تحمل علامة 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() بعد مرور 24 ساعة كحد أقصى من منح الثقة، أو فترة عدم النشاط لمدة 8 ساعات، أو عند فقدان الاتصال الأساسي بالجهاز الفعلي القريب.

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

  • [C-13-8] يجب حظر الأنشطة التي تتضمن السمة android:canDisplayOnRemoteDevices أو البيانات الوصفية android.activity.can_display_on_remote_devices التي تم ضبطها على "خطأ" لمنع تشغيلها على الجهاز الافتراضي.
  • [C-13-9] يجب حظر الأنشطة التي لا تفعّل البث بشكل صريح والتي تشير إلى أنّها تعرض محتوًى حسّاسًا، بما في ذلك من خلال SurfaceView#setSecure أو FLAG_SECURE أو SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS، من بدء تشغيلها على الجهاز الافتراضي.
  • [C-13-10] يجب إيقاف تثبيت التطبيقات التي تم بدؤها من الأجهزة الافتراضية.

  إنهاء المتطلبات الجديدة

• 9.11.2 Strongbox: جعل مقاومة الهجمات الداخلية (IAR) أحد المتطلبات الضرورية.

  عرض النسخة السابقة

  للتحقّق من الامتثال لمعيار [C-1-3] إلى [C-1-9]، يجب تنفيذ ما يلي:

  • [C-SR] يُنصَح بشدة بتوفير مقاومة للهجوم الداخلي (IAR)، ما يعني أنّ المحلّل الداخلي الذي لديه إذن الوصول إلى مفاتيح توقيع البرامج الثابتة لا يمكنه إنشاء برامج ثابتة تتسبّب في تسرُّب جهاز StrongBox للأسرار، أو تجاوز متطلبات الأمان الوظيفية، أو إتاحة الوصول إلى بيانات المستخدمين الحسّاسة. والطريقة المقترحة لتنفيذ IAR هي السماح بتحديثات البرامج الثابتة فقط عندما يتم توفير كلمة مرور المستخدم الأساسي من خلال IAuthSecret HAL. ستصبح ميزة IAR من المتطلبات الضرورية في Android 14.

• 9.11.3 "بيانات اعتماد الهوية": تمت إضافة معلومات حول تنفيذ مرجع نظام "بيانات اعتماد الهوية".

  عرض النسخة السابقة

  يتم تحديد نظام بيانات الاعتماد الهوية وتحقيقه من خلال تنفيذ جميع واجهات برمجة التطبيقات في حزمة android.security.identity.*. تسمح واجهات برمجة التطبيقات هذه لمطوّري التطبيقات بتخزين مستندات هوية المستخدم واستردادها. عمليات تنفيذ الأجهزة:

  يوفّر "المشروع المفتوح المصدر لنظام Android" المشروع المرجعي لتطبيق موثوق به (libeic) يمكن استخدامه لتنفيذ نظام "بيانات اعتماد الهوية".

  إنهاء المتطلبات الجديدة

• 9.11.4 المصادقة على المعرّف: تمت إضافة قسم حول متطلبات مصادقة رقم التعريف.

  عرض النسخة السابقة

  9.11.4 مصادقة المعرّف

  يجب أن تتيح عمليات تنفيذ الأجهزة ميزة مصادقة الهوية.

  إنهاء المتطلبات الجديدة

• 9.17 Android Virtualization frame: تمت إضافة قسم لمتطلبات إطار عمل المحاكاة الافتراضية لنظام التشغيل Android.

  عرض النسخة السابقة

  9.17. إطار عمل المحاكاة الافتراضية على Android

  إذا كان الجهاز يتوافق مع واجهات برمجة تطبيقات إطار عمل المحاكاة الافتراضية على Android (android.system.virtualmachine.*)، سينفّذ مضيف Android ما يلي:

  • يجب أن يتوافق [C-1-1] مع جميع واجهات برمجة التطبيقات المحدّدة في حزمة android.system.virtualmachine.*.
  • [C-1-2] يجب ألا يُعدّل نظام التشغيل Android SELinux ونموذج الإذن لإدارة الأجهزة الافتراضية المحمية.
  • [C-1-3] يجب ألا يعدل القواعد الموجودة ضمن النظام/السياسة المتوفر في مشروع Android مفتوح المصدر (AOSP) أو يحذفها أو يحل محلها، ويجب أن تجمع السياسة مع جميع قواعد "Neverallow" الحالية
  • [C-1-4] يجب ألا يسمح باستخدام رمز غير موثوق به (مثل تطبيقات الجهات الخارجية) لإنشاء جهاز افتراضي محمي وتشغيله. ملاحظة: قد يتغير ذلك في إصدارات Android المستقبلية.
  • [C-1-5] يجب ألا يسمح للجهاز الافتراضي المحمي بتنفيذ رمز برمجي ليس جزءًا من صورة المصنع أو من تحديثاته. يجب عدم السماح بتشغيل أي محتوى لا يشمله برنامج "التشغيل المُتحقَّق منه من Android" (مثل الملفات التي تم تنزيلها من الإنترنت أو البيانات من مصدر غير معروف) في "جهاز افتراضي محمي".

  إذا كان الجهاز يوفِّر دعمًا لواجهات برمجة تطبيقات إطار عمل المحاكاة الافتراضية لنظام التشغيل Android (android.system.virtualmachine.*)، فإنّ أي مثيل لجهاز افتراضي محمي:

  • [C-2-1] يجب أن يتمكن من تشغيل جميع أنظمة التشغيل المتوفرة في واجهة برمجة التطبيقات الافتراضية في جهاز افتراضي محمي.
  • [C-2-2] يجب ألا يسمح للجهاز الافتراضي المحمي بتشغيل نظام تشغيل لم يتم توقيعه من قِبل جهة تنفيذ الجهاز أو مورّد نظام التشغيل.
  • [C-2-3] يجب ألا يسمح لجهاز افتراضي محمي بتنفيذ البيانات كرمز برمجي (على سبيل المثال، SELinux أبدًا لا تسمح بـ execmem).
  • [C-2-4] يجب ألا يعدّل أو يحذف أو يستبدل قواعد nonallow الحالية في النظام/sepolicy/microdroid المقدَّم في "المشروع المفتوح المصدر لنظام Android" (AOSP).
  • [C-2-5] يجب تنفيذ آليات الدفاع المتعمق للجهاز الافتراضي المحمي (مثل SELinux للأجهزة الافتراضية) حتى مع أنظمة التشغيل غير المجهرية.
  • [C-2-6] يجب أن يضمن أن برامج pVM الثابتة ترفض التشغيل إذا لم تتمكن من التحقق من الصورة الأولية.
  • [C-2-7] يجب أن تضمن رفض برامج pVM الثابتة للتشغيل في حال تم اختراق سلامة المثيل.img.

  إذا أتاح الجهاز استخدام واجهات برمجة تطبيقات إطار عمل المحاكاة الافتراضية على Android (android.system.virtualmachine.*)، سينفّذ برنامج Hypervisor (مراقب الأجهزة الظاهرية) ما يلي:

  • [C-3-1] يجب ألا يسمح لأي جهاز افتراضي (pVM) بالوصول إلى صفحة تابعة لكيان آخر (مثل جهاز افتراضي (PVM) آخر أو برنامج Hypervisor (مراقب الأجهزة الظاهرية)) ما لم يشاركه مالك الصفحة صراحةً. ويشمل ذلك الجهاز الافتراضي (VM) الخاص بالمضيف. وينطبق ذلك على عمليات الوصول إلى كل من وحدة المعالجة المركزية (CPU) ومنطقة السوق المحددة.
  • [C-3-2] يجب حجب بيانات الصفحة بعد استخدامها بواسطة جهاز افتراضي وقبل إرجاعها إلى المضيف (على سبيل المثال، تلف الجهاز).
  • [C-3-3] يجب التأكّد من تحميل برامج pVM الثابتة وتنفيذها قبل أي رمز في جهاز افتراضي (pVM).
  • [C-3-4] يجب أن يتأكد من أنّه لا يمكن الحصول على النسخة المخفية الوجهة والإصدارات المخصّصة لمثيل الجهاز الافتراضي (PVM) إلا من خلال هذا المثيل تحديدًا.

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

  • [C-4-1] يجب ألا يتم توفير وظائف لجهاز افتراضي يتيح تجاوز نموذج أمان Android.

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

  • يجب أن يتوافق [C-5-1] مع التجميع المعزول لتحديث وقت تشغيل ART.

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

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

  إنهاء المتطلبات الجديدة

13 التواصل معنا

يمكنك الانضمام إلى منتدى التوافق مع android وطلب توضيحات أو إثارة أي مشاكل تعتقد أن المستند لا يتناولها.