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

1. مقدّمة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.1. الأجهزة

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

• [7.1.1.1/H-0-1] يجب أن يتضمّن جهاز Android شاشة واحدة على الأقل متوافقة مع Android تستوفي جميع المتطلبات الموضّحة في هذا المستند.
• [7.1.1.3/H-SR] يُنصح بشدة بمنح المستخدمين إمكانية تغيير حجم الشاشة (كثافة الشاشة).

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

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

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

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

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

• [7.1.4.5/H-1-1] يجب الإعلان عن توفّر الإضافات EGL_EXT_gl_colorspace_bt2020_pq وEGL_EXT_surface_SMPTE2086_metadata وEGL_EXT_surface_CTA861_3_metadata وVK_EXT_swapchain_colorspace وVK_EXT_hdr_metadata.

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

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

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

• [7.1.4.6/H-1-1] يجب أن يُبلغ عن تتبع protobuf كإخراج يتوافق مع مخطّط عدّادات وحدة معالجة الرسومات ومراحل عرض وحدة معالجة الرسومات المحدّدة في مستندات Perfetto.
• [7.1.4.6/H-1-2] يجب أن تُبلغ عن قيم متوافقة لعدادات وحدة معالجة الرسومات في الجهاز وفقًا لبروتوكول حزمة تتبُّع عداد وحدة معالجة الرسومات.
• [7.1.4.6/H-1-3] يجب أن يتم الإبلاغ عن قيم متوافقة لمراحل عرض وحدة معالجة الرسومات في الجهاز وفقًا لبروتوكول حزمة تتبُّع مرحلة العرض.
• [7.1.4.6/H-1-4] يجب الإبلاغ عن نقطة تتبُّع لتردد وحدة معالجة الرسومات على النحو المحدّد في التنسيق: power/gpu_frequency.

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

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

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

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

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

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

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

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

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

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

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

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

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

• [7.4.7/H-1-1] يجب توفير وضع توفير البيانات.

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

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

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

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

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

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

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

• [7.6.1/H-3-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 896 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم درجات دقة إطار الذاكرة حتى 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").

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

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

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

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

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

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

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

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

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

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

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

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

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

• [7.8.2.2/H-1-1] يجب توفير التعيين البرمجي التالي لأرقام HID:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [7.10/H-SR]* يُنصح بشدة بعدم استخدام محرّك لمسي (مُحرّك اهتزازي) للكتلة الدوّارة(ERM).
• [7.10/ساعة]* يجب وضع المحرِّك بالقرب من المكان الذي يتم عادةً فيه حمل الجهاز أو لمسه باليدين.
• [7.10/H-SR]* يُنصح بشدة بتنفيذ جميع الثوابت العامة لللمسات الواضحة في 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/H-SR]* يُنصح بشدة بتنفيذ جميع الثوابت العامة لللمسات الواضحة في android.os.VibrationEffect، وهي (EFFECT_TICK وEFFECT_CLICK وEFFECT_HEAVY_CLICK وEFFECT_DOUBLE_CLICK) وجميع الثوابت العامة لللمسات الغنية في android.os.VibrationEffect.Composition، وهي (PRIMITIVE_CLICK وPRIMITIVE_TICK).
• [7.10/H-SR]* يُنصح بشدة باستخدام عمليات الربط هذه للمستشعرات اللمسية الثابتة المرتبطة.
• [7.10/H-SR]* يُنصح بشدة باتّباع تقييم الجودة لواجهات برمجة التطبيقات createOneShot()‎ وcreateWaveform()‎.
• [7.10/H-SR]* يُنصح بشدة بالتحقّق من إمكانات قابلية تغيير شدة الاهتزاز من خلال تشغيل android.os.Vibrator.hasAmplitudeControl()‎.

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

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

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

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

• [7.10/H-SR]* يُنصح بشدة بأن يكون تردد الرنين لوحدة LRA في محور X أقل من 200 هرتز.

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

• [7.10/H-SR]* يُنصح بشدة بإجراء تقييم للجودة للمستشعرات اللمسية.

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

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

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

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

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

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

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

2.2.3. البرامج

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

• [3.2.3.1/H-0-1] يجب أن يتضمّن التطبيق طلبات ACTION_GET_CONTENT وACTION_OPEN_DOCUMENT وACTION_OPEN_DOCUMENT_TREE وACTION_CREATE_DOCUMENT كما هو موضّح في مستندات حزمة تطوير البرامج (SDK)، وأن يقدّم للمستخدم إمكانية الوصول إلى بيانات مقدّم المستندات باستخدام واجهة برمجة التطبيقات DocumentsProvider.
• [3.2.3.1/H-0-2]* يجب تحميل تطبيق واحد أو أكثر أو مكوّنات خدمة واحدة أو أكثر مسبقًا باستخدام معالِج أهداف، وذلك لجميع أنماط فلاتر الأهداف العامة التي تحدّدها أهداف التطبيقات التالية المدرَجة هنا.
• [3.2.3.1/H-SR] يُنصح بشدة بتثبيت تطبيق بريد إلكتروني مُسبَقًا يمكنه معالجة النوايا 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] يُنصح بشدة باستخدام مشغّل افتراضي يتيح تثبيت التطبيقات المصغّرة والتطبيقات المصغّرة وwidgetFeatures داخل التطبيق.
• [3.8.1/H-SR] يُنصح بشدة بتنفيذ مشغّل افتراضي يوفر إمكانية الوصول السريع إلى الاختصارات الإضافية التي تقدّمها التطبيقات التابعة لجهات خارجية من خلال واجهة برمجة التطبيقات ShortcutManager.
• [3.8.1/H-SR] يُنصح بشدة بتضمين تطبيق مشغّل تطبيقات تلقائي يعرض شارات لرمز التطبيق.
• [3.8.2/H-SR] يُنصح بشدة بتوفّر التطبيقات المصغّرة التابعة لجهات خارجية.
• [3.8.3/H-0-1] يجب السماح للتطبيقات التابعة لجهات خارجية بإرسال إشعارات إلى المستخدمين بشأن الأحداث البارزة من خلال فئات واجهة برمجة التطبيقات Notification وNotificationManager.
• [3.8.3/H-0-2] يجب أن تتيح الإشعارات الغنية.
• [3.8.3/H-0-3] يجب أن يكون التطبيق متوافقًا مع الإشعارات الفورية.
• [3.8.3/H-0-4] يجب أن يتضمّن تطبيقك مربّع إشعارات، ما يتيح للمستخدم التحكّم مباشرةً في الإشعارات (مثل الردّ أو التأجيل أو الإغلاق أو الحظر) من خلال عناصر تفاعلية تناسب المستخدمين، مثل أزرار الإجراءات أو لوحة التحكّم كما هو مُطبَّق في AOSP.
• [3.8.3/H-0-5] يجب عرض الخيارات المقدَّمة من خلال RemoteInput.Builder setChoices() في مركز الإشعارات.
• [3.8.3/H-SR] يُنصح بشدة بعرض الخيار الأول المقدَّم من خلال RemoteInput.Builder setChoices() في نافذة الإشعارات بدون تفاعل إضافي من المستخدم.
• [3.8.3/H-SR] يُنصح بشدة بعرض جميع الخيارات المقدَّمة من خلال RemoteInput.Builder setChoices() في مركز الإشعارات عندما يوسّع المستخدم جميع الإشعارات في مركز الإشعارات.
• [3.8.3.1/H-SR] يُنصح بشدة بعرض الإجراءات التي تم ضبط Notification.Action.Builder.setContextual فيها على أنّها true مع الردّ الذي يعرضه Notification.Remoteinput.Builder.setChoices.
• [3.8.4/H-SR] يُنصح بشدة بتنفيذ مساعد على الجهاز لمعالجة إجراء المساعدة.

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

• [3.8.4/H-SR] يُنصح بشدة باستخدام الضغط مع الاستمرار على مفتاح 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.
• [3.9/H-1-2] يجب أن يعلن التطبيق عن توافقه مع الملفات الشخصية المُدارة من خلال علامة ميزة android.software.managed_users، إلا عندما يتم ضبط الجهاز لإبلاغ عن نفسه كجهاز يحتوي على ذاكرة وصول عشوائي منخفضة أو لتحديد مساحة تخزين داخلية (غير قابلة للإزالة) كمساحة تخزين مشترَكة.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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]* يجب أن يوفّر، من خلال ملف perfetto الثنائي، على الأقلّ مصادر البيانات الموضّحة في مستندات perfetto.
  • [6.1/H-0-6]* يجب تفعيل البرنامج الخفي الذي يتتبّع perfetto تلقائيًا (خاصية النظام persist.traced.enable).

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

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

2.2.7.1. الوسائط

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

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

2.2.7.2. الكاميرا

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

• [7.5/H-1-1] يجب أن تتضمّن الكاميرا الأساسية المواجهة للخلف دقة لا تقل عن 12 ميغابكسل وأن تتيح تسجيل الفيديو بدقة 4K بمعدّل 30 لقطة في الثانية. الكاميرا الخلفية الأساسية هي الكاميرا الخلفية التي تحمل رقم تعريف الكاميرا الأقل.
• [7.5/H-1-2] يجب أن تتضمّن الكاميرا الأمامية الأساسية دقة لا تقل عن 4 ميغابكسل وأن تتيح تسجيل الفيديوهات بدقة 1080p بمعدل 30 لقطة في الثانية. الكاميرا الأمامية الأساسية هي الكاميرا الأمامية التي تحمل رقم تعريف الكاميرا الأقل.
• [7.5/H-1-3] يجب أن تكون السمة android.info.supportedHardwareLevel متوافقة مع القيمة FULL أو أفضل للكاميرا الأساسية الخلفية وLIMITED أو أفضل للكاميرا الأساسية الأمامية
• [7.5/H-1-4] يجب أن يكون متوافقًا مع CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME لكلتا الكاميرتَين الأساسيتَين.
• [7.5/H-1-5] يجب أن يكون وقت استجابة التقاط ملف JPEG في الكاميرا 2 أقل من 1000 ملي ثانية عند استخدام دقة 1080p، وذلك وفقًا لما يتم قياسه من خلال اختبار أداء الكاميرا في CTS في ظل ظروف الإضاءة ITS (3000K) لكلتا الكاميرتين الأساسيتين.
• [7.5/H-1-6] يجب أن يكون وقت استجابة بدء تشغيل camera2 (فتح الكاميرا إلى أول إطار معاينة) أقل من 600 ملي ثانية كما تم قياسه من خلال اختبار أداء كاميرا CTS في ظل ظروف الإضاءة ITS (3000K) لكلتا الكاميرتين الأساسيتين.

2.2.7.3. الأجهزة

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

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

2.2.7.4. الأداء

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [5.3.4/T-1-1] دقة عالية 1080p بمعدل 60 لقطة في الثانية باستخدام الملف الشخصي الأساسي
• [5.3.4/T-1-2] دقة عالية 1080p بمعدل 60 لقطة في الثانية باستخدام الملف الشخصي الرئيسي
• [5.3.4/T-1-3] دقة عالية 1080p بمعدل 60 لقطة في الثانية باستخدام High Profile Level 4.2

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

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

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

• [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 وملف فك ترميز المحتوى بدقة فائقة، يجب أن تستوفي الشروط التالية:

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

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

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

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

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

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

• [5.8/T-1-1] يجب أن يكون الجهاز متوافقًا مع معيار HDCP 2.2.

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

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

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

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

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

• [9.11/T-0-1] يجب الاحتفاظ بنسخة احتياطية من عملية تنفيذ ملف تخزين المفاتيح باستخدام بيئة تنفيذ معزولة.
• [9.11/T-0-2] يجب أن تتضمّن عمليات تنفيذ خوارزميات التشفير RSA وAES وECDSA وHMAC ووظائف تجزئة مجموعة MD5 وSHA1 وSHA-2 لتتوافق بشكل صحيح مع الخوارزميات المتوافقة لنظام "متجر مفاتيح Android" في منطقة معزولة بشكل آمن عن الرمز البرمجي الذي يتم تشغيله على النواة والإصدارات الأحدث. يجب أن تحظر ميزة "العزل الآمن" جميع الآليات المحتملة التي يمكن من خلالها لرمز 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 في استخدام عناصر التحكّم لتفعيل /إيقاف إمكانية وصول المستخدمين الآخرين إلى المكالمات الصوتية والرسائل القصيرة.

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] يجب أن تتوفّر للمستخدم وظيفة "الصفحة الرئيسية" و"الرجوع" باستثناء الحالات التي يكون فيها الجهاز في وضع UI_MODE_TYPE_WATCH.

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

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

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

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

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

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

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

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

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

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

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

2.4.3. البرامج

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5.1. الأجهزة

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

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

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

• [7.2.3/A-0-1] يجب أن يوفّر التطبيق وظيفة "الصفحة الرئيسية"، ويمكن أن يوفّر وظيفتَي "الرجوع" و"التطبيقات المستخدَمة مؤخرًا".

• [7.2.3/A-0-2] يجب إرسال كل من حدث الضغط العادي والضغط مع الاستمرار لدالة الرجوع (KEYCODE_BACK) إلى التطبيق الذي يعمل في المقدّمة.
• [7.3/A-0-1] يجب تنفيذ GEAR_SELECTION وNIGHT_MODE وPERF_VEHICLE_SPEED وPARKING_BRAKE_ON والإبلاغ عنها.
• [7.3/A-0-2] يجب أن تكون قيمة العلامة NIGHT_MODE متسقة مع وضع لوحة البيانات "ليل/نهار"، ويجب أن تستند إلى إدخال أداة استشعار الإضاءة المحيطة. قد تكون أداة استشعار الضوء المحيط الأساسية هي نفسها مقياس الضوء.
• [7.3/A-0-3] يجب تقديم حقل معلومات إضافية عن جهاز الاستشعار TYPE_SENSOR_PLACEMENT كجزء من SensorAdditionalInfo لكل جهاز استشعار مقدَّم.
• [7.3/أ-0-1] يجوز استخدام طريقة التقدير التقريبي للموقع الجغرافي من خلال دمج نظام تحديد المواقع العالمي (GPS)/نظام تحديد المواقع العالمي عبر الأقمار الصناعية (GNSS) مع أجهزة استشعار إضافية. إذا تم احتساب الموقع الجغرافي بالاستناد إلى التقديرات، يُنصح بشدة بتنفيذ أنواع أجهزة الاستشعار و/أو أرقام تعريف خصائص المركبات المقابلة وإعداد تقارير عنها.
• [7.3/A-0-2] يجب عدم مطابقة الموقع الجغرافي الذي تم طلبه من خلال LocationManager#requestLocationUpdates()‎ مع الخريطة.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [5.1/A-0-1] الملف الشخصي MPEG-4 AAC (AAC LC)
• [5.1/A-0-2] MPEG-4 HE AAC Profile (AAC+)
• [5.1/A-0-3] ‫AAC ELD (ترميز AAC المتقدّم المنخفض التأخير)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

يُرجى العِلم أنّه إذا سبق إطلاق عملية تنفيذ على جهاز باستخدام إصدار أقدم من 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.1.1.1/Tab-0-1] يجب أن يكون حجم الشاشة في النطاق من 7 إلى 18 بوصة.

الجيروسكوب

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

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

3.1.1. إضافات Android

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

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

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

• [C-0-2] يجب أن يعرض الحقل رقم إصدار صالحًا للملحق تم تحديده من خلال AOSP فقط.

• [C-0-3] يجب أن تكون متوافقة مع جميع واجهات برمجة التطبيقات المحدّدة من خلال إصدارات الإضافة التي يعرضها android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) بالطريقة نفسها التي تتوفّر بها واجهات برمجة التطبيقات المُدارة الأخرى، وذلك وفقًا للمتطلبات الواردة في الفقرة 3.1.

3.1.2. مكتبة Android

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

• [C-0-1] يجب عدم وضع مكتبة org.apache.http.legacy في مسار تحميل البرامج.
• [C-0-2] يجب إضافة مكتبة org.apache.http.legacy إلى مسار تطبيق 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] لتقديم قيم متسقة ومفيدة في جميع عمليات تنفيذ الأجهزة، يتضمّن الجدول أدناه قيودًا إضافية على تنسيقات هذه القيم التي يجب أن تتوافق معها عمليات تنفيذ الأجهزة.

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

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

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

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

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

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

3.2.3.2. حلّ النية

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

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

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

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

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

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

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

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

3.2.3.4. نوايا البث

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

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

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

3.2.3.5. أغراض التطبيقات المشروطة

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

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

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

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

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

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

• [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] يُنصح بشدة بتنفيذ إجراءات 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] يجب أن يراعي التطبيق عناصر النية التالية android.nfc.action.NDEF_DISCOVERED وandroid.nfc.action.TAG_DISCOVERED وandroid.nfc.action.TECH_DISCOVERED لعرض نشاط يستوفي توقعات المطوّرين لهذه النية كما هو موضّح في حزمة تطوير البرامج (SDK).

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

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

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

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

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

• [C-11-1] يجب أن يتضمّن نشاطًا يعالج هدف Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS، ولكن يجوز تنفيذه كإجراء لا يؤدي إلى أيّ تأثير.

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

• [C-12-1] يجب أن يراعي التطبيق النية android.media.action.STILL_IMAGE_CAMERA وandroid.media.action.STILL_IMAGE_CAMERA_SECURE وأن يشغّل الكاميرا في وضع الصور الثابتة على النحو الموضّح في حزمة تطوير البرامج (SDK).
• [C-12-2] يجب أن يحترم التطبيق android.media.action.VIDEO_CAMERA نية تشغيل الكاميرا في وضع الفيديو على النحو الموضّح في حزمة تطوير البرامج (SDK).
• [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.ADMIN_POLICY_COMPLIANCE وandroid.app.action.GET_PROVISIONING_MODE وandroid.app.action.PROVISIONING_SUCCESSFUL وandroid.app.action.PROVISION_MANAGED_DEVICE و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] يُنصح بشدة بتوفير آلية يمكن للمستخدم الوصول إليها لمنح الإذن بالوصول إلى إحصاءات الاستخدام أو إبطاله استجابةً للنوايا android.settings.ACTION_USAGE_ACCESS_SETTINGS للتطبيقات التي تذكر الإذن android.permission.PACKAGE_USAGE_STATS.

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

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

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

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

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

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

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

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

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

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

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

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

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

• [SR] يُنصح بشدة باستخدام عمليات تنفيذ المكتبات المدرَجة أدناه من مشروع Android Open Source Project.

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

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

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

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

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

  • armeabi (لم يعُد متوافقًا مع NDK)
  • armeabi-v7a
  • arm64-v8a
  • x86
  • x86-64

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

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

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

• [C-0-9] يجب إدراج مكتبات إضافية غير تابعة لمشروع AOSP تم إتاحة الوصول إليها مباشرةً للتطبيقات التابعة لجهات خارجية في /vendor/etc/public.libraries.txt.
• [C-0-10] يجب عدم إتاحة أي مكتبات أخرى مجمّعة من رموز برمجية أصلية، تم تنفيذها وتوفيرها في AOSP كمكتبات نظام، للتطبيقات التابعة لجهات خارجية التي تستهدف المستوى 24 من واجهة برمجة التطبيقات أو الإصدارات الأحدث، لأنّها محجوزة.
• [C-0-11] يجب تصدير جميع رموز دوال OpenGL ES 3.1 ومجموعة ملحقات Android، كما هو محدّد في حزمة NDK، من خلال مكتبة libGLESv3.so. يُرجى العِلم أنّه على الرغم من أنّه يجب أن تكون جميع الرموز متوفّرة، يصف القسم 7.1.4.1 بالتفصيل المتطلّبات المتعلّقة بوقت تنفيذ كلّ دالة مقابلة بالكامل.
• [C-0-12] يجب تصدير رموز الدوالّ الأساسية لواجهة برمجة التطبيقات Vulkan 1.0، بالإضافة إلى الإضافات VK_KHR_surface وVK_KHR_android_surface وVK_KHR_swapchain وVK_KHR_maintenance1 وVK_KHR_get_physical_device_properties2 من خلال مكتبة libvulkan.so. يُرجى العِلم أنّه على الرغم من أنّه يجب أن تكون جميع الرموز متوفّرة، يوضّح القسم 7.1.4.2 متطلبات وقت التنفيذ الكامل لكل دالة مقابلة بمزيد من التفصيل.
• يجب إنشاؤها باستخدام رمز المصدر وملفات الرأس المتاحة في مشروع Android Open Source Project

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

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

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

• [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
  • تعليمات SETEND
  • عمليات الحواجز CP15ISB وCP15DSB وCP15DMB

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

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

3.4.1. توافق WebView

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

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

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

• [C-1-3] يجب عرض المحتوى المقدَّم أو محتوى عنوان 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 الأساسي أو بديلاً تابعًا لجهة خارجية).

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

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

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

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

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

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

• [C-0-1] يجب ألا تغيّر الأجهزة سلوك النية العادية أو دلالة ذلك.
• [C-0-2] يجب ألا تغيّر الأجهزة دورة الحياة أو دلالات دورة الحياة لأحد أنواع مكوّنات النظام (مثل Service أو Activity أو 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-9] يجب أن تعرض الأجهزة مقدّمي خدمات الأمان التاليين كأول قيم سبعة في الصفيف من طريقة Security.getProviders()، بالترتيب المحدّد وبالأسماء المحدّدة (كما تعرضها Provider.getName()) والفئات، ما لم يُعدِّل التطبيق القائمة من خلال insertProviderAt() أو removeProvider(). قد تعرض الأجهزة مزوّدين إضافيين بعد قائمة المزوّدين المحدّدة أدناه.
  1. AndroidNSSP - android.security.net.config.NetworkSecurityConfigProvider
  2. AndroidOpenSSL - com.android.org.conscrypt.OpenSSLProvider
  3. CertPathProvider - sun.security.provider.CertPathProvider
  4. ‫AndroidKeyStoreBCWorkaround - android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
  5. BC - com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
  6. HarmonyJSSE - com.android.org.conscrypt.JSSEProvider
  7. ‫AndroidKeyStore - android.security.keystore.AndroidKeyStoreProvider

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

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

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

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

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>) بزيادة استخدام الذاكرة لهذه واجهات برمجة التطبيقات.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [C-SR] يُنصح بشدة بعرض هذه المحادثة كفقاعة محادثة. يستوفي تطبيق 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. البحث

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

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

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

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

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

• من المفترض أن يكون السلوك التلقائي هو عرض نتائج واقتراحات محرّك بحث الويب.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* [C-2-1] MUST render text with Unicode compliant font as default;
  non-Unicode compliant font MUST NOT be set as default font unless the user
  chooses it in the language picker.
* [C-2-2] MUST support a Unicode font and a non-Unicode compliant font if a
  non-Unicode compliant font is supported on the device.  Non-Unicode
  compliant font MUST NOT remove or overwrite the Unicode font.
* [C-2-3] MUST render text with non-Unicode compliant font ONLY IF a
  language code with [script code Qaag](
  http://unicode.org/reports/tr35/#unicode_script_subtag_validity) is
  specified (e.g. my-Qaag). No other ISO language or region codes (whether
  assigned, unassigned, or reserved) can be used to refer to non-Unicode
  compliant font for Myanmar. App developers and web page authors can
  specify my-Qaag as the designated language code as they would for any
  other language.

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

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

• [C-3-1] يجب إطلاق الأنشطة في وضع "صورة في صورة" المتعدّد النوافذ عندما يكون التطبيق: * يستهدف المستوى 26 من واجهة برمجة التطبيقات أو إصدارًا أحدث ويعلن عن android:supportsPictureInPicture * يستهدف المستوى 25 من واجهة برمجة التطبيقات أو إصدارًا أقدم ويعلن عن كل من android:resizeableActivity وandroid:supportsPictureInPicture.
• [C-3-2] يجب أن يعرض التطبيق الإجراءات في SystemUI على النحو المحدّد من خلال نشاط PIP الحالي من خلال واجهة برمجة التطبيقات setActions().
• [C-3-3] يجب أن تتيح استخدام نسب عرض إلى ارتفاع أكبر من أو تساوي 1:2.39 وأصغر من أو تساوي 2.39:1، كما هو محدّد في نشاط وضع الصورة في الصورة من خلال واجهة برمجة التطبيقات setAspectRatio().
• [C-3-4] يجب استخدام KeyEvent.KEYCODE_WINDOW للتحكّم في نافذة الصورة في الصورة. وفي حال عدم تنفيذ وضع "الصورة في الصورة"، يجب أن يكون المفتاح متاحًا للنشاط في المقدّمة.
• [C-3-5] يجب أن يقدّم التطبيق ميزة تتيح للمستخدم حظر عرض تطبيق في وضع "صورة في صورة"، ويلبي تطبيق AOSP هذا الشرط من خلال توفير عناصر تحكّم في نافذة الإشعارات.

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

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

3.8.15. جزء مقتطع من الشاشة

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

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

• [C-1-5] يجب ألّا تتضمّن لقطات الشاشة أيّ أجزاء مُقتطعة إذا كانت نسبة العرض إلى الارتفاع للجهاز 1.0(1:1).
• [C-1-2] يجب ألا يتضمّن أكثر من فتحة واحدة لكل جانب.
• [C-1-3] يجب الالتزام بعلامات اقتصاص الشاشة التي يضبطها التطبيق من خلال واجهة برمجة التطبيقات WindowManager.LayoutParams على النحو الموضّح في حزمة تطوير البرامج (SDK).
• [C-1-4] يجب أن تُبلغ عن قيم صحيحة لجميع مقاييس القطع المحدّدة في واجهة برمجة التطبيقات DisplayCutout.

3.8.16. عناصر التحكّم بالأجهزة

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

راجِع القسم 2_2_3 لمعرفة المتطلبات الخاصة بالأجهزة.

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

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

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

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

3.9.1 إدارة الجهاز

3.9.1.1 إعداد حساب مالك الجهاز

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

• [C-1-1] يجب أن يتيح التطبيق تسجيل "وحدة التحكّم بسياسة الجهاز" (DPC) كـ تطبيق مالك الجهاز على النحو الموضّح أدناه:
  • عندما لا تتوفّر بيانات المستخدمين في عملية تنفيذ الجهاز بعد، يتم تنفيذ ما يلي:
    • [C-1-3] يجب الإبلاغ عن true DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-4] يجب تسجيل تطبيق DPC كتطبيق "مالك الجهاز" استجابةً للإجراء المستند إلى النية android.app.action.PROVISION_MANAGED_DEVICE.
    • [C-1-5] يجب تسجيل تطبيق إدارة الخدمات الجوّالة (DPC) كتطبيق "مالك الجهاز" إذا كان الجهاز يعلن عن توافقه مع تقنية "الاتصال القصير المدى" (NFC) من خلال علامة ميزة android.hardware.nfc ويتلقّى رسالة NFC تحتوي على سجلّ بنوع MIME‏ MIME_TYPE_PROVISIONING_NFC.
  • عندما يتضمّن تطبيق الجهاز بيانات المستخدمين، يتم إجراء ما يلي:
    • [C-1-6] يجب الإبلاغ عن false لـ DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-7] يجب عدم تسجيل أي تطبيق DPC كتطبيق "مالك الجهاز" بعد الآن.
• [C-1-2] يجب أن يتطلّب التطبيق اتخاذ إجراء إيجابي قبل عملية الإعداد أو أثناءها للموافقة على ضبط التطبيق على أنّه "مالك الجهاز". يمكن الحصول على الموافقة من خلال إجراء يتّخذه المستخدم أو من خلال بعض الوسائل الآلية، ولكن يجب عرض إشعار الإفصاح المناسب (كما هو مذكور في AOSP) قبل بدء عملية إدارة حسابات مالك الجهاز. بالإضافة إلى ذلك، يجب ألّا تتداخل آلية الموافقة الآلية الخاصة بمالك الجهاز التي تستخدمها (المؤسسات) لتوفير مالك الجهاز مع تجربة الاستخدام خارج العلبة للاستخدام غير المرتبط بالمؤسسة.
• [C-1-3] يجب عدم تضمين الموافقة في الرمز البرمجي بشكل ثابت أو منع استخدام تطبيقات مالك الجهاز الأخرى.

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

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

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
  • رمز تطبيق "مركز التحكّم في البيانات"

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)، حتى إذا لم يتم احتساب الملف الشخصي المُدار كمستخدم آخر بالإضافة إلى المستخدم الأساسي.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.13. الإعدادات السريعة

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

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

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

