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

‫1. مقدّمة

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

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

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

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

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

• أن يكون مزوّدًا بمصدر طاقة يسمح بالتنقّل، مثل بطارية
• أن يكون حجم الشاشة القطري يتراوح بين 2.5 و8 بوصات

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

2.2.1. الأجهزة

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

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

إذا كانت عمليات تنفيذ الأجهزة الجوّالة تدّعي توفّر شاشات النطاق العالي الديناميكية من خلال 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.5/H-0-1] يجب أن يتضمّن وضع التوافق مع التطبيقات القديمة كما هو منفذ في الرمز البرمجي المفتوح المصدر لنظام Android. وهذا يعني أنّه يجب ألّا تغيّر عمليات تنفيذ الأجهزة عوامل التفعيل أو الحدود الدنيا التي يتم عندها تفعيل وضع التوافق، ويجب ألّا تغيّر سلوك وضع التوافق نفسه.
• [7.2.1/H-0-1] يجب أن تتضمّن التطبيقات إمكانية استخدام تطبيقات "محرر أسلوب الإدخال" (IME) التابعة لجهات خارجية.
• [7.2.3/H-0-1] يجب أن يوفّر التطبيق وظائف "الصفحة الرئيسية" و"التطبيقات المستخدَمة مؤخرًا" و"الرجوع".
• [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 هرتز.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [5.1.2/H-0-1] AMR-NB
• [5.1.2/H-0-2] AMR-WB

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

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

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

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

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

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

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

• [3.9/H-1-1] يجب تنفيذ المجموعة الكاملة من سياسات إدارة الجهاز المحدّدة في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
• [3.9/H-1-2] يجب أن يعلن التطبيق عن توافقه مع الملفات الشخصية المُدارة من خلال ميزة android.software.managed_users، إلا عندما يتم ضبط الجهاز لإبلاغ عن نفسه كجهاز يحتوي على ذاكرة وصول عشوائي منخفضة أو لتحديد مساحة تخزين داخلية (غير قابلة للإزالة) كمساحة تخزين مشترَكة.

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

• [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] يجب أن يتيح الجهاز ميزة إقران الجهاز المصاحب.

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

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.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-SR] MPEG-2

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

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

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

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

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

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

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

• [5.3.6.4/T-1-1] الملف الشخصي لفك ترميز دقة عالية 1080p بمعدل 60 لقطة في الثانية

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

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

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

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

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

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

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

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

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

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

2.3.3. البرامج

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

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

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

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

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

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

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

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

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

• [7.3.11/A-0-1] يجب تقديم الترس الحالي على النحو التالي: SENSOR_TYPE_GEAR.

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

• [7.3.11.2/A-0-1] يجب أن يكون متوافقًا مع وضعَي "الإضاءة النهارية" و"الإضاءة الليلية" المحدَّدَين على النحو التالي: SENSOR_TYPE_NIGHT.
• [7.3.11.2/A-0-2] يجب أن تكون قيمة العلامة SENSOR_TYPE_NIGHT متسقة مع وضع لوحة البيانات النهاري/الليلي، ويجب أن تستند إلى إدخال أداة استشعار الإضاءة المحيطة.

• قد تكون أداة استشعار الضوء المحيط الأساسية هي نفسها مقياس الضوء.

• [7.3.11.4/A-0-1] يجب توفير سرعة المركبة على النحو المحدّد في SENSOR_TYPE_CAR_SPEED.

• [7.3.11.5/A-0-1] يجب توفير حالة فرامل الانتظار على النحو المحدّد في SENSOR_TYPE_PARKING_BRAKE.

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

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

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

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

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

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

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

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

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

• [3.13/A-SR] يُنصح بشدة بتضمين مكوّن واجهة مستخدم "الإعدادات السريعة".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.4.1. الأجهزة

حجم الشاشة

• [7.1.1.1/Tab-0-1] يجب أن تكون الشاشة في النطاق من 7 إلى 18 بوصة.

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

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

وضع جهاز USB الملحق (الفقرة 7.7.1)

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

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

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

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

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

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] يجب حظر استخدام التطبيقات التابعة لجهات خارجية لواجهات برمجة التطبيقات المخفية، والتي يتم تعريفها على أنّها واجهات برمجة تطبيقات في مساحة اسم Android مُزيّنة بالتعليق التوضيحي @hidden ولكن ليس @SystemAPI أو @TestApi، كما هو موضّح في مستندات حِزم تطوير البرامج (SDK)، ويجب أن يتم شحن كل واجهة برمجة تطبيقات مخفية في القوائم المحظورة نفسها كما هو موضح في الملفات المؤقتة وقائمة الرفض في مسار prebuilts/runtime/appcompat/ لفرع مستوى واجهة برمجة التطبيقات المناسب في AOSP. ومع ذلك، فإنّه:

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

3.1.1. إضافات Android

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

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

المَعلمة	التفاصيل
VERSION.RELEASE	إصدار نظام Android الذي يتم تنفيذه حاليًا بتنسيق يمكن للمستخدم قراءته يجب أن يحتوي هذا الحقل على إحدى قيم السلاسل المحدّدة في 9.
VERSION.SDK	إصدار نظام Android الذي يتم تنفيذه حاليًا بتنسيق يمكن لرمز التطبيق التابع لجهة خارجية الوصول إليه بالنسبة إلى Android 9، يجب أن يحتوي هذا الحقل على القيمة الصحيحة 9_INT.
VERSION.SDK_INT	إصدار نظام Android الذي يتم تنفيذه حاليًا بتنسيق يمكن لرمز التطبيق التابع لجهة خارجية الوصول إليه بالنسبة إلى Android 9، يجب أن يحتوي هذا الحقل على القيمة الصحيحة 9_INT.
VERSION.INCREMENTAL	قيمة يختارها مُنفِّذ الجهاز لتحديد الإصدار المحدّد من نظام Android الذي يتم تنفيذه حاليًا، بتنسيق يمكن لشخص عادي قراءته يجب عدم إعادة استخدام هذه القيمة لإصدارات مختلفة يتم توفيرها للمستخدمين النهائيين. يتمثل الاستخدام المعتاد لهذا الحقل في الإشارة إلى رقم الإصدار أو معرّف تغيير التحكّم في المصدر الذي تم استخدامه لإنشاء الإصدار. ما مِن متطلبات خاصة بتنسيق هذا الحقل، باستثناء أنّه يجب ألّا يكون فارغًا أو سلسلة فارغة ("").
ألعاب ألواح	قيمة يختارها منفذ الجهاز لتحديد الجهاز الداخلي المحدّد الذي يستخدمه الجهاز، بتنسيق يمكن لشخص عادي قراءته من الاستخدامات المحتملة لهذا الحقل الإشارة إلى المراجعة المحدّدة للوحة التي تشغّل الجهاز. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9_-]+$".
العلامة التجارية	قيمة تعكس اسم العلامة التجارية المرتبط بالجهاز كما هو معروف للمستخدمين النهائيين يجب أن يكون بتنسيق يسهل قراءته، ويجب أن يمثّل الشركة المصنّعة للجهاز أو العلامة التجارية للشركة التي يتم تسويق الجهاز باسمها. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9_-]+$".
SUPPORTED_ABIS	اسم مجموعة التعليمات (نوع وحدة المعالجة المركزية + اصطلاح ABI) للرمز الأصلي راجِع الفقرة 3.3. التوافق مع واجهات برمجة التطبيقات الأصلية:
SUPPORTED_32_BIT_ABIS	اسم مجموعة التعليمات (نوع وحدة المعالجة المركزية + اصطلاح ABI) للرمز الأصلي راجِع الفقرة 3.3. التوافق مع واجهات برمجة التطبيقات الأصلية:
SUPPORTED_64_BIT_ABIS	اسم مجموعة التعليمات الثانية (نوع وحدة المعالجة المركزية + اصطلاح ABI) للرمز البرمجي الأصلي راجِع الفقرة 3.3. التوافق مع واجهات برمجة التطبيقات الأصلية:
CPU_ABI	اسم مجموعة التعليمات (نوع وحدة المعالجة المركزية + اصطلاح ABI) للرمز الأصلي راجِع الفقرة 3.3. التوافق مع واجهات برمجة التطبيقات الأصلية:
CPU_ABI2	اسم مجموعة التعليمات الثانية (نوع وحدة المعالجة المركزية + اصطلاح ABI) للرمز البرمجي الأصلي راجِع الفقرة 3.3. التوافق مع واجهات برمجة التطبيقات الأصلية:
الجهاز	قيمة يختارها منفذ الجهاز تحتوي على اسم التطوير أو الاسم الرمزي الذي يحدِّد إعدادات ميزات الجهاز والتصميم الصناعي للجهاز. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9_-]+$". ويجب ألّا يتغيّر اسم الجهاز هذا خلال فترة استخدام المنتج.
بصمة الإصبع	سلسلة تحدّد هذا الإصدار بشكل فريد يجب أن يكون سهل الفهم على الإنسان. يجب أن يتّبع هذا النموذج: $(BRAND)/$(PRODUCT)/     $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) مثلاً: acme/myproduct/     mydevice:9/LMYXX/3359:userdebug/test-keys يجب ألّا يتضمّن المرجع الرقمي أحرف مسافات بيضاء. إذا كانت الحقول الأخرى المضمّنة في النموذج أعلاه تحتوي على أحرف مسافات بيضاء، يجب استبدالها في بصمة البناء بحرف آخر، مثل الشرطة السفلية ("_"). يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات.
الأجهزة	اسم الجهاز (من سطر أوامر kernel أو ‎ /proc) يجب أن يكون سهل الفهم على الإنسان. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9_-]+$".
HOST	سلسلة تحدِّد بشكل فريد المضيف الذي تم إنشاء الإصدار عليه، بتنسيق يمكن لشخص عادي قراءته ما مِن متطلبات خاصة بتنسيق هذا الحقل، باستثناء أنّه يجب ألّا يكون فارغًا أو سلسلة فارغة ("").
رقم التعريف	معرّف يختاره منفذ الجهاز للإشارة إلى إصدار معيّن بتنسيق يسهل على المستخدم قراءته يمكن أن يكون هذا الحقل هو نفسه android.os.Build.VERSION.INCREMENTAL، ولكن يجب أن يكون له قيمة ذات مغزى كافٍ للمستخدمين النهائيين من أجل التمييز بين إصدارات البرامج. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9._-]+$".
الشركة المصنّعة	الاسم التجاري للمصنّع الأصلي للجهاز (OEM) ما مِن متطلبات حول التنسيق المحدّد لهذا الحقل، باستثناء أنّه يجب ألّا يكون فارغًا أو سلسلة فارغة (""). يجب ألّا يتغيّر هذا الحقل خلال فترة توفّر المنتج.
الطراز	قيمة يختارها منفذ الجهاز تحتوي على اسم الجهاز كما يعرفه المستخدم النهائي. يجب أن يكون هذا هو الاسم نفسه الذي يتم بموجبه تسويق الجهاز وبيعه للمستخدمين النهائيين. ما مِن متطلبات حول التنسيق المحدّد لهذا الحقل، باستثناء أنّه يجب ألّا يكون فارغًا أو سلسلة فارغة (""). يجب ألّا يتغيّر هذا الحقل خلال فترة توفّر المنتج.
المنتج	قيمة يختارها منفذ الجهاز تحتوي على اسم التطوير أو الاسم الرمزي للمنتج المحدّد (رمز التخزين التعريفي) الذي يجب أن يكون فريدًا ضمن العلامة التجارية نفسها. يجب أن تكون قابلة للقراءة من قِبل البشر، ولكن ليس بالضرورة أن تكون مخصّصة للعرض من قِبل المستخدمين النهائيين. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9_-]+$". ويجب ألّا يتغيّر اسم المنتج هذا خلال فترة استخدام المنتج.
SERIAL	يجب أن يعرض العنصر القيمة "UNKNOWN".
العلامات	قائمة مفصولة بفواصل بالعلامات التي اختارها مُنفِّذ الجهاز والتي تميّز الإصدار بشكل أكبر يجب أن يحتوي هذا الحقل على إحدى القيم المقابلة لإعدادات التوقيع النموذجية الثلاثة لنظام Android الأساسي: مفاتيح الإصدار، مفاتيح المطوّرين، مفاتيح الاختبار.
الوقت	قيمة تمثّل الطابع الزمني لوقت إنشاء الإصدار
النوع	قيمة يختارها مُنفِّذ الجهاز لتحديد إعدادات وقت التشغيل للإصدار يجب أن يحتوي هذا الحقل على إحدى القيم المقابلة لإعدادات وقت تشغيل Android النموذجية الثلاثة: user أو userdebug أو eng.
المستخدم	اسم أو رقم تعريف المستخدم (أو المستخدم المبرمَج) الذي أنشأ الإصدار ما مِن متطلبات خاصة بتنسيق هذا الحقل، باستثناء أنّه يجب ألّا يكون فارغًا أو سلسلة فارغة ("").
SECURITY_PATCH	قيمة تشير إلى مستوى رمز تصحيح الأمان لإصدار معيّن يجب أن يشير ذلك إلى أنّ الإصدار ليس معرّضًا بأي شكل من الأشكال لأي من المشاكل الموضّحة في نشرة أمان Android العامة المحدّدة. يجب أن تكون بالتنسيق [YYYY-MM-DD]، وأن تتطابق مع سلسلة محدّدة موثّقة في نشرة أمان Android العامة أو في إشعار أمان Android، على سبيل المثال "‎2015-11-01".
BASE_OS	قيمة تمثّل مَعلمة FINGERPRINT للإصدار الذي يشبه هذا الإصدار تمامًا باستثناء الرقع المقدَّمة في نشرة الأمان العام لنظام التشغيل Android يجب أن يعرض الإصدار القيمة الصحيحة، وإذا لم يكن هذا الإصدار متوفّرًا، يجب أن يعرض سلسلة فارغة ("").
برنامج تحميل التشغيل	قيمة يختارها منفذ الجهاز لتحديد إصدار أداة تحميل البرامج الثابتة الداخلية المحدّد المستخدَم في الجهاز، بتنسيق يمكن لشخص عادي قراءته يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9._-]+$".
getRadioVersion()	يجب أن تكون (أو تعرض) قيمة يختارها مُنفِّذ الجهاز لتحديد إصدار الراديو/المودم الداخلي المحدّد المستخدَم في الجهاز، بتنسيق يمكن لشخص عادي قراءته. إذا لم يكن الجهاز مزوّدًا بأي جهاز لاسلكي/مودم داخلي، يجب أن يعرض القيمة NULL. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9._-,]+$".
getSerial()‎	يجب أن يكون (أو يعرض) رقمًا تسلسليًا للأجهزة، ويجب أن يكون متاحًا وفريدًا على جميع الأجهزة التي تحمل الطراز والشركة المصنّعة نفسها. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9._-,]+$".

