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

‫1. مقدّمة

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

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

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

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

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

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

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

1.1 بنية المستند

1.1.1. المتطلبات حسب نوع الجهاز

يحتوي القسم 2 على جميع المتطلبات التي يجب استيفاؤها والإجراءات التي يُنصح بشدة باتّباعها والتي تنطبق على نوع جهاز معيّن. كل قسم فرعي من القسم 2 مخصّص لنوع جهاز معيّن.

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

1.1.2. رقم تعريف المتطلّبات

يتمّ منح معرّف المتطلّبات للمتطلّبات التي يجب استيفاؤها.

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

يتم تعريف كل معرّف على النحو التالي:

  • رقم تعريف نوع الجهاز (اطّلِع على مزيد من المعلومات في 2. أنواع الأجهزة
    • ج: الأساسية (المتطلبات التي يتم تطبيقها على أي عمليات تنفيذ على أجهزة Android)
    • H: جهاز Android المحمول
    • T: جهاز Android Television
    • أ: عملية تنفيذ Android Automotive
  • رقم تعريف الحالة
    • عندما يكون الشرط غير مشروط، يتم ضبط هذا المعرّف على 0.
    • عندما يكون الشرط شَرطًا مشروطًا، يتمّ تخصيص الرقم 1 للشرط الأول، ويزداد الرقم بمقدار 1 ضمن القسم نفسه ونوع الجهاز نفسه.
  • رقم تعريف المتطلّب
    • يبدأ هذا المعرّف من 1 ويزيد بمقدار 1 ضمن القسم نفسه والشرط نفسه.

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

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

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

يجب أن تستوفي جميع عمليات تنفيذ أجهزة 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 بوصة (6.35 سم) قطريًا.*

كثافة الشاشة (الفقرة 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)

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

  • يجب أن تتضمّن تقنية البلوتوث وBluetooth LE.

توفير استهلاك البيانات (القسم 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 Profile (AAC LC)
  • [H-0-4] MPEG-4 HE AAC Profile (AAC+)
  • [H-0-5] AAC ELD (enhanced low delay 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] يجب أن يتضمّن التطبيق شاشة إشعارات تتيح للمستخدم التحكّم مباشرةً في الإشعارات (مثل الردّ أو الإيقاف المؤقت أو الإغلاق أو الحظر) من خلال عناصر تفاعلية تناسب المستخدمين، مثل أزرار الإجراءات أو لوحة التحكّم كما هو مُطبَّق في 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] يجب أن تكون جميع التطبيقات المعفاة من وضعَي "الاستراحة" و"الوضع المنخفض الطاقة" للتطبيقات مرئية للمستخدم النهائي.
  • [H-0-2] يجب ألا تختلف خوارزميات التفعيل والصيانة والتنشيط واستخدام إعدادات النظام الشاملة لوضعَي "الاستراحة" و"الاستراحة الذكية" للتطبيقات عن تلك الواردة في مشروع Android Open Source Project.

تتبُّع استهلاك الطاقة (الفقرات 8.4)

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

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

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

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

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

2.3.1. الأجهزة

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

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

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

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

  • [T-0-1] يجب أن يوفّر زرّي Home وBack.
  • [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] يجب أن يكون الجهاز متوافقًا مع البلوتوث وتقنية البلوتوث منخفضة الطاقة.

الحد الأدنى للذاكرة ومساحة التخزين (الفقرة 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 Profile (AAC LC)
  • [T-0-2] MPEG-4 HE AAC Profile (AAC+)
  • ‫[T-0-3] AAC ELD (الترميز المتقدّم للصوت بوقت استجابة منخفض)

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

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

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

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

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

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

فك ترميز الفيديو (القسم 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] يجب أن يكون متوافقًا مع الملف الشخصي لمستوى High Profile 4.2 وملف ترميز 1080p HD (بمعدل 60 لقطة في الثانية).
  • [T-1-2] يجب أن يكون الجهاز قادرًا على فك ترميز الفيديوهات باستخدام الملفات الشخصية ذات الدقة العالية كما هو موضّح في الجدول التالي، والتي تم ترميزها باستخدام الملف الشخصي الأساسي أو الملف الشخصي الرئيسي أو الملف الشخصي العالي المستوى 4.2.

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

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

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

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

  • [T-2-1] يجب أن يتوافق برنامج الترميز مع ملف التعريف Main10 Level 5 Main Tier.

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] يجب أن يكون الجهاز متوافقًا مع دقة 1080p بمعدل 60 لقطة في الثانية.

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

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

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

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

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

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

  • [T-SR] Are STRONGLY RECOMMENDED to support simultaneous decoding of secure streams. يُنصح بشدة بفك ترميز بثَّين في الوقت نفسه على الأقل.

مستوى صوت إخراج الصوت (القسم 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 TV بحيث تكون وظائفها مماثلة أو أفضل من وظائف خدمات "الوصول عبر مفتاح التحويل" وTalkBack (للغات المتوافقة مع ميزة "تحويل النص إلى كلام" المُحمَّلة مسبقًا) كما هو موضّح في مشروع TalkBack المفتوح المصدر.

تحويل النص إلى كلام (الفقرة 3.11)

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

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

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

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

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

  • [T-0-1] يجب أن يكون متوافقًا مع إطار عمل إدخال التلفزيون.

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 Open Source Project.

تتبُّع استهلاك الطاقة (الفقرات 8.4)

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

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

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

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

2.5.1. الأجهزة

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

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

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

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

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

  • [A-0-1] يجب أن يوفّر دالة Home (الصفحة الرئيسية) ويمكن أن يوفّر دالتَي Back (الرجوع) وRecent (التطبيقات المستخدَمة مؤخرًا).
  • [A-0-2] يجب إرسال كل من حدث الضغط العادي والضغط لفترة طويلة على وظيفة الرجوع (KEYCODE_BACK) إلى التطبيق المعروض في المقدّمة.

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

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

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

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

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

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

  • [أ-1-1] يجب أن يكون الجيل من تكنولوجيا نظام تحديد المواقع العالمي (GNSS) لعام "2017" أو إصدارًا أحدث.

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

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

  • [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 مع الملفات الشخصية التالية لبروتوكول Bluetooth:

    • إجراء مكالمات هاتفية عبر ملف الإعدادات بدون لمس الجهاز (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] الملف الشخصي لبرنامج ترميز الصوت المتقدم (AAC) في MPEG-4 (AAC LC)
  • [A-1-2] MPEG-4 HE AAC Profile (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)

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

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

تتبُّع استهلاك الطاقة (الفقرات 8.4)

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

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

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

التوافق مع ميزة "الوصول المتعدّد للمستخدمين" (الفقرة 9.5)

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

  • [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. واجهة برمجة تطبيقات 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_-]+$". ويجب ألّا يتغيّر اسم الجهاز هذا خلال فترة استخدام المنتج.
بصمة الإصبع سلسلة تحدّد هذا الإصدار بشكل فريد يجب أن يكون سهل القراءة على الإنسان. يجب أن يتّبع هذا النموذج:

$(BRAND)/$(PRODUCT)/
    $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)

مثلاً:

acme/myproduct/
    mydevice:8.1/LMYXX/3359:userdebug/test-keys

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

الأجهزة اسم الجهاز (من سطر أوامر kernel أو ‎ /proc) يجب أن يكون سهل القراءة على الإنسان. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9_-]+$".
HOST سلسلة تحدِّد بشكل فريد المضيف الذي تم إنشاء الإصدار عليه، بتنسيق يمكن لشخص عادي قراءته ما مِن متطلبات خاصة بتنسيق هذا الحقل، باستثناء أنّه يجب ألّا يكون فارغًا أو سلسلة فارغة ("").
رقم التعريف معرّف يختاره مُنفِّذ الجهاز للإشارة إلى إصدار معيّن بتنسيق يسهل على المستخدم قراءته يمكن أن يكون هذا الحقل هو نفسه android.os.Build.VERSION.INCREMENTAL، ولكن يجب أن يكون له قيمة ذات مغزى كافٍ للمستخدمين النهائيين من أجل التمييز بين إصدارات البرامج. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9._-]+$".
الشركة المصنّعة الاسم التجاري للمصنّع الأصلي للجهاز (OEM) ما مِن متطلبات حول التنسيق المحدّد لهذا الحقل، باستثناء أنّه يجب ألّا يكون فارغًا أو سلسلة فارغة (""). يجب ألّا يتغيّر هذا الحقل خلال مدة توفّر المنتج.
الطراز قيمة يختارها منفذ الجهاز تحتوي على اسم الجهاز كما يعرفه المستخدم النهائي. يجب أن يكون هذا هو الاسم نفسه الذي يتم بموجبه تسويق الجهاز وبيعه للمستخدمين النهائيين. ما مِن متطلبات حول التنسيق المحدّد لهذا الحقل، باستثناء أنّه يجب ألّا يكون فارغًا أو سلسلة فارغة (""). يجب ألّا يتغيّر هذا الحقل خلال مدة توفّر المنتج.
المنتج قيمة يختارها منفذ الجهاز تحتوي على اسم التطوير أو الاسم الرمزي للمنتج المحدّد (رمز التخزين التعريفي) الذي يجب أن يكون فريدًا ضمن العلامة التجارية نفسها. يجب أن تكون قابلة للقراءة من قِبل البشر، ولكن ليس بالضرورة أن تكون مخصّصة للعرض من قِبل المستخدمين النهائيين. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9_-]+$". ويجب ألّا يتغيّر اسم المنتج هذا خلال فترة استخدام المنتج.
SERIAL رقم تسلسلي للأجهزة، يجب أن يكون متاحًا وفريدًا على جميع الأجهزة التي تحمل الطراز والشركة المصنّعة نفسهما يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي "^([a-zA-Z0-9]{6,20})$".
العلامات قائمة مفصولة بفواصل بالعلامات التي اختارها مُنفِّذ الجهاز والتي تميّز الإصدار بشكل أكبر يجب أن يحتوي هذا الحقل على إحدى القيم المقابلة لإعدادات التوقيع النموذجية الثلاثة لنظام Android الأساسي: مفاتيح الإصدار، مفاتيح المطوّرين، مفاتيح الاختبار.
الوقت قيمة تمثّل الطابع الزمني لوقت إنشاء الإصدار
النوع قيمة يختارها مُنفِّذ الجهاز لتحديد إعدادات وقت التشغيل للإصدار يجب أن يحتوي هذا الحقل على إحدى القيم المقابلة لإعدادات وقت تشغيل Android النموذجية الثلاثة: user أو userdebug أو eng.
المستخدم اسم أو رقم تعريف المستخدم (أو المستخدم المبرمَج) الذي أنشأ الإصدار ما مِن متطلبات خاصة بتنسيق هذا الحقل، باستثناء أنّه يجب ألّا يكون فارغًا أو سلسلة فارغة ("").
SECURITY_PATCH قيمة تشير إلى مستوى تصحيح الأمان لإصدار معيّن يجب أن يشير ذلك إلى أنّ الإصدار ليس معرّضًا بأي شكل من الأشكال لأي من المشاكل الموضّحة في نشرة أمان Android العامة المحدّدة. يجب أن تكون بالتنسيق [YYYY-MM-DD]، وأن تتطابق مع سلسلة محدّدة موثّقة في نشرة أمان Android العامة أو في إشعار أمان Android، على سبيل المثال "‎2015-11-01".
BASE_OS قيمة تمثّل مَعلمة FINGERPRINT للإصدار الذي يتطابق مع هذا الإصدار باستثناء الرقع المقدَّمة في نشرة الأمان العام لنظام التشغيل Android يجب أن يعرض الإصدار القيمة الصحيحة، وإذا لم يكن هذا الإصدار متوفّرًا، يجب أن يعرض سلسلة فارغة ("").
برنامج تحميل التشغيل قيمة يختارها مُنفِّذ الجهاز لتحديد إصدار أداة تحميل البرامج الثابتة الداخلية المحدّد المستخدَم في الجهاز، بتنسيق يمكن لشخص عادي قراءته يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9._-]+$".
getRadioVersion() يجب أن تكون (أو تعرض) قيمة يختارها مُنفِّذ الجهاز لتحديد إصدار الراديو/المودم الداخلي المحدّد المستخدَم في الجهاز، بتنسيق يمكن لشخص عادي قراءته. إذا لم يكن الجهاز مزوّدًا بأي جهاز لاسلكي/مودم داخلي، يجب أن يعرض القيمة NULL. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9._-,]+$".

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

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

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

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

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

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

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

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

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

  • [C-0-4] يجب محاولة التحقّق من صحة أي فلاتر أهداف من خلال تنفيذ خطوات التحقّق المحدّدة في مواصفات روابط تنقل إلى مواد عرض رقمية على النحو الذي نفّذه "مدير الحِزم" في مشروع Android Open Source Project.
  • [C-0-5] يجب محاولة التحقّق من فلاتر الأهداف أثناء تثبيت التطبيق وضبط جميع فلاتر أهداف UIR التي تم التحقّق منها بنجاح كمعالِجات تلقائية للتطبيقات لعناوين URL الخاصة بها.
  • يجوز لها ضبط فلاتر أهداف معيّنة لعناوين URL كمعالِجات تطبيق تلقائية لمعرّفات URL الخاصة بها، إذا تم التحقّق منها بنجاح ولكن تعذّر التحقّق من فلاتر عناوين URL المعنيّة الأخرى. إذا كان تنفيذ الجهاز يفعل ذلك، يجب أن يقدّم للمستخدم عمليات إلغاء أنماط لكل عنوان URL في قائمة الإعدادات.
  • يجب أن يقدّم التطبيق للمستخدم عناصر تحكّم في "روابط التطبيقات" لكل تطبيق في "الإعدادات" على النحو التالي:
    • [C-0-6] يجب أن يتمكّن المستخدم من إلغاء السلوك التلقائي لـ "روابط التطبيقات" بشكل كامل ليكون التطبيق: مفتوحًا دائمًا أو يسأل المستخدم دائمًا أو لا يفتح أبدًا، ويجب أن ينطبق ذلك على جميع فلاتر أغراض معرّفات URI المرشحة بالتساوي.
    • [C-0-7] يجب أن يتمكّن المستخدم من الاطّلاع على قائمة بفلاتر أغراض معرّفات الموارد المنتظمة المعنيّة.
    • قد يمنح تنفيذ الجهاز المستخدم إمكانية إلغاء فلاتر أهداف معرّفات الموارد المنتظمة (URI) المرشحة المحدّدة التي تم التحقّق منها بنجاح، وذلك على أساس كل فلتر هدف.
    • [C-0-8] يجب أن يمنح تطبيق الجهاز المستخدمين إمكانية عرض فلاتر معيّنة لقصد معرّف الموارد المنتظم (URI) المرشح وتجاوزها إذا كان تطبيق الجهاز يسمح لبعض فلاتر قصد معرّف الموارد المنتظم (URI) المرشح بالنجاح في عملية التحقّق بينما يمكن أن يفشل البعض الآخر.
3.2.3.3. مساحات أسماء الأهداف
  • [C-0-1] يجب ألا تتضمّن عمليات تنفيذ الأجهزة أي مكوّن Android يراعي أي أنماط جديدة لبث الأهداف أو الأهداف باستخدام سلسلة مفتاح ACTION أو CATEGORY أو سلسلة مفتاح أخرى في مساحة الاسم android. أو com.android..
  • [C-0-2] يجب ألا يُدرِج مورّدو الأجهزة أيّ مكوّنات Android تلتزم بأي أنماط جديدة لطلبات التشغيل أو أنماط طلبات البث باستخدام سلسلة مفتاح ACTION أو CATEGORY أو سلسلة مفتاح أخرى في مساحة حزمة تابعة لمؤسسة أخرى.
  • [C-0-3] يجب ألا يغيّر مورّدو الأجهزة أو يمدّدوا أيًا من أنماط النوايا المستخدَمة من قِبل التطبيقات الأساسية المُدرَجة في الفقرة 3.2.3.1.
  • قد تتضمّن عمليات تنفيذ الأجهزة أنماط النية باستخدام مساحات الأسماء المرتبطة بوضوح وبشكل واضح بمؤسستها. يشبه هذا الحظر الحظر المحدّد لفئات لغة Java في الفقرة 3.6.
3.2.3.4. نوايا البث

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

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

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

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

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

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

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

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

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

  • [C-2-2] يجب الالتزام بنية android.telecom.action.CHANGE_DEFAULT_DIALER لعرض مربّع حوار للسماح للمستخدم بتغيير تطبيق "الهاتف" التلقائي.

  • [C-2-3] يجب الالتزام بنِيّة android.telecom.action.CHANGE_PHONE_ACCOUNTS لتوفير إمكانات للمستخدم لضبط ConnectionServices المرتبط بـ PhoneAccounts، بالإضافة إلى PhoneAccount التلقائي الذي سيستخدمه مقدّم خدمة الاتصالات السلكية واللاسلكية لإجراء المكالمات الصادرة. يستوفي تطبيق AOSP هذا الشرط من خلال تضمين قائمة "خيارات حسابات الاتصال" ضمن قائمة إعدادات "المكالمات".

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

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

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

3.2.4. الأنشطة على شاشات العرض الثانوية

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.4.1. توافق 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 Open Source Project.
    • قد تحذف عمليات تنفيذ الأجهزة كلمة Mobile في سلسلة وكيل المستخدم.

  • يجب أن يتضمّن مكوّن 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 Open Source في المصدر. في ما يلي بعض مجالات التوافق المحدّدة:

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

يُرجى العِلم أنّ القائمة أعلاه ليست شاملة. تختبر مجموعة أدوات اختبار التوافق (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 Executable Format ونظام إدارة الحِزم المرجعي.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.3. الإشعارات

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

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

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

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

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

  • [C-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. عدم الإزعاج

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [SR] يُنصح بشدة باستخدام واجهة مستخدم Android الأصلية (أو واجهة مشابهة مستندة إلى الصور المصغّرة) لشاشة النظرة العامة.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.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 قبل تسجيل تطبيق "إدارة الخدمات الجوّالة للمؤسسات" بصفته "مالك الجهاز".
  • قد تتوفّر لديه بيانات المستخدم على الجهاز قبل تسجيل تطبيق "وحدة التحكّم بسياسة الجهاز" بصفته "مالك الجهاز".
3.9.1.2 توفير الملف الشخصي المُدار

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

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

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

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

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

3.9.2 توافق الملف الشخصي المُدار

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

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

3.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 Television (TIF) على تبسيط عرض المحتوى المباشر على أجهزة Android Television. توفّر TIF واجهة برمجة تطبيقات عادية لإنشاء وحدات إدخال تتحكّم في أجهزة Android Television.

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

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

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

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

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

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

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

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

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

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

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

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

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

    • تغيير القنوات التلفزيونية
    • فتح دليل البرامج الإلكتروني (EPG)
    • ضبط وتعديل الإدخالات المستندة إلى 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، يجب استيفاء الشروط التالية:

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] يجب أن يكون الجهاز قادرًا على تثبيت ملفات "‎.apk" لنظام التشغيل Android وتشغيلها كما يتم إنشاؤها بواسطة أداة "aapt" المضمّنة في حزمة تطوير البرامج (SDK) الرسمية لنظام التشغيل Android.
  • بما أنّ الشرط أعلاه قد يكون صعبًا، ننصحك باستخدام نظام إدارة الحِزم في التنفيذ المرجعي لنظام التشغيل AOSP في عمليات تنفيذ الأجهزة.
  • [C-0-2] يجب أن تتيح عملية التحقّق من ملفات "‎.apk" باستخدام الإصدار 2 من مخطّط توقيع حِزم APK وتوقيع JAR.
  • [C-0-3] يجب عدم توسيع تنسيقات ‎.apk أو بيان Android أو الرمز الثنائي لنظام Dalvik أو الرمز الثنائي لـ RenderScript بطريقة تمنع تثبيت هذه الملفات وتشغيلها بشكل صحيح على الأجهزة المتوافقة الأخرى.
  • [C-0-4] يجب عدم السماح للتطبيقات غير "مُثبّت الحِزمة" الحالي بإلغاء تثبيت التطبيق بدون أي إشعار، كما هو موضّح في حزمة تطوير البرامج الخاصة بإذن 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] يجب أن تتوافق مع تنسيقات الوسائط وبرامج الترميز وفك الترميز وأنواع الملفات وتنسيقات الحاويات المحدّدة في الفقرة 5.1 لكل مُشفِّر أعلن عنه MediaCodecList.
  • [C-0-2] يجب الإفصاح عن توفّر برامج الترميز وفك الترميز المتاحة للتطبيقات التابعة لجهات خارجية والإبلاغ عنها من خلال MediaCodecList.
  • [C-0-3] يجب أن يكون بإمكانه فك ترميز جميع التنسيقات التي يمكنه ترميزها وإتاحتها للتطبيقات التابعة لجهات خارجية. ويشمل ذلك جميع سلاسل البتات التي تنشئها برامج الترميز والملفات الشخصية التي يتم الإبلاغ عنها في CamcorderProfile.

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

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

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

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

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

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

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

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

  • ‫[C-1-1] PCM/WAVE

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

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

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

  • [C-1-1] الملف الشخصي MPEG-4 AAC (AAC LC)
  • [C-1-2] ملف تعريف MPEG-4 HE AAC (AAC+)
  • [C-1-3] الملف الشخصي MPEG-4 HE AACv2 (الترميز المحسّن للصوت بترميز متقدّم)
  • ‫[C-1-4] AAC ELD (الترميز المتقدّم لصوت AAC المنخفض التأخير)
  • ‫[C-1-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) مع ميزة "النطاق الديناميكي التكيُّفي" في الإصدار 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 raw AAC (‎.aac, ADIF غير متوافقة)
  • ‫MPEG-TS (بتنسيق ‎.ts، لا يمكن تقديمه أو ترجيعه)
الملف الشخصي MPEG-4 HE AAC (AAC+) إتاحة محتوى صوت أحادي/استيريو/5.0/5.1 بمعدّلات بيانات في الملف الصوتي عادية تتراوح بين 16 و48 كيلوهرتز
الملف الشخصي MPEG-4 HE AACv2
(الترميز المحسّن للصوت بترميز متقدّم) 		إتاحة محتوى صوت أحادي/استيريو/5.0/5.1 بمعدّلات بيانات في الملف الصوتي عادية تتراوح بين 16 و48 كيلوهرتز
الترميز المتقدّم للصوت بوقت استجابة منخفض (AAC 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 كيلوبت في الثانية (معدل نقل بيانات ثابت) أو بمعدّل نقل بيانات متغيّر (VBR) MP3 ‏(‎.mp3)
MIDI نوعا MIDI 0 و1 الإصداران 1 و2 من DLS XMF وMobile XMF إتاحة تنسيقات نغمات الرنين RTTTL/RTX وOTA وiMelody
  • النوع 0 و1 (‎.mid و‎.xmf و‎.mxmf)
  • RTTTL/RTX ‏(‎.rtttl, .rtx)
  • OTA (‎.ota)
  • iMelody ‏(‎.imy)
Vorbis
  • Ogg (‎.ogg)
  • Matroska (‎.mkv, Android 4.0 والإصدارات الأحدث)
PCM/WAVE تنسيق PCM خطي بترميز 16 بت (بمعدلات تصل إلى الحد الأقصى للأجهزة) يجب أن تتوافق الأجهزة مع معدّلات أخذ العينات لتسجيل PCM الأوّلي بمعدّلات تردد 8000 و11025 و16000 و44100 هرتز. WAVE (‎.wav)
Opus Matroska (‎.mkv)، Ogg(‎.ogg)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.2.1. ‫H.263

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

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

5.2.2. ‫H-264

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

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

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

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

5.2.3. VP8

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

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

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

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

5.2.4. ‫VP9

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

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

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

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

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

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

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

5.3.1. MPEG-2

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

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

5.3.2. ‫H.263

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

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

5.3.3. MPEG-4

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

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

5.3.4. H.264

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

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

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

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

5.3.5. ‫H.265 (HEVC)

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

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

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

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

5.3.6. VP8

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

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

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

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

5.3.7. ‫VP9

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

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

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

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

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

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

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

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

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

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

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

  • التنسيق: Linear PCM، بسعة 16 بت

  • معدّلات أخذ العينات: 8000 و11025 و16000 و44100 هرتز

  • القنوات: صوت أحادي

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

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

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

  • التنسيق: Linear PCM، بسعة 16 بت

  • معدّلات أخذ العينات: 22050 و48000 هرتز
  • القنوات: صوت استيريو

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • التنسيق: Linear PCM، بسعة 16 بت
    • معدلات أخذ العينات: 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 القابلَين للتحكّم من خلال الفئتَين الفرعيتَين AudioEffect Equalizer وLoudnessEnhancer.
  • [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
  • فقدان الإدخال الجزء الأول من إشارة الإدخال غير القابلة للاستخدام أو غير المتوفّرة
  • وقت استجابة الإدخال من البداية مجموع وقت الإدخال المفقود ووقت استجابة الإدخال للإطار الأول، عندما يكون نظام إدخال الصوت غير نشط ومتوقفًا قبل الطلب
  • وقت استجابة إدخال مستمر وقت استجابة الإدخال للإطارات اللاحقة أثناء تسجيل الجهاز للصوت
  • التشويش في إخراج الفيديو غير المشغّل التباين بين القياسات المنفصلة لقيم وقت استجابة الإخراج غير المتوفّر بشكل دائم
  • التشويش في الإدخال غير المُعدّ مسبقًا التباين بين القياسات المنفصلة لقيم وقت استجابة الإدخال من خلال طلبات البحث المجانية
  • وقت استجابة مستمر للذهاب والعودة مجموع وقت استجابة الإدخال المستمر ووقت استجابة الإخراج المستمر وفترة تخزين مؤقت واحدة تسمح فترة التخزين المؤقت للتطبيق بمعالجة الإشارة والوقت الذي يحتاجه التطبيق لتقليل الفرق في الطور بين مصادر الإدخال والإخراج.
  • واجهة برمجة التطبيقات لصفيف ذاكرة التخزين المؤقت لـ PCM في OpenSL ES مجموعة واجهات برمجة تطبيقات OpenSL ES ذات الصلة بتنسيق PCM ضمن مجموعة تطوير البرامج (NDK) لنظام التشغيل Android
  • واجهة برمجة التطبيقات AAudio native audio API مجموعة واجهات برمجة تطبيقات AAudio ضمن مجموعة تطوير البرامج (NDK) لنظام التشغيل Android

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

  • [SR] وقت استجابة الإخراج على البارد بمقدار 100 ملي ثانية أو أقل
  • [SR] وقت استجابة مستمر للإخراج يبلغ 45 ملي ثانية أو أقل
  • [SR] الحدّ من التقلّبات في سرعة الإخراج عند عدم توفّر بيانات

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

  • [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] الحدّ من الارتعاش في الإدخال غير المعالج

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.

برامج ترميز الصوت:

  • الترميز المتقدّم للصوت
اطّلِع على الفقرة 5.1.1 لمعرفة تفاصيل عن الترميز المتقدّم للصوت (AAC) وأشكاله المختلفة.
الترميز المتقدّم للصوت مع إطارات ADTS وعلامات ID3 ISO 13818-7 راجِع الفقرة 5.1.1 لمعرفة تفاصيل عن الترميز المتقدّم للصوت وأنواعه.
WebVTT WebVTT

بروتوكول RTSP (بروتوكول النقل في الوقت الفعلي وبروتوكول وصف الجلسة)

اسم الملف الشخصي المراجع توافق برامج الترميز المطلوبة
‫H264 AVC RFC 6184 راجِع القسم 5.1.3 للاطّلاع على تفاصيل عن H264 AVC.
MP4A-LATM RFC 6416 راجِع الفقرة 5.1.1 لمعرفة تفاصيل عن الترميز المتقدّم للصوت وأنواعه.
‫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 لمعرفة تفاصيل عن الترميز المتقدّم للصوت وأنواعه.
MP2T RFC 2250 راجِع MPEG-2 Transport Stream ضمن "البث المباشر عبر HTTP" للاطّلاع على التفاصيل.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Android Debug Bridge ‏ (adb)

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

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

  • Dalvik Debug Monitor Service ‏ (ddms)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.1.1.1. حجم الشاشة

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

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

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

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

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

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

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

    • أعلن التطبيق أنّه يتوافق مع نسبة عرض إلى ارتفاع أكبر للشاشة من خلال قيمة البيانات الوصفية android.max_aspect.
    • يُعلِن التطبيق أنّه يمكن تغيير حجمه من خلال السمة android:resizeableActivity.
    • يستهدف التطبيق المستوى 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 نقطة لكل بوصة (دقة عالية)
    • 260 نقطة لكل بوصة (260dpi)
    • 280 نقطة لكل بوصة (280dpi)
    • 300 نقطة لكل بوصة (300dpi)
    • 320 نقطة لكل بوصة (xhdpi)
    • 340 نقطة لكل بوصة (340dpi)
    • 360 نقطة في البوصة (360dpi)
    • 400 نقطة لكل بوصة (400dpi)
    • 420 نقطة لكل بوصة (420dpi)
    • 480 نقطة لكل بوصة (xxhdpi)
    • 560 نقطة في البوصة (560dpi)
    • 640 نقطة لكل بوصة (xxxhdpi)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

‫7.1.4.1 OpenGL ES

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

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

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

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

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

  • يجب أن تتضمّن ميزة التوافق مع Vulkan 1.0.

عمليات تنفيذ الأجهزة، في حال تضمين توافق مع Vulkan 1.0:

  • [C-1-1] يجب الإبلاغ عن القيمة الصحيحة للعدد الصحيح باستخدام علامتَي ميزة android.hardware.vulkan.level وandroid.hardware.vulkan.version.
  • [C-1-2] يجب إدراج VkPhysicalDevice واحدة على الأقل لواجهة برمجة التطبيقات الأصلية Vulkan vkEnumeratePhysicalDevices() .
  • [C-1-3] يجب تنفيذ واجهات برمجة تطبيقات Vulkan 1.0 بالكامل لكل VkPhysicalDevice مُدرَج.
  • [C-1-4] يجب إدراج الطبقات، المضمّنة في المكتبات المجمّعة من رموز برمجية أصلية والتي تحمل الاسم libVkLayer*.so في دليل المكتبة المجمّعة من رموز برمجية أصلية لحزمة التطبيق، من خلال واجهات برمجة التطبيقات المجمّعة من رموز برمجية أصلية لـ Vulkan‏ vkEnumerateInstanceLayerProperties() وvkEnumerateDeviceLayerProperties() .
  • [C-1-5] يجب عدم إدراج الطبقات التي تقدّمها المكتبات خارج حزمة التطبيق، أو توفير طرق أخرى لتتبُّع Vulkan API أو اعتراضها، ما لم يتم ضبط السمة android:debuggable على القيمة true في التطبيق.
  • [C-1-6] يجب الإبلاغ عن جميع سلاسل الإضافات التي تتوافق معها من خلال واجهات برمجة التطبيقات الأصلية لـ Vulkan، وعلى العكس من ذلك، يجب عدم الإبلاغ عن سلاسل الإضافات التي لا تتوافق معها بشكل صحيح.

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

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

  • [C-0-3] يجب أن يكون متوافقًا مع واجهة برمجة التطبيقات TextureView API، ويجب أن يعرض سلوكًا متسقًا مع التنفيذ في 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] يجب أن تغطي نسبة% 100 أو أكثر من sRGB في مساحة CIE 1931 xyY، على الرغم من أنّ نطاق ألوان الشاشة غير محدّد.

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

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

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

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

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

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

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

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

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

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

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

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

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] يُنصح بشدة بعدم توفير آلية الإدخال لدالة القائمة لأنّها قد تم إيقافها نهائيًا لصالح شريط الإجراءات منذ Android 4.0.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.2.5. الإدخال باللمس الزائف

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

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

  • يجب أن يعلن عن توافقه مع علامة ميزة android.hardware.faketouch.

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

  • [C-1-1] يجب الإبلاغ عن الموضع المطلق للشاشة X وY لموضع المؤشر وعرض مؤشر مرئي على الشاشة.
  • [C-1-2] يجب الإبلاغ عن حدث اللمس باستخدام رمز الإجراء الذي يحدّد تغيير الحالة الذي يحدث على المؤشر عند الانتقال للأسفل أو للأعلى على الشاشة.
  • [C-1-3] يجب أن تتيح الأداة تحريك المؤشر للأسفل وللأعلى على عنصر على الشاشة، ما يسمح للمستخدمين بمحاكاة النقر على عنصر على الشاشة.
  • [C-1-4] يجب أن يتيح الجهاز الإشارة للأسفل والإشارة للأعلى والإشارة للأسفل ثم الإشارة للأعلى في المكان نفسه على عنصر على الشاشة خلال حد زمني معيّن، ما يسمح للمستخدمين بمحاكاة النقر مرّتين على عنصر على الشاشة.
  • [C-1-5] يجب أن يتيح الجهاز وضع المؤشر في الأسفل على نقطة عشوائية على الشاشة، ونقل المؤشر إلى أي نقطة عشوائية أخرى على الشاشة، ثم وضع المؤشر في الأعلى، ما يسمح للمستخدمين بمحاكاة السحب باللمس.
  • [C-1-6] يجب أن يتيح استخدام المؤشر للأسفل ثم السماح للمستخدمين بنقل الجسم بسرعة إلى موضع مختلف على الشاشة ثم استخدام المؤشر للأعلى على الشاشة، ما يسمح للمستخدمين برمي جسم على الشاشة.
  • [C-1-7] يجب الإبلاغ عن TOUCHSCREEN_NOTOUCH لحقل واجهة برمجة التطبيقات Configuration.touchscreen.

إذا كانت عمليات تنفيذ الأجهزة تعلن عن توافقها مع android.hardware.faketouch.multitouch.distinct، يعني ذلك ما يلي:

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

إذا كانت عمليات تنفيذ الأجهزة تعلن عن توافقها مع android.hardware.faketouch.multitouch.jazzhand، يعني ذلك ما يلي:

  • [C-3-1] يجب الإفصاح عن توافق التطبيق مع android.hardware.faketouch.
  • [C-3-2] يجب أن يتيح الجهاز تتبُّعًا متميزًا لـ 5 (تتبُّع يد مكوّنة من أصابع) أو أكثر من إشارات المؤشر بشكل مستقل تمامًا.

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

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

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

  • [C-1-1] يجب أن يكون جهاز التحكّم مضمّنًا في الجهاز أو أن يتم إرساله مع جهاز تحكّم منفصل في العلبة، ما يوفر وسائل لإدخال جميع الأحداث المدرَجة في الجداول أدناه.
  • [C-1-2] يجب أن يكون التطبيق قادرًا على ربط أحداث HID بثوابت view.InputEvent المرتبطة بها في Android كما هو موضّح في الجداول أدناه. يتضمّن تنفيذ Android من المصدر وحدات تحكّم في الألعاب تستوفي هذا الشرط.
زرّ استخدام HID2 زر Android
أ1 0x09 0x0001 KEYCODE_BUTTON_A (96)
ب1 0x09 0x0002 KEYCODE_BUTTON_B (97)
X1 0x09 0x0004 KEYCODE_BUTTON_X (99)
نعم1 0x09 0x0005 KEYCODE_BUTTON_Y (100)
أداة التوجيه لليسار واليمين للأعلى1
أداة التوجيه لليسار واليمين للأسفل1 		‎0x01 0x00393 AXIS_HAT_Y4
لوحة التحكم، السهم المتّجه لليسار1
لوحة التحكم، السهم المتّجه لليسار1 		‎0x01 0x00393 AXIS_HAT_X4
زرّ أعلى ذراع التحكّم الأيسر1 0x09 0x0007 KEYCODE_BUTTON_L1 (102)
زرّ أعلى ذراع التحكّم الأيمن1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
النقر على العصا اليسرى1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
النقر على ذراع التحكم الأيمن1 0x09 0x000F KEYCODE_BUTTON_THUMBR (107)
المنزل1 0x0c 0x0223 KEYCODE_HOME (3)
رجوع1 0x0c 0x0224 KEYCODE_BACK (4)

‫1 KeyEvent

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

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

‫4 MotionEvent

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

‫1 MotionEvent

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

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

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

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

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

  • [C-0-1] يجب الإبلاغ بدقة عن توفّر أدوات الاستشعار أو عدم توفّرها وفقًا لفئة android.content.pm.PackageManager.
  • [C-0-2] يجب أن يعرض التطبيق قائمة دقيقة بأجهزة الاستشعار المتوافقة من خلال SensorManager.getSensorList() والطُرق المشابهة.
  • [C-0-3] يجب أن تعمل بشكل معقول مع جميع واجهات برمجة التطبيقات الأخرى الخاصة بأجهزة الاستشعار (على سبيل المثال، من خلال عرض true أو false حسب الاقتضاء عندما تحاول التطبيقات تسجيل مستمعين، وعدم استدعاء مستمعي أجهزة الاستشعار عندما لا تكون أجهزة الاستشعار المقابلة متوفّرة، وما إلى ذلك).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

إذا كانت عمليات تنفيذ الأجهزة تتضمّن أداة تسارع 3 محاور وأيًا من أجهزة الاستشعار المركبة TYPE_SIGNIFICANT_MOTION وTYPE_TILT_DETECTOR وTYPE_STEP_DETECTOR وTYPE_STEP_COUNTER:

  • [C-2-1] يجب أن يكون مجموع استهلاك الطاقة أقل من 4 ملي واط في أي وقت.
  • يجب أن يكون كل منهما أقل من 2 ملي واط و0.5 ملي واط عندما يكون الجهاز في حالة ديناميكية أو ثابتة.

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

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

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

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

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

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

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

  • [C-1-1] يجب تنفيذ أداة استشعار TYPE_MAGNETIC_FIELD.
  • [C-1-2] يجب أن يكون الجهاز قادرًا على تسجيل الأحداث بمعدّل تكرار لا يقل عن 10 هرتز، ويجب أن يسجّل الأحداث بمعدّل تكرار لا يقل عن 50 هرتز.
  • [C-1-3] يجب أن تكون متوافقة مع نظام إحداثيات أدوات استشعار Android كما هو موضّح بالتفصيل في واجهات برمجة تطبيقات Android.
  • [C-1-4] يجب أن يكون الجهاز قادرًا على قياس القيم بين -900 و+900 ميكرو تسلا على كل محور قبل الوصول إلى التشبع.
  • [C-1-5] يجب أن تكون قيمة إزاحة الحديد الصلب أقل من 700 ميكرو تسلا، ويجب أن تكون القيمة أقل من 200 ميكرو تسلا، وذلك من خلال وضع مقياس المغناطيسية بعيدًا عن الحقول المغناطيسية الديناميكية (المُنشأة بالتيار الكهربي) والثابتة (المُنشأة بالمغناطيس).
  • [C-1-6] يجب أن تكون درجة الدقة مساوية أو أعلى من 0.6 ميكرو تسلا.
  • [C-1-7] يجب أن تتيح المعايرة على الإنترنت وتعويض الانحياز الحديدي الصلب، والحفاظ على مَعلمات التعويض بين عمليات إعادة تشغيل الجهاز.
  • [C-1-8] يجب تطبيق التعويض عن الحديد اللين، ويمكن إجراء المعايرة أثناء الاستخدام أو أثناء إنتاج الجهاز.
  • [C-1-9] يجب أن يكون الانحراف المعياري، الذي يتم احتسابه لكل محور من خلال العينات التي تم جمعها على مدار فترة لا تقل عن 3 ثوانٍ بأعلى معدّل لأخذ العينات، لا يزيد عن 1.5 ميكرو تسلا، ويجب أن يكون الانحراف المعياري لا يزيد عن 0.5 ميكرو تسلا.
  • يجب تنفيذ أداة استشعار TYPE_MAGNETIC_FIELD_UNCALIBRATED.
  • [SR] يُنصح بشدة باستخدام أجهزة Android الحالية والجديدة لتطبيق أداة استشعار TYPE_MAGNETIC_FIELD_UNCALIBRATED.

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

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

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

  • يجوز تنفيذ أداة استشعار TYPE_GEOMAGNETIC_ROTATION_VECTOR.

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

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

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

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

  • يجب أن يتضمّن جهاز استقبال نظام تحديد المواقع العالمي (GPS) أو نظام تحديد المواقع العالمي (GNSS).

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

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

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

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

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 sensor والإبلاغ عنه.
  • [C-1-2] يجب أن يكون الجهاز قادرًا على إرسال الأحداث بمعدّل 5 هرتز أو أكثر.
  • [C-1-3] يجب أن يكون مصحوبًا بمُعدِّل حرارة.
  • [SR] يُنصح بشدة بإمكانية تسجيل قياسات الضغط في النطاق من 300hPa إلى 1100hPa.
  • يجب أن تكون الدقة المطلقة 1hPa.
  • يجب أن تكون الدقة النسبية 0.12hPa على نطاق 20hPa (أي ما يعادل دقة متر واحد تقريبًا على نطاق 200 متر تقريبًا على مستوى سطح البحر).

7.3.6. مقياس درجة الحرارة

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

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

  • [C-1-1] يجب أن يتم تعريفه على أنّه SENSOR_TYPE_AMBIENT_TEMPERATURE ويجب أن يقيس درجة الحرارة المحيطة (الغرفة/مقصورة المركبة) من حيث يتفاعل المستخدم مع الجهاز بالدرجات المئوية.
  • [C-1-2] يجب تحديده على أنّه SENSOR_TYPE_TEMPERATURE.
  • [C-1-3] يجب قياس درجة حرارة وحدة المعالجة المركزية للجهاز.
  • [C-1-4] يجب عدم قياس أي درجة حرارة أخرى.

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

7.3.7. مقياس الإضاءة

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

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

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

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

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

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

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

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

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

  • [C-2-1] يجب أن يتضمّن جهازك أداة استشعار TYPE_ACCELEROMETER تستوفي الشروط التالية:

    • يجب أن يكون نطاق القياس بين -8 غرام و+8 غرام على الأقل.
    • يجب أن يكون دقة القياس 1024 LSB/G على الأقل.
    • يجب أن يكون الحد الأدنى لعدد مرات القياس 12.5 هرتز أو أقل.
    • يجب أن يكون الحد الأقصى لعدد مرات القياس 400 هرتز أو أعلى.
    • يجب أن يكون التشويش في القياس أقل من 400 ميكرو غاوس/√هرتز.
    • يجب استخدام شكل غير مُشغِّل لهذا المستشعر مع إمكانية تخزين مؤقت لما لا يقل عن 3000 حدث مستشعر.
    • يجب أن يكون استهلاك الطاقة في وضع "المعالجة المجمّعة" لا يزيد عن 3 ملي واط.
    • يجب أن يكون هناك ثبات في خطأ التشويش الثابت الذي يقل عن 15 μg √Hz من مجموعة البيانات الثابتة التي تبلغ مدتها 24 ساعة.
    • من المفترض أن يكون هناك تغيير في الانحياز مقابل درجة الحرارة بمقدار ‎1mg / °C أو أقل أو أكثر.
    • يجب أن يكون خط أفضل الملاءمة غير خطي بنسبة ≤ 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 درجة / ثانية / درجة مئوية.
    • يجب أن يكون هناك تغيير في الحساسية مقارنةً بدرجة الحرارة لا يتجاوز 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 uT على الأقل.
    • يجب أن يكون دقة القياس 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 hPa على الأقل.
    • يجب أن يكون دقة القياس 80 LSB/hPa على الأقل.
    • يجب أن يكون الحد الأدنى لعدد مرات القياس 1 هرتز أو أقل.
    • يجب أن يكون الحد الأقصى لعدد مرات القياس 10 هرتز أو أعلى.
    • يجب أن يكون التشويش في القياس أقل من 2 باسكال/√هرتز.
    • يجب استخدام شكل غير مُشغِّل لهذا المستشعر مع قدرة تخزين مؤقت لا تقل عن 300 حدث مستشعر.
    • يجب أن يكون استهلاك الطاقة في وضع "المعالجة المجمّعة" لا يزيد عن 2 ملي واط.
  • [C-2-8] يجب أن يتضمّن جهاز استشعار TYPE_GAME_ROTATION_VECTOR يستوفي الشروط التالية:
    • يجب استخدام شكل غير مُشغِّل لهذا المستشعر مع قدرة تخزين مؤقت لا تقل عن 300 حدث مستشعر.
    • يجب أن يكون استهلاك الطاقة في وضع "المعالجة المجمّعة" لا يزيد عن 4 ملي واط.
  • [C-2-9] يجب أن يتضمّن التطبيق أداة استشعار TYPE_SIGNIFICANT_MOTION تستوفي الشروط التالية:
    • يجب أن يكون استهلاك الطاقة أقل من 0.5 ملي واط عندما يكون الجهاز ثابتًا و1.5 ملي واط عندما يكون الجهاز متحركًا.
  • [C-2-10] يجب أن يتضمّن جهاز استشعار TYPE_STEP_DETECTOR ما يلي:
    • يجب تنفيذ شكل غير نشط من أداة الاستشعار هذه مع إمكانية تخزين مؤقت لما لا يقل عن 100 حدث أداة استشعار.
    • يجب أن يكون استهلاك الطاقة أقل من 0.5 ملي واط عندما يكون الجهاز ثابتًا و1.5 ملي واط عندما يكون الجهاز متحركًا.
    • يجب أن يكون استهلاك الطاقة في وضع "المعالجة المجمّعة" لا يزيد عن 4 ملي واط.
  • [C-2-11] يجب أن يتضمّن جهاز استشعار TYPE_STEP_COUNTER يستوفي الشروط التالية:
    • يجب أن يكون استهلاك الطاقة أقل من 0.5 ملي واط عندما يكون الجهاز ثابتًا و1.5 ملي واط عندما يكون الجهاز متحركًا.
  • [C-2-12] يجب أن يتضمّن التطبيق أداة استشعار TILT_DETECTOR تستوفي الشروط التالية:
    • يجب أن يكون استهلاك الطاقة أقل من 0.5 ملي واط عندما يكون الجهاز ثابتًا و1.5 ملي واط عندما يكون الجهاز متحركًا.
  • [C-2-13] يجب أن يكون الطابع الزمني للحدث المادي نفسه الذي يُبلغ عنه مقياس التسارع ومستشعر الدوران والمقياس المغناطيسي ضمن 2.5 ملي ثانية من بعضها.
  • [C-2-14] يجب أن تتضمّن الطوابع الزمنية لأحداث أداة استشعار الدوران قاعدة زمنية مماثلة لقاعدة النظام الفرعي للكاميرا ويجب ألا يتجاوز الخطأ ملي ثانية واحدة.
  • [C-2-15] يجب إرسال عيّنات إلى التطبيقات في غضون 5 مللي ثانية من وقت توفّر البيانات على أي من أجهزة الاستشعار المادية المذكورة أعلاه إلى التطبيق.
  • [C-2-16] يجب ألا يتجاوز استهلاك الطاقة 0.5 ملي واط عندما يكون الجهاز ثابتًا و2.0 ملي واط عندما يكون الجهاز متحركًا عند تفعيل أي مجموعة من أجهزة الاستشعار التالية:
    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS
  • [C-2-17] يجوز أن يتضمّن جهاز التحكّم في الطاقة TYPE_PROXIMITY، ولكن في حال توفّره، يجب أن يكون الحد الأدنى لسعة المخزن المؤقت 100 حدث من أحداث أجهزة الاستشعار.

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

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

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

7.3.10. أداة استشعار بصمة الإصبع

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

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

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

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

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

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

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

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

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

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

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

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

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

  • يجب أن تتضمّن تقنية Wi-Fi Direct (الاتصال المباشر عبر Wi-Fi).

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-2-1] يجب أن يؤدي تنفيذ واجهات برمجة التطبيقات WifiManager ذات الصلة بـ Passpoint إلى طرح UnsupportedOperationException.

7.4.3. البلوتوث

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

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

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

  • [C-1-1] يجب أن يكون الجهاز متوافقًا مع معيار Bluetooth 4.2 وBluetooth LE Data Length Extension.

يتيح نظام Android استخدام البلوتوث والبلوتوث المنخفض الطاقة.

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

  • [C-2-1] يجب الإفصاح عن ميزات المنصة ذات الصلة (android.hardware.bluetooth وandroid.hardware.bluetooth_le على التوالي) وتنفيذ واجهات برمجة تطبيقات المنصة.
  • يجب تنفيذ الملفات الشخصية ذات الصلة بالبلوتوث، مثل A2DP و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] يُنصح بشدة بتطبيق مهلة لعنوان IP الخاص القابل للحل (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 Forum (على النحو المحدّد في المواصفة الفنية NFCForum-TS-DigitalProtocol-1.0) من خلال معايير NFC التالية:
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • أنواع علامات NFC التي حدّدها المنتدى 1 و2 و3 و4 و5

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • قد تتضمّن إتاحة استخدام كاميرا خارجية قد لا تكون متصلة دائمًا.

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

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

7.5.4. سلوك Camera API

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

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

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

  • [C-0-1] يجب استخدام android.hardware.PixelFormat.YCbCr_420_SP لمعاينة البيانات المقدَّمة إلى عمليات استدعاء التطبيق عندما لم يسبق للتطبيق استدعاء android.hardware.Camera.Parameters.setPreviewFormat(int).
  • [C-0-2] يجب أن يكون android.hardware.Camera.PreviewCallback أيضًا بتنسيق ترميز NV21 عندما يسجِّل أحد التطبيقات مثيلًا من android.hardware.Camera.PreviewCallback ويطلب النظام طريقة onPreviewFrame() ويكون تنسيق المعاينة هو YCbCr_420_SP، ويتم تمرير البيانات في صفيف البايت إلى onPreviewFrame(). وهذا يعني أنّه يجب أن يكون NV21 هو الإعداد التلقائي.
  • [C-0-3] يجب أن يكون الجهاز متوافقًا مع تنسيق YV12 (كما هو موضّح في الثابت android.graphics.ImageFormat.YV12) لمعاينات الكاميرا لكل من الكاميرا الأمامية والخلفية في android.hardware.Camera. (قد يستخدم برنامج ترميز الفيديو والكاميرا أي تنسيق أصلي للبكسل، ولكن يجب أن يتيح تنفيذ الجهاز التحويل إلى YV12).
  • [C-0-4] يجب أن تتوافق مع تنسيقَي android.hardware.ImageFormat.YUV_420_888 وandroid.hardware.ImageFormat.JPEG كمخرجات من خلال واجهة برمجة التطبيقات android.media.ImageReader لأجهزة android.hardware.camera2 التي تعلن عن قدرة REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE في android.request.availableCapabilities.
  • [C-0-5] يجب أن يظلّ تطبيقك يوفّر Camera API الكاملة المضمّنة في مستندات حزمة تطوير البرامج (SDK) لنظام Android، بغض النظر عمّا إذا كان الجهاز يتضمّن ميزة ضبط التركيز التلقائي للأجهزة أو ميزات أخرى. على سبيل المثال، يجب أن تظل الكاميرات التي لا تتضمّن ميزة ضبط التركيز التلقائي تستدعي أيّ نُسخ مسجّلة من android.hardware.Camera.AutoFocusCallback (على الرغم من أنّ هذا ليس له صلة بالكاميرات التي لا تتضمّن ميزة ضبط التركيز التلقائي). يُرجى العِلم أنّ ذلك ينطبق على الكاميرات الأمامية. على سبيل المثال، على الرغم من أنّ معظم الكاميرات الأمامية لا توفّر ميزة التركيز التلقائي، يجب أن تظلّ عمليات استدعاء واجهة برمجة التطبيقات "مزوّرة" كما هو موضّح.
  • [C-0-6] يجب أن يتعرّف على كل اسم مَعلمة محدّد كثابت في فئة android.hardware.Camera.Parameters ويحترمه. في المقابل، يجب ألا تلتزم عمليات تنفيذ الأجهزة بثوابت السلاسل التي يتم تمريرها إلى طريقة android.hardware.Camera.setParameters() أو تتعرّف عليها، باستثناء تلك التي تم توثيقها كثوابت في android.hardware.Camera.Parameters. وهذا يعني أنّه يجب أن تتوافق عمليات تنفيذ الأجهزة مع جميع مَعلمات الكاميرا العادية إذا كان الجهاز يسمح بذلك، ويجب ألّا تتوافق مع أنواع مَعلمات الكاميرا المخصّصة. على سبيل المثال، يجب أن تتيح عمليات تنفيذ الأجهزة التي تتيح التقاط الصور باستخدام تقنيات التصوير بنطاق عالي الديناميكية (HDR) مَعلمة الكاميرا Camera.SCENE_MODE_HDR.
  • [C-0-7] يجب الإبلاغ عن المستوى المناسب من التوافق مع السمة android.info.supportedHardwareLevel كما هو موضّح في حزمة تطوير البرامج (SDK) لنظام التشغيل Android والإبلاغ عن رموز وضع ميزات إطار العمل المناسبة.
  • [C-0-8] يجب أيضًا الإفصاح عن إمكانات الكاميرا الفردية الخاصة بـ android.hardware.camera2 من خلال السمة android.request.availableCapabilities والإفصاح عن رموز الميزات المناسبة، ويجب تحديد رمز الميزة إذا كانت أي من أجهزة الكاميرا المرفقة تتيح الميزة.
  • [C-0-9] يجب بث نية Camera.ACTION_NEW_PICTURE كلما التقطت الكاميرا صورة جديدة وتمّت إضافة إدخال الصورة إلى "متجر الوسائط".
  • [C-0-10] يجب بث نية Camera.ACTION_NEW_VIDEO كلما سجّلت الكاميرا فيديو جديدًا وتمّت إضافة إدخال الصورة إلى "متجر الوسائط".

7.5.5. اتجاه الكاميرا

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

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

7.6. الذاكرة ومساحة التخزين

7.6.1. الحد الأدنى للذاكرة ومساحة التخزين

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

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

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

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

  • [C-0-1] يجب أن يوفّر الجهاز مساحة تخزين يمكن للتطبيقات مشاركتها، ويُشار إليها غالبًا أيضًا باسم "مساحة التخزين الخارجية المشتركة" أو "مساحة التخزين المشتركة للتطبيقات" أو باسم مسار Linux‏ "‎/sdcard" الذي يتم تثبيتها عليه.
  • [C-0-2] يجب ضبطه باستخدام مساحة تخزين مشتركة يتم تثبيتها تلقائيًا، بعبارة أخرى "جاهز للاستخدام"، بغض النظر عمّا إذا تم تنفيذ مساحة التخزين على مكوّن تخزين داخلي أو وسيط تخزين قابل للإزالة (مثل فتحة بطاقة Secure Digital).
  • [C-0-3] يجب ربط مساحة التخزين المشتركة للتطبيق مباشرةً على مسار Linux sdcard أو تضمين رابط رمزي لنظام التشغيل Linux من sdcard إلى نقطة الربط الفعلية.
  • [C-0-4] يجب فرض إذن android.permission.WRITE_EXTERNAL_STORAGE على مساحة التخزين المشتركة هذه كما هو موضّح في حزمة تطوير البرامج (SDK). ويجب أن تكون مساحة التخزين المشتركة قابلة للكتابة من قِبل أي تطبيق يحصل على هذا الإذن.

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

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

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

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

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

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

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

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

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

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

7.7.2. وضع مضيف USB

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

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

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

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

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

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

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

  • [C-4-1] يجب تنفيذ وظيفة منفذ Dual Role Port كما هو محدّد في مواصفة USB Type-C (الفقرة 4.5.1.3.3).
  • [SR] يُنصح بشدة بتوفير منفذ DisplayPort، ويجب أن يتوافق مع معدلات نقل البيانات بمعيار SuperSpeed USB، ويُنصح بشدة بتوفير ميزة "إرسال الطاقة" لتبديل دور نقل البيانات ونقل الطاقة.
  • [SR] يُنصح بشدة بعدم إتاحة "وضع ملحق محوِّل الصوت" كما هو موضّح في "الملحق أ" من المراجعة 1.2 لمواصفات كابل USB من النوع C وموصّله.
  • يجب تنفيذ نموذج Try.* الأنسب لشكل الجهاز. على سبيل المثال، يجب أن ينفذ الجهاز المحمول طراز Try.SNK.

7.8. الصوت

7.8.1. الميكروفون

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

  • [C-1-1] يجب الإبلاغ عن ثابت الميزة android.hardware.microphone.
  • [C-1-2] يجب استيفاء متطلبات التسجيل الصوتي الواردة في الفقرة 5.4.
  • [C-1-3] يجب استيفاء متطلبات وقت استجابة الصوت في الفقرة 5.6.
  • [SR] يُنصح بشدة بتوفير إمكانية تسجيل الصوت بالقرب من ترددات فوق الصوتية كما هو موضّح في الفقرة 7.8.3.

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

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

7.8.2. إخراج الصوت

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

  • [C-1-1] يجب الإبلاغ عن ثابت الميزة android.hardware.audio.output.
  • [C-1-2] يجب أن تستوفي متطلبات تشغيل الصوت الواردة في الفقرة 5.5.
  • [C-1-3] يجب استيفاء متطلبات وقت استجابة الصوت في الفقرة 5.6.
  • [SR] يُنصح بشدة بتوفير ميزة تشغيل الصوت بالقرب من الحد الأقصى المسموح به كما هو موضّح في الفقرة 7.8.3.

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

  • [C-2-1] يجب عدم الإبلاغ عن ميزة android.hardware.audio.output.
  • [C-2-2] يجب تنفيذ واجهات برمجة التطبيقات ذات الصلة بإخراج الصوت كعمليات لا تؤدي إلى أيّ إجراء على الأقل.

لأغراض هذا القسم، "منفذ الإخراج" هو واجهة مادية، مثل مقبس صوت مقاس 3.5 ملم أو منفذ HDMI أو منفذ وضع مضيف USB مع فئة صوت USB. لا يُعدّ توفُّر مخرج صوت عبر بروتوكولات تستند إلى البث اللاسلكي، مثل البلوتوث أو شبكة Wi-Fi أو شبكة الجوّال، مؤهلاً لتضمين "منفذ إخراج".

7.8.2.1. منافذ الصوت التناظري

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

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

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

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

  • [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 بدقة 3840×2160 بمعدل 30 لقطة في الثانية أو 40 ميغابت في الثانية على الأقل (أي ما يعادل 4 عمليات ترميز بدقة 1920×1080 بمعدل 30 لقطة في الثانية أو 10 ميغابت في الثانية أو عمليتَي ترميز بدقة 1920×1080 بمعدل 60 لقطة في الثانية أو 20 ميغابت في الثانية).
  • [C-1-12] يجب أن يكون متوافقًا مع HEVC وVP9، ويجب أن يكون قادرًا على فك ترميز 1920×1080 بمعدّل 10 ميغابت في الثانية بمعدل 30 لقطة في الثانية على الأقل، ويجب أن يكون قادرًا على فك ترميز 3840×2160 بمعدّل 20 ميغابت في الثانية بمعدل 30 لقطة في الثانية على الأقل (أي ما يعادل 4 عمليات فك ترميز بدقة 1920×1080 بمعدّل 5 ميغابت في الثانية بمعدل 30 لقطة في الثانية).
  • [C-1-13] يجب أن تكون متوافقة مع واجهة برمجة التطبيقات HardwarePropertiesManager.getDeviceTemperatures وأن تعرض قيمًا دقيقة لدرجة حرارة الجلد.
  • [C-1-14] يجب أن يكون الجهاز مزوّدًا بشاشة مدمجة، ويجب أن تكون درجة دقتها FullHD(1080p) على الأقل، ويُنصح بشدة أن تكون QuadHD (1440p) أو أعلى.
  • [C-1-15] يجب أن يتم تعديل الشاشة بمعدّل 60 هرتز على الأقل أثناء استخدام "وضع الواقع الافتراضي".
  • [C-1-16] يجب أن يكون وقت استجابة الشاشة (كما يتم قياسه في وقت التبديل من الرمادي إلى الرمادي، والأبيض إلى الأسود، والأسود إلى الأبيض) أقل من 6 مللي ثانية.
  • [C-1-17] يجب أن تتيح الشاشة وضعًا بفترة بقاء منخفضة لا تزيد عن 5 مللي ثانية، ويتم تعريف فترة البقاء على أنّها المدة التي يُصدر فيها وحدات البكسل ضوءًا.
  • [C-1-18] يجب أن يكون متوافقًا مع معيار Bluetooth 4.2 وإضافة طول البيانات في Bluetooth LE الفقرة 7.4.3.
  • [C-1-19] يجب أن يتيح التطبيق الإبلاغ بشكل صحيح عن نوع القناة المباشرة لجميع أنواع أجهزة الاستشعار التلقائية التالية:
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED
  • [C-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 أيًا من أوضاع الطاقة الأربعة للاستعداد أو جميعها كما هو محدّد في واجهة Advanced Configuration and Power Interface (ACPI).

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

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

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

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

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

  • [SR] يُنصح بشدة بتقديم ملف تعريف للطاقة لكل مكوّن يحدِّد قيمة الاستهلاك الحالي لكل مكوّن من مكونات الجهاز ومعدل استنزاف البطارية التقريبي الذي تتسبّب فيه المكوّنات بمرور الوقت، كما هو موضّح في موقع "مشروع Android المفتوح المصدر" الإلكتروني.
  • [SR] يُنصح بشدة بالإبلاغ عن جميع قيم استهلاك الطاقة بالمللي أمبير ساعة (mAh).
  • [SR] يُنصح بشدة بالإبلاغ عن استهلاك طاقة وحدة المعالجة المركزية لكل معرّف مستخدم لكل عملية. يستوفي "مشروع مفتوح المصدر لنظام Android" المتطلّبات من خلال تنفيذ وحدة نواة uid_cputime.
  • [SR] يُنصح بشدة بإتاحة استخدام الطاقة هذا من خلال أمر shell‏ adb shell dumpsys batterystats لمطوّر التطبيق.
  • يجب أن يُنسَب إلى مكوّن الجهاز نفسه في حال تعذّر تحديد تطبيق معيّن كمصدر استهلاك الطاقة في مكوّن الجهاز.

8.5. الأداء المتسق

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

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

  • [C-0-1] يجب الإبلاغ عن توفّر "وضع الأداء المستدام" بدقة من خلال طريقة واجهة برمجة التطبيقات PowerManager.isSustainedPerformanceModeSupported().

  • يجب أن يكون متوافقًا مع "وضع الأداء المستدام".

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

  • [C-1-1] يجب أن يقدّم التطبيق الأهم في المقدّمة مستوى أداء ثابتًا لمدة 30 دقيقة على الأقل عندما يطلب ذلك.
  • [C-1-2] يجب الالتزام بواجهة برمجة التطبيقات Window.setSustainedPerformanceMode() وواجهات برمجة التطبيقات الأخرى ذات الصلة.

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

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

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

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

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

  • [C-3-1] يجب أن تعرض قائمة فارغة من خلال طريقة واجهة برمجة التطبيقات Process.getExclusiveCores().

9. توافق نموذج الأمان

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

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

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

9.1. الأذونات

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

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

  • يجوز إضافة أذونات إضافية، شرط ألا تكون سلاسل أرقام تعريف الأذونات الجديدة في مساحة الاسم android.\*.

  • [C-0-2] يجب عدم منح الأذونات التي لها protectionLevel‏PROTECTION_FLAG_PRIVILEGED إلا للتطبيقات المحمَّلة مسبقًا في المسارات المميّزة لصورة النظام وضمن المجموعة الفرعية من الأذونات المدرَجة في القائمة المسموح بها لكل تطبيق. يستوفي تطبيق AOSP هذا الشرط من خلال قراءة الأذونات المدرَجة في القائمة المسموح بها لكل تطبيق من الملفات في مسار etc/permissions/ واستخدام مسار system/priv-app كمسار مميّز.

إنّ الأذونات التي يكون مستوى حمايتها خطيرًا هي أذونات وقت التشغيل. تطلب التطبيقات التي تحتوي على targetSdkVersion > 22 هذه الأذونات أثناء التشغيل.

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

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

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

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

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

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

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

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

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

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

  • [C-0-8] عند تثبيت التطبيقات، يجب أن تحصل أوقات التشغيل البديلة على موافقة المستخدم على أذونات Android التي يستخدمها التطبيق.

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

  • [C-0-10] عندما لا تسجِّل بيئة التشغيل إمكانات التطبيق بهذه الطريقة، يجب أن تُدرِج بيئة التشغيل جميع الأذونات التي يمتلكها وقت التشغيل نفسه عند تثبيت أي تطبيق يستخدم وقت التشغيل هذا.

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

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

9.5. ميزة "الوصول المتعدد"

يتضمّن Android إمكانية استخدام عدّة مستخدمين ويوفّر إمكانية عزل المستخدمين بالكامل.

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

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

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

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

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

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

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

9.6 تحذير بشأن الرسائل القصيرة برسوم إضافية

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

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

  • [C-1-1] يجب تحذير المستخدمين قبل إرسال رسالة SMS إلى الأرقام التي تم تحديدها من خلال التعبيرات العادية المحدّدة في ملف /data/misc/sms/codes.xml على الجهاز. يقدّم مشروع Android Open Source Project الإصدار الأصلي الذي يستوفي هذا الشرط.

9.7. ميزات أمان النواة

يتضمّن "وضع الحماية في Android" ميزات تستخدِم نظام التحكّم الإجباري في الوصول (MAC) في نظام التشغيل Security-Enhanced Linux (SELinux) ووضع الحماية seccomp وميزات أمان أخرى في نواة Linux. عمليات التنفيذ على الأجهزة:

  • [C-0-1] يجب الحفاظ على التوافق مع التطبيقات الحالية، حتى في حال تنفيذ SELinux أو أي ميزات أمان أخرى ضمن إطار عمل Android.
  • [C-0-2] يجب ألّا تتضمّن واجهة مستخدم مرئية عند رصد انتهاك أمني وحظره بنجاح من خلال ميزة الأمان المُطبَّقة أسفل إطار عمل Android، ولكن يجوز أن تتضمّن واجهة مستخدم مرئية عند حدوث انتهاك أمني غير محظور يؤدي إلى استغلال ناجح.
  • [C-0-3] يجب عدم السماح للمستخدم أو مطوّر التطبيقات بضبط SELinux أو أي ميزات أمان أخرى تم تنفيذها أسفل إطار عمل Android.
  • [C-0-4] يجب عدم السماح لتطبيق يمكنه التأثير في تطبيق آخر من خلال واجهة برمجة تطبيقات (مثل Device Administration API) بضبط سياسة تؤدي إلى إيقاف التوافق.
  • [C-0-5] يجب تقسيم إطار عمل الوسائط إلى عمليات متعددة لكي يكون من الممكن منح إذن الوصول لكل عملية بشكل أكثر تقييدًا على النحو الموضَّح في الموقع الإلكتروني لمشروع Android Open Source Project.
  • [C-0-6] يجب تنفيذ آلية وضع التطبيقات في بيئة معزولة للنواة تسمح بفلترة طلبات النظام باستخدام سياسة قابلة للضبط من البرامج المتعدّدة المواضيع. يستوفي مشروع Android Open Source Project هذا الشرط من خلال تفعيل seccomp-BPF مع مزامنة مجموعة المواضيع (TSYNC) كما هو موضّح في قسم "إعدادات kernel" على source.android.com.

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

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

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

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

9.8. الخصوصية

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

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

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

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

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

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

إذا كانت عمليات تنفيذ الأجهزة تتضمّن آلية مفعّلة تلقائيًا من خارج العلبة لتوجيه حركة بيانات الشبكة من خلال خادم وكيل أو بوابة شبكة VPN (على سبيل المثال، التحميل المُسبَق لخدمة VPN مع منح android.permission.CONTROL_VPN)، يجب استيفاء الشروط التالية:

  • [C-2-1] يجب طلب موافقة المستخدم قبل تفعيل هذه الآلية، ما لم يفعّل وحدة التحكّم في سياسة الجهاز شبكة VPN هذه من خلال DevicePolicyManager.setAlwaysOnVpnPackage()، وفي هذه الحالة لا يحتاج المستخدم إلى تقديم موافقة منفصلة، ولكن يجب إعلامه فقط.

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

  • [C-3-1] يجب إيقاف ميزة المستخدم هذه للتطبيقات التي لا تتوافق مع خدمة شبكة VPN المفعَّلة دائمًا في ملف AndroidManifest.xml من خلال ضبط السمة SERVICE_META_DATA_SUPPORTS_ALWAYS_ON على false.

9.9. تشفير مساحة تخزين البيانات

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

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

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

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

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

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

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

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

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

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

يقدّم مشروع Android Open Source الإصدار الأصلي من هذه الميزة استنادًا إلى ميزة التشفير 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 Open Source الإصدار الأصلي من هذه الميزة، استنادًا إلى ميزة 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" رمزًا تنفيذيًا مفضّلاً لهذه الميزة في مستودع 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" في منطقة معزولة بشكل آمن عن الرمز البرمجي الذي يتم تشغيله على النواة والإصدارات الأحدث. يجب أن تحظر ميزة "العزل الآمن" جميع الآليات المحتمَلة التي يمكن من خلالها لرمز kernel أو مساحة المستخدم الوصول إلى الحالة الداخلية للبيئة المعزولة، بما في ذلك DMA. يستوفي "المشروع المفتوح المصدر لنظام Android" (AOSP) هذا الشرط من خلال استخدام عملية تنفيذ Trusty، ولكن هناك خيارات بديلة تشمل حلًا آخر يستند إلى ARM TrustZone أو عملية تنفيذ آمنة تمت مراجعتها من قِبل جهة خارجية لتوفير عزل مناسب يستند إلى أداة إدارة الأجهزة الافتراضية.
  • [C-1-3] يجب إجراء مصادقة شاشة القفل في بيئة التنفيذ المعزولة، والسماح باستخدام المفاتيح المرتبطة بالمصادقة فقط عند نجاحها. يجب تخزين بيانات اعتماد شاشة القفل بطريقة لا تسمح إلا لبيئات التنفيذ المعزولة بإجراء مصادقة شاشة القفل. يقدّم مشروع Android Open Source Project Gatekeeper Hardware Abstraction Layer (HAL) وTrusty، ويمكن استخدامهما لاستيفاء هذا الشرط.
  • [C-1-4] يجب أن يكون متوافقًا مع مصادقة المفتاح حيث يكون مفتاح التوقيع للمصادقة محميًا بأجهزة آمنة ويتم إجراء التوقيع في أجهزة آمنة. يجب مشاركة مفاتيح توقيع الإثبات على مستوى عدد كبير بما يكفي من الأجهزة لمنع استخدام المفاتيح كمعرّفات للأجهزة. وإحدى الطرق لاستيفاء هذا الشرط هي مشاركة مفتاح الإثبات نفسه ما لم يتم إنتاج 100,000 وحدة على الأقل من رمز تخزين تعريفي معيّن. إذا تم إنتاج أكثر من 100,000 وحدة من رمز التخزين التعريفي، قد يتم استخدام مفتاح مختلف لكل 100,000 وحدة.

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

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] يجب إيقاف هذا الخيار عندما يضبط تطبيق "وحدة التحكّم بسياسة الجهاز" سياسة جودة كلمة المرور من خلال طريقة DevicePolicyManager.setPasswordQuality() باستخدام ثابت جودة أكثر تقييدًا من PASSWORD_QUALITY_SOMETHING.

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

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

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

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

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

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

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

9.12. حذف البيانات

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

  • [C-0-1] يجب أن يوفّر التطبيق للمستخدمين آلية لإجراء "إعادة الضبط على الإعدادات الأصلية".
  • [C-0-2] يجب حذف جميع البيانات التي أنشأها المستخدم. ويعني ذلك أنّه يتم احتساب جميع البيانات باستثناء ما يلي:
    • صورة النظام
    • أي ملفات نظام تشغيل مطلوبة لصورة النظام
  • [C-0-3] يجب حذف البيانات بطريقة تتوافق مع معايير الصناعة ذات الصلة، مثل NIST SP800-88.
  • [C-0-4] يجب بدء عملية "إعادة الضبط على الإعدادات الأصلية" المذكورة أعلاه عند استدعاء واجهة برمجة التطبيقات DevicePolicyManager.wipeData() من خلال تطبيق "وحدة التحكّم بسياسة الجهاز" للمستخدم الأساسي.
  • قد يوفّر خيارًا سريعًا لمحو البيانات لا يؤدي إلا إلى محو البيانات المنطقية.

9.13. وضع التشغيل الآمن

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

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

  • [SR] STRONGLY RECOMMENDED to implement Safe Boot Mode.

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

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

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

  • يجب أن يوفّر للمستخدم خيارًا للدخول إلى "وضع التشغيل الآمن" من قائمة التشغيل باستخدام سير عمل مختلف عن سير عمل التشغيل العادي.

9.14. عزل نظام المركبات الآلية

من المتوقّع أن تتبادل أجهزة Android Automotive البيانات مع الأنظمة الفرعية المهمة للمركبة باستخدام HAL للمركبة لإرسال الرسائل واستلامها عبر شبكات المركبات، مثل ناقل CAN.

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

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

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

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

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

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

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

10.2. أداة إثبات ملكية CTS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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