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

1. مقدّمة

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

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

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

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

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

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

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

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

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

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

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

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

يتمّ منح معرّف المتطلّبات للمتطلّبات التي يجب استيفاؤها.

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

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

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

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

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

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

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

‫2- أنواع الأجهزة

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

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

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

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

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

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

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

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

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

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

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

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

إذا كانت عمليات تنفيذ الأجهزة الجوّالة تدّعي توفّر شاشات مزوّدة بتقنية النطاق العالي الديناميكية من خلال 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] يجب أن يُبلغ عن مسار traced protobuf الذي يتوافق مع مخطّط عدّادات وحدة معالجة الرسومات ومراحل عرض وحدة معالجة الرسومات المحدّدة في مستندات Perfetto.
• [7.1.4.6/H-1-2] يجب أن تُبلغ عن قيم متوافقة لعدادات وحدة معالجة الرسومات في الجهاز وفقًا لبروتوكول حزمة تتبُّع عداد وحدة معالجة الرسومات.
• [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-3] يجب توفير وظيفة "الصفحة الرئيسية" على جميع الشاشات المتوافقة مع Android التي توفّر الشاشة الرئيسية.
• [7.2.3/H-0-4] يجب توفير وظيفة "الرجوع" على جميع الشاشات المتوافقة مع Android ووظيفة "التطبيقات المستخدَمة مؤخرًا" على الأقل على أحد الشاشات المتوافقة مع Android.
• [7.2.3/H-0-2] يجب إرسال حدثي الضغط العادي والضغط مع الاستمرار لدالّة الرجوع (KEYCODE_BACK) إلى التطبيق الذي يعمل في المقدّمة. يجب ألّا يستخدِم النظام هذه الأحداث ويمكن أن يتم تشغيلها من خارج جهاز Android (مثل الأجهزة الخارجية لوحة المفاتيح المتصلة بجهاز Android).
• [7.2.4/H-0-1] يجب أن يتيح الجهاز إدخال البيانات من خلال شاشة اللمس.
• [7.2.4/H-SR-1] يُنصح بشدة بتشغيل تطبيق المساعدة الذي يختاره المستخدم، أي التطبيق الذي ينفِّذ VoiceInteractionService، أو نشاط يعالج ACTION_ASSIST عند الضغط مع الاستمرار على KEYCODE_MEDIA_PLAY_PAUSE أو KEYCODE_HEADSETHOOK إذا كان النشاط الذي يعمل في المقدّمة لا يعالج أحداث الضغط مع الاستمرار هذه.
• [7.3.1/H-SR-1] يُنصح بشدة بتضمين مقياس تسارع ثلاثي المحاور.

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

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

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

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

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

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

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

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

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

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

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

إذا كانت عمليات تنفيذ الأجهزة الجوّالة تعلن عن توافقها مع معرّف ABI لنظام التشغيل 32 بت فقط:

• [7.6.1/H-1-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 416 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم دقة framebuffer تصل إلى qHD (مثل FWVGA).

• [7.6.1/H-2-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 592 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم دقة framebuffer تصل إلى HD+ (مثل HD وWSVGA).

• [7.6.1/H-3-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 896 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم دقة framebuffer تصل إلى FHD (مثل WSXGA+).

• [7.6.1/H-4-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 1344 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم درجات دقة إطار الذاكرة المؤقتة تصل إلى QHD (مثل QWXGA).

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

• [7.6.1/H-5-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم بسعة 816 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم دقة إطارات الذاكرة المؤقتة التي تصل إلى qHD (مثل FWVGA).

• [7.6.1/H-6-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 944 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم دقة إطارات الذاكرة المؤقتة التي تصل إلى HD+ (مثل HD وWSVGA).

• [7.6.1/H-7-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 1280 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم دقة إطار الذاكرة حتى FHD (مثل WSXGA+).

• [7.6.1/H-8-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 1824 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم دقة إطارات الذاكرة المؤقتة التي تصل إلى QHD (مثل QWXGA).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

عند رصد أنواع وحدات التحكّم في الصوت عبر USB‏ 0x0302، يتم تنفيذ ما يلي:

• [7.8.2.2/H-2-1] يجب بث Intent ACTION_HEADSET_PLUG مع تحديد قيمة 0 لسمة "microphone" الإضافية.

عند رصد أنواع وحدات تحكّم الصوت عبر USB‏ 0x0402، يتم تنفيذ ما يلي:

• [7.8.2.2/H-3-1] يجب بث Intent ACTION_HEADSET_PLUG مع تحديد قيمة 1 لإضافة "الميكروفون".

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

• [7.8.2.2/H-4-1] يجب إدراج جهاز من النوع AudioDeviceInfo.TYPE_USB_HEADSET ويكون دوره isSink() إذا كان حقل نوع وحدة الإدخال/الإخراج الصوتية عبر USB هو 0x0302.

• [7.8.2.2/H-4-2] يجب إدراج جهاز من النوع AudioDeviceInfo.TYPE_USB_HEADSET ودور isSink() إذا كان حقل نوع وحدة التحكّم في الصوت عبر USB هو 0x0402.

• [7.8.2.2/H-4-3] يجب إدراج جهاز من النوع AudioDeviceInfo.TYPE_USB_HEADSET ودور isSource() إذا كان حقل نوع تجهيز الصوت بمنفذ USB ‏0x0402.

• [7.8.2.2/H-4-4] يجب إدراج جهاز من النوع AudioDeviceInfo.TYPE_USB_DEVICE ويكون دوره isSink() إذا كان حقل نوع وحدة التحكّم في الصوت عبر USB هو 0x603.

• [7.8.2.2/H-4-5] يجب إدراج جهاز من النوع AudioDeviceInfo.TYPE_USB_DEVICE ويكون دوره isSource() إذا كان حقل نوع تجهيز الصوت بمنفذ USB ‏0x604.

• [7.8.2.2/H-4-6] يجب إدراج جهاز من النوع AudioDeviceInfo.TYPE_USB_DEVICE ودور isSink() إذا كان حقل نوع وحدة التحكّم في الصوت USB يساوي 0x400.

• [7.8.2.2/H-4-7] يجب إدراج جهاز من النوع AudioDeviceInfo.TYPE_USB_DEVICE ودور isSource() إذا كان حقل نوع وحدة التحكّم في الصوت عبر USB هو 0x400.

• [7.8.2.2/H-SR-1] يُنصح بشدة عند توصيل جهاز محيطي للصوت بمنفذ USB-C بتنفيذ عملية سرد لموصّفات USB وتحديد أنواع المحطات وبث Intent ACTION_HEADSET_PLUG في أقل من 1000 ملي ثانية.

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

• [5.6(#56_audio-latency)/H-1-1] يجب أن يكون متوسّط وقت الاستجابة المستمر لسلسلة إرسال البيانات واستقبالها 800 ملي ثانية أو أقل على مدار 5 قياسات، مع متوسّط اختلاف مطلق أقل من 100 ملي ثانية، على مسار واحد متوافق على الأقل.

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

• [7.10/ساعة]* يجب عدم استخدام كتلة دوّارة غريبة الأطوار (ERM) مشغِّل لمسي (مُحرِّك اهتزازي).
• [7.10/ساعة]* يجب وضع المحرِّك بالقرب من المكان الذي يتم عادةً فيه حمل الجهاز أو لمسه باليدين.
• [7.10/H]* يجب تنفيذ جميع الثوابت العامة لسمة اللمسات الواضحة في android.view.HapticFeedbackConstants ، وهي (CLOCK_TICK وCONTEXT_CLICK وKEYBOARD_PRESS وKEYBOARD_RELEASE وKEYBOARD_TAP وLONG_PRESS وTEXT_HANDLE_MOVE وVIRTUAL_KEY وVIRTUAL_KEY_RELEASE وCONFIRM وREJECT وGESTURE_START وGESTURE_END).
• [7.10/ساعة]* يجب أن تُنفِّذ جميع الثوابت العامة لسمة اللمسات الواضحة في android.os.VibrationEffect ، وهي (EFFECT_TICK وEFFECT_CLICK وEFFECT_HEAVY_CLICK و EFFECT_DOUBLE_CLICK) وجميع الثوابت العامة لسمة اللمسات الغنية في android.os.VibrationEffect.Composition ، وهي (PRIMITIVE_CLICK وPRIMITIVE_TICK).
• [7.10/ساعة]* يجب أن تستخدم هذه الثابتة المرتبط عمليات الربط.
• [7.10/ساعة]* يجب أن يتّبع تقييم الجودة لواجهات برمجة التطبيقات createOneShot() وcreateWaveform().
• [7.10/H]* يجب التحقّق من إمكانات توسيع نطاق amplitude من خلال تنفيذ android.os.Vibrator.hasAmplitudeControl().

المحرِّك الخطي للمعايرة (LRA) هو نظام زنبرك ذو كتلة واحدة يمتلك ترددًا مميّزًا للمعايرة حيث تتحرّك الكتلة في اتجاه الحركة المطلوبة.

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

• [7.10/ساعة]* من المفترض أن يحرك المحرِّك اللمسي على محور X في اتجاه عمودي.

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

• [7.10/ساعة]* يجب أن يكون تردد الرنين للمحور X LRA أقل من 200 هرتز.

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

• [7.10/H]* يجب التحقّق من حالة التنفيذ من خلال تشغيل واجهتَي برمجة التطبيقات android.os.Vibrator.areAllEffectsSupported()‎ وandroid.os.Vibrator.arePrimitvesSupported()‎.
• [7.10/ساعة]* يجب إجراء تقييم للجودة للثوابت اللمسية.
• [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 Profile (AAC LC)
• [5.1/H-0-4] MPEG-4 HE AAC Profile (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] يُنصح بشدة باستخدام مشغّل افتراضي يتيح تثبيت الاختصارات والتطبيقات المصغّرة وwidgetFeatures داخل التطبيق.
• [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] يجب أن يتضمّن ظلّ الإشعارات، ما يمنح المستخدم إمكانية التحكّم مباشرةً في الإشعارات (مثل الردّ أو الإيقاف المؤقت أو الإغلاق أو الحظر) من خلال ميزات مساعدة المستخدم، مثل buttons buttons أو لوحة التحكّم كما هو مُطبَّق في 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] يُنصح بشدة بتنفيذ مساعد على الجهاز لمعالجة الإجراء المساعد.

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

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

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

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

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

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

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

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

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

• [3.8.16/H-1-1] يجب الإفصاح عن علامة الميزة android.software.controls وضبطها على true.
• [3.8.16/H-1-2] يجب أن يوفّر التطبيق للمستخدم ميزات تتيح له إضافة عناصر التحكّم المفضّلة لديه في الجهاز وتعديلها واختيارها وتشغيلها من عناصر التحكّم المسجّلة من خلال التطبيقات التابعة لجهات خارجية من خلال واجهات برمجة التطبيقات ControlsProviderService وControl.
• [3.8.16/H-1-3] يجب توفير إمكانية الوصول إلى هذه الميزة للمستخدم في غضون ثلاث تفاعلات من مشغّل التطبيقات التلقائي.
• [3.8.16/H-1-4] يجب أن يعرض هذا العنصر المتاح للمستخدمين اسم كل تطبيق تابع لجهة خارجية يقدّم عناصر تحكّم من خلال واجهة برمجة التطبيقات ControlsProviderService بالإضافة إلى أي حقول محدّدة تقدّمها واجهات برمجة التطبيقات Control بدقة.

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

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

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

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

إذا كانت عمليات تنفيذ الأجهزة المحمولة التي تعمل بنظام التشغيل Android تعلن عن توافقها مع FEATURE_BLUETOOTH أو FEATURE_WIFI، يجب استيفاء الشروط التالية:

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

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

• [7.2.3/H] يجب ألا يزيد ارتفاع منطقة التعرّف على الإيماءات لميزة "منزل" عن 32 dp من أسفل الشاشة.

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

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

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

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

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

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

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

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

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

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

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

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

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

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" في منطقة معزولة بشكل آمن عن الرمز البرمجي الذي يعمل على النواة والإصدارات الأحدث. يجب أن تحظر ميزة "العزل الآمن" جميع الآليات المحتملة التي يمكن من خلالها لرمز kernel أو مساحة المستخدم الوصول إلى الحالة الداخلية للبيئة المعزولة، بما في ذلك DMA. يستوفي "المشروع المفتوح المصدر لنظام Android" (AOSP) هذا الشرط من خلال استخدام عملية تنفيذ Trusty، ولكن هناك خياران بديلة هما أحد الحلول المقترَحة المستندة إلى ARM TrustZone أو عملية تنفيذ آمنة تمت مراجعتها من قِبل جهة خارجية لتوفير عزل مناسب بالاستناد إلى أداة إدارة الأجهزة الافتراضية.
• [9.11/H-0-4] يجب تنفيذ مصادقة شاشة القفل في بيئة التنفيذ المعزولة، والسماح باستخدام المفاتيح المرتبطة بالمصادقة فقط عند اختلاف. يجب تخزين بيانات اعتماد شاشة القفل بطريقة لا تسمح إلا لبيئة التنفيذ المعزولة بإجراء مصادقة شاشة القفل. يقدّم مشروع Android Open Source Project الإصدارات السابقة من Gatekeeper Hardware Abstraction Layer (HAL) وTrusty، والتي يمكن استخدامها لاستيفاء هذا الشرط.
• [9.11/H-0-5] يجب أن تتيح المصادقة على المفاتيح حيث يتم حماية مفتاح توقيع المصادقة باستخدام جهاز آمن ويتم تنفيذ التوقيع على جهاز آمن. يجب مشاركة مفاتيح توقيع الإثبات على عدد كبير بما يكفي من الأجهزة لمنع استخدام المفاتيح كمعرّفات للأجهزة. وإحدى الطرق لاستيفاء هذا الشرط هي مشاركة مفتاح الإثبات نفسه ما لم يتم تصنيع 100,000 وحدة على الأقل من رمز التخزين التعريفي معيّن. إذا تم إنتاج أكثر من 100,000 وحدة من رمز التخزين التعريفي، قد يتم استخدام مفتاح مختلف لكل 100,000 وحدة.
• [9/H-0-1] يجب الإفصاح عن ميزة "android.hardware.security.model.compatible" .

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

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

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

• [9.8/H-1-1] يجب التأكّد من أنّ خدمة رصد الكلمات الرئيسية لا يمكنها إرسال سوى البيانات إلى System أو ContentCaptureService
• [9.8/H-1-2] يجب التأكّد من أنّ خدمة رصد الكلمات الرئيسية لا يمكنها نقل سوى data الصوتية من الميكروفون أو البيانات المستمدة منها إلى خادم النظام من خلال واجهة برمجة التطبيقات HotwordDetectionService، أو إلى ContentCaptureService من خلال واجهة برمجة التطبيقات ContentCaptureManager.
• [9.8/H-1-3] يجب عدم تقديم صوت من الميكروفون أطول من 30 ثانية لطلب individual individual hardware-triggered request إلى خدمة رصد الكلمات الرئيسية.
• [9.8/H-1-4] يجب عدم تقديم صوت من الميكروفون محفوظ في الذاكرة أقدم من 8 ثوانٍ لطلب individual request إلى خدمة رصد الكلمات المهمة.
• [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-13] يجب إعادة تشغيل العملية التي تستضيف خدمة رصد الكلمات الرئيسية مرة واحدة على الأقل كل ساعة أو بعد كل 30 حدثًا يتم تشغيله بالأجهزة، أيهما أولاً.
• [9.8/H-1-14] يجب عرض مؤشر الميكروفون، كما هو موضّح في القسم 9.8.2، عند إرسال نتيجة كلمة تشغيل ناجحة إلى خدمة التفاعل الصوتي أو كيان مشابه.
• [9.8/H-SR-1] يُنصح بشدة بإشعار المستخدمين قبل ضبط التطبيق كمقدّم خدمة رصد الكلمات الرئيسية.
• [9.8/H-SR-2] يُنصح بشدة بعدم السماح بإرسال البيانات غير المنظَّمة خارج خدمة رصد الكلمات الرئيسية.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن تطبيقًا يستخدم واجهة برمجة التطبيقات 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()، بالإضافة إلى أي رسائل تحديد مصدر مرتبطة بها.
• [9.8.2/H-4-3] يجب عدم إخفاء مؤشر الميكروفون ل تطبيقات النظام التي تتضمّن واجهات مستخدم مرئية أو تفاعلًا مباشرًا مع المستخدم.
• [9.8.2/H-4-4] يجب عرض قائمة التطبيقات المستخدَمة مؤخرًا والنشطة التي تستخدم الميكروفون كما هو موضّح في PermissionManager.getIndicatorAppOpUsageData()، بالإضافة إلى أي رسائل تحديد مصدر مرتبطة بها.

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

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

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

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

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

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

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

2.2.7. فئة أداء الوسائط على الأجهزة الجوّالة

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

2.2.7.1. الوسائط

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

• يجب استيفاء متطلبات الوسائط الواردة في CDD لنظام التشغيل Android 11 القسم 2.2.7.1

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

• [5.1/H-1-1] يجب الإعلان عن الحد الأقصى لعدد جلسات فك ترميز الفيديو في الأجهزة التي يمكن تشغيلها بشكل متزامن في أي مجموعة من برامج الترميز من خلال الطريقتَين CodecCapabilities.getMaxSupportedInstances() وVideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-2] يجب أن يكون متوافقًا مع 6 عمليات تشغيل لملفات ترميز الفيديو في الأجهزة (AVC أو HEVC أو VP9* أو الإصدارات الأحدث) في أي مجموعة من برامج الترميز التي تعمل بالتزامن بدقة 720p بمعدّل 30 لقطة في الثانية. *لا يلزم سوى مثيلَين في حال توفّر ملف ترميز VP9.
• [5.1/H-1-3] يجب الإعلان عن الحد الأقصى لعدد جلسات فاقدي ترميز الفيديو في الأجهزة التي يمكن تشغيلها بشكل متزامن في أي مجموعة من برامج الترميز من خلال الأسلوبين CodecCapabilities.getMaxSupportedInstances() وVideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-4] يجب أن يكون متوافقًا مع 6 جلسات من تطبيقات ترميز الفيديو في الأجهزة (AVC أو HEVC أو VP9* أو الإصدارات الأحدث) في أي مجموعة من برامج الترميز التي تعمل بالتزامن بدقة 720p ومعدل 30 لقطة في الثانية. *لا يلزم سوى مثيلَين في حال توفّر برنامج ترميز VP9.
• [5.1/H-1-5] يجب الإعلان عن الحد الأقصى لعدد جلسات ترميز وفك ترميز الفيديو في الأجهزة التي يمكن تشغيلها بشكل متزامن في أي مجموعة من برامج الترميز من خلال CodecCapabilities.getMaxSupportedInstances() وVideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-6] يجب أن يكون الجهاز مزوّدًا بـ 6 عمليات لفك ترميز الفيديو وجلسات برمجة ترميزه (AVC أو HEVC أو VP9* أو الإصدارات الأحدث) في أي تركيبة من برامج الترميز التي تعمل بشكل متزامن بدقة 720p ومعدل 30 لقطة في الثانية. *لا يلزم سوى مثيلَين في حال توفّر برنامج ترميز VP9.
• [5.1/H-1-7] يجب أن يكون وقت استجابة إعداد ترميز الفيديو 50 ملي ثانية أو أقل لجلسة ترميز فيديو بدقة 1080p أو أقل لجميع برامج ترميز الفيديو المزوّدة بالأجهزة (باستثناء برنامج ترميز Dolby Vision) عند تحميلها. يتم تعريف "التحميل" هنا على أنّه جلسة تحويل ترميز متزامنة للفيديوهات فقط من دقة 1080p إلى 720p باستخدام برامج ترميز الفيديوهات على الأجهزة مع بدء تسجيل الصوت والفيديو بدقة 1080p.
• [5.1/H-1-8] يجب أن يكون وقت استجابة إعداد ترميز الصوت 40 ملي ثانية أو أقل لجلسة ترميز صوت بمعدل 128 كيلوبت في الثانية أو أقل لجميع برامج ترميز الصوت عند معالجة حمولة. يتم تعريف "التحميل" هنا على أنّه جلسة تحويل ترميز متزامنة للفيديوهات فقط من دقة 1080p إلى 720p باستخدام برامج ترميز الفيديو على الأجهزة، بالإضافة إلى بدء تسجيل الصوت والفيديو بدقة 1080p.
• [5.3/H-1-1] يجب ألا يتم إسقاط أكثر من لقتَين في 10 ثوانٍ (أي أقل من 0.333 في المئة من عدد اللقطات) لجلسة فيديو بدقة 1080p وعدد لقطات في الثانية 60 أثناء التحميل. يتم تعريف "الحمل" على أنّه جلسة تحويل ترميز متزامنة للفيديوهات فقط من دقة 1080p إلى 720p باستخدام برامج ترميز الفيديو للأجهزة، بالإضافة إلى تشغيل محتوى صوتي بتنسيق AAC بمعدّل 128 كيلوبت في الثانية.
• [5.3/H-1-2] يجب عدم إسقاط أكثر من إطارَين في 10 ثوانٍ أثناء تغيير درجة دقة الفيديو في جلسة فيديو بمعدل 60 لقطة في الثانية أثناء التحميل. يتم تعريف "الحمل" على أنّه جلسة تحويل ترميز للفيديوهات فقط تتم بشكل متزامن من دقة 1080p إلى 720p باستخدام برامج ترميز للفيديوهات على الأجهزة، بالإضافة إلى تشغيل صوت بترميز AAC بمعدّل 128 كيلوبت في الثانية.
• [5.6/H-1-1] يجب أن يكون وقت استجابة النقر على الشاشة لسماع الصوت أقل من 100 ملي ثانية باستخدام اختبار النقر على الشاشة لسماع الصوت في OboeTester أو اختبار النقر على الشاشة لسماع الصوت في CTS Verifier.

2.2.7.2. الكاميرا

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

• يجب استيفاء متطلبات الكاميرا الواردة في CDD لنظام التشغيل Android 11 القسم 2.2.7.2

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

• [7.5/H-1-1] يجب أن تتضمّن الكاميرا الأساسية الخلفية دقة 12 ميغا بكسل على الأقل مع إمكانية تسجيل الفيديو بدقة 4K بمعدل 30 لقطة في الثانية. الكاميرا الخلفية الأساسية هي الكاميرا الخلفية التي تحمل رقم تعريف الكاميرا الأقل.
• [7.5/H-1-2] يجب أن تتضمّن الكاميرا الأمامية الأساسية دقة rzęd 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 أقل من 1000 ملي ثانية عند استخدام دقة 1080p، وذلك وفقًا لما يتم قياسه من خلال اختبار أداء الكاميرا في CTS في ظروف الإضاءة ITS (3000K) لكلتا الكاميرتين الأساسيتين.
• [7.5/H-1-6] يجب أن يكون وقت استجابة بدء تشغيل camera2 (فتح الكاميرا إلى أول ملف شخصي إطار) أقل من 600 ملي ثانية كما تم قياسه من خلال اختبار أداء كاميرا CTS في ظل ظروف الإضاءة ITS (3000K) لكلتا الكاميرتين الأساسيتين.
• [7.5/H-1-8] يجب أن تكون الكاميرا الخلفية الأساسية متوافقة مع CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW وandroid.graphics.ImageFormat.RAW_SENSOR.

2.2.7.3. الأجهزة

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

• يجب استيفاء متطلبات الأجهزة الواردة في CDD لنظام التشغيل Android 11 القسم 2.2.7.3

إذا كانت عمليات تنفيذ الأجهزة الجوّالة تعرض android.os.Build.VERSION_CODES.S لحالة android.os.Build.VERSION.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] يجب أن يكون الجهاز مزوّدًا بذاكرة أساسية لا تقلّ عن 6 غيغابايت.

2.2.7.4. الأداء

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

• يجب استيفاء متطلبات الأداء الواردة في CDD لنظام التشغيل Android 11 القسم 2.2.7.4

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

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

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

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

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

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

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

2.3.1. الأجهزة

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

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

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

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

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

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

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

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

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

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

  • 400 نقطة في البوصة أو أعلى على الشاشات الصغيرة/العادية
  • ‫xhdpi أو إصدار أحدث على الشاشات الكبيرة
  • ‫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 Profile (AAC LC)
• [5.1/T-0-2] MPEG-4 HE AAC Profile (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 من High Profile

يجب أن تتيح عمليات تنفيذ أجهزة التلفزيون المزوّدة ببرامج فك ترميز الأجهزة لتنسيق 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 لقطة في الثانية باستخدام ملف تعريف Main10 من المستوى 5 من الفئة الرئيسية

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

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

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

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

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

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

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

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

2.3.3. البرامج

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [8.3/T-1-3] يجب أن يقدّم التطبيق للمستخدم ميزة لعرض جميع التطبيقات المعفاة من وضعَي "الاستراحة" و"الاستراحة الذكية" لتوفير الطاقة.

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

• [8.4/T-0-1] يجب تقديم ملف تعريف استهلاك الطاقة لكل مكوّن يحدِّد قيمة الاستهلاك الحالي لكل مكوّن من مكوّنات الأجهزة ومعدل استنزاف البطارية التقريبي الذي يسبّبه المكوّنات بمرور الوقت كما هو موضّح في الموقع الإلكتروني لمشروع Android المفتوح المصدر.
• [8.4/T-0-2] يجب الإبلاغ عن جميع قيم استهلاك الطاقة بالمللي أمبير ساعة (mAh).
• [8.4/T-0-3] يجب الإبلاغ عن استهلاك طاقة وحدة المعالجة المركزية (CPU) حسب المعرّف الفريد لكل عملية. يستوفي "مشروع مفتوح المصدر لنظام Android" المتطلبات من خلال تنفيذ وحدة نواة uid_cputime.
• [8.4/T] يجب أن يُنسَب إلى مكوّن الجهاز نفسه في حال تعذُّر تحديد تطبيق معيّن يستخدِم طاقة مكوّن الجهاز.
• [8.4/T-0-4] يجب أن يتيح مطوّر التطبيقات استخدام الطاقة هذا من خلال الأمر 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" المتاحة بشكلٍ سليم في منطقة معزولة بشكلٍ آمن عن الرمز البرمجي الذي يعمل على النواة والإصدارات الأحدث. يجب أن تحظر ميزة "العزل الآمن" جميع الآليات المحتملة التي يمكن من خلالها لرمز kernel أو مساحة المستخدم الوصول إلى الحالة الداخلية للبيئة المعزولة، بما في ذلك DMA. يستوفي "المشروع المفتوح المصدر لنظام Android" (AOSP) هذا الشرط من خلال استخدام عملية تنفيذ Trusty، ولكن هناك خياران بديلة هما أحد الحلول المقترَحة المستندة إلى ARM TrustZone أو عملية تنفيذ آمنة تمت مراجعتها من قِبل جهة خارجية لتوفير عزل مناسب بالاستناد إلى أداة إدارة الأجهزة الافتراضية.
• [9.11/T-0-3] يجب تنفيذ مصادقة شاشة القفل في بيئة التنفيذ المعزولة، وعند نجاح المصادقة فقط، يجب السماح باستخدام المفاتيح المرتبطة بالمصادقة. يجب تخزين بيانات اعتماد شاشة القفل بطريقة لا تسمح إلا لبيئة التنفيذ المعزولة بإجراء مصادقة شاشة القفل. يقدّم مشروع Android Open Source Project الإصدارات السابقة من Gatekeeper Hardware Abstraction Layer (HAL) وTrusty، والتي يمكن استخدامها لاستيفاء هذا الشرط.
• [9.11/T-0-4] يجب أن يكون متوافقًا مع مصادقة المفتاح حيث يتم حماية مفتاح توقيع المصادقة باستخدام جهاز آمن ويتم تنفيذ التوقيع على جهاز آمن. يجب مشاركة مفاتيح توقيع الإثبات على عدد كبير بما يكفي من الأجهزة لمنع استخدام المفاتيح كمعرّفات للأجهزة. وإحدى الطرق لاستيفاء هذا الشرط هي مشاركة مفتاح الإثبات نفسه ما لم يتم تصنيع 100,000 وحدة على الأقل من رمز التخزين التعريفي معيّن. إذا تم إنتاج أكثر من 100,000 وحدة من رمز التخزين التعريفي، قد يتم استخدام مفتاح مختلف لكل 100,000 وحدة.
• [9/T-0-1] يجب الإفصاح عن ميزة "android.hardware.security.model.compatible" .

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

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

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

• Perfetto
  • [6.1/T-0-1] يجب عرض /system/bin/perfetto ملف ثنائي لمستخدم shell يكون cmdline متوافقًا مع مستندات perfetto.
  • [6.1/T-0-2] يجب أن يقبل ملف perfetto الثنائي كأحد مدخلات ملف إعدادات protobuf متوافق مع المخطّط المحدّد في مستندات perfetto.
  • [6.1/T-0-3] يجب أن يكتب ملف perfetto الثنائي كملف أثر protobuf يتوافق مع المخطط المحدّد في مستندات perfetto.
  • [6.1/T-0-4] يجب أن يوفّر الإصدار، من خلال ملف برمجي ثنائي لـ perfetto، على الأقل مصادر البيانات الموضّحة في مستندات 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] يجب أن تتوفّر للمستخدم دالة Home والدالة Back باستثناء الحالات التي يكون فيها الجهاز في وضع UI_MODE_TYPE_WATCH.

• [7.2.4/W-0-1] يجب أن تتيح إمكانية إدخال البيانات من خلال شاشة اللمس.

• [7.3.1/W-SR-1] يُنصح بشدة بتضمين accelerometer (مقياس تسارع) بثلاثة محاور.

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

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

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

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

اطّلِع على عمليات تنفيذ الأجهزة:

• [7.4.3/W-0-1] يجب أن يكون الجهاز متوافقًا مع البلوتوث.

• [7.6.1/W-0-1] يجب أن يتوفّر مساحة تخزين دائمة بسعة 1 غيغابايت على الأقل لبيانات التطبيق الخاصة (المعروفة أيضًا باسم قسم "‎/data").

• [7.6.1/W-0-2] يجب أن تتوفّر ذاكرة بسعة 416 ميغابايت على الأقل للنواة ومساحة المستخدم.

• [7.8.1/W-0-1] يجب أن يتضمّن الجهاز ميكروفونًا.

• [7.8.2/W] قد يتضمّن مخرج صوت.

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

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

2.4.3. البرامج

اطّلِع على عمليات تنفيذ الأجهزة:

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

اطّلِع على عمليات تنفيذ الأجهزة:

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

راقِب عمليات التنفيذ على الأجهزة التي تحدّد android.hardware.audio.output علامة الفلاش المميّزة:

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

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

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

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

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

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

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

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

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

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

2.5.1. الأجهزة

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

• [7.1.1.1/A-0-1] يجب أن يكون حجم الشاشة على الأقل 6 بوصة (15.2 سم) في شكله العمودي.

• [7.1.1.1/A-0-2] يجب أن يتضمّن تنسيق حجم الشاشة ‫750 dp x ‏480 dp على الأقل.

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

• [7.3/A-0-2] الموقع الجغرافي الذي تم طلبه من خلال LocationManager#requestLocationUpdates()‎ يجب ألّا يكون مطابقًا للخريطة.

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

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

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

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

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

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

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

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

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

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

• [7.4.5/أ] يجب أن يتضمّن الجهاز إمكانية الربط بشبكة بيانات الجوّال.

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

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

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

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

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

• [7.5/A-1-1] يجب ألّا تتيح كاميرات الرؤية الخارجية الوصول إليها من خلال واجهات برمجة تطبيقات كاميرا Android، ما لم تكن متوافقة مع المتطلبات الأساسية للكاميرا.
• [7.5/A-SR-1] يُنصح بشدة بعدم تدوير معاينة الكاميرا أو عكسها أفقيًا.
• [7.5.5/A-SR-1] يُنصح بشدة بتوجيه الكاميرا بحيث تتماشى سمتها الطويلة مع الأفق.
• [7.5/A-SR-2] يُنصح بشدة بأن تكون درجة دقة الصور 1.3 ميغابكسل على الأقل.
• يجب أن يكون مزوّدًا بأجهزة ذات تركيز ثابت أو بميزة "عمق مجال الصورة الموسّع".
• يجب أن يكون متوافقًا مع إطار عمل مزامنة Android.
• قد يكون قد تم تنفيذ ميزة التركيز التلقائي للأجهزة أو التركيز التلقائي للبرامج في برنامج تشغيل الكاميرا.

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

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

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

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

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

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

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

  • ‫280 نقطة في البوصة أو أقل على الشاشات الصغيرة/العادية
  • ldpi أو أقل على الشاشات الكبيرة جدًا
  • mdpi أو أقل على الشاشات الكبيرة

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

  • ‫xhdpi أو أعلى على الشاشات الصغيرة/العادية
  • دقة عالية جدًا أو أعلى على الشاشات الكبيرة
  • mdpi أو أعلى على الشاشات الكبيرة جدًا

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

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

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

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

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

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

  • ‫280 نقطة في البوصة أو أقل على الشاشات الصغيرة/العادية
  • ldpi أو أقل على الشاشات الكبيرة جدًا
  • mdpi أو أقل على الشاشات الكبيرة

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

  • ‫xhdpi أو أعلى على الشاشات الصغيرة/العادية
  • دقة عالية جدًا أو أعلى على الشاشات الكبيرة
  • mdpi أو أعلى على الشاشات الكبيرة جدًا

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

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

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

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

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

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

• [7.7.1/أ] يجب أن يتضمّن منفذ 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 Profile (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.*.

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

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

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

• [3.2.1/A-0-1] يجب أن يتيح التطبيق استخدام كل CONSTANT للأذونات ويفرض استخدامها كما هو موضّح في صفحة مرجع أذونات السيارات.

• [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] يُنصح بشدة بتنفيذ مساعد على الجهاز لمعالجة الإجراء المساعد.

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

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

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

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

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

• [3.9.3/A-1-1] يجب تنفيذ كلّ خصائص رحلة المستخدِم
  • INITIAL_USER_INFO، SWITCH_USER، CREATE_USER، REMOVE_USER.

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

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

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

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

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

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

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

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

• [8.2/A-0-1] يجب الإبلاغ عن عدد البايت التي تم قراءتها وكتابتها في مساحة التخزين غير القابلة للفقد لكل معرّف مستخدم فريد لكل عملية حتى تكون الإحصاءات متاحة للمطوّرين من خلال System API android.car.storagemonitoring.CarStorageMonitoringManager. يستوفي "مشروع مفتوح المصدر لنظام Android" المتطلّبات من خلال وحدة نواة uid_sys_stats.
• [8.3/أ-1-3] يجب أن يكون الجهاز متوافقًا مع وضع المرآب.
• [8.3/أ] يجب أن يكون الجهاز في وضع "المرآب" لمدة 15 دقيقة على الأقل بعد كل رحلة ما لم يكن:
  • نفاذ شحن البطارية
  • لا يتم جدولة أي مهام غير نشطة.
  • يخرج السائق من "وضع المرآب".
• [8.4/A-0-1] يجب تقديم ملف تعريف استهلاك الطاقة لكل مكوّن يحدّد قيمة الاستهلاك الحالي لكل مكوّن من مكوّنات الأجهزة ومعدل استنزاف البطارية التقريبي الذي يسببه المكوّنات بمرور الوقت كما هو موضّح في الموقع الإلكتروني لمشروع Android Open Source Project.
• [8.4/A-0-2] يجب الإبلاغ عن جميع قيم استهلاك الطاقة بالمللي أمبير ساعة (mAh).
• [8.4/A-0-3] يجب الإبلاغ عن استهلاك طاقة وحدة المعالجة المركزية (CPU) حسب المعرّف الفريد لكل عملية. يستوفي "مشروع مفتوح المصدر لنظام Android" المتطلبات من خلال تنفيذ وحدة نواة uid_cputime.
• [8.4/أ] يجب أن يُنسَب إلى مكوّن الجهاز نفسه في حال تعذُّر تحديد تطبيق معيّن لاستخدام طاقة مكوّن الجهاز.
• [8.4/A-0-4] يجب أن يتيح مطوّر التطبيق استخدام الطاقة هذا من خلال الأمر adb shell dumpsys batterystats في بيئة سطر الأوامر.

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

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

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

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

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

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

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

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

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

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

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

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

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

2.6.2. البرامج

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

3- البرامج

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

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

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

• [C-0-1] يجب توفير عمليات تنفيذ كاملة، بما في ذلك جميع السلوكيات الموثَّقة ، لأي واجهة برمجة تطبيقات موثَّقة يوفّرها حزمة تطوير البرامج (SDK) لنظام التشغيل Android أو أي واجهة برمجة تطبيقات تم تزيينها بعلامة "‎@SystemApi" في رمز المصدر لنظام التشغيل Android.

• [C-0-2] يجب أن تتوافق/تحافظ على جميع الفئات والأساليب والعناصر المرتبطة التي تم وضع التعليق التوضيحي TestApi عليها ("‎@TestApi").

• [C-0-3] يجب عدم حذف أي واجهات برمجة تطبيقات مُدارة أو تغيير واجهات برمجة التطبيقات أو توقيعاتها، أو الانحراف عن السلوك المُسجَّل، أو تضمين عمليات لا تؤدي إلى أيّ تأثير، إلا في الحالات التي يسمح فيها تحديد التوافق هذا تحديدًا بذلك.

• [C-0-4] يجب أن تظل واجهات برمجة التطبيقات متوفّرة وأن تعمل بطريقة معقولة، حتى في حال حذف بعض ميزات الأجهزة التي يتضمّن Android واجهات برمجة تطبيقات لها. اطّلِع على القسم 7 لمعرفة المتطلبات المحدّدة لهذا السيناريو.

• [C-0-5] يجب عدم السماح للتطبيقات التابعة لجهات خارجية باستخدام واجهات غير متوفرة في حزمة SDK، والتي يتم تحديدها على أنّها طُرق وحقول في حِزم لغة Java التي يتم تضمينها في مسار تحميل البرامج في AOSP، والتي لا تشكّل جزءًا من حزمة SDK العامة. ويشمل ذلك واجهات برمجة التطبيقات التي تم تزيينها بالتعليق التوضيحي @hide وليس باستخدام @SystemAPI، كما هو موضّح في مستندات حزمة تطوير البرامج (SDK)، وكذلك عناصر الفئات الخاصة والخاصة بالحزمة.

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

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

  ومع ذلك، فإنّه:

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

3.1.2. مكتبة Android

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

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

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

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

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

3.2.1. الأذونات

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

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

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

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

المَعلمة	التفاصيل
VERSION.RELEASE	إصدار نظام Android الذي يتم تنفيذه حاليًا بتنسيق يمكن للمستخدمين قراءته يجب أن يحتوي هذا الحقل على إحدى قيم السلاسل المحدّدة في سلاسل الإصدارات المسموح بها لنظام التشغيل Android 12.
VERSION.SDK	إصدار نظام Android الذي يتم تنفيذه حاليًا بتنسيق يمكن لرمز التطبيق التابع لجهة خارجية الوصول إليه بالنسبة إلى Android 12، يجب أن يحتوي هذا الحقل على القيمة الصحيحة 12_INT.
VERSION.SDK_INT	إصدار نظام Android الذي يتم تنفيذه حاليًا بتنسيق يمكن لرمز التطبيق التابع لجهة خارجية الوصول إليه بالنسبة إلى Android 12، يجب أن يحتوي هذا الحقل على القيمة الصحيحة 12_INT.
VERSION.INCREMENTAL	قيمة يختارها مُنفِّذ الجهاز لتحديد الإصدار المحدد من نظام Android الذي يتم تنفيذه حاليًا، بتنسيق يمكن لشخص عادي قراءته يجب عدم إعادة استخدام هذه القيمة في الإصدارات المختلفة المتاحة للمستخدمين النهائيين. أحد استخدامات هذا الحقل المعتادة هي الإشارة إلى رقم الإصدار أو معرّف تغيير التحكّم في المصدر الذي تم استخدامه لإنشاء الإصدار. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII القابل للطباعة المكوّن من 7 بتات وأن تتطابق مع العبارة العادية "^[^ :\/~]+$".
ألعاب ألواح	قيمة يختارها منفذ الجهاز لتحديد المكونات الداخلية المحدّدة التي يستخدمها الجهاز، بتنسيق يمكن لشخص عادي قراءته من أحد الاستخدامات المحتملة لهذا الحقل الإشارة إلى المراجعة المحدّدة للوحة التي توفّر питаниеً للجهاز. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بت ويجب أن تتماثل مع التعبير العادي "^[a-zA-Z0-9_-]+$".
العلامة التجارية	قيمة تعكس اسم العلامة التجارية المرتبط بالجهاز كما هو معروف للمستخدمين النهائيين يجب أن يكون بتنسيق يسهل قراءته ويجب أن يمثّل الشركة المصنّعة للجهاز أو علامة الشركة التجارية التي يتم تحتها التسويق للجهاز. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9_-]+$".
SUPPORTED_ABIS	اسم مجموعة التعليمات (نوع وحدة المعالجة المركزية + اصطلاح ABI) للرمز المبرمَج الأصلي راجِع الفقرة 3.3. توافق واجهة برمجة التطبيقات المدمجة
SUPPORTED_32_BIT_ABIS	اسم مجموعة التعليمات (نوع وحدة المعالجة المركزية + اصطلاح ABI) للرمز المبرمَج الأصلي راجِع الفقرة 3.3. توافق واجهة برمجة التطبيقات المدمجة
SUPPORTED_64_BIT_ABIS	اسم مجموعة التعليمات الثانية (نوع وحدة المعالجة المركزية + اصطلاح ABI) للرمز البرمجي الأصلي راجِع الفقرة 3.3. التوافق مع واجهة برمجة التطبيقات الأساسية
CPU_ABI	اسم مجموعة التعليمات (نوع وحدة المعالجة المركزية + اصطلاح ABI) للرمز المبرمَج الأصلي راجِع الفقرة 3.3. توافق واجهة برمجة التطبيقات المدمجة
CPU_ABI2	اسم مجموعة التعليمات الثانية (نوع وحدة المعالجة المركزية + اصطلاح ABI) للرمز البرمجي الأصلي راجِع الفقرة 3.3. التوافق مع واجهة برمجة التطبيقات الأساسية
الجهاز	قيمة يختارها منفذ الجهاز تحتوي على اسم التطوير أو الاسم الرمزي الذي يحدِّد إعدادات ميزات الجهاز والتصميم الصناعي للجهاز. يجب أن تكون قيمة هذا الحقل قابلة للترميز على أنّها 7 بت ASCII وأن تتطابق مع التعبير العادي “^[a-zA-Z0-9_-]+$”. يجب ألّا يتغيّر اسم الجهاز هذا أثناء فترة استخدام المنتج.
بصمة الإصبع	سلسلة تحدّد هذا الإصدار بشكل فريد يجب أن يكون سهل القراءة إلى حدٍّ معقول. يجب أن يتّبع هذا النموذج: $(BRAND)/$(PRODUCT)/     $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) مثلاً: acme/myproduct/     mydevice:12/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._-]+$”.
الشركة المصنّعة	الاسم التجاري للمصنّع الأصلي للجهاز الذي يُصنِّع المنتج ما مِن متطلبات حول التنسيق المحدّد لهذا الحقل، باستثناء أنّه يجب ألّا يكون فارغًا أو سلسلة فارغة (""). يجب ألّا يتغيّر هذا الحقل خلال مدة توفّر المنتج.
SOC_MANUFACTURER	الاسم التجاري للشركة المصنّعة للمنظومة الأساسية على الرقاقة (SoC) المستخدَمة في المنتج. يجب أن تستخدم الأجهزة التي تحمل الشركة المصنّعة نفسها للنظام على الرقاقة القيمة الثابتة نفسها. يُرجى طلب المتغيّر الصحيح من الشركة المصنّعة لوحدة التحكّم في الشريحة. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات، ويجب أن تتطابق مع التعبير العادي "^([0-9A-Za-z ]+)"، ويجب ألّا تبدأ بمسافة أو تنتهي بها، ويجب ألّا تساوي "غير معروف". ويجب ألّا يتغيّر هذا الحقل خلال فترة استخدام المنتج.
SOC_MODEL	اسم طراز المنظومة الأساسية على الرقاقة (SoC) المستخدَمة في المنتج. يجب أن تستخدم الأجهزة التي تتضمّن طراز SOC نفسه القيمة الثابتة نفسها. يُرجى سؤال الشركة المصنّعة لوحدة التحكّم في الشريحة عن القيمة الثابتة الصحيحة التي يجب استخدامها. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي "^([0-9A-Za-z ._/+-]+)$"، ويجب ألّا تبدأ أو تنتهي بمسافة بيضاء، ويجب ألّا تساوي "غير معروف". يجب ألّا يتغيّر هذا الحقل أثناء فترة استخدام المنتج.
الطراز	قيمة يختارها منفذ الجهاز تحتوي على اسم الجهاز كما يعرفه المستخدم النهائي. يجب أن يكون هذا هو الاسم نفسه الذي يتم بموجبه تسويق الجهاز وبيعه للمستخدمين النهائيين. ما مِن متطلبات تتعلّق بالتنسيق المحدّد لهذا الحقل، باستثناء أنّه يجب ألا يكون فارغًا أو سلسلة فارغة (""). يجب ألا يتغيّر هذا الحقل خلال فترة توفّر المنتج.
المنتج	قيمة يختارها مُنفِّذ الجهاز تحتوي على اسم التطوير أو الاسم الرمزي للمنتج المحدّد (رمز التخزين التعريفي) الذي يجب أن يكون فريدًا ضمن العلامة التجارية نفسها. يجب أن تكون قابلة للقراءة من قِبل البشر، ولكن ليس بالضرورة أن تكون مخصّصة للعرض من قِبل المستخدمين النهائيين. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بت ويجب أن تتطابق مع التعبير العادي "^[a-zA-Z0-9_-]+$". ويجب ألّا يتغيّر اسم المنتج خلال فترة استخدام المنتج.
ODM_SKU	قيمة اختيارية يختارها منفذ الجهاز تحتوي على رمز التخزين التعريفي (SKU) المستخدَم لتتبُّع إعدادات محدّدة للجهاز، مثل أي أجهزة ملحقة مضمّنة مع الجهاز عند بيعه. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي ^([0-9A-Za-z.,_-]+)$.
SERIAL	يجب أن يعرض العنصر القيمة "UNKNOWN".
العلامات	قائمة مفصولة بفواصل بالعلامات التي اختارها مُنفِّذ الجهاز والتي تُميِّز الإصدار بشكلٍ أكبر يجب أن تكون العلامات قابلة للترميز بترميز ASCII المكوّن من 7 بت وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9._-]+"، ويجب أن تتضمن إحدى القيم المقابلة لإعدادات توقيع نظام التشغيل Android الثلاثة النموذجية: مفاتيح الإصدار ومفاتيح المطوّرين ومفاتيح الاختبار.
الوقت	قيمة تمثّل الطابع الزمني لوقت إنشاء الإصدار
النوع	قيمة يختارها مُنفِّذ الجهاز لتحديد إعدادات وقت التشغيل للإصدار يجب أن يحتوي هذا الحقل على إحدى القيم التالية التي تتوافق مع الإعدادات الثلاثة المعتادة لوقت تشغيل Android: user أو userdebug أو eng.
المستخدم	اسم أو رقم تعريف المستخدم (أو المستخدم المبرمَج) الذي أنشأ الإصدار ما مِن متطلبات خاصة بتنسيق هذا الحقل، باستثناء أنّه يجب ألّا يكون فارغًا أو سلسلة فارغة ("").
SECURITY_PATCH	قيمة تشير إلى مستوى تصحيح الأمان لإصدار معيّن يجب أن يشير ذلك إلى أنّ الإصدار ليس معرّضًا بأي شكل من الأشكال لأي من المشاكل الموضّحة في نشرة أمان Android العامة المحدّدة. يجب أن تكون بالتنسيق [YYYY-MM-DD]، وأن تتطابق مع سلسلة محدّدة موثّقة في نشرة أمان Android العامة أو في إشعار أمان Android، على سبيل المثال "‎2015-11-01".
BASE_OS	قيمة تمثّل مَعلمة FINGERPRINT للإصدار الذي هو مطابق لهذا الإصدار باستثناء الرقع المقدَّمة في نشرة الأمان العام لنظام التشغيل Android يجب أن يعرض الإصدار القيمة الصحيحة، وإذا لم يكن هذا الإصدار متوفّرًا، يجب عرض سلسلة فارغة ("").
برنامج تحميل التشغيل	قيمة يختارها منفذ الجهاز لتحديد إصدار bootloader الداخلي المُستخدَم في الجهاز بتنسيق يمكن لشخص عادي قراءته يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9._-]+$".
getRadioVersion()	يجب أن تكون (أو تعرض) قيمة يختارها منفذ الجهاز لتحديد إصدار الراديو/المودم الداخلي المحدّد المستخدَم في الجهاز، بتنسيق يمكن لشخص عادي قراءته. إذا لم يكن الجهاز يحتوي على أي إشارة تردد لاسلكي/مودم داخلي، يجب أن يعرض القيمة NULL. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي “^[a-zA-Z0-9._-,]+$”.
getSerial()‎	يجب أن يكون (أو يعرض) رقمًا تسلسليًا للأجهزة، ويجب أن يكون متاحًا وفريدًا على مستوى الأجهزة التي تحمل الطراز والشركة المصنّعة نفسهما. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي “^[a-zA-Z0-9._-,]+$”.

3.2.3. توافق الغرض

3.2.3.1. نوايا التطبيقات الشائعة

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

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

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

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

3.2.3.2. حلّ النية

• [C-0-1] بما أنّ Android هو نظام أساسي قابل للتوسيع، يجب أن تسمح عمليات تنفيذ الأجهزة بتجاوز كل نمط نية تتم الإشارة إليه في الفقرة 3.2.3.1 ، باستثناء "الإعدادات"، من خلال التطبيقات التابعة لجهات خارجية. يسمح الإصدار الأحدث من Android المفتوح المصدر بذلك تلقائيًا.

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

• [C-0-3] يجب أن توفّر عمليات تنفيذ الأجهزة واجهة مستخدم تتيح للمستخدمين تعديل النشاط التلقائي للنوايا.

• ومع ذلك، قد تقدّم عمليات تنفيذ الأجهزة أنشطة تلقائية لنماذج عناوين URL معيّنة (مثل http://play.google.com) عندما يوفّر النشاط التلقائي سمة أكثر تحديدًا لعنوان URL للبيانات. على سبيل المثال، يكون نمط فلتر الأهداف الذي يحدد معرّف الموارد المنتظم للبيانات "http://www.android.com" أكثر تحديدًا من نمط العمل الأساسي للمتصفّح الذي يخصّ "http://".

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

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

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

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

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

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

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

• [C-2-1] يجب توفير قائمة إعدادات تستدعي android.provider.Telephony.ACTION_CHANGE_DEFAULT intent لعرض مربّع حوار لتغيير تطبيق الرسائل القصيرة التلقائي.

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

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

• [C-2-3] يجب الالتزام بغرض android.telecom.action.CHANGE_PHONE_ACCOUNTS لتوفير إمكانية ضبط ConnectionServices المرتبطة بـ PhoneAccounts، بالإضافة إلى PhoneAccount التلقائي الذي سيستخدمه مقدّم خدمة الاتصالات الهاتفية لإجراء المكالمات الصادرة. يستوفي تطبيق AOSP هذا الشرط من خلال تضمين قائمة "خيارات حسابات الاتصال" ضمن قائمة إعدادات "المكالمات".

• [C-2-4] يجب السماح android.telecom.CallRedirectionService لتطبيق يشغل دور android.app.role.CALL_REDIRECTION.

• [C-2-5] يجب أن توفّر للمستخدم إمكانية اختيار تطبيق يمتلك دور android.app.role.CALL_REDIRECTION.

• [C-2-6] يجب أن يتوافق التطبيق مع نيتي android.intent.action.SENDTO وandroid.intent.action.VIEW وأن يقدّم نشاطًا لإرسال رسائل SMS أو عرضها.

• [C-SR-1] يُنصح بشدة بتنفيذ إجراءات android.intent.action.ANSWER، android.intent.action.CALL، android.intent.action.CALL_BUTTON، android.intent.action.VIEW & android.intent.action.DIAL باستخدام تطبيق اتصال مُحمَّل مسبقًا يمكنه معالجة هذه الإجراءات و توفير الامتثال كما هو موضّح في حزمة تطوير البرامج (SDK).

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

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

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

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

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

• [C-5-1] يجب أن يحترم النشاط ‎‘android.bluetooth.adapter.action.REQUEST_ENABLE’ وعرض نشاط نظام للسماح للمستخدم بتفعيل البلوتوث.
• [C-5-2] يجب الالتزام بغرض ‎‘android.bluetooth.adapter.action.REQUEST_DISCOVERABLE’ وعرض نشاط نظام يطلب وضع "الاكتشاف التلقائي".

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

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

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

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

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

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

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

• [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] يجب أن يتضمّن نشاطًا يعالج هدف ملف APK Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS ، ولكن يجوز تنفيذه كإجراء لا يؤدي إلى أيّ تأثير.

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

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

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

• [C-13-1] يجب أن تلتزم بالهدف android.app.action.ADD_DEVICE_ADMIN لتشغيل واجهة مستخدم لتوجيه المستخدم إلى إضافة مشرف الجهاز إلى النظام (أو السماح له برفضه).

• [C-13-2] يجب أن تلتزم التطبيقات بالطلبات التالية: android.app.action.PROVISION_MANAGED_PROFILE، android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD، android.app.action.SET_NEW_PASSWORD & android.app.action.START_ENCRYPTION ويجب أن تتضمّن نشاطًا لتنفيذ هذه الطلبات على النحو الموضّح في حِزمة تطوير البرامج (SDK) هنا.

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

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

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

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

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

• [C-15-1] يجب أن يتضمّن التطبيق نشاطًا يعالج android.settings.ACTION_USAGE_ACCESS_SETTINGS نمط الطلب، ولكن يجب تنفيذه كإجراء لا يؤدي إلى أيّ تأثير، أي أن يكون له سلوك مماثل لما يحدث عند رفض وصول المستخدم.

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

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

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

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

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

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

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

• يجب أن تتضمّن ميزة توفير خلفيات شاشة وأن تقدّم خيار إعدادات لسماح للمستخدمين بضبط خلفيات الشاشة استجابةً لintent 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 Open Source Project.

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

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

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

• [C-0-1] يجب أن يكون متوافقًا مع واجهة برمجة التطبيقات لنظام التشغيل Android NDK محدّدة واحدة أو أكثر.
• [C-0-2] يجب أن يتضمّن التطبيق إمكانية تشغيل الرمز في البيئة المُدارة لبدء تنفيذ رمز أصلي باستخدام بنية Java Native Interface (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 (دعم الصوت الأصلي في AAudio)
  • libamidi.so (لإتاحة استخدام تنسيق MIDI الأصلي، إذا تمّت المطالبة بالميزة android.software.midi كما هو موضّح في القسم 5.9)
  • libandroid.so (لتوفير وظائف الأنشطة الأصلية في Android)
  • libc (مكتبة C)
  • libcamera2ndk.so
  • libdl (الرابط الديناميكي)
  • libEGL.so (إدارة سطح OpenGL الأصلي)
  • libGLESv1_CM.so (OpenGL ES 1.x)
  • libGLESv2.so (OpenGL ES 2.0)
  • libGLESv3.so (OpenGL ES 3.x)
  • libicui18n.so
  • libicuuc.so
  • libjnigraphics.so
  • liblog (تسجيل Android)
  • libmediandk.so (تتيح استخدام واجهات برمجة التطبيقات الأصلية للوسائط)
  • libm (مكتبة الرياضيات)
  • libneuralnetworks.so (Neural Networks API)
  • libOpenMAXAL.so (لتوفير دعم OpenMAX AL 1.0.1)
  • libOpenSLES.so (دعم الصوت في OpenSL ES 1.0.1)
  • libRS.so
  • libstdc++ (الحد الأدنى من الدعم لـ C++)
  • libvulkan.so (Vulkan)
  • libz (ضغط Zlib)
  • واجهة JNI

• [C-0-8] يجب عدم إضافة أو إزالة الدوال العامة للمكتبات الأصلية المُدرَجة أعلاه.

• [C-0-9] يجب إدراج مكتبات إضافية غير تابعة لمشروع AOSP ومفتوحة مباشرةً أمام التطبيقات التابعة لجهات خارجية في /vendor/etc/public.libraries.txt.

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

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

• [C-0-12] يجب تصدير رموز الدوالّ الأساسية لرمودفدالّ Vulkan 1.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 قد توفّر دعمًا لمزيد من IDE.

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

إذا أبلغت عمليات تنفيذ الأجهزة عن توفّر ملف ABI الخاص بنظام التشغيل armeabi، يتم تنفيذ ما يلي:

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

إذا أبلغت عمليات تنفيذ الأجهزة عن توافقها مع ABI‏ armeabi-v7a، بالنسبة إلى التطبيقات التي تستخدم ABI هذا، يتم تنفيذ ما يلي:

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

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

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

  • تعليمات SWP وSWPB
  • عمليات الحواجز CP15ISB وCP15DSB وCP15DMB

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

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

3.4.1. توافق WebView

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

• [C-1-1] يجب الإبلاغ عن android.software.webview.
• [C-1-2] يجب استخدام إصدار Chromium من مشروع Android Open Source Project في الإصدار 12 من Android لتنفيذ واجهة برمجة التطبيقات 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) نفسها قيمة android.os.Build.ID.
  • يجب أن تكون قيمة السلسلة $(CHROMIUM_VER) هي إصدار Chromium في المشروع المفتوح المصدر لنظام التشغيل Android.
  • قد تحذف عمليات تنفيذ الأجهزة كلمة Mobile في سلسلة وكيل المستخدم.

• يجب أن يتضمّن مكوّن WebView ميزات HTML5 بقدرٍ كبيرٍ ممكن، وإذا كان يتيح استخدام الميزة، يجب أن يكون متوافقًا مع مواصفات HTML5.

• [C-1-4] يجب عرض المحتوى المقدَّم أو محتوى عنوان URL البعيد في عملية مختلفة عن التطبيق الذي ينشئ WebView. على وجه التحديد، يجب أن تحصل عملية عرض الصور المنفصلة على امتيازات أقل، وأن يتم تشغيلها باستخدام معرّف مستخدم منفصل، وألا تتمكن من الوصول إلى دليل بيانات التطبيق، وألا تتمكن من الوصول إلى الشبكة مباشرةً، وألا تتمكن من الوصول إلا إلى الحد الأدنى من خدمات النظام المطلوبة من خلال Binder. يستوفي تطبيق WebView المُطبَّق على AOSP هذا الشرط.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.7 التوافق مع بيئة التشغيل

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

• [C-0-1] يجب أن يكون متوافقًا مع تنسيق Dalvik Executable (DEX) الكامل ومواصفات ودلالات رمز Dalvik البرمجي.

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

• يجب استخدام Android RunTime ‏ (ART)، وهو التنفيذ المرجعي لتنسيق Dalvik القابل للتنفيذ، ونظام إدارة الحِزم المرجعي للتنفيذ.

• يجب إجراء اختبارات التداخل في أوضاع تنفيذ مختلفة والتصاميم المستهدفة لضمان ثبات وقت التشغيل. راجِع JFuzz وDexFuzz على الموقع الإلكتروني لمشروع Android Open Source Project.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

يقدّم الإصدار 11 من Android ميزة إشعارات المحادثات، وهي إشعارات تستخدِم MessagingStyle وتوفّر معرّف اختصار الأشخاص منشورًا.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.3.3. عدم الإزعاج

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

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

3.8.4. واجهات برمجة تطبيقات Assist

يتضمّن Android Assist APIs للسماح للتطبيقات باختيار مقدار المعلومات التي تتم مشاركتها مع "مساعد Google" على الجهاز.

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

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

3.8.5. التنبيهات والرسائل المنبثقة

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

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

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

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

3.8.6. المظاهر

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

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

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

• [C-1-1] يجب عدم تغيير أي من سمات مظهر Holo المعروضة للتطبيقات.
• [C-1-2] يجب أن تكون متوافقة مع عائلة المظاهر "المادية"، ويجب ألّا تغيّر أيًا من سمات المظهر المادي أو مواد العرض المعروضة للتطبيقات.
• [C-1-3] يجب ضبط عائلة الخطوط "sans-serif" على الإصدار 2.x من Roboto للغات التي يتوافق معها Roboto، أو توفير عنصر تحكم للمستخدم لتغيير الخط المستخدَم لعائلة الخطوط "sans-serif" إلى الإصدار 2.x من Roboto للغات التي يتوافق معها Roboto.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

يتيح نظام Android استخدام ميزة إدارة الإدخال واستخدام برامج تحرير طرق الإدخال التابعة لجهات خارجية.

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

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

3.8.10. عناصر التحكّم في الوسائط على شاشة القفل

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

3.8.11. شاشات الاستراحة (المعروفة سابقًا باسم "الأحلام")

راجِع القسم 3.2.3.5 للاطّلاع على الإعدادات المقصودة لضبط حِزم حفظ الشاشة.

3.8.12. الموقع الجغرافي

إذا كانت عمليات تنفيذ الأجهزة تتضمّن أداة استشعار للأجهزة (مثل نظام تحديد المواقع العالمي (GPS)) قادرة على تقديم إحداثيات الموقع الجغرافي،

• [C-1-2] يجب عرض الحالة الحالية للموقع الجغرافي في قائمة "الموقع الجغرافي" ضمن "الإعدادات".
• [C-1-3] يجب عدم عرض أوضاع الموقع الجغرافي في قائمة "الموقع الجغرافي" ضمن "الإعدادات".

3.8.13. يونيكود والخط

يتيح نظام Android استخدام أحرف الرموز التعبيرية المحدّدة في Unicode 10.0.

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

• [C-1-1] يجب أن يكون النظام قادرًا على عرض أحرف الرموز التعبيرية هذه برمز مميّز بالألوان.
• [C-1-2] يجب أن تتضمّن ميزة الدعم ما يلي:
  • خط Roboto 2 بدرجات مختلفة من السماكة، مثل sans-serif-thin وsans-serif-light وsans-serif-medium وsans-serif-black وsans-serif-condensed وsans-serif-condensed-light للغات المتوفّرة على الجهاز
  • تغطية كاملة لـ Unicode 7.0 للغة اللاتينية واليونانية والسيريلية، بما في ذلك النطاقات A وB وC وD الموسّعة للغة اللاتينية وجميع الأحرف الرسومية في مجموعة رموز العملة في Unicode 7.0
• [C-1-3] يجب عدم إزالة ملف NotoColorEmoji.tff أو تعديله في صورة النظام. (يُسمح بإضافة خط رموز تعبيرية جديد لتجاهل الرموز التعبيرية فيملف ‎ NotoColorEmoji.tff)
• يجب أن تتيح استخدام رموز الإيموجي التي تُظهر درجات لون البشرة المختلفة وأفراد العائلة المتنوعة كما هو موضّح في التقرير الفني 51 حول يونيكود.

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

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

يتيح نظام التشغيل Android عرض خطوط ميانمار. تستخدم ميانمار عدة خطوط غير متوافقة مع Unicode، وتُعرف هذه الخطوط عادةً باسم "Zawgyi"، وهي مخصّصة لعرض محتوى ملفّات ميانمار.

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

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

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

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

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

• [C-3-3] يجب أن تتيح استخدام نسب عرض إلى ارتفاع أكبر من أو تساوي 1:2.39 وأصغر من أو تساوي 2.39:1، كما هو محدّد في نشاط وضع الصورة داخل الصورة من خلال واجهة برمجة التطبيقات setAspectRatio().

• [C-3-4] يجب استخدام KeyEvent.KEYCODE_WINDOW للتحكّم في نافذة الصورة في الصورة. وفي حال عدم تنفيذ وضع الصورة في الصورة، يجب أن يكون المفتاح متاحًا للنشاط الذي يظهر في المقدّمة.

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

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

  • بالنسبة إلى الأجهزة التي تم ضبط ‎Configuration.uiMode فيها على قيمة غير UI_MODE_TYPE_TELEVISION ، يجب أن يكون الحد الأدنى للعرض والارتفاع 108 dp.
  • بالنسبة إلى الأجهزة التي تم ضبط Configuration.uiMode فيها على UI_MODE_TYPE_TELEVISION ، يجب أن يكون الحد الأدنى للعرض 240 بكسل مستقل الكثافة والحد الأدنى للارتفاع 135 بكسل مستقل الكثافة.

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

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

إذا كانت عمليات تنفيذ الأجهزة تنفِّذ المجموعة الكاملة من سياسات إدارة الجهاز المحدّدة في مستندات حزمة تطوير البرامج (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] يجب أن يتيح التطبيق تسجيل "وحدة التحكّم بسياسة الجهاز" (DPC) كأحد تطبيقات "مالك الجهاز" على النحو الموضّح أدناه:
  • عندما لا يتم ضبط بيانات المستخدمين في عملية تنفيذ الجهاز بعد، يتم تنفيذ ما يلي:
    • [C-1-5] يجب تسجيل تطبيق DPC كتطبيق "مالك الجهاز" إذا كان الجهاز يعلن عن توافقه مع تقنية "الاتصال القصير المدى" (NFC) من خلال علامة الميزة android.hardware.nfc ويتلقّى رسالة NFC تحتوي على سجلّ بنوع MIME‏ MIME_TYPE_PROVISIONING_NFC.
    • [C-1-8] يجب إرسال ACTION_GET_PROVISIONING_MODE intent بعد بدء عملية إعداد مالك الجهاز حتى تتمكّن DPC من اختيار ما إذا كان سيتم ضبطه على مالك جهاز أو ملف شخصي مالك ما لم يكن من الممكن تحديد من السياق أنّه لا يوجد سوى خيار واحد صالح (مثل عملية الإعداد المستندة إلى NFC حيث لا تتوفّر عملية إعداد ملف شخصي مالك).
    • [C-1-9] يجب إرسال ACTION_ADMIN_POLICY_COMPLIANCE بقصد إلى تطبيق "مالك الجهاز" في حال تم إنشاء مالك جهاز أثناء عملية الإعداد بغض النظر عن طريقة الإعداد المستخدَمة. يجب ألا يتمكّن المستخدم من المتابعة في معالج الإعداد إلى أن ينتهي تطبيق "مالك الجهاز".
  • عندما يتضمّن تطبيق الجهاز بيانات المستخدمين، يتم إجراء ما يلي:
    • [C-1-7] يجب عدم تسجيل أي تطبيق DPC كتطبيق "مالك الجهاز" بعد الآن.
• [C-1-2] يجب أن يطلب التطبيق اتخاذ إجراء إيجابي قبل عملية الإعداد أو أثناءها للموافقة على ضبط التطبيق كـ "مالك الجهاز". يمكن الحصول على الموافقة من خلال إجراء يتّخذه المستخدم أو من خلال بعض الوسائل الآلية، ولكن يجب عرض إشعار الإفصاح المناسب (كما هو مذكور في AOSP) قبل بدء عملية تجهيز مالك الجهاز. بالإضافة إلى ذلك، يجب ألا تؤدي آلية الموافقة الآلية لمالكي الأجهزة التي تستخدمها (المؤسسات) لتوفير مالك الجهاز إلى التداخل مع تجربة الاستخدام العادي للأجهزة غير المخصّصة للمؤسسات.
• [C-1-3] يجب عدم تضمين الموافقة في الرمز البرمجي الثابت أو منع استخدام تطبيقات مالك الجهاز الأخرى.

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

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

3.9.1.2 توفير الملف الشخصي المُدار

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

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

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

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

  • رمز متسق أو عنصر تحكم آخر للمستخدم (مثل رمز معلومات AOSP في المصدر المفتوح) للإشارة إلى حظر إعداد معيّن من قِبل أحد مشرفي الجهاز
  • رسالة شرح موجزة، كما قدّمها مشرف الجهاز من خلال setShortSupportMessage
  • رمز تطبيق "مركز التحكّم في البيانات"

• [C-1-4] يجب تشغيل معالِج طلب ACTION_PROVISIONING_SUCCESSFUL في الملف الشخصي للعمل إذا تم إنشاء مالك ملف شخصي عند بدء عملية الإعداد من خلال طلب android.app.action.PROVISION_MANAGED_PROFILE ونفَّذ موفِّر الخدمات الجوّالة للمؤسسات المعالِج.

• [C-1-5] يجب إرسال بث ACTION_PROFILE_PROVISIONING_COMPLETE إلى DPC الخاص بملف العمل عند بدء عملية الإعداد من خلال android.app.action.PROVISION_MANAGED_PROFILE intent.

• [C-1-6] يجب إرسال ACTION_GET_PROVISIONING_MODE intent بعد بدء عملية إعداد مالك الملف الشخصي حتى تتمكّن DPC app من اختيار ما إذا كان يريد أن يصبح مالك جهاز أو مالك ملف شخصي، باستثناء الحالات التي يتم فيها بدء عملية الإعداد من خلال 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 بثًا إلى وحدة التحكّم في حدود الحساب (DPC) للملف الشخصي عند إنشاء مالك ملف شخصي، بغض النظر عن طريقة الإعداد المستخدَمة.

3.9.2 توافق الملف الشخصي المُدار

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

• [C-1-1] يجب أن تتيح التطبيقات إدارة الملفات التجارية من خلال android.app.admin.DevicePolicyManager واجهات برمجة التطبيقات.
• [C-1-2] يجب السماح بإنشاء ملف شخصي مُدار واحد فقط.
• [C-1-3] يجب استخدام شارة رمز (مثل شارة العمل في AOSP) لتمثيل التطبيقات المصغّرة والتطبيقات المُدارة وعناصر واجهة المستخدم الأخرى التي تحمل شارة، مثل "التطبيقات المستخدَمة مؤخرًا" و"الإشعارات".
• [C-1-4] يجب عرض رمز إشعار (يشبه شارة العمل في AOSP) للإشارة إلى وقت استخدام المستخدم لتطبيق ملف شخصي مُدار.
• [C-1-6] في حال توفّر ملف شخصي مُدار، يجب عرض عنصر تحكم مرئي في "أداة اختيار" الإجراء للسماح للمستخدم بإعادة توجيه الإجراء من الملف الشخصي المُدار إلى المستخدم الأساسي أو العكس، إذا فعّل ذلك "مُشغِّل سياسة الجهاز".
• [C-1-7] في حال توفّر ملف شخصي مُدار، يجب عرض ميزات الاستخدام التالية لكل من المستخدم الأساسي والملف الشخصي المُدار:
  • احتساب استخدام البطارية والموقع الجغرافي وبيانات الجوّال ومساحة التخزين بشكل منفصل للمستخدم الأساسي والملف الشخصي المُدار
  • إدارة مستقلة لتطبيقات VPN المثبَّتة في الملف الشخصي الأساسي للمستخدم أو الملف الشخصي المُدار
  • إدارة مستقلة للتطبيقات المثبَّتة في الملف الشخصي الأساسي أو الملف الشخصي المُدار
  • إدارة مستقلة للحسابات ضمن الملف الشخصي للمستخدم الأساسي أو الملف الشخصي المُدار
• [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 Open Source.
  • سياسات كلمات المرور في DPC: يجب أن تنطبق فقط على بيانات اعتماد شاشة القفل للملف الشخصي المُدار ما لم يتم استدعاء مثيل DevicePolicyManager الذي تم إرجاعه من getParentProfileInstance.
• عند عرض جهات الاتصال من الملف الشخصي المُدار في سجلّ المكالمات المثبَّت مسبقًا وواجهة المستخدم أثناء المكالمة والإشعارات المتعلّقة بالمكالمات الجارية والمُفوَّتة وتطبيقات جهات الاتصال والرسائل، يجب وضع الشارة نفسها المستخدَمة للإشارة إلى تطبيقات الملف الشخصي المُدار.

3.9.3 دعم المستخدِم المُدار

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

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

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

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

3.10. تسهيل الاستخدام

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [C-1-1] يجب الإفصاح عن ميزة المنصة android.software.live_tv.
• [C-1-2] يجب أن يكون متوافقًا مع جميع واجهات برمجة التطبيقات لتنسيق TIF، بحيث يمكن تثبيت تطبيق يستخدم هذه الواجهات والخدمات التابعة لجهات خارجية المستندة إلى تنسيق 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] يجب ألّا تتفاعل التطبيقات الفورية مع التطبيقات المثبّتة من خلال المهام الضمنية ما لم يكن أحد الشروط التالية صحيحًا:
  • يتم عرض فلتر نمط الأهداف للمكوّن ويتضمّن CATEGORY_BROWSABLE.
  • الإجراء هو أحد الإجراءات التالية: ACTION_SEND أو ACTION_SENDTO أو ACTION_SEND_MULTIPLE
  • يتم عرض الهدف بشكل صريح باستخدام android:visibleToInstantApps
• [C-1-3] يجب ألّا تتفاعل التطبيقات الفورية بشكل صريح مع التطبيقات المثبّتة ما لم يتم عرض العنصر باستخدام android:visibleToInstantApps.
• [C-1-4] يجب ألّا تظهر تفاصيل عن التطبيقات الفورية على الجهاز للتطبيقات المثبّتة ما لم يتصل التطبيق الفوري صراحةً بالتطبيق المثبّت.

• يجب أن توفّر عمليات التنفيذ على الأجهزة ميزات الاستخدام التالية للمستخدمين من أجل التفاعل مع التطبيقات الفورية. يستوفي AOSP المتطلبات من خلال واجهة المستخدم و"الإعدادات" و"المشغِّل" التلقائيَين للنظام. عمليات التنفيذ على الأجهزة:

  • [C-1-5] يجب أن يوفّر التطبيق ميزة للمستخدم لعرض التطبيقات الفورية وحذفها التي تم تخزينها مؤقتًا على الجهاز لكل حزمة تطبيق فردية.
  • [C-1-6] يجب أن يقدّم التطبيق إشعارًا دائمًا للمستخدم يمكنه تصغيره أثناء تشغيل تطبيق فوري في المقدّمة. يجب أن يتضمّن إعلام المستخدمين هذا أنّ التطبيقات الفورية لا تتطلّب التثبيت وأن يقدّم عنصر تحكم يوجّه المستخدم إلى شاشة معلومات التطبيق في الإعدادات. بالنسبة إلى التطبيقات الفورية التي يتم تشغيلها من خلال نوايا الويب، كما هو الحال في التطبيقات التي يتم تحديدها باستخدام نية تم ضبط الإجراء فيها على Intent.ACTION_VIEW باستخدام مخطّط "http" أو "https"، يجب أن تسمح ميزة إضافية متاحة للمستخدمين بعدم تشغيل التطبيق الفوري و تشغيل الرابط المرتبط باستخدام متصفّح الويب الذي تم ضبطه، إذا كان متصفّحًا متاحًا على الجهاز.
  • [C-1-7] يجب السماح بالوصول إلى التطبيقات الفورية التي يتم تشغيلها من خلال ميزة "التطبيقات المستخدَمة مؤخرًا" إذا كانت ميزة "التطبيقات المستخدَمة مؤخرًا" متاحة على الجهاز.

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

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

إذا لم تُعلِن عمليات تنفيذ الميزات على الأجهزة عن الميزات FEATURE_CANT_SAVE_STATE، يحدث ما يلي:

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

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

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

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

الحساب المحلي التلقائي: حساب لجهات الاتصال الأوّلية التي يتم تخزينها فقط على الجهاز وغير مرتبطة بحساب في AccountManager، ويتم إنشاؤه باستخدام قيم null للعمودين ACCOUNT_NAME، و ACCOUNT_TYPE.

حساب محلي مخصّص: حساب للجهات التي لم تتم معالجتها والتي يتم تخزينها فقط على الجهاز وغير مرتبطة بحساب في AccountManager، ويتم إنشاؤها باستخدام قيمة واحدة على الأقل غير صفرية للعمودين ACCOUNT_NAME و ACCOUNT_TYPE.

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

• [C-SR-1] يُنصح بشدة بعدم إنشاء حسابات محلية مخصّصة.

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

• [C-1-1] يجب أن يتم إرجاع ACCOUNT_NAME، من الحساب المحلي المخصّص من قِبل ContactsContract.RawContacts.getLocalAccountName
• [C-1-2] يجب أن يتم إرجاع ACCOUNT_TYPE، من الحساب المحلي المخصّص من قِبل ContactsContract.RawContacts.getLocalAccountType
• [C-1-3] يجب إدراج جهات الاتصال الأوّلية التي تُدرجها تطبيقات تابعة لجهات خارجية باستخدام الحساب المحلي التلقائي (أي من خلال ضبط قيم فارغة لملفَّي ACCOUNT_NAME وACCOUNT_TYPE) في الحساب المحلي المخصّص .
• [C-1-4] يجب عدم إزالة جهات الاتصال الأوّلية التي تم إدراجها في الحساب المحلي المخصّص عند إضافة حسابات أو إزالتها.
• [C-1-5] يجب أن تؤدي عمليات الحذف التي يتم إجراؤها على الحساب المحلي المخصّص إلى محو جهات الاتصال الأوّلية على الفور (كما لو تم ضبط المَعلمة CALLER_IS_SYNCADAPTER على true)، حتى إذا تم ضبط المَعلمة CALLER\_IS\_SYNCADAPTER على false أو لم يتم تحديدها.

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

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

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

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

• [C-0-2] يجب أن تتيح عملية التحقّق من ملفات "‎.apk" باستخدام الإصدار 3 من مخطّط توقيع حِزم APK والإصدار 2 من مخطّط توقيع حِزم APK وتوقيع JAR.
• [C-0-3] يجب عدم توسيع تنسيقات ملف ‎.apk أو بيان Android أو الرمز البرمجي لنظام Dalvik أو الرمز البرمجي لـ RenderScript بطريقة تمنع تثبيت هذه الملفات وتشغيلها بشكل صحيح على الأجهزة المتوافقة الأخرى.

• [C-0-4] يجب عدم السماح للتطبيقات غير "مُثبِّت الحِزمة" الحالي بإلغاء تثبيت التطبيق بصمت بدون أي تأكيد من المستخدم، كما هو موضّح في حزمة تطوير البرامج (SDK) لإذن DELETE_PACKAGE. الاستثناءات الوحيدة هي تطبيق مدقّق حِزم النظام الذي يتعامل مع PACKAGE_NEEDS_VERIFICATION intent وتطبيق مدير مساحة التخزين الذي يتعامل مع ACTION_MANAGE_STORAGE intent.

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

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 (الترميز المحسّن للصوت بترميز متقدّم)
• ‫[C-1-4] ‫AAC ELD (الترميز المتقدّم لصوت AAC بوقت استجابة منخفض)
• [C-1-11] ‫xHE-AAC (ملف الإصدار الموسّع من HE AAC وفقًا لمعيار ISO/IEC 23003-3، والذي يتضمّن الملف الأساسي USAC وملف التحكّم في النطاق الديناميكي وفقًا لمعيار 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، يجب أن يكون ما يلي متوافقًا:

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

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

• [C-3-1] يجب تفسير البيانات الوصفية لمستوى الصوت وDRC وتطبيقها وفقًا لملف تعريف التحكّم في النطاق الديناميكي MPEG-D DRC، المستوى 1.
• [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

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

التنسيق/برنامج الترميز	التفاصيل	أنواع الملفات/تنسيقات الحاويات المتوافقة
الملف الشخصي لبرنامج الترميز المتقدّم للصوت (AAC) في MPEG-4 (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 الملف الشخصي (الترميز المحسّن للصوت بكفاءة عالية)	إتاحة محتوى صوت أحادي/استيريو/5.0/5.1 بمعدّلات قياسية للبيانات في الملف الصوتي من 16 إلى 48 كيلوهرتز	3GPP (‎.3gp) ‫MPEG-4 (‎.mp4 و‎.m4a)
الترميز المتقدّم للصوت بوقت استجابة منخفض (AAC ELD)	إتاحة المحتوى الأحادي/الإستيريو بمعدّلات بيانات عادية في الملف الصوتي تتراوح بين 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 كيلوبت في الثانية (معدل نقل بيانات ثابت) أو بمعدّل نقل بيانات متغيّر (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)
Vorbis		Ogg (‎.ogg) ‫MPEG-4 (‎.mp4 و‎.m4a، فك التشفير فقط) Matroska (‎.mkv) Webm ‏(‎.webm)
PCM/WAVE	يجب أن يتيح برنامج ترميز PCM تنسيق PCM الخطي بترميز 16 بت وتنسيق PCM العائم بترميز 16 بت. يجب أن يتيح مستخرج WAVE ترميز PCM الخطي بسعة 16 بت و24 بت و32 بت وتنسيق PCM المتغير بسعة 32 بت (بمعدلات تصل إلى الحد الأقصى للأجهزة). يجب أن تكون معدّلات أخذ العينات متوافقة من 8 كيلوهرتز إلى 192 كيلوهرتز.	WAVE (‎.wav)
Opus	فك التشفير: يتيح الجهاز فك تشفير المحتوى الأحادي الصوت والصوت الاستيريو وصوت 5.0 و5.1 بمعدّلات أخذ العينات 8000 و12000 و16000 و24000 و48000 هرتز. التشفير: يتيح الجهاز تشفير المحتوى الأحادي الصوت والصوت الاستيريو بمعدّلات أخذ العينات 8000 و12000 و16000 و24000 و48000 هرتز.	Ogg (‎.ogg) ‫MPEG-4 (‎.mp4 و‎.m4a، فك التشفير فقط) Matroska (‎.mkv) Webm ‏(‎.webm)

5.1.4. ترميز الصور

يمكنك الاطّلاع على مزيد من التفاصيل في 5.1.6. تفاصيل برامج ترميز الصور

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

• ‫[C-0-1] JPEG
• ‫[C-0-2] ملف بتنسيق PNG
• ‫[C-0-3] WebP

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

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

• [C-1-1] يجب أن يكون الجهاز متوافقًا مع فك ترميز صور HEIF (HEIC).

برامج ترميز الصور المتوافقة مع تنسيقات عالية بعمق البت (أكثر من 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.

• [SR-1] يُنصح بشدة بتوفّر تنسيق اللون RGB888 لوضع Surface الإدخال.

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

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

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

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

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

• [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). ننصح بشدة باستخدام كليهما.

• [SR-1] يُنصح بشدة بأن تتيح برامج ترميز الفيديو وفك ترميزه استخدام أحد التنسيقات التالية على الأقل: تنسيق YUV420 8:8:8 المسطح أو شبه المسطح المحسَّن للأجهزة (YV12 أو NV12 أو NV21 أو تنسيق محسَّن مكافئ من المورّد).

• [C-1-5] يجب أن تتيح برامج فك ترميز الفيديو التي تتيح تنسيقًا بدرجة عمق بت عالية (9 بت أو أكثر لكل قناة) إخراج تنسيق مكافئ بدقة 8 بت إذا طلبه التطبيق. يجب أن يظهر ذلك من خلال إتاحة تنسيق ألوان YUV420 8:8:8 عبر android.media.MediaCodecInfo.

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

• [C-2-1] يجب أن يكون متوافقًا مع تحليل البيانات الوصفية الثابتة ذات تنسيق HDR ومعالجتها.

إذا كانت عمليات تنفيذ الأجهزة تعلن عن توفّر ميزة إعادة التحميل أثناء التشغيل من خلال FEATURE_IntraRefresh في فئة MediaCodecInfo.CodecCapabilities ، يجب استيفاء الشروط التالية:

• [C-3-1] يجب أن تتيح فترات التحديث في النطاق من 10 إلى 60 لقطة و تعمل بدقة في غضون% 20 من فترة التحديث التي تم ضبطها.

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

• [C-4-1] يجب ضبط الإعداد التلقائي على تنسيق الألوان المحسَّن لشاشة الجهاز في حال الضبط باستخدام إخراج Surface.
• [C-4-2] يجب أن يكون تنسيق اللون التلقائي هو YUV420 8:8:8 المحسَّن لقراءة وحدة المعالجة المركزية (CPU) في حال ضبطه على عدم استخدام إخراج Surface.

5.1.8. قائمة برامج ترميز الفيديو

التنسيق/برنامج الترميز	التفاصيل	أنواع الملفات/تنسيقات الحاويات المتوافقة
‫H.263		3GPP (‎.3gp) ‫MPEG-4 (‎.mp4) Matroska (‎.mkv، فك التشفير فقط)
‫H.264 AVC	راجِع الفقرة 5.2 و5.3 للاطّلاع على التفاصيل.	3GPP (‎.3gp) ‫MPEG-4 (‎.mp4) ‫MPEG-2 TS (بتنسيق ‎.ts، لا يمكن التقديم أو الإيقاف) Matroska (‎.mkv، فك التشفير فقط)
‫H.265 HEVC	راجِع الفقرة 5.3 لمعرفة التفاصيل.	‫MPEG-4 (‎.mp4) Matroska (‎.mkv، فك التشفير فقط)
MPEG-2	الجودة الرئيسية	‫MPEG2-TS (‎.ts، لا يمكن التقديم أو الإيقاف) ‫MPEG-4 (‎.mp4، فك التشفير فقط) Matroska (‎.mkv، فك التشفير فقط)
MPEG-4 SP		3GPP (‎.3gp) ‫MPEG-4 (‎.mp4) Matroska (‎.mkv، فك التشفير فقط)
VP8	راجِع الفقرة 5.2 و5.3 للاطّلاع على التفاصيل.	WebM (‎.webm) Matroska (‎.mkv)
‫VP9	راجِع الفقرة 5.3 لمعرفة التفاصيل.	WebM (‎.webm) Matroska (‎.mkv)

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

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

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

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

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

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

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

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

• [C-3-1] يجب أن يتضمّن البرنامج برنامج ترميز Codec 2.0 المقابل من مشروع Android Open Source Project (إذا كان متاحًا) لكل تنسيق وسائط ونوعها (برنامج ترميز أو فك ترميز) متوافق مع الجهاز.
• [C-3-2] يجب أن تتضمّن برامج الترميز 2.0 برامج الترميز البرمجية في عملية الترميز البرمجي كما هو موضّح في مشروع Android Open Source Project لكي يصبح من الممكن منح إذن الوصول إلى برامج الترميز البرمجية بشكل أكثر تقييدًا.
• [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 ويجب أن تتّبع أسماءها إرشادات تسمية Codec 2.0 لنظام التشغيل Android.
• [C-1-4] برامج الترميز التي تحمل أسماء تبدأ بـ "OMX.google." أو "c2.android." يجب عدم تصنيفها على أنّها من المورّدين أو مُسرَّعة بالأجهزة.
• [C-1-5] يجب عدم تحديد برامج الترميز التي تعمل في عملية ترميز (للمورّد أو النظام) والتي يمكنها الوصول إلى برامج تشغيل الأجهزة غير أدوات تخصيص الذاكرة وربطها على أنّها برامج فقط.
• [C-1-6] يجب تصنيف برامج الترميز التي لا تتوفّر في مشروع Android Open Source Project أو التي لا تستند إلى رمز المصدر في هذا المشروع على أنّها برامج تابعة لمورّد.
• [C-1-7] يجب أن يتم تصنيف برامج الترميز التي تستخدم ميزة "تسريع الأجهزة" على أنّها مسرَّعة على الأجهزة.
• [C-1-8] يجب ألّا تكون أسماء برامج الترميز مضلِّلة. على سبيل المثال، يجب أن تتيح برامج الترميز المُسمّاة "برامج فك الترميز" فك الترميز، ويجب أن تتيح تلك المُسمّاة "برامج الترميز" التشفير. يجب أن تكون برامج الترميز التي تحمل أسماء تحتوي على تنسيقات الوسائط متوافقة مع هذين التنسيقَين.

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

• [C-2-1] يجب أن تنشر جميع برامج ترميز الفيديو بيانات معدل عرض اللقطات الذي يمكن تحقيقه للأحجام التالية إذا كانت برامج الترميز متوافقة معها:

	الدقة العادية (جودة منخفضة)	الدقة العادية (جودة عالية)	دقة عالية - 720p	دقة عالية - 1080p	دقة فائقة
دقة الفيديو	‫176 × 144 بكسل (H263 وMPEG2 وMPEG4) ‫352 × 288 بكسل (برنامج ترميز MPEG4 وH263 وMPEG2) ‫320 × 180 بكسل (VP8 وVP8) ‫320 × 240 بكسل (غير ذلك)	‫704 × 576 بكسل (H263) ‫640 × 360 بكسل (VP8 وVP9) ‫640 × 480 بكسل (برنامج ترميز MPEG4) ‫‎720 × 480 بكسل (غير ذلك)	‫‎1408 × 1152 بكسل (H263) ‫‎1280 × 720 بكسل (غير ذلك)	‫‎1920 × 1080 بكسل (بتنسيق آخر غير MPEG4)	‫3840 × 2160 بكسل (HEVC وVP9)

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

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

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

• يجب ألا تزيد سرعة نقل البيانات عن معدّل نقل البيانات بنسبة تزيد عن% 15 على مدار نافذتَين متتاليتَين بين فواصل اللقطات الداخلية (اللقطات I).
• يجب ألا تزيد عن معدّل نقل البيانات بنسبة% 100 على مدار فترة زمنية متحركة تبلغ ثانية واحدة.

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

• [C-1-1] يجب أن تتضمّن إتاحة استخدام أحد برامج ترميز الفيديو VP8 أو H.264 على الأقل، وأن تكون متاحة للتطبيقات التابعة لجهات خارجية.
• يجب أن يكون متوافقًا مع برنامجَي ترميز الفيديو VP8 وH.264، وأن يكون متاحًا للتطبيقات التابعة لجهات خارجية.

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

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

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

• يجب أن تتيح معدلات نقل بيانات قابلة للضبط ديناميكيًا لبرنامج الترميز المتوافق.

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

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

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

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

5.2.1. ‫H.263

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

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

5.2.2. H.264

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

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

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

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

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

5.2.3. VP8

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

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

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

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

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

5.2.4. ‫VP9

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

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

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

إذا كانت عمليات تنفيذ الأجهزة تدّعي أنّها متوافقة مع الملف الشخصي 2 أو الملف الشخصي 3 من خلال Media APIs:

• إنّ إتاحة التنسيق 12 بت اختيارية.

5.2.5. ‫H.265

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

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

	دقة عادية	دقة عالية - 720p	دقة عالية - 1080p	دقة فائقة
دقة الفيديو	‫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 الواردة في جدول التوافق التالي.

	الدقة العادية (جودة منخفضة)	الدقة العادية (جودة عالية)	دقة عالية - 720p	دقة عالية - 1080p
دقة الفيديو	‫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 وUHD على الأقل.

	الدقة العادية (جودة منخفضة)	الدقة العادية (جودة عالية)	دقة عالية - 720p	دقة عالية - 1080p	دقة فائقة
دقة الفيديو	‫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 ميغابت في الثانية

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

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

5.3.6. VP8

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

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

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

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

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

5.3.7. ‫VP9

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

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

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

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

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

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

	الدقة العادية (جودة منخفضة)	الدقة العادية (جودة عالية)	دقة عالية - 720p	دقة عالية - 1080p	دقة فائقة
دقة الفيديو	‫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] يجب أن تسمح بتسجيل محتوى صوتي أولي بالخصائص التالية:

  • التنسيق: Linear PCM، بسعة 16 بت
  • معدّلات أخذ العينات: 8000 و11025 و16000 و44100 و48000 هرتز
  • القنوات: صوت أحادي

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

  • التنسيق: Linear PCM و16 بت و24 بت
  • معدّلات أخذ العينات: 8000 و11025 و16000 و22050 و24000 و32000 و44100 48000 هرتز
  • القنوات: عدد القنوات يساوي عدد الميكروفونات في الجهاز

• [C-1-2] يجب تسجيل المحتوى بمعدّلات أعلى من معدّلات أخذ العينات بدون زيادة معدّل أخذ العينات.

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

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

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

• [C-1-4] يجب الالتزام بواجهة برمجة التطبيقات MicrophoneInfo وملء معلومات الميكروفونات المتاحة على الجهاز التي يمكن للتطبيقات التابعة لجهات خارجية الوصول إليها من خلال واجهة برمجة التطبيقات AudioManager.getMicrophones() ، والميكروفونات النشطة حاليًا التي يمكن للتطبيقات التابعة لجهات خارجية الوصول إليها من خلال واجهات برمجة التطبيقات AudioRecord.getActiveMicrophones() وMediaRecorder.getActiveMicrophones(). إذا كانت عمليات تنفيذ الأجهزة تسمح بتسجيل محتوى صوتي بدائي بجودة راديو 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 هرتز.
• يجب تسجيل بث الصوت للتعرّف على الصوت مع ضبط حساسية الإدخال بحيث ينتج مصدر طاقة صوتية (SPL) بقدرة 90 ديسيبل عند 1000 هرتز قيمة RMS تبلغ 2500 لعيّنات 16 بت.
• يجب تسجيل بث الصوت لميزة التعرّف على الصوت بحيث تتتبّع مستويات كثافة PCM الصوت التغيُّرات في مستوى الضغط الصوتي (SPL) للإدخال بشكل خطي على مدى نطاق 30 ديسيبل على الأقل من -18 ديسيبل إلى +12 ديسيبل مقارنةً بمستوى الضغط الصوتي البالغ 90 ديسيبل عند الميكروفون.
• يجب أن يسجِّل بث الصوت الخاص بميزة التعرّف على الصوت مجموع التشوه التوافقي (THD) بنسبة أقل من% 1 عند تردد 1 كيلوهرتز ومستوى إدخال 90 ديسيبل SPL في الميكروفون.

إذا كانت عمليات تنفيذ الأجهزة تُعلن عن تكنولوجيات android.hardware.microphone وتكنولوجيات معالجة الضوضاء (تقليلها) المُعدّة للتعرّف على الكلام، يجب أن تستوفي المتطلبات التالية:

• [C-2-1] يجب السماح بالتحكّم في هذا المؤثر الصوتي باستخدام واجهة برمجة التطبيقات android.media.audiofx.NoiseSuppressor.
• [C-2-2] يجب تحديد كل عملية تنفيذ تكنولوجيات تقليل الضوضاء بشكل فريد من خلال الحقل AudioEffect.Descriptor.uuid.

5.4.3. تسجيل لإعادة توجيه التشغيل

تتضمّن فئة android.media.MediaRecorder.AudioSource مصدر الصوت REMOTE_SUBMIX.

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

• [C-1-1] يجب تنفيذ مصدر الصوت REMOTE_SUBMIX بشكل صحيح لكي تتمكّن التطبيقات من استخدام واجهة برمجة التطبيقات android.media.AudioRecord لتسجيل المحتوى من مصدر الصوت هذا، وتسجيل مزيج من جميع مصادر الصوت باستثناء ما يلي:

  • AudioManager.STREAM_RING
  • AudioManager.STREAM_ALARM
  • AudioManager.STREAM_NOTIFICATION

5.4.4. ميزة "إلغاء الصدى الصوتي"

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

• يجب استخدام تقنية إلغاء الصدى الصوتي (AEC) التي تم ضبطها للتواصل الصوتي وتطبيقها على مسار الالتقاط عند الالتقاط باستخدام AudioSource.VOICE_COMMUNICATION

إذا كانت عمليات تنفيذ الأجهزة توفّر ميزة "إلغاء الصدى الصوتي" التي يتم إدراجها في مسار الصوت الذي يتم تسجيله عند اختيار AudioSource.VOICE_COMMUNICATION ، يتم تنفيذ ما يلي:

• [C-SR-1] يُنصح بشدة بتحديد ذلك من خلال AcousticEchoCanceler طريقة واجهة برمجة التطبيقات AcousticEchoCanceler.isAvailable()
• [C-SR-2] يُنصح بشدة بالسماح بالتحكم في أثر الصوت هذا باستخدام واجهة برمجة التطبيقات AcousticEchoCanceler.
• [C-SR-3] يُنصح بشدة بتحديد كل عملية تنفيذ لتكنولوجيا AEC بشكل فريد من خلال الحقل AudioEffect.Descriptor.uuid.

5.4.5. التسجيل المتزامن

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

• [C-1-1] يجب السماح بالوصول المتزامن إلى الميكروفون من خلال خدمة تسهيل الاستخدام التي تسجِّل باستخدام AudioSource.VOICE_RECOGNITION وتطبيق واحد على الأقل يسجِّل باستخدام أي AudioSource.
• [C-1-2] يجب السماح بالوصول المتزامن إلى الميكروفون من خلال تطبيق pre-installed يحمل دور "مساعد 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. مستويات تضخيم الصوت في الميكروفون

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

• يجب أن يُظهر الميكروفون خصائص تقريبية مسطّحة لسعة الإشارة مقابل التردد في نطاق التردد المتوسط: على وجه التحديد ±3 ديسيبل من 100 هرتز إلى 4000 هرتز لكل ميكروفون مستخدَم لتسجيل مصدر ملف صوتي التعرّف على الصوت.
• يجب ضبط حساسية إدخال الصوت بحيث ينتج مصدر نغمة سينوسoidal بتردد 1000 هرتز يتم تشغيله عند مستوى ضغط صوت (SPL) يبلغ 90 ديسيبل استجابة بمتوسط طاقة 2500 لمعاينات 16 بت (أو -22.35 ديسيبل على النطاق الكامل لمعاينات النقطة المتغيرة/الدقة المزدوجة) لكل ميكروفون يتم استخدامه لتسجيل مصدر الصوت المخصّص للتعرّف على الكلام.
• [C-SR-1] يُنصح بشدة بعرض مستويات السعة في نطاق التردد المنخفض: على وجه التحديد من ±20 ديسيبل من 5 هرتز إلى 100 هرتز مقارنةً بنطاق التردد المتوسط لكل ميكروفون مستخدَم لتسجيل مصدر الصوت الذي يستند إليه التعرّف على الصوت.
• [C-SR-2] يُنصح بشدة بعرض مستويات السعة في نطاق التردد العالي: على وجه التحديد من ±30 ديسيبل من 4000 هرتز إلى 22 كيلوهرتز مقارنةً بنطاق التردد المتوسط لكل ميكروفون مستخدَم لتسجيل مصدر الصوت لميزة التعرّف على الصوت.

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

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

5.5.1. تشغيل الصوت غير المُعالج

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

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

  • تنسيقات المصدر: Linear PCM و16 بت و8 بت وقيمة عائمة
  • القنوات: صوت أحادي أو صوت استيريو أو إعدادات صالحة للصوت المتعدّد القنوات مع ما يصل إلى 8 قنوات
  • معدلات أخذ العينات (بالهرتز):
    • ‫8000 و11025 و16000 و22050 و24000 و32000 و44100 و48000 في إعدادات القناة المذكورة أعلاه
    • ‫96000 بصوت أحادي واستيريو

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

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

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

• [C-1-1] يجب أن يتيح التطبيق تنفيذ EFFECT_TYPE_EQUALIZER و EFFECT_TYPE_LOUDNESS_ENHANCER القابلَين للتحكّم من خلال Equalizer وLoudnessEnhancer، وهما فئتا فرعيتان من فئة AudioEffect.
• [C-1-2] يجب أن تتيح تنفيذ واجهة برمجة التطبيقات لعرض البيانات، والتي يمكن التحكّم فيها من خلال فئة Visualizer.
• [C-1-3] يجب أن تتيح تنفيذ EFFECT_TYPE_DYNAMICS_PROCESSING التي يمكن التحكّم فيها من خلال فئة فرعية من AudioEffect‏ DynamicsProcessing.
• يجب أن تتوافق مع عمليات تنفيذ 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
• فقدان الإدخال الجزء الأول من إشارة الإدخال غير القابلة للاستخدام أو غير المتوفّرة.
• وقت استجابة الإدخال من البداية الوقت المستغرَق بين بدء البث وتلقّي الإطار الصالح الأول، عندما يكون نظام إدخال الصوت في وضع السكون وقد تم إيقافه قبل الطلب
• وقت استجابة إدخال مستمر وقت استجابة الإدخال للّقطات اللاحقة، أثناء تسجيل الجهاز للصوت
• التشويش في إخراج الفيديو غير المشغّل التباين بين القياسات المنفصلة لقيم وقت استجابة الإخراج البطيء
• التشويش في الإدخال غير المُعدّ للبث التباين بين القياسات المنفصلة لقيم وقت استجابة الإدخال البارد
• وقت استجابة مستمر للذهاب والعودة مجموع وقت استجابة الإدخال المتواصل بالإضافة إلى وقت استجابة الإخراج المتواصل بالإضافة إلى فترة تخزين مؤقت واحد تسمح فترة التخزين المؤقت للتطبيق بمعالجة الإشارة والوقت الذي يحتاجه التطبيق للتخفيف من اختلاف مرحلته بين مصادر الإدخال والإخراج.
• واجهة برمجة التطبيقات لصفيف ذاكرة التخزين المؤقت لـ PCM في OpenSL ES مجموعة واجهات برمجة تطبيقات OpenSL ES ذات الصلة بتنسيق PCM ضمن Android NDK
• واجهة برمجة التطبيقات AAudio للصوت الأصلي مجموعة واجهتَي برمجة تطبيقات AAudio ضمن Android NDK
• الطابع الزمني: زوج يتألّف من موضع إطار نسبي ضمن مجرى تدفق ومقدار الوقت المقدَّر الذي يدخل فيه هذا الإطار أو يغادره مجرى معالجة الصوت في نقطة النهاية المرتبطة راجِع أيضًا AudioTimestamp.
• خطأ انقطاع مؤقت أو قيمة عيّنة غير صحيحة في إشارة الصوت، ويحدث ذلك عادةً بسبب توقّف مؤقت للذاكرة المؤقتة في الإخراج أو تجاوز الذاكرة المؤقتة في الإدخال أو أي مصدر آخر للضوضاء الرقمية أو التناظرية.
• متوسّط الانحراف المطلق متوسّط القيمة المطلقة للانحرافات عن المتوسط لمجموعة من القيم
• وقت استجابة ميزة "النقر للتحدث" الوقت المستغرَق بين النقر على الشاشة وسماع نغمة تم إنشاؤها نتيجةً لذلك النقر على مكبّر الصوت

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

• [C-1-1] يجب أن يكون الطابع الزمني الناتج الذي تعرضه AudioTrack.getTimestamp وAAudioStream_getTimestamp دقيقًا بدقة تصل إلى ± 2 ملي ثانية.
• [C-1-2] وقت استجابة الإخراج عند التشغيل على البارد لا يتجاوز 500 ملي ثانية

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

• [C-SR-1] يجب أن يكون وقت استجابة الإخراج بدون محتوى 100 ملي ثانية أو أقل على مسار بيانات مكبّر الصوت. ننصح بشدة بالامتثال لهذه المتطلبات الآن على الأجهزة الحالية والجديدة التي تعمل بهذا الإصدار من Android. في إصدار قادم من المنصة، سنشترط أن يكون وقت استجابة الإخراج "غير القابل للتقديم أو الإيقاف" 200 ملي ثانية أو أقل.
• [C-SR-2] يجب أن يكون وقت استجابة ميزة "النقر للتشغيل" 80 ملي ثانية أو أقل.
• [C-SR-3] الحدّ من التقلّبات في إخراج التشغيل على البارد
• [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] يُنصح بشدة بالتأكّد من أنّ قيم مصادر البيانات التي تعرض AAUDIO_PERFORMANCE_MODE_LOW_LATENCY من AAudioStream_getPerformanceMode()، تكون القيمة التي تعرِضها AAudioStream_getFramesPerBurst() أقل من أو مساوية للقيمة التي تعرِضها android.media.AudioManager.getProperty(String) لمفتاح الموقع AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

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

• [C-2-1] يجب عدم الإبلاغ عن توفّر ميزة الصوت بوقت استجابة منخفض.

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

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

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

• [C-SR-8] وقت استجابة الإدخال بدون تحضير يبلغ 100 ملي ثانية أو أقل عبر مسار بيانات الميكروفون بالنسبة إلى الأجهزة الحالية والجديدة التي تعمل بهذا الإصدار من Android، ننصحك بشدة باستيفاء هذه المتطلبات الآن. في إصدار قادم من المنصة، سنطلب وقت استجابة الإدخال من حالة السكون بمقدار 200 ملي ثانية أو أقل كأحد متطلبات التوافق.
• [C-SR-9] يجب أن يكون وقت استجابة الإدخال المستمر 30 ملي ثانية أو أقل.
• [C-SR-10] الحدّ من الارتعاش في الإدخال غير المُعدّ مسبقًا
• [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 وعلامات ID3	ISO 13818-7	راجِع القسم 5.1.1 للاطّلاع على تفاصيل حول الترميز المتقدّم للصوت (AAC) وأنواعه.
WebVTT	WebVTT

‫RTSP (RTP وSDP)

اسم الملف الشخصي	المراجع	توفُّر برامج الترميز المطلوبة
‫H264 AVC	RFC 6184	راجِع القسم 5.1.8 للاطّلاع على تفاصيل عن H264 AVC.
MP4A-LATM	RFC 6416	راجِع الفقرة 5.1.3 للاطّلاع على تفاصيل حول الترميز المتقدّم للصوت (AAC) وأنواعه.
‫H263-1998	RFC 3551 RFC 4629 RFC 2190	راجِع القسم 5.1.8 للاطّلاع على تفاصيل عن H263.
‫H263-2000	RFC 4629	راجِع القسم 5.1.8 للاطّلاع على تفاصيل عن H263.
AMR	RFC 4867	راجِع القسم 5.1.3 للاطّلاع على تفاصيل حول AMR-NB.
AMR-WB	RFC 4867	راجِع الفقرة 5.1.3 للاطّلاع على تفاصيل حول AMR-WB.
MP4V-ES	RFC 6416	راجِع القسم 5.1.8 للاطّلاع على تفاصيل عن MPEG-4 SP.
mpeg4-generic	RFC 3640	راجِع الفقرة 5.1.3 للاطّلاع على تفاصيل حول الترميز المتقدّم للصوت (AAC) وأنواعه.
MP2T	RFC 2250	راجِع MPEG-2 Transport Stream ضمن "البث المباشر عبر HTTP" للاطّلاع على التفاصيل.

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] يجب تضمين libamidi.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 وقت استجابة إرسال البيانات واستقبالها للصوت، 20 ملي ثانية أو أقل ويجب أن يكون 10 ملي ثانية أو أقل على مسار واحد متوافق على الأقل.
• [C-1-3] يجب أن يتضمّن الجهاز منافذ USB متوافقة مع وضع مضيف USB ووضع جهاز USB محيطي.
• [C-1-4] يجب الإبلاغ عن توفّر الميزة android.software.midi.
• [C-1-5] يجب استيفاء متطلبات وقت الاستجابة والصوت عبر USB باستخدام واجهة برمجة التطبيقات AAudio native audio.
• [C-1-6] يجب أن يكون وقت استجابة الإخراج غير القابل للتقديم أو الإيقاف 200 ملي ثانية أو أقل.
• [C-1-7] يجب أن يكون وقت استجابة الإدخال في وضع عدم التشغيل 200 ملي ثانية أو أقل.
• [C-SR-1] يُنصح بشدة باستيفاء أوقات الاستجابة كما هو محدّد في القسم 5.6 وقت استجابة الصوت، والذي يبلغ 20 ملي ثانية أو أقل، على مدار 5 قياسات مع متوسّط انحراف مطلق أقل من 5 ملي ثانية على مسار انتقال الصوت من مكبّر الصوت إلى الميكروفون.
• [C-SR-2] يُنصح بشدة باستيفاء متطلبات Pro Audio لوقت استجابة الصوت المستمر للنقل والاستقبال ووقت استجابة الإدخال والإخراج عند بدء التشغيل ووقت استجابة الصوت عبر USB باستخدام واجهة برمجة التطبيقات AAudio native audio على مسار MMAP.
• [C-SR-3] يُنصح بشدة بتوفير مستوى ثابت من أداء وحدة المعالجة المركزية أثناء تشغيل الصوت وتغيُّر عبء وحدة المعالجة المركزية. يجب اختبار ذلك باستخدام تطبيق Android SynthMark. تستخدِم أداة SynthMark برنامجًا مركبًا يعمل على إطار عمل صوتي اصطناعي يقيس أداء النظام. يجب تشغيل تطبيق SynthMark باستخدام خيار "الاختبار المبرمَج" وتحقيق النتائج التالية:
  • ‫voicemark.90 >= 32 صوتًا
  • ‫latencymark.fixed.little <= 15 msec
  • ‫latencymark.dynamic.little <= 50 msec

راجِع مستندات SynthMark للحصول على شرح لمقاييس الأداء.

• يجب تقليل عدم دقة الساعة الصوتية وانحرافها مقارنةً بالوقت العادي.
• من المفترض أن تقلّل هذه الميزة من انحراف ساعة الصوت بالنسبة إلى وحدة المعالجة المركزية CLOCK_MONOTONIC عندما يكون كلاهما نشطًا.
• يجب تقليل وقت استجابة الصوت عبر محوِّلات الطاقة على الجهاز.
• يجب أن تقلّل من وقت استجابة الصوت عبر الصوت الرقمي عبر USB.
• يجب تسجيل قياسات وقت استجابة الصوت على جميع المسارات.
• يجب تقليل الارتعاش في أوقات إدخال طلب معاودة الاتصال لإكمال ذاكرة التخزين المؤقت للصوت، لأنّ ذلك يؤثر في النسبة المئوية القابلة للاستخدام من معدل نقل البيانات الكامل لوحدة المعالجة المركزية من خلال طلب معاودة الاتصال.
• يجب ألا يتضمّن أي مشاكل في الصوت أثناء الاستخدام العادي بمعدّل الاستجابة المسجَّل.
• يجب أن لا يختلف وقت الاستجابة بين القنوات.
• يجب تقليل متوسط وقت استجابة MIDI على جميع عمليات النقل.
• يجب تقليل التباين في وقت استجابة MIDI أثناء التحميل (التشويش) على جميع عمليات النقل.
• يجب أن يوفّر الطوابع الزمنية MIDI دقيقة على جميع عمليات النقل.
• يجب تقليل الضوضاء في إشارة الصوت عبر محوِّلات الطاقة على الجهاز، بما في ذلك الفترة التي تلي التشغيل على البارد مباشرةً.
• يجب أن لا يكون هناك أي فرق في ساعة الصوت بين جانبَي الإدخال والإخراج للنقاط الطرفية المقابلة، عندما يكون كلاهما نشطًا. تشمل أمثلة نقاط النهاية المقابلة الميكروفون ومكبّر الصوت على الجهاز، أو إدخال ومقبس إخراج الصوت.
• يجب أن تعالج عمليات تسجيل الإشعارات عند اكتمال تخزين مؤقت للصوت في جانبَي الإدخال والإخراج للنقاط الطرفية المقابلة في سلسلة المحادثات نفسها عندما يكون كلاهما نشطًا، ويجب إدخال إشعار الإدخال فورًا بعد العودة من إشعار الإخراج. أو إذا لم يكن من الممكن معالجة طلبات الاستدعاء في سلسلة المهام نفسها، أدخِل طلب استدعاء الإخراج بعد وقت قصير من إدخال طلب استدعاء الإدخال للسماح للتطبيق بتحديد توقيت متسق لكل من جانبَي الإدخال والإخراج.
• يجب تقليل الفرق في الطور بين التخزين المؤقت للصوت في HAL لكل من جانبَي الإدخال والإخراج في نقاط النهاية المقابلة.
• يجب أن تقلِّل من وقت استجابة اللمس.
• يجب تقليل التباين في وقت استجابة اللمس أثناء التحميل (التشويش).
• يجب أن يكون وقت الاستجابة من الإدخال باللمس إلى إخراج الصوت أقل من أو مساوياً ‎40 ملي ثانية.

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

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

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

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

• [C-1-7] يجب أن يكون التشويه التوافقي الكلي (THD) أقل من 1% عند تردد 1 كيلوهرتز ومستوى إدخال 90 ديسيبل للضغط الصوتي في كل ميكروفون يتم استخدامه لتسجيل مصدر الصوت غير المعالج.

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

  • [C-1-9] إذا كان هناك أيّ معالجة إشارة في البنية لأيّ سبب، يجب إيقافها وتقديم تأخير صفري أو وقت استجابة إضافي إلى مسار الإشارة بشكل فعّال.
  • [C-1-10] يجب ألا يؤدي مُضاعِف المستوى، على الرغم من السماح بوجوده في المسار، إلى إدخال تأخير أو وقت استجابة في مسار الإشارة.

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

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

• [C-2-1] يجب أن تُرجع null لطريقة AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) API، للإشارة بشكل صحيح إلى عدم توفّر الدعم.
• [C-SR-1] لا يزال يُنصح بشدة باستيفاء أكبر عدد ممكن من المتطلبات لمسار الإشارة لمصدر التسجيل غير المعالج.

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 في shell. قد يتم استثناء عمليات ترقية عمليات تنفيذ الأجهزة من إصدار Android أقدم بدون توفُّر كتلة بيانات دائمة من C-0-11.
  • [C-0-3] يجب عدم تغيير تنسيق أو محتوى أحداث نظام الجهاز (batterystats وdiskstats وfingerprint وgraphicsstats وnetstats وnotification وprocstats) التي يتم تسجيلها من خلال الأمر dumpsys.
  • [C-0-10] يجب تسجيل الأحداث التالية بدون حذفها وإتاحة الوصول إليها من خلال الأمر cmd stats shell وStatsManager فئة System API.
    • ActivityForegroundStateChanged
    • AnomalyDetected
    • AppBreadcrumbReported
    • AppCrashOccurred
    • AppStartOccurred
    • BatteryLevelChanged
    • BatterySaverModeStateChanged
    • BleScanResultReceived
    • BleScanStateChanged
    • ChargingStateChanged
    • DeviceIdleModeStateChanged
    • ForegroundServiceStateChanged
    • GpsScanStateChanged
    • JobStateChanged
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • ScreenStateChanged
    • SyncStateChanged
    • SystemElapsedRealtime
    • UidProcessStateChanged
    • WakelockStateChanged
    • WakeupAlarmOccurred
    • WifiLockStateChanged
    • WifiMulticastLockStateChanged
    • WifiScanStateChanged
  • [C-0-4] يجب أن يكون برنامج adb الخفي غير مفعّل تلقائيًا على الجهاز، ويجب أن تتوفّر آلية يمكن للمستخدم الوصول إليها لتفعيل أداة Android Debug Bridge.
  • [C-0-5] يجب أن يكون متوافقًا مع adb الآمن. يتيح نظام Android استخدام أداة adb الآمنة. تفعِّل أداة adb الآمنة أداة adb على المضيفين المعروفين الذين تمّت مصادقتهم.
  • [C-0-6] يجب توفير آلية تسمح بربط adb من جهاز مضيف. وعلى وجه التحديد:

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

  • [C-3-1] يجب تنفيذ adb عبر شبكة منطقة محلية (مثل إيثرنت أو 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 Service ‏ (ddms)

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

• Monkey

  • [C-0-8] يجب أن يتضمّن إطار عمل Monkey وأن يكون متاحًا للاستخدام في التطبيقات.

• SysTrace

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

• Perfetto

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

• Low Memory Killer

  • [C-0-10] يجب كتابة LMK_KILL_OCCURRED_FIELD_NUMBER Atom في ملف سجلّ statsd عند إنهاء أحد التطبيقات بواسطة Low Memory Killer.

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

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

إذا أبلغت عمليات تنفيذ الأجهزة عن توفّر 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] يجب أن ينفِّذ تطبيق الجهاز واجهة برمجة التطبيقات (IDE) هذه كما هو موضّح في مستندات حزمة تطوير البرامج (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 نقطة لكل بوصة، ويتم احتسابها على النحو التالي: وحدات البكسل = عدد النقاط لكل بوصة * (الكثافة/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 dp x ‏480 dp على الأقل.
  • يجب أن تكون الأجهزة التي تُبلغ عن حجم xlarge لشاشة Configuration.screenLayout، بدقة 960 نقطة لكل بوصة × 720 نقطة لكل بوصة على الأقل.

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

• يمكن أن تتضمّن شاشات متوافقة مع Android وزوايا دائرية.

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

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

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

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

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

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

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

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

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

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

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

• [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 مرة من الكثافة الأصلية أو أن يؤدي إلى الحد الأدنى الفعال لبُعد الشاشة الذي يقل عن 320dp (أي ما يعادل مُحدِّد المورد 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 للشاشة التلقائية المحاكية 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-master-YYYY-MM-DD.txt. يشير الجهاز الذي يتوافق مع OpenGL ES على مستوى يُبلِغ عنه المستخدم إلى أنّه يمكنه اجتياز اختبارات dEQP في جميع قوائم الاختبارات من هذا المستوى والإصدارات الأقدم.

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

• [C-2-1] يجب الإبلاغ من خلال واجهات برمجة التطبيقات المُدارة وواجهات برمجة التطبيقات الأصلية لـ OpenGL ES عن أي إضافات أخرى لـ OpenGL ES تم تنفيذها، وعلى العكس يجب عدم الإبلاغ عن سلاسل الإضافات التي لا تتوافق معها.
• [C-2-2] يجب أن تكون متوافقًا مع الإضافات EGL_KHR_image وEGL_KHR_image_base EGL_ANDROID_image_native_buffer وEGL_ANDROID_get_native_client_buffer EGL_KHR_wait_sync وEGL_KHR_get_all_proc_addresses EGL_ANDROID_presentation_time وEGL_KHR_swap_buffers_with_damage EGL_ANDROID_recordable وEGL_ANDROID_GLES_layers.
• [C-2-3] يجب الإبلاغ عن الحد الأقصى لإصدار اختبارات dEQP في OpenGL ES المتوافقة من خلال علامة ميزة android.software.opengles.deqp.level.
• [C-2-4] يجب أن يكون متوافقًا مع الإصدار 132383489 على الأقل (بدءًا من 1 آذار (مارس) 2020) كما هو مذكور في علامة ميزة android.software.opengles.deqp.level.
• [C-2-5] يجب اجتياز جميع اختبارات dEQP في OpenGL ES في قوائم الاختبار بين الإصدار 132383489 والإصدار المحدّد في علامة ميزة android.software.opengles.deqp.level، لكل إصدار متوافق من OpenGL ES.
• [C-SR-2] يُنصح بشدة بتوفّر الإضافتَين EGL_KHR_partial_update و OES_EGL_image_external.
• يجب أن يتم الإبلاغ بدقة من خلال طريقة getString() عن أي تنسيق ضغط رسومات يتوافق معه التطبيق، والذي يكون عادةً خاصًا بالمورّد.

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

• [C-3-1] يجب تصدير رموز الدوالّ المقابلة لهذه الإصدارات بالإضافة إلى رموز دوالّ OpenGL ES 2.0 في مكتبة libGLESv2.so.
• [C-SR-3] يُنصح بشدة بتوفُّر إضافة OES_EGL_image_external_essl3.

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

• [C-4-1] يجب أن يكون متوافقًا مع حزمة OpenGL ES Android Extension Pack بالكامل.

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

• [C-5-1] يجب تحديد مدى توفّر الميزة من خلال android.hardware.opengles.aep علامة الميزة.

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

• [C-6-1] يجب أن تتيح أيضًا إضافة EGL_ANDROID_front_buffer_auto_refresh.

7.1.4.2 Vulkan

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

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

• [C-SR-1] يُنصح بشدة بتضمين واجهة برمجة التطبيقات Vulkan 1.1.

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

• يجب أن تتضمّن واجهة برمجة التطبيقات إمكانية استخدام Vulkan 1.1.

يتم تقسيم اختبارات Vulkan dEQP إلى عدد من قوائم الاختبارات، ولكل منها تاريخ أو إصدار مرتبط. يمكنك العثور على هذه المراجع في شجرة مصدر Android على الرابط external/deqp/android/cts/main/vk-master-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 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] يجب الإبلاغ عن الحد الأقصى لإصدار اختبارات Vulkan dEQP المتوافقة من خلال علامة ميزة 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-2] يُنصح بشدة بتوفير دعم للإضافتَين VK_KHR_driver_properties و VK_GOOGLE_display_timing.

إذا لم تتضمّن عمليات تنفيذ الأجهزة إتاحة استخدام 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 إشارة الانتظار الخارجية وhandle وإضافة 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 APIs.
• [C-0-2] يجب أن يعرض التطبيق سلوكًا متوافقًا مع مستندات IDE لنظام التشغيل 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 "وضع التوافق" الذي يعمل فيه إطار العمل في وضع مكافئ لحجم الشاشة "العادي" (بعرض 320dp) لمنفعة التطبيقات القديمة التي لم يتم تطويرها لإصدارات Android القديمة التي تسبق استقلالية حجم الشاشة.

7.1.6. تكنولوجيا الشاشة

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

جميع شاشات التنفيذ المتوافقة مع Android للجهاز:

• [C-0-1] يجب أن يكون الجهاز قادرًا على عرض رسومات ملونة بدقة 16 بت.
• يجب أن تكون متوافقة مع الشاشات التي يمكنها عرض الرسومات الملوّنة بدقة 24 بت.
• [C-0-2] يجب أن يكون الجهاز قادرًا على عرض الرسوم المتحركة.
• [C-0-3] يجب أن تكون نسبة العرض إلى الارتفاع بالبكسل (PAR) بين 0.9 و1.15. وهذا يعني أنّ نسبة عرض البكسل إلى ارتفاعه يجب أن تكون قريبة من مربّعة (1.0) مع هامش خطأ يتراوح بين ‎10% و‎15%.

7.1.7. الشاشات الثانوية

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

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

• [C-1-1] يجب تنفيذ خدمة النظام DisplayManager وواجهة برمجة التطبيقات على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

7.2. أجهزة إدخال بيانات

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

• [C-0-1] يجب أن يتضمّن آلية إدخال، مثل شاشة لمس أو تنقّل بدون لمس، للتنقّل بين عناصر واجهة المستخدم.

7.2.1. لوحة المفاتيح

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

• [C-1-1] يجب الإفصاح عن علامة ميزة android.software.input_methods.
• [C-1-2] يجب تنفيذ Input Management Framework بالكامل
• [C-1-3] يجب أن يكون الجهاز مزوّدًا بلوحة مفاتيح برمجية مثبَّتة مسبقًا.

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

• [C-0-1] يجب عدم تضمين لوحة مفاتيح أجهزة لا تتطابق مع أحد التنسيقات المحدّدة في android.content.res.Configuration.keyboard (QWERTY أو 12 مفتاحًا).
• يجب أن تتضمّن عمليات تنفيذ إضافية للوحة المفاتيح.
• قد تتضمّن لوحة مفاتيح جهاز.

7.2.2. التنقّل بدون لمس الشاشة

يتيح نظام التشغيل Android استخدام لوحة التوجيه وكرة التتبُّع والعجلة كآليات للتنقّل بدون لمس الشاشة.

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

• [C-0-1] يجب الإبلاغ عن القيمة الصحيحة لملف برمجي android.content.res.Configuration.navigation.

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

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

7.2.3. مفاتيح التنقل

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

• [C-0-1] يجب توفير عنصر تحكم للمستخدم لبدء التطبيقات المثبَّتة التي لها نشاط مع <intent-filter> تم ضبطه على ACTION=MAIN و CATEGORY=LAUNCHER أو CATEGORY=LEANBACK_LAUNCHER لعمليات تنفيذ أجهزة التلفزيون. يجب أن تكون وظيفة "المنزل" هي آلية توفير هذه الميزة للمستخدم.
• يجب أن توفّر أزرارًا لوظيفتَي "التطبيقات المستخدَمة مؤخرًا" و"الرجوع".

في حال توفّر وظائف "الصفحة الرئيسية" أو "العناصر الأخيرة" أو "رجوع"، يجب أن تستوفي الشروط التالية:

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

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

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

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

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

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

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

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

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

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

• [C-5-1] يجب أن تستخدم مفاتيح التنقّل جزءًا محددًا من الشاشة غير متاح للتطبيقات، ويجب ألّا تحجب أو تتداخل مع الجزء من الشاشة المتاح للتطبيقات.
• [C-5-2] يجب أن يتيح الجهاز جزءًا من الشاشة للتطبيقات التي تفي بالمتطلبات المحدّدة في الفقرة 7.1.1.
• [C-5-3] يجب أن يراعي التطبيق العلامات التي يضبطها من خلال View.setSystemUiVisibility() طريقة واجهة برمجة التطبيقات، وذلك لإخفاء هذا الجزء الواضح من الشاشة (المعروف أيضًا باسم شريط التنقّل) بشكلٍ سليم كما هو موضّح في مستندات حزمة تطوير البرامج (SDK).

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

• [C-6-1] WindowInsets#getMandatorySystemGestureInsets() يجب استخدام هذا الرمز فقط للإبلاغ عن منطقة التعرّف على إيماءات Home.
• [C-6-2] يجب عدم اعتراض الإيماءات التي تبدأ داخل مستطيل استبعاد كما يقدّمها التطبيق الذي يعمل في المقدّمة من خلال View#setSystemGestureExclusionRects()، ولكن خارج WindowInsets#getMandatorySystemGestureInsets()، لوظيفة التنقّل ما دام مستطيل الاستبعاد مسموحًا به ضمن الحد الأقصى للاستبعاد كما هو محدّد في مستندات View#setSystemGestureExclusionRects().
• [C-6-3] يجب إرسال حدث MotionEvent.ACTION_CANCEL إلى التطبيق المعروض في المقدّمة بعد بدء اعتراض اللمسات لتنفيذ إيماءة نظام، إذا سبق أن تم إرسال حدث MotionEvent.ACTION_DOWN إلى التطبيق المعروض في المقدّمة.
• [C-6-4] يجب أن توفّر ميزة للمستخدم للتبديل إلى تنقّل على الشاشة يستند إلى buttons (مثلاً، في الإعدادات).
• يجب أن توفّر وظيفة "الشاشة الرئيسية" من خلال التمرير سريعًا من الحافة السفلية لاتجاه الشاشة الحالي.
• يجب أن توفّر وظيفة "التطبيقات المستخدَمة مؤخرًا" من خلال التمرير سريعًا للأعلى مع الاستمرار قبل تحرير الإصبع، من المنطقة نفسها التي يتم فيها استخدام إيماءة "الرجوع إلى الشاشة الرئيسية".
• يجب ألا تتأثر الإيماءات التي تبدأ في WindowInsets#getMandatorySystemGestureInsets() بأشكال الاستبعاد التي يوفّرها التطبيق في المقدّمة من خلال View#setSystemGestureExclusionRects().

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

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

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

7.2.6. توافق وحدة التحكّم في الألعاب

7.2.6.1. عمليات ربط الأزرار

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

• [C-1-1] يجب أن يكون النظام قادرًا على ربط أحداث HID بثوابت InputEvent المقابلة كما هو موضّح في الجداول أدناه. يستوفي تطبيق Android هذا الشرط.

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

• [C-2-1] يجب الإفصاح عن علامة الميزة android.hardware.gamepad

زرّ	استخدام HID2	زر Android
أ1	0x09 0x0001	KEYCODE_BUTTON_A (96)
ب1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X1	0x09 0x0004	KEYCODE_BUTTON_X (99)
نعم1	0x09 0x0005	KEYCODE_BUTTON_Y (100)
أداة التوجيه العلوية1 أداة التوجيه السفلية1	‎0x01 0x00393	AXIS_HAT_Y4
الزر الأيسر في لوحة التحكم1 الزر الأيمن في لوحة التحكم1	‎0x01 0x00393	AXIS_HAT_X4
زرّ أعلى ذراع التحكّم الأيسر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 حسب الاقتضاء عندما تحاول التطبيقات تسجيل المستمعين، وعدم استدعاء مستمعي أجهزة الاستشعار عندما لا تكون أجهزة الاستشعار المقابلة متوفّرة، وما إلى ذلك).

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

• [C-1-1] يجب الإبلاغ عن جميع قياسات أجهزة الاستشعار باستخدام قيم النظام الدولي للوحدات (المقياس) ذات الصلة لكل نوع من أجهزة الاستشعار كما هو محدّد في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
• [C-1-2] يجب الإبلاغ عن بيانات أجهزة الاستشعار بحد أقصى لمُدد الاستجابة يبلغ 100 ملي ثانية + 2 * sample_time في حال بث بيانات أجهزة الاستشعار بحد أقصى لمُدد الاستجابة المطلوبة يبلغ 0 ملي ثانية عندما يكون معالج التطبيقات نشطًا. ولا يشمل هذا التأخير أي تأخيرات في الفلترة.
• [C-1-3] يجب الإبلاغ عن أول عيّنة من بيانات المستشعر في غضون 400 ملي ثانية + 2 * وقت_العيّنة من وقت تفعيل المستشعر. من المقبول أن تبلغ دقة هذه العيّنة 0.
• [C-1-4] بالنسبة إلى أيّ واجهة برمجة تطبيقات يشير مستند حزمة تطوير البرامج (SDK) لنظام التشغيل Android إلى أنّها جهاز استشعار مستمر، يجب أن تقدّم عمليات تنفيذ الأجهزة باستمرار عيّنات بيانات دورية يجب أن يكون لها انحرافًا أقل من %3، حيث يتم تعريف الانحراف على أنّه التباين المعياري للفرق بين قيم الطوابع الزمنية المسجّلة بين الأحداث المتتالية.
• [C-1-5] يجب التأكّد من أنّه يجب ألا يمنع بث أحداث الاستشعار وحدة المعالجة المركزية (CPU) في الجهاز من الدخول في حالة تعليق أو الاستيقاظ من حالة تعليق.
• [C-1-6] يجب تسجيل وقت الحدث بالنانو ثانية كما هو محدّد في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android، ما يمثّل وقت وقوع الحدث ومزامنة مع الساعة SystemClock.elapsedRealtimeNano()‎.
• [C-SR-1] يُنصح بشدة بأن يكون خطأ مزامنة الطابع الزمني أقل من 100 مللي ثانية، ويجب أن يكون خطأ مزامنة الطابع الزمني أقل من 1 مللي ثانية.
• عند تفعيل عدة أدوات استشعار، يجب ألا يتجاوز استهلاك الطاقة مجموع استهلاك الطاقة المسجَّل لكل أداة استشعار فردية.

القائمة أعلاه ليست شاملة، ويجب اعتبار السلوك المُسجَّل لحزمة SDK لنظام التشغيل Android ومستندات Android Open Source حول أجهزة الاستشعار مستندًا موثوقاً.

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

• [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-2] يجب تنفيذ TYPE_ACCELEROMETER جهاز الاستشعار والإبلاغ عنه.
• [C-1-3] يجب أن تكون متوافقة مع نظام إحداثيات أدوات استشعار Android كما هو موضّح بالتفصيل في واجهات برمجة تطبيقات Android.
• [C-1-4] يجب أن يكون الجهاز قادرًا على قياس التسارع من السقوط الحر إلى أربع مرات كثافة الجاذبية(4g) أو أكثر على أي محور.
• [C-1-5] يجب أن تكون درجة دقة الصورة 12 بت على الأقل.
• [C-1-6] يجب أن يكون التباين المعياري لا يزيد عن 0.05 متر في الثانية المربعة، حيث يجب احتساب التباين المعياري لكل محور على أساس عيّنات يتم جمعها على مدار 3 ثوانٍ على الأقل بأسرع معدّل تحليل.
• [C-SR-2] يُنصح بشدة بتنفيذ TYPE_SIGNIFICANT_MOTION أداة الاستشعار المركبة.
• [C-SR-3] يُنصح بشدة بتنفيذ TYPE_ACCELEROMETER_UNCALIBRATED الاستشعار والإبلاغ عنه. ننصح بشدة بتوافق أجهزة Android مع هذا الشرط حتى تتمكّن من الترقية إلى إصدار المنصة المستقبلي الذي قد يصبح فيه هذا الشرط مطلوبًا.
• يجب تنفيذ أدوات الاستشعار المركبة TYPE_SIGNIFICANT_MOTION وTYPE_TILT_DETECTOR TYPE_STEP_DETECTOR وTYPE_STEP_COUNTER كما هو موضّح في مستند حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
• يجب أن تُبلغ عن الأحداث التي تصل إلى 200 هرتز على الأقل.
• يجب أن تكون درجة دقتها 16 بت على الأقل.
• يجب معايرة هذه الخصائص أثناء الاستخدام إذا تغيّرت على مدار دورة الحياة، ويجب تعويضها والحفاظ على مَعلمات التعويض بين عمليات إعادة تشغيل الجهاز.
• يجب أن يتم تصحيحها حسب درجة الحرارة.

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

• [C-2-1] يجب أن يكون مجموع استهلاك الطاقة أقل من 4 ملي واط في أي وقت.
• يجب أن يكون كل منهما أقل من 2 ملي واط و0.5 ملي واط عندما يكون الجهاز في حالة ديناميكية أو ساكنة.

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

• [C-3-1] يجب تنفيذ أداتَي الاستشعار المركبتَين TYPE_GRAVITY وTYPE_LINEAR_ACCELERATION.
• [C-SR-4] يُنصح بشدة بتنفيذ أداة الاستشعار المركبة TYPE_GAME_ROTATION_VECTOR.

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

• [C-4-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 µT على كل محور قبل الوصول إلى التشبع.
• [C-1-5] يجب أن تكون قيمة الإزاحة الحديدية الصلبة أقل من 700 ميكرو تسلا، ويجب أن تكون قيمتها أقل من 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) وتُبلغ عن إمكانية استخدام الميزة للتطبيقات من خلال علامة ميزة android.hardware.location.gps، يجب استيفاء الشروط التالية:

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

• في ظروف السماء المفتوحة بعد تحديد الموقع الجغرافي، أثناء الثبات أو الحركة بسرعة تسارع أقل من متر واحد في الثانية المربعة:

  • [C-1-3] يجب أن يكون الجهاز قادرًا على تحديد الموقع الجغرافي ضمن نطاق 20 مترًا، وسرعة التنقّل ضمن نطاق 0.5 متر في الثانية، في% 95 من الوقت على الأقل.
  • [C-1-4] يجب تتبُّع 8 أقمار صناعية على الأقل من مجموعة نجوم واحدة والإبلاغ عنها في الوقت نفسه من خلال GnssStatus.Callback.
  • يجب أن يكون الجهاز قادرًا على تتبُّع 24 قمرًا صناعيًا على الأقل في وقت واحد من أنظمة تحديد المواقع المتعدّدة (مثل نظام تحديد المواقع العالمي (GPS) ونظام GLONASS ونظام Beidou ونظام Galileo على الأقل).

• [C-SR-2] يُنصح بشدة بمواصلة عرض نتائج الموقع الجغرافي العادية من خلال واجهات برمجة التطبيقات GNSS Location Provider API أثناء مكالمة هاتفية للطوارئ.

• [C-SR-3] يُنصح بشدة بالإبلاغ عن قياسات نظام تحديد المواقع العالمي (GNSS) من جميع المجموعات النجمية التي يتم تتبُّعها (كما هو موضّح في رسائل GnssStatus)، باستثناء نظام SBAS.

• [C-SR-4] يُنصح بشدة بالإبلاغ عن AGC ومعدّل قياس GNSS.

• [C-SR-5] يُنصح بشدة بالإبلاغ عن جميع تقديرات الدقة (بما في ذلك الاتجاه والسرعة والقيمة العمودية) كجزء من كل موقع جغرافي لنظام تحديد المواقع العالمي (GPS) أو نظام تحديد المواقع العالمي (GNSS).

• [C-SR-6] يُنصح بشدة بالإبلاغ عن قياسات نظام تحديد المواقع العالمي (GNSS) فورًا عند العثور عليها، حتى إذا لم يتم الإبلاغ عن موقع جغرافي تم احتسابه من نظام تحديد المواقع العالمي (GPS)/نظام تحديد المواقع العالمي (GNSS).

• [C-SR-7] يُنصح بشدة بالإبلاغ عن نطاقات GNSS الزائفة ومقدّرات النطاقات الزائفة، والتي تكون كافية لاحتساب الموقع الجغرافي ضمن 20 مترًا والسرعة ضمن 0.2 متر في الثانية في ‎95% من الوقت على الأقل، وذلك في ظروف السماء المفتوحة بعد تحديد الموقع الجغرافي، أثناء الثبات أو التحرك بمعدّل تسارع أقل من 0.2 متر في الثانية المربعة.

7.3.4. الجيروسكوب

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

• [C-SR-1] يُنصح بشدة بتضمين أداة استشعار جيروسكوب.

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

• [C-1-1] يجب أن يكون الجهاز قادرًا على تسجيل الأحداث بمعدّل تكرار لا يقل عن 50 هرتز.
• [C-1-2] يجب تنفيذ أداة استشعار TYPE_GYROSCOPE.
• [C-1-4] يجب أن تكون درجة دقة الصورة 12 بت أو أكثر.
• [C-1-5] يجب أن يكون مصحوبًا بمُعدِّل حرارة.
• [C-1-6] يجب معايرة الجهاز وتعويضه أثناء الاستخدام، والحفاظ على مَعلمات التعويض بين عمليات إعادة تشغيل الجهاز.
• [C-1-7] يجب ألا يزيد التباين عن 1e-7 rad^2 / s^2 لكل هرتز (التباين لكل هرتز أو rad^2 / s). يُسمح باختلاف التباين مع معدل sampling، ولكن يجب أن يكون مقيّدًا بهذه القيمة. بعبارة أخرى، إذا measuredيتم قياس التباين في أداة الاستشعار الدوراني بمعدّل أخذ عينات يبلغ 1 هرتز، يجب ألا يزيد عن 1e-7 rad^2/s^2.
• [C-SR-2] يُنصح بشدة بأن يكون خطأ المعايرة أقل من 0.01 راديان/ثانية عندما يكون الجهاز ثابتًا في درجة حرارة الغرفة.
• [C-SR-3] ننصح بشدة بتنفيذ أداة الاستشعار TYPE_GYROSCOPE_UNCALIBRATED.
• [C-SR-4] يُنصح بشدة بدرجة دقة 16 بت أو أكثر.
• يجب أن تُبلغ عن الأحداث التي تصل إلى 200 هرتز على الأقل.

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

• [C-2-1] يجب تنفيذ أداة استشعار مركبة TYPE_ROTATION_VECTOR.

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

• [C-3-1] يجب تنفيذ أداتَي الاستشعار المركبتَين TYPE_GRAVITY و TYPE_LINEAR_ACCELERATION.
• [C-SR-5] يُنصح بشدة بتنفيذ أداة الاستشعار المركبة TYPE_GAME_ROTATION_VECTOR.

7.3.5. مقياس الضغط الجوي

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

• [C-SR-1] يُنصح بشدة بتضمين مقياس ضغط جوي (جهاز استشعار ضغط الهواء المحيط).

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

• [C-1-1] يجب تنفيذ TYPE_PRESSURE sensor والإبلاغ عنه.
• [C-1-2] يجب أن يكون الجهاز قادرًا على إرسال الأحداث بمعدّل 5 هرتز أو أكثر.
• [C-1-3] يجب أن يكون مُعدَّلاً للحرارة.
• [C-SR-2] يُنصح بشدة بإمكانية تسجيل قياسات الضغط في النطاق من 300hPa إلى 1100hPa.
• يجب أن تكون الدقة المطلقة 1hPa.
• يجب أن تكون الدقة النسبية 0.12hPa على نطاق 20hPa (أي ما يعادل دقة متر واحد تقريبًا على نطاق 200 متر تقريبًا على مستوى سطح البحر).

7.3.6. مقياس درجة الحرارة

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

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

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

• [C-2-1] يجب عدم تحديد SENSOR_TYPE_AMBIENT_TEMPERATURE لجهاز استشعار الحرارة.

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

• [C-SR-1] يُنصح بشدة بتوفُّر واجهة برمجة التطبيقات PowerManager.getThermalHeadroom.

7.3.7. مقياس الإضاءة

• قد تتضمّن عمليات تنفيذ الأجهزة مقياسًا للضوء (أداة استشعار الضوء المحيط).

7.3.8. أداة استشعار التقارب

• قد تتضمّن عمليات تنفيذ الأجهزة أداة استشعار التقارب.

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

• [C-1-1] يجب قياس مدى قرب الجسم من الشاشة في الاتجاه نفسه. وهذا يعني أنّه يجب توجيه أداة استشعار التقارب لرصد الأجسام بالقرب من الشاشة، لأنّ الغرض الأساسي من هذا النوع من أدوات الاستشعار هو رصد هاتف يستخدمه المستخدم. إذا كانت عمليات تنفيذ الأجهزة تتضمّن مستشعر قرب مع أي اتجاه آخر، يجب ألّا يكون بالإمكان الوصول إليه من خلال واجهة برمجة التطبيقات هذه.
• [C-1-2] يجب أن تكون الدقة 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/g على الأقل.
  • يجب أن يكون الحد الأدنى لعدد مرات القياس 12.5 هرتز أو أقل.
  • يجب أن يكون الحد الأقصى لعدد مرات القياس 400 هرتز أو أعلى، ويجب أن يكون متوافقًا مع SensorDirectChannel RATE_VERY_FAST.
  • يجب أن يكون التشويش في القياس أقل من 400 ميكروغرام/√هرتز.
  • يجب استخدام شكل غير نشط من هذا المستشعر مع ميزة معالجة مؤقتة لأحداث المستشعر التي لا تقل عن 3000 حدث.
  • يجب أن يكون استهلاك الطاقة في وضع التجميع أقل من 3 ملي واط.
  • [C-SR-1] يُنصح بشدة بتوفير نطاق قياس 3 ديسيبل لا يقل عن% 80 من تردد Nyquist، ويجب أن يكون نطاق الضوضاء البيضاء ضمن هذا النطاق.
  • يجب أن يكون هناك انحراف عشوائي للتسارع أقل من 30 μg √Hz تم اختباره عند درجة حرارة الغرفة.
  • من المفترض أن يكون هناك تغيير في الانحياز مقابل درجة الحرارة بمقدار ‎1 mg/°C ±/‎- أو أقل.
  • يجب أن يكون خط أفضل توافق غير خطي بنسبة ≤ 0.5%، ويجب أن يكون تغيير الحساسية مقارنةً بالحرارة ≤ 0.03%/درجة مئوية.
  • يجب أن تكون حساسية المحاور المتقاطعة أقل من % 2.5 وأن يكون التباين في حساسية المحاور المتقاطعة أقل من% 0.2 في نطاق درجة حرارة تشغيل الجهاز.

• [C-2-2] يجب أن يكون لدى TYPE_ACCELEROMETER_UNCALIBRATED متطلبات الجودة نفسها التي يتطلبها TYPE_ACCELEROMETER.

• [C-2-3] يجب أن يتضمّن جهازك أداة استشعار TYPE_GYROSCOPE تستوفي الشروط التالية:

  • يجب أن يكون نطاق القياس بين -1000 و1000 دورة في الثانية على الأقل.
  • يجب أن تكون دقة القياس 16 LSB/dps على الأقل.
  • يجب أن يكون الحد الأدنى لعدد مرات القياس 12.5 هرتز أو أقل.
  • يجب أن يكون الحد الأقصى لعدد مرات القياس 400 هرتز أو أعلى، ويجب أن يكون متوافقًا مع SensorDirectChannel RATE_VERY_FAST.
  • يجب أن يكون التشويش في القياس أقل من 0.014 درجة في الثانية لكل جذر هرتز.
  • [C-SR-2] يُنصح بشدة بتوفير نطاق قياس 3 ديسيبل لا يقل عن% 80 من تردد Nyquist، ويجب أن يكون نطاق قياس الضوضاء البيضاء ضمن هذا النطاق.
  • يجب أن يكون معدل التنقّل العشوائي أقل من 0.001 درجة/ثانية √هرتز عند اختباره في درجة حرارة الغرفة.
  • يجب أن يكون هناك تغيير في الانحياز مقارنةً بدرجة الحرارة لا يتجاوز ± 0.05 درجة / ثانية / درجة مئوية.
  • يجب أن يكون هناك تغيير في الحساسية مقارنةً بدرجة الحرارة بمقدار 0.02% / درجة مئوية كحد أقصى.
  • يجب أن يكون الخط الأنسب غير خطي بنسبة لا تزيد عن %0.2.
  • يجب أن تكون كثافة الضوضاء ≤ 0.007 درجة/ثانية/√هرتز.
  • يجب أن يكون خطأ المعايرة أقل من 0.002 راد/ثانية في نطاق درجة الحرارة من 10 إلى 40 درجة مئوية عندما يكون الجهاز ثابتًا.
  • يجب أن تكون حساسية التسارع أقل من 0.1 درجة في الثانية لكل متر في الثانية.
  • يجب أن تكون الحساسية على جميع المحاور أقل من % 4.0 وأن يكون التباين في الحساسية على جميع المحاور أقل من% 0.3 في نطاق درجة حرارة تشغيل الجهاز.

• [C-2-4] يجب أن يتضمّن TYPE_GYROSCOPE_UNCALIBRATED متطلبات الجودة نفسها التي يتضمّنها TYPE_GYROSCOPE.

• [C-2-5] يجب أن يكون الجهاز مزوّدًا بجهاز استشعار TYPE_GEOMAGNETIC_FIELD يستوفي الشروط التالية:

  • يجب أن يكون نطاق القياس بين -900 و+900 μT على الأقل.
  • يجب أن يكون دقة القياس 5 LSB/uT على الأقل.
  • يجب أن يكون الحد الأدنى لعدد مرات القياس 5 هرتز أو أقل.
  • يجب أن يكون الحد الأقصى لعدد مرات القياس 50 هرتز أو أعلى.
  • يجب أن يكون التشويش في القياس أقل من 0.5 ميكرو تسلا.

• [C-2-6] يجب أن يتضمّن TYPE_MAGNETIC_FIELD_UNCALIBRATED متطلبات الجودة نفسها التي يتضمّنها TYPE_GEOMAGNETIC_FIELD، بالإضافة إلى ما يلي:

  • يجب استخدام شكل غير مُشغِّل لهذا المستشعر مع ميزة معالجة مؤقتة لأحداث المستشعر التي لا تقل عن 600 حدث.
  • [C-SR-3] يُنصح بشدة بتوفير نطاق للضوضاء البيضاء من 1 هرتز إلى 10 هرتز على الأقل عندما يكون معدّل الإبلاغ 50 هرتز أو أعلى.

• [C-2-7] يجب أن يتضمّن جهاز TYPE_PRESSURE أداة استشعار تستوفي الشروط التالية:

  • يجب أن يكون نطاق القياس بين 300 و1100 hPa على الأقل.
  • يجب أن يكون دقة القياس 80 LSB/hPa على الأقل.
  • يجب أن يكون الحد الأدنى لعدد مرات القياس 1 هرتز أو أقل.
  • يجب أن يكون الحد الأقصى لعدد مرات القياس 10 هرتز أو أعلى.
  • يجب أن يكون التشويش في القياس أقل من 2 باسكال/√هرتز.
  • يجب استخدام شكل غير مُشغِّل لهذا المستشعر مع ميزة معالجة مؤقتة لأحداث المستشعر التي لا تقل عن 300 حدث.
  • يجب أن يكون استهلاك الطاقة في وضع "المعالجة المجمّعة" لا يزيد عن 2 ملي واط.

• [C-2-8] يجب أن يتضمّن جهازك أداة استشعار TYPE_GAME_ROTATION_VECTOR.

• [C-2-9] يجب أن يتضمّن جهازك أداة استشعار TYPE_SIGNIFICANT_MOTION تستوفي الشروط التالية:

  • يجب أن يكون استهلاك الطاقة أقل من 0.5 ملي واط عندما يكون الجهاز ثابتًا و1.5 ملي واط عندما يكون الجهاز متحركًا.

• [C-2-10] يجب أن يتضمّن جهازك أداة استشعار TYPE_STEP_DETECTOR تستوفي الشروط التالية:

  • يجب تنفيذ شكل غير مُشغِّل لهذا المستشعر مع ميزة معالجة مؤقتة لأحداث المستشعر التي لا تقل عن 100 حدث.
  • يجب أن يكون استهلاك الطاقة أقل من 0.5 ملي واط عندما يكون الجهاز ثابتًا و1.5 ملي واط عندما يكون الجهاز متحركًا.
  • يجب أن يكون استهلاك الطاقة في وضع "المعالجة المجمّعة" لا يزيد عن 4 ملي واط.

• [C-2-11] يجب أن يكون الجهاز مزوّدًا بجهاز استشعار TYPE_STEP_COUNTER يستوفي الشروط التالية:

  • يجب أن يكون استهلاك الطاقة أقل من 0.5 ملي واط عندما يكون الجهاز ثابتًا و1.5 ملي واط عندما يكون الجهاز متحركًا.

• [C-2-12] يجب أن يتضمّن جهاز TILT_DETECTOR أداة استشعار تستوفي الشروط التالية:

  • يجب أن يكون استهلاك الطاقة أقل من 0.5 ملي واط عندما يكون الجهاز ثابتًا و1.5 ملي واط عندما يكون الجهاز متحركًا.

• [C-2-13] يجب أن يكون الطابع الزمني للحدث نفسه الذي يُبلغ عنه كل من قياس التسارع والجيروسكوب والمقياس المغناطيسي ضمن 2.5 ملي ثانية من بعضها. يجب أن يكون الطابع الزمني للحدث المادي نفسه الذي يُبلغ عنه كل من accelerometer وgyroscope ضمن 0.25 ملي ثانية من بعضهم.

• [C-2-14] يجب أن تتضمّن الطوابع الزمنية لأحداث أداة استشعار الدوران قاعدة زمنية مماثلة لقاعدة الوقت في النظام الفرعي للكاميرا ويجب ألا يتجاوز الخطأ ملي ثانية واحدة.

• [C-2-15] يجب إرسال عيّنات إلى التطبيقات في غضون 5 مللي ثانية من الوقت الذي تتوفّر فيه البيانات على أي من أجهزة الاستشعار البدنية المذكورة أعلاه إلى التطبيق.

• [C-2-16] يجب ألا يتجاوز استهلاك الطاقة 0.5 ملي واط عندما يكون الجهاز ثابتًا و2.0 ملي واط عندما يكون الجهاز متحركًا عند تفعيل أي مجموعة من أجهزة الاستشعار التالية:

  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS

• [C-2-17] يجوز أن يتضمّن جهاز التحكّم في السرعة TYPE_PROXIMITY، ولكن في حال توفّره، يجب أن يكون لديه حد أدنى لسعة المخزن المؤقت يبلغ 100 حدث حسّاس.

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

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

• [C-3-1] يجب أن يُعلن التطبيق بشكل صحيح عن توفّر أنواع القنوات المباشرة ومستوى تقارير معدلات التحويل المباشرة من خلال واجهتَي برمجة التطبيقات isDirectChannelTypeSupported وgetHighestDirectReportRateLevel.
• [C-3-2] يجب أن يكون متوافقًا مع نوع واحد على الأقل من نوعَي قناة الاستشعار المباشر لجميع أدوات الاستشعار التي تعلن عن توافقها مع قناة الاستشعار المباشر.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• يجب أن تتيح أداة الاستشعار إعداد تقارير الأحداث من خلال قناة الاستشعار المباشرة لأداة الاستشعار الأساسية (الصيغة غير المخصّصة للتنشيط) من الأنواع التالية:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. أجهزة الاستشعار الحيوية

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

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

• يجب أن يتضمّن جهاز استشعار حيويًا

يمكن تصنيف أدوات الاستشعار الحيوية على أنّها من الفئة 3 (المعروفة سابقًا باسم قوية)، الفئة 2 (المعروفة سابقًا باسم ضعيفة)، أو الفئة 1 (المعروفة سابقًا باسم سهلة الاستخدام) استنادًا إلى معدّلات قبول عمليات التزوير والتزييف، وإلى أمان مسار المعالجة المتعلّق بالمقاييس الحيوية. يحدِّد هذا التصنيف إمكانات المستشعر البيومتري للتفاعل مع المنصة وتطبيقات الجهات الخارجية. يتم تصنيف أجهزة الاستشعار على أنّها من الفئة 1 تلقائيًا، ويجب أن تستوفي متطلبات إضافية كما هو موضّح أدناه إذا أرادت أن يتم تصنيفها على أنّها من الفئة 2 أو الفئة 3. تحصل ميزات الفئة 2 والفئة 3 البيومترية على إمكانات إضافية كما هو موضّح أدناه.

إذا كانت عمليات تنفيذ الأجهزة تتيح أداة استشعار حيوية لتطبيقات تابعة لجهات خارجية من خلال android.hardware.biometrics.BiometricManager، android.hardware.biometrics.BiometricPrompt، وandroid.provider.Settings.ACTION_BIOMETRIC_ENROLL، يجب أن تستوفي التطبيقات المتطلبات التالية:

• [C-4-1] يجب أن تستوفي متطلبات المقاييس الحيوية من الفئة 3 أو الفئة 2 كما هو محدّد في هذا المستند.
• [C-4-2] يجب التعرّف على كل اسم مَعلمة محدّد على أنّه ثابت في فئة المصادقين وأي مجموعات منه والامتثال له. في المقابل، يجب عدم الامتثال أو التعرّف على الثوابت الصحيحة التي يتم تمريرها إلى الأسلوبين canAuthenticate(int) وsetAllowedAuthenticators(int) بخلاف تلك التي تم توثيقها كثوابت عامة في Authenticators وأي مجموعات منها.
• [C-4-3] يجب تنفيذ الإجراء ACTION_BIOMETRIC_ENROLL على الأجهزة التي تتضمّن مقاييس حيوية من الفئة 3 أو الفئة 2. يجب أن يقدّم هذا الإجراء نقاط دخول التسجيل فقط لتقنيات الفئة 3 أو الفئة 2 البيومترية.

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

• [C-5-1] يجب أن تتطلّب تلقائيًا خطوة تأكيد إضافية (مثل الضغط على زر).
• [C-SR-1] يُنصح بشدة بتوفير إعداد للسماح للمستخدمين بتجاوز الإعدادات المفضّلة للتطبيق وفرض خطوة تأكيد مصاحبة دائمًا.
• [C-SR-2] يُنصح بشدة بتأمين إجراء التأكيد بحيث لا يمكن لخداع نظام التشغيل أو نواة النظام. على سبيل المثال، يعني ذلك أنّ إجراء التأكيد المستنِد إلى زرّ مادي يتم توجيهه من خلال دبوس إدخال/إخراج (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-4] يجب منع إضافة مقاييس حيوية جديدة بدون إنشاء سلسلسة ثقة أولاً من خلال مطالبة المستخدم بتأكيد بيانات اعتماد الجهاز الحالية أو إضافة بيانات اعتماد جديدة (رقم التعريف الشخصي أو النمط أو كلمة المرور) التي تم تأمينها من خلال TEE، ويوفّر تنفيذ مشروع Android Open sourced في إطار العمل آلية للقيام بذلك.
• [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 ساعة أو أقل للأجهزة التي يتم ترقيتها من الإصدار 8 من Android أو الإصدارات الأقدم.

• [C-1-8] يجب أن يطلب الجهاز من المستخدم إثبات هويته باستخدام المصادقة الأساسية المُقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) أو المقاييس الحيوية من الفئة 3 (قوية) بعد حدوث أحد الإجراءَين التاليَين:

  • مهلة عدم النشاط لمدة 4 ساعات

  • 3 محاولات مصادقة بالمقاييس الحيوية غير ناجحة

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

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

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

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

• [C-2-1] يجب استيفاء جميع متطلبات الفئة 1 أعلاه.
• [C-2-2] يجب ألا يزيد معدّل قبول عمليات التزوير والتصيّد الاحتيالي عن %20، كما يتم قياسه من خلال بروتوكولات اختبار المقاييس الحيوية في Android.
• [C-2-3] يجب تنفيذ عملية المطابقة البيومترية في بيئة تنفيذ معزولة خارج مساحة مستخدم Android أو مساحة نظام التشغيل، مثل بيئة التنفيذ الموثوقة (TEE)، أو على شريحة تتضمّن قناة آمنة تؤدي إلى بيئة التنفيذ المعزولة.
• [C-2-4] يجب أن تكون جميع البيانات التعريفية مشفّرة ومصادق عليها cryptographically بحيث لا يمكن الحصول عليها أو قراءتها أو تغييرها خارج بيئة التنفيذ المعزولة أو شريحة تتضمّن قناة آمنة تؤدي إلى بيئة التنفيذ المعزولة كما هو موضّح في إرشادات التنفيذ على الموقع الإلكتروني لمشروع Android Open Source Project.
• [C-2-5] بالنسبة إلى المقاييس الحيوية المستندة إلى الكاميرا، أثناء المصادقة أو التسجيل المستندَين إلى المقاييس الحيوية:
  • يجب تشغيل الكاميرا في وضع يمنع قراءة إطارات الكاميرا أو تغييرها خارج بيئة التنفيذ المعزولة أو شريحة تتضمّن قناة آمنة تؤدي إلى بيئة التنفيذ المعزولة.
  • بالنسبة إلى حلول الكاميرا الواحدة ذات الإضاءة الساطعة (RGB)، يمكن قراءة إطارات الكاميرا خارج بيئة التنفيذ المعزولة لدعم العمليات، مثل المعاينة للتسجيل، ولكن يجب ألّا تكون قابلة للتغيير.
• [C-2-6] يجب عدم السماح للتطبيقات التابعة لجهات خارجية بالتمييز بين عمليات التسجيل البيومتري الفردية.
• [C-2-7] يجب عدم السماح بالوصول غير المشفَّر إلى بيانات قياس البصمات الحيوية القابلة للتحديد أو أي بيانات مشتقة منها (مثل البيانات المضمَّنة) إلى معالج التطبيقات خارج سياق وحدة TEE. لا يتم استثناء الأجهزة التي تم ترقيتها وكانت تعمل بالإصدار 9 من Android أو الإصدارات الأقدم من القاعدة C-2-7.

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

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

• [C-2-9] يجب إتاحة أداة الاستشعار الحيوية للتطبيقات التابعة لجهات خارجية.

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

• يجب أن يستوفي [C-3-1] جميع متطلبات الفئة 2 أعلاه، باستثناء [C-1-7] و[C-1-8].
• [C-3-2] يجب أن يكون هناك تطبيق لمستودع مفاتيح مستند إلى الأجهزة.
• [C-3-3] يجب ألا يزيد معدّل قبول عمليات التزوير والتصيّد الاحتيالي عن %7، كما يتم قياسه من خلال بروتوكولات اختبار المقاييس الحيوية في Android.
• [C-3-4] يجب أن يطلب الجهاز من المستخدم إثبات هويته باستخدام طريقة المصادقة الأساسية المُقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) مرة واحدة كل 72 ساعة أو أقل.
• [C-3-5] يجب إعادة إنشاء معرّف المصادقة لجميع ميزات المقاييس الحيوية من الفئة 3 المتوافقة على الجهاز في حال إعادة تسجيل أي منها.
• [C-3-6] يجب تفعيل مفاتيح ملف تخزين المفاتيح المستندة إلى المقاييس الحيوية لتطبيقات الجهات الخارجية.

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

• [C-SR-11] يُنصح بشدة بمنع المنطقة القابلة للمس في UDFPS من التدخل في التنقّل باستخدام 3 أزرار (الذي قد يحتاجه بعض المستخدمين لأغراض تسهيل الاستخدام).

7.3.12. أداة استشعار الوضعية

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

• قد تتيح استخدام أداة استشعار الوضع بـ 6 درجات من الحرية.

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

• [C-1-1] يجب تنفيذ TYPE_POSE_6DOF جهاز الاستشعار والإبلاغ عنه.
• [C-1-2] يجب أن تكون أكثر دقة من متجه الدوران وحده.

7.3.13. أداة استشعار زاوية المفصل

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

• [C-1-1] يجب تنفيذ TYPE_HINGLE_ANGLE والإبلاغ عنه.
• [C-1-2] يجب أن يتيح الجهاز قراءة قراءتَين على الأقل بين 0 و360 درجة (بما في ذلك 0 و360 درجة).
• [C-1-3] يجب عرض مستشعر للتنشيط getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

7.4. إمكانية الوصول إلى البيانات

7.4.1. الاتصالات الهاتفية

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

إذا لم تضبط عمليات تنفيذ الأجهزة سمة النظام ro.telephony.iwlan\_operation\_mode على "قديم"، فإنّها:

• [C-4-1] يجب عدم الإبلاغ عن NETWORK_TYPE_IWLAN من خلال NetworkRegistrationInfo#getAccessNetworkTechnology() عندما يتم الإبلاغ عن NetworkRegistrationInfo#getTransportType() على أنّه TRANSPORT_TYPE_WWAN لنسخة NetworkRegistrationInfo نفسها.

إذا كانت عمليات تنفيذ الأجهزة تتيح تسجيلًا واحدًا لنظام IP Multimedia Subsystem (IMS) لكل من خدمة الهاتف الجوّال للوسائط المتعددة (MMTEL) وميزات خدمة الاتصالات التفاعلية (RCS) ومن المتوقّع أن تمتثل لمتطلبات مشغّل شبكة الجوّال في ما يتعلّق باستخدام تسجيل واحد لنظام IMS لجميع عمليات إرسال الإشارات في IMS، يجب أن تستوفي الأجهزة المتطلبات التالية:

• [C-5-1] يجب الإفصاح عن علامة ميزة android.hardware.telephony.ims وتوفير تنفيذ كامل لواجهة برمجة التطبيقات ImsService API لكل من MMTEL وUser Capability Exchange API لخدمات RCS.
• [C-5-2] يجب الإفصاح عن android.hardware.telephony.ims.singlereg علامة الميزة وتوفير تنفيذ كامل لواجهة برمجة التطبيقات SipTransport API، وGbaService API، ومؤشرات حامل البيانات المخصّصة باستخدام IRadio 1.6 HAL، وإعداد التطبيق من خلال خادم الإعداد التلقائي (ACS) أو آلية إعداد أخرى مملوكة باستخدام IMS Configuration API.

7.4.1.1. توافق حظر الأرقام

إذا أبلغت عمليات تنفيذ الأجهزة عن android.hardware.telephony feature، يعني ذلك ما يلي:

• [C-1-1] يجب أن تتضمّن ميزة حظر الأرقام
• [C-1-2] يجب تنفيذ BlockedNumberContract وواجهة برمجة التطبيقات المقابلة لها بالكامل على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK).
• [C-1-3] يجب حظر جميع المكالمات والرسائل الواردة من رقم هاتف في ملف "موفِّر الأرقام المحظورة" بدون أي تفاعل مع التطبيقات. ويتمثل الاستثناء الوحيد في رفع حظر الأرقام مؤقتًا كما هو موضّح في مستندات SDK.
• [C-1-4] يجب عدم الكتابة إلى مقدّم سجلّ المكالمات في النظام الأساسي لطلب مكالمة محظورة.
• [C-1-5] يجب عدم الكتابة إلى مقدّم خدمة الاتصال الهاتفي بشأن رسالة محظورة.
• [C-1-6] يجب تنفيذ واجهة مستخدم لإدارة الأرقام المحظورة، والتي يتم فتحها باستخدام النية التي تعرضها طريقة TelecomManager.createManageBlockedNumbersIntent().
• [C-1-7] يجب عدم السماح للمستخدمين الثانويين بالاطّلاع على الأرقام المحظورة أو تعديلها على الجهاز لأنّ نظام Android يفترض أنّ المستخدم الأساسي لديه إمكانية التحكّم الكامل في خدمات الهاتف، وهي نسخة واحدة على الجهاز. يجب أن تكون كل واجهة مستخدم مرتبطة بحظر المحتوى مخفية للمستخدمين الثانويين، ويجب أن تظل القائمة المحظورة مفعّلة.
• من المفترض نقل الأرقام المحظورة إلى مقدّم الخدمة عند تحديث أحد الأجهزة إلى Android 7.0.

7.4.1.2. Telecom API

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

• [C-1-1] يجب أن تتوافق مع واجهات برمجة تطبيقات ConnectionService الموضّحة في حزمة تطوير البرامج (SDK).
• [C-1-2] يجب عرض مكالمة واردة جديدة وتوفير إمكانات للمستخدم لقبول المكالمة الواردة أو رفضها عندما يكون المستخدم في مكالمة جارية يجريها تطبيق تابع لجهة خارجية لا يتيح ميزة الانتظار المحدّدة من خلال CAPABILITY_SUPPORT_HOLD.
• [C-1-3] يجب أن يتضمّن التطبيق فئة برمجة التطبيقات InCallService.

• [C-SR-1] يُنصح بشدة بإعلام المستخدم بأنّ الردّ على مكالمة واردة سيؤدي إلى إنهاء مكالمة حالية.

  يستوفي تنفيذ AOSP هذه المتطلبات من خلال إشعار تنبيه يشير إلى المستخدم بأنّ الردّ على مكالمة واردة سيؤدي إلى إنهاء المكالمة الأخرى.

• [C-SR-1] يُنصح بشدة بتثبيت تطبيق الاتصال التلقائي الذي يعرض إدخال سجلّ المكالمات واسم تطبيق تابع لجهة خارجية في سجلّ المكالمات، وذلك عندما يضبط التطبيق التابع لجهة خارجية مفتاح EXTRA_LOG_SELF_MANAGED_CALLS الإضافات على PhoneAccount إلى true.

• [C-SR-2] يُنصح بشدة بمعالجة حدثَي KEYCODE_MEDIA_PLAY_PAUSE وKEYCODE_HEADSETHOOK لسماعات الرأس الصوتية في واجهات برمجة التطبيقات android.telecom على النحو التالي:

  • اتصل بالرقم Connection.onDisconnect() عند رصد ضغطة قصيرة على الحدث الرئيسي أثناء مكالمة جارية.
  • اتصل بالرقم Connection.onAnswer() عند رصد ضغطة قصيرة على الحدث الرئيسي أثناء مكالمة واردة.
  • اتصل بالرقم Connection.onReject() عند رصد الضغط مع الاستمرار على الحدث الرئيسي أثناء مكالمة واردة.
  • فعِّل أو أوقِف ميزة كتم الصوت في CallAudioState.

7.4.2. معيار IEEE 802.11 (لشبكات Wi-Fi)

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

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

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

• [C-1-1] يجب تنفيذ واجهة برمجة تطبيقات Android المقابلة.
• [C-1-2] يجب الإبلاغ عن علامة ميزة الجهاز android.hardware.wifi.
• [C-1-3] يجب تنفيذ واجهة برمجة التطبيقات لبث الوسائط المتعدّدة على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK).
• [C-1-4] يجب أن يكون متوافقًا مع نظام أسماء النطاقات ذي البث المتعدد (mDNS) ويجب عدم فلترة حزم mDNS (224.0.0.251) في أي وقت من التشغيل، بما في ذلك:
  • حتى عندما تكون الشاشة غير نشطة
  • لعمليات تنفيذ أجهزة Android Television، حتى في حالات وضع الاستعداد حالات الطاقة
• [C-1-5] يجب عدم التعامل مع طلب بيانات واجهة برمجة التطبيقات WifiManager.enableNetwork() كإشارة كافية لتبديلNetwork النشط حاليًا والذي يتم استخدامه تلقائيًا للزيارات الواردة إلى التطبيق ويتم إرجاعه بواسطة طرق واجهة برمجة التطبيقات ConnectivityManager مثل getActiveNetwork وregisterDefaultNetworkCallback. بعبارة أخرى، يجوز لهم إيقاف إمكانية الوصول إلى الإنترنت المقدَّمة من أي مزوّد شبكة آخر (مثل بيانات الجوّال) فقط إذا تم التحقّق بنجاح من أنّ شبكة Wi-Fi توفّر إمكانية الوصول إلى الإنترنت.
• [C-1-6] يُنصح بشدة بإعادة تقييم إمكانية الوصول إلى الإنترنت على Network عند استدعاء ConnectivityManager.reportNetworkConnectivity() طريقة واجهة برمجة التطبيقات، وبالتبديل إلى أي شبكة أخرى متاحة (مثل بيانات الشبكة اللاسلكية للأجهزة الجوّالة) تتيح الوصول إلى الإنترنت بعد أن يحدِّد التقييم أنّ 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 لبروتوكول Passpoint) يتواصل معه.
  • يجب أن يقدّم الجهاز للمستخدم خيارًا للتحكّم في عملية التبديل العمياء لكل معرّف SSID (FQDN لبروتوكول Passpoint) من خلال خيارات غير عشوائية وأخرى عشوائية، ويجب ضبط الوضع التلقائي لعمليات ضبط Wi-Fi الجديدة على أن تكون عشوائية.
• [C-SR-2] ننصح بشدة باستخدام معرّف BSSID عشوائي لأي نقطة اتصال يتم إنشاؤها.
  • يجب أن يكون عنوان MAC عشوائيًا ومستمرًا لكل SSID يستخدمه العميل.
  • يجوز للجهاز أن يقدّم للمستخدم خيارًا لإيقاف هذه الميزة. في حال توفّر هذا الخيار، يجب تفعيل وضع "العرض العشوائي" تلقائيًا.

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

• يجب إيقاف وضع "توفير الطاقة في Wi-Fi" عندما يحصل تطبيق على قفل WIFI_MODE_FULL_HIGH_PERF أو قفل WIFI_MODE_FULL_LOW_LATENCY من خلال واجهات برمجة التطبيقات WifiManager.createWifiLock() وWifiManager.WifiLock.acquire() ويكون القفل مفعّلاً.
• [C-3-2] يجب أن يكون متوسّط وقت الاستجابة لرحلة الذهاب والعودة بين الجهاز ونقطة وصول أثناء تشغيل الجهاز في وضع "قفل وقت الاستجابة المنخفض لشبكة Wi-Fi" (WIFI_MODE_FULL_LOW_LATENCY) أقصر من وقت الاستجابة أثناء تشغيل الجهاز في وضع "قفل الأداء العالي لشبكة Wi-Fi" (WIFI_MODE_FULL_HIGH_PERF).
• [C-SR-3] ننصح بشدة بتقليل وقت استجابة جولة Wi-Fi بالكامل عند الحصول على قفل وقت الاستجابة المنخفض (WIFI_MODE_FULL_LOW_LATENCY) وبدء تطبيقه.

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

• [C-2-1] يجب توفير عنصر تحكم للمستخدم لتفعيل/إيقاف قراءة القيمة من خلال طريقة واجهة برمجة التطبيقات WifiManager.isScanAlwaysAvailable.

7.4.2.1. اتصال Wi-Fi مباشر

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

• يجب أن تتضمّن تقنية Wi-Fi Direct (الاتصال المباشر عبر Wi-Fi).

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

• [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 وتم تفعيله من خلال واجهة برمجة التطبيقات WiFiManager API، يتم تنفيذ ما يلي:

• [C-1-1] يجب الإفصاح عن توفّر بروتوكول TDLS من خلال WifiManager.isTdlsSupported.
• يجب استخدام بروتوكول TDLS فقط عندما يكون ذلك ممكنًا ومفيدًا.
• يجب أن يتضمّن بعض الأساليب الاستقرائية وألا يستخدم بروتوكول TDLS عندما يكون أداؤه أسوأ من استخدام نقطة وصول Wi-Fi.

7.4.2.3. Wi-Fi Aware

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

• يجب أن تتضمّن ميزة Wi-Fi Aware.

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

• [C-1-1] يجب تنفيذ واجهات برمجة تطبيقات WifiAwareManager على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK).
• [C-1-2] يجب الإفصاح عن علامة ميزة android.hardware.wifi.aware.
• [C-1-3] يجب أن يكون متوافقًا مع عمليات Wi-Fi وWi-Fi Aware في الوقت نفسه.
• [C-1-4] يجب إنشاء عنوان واجهة إدارة Wi-Fi Aware بشكل عشوائي على فترات زمنية لا تزيد عن 30 دقيقة وكلما تم تفعيل Wi-Fi Aware ما لم تكن عملية الاستكشاف قيد التنفيذ أو كان مسار بيانات Aware نشطًا (لا يُتوقّع استخدام الإنشاء العشوائي طيلة فترة نشاط مسار البيانات).

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

• [C-2-1] يجب تنفيذ واجهات برمجة تطبيقات الاستكشاف المستندة إلى الموقع الجغرافي: setRangingEnabled، setMinDistanceMm، setMaxDistanceMm ، و onServiceDiscoveredWithinRange.

7.4.2.4. Wi-Fi Passpoint

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

• يجب أن تتضمّن ميزة Wi-Fi Passpoint.

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

• [C-1-2] يجب تنفيذ واجهات برمجة التطبيقات WifiManager ذات الصلة ببرنامج Passpoint كما هو описан في مستندات حزمة تطوير البرامج (SDK).
• [C-1-3] يجب أن يكون متوافقًا مع معيار IEEE 802.11u، خاصةً ما يتعلق باكتشاف الشبكة واختيارها، مثل خدمة الإعلانات الشاملة (GAS) وبروتوكول طلب شبكة الوصول (ANQP).
• [C-1-4] يجب الإفصاح عن علامة ميزة android.hardware.wifi.passpoint.
• [C-1-5] يجب اتّباع عملية التنفيذ في AOSP للتعرّف على شبكات Passpoint ومطابقتها وربطها بها.
• [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] يجب أن تظل إعدادات Passpoint ثابتة عند إعادة التشغيل.
• [C-SR-1] يُنصح بشدة بتفعيل ميزة قبول الأحكام والشروط.
• [C-SR-2] يُنصح بشدة بتوفير ميزة "معلومات عن المكان".

في المقابل، إذا كانت عمليات تنفيذ الأجهزة لا تتضمّن إتاحة Wi-Fi Passpoint:

• [C-2-1] يجب أن يؤدي تنفيذ WifiManager واجهات برمجة التطبيقات ذات الصلة بنقطة المرور إلى طرح UnsupportedOperationException.

في حال توفُّر مفتاح تحكّم عام في إيقاف Passpoint، يتم تنفيذ ما يلي:

• [C-3-1] يجب تفعيل Passpoint تلقائيًا.

7.4.2.5. الموقع الجغرافي لشبكة Wi-Fi (مدّة الرحلة ذهابًا وإيابًا لشبكة Wi-Fi)

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

• يجب أن تتضمّن ميزة تحديد الموقع الجغرافي من خلال شبكة Wi-Fi.

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

• [C-1-1] يجب تنفيذ واجهات برمجة تطبيقات WifiRttManager على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK).
• [C-1-2] يجب الإفصاح عن علامة ميزة android.hardware.wifi.rtt.
• [C-1-3] يجب اختيار عنوان MAC المصدر بشكل عشوائي لكل رشقة RTT التي يتم تنفيذها عندما لا تكون واجهة Wi-Fi التي يتم تنفيذ RTT عليها مرتبطة بنقطة وصول.
• [C-1-4] يجب أن تكون الدقة ضمن مترَين عند عرض النطاق البالغ 80 ميغاهرتز في المعدل المئوي 68 (كما يتم احتسابه باستخدام دالة التوزيع المتراكم).

7.4.2.6. نقل بيانات ميزة "إبقاء الاتصال بالإنترنت" في 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.7. Wi-Fi Easy Connect (بروتوكول توفير الأجهزة)

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

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

7.4.3. البلوتوث

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

• يجب أن تكون متوافقة مع برامج ترميز الصوت المتقدّمة وبرامج ترميز صوت البلوتوث (مثل LDAC).

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

• يجب أن يكون متوافقًا مع 5 أجهزة متصلة على الأقل.

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

• [C-1-1] يجب أن يكون الجهاز متوافقًا مع معيارَي Bluetooth 4.2 وBluetooth LE Data Length Extension.

يتيح نظام Android استخدام البلوتوث والبلوتوث المنخفض الطاقة.

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

• [C-2-1] يجب الإفصاح عن ميزات المنصة ذات الصلة (android.hardware.bluetooth وandroid.hardware.bluetooth_le على التوالي) وتنفيذ واجهات برمجة تطبيقات المنصة.
• يجب تنفيذ الملفات الشخصية ذات الصلة بالبلوتوث، مثل A2DP وAVRCP وOBEX وHFP وما إلى ذلك، حسبما يناسب الجهاز.

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

• [C-3-1] يجب الإفصاح عن ميزة الجهاز android.hardware.bluetooth_le.
• [C-3-2] يجب تفعيل واجهات برمجة التطبيقات (API) لتقنية Bluetooth المستندة إلى GATT (ملف الخصائص العام) على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK) وandroid.bluetooth.
• [C-3-3] يجب الإبلاغ عن القيمة الصحيحة لسمة BluetoothAdapter.isOffloadedFilteringSupported() للإشارة إلى ما إذا تم تنفيذ منطق filtering لصفوف واجهة برمجة التطبيقات ScanFilter.
• [C-3-4] يجب الإبلاغ عن القيمة الصحيحة لسمة BluetoothAdapter.isMultipleAdvertisementSupported() للإشارة إلى ما إذا كان الإعلان المنخفض الطاقة متوافقًا.
• [C-3-5] يجب تنفيذ مهلة لعنوان RPA لا تزيد عن 15 دقيقة وتبديل العنوان عند انتهاء المهلة لحماية خصوصية المستخدم عندما يستخدم الجهاز تقنية BLE بشكل نشط للبحث أو الإعلان. لمنع هجمات التوقيت، يجب أيضًا اختيار الفواصل الزمنية للمهلة بشكل عشوائي بين 5 و15 دقيقة.
• يجب أن تتيح تفريغ منطق الفلترة إلى مجموعة شرائح البلوتوث عند تنفيذ واجهة برمجة التطبيقات ScanFilter API.
• يجب أن تتيح ميزة "البحث المجمّع" نقل البيانات إلى مجموعة شرائح البلوتوث.
• يجب أن تتيح عرض إعلانات متعددة مع 4 خانات على الأقل.

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

• [C-4-1] يجب توفير عنصر تحكم للمستخدم لتفعيل/إيقاف القيمة التي يتم قراءتها من خلال System API BluetoothAdapter.isBleScanAlwaysAvailable().

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

• [C-5-1] يجب عرض القيمة true لصيغة BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).

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

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

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