3.14. واجهة مستخدم الوسائط

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

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

• [C-1-3] يجب عرض رمز التطبيق التابع لجهة خارجية عند عرض محتوى يقدّمه هذا التطبيق التابع لجهة خارجية.

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

• [C-1-5] يجب اعتبار النقر مرّتين على KEYCODE_HEADSETHOOK أو KEYCODE_MEDIA_PLAY_PAUSE على أنّه KEYCODE_MEDIA_NEXT لـ MediaSession.Callback#onMediaButtonEvent.

3.15. التطبيقات الفورية

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

• [C-0-1] يجب عدم منح "التطبيقات الفورية" سوى الأذونات التي تم ضبط android:protectionLevel فيها على "instant".
• [C-0-2] يجب ألا تتفاعل التطبيقات الفورية مع التطبيقات المثبّتة من خلال المهام الضمنية ما لم يكن أحد الشروط التالية صحيحًا:
  • يتم عرض فلتر نمط الأهداف للمكوّن ويتضمّن CATEGORY_BROWSABLE.
  • الإجراء هو أحد الإجراءات التالية: ACTION_SEND أو ACTION_SENDTO أو ACTION_SEND_MULTIPLE
  • يتم عرض الهدف بشكل صريح باستخدام android:visibleToInstantApps
• [C-0-3] يجب ألّا تتفاعل التطبيقات الفورية بشكل صريح مع التطبيقات المثبّتة ما لم يتم عرض المكوّن من خلال android:visibleToInstantApps.
• [C-0-4] يجب ألا تظهر تفاصيل عن التطبيقات الفورية على الأجهزة للتطبيقات المثبّتة ما لم يتصل التطبيق الفوري صراحةً بالتطبيق المثبّت.

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

• [C-1-1] يجب توفير العناصر التالية للمستخدمين للتفاعل مع التطبيقات الفورية. يستوفي نظام التشغيل AOSP المتطلبات من خلال واجهة المستخدم و"الإعدادات" و"المشغِّل" التلقائيَين.
• [C-1-2] يجب أن يوفّر التطبيق ميزة للمستخدم لعرض التطبيقات الفورية المحفوظة مؤقتًا على الجهاز وحذفها لكل حزمة تطبيق فردية.
• [C-1-3] يجب تقديم إشعار دائم للمستخدم يمكن تصغيره أثناء تشغيل تطبيق فوري في المقدّمة. يجب أن يتضمّن إشعار المستخدم هذا أنّ التطبيقات الفورية لا تتطلّب التثبيت وأن يقدّم عنصر تحكم يوجّه المستخدم إلى شاشة معلومات التطبيق في الإعدادات. بالنسبة إلى التطبيقات الفورية التي يتم تشغيلها من خلال نوايا الويب، كما هو محدّد باستخدام نية تم ضبط الإجراء فيها على Intent.ACTION_VIEW وباستخدام مخطّط "http" أو "https"، يجب أن تسمح ميزة إضافية للمستخدم بعدم تشغيل التطبيق الفوري وتشغيل الرابط المرتبط باستخدام متصفّح الويب الذي تم ضبطه، في حال توفّر متصفّح على الجهاز.
• [C-1-4] يجب السماح بالوصول إلى التطبيقات الفورية التي يتم تشغيلها من خلال ميزة "التطبيقات المستخدَمة مؤخرًا" إذا كانت هذه الميزة متاحة على الجهاز.
• [C-1-5] يجب تحميل تطبيق واحد أو أكثر أو مكوّنات خدمة واحدة أو أكثر مسبقًا باستخدام معالِج أهداف للأهداف المدرَجة في حزمة تطوير البرامج (SDK) هنا ويجب إظهار الأهداف لتطبيقات Instant Apps.

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

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

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

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

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

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

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

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

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

• [C-0-5] يجب أن يتضمّن نشاطًا يعالج هدف android.settings.MANAGE_UNKNOWN_APP_SOURCES.

• [C-0-6] يجب عدم تثبيت حِزم التطبيقات من مصادر غير معروفة، ما لم يستوفِ التطبيق الذي يطلب التثبيت جميع المتطلبات التالية:

  • يجب أن يعلن التطبيق عن إذن REQUEST_INSTALL_PACKAGES أو أن يكون android:targetSdkVersion مضبوطًا على 24 أو أقل.
  • يجب أن يكون المستخدم قد منح الإذن بتثبيت التطبيقات من مصادر غير معروفة.

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

• [C-0-7] يجب أن يعرض التطبيق مربّع حوار تحذيريًا يتضمّن سلسلة التحذير المقدَّمة من خلال واجهة برمجة التطبيقات للنظام PackageManager.setHarmfulAppWarning للمستخدم قبل بدء نشاط في تطبيق تم وضع علامة عليه من خلال واجهة برمجة التطبيقات للنظام نفسها PackageManager.setHarmfulAppWarning على أنّه قد يكون ضارًا.

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

• [C-0-8] يجب توفير إمكانية استخدام نظام الملفات المتزايدة كما هو موضّح هنا.

• [C-0-9] يجب أن تتيح عملية التحقّق من ملفات APK .باستخدام الإصدار 4 من مخطّط توقيع حِزم APK.

• إذا سبق إطلاق عمليات تنفيذ الأجهزة على إصدار أقدم من 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 Open Source Project.

يُرجى العِلم أنّ 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 وملف الإصدار Dynamic Range Control وفقًا لمعيار 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] يجب أن تكون البيانات الوصفية للنطاق الديناميكي كما هو محدّد في "التحكّم في النطاق الديناميكي (DRC)" في ISO/IEC 14496-3، ومفاتيح android.media.MediaFormat DRC لضبط السلوكيات ذات الصلة بالنطاق الديناميكي لبرنامج ترميز الصوت. تمّ تقديم مفاتيح AAC DRC في الإصدار 21 من واجهة برمجة التطبيقات، وهي: KEY_AAC_DRC_ATTENUATION_FACTOR وKEY_AAC_DRC_BOOST_FACTOR وKEY_AAC_DRC_HEAVY_COMPRESSION وKEY_AAC_DRC_TARGET_REFERENCE_LEVEL وKEY_AAC_ENCODED_TARGET_LEVEL.
• [SR] يُنصح بشدة باستيفاء المتطلبَين C-2-1 وC-2-2 أعلاه من قِبل جميع برامج ترميز/فك ترميز الصوت بتنسيق AAC.

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

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

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

• قد تتيح إمكانية التحكّم في مستوى الصوت والنطاق الديناميكي باستخدام الملف الشخصي للتحكّم في النطاق الديناميكي ISO/IEC 23003-4.

إذا كان معيار ISO/IEC 23003-4 متوافقًا وإذا كانت البيانات الوصفية لكل من ISO/IEC 23003-4 وISO/IEC 14496-3 متوفّرة في بث بت تم فك ترميزه، فيُرجى اتّباع الخطوات التالية:

• يجب أن تكون البيانات الوصفية وفقًا لمعيار ISO/IEC 23003-4 لها الأولوية.

يجب أن تتيح جميع برامج ترميز الصوت إخراج ما يلي:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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] يُنصح بشدة بتضمين واجهة برمجة التطبيقات Codec 2.0.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.2.1. ‫H.263

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

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

5.2.2. H.264

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

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

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

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

5.2.3. VP8

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

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

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

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

5.2.4. ‫VP9

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

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

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

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

5.2.5. ‫H.265

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

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

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

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

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

5.3.1. MPEG-2

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

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

5.3.2. ‫H.263

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

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

5.3.3. MPEG-4

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

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

5.3.4. H.264

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

• [C-1-1] يجب أن يكون متوافقًا مع المستوى 3.1 من الملف الشخصي الرئيسي والملف الشخصي الأساسي. إنّ إتاحة ASO (ترتيب الشرائح التعسّفي) وFMO (ترتيب الوحدات المجمّعة المرنة) وRS (الشريحات المكرّرة) اختيارية.
• [C-1-2] يجب أن يكون الجهاز قادرًا على فك ترميز الفيديوهات باستخدام ملفات التعريف بدقة عادية (SD) المدرَجة في الجدول التالي والمشفَّرة باستخدام ملف التعريف الأساسي وملف التعريف الرئيسي بمستوى 3.1 (بما في ذلك 720p30).
• يجب أن تكون قادرة على فك ترميز الفيديوهات باستخدام الملفات الشخصية بدقة عالية (HD) كما هو موضّح في الجدول التالي.

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

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

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.

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

5.3.7. ‫VP9

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

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

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

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

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

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

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

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

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

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

5.3.8. Dolby Vision

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

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

5.3.9. AV1

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

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

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

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

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

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

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

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

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

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

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

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

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

  • التنسيق: Linear PCM، بسعة 16 بت
  • معدّلات أخذ العينات: 22050 و48000 هرتز
  • القنوات: صوت استيريو
  • [C-1-4] يجب الالتزام بواجهة برمجة التطبيقات MicrophoneInfo وملء معلومات الميكروفونات المتاحة على الجهاز التي يمكن للتطبيقات التابعة لجهات خارجية الوصول إليها من خلال واجهة برمجة التطبيقات AudioManager.getMicrophones()، والميكروفونات النشطة حاليًا التي يمكن للتطبيقات التابعة لجهات خارجية الوصول إليها من خلال واجهات برمجة التطبيقات AudioRecord.getActiveMicrophones() وMediaRecorder.getActiveMicrophones(). إذا كانت عمليات تنفيذ الأجهزة تسمح بتسجيل المحتوى الصوتي الأوّلي بجودة راديو AM وأقراص DVD، يجب أن تستوفي الأجهزة الشروط التالية:

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

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

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

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

• [C-1-1] يجب تسجيل مصدر الصوت android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION بمعدّل من معدّلات أخذ العينات، 44100 و48000.
• [C-1-2] يجب إيقاف أي معالجة صوتية لخفض الضوضاء تلقائيًا عند تسجيل بث صوتي من مصدر الصوت AudioSource.VOICE_RECOGNITION.
• [C-1-3] يجب إيقاف أي ميزة تلقائية للتحكّم في مستوى الصوت تلقائيًا عند تسجيل بث صوتي من مصدر الصوت AudioSource.VOICE_RECOGNITION.
• يجب تسجيل بث الصوت للتعرّف على الصوت مع خصائص اتّساع ترددية مسطّحة تقريبًا: على وجه التحديد، ±3 ديسيبل، من 100 هرتز إلى 4000 هرتز.
• يجب تسجيل بث الصوت للتعرّف على الصوت مع ضبط حساسية الإدخال بحيث ينتج مصدر طاقة صوتية (SPL) بقدرة 90 ديسيبل عند 1000 هرتز قيمة طاقة متوسطة متراصة (RMS) تبلغ 2500 لملفات 16 بت.
• يجب تسجيل بث الصوت لميزة التعرّف على الصوت بحيث تتتبّع مستويات سعة PCM التغييرات في مستوى الضغط الصوتي (SPL) للإدخال بشكل خطي على نطاق 30 ديسيبل على الأقل من -18 ديسيبل إلى +12 ديسيبل مقارنةً بمستوى الضغط الصوتي البالغ 90 ديسيبل عند الميكروفون.
• يجب أن يسجِّل بث الصوت لميزة التعرّف على الصوت مع إجمالي تشويه توافقي (THD) أقل من% 1 لتردد 1 كيلوهرتز عند مستوى إدخال 90 ديسيبل SPL في الميكروفون.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.4.6. مستويات تضخيم الصوت في الميكروفون

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

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

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

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

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

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

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

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

• يجب أن تسمح بتشغيل المحتوى الصوتي الأوّلي الذي يتسم بالسمات التالية:

  • معدلات أخذ العينات: 24000 و48000

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

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

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

• [C-1-1] يجب أن تتيح تنفيذ EFFECT_TYPE_EQUALIZER وEFFECT_TYPE_LOUDNESS_ENHANCER القابلَين للتحكّم من خلال الفئتَين الفرعيتَين AudioEffect Equalizer وLoudnessEnhancer.
• [C-1-2] يجب أن تتيح تنفيذ واجهة برمجة التطبيقات لعرض البيانات، والتي يمكن التحكّم فيها من خلال فئة Visualizer.
• [C-1-3] يجب أن تتيح تنفيذ EFFECT_TYPE_DYNAMICS_PROCESSING الذي يمكن التحكّم فيه من خلال فئة فرعية من AudioEffect‏ DynamicsProcessing.
• يجب أن تتيح تنفيذ EFFECT_TYPE_BASS_BOOST وEFFECT_TYPE_ENV_REVERB وEFFECT_TYPE_PRESET_REVERB وEFFECT_TYPE_VIRTUALIZER التي يمكن التحكّم فيها من خلال الفئات الفرعية AudioEffect BassBoost وEnvironmentalReverb وPresetReverb وVirtualizer.
• [C-SR] يُنصح بشدة بتوفّر تأثيرات بتنسيق النقطة العائمة وقنوات متعددة.

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

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

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

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

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

لأغراض هذا القسم، يُرجى استخدام التعريفات التالية:

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

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

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

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

• [C-SR] وقت استجابة الإخراج على البارد بمقدار 100 ملي ثانية أو أقل ننصحك بشدة بضرورة استيفاء هذه المتطلبات الآن على الأجهزة الحالية والجديدة التي تعمل بهذا الإصدار من Android. في إصدار مستقبلي من المنصة في عام 2021، سنشترط أن يكون وقت استجابة الإخراج غير القابل للتقديم أو الإيقاف 200 ملي ثانية أو أقل.
• [C-SR] وقت استجابة مستمر للإخراج يبلغ 45 ملي ثانية أو أقل
• [C-SR] الحدّ من الارتعاش في الإخراج عند التشغيل على البارد
• [C-SR] الطابع الزمني الناتج الذي يعرضه AudioTrack.getTimestamp وAAudioStream_getTimestamp يكون دقيقًا بدقة تصل إلى ± 1 ملي ثانية.

إذا كانت عمليات تنفيذ الأجهزة تستوفي المتطلبات المذكورة أعلاه، بعد أي عملية معايرة أولية، عند استخدام كلّ من قائمة انتظار وحدة تخزين مؤقت PCM في OpenSL ES وواجهات برمجة التطبيقات الأصلية للصوت في AAudio، يجب أن تكون مدة الاستجابة المستمرة للإخراج ومدة الاستجابة للإخراج عند التشغيل لأول مرة على جهاز واحد على الأقل متوافق لإخراج الصوت على النحو التالي:

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

إذا لم تستوفِ عمليات تنفيذ الأجهزة متطلبات الصوت المنخفض الاستجابة من خلال كلّ من قائمة انتظار وحدة تخزين مؤقت PCM في OpenSL ES وواجهات برمجة التطبيقات الصوتية الأصلية في AAudio، يحدث ما يلي:

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

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

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

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

• [C-SR] وقت استجابة الإدخال من حالة السكون 100 ملي ثانية أو أقل ننصحك بشدة بضرورة استيفاء هذه المتطلبات الآن على الأجهزة الحالية والجديدة التي تعمل بهذا الإصدار من Android. في إصدار مستقبلي من المنصة في عام 2021، سنشترط أن يكون وقت استجابة الإدخال من حالة السكون 200 ملي ثانية أو أقل.
• [C-SR] وقت استجابة مستمر للإدخال يبلغ 30 ملي ثانية أو أقل
• [C-SR] وقت استجابة مستمر لإرسال البيانات واستقبالها يبلغ 50 ملي ثانية أو أقل
• [C-SR] الحدّ من الارتعاش في الإدخال البارد
• [C-SR] يجب الحد من الخطأ في الطوابع الزمنية للإدخال، كما تظهر في AudioRecord.getTimestamp أو AAudioStream_getTimestamp، إلى ± 1 ملي ثانية.

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

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

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

• [C-1-1] يجب أن تتوافق مع جميع برامج الترميز وتنسيقات الحاويات المطلوبة في الفقرة 5.1 عبر بروتوكول HTTP(S).

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

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

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

‫RTSP (RTP وSDP)

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

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

• [C-1-1] يجب الإفصاح عن توافق التطبيق مع Display.FLAG_SECURE.

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

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

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

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

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

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

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

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

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

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

• يجب أن يكون متوافقًا مع وضع MIDI عبر USB الملحق، الفقرة 7.7

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

إذا كانت عمليات تنفيذ الأجهزة تُبلغ عن توفّر الميزة android.hardware.audio.pro من خلال فئة android.content.pm.PackageManager، فإنّها:

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

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

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

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

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

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

• [C-2-1] يجب أن يكون وقت استجابة إرسال البيانات واستقبالها للصوت بشكل مستمر 20 ملي ثانية أو أقل عبر مسار مقبس الصوت.
• [SR] يُنصح بشدة بالالتزام بالقسم مواصفات الجهاز الجوّال (مقبس) من مواصفات سماعة الرأس السلكية للصوت (الإصدار 1.1).
• يجب أن يكون وقت استجابة إرسال البيانات واستقبالها للصوت بشكلٍ مستمر 10 ملي ثانية أو أقل عبر مسار مقبس الصوت.

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

• [C-3-1] يجب تنفيذ فئة الصوت في USB.
• [C-3-2] يجب أن يكون وقت استجابة إرسال البيانات واستقبالها في الصوت مستمرًا بمقدار 20 ملي ثانية أو أقل من خلال منفذ وضع مضيف USB باستخدام فئة صوت USB.
• من المفترض أن يكون وقت استجابة إرسال البيانات واستقبالها في الصوت المستمر 10 ملي ثانية أو أقل عبر منفذ وضع مضيف USB باستخدام فئة صوت USB.
• [C-SR] يُنصح بشدة بتوفُّر إمكانية نقل البيانات في كل من الاتجاهين في ما يصل إلى 8 قنوات في كل اتجاه، ومعدّل أخذ العينات 96 كيلوهرتز، وعمق 24 أو 32 بت، عند استخدامها مع أجهزة صوتية USB خارجية تتوافق أيضًا مع هذه المتطلبات.

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

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

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

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

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

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

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

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

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] يجب تسجيل الأحداث التالية بدون حذفها وإتاحة الوصول إليها لأمر shell‏ cmd stats وفئة 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"، كما هو موضّح أعلاه.
• القرد
  • [C-0-8] يجب أن يتضمّن إطار عمل Monkey وأن يكون متاحًا للتطبيقات لاستخدامه.
• SysTrace
  • [C-0-9] يجب أن تكون متوافقة مع أداة systrace كما هو موضّح في حزمة تطوير البرامج (SDK) لنظام التشغيل Android. يجب أن يكون Systrace غير مفعَّل تلقائيًا ويجب أن تتوفّر آلية يمكن للمستخدم تفعيل Systrace من خلالها.
• Perfetto
  • [C-SR] يُنصح بشدة بعرض ملف ثنائي /system/bin/perfetto لمستخدم shell الذي يتوافق مع cmdline مع مستندات perfetto.
  • [C-SR] يُنصح بشدة بقبول ملف perfetto الثنائي كإدخال لإعدادات protobuf متوافقة مع المخطط المحدّد في مستندات perfetto.
  • [C-SR] يُنصح بشدة باستخدام ملف perfetto الثنائي لكتابة تتبع protobuf يتوافق مع المخطّط المحدّد في مستندات perfetto.
  • [C-SR] يُنصح بشدة بتوفير مصادر البيانات الموضّحة في مستندات perfetto على الأقل من خلال ملف perfetto الثنائي.
• Low Memory Killer
  • [C-0-10] يجب كتابة LMK_KILL_OCCURRED_FIELD_NUMBER Atom في سجلّ statsd عند إغلاق تطبيق بواسطة Low Memory Killer.
• وضع "مفعّل الاختبار" إذا كانت عمليات تنفيذ الأجهزة تتيح استخدام الأمر shell cmd testharness وتشغيل cmd testharness enable، يتم تنفيذ ما يلي:
  • [C-2-1] يجب إرجاع true لـ ActivityManager.isRunningInUserTestHarness()
  • [C-2-2] يجب تنفيذ وضع "مفعِّل الاختبار" كما هو موضّح في مستندات وضع "مفعِّل الاختبار".

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

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

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

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

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

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

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

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

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

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

• [C-0-2] يجب تقديم تعريفات الفصول الكاملة (على النحو الموضّح في حزمة تطوير البرامج) لواجهات برمجة التطبيقات المكوّنة.
• [C-0-3] يجب تنفيذ سلوكيات واجهة برمجة التطبيقات كعمليات لا تؤدي إلى أيّ إجراء بطريقة معقولة.
• [C-0-4] يجب أن تعرِض طُرق واجهة برمجة التطبيقات قيمًا فارغة حيثما يسمح بذلك مستند حزمة تطوير البرامج (SDK).
• [C-0-5] يجب أن تعرِض طُرق واجهة برمجة التطبيقات عمليات تنفيذ لا تؤدي إلى أيّ إجراء للفئات التي لا تسمح مستندات حِزم تطوير البرامج (SDK) بقيم فارغة فيها.
• [C-0-6] يجب ألّا تُعرِض طرق واجهة برمجة التطبيقات استثناءات غير مُوثَّقة في مستندات حزمة تطوير البرامج (SDK).
• [C-0-7] يجب أن تُبلغ عمليات تنفيذ الأجهزة باستمرار عن معلومات دقيقة حول إعدادات الأجهزة من خلال الطريقتَين getSystemAvailableFeatures() وhasSystemFeature(String) في فئة android.content.pm.PackageManager لمعرف التجميع نفسه.

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

7.1. الشاشة والرسومات

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

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

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

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

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

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

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

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

  • يجب أن تكون الأجهزة التي تم ضبط Configuration.uiMode فيها على أي قيمة غير UI_MODE_TYPE_WATCH، والتي تُبلغ عن حجم small للConfiguration.screenLayout، أبعادها 426 dp x ‏320 dp على الأقل.
  • يجب أن تكون الأجهزة التي تُبلغ عن حجم normal للشاشة Configuration.screenLayout أبعادها 480 نقطة لكل بوصة × 320 نقطة لكل بوصة على الأقل.
  • يجب أن تكون أبعاد الأجهزة التي تُبلغ عن حجم large للشاشة Configuration.screenLayout على الأقل 640 نقطة لكل بوصة × 480 نقطة لكل بوصة.
  • يجب أن تكون الأجهزة التي تُبلغ عن حجم xlarge للشاشة Configuration.screenLayout بدرجة دقة لا تقل عن 960 نقطة لكل بوصة × 720 نقطة لكل بوصة.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • يُعلِن التطبيق أنّه يمكن تغيير حجمه من خلال السمة android:resizeableActivity.
  • يعلن التطبيق عن android:minAspectRatio التي تحدّ من نسبة العرض إلى الارتفاع المسموح بها.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

‎7.1.4.1 OpenGL ES

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

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

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

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

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

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

• [C-3-1] يجب تصدير رموز الدوالّ المقابلة لهذه الإصدارات بالإضافة إلى رموز دوالّ OpenGL ES 2.0 في مكتبة libGLESv2.so.
• [SR] يُنصح بشدة بتوفّر إضافة 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، يجب أن تستوفي الشروط التالية:

• [SR] يُنصح بشدة بتضمين توافق مع Vulkan 1.1.

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

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

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

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

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

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

• [C-2-1] يجب عدم الإفصاح عن أي من مفاتيح تبديل أوضاع ميزات Vulkan (مثل android.hardware.vulkan.level وandroid.hardware.vulkan.version).
• [C-2-2] يجب عدم إدراج أي VkPhysicalDevice لواجهة برمجة التطبيقات الأصلية Vulkan vkEnumeratePhysicalDevices().

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

• [C-3-1] يجب أن يقدّم الدعم لأنواع الإشارة الخارجية وأنواع المعرّفات وإضافة VK_ANDROID_external_memory_android_hardware_buffer.SYNC_FD

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

يتضمّن Android عنصر TextureView الذي يتيح للمطوّرين دمج مواد OpenGL ES المُسرَّعة بالأجهزة مباشرةً كأهداف للعرض في التسلسل الهرمي لواجهة المستخدم.

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

• [C-0-3] يجب أن يكون متوافقًا مع واجهة برمجة التطبيقات TextureView API، ويجب أن يعرض سلوكًا متسقًا مع التنفيذ في Android.

7.1.4.5 شاشات النطاق اللوني الواسع

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

• [C-1-1] يجب أن يكون الجهاز مزوّدًا بشاشة تم ضبط ألوانها.
• [C-1-2] يجب أن تتضمّن الشاشة نطاق ألوان يغطي نطاق ألوان sRGB بالكامل في مساحة CIE 1931 xyY.
• [C-1-3] يجب أن يكون الجهاز مزوّدًا بشاشة تبلغ مساحة نطاق ألوانها% 90 على الأقل من نطاق DCI-P3 في مساحة CIE 1931 xyY.
• [C-1-4] يجب أن يكون متوافقًا مع OpenGL ES 3.1 أو 3.2 وأن يتم الإبلاغ عنه بشكل صحيح.
• [C-1-5] يجب الإعلان عن توفّر الإضافات EGL_KHR_no_config_context وEGL_EXT_pixel_format_float وEGL_KHR_gl_colorspace وEGL_EXT_gl_colorspace_scrgb وEGL_EXT_gl_colorspace_scrgb_linear وEGL_EXT_gl_colorspace_display_p3 وEGL_EXT_gl_colorspace_display_p3_linear وEGL_EXT_gl_colorspace_display_p3_passthrough.
• [C-SR] يُنصح بشدة بتوفير الدعم 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 استخدام شاشات ثانوية متوافقة مع 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] يجب تقديم إشارة واضحة إلى الإجراء الفردي الذي سيؤدي إلى بدء كل وظيفة. ومن الأمثلة على ذلك وضع رمز مرئي على الزر، أو عرض رمز البرنامج على جزء شريط التنقّل من الشاشة، أو توجيه المستخدم خلال عملية تجريبية إرشادية خطوة بخطوة أثناء تجربة الإعداد خارج العلبة.

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

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

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

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

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

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

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

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

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

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

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

• [C-6-1] يجب استخدام WindowInsets#getMandatorySystemGestureInsets() فقط للإبلاغ عن منطقة التعرّف على إيماءات Home.
• [C-6-2] يجب عدم اعتراض الإيماءات التي تبدأ داخل مستطيل استبعاد كما يقدّمها التطبيق المعروض في المقدّمة من خلال View#setSystemGestureExclusionRects()، ولكن خارج WindowInsets#getMandatorySystemGestureInsets()، وذلك لاستخدامها في وظيفة التنقّل ما دام مستطيل الاستبعاد مسموحًا به ضمن الحد الأقصى المسموح به للاستبعاد كما هو محدّد في مستندات View#setSystemGestureExclusionRects().
• [C-6-3] يجب إرسال حدث MotionEvent.ACTION_CANCEL إلى التطبيق المعروض في المقدّمة بعد بدء اعتراض اللمسات لتنفيذ إيماءة نظام، إذا سبق أن تم إرسال حدث MotionEvent.ACTION_DOWN إلى التطبيق المعروض في المقدّمة.
• [C-6-4] يجب أن توفّر ميزة للمستخدم للتبديل إلى تنقّل على الشاشة يستند إلى الأزرار (على سبيل المثال، في "الإعدادات").
• يجب أن توفّر وظيفة "الشاشة الرئيسية" من خلال التمرير سريعًا للأعلى من الحافة السفلية للاتجاه الحالي للشاشة.
• من المفترض أن توفّر وظيفة "التطبيقات المستخدَمة مؤخرًا" من خلال التمرير سريعًا للأعلى مع الاستمرار قبل تحرير الإصبع من الشاشة، وذلك من المنطقة نفسها التي يتم فيها استخدام إيماءة "الرجوع إلى الشاشة الرئيسية".
• يجب ألا تتأثر الإيماءات التي تبدأ داخل WindowInsets#getMandatorySystemGestureInsets() بمستطيلات الاستبعاد التي يوفّرها التطبيق الذي يعمل في المقدّمة من خلال View#setSystemGestureExclusionRects().

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

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

