تعريف التوافق مع الإصدار 8.1 من نظام Android

1. مقدمة

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

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

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

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

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

2. أنواع الأجهزة

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

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

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

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

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

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

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

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

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

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

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

2.2.1. الأجهزة

حجم الشاشة (الفقرة 7.1.1.1)

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

  • [H-0-1] يجب أن تتضمّن شاشة بحجم 2.5 بوصة على الأقل في القطر المادي.*

كثافة الشاشة (الفقرة 7.1.1.3)

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

  • [H-SR] يُنصح بشدة بتوفير تلميحات مرئية للمستخدمين لتغيير حجم العرض.

وضع توافق التطبيقات القديمة (الفقرة 7.1.5)

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

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

لوحة المفاتيح (الفقرة 7.2.1)

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

  • [H-0-1] يجب أن يتضمّن دعمًا لتطبيقات "محرّر أسلوب الإدخال" (IME) التابعة لجهات خارجية.

مفاتيح التنقل (الفقرة 7.2.3)

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

  • [H-0-1] يجب توفير وظائف "الشاشة الرئيسية" و"النشاطات الأخيرة" و"الرجوع".

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

الإدخال عبر شاشة اللمس (الفقرة 7.2.4)

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

  • ‫[H-0-1] يجب أن يتيح إدخال البيانات من خلال شاشة اللمس.

مقياس التسارع (الفقرة 7.3.1)

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

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

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

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

الجيروسكوب (الفقرة 7.3.4)

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

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

مستشعر الاقتراب (الفقرة 7.3.8)

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

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

مستشعر تحديد الوضع (الفقرة 7.3.12)

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

  • يُنصح باستخدامها مع مستشعر الوضع الذي يتيح 6 درجات من الحرية.

البلوتوث (الفقرة 7.4.3)

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

  • يجب أن تتضمّن دعمًا لتقنيتَي البلوتوث وبلوتوث منخفض الطاقة.

توفير البيانات (الفقرة 7.4.7)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

مساحة التخزين المشتركة للتطبيقات (الفقرة 7.6.2)

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

  • [H-0-1] يجب ألا توفّر مساحة تخزين مشتركة للتطبيق أقل من 1 غيغابايت.

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

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

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

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

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

الميكروفون (الفقرة 7.8.1)

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

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

إخراج الصوت (الفقرة 7.8.2)

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

  • [H-0-1] يجب أن يتضمّن مخرجًا للصوت وأن يعرّف android.hardware.audio.output.

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

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

  • [H-1-1] يجب الإفصاح عن الميزة android.software.vr.mode.*

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

  • [H-2-1] يجب أن يتضمّن تطبيقًا ينفّذ android.service.vr.VrListenerService يمكن تفعيله من خلال تطبيقات الواقع الافتراضي عبر android.app.Activity#setVrModeEnabled.*

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

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

  • [H-1-1] يجب الإفصاح عن علامة الميزة android.hardware.vr.high_performance.*

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

ترميز الصوت (القسم 5.1.1)

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

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

فك ترميز الصوت (الفقرة 5.1.2)

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

  • ‫[H-0-1] AMR-NB
  • [H-0-2] AMR-WB

ترميز الفيديو (الفقرة 5.2)

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

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

فك ترميز الفيديو (الفقرة 5.3)

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

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

2.2.3. برامج

توافق WebView (الفقرة 3.4.1)

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

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

توافُق المتصفّح (الفقرة 3.4.2)

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

  • [H-0-1] يجب أن يتضمّن تطبيق متصفّح مستقل لتصفّح الويب بشكل عام.

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

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

  • [H-SR] يُنصح بشدة بتنفيذ مشغّل تطبيقات تلقائي يتيح تثبيت الاختصارات والتطبيقات المصغّرة داخل التطبيق.

  • [H-SR] يُنصح بشدة بتنفيذ مشغّل تطبيقات تلقائي يوفّر وصولاً سريعًا إلى الاختصارات الإضافية التي توفّرها التطبيقات التابعة لجهات خارجية من خلال واجهة برمجة التطبيقات ShortcutManager.

  • [H-SR] يُنصح بشدة بتضمين تطبيق مشغّل تلقائي يعرض شارات لرموز التطبيقات.

التطبيقات المصغّرة (الفقرة 3.8.2)

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

  • [H-SR] يُنصح بشدة بتوفير الدعم لأدوات التطبيقات الخارجية.

الإشعارات (الفقرة 3.8.3)

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

  • [H-0-1] يجب السماح للتطبيقات التابعة لجهات خارجية بإرسال إشعارات إلى المستخدمين بشأن الأحداث المهمة من خلال فئتَي واجهة برمجة التطبيقات Notification وNotificationManager.
  • ‫[H-0-2] يجب أن تتوافق مع الإشعارات الغنية بصريًا.
  • [H-0-3] يجب أن يتيح عرض الإشعارات المنبثقة.
  • [H-0-4] يجب أن يتضمّن مركز إشعارات يتيح للمستخدم التحكّم مباشرةً في الإشعارات (مثل الردّ أو تأجيل الإشعار أو تجاهله أو حظره) من خلال عناصر تحكّم يوفّرها المستخدم، مثل أزرار الإجراءات أو لوحة التحكّم كما هو موضّح في مشروع Android مفتوح المصدر (AOSP).

البحث (الفقرة 3.8.4)

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

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

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

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

إدارة الأجهزة (الفقرة 3.9)

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

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

تسهيل الاستخدام (الفقرة 3.10)

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

  • [H-SR] يجب أن تتوافق مع خدمات تسهيل الاستخدام التابعة لجهات خارجية.

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

تحويل النص إلى كلام (البند 3.11)

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

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

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

الإعدادات السريعة (الفقرة 3.13)

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

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

إقران الأجهزة المساعدة (الفقرة 3.15)

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

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

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

اتّساق تجربة المستخدم (الفقرة 8.1)

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

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

أداء الوصول إلى ملفات الإدخال والإخراج (الفقرة 8.2)

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

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

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

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

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

محاسبة استهلاك الطاقة (الفقرات 8.4)

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

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

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

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

الأذونات (الفقرة 9.1)

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

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

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

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

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

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

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

‫1.3.2. الأجهزة

التنقل بدون لمس (الفقرة 7.2.2)

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

مفاتيح التنقل (الفقرة 7.2.3)

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

  • [T-0-1] يجب توفير وظيفتَي "الصفحة الرئيسية" و"رجوع".
  • [T-0-2] يجب إرسال كلّ من حدث الضغط العادي والطويل على زر وظيفة "الرجوع" (KEYCODE_BACK) إلى التطبيق الذي يعمل في المقدّمة.

عمليات ربط الأزرار (الفقرة 7.2.6.1)

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

  • [T-0-1] يجب أن تتضمّن دعمًا لوحدات التحكّم بالألعاب والإفصاح عن علامة الميزة android.hardware.gamepad.

التحكّم عن بُعد (الفقرة 7.2.7)

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

الجيروسكوب (الفقرة 7.3.4)

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

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

البلوتوث (الفقرة 7.4.3)

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

  • [T-0-1] يجب أن يتوافق الجهاز مع البلوتوث وBluetooth LE.

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

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

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

الميكروفون (الفقرة 7.8.1)

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

  • يجب أن يتضمّن ميكروفونًا.

إخراج الصوت (الفقرة 7.8.2)

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

  • [T-0-1] يجب أن يتضمّن ميزة إخراج الصوت وأن يوضّح android.hardware.audio.output.

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

ترميز الصوت (القسم 5.1)

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

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

ترميز الفيديو (الفقرة 5.2)

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

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

H-264 (الفقرة 5.2.2)

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

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

فك ترميز الفيديو (الفقرة 5.3)

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

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

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

  • [T-SR] MPEG-2

H.264 (الفقرة 5.3.4)

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

  • [T-1-1] يجب أن يتوافق مع المستوى 4.2 من High Profile وملف تعريف فك الترميز بدقة 1080p عالية الدقة (بمعدل 60 لقطة في الثانية).
  • [T-1-2] يجب أن يكون الجهاز قادرًا على فك ترميز الفيديوهات باستخدام ملفات تعريف الدقة العالية كما هو موضّح في الجدول التالي، وأن تكون هذه الفيديوهات مرمّزة باستخدام ملفات التعريف Baseline أو Main أو High Profile Level 4.2

‫H.265 (HEVC) (الفقرة 5.3.5)

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

  • [T-1-1] يجب أن يتوافق مع المستوى 4.1 من الفئة الرئيسية للملف الشخصي.
  • [T-SR] ننصح بشدة بأن تتيح أجهزة البث المباشر تشغيل الفيديوهات بمعدّل 60 عدد اللقطات في الثانية بدقة 1080p عالية.

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

  • [T-2-1] يجب أن يتوافق برنامج الترميز مع الملف الشخصي "المستوى 5" من "الفئة الرئيسية" في Main10.

‫VP8 (الفقرة 5.3.6)

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

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

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

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

VP9 (الفقرة 5.3.7)

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

  • [T-1-1] يجب أن تتوافق مع عمق الألوان 8 بت ويجب أن تتوافق مع "الملف الشخصي 2" من VP9 (10 بت).

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

  • ‫[T-2-1] يجب أن تتوافق مع 60 لقطة في الثانية لدقة 1080p.

الوسائط الآمنة (الفقرة 5.8)

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

  • [T-1-1] يجب أن تتوافق جميع شاشات العرض الخارجية السلكية مع معيار HDCP 2.2.

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

  • [T-2-1] يجب أن تتوافق الأجهزة مع الإصدار 1.4 من بروتوكول HDCP لجميع شاشات العرض الخارجية السلكية.

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

  • [T-SR] يُنصح بشدة بتوفير إمكانية فك الترميز المتزامن لعمليات البث الآمنة. يُنصح بشدة بتوفير إمكانية فك ترميز بثَّين متزامنين كحدّ أدنى.

مستوى صوت إخراج الصوت (القسم 5.5.3)

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

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

‫2.3.3. برامج

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

التوافق مع WebView (الفقرة 3.4.1)

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

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

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

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

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

النوافذ المتعدّدة (الفقرة 3.8.14)

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

  • [T-SR] يُنصح بشدة بتوفير إمكانية استخدام وضع "نافذة ضمن النافذة" في النوافذ المتعددة.