3.2.3. توافق الغاية

3.2.3.1. أغراض التطبيقات الأساسية

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

• [C-0-1] يجب أن تحمِّل عمليات تنفيذ الأجهزة تطبيقًا أو مكوّن خدمة واحدًا أو أكثر مزوّدًا بمعالج للنوايا، وذلك لجميع أنماط فلاتر النوايا العامة التي تحدّدها تطبيقات Android الأساسية التالية في AOSP:

  • ساعة مكتب
  • المتصفح
  • التقويم
  • جهات الاتصال
  • معرض الصور
  • GlobalSearch
  • مشغِّل التطبيقات
  • الموسيقى
  • الإعدادات

3.2.3.2. حلّ النية

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

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

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

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 هذا الشرط من خلال تضمين قائمة "خيارات حسابات الاتصال" ضمن قائمة إعدادات "المكالمات".

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

• [C-3-1] يجب الالتزام بنية android.settings.NFC_PAYMENT_SETTINGS لعرض قائمة إعدادات التطبيق التلقائية لميزة "انقر وادفع".

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

• [C-4-1] يجب الالتزام android.settings.ACTION_VOICE_INPUT_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] يجب تغيير حجم جميع الأنشطة على VirtualDisplay وفقًا لذلك في حال تغيير حجم الشاشة نفسها.
• يجوز عرض "أداة تحرير طريقة الإدخال" (IME) (وهي عنصر تحكّم يتيح للمستخدمين إدخال نص) على الشاشة الأساسية عندما يتم التركيز على حقل إدخال نص على شاشة ثانوية.
• يجب تنفيذ تركيز الإدخال على الشاشة الثانوية بشكل مستقل عن الشاشة الأساسية، عندما تكون الإدخالات باللمس أو المفاتيح متاحة.
• يجب أن يتضمّن android.content.res.Configuration الذي يتوافق مع هذه الشاشة ليتم عرضه ويعمل بشكل صحيح ويحافظ على التوافق في حال بدء نشاط على الشاشة الثانوية.

إذا كانت عمليات تنفيذ الأجهزة تسمح بتشغيل أنشطة Android العادية على الشاشات الثانوية وكانت الشاشات الأساسية والثانوية تستخدم android.util.DisplayMetrics مختلفًا:

• [C-2-1] يجب عدم السماح على الشاشات الثانوية بالأنشطة التي لا يمكن تغيير حجمها (التي تحتوي على resizeableActivity=false في AndroidManifest.xml) والتطبيقات التي تستهدف المستوى 23 أو أقل من واجهة برمجة التطبيقات.

إذا كانت عمليات تنفيذ الأجهزة تسمح بتشغيل أنشطة 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) في حزمة Android NDK.

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

• [C-0-1] يجب أن يكون متوافقًا مع واجهة برمجة تطبيقات واحدة أو أكثر محدّدة وأن ينفّذ التوافق مع حزمة تطوير البرامج (NDK) لنظام التشغيل Android.
• [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
  • armeabi-v7a
  • arm64-v8a
  • x86
  • x86-64

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

  • libaaudio.so (دعم الصوت الأصلي في AAudio)

  • 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 في الإصدار 9 من Android لتنفيذ واجهة برمجة التطبيقات android.webkit.WebView.

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

  Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

  • يجب أن تكون قيمة سلسلة $(VERSION) هي نفسها قيمة android.os.Build.VERSION.RELEASE.
  • يجوز أن تكون السلسلة $(MODEL) فارغة، ولكن إذا لم تكن فارغة، يجب أن تكون لها القيمة نفسها مثل android.os.Build.MODEL.
  • يجوز حذف "الإصدار/$(BUILD)"، ولكن إذا كانت السلسلة $(BUILD) متوفّرة، يجب أن تكون مطابقة لقيمة android.os.Build.ID.
  • يجب أن تكون قيمة السلسلة $(CHROMIUM_VER) هي إصدار Chromium في المشروع المفتوح المصدر لنظام التشغيل Android.
  • قد تحذف عمليات تنفيذ الأجهزة كلمة Mobile في سلسلة وكيل المستخدم.

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

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. حظر العمل في الخلفية

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [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 التي تسمح للتطبيقات (بعد أن يفعّلها المستخدم صراحةً) بتلقّي نسخة من جميع الإشعارات عند نشرها أو تعديلها.

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

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

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

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

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

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

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

3.8.4. البحث

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

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

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

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

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

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

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

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

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

يتضمّن 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 وتوفير واجهات برمجة التطبيقات لخدمات تحسين الكتابة كما هو محدّد في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
• [C-1-2] يجب توفير آلية يمكن للمستخدم الوصول إليها لإضافة أساليب إدخال تابعة لجهات خارجية وضبطها استجابةً للintent android.settings.INPUT_METHOD_SETTINGS.

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

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

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

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

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

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

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، يجب أن تستوفي الشروط التالية:

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

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

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

• [C-1-1] يجب تنفيذ أوضاع "تعدد النوافذ" هذه بما يتوافق مع سلوكيات التطبيقات وواجهات برمجة التطبيقات الموضّحة في مستندات دعم وضع "تعدد النوافذ" لحزمة تطوير البرامج(SDK) لنظام التشغيل Android واستيفاء المتطلبات التالية:
• [C-1-2] يمكن للتطبيقات الإشارة إلى ما إذا كانت قادرة على العمل في وضع "النوافذ المتعددة" في ملف AndroidManifest.xml، إما بشكل صريح من خلال ضبط السمة android:resizeableActivity على true أو بشكل ضمني من خلال ضبط targetSdkVersion على قيمة أكبر من 24. يجب عدم تشغيل التطبيقات التي تضبط هذه السمة على false في ملف البيان الخاص بها في وضع "النوافذ المتعددة". قد يتم تشغيل التطبيقات القديمة التي يكون فيها targetSdkVersion < 24 والتي لم تضبط هذه السمة android:resizeableActivity في وضع النوافذ المتعدّدة، ولكن يجب أن يقدّم النظام تحذيرًا بأنّ التطبيق قد لا يعمل على النحو المتوقّع في وضع النوافذ المتعدّدة.
• [C-1-3] يجب عدم توفير وضع "تقسيم الشاشة" أو وضع "شكل حر" إذا كان ارتفاع الشاشة أقل من 440 نقطة كثافة وعرض الشاشة أقل من 440 نقطة كثافة.
• يجب أن تتيح عمليات تنفيذ الأجهزة التي يبلغ حجم شاشته 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] يجب تخصيص الحد الأدنى للعرض والارتفاع 108 وحدة بكسل مستقلة الكثافة (dp) لإطار الصورة في الصورة، والحد الأدنى للعرض 240 وحدة بكسل مستقلة الكثافة والارتفاع 135 وحدة بكسل مستقلة الكثافة لإطار الصورة في الصورة عند ضبط Configuration.uiMode على UI_MODE_TYPE_TELEVISION.

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

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

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

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

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

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

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

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

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

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

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

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

إذا كانت عمليات تنفيذ الأجهزة تُعلن عن 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)، حتى إذا لم يتم احتساب الملف الشخصي المُدار كمستخدم آخر بالإضافة إلى المستخدم الأساسي.
• [C-1-10] يجب أن تتيح إمكانية تحديد شاشة قفل منفصلة تستوفي المتطلبات التالية لمنح الإذن بالوصول إلى التطبيقات التي تعمل في ملف شخصي مُدار.
  • يجب أن تلتزم عمليات تنفيذ الأجهزة بنية 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-3] يجب الالتزام android.settings.ACCESSIBILITY_SETTINGS بتوفير آلية يمكن للمستخدم الوصول إليها لتفعيل خدمات تسهيل الاستخدام التابعة لجهات خارجية وإيقافها إلى جانب خدمات تسهيل الاستخدام المثبَّتة مسبقًا.
• [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-1] يجب عرض رموز MediaItem ورموز الإشعارات بدون تغيير.
• [C-1-2] يجب عرض هذه العناصر على النحو الموضّح في MediaSession، مثل البيانات الوصفية والرموز والصور.
• [C-1-3] يجب عرض عنوان التطبيق.
• [C-1-4] يجب أن يتضمّن درجًا أو آلية أخرى لعرض التسلسل الهرمي MediaBrowser وتوفير إمكانات الاستخدام للتسلسل الهرمي 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] يجب ألا تظهر تفاصيل عن التطبيقات الفورية على الأجهزة للتطبيقات المثبَّتة ما لم يتم ربط التطبيق الفوري صراحةً بالتطبيق المثبَّت.

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

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

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

• [C-0-1] يجب أن يكون التطبيق قادرًا على تثبيت ملفات "‎.apk" لنظام التشغيل Android وتشغيلها كما يتم إنشاؤها بواسطة أداة "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 نفسها على أنّه قد يكون ضارًا.

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

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

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 Baseline Profile وملف الامتداد Dynamic Range Control Profile وفقًا لمعيار ISO/IEC 23003-4)
• ‫[C-1-5] FLAC
• [C-1-6] MP3
• [C-1-7] MIDI
• ‫[C-1-8] Vorbis
• ‫[C-1-9] PCM/WAVE
• [C-1-10] Opus

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

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

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

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

