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

1. مقدّمة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.1. الأجهزة

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

• [7.1.1.1/H-0-1] يجب أن يكون الجهاز مزوّدًا بشاشة متوافقة مع Android على الأقل تستوفي جميع المتطلبات описанة في هذا المستند. يجب أن يكون حجم الشاشة 5.6 سم على الأقل على الحافة القصيرة و8.6 سم على الحافة الطويلة.

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

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

بدء متطلبات جديدة

• [7.1.1.1/H-0-3]* يجب ربط كل UI_MODE_NORMAL شاشة متوفّرة للتطبيقات التابعة لجهات خارجية بمنطقة شاشة جسدية بدون عائق مساحتها 5.6 سم على الأقل على الحافة القصيرة و8.6 سم على الحافة الطويلة.

• [7.1.1.3/H-0-1]* يجب ضبط قيمة DENSITY_DEVICE_STABLE لتكون ‎92% أو أعلى من الكثافة الفعلية للشاشة المقابلة.

إنهاء المتطلبات الجديدة

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

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

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

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

بدء متطلبات جديدة

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

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

إنهاء المتطلبات الجديدة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

بدء متطلبات جديدة

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

• [7.4.3/H-1-3] يجب قياس ناتج Rx المعدَّل وتعويضه لضمان أن يكون متوسّط RSSI لتقنية BLE هو -50 ديسي بل +/-15 ديسي بل على مسافة 1 متر من جهاز مرجعي يُرسِل البيانات بسرعة ADVERTISE_TX_POWER_HIGH.
• [7.4.3/H-1-4] يجب قياس ناتج الإرسال المتغيّر وتعويضه لضمان أن يكون متوسّط مؤشر RSSI لتقنية BLE هو -50 ديسي بل +/-15 ديسي بل عند البحث من جهاز مرجعي على مسافة متر واحد ويُرسِل البيانات بسرعة ADVERTISE_TX_POWER_HIGH.

إنهاء المتطلبات الجديدة

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

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

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

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

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