• [C-6-2] يجب حظر الوصول إلى البلوتوث من خلال android.permission.ACCESS_FINE_LOCATION.

7.4.4. تقنية الاتصال القصير المدى

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

• يجب أن يتضمّن جهاز إرسال واستقبال والأجهزة ذات الصلة للاتصال القصير المدى (NFC).
• [C-0-1] يجب تنفيذ واجهات برمجة التطبيقات android.nfc.NdefMessage و android.nfc.NdefRecord حتى إذا لم تتضمّن إتاحة استخدام NFC أو إعلان ميزة android.hardware.nfc لأنّ الفئات تمثّل تنسيقًا لتمثيل البيانات لا يعتمد على البروتوكول.

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

• [C-1-1] يجب الإبلاغ عن الميزة android.hardware.nfc من خلال طريقة android.content.pm.PackageManager.hasSystemFeature().
• يجب أن يكون الجهاز قادرًا على قراءة رسائل NDEF وكتابتها من خلال معايير NFC التالية كما هو موضّح أدناه:
• [C-1-2] يجب أن يكون الجهاز قادرًا على العمل كقارئ/كاتب في NFC Forum (على النحو المحدّد في المواصفة الفنية لـ NFC Forum 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

• [C-SR-1] يُنصح بشدة بأن يكون الجهاز قادرًا على قراءة رسائل NDEF وكتابتها بالإضافة إلى البيانات الأولية من خلال معايير NFC التالية. يُرجى العلم أنّه على الرغم من أنّ معايير NFC مُدرجة على أنّها "مُستحسَنة بشدة"، من المخطّط أن يتم تغيير هذه المعايير في ملف تعريف التوافق لإصدار مستقبلي ليصبح "يجب". هذه المعايير اختيارية في هذا الإصدار، ولكنها ستكون مطلوبة في الإصدارات المستقبلية. ننصح بشدة بتلبية هذه المتطلبات الآن على الأجهزة الحالية والجديدة التي تعمل بهذا الإصدار من Android حتى تتمكّن من الترقية إلى إصدارات المنصة المستقبلية.

• [C-1-13] يجب إجراء استطلاع لجميع التكنولوجيات المتوافقة أثناء استخدام وضع اكتشاف NFC.

• يجب أن يكون الجهاز في وضع اكتشاف NFC عندما يكون مفعَّلاً وبشاشة نشطة وشاشة القفل مفتوحة.

• يجب أن يكون الجهاز قادرًا على قراءة الرمز الشريطي وعنوان URL (إذا كان مُرمّزًا) لمنتجات الرمز الشريطي NFC المُدمَج في فيلم رقيق.

يُرجى العلم أنّ الروابط المتاحة للجميع غير متاحة لمواصفات JIS وISO وNFC Forum المذكورة أعلاه.

يتيح نظام Android وضع "محاكاة البطاقة المضيفة" (HCE) عبر NFC.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مجموعة شرائح تحكّم في NFC قادرة على استخدام تقنية HCE (لبروتوكول NfcA و/أو NfcB) وتتوافق مع توجيه معرّف التطبيق (AID)، يجب استيفاء الشروط التالية:

• [C-2-1] يجب الإبلاغ عن ثابت الميزة android.hardware.nfc.hce.
• [C-2-2] يجب أن تكون متوافقة مع واجهات برمجة تطبيقات NFC HCE كما هو описан في حزمة SDK لنظام التشغيل Android.

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

• [C-3-1] يجب الإبلاغ عن ثابت الميزة android.hardware.nfc.hcef.
• [C-3-2] يجب تنفيذ واجهات برمجة تطبيقات محاكاة بطاقات 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 وEthernet وBluetooth PAN.
• يجب أن يتضمّن أيضًا معيارًا واحدًا على الأقل لتكنولوجيات نقل البيانات اللاسلكية الشائعة، مثل 802.11 (Wi-Fi)، عندما يكون معيار الشبكة المادية (مثل تكنولوجيات نقل البيانات اللاسلكية) هو اتصال البيانات الأساسي.
• يجوز تنفيذ أكثر من شكل واحد للربط بالبيانات.

7.4.5.2. بروتوكول IPv6

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

• [C-0-2] يجب أن تتضمّن حِزمة شبكة IPv6 وأن تتيح مشاركة IPv6 باستخدام واجهات برمجة التطبيقات المُدارة، مثل java.net.Socket و java.net.URLConnection، بالإضافة إلى واجهات برمجة التطبيقات الأصلية، مثل AF_INET6 مقابس التوصيل.
• [C-0-3] يجب تفعيل بروتوكول IPv6 تلقائيًا.
  • يجب التأكّد من أنّ اتصالات IPv6 موثوقة مثل اتصالات IPv4، على سبيل المثال:
    • [C-0-4] يجب الحفاظ على إمكانية الاتصال بشبكة IPv6 في وضع السكون.
    • [C-0-5] يجب ألّا يؤدي الحدّ من معدّل الإرسال إلى فقدان الجهاز لإمكانية الاتصال عبر IPv6 على أي شبكة متوافقة مع IPv6 تستخدم مدد صلاحية RA تبلغ 180 ثانية على الأقل.
• [C-0-6] يجب أن توفّر التطبيقات التابعة لجهات خارجية إمكانية اتصال IPv6 المباشر بالشبكة عند الاتصال بشبكة IPv6، بدون أي شكل من أشكال ترجمة العناوين أو منافذ على الجهاز. يجب أن تعرض كلّ من واجهات برمجة التطبيقات المُدارة، مثل Socket#getLocalAddress أو Socket#getLocalPort) وواجهات برمجة التطبيقات في NDK، مثل getsockname() أو IPV6_PKTINFO، عنوان IP والمنفذ المستخدَمين فعليًا لإرسال الحِزم واستلامها على الشبكة، ويجب أن يظهرا كعنوان IP المصدر والمنفذ لخوادم الإنترنت (الويب).

يعتمد المستوى المطلوب من توافق IPv6 على نوع الشبكة، كما هو موضّح في المتطلبات التالية.

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

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

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

• [C-2-1] يجب أن يكون الجهاز متوافقًا مع الحزمة المزدوجة وIPv6 فقط على فاقتضاد برمجي ‎Ethernet.

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

• [C-3-1] يجب أن يكون الجهاز متوافقًا مع بروتوكول IPv6 (IPv6 فقط أو ربما الإصدار المزدوج) على شبكة الجيل الثالث أو الجيل الرابع.

إذا كانت عمليات تنفيذ الأجهزة متوافقة مع أكثر من نوع شبكة واحد (مثل Wi-Fi وبيانات شبكة الجوّال)، اتّبِع الخطوات التالية:

• [C-4-1] يجب استيفاء المتطلبات المذكورة أعلاه في كل شبكة في الوقت نفسه عندما يكون الجهاز متصلاً في الوقت نفسه بأكثر من نوع شبكة واحد.

7.4.5.3. المداخل المشروط الوصول إليها

يشير مدخل الشبكة المشروط الوصول إليها إلى شبكة تتطلب تسجيل الدخول من أجل الوصول إلى الإنترنت.

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

• [C-1-1] يجب توفير تطبيق بوابة إلكترونية لمعالجة الطلب ACTION_CAPTIVE_PORTAL_SIGN_IN وعرض صفحة تسجيل الدخول إلى البوابة الإلكترونية، وذلك من خلال إرسال هذا الطلب عند الاتصال بواجهة برمجة تطبيقات النظام ConnectivityManager#startCaptivePortalApp(Network, Bundle).
• [C-1-2] يجب أن يتم رصد بوابات الربط ويجب أن يتيح التطبيق تسجيل الدخول من خلال بوابة الربط عندما يكون الجهاز متصلاً بأي نوع من الشبكات، بما في ذلك شبكة الجوّال/الشبكة الخلوية أو شبكة Wi-Fi أو إيثرنت أو البلوتوث.
• [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 للجهاز الذي يتضمّن عناصر أمان مستندة إلى شريحة SD.

7.5. الكاميرات

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

• [C-1-1] يجب الإفصاح عن علامة ميزة android.hardware.camera.any.
• [C-1-2] يجب أن يكون من الممكن للتطبيق تخصيص ملفّات رسومات bitmap RGBA_8888 وعددها 3 متزامنة تساوي حجم الصور التي تنتجها أداة استشعار الكاميرا ذات الدقة الأعلى على الجهاز، وذلك عندما تكون الكاميرا مفتوحة بغرض المعاينة الأساسية وتصوير الصور الثابتة.
• [C-1-3] يجب التأكّد من أنّ تطبيق الكاميرا التلقائي المثبَّت مسبقًا الذي يعالج النوايا MediaStore.ACTION_IMAGE_CAPTURE، MediaStore.ACTION_IMAGE_CAPTURE_SECURE، أو MediaStore.ACTION_VIDEO_CAPTURE، هو المسؤول عن إزالة الموقع الجغرافي للمستخدم في البيانات الوصفية للصورة قبل إرسالها إلى التطبيق المستلِم عندما لا يحتوي التطبيق المستلِم على ACCESS_FINE_LOCATION.

7.5.1. الكاميرا الخلفية

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

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

• يجب أن تتضمّن كاميرا خلفية.

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

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

إذا كانت الكاميرا تتضمّن فلاشًا:

• [C-2-1] يجب ألّا يكون مصباح الفلاش مضاءً أثناء تسجيل مثيل android.hardware.Camera.PreviewCallback على سطح معاينة الكاميرا، ما لم يفعِّل التطبيق FLASH_MODE_AUTOبوضوح فلاشًا من خلال تفعيل سمة 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] يجب عدم استخدام الكاميرا الأمامية كإعداد تلقائي لواجهة برمجة التطبيقات Camera API، ويجب عدم ضبط واجهة برمجة التطبيقات لمعالجة الكاميرا الأمامية على أنّها الكاميرا الخلفية التلقائية، حتى إذا كانت الكاميرا الوحيدة على الجهاز.
• [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 Video Class ‏ (UVC 1.0 أو إصدار أحدث) في حال توصيل الكاميرا الخارجية من خلال منفذ مضيف USB.
• [C-1-3] يجب اجتياز اختبارات CTS للكاميرا مع توصيل كاميرا خارجية. تتوفّر تفاصيل اختبار مجموعة أدوات اختبار التوافق (CTS) للكاميرا على source.android.com.
• يجب أن تتيح ضغط الفيديوهات، مثل MJPEG، لنقل مجريات البث بدون ترميز بجودة عالية (أي مجريات بث الصور غير المضغوطة أو المضغوطة بشكل مستقل).
• قد تتيح استخدام كاميرات متعددة.
• قد تتيح ميزة ترميز الفيديو المستند إلى الكاميرا.

في حال توفّر ميزة ترميز الفيديو بالاستناد إلى الكاميرا:

• [C-2-1] يجب أن يكون بالإمكان بث محتوى متزامن غير مشفَّر أو بتنسيق MJPEG (بدقة QVGA أو أعلى) لإتمام عملية تنفيذ الجهاز.

7.5.4. سلوك Camera API

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

تم وضع علامة على حزمة واجهة برمجة التطبيقات القديمة،android.hardware.Camera، بأنّها متوقّفة نهائيًا في 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] يجب أن يكون android.hardware.Camera.PreviewCallback بتنسيق ترميز 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 لأجهزة android.hardware.camera2 التي تُعلِن عن إمكانية REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE في android.request.availableCapabilities.
• [C-0-5] يجب تنفيذ Camera API بالكامل المضمّنة في مستندات حزمة تطوير البرامج (SDK) لنظام Android، بغض النظر عمّا إذا كان الجهاز يتضمّن ميزة ضبط التركيز التلقائي للأجهزة أو إمكانات أخرى. على سبيل المثال، يجب أن تظل الكاميرات التي carece of autofocus تستدعي أي مثيلات registered android.hardware.Camera.AutoFocusCallback (على الرغم من أنّ هذا ليس له صلة بكاميرا لا تتضمّن ميزة ضبط التركيز التلقائي). يُرجى العِلم أنّ ذلك ينطبق على الكاميرات المزوّدة بمثبّت كاميرا أمامي. على سبيل المثال، على الرغم من أنّ معظم الكاميرات المزوّدة بمثبّت كاميرا أمامي لا تتيح استخدام ميزة "التركيز التلقائي"، يجب أن تظلّ عمليات استدعاء واجهة برمجة التطبيقات "مزوّرة" كما هو موضّح.
• [C-0-6] يجب أن يتعرّف على كل اسم مَعلمة ويحترمه يُحدَّد كمتغيّر ثابت في فئة android.hardware.Camera.Parameters وفئة android.hardware.camera2.CaptureRequest. في المقابل، يجب ألا تلتزم عمليات تنفيذ الأجهزة بثوابت السلاسل المرسَلة إلى طريقة android.hardware.Camera.setParameters() أو تتعرّف عليها، باستثناء تلك الموثَّقة كثوابت في android.hardware.Camera.Parameters. وهذا يعني أنّه يجب أن تتوافق عمليات تنفيذ الأجهزة مع جميع مَعلمات الكاميرا العادية إذا كان الجهاز يسمح بذلك، ويجب ألّا تتوافق مع أنواع مَعلمات الكاميرا المخصّصة. على سبيل المثال، يجب أن تتيح عمليات تنفيذ الأجهزة التي تتيح التقاط الصور باستخدام تقنيات التصوير بنطاق عالي الديناميكية (HDR) استخدام مَعلمة الكاميرا Camera.SCENE_MODE_HDR.
• [C-0-7] يجب الإبلاغ عن المستوى المناسب من التوافق باستخدام السمة android.info.supportedHardwareLevel كما هو موضّح في حزمة تطوير البرامج (SDK) لنظام التشغيل Android والإبلاغ عن رموز ميزات إطار العمل المناسبة.
• [C-0-8] يجب أيضًا الإفصاح عن إمكانات الكاميرا الفردية التي تبلغ android.hardware.camera2 من خلال السمة android.request.availableCapabilities، والإفصاح عن رموز الميزات المناسبة، وتحديد رمز الميزة إذا كان أي من أجهزة الكاميرا المُرفَقة تتيح الميزة.
• [C-0-9] يجب بث Camera.ACTION_NEW_PICTURE intent عند التقاط صورة جديدة بالكاميرا وإضافة إدخال الصورة إلى "متجر الوسائط".
• [C-0-10] يجب بث Camera.ACTION_NEW_VIDEO intent عند تسجيل فيديو جديد بواسطة الكاميرا وإضافة إدخال الصورة إلى "متجر الوسائط".
• [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.

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

• مساحة تخزين قابلة للإزالة يمكن للمستخدم الوصول إليها، مثل فتحة بطاقة Secure Digital (SD)
• جزء من مساحة التخزين الداخلية (غير القابلة للإزالة) كما هو مُنفَّذ في المشروع المفتوح المصدر لنظام Android‏ (AOSP)

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

• [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 أمبير وفقًا لمعيار المقاوم لـ Type-C، ويجب أن يرصد التغييرات في الإعلان إذا كانا متوافقَين مع USB Type-C.
• [C-SR-1] يجب أن يستخدم المنفذ عامل شكل USB من النوع micro-B أو micro-AB أو Type-C. ننصح بشدة بتوافق أجهزة Android الحالية والجديدة مع هذه المتطلبات حتى تتمكّن من الترقية إلى إصدارات المنصة المستقبلية.
• [C-SR-2] يجب أن يكون المنفذ في أسفل الجهاز (وفقًا للاتجاه الطبيعي) أو تفعيل ميزة دوران الشاشة من خلال البرامج في جميع التطبيقات (بما في ذلك الشاشة الرئيسية)، حتى يتم عرض المحتوى على الشاشة بشكل صحيح عند توجيه الجهاز مع وضع المنفذ في أسفل الجهاز. ننصح بشدة بتوافق أجهزة Android الحالية والجديدة مع هذه المتطلبات حتى تتمكّن من الترقية إلى إصدارات المنصة المستقبلية.
• [C-SR-3] يجب أن يتيح الجهاز سحب تيار 1.5 أمبير أثناء إشارة HS chirp وعمليات نقل البيانات على النحو المحدّد في مواصفة شحن البطارية عبر USB، المراجعة 1.2. ننصح بشدة بتوافق أجهزة Android الحالية والجديدة مع هذه المتطلبات حتى تتمكّن من الترقية إلى إصدارات المنصة المستقبلية.
• [C-SR-4] يُنصح بشدة بعدم استخدام طرق الشحن الخاصة التي تعمل على تعديل جهد Vbus الكهربائي إلى ما بعد المستويات التلقائية، أو تغيير أدوار الحوض/المصدر على النحو، قد يؤدي ذلك إلى حدوث مشاكل في إمكانية التشغيل التفاعلي مع الشواحن أو الأجهزة التي تتوافق مع طرق "توصيل الطاقة عبر USB" العادية. على الرغم من أنّه يُنصح بشدة باستخدام هذه الطريقة، قد نشترط في الإصدارات المستقبلية من Android أن تتوافق جميع الأجهزة التي تستخدم موصلات من النوع C مع الشواحن العادية من النوع C.
• [C-SR-5] يُنصح بشدة بتوفُّر ميزة "إرسال الطاقة" لنقل البيانات و تبديل دور الطاقة عندما يتوفّر منفذ USB من النوع C ووضع مضيف USB.
• يجب أن يكون متوافقًا مع ميزة "إرسال الطاقة" للشحن بتيار عالي الجهد ويجب أن يكون متوافقًا مع الأوضاع البديلة، مثل "إخراج الشاشة".
• يجب تنفيذ واجهة برمجة التطبيقات وتحديد مواصفات Android Open Accessory (AOA) كما هو موضح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

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

• [C-2-1] يجب الإفصاح عن توافق التطبيق مع ميزة الجهاز android.hardware.usb.accessory.
• [C-2-2] يجب أن تتضمّن فئة وحدة تخزين USB الضخمة السلسلة "android" في نهاية سلسلة وصف الواجهة iInterface لوحدة تخزين USB الضخمة.

7.7.2. وضع مضيف USB

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

• [C-1-1] يجب تنفيذ واجهة برمجة التطبيقات Android USB host API كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android، ويجب الإفصاح عن توفّر ميزة الأجهزة android.hardware.usb.host.
• [C-1-2] يجب أن تتيح إمكانية توصيل أجهزة USB ملحقة عادية، بمعنى آخر، يجب أن:
  • أن يتضمّن منفذًا من النوع C على الجهاز أو أن يتم شحنه مع كابلات تتيح تحويل منفذ مملوك على الجهاز إلى منفذ USB عادي من النوع C (جهاز USB من النوع C)
  • أن يكون مزوّدًا بمنفذ من النوع "أ" على الجهاز أو أن يتم شحنه مع كابلات تتيح تحويل منفذ خاص على الجهاز إلى منفذ USB عادي من النوع "أ"
  • أن يتضمّن الجهاز منفذ micro-AB، والذي من المفترض أن يتم شحنه مع كابل محوِّل إلى منفذ من النوع A عادي
• [C-1-3] يجب عدم شحن الجهاز مع محوِّل يحوّل من منافذ USB من النوع A أو منافذ micro-AB إلى منفذ من النوع C (مقبس).
• [C-SR-1] يُنصح بشدة بتنفيذ فئة الصوت عبر USB كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
• يجب أن يكون متوافقًا مع شحن الجهاز الملحق USB المتصل به أثناء بدء التشغيل، وأن يعرض تيار مصدر لا يقل عن 1.5 أمبير كما هو موضّح في قسم "مَعلمات القطع" من الإصدار 1.2 من مواصفات كابل USB ووصلاته من النوع C لموصّلات USB من النوع C أو استخدام نطاق تيار الإخراج لمحطة الشحن(CDP) كما هو موضّح في مواصفات شحن البطارية عبر USB، الإصدار 1.2 لموصّلات Micro-AB.
• يجب أن تتوافق مع معايير USB من النوع C وأن تتيح استخدامها.

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

• [C-2-1] يجب أن يكون متوافقًا مع فئة USB HID.
• [C-2-2] يجب أن يتيح الجهاز رصد حقول بيانات HID التالية وربطها كما هو محدّد في جداول استخدام USB HID وطلب استخدام الأوامر الصوتية بثوابت KeyEvent على النحو التالي:
  • رقم تعريف صفحة الاستخدام (0xC) ورقم تعريف الاستخدام (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • رقم تعريف صفحة الاستخدام (0xC) ورقم تعريف الاستخدام (0x0E9): KEYCODE_VOLUME_UP
  • رقم تعريف استخدام صفحة الاستخدام (0xC): KEYCODE_VOLUME_DOWN
  • صفحة الاستخدام (0xC) معرّف الاستخدام (0x0CF): KEYCODE_VOICE_ASSIST

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

• [C-3-1] يجب أن يتعرّف التطبيق على أي أجهزة متصلة عن بُعد باستخدام بروتوكول نقل الوسائط (MTP) ويتيح الوصول إلى محتوياتها من خلال طلبات الإجراء ACTION_GET_CONTENT وACTION_OPEN_DOCUMENT وACTION_CREATE_DOCUMENT. .

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

• [C-4-1] يجب تنفيذ وظيفة "منفذ الدور المزدوج" كما هو محدّد في مواصفة USB Type-C (الفقرة 4.5.1.3.3).
• [C-SR-2] يُنصح بشدة بتوفير منفذ DisplayPort، ويجب أن يتوافق مع سرعات نقل البيانات الفائقة USB ، ويُنصح بشدة بتوفير ميزة Power Delivery لتبادل دور نقل البيانات ونقل الطاقة.
• [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 ohm: KEYCODE_VOLUME_UP
  • ‫‎360-680 ohm: KEYCODE_VOLUME_DOWN
• [C-1-4] يجب أن يؤدي إدخال القابس إلى تنشيط ACTION_HEADSET_PLUG، ولكن فقط بعد أن تلمس جميع جهات الاتصال في القابس الأجزاء ذات الصلة في المقبس.
• [C-1-5] يجب أن يكون قادرًا على توفير 150 مللي فولت ± 10% من الجهد الكهربي الخارج على ممانعة مكبّر صوت تبلغ 32 أوم.
• [C-1-6] يجب أن يكون جهد الميكروفون المرجعي بين 1.8 فولت و2.9 فولت.
• [C-1-7] يجب رصد ونَسْق رمز المفتاح التالي لمدى المقاومة المكافئة بين الميكروفون وسلكان الأرض في مقبس الصوت:
  • من 110 إلى 180 أوم: KEYCODE_VOICE_ASSIST
• [C-SR-2] يُنصح بشدة بتوفير مقابس صوت تتضمّن ترتيب دبوس OMTP.
• [C-SR-3] يُنصح بشدة بتوفُّر ميزة تسجيل الصوت من سماعات الرأس المزوّدة بميكروفون والتي توفّر صوتًا ستيريو.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقبس صوت 3.5 ملم مزوّدًا بأربعة موصلات وتتوافق مع استخدام الميكروفون، وبثّت الرسالة android.intent.action.HEADSET_PLUG مع ضبط قيمة الملحق المتمثل في الميكروفون على 1، يعني ذلك ما يلي:

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

7.8.2.2. منافذ الصوت الرقمي

أن تكون متوافقة مع سماعات الرأس وملحقات الصوت الأخرى التي تستخدم قوابس USB-C وتنفيذ (فئة الصوت عبر USB) على مستوى منظومة Android المتكاملة كما هو محدّد في مواصفات سماعات الرأس USB لأجهزة Android

راجِع القسم 2.2.1 لمعرفة المتطلبات الخاصة بالأجهزة.

7.8.3. الموجات فوق الصوتية القريبة

يتراوح نطاق الصوت بالقرب من الموجات فوق الصوتية بين 18.5 كيلوهرتز و20 كيلوهرتز.

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

• يجب الإبلاغ بشكل صحيح عن توفّر ميزة الصوت بالقرب من الموجات فوق الصوتية من خلال واجهة برمجة التطبيقات AudioManager.getProperty على النحو التالي:

إذا كانت قيمة PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND هي "true"، يجب استيفاء المتطلبات التالية لمصادر الصوت VOICE_RECOGNITION وUNPROCESSED:

• [C-1-1] يجب ألا يقلّ متوسط استجابة الطاقة للميكروفون في النطاق من 18.5 كيلوهرتز إلى 20 كيلوهرتز عن 15 ديسيبل عن الاستجابة عند 2 كيلوهرتز.
• [C-1-2] يجب ألا تقل نسبة الإشارة إلى الضوضاء غير المحسوبة للميكروفون عن 50 ديسيبل عند سماع نغمة بتردد 19 كيلوهرتز ومستوى -26 ديسيبل في نطاقات التردد من 18.5 كيلوهرتز إلى 20 كيلوهرتز.

إذا كانت قيمة PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND هي "true":

• [C-2-1] يجب ألا يقل متوسّط استجابة مكبّر الصوت في النطاق من 18.5 كيلوهرتز إلى 20 كيلوهرتز عن 40 ديسيبل أقل من الاستجابة عند 2 كيلوهرتز.

7.8.4. سلامة الإشارة

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

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

يتطلّب الاختبار استخدام محوّل صوتي يُستخدَم مباشرةً في مقبس 3.5 ملم و/أو مع محوّل USB-C إلى 3.5 ملم. يجب اختبار جميع منافذ إخراج الصوت.

يتيح OboeTester حاليًا مسارات AAudio، لذا يجب اختبار المجموعات التالية بحثًا عن أي مشاكل باستخدام AAudio:

وضع الأداء	المشاركة	معدّل البيانات في الملف الصوتي الناتج	في Chans	Out Chans
LOW_LATENCY	حصري	غير محدّد	1	2
LOW_LATENCY	حصري	غير محدّد	2	1
LOW_LATENCY	مشترك	غير محدّد	1	2
LOW_LATENCY	مشترك	غير محدّد	2	1
لم يتم اختيار لون	مشترك	48000	1	2
لم يتم اختيار لون	مشترك	48000	2	1
لم يتم اختيار لون	مشترك	44100	1	2
لم يتم اختيار لون	مشترك	44100	2	1
لم يتم اختيار لون	مشترك	16000	1	2
لم يتم اختيار لون	مشترك	16000	2	1

يجب أن يستوفي البث الموثوق المعايير التالية لنسبة الإشارة إلى الضوضاء (SNR) وإجمالي التشوه التوافقي (THD) لموجة جيبية بتردد 2000 هرتز.

محوّل طاقة صوتية	THD	معدّل الضوضاء الديناميكي
مكبّر الصوت المدمج الأساسي، تم قياسه باستخدام ميكروفون مرجعي خارجي	أقل من %3.0	‫>= 50 ديسيبل
الميكروفون المدمج الأساسي، والذي يتم قياسه باستخدام مكبّر صوت مرجعي خارجي	أقل من %3.0	‫>= 50 ديسيبل
مقابس 3.5 ملم تناظرية مدمجة تم اختبارها باستخدام محوّل loopback	أقل من %1	‫>= 60 ديسيبل
محوِّلات USB المزوَّدة مع الهاتف، والتي تم اختبارها باستخدام محوِّل loopback	أقل من %1	‫>= 60 ديسيبل

7.9. الواقع الافتراضي

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

7.9.1. وضع الواقع الافتراضي

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

7.9.2. وضع الواقع الافتراضي - الأداء العالي

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

• [C-1-1] يجب أن يكون الجهاز مزوّدًا بنوى فعلية اثنتان على الأقل.
• [C-1-2] يجب الإفصاح عن ميزة android.hardware.vr.high_performance.
• [C-1-3] يجب أن يكون الجهاز متوافقًا مع وضع الأداء المستدام.
• [C-1-4] يجب أن يكون متوافقًا مع OpenGL ES 3.2.
• [C-1-5] يجب أن يكون متوافقًا مع android.hardware.vulkan.level 0.
• يجب أن يكون متوافقًا مع الإصدار 1 من android.hardware.vulkan.level أو إصدار أحدث.
• [C-1-6] يجب تنفيذ EGL_KHR_mutable_render_buffer، EGL_ANDROID_front_buffer_auto_refresh، EGL_ANDROID_get_native_client_buffer، EGL_KHR_fence_sync، EGL_KHR_wait_sync، EGL_IMG_context_priority، EGL_EXT_protected_content، EGL_EXT_image_gl_colorspace، وعرض الإضافات في قائمة إضافات EGL المتاحة.
• [C-1-8] يجب تنفيذ GL_EXT_multisampled_render_to_texture2، GL_OVR_multiview، GL_OVR_multiview2، GL_EXT_protected_textures، وعرض الإضافات في قائمة إضافات GL المتاحة.
• [C-SR-1] يُنصح بشدة بتنفيذ GL_EXT_external_buffer، GL_EXT_EGL_image_array، GL_OVR_multiview_multisampled_render_to_texture، وعرض الإضافات في قائمة إضافات GL المتاحة.
• [C-SR-2] يُنصح بشدة بتوفير دعم لـ Vulkan 1.1.
• [C-SR-3] يُنصح بشدة بتنفيذ VK_ANDROID_external_memory_android_hardware_buffer، VK_GOOGLE_display_timing، VK_KHR_shared_presentable_image، وعرضها في قائمة إضافات Vulkan المتاحة.
• [C-SR-4] يُنصح بشدة بعرض عائلة قوائم انتظار Vulkan واحدة على الأقل حيث يحتوي flags على كل من VK_QUEUE_GRAPHICS_BIT وVK_QUEUE_COMPUTE_BIT، ويكون queueCount 2 على الأقل.
• [C-1-7] يجب أن يكون بإمكان وحدة معالجة الرسومات والشاشة مزامنة الوصول إلى ملف التخزين المؤقت المشترَك في المقدّمة، وذلك لعرض محتوى الواقع الافتراضي بالتناوب بين العينَين بمعدّل 60 لقطة في الثانية باستخدام سياقَي عرض بدون أيّ تمزّق مرئي.
• [C-1-9] يجب توفير إمكانية استخدام AHardwareBuffer العلامات AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER وAHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA وAHARDWAREBUFFER_USAGE_PROTECTED_CONTENT كما هو موضّح في حزمة NDK.
• [C-1-10] يجب أن تتيح التطبيقات استخدام AHardwareBuffer مع أي تركيبة من علامات الاستخدام AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT، AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE، AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT لأشكال الإعلانات التالية على الأقل: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM، AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM، AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM، AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
• [C-SR-5] يُنصح بشدة بتفعيل تخصيص AHardwareBuffers التي تحتوي على أكثر من طبقة واحدة وعلامات وتنسيقات محدّدة في C-1-10.
• [C-1-11] يجب أن يكون الجهاز متوافقًا مع ترميز H.264 بدرجة دقة 3840 × 2160 على الأقل بمعدّل 30 لقطة في الثانية، ومضغوطًا بمعدّل 40 ميغابت في الثانية في المتوسط (أي ما يعادل 4 مرات دقة 1920 × 1080 بمعدّل 10 ميغابت في الثانية أو مرّتين بدقة 1920 × 1080 بمعدّل 20 ميغابت في الثانية).
• [C-1-12] يجب أن يكون متوافقًا مع HEVC وVP9، ويجب أن يكون قادرًا على فك ترميز محتوى بدقة 1920 x ‏1080 على الأقل بمعدّل 30 لقطة في الثانية مضغوطًا بمتوسط 10 ميغابت في الثانية، ويجب أن يكون قادرًا على فك ترميز محتوى بدقة 3840 x ‏2160 بمعدّل 30 لقطة في الثانية أو 20 ميغابت في الثانية (أي ما يعادل 4 مرات بدقة 1920 x ‏1080 بمعدّل 30 لقطة في الثانية أو 5 ميغابت في الثانية).
• [C-1-13] يجب أن يكون الجهاز متوافقًا مع واجهة برمجة التطبيقات HardwarePropertiesManager.getDeviceTemperatures وأن يعرض قيمًا دقيقة لدرجة حرارة الجلد.
• [C-1-14] يجب أن يكون الجهاز مزوّدًا بشاشة مدمجة، ويجب ألا تقل درجة دقتها عن 1920 × 1080.
• [C-SR-6] يُنصح بشدة بدرجة دقة شاشة لا تقل عن ‎2560 x 1440.
• [C-1-15] يجب أن يتم تعديل الشاشة بمعدّل 60 هرتز على الأقل أثناء استخدام "وضع الواقع الافتراضي".
• [C-1-17] يجب أن تتيح الشاشة وضعًا بفترة بقاء منخفضة لا تزيد عن 5 مللي ثانية، وفترة البقاء هي الوقت الذي يُصدر فيه البكسل ضوءًا.
• [C-1-18] يجب أن يكون متوافقًا مع معيار Bluetooth 4.2 وBluetooth LE Data Length Extension الفقرة 7.4.3.
• [C-1-19] يجب أن يتيح الجهاز بشكل صحيح تسجيل نوع القناة المباشرة لجميع أنواع أجهزة الاستشعار التلقائية التالية:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR-7] يُنصح بشدة بتوفّر نوع القناة المباشرة TYPE_HARDWARE_BUFFER لجميع أنواع القنوات المباشرة المُدرَجة أعلاه.
• [C-1-21] يجب استيفاء متطلبات الجيروسكوب ومقياس التسارع ومقياس المغناطيسية المتعلقةandroid.hardware.hifi_sensors، على النحو المحدّد في الفقرة 7.3.9.
• [C-SR-8] يُنصح بشدة بتوفّر ميزة android.hardware.sensor.hifi_sensors.
• [C-1-22] يجب ألا يزيد وقت استجابة انتقال الصور من البداية إلى النهاية عن 28 ملي ثانية.
• [C-SR-9] يُنصح بشدة بضبط وقت استجابة الإطارات من البداية إلى النهاية ليكون ألا يزيد عن 20 ملي ثانية.
• [C-1-23] يجب أن تكون نسبة اللقطة الأولى، وهي نسبة بين brightness بكسل اللقطة الأولى بعد الانتقال من الأسود إلى الأبيض وbrightness بكسل الأبيض في الحالة الثابتة، لا تقل عن %85.
• [C-SR-10] يُنصح بشدة بأن تكون نسبة اللقطة الأولى 90% على الأقل.
• قد توفّر وحدة معالجة مركزية حصرية لتطبيق foreground ، وقد تتوافق مع واجهة برمجة التطبيقات Process.getExclusiveCores لعرض أعداد وحدات المعالجة المركزية الحصرية لتطبيق foreground الأكثر أهمية.

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

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

7.10. أجهزة تعمل باللمس

راجِع القسم 2.2.1 لمعرفة المتطلبات الخاصة بالأجهزة.

7.11. فئة أداء الوسائط

يمكن الحصول على فئة أداء الوسائط لتنفيذ الجهاز من android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS. يتم تحديد متطلبات فئة أداء الوسائط لكل إصدار من Android بدءًا من R (الإصدار 30). تشير القيمة الخاصة 0 إلى أنّ الجهاز ليس من فئة أداء الوسائط.

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

• [C-1-1] يجب أن تعرِض قيمة android.os.Build.VERSION_CODES.R على الأقل.

• [C-1-2] يجب أن يكون التنفيذ على جهاز محمول باليد.

• [C-1-3] يجب استيفاء جميع متطلبات "فئة أداء الوسائط" الموضّحة في الفقرة 2.2.7.

اطّلِع على الفقرة 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 لعدد مجموعات وضع "التطبيقات في وضع الاستعداد" المستخدَمة في وضع "التطبيقات في وضع الاستعداد".
• [C-1-4] يجب تنفيذ مجموعات تطبيقات وضع الاستعداد وميزة "الاستراحة" كما هو описан في إدارة الطاقة.
• [C-1-5] يجب عرض القيمة true لـ PowerManager.isPowerSaveMode() عندما يكون الجهاز في وضع توفير الطاقة.
• [C-1-6] يجب أن يقدّم التطبيق للمستخدم إمكانية عرض كل التطبيقات التي تم استثناؤها من وضعَي "الاستراحة" و"الاستعداد" للتوفير في استهلاك الطاقة أو أي تحسينات على البطارية، ويجب أن ينفذ التطبيق الإجراء ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS لطلب السماح للتطبيق بتجاهل تحسينات البطارية.
• [C-SR-1] يُنصح بشدة بتوفير إمكانات للمستخدم لتفعيل ميزة "توفير البطارية" وإيقافها.
• [C-SR-2] يُنصح بشدة بتوفير ميزة للمستخدم لعرض كل التطبيقات التي تم استثناؤها من وضعَي "الاستراحة" و"الاستراحة الذكية" لتوفير الطاقة.

إذا كانت عمليات تنفيذ الأجهزة توفّر ميزات إدارة الطاقة المضمّنة في AOSP وكانت هذه الميزات تفرض قيودًا أكثر صرامة من مجموعة التطبيقات التي نادرًا ما تكون في وضع الاستعداد، يُرجى الرجوع إلى الفقرة 3.5.1.

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

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

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

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

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

  في المقابل، يجب الخروج من حالة S3 عندما تحتاج التطبيقات التابعة لجهات خارجية إلى موارد النظام، كما هو موضّح في حزمة تطوير البرامج (SDK) هذه.

  على سبيل المثال، عندما تطلب التطبيقات التابعة لجهات خارجية إبقاء الشاشة مشغّلة من خلال FLAG_KEEP_SCREEN_ON أو إبقاء وحدة المعالجة المركزية (CPU) تعمل من خلال PARTIAL_WAKE_LOCK، يجب ألّا يدخل الجهاز في حالة S3 ما لم يتّخذ المستخدم إجراءً صريحًا لوضع الجهاز في حالة غير نشط، كما هو موضّح في C-1-1. في المقابل، في الوقت الذي يتم فيه بدء مهمة تنفذها التطبيقات التابعة لجهات خارجية من خلال JobScheduler أو يتم فيه إرسال Firebase Cloud Messaging إلى التطبيقات التابعة لجهات خارجية، يجب أن يخرج الجهاز من حالة S3 ما لم يكن المستخدم قد وضع الجهاز في حالة غير نشطة. هذه ليست مثالاً كاملاً، وينفِّذ AOSP إشارات استيقاظ مكثفة تؤدي إلى الاستيقاظ من هذه الحالة.

8.4. احتساب استهلاك الطاقة

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

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

• [C-SR-1] يُنصح بشدة بتقديم ملفات تعريف الطاقة لكل مكوّن تحدد قيمة الاستهلاك الحالي لكل مكوّن من مكونات الجهاز ومعدل استنزاف البطارية التقريبي الذي يسببه المكوّنات بمرور الوقت كما هو موضّح في موقع "مشروع Android المفتوح المصدر" الإلكتروني.
• [C-SR-2] يُنصح بشدة بالإبلاغ عن جميع قيم استهلاك الطاقة بالمللي أمبير ساعة (mAh).
• [C-SR-3] يُنصح بشدة بالإبلاغ عن استهلاك طاقة وحدة المعالجة المركزية لكل معرّف مستخدم لكل عملية. يستوفي "مشروع مفتوح المصدر لنظام Android" المتطلّبات من خلال تنفيذ uid_cputime وحدة النواة.
• [C-SR-4] يُنصح بشدة بإتاحة استخدام الطاقة هذا من خلال استخدام الأمر adb shell dumpsys batterystats shell من قِبل مطوّر التطبيق.
• يجب أن يُنسَب إلى مكوّن الجهاز نفسه في حال تعذّر نسْب استهلاك الطاقة لمكوّن الجهاز إلى أحد التطبيقات.

8.5. الأداء المتسق

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

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

• [C-0-1] يجب الإبلاغ بدقة عن توفّر "وضع الأداء المستدام" من خلال استخدام PowerManager.isSustainedPerformanceModeSupported() طريقة واجهة برمجة التطبيقات.

• يجب أن يكون متوافقًا مع "وضع الأداء المستدام".

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

• [C-1-1] يجب أن يقدّم التطبيق الأهم في المقدّمة مستوى ثبات في الأداء لمدة 30 دقيقة على الأقل عندما يطلب ذلك.
• [C-1-2] يجب الالتزام بواجهة برمجة التطبيقات Window.setSustainedPerformanceMode() API وواجهات برمجة التطبيقات الأخرى ذات الصلة.

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

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

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

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

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

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

• يجوز إضافة أذونات إضافية، شرط ألّا تكون سلاسل أرقام تعريف الأذونات الجديدة في مساحة الاسم android.\*.

• [C-0-2] يجب عدم منح الأذونات التي تحمل protectionLevel PROTECTION_FLAG_PRIVILEGED سوى للتطبيقات المثبَّتة مسبقًا في المسارات المميَّزة لصورة النظام وضمن المجموعة الفرعية من الأذونات المدرَجة في القائمة المسموح بها لكل تطبيق. يستوفي تطبيق AOSP هذا الشرط من خلال قراءة الأذونات المدرَجة في القائمة المسموح بها لكل تطبيق من الملفات في مسار etc/permissions/ واستخدام مسار system/priv-app كملاذ مميَّز.

إنّ الأذونات التي يكون مستوى حمايتها خطيرًا هي أذونات وقت التشغيل. تطلب التطبيقات التي تحتوي على targetSdkVersion > 22 هذه الأذونات أثناء التشغيل.

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

• [C-0-3] يجب أن يعرض التطبيق واجهة مخصّصة للمستخدم ليقرر ما إذا كان سيمنح أذونات التشغيل المطلوبة، كما يجب أن يقدّم واجهة للمستخدم لإدارة أذونات التشغيل.
• [C-0-4] يجب أن يكون هناك تنفيذ واحد فقط لكلتا جهتي واجهة العميل.
• [C-0-5] يجب عدم منح أي أذونات تشغيل للتطبيقات preinstalled إلا في الحالات التالية:
  • يمكن الحصول على موافقة المستخدم قبل أن يستخدم التطبيق هذه البيانات.
  • ترتبط أذونات التشغيل بنمط نية يتم ضبط التطبيق المثبَّت مسبقًا كمعالج تلقائي له.
• [C-0-6] يجب منح الإذن android.permission.RECOVER_KEYSTORE فقط لتطبيقات النظام التي تسجِّل وكيل استرداد آمنًا بشكلٍ صحيح. يتم تعريف وكيل الاسترداد المُؤمَّن بشكلٍ صحيح على أنّه وكيل برامج على الجهاز تتم مزامنته مع مساحة تخزين عن بُعد خارج الجهاز، ومزوّد بجهاز آمن يقدّم حماية مماثلة أو أقوى مما هو описан في خدمة Google Cloud Key Vault لمنع هجمات القوة الغاشمة على عامل المعلومات في شاشة القفل.

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

• [C-0-7] يجب الالتزام بخصائص إذن الوصول إلى الموقع الجغرافي في Android عندما يطلب التطبيق بيانات الموقع الجغرافي أو النشاط البدني من خلال واجهة برمجة التطبيقات العادية لنظام التشغيل Android أو آلية خاصة. وتشمل هذه البيانات على سبيل المثال لا الحصر ما يلي:

  • الموقع الجغرافي للجهاز (مثل خط العرض وخط الطول) كما هو موضّح في الفقرة 9.8.8
  • المعلومات التي يمكن استخدامها لتحديد الموقع الجغرافي للجهاز أو تقديره (مثل معرّف شبكة WLAN أو معرّف مجموعة الخدمات الأساسية أو معرّف الخلية أو الموقع الجغرافي للشبكة التي يكون الجهاز متصلاً بها)
  • النشاط البدني للمستخدم أو تصنيف النشاط البدني

وعلى وجه التحديد، تؤدي عمليات تنفيذ الأجهزة إلى ما يلي:

• [C-0-8] يجب الحصول على موافقة المستخدم للسماح للتطبيق بالوصول إلى data الموقع الجغرافي أو النشاط البدني.
• [C-0-9] يجب منح إذن التشغيل للتطبيق الذي يملك إذنًا كافيًا كما هو موضّح في حزمة SDK فقط. على سبيل المثال، تتطلّب TelephonyManager#getServiceStateandroid.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] يجب عرض بيان إخلاء مسؤولية أثناء عملية إعداد الجهاز المُدار بالكامل (إعداد مالك الجهاز) يفيد بأنّه سيكون بإمكان مشرف تكنولوجيا المعلومات السماح للتطبيقات بالتحكم في الإعدادات على الهاتف، بما في ذلك الميكروفون والكاميرا وموقع الجهاز الجغرافي، مع خيارات تتيح للمستخدم مواصلة عملية الإعداد أو الخروج منها ما لم يكن المشرف قد أوقف إمكانية التحكّم في الأذونات على الجهاز.

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

• [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، والذي يتم فيه تشغيل كل تطبيق كمعرّف مستخدم فريد على غرار Unix وفي عملية منفصلة.
• [C-0-2] يجب أن تتيح تشغيل تطبيقات متعددة باستخدام معرّف مستخدم Linux نفسه، شرط أن تكون التطبيقات موقَّعة ومصمّمة بشكل صحيح، كما هو محدّد في مرجع الأمان والأذونات.

9.3. أذونات نظام الملفات

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

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

9.4. بيئات التنفيذ البديلة

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

• [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] يجب عدم تشغيل أو منح أو منح التطبيقات الأخرى أي امتيازات خاصة بالمستخدم المتميّز (root) أو أي مستخدم آخر باستخدام أوقات التشغيل البديلة.

• [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 للخدمات هي رسائل نصية يتم إرسالها إلى خدمة مسجَّلة لدى مشغِّل شبكة الجوّال وقد تؤدي إلى تحصيل رسوم من المستخدم.

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

• [C-1-1] يجب تحذير المستخدمين قبل إرسال رسالة قصيرة إلى الأرقام التي يتم تحديدها من خلال التعبيرات العادية المحدّدة في ملف /data/misc/sms/codes.xml على الجهاز. يقدّم "المشروع المفتوح المصدر لنظام Android" الإصدار الأساسي الذي يلبّي هذا الشرط.

9.7. ميزات الأمان

يجب أن تضمن عمليات تنفيذ الأجهزة الامتثال لميزات الأمان في كلّ من النواة والنظام الأساسي على النحو الموضّح أدناه.

يتضمّن "وضع الحماية" في Android ميزات تستخدِم نظام التحكّم الإجباري في الوصول (MAC) لنظام التشغيل Linux المُحسَّن للأمان (SELinux) ووضع الحماية seccomp وميزات أمان أخرى في نواة Linux. عمليات التنفيذ على الأجهزة:

• [C-0-1] يجب الحفاظ على التوافق مع التطبيقات الحالية، حتى في حال تنفيذ SELinux أو أي ميزات أمان أخرى ضمن إطار عمل Android.
• [C-0-2] يجب ألّا تتضمّن واجهة مستخدم مرئية عند رصد انتهاك أمان وحظره بنجاح من خلال ميزة الأمان المُطبَّقة أسفل إطار عمل Android، ولكن يجوز أن تتضمّن واجهة مستخدم مرئية عند حدوث انتهاك أمان غير محظور يؤدي إلى استغلال ناجح.
• [C-0-3] يجب عدم السماح للمستخدم أو مطوّر التطبيقات بضبط SELinux أو أي ميزات أمان أخرى تم تنفيذها أسفل إطار عمل Android.
• [C-0-4] يجب عدم السماح لتطبيق يمكنه التأثير في تطبيق آخر من خلال واجهة برمجة تطبيقات (مثل Device Administration API) بضبط سياسة تؤدي إلى إيقاف التوافق.
• [C-0-5] يجب تقسيم إطار عمل الوسائط إلى عمليات متعددة لكي تتمكّن من منح إذن الوصول لكل عملية على حدة بشكل أكثر تقييدًا على النحو الموضَّح في الموقع الإلكتروني لمشروع Android Open Source Project.
• [C-0-6] يجب تنفيذ آلية وضع التطبيقات في بيئة معزولة في نظام التشغيل تسمح بتصفية طلبات النظام باستخدام سياسة قابلة للضبط من البرامج المتعدّدة المواضيع. يستوفي "المشروع المفتوح المصدر لنظام Android" هذا المتطلب من خلال تفعيل seccomp-BPF مع ميزة التزامن في مجموعة المواضيع (TSYNC) كما هو موضّح في قسم "إعدادات النواة" على source.android.com.

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

• [C-0-7] يجب تنفيذ آليات الحماية من تدفّق سعة المخزن المؤقت للحزمة في kernel. ومن الأمثلة على هذه الآليات CC_STACKPROTECTOR_REGULAR و CONFIG_CC_STACKPROTECTOR_STRONG.
• [C-0-8] يجب تنفيذ إجراءات حماية صارمة لذاكرة kernel حيث يكون الرمز البرمجي قابلاً للتنفيذ ولكنه للقراءة فقط، وتكون البيانات القابلة للقراءة فقط غير قابلة للتنفيذ وغير قابلة للكتابة، وتكون البيانات القابلة للكتابة غير قابلة للتنفيذ (مثل CONFIG_DEBUG_RODATA أو CONFIG_STRICT_KERNEL_RWX).
• [C-0-9] يجب تنفيذ التحقّق من حدود حجم العناصر الثابتة والديناميكية للنُسخ بين مساحة المستخدم ومساحة النواة (مثل 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] يُنصح بشدة بتعشيب تنسيق رمز kernel و الذاكرة، وتجنُّب التعرّض للاختراقات التي قد تؤدي إلى اختراق العشوائية (مثل CONFIG_RANDOMIZE_BASE مع التشويش في أداة تحميل البرامج من خلال /chosen/kaslr-seed Device Tree node أو EFI_RNG_PROTOCOL).

• [C-SR-3] يُنصح بشدة بتفعيل ميزة "سلامة تدفّق التحكّم" (CFI) في النواة لتوفير حماية إضافية ضد هجمات إعادة استخدام الرموز البرمجية (مثل CONFIG_CFI_CLANG وCONFIG_SHADOW_CALL_STACK).

• [C-SR-4] يُنصح بشدة بعدم إيقاف ميزة "سلامة تدفّق التحكّم" (CFI) أو "تسلسل استدعاء الظل" (SCS) أو "التطهير من تدفّق الأعداد الصحيحة" (IntSan) في المكونات التي تم تفعيلها فيها.

• [C-SR-5] يُنصح بشدة بتفعيل CFI وSCS وIntSan لأي مكونات إضافية حسّاسة للأمان في مساحة المستخدم كما هو موضّح في CFI و IntSan.

• [C-SR-6] يُنصح بشدة بتفعيل عملية إعداد الحزمة في النواة لمنع استخدام المتغيّرات المحلية غير المُعدَّة (CONFIG_INIT_STACK_ALL أو CONFIG_INIT_STACK_ALL_ZERO). ويجب أيضًا ألا تفترض عمليات تنفيذ الأجهزة القيمة المستخدَمة من المُجمِّع لإعداد المتغيّرات المحلية.

• [C-SR-7] يُنصح بشدة بتفعيل بدء تشغيل الذاكرة في kernel لمنع استخدام عمليات تخصيص الذاكرة غير المُنشَطة (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) ويجب عدم افتراض القيمة المستخدَمة في kernel لبدء تشغيل عمليات التخصيص هذه.

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

• [C-1-1] يجب تنفيذ SELinux.
• [C-1-2] يجب ضبط SELinux على وضع التنفيذ الشامل.
• [C-1-3] يجب ضبط جميع النطاقات في وضع التنفيذ. لا يُسمح باستخدام نطاقات في الوضع المرخّص، بما في ذلك النطاقات الخاصة بجهاز أو موفِّر.
• [C-1-4] يجب عدم تعديل قواعد neverallow الحالية أو حذفها أو استبدالها ضمن مجلد system/sepolicy المتوفّر في "المشروع المفتوح المصدر لنظام Android" (AOSP) ويجب تجميع السياسة مع جميع قواعد neverallow الحالية، لكل من نطاقات AOSP SELinux بالإضافة إلى النطاقات الخاصة بالجهاز/المورّد.
• [C-1-5] يجب تشغيل التطبيقات التابعة لجهات خارجية التي تستهدف مستوى واجهة برمجة التطبيقات 28 أو أعلى في أدوات وضع الحماية في SELinux لكل تطبيق مع قيود SELinux لكل تطبيق على كل directory البيانات الخاصة بالتطبيق.
• يجب الاحتفاظ بسياسة SELinux التلقائية المقدَّمة في مجلد system/sepolicy ضمن مشروع Android Open Source Project الأساسي، وإضافة المزيد إلى هذه السياسة فقط لإعدادات الجهاز الخاصة بكل مصنع.

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

• [C-2-1] يجب استخدام نظام تحكّم إجباري في الوصول يكون مكافئًا لنظام SELinux.

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

• [C-SR-8] يُنصح بشدة بعزل كل جهاز إدخال/إخراج قادر على نقل البيانات المباشر (DMA)، باستخدام وحدة إدارة الذاكرة (IOMMU) (مثل ARM SMMU).

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

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

• [C-SR-9] يُنصح بشدة باختبارها باستخدام أدوات رصد أخطاء ملف الذاكرة في مساحة المستخدم، مثل MTE لأجهزة ARMv9 أو HWASan لأجهزة ARMv8 والإصدارات الأحدث أو ASan لأنواع الأجهزة الأخرى.
• [C-SR-10] يُنصح بشدة باختبارها باستخدام أدوات رصد أخطاء ذاكرة kernel مثل KASAN (CONFIG_KASAN أو CONFIG_KASAN_HW_TAGS لأجهزة ARMv9 أو CONFIG_KASAN_SW_TAGS لأجهزة ARMv8 أو CONFIG_KASAN_GENERIC لأنواع الأجهزة الأخرى).
• [C-SR-11] يُنصح بشدة باستخدام أدوات رصد أخطاء الذاكرة في مرحلة التطوير، مثل MTE وGWP-ASan وKFENCE.

إذا كانت عمليات تنفيذ الأجهزة تستخدم وحدة معالجة آمنة (TEE) مستندة إلى Arm TrustZone، فإنّها:

• [C-SR-12] يُنصح بشدة باستخدام بروتوكول عادي لمشاركة الذاكرة بين Android ووحدة TEE، مثل Arm Firmware Framework لمعالج Armv8-A (FF-A).
• [C-SR-13] يُنصح بشدة بحصر التطبيقات الموثوق بها في الوصول إلى الذاكرة التي تمت مشاركتها معهم صراحةً من خلال الخطوات المذكورة أعلاه. إذا كان الجهاز متوافقًا مع مستوى استثناء Arm S-EL2، يجب أن يفرض مدير الأقسام الآمنة هذا الإجراء. وبخلاف ذلك، يجب أن يتم فرض ذلك من خلال نظام التشغيل TEE.

9.8. الخصوصية

9.8.1. سجلّ الاستخدام

يخزِّن نظام التشغيل Android سجلّ خيارات المستخدم ويدير هذا السجلّ من خلال UsageStatsManager.

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

• [C-0-1] يجب الاحتفاظ بسجلّ المستخدمين هذا لفترة زمنية معقولة.
• [C-SR-1] يُنصح بشدة بالاحتفاظ بفترة الاحتفاظ التي تبلغ 14 يومًا كما هو الحال في الإعداد التلقائي لتنفيذ AOSP.

يخزِّن Android أحداث النظام باستخدام معرّفات StatsLog ، ويدير هذا السجلّ من خلال StatsManager و IncidentManager System API.

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

• [C-0-2] يجب أن يتضمّن تقرير الحادثة الذي أنشأته فئة System API IncidentManager الحقول التي تم وضع علامة DEST_AUTOMATIC عليها فقط.
• [C-0-3] يجب عدم استخدام معرّفات أحداث النظام لتسجيل أي حدث آخر غير ما هو موضّح في مستندات حزمة تطوير البرامج (SDK) StatsLog. في حال تسجيل أحداث نظام إضافية، قد تستخدم معرّف ذرة مختلفًا في النطاق بين 100,000 و200,000.

9.8.2. يتم التسجيل

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

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

إذا كانت عمليات تنفيذ الأجهزة تتضمّن وظيفة في النظام تلتقط المحتوى المعروض على الشاشة و/أو تسجّل البث الصوتي الذي يتم تشغيله على الجهاز بخلاف استخدام System API 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 "الأذونات" التي تحمل معرّف CDD‏ [C-3-X].
• [C-SR-5] يُنصح بشدة بعرض التطبيقات المستخدَمة مؤخرًا والتطبيقات النشطة باستخدام الكاميرا كما تظهر في PermissionManager.getIndicatorAppOpUsageData()، بالإضافة إلى أي رسائل تحديد مصدر مرتبطة بها.
• [C-SR-6] يُنصح بشدة بعدم إخفاء مؤشر الكاميرا لتطبيقات النظام التي تتضمّن واجهات مستخدم مرئية أو تفاعلًا مباشرًا مع المستخدم.

9.8.3. إمكانية الاتصال

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

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

9.8.4. حركة بيانات الشبكة

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

• [C-0-1] يجب تثبيت الشهادات الجذر نفسها مسبقًا لمتجر "هيئة إصدار الشهادات" (CA) الموثوق به على مستوى النظام على النحو الموضَّح في مشروع Android Open Source Project.
• [C-0-2] يجب شحن الجهاز مع متجر مرجع تصديق جذر فارغ للمستخدم.
• [C-0-3] يجب عرض تحذير للمستخدم يشير إلى أنّه قد تتم مراقبة كثافة حركة المرور على الشبكة عند إضافة مرجع تصديق جذر للمستخدم.

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

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

إذا كانت عمليات تنفيذ الأجهزة تتضمّن آلية مفعَّلة تلقائيًا بدون خطوات إضافية، والتي تُوجّه كثافة بيانات الشبكة من خلال خادم وكيل أو بوابة شبكة VPN (على سبيل المثال، تحميل خدمة VPN مسبقًا مع منح الإذن android.permission.CONTROL_VPN)، يجب استيفاء الشروط التالية:

• [C-2-1] يجب طلب موافقة المستخدم قبل تفعيل هذه الآلية، ما لم يفعّل وحدة التحكّم في سياسة الجهاز شبكة VPN هذه من خلال DevicePolicyManager.setAlwaysOnVpnPackage() . وفي هذه الحالة، لا يحتاج المستخدم إلى تقديم موافقة منفصلة، ولكن يجب إعلامه فقط.

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

• [C-3-1] يجب إيقاف ميزة المستخدم هذه للتطبيقات التي لا تتوافق مع خدمة شبكة VPN الدائمة في ملف AndroidManifest.xml من خلال ضبط سمة SERVICE_META_DATA_SUPPORTS_ALWAYS_ON على false.

9.8.5. معرّفات الأجهزة

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

• [C-0-1] يجب أن يمنع التطبيق الوصول إلى الرقم التسلسلي للجهاز ورقم IMEI/MEID والرقم التسلسلي لشريحة SIM ورقم التعريف الدولي للمشترك في خدمات الجوّال (IMSI) إن وُجد، ما لم يستوفِ أحد المتطلبات التالية:
  • هو تطبيق مشفَّر لمشغِّل شبكة الجوّال تم التحقّق منه من قِبل الشركات المصنّعة للأجهزة.
  • تم منح الإذن READ_PRIVILEGED_PHONE_STATE.
  • أن يكون لديه امتيازات مشغّل شبكة الجوّال على النحو المحدّد في امتيازات مشغّل شبكة الجوّال في شريحة UICC
  • هو مالك جهاز أو ملف تجاري تم منحه إذن READ_PHONE_STATE.
  • (بالنسبة إلى الرقم التسلسلي لشريحة SIM أو رقم ICCID فقط) يجب أن يستوفي التطبيق متطلبات اللوائح المحلية ويرصد التغيُّرات في هوية المشترك.

9.8.6. ميزة "تسجيل المحتوى" وميزة "بحث التطبيقات"

يتيح نظام التشغيل Android من خلال System API‏ ContentCaptureService أو AugmentedAutofillService أو AppSearchGlobalManager.query أو بوسائل أخرى خاصة آلية لعمليات التنفيذ على الأجهزة من أجل تسجيل التفاعلات التالية بين التطبيقات والمستخدمين في ما يتعلّق ببيانات التطبيقات:

• النصوص والرسومات المعروضة على الشاشة، بما في ذلك على سبيل المثال لا الحصر، الإشعارات وبيانات المساعدة من خلال واجهة برمجة التطبيقات AssistStructure
• بيانات الوسائط، مثل الصوت أو الفيديو، التي سجّلها الجهاز أو شغّلها
• أحداث الإدخال (مثل المفاتيح والفأرة والإيماءات والصوت والفيديو وإمكانية الاستخدام)
• أي أحداث أخرى يوفّرها التطبيق للنظام من خلال واجهة برمجة التطبيقات Content Capture أو واجهة برمجة التطبيقات AppSearchManager أو واجهة برمجة تطبيقات خاصة تابعة لشركة Android و ذات إمكانات مماثلة
• أي نص أو بيانات أخرى يتم إرسالها عبر TextClassifier API إلى System TextClassifier، أي خدمة النظام لفهم معنى النص، بالإضافة إلى إنشاء الإجراءات التالية المتوقّعة استنادًا إلى النص
• البيانات التي يتمّ فهرستها من خلال تنفيذ AppSearch على المنصة، بما في ذلك على سبيل المثال لا الحصر، النصوص أو الرسومات أو بيانات الوسائط أو البيانات الأخرى المشابهة

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

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

  • الاتصال الهاتفي وجهات الاتصال وواجهة مستخدم النظام والوسائط

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

9.8.7. الوصول إلى الحافظة

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

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

9.8.8. الموقع الجغرافي

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

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

• GPS/GNSS/DGPS/PPP
  • نظام تحديد المواقع العالمي أو نظام تحديد المواقع العالمي عبر الأقمار الصناعية أو نظام تحديد المواقع العالمي التفاضلي
  • ويشمل ذلك أيضًا قياسات GNSS الأوّلية وحالة GNSS.
    • يمكن الحصول على الموقع الجغرافي الدقيق من قياسات GNSS الأوّلية.
• التكنولوجيات اللاسلكية التي تتضمّن معرّفات فريدة، مثل:
  • نقاط وصول Wi-Fi (عنوان MAC أو معرّف مجموعة الخدمات الأساسي أو الاسم أو SSID)
  • البلوتوث/تقنية BLE (عنوان MAC أو معرّف مجموعة الخدمات الأساسية أو الاسم أو SSID)
  • النطاق الفائق العرض (MAC أو BSSID أو الاسم أو SSID)
  • رقم تعريف برج الخلية (الجيل الثالث والرابع والخامس وما إلى ذلك، بما في ذلك جميع تكنولوجيات مودم الخلية المستقبلية التي تتضمّن معرّفات فريدة)

كنقطة مرجعية أساسية، يمكنك الاطّلاع على واجهات برمجة تطبيقات Android التي تتطلّب أذونات ACCESS_FINE_Location أو ACCESS_COARSE_Location.

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

• [C-0-1] يجب عدم تفعيل/إيقاف إعدادات الموقع الجغرافي للجهاز وإعدادات فحص شبكة Wi-Fi/البلوتوث بدون موافقة صريحة من المستخدم أو بدء المستخدم لهذه العملية.
• [C-0-2] يجب أن يقدّم التطبيق للمستخدم إمكانية الوصول إلى المعلومات المتعلّقة بالموقع الجغرافي، بما في ذلك طلبات الموقع الجغرافي الأخيرة والأذونات على مستوى التطبيق واستخدام البحث عن نقاط الوصول إلى Wi-Fi/البلوتوث لتحديد الموقع الجغرافي.
• [C-0-3] يجب التأكّد من أنّ التطبيق الذي يستخدم واجهة برمجة التطبيقات Emergency Location Bypass API [LocationRequest.setLocationSettingsIgnored()] هو جلسة طوارئ بدأها المستخدم (مثل الاتصال بالرقم 911 أو إرسال رسالة نصية إلى 911). في ما يتعلّق بالمركبات، يجوز للمركبة بدء جلسة طوارئ بدون تفاعل نشط من المستخدم في حال رصد حادث (مثلاً لتلبية متطلبات eCall).
• [C-0-4] يجب الحفاظ على قدرة Emergency Location Bypass API على تجاوز إعدادات الموقع الجغرافي للجهاز بدون تغيير الإعدادات.
• [C-0-5] يجب تحديد موعد لإرسال إشعار يذكّر المستخدم بعد أن يصل أحد التطبيقات في الخلفية إلى موقعه الجغرافي باستخدام إذن [ACCESS_BACKGROUND_LOCATION].

9.8.9. التطبيقات المثبّتة

لا يمكن لتطبيقات Android التي تستهدف المستوى 30 أو أعلى من واجهة برمجة التطبيقات الاطّلاع على تفاصيل عن التطبيقات المثبّتة الأخرى تلقائيًا (اطّلِع على مستوى ظهور الحِزمة في مستندات IDE IDE لنظام 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. مشاركة البيانات

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

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

• [C-1-1] يجب عدم مشاركة ملفات البيانات التي تنتمي إلى التطبيقات بما يتجاوز ما هو مقصود للسماح به (أي نطاق الوصول التلقائي وأوضاع الوصول الأخرى التي يمكن تحديدها باستخدام BlobStoreManager.session#allowPackageAccess()‎ أو BlobStoreManager.session#allowSameSignatureAccess()‎ أو BlobStoreManager.session#allowPublicAccess()‎). يستوفي التنفيذ المرجعي لنظام التشغيل AOSP هذه المتطلبات.
• [C-1-2] يجب عدم إرسال التجزئات الآمنة لملفات البيانات (التي تُستخدَم للتحكّم في الوصول) خارج الجهاز أو مشاركتها مع تطبيقات أخرى.

9.8.12. Music Recognition

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

إذا كانت عمليات تنفيذ الأجهزة تتضمّن خدمة تنفِّذ واجهة برمجة التطبيقات System API MusicRecognitionManager أو أي خدمة خاصة تبث بيانات صوتية كما هو описан أعلاه، يجب استيفاء الشروط التالية:

• [C-1-1] يجب فرض أن يكون لدى المُرسِل إلى MusicRecognitionManager إذن MANAGE_MUSIC_RECOGNITION
• [C-1-2] يجب أن يفرض التطبيق المُثبَّت مُسبقًا والمخصّص للتعرّف على الموسيقى استخدام MusicRecognitionService.
• [C-1-3] يجب عدم السماح للمستخدمين باستبدال MusicRecognitionManagerService أو MusicRecognitionService بتطبيق أو خدمة يمكن للمستخدم تثبيتهما.
• [C-1-4] يجب التأكّد من أنّه عند وصول MusicRecognitionManagerService إلى تسجيل المقطع الصوتي وإعادة توجيهه إلى التطبيق الذي ينفِّذ MusicRecognitionService، يتم تتبُّع الوصول إلى المقطع الصوتي من خلال عمليات استدعاء AppOpsManager.noteOp / startOp.

إذا كانت عمليات تنفيذ MusicRecognitionManagerService أو MusicRecognitionService على الأجهزة تخزِّن أي بيانات صوتية تم تسجيلها، يجب أن تستوفي المتطلبات التالية:

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

9.8.13. SensorPrivacyManager

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

• [C-1-1] يجب أن تعرِض بدقة القيمة "صحيح" لطريقة واجهة برمجة التطبيقات ذات الصلة supportsSensorToggle().
• [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] يجب مواصلة بث طلبات 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

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] إذا كان الجهاز يتضمّن تعليمات Advanced Encryption Standard (AES) (مثل ARMv8 Cryptography Extensions على الأجهزة المستندة إلى ARM أو AES-NI على الأجهزة المستندة إلى x86)، يجب استخدام الخيارات المستندة إلى AES أعلاه لتشفير اسم الملف، ومحتوى الملف، والبيانات الوصفية لنظام الملفات، وليس Adiantum.
• [C-1-13] يجب استخدام دالة اشتقاق مفاتيح تشفير قوية وغير قابلة للعكس (مثل HKDF-SHA512) لاشتقاق أي مفاتيح فرعية مطلوبة (مثل مفاتيح كل ملف) من مفاتيح التشفير والتشفير العكسي. تعني عبارة "قوية من الناحية التشفيرية وغير قابلة للعكس" أنّ دالة اشتقاق المفتاح تتمتع بقوة أمان تبلغ 256 بت على الأقل وتتصرف كـ عائلة دالة pseudorandom على مدخلاتها.
• [C-1-14] يجب عدم استخدام مفاتيح التشفير المستند إلى الملفات (FBE) أو مفاتيح التشفير الفرعية لأغراض تشفير مختلفة (مثل التشفير وتحديد المفتاح أو خوارزميات تشفير مختلفة).
• [C-1-15] يجب التأكّد من أنّه تم تشفير جميع الكتل غير المحذوفة من محتوى الملف المشفَّر في مساحة التخزين الثابتة باستخدام مجموعات من مفتاح التشفير وملفه المبتدئ (IV) التي تعتمد على كل من الملف وقيمة الإزاحة في الملف. بالإضافة إلى ذلك، يجب أن تكون جميع هذه التركيبات مختلفة، باستثناء الحالات التي يتم فيها إجراء التشفير باستخدام أجهزة تشفير مضمّنة لا تتوافق إلا مع طول IV الذي يبلغ 32 بت.
• [C-1-16] يجب التأكّد من أنّه تم تشفير جميع أسماء الملفات المشفّرة غير المحذوفة في مساحة التخزين الدائمة في أدلة مختلفة باستخدام مجموعات مختلفة من مفتاح التشفير ومتّجه الإعداد (IV).

• [C-1-17] يجب التأكّد من أنّه تم تشفير جميع مجموعات البيانات الوصفية المشفّرة لنظام الملفات على مساحة التخزين الثابتة باستخدام مجموعات مختلفة من مفتاح التشفير ومتجه الإعداد (IV).

• مفاتيح حماية مساحات تخزين CE وDE والبيانات الوصفية لنظام الملفات:

  • [C-1-7] يجب أن يكون مرتبطًا بشكل تشفير بملف تخزين مفاتيح مستند إلى الأجهزة. يجب ربط ملف تخزين المفاتيح هذا بميزة "التمهيد المتحقّق منه" و"جذر الثقة" لأجهزة الجهاز.
  • [C-1-8] يجب ربط مفاتيح التشفير المتقدّم ببيانات اعتماد شاشة القفل الخاصة بالمستخدم.
  • [C-1-9] يجب ربط مفاتيح التشفير المتقدّم برمز مرور تلقائي عندما لا يحدّد المستخدم بيانات اعتماد شاشة القفل.
  • [C-1-10] يجب أن يكون فريدًا ومميّزًا، بعبارة أخرى، لا يتطابق مفتاح CE أو DE لأي مستخدم مع مفاتيح CE أو DE الخاصة بأي مستخدم آخر.
  • [C-1-11] يجب استخدام التشفيرات وأطوال المفاتيح و الأوضاع المتوافقة بشكل إلزامي.
  • [C-1-12] يجب محو البيانات بأمان أثناء فتح قفل برنامج الإقلاع وقفله كما هو موضّح هنا.

• يجب أن تجعل التطبيقات الأساسية المثبَّتة مسبقًا (مثل المنبّه والهاتف وMessenger) على دراية بميزة "التشغيل المباشر".

يقدّم "المشروع المفتوح المصدر لنظام Android" الإصدار المفضّل من ميزة التشفير على مستوى الملفات استنادًا إلى ميزة التشفير "fscrypt" في نواة Linux، وميزة تشفير البيانات الوصفية استنادًا إلى ميزة "dm-default-key" في نواة Linux.

9.9.3.2. التشفير على مستوى الكتلة لكل مستخدم

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

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

• [C-1-4] يجب استخدام AES-256-XTS لتشفير أقسام ملف التمهيد على مستوى الوحدات.

• المفاتيح التي تحمي الأجهزة المشفَّرة على مستوى الكتلة لكل مستخدم:

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

يمكن تنفيذ التشفير على مستوى الوحدات لكل مستخدم باستخدام ميزة "dm-crypt" في نواة Linux على الأقسام الخاصة بكل مستخدم.

9.9.4. استئناف العمل عند إعادة التشغيل

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

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

وعلى وجه التحديد:

• [C-0-1] يجب ألا يكون تخزين "التشفير من جهة العميل" قابلاً للقراءة حتى للمهاجم الذي يملك الجهاز جسديًا ويحصل بعد ذلك على الإمكانات والقيود التالية:

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

على سبيل المثال، فإنّ عملية تنفيذ الجهاز التي تنفِّذ وتلتزم بكل الأوصاف المتوفّرة هنا ستكون متوافقة مع [C-0-1].

9.10. سلامة الجهاز

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

• [C-0-1] يجب الإبلاغ بشكل صحيح من خلال طريقة System API PersistentDataBlockManager.getFlashLockState() عمّا إذا كانت حالة bootloader تسمح بفلاش صورة النظام.

• [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] يجب استخدام وحدة تخزين تُظهر أي عبث: لتخزين ما إذا كان bootloader قد تم فتح قفله. تعني ميزة "التخزين الذي يكشف التلاعب" أنّه يمكن لبرنامج التمهيد اكتشاف ما إذا تم التلاعب بوحدة التخزين من داخل نظام التشغيل Android.
• [C-1-9] يجب أن يطلب الجهاز من المستخدم تأكيدًا أثناء استخدامه، وقبل السماح بالانتقال من وضع bootloader المقفل إلى وضع bootloader المُفعَّل.
• [C-1-10] يجب توفير حماية لإعادة الترجيع للأقسام التي يستخدمها نظام التشغيل Android (مثل أقسام التمهيد والنظام) واستخدام مساحة تخزين مقاومة للتلاعب لتخزين البيانات الوصفية المستخدَمة لتحديد الحد الأدنى المسموح به لإصدار نظام التشغيل.
• [C-1-11] يجب محو جميع بيانات المستخدم بأمان أثناء فتح قفل برنامج الإقلاع و قفله، وفقًا لـ "9.12". حذف البيانات (بما في ذلك قسم userdata و أي مساحات NVRAM)
• [C-SR-2] يُنصح بشدة بالتحقق من جميع ملفات APK الخاصة بالتطبيقات المميّزة باستخدام سلسلة ثقة تستند إلى أقسام محمية من خلال ميزة "التمهيد التحقق منه".
• [C-SR-3] يُنصح بشدة بالتحقق من أي عناصر قابلة للتنفيذ يحمّلها تطبيق مفوَّض من خارج ملف APK (مثل الرمز الذي يتم تحميله ديناميكيًا أو الرمز المجمّع) قبل تنفيذها أو يُنصح بشدة بعدم تنفيذها إطلاقًا.
• يجب أن توفّر الحماية من العودة إلى الإصدارات السابقة لأي مكوّن يحتوي على برمجية أساسية دائمة (مثل المودم والكاميرا)، ويجب أن تستخدم مساحة تخزين مقاومة للتلاعب لحفظ البيانات الوصفية المستخدَمة لتحديد الحد الأدنى للإصدار المسموح به.

إذا سبق أن تم إطلاق عمليات تنفيذ الأجهزة بدون توفير متطلبات C-1-8 إلى C-1-11 على إصدار أقدم من Android ولا يمكن إضافة متطلبات هذه المتطلبات من خلال تحديث لنظام التشغيل، قد يتم استثناءها من المتطلبات.

يقدّم مشروع Android Open Source Project (المعروف أيضًا باسم "المشروع المصدري") طريقة تنفيذ مفضّلة لهذه الميزة في مستودع external/avb/ ، ويمكن دمجها في أداة تحميل البرامج الثابتة المستخدَمة لتحميل نظام Android.

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

• [C-0-3] يجب أن تتيح التحقق من محتوى الملف من خلال التشفير باستخدام مفتاح موثوق به بدون قراءة الملف بأكمله.
• [C-0-4] يجب عدم السماح بنجاح طلبات القراءة في ملف محمي عندما لا يتم التحقّق من صحة المحتوى المقروء باستخدام مفتاح موثوق.

إذا سبق أن تم إطلاق عمليات تنفيذ الأجهزة بدون إمكانية التحقّق من محتوى الملف باستخدام مفتاح موثوق به على إصدار Android سابق ولا يمكنه إضافة دعم لهذه الميزة من خلال تحديث لنظام التشغيل، قد يتم استثناءه من الشرط. يقدّم مشروع Android Open Source التلقائي طريقة تنفيذ مفضّلة لهذه الميزة استنادًا إلى ميزة fs-verity في نواة Linux.

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

• [C-SR-4] يُنصح بشدة بتوفُّر Android Protected Confirmation API.

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

• [C-3-1] يجب الإبلاغ عن true لواجهة برمجة التطبيقات ConfirmationPrompt.isSupported().

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

• [C-3-3] يجب التأكّد من أنّ المستخدم تمكّن من مراجعة الرسالة المطلوبة والموافقة عليها حتى في حال اختراق نظام التشغيل Android، بما في ذلك النواة.

9.11. المفاتيح وبيانات الاعتماد

يسمح نظام Android Keystore لمطوّري التطبيقات بتخزين مفاتيح التشفير في حاوية واستخدامها في عمليات التشفير من خلال KeyChain API أو Keystore API. عمليات التنفيذ على الأجهزة:

• [C-0-1] يجب أن يسمح بتصدير أو إنشاء 8,192 مفتاحًا على الأقل.
• [C-0-2] يجب أن تطبّق مصادقة شاشة القفل فاصلاً زمنيًا بين المحاولات غير الناجحة. مع n كعدد المحاولات الفاشلة، يجب أن يكون الفاصل الزمني 30 ثانية على الأقل عندما يكون العدد 9 < n < 30. إذا كان n أكبر من 29، يجب أن تكون قيمة الفاصل الزمني 30*2^floor((n-30)/10)) ثانية على الأقل أو 24 ساعة على الأقل، أيهما أصغر.
• يجب عدم وضع حدّ لعدد المفاتيح التي يمكن إنشاؤها

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

• [C-1-1] يجب الاحتفاظ بنسخة احتياطية من عملية تنفيذ ملف تخزين المفاتيح باستخدام بيئة تنفيذ معزولة.
• [C-1-2] يجب أن تتضمّن تطبيقات نظام Android Keystore لتنفيذ خوارزميات التشفير RSA وAES وECDSA وHMAC ودوال تجزئة مجموعة MD5 وSHA1 وSHA-2 لكي تتوافق بشكلٍ سليم مع خوارزميات نظام Android Keystore المتوافقة في منطقة معزولة بشكلٍ آمن عن الرمز البرمجي الذي يتم تشغيله على النواة والإصدارات الأحدث. يجب أن يؤدي العزل الآمن إلى منع كل الآليات المحتمَلة التي يمكن من خلالها لرمز kernel أو مساحة المستخدم الوصول إلى الحالة الداخلية للبيئة المعزولة، بما في ذلك DMA. يستوفي "المشروع المفتوح المصدر لنظام Android" (AOSP) هذا الشرط من خلال استخدام تنفيذ Trusty، ولكن هناك خياران بديلان: أحدهما هو حلّ آخر يستند إلى ARM TrustZone أو تنفيذ آمن تمت مراجعته من قِبل جهة خارجية لعزل مناسب يستند إلى أداة إدارة الأجهزة الافتراضية.
• [C-1-3] يجب إجراء مصادقة شاشة القفل في بيئة التنفيذ المعزولة والسماح باستخدام المفاتيح المرتبطة بالمصادقة فقط بعد المصادقة الناجحة. يجب تخزين بيانات اعتماد شاشة القفل بطريقة تسمح فقط لبيئة التنفيذ المعزولة بإجراء مصادقة شاشة القفل. يقدّم مشروع Android Open Source Project الإصدارات السابقة من Gatekeeper Hardware Abstraction Layer (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
• [C-SR-1] يُنصح بشدة بتوفير الإصدار 1 من IKeyMintDevice.

9.11.1. شاشة القفل الآمنة والمصادقة

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

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

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

يُرجى العلم أنّه تتم الإشارة إلى طرق المصادقة المذكورة أعلاه على أنّها methodsprimary methods مصادقة primary methods مقترَحة في هذا المستند.

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

• [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()‎ باستخدام ثابت أكثر تقييدًا من PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-3-5] يجب أن تعتمد طرق المصادقة الجديدة على methods methods primary authentication primary (مثل رقم التعريف الشخصي أو النمط أو كلمة المرور) مرة واحدة كل 72 ساعة أو أقل، أو أن تُفصح بوضوح للمستخدم عن عدم الاحتفاظ بنسخة احتياطية من بعض البيانات للحفاظ على خصوصية بياناته.

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

• [C-4-1] يجب أن تستوفي جميع المتطلبات الموضّحة في الفقرة 7.3.10 لفئة الدرجة 1 (التي كانت تُعرف سابقًا باسم الراحة).
• [C-4-2] يجب أن تتوفّر آلية احتياطية لاستخدام إحدى طرق المصادقة الأساسية المُقترَحة والتي تستند إلى سر معروف.
• [C-4-3] يجب إيقافه والسماح فقط بالمصادقة الأساسية المُقترَحة لفتح قفل الشاشة عندما يضبط تطبيق Device Policy Controller (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] يجب إيقاف الطريقة الجديدة والسماح باستخدام إحدى methods طرق المصادقة الأساسية المقترَحة فقط لفتح قفل الشاشة عندما يضبط تطبيق وحدة التحكّم بسياسة الجهاز (DPC) السياسة باستخدام أيّ مما يلي:
  • طريقة DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS)
  • DevicePolicyManager.setPasswordQuality() باستخدام طريقة ثبات جودة أكثر تقييدًا من PASSWORD_QUALITY_NONE
  • طريقة DevicePolicyManager.setRequiredPasswordComplexity() التي تتضمّن مجموعة تعقيد أكثر تقييدًا من PASSWORD_COMPLEXITY_NONE
• [C-6-3] يجب أن يُطلب من المستخدم إدخال إحدى طرق المصادقة الأساسية المُقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) مرة واحدة على الأقل كل 4 ساعات أو أقل.
• [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 Television أو جهاز Automotive).
• [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] يجب عدم السماح لخدمات TrustAgent على الأجهزة الشخصية الأساسية (مثل الأجهزة الجوّالة) بفتح قفل الجهاز، ولا يمكن استخدامها إلا للحفاظ على حالة فتح قفل جهاز سبق أن تم فتح قفله لمدة تصل إلى 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] يجب عدم إتاحة واجهة برمجة تطبيقات للاستخدام من قِبل التطبيقات التابعة لجهات خارجية بهدف تغيير حالة القفل.

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

عمليات تنفيذ الأجهزة التي تتضمّن معالجًا آمنًا مخصّصًا:

• [C-SR-1] يُنصح بشدة بتوفير StrongBox. من المحتمل أن يصبح استخدام StrongBox شرطًا أساسيًا في إصدار مستقبلي.

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

• [C-1-1] يجب الإفصاح عن FEATURE_STRONGBOX_KEYSTORE.

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

• [C-1-3] يجب أن يكون هناك وحدة معالجة مركزية منفصلة لا تشارك ذاكرة التخزين المؤقت أو ذاكرة الوصول العشوائي الديناميكية أو المعالجات الملحقة أو الموارد الأساسية الأخرى مع معالج التطبيقات (AP).

• [C-1-4] يجب التأكّد من أنّ أي أجهزة طرفية تمت مشاركتها مع نقطة الوصول لا يمكنها تغيير معالجة StrongBox بأي شكل من الأشكال أو الحصول على أي معلومات من StrongBox. يجوز لمسؤول نقطة الربط إيقاف StrongBox أو حظر الوصول إليه.

• [C-1-5] يجب أن يكون لدى الجهاز ساعة داخلية بدقة معقولة (+-10%) تكون محصّنة من التلاعب بها من خلال نقطة الوصول.

• [C-1-6] يجب أن يتضمّن مولد أرقام عشوائية حقيقي ينتج ناتجًا موزّعًا بشكلٍ موحّد وغير متوقّع.

• [C-1-7] يجب أن يكون الجهاز مقاومًا للعبث، بما في ذلك المقاومة ضد الاختراق المادي والأعطال.

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

• [C-1-9] يجب أن يكون لدى التطبيق مساحة تخزين آمنة تضمن سرية المحتوى وسلامته وأصالته واتساقه وحداثته. يجب ألا يكون بالإمكان قراءة مساحة التخزين أو تغييرها، إلا على النحو الذي تسمح به واجهات برمجة تطبيقات StrongBox.

• للتحقّق من الامتثال للفقرات من [C-1-3] إلى [C-1-9]، يجب أن تستوفي عمليات تنفيذ على الأجهزة الشروط التالية:

  • [C-1-10] يجب أن يتضمّن الجهاز المعتمد وفقًا لملف الحماية لشرائح IC الآمنة BSI-CC-PP-0084-2014 أو الذي تم تقييمه من قِبل مختبر اختبار معتمَد على مستوى البلد والذي يتضمّن تقييمًا للثغرات الأمنية العالية الخطورة وفقًا لـ المعايير المشتركة لتطبيق احتمالية الهجوم على البطاقات الذكية.
  • [C-1-11] يجب أن تتضمّن البرامج الثابتة التي يتم تقييمها من قِبل مختبر اختبار معتمَد على المستوى الوطني، مع تضمين تقييم مرتفع لإمكانية حدوث ثغرة أمنية وفقًا لتقييم المعايير المشتركة لتطبيق احتمالية الهجوم على البطاقات الذكية.
  • [C-SR-2] يُنصح بشدة بتضمين الأجهزة التي يتم تقييمها باستخدام مستوى ضمان التقييم (EAL) 5 لهدف الأمان، مع إضافة AVA_VAN.5. من المرجّح أن يصبح الحصول على شهادة EAL 5 شرطًا أساسيًا في إصدار مستقبلي.

• [C-SR-3] يُنصح بشدة بتوفير مقاومة للهجوم من الداخل (IAR)، ما يعني أنّه لا يمكن لأحد من الداخل الوصول إلى مفاتيح توقيع البرامج الثابتة لإنشاء برنامج ثابت يؤدي إلى تسرُّب الأسرار من StrongBox أو تجاوز متطلبات أمان الوظائف أو السماح بالوصول إلى بيانات المستخدمين الحسّاسة بأي شكل آخر. إنّ الطريقة المقترَحة لتنفيذ IAR هي السماح بتحديثات البرامج الثابتة فقط عند تقديم كلمة مرور المستخدم الأساسية من خلال HAL IAuthSecret.

9.11.3. بيانات اعتماد الهوية

يتم تحديد نظام بيانات الاعتماد الخاصة بالهوية وتحقيقه من خلال تنفيذ كل واجهة برمجة تطبيقات في حزمة android.security.identity.*. تسمح واجهات برمجة التطبيقات هذه لمطوّري التطبيقات بتخزين مستندات هوية المستخدِم واستردادها. عمليات التنفيذ على الأجهزة:

• [C-SR-1] يُنصح بشدة بتنفيذ ملف تعريف هوية النظام.

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

• [C-1-1] يجب أن تُعرِض الطريقة IdentityCredentialStore#getInstance()‎ قيمة غير صفرية.

• [C-1-2] يجب تنفيذ نظام بيانات الاعتماد الخاصة بالهوية (مثل android.security.identity.* واجهات برمجة التطبيقات) باستخدام رمز برمجي يتواصل مع تطبيق موثوق به في منطقة معزولة بشكل آمن عن الرمز البرمجي الذي يعمل على النواة والإصدارات الأحدث. يجب أن تحظر ميزة "العزل الآمن" جميع الآليات المحتملة التي يمكن من خلالها لرمز kernel أو مساحة المستخدم الوصول إلى الحالة الداخلية للبيئة المعزولة، بما في ذلك DMA.

• [C-1-3] يجب تنفيذ العمليات التشفيرية اللازمة لتنفيذ نظام ملف تعريف الاعتماد المرتبط بهوية المستخدم (مثل واجهات برمجة التطبيقات android.security.identity.*) بالكامل في التطبيق الموثوق، ويجب عدم إزالة مادة المفتاح الخاص نهائيًا من بيئة التنفيذ المعزولة ما لم تطلب واجهات برمجة التطبيقات ذات المستوى الأعلى ذلك على وجه التحديد (مثل الأسلوب createEphemeralKeyPair()‎ ).

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

9.12. حذف البيانات

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

• [C-0-1] يجب أن يوفّر التطبيق للمستخدمين آلية لإجراء "إعادة ضبط الجهاز على الإعدادات الأصلية".
• [C-0-2] يجب حذف جميع البيانات في نظام ملفات userdata عند تنفيذ "إعادة الضبط على الإعدادات الأصلية".
• [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 framework لمنع التفاعل الضار أو غير المقصود مع هذه الأنظمة الفرعية.

9.15. خطط الاشتراك

تشير "خطط الاشتراك" إلى تفاصيل خطة العلاقة مع جهة الفوترة التي يوفّرها مشغّل شبكة الجوّال من خلال SubscriptionManager.setSubscriptionPlans().

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

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

9.16. نقل بيانات التطبيقات

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

• [C-1-1] يجب عدم بدء عمليات نقل بيانات التطبيق من الأجهزة التي لم يضبط المستخدم فيها مصادقة أساسية على النحو описан في 9.11.1 شاشة القفل الآمنة والمصادقة.
• [C-1-2] يجب تأكيد المصادقة الأساسية على جهاز النسخ بأمان والتأكّد من نية المستخدم في نسخ البيانات على جهاز النسخ قبل نقل أي بيانات.
• [C-1-3] يجب استخدام شهادة مفتاح الأمان لضمان أنّ كلاً من الجهاز المصدر والجهاز المستهدَف في عملية نقل البيانات من جهاز إلى آخر هما جهازَا Android شرعيَان وأنّ برنامج الإقلاع فيهما مقفل.
• [C-1-4] يجب نقل بيانات التطبيق إلى التطبيق نفسه على الجهاز المستهدَف فقط، باستخدام اسم الحزمة وشهادة التوقيع نفسها.
• [C-1-5] يجب أن تعرض قائمة الإعدادات في الجهاز المصدر مؤشرًا على أنّه تم نقل بياناته من خلال عملية نقل بيانات من جهاز إلى آخر. يجب ألا يتمكّن المستخدم من إزالة هذا الرمز.

10. اختبار توافق البرامج

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

10.1. مجموعة أدوات اختبار التوافق

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

• [C-0-1] يجب اجتياز مجموعة اختبار التوافق مع Android (CTS) المتوفّرة من "المشروع المفتوح المصدر لنظام Android"، باستخدام الإصدار النهائي من البرنامج على الجهاز.

• [C-0-2] يجب التأكّد من التوافق في حالات الغموض في CTS وأي عمليات إعادة تنفيذ لأجزاء من الرمز المصدر المرجعي.

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

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

• [C-0-3] يجب اجتياز أحدث إصدار من مجموعة أدوات اختبار التوافق (CTS) المتاح في وقت اكتمال برمجة الجهاز.

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

10.2. أداة إثبات ملكية CTS

يتم تضمين أداة التحقّق من CTS في مجموعة اختبار التوافق، ويُفترض أن يشغّلها مشغل بشري لاختبار الوظائف التي لا يمكن لنظام آلي اختبارها، مثل الأداء الصحيح للكاميرا والأجهزة الاستشعارية.

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

• [C-0-1] يجب تنفيذ جميع الحالات السارية بشكل صحيح في أداة التحقّق من CTS.

يتضمّن أداة CTS Verifier اختبارات لأنواع كثيرة من الأجهزة، بما في ذلك بعض الأجهزة التي تكون اختيارية.

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

• [C-0-2] يجب أن يجتاز الجهاز جميع اختبارات الأجهزة التي يمتلكها. على سبيل المثال، إذا كان الجهاز يحتوي على مقياس تسارع، يجب أن ينفذ بشكل صحيح حالة اختبار مقياس التسارع في أداة التحقّق من التوافق (CTS Verifier).

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

• [C-0-2] يجب أن يشغّل كل جهاز وكل إصدار أداة CTS Verifier بشكل صحيح، كما هو موضّح أعلاه. ومع ذلك، بما أنّ العديد من النُسخ متشابهة جدًا، لا يُتوقّع من مُنفّذِي الأجهزة استخدام أداة CTS Verifier بشكل صريح على النُسخ التي تختلف فقط بطرق بسيطة. وعلى وجه التحديد، قد يتم حذف اختبار CTS Verifier في عمليات تنفيذ الأجهزة التي تختلف عن عملية تنفيذ اجتازت أداة CTS Verifier فقط من خلال مجموعة اللغات والعلامات التجارية المضمّنة وما إلى ذلك.

11. البرامج القابلة للتحديث

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

  • تنزيل التحديثات عبر شبكة غير سلكية (OTA) مع التحديث بلا إنترنت من خلال إعادة التشغيل
  • يتم إجراء التحديثات "اللاسلكية" عبر USB من جهاز كمبيوتر مضيف.
  • يتم إجراء التحديثات "بلا إنترنت" من خلال إعادة تشغيل الجهاز وإجراء التحديث من ملف على مساحة تخزين قابلة للإزالة.

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

• [C-0-3] يجب توقيع التحديث بالكامل، ويجب أن تتحقّق آلية التحديث على الجهاز من التحديث والتوقيع مقارنةً بمفتاح عام مخزّن على الجهاز.

• [C-SR-1] يُنصح بشدة باستخدام آلية التوقيع لتجزئة التحديث باستخدام SHA-256 والتحقّق من التجزئة مقارنةً بالمفتاح العام باستخدام ECDSA NIST P-256.

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

• [C-1-1] يجب أن يتيح الجهاز تنزيل التحديثات من خلال شبكة الجوّال مع تحديث بلا إنترنت من خلال إعادة التشغيل.

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

ويجب أيضًا أن تتيح عمليات تنفيذ الأجهزة تحديثات نظام A/B. ينفِّذ نظام التشغيل AOSP هذه الميزة باستخدام واجهة برمجة التطبيقات لنظام التحكّم في عملية التمهيد.

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

• [C-2-1] على مُنفِّذ الجهاز تصحيح الخطأ من خلال تحديث البرامج المتاح الذي يمكن تطبيقه وفقًا للآلية الموضّحة للتو.

يتضمّن نظام التشغيل Android ميزات تتيح لتطبيق "مالك الجهاز" (في حال توفّره) التحكّم في تثبيت تحديثات النظام. إذا أبلغ نظام تحديث النظام الفرعي للأجهزة عن android.software.device_admin، يتم تنفيذ ما يلي:

• [C-3-1] يجب تنفيذ السلوك الموضّح في فئة SystemUpdatePolicy.

12. سجلّ تغييرات المستندات

في ما يلي ملخّص للتغييرات التي طرأت على تعريف التوافق في هذا الإصدار:

• سجلّ التغييرات في المستند

في ما يلي ملخّص للتغييرات التي طرأت على أقسام الأفراد:

1. المقدّمة
2. أنواع الأجهزة
3. البرامج
4. تجميع التطبيقات
5. الوسائط المتعددة
6. أدوات المطوّرين وخياراتهم
7. توافق الأجهزة
8. الأداء واستهلاك الطاقة
9. نموذج الأمان
10. اختبار توافق البرامج
11. البرامج القابلة للتحديث
12. سجلّ تغييرات المستندات
13. التواصل معنا

12.1. نصائح حول عرض سجلّ التغييرات

يتم وضع علامة على التغييرات على النحو التالي:

• CDD
  تغييرات جوهرية في متطلبات التوافق

• مستندات Google
  التغييرات المتعلقة بالمظهر أو بالإصدار

للحصول على أفضل تجربة عرض، يمكنك إلحاق مَعلمتَي pretty=full وno-merges لعنوان URL بعناوين URL الخاصة بملف ملفّات التعديل.

13. التواصل معنا

يمكنك الانضمام إلى منتدى توافق Android وطلب توضيحات أو طرح أي مشاكل تعتقد أنّ المستند لا يتناولها.