التنسيق/برنامج الترميز	التفاصيل	أنواع الملفات/تنسيقات الحاويات المتوافقة
الملف الشخصي لبرنامج الترميز المتقدّم للصوت (AAC) في MPEG-4 (AAC LC)	إتاحة محتوى أحادي/استيريو/5.0/5.1 بمعدّلات بيانات في الملف الصوتي عادية تتراوح بين 8 و48 كيلوهرتز	3GPP (‎.3gp) ‫MPEG-4 (‎.mp4 و‎.m4a) ‫ADTS raw AAC (‎.aac, ADIF غير متوافقة) ‫MPEG-TS (بتنسيق ‎.ts، لا يمكن التقديم أو الإيقاف)
الملف الشخصي MPEG-4 HE AAC (AAC+)	إتاحة محتوى صوت أحادي/استيريو/5.0/5.1 بمعدّلات بيانات في الملف الصوتي عادية تتراوح بين 16 و48 كيلوهرتز
MPEG-4 HE AACv2 الملف الشخصي (الترميز المحسّن للصوت بترميز متقدّم)	إتاحة محتوى صوت أحادي/استيريو/5.0/5.1 بمعدّلات بيانات في الملف الصوتي عادية تتراوح بين 16 و48 كيلوهرتز
الترميز المتقدّم للصوت (AAC) بوقت استجابة منخفض ومحسّن	إتاحة المحتوى الصوتي الأحادي أو الاستيريو بمعدّلات بيانات في الملف الصوتي عادية تتراوح بين 16 و48 كيلوهرتز
USAC	إتاحة المحتوى الأحادي/الإستيريو بمعدّلات بيانات في الملف الصوتي العادية من 7.35 إلى 48 كيلوهرتز	‫MPEG-4 (‎.mp4 و‎.m4a)
AMR-NB	من 4.75 إلى 12.2 كيلوبت في الثانية بمعدل أخذ عينات يبلغ 8 كيلوهرتز	3GPP (‎.3gp)
AMR-WB	9 معدّلات تتراوح بين 6.60 كيلوبت في الثانية و23.85 كيلوبت في الثانية بمعدّل أخذ عينات يبلغ 16 كيلوهرتز
FLAC	صوت أحادي/استيريو (بدون قنوات متعددة) معدلات أخذ العينات التي تصل إلى 48 كيلوهرتز (ولكن يُنصح باستخدام معدلات تصل إلى 44.1 كيلوهرتز على الأجهزة التي تبلغ سرعة إخراجها 44.1 كيلوهرتز، لأنّ أداة تقليل معدل أخذ العينات من 48 إلى 44.1 كيلوهرتز لا تتضمّن فلترًا منخفض التردد) يُنصح باستخدام 16 بت، ولا يتم تطبيق ميزة التمويه على 24 بت.	‫FLAC (‎.flac) فقط
MP3	صوت أحادي/صوت استيريو بمعدّل نقل بيانات ثابت من 8 إلى 320 كيلوبت في الثانية (معدل نقل بيانات ثابت) أو بمعدّل نقل بيانات متغيّر (VBR)	MP3 ‏(‎.mp3)
MIDI	نوعا MIDI 0 و1 الإصداران 1 و2 من DLS XMF وMobile XMF إتاحة تنسيقات نغمات الرنين RTTTL/RTX وOTA وiMelody	النوع 0 و1 (‎.mid و‎.xmf و‎.mxmf) RTTTL/RTX ‏(‎.rtttl, .rtx) OTA (‎.ota) iMelody ‏(‎.imy)
Vorbis		Ogg (‎.ogg) Matroska (‎.mkv, Android 4.0 والإصدارات الأحدث)
PCM/WAVE	تنسيق PCM خطي بترميز 16 بت (بمعدلات تصل إلى الحد الأقصى للأجهزة) يجب أن تتوافق الأجهزة مع معدّلات أخذ العينات لتسجيل PCM الأوّلي بمعدّلات تردد 8000 و11025 و16000 و44100 هرتز.	WAVE (‎.wav)
Opus		Matroska (‎.mkv) وOgg(‎.ogg)

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

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

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

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

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

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

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

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

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

التنسيق/برنامج الترميز	التفاصيل	أنواع الملفات/تنسيقات الحاويات المتوافقة
JPEG	قاعدة + رسوم متحركة	‫JPEG (‎.jpg)
ملف GIF		GIF ‏(‎.gif)
PNG		‫PNG‏ (‎.png)
BMP		BMP‏ (‎.bmp)
WebP		WebP ‏(‎.webp)
عرض أوّلي		‫ARW (‎.arw)، وCR2 (‎.cr2)، وDNG (‎.dng)، وNEF (‎.nef)، وNRW (‎.nrw)، وORF (‎.orf)، وPEF (‎.pef)، وRAF (‎.raf)، وRW2 (‎.rw2)، وSRW (‎.srw)
HEIF	صورة، مجموعة صور، تسلسل صور	HEIF (‎.heif) وHEIC (‎.heic)

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

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

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

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

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

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

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

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

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

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

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

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 وتوفّره للتطبيقات التابعة لجهات خارجية، يجب أن تستوفي المتطلبات التالية:

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

5.2.1. ‫H.263

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

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

5.2.2. ‫H-264

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

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

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

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

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

5.2.3. VP8

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

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

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

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

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

5.2.4. VP9

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

• يجب أن تتيح كتابة ملفات Matroska WebM.

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

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

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

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

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

5.3.1. MPEG-2

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

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

5.3.2. ‫H.263

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

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

5.3.3. MPEG-4

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

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

5.3.4. H.264

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

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

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

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

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

5.3.5. ‫H.265 (HEVC)

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

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

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

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

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

5.3.6. VP8

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

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

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

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

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

5.3.7. VP9

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

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

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

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

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

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

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

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

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

5.4.1. تسجيل الصوت بجودة عالية

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [C-SR] وقت استجابة الإخراج على البارد يبلغ 100 ملي ثانية أو أقل
• [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-1-1] يجب عدم الإبلاغ عن توفّر ميزة الصوت بوقت استجابة منخفض.

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

• [C-SR] وقت استجابة الإدخال من حالة السكون 100 ملي ثانية أو أقل
• [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.

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

أشكال الشرائح	المراجع	توفُّر برامج الترميز المطلوبة
MPEG-2 Transport Stream	ISO 13818	برامج ترميز الفيديو: ‫H264 AVC MPEG-4 SP MPEG-2 راجِع القسم 5.1.3 لمعرفة تفاصيل عن H264 AVC وMPEG2-4 SP وMPEG-2. برامج ترميز الصوت: AAC اطّلِع على الفقرة 5.1.1 لمعرفة تفاصيل عن الترميز المتقدّم للصوت (AAC) وأشكاله المختلفة.
الترميز المتقدّم للصوت مع إطارات ADTS وعلامات ID3	ISO 13818-7	راجِع الفقرة 5.1.1 لمعرفة تفاصيل عن الترميز المتقدّم للصوت (AAC) وأنواعه.
WebVTT	WebVTT

‫RTSP (RTP وSDP)

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

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

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

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

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

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

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

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

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

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

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

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

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

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 باستخدام كلّ من قائمة انتظار وحدة تخزين مؤقت PCM في OpenSL ES وواجهات برمجة التطبيقات AAudio native audio.
• [SR] يُنصح بشدة بتوفير مستوى ثابت من أداء وحدة المعالجة المركزية عندما يكون الصوت نشطًا ويكون تحميل وحدة المعالجة المركزية متغيرًا. يجب اختبار ذلك باستخدام الإصدار 1bd6391 من SimpleSynth. يجب تشغيل تطبيق SimpleSynth باستخدام المَعلمات التالية وعدم حدوث أيّ تأخّر في عرض المحتوى بعد 10 دقائق:
  • دورات العمل: 200,000
  • الحمل المتغيّر: مفعَّل (سيتم التبديل بين% 100 و% 10 من قيمة دورات العمل كل ثانيتين، وهو مصمّم لاختبار سلوك وحدة تحكّم وحدة المعالجة المركزية)
  • الحمل المستقر: غير مفعَّل
• يجب تقليل عدم دقة الساعة الصوتية وانحرافها مقارنةً بالوقت العادي.
• يجب تقليل انحراف ساعة الصوت بالنسبة إلى وحدة المعالجة المركزية 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.

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

• [C-4-1] يجب أن يكون الجهاز متوافقًا مع إخراج الصوت الاستيريو وثماني قنوات بمعدل بت 20 أو 24 بت وتردد 192 كيلوهرتز بدون فقدان معدل البت أو إعادة أخذ العينات، في إعداد واحد على الأقل.

5.11. التقاط بيانات "لم تتمّ المعالجة"

يتيح نظام التشغيل Android تسجيل الصوت غير المعالج من خلال مصدر الصوت android.media.MediaRecorder.AudioSource.UNPROCESSED. في OpenSL ES، يمكن الوصول إليه باستخدام الإعداد المُسبَق للتسجيل SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

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

• [C-1-1] يجب الإبلاغ عن مدى التوفّر من خلال سمة android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.

• [C-1-2] يجب أن يعرض الجهاز خصائص تقريبية مسطّحة للسعة مقابل التردد في نطاق التردد المتوسط: على وجه التحديد ±10 ديسيبل من 100 هرتز إلى 7000 هرتز لكل ميكروفون مستخدَم لتسجيل مصدر الصوت غير المعالج.

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

• [C-1-4] يجب أن يعرض مستويات الجهارة في نطاق الترددات العالية: على وجه التحديد من ±30 ديسيبل من 7000 هرتز إلى 22 كيلوهرتز مقارنةً بنطاق الترددات المتوسطة لكل ميكروفون مستخدَم لتسجيل مصدر الصوت غير المعالج.

• [C-1-5] يجب ضبط حساسية إدخال الصوت بحيث ينتج مصدر الصوت الجيبي بتردد 1000 هرتز عند مستوى ضغط الصوت (SPL)‏ 94 ديسيبل استجابة بمتوسط طاقة 520 لمعاينات 16 بت (أو -36 ديسيبل على النطاق الكامل لمعاينات النقطة العائمة/الدقة المزدوجة) لكل ميكروفون مستخدَم لتسجيل مصدر الصوت غير المعالج.

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

• [C-1-7] يجب أن يكون التشويه التوافقي الكلي (THD) أقل من% 1 عند تردد 1 كيلوهرتز ومستوى إدخال 90 ديسيبل 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-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 متوافقًا مع وضع الجهاز الملحق برنامج adb عبر شبكة المنطقة المحلية (مثل Ethernet أو Wi-Fi).
    • يجب توفير برامج تشغيل لنظام التشغيل Windows 7 و9 و10، ما يسمح للمطوّرين بالاتصال بالجهاز باستخدام بروتوكول adb.

• 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 غير مفعّلة تلقائيًا ويجب أن تتوفّر آلية يمكن للمستخدم تفعيلها.

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

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

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

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

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

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

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

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

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

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

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

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

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

• قد تتضمّن شاشة بزوايا دائرية.

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

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

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

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

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

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

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

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

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

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

  • 120 نقطة لكل بوصة (ldpi)
  • 160 نقطة لكل بوصة (mdpi)
  • ‫213 نقطة لكل بوصة (tvdpi)
  • 240 نقطة لكل بوصة (دقة عالية)
  • 260 نقطة لكل بوصة (260dpi)
  • 280 نقطة لكل بوصة (280dpi)
  • 300 نقطة لكل بوصة (300dpi)
  • 320 نقطة لكل بوصة (xhdpi)
  • 340 نقطة لكل بوصة (340dpi)
  • 360 نقطة في البوصة (360dpi)
  • 400 نقطة لكل بوصة (400dpi)
  • 420 نقطة لكل بوصة (420dpi)
  • 480 نقطة لكل بوصة (xxhdpi)
  • 560 نقطة في البوصة (560dpi)
  • 640 نقطة لكل بوصة (xxxhdpi)

• يجب أن تحدِّد عمليات تنفيذ الأجهزة كثافة إطار عمل 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. مقاييس الشبكة الإعلانية

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

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

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

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

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

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

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

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

• [C-2-1] يجب عدم الإفصاح عن أي من مفاتيح إيقاف أو تفعيل ميزات Vulkan (مثل android.hardware.vulkan.level وandroid.hardware.vulkan.version).
• [C-2-2] يجب عدم إدراج أي VkPhysicalDevice لواجهة برمجة التطبيقات الأصلية Vulkan vkEnumeratePhysicalDevices().

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

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

7.1.4.3 RenderScript

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

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

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

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

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

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

• [C-2-1] يجب أن تغطي نسبة% 100 أو أكثر من sRGB في مساحة CIE 1931 xyY، على الرغم من أنّ نطاق ألوان الشاشة غير محدّد.

7.1.5. وضع التوافق مع التطبيقات القديمة

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

7.1.6. تكنولوجيا الشاشة

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

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

• [C-0-1] يجب أن يكون متوافقًا مع الشاشات القادرة على عرض رسومات ملونة بدقة 16 بت.
• يجب أن تكون متوافقة مع الشاشات التي يمكنها عرض الرسومات الملوّنة بدقة 24 بت.
• [C-0-2] يجب أن تكون متوافقة مع الشاشات القادرة على عرض الصور المتحركة.
• [C-0-3] يجب استخدام تكنولوجيا العرض التي تبلغ نسبة عرض إلى ارتفاع البكسل (PAR) فيها بين 0.9 و1.15. وهذا يعني أنّ نسبة عرض البكسل إلى ارتفاعه يجب أن تكون قريبة من نسبة العرض إلى الارتفاع المربّع (1.0) مع هامش خطأ يتراوح بين ‎10% و‎15%.

7.1.7. الشاشات الثانوية

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

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

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

7.2. أجهزة إدخال بيانات

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

• [C-0-1] يجب أن يتضمّن آلية إدخال، مثل شاشة تعمل باللمس أو تنقّل بدون لمس، للتنقّل بين عناصر واجهة المستخدم.

7.2.1. لوحة المفاتيح

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

• [C-1-1] يجب الإفصاح عن علامة ميزة android.software.input_methods.
• [C-1-2] يجب تنفيذ Input Management Framework بالكامل
• [C-1-3] يجب أن يكون الجهاز مزوّدًا بلوحة مفاتيح برمجية مثبَّتة مسبقًا.

عمليات تنفيذ الأجهزة: * [C-0-1] يجب ألا تتضمّن لوحة مفاتيح أجهزة لا تتطابق مع أحد التنسيقات المحدّدة في android.content.res.Configuration.keyboard (QWERTY أو 12 مفتاحًا). * يجب أن تتضمّن عمليات تنفيذ إضافية للوحة المفاتيح. * قد تتضمّن لوحة مفاتيح خارجية.

7.2.2. التنقّل بدون لمس الشاشة

يتيح نظام التشغيل Android استخدام لوحة التوجيه وكرة التتبُّع والعجلة كآليات للتنقّل بدون لمس الشاشة.

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

• [C-0-1] يجب الإبلاغ عن القيمة الصحيحة لسمة android.content.res.Configuration.navigation.

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

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

7.2.3. مفاتيح التنقل

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

• [C-0-1] يجب توفير عنصر تحكم للمستخدم لتشغيل التطبيقات المثبَّتة التي تحتوي على نشاط مع <intent-filter> تم ضبطه باستخدام ACTION=MAIN وCATEGORY=LAUNCHER أو CATEGORY=LEANBACK_LAUNCHER لعمليات تنفيذ أجهزة التلفزيون. يجب أن تكون وظيفة "المنزل" هي آلية توفير هذه الميزة للمستخدم.
• يجب أن توفّر أزرارًا لوظيفتَي "التطبيقات المستخدَمة مؤخرًا" و"الرجوع".

في حال توفّر وظائف "الصفحة الرئيسية" أو "العناصر الأخيرة" أو "رجوع"، يجب أن تستوفي الشروط التالية:

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

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

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

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

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

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

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

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

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

7.2.4. الإدخال من خلال شاشة تعمل باللمس

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

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

• يجب أن يتضمّن نظام إدخال مؤشر من نوع ما (إما مثل الماوس أو باللمس).
• يجب أن تتيح استخدام مؤشرات يتم تتبُّعها بشكل مستقل بالكامل.

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

• [C-1-1] يجب الإبلاغ عن TOUCHSCREEN_FINGER لحقل واجهة برمجة التطبيقات Configuration.touchscreen.
• [C-1-2] يجب الإبلاغ عن علامتَي ميزة android.hardware.touchscreen وandroid.hardware.faketouch.

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

• [C-2-1] يجب الإبلاغ عن علامات الميزات المناسبة android.hardware.touchscreen.multitouch وandroid.hardware.touchscreen.multitouch.distinct وandroid.hardware.touchscreen.multitouch.jazzhand التي تتوافق مع نوع الشاشة التي تعمل باللمس المحدّدة على الجهاز.

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

• [C-3-1] يجب عدم الإبلاغ عن أي ميزة تتضمّن علامة اختيار تبدأ بـ android.hardware.touchscreen، ويجب الإبلاغ عن android.hardware.faketouch فقط.

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] يجب أن يتيح استخدام المؤشر للأسفل ثم السماح للمستخدمين بنقل الجسم بسرعة إلى موضع مختلف على الشاشة ثم استخدام المؤشر للأعلى على الشاشة، ما يسمح للمستخدمين برمي جسم على الشاشة.
• [C-1-7] يجب الإبلاغ عن TOUCHSCREEN_NOTOUCH لحقل واجهة برمجة التطبيقات Configuration.touchscreen.

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

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

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

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