7.2.4. الإدخال من خلال شاشة تعمل باللمس

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

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

• يجب أن يتضمّن نظام إدخال مؤشر من نوع ما (إما مثل الماوس أو باللمس).
• يجب أن تتيح استخدام مؤشرات يتم تتبُّعها بشكل مستقل بالكامل.

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

• [C-1-1] يجب الإبلاغ عن TOUCHSCREEN_FINGER لحقل واجهة برمجة التطبيقات Configuration.touchscreen.
• [C-1-2] يجب الإبلاغ عن علامتَي ميزة android.hardware.touchscreen وandroid.hardware.faketouch.

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

• [C-2-1] يجب الإبلاغ عن علامات الميزات المناسبة android.hardware.touchscreen.multitouch وandroid.hardware.touchscreen.multitouch.distinct وandroid.hardware.touchscreen.multitouch.jazzhand التي تتوافق مع نوع الشاشة التي تعمل باللمس المحدّدة على الجهاز.

إذا كانت عمليات تنفيذ الأجهزة تعتمد على جهاز إدخال خارجي، مثل الماوس أو كرة التتبُّع (أي عدم لمس الشاشة مباشرةً) لإدخال البيانات على شاشة أساسية متوافقة مع Android واستيفاء متطلبات اللمس الزائف في الفقرة 7.2.5، يجب استيفاء الشروط التالية:

• [C-3-1] يجب عدم الإبلاغ عن أي ميزة تتضمّن علامة اختيار تبدأ بالرمز android.hardware.touchscreen.
• [C-3-2] يجب الإبلاغ عن android.hardware.faketouch فقط.
• [C-3-3] يجب الإبلاغ عن TOUCHSCREEN_NOTOUCH لحقل واجهة برمجة التطبيقات Configuration.touchscreen.

7.2.5. الإدخال باللمس الزائف

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

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

• يجب الإفصاح عن توافق التطبيق مع علامة ميزة android.hardware.faketouch.

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

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

إذا كانت عمليات تنفيذ الأجهزة تعلن عن توافقها مع android.hardware.faketouch.multitouch.distinct، يعني ذلك ما يلي:

• [C-2-1] يجب الإفصاح عن توفّر android.hardware.faketouch.
• [C-2-2] يجب أن يتيح التتبُّع الواضح لمدخلات مؤشر مستقلة أو أكثر.

إذا كانت عمليات تنفيذ الأجهزة تعلن عن توافقها مع android.hardware.faketouch.multitouch.jazzhand، يعني ذلك ما يلي:

• [C-3-1] يجب الإفصاح عن توافق التطبيق مع android.hardware.faketouch.
• [C-3-2] يجب أن يتيح الجهاز تتبُّعًا دقيقًا لخمسة إشارات (تتبُّع يد مكوّنة من أصابع) أو أكثر بشكل مستقل تمامًا.

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

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

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

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

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

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

‫1 KeyEvent

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

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

‫4 MotionEvent

‫1 MotionEvent

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

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

7.3. أجهزة الاستشعار

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

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

• [C-0-1] يجب الإبلاغ بدقة عن توفّر أدوات الاستشعار أو عدم توفّرها وفقًا لفئة android.content.pm.PackageManager.
• [C-0-2] يجب أن يعرض التطبيق قائمة دقيقة بأجهزة الاستشعار المتوافقة من خلال SensorManager.getSensorList() والطُرق المشابهة.
• [C-0-3] يجب أن تعمل بشكل معقول مع جميع واجهات برمجة التطبيقات الأخرى الخاصة بأجهزة الاستشعار (على سبيل المثال، من خلال عرض true أو false حسب الاقتضاء عندما تحاول التطبيقات تسجيل مستمعين، وعدم استدعاء مستمعي أجهزة الاستشعار عندما لا تكون أجهزة الاستشعار المقابلة متوفّرة، وما إلى ذلك).

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

• [C-1-1] يجب الإبلاغ عن جميع قياسات أجهزة الاستشعار باستخدام قيم النظام الدولي للوحدات (المقياس) ذات الصلة لكل نوع من أنواع أجهزة الاستشعار على النحو المحدّد في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
• [C-1-2] يجب الإبلاغ عن بيانات أجهزة الاستشعار بحد أقصى لمُدد الاستجابة يبلغ 100 ملي ثانية + 2 * sample_time في حال تدفّق بيانات أجهزة الاستشعار بحد أقصى لمُدد الاستجابة المطلوبة يبلغ 0 ملي ثانية عندما يكون معالج التطبيقات نشطًا. ولا يشمل هذا التأخير أي تأخيرات في الفلترة.
• [C-1-3] يجب الإبلاغ عن أول عيّنة من بيانات المستشعر في غضون 400 ملي ثانية + 2 * sample_time من وقت تفعيل المستشعر. من المقبول أن تكون دقة هذه العينة 0.
• [C-1-4] بالنسبة إلى أيّ واجهة برمجة تطبيقات يشير مستند حزمة تطوير البرامج (SDK) لنظام التشغيل Android إلى أنّها جهاز استشعار مستمر، يجب أن تقدّم عمليات تنفيذ الأجهزة بشكلٍ مستمر عيّنات بيانات دورية يجب أن يكون لها انحرافًا أقل من %3، حيث يتم تعريف الانحراف على أنّه التباين المعياري لفرق قيم الطابع الزمني المسجّلة بين الأحداث المتتالية.
• [C-1-5] يجب التأكّد من أنّ بث أحداث الاستشعار يجب ألا يمنع وحدة المعالجة المركزية للجهاز من الدخول في حالة تعليق أو الاستيقاظ من حالة تعليق.
• [C-1-6] يجب تسجيل وقت الحدث بالنانوثواني كما هو محدّد في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android، ما يمثّل وقت وقوع الحدث ويتم مزامنته مع الساعة SystemClock.elapsedRealtimeNano()‎.
• [C-SR] يُنصح بشدة بضبط خطأ مزامنة الطابع الزمني على أقل من 100 مللي ثانية، ويجب ضبط خطأ مزامنة الطابع الزمني على أقل من مللي ثانية واحدة.
• عند تفعيل عدة أدوات استشعار، يجب ألّا يتجاوز استهلاك الطاقة مجموع استهلاك الطاقة المسجَّل لكل أداة استشعار فردية.

القائمة أعلاه ليست شاملة، ويجب اعتبار السلوك المُسجَّل لحزمة SDK لنظام التشغيل Android ومستندات Android Open Source حول أجهزة الاستشعار موثوقًا به.

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

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

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

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

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

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

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

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

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

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

• [C-4-1] يجب عدم تضمين أي مَعلمات ثابتة محدّدة من المصنع في البيانات المقدَّمة.

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

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

7.3.1. مقياس التسارع

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

• [C-SR] يُنصح بشدة بتضمين مقياس تسارع ثلاثي المحاور.

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

• [C-1-1] يجب أن يكون الجهاز قادرًا على تسجيل الأحداث بمعدّل تكرار لا يقل عن 50 هرتز.
• [C-1-2] يجب تنفيذ أداة استشعار TYPE_ACCELEROMETER والإبلاغ عنها.
• [C-1-3] يجب أن تكون متوافقة مع نظام إحداثيات أدوات استشعار Android كما هو موضّح بالتفصيل في واجهات برمجة تطبيقات Android.
• [C-1-4] يجب أن يكون الجهاز قادرًا على قياس التسارع من السقوط الحر إلى أربع مرات قوة الجاذبية(4g) أو أكثر على أي محور.
• [C-1-5] يجب أن تكون درجة دقة الصورة 12 بت على الأقل.
• [C-1-6] يجب أن يكون التباين المعياري لا يزيد عن 0.05 متر في الثانية^، حيث يجب احتساب التباين المعياري لكل محور على أساس العيّنات التي تم جمعها على مدار فترة لا تقل عن 3 ثوانٍ بأعلى معدّل تحليل.
• [SR] يُنصح بشدة بتنفيذ أداة الاستشعار المركبة TYPE_SIGNIFICANT_MOTION.
• [SR] يُنصح بشدة بتنفيذ أداة الاستشعار TYPE_ACCELEROMETER_UNCALIBRATED والإبلاغ عنها. ننصح بشدة بتوافق أجهزة Android مع هذا الشرط حتى تتمكّن من الترقية إلى إصدار المنصة المستقبلي الذي قد يصبح فيه هذا الشرط مطلوبًا.
• يجب تنفيذ أدوات الاستشعار المركبة TYPE_SIGNIFICANT_MOTION وTYPE_TILT_DETECTOR وTYPE_STEP_DETECTOR وTYPE_STEP_COUNTER كما هو موضّح في مستند حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
• يجب أن تُبلغ عن الأحداث التي تصل إلى 200 هرتز على الأقل.
• يجب أن تكون درجة دقتها 16 بت على الأقل.
• يجب معايرة هذه الخصائص أثناء استخدامها إذا تغيّرت خلال دورة الاستخدام، ويجب تعويضها والحفاظ على مَعلمات التعويض بين عمليات إعادة تشغيل الجهاز.
• يجب أن يتم تصحيحها حسب درجة الحرارة.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن أداة تسارع 3 محاور وأيًا من أجهزة الاستشعار المركبة TYPE_SIGNIFICANT_MOTION وTYPE_TILT_DETECTOR وTYPE_STEP_DETECTOR وTYPE_STEP_COUNTER:

• [C-2-1] يجب أن يكون مجموع استهلاك الطاقة أقل من 4 ملي واط في أي وقت.
• يجب أن يكون كل منهما أقل من 2 ملي واط و0.5 ملي واط عندما يكون الجهاز في حالة ديناميكية أو ثابتة.

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

• [C-3-1] يجب تنفيذ أدات الاستشعار المركبة TYPE_GRAVITY وTYPE_LINEAR_ACCELERATION.
• [C-SR] يُنصح بشدة بتنفيذ أداة الاستشعار المركبة TYPE_GAME_ROTATION_VECTOR.

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

• [C-4-1] يجب استخدام أداة استشعار مركبة TYPE_ROTATION_VECTOR.

7.3.2. مقياس المغناطيسية

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

• [C-SR] يُنصح بشدة بتضمين مقياس مغناطيسي ثلاثي المحاور (بوصلة).

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

• [C-1-1] يجب تنفيذ أداة استشعار TYPE_MAGNETIC_FIELD.
• [C-1-2] يجب أن يكون الجهاز قادرًا على تسجيل الأحداث بمعدّل تكرار لا يقل عن 10 هرتز، ويجب أن يسجِّل الأحداث بمعدّل تكرار لا يقل عن 50 هرتز.
• [C-1-3] يجب أن تكون متوافقة مع نظام إحداثيات أدوات استشعار Android كما هو موضّح بالتفصيل في واجهات برمجة تطبيقات Android.
• [C-1-4] يجب أن يكون الجهاز قادرًا على قياس القيم بين -900 و+900 ميكرو تسلا على كل محور قبل الوصول إلى التشبع.
• [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-SR] ننصح بشدة بتنفيذ أداة الاستشعار 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] يُنصح بشدة بتضمين جهاز استقبال 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] يُنصح بشدة بمواصلة عرض النتائج العادية لموقع GPS/GNSS الجغرافي من خلال واجهات برمجة التطبيقات GNSS Location Provider API أثناء إجراء مكالمة هاتفية للطوارئ.
  • [C-SR] يُنصح بشدة بالإبلاغ عن قياسات GNSS من جميع المجموعات التي يتم تتبُّعها (كما هو موضّح في رسائل GnssStatus)، باستثناء SBAS.
  • [C-SR] يُنصح بشدة بالإبلاغ عن AGC ومعدّل تكرار قياس GNSS.
  • [C-SR] يُنصح بشدة بالإبلاغ عن جميع تقديرات الدقة (بما في ذلك الاتجاه والسرعة والقيمة العمودية) كجزء من كل موقع جغرافي لنظام تحديد المواقع العالمي (GPS) أو نظام تحديد المواقع العالمي (GNSS).
  • [C-SR] يُنصح بشدة بالإبلاغ عن قياسات نظام تحديد المواقع العالمي (GNSS) فور العثور عليها، حتى إذا لم يتم الإبلاغ عن موقع جغرافي تم احتسابه من نظام تحديد المواقع العالمي (GPS)/نظام تحديد المواقع العالمي (GNSS) بعد.
  • [C-SR] يُنصح بشدة بالإبلاغ عن نطاقات GNSS الزائفة ومعدّلات النطاقات الزائفة، والتي تكون كافية لاحتساب الموقع الجغرافي ضمن 20 مترًا والسرعة ضمن 0.2 متر في الثانية في ‎95% من الوقت على الأقل، وذلك في ظروف السماء المفتوحة بعد تحديد الموقع الجغرافي، أثناء الثبات أو التحرك بسرعة أقل من 0.2 متر في الثانية المربعة.

7.3.4. الجيروسكوب

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

• [C-SR] يُنصح بشدة بتضمين أداة استشعار جيروسكوب.

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

• [C-1-1] يجب أن يكون الجهاز قادرًا على تسجيل الأحداث بمعدّل تكرار لا يقل عن 50 هرتز.
• [C-1-2] يجب استخدام أداة استشعار TYPE_GYROSCOPE، ويُنصح بشدة باستخدام أداة استشعار TYPE_GYROSCOPE_UNCALIBRATED أيضًا.
• [C-1-4] يجب أن تكون درجة دقة هذا العنصر 12 بت أو أكثر، ومن المفترض أن تكون 16 بت أو أكثر.
• [C-1-5] يجب أن يكون مصحوبًا بمُعدِّل حرارة.
• [C-1-6] يجب معايرة الجهاز وتعويضه أثناء الاستخدام، والحفاظ على مَعلمات التعويض بين عمليات إعادة تشغيل الجهاز.
• [C-1-7] يجب ألا يزيد التباين عن 1e-7 rad^2 / s^2 لكل هرتز (التباين لكل هرتز أو rad^2 / s). يُسمح باختلاف التباين حسب معدّل أخذ العينات، ولكن يجب أن يكون مقيّدًا بهذه القيمة. بعبارة أخرى، إذا كنت تقيس التباين في أداة الاستشعار الدوراني بمعدّل أخذ عينات يبلغ 1 هرتز، يجب ألا يزيد عن 1e-7 rad^2/s^2.
• [SR] يُنصح بشدة بأن يكون خطأ المعايرة أقل من 0.01 راديان في الثانية عندما يكون الجهاز ثابتًا في درجة حرارة الغرفة.
• يجب أن تُبلغ عن الأحداث التي تصل إلى 200 هرتز على الأقل.

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

• [C-2-1] يجب تنفيذ أداة استشعار مركبة TYPE_ROTATION_VECTOR.

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

• [C-3-1] يجب تنفيذ أدات الاستشعار المركبة TYPE_GRAVITY وTYPE_LINEAR_ACCELERATION.
• [C-SR] يُنصح بشدة بتنفيذ أداة الاستشعار المركبة TYPE_GAME_ROTATION_VECTOR.

7.3.5. مقياس الضغط الجوي

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

• [C-SR] يُنصح بشدة بتضمين مقياس ضغط جوي (أداة استشعار الضغط الجوي المحيط).

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

• [C-1-1] يجب تنفيذ TYPE_PRESSURE sensor والإبلاغ عنه.
• [C-1-2] يجب أن يكون الجهاز قادرًا على إرسال الأحداث بمعدّل 5 هرتز أو أكثر.
• [C-1-3] يجب أن يكون مُعدَّلاً للحرارة.
• [SR] يُنصح بشدة بإمكانية تسجيل قياسات الضغط في النطاق من 300hPa إلى 1100hPa.
• يجب أن تكون الدقة المطلقة 1hPa.
• يجب أن تكون الدقة النسبية 0.12hPa على نطاق 20hPa (أي ما يعادل دقة متر واحد تقريبًا على نطاق 200 متر تقريبًا على مستوى سطح البحر).

7.3.6. مقياس درجة الحرارة

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

• [C-1-1] يجب تحديد SENSOR_TYPE_AMBIENT_TEMPERATURE لآلة استشعار درجة الحرارة المحيطة، ويجب أن تقيس الآلة درجة الحرارة المحيطة (درجة حرارة الغرفة أو المقصورة في المركبة) من حيث يتفاعل المستخدم مع الجهاز بالدرجات المئوية.

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

• [C-2-1] يجب عدم تحديد SENSOR_TYPE_AMBIENT_TEMPERATURE لجهاز استشعار الحرارة.

7.3.7. مقياس الإضاءة

• قد تتضمّن عمليات تنفيذ الأجهزة مقياسًا للضوء (أداة استشعار الضوء المحيط).

7.3.8. أداة استشعار التقارب

• قد تتضمّن عمليات تنفيذ الأجهزة أداة استشعار التقارب.

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

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

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] يُنصح بشدة بتوفير نطاق قياس 3 ديسيبل لا يقل عن% 80 من تردد Nyquist، ويجب أن يكون نطاق الضوضاء البيضاء ضمن هذا النطاق.
  • يجب أن يكون هناك انحراف عشوائي للتسارع أقل من 30 μg √Hz تم اختباره عند درجة حرارة الغرفة.
  • من المفترض أن يكون هناك تغيير في الانحياز مقابل درجة الحرارة بمقدار ‎1 mg/°C ±/‎- أو أقل.
  • يجب أن يكون خط أفضل توافق غير خطي بنسبة ≤ 0.5%، ويجب أن يكون تغيير الحساسية مقارنةً بالحرارة ≤ 0.03%/درجة مئوية.
  • يجب أن تكون حساسية المحاور المتقاطعة أقل من % 2.5 وأن يكون التباين في حساسية المحاور المتقاطعة أقل من% 0.2 في نطاق درجة حرارة تشغيل الجهاز.

• [C-2-2] يجب أن يكون لدى TYPE_ACCELEROMETER_UNCALIBRATED متطلبات الجودة نفسها التي يتطلبها TYPE_ACCELEROMETER.

• [C-2-3] يجب أن يتضمّن جهازك أداة استشعار TYPE_GYROSCOPE تستوفي الشروط التالية:

  • يجب أن يكون نطاق القياس بين -1000 و1000 دورة في الثانية على الأقل.
  • يجب أن تكون دقة القياس 16 LSB/dps على الأقل.
  • يجب أن يكون الحد الأدنى لعدد مرات القياس 12.5 هرتز أو أقل.
  • يجب أن يكون الحد الأقصى لعدد مرات القياس 400 هرتز أو أعلى، ويجب أن يكون متوافقًا مع SensorDirectChannel RATE_VERY_FAST.
  • يجب أن يكون التشويش في القياس أقل من 0.014 درجة في الثانية لكل جذر هرتز.
  • [C-SR] يُنصح بشدة بتوفير نطاق قياس 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] يُنصح بشدة بتوفير طيف للضوضاء البيضاء من 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 ملي ثانية من بعضها. يجب أن يكون الطابع الزمني للحدث المادي نفسه الذي يُبلغ عنه مقياس التسارع والجيروسكوب ضمن 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] يُنصح بشدة بتوفير إعداد للسماح للمستخدمين بتجاهل الإعدادات المفضّلة للتطبيق وفرض خطوة تأكيد دائمًا.
• [C-SR] يُنصح بشدة بتأمين إجراء التأكيد بحيث لا يمكن لخداع نظام التشغيل أو نواة النظام. على سبيل المثال، يعني ذلك أنّ إجراء التأكيد المستنِد إلى زرّ مادي يتم توجيهه من خلال دبوس إدخال/إخراج (GPIO) مخصّص للأغراض العامة للإدخال فقط في عنصر آمن (SE) لا يمكن تشغيله بأي وسيلة أخرى غير الضغط على زرّ مادي.
• [C-5-2] يجب أيضًا تنفيذ عملية مصادقة ضمنية (بدون خطوة تأكيد) تتوافق مع setConfirmationRequired(boolean)، والتي يمكن للتطبيقات ضبطها لاستخدامها في عمليات تسجيل الدخول.

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

• [C-SR] يُنصح بشدة بطلب تأكيد مقياس حيوي واحد فقط لكل عملية مصادقة (على سبيل المثال، إذا كان كل من أداتا استشعار بصمة الإصبع والوجه متوفّرتين على الجهاز، يجب إرسال 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-3] يجب تحديد معدّل لعدد المحاولات المسموح به لمدة 30 ثانية على الأقل بعد خمس محاولات خاطئة للتحقّق من المقاييس الحيوية، حيث تكون المحاولة الخاطئة هي محاولة ذات جودة تسجيل مناسبة (BIOMETRIC_ACQUIRED_GOOD) لا تتطابق مع المقاييس الحيوية المسجَّلة.
• [C-1-4] يجب منع إضافة مقاييس حيوية جديدة بدون إنشاء سلسلة ثقة أولاً من خلال مطالبة المستخدم بتأكيد بيانات اعتماد الجهاز الحالية أو إضافة بيانات اعتماد جديدة (رقم تعريف شخصي أو نمط أو كلمة مرور) يتم تأمينها من خلال تقنية TEE. يقدّم تنفيذ مشروع Android Open Source Mechanism في إطار العمل آلية لإجراء ذلك.
• [C-1-5] يجب إزالة جميع البيانات البيومترية القابلة للتحديد الخاصة بالمستخدم بالكامل عند إزالة حسابه (بما في ذلك من خلال إعادة الضبط على الإعدادات الأصلية).
• [C-1-6] يجب الالتزام بالعلامة الفردية للمقياس الحيوي (مثل DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT أو DevicePolicymanager.KEYGUARD_DISABLE_FACE أو DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
• [C-1-7] يجب أن يطلب التطبيق من المستخدم المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) مرة واحدة كل 24 ساعة أو أقل للأجهزة الجديدة التي تعمل بالإصدار 10 من Android، ومرة واحدة كل 72 ساعة أو أقل للأجهزة التي يتم ترقيتها من إصدار أقدم من Android.

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

  • مهلة عدم النشاط لمدة 4 ساعات
  • 3 محاولات مصادقة بالمقاييس الحيوية غير ناجحة
  • تتم إعادة ضبط فترة الانتظار في حالة عدم النشاط وعدد عمليات المصادقة غير الناجحة بعد أي تأكيد ناجح لبيانات اعتماد الجهاز.

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

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

• [C-2-1] يجب استيفاء جميع متطلبات الفئة 1 أعلاه.
• [C-2-2] يجب ألا يزيد معدّل قبول عمليات التزوير والتصيّد الاحتيالي عن% 20، وذلك وفقًا لبروتوكولات اختبار المقاييس الحيوية في Android.
• [C-2-3] يجب إجراء عملية المطابقة البيومترية في بيئة تنفيذ معزولة خارج مساحة المستخدم أو مساحة نواة Android، مثل بيئة التنفيذ الموثوقة (TEE)، أو على شريحة تتضمّن قناة آمنة تؤدي إلى بيئة التنفيذ المعزولة.
• [C-2-4] يجب أن تكون جميع البيانات التعريفية مشفَّرة وموثَّقة بشكل تشفير بحيث لا يمكن الحصول عليها أو قراءتها أو تغييرها خارج بيئة التنفيذ المعزولة أو شريحة تتضمّن قناة آمنة تؤدي إلى بيئة التنفيذ المعزولة كما هو موضّح في إرشادات التنفيذ على الموقع الإلكتروني لمشروع Android Open Source Project.
• [C-2-5] بالنسبة إلى المقاييس الحيوية المستندة إلى الكاميرا، أثناء عملية المصادقة أو التسجيل المستندة إلى المقاييس الحيوية:
  • يجب تشغيل الكاميرا في وضع يمنع قراءة إطارات الكاميرا أو تغييرها خارج بيئة التنفيذ المعزولة أو شريحة تتضمّن قناة آمنة تؤدي إلى بيئة التنفيذ المعزولة.
  • بالنسبة إلى حلول الكاميرا الواحدة ذات الإضاءة الملوّنة، يمكن قراءة لقطات الكاميرا خارج بيئة التنفيذ المعزولة لدعم عمليات مثل المعاينة للتسجيل، ولكن يجب ألّا تكون قابلة للتغيير.
• [C-2-6] يجب عدم السماح للتطبيقات التابعة لجهات خارجية بالتمييز بين عمليات التسجيل بالمقاييس الحيوية الفردية.
• [C-2-7] يجب عدم السماح بالوصول غير المشفَّر إلى البيانات الحيوية القابلة للتحديد أو أي بيانات مشتقة منها (مثل البيانات المضمَّنة) إلى معالج التطبيقات خارج سياق بيئة التنفيذ الموثوقة.

• [C-2-8] يجب أن يتضمّن مسار معالجة آمنًا بحيث لا تسمح أي عملية اختراق لنظام التشغيل أو النواة بإدخال البيانات مباشرةً لمصادقة المستخدم بشكل زائف.

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

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

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

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

7.3.12. أداة استشعار الوضعية

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

• قد تتيح استخدام أداة استشعار الوضع بـ 6 درجات من الحرية.

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

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

7.3.13. أداة استشعار زاوية المفصل

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

• [C-1-1] يجب تنفيذ TYPE_HINGLE_ANGLE والإبلاغ عنه.
• [C-1-2] يجب أن يتيح الجهاز قراءة قياسَين على الأقل بين 0 و360 درجة (بما في ذلك 0 و360 درجة).
• [C-1-3] يجب عرض مستشعر تنشيط لـ getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

7.4. إمكانية الوصول إلى البيانات

7.4.1. الاتصالات الهاتفية

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

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

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

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

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

• [C-2-1] يجب تنفيذ واجهات برمجة التطبيقات الكاملة كعمليات لا تتطلّب تدخلًا.

إذا كانت عمليات تنفيذ الأجهزة تتيح استخدام شرائح eUICC أو شرائح eSIM/شرائح SIM المضمّنة وتتضمن آلية خاصة إتاحة وظائف شرائح eSIM للمطوّرين التابعين لجهات خارجية، يجب أن تستوفي المتطلبات التالية:

• [C-3-1] يجب تقديم تنفيذ كامل EuiccManager API.

7.4.1.1. توافق حظر الأرقام

إذا أبلغت عمليات تنفيذ الأجهزة عن android.hardware.telephony feature، يعني ذلك ما يلي:

• [C-1-1] يجب أن تتضمّن ميزة حظر الأرقام
• [C-1-2] يجب تنفيذ BlockedNumberContract وواجهة برمجة التطبيقات المقابلة لها بالكامل على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK).
• [C-1-3] يجب حظر جميع المكالمات والرسائل الواردة من رقم هاتف في BlockedNumberProvider بدون أي تفاعل مع التطبيقات. الاستثناء الوحيد هو عند رفع حظر الأرقام مؤقتًا كما هو موضّح في مستندات حِزم تطوير البرامج (SDK).
• [C-1-4] يجب عدم الكتابة إلى مقدّم سجلّ المكالمات في النظام الأساسي لمكالمة محظورة.
• [C-1-5] يجب عدم الكتابة إلى مزوّد خدمة الاتصال الهاتفي بشأن رسالة محظورة.
• [C-1-6] يجب توفير واجهة مستخدم لإدارة الأرقام المحظورة، والتي يتم فتحها باستخدام النية التي تعرضها طريقة TelecomManager.createManageBlockedNumbersIntent().
• [C-1-7] يجب عدم السماح للمستخدمين الثانويين بعرض الأرقام المحظورة أو تعديلها على الجهاز لأنّ نظام Android يفترض أنّ المستخدم الأساسي يتحكّم بشكل كامل في خدمات الهاتف، وهي نسخة واحدة على الجهاز. يجب إخفاء جميع عناصر واجهة المستخدم ذات الصلة بعملية الحظر للمستخدمين الثانويين، ويجب الالتزام بقائمة المستخدمين المحظورين.
• من المفترض نقل الأرقام المحظورة إلى مقدّم الخدمة عند تحديث الجهاز إلى Android 7.0.

7.4.1.2. Telecom API

إذا أبلغت عمليات تنفيذ الأجهزة عن android.hardware.telephony، يعني ذلك ما يلي:

• [C-1-1] يجب أن تتوافق مع واجهات برمجة تطبيقات ConnectionService الموضّحة في حزمة تطوير البرامج (SDK).
• [C-1-2] يجب عرض مكالمة واردة جديدة وتوفير عنصر تحكم للمستخدم لقبول المكالمة الواردة أو رفضها عندما يكون المستخدم في مكالمة جارية من خلال تطبيق تابع لجهة خارجية لا يتيح ميزة الانتظار المحدّدة من خلال CAPABILITY_SUPPORT_HOLD.
• [C-1-3] يجب أن يتضمّن التطبيق فئة InCallService.

• [C-SR] يُنصح بشدة بإعلام المستخدم بأنّ الردّ على مكالمة واردة سيؤدي إلى إنهاء مكالمة جارية.

  يستوفي تطبيق AOSP هذه المتطلبات من خلال إشعار يُعلم المستخدم بأنّ الردّ على مكالمة واردة سيؤدي إلى إنهاء المكالمة الأخرى.

• [C-SR] يُنصح بشدة بتثبيت تطبيق الاتصال التلقائي الذي يعرض إدخال سجلّ المكالمات واسم تطبيق تابع لجهة خارجية في سجلّ المكالمات عندما يضبط التطبيق التابع لجهة خارجية مفتاح الإضافات EXTRA_LOG_SELF_MANAGED_CALLS على PhoneAccount إلى true.

• [C-SR] يُنصح بشدة بمعالجة حدثَي KEYCODE_MEDIA_PLAY_PAUSE وKEYCODE_HEADSETHOOK لسماعة الرأس الصوتية في واجهات برمجة التطبيقات android.telecom على النحو التالي:
  • اتصل بالرقم Connection.onDisconnect() عند رصد ضغطة قصيرة على الحدث الرئيسي أثناء مكالمة جارية.
  • اتصل بالرقم Connection.onAnswer() عند رصد ضغطة قصيرة على الحدث الرئيسي أثناء مكالمة واردة.
  • اتصل بالرقم Connection.onReject() عند رصد الضغط مع الاستمرار على الحدث الرئيسي أثناء مكالمة واردة.
  • فعِّل أو أوقِف ميزة كتم الصوت في CallAudioState.

7.4.2. معيار IEEE 802.11 (لشبكات Wi-Fi)

عمليات التنفيذ على الأجهزة:

• يجب أن تتضمّن إتاحة استخدام شكل واحد أو أكثر من 802.11.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة 802.11 وتعرض الوظيفة لتطبيق تابع لجهة خارجية، يجب أن تستوفي المتطلبات التالية:

• [C-1-1] يجب تنفيذ واجهة برمجة تطبيقات Android المقابلة.
• [C-1-2] يجب الإبلاغ عن علامة ميزة الجهاز android.hardware.wifi.
• [C-1-3] يجب تنفيذ واجهة برمجة التطبيقات للبث المتعدد على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK).
• [C-1-4] يجب أن يكون متوافقًا مع نظام أسماء النطاقات ذي البث المتعدد (mDNS) ويجب عدم فلترة حزم mDNS (224.0.0.251) في أي وقت من التشغيل، بما في ذلك:
  • حتى عندما تكون الشاشة غير نشطة
  • لعمليات تنفيذ أجهزة Android Television، حتى في حالات الطاقة الاحتياطية
• [C-1-5] يجب عدم التعامل مع طلب بيانات من واجهة برمجة التطبيقات WifiManager.enableNetwork() كإشارة كافية لتبديل Network النشط حاليًا والذي يتم استخدامه تلقائيًا للزيارات الواردة إلى التطبيق ويتم إرجاعه من خلال طرق واجهة برمجة التطبيقات ConnectivityManager مثل getActiveNetwork وregisterDefaultNetworkCallback. بعبارة أخرى، يجوز لهم إيقاف إمكانية الوصول إلى الإنترنت المقدَّمة من أي مزوّد شبكة آخر (مثل بيانات الجوّال) فقط إذا تحقّقوا بنجاح من أنّ شبكة Wi-Fi توفّر إمكانية الوصول إلى الإنترنت.
• [C-1-6] يُنصح بشدة بإعادة تقييم إمكانية الوصول إلى الإنترنت على Network عند استدعاء طريقة واجهة برمجة التطبيقات ConnectivityManager.reportNetworkConnectivity()، وبعد أن يحدِّد التقييم أنّ Network الحالية لم تعُد توفّر إمكانية الوصول إلى الإنترنت، يجب التبديل إلى أي شبكة أخرى متاحة (مثل بيانات الجوّال) توفّر إمكانية الوصول إلى الإنترنت.
• [C-SR] يُنصح بشدة بتعشيب عنوان MAC المصدر ورقم التسلسل لإطارات طلب الاستكشاف، مرة واحدة في بداية كل عملية بحث، عندما يكون STA غير متصل.
  • يجب أن تستخدم كل مجموعة من إطارات طلبات الاستكشاف التي تتضمّن عملية فحص واحدة عنوان MAC واحدًا متسقًا (يجب عدم توزيع عنوان MAC عشوائيًا في منتصف عملية الفحص).
  • يجب تكرار الرقم التسلسلي لطلب الفحص كالمعتاد (بشكل تسلسلي) بين طلبات الفحص في عملية الفحص.
  • يجب أن يكون رقم تسلسل طلب الاستكشاف عشوائيًا بين آخر طلب استكشاف لعملية فحص وأول طلب استكشاف لعملية الفحص التالية.
• [C-SR] يُنصح بشدة، عندما يكون STA غير متصل، بالسماح بالعناصر التالية فقط في إطارات طلب الاستكشاف:
  • مجموعة مَعلمات SSID (0)
  • مجموعة مَعلمات DS (3)

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة وضع توفير الطاقة في Wi-Fi كما هو محدّد في معيار IEEE 802.11، يجب أن تستوفي ما يلي:

• [C-3-1] يجب إيقاف وضع توفير الطاقة في Wi-Fi عندما يحصل التطبيق على قفل WIFI_MODE_FULL_HIGH_PERF أو قفل WIFI_MODE_FULL_LOW_LATENCY من خلال واجهات برمجة التطبيقات WifiManager.createWifiLock() وWifiManager.WifiLock.acquire() وكان القفل مفعّلاً.
• [C-3-2] يجب أن يكون متوسّط وقت الاستجابة لرحلة الذهاب والعودة بين الجهاز ونقطة وصول عندما يكون الجهاز في وضع "قفل وقت الاستجابة المنخفض لشبكة Wi-Fi" (WIFI_MODE_FULL_LOW_LATENCY) أقصر من وقت الاستجابة أثناء وضع "قفل الأداء العالي لشبكة Wi-Fi" (WIFI_MODE_FULL_HIGH_PERF).
• [C-SR] يُنصح بشدة بتقليل وقت الاستجابة لإرسال الرسائل واستقبالها عبر شبكة 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 في الوقت نفسه.

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" وتعرض الوظيفة للتطبيقات التابعة لجهات خارجية، يجب أن تستوفي الشروط التالية:

• [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 ما لم تكن عملية تحديد النطاق قيد التنفيذ أو كان مسار البيانات قيد التشغيل (لا يُتوقّع إنشاء عنوان عشوائي طالما أنّ مسار البيانات نشط).

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة ميزتَي "الاستشعار عبر Wi-Fi" و"تحديد الموقع الجغرافي عبر Wi-Fi" كما هو موضّح في الفقرة 7.4.2.5 وتوفّر هذه الوظائف للتطبيقات التابعة لجهات خارجية، يجب أن تستوفي الشروط التالية:

• [C-2-1] يجب تنفيذ واجهات برمجة تطبيقات الاستكشاف المستندة إلى الموقع الجغرافي: setRangingEnabled وsetMinDistanceMm وsetMaxDistanceMm وonServiceDiscoveredWithinRange.

7.4.2.4. Wi-Fi Passpoint

إذا كانت عمليات تنفيذ الأجهزة تتضمّن توافقًا مع معيار 802.11 (Wi-Fi)، يجب أن تستوفي الشروط التالية:

• يجب أن تتضمّن ميزة Wi-Fi Passpoint.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة Wi-Fi Passpoint، يجب أن تستوفي ما يلي:

• [C-1-2] يجب تنفيذ واجهات برمجة التطبيقات WifiManager ذات الصلة ببرنامج Passpoint كما هو موضّح في مستندات حزمة تطوير البرامج (SDK).
• [C-1-3] يجب أن يكون متوافقًا مع معيار IEEE 802.11u، خاصةً في ما يتعلق باكتشاف الشبكة واختيارها، مثل خدمة الإعلانات الشاملة (GAS) وبروتوكول طلب شبكة الوصول (ANQP).

في المقابل، إذا كانت عمليات تنفيذ الأجهزة لا تتضمّن إتاحة Wi-Fi Passpoint:

• [C-2-1] يجب أن يؤدي تنفيذ واجهات برمجة التطبيقات WifiManager ذات الصلة ببرنامج Passpoint إلى طرح UnsupportedOperationException.

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 عليها مرتبطة بنقطة وصول.

7.4.2.6. نقل بيانات ميزة "إبقاء الاتصال بالإنترنت" في Wi-Fi

عمليات التنفيذ على الأجهزة:

• يجب أن تتضمّن إتاحة ميزة "إبقاء الاتصال بالإنترنت" في شبكة Wi-Fi.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة ميزة "إبقاء الاتصال بالإنترنت" في Wi-Fi وتوفير هذه الميزة للتطبيقات التابعة لجهات خارجية، يجب أن تستوفي المتطلبات التالية:

• [C-1-1] يجب أن تكون متوافقة مع واجهة برمجة التطبيقات SocketKeepAlive.

• [C-1-2] يجب أن يتيح الجهاز ثلاث خانات keepalive متزامنة على الأقل عبر شبكة Wi-Fi وخانة keepalive واحدة على الأقل عبر شبكة الجوّال.

إذا لم تتضمّن عمليات تنفيذ الأجهزة ميزة تفريغ عمليات الاحتفاظ بحالة الاتصال بشبكة 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.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] يجب تفعيل واجهات برمجة تطبيقات Bluetooth المستندة إلى GATT (ملف الخصائص العام) كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) وandroid.bluetooth.
• [C-3-3] يجب الإبلاغ عن القيمة الصحيحة لـ BluetoothAdapter.isOffloadedFilteringSupported() للإشارة إلى ما إذا كان قد تم تنفيذ منطق الفلترة لفئات واجهة برمجة التطبيقات ScanFilter.
• [C-3-4] يجب الإبلاغ عن القيمة الصحيحة لسمة BluetoothAdapter.isMultipleAdvertisementSupported() للإشارة إلى ما إذا كان الإعلان المنخفض الطاقة متوافقًا.
• [C-3-5] يجب تنفيذ مهلة لعنوان RPA لا تزيد عن 15 دقيقة وتبديل العنوان عند انتهاء المهلة لحماية خصوصية المستخدم عندما يستخدم الجهاز تقنية BLE بشكل نشط للبحث أو الإعلان. لمنع هجمات التوقيت، يجب أيضًا اختيار فواصل المهلة عشوائيًا بين 5 و15 دقيقة.
• يجب أن تتيح واجهة برمجة التطبيقات إمكانية نقل منطق الفلترة إلى شريحة البلوتوث عند تنفيذ ScanFilter API.
• يجب أن تتيح ميزة "البحث المجمّع" نقل البيانات إلى مجموعة شرائح البلوتوث.
• يجب أن تتيح عرض إعلانات متعددة مع 4 خانات على الأقل.

إذا كانت عمليات تنفيذ الأجهزة متوافقة مع تقنية Bluetooth LE وتستخدمها للبحث عن الموقع الجغرافي، يجب أن تستوفي المتطلبات التالية:

• [C-4-1] يجب توفير عنصر تحكم للمستخدم لتفعيل/إيقاف القيمة المقروءة من خلال System API BluetoothAdapter.isBleScanAlwaysAvailable().

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة تقنية Bluetooth LE وملف تعريف سماعات الأذن الطبية، كما هو موضّح في مقالة إتاحة الصوت في سماعات الأذن الطبية باستخدام تقنية Bluetooth LE، يجب استيفاء الشروط التالية:

• [C-5-1] يجب عرض القيمة true لـ BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).

7.4.4. تقنية الاتصال القصير المدى

عمليات التنفيذ على الأجهزة:

• يجب أن تتضمّن وحدة إرسال واستقبال وأجهزة ذات صلة بتقنية الاتصال القصير المدى (NFC).
• [C-0-1] يجب تنفيذ واجهات برمجة التطبيقات android.nfc.NdefMessage وandroid.nfc.NdefRecord حتى إذا لم تتضمّن إتاحة استخدام NFC أو الإفصاح عن ميزة android.hardware.nfc لأنّ الفئات تمثّل تنسيقًا لتمثيل البيانات لا يعتمد على البروتوكول.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن أجهزة NFC وتخطط لتوفيرها للتطبيقات التابعة لجهات خارجية، يجب أن:

• [C-1-1] يجب الإبلاغ عن ميزة android.hardware.nfc من طريقة android.content.pm.PackageManager.hasSystemFeature().
• يجب أن يكون الجهاز قادرًا على قراءة رسائل NDEF وكتابتها من خلال معايير NFC التالية كما هو موضّح أدناه:
• [C-1-2] يجب أن يكون الجهاز قادرًا على العمل كقارئ/كاتب وفقًا لمواصفات NFC Forum (على النحو المحدّد في المواصفة الفنية NFCForum-TS-DigitalProtocol-1.0) من خلال معايير NFC التالية:
  • NfcA (ISO14443-3A)
  • ‫NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • أنواع علامات NFC التي حدّدها المنتدى 1 و2 و3 و4 و5

• [SR] يُنصح بشدة بأن يكون الجهاز قادرًا على قراءة وكتابة رسائل NDEF بالإضافة إلى البيانات الأولية من خلال معايير NFC التالية. يُرجى العلم أنّه على الرغم من أنّ معايير NFC مُدرجة على أنّها "مُستحسَنة بشدة"، من المخطَّط أن يتم تغييرها في تعريف التوافق لإصدار مستقبلي إلى "يجب". هذه المعايير اختيارية في هذا الإصدار، ولكن ستكون مطلوبة في الإصدارات المستقبلية. ننصح بشدة بتلبية هذه المتطلبات الآن على الأجهزة الحالية والجديدة التي تعمل بهذا الإصدار من Android حتى تتمكّن من الترقية إلى إصدارات المنصة المستقبلية.

• [C-1-13] يجب إجراء استطلاع لجميع التكنولوجيات المتوافقة أثناء وضع رصد NFC.

• يجب أن يكون الجهاز في وضع اكتشاف NFC عندما يكون مفعَّلاً والشاشة نشطة وشاشة القفل مفتوحة.
• يجب أن يكون قادرًا على قراءة الرمز الشريطي وعنوان URL (إذا كان مُرمّزًا) لمنتجات الرمز الشريطي NFC من Thinfilm.

يُرجى العلم أنّ الروابط المتاحة للجميع غير متاحة لمواصفات 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 فقط على شبكة إيثرنت.

إذا كانت عمليات تنفيذ الأجهزة تتيح استخدام بيانات الجوّال، يجب أن:

• [C-3-1] يجب أن يكون الجهاز متوافقًا مع بروتوكول IPv6 (IPv6 فقط وربما الإصدار المزدوج) على شبكة الجوّال.

إذا كانت عمليات تنفيذ الأجهزة متوافقة مع أكثر من نوع شبكة واحد (مثل Wi-Fi وبيانات شبكة الجوّال)، يتم تنفيذ ما يلي:

• [C-4-1] يجب استيفاء المتطلبات المذكورة أعلاه في كل شبكة في الوقت نفسه عندما يكون الجهاز متصلاً في الوقت نفسه بأكثر من نوع شبكة واحد.

7.4.5.3. المداخل المشروط الوصول إليها

يشير مدخل الشبكة المشروط الوصول إليها إلى شبكة تتطلب تسجيل الدخول للوصول إلى الإنترنت.

إذا كانت عمليات تنفيذ الأجهزة توفّر تنفيذًا كاملاً android.webkit.Webview API، فإنّها:

• [C-1-1] يجب توفير تطبيق بوابة إلكترونية لمعالجة النية ACTION_CAPTIVE_PORTAL_SIGN_IN وعرض صفحة تسجيل الدخول إلى البوابة الإلكترونية، وذلك من خلال إرسال هذه النية عند الطلب إلى System API ConnectivityManager#startCaptivePortalApp(Network, Bundle).
• [C-1-2] يجب أن يتم رصد بوابات الربط ويجب أن يتيح التطبيق تسجيل الدخول من خلال بوابة الربط عندما يكون الجهاز متصلاً بأي نوع من الشبكات، بما في ذلك شبكة الجوّال أو شبكة Wi-Fi أو إيثرنت أو البلوتوث.
• [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() القيمة "صحيح".

7.4.7. توفير البيانات

إذا كانت عمليات تنفيذ الأجهزة تتضمّن اتصالاً بمقدار محدّد، تكون على النحو التالي:

• [SR] يُنصح بشدة بتوفير وضع توفير البيانات.

إذا كانت عمليات تنفيذ الأجهزة توفّر وضع توفير البيانات، يجب أن:

• [C-1-1] يجب أن تتوافق مع جميع واجهات برمجة التطبيقات في فئة ConnectivityManager كما هو موضّح في مستندات حزمة تطوير البرامج (SDK)

إذا لم توفّر عمليات تنفيذ الأجهزة وضع "توفير البيانات"، يجب أن تستوفي المتطلبات التالية:

• [C-2-1] يجب عرض القيمة RESTRICT_BACKGROUND_STATUS_DISABLED للعنصر ConnectivityManager.getRestrictBackgroundStatus()
• [C-2-2] يجب عدم بث ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

7.4.8. العناصر الآمنة

إذا كانت عمليات تنفيذ الأجهزة متوافقة مع العناصر الآمنة المتوافقة مع Open Mobile API وتوفّرها للتطبيقات التابعة لجهات خارجية، فإنّها:

• [C-1-1] يجب إدراج أدوات قراءة العناصر الآمنة المتاحة من خلال واجهة برمجة التطبيقات android.se.omapi.SEService.getReaders().

• [C-1-2] يجب الإفصاح عن علامات الميزات الصحيحة من خلال android.hardware.se.omapi.uicc للجهاز الذي يتضمّن عناصر آمنة مستندة إلى شريحة UICC، وandroid.hardware.se.omapi.ese للجهاز الذي يتضمّن عناصر آمنة مستندة إلى شريحة eSE، وandroid.hardware.se.omapi.sd للجهاز الذي يتضمّن عناصر آمنة مستندة إلى شريحة SD.

7.5. الكاميرات

إذا كانت عمليات تنفيذ الأجهزة تتضمّن كاميرا واحدة على الأقل، يجب أن تستوفي الشروط التالية:

• [C-1-1] يجب الإفصاح عن علامة ميزة android.hardware.camera.any.
• [C-1-2] يجب أن يكون من الممكن للتطبيق تخصيص 3 صور نقطية RGBA_8888 في الوقت نفسه مساوية لحجم الصور التي تنتجها أداة استشعار الكاميرا ذات الدقة الأعلى على الجهاز، وذلك عندما تكون الكاميرا مفتوحة بغرض المعاينة الأساسية وتصوير الصور الثابتة.
• [C-1-3] يجب التأكّد من أنّ تطبيق الكاميرا التلقائي المثبَّت مسبقًا الذي يعالج النوايا MediaStore.ACTION_IMAGE_CAPTURE أو MediaStore.ACTION_IMAGE_CAPTURE_SECURE أو MediaStore.ACTION_VIDEO_CAPTURE هو المسؤول عن إزالة الموقع الجغرافي للمستخدم في البيانات الوصفية للصورة قبل إرسالها إلى التطبيق المستلِم عندما لا يتضمّن التطبيق المستلِم ACCESS_FINE_LOCATION.

7.5.1. الكاميرا الخلفية

الكاميرا الخلفية هي كاميرا موجودة على جانب الجهاز المقابل للشاشة، أي أنها تلتقط صورًا للمشاهد على الجانب البعيد من الجهاز، مثل الكاميرا التقليدية.

عمليات التنفيذ على الأجهزة:

• يجب أن تتضمّن كاميرا خلفية.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن كاميرا خلفية واحدة على الأقل، يجب استيفاء الشروط التالية:

• [C-1-1] يجب الإبلاغ عن علامتَي الخيار android.hardware.camera وandroid.hardware.camera.any.
• [C-1-2] يجب أن تكون درجة دقة الصورة 2 ميغابكسل على الأقل.
• يجب أن يتضمّن برنامج تشغيل الكاميرا ميزة التركيز التلقائي بالأجهزة أو بالبرامج (بشكل شفاف لبرنامج التطبيق).
• قد تحتوي على أجهزة ذات تركيز ثابت أو ميزة "عمق مجال ممتد".
• قد تتضمّن وميضًا.

إذا كانت الكاميرا تتضمّن فلاشًا:

• [C-2-1] يجب ألّا يكون مصباح الفلاش مضاءً أثناء تسجيل مثيل android.hardware.Camera.PreviewCallback على سطح معاينة الكاميرا، ما لم يفعّل التطبيق الفلاش صراحةً من خلال تفعيل السمتَين FLASH_MODE_AUTO أو FLASH_MODE_ON لعنصر Camera.Parameters. يُرجى العِلم أنّ هذا القيد لا ينطبق على تطبيق كاميرا النظام المضمّن في الجهاز، بل على التطبيقات التابعة لجهات خارجية فقط التي تستخدم Camera.PreviewCallback.

7.5.2. الكاميرا الأمامية

الكاميرا الأمامية هي كاميرا موجودة على جانب الجهاز نفسه الذي تظهر عليه الشاشة، أي كاميرا تُستخدَم عادةً لتصوير المستخدم، مثل مكالمات الفيديو والتطبيقات المشابهة.

عمليات التنفيذ على الأجهزة:

• قد تتضمّن كاميرا أمامية.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن كاميرا أمامية واحدة على الأقل، يجب استيفاء الشروط التالية:

• [C-1-1] يجب الإبلاغ عن علامتَي الخيار android.hardware.camera.any وandroid.hardware.camera.front.
• [C-1-2] يجب أن تكون درجة دقة الفيديوهات على الأقل VGA (640x480 بكسل).
• [C-1-3] يجب عدم استخدام الكاميرا الأمامية كإعداد تلقائي لواجهة برمجة التطبيقات Camera API، ويجب عدم ضبط واجهة برمجة التطبيقات لمعالجة الكاميرا الأمامية على أنّها الكاميرا الخلفية التلقائية، حتى إذا كانت الكاميرا الوحيدة على الجهاز.
• [C-1-4] يجب أن تكون معاينة الكاميرا معكوسة أفقيًا بالنسبة إلى الاتجاه الذي يحدّده التطبيق عندما يطلب التطبيق الحالي صراحةً تدوير شاشة الكاميرا من خلال طلب إلى طريقة android.hardware.Camera.setDisplayOrientation(). في المقابل، يجب أن تتم عكس المعاينة على طول المحور الأفقي التلقائي للجهاز عندما لا يطلب التطبيق الحالي صراحةً تدوير شاشة الكاميرا من خلال طلب إلى طريقة android.hardware.Camera.setDisplayOrientation().
• [C-1-5] يجب عدم تكرار صور الثابتة أو أحداث الفيديو النهائية التي تم التقاطها والتي يتم عرضها في عمليات استدعاء التطبيق أو تخزينها في مساحة تخزين الوسائط.
• [C-1-6] يجب أن تعكس الصورة المعروضة في معاينة المشاركة بالطريقة نفسها التي يتم بها بث صورة معاينة الكاميرا.
• قد تتضمّن ميزات (مثل التركيز التلقائي والفلاش وما إلى ذلك) متاحة للكاميرات الخلفية كما هو موضّح في الفقرة 7.5.1.

إذا كان بإمكان المستخدم تدوير عمليات تنفيذ الأجهزة (مثلاً تلقائيًا من خلال مقياس تسارع أو يدويًا من خلال إدخال المستخدم):

• [C-2-1] يجب أن تكون معاينة الكاميرا مصغّرة أفقيًا بالنسبة إلى الاتجاه الحالي للجهاز.

7.5.3. الكاميرا الخارجية

عمليات التنفيذ على الأجهزة:

• قد تتضمّن إتاحة استخدام كاميرا خارجية قد لا تكون متصلة دائمًا.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية استخدام كاميرا خارجية، يجب أن تستوفي الشروط التالية:

• [C-1-1] يجب الإفصاح عن علامتَي ميزة المنصة android.hardware.camera.external وandroid.hardware camera.any.
• [C-1-2] يجب أن يكون متوافقًا مع فئة USB Video Class (UVC 1.0 أو إصدار أحدث) في حال توصيل الكاميرا الخارجية من خلال منفذ مضيف USB.
• [C-1-3] يجب اجتياز اختبارات مجموعة اختبار التوافق (CTS) للكاميرا مع توصيل جهاز كاميرا خارجي. تتوفّر تفاصيل اختبار مجموعة أدوات اختبار التوافق (CTS) للكاميرا على source.android.com.
• يجب أن تتيح ضغط الفيديوهات، مثل MJPEG، لنقل أحداث البث غير المشفَّرة العالية الجودة (أي أحداث بث الصور الأولية أو المضغوطة بشكل مستقل).
• قد تتيح استخدام كاميرات متعددة.
• قد تتيح ميزة ترميز الفيديو المستند إلى الكاميرا.

في حال توفّر ميزة ترميز الفيديو بالاستناد إلى الكاميرا:

• [C-2-1] يجب أن يكون من الممكن تنفيذ بث غير مُشفَّر أو MJPEG متزامن (بدقة QVGA أو أعلى).

7.5.4. سلوك Camera API

يتضمّن نظام التشغيل Android حِزمتَي واجهة برمجة تطبيقات للوصول إلى الكاميرا، وتعرض واجهة برمجة التطبيقات android.hardware.camera2 API الأحدث عناصر التحكّم في الكاميرا على مستوى أدنى للتطبيق، بما في ذلك عمليات البث أو اللقطات السريعة الفعّالة بدون نسخ وعناصر التحكّم في كل إطار من حيث التعريض والزيادة ومكاسب توازن اللون الأبيض وتحويل الألوان وإزالة الضوضاء والتحسين وغير ذلك.

تم وضع علامة على حزمة واجهة برمجة التطبيقات القديمة،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، بغض النظر عمّا إذا كان الجهاز يتضمّن ميزة ضبط التركيز التلقائي للأجهزة أو ميزات أخرى. على سبيل المثال، يجب أن تظل الكاميرات التي لا تتضمّن ميزة ضبط التركيز التلقائي تستدعي أيّ نُسخ مسجّلة من android.hardware.Camera.AutoFocusCallback (على الرغم من أنّ هذا ليس له صلة بالكاميرات التي لا تتضمّن ميزة ضبط التركيز التلقائي). يُرجى العِلم أنّ ذلك ينطبق على الكاميرات الأمامية. على سبيل المثال، على الرغم من أنّ معظم الكاميرات الأمامية لا توفّر ميزة "ضبط التركيز التلقائي"، يجب أن تظلّ عمليات استدعاء واجهة برمجة التطبيقات "مزوّرة" على النحو الموضّح.
• [C-0-6] يجب أن يتعرّف على كل اسم مَعلمة محدّد كثابت في فئة android.hardware.Camera.Parameters وفئة android.hardware.camera2.CaptureRequest ويحترمه. في المقابل، يجب ألا تلتزم عمليات تنفيذ الأجهزة بثوابت السلاسل التي يتم تمريرها إلى طريقة android.hardware.Camera.setParameters() أو تتعرّف عليها، باستثناء تلك التي تم توثيقها كثوابت في android.hardware.Camera.Parameters. وهذا يعني أنّه يجب أن تتوافق عمليات تنفيذ الأجهزة مع جميع مَعلمات الكاميرا العادية إذا كان الجهاز يسمح بذلك، ويجب ألّا تتوافق مع أنواع مَعلمات الكاميرا المخصّصة. على سبيل المثال، يجب أن تتيح عمليات تنفيذ الأجهزة التي تتيح التقاط الصور باستخدام تقنيات التصوير بنطاق عالي الديناميكية (HDR) مَعلمة الكاميرا Camera.SCENE_MODE_HDR.
• [C-0-7] يجب الإبلاغ عن المستوى المناسب من التوافق مع سمة android.info.supportedHardwareLevel كما هو موضّح في حزمة تطوير البرامج (SDK) لنظام التشغيل Android والإبلاغ عن رموز ميزات إطار العمل المناسبة.
• [C-0-8] يجب أيضًا الإفصاح عن إمكانات الكاميرا الفردية التي تبلغ android.hardware.camera2 من خلال السمة android.request.availableCapabilities والإفصاح عن رموز الميزات المناسبة، ويجب تحديد رمز الميزة إذا كانت أي من أجهزة الكاميرا المرفقة تتيح الميزة.
• [C-0-9] يجب بث نية Camera.ACTION_NEW_PICTURE كلما التقطت الكاميرا صورة جديدة وتمّت إضافة إدخال الصورة إلى "متجر الوسائط".
• [C-0-10] يجب بث نية Camera.ACTION_NEW_VIDEO كلما سجّلت الكاميرا فيديو جديدًا وتمّت إضافة إدخال الصورة إلى "متجر الوسائط".
• [C-0-11] يجب أن تكون جميع الكاميرات متاحة للوصول إليها من خلال واجهة برمجة التطبيقات android.hardware.Camera المتوقّفة نهائيًا، كما يجب أن تكون متاحة للوصول إليها من خلال واجهة برمجة التطبيقات android.hardware.camera2.
• [C-0-12] يجب التأكّد من عدم تغيير مظهر الوجه، بما في ذلك على سبيل المثال لا الحصر، تغيير شكل الوجه أو درجة لون البشرة أو تنعيم البشرة لأي واجهة برمجة تطبيقات android.hardware.camera2 أو android.hardware.Camera.
• [C-SR] بالنسبة إلى الأجهزة التي تحتوي على كاميرات 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] يجب ضبطه باستخدام مساحة تخزين مشتركة يتم تثبيتها تلقائيًا، بعبارة أخرى "جاهز للاستخدام"، بغض النظر عمّا إذا تم تنفيذ مساحة التخزين على مكوّن تخزين داخلي أو وسيط تخزين قابل للإزالة (مثل فتحة بطاقة Secure Digital).
• [C-0-3] يجب ربط مساحة التخزين المشتركة للتطبيق مباشرةً بمسار Linux sdcard أو تضمين رابط رمزي لنظام التشغيل Linux من sdcard إلى نقطة الربط الفعلية.
• [C-0-4] يجب تفعيل مساحة التخزين ذات النطاق المحدّد تلقائيًا لجميع التطبيقات التي تستهدف المستوى 29 أو أعلى لواجهة برمجة التطبيقات، باستثناء الحالة التالية:
  • عندما يطلب التطبيق android:requestLegacyExternalStorage="true" في بيانه
• [C-0-5] يجب إخفاء البيانات الوصفية للموقع الجغرافي، مثل علامات EXIF لنظام تحديد المواقع العالمي (GPS)، المخزّنة في ملفات الوسائط عند الوصول إلى هذه الملفات من خلال MediaStore، إلا عندما يكون التطبيق المُرسِل يمتلك إذن ACCESS_MEDIA_LOCATION.

قد تستوفي عمليات تنفيذ الأجهزة المتطلبات المذكورة أعلاه باستخدام أيّ من الإجراءَين التاليَين:

• مساحة تخزين قابلة للإزالة يمكن للمستخدم الوصول إليها، مثل فتحة بطاقة Secure Digital (SD)
• جزء من مساحة التخزين الداخلية (غير القابلة للإزالة) كما هو منفذ في "المشروع المفتوح المصدر لنظام Android" ‏ (AOSP).

إذا كانت عمليات تنفيذ الأجهزة تستخدم مساحة تخزين قابلة للإزالة لاستيفاء المتطلبات المذكورة أعلاه، يجب استيفاء الشروط التالية:

• [C-1-1] يجب توفير واجهة مستخدم منبثقة أو شاشة منبثقة لتحذير المستخدم في حال عدم إدخال وسيط تخزين في الفتحة.
• [C-1-2] يجب أن يتضمّن الجهاز وسيط تخزين بتنسيق FAT (مثل بطاقة SD) أو أن يُظهر على العلبة والمواد الأخرى المتوفّرة في وقت الشراء أنّه يجب شراء وسيط التخزين بشكل منفصل.

إذا كانت عمليات تنفيذ الأجهزة تستخدِم جزءًا من مساحة التخزين غير القابلة للإزالة لتلبية المتطلبات أعلاه، يجب استيفاء ما يلي:

• يجب استخدام واجهة برمجة التطبيقات لنظام التشغيل Android Open Source Project (AOSP) في مساحة التخزين المشتركة للتطبيق الداخلي.
• يجوز له مشاركة مساحة التخزين مع البيانات الخاصة بالتطبيق.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB متوافقًا مع وضع الجهاز الطرفي USB، يجب استيفاء الشروط التالية:

• [C-3-1] يجب توفير آلية للوصول إلى البيانات في مساحة التخزين المشتركة للتطبيق من جهاز كمبيوتر مضيف.
• يجب أن يعرض المحتوى من كلا مسارَي التخزين بشكل شفاف من خلال خدمة "أداة فحص الوسائط" في Android وandroid.provider.MediaStore.
• يجوز استخدام وحدة تخزين USB المجمّعة، ولكن يجب استخدام بروتوكول نقل الوسائط لاستيفاء هذا الشرط.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB مع وضع الجهاز الطرفي USB وتتوافق مع بروتوكول نقل الوسائط، يجب أن تستوفي المتطلبات التالية:

• يجب أن يكون متوافقًا مع مضيف MTP المرجعي لنظام التشغيل Android، وهو نقل ملفات Android.
• يجب أن يُبلغ عن فئة جهاز USB‏ 0x00.
• يجب أن يُبلغ عن اسم واجهة USB‏ "MTP".

7.6.3. مساحة تخزين قابلة للاستخدام

إذا كان من المتوقّع أن يكون الجهاز جوّالاً بطبيعته على عكس التلفزيون، تكون عمليات تنفيذ الأجهزة على النحو التالي:

• [SR] يُنصح بشدة بتنفيذ مساحة التخزين القابلة للتخصيص في موقع ثابت على المدى الطويل، لأنّ فصلها عن طريق الخطأ قد يؤدي إلى فقدان البيانات أو تلفها.

إذا كان منفذ جهاز التخزين القابل للإزالة في مكان ثابت على المدى الطويل، مثل داخل مقصورة البطارية أو غطاء واقي آخر، تكون عمليات تنفيذ الجهاز:

• [SR] يُنصح بشدة بتنفيذ وحدة تخزين قابلة للاستخدام.

7.7. 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 أمبير وفقًا لمعيار المقاوم لوصلات USB من النوع C، ويجب أن يرصد التغييرات في الإعلان إذا كان متوافقًا مع USB من النوع C.
• [SR] يجب أن يستخدم المنفذ عامل شكل USB من النوع micro-B أو micro-AB أو Type-C. ننصح بشدة بتوافق أجهزة Android الحالية والجديدة مع هذه المتطلبات حتى تتمكّن من الترقية إلى إصدارات المنصة المستقبلية.
• [SR] يجب أن يكون المنفذ في أسفل الجهاز (وفقًا للاتجاه الطبيعي) أو تفعيل دوران الشاشة من خلال البرامج لجميع التطبيقات (بما في ذلك الشاشة الرئيسية)، حتى يتم عرض الشاشة بشكل صحيح عند توجيه الجهاز مع وضع المنفذ في الأسفل. ننصح بشدة بأن تستوفي أجهزة Android الحالية والجديدة هذه المتطلبات حتى تتمكّن من الترقية إلى إصدارات المنصة المستقبلية.
• [SR] يجب أن يتيح الجهاز سحب تيار 1.5 أمبير أثناء إشارة HS chirp ووقت نقل البيانات كما هو محدّد في مواصفات شحن البطارية عبر USB، المراجعة 1.2. ننصح بشدة بتوافق أجهزة Android الحالية والجديدة مع هذه المتطلبات حتى تتمكّن من الترقية إلى إصدارات المنصة المستقبلية.
• [SR] يُنصح بشدة بعدم السماح بأساليب الشحن الحصرية التي تعدّل جهد Vbus إلى ما بعد المستويات التلقائية، أو تغيير أدوار مصدر الطاقة أو المستهلك، لأنّ ذلك قد يؤدي إلى مشاكل في التشغيل التفاعلي مع الشواحن أو الأجهزة التي تتيح طرق إرسال الطاقة عبر USB العادية. على الرغم من أنّنا ننصحك بشدة باستخدام هذه الميزة، قد نشترط في الإصدارات المستقبلية من Android أن تتيح جميع الأجهزة التي تستخدم موصلات من النوع C إمكانية التشغيل التفاعلي الكامل مع شواحن من النوع C عادية.
• [SR] يُنصح بشدة بتوفُّر ميزة "إرسال الطاقة" لنقل البيانات وتبديل دور الطاقة عندما يتوفّر منفذ 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)
  • أن يكون مزوّدًا بمنفذ من النوع A على الجهاز أو أن يتم شحنه مع كابلات تتيح تحويل منفذ خاص على الجهاز إلى منفذ USB عادي من النوع A
  • أن يتضمّن منفذ micro-AB على الجهاز، والذي من المفترض أن يتم شحنه مع كابل متوافق مع منفذ Type-A عادي
• [C-1-3] يجب عدم شحن الجهاز مع محوِّل يحوّل من منافذ USB من النوع A أو micro-AB إلى منفذ من النوع C (مقبس).
• [C-SR] يُنصح بشدة بتنفيذ فئة الصوت عبر 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 من النوع C، يجب استيفاء الشروط التالية:

• [C-4-1] يجب تنفيذ وظيفة منفذ Dual Role Port كما هو محدّد في مواصفة USB Type-C (الفقرة 4.5.1.3.3).
• [SR] يُنصح بشدة بتوفير منفذ DisplayPort، ويجب أن يتوافق مع معدلات نقل البيانات بمعيار SuperSpeed USB، ويُنصح بشدة بتوفير ميزة "إرسال الطاقة" لتبديل دور نقل البيانات ونقل الطاقة.
• [SR] يُنصح بشدة بعدم إتاحة "وضع ملحق محوِّل الصوت" كما هو موضّح في "الملحق أ" من المراجعة 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.
• [SR] يُنصح بشدة بتوفير ميزة تسجيل الصوت بالقرب من ترددات فوق الصوتية كما هو موضّح في الفقرة 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.
• [SR] يُنصح بشدة بتفعيل ميزة تشغيل المحتوى بالقرب من ترددات الموجات فوق الصوتية كما هو موضّح في الفقرة 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] يُنصح بشدة بتضمين مقبس صوت 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] يُنصح بشدة بتوفُّر مقابس صوت بترتيب دبوس OMTP.
• [C-SR] ننصح بشدة بتفعيل ميزة تسجيل الصوت من سماعات الرأس الاستيريو المزوّدة بميكروفون.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقبس صوت 3.5 ملم مزوّدًا بأربعة موصلات ومتوافقًا مع الميكروفون، وبثّت الرسالة android.intent.action.HEADSET_PLUG مع ضبط القيمة الإضافية للميكروفون على 1، يعني ذلك ما يلي:

• [C-2-1] يجب أن يتيح الجهاز رصد الميكروفون في ملحق الصوت المتصل.

7.8.2.2. منافذ الصوت الرقمي

أن تكون متوافقة مع سماعات الرأس وغيرها من ملحقات الصوت التي تستخدم موصلات USB-C وتنفيذ (فئة الصوت عبر USB) على مستوى منظومة Android المتكاملة كما هو محدّد في مواصفات سماعات الرأس USB لأجهزة Android

راجِع القسم 2.2.1 لمعرفة المتطلبات الخاصة بالأجهزة.

7.8.3. الموجات فوق الصوتية القريبة

يتراوح نطاق الصوت بالقرب من الموجات فوق الصوتية بين 18.5 كيلوهرتز و20 كيلوهرتز.

عمليات التنفيذ على الأجهزة:

• يجب الإبلاغ بشكل صحيح عن توفّر ميزة الصوت بالقرب من الموجات فوق الصوتية من خلال واجهة برمجة التطبيقات AudioManager.getProperty على النحو التالي:

إذا كانت قيمة PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND هي "true"، يجب استيفاء المتطلبات التالية لمصادر الصوت VOICE_RECOGNITION وUNPROCESSED:

• [C-1-1] يجب ألا يقلّ متوسط استجابة الطاقة للميكروفون في النطاق من 18.5 كيلوهرتز إلى 20 كيلوهرتز عن 15 ديسيبل عن الاستجابة عند 2 كيلوهرتز.
• [C-1-2] يجب ألا تقل نسبة الإشارة إلى الضوضاء غير المحسوبة للميكروفون عن 50 ديسيبل عند تردد يتراوح بين 18.5 كيلوهرتز و20 كيلوهرتز لنغمة 19 كيلوهرتز عند -26 ديسيبل عادي.

إذا كانت قيمة PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND هي "صحيح":

• [C-2-1] يجب ألا يقل متوسّط استجابة مكبّر الصوت في النطاق من 18.5 كيلوهرتز إلى 20 كيلوهرتز عن 40 ديسيبل أقل من الاستجابة عند 2 كيلوهرتز.

7.8.4. سلامة الإشارة

عمليات تنفيذ الأجهزة: * يجب أن توفّر مسار إشارة صوتيًا خاليًا من الأعطال لكل من مصادر البث وقنوات الإخراج على الأجهزة الجوّالة، كما هو محدّد من خلال عدم رصد أي أعطال خلال اختبار لمدة دقيقة واحدة لكل مسار. يمكنك إجراء الاختبار باستخدام [OboeTester] (https://github.com/google/oboe/tree/master/apps/OboeTester) "اختبار الأعطال المبرمَج".

يتطلّب الاختبار استخدام محوِّل صوت يتم توصيله مباشرةً بمقابس 3.5 ملم و/أو مع محوِّل USB-C إلى 3.5 ملم. يجب اختبار جميع منافذ إخراج الصوت.

يتيح OboeTester حاليًا مسارات AAudio، لذا يجب اختبار التركيبات التالية بحثًا عن أي مشاكل باستخدام AAudio:

يجب أن يستوفي البث الموثوق المعايير التالية لنسبة الإشارة إلى الضوضاء (SNR) والتشويش التوافقي الكلي (THD) لموجة جيبية بتردد 2000 هرتز.

7.9. الواقع الافتراضي

يتضمّن نظام Android واجهات برمجة التطبيقات (API) ومرافق لإنشاء تطبيقات "الواقع الافتراضي" (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] يُنصح بشدة بتنفيذ GL_EXT_external_buffer وGL_EXT_EGL_image_array وGL_OVR_multiview_multisampled_render_to_texture وعرض الإضافات في قائمة إضافات GL المتاحة.
• [C-SR] يُنصح بشدة بتوفير Vulkan 1.1.
• [C-SR] يُنصح بشدة بتنفيذ VK_ANDROID_external_memory_android_hardware_buffer وVK_GOOGLE_display_timing وVK_KHR_shared_presentable_image وعرضها في قائمة إضافات Vulkan المتاحة.
• [C-SR] يُنصح بشدة بعرض عائلة قوائم انتظار 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] يُنصح بشدة بتفعيل تخصيص 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 × 1080 على الأقل بمعدّل 30 لقطة في الثانية مضغوطًا بمتوسط 10 ميغابت في الثانية، ويجب أن يكون قادرًا على فك ترميز 3840 × 2160 بمعدّل 30 لقطة في الثانية أو 20 ميغابت في الثانية (أي ما يعادل 4 مرات من 1920 × 1080 بمعدّل 30 لقطة في الثانية أو 5 ميغابت في الثانية).
• [C-1-13] يجب أن تكون متوافقة مع واجهة برمجة التطبيقات HardwarePropertiesManager.getDeviceTemperatures وأن تعرض قيمًا دقيقة لدرجة حرارة الجلد.
• [C-1-14] يجب أن يكون الجهاز مزوّدًا بشاشة مدمجة، ويجب ألا تقل درجة دقتها عن 1920 × 1080.
• [C-SR] يُنصح بشدة بضبط دقة الشاشة على 2560 × 1440 على الأقل.
• [C-1-15] يجب أن يتم تعديل الشاشة بمعدّل 60 هرتز على الأقل أثناء استخدام "وضع الواقع الافتراضي".
• [C-1-17] يجب أن تتيح الشاشة وضعًا بفترة بقاء منخفضة لا تزيد عن 5 مللي ثانية، ويتم تعريف فترة البقاء على أنّها المدة التي يُصدر فيها وحدات البكسل ضوءًا.
• [C-1-18] يجب أن يكون متوافقًا مع معيار Bluetooth 4.2 وإضافة طول البيانات في Bluetooth 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] يُنصح بشدة بتوفّر نوع القناة المباشرة TYPE_HARDWARE_BUFFER لجميع أنواع القنوات المباشرة المُدرَجة أعلاه.
• [C-1-21] يجب أن يستوفي الجهاز المتطلبات المتعلقة بالجيروسكوب ومقياس التسارع ومقياس المغناطيسية في android.hardware.hifi_sensors، كما هو موضّح في الفقرة 7.3.9.
• [C-SR] يُنصح بشدة بتوفير ميزة android.hardware.sensor.hifi_sensors.
• [C-1-22] يجب ألا يزيد وقت استجابة انتقال الصور من الإطار إلى شعاع الفوتون من طرف إلى آخر عن 28 ملي ثانية.
• [C-SR] يُنصح بشدة بضبط وقت استجابة الإطارات من البداية إلى النهاية بحيث لا يزيد عن 20 ملي ثانية.
• [C-1-23] يجب أن تكون نسبة اللقطة الأولى، وهي نسبة سطوع وحدات البكسل في اللقطة الأولى بعد الانتقال من الأسود إلى الأبيض وسطوع وحدات البكسل البيضاء في الحالة الثابتة، لا تقل عن %85.
• [C-SR] يُنصح بشدة بأن تكون نسبة اللقطة الأولى 90% على الأقل.
• يجوز أن يوفّر نواة حصرية للتطبيق الذي يعمل في المقدّمة، ويجوز أن يتوافق مع واجهة برمجة التطبيقات Process.getExclusiveCores لعرض أرقام أنوية وحدة المعالجة المركزية الحصرية للتطبيق الأهم الذي يعمل في المقدّمة.

إذا كان التطبيق يتضمّن ميزة "النواة الحصرية"، يجب أن يستوفي النواة الشروط التالية:

• [C-2-1] يجب عدم السماح بتشغيل أي عمليات أخرى في مساحة المستخدم (باستثناء برامج تشغيل الأجهزة التي يستخدمها التطبيق)، ولكن يجوز السماح بتشغيل بعض عمليات نظام التشغيل حسب الضرورة.

7.10. أجهزة تعمل باللمس

راجِع القسم 2.2.1 لمعرفة المتطلبات الخاصة بالأجهزة.

7.11. فئة أداء الوسائط

يمكن الحصول على فئة أداء الوسائط لتنفيذ الجهاز من واجهة برمجة التطبيقات android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS. يتم تحديد متطلبات فئة أداء الوسائط لكل إصدار من إصدارات Android بدءًا من R (الإصدار 30). تشير القيمة الخاصة 0 إلى أنّ الجهاز ليس من فئة أداء الوسائط.

إذا كانت عمليات تنفيذ الأجهزة تعرض قيمة غير صفرية لسمة android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS، فإنّها:

• [C-1-1] يجب أن تعرِض قيمة android.os.Build.VERSION_CODES.R على الأقل.

• [C-1-2] يجب أن يكون التنفيذ على جهاز محمول باليد.

• [C-1-3] يجب استيفاء جميع متطلبات "فئة أداء الوسائط" الموضّحة في الفقرة 2.2.7.

اطّلِع على الفقرة 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 لآلات تشغيل وصيانة وتنشيط الخوارزميات واستخدام إعدادات النظام الشاملة لتوفير الطاقة في وضعَي "الاستراحة" و"الاستعداد للتطبيقات".
• [C-1-2] يجب عدم الانحراف عن تنفيذ AOSP لاستخدام الإعدادات الشاملة لإدارة الحدّ من عدد المهام وعمليات التنبيه والشبكة للتطبيقات في كل مجموعة للوضع "الاستعداد للتطبيقات".
• [C-1-3] يجب عدم الانحراف عن طريقة تنفيذ AOSP لعدد مجموعات وضع "التطبيقات في وضع الاستعداد" المستخدَمة في وضع "التطبيقات في وضع الاستعداد".
• [C-1-4] يجب تنفيذ مجموعات التطبيقات في وضع الاستعداد ووضع "الاستراحة الذكية" كما هو موضّح في إدارة الطاقة.
• [C-1-5] يجب عرض true لرمز PowerManager.isPowerSaveMode() عندما يكون الجهاز في وضع توفير الطاقة.
• [C-SR] يُنصح بشدة بتوفير ميزة للمستخدم لتفعيل ميزة "توفير البطارية" وإيقافها.
• [C-SR] يُنصح بشدة بتوفير ميزة للمستخدم لعرض جميع التطبيقات المعفاة من وضعَي "الاستراحة" و"الاستراحة الذكية" لتوفير الطاقة.

إذا كانت عمليات تنفيذ الأجهزة توفّر ميزات إدارة الطاقة المضمّنة في AOSP وكانت هذه الميزات تفرض قيودًا أكثر صرامة من مجموعة التطبيقات التي نادرًا ما تكون في وضع الاستعداد، يُرجى الرجوع إلى الفقرة 3.5.1.

بالإضافة إلى أوضاع توفير الطاقة، قد تُنفِّذ عمليات تنفيذ أجهزة Android أيًا من أوضاع الطاقة الأربعة للاستعداد أو جميعها كما هو محدّد في واجهة Advanced Configuration and Power Interface (ACPI).

إذا كانت عمليات تنفيذ الأجهزة تطبّق حالات الطاقة S4 على النحو المحدّد في ACPI، فإنّها:

• [C-1-1] يجب عدم الدخول إلى هذه الحالة إلا بعد أن يتّخذ المستخدم إجراءً صريحًا لوضع الجهاز في حالة غير نشطة (مثل إغلاق غطاء يشكّل جزءًا من الجهاز أو إطفاء مركبة أو تلفزيون) وقبل أن يعيد المستخدم تفعيل الجهاز (مثل فتح الغطاء أو إعادة تشغيل المركبة أو التلفزيون).

إذا كانت عمليات تنفيذ الأجهزة تطبّق حالات الطاقة S3 على النحو المحدّد من قِبل ACPI، فإنّها:

• [C-2-1] يجب أن يستوفي C-1-1 أعلاه، أو يجب أن يدخل إلى حالة S3 فقط عندما لا تحتاج التطبيقات التابعة لجهات خارجية إلى موارد النظام (مثل الشاشة ووحدة المعالجة المركزية).

  في المقابل، يجب الخروج من حالة S3 عندما تحتاج التطبيقات التابعة لجهات خارجية إلى موارد النظام، كما هو موضّح في حزمة تطوير البرامج (SDK) هذه.

  على سبيل المثال، عندما تطلب التطبيقات التابعة لجهات خارجية إبقاء الشاشة مُضاءة من خلال FLAG_KEEP_SCREEN_ON أو إبقاء وحدة المعالجة المركزية (CPU) تعمل من خلال PARTIAL_WAKE_LOCK، يجب ألّا يدخل الجهاز في حالة S3 ما لم يتّخذ المستخدم إجراءً صريحًا لوضع الجهاز في حالة غير نشطة، كما هو موضّح في C-1-1. في المقابل، في الوقت الذي يتم فيه تشغيل مهمة تنفّذها التطبيقات التابعة لجهات خارجية من خلال JobScheduler أو يتم فيه إرسال رسائل "المراسلة عبر السحابة الإلكترونية من Firebase" إلى التطبيقات التابعة لجهات خارجية، يجب أن يخرج الجهاز من حالة S3 ما لم يضع المستخدم الجهاز في حالة غير نشطة. هذه ليست أمثلة شاملة، وينفِّذ AOSP إشارات استيقاظ واسعة النطاق تؤدي إلى الاستيقاظ من هذه الحالة.

8.4. احتساب استهلاك الطاقة

من خلال احتساب استهلاك الطاقة وإعداد تقارير أكثر دقة، يحصل مطوّر التطبيقات على الحوافز والأدوات اللازمة لتحسين نمط استخدام الطاقة في التطبيق.

عمليات التنفيذ على الأجهزة:

• [SR] يُنصح بشدة بتقديم ملف تعريف للطاقة لكل مكوّن يحدِّد قيمة الاستهلاك الحالي لكل مكوّن من مكونات الجهاز ومعدل استنزاف البطارية التقريبي الذي تتسبّب فيه المكوّنات بمرور الوقت، كما هو موضّح في موقع "مشروع Android المفتوح المصدر" الإلكتروني.
• [SR] يُنصح بشدة بالإبلاغ عن جميع قيم استهلاك الطاقة بالمللي أمبير ساعة (mAh).
• [SR] يُنصح بشدة بالإبلاغ عن استهلاك طاقة وحدة المعالجة المركزية لكل معرّف مستخدم لكل عملية. يستوفي "مشروع مفتوح المصدر لنظام Android" المتطلّبات من خلال تنفيذ وحدة نواة uid_cputime.
• [SR] يُنصح بشدة بإتاحة استخدام الطاقة هذا من خلال أمر shell‏ adb shell dumpsys batterystats لمطوّر التطبيق.
• يجب أن يُنسَب إلى مكوّن الجهاز نفسه في حال تعذّر تحديد تطبيق معيّن كمصدر استهلاك الطاقة في مكوّن الجهاز.

8.5. الأداء المتسق

يمكن أن يتفاوت الأداء بشكل كبير في التطبيقات العالية الأداء التي تعمل لفترة طويلة، إما بسبب التطبيقات الأخرى التي تعمل في الخلفية أو بسبب الحد من سرعة وحدة المعالجة المركزية بسبب الحدود القصوى لدرجة الحرارة. يتضمّن نظام التشغيل Android واجهات برمجة تطبيقات حتى يتمكّن التطبيق الأهم في المقدّمة من طلب تحسين تخصيص الموارد من النظام لمواجهة هذه التقلبات عندما يكون الجهاز مزوّدًا بالإمكانية اللازمة.

عمليات التنفيذ على الأجهزة:

• [C-0-1] يجب الإبلاغ عن توفّر "وضع الأداء المستدام" بدقة من خلال طريقة واجهة برمجة التطبيقات PowerManager.isSustainedPerformanceModeSupported().

• يجب أن يكون متوافقًا مع "وضع الأداء المستدام".

إذا أبلغت عمليات تنفيذ الأجهزة عن توفّر "وضع الأداء المستدام"، يعني ذلك أنّها:

• [C-1-1] يجب أن يقدّم التطبيق الأهم في المقدّمة مستوى أداء ثابتًا لمدة 30 دقيقة على الأقل عندما يطلب ذلك.
• [C-1-2] يجب الالتزام بواجهة برمجة التطبيقات Window.setSustainedPerformanceMode() وواجهات برمجة التطبيقات الأخرى ذات الصلة.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن نواتين أو أكثر من وحدات المعالجة المركزية، يتم تنفيذ ما يلي:

• يجب أن يوفّر معالجًا مركزيًا حصريًا واحدًا على الأقل يمكن حجز استخدامه من قِبل التطبيق الأهم في المقدّمة.

إذا كانت عمليات تنفيذ الأجهزة تتيح حجز نواة حصرية واحدة للتطبيق الأهم في المقدّمة، يتم تنفيذ ما يلي:

• [C-2-1] يجب الإبلاغ من خلال طريقة واجهة برمجة التطبيقات Process.getExclusiveCores() عن أرقام تعريف النوى الحصرية التي يمكن حجزها من خلال التطبيق الأهم الذي يعمل في المقدّمة.
• [C-2-2] يجب عدم السماح لأي عمليات في مساحة المستخدم باستثناء برامج تشغيل الأجهزة التي يستخدمها التطبيق للتشغيل على النوى الحصرية، ولكن يجوز السماح بتشغيل بعض عمليات نواة النظام حسب الضرورة.

إذا كانت عمليات تنفيذ الأجهزة لا تتيح استخدام نواة حصرية، يتم تنفيذ ما يلي:

• [C-3-1] يجب أن تعرض قائمة فارغة من خلال طريقة واجهة برمجة التطبيقات Process.getExclusiveCores().

9. توافق نموذج الأمان

عمليات التنفيذ على الأجهزة:

• [C-0-1] يجب تنفيذ نموذج أمان متوافق مع نموذج أمان نظام Android الأساسي كما هو محدّد في مستند مرجعي للأمان والأذونات في واجهات برمجة التطبيقات ضمن مستندات مطوّري تطبيقات Android.

• [C-0-2] يجب أن تتيح هذه الأجهزة تثبيت التطبيقات الموقَّعة ذاتيًا بدون الحاجة إلى أي أذونات أو شهادات إضافية من أي جهات خارجية أو سلطات. وعلى وجه التحديد، يجب أن تتيح الأجهزة المتوافقة آليات الأمان الموضّحة في الأقسام الفرعية التالية.

9.1. الأذونات

عمليات التنفيذ على الأجهزة:

• [C-0-1] يجب أن يكون التطبيق متوافقًا مع نموذج أذونات Android كما هو محدّد في مستندات مطوّري تطبيقات Android. وعلى وجه التحديد، يجب أن تفرض كل إذن محدّد كما هو موضّح في مستندات حزمة SDK، ولا يجوز حذف أي أذونات أو تغييرها أو تجاهلها.

• يجوز إضافة أذونات إضافية، شرط ألا تكون سلاسل أرقام تعريف الأذونات الجديدة في مساحة الاسم android.\*.

• [C-0-2] يجب عدم منح الأذونات التي لها protectionLevel‏PROTECTION_FLAG_PRIVILEGED إلا للتطبيقات المثبَّتة مسبقًا في المسارات المميَّزة لصورة النظام وضمن المجموعة الفرعية من الأذونات المدرَجة في القائمة المسموح بها لكل تطبيق. يستوفي تطبيق AOSP هذا الشرط من خلال قراءة الأذونات المدرَجة في القائمة المسموح بها لكل تطبيق من الملفات في مسار etc/permissions/ واستخدام مسار system/priv-app كمسار مميَّز.

إنّ الأذونات التي يكون مستوى حمايتها خطيرًا هي أذونات وقت التشغيل. تطلب التطبيقات التي تحتوي على targetSdkVersion > 22 هذه الأذونات أثناء التشغيل.

عمليات التنفيذ على الأجهزة:

• [C-0-3] يجب أن يعرض التطبيق واجهة مخصّصة للمستخدم ليقرر ما إذا كان سيمنح أذونات التشغيل المطلوبة، كما يجب أن يقدّم واجهة للمستخدم لإدارة أذونات التشغيل.
• [C-0-4] يجب أن يكون هناك تطبيق واحد فقط لكلتا واجهتَي المستخدم.
• [C-0-5] يجب عدم منح أي أذونات تشغيل للتطبيقات المثبَّتة مسبقًا ما لم يكن:
  • يمكن الحصول على موافقة المستخدم قبل أن يستخدمها التطبيق.
  • ترتبط أذونات التشغيل بنمط نية تم ضبط التطبيق المثبَّت مسبقًا كمعالج تلقائي له.
• [C-0-6] يجب منح الإذن android.permission.RECOVER_KEYSTORE لتطبيقات النظام فقط التي تسجِّل وكيل استرداد آمنًا بشكلٍ صحيح. يتم تعريف "وكيل الاسترداد" المُؤمَّن بشكلٍ صحيح على أنّه وكيل برامج على الجهاز تتم مزامنته مع مساحة تخزين عن بُعد خارج الجهاز، ومزوّد بأجهزة آمنة توفّر حماية مماثلة أو أقوى مما هو موضّح في خدمة Google Cloud Key Vault لمنع هجمات القوة الغاشمة على عامل المعلومات في شاشة القفل.

عمليات التنفيذ على الأجهزة:

• [C-0-7] يجب الالتزام بسمات إذن تحديد الموقع الجغرافي على Android عندما يطلب تطبيق بيانات الموقع الجغرافي أو النشاط البدني من خلال واجهة برمجة تطبيقات Android العادية أو آلية خاصة. وتشمل هذه البيانات على سبيل المثال لا الحصر ما يلي:

  • الموقع الجغرافي للجهاز (مثل خط العرض وخط الطول)
  • المعلومات التي يمكن استخدامها لتحديد موقع الجهاز الجغرافي أو تقديره (مثل معرّف شبكة Wi-Fi أو معرّف مجموعة الخدمات الأساسية أو معرّف الخلية أو الموقع الجغرافي للشبكة التي يتصل بها الجهاز)
  • النشاط البدني للمستخدم أو تصنيف النشاط البدني

وعلى وجه التحديد، تؤدي عمليات تنفيذ الأجهزة إلى ما يلي:

• [C-0-8] يجب الحصول على موافقة المستخدم للسماح للتطبيق بالوصول إلى بيانات الموقع الجغرافي أو النشاط البدني.
• [C-0-9] يجب منح إذن التشغيل للتطبيق الذي يملك إذنًا كافيًا كما هو موضّح في حزمة SDK فقط. على سبيل المثال، يتطلب TelephonyManager#getServiceState android.permission.ACCESS_FINE_LOCATION.

يمكن وضع علامة على الأذونات على أنّها محظورة، ما يؤدي إلى تغيير سلوكها.

• [C-0-10] يجب عدم منح الأذونات التي تم وضع العلامة hardRestricted عليها لأي تطبيق ما لم يكن:

  • إذا كان ملف APK للتطبيق في قسم النظام
  • يمنح المستخدم دورًا مرتبطًا بأذونات hardRestricted لتطبيق معيّن.
  • يمنح برنامج التثبيت إذن hardRestricted لتطبيق معيّن.
  • تم منح أحد التطبيقات إذن hardRestricted على إصدار سابق من Android.

• [C-0-11] يجب أن تحصل التطبيقات التي تمتلك إذن softRestricted على إذن وصول محدود فقط، ويجب ألا تحصل على إذن وصول كامل إلى أن يتم إدراجها في القائمة المسموح بها كما هو موضّح في حزمة تطوير البرامج (SDK)، حيث يتم تحديد إذن الوصول الكامل والمحدود لكل إذن softRestricted (على سبيل المثال، READ_EXTERNAL_STORAGE).

إذا كانت عمليات تنفيذ الأجهزة توفّر للمستخدم إمكانات اختيار التطبيقات التي يمكنها الرسم على التطبيقات الأخرى من خلال نشاط يعالج نية ACTION_MANAGE_OVERLAY_PERMISSION، يجب أن تستوفي المتطلبات التالية:

• [C-2-1] يجب التأكّد من أنّ جميع الأنشطة التي تتضمّن فلاتر الأهداف لهدف ACTION_MANAGE_OVERLAY_PERMISSION تتضمّن شاشة واجهة المستخدم نفسها، بغض النظر عن التطبيق الذي بدأ النشاط أو أي معلومات يوفّرها.

9.2. رقم التعريف الفريد للعملية وعزل العمليات

عمليات التنفيذ على الأجهزة:

• [C-0-1] يجب أن يكون متوافقًا مع نموذج وضع الحماية لتطبيقات Android، حيث يتم تشغيل كل تطبيق كمعرّف مستخدم فريد على غرار Unix وفي عملية منفصلة.
• [C-0-2] يجب أن تتيح تشغيل تطبيقات متعددة باستخدام معرّف مستخدم Linux نفسه، شرط أن تكون التطبيقات موقَّعة ومُنشأة بشكل صحيح، كما هو محدّد في مرجع الأمان والأذونات.

9.3. أذونات نظام الملفات

عمليات التنفيذ على الأجهزة:

• [C-0-1] يجب أن يكون متوافقًا مع نموذج أذونات الوصول إلى الملفات في Android كما هو محدّد في مرجع الأمان والأذونات.

9.4. بيئات التنفيذ البديلة

يجب أن تحافظ عمليات تنفيذ التطبيقات على الأجهزة على اتساق نموذج أمان Android وأذوناته، حتى إذا كانت تتضمّن بيئات تشغيل تنفِّذ التطبيقات باستخدام بعض البرامج أو التكنولوجيات الأخرى غير تنسيق Dalvik Executable Format أو الرمز الأصلي. بعبارة أخرى:

• [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 إمكانية استخدام عدّة مستخدمين ويوفّر إمكانية عزل المستخدمين بالكامل.

• يجوز لعمليات تنفيذ الأجهزة تفعيل ميزة "الوصول المتعدّد للمستخدمين"، ولكن لا يُفترَض أن تفعّلها إذا كانت تستخدم وسائط قابلة للإزالة لمساحة التخزين الخارجية الأساسية.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مستخدمين متعدّدين، عليهم اتّباع الخطوات التالية:

• [C-1-1] يجب أن تستوفي المتطلبات التالية المتعلقة بإتاحة استخدام التطبيق لعدة مستخدمين.
• [C-1-2] يجب أن تطبّق كل تطبيق نموذج أمان متوافقًا مع نموذج أمان نظام Android الأساسي كما هو محدّد في مستند مرجعي للأمان والأذونات في واجهات برمجة التطبيقات.
• [C-1-3] يجب أن تتضمّن فهارس تخزين التطبيقات المشتركة (المعروفة أيضًا باسم /sdcard) منفصلة ومحصَّنة لكل مثيل مستخدم.
• [C-1-4] يجب التأكّد من أنّ التطبيقات التي يملكها مستخدم معيّن ويتم تشغيلها نيابةً عنه لا يمكنها إدراج الملفات التي يملكها أي مستخدم آخر أو قراءتها أو الكتابة فيها، حتى إذا كانت بيانات كلا المستخدمَين مخزّنة في وحدة التخزين أو نظام الملفات نفسهما.
• [C-1-5] يجب تشفير محتوى بطاقة SD عند تفعيل ميزة "الوصول المتعدد" باستخدام مفتاح يتم تخزينه فقط على وسائط غير قابلة للإزالة لا يمكن للنظام الوصول إليها إلا إذا كانت عمليات تنفيذ الأجهزة تستخدم وسائط قابلة للإزالة لواجهات برمجة تطبيقات مساحة التخزين الخارجية. وبما أنّ هذا الإجراء سيجعل الوسائط غير قابلة للقراءة من خلال جهاز كمبيوتر مضيف، سيُطلب من عمليات تنفيذ الأجهزة التبديل إلى بروتوكول MTP أو نظام مشابه لمنح أجهزة الكمبيوتر المضيف إمكانية الوصول إلى بيانات المستخدم الحالي.

9.6 تحذير بشأن الرسائل القصيرة برسوم إضافية

يتيح نظام التشغيل Android تحذير المستخدمين من أي رسالة قصيرة غير مجانية يتم إرسالها. الرسائل القصيرة SMS للخدمات هي رسائل نصية يتم إرسالها إلى خدمة مسجَّلة لدى مشغِّل شبكة الجوّال وقد تفرض رسومًا على المستخدم.

إذا كانت عمليات تنفيذ الأجهزة تعلن عن توافقها مع android.hardware.telephony، يعني ذلك ما يلي:

• [C-1-1] يجب تحذير المستخدمين قبل إرسال رسالة SMS إلى الأرقام التي تم تحديدها من خلال التعبيرات العادية المحدّدة في ملف /data/misc/sms/codes.xml على الجهاز. يقدّم مشروع Android Open Source Project الإصدار الأصلي الذي يستوفي هذا الشرط.

9.7. ميزات الأمان

يجب أن تضمن عمليات تنفيذ الأجهزة الامتثال لميزات الأمان في كلّ من النواة والنظام الأساسي على النحو الموضّح أدناه.

يتضمّن "وضع الحماية في Android" ميزات تستخدِم نظام التحكّم الإجباري في الوصول (MAC) في نظام التشغيل Security-Enhanced Linux (SELinux) ووضع الحماية seccomp وميزات أمان أخرى في نواة Linux. عمليات التنفيذ على الأجهزة:

• [C-0-1] يجب الحفاظ على التوافق مع التطبيقات الحالية، حتى في حال تنفيذ SELinux أو أي ميزات أمان أخرى ضمن إطار عمل Android.
• [C-0-2] يجب ألّا تتضمّن واجهة مستخدم مرئية عند رصد انتهاك أمني وحظره بنجاح من خلال ميزة الأمان المُطبَّقة أسفل إطار عمل Android، ولكن يجوز أن تتضمّن واجهة مستخدم مرئية عند حدوث انتهاك أمني غير محظور يؤدي إلى استغلال ناجح.
• [C-0-3] يجب عدم السماح للمستخدم أو مطوّر التطبيقات بضبط SELinux أو أي ميزات أمان أخرى تم تنفيذها أسفل إطار عمل Android.
• [C-0-4] يجب عدم السماح لتطبيق يمكنه التأثير في تطبيق آخر من خلال واجهة برمجة تطبيقات (مثل Device Administration API) بضبط سياسة تؤدي إلى إيقاف التوافق.
• [C-0-5] يجب تقسيم إطار عمل الوسائط إلى عمليات متعددة حتى يصبح من الممكن منح إذن الوصول لكل عملية بشكل أكثر تقييدًا على النحو الموضَّح في الموقع الإلكتروني لمشروع Android Open Source Project.
• [C-0-6] يجب تنفيذ آلية وضع التطبيقات في بيئة معزولة في نظام التشغيل الأساسية تسمح بفلترة طلبات النظام باستخدام سياسة قابلة للضبط من البرامج المتعدّدة المواضيع. يستوفي مشروع Android Open Source Project هذا الشرط من خلال تفعيل seccomp-BPF مع مزامنة مجموعة المواضيع (TSYNC) كما هو موضّح في قسم "إعدادات kernel" على source.android.com.

إنّ ميزات حماية سلامة النواة والحماية الذاتية هي جزء لا يتجزأ من أمان Android. عمليات التنفيذ على الأجهزة:

• [C-0-7] يجب تنفيذ آليات الحماية من تدفّق سعة المخزن المؤقت للحزمة في kernel. ومن الأمثلة على هذه الآليات CC_STACKPROTECTOR_REGULAR وCONFIG_CC_STACKPROTECTOR_STRONG.
• [C-0-8] يجب تنفيذ إجراءات حماية صارمة لذاكرة نظام التشغيل الأساسية حيث يكون الرمز القابل للتنفيذ للقراءة فقط، والبيانات القابلة للقراءة فقط غير قابلة للتنفيذ وغير قابلة للكتابة، والبيانات القابلة للكتابة غير قابلة للتنفيذ (مثل CONFIG_DEBUG_RODATA أو CONFIG_STRICT_KERNEL_RWX).
• [C-0-9] يجب تنفيذ عمليات التحقّق من حدود حجم العناصر الثابتة والديناميكية للنسخ بين مساحة المستخدم ومساحة النواة (مثل CONFIG_HARDENED_USERCOPY) على الأجهزة التي تعمل في الأصل بالإصدار 28 من واجهة برمجة التطبيقات أو إصدار أحدث.
• [C-0-10] يجب عدم تنفيذ ذاكرة مساحة المستخدم عند التنفيذ في وضع kernel (مثل PXN للأجهزة أو المحاكاة من خلال CONFIG_CPU_SW_DOMAIN_PAN أو CONFIG_ARM64_SW_TTBR0_PAN) على الأجهزة التي يتم شحنها في الأصل مع المستوى 28 من واجهة برمجة التطبيقات أو إصدار أحدث.
• [C-0-11] يجب عدم قراءة ذاكرة مساحة المستخدم أو كتابتها في النواة خارج واجهات برمجة التطبيقات العادية للوصول إلى مساحة المستخدم (مثل شبكة المنطقة الشخصية للأجهزة أو المحاكاة من خلال CONFIG_CPU_SW_DOMAIN_PAN أو CONFIG_ARM64_SW_TTBR0_PAN) على الأجهزة التي يتم شحنها في الأصل بمستوى واجهة برمجة التطبيقات 28 أو أعلى.
• [C-0-12] يجب تنفيذ عزل جدول صفحات نظام التشغيل إذا كان الجهاز عرضة للاختراق من خلال CVE-2017-5754 على جميع الأجهزة التي تم شحنها في الأصل بالمستوى 28 من واجهة برمجة التطبيقات أو مستوى أعلى (مثل CONFIG_PAGE_TABLE_ISOLATION أو CONFIG_UNMAP_KERNEL_AT_EL0).
• [C-0-13] يجب تنفيذ إجراءات تأمين توقّعات الفرع إذا كان الجهاز معرّضًا للاختراق من خلال CVE-2017-5715 على جميع الأجهزة التي كانت تعمل في الأصل بالمستوى 28 من واجهة برمجة التطبيقات أو إصدارًا أحدث (مثل CONFIG_HARDEN_BRANCH_PREDICTOR).
• [SR] يُنصح بشدة بالاحتفاظ ببيانات kernel التي يتم كتابتها فقط أثناء عملية الإعداد ووضع علامة "للقراءة فقط" عليها بعد اكتمال عملية الإعداد (مثل __ro_after_init).

• [C-SR] يُنصح بشدة بتعشيب تنسيق رمز النواة والذاكرة، وتجنُّب التعرّض للاختراقات التي قد تؤدي إلى التأثير في العشوائية (مثل CONFIG_RANDOMIZE_BASE مع التشويش في أداة تحميل البرامج من خلال /chosen/kaslr-seed Device Tree node أو EFI_RNG_PROTOCOL).

• [C-SR] يُنصح بشدة بتفعيل ميزة "سلامة تدفّق التحكّم" (CFI) في النواة لتوفير حماية إضافية ضد هجمات إعادة استخدام الرموز البرمجية (مثل CONFIG_CFI_CLANG وCONFIG_SHADOW_CALL_STACK).

• [C-SR] يُنصح بشدة بعدم إيقاف ميزة "سلامة تدفّق التحكّم" (CFI) أو "تسلسل استدعاء الظل" (SCS) أو "التطهير من تدفّق الأعداد الصحيحة" (IntSan) في المكوّنات التي تم تفعيلها فيها.
• [C-SR] يُنصح بشدة بتفعيل CFI وSCS وIntSan لأي مكوّنات إضافية حسّاسة للّامن في مساحة المستخدم كما هو موضّح في CFI وIntSan.
• [C-SR] يُنصح بشدة بتفعيل عملية إعداد الحزمة في النواة لمنع استخدام المتغيّرات المحلية غير المُعدَّة (CONFIG_INIT_STACK_ALL أو CONFIG_INIT_STACK_ALL_ZERO). بالإضافة إلى ذلك، يجب ألا تفترض عمليات تنفيذ الأجهزة القيمة المستخدَمة من المُجمِّع لإعداد المتغيّرات المحلية.
• [C-SR] يُنصح بشدة بتفعيل عملية إعداد الذاكرة في النواة لمنع استخدام عمليات تخصيص الذاكرة غير المُعدَّة (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) ويجب عدم افتراض القيمة المستخدَمة من قِبل النواة لإعداد عمليات التخصيص هذه.

إذا كانت عمليات تنفيذ الأجهزة تستخدم نواة Linux، فإنّها:

• [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 لكل تطبيق على دليل البيانات الخاصة بكل تطبيق.
• يجب الاحتفاظ بسياسة SELinux التلقائية المقدَّمة في مجلد system/sepolicy ضمن مشروع Android Open Source Project الأساسي، وإضافة المزيد إلى هذه السياسة فقط لإعدادات الجهاز الخاصة بكل مصنع.

إذا سبق أن تم إطلاق عمليات تنفيذ الأجهزة على إصدار أقدم من Android وتعذّر استيفاء المتطلبات [C-1-1] و[C-1-5] من خلال تحديث لنظام التشغيل، قد يتم إعفاؤها من هذه المتطلبات.

إذا كانت عمليات تنفيذ الأجهزة تستخدم نواة غير Linux، يجب استيفاء الشروط التالية:

• [C-2-1] يجب استخدام نظام تحكّم إجباري في الوصول يكون مكافئًا لنظام SELinux.

يحتوي Android على ميزات متعددة للدفاع العميق تُعدّ جزءًا لا يتجزأ من أمان الجهاز.

9.8. الخصوصية

9.8.1. سجلّ الاستخدام

يخزِّن Android سجلّ خيارات المستخدم ويُدير هذا السجلّ من خلال UsageStatsManager.

عمليات التنفيذ على الأجهزة:

• [C-0-1] يجب الاحتفاظ بسجلّ المستخدمين هذا لفترة زمنية معقولة.
• [SR] يُنصح بشدة بالاحتفاظ بفترة الاحتفاظ التي تبلغ 14 يومًا كما تم ضبطها تلقائيًا في عملية تنفيذ AOSP.

يخزِّن Android أحداث النظام باستخدام معرّفات StatsLog، ويدير هذا السجلّ من خلال واجهتَي برمجة التطبيقات StatsManager وIncidentManager System API.

عمليات التنفيذ على الأجهزة:

• [C-0-2] يجب تضمين الحقول التي تم وضع علامة DEST_AUTOMATIC عليها فقط في تقرير الحادثة الذي أنشأته فئة System API‏ IncidentManager.
• [C-0-3] يجب عدم استخدام معرّفات أحداث النظام لتسجيل أي حدث آخر غير ما هو موضّح في مستندات حزمة تطوير البرامج (SDK) الخاصة بتطبيق StatsLog. في حال تسجيل أحداث نظام إضافية، قد يتم استخدام معرّف ذرة مختلف في النطاق بين 100,000 و200,000.

9.8.2. يتم التسجيل

عمليات التنفيذ على الأجهزة:

• [C-0-1] يجب عدم تحميل مكوّنات البرامج مسبقًا أو توزيعها خارج العلبة إذا كانت ترسل معلومات المستخدم الخاصة (مثل ضغطات المفاتيح والنصوص المعروضة على الشاشة وتقارير الأخطاء) خارج الجهاز بدون موافقة المستخدم أو إشعارات واضحة ومستمرة.
• [C-0-2] يجب عرض موافقة صريحة من المستخدم والحصول عليها للسماح بتسجيل أي معلومات حساسة تظهر على شاشة المستخدم عند تفعيل بث الشاشة أو تسجيل الشاشة من خلال MediaProjection أو واجهات برمجة التطبيقات المملوكة. يجب عدم تزويد المستخدمين بإمكانية إيقاف عرض موافقة المستخدم في المستقبل.
• [C-0-3] يجب أن يعرض التطبيق إشعارًا مستمرًا للمستخدم أثناء بث الشاشة أو تسجيلها. يستوفي AOSP هذا الشرط من خلال عرض رمز إشعار جاري في شريط الحالة.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن وظائف في النظام تعمل على تسجيل المحتوى المعروض على الشاشة و/أو تسجيل البث الصوتي الذي يتم تشغيله على الجهاز بخلاف استخدام System API ContentCaptureService أو وسائل أخرى مملوكة مُوضّحة في الفقرة 9.8.6 "تسجيل المحتوى"، يجب استيفاء الشروط التالية:

• [C-1-1] يجب أن يتلقّى المستخدم إشعارًا مستمرًا عند تفعيل هذه الوظيفة وتسجيل/التقاط المحتوى بشكل نشط.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مكوّنًا مفعّلاً تلقائيًا، وقابلاً لتسجيل الصوت المحيط و/أو تسجيل الصوت الذي يتم تشغيله على الجهاز لاستنتاج معلومات مفيدة عن سياق المستخدم، يجب استيفاء الشروط التالية:

• [C-2-1] يجب عدم تخزين الملفات الصوتية الأولية المسجّلة أو أي تنسيق يمكن تحويله مرة أخرى إلى الملف الصوتي الأصلي أو نسخة طبق الأصل تقريبًا في مساحة التخزين الثابتة على الجهاز أو نقلها خارج الجهاز إلا بعد الحصول على موافقة صريحة من المستخدم.

9.8.3. إمكانية الاتصال

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB متوافقًا مع وضع الجهاز الطرفي USB، يجب استيفاء الشروط التالية:

• [C-1-1] يجب أن تعرِض واجهة المستخدم طلبًا للحصول على موافقة المستخدم قبل السماح بالوصول إلى محتوى مساحة التخزين المشتركة عبر منفذ USB.

9.8.4. حركة بيانات الشبكة

عمليات التنفيذ على الأجهزة:

• [C-0-1] يجب تثبيت الشهادات الجذر نفسها مسبقًا لمتجر هيئة إصدار الشهادات (CA) الموثوق به من النظام على النحو الموضَّح في مشروع Android Open Source Project.
• [C-0-2] يجب شحن الجهاز مع متجر مرجع تصديق جذر فارغ للمستخدم.
• [C-0-3] يجب عرض تحذير للمستخدم يشير إلى أنّه قد يتم رصد حركة المرور على الشبكة عند إضافة هيئة إصدار مصدق جذر للمستخدِم.

في حال توجيه حركة بيانات الجهاز من خلال شبكة VPN، يتم تنفيذ ما يلي على الجهاز:

• [C-1-1] يجب عرض تحذير للمستخدم يشير إلى أيّ مما يلي:
  • قد يتم تتبُّع حركة بيانات الشبكة هذه.
  • ويتم توجيه حركة بيانات الشبكة هذه من خلال تطبيق شبكة VPN المحدّد الذي يقدّم شبكة VPN.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن آلية مفعَّلة تلقائيًا من خارج العلبة لتوجيه حركة بيانات الشبكة من خلال خادم وكيل أو بوابة شبكة VPN (على سبيل المثال، التحميل المُسبَق لخدمة VPN مع منح android.permission.CONTROL_VPN)، يجب استيفاء الشروط التالية:

• [C-2-1] يجب طلب موافقة المستخدم قبل تفعيل هذه الآلية، ما لم يفعّل وحدة التحكّم في سياسة الجهاز شبكة VPN هذه من خلال DevicePolicyManager.setAlwaysOnVpnPackage()، وفي هذه الحالة لا يحتاج المستخدم إلى تقديم موافقة منفصلة، ولكن يجب إعلامه فقط.

إذا كانت عمليات تنفيذ الأجهزة توفّر للمستخدم إمكانية تفعيل ميزة "شبكة VPN قيد التشغيل دائمًا" في تطبيق شبكة VPN تابع لجهة خارجية، يجب أن تستوفي المتطلبات التالية:

• [C-3-1] يجب إيقاف ميزة المستخدم هذه للتطبيقات التي لا تتوافق مع خدمة شبكة VPN المفعَّلة دائمًا في ملف AndroidManifest.xml من خلال ضبط السمة SERVICE_META_DATA_SUPPORTS_ALWAYS_ON على false.

9.8.5. معرّفات الأجهزة

عمليات التنفيذ على الأجهزة:

• [C-0-1] يجب أن يمنع التطبيق الوصول إلى الرقم التسلسلي للجهاز ورقم IMEI/MEID ورقم شريحة SIM التسلسلي ورقم التعريف الدولي للمشترك في خدمات الجوّال (IMSI) من التطبيق، ما لم يستوفِ أحد المتطلبات التالية:
  • هو تطبيق مشفَّر لمشغِّل شبكة الجوّال تم التحقّق منه من قِبل الشركات المصنّعة للأجهزة.
  • تم منح الإذن READ_PRIVILEGED_PHONE_STATE.
  • أن يكون لديه امتيازات مشغّل شبكة الجوّال على النحو المحدّد في امتيازات مشغّل شبكة الجوّال في شريحة UICC
  • هو مالك جهاز أو ملف تجاري تم منحه الإذن READ_PHONE_STATE.
  • (بالنسبة إلى الرقم التسلسلي لشريحة SIM/رقم ICCID فقط) تشترط اللوائح المحلية أن يرصد التطبيق التغييرات في هوية المشترك.

9.8.6. تسجيل المحتوى

يتيح نظام التشغيل Android، من خلال System API ContentCaptureService أو بوسائل أخرى خاصة، آلية لعمليات تنفيذ الأجهزة لتسجيل التفاعلات التالية بين التطبيقات والمستخدم.

• النصوص والرسومات المعروضة على الشاشة، بما في ذلك على سبيل المثال لا الحصر، الإشعارات وبيانات المساعدة من خلال واجهة برمجة التطبيقات AssistStructure
• بيانات الوسائط، مثل الصوت أو الفيديو، التي سجّلها الجهاز أو شغّلها
• أحداث الإدخال (مثل المفاتيح والفأرة والإيماءات والصوت والفيديو وإمكانية الاستخدام)
• أيّ أحداث أخرى يوفّرها التطبيق للنظام من خلال واجهة برمجة التطبيقات Content Capture أو واجهة برمجة تطبيقات خاصة ذات إمكانات مماثلة
• أي نص أو بيانات أخرى يتم إرسالها عبر TextClassifier API إلى System TextClassifier، أي خدمة النظام لفهم معنى النص، بالإضافة إلى إنشاء الإجراءات التالية المتوقّعة استنادًا إلى النص

إذا كانت عمليات تنفيذ الأجهزة تلتقط البيانات أعلاه، فإنّها:

• [C-1-1] يجب تشفير جميع هذه البيانات عند تخزينها في الجهاز. يجوز تنفيذ هذا التشفير باستخدام ميزة "التشفير المستند إلى الملفات" في Android أو أي من التشفيرات المُدرَجة في الإصدار 26 من واجهة برمجة التطبيقات أو الإصدارات الأحدث الموضّحة في حزمة تطوير البرامج (SDK) لتشفير البيانات.
• [C-1-2] يجب عدم الاحتفاظ بنسخة احتياطية من البيانات الأولية أو المشفَّرة باستخدام طرق الاحتفاظ بنسخة احتياطية من بيانات Android أو أي طرق أخرى للاحتفاظ بنسخة احتياطية.
• [C-1-3] يجب عدم إرسال جميع هذه البيانات وسجلّ الجهاز إلا باستخدام آلية للحفاظ على الخصوصية. يتم تعريف آلية الحفاظ على الخصوصية على أنّها "تلك التي لا تسمح إلا بالتحليل بشكل مجمّع وتمنع مطابقة الأحداث المسجّلة أو النتائج المستمدة مع مستخدمين فرديين"، لمنع إمكانية استكشاف أي بيانات خاصة بالمستخدم (على سبيل المثال، يتم تنفيذها باستخدام تكنولوجيا الخصوصية التفاضلية مثل RAPPOR).
• [C-1-4] يجب عدم ربط هذه البيانات بأي هوية مستخدم (مثل Account) على الجهاز، إلا بعد الحصول على موافقة صريحة من المستخدم في كل مرة يتم فيها ربط البيانات.
• [C-1-5] يجب عدم مشاركة هذه البيانات مع تطبيقات أخرى إلا بعد الحصول على موافقة صريحة من المستخدم في كل مرة تتم فيها المشاركة.
• [C-1-6] يجب أن توفّر للمستخدم إمكانية محو هذه البيانات التي يجمعها ContentCaptureService أو الوسائل المملوكة إذا كانت البيانات مخزّنة بأي شكل على الجهاز.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن خدمة تنفِّذ System API ContentCaptureService أو أي خدمة خاصة تلتقط البيانات على النحو الموضّح أعلاه، يجب استيفاء الشروط التالية:

• [C-2-1] يجب عدم السماح للمستخدمين باستبدال خدمة التقاط المحتوى بتطبيق أو خدمة يمكن للمستخدم تثبيتها، ويجب السماح فقط للخدمة المثبَّتة مسبقًا بتسجيل هذه البيانات.
• [C-2-2] يجب عدم السماح لأي تطبيقات غير آلية خدمة التقاط المحتوى المثبَّتة مسبقًا بتسجيل هذه البيانات.
• [C-2-3] يجب أن توفّر للمستخدم إمكانية إيقاف خدمة تسجيل المحتوى.
• [C-2-4] يجب عدم حذف ميزة إدارة أذونات Android التي تمتلكها خدمة تسجيل المحتوى واتّباع نموذج أذونات Android كما هو موضّح في الفقرة 9.1. الإذن:

• [C-SR] يُنصح بشدة بإبقاء مكوّنات خدمة التقاط المحتوى منفصلة، على سبيل المثال، عدم ربط الخدمة أو مشاركة أرقام تعريف العمليات، عن مكوّنات النظام الأخرى باستثناء ما يلي:

  • الاتصال الهاتفي وجهات الاتصال وواجهة مستخدم النظام والوسائط

9.8.7. الوصول إلى الحافظة

عمليات التنفيذ على الأجهزة:

• [C-0-1] يجب عدم عرض بيانات مُقتطعة في الحافظة (مثلاً من خلال واجهة برمجة التطبيقات ClipboardManager) ما لم يكن التطبيق هو واجهة برمجة التطبيقات التلقائية للكتابة الآلية أو التطبيق الذي يتم التركيز عليه حاليًا.

9.8.8. الموقع الجغرافي

عمليات التنفيذ على الأجهزة:

• [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 أو أعلى من واجهة برمجة التطبيقات الاطّلاع على تفاصيل عن التطبيقات المثبَّتة الأخرى تلقائيًا (اطّلِع على مستوى رؤية الحِزمة في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android).

عمليات التنفيذ على الأجهزة:

• [C-0-1] يجب عدم عرض أي تفاصيل عن أي تطبيق آخر مثبَّت لأي تطبيق يستهدف المستوى 30 أو أعلى لواجهة برمجة التطبيقات، ما لم يكن التطبيق قادرًا على الاطّلاع على تفاصيل عن التطبيق الآخر المثبَّت من خلال واجهات برمجة التطبيقات المُدارة. ويشمل ذلك، على سبيل المثال لا الحصر، التفاصيل التي تعرضها أي واجهات برمجة تطبيقات مخصّصة أضافها مطوّر الجهاز، أو التي يمكن الوصول إليها من خلال نظام الملفات.

9.8.10. تقرير خطأ في الاتصال

إذا كانت عمليات تنفيذ الأجهزة تنشئ تقارير أخطاء باستخدام واجهة برمجة التطبيقات System API BUGREPORT_MODE_TELEPHONY مع BugreportManager، فإنّها:

• [C-1-1] يجب الحصول على موافقة المستخدم في كل مرة يتم فيها استدعاء System API BUGREPORT_MODE_TELEPHONY لإنشاء تقرير، ويجب عدم مطالبة المستخدم بالموافقة على جميع الطلبات المستقبلية من التطبيق.
• [C-1-2] يجب عرض موافقة المستخدم الصريحة والحصول عليها عند بدء إنشاء التقارير، ويجب عدم إعادة التقرير الذي تم إنشاؤه إلى التطبيق الذي طلبه بدون موافقة المستخدم الصريحة.
• [C-1-3] يجب أن تنشئ التقارير المطلوبة التي تحتوي على المعلومات التالية على الأقل:
  • بيانات الجلسة في TelephonyDebugService
  • تفريغ ذاكرة TelephonyRegistry
  • ملف الذاكرة الذي يضم بيانات WifiService
  • نبذة عن حالة ConnectivityService
  • تمهيد مثيل CarrierService لحزمة الاتصال (في حال ربطها)
  • ذاكرة التخزين المؤقت لسجلّ الراديو
• [C-1-4] يجب عدم تضمين ما يلي في التقارير التي يتم إنشاؤها:
  • أي نوع من المعلومات غير ذات الصلة بتصحيح أخطاء الاتصال
  • أي نوع من سجلات زيارات التطبيقات التي ثبَّتها المستخدم أو الملفات الشخصية التفصيلية للتطبيقات أو الحِزم التي ثبَّتها المستخدم (يُسمح بأرقام التعريف الفريد للمستخدمين، ولكن لا يُسمح بأسماء الحِزم)
• قد تتضمّن معلومات إضافية غير مرتبطة بأي هوية مستخدم. (مثل سجلات المورّدين)

إذا كانت عمليات تنفيذ الأجهزة تتضمّن معلومات إضافية (مثل سجلّات المورّدين) في تقرير الخطأ وكانت هذه المعلومات لها تأثير في الخصوصية/الأمان/البطارية/مساحة التخزين/الذاكرة، يجب:

• [C-SR] يُنصح بشدة بضبط إعداد المطوِّر تلقائيًا على "غير مفعَّل". يستوفي إطار عمل 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.9. تشفير مساحة تخزين البيانات

يجب أن تستوفي جميع الأجهزة متطلبات القسم 9.9.1. إنّ الأجهزة التي تم إطلاقها باستخدام مستوى واجهة برمجة تطبيقات أقدم من مستوى واجهة برمجة التطبيقات في هذا المستند معفاة من متطلبات القسمَين 9.9.2 و9.9.3، وبدلاً من ذلك يجب أن تستوفي المتطلبات الواردة في القسم 9.9 من مستند "تعريف التوافق مع Android" المرتبط بمستوى واجهة برمجة التطبيقات الذي تم إطلاق الجهاز عليه.

9.9.1. التشغيل المباشر

عمليات التنفيذ على الأجهزة:

• [C-0-1] يجب تنفيذ واجهات برمجة التطبيقات لوضع التشغيل المباشر حتى إذا كانت لا تتوافق مع ميزة "تشفير مساحة التخزين".

• [C-0-2] يجب مواصلة بث طلبات ACTION_LOCKED_BOOT_COMPLETED وACTION_USER_UNLOCKED للإشارة إلى التطبيقات المتوافقة مع ميزة "التمهيد المباشر" بأنّ مواقع التخزين المشفَّرة على الجهاز (DE) والمشفَّرة للبيانات المرسَلة (CE) متاحة للمستخدم.

9.9.2. متطلبات التشفير

عمليات التنفيذ على الأجهزة:

• [C-0-1] يجب تشفير بيانات التطبيق الخاصة (قسم /data) بالإضافة إلى قسم مساحة التخزين المشتركة للتطبيق (قسم /sdcard) إذا كان جزءًا دائمًا وغير قابل للإزالة من الجهاز.
• [C-0-2] يجب تفعيل تشفير مساحة تخزين البيانات تلقائيًا عند اكتمال تجربة الإعداد الأوّلي للمستخدم.

• [C-0-3] يجب استيفاء متطلبات تشفير مساحة تخزين البيانات المذكورة أعلاه من خلال تنفيذ إحدى الطريقتَين التاليتَين للتشفير:

  • التشفير على مستوى الملفات (FBE) وتشفير البيانات الوصفية كما هو موضّح في القسم 9.9.3.1.
  • التشفير على مستوى الكتل لكل مستخدم كما هو موضّح في القسم 9.9.3.2

9.9.3. طرق التشفير

في حال تشفير عمليات تنفيذ الأجهزة، يتم تنفيذ ما يلي:

• [C-1-1] يجب أن يتم تشغيل الجهاز بدون طلب بيانات الاعتماد من المستخدم والسماح للتطبيقات المتوافقة مع ميزة "التمهيد المباشر" بالوصول إلى مساحة التخزين المشفَّرة على الجهاز (DE) بعد بث رسالة ACTION_LOCKED_BOOT_COMPLETED.
• [C-1-2] يجب عدم السماح بالوصول إلى مساحة التخزين المشفَّرة لبيانات الاعتماد (CE) إلا بعد أن يفتح المستخدم قفل الجهاز من خلال تقديم بيانات اعتماده (مثل رمز المرور أو رقم التعريف الشخصي أو النمط أو بصمة الإصبع) ويتم بث رسالة ACTION_USER_UNLOCKED.
• [C-1-13] يجب عدم تقديم أي طريقة لفتح قفل مساحة التخزين المحمية بتقنية CE بدون بيانات الاعتماد المقدَّمة من المستخدم أو مفتاح وديعة مسجَّل أو تنفيذ ميزة "استئناف العمل بعد إعادة التشغيل" التي تستوفي المتطلبات الواردة في الفقرة 9.9.4.
• [C-1-4] يجب استخدام ميزة "التشغيل المتحقّق منه".

9.9.3.1. التشفير المستند إلى الملفات مع تشفير البيانات الوصفية

إذا كانت عمليات تنفيذ الأجهزة تستخدم ميزة "التشفير على مستوى الملفات" مع ميزة "التشفير على مستوى البيانات الوصفية"، فإنّها:

• [C-1-5] يجب تشفير محتوى الملفات والبيانات الوصفية لنظام الملفات باستخدام AES-256-XTS أو Adiantum. يشير معيار AES-256-XTS إلى معيار التشفير المتقدّم الذي يبلغ طول مفتاح التشفير فيه 256 بت، ويتم تشغيله في وضع XTS، ويبلغ الطول الكامل للمفتاح 512 بت. يشير Adiantum إلى Adiantum-XChaCha12-AES، كما هو محدّد في https://github.com/google/adiantum. البيانات الوصفية لنظام الملفات هي بيانات مثل أحجام الملفات والملكية والأوضاع والسمات الموسّعة (xattrs).
• [C-1-6] يجب تشفير أسماء الملفات باستخدام AES-256-CBC-CTS أو Adiantum.
• [C-1-12] إذا كان الجهاز يتضمّن تعليمات Advanced Encryption Standard (AES) (مثل ARMv8 Cryptography Extensions على الأجهزة المستندة إلى ARM أو AES-NI على الأجهزة المستندة إلى x86)، يجب استخدام الخيارات المستندة إلى AES أعلاه لتشفير اسم الملف ومحتوياته والبيانات الوصفية لنظام الملفات، وليس Adiantum.
• [C-1-13] يجب استخدام دالة اشتقاق مفاتيح قوية من الناحية التشفيرية وغير قابلة للعكس (مثل HKDF-SHA512) لاشتقاق أي مفاتيح فرعية مطلوبة (مثل مفاتيح كل ملف) من مفاتيح التشفير من جهة العميل وتشفير البيانات. تعني عبارة "قوية من الناحية التشفيرية وغير قابلة للعكس" أنّ دالة اشتقاق المفتاح تتمتع بأمان لا يقل عن 256 بت وتتصرف كـ عائلة دوال عشوائية زائفة على مدخلاتها.

• [C-1-14] يجب عدم استخدام مفاتيح أو مفاتيح فرعية التشفير المستند إلى الملفات (FBE) نفسها لأغراض تشفير مختلفة (مثل التشفير واستخراج المفتاح أو خوارزميات تشفير مختلفة).

• مفاتيح حماية مساحات تخزين CE وDE والبيانات الوصفية لنظام الملفات:

• [C-1-7] يجب أن يكون مرتبطًا بشكل تشفير بملف تخزين مفاتيح مستند إلى الأجهزة. يجب ربط ملف تخزين المفاتيح هذا بميزة "التمهيد المتحقّق منه" وجذر الثقة في جهازك.

• [C-1-8] يجب ربط مفاتيح التشفير المتقدّم ببيانات اعتماد شاشة القفل الخاصة بالمستخدم.
• [C-1-9] يجب ربط مفاتيح التشفير المتقدّم برمز مرور تلقائي عندما لا يحدّد المستخدم بيانات اعتماد شاشة القفل.
• [C-1-10] يجب أن تكون فريدة ومميّزة، أي أنّ مفتاح CE أو DE الخاص بأي مستخدم لا يتطابق مع مفاتيح CE أو DE الخاصة بأي مستخدم آخر.

• [C-1-11] يجب استخدام التشفيرات وأطوال المفاتيح والأوضاع المتوافقة بشكل إلزامي.

• يجب أن يكون بالإمكان تفعيل ميزة "التشغيل المباشر" في التطبيقات الأساسية المثبَّتة مسبقًا (مثل المنبّه والهاتف وMessenger).

يقدّم مشروع Android Open Source الإصدار الأصلي من ميزة "التشفير على مستوى الملفات" استنادًا إلى ميزة التشفير "fscrypt" في نواة Linux، وميزة "تشفير البيانات الوصفية" استنادًا إلى ميزة "dm-default-key" في نواة Linux.

9.9.3.2. التشفير على مستوى الكتلة لكل مستخدم

إذا كانت عمليات تنفيذ الأجهزة تستخدم التشفير على مستوى الكتلة لكل مستخدم، فإنّها:

• [C-1-1] يجب تفعيل ميزة "الوصول المتعدد للمستخدمين" كما هو موضّح في القسم 9.5.
• [C-1-2] يجب توفير أقسام لكل مستخدم، إما باستخدام أقسام أولية أو مجلدات منطقية.
• [C-1-3] يجب استخدام مفاتيح تشفير فريدة ومميّزة لكل مستخدم لتشفير أجهزة الكتل الأساسية.

• [C-1-4] يجب استخدام AES-256-XTS لتشفير أقسام المستخدم على مستوى الكتلة.

• المفاتيح التي تحمي الأجهزة المشفَّرة على مستوى الكتلة لكل مستخدم:

• [C-1-5] يجب أن يكون مرتبطًا بشكل تشفير بملف تخزين مفاتيح مستند إلى الأجهزة. يجب ربط ملف تخزين المفاتيح هذا بميزة "التمهيد المتحقّق منه" وجذر الثقة في جهازك.

• [C-1-6] يجب أن تكون مرتبطة ببيانات اعتماد شاشة القفل الخاصة بالمستخدم المقابل.

يمكن تنفيذ التشفير على مستوى الوحدات لكل مستخدم باستخدام ميزة "dm-crypt" في نواة Linux على الأقسام الخاصة بكل مستخدم.

9.9.4. استئناف العمل عند إعادة التشغيل

تتيح ميزة "استئناف التطبيقات بعد إعادة التشغيل" فتح قفل مساحة التخزين في وضع "التشغيل المتعدّد" لجميع التطبيقات، بما في ذلك التطبيقات التي لا تتيح ميزة "التشغيل المباشر" بعد، وذلك بعد إعادة التشغيل التي تبدأ من خلال تحديث OTA. تتيح هذه الميزة للمستخدمين تلقّي إشعارات من التطبيقات المثبَّتة بعد إعادة التشغيل.

يجب مواصلة تنفيذ ميزة "استئناف العمل بعد إعادة التشغيل" لضمان أنّه عندما يقع الجهاز في أيدي مهاجم، سيكون من الصعب جدًا على هذا المهاجم استرداد بيانات المستخدم المشفَّرة باستخدام تقنية "التشفير من جهة العميل"، حتى إذا كان الجهاز مفعَّلاً وتم فتح قفل مساحة التخزين المشفَّرة باستخدام تقنية "التشفير من جهة العميل"، وكان المستخدم قد فتح قفل الجهاز بعد تلقّي تحديث OTA. لضمان مقاومة الهجمات من الداخل، نفترض أيضًا أنّ المهاجم يحصل على مفاتيح التوقيع التشفيرية للبث.

وعلى وجه التحديد:

• [C-0-1] يجب ألا يكون تخزين CE قابلاً للقراءة حتى للمهاجم الذي يمتلك الجهاز فعليًا ويحصل بعد ذلك على الإمكانات والقيود التالية:

  • يمكن استخدام مفتاح التوقيع لأي مورّد أو شركة لتوقيع رسائل عشوائية.
  • يمكن أن يؤدي ذلك إلى تلقّي الجهاز تحديثًا من خلال شبكة الجوّال.
  • يمكن تعديل تشغيل أي أجهزة (AP أو فلاش أو غير ذلك) باستثناء ما هو موضّح أدناه، ولكن يتطلّب هذا التعديل تأخيرًا لمدة ساعة على الأقل ودورة طاقة تؤدي إلى فقدان محتوى ذاكرة الوصول العشوائي.
  • لا يمكن تعديل تشغيل الأجهزة المقاومة للتلاعب (مثل Titan M).
  • لا يمكن قراءة ذاكرة الوصول العشوائي للجهاز المباشر.
  • لا يمكن الحصول على بيانات اعتماد المستخدم (رقم التعريف الشخصي أو النقش أو كلمة المرور) أو إجباره على إدخالها.

على سبيل المثال، فإنّ تنفيذ الجهاز الذي ينفذ جميع الأوصاف المتوفّرة هنا ويتوافق معها سيكون متوافقًا مع [C-0-1].

9.10. سلامة الجهاز

تضمن المتطلبات التالية توفير شفافية بشأن حالة سلامة الجهاز. عمليات التنفيذ على الأجهزة:

• [C-0-1] يجب الإبلاغ بشكل صحيح من خلال طريقة System API PersistentDataBlockManager.getFlashLockState() عمّا إذا كانت حالة أداة تحميل البرامج الثابتة تسمح بفلاش صورة النظام. يتم حجز الحالة FLASH_LOCK_UNKNOWN لعمليات تنفيذ الأجهزة التي يتم ترقيتها من إصدار سابق من Android لم تكن فيه طريقة واجهة برمجة التطبيقات الجديدة هذه متاحة للنظام.

• [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] إذا كانت هناك شرائح متعددة منفصلة في الجهاز (مثل الراديو ومعالج الصور المخصّص)، يُنصح بشدة بمراقبة كل مرحلة من مراحل عملية تشغيل كل شريحة من هذه الشرائح عند تشغيل الجهاز.
• [C-1-8] يجب استخدام مساحة تخزين مقاومة للتلاعب: لتخزين ما إذا كان مُشغِّل التمهيد غير مقفل. تعني ميزة "التخزين الذي يكشف التلاعب" أنّ أداة تحميل التشغيل يمكنها رصد ما إذا تم التلاعب بوحدة التخزين من داخل نظام التشغيل Android.
• [C-1-9] يجب أن يطلب الجهاز من المستخدم تأكيدًا فعليًا قبل السماح بالانتقال من وضع قفل برنامج الإقلاع إلى وضع فتح قفل برنامج الإقلاع أثناء استخدام الجهاز.
• [C-1-10] يجب تنفيذ ميزة حماية التراجع عن التغييرات في الأقسام التي يستخدمها Android (مثل أقسام التمهيد والنظام) واستخدام مساحة تخزين مقاومة للتلاعب لتخزين البيانات الوصفية المستخدَمة لتحديد الحد الأدنى المسموح به لإصدار نظام التشغيل.
• [C-SR] يُنصح بشدة بالتحقّق من جميع ملفات APK الخاصة بالتطبيقات المميّزة باستخدام سلسلة ثقة تستند إلى أقسام محمية من خلال ميزة "التمهيد التحقق منه".
• [C-SR] يُنصح بشدة بالتحقق من أي عناصر قابلة للتنفيذ يحمّلها تطبيق مفوَّض من خارج ملف APK (مثل الرمز البرمجي المحمَّل ديناميكيًا أو الرمز البرمجي المجمَّع) قبل تنفيذها أو يُنصح بشدة بعدم تنفيذها على الإطلاق.
• يجب أن توفّر الحماية من العودة إلى الإصدارات السابقة لأي مكوّن يتضمّن برنامجًا ثابتًا (مثل المودم أو الكاميرا)، ويجب أن تستخدم مساحة تخزين مقاومة للتلاعب لتخزين البيانات الوصفية المستخدَمة لتحديد الحد الأدنى للإصدار المسموح به.

إذا سبق أن تم إطلاق عمليات تنفيذ الأجهزة بدون توفير متطلبات C-1-8 إلى C-1-10 على إصدار أقدم من Android ولا يمكن إضافة متطلبات هذه المتطلبات من خلال تحديث لنظام التشغيل، قد يتم إعفاؤها من المتطلبات.

يقدّم "مشروع مفتوح المصدر لنظام Android" الإصدار الأصلي من هذه الميزة في مستودع external/avb/، والذي يمكن دمجه في أداة تحميل البرامج الثابتة المستخدَمة لتحميل نظام Android.

عمليات التنفيذ على الأجهزة:

• [C-0-3] يجب أن تتيح إمكانية التحقّق من محتوى الملف باستخدام التشفير ومقارنته بمفتاح موثوق به بدون قراءة الملف بأكمله.
• [C-0-4] يجب عدم السماح بنجاح طلبات القراءة على ملف محمي عندما لا يتم التحقّق من محتوى القراءة باستخدام مفتاح موثوق.

إذا سبق أن تم إطلاق عمليات تنفيذ الأجهزة بدون إمكانية التحقّق من محتوى الملف باستخدام مفتاح موثوق به على إصدار Android سابق ولا يمكن إضافة ميزة هذه الميزة من خلال تحديث لنظام التشغيل، قد يتم إعفاؤها من الشرط. يقدّم مشروع Android Open Source الإصدار الأصلي من هذه الميزة استنادًا إلى ميزة fs-verity في نواة Linux.

عمليات التنفيذ على الأجهزة:

• [C-R] يُنصح بتوفُّر Android Protected Confirmation API.

إذا كانت عمليات تنفيذ الأجهزة متوافقة مع واجهة برمجة التطبيقات Android Protected Confirmation API، يجب أن تستوفي المتطلبات التالية:

• [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] يجب أن تحدّ المصادقة على شاشة القفل من عدد المحاولات وأن تتضمّن خوارزمية خفض معدّل تكرار المحاولات بشكلٍ تصاعدي. بعد 150 محاولة غير ناجحة، يجب أن يكون التأخير 24 ساعة على الأقل لكل محاولة.
• يجب عدم وضع حدّ لعدد المفاتيح التي يمكن إنشاؤها.

عندما يتيح تطبيق الجهاز شاشة قفل آمنة، يتم تنفيذ ما يلي:

• [C-1-1] يجب الاحتفاظ بنسخة احتياطية من عملية تنفيذ ملف تخزين المفاتيح باستخدام بيئة تنفيذ معزولة.
• [C-1-2] يجب أن تتضمّن عمليات تنفيذ خوارزميات التشفير RSA وAES وECDSA و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 ثانية. قد لا تتضمّن الأجهزة المخصّصة للسيارات التي تُقفل الشاشة عند إيقاف تشغيل وحدة التحكّم أو تبديل المستخدم إعداد مهلة وضع السكون.

9.11.1. شاشة القفل الآمنة والمصادقة

يتّبع تطبيق AOSP نموذج مصادقة متعدّد المستويات، حيث يمكن أن تستند المصادقة الأساسية إلى قاعدة معلومات، ويمكن أن يتم دعمها إما بمقياس حيوي ثانوي قوي أو بوسائل ثالثية أضعف.

عمليات التنفيذ على الأجهزة:

• [C-SR] يُنصح بشدة بضبط طريقة واحدة فقط من الطرق التالية كطريقة المصادقة الأساسية:
  • رقم تعريف شخصي رقمي
  • كلمة مرور أبجدية رقمية
  • نمط تمرير سريع على شبكة من النقاط 3×3 بالضبط

يُرجى العِلم أنّه تتم الإشارة إلى طرق المصادقة المذكورة أعلاه على أنّها طرق المصادقة الأساسية المُقترَحة في هذا المستند.

إذا كانت عمليات تنفيذ الأجهزة تضيف طرق المصادقة الأساسية المقترَحة أو تعدّلها وتستخدم طريقة مصادقة جديدة كطريقة آمنة لقفل الشاشة، يجب أن تستوفي طريقة المصادقة الجديدة الشروط التالية:

• [C-2-1] يجب أن تكون طريقة مصادقة المستخدم كما هو موضّح في طلب مصادقة المستخدم لاستخدام المفتاح.

إذا كانت عمليات تنفيذ الجهاز تضيف طرق مصادقة أو تعدّلها لفتح قفل الشاشة إذا كانت تستند إلى سر معروف وتستخدم طريقة مصادقة جديدة ليتم التعامل معها كطريقة آمنة لقفل الشاشة:

• [C-3-1] يجب أن تكون الانتروبيّة لأقصر طول مسموح به للإدخالات أكبر من 10 بت.
• [C-3-2] يجب أن يكون الحد الأقصى للانتروبيا لجميع الإدخالات المحتملة أكبر من 18 بت.
• [C-3-3] يجب ألّا تستبدل طريقة المصادقة الجديدة أيًا من طرق المصادقة الأساسية المقترَحة (أي رقم التعريف الشخصي والنقش وكلمة المرور) التي تم تنفيذها وتوفيرها في AOSP.
• [C-3-4] يجب إيقاف طريقة المصادقة الجديدة عندما يضبط تطبيق "وحدة التحكّم بسياسة الجهاز" سياسة جودة كلمة المرور من خلال طريقة DevicePolicyManager.setPasswordQuality() باستخدام ثابت جودة أكثر تقييدًا من PASSWORD_QUALITY_SOMETHING.
• [C-3-5] يجب أن تعتمد طرق المصادقة الجديدة على طرق المصادقة الأساسية المُقترَحة (مثل رقم التعريف الشخصي أو النمط أو كلمة المرور) مرة واحدة كل 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] يجب إيقاف الطرق إذا ضبط تطبيق "وحدة التحكّم بسياسة الجهاز" سياسة جودة كلمة المرور من خلال طريقة 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] يجب إيقاف الطريقة الجديدة والسماح باستخدام إحدى طرق المصادقة الأساسية المقترَحة فقط لإلغاء قفل الشاشة عندما يضبط تطبيق "وحدة التحكّم في سياسة الجهاز" السياسة باستخدام طريقة DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) أو طريقة DevicePolicyManager.setPasswordQuality() مع ثابت جودة أكثر تقييدًا من PASSWORD_QUALITY_UNSPECIFIED.
• [C-6-3] يجب أن يُطلب من المستخدم إدخال إحدى طرق المصادقة الأساسية المُقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) مرة واحدة على الأقل كل 4 ساعات أو أقل.
• [C-6-4] يجب عدم التعامل مع الطريقة الجديدة على أنّها شاشة قفل آمنة، ويجب أن تلتزم بالقيود الواردة في C-8 أدناه.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة قفل آمنة وتتضمن وكيل ثقة واحدًا أو أكثر، والذي ينفِّذ واجهة برمجة التطبيقات TrustAgentService System API، يجب أن تستوفي المتطلبات التالية:

• [C-7-1] يجب أن يتضمّن الجهاز مؤشرًا واضحًا في قائمة الإعدادات وعلى شاشة القفل عند تأجيل قفل الجهاز أو إمكانية فتح قفله من قِبل وكلاء الثقة. على سبيل المثال، يستوفي AOSP هذا الشرط من خلال عرض وصف نصي لـ "إعداد القفل التلقائي" و "قفل زر التشغيل على الفور" في قائمة الإعدادات ورمزًا مميزًا على شاشة القفل.
• [C-7-2] يجب الالتزام بجميع واجهات برمجة تطبيقات وكيل الثقة في فئة DevicePolicyManager وتنفيذها بالكامل، مثل الثابت KEYGUARD_DISABLE_TRUST_AGENTS.
• [C-7-3] يجب عدم تنفيذ وظيفة TrustAgentService.addEscrowToken() بالكامل على جهاز يُستخدَم كجهاز شخصي أساسي (مثل الجهاز المحمول)، ولكن يجوز تنفيذ الوظيفة بالكامل على عمليات تنفيذ الأجهزة التي تتم مشاركتها عادةً (مثل Android Television أو جهاز Automotive).
• [C-7-4] يجب تشفير جميع الرموز المميّزة المخزّنة التي أضافها TrustAgentService.addEscrowToken().
• [C-7-5] يجب عدم تخزين مفتاح التشفير أو رمز الضمان على الجهاز نفسه الذي يتم استخدام المفتاح عليه. على سبيل المثال، يُسمح لمفتاح مخزّن على هاتف بفتح قفل حساب مستخدم على التلفزيون. بالنسبة إلى الأجهزة المخصّصة للسيارات، لا يُسمح بتخزين رمز الاعتماد الخاص بالحجز في أي جزء من المركبة.
• [C-7-6] يجب إبلاغ المستخدم بالآثار الأمنية قبل تفعيل الرمز المميّز للحفظ المؤقت من أجل فك تشفير مساحة تخزين البيانات.
• [C-7-7] يجب أن تتوفّر آلية احتياطية لاستخدام إحدى طرق المصادقة الأساسية المقترَحة.
• [C-7-8] يجب أن يُطلب من المستخدم إدخال إحدى طرق المصادقة الأساسية المُقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) مرة واحدة على الأقل كل 72 ساعة أو أقل ما لم تكن سلامة المستخدم (مثل تشتيت انتباه السائق) موضع قلق.
• [C-7-9] يجب أن يُطلب من المستخدم إثبات هويته باستخدام إحدى طرق المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النمط أو كلمة المرور) كما هو موضّح في [C-1-7] و[C-1-8] في الفقرة 7.3.10، ما لم تكن سلامة المستخدم (مثل تشتيت انتباه السائق) موضع قلق.
• [C-7-10] يجب عدم التعامل معها كشاشة قفل آمنة ويجب أن تلتزم بالقيود الواردة في C-8 أدناه.
• [C-7-11] يجب عدم السماح لخدمات TrustAgent على الأجهزة الشخصية الأساسية (مثل الأجهزة الجوّالة) بفتح قفل الجهاز، ولا يمكن استخدامها إلا للحفاظ على حالة فتح قفل جهاز سبق أن تم فتح قفله لمدة تصل إلى 4 ساعات كحد أقصى. يستوفي التنفيذ التلقائي لواجهة TrustManagerService في AOSP هذا الشرط.
• [C-7-12] يجب استخدام قناة اتصال آمنة من ناحية التشفير (مثل UKEY2) لتمرير رمز التأمين من جهاز التخزين إلى الجهاز المستهدَف.

إذا كانت عمليات تنفيذ الأجهزة تضيف طرق مصادقة أو تعدّلها لفتح قفل شاشة غير آمنة كما هو موضّح أعلاه، وتستخدم طريقة مصادقة جديدة لفتح قفل شاشة القفل:

• [C-8-1] يجب إيقاف الطريقة الجديدة عندما يضبط تطبيق "وحدة التحكّم بسياسة الجهاز" سياسة جودة كلمة المرور من خلال طريقة DevicePolicyManager.setPasswordQuality() باستخدام ثابت جودة أكثر تقييدًا من PASSWORD_QUALITY_UNSPECIFIED.
• [C-8-2] يجب عدم إعادة ضبط أدوات ضبط مدة صلاحية كلمة المرور التي ضبطها DevicePolicyManager.setPasswordExpirationTimeout().
• [C-8-3] يجب عدم إتاحة واجهة برمجة تطبيقات للاستخدام من قِبل التطبيقات التابعة لجهات خارجية من أجل تغيير حالة القفل.

9.11.2. StrongBox

يسمح نظام "متجر مفاتيح Android" لمطوّري التطبيقات بتخزين مفاتيح التشفير في وحدة معالجة آمنة مخصّصة، بالإضافة إلى بيئة التنفيذ المعزولة الموضّحة أعلاه. يُعرف هذا المعالج الآمن المخصّص باسم "StrongBox". تحدِّد المتطلبات C-1-3 إلى C-1-11 أدناه المتطلبات التي يجب أن يستوفيها الجهاز للتأهّل كجهاز StrongBox.

عمليات تنفيذ الأجهزة التي تتضمّن معالجًا آمنًا مخصّصًا:

• [C-SR] يُنصح بشدة بتوفير 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] يجب أن يتضمّن الجهاز المعتمد وفقًا لملف حماية الشرائح الإلكترونية الآمنة BSI-CC-PP-0084-2014 أو الذي تم تقييمه من قِبل مختبر اختبار معتمَد على مستوى البلد والذي يتضمّن تقييمًا للثغرات الأمنية العالية الخطورة وفقًا لمعيار المعايير المشتركة لتطبيق احتمالية الهجوم على البطاقات الذكية.
  • [C-1-11] يجب أن تتضمّن البرامج الثابتة التي يتم تقييمها من قِبل مختبر اختبار معتمَد على مستوى البلد، مع تضمين تقييم للثغرات الأمنية ذات احتمالية الهجوم العالية وفقًا لمعيار المعايير المشتركة لتطبيق احتمالية الهجوم على البطاقات الذكية.
  • [C-SR] يُنصح بشدة بتضمين الأجهزة التي يتم تقييمها باستخدام "هدف الأمان"، ومستوى ضمان التقييم (EAL) 5، مع إضافة AVA_VAN.5. من المرجّح أن تصبح شهادة EAL 5 شرطًا أساسيًا في إصدار مستقبلي.

• [C-SR] يُنصح بشدة بتوفير مقاومة هجمات المستخدمين الداخليين (IAR)، ما يعني أنّ المستخدم الداخلي الذي يمكنه الوصول إلى مفاتيح توقيع البرامج الثابتة لا يمكنه إنشاء برنامج ثابت يؤدي إلى تسرُّب الأسرار من StrongBox أو تجاوز متطلبات الأمان الوظيفي أو تفعيل الوصول إلى بيانات المستخدمين الحسّاسة بأي شكل آخر. إنّ الطريقة المقترَحة لتنفيذ IAR هي عدم السماح بتحديثات البرامج الثابتة إلا عند تقديم كلمة مرور المستخدم الأساسي من خلال IAuthSecret HAL.

9.11.3. بيانات اعتماد الهوية

يتم تحديد نظام بيانات الاعتماد الخاصة بالهوية وتحقيقه من خلال تنفيذ جميع واجهات برمجة التطبيقات في حزمة android.security.identity.*. تسمح واجهات برمجة التطبيقات هذه لمطوّري التطبيقات بتخزين مستندات هوية المستخدم واستعادتها. عمليات التنفيذ على الأجهزة:

• [C-SR] يُنصح بشدة بتنفيذ نظام بيانات الاعتماد الخاصة بالهوية.

في حال تنفيذ عمليات تنفيذ الأجهزة لنظام بيانات اعتماد الهوية، يتم تنفيذ ما يلي:

• [C-0-1] يجب أن تُعرِض طريقة IdentityCredentialStore#getInstance() قيمة غير صفرية.

• [C-0-2] يجب تنفيذ نظام بيانات الاعتماد الخاصة بالهوية (مثل واجهات برمجة تطبيقات android.security.identity.*) باستخدام رمز برمجي يتواصل مع تطبيق موثوق به في منطقة معزولة بشكل آمن عن الرمز البرمجي الذي يعمل على النواة والإصدارات الأحدث. يجب أن تحظر ميزة "العزل الآمن" جميع الآليات المحتملة التي يمكن من خلالها لرمز kernel أو مساحة المستخدم الوصول إلى الحالة الداخلية للبيئة المعزولة، بما في ذلك DMA.

• [C-0-3] يجب تنفيذ العمليات التشفيرية اللازمة لتنفيذ نظام بيانات الاعتماد الخاصة بالهوية (مثل واجهات برمجة تطبيقات android.security.identity.*) بالكامل في التطبيق الموثوق به، ويجب ألا تغادر مادة المفتاح الخاص بيئة التنفيذ المعزولة أبدًا ما لم تطلب واجهات برمجة التطبيقات ذات المستوى الأعلى ذلك على وجه التحديد (مثل الطريقة createEphemeralKeyPair()‎).

• [C-0-4] يجب تنفيذ التطبيق الموثوق به بطريقة لا تتأثر بها خصائص الأمان (على سبيل المثال، لا يتم الإفصاح عن بيانات بيانات الاعتماد ما لم يتم استيفاء شروط التحكّم في الوصول، ولا يمكن إنشاء عناوين MAC لبيانات عشوائية) حتى إذا كان Android يتضمّن أخطاء أو تم اختراقه.

9.12. حذف البيانات

جميع عمليات التنفيذ على الأجهزة:

• [C-0-1] يجب أن يوفّر التطبيق للمستخدمين آلية لإجراء "إعادة ضبط الجهاز على الإعدادات الأصلية".
• [C-0-2] يجب حذف جميع البيانات في نظام ملفات userdata.
• [C-0-3] يجب حذف البيانات بطريقة تتوافق مع معايير الصناعة ذات الصلة، مثل NIST SP800-88.
• [C-0-4] يجب بدء عملية "إعادة الضبط على الإعدادات الأصلية" المذكورة أعلاه عند استدعاء واجهة برمجة التطبيقات DevicePolicyManager.wipeData() من خلال تطبيق "وحدة التحكّم بسياسة الجهاز" للمستخدم الأساسي.
• قد يوفّر خيارًا سريعًا لمحو البيانات لا يؤدي إلا إلى محو البيانات المنطقية.

9.13. وضع التشغيل الآمن

يقدّم نظام التشغيل Android وضع "التشغيل الآمن" الذي يسمح للمستخدمين بالتمهيد إلى وضع يُسمح فيه بتشغيل تطبيقات النظام المثبّتة مسبقًا فقط وإيقاف جميع التطبيقات التابعة لجهات خارجية. يُعرف هذا الوضع باسم "وضع التشغيل الآمن"، وهو يمنح المستخدم إمكانية إلغاء تثبيت التطبيقات التابعة لجهات خارجية التي يُحتمل أن تكون ضارة.

عمليات تنفيذ الأجهزة هي:

• [SR] STRONGLY RECOMMENDED to implement Safe Boot Mode.

في حال تنفيذ عمليات تنفيذ الأجهزة لوضع التشغيل الآمن، يتم تنفيذ ما يلي:

• [C-1-1] يجب أن يوفّر الجهاز للمستخدم خيارًا للدخول إلى وضع "التشغيل الآمن" بطريقة لا يمكن للتطبيقات التابعة لجهات خارجية المثبّتة على الجهاز إيقافها، إلا عندما يكون التطبيق التابع لجهة خارجية هو وحدة تحكّم في سياسة الجهاز وضبط علامة UserManager.DISALLOW_SAFE_BOOT على "صحيح".

• [C-1-2] يجب أن يمنح التطبيق المستخدم إمكانية إلغاء تثبيت أي تطبيقات تابعة لجهات خارجية في "الوضع الآمن".

• يجب أن يوفّر للمستخدم خيارًا للدخول إلى "وضع التشغيل الآمن" من قائمة التشغيل باستخدام سير عمل مختلف عن سير عمل التشغيل العادي.

9.14. عزل نظام المركبات الآلية

من المتوقّع أن تتبادل أجهزة Android Automotive البيانات مع الأنظمة الفرعية المهمة للمركبة باستخدام HAL للمركبة لإرسال الرسائل واستلامها عبر شبكات المركبات، مثل ناقل CAN.

يمكن تأمين عملية تبادل البيانات من خلال تنفيذ ميزات الأمان أسفل طبقات إطار عمل Android لمنع التفاعل الضار أو غير المقصود مع هذه الأنظمة الفرعية.

9.15. خطط الاشتراك

تشير "خطط الاشتراك" إلى تفاصيل خطة العلاقة مع جهة الفوترة التي يوفّرها مشغّل شبكة الجوّال من خلال SubscriptionManager.setSubscriptionPlans().

جميع عمليات التنفيذ على الأجهزة:

• [C-0-1] يجب إعادة خطط الاشتراك إلى تطبيق مشغّل شبكة الجوّال الذي قدّمها في الأصل فقط.
• [C-0-2] يجب عدم الاحتفاظ بنسخة احتياطية من خطط الاشتراك أو تحميلها عن بُعد.
• [C-0-3] يجب السماح فقط بعمليات إلغاء الإعدادات، مثل SubscriptionManager.setSubscriptionOverrideCongested()، من تطبيق مشغّل شبكة الجوّال الذي يقدّم حاليًا خطط اشتراك صالحة.

9.16. نقل بيانات التطبيقات

إذا كانت عمليات تنفيذ التطبيقات على الأجهزة تتضمّن إمكانية نقل البيانات من جهاز إلى جهاز آخر ولا تحدّ من بيانات التطبيق التي تنسخها إلى ما ضبطه مطوّر التطبيق في البيان من خلال السمة android:fullBackupContent، يجب استيفاء الشروط التالية:

• [C-1-1] يجب عدم بدء عمليات نقل بيانات التطبيق من الأجهزة التي لم يضبط المستخدم فيها مصادقة أساسية كما هو موضّح في 9.11.1 شاشة القفل الآمنة والمصادقة.
• [C-1-2] يجب تأكيد المصادقة الأساسية على الجهاز المصدر بأمان والتأكّد من نية المستخدم في نسخ البيانات على الجهاز المصدر قبل نقل أي بيانات.
• [C-1-3] يجب استخدام شهادة مفتاح الأمان لضمان أنّ كلّ من الجهاز المصدر والجهاز المستهدَف في عملية نقل البيانات من جهاز إلى آخر هما جهازَا Android شرعيَين وأنّهما مزوّدان ببرنامج إقلاع مقفل.
• [C-1-4] يجب نقل بيانات التطبيق إلى التطبيق نفسه على الجهاز المستهدَف فقط، باستخدام اسم الحزمة وشهادة التوقيع نفسها.
• [C-1-5] يجب أن تعرض قائمة الإعدادات في الجهاز المصدر مؤشرًا على أنّه تم نقل البيانات من خلال عملية نقل بيانات من جهاز إلى آخر. يجب ألّا يتمكّن المستخدم من إزالة هذا الرمز.

10. اختبار توافق البرامج

يجب أن تجتاز عمليات تنفيذ الأجهزة جميع الاختبارات الموضّحة في هذا القسم. يُرجى العلم أنّه لا تتوفّر حزمة اختبار برامج شاملة بالكامل. لهذا السبب، ننصح بشدة جهات تنفيذ الأجهزة بإجراء الحد الأدنى من التغييرات على الإصدار المرجعي والتنفيذ المفضّل لنظام Android المتاح من "المشروع المفتوح المصدر لنظام Android". سيؤدي ذلك إلى تقليل خطر إدخال أخطاء تؤدي إلى حدوث حالات عدم توافق تتطلّب إعادة العمل وإجراء تحديثات محتملة على الأجهزة.

10.1. مجموعة أدوات اختبار التوافق

عمليات التنفيذ على الأجهزة:

• [C-0-1] يجب اجتياز مجموعة اختبار التوافق مع Android (CTS) المتوفّرة من "المشروع المفتوح المصدر لنظام Android"، باستخدام الإصدار النهائي من البرنامج المُرسَل على الجهاز.

• [C-0-2] يجب ضمان التوافق في حالات الغموض في CTS وأي عمليات إعادة تنفيذ لأجزاء من رمز المصدر المرجعي.

تم تصميم CTS ليتم تشغيله على جهاز حقيقي. مثل أي برنامج، قد يحتوي CTS نفسه على أخطاء. سيتم إصدار إصدارات من مجموعة اختبار التوافق (CTS) بشكل مستقل عن "تعريف التوافق" هذا، وقد يتم إصدار عدّة نُسخ من مجموعة اختبار التوافق لنظام التشغيل Android 11.

عمليات التنفيذ على الأجهزة:

• [C-0-3] يجب اجتياز أحدث إصدار من CTS متاح في وقت اكتمال برنامج الجهاز.

• يجب استخدام التنفيذ المرجعي في شجرة Android Open Source قدر الإمكان.

10.2. أداة إثبات ملكية CTS

يتم تضمين أداة التحقّق من CTS في مجموعة اختبار التوافق، ومن المفترض أن يشغّلها مشغل بشري لاختبار الوظائف التي لا يمكن اختبارها من خلال نظام آلي، مثل الأداء الصحيح للكاميرا وأجهزة الاستشعار.

عمليات التنفيذ على الأجهزة:

• [C-0-1] يجب تنفيذ جميع الحالات السارية بشكل صحيح في أداة التحقّق من CTS.

يتضمّن أداة التحقّق من توافق الأجهزة مع معيار CTS اختبارات لأنواع كثيرة من الأجهزة، بما في ذلك بعض الأجهزة الاختيارية.

عمليات التنفيذ على الأجهزة:

• [C-0-2] يجب أن يجتاز الجهاز جميع اختبارات الأجهزة التي يمتلكها. على سبيل المثال، إذا كان الجهاز يحتوي على مقياس تسارع، يجب أن ينفذ بشكل صحيح نموذج اختبار مقياس التسارع في أداة التحقّق من التوافق (CTS Verifier).

يجوز تخطّي أو حذف حالات اختبار الميزات التي يُشار إليها على أنّها اختيارية في "مستند تعريف معايير التوافق" هذا.

• [C-0-2] يجب أن يعمل كل جهاز وكل إصدار بشكل صحيح مع أداة CTS Verifier، كما هو موضّح أعلاه. ومع ذلك، بما أنّ العديد من النُسخ متشابهة جدًا، لا يُتوقّع من جهات تنفيذ الأجهزة تشغيل أداة CTS Verifier صراحةً على النُسخ التي تختلف بطرق بسيطة فقط. على وجه التحديد، قد يتم حذف اختبار أداة التحقّق من CTS في عمليات تنفيذ الأجهزة التي تختلف عن عملية تنفيذ اجتازت أداة التحقّق من CTS فقط من خلال مجموعة اللغات المضمّنة والعلامة التجارية وما إلى ذلك.

11. البرامج القابلة للتحديث

• [C-0-1] يجب أن تتضمّن عمليات تنفيذ الأجهزة آلية لاستبدال برنامج النظام بالكامل. ولا يلزم أن تُجري الآلية ترقيات "مباشرة"، أي أنّه قد يلزم إعادة تشغيل الجهاز. يمكن استخدام أي طريقة، شرط أن تكون قادرة على استبدال كامل البرامج المثبَّتة مسبقًا على الجهاز. على سبيل المثال، سيستوفي أيّ من النهجَين التاليَين هذا الشرط:

  • تنزيل "التحديثات عبر شبكة غير سلكية (OTA)" مع التحديث بلا إنترنت من خلال إعادة التشغيل
  • التحديثات "المرتبطة" عبر USB من جهاز كمبيوتر مضيف
  • يتم إجراء التحديثات "بلا إنترنت" من خلال إعادة تشغيل الجهاز وإجراء التحديث من ملف على مساحة تخزين قابلة للإزالة.

• [C-0-2] يجب أن تتيح آلية التحديث المستخدَمة إجراء التحديثات بدون محو بيانات المستخدمين. وهذا يعني أنّ آلية التحديث يجب أن تحافظ على البيانات الخاصة بالتطبيق والبيانات المشتركة للتطبيق. يُرجى العِلم أنّ برنامج Android الأساسي يتضمّن آلية تحديث تستوفي هذا الشرط.

• [C-0-3] يجب توقيع التحديث بالكامل، ويجب أن تتحقّق آلية التحديث على الجهاز من التحديث والتوقيع مقارنةً بمفتاح عام مخزّن على الجهاز.

• [C-SR] يُنصح بشدة باستخدام آلية التوقيع لتجزئة التحديث باستخدام SHA-256 والتحقّق من التجزئة مقارنةً بالمفتاح العام باستخدام ECDSA NIST P-256.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية الاتصال بشبكة بيانات غير محدودة، مثل ملف 802.11 أو شبكة المنطقة الشخصية (PAN) عبر البلوتوث، يجب استيفاء الشروط التالية:

• [C-1-1] يجب أن يتيح الجهاز تنزيل التحديثات من خلال شبكة الجوّال مع تحديث بلا إنترنت من خلال إعادة التشغيل.

بالنسبة إلى عمليات تنفيذ الأجهزة التي يتم تشغيلها باستخدام الإصدار 6.0 من نظام التشغيل Android والإصدارات الأحدث، من المفترض أن تتيح آلية التحديث التحقّق من أنّ صورة النظام ثنائية مطابقة للنتيجة المتوقّعة بعد تحديث OTA. يلبي هذا الشرط تنفيذ التحديثات عبر الهواء المستند إلى الحِزم في "المشروع المفتوح المصدر لنظام Android"، والذي تمت إضافته منذ Android 5.1.

ويجب أيضًا أن تتيح عمليات تنفيذ الأجهزة تحديثات نظام A/B. ينفِّذ نظام التشغيل AOSP هذه الميزة باستخدام واجهة برمجة التطبيقات لنظام التحكّم في عملية التمهيد.

إذا تم العثور على خطأ في عملية تنفيذ الجهاز بعد طرحه ولكن خلال فترة زمنية معقولة للمنتج يتم تحديدها بالتشاور مع فريق التوافق في Android للتأثير في توافق التطبيقات التابعة لجهات خارجية، يتم اتّخاذ الإجراءات التالية:

• [C-2-1] على مُنفِّذ الجهاز تصحيح الخطأ من خلال تحديث برنامج متاح يمكن تطبيقه وفقًا للآلية الموضّحة للتو.

يتضمّن نظام Android ميزات تتيح لتطبيق "مالك الجهاز" (في حال توفّره) التحكّم في تثبيت تحديثات النظام. إذا أبلغ نظام تحديث النظام الفرعي للأجهزة عن android.software.device_admin، يتم تنفيذ ما يلي:

• [C-3-1] يجب تنفيذ السلوك الموضّح في فئة SystemUpdatePolicy.

12. سجلّ تغييرات المستندات

في ما يلي ملخّص للتغييرات التي طرأت على تعريف التوافق في هذا الإصدار:

• سجلّ التغييرات في المستند

في ما يلي ملخّص للتغييرات التي طرأت على أقسام الأفراد:

1. المقدّمة
2. أنواع الأجهزة
3. البرامج
4. تجميع التطبيقات
5. الوسائط المتعددة
6. أدوات المطوّرين وخياراتهم
7. توافق الأجهزة
8. الأداء واستهلاك الطاقة
9. نموذج الأمان
10. اختبار توافق البرامج
11. البرامج القابلة للتحديث
12. سجلّ تغييرات المستندات
13. التواصل معنا

12.1. نصائح حول الاطّلاع على سجلّ التغييرات

يتم وضع علامة على التغييرات على النحو التالي:

• CDD
  تغييرات جوهرية في متطلبات التوافق

• مستندات Google
  التغييرات المتعلقة بالمظهر أو التصميم

للحصول على أفضل تجربة عرض، يمكنك إلحاق مَعلمتَي pretty=full وno-merges لعنوان URL بعناوين URL لسجلّ التغييرات.

13. التواصل معنا

يمكنك الانضمام إلى منتدى توافق Android وطلب الحصول على توضيحات أو طرح أي مشاكل تعتقد أنّ المستند لا يتناولها.