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

‫1. مقدّمة

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

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

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

لكي يُعدّ الجهاز متوافقًا مع 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. أنواع الأجهزة)
  • C: Core (المتطلبات التي يتم تطبيقها على أي عمليات تنفيذ لأجهزة Android)
  • H: جهاز Android محمول
  • T: جهاز تلفزيون Android
  • ج: عملية إعداد Android Automotive
  • علامة التبويب: تنفيذ الأجهزة اللوحية التي تعمل بنظام التشغيل Android
• رقم تعريف الحالة
  • عندما يكون الشرط غير مشروط، يتم ضبط رقم التعريف هذا على 0.
  • عندما يكون الشرط مشروطًا، يتم تعيين الرقم 1 للشرط الأول، ويزداد الرقم بمقدار 1 ضمن القسم نفسه ونوع الجهاز نفسه.
• معرّف المتطلبات
  • يبدأ هذا المعرّف من 1 ويزيد بمقدار 1 ضمن القسم نفسه والشرط نفسه.

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

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

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

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

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

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

يجب أن تستوفي جميع عمليات تنفيذ أجهزة 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] يجب أن يتضمّن دعمًا لتقنيتَي Bluetooth وBluetooth LE.

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

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

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

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

إذا كانت عمليات تنفيذ "الأجهزة المحمولة" تحدّد توافقًا مع واجهة التطبيق الثنائية 32 بت فقط:

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

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

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

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

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

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

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

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

• ‫[7.6.1/H-8-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 1824 ميغابايت على الأقل إذا كان العرض التلقائي يستخدم دقة إطارات تصل إلى 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] يجب تنفيذ واجهة برمجة التطبيقات (API) الخاصة ببروتوكول 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 (برنامج الترميز AAC LC)
• ‫[5.1.1/H-0-4] ملف تعريف MPEG-4 HE AAC (برنامج ترميز 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] يجب أن يتضمّن لوحة إشعارات تتيح للمستخدم التحكّم مباشرةً في الإشعارات (مثل الردّ أو التأجيل أو الإغلاق أو الحظر) من خلال عناصر تحكّم سهلة الاستخدام، مثل أزرار الإجراءات أو لوحة التحكّم كما هو موضّح في مشروع Android المفتوح المصدر (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] يجب توفير إمكانية للمستخدم لعرض جميع التطبيقات المستثناة من وضعي "استعداد التطبيق" و"توفير الطاقة" (Doze).

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

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

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

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

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

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

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

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

2.3.1. الأجهزة

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

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

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

• [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 أو أعلى على الشاشات الكبيرة
  • tvddpi أو أعلى على الشاشات الكبيرة جدًا

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

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

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

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

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

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

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

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

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

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

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

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

• [5.2.2/T-SR] يُنصح بشدة بأن تتوافق أجهزة البث المباشر مع ترميز 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 إطارًا في الثانية مع ملف Baseline
• ‫[5.3.4.4/T-1-2] دقة عالية 1080p بمعدل 60 لقطة في الثانية باستخدام الملف التعريفي الرئيسي
• ‫[5.3.4.4/T-1-3] دقة عالية 1080p بمعدل 60 إطارًا في الثانية مع المستوى 4.2 من الملف الشخصي العالي

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

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

إذا كانت عمليات تنفيذ أجهزة التلفزيون التي تتضمّن برامج فك ترميز H.265 للأجهزة تتوافق مع فك ترميز H.265 وملف فك الترميز بدقة فائقة (UHD)، فإنّها:

• ‫[5.3.5.5/T-2-1] يجب أن تتوافق مع ملف تعريف فك الترميز بدقة فائقة الوضوح بمعدل 60 إطارًا في الثانية مع ملف تعريف Main10 Level 5 Main Tier.

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

• ‫[5.3.7.5/T-2-1] يجب أن تتوافق مع ملف تعريف فك الترميز بدقة فائقة (UHD) بمعدل 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 هرتز، وذلك حسب معدّل تكرار الفيديو في المنطقة التي يُباع فيها الجهاز لجميع شاشات العرض السلكية.

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

• [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 ميغابايت في الثانية.

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

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

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

• [8.4/T-0-1] يجب توفير ملف تعريف طاقة لكل مكوّن يحدّد قيمة استهلاك التيار لكل مكوّن من مكوّنات الجهاز ومعدّل استهلاك البطارية التقريبي الذي تسببه المكوّنات بمرور الوقت على النحو الموضّح في موقع "مشروع Android المفتوح المصدر".
• [8.4/T-0-2] يجب تسجيل جميع قيم استهلاك الطاقة بوحدة "ملّي أمبير ساعة" (mAh).
• [8.4/T-0-3] يجب الإبلاغ عن استهلاك طاقة وحدة المعالجة المركزية لكل معرّف UID خاص بكل عملية. يستوفي "مشروع 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. الأداء والطاقة

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

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

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

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

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

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

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

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

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

2.5.1. الأجهزة

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

• [7.1.1.1/A-0-1] يجب أن تتضمّن شاشة لا يقل حجمها القطري عن 6 بوصات.

• ‫[7.1.1.1/A-0-2] يجب أن يتضمّن الجهاز تصميمًا لمقاس الشاشة لا يقلّ عن 750 وحدة بكسل مستقلة عن الكثافة × 480 وحدة بكسل مستقلة عن الكثافة.

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

• [7.2.3/A-0-2] يجب إرسال كلّ من حدث الضغط العادي والضغط مع الاستمرار على زر الرجوع (KEYCODE_BACK) إلى التطبيق الذي يعمل في المقدّمة.

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

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

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

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

• [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/A] يجب أن تتضمّن إمكانية الاتصال بالبيانات المستندة إلى شبكة الجوّال.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

في حال كانت عمليات تنفيذ أجهزة Automotive بنظام 64 بت:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ‫[5.3/A-SR] 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] يُنصح بشدة بتضمين مكوّن واجهة مستخدم "الإعدادات السريعة".

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

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

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

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

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

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

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

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

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

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

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

• ‫[9.5/A-1-1] يجب أن يتضمّن حساب ضيف يتيح استخدام جميع الوظائف التي يوفّرها نظام المركبة بدون أن يُطلب من المستخدم تسجيل الدخول.

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

• ‫[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/Tab] يمكن تنفيذ واجهة برمجة التطبيقات Android Open Accessory (AOA).

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

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

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

3- البرامج

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

بيئة تنفيذ رمز بايت Dalvik المُدارة هي الوسيلة الأساسية لتشغيل تطبيقات Android. واجهة برمجة التطبيقات (API) لنظام التشغيل 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/ لفرع مستوى واجهة برمجة التطبيقات المناسب في مشروع Android مفتوح المصدر (AOSP). ومع ذلك، فإنّها:

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

3.1.1. إضافات Android

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

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

3.1.2. مكتبة Android

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

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

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

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

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

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

3.2.3.1. أهداف التطبيق الأساسية

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

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

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

3.2.3.2. حلّ النية

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

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

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

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

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

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

3.2.3.3. مساحات أسماء Intent

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

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

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

• [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 مفتوح المصدر.

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

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

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

• [C-0-1] يجب أن يكون متوافقًا مع واجهة واحدة أو أكثر من واجهات التطبيق الثنائية المحدّدة وأن يوفّر إمكانية التوافق مع حزمة تطوير البرامج الأصلية (NDK) لنظام التشغيل Android.
• [C-0-2] يجب أن يتضمّن دعمًا لتشغيل الرمز البرمجي في البيئة المُدارة من أجل استدعاء الرمز البرمجي الأصلي، وذلك باستخدام دلالات Java Native Interface (JNI) العادية.
• [C-0-3] يجب أن يكون متوافقًا مع المصدر (أي متوافقًا مع العناوين) ومتوافقًا مع الرمز الثنائي (بالنسبة إلى واجهة التطبيق الثنائية) مع كل مكتبة مطلوبة في القائمة أدناه.
• [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] يجب إدراج المكتبات الإضافية غير التابعة لمشروع Android مفتوح المصدر (AOSP) والتي يتم عرضها مباشرةً للتطبيقات الخارجية في /vendor/etc/public.libraries.txt.
• [C-0-10] يجب عدم إتاحة أي مكتبات مجمّعة من رموز برمجية أصلية أخرى، تم تنفيذها وتوفيرها في مشروع AOSP كمكتبات نظام، للتطبيقات التابعة لجهات خارجية التي تستهدف المستوى 24 من واجهة برمجة التطبيقات أو المستويات الأحدث لأنّها محجوزة.
• [C-0-11] يجب تصدير جميع رموز دوال OpenGL ES 3.1 وAndroid Extension Pack، كما هو محدّد في NDK، من خلال مكتبة libGLESv3.so. يُرجى العِلم أنّه يجب توفُّر جميع الرموز، ولكن يقدّم القسم 7.1.4.1 وصفًا أكثر تفصيلاً للمتطلبات المتعلقة بالحالات التي يُتوقّع فيها التنفيذ الكامل لكل وظيفة مقابلة.
• [C-0-12] يجب تصدير رموز الدوال الأساسية في Vulkan 1.0، بالإضافة إلى الإضافات VK_KHR_surface وVK_KHR_android_surface وVK_KHR_swapchain وVK_KHR_maintenance1 وVK_KHR_get_physical_device_properties2 من خلال مكتبة libvulkan.so. يُرجى العِلم أنّه يجب توفُّر جميع الرموز، ويقدّم القسم 7.1.4.2 وصفًا أكثر تفصيلاً للمتطلبات المتعلقة بالحالات التي يُتوقّع فيها التنفيذ الكامل لكل وظيفة مقابلة.
• يجب أن يتم إنشاؤها باستخدام رمز المصدر وملفات العناوين المتوفّرة في مشروع Android مفتوح المصدر

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

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

إذا كانت عمليات تنفيذ الأجهزة تشير إلى توافقها مع واجهة armeabi الثنائية، فإنّها:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.3. الإشعارات

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

3.8.3.1. طريقة عرض الإشعارات

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

• ‫[C-1-1] يجب أن تتوافق مع الإشعارات التي تستخدم ميزات الأجهزة، كما هو موضّح في مستندات حزمة تطوير البرامج (SDK)، وإلى الحدّ الممكن مع أجهزة تنفيذ الجهاز. على سبيل المثال، إذا كان تنفيذ الجهاز يتضمّن جهاز اهتزاز، يجب أن ينفّذ واجهات برمجة التطبيقات الخاصة بالاهتزاز بشكلٍ صحيح. إذا كان تنفيذ الجهاز يفتقر إلى الأجهزة، يجب تنفيذ واجهات برمجة التطبيقات المقابلة كعمليات غير فعّالة. يمكنك الاطّلاع على مزيد من التفاصيل حول هذا السلوك في الفقرة 7.
• [C-1-2] يجب أن يعرض جميع الموارد (الرموز وملفات الصور المتحركة وما إلى ذلك) المقدَّمة في واجهات برمجة التطبيقات أو في دليل أسلوب الرموز في شريط الحالة/النظام بشكلٍ صحيح، على الرغم من أنّه يجوز له تقديم تجربة مستخدم بديلة للإشعارات تختلف عن تلك التي يوفّرها التنفيذ المرجعي لمشروع Android المفتوح المصدر.
• [C-1-3] يجب الالتزام بالسلوكيات الموضّحة في واجهات برمجة التطبيقات لتعديل الإشعارات وإزالتها وتجميعها وتنفيذها بشكل صحيح.
• [C-1-4] يجب توفير السلوك الكامل لواجهة برمجة التطبيقات NotificationChannel الموضّح في حزمة SDK.
• [C-1-5] يجب توفير أداة تحكّم للمستخدم لحظر إشعارات تطبيق معيّن تابع لجهة خارجية وتعديلها على مستوى كل قناة وحزمة تطبيق.
• [C-1-6] يجب أيضًا توفير أداة تحكّم للمستخدم لعرض قنوات الإشعارات المحذوفة.
• [C-1-7] يجب عرض جميع الموارد (الصور والملصقات والرموز وما إلى ذلك) المقدَّمة من خلال Notification.MessagingStyle بشكل صحيح بجانب نص الإشعار بدون تفاعل إضافي من المستخدم. على سبيل المثال، يجب عرض جميع الموارد، بما في ذلك الرموز المقدَّمة من خلال android.app.Person، في محادثة جماعية تم إعدادها من خلال setGroupConversation.
• [C-SR] يُنصح بشدة بعرض أداة تحكّم تلقائيًا للمستخدم لحظر إشعارات تطبيق معيّن تابع لجهة خارجية على مستوى كل قناة وحزمة تطبيق بعد أن يرفض المستخدم هذا الإشعار عدة مرات.
• يجب أن تتوافق مع الإشعارات الغنية بصريًا.
• يجب عرض بعض الإشعارات ذات الأولوية الأعلى كتنبيهات.
• يجب أن يتضمّن وسيلة تتيح للمستخدم تأجيل الإشعارات.
• يمكن لتطبيق MAY إدارة إمكانية ظهور الإشعارات من تطبيقات الجهات الخارجية وتوقيت ظهورها فقط، وذلك للحدّ من مشاكل السلامة، مثل تشتيت انتباه السائق.

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

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

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

• [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" و"Material" المحدّدة التي يمكن لمطوّري التطبيقات استخدامها إذا أرادوا مطابقة مظهر وخصائص تصميم Holo كما هو محدّد في حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

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

• [C-1-1] يجب عدم تغيير أي من سمات مظهر Holo المعروضة للتطبيقات.
• [C-1-2] يجب أن تتوافق مع مجموعة سمات "Material"، ويجب ألّا تغيّر أيًا من سمات Material أو مواد العرض الخاصة بها المعروضة للتطبيقات.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

يتضمّن Android ميزة شاشات التوقف التفاعلية، والتي كانت تُعرف سابقًا باسم Dreams. تتيح شاشات التوقف للمستخدمين التفاعل مع التطبيقات عندما يكون الجهاز المتصل بمصدر طاقة غير نشط أو مثبّتًا في قاعدة مكتبية. قد تتضمّن أجهزة Android Watch شاشات توقّف، ولكن يجب أن تتضمّن الأنواع الأخرى من عمليات تنفيذ الأجهزة إمكانية استخدام شاشات التوقّف وأن توفّر خيار إعداد للمستخدمين لضبط شاشات التوقّف استجابةً للغرض 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 للّغات اللاتينية واليونانية والسيريلية، بما في ذلك نطاقات Latin Extended A وB وC وD، وجميع الرموز الرسومية في مجموعة رموز العملات في معيار Unicode 7.0
• يجب أن تتوافق مع رموز الإيموجي الخاصة بلون البشرة والعائلات المتنوعة على النحو المحدّد في التقرير الفني رقم 51 الصادر عن Unicode.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن محرّك 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 وحدة بكسل مستقلة الكثافة لنافذة "الصورة في الصورة"، وحد أدنى للعرض يبلغ 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] يجب تسجيل تطبيق "سياسة الجهاز" كتطبيق "مالك الجهاز" استجابةً لإجراء الغرض 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، وذلك عند بدء عملية التسجيل في تطبيق "سياسة إدارة الأجهزة الجوّالة" (DPC) باعتباره "مالك الجهاز" من خلال android.app.action.PROVISION_MANAGED_DEVICE.
• قد يتضمّن بيانات المستخدم على الجهاز قبل تسجيل تطبيق وحدة التحكّم بسياسة الجهاز (DPC) بصفتك "مالك الجهاز".

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

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

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

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

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

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

‫3.9.2 إتاحة الملف الشخصي المُدار

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

• [C-1-1] يجب أن تتوافق مع الملفات الشخصية المُدارة من خلال واجهات برمجة التطبيقات android.app.admin.DevicePolicyManager.
• [C-1-2] يجب السماح بإنشاء ملف عمل واحد فقط.
• [C-1-3] يجب استخدام شارة رمز (مشابهة لشارة العمل في المصدر العلوي لنظام التشغيل AOSP) لتمثيل التطبيقات والأدوات المُدارة وعناصر واجهة المستخدم الأخرى التي تحمل شارة، مثل "التطبيقات الحديثة" و"الإشعارات".
• [C-1-4] يجب عرض رمز إشعار (مشابه لشارة العمل في المصدر العلوي لنظام التشغيل Android) للإشارة إلى الوقت الذي يكون فيه المستخدم داخل تطبيق ملف شخصي مُدار.
• [C-1-5] يجب عرض إشعار مؤقت يشير إلى أنّ المستخدم في الملف الشخصي المُدار عند تنبيه الجهاز (ACTION_USER_PRESENT) وعندما يكون التطبيق الذي يتم تشغيله في المقدّمة ضِمن الملف الشخصي المُدار.
• [C-1-6] في حال توفّر ملف شخصي مُدار، يجب عرض عنصر مرئي في "أداة اختيار" Intent للسماح للمستخدم بإعادة توجيه Intent من الملف الشخصي المُدار إلى المستخدم الأساسي أو العكس، إذا كان ذلك مفعَّلاً من خلال "وحدة التحكّم في سياسة الجهاز".
• [C-1-7] في حال توفّر ملف شخصي مُدار، يجب توفير إمكانات الاستخدام التالية لكل من المستخدم الأساسي والملف الشخصي المُدار:
  • محاسبة منفصلة عن استخدام البطارية والموقع الجغرافي وبيانات الجوّال ومساحة التخزين للمستخدم الأساسي والملف الشخصي المُدار
  • إدارة تطبيقات VPN المثبَّتة بشكل مستقل ضمن المستخدم الأساسي أو الملف الشخصي المُدار
  • إدارة التطبيقات المثبَّتة في الملف الشخصي الأساسي أو ملف العمل بشكل مستقل
  • إدارة الحسابات بشكل مستقل ضمن الملف الشخصي للمستخدم الأساسي أو الملف المُدار
• [C-1-8] يجب التأكّد من أنّ تطبيقات الاتصال وجهات الاتصال والمراسلة المثبَّتة مسبقًا يمكنها البحث عن معلومات المتصل والاطّلاع عليها من ملف العمل (في حال توفّره) إلى جانب المعلومات من الملف الشخصي الأساسي، إذا سمح بذلك تطبيق "وحدة التحكّم في سياسة الجهاز".
• [C-1-9] يجب التأكّد من استيفاء جميع متطلبات الأمان السارية على جهاز تم تفعيل ميزة "عدة مستخدمين" عليه (راجِع الفقرة 9.5)، حتى إذا لم يتم احتساب الملف الشخصي المُدار كمستخدم آخر بالإضافة إلى المستخدم الأساسي.
• [C-1-10] يجب أن تتيح إمكانية تحديد شاشة قفل منفصلة تستوفي المتطلبات التالية لمنح إذن الوصول إلى التطبيقات التي تعمل في ملف شخصي مُدار.
  • يجب أن تلتزم عمليات تنفيذ الأجهزة بطلب DevicePolicyManager.ACTION_SET_NEW_PASSWORD وتعرض واجهة لإعداد بيانات اعتماد منفصلة لشاشة القفل في الملف الشخصي المُدار.
  • يجب أن تستخدم بيانات اعتماد قفل الشاشة في الملف الشخصي المُدار آليات تخزين وإدارة بيانات الاعتماد نفسها المستخدَمة في الملف الشخصي الرئيسي، كما هو موضّح في موقع "مشروع Android المفتوح المصدر" الإلكتروني.
  • يجب أن تنطبق سياسات كلمات المرور الخاصة بوحدة التحكّم في سياسة الجهاز (DPC) على بيانات اعتماد شاشة القفل للملف الشخصي المُدار فقط، ما لم يتم استدعاء مثيل DevicePolicyManager الذي تم إرجاعه بواسطة getParentProfileInstance.
• عند عرض جهات الاتصال من ملف العمل في سجلّ المكالمات المثبَّت مسبقًا وواجهة المستخدم أثناء المكالمة والإشعارات بالمكالمات الجارية والفائتة، يجب أن يتم تمييز جهات الاتصال وتطبيقات المراسلة بالشارة نفسها المستخدَمة للإشارة إلى تطبيقات ملف العمل.

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

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

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

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

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

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

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

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

• SHOULD aim for minimum codec latency, in others words, they
  • يجب ألا تستهلك المخزن المؤقت للإدخال وتخزّنه، وأن تعرضه مرة واحدة فقط بعد معالجته.
  • يجب ألا يتم الاحتفاظ بالمخازن المؤقتة التي تم فك ترميزها لمدة أطول من المدة المحددة في المعيار (مثل SPS).
  • يجب عدم الاحتفاظ بالمخازن المؤقتة المشفرة لفترة أطول من المدة التي تتطلّبها بنية مجموعة الصور.

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

يُرجى العِلم أنّ 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 (برنامج ترميز AAC+ المحسّن)
• ‫[C-1-4] AAC ELD (ترميز AAC المحسّن بزمن انتقال منخفض)
• ‫[C-1-11] xHE-AAC (ملف تعريف HE AAC الموسّع وفقًا للمعيار ISO/IEC 23003-3، والذي يتضمّن ملف تعريف USAC الأساسي وملف تعريف التحكّم في النطاق الديناميكي وفقًا للمعيار ISO/IEC 23003-4)
• ‫[C-1-5] FLAC
• [C-1-6] MP3
• ‫[C-1-7] MIDI
• ‫[C-1-8] Vorbis
• ‫[C-1-9] PCM/WAVE
• ‫[C-1-10] Opus

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

• ‫[C-2-1] يجب إجراء عملية فك الترميز بدون خلط الصوت (على سبيل المثال، يجب فك ترميز بث AAC بتنسيق 5.0 إلى خمس قنوات PCM، ويجب فك ترميز بث AAC بتنسيق 5.1 إلى ست قنوات PCM).
• [C-2-2] يجب أن تكون البيانات الوصفية للنطاق الديناميكي على النحو المحدّد في "التحكّم في النطاق الديناميكي" (DRC) في ISO/IEC 14496-3، وأن تكون مفاتيح android.media.MediaFormat DRC هي مفاتيح ضبط السلوكيات ذات الصلة بالنطاق الديناميكي لبرنامج ترميز الصوت. تم تقديم مفاتيح AAC DRC في الإصدار 21 من واجهة برمجة التطبيقات، وهي: KEY_AAC_DRC_ATTENUATION_FACTOR وKEY_AAC_DRC_BOOST_FACTOR وKEY_AAC_DRC_HEAVY_COMPRESSION وKEY_AAC_DRC_TARGET_REFERENCE_LEVEL وKEY_AAC_ENCODED_TARGET_LEVEL.

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

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

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

• قد يتيح MAY التحكّم في مستوى الصوت ونطاقه الديناميكي باستخدام ملف تعريف التحكّم في النطاق الديناميكي ISO/IEC 23003-4.

في حال توفّر توافق مع معيار ISO/IEC 23003-4 وتوفّر البيانات الوصفية لكل من ISO/IEC 23003-4 وISO/IEC 14496-3 في دفق بت تم فك ترميزه، سيتم تطبيق ما يلي:

• يجب أن تكون الأولوية للبيانات الوصفية ISO/IEC 23003-4.

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

التنسيق/برنامج الترميز	التفاصيل	أنواع الملفات/تنسيقات الحاويات المتوافقة
ملف تعريف MPEG-4 AAC (AAC LC)	إتاحة المحتوى أحادي/ثنائي/5.0/5.1 مع معدّلات بيانات في الملف الصوتي تتراوح بين 8 و48 كيلوهرتز	3GPP‏ (‎.3gp) ‫MPEG-4 ‏(mp4.،‏ m4a.) ملف ADTS AAC الأولي (لا يمكن استخدام ADIF) ‫MPEG-TS (.ts، لا يمكن البحث فيه)
ملف تعريف MPEG-4 HE AAC (‏AAC+)	إتاحة المحتوى الأحادي/الاستيريو/5.0/5.1 بمعدّلات بيانات في الملف الصوتي تتراوح بين 16 و48 كيلوهرتز
ملف تعريف MPEG-4 HE AACv2 (AAC+ محسّن)	إتاحة المحتوى الأحادي/الاستيريو/5.0/5.1 بمعدّلات بيانات في الملف الصوتي تتراوح بين 16 و48 كيلوهرتز
‫AAC ELD (الترميز المتقدّم للصوت مع تأخير منخفض محسّن)	إتاحة المحتوى الأحادي أو الاستيريو بمعدّلات بيانات في الملف الصوتي تتراوح بين 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	صوت أحادي/استيريو بمعدل نقل بيانات ثابت (CBR) أو متغيّر (VBR) يتراوح بين 8 و320 كيلوبت في الثانية	MP3 ‏(‎.mp3)
MIDI	النوعان 0 و1 من ملفات MIDI الإصداران 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، الإصدار 4.0 من نظام التشغيل Android والإصدارات الأحدث)
PCM/WAVE	‫16-bit linear PCM (بمعدّلات تصل إلى الحدّ الأقصى للأجهزة) يجب أن تتوافق الأجهزة مع معدّلات البيانات في الملفّ الصوتي لتسجيل 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	Base+progressive	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] يجب أن تتوافق برامج ترميز الفيديو مع أحجام bytebuffer للإخراج والإدخال التي تستوعب أكبر إطار مضغوط وغير مضغوط ممكن وفقًا للمعيار والإعداد، ولكن يجب أيضًا عدم الإفراط في التخصيص.

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

إذا كانت عمليات تنفيذ الأجهزة تعلن عن إتاحة ملفات تعريف HDR من خلال 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 فقط، لا يمكن البحث فيه، الإصدار 3.0 من نظام التشغيل Android أو الإصدارات الأحدث)
‫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 تقريبًا من معدّل نقل البيانات بين فواصل الإطارات الداخلية (إطارات I).
• يجب ألا تتجاوز% 100 من معدّل نقل البيانات خلال فترة زمنية متغيرة تبلغ ثانية واحدة.

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

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

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

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

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

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

5.2.1. H.263

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

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

5.2.2. H-264

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

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

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

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

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

5.2.3. VP8

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

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

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

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

	الدقة العادية (جودة منخفضة)	الدقة العادية (جودة عالية)	دقة عالية - 720p	دقة عالية - 1080p
دقة الفيديو	‫320 × 180 بكسل	‫640 × 360 بكسل	‫1280 × 720 بكسل	‫‎1920 x 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] يجب أن يتوافق مع Simple Profile Level 3.

5.3.4. H.264

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

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

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

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

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

5.3.5. ‫H.265 (HEVC)

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

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

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

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

	الدقة العادية (جودة منخفضة)	الدقة العادية (جودة عالية)	دقة عالية - 720p	دقة عالية - 1080p	دقة فائقة
دقة الفيديو	‫352 × 288 بكسل	‫720 × 480 بكسل	‫1280 × 720 بكسل	‫‎1920 x 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 x 1080 بكسل
عدد اللقطات في الثانية في الفيديو	30 إطارًا في الثانية	30 إطارًا في الثانية	‫30 لقطة في الثانية (‫60 لقطة في الثانيةتلفزيون)	‫30 (60 لقطة في الثانيةتلفزيون)
معدّل نقل بيانات الفيديو	‫800 كيلوبت في الثانية	‫2 ميغابت في الثانية	‫8 ميغابت في الثانية	20 ميغابت في الثانية

5.3.7. VP9

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

• ‫[C-1-1] يجب أن تتوافق مع ملفات تعريف فك ترميز الفيديو بدقة عادية (SD) كما هو موضّح في الجدول التالي.
• يجب أن تتوافق مع ملفات تعريف فك الترميز عالية الدقة كما هو موضّح في الجدول التالي.

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

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

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

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

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

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

على الرغم من أنّ بعض المتطلبات الموضّحة في هذا القسم مُدرَجة على أنّها SHOULD منذ الإصدار 4.3 من نظام التشغيل Android، من المخطّط أن يتم تغييرها إلى MUST في تعريف التوافق للإصدارات المستقبلية. يُنصح بشدة بأن تستوفي أجهزة 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 هرتز.
• يجب تسجيل بث الصوت الخاص بالتعرّف على الصوت مع ضبط حساسية الإدخال على مستوى طاقة صوتي يبلغ 90 ديسيبل (SPL) عند 1000 هرتز، ما يؤدي إلى الحصول على قيمة RMS تبلغ 2500 لعينات 16 بت.
• يجب أن يسجّل دفق الصوت الخاص بالتعرّف على الصوت، وذلك لكي تتتبّع مستويات اتساع تعديل رمز النبض (PCM) بشكل خطي التغييرات في مستوى ضغط الصوت (SPL) للإدخال على مدى نطاق 30 ديسيبل على الأقل من ‎-18 ديسيبل إلى ‎+12 ديسيبل بالنسبة إلى 90 ديسيبل SPL عند الميكروفون.
• يجب تسجيل بث الصوت الخاص بالتعرّف على الصوت مع تشويه توافقي إجمالي (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 بت، وfloat
  • القنوات: أحادية الصوت أو استيريو أو إعدادات صالحة لقنوات متعدّدة مع ما يصل إلى 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 التي يمكن التحكّم فيها من خلال الفئات الفرعية Equalizer وLoudnessEnhancer من AudioEffect.
• ‫[C-1-2] يجب أن يتيح تنفيذ واجهة برمجة التطبيقات الخاصة بأداة العرض، ويمكن التحكّم فيها من خلال الفئة Visualizer.
• [C-1-3] يجب أن يتيح تنفيذ EFFECT_TYPE_DYNAMICS_PROCESSING الذي يمكن التحكّم فيه من خلال فئة AudioEffect الفرعية DynamicsProcessing.
• يجب أن تتوافق مع عمليات التنفيذ EFFECT_TYPE_BASS_BOOST وEFFECT_TYPE_ENV_REVERB وEFFECT_TYPE_PRESET_REVERB وEFFECT_TYPE_VIRTUALIZER التي يمكن التحكّم فيها من خلال الفئات الفرعية AudioEffect BassBoost وEnvironmentalReverb وPresetReverb وVirtualizer.

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

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

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

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

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

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

• وقت استجابة الإخراج الفاصل الزمني بين كتابة تطبيق لإطار بيانات مرمز بتعديل ترميز النبض (PCM) وعرض الصوت المقابل في البيئة باستخدام محوّل طاقة على الجهاز أو مغادرة الإشارة للجهاز عبر منفذ وإمكانية ملاحظتها خارجيًا
• وقت استجابة الناتج البارد وقت استجابة الإطار الأول عند إخراج الصوت، عندما يكون نظام إخراج الصوت في وضع الخمول وتم إيقاف تشغيله قبل الطلب
• وقت استجابة الناتج المتواصل وقت الاستجابة للإخراج في اللقطات اللاحقة، بعد أن يبدأ الجهاز في تشغيل الصوت
• وقت استجابة الإدخال الفاصل الزمني بين الوقت الذي يعرض فيه الجهاز صوتًا من البيئة باستخدام محوّل طاقة أو إشارة تدخل الجهاز عبر منفذ، والوقت الذي يقرأ فيه التطبيق إطار البيانات المقابل المرمّز بتنسيق PCM.
• فقدان البيانات الجزء الأولي من إشارة الإدخال الذي لا يمكن استخدامه أو غير متوفّر.
• وقت استجابة الإدخال البارد مجموع وقت فقدان البيانات ووقت استجابة البيانات للإطار الأول، عندما يكون نظام إدخال الصوت غير نشط ومتوقفًا عن العمل قبل الطلب
• وقت استجابة الإدخال المتواصل وقت استجابة الإدخال للأُطر اللاحقة أثناء تسجيل الجهاز للصوت
• التفاوت في وقت الاستجابة عند بدء التشغيل التفاوت بين القياسات المنفصلة لقيم وقت الاستجابة الباردة.
• التشوّش الناتج عن الإدخال البارد مدى التفاوت بين القياسات المنفصلة لقيم وقت استجابة الإدخال البارد
• وقت الاستجابة المتواصل لرحلة الذهاب والعودة مجموع وقت استجابة الإدخال المتواصل ووقت استجابة الإخراج المتواصل بالإضافة إلى فترة تخزين مؤقت واحدة تتيح فترة التخزين المؤقت وقتًا للتطبيق لمعالجة الإشارة ووقتًا للتطبيق للحدّ من فرق الطور بين تدفقات الإدخال والإخراج.
• واجهة برمجة التطبيقات OpenSL ES PCM buffer queue مجموعة واجهات برمجة التطبيقات ذات الصلة بـ PCM في OpenSL ES ضمن Android NDK
• واجهة برمجة التطبيقات الأصلية للصوت AAudio مجموعة واجهات برمجة التطبيقات AAudio ضمن Android NDK
• الطابع الزمني زوج يتألف من موضع إطار نسبي ضمن بث والوقت المقدَّر الذي يدخل فيه هذا الإطار إلى مسار معالجة الصوت أو يخرج منه على نقطة النهاية المرتبطة. راجِع أيضًا 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() أقل من أو تساوي القيمة التي تعرضها android.media.AudioManager.getProperty(String) لمفتاح السمة AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

إذا لم تستوفِ عمليات تنفيذ الأجهزة متطلبات الصوت المنخفض الكمون من خلال كلّ من قائمة انتظار مخزن OpenSL ES PCM وواجهات برمجة تطبيقات الصوت الأصلية 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 وأشكاله المختلفة.
ترميز 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 Live Streaming للحصول على التفاصيل.

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

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

• [C-1-1] يجب الإعلان عن توفير الدعم لـ Display.FLAG_SECURE.

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

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

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

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

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

إذا كانت عمليات تنفيذ الأجهزة تشير إلى إتاحة الميزة 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] يُنصح بشدة بتوفير مستوى ثابت من أداء وحدة المعالجة المركزية أثناء تشغيل الصوت وتفاوت حمل وحدة المعالجة المركزية. يجب اختبار ذلك باستخدام عملية الإيداع SimpleSynth 1bd6391. يجب تشغيل تطبيق SimpleSynth مع المَعلمات أدناه وتحقيق صفر من حالات نقص البيانات بعد 10 دقائق:
  • دورات العمل: 200,000
  • Variable load: ON (سيتم التبديل بين% 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] يجب أن يتيح إخراج الصوت في قناتَين و8 قنوات بعمق 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 هرتز يتم تشغيله عند مستوى ضغط صوت يبلغ 94 ديسيبل إلى استجابة بقيمة متوسط الجذر التربيعي تبلغ 520 لعينات 16 بت (أو -36 ديسيبل من المقياس الكامل لعينات النقطة العائمة/الدقة المزدوجة) لكل ميكروفون مستخدَم لتسجيل مصدر الصوت غير المعالج.

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

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

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

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

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

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

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

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

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

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

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

• أداة تصحيح أخطاء Android (adb)

  • ‫[C-0-2] يجب أن تتوافق مع أداة تصحيح الأخطاء عبر ADB كما هو موضّح في حزمة تطوير البرامج (SDK) لنظام التشغيل Android وأوامر shell المتوفّرة في مشروع Android مفتوح المصدر (AOSP)، والتي يمكن أن يستخدمها مطوّرو التطبيقات، بما في ذلك dumpsys وcmd stats.
  • [C-0-3] يجب عدم تغيير تنسيق أو محتوى أحداث نظام الجهاز (batterystats وdiskstats وfingerprint وgraphicsstats وnetstats وnotification وprocstats) التي يتم تسجيلها من خلال الأمر dumpsys.
  • [C-0-10] يجب تسجيل الأحداث التالية بدون حذفها وإتاحتها وإمكانية الوصول إليها من خلال أمر الصدفة cmd stats وفئة واجهة برمجة التطبيقات StatsManager.
    • 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] يجب توفير آلية تتيح ربط أداة تصحيح الأخطاء في Android (adb) من جهاز مضيف. مثلاً:

    • يجب أن تتضمّن عمليات تنفيذ الأجهزة التي لا تحتوي على منفذ USB متوافق مع وضع الأجهزة الطرفية أداة تصحيح أخطاء Android عبر الشبكة المحلية (مثل Ethernet أو Wi-Fi).
    • يجب توفير برامج تشغيل لنظام التشغيل Windows 7 و9 و10، ما يتيح للمطوّرين الاتصال بالجهاز باستخدام بروتوكول adb.

• خدمة مراقبة تصحيح الأخطاء في Dalvik (ddms)

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

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

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

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

يتضمّن Android إمكانية ضبط الإعدادات المتعلّقة بتطوير التطبيقات.

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

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

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

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

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

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

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

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

‫7.1. العرض والرسومات

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

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

• الحجم القُطري الفعلي المسافة بالبوصة بين زاويتين متقابلتين من الجزء المضاء من الشاشة
• نقاط لكل بوصة (dpi) عدد وحدات البكسل التي يشملها مدى أفقي أو عمودي خطي يبلغ بوصة واحدة. وعند إدراج قيم النقاط لكل بوصة، يجب أن تندرج النقاط الأفقية والعمودية لكل بوصة ضمن النطاق.
• نسبة العرض إلى الارتفاع. نسبة وحدات البكسل في البُعد الأطول إلى البُعد الأقصر للشاشة على سبيل المثال، إذا كانت الشاشة تعرض 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 وحدة بكسل مستقلة الكثافة × 320 وحدة بكسل مستقلة الكثافة.
  • يجب أن يكون حجم normal الذي يتم الإبلاغ عنه في Configuration.screenLayout 480 وحدة بكسل مستقلة عن الكثافة × 320 وحدة بكسل مستقلة عن الكثافة على الأقل.
  • يجب أن يكون حجم Configuration.screenLayout الذي تعرضه الأجهزة large على الأقل 640 وحدة بكسل مستقلة عن الكثافة × 480 وحدة بكسل مستقلة عن الكثافة.
  • يجب أن تتضمّن الأجهزة التي تعرض حجم 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، المتطلبات التالية:

• [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 نقطة لكل بوصة (hdpi)
  • ‫260 نقطة لكل بوصة (260 نقطة لكل بوصة)
  • 280 نقطة لكل بوصة (280dpi)
  • 300 نقطة لكل بوصة (300 نقطة لكل بوصة)
  • 320 نقطة لكل بوصة (xhdpi)
  • ‫340 نقطة في البوصة (340 نقطة في البوصة)
  • 360 نقطة في البوصة (360 نقطة في البوصة)
  • 400 نقطة في البوصة (400dpi)
  • 420 نقطة لكل بوصة (420dpi)
  • 480 نقطة لكل بوصة (xxhdpi)
  • 560 نقطة في البوصة (560dpi)
  • 640 نقطة لكل بوصة (xxxhdpi)

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

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

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

7.1.2. مقاييس الإعلانات الصورية

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

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

‫7.1.4.3 RenderScript

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

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

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

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

• [C-0-1] يجب تفعيل ميزة "تسريع الأجهزة" تلقائيًا، ويجب إيقافها إذا طلب المطوّر ذلك من خلال ضبط android:hardwareAccelerated="false” أو إيقافها مباشرةً من خلال واجهات برمجة التطبيقات Android View.
• [C-0-2] يجب أن يظهر سلوك متوافق مع مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android بشأن تسريع الأجهزة.

يتضمّن Android عنصر TextureView يتيح للمطوّرين دمج مواد عرض OpenGL ES التي يتم تسريعها باستخدام الأجهزة مباشرةً كأهداف عرض في تسلسل هرمي لواجهة المستخدم.

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

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

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

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

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

إذا كانت عمليات تنفيذ الأجهزة توفّر وظيفة "المساعد"، عليها استيفاء ما يلي: * [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. Fake Touch Input

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

‫7.2.6. التوافق مع وحدات التحكّم في الألعاب

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

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

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

زرّ	استخدام HID2	زر Android
A1	0x09 0x0001	KEYCODE_BUTTON_A (96)
B1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X1	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y1	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 المذكورة أعلاه ضمن CA لوحة ألعاب (0x01 0x0005).

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

‫4 MotionEvent

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

‫1 MotionEvent

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

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

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

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

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

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

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

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

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

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

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

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

• [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 متر/ثانية^2 أو أقل، ويجب احتساب الانحراف المعياري لكل محور على أساس العيّنات التي تم جمعها على مدار 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.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس تسارع ثلاثي المحاور وتم تنفيذ أيّ من أجهزة الاستشعار المركّبة 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 µT و‎+900 µT على كل محور قبل التشبع.
• [C-1-5] يجب أن تكون قيمة إزاحة الحديد الصلب أقل من 700 ميكرو تسلا، ويجب أن تكون القيمة أقل من 200 ميكرو تسلا، وذلك عن طريق وضع مقياس المغناطيسية بعيدًا عن المجالات المغناطيسية الديناميكية (الناتجة عن التيار) والثابتة (الناتجة عن المغناطيس).
• ‫[C-1-6] يجب أن تكون درجة الدقة مساوية لـ 0.6 ميكرو تسلا أو أعلى.
• [C-1-7] يجب أن يتيح المعايرة والتعويض على الإنترنت عن انحياز الحديد الصلب، وأن يحتفظ بمَعلمات التعويض بين عمليات إعادة تشغيل الجهاز.
• [C-1-8] يجب تطبيق تعويض الحديد اللين، ويمكن إجراء عملية المعايرة أثناء الاستخدام أو أثناء إنتاج الجهاز.
• [C-1-9] يجب أن يكون الانحراف المعياري محسوبًا على أساس كل محور من العيّنات التي تم جمعها على مدار 3 ثوانٍ على الأقل بأسرع معدّل لأخذ العيّنات، وألا يزيد عن 1.5 ميكرو تسلا، ويجب ألا يزيد الانحراف المعياري عن 0.5 ميكرو تسلا.
• يجب تنفيذ أداة الاستشعار 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] يجب أن يتيح إخراج بيانات الموقع الجغرافي بمعدّل مرّة واحدة على الأقل في الثانية عند طلب ذلك من خلال 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
  • [طلب خدمة] الإبلاغ عن 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 متر في الثانية، وذلك في ظروف السماء المفتوحة بعد تحديد الموقع الجغرافي، وأثناء الثبات أو الحركة بمعدل تسارع أقل من 0.2 متر في الثانية المربعة، وذلك بنسبة% 95 على الأقل من الوقت.

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

‫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] يُنصح بشدة بتوفير إمكانية تسجيل قياسات الضغط في النطاق من 300 هكتوباسكال إلى 1100 هكتوباسكال.
• يجب أن تبلغ الدقة المطلقة 1 هكتوباسكال.
• يجب أن تبلغ الدقة النسبية 0.12 هكتوباسكال على مدى 20 هكتوباسكال (أي ما يعادل دقة تبلغ مترًا واحدًا على مدى تغيير يبلغ 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 نهائيًا في الإصدار 4.0 من نظام التشغيل Android.

7.3.7. مقياس الضوء

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

‫7.3.8. أداة استشعار التقارب

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

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

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

‫7.3.9. أجهزة استشعار عالية الدقة

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

• [C-1-1] يجب تحديد الإمكانية من خلال علامة الميزة android.hardware.sensor.hifi_sensors.

في حال إعلان عمليات تنفيذ الأجهزة عن android.hardware.sensor.hifi_sensors، يجب أن:

• [C-2-1] يجب أن يحتوي على أداة استشعار TYPE_ACCELEROMETER التي:

  • يجب أن يتضمّن نطاق قياس بين ‎-8g و‎+8g على الأقل، ويُفضّل أن يتضمّن نطاق قياس بين ‎-16g و‎+16g على الأقل.
  • يجب أن تبلغ درجة دقة القياس 2048 LSB/g على الأقل.
  • يجب أن يكون الحدّ الأدنى لتردّد القياس 12.5 هرتز أو أقل.
  • يجب أن يكون الحد الأقصى لوتيرة القياس 400 هرتز أو أكثر، ويجب أن يتيح استخدام SensorDirectChannel RATE_VERY_FAST.
  • يجب ألا يتجاوز تشويش القياس 400 ميكروغرام/√هرتز.
  • يجب تنفيذ شكل غير نشط من أداة الاستشعار هذه مع إمكانية التخزين المؤقت لما لا يقل عن 3000 حدث من أحداث أداة الاستشعار.
  • يجب ألا يزيد استهلاك الطاقة في عملية تجميع البيانات عن 3 ملي واط.
  • [C-SR] يُنصح بشدة بأن يكون عرض نطاق قياس نسبة الإشارة إلى الضوضاء (SNR) يبلغ% 80 على الأقل من تردد Nyquist، وأن يكون طيف الضوضاء البيضاء ضمن عرض النطاق هذا.
  • يجب أن يكون معدّل التغيّر العشوائي في التسارع أقل من 30 ميكروغرام √هرتز عند اختباره في درجة حرارة الغرفة.
  • يجب أن يكون التغيير في الانحياز مقابل درجة الحرارة ≤ ‎+/- 1 mg/°C.
  • يجب أن يكون الانحراف عن الخط المستقيم لأفضل خط مطابق ≤ 0.5%، وتغيُّر الحساسية مقابل درجة الحرارة ≤ 0.03%/درجة مئوية.
  • يجب أن تبلغ حساسية المحور المتقاطع أقل من % 2.5 وأن يكون تباين حساسية المحور المتقاطع أقل من% 0.2 في نطاق درجة حرارة تشغيل الجهاز.

• [C-2-2] يجب أن تتضمّن TYPE_ACCELEROMETER_UNCALIBRATED تستوفي متطلبات الجودة نفسها التي تستوفيها TYPE_ACCELEROMETER.

• [C-2-3] يجب أن يحتوي على أداة استشعار TYPE_GYROSCOPE التي:

  • يجب أن يتضمّن نطاق قياس بين 1000- و1000+ وحدة في الثانية على الأقل.
  • يجب أن تبلغ دقة القياس 16 LSB/dps على الأقل.
  • يجب أن يكون الحدّ الأدنى لتردّد القياس 12.5 هرتز أو أقل.
  • يجب أن يكون الحد الأقصى لتردد القياس 400 هرتز أو أعلى، ويجب أن يتوافق مع SensorDirectChannel RATE_VERY_FAST.
  • يجب ألا يتجاوز التشويش في القياس 0.014 درجة/ثانية/√هرتز.
  • [C-SR] يُنصح بشدة بأن يكون عرض نطاق قياس نسبة الإشارة إلى الضوضاء (SNR) يبلغ% 80 على الأقل من تردد Nyquist، وأن يكون طيف الضوضاء البيضاء ضمن عرض النطاق هذا.
  • يجب أن يكون معدّل التغيّر العشوائي أقل من 0.001 درجة/ثانية √هرتز عند اختباره في درجة حرارة الغرفة.
  • يجب أن يكون التغيير في الانحياز مقارنةً بدرجة الحرارة ≤ ‎+/- 0.05 °/ s / °C.
  • يجب أن يكون معدّل تغيُّر الحساسية مقارنةً بدرجة الحرارة ≤ 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+ ميكرو تسلا على الأقل.
  • يجب أن تبلغ دقة القياس 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 هكتوباسكال على الأقل.
  • يجب أن تبلغ دقة القياس 80 LSB/hPa على الأقل.
  • يجب أن يكون الحدّ الأدنى لتردّد القياس 1 هرتز أو أقل.
  • يجب أن يكون الحد الأقصى لعدد مرات القياس 10 هرتز أو أكثر.
  • يجب أن يكون مستوى التشويش في القياس أقل من 2 Pa/√Hz.
  • يجب تنفيذ شكل غير مفعِّل لهذا المستشعر مع إمكانية التخزين المؤقت لما لا يقل عن 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] يجب أن تتضمّن الطوابع الزمنية لأحداث مستشعر الجيروسكوب قاعدة الوقت نفسها التي يستخدمها النظام الفرعي للكاميرا، وأن يكون الخطأ في حدود 1 ملي ثانية.
• [C-2-15] يجب أن يتم تسليم العيّنات إلى التطبيقات في غضون 5 ملي ثانية من وقت توفّر البيانات على أيّ من أجهزة الاستشعار المادية المذكورة أعلاه للتطبيق.
• [C-2-16] يجب ألا يزيد استهلاك الطاقة عن 0.5 ملي واط عندما يكون الجهاز ثابتًا و2.0 ملي واط عندما يكون الجهاز متحركًا عند تفعيل أي مجموعة من أجهزة الاستشعار التالية:
  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS
• [C-2-17] قد يتضمّن جهاز الاستشعار TYPE_PROXIMITY، ولكن في حال توفّره، يجب أن تتوفّر فيه سعة تخزين مؤقت لا تقل عن 100 حدث من أحداث جهاز الاستشعار.

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

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

• [C-3-1] يجب الإفصاح بشكل صحيح عن إمكانية استخدام أنواع القنوات المباشرة ومعدّلات التقارير المباشرة من خلال واجهتَي برمجة التطبيقات isDirectChannelTypeSupported وgetHighestDirectReportRateLevel.
• ‫[C-3-2] يجب أن يتوافق مع نوع واحد على الأقل من نوعَي القنوات المباشرة لأجهزة الاستشعار لجميع أجهزة الاستشعار التي تعلن عن توافقها مع القناة المباشرة لأجهزة الاستشعار.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• يجب أن يتيح إعداد تقارير الأحداث من خلال القناة المباشرة لأداة الاستشعار لأداة الاستشعار الأساسية (النوع غير المفعِّل) من الأنواع التالية:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

‫7.3.10. أجهزة استشعار المقاييس الحيوية

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

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

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

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

• يجب أن تتضمّن دعم إعداد رابط مباشر عبر شبكة Wi-Fi (TDLS) على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

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

• ‫[C-1-1] يجب الإعلان عن إتاحة بروتوكول TDLS من خلال WifiManager.isTdlsSupported.
• يجب استخدام TDLS فقط عندما يكون ذلك ممكنًا ومفيدًا.
• يجب أن يتضمّن بعض الإرشادات ولا يستخدم TDLS عندما يكون أداؤه أسوأ من المرور عبر نقطة وصول Wi-Fi.

7.4.2.3. Wi-Fi Aware

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

• يجب أن يتضمّن دعمًا لمعيار Wi-Fi Aware.

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

• [C-1-1] يجب تنفيذ واجهات برمجة التطبيقات WifiAwareManager على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK).
• [C-1-2] يجب الإعلان عن علامة الميزة android.hardware.wifi.aware.
• [C-1-3] يجب أن تتوافق مع عمليات Wi-Fi وWi-Fi Aware في الوقت نفسه.
• [C-1-4] يجب أن يتم اختيار عنوان واجهة إدارة Wi-Fi Aware بشكل عشوائي على فترات لا تزيد عن 30 دقيقة وكلما تم تفعيل Wi-Fi Aware.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة استخدام Wi-Fi Aware وخدمة "الموقع الجغرافي عبر 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] يجب تنفيذ واجهات برمجة التطبيقات ذات الصلة بـ Passpoint WifiManager على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK).
• ‫[C-1-2] يجب أن يتوافق مع معيار IEEE 802.11u، وتحديدًا ما يتعلّق باكتشاف الشبكة واختيارها، مثل خدمة الإعلانات الشاملة (GAS) وبروتوكول طلب شبكة الوصول (ANQP).

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

• [C-2-1] يجب أن يؤدي تنفيذ واجهات برمجة التطبيقات ذات الصلة بمعيار Passpoint 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. البلوتوث

في حال توفّر ملف Bluetooth Audio على الأجهزة، يجب أن تتوفّر فيها ما يلي:

• يجب أن تتوافق مع برامج ترميز الصوت المتقدّمة وبرامج ترميز صوت البلوتوث (مثل LDAC).

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

• يجب أن يتيح ربط 5 أجهزة إجمالاً على الأقل.

إذا كانت عمليات تنفيذ الأجهزة تعرّف الميزة android.hardware.vr.high_performance، عليها استيفاء ما يلي:

• ‫[C-1-1] يجب أن يتوافق مع الإصدار 4.2 من البلوتوث وإضافة "تمديد طول بيانات البلوتوث المنخفض الطاقة".

يتضمّن 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] يُنصح بشدة بتنفيذ مهلة لعنوان خاص قابل للحل (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 (على النحو المحدّد في المواصفات الفنية NFCForum-TS-DigitalProtocol-1.0 الصادرة عن NFC Forum) من خلال معايير NFC التالية:
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • أنواع علامات NFC Forum‏ 1 و2 و3 و4 و5 (محدّدة من قِبل NFC Forum)

• [SR] يُنصح بشدة أن يكون الجهاز قادرًا على قراءة رسائل NDEF وكتابتها بالإضافة إلى البيانات الأولية من خلال معايير NFC التالية. يُرجى العِلم أنّه على الرغم من أنّ معايير NFC مُحدّدة على أنّها يُنصَح بها بشدة، من المخطّط أن يتم تغييرها إلى "يجب" في تعريف التوافق لإصدار مستقبلي. هذه المعايير اختيارية في هذا الإصدار، ولكن سيتم فرضها في الإصدارات المستقبلية. ننصح بشدة الأجهزة الحالية والجديدة التي تعمل بهذا الإصدار من Android باستيفاء هذه المتطلبات الآن حتى تتمكّن من الترقية إلى إصدارات النظام الأساسي المستقبلية.

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

  • ISO 18092
  • LLCP 1.2 (محدّد من قِبل منتدى NFC)
  • SDP 1.0 (المحدّد من قِبل منتدى NFC)
  • بروتوكول إرسال بيانات NDEF
  • SNEP 1.0 (محدّد من قِبل منتدى NFC)
• [C-1-4] يجب أن يتضمّن الجهاز إمكانية استخدام Android Beam ويجب تفعيلها تلقائيًا.
• [C-1-5] يجب أن يكون الجهاز قادرًا على الإرسال والاستلام باستخدام Android Beam، وذلك عند تفعيل Android Beam أو تفعيل وضع آخر خاص من أوضاع NFC P2p.
• [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 الصادرة من خلال P2P باستخدام 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، وذلك من خلال تنفيذ مواصفات Connection Handover الإصدار 1.2 وBluetooth Secure Simple Pairing Using NFC الإصدار 1.0 من "منتدى NFC". يجب أن تنفّذ هذه الطريقة خدمة LLCP لنقل البيانات مع اسم الخدمة "urn:nfc:sn:handover" لتبادل سجلّات طلب/اختيار نقل البيانات عبر NFC، ويجب أن تستخدم "ملف تعريف نقل البيانات عبر البلوتوث" لنقل البيانات عبر البلوتوث. لأسباب قديمة (للحفاظ على التوافق مع أجهزة Android 4.1)، يجب أن يظل التنفيذ يقبل طلبات SNEP GET لتبادل طلب التسليم/اختيار السجلات عبر NFC. ومع ذلك، يجب ألا يرسل التنفيذ نفسه طلبات SNEP GET لإجراء عملية تسليم الاتصال.
• [C-1-13] يجب إجراء عملية بحث عن جميع التقنيات المتوافقة أثناء تفعيل وضع رصد أجهزة NFC.
• يجب أن يكون في وضع رصد تقنية NFC أثناء تنشيط الجهاز مع تفعيل الشاشة وفتح قفل شاشة القفل.
• يجب أن يكون قادرًا على قراءة الرمز الشريطي وعنوان URL (في حال ترميزه) لمنتجات Thinfilm NFC Barcode.

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

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

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

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

• يجب أن يتيح تشغيل IPv6 (IPv6 فقط وربما ثنائي الحزمة) على شبكة الجوّال.

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

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

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

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

• [C-0-1] يجب أن يكون إعداد المزامنة التلقائية الرئيسي مفعَّلاً تلقائيًا حتى تعرض الطريقة getMasterSyncAutomatically() القيمة "true".

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

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

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

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

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

إذا كانت الكاميرا تتضمّن فلاشًا:

• [C-2-1] يجب ألا يضيء مصباح الفلاش أثناء تسجيل مثيل android.hardware.Camera.PreviewCallback على مساحة معاينة الكاميرا، ما لم يفعّل التطبيق الفلاش صراحةً من خلال تفعيل السمتَين FLASH_MODE_AUTO أو FLASH_MODE_ON لكائن Camera.Parameters. يُرجى العِلم أنّ هذا القيد لا ينطبق على تطبيق كاميرا النظام المضمّن في الجهاز، ولكنّه ينطبق فقط على التطبيقات التابعة لجهات خارجية التي تستخدم Camera.PreviewCallback.

7.5.2. الكاميرا الأمامية

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

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

• قد يتضمّن كاميرا أمامية.

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

• [C-1-1] يجب الإبلاغ عن علامة الميزة android.hardware.camera.any وandroid.hardware.camera.front.
• [C-1-2] يجب أن تكون درجة الدقة VGA (640x480 بكسل) على الأقل.
• [C-1-3] يجب عدم استخدام كاميرا أمامية كإعداد تلقائي لواجهة برمجة التطبيقات 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 (الإصدار 1.0 أو إصدار أحدث) إذا كانت الكاميرا الخارجية تتصل من خلال منفذ USB المضيف.
• [C-1-3] يجب اجتياز اختبارات CTS للكاميرا مع توصيل جهاز كاميرا خارجي. تتوفّر تفاصيل اختبار مجموعة أدوات اختبار التوافق (CTS) للكاميرا على source.android.com.
• يجب أن تتوافق مع عمليات ضغط الفيديو، مثل MJPEG، للسماح بنقل بث عالي الجودة غير مشفّر (أي بث صور أولية أو مضغوطة بشكل مستقل).
• قد يتيح استخدام كاميرات متعددة.
• قد يتيح MAY ترميز الفيديو المستند إلى الكاميرا.

في حال توفّر ترميز الفيديو المستند إلى الكاميرا:

• [C-2-1] يجب أن يكون الجهاز قادرًا على الوصول إلى بث متزامن غير مشفّر / MJPEG (بدقة QVGA أو أعلى).

7.5.4. سلوك Camera API

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

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

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

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

• [C-0-1] يجب استخدام android.hardware.PixelFormat.YCbCr_420_SP لمعاينة البيانات المقدَّمة إلى عمليات ردّ الاتصال في التطبيق عندما لم يسبق للتطبيق طلب android.hardware.Camera.Parameters.setPreviewFormat(int).
• [C-0-2] يجب أن يكون التنسيق NV21 أيضًا عند تسجيل تطبيق مثيلاً من android.hardware.Camera.PreviewCallback واستدعاء النظام للطريقة onPreviewFrame() وتنسيق المعاينة هو YCbCr_420_SP، والبيانات في byte[] التي تم تمريرها إلى onPreviewFrame(). أي أنّ NV21 يجب أن يكون التنسيق التلقائي.
• [C-0-3] يجب أن تتوافق الكاميرات الأمامية والخلفية في android.hardware.Camera مع تنسيق YV12 (كما هو موضّح بالثابت android.graphics.ImageFormat.YV12) لمعاينات الكاميرا. (يمكن أن يستخدم برنامج ترميز الفيديو والكاميرا أي تنسيق بكسل أصلي، ولكن يجب أن يتيح تنفيذ الجهاز إمكانية التحويل إلى YV12).
• [C-0-4] يجب أن تتوافق الأجهزة التي تعلن عن إمكانية REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE في android.request.availableCapabilities مع التنسيقَين android.hardware.ImageFormat.YUV_420_888 وandroid.hardware.ImageFormat.JPEG كناتجَين من خلال واجهة برمجة التطبيقات android.media.ImageReader للأجهزة android.hardware.camera2.
• [C-0-5] يجب أن يظلّ الجهاز ينفّذ واجهة برمجة التطبيقات للكاميرا الكاملة المُضمّنة في مستندات حزمة تطوير البرامج (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 intent كلما التقطت الكاميرا صورة جديدة وتمت إضافة إدخال الصورة إلى "متجر الوسائط".
• [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) أو أن يوضّح على العلبة والمواد الأخرى المتوفّرة عند الشراء أنّه يجب شراء وسيط التخزين بشكل منفصل.

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

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

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB يتيح وضع المضيف وفئة صوت USB، يجب أن:

• [C-2-1] يجب أن يتوافق مع فئة أجهزة واجهة المستخدم البشرية (HID) عبر USB.
• [C-2-2] يجب أن يتيح رصد حقول بيانات HID التالية وتعيينها، كما هو محدّد في جداول استخدام USB HID وطلب استخدام الأوامر الصوتية إلى الثوابت KeyEvent على النحو التالي:
  • صفحة الاستخدام (0xC) معرّف الاستخدام (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • صفحة الاستخدام (0xC) معرّف الاستخدام (0x0E9): KEYCODE_VOLUME_UP
  • صفحة الاستخدام (0xC) معرّف الاستخدام (0x0EA): KEYCODE_VOLUME_DOWN
  • صفحة الاستخدام (0xC) رقم تعريف الاستخدام (0x0CF): KEYCODE_VOICE_ASSIST

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB متوافقًا مع وضع المضيف وStorage Access Framework (SAF)، فإنّها:

• [C-3-1] يجب أن يتعرّف التطبيق على أي أجهزة متصلة عن بُعد باستخدام بروتوكول نقل الوسائط (MTP) وأن يتيح الوصول إلى محتواها من خلال أغراض ACTION_GET_CONTENT وACTION_OPEN_DOCUMENT وACTION_CREATE_DOCUMENT. .

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

• [C-4-1] يجب تنفيذ وظيفة المنفذ المزدوج الدور على النحو المحدّد في مواصفات USB من النوع C (الفقرة 4.5.1.3.3).
• [SR] يُنصح بشدة بتوفير منفذ DisplayPort، ويجب توفير معدّلات نقل البيانات SuperSpeed عبر منفذ USB، ويُنصح بشدة بتوفير ميزة Power Delivery لتبديل أدوار البيانات والطاقة.
• [SR] يُنصح بشدة بعدم توفير "وضع ملحق محوّل الصوت" كما هو موضّح في الملحق (أ) من مواصفات كابل وموصل USB من النوع C، الإصدار 1.2.
• يجب تنفيذ نموذج 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] يُنصح بشدة بأن يتضمّن جهاز البث المباشر(STR) منفذًا واحدًا على الأقل من منافذ الصوت على شكل مقبس صوتي رباعي الموصلات بحجم 3.5 ملم.

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

• ‫[C-1-1] يجب أن يتيح تشغيل الصوت على سماعات رأس ستيريو وسماعات ستيريو مع ميكروفون.
• [C-1-2] يجب أن تتوافق الأجهزة مع مقابس الصوت TRRS بترتيب دبابيس CTIA.
• [C-1-3] يجب أن يتيح الجهاز رصد نطاقات المعاوقة المكافئة الثلاثة التالية بين الميكروفون وموصلات التأريض على قابس الصوت وربطها برموز المفاتيح:
  • ‫70 أوم أو أقل: KEYCODE_HEADSETHOOK
  • من 210 إلى 290 أوم: KEYCODE_VOLUME_UP
  • ‫360-680 أوم: KEYCODE_VOLUME_DOWN
• [C-1-4] يجب أن يتم تشغيل ACTION_HEADSET_PLUG عند إدخال القابس، ولكن فقط بعد أن تلامس جميع نقاط التلامس الموجودة على القابس الأجزاء ذات الصلة في المقبس.
• [C-1-5] يجب أن يكون الجهاز قادرًا على توفير جهد كهربائي خارجي لا يقل عن 150 ملي فولت ±% 10 على مقاومة سماعة تبلغ 32 أوم.
• [C-1-6] يجب أن يتراوح جهد انحياز الميكروفون بين 1.8 فولت و2.9 فولت.
• [C-1-7] يجب رصد نطاق المعاوقة المكافئة التالي بين موصّلي الميكروفون والأرضي على قابس الصوت وربطه برمز المفتاح:
  • من 110 إلى 180 أوم: KEYCODE_VOICE_ASSIST
• [C-SR] يُنصح بشدة بتوفير مقابس صوتية بترتيب دبابيس 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 dBFS.

إذا كانت قيمة PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND هي "true":

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

7.9. الواقع الافتراضي

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

‫7.9.1. وضع الواقع الافتراضي

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

7.9.2. وضع الواقع الافتراضي - أداء عالٍ

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

• [C-1-1] يجب أن يحتوي على نواتَين ماديتَين على الأقل.
• [C-1-2] يجب الإفصاح عن ميزة android.hardware.vr.high_performance.
• ‫[C-1-3] يجب أن يتوافق الجهاز مع وضع الأداء المستدام.
• [C-1-4] يجب أن يتوافق مع OpenGL ES 3.2.
• [C-1-5] يجب أن تتوافق مع android.hardware.vulkan.level 0.
• يجب أن تتوافق مع الإصدار 1 من android.hardware.vulkan.level أو إصدار أحدث.
• [C-1-6] يجب تنفيذ EGL_KHR_mutable_render_buffer وEGL_ANDROID_front_buffer_auto_refresh وEGL_ANDROID_get_native_client_buffer وEGL_KHR_fence_sync وEGL_KHR_wait_sync وEGL_IMG_context_priority وEGL_EXT_protected_content وEGL_EXT_image_gl_colorspace وعرض الإضافات في قائمة إضافات EGL المتاحة.
• [C-1-8] يجب تنفيذ GL_EXT_multisampled_render_to_texture2 وGL_OVR_multiview وGL_OVR_multiview2 وGL_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] يجب أن يتيح دعم AHardwareBuffers مع أي مجموعة من علامات الاستخدام 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 بمعدل 30 لقطة في الثانية - 10 ميغابت في الثانية أو حالتين بدقة 1920 × 1080 بمعدل 60 لقطة في الثانية - 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 هرتز على الأقل أثناء وضع VR.
• ‫[C-1-17] يجب أن تتيح الشاشة وضعًا منخفض الثبات مع ثبات ≤ 5 مللي ثانية، ويتم تعريف الثبات على أنّه مقدار الوقت الذي ينبعث فيه الضوء من البكسل.
• ‫[C-1-18] يجب أن يتوافق مع الإصدار 4.2 من البلوتوث ومعيار "تمديد طول بيانات البلوتوث المنخفض الطاقة" الفقرة 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 لخوارزميات التنشيط والصيانة والتنبيه واستخدام إعدادات النظام العامة لوضعَي "استعداد التطبيق" و"توفير الطاقة" في Doze.
• [C-1-2] يجب عدم الانحراف عن تنفيذ AOSP لاستخدام الإعدادات العامة لإدارة تقييد المهام والتنبيهات والشبكة للتطبيقات في كل مجموعة من مجموعات وضع "التطبيق في وضع الاستعداد".
• [C-1-3] يجب عدم الانحراف عن تنفيذ AOSP لعدد حِزم وضع "التطبيق في وضع الاستعداد" المستخدَمة في وضع "التطبيق في وضع الاستعداد".
• [C-1-4] يجب تنفيذ حِزم وضع "التطبيق في وضع الاستعداد" ووضع "القيلولة" كما هو موضّح في إدارة الطاقة.
• [C-1-5] يجب أن تعرض true القيمة PowerManager.isPowerSaveMode() عندما يكون الجهاز في وضع توفير الطاقة.
• [C-SR] يُنصح بشدة بتوفير إمكانية للمستخدمين لتفعيل ميزة "توفير البطارية" وإيقافها.
• [C-SR] يُنصح بشدة بتوفير إمكانية للمستخدم لعرض جميع التطبيقات المستثناة من وضع "استعداد التطبيق" ووضعَي توفير الطاقة "القيلولة".

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

إذا كانت عمليات تنفيذ الأجهزة تنفّذ حالات الطاقة S4 على النحو المحدّد في ACPI، فإنّها:

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

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

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

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

  على سبيل المثال، بينما تطلب تطبيقات الجهات الخارجية إبقاء الشاشة قيد التشغيل من خلال FLAG_KEEP_SCREEN_ON أو إبقاء وحدة المعالجة المركزية قيد التشغيل من خلال PARTIAL_WAKE_LOCK، يجب ألا يدخل الجهاز في حالة S3 إلا إذا اتّخذ المستخدم إجراءً صريحًا لوضع الجهاز في حالة غير نشطة، كما هو موضّح في C-1-1. في المقابل، عندما يتم تشغيل مهمة تنفّذها تطبيقات تابعة لجهات خارجية من خلال JobScheduler أو يتم إرسال رسالة من "المراسلة عبر السحابة الإلكترونية من Firebase" إلى تطبيقات تابعة لجهات خارجية، يجب أن يخرج الجهاز من حالة S3 ما لم يضعه المستخدم في حالة غير نشطة. هذه ليست أمثلة شاملة، وينفّذ مشروع AOSP إشارات تنبيه شاملة تؤدي إلى التنبيه من هذه الحالة.

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

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

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

• [SR] يُنصح بشدة بتوفير ملف تعريف طاقة لكل مكوّن يحدّد قيمة استهلاك التيار لكل مكوّن من مكوّنات الجهاز ومعدّل استنزاف البطارية التقريبي الذي تسببه المكوّنات بمرور الوقت كما هو موضّح في موقع "مشروع Android المفتوح المصدر".
• [SR] يُنصح بشدة بالإبلاغ عن جميع قيم استهلاك الطاقة بوحدة "ملّي أمبير في الساعة" (mAh).
• [SR] يُنصح بشدة بالإبلاغ عن استهلاك طاقة وحدة المعالجة المركزية لكل معرّف مستخدم (UID) خاص بكل عملية. يستوفي "مشروع 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() API عن أرقام تعريف النوى الحصرية التي يمكن أن يحجزها التطبيق العلوي الذي يعمل في المقدّمة.
• [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] يجب عدم منح أي أذونات تشغيل للتطبيقات المثبَّتة مسبقًا إلا في الحالات التالية:
  • يمكن الحصول على موافقة المستخدم قبل أن يستخدم التطبيق هذه البيانات.
  • ترتبط أذونات وقت التشغيل بنمط intent تم ضبط التطبيق المثبَّت مُسبقًا كمعالج تلقائي له.
• [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] يجب أن يظل هناك نشاط يعالج نمط intent android.settings.ACTION_USAGE_ACCESS_SETTINGS ولكن يجب تنفيذه كعملية لا تفعل شيئًا، أي أن يكون له سلوك مكافئ كما لو تم رفض وصول المستخدم.

‫9.2. المعرّف الفريد وعزل العمليات

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

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

• [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 المفتوح المصدر" (AOSP) إصدارًا يستوفي هذا الشرط.

‫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 المفتوح المصدر".
• [C-0-6] يجب تنفيذ آلية حماية التطبيقات في النواة والتي تسمح بفلترة طلبات النظام باستخدام سياسة قابلة للضبط من البرامج المتعددة مؤشرات الترابط. يستوفي مشروع Android المفتوح المصدر هذا الشرط من خلال تفعيل seccomp-BPF مع مزامنة مجموعة سلاسل العمليات (TSYNC) على النحو الموضّح في قسم "إعدادات النواة" من 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] يجب عدم تنفيذ ذاكرة مساحة المستخدم عند التنفيذ في وضع النواة (مثل PXN للأجهزة أو المحاكي عبر CONFIG_CPU_SW_DOMAIN_PAN أو CONFIG_ARM64_SW_TTBR0_PAN) على الأجهزة التي تم شحنها في الأصل بالمستوى 28 من واجهة برمجة التطبيقات أو أعلى.
• [C-0-11] يجب عدم قراءة أو كتابة ذاكرة مساحة المستخدم في النواة خارج واجهات برمجة التطبيقات العادية للوصول إلى usercopy (مثل PAN للأجهزة أو المحاكي عبر CONFIG_CPU_SW_DOMAIN_PAN أو CONFIG_ARM64_SW_TTBR0_PAN) على الأجهزة التي تم شحنها في الأصل بالمستوى 28 أو مستوى أحدث من واجهة برمجة التطبيقات.
• [C-0-12] يجب تنفيذ ميزة "عزل جداول صفحات النواة" على جميع الأجهزة التي تم شحنها في الأصل مع المستوى 28 من واجهة برمجة التطبيقات أو مستوى أعلى (مثل CONFIG_PAGE_TABLE_ISOLATION أو ‎`CONFIG_UNMAP_KERNEL_AT_EL0`).
• [SR] يُنصح بشدة بإبقاء بيانات النواة التي تتم كتابتها أثناء عملية الإعداد فقط مع وضع علامة للقراءة فقط بعد عملية الإعداد (مثل __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 المتوفّرة، وذلك لكل من نطاقات SELinux في AOSP ونطاقات الأجهزة/المورّدين المحدّدة.
• ‫[C-1-5] يجب تشغيل تطبيقات تابعة لجهات خارجية تستهدف مستوى واجهة برمجة التطبيقات 28 أو أعلى في بيئات الاختبار المعزولة SELinux لكل تطبيق مع فرض قيود SELinux على كل تطبيق على دليل البيانات الخاص بكل تطبيق.
• يجب الاحتفاظ بسياسة SELinux التلقائية المتوفّرة في المجلد system/sepolicy في مشروع Android المفتوح المصدر الأساسي، وإضافة المزيد إلى هذه السياسة فقط لتوفير إعدادات خاصة بالجهاز.

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

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

• [C-0-2] يجب أن يتضمّن فقط الحقول التي تم وضع علامة DEST_AUTOMATIC عليها في تقرير الحدث الذي تم إنشاؤه بواسطة فئة System API IncidentManager.
• [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 مفتوح المصدر.
• [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. تشفير البيانات المخزّنة

إذا كان أداء التشفير وفقًا لمعيار التشفير المتقدّم (AES) الذي يتم قياسه باستخدام تكنولوجيا AES الأكثر فعالية المتوفّرة على الجهاز (مثل "إضافات التشفير" في ARM) أعلى من 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. التشفير على مستوى الملفات

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

• [C-1-1] يجب أن يتم التشغيل بدون مطالبة المستخدم بتقديم بيانات الاعتماد والسماح للتطبيقات المتوافقة مع ميزة "التشغيل المباشر" بالوصول إلى مساحة التخزين المشفرة على الجهاز (DE) بعد بث الرسالة ACTION_LOCKED_BOOT_COMPLETED.
• [C-1-2] يجب ألا يسمح بالوصول إلى مساحة التخزين المشفرة ببيانات الاعتماد (CE) إلا بعد أن يفتح المستخدم قفل الجهاز من خلال تقديم بيانات الاعتماد (مثل رمز المرور أو رقم التعريف الشخصي أو النمط أو بصمة الإصبع) ويتم بث الرسالة ACTION_USER_UNLOCKED.
• [C-1-3] يجب ألا يوفّر أي طريقة لفتح مساحة التخزين المحمية بواسطة CE بدون بيانات الاعتماد التي يقدّمها المستخدم أو مفتاح استرداد مسجّل.
• ‫[C-1-4] يجب أن تتوافق مع ميزة "التشغيل المتحقّق منه" والتأكّد من أنّ مفاتيح تشفير البيانات مرتبطة بشكل مشفَّر بجذر الثقة للأجهزة.
• ‫[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] يجب أن تكون مرتبطة بشكل مشفّر بـ Keystore مستند إلى الأجهزة.

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

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

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

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

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

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

يوفر مشروع Android مفتوح المصدر الأساسي تنفيذًا مفضّلاً لهذه الميزة استنادًا إلى ميزة التشفير 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 مفتوح المصدر الأساسي عملية تنفيذ مفضّلة لهذه الميزة، استنادًا إلى ميزة 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] يجب استخدام مساحة تخزين مقاومة للتلاعب: لتخزين ما إذا كان برنامج Bootloader غير مقفل. تعني مساحة التخزين المقاومة للتلاعب أنّه يمكن لبرنامج التحميل اكتشاف ما إذا تم التلاعب بمساحة التخزين من داخل 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 Keystore في منطقة معزولة بشكل آمن عن الرمز البرمجي الذي يتم تنفيذه على النواة والإصدارات الأحدث. يجب أن تحظر ميزة العزل الآمن جميع الآليات المحتملة التي يمكن من خلالها أن يصل رمز kernel أو رمز مساحة المستخدم إلى الحالة الداخلية للبيئة المعزولة، بما في ذلك الوصول المباشر إلى الذاكرة (DMA). يستوفي "مشروع Android المفتوح المصدر" (AOSP) هذا الشرط باستخدام تنفيذ Trusty، ولكن هناك خيارات بديلة أخرى، مثل حلّ آخر يستند إلى ARM TrustZone أو تنفيذ آمن راجعه طرف ثالث لعزل مناسب يستند إلى برنامج مراقبة الأجهزة الافتراضية.
• [C-1-3] يجب إجراء مصادقة شاشة القفل في بيئة التنفيذ المعزولة، ولا يُسمح باستخدام المفاتيح المرتبطة بالمصادقة إلا عند نجاحها. يجب تخزين بيانات اعتماد شاشة القفل بطريقة تسمح لبيئة التنفيذ المعزولة فقط بإجراء مصادقة شاشة القفل. يوفر مشروع Android مفتوح المصدر طبقة تجريد الأجهزة (HAL) في Gatekeeper و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] يجب ألا تحل طريقة المصادقة الجديدة محل أي من طرق المصادقة الأساسية المقترَحة (أي رقم التعريف الشخصي أو النقش أو كلمة المرور) التي تم تنفيذها وتوفيرها في مشروع Android مفتوح المصدر (AOSP).
• [C-3-4] يجب إيقاف طريقة المصادقة الجديدة عندما يضبط تطبيق "وحدة التحكّم بسياسة الجهاز" (DPC) سياسة جودة كلمة المرور من خلال الطريقة DevicePolicyManager.setPasswordQuality() باستخدام ثابت جودة أكثر تقييدًا من PASSWORD_QUALITY_SOMETHING.

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

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

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

• [C-6-1] يجب أن تتضمّن آلية احتياطية لاستخدام إحدى طرق المصادقة الأساسية المقترَحة المستندة إلى سر معروف، وأن تستوفي المتطلبات التي تؤهّلها لأن تُعتبَر شاشة قفل آمنة.
• [C-6-2] يجب إيقاف الطريقة الجديدة وعدم السماح إلا بإحدى طرق المصادقة الأساسية الموصى بها لإلغاء قفل الشاشة عندما يضبط تطبيق "وحدة التحكّم في سياسات الجهاز" (DPC) السياسة باستخدام الطريقة DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) أو الطريقة DevicePolicyManager.setPasswordQuality() مع ثابت جودة أكثر تقييدًا من PASSWORD_QUALITY_UNSPECIFIED.
• [C-6-3] يجب أن يُطلب من المستخدم إدخال إحدى طرق المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) مرة واحدة على الأقل كل 72 ساعة أو أقل.
• [C-6-4] يجب ألا يتم التعامل مع الطريقة الجديدة على أنّها شاشة قفل آمنة، ويجب أن تلتزم بالقيود الواردة في القسم C-8 أدناه.

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

• [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 أدناه.

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

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

9.11.2. StrongBox

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

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

• [C-SR] يُنصح بشدة بأن تتوافق مع StrongBox.

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

• [C-1-1] يجب الإفصاح عن FEATURE_STRONGBOX_KEYSTORE.

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

• [C-1-3] يجب أن تتضمّن وحدة معالجة مركزية منفصلة لا تشارك أي ذاكرة تخزين مؤقت أو ذاكرة وصول عشوائي ديناميكية (DRAM) أو معالجات مساعدة أو موارد أساسية أخرى مع معالج التطبيقات (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] يُنصح بشدة بتفعيل "وضع التشغيل الآمن".

في حال تنفيذ الأجهزة "وضع التشغيل الآمن"، يجب أن تستوفي ما يلي:

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

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

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

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

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

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

10.2. أداة التحقّق في مجموعة أدوات اختبار التوافق (CTS)

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

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

• [C-0-1] يجب تنفيذ جميع حالات الاختبار السارية في أداة CTS Verifier بشكل صحيح.

يحتوي CTS Verifier على اختبارات للعديد من أنواع الأجهزة، بما في ذلك بعض الأجهزة الاختيارية.

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

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

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

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

11. البرامج القابلة للتحديث

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

  • عمليات التنزيل "عبر شبكة غير سلكية (OTA)" مع تحديث بلا إنترنت من خلال إعادة التشغيل
  • التحديثات "المربوطة" عبر USB من جهاز كمبيوتر مضيف
  • التحديثات "بلا إنترنت" من خلال إعادة التشغيل والتحديث من ملف على وحدة تخزين قابلة للإزالة

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

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

• [C-1-1] يجب أن يتيح تنزيل تحديثات عبر الأثير (OTA) مع إمكانية التحديث بلا إنترنت من خلال إعادة التشغيل.

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

يجب أيضًا أن تتوافق عمليات تنفيذ الأجهزة مع تحديثات نظام التشغيل A/B. ينفّذ AOSP هذه الميزة باستخدام طبقة تجريد الأجهزة (HAL) الخاصة بالتحكّم في عملية التشغيل.

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

• المستندات
  تغييرات متعلقة بالتجميل أو الإنشاء

للحصول على أفضل عرض، أضِف مَعلمتَي عنوان URL pretty=full وno-merges إلى عناوين URL الخاصة بسجلّ التغيير.

13. التواصل معنا

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