‫1 KeyEvent

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

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

‫4 MotionEvent

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

‫1 MotionEvent

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

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

7.3. أجهزة الاستشعار

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

• [SR] يجب تسجيل وقت الحدث بالنانوسات كما هو محدّد في مستندات Android SDK، ما يمثّل وقت وقوع الحدث ومزامنة مع ساعة SystemClock.elapsedRealtimeNano()‎. ننصح بشدة بتلبية هذه المتطلبات على أجهزة Android الحالية والجديدة حتى تتمكّن من الترقية إلى إصدارات المنصة المستقبلية التي قد يصبح فيها هذا المكوّن مطلوبًا. يجب أن يكون خطأ المزامنة أقل من 100 ملي ثانية.

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

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

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

القائمة أعلاه ليست شاملة، ويجب اعتبار السلوك المُسجَّل لحزمة SDK لنظام التشغيل Android ومستندات Android Open Source حول أجهزة الاستشعار موثوقًا به.

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

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

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

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

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

7.3.1. مقياس التسارع

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

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

• [C-1-1] يجب أن يكون الجهاز قادرًا على تسجيل الأحداث بمعدّل تكرار لا يقل عن 50 هرتز.
• [C-1-2] يجب تنفيذ أداة استشعار TYPE_ACCELEROMETER والإبلاغ عنها.
• [C-1-3] يجب أن تكون متوافقة مع نظام إحداثيات أدوات استشعار Android كما هو موضّح في واجهات برمجة تطبيقات Android.
• [C-1-4] يجب أن يكون الجهاز قادرًا على قياس التسارع من السقوط الحر إلى أربعة أضعاف قوة الجاذبية(4g) أو أكثر على أي محور.
• [C-1-5] يجب أن تكون درجة دقة الصورة 12 بت على الأقل.
• [C-1-6] يجب أن يكون التباين المعياري لا يزيد عن 0.05 متر في الثانية^، حيث يجب احتساب التباين المعياري لكل محور على أساس العيّنات التي تم جمعها على مدار فترة لا تقل عن 3 ثوانٍ بأسرع معدّل تحليل.
• [SR] يُنصح بشدة بتنفيذ أداة الاستشعار المركبة TYPE_SIGNIFICANT_MOTION.
• [SR] يُنصح بشدة بتنفيذ أداة استشعار TYPE_ACCELEROMETER_UNCALIBRATED إذا كان توفّر أداة معايرة التسارع على الإنترنت.
• يجب تنفيذ أدوات الاستشعار المركبة TYPE_SIGNIFICANT_MOTION وTYPE_TILT_DETECTOR وTYPE_STEP_DETECTOR وTYPE_STEP_COUNTER كما هو موضّح في مستند حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
• يجب أن تُبلغ عن الأحداث التي تصل إلى 200 هرتز على الأقل.
• يجب أن تكون درجة دقتها 16 بت على الأقل.
• يجب معايرة هذه الخصائص أثناء الاستخدام إذا تغيّرت خلال دورة الحياة، ويجب تعويضها والحفاظ على مَعلمات التعويض بين عمليات إعادة تشغيل الجهاز.
• يجب أن تكون مصحَّحة حسب درجة الحرارة.
• يجب أيضًا تنفيذ TYPE_ACCELEROMETER_UNCALIBRATED sensor.

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

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

• [C-4-1] يجب استخدام أداة استشعار مركبة TYPE_ROTATION_VECTOR.

7.3.2. مقياس المغناطيسية

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

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

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

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

• يجب أن يتضمّن جهاز استقبال نظام تحديد المواقع العالمي (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-1-5] يجب الإبلاغ عن الجيل من تكنولوجيا GNSS من خلال واجهة برمجة التطبيقات الاختبارية "getGnssYearOfHardware".
  • [SR] مواصلة عرض نتائج الموقع الجغرافي العادية لنظام تحديد المواقع العالمي (GPS)/نظام تحديد المواقع العالمي (GNSS) أثناء إجراء مكالمة هاتفية للطوارئ
  • [SR] الإبلاغ عن قياسات GNSS من جميع المجموعات التي يتم تتبُّعها (كما هو موضّح في رسائل GnssStatus)، باستثناء SBAS
  • [SR] الإبلاغ عن AGC ومعدّل تكرار قياس GNSS
  • [SR] الإبلاغ عن جميع تقديرات الدقة (بما في ذلك الاتجاه والسرعة والقيمة العمودية) كجزء من كل موقع جغرافي لنظام تحديد المواقع العالمي (GPS) أو نظام تحديد المواقع العالمي (GNSS)
  • [SR] يُنصح بشدة باستيفاء أكبر عدد ممكن من المتطلبات الإلزامية الإضافية للأجهزة التي تسجّل السنة "2016" أو "2017" من خلال Test API LocationManager.getGnssYearOfHardware().

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

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

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

• [C-3-1] يجب مواصلة عرض بيانات الموقع الجغرافي العادية من نظام تحديد المواقع العالمي (GPS) أو نظام تحديد المواقع العالمي (GNSS) أثناء إجراء مكالمة هاتفية طارئة.
• [C-3-2] يجب الإبلاغ عن قياسات GNSS من جميع المجموعات التي يتم تتبُّعها (كما هو موضّح في رسائل GnssStatus)، باستثناء SBAS.
• [C-3-3] يجب الإبلاغ عن AGC ومعدّل قياس GNSS.
• [C-3-4] يجب الإبلاغ عن جميع تقديرات الدقة (بما في ذلك الاتجاه والسرعة والقيمة العمودية) كجزء من كل موقع جغرافي لنظام تحديد المواقع العالمي (GPS) أو نظام تحديد المواقع العالمي (GNSS).

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

• [C-4-1] يجب مواصلة تقديم نتائج GPS/GNSS العادية إلى التطبيقات أثناء مكالمة جلسة الطوارئ التي تبدأها الشبكة استنادًا إلى المحطة الجوّالة (MS-Based).
• [C-4-2] يجب الإبلاغ عن مواضع وقياسات واجهة برمجة التطبيقات GNSS Location Provider.

7.3.4. الجيروسكوب

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

• يجب أن يتضمّن أداة جيروسكوب (جهاز استشعار للتغيير الزاوي).
• يجب عدم تضمين أداة استشعار جيروسكوب ما لم يتم تضمين مقياس تسارع ثلاثي المحاور أيضًا.

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