• [7.6.1/H-1-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 416 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم دقة 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 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم درجات دقة إطار الذاكرة حتى دقة عالية+ (مثلاً، دقة عالية أو 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 الخاصة بالتطبيق (المعروفة أيضًا باسم قسم "‎/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 عند إدخال مقبس، ولكن فقط بعد تحديد واجهات الصوت ونقاط النهاية 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 لسمة "microphone" الإضافية.

عند استدعاء واجهة برمجة التطبيقات 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/H-1-1] يجب أن يكون متوسّط وقت الاستجابة المستمر للرحلة المتبادلة 300 ملي ثانية أو أقل على مدار 5 قياسات، مع متوسّط انحراف مطلق أقل من 30 ملي ثانية، على مدار مسارات البيانات التالية: "مكبّر الصوت إلى الميكروفون"، محوّل حلقة 3.5 ملم (في حال توفّره)، حلقة USB (في حال توفّرها).

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

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

• [7.10/ساعة]* يجب عدم استخدام كتلة دوّارة غريبة الأطوار (ERM) مشغّل لمسي (مُحرِّك اهتزازي).
• [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) وجميع الثوابت العامة القابلة للتطبيق PRIMITIVE_* لسمة اللمسات الغنية في android.os.VibrationEffect.Composition ، وهي (CLICK وTICK وLOW_TICK وQUICK_FALL وQUICK_RISE وSLOW_RISE وSPIN وTHUD). قد لا تكون بعض هذه العناصر الأساسية، مثل LOW_TICK وSPIN، قابلة للتنفيذ إلا إذا كان الهزّاز قادرًا على استخدام ترددات منخفضة نسبيًا.
• [7.10/H]* يجب اتّباع الإرشادات لربط الثوابت العامة في android.view.HapticFeedbackConstants بثوابت android.os.VibrationEffect المقترَحة، مع العلاقات المقابلة للسعة.
• [7.10/ساعة]* يجب أن تتّبع تقييم الجودة لواجهتَي برمجة التطبيقات createOneShot()‎ وcreateWaveform()‎.
• [7.10/H]* يجب التحقّق من أنّ نتيجة واجهة برمجة التطبيقات العامة android.os.Vibrator.hasAmplitudeControl()‎ تعكس إمكانات أداة الاهتزاز بشكل صحيح.
• [7.10/ساعة]* يجب وضع المحرِّك بالقرب من المكان الذي يتم عادةً فيه حمل الجهاز أو لمسه باليدين.

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

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

بدء متطلبات جديدة

• [7.10/ح] يجب وضع المحرِّك بالقرب من الموقع الذي يتم عادةً فيه حمل الجهاز أو لمسه باليدين.

إنهاء المتطلبات الجديدة

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

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

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

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

• [7.10/H]* يجب التحقّق من حالة التنفيذ من خلال تشغيل واجهتَي برمجة التطبيقات android.os.Vibrator.areAllEffectsSupported()‎ وandroid.os.Vibrator.arePrimitivesSupported()‎.

• [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.2/H-0-3] AV1

إنهاء المتطلبات الجديدة

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

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

بدء متطلبات جديدة

• [5.3/H-0-6] AV1

إنهاء المتطلبات الجديدة

2.2.3. البرامج

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

• [3.2.3.1/H-0-1] يجب أن يتضمّن التطبيق إمكانية معالجة طلبات ACTION_GET_CONTENT ACTION_OPEN_DOCUMENT ACTION_OPEN_DOCUMENT_TREE وACTION_CREATE_DOCUMENT كما هو موضّح في مستندات حزمة SDK، وأن يقدّم للمستخدم إمكانية الوصول إلى بيانات مقدّم المستندات باستخدام واجهة برمجة التطبيقات DocumentsProvider.
• [3.2.3.1/H-0-2]* يجب تحميل تطبيقات أو مكونات خدمة واحدة أو أكثر مزوّدة بمعالج للطلبات، وذلك لتطبيق جميع أنماط فلاتر الطلبات العامة التي تحدّدها طلبات التطبيق التالية المدرَجة هنا.
• [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] يُنصح بشدة بتنفيذ مساعد على الجهاز لمعالجة الإجراء المساعد.

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

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

بدء متطلبات جديدة

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

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

إنهاء المتطلبات الجديدة

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

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

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

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

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

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

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

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

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

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

• [3.8.16/H-1-4] يجب أن يعرض هذا العنصر المتاح للمستخدمين اسم كل تطبيق تابع لجهة خارجية يقدّم عناصر تحكّم من خلال واجهة برمجة التطبيقات ControlsProviderService بالإضافة إلى أي حقول محدّدة تقدّمها واجهات برمجة التطبيقات Control بدقة.

• [3.8.16/H-1-5] يجب أن يوفّر التطبيق للمستخدمين إمكانية إيقاف عناصر التحكّم في الجهاز غير المهمة لتوفير إمكانية المصادقة من خلال عناصر التحكّم المسجّلة من قِبل التطبيقات التابعة لجهات خارجية من خلال واجهتَي برمجة التطبيقات ControlsProviderService وControl Control.isAuthRequired.

بدء متطلبات جديدة

• [3.8.16/H-1-6] يجب أن تعرض عمليات تنفيذ الأجهزة إمكانية استخدام العنصر بدقة على النحو التالي:
  • إذا ضبط الجهاز القيمة config_supportsMultiWindow=true وأعلن التطبيق عن البيانات الوصفية META_DATA_PANEL_ACTIVITY في ملف تعريف الارتباط ControlsProviderService ، بما في ذلك ComponentName لنشاط صالح (على النحو المحدّد في واجهة برمجة التطبيقات)، يجب أن يضمِّن التطبيق النشاط المذكور في ميزة المستخدم هذه.
  • إذا لم يعلن التطبيق عن البيانات الوصفية META_DATA_PANEL_ACTIVITY، يجب أن يعرض الحقول المحدّدة كما تقدّمها واجهة برمجة التطبيقات ControlsProviderService بالإضافة إلى أي حقول محدّدة تقدّمها واجهات برمجة التطبيقات Control.
• [3.8.16/H-1-7] إذا كان التطبيق يعلن عن البيانات الوصفية META_DATA_PANEL_ACTIVITY، يجب أن يُرسِل قيمة الإعداد المحدّدة في [3.8.16/H-1-5] باستخدام EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS عند بدء النشاط المضمّن.

إنهاء المتطلبات الجديدة

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

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

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

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

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

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

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

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

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

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

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

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

بدء متطلبات جديدة

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

• [7.4.1.2/H-0-1] يجب الإفصاح عن ميزة التبديل android.software.telecom.
• [7.4.1.2/H-0-2] يجب تنفيذ إطار عمل الاتصالات السلكية واللاسلكية.

إنهاء المتطلبات الجديدة

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

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

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

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

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

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

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

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

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

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

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

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

بدء متطلبات جديدة

• [8.5/H-0-2]يجب أن يقدّم التطبيق للمستخدم إمكانية إيقاف تطبيق يشغّل خدمة تعمل في المقدّمة أو مهمة بدأها المستخدم.

إنهاء المتطلبات الجديدة

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

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

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

بدء متطلبات جديدة

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

• [9.5/H-1-1] يجب عدم ضبط UserManager.isHeadlessSystemUserMode على true.

إنهاء المتطلبات الجديدة

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

• [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 وحدة.

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

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

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

بدء متطلبات جديدة

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

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

إنهاء المتطلبات الجديدة

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

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

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

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

بدء متطلبات جديدة

إذا كانت عمليات تنفيذ الأجهزة الجوّالة تضبط UserManager.isHeadlessSystemUserMode على true،

• [9.5/H-4-1] يجب ألا يتضمّن الجهاز إمكانية استخدام شرائح eUICC أو شرائح eSIM المزوّدة بإمكانية الاتصال.
• [9.5/H-4-2] يجب عدم الإفصاح عن توفّر ميزة android.hardware.telephony.

إنهاء المتطلبات الجديدة

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

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

• [9.8/H-1-1] يجب التأكّد من أنّ خدمة رصد الكلمات الرئيسية لا يمكنها نقل سوى البيانات إلى النظام أو ContentCaptureService أو أو خدمة التعرّف على الكلام على الجهاز التي أنشأها SpeechRecognizer#createOnDeviceSpeechRecognizer().
• [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 بايت من البيانات خارج خدمة رصد الكلمات الرئيسية في كل نتيجة ناجحة لكلمة رئيسيةباستثناء بيانات الصوت التي يتم تمريرها من خلال HotwordAudioStream.
• [9.8/H-1-7] يجب عدم السماح بنقل أكثر من 5 بت من البيانات خارج خدمة رصد الكلمات الرئيسية في كل نتيجة سلبية للكلمة الرئيسية.
• [9.8/H-1-8] يجب عدم السماح بنقل البيانات خارج خدمة الكشف عن الكلمات المميّزة إلا عند تلقّي طلب التحقّق من الكلمة المميّزة من خادم النظام.
• [9.8/H-1-9] يجب عدم السماح لتطبيق يمكن للمستخدم تثبيته بتقديم خدمة رصد الكلمات الرئيسية.
• [9.8/H-1-10] يجب عدم عرض بيانات كمية عن استخدام الميكروفون من قِبل خدمة رصد الكلمات الرئيسية في واجهة المستخدم.
• [9.8/H-1-11] يجب تسجيل عدد البايتات المضمّنة في كل عملية إرسال من خدمة رصد الكلمات الرئيسية للسماح بفحصها من قِبل باحثي الأمان.
• [9.8/H-1-12] يجب أن يتيح وضع تصحيح الأخطاء تسجيل المحتوى الأوّلي لكل عملية إرسال من خدمة رصد الكلمات الرئيسية للسماح لباحثي الأمان بالفحص.
• [9.8/H-1-14] يجب عرض مؤشر الميكروفون، كما هو موضّح في القسم 9.8.2، عند إرسال نتيجة كلمة تشغيل ناجحة إلى خدمة التفاعل الصوتي أو كيان مشابه.

بدء متطلبات جديدة

• [9.8/H-1-15] يجب التأكّد من أنّ عمليات نقل البث الصوتي المقدَّمة عند رصد كلمة مفتاح ناجحة تتم في اتجاه واحد من خدمة رصد الكلمة المفتاح إلى خدمة التفاعل بالصوت.

إنهاء المتطلبات الجديدة

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

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

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

بدء متطلبات جديدة

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

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

إنهاء المتطلبات الجديدة

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

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

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

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

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

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

• [6.1/H-0-1]* يجب أن يكون متوافقًا مع الأمر 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.T لـ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS، يعني ذلك أنّها:

• يجب أن تستوفي متطلبات الوسائط الواردة في الفقرة 2.2.7.1 من "سياسة تطوير البرامج (CDD) لنظام التشغيل Android 13".

بدء متطلبات جديدة

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

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

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

• [5.1/H-1-17] يجب أن يتضمّن الجهاز وحدة فك ترميز للصور تتوافق مع AVIF Baseline Profile.
• [5.1/H-1-18] يجب أن يكون متوافقًا مع برنامج ترميز AV1 الذي يمكنه ترميز ما يصل إلى دقة 480p بسرعة 30 لقطة في الثانية وسرعة 1 ميغا بت في الثانية.
• [5.12/H-1-1] يجب [5.12/H-SR] يُنصح بشدة بتفعيل ميزة Feature_HdrEditing لجميع برامج ترميز AV1 وHEVC للأجهزة المتوفّرة على الجهاز.
• [5.12/H-1-2] يجب أن يكون الجهاز متوافقًا مع تنسيق الألوان RGBA_1010102 لجميع برامج ترميز AV1 و HEVC المضمّنة في الجهاز.
• [5.12/H-1-3] يجب الإعلان عن توفّر إضافة EXT_YUV_target لجمع عيّنات من صور YUV بتنسيق 8 و10 بت.
• [7.1.4/H-1-1] يجب أن يتضمّن الجهاز 6 طبقات رسومات على الأقل في وحدة معالجة الشاشة (DPU)، على أن يكون اثنان منها على الأقل قادرَين على عرض محتوى فيديو بدقة 10 بت.

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

• [5.2/H-2-1] يجب أن تستوفي الحد الأدنى لهدف الجودة المحدَّد من خلال منحنيات معدل التشويش/الترميز لبرنامج ترميز الفيديو AVC وHEVC للأجهزة، كما هو محدَّد في اختبارات فئة الأداء 14 (PC14) لجودة ترميز الفيديو (VEQ).

إنهاء المتطلبات الجديدة

2.2.7.2. الكاميرا

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

• يجب أن تستوفي متطلبات الوسائط الواردة في القسم 2.2.7.2 من CDD لنظام التشغيل Android 13.

بدء متطلبات جديدة

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

• [7.5/H-1-1] يجب أن يتضمّن الجهاز كاميرا خلفية أساسية بدرجة دقة لا تقل عن 12 ميغابكسل وتتيح تسجيل الفيديو بدقة 4K بمعدل 30 لقطة في الثانية. الكاميرا الخلفية الأساسية هي الكاميرا الخلفية التي تحمل رقم تعريف الكاميرا الأقل.
• [7.5/H-1-2] يجب أن تتضمّن كاميرا أمامية أساسية بدقة ‎6 ميغابكسل على الأقل وأن تتيح تسجيل الفيديوهات بدقة 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 900 ملي ثانية بدقة 1080p، كما تم قياسه من خلال اختبار أداء الكاميرا في CTS في ظل ظروف الإضاءة (3000K) لكلتا الكاميرتين الأساسيتين.
• [7.5/H-1-6] يجب أن يكون وقت استجابة بدء تشغيل الكاميرا2 (فتح الكاميرا إلى أول ملف شخصي للمعاينة) أقل من 500 ملي ثانية، كما تم قياسه من خلال اختبار أداء الكاميرا في CTS في ظل ظروف الإضاءة ITS (3000K) لكلتا الكاميرتَين الأساسيتَين.
• [7.5/H-1-8] يجب أن تكون الكاميرا الخلفية الأساسية متوافقة مع CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW وandroid.graphics.ImageFormat.RAW_SENSOR.
• [7.5/H-1-9] يجب أن تتضمّن الكاميرا الأساسية الخلفية دقة 720p أو 1080p بسرعة 240 لقطة في الثانية.
• [7.5/H-1-10] يجب أن يكون الحد الأدنى لنسبة التكبير ZOOM_RATIO أقل من 1.0 للكاميرات الأساسية إذا كانت هناك كاميرا RGB عريضة جدًا مواجهة للاتجاه نفسه.
• [7.5/H-1-11] يجب تنفيذ بث متزامن للأمام والخلف في الكاميرات primary.
• [7.5/H-1-12] يجب أن يكون الجهاز متوافقًا مع CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION لكل من الكاميرتين الأمامية والخلفية الأساسيتَين.
• [7.5/H-1-13] يجب أن تتوفّر ميزة LOGICAL_MULTI_CAMERA للكاميرا الخلفية الأساسية إذا كانت هناك أكثر من كاميرا RGB واحدة خلفية.
• [7.5/H-1-14] يجب أن تتوفّر إمكانية STREAM_USE_CASE لكل من الكاميرتين الأساسية الأمامية والأساسية الخلفية.
• [7.5/H-1-15] يجب أن تتيح إضافات "الخلفية الضبابية" و "وضع الليل" من خلال كلّ من CameraX وCamera2 لإضافات الكاميرات الأساسية.
• [7.5/H-1-16] يجب أن تكون الكاميرات الأساسية مزوّدة بإمكانية DYNAMIC_RANGE_TEN_BIT.
• [7.5/H-1-17] يجب أن تكون الكاميرات الأساسية متوافقة مع CONTROL_SCENE_MODE_FACE_PRIORITY وميزة "اكتشاف الوجوه" (STATISTICS_FACE_DETECT_MODE_SIMPLE أو STATISTICS_FACE_DETECT_MODE_FULL) .

إنهاء المتطلبات الجديدة

2.2.7.3. الأجهزة

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

• يجب أن تستوفي متطلبات الوسائط الواردة في الفقرة 2.2.7.3 من "سياسة تطوير البرامج (CDD) لنظام التشغيل Android 13".

بدء متطلبات جديدة

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

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

إنهاء المتطلبات الجديدة

2.2.7.4. الأداء

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

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

بدء متطلبات جديدة

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

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

إنهاء المتطلبات الجديدة

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

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

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

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

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

2.3.1. الأجهزة

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

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

إنهاء المتطلبات الجديدة

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

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

بدء متطلبات جديدة

• [5.3.2/T-0-7] ‫AV1

إنهاء المتطلبات الجديدة

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

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

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

• [5.3.4/T-1-1] دقة عالية 1080p بمعدل 60 لقطة في الثانية باستخدام ملف الوصف الأساسي
• [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-SR1] يُنصح بشدة بتوفير ملف تعريف فك ترميز UHD بمعدّل 60 لقطة في الثانية باستخدام الملف 2 (عمق الألوان 10 بت).

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

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

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

• [5.8/T-0-1] يجب ضبط وضع مخرج HDMI على أعلى درجة دقة لتنسيق البكسل الذي تم اختياره والذي يعمل بمعدل تحديث 50 هرتز أو 60 هرتز للشاشة الخارجية، استنادًا إلى معدل تحديث الفيديو في المنطقة التي يتم بيع الجهاز فيها. يجب ضبط وضع إخراج 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/T-0-1] يجب الإفصاح عن ميزة android.hardware.security.model.compatible.
• [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 وحدة.

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

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

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

بدء متطلبات جديدة

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

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

إنهاء المتطلبات الجديدة

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

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

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

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

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

2.5.1. الأجهزة

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

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

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

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

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

• [7.3/A-SR-2] يُنصح بشدة بتنفيذ قياسات TYPE_HEADING والإبلاغ عنها.

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

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

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

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

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

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

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

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

• [7.3.4/A-4-1] يجب تنفيذ قياس TYPE_GYROSCOPE_LIMITED_AXES والإبلاغ عنه.
• [7.3.4/A-4-2] يجب تنفيذ قياس TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED والإبلاغ عنه.

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

• [7.3.3/أ-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، أو باستخدام كليهما.

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

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

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

• [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 للشبكة التي يجب أن تكون متاحة لتطبيقات النظام.

بدء متطلبات جديدة

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

• [7.4.10/A-0-1] يجب الإفصاح عن توافق التطبيق مع FEATURE_BROADCAST_RADIO.

إنهاء المتطلبات الجديدة

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

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

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

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

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

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

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

• يجب أن يكون مزوّدًا بأجهزة ذات تركيز ثابت أو بميزة "عمق مجال الصورة الموسّع".

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

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

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

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

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

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

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

بدء متطلبات جديدة

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

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

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

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

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

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

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

• [7.5/أ-2-1] يجب أن تكون الكاميرا الأساسية التي تواجه المستخدم هي كاميرا rivolta التي لها رقم تعريف الكاميرا الأقل.
• يمكن توجيهها بحيث يكون الجانب الطويل من الكاميرا متوافقًا مع مستوى X-Y لمحورَي استشعار Android Automotive.

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

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

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

• [7.5/أ-4-1] يجب أن يكون بالإمكان الوصول إلى التطبيق من خلال خدمة نظام العرض الموسّع.

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

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

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

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

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

• [7.5/A-7-1] يجب تنفيذ واجهة برمجة تطبيقات الكاميرا هذه باستخدام واجهة برمجة التطبيقات android.hardware.camera2 أو واجهة برمجة التطبيقات لنظام العرض الموسّع.

إنهاء المتطلبات الجديدة

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

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

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

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

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

إذا كانت عمليات تنفيذ الأجهزة في السيارات تعمل بنظام 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 Profile (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/A-0-1] يجب عدم السماح للمستخدمين الثانويين الكاملين الذين ليسوا المستخدم الحالي في المقدّمة بتشغيل الأنشطة والوصول إلى واجهة المستخدم على أي شاشات.

إنهاء المتطلبات الجديدة

• [3.8.3/A-0-1] يجب عرض إعلامات تستخدم واجهة برمجة التطبيقات Notification.CarExtender عند طلبها من تطبيقات تابعة لجهات خارجية.

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

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

• [3.8.4/أ-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/A-0-4] يجب توفير عنصر تحكم للانتقال إلى نشاط الإعدادات المفضّلة في تطبيق الوسائط، ولكن يجب عدم تفعيله إلا عندما لا تكون قيود تجربة المستخدم في السيارة سارية.
• [3.14/A-0-5] يجب أن يعرض التطبيق رسائل الخطأ التي تحدّدها تطبيقات الوسائط، ويجب أن يكون متوافقًا مع الإضافات الاختيارية ERROR_RESOLUTION_ACTION_LABEL وERROR_RESOLUTION_ACTION_INTENT.
• [3.14/A-0-6] يجب أن يتيح التطبيق ميزة البحث داخل التطبيق للتطبيقات التي تتيح البحث.
• [3.14/A-0-7] يجب الالتزام بتعريفات CONTENT_STYLE_BROWSABLE_HINT وCONTENT_STYLE_PLAYABLE_HINT عند عرض التسلسل الهرمي MediaBrowser.

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

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

بدء متطلبات جديدة

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

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

إنهاء المتطلبات الجديدة

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

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

بدء متطلبات جديدة

• [9.8.2/أ-2-3] يجب توفير عنصر تحكم للمستخدم لتفعيل الكاميرا وإيقافها في تطبيق "الإعدادات".
• [9.8.2/أ-2-4] يجب عرض التطبيقات المستخدَمة مؤخرًا والنشطة باستخدام الكاميرا كما هو معروض فيPermissionManager.getIndicatorAppOpUsageData()، بالإضافة إلى أي رسائل تحديد مصدر مرتبطة بها.

إنهاء المتطلبات الجديدة

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

• [9/أ-0-1] يجب الإفصاح عن ميزة android.hardware.security.model.compatible.
• [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 وحدة.

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

بدء متطلبات جديدة

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

إنهاء المتطلبات الجديدة

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 14.
VERSION.SDK	إصدار نظام Android الذي يتم تنفيذه حاليًا بتنسيق يمكن لرمز التطبيق التابع لجهة خارجية الوصول إليه بالنسبة إلى Android 14، يجب أن يحتوي هذا الحقل على القيمة الصحيحة 14_INT.
VERSION.SDK_INT	إصدار نظام Android الذي يتم تنفيذه حاليًا بتنسيق يمكن لرمز التطبيق التابع لجهة خارجية الوصول إليه بالنسبة إلى Android 14، يجب أن يحتوي هذا الحقل على القيمة الصحيحة 14_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:14/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] يجب أن توفّر عمليات تنفيذ الأجهزة واجهة مستخدم تتيح للمستخدمين تعديل النشاط التلقائي للنوايا.

• ومع ذلك، قد تقدّم عمليات تنفيذ الأجهزة أنشطة تلقائية لنماذج عناوين URI معيّنة (مثل 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.calling، يعني ذلك ما يلي:

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

بدء متطلبات جديدة

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

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

إنهاء المتطلبات الجديدة

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

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

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

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

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

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

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

• [C-SR-1] يُنصح بشدة باستخدام عمليات تنفيذ المكتبات المُدرَجة أدناه من مشروع Android 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 Vulkan 1.1 ، بالإضافة إلى رموز الدوالّ الموسّعة VK_KHR_surface وVK_KHR_android_surface VK_KHR_swapchain وVK_KHR_maintenance1 VK_KHR_get_physical_device_properties2 من خلال مكتبة libvulkan.so. يُرجى العِلم أنّه على الرغم من أنّه يجب أن تكون جميع الرموز متوفّرة، فإنه في الفقرة 7.1.4.2 описано بمزيد من التفصيل متطلبات تنفيذ كل دالة مقابلة بشكل كامل.

• يجب إنشاؤها باستخدام رمز المصدر وملفات الرأس المتاحة في الإصدار الأحدث من مشروع Android Open Source Project.

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

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

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

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

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

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

  • 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" في الإصدار 14 من 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. قيود التطبيق

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

• [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] يجب تقديم مستند أو موقع إلكتروني علني وواضح يصف كيفية تطبيق القيود المتعلقة بالملكية. يجب أن يكون هذا المستند أو الموقع الإلكتروني قابلاً للربط من مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android، ويجب أن يتضمّن ما يلي:

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

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

إذا كانت عمليات تنفيذ الأجهزة تُوسّع نطاق قيود التطبيقات التي يتم تنفيذها في 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().

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

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

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

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

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

• [C-1-1] يجب الإفصاح عن توافق التطبيق مع ميزة المنصة android.software.app_widgets.

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

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

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

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

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

3.8.3. الإشعارات

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

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

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

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

3.8.6. المظاهر

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

يتضمّن Android مجموعتَي مظاهر "Holo" و"المادة" كمجموعة من الأنماط المحدّدة التي يمكن لمطوّري التطبيقات استخدامها إذا أرادوا مطابقة مظهر مظهر المظهر 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.

• [C-1-4] يجب إنشاء لوحات ألوان ديناميكية كما هو محدّد في مستندات AOSP الخاصة بـ Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (راجِع android.theme.customization.system_palette و android.theme.customization.theme_style).

• [C-1-5] يجب إنشاء لوحات ألوان ديناميكية باستخدام أنماط مظاهر الألوان المُدرَجة في مستندات Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (راجِع android.theme.customization.theme_styles)، مثل TONAL_SPOT وVIBRANT وEXPRESSIVE وSPRITZ وRAINBOW وFRUIT_SALAD ووMONOCHROMATIC.

  "لون المصدر" المستخدَم لإنشاء لوحات ألوان ديناميكية عند إرسالها مع android.theme.customization.system_palette (كما هو موضّح في Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES).

• [C-1-6] يجب أن تكون قيمة معلومات CAM16 اللونية 5 أو أكبر.

  • يجب أن يتم استخراجه من الخلفية من خلال com.android.systemui.monet.ColorScheme#getSeedColors، الذي يقدّم عدة ألوان مصدر صالحة للاختيار من بينها.

  • يجب استخدام القيمة 0xFF1B6EF3 إذا لم تستوفِ أي من الألوان المقدَّمة متطلبات لون المصدر أعلاه.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [C-1-1] يجب أن تتيح عرض ما يصل إلى 7 أنشطة على الأقل.
• يجب أن يعرض عنوان 4 أنشطة على الأقل في المرة الواحدة.

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

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

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

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

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

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

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

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

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

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

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 وحدة كثافة بكسل وعرض الشاشة أقل من 440 وحدة كثافة بكسل.
• [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.8.17. الحافظة

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

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

إذا كانت عمليات تنفيذ الأجهزة تنشئ معاينة مرئية للمستخدم عند نسخ المحتوى إلى الحافظة لأي عنصر ClipData حيث يحتوي ClipData.getDescription().getExtras() على android.content.extra.IS_SENSITIVE، فإنّها:

• [C-1-1] يجب إخفاء المعاينة الظاهرة للمستخدم

يستوفي التنفيذ المرجعي لنظام التشغيل AOSP متطلبات الحافظة هذه.

3.9. إدارة الجهاز

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

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

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

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

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

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 وتنفيذ وحدة التحكّم في نقطة النهاية (DPC) للمعالِج.

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

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

بدء متطلبات جديدة

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

إنهاء المتطلبات الجديدة

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

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

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

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

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

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

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

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

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

• [C-1-1] يجب أن يتيح دور إدارة سياسة الجهاز على النحو المحدّد في الفقرة 9.1. التطبيق الذي يشغل دور إدارة سياسة الجهاز يمكن تحديده من خلال ضبط config_devicePolicyManagement على اسم الحزمة. يجب أن يتبع اسم الحزمة : وشهادة التوقيع ما لم يكن التطبيق محمَّلاً مسبقًا.

في حال عدم تحديد اسم حزمة لـ config_devicePolicyManagement كما هو описан أعلاه:

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

إذا تم تحديد اسم حزمة لـ config_devicePolicyManagement كما هو موضّح أعلاه:

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

في حال تحديد اسم حزمة لـ config_devicePolicyManagementUpdater كما هو описан أعلاه:

• [C-4-1] يجب أن يكون التطبيق مثبَّتًا مسبقًا على الجهاز.
• [C-4-2] يجب أن ينفِّذ التطبيق فلتر طلبات بحث يحلّ android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER.

بدء متطلبات جديدة

3.9.5 إطار عمل حلّ المشاكل في سياسة الجهاز

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

• [C-1-1] يجب حلّ تعارضات سياسة الجهاز كما هو موضّح في إطار عمل حلّ سياسة الجهاز.

إنهاء المتطلبات الجديدة

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

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

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

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

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

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

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

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

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

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

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

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

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] يجب أن يكون الجهاز قادرًا على تثبيت ملفات "‎.apk" لنظام التشغيل Android وتشغيلها على النحو الذي يتم إنشاؤه بواسطة أداة "aapt" المضمّنة في حزمة تطوير البرامج (SDK) الرسمية لنظام التشغيل Android.

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

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

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

• [C-0-4] يجب عدم السماح للتطبيقات غير "مُثبِّت الحِزمة" الحالي بالانتقام من التطبيق بدون تأكيد من العميل، كما هو موضّح في حزمة تطوير البرامج للإذن 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 و الإصدار 4.1 من مخطّط توقيع حِزم APK.

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

5. توافق الوسائط المتعددة

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

• [C-0-1] يجب أن يكون متوافقًا مع تنسيقات الوسائط وبرامج الترميز وفك الترميز وأنواع الملفات وتنسيقات الحاويات المحدّدة في الفقرة 5.1 لكل مُشفِّر أعلن عنه MediaCodecList.
• [C-0-2] يجب الإفصاح عن توفّر برامج الترميز وفك الترميز المتاحة للتطبيقات التابعة لجهات خارجية والإبلاغ عنها من خلال MediaCodecList.
• [C-0-3] يجب أن يكون بإمكانه فك ترميز جميع التنسيقات التي يمكنه ترميزها بشكل صحيح وإتاحتها للتطبيقات التابعة لجهات خارجية. ويشمل ذلك جميع مجموعات البيانات التي تنشئها برامج الترميز والملفات الشخصية التي يتم الإبلاغ عنها في CamcorderProfile.

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

• يجب أن تهدف إلى الحد الأدنى من وقت استجابة ترميز الفيديو، بعبارة أخرى، يجب أن تراعي
  • يجب عدم استخدام وحفظ وحدات تخزين المؤقتة للإدخال وإرجاع وحدات تخزين المؤقتة للإدخال فقط بعد معالجتها.
  • يجب عدم الاحتفاظ بوحدات التخزين المؤقتة التي تم فك ترميزها لفترة أطول من المدة المحدّدة في المعيار (مثل SPS).
  • يجب عدم الاحتفاظ بمخازن مؤقتة مُشفَّرة لفترة أطول من الوقت المطلوب وفقًا لبنية GOP.

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

يُرجى العِلم أنّ Google أو تحالف Open Handset Alliance لا يقدّمان أي تأكيد بأنّ برامج الترميز هذه خالية من براءات اختراع تابعة لجهات خارجية. ننصحك بأنّه إذا أردت استخدام رمز المصدر هذا في منتجات الأجهزة أو البرامج، قد تتطلّب عمليات تنفيذ هذا الرمز، بما في ذلك في البرامج المفتوحة المصدر أو البرامج المشترَكة، تراخيص براءات اختراع من مالكي براءات الاختراع المعنيّين.

5.1. برامج ترميز الوسائط

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

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

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

• ‫[C-1-1] PCM/WAVE
• [C-1-2] FLAC
• [C-1-3] Opus

يجب أن تكون جميع برامج ترميز الصوت متوافقة مع ما يلي:

• ‫[C-3-1] إطارات صوتية بتنسيق PCM بسعة 16 بت بترتيب البايت الأصلي من خلال واجهة برمجة التطبيقات android.media.MediaCodec

5.1.2. فك ترميز الصوت

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

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

• [C-1-1] الملف الشخصي MPEG-4 AAC (AAC LC)
• [C-1-2] ملف تعريف MPEG-4 HE AAC (AAC+)
• [C-1-3] الملف الشخصي MPEG-4 HE AACv2 (الترميز المحسّن للصوت بترميز متقدّم)
• ‫[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.
• [C-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

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

• [C-7-1] يجب أن يكون بإمكان التطبيق ضبط عملية فك التشفير باستخدام المفتاح KEY_MAX_OUTPUT_CHANNEL_COUNT للتحكّم في ما إذا كان سيتم تقليل جودة المحتوى إلى صوت استيريو (عند استخدام القيمة 2) أو يتم إخراجه باستخدام العدد الأصلي للقنوات (عند استخدام قيمة مساوية أو أكبر من هذا العدد). على سبيل المثال، ستؤدي القيمة 6 أو أكثر إلى ضبط أداة فك التشفير لإخراج 6 قنوات عند تزويدها بمحتوى بدقة 5.1.
• [C-7-2] عند فك التشفير، يجب أن يعلن برنامج فك التشفير عن قناع القناة المستخدَم في تنسيق الإخراج باستخدام مفتاح KEY_CHANNEL_MASK ، وذلك باستخدام الثوابت android.media.AudioFormat (على سبيل المثال: CHANNEL_OUT_5POINT1).

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

• [C-SR-2] يُنصح بشدة بأن يكون من الممكن للتطبيق ضبط وحدة الترميز باستخدام KEY_MAX_OUTPUT_CHANNEL_COUNT للتحكّم في ما إذا كان سيتم تقليل جودة المحتوى إلى صوت استيريو (عند استخدام القيمة 2) أو يتم إخراجه باستخدام العدد الأصلي للقنوات (عند استخدام قيمة مساوية أو أكبر من هذا العدد). على سبيل المثال، ستؤدي القيمة 6 أو أكثر إلى ضبط أداة فك التشفير لإخراج 6 قنوات عند تزويدها بمحتوى بدقة 5.1.
• [C-SR-3] عند فك التشفير، يُنصح بشدة باستخدام وحدة فك التشفير للإعلان عن قناع القناة المستخدَم في تنسيق الإخراج باستخدام KEY_CHANNEL_MASK المفتاح، وذلك باستخدام الثوابت android.media.AudioFormat (مثال: CHANNEL_OUT_5POINT1).

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

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

بدء متطلبات جديدة

• [C-0-4] AVIF
  • يجب أن تتوافق الأجهزة مع BITRATE_MODE_CQ و"ملف العمل الأساسي".

إنهاء المتطلبات الجديدة

إذا كانت عمليات تنفيذ الأجهزة تتيح ترميز HEIC من خلال android.media.MediaCodec لنوع الوسائط MIMETYPE_IMAGE_ANDROID_HEIC، يجب أن تستوفي الشروط التالية:

• [C-1-1] يجب أن يوفّر برنامج ترميز HEVC مُسرَّع بالأجهزة ويتوافق مع BITRATE_MODE_CQ وضع التحكّم في معدل نقل البيانات، HEVCProfileMainStill الملف الشخصي وحجم اللقطة 512 × 512 بكسل.

5.1.5. فك ترميز الصور

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

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

• ‫[C-0-1] JPEG
• [C-0-2] GIF
• ‫[C-0-3] ملف بتنسيق PNG
• [C-0-4] BMP
• ‫[C-0-5] WebP
• [C-0-6] ملف خام
• [C-0-7] AVIF (Baseline Profile)

إذا كانت عمليات تنفيذ الأجهزة تتيح فك ترميز الفيديو بتنسيق 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)
AVIF (الملف الشخصي الأساسي)	ملف مرجعي للصور ومجموعات الصور وتسلسل الصور	حاوية HEIF (‎.avif)

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

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

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

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

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

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

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

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

• [C-1-2] يجب أن تتيح برامج ترميز الفيديو وفك ترميزه استخدام تنسيقات ملفّات YUV420 8:8:8 المرنة للألوان (COLOR_FormatYUV420Flexible) حتى CodecCapabilities.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [C-1-1] يجب أن يقدّم التطبيق دعمًا لبرامج ترميز الوسائط إما من خلال واجهات برمجة التطبيقات OMX أو Codec 2.0 (أو كليهما) كما هو الحال في مشروع Android 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 بكسل (غير ذلك، AV1)	‫‎1408 × 1152 بكسل (H263) ‫‎1280 × 720 بكسل (غير ذلك، AV1)	‫‎1920 × 1080 بكسل (باستثناء MPEG4 وAV1)	‫‎3840 × 2160 بكسل (HEVC وVP9 وAV1)

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

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

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

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

بدء متطلبات جديدة

إذا كانت عمليات تنفيذ الأجهزة متوافقة مع أيّ برنامج ترميز فيديو وتوفّره لتطبيقات خارجية، وتم ضبط
MediaFormat.KEY_BITRATE_MODE على BITRATE_MODE_VBR لكي يعمل برنامج الترميز في وضع معدل نقل البيانات المتغيّر، فإنّه، ما دام ذلك لا يؤثّر في الحدّ الأدنى للجودة، يكون معدل نقل البيانات المشفَّر :

• [C-5-1] يجب ألا يزيد معدل نقل البيانات في كل ملف على ملف سابق بنسبة تزيد عن% 15 خلال فواصل ملف الترميز الداخلي (I-frame).
• [C-5-2] يجب ألا تتجاوز نسبته 100% من معدل نقل البيانات خلال فترة زمنية متحركة تبلغ ثانية واحدة.

إذا كانت عمليات تنفيذ الأجهزة متوافقة مع أي برنامج ترميز فيديو وتوفّره ل التطبيقات التابعة لجهات خارجية وضبط MediaFormat.KEY_BITRATE_MODE على BITRATE_MODE_CBR لكي يعمل برنامج الترميز في وضع معدل نقل بيانات ثابت، يكون معدل نقل البيانات المُشفَّر على النحو التالي:

• [C-6-1] يجب [C-SR-2] يُنصح بشدة ألا يزيد عن ‎15% من معدل نقل البيانات المستهدَف على مدار فترة زمنية متحركة تبلغ ثانية واحدة.

إنهاء المتطلبات الجديدة

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة مضمّنة بطول قياسي أفقي لا يقل عن 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] يجب أن يكون الجهاز متوافقًا مع درجة دقة QCIF (176 x ‏144) باستخدام المستوى 45 من الملف الشخصي الأساسي. درجة دقة SQCIF اختيارية.
• يجب أن تتيح ضبط معدلات نقل البيانات ديناميكيًا لبرنامج الترميز المتوافق.

5.2.2. H.264

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

• [C-1-1] يجب أن يكون متوافقًا مع المستوى 3 من "ملف المرجع". ومع ذلك، فإنّ إتاحة ASO (ترتيب الشرائح التعسّفي) وFMO (ترتيب وحدات الماكروبلوك المرن) وRS (شرائح زائدة) هو اختياري. بالإضافة إلى ذلك، للحفاظ على التوافق مع أجهزة Android الأخرى، ننصح بعدم استخدام أدوات الترميز لميزة ASO وFMO وRS في الملف الشخصي الأساسي.
• [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 من الملف الشخصي الرئيسي حتى درجة دقة 512 x ‏512.
• يجب أن تكون متوافقة مع ملفات ترميز الفيديوهات العالية الدقة كما هو موضّح في الجدول التالي.
• [C-SR-1] يُنصح بشدة بتوفّر ملف التعريف بدقة عادية 720 x ‏480 و ملفّات ترميز بدقة عالية كما هو موضّح في الجدول التالي في حال توفّر برنامج ترميز للأجهزة.

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

بدء متطلبات جديدة

5.2.6. AV1

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

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

• [C-1-2] يجب نشر بيانات الأداء، أي الإبلاغ عن بيانات الأداء من خلال واجهتَي برمجة التطبيقات getSupportedFrameRatesFor() أو getSupportedPerformancePoints() لدرجات الدقة المتوافقة الواردة في الجدول أدناه.

• [C-1-3] يجب قبول البيانات الوصفية ذات تنسيق HDR وإخراجها إلى بث البتات

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

• [C-2-1] يجب أن يكون متوافقًا مع الملف الشخصي لتشفير HD1080p وما يصل إليه من ملف شخصي من جدول المعلومات أدناه:

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

إنهاء المتطلبات الجديدة

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 من الملف الشخصي الأساسي (دقة CIF وQCIF وSQCIF بمعدّل 30 لقطة في الثانية 384 كيلوبت في الثانية) والمستوى 45 (دقة QCIF وSQCIF بمعدّل 30 لقطة في الثانية 128 كيلوبت في الثانية).

5.3.3. MPEG-4

في حال استخدام أجهزة مع برامج ترميز MPEG-4، يجب:

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

5.3.4. H.264

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

• [C-1-1] يجب أن يكون الجهاز متوافقًا مع المستوى 3.1 من الملف الشخصي الرئيسي والملف الشخصي الأساسي. إنّ إتاحة ميزة ASO (ترتيب الشرائح التعسّفي) وFMO (ترتيب الوحدات المجمّعة المرنة) وRS (شرائح زائدة) هو اختياري.
• [C-1-2] يجب أن يكون الجهاز قادرًا على فك ترميز الفيديوهات باستخدام ملفات تعريف الدقة المتوسّطة (SD) المُدرَجة في الجدول التالي والمُشفَّرة باستخدام ملف التعريف الأساسي وملف التعريف الرئيسي المستوى 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 بت.

بدء متطلبات جديدة

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

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

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

• [C-2-1] يجب أن يكون الجهاز قادرًا على فك ترميز ملفات الفيديو بدقة عالية 720p على الأقل من جدول الإعدادات أدناه عندما يكون الارتفاع الذي تم قياسه باستخدام طريقة Display.getSupportedModes() يساوي 720p أو يزيد عنه.
• [C-2-2] يجب أن يكون الجهاز قادرًا على فك ترميز ملفات الفيديو بدقة عالية 1080p على الأقل من الجدول أدناه عندما يكون الارتفاع الذي تُبلغ عنه طريقة Display.getSupportedModes() يساوي 1080p أو أكبر.

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

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

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

إنهاء المتطلبات الجديدة

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

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

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

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

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

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

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

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

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

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

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

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

• [C-1-4] يجب الالتزام لواجهة برمجة التطبيقات MicrophoneInfo وملء معلومات الميكروفونات المتاحة على الجهاز التي يمكن للتطبيقات التابعة لجهات خارجية الوصول إليها من خلال واجهة برمجة التطبيقات AudioManager.getMicrophones() لتسجيل الصوت باستخدام MediaRecorder.AudioSources DEFAULT أو MIC أو CAMCORDER أو VOICE_RECOGNITION VOICE_COMMUNICATION أو UNPROCESSED أو VOICE_PERFORMANCE. إذا كانت عمليات تنفيذ الأجهزة تسمح بتسجيل محتوى صوتي بدائي بجودة راديو AM وأقراص DVD، يجب أن تستوفي المتطلبات التالية:

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

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

5.4.2. تسجيل الصوت للتعرّف عليه

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

• [C-1-1] يجب تسجيل android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION مصدر الصوت عند أحد معدّلات أخذ العينات، 44100 و48000.
• [C-1-2] يجب إيقاف أي معالجة صوتية للحد من الضوضاء تلقائيًا عند تسجيل بث صوتي من مصدر AudioSource.VOICE_RECOGNITION الصوت.

• [C-1-3] يجب إيقاف أيّ ميزة تلقائية للتحكّم في مستوى الصوت تلقائيًا عند تسجيل بثّ صوتي من مصدر الصوت AudioSource.VOICE_RECOGNITION.

• يجب أن يُظهر خصائص تقريبية مسطّحة للسعة مقابل التردد في نطاق التردد المتوسط: على وجه التحديد ±3 ديسيبل من 100 هرتز إلى 4000 هرتز لكل وكل ميكروفون مستخدَم لتسجيل مصدر الصوت الخاص بميزة التعرّف على الصوت.

• [C-SR-1] يُنصح بشدة بعرض مستويات السعة في نطاق التردد المنخفض: على وجه التحديد من ±20 ديسيبل من 30 هرتز إلى 100 هرتز مقارنةً بنطاق التردد المتوسط لكل ميكروفون مستخدَم لتسجيل مصدر ملف صوتي لخدمة التعرّف على الكلام.

• [C-SR-2] يُنصح بشدة بعرض مستويات السعة في نطاق التردد العالي: على وجه التحديد من ±30 ديسيبل من 4000 هرتز إلى 22 كيلوهرتز مقارنةً بنطاق التردد المتوسط لكل ميكروفون مستخدَم لتسجيل مصدر ملف صوتي لخدمة التعرّف على الكلام.

• يجب ضبط حساسية إدخال الصوت بحيث ينتج مصدر النغمات الجيبية بمقدار 1000 هرتز عند مستوى ضغط صوتي يبلغ 90 ديسيبل (SPL) (يتم قياسه على مسافة 30 سم من بجانب الميكروفون) استجابة مثالية بمقدار 2500 ذروة متوسطة مربّعة (RMS) ضمن نطاق يتراوح بين 1770 و3530 لعيّنات 16 بت (أو -22.35 ديسيبل ±3 ديسيبل على النطاق الكامل لعيّنات النقطة العائمة/الدقة المزدوجة) لكل ميكروفون مستخدَم لتسجيل مصدر ملف صوتي التعرّف على الكلام.

• يجب تسجيل بث الصوت لميزة التعرّف على الصوت بحيث تتتبّع مستويات كثافة 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.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.

بدء متطلبات جديدة

• [C-1-4] يجب أن تتيح التأثيرات الصوتية باستخدام إدخال وإخراج باستخدام النقطة العائمة.
• [C-1-5] يجب التأكّد من أنّ التأثيرات الصوتية تتيح استخدام قنوات متعددة حتى عدد قنوات الخلاط المعروف أيضًا باسم FCC_LIMIT.

إنهاء المتطلبات الجديدة

• يجب أن تتوافق مع عمليات تنفيذ EFFECT_TYPE_BASS_BOOST وEFFECT_TYPE_ENV_REVERB EFFECT_TYPE_PRESET_REVERB وEFFECT_TYPE_VIRTUALIZER التي يمكن التحكّم فيها من خلال الفئات الفرعية AudioEffect BassBoost EnvironmentalReverb وPresetReverb وVirtualizer.
• [C-SR-1] يُنصح بشدة بتوفّر تأثيرات بتنسيق النقطة العائمة و قنوات المتعددة.

5.5.3. مستوى صوت إخراج الصوت

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

• يجب أن تسمح بضبط مستوى الصوت بشكل منفصل لكل بث صوتي باستخدام نوع المحتوى أو الاستخدام على النحو المحدّد بواسطة AudioAttributes واستخدام الصوت في السيارة على النحو المحدّد علنًا في android.car.CarAudioManager.

5.5.4. إزالة المحتوى الصوتي

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

• [C-SR-1] يُنصح بشدة بقطع المحتوى الصوتي الذي يتم تشغيله بدون انقطاع بين مقطعَين بالتنسيق نفسه عند تحديد ذلك من خلال واجهة برمجة التطبيقات AudioTrack gapless 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 مللي ثانية أو أقل

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

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

• [C-SR-1] يجب أن يكون وقت استجابة الإخراج بدون محتوى 100 ملي ثانية أو أقل على مسار بيانات مكبّر الصوت.
• [C-SR-2] يجب أن يكون وقت استجابة ميزة "النقر للتشغيل" 80 ملي ثانية أو أقل.

• [C-SR-4] يجب أن يكون الطابع الزمني الناتج الذي يعرضه كل من AudioTrack.getTimestamp وAAudioStream_getTimestamp دقيقًا بمعدل ± 1 ملي ثانية.

بدء متطلبات جديدة

• [C-SR-4] يُنصح بشدة بأن تكون أوقات الاستجابة المحسوبة للذهاب والعودة استنادًا إلى علامات توقيت الإدخال والإخراج التي يعرضها AAudioStream_getTimestamp ضمن 30 ملي ثانية من وقت الاستجابة المقاس للذهاب والعودة لAAUDIO_PERFORMANCE_MODE_NONE وAAUDIO_PERFORMANCE_MODE_LOW_LATENCY للمكبّرات الصوت وسماعات الرأس السلكية واللاسلكية.

إنهاء المتطلبات الجديدة

إذا كانت عمليات تنفيذ الأجهزة تستوفي المتطلبات المذكورة أعلاه، بعد أي عملية قياس أولي، عند استخدام واجهة برمجة التطبيقات 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 مللي ثانية أو أقل
• [C-3-3] يجب ألا يستغرق فتح مصدر إدخال باستخدام AAudioStreamBuilder_openStream() أقل من 1000 ملي ثانية.

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

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

• [C-SR-11] يجب الحد من الخطأ في الطوابع الزمنية للدخل، كما تظهر في AudioRecord.getTimestamp أو AAudioStream_getTimestamp، إلى ± 1 ملي ثانية.

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

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

5.7. بروتوكولات الشبكة

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

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

• [C-1-1] يجب أن يكون متوافقًا مع برنامج الترميز أو الحاوية هذاَين عبر بروتوكولَي HTTP وHTTPS.

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

• [C-1-3] يجب أن يكون متوافقًا مع تنسيقات حمولة RTSP المقابلة كما هو موضّح في جدول RTSP أدناه. للاطّلاع على الاستثناءات، يُرجى الاطّلاع على حواشي الجدول في القسم 5.1.

تنسيقات مقاطع الوسائط

تنسيقات الشرائح	المراجع	توفُّر برامج الترميز المطلوبة
MPEG-2 Transport Stream	ISO 13818	برامج ترميز الفيديو: ‫H264 AVC MPEG-4 SP MPEG-2 راجِع الفقرة 5.1.8 لمعرفة تفاصيل عن H264 AVC وMPEG2-4 SP وMPEG-2. برامج ترميز الصوت: الترميز المتقدّم للصوت راجِع القسم 5.1.3 لمعرفة تفاصيل عن الترميز المتقدّم للصوت وأنواعه.
الترميز المتقدّم للصوت مع إطارات ADTS وعلامات 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 وقت استجابة إرسال البيانات واستقبالها للصوت، بمقدار 25 ملي ثانية أو أقل على مسار واحد متوافق على الأقل.
• [C-1-3] يجب أن يتضمّن الجهاز منافذ USB متوافقة مع وضع مضيف USB ووضع جهاز USB محيطي.
• [C-1-4] يجب الإبلاغ عن توفّر الميزة android.software.midi.
• [C-1-5] يجب استيفاء متطلبات وقت الاستجابة والصوت عبر USB باستخدام واجهة برمجة التطبيقات AAudio native audio وAAUDIO_PERFORMANCE_MODE_LOW_LATENCY.
• [C-1-6] يجب أن يكون وقت استجابة الإخراج غير القابل للتقديم أو الإيقاف 200 ملي ثانية أو أقل.
• [C-1-7] يجب أن يكون وقت استجابة الإدخال في وضع "التشغيل لأول مرة" 200 ملي ثانية أو أقل.

• [C-1-8] يجب أن يكون متوسط وقت الاستجابة من النقر إلى ظهور الصوت 80 ملي ثانية أو أقل على مدار 5 قياسات على الأقل على مسار بيانات مكبّر الصوت إلى الميكروفون.

• [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 للحصول على شرح لمقاييس الأداء. يجب تشغيل تطبيق SynthMark باستخدام خيار "الاختبار المبرمَج" وتحقيق النتائج التالية:

  • ‫voicemark.90 >= 32 صوتًا
  • ‫latencymark.fixed.little <= 15 msec
  • ‫latencymark.dynamic.little <= 50 msec

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

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

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

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

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

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

• يجب ألا يتضمّن أي مشاكل في الصوت أثناء الاستخدام العادي وفقًا لوقت الاستجابة المسجَّل.

• يجب ألا يختلف وقت الاستجابة بين القنوات.

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

• يجب تقليل التباين في وقت استجابة MIDI أثناء التحميل (التشويش) على جميع عمليات النقل.

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

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

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

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

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

• يجب أن تقلِّل من وقت استجابة اللمس.

• يجب تقليل التباين في وقت استجابة اللمس أثناء التحميل (التشويش).

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

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

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

• [C-2-1] يجب أن يكون متوسّط وقت استجابة إرسال البيانات واستقبالها في الصوت مستمرًا، كما هو محدّد في الفقرة 5.6 وقت استجابة إرسال البيانات واستقبالها في الصوت،‏ 20 ملي ثانية أو أقل، على مدار 5 قياسات مع متوسّط انحراف مطلق أقل من 5 ملي ثانية على مدار مسار مقبس الصوت باستخدام دونجل loopback للصوت.

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

5.12. فيديو بنطاق عالي الديناميكية

يتوافق نظام التشغيل Android 13 مع تقنيات HDR كما هو موضّح في مستند قادم.

تنسيق البكسل

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

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

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

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

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

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

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

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

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

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

متطلبات تسجيل الفيديوهات بنطاق عالي الديناميكية (HDR)

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

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

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

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

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

• [C-6-2] يجب أن يتضمّن الجهاز برنامج ترميز فيديو واحدًا على الأقل مُسرَّعًا بالأجهزة لكل تكنولوجيا HDR متوافقة.

• [C-6-3] يجب أن يكون الجهاز متوافقًا مع وضع التصوير بتنسيق HLG (على الأقل).

• [C-6-4] يجب أن تتيح كتابة البيانات الوصفية ذات تنسيق HDR (إذا كان ذلك منطبقًا على تكنولوجيا HDR) في ملف الفيديو الذي تم تسجيله. بالنسبة إلى AV1 وHEVC وDolbyVision، يعني ذلك تضمين البيانات الوصفية في بث البتات المشفَّرة.

• [C-6-5] يجب أن يكون متوافقًا مع التنسيقَين P010 وCOLOR_FormatYUVP010.

• [C-6-6] يجب أن يكون متوافقًا مع تحويل النغمة من HDR إلى SDR في وحدة فك الترميز الافتراضية التي تعمل بالاستناد إلى الأجهزة للملف الشخصي الذي تم التقاطه. بعبارة أخرى، إذا كان الجهاز قادرًا على تسجيل محتوى بتنسيق HDR10+ HEVC، يجب أن يكون برنامج ترميز HEVC التلقائي قادرًا على فك ترميز البث المسجّل بتنسيق SDR.

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

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

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

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

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

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

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

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

إذا كان تنفيذ الجهاز يتضمّن برامج ترميز متوافقة مع FEATURE_HdrEditing، عندئذٍ: يُطبّق الجهاز ما يلي:

• [C-7-4] يجب الإعلان عن توافق الجهاز مع إضافة OpenGL EXT_YUV_target.

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

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

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

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

• Android Debug Bridge ‏ (adb)

  • [C-0-2] يجب أن تكون متوافقة مع adb كما هو موضّح في حزمة تطوير البرامج (SDK) لنظام التشغيل Android وshell الأوامر المقدّمة في AOSP، والتي يمكن لمطوّري التطبيقات استخدامها، بما في ذلك dumpsys cmd stats
  • [C-0-11] يجب أن يكون متوافقًا مع الأمر cmd testharness في 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، كما هو موضّح أعلاه.

• 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-12] يجب كتابة LMK_KILL_OCCURRED_FIELD_NUMBER Atom في ملف تسجيل statsd عند إنهاء أحد التطبيقات بواسطة Low Memory Killer.

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

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

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

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

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

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

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

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

يتيح نظام التشغيل Android للمطوّرين ضبط الإعدادات المتعلقة بتطوير التطبيقات.

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

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

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

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

• [C-0-1] يجب أن ينفِّذ تطبيق الجهاز واجهة برمجة التطبيقات (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، وهذا القسم (7.1) وأقسامه الفرعية، بالإضافة إلى أي سلوكيات إضافية خاصة بنوع الجهاز موثّقة في القسم 2 من مستند CDD هذا. على شاشات Android المتوافقة التي يمكن تشغيل جميع التطبيقات المتوافقة مع Android التابعة لجهات خارجية عليها، يجب أن تُنفِّذ عمليات تنفيذ الأجهزة واجهات برمجة التطبيقات هذه والسلوكيات بشكل صحيح، كما هو موضّح بالتفصيل في هذا القسم.

بدء متطلبات جديدة

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

• [C-0-1] يجب أن يتم عرض التطبيقات التابعة لجهات خارجية تلقائيًا على الشاشات المتوافقة مع Android فقط.

إنهاء المتطلبات الجديدة

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

• الحجم المادي القطري المسافة بين جهتَين متقابلتَين من الجزء المضيء من الشاشة، بالبوصة
• كثافة النقاط لكل بوصة (dpi) عدد وحدات البكسل التي تتضمنها مساحة قياسية أفقية أو عمودية تبلغ 1 بوصة، ويتم التعبير عنها بوحدات بكسل لكل بوصة (ppi أو dpi). في حال إدراج قيم dpi ppi وdpi، πρέπει أن تقع قيم dpi الأفقية والرأسية ضمن النطاق المُدرَج.
• نسبة العرض إلى الارتفاع نسبة وحدات البكسل في البُعد الأطول إلى البُعد الأقصر للشاشة على سبيل المثال، سيكون تنسيق شاشة بدقة 480×854 بكسل هو ‎854/480 = 1.779، أو ‎16:9 تقريبًا.
• وحدة البكسل المستقلة عن الكثافة (dp) وحدة بكسل افتراضية تم تسويتها لتتوافق مع شاشة بكثافة 160 نقطة لكل بوصة كثافة شاشة تبلغ 160. بالنسبة إلى كثافة معيّنة d وعدد وحدات البكسل p، يتم احتساب عدد وحدات البكسل المستقلة عن الكثافة dp على النحو التالي: وحدات البكسل = وحدات البكسل لكل بوصة * (الكثافة/160) dp = (160 / d) * p .

7.1.1. إعدادات الشاشة

7.1.1.1. حجم الشاشة وشكلها

يتيح إطار عمل واجهة مستخدم Android مجموعة متنوعة من أحجام تنسيق الشاشة المنطقي المختلفة، ويسمح للتطبيقات بالاستعلام عن حجم تنسيق الشاشة في الإعدادات الحالية من خلال Configuration.screenLayout باستخدام SCREENLAYOUT_SIZE_MASK وConfiguration.smallestScreenWidthDp.

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

• [C-0-1] يجب الإبلاغ عن حجم التنسيق الصحيح لملف Configuration.screenLayout كما هو محدّد في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android. وعلى وجه التحديد، يجب أن تُبلغ عمليات تنفيذ الأجهزة عن الأبعاد المنطقية الصحيحة لوحدات البكسل المستقلة الكثافة (dp) على الشاشة على النحو التالي:

  • يجب أن تكون الأجهزة التي تم ضبط Configuration.uiMode فيها على أي قيمة غير UI_MODE_TYPE_WATCH، والتي تُبلغ عن حجم small لسمة Configuration.screenLayout، أبعادها 426 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 وحدة بكسل
  • عند تثبيت صندوق أبعاده 1518 dp × 1518 dp في كلّ زاوية من الزوايا في الشاشة المنطقية، يظهر بكسل واحد على الأقل من كلّ صندوق على الشاشة.

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

بدء متطلبات جديدة

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

• [C-4-1] يجب أن يكون حجم التنسيق، باستثناء أيّ أجزاء مُقتطعة من الشاشة، هو 596 dp × 384 dp أو أكبر.

إنهاء المتطلبات الجديدة

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

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

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

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

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

بدء متطلبات جديدة

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

• [C-4-1] يجب تنفيذ الإصدار الصحيح من WindowManager Extensions API level كما هو موضّح في WindowManager Extensions.

إنهاء المتطلبات الجديدة

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

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

بدء متطلبات جديدة

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

إنهاء المتطلبات الجديدة

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

• [C-1-1] يجب عدم تغيير حجم الشاشة يجب عدم تغيير حجم الشاشة بمقدار أكبر من 1.5 مرة DENSITY_DEVICE_STABLE الكثافة الأصلية أو إنتاج الحد الأدنى الفعال لسمة الشاشة الأصغر من 320dp (أي ما يعادل مُحدِّد المورد sw320dp)، أيهما أقرب.
• [C-1-2] يجب عدم تغيير حجم الشاشة يجب عدم تغيير حجم الشاشة بمقدار أقل من 0.85 مرة من DENSITY_DEVICE_STABLE الكثافة الأصلية.
• لضمان سهولة الاستخدام وأحجام الخطوط المتسقة، ننصحك بتقديم الحجم التالي لخيارات العرض الأصلية (مع الالتزام بالحدود المذكورة أعلاه):
  • صغير: 0.85x
  • الإعداد التلقائي: 1x (مقياس الشاشة الأصلي)
  • كبير: 1.15x
  • أكبر: 1.3x
  • أكبر حجمًا 1.45x

7.1.2. مقاييس الشبكة الإعلانية

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

• [C-1-1] يجب الإبلاغ عن قيم صحيحة لجميع مقاييس شاشة التوافقية مع Android المحدّدة في واجهة برمجة التطبيقات android.util.DisplayMetrics.

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

• [C-2-1] يجب عرض القيم الصحيحة للشاشة المتوافقة مع Android كما هو محدّد في واجهة برمجة التطبيقات android.util.DisplayMetrics للشاشة التلقائية المحاكية view.Display.

7.1.3. اتجاه الشاشة

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

• [C-0-1] يجب الإبلاغ عن أوضاع الشاشة المتاحة (android.hardware.screen.portrait و/أو android.hardware.screen.landscape) ويجب الإبلاغ عن اتجاه واحد على الأقل متاح. على سبيل المثال، يجب أن يُبلغ الجهاز الذي يتضمّن شاشة عمودية ثابتة، مثل التلفزيون أو الكمبيوتر المحمول، عن android.hardware.screen.landscape فقط.
• [C-0-2] يجب عرض القيمة الصحيحة لاتجاه الجهاز الحالي، عند الاستعلام من خلال android.content.res.Configuration.orientation أو android.view.Display.getOrientation() أو واجهات برمجة تطبيقات أخرى.

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

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

7.1.4. ميزة "تسريع الرسومات" ثنائية وثلاثية الأبعاد

‎7.1.4.1 OpenGL ES

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

• [C-0-1] يجب تحديد إصدارات OpenGL ES المتوافقة (1.1 و2.0 و3.0 و3.1 و3.2) بشكل صحيح من خلال واجهات برمجة التطبيقات المُدارة (مثلاً من خلال GLES10.getString()) وواجهات برمجة التطبيقات الأصلية.
• [C-0-2] يجب أن تتضمّن التوافق مع جميع واجهات برمجة التطبيقات المُدارة المقابلة و واجهات برمجة التطبيقات الأصلية لكل إصدارات OpenGL ES التي تم تحديدها للتوافق معها.

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

• [C-1-1] يجب أن تكون متوافقة مع كلّ من OpenGL ES 1.1 و2.0، على النحو الموضّح بالتفصيل في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
• [C-SR-1] يُنصح بشدة بتوفُّر OpenGL ES 3.1.
• يجب أن يكون متوافقًا مع OpenGL ES 3.2.

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

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

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

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

• يجب أن تكون متوافقة مع الإضافتَين EGL_IMG_context_priority و EGL_EXT_protected_content.

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

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

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

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

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

• [C-5-1] يجب تحديد مدى توفّر الميزة من خلال android.hardware.opengles.aep علامة الميزة.

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

• [C-6-1] يجب أن تتيح أيضًا إضافة EGL_ANDROID_front_buffer_auto_refresh.

7.1.4.2 Vulkan

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

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

• [C-SR-1] يُنصح بشدة بتضمين الدعم لـ Vulkan 1.3.
• [C-4-1] يجب ألّا يكون متوافقًا مع إصدار متغير من Vulkan (أي يجب أن يكون الجزء المتغير من إصدار Vulkan الأساسي صفرًا).

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

• [C-SR-2] يُنصح بشدة بتضمين ميزة استخدام Vulkan 1.3.

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

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

• [C-1-1] يجب الإبلاغ عن القيمة الصحيحة للعدد الصحيح باستخدام علامتَي ميزة android.hardware.vulkan.level وandroid.hardware.vulkan.version.
• [C-1-2] يجب إدراج VkPhysicalDevice واحد على الأقل لواجهة برمجة التطبيقات المضمّنة Vulkan vkEnumeratePhysicalDevices().
• [C-1-3] يجب تنفيذ واجهات برمجة تطبيقات Vulkan 1.0 Vulkan 1.1 بالكامل لكل VkPhysicalDevice مُدرَج.
• [C-1-4] يجب إدراج الطبقات، المضمّنة في المكتبات المجمّعة من رموز برمجية أصلية والتي تحمل الاسم libVkLayer*.so في دليل المكتبة المجمّعة من رموز برمجية أصلية لحزمة التطبيق، من خلال واجهات برمجة التطبيقات المجمّعة من رموز برمجية أصلية لـ Vulkan vkEnumerateInstanceLayerProperties() وvkEnumerateDeviceLayerProperties().
• [C-1-5] يجب عدم إدراج الطبقات التي تقدّمها المكتبات خارج حزمة التطبيق، أو توفير طرق أخرى لتتبُّع واجهة برمجة التطبيقات Vulkan أو اعتراضها، ما لم يكن التطبيق يحتوي على سمة android:debuggable مُعدّة على القيمة true أو البيانات الوصفية com.android.graphics.injectLayers.enable مُعدّة على القيمة 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-3] يُنصح بشدة بتوفّر الإضافتَين VK_KHR_driver_properties وVK_GOOGLE_display_timing.

• يجب أن يكون متوافقًا مع VkPhysicalDeviceProtectedMemoryFeatures و VK_EXT_global_priority.

• [C-1-12] يجب عدم إدراج إمكانية استخدام إضافة VK_KHR_performance_query.

• [C-1-13] يجب أن تستوفي المتطلبات المحدّدة في ملف Android Baseline 2021.

• [C-SR-4] يُنصح بشدة باستيفاء المتطلبات المحدّدة في ملف Android Baseline 2022 الشخصي.

بدء متطلبات جديدة

• [C-SR-5] يُنصح بشدة بتوفّر VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory وVK_EXT_global_priority.

• [C-SR-6] يُنصح بشدة باستخدام SkiaVk مع HWUI.

إنهاء المتطلبات الجديدة

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

بدء متطلبات جديدة

• [C-SR-7] يُنصح بشدة بتوفير إضافة VK_KHR_external_fence_fd للتطبيقات التابعة لجهات خارجية وتفعيل التطبيق لتصدير الحمولة إلى وصفاء الحدود واستيرادها من وصفاءملف POSIX كما هو موضّح هنا.

إنهاء المتطلبات الجديدة

7.1.4.3 RenderScript

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

7.1.4.4 ميزة "تسريع الرسومات ثنائية الأبعاد"

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

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

• [C-0-1] يجب تفعيل ميزة "تسريع الأجهزة" تلقائيًا، ويجب إيقافها إذا طلب المطوِّر ذلك من خلال ضبط قيمة android:hardwareAccelerated="false” أو إيقافها مباشرةً من خلال واجهات برمجة التطبيقات Android View 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-SR-2] يُنصح بشدة بتوفير جميع وظائف التنقّل على أنّها قابلة للإلغاء. يتم تعريف "قابل للإلغاء" على أنّه قدرة المستخدم على منع تنفيذ وظيفة التنقّل (مثل الانتقال إلى الصفحة الرئيسية أو الرجوع إلى الخلف وما إلى ذلك) في حال عدم رفع إصبع المستخدم عن الشاشة بعد مرور حدّ معيّن.

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

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

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

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

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

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

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

• [C-5-1] يجب أن تستخدم مفاتيح التنقّل جزءًا محددًا من الشاشة غير متاح للتطبيقات، ويجب ألّا تحجب أو تتداخل مع الجزء من الشاشة المتاح للتطبيقات.
• [C-5-2] يجب أن يتيح الجهاز جزءًا من الشاشة للتطبيقات التي تفي بالمتطلبات المحدّدة في الفقرة 7.1.1.
• [C-5-3] يجب أن يراعي التطبيق العلامات التي يضبطها من خلال View.setSystemUiVisibility() طريقة واجهة برمجة التطبيقات، وذلك لإخفاء هذا الجزء الواضح من الشاشة (المعروف أيضًا باسم شريط التنقّل) بشكلٍ سليم كما هو موضّح في مستندات IDE.

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

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

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

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

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

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

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

• [C-9-1] يجب أن يتيح استخدام الرموز الملائمة للأطفال أو التنقل بالاستناد إلى buttons كما هو موضّح في رمز 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] يجب أن يتيح الجهاز تتبُّعًا دقيقًا لـ 5 (تتبُّع يد مكوّنة من أصابع) أو أكثر من إشارات المؤشر بشكل مستقل تمامًا.

7.2.6. توافق مع أجهزة التحكّم في الألعاب

7.2.6.1. عمليات ربط الأزرار

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

• [C-1-1] يجب أن يكون النظام قادرًا على ربط أحداث HID بثوابت InputEvent المقابلة كما هو موضّح في الجداول أدناه. يستوفي تطبيق Android هذا الشرط.

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

• [C-2-1] يجب الإفصاح عن علامة الميزة android.hardware.gamepad

زرّ	استخدام HID^2	زر Android
أ^1	0x09 0x0001	KEYCODE_BUTTON_A (96)
ب^1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X^1	0x09 0x0004	KEYCODE_BUTTON_X (99)
نعم^1	0x09 0x0005	KEYCODE_BUTTON_Y (100)
أداة التوجيه العلوية^1 أداة التوجيه السفلية^1	‎0x01 0x0039^3	AXIS_HAT_Y^4
الزر الأيسر في لوحة التحكم1 الزر الأيمن في لوحة التحكم^1	‎0x01 0x0039^3	AXIS_HAT_X^4
زرّ أعلى ذراع التحكّم الأيسر^1	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
زرّ أعلى ذراع التحكّم الأيمن^1	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
النقر على العصا اليسرى^1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
النقر على ذراع التحكم الأيمن^1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
رجوع^1	0x0c 0x0224	KEYCODE_BACK (4)

‫1 KeyEvent

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

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

‫4 MotionEvent

عناصر التحكّم التناظرية^1	استخدام HID	زر Android
المشغِّل الأيسر	0x02 0x00C5	AXIS_LTRIGGER
مشغِّل الإجراء الأيمن	0x02 0x00C4	AXIS_RTRIGGER
ذراع التحكّم الأيسر	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
ذراع التحكّم الأيمن	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

‫1 MotionEvent

7.2.7. جهاز التحكّم عن بُعد

اطّلِع على الفقرة 2.3.1 لمعرفة المتطلبات الخاصة بالأجهزة.

7.3. أجهزة الاستشعار

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

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

• [C-0-1] يجب الإبلاغ بدقة عن توفّر أدوات الاستشعار أو عدم توفّرها وفقًا ل android.content.pm.PackageManager الفئة.
• [C-0-2] يجب أن يعرض التطبيق قائمة دقيقة بأجهزة الاستشعار المتوافقة من خلال SensorManager.getSensorList() والطرق المشابهة.
• [C-0-3] يجب أن تعمل بشكل معقول مع جميع واجهات برمجة التطبيقات الأخرى الخاصة بأجهزة الاستشعار (على سبيل المثال، عن طريق عرض true أو false حسب الاقتضاء عندما تحاول التطبيقات تسجيل المستمعين، وعدم استدعاء مستمعي أجهزة الاستشعار عندما لا تكون أجهزة الاستشعار المقابلة متوفّرة، وما إلى ذلك).

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

• [C-1-1] يجب الإبلاغ عن جميع قياسات أجهزة الاستشعار باستخدام قيم النظام الدولي للوحدات (المقياس) ذات الصلة لكل نوع من أجهزة الاستشعار كما هو محدّد في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
• [C-1-2] يجب الإبلاغ عن بيانات أجهزة الاستشعار بحد أقصى لمُدد الاستجابة يبلغ 100 ملي ثانية + 2 * وقت_التحليل في حال بث بيانات أجهزة الاستشعار بحد أقصى لمُدد الاستجابة المطلوبة يبلغ 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-3] يجب أن تكون متوافقة مع نظام إحداثيات أدوات استشعار Android كما هو موضّح في واجهات برمجة تطبيقات Android.
• [C-1-4] يجب أن يكون الجهاز قادرًا على قياس التسارع من السقوط الحر إلى أربع مرات كثافة الجاذبية(4g) أو أكثر على أي محور.
• [C-1-5] يجب أن تكون درجة دقة الصورة 12 بت على الأقل.
• [C-1-6] يجب أن يكون التباين المعياري لا يزيد عن 0.05 متر في الثانية المربعة، حيث يجب احتساب التباين المعياري لكل محور على أساس عيّنات يتم جمعها على مدار 3 ثوانٍ على الأقل بأسرع معدّل تحليل.
• يجب الإبلاغ عن الأحداث التي تصل إلى 200 هرتز على الأقل.
• يجب أن تكون درجة دقتها 16 بت على الأقل.
• يجب معايرة هذه الخصائص أثناء الاستخدام إذا تغيّرت على مدار دورة الحياة، ويجب تعويضها والحفاظ على مَعلمات التعويض بين عمليات إعادة تشغيل الجهاز.
• يجب أن يتم تصحيحها حسب درجة الحرارة.

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

• [C-2-1] يجب تنفيذ TYPE_ACCELEROMETER sensor والإبلاغ عنه.
• [C-SR-4] يُنصح بشدة بتنفيذ TYPE_SIGNIFICANT_MOTION أداة الاستشعار المركبة.
• [C-SR-5] يُنصح بشدة بتنفيذ رصد TYPE_ACCELEROMETER_UNCALIBRATED والإبلاغ عنه. ننصح بشدة باستيفاء أجهزة Android لهذا الشرط حتى تتمكّن من الترقية إلى إصدار المنصة المستقبلي الذي قد يصبح فيه هذا الشرط مطلوبًا.
• يجب تنفيذ TYPE_SIGNIFICANT_MOTION وTYPE_TILT_DETECTOR TYPE_STEP_DETECTOR وTYPE_STEP_COUNTER الأجهزة الاستشعارية المركبة كما هو موضّح في مستند حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

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

• [C-3-1] يجب تنفيذ TYPE_ACCELEROMETER_LIMITED_AXES sensor والإبلاغ عنه.
• [C-SR-6] يُنصح بشدة بتنفيذ رصد TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED والإبلاغ عنه.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن أداة تسارع 3 محاور وأيًا من أجهزة الاستشعار المركبة TYPE_SIGNIFICANT_MOTION وTYPE_TILT_DETECTOR وTYPE_STEP_DETECTOR TYPE_STEP_COUNTER:

• [C-4-1] يجب أن يكون مجموع استهلاك الطاقة أقل من 4 ملي واط في أي وقت.
• يجب أن يكون كل منهما أقل من 2 ملي واط و0.5 ملي واط عندما يكون الجهاز في حالة ديناميكية أو ساكنة.

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

• [C-5-1] يجب تنفيذ TYPE_GRAVITY وTYPE_LINEAR_ACCELERATION أجهزة الاستشعار المركبة.
• [C-SR-7] يُنصح بشدة بتنفيذ أداة الاستشعار المركبة TYPE_GAME_ROTATION_VECTOR.

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

• [C-6-1] يجب استخدام أداة استشعار مركبة TYPE_ROTATION_VECTOR.

7.3.2. مقياس المغناطيسية

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

• [C-SR-1] يُنصح بشدة بتضمين مقياس مغناطيسي ثلاثي المحاور (بوصلة).

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

• [C-1-1] يجب تنفيذ أداة استشعار TYPE_MAGNETIC_FIELD.
• [C-1-2] يجب أن يكون الجهاز قادرًا على تسجيل الأحداث بمعدّل تكرار لا يقل عن 10 هرتز، ويجب أن يسجِّل الأحداث بمعدّل تكرار لا يقل عن 50 هرتز.
• [C-1-3] يجب أن يكون متوافقًا مع نظام إحداثيات أدوات استشعار Android كما هو موضّح بالتفصيل في واجهات برمجة تطبيقات Android.
• [C-1-4] يجب أن يكون الجهاز قادرًا على قياس قيم تتراوح بين -900 و+900 µ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-4] يجب أن تكون درجة دقة الصورة 12 بت أو أكثر.
• [C-1-5] يجب أن يكون مُعدَّلاً للحرارة.
• [C-1-6] يجب معايرة الجهاز وتعويضه أثناء الاستخدام، والحفاظ على مَعلمات التعويض بين عمليات إعادة تشغيل الجهاز.
• [C-1-7] يجب ألا يزيد التباين عن 1e-7 rad^2 / s^2 لكل هرتز (التباين لكل هرتز أو rad^2 / s). يُسمح باختلاف التباين مع معدل أخذ العينات، ولكن يجب أن يكون مقيّدًا بهذه القيمة. بعبارة أخرى، إذا measuredيتم قياس التباين في أداة الاستشعار الدوراني بمعدّل أخذ عينات يبلغ 1 هرتز، يجب ألا يزيد عن 1e-7 rad^2/s^2.
• [C-SR-2] يُنصح بشدة بأن يكون خطأ المعايرة أقل من 0.01 راد/ث عندما يكون الجهاز ثابتًا في درجة حرارة الغرفة.
• [C-SR-3] يُنصح بشدة بدرجة دقة 16 بت أو أكثر.
• يجب الإبلاغ عن الأحداث التي تصل إلى 200 هرتز على الأقل.

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

• [C-2-1] يجب تنفيذ أداة استشعار TYPE_GYROSCOPE.
• [C-SR-4] يُنصح بشدة بتنفيذ أداة الاستشعار TYPE_GYROSCOPE_UNCALIBRATED.

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

• [C-3-1] يجب تنفيذ TYPE_GYROSCOPE_LIMITED_AXES sensor والإبلاغ عنه.
• [C-SR-5] ننصح بشدة بتنفيذ قياسات TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED والإبلاغ عنها.

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

• [C-4-1] يجب استخدام أداة استشعار مركبة TYPE_ROTATION_VECTOR.

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

• [C-5-1] يجب تنفيذ TYPE_GRAVITY وTYPE_LINEAR_ACCELERATION أجهزة الاستشعار المركبة.
• [C-SR-6] يُنصح بشدة بتنفيذ أداة الاستشعار المركبة TYPE_GAME_ROTATION_VECTOR.

7.3.5. مقياس الضغط الجوي

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

• [C-SR-1] يُنصح بشدة بتضمين مقياس ضغط جوي (جهاز استشعار ضغط الهواء المحيط).

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

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

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

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

إنهاء المتطلبات الجديدة

• [C-SR-3] يُنصح بشدة بطلب تأكيد مقياس حيوي واحد فقط لكل عملية مصادقة (على سبيل المثال، إذا كانت أداتا استشعار بصمة الإصبع والوجه متوفرة على الجهاز، يجب إرسال onAuthenticationSucceeded بعد تأكيد أيٍّ منهما).

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

• [C-6-1] يجب أن تستوفي المتطلبات الخاصة بالفئة 3 على النحو المحدّد في هذا القسم أدناه.
• [C-6-2] يجب تقديم المقاييس الحيوية من الفئة 3 فقط عندما تتطلّب المصادقة BIOMETRIC_STRONG، أو يتمّ استدعاء المصادقة باستخدام CryptoObject.

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

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

• [C-1-10] يجب إيقاف المقاييس الحيوية بعد بدء المدة الزمنية الإضافية للمصادقة الأساسية للمرة الأولى على النحو الموضّح في [C-0-2] من القسم 9.11.

• [C-1-11] يجب أن يكون معدّل قبول المحاكاة والتزوير أقل من %30، مع (1) معدّل قبول المحاكاة والتزوير لأنواع أدوات هجمات عرض المستوى (PAI) من الفئة (أ) أقل من %30، و(2) معدّل قبول المحاكاة والتزوير لأنواع أدوات هجمات عرض المستوى (PAI) من الفئة (ب) أقل من %40، كما هو مُقاس من خلال بروتوكولات اختبار المقاييس الحيوية في Android.

• [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 ساعة أو أقل.

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

  • مهلة عدم النشاط لمدة 4 ساعات
  • 3 محاولات مصادقة بالمقاييس الحيوية غير ناجحة
  • تتم إعادة ضبط فترة الانتظار في حالة عدم النشاط وعدد عمليات المصادقة غير الناجحة بعد أي تأكيد ناجح لبيانات اعتماد الجهاز. ملاحظة: قد يتم استثناء ترقية الأجهزة التي تم إطلاقها باستخدام الإصدار 9 من Android أو الإصدارات الأقدم من C-1-8.

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

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

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

بدء متطلبات جديدة

• [C-1-12] يجب ألا يزيد معدّل قبول عمليات التزوير والتصيّد الاحتيالي عن %40 لكل نوع من أدوات هجمات المحاكاة، وذلك وفقًا لما يتم قياسه في بروتوكولات اختبار المقاييس الحيوية في Android.

• [C-SR-13] يُنصح بشدة بأن يكون معدّل قبول المحاكاة والتزوير لا يزيد عن% 30 لكل نوع من أدوات هجمات المحاكاة (PAI)، كما يتم قياسه من خلال بروتوكولات اختبار المقاييس الحيوية في Android.

• [C-SR-14] يُنصح بشدة بالكشف عن فئة المقاييس الحيوية لجهاز قياس المقاييس الحيوية والمخاطر المرتبطة بتفعيله.

• [C-SR-17] ننصح بشدة بتنفيذ واجهات AIDL الجديدة (مثل IFace.aidl وIFingerprint.aidl).

إنهاء المتطلبات الجديدة

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

• [C-2-1] يجب استيفاء جميع متطلبات الفئة 1 أعلاه.

• [C-2-2] يجب أن يكون معدّل قبول المحاكاة والتزوير أقل من %20، مع (1) معدّل قبول المحاكاة والتزوير لأنواع أدوات هجمات المحاكاة (PAI) من المستوى "أ" أقل من %20، و(2) معدّل قبول المحاكاة والتزوير لأنواع أدوات هجمات المحاكاة (PAI) من المستوى "ب" أقل من %30، وفقًا لما يتم قياسه في بروتوكولات اختبار المقاييس الحيوية في Android.

بدء متطلبات جديدة

• [C-SR-15] يُنصح بشدة بأن يكون معدّل قبول عمليات التزوير والتحايل لا يزيد عن% 20 لكل نوع من أدوات هجمات المحاكاة، كما يتم قياسه من خلال بروتوكولات اختبار المقاييس الحيوية في Android.

إنهاء المتطلبات الجديدة

• [C-2-3] يجب تنفيذ عملية مطابقة المقاييس الحيوية في بيئة تنفيذ معزولة خارج مساحة مستخدم Android أو مساحة نظام التشغيل، مثل بيئة التنفيذ الموثوقة (TEE)، أو على شريحة تتضمّن قناة آمنة تؤدي إلى بيئة التنفيذ المعزولة أو على جهاز افتراضي محمي يستوفي المتطلبات الواردة في القسم 9.17.
• [C-2-4] يجب أن تكون جميع البيانات التعريفية مشفَّرة ومصادق عليها cryptographically بحيث لا يمكن الحصول عليها أو قراءتها أو تغييرها خارج بيئة التنفيذ المعزولة أو شريحة تتضمّن قناة آمنة تؤدي إلى بيئة التنفيذ المعزولة كما هو موضّح في إرشادات التنفيذ على الموقع الإلكتروني لمشروع Android Open Source Project أو آلة افتراضية محمية يتحكّم فيها نظام التشغيل الظاهري وتستوفي المتطلبات الواردة في القسم 9.17.
• [C-2-5] بالنسبة إلى المقاييس الحيوية المستندة إلى الكاميرا، أثناء المصادقة أو التسجيل المستندَين إلى المقاييس الحيوية:
  • يجب تشغيل الكاميرا في وضع يمنع قراءة إطارات الكاميرا أو تعديلها خارج بيئة التنفيذ المعزول أو شريحة تتضمّن قناة آمنة تؤدي إلى بيئة التنفيذ المعزول أو جهاز افتراضي محمي يتحكّم فيه نظام التشغيل الظاهري ويستوفي المتطلبات الواردة في القسم 9.17.
  • بالنسبة إلى حلول الكاميرا الواحدة ذات الإضاءة الملوّنة (RGB)، يمكن قراءة إطارات الكاميرا خارج بيئة التنفيذ المعزولة لدعم العمليات، مثل المعاينة للتسجيل، ولكن يجب ألّا تكون قابلة للتغيير.
• [C-2-6] يجب عدم السماح للتطبيقات التابعة لجهات خارجية بالتمييز بين عمليات التسجيل البيومتري الفردية.
• [C-2-7] يجب عدم السماح بالوصول غير المشفَّر إلى البيانات الحيوية القابلة للتحديد أو أي بيانات مشتقة منها (مثل البيانات المضمَّنة) إلى "معالج التطبيقات" خارج سياق "بيئة التنفيذ الموثوقة" أو "الجهاز الافتراضي المحمي" الذي يتحكّم فيه "برنامج التشغيل الظاهري" ويستوفي المتطلبات الواردة في "الفقرة 9.17". لا يتم استثناء الأجهزة التي تم ترقيتها من الإصدار 9 من نظام التشغيل Android أو الإصدارات الأقدم من C-2-7.

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

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

• [C-2-9] يجب إتاحة أداة الاستشعار الحيوية للتطبيقات التابعة لجهات خارجية.

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

• يجب أن يستوفي [C-3-1] جميع متطلبات الفئة 2 أعلاه، باستثناء [C-1-7] و[C-1-8].
• [C-3-2] يجب أن يكون هناك تطبيق لمستودع مفاتيح مستند إلى الأجهزة.
• [C-3-3] يجب ألا يزيد معدّل قبول عمليات التزوير والتصيّد الاحتيالي عن %7، مع (1) عدم تجاوز معدّل قبول عمليات التزوير والتصيّد الاحتيالي لأنواع أدوات هجمات المحاكاة (PAI) من المستوى A %7، (2) عدم تجاوز معدّل قبول عمليات التزوير والتصيّد الاحتيالي لأنواع أدوات هجمات المحاكاة (PAI) من المستوى B %20، وفقًا لما يتم قياسه في بروتوكولات اختبار المقاييس الحيوية في Android.
• [C-3-4] يجب أن يطلب الجهاز من المستخدم إدخال مصادقة أساسية مقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) مرة واحدة كل 72 ساعة أو أقل.
• [C-3-5] يجب إعادة إنشاء معرّف المصادقة لجميع ميزات المقاييس الحيوية من الفئة 3 المتوافقة على الجهاز في حال إعادة تسجيل أي منها.
• [C-3-6] يجب تفعيل مفاتيح ملف تخزين المفاتيح المستندة إلى المقاييس الحيوية لتطبيقات الجهات الخارجية.

بدء متطلبات جديدة

• [C-SR-16] يُنصح بشدة بأن يكون معدّل قبول عمليات التزوير والتحايل لا يزيد عن% 7 لكل نوع من أدوات هجمات المحاكاة، كما يتم قياسه من خلال بروتوكولات اختبار المقاييس الحيوية في Android.

إنهاء المتطلبات الجديدة

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

• [C-SR-11] يُنصح بشدة بمنع المنطقة القابلة للمس في UDFPS من التدخل في التنقّل باستخدام 3 أزرار (الذي قد يحتاجه بعض المستخدمين لأغراض تسهيل الاستخدام).

7.3.11. أداة استشعار الوضعية

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

• قد تتيح استخدام أداة استشعار الوضع بـ 6 درجات من الحرية.

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

• [C-1-1] يجب تنفيذ TYPE_POSE_6DOF جهاز الاستشعار والإبلاغ عنه.
• [C-1-2] يجب أن تكون أكثر دقة من متجه الدوران وحده.

7.3.12. أداة استشعار زاوية المفصل

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

• [C-1-1] يجب تنفيذ TYPE_HINGLE_ANGLE والإبلاغ عنه.
• [C-1-2] يجب أن يتيح الجهاز قراءة قراءتَين على الأقل بين 0 و360 درجة (بما في ذلك 0 و360 درجة).
• [C-1-3] يجب عرض مستشعر للتنشيط getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

7.3.13. IEEE 802.1.15.4 (النطاق الفائق العرض)

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

بدء متطلبات جديدة

• [C-1-2] يجب الإبلاغ عن علامة ميزة الجهاز android.hardware.uwb.
• [C-1-3] يجب أن تتوافق مع جميع مجموعات الإعدادات التالية (مجموعات مُحدَّدة مسبقًا لمَعلمات FIRA UCI) المحدَّدة في عملية تنفيذ AOSP.
  • CONFIG_ID_1: قياس المسافة عبر بث STATIC STS DS-TWR أحادي الوجهة تحدّده جمعية FiRa، الوضع المؤجّل، الفاصل الزمني لقياس المسافة 240 ملي ثانية
  • ‫CONFIG_ID_2: قياس المسافة من جهاز إلى عدة أجهزة STATIC STS DS-TWR وفقًا لمعيار FiRa، الوضع المؤجل، الفاصل الزمني لقياس المسافة 200 ملي ثانية. حالة الاستخدام المعتادة: هاتف ذكي يتفاعل مع العديد من الأجهزة الذكية.
  • CONFIG_ID_3: الإجراء نفسه المُتّبع في CONFIG_ID_1، باستثناء أنّه لا يتم تسجيل بيانات ∡ زاوية الوصول (AoA).
  • CONFIG_ID_4: القيمة نفسها المُستخدَمة في CONFIG_ID_1، باستثناء أنّه تم تفعيل وضع أمان P-STS.
  • CONFIG_ID_5: القيمة نفسها المُستخدَمة في CONFIG_ID_2، باستثناء أنّه تم تفعيل وضع أمان P-STS.
  • CONFIG_ID_6: القيمة نفسها المُستخدَمة في CONFIG_ID_3، باستثناء أنّه تم تفعيل وضع أمان P-STS.
  • CONFIG_ID_7: يشبه CONFIG_ID_2، باستثناء أنّه تم تفعيل وضع مفتاح التحكّم الفردي في P-STS.
• [C-1-4] يجب توفير عنصر تحكم للمستخدم للسماح له بتفعيل/إيقاف تكنولوجيا UWB الراديو.
• [C-1-5] يجب فرض أن تحصل التطبيقات التي تستخدم شبكة UWB اللاسلكية على إذن UWB_RANGING (ضمن مجموعة أذونات NEARBY_DEVICES).

يساعد اجتياز اختبارات الامتثال والاعتماد ذات الصلة التي تحدّدها منظمات المعايير، بما في ذلك FIRA وCCC وCSA، في ضمان عمل معيار 802.1.15.4 بشكل صحيح.

إنهاء المتطلبات الجديدة

7.4. إمكانية الوصول إلى البيانات

7.4.1. الاتصالات الهاتفية

يشير مصطلح "الهاتف" كما تستخدمه واجهات برمجة تطبيقات Android وهذا المستند تحديدًا إلى الأجهزة ذات الصلة بإجراء المكالمات الصوتية وإرسال الرسائل القصيرة أو إعداد بيانات الجوّال عبر شبكة الجوّال (مثل GSM أو CDMA أو LTE أو NR). يمكن للجهاز المتوافق مع "الاتصال الهاتفي" اختيار تقديم بعض خدمات المكالمات والمراسلة والبيانات أو جميعها بما يتناسب مع المنتج.

عبر شبكة 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] يجب الإفصاح عن علامة ميزة android.hardware.telephony.euicc.

إذا لم تضبط عمليات تنفيذ الأجهزة سمة النظام 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.

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

• [C-6-1] يجب أن يؤدي SmsManager#sendTextMessage وSmsManager#sendMultipartTextMessage إلى إجراء مكالمات مقابلة إلى CarrierMessagingService لتوفير وظيفة المراسلة النصية. SmsManager#sendMultimediaMessage و SmsManager#downloadMultimediaMessage يجب أن تؤدي إلى إجراء مكالمات مقابلة إلى CarrierMessagingService لتوفير وظيفة المراسلة عبر الوسائط المتعددة.
• [C-6-2] على التطبيق الذي يُشار إليه باسم android.provider.Telephony.Sms#getDefaultSmsPackage استخدام واجهات برمجة التطبيقات SmsManager عند إرسال رسائل SMS ورسائل الوسائط المتعددة واستلامها. يستوفي تنفيذ مرجع AOSP في الحِزم/التطبيقات/الرسائل هذا الشرط.
• [C-6-3] يجب أن يتيح التطبيق الذي يستجيب لرمز Intent#ACTION_DIAL إدخال رموز عشوائية للمتصل بتنسيق *#*#CODE#*#* وبدء بث TelephonyManager#ACTION_SECRET_CODE ملائم.
• [C-6-4] على التطبيق الذي يستجيب لطلب Intent#ACTION_DIAL استخدام VoicemailContract.Voicemails#TRANSCRIPTION لعرض تحويل رسائل البريد الصوتي إلى نص للمستخدمين إذا كان يتيح تحويل رسائل البريد الصوتي إلى نص.
• [C-6-5] يجب أن تمثّل جميع SubscriptionInfo باستخدام معرّفات مجموعة UUID مماثلة كاشتراك واحد في جميع عناصر التحكم المرئية للمستخدم والتي تعرِض معلومات شريحة SIM وتتحكّم فيها. وتشمل أمثلة هذه الإمكانات واجهات الإعدادات التي تتطابق مع رمزَي Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS أو EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS.
• [C-6-6] يجب عدم عرض أي عنصر SubscriptionInfo أو السماح بالتحكم فيه إذا كان يحتوي على معرّف UUID للمجموعة غير صفري وبت احتياطي في أي عناصر ظاهرة للمستخدمين تسمح بالضبط أو التحكّم في إعدادات بطاقة SIM.

إذا كانت عمليات تنفيذ الأجهزة تُبلغ عن ميزة android.hardware.telephony وتوفّر شريط حالة النظام، يجب اتّباع الخطوات التالية:

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

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

• [C-6-7] يجب أن يكون الجهاز قادرًا على فتح الحد الأقصى لعدد القنوات المنطقية (20 قناة في المجمل) لكل شريحة UICC واستخدامها بشكل متزامن وفقًا لمعيار ETSI TS 102 221.
• [C-6-8] يجب عدم تطبيق أي من السلوكيات التالية على تطبيقات مشغّلي شبكات الجوّال النشطين (على النحو المحدّد من قِبل TelephonyManager#getCarrierServicePackageName) تلقائيًا أو بدون تأكيد صريح من المستخدم:
  • إبطال إذن الوصول إلى الشبكة أو تقييده
  • إبطال الأذونات
  • تقييد تنفيذ التطبيقات في المقدّمة أو الخلفية خارج نطاق ميزات إدارة الطاقة الحالية المضمّنة في AOSP
  • إيقاف التطبيق أو إلغاء تثبيته

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

• [C-8-1] يجب إيقاف جميع الاشتراكات الانتهازية النشطة المتبقية في المجموعة نفسها تلقائيًا.

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

• [C-9-1] يجب عدم الإفصاح عن PackageManager#FEATURE_TELEPHONY_CDMA.
• [C-9-2] يجب أن يُرسِل الجهاز IllegalArgumentException عند محاولات ضبط أي أنواع شبكات 3GPP2 في أقنعة بت لأنواع الشبكات المفضّلة أو المسموح بها.
• [C-9-3] يجب أن تعرض سلسلة فارغة من TelephonyManager#getMeid.

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

• [C-10-1] يجب الإفصاح عن علامة ميزة android.hardware.telephony.euicc.mep.

7.4.1.1. توافق حظر الأرقام

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

• [C-1-1] يجب أن تتضمّن ميزة حظر الأرقام
• [C-1-2] يجب تنفيذ BlockedNumberContract وواجهة برمجة التطبيقات المقابلة لها بالكامل على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK).

• [C-1-3] يجب حظر جميع المكالمات والرسائل الواردة من رقم هاتف في ملف "موفِّر الأرقام المحظورة" بدون أي تفاعل مع التطبيقات. ويتمثل الاستثناء الوحيد في رفع حظر الأرقام مؤقتًا كما هو موضّح في مستندات SDK.

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

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

• [C-1-6] يجب تنفيذ واجهة مستخدم لإدارة الأرقام المحظورة، والتي يتم فتحها باستخدام النية التي تعرضها طريقة TelecomManager.createManageBlockedNumbersIntent().

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

• من المفترض نقل الأرقام المحظورة إلى مقدّم الخدمة عند تحديث أحد الأجهزة إلى Android 7.0.

• يجب أن يقدّم التطبيق ميزة للمستخدم لعرض المكالمات المحظورة في تطبيق DIALER المثبَّت مسبقًا.

7.4.1.2. Telecom API

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

• [C-1-1] يجب أن تتوافق مع واجهات برمجة تطبيقات ConnectionService الموضّحة في حزمة تطوير البرامج (SDK).
• [C-1-2] يجب عرض مكالمة واردة جديدة وتوفير إمكانات للمستخدم لقبول المكالمة الواردة أو رفضها عندما يكون المستخدم في مكالمة جارية يجريها تطبيق تابع لجهة خارجية لا يتيح ميزة الانتظار المحدَّدة من خلال CAPABILITY_SUPPORT_HOLD.
• [C-1-3] يجب أن يتضمّن التطبيق فئة برمجة التطبيقات InCallService.

• [C-SR-1] يُنصح بشدة بإعلام المستخدم بأنّ الردّ على مكالمة واردة سيؤدي إلى إنهاء مكالمة حالية.

  يستوفي تنفيذ AOSP هذه المتطلبات من خلال إشعار تنبيه يشير إلى المستخدم بأنّ الردّ على مكالمة واردة سيؤدي إلى إنهاء المكالمة الأخرى.

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

• [C-SR-3] يُنصح بشدة بمعالجة حدثَي KEYCODE_MEDIA_PLAY_PAUSE وKEYCODE_HEADSETHOOK لسماعات الرأس الصوتية في واجهات برمجة التطبيقات android.telecom على النحو التالي:

  • اتصل بالرقم Connection.onDisconnect() عند رصد ضغطة قصيرة على الحدث الرئيسي أثناء مكالمة جارية.
  • اتصل بالرقم Connection.onAnswer() عند رصد ضغطة قصيرة على الحدث الرئيسي أثناء مكالمة واردة.
  • اتصل بالرقم Connection.onReject() عند رصد الضغط مع الاستمرار على الحدث الرئيسي أثناء مكالمة واردة.
  • فعِّل أو أوقِف ميزة كتم الصوت في CallAudioState.

7.4.1.3. نقل بيانات رسالة التحقّق من الاتصال في بروتوكول NAT-T على شبكة الجوّال

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

• يجب أن يتضمّن ذلك إمكانية إيقاف خدمة "إبقاء الاتصال بالإنترنت" على شبكة الجوّال.

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

• [C-1-1] يجب أن تكون متوافقة مع واجهة برمجة التطبيقات SocketKeepAlive API.
• [C-1-2] يجب أن تتيح فتحة واحدة على الأقل للاحتفاظ بحالة الاتصال في الوقت الفعلي بشكل متزامن عبر شبكة الجوّال.
• [C-1-3] يجب أن تتيح أكبر عدد ممكن من خانات keepalive الخلوية المتزامنة التي يسمح بها واجهة HAL لجهاز الراديو الخلوي.
• [C-SR-1] يُنصح بشدة بتوفير ثلاث خانات على الأقل للحفاظ على الاتصال الخلوي لكل مثيل من جهاز البث.

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

• [C-2-1] يجب عرض ERROR_UNSUPPORTED.

7.4.2. معيار IEEE 802.11 (لشبكات Wi-Fi)

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

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

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

• [C-1-1] يجب تنفيذ واجهة برمجة تطبيقات Android المقابلة.
• [C-1-2] يجب الإبلاغ عن علامة ميزة الجهاز android.hardware.wifi.
• [C-1-3] يجب تنفيذ واجهة برمجة التطبيقات لبث الوسائط المتعدّدة على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK).
• [C-1-4] يجب أن يكون الجهاز متوافقًا مع نظام أسماء النطاقات ذي البث المتعدد (mDNS) ويجب عدم فلترة حزم mDNS (224.0.0.251 أو ff02::fb) في أي وقت من أوقات التشغيل، بما في ذلك عندما تكون الشاشة في حالة غير نشطة، ما لم يكن إسقاط هذه الحِزم أو تصفيتها ضروريًا للبقاء ضمن نطاقات استهلاك الطاقة المطلوبة بموجب المتطلبات التنظيمية السارِية في السوق المستهدَف. في عمليات تنفيذ أجهزة 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)، يجب أن تستوفي المتطلبات التالية:

• [C-1-1] يجب أن تتضمّن 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] يُنصح بشدة بتوفير ميزة "معلومات عن المكان".

في حال توفُّر مفتاح تحكّم عام في إيقاف 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 ميغاهرتز في المئة السادسة والستون (كما يتم احتسابها باستخدام دالة التوزيع التجميعي).
• [C-SR-1] يُنصح بشدة بالإبلاغ عن ذلك بدقة ضمن نطاق 1.5 متر عند عرض النطاق بتردد 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 لنظام التشغيل Enterprise يدوياً في تطبيق "الإعدادات".

7.4.2.9. الثقة في أول استخدام (TOFU)

إذا كانت عمليات تنفيذ الأجهزة تتيح ميزة "الثقة عند الاستخدام الأول" (TOFU) وتسمح للمستخدم بتحديد إعدادات WPA/WPA2/WPA3-Enterprise، يمكنها إجراء ما يلي:

• [C-4-1] يجب أن يوفّر التطبيق للمستخدم خيارًا لاختيار استخدام ميزة TOFU.

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.

إذا كانت عمليات تنفيذ الأجهزة تعرض true لواجهة برمجة التطبيقات BluetoothAdapter.isLeAudioSupported()، يعني ذلك أنّها:

• [C-7-1] يجب أن يكون متوافقًا مع برنامج بث المحتوى المباشر إلى مستخدم واحد.
• [C-7-2] يجب أن يكون الجهاز متوافقًا مع واجهة النقل الفيزيائية بمعيار 2M.
• [C-7-3] يجب أن يكون متوافقًا مع الإعلانات الموسّعة في LE.
• [C-7-4] يجب أن تتيح إمكانية إجراء اتصالَين على الأقل بشبكة CIS في شبكة CIG.
• [C-7-5] يجب تفعيل برنامج BAP لعملاء البث المباشر، وتنسيق CSIP، وتنسيق CSIP، وخادم MCP، ووحدة التحكّم في VCP، وخادم CCP في الوقت نفسه.
• [C-SR-1] يُنصح بشدة بتفعيل عميل البث المباشر لبروتوكول HAP.

إذا كانت عمليات تنفيذ الأجهزة تعرض true لواجهة برمجة التطبيقات BluetoothAdapter.isLeAudioBroadcastSourceSupported()، يعني ذلك أنّها:

• [C-8-1] يجب أن تتيح ربطَين على الأقل من ربطات BIS في BIG.
• [C-8-2] يجب تفعيل مصدر البث BAP ومساعد البث BAP بالتزامن.
• [C-8-3] يجب أن تتيح الإعلانات الدورية في التطبيقات المتوافقة مع الأجهزة الجوّالة.

إذا كانت عمليات تنفيذ الأجهزة تعرض true لواجهة برمجة التطبيقات BluetoothAdapter.isLeAudioBroadcastAssistantSupported()، يعني ذلك أنّها:

• [C-9-1] يجب أن يكون متوافقًا مع PAST (نقل المزامنة الإعلانية الدورية).
• [C-9-2] يجب أن تتيح الإعلانات الدورية في التطبيقات المتوافقة مع الأجهزة المنخفضة الطاقة.

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

• [C-10-1] يجب أن تكون قياسات RSSI ضمن +/-9dB لنسبة% 95 من القياسات على مسافة 1 متر من جهاز مرجعي يُرسِل عند ADVERTISE_TX_POWER_HIGH في بيئة مرئية.

• [C-10-2] يجب أن تتضمّن تصحيحات Rx/Tx لتقليل الانحرافات لكل قناة كي تكون القياسات في كل قناة من القنوات الثلاث، وفي كل هوائي (في حال استخدام هوائيات متعددة)، ضمن نطاق ±3 ديسيبل من بعضها البعض بنسبة% 95 من القياسات.

• [C-SR-2] يُنصح بشدة بقياس ومعالجة انحراف Rx لضمان أن يكون متوسّط RSSI لتقنية BLE هو -60dBm +/-10 dB على مسافة 1 متر من جهاز مرجعي يُرسِل على ADVERTISE_TX_POWER_HIGH، حيث تكون الأجهزة موجَّهة بحيث تكون على "مستويات متوازية" مع الشاشات التي تواجه الاتجاه نفسه.

• [C-SR-3] يُنصح بشدة بقياس إزاحة الإرسال وتعويضها لضمان أن يكون متوسّط مؤشر RSSI لتقنية BLE هو -60 ديسيبل +/-10 ديسيبل عند البحث من جهاز مرجعي يبعد مسافة متر واحد ويُرسِل على ADVERTISE_TX_POWER_HIGH، حيث يتم توجيه الأجهزة بحيث تكون على "مستويات متوازية" مع الشاشات التي تواجه الاتجاه نفسه.

  تم نقل المتطلبَين [C-10-3] و[C-10-4] إلى 2.2.1. الأجهزة:

• [C-10-3] يجب قياس إزاحة Rx وتعويضها لضمان أن يكون متوسّط RSSI لبروتوكول BLE هو -55 ديسي بل +/-10 ديسي بل على مسافة 1 متر من جهاز مرجعي يُرسِل بمعدل ADVERTISE_TX_POWER_HIGH.
• [C-10-4] يجب قياس إزاحة الإرسال وتعويضها لضمان أن يكون متوسّط مؤشر RSSI لتقنية BLE هو -55 ديسي بل +/-10 ديسي بل عند البحث من جهاز مرجعي يبعد مسافة متر واحد ويُرسِل إشارة بمدى ADVERTISE_TX_POWER_HIGH.

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

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

• [C-SR-4] يُنصح بشدة بتوفير الدعم لما يلي:
  • LE 2M PHY
  • LE Codec PHY
  • إضافة الإعلانات على الأجهزة الجوّالة
  • الإعلانات الدورية
  • 10 مجموعات إعلانية على الأقل
  • ‫8 اتصالات متزامنة على الأقل من خلال بروتوكول LE يمكن أن يكون كلّ اتصال في أحد أدوار طوبولوجيا الربط.
  • خصوصية طبقة رابط LE
  • حجم "قائمة الترجمة" لا يقل عن 8 إدخالات

7.4.4. تقنية الاتصال القصير المدى

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

• يجب أن يتضمّن جهاز إرسال واستقبال والأجهزة ذات الصلة للاتصال القصير المدى (NFC).
• [C-0-1] يجب تنفيذ واجهات برمجة التطبيقات android.nfc.NdefMessage و android.nfc.NdefRecord حتى إذا لم تتضمّن إتاحة استخدام NFC أو إعلان ميزة android.hardware.nfc لأنّ الفئات تمثّل تنسيقًا لتمثيل البيانات لا يعتمد على البروتوكول.

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

• [C-1-1] يجب الإبلاغ عن الميزة android.hardware.nfc من خلال طريقة android.content.pm.PackageManager.hasSystemFeature().
• يجب أن يكون الجهاز قادرًا على قراءة رسائل NDEF وكتابتها من خلال معايير NFC التالية كما هو موضّح أدناه:
• [C-1-2] يجب أن يكون الجهاز قادرًا على العمل كقارئ/كاتب في NFC 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.4.9. النطاق الفائق العرض (UWB)

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

• [C-1-1] يجب تنفيذ واجهة برمجة تطبيقات Android المقابلة في android.uwb.
• [C-1-2] يجب الإبلاغ عن علامة ميزة الجهاز android.hardware.uwb.
• [C-1-3] يجب أن يكون متوافقًا مع جميع الملفات الشخصية ذات الصلة للنطاق الفائق العرض (UWB) المحدّدة في عملية تنفيذ Android.
• [C-1-4] يجب توفير عنصر تحكم للمستخدم للسماح له بتفعيل/إيقاف تكنولوجيا UWB الراديو.
• [C-1-5] يجب فرض أن تحصل التطبيقات التي تستخدم راديو النطاق الفائق العرض (UWB) على إذن UWB_RANGING (ضمن مجموعة أذونات NEARBY_DEVICES).
• [C-SR-1] يُنصح بشدة باجتياز اختبارات الامتثال والاعتماد ذات الصلة التي تحدّدها المنظمات المسؤولة عن وضع المعايير، بما في ذلك FIRA وCCC وCSA.
• [C-1-6] يجب التأكّد من أنّ قياسات المسافة تقع ضمن نطاق ±15 سم لنسبة %95 من القياسات في بيئة خط الرؤية على مسافة 1 متر في غرفة غير عاكسة.
• [C-1-7] يجب التأكّد من أنّ متوسط قياسات المسافة عند 1 متر من الجهاز المرجعي يقع ضمن [0.75 متر، 1.25 متر]، حيث يتم قياس المسافة من الحافة العلوية لجهاز DUT الذي يتم تثبيته مع توجيه الشاشة للأعلى وإمالته بزاوية 45 درجة.
• [C-SR-2] يُنصح بشدة باتّباع خطوات إعداد القياس المحدّدة في متطلبات معايرة بيانات الحضور.

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.

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

• [C-2-1] يجب أن يكون متوافقًا مع الملف الشخصي HLG HDR على الأقل لكل جهاز كاميرا يتوافق مع إخراج 10 بت.
• [C-2-2] يجب أن تتيح الكاميرا الخلفية الأساسية أو الكاميرا الأمامية الأساسية إخراج 10 بت.
• [C-SR-1] يُنصح بشدة بتوفّر إخراج بدقة 10 بت لكل من الكاميرات الأساسية.
• [C-2-3] يجب أن تتيح الكاميرا الملفات الشخصية نفسها لميزة "النطاق العالي الديناميكية" لكل الكاميرات الفرعية المتوافقة مع الإصدارات القديمة من الكاميرا المنطقية، وكذلك للكاميرا المنطقية نفسها.

بالنسبة إلى أجهزة الكاميرا المنطقية التي تتوافق مع تقنية 10 بت بنطاق عالي الديناميكية وتنفِّذ واجهة برمجة التطبيقات android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO، يجب استيفاء الشروط التالية:

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

7.5.1. الكاميرا الخلفية

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

بدء متطلبات جديدة

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

إنهاء المتطلبات الجديدة

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

• يجب أن تتضمّن كاميرا خلفية.

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

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

إذا كانت الكاميرا تتضمّن فلاشًا:

• [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. الكاميرا الخارجية

بدء متطلبات جديدة

الكاميرا الخارجية هي كاميرا يمكن تركيبها أو فصلها عن التنفيذ في الجهاز في أي وقت ويمكن توجيهها في أي اتجاه، مثل كاميرات USB.

إنهاء المتطلبات الجديدة

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

• قد تتضمّن إتاحة استخدام كاميرا خارجية ليست متصلة دائمًا بالضرورة.

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

• [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 عند تسجيل فيديو جديد بواسطة الكاميرا وإضافة إدخال picture إلى "متجر الوسائط".
• [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 من النوع 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 Type-C لموصّلات USB Type-C أو استخدام نطاق تيار الإخراج لمنفذ الشحن (CDP) كما هو موضّح في الإصدار 1.2 من مواصفات شحن البطارية عبر USB لموصّلات 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). بالنسبة إلى منافذ Dual Role Ports (منافذ ذات دورَين)، على الأجهزة التي تتضمّن مقبس صوت مقاس 3.5 ملم، قد يكون رصد مقبس USB (وضع المضيف) مفعَّلاً تلقائيًا، ولكن يجب أن يكون بإمكان العميل تفعيله.
• [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. إنّ إتاحة إخراج الصوت عبر بروتوكولات تستند إلى البث اللاسلكي، مثل البلوتوث أو Wi-Fi أو شبكة الجوّال، لا تُعدّ مؤهّلة لتضمين "منفذ إخراج".

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. منافذ الصوت الرقمي

راجِع القسم 2.2.1 لمعرفة المتطلبات الخاصة بالأجهزة.

7.8.3. الموجات فوق الصوتية القريبة

يتراوح نطاق الصوت بالقرب من الموجات فوق الصوتية بين 18.5 كيلوهرتز و20 كيلوهرتز.

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

• يجب الإبلاغ بشكل صحيح عن توفُّر ميزة الصوت بالقرب من الموجات فوق الصوتية من خلال واجهة برمجة التطبيقات AudioManager.getProperty على النحو التالي:

إذا كانت قيمة PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND هي "صحيح"، يجب استيفاء المتطلبات التالية لمصادر الصوت VOICE_RECOGNITION وUNPROCESSED:

• [C-1-1] يجب ألا يقلّ متوسط استجابة الطاقة للميكروفون في النطاق من 18.5 كيلوهرتز إلى 20 كيلوهرتز عن 15 ديسيبل عن الاستجابة عند 2 كيلوهرتز.
• [C-1-2] يجب ألا تقل نسبة الإشارة إلى الضوضاء غير المحسوبة للميكروفون عن 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] يجب أن يكون متوافقًا مع البلوتوث 4.2 وإضافة طول البيانات في البلوتوث منخفض الطاقة (LE) الفقرة 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. أجهزة تعمل باللمس

بدء متطلبات جديدة

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

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

• [7.10/ج] يجب أن تعرِض الدالة قيمة false لـ Vibrator.hasVibrator().

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

• [C-1-1] يجب أن يعرض القيمة "صحيح" لـ Vibrator.hasVibrator().
• يجب عدم استخدام محرّك لمسي (مُحرِّك اهتزازي) للكتلة الدوّارة (ERM).
• يجب تنفيذ جميع الثوابت العامة لللمسات الواضحة في android.view.HapticFeedbackConstants أي (CLOCK_TICK وCONTEXT_CLICK وKEYBOARD_PRESS وKEYBOARD_RELEASE وKEYBOARD_TAP وLONG_PRESS وTEXT_HANDLE_MOVE وVIRTUAL_KEY وVIRTUAL_KEY_RELEASE وCONFIRM وREJECT وGESTURE_START و GESTURE_END).
• يجب تنفيذ جميع الثوابت العامة لللمسات الواضحة في android.os.VibrationEffect أي (EFFECT_TICK وEFFECT_CLICK وEFFECT_HEAVY_CLICK و EFFECT_DOUBLE_CLICK) وجميع الثوابت العامة PRIMITIVE_* الممكنة لللمسات الغنية في android.os.VibrationEffect.Composition أي (CLICK وTICK وLOW_TICK وQUICK_FALL وQUICK_RISE SLOW_RISE وSPIN وTHUD). قد لا تكون بعض هذه العناصر الأساسية، مثل LOW_TICK وSPIN، ممكنة إلا إذا كان الهزّاز قادرًا على التعامل مع ترددات قليلة نسبيًا.
• يجب اتّباع إرشادات ربط الثوابت العامة في android.view.HapticFeedbackConstants بثوابت android.os.VibrationEffect المقترَحة، مع العلاقات المقابلة للسعة.
• يجب استخدام عمليات ربط هذه العناصر الثابتة المرتبطة باللمس.
• يجب اتّباع تقييم الجودة لواجهتَي برمجة التطبيقات createOneShot() وcreateWaveform().
• يجب التحقّق من أنّ نتيجة واجهة برمجة التطبيقات العامة android.os.Vibrator.hasAmplitudeControl() تعكس إمكانات الهزّاز بشكل صحيح.
• يجب التحقّق من إمكانات زيادة نطاق عمل Amplitude من خلال تشغيل android.os.Vibrator.hasAmplitudeControl().

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

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

إنهاء المتطلبات الجديدة

راجِع القسم 2.2.1 لمعرفة المتطلبات الخاصة بالأجهزة.

7.11. فئة أداء الوسائط

يمكن الحصول على فئة أداء الوسائط لتنفيذ الجهاز من واجهة برمجة التطبيقات android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS. يتم تحديد متطلبات فئة أداء الوسائط لكل إصدار من Android بدءًا من R (الإصدار 30). تشير القيمة الخاصة 0 إلى أنّ الجهاز ليس من فئة أداء الوسائط.

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

• [C-1-1] يجب أن تعرِض قيمة android.os.Build.VERSION_CODES.R على الأقل.

• [C-1-2] يجب أن يكون التنفيذ على جهاز محمول باليد.

• [C-1-3] يجب استيفاء جميع متطلبات "فئة أداء الوسائط" الموضّحة في الفقرة 2.2.7.

بعبارة أخرى، لا يتم تحديد فئة أداء الوسائط في Android T إلا ل الأجهزة الجوّالة التي تعمل بالإصدار T أو S أو R.

اطّلِع على الفقرة 2.2.7 للاطّلاع على المتطلّبات المتعلّقة بالأجهزة.

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

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

8.1. اتساق تجربة المستخدم

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

8.2. أداء الوصول إلى الإدخال/الإخراج من الملفات

من خلال توفير مرجع قياسي شائع لأداء الوصول إلى الملفات بشكلٍ متسق على مساحة تخزين البيانات الخاصة بالتطبيق (قسم /data)، يمكن لمطوّري التطبيقات وضع توقّعات مناسبة تساعدهم في تصميم برامجهم. قد تفرض عمليات تنفيذ التطبيقات على الأجهزة، استنادًا إلى نوع الجهاز، متطلبات معيّنة описанة في القسم 2 لعمليات القراءة والكتابة التالية:

• أداء الكتابة التسلسلية: يتم قياسها من خلال كتابة ملف بحجم 256 ميغابايت باستخدام ملف تدوين كتابة بحجم 10 ميغابايت.
• أداء الكتابة العشوائية يتم قياسها من خلال كتابة ملف بحجم 256 ميغابايت باستخدام ذاكرة تخزين مؤقت للكتابة بسعة 4 كيلوبايت.
• أداء القراءة التسلسلية: تم قياس السرعة من خلال قراءة ملف بحجم 256 ميغابايت باستخدام ملف تدوين كتابة بحجم 10 ميغابايت.
• أداء القراءة العشوائية يتم قياسه من خلال قراءة ملف بحجم 256 ميغابايت باستخدام ذاكرة تخزين مؤقت للكتابة بسعة 4 كيلوبايت.

8.3. أوضاع توفير الطاقة

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

• [C-1-1] يجب عدم الانحراف عن تنفيذ AOSP لبدء تطبيقات وضع "الاستعداد" وDeviceConfig ووضع "الاستراحة الذكية" وخوارزمية الاحتفاظ بالطاقة واستخدام إعدادات النظام الشاملة.
• [C-1-2] يجب عدم الانحراف عن تنفيذ AOSP لاستخدام الإعدادات العموية أو DeviceConfig لإدارة الحدّ من عدد المهام وعمليات التنبيه و الشبكة للتطبيقات في كل مجموعة للوضع "الاستعداد للتطبيقات".
• [C-1-3] يجب عدم الانحراف عن طريقة تنفيذ AOSP لعدد مجموعات "وضع الاستعداد للتطبيقات" المستخدَمة في "وضع الاستعداد للتطبيقات".
• [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 Open Source Project.
• [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 إلا للتطبيقات المثبَّتة مسبقًا في المسارات المميّزة بامتيازات خاصة في صورة النظام (بالإضافة إلى ملفات APEX) ويجب أن تكون ضمن المجموعة الفرعية من الأذونات المدرَجة في القائمة المسموح بها لكل تطبيق. يستوفي تطبيق AOSP هذا الشرط من خلال قراءة الأذونات المدرَجة في القائمة المسموح بها لكل تطبيق من الملفات في مسار etc/permissions/ واستخدام مسار system/priv-app كمسار مميّز بامتيازات خاصة.

إنّ الأذونات التي يكون مستوى حمايتها خطيرًا هي أذونات وقت التشغيل. تطلب التطبيقات التي تحتوي على targetSdkVersion > 22 هذه الأذونات أثناء التشغيل.

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

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

• [C-0-4] يجب أن يكون هناك تنفيذ واحد فقط لكلتا جهتي واجهة العميل.

• [C-0-5] يجب عدم منح أي أذونات وقت تشغيل للتطبيقات إلا في الحالات التالية:

  • يتم تثبيتها في وقت شحن الجهاز،

  • يمكن الحصول على موافقة المستخدم قبل أن يستخدم التطبيق الإذن.

    أو

  • يتم منح أذونات وقت التشغيل بموجب سياسة منح الأذونات التلقائية أو لشغل دور على المنصة.

• [C-0-6] يجب منح الإذن android.permission.RECOVER_KEYSTORE فقط لتطبيقات النظام التي تسجِّل وكيل استرداد آمنًا بشكلٍ صحيح. يتم تعريف وكيل الاسترداد الآمن على أنّه وكيل برامج على الجهاز تتم مزامنته مع مساحة تخزين عن بُعد خارج الجهاز ومزوّدة بأجهزة آمنة توفّر حماية مماثلة أو أقوى مما هو описан في خدمة Google Cloud Key Vault لمنع هجمات القوة الغاشمة على عامل المعلومات في شاشة القفل.

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

• [C-0-7] يجب الالتزام بخصائص إذن الوصول إلى الموقع الجغرافي في Android عندما يطلب التطبيق بيانات الموقع الجغرافي أو النشاط البدني من خلال واجهة برمجة التطبيقات العادية لنظام التشغيل Android أو آلية خاصة. وتشمل هذه البيانات على سبيل المثال لا الحصر ما يلي:

  • الموقع الجغرافي للجهاز (مثل خط العرض وخط الطول) كما هو موضّح في الفقرة 9.8.8
  • المعلومات التي يمكن استخدامها لتحديد الموقع الجغرافي للجهاز أو تقديره (مثل معرّف شبكة WLAN أو معرّف مجموعة الخدمات الأساسية أو معرّف الخلية أو الموقع الجغرافي للشبكة التي يكون الجهاز متصلاً بها)
  • النشاط البدني للمستخدم أو تصنيف النشاط البدني

وعلى وجه التحديد، تؤدي عمليات تنفيذ الأجهزة إلى ما يلي:

• [C-0-8] يجب الحصول على موافقة المستخدم للسماح للتطبيق بالوصول إلى data الموقع الجغرافي أو النشاط البدني.
• [C-0-9] يجب منح إذن التشغيل للتطبيق الذي يملك إذنًا كافيًا كما هو موضّح في حزمة SDK فقط. على سبيل المثال، يحتاج الإجراء TelephonyManager#getServiceState إلى android.permission.ACCESS_FINE_LOCATION).

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

• عندما تحصل التطبيقات على إذن RADIO_SCAN_WITHOUT_LOCATION
• لأغراض ضبط الجهاز وإعداده، حيث تمتلك تطبيقات النظام إذن NETWORK_SETTINGS أو NETWORK_SETUP_WIZARD

يمكن وضع علامة على الأذونات على أنّها محظورة، ما يؤدي إلى تغيير سلوكها.

• [C-0-10] يجب عدم منح الأذونات التي تم وضع العلامة hardRestricted عليها لأي تطبيق ما لم يكن:

  • ملف APK للتطبيق في قسم النظام
  • يمنح المستخدم دورًا مرتبطًا بأذونات hardRestricted لتطبيق معيّن.
  • يمنح برنامج التثبيت إذن hardRestricted لتطبيق معيّن.
  • تم منح أحد التطبيقات إذن hardRestricted على إصدار سابق من Android.

• [C-0-11] يجب أن تحصل التطبيقات التي تمتلك إذن softRestricted على إذن بالوصول محدود فقط، ويجب ألا تحصل على إذن بالوصول الكامل إلى أن يتم إدراجها في القائمة المسموح بها كما هو موضّح في مستندات حزمة تطوير البرامج (SDK)، حيث يتم تحديد إذن الوصول الكامل والمحدود لكل إذن softRestricted (على سبيل المثال، READ_EXTERNAL_STORAGE).

• [C-0-12] يجب عدم توفير أي دوال أو واجهات برمجة تطبيقات مخصّصة لتجاوز قيود الأذونات المحدّدة في واجهات برمجة التطبيقات setPermissionPolicy وsetPermissionGrantState.

• [C-0-13] يجب استخدام واجهات برمجة تطبيقات AppOpsManager لتسجيل وتتبُّع كل عملية وصول آلي إلى البيانات المحمية بأذونات خطيرة من أنشطة Android وخدماته.

• [C-0-14] يجب منح الأدوار للتطبيقات التي تتضمّن وظائف تفي بمتطلبات الدور فقط.

• [C-0-15] يجب عدم تحديد أدوار مكرّرة أو وظائف فائقة للأدوار التي حدّدها النظام الأساسي.

إذا أبلغت الأجهزة عن 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 ميزة التقاط المحتوى" "9.8.6 البيانات على مستوى نظام التشغيل والبيانات المحيطة و9.8.15 عمليات تنفيذ واجهات برمجة التطبيقات في وضع الحماية".

• [C-4-2] يجب ألّا يكون لدى التطبيق إذن android.permission.INTERNET. وهذا الإجراء أكثر صرامة من الإجراء "يُنصح به بشدة" المُدرَج في القسم 9.8.6.
• [C-4-3] يجب عدم الربط بتطبيقات أخرى، باستثناء تطبيقات النظام التالية: البلوتوث و"جهات الاتصال" و"الوسائط" و"الهاتف" وSystemUI والمكونات التي توفّر واجهات برمجة التطبيقات الخاصة بالإنترنت. وهذا أكثر صرامة من الإجراء "يُنصح به بشدة" المُدرَج في الفقرة 9.8.6.

بدء متطلبات جديدة

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

• [C-5-1] يجب عدم منح ACCESS_FINE_LOCATION كقيمة تلقائية لذلك التطبيق.

إنهاء المتطلبات الجديدة

9.2. رقم تعريف المستخدم وعملية العزل

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

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

بدء متطلبات جديدة

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

• [C-4-5] يجب التمييز بصريًا بين رموز التطبيقات المزوّدة بمثيلَين عند عرض الرموز للمستخدمين.
• [C-4-6] يجب توفير ميزة للمستخدم لحذف بيانات الملف الشخصي المُكرّر بالكامل.
• [C-4-7] يجب إلغاء تثبيت جميع التطبيقات المكرّرة وحذف ملفات تعريف بيانات التطبيقات الخاصة والملفات ومحتوى الملفات وبيانات الملف الشخصي المكرّر، عندما يختار المستخدِم حذف بيانات الملف الشخصي المكرّر بالكامل.
• يجب أن يطلب من المستخدم حذف بيانات الملف التجاري المُكرّر بالكامل عند حذف التطبيق المُكرّر الأخير.
• [C-4-8] يجب إبلاغ المستخدم بأنّه سيتم حذف بيانات التطبيق عند إلغاء تثبيت التطبيق المكرّر، أو توفير خيار للمستخدمين للاحتفاظ ببيانات التطبيق عند إلغاء تثبيت التطبيق من الجهاز.
• [C-4-9] يجب حذف أدلة بيانات التطبيقات الخاصة ومحتوى تلك الأدلة عندما يختار المستخدم حذف البيانات أثناء إلغاء التثبيت.

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

  • Intent.ACTION_VIEW
  • Intent.ACTION_SENDTO
  • Intent.ACTION_SEND
  • Intent.ACTION_EDIT
  • Intent.ACTION_INSERT
  • Intent.ACTION_INSERT_OR_EDIT
  • Intent.ACTION_SEND_MULTIPLE
  • Intent.ACTION_PICK
  • Intent.ACTION_GET_CONTENT
  • MediaStore.ACTION_IMAGE_CAPTURE
  • MediaStore.ACTION_VIDEO_CAPTURE

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

  • setScreenCaptureDisabled
  • setAccountManagementDisabled
  • setCameraDisabled
  • setPermittedInputMethods
  • setApplicationHidden
  • setPersonalAppsSuspended

• [C-4-3] يجب السماح فقط بكتابة جهات الاتصال من هذا الملف الشخصي الإضافي من خلال المقصودَين التاليَين:

  • ContactsContract.Intents.Insert.ACTION
  • Intent.ACTION_PICK
  • Intent.ACTION_EDIT
  • Intent.ACTION_INSERT_OR_EDIT

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

• [C-4-14] يجب أن يكون هناك إذن منفصل وإدارة تخزين منفصلة للتطبيقات التي تعمل في هذا الملف الشخصي الإضافي.

• [C-4-5] يجب السماح للتطبيقات في الملف الشخصي الإضافي التي تحتوي على نشاط مشغِّل فقط بالوصول إلى جهات الاتصال التي يمكن الوصول إليها منملف شخصي مستخدم أساسي.

إنهاء المتطلبات الجديدة

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] يجب تنفيذ عزل جدول صفحات kernel إذا كان الجهاز معرضًا للاختراق من خلال 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-9] يُنصح بشدة بعزل كل جهاز إدخال/إخراج مزوّد بإمكانية الوصول المباشر إلى الذاكرة (DMA)، باستخدام وحدة إدارة الذاكرة (IOMMU) (مثل ARM SMMU).

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

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

• [C-SR-10] يُنصح بشدة بإجراء الاختبار باستخدام أدوات رصد أخطاء ملف الذاكرة في مساحة المستخدم، مثل MTE لأجهزة ARMv9 أو HWASan لأجهزة ARMv8 والإصدارات الأحدث أو ASan لأنواع الأجهزة الأخرى.
• [C-SR-11] يُنصح بشدة باختبارها باستخدام أدوات رصد أخطاء ذاكرة kernel مثل KASAN (CONFIG_KASAN أو CONFIG_KASAN_HW_TAGS لأجهزة ARMv9 أو CONFIG_KASAN_SW_TAGS لأجهزة ARMv8 أو CONFIG_KASAN_GENERIC لأنواع الأجهزة الأخرى).
• [C-SR-12] يُنصح بشدة باستخدام أدوات رصد أخطاء الذاكرة في مرحلة التطوير، مثل MTE وGWP-ASan وKFENCE.

إذا كانت عمليات تنفيذ الأجهزة تستخدم وحدة معالجة آمنة (TEE) مستندة إلى Arm TrustZone، فإنّها:

• [C-SR-13] يُنصح بشدة باستخدام بروتوكول عادي لمشاركة الذاكرة بين Android ووحدة TEE، مثل Arm Firmware Framework لمعالج Armv8-A (FF-A).
• [C-SR-14] يُنصح بشدة بحصر إمكانية وصول التطبيقات الموثوق بها إلى الذاكرة التي تمت مشاركتها معها صراحةً من خلال الخطوات المذكورة أعلاه. إذا كان الجهاز متوافقًا مع مستوى استثناء Arm S-EL2، يجب أن يفرض مدير الأقسام الآمنة هذا الإجراء. وبخلاف ذلك، يجب أن يتم فرض ذلك من خلال نظام التشغيل TEE.

بدء متطلبات جديدة

تكنولوجيا أمان الذاكرة هي تكنولوجيا تقلّل على الأقل من فئات الأخطاء التالية بدرجة عالية (> %90) في التطبيقات التي تستخدم خيار البيان android:memtagMode:

• فائض سعة مخزن مؤقت للمساحة الفارغة
• الاستخدام بعد انتهاء الفترة المجانية
• double free
• ذاكرة عشوائية متاحة (غير متاحة لمؤشر غير malloc)

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

• [C-SR-15] يُنصح بشدة بضبط ro.arm64.memtag.bootctl_supported.

إذا ضبطت عمليات تنفيذ الأجهزة سمة النظام ro.arm64.memtag.bootctl_supported على true، فإنّها:

• [C-3-1] يجب السماح لسمة النظام arm64.memtag.bootctl بقبول قائمة مفصولة بفواصل للقيم التالية، مع تطبيق التأثير المطلوب عند إعادة التشغيل التالية:

  • memtag: تم تفعيل تكنولوجيا أمان الذاكرة كما هو محدّد أعلاه
  • memtag-once: يتم تفعيل تكنولوجيا أمان الذاكرة كما هو محدّد أعلاه بشكل مؤقت، ويتم إيقافها تلقائيًا عند إعادة التشغيل التالية.
  • memtag-off: تم إيقاف تكنولوجيا أمان الذاكرة على النحو المحدّد أعلاه

• [C-3-2] يجب السماح لمستخدم shell بضبط arm64.memtag.bootctl.

• [C-3-3] يجب السماح لأي عملية بقراءة arm64.memtag.bootctl.

• [C-3-4] يجب ضبط arm64.memtag.bootctl على الحالة المطلوبة حاليًا عند التشغيل، ويجب أيضًا تعديل السمة، إذا كان تنفيذ الجهاز يسمح بتعديل الحالة بدون تغيير سمة النظام.

• [C-SR-16] يُنصح بشدة بعرض إعدادات المطوّر التي تضبط memtag-once وتعيد تشغيل الجهاز. من خلال أداة تحميل البرامج الثابتة المتوافقة، يستوفي مشروع Android Open Source Project المتطلبات المذكورة أعلاه من خلال بروتوكول أداة تحميل البرامج الثابتة MTE.

• [C-SR-17] يُنصح بشدة بعرض إعداد في قائمة "إعدادات الأمان" يتيح للمستخدم تفعيل memtag.

إنهاء المتطلبات الجديدة

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] يجب عرض تحذير للمستخدم والحصول على موافقة صريحة من المستخدم للسماح بتسجيل أي معلومات حسّاسة معروضة على شاشة المستخدم، ويجب أن تتضمّن الموافقة بالضبط الرسالة نفسها الواردة في AOSP في كل مرة يتم فيها تفعيل بدء جلسة لتسجيل الشاشة أو بث الشاشة عبر MediaProjection.createVirtualDisplay() أو VirtualDeviceManager.createVirtualDisplay() أو واجهات برمجة التطبيقات المملوكة. يجب عدم منح المستخدمين إمكانية إيقاف عرض موافقة المستخدم في المستقبل.
• [C-0-3] يجب أن يتلقّى المستخدم إشعارًا مستمرًا أثناء بث الشاشة أو تفعيل تسجيل الشاشة. يستوفي AOSP هذا الشرط من خلال عرض رمز إعلام قيد التنفيذ في شريط الحالة.

بدء متطلبات جديدة

• [C-SR-1] يُنصح بشدة بعرض تحذير للمستخدم يتضمن الرسالة نفسها تمامًا التي تم تنفيذها في AOSP، ولكن يمكن تغييرها طالما أنّ الرسالة تحذر المستخدم بوضوح من أنّه يتم تسجيل أي معلومات حساسة على شاشة المستخدم.

• [C-0-4] يجب عدم تزويد المستخدمين بإمكانية إيقاف الطلبات المستقبلية لمنحهم الموافقة على تسجيل الشاشة، ما لم يتم بدء الجلسة من خلال تطبيق نظام سمح له المستخدم بالتسجيلassociate() باستخدام android.app.role.COMPANION_DEVICE_APP_STREAMING أوملف تعريف android.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING الجهاز.

  إنهاء المتطلبات الجديدة

إذا كانت عمليات تنفيذ الأجهزة تتضمّن وظائف في النظام تؤدي إلى التقاط المحتوى المعروض على الشاشة و/أو تسجيل البث الصوتي الذي يتم تشغيله على الجهاز بخلاف استخدام 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 من خلال واجهات برمجة تطبيقات النظام ContentCaptureService AugmentedAutofillService أو AppSearchGlobalManager.query أو بوسائل أخرى مملوكة آلية لعمليات التنفيذ على الأجهزة من أجل تسجيل التفاعلات مع بيانات التطبيقات بين التطبيقات والمستخدم البيانات الحسّاسة التالية:

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

بدء متطلبات جديدة

• أي شاشة أو بيانات أخرى يتم إرسالها عبر AugmentedAutofillService إلى النظام
• أي شاشة أو بيانات أخرى يمكن الوصول إليها من خلال Content Capture واجهة برمجة التطبيقات
• أي شاشة أو بيانات أخرى يمكن الوصول إليها من خلال واجهة برمجة التطبيقات FieldClassificationService
• أي بيانات تطبيق تم تمريرها إلى النظام من خلال واجهة برمجة التطبيقات AppSearchManager والتي يمكن الوصول إليها من خلال AppSearchGlobalManager.query

إنهاء المتطلبات الجديدة

• أي أحداث أخرى يوفّرها التطبيق للنظام من خلال واجهة برمجة التطبيقات Content Capture أو واجهة برمجة التطبيقات AppSearchManager أو واجهة برمجة تطبيقات خاصة تابعة لشركة Android و ذات قدرات مماثلة

• أي نص أو بيانات أخرى يتم إرسالها عبر TextClassifier API إلى System TextClassifier، أي خدمة النظام لفهم معنى النص، بالإضافة إلى إنشاء الإجراءات التالية المتوقّعة استنادًا إلى النص
• البيانات التي يتم فهرستها من خلال تنفيذ AppSearch على المنصة، بما في ذلك على سبيل المثال لا الحصر، النصوص أو الرسومات أو بيانات الوسائط أو البيانات الأخرى المشابهة

بدء متطلبات جديدة

• البيانات الصوتية التي تم الحصول عليها نتيجة استخدام SpeechRecognizer#onDeviceSpeechRecognizer() من خلال تنفيذ تكنولوجيا التعرّف على الكلام
• بيانات الصوت التي يتم الحصول عليها في الخلفية (بشكل مستمر) من خلال AudioRecord أو SoundTrigger أو واجهات برمجة تطبيقات أخرى للصوت، والتي لا تؤدي إلى ظهور إشارة ملفتة للمستخدم
• بيانات الكاميرا التي يتم الحصول عليها في الخلفية (بشكل مستمر) من خلال CameraManager أو واجهات برمجة التطبيقات الأخرى الخاصة بالكاميرا، والتي لا تؤدي إلى ظهور مؤشر يراه المستخدم

إنهاء المتطلبات الجديدة

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

• [C-1-1] يجب تشفير جميع هذه البيانات عند تخزينها في الجهاز. قد يتم تنفيذ هذا التشفير باستخدام ميزة "التشفير المستنِد إلى الملفات" في Android أو أي من التشفيرات المُدرَجة في الإصدار 26 من واجهة برمجة التطبيقات أو الإصدارات الأحدث الموضّحة في حزمة تطوير البرامج (SDK) لتشفير البيانات.
• [C-1-2] يجب عدم الاحتفاظ بنسخة احتياطية من البيانات الأولية أو المشفَّرة باستخدام طرق الاحتفاظ بنسخة احتياطية من بيانات Android أو أي طرق أخرى للاحتفاظ بنسخة احتياطية.
• [C-1-3] يجب عدم إرسال جميع هذه البيانات والسجلّ خارج الجهاز إلا باستخدام آلية للحفاظ على الخصوصية، إلا بعد الحصول على موافقة صريحة من المستخدم في كل مرة تتم فيها مشاركة البيانات. يتم تعريف آلية الحفاظ على الخصوصية على أنّها "تلك التي لا تسمح إلا بالتحليل بشكل مجمّع وتمنع مطابقة الأحداث المسجّلة أو النتائج المستمدة للمستخدمين الفرديين"، وذلك لمنع إمكانية فحص أي بيانات خاصة بالمستخدم (على سبيل المثال، يتم تنفيذها باستخدام تكنولوجيا الخصوصية التفاضلية مثل RAPPOR).
• [C-1-4] يجب عدم ربط هذه البيانات بأي هوية مستخدم (مثل Account) على الجهاز، إلا بعد الحصول على موافقة صريحة من المستخدم في كل مرة يتم فيها ربط البيانات.
• [C-1-5] يجب عدم مشاركة هذه البيانات مع مكوّنات نظام التشغيل الأخرى التي لا تلتزم بالمتطلبات الموضّحة في القسم الحالي (9.8.6 التقاط المحتوى بيانات مستوى نظام التشغيل والبيانات المحيطة)، إلا بعد الحصول على موافقة صريحة من المستخدم في كل مرة تتم فيها مشاركتها. ما لم يتم إنشاء هذه الوظيفة كواجهة برمجة تطبيقات لـ Android SDK (AmbientContext، HotwordDetectionService).
• [C-1-6] يجب أن توفّر للمستخدم إمكانية محو هذه البيانات التي جمعها ContentCaptureService تنفيذ التطبيق أو الوسائل المملوكة إذا عند تخزين البيانات بأي شكل على الجهاز. إذا اختار العميل محو البيانات، يجب إزالة جميع البيانات السابقة التي تم جمعها.
• [C-1-7] يجب أن يقدّم التطبيق للمستخدم ميزة لإيقاف عرض البيانات التي يتم جمعها من خلال AppSearch أو وسائل خاصة في نظام التشغيل Android ، مثل مشغّل التطبيقات.
• [C-SR-1] يُنصح بشدة بعدم طلب إذن الوصول إلى الإنترنت.
• [C-SR-2] يُنصح بشدة بالوصول إلى الإنترنت فقط من خلال واجهات برمجة التطبيقات منظَّمة التي تستند إلى عمليات تنفيذ مفتوحة المصدر متاحة للجميع.

بدء متطلبات جديدة

• [C-SR-4] يُنصح بشدة بتنفيذها باستخدام واجهة برمجة التطبيقات Android SDK API أو مستودع مفتوح المصدر مشابه مملوك من المصنّع الأصلي للجهاز، و / أو تنفيذها في بيئة محاكاة (راجِع 9.8.15 عمليات تنفيذ واجهة برمجة التطبيقات في بيئة محاكاة).

إنهاء المتطلبات الجديدة

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

• [C-0-2] يجب محو بيانات الحافظة بعد 60 دقيقة على الأكثر من وضعها في الحافظة أو قراءتها منها.

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 لحزمة المتصل (إذا كان مرتبطًا)
  • ذاكرة التخزين المؤقت لسجلّ الراديو
  • SubscriptionManagerService dump
• [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.8.14. مدير بيانات الاعتماد

تمّت إزالة الموضوع.

9.8.15. عمليات تنفيذ واجهة برمجة التطبيقات في وضع الحماية

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

أيّ عملية تنفيذ لواجهة برمجة التطبيقات في وضع الحماية:

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

9.8.16. بيانات الصوت والكاميرا المستمرة

بالإضافة إلى المتطلبات الموضّحة في 9.8.2 التسجيل و9.8.6 البيانات على مستوى نظام التشغيل والبيانات المحيطة و9.8.15 عمليات تنفيذ واجهات برمجة التطبيقات في وضع الحماية، فإنّ عمليات التنفيذ التي تستخدِم بيانات الصوت التي يتم الحصول عليها في الخلفية (بشكل مستمر) من خلال AudioRecord أو SoundTrigger أو واجهات برمجة تطبيقات الصوت الأخرى أو بيانات الكاميرا التي يتم الحصول عليها في الخلفية (بشكل مستمر) من خلال CameraManager أو واجهات برمجة تطبيقات الكاميرا الأخرى:

• [C-0-1] يجب فرض مؤشر ملائم (للكاميرا و/أو الميكروفون كما هو موضّح في القسم 9.8.2 التسجيل)، ما لم يكن:
  • يتم تنفيذ هذا الوصول في عملية تنفيذ في مساحة مغلقة (راجِع 9.8.15 تنفيذ واجهة برمجة التطبيقات في مساحة مغلقة)، من خلال حزمة تحتوي على دور واحد أو أكثر من الأدوار التالية: System UI Intelligence، System Ambient Audio Intelligence، System Audio Intelligence، System Notification Intelligence، System Text Intelligence، أو System Visual Intelligence.
  • يتم الوصول من خلال بيئة محاكاة يتم تنفيذها وفرضها من خلال آليات في AOSP (HotwordDetectionService، WearableSensingService، VisualQueryDetector).
  • يُجري تطبيق "مساعد Google" عملية الوصول إلى الصوت لأغراض مساعدة، ما يقدّم SOURCE_HOTWORD كمصدر صوت.
  • ينفّذ النظام عملية الوصول وينفّذها باستخدام رمز برمجي مفتوح المصدر.
• [C-SR-1] يُنصح بشدة بطلب موافقة المستخدم لكل ميزة تستخدم هذه البيانات، ويجب أن تكون هذه الميزة غير مفعّلة تلقائيًا.
• [C-SR-2] يُنصح بشدة بتطبيق المعالجة نفسها (أي اتّباع القيود الموضّحة في 9.8.2 التسجيل و9.8.6 البيانات على مستوى نظام التشغيل والبيانات المحيطة و9.8.15 عمليات تنفيذ واجهة برمجة التطبيقات في وضع الحماية و9.8.16 بيانات الصوت والكاميرا المتواصلة) على بيانات الكاميرا الواردة من جهاز قابل للارتداء عن بُعد.

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

• [C-1-1] يجب أن يشير إلى الجهاز البعيد القابل للارتداء ل عرض مؤشر إضافي هناك.

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

• [C-2-1] يجب التأكّد من أنّ هذا التنفيذ مقدَّم من حزمة تحمل دور android.app.role.ASSISTANT.
• [C-2-2] يجب التأكّد من أنّ هذا التنفيذ يستخدِم HotwordDetectionService و/أو VisualQueryDetectionService واجهات برمجة تطبيقات Android.

9.8.17. Telemetry

يخزِّن Android سجلات النظام والتطبيقات باستخدام واجهات برمجة التطبيقات StatsLog. تتم إدارة هذه السجلات من خلال واجهات برمجة التطبيقات StatsManager التي يمكن أن تستخدمها تطبيقات النظام المزوّدة بأذونات مميّزة.

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

أيّ عملية تنفيذ تطلب المقاييس المحظورة وتجمعها من StatsManager:

• [C-0-1] يجب أن يكون التطبيق/التطبيق الوحيد على الجهاز وأن يمتلك إذن READ_RESTRICTED_STATS.
• [C-0-2] يجب إرسال بيانات القياس وسجلّ الجهاز فقط باستخدام آلية الحفاظ على الخصوصية. يتم تعريف آلية الحفاظ على الخصوصية على أنّها "تلك التي تسمح بالتحليل بشكل مجمّع فقط وتمنع مطابقة الأحداث المسجّلة أو النتائج المستمدة مع المستخدمين الفرديين"، لمنع إمكانية فحص أي بيانات فردية للمستخدمين (على سبيل المثال، يتم تنفيذها باستخدام تكنولوجيا اختلاف الخصوصية مثل RAPPOR).
• [C-0-3] يجب عدم ربط هذه البيانات بأي هوية مستخدم (مثل الحساب) على الجهاز.
• [C-0-4] يجب عدم مشاركة هذه البيانات مع مكوّنات نظام التشغيل الأخرى التي لا تلتزم بالمتطلبات الموضّحة في القسم الحالي (9.8.17 ميزة التتبّع التي تحافظ على الخصوصية).
• [C-0-5] يجب أن توفّر ميزة للمستخدم لتفعيل/إيقاف جمع ومقايسة واستخدام ميزات التتبُّع التي تحافظ على الخصوصية.
• [C-0-6] يجب أن يقدّم التطبيق للمستخدم إمكانية محو هذه البيانات التي يجمعها التكامل إذا كانت البيانات مخزّنة بأي شكل على الجهاز. إذا اختَر العميل محو البيانات، يجب إزالة جميع البيانات المخزّنة حاليًا على الجهاز.
• [C-0-7] يجب الإفصاح عن تنفيذ البروتوكول الأساسي للحفاظ على الخصوصية في مستودع مفتوح المصدر.
• [C-0-8 ]يجب فرض سياسات نقل البيانات في هذا القسم لحظر جمع البيانات في فئات المقاييس المحظورة التي تم تحديدها في StatsLog.

إنهاء المتطلبات الجديدة

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

ملاحظة: يجب أن تستوفي عمليات تنفيذ الأجهزة التي تم شحنها بالإصدار 28 من واجهة برمجة التطبيقات أو إصدار أقدم والتي لا تستوفي المتطلبات الواردة في القسم 9.9.2 من خلال تحديث لنظام التشغيل المتطلبات الواردة في القسم 9.9 من مستند "تعريف التوافق مع Android" المتوافقة مع مستوى واجهة برمجة التطبيقات الذي تم شحنه على الجهاز.

9.9.3. طرق التشفير

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

• [C-1-1] يجب أن يتم تشغيل الجهاز بدون طلب بيانات الاعتماد من المستخدم ويجب أن يسمح للتطبيقات المتوافقة مع ميزة "التمهيد المباشر" بالوصول إلى مساحة التخزين المشفَّرة على الجهاز (DE) بعد بث رسالة ACTION_LOCKED_BOOT_COMPLETED.
• [C-1-2] يجب عدم السماح بالوصول إلى مساحة التخزين المشفَّرة للمستندات المُعتمَدة (CE) إلا بعد أن يفتح المستخدم قفل الجهاز من خلال تقديم مستندات اعتماده (مثل رمز المرور أو رقم التعريف الشخصي أو النمط أو بصمة الإصبع) ويتم بثACTION_USER_UNLOCKED الرسالة.
• [C-1-13] يجب ألّا يوفّر أي طريقة لفتح قفل مساحة التخزين المحمية بتقنية CE بدون بيانات الاعتماد المقدَّمة من المستخدم أو مفتاح وديعة مسجَّل أو تنفيذ استئناف التشغيل بعد إعادة التشغيل يستوفي المتطلبات الواردة في الفقرة 9.9.4.
• [C-1-4] يجب استخدام ميزة "التشغيل المتحقّق منه".

9.9.3.1. التشفير المستند إلى الملفات مع تشفير البيانات الوصفية

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

• [C-1-5] يجب تشفير محتوى الملفات والبيانات الوصفية لنظام الملفات باستخدام AES-256-XTS أو Adiantum. يشير معيار AES-256-XTS إلى معيار التشفير المتقدّم (AES) بطول مفتاح التشفير 256 بت، ويتم تشغيله في وضع XTS، ويبلغ الطول الكامل للمفتاح 512 بت. يشير Adiantum إلى Adiantum-XChaCha12-AES، كما هو محدّد في الرابط https://github.com/google/adiantum. البيانات الوصفية لنظام الملفات هي بيانات مثل أحجام الملفات وملكيتها وأوضاعها والسمات الموسّعة (xattrs).
• [C-1-6] يجب تشفير أسماء الملفات باستخدام AES-256-CBC-CTS أو AES-256-HCTR2 أو Adiantum.
• [C-1-12] إذا كان الجهاز يتضمّن تعليمات 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.

ملاحظة: بالنسبة إلى عمليات تنفيذ الأجهزة التي تم شحنها بالمستوى 28 من واجهة برمجة التطبيقات أو إصدار أقدم والتي لا تستوفي المتطلبات الواردة في القسم 9.9.3 من خلال تحديث لنظام التشغيل، يجب أن تستوفي المتطلبات الواردة في القسم 9.9 من مستند تعريف التوافق مع Android المتوافقة مع مستوى واجهة برمجة التطبيقات الذي تم شحن الجهاز به.

9.9.3.2. التشفير على مستوى الكتلة لكل مستخدم

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

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

• [C-1-4] يجب استخدام AES-256-XTS لتشفير أقسام ملف التمهيد على مستوى الكتل.

• المفاتيح التي تحمي الأجهزة المشفَّرة على مستوى الكتلة لكل مستخدم:

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

يمكن تنفيذ التشفير على مستوى الوحدات لكل مستخدم باستخدام ميزة "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-2-1] تتيح التحقّق من محتوى الملف باستخدام مفتاح موثوق به بدون قراءة الملف بأكمله.

• [C-0-4 C-2-2] يجب عدم السماح بنجاح طلبات القراءة على ملف محمي عندما يتم قراءة محتوى لا يتم التحقّق منه باستخدام مفتاح موثوق لا يتم التحقّق منه وفقًا لحالة [C-2-1] أعلاه.

بدء متطلبات جديدة

• [C-2-4] يجب عرض قيمة تحقّق الملف في O(1) للملفات المفعّلة.

إنهاء المتطلبات الجديدة

إذا سبق أن تم إطلاق عمليات تنفيذ الأجهزة بدون إمكانية التحقّق من محتوى الملف باستخدام مفتاح موثوق به على إصدار 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-0-3] يجب وضع حدّ لعدد محاولات المصادقة الأساسية غير الناجحة.
• [C-SR-2] يُنصح بشدة بتطبيق حد أقصى يبلغ 20 محاولة مصادقة أساسية غير ناجحة، وإذا وافق المستخدمون على ميزة وفعّلوها، يجب إجراء "إعادة ضبط البيانات إلى الإعدادات الأصلية" بعد تجاوز الحد الأقصى لعدد محاولات المصادقة الأساسية غير الناجحة.

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

• [C-SR-3] يُنصح بشدة بأن يتألّف رقم التعريف الشخصي من 6 أرقام على الأقل، أو محتوى عشوائيًا بسعة 20 بت.
• [C-2-1] يجب ألا يسمح رقم التعريف الشخصي الذي يقلّ طوله عن 6 أرقام بإدخاله تلقائيًا بدون تفاعل المستخدم لتجنُّب الكشف عن طول رقم التعريف الشخصي.

إنهاء المتطلبات الجديدة

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

• [C-1-1] يجب الاحتفاظ بنسخة احتياطية من عملية تنفيذ ملف تخزين المفاتيح باستخدام بيئة تنفيذ معزولة.
• [C-1-2] يجب أن تتضمّن عمليات تنفيذ خوارزميات التشفير RSA وAES وECDSA وECDH (إذا كان IKeyMintDevice متوافقًا) و3DES وHMAC ووظائف تجزئة عائلة MD5 وSHA1 وSHA-2 لكي تتوافق بشكلٍ سليم مع خوارزميات نظام "متجر مفاتيح Android" المتوافقة في منطقة معزولة بشكلٍ آمن عن الرمز البرمجي الذي يعمل على النواة والإصدارات الأحدث. يجب أن تحظر ميزة "العزل الآمن" جميع الآليات المحتملة التي يمكن من خلالها لرمز 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
  • الإصدار 2 من IKeyMintDevice
• [C-SR-1] يُنصح بشدة بتوفير الإصدار 1 من IKeyMintDevice.

9.11.1. تأمين شاشة القفل والمصادقة والأجهزة الافتراضية

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

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

• [C-SR-1] يُنصح بشدة بضبط طريقة واحدة فقط مما يلي على أنّها طريقة المصادقة الأساسية:

  • رقم تعريف شخصي رقمي
  • كلمة مرور أبجدية رقمية

  • نمط تمرير سريع على شبكة من النقاط 3×3 بالضبط

    يُرجى العلم أنّه تتم الإشارة إلى طرق المصادقة المذكورة أعلاه على أنّها methodsprimary methods مصادقة primary methods مقترَحة في هذا المستند.

بدء متطلبات جديدة

• [C-0-1] يجب وضع حدّ لعدد محاولات المصادقة الأساسية غير الناجحة.
• [C-SR-5] يُنصح بشدة بتطبيق حد أقصى يبلغ 20 محاولة مراسلة غير ناجحة للمصادقة الأساسية، وإذا وافق المستخدمون على الميزة وفعّلوها، ينبغي إجراء "إعادة ضبط البيانات على الإعدادات الأصلية" بعد تجاوز الحد الأقصى لمحاولات المراسلة غير الناجحة للمصادقة الأساسية.

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

• [C-SR-6] يُنصح بشدة بأن يتكوّن رقم التعريف الشخصي من 6 أرقام على الأقل، أو ما يعادل 20 بتًا من التشويش.
• [C-SR-7] يُنصح بشدة بعدم السماح بتسجيل رقم تعريف شخصي أقصر من 6 أرقام بواسطة إدخاله تلقائيًا بدون تدخل المستخدم لتجنُّب الكشف عن طول رقم التعريف الشخصي.

إنهاء المتطلبات الجديدة

إذا كانت عمليات تنفيذ الأجهزة تضيف أو تعدّل 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 ساعات أو أقل. عندما يستوفي الرمز المميّز المادي متطلبات عمليات تنفيذ TrustAgent في C-X، تنطبق قيود المهلة المحدّدة في C-9-5 بدلاً من ذلك.
• [C-6-4] يجب عدم التعامل مع الطريقة الجديدة على أنّها شاشة قفل آمنة، ويجب اتّباع القيود الواردة في C-8 أدناه.

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

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

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

• [C-9-1] يجب قفل هذه الشاشات الافتراضية الثانوية عند قفل الشاشة التلقائية للجهاز، وفتح قفل هذه الشاشات الافتراضية الثانوية عند فتح قفل الشاشة التلقائية للجهاز.

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

• [C-10-1] يجب أن تتيح حالات قفل منفصلة لكل جهاز افتراضي
• [C-10-2] يجب فصل جميع الأجهزة الافتراضية عند انتهاء مهلة الخمول
• [C-10-3] يجب أن يكون هناك مهلة عدم نشاط
• [C-10-4] يجب قفل جميع الشاشات عندما يبدأ المستخدم وضع القفل، بما في ذلك من خلال عنصر تحكّم المستخدم في وضع القفل المطلوب للأجهزة المحمولة (راجِع الفقرة 2.2.5[9.11/H-1-2]).
• [C-10-5] يجب أن تتوفّر نُسخ أجهزة افتراضية منفصلة لكل مستخدم
• [C-10-6] يجب إيقاف إنشاء أحداث الإدخال المرتبطة من خلال VirtualDeviceManager عند الإشارة إلى ذلك من خلال DevicePolicyManager.setNearbyAppStreamingPolicy
• [C-10-7] يجب استخدام حافظة نصوص منفصلة لكل جهاز افتراضي فقط (أو إيقاف حافظة النصوص للأجهزة الافتراضية)
• [C-10-11] يجب إيقاف واجهة مستخدم المصادقة على الأجهزة الافتراضية، بما في ذلك إدخال عامل المعرفة وطلب المقاييس الحيوية
• [C-10-12] يجب حصر النوايا التي يتم بدء تشغيلها من جهاز افتراضي لعرضها على الجهاز الافتراضي نفسه فقط
• [C-10-13] يجب عدم استخدام حالة قفل الجهاز الافتراضي كمصادقة مستخدم إذن باستخدام نظام "مخزن مفاتيح Android". يُرجى الاطّلاع على KeyGenParameterSpec.Builder.setUserAuthentication*.

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

• [C-11-1] يجب تشفير عامل المعلومات باستخدام ضمانات حماية مشابهة لتلك الموضّحة في مستند Google Cloud Key Vault Service المتعلق بالأمان عند نقل عامل المعلومات من الجهاز المصدر إلى الجهاز المستهدَف بحيث لا يمكن فك تشفير عامل المعلومات عن بُعد أو استخدامه لفتح قفل أي من الجهازَين عن بُعد.
• [C-11-2] يجب أن يطلب التطبيق من المستخدم تأكيد عامل المعرفة على الجهاز المصدر قبل نقله إلى الجهاز الهدف.
• [C-11-3] على الجهاز المستهدَف الذي لا يتضمّن أي عامل معرفة أساسي تم ضبطه للمصادقة، يجب أن يطلب من المستخدم تأكيد عامل معرفة تم نقله على الجهاز المستهدَف قبل ضبط عامل المعرفة هذا كعامل معرفة أساسي للمصادقة على الجهاز المستهدَف وقبل إتاحة أي بيانات تم نقلها من جهاز مصدر.

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

• [C-12-1] يجب عدم استدعاء grantTrust() باستخدام العلامة إلا عند الاتصال بجهاز مادي قريب يحتوي على شاشة قفل خاصة به، وعند مصادقة المستخدم على هويته باستخدام شاشة القفل هذه. يمكن للأجهزة القريبة استخدام آليات رصد على المعصم أو أثناء حمل الجهاز بعد فتح قفل المستخدم لمرة واحدة لاستيفاء شرط مصادقة المستخدم.
• [C-12-2] يجب أن يضع تنفيذ الجهاز الجهاز في الحالة TrustState.TRUSTABLE عندما تكون الشاشة مطفأة (مثلاً من خلال الضغط على زر أو عند انتهاء مهلة الشاشة ) ولم يُلغِ TrustAgent الثقة. يستوفي AOSP هذا الشرط.
• [C-12-3] يجب عدم نقل الجهاز من الحالة TrustState.TRUSTABLE إلى الحالة TrustState.TRUSTED إلا إذا كان TrustAgent لا يزال يمنح الثقة استنادًا إلى المتطلبات الواردة في C-12-1.
• [C-12-4] يجب الاتصال بـ TrustManagerService.revokeTrust()
  • بعد 24 ساعة كحد أقصى من منح الثقة
  • بعد مرور فترة عدم تنشيط تبلغ 8 ساعات
  • إذا كانت عمليات التنفيذ لا تستخدم نطاقات آمنة من الناحية التشفيرية و دقیقة كما هو محدّد في [C-12-5]، عند فقدان الاتصال الأساسي بالجهاز المادي القريب
• [C-12-5] في عمليات التنفيذ التي تعتمد على قياس المسافة الآمن والدقيق لاستيفاء متطلبات [C-12-4]، يجب استخدام أحد الحلول التالية:
  • عمليات التنفيذ التي تستخدم النطاق الفائق العرض (UWB):
    • يجب أن تستوفي متطلبات الامتثال والشهادة والدقة و متطلبات المعايرة لتقنية النطاق الفائق العرض (UWB) الموضّحة في 7.4.9.
    • يجب استخدام أحد أوضاع أمان P-STS المُدرَجة في 7.4.9.
  • عمليات التنفيذ التي تستخدم تقنية "الاتصال المباشر بمحطات لاسلكية مجاورة" (NAN) في Wi-Fi:
    • يجب أن تستوفي متطلبات الدقة الواردة في 2.2.1 [7.4.2.5/H-SR-1]، ويجب استخدام عرض النطاق الذي يبلغ 160 ميغاهرتز (أو أكثر)، ويجب اتّباع خطوات إعداد القياس المحدّدة في معايرة قياس مدى التوفّر.
    • يجب استخدام بروتوكول LTF الآمن كما هو محدّد في IEEE 802.11az.

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

• [C-13-8] يجب حظر بدء الأنشطة التي تتضمّن السمة android:canDisplayOnRemoteDevices أو التي تم ضبط البيانات الوصفية android.activity.can_display_on_remote_devices فيها على false على الافتراضي الجهاز.
• [C-13-9] يجب حظر الأنشطة التي لا تفعّل البث بشكل صريح والتي تشير إلى أنّها تعرض محتوى حسّاسًا، بما في ذلك من خلال SurfaceView#setSecure أو FLAG_SECURE أو SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS، من بدؤها على الجهاز الافتراضي.
• [C-13-10] يجب إيقاف تثبيت التطبيقات التي يتم بدء تثبيتها من الأجهزة الافتراضية.

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

يقدّم مشروع Android Open Source Project مرجعًا لتطبيق موثوق (libeic) يمكن استخدامه لتنفيذ نظام بيانات اعتماد الهوية.

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

9.17. Android Virtualization Framework

إذا كان الجهاز يتيح استخدام واجهات برمجة تطبيقات Android Virtualization Framework (android.system.virtualmachine.*)، سينفّذ مضيف Android ما يلي:

• [C-1-1] يجب أن تتوافق مع جميع واجهات برمجة التطبيقات المحدّدة في حزمة android.system.virtualmachine.
• [C-1-2] يجب عدم تعديل نموذج أذونات ونظام SELinux في Android لإدارة الأجهزة الافتراضية المحمية (pVM).

• [C-1-3] يجب عدم تعديل قواعد neverallow الحالية أو حذفها أو استبدالها ضمن نظام/سياسة sepolicy المقدَّمة في "المشروع المفتوح المصدر لنظام Android" (AOSP)، ويجب أن تكون السياسة متوافقة مع جميع قواعد neverallow الحالية.

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

• [C-1-5] يجب عدم السماح بجهاز افتراضي محمي pVM بتنفيذ رمز برمجي ليس جزءًا من صورة المصنع أو تحديثاتها. يجب عدم السماح بتشغيل أي محتوى لا يشمله أسلوب "التشغيل المتحقّق منه" في نظام Android (مثل الملفات التي تم تنزيلها من الإنترنت أو التي تم تثبيتها من مصدر غير معروف) في "آلة افتراضية محمية" .

بدء متطلبات جديدة

• [C-1-5] يجب السماح فقط لنظام التشغيل الظاهري (VM) غير القابل لتصحيح الأخطاء بتنفيذ الرمز من ملف بدء التشغيل أو تحديثات النظام الأساسي التي تتضمّن أيضًا أي تحديثات للتطبيقات المفوَّضة.

إنهاء المتطلبات الجديدة

إذا كان الجهاز يتيح استخدام واجهات برمجة التطبيقات في إطار عمل Android Virtualization Framework (android.system.virtualmachine.*)، فإنّ أي مثيل لجهاز افتراضي محمي pVM :

• [C-2-1] يجب أن يكون بإمكانه تشغيل جميع أنظمة التشغيل المتاحة في APEX لتكنولوجيات الافتراضية في جهاز افتراضي محمي pVM .
• [C-2-2] يجب عدم السماح بتشغيل نظام التشغيل pVM على جهاز افتراضي محمي لم يوقّعه مطوّر الجهاز أو موفّر نظام التشغيل.
• [C-2-3] يجب عدم السماح بآلة افتراضية محمية pVM بتنفيذ البيانات كرمز مبرمَج (مثل SELinux neverallow execmem).

• [C-2-4] يجب عدم تعديل قواعد neverallow أو حذفها أو استبدالها في system/sepolicy/microdroid المقدَّمة في الإصدار الأحدث من "مشروع Android Open Source (AOSP)".

• [C-2-5] يجب تنفيذ آليات الدفاع المتعدّد الطبقات في الآلة الافتراضية المحمية pVM (مثل SELinux للآلات الافتراضية المحمية) حتى في أنظمة التشغيل غير المستندة إلى Microdroid.
• [C-2-6] يجب التأكّد من أنّ الجهاز الظاهري لا يعمل أو أنّ الإصدار الثابت من البرنامج يرفض التمهيد إذا تعذّر عليه التحقّق من الصور الأولية التي سيتم تشغيل الجهاز الظاهري عليها. يجب إجراء عملية إثبات الملكية داخل الجهاز الظاهري.
• [C-2-7] يجب التأكّد من أنّ البرامج الثابتة لنظام التشغيل pVM ترفض بدء التشغيل في حال تم اختراق سلامة ملف instance.img.

إذا كان الجهاز يتيح استخدام واجهات برمجة تطبيقات إطار عمل Android Virtualization (android.system.virtualmachine.*)، ينطبق ما يلي على أداة إدارة الأجهزة الافتراضية:

• [C-3-1] يجب التأكّد من أنّه لا يمكن الوصول إلى صفحات الذاكرة التي تملكها VM (إما pVM أو VM المضيف) إلا من خلال VM نفسها أو نظام التشغيل الافتراضي، وليس من خلال أجهزة VM الأخرى، سواء كانت محمية أو غير محمية. يجب عدم السماح لأي جهاز افتراضي شخصي بالوصول إلى صفحة تعود إلى كيان آخر (أي جهاز افتراضي شخصي أو نظام تشغيل افتراضي آخر)، ما لم يشاركها مالك الصفحة صراحةً. ويشمل ذلك الجهاز الظاهري المضيف. ينطبق ذلك على كلٍّ من عمليات الوصول إلى وحدة المعالجة المركزية وDMA.
• [C-3-2] يجب محو صفحة بعد استخدامها من قِبل آلة افتراضية شخصية وقبل إعادتها إلى المضيف (مثلاً، يتم إتلاف الآلة الافتراضية الشخصية).
• [C-3-3SR-1] يُنصح بشدة بالتأكّد يجب التأكّد من تحميل البرامج الثابتة لنظام التشغيل pVM وتنفيذها قبل أي رمز في نظام التشغيل pVM.
• [C-3-4] يجب التأكّد من أنّ كل جهاز افتراضي يحصل على سر خاص به {سلسلة شهادة التشغيل (BCC) ومعرّف الجهاز المركب (CDI) المقدَّمَين إلى مثيل جهاز افتراضي مخصّص للبرامج (pVM) لا يمكن الحصول عليه إلا من خلال مثيل الجهاز الافتراضي هذا ويتغيّر عند إعادة الضبط على الإعدادات الأصلية وعبر الهواء.

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

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

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

• [C-5-1] يجب أن يكون قادرًا على إتاحة ميزة "الترجمة المجمّعة المنعزلة" ولكن يمكنه إيقاف ميزة "الترجمة المجمّعة المنعزلة" في عملية شحن الجهاز عند توفّر تحديث لوقت تشغيل ART.

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

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

• [C-SR-26-2] يُنصح بشدة باستخدام DICE كآلية اشتقاق سر لكل جهاز افتراضي. يجب إجراء تحليل DICE بشكل صحيح، أي تقديم القيم الصحيحة.

10. اختبار توافق البرامج

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

10.1. مجموعة أدوات اختبار التوافق

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

• [C-0-1] يجب اجتياز مجموعة اختبار التوافق مع Android (CTS) المتوفّرة من "المشروع المفتوح المصدر لنظام Android"، باستخدام الإصدار النهائي من البرنامج على الجهاز.

• [C-0-2] يجب ضمان التوافق في حالات الغموض في CTS وأي إعادة تنفيذ لأجزاء من رمز المصدر المرجعي.

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

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

• [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. سجلّ تغييرات المستندات

في ما يلي ملخّص للتغييرات التي طرأت على تعريف التوافق في هذا الإصدار:

• سجلّ التغييرات في المستند

13. التواصل معنا

يمكنك الانضمام إلى منتدى توافق Android وطلب توضيحات أو طرح أي مشاكل تعتقد أنّ المستند لا يتناولها.