تسهيل الاستخدام (الفقرة 3.10)

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

  • [T-SR] يجب أن تتوافق مع خدمات تسهيل الاستخدام التابعة لجهات خارجية.

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

تحويل النص إلى كلام (البند 3.11)

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

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

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

إطار عمل إدخال التلفزيون (القسم 3.12)

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

  • [T-0-1] يجب أن يتوافق الجهاز مع TV Input Framework.

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

اتّساق تجربة المستخدم (الفقرة 8.1)

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

  • ‫[T-0-1] وقت استجابة ثابت للإطارات: يجب ألا يحدث تأخير في عرض اللقطات أو عدم اتساق في وقت استجابة اللقطات أكثر من 5 لقطات في الثانية، ويجب أن يكون أقل من لقطة واحدة في الثانية.

أداء الوصول إلى ملفات الإدخال والإخراج (الفقرة 8.2)

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

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

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

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

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

محاسبة استهلاك الطاقة (الفقرات 8.4)

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

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

مقياس التسارع (الفقرة 7.3.1)

طُرق استخدام أجهزة الساعات الذكية:

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

البلوتوث (الفقرة 7.4.3)

طُرق استخدام أجهزة الساعات الذكية:

  • [W-0-1] يجب أن يتوافق مع البلوتوث.

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

طُرق استخدام أجهزة الساعات الذكية:

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

الميكروفون (الفقرة 7.8.1)

طُرق استخدام أجهزة الساعات الذكية:

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

إخراج الصوت (الفقرة 7.8.1)

طُرق استخدام أجهزة الساعات الذكية:

  • يمكن أن يتضمّن مصدر إخراج الصوت ولكن لا يُنصح بذلك.

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

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

‫2.4.3. برامج

طُرق استخدام أجهزة الساعات الذكية:

  • [W-0-1] يجب تعريف الميزة android.hardware.type.watch.
  • [W-0-2] يجب أن تتوافق مع uiMode = UI_MODE_TYPE_WATCH.

البحث (الفقرة 3.8.4)

طُرق استخدام أجهزة الساعات الذكية:

تسهيل الاستخدام (الفقرة 3.10)

الأجهزة التي تتضمّن ميزة android.hardware.audio.output:

  • [W-1-1] يجب أن تتوافق مع خدمات تسهيل الاستخدام التابعة لجهات خارجية.

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

تحويل النص إلى كلام (البند 3.11)

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

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

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

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

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

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

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

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

2.5.1. الأجهزة

حجم الشاشة (الفقرة 7.1.1.1)

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

  • [A-0-1] يجب أن تتضمّن شاشة لا يقل حجمها القطري عن 6 بوصات.
  • [A-0-2] يجب أن يتضمّن تصميمًا لحجم الشاشة لا يقل عن 750 بكسل غير مرتبط بالكثافة × 480 بكسل غير مرتبط بالكثافة.

مفاتيح التنقل (الفقرة 7.2.3)

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

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

مقياس التسارع (الفقرة 7.3.1)

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

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

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

نظام تحديد المواقع العالمي (GPS) (الفقرة 7.3.3)

إذا كانت عمليات تنفيذ أجهزة Automotive تتضمّن جهاز استقبال GPS/GNSS وتُبلغ التطبيقات عن إمكانية استخدامها من خلال علامة الميزة android.hardware.location.gps:

  • [A-1-1] يجب أن يكون جيل تكنولوجيا نظام GNSS هو العام "2017" أو أحدث.

الجيروسكوب (الفقرة 7.3.4)

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

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

أجهزة الاستشعار المتوافقة مع Android Automotive فقط (الفقرة 7.3.11) الترس الحالي (الفقرة 7.3.11.1)

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

  • يجب توفير الترس الحالي على النحو التالي: SENSOR_TYPE_GEAR.

وضع النهار والليل (الفقرة 7.3.11.2)

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

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

حالة القيادة (الفقرة 7.3.11.3)

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

  • [A-0-1] يجب أن تتوافق مع حالة القيادة المحدّدة على أنّها SENSOR_TYPE_DRIVING_STATUS، مع قيمة تلقائية DRIVE_STATUS_UNRESTRICTED عندما تكون المركبة متوقفة بالكامل ومركونة. يتحمّل مصنّعو الأجهزة مسؤولية ضبط SENSOR_TYPE_DRIVING_STATUS بما يتوافق مع جميع القوانين واللوائح التي تنطبق على الأسواق التي يتم شحن المنتج إليها.

سرعة العجلات (الفقرة 7.3.11.4)

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

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

البلوتوث (الفقرة 7.4.3)

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

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

  • [A-0-2] يجب أن تتوافق عمليات تنفيذ Android Automotive مع ملفات تعريف البلوتوث التالية:

    • إجراء مكالمات هاتفية عبر ملف بدون لمس الجهاز (HFP)
    • تشغيل الوسائط عبر نمط توزيع الصوت المتقدّم (A2DP)
    • التحكّم في تشغيل الوسائط من خلال نمط التحكم عن بُعد (AVRCP)
    • مشاركة جهات الاتصال باستخدام ملف الوصول إلى دفتر العناوين (PBAP)
  • يجب أن تتوافق مع ملف الوصول إلى الرسائل (MAP).

الحد الأدنى من إمكانات الشبكة (الفقرة 7.4.5)

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

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

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

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

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

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

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

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

الميكروفون (الفقرة 7.8.1)

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

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

إخراج الصوت (الفقرة 7.8.2)

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

  • [A-0-1] يجب أن يتضمّن ميزة إخراج الصوت وأن يعرّف android.hardware.audio.output.

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

ترميز الصوت (القسم 5.1)

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

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

ترميز الفيديو (الفقرة 5.2)

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

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

فك ترميز الفيديو (الفقرة 5.3)

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

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

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

  • ‫[A-SR] H.265 HEVC

‫2.5.3. برامج

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

  • [A-0-1] يجب تعريف الميزة android.hardware.type.automotive.
  • [A-0-2] يجب أن تتوافق مع uiMode = UI_MODE_TYPE_CAR.
  • [A-0-3] يجب أن تتوافق عمليات تنفيذ Android Automotive مع جميع واجهات برمجة التطبيقات العامة في مساحة الاسم android.car.*.

توافق WebView (الفقرة 3.4.1)

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

  • [A-0-1] يجب توفير تنفيذ كامل لـ android.webkit.Webview API.

الإشعارات (الفقرة 3.8.3)

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

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

البحث (الفقرة 3.8.4)

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

واجهة مستخدم الوسائط (الفقرة 3.14)

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

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

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

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

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

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

محاسبة استهلاك الطاقة (الفقرات 8.4)

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

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

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

إتاحة استخدام حسابات متعددة (الفقرة 9.5)

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

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

عزل أنظمة المركبات (الفقرة 9.14)

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

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

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

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

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

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

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

2.4.1. الأجهزة

حجم الشاشة (الفقرة 7.1.1.1)

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

  • [Ta-0-1] يجب أن تتراوح مقاسات الشاشة بين 7 و18 بوصة.

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

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

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

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

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

3.1.1. إضافات Android

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

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

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

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

3.2.1. الأذونات

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

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

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

  • [C-0-1] لتوفير قيم متسقة وذات مغزى في جميع عمليات تنفيذ الأجهزة، يتضمّن الجدول أدناه قيودًا إضافية على تنسيقات هذه القيم التي يجب أن تتوافق معها عمليات تنفيذ الأجهزة.
المَعلمة التفاصيل
VERSION.RELEASE إصدار نظام Android الذي يتم تنفيذه حاليًا، بتنسيق يمكن للمستخدم قراءته يجب أن يحتوي هذا الحقل على إحدى قيم السلسلة المحدّدة في 8.1.
VERSION.SDK إصدار نظام Android الذي يتم تنفيذه حاليًا، بتنسيق يمكن الوصول إليه من خلال الرمز البرمجي للتطبيق التابع لجهة خارجية. في نظام التشغيل Android 8.1، يجب أن يحتوي هذا الحقل على القيمة الصحيحة 8.1_INT.
VERSION.SDK_INT إصدار نظام Android الذي يتم تنفيذه حاليًا، بتنسيق يمكن الوصول إليه من خلال الرمز البرمجي للتطبيق التابع لجهة خارجية. في نظام التشغيل Android 8.1، يجب أن يحتوي هذا الحقل على القيمة الصحيحة 8.1_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:8.1/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 رقم تسلسلي للأجهزة يجب أن يكون متاحًا وفريدًا على مستوى الأجهزة التي تحمل نفس الطراز والشركة المصنّعة يجب أن تكون قيمة هذا الحقل قابلة للترميز بتنسيق ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي "‎^([a-zA-Z0-9]{6,20})$".
العلامات قائمة قيم مفصولة بفاصلة تتضمّن العلامات التي يختارها مطوّر الجهاز والتي تميّز الإصدار بشكل أكبر. يجب أن يحتوي هذا الحقل على إحدى القيم المقابلة لإعدادات التوقيع الثلاثة النموذجية لنظام Android الأساسي: release-keys وdev-keys وtest-keys.
الوقت قيمة تمثّل الطابع الزمني لوقت حدوث الإنشاء.
النوع قيمة يختارها منفِّذ الجهاز لتحديد إعدادات وقت التشغيل للنسخة. يجب أن يحتوي هذا الحقل على إحدى القيم التي تتوافق مع إعدادات وقت التشغيل الثلاثة النموذجية لنظام التشغيل Android: user أو userdebug أو eng.
المستخدم اسم أو معرّف المستخدم (أو المستخدم الآلي) الذي أنشأ الإصدار لا توجد متطلبات بشأن التنسيق المحدّد لهذا الحقل، باستثناء أنّه يجب ألا تكون قيمته فارغة أو السلسلة الفارغة ("").
حزمة الأمان قيمة تشير إلى مستوى رمز تصحيح الأمان لإصدار معيّن. يجب أن يشير إلى أنّ الإصدار لا يتضمّن أي ثغرات أمنية من أي نوع من المشاكل الموضّحة في "نشرة أمان Android العامة" المحدّدة. يجب أن يكون بالتنسيق [YYYY-MM-DD]، وأن يتطابق مع سلسلة محدّدة موثّقة في نشرة أمان Android العامة أو في إشعار أمان Android، مثل "2015-11-01".
BASE_OS قيمة تمثّل المَعلمة FINGERPRINT للإصدار الذي يكون مطابقًا لهذا الإصدار باستثناء تصحيحات الأمان الواردة في "نشرة أمان Android العلنية". يجب أن تعرض القيمة الصحيحة، وإذا لم يكن هناك إصدار من هذا النوع، يجب أن تعرض سلسلة فارغة ("").
برنامج التحميل قيمة يختارها منفِّذ الجهاز لتحديد إصدار برنامج التحميل الداخلي المحدّد المستخدَم في الجهاز، بتنسيق يمكن للمستخدمين قراءته. يجب أن تكون قيمة هذا الحقل قابلة للترميز بتنسيق ASCII المكوّن من 7 بت وأن تتطابق مع التعبير العادي "‎^[a-zA-Z0-9._-]+$".
getRadioVersion() يجب أن تكون القيمة التي يختارها مطوّر الجهاز هي القيمة التي تحدّد الإصدار الداخلي المحدّد للراديو/المودم المستخدَم في الجهاز، أو أن تعرض هذه القيمة، وذلك بتنسيق يمكن قراءته. إذا لم يكن الجهاز مزوّدًا بأي راديو/مودم داخلي، يجب أن يعرض القيمة NULL. يجب أن تكون قيمة هذا الحقل قابلة للترميز بتنسيق ASCII المكوّن من 7 بت وأن تتطابق مع التعبير العادي “^[a-zA-Z0-9._-,]+$”.

‫3.2.3. توافق النية

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

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

  • [C-0-1] يجب أن تعمل عمليات تنفيذ الأجهزة على التحميل المُسبَق لتطبيق واحد أو أكثر أو لمكوّنات الخدمة مع معالج الأهداف، وذلك لجميع أنماط intent filter العامة المحدّدة من خلال تطبيقات Android الأساسية التالية في مشروع 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 الخاص بالبيانات. على سبيل المثال، يكون نمط intent filter الذي يحدّد معرّف الموارد المنتظم للبيانات "http://www.android.com" أكثر تحديدًا من نمط intent الأساسي للمتصفّح "http://‎".

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

  • [C-0-4] يجب محاولة التحقّق من صحة أي فلاتر أهداف من خلال تنفيذ خطوات التحقّق المحدّدة في مواصفات Digital Asset Links كما تم تنفيذها بواسطة "مدير الحِزم" في "مشروع Android المفتوح المصدر" (AOSP) الأساسي.
  • [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. مساحات أسماء الأهداف
  • [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 لعرض مربّع حوار لتغيير تطبيق SMS التلقائي.

  • [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) في Android NDK.

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

  • [C-0-1] يجب أن يكون متوافقًا مع واجهة واحدة أو أكثر من واجهات التطبيق الثنائية المحدّدة وأن يتيح التوافق مع حزمة تطوير البرامج الأصلية (NDK) لنظام التشغيل Android.
  • [C-0-2] يجب أن يتضمّن دعمًا لتشغيل الرمز البرمجي في البيئة المُدارة من أجل استدعاء الرمز البرمجي الأصلي، وذلك باستخدام دلالات Java Native Interface (JNI) العادية.
  • [C-0-3] يجب أن يكون متوافقًا مع المصدر (أي متوافقًا مع العناوين) ومتوافقًا مع الرمز الثنائي (بالنسبة إلى واجهة التطبيق الثنائية) مع كل مكتبة مطلوبة في القائمة أدناه.
  • [C-0-4] يجب أن تتوافق مع واجهة التطبيق الثنائية (ABI) المكافئة ذات 32 بت في حال توفُّر أي واجهة تطبيق ثنائية ذات 64 بت.
  • [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) في Android NDK، ويجب أن تتضمّن إمكانية استخدام إضافة Advanced SIMD (المعروفة أيضًا باسم NEON).

  • [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 (مكتبة الرياضيات)
    • 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 مفتوح المصدر

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

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

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

  • [C-1-1] على الرغم من أنّ بنية ARMv8 توقِف العديد من عمليات وحدة المعالجة المركزية، بما في ذلك بعض العمليات المستخدَمة في الرموز البرمجية الأصلية الحالية، يجب أن تظل العمليات المتوقّفة التالية متاحة لرموز ARM البرمجية الأصلية ذات 32 بت، إما من خلال دعم وحدة المعالجة المركزية الأصلية أو من خلال محاكاة البرامج:

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

إذا كانت عمليات تنفيذ الأجهزة تتضمّن واجهة ثنائية لتطبيق ARM‏ 32 بت، يجب أن تستوفي ما يلي:

  • [C-2-1] يجب تضمين الأسطر التالية في /proc/cpuinfo عند قراءتها بواسطة تطبيقات ARM ذات 32 بت لضمان التوافق مع التطبيقات التي تم إنشاؤها باستخدام الإصدارات القديمة من Android NDK.

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

  • يجب عدم تغيير /proc/cpuinfo عند قراءته بواسطة تطبيقات 64 بت ARM أو غير ARM.

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

‫1.4.3. توافق WebView

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

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

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

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

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

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

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

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

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

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

  • [C-0-1] يجب ألا تغيّر الأجهزة سلوك أو دلالات هدف عادي.
  • [C-0-2] يجب ألا تغيّر الأجهزة مراحل النشاط أو معاني مراحل النشاط لنوع معيّن من المكوِّنات (مثل الخدمة أو النشاط أو ContentProvider أو غير ذلك).
  • [C-0-3] يجب ألا تغيّر الأجهزة دلالات أحد الأذونات العادية.
  • يجب ألا تغيّر الأجهزة القيود المفروضة على التطبيقات التي تعمل في الخلفية. على وجه التحديد، بالنسبة إلى التطبيقات التي تعمل في الخلفية:
    • [C-0-4] يجب أن تتوقف عن تنفيذ عمليات الرجوع التي يسجّلها التطبيق لتلقّي النتائج من GnssMeasurement وGnssNavigationMessage.
    • [C-0-5] يجب أن يحدّوا من معدّل تكرار التحديثات التي يتم توفيرها للتطبيق من خلال فئة واجهة برمجة التطبيقات LocationManager أو طريقة WifiManager.startScan().
    • [C-0-6] إذا كان التطبيق يستهدف المستوى 25 أو أعلى من واجهة برمجة التطبيقات، يجب ألا يسمح بتسجيل أدوات استقبال البث لعمليات البث الضمنية لغايات Android العادية في بيان التطبيق، ما لم تتطلّب غاية البث إذن "signature" أو "signatureOrSystem" protectionLevel أو كانت مدرَجة في قائمة الإعفاء.
    • [C-0-7] إذا كان التطبيق يستهدف المستوى 25 أو أعلى من واجهة برمجة التطبيقات، يجب إيقاف الخدمات التي تعمل في الخلفية في التطبيق، تمامًا كما لو كان التطبيق قد استدعى طريقة stopSelf() للخدمات، ما لم يتم وضع التطبيق في قائمة مؤقتة بالسماح لتنفيذ مهمة مرئية للمستخدم.
    • [C-0-8] إذا كان التطبيق يستهدف المستوى 25 أو مستوى أحدث لواجهة برمجة التطبيقات، يجب أن يحرر عمليات قفل التنشيط التي يحتفظ بها التطبيق.

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

‫3.6. مساحات أسماء واجهة برمجة التطبيقات

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

  • java.*
  • javax.*
  • sun.*
  • android.*
  • com.android.*

أي أنّها:

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

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

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

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

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

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

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

‫3.7. التوافق مع وقت التشغيل

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [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.
  • قد تتيح عرض تطبيقات مصغّرة على شاشة القفل.

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

‫3.8.3. الإشعارات

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

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

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

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

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

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

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

  • [C-3-1] يجب استخدام عرض الإشعارات المنبثقة ومواردها كما هو موضّح في فئة واجهة برمجة التطبيقات Notification.Builder عند عرض الإشعارات المنبثقة.
‫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. عدم الإزعاج (DND)

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

  • [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، يجب أن يشير إلى المستخدم بأنّه تم إيقاف التأثيرات المرئية في قائمة إعدادات "عدم الإزعاج".

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

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

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

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

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

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

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

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

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

‫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)) يمكنها توفير إحداثيات الموقع الجغرافي:

‫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.

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

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

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

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

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

  • [C-1-1] يجب تعريف android.software.device_admin.
  • [C-1-2] يجب أن يتيح توفير وضع "مالك الجهاز" كما هو موضّح في الفقرة 3.9.1 والفقرة 3.9.1.1.
  • [C-1-3] يجب الإفصاح عن إتاحة استخدام الملفات الشخصية المُدارة من خلال علامة الميزة android.software.managed_users، إلا في حال تم ضبط الجهاز على الإبلاغ عن نفسه كجهاز ذاكرة وصول عشوائي منخفضة أو على تخصيص مساحة تخزين داخلية (غير قابلة للإزالة) كمساحة تخزين مشترَكة.

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

‫3.9.1.1 إدارة مالك الجهاز

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

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

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

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

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

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

  • [C-1-2] يجب أن تتوافق عملية توفير الملف الشخصي المُدار (المسار الذي يبدأه android.app.action.PROVISION_MANAGED_PROFILE) التي يمر بها المستخدمون مع عملية التنفيذ في مشروع 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 Open Source Project (AOSP)) للإشارة إلى وقت استخدام المستخدم لتطبيق ضمن ملف شخصي مُدار.
  • [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.10. تسهيل الاستخدام

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-1-1] يجب الإفصاح عن ميزة النظام الأساسي android.software.live_tv.
  • [C-1-2] يجب أن يتم تحميل تطبيق تلفزيون (تطبيق TV) مسبقًا واستيفاء جميع المتطلبات الموضّحة في الفقرة 3.12.1.

3.12.1. تطبيق البث التلفزيوني

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

  • [C-1-1] يجب أن يوفّر تطبيق التلفزيون إمكانية تثبيت قنوات التلفزيون واستخدامها، وأن يستوفي المتطلبات التالية:

يجب أن يستوفي تطبيق بث تلفزيوني المطلوب لعمليات تنفيذ أجهزة Android التي تحدّد علامة الميزة android.software.live_tv المتطلبات التالية:

  • يجب أن تسمح عمليات تنفيذ الأجهزة بتثبيت وإدارة الإدخالات المستندة إلى إطار عمل إدخال التلفزيون (إدخالات الجهات الخارجية).
  • قد توفّر عمليات تنفيذ الأجهزة فصلاً مرئيًا بين عمليات الإدخال المستندة إلى TIF (عمليات الإدخال المثبَّتة) وعمليات الإدخال التابعة لجهات خارجية.
  • يجب ألا تعرض عمليات تنفيذ الأجهزة المدخلات التابعة لجهات خارجية على بُعد أكثر من إجراء تنقّل واحد من تطبيق التلفزيون (أي توسيع قائمة المدخلات التابعة لجهات خارجية من تطبيق التلفزيون).

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

3.12.1.1. دليل البرامج الإلكتروني

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

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

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

  • [C-1-1] يجب السماح بالتنقّل بين الوظائف التالية باستخدام لوحة التحكّم الاتجاهية وزرَي الرجوع والشاشة الرئيسية على أجهزة إدخال بيانات أجهزة Android Television (مثل جهاز التحكّم عن بُعد أو تطبيق التحكّم عن بُعد أو ذراع التحكّم في الألعاب):

    • تغيير القنوات التلفزيونية
    • فتح دليل البرامج الإلكتروني
    • ضبط الإعدادات وإجراء التعديلات على المدخلات المستندة إلى TIF التابعة لجهات خارجية (إذا كانت هذه المدخلات متوافقة)
    • فتح قائمة الإعدادات

  • يجب تمرير الأحداث الرئيسية إلى مدخلات HDMI من خلال CEC.

‫3.12.1.3. ربط التطبيقات بإدخال التلفزيون

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

3.12.1.4. تغيير الوقت

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

  • [SR] ننصح بشدة بتوفير ميزة "تغيير الوقت" التي تتيح للمستخدم إيقاف المحتوى المباشر مؤقتًا واستئنافه.
  • يجب أن يوفّر للمستخدم طريقة لإيقاف البرنامج الذي يتم تشغيله حاليًا مؤقتًا واستئنافه، إذا كان بإمكان المستخدم تغيير وقت هذا البرنامج.
‫3.12.1.5. تسجيل البرامج التلفزيونية

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

  • [SR] يُنصح بشدة بتوفير إمكانية تسجيل البث التلفزيوني.
  • إذا كان إدخال التلفزيون يتيح التسجيل ولم يكن تسجيل برنامج محظورًا، قد يوفّر دليل البرامج الإلكتروني طريقة لتسجيل برنامج.

‫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.
  • [C-1-5] يجب أن يتم اعتبار النقر مرّتين على KEYCODE_HEADSETHOOK أو KEYCODE_MEDIA_PLAY_PAUSE على أنّه KEYCODE_MEDIA_NEXT في ما يخص MediaSession.Callback#onMediaButtonEvent.

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

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

  • [C-0-1] يجب ألا تُمنح "التطبيقات الفورية" إلا الأذونات التي تم ضبط قيمة android:protectionLevel فيها على "ephemeral".
  • [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] يجب توفير إمكانات للمستخدم تتيح له اختيار/تأكيد توفّر جهاز مصاحب وجاهزيته للتشغيل.

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

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

  • [C-0-1] يجب أن يكون الجهاز قادرًا على تثبيت ملفات Android ‎".apk" وتشغيلها كما تم إنشاؤها باستخدام أداة "aapt" المضمّنة في حزمة تطوير البرامج (SDK) الرسمية لنظام التشغيل Android.
  • بما أنّ الشرط أعلاه قد يكون صعبًا، يُنصح بتنفيذ الأجهزة باستخدام نظام إدارة الحِزم في التنفيذ المرجعي لمشروع AOSP.
  • [C-0-2] يجب أن يتيح التحقّق من ملفات ‎.apk باستخدام الإصدار 2 من مخطّط توقيع حزمة APK وتوقيع JAR.
  • [C-0-3] يجب ألا يتم توسيع نطاق أي من تنسيقات .apk أو بيان Android أو رمز Dalvik البايت أو رمز RenderScript البايت بطريقة تمنع تثبيت هذه الملفات وتشغيلها بشكل صحيح على الأجهزة المتوافقة الأخرى.
  • [C-0-4] يجب ألا تسمح التطبيقات لأي تطبيق آخر غير "برنامج التثبيت التلقائي" الحالي للحزمة بإلغاء تثبيت التطبيق بدون أي طلب، كما هو موضّح في حزمة تطوير البرامج (SDK) للإذن DELETE_PACKAGE. الاستثناءات الوحيدة هي تطبيق التحقّق من حِزم النظام الذي يتعامل مع الغرض PACKAGE_NEEDS_VERIFICATION وتطبيق أداة إدارة مساحة التخزين الذي يتعامل مع الغرض ACTION_MANAGE_STORAGE.

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

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

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

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

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

  • [C-0-1] يجب أن تتوافق MediaCodecList مع تنسيقات الوسائط وبرامج الترميز والتشفير وأنواع الملفات وتنسيقات الحاويات المحدّدة في القسم 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-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

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 كيلو هرتز
AMR-NB من 4.75 إلى 12.2 كيلوبت في الثانية، تم أخذ عينات بمعدل 8 كيلوهرتز 3GPP‏ (‎.3gp)
AMR-WB ‫9 معدّلات تتراوح بين 6.60 كيلوبت/ثانية و23.85 كيلوبت/ثانية بمعدّل أخذ عيّنات يبلغ 16 كيلوهرتز
FLAC أحادي/استيريو (بدون قنوات متعددة) معدّلات البيانات التي تصل إلى 48 كيلو هرتز (ولكن يُنصح باستخدام معدّل بيانات يصل إلى 44.1 كيلو هرتز على الأجهزة التي تتيح إخراج الصوت بمعدّل 44.1 كيلو هرتز، لأنّ أداة خفض معدّل البيانات من 48 إلى 44.1 كيلو هرتز لا تتضمّن فلتر تمرير منخفض). يُنصح باستخدام 16 بت، ولا يتم تطبيق التمويه على 24 بت. ‫FLAC (.flac) فقط
MP3 صوت أحادي/استيريو بمعدل نقل بيانات ثابت أو متغير يتراوح بين 8 و320 كيلوبت في الثانية 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] Raw

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)

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 للحصول على التفاصيل.
VP9 يمكنك الاطّلاع على الفقرة 5.3 للحصول على التفاصيل.

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

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

  • يجب ألا يتجاوز معدّل نقل البيانات، على مدى نافذتَي فترة متداخلتَين، %15 تقريبًا من معدّل نقل البيانات بين الفواصل الزمنية للقطات الكاملة (I-frame).
  • يجب ألا يزيد عن% 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 من الملف الشخصي للمرجع.
  • يجب أن يتيح معدلات نقل بيانات قابلة للضبط بشكل ديناميكي لبرنامج الترميز المتوافق.

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 من Baseline Profile.

‫5.3.3. MPEG-4

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

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

5.3.4. H.264

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

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

إذا كان الارتفاع الذي تعرضه الطريقة 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 لقطة في الثانية (60 لقطة في الثانيةتلفزيون مزوّد ببرنامج ترميز VP9) ‫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 هرتز.
  • يجب تسجيل بث الصوت الخاص بالتعرّف على الصوت مع ضبط حساسية الإدخال على مستوى طاقة صوتية (SPL) يبلغ 90 ديسيبل عند 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 بت
    • معدّلات أخذ العيّنات: 8000 و11025 و16000 و22050 و32000 و44100
    • القنوات: أحادية، استيريو

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

    • معدّلات أخذ العيّنات: 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.
  • يجب أن تتوافق مع عمليات التنفيذ 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 لقائمة انتظار المخزن المؤقت مجموعة واجهات برمجة التطبيقات ذات الصلة بترميز نبضي معدّل (PCM) في OpenSL ES ضمن Android NDK
  • AAudio native audio API مجموعة واجهات برمجة التطبيقات AAudio ضمن حزمة تطوير البرامج (SDK) لنظام التشغيل Android

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

  • ‫[SR] وقت استجابة الإخراج البارد يبلغ 100 ملي ثانية أو أقل
  • ‫[SR] وقت استجابة الإخراج المتواصل يبلغ 45 ملي ثانية أو أقل
  • [SR] Minimize the cold output jitter

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

  • [SR] ننصح بشدة بالإبلاغ عن توفّر ميزة الصوت بزمن استجابة منخفض من خلال تعريف علامة الميزة android.hardware.audio.low_latency.
  • [SR] يُنصح بشدة أيضًا باستيفاء متطلبات الصوت المنخفض الكمون من خلال AAudio API.

إذا لم تستوفِ عمليات تنفيذ الأجهزة متطلبات الصوت بزمن انتقال منخفض من خلال واجهة برمجة التطبيقات OpenSL ES PCM buffer queue API، فإنّها:

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

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

  • [SR] وقت استجابة الإدخال البارد يبلغ 100 ملي ثانية أو أقل
  • ‫[SR] وقت استجابة الإدخال المتواصل يبلغ 30 ملي ثانية أو أقل
  • [SR] وقت استجابة إرسال البيانات واستقبالها بشكل متواصل بمقدار 50 ملي ثانية أو أقل
  • [SR] Minimize the cold input jitter

‫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. Secure Media

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

  • [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، حيث تكون عمليات النقل هذه:

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

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

إذا كانت عمليات تنفيذ الأجهزة تستوفي المتطلبات من خلال واجهة برمجة التطبيقات OpenSL ES PCM buffer queue، فإنّها:

  • [SR] يُنصح بشدة باستيفاء المتطلبات نفسها أيضًا من خلال واجهة برمجة التطبيقات AAudio.

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

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

  • ‫[C-3-1] يجب تنفيذ فئة الصوت عبر USB.
  • [C-3-2] يجب أن يكون وقت استجابة إرسال البيانات واستقبالها المستمر للصوت 20 ملي ثانية أو أقل عبر منفذ وضع مضيف USB باستخدام فئة صوت USB.
  • يجب أن يكون وقت استجابة إرسال البيانات واستقبالها المستمر للصوت 10 ملي ثانية أو أقل عبر منفذ وضع مضيف USB باستخدام فئة صوت USB.

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

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

‫5.11. التقاط الصور التي لم تتم معالجتها

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

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

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

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

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

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

  • [C-1-5] يجب ضبط حساسية إدخال الصوت بحيث يؤدي مصدر نغمي جيبي بتردد 1000 هرتز يتم تشغيله عند مستوى ضغط صوت يبلغ 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 Debug Bridge‏ (adb)

    • [C-0-2] يجب أن تتوافق مع جميع وظائف adb كما هو موضّح في حزمة تطوير البرامج (SDK) لنظام التشغيل Android، بما في ذلك dumpsys.
    • [C-0-3] يجب عدم تغيير تنسيق أو محتوى أحداث نظام الجهاز (batterystats وdiskstats وfingerprint وgraphicsstats وnetstats وnotification وprocstats) التي يتم تسجيلها من خلال dumpsys.
    • [C-0-4] يجب أن يكون برنامج adb الخفي على الجهاز غير نشط تلقائيًا، ويجب أن تتوفّر آلية يمكن للمستخدم الوصول إليها لتفعيل Android Debug Bridge.
    • [C-0-5] يجب أن يتيح الجهاز تصحيح أخطاء adb الآمن. يتضمّن Android إمكانية استخدام adb الآمن. تتيح ميزة "adb الآمن" استخدام أداة adb على الأجهزة المضيفة المعروفة التي تمت مصادقتها.

    • [C-0-6] يجب توفير آلية تسمح بربط أداة تصحيح الأخطاء من Android (adb) بجهاز مضيف. على سبيل المثال:

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

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

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

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

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

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

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

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

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

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

‫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.
    • يستهدف التطبيق المستوى 26 من واجهة برمجة التطبيقات أو المستويات الأحدث ولا يقدّم بيانًا بشأن 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 نقطة لكل بوصة (260dpi)
    • 280 نقطة في البوصة (280dpi)
    • ‫300 نقطة في البوصة (300 نقطة في البوصة)
    • 320 نقطة لكل بوصة (xhdpi)
    • ‫340 نقطة لكل بوصة (340 نقطة لكل بوصة)
    • ‫360 نقطة في البوصة (360dpi)
    • ‫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 التي تم تحديدها على أنّها متوافقة.

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

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

  • [SR] يُنصح بشدة بتضمين إمكانية استخدام الإصدار 1.0 من Vulkan .

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

  • يجب أن يتضمّن دعمًا للإصدار 1.0 من Vulkan.

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

  • [C-1-1] يجب عرض قيمة العدد الصحيح الصحيحة باستخدام علامتَي الميزة android.hardware.vulkan.level وandroid.hardware.vulkan.version.
  • [C-1-2] يجب إدراج VkPhysicalDevice واحدة على الأقل لواجهة برمجة التطبيقات الأصلية vkEnumeratePhysicalDevices() في Vulkan .
  • [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 الأصلية، ويجب عدم الإبلاغ عن سلاسل الإضافات التي لا تتوافق معها بشكل صحيح.

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

  • [C-2-1] يجب عدم الإفصاح عن أي من مفاتيح إيقاف أو تفعيل ميزات Vulkan (مثل android.hardware.vulkan.level وandroid.hardware.vulkan.version).
  • [C-2-2] يجب عدم تعداد أي VkPhysicalDevice لواجهة Vulkan الأصلية vkEnumeratePhysicalDevices().
‫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 شاشات العرض ذات النطاق اللوني الواسع

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

  • [C-1-1] يجب أن تتضمّن شاشة تمت معايرتها من حيث الألوان.
  • [C-1-2] يجب أن يتضمّن الجهاز شاشة تغطي نطاق ألوان sRGB بالكامل في مساحة CIE 1931 xyY.
  • [C-1-3] يجب أن يحتوي على شاشة يكون نطاق ألوانها بمساحة% 90 على الأقل من معيار NTSC 1953 في مساحة CIE 1931 xyY.
  • [C-1-4] يجب أن يتوافق الجهاز مع OpenGL ES 3.0 أو 3.1 أو 3.2 وأن يعرضه بشكل صحيح.
  • [C-1-5] يجب الإعلان عن إمكانية استخدام الإضافات EGL_KHR_no_config_context وEGL_EXT_pixel_format_float وEGL_KHR_gl_colorspace وEGL_EXT_colorspace_scrgb_linear وEGL_GL_colorspace_display_p3.
  • [SR] يُنصح بشدة بتوفير دعم GL_EXT_sRGB.

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

  • [C-2-1] يجب أن تغطّي مساحة الألوان sRGB بنسبة% 100 أو أكثر في مساحة 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. أجهزة إدخال بيانات

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

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

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

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

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

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

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

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

  • [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] MUST report the android.hardware.touchscreen and android.hardware.faketouch feature flags

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

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

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

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

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

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

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

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

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

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

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

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

  • في ظروف السماء المفتوحة بعد تحديد الموقع الجغرافي، سواء كنت ثابتًا أو تتحرّك بتسارع أقل من متر واحد في الثانية المربعة:

    • ‫[C-1-3] يجب أن يكون الجهاز قادرًا على تحديد الموقع الجغرافي في نطاق 20 مترًا، والسرعة في نطاق 0.5 متر في الثانية، وذلك بنسبة% 95 على الأقل من الوقت.
    • [C-1-4] يجب تتبُّع 8 أقمار صناعية على الأقل من مجموعة واحدة وإرسال بياناتها في الوقت نفسه عبر GnssStatus.Callback.
    • يجب أن يكون الجهاز قادرًا على تتبُّع 24 قمرًا صناعيًا على الأقل في الوقت نفسه، من مجموعات متعددة (مثل نظام تحديد المواقع العالمي (GPS) وقمر واحد على الأقل من Glonass أو Beidou أو Galileo).
    • [C-1-5] يجب الإبلاغ عن جيل تكنولوجيا نظام GNSS من خلال واجهة برمجة التطبيقات للاختبار getGnssYearOfHardware.
    • [SR] مواصلة تقديم نواتج الموقع الجغرافي العادية لنظام تحديد المواقع العالمي (GPS) أو نظام الملاحة العالمي عبر الأقمار الصناعية (GNSS) أثناء مكالمة هاتفية للطوارئ
    • [SR] الإبلاغ عن قياسات GNSS من جميع المجموعات التي يتم تتبّعها (كما هو موضّح في رسائل GnssStatus)، باستثناء SBAS
    • [SR] تقرير AGC، وعدد مرات قياس نظام GNSS
    • [SR] يجب إعداد تقارير عن جميع تقديرات الدقة (بما في ذلك الاتجاه والسرعة والارتفاع) كجزء من كل موقع جغرافي لنظام تحديد المواقع العالمي (GPS).
    • [SR] يُنصح بشدة باستيفاء أكبر عدد ممكن من المتطلبات الإضافية الإلزامية للأجهزة التي تُبلغ عن العام "2016" أو "2017" من خلال Test API LocationManager.getGnssYearOfHardware().

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

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

‫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 على الأقل.
    • يجب أن تبلغ دقة القياس 1024 LSB/G على الأقل.
    • يجب أن يكون الحدّ الأدنى لتردّد القياس 12.5 هرتز أو أقل.
    • يجب أن يكون الحد الأقصى لوتيرة القياس 400 هرتز أو أكثر.
    • يجب ألا يتجاوز تشويش القياس 400 uG/√Hz.
    • يجب تنفيذ شكل غير نشط من أداة الاستشعار هذه مع إمكانية التخزين المؤقت لما لا يقل عن 3000 حدث من أحداث أداة الاستشعار.
    • يجب ألا يزيد استهلاك الطاقة في وضع التجميع عن 3 ملي واط.
    • يجب أن يكون ثبات انحياز الضوضاء الثابتة أقل من ‎15 μg √Hz من مجموعة البيانات الثابتة لمدة 24 ساعة.
    • يجب أن يكون هناك تغيُّر في الانحياز مقابل درجة الحرارة بمقدار ≤ +/- 1 ملغ / درجة مئوية.
    • يجب أن يكون الانحراف عن الخط المستقيم لأفضل خط مطابق ≤ 0.5%، وتغيُّر الحساسية مقابل درجة الحرارة ≤ 0.03%/درجة مئوية.
    • يجب أن يتضمّن طيف ضوضاء بيضاء لضمان التأهّل الكافي لسلامة الضوضاء في المستشعر.

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

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

    • يجب أن يتضمّن نطاق قياس بين ‎-1000 و‎+1000 وحدة في الثانية المربعة على الأقل.
    • يجب أن تبلغ دقة القياس 16 LSB/dps على الأقل.
    • يجب أن يكون الحدّ الأدنى لتردّد القياس 12.5 هرتز أو أقل.
    • يجب أن يكون الحد الأقصى لوتيرة القياس 400 هرتز أو أكثر.
    • يجب ألا يتجاوز تشويش القياس 0.014 درجة/ثانية/√هرتز.
    • يجب أن يكون ثبات الانحياز الثابت أقل من 0.0002 درجة/ثانية √هرتز من مجموعة البيانات الثابتة لمدة 24 ساعة.
    • يجب أن يكون التغيير في الانحياز مقارنةً بدرجة الحرارة ≤ ‎+/- 0.05 °/ s / °C.
    • يجب أن يكون معدّل تغيُّر الحساسية مقارنةً بدرجة الحرارة ≤ 0.02% / درجة مئوية.
    • يجب أن يكون الانحراف عن الخطية لأفضل خط مناسب ≤ 0.2%.
    • يجب أن تبلغ كثافة التشويش ≤ 0.007 درجة/ثانية/√هرتز.
    • يجب أن يتضمّن طيف ضوضاء بيضاء لضمان التأهّل الكافي لسلامة الضوضاء في المستشعر.
    • يجب أن يكون خطأ المعايرة أقل من 0.002 راديان/ثانية في نطاق درجة الحرارة من 10 إلى 40 درجة مئوية عندما يكون الجهاز ثابتًا.

  • [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-2-7] يجب أن يتضمّن الجهاز أداة استشعار TYPE_PRESSURE تستوفي الشروط التالية:
    • يجب أن يتراوح نطاق القياس بين 300 و1100 هكتوباسكال على الأقل.
    • يجب أن تبلغ دقة القياس 80 LSB/hPa على الأقل.
    • يجب أن يكون الحدّ الأدنى لتردّد القياس 1 هرتز أو أقل.
    • يجب أن يكون الحد الأقصى لعدد مرات القياس 10 هرتز أو أكثر.
    • يجب أن يكون مستوى الضوضاء في القياس أقل من 2 باسكال لكل جذر هرتز.
    • يجب تنفيذ شكل غير مُفعِّل لهذا المستشعر مع إمكانية التخزين المؤقت لما لا يقل عن 300 حدث من أحداث المستشعر.
    • يجب أن يكون استهلاك الطاقة في وضع التجميع لا يزيد عن 2 ميغاواط.
  • [C-2-8] يجب أن يتضمّن الجهاز أداة استشعار TYPE_GAME_ROTATION_VECTOR تستوفي الشروط التالية:
    • يجب تنفيذ شكل غير مُفعِّل لهذا المستشعر مع إمكانية التخزين المؤقت لما لا يقل عن 300 حدث من أحداث المستشعر.
    • يجب ألا يزيد استهلاك الطاقة في وضع تجميع البيانات عن 4 ملي واط.
  • [C-2-9] يجب أن يتضمّن الجهاز أداة استشعار TYPE_SIGNIFICANT_MOTION تستوفي الشروط التالية:
    • يجب ألا يزيد استهلاك الطاقة عن 0.5 ملي واط عندما يكون الجهاز ثابتًا و1.5 ملي واط عندما يكون الجهاز متحركًا.
  • [C-2-10] يجب أن يتضمّن الجهاز أداة استشعار TYPE_STEP_DETECTOR تستوفي الشروط التالية:
    • يجب تنفيذ شكل غير مُفعِّل لهذا المستشعر مع إمكانية التخزين المؤقت لما لا يقل عن 100 حدث من أحداث المستشعر.
    • يجب ألا يزيد استهلاك الطاقة عن 0.5 ملي واط عندما يكون الجهاز ثابتًا و1.5 ملي واط عندما يكون الجهاز متحركًا.
    • يجب ألا يزيد استهلاك الطاقة في وضع تجميع البيانات عن 4 ملي واط.
  • [C-2-11] يجب أن يتضمّن الجهاز أداة استشعار TYPE_STEP_COUNTER تستوفي الشروط التالية:
    • يجب ألا يزيد استهلاك الطاقة عن 0.5 ملي واط عندما يكون الجهاز ثابتًا و1.5 ملي واط عندما يكون الجهاز متحركًا.
  • [C-2-12] يجب أن يتضمّن الجهاز أداة استشعار TILT_DETECTOR تستوفي الشروط التالية:
    • يجب ألا يزيد استهلاك الطاقة عن 0.5 ملي واط عندما يكون الجهاز ثابتًا و1.5 ملي واط عندما يكون الجهاز متحركًا.
  • ‫[C-2-13] يجب أن يكون الطابع الزمني للحدث الفعلي نفسه الذي يتم تسجيله بواسطة مقياس التسارع ومستشعر الجيروسكوب ومقياس المغناطيسية في نطاق 2.5 ملي ثانية من بعضها البعض.
  • [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. أداة استشعار بصمة الإصبع

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

  • يجب أن يتضمّن مستشعر بصمات الإصبع.

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

  • [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) كما هو موضّح في إرشادات التنفيذ على موقع "مشروع Android المفتوح المصدر".
  • [C-1-8] يجب منع إضافة بصمة إصبع بدون إنشاء سلسلة ثقة أولاً من خلال مطالبة المستخدم بتأكيد بيانات اعتماد الجهاز الحالية أو إضافة بيانات اعتماد جديدة (رقم تعريف شخصي أو نمط أو كلمة مرور) يتم تأمينها بواسطة TEE. يوفّر تطبيق "مشروع Android المفتوح المصدر" الآلية اللازمة في إطار العمل لإجراء ذلك.
  • [C-1-9] يجب عدم السماح للتطبيقات التابعة لجهات خارجية بالتمييز بين بصمات الأصابع الفردية.
  • [C-1-10] يجب الالتزام بالعلامة DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT.
  • [C-1-11] يجب، عند الترقية من إصدار أقدم من Android 6.0، نقل بيانات بصمة الإصبع بشكل آمن لاستيفاء المتطلبات المذكورة أعلاه أو إزالتها.
  • [SR] يُنصح بشدة أن يكون معدّل الرفض الخاطئ أقل من %10، وذلك حسب القياس على الجهاز.
  • [SR] يُنصح بشدة أن يكون وقت الاستجابة أقل من ثانية واحدة، ويتم قياسه من وقت لمس أداة استشعار بصمة الإصبع إلى أن يتم فتح قفل الشاشة، وذلك لبصمة إصبع واحدة مسجّلة.
  • يجب استخدام رمز بصمة الإصبع على Android المتوفّر في "مشروع مفتوح المصدر لنظام Android".

‫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. حالة القيادة

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

‫7.3.11.4. سرعة العجلة

راجِع الفقرة 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-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، حتى في حالات الطاقة الاحتياطية
  • يجب أن يتم بشكل عشوائي مصدر عنوان MAC ورقم التسلسل لإطارات طلب الفحص، وذلك مرة واحدة في بداية كل عملية فحص، عندما يكون الجهاز غير متصل.
    • يجب أن تستخدم كل مجموعة من حِزم طلبات البحث التي تتضمّن عملية فحص واحدة عنوان MAC متسقًا (يجب عدم توزيع عنوان MAC عشوائيًا في منتصف عملية الفحص).
    • يجب أن يتكرّر رقم تسلسل طلب الفحص بشكل عادي (بالترتيب) بين طلبات الفحص في عملية المسح
    • يجب أن يكون رقم تسلسل طلب الفحص عشوائيًا بين آخر طلب فحص لعملية فحص وأول طلب فحص لعملية الفحص التالية
  • يجب السماح بعناصر المعلومات التالية فقط في إطارات طلبات البحث، بينما يكون الجهاز غير متصل بشبكة Wi-Fi:
    • مجموعة مَعلمات SSID (0)
    • مجموعة مَعلمات DS (3)
7.4.2.1. اتصال Wi-Fi مباشر

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

  • يجب أن يتضمّن دعمًا لتقنية اتصال Wi-Fi مباشر (شبكة Wi-Fi من جهاز إلى جهاز).

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

  • [C-1-1] يجب تنفيذ واجهة برمجة التطبيقات المتوافقة مع Android على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK).
  • [C-1-2] يجب الإبلاغ عن ميزة الأجهزة android.hardware.wifi.direct.
  • [C-1-3] يجب أن يتيح الجهاز التشغيل العادي لشبكة Wi-Fi.
  • يجب أن يتيح إجراء عمليات Wi-Fi واتصال Wi-Fi مباشر في الوقت نفسه.

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

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

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

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

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

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

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

‫7.4.3. بلوتوث

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

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

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

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

يتضمّن نظام التشغيل Android إمكانية استخدام البلوتوث والبلوتوث المنخفض الطاقة.

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

  • [C-2-1] يجب الإفصاح عن ميزات النظام الأساسي ذات الصلة (android.hardware.bluetooth وandroid.hardware.bluetooth_le على التوالي) وتنفيذ واجهات برمجة التطبيقات الخاصة بالنظام الأساسي.
  • يجب تنفيذ ملفات تعريف البلوتوث ذات الصلة، مثل A2DP وAVCP وOBEX وما إلى ذلك، حسب ما هو مناسب للجهاز.

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

  • [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 دقيقة وتغيير العنوان عند انتهاء المهلة لحماية خصوصية المستخدم.

‫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 (كما هو محدّد في المواصفات الفنية لمنتدى NFC‏ NFCForum-TS-DigitalProtocol-1.0) من خلال معايير 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، وذلك من خلال تنفيذ مواصفات "نقل الاتصال الإصدار 1.2" و"الإقران البسيط الآمن عبر البلوتوث باستخدام الإصدار 1.0 من تقنية NFC" الصادرة عن منتدى 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 القادرة على وظيفة محاكاة البطاقة المُضيفة (HCE) (لبروتوكول NfcA و/أو NfcB) وتتيح توجيه معرّف التطبيق (AID)، فإنّها:

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

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

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

يعتمد مستوى توافق IPv6 المطلوب على نوع الشبكة، كما يلي:

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

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

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

  • ‫[C-2-1] يجب أن يتيح الجهاز التشغيل المزدوج على شبكة Ethernet.

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

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

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

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

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

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

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

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

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

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

  • [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.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-5] يجب أن تكون معاينة الكاميرا معكوسة أفقيًا بالنسبة إلى الاتجاه الذي يحدده التطبيق عندما يطلب التطبيق الحالي صراحةً تدوير شاشة الكاميرا من خلال استدعاء الطريقة android.hardware.Camera.setDisplayOrientation(). في المقابل، يجب أن تتم محاكاة المعاينة على طول المحور الأفقي التلقائي للجهاز عندما لا يطلب التطبيق الحالي صراحةً تدوير شاشة الكاميرا من خلال استدعاء الطريقة android.hardware.Camera.setDisplayOrientation().
  • [C-1-6] يجب عدم عرض صورة ثابتة أو بث فيديو تم التقاطهما بشكل نهائي في معاينة معكوسة عند إرجاعهما إلى عمليات رد الاتصال في التطبيق أو حفظهما في مساحة تخزين الوسائط.
  • [C-1-7] يجب أن تعكس الصورة المعروضة في Postview الصورة المعروضة في معاينة الكاميرا بالطريقة نفسها.
  • قد تتضمّن ميزات (مثل التركيز التلقائي والفلاش وما إلى ذلك) متاحة للكاميرات الخلفية كما هو موضّح في الفقرة 7.5.1.

إذا كانت عمليات تنفيذ الأجهزة قابلة للتدوير من قِبل المستخدم (مثل التدوير تلقائيًا من خلال مقياس تسارع أو يدويًا من خلال بيانات أدخلها المستخدم):

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

‫7.5.3. الكاميرا الخارجية

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

  • قد يشمل إمكانية استخدام كاميرا خارجية غير متصلة دائمًا.

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

  • [C-1-1] يجب الإعلان عن علامة ميزة النظام الأساسي android.hardware.camera.external وandroid.hardware camera.any.
  • [C-1-2] يجب أن تتوافق مع "فئة فيديو USB" (الإصدار 1.0 أو إصدار أحدث) إذا كانت الكاميرا الخارجية تتصل من خلال منفذ USB.
  • يجب أن تتوافق مع عمليات ضغط الفيديو، مثل MJPEG، للسماح بنقل بث عالي الجودة غير مشفّر (أي بث صور أولية أو مضغوطة بشكل مستقل).
  • قد يتيح استخدام كاميرات متعددة.
  • قد يتيح ترميز الفيديو المستند إلى الكاميرا. في حال توفّرها، يجب أن يكون بث MJPEG أو بث غير مشفّر متزامن (بدقة QVGA أو أعلى) متاحًا لتنفيذ الجهاز.

7.5.4. سلوك Camera API

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

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

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

  • [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] يجب أن تتوافق الكاميرات الأمامية والخلفية مع تنسيق YV12 (كما هو موضّح بالثابت android.graphics.ImageFormat.YV12) لمعاينات الكاميرا في android.hardware.Camera. (قد يستخدم برنامج ترميز الفيديو والكاميرا أي تنسيق بكسل أصلي، ولكن يجب أن يتيح تنفيذ الجهاز التحويل إلى YV12).
  • [C-0-4] يجب أن تتوافق مع تنسيقي android.hardware.ImageFormat.YUV_420_888 وandroid.hardware.ImageFormat.JPEG كناتجَين من خلال واجهة برمجة التطبيقات android.media.ImageReader لأجهزة android.hardware.camera2 التي تعلن عن إمكانية REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE في android.request.availableCapabilities.
  • [C-0-5] يجب أن يظلّ الجهاز ينفّذ واجهة برمجة التطبيقات للكاميرا الكاملة المُضمّنة في مستندات حزمة تطوير البرامج (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 على النحو الموضّح في حزمة تطوير البرامج لنظام التشغيل Android، والإبلاغ عن علامات ميزات إطار العمل المناسبة.
  • [C-0-8] يجب أيضًا الإفصاح عن إمكانات الكاميرا الفردية android.hardware.camera2 من خلال السمة android.request.availableCapabilities والإفصاح عن علامات الميزات المناسبة، ويجب تحديد علامة الميزة إذا كانت أي من أجهزة الكاميرا المرفقة بها تتوافق مع الميزة.
  • [C-0-9] يجب بثّ الغرض Camera.ACTION_NEW_PICTURE كلما تم التقاط صورة جديدة بالكاميرا وتمت إضافة إدخال الصورة إلى "متجر الوسائط".
  • [C-0-10] يجب بث الغرض Camera.ACTION_NEW_VIDEO كلما سجّلت الكاميرا فيديو جديدًا وتمت إضافة إدخال الصورة إلى "متجر الوسائط".

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

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

‫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 الحالية والجديدة باستيفاء هذه المتطلبات حتى تتمكّن من الترقية إلى إصدارات المنصة المستقبلية.
  • [موصى به بشدة] يُنصح بعدم توفير طرق شحن خاصة تعدّل جهد Vbus بما يتجاوز المستويات التلقائية، أو تغيّر أدوار المصدر/المستقبل، لأنّ ذلك قد يؤدي إلى حدوث مشاكل في التشغيل التفاعلي مع الشواحن أو الأجهزة التي تتوافق مع طرق USB Power Delivery العادية. على الرغم من أنّ هذا الإجراء يُصنّف على أنّه "يُنصح به بشدة"، قد نطلب في إصدارات Android المستقبلية أن تتوافق جميع الأجهزة من النوع C بشكل كامل مع الشواحن العادية من النوع C.
  • [مطلوب بشدة] يُنصح بشدة بتوفير ميزة Power Delivery لتبديل أدوار البيانات والطاقة عند توفّر منفذ USB من النوع C ووضع مضيف USB.
  • يجب أن تتوافق مع معيار الشحن الفائق السرعة للشحن بجهد عالٍ، وأن تتوافق مع الأوضاع البديلة، مثل عرض المحتوى على شاشة خارجية.
  • يجب تنفيذ واجهة برمجة التطبيقات والمواصفات الخاصة ببروتوكول Android Open Accessory (AOA) كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

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

  • [C-2-1] يجب الإفصاح عن إمكانية استخدام ميزة الجهاز android.hardware.usb.accessory.
  • [C-2-2] يجب أن يتضمّن فئة وحدة تخزين USB الخارجية السلسلة "android" في نهاية سلسلة iInterface لوصف الواجهة الخاصة بوحدة تخزين USB الخارجية

‫7.7.2. وضع مستضيف USB

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

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

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقبس صوت رباعي الموصلات مقاس 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 فولت.
  • [SR] يُنصح بشدة بربط رمز المفتاح بنطاق المعاوقة المكافئة التالي بين الميكروفون وموصلات التأريض في قابس الصوت:
    • من 110 إلى 180 أوم: KEYCODE_VOICE_ASSIST
  • يجب أن تتوافق مع ترتيب دبابيس OMTP.
  • يجب أن يتيح تسجيل الصوت من سمّاعات الرأس الاستيريو التي تتضمّن ميكروفونًا.

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

إذا كانت قيمة 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. أداء عالٍ في الواقع الافتراضي

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

  • [C-1-1] يجب أن تتضمّن وحدتا معالجة مركزية مادية على الأقل.
  • [C-1-2] يجب الإفصاح عن android.software.vr.mode feature.
  • [C-1-3] يجب أن يتوافق الجهاز مع وضع الأداء المستدام.
  • [C-1-4] يجب أن يتوافق الجهاز مع OpenGL ES 3.2.
  • [C-1-5] يجب أن تتوافق الأجهزة مع مستوى الأجهزة 0 في Vulkan، ويُفضَّل أن تتوافق مع مستوى الأجهزة 1 في Vulkan.
  • [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 المتاحة.
  • ‫[C-1-7] يجب أن يكون بإمكان وحدة معالجة الرسومات والشاشة مزامنة الوصول إلى المخزن المؤقت الأمامي المشترَك، وذلك لعرض محتوى الواقع الافتراضي بمعدل 60 إطارًا في الثانية مع سياقَي عرض بدون أي تشوّهات مرئية.
  • [C-1-8] يجب تنفيذ GL_EXT_multisampled_render_to_texture وGL_OVR_multiview وGL_OVR_multiview2 وGL_OVR_multiview_multisampled_render_to_texture وGL_EXT_protected_textures وGL_EXT_EGL_image_array وGL_EXT_external_buffer، وعرض الإضافات في قائمة إضافات GL المتاحة.
  • [C-1-9] يجب توفير إمكانية استخدام العلامتَين AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER وAHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA على النحو الموضّح في حزمة تطوير البرامج الأصلية (NDK).
  • [C-1-10] يجب توفير إمكانية استخدام AHardwareBuffers مع أكثر من طبقة واحدة.
  • ‫[C-1-11] يجب أن تتوافق مع فك ترميز H.264 بدقة 3840x2160@30fps-40Mbps على الأقل (أي ما يعادل 4 حالات بدقة 1920x1080@30fps-10Mbps أو حالتين بدقة 1920x1080@60fps-20Mbps).
  • ‫[C-1-12] يجب أن يتوافق مع HEVC وVP9، ويجب أن يكون قادرًا على فك ترميز 1920x1080@30fps-10Mbps على الأقل، ويجب أن يكون قادرًا على فك ترميز 3840x2160@30fps-20Mbps (أي ما يعادل 4 حالات من 1920x1080@30fps-5Mbps).
  • [C-1-13] يجب أن تتوافق الساعة مع واجهة برمجة التطبيقات HardwarePropertiesManager.getDeviceTemperatures وأن تعرض قيمًا دقيقة لدرجة حرارة الجلد.
  • [C-1-14] يجب أن يتضمّن شاشة مدمجة، ويجب أن تكون درجة الدقة Full HD(1080p) على الأقل، ويُنصح بشدة أن تكون Quad HD (1440p) أو أعلى.
  • ‫[C-1-15] يجب أن يتم تعديل الشاشة بمعدّل 60 هرتز على الأقل أثناء وضع الواقع الافتراضي.
  • ‫[C-1-16] يجب أن يكون وقت استجابة الشاشة (كما تم قياسه في وقت التبديل من الرمادي إلى الرمادي ومن الأبيض إلى الأسود ومن الأسود إلى الأبيض) ≤ 6 مللي ثانية.
  • [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-1-20] يجب أن تتوافق مع نوع القناة المباشرة TYPE_HARDWARE_BUFFER لجميع أنواع القنوات المباشرة المذكورة أعلاه.
  • [SR] يُنصح بشدة بتوفير ميزة android.hardware.sensor.hifi_sensors ويجب استيفاء المتطلبات المتعلقة بالجيروسكوب ومقياس التسارع ومقياس المغناطيسية في android.hardware.hifi_sensors.
  • يمكن توفير نواة حصرية للتطبيق الذي يعمل في المقدّمة، ويمكن أن تتوافق مع واجهة برمجة التطبيقات Process.getExclusiveCores لعرض أرقام نوى وحدة المعالجة المركزية الحصرية للتطبيق الذي يعمل في المقدّمة. إذا كان النواة الحصرية متوافقة، يجب ألا تسمح النواة بتشغيل أي عمليات أخرى لمساحة المستخدم (باستثناء برامج تشغيل الأجهزة التي يستخدمها التطبيق)، ولكن قد تسمح بتشغيل بعض عمليات النواة حسب الضرورة.

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

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

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

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

‫8.2. أداء الوصول إلى عمليات الإدخال والإخراج للملفات

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

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

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

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

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

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

  • [C-1-1] يجب ألا يدخل الجهاز في هذه الحالات إلا عند إغلاق غطاء يشكّل جزءًا ماديًا من الجهاز.

‫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() لواجهة برمجة التطبيقات تتضمّن أرقام تعريف النوى الحصرية التي يمكن أن يحجزها التطبيق الذي يعمل في المقدّمة.
  • [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-1-1] يُنصح بشدة بتوفير آلية يمكن للمستخدم الوصول إليها لمنح إذن الوصول إلى إحصاءات الاستخدام أو إبطاله استجابةً للغرض android.settings.ACTION_USAGE_ACCESS_SETTINGS للتطبيقات التي تصرِّح باستخدام الإذن android.permission.PACKAGE_USAGE_STATS.

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

  • [C-2-1] يجب أن يظلّ هناك نشاط يعالج نمط intent android.settings.ACTION_USAGE_ACCESS_SETTINGS، ولكن يجب تنفيذه على أنّه عملية غير نشطة، أي أن يكون له سلوك مكافئ كما لو تم رفض وصول المستخدم.

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

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

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

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

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

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

في حال إعلان عمليات تنفيذ الأجهزة عن إتاحة 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] يجب تنفيذ وسائل الحماية من تجاوز سعة المخزن المؤقت لمكدس النواة (مثل CONFIG_CC_STACKPROTECTOR_STRONG).
  • [C-0-8] يجب تنفيذ إجراءات حماية صارمة لذاكرة النواة، بحيث يكون الرمز القابل للتنفيذ للقراءة فقط، والبيانات للقراءة فقط غير قابلة للتنفيذ وغير قابلة للكتابة، والبيانات القابلة للكتابة غير قابلة للتنفيذ (مثل CONFIG_DEBUG_RODATA أو CONFIG_STRICT_KERNEL_RWX).
  • [SR] يُنصح بشدة بإبقاء بيانات النواة التي تتم كتابتها أثناء عملية الإعداد فقط على أنّها للقراءة فقط بعد عملية الإعداد (مثل __ro_after_init).
  • [SR} يُنصح بشدة بتنفيذ عملية التحقّق من الحدود الثابتة والديناميكية لحجم النسخ بين مساحة المستخدم ومساحة النواة (مثل CONFIG_HARDENED_USERCOPY).
  • [SR] يُنصح بشدة بعدم تنفيذ ذاكرة مساحة المستخدم عند التشغيل في النواة (مثل PXN للأجهزة أو المحاكي من خلال CONFIG_CPU_SW_DOMAIN_PAN أو CONFIG_ARM64_SW_TTBR0_PAN).
  • [SR] يُنصح بشدة بعدم قراءة أو كتابة ذاكرة مساحة المستخدم في النواة خارج واجهات برمجة التطبيقات العادية للوصول إلى usercopy (مثل PAN للأجهزة أو المحاكي عبر CONFIG_CPU_SW_DOMAIN_PAN أو CONFIG_ARM64_SW_TTBR0_PAN).
  • [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 ونطاقات الأجهزة/المورّدين المحدّدة.
  • يجب الاحتفاظ بسياسة SELinux التلقائية المتوفّرة في مجلد system/sepolicy في مشروع Android المفتوح المصدر الأساسي، وإضافة المزيد إلى هذه السياسة فقط لتوفير إعدادات خاصة بالجهاز.

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

  • [C-2-1] يجب استخدام نظام تحكّم إلزامي في الوصول يكون مكافئًا لنظام SELinux.

‫9.8. الخصوصية

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

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

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

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

‫9.8.2. جارٍ التسجيل

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

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

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

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

إذا كانت عمليات تنفيذ الأجهزة تتيح شاشة قفل آمنة كما هو موضّح في الفقرة 9.11.1 وتتيح تشفير تخزين البيانات باستخدام أداء تشفير "معيار التشفير المتقدّم" (AES) الذي يزيد عن 50 ميغابايت/ثانية، فإنّها:

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

  • ‫[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 لأي مستخدم مع مفاتيح CE أو DE لأي مستخدم آخر.

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

  • قد يتيح استخدام طرق تشفير بديلة وأطوال مفاتيح وأنماط لتشفير محتوى الملف واسم الملف، ولكن يجب استخدام طرق التشفير وأطوال المفاتيح والأنماط المتوافقة إلزاميًا بشكلٍ تلقائي.

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

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

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

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

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

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

  • [C-2-1] يجب أن تتوافق مع ميزة "التشغيل المتحقّق منه" لضمان سلامة الجهاز.

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

‫9.11. المفاتيح وبيانات الاعتماد

يتيح نظام Android Keystore لمطوّري التطبيقات تخزين مفاتيح التشفير في حاوية واستخدامها في عمليات التشفير من خلال KeyChain API أو Keystore API. عمليات تنفيذ الجهاز:

  • [C-0-1] يجب أن يسمح على الأقل باستيراد أكثر من 8,192 مفتاحًا.
  • ‫[C-0-2] يجب أن يفرض مصادقة شاشة القفل حدًا أقصى لعدد المحاولات، ويجب أن يتضمّن خوارزمية التراجع الأسي. بعد 150 محاولة فاشلة، يجب أن يكون التأخير 24 ساعة على الأقل لكل محاولة.
  • يجب عدم وضع حدّ لعدد المفاتيح التي يمكن إنشاؤها

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

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

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

‫9.11.1. تأمين قفل الجهاز

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

  • [C-1-1] يجب أن تشير واجهة مستخدم "الإعدادات" و"شاشة القفل" إلى الحالات التي يتم فيها تأجيل القفل التلقائي للشاشة أو الحالات التي يمكن فيها فتح قفل الشاشة باستخدام وكيل موثوق به. يستوفي AOSP هذا الشرط من خلال عرض وصف نصي لقائمتَي "إعداد القفل التلقائي" و "إعداد القفل الفوري باستخدام زر التشغيل"، بالإضافة إلى رمز مميّز على شاشة القفل.
  • [C-1-2] يجب احترام جميع واجهات برمجة التطبيقات الخاصة بالوكيل المعتمد وتنفيذها بالكامل في الفئة DevicePolicyManager، مثل الثابت KEYGUARD_DISABLE_TRUST_AGENTS.
  • [C-1-3] يجب ألا يتم تنفيذ وظيفة TrustAgentService.addEscrowToken() بالكامل على جهاز يُستخدَم كجهاز شخصي أساسي (مثل جهاز محمول)، ولكن يجوز تنفيذ الوظيفة بالكامل على عمليات تنفيذ الأجهزة التي تتم مشاركتها عادةً.
  • [C-1-4] يجب أن يشفّر TrustAgentService.addEscrowToken() الرموز المميزة التي يضيفها قبل تخزينها على الجهاز.
  • [C-1-5] يجب عدم تخزين مفتاح التشفير على الجهاز.
  • [C-1-6] يجب إبلاغ المستخدم بالآثار الأمنية قبل تفعيل الرمز المميز للوصول الاحتياطي من أجل فك تشفير بيانات التخزين.

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

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

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

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

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

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

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

  • [C-5-1] يجب توفُّر آلية احتياطية لاستخدام إحدى طرق المصادقة الأساسية المستندة إلى سر معروف وتستوفي متطلبات اعتبارها شاشة قفل آمنة.
  • [C-5-2] يجب إيقافها ولا يُسمح إلا بالمصادقة الأساسية لفتح قفل الشاشة عندما يضبط تطبيق "وحدة التحكّم في سياسة الجهاز" (DPC) سياسة ميزة keguard من خلال استدعاء الطريقة DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT).
  • [C-5-3] يجب أن يكون معدّل القبول الخاطئ مساويًا أو أفضل من المعدّل المطلوب لأداة استشعار بصمة الإصبع كما هو موضّح في القسم 7.3.10، أو يجب إيقافه والسماح فقط بالمصادقة الأساسية لفتح قفل الشاشة عندما يضبط تطبيق "وحدة التحكّم في سياسة الجهاز" سياسة جودة كلمة المرور باستخدام الطريقة DevicePolicyManager.setPasswordQuality() مع ثابت جودة أكثر تقييدًا من PASSWORD_QUALITY_BIOMETRIC_WEAK.
  • [SR] يُنصح بشدة بأن تكون معدّلات قبول عمليات الانتحال والتزوير مساوية أو أفضل من المعدّلات المطلوبة لمستشعر بصمة الإصبع كما هو موضّح في القسم 7.3.10.

إذا لم تكن معدلات قبول الانتحال والتزوير مساوية أو أفضل من المعدلات المطلوبة لمستشعر بصمة الإصبع كما هو موضح في الفقرة 7.3.10، وإذا كان تطبيق "وحدة التحكّم بسياسة الجهاز" (DPC) قد ضبط سياسة جودة كلمة المرور من خلال طريقة DevicePolicyManager.setPasswordQuality() مع ثابت جودة أكثر تقييدًا من PASSWORD_QUALITY_BIOMETRIC_WEAK، فيجب استيفاء ما يلي:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

يتضمّن Android ميزات تسمح لتطبيق "مالك الجهاز" (في حال توفّره) بالتحكّم في تثبيت تحديثات النظام. ولتسهيل ذلك، يجب أن ينفّذ النظام الفرعي لتحديث النظام للأجهزة التي تُبلغ عن android.software.device_admin السلوك الموضّح في فئة SystemUpdatePolicy.

12. سجلّ التغييرات في المستند

للاطّلاع على ملخّص للتغييرات التي تم إجراؤها على "مستند تعريف معايير التوافق" في هذا الإصدار، يُرجى اتّباع الخطوات التالية:

للحصول على ملخّص بالتغييرات التي تم إجراؤها على أقسام الأفراد، اتّبِع الخطوات التالية:

  1. مقدّمة
  2. أنواع الأجهزة
  3. البرامج
  4. تغليف التطبيق
  5. الوسائط المتعددة
  6. أدوات وخيارات المطوّرين
  7. توافق الأجهزة
  8. الأداء والطاقة
  9. نموذج الأمان
  10. اختبار توافق البرامج
  11. البرامج القابلة للتحديث
  12. سجلّ تغييرات المستند
  13. التواصل معنا

‫12.1. نصائح حول عرض سجلّ التغييرات

يتم وضع علامات على التغييرات على النحو التالي:

  • CDD
    تغييرات جوهرية في متطلبات التوافق

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

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

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

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