• [C-1-1] يجب أن يكون الجهاز قادرًا على تسجيل الأحداث بمعدّل تكرار لا يقل عن 50 هرتز.
• [C-1-2] يجب تنفيذ أداة استشعار TYPE_GYROSCOPE ويجب أيضًا تنفيذ أداة استشعار TYPE_GYROSCOPE_UNCALIBRATED.
• [C-1-3] يجب أن يكون الجهاز قادرًا على قياس تغييرات الاتجاه بما يصل إلى 1,000 درجة في الثانية.
• [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] يُنصح بشدة باستخدام أجهزة Android الحالية والجديدة لتطبيق أداة استشعار SENSOR_TYPE_GYROSCOPE_UNCALIBRATED.
• [SR] يُنصح بشدة بأن يكون خطأ المعايرة أقل من 0.01 راديان في الثانية عندما يكون الجهاز ثابتًا في درجة حرارة الغرفة.
• يجب أن تُبلغ عن الأحداث التي تصل إلى 200 هرتز على الأقل.

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

• [C-2-1] يجب تنفيذ أداة استشعار مركبة TYPE_ROTATION_VECTOR.

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

• [C-3-1] يجب تنفيذ أدات الاستشعار المركبة TYPE_GRAVITY وTYPE_LINEAR_ACCELERATION.
• [SR] يُنصح بشدة باستخدام أجهزة Android الحالية والجديدة لتطبيق أداة استشعار TYPE_GAME_ROTATION_VECTOR.
• يجب تنفيذ أداة الاستشعار المركبة TYPE_GAME_ROTATION_VECTOR.

7.3.5. مقياس الضغط الجوي

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

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

• [C-1-1] يجب تنفيذ أداة استشعار TYPE_PRESSURE والإبلاغ عنها.
• [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-1-2] يجب تحديده على أنّه SENSOR_TYPE_TEMPERATURE.
• [C-1-3] يجب قياس درجة حرارة وحدة المعالجة المركزية للجهاز.
• [C-1-4] يجب عدم قياس أي درجة حرارة أخرى.

يُرجى العلم أنّه تم إيقاف نوع أداة الاستشعار SENSOR_TYPE_TEMPERATURE نهائيًا في Android 4.0.

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 مجم/درجة مئوية كحد أقصى أو أدنى.
  • يجب أن يكون خط أفضل الملاءمة غير خطي بنسبة ≤ 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 ما يلي:
  • يجب استخدام شكل غير مُشغِّل لهذا المستشعر مع قدرة تخزين مؤقت لا تقل عن 300 حدث مستشعر.
  • يجب أن يكون استهلاك الطاقة في وضع "المعالجة المجمّعة" لا يزيد عن 4 ملي واط.
• [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. أجهزة الاستشعار الحيوية

7.3.10.1. أجهزة استشعار بصمة الإصبع

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

• يجب أن يتضمّن جهازك أداة استشعار بصمة الإصبع.

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

• [C-1-1] يجب الإفصاح عن توفّر ميزة android.hardware.fingerprint.
• [C-1-2] يجب تنفيذ واجهة برمجة التطبيقات المقابلة بالكامل على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
• [C-1-3] يجب ألا يزيد معدّل القبول الخاطئ عن 0.002%.
• [SR] يُنصح بشدة بأن لا يزيد معدّل قبول عمليات التزوير والتضليل عن %7.
• [C-1-4] يجب الإفصاح عن أنّ هذا الوضع قد يكون أقل أمانًا من استخدام رقم تعريف شخصي أو نقش أو كلمة مرور قوية، ويجب سرد مخاطر تفعيله بوضوح، إذا كانت معدّلات قبول عمليات التزوير والتصيّد الاحتيالي أعلى من %7.
• [C-1-5] يجب تحديد معدّل لعدد المحاولات المسموح به لمدة 30 ثانية على الأقل بعد خمس محاولات غير صحيحة لإثبات الهوية باستخدام بصمة الإصبع.
• [C-1-6] يجب أن يتضمّن التطبيق تنفيذًا لمتجر مفاتيح مستندًا إلى الأجهزة، وأن يُجري عملية مطابقة بصمة الإصبع في بيئة تنفيذ موثوقة (TEE) أو على شريحة تتضمّن قناة آمنة تؤدي إلى بيئة التنفيذ الموثوقة.
• [C-1-7] يجب أن تكون جميع بيانات بصمة الإصبع القابلة للتحديد مشفّرة وموثَّقة تشفيريًا بحيث لا يمكن الحصول عليها أو قراءتها أو تغييرها خارج وحدة TEE، أو أن تكون هناك شريحة تتضمّن قناة آمنة تؤدي إلى وحدة TEE كما هو موضّح في إرشادات التنفيذ على الموقع الإلكتروني لمشروع Android Open Source Project.
• [C-1-8] يجب منع إضافة بصمة إصبع بدون إنشاء سلسلة ثقة أولاً من خلال مطالبة المستخدم بتأكيد بيانات اعتماد الجهاز الحالية أو إضافة بيانات اعتماد جديدة (رقم التعريف الشخصي أو النمط أو كلمة المرور) التي تم تأمينها من خلال TEE، ويوفّر تنفيذ مشروع Android Open Source Mechanism في إطار العمل لإجراء ذلك.
• [C-1-9] يجب عدم السماح للتطبيقات التابعة لجهات خارجية بالتمييز بين بصمات الأصابع الفردية.
• [C-1-10] يجب الالتزام بالعلامة DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT.
• [C-1-11] عند الترقية من إصدار أقدم من Android 6.0، يجب نقل بيانات بصمة الإصبع بأمان لاستيفاء المتطلبات المذكورة أعلاه أو إزالتها.
• [C-1-12] يجب إزالة جميع بيانات بصمة الإصبع القابلة للتحديد الخاصة بالمستخدم تمامًا عند إزالة حساب المستخدم (بما في ذلك من خلال إعادة الضبط على الإعدادات الأصلية).
• [C-1-13] يجب عدم السماح لمعالج التطبيقات بالوصول غير المشفَّر إلى بيانات بصمة الإصبع القابلة للتحديد أو أي بيانات مشتقة منها (مثل العناصر المضمَّنة).
• [SR] يُنصح بشدة بخفض معدّل الرفض الخاطئ إلى أقل من %10، كما يتم قياسه على الجهاز.
• [SR] يُنصح بشدة بخفض وقت الاستجابة إلى أقل من ثانية واحدة، ويتم قياسه من لحظة لمس أداة استشعار بصمة الإصبع إلى لحظة فتح قفل الشاشة باستخدام إصبع مسجَّل واحد.
• يجب استخدام رمز بصمة الإصبع في Android المتوفّر في "مشروع Android المفتوح المصدر".

7.3.10.2. أجهزة الاستشعار الحيوية الأخرى

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

• [C-1-1] يجب أن يكون معدّل القبول الخاطئ أقل من 0.002%.
• [C-SR] يُنصح بشدة بأن لا يزيد معدّل قبول عمليات التزوير والتضليل عن %7.
• [C-1-2] يجب الإفصاح عن أنّ هذا الوضع قد يكون أقل أمانًا من استخدام رقم تعريف شخصي أو نقش أو كلمة مرور قوية، ويجب سرد مخاطر تفعيله بوضوح، إذا كانت معدّلات قبول عمليات التزوير والتصيّد الاحتيالي أعلى من %7.
• [C-1-3] يجب تحديد معدّل لعدد المحاولات المسموح به لمدة 30 ثانية على الأقل بعد خمس محاولات خاطئة للتحقّق من المقاييس الحيوية، حيث تكون المحاولة الخاطئة هي محاولة ذات جودة تسجيل مناسبة (ACQUIRED_GOOD) لا تتطابق مع مقياس حيوي مسجَّل.
• [C-1-4] يجب أن يتضمّن التطبيق متجر مفاتيح مستندًا إلى الأجهزة، وأن يُجري عملية مطابقة المقاييس الحيوية في بيئة تنفيذ موثوقة (TEE) أو على شريحة تتضمّن قناة آمنة تؤدي إلى بيئة التنفيذ الموثوقة.
• [C-1-5] يجب أن تكون جميع البيانات التعريفية مشفّرة وموثَّقة تشفيريًا بحيث لا يمكن الحصول عليها أو قراءتها أو تغييرها خارج وحدة TEE، أو أن تكون هناك شريحة تتضمّن قناة آمنة تؤدي إلى وحدة TEE كما هو موضّح في إرشادات التنفيذ على الموقع الإلكتروني لمشروع Android Open Source Project.
• [C-1-6] يجب منع إضافة مقاييس حيوية جديدة بدون إنشاء سلسلة ثقة أولاً من خلال مطالبة المستخدم بتأكيد بيانات اعتماد الجهاز الحالية أو إضافة بيانات اعتماد جديدة (رقم التعريف الشخصي/نمط الشاشة/كلمة المرور) التي تم تأمينها من خلال TEE، ويوفّر تنفيذ مشروع Android Open Source Mechanism في إطار العمل لإجراء ذلك.
• [C-1-7] يجب عدم السماح للتطبيقات التابعة لجهات خارجية بالتمييز بين عمليات التسجيل باستخدام المقاييس الحيوية.
• [C-1-8] يجب الالتزام بالعلامة الفردية للمقياس الحيوي (مثل DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT أو DevicePolicymanager.KEYGUARD_DISABLE_FACE أو DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
• [C-1-9] يجب إزالة جميع البيانات البيومترية التعريفية للمستخدم بالكامل عند إزالة حسابه (بما في ذلك من خلال إعادة الضبط على الإعدادات الأصلية).
• [C-1-10] يجب عدم السماح بالوصول غير المشفَّر إلى البيانات الحيوية القابلة للتحديد الهوية أو أي بيانات مشتقة منها (مثل البيانات المضمَّنة) إلى معالج التطبيقات خارج سياق بيئة التنفيذ الموثوقة.
• [C-SR] يُنصح بشدة بخفض معدّل الرفض الخاطئ إلى أقل من %10، كما يتم قياسه على الجهاز.
• [C-SR] يُنصح بشدة بخفض وقت الاستجابة إلى أقل من ثانية واحدة، ويتم قياسه من وقت رصد المقياس الحيوي إلى وقت فتح قفل الشاشة لكل مقياس حيوي مسجَّل.

7.3.11. أجهزة الاستشعار المخصّصة لنظام Android Automotive فقط

يتم تحديد أدوات الاستشعار الخاصة بالمركبات في android.car.CarSensorManager API.

7.3.11.1. الترس الحالي

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

7.3.11.2. الوضع الليلي/النهاري

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

7.3.11.3. حالة القيادة

تم إيقاف هذا الشرط نهائيًا.

7.3.11.4. سرعة الدوران

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

7.3.11.5. فرامل اليد

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

7.3.12. أداة استشعار الوضع

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

• قد تتيح استخدام أداة استشعار الوضع بـ 6 درجات من الحرية.

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

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

7.4. إمكانية الوصول إلى البيانات

7.4.1. الاتصالات الهاتفية

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

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

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

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

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

• [C-2-1] يجب تنفيذ واجهات برمجة التطبيقات الكاملة كعمليات لا تتطلّب تدخلًا.

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-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-SR] يُنصح بشدة، عند استدعاء طريقة واجهة برمجة التطبيقات ConnectivityManager.reportNetworkConnectivity()، بإعادة تقييم إمكانية الوصول إلى الإنترنت على Network، وبعد أن يحدّد التقييم أنّ Network الحالي لم يعُد يقدّم إمكانية الوصول إلى الإنترنت، يمكنك التبديل إلى أي شبكة أخرى متاحة (مثل بيانات الجوّال) تتيح الوصول إلى الإنترنت.
• [C-SR] يُنصح بشدة بتعشيب عنوان MAC المصدر ورقم التسلسل لإطارات طلب الاستكشاف، مرة واحدة في بداية كل عملية بحث، عندما يكون STA غير متصل.
  • يجب أن تستخدم كل مجموعة من إطارات طلبات الاستكشاف التي تتضمّن عملية فحص واحدة عنوان MAC واحدًا متسقًا (يجب عدم توزيع عنوان MAC عشوائيًا في منتصف عملية الفحص).
  • يجب تكرار الرقم التسلسلي لطلب الفحص كالمعتاد (بشكل تسلسلي) بين طلبات الفحص في عملية الفحص.
  • يجب أن يكون رقم تسلسل طلب الفحص عشوائيًا بين آخر طلب فحص لعملية فحص وأول طلب فحص لعملية الفحص التالية.
• [C-SR] يُنصح بشدة، عندما يكون STA غير متصل، بالسماح بالعناصر التالية فقط في إطارات طلب الاستكشاف:
  • مجموعة مَعلمات SSID (0)
  • مجموعة مَعلمات DS (3)

إذا كانت عمليات تنفيذ الأجهزة تتيح استخدام شبكة 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.

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

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

• [C-2-1] يجب تنفيذ واجهات برمجة تطبيقات الاستكشاف المستندة إلى الموقع الجغرافي: setRangingEnabled وsetMinDistanceMm وsetMaxDistanceMm وonServiceDiscoveredWithinRange.

7.4.2.4. Wi-Fi Passpoint

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

• يجب أن تتضمّن ميزة Wi-Fi Passpoint.

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

• [C-1-1] يجب تنفيذ واجهات برمجة التطبيقات WifiManager ذات الصلة بـ Passpoint كما هو موضّح في مستندات حزمة تطوير البرامج (SDK).
• [C-1-2] يجب أن يكون متوافقًا مع معيار IEEE 802.11u، خاصةً في ما يتعلق باكتشاف الشبكة واختيارها، مثل خدمة الإعلانات الشاملة (GAS) وبروتوكول طلب شبكة الوصول (ANQP).

في المقابل، إذا كانت عمليات تنفيذ الأجهزة لا تتضمّن إتاحة Wi-Fi Passpoint:

• [C-2-1] يجب أن يؤدي تنفيذ واجهات برمجة التطبيقات WifiManager ذات الصلة بنقطة المرور إلى طرح 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.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 وما إلى ذلك، حسبما يناسب الجهاز.

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

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

• يجب أن تتيح عرض إعلانات متعددة مع 4 خانات على الأقل.

• [SR] يُنصح بشدة بتطبيق مهلة لعنوان IP الخاص القابل للحل (RPA) لا تزيد عن 15 دقيقة وتغيير العنوان عند انتهاء المهلة لحماية خصوصية المستخدم.

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

• [C-4-1] يجب توفير عنصر تحكم للمستخدم لتفعيل/إيقاف القيمة المقروءة من خلال System API BluetoothAdapter.isBleScanAlwaysAvailable().

7.4.4. تقنية الاتصال القصير المدى

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

• يجب أن تتضمّن وحدة إرسال واستقبال وأجهزة ذات صلة بتقنية الاتصال القصير المدى (NFC).
• [C-0-1] يجب تنفيذ واجهات برمجة التطبيقات android.nfc.NdefMessage وandroid.nfc.NdefRecord حتى إذا لم تتضمّن إتاحة استخدام NFC أو الإفصاح عن ميزة android.hardware.nfc لأنّ الفئات تمثّل تنسيقًا لتمثيل البيانات لا يعتمد على البروتوكول.

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

• [C-1-1] يجب الإبلاغ عن ميزة android.hardware.nfc من خلال طريقة android.content.pm.PackageManager.hasSystemFeature().
• يجب أن يكون الجهاز قادرًا على قراءة رسائل NDEF وكتابتها من خلال معايير NFC التالية كما هو موضّح أدناه:
• [C-1-2] يجب أن يكون الجهاز قادرًا على العمل كقارئ/كاتب وفقًا لمعيار NFC Forum (على النحو المحدّد في المواصفة الفنية NFC Forum-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-3] يجب أن يكون الجهاز قادرًا على إرسال البيانات واستلامها من خلال المعايير والبروتوكولات التالية للاتصال المباشر بين الأجهزة:

  • ISO 18092
  • LLCP 1.2 (حدّده NFC Forum)
  • SDP 1.0 (حدّده NFC Forum)
  • بروتوكول NDEF Push
  • SNEP 1.0 (حدّده NFC Forum)
• [C-1-4] يجب أن يتضمّن التطبيق ميزة Android Beam، ويجب تفعيلها تلقائيًا.
• [C-1-5] يجب أن يكون بإمكان الجهاز الإرسال والاستلام باستخدام تقنية Android Beam، وذلك عند تفعيل تقنية Android Beam أو تفعيل وضع P2p آخر خاص بتقنية NFC.
• [C-1-6] يجب تنفيذ الخادم التلقائي لبروتوكول SNEP. يجب إرسال رسائل NDEF الصالحة التي يتلقّاها خادم SNEP التلقائي إلى التطبيقات باستخدام النية android.nfc.ACTION_NDEF_DISCOVERED. يجب ألّا يؤدي إيقاف ميزة Android Beam في الإعدادات إلى إيقاف إرسال رسالة NDEF الواردة.
• [C-1-7] يجب الالتزام android.settings.NFCSHARING_SETTINGS بعرض إعدادات مشاركة NFC.
• [C-1-8] يجب تنفيذ خادم NPP. يجب معالجة الرسائل التي يتلقّاها خادم NPP بالطريقة نفسها التي يعالج بها الخادم التلقائي لبروتوكول SNEP الرسائل.
• [C-1-9] يجب تنفيذ برنامج SNEP عميل ومحاولة إرسال NDEF P2P الصادر إلى خادم SNEP التلقائي عند تفعيل ميزة Android Beam. إذا لم يتم العثور على خادم SNEP تلقائي، يجب أن يحاول العميل الإرسال إلى خادم NPP.
• [C-1-10] يجب السماح للأنشطة التي تعمل في المقدّمة بضبط رسالة NDEF للاتصال المباشر بين الأجهزة التي تغادر الجهاز باستخدام android.nfc.NfcAdapter.setNdefPushMessage وandroid.nfc.NfcAdapter.setNdefPushMessageCallback وandroid.nfc.NfcAdapter.enableForegroundNdefPush.
• يجب استخدام إيماءة أو تأكيد على الشاشة، مثل "اللمس للإرسال"، قبل إرسال رسائل NDEF للاتصال المباشر بين الأجهزة.
• [C-1-11] يجب أن يتيح الجهاز تسليم اتصال NFC إلى البلوتوث عندما يكون الجهاز متوافقًا مع ملف Bluetooth Object Push Profile.
• [C-1-12] يجب أن يتيح الجهاز تسليم الاتصال إلى البلوتوث عند استخدام android.nfc.NfcAdapter.setBeamPushUris، وذلك من خلال تنفيذ مواصفات "الإصدار 1.2 من تسليم الاتصال" و"الإصدار 1.0 من ميزة "الإقران الآمن والبسيط عبر البلوتوث" باستخدام NFC من منتدى NFC. يجب أن ينفذ هذا التنفيذ خدمة LLCP الخاصة بنقل البيانات باستخدام اسم الخدمة "urn:nfc:sn:handover" لتبادل طلب نقل البيانات/اختيار السجلات عبر NFC، ويجب أن يستخدم ملف تعريف Bluetooth Object Push لنقل البيانات الفعلي عبر البلوتوث. لأسباب قديمة (للحفاظ على التوافق مع أجهزة Android 4.1)، من المفترض أن يستمر التنفيذ في قبول طلبات SNEP GET لتبادل طلب النقل أو اختيار السجلات عبر NFC. ومع ذلك، يجب ألا يُرسِل التنفيذ نفسه طلبات SNEP GET لإجراء عملية تسليم الاتصال.
• [C-1-13] يجب إجراء استطلاع لجميع التكنولوجيات المتوافقة أثناء وضع رصد NFC.
• يجب أن يكون الجهاز في وضع اكتشاف NFC عندما يكون مفعَّلاً والشاشة نشطة وشاشة القفل مفتوحة.
• يجب أن يكون الجهاز قادرًا على قراءة الرمز الشريطي وعنوان URL (في حال كان مُشفَّرًا) لمنتجات الرمز الشريطي NFC الرقيق.

يُرجى العِلم أنّ الروابط المتاحة للجميع غير متاحة لمواصفات JIS وISO وNFC Forum المذكورة أعلاه.

يتيح نظام Android وضع "محاكاة البطاقة المضيفة" (HCE) عبر NFC.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شريحة تحكم NFC قادرة على استخدام تقنية HCE (لبروتوكول NfcA و/أو NfcB) وتتوافق مع توجيه معرّف التطبيق (AID)، يجب استيفاء الشروط التالية:

• [C-2-1] يجب الإبلاغ عن ثابت الميزة android.hardware.nfc.hce.
• [C-2-2] يجب أن تكون متوافقة مع واجهات برمجة تطبيقات NFC HCE كما هو محدّد في حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

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

• [C-3-1] يجب الإبلاغ عن ثابت الميزة android.hardware.nfc.hcef.
• [C-3-2] يجب تنفيذ واجهات برمجة تطبيقات محاكاة بطاقات NfcF على النحو المحدّد في حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة استخدام تكنولوجيا NFC بشكل عام كما هو موضّح في هذا القسم وتتيح استخدام تقنيات MIFARE (MIFARE Classic وMIFARE Ultralight وNDEF على MIFARE Classic) في دور القارئ/المحرِّر، يجب استيفاء الشروط التالية:

• [C-4-1] يجب تنفيذ واجهات برمجة تطبيقات Android المقابلة كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
• [C-4-2] يجب الإبلاغ عن الميزة com.nxp.mifare من الطريقة android.content.pm.PackageManager.hasSystemFeature()‎. يُرجى العِلم أنّ هذه ليست ميزة عادية في Android، وبالتالي لا تظهر كقيمة ثابتة في فئة android.content.pm.PackageManager.

7.4.5. الحد الأدنى من إمكانات الشبكة

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

• [C-0-1] يجب أن يتضمّن الجهاز إمكانية استخدام شكل واحد أو أكثر من أشكال الشبكات لربط البيانات. وعلى وجه التحديد، يجب أن تتضمّن عمليات تنفيذ الأجهزة معيار بيانات واحدًا على الأقل يمكنه نقل البيانات بسرعة 200 كيلوبت في الثانية أو أكثر. تشمل الأمثلة على التقنيات التي تستوفي هذا الشرط EDGE وHSPA وEV-DO و802.11g وEthernet وBluetooth PAN.
• يجب أن يتضمّن أيضًا معيارًا واحدًا على الأقل من معايير البيانات اللاسلكية الشائعة، مثل 802.11 (Wi-Fi)، عندما يكون معيار الشبكة المادية (مثل إيثرنت) هو اتصال البيانات الأساسي.
• يجوز تنفيذ أكثر من شكل واحد من أشكال ربط البيانات.
• [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 والمنفذ المستخدَمين فعليًا لإرسال الحِزم واستلامها على الشبكة.

يعتمد المستوى المطلوب من توافق IPv6 على نوع الشبكة، كما هو موضّح في المتطلبات التالية.

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

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

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

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

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

• يجب أن يكون الجهاز متوافقًا مع بروتوكول IPv6 (IPv6 فقط وربما الإصدار المزدوج) على شبكة الجوّال.

إذا كانت عمليات تنفيذ الأجهزة متوافقة مع أكثر من نوع شبكة واحد (مثل Wi-Fi وبيانات شبكة الجوّال)، يتم تنفيذ ما يلي:

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

7.4.6. إعدادات المزامنة

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

• [C-0-1] يجب تفعيل الإعداد الرئيسي للمزامنة التلقائية تلقائيًا لكي تُعرِض الطريقة getMasterSyncAutomatically() القيمة "صحيح".

7.4.7. توفير البيانات

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

• [SR] يُنصح بشدة بتوفير وضع توفير البيانات.

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

• [C-1-1] يجب أن تتيح جميع واجهات برمجة التطبيقات في فئة ConnectivityManager على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK)
• [C-1-2] يجب توفير واجهة مستخدم في الإعدادات تعالج نية Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS، ما يسمح للمستخدمين بإضافة تطبيقات إلى القائمة المسموح بها أو إزالتها منها.

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

• [C-2-1] يجب عرض القيمة RESTRICT_BACKGROUND_STATUS_DISABLED للعنصر ConnectivityManager.getRestrictBackgroundStatus()
• [C-2-2] يجب عدم بث ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.
• [C-2-3] يجب أن يتضمّن نشاطًا يعالج النية Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS، ولكن يجوز تنفيذه كإجراء لا يؤدي إلى أيّ تأثير.

7.4.8. العناصر الآمنة

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

• [C-1-1] يجب إدراج أدوات قراءة عناصر الأمان المتاحة عند استدعاء طريقة android.se.omapi.SEService.getReaders().

7.5. الكاميرات

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

• [C-1-1] يجب الإفصاح عن علامة ميزة android.hardware.camera.any.
• [C-1-2] يجب أن يكون من الممكن للتطبيق تخصيص 3 صور نقطية RGBA_8888 في الوقت نفسه مساوية لحجم الصور التي تنتجها أداة استشعار الكاميرا ذات الدقة الأعلى على الجهاز، وذلك عندما تكون الكاميرا مفتوحة بغرض المعاينة الأساسية وتصوير الصور الثابتة.

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.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-SR] يُنصح بشدة بتوفير جهاز كاميرا منطقي يسرد الإمكانية CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA للأجهزة التي تحتوي على كاميرات متعددة تواجه الاتجاه نفسه، وتتألف من كل كاميرا مادية تواجه هذا الاتجاه، ما دام نوع الكاميرا المادية متوافقًا مع الإطار وCameraCharacteristics.INFO_SUPPORTED_HARDWARE_LEVEL للكاميرات المادية هو LIMITED أو FULL أو LEVEL_3.

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

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

• مساحة تخزين قابلة للإزالة يمكن للمستخدم الوصول إليها، مثل فتحة بطاقة Secure Digital (SD)
• جزء من مساحة التخزين الداخلية (غير القابلة للإزالة) كما هو منفذ في "المشروع المفتوح المصدر لنظام Android" ‏ (AOSP).

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

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

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

• يجب استخدام واجهة برمجة التطبيقات لنظام التشغيل Android Open Source Project (AOSP) في مساحة التخزين المشتركة للتطبيق الداخلي.
• يجوز له مشاركة مساحة التخزين مع البيانات الخاصة بالتطبيق.

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

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

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ 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 أمبير وفقًا لمعيار المقاوم من النوع 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 على الجهاز، والذي من المفترض أن يتم شحنه مع كابل يتيح ربطه بمنفذ من النوع A عادي
• [C-1-3] يجب عدم شحن الجهاز مع محوِّل يحول من منافذ USB من النوع A أو micro-AB إلى منفذ من النوع C (مقبس).
• [SR] يُنصح بشدة بتنفيذ فئة الصوت عبر USB كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
• يجب أن يتيح شحن الجهاز الملحق USB المتصل به أثناء وضع المضيف، مع عرض تيار مصدر لا يقل عن 1.5 أمبير كما هو محدّد في قسم مَعلمات الإنهاء من الإصدار 1.2 من مواصفات الكابل والموصّل USB Type-C لموصّلات USB Type-C أو استخدام نطاق تيار الإخراج لمنفذ الشحن(CDP) كما هو محدّد في مواصفات شحن البطارية عبر USB، الإصدار 1.2 لموصّلات Micro-AB.
• يجب أن تتوافق مع معايير USB من النوع C وأن تتيح استخدامها.

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

• [C-2-1] يجب أن يكون متوافقًا مع فئة USB HID.
• [C-2-2] يجب أن يتيح الجهاز رصد حقول بيانات HID التالية المحدّدة في جداول استخدام USB HID وطلب استخدام الأوامر الصوتية وربطها بثوابت KeyEvent على النحو التالي:
  • رقم تعريف صفحة الاستخدام (0xC) ورقم تعريف الاستخدام (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • صفحة الاستخدام (0xC) معرّف الاستخدام (0x0E9): KEYCODE_VOLUME_UP
  • رقم تعريف استخدام صفحة الاستخدام (0xC): KEYCODE_VOLUME_DOWN
  • رقم تعريف استخدام صفحة الاستخدام (0xC): 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.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.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_OVR_multiview_multisampled_render_to_texture وGL_EXT_protected_textures وعرض الإضافات في قائمة إضافات GL المتاحة.
• [C-SR] يُنصح بشدة بتنفيذ GL_EXT_external_buffer وGL_EXT_EGL_image_array وعرض الإضافات في قائمة إضافات 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] يجب عدم السماح بتشغيل أي عمليات أخرى في مساحة المستخدم (باستثناء برامج تشغيل الأجهزة التي يستخدمها التطبيق)، ولكن يجوز السماح بتشغيل بعض عمليات نظام التشغيل حسب الضرورة.

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

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

8.1. اتساق تجربة المستخدم

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

8.2. أداء الوصول إلى الإدخال/الإخراج من الملفات

من خلال توفير مرجع قياسي شائع لأداء الوصول إلى الملفات بشكلٍ متسق في مساحة تخزين البيانات الخاصة بالتطبيق (قسم /data)، يمكن لمطوّري التطبيقات وضع توقعات مناسبة تساعدهم في تصميم برامجهم. قد تفرض عمليات تنفيذ الأجهزة، استنادًا إلى نوع الجهاز، متطلبات معيّنة موضّحة في القسم 2 لعمليات القراءة والكتابة التالية:

• أداء الكتابة التسلسلية: يتم قياسها من خلال كتابة ملف بحجم 256 ميغابايت باستخدام ذاكرة تخزين مؤقت للكتابة بسعة 10 ميغابايت.
• أداء الكتابة العشوائية: يتم قياسها من خلال كتابة ملف بحجم 256 ميغابايت باستخدام ذاكرة تخزين مؤقت للكتابة بسعة 4 كيلوبايت.
• أداء القراءة التسلسلية: يتم قياسها من خلال قراءة ملف بحجم 256 ميغابايت باستخدام ذاكرة تخزين مؤقت للكتابة بسعة 10 ميغابايت.
• أداء القراءة العشوائية: يتم قياسها من خلال قراءة ملف بحجم 256 ميغابايت باستخدام وحدة تخزين مؤقت للكتابة بسعة 4 كيلوبايت.

8.3. أوضاع توفير الطاقة

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

بالإضافة إلى أوضاع توفير الطاقة، قد تُنفِّذ عمليات تنفيذ أجهزة 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 Cloud Messaging إلى تطبيقات تابعة لجهات خارجية، يجب أن يخرج الجهاز من حالة S3 ما لم يضع المستخدم الجهاز في حالة غير نشطة. هذه ليست أمثلة شاملة، ويعمل نظام التشغيل AOSP على تنفيذ إشارات استيقاظ واسعة النطاق تؤدي إلى الاستيقاظ من هذه الحالة.

8.4. احتساب استهلاك الطاقة

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

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

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

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

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

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

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

9.2. رقم تعريف المستخدم (UID) وعزل العمليات

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

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

9.3. أذونات نظام الملفات

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

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

9.4. بيئات التنفيذ البديلة

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

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

• [C-0-2] يجب عدم منح أوقات التشغيل البديلة إذن الوصول إلى الموارد المحمية بأذونات لم يتم طلبها في ملف AndroidManifest.xml الخاص بوقت التشغيل من خلال آلية <uses-permission>.

• [C-0-3] يجب ألا تسمح أوقات التشغيل البديلة للتطبيقات باستخدام الميزات المحمية بأذونات Android المخصّصة لتطبيقات النظام.

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

• [C-0-5] يجب عدم تشغيل أو منح أو منح إمكانية الوصول إلى مساحات العزل المقابلة لتطبيقات Android الأخرى باستخدام أوقات التشغيل البديلة.

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

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

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

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

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

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 (مثل 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] يجب تنفيذ عزل جدول صفحات kernel على جميع الأجهزة التي يتم شحنها في الأصل مع المستوى 28 من واجهة برمجة التطبيقات أو أعلى (مثل CONFIG_PAGE_TABLE_ISOLATION أو CONFIG_UNMAP_KERNEL_AT_EL0).
• [SR] يُنصح بشدة بالاحتفاظ ببيانات kernel التي يتم كتابتها فقط أثناء عملية الإعداد ووضع علامة "للقراءة فقط" عليها بعد اكتمال عملية الإعداد (مثل __ro_after_init).
• [SR] يُنصح بشدة بتعشيب تنسيق رمز النواة والذاكرة، وتجنُّب التعرّض للاختراقات التي قد تؤدي إلى تعطيل العشوائية (مثل CONFIG_RANDOMIZE_BASE مع التشويش في أداة تحميل البرامج من خلال /chosen/kaslr-seed Device Tree node أو EFI_RNG_PROTOCOL).

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

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

• [C-SR] يُنصح بشدة بعدم إيقاف ميزة "سلامة تدفّق التحكّم" (CFI) أو ميزة "التطهير من تدفّق الأعداد الصحيحة" (IntSan) في المكونات التي تم تفعيلها فيها.
• [C-SR] يُنصح بشدة بتفعيل كل من CFI وIntSan لأي مكوّنات إضافية حسّاسة للأمان في مساحة المستخدم كما هو موضّح في CFI وIntSan.

9.8. الخصوصية

9.8.1. سجلّ الاستخدام

يخزِّن Android سجلّ خيارات المستخدم ويدير هذا السجلّ من خلال UsageStatsManager.

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

• [C-0-1] يجب الاحتفاظ بسجلّ المستخدمين هذا لفترة زمنية معقولة.
• [SR] يُنصح بشدة بالاحتفاظ بفترة الاحتفاظ التي تبلغ 14 يومًا كما تم ضبطها تلقائيًا في عملية تنفيذ AOSP.

يخزِّن Android أحداث النظام باستخدام معرّفات StatsLog، ويدير هذا السجلّ من خلال واجهتَي برمجة التطبيقات StatsManager وIncidentManager System API.

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

• [C-0-2] يجب أن يتضمّن تقرير الحادثة الذي أنشأته فئة System API IncidentManager الحقول التي تم وضع علامة DEST_AUTOMATIC عليها فقط.
• [C-0-3] يجب عدم استخدام معرّفات أحداث النظام لتسجيل أي حدث آخر غير ما هو موضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل StatsLog. في حال تسجيل أحداث نظام إضافية، قد يتم استخدام معرّف ذرة مختلف في النطاق بين 100,000 و200,000.

9.8.2. يتم التسجيل

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

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

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

• [C-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.9. تشفير مساحة تخزين البيانات

إذا كان أداء التشفير وفقًا لمعيار Advanced Encryption Standard (AES)، والذي يتم قياسه باستخدام تكنولوجيا AES الأفضل أداءً المتاحة على الجهاز (مثل ARM Cryptography Extensions)، أعلى من 50 ميغابايت في الثانية، يجب أن تستوفي عمليات تنفيذ التشفير على الجهاز الشروط التالية:

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

إذا كان أداء التشفير باستخدام مخطط AES يبلغ 50 ميغابايت في الثانية أو أقل، يجوز لعمليات تنفيذ الأجهزة استخدام Adiantum-XChaCha12-AES بدلاً من شكل AES المُدرَج في أيٍّ ممّا يلي: AES-256-XTS في الفقرة 9.9.2 [C-1-5]، وAES-256 في وضع CBS-CTS في الفقرة 9.9.2 [C-1-6]، وAES في الفقرة 9.9.3 [C-1-1]، وAES في الفقرة 9.9.3 [C-1-3].

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

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

• يجب أن تستوفي متطلبات تشفير مساحة تخزين البيانات المذكورة أعلاه من خلال تنفيذ التشفير على مستوى الملفات (FBE).

9.9.1. التشغيل المباشر

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

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

• [C-0-2] يجب مواصلة بث طلبات ACTION_LOCKED_BOOT_COMPLETED وACTION_USER_UNLOCKED للإشارة إلى التطبيقات المتوافقة مع ميزة "التمهيد المباشر" بأنّ مواقع تخزين "التشفير على مستوى الجهاز" (DE) و"التشفير على مستوى بيانات الاعتماد" (CE) متاحة للمستخدم.

9.9.2. التشفير على مستوى الملفات

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

• [C-1-1] يجب أن يتم تشغيل الجهاز بدون طلب بيانات الاعتماد من المستخدم والسماح للتطبيقات المتوافقة مع ميزة "التشغيل المباشر" بالوصول إلى مساحة التخزين المشفَّرة على الجهاز (DE) بعد بث رسالة ACTION_LOCKED_BOOT_COMPLETED.
• [C-1-2] يجب عدم السماح بالوصول إلى مساحة التخزين المشفَّرة لبيانات الاعتماد (CE) إلا بعد أن يفتح المستخدم قفل الجهاز من خلال تقديم بيانات اعتماده (مثل رمز المرور أو رقم التعريف الشخصي أو النمط أو بصمة الإصبع) ويتم بث رسالة ACTION_USER_UNLOCKED.
• [C-1-3] يجب عدم توفير أي طريقة لفتح قفل مساحة التخزين المحمية بتقنية CE بدون بيانات الاعتماد التي يقدّمها المستخدم أو مفتاح وديعة مسجَّل.
• [C-1-4] يجب أن يكون الجهاز متوافقًا مع ميزة "التشغيل المتحقّق منه" وأن يضمن أنّ مفاتيح DE مرتبطة بشكل مشفَّر بنقطة ثقة الجهاز.
• [C-1-5] يجب أن تتيح تشفير محتوى الملفات باستخدام AES-256-XTS. يشير معيار AES-256-XTS إلى معيار التشفير المتقدّم بطول مفتاح 256 بت، ويتم تشغيله في وضع XTS. يبلغ الطول الكامل لمفتاح XTS 512 بت.

• [C-1-6] يجب أن تتيح الخدمة تشفير أسماء الملفات باستخدام معيار AES-256 في وضع CBC-CTS.

• مفاتيح حماية مساحتَي التخزين CE وDE:

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

• [C-1-8] يجب ربط مفاتيح التشفير المتقدّم ببيانات اعتماد شاشة القفل الخاصة بالمستخدم.
• [C-1-9] يجب ربط مفاتيح CE برمز مرور تلقائي عندما لا يحدّد المستخدم بيانات اعتماد شاشة القفل.

• [C-1-10] يجب أن تكون فريدة ومميّزة، بعبارة أخرى، لا يتطابق مفتاح CE أو DE الخاص بأي مستخدم مع مفاتيح CE أو DE الخاصة بأي مستخدم آخر.

• [C-1-11] يجب استخدام التشفيرات وأطوال المفاتيح والأوضاع المتوافقة بشكلٍ إلزامي تلقائيًا.

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

• يجب أن يكون بالإمكان تفعيل ميزة "التشغيل المباشر" في التطبيقات الأساسية المثبَّتة مسبقًا (مثل المنبّه والهاتف وMessenger).

• قد توفّر التشفيرات البديلة وأطوال المفاتيح والأوضاع لتشفير محتوى الملف واسم الملف.

يقدّم مشروع Android Open Source الإصدار الأصلي من هذه الميزة استنادًا إلى ميزة التشفير ext4 في نواة Linux.

9.9.3. تشفير القرص بالكامل

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

• [C-1-1] يجب استخدام AES في وضع مصمّم للتخزين (مثل XTS أو CBC-ESSIV)، وبطول مفتاح التشفير 128 بت أو أكثر.
• [C-1-2] يجب استخدام رمز مرور تلقائي لف مفتاح التشفير، ويجب عدم كتابة مفتاح التشفير في مساحة التخزين في أي وقت بدون تشفير.
• [C-1-3] يجب أن يشفِّر معيار AES مفتاح التشفير تلقائيًا ما لم يوقف المستخدم هذا الإجراء صراحةً، باستثناء الحالات التي يكون فيها مفتاح التشفير قيد الاستخدام النشط، مع تمديد بيانات اعتماد شاشة القفل باستخدام خوارزمية تمديد بطيئة (مثل PBKDF2 أو scrypt).
• [C-1-4] يجب أن تكون خوارزمية تمديد كلمة المرور التلقائية أعلاه مرتبطة تشفيريًا بملف تخزين المفاتيح هذا عندما لا يحدّد المستخدم بيانات اعتماد شاشة القفل أو يوقف استخدام رمز المرور للتشفير ويوفّر الجهاز ملف تخزين مفاتيح مستندًا إلى الأجهزة.
• [C-1-5] يجب عدم إرسال مفتاح التشفير خارج الجهاز (حتى عند تشفيره باستخدام رمز مرور المستخدم و/أو مفتاح مرتبط بالجهاز).

يقدّم مشروع Android Open Source الإصدار الأصلي من هذه الميزة، استنادًا إلى ميزة dm-crypt في نواة Linux.

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

إذا سبق أن تم إطلاق عمليات تنفيذ الأجهزة بدون توفير متطلبات C-1-8 إلى C-1-10 على إصدار أقدم من Android ولا يمكن إضافة متطلبات هذه المتطلبات من خلال تحديث لنظام التشغيل، قد يتم إعفاؤها من المتطلبات.

يقدّم "مشروع مفتوح المصدر لنظام Android" رمزًا تنفيذيًا مفضّلاً لهذه الميزة في مستودع external/avb/، والذي يمكن دمجه في أداة تحميل التشغيل المستخدَمة لتحميل نظام Android.

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

• [C-R] يُنصح بتوفُّر Android Protected Confirmation API.

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

• [C-3-1] يجب الإبلاغ عن true لواجهة برمجة التطبيقات ConfirmationPrompt.isSupported().
• [C-3-2] يجب التأكّد من أنّ الجهاز الآمن يتحكّم بشكل كامل في الشاشة بحيث لا يتمكّن نظام التشغيل Android من حظرها بدون رصدها من خلال الجهاز الآمن.
• [C-3-3] يجب التأكّد من أنّ الجهاز الآمن يتحكّم بشكل كامل في الشاشة اللمسية.

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 وحدة.
• [C-1-5] يجب السماح للمستخدم باختيار مهلة وضع السكون للانتقال من الحالة غير المُقفَلة إلى الحالة المُقفَلة، مع الحد الأدنى من المهلة المسموح بها التي تصل إلى 15 ثانية.

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

9.11.1. شاشة القفل الآمنة

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

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

• [C-SR] يُنصح بشدة بضبط طريقة واحدة فقط من الطرق التالية كطريقة المصادقة الأساسية:
  • رقم تعريف شخصي رقمي
  • كلمة مرور أبجدية رقمية
  • نمط تمرير سريع على شبكة من النقاط 3×3 بالضبط

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

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

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

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

• [C-3-1] يجب أن تكون إنتروبيا أقصر طول مسموح به للعناصر أكبر من 10 بت.
• [C-3-2] يجب أن يكون الحد الأقصى للانتروبيا لجميع الإدخالات المحتملة أكبر من 18 بت.
• [C-3-3] يجب ألّا تستبدل طريقة المصادقة الجديدة أيًا من طرق المصادقة الأساسية المقترَحة (أي رقم التعريف الشخصي والنقش وكلمة المرور) التي تم تنفيذها وتوفيرها في AOSP.
• [C-3-4] يجب إيقاف طريقة المصادقة الجديدة عندما يضبط تطبيق "وحدة التحكّم بسياسة الجهاز" سياسة جودة كلمة المرور من خلال طريقة DevicePolicyManager.setPasswordQuality() باستخدام ثابت جودة أكثر تقييدًا من PASSWORD_QUALITY_SOMETHING.

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

• [C-4-1] يجب أن تستوفي جميع المتطلبات الموضّحة في الفقرة 7.3.10.2.
• [C-4-2] يجب أن تتوفّر آلية احتياطية لاستخدام إحدى طرق المصادقة الأساسية المقترَحة التي تستند إلى سر معروف.
• [C-4-3] يجب إيقاف هذه الميزة والسماح فقط بالمصادقة الأساسية المقترَحة لفتح قفل الشاشة عندما يضبط تطبيق Device Policy Controller (DPC) سياسة ميزة keguard من خلال استدعاء الطريقة DevicePolicyManager.setKeyguardDisabledFeatures() مع أي من علامات المقاييس الحيوية المرتبطة (أي KEYGUARD_DISABLE_BIOMETRICS أو KEYGUARD_DISABLE_FINGERPRINT أو KEYGUARD_DISABLE_FACE أو KEYGUARD_DISABLE_IRIS).
• [C-4-4] يجب أن يطلب التطبيق من المستخدم المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) مرة واحدة على الأقل كل 72 ساعة أو أقل.
• [C-4-5] يجب أن يكون معدّل القبول الخاطئ مساويًا أو أقوى من المعدّل المطلوب لجهاز استشعار بصمة الإصبع كما هو موضّح في القسم القسم 7.3.10، أو يجب إيقافه وعدم السماح إلا بالمصادقة الأساسية المقترَحة لفتح قفل الشاشة عندما يضبط تطبيق "وحدة التحكّم في سياسة الجهاز" سياسة جودة كلمة المرور من خلال طريقة DevicePolicyManager.setPasswordQuality() باستخدام ثابت جودة أكثر تقييدًا من PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-SR] يُنصح بشدة بتوفير معدّلات قبول مرتفعة لعمليات التزوير والتزييف مساوية أو أعلى من المعدّلات المطلوبة لجهاز استشعار بصمة الإصبع كما هو موضّح في الفقرة 7.3.10.
• [C-4-6] يجب أن يتضمّن مسار معالجة آمنًا بحيث لا تسمح عملية اختراق نظام التشغيل أو النواة بإدخال البيانات مباشرةً للمصادقة بشكل زائف على أنّه المستخدم.
• [C-4-7] يجب إقران هذا الإجراء بإجراء تأكيد صريح (مثل الضغط على زر) للسماح بالوصول إلى مفاتيح تخزين المفاتيح إذا كان التطبيق يضبط true على KeyGenParameterSpec.Built.setUserAuthenticationRequired() وكانت المقاييس الحيوية غير نشطة (مثل الوجه أو القزحية حيث لا تتوفّر إشارة صريحة للنية).
• [C-SR] يُنصح بشدة بتأمين إجراء تأكيد المقاييس الحيوية السلبية بحيث لا يمكن لخداع نظام التشغيل أو نواة النظام. على سبيل المثال، يعني ذلك أنّ إجراء التأكيد المستنِد إلى زرّ مادي يتم توجيهه من خلال دبوس إدخال/إخراج (GPIO) مخصّص للأغراض العامة للإدخال فقط في عنصر آمن (SE) لا يمكن تشغيله بأي وسيلة أخرى غير الضغط على زرّ مادي.

إذا لم تستوفِ طرق المصادقة باستخدام المقاييس الحيوية معدّلات قبول عمليات التزوير والتصيّد كما هو موضّح في الفقرة 7.3.10:

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

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

• [C-8-1] يجب إيقاف الطريقة الجديدة عندما يضبط تطبيق "وحدة التحكّم بسياسة الجهاز" سياسة جودة كلمة المرور من خلال طريقة DevicePolicyManager.setPasswordQuality() باستخدام ثابت جودة أكثر تقييدًا من PASSWORD_QUALITY_UNSPECIFIED.
• [C-8-2] يجب عدم إعادة ضبط أدوات ضبط مدة صلاحية كلمة المرور التي ضبطها DevicePolicyManager.setPasswordExpirationTimeout().
• [C-8-3] يجب عدم مصادقة الوصول إلى ملفّات تخزين المفاتيح عندما يضبط التطبيق true على KeyGenParameterSpec.Builder.setUserAuthenticationRequired()).

9.11.2. StrongBox

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

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

• [C-SR] يُنصح بشدة بتوفير 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.12. حذف البيانات

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

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

10. اختبار توافق البرامج

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

10.1. مجموعة أدوات اختبار التوافق

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

• [C-0-1] يجب اجتياز مجموعة اختبار التوافق لنظام التشغيل Android (CTS) المتوفّرة من "المشروع المفتوح المصدر لنظام التشغيل Android"، باستخدام الإصدار النهائي من البرنامج المُرسَل على الجهاز.

• [C-0-2] يجب ضمان التوافق في حالات الغموض في CTS وأي عمليات إعادة تنفيذ لأجزاء من رمز المصدر المرجعي.

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

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

• [C-0-3] يجب اجتياز أحدث إصدار من CTS متاح في وقت اكتمال برنامج الجهاز.

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

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 الأساسي يتضمّن آلية تحديث تستوفي هذا الشرط.

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