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

‫1. مقدّمة

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

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

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

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

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

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

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

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

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

يحتوي القسم 2 على جميع المتطلبات التي تنطبق على نوع جهاز معيّن. يتم تخصيص كل قسم فرعي من القسم 2 لنوع جهاز معيّن.

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

‫1.1.2 معرّف المتطلبات

يتم تعيين معرّف المتطلبات للمتطلبات الإلزامية.

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

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

• معرّف نوع الجهاز (يمكنك الاطّلاع على مزيد من المعلومات في 2. أنواع الأجهزة)
  • C: Core (المتطلبات التي يتم تطبيقها على أي عمليات تنفيذ لأجهزة Android)
  • H: جهاز Android محمول
  • T: جهاز تلفزيون Android
  • ج: عملية إعداد Android Automotive
  • W: Android Watch implementation
  • علامة التبويب: تنفيذ الأجهزة اللوحية التي تعمل بنظام التشغيل Android
• رقم تعريف الحالة
  • عندما يكون الشرط غير مشروط، يتم ضبط رقم التعريف هذا على 0.
  • عندما يكون الشرط مشروطًا، يتم تعيين الرقم 1 للشرط الأول، ويزداد الرقم بمقدار 1 ضمن القسم نفسه ونوع الجهاز نفسه.
• معرّف المتطلبات
  • يبدأ هذا المعرّف من 1 ويزيد بمقدار 1 ضمن القسم نفسه والشرط نفسه.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.1. الأجهزة

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

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

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

• [7.1.4.5/H-1-1] يجب الإعلان عن إمكانية استخدام الإضافات EGL_EXT_gl_colorspace_bt2020_pq وEGL_EXT_surface_SMPTE2086_metadata وEGL_EXT_surface_CTA861_3_metadata وVK_EXT_swapchain_colorspace وVK_EXT_hdr_metadata.

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

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

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

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

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

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

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

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

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

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

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

• [7.3.11/H-SR] يُنصح بتوفير دعم لجهاز استشعار الوضع مع 6 درجات حرية.
• [7.4.3/H] يجب أن يتضمّن دعمًا لتقنيتَي Bluetooth وBluetooth LE.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [7.8.2.2/H-1-1] يجب توفير ربط البرامج التالي لرموز HID:

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

عند رصد أنواع طرفيات الصوت عبر USB 0x0302، يتم إجراء ما يلي:

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

عند رصد أنواع أطراف توصيل الصوت عبر USB 0x0402، يتم إجراء ما يلي:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.3. البرامج

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [6.1/H-0-1]* يجب أن يتيح تنفيذ أمر الصدفة cmd testharness.

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

• Perfetto
  • [6.1/H-0-2]* يجب أن يعرض /system/bin/perfetto ثنائيًا لمستخدم shell يتوافق سطر الأوامر الخاص به مع مستندات perfetto.
  • [6.1/H-0-3]* يجب أن يقبل ملف perfetto الثنائي كإدخال إعدادات protobuf متوافقة مع المخطط المحدّد في مستندات perfetto.
  • [6.1/H-0-4]* يجب أن يكتب ملف perfetto الثنائي كناتج تتبُّع protobuf يتوافق مع المخطط المحدّد في مستندات perfetto.
  • [6.1/H-0-5]* يجب توفير مصادر البيانات الموضّحة في مستندات perfetto على الأقل من خلال ملف perfetto الثنائي.

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

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

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

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

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

‫2.3.1 الأجهزة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ‫[5.3.6/T-1-1] ملف فك الترميز بدقة 1080p عالية الوضوح وبسرعة 60 إطارًا في الثانية

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

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

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

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

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

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

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

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

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

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

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

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

‫2.3.3 البرامج

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

• [3/T-0-1] يجب الإفصاح عن الميزتَين android.software.leanback وandroid.hardware.type.television.
• [3.4.1/T-0-1] يجب توفير تنفيذ كامل لواجهة برمجة التطبيقات android.webkit.Webview.

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

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

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

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

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

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

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

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

‫2.3.4 الأداء والطاقة

• ‫[8.1/T-0-1] وقت استجابة ثابت للإطار: يجب ألا يحدث تأخّر عرض اللقطات أو عدم اتساقه بمعدّل يزيد عن 5 لقطات في الثانية، ويجب أن يكون أقل من لقطة واحدة في الثانية.
• [8.2/T-0-1] يجب ضمان أداء كتابة تسلسلي لا يقل عن 5 ميغابايت/ثانية.
• ‫[8.2/T-0-2] يجب ضمان أداء كتابة عشوائية لا يقل عن 0.5 ميغابايت/ثانية.
• ‫[8.2/T-0-3] يجب ضمان أداء قراءة تسلسلية لا يقل عن 15 ميغابايت في الثانية.
• [8.2/T-0-4] يجب ضمان أداء قراءة عشوائية لا يقل عن 3.5 ميغابايت في الثانية.

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

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

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

• ‫[8.3/T-1-2] يجب تسجيل الجهاز كجهاز بدون بطارية على النحو الموضّح في دعم الأجهزة التي لا تعمل بالبطارية.

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

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

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

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

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

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

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

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

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

• [‫9.11/T-1-1] يجب أن يسمح للمستخدم باختيار مهلة "السكون" للانتقال من حالة إلغاء القفل إلى حالة القفل، مع حد أدنى مسموح به للمهلة يصل إلى 15 ثانية أو أقل.

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

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

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

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

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

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

• Perfetto
  • [6.1/T-0-1] يجب توفير ملف /system/bin/perfetto ثنائي لمستخدم shell يتوافق cmdline مع مستندات perfetto.
  • [6.1/T-0-2] يجب أن يقبل ملف perfetto الثنائي كإدخال إعدادات protobuf متوافقة مع المخطط المحدّد في مستندات perfetto.
  • [6.1/T-0-3] يجب أن يكتب ملف perfetto الثنائي كناتج تتبُّع protobuf يتوافق مع المخطط المحدّد في مستندات perfetto.
  • [6.1/T-0-4] يجب توفير مصادر البيانات الموضّحة في مستندات perfetto على الأقل من خلال ملف perfetto الثنائي.

‫2.4 متطلبات المشاهدة

يشير جهاز Android Watch إلى تنفيذ جهاز Android مصمَّم ليتم ارتداؤه على الجسم، ربما على المعصم.

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

• أن تتضمّن شاشة يتراوح طول قطرها الفعلي بين 1.1 و2.5 بوصة
• أن يتضمّن آلية يمكن ارتداؤها على الجسم

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

‫2.4.1 الأجهزة

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

• ‫[7.1.1.1/W-0-1] يجب أن يتضمّن الجهاز شاشة يتراوح حجم قطرها الفعلي بين 1.1 و2.5 بوصة.

• ‫[7.2.3/W-0-1] يجب أن تتوفّر للمستخدم وظيفة "الصفحة الرئيسية" ووظيفة "رجوع" باستثناء الحالات التي يكون فيها الجهاز في وضع UI_MODE_TYPE_WATCH.

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

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

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

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

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

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

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

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

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

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

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

• [7.8.2/W] قد يتضمّن مخرج صوت ولكن لا يُنصح بذلك.

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

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

‫2.4.3 البرامج

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

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

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

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

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

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

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

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

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

‫2.4.4 الأداء والطاقة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

‫2.5.1 الأجهزة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [7.4.5/A] يجب أن تتضمّن إمكانية الاتصال بالبيانات المستندة إلى شبكة الجوّال.

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

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

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

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

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

• [7.5/A-1-1] يجب ألا تتضمّن المركبة كاميرات تعرض المنظر الخارجي ويمكن الوصول إليها من خلال واجهات برمجة التطبيقات الخاصة بالكاميرا في Android، ما لم تستوفِ المتطلبات الأساسية للكاميرا.
• [‫7.5/A-SR] يُنصح بشدة بعدم تدوير معاينة الكاميرا أو عكسها أفقيًا.
• [7.5.5/A-SR] يُنصح بشدة بتوجيه STRONGLY RECOMMENDED بحيث يتوافق البُعد الأطول للكاميرا مع الأفق.
• [7.5/A-SR] يُنصح بشدة أن تكون درجة دقة STRONGLY RECOMMENDED‏ 1.3 ميغابكسل على الأقل.
• يجب أن يتضمّن الجهاز إما أجهزة تركيز ثابت أو أجهزة EDOF (عمق مجال التركيز الموسّع).
• يجب أن يتضمّن برنامج تشغيل الكاميرا ميزة التركيز التلقائي للأجهزة أو البرامج.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ‫[5.3/A-SR] H.265 HEVC

‫2.5.3 البرامج

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

• [3/A-0-1] يجب الإفصاح عن الميزة android.hardware.type.automotive.

• [3/A-0-2] يجب أن تتوافق مع uiMode = UI_MODE_TYPE_CAR.

• ‫[3/A-0-3] يجب أن تتوافق مع جميع واجهات برمجة التطبيقات المتاحة للجميع في مساحة الاسم android.car.*.

• ‫[3.2.1/A-0-1] يجب أن تتوافق مع جميع ثوابت الأذونات وأن تفرضها على النحو الموضّح في صفحة مرجع أذونات السيارات.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ‫[8.2/A-0-1] يجب تسجيل عدد وحدات البايت التي تمت قراءتها وكتابتها في وحدة التخزين غير المتطايرة لكل معرّف مستخدم (UID) خاص بكل عملية، وذلك لإتاحة الإحصاءات للمطوّرين من خلال واجهة برمجة التطبيقات للنظام android.car.storagemonitoring.CarStorageMonitoringManager. يستوفي "مشروع Android المفتوح المصدر" هذا الشرط من خلال وحدة النواة uid_sys_stats.
• [8.3/A-1-3] يجب تفعيل وضع المرآب مرة واحدة على الأقل قبل إيقاف تشغيل السيارة.
• [8.3/A-1-4] يجب أن يكون الجهاز في وضع "المرآب" لمدة 15 دقيقة على الأقل في الحالات التالية:
  • تم استنزاف شحن البطارية.
  • لم تتم جدولة أي مهام غير نشطة.
  • يخرج السائق من "وضع المرآب".
• [8.4/A-0-1] يجب توفير ملف تعريف طاقة لكل مكوّن يحدّد قيمة استهلاك التيار لكل مكوّن من مكوّنات الجهاز ومعدّل استهلاك البطارية التقريبي الذي تسبّبه المكوّنات بمرور الوقت على النحو الموضّح في موقع "مشروع Android المفتوح المصدر".
• [8.4/A-0-2] يجب الإبلاغ عن جميع قيم استهلاك الطاقة بوحدة "ملّي أمبير في الساعة" (mAh).
• [8.4/A-0-3] يجب إعداد تقرير عن استهلاك وحدة المعالجة المركزية للطاقة لكل معرّف UID خاص بكل عملية. يستوفي "مشروع Android المفتوح المصدر" هذا الشرط من خلال تنفيذ وحدة النواة uid_cputime.
• [8.4/A] يجب أن يُنسب إلى مكوّن الجهاز نفسه إذا تعذّر تحديد التطبيق المسؤول عن استهلاك طاقة مكوّن الجهاز.
• [8.4/A-0-4] يجب إتاحة معلومات استهلاك الطاقة هذه لمطوّر التطبيق من خلال الأمر adb shell dumpsys batterystats في واجهة الأوامر.

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

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

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

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

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

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

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

• [9.11/A-1-1] يجب أن يسمح للمستخدم باختيار مهلة السكون للانتقال من حالة إلغاء القفل إلى حالة القفل، مع حد أدنى مسموح به للمهلة يصل إلى 15 ثانية أو أقل.

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

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

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

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

• Perfetto
  • [6.1/A-0-1] يجب توفير ملف /system/bin/perfetto ثنائي لمستخدم shell يتوافق سطر الأوامر الخاص به مع مستندات perfetto.
  • ‫[6.1/A-0-2] يجب أن يقبل ملف perfetto الثنائي كمدخل إعدادات protobuf تتوافق مع المخطط المحدّد في مستندات perfetto.
  • [6.1/A-0-3] يجب أن يكتب ملف perfetto الثنائي كناتج تتبُّع protobuf يتوافق مع المخطط المحدّد في مستندات perfetto.
  • [6.1/A-0-4] يجب توفير مصادر البيانات الموضّحة في مستندات perfetto على الأقل من خلال ملف perfetto الثنائي.

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

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

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

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

2.6.1. الأجهزة

حجم الشاشة

• [7.1.1.1/Tab-0-1] يجب أن تتضمّن شاشة يتراوح حجمها بين 7 و18 بوصة.

الجيروسكوب

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

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

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

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

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

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

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

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

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

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

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

المفاتيح وبيانات الاعتماد (الفقرة 9.11)

يُرجى الرجوع إلى القسم [9.11].

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

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

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

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

3- البرامج

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

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

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

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

• [C-0-2] يجب أن يتيح/يحافظ على جميع الفئات والطرق والعناصر المرتبطة بها التي تم وضع علامة عليها باستخدام التعليق التوضيحي TestApi (@TestApi).

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

• [C-0-4] يجب أن تظل واجهات برمجة التطبيقات متوفرة وأن تعمل بطريقة معقولة، حتى عند حذف بعض ميزات الأجهزة التي يتضمّن Android واجهات برمجة تطبيقات لها. اطّلِع على الفقرة 7 لمعرفة المتطلبات المحدّدة لهذا السيناريو.

• [C-0-5] يجب ألا تسمح التطبيقات التابعة لجهات خارجية باستخدام واجهات غير متوفرة في حزمة SDK، ويُقصد بها الطرق والحقول في حِزم لغة Java التي تقع في مسار فئة التمهيد في مشروع Android مفتوح المصدر (AOSP)، والتي لا تشكّل جزءًا من حزمة SDK العامة. ويشمل ذلك واجهات برمجة التطبيقات التي تم تزيينها بالتعليق التوضيحي @hide ولكن ليس بالتعليق التوضيحي @SystemAPI، كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) وأعضاء الفئات الخاصة وعلى مستوى الحزمة.

• [C-0-6] يجب أن يتم شحنها مع كل واجهة غير تابعة لحزمة تطوير البرامج (SDK) في القوائم المحظورة نفسها التي يتم توفيرها من خلال علامات القائمة المؤقتة وقائمة الحظر في مسار prebuilts/runtime/appcompat/hiddenapi-flags.csv لفرع مستوى واجهة برمجة التطبيقات المناسب في مشروع Android مفتوح المصدر (AOSP).

  ومع ذلك، فإنّها:

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

• [C-0-7] يجب أن تتوافق الأجهزة مع آلية التعديل الديناميكي لإعدادات التكوين الموقَّعة من أجل إزالة الواجهات غير المتوفّرة في حزمة SDK من قائمة محظورة من خلال تضمين إعدادات التكوين الموقَّعة في أي حزمة APK، وذلك باستخدام المفاتيح العامة الحالية المتوفّرة في "مشروع Android مفتوح المصدر" (AOSP).

3.1.1. إضافات Android

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

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

3.1.2. مكتبة Android

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

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

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

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

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

3.2.1. الأذونات

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

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

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

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

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

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

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

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

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

‫3.2.3.2 حلّ النية

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

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

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

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

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

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

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

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

‫3.2.3.4. Broadcast Intents

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

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

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

‫3.2.3.5 إعدادات التطبيق التلقائية

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

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

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

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

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

• [C-2-1] يجب توفير قائمة إعدادات تستدعي الغرض RoleManager.createRequestRoleIntent(String) مع RoleManager.ROLE_SMS لعرض مربّع حوار لتغيير تطبيق الرسائل القصيرة التلقائي.

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

  • يجب استخدام واجهة المستخدم لتطبيق "الهاتف" التلقائي الذي اختاره المستخدم للمكالمات الواردة والصادرة باستثناء مكالمات الطوارئ التي سيتم إجراؤها باستخدام تطبيق "الهاتف" المثبَّت مسبقًا.

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

• [C-2-4] يجب السماح باستخدام android.telecom.CallRedirectionService لتطبيق يؤدي دور android.app.role.CALL_REDIRECTION.

• [C-2-5] يجب توفير إمكانية للمستخدم لاختيار تطبيق لديه دور android.app.role.CALL_REDIRECTION.

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

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

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

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

‫3.2.4 الأنشطة على شاشات العرض الثانوية/المتعددة

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

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

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

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

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

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

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

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

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

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

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

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

  • armeabi
  • armeabi-v7a
  • arm64-v8a
  • x86
  • x86-64

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

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

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

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

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

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

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

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

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

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

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

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

• [C-2-2] يجب إتاحة العمليات التالية دائمًا، حتى في حال تنفيذ واجهة التطبيق الثنائية (ABI) على بنية ARMv8، إما من خلال إتاحة وحدة المعالجة المركزية (CPU) الأصلية أو من خلال محاكاة البرامج:

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

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

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

‫3.4.1 توافق WebView

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

• [C-1-1] يجب عرض android.software.webview.
• [C-1-2] يجب استخدام إصدار مشروع Chromium من مشروع Android المفتوح المصدر الأساسي على فرع Android 10 لتنفيذ واجهة برمجة التطبيقات android.webkit.WebView.

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

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

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

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

• [C-1-4] يجب عرض المحتوى المقدَّم أو محتوى عنوان URL البعيد في عملية منفصلة عن التطبيق الذي ينشئ WebView. ويجب أن يكون لدى عملية العرض المنفصلة على وجه التحديد أذونات أقل، وأن يتم تشغيلها باستخدام معرّف مستخدم منفصل، وألا يكون لديها إذن الوصول إلى دليل بيانات التطبيق، وألا يكون لديها إذن الوصول المباشر إلى الشبكة، وأن يكون لديها إذن الوصول فقط إلى الحد الأدنى من خدمات النظام المطلوبة عبر Binder. يتوافق تطبيق WebView في AOSP مع هذا الشرط.

يُرجى العِلم أنّه إذا كانت عمليات تنفيذ الأجهزة 32 بت أو كانت تحدّد علامة الميزة android.hardware.ram.low، يتم إعفاؤها من المتطلّب C-1-3.

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

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

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

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

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

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

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

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

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

• [C-0-1] يجب ألا تغيّر الأجهزة سلوك أو دلالات الغرض العادي.
• [C-0-2] يجب ألا تغيّر الأجهزة دورة الحياة أو دلالات دورة الحياة لنوع معيّن من مكونات النظام (مثل الخدمة أو النشاط أو ContentProvider أو غير ذلك).
• [C-0-3] يجب ألا تغيّر الأجهزة دلالات أحد الأذونات العادية.
• يجب ألا تغيّر الأجهزة القيود المفروضة على التطبيقات التي تعمل في الخلفية. على وجه التحديد، بالنسبة إلى التطبيقات التي تعمل في الخلفية:
  • [C-0-4] يجب إيقاف تنفيذ عمليات معاودة الاتصال التي يسجّلها التطبيق لتلقّي نواتج من GnssMeasurement وGnssNavigationMessage.
  • [C-0-5] يجب أن يتم تحديد معدّل تكرار التحديثات التي يتم توفيرها للتطبيق من خلال فئة واجهة برمجة التطبيقات LocationManager أو طريقة WifiManager.startScan().
  • [C-0-6] إذا كان التطبيق يستهدف المستوى 25 أو أعلى من واجهة برمجة التطبيقات، يجب ألا يسمح بتسجيل أدوات استقبال البث لعمليات البث الضمنية لغايات Android العادية في بيان التطبيق، ما لم تتطلّب غاية البث إذن "signature" أو "signatureOrSystem" protectionLevel أو كانت ضمن قائمة الإعفاءات.
  • [C-0-7] إذا كان التطبيق يستهدف المستوى 25 أو أعلى من واجهة برمجة التطبيقات، يجب إيقاف الخدمات التي تعمل في الخلفية، تمامًا كما لو كان التطبيق قد استدعى طريقة stopSelf() الخاصة بالخدمات، ما لم يتم وضع التطبيق في قائمة مؤقتة بالسماح لتنفيذ مهمة مرئية للمستخدم.
  • [C-0-8] إذا كان التطبيق يستهدف المستوى 25 أو مستوى أحدث لواجهة برمجة التطبيقات، يجب أن يحرر عمليات قفل التنشيط التي يحتفظ بها التطبيق.
• [C-0-9] يجب أن تعرض الأجهزة موفّري الأمان التاليين كأول سبع قيم في المصفوفة من الطريقة Security.getProviders()، بالترتيب المحدّد وبالأسماء المحدّدة (كما يتم عرضها من خلال Provider.getName()) والفئات، ما لم يعدّل التطبيق القائمة من خلال insertProviderAt() أو removeProvider(). يمكن أن تعرض الأجهزة مزوّدين إضافيين بعد قائمة المزوّدين المحدّدة أدناه.
  1. ‫AndroidNSSP - android.security.net.config.NetworkSecurityConfigProvider
  2. ‫AndroidOpenSSL - com.android.org.conscrypt.OpenSSLProvider
  3. ‫CertPathProvider - sun.security.provider.CertPathProvider
  4. ‫AndroidKeyStoreBCWorkaround - android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
  5. BC - com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
  6. ‫HarmonyJSSE - com.android.org.conscrypt.JSSEProvider
  7. ‫AndroidKeyStore - android.security.keystore.AndroidKeyStoreProvider

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

‫3.5.1 حظر العمل في الخلفية

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

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

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

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

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

أي أنّها:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

‫3.8.3 الإشعارات

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

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

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

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

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

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

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

• [C-3-1] يجب استخدام عرض الإشعارات المنبثقة ومواردها كما هو موضّح في فئة واجهة برمجة التطبيقات Notification.Builder عند عرض الإشعارات المنبثقة.
• [C-3-2] يجب عرض الإجراءات المقدَّمة من خلال Notification.Builder.addAction() مع محتوى الإشعار بدون تفاعل إضافي من المستخدم على النحو الموضّح في حزمة تطوير البرامج (SDK).

‫3.8.3.2 خدمة تلقّي الإشعارات الصوتية

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

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

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

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

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

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

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

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

‫3.8.4 البحث

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

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

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

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

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

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

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

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

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

‫3.8.5 التنبيهات والإشعارات المؤقتة

يمكن للتطبيقات استخدام واجهة برمجة التطبيقات Toast لعرض سلاسل قصيرة غير مشروطة للمستخدم النهائي تختفي بعد فترة وجيزة، واستخدام واجهة برمجة التطبيقات لنوع النافذة TYPE_APPLICATION_OVERLAY لعرض نوافذ التنبيه كتراكب على التطبيقات الأخرى.

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

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

• [C-1-2] يجب أن يلتزم الجهاز بواجهة برمجة التطبيقات Toast API وأن يعرض إشعارات Toast من التطبيقات للمستخدمين النهائيين بطريقة واضحة جدًا.

‫3.8.6. المظاهر

يوفّر نظام التشغيل Android "تصميمات" كآلية لتطبيق الأنماط على مستوى نشاط أو تطبيق بأكمله.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.10. وحدة تحكّم الوسائط على شاشة القفل

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

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

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

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

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

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

‫3.8.13. الرموز الموحّدة والخط

يتضمّن نظام التشغيل Android دعمًا لأحرف الإيموجي المحدّدة في Unicode 10.0.

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

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

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

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

يتضمّن Android إمكانية عرض خطوط ميانمار. تتضمّن ميانمار العديد من الخطوط غير المتوافقة مع Unicode، والمعروفة باسم "Zawgyi"، لعرض لغات ميانمار.

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

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

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

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

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

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

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

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

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

‫3.8.15. صورة مقطوعة للشاشة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [C-0-1] يجب ألا تُمنح "التطبيقات الفورية" إلا الأذونات التي تم ضبط android:protectionLevel فيها على "instant".
• [C-0-2] يجب ألا تتفاعل التطبيقات الفورية مع التطبيقات المثبَّتة من خلال النوايا الضمنية إلا في حال استيفاء أحد الشروط التالية:
  • فلتر نمط الأهداف الخاص بالمكوِّن معرَّض ويتضمّن CATEGORY_BROWSABLE
  • يجب أن يكون الإجراء أحد الإجراءات ACTION_SEND أو ACTION_SENDTO أو ACTION_SEND_MULTIPLE
  • يتم عرض الهدف بشكل صريح باستخدام android:visibleToInstantApps
• [C-0-3] يجب ألا تتفاعل التطبيقات الفورية بشكل صريح مع التطبيقات المثبَّتة إلا إذا تم عرض المكوّن من خلال android:visibleToInstantApps.
• [C-0-4] يجب ألا ترى التطبيقات المثبَّتة تفاصيل حول التطبيقات الفورية على الجهاز ما لم يتصل التطبيق الفوري بالتطبيق المثبَّت بشكل صريح.
• يجب أن توفّر عمليات تنفيذ الأجهزة إمكانات المستخدم التالية للتفاعل مع "التطبيقات الفورية". يستوفي AOSP المتطلبات باستخدام واجهة مستخدم النظام والإعدادات والمشغّل التلقائيين. عمليات تنفيذ الأجهزة:
  • [C-0-5] يجب توفير وسيلة تتيح للمستخدم عرض التطبيقات الفورية المخزّنة مؤقتًا على الجهاز وحذفها لكل حزمة تطبيق على حدة.
  • [C-0-6] يجب توفير إشعار مستمر للمستخدم يمكن تصغيره أثناء تشغيل تطبيق فوري في المقدّمة. يجب أن يتضمّن إشعار المستخدم هذا أنّ "التطبيقات الفورية" لا تتطلّب التثبيت وأن يوفّر للمستخدم إمكانية الوصول إلى شاشة معلومات التطبيق في "الإعدادات". بالنسبة إلى "التطبيقات الفورية" التي يتم تشغيلها من خلال نوايا الويب، كما هو محدّد باستخدام نية تم ضبط الإجراء فيها على Intent.ACTION_VIEW وبمخطط "http" أو "https"، يجب أن يتيح عنصر تحكّم إضافي للمستخدم عدم تشغيل "التطبيق الفوري" وفتح الرابط المرتبط به باستخدام متصفّح الويب الذي تم ضبطه، إذا كان المتصفّح متاحًا على الجهاز.
  • [C-0-7] يجب السماح بالوصول إلى "التطبيقات الفورية" من وظيفة "التطبيقات الحديثة" إذا كانت هذه الوظيفة متاحة على الجهاز.

‫3.16. إقران الجهاز المصاحب

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

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

• [C-1-1] يجب الإعلان عن علامة الميزة FEATURE_COMPANION_DEVICE_SETUP .
• [C-1-2] يجب التأكّد من تنفيذ واجهات برمجة التطبيقات في حزمة android.companion بالكامل.
• [C-1-3] يجب توفير إمكانات للمستخدم تتيح له اختيار/تأكيد توفّر جهاز مصاحب وجاهزيته للتشغيل.

3.17. التطبيقات ذات الاستهلاك المكثّف للموارد

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

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

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

• [C-1-1] يجب تجاهل السمة cantSaveState التي تحدّدها التطبيقات ويجب عدم تغيير سلوك التطبيق استنادًا إلى هذه السمة.

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

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

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

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

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

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

• [C-0-5] يجب أن يتضمّن تطبيقك نشاطًا يعالج الغرض android.settings.MANAGE_UNKNOWN_APP_SOURCES.

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

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

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

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

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

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

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

• [C-0-1] يجب أن تتوافق مع تنسيقات الوسائط وبرامج الترميز والفك وأنواع الملفات وتنسيقات الحاويات المحدّدة في الفقرة 5.1 لكل برنامج ترميز وفك تم الإعلان عنه بواسطة MediaCodecList.
• [C-0-2] يجب الإفصاح عن إتاحة برامج الترميز وفك الترميز للتطبيقات الخارجية من خلال MediaCodecList والإبلاغ عن ذلك.
• [C-0-3] يجب أن يكون الجهاز قادرًا على فك ترميز جميع التنسيقات التي يمكنه ترميزها وإتاحتها للتطبيقات الخارجية بشكل صحيح. ويشمل ذلك جميع تدفقات البتات التي تنشئها برامج الترميز والملفات الشخصية المُبلغ عنها في CamcorderProfile.

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

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

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

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

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

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

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

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

• [C-1-1] PCM/WAVE
• [C-1-2] FLAC
• ‫[C-1-3] Opus

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

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

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

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

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

• ‫[C-1-1] ملف تعريف MPEG-4 AAC (ملف تعريف AAC LC)
• ‫[C-1-2] ملف تعريف MPEG-4 HE AAC (تنسيق AAC+)
• ‫[C-1-3] ملف تعريف MPEG-4 HE AACv2 (برنامج ترميز AAC+ المحسّن)
• ‫[C-1-4] AAC ELD (ترميز AAC المحسّن بزمن انتقال منخفض)
• ‫[C-1-11] xHE-AAC (ملف تعريف HE AAC الموسّع وفقًا للمعيار ISO/IEC 23003-3، والذي يتضمّن ملف تعريف USAC الأساسي وملف تعريف التحكّم في النطاق الديناميكي وفقًا للمعيار ISO/IEC 23003-4)
• ‫[C-1-5] FLAC
• [C-1-6] MP3
• ‫[C-1-7] MIDI
• ‫[C-1-8] Vorbis
• ‫[C-1-9] PCM/WAVE، بما في ذلك تنسيقات الصوت العالي الدقة التي تصل إلى 24 بت ومعدّل بيانات في الملف الصوتي يبلغ 192 كيلوهرتز و8 قنوات يُرجى العِلم أنّ هذا الشرط ينطبق على فك الترميز فقط، ويُسمح للجهاز بتقليل معدّل أخذ العينات وتقليل عدد القنوات أثناء مرحلة التشغيل.
• ‫[C-1-10] Opus

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ‫[C-0-1] JPEG
• [C-0-2] PNG
• ‫[C-0-3] WebP

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

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

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

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

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

• ‫[C-0-1] JPEG
• [C-0-2] GIF
• ‫[C-0-3] PNG
• [C-0-4] BMP
• [C-0-5] WebP
• [C-0-6] Raw
• ‫[C-0-7] HEIF (HEIC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

إذا كانت عمليات تنفيذ الأجهزة تعلن عن إتاحة ملفات تعريف HDR من خلال Display.HdrCapabilities، يجب أن:

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

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

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

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

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

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

5.1.9. أمان برامج ترميز الوسائط

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

يتضمّن Android دعمًا لواجهة برمجة التطبيقات OMX، وهي واجهة برمجة تطبيقات متعددة المنصات لتسريع الوسائط المتعددة، بالإضافة إلى Codec 2.0، وهي واجهة برمجة تطبيقات لتسريع الوسائط المتعددة ذات الحمل المنخفض.

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

• [C-1-1] يجب توفير دعم لبرامج ترميز الوسائط إما من خلال واجهات برمجة تطبيقات OMX أو Codec 2.0 (أو كليهما) كما هو الحال في "مشروع Android المفتوح المصدر"، ويجب عدم إيقاف أو التحايل على وسائل الحماية الأمنية. ولا يعني ذلك تحديدًا أنّه يجب أن يستخدم كل برنامج ترميز إما واجهة برمجة التطبيقات OMX أو Codec 2.0، بل يجب أن تتوفّر إمكانية استخدام إحدى واجهات برمجة التطبيقات هذه على الأقل، ويجب أن تتضمّن إمكانية استخدام واجهات برمجة التطبيقات المتاحة وسائل الحماية الأمنية المتوفّرة.
• [C-SR] يُنصح بشدة بتضمين دعم Codec 2.0 API.

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

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

في حال توفُّر واجهة برمجة التطبيقات Codec 2.0 في عمليات تنفيذ الأجهزة، يجب أن:

• [C-3-1] يجب أن يتضمّن برنامج الترميز 2.0 المقابل من "مشروع Android المفتوح المصدر" (إذا كان متاحًا) لكل تنسيق ونوع وسائط (برنامج ترميز أو فك ترميز) متوافق مع الجهاز.
• [C-3-2] يجب أن تستضيف عملية برامج الترميز برامج الترميز 2.0 كما هو موضّح في "مشروع Android مفتوح المصدر" لإتاحة منح إذن الوصول إلى برامج الترميز بشكل أكثر تحديدًا.
• ‫[C-3-3] برامج الترميز التي تبدأ أسماؤها بـ "c2.android." يجب أن تستند إلى رمز المصدر الخاص بمشروع Android المفتوح المصدر.

5.1.10. تحديد خصائص برامج ترميز الوسائط

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

• [C-1-1] يجب أن تعرض قيمًا صحيحة لتوصيف برامج الترميز الخاصة بالوسائط من خلال واجهة برمجة التطبيقات MediaCodecInfo.

ويشمل ذلك على وجه الخصوص:

• ‫[C-1-2] برامج الترميز التي تبدأ أسماؤها بـ "OMX" يجب استخدام واجهات برمجة التطبيقات OMX وأن تتضمّن أسماء تتوافق مع إرشادات التسمية OMX IL.
• ‫[C-1-3] برامج الترميز التي تبدأ أسماؤها بـ "c2." يجب استخدام Codec 2.0 API وأن تتضمّن أسماء تتوافق مع إرشادات التسمية في Codec 2.0 لنظام التشغيل Android.
• ‫[C-1-4] برامج الترميز التي تبدأ أسماؤها بـ "OMX.google." أو "c2.android." يجب ألا يتم تصنيفها على أنّها خاصة بمورّد أو أنّها تستخدم تسريع الأجهزة.
• [C-1-5] يجب عدم تصنيف برامج الترميز التي تعمل في عملية برنامج ترميز (مورّد أو نظام) يمكنها الوصول إلى برامج تشغيل الأجهزة بخلاف أدوات تخصيص الذاكرة وأدوات الربط على أنّها برامج فقط.
• [C-1-6] يجب تصنيف برامج الترميز غير المتوفّرة في "مشروع Android مفتوح المصدر" أو غير المستندة إلى الرمز المصدر في هذا المشروع على أنّها برامج ترميز خاصة بمورّد.
• ‫[C-1-7] يجب تصنيف برامج الترميز التي تستخدم ميزة "تسريع الأجهزة" على أنّها تستخدم هذه الميزة.
• ‫[C-1-8] يجب ألا تكون أسماء برامج الترميز مضلِّلة. على سبيل المثال، يجب أن تتوافق برامج الترميز التي تحمل الاسم "decoders" مع فك الترميز، كما يجب أن تتوافق البرامج التي تحمل الاسم "encoders" مع الترميز. يجب أن تتوافق برامج الترميز التي تحتوي أسماؤها على تنسيقات وسائط مع هذه التنسيقات.

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

• [C-2-1] يجب أن تنشر جميع برامج ترميز الفيديو بيانات معدّل اللقطات القابل للتحقيق للأحجام التالية إذا كان برنامج الترميز يتيح ذلك:

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

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

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

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

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

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

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

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

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

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

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

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

5.2.1. H.263

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

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

5.2.2. H.264

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

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

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

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

5.2.3. VP8

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

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

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

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

5.2.4. VP9

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

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

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

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

‫5.2.5 ‫H.265

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

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

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

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

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

‫5.3.1 MPEG-2

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

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

5.3.2. H.263

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

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

5.3.3. MPEG-4

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

• [C-1-1] يجب أن يتوافق مع Simple Profile Level 3.

5.3.4. H.264

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

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

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

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

5.3.5. ‫H.265 (HEVC)

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

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

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

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

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

• [C-3-1] يجب أن تقبل عمليات تنفيذ الأجهزة البيانات الوصفية المطلوبة ذات تنسيق HDR (MediaFormat#KEY_HDR_STATIC_INFO لجميع ملفات HDR الشخصية) من التطبيق باستخدام واجهة برمجة التطبيقات MediaCodec، بالإضافة إلى إتاحة استخراج البيانات الوصفية المطلوبة ذات تنسيق HDR (MediaFormat#KEY_HDR_STATIC_INFO لجميع ملفات HDR الشخصية، بالإضافة إلى MediaFormat#KEY_HDR10_PLUS_INFO لملفات HDR10Plus الشخصية) من دفق البت و/أو الحاوية على النحو المحدّد في المواصفات ذات الصلة. يجب أيضًا أن تتوافق مع إخراج البيانات الوصفية المطلوبة بتنسيق HDR (MediaFormat#KEY_HDR_STATIC_INFO لجميع ملفات HDR الشخصية) من دفق البتات و/أو الحاوية على النحو المحدّد في المواصفات ذات الصلة.

• [C-SR] يُنصح بشدة بأن تتيح عمليات تنفيذ الأجهزة إمكانية إخراج بيانات وصفية MediaFormat#KEY_HDR10_PLUS_INFO لملفات HDR10Plus الشخصية من خلال MediaCodec#getOutputFormat(int).

• [C-3-2] يجب أن تعرض عمليات تنفيذ الأجهزة محتوى HDR بشكل صحيح لملف تعريف HEVCProfileMain10HDR10 على شاشة الجهاز أو على منفذ إخراج فيديو عادي (مثل HDMI).

• [C-SR] يُنصح بشدة بتنفيذ الأجهزة لعرض محتوى HDR بشكل صحيح لملف تعريف HEVCProfileMain10HDR10Plus على شاشة الجهاز أو على منفذ إخراج فيديو عادي (مثل HDMI).

5.3.6. VP8

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

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

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

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

5.3.7. VP9

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

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

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

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

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

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

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

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

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

• [C-4-1] يجب أن تقبل عمليات تنفيذ الأجهزة البيانات الوصفية المطلوبة ذات تنسيق HDR (MediaFormat#KEY_HDR_STATIC_INFO لجميع ملفات HDR الشخصية، بالإضافة إلى المَعلمة MediaCodec#PARAMETER_KEY_HDR10_PLUS_INFO لملفات HDR10Plus الشخصية) من التطبيق باستخدام واجهة برمجة التطبيقات MediaCodec، بالإضافة إلى إتاحة استخراج البيانات الوصفية المطلوبة ذات تنسيق HDR (MediaFormat#KEY_HDR_STATIC_INFO لجميع ملفات HDR الشخصية، بالإضافة إلى MediaFormat#KEY_HDR10_PLUS_INFO لملفات HDR10Plus الشخصية) من دفق البت و/أو الحاوية على النحو المحدّد في المواصفات ذات الصلة. يجب أيضًا أن تتيح إخراج البيانات الوصفية المطلوبة بتنسيق HDR (MediaFormat#KEY_HDR_STATIC_INFO لجميع ملفات HDR الشخصية) من دفق البتات و/أو الحاوية على النحو المحدّد في المواصفات ذات الصلة.

• [C-4-2] يجب أن تعرض عمليات تنفيذ الأجهزة محتوى HDR بشكل صحيح لملفَي التعريف VP9Profile2HDR وVP9Profile3HDR على شاشة الجهاز أو على منفذ إخراج فيديو عادي (مثل HDMI).

• [C-SR] يُنصح بشدة بأن تتيح عمليات تنفيذ الأجهزة إخراج البيانات الوصفية MediaFormat#KEY_HDR10_PLUS_INFO لملفات HDR10Plus الشخصية من خلال MediaCodec#getOutputFormat(int).

• [C-SR] يُنصح بشدة بتنفيذ الأجهزة لعرض محتوى HDR بشكل صحيح لملفات VP9Profile2HDR10Plus وVP9Profile3HDR10Plus على شاشة الجهاز أو على منفذ إخراج فيديو عادي (مثل HDMI).

5.3.8. Dolby Vision

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

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

5.3.9. AV1

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

• ‫[C-1-1] يجب أن يتوافق مع Profile 0، بما في ذلك المحتوى ذو 10 بت.

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

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

5.4.1. التقاط الصوت الخام ومعلومات الميكروفون

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.4.3. التقاط المحتوى لإعادة توجيه التشغيل

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

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

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

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

5.4.4. جهاز إلغاء الصدى

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

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

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

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

5.4.5. التقاط متزامن

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

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

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

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

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

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

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

5.5.1. تشغيل الصوت الخام

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

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

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

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

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

5.5.2. المؤثرات الصوتية

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.7. بروتوكولات الشبكة

يجب أن تتوافق عمليات تنفيذ الأجهزة مع بروتوكولات شبكة الوسائط لتشغيل الصوت والفيديو على النحو المحدّد في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن برنامج فك ترميز صوتي أو فيديو، يجب أن تستوفي ما يلي:

• [C-1-1] يجب أن تتوافق مع جميع برامج الترميز وتنسيقات الحاويات المطلوبة في القسم 5.1 عبر HTTP(S).

• [C-1-2] يجب أن تتوافق مع نسق مقاطع الوسائط الموضّحة في جدول "نسق مقاطع الوسائط" أدناه عبر مسودة بروتوكول البث المباشر وفق بروتوكول HTTP، الإصدار 7.

• [C-1-3] يجب أن تتوافق مع ملف تعريف الصوت والفيديو RTP وبرامج الترميز ذات الصلة في جدول RTSP أدناه. للاطّلاع على الاستثناءات، يُرجى الرجوع إلى الحواشي السفلية للجدول في القسم 5.1.

تنسيقات شرائح الوسائط

RTSP (RTP, SDP)

‫5.8. Secure Media

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع إخراج الفيديو الآمن ويمكنها توفير مساحات آمنة، فإنّها:

• [C-1-1] يجب الإعلان عن إتاحة Display.FLAG_SECURE.

إذا كانت عمليات تنفيذ الأجهزة تعلن عن توفّر Display.FLAG_SECURE وتتيح بروتوكول العرض اللاسلكي، عليها استيفاء ما يلي:

• ‫[C-2-1] يجب تأمين الرابط باستخدام آلية تشفير قوية مثل HDCP 2.x أو إصدار أحدث للشاشات المتصلة من خلال بروتوكولات لاسلكية مثل Miracast.

إذا كانت عمليات تنفيذ الأجهزة تعلن عن إتاحة Display.FLAG_SECURE وتتيح شاشة عرض خارجية سلكية، عليها استيفاء ما يلي:

• ‫[C-3-1] يجب أن تتوافق جميع شاشات العرض الخارجية المتصلة عبر منفذ سلكي يمكن للمستخدم الوصول إليه مع الإصدار 1.2 أو إصدار أحدث من بروتوكول HDCP.

5.9. الواجهة الرقمية للآلات الموسيقية (MIDI)

إذا كانت عمليات تنفيذ الأجهزة تشير إلى إتاحة الميزة android.software.midi من خلال الفئة android.content.pm.PackageManager، فإنّها:

• [C-1-1] يجب أن تتوافق مع MIDI عبر جميع عمليات نقل الأجهزة المتوافقة مع MIDI والتي توفّر لها إمكانية اتصال عامة غير MIDI، حيث تكون عمليات النقل هذه:

  • وضع مضيف USB، الفقرة 7.7
  • وضع أجهزة USB المُلحقة، الفقرة 7.7
  • واجهة MIDI عبر البلوتوث منخفض الطاقة (Bluetooth LE) التي تعمل في دور مركزي، الفقرة 7.4.3

• [C-1-2] يجب أن تتوافق مع نقل برامج MIDI بين التطبيقات (أجهزة MIDI الافتراضية)

• [C-1-3] يجب تضمين libamidi.so (توافق MIDI الأصلي)

‫5.10. Professional Audio

إذا كانت عمليات تنفيذ الأجهزة تشير إلى إتاحة الميزة android.hardware.audio.pro من خلال الفئة android.content.pm.PackageManager، فإنّها:

• [C-1-1] يجب الإبلاغ عن إمكانية استخدام الميزة android.hardware.audio.low_latency.
• [C-1-2] يجب أن يكون وقت استجابة إرسال البيانات واستقبالها المستمر للصوت، كما هو محدّد في الفقرة 5.6 "وقت استجابة إرسال البيانات واستقبالها للصوت"، بمقدار 20 ملي ثانية أو أقل، ويجب أن يكون بمقدار 10 ملي ثانية أو أقل على مسار واحد على الأقل من المسارات المتوافقة.
• [C-1-3] يجب أن يتضمّن منفذ USB واحدًا أو أكثر يتيح وضع مضيف USB ووضع ملحق USB.
• [C-1-4] يجب الإبلاغ عن توفّر الميزة android.software.midi.
• [C-1-5] يجب استيفاء متطلبات زمن الاستجابة والصوت عبر USB باستخدام كلّ من واجهة برمجة التطبيقات OpenSL ES لقائمة انتظار مخزن مؤقت لبيانات PCM ومسار واحد على الأقل لواجهة برمجة التطبيقات AAudio native audio.
• [SR] يُنصح بشدة باستيفاء متطلبات زمن الاستجابة والصوت عبر USB باستخدام واجهة برمجة التطبيقات AAudio native audio بدلاً من مسار MMAP.
• [C-1-6] يجب أن يكون وقت استجابة الإخراج البارد 200 ملي ثانية أو أقل.
• [C-1-7] يجب أن يكون وقت استجابة الإدخال البارد 200 ملي ثانية أو أقل.
• [SR] يُنصح بشدة بتوفير مستوى ثابت من أداء وحدة المعالجة المركزية أثناء تشغيل الصوت وتفاوت حمل وحدة المعالجة المركزية. يجب اختبار ذلك باستخدام إصدار تطبيق Android من SynthMark برقم التعريف 09b13c6f49ea089f8c31e5d035f912cc405b7ab8. يستخدم SynthMark برنامج توليف صوتي يعمل على إطار صوتي محاكى يقيس أداء النظام. يجب تشغيل تطبيق SynthMark باستخدام خيار "الاختبار الآلي" وتحقيق النتائج التالية:
  • voicemark.90 >= 32 voices
  • ‫latencymark.fixed.little <= 15 msec
  • latencymark.dynamic.little <= 50 msec

يمكنك الاطّلاع على المستندات الخاصة بأداة SynthMark للحصول على شرح للمعايير.

• يجب تقليل عدم دقة الساعة الصوتية والانحراف عن الوقت العادي.
• يجب تقليل انحراف ساعة الصوت إلى الحدّ الأدنى مقارنةً بوحدة المعالجة المركزية CLOCK_MONOTONIC عندما يكون كلاهما نشطًا.
• يجب تقليل وقت استجابة الصوت عبر محوّلات الطاقة على الجهاز.
• يجب تقليل وقت استجابة الصوت إلى الحدّ الأدنى عند استخدام الصوت الرقمي عبر USB.
• يجب أن يوثّق المستند قياسات وقت استجابة الصوت على جميع المسارات.
• يجب تقليل التشويش في أوقات إدخال معاودة الاتصال عند اكتمال مخزن الصوت المؤقت، لأنّ ذلك يؤثّر في النسبة المئوية القابلة للاستخدام من معدل نقل البيانات الكامل لوحدة المعالجة المركزية من خلال معاودة الاتصال.
• يجب ألا تحدث أي أخطاء صوتية أثناء الاستخدام العادي عند معدل الكمون المُبلغ عنه.
• يجب ألا يكون هناك أي فرق في وقت الاستجابة بين القنوات.
• يجب تقليل متوسط وقت استجابة MIDI إلى الحدّ الأدنى على جميع وسائل النقل.
• يجب تقليل تفاوت وقت استجابة MIDI إلى الحدّ الأدنى أثناء التحميل (التشوّش) على جميع عمليات النقل.
• يجب توفير طوابع زمنية دقيقة لبيانات MIDI عبر جميع عمليات النقل.
• يجب تقليل الضوضاء في إشارة الصوت عبر محوّلات الطاقة على الجهاز، بما في ذلك الفترة التي تلي التشغيل على البارد مباشرةً.
• يجب ألا يكون هناك أي فرق في توقيت الصوت بين جهة الإدخال وجهة الإخراج لنقاط النهاية المتوافقة، وذلك عندما تكون كلتا الجهتَين نشطتَين. وتشمل الأمثلة على نقاط النهاية المتوافقة الميكروفون ومكبّر الصوت على الجهاز، أو إدخال وإخراج مقبس الصوت.
• يجب أن تعالج عمليات معاودة الاتصال عند اكتمال مخزن الصوت المؤقت لجانبَي الإدخال والإخراج لنقاط النهاية المتوافقة على سلسلة المحادثات نفسها عندما يكون كلاهما نشطًا، ويجب أن تدخل عملية معاودة الاتصال الخاصة بالإخراج مباشرةً بعد الرجوع من عملية معاودة الاتصال الخاصة بالإدخال. أو إذا لم يكن من الممكن التعامل مع عمليات معاودة الاتصال في سلسلة المحادثات نفسها، أدخِل عملية معاودة الاتصال الخاصة بالإخراج بعد وقت قصير من إدخال عملية معاودة الاتصال الخاصة بالإدخال للسماح للتطبيق بالحصول على توقيت متسق لجانبَي الإدخال والإخراج.
• يجب تقليل فرق الطور بين تخزين الصوت مؤقتًا في طبقة تجريد الأجهزة (HAL) لكل من الإدخال والإخراج في نقاط النهاية المتوافقة.
• يجب تقليل وقت استجابة اللمس.
• يجب تقليل تفاوت زمن استجابة اللمس عند التحميل (الارتعاش).
• يجب أن يكون وقت الاستجابة من إدخال اللمس إلى إخراج الصوت أقل من أو يساوي 40 ملي ثانية.

إذا كانت عمليات تنفيذ الأجهزة تستوفي جميع المتطلبات المذكورة أعلاه، فإنّها:

• [SR] يُنصح بشدة بالإبلاغ عن إمكانية استخدام الميزة android.hardware.audio.pro من خلال الفئة android.content.pm.PackageManager.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقبس صوت 3.5 ملم بأربعة موصلات، يجب أن:

• [C-2-1] يجب أن يكون وقت استجابة إرسال البيانات الصوتية واستقبالها بشكل متواصل 20 ملي ثانية أو أقل عبر مسار مقبس الصوت.
• [SR] يُنصح بشدة بالامتثال للفقرة مواصفات الجهاز الجوّال (المقبس) من مواصفات سماعات الرأس السلكية (الإصدار 1.1).
• يجب ألا يزيد وقت استجابة إرسال البيانات واستقبالها المستمر للصوت عن 10 ملي ثانية عبر مسار مقبس الصوت.

إذا كانت عمليات تنفيذ الأجهزة لا تتضمّن مقبس صوت 3.5 ملم بأربعة موصلات وتتضمّن منفذ USB(أو منافذ) يتيح وضع مضيف USB، يجب أن:

• ‫[C-3-1] يجب تنفيذ فئة الصوت عبر USB.
• [C-3-2] يجب أن يكون وقت استجابة إرسال البيانات واستقبالها المستمر للصوت 20 ملي ثانية أو أقل عبر منفذ وضع مضيف USB باستخدام فئة صوت USB.
• يجب أن يكون وقت استجابة إرسال البيانات واستقبالها المستمر للصوت 10 ملي ثانية أو أقل عبر منفذ وضع مضيف USB باستخدام فئة صوت USB.
• [C-SR] يُنصح بشدة بتوفير إمكانية إدخال/إخراج متزامن لما يصل إلى 8 قنوات في كل اتجاه، ومعدّل عيّنات يبلغ 96 كيلو هرتز، وعمق يبلغ 24 أو 32 بت، عند استخدامها مع أجهزة USB الطرفية الصوتية التي تتوافق أيضًا مع هذه المتطلبات.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ HDMI، يجب أن:

• يجب أن يتيح إخراج الصوت في قناتَين و8 قنوات بعمق 20 أو 24 بت وبتردد 192 كيلو هرتز بدون فقدان عمق البت أو إعادة التعيين، وذلك في إعداد واحد على الأقل.

‫5.11. التقاط الصور التي لم تتم معالجتها

يتيح نظام التشغيل Android تسجيل الصوت غير المعالج من خلال مصدر الصوت android.media.MediaRecorder.AudioSource.UNPROCESSED. في OpenSL ES، يمكن الوصول إلى هذا الإعداد المُسبَق باستخدام SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

إذا كانت عمليات تنفيذ الأجهزة تهدف إلى توفير مصدر صوت غير معالج وإتاحته للتطبيقات التابعة لجهات خارجية، عليها استيفاء ما يلي:

• [C-1-1] يجب الإبلاغ عن التوافق من خلال السمة android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.

• [C-1-2] يجب أن تُظهر خصائص السعة مقابل التردد مسطّحة تقريبًا في نطاق التردد المتوسط: تحديدًا ‎±10 ديسيبل من 100 هرتز إلى 7000 هرتز لكل ميكروفون مستخدَم لتسجيل مصدر الصوت غير المعالج.

• [C-1-3] يجب أن تعرض مستويات السعة في نطاق التردد المنخفض: تحديدًا من ‎±20 ديسيبل من 5 هرتز إلى 100 هرتز مقارنةً بنطاق التردد المتوسط لكل ميكروفون مستخدَم لتسجيل مصدر الصوت غير المعالج.

• ‫[C-1-4] يجب أن تعرض مستويات السعة في نطاق التردد العالي: تحديدًا من ±30 ديسيبل من 7000 هرتز إلى 22 كيلو هرتز مقارنةً بنطاق التردد المتوسط لكل ميكروفون مستخدَم لتسجيل مصدر الصوت غير المعالج.

• [C-1-5] يجب ضبط حساسية إدخال الصوت بحيث يؤدي مصدر نغمي جيبي بتردد 1000 هرتز يتم تشغيله عند مستوى ضغط صوتي (SPL) يبلغ 94 ديسيبل إلى استجابة بقيمة متوسط الجذر التربيعي (RMS) تبلغ 520 لعينات 16 بت (أو -36 ديسيبل من المقياس الكامل لعينات النقطة العائمة/الدقة المزدوجة) لكل ميكروفون مستخدَم لتسجيل مصدر الصوت غير المعالج.

• [C-1-6] يجب أن تتوفّر نسبة الإشارة إلى الضوضاء (SNR) عند 60 ديسيبل أو أعلى لكل ميكروفون مستخدَم لتسجيل مصدر الصوت غير المعالج. (بينما يتم قياس نسبة الإشارة إلى الضوضاء على أنّها الفرق بين مستوى ضغط الصوت البالغ 94 ديسيبل ومستوى ضغط الصوت المكافئ للضوضاء الذاتية، مع ترجيح A).

• [C-1-7] يجب أن يكون إجمالي التشوه التوافقي (THD) أقل من% 1 عند 1 كيلو هرتز ومستوى ضغط صوتي (SPL) يبلغ 90 ديسيبل عند كل ميكروفون مستخدَم لتسجيل مصدر الصوت غير المعالج.

• يجب ألا تتضمّن أي معالجة أخرى للإشارات (مثل التحكّم التلقائي في مستوى الصوت أو فلتر الترددات العالية أو إلغاء الصدى) في المسار باستثناء مضاعف المستوى لضبط المستوى على النطاق المطلوب. بعبارة أخرى:

• [C-1-8] إذا كانت هناك أي معالجة للإشارات في البنية لأي سبب، يجب إيقافها وعدم إضافة أي تأخير أو وقت استجابة إضافي إلى مسار الإشارة.
• ‫[C-1-9] يجب ألا يؤدي مضاعف المستوى، مع السماح بوجوده في المسار، إلى حدوث تأخير أو بطء في مسار الإشارة.

يتم إجراء جميع قياسات مستوى ضغط الصوت (SPL) بجانب الميكروفون الخاضع للاختبار مباشرةً. في حال توفّر إعدادات متعددة للميكروفون، تنطبق هذه المتطلبات على كل ميكروفون.

إذا كانت عمليات تنفيذ الأجهزة تعرّف android.hardware.microphone ولكنّها لا تتيح مصدر الصوت غير المعالج، عليها اتّباع ما يلي:

• [C-2-1] يجب أن تعرض null لطريقة AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) API، للإشارة بشكل صحيح إلى عدم التوافق.
• [SR] لا يزال يُنصح بشدة باستيفاء أكبر عدد ممكن من متطلبات مسار الإشارة لمصدر التسجيل غير المعالج.

6. التوافق مع أدوات وخيارات المطوّرين

6.1. أدوات مطوّري البرامج

عمليات تنفيذ الأجهزة:

• [C-0-1] يجب أن تتوافق مع أدوات مطوّري Android المتوفّرة في حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

• أداة تصحيح أخطاء Android (adb)

  • [C-0-2] يجب أن تتوافق مع أداة تصحيح الأخطاء عبر منفذ USB (adb) كما هو موضّح في حزمة تطوير البرامج (SDK) لنظام التشغيل Android وأوامر shell المتوفّرة في مشروع Android مفتوح المصدر (AOSP)، والتي يمكن أن يستخدمها مطوّرو التطبيقات، بما في ذلك dumpsys cmd stats
  • [C-SR] يُنصح بشدة بتوفير دعم لأمر shell cmd testharness.
  • [C-0-3] يجب عدم تغيير تنسيق أو محتوى أحداث نظام الجهاز (batterystats وdiskstats وfingerprint وgraphicsstats وnetstats وnotification وprocstats) التي يتم تسجيلها من خلال الأمر dumpsys.
  • [C-0-10] يجب تسجيل الأحداث التالية بدون حذفها وإتاحتها وإمكانية الوصول إليها من خلال أمر الصدفة cmd stats وفئة واجهة برمجة التطبيقات StatsManager.
    • ActivityForegroundStateChanged
    • AnomalyDetected
    • AppBreadcrumbReported
    • AppCrashOccurred
    • AppStartOccurred
    • BatteryLevelChanged
    • BatterySaverModeStateChanged
    • BleScanResultReceived
    • BleScanStateChanged
    • ChargingStateChanged
    • DeviceIdleModeStateChanged
    • ForegroundServiceStateChanged
    • GpsScanStateChanged
    • JobStateChanged
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • ScreenStateChanged
    • SyncStateChanged
    • SystemElapsedRealtime
    • UidProcessStateChanged
    • WakelockStateChanged
    • WakeupAlarmOccurred
    • WifiLockStateChanged
    • WifiMulticastLockStateChanged
    • WifiScanStateChanged
  • [C-0-4] يجب أن يكون برنامج adb الخفي على الجهاز غير نشط تلقائيًا، ويجب أن تتوفّر آلية يمكن للمستخدم الوصول إليها لتفعيل Android Debug Bridge.
  • [C-0-5] يجب أن يتيح الجهاز تصحيح أخطاء adb الآمن. يتضمّن Android إمكانية استخدام adb الآمن. تتيح ميزة "adb الآمن" استخدام أداة تصحيح الأخطاء adb على الأجهزة المضيفة المعروفة التي تمت مصادقتها.

  • [C-0-6] يجب توفير آلية تسمح بربط أداة تصحيح الأخطاء في Android (adb) من جهاز مضيف. مثلاً:

    • يجب أن تتضمّن عمليات تنفيذ الأجهزة التي لا تحتوي على منفذ USB متوافق مع وضع الأجهزة الطرفية أداة تصحيح الأخطاء adb عبر شبكة المنطقة المحلية (مثل Ethernet أو Wi-Fi).
    • يجب توفير برامج تشغيل لنظام التشغيل Windows 7 و9 و10، ما يتيح للمطوّرين الاتصال بالجهاز باستخدام بروتوكول adb.

• خدمة مراقبة تصحيح الأخطاء في Dalvik (ddms)

  • [C-0-7] يجب أن تتوافق مع جميع ميزات ddms كما هو موضّح في حزمة تطوير البرامج (SDK) لنظام التشغيل Android. بما أنّ ddms تستخدم adb، يجب أن يكون خيار ddms غير نشط تلقائيًا، ولكن يجب أن يكون متاحًا عندما يفعّل المستخدم Android Debug Bridge، كما هو موضّح أعلاه.
• Monkey
  • [C-0-8] يجب تضمين إطار عمل Monkey وإتاحته للتطبيقات لاستخدامه.
• SysTrace
  • [C-0-9] يجب أن يتوافق مع أداة systrace على النحو الموضّح في حزمة تطوير البرامج (SDK) لنظام التشغيل Android. يجب أن يكون Systrace غير نشط تلقائيًا، ويجب أن تتوفّر آلية يمكن للمستخدم الوصول إليها لتفعيل Systrace.

• Perfetto

  • [C-SR] يُنصح بشدة بعرض ملف /system/bin/perfetto ثنائي لمستخدم shell يتوافق سطر الأوامر الخاص به مع مستندات perfetto.
  • [C-SR] يُنصح بشدة بقبول ملف perfetto الثنائي كإدخال لتكوين protobuf يتوافق مع المخطط المحدّد في مستندات perfetto.
  • [C-SR] يُنصح بشدة باستخدام ملف perfetto الثنائي لكتابة أثر protobuf كناتج يتوافق مع المخطط المحدّد في مستندات perfetto.
  • [C-SR] يُنصح بشدة بتوفير مصادر البيانات الموضّحة في مستندات Perfetto على الأقل من خلال ملف Perfetto الثنائي.

• وضع مفعِّل الاختبار

  إذا كانت عمليات تنفيذ الأجهزة تتوافق مع أمر shell cmd testharness وتنفّذ cmd testharness enable، يجب أن:

  • [C-2-1] يجب إرجاع true مقابل ActivityManager.isRunningInUserTestHarness()
  • ‫[C-2-2] يجب تنفيذ "وضع مفعّل الاختبار" على النحو الموضّح في مستندات وضع مفعّل الاختبار.

إذا كانت عمليات تنفيذ الأجهزة تُبلغ عن إمكانية استخدام الإصدار 1.0 من Vulkan أو إصدار أحدث من خلال علامات الميزات android.hardware.vulkan.version، فإنّها:

• [C-1-1] يجب توفير وسيلة تتيح لمطوّر التطبيق تفعيل طبقات تصحيح أخطاء GPU أو إيقافها.
• [C-1-2] يجب، عند تفعيل طبقات تصحيح أخطاء وحدة معالجة الرسومات، تعداد الطبقات في المكتبات التي توفّرها الأدوات الخارجية (أي التي لا تشكّل جزءًا من النظام الأساسي أو حزمة التطبيق) والموجودة في الدليل الأساسي للتطبيقات القابلة للتصحيح من أجل إتاحة طريقتَي واجهة برمجة التطبيقات vkEnumerateInstanceLayerProperties() وvkCreateInstance().

6.2. خيارات المطوّرين

يتضمّن Android إمكانية ضبط الإعدادات المتعلّقة بتطوير التطبيقات.

يجب أن توفّر عمليات تنفيذ الأجهزة تجربة متّسقة لخيارات المطوّرين، ويجب أن:

• [C-0-1] يجب أن يستجيب للغرض android.settings.APPLICATION_DEVELOPMENT_SETTINGS لعرض الإعدادات ذات الصلة بتطوير التطبيقات. يخفي تطبيق Android الأساسي قائمة "خيارات المطوّرين" تلقائيًا ويتيح للمستخدمين تشغيلها بعد النقر سبع (7) مرات على عنصر القائمة الإعدادات > حول الجهاز > رقم الإصدار.
• [C-0-2] يجب إخفاء "خيارات المطوّرين" تلقائيًا.
• [C-0-3] يجب توفير آلية واضحة لا تمنح معاملة تفضيلية لأحد تطبيقات الجهات الخارجية على حساب تطبيق آخر لتفعيل "خيارات المطوّرين". يجب توفير مستند أو موقع إلكتروني متاح للجميع يوضّح كيفية تفعيل "خيارات المطوّرين". يجب أن يكون هذا المستند أو الموقع الإلكتروني قابلاً للربط من مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
• يجب أن يظهر للمستخدم إشعار مرئي مستمر عند تفعيل "خيارات المطوّرين" وعندما تكون سلامة المستخدم موضع قلق.
• قد نحظر مؤقتًا الوصول إلى قائمة "خيارات المطوّرين" من خلال إخفائها بصريًا أو إيقافها، وذلك لتجنُّب تشتيت الانتباه في الحالات التي يكون فيها أمان المستخدم مهمًا.

7. توافُق الأجهزة

إذا كان الجهاز يتضمّن أحد مكونات الأجهزة التي تتضمّن واجهة برمجة تطبيقات للمطوّرين الخارجيين:

• [C-0-1] يجب أن تنفِّذ عملية تنفيذ الجهاز واجهة برمجة التطبيقات هذه على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

إذا كانت إحدى واجهات برمجة التطبيقات في حزمة SDK تتفاعل مع أحد المكوّنات المادية التي يُذكر أنّها اختيارية ولم يتضمّن تصميم الجهاز هذا المكوّن، سيحدث ما يلي:

• [C-0-2] يجب أن تظل تعريفات الفئات الكاملة (كما هو موثّق في حزمة تطوير البرامج (SDK)) لواجهات برمجة التطبيقات الخاصة بالمكوّنات معروضة.
• [C-0-3] يجب تنفيذ سلوكيات واجهة برمجة التطبيقات على أنّها عمليات غير فعّالة بطريقة معقولة.
• [C-0-4] يجب أن تعرض طرق واجهة برمجة التطبيقات قيمًا فارغة حيثما يسمح بذلك مستند حزمة SDK.
• [C-0-5] يجب أن تعرض طرق واجهة برمجة التطبيقات عمليات لا تفعل شيئًا للفئات التي لا تسمح مستندات حزمة تطوير البرامج (SDK) بقيم فارغة فيها.
• [C-0-6] يجب ألا تعرض طرق واجهة برمجة التطبيقات استثناءات غير موثّقة في مستندات حزمة تطوير البرامج (SDK).
• [C-0-7] يجب أن تعرض عمليات تنفيذ الأجهزة معلومات دقيقة عن إعدادات الأجهزة بشكلٍ متّسق من خلال طريقتَي getSystemAvailableFeatures() وhasSystemFeature(String) في فئة android.content.pm.PackageManager لبصمة الإصدار نفسها.

من الأمثلة النموذجية على السيناريوهات التي تنطبق فيها هذه المتطلبات واجهة برمجة تطبيقات الاتصال الهاتفي: حتى على الأجهزة غير الهاتفية، يجب تنفيذ واجهات برمجة التطبيقات هذه كعمليات غير فعّالة معقولة.

‫7.1. العرض والرسومات

يتضمّن نظام التشغيل Android تسهيلات تعمل على تعديل مواد عرض التطبيقات وتنسيقات واجهة المستخدم تلقائيًا بما يتناسب مع الجهاز لضمان تشغيل تطبيقات الجهات الخارجية بشكل جيد على مجموعة متنوعة من إعدادات الأجهزة. على الشاشات المتوافقة مع Android التي يمكن تشغيل جميع التطبيقات المتوافقة مع Android التابعة لجهات خارجية عليها، يجب أن تنفّذ عمليات تنفيذ الأجهزة واجهات برمجة التطبيقات والسلوكيات هذه بشكلٍ سليم، كما هو موضّح بالتفصيل في هذا القسم.

يتم تحديد الوحدات المشار إليها في المتطلبات الواردة في هذا القسم على النحو التالي:

• الحجم القُطري الفعلي المسافة بالبوصة بين زاويتين متقابلتين من الجزء المضاء من الشاشة
• نقاط لكل بوصة (dpi) عدد وحدات البكسل التي يشملها مدى أفقي أو عمودي خطي يبلغ بوصة واحدة. وعند إدراج قيم النقاط لكل بوصة، يجب أن تندرج النقاط الأفقية والعمودية لكل بوصة ضمن النطاق.
• نسبة العرض إلى الارتفاع نسبة وحدات البكسل في البُعد الأطول إلى البُعد الأقصر للشاشة على سبيل المثال، إذا كانت الشاشة تعرض 480 × 854 بكسل، سيكون معدّل العرض إلى الارتفاع 854/480 = 1.779، أو "16:9" تقريبًا.
• وحدة بكسل مستقلة الكثافة (dp) وحدة البكسل الافتراضية التي تمّت تسويتها إلى شاشة بدقة 160 نقطة لكل بوصة، ويتم احتسابها على النحو التالي: وحدات البكسل = وحدات البكسل المستقلة عن الكثافة * (الكثافة/160).

‫7.1.1. إعدادات الشاشة

7.1.1.1. حجم الشاشة وشكلها

يتيح إطار عمل واجهة مستخدم Android مجموعة متنوعة من أحجام تنسيقات الشاشة المنطقية المختلفة، كما يسمح للتطبيقات بالاستعلام عن حجم تنسيق الشاشة للإعداد الحالي من خلال Configuration.screenLayout باستخدام SCREENLAYOUT_SIZE_MASK وConfiguration.smallestScreenWidthDp.

عمليات تنفيذ الأجهزة:

• [C-0-1] يجب أن تعرض Configuration.screenLayout حجم التصميم الصحيح على النحو المحدّد في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android. على وجه التحديد، يجب أن تعرض عمليات تنفيذ الأجهزة أبعاد الشاشة الصحيحة المستندة إلى وحدات البكسل المستقلة عن الكثافة المنطقية (dp) كما هو موضّح أدناه:

  • يجب أن تبلغ أبعاد الأجهزة التي تم ضبط Configuration.uiMode على أي قيمة أخرى غير UI_MODE_TYPE_WATCH، والتي تعرض حجم small لـ Configuration.screenLayout، ‏426 وحدة بكسل مستقلة عن الكثافة × 320 وحدة بكسل مستقلة عن الكثافة على الأقل.
  • يجب أن تتضمّن الأجهزة التي تعرض حجم normal لـ Configuration.screenLayout ما لا يقل عن 480 وحدة بكسل مستقلة عن الكثافة × 320 وحدة بكسل مستقلة عن الكثافة.
  • يجب أن تحتوي الأجهزة التي تعرض حجم large للعنصر Configuration.screenLayout على 640 وحدة بكسل مستقلة عن الكثافة × 480 وحدة بكسل مستقلة عن الكثافة على الأقل.
  • يجب أن تتضمّن الأجهزة التي تعرض حجم xlarge للسمة Configuration.screenLayout ما لا يقل عن 960 وحدة بكسل مستقلة الكثافة × 720 وحدة بكسل مستقلة الكثافة.

• [C-0-2] يجب أن يلتزم الجهاز بشكل صحيح بإتاحة التطبيقات لأحجام الشاشات المحدّدة من خلال السمة <supports-screens> في ملف AndroidManifest.xml، كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

• قد تتضمّن شاشات متوافقة مع Android بزوايا دائرية.

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع UI_MODE_TYPE_NORMAL وتتضمّن الشاشات المتوافقة مع Android ذات الزوايا الدائرية، فإنّها:

• [C-1-1] يجب التأكّد من أنّ نصف قطر الزوايا المنحنية أقل من أو يساوي 38 وحدة بكسل مستقلة عن الكثافة.
• يجب أن تتضمّن إمكانية وصول المستخدم إلى وضع العرض بزوايا مستطيلة.

‫7.1.1.2 نسبة العرض إلى الارتفاع للشاشة

على الرغم من عدم وجود قيود على نسبة العرض إلى الارتفاع للشاشة الفعلية في الشاشات المتوافقة مع Android، يجب أن تستوفي نسبة العرض إلى الارتفاع للشاشة المنطقية التي يتم عرض التطبيقات التابعة لجهات خارجية عليها، والتي يمكن استخلاصها من قيم الارتفاع والعرض التي يتم إرسالها من خلال واجهات برمجة التطبيقات view.Display وواجهات برمجة التطبيقات Configuration، المتطلبات التالية:

• [C-0-1] يجب أن تتضمّن عمليات تنفيذ الأجهزة التي تم ضبط Configuration.uiMode فيها على UI_MODE_TYPE_NORMAL نسبة عرض إلى ارتفاع أقل من أو تساوي 1.86 (حوالي 16:9)، ما لم يستوفِ التطبيق أحد الشروط التالية:

  • أعلن التطبيق أنّه يتيح نسبة عرض إلى ارتفاع أكبر للشاشة من خلال قيمة البيانات الوصفية android.max_aspect.
  • يُعلن التطبيق أنّه يمكن تغيير حجمه من خلال السمة android:resizeableActivity.
  • يستهدف التطبيق المستوى 24 من واجهة برمجة التطبيقات أو المستويات الأحدث ولا يحدّد android:maxAspectRatio من شأنه أن يقيّد نسبة العرض إلى الارتفاع المسموح بها.

• [C-0-2] يجب أن تتضمّن عمليات تنفيذ الأجهزة التي تم ضبط Configuration.uiMode فيها على UI_MODE_TYPE_NORMAL قيمة نسبة عرض إلى ارتفاع تساوي 1.3333 (4:3) أو أكبر، ما لم يكن من الممكن توسيع التطبيق من خلال استيفاء أحد الشروط التالية:

  • يُعلن التطبيق أنّه يمكن تغيير حجمه من خلال السمة android:resizeableActivity.
  • يقدّم التطبيق android:minAspectRatio من شأنه أن يقيّد نسبة العرض إلى الارتفاع المسموح بها.

• [C-0-3] يجب أن تتضمّن عمليات تنفيذ الأجهزة التي تم ضبط Configuration.uiMode فيها على UI_MODE_TYPE_WATCH قيمة نسبة العرض إلى الارتفاع على 1.0 (1:1).

‫7.1.1.3. كثافة الشاشة

يحدّد إطار عمل واجهة مستخدم Android مجموعة من الكثافات المنطقية العادية لمساعدة مطوّري التطبيقات في استهداف موارد التطبيقات.

• [C-0-1] يجب أن تعرض عمليات تنفيذ الأجهزة تلقائيًا إحدى كثافات إطار عمل Android المُدرَجة في DisplayMetrics من خلال واجهة برمجة التطبيقات DENSITY_DEVICE_STABLE، ويجب ألا تتغيّر هذه القيمة في أي وقت. ومع ذلك، يجوز للجهاز عرض كثافة عشوائية مختلفة وفقًا لتغييرات إعدادات الشاشة التي يجريها المستخدم (مثل حجم الشاشة) بعد عملية التشغيل الأولية.

• يجب أن تحدّد عمليات تنفيذ الأجهزة كثافة إطار عمل Android العادي الأقرب عدديًا إلى الكثافة الفعلية للشاشة، ما لم تؤدِّ هذه الكثافة المنطقية إلى خفض حجم الشاشة المُبلَغ عنه إلى أقل من الحد الأدنى المسموح به. إذا كانت كثافة إطار عمل Android العادي الأقرب عدديًا إلى الكثافة الفعلية تؤدي إلى حجم شاشة أصغر من أصغر حجم شاشة متوافق (عرض 320 وحدة بكسل مستقلة الكثافة)، يجب أن تعرض عمليات تنفيذ الأجهزة كثافة إطار عمل Android العادي الأقل التالية.

في حال توفُّر عنصر تحكّم لتغيير حجم العرض على شاشة الجهاز:

• [C-1-1] يجب ألا يتم تغيير حجم العرض إلى أكثر من 1.5 مرة من الكثافة الأصلية أو إنتاج حد أدنى فعّال لأبعاد الشاشة أقل من 320 بكسل مستقل الكثافة (ما يعادل مؤهّل الموارد sw320dp)، أيهما يحدث أولاً.
• [C-1-2] يجب ألا يتم تغيير حجم العرض إلى أقل من 0.85 مرة من الكثافة الأصلية.
• لضمان سهولة الاستخدام وتناسق أحجام الخطوط، يُنصح بتوفير خيارات تغيير الحجم التالية في "الإعلانات الصورية على الأجهزة الجوّالة" (مع الالتزام بالحدود المحدّدة أعلاه)
• صغير: 0.85x
• القيمة التلقائية: 1x (مقياس العرض الأصلي)
• كبير: 1.15x
• أكبر: 1.3x
• الأكبر 1.45x

‫7.1.2 مقاييس الإعلانات الصورية

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشات متوافقة مع Android أو إخراج الفيديو إلى شاشات متوافقة مع Android، يجب أن تستوفي ما يلي:

• [C-1-1] يجب عرض قيم صحيحة لجميع مقاييس العرض المتوافقة مع Android والمحدّدة في واجهة برمجة التطبيقات android.util.DisplayMetrics.

إذا لم تتضمّن عمليات تنفيذ الأجهزة شاشة مدمجة أو إخراج فيديو، يجب أن:

• [C-2-1] يجب عرض القيم الصحيحة للشاشة المتوافقة مع Android على النحو المحدّد في واجهة برمجة التطبيقات android.util.DisplayMetrics للوضع التلقائي المحاكى view.Display.

‫7.1.3. اتجاه الشاشة

عمليات تنفيذ الأجهزة:

• [C-0-1] يجب أن توضّح الأجهزة اتجاهات الشاشة المتوافقة معها (android.hardware.screen.portrait و/أو android.hardware.screen.landscape)، ويجب أن توضّح اتجاهًا واحدًا على الأقل. على سبيل المثال، يجب أن يعرض الجهاز الذي يحتوي على شاشة أفقية ثابتة، مثل التلفزيون أو الكمبيوتر المحمول، القيمة android.hardware.screen.landscape فقط.
• [C-0-2] يجب عرض القيمة الصحيحة لاتجاه الجهاز الحالي عند طلبها من خلال android.content.res.Configuration.orientation أو android.view.Display.getOrientation() أو واجهات برمجة التطبيقات الأخرى.

إذا كانت عمليات تنفيذ الأجهزة تتيح كلا الاتجاهين للشاشة، يجب أن:

• [C-1-1] يجب أن تتيح التطبيقات تغيير اتجاه الشاشة ديناميكيًا إلى الوضع العمودي أو الأفقي. أي أنّ الجهاز يجب أن يلتزم بطلب التطبيق لاتجاه شاشة معيّن.
• [C-1-2] يجب عدم تغيير حجم الشاشة أو كثافتها عند تغيير اتجاهها.
• يمكن اختيار الاتجاه الرأسي أو الأفقي كإعداد تلقائي.

‫7.1.4. تسريع الرسومات الثنائية والثلاثية الأبعاد

‫7.1.4.1 OpenGL ES

عمليات تنفيذ الأجهزة:

• [C-0-1] يجب أن تحدّد بشكل صحيح إصدارات OpenGL ES المتوافقة (1.1 و2.0 و3.0 و3.1 و3.2) من خلال واجهات برمجة التطبيقات المُدارة (مثل طريقة GLES10.getString()) وواجهات برمجة التطبيقات الأصلية.
• [C-0-2] يجب أن تتضمّن دعم جميع واجهات برمجة التطبيقات المُدارة وواجهات برمجة التطبيقات الأصلية لكل إصدارات OpenGL ES التي تم تحديدها على أنّها متوافقة.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة أو إخراج فيديو، يجب أن تستوفي ما يلي:

• [C-1-1] يجب أن تتوافق مع كل من OpenGL ES 1.1 و2.0، كما هو موضّح بالتفصيل في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
• [C-SR] يُنصح بشدة بتوفير دعم OpenGL ES 3.1.
• يجب أن يتوافق مع OpenGL ES 3.2.

إذا كانت عمليات تنفيذ الأجهزة متوافقة مع أي من إصدارات OpenGL ES، يجب أن تستوفي ما يلي:

• [C-2-1] يجب الإبلاغ عن أي إضافات أخرى تم تنفيذها في OpenGL ES من خلال واجهات برمجة التطبيقات المُدارة وواجهات برمجة التطبيقات الأصلية، ويجب عدم الإبلاغ عن سلاسل الإضافات التي لا تتوافق معها.
• [C-2-2] يجب أن تتوافق مع الإضافات EGL_KHR_image وEGL_KHR_image_base وEGL_ANDROID_image_native_buffer وEGL_ANDROID_get_native_client_buffer وEGL_KHR_wait_sync وEGL_KHR_get_all_proc_addresses وEGL_ANDROID_presentation_time وEGL_KHR_swap_buffers_with_damage وEGL_ANDROID_recordable وEGL_ANDROID_GLES_layers.
• [C-SR] يُنصح بشدة بتوفير إمكانية استخدام الإضافتين EGL_KHR_partial_update وOES_EGL_image_external.
• يجب أن يتم الإبلاغ بدقة عن أي تنسيق لضغط النسيج يتوافق معه الجهاز باستخدام الطريقة getString()، ويكون هذا التنسيق عادةً خاصًا بالمورّد.

إذا كانت عمليات تنفيذ الأجهزة تعلن عن التوافق مع OpenGL ES 3.0 أو 3.1 أو 3.2، يجب أن تستوفي ما يلي:

• [C-3-1] يجب تصدير رموز الدالات المتوافقة مع هذه الإصدارات بالإضافة إلى رموز دالات OpenGL ES 2.0 في مكتبة libGLESv2.so.
• [SR] يُنصح بشدة بتوفير دعم لإضافة OES_EGL_image_external_essl3.

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع OpenGL ES 3.2، يجب أن:

• [C-4-1] يجب أن يتوافق الجهاز مع حزمة OpenGL ES Android Extension Pack بالكامل.

في حال كانت عمليات تنفيذ الأجهزة تتوافق مع حزمة Android الإضافية في OpenGL ES بالكامل، فإنّها:

• [C-5-1] يجب تحديد إمكانية التوافق من خلال علامة الميزة android.hardware.opengles.aep.

إذا كانت عمليات تنفيذ الأجهزة توفّر إمكانية استخدام الإضافة EGL_KHR_mutable_render_buffer، عليها استيفاء ما يلي:

• [C-6-1] يجب أن تتوافق أيضًا مع الإضافة EGL_ANDROID_front_buffer_auto_refresh.

‫7.1.4.2 Vulkan

يتوافق نظام التشغيل Android مع Vulkan، وهي واجهة برمجة تطبيقات متوافقة مع عدة أنظمة أساسية وتتطلّب موارد قليلة لتقديم رسومات ثلاثية الأبعاد عالية الأداء.

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع OpenGL ES 3.1، يجب أن:

• [SR] يُنصح بشدة بتضمين إمكانية استخدام Vulkan 1.1.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة أو إخراج فيديو، يجب أن تستوفي ما يلي:

• يجب أن تتضمّن دعم Vulkan 1.1.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية استخدام Vulkan 1.0، يجب أن:

• [C-1-1] يجب عرض قيمة العدد الصحيح الصحيحة باستخدام علامتَي الميزة android.hardware.vulkan.level وandroid.hardware.vulkan.version.
• [C-1-2] يجب إدراج VkPhysicalDevice واحدة على الأقل لواجهة برمجة التطبيقات الأصلية Vulkan vkEnumeratePhysicalDevices() .
• [C-1-3] يجب تنفيذ واجهات برمجة التطبيقات Vulkan 1.0 بالكامل لكل VkPhysicalDevice مُدرَج.
• [C-1-4] يجب تعداد الطبقات المضمّنة في المكتبات المجمّعة من رموز برمجية أصلية والتي تحمل الاسم libVkLayer*.so في دليل المكتبات المجمّعة من رموز برمجية أصلية في حزمة التطبيق، وذلك من خلال واجهات برمجة التطبيقات الأصلية في Vulkan vkEnumerateInstanceLayerProperties() وvkEnumerateDeviceLayerProperties() .
• [C-1-5] يجب عدم تعداد الطبقات التي توفّرها المكتبات خارج حزمة التطبيق، أو توفير طرق أخرى لتتبُّع واجهة برمجة تطبيقات Vulkan أو اعتراضها، ما لم يتم ضبط السمة android:debuggable للتطبيق على true.
• [C-1-6] يجب الإبلاغ عن جميع سلاسل الإضافات التي تتوافق معها من خلال واجهات برمجة التطبيقات الأصلية في Vulkan، ويجب عدم الإبلاغ عن سلاسل الإضافات التي لا تتوافق معها بشكل صحيح.
• [C-1-7] يجب أن تتوافق مع الإضافات VK_KHR_surface وVK_KHR_android_surface وVK_KHR_swapchain وVK_KHR_incremental_present.
• [C-SR] يُنصح بشدة بتوفير الدعم للإضافتين VK_KHR_driver_properties وVK_GOOGLE_display_timing.

إذا لم تتضمّن عمليات تنفيذ الأجهزة إمكانية استخدام Vulkan 1.0، يجب أن:

• [C-2-1] يجب عدم الإفصاح عن أي من مفاتيح إيقاف أو تفعيل ميزات Vulkan (مثل android.hardware.vulkan.level وandroid.hardware.vulkan.version).
• [C-2-2] يجب عدم تعداد أي VkPhysicalDevice لواجهة Vulkan الأصلية vkEnumeratePhysicalDevices().

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة الإصدار 1.1 من Vulkan وتوضّح أيًا من علامات ميزات Vulkan، يجب أن:

• [C-3-1] يجب أن يتيح إمكانية استخدام أنواع SYNC_FD وVK_ANDROID_external_memory_android_hardware_buffer الخارجية من أجل الإشارات الدلالية والتعامل معها.

‫7.1.4.3 RenderScript

• [C-0-1] يجب أن تتوافق عمليات تنفيذ الأجهزة مع Android RenderScript، كما هو موضّح بالتفصيل في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

‫7.1.4.4 تسريع الرسومات الثنائية الأبعاد

يتضمّن نظام التشغيل Android آلية تتيح للتطبيقات الإعلان عن رغبتها في تفعيل ميزة تسريع الأجهزة للرسومات الثنائية الأبعاد على مستوى التطبيق أو النشاط أو النافذة أو العرض من خلال استخدام علامة بيان android:hardwareAccelerated أو طلبات مباشرة من واجهة برمجة التطبيقات.

عمليات تنفيذ الأجهزة:

• [C-0-1] يجب تفعيل ميزة "تسريع الأجهزة" تلقائيًا، ويجب إيقافها إذا طلب المطوّر ذلك من خلال ضبط android:hardwareAccelerated="false” أو إيقافها مباشرةً من خلال واجهات برمجة التطبيقات Android View.
• [C-0-2] يجب أن يظهر سلوك متوافق مع مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android بشأن تسريع الأجهزة.

يتضمّن Android عنصر TextureView يتيح للمطوّرين دمج مواد عرض OpenGL ES التي يتم تسريعها بواسطة الأجهزة مباشرةً كأهداف عرض في تسلسل هرمي لواجهة المستخدم.

عمليات تنفيذ الأجهزة:

• [C-0-3] يجب أن تتوافق مع واجهة برمجة التطبيقات TextureView، ويجب أن يكون سلوكها متوافقًا مع تنفيذ Android في المصدر.

‫7.1.4.5 شاشات العرض ذات النطاق الواسع للألوان

إذا كانت عمليات تنفيذ الأجهزة تدّعي إمكانية استخدام شاشات ذات نطاق ألوان واسع من خلال Configuration.isScreenWideColorGamut()، عليها استيفاء ما يلي:

• [C-1-1] يجب أن تتضمّن شاشة تمت معايرة الألوان فيها.
• ‫[C-1-2] يجب أن يتضمّن الجهاز شاشة تغطّي نطاق ألوان sRGB بالكامل في مساحة CIE 1931 xyY.
• [C-1-3] يجب أن يحتوي الجهاز على شاشة يكون نطاق الألوان فيها بمساحة% 90 على الأقل من DCI-P3 في مساحة CIE 1931 xyY.
• [C-1-4] يجب أن يتوافق الجهاز مع OpenGL ES 3.1 أو 3.2 وأن يعرضه بشكل صحيح.
• [C-1-5] يجب الإعلان عن إمكانية استخدام الإضافات EGL_KHR_no_config_context وEGL_EXT_pixel_format_float وEGL_KHR_gl_colorspace وEGL_EXT_gl_colorspace_scrgb وEGL_EXT_gl_colorspace_scrgb_linear وEGL_EXT_gl_colorspace_display_p3 وEGL_EXT_gl_colorspace_display_p3_linear وEGL_EXT_gl_colorspace_display_p3_passthrough.
• [C-SR] يُنصح بشدة بتوفير GL_EXT_sRGB.

في المقابل، إذا كانت عمليات تنفيذ الأجهزة لا تتوافق مع شاشات الألوان الواسعة، فإنّها:

• [C-2-1] يجب أن تغطي مساحة الألوان sRGB بنسبة% 100 أو أكثر في مساحة CIE 1931 xyY، على الرغم من أنّ نطاق ألوان الشاشة غير محدّد.

‫7.1.5. وضع التوافق مع التطبيقات القديمة

يحدّد نظام التشغيل Android "وضع التوافق" الذي يعمل فيه إطار العمل في وضع مكافئ لحجم الشاشة "العادي" (عرض 320 وحدة بكسل مستقلة الكثافة) لصالح التطبيقات القديمة التي لم يتم تطويرها لإصدارات Android القديمة التي تسبق استقلالية حجم الشاشة.

‫7.1.6. تقنية الشاشة

تتضمّن منصة Android واجهات برمجة تطبيقات تتيح للتطبيقات عرض رسومات غنية على شاشة متوافقة مع Android. يجب أن تتوافق الأجهزة مع جميع واجهات برمجة التطبيقات هذه على النحو المحدّد في حزمة تطوير البرامج (SDK) لنظام التشغيل Android ما لم يُسمح بذلك تحديدًا في هذا المستند.

جميع الشاشات المتوافقة مع Android في تنفيذ الجهاز:

• [C-0-1] يجب أن يكون الجهاز قادرًا على عرض رسومات ملوّنة بدقة 16 بت.
• يجب أن تتوافق مع الشاشات التي يمكنها عرض رسومات بألوان 24 بت.
• [C-0-2] يجب أن يكون الجهاز قادرًا على عرض الصور المتحركة.
• [C-0-3] يجب أن تتراوح نسبة العرض إلى الارتفاع بالبكسل (PAR) بين 0.9 و1.15. أي أنّ نسبة عرض البكسل إلى ارتفاعه يجب أن تكون مربّعة تقريبًا (1.0) مع هامش خطأ يتراوح بين %10 و%15.

‫7.1.7. الشاشات الثانوية

يتيح نظام التشغيل Android استخدام شاشات ثانوية متوافقة مع Android لتفعيل إمكانات مشاركة الوسائط وواجهات برمجة التطبيقات للمطوّرين للوصول إلى الشاشات الخارجية.

إذا كانت عمليات تنفيذ الأجهزة تتيح شاشة خارجية إما عبر اتصال سلكي أو لاسلكي أو اتصال شاشة إضافية مدمجة، يجب أن تستوفي ما يلي:

• [C-1-1] يجب تنفيذ خدمة النظام وواجهة برمجة التطبيقات DisplayManager على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

7.2. أجهزة إدخال بيانات

عمليات تنفيذ الأجهزة:

• [C-0-1] يجب أن يتضمّن آلية إدخال، مثل شاشة تعمل باللمس أو تنقّل غير لمسي، للتنقّل بين عناصر واجهة المستخدم.

‫7.2.1 لوحة المفاتيح

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية استخدام تطبيقات "محرّر أسلوب الإدخال" (IME) التابعة لجهات خارجية، يجب أن تستوفي ما يلي:

• [C-1-1] يجب الإعلان عن علامة الميزة android.software.input_methods.
• [C-1-2] يجب تنفيذ Input Management Framework بالكامل
• [C-1-3] يجب أن يتضمّن لوحة مفاتيح برمجية مثبَّتة مسبقًا.

في عمليات تنفيذ الأجهزة: * [C-0-1] يجب ألا تتضمّن لوحة مفاتيح للأجهزة لا تتطابق مع أحد التنسيقات المحدّدة في android.content.res.Configuration.keyboard (QWERTY أو 12 مفتاحًا). * يجب أن تتضمّن عمليات تنفيذ إضافية للوحة المفاتيح البرمجية. * قد تتضمّن لوحة مفاتيح خارجية.

‫7.2.2 التنقّل بدون لمس

يتوافق نظام التشغيل Android مع لوحة المفاتيح الاتجاهية وكرة التتبّع والعجلة كآليات للتنقّل بدون لمس.

عمليات تنفيذ الأجهزة:

• [C-0-1] يجب عرض القيمة الصحيحة لـ android.content.res.Configuration.navigation.

إذا كانت عمليات تنفيذ الأجهزة تفتقر إلى وسائل التنقّل غير اللمسية، يجب أن:

• [C-1-1] يجب توفير آلية بديلة معقولة لواجهة المستخدم تتيح اختيار النص وتعديله، وتكون متوافقة مع محركات إدارة الإدخال. يتضمّن تنفيذ Android مفتوح المصدر في المصدر آلية اختيار مناسبة للاستخدام مع الأجهزة التي لا تتضمّن أدوات إدخال للتنقّل غير اللمسي.

‫7.2.3 مفاتيح التنقل

تُعدّ وظائف الشاشة الرئيسية والتطبيقات الحديثة والرجوع، التي يتم توفيرها عادةً من خلال التفاعل مع زر فعلي مخصّص أو جزء مميّز من شاشة اللمس، ضرورية لنموذج التنقّل في Android، وبالتالي لعمليات تنفيذ الأجهزة:

• [C-0-1] يجب توفير وسيلة تتيح للمستخدم تشغيل التطبيقات المثبَّتة التي تتضمّن نشاطًا تم ضبط <intent-filter> على ACTION=MAIN وCATEGORY=LAUNCHER أو CATEGORY=LEANBACK_LAUNCHER في عمليات تنفيذ أجهزة التلفزيون. يجب أن تكون وظيفة "الصفحة الرئيسية" هي الآلية التي تتيح للمستخدم الاستفادة من هذه الميزة.
• يجب توفير أزرار لوظيفتَي "التطبيقات المستخدَمة مؤخرًا" و"الرجوع".

في حال توفُّر وظائف "الشاشة الرئيسية" أو "التطبيقات الحديثة" أو "الرجوع"، يجب أن:

• [C-1-1] يجب أن يكون الوصول إلى أي من هذه العناصر ممكنًا من خلال إجراء واحد (مثل النقر أو النقر مرّتين أو الإيماءة).
• [C-1-2] يجب تقديم إشارة واضحة إلى الإجراء الفردي الذي سيؤدي إلى تشغيل كل وظيفة. وتشمل الأمثلة على هذا المؤشر عرض رمز مرئي مطبوع على الزر، أو عرض رمز برنامج على جزء شريط التنقّل من الشاشة، أو توجيه المستخدم خلال عرض توضيحي تفصيلي خطوة بخطوة أثناء تجربة الإعداد الجاهزة للاستخدام.

عمليات تنفيذ الأجهزة:

• [SR] يُنصح بشدة بعدم توفير آلية الإدخال لوظيفة القائمة لأنّها أصبحت قديمة لصالح شريط الإجراءات منذ الإصدار 4.0 من نظام التشغيل Android.

في حال توفير وظيفة "القائمة" في عمليات تنفيذ الأجهزة، يجب أن:

• [C-2-1] يجب عرض زر القائمة الكاملة للإجراءات عندما لا تكون القائمة المنبثقة للقائمة الكاملة للإجراءات فارغة ويكون شريط الإجراءات مرئيًا.
• [C-2-2] يجب عدم تعديل موضع النافذة المنبثقة الخاصة بقائمة الإجراءات الإضافية التي يتم عرضها عند النقر على زر القائمة الإضافية في شريط الإجراءات، ولكن يجوز عرض النافذة المنبثقة الخاصة بقائمة الإجراءات الإضافية في موضع معدَّل على الشاشة عند عرضها من خلال النقر على وظيفة "القائمة".

إذا لم توفّر عمليات تنفيذ الأجهزة وظيفة "القائمة"، ولضمان التوافق مع الإصدارات القديمة، عليها: * [C-SR] يُنصح بشدة بإتاحة وظيفة "القائمة" للتطبيقات عندما تكون قيمة targetSdkVersion أقل من 10، إما من خلال زر فعلي أو مفتاح برنامج أو إيماءات. يجب أن تكون وظيفة "القائمة" متاحة ما لم يتم إخفاؤها مع وظائف التنقّل الأخرى.

إذا كانت عمليات تنفيذ الأجهزة توفّر وظيفة "المساعدة"، عليها استيفاء ما يلي:

• [C-4-1] يجب أن تكون وظيفة "المساعد" متاحة من خلال إجراء واحد (مثل النقر أو النقر مرّتين أو الإيماءة) عندما تكون مفاتيح التنقّل الأخرى متاحة.
• [SR] يُنصح بشدة باستخدام الضغط مع الاستمرار على وظيفة "الشاشة الرئيسية" كطريقة التفاعل المحدّدة هذه.

إذا كانت عمليات تنفيذ الأجهزة تستخدم جزءًا مميزًا من الشاشة لعرض مفاتيح التنقّل، يجب أن:

• [C-5-1] يجب أن تستخدم مفاتيح التنقّل جزءًا مميزًا من الشاشة لا يمكن للتطبيقات الوصول إليه، ويجب ألا تحجب أو تتداخل بأي شكل من الأشكال مع الجزء المتاح للتطبيقات من الشاشة.
• [C-5-2] يجب توفير جزء من الشاشة للتطبيقات يستوفي المتطلبات المحدّدة في الفقرة 7.1.1.
• [C-5-3] يجب الالتزام بالعلامات التي يضبطها التطبيق من خلال طريقة View.setSystemUiVisibility() في واجهة برمجة التطبيقات، وذلك لإخفاء هذا الجزء المميّز من الشاشة (المعروف أيضًا باسم شريط التنقّل) بشكلٍ سليم كما هو موضّح في حزمة تطوير البرامج (SDK).

إذا كانت وظيفة التنقّل متوفّرة كإجراء مستند إلى الإيماءات على الشاشة:

• [C-6-1] يجب استخدام WindowInsets#getMandatorySystemGestureInsets() للإبلاغ عن منطقة التعرّف على إيماءة "الصفحة الرئيسية" فقط.
• [C-6-2] يجب عدم اعتراض الإيماءات التي تبدأ داخل مستطيل الاستبعاد الذي يوفّره التطبيق الذي يعمل في المقدّمة من خلال View#setSystemGestureExclusionRects()، ولكن خارج WindowInsets#getMandatorySystemGestureInsets()، لوظيفة التنقّل طالما أنّ مستطيل الاستبعاد مسموح به ضمن الحدّ الأقصى للاستبعاد كما هو محدّد في مستندات View#setSystemGestureExclusionRects().
• [C-6-3] يجب إرسال حدث MotionEvent.ACTION_CANCEL إلى التطبيق الذي يعمل في المقدّمة عند بدء اعتراض اللمسات لإجراء إيماءة نظام، وذلك إذا سبق أن تم إرسال حدث MotionEvent.ACTION_DOWN إلى التطبيق الذي يعمل في المقدّمة.
• [C-6-4] يجب توفير وسيلة تتيح للمستخدم التبديل إلى التنقّل المستند إلى الأزرار على الشاشة (على سبيل المثال، في "الإعدادات").
• يجب توفير وظيفة "الشاشة الرئيسية" من خلال التمرير سريعًا للأعلى من الحافة السفلية للاتجاه الحالي للشاشة.
• يجب توفير وظيفة "التطبيقات الحديثة" من خلال التمرير سريعًا للأعلى مع الاستمرار في الضغط قبل رفع الإصبع، وذلك من المنطقة نفسها التي يتم منها تنفيذ إيماءة "الصفحة الرئيسية".
• يجب ألا تتأثر الإيماءات التي تبدأ ضمن WindowInsets#getMandatorySystemGestureInsets() بمستطيلات الاستبعاد التي يوفّرها التطبيق الذي يعمل في المقدّمة من خلال View#setSystemGestureExclusionRects().

إذا تم توفير وظيفة تنقّل من أي مكان على الحافتَين اليسرى واليمنى للاتجاه الحالي للشاشة:

• [C-7-1] يجب أن تكون وظيفة التنقّل هي "رجوع" وأن يتم توفيرها من خلال التمرير السريع من الحافتين اليمنى واليسرى للشاشة في اتجاهها الحالي.
• [C-7-2] في حال توفير لوحات نظام مخصّصة يمكن التمرير سريعًا عليها على الحافتين اليسرى أو اليمنى، يجب وضعها ضمن الثلث العلوي من الشاشة مع إشارة مرئية واضحة وثابتة إلى أنّ السحب للداخل سيؤدي إلى استدعاء اللوحات المذكورة أعلاه، وبالتالي لن يتم الرجوع إلى الخلف. يمكن للمستخدم ضبط لوحة النظام بحيث تظهر أسفل الثلث العلوي من حواف الشاشة، ولكن يجب ألا تستخدم لوحة النظام أكثر من ثلث الحواف.
• [C-7-3] عندما يضبط التطبيق الذي يعمل في المقدّمة العلامتَين View.SYSTEM_UI_FLAG_IMMERSIVE أو View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY، يجب أن يكون سلوك التمرير السريع من الحواف مطابقًا للسلوك المحدّد في AOSP، والذي تم توثيقه في حزمة تطوير البرامج (SDK).
• [C-7-4] عندما يكون للتطبيق الذي يعمل في المقدّمة العلامتان View.SYSTEM_UI_FLAG_IMMERSIVE أو View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY، يجب إخفاء لوحات النظام المخصّصة القابلة للتمرير سريعًا إلى أن يعرض المستخدم أشرطة النظام (المعروفة أيضًا باسم شريطَي التنقّل والحالة) كما هو موضّح في AOSP.

‫7.2.4 الإدخال عبر شاشة اللمس

يتوافق Android مع مجموعة متنوعة من أنظمة إدخال المؤشر، مثل الشاشات التي تعمل باللمس ولوحات اللمس وأجهزة إدخال اللمس الوهمي. ترتبط عمليات تنفيذ الأجهزة المستندة إلى شاشة اللمس بشاشة عرض، ما يمنح المستخدم انطباعًا بأنّه يتلاعب مباشرةً بالعناصر الظاهرة على الشاشة. بما أنّ المستخدم يلمس الشاشة مباشرةً، لا يتطلّب النظام أي إشارات إضافية لتوضيح العناصر التي يتم التلاعب بها.

عمليات تنفيذ الأجهزة:

• يجب أن يتضمّن نظام إدخال مؤشر من نوع ما (إما يشبه الماوس أو اللمس).
• يجب أن يتيح تتبُّع المؤشرات بشكل مستقل تمامًا.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة تعمل باللمس (لمسة واحدة أو أكثر)، يجب أن تستوفي ما يلي:

• [C-1-1] يجب عرض القيمة TOUCHSCREEN_FINGER لحقل واجهة برمجة التطبيقات Configuration.touchscreen.
• [C-1-2] يجب الإبلاغ عن علامات الميزة android.hardware.touchscreen وandroid.hardware.faketouch.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة تعمل باللمس ويمكنها تتبُّع أكثر من لمسة واحدة، يجب أن تستوفي ما يلي:

• [C-2-1] يجب عرض علامات الميزات المناسبة android.hardware.touchscreen.multitouch وandroid.hardware.touchscreen.multitouch.distinct وandroid.hardware.touchscreen.multitouch.jazzhand التي تتوافق مع نوع شاشة اللمس المحدّدة على الجهاز.

إذا كانت عمليات تنفيذ الأجهزة لا تتضمّن شاشة تعمل باللمس (وتعتمد على جهاز مؤشر فقط) وتستوفي متطلبات اللمس الزائف الواردة في الفقرة 7.2.5، يجب أن:

• [C-3-1] يجب عدم إرسال أي علامة ميزة تبدأ بـ android.hardware.touchscreen ويجب إرسال android.hardware.faketouch فقط.

‫7.2.5. Fake Touch Input

توفّر الواجهة التي تحاكي عمل الواجهات التي تعمل باللمس نظامًا لإدخال بيانات المستخدم يحاكي مجموعة فرعية من إمكانات الشاشة التي تعمل باللمس. على سبيل المثال، يتيح الماوس أو جهاز التحكّم عن بُعد الذي يحرك مؤشرًا على الشاشة محاكاة اللمس، ولكنّه يتطلّب من المستخدم أولاً توجيه المؤشر أو التركيز عليه ثم النقر. يمكن أن تتوافق العديد من أجهزة الإدخال، مثل الماوس ولوحة اللمس والماوس الهوائي المستند إلى الجيروسكوب والمؤشر المستند إلى الجيروسكوب وعصا التحكّم ولوحة اللمس المتعددة اللمس، مع تفاعلات اللمس الزائف. يتضمّن نظام التشغيل Android الثابت android.hardware.faketouch الخاص بالميزات، والذي يتوافق مع جهاز إدخال عالي الدقة غير مستند إلى اللمس (مستند إلى المؤشر)، مثل الماوس أو لوحة اللمس، ويمكنه محاكاة الإدخال المستند إلى اللمس بشكلٍ كافٍ (بما في ذلك إتاحة الإيماءات الأساسية)، ويشير إلى أنّ الجهاز يتيح مجموعة فرعية محاكاة من وظائف الشاشة التي تعمل باللمس.

إذا كانت عمليات تنفيذ الأجهزة لا تتضمّن شاشة تعمل باللمس ولكنها تتضمّن نظام إدخال مؤشر آخر يريدون إتاحته، عليهم اتّباع ما يلي:

• يجب الإفصاح عن توفّر علامة الميزة android.hardware.faketouch.

في حال إعلان عمليات تنفيذ الأجهزة عن إتاحة android.hardware.faketouch، يجب أن تستوفي ما يلي:

• [C-1-1] يجب أن يتم تسجيل موضعَي X وY المطلقَين على الشاشة لموقع المؤشر وعرض مؤشر مرئي على الشاشة.
• [C-1-2] يجب إرسال حدث اللمس مع رمز الإجراء الذي يحدّد تغيير الحالة الذي يحدث عند تحريك المؤشر للأسفل أو للأعلى على الشاشة.
• ‫[C-1-3] يجب أن يتيح الجهاز الضغط مع الاستمرار على عنصر على الشاشة ورفع الإصبع عنه، ما يسمح للمستخدمين بمحاكاة النقر على عنصر على الشاشة.
• [C-1-4] يجب أن يتيح الجهاز تنفيذ الإجراءات التالية: الضغط بالمؤشر، ورفع المؤشر، والضغط بالمؤشر ثم رفعه في المكان نفسه على أحد العناصر الظاهرة على الشاشة خلال مدة زمنية محددة، ما يتيح للمستخدمين محاكاة النقر المزدوج على أحد العناصر الظاهرة على الشاشة.
• [C-1-5] يجب أن يتيح الجهاز الضغط بالمؤشر على أي نقطة عشوائية على الشاشة، ثم تحريك المؤشر إلى أي نقطة عشوائية أخرى على الشاشة، ثم رفع المؤشر، ما يسمح للمستخدمين بمحاكاة عملية السحب باللمس.
• [C-1-6] يجب أن يتيح للمستخدمين الضغط مع الاستمرار على المؤشر ثم تحريك العنصر بسرعة إلى موضع مختلف على الشاشة ثم رفع المؤشر عن الشاشة، ما يتيح للمستخدمين تحريك العنصر بسرعة على الشاشة.
• [C-1-7] يجب الإبلاغ عن TOUCHSCREEN_NOTOUCH لحقل واجهة برمجة التطبيقات Configuration.touchscreen.

في حال إعلان عمليات تنفيذ الأجهزة عن إتاحة android.hardware.faketouch.multitouch.distinct، يجب أن تستوفي ما يلي:

• [C-2-1] يجب الإعلان عن إتاحة android.hardware.faketouch.
• ‫[C-2-2] يجب أن يتيح تتبُّع إشارتَي إدخال أو أكثر بشكل منفصل.

في حال إعلان عمليات تنفيذ الأجهزة عن إتاحة android.hardware.faketouch.multitouch.jazzhand، يجب أن تستوفي ما يلي:

• [C-3-1] يجب الإعلان عن إتاحة android.hardware.faketouch.
• [C-3-2] يجب أن يتيح تتبُّع 5 إدخالات مؤشر أو أكثر بشكل مستقل تمامًا.

‫7.2.6. التوافق مع وحدات التحكّم في الألعاب

7.2.6.1. عمليات ربط الأزرار

إذا كانت عمليات تنفيذ الأجهزة تتضمّن علامة الميزة android.hardware.gamepad، فإنّها:

• [C-1-1] يجب أن يتضمّن الجهاز وحدة تحكّم مدمجة أو أن يتم شحنه مع وحدة تحكّم منفصلة في العلبة، على أن توفّر هذه الوحدة وسائل لإدخال جميع الأحداث المُدرَجة في الجداول أدناه.
• [C-1-2] يجب أن يكون الجهاز قادرًا على ربط أحداث HID بثوابت Android view.InputEvent المرتبطة بها كما هو موضّح في الجداول أدناه. يتضمّن التنفيذ الأولي لنظام التشغيل Android تنفيذًا لوحدات التحكّم في الألعاب يستوفي هذا الشرط.

‫1 KeyEvent

‫2 يجب الإفصاح عن استخدامات HID المذكورة أعلاه ضمن CA لوحة الألعاب (0x01 0x0005).

‫3 يجب أن يكون لهذا الاستخدام حد أدنى منطقي يبلغ 0، وحد أقصى منطقي يبلغ 7، وحد أدنى فعلي يبلغ 0، وحد أقصى فعلي يبلغ 315، ووحدات بالدرجات، وحجم تقرير يبلغ 4. يتم تحديد القيمة المنطقية على أنّها الدوران في اتجاه عقارب الساعة بعيدًا عن المحور العمودي. على سبيل المثال، تمثّل القيمة المنطقية 0 عدم الدوران والضغط على زرّ الاتجاه للأعلى، بينما تمثّل القيمة المنطقية 1 دورانًا بمقدار 45 درجة والضغط على كلّ من زرّ الاتجاه للأعلى ولليسار.

‫4 MotionEvent

‫1 MotionEvent

‫7.2.7 جهاز التحكّم عن بُعد

يُرجى الاطّلاع على الفقرة 2.3.1 لمعرفة المتطلبات الخاصة بكل جهاز.

‫7.3. أجهزة الاستشعار

إذا كانت عمليات تنفيذ الأجهزة تتضمّن نوعًا معيّنًا من أجهزة الاستشعار يتضمّن واجهة برمجة تطبيقات مقابلة للمطوّرين الخارجيين، يجب أن تنفّذ عملية تنفيذ الجهاز واجهة برمجة التطبيقات هذه على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android ومستندات Android Open Source حول أجهزة الاستشعار.

عمليات تنفيذ الأجهزة:

• [C-0-1] يجب أن يتم الإبلاغ بدقة عن توفّر أجهزة الاستشعار أو عدم توفّرها وفقًا لفئة android.content.pm.PackageManager.
• [C-0-2] يجب عرض قائمة دقيقة بأجهزة الاستشعار المتوافقة من خلال SensorManager.getSensorList() والطرق المشابهة.
• [C-0-3] يجب أن تتصرف بشكل معقول مع جميع واجهات برمجة التطبيقات الأخرى الخاصة بأجهزة الاستشعار (على سبيل المثال، من خلال عرض true أو false حسب الاقتضاء عندما تحاول التطبيقات تسجيل أدوات معالجة الأحداث، وعدم استدعاء أدوات معالجة الأحداث الخاصة بأجهزة الاستشعار عندما لا تكون أجهزة الاستشعار المقابلة متوفرة، وما إلى ذلك).

إذا كانت عمليات تنفيذ الأجهزة تتضمّن نوعًا معيّنًا من أجهزة الاستشعار يتضمّن واجهة برمجة تطبيقات مقابلة للمطوّرين الخارجيين، يجب أن تستوفي ما يلي:

• [C-1-1] يجب تسجيل جميع قياسات المستشعر باستخدام قيم النظام الدولي للوحدات (المترية) ذات الصلة لكل نوع من أنواع المستشعرات على النحو المحدّد في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
• [C-1-2] يجب إرسال بيانات أجهزة الاستشعار بحد أقصى لوقت الاستجابة يبلغ 100 ملي ثانية + 2 * sample_time في حالة بث بيانات جهاز استشعار بحد أقصى لوقت الاستجابة المطلوب يبلغ 0 ملي ثانية عندما يكون معالج التطبيقات نشطًا. لا يشمل هذا التأخير أي تأخيرات في الفلترة.
• [C-1-3] يجب إرسال عيّنة المستشعر الأولى في غضون 400 ملي ثانية + 2 * sample_time من تفعيل المستشعر. من المقبول أن تبلغ دقة هذه العيّنة 0.

• [SR] يجب تسجيل وقت الحدث بالنانو ثانية كما هو محدّد في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android، ما يمثّل الوقت الذي وقع فيه الحدث وتمت مزامنته مع ساعة SystemClock.elapsedRealtimeNano(). يُنصح بشدة بأن تستوفي أجهزة Android الحالية والجديدة هذه المتطلبات لكي تتمكّن من الترقية إلى إصدارات المنصة المستقبلية التي قد يصبح فيها هذا المكوّن إلزاميًا. يجب أن يكون خطأ المزامنة أقل من 100 ملي ثانية.

• [C-1-4] بالنسبة إلى أي واجهة برمجة تطبيقات تشير مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android إلى أنّها مستشعر مستمر، يجب أن توفّر عمليات تنفيذ الأجهزة بشكلٍ مستمر عيّنات بيانات دورية يجب أن يكون فيها التفاوت أقل من %3، ويُعرَّف التفاوت بأنّه الانحراف المعياري للفرق بين قيم الطوابع الزمنية المُسجّلة بين الأحداث المتتالية.

• [C-1-5] يجب التأكّد من أنّ بث أحداث أجهزة الاستشعار يجب ألا يمنع وحدة المعالجة المركزية للجهاز من الدخول في حالة تعليق أو الاستئناف من حالة التعليق.

• عند تفعيل عدّة أجهزة استشعار، يجب ألا يتجاوز استهلاك الطاقة مجموع استهلاك الطاقة المُبلغ عنه لكل جهاز استشعار على حدة.

القائمة أعلاه ليست شاملة، ويجب اعتبار السلوك الموثّق لحزمة تطوير البرامج (SDK) لنظام التشغيل Android ومستندات Android مفتوحة المصدر حول أجهزة الاستشعار مرجعًا موثوقًا.

بعض أنواع المستشعرات مركّبة، ما يعني أنّه يمكن استخلاصها من البيانات المقدَّمة من مستشعر واحد أو أكثر. (تشمل الأمثلة مستشعر الاتجاه ومستشعر التسارع الخطي).

عمليات تنفيذ الأجهزة:

• يجب تنفيذ أنواع المستشعرات هذه، عندما تتضمّن المستشعرات المادية المطلوبة مسبقًا كما هو موضّح في أنواع المستشعرات.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن أداة استشعار مركّبة، يجب أن:

• [C-2-1] يجب تنفيذ المستشعر على النحو الموضّح في مستندات Android Open Source حول المستشعرات المركّبة.

‫7.3.1 مقياس التسارع

عمليات تنفيذ الأجهزة:

• [C-SR] يُنصح بشدة بتضمين مقياس تسارع ثلاثي المحاور.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس تسارع ثلاثي المحاور، يجب أن تستوفي ما يلي:

• [C-1-1] يجب أن يكون الجهاز قادرًا على تسجيل الأحداث بمعدّل تكرار يبلغ 50 هرتز على الأقل.
• [C-1-2] يجب تنفيذ جهاز استشعار TYPE_ACCELEROMETER وإعداد تقرير عنه.
• [C-1-3] يجب الالتزام بنظام إحداثيات مستشعر Android كما هو موضّح بالتفصيل في واجهات برمجة تطبيقات Android.
• ‫[C-1-4] يجب أن يكون الجهاز قادرًا على قياس التسارع من السقوط الحر إلى أربعة أضعاف الجاذبية(4g) أو أكثر على أي محور.
• [C-1-5] يجب أن تبلغ درجة الدقة 12 بت على الأقل.
• [C-1-6] يجب أن يكون الانحراف المعياري أقل من أو يساوي 0.05 متر/ثانية^2، ويجب احتساب الانحراف المعياري لكل محور على أساس العيّنات التي يتم جمعها على مدار 3 ثوانٍ على الأقل بأسرع معدّل أخذ عيّنات.
• [SR] يُنصح بشدة بتنفيذ أداة الاستشعار المركّبة TYPE_SIGNIFICANT_MOTION.
• يُنصح بشدة [SR] بتنفيذ مستشعر TYPE_ACCELEROMETER_UNCALIBRATED وإعداد تقارير عنه. يُنصح بشدة بأن تستوفي أجهزة Android هذا الشرط حتى تتمكّن من الترقية إلى إصدار المنصة المستقبلي الذي قد يصبح فيه هذا الشرط إلزاميًا.
• يجب تنفيذ أجهزة الاستشعار المركّبة TYPE_SIGNIFICANT_MOTION وTYPE_TILT_DETECTOR وTYPE_STEP_DETECTOR وTYPE_STEP_COUNTER كما هو موضّح في مستند حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
• يجب أن يتم تسجيل الأحداث بمعدّل 200 هرتز على الأقل.
• يجب أن تبلغ درجة الدقة 16 بت على الأقل.
• يجب معايرته أثناء الاستخدام إذا تغيّرت الخصائص خلال دورة الحياة وتعويضها، والحفاظ على مَعلمات التعويض بين عمليات إعادة تشغيل الجهاز.
• يجب أن يكون مزوّدًا بمُعدِّل حرارة.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس تسارع ثلاثي المحاور وتم تنفيذ أيّ من أجهزة الاستشعار المركّبة TYPE_SIGNIFICANT_MOTION أو TYPE_TILT_DETECTOR أو TYPE_STEP_DETECTOR أو TYPE_STEP_COUNTER:

• [C-2-1] يجب أن يكون مجموع استهلاك الطاقة أقل من 4 ميغاواط في جميع الأوقات.
• يجب أن يكون كل منهما أقل من 2 ملي واط و0.5 ملي واط عندما يكون الجهاز في حالة ديناميكية أو ثابتة.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس تسارع ثلاثي المحاور وجهاز استشعار جيروسكوب ثلاثي المحاور، يجب أن:

• [C-3-1] يجب تنفيذ أدوات الاستشعار المركّبة TYPE_GRAVITY وTYPE_LINEAR_ACCELERATION.
• [C-SR] يُنصح بشدة بتنفيذ أداة الاستشعار المركّبة TYPE_GAME_ROTATION_VECTOR.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس تسارع ثلاثي المحاور وجهاز استشعار جيروسكوب ثلاثي المحاور وجهاز استشعار مقياس المغناطيسية، فإنّها:

• [C-4-1] يجب تنفيذ أداة استشعار مركّبة TYPE_ROTATION_VECTOR.

‫7.3.2 مقياس المغناطيسية

عمليات تنفيذ الأجهزة:

• [C-SR] يُنصح بشدة بتضمين مقياس مغناطيسي ثلاثي المحاور (بوصلة).

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس مغناطيسية ثلاثي المحاور، يجب أن:

• [C-1-1] يجب تنفيذ مستشعر TYPE_MAGNETIC_FIELD.
• [C-1-2] يجب أن يكون الجهاز قادرًا على تسجيل الأحداث بمعدّل تكرار لا يقل عن 10 هرتز، ويجب أن يسجّل الأحداث بمعدّل تكرار لا يقل عن 50 هرتز.
• [C-1-3] يجب الالتزام بنظام إحداثيات مستشعر Android كما هو موضّح بالتفصيل في واجهات برمجة تطبيقات Android.
• [C-1-4] يجب أن يكون الجهاز قادرًا على قياس المجال المغناطيسي بين ‎-900 µT و‎+900 µT على كل محور قبل التشبع.
• [C-1-5] يجب أن تكون قيمة إزاحة الحديد الصلب أقل من 700 ميكرو تسلا، ويجب أن تكون القيمة أقل من 200 ميكرو تسلا، وذلك عن طريق وضع مقياس المغناطيسية بعيدًا عن المجالات المغناطيسية الديناميكية (الناتجة عن التيار) والثابتة (الناتجة عن المغناطيس).
• ‫[C-1-6] يجب أن تكون درجة الدقة مساوية لـ 0.6 ميكرو تسلا أو أعلى.
• [C-1-7] يجب أن يتيح المعايرة والتعويض على الإنترنت عن انحياز الحديد الصلب، وأن يحتفظ بمَعلمات التعويض بين عمليات إعادة تشغيل الجهاز.
• [C-1-8] يجب تطبيق تعويض الحديد اللين، ويمكن إجراء عملية المعايرة أثناء الاستخدام أو أثناء إنتاج الجهاز.
• [C-1-9] يجب أن يتضمّن انحرافًا معياريًا يتم احتسابه على أساس كل محور من العيّنات التي يتم جمعها على مدار فترة لا تقل عن 3 ثوانٍ بأسرع معدّل لأخذ العيّنات، وبقيمة لا تزيد عن 1.5 ميكرو تسلا، ويجب أن يتضمّن انحرافًا معياريًا بقيمة لا تزيد عن 0.5 ميكرو تسلا.
• يجب تنفيذ أداة الاستشعار TYPE_MAGNETIC_FIELD_UNCALIBRATED.
• [SR] يُنصح بشدة بأن تتضمّن أجهزة Android الحالية والجديدة مستشعر TYPE_MAGNETIC_FIELD_UNCALIBRATED.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس مغناطيسية ثلاثي المحاور وجهاز استشعار تسارع وجهاز استشعار جيروسكوب ثلاثي المحاور، يجب أن تستوفي ما يلي:

• [C-2-1] يجب تنفيذ أداة استشعار مركّبة TYPE_ROTATION_VECTOR.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس مغناطيسية ثلاثي المحاور ومقياس تسارع، يجب أن:

• يمكن تنفيذ أداة الاستشعار TYPE_GEOMAGNETIC_ROTATION_VECTOR.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس مغناطيسية ثلاثي المحاور ومقياس تسارع ومستشعر TYPE_GEOMAGNETIC_ROTATION_VECTOR، يجب أن تستوفي ما يلي:

• ‫[C-3-1] يجب أن يستهلك أقل من 10 ميغاواط.
• يجب أن يستهلك أقل من 3 ملي واط عند تسجيل المستشعر لوضع الدُفعات بمعدّل 10 هرتز.

‫7.3.3 نظام تحديد المواقع العالمي (GPS)

عمليات تنفيذ الأجهزة:

• [C-SR] يُنصح بشدة بتضمين جهاز استقبال GPS/GNSS.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن جهاز استقبال GPS/GNSS وتُبلغ التطبيقات بإمكانية استخدامها من خلال علامة الميزة android.hardware.location.gps، عليها استيفاء ما يلي:

• ‫[C-1-1] يجب أن يتيح إخراج بيانات الموقع الجغرافي بمعدّل مرّة واحدة على الأقل في الثانية عند الطلب عبر LocationManager#requestLocationUpdate.
• [C-1-2] يجب أن يكون الجهاز قادرًا على تحديد الموقع الجغرافي في ظروف السماء المفتوحة (إشارات قوية، وتعدد مسارات ضئيل، ودقة تحديد الموقع الأفقي (HDOP) أقل من 2) في غضون 10 ثوانٍ (سرعة تحديد الموقع الجغرافي لأول مرة)، وذلك عند الاتصال بشبكة إنترنت بسرعة بيانات تبلغ 0.5 ميغابت في الثانية أو أكثر. يتم استيفاء هذا الشرط عادةً باستخدام شكل من أشكال تقنية نظام تحديد المواقع العالمي (GPS) أو نظام الملاحة العالمي عبر الأقمار الصناعية (GNSS) المُساعِد أو المتوقّع لتقليل وقت تحديد الموقع الجغرافي باستخدام نظام تحديد المواقع العالمي (GPS) أو نظام الملاحة العالمي عبر الأقمار الصناعية (GNSS) (تتضمّن بيانات المساعدة الوقت المرجعي والموقع الجغرافي المرجعي والمدار الفلكي/الساعة للقمر الصناعي).
  • [C-1-6] بعد إجراء عملية حسابية للموقع الجغرافي، يجب أن تحدّد عمليات تنفيذ الجهاز الموقع الجغرافي في السماء المفتوحة في غضون 5 ثوانٍ، وذلك عند إعادة تشغيل طلبات الموقع الجغرافي، ولمدّة تصل إلى ساعة واحدة بعد عملية حساب الموقع الجغرافي الأولية، حتى عندما يتم تقديم الطلب اللاحق بدون اتصال بيانات و/أو بعد إعادة التشغيل.

• في ظروف السماء المفتوحة بعد تحديد الموقع الجغرافي، سواء كنت ثابتًا أو تتحرّك بتسارع أقل من متر واحد في الثانية المربعة:

  • ‫[C-1-3] يجب أن يكون الجهاز قادرًا على تحديد الموقع الجغرافي في نطاق 20 مترًا، والسرعة في نطاق 0.5 متر في الثانية، وذلك بنسبة% 95 على الأقل من الوقت.
  • ‫[C-1-4] يجب تتبُّع 8 أقمار صناعية على الأقل من مجموعة واحدة وإرسال بياناتها في الوقت نفسه عبر GnssStatus.Callback.
  • يجب أن يكون الجهاز قادرًا على تتبُّع 24 قمرًا صناعيًا على الأقل في الوقت نفسه، من مجموعات متعددة (مثل نظام تحديد المواقع العالمي (GPS) وقمر واحد على الأقل من Glonass أو Beidou أو Galileo).
  • [C-SR] يُنصح بشدة بمواصلة تقديم نواتج الموقع الجغرافي العادية لنظام تحديد المواقع العالمي (GPS) أو نظام الملاحة العالمي عبر الأقمار الصناعية (GNSS) من خلال واجهات برمجة التطبيقات الخاصة بمزوّد الموقع الجغرافي لنظام GNSS أثناء مكالمة هاتفية للطوارئ.
  • [C-SR] يُنصح بشدة بالإبلاغ عن قياسات GNSS من جميع المجموعات التي يتم تتبّعها (كما هو موضّح في رسائل GnssStatus)، باستثناء SBAS.
  • [C-SR] يُنصح بشدة بالإبلاغ عن محتوى من إنشاء الذكاء الاصطناعي التوليدي، وعن عدد مرات قياس نظام GNSS.
  • [C-SR] يُنصح بشدة بإرسال جميع تقديرات الدقة (بما في ذلك الاتجاه والسرعة والارتفاع) كجزء من كل موقع جغرافي لنظام تحديد المواقع العالمي (GPS) أو نظام GNSS.
  • [C-SR] يُنصح بشدة بالإبلاغ عن قياسات نظام GNSS فور العثور عليها، حتى إذا لم يتم الإبلاغ عن الموقع الجغرافي المحسوب من نظام GPS/GNSS بعد.
  • [C-SR] يُنصح بشدة بإرسال نطاقات زائفة ومعدلات نطاقات زائفة لنظام GNSS، والتي تكون كافية لاحتساب الموقع الجغرافي في نطاق 20 مترًا والسرعة في نطاق 0.2 متر في الثانية، وذلك بنسبة% 95 على الأقل من الوقت، في ظروف السماء المفتوحة بعد تحديد الموقع الجغرافي، وأثناء الثبات أو الحركة بمعدل تسارع أقل من 0.2 متر في الثانية المربعة.

‫7.3.4. الجيروسكوب

عمليات تنفيذ الأجهزة:

• [C-SR] يُنصح بشدة بتضمين مستشعر جيروسكوب ما لم يتم تضمين مقياس تسارع ثلاثي المحاور أيضًا.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن جيروسكوبًا ثلاثي المحاور، يجب أن تستوفي ما يلي:

• [C-1-1] يجب أن يكون الجهاز قادرًا على تسجيل الأحداث بمعدّل تكرار يبلغ 50 هرتز على الأقل.
• [C-1-2] يجب تنفيذ أداة الاستشعار TYPE_GYROSCOPE ويُنصح بشدة بتنفيذ أداة الاستشعار TYPE_GYROSCOPE_UNCALIBRATED أيضًا.
• [C-1-4] يجب أن تكون درجة الدقة 12 بت أو أكثر، ويجب أن تكون 16 بت أو أكثر.
• [C-1-5] يجب أن يتم تعويض درجة الحرارة.
• ‫[C-1-6] يجب معايرته وتعويضه أثناء الاستخدام، والاحتفاظ بمعلمات التعويض بين عمليات إعادة تشغيل الجهاز.
• [C-1-7] يجب ألا يزيد التباين عن 1e-7 rad^2 / s^2 لكل هرتز (التباين لكل هرتز، أو rad^2 / s). يُسمح بتفاوت التباين مع معدّل أخذ العينات، ولكن يجب أن يكون مقيّدًا بهذه القيمة. بمعنى آخر، إذا قست التباين في الجيروسكوب بمعدل أخذ عينات يبلغ 1 هرتز، يجب ألا يكون أكبر من 1e-7 rad^2/s^2.
• [SR] يُنصح بشدة بأن يكون خطأ المعايرة أقل من 0.01 راديان/ثانية عندما يكون الجهاز ثابتًا في درجة حرارة الغرفة.
• يجب أن يتم تسجيل الأحداث بمعدّل 200 هرتز على الأقل.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن جيروسكوبًا ثلاثي المحاور ومقياس تسارع ومقياس مغناطيسية، يجب أن:

• [C-2-1] يجب تنفيذ أداة استشعار مركّبة TYPE_ROTATION_VECTOR.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس تسارع ثلاثي المحاور وجهاز استشعار جيروسكوب ثلاثي المحاور، يجب أن:

• [C-3-1] يجب تنفيذ أدوات الاستشعار المركّبة TYPE_GRAVITY وTYPE_LINEAR_ACCELERATION.
• [C-SR] يُنصح بشدة بتنفيذ أداة الاستشعار المركّبة TYPE_GAME_ROTATION_VECTOR.

‫7.3.5. مقياس الضغط الجوي

عمليات تنفيذ الأجهزة:

• [C-SR] يُنصح بشدة بتضمين مقياس للضغط الجوي (جهاز استشعار ضغط الهواء المحيط).

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياسًا للضغط الجوي، يجب أن:

• [C-1-1] يجب تنفيذ جهاز الاستشعار TYPE_PRESSURE والإبلاغ عنه.
• [C-1-2] يجب أن يكون الجهاز قادرًا على عرض الأحداث بمعدّل 5 هرتز أو أكثر.
• [C-1-3] يجب أن يكون مزوّدًا بمُعدِّل حرارة.
• [SR] يُنصح بشدة بتوفير إمكانية تسجيل قياسات الضغط في النطاق من 300 هكتوباسكال إلى 1100 هكتوباسكال.
• يجب أن تبلغ الدقة المطلقة 1 هكتوباسكال.
• يجب أن تبلغ الدقة النسبية 0.12 هكتوباسكال على مدى 20 هكتوباسكال (أي ما يعادل دقة تبلغ مترًا واحدًا على مدى تغيير يبلغ 200 متر تقريبًا عند مستوى سطح البحر).

‫7.3.6. مقياس درجة الحرارة

عمليات تنفيذ الأجهزة:

• قد يتضمّن مقياس حرارة محيطة (جهاز استشعار الحرارة).
• يمكن أن يتضمّن جهاز استشعار درجة حرارة وحدة المعالجة المركزية، ولكن لا يُنصح بذلك.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن ميزان حرارة محيط (أداة استشعار درجة الحرارة)، يجب أن تستوفي ما يلي:

• [C-1-1] يجب أن يتم تحديدها على أنّها SENSOR_TYPE_AMBIENT_TEMPERATURE ويجب أن تقيس درجة الحرارة المحيطة (الغرفة/مقصورة المركبة) من المكان الذي يتفاعل فيه المستخدم مع الجهاز بالدرجات المئوية.
• [C-1-2] يجب أن يتم تحديدها على أنّها SENSOR_TYPE_TEMPERATURE.
• [C-1-3] يجب قياس درجة حرارة وحدة المعالجة المركزية للجهاز.
• [C-1-4] يجب ألا يقيس أي درجة حرارة أخرى.

يُرجى العِلم أنّه تم إيقاف نوع أداة الاستشعار SENSOR_TYPE_TEMPERATURE نهائيًا في 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 التي:

  • يجب أن يتضمّن نطاق قياس بين ‎-8g و‎+8g على الأقل، ويُفضّل أن يتضمّن نطاق قياس بين ‎-16g و‎+16g على الأقل.
  • يجب أن تبلغ درجة دقة القياس 2048 LSB/g على الأقل.
  • يجب أن يكون الحدّ الأدنى لتردّد القياس 12.5 هرتز أو أقل.
  • يجب أن يكون الحد الأقصى لتردد القياس 400 هرتز أو أعلى، ويجب أن يتوافق مع SensorDirectChannel RATE_VERY_FAST.
  • يجب ألا يتجاوز التشويش في القياس 400 ميكروغرام/√هرتز.
  • يجب تنفيذ شكل غير نشط من أداة الاستشعار هذه مع إمكانية التخزين المؤقت لما لا يقل عن 3000 حدث من أحداث أداة الاستشعار.
  • يجب ألا يزيد استهلاك الطاقة في عملية تجميع البيانات عن 3 ملي واط.
  • [C-SR] يُنصح بشدة أن يكون عرض نطاق قياس نسبة الإشارة إلى الضوضاء (SNR) يبلغ% 80 على الأقل من تردد Nyquist، وأن يكون طيف الضوضاء البيضاء ضمن عرض النطاق هذا.
  • يجب أن يكون معدّل التغيّر العشوائي في التسارع أقل من 30 ميكروغرام √هرتز عند اختباره في درجة حرارة الغرفة.
  • يجب أن يكون تغيُّر الانحياز مقابل درجة الحرارة ≤ ‎+/- 1 mg/°C.
  • يجب أن يكون الانحراف عن الخط المستقيم لأفضل تطابق ≤ 0.5%، وتغيُّر الحساسية مقابل درجة الحرارة ≤ 0.03%/درجة مئوية.
  • يجب أن تبلغ حساسية المحور المتقاطع أقل من % 2.5 وأن يبلغ تباين حساسية المحور المتقاطع أقل من% 0.2 في نطاق درجة حرارة تشغيل الجهاز.

• [C-2-2] يجب أن تتضمّن TYPE_ACCELEROMETER_UNCALIBRATED تستوفي متطلبات الجودة نفسها التي تستوفيها TYPE_ACCELEROMETER.

• [C-2-3] يجب أن يحتوي على أداة استشعار TYPE_GYROSCOPE تعمل على:

  • يجب أن يتضمّن نطاق قياس بين 1000- و1000+ وحدة على الأقل.
  • يجب أن تبلغ دقة القياس 16 LSB/dps على الأقل.
  • يجب أن يكون الحدّ الأدنى لتردّد القياس 12.5 هرتز أو أقل.
  • يجب أن يكون الحد الأقصى لتردد القياس 400 هرتز أو أعلى، ويجب أن يتوافق مع SensorDirectChannel RATE_VERY_FAST.
  • يجب ألا يتجاوز تشويش القياس 0.014 درجة/ثانية/√هرتز.
  • [C-SR] يُنصح بشدة أن يكون عرض نطاق قياس نسبة الإشارة إلى الضوضاء (SNR) يبلغ% 80 على الأقل من تردد Nyquist، وأن يكون طيف الضوضاء البيضاء ضمن عرض النطاق هذا.
  • يجب أن يكون معدّل المشي العشوائي أقل من 0.001 درجة/ثانية √هرتز عند اختباره في درجة حرارة الغرفة.
  • يجب أن يكون التغيير في الانحياز مقارنةً بدرجة الحرارة ≤ ‎+/- 0.05 °/ s / °C.
  • يجب أن يكون معدّل تغيُّر الحساسية مقارنةً بدرجة الحرارة ≤ 0.02% / درجة مئوية.
  • يجب أن يكون الانحراف عن الخطية لأفضل خط مناسب ≤ 0.2%.
  • يجب أن تبلغ كثافة التشويش ≤ 0.007 درجة/ثانية/√هرتز.
  • يجب أن يكون خطأ المعايرة أقل من 0.002 راديان/ثانية في نطاق درجة الحرارة من 10 إلى 40 درجة مئوية عندما يكون الجهاز ثابتًا.
  • يجب أن تكون حساسية الجاذبية أقل من 0.1 درجة/ثانية/غرام.
  • يجب أن تبلغ حساسية المحور المتقاطع < 4.0 % وأن يبلغ تباين حساسية المحور المتقاطع < 0.3% في نطاق درجة حرارة تشغيل الجهاز.

• [C-2-4] يجب أن تتضمّن TYPE_GYROSCOPE_UNCALIBRATED تستوفي متطلبات الجودة نفسها التي تستوفيها TYPE_GYROSCOPE.

• [C-2-5] يجب أن يحتوي على أداة استشعار TYPE_GEOMAGNETIC_FIELD التي:

  • يجب أن يتضمّن نطاق قياس بين 900- و900+ ميكرو تسلا على الأقل.
  • يجب أن تبلغ دقة القياس 5 LSB/uT على الأقل.
  • يجب أن يكون الحدّ الأدنى لتكرار القياس 5 هرتز أو أقل.
  • يجب أن يكون الحد الأقصى لوتيرة القياس 50 هرتز أو أكثر.
  • يجب ألا يتجاوز التشويش في القياس 0.5 ميكرو تسلا.

• [C-2-6] يجب أن تتضمّن TYPE_MAGNETIC_FIELD_UNCALIBRATED مع متطلبات الجودة نفسها التي تنطبق على TYPE_GEOMAGNETIC_FIELD، بالإضافة إلى ما يلي:

  • يجب تنفيذ شكل غير مفعَّل من هذا المستشعر مع إمكانية تخزين مؤقت لما لا يقل عن 600 حدث من أحداث المستشعر.
  • [C-SR] يُنصح بشدة بأن يتضمّن الطيف الضوضائي الأبيض نطاقًا من 1 هرتز إلى 10 هرتز على الأقل عندما يكون معدّل إعداد التقارير 50 هرتز أو أعلى.

• [C-2-7] يجب أن يحتوي على أداة استشعار TYPE_PRESSURE تتضمّن ما يلي:

  • يجب أن يتراوح نطاق القياس بين 300 و1100 هكتوباسكال على الأقل.
  • يجب أن تبلغ دقة القياس 80 LSB/hPa على الأقل.
  • يجب أن يكون الحدّ الأدنى لتردّد القياس 1 هرتز أو أقل.
  • يجب أن يكون الحد الأقصى لعدد مرات القياس 10 هرتز أو أكثر.
  • يجب ألا يتجاوز التشويش في القياس 2 Pa/√Hz.
  • يجب تنفيذ شكل غير مفعّل لهذا المستشعر مع إمكانية التخزين المؤقت لما لا يقل عن 300 حدث من أحداث المستشعر.
  • يجب أن يكون استهلاك الطاقة في عملية تجميع البيانات لا يزيد عن 2 ملي واط.
• [C-2-8] يجب أن يحتوي على مستشعر TYPE_GAME_ROTATION_VECTOR.
• [C-2-9] يجب أن يتضمّن الجهاز مستشعر TYPE_SIGNIFICANT_MOTION يستوفي الشروط التالية:
  • يجب ألا يزيد استهلاك الطاقة عن 0.5 ملي واط عندما يكون الجهاز ثابتًا و1.5 ملي واط عندما يكون الجهاز متحركًا.
• [C-2-10] يجب أن يتضمّن الجهاز أداة استشعار TYPE_STEP_DETECTOR تستوفي الشروط التالية:
  • يجب تنفيذ شكل غير مُفعِّل لهذا المستشعر مع إمكانية التخزين المؤقت لما لا يقل عن 100 حدث من أحداث المستشعر.
  • يجب ألا يزيد استهلاك الطاقة عن 0.5 ملي واط عندما يكون الجهاز ثابتًا و1.5 ملي واط عندما يكون الجهاز متحركًا.
  • يجب ألا يزيد استهلاك الطاقة في عملية تجميع البيانات عن 4 ملي واط.
• [C-2-11] يجب أن يتضمّن الجهاز أداة استشعار TYPE_STEP_COUNTER تستوفي الشروط التالية:
  • يجب ألا يزيد استهلاك الطاقة عن 0.5 ملي واط عندما يكون الجهاز ثابتًا و1.5 ملي واط عندما يكون الجهاز متحركًا.
• [C-2-12] يجب أن يتضمّن الجهاز أداة استشعار TILT_DETECTOR تستوفي الشروط التالية:
  • يجب ألا يزيد استهلاك الطاقة عن 0.5 ملي واط عندما يكون الجهاز ثابتًا و1.5 ملي واط عندما يكون الجهاز متحركًا.
• ‫[C-2-13] يجب أن يكون الطابع الزمني للحدث الفعلي نفسه الذي يتم تسجيله بواسطة مقياس التسارع والجيروسكوب ومقياس المغناطيسية في نطاق 2.5 ملي ثانية من بعضها البعض. يجب أن يكون الطابع الزمني للحدث الفعلي نفسه الذي تمّ تسجيله بواسطة مقياس التسارع والجيروسكوب في حدود 0.25 ملي ثانية من بعضهما البعض.
• [C-2-14] يجب أن تتضمّن الطوابع الزمنية لأحداث مستشعر الجيروسكوب قاعدة زمنية مماثلة لقاعدة نظام الكاميرا الفرعي، وأن يكون الخطأ في حدود 1 ملي ثانية.
• [C-2-15] يجب أن يتم تسليم العيّنات إلى التطبيقات في غضون 5 ملي ثانية من الوقت الذي تصبح فيه البيانات متاحة على أي من أجهزة الاستشعار المادية المذكورة أعلاه للتطبيق.
• [C-2-16] يجب ألا يزيد استهلاك الطاقة عن 0.5 ملي واط عندما يكون الجهاز ثابتًا و2.0 ملي واط عندما يكون الجهاز متحركًا عند تفعيل أي مجموعة من أجهزة الاستشعار التالية:
  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS
• [C-2-17] قد يتضمّن جهاز TYPE_PROXIMITY مستشعرًا، ولكن في حال توفّره، يجب أن تتوفّر فيه سعة تخزين مؤقت لا تقل عن 100 حدث مستشعر.

يُرجى العِلم أنّ جميع متطلبات استهلاك الطاقة الواردة في هذا القسم لا تشمل استهلاك الطاقة في معالج التطبيقات. ويشمل ذلك الطاقة التي تستهلكها سلسلة المستشعرات بأكملها، أي المستشعر وأي دوائر كهربائية مساعدة وأي نظام مخصّص لمعالجة بيانات المستشعر وما إلى ذلك.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية استخدام المستشعر مباشرةً، يجب أن تستوفي ما يلي:

• [C-3-1] يجب الإفصاح بشكل صحيح عن إمكانية استخدام أنواع القنوات المباشرة ومعدّلات التقارير المباشرة من خلال واجهتَي برمجة التطبيقات isDirectChannelTypeSupported وgetHighestDirectReportRateLevel.
• ‫[C-3-2] يجب أن تتوافق مع نوع واحد على الأقل من نوعَي قنوات الاتصال المباشر بأجهزة الاستشعار لجميع أجهزة الاستشعار التي تعلن عن توافقها مع قنوات الاتصال المباشر بأجهزة الاستشعار.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• يجب أن يتيح إعداد تقارير الأحداث من خلال القناة المباشرة لأداة الاستشعار لأداة الاستشعار الأساسية (النوع غير المفعّل عند الاستيقاظ) من الأنواع التالية:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

‫7.3.10 أجهزة استشعار المقاييس الحيوية

للحصول على معلومات أساسية إضافية حول قياس أمان فتح قفل الجهاز باستخدام المقاييس الحيوية، يُرجى الاطّلاع على مستندات قياس أمان المقاييس الحيوية.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة قفل آمنة، يجب أن تستوفي ما يلي:

• يجب أن يتضمّن مستشعرًا للمقاييس الحيوية

يمكن تصنيف أجهزة استشعار المقاييس الحيوية على أنّها قوية أو ضعيفة أو مريحة استنادًا إلى معدلات قبولها لعمليات التزييف وانتحال الهوية، وإلى أمان مسار المقاييس الحيوية. يحدّد هذا التصنيف الإمكانات التي يجب أن يتوافق معها مستشعر المقاييس الحيوية مع النظام الأساسي والتطبيقات التابعة لجهات خارجية. يتم تصنيف أجهزة الاستشعار على أنّها أجهزة استشعار ملائمة تلقائيًا، ويجب أن تستوفي متطلبات إضافية على النحو المفصّل أدناه إذا أرادت أن يتم تصنيفها على أنّها أجهزة استشعار ضعيفة أو أجهزة استشعار قوية. تتوفّر إمكانات إضافية لكل من المقاييس الحيوية الضعيفة والقوية كما هو موضّح أدناه.

لإتاحة استخدام مستشعر المقاييس الحيوية للتطبيقات التابعة لجهات خارجية، يجب أن تتضمّن عمليات تنفيذ الأجهزة ما يلي:

• [C-0-1] يجب استيفاء متطلبات المقاييس الحيوية القوية أو الضعيفة على النحو المحدّد في هذا المستند.

للسماح للتطبيقات الخارجية بالوصول إلى مفاتيح keystore، يجب أن تتضمّن عمليات تنفيذ الأجهزة ما يلي:

• [C-0-2] يجب استيفاء متطلبات القوة المحدّدة في هذا المستند.

علاوةً على ذلك:

• [C-0-3] يجب أن يكون مصحوبًا بإجراء تأكيد صريح (مثل الضغط على زر) إذا كانت المقاييس الحيوية القوية غير نشطة (مثل الوجه أو قزحية العين حيث لا توجد إشارة صريحة إلى نية المستخدم).
  • [C-SR] يُنصح بشدة بتأمين إجراء التأكيد للمقاييس الحيوية غير النشطة بطريقة لا يمكن فيها تزويرها من خلال اختراق نظام التشغيل أو النواة. على سبيل المثال، يعني ذلك أنّه يتم توجيه إجراء التأكيد المستند إلى زر فعلي من خلال دبوس إدخال/إخراج للأغراض العامة (GPIO) مخصّص للإدخال فقط في عنصر آمن (SE) لا يمكن تشغيله بأي وسيلة أخرى غير الضغط على زر فعلي.

إذا كانت عمليات تنفيذ الأجهزة تريد التعامل مع أداة استشعار المقاييس الحيوية على أنّها ميزة ملائمة، عليها إجراء ما يلي:

• [C-1-1] يجب أن يكون معدّل القبول الخاطئ أقل من %0.002.
• [C-1-2] يجب الإفصاح عن أنّ هذا الوضع قد يكون أقل أمانًا من استخدام رقم تعريف شخصي أو نقش أو كلمة مرور قوية، ويجب توضيح مخاطر تفعيله إذا كانت معدّلات قبول الانتحال والتزوير أعلى من %7.
• [C-1-3] يجب فرض حدّ أقصى لعدد محاولات التحقّق من المقاييس الحيوية لمدة 30 ثانية على الأقل بعد خمس محاولات خاطئة، حيث تكون المحاولة الخاطئة هي المحاولة التي تتضمّن جودة التقاط كافية (BIOMETRIC_ACQUIRED_GOOD) ولا تتطابق مع مقياس حيوي مسجّل.
• [C-1-4] يجب منع إضافة مقاييس حيوية جديدة بدون إنشاء سلسلة ثقة أولاً من خلال مطالبة المستخدم بتأكيد بيانات اعتماد الجهاز الحالية أو إضافة بيانات اعتماد جديدة (رقم تعريف شخصي أو نقش أو كلمة مرور) يتم تأمينها بواسطة TEE. يوفّر تطبيق "مشروع Android مفتوح المصدر" الآلية اللازمة في إطار العمل لإجراء ذلك.
• [C-1-5] يجب إزالة جميع بيانات القياسات الحيوية المحددة للهوية الخاصة بالمستخدم تمامًا عند إزالة حساب المستخدم (بما في ذلك من خلال إعادة الضبط على الإعدادات الأصلية).
• [C-1-6] يجب الالتزام بالعلامة الفردية الخاصة بالمقياس الحيوي (أي DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT أو DevicePolicymanager.KEYGUARD_DISABLE_FACE أو DevicePolicymanager.KEYGUARD_DISABLE_IRIS ).
• [C-1-7] يجب أن يطلب الجهاز من المستخدم إدخال طريقة المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) مرة واحدة كل 24 ساعة أو أقل للأجهزة الجديدة التي تعمل بالإصدار 10 من نظام التشغيل Android، ومرة واحدة كل 72 ساعة أو أقل للأجهزة التي تمت ترقيتها من إصدار Android أقدم.

• [C-1-8] يجب أن يطلب الجهاز من المستخدم إكمال عملية المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النمط أو كلمة المرور) بعد تنفيذ أحد الإجراءات التالية:

  • فترة مهلة عدم النشاط لمدة 4 ساعات
  • 3 محاولات فاشلة للمصادقة بالمقاييس الحيوية
  • تتم إعادة ضبط فترة المهلة غير النشطة وعدد محاولات المصادقة غير الناجحة بعد أي تأكيد ناجح لبيانات اعتماد الجهاز.

  يمكن إعفاء الأجهزة التي تمت ترقيتها من إصدار Android أقدم من المتطلبات الواردة في القسم C-1-8.

• [C-SR] يُنصح بشدة بأن يكون معدّل الرفض الخاطئ أقل من %10، وذلك وفقًا للقياسات التي يتم إجراؤها على الجهاز.

• [C-SR] يُنصح بشدة أن يكون وقت الاستجابة أقل من ثانية واحدة، ويتم قياسه من وقت رصد المقاييس الحيوية إلى حين فتح قفل الشاشة، وذلك لكل مقياس حيوي تم تسجيله.

إذا كانت عمليات تنفيذ الأجهزة تريد التعامل مع أداة استشعار المقاييس الحيوية على أنّها ضعيفة، عليها:

• [C-2-1] يجب استيفاء جميع متطلبات الراحة أعلاه، باستثناء [C-1-2].
• [C-2-2] يجب ألا يزيد معدّل قبول عمليات الانتحال عن %20.
• [C-2-3] يجب توفير تنفيذ لمخزن مفاتيح مستند إلى الأجهزة، وتنفيذ عملية مطابقة المقاييس الحيوية في بيئة تنفيذ معزولة خارج مساحة المستخدم أو النواة في Android، مثل بيئة التنفيذ الموثوقة (TEE)، أو على شريحة مزوّدة بقناة آمنة إلى بيئة التنفيذ المعزولة.
• [C-2-4] يجب أن تكون جميع البيانات التي يمكن التعرّف على هوية صاحبها مشفَّرة ومصدَّقة تشفيرًا بحيث لا يمكن الحصول عليها أو قراءتها أو تغييرها خارج بيئة التنفيذ المعزولة أو شريحة تحتوي على قناة آمنة إلى بيئة التنفيذ المعزولة كما هو موضّح في إرشادات التنفيذ على موقع "مشروع Android المفتوح المصدر".
• [C-2-5] أثناء إجراء المصادقة أو التسجيل باستخدام المقاييس الحيوية المستندة إلى الكاميرا:
  • يجب تشغيل الكاميرا في وضع يمنع قراءة أو تعديل إطارات الكاميرا خارج بيئة التنفيذ المعزولة أو شريحة تحتوي على قناة آمنة إلى بيئة التنفيذ المعزولة.
  • بالنسبة إلى حلول الكاميرا الواحدة التي تستخدم ألوان الأحمر والأخضر والأزرق، يمكن قراءة إطارات الكاميرا خارج بيئة التنفيذ المعزولة لدعم عمليات مثل المعاينة للتسجيل، ولكن يجب ألا يكون من الممكن تعديلها.
• [C-2-6] يجب ألا تسمح التطبيقات التابعة لجهات خارجية بالتمييز بين عمليات تسجيل المقاييس الحيوية الفردية.
• [C-2-7] يجب ألا يسمح بالوصول غير المشفّر إلى البيانات الحيوية التي يمكن تحديد الهوية من خلالها أو أي بيانات مشتقة منها (مثل عمليات التضمين) إلى معالج التطبيقات خارج سياق بيئة التنفيذ الموثوقة (TEE).

• [C-2-8] يجب أن يتضمّن مسار معالجة آمنًا لا يسمح باختراق نظام التشغيل أو النواة لإدخال البيانات مباشرةً بهدف المصادقة بشكل خاطئ على أنّها بيانات المستخدم.

  إذا تم إطلاق عمليات تنفيذ الأجهزة على إصدار Android سابق ولم تستوفِ المتطلبات C-2-8 من خلال تحديث لبرامج النظام، يجوز إعفاؤها من المتطلبات.

إذا كانت عمليات تنفيذ الأجهزة تريد التعامل مع أداة استشعار المقاييس الحيوية على أنّها قوية، عليها استيفاء ما يلي:

• [C-3-1] يجب استيفاء جميع متطلبات ضعيف المذكورة أعلاه. لا يُستثنى ترقية الأجهزة من إصدار Android أقدم من المتطلبات الواردة في القسم C-2-7.
• [C-3-2] يجب أن يكون معدّل قبول عمليات الانتحال والتزوير أقل من %7.
• [C-3-3] يجب أن يطلب الجهاز من المستخدم إكمال عملية المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) مرة واحدة كل 72 ساعة أو أقل.

‫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] يجب تنفيذ واجهات برمجة التطبيقات الكاملة كعمليات غير فعّالة.

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع شرائح eUICC أو شرائح eSIM/شرائح SIM المضمّنة وتتضمّن آلية خاصة لإتاحة وظائف شريحة eSIM للمطوّرين التابعين لجهات خارجية، يجب أن تستوفي ما يلي:

• [C-3-1] يجب توفير تنفيذ كامل للسمة EuiccManager API.

7.4.1.1. التوافق مع ميزة حظر الأرقام

إذا كانت عمليات تنفيذ الأجهزة تُبلغ عن android.hardware.telephony feature، فإنّها:

• [C-1-1] يجب أن يتضمّن دعمًا لحظر الأرقام
• [C-1-2] يجب تنفيذ BlockedNumberContract وواجهة برمجة التطبيقات المقابلة بالكامل على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK).
• [C-1-3] يجب حظر جميع المكالمات والرسائل الواردة من رقم هاتف في BlockedNumberProvider بدون أي تفاعل مع التطبيقات. الاستثناء الوحيد هو عندما يتم رفع حظر الأرقام مؤقتًا كما هو موضّح في مستندات حزمة تطوير البرامج (SDK).
• [C-1-4] يجب عدم الكتابة إلى مقدّم سجلّ المكالمات على المنصة لمكالمة محظورة.
• [C-1-5] يجب عدم الكتابة إلى مزوّد خدمة الاتصال الهاتفي بشأن رسالة محظورة.
• [C-1-6] يجب تنفيذ واجهة مستخدم لإدارة الأرقام المحظورة، ويتم فتحها باستخدام الغرض الذي تعرضه الطريقة TelecomManager.createManageBlockedNumbersIntent().
• [C-1-7] يجب ألا تسمح للمستخدمين الثانويين بعرض الأرقام المحظورة أو تعديلها على الجهاز، لأنّ منصة Android تفترض أنّ المستخدم الأساسي لديه تحكّم كامل في خدمات الاتصال الهاتفي، وهي نسخة واحدة على الجهاز. يجب إخفاء جميع عناصر واجهة المستخدم ذات الصلة بالحظر عن المستخدمين الثانويين، ويجب أن تظل قائمة الحظر سارية.
• يجب نقل الأرقام المحظورة إلى مقدّم الخدمة عند تحديث الجهاز إلى الإصدار 7.0 من نظام التشغيل Android.

‫7.4.1.2. Telecom API

إذا كان تقرير عمليات تنفيذ الأجهزة android.hardware.telephony، يعني ذلك ما يلي:

• [C-1-1] يجب أن تتوافق مع واجهات برمجة التطبيقات ConnectionService الموضّحة في حزمة تطوير البرامج (SDK).
• [C-1-2] يجب عرض مكالمة واردة جديدة وتوفير إمكانية للمستخدم لقبول المكالمة الواردة أو رفضها عندما يكون المستخدم في مكالمة جارية تم إجراؤها من خلال تطبيق تابع لجهة خارجية لا يتيح ميزة التعليق المحدّدة من خلال CAPABILITY_SUPPORT_HOLD.
• [C-1-3] يجب أن يتضمّن تطبيقًا ينفّذ InCallService.

• [C-SR] يُنصح بشدة بإشعار المستخدم بأنّ الرد على مكالمة واردة سيؤدي إلى إنهاء مكالمة جارية.

  يستوفي تطبيق AOSP هذه المتطلبات من خلال إشعار عائم يُعلم المستخدم بأنّ الردّ على مكالمة واردة سيؤدي إلى قطع المكالمة الأخرى.

• [C-SR] يُنصح بشدة بتحميل تطبيق الاتصال التلقائي مسبقًا الذي يعرض إدخالاً في سجلّ المكالمات واسم تطبيق تابع لجهة خارجية في سجلّ المكالمات عندما يضبط التطبيق التابع لجهة خارجية مفتاح الإضافات EXTRA_LOG_SELF_MANAGED_CALLS في PhoneAccount على true.

• [C-SR] يُنصح بشدة بمعالجة حدثَي KEYCODE_MEDIA_PLAY_PAUSE وKEYCODE_HEADSETHOOK لسماعة الرأس الصوتية في واجهات برمجة التطبيقات android.telecom على النحو التالي:
  • يتم استدعاء Connection.onDisconnect() عند رصد ضغطة قصيرة على حدث المفتاح أثناء مكالمة جارية.
  • يتم استدعاء Connection.onAnswer() عند رصد ضغطة قصيرة على حدث المفتاح أثناء مكالمة واردة.
  • يتم استدعاء Connection.onReject() عند رصد ضغطة مع الاستمرار على حدث المفتاح أثناء مكالمة واردة.
  • تبديل حالة كتم صوت CallAudioState

‫7.4.2 معيار IEEE 802.11 (لشبكات Wi-Fi)

عمليات تنفيذ الأجهزة:

• يجب أن تتضمّن دعمًا لشكل واحد أو أكثر من أشكال 802.11.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية استخدام معيار 802.11 وتتيح هذه الوظيفة لتطبيق تابع لجهة خارجية، يجب أن تستوفي ما يلي:

• [C-1-1] يجب تنفيذ واجهة برمجة تطبيقات Android المقابلة.
• [C-1-2] يجب الإبلاغ عن علامة ميزة الأجهزة android.hardware.wifi.
• [C-1-3] يجب تنفيذ واجهة برمجة تطبيقات البث المتعدد على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK).
• [C-1-4] يجب أن يتيح نظام أسماء النطاقات ذي البث المتعدد (mDNS) ويجب ألا يصفّي حِزم mDNS (224.0.0.251) في أي وقت من التشغيل، بما في ذلك:
  • حتى عندما لا تكون الشاشة في حالة نشطة
  • بالنسبة إلى عمليات تنفيذ أجهزة Android Television، حتى عندما تكون في حالات طاقة الاستعداد
• [C-1-5] يجب عدم اعتبار طلب بيانات من طريقة WifiManager.enableNetwork() في واجهة برمجة التطبيقات مؤشرًا كافيًا لتبديل Network النشط حاليًا والذي يتم استخدامه تلقائيًا في زيارات التطبيق ويتم عرضه من خلال طرق ConnectivityManager في واجهة برمجة التطبيقات، مثل getActiveNetwork وregisterDefaultNetworkCallback. بعبارة أخرى، يجوز لهم إيقاف إمكانية الوصول إلى الإنترنت التي يوفّرها أي مقدّم خدمة شبكة آخر (مثل بيانات الجوّال) فقط إذا تمكّنوا من التحقّق بنجاح من أنّ شبكة Wi-Fi توفّر إمكانية الوصول إلى الإنترنت.
• [C-1-6] يُنصح بشدة عند استدعاء طريقة واجهة برمجة التطبيقات ConnectivityManager.reportNetworkConnectivity() بإعادة تقييم إمكانية الوصول إلى الإنترنت على Network، وبعد أن يحدّد التقييم أنّ Network الحالي لم يعُد يوفّر إمكانية الوصول إلى الإنترنت، يجب التبديل إلى أي شبكة أخرى متاحة (مثل بيانات الجوّال) توفّر إمكانية الوصول إلى الإنترنت.
• [C-SR] يُنصح بشدة بتغيير عنوان MAC المصدر ورقم التسلسل لإطارات طلب الفحص عشوائيًا، وذلك مرة واحدة في بداية كل عملية فحص، عندما يكون الجهاز غير متصل.
  • يجب أن تستخدم كل مجموعة من حزم طلبات البحث التي تتضمّن عملية فحص واحدة عنوان MAC متسقًا واحدًا (يجب عدم توزيع عنوان MAC بشكل عشوائي في منتصف عملية الفحص).
  • يجب أن يتكرّر رقم تسلسل طلب الفحص بشكل عادي (تسلسليًا) بين طلبات الفحص في عملية المسح.
  • يجب أن يكون رقم تسلسل طلب الفحص عشوائيًا بين آخر طلب فحص لعملية مسح وأول طلب فحص لعملية المسح التالية.
• [C-SR] يُنصح بشدة باستخدامها، بينما يكون STA غير متصل، للسماح بالعناصر التالية فقط في إطارات طلب الفحص:
  • مجموعة مَعلمات معرّف مجموعة الخدمات (0)
  • مجموعة مَعلمات DS (3)

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة وضع توفير الطاقة في شبكة Wi-Fi على النحو المحدّد في معيار IEEE 802.11، يجب أن:

• [C-3-1] يجب إيقاف وضع توفير الطاقة في شبكة Wi-Fi عندما يحصل تطبيق على قفل WIFI_MODE_FULL_HIGH_PERF أو قفل WIFI_MODE_FULL_LOW_LATENCY من خلال واجهات برمجة التطبيقات WifiManager.createWifiLock() وWifiManager.WifiLock.acquire() ويكون القفل نشطًا.
• ‫[C-3-2] يجب أن يكون متوسط وقت الاستجابة لرحلة الذهاب والعودة بين الجهاز ونقطة الوصول أثناء وضع قفل Wi-Fi Low Latency Lock (WIFI_MODE_FULL_LOW_LATENCY) أقل من وقت الاستجابة أثناء وضع قفل Wi-Fi High Perf Lock (WIFI_MODE_FULL_HIGH_PERF).
• [C-SR] يُنصح بشدة باستخدامها لتقليل وقت الاستجابة الكامل لشبكة Wi-Fi إلى الحدّ الأدنى عند الحصول على قفل التأخير المنخفض (WIFI_MODE_FULL_LOW_LATENCY) وتفعيله.

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع شبكة Wi-Fi وتستخدمها للبحث عن الموقع الجغرافي، يجب أن تستوفي ما يلي:

• [C-2-1] يجب توفير وسيلة تتيح للمستخدم تفعيل/إيقاف القيمة التي تتم قراءتها من خلال طريقة واجهة برمجة التطبيقات WifiManager.isScanAlwaysAvailable.

‫7.4.2.1 اتصال Wi-Fi مباشر

عمليات تنفيذ الأجهزة:

• يجب أن يتضمّن دعمًا لتقنية Wi-Fi Direct (Wi-Fi من جهاز إلى جهاز).

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية استخدام Wi-Fi Direct، يجب أن:

• [C-1-1] يجب تنفيذ واجهة برمجة التطبيقات المتوافقة مع Android على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK).
• ‫[C-1-2] يجب الإبلاغ عن ميزة الأجهزة android.hardware.wifi.direct.
• [C-1-3] يجب أن يتيح الجهاز التشغيل المنتظم لشبكة Wi-Fi.
• ‫[C-1-4] يجب أن تتوافق مع عمليات Wi-Fi وWi-Fi Direct في الوقت نفسه.

‫7.4.2.2. إعداد رابط مباشر عبر شبكة Wi-Fi

عمليات تنفيذ الأجهزة:

• يجب أن تتضمّن دعم إعداد رابط مباشر عبر شبكة Wi-Fi (TDLS) على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة TDLS وتم تفعيلها من خلال واجهة برمجة التطبيقات WiFiManager، فإنّها:

• ‫[C-1-1] يجب الإعلان عن إتاحة بروتوكول TDLS من خلال WifiManager.isTdlsSupported.
• يجب استخدام TDLS فقط عندما يكون ذلك ممكنًا ومفيدًا.
• يجب أن يتضمّن بعض الإرشادات ولا يستخدم TDLS عندما يكون أداؤه أسوأ من المرور عبر نقطة وصول Wi-Fi.

‫7.4.2.3. Wi-Fi Aware

عمليات تنفيذ الأجهزة:

• يجب أن يتضمّن دعمًا لتقنية Wi-Fi Aware.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية استخدام Wi-Fi Aware وتتيح هذه الوظيفة للتطبيقات التابعة لجهات خارجية، يجب أن تستوفي الشروط التالية:

• [C-1-1] يجب تنفيذ واجهات برمجة التطبيقات WifiAwareManager على النحو الموضّح في مستندات حزمة تطوير البرامج.
• [C-1-2] يجب الإفصاح عن علامة الميزة android.hardware.wifi.aware.
• [C-1-3] يجب أن تتوافق مع عمليات Wi-Fi وWi-Fi Aware في الوقت نفسه.
• [C-1-4] يجب أن يتم اختيار عنوان واجهة إدارة Wi-Fi Aware بشكل عشوائي على فترات لا تزيد عن 30 دقيقة وكلما تم تفعيل Wi-Fi Aware.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة استخدام Wi-Fi Aware وخدمة تحديد الموقع الجغرافي عبر Wi-Fi كما هو موضّح في الفقرة 7.4.2.5 وتتيح هذه الوظائف لتطبيقات الجهات الخارجية، يجب أن تستوفي ما يلي:

• [C-2-1] يجب تنفيذ واجهات برمجة التطبيقات التي تتيح الاستكشاف المستند إلى الموقع الجغرافي: setRangingEnabled وsetMinDistanceMm وsetMaxDistanceMm وonServiceDiscoveredWithinRange.

‫7.4.2.4 Wi-Fi Passpoint

عمليات تنفيذ الأجهزة:

• يجب أن تتضمّن إمكانية استخدام Wi-Fi Passpoint.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة استخدام Wi-Fi Passpoint، يجب أن تستوفي ما يلي:

• [C-1-1] يجب تنفيذ واجهات برمجة التطبيقات ذات الصلة بمعيار Passpoint WifiManager على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK).
• [C-1-2] يجب أن يتوافق مع معيار IEEE 802.11u، وتحديدًا ما يتعلّق باكتشاف الشبكة واختيارها، مثل خدمة الإعلانات الشاملة (GAS) وبروتوكول طلب شبكة الوصول (ANQP).

في المقابل، إذا لم تتضمّن عمليات تنفيذ الأجهزة إمكانية استخدام Wi-Fi Passpoint:

• [C-2-1] يجب أن يؤدي تنفيذ واجهات برمجة التطبيقات ذات الصلة بمعيار Passpoint WifiManager إلى عرض UnsupportedOperationException.

‫7.4.2.5. الموقع الجغرافي عبر شبكة Wi-Fi (المدة بين نقطتَي البداية والنهاية لشبكة Wi-Fi)

عمليات تنفيذ الأجهزة:

• يجب أن تتضمّن دعم خدمة تحديد الموقع الجغرافي عبر Wi-Fi.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة ميزة "تحديد الموقع الجغرافي عبر شبكة Wi-Fi" وتوفير الوظيفة للتطبيقات التابعة لجهات خارجية، يجب أن تستوفي ما يلي:

• [C-1-1] يجب تنفيذ واجهات برمجة التطبيقات WifiRttManager على النحو الموضّح في مستندات حزمة تطوير البرامج.
• [C-1-2] يجب الإفصاح عن علامة الميزة android.hardware.wifi.rtt.
• [C-1-3] يجب اختيار عنوان MAC المصدر بشكل عشوائي لكل مجموعة من عمليات إرسال واستقبال بيانات RTT التي يتم تنفيذها عندما لا تكون واجهة Wi-Fi التي يتم تنفيذ RTT عليها مرتبطة بنقطة وصول.

7.4.2.6. نقل بيانات إبقاء اتصال Wi-Fi نشطًا

عمليات تنفيذ الأجهزة:

• يجب أن تتضمّن إمكانية إيقاف تحميل Wi-Fi keepalive.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية إيقاف تحميل Wi-Fi keepalive وتتيح هذه الوظيفة للتطبيقات التابعة لجهات خارجية، يجب أن تستوفي الشروط التالية:

• [C-1-1] يجب أن تتوافق مع واجهة برمجة التطبيقات SocketKeepAlive.

• [C-1-2] يجب أن يتيح الجهاز ثلاث فترات متزامنة على الأقل لإبقاء الاتصال نشطًا عبر شبكة Wi-Fi وفترة واحدة على الأقل لإبقاء الاتصال نشطًا عبر شبكة الجوّال.

إذا لم تتضمّن عمليات تنفيذ الأجهزة إمكانية إيقاف ميزة "إبقاء Wi-Fi نشطًا"، يجب أن:

• [C-2-1] يجب أن تعرض ERROR_UNSUPPORTED.

7.4.2.7. Wi-Fi Easy Connect (بروتوكول توفير المتطلبات اللازمة للأجهزة)

عمليات تنفيذ الأجهزة:

• يجب أن تتضمّن إمكانية استخدام Wi-Fi Easy Connect (DPP).

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة استخدام ميزة "الاتصال السهل بشبكة Wi-Fi" وإتاحة الوظيفة للتطبيقات التابعة لجهات خارجية، يجب أن تستوفي ما يلي:

• [C-1-1] يجب تنفيذ واجهات برمجة التطبيقات Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI Intent على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK).
• [C-1-2] يجب أن تعرض الدالة WifiManager#isEasyConnectSupported() القيمة true.

‫7.4.3. البلوتوث

في حال توفّر ملف Bluetooth Audio على الأجهزة، يجب أن:

• يجب أن تتوافق مع برامج ترميز الصوت المتقدّمة وبرامج ترميز صوت البلوتوث (مثل LDAC).

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع ملفات HFP وA2DP وAVRCP، يجب أن:

• يجب أن يتيح ربط 5 أجهزة إجمالاً على الأقل.

إذا كانت عمليات تنفيذ الأجهزة تعرّف الميزة android.hardware.vr.high_performance، عليها استيفاء ما يلي:

• ‫[C-1-1] يجب أن تتوافق مع الإصدار 4.2 من البلوتوث وإضافة "تمديد طول بيانات البلوتوث" (Bluetooth LE Data Length Extension).

يتضمّن نظام التشغيل Android إمكانية استخدام البلوتوث والبلوتوث المنخفض الطاقة.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة استخدام البلوتوث والبلوتوث المنخفض الطاقة، يجب أن تستوفي ما يلي:

• [C-2-1] يجب الإفصاح عن ميزات المنصة ذات الصلة (android.hardware.bluetooth وandroid.hardware.bluetooth_le على التوالي) وتنفيذ واجهات برمجة التطبيقات الخاصة بالمنصة.
• يجب تنفيذ ملفات تعريف البلوتوث ذات الصلة، مثل A2DP وAVRCP وOBEX وHFP وما إلى ذلك، حسب ما هو مناسب للجهاز.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية استخدام البلوتوث المنخفض الطاقة، يجب أن تستوفي ما يلي:

• [C-3-1] يجب الإعلان عن ميزة الجهاز android.hardware.bluetooth_le.
• [C-3-2] يجب تفعيل واجهات برمجة تطبيقات Bluetooth المستندة إلى GATT (ملف تعريف السمات العامة) على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK) وandroid.bluetooth.
• [C-3-3] يجب عرض القيمة الصحيحة لـ BluetoothAdapter.isOffloadedFilteringSupported() للإشارة إلى ما إذا كان قد تم تنفيذ منطق الفلترة لفئات واجهة برمجة التطبيقات ScanFilter.
• [C-3-4] يجب عرض القيمة الصحيحة لـ BluetoothAdapter.isMultipleAdvertisementSupported() للإشارة إلى ما إذا كان يتم توفير ميزة "الإعلان عن الطاقة المنخفضة".
• يجب أن تتيح إمكانية نقل منطق الفلترة إلى مجموعة شرائح البلوتوث عند تنفيذ ScanFilter API.
• يجب أن تتيح إمكانية نقل عملية المسح الضوئي المجمّع إلى مجموعة شرائح البلوتوث.

• يجب أن يتيح عرض إعلانات متعدّدة مع 4 خانات على الأقل.

• [SR] يُنصح بشدة بتنفيذ مهلة لعنوان خاص قابل للحل (RPA) لا تزيد عن 15 دقيقة وتغيير العنوان عند انتهاء المهلة لحماية خصوصية المستخدم.

في حال كانت عمليات تنفيذ الأجهزة تتوافق مع تقنية Bluetooth LE وتستخدمها في البحث عن الموقع الجغرافي، يجب أن تستوفي ما يلي:

• [C-4-1] يجب توفير وسيلة تحكّم للمستخدم لتفعيل/إيقاف قراءة القيمة من خلال System API BluetoothAdapter.isBleScanAlwaysAvailable().

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية استخدام Bluetooth LE و"ملف تعريف سماعات الأذن الطبية"، كما هو موضّح في إتاحة الصوت لسماعات الأذن الطبية باستخدام Bluetooth LE، فإنّها:

• [C-5-1] يجب أن تعرض الدالة true عند استدعاء BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).

‫7.4.4 اتصالات المجال القريب

عمليات تنفيذ الأجهزة:

• يجب أن يتضمّن جهاز إرسال واستقبال وأجهزة ذات صلة بتقنية الاتصال القصير المدى (NFC).
• [C-0-1] يجب تنفيذ واجهات برمجة التطبيقات android.nfc.NdefMessage وandroid.nfc.NdefRecord حتى إذا لم تتضمّن دعمًا لاتصالات المجال القريب أو لم يتم الإفصاح عن الميزة 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 Forum‏ 1 و2 و3 و4 و5 (المحدّدة من قِبل NFC Forum)

• [SR] يُنصح بشدة أن يكون الجهاز قادرًا على قراءة رسائل NDEF وكتابتها بالإضافة إلى البيانات الأولية من خلال معايير NFC التالية. يُرجى العِلم أنّه على الرغم من أنّ معايير NFC مُحدّدة على أنّها يُنصَح بها بشدة، من المقرّر أن يتم تغييرها إلى "يجب" في تعريف التوافق لإصدار مستقبلي. هذه المعايير اختيارية في هذا الإصدار، ولكن سيتم فرضها في الإصدارات المستقبلية. ننصح بشدة الأجهزة الحالية والجديدة التي تعمل بهذا الإصدار من Android باستيفاء هذه المتطلبات الآن حتى تتمكّن من الترقية إلى إصدارات النظام الأساسي المستقبلية.

• [C-1-13] يجب إجراء عملية بحث عن جميع التقنيات المتوافقة أثناء تفعيل وضع البحث عن أجهزة NFC.

• يجب أن يكون في وضع رصد NFC أثناء تنشيط الجهاز مع تفعيل الشاشة وفتح قفل شاشة القفل.
• يجب أن يكون قادرًا على قراءة الرمز الشريطي وعنوان URL (في حال ترميزه) لمنتجات Thinfilm NFC Barcode.

يُرجى العِلم أنّ الروابط المتاحة للجميع غير متوفّرة لمواصفات JIS وISO وNFC Forum المذكورة أعلاه.

يتوافق نظام التشغيل Android مع وضع محاكاة البطاقة المضيفة (HCE) عبر تقنية NFC.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مجموعة شرائح وحدة التحكّم في NFC القادرة على محاكاة البطاقة (لبروتوكول NfcA و/أو NfcB) وتتيح توجيه رقم تعريف التطبيق (AID)، يجب أن تستوفي ما يلي:

• [C-2-1] يجب عرض قيمة ثابتة للميزة android.hardware.nfc.hce.
• [C-2-2] يجب أن تتوافق مع واجهات برمجة التطبيقات NFC HCE على النحو المحدّد في حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مجموعة شرائح وحدة التحكّم في NFC التي تتيح محاكاة البطاقة (HCE) في NfcF، وتنفّذ الميزة للتطبيقات التابعة لجهات خارجية، عليها استيفاء ما يلي:

• [C-3-1] يجب عرض قيمة ثابتة للميزة android.hardware.nfc.hcef.
• [C-3-2] يجب تنفيذ واجهات برمجة التطبيقات لمحاكاة بطاقة NFC-F على النحو المحدّد في حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة استخدام تكنولوجيا NFC العامة كما هو موضّح في هذا القسم وتتيح استخدام تقنيات MIFARE (مثل MIFARE Classic وMIFARE Ultralight وNDEF على MIFARE Classic) في دور القارئ/الكاتب، يجب أن تستوفي ما يلي:

• [C-4-1] يجب تنفيذ واجهات برمجة تطبيقات Android ذات الصلة كما هو موثّق في حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
• [C-4-2] يجب الإبلاغ عن الميزة com.nxp.mifare من خلال الطريقة android.content.pm.PackageManager.hasSystemFeature(). يُرجى العِلم أنّ هذه ليست ميزة عادية في Android، وبالتالي لا تظهر كثابتة في الفئة android.content.pm.PackageManager.

‫7.4.5. الحد الأدنى من إمكانات الشبكة

عمليات تنفيذ الأجهزة:

• [C-0-1] يجب أن يتضمّن دعمًا لشكل واحد أو أكثر من أشكال ربط البيانات بالشبكة. على وجه التحديد، يجب أن تتضمّن عمليات تنفيذ الأجهزة إمكانية استخدام معيار واحد على الأقل من معايير البيانات التي يمكنها نقل البيانات بمعدّل 200 كيلوبت في الثانية أو أكثر. تشمل الأمثلة على التقنيات التي تستوفي هذا الشرط EDGE وHSPA وEV-DO و802.11g وEthernet وBluetooth PAN.
• يجب أن تتضمّن أيضًا إمكانية استخدام معيار واحد على الأقل من معايير البيانات اللاسلكية الشائعة، مثل 802.11 (Wi-Fi)، عندما يكون معيار الشبكات المادية (مثل Ethernet) هو اتصال البيانات الأساسي.
• يمكن أن تنفّذ أكثر من شكل واحد من أشكال ربط البيانات.
• [C-0-2] يجب أن يتضمّن حزمة شبكات IPv6 وأن يتيح إمكانية التواصل عبر IPv6 باستخدام واجهات برمجة التطبيقات المُدارة، مثل java.net.Socket وjava.net.URLConnection، بالإضافة إلى واجهات برمجة التطبيقات الأصلية، مثل مقابس AF_INET6.
• [C-0-3] يجب تفعيل بروتوكول IPv6 تلقائيًا.
• يجب التأكّد من أنّ الاتصال عبر IPv6 موثوق به مثل IPv4، على سبيل المثال:
  • [C-0-4] يجب الحفاظ على إمكانية الاتصال ببروتوكول IPv6 في وضع "السكون".
  • [C-0-5] يجب ألا يؤدي الحدّ من معدّل نقل البيانات إلى فقدان الجهاز لإمكانية الاتصال ببروتوكول IPv6 على أي شبكة متوافقة مع IPv6 تستخدم مدة صلاحية إعلانات الموجه (RA) لا تقل عن 180 ثانية.
• [C-0-6] يجب أن توفّر التطبيقات التابعة لجهات خارجية إمكانية الاتصال المباشر بالشبكة باستخدام الإصدار السادس من بروتوكول الإنترنت (IPv6) عند الاتصال بشبكة IPv6، بدون أي شكل من أشكال ترجمة العناوين أو المنافذ محليًا على الجهاز. يجب أن تعرض كل من واجهات برمجة التطبيقات المُدارة، مثل Socket#getLocalAddress أو Socket#getLocalPort، وواجهات برمجة التطبيقات الخاصة بحزمة تطوير البرامج الأصلية (NDK)، مثل getsockname() أو IPV6_PKTINFO، عنوان IP والمنفذ المستخدَمَين فعليًا لإرسال الحِزم وتلقّيها على الشبكة.

يعتمد مستوى توافق IPv6 المطلوب على نوع الشبكة، كما هو موضّح في المتطلبات التالية.

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع شبكة Wi-Fi، يجب أن تستوفي ما يلي:

• ‫[C-1-1] يجب أن يتيح الجهاز التشغيل المزدوج والتشغيل عبر IPv6 فقط على شبكة Wi-Fi.

في حال كانت عمليات تنفيذ الأجهزة تتوافق مع شبكة إيثرنت، يجب أن تتضمّن ما يلي:

• ‫[C-2-1] يجب أن يتيح الجهاز التشغيل المزدوج على شبكة Ethernet.

في حال توفير عمليات تنفيذ الأجهزة لبيانات شبكة الجوّال، يجب أن:

• يجب أن تتوافق مع عملية IPv6 (IPv6 فقط وربما ثنائية الحزمة) على شبكة الجوّال.

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع أكثر من نوع شبكة واحد (مثل شبكة Wi-Fi وبيانات شبكة الجوّال)، عليك اتّباع ما يلي:

• [C-3-1] يجب استيفاء المتطلبات المذكورة أعلاه في الوقت نفسه على كل شبكة عندما يكون الجهاز متصلاً في الوقت نفسه بأكثر من نوع شبكة واحد.

‫7.4.6. إعدادات المزامنة

عمليات تنفيذ الأجهزة:

• [C-0-1] يجب أن يكون إعداد المزامنة التلقائية الرئيسي مفعَّلاً تلقائيًا لكي تعرض الطريقة getMasterSyncAutomatically() القيمة "true".

7.4.7. توفير البيانات

إذا كانت عمليات تنفيذ الأجهزة تتضمّن اتصالاً محدودًا، تكون على النحو التالي:

• [SR] يُنصح بشدة بتوفير وضع توفير البيانات.

إذا كانت عمليات تنفيذ الأجهزة توفّر وضع "توفير البيانات"، فإنّها:

• [C-1-1] يجب أن تتوافق مع جميع واجهات برمجة التطبيقات في فئة ConnectivityManager على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK).
• [C-1-2] يجب توفير واجهة مستخدم في الإعدادات تتعامل مع الغرض Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS، ما يسمح للمستخدمين بإضافة تطبيقات إلى القائمة أو إزالتها منها.

إذا لم توفّر عمليات تنفيذ الأجهزة وضع "توفير البيانات"، عليها استيفاء الشروط التالية:

• [C-2-1] يجب أن تعرض القيمة RESTRICT_BACKGROUND_STATUS_DISABLED للسمة ConnectivityManager.getRestrictBackgroundStatus()
• [C-2-2] يجب عدم بث ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.
• [C-2-3] يجب أن يتضمّن نشاطًا يعالج الغرض Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS، ولكن يجوز تنفيذه كعملية غير فعّالة.

‫7.4.8. العناصر الآمنة

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع Open Mobile API التي تتضمّن عناصر آمنة وتتيحها للتطبيقات التابعة لجهات خارجية، يجب أن تستوفي ما يلي:

• [C-1-1] يجب تعداد قارئات "عناصر الأمان" المتاحة عند استدعاء الطريقة android.se.omapi.SEService.getReaders().

‫7.5 الكاميرا

إذا كانت عمليات تنفيذ الأجهزة تتضمّن كاميرا واحدة على الأقل، يجب أن تستوفي ما يلي:

• [C-1-1] يجب الإعلان عن علامة الميزة android.hardware.camera.any.
• [C-1-2] يجب أن يكون من الممكن لأحد التطبيقات تخصيص 3 صور نقطية بتنسيق RGBA_8888 تساوي حجم الصور التي تنتجها أداة استشعار الكاميرا ذات أعلى دقة على الجهاز، وذلك أثناء فتح الكاميرا لغرض المعاينة الأساسية والتقاط الصور الثابتة.
• [C-1-3] يجب التأكّد من أنّ تطبيق الكاميرا التلقائي المثبَّت مسبقًا الذي يعالج الأهداف MediaStore.ACTION_IMAGE_CAPTURE أو MediaStore.ACTION_IMAGE_CAPTURE_SECURE أو MediaStore.ACTION_VIDEO_CAPTURE هو المسؤول عن إزالة الموقع الجغرافي للمستخدم من البيانات الوصفية للصور قبل إرسالها إلى التطبيق المستلِم عندما لا يتضمّن التطبيق المستلِم الإذن ACCESS_FINE_LOCATION.

7.5.1. الكاميرا الخلفية

الكاميرا الخلفية هي كاميرا تقع على جانب الجهاز المقابل للشاشة، أي أنّها تصوّر المشاهد على الجانب البعيد من الجهاز، مثل الكاميرا التقليدية.

عمليات تنفيذ الأجهزة:

• يجب أن يتضمّن كاميرا خلفية.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن كاميرا واحدة على الأقل مواجهة للخلف، يجب أن:

• [C-1-1] يجب الإبلاغ عن علامة الميزة android.hardware.camera وandroid.hardware.camera.any.
• [C-1-2] يجب أن تبلغ دقتها 2 ميغابكسل على الأقل.
• يجب أن يتضمّن برنامج تشغيل الكاميرا ميزة التركيز التلقائي للأجهزة أو البرامج (بدون أن يظهر ذلك لبرامج التطبيقات).
• قد تحتوي على أجهزة تركيز ثابت أو أجهزة EDOF (عمق مجال موسّع).
• قد تتضمّن فلاشًا.

إذا كانت الكاميرا تتضمّن فلاشًا:

• [C-2-1] يجب عدم إضاءة مصباح الفلاش أثناء تسجيل مثيل android.hardware.Camera.PreviewCallback على مساحة معاينة الكاميرا، ما لم يفعّل التطبيق الفلاش صراحةً من خلال تفعيل السمتَين FLASH_MODE_AUTO أو FLASH_MODE_ON لكائن Camera.Parameters. يُرجى العِلم أنّ هذا القيد لا ينطبق على تطبيق كاميرا النظام المضمّن في الجهاز، ولكنّه ينطبق فقط على التطبيقات التابعة لجهات خارجية التي تستخدم Camera.PreviewCallback.

‫7.5.2. الكاميرا الأمامية

الكاميرا الأمامية هي كاميرا تقع على الجانب نفسه من الجهاز الذي توجد فيه الشاشة، أي كاميرا تُستخدم عادةً لتصوير المستخدم، مثلاً في مؤتمرات الفيديو والتطبيقات المشابهة.

عمليات تنفيذ الأجهزة:

• قد يتضمّن كاميرا أمامية.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن كاميرا واحدة على الأقل مواجهة للأمام، يجب أن تستوفي ما يلي:

• [C-1-1] يجب الإبلاغ عن علامة الميزة android.hardware.camera.any وandroid.hardware.camera.front.
• [C-1-2] يجب أن تكون درجة الدقة VGA (640x480 بكسل) على الأقل.
• [C-1-3] يجب عدم استخدام كاميرا أمامية كإعداد تلقائي لواجهة برمجة التطبيقات Camera API، ويجب عدم ضبط واجهة برمجة التطبيقات على اعتبار الكاميرا الأمامية هي الكاميرا الخلفية التلقائية، حتى إذا كانت الكاميرا الوحيدة على الجهاز.
• [C-1-4] يجب أن تكون معاينة الكاميرا معكوسة أفقيًا بالنسبة إلى الاتجاه الذي يحدّده التطبيق عندما يطلب التطبيق الحالي صراحةً تدوير شاشة الكاميرا من خلال استدعاء الطريقة android.hardware.Camera.setDisplayOrientation(). في المقابل، يجب أن تتم محاكاة المعاينة على طول المحور الأفقي التلقائي للجهاز عندما لا يطلب التطبيق الحالي صراحةً تدوير شاشة الكاميرا من خلال طلب إلى الطريقة android.hardware.Camera.setDisplayOrientation().
• [C-1-5] يجب عدم عرض الصورة الثابتة أو بث الفيديو النهائيَّين اللذين تم التقاطهما في معاودة الاتصال بالتطبيق أو حفظهما في مساحة تخزين الوسائط.
• [C-1-6] يجب أن تعكس الصورة المعروضة في العرض اللاحق الصورة المعروضة في معاينة الكاميرا بالطريقة نفسها.
• قد تتضمّن ميزات (مثل التركيز التلقائي والفلاش وما إلى ذلك) متاحة للكاميرات الخلفية كما هو موضّح في الفقرة 7.5.1.

إذا كانت عمليات تنفيذ الأجهزة قابلة للتدوير من قِبل المستخدم (مثل التدوير تلقائيًا من خلال مقياس تسارع أو يدويًا من خلال إدخال المستخدم):

• ‫[C-2-1] يجب أن يتم عكس معاينة الكاميرا أفقيًا بالنسبة إلى اتجاه الجهاز الحالي.

7.5.3. الكاميرا الخارجية

عمليات تنفيذ الأجهزة:

• قد تتضمّن إمكانية استخدام كاميرا خارجية لا تكون متصلة دائمًا.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية استخدام كاميرا خارجية، يجب أن:

• [C-1-1] يجب الإعلان عن علامة ميزة النظام الأساسي android.hardware.camera.external وandroid.hardware camera.any.
• [C-1-2] يجب أن يتوافق الجهاز مع معيار USB Video Class (الإصدار 1.0 أو إصدار أحدث) إذا كانت الكاميرا الخارجية تتصل من خلال منفذ مضيف USB.
• [C-1-3] يجب اجتياز اختبارات CTS للكاميرا مع توصيل جهاز كاميرا خارجي. تتوفّر تفاصيل اختبار مجموعة أدوات اختبار التوافق (CTS) للكاميرا على source.android.com.
• يجب أن تتوافق مع عمليات ضغط الفيديو، مثل MJPEG، للسماح بنقل فيديوهات عالية الجودة غير مشفّرة (أي فيديوهات أولية أو فيديوهات مضغوطة بشكل مستقل).
• قد يتيح استخدام كاميرات متعددة.
• قد يتيح MAY ترميز الفيديو المستند إلى الكاميرا.

في حال توفّر ترميز الفيديو المستند إلى الكاميرا:

• [C-2-1] يجب أن يكون بإمكان الجهاز الوصول إلى بث متزامن غير مشفّر / MJPEG (بدقة QVGA أو أعلى).

7.5.4. سلوك Camera API

يتضمّن Android حزمتَي واجهات برمجة تطبيقات للوصول إلى الكاميرا، وتتيح واجهة برمجة التطبيقات الأحدث android.hardware.camera2 API للتطبيق إمكانية التحكّم في الكاميرا على مستوى أدنى، بما في ذلك عمليات نقل البيانات الفعّالة بدون نسخ، وعمليات نقل البيانات المتسلسلة أو المتدفقة، وعناصر التحكّم في التعريض والزيادة وتوازن اللون الأبيض وتحويل الألوان وإزالة التشويش والحدة وغير ذلك لكل إطار.

تم وضع علامة "متوقّف نهائيًا" على حزمة واجهة برمجة التطبيقات القديمة،android.hardware.Camera، في الإصدار 5.0 من نظام التشغيل Android، ولكن من المفترض أن تظل متاحة للتطبيقات. يجب أن تضمن عمليات تنفيذ أجهزة Android استمرار إتاحة واجهة برمجة التطبيقات على النحو الموضّح في هذا القسم وفي حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

يجب أن تتوفّر في كلتا واجهتَي برمجة التطبيقات جميع الميزات المشتركة بين فئة android.hardware.Camera المتوقّفة نهائيًا وحزمة android.hardware.camera2 الأحدث، وأن يكون أداؤها وجودتها متطابقَين. على سبيل المثال، مع الإعدادات المكافئة، يجب أن تكون سرعة التركيز التلقائي ودقته متطابقتَين، ويجب أن تكون جودة الصور الملتقطة هي نفسها. لا يُشترَط أن تتطابق السرعة أو الجودة في الميزات التي تعتمد على الدلالات المختلفة لواجهتَي برمجة التطبيقات، ولكن يجب أن تتطابق بأكبر قدر ممكن.

يجب أن تنفّذ عمليات تنفيذ الأجهزة السلوكيات التالية لواجهات برمجة التطبيقات ذات الصلة بالكاميرا، وذلك لجميع الكاميرات المتاحة. عمليات تنفيذ الأجهزة:

• [C-0-1] يجب استخدام android.hardware.PixelFormat.YCbCr_420_SP لمعاينة البيانات المقدَّمة إلى عمليات ردّ الاتصال في التطبيق عندما لم يسبق للتطبيق استدعاء android.hardware.Camera.Parameters.setPreviewFormat(int).
• [C-0-2] يجب أن يكون التنسيق NV21 أيضًا عند تسجيل تطبيق مثيلاً من android.hardware.Camera.PreviewCallback واستدعاء النظام للطريقة onPreviewFrame() وتنسيق المعاينة هو YCbCr_420_SP، والبيانات في byte[] التي تم تمريرها إلى onPreviewFrame(). أي أنّ NV21 يجب أن يكون التنسيق التلقائي.
• [C-0-3] يجب أن تتوافق الكاميرات الأمامية والخلفية مع تنسيق YV12 (كما هو موضّح بالثابت android.graphics.ImageFormat.YV12) لمعاينات الكاميرا في android.hardware.Camera. (قد يستخدم برنامج ترميز الفيديو والكاميرا أي تنسيق بكسل أصلي، ولكن يجب أن يتيح تنفيذ الجهاز إمكانية التحويل إلى YV12).
• [C-0-4] يجب أن تتوافق الأجهزة التي تعلن عن إمكانية REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE في android.request.availableCapabilities مع تنسيقي android.hardware.ImageFormat.YUV_420_888 وandroid.hardware.ImageFormat.JPEG كناتجَين من خلال واجهة برمجة التطبيقات android.media.ImageReader لأجهزة android.hardware.camera2.
• [C-0-5] يجب أن يظلّ الجهاز ينفّذ Camera API الكاملة المُدرَجة في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android، بغض النظر عمّا إذا كان الجهاز يتضمّن ميزة التركيز التلقائي للأجهزة أو إمكانات أخرى. على سبيل المثال، يجب أن تستدعي الكاميرات التي لا تتضمّن ميزة التركيز التلقائي أي مثيلات android.hardware.Camera.AutoFocusCallback مسجّلة (حتى لو لم يكن ذلك ذا صلة بكاميرا لا تتضمّن ميزة التركيز التلقائي). يُرجى العِلم أنّ هذا ينطبق على الكاميرات الأمامية. على سبيل المثال، على الرغم من أنّ معظم الكاميرات الأمامية لا تتوافق مع التركيز التلقائي، يجب أن تظل عمليات معاودة الاتصال لواجهة برمجة التطبيقات "مزيّفة" كما هو موضّح.
• [C-0-6] يجب التعرّف على كل اسم مَعلمة محدّد كثابت في الفئة android.hardware.Camera.Parameters والفئة android.hardware.camera2.CaptureRequest والالتزام به. في المقابل، يجب ألا تقبل عمليات تنفيذ الأجهزة أو تتعرّف على ثوابت السلسلة التي يتم تمريرها إلى طريقة android.hardware.Camera.setParameters() بخلاف تلك الموثّقة كثوابت في android.hardware.Camera.Parameters. أي أنّ عمليات تنفيذ الجهاز يجب أن تتوافق مع جميع مَعلمات الكاميرا العادية إذا كان الجهاز يسمح بذلك، ويجب ألا تتوافق مع أنواع مَعلمات الكاميرا المخصّصة. على سبيل المثال، يجب أن تتوافق عمليات تنفيذ الأجهزة التي تتيح التقاط الصور باستخدام تقنيات التصوير بنطاق عالي الديناميكية (HDR) مع مَعلمة الكاميرا Camera.SCENE_MODE_HDR.
• [C-0-7] يجب الإبلاغ عن مستوى التوافق المناسب باستخدام السمة android.info.supportedHardwareLevel على النحو الموضّح في حزمة تطوير البرامج (SDK) لنظام التشغيل Android، والإبلاغ عن علامات ميزات إطار العمل المناسبة.
• [C-0-8] يجب أيضًا الإفصاح عن إمكانات الكاميرا الفردية android.hardware.camera2 من خلال السمة android.request.availableCapabilities والإفصاح عن علامات الميزات المناسبة، ويجب تحديد علامة الميزة إذا كانت أي من أجهزة الكاميرا المرفقة بها تتوافق مع الميزة.
• [C-0-9] يجب بثّ الغرض Camera.ACTION_NEW_PICTURE كلما تم التقاط صورة جديدة بالكاميرا وتمت إضافة إدخال الصورة إلى متجر الوسائط.
• [C-0-10] يجب بثّ الغرض Camera.ACTION_NEW_VIDEO كلما سجّلت الكاميرا فيديو جديدًا وتمت إضافة إدخال الصورة إلى "متجر الوسائط".
• ‫[C-0-11] يجب أن تكون جميع الكاميرات التي يمكن الوصول إليها من خلال واجهة برمجة التطبيقات android.hardware.Camera المتوقّفة نهائيًا متاحة أيضًا من خلال واجهة برمجة التطبيقات android.hardware.camera2.
• [C-SR] بالنسبة إلى الأجهزة التي تحتوي على كاميرات RGB متعددة تواجه الاتجاه نفسه، يُنصح بشدة بتوفير جهاز كاميرا منطقي يعرض الإمكانية CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA، ويتألف من جميع كاميرات RGB التي تواجه هذا الاتجاه كأجهزة فرعية مادية.

في حال توفير عمليات تنفيذ الأجهزة لواجهة برمجة تطبيقات كاميرا خاصة لتطبيقات الجهات الخارجية، يجب أن تستوفي ما يلي:

• [C-1-1] يجب تنفيذ واجهة برمجة تطبيقات الكاميرا هذه باستخدام واجهة برمجة التطبيقات android.hardware.camera2.
• يمكن تقديم علامات و/أو إضافات المورّدين إلى واجهة برمجة التطبيقات android.hardware.camera2.

‫7.5.5. اتجاه الكاميرا

إذا كانت عمليات تنفيذ الأجهزة تتضمّن كاميرا أمامية أو خلفية، يجب أن تستوفي هذه الكاميرات ما يلي:

• [C-1-1] يجب أن يكون اتجاهها بحيث يتوافق البُعد الأطول للكاميرا مع البُعد الأطول للشاشة. أي أنّه عند حمل الجهاز في الوضع الأفقي، يجب أن تلتقط الكاميرات الصور في الوضع الأفقي. وينطبق ذلك بغض النظر عن الاتجاه الطبيعي للجهاز، أي أنّه ينطبق على الأجهزة التي يكون اتجاهها الأفقي هو الاتجاه الأساسي، وكذلك الأجهزة التي يكون اتجاهها العمودي هو الاتجاه الأساسي.

‫7.6. الذاكرة ومساحة التخزين

7.6.1. الحد الأدنى من الذاكرة ومساحة التخزين

عمليات تنفيذ الأجهزة:

• [C-0-1] يجب أن يتضمّن إدارة التنزيل التي يمكن للتطبيقات استخدامها لتنزيل ملفات البيانات، ويجب أن تكون قادرة على تنزيل ملفات فردية بحجم 100 ميغابايت على الأقل إلى الموقع الجغرافي التلقائي "للتخزين المؤقت".

‫7.6.2. مساحة التخزين المشتركة للتطبيقات

عمليات تنفيذ الأجهزة:

• [C-0-1] يجب توفير مساحة تخزين يمكن للتطبيقات مشاركتها، ويُشار إليها أيضًا باسم "مساحة التخزين الخارجية المشتركة" أو "مساحة التخزين المشتركة للتطبيقات" أو مسار Linux "/sdcard" الذي يتم تركيبها عليه.
• [C-0-2] يجب ضبط الجهاز على أن تكون وحدة التخزين المشتركة مثبّتة تلقائيًا، أي "بدون الحاجة إلى إجراء أي خطوات"، بغض النظر عمّا إذا كانت وحدة التخزين مدمجة في أحد مكونات وحدة التخزين الداخلية أو في وسيط تخزين قابل للإزالة (مثل فتحة بطاقة Secure Digital).
• [C-0-3] يجب ربط مساحة التخزين المشتركة للتطبيق مباشرةً بمسار Linux sdcard أو تضمين رابط رمزي لنظام Linux من sdcard إلى نقطة الربط الفعلية.
• [C-0-4] يجب فرض إذن android.permission.WRITE_EXTERNAL_STORAGE على مساحة التخزين المشتركة هذه كما هو موضّح في حزمة تطوير البرامج (SDK).
• [C-0-5] يجب تفعيل ميزة "التخزين المحصور" تلقائيًا لجميع التطبيقات التي تستهدف المستوى 29 أو أعلى لواجهة برمجة التطبيقات، باستثناء الحالات التالية:
  • عند تثبيت التطبيق قبل ترقية الجهاز إلى المستوى 29 لواجهة برمجة التطبيقات، بغض النظر عن المستوى المستهدف لواجهة برمجة التطبيقات في التطبيق
  • عندما يطلب التطبيق إذن الوصول إلى android:requestLegacyExternalStorage="true" في بيان التطبيق
  • عندما يتم منح التطبيق إذن android.permission.WRITE_MEDIA_STORAGE
• [C-0-6] يجب فرض عدم السماح للتطبيقات التي تم تفعيل ميزة "مساحة التخزين المحصورة" فيها بالوصول المباشر إلى نظام الملفات خارج الأدلة الخاصة بالتطبيق، وذلك على النحو الذي تعرضه طرق واجهة برمجة التطبيقات Context، مثل طرق Context.getExternalFilesDirs() وContext.getExternalCacheDirs() وContext.getExternalMediaDirs() وContext.getObbDirs().
• [C-0-7] يجب إخفاء البيانات الوصفية للموقع الجغرافي، مثل علامات EXIF لنظام تحديد المواقع العالمي (GPS)، المخزَّنة في ملفات الوسائط عند الوصول إلى هذه الملفات من خلال MediaStore، إلا عندما يكون لدى التطبيق الذي يجري المكالمة إذن ACCESS_MEDIA_LOCATION.

يمكن أن تستوفي عمليات تنفيذ الأجهزة المتطلبات المذكورة أعلاه باستخدام أيّ مما يلي:

• مساحة تخزين قابلة للإزالة يمكن للمستخدم الوصول إليها، مثل فتحة بطاقة Secure Digital (SD).
• جزء من وحدة التخزين الداخلية (غير القابلة للإزالة) كما هو مستخدَم في "مشروع Android المفتوح المصدر" ‏ (AOSP)

في حال استخدام عمليات تنفيذ الأجهزة لمساحة تخزين قابلة للإزالة لاستيفاء المتطلبات المذكورة أعلاه، يجب أن تستوفي ما يلي:

• [C-1-1] يجب تنفيذ تحذير في واجهة المستخدم على شكل إشعار مؤقت أو نافذة منبثقة لتنبيه المستخدم عند عدم إدخال وسيط تخزين في الفتحة.
• [C-1-2] يجب أن يتضمّن وسيط تخزين منسَّقًا بتنسيق FAT (مثل بطاقة SD) أو أن يوضّح على العلبة والمواد الأخرى المتوفّرة عند الشراء أنّه يجب شراء وسيط التخزين بشكل منفصل.

إذا كانت عمليات تنفيذ الأجهزة تستخدم جزءًا من مساحة التخزين غير القابلة للإزالة لاستيفاء المتطلبات المذكورة أعلاه، يجب أن:

• يجب استخدام تنفيذ AOSP لمساحة التخزين المشتركة للتطبيقات الداخلية.
• قد تتم مشاركة مساحة التخزين مع البيانات الخاصة بالتطبيق.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مسارات متعددة لوحدة التخزين المشتركة (مثل فتحة بطاقة SD ووحدة التخزين الداخلية المشتركة)، يجب أن:

• [C-2-1] يجب ألا يسمح إلا لتطبيقات Android المثبَّتة مسبقًا والتطبيقات ذات الامتيازات التي لديها إذن WRITE_MEDIA_STORAGE بالكتابة إلى وحدة التخزين الخارجية الثانوية، باستثناء الكتابة إلى الدلائل الخاصة بالحزمة أو داخل URI التي يتم عرضها عند تشغيل الغرض ACTION_OPEN_DOCUMENT_TREE.
• [C-2-2] يجب أن يشترط منح إذن الوصول المباشر المرتبط بالإذن android.permission.WRITE_MEDIA_STORAGE للتطبيقات المرئية للمستخدم فقط عند منح الإذن android.permission.WRITE_EXTERNAL_STORAGE أيضًا.
• [SR] يُنصح بشدة بأن تستخدم تطبيقات Android المثبَّتة مسبقًا والتطبيقات ذات الامتيازات واجهات برمجة التطبيقات العامة، مثل MediaStore، للتفاعل مع أجهزة التخزين بدلاً من الاعتماد على إذن الوصول المباشر الذي يمنحه android.permission.WRITE_MEDIA_STORAGE.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB متوافقًا مع وضع الأجهزة الطرفية USB، يجب أن تستوفي ما يلي:

• [C-3-1] يجب توفير آلية للوصول إلى البيانات في مساحة التخزين المشتركة للتطبيق من جهاز كمبيوتر مضيف.
• يجب عرض المحتوى من كلا مسارَي التخزين بشفافية من خلال خدمة "ماسح الوسائط" في Android وandroid.provider.MediaStore.
• يمكن استخدام وحدة تخزين USB، ولكن يجب استخدام بروتوكول نقل الوسائط لاستيفاء هذا الشرط.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB مع وضع جهاز USB الطرفي وتتوافق مع بروتوكول نقل الوسائط، يجب أن تستوفي ما يلي:

• يجب أن يكون متوافقًا مع مضيف MTP المرجعي على Android، وهو نقل الملفات في Android.
• يجب الإبلاغ عن فئة جهاز USB بقيمة 0x00.
• يجب أن يتم الإبلاغ عن اسم واجهة USB على أنّه "MTP".

‫7.6.3 وحدة تخزين قابلة للاستخدام

إذا كان من المتوقّع أن يكون الجهاز جوّالاً على عكس التلفزيون، تكون عمليات تنفيذ الجهاز كما يلي:

• [SR] يُنصح بشدة بتنفيذ ميزة "وحدة التخزين القابلة للنقل" في موقع جغرافي ثابت على المدى الطويل، لأنّ فصلها عن طريق الخطأ قد يؤدي إلى فقدان البيانات أو تلفها.

إذا كان منفذ جهاز التخزين القابل للإزالة في مكان ثابت على المدى الطويل، مثل داخل حجرة البطارية أو غطاء واقٍ آخر، تكون عمليات تنفيذ الجهاز على النحو التالي:

• [SR] ننصح بشدة بتنفيذ وحدة تخزين قابلة للاستخدام.

7.7. USB

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB، يجب أن تستوفي ما يلي:

• يجب أن يتوافق مع وضع الجهاز الملحق USB ووضع المضيف USB.

7.7.1. وضع الأجهزة الملحقة المزودة بكابل USB

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB يتيح وضع الأجهزة الطرفية:

• [C-1-1] يجب أن يكون المنفذ قابلاً للتوصيل بمضيف USB يحتوي على منفذ USB عادي من النوع A أو النوع C.
• ‫[C-1-2] يجب عرض القيمة الصحيحة لـ iSerialNumber في واصف جهاز USB العادي من خلال android.os.Build.SERIAL.
• [C-1-3] يجب أن يرصد الجهاز الشواحن التي تبلغ شدة تيارها 1.5 أمبير و3.0 أمبير وفقًا لمعيار مقاومة النوع C، ويجب أن يرصد التغييرات في الإعلان إذا كان متوافقًا مع منفذ USB من النوع C.
• [SR] يجب أن يستخدم المنفذ عامل الشكل micro-B أو micro-AB أو Type-C USB. يُنصح بشدة بأن تستوفي أجهزة Android الحالية والجديدة هذه المتطلبات لتتمكّن من الترقية إلى إصدارات النظام الأساسي المستقبلية.
• [SR] يجب أن يكون المنفذ في أسفل الجهاز (وفقًا للاتجاه الطبيعي) أو يجب تفعيل تدوير الشاشة في جميع التطبيقات (بما في ذلك الشاشة الرئيسية)، وذلك لضمان عرض المحتوى بشكل صحيح عند توجيه الجهاز بحيث يكون المنفذ في الأسفل. يُنصح بشدة بأن تستوفي أجهزة Android الحالية والجديدة هذه المتطلبات لتتمكّن من الترقية إلى إصدارات المنصة المستقبلية.
• [SR] يجب توفير إمكانية سحب تيار بقوة 1.5 أمبير أثناء إرسال إشارة صوتية عالية السرعة وحركة المرور كما هو محدّد في مواصفات شحن البطارية عبر منفذ USB، الإصدار 1.2. يُنصح بشدة بأن تستوفي أجهزة Android الحالية والجديدة هذه المتطلبات لتتمكّن من الترقية إلى إصدارات النظام الأساسي المستقبلية.
• [SR] يُنصح بشدة بعدم توفير طرق شحن خاصة تعدّل جهد Vbus إلى ما يتجاوز المستويات التلقائية، أو تغيّر أدوار المصدر/المستقبل، لأنّ ذلك قد يؤدي إلى حدوث مشاكل في التشغيل التفاعلي مع الشواحن أو الأجهزة التي تتوافق مع طرق USB Power Delivery العادية. على الرغم من أنّ هذا الإجراء يُصنّف على أنّه "يُنصح به بشدة"، قد نطلب في إصدارات Android المستقبلية أن تتيح جميع الأجهزة من النوع C إمكانية التشغيل التوافقي الكامل مع الشواحن العادية من النوع C.
• [SR] يُنصح بشدة بتوفير ميزة Power Delivery لتبديل أدوار البيانات والطاقة عند توفير منفذ USB من النوع C ووضع مضيف USB.
• يجب أن تتوافق مع معيار Power Delivery للشحن بجهد عالٍ، وأن تتوافق مع "الأوضاع البديلة"، مثل عرض المحتوى على شاشة خارجية.
• يجب تنفيذ واجهة برمجة التطبيقات (API) ومواصفات Android Open Accessory (AOA) على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB وتنفّذ مواصفات AOA، فإنّها:

• [C-2-1] يجب الإفصاح عن توفّر ميزة الأجهزة android.hardware.usb.accessory.
• [C-2-2] يجب أن يتضمّن فئة التخزين الكبير عبر USB السلسلة "android" في نهاية سلسلة وصف الواجهة iInterface الخاصة بالتخزين الكبير عبر USB

‫7.7.2. وضع مستضيف USB

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB متوافقًا مع وضع المضيف، يجب أن تستوفي ما يلي:

• [C-1-1] يجب تنفيذ واجهة برمجة تطبيقات مضيف USB لنظام التشغيل Android على النحو الموضّح في حزمة تطوير البرامج (SDK) لنظام التشغيل Android، ويجب الإفصاح عن إمكانية استخدام ميزة الجهاز android.hardware.usb.host.
• [C-1-2] يجب توفير إمكانية توصيل أجهزة USB الطرفية العادية، أي يجب أن يتم:
  • أن يتضمّن منفذًا من النوع C أو أن يتم شحنه مع كابلات تحوّل منفذًا خاصًا بالجهاز إلى منفذ USB من النوع C (جهاز USB من النوع C).
  • أن يتضمّن منفذًا من النوع A أو أن يتم شحنه مع كابلات تحوّل منفذًا خاصًا بالجهاز إلى منفذ USB عادي من النوع A
  • أن يتضمّن منفذ micro-AB على الجهاز، ويجب أن يكون مزوّدًا بكابل متوافق مع منفذ عادي من النوع A
• [C-1-3] يجب ألا يتم شحنها مع محوّل يحوّل من منافذ USB من النوع A أو micro-AB إلى منفذ من النوع C (مقبس).
• [C-SR] يُنصح بشدة بتنفيذ فئة الصوت عبر USB كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
• يجب أن يتيح شحن جهاز USB الطرفي المتصل أثناء وضع المضيف، وأن يعلن عن تيار مصدر لا يقل عن 1.5 أمبير على النحو المحدّد في قسم "معلمات الإنهاء" من مواصفات كابل وموصل USB من النوع C، الإصدار 1.2 لموصلات USB من النوع C أو باستخدام نطاق تيار الإخراج لمنفذ الشحن السفلي(CDP) على النحو المحدّد في مواصفات شحن بطارية USB، الإصدار 1.2 لموصلات Micro-AB.
• يجب تنفيذ معايير USB من النوع C وتوفير الدعم لها.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB يتيح وضع المضيف وفئة صوت USB، يجب أن:

• [C-2-1] يجب أن يتوافق مع فئة أجهزة واجهة المستخدم البشرية (HID) عبر USB.
• [C-2-2] يجب أن يتيح رصد حقول بيانات HID التالية وتعيينها، كما هو محدّد في جداول استخدام USB HID وطلب استخدام الأوامر الصوتية إلى الثوابت KeyEvent على النحو التالي:
  • صفحة الاستخدام (0xC) معرّف الاستخدام (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • صفحة الاستخدام (0xC) معرّف الاستخدام (0x0E9): KEYCODE_VOLUME_UP
  • صفحة الاستخدام (0xC) معرّف الاستخدام (0x0EA): KEYCODE_VOLUME_DOWN
  • صفحة الاستخدام (0xC) رقم تعريف الاستخدام (0x0CF): KEYCODE_VOICE_ASSIST

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB يتيح وضع المضيف وStorage Access Framework (SAF)، فإنّها:

• [C-3-1] يجب أن يتعرّف التطبيق على أي أجهزة متصلة عن بُعد باستخدام بروتوكول نقل الوسائط (MTP) وأن يتيح الوصول إلى محتواها من خلال أغراض ACTION_GET_CONTENT وACTION_OPEN_DOCUMENT وACTION_CREATE_DOCUMENT.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB يتيح وضع المضيف ومنفذ USB من النوع C، يجب أن:

• [C-4-1] يجب تنفيذ وظيفة المنفذ المزدوج الدور على النحو المحدّد في مواصفات USB Type-C (القسم 4.5.1.3.3).
• [SR] يُنصح بشدة بتوفير منفذ DisplayPort، ويجب توفير معدّلات نقل البيانات SuperSpeed عبر منفذ USB، ويُنصح بشدة بتوفير ميزة Power Delivery لتبديل أدوار البيانات والطاقة.
• [SR] يُنصح بشدة بعدم إتاحة "وضع ملحق محوّل الصوت" كما هو موضّح في الملحق (أ) من مواصفات كابل وموصل USB من النوع C، الإصدار 1.2.
• يجب تنفيذ نموذج Try.* الأنسب لشكل الجهاز. على سبيل المثال، يجب أن ينفّذ جهاز محمول نموذج Try.SNK.

7.8. الصوت

‫7.8.1. الميكروفون

إذا كانت عمليات تنفيذ الأجهزة تتضمّن ميكروفونًا، يجب أن تستوفي ما يلي:

• [C-1-1] يجب عرض ثابت ميزة android.hardware.microphone.
• [C-1-2] يجب استيفاء متطلبات التسجيل الصوتي الواردة في الفقرة 5.4.
• [C-1-3] يجب استيفاء متطلبات تأخُّر الصوت المحدّدة في الفقرة 5.6.
• [SR] يُنصح بشدة بتوفير إمكانية تسجيل الصوت القريب من نطاق ما فوق الصوتي كما هو موضّح في الفقرة 7.8.3.

إذا كانت عمليات تنفيذ الأجهزة لا تتضمّن ميكروفونًا، يجب أن:

• [C-2-1] يجب عدم عرض الثابت الخاص بميزة android.hardware.microphone.
• [C-2-2] يجب تنفيذ واجهة برمجة التطبيقات لتسجيل الصوت كعمليات غير فعّالة على الأقل، وذلك وفقًا للفقرة 7.

‫7.8.2. إخراج الصوت

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مكبّر صوت أو منفذ إخراج صوتي/متعدّد الوسائط لجهاز طرفي لإخراج الصوت، مثل مقبس صوت رباعي الموصلات 3.5 ملم أو منفذ وضع مضيف USB باستخدام فئة صوت USB، يجب أن:

• [C-1-1] يجب عرض ثابت ميزة android.hardware.audio.output.
• [C-1-2] يجب استيفاء متطلبات تشغيل الصوت الواردة في الفقرة 5.5.
• [C-1-3] يجب استيفاء متطلبات تأخُّر الصوت المحدّدة في الفقرة 5.6.
• [SR] يُنصح بشدة بتوفير إمكانية تشغيل الصوت القريب من نطاق الموجات فوق الصوتية على النحو الموضّح في الفقرة 7.8.3.

إذا لم تتضمّن عمليات تنفيذ الأجهزة مكبّر صوت أو منفذ إخراج صوت، يجب أن:

• [C-2-1] يجب عدم عرض ميزة android.hardware.audio.output.
• [C-2-2] يجب تنفيذ واجهات برمجة التطبيقات ذات الصلة بإخراج الصوت كعمليات غير فعّالة على الأقل.

لأغراض هذا القسم، "منفذ الإخراج" هو واجهة مادية، مثل مقبس صوت مقاس 3.5 ملم أو HDMI أو منفذ وضع المضيف USB مع فئة صوت USB. لا يُعدّ توفير إمكانية إخراج الصوت عبر بروتوكولات مستندة إلى الراديو، مثل البلوتوث أو شبكة Wi-Fi أو شبكة الجوّال، من ضمن "منفذ الإخراج".

‫7.8.2.1. منافذ الصوت التناظري

لكي تكون سماعات الرأس وملحقات الصوت الأخرى متوافقة مع مقبس الصوت 3.5 ملم في جميع أنحاء نظام Android الأساسي، إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذًا واحدًا أو أكثر من منافذ الصوت التناظرية، يجب أن تستوفي ما يلي:

• [C-SR] يُنصح بشدة بأن يتضمّن جهاز البث المباشر واحدًا على الأقل من منافذ الصوت على شكل مقبس صوتي 3.5 ملم بأربعة موصلات.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقبس صوت رباعي الموصلات مقاس 3.5 ملم، يجب أن تستوفي ما يلي:

• ‫[C-1-1] يجب أن يتيح تشغيل الصوت على سماعات رأس ستيريو وسماعات ستيريو مزوّدة بميكروفون.
• [C-1-2] يجب أن تتوافق الأجهزة مع مقابس الصوت TRRS بترتيب دبابيس CTIA.
• [C-1-3] يجب أن يتيح رصد نطاقات المعاوقة المكافئة الثلاثة التالية بين الميكروفون وموصلات التأريض على قابس الصوت وربطها برموز المفاتيح:
  • ‫70 أوم أو أقل: KEYCODE_HEADSETHOOK
  • من 210 إلى 290 أوم: KEYCODE_VOLUME_UP
  • ‫360-680 أوم: KEYCODE_VOLUME_DOWN
• [C-1-4] يجب أن يتم تشغيل ACTION_HEADSET_PLUG عند إدخال القابس، ولكن فقط بعد أن تلامس جميع نقاط التلامس الموجودة على القابس الأجزاء ذات الصلة في المقبس.
• [C-1-5] يجب أن يكون الجهاز قادرًا على توفير جهد كهربائي خارجي لا يقل عن 150 ملي فولت ±% 10 على مقاومة سماعة تبلغ 32 أوم.
• [C-1-6] يجب أن يتراوح جهد انحياز الميكروفون بين 1.8 و2.9 فولت.
• [C-1-7] يجب رصد نطاق المعاوقة المكافئة التالي بين موصّلي الميكروفون والأرضي في قابس الصوت وربطه برمز المفتاح:
  • من 110 إلى 180 أوم: KEYCODE_VOICE_ASSIST
• [C-SR] يُنصح بشدة بتوفير مقابس صوتية بترتيب دبابيس OMTP.
• [C-SR] يُنصح بشدة بتوفير إمكانية تسجيل الصوت من سمّاعات الرأس الستيريو المزودة بميكروفون.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقبس صوت رباعي الموصلات مقاس 3.5 ملم ويتوافق مع ميكروفون، وتبث android.intent.action.HEADSET_PLUG مع ضبط قيمة الميكروفون الإضافية على 1، فإنّها:

• ‫[C-2-1] يجب أن يتيح رصد الميكروفون في الملحق الصوتي الموصّل.

‫7.8.2.2. منافذ الصوت الرقمي

للتوافق مع سماعات الرأس وغيرها من ملحقات الصوت التي تستخدم موصلات USB-C وتنفّذ (فئة صوت USB) في جميع أنحاء نظام Android المتكامل على النحو المحدّد في مواصفات سماعة رأس USB لنظام Android

راجِع القسم 2.2.1 لمعرفة المتطلبات الخاصة بالأجهزة.

‫7.8.3 الموجات فوق الصوتية القريبة

يتراوح نطاق الصوت القريب من الموجات فوق الصوتية بين 18.5 كيلوهرتز و20 كيلوهرتز.

عمليات تنفيذ الأجهزة:

• يجب الإبلاغ بشكل صحيح عن إتاحة إمكانية استخدام الصوت القريب من نطاق الموجات فوق الصوتية من خلال واجهة برمجة التطبيقات AudioManager.getProperty على النحو التالي:

إذا كانت قيمة PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND هي "true"، يجب أن تستوفي مصادر الصوت VOICE_RECOGNITION وUNPROCESSED المتطلبات التالية:

• ‫[C-1-1] يجب ألا يقل متوسط استجابة طاقة الميكروفون في النطاق من 18.5 كيلو هرتز إلى 20 كيلو هرتز عن 15 ديسيبل مقارنةً بالاستجابة عند 2 كيلو هرتز.
• ‫[C-1-2] يجب ألا تقل نسبة الإشارة إلى الضوضاء غير المرجّحة للميكروفون عن 50 ديسيبل في نطاق التردد من 18.5 كيلو هرتز إلى 20 كيلو هرتز عند استخدام نغمة بتردد 19 كيلو هرتز بمستوى ‎-26 dBFS.

إذا كانت قيمة PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND هي "true":

• [C-2-1] يجب ألا يقل متوسط استجابة السمّاعة في نطاق التردد من 18.5 كيلو هرتز إلى 20 كيلو هرتز عن 40 ديسيبل تحت الاستجابة عند 2 كيلو هرتز.

‫7.8.4. سلامة الإشارة

عمليات تنفيذ الأجهزة:

• يجب توفير مسار إشارة صوتية خالٍ من الأخطاء لكلّ من عمليات الإدخال والإخراج على الأجهزة المحمولة، وذلك على النحو المحدّد بعدم تسجيل أي أخطاء أثناء اختبار مدته دقيقة واحدة لكل مسار. اختبِر باستخدام [OboeTester] (https://github.com/google/oboe/tree/master/apps/OboeTester) "اختبار الخلل الآلي".

يتطلّب الاختبار جهاز دونجل لربط الصوت، ويتم استخدامه مباشرةً في مقبس 3.5 ملم و/أو مع محوّل من USB-C إلى 3.5 ملم. يجب اختبار جميع منافذ إخراج الصوت.

يتوافق OboeTester حاليًا مع مسارات AAudio، لذا يجب اختبار التركيبات التالية بحثًا عن أخطاء باستخدام AAudio:

يجب أن يستوفي البث الموثوق المعايير التالية لنسبة الإشارة إلى الضوضاء (SNR) والتشويه التوافقي الكلي (THD) لموجة جيبية بتردد 2000 هرتز.

‫7.9. الواقع الافتراضي

يتضمّن نظام التشغيل Android واجهات برمجة تطبيقات ومرافق لإنشاء تطبيقات "الواقع الافتراضي" (VR)، بما في ذلك تجارب الواقع الافتراضي عالية الجودة على الأجهزة الجوّالة. يجب أن تنفّذ الأجهزة هذه الواجهات والسلوكيات بشكل سليم، كما هو موضّح بالتفصيل في هذا القسم.

‫7.9.1. وضع الواقع الافتراضي

يتضمّن نظام التشغيل Android إمكانية استخدام وضع الواقع الافتراضي، وهي ميزة تعالج العرض المجسّم للإشعارات وتوقف مكوّنات واجهة مستخدم النظام أحادية العين أثناء تركيز تطبيق الواقع الافتراضي على المستخدم.

‫7.9.2. وضع الواقع الافتراضي - أداء عالٍ

إذا كانت عمليات تنفيذ الأجهزة تتيح وضع الواقع الافتراضي، يجب أن:

• [C-1-1] يجب أن يحتوي على نواتَين ماديتَين على الأقل.
• [C-1-2] يجب الإفصاح عن ميزة android.hardware.vr.high_performance.
• ‫[C-1-3] يجب أن يتوافق الجهاز مع وضع الأداء المستدام.
• [C-1-4] يجب أن يتوافق مع OpenGL ES 3.2.
• [C-1-5] يجب أن تتوافق مع android.hardware.vulkan.level 0.
• يجب أن تتوافق مع الإصدار 1 من android.hardware.vulkan.level أو إصدار أحدث.
• [C-1-6] يجب تنفيذ EGL_KHR_mutable_render_buffer وEGL_ANDROID_front_buffer_auto_refresh وEGL_ANDROID_get_native_client_buffer وEGL_KHR_fence_sync وEGL_KHR_wait_sync وEGL_IMG_context_priority وEGL_EXT_protected_content وEGL_EXT_image_gl_colorspace، وعرض الإضافات في قائمة إضافات EGL المتاحة.
• [C-1-8] يجب تنفيذ GL_EXT_multisampled_render_to_texture2 وGL_OVR_multiview وGL_OVR_multiview2 وGL_OVR_multiview_multisampled_render_to_texture وGL_EXT_protected_textures وعرض الإضافات في قائمة إضافات GL المتاحة.
• [C-SR] يُنصح بشدة بتنفيذ GL_EXT_external_buffer وGL_EXT_EGL_image_array وعرض الإضافات في قائمة إضافات GL المتاحة.
• [C-SR] يُنصح بشدة بتوفير إمكانية استخدام Vulkan 1.1.
• [C-SR] يُنصح بشدة بتنفيذ VK_ANDROID_external_memory_android_hardware_buffer وVK_GOOGLE_display_timing وVK_KHR_shared_presentable_image وعرضها في قائمة إضافات Vulkan المتاحة.
• [C-SR] يُنصح بشدة بعرض مجموعة واحدة على الأقل من قوائم انتظار Vulkan التي تحتوي فيها flags على كل من VK_QUEUE_GRAPHICS_BIT وVK_QUEUE_COMPUTE_BIT، وأن تكون قيمة queueCount هي 2 على الأقل.
• ‫[C-1-7] يجب أن يكون بإمكان وحدة معالجة الرسومات والشاشة مزامنة الوصول إلى المخزن المؤقت الأمامي المشترَك، وذلك لعرض محتوى الواقع الافتراضي بمعدل 60 إطارًا في الثانية مع سياقَي عرض بالتناوب بين العينين بدون أي تشوّهات مرئية.
• [C-1-9] يجب توفير إمكانية استخدام العلامات AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER وAHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA وAHARDWAREBUFFER_USAGE_PROTECTED_CONTENT على النحو الموضّح في NDK.
• [C-1-10] يجب توفير إمكانية استخدام AHardwareBuffer مع أي مجموعة من علامات الاستخدام AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT وAHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE وAHARDWAREBUFFER_USAGE_PROTECTED_CONTENT للتنسيقات التالية على الأقل: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM وAHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM وAHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM وAHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
• [C-SR] يُنصح بشدة بتوفير إمكانية تخصيص AHardwareBuffers بأكثر من طبقة واحدة وعلامات وتنسيقات محددة في C-1-10.
• [C-1-11] يجب أن تتوافق مع فك ترميز H.264 بدقة 3840 × 2160 على الأقل بمعدل 30 لقطة في الثانية، مع ضغطها إلى 40 ميغابت في الثانية في المتوسط (أي ما يعادل 4 حالات بدقة 1920 × 1080 بمعدل 30 لقطة في الثانية - 10 ميغابت في الثانية أو حالتين بدقة 1920 × 1080 بمعدل 60 لقطة في الثانية - 20 ميغابت في الثانية).
• ‫[C-1-12] يجب أن يتوافق مع HEVC وVP9، ويجب أن يكون قادرًا على فك ترميز 1920 × 1080 على الأقل بمعدل 30 لقطة في الثانية مضغوطة بمتوسط 10 ميغابت في الثانية، ويجب أن يكون قادرًا على فك ترميز 3840 × 2160 بمعدل 30 لقطة في الثانية و20 ميغابت في الثانية (أي ما يعادل 4 حالات من 1920 × 1080 بمعدل 30 لقطة في الثانية و5 ميغابت في الثانية).
• ‫[C-1-13] يجب أن تتوافق مع واجهة برمجة التطبيقات HardwarePropertiesManager.getDeviceTemperatures وأن تعرض قيمًا دقيقة لدرجة حرارة الجلد.
• [C-1-14] يجب أن يتضمّن شاشة مدمجة، ويجب أن تكون درجة الدقة 1920 × 1080 على الأقل.
• [C-SR] يُنصح بشدة أن تكون دقة العرض 2560 × 1440 على الأقل.
• ‫[C-1-15] يجب أن يتم تعديل الشاشة بمعدّل 60 هرتز على الأقل أثناء وضع الواقع الافتراضي.
• ‫[C-1-17] يجب أن تتيح الشاشة وضعًا منخفض الثبات مع ثبات ≤ 5 مللي ثانية، ويتم تعريف الثبات على أنّه مقدار الوقت الذي ينبعث فيه الضوء من البكسل.
• ‫[C-1-18] يجب أن يتوافق مع الإصدار 4.2 من البلوتوث و"إضافة طول بيانات" في البلوتوث المنخفض الطاقة الفقرة 7.4.3.
• [C-1-19] يجب أن يتيح الجهاز إمكانية تسجيل نوع القناة المباشرة بشكل صحيح لجميع أنواع أجهزة الاستشعار التلقائية التالية:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR] يُنصح بشدة بتوفير نوع القناة المباشرة TYPE_HARDWARE_BUFFER لجميع أنواع القنوات المباشرة المذكورة أعلاه.
• [C-1-21] يجب استيفاء المتطلبات المتعلّقة بالجيروسكوب ومقياس التسارع ومقياس المغناطيسية في android.hardware.hifi_sensors، كما هو محدّد في الفقرة 7.3.9.
• [C-SR] ننصح بشدة بتوفير ميزة android.hardware.sensor.hifi_sensors.
• [C-1-22] يجب ألا يزيد وقت استجابة الحركة من البداية إلى النهاية عن 28 ملي ثانية.
• [C-SR] يُنصح بشدة ألا يتجاوز وقت استجابة الحركة من البداية إلى النهاية 20 ملي ثانية.
• [C-1-23] يجب أن تتضمّن نسبة الإطار الأول، وهي النسبة بين سطوع وحدات البكسل في الإطار الأول بعد الانتقال من الأسود إلى الأبيض وسطوع وحدات البكسل البيضاء في الحالة الثابتة، بنسبة %85 على الأقل.
• [C-SR] يُنصح بشدة أن تكون نسبة الإطار الأول %90 على الأقل.
• يمكن توفير نواة حصرية للتطبيق الذي يعمل في المقدّمة، ويمكن إتاحة استخدام واجهة برمجة التطبيقات Process.getExclusiveCores لعرض أعداد نوى وحدة المعالجة المركزية الحصرية للتطبيق الذي يعمل في المقدّمة.

في حال توفّر النواة الحصرية، يجب أن تستوفي النواة الشروط التالية:

• [C-2-1] يجب ألا يسمح بتشغيل أي عمليات أخرى في مساحة المستخدم (باستثناء برامج تشغيل الأجهزة التي يستخدمها التطبيق)، ولكن يجوز السماح بتشغيل بعض عمليات النواة حسب الضرورة.

8. الأداء والطاقة

تُعدّ بعض معايير الأداء والطاقة الدنيا ضرورية لتجربة المستخدم وتؤثّر في الافتراضات الأساسية التي يضعها المطوّرون عند تطوير تطبيق.

‫8.1. اتّساق تجربة المستخدم

يمكن توفير واجهة مستخدم سلسة للمستخدم النهائي إذا كانت هناك بعض الحد الأدنى من المتطلبات لضمان معدل إطارات ثابت وأوقات استجابة للتطبيقات والألعاب. قد تتضمّن عمليات تنفيذ الأجهزة، وفقًا لنوع الجهاز، متطلبات قابلة للقياس بشأن وقت استجابة واجهة المستخدم وتبديل المهام على النحو الموضّح في القسم 2.

‫8.2 أداء الوصول إلى ملفات الإدخال والإخراج

يتيح توفير أساس مشترك لأداء موحّد في الوصول إلى الملفات في مساحة تخزين البيانات الخاصة بالتطبيق (قسم /data) لمطوّري التطبيقات وضع توقعات مناسبة تساعد في تصميم برامجهم. قد تتضمّن عمليات تنفيذ الأجهزة، استنادًا إلى نوع الجهاز، متطلبات معيّنة موضّحة في القسم 2 لعمليات القراءة والكتابة التالية:

• أداء الكتابة التسلسلية: يتم قياسها من خلال كتابة ملف بحجم 256 ميغابايت باستخدام مخزن مؤقت للكتابة بحجم 10 ميغابايت.
• أداء الكتابة العشوائية: يتم قياسها من خلال كتابة ملف بحجم 256 ميغابايت باستخدام مخزن مؤقت للكتابة بحجم 4 كيلوبايت.
• أداء القراءة التسلسلية: يتم قياسها من خلال قراءة ملف بحجم 256 ميغابايت باستخدام مخزن مؤقت للكتابة بحجم 10 ميغابايت.
• أداء القراءة العشوائية: يتم قياسها من خلال قراءة ملف بحجم 256 ميغابايت باستخدام مخزن مؤقت للكتابة بحجم 4 كيلوبايت.

8.3. أوضاع توفير الطاقة

إذا كانت عمليات تنفيذ الأجهزة تتضمّن ميزات لتحسين إدارة طاقة الجهاز مضمّنة في مشروع Android مفتوح المصدر (AOSP) أو توسّع الميزات المضمّنة في مشروع Android مفتوح المصدر (AOSP)، يجب أن تستوفي الشروط التالية:

• [C-1-1] يجب ألا تنحرف عن تنفيذ AOSP لخوارزميات التشغيل والصيانة والتنشيط واستخدام إعدادات النظام العامة لوضعَي "استعداد التطبيق" و"توفير الطاقة" في Doze.
• [C-1-2] يجب عدم الانحراف عن تنفيذ AOSP لاستخدام الإعدادات العامة لإدارة تقييد المهام والتنبيهات والشبكة للتطبيقات في كل مجموعة من مجموعات وضع "التطبيق في وضع الاستعداد".
• [C-1-3] يجب عدم الانحراف عن تنفيذ AOSP لعدد حِزم وضع "التطبيق في وضع الاستعداد" المستخدَمة في وضع "التطبيق في وضع الاستعداد".
• [C-1-4] يجب تنفيذ حِزم وضع "استعداد التطبيق" ووضع "القيلولة" كما هو موضّح في إدارة الطاقة.
• [C-1-5] يجب أن تعرض true القيمة PowerManager.isPowerSaveMode() عندما يكون الجهاز في وضع توفير الطاقة.
• [C-SR] يُنصح بشدة بتوفير إمكانية للمستخدمين لتفعيل ميزة "توفير شحن البطارية" وإيقافها.
• [C-SR] يُنصح بشدة بتوفير إمكانية للمستخدم لعرض جميع التطبيقات المستثناة من وضع "استعداد التطبيق" ووضعَي توفير الطاقة "القيلولة".

بالإضافة إلى أوضاع توفير الطاقة، يمكن أن تنفّذ أجهزة Android بعضًا من حالات الطاقة الأربع في وضع السكون أو جميعها على النحو المحدّد في "واجهة الضبط والطاقة المتقدّمة" (ACPI).

إذا كانت عمليات تنفيذ الأجهزة تنفّذ حالات الطاقة S4 على النحو المحدّد في ACPI، عليها استيفاء ما يلي:

• [C-1-1] يجب ألا يتم الانتقال إلى هذه الحالة إلا بعد أن يتّخذ المستخدم إجراءً صريحًا لوضع الجهاز في حالة غير نشطة (مثل إغلاق غطاء يشكّل جزءًا فعليًا من الجهاز أو إيقاف تشغيل مركبة أو تلفزيون) وقبل أن يعيد المستخدم تنشيط الجهاز (مثل فتح الغطاء أو إعادة تشغيل المركبة أو التلفزيون).

إذا كانت عمليات تنفيذ الأجهزة تنفّذ حالات الطاقة S3 على النحو المحدّد في ACPI، يجب أن:

• [C-2-1] يجب استيفاء المتطلبات الواردة في الفقرة C-1-1 أعلاه، أو يجب الدخول في حالة S3 فقط عندما لا تحتاج التطبيقات التابعة لجهات خارجية إلى موارد النظام (مثل الشاشة ووحدة المعالجة المركزية).

  في المقابل، يجب الخروج من حالة S3 عندما تحتاج تطبيقات تابعة لجهات خارجية إلى موارد النظام، كما هو موضّح في حزمة تطوير البرامج (SDK) هذه.

  على سبيل المثال، بينما تطلب التطبيقات التابعة لجهات خارجية إبقاء الشاشة قيد التشغيل من خلال FLAG_KEEP_SCREEN_ON أو إبقاء وحدة المعالجة المركزية قيد التشغيل من خلال PARTIAL_WAKE_LOCK، يجب ألا يدخل الجهاز في حالة S3 إلا إذا اتّخذ المستخدم إجراءً صريحًا لوضع الجهاز في حالة غير نشطة، كما هو موضّح في C-1-1. في المقابل، عندما يتم تشغيل مهمة تنفّذها تطبيقات تابعة لجهات خارجية من خلال JobScheduler أو يتم إرسال رسالة من "المراسلة عبر السحابة الإلكترونية من Firebase" إلى تطبيقات تابعة لجهات خارجية، يجب أن يخرج الجهاز من حالة S3 ما لم يضعه المستخدم في حالة غير نشطة. هذه ليست أمثلة شاملة، وينفّذ مشروع AOSP إشارات تنبيه شاملة تؤدي إلى التنبيه من هذه الحالة.

‫8.4. محاسبة استهلاك الطاقة

يوفّر احتساب استهلاك الطاقة وإعداد التقارير عنه بشكل أكثر دقة للمطوّر الحوافز والأدوات اللازمة لتحسين نمط استخدام الطاقة في التطبيق.

عمليات تنفيذ الأجهزة:

• [SR] يُنصح بشدة بتوفير ملف تعريف طاقة لكل مكوّن يحدّد قيمة استهلاك التيار لكل مكوّن من مكوّنات الجهاز ومعدّل استنزاف البطارية التقريبي الذي تسببه المكوّنات بمرور الوقت كما هو موثّق في موقع "مشروع Android المفتوح المصدر".
• [SR] يُنصح بشدة بالإبلاغ عن جميع قيم استهلاك الطاقة بوحدة "ملّي أمبير في الساعة" (mAh).
• [SR] يُنصح بشدة بالإبلاغ عن استهلاك وحدة المعالجة المركزية للطاقة لكل معرّف مستخدم (UID) خاص بكل عملية. يستوفي "مشروع Android المفتوح المصدر" هذا الشرط من خلال تنفيذ وحدة النواة uid_cputime.
• [SR] يُنصح بشدة بإتاحة معلومات استخدام الطاقة هذه من خلال أمر shell adb shell dumpsys batterystats لمطوّر التطبيق.
• يجب أن يُنسَب إلى مكوّن الجهاز نفسه إذا تعذّر تحديد التطبيق المسؤول عن استخدام طاقة مكوّن الجهاز.

‫8.5. الأداء المتّسق

يمكن أن يتفاوت الأداء بشكل كبير في التطبيقات التي تعمل لفترة طويلة وتتطلّب أداءً عاليًا، إما بسبب التطبيقات الأخرى التي تعمل في الخلفية أو بسبب تقييد وحدة المعالجة المركزية نتيجةً لحدود درجة الحرارة. يتضمّن نظام التشغيل Android واجهات برمجية آلية، وبالتالي عندما يكون الجهاز متوافقًا، يمكن للتطبيق الذي يظهر في المقدّمة أن يطلب من النظام تحسين تخصيص الموارد للتعامل مع هذه التقلبات.

عمليات تنفيذ الأجهزة:

• [C-0-1] يجب الإبلاغ عن إمكانية استخدام "وضع الأداء المستدام" بدقة من خلال طريقة واجهة برمجة التطبيقات PowerManager.isSustainedPerformanceModeSupported().

• يجب أن يتوافق مع "وضع الأداء المستدام".

في حال إبلاغ عمليات تنفيذ الأجهزة بتوافقها مع "وضع الأداء المستدام"، يجب أن:

• [C-1-1] يجب أن يوفّر التطبيق الذي يعمل في المقدّمة أعلى مستوى من الأداء لمدة 30 دقيقة على الأقل، وذلك عندما يطلب التطبيق ذلك.
• [C-1-2] يجب الالتزام بواجهة برمجة التطبيقات Window.setSustainedPerformanceMode() وغيرها من واجهات برمجة التطبيقات ذات الصلة.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن نواتَين أو أكثر لوحدة المعالجة المركزية، يجب أن تستوفي ما يلي:

• يجب توفير نواة حصرية واحدة على الأقل يمكن للتطبيق الأعلى في المقدّمة حجزها.

إذا كانت عمليات تنفيذ الأجهزة تتيح حجز نواة حصرية واحدة للتطبيق الذي يعمل في المقدّمة، يجب أن:

• [C-2-1] يجب الإبلاغ من خلال طريقة Process.getExclusiveCores() API عن أرقام تعريف النوى الحصرية التي يمكن أن يحجزها التطبيق الذي يعمل في المقدّمة.
• [C-2-2] يجب ألا يسمح بأي عمليات في مساحة المستخدم باستثناء برامج تشغيل الأجهزة التي يستخدمها التطبيق للتشغيل على النوى الحصرية، ولكن يجوز السماح بتشغيل بعض عمليات النواة حسب الضرورة.

إذا كانت عمليات تنفيذ الأجهزة لا تتوافق مع نواة حصرية، يجب أن:

• [C-3-1] يجب عرض قائمة فارغة من خلال طريقة واجهة برمجة التطبيقات Process.getExclusiveCores().

9. التوافق مع نموذج الأمان

عمليات تنفيذ الأجهزة:

• [C-0-1] يجب تنفيذ نموذج أمان متوافق مع نموذج أمان نظام Android الأساسي على النحو المحدّد في مستند مرجع الأمان والأذونات في واجهات برمجة التطبيقات ضمن مستندات مطوّري تطبيقات Android.

• [C-0-2] يجب أن يتيح تثبيت التطبيقات الموقّعة ذاتيًا بدون الحاجة إلى أي أذونات أو شهادات إضافية من أي جهات خارجية أو سلطات. على وجه التحديد، يجب أن تتوافق الأجهزة المتوافقة مع آليات الأمان الموضّحة في الأقسام الفرعية التالية.

‫9.1. الأذونات

عمليات تنفيذ الأجهزة:

• [C-0-1] يجب أن يتوافق الجهاز مع نموذج أذونات Android على النحو المحدّد في مستندات مطوّري Android. وعليهم تحديدًا فرض كل إذن على النحو الموضّح في مستندات حزمة SDK، ولا يجوز حذف أي أذونات أو تغييرها أو تجاهلها.

• يمكن إضافة أذونات إضافية، شرط ألا تكون سلاسل معرّفات الأذونات الجديدة في مساحة الاسم android.\*.

• [C-0-2] يجب عدم منح الأذونات التي تتضمّن protectionLevel بقيمة PROTECTION_FLAG_PRIVILEGED إلا للتطبيقات المثبَّتة مسبقًا في مسارات التطبيقات ذات الأذونات الخاصة ضمن صورة النظام وضِمن المجموعة الفرعية من الأذونات المدرَجة صراحةً في القائمة البيضاء لكل تطبيق. يستوفي تنفيذ AOSP هذا الشرط من خلال قراءة الأذونات المدرَجة في القائمة البيضاء لكل تطبيق من الملفات في المسار etc/permissions/ والالتزام بها، واستخدام المسار system/priv-app كمسار للتطبيقات ذات الأذونات الخاصة.

الأذونات التي لها مستوى حماية خطير هي أذونات التشغيل. تطلب التطبيقات التي تتضمّن targetSdkVersion > 22 هذه الأذونات أثناء التشغيل.

عمليات تنفيذ الأجهزة:

• [C-0-3] يجب عرض واجهة مخصّصة للمستخدم ليقرّر ما إذا كان سيمنح أذونات التشغيل المطلوبة، ويجب أيضًا توفير واجهة للمستخدم لإدارة أذونات التشغيل.
• [C-0-4] يجب أن يتضمّن تنفيذًا واحدًا فقط لكلتا واجهتَي المستخدِم.
• [C-0-5] يجب عدم منح أي أذونات تشغيل للتطبيقات المثبَّتة مسبقًا إلا في الحالات التالية:
  • يمكن الحصول على موافقة المستخدم قبل أن يستخدم التطبيق هذه البيانات.
  • ترتبط أذونات وقت التشغيل بنمط Intent تم ضبط التطبيق المُثبَّت مُسبقًا كمعالج تلقائي له.
• [C-0-6] يجب منح إذن android.permission.RECOVER_KEYSTORE لتطبيقات النظام فقط التي تسجّل "وكيل استرداد" آمنًا بشكل صحيح. يتم تعريف "عامل الاسترداد" المحمي بشكل صحيح على أنّه برنامج يعمل على الجهاز ويتزامن مع وحدة تخزين بعيدة خارج الجهاز، ومزوّد بأجهزة آمنة توفّر حماية مماثلة أو أقوى من تلك الموضّحة في خدمة Google Cloud Key Vault لمنع هجمات القوة العمياء على عامل معرفة شاشة القفل.

عمليات تنفيذ الأجهزة:

• [C-0-7] يجب الالتزام بخصائص إذن تحديد الموقع الجغرافي على Android عندما يطلب تطبيق بيانات الموقع الجغرافي أو النشاط البدني من خلال واجهة برمجة تطبيقات Android العادية أو آلية خاصة. وتشمل هذه البيانات على سبيل المثال لا الحصر:

  • الموقع الجغرافي للجهاز (مثل خط العرض وخط الطول)
  • المعلومات التي يمكن استخدامها لتحديد موقع الجهاز أو تقديره (مثل SSID أو BSSID أو رقم تعريف الخلية أو عمليات البحث عبر البلوتوث أو موقع الشبكة التي يتصل بها الجهاز)
  • النشاط البدني للمستخدم أو تصنيف النشاط البدني

على وجه التحديد، يجب أن تتضمّن عمليات تنفيذ الأجهزة ما يلي:

• [C-0-8] يجب الحصول على موافقة المستخدم للسماح لأحد التطبيقات بالوصول إلى بيانات الموقع الجغرافي أو النشاط البدني.
• [C-0-9] يجب منح إذن التشغيل للتطبيق الذي لديه إذن كافٍ فقط كما هو موضّح في حزمة تطوير البرامج (SDK). على سبيل المثال، يتطلّب TelephonyManager#getServiceState إذن android.permission.ACCESS_FINE_LOCATION).

يمكن وضع علامة "مقيّد" على الأذونات لتغيير سلوكها.

• [C-0-10] يجب عدم منح التطبيق الأذونات التي تحمل العلامة hardRestricted إلا في الحالات التالية:

  • ملف APK لأحد التطبيقات في قسم تطبيقات النظام
  • يمنح المستخدم دورًا مرتبطًا بأذونات hardRestricted لأحد التطبيقات.
  • يمنح برنامج التثبيت hardRestricted لأحد التطبيقات.
  • تم منح التطبيق الإذن hardRestricted على إصدار Android أقدم.

• [C-0-11] يجب أن تحصل التطبيقات التي لديها إذن softRestricted على إذن وصول محدود فقط، ويجب ألا تحصل على إذن وصول كامل إلا بعد إضافتها إلى قائمة مسموح بها كما هو موضّح في حزمة تطوير البرامج (SDK)، حيث يتم تحديد إذن الوصول الكامل والمحدود لكل إذن softRestricted (على سبيل المثال، WRITE_EXTERNAL_STORAGE وREAD_EXTERNAL_STORAGE).

إذا كانت عمليات تنفيذ الأجهزة تتضمّن تطبيقًا مثبَّتًا مسبقًا أو تريد السماح لتطبيقات تابعة لجهات خارجية بالوصول إلى إحصاءات الاستخدام، يجب أن تستوفي الشروط التالية:

• [SR] يُنصح بشدة بتوفير آلية يمكن للمستخدم الوصول إليها لمنح إذن الوصول إلى إحصاءات الاستخدام أو إبطاله استجابةً للغرض android.settings.ACTION_USAGE_ACCESS_SETTINGS للتطبيقات التي تصرّح باستخدام إذن android.permission.PACKAGE_USAGE_STATS.

إذا كانت عمليات تنفيذ الأجهزة تهدف إلى عدم السماح لأي تطبيقات، بما في ذلك التطبيقات المثبَّتة مسبقًا، بالوصول إلى إحصاءات الاستخدام، عليها اتّباع ما يلي:

• [C-1-1] يجب أن يظل هناك نشاط يعالج نمط intent android.settings.ACTION_USAGE_ACCESS_SETTINGS ولكن يجب تنفيذه كعملية لا تفعل شيئًا، أي أن يكون له سلوك مكافئ كما لو تم رفض وصول المستخدم.

‫9.2. المعرّف الفريد (UID) وعزل العمليات

عمليات تنفيذ الأجهزة:

• [C-0-1] يجب أن يتوافق الجهاز مع نموذج وضع الحماية لتطبيقات Android، حيث يتم تشغيل كل تطبيق بمعرّف مستخدم (UID) فريد بنظام Unix وفي عملية منفصلة.
• [C-0-2] يجب أن يتيح تشغيل تطبيقات متعددة باستخدام معرّف مستخدم Linux نفسه، شرط أن تكون التطبيقات موقَّعة ومصمَّمة بشكل صحيح، كما هو موضّح في مرجع الأمان والأذونات.

‫9.3. أذونات نظام الملفات

عمليات تنفيذ الأجهزة:

• [C-0-1] يجب أن يتوافق مع نموذج أذونات الوصول إلى الملفات في Android على النحو المحدّد في مرجع الأمان والأذونات.

‫9.4. بيئات التنفيذ البديلة

يجب أن تحافظ عمليات تنفيذ الأجهزة على اتساق نموذج الأمان والأذونات في Android، حتى إذا كانت تتضمّن بيئات وقت التشغيل التي تنفّذ التطبيقات باستخدام برامج أو تكنولوجيا أخرى غير "تنسيق Dalvik التنفيذي" أو الرمز البرمجي الأصلي. بعبارة أخرى:

• [C-0-1] يجب أن تكون أوقات التشغيل البديلة تطبيقات Android، وأن تلتزم بنموذج أمان Android العادي، كما هو موضّح في مكان آخر في القسم 9.

• [C-0-2] يجب عدم منح أوقات التشغيل البديلة إذن الوصول إلى الموارد المحمية بأذونات لم يتم طلبها في ملف AndroidManifest.xml لوقت التشغيل من خلال آلية <uses-permission>.

• [C-0-3] يجب ألا تسمح بيئات التشغيل البديلة للتطبيقات باستخدام الميزات المحمية بأذونات Android المحصورة على تطبيقات النظام.

• [C-0-4] يجب أن تلتزم أوقات التشغيل البديلة بنموذج وضع الحماية في Android، ويجب ألا تعيد التطبيقات المثبَّتة باستخدام وقت تشغيل بديل استخدام وضع الحماية لأي تطبيق آخر مثبَّت على الجهاز، إلا من خلال آليات Android العادية لمعرّف المستخدم المشترَك وشهادة التوقيع.

• [C-0-5] يجب ألا يتم تشغيل أوقات التشغيل البديلة مع الوصول إلى البيئات المعزولة الخاصة بتطبيقات Android الأخرى أو منحها أو الحصول على إذن الوصول إليها.

• [C-0-6] يجب ألا يتم تشغيل أوقات التشغيل البديلة مع أي امتيازات خاصة بالمستخدم المتميّز (الجذر) أو أي معرّف مستخدم آخر، أو منحها أو منحها لتطبيقات أخرى.

• [C-0-7] عند تضمين ملفات .apk لأوقات تشغيل بديلة في صورة نظام عمليات تنفيذ الأجهزة، يجب توقيعها باستخدام مفتاح مختلف عن المفتاح المستخدَم لتوقيع التطبيقات الأخرى المضمّنة في عمليات تنفيذ الأجهزة.

• ‫[C-0-8] عند تثبيت التطبيقات، يجب أن تحصل بيئات التشغيل البديلة على موافقة المستخدم على أذونات Android التي يستخدمها التطبيق.

• [C-0-9] عندما يحتاج تطبيق إلى استخدام أحد موارد الجهاز التي يتوفّر لها إذن Android مطابق (مثل الكاميرا ونظام تحديد المواقع العالمي (GPS) وما إلى ذلك)، يجب أن يُعلم وقت التشغيل البديل المستخدم بأنّ التطبيق سيتمكّن من الوصول إلى هذا المورد.

• ‫[C-0-10] عندما لا يسجّل وقت التشغيل إمكانات التطبيق بهذه الطريقة، يجب أن يدرج وقت التشغيل جميع الأذونات التي يملكها وقت التشغيل نفسه عند تثبيت أي تطبيق يستخدم وقت التشغيل هذا.

• يجب أن تثبِّت بيئات التشغيل البديلة التطبيقات من خلال PackageManager في مساحات معزولة منفصلة لنظام Android (معرّفات مستخدمي Linux وما إلى ذلك).

• قد توفّر أوقات التشغيل البديلة وضع حماية واحدًا لنظام Android تشترك فيه جميع التطبيقات التي تستخدم وقت التشغيل البديل.

‫9.5. إتاحة استخدام التطبيق لعدة مستخدمين

يتضمّن نظام التشغيل Android إمكانية استخدام عدة مستخدمين ويوفر إمكانية عزل المستخدمين بشكل كامل.

• يمكن أن تتيح عمليات تنفيذ الأجهزة ميزة "المستخدمون المتعدّدون"، ولكن لا يُنصح بذلك إذا كانت تستخدم وسائط قابلة للإزالة كمساحة تخزين خارجية أساسية.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن عدة مستخدمين، يجب أن:

• [C-1-1] يجب استيفاء المتطلبات التالية المتعلقة بالأجهزة التي يمكن أن يستخدمها عدة مستخدمين.
• [C-1-2] يجب أن يتم تنفيذ نموذج أمان متوافق مع نموذج أمان نظام Android الأساسي على النحو المحدّد في مستند مرجع الأمان والأذونات في واجهات برمجة التطبيقات لكل مستخدم.
• [C-1-3] يجب أن تتضمّن مساحة تخزين منفصلة ومعزولة للتطبيقات المشترَكة (المعروفة أيضًا باسم /sdcard) لكل نُسخة من المستخدم.
• [C-1-4] يجب التأكّد من أنّ التطبيقات التي يملكها مستخدم معيّن ويشغّلها لا يمكنها إدراج الملفات التي يملكها أي مستخدم آخر أو قراءتها أو الكتابة فيها، حتى إذا تم تخزين بيانات كلا المستخدمَين على وحدة تخزين أو نظام ملفات واحد.
• [C-1-5] يجب تشفير محتويات بطاقة SD عند تفعيل ميزة "استخدام عدة مستخدمين" باستخدام مفتاح مخزَّن فقط على وسائط غير قابلة للإزالة ولا يمكن الوصول إليها إلا من خلال النظام، وذلك في حال كانت عمليات تنفيذ الأجهزة تستخدم وسائط قابلة للإزالة لواجهات برمجة التطبيقات الخاصة بوحدة التخزين الخارجية. وبما أنّ ذلك سيجعل الوسائط غير قابلة للقراءة بواسطة الكمبيوتر المضيف، يجب أن تتضمّن عمليات تنفيذ الأجهزة إمكانية التبديل إلى بروتوكول نقل الوسائط (MTP) أو نظام مشابه لتزويد أجهزة الكمبيوتر المضيفة بإمكانية الوصول إلى بيانات المستخدم الحالي.

‫9.6. تحذير بشأن الرسائل القصيرة برسوم إضافية

يتضمّن Android ميزة تحذير المستخدمين من أي رسالة SMS غير مجانية صادرة. رسائل SMS للخدمات هي رسائل نصية يتم إرسالها إلى خدمة مسجّلة لدى مشغّل شبكة جوّال وقد يتم تحصيل رسوم من المستخدم مقابلها.

في حال إعلان عمليات تنفيذ الأجهزة عن إتاحة android.hardware.telephony، يجب أن تستوفي ما يلي:

• [C-1-1] يجب تحذير المستخدمين قبل إرسال رسالة SMS إلى أرقام تم تحديدها باستخدام تعبيرات عادية محددة في ملف /data/misc/sms/codes.xml على الجهاز. يوفر "مشروع Android المفتوح المصدر" (AOSP) إصدارًا يستوفي هذا الشرط.

‫9.7. ميزات الأمان

يجب أن تضمن عمليات تنفيذ الأجهزة الامتثال لميزات الأمان في كلّ من النواة والنظام الأساسي على النحو الموضّح أدناه.

يتضمّن وضع الحماية في Android ميزات تستخدم نظام التحكّم الإلزامي في الوصول (MAC) المستند إلى Security-Enhanced Linux (SELinux)، ووضع الحماية seccomp، وميزات أمان أخرى في نواة Linux. عمليات تنفيذ الأجهزة:

• [C-0-1] يجب الحفاظ على التوافق مع التطبيقات الحالية، حتى عند تنفيذ SELinux أو أي ميزات أمان أخرى أسفل إطار عمل Android.
• [C-0-2] يجب ألا تتضمّن واجهة مستخدم مرئية عند رصد انتهاك أمني وحظره بنجاح من خلال ميزة الأمان المُنفَّذة أسفل إطار عمل Android، ولكن يجوز أن تتضمّن واجهة مستخدم مرئية عند حدوث انتهاك أمني لم يتم حظره وأدّى إلى استغلال ناجح.
• [C-0-3] يجب عدم السماح للمستخدم أو مطوّر التطبيق بضبط SELinux أو أي ميزات أمان أخرى تم تنفيذها أسفل إطار عمل Android.
• [C-0-4] يجب ألا يسمح بتطبيق يمكنه التأثير في تطبيق آخر من خلال واجهة برمجة تطبيقات (مثل Device Administration API) بضبط سياسة تؤدي إلى عدم التوافق.
• [C-0-5] يجب تقسيم إطار عمل الوسائط إلى عمليات متعددة حتى يمكن منح إذن الوصول لكل عملية بشكل أكثر تحديدًا كما هو موضّح في موقع "مشروع Android المفتوح المصدر".
• [C-0-6] يجب تنفيذ آلية حماية التطبيقات في النواة والتي تسمح بفلترة طلبات النظام باستخدام سياسة قابلة للضبط من البرامج المتعددة مؤشرات الترابط. يستوفي مشروع Android مفتوح المصدر هذا الشرط من خلال تفعيل seccomp-BPF مع مزامنة مجموعة سلاسل العمليات (TSYNC) كما هو موضّح في قسم "إعدادات النواة" من source.android.com.

تُعد ميزات سلامة النواة والحماية الذاتية جزءًا لا يتجزأ من أمان Android. عمليات تنفيذ الأجهزة:

• [C-0-7] يجب تنفيذ آليات الحماية من تجاوز المخزن المؤقت لحزمة kernel. من الأمثلة على هذه الآليات CC_STACKPROTECTOR_REGULAR وCONFIG_CC_STACKPROTECTOR_STRONG.
• [C-0-8] يجب تنفيذ إجراءات حماية صارمة لذاكرة النواة، حيث يكون الرمز القابل للتنفيذ للقراءة فقط، والبيانات للقراءة فقط غير قابلة للتنفيذ وغير قابلة للكتابة، والبيانات القابلة للكتابة غير قابلة للتنفيذ (مثل CONFIG_DEBUG_RODATA أو CONFIG_STRICT_KERNEL_RWX).
• [C-0-9] يجب تنفيذ عملية التحقّق من حدود حجم العناصر الثابتة والديناميكية للنسخ بين مساحة المستخدم ومساحة النواة (مثل CONFIG_HARDENED_USERCOPY) على الأجهزة التي تم شحنها في الأصل بالمستوى 28 لواجهة برمجة التطبيقات أو مستوى أعلى.
• [C-0-10] يجب عدم تنفيذ ذاكرة مساحة المستخدم عند التنفيذ في وضع النواة (مثل PXN للأجهزة أو المحاكي عبر CONFIG_CPU_SW_DOMAIN_PAN أو CONFIG_ARM64_SW_TTBR0_PAN) على الأجهزة التي تم شحنها في الأصل بالمستوى 28 من واجهة برمجة التطبيقات أو أعلى.
• [C-0-11] يجب عدم قراءة أو كتابة ذاكرة مساحة المستخدم في النواة خارج واجهات برمجة التطبيقات العادية للوصول إلى usercopy (مثل PAN للأجهزة أو المحاكي من خلال CONFIG_CPU_SW_DOMAIN_PAN أو CONFIG_ARM64_SW_TTBR0_PAN) على الأجهزة التي تم شحنها في الأصل بالمستوى 28 أو مستوى أحدث من واجهة برمجة التطبيقات.
• [C-0-12] يجب تنفيذ ميزة "عزل جداول صفحات النواة" إذا كان الجهاز عرضة للثغرة الأمنية CVE-2017-5754 على جميع الأجهزة التي تم شحنها في الأصل بالإصدار 28 من واجهة برمجة التطبيقات أو إصدار أحدث (مثل CONFIG_PAGE_TABLE_ISOLATION أو CONFIG_UNMAP_KERNEL_AT_EL0).
• [C-0-13] يجب تنفيذ إجراءات تقوية التخمين الفرعي إذا كان الجهاز معرَّضًا للثغرة الأمنية CVE-2017-5715 على جميع الأجهزة التي تم شحنها في الأصل بالإصدار 28 من واجهة برمجة التطبيقات أو إصدار أحدث (مثل CONFIG_HARDEN_BRANCH_PREDICTOR).
• [SR] يُنصح بشدة بإبقاء بيانات النواة التي تتم كتابتها أثناء عملية الإعداد فقط مع وضع علامة للقراءة فقط بعد عملية الإعداد (مثل __ro_after_init).

• [C-SR] يُنصح بشدة بتوزيع تخطيط رمز النواة والذاكرة بشكل عشوائي، وتجنُّب أي عمليات إفصاح قد تؤدي إلى اختراق التوزيع العشوائي (مثل CONFIG_RANDOMIZE_BASE مع إنتروبيا برنامج التحميل عبر /chosen/kaslr-seed Device Tree node أو EFI_RNG_PROTOCOL).

• [C-SR] يُنصح بشدة بتفعيل ميزة "سلامة تدفق التحكّم" (CFI) في النواة لتوفير حماية إضافية ضد هجمات إعادة استخدام الرموز (مثل CONFIG_CFI_CLANG وCONFIG_SHADOW_CALL_STACK).

• [C-SR] يُنصح بشدة بعدم إيقاف ميزة "سلامة تدفق التحكّم" (CFI) أو "مكدس استدعاء الظل" (SCS) أو "تنظيف تجاوز عدد صحيح" (IntSan) في المكوّنات التي تم تفعيلها فيها.
• [C-SR] يُنصح بشدة بتفعيل ميزات CFI وSCS وIntSan لأي مكونات إضافية لمساحة المستخدم حساسة للأمان، كما هو موضّح في CFI وIntSan.

إذا كانت عمليات تنفيذ الأجهزة تستخدم نواة Linux، يجب أن:

• [C-1-1] يجب تنفيذ SELinux.
• [C-1-2] يجب ضبط SELinux على وضع التنفيذ العام.
• [C-1-3] يجب ضبط جميع النطاقات في وضع التنفيذ. لا يُسمح بأي نطاقات في الوضع المتساهل، بما في ذلك النطاقات الخاصة بجهاز أو مورّد.
• [C-1-4] يجب عدم تعديل قواعد neverallow أو حذفها أو استبدالها، وهي القواعد المتوفّرة في مجلد system/sepolicy المقدَّم في "المشروع المفتوح المصدر لنظام Android" ‏ (AOSP) الأساسي، ويجب أن يتم تجميع السياسة مع جميع قواعد neverallow المتوفّرة، وذلك لكل من نطاقات SELinux في AOSP ونطاقات الأجهزة/المورّدين المحدّدة.
• ‫[C-1-5] يجب تشغيل تطبيقات الجهات الخارجية التي تستهدف مستوى واجهة برمجة التطبيقات 28 أو أعلى في بيئات الاختبار المعزولة SELinux لكل تطبيق مع فرض قيود SELinux على كل تطبيق على دليل البيانات الخاصة بكل تطبيق.
• يجب الاحتفاظ بسياسة SELinux التلقائية المتوفّرة في المجلد system/sepolicy في مشروع Android المفتوح المصدر الأساسي، وإضافة المزيد إلى هذه السياسة فقط لتوفير إعدادات خاصة بالجهاز.

إذا تم إطلاق عمليات تنفيذ الأجهزة على إصدار Android أقدم ولم تستوفِ المتطلبات [C-1-1] و[C-1-5] من خلال تحديث لبرامج النظام، يجوز إعفاؤها من هذه المتطلبات.

إذا كانت عمليات تنفيذ الأجهزة تستخدم نواة غير Linux، يجب أن:

• [C-2-1] يجب استخدام نظام تحكّم إلزامي في الوصول يكون مكافئًا لنظام SELinux.

يحتوي نظام التشغيل Android على ميزات متعددة للدفاع العميق تشكّل جزءًا لا يتجزأ من أمان الجهاز.

‫9.8. الخصوصية

‫9.8.1. سجلّ الاستخدام

يخزِّن نظام التشغيل Android سجلّ خيارات المستخدم ويدير هذا السجلّ من خلال UsageStatsManager.

عمليات تنفيذ الأجهزة:

• [C-0-1] يجب الحفاظ على فترة احتفاظ معقولة بسجلّ المستخدم هذا.
• [SR] يُنصح بشدة بالاحتفاظ بفترة الاحتفاظ بالبيانات لمدة 14 يومًا كما هو مضبوط تلقائيًا في تطبيق AOSP.

يخزِّن نظام التشغيل Android أحداث النظام باستخدام معرّفات StatsLog، ويدير هذا السجلّ من خلال واجهة برمجة التطبيقات StatsManager وIncidentManager.

عمليات تنفيذ الأجهزة:

• [C-0-2] يجب أن يتضمّن فقط الحقول التي تم وضع علامة DEST_AUTOMATIC عليها في تقرير الحدث الذي تم إنشاؤه بواسطة فئة System API IncidentManager.
• [C-0-3] يجب عدم استخدام معرّفات أحداث النظام لتسجيل أي حدث آخر غير ما هو موضح في مستندات حزمة تطوير البرامج (SDK) الخاصة بـ StatsLog. في حال تسجيل أحداث نظام إضافية، يمكن أن تستخدم معرّفًا مختلفًا للوحدة الأساسية في النطاق بين 100,000 و200,000.

‫9.8.2. يتم التسجيل

عمليات تنفيذ الأجهزة:

• [C-0-1] يجب عدم التحميل المُسبَق أو التوزيع خارج الصندوق لمكوّنات البرامج التي ترسل المعلومات الخاصة بالمستخدم (مثل ضغطات المفاتيح والنص المعروض على الشاشة وتقرير الأخطاء) إلى خارج الجهاز بدون موافقة المستخدم أو إشعارات مستمرة واضحة.

• [C-0-2] يجب عرض طلب موافقة صريح من المستخدم يتضمّن الرسالة نفسها تقريبًا التي يعرضها مشروع AOSP عند تفعيل ميزة مشاركة الشاشة أو تسجيلها من خلال MediaProjection أو واجهات برمجة التطبيقات الخاصة. يجب عدم توفير وسيلة للمستخدمين لإيقاف عرض الموافقة في المستقبل.

• [C-0-3] يجب عرض إشعار مستمر للمستخدم أثناء تفعيل ميزة "إرسال المحتوى إلى شاشة خارجية" أو "تسجيل الشاشة". يستوفي AOSP هذا الشرط من خلال عرض رمز إشعار مستمر في شريط الحالة.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن وظائف في النظام تعمل على تسجيل المحتوى المعروض على الشاشة و/أو تسجيل بث الصوت الذي يتم تشغيله على الجهاز بطريقة أخرى غير System API ContentCaptureService، أو وسائل أخرى خاصة موضّحة في الفقرة 9.8.6 تسجيل المحتوى، فإنّها:

• [C-1-1] يجب عرض إشعار مستمر للمستخدم كلما تم تفعيل هذه الوظيفة وبدأت في التسجيل أو الالتقاط بشكل نشط.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مكوّنًا مفعَّلاً فور إخراجه من العلبة، وقادرًا على تسجيل الصوت المحيط و/أو تسجيل الصوت الذي يتم تشغيله على الجهاز لاستنتاج معلومات مفيدة حول سياق المستخدم، يجب أن:

• [C-2-1] يجب عدم تخزين الصوت الخام المسجَّل أو أي تنسيق يمكن تحويله مرة أخرى إلى الصوت الأصلي أو نسخة طبق الأصل تقريبًا في وحدة تخزين دائمة على الجهاز أو إرساله خارج الجهاز، إلا بموافقة صريحة من المستخدم.

‫9.8.3. إمكانية الاتصال

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB متوافقًا مع وضع الأجهزة الطرفية USB، يجب أن تستوفي ما يلي:

• [C-1-1] يجب عرض واجهة مستخدم تطلب موافقة المستخدم قبل السماح بالوصول إلى محتوى وحدة التخزين المشتركة عبر منفذ USB.

‫9.8.4 حركة بيانات الشبكة

عمليات تنفيذ الأجهزة:

• [C-0-1] يجب أن يتم تثبيت شهادات الجذر نفسها مسبقًا في متجر مراجع التصديق (CA) الموثوق به في النظام كما هو موضّح في مشروع Android مفتوح المصدر.
• [C-0-2] يجب أن يتم شحن الجهاز مع متجر فارغ لشهادات المراجع المصدقة الجذرية الخاصة بالمستخدم.
• [C-0-3] يجب عرض تحذير للمستخدم يشير إلى أنّه قد تتم مراقبة عدد الزيارات على الشبكة، وذلك عند إضافة شهادة مرجعية أساسية للمستخدم.

إذا تم توجيه زيارات الجهاز من خلال شبكة VPN، ستكون عمليات تنفيذ الجهاز على النحو التالي:

• [C-1-1] يجب عرض تحذير للمستخدم يشير إلى أحد الخيارَين التاليَين:
  • وقد يتم تتبُّع حركة البيانات هذه.
  • يتم توجيه حركة بيانات الشبكة هذه من خلال تطبيق VPN المحدّد الذي يوفّر شبكة VPN.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن آلية مفعَّلة تلقائيًا عند إخراج الجهاز من العلبة، وتوجّه حركة بيانات الشبكة من خلال خادم وكيل أو بوابة شبكة VPN (على سبيل المثال، التحميل المُسبَق لخدمة VPN مع منح الإذن android.permission.CONTROL_VPN)، يجب أن تستوفي ما يلي:

• [C-2-1] يجب طلب موافقة المستخدم قبل تفعيل هذه الآلية، ما لم يتم تفعيل شبكة VPN من خلال "وحدة التحكّم في سياسة الجهاز" عبر DevicePolicyManager.setAlwaysOnVpnPackage()، وفي هذه الحالة لا يحتاج المستخدم إلى تقديم موافقة منفصلة، ولكن يجب إبلاغه فقط.

إذا كانت عمليات تنفيذ الأجهزة توفّر وسيلة تحكّم للمستخدم لتفعيل وظيفة "شبكة VPN قيد التفعيل دائمًا" في تطبيق شبكة VPN تابع لجهة خارجية، يجب أن تستوفي ما يلي:

• [C-3-1] يجب إيقاف إمكانية الوصول هذه للمستخدم في التطبيقات التي لا تتوافق مع خدمة "شبكة VPN دائمة التفعيل" في ملف AndroidManifest.xml من خلال ضبط السمة SERVICE_META_DATA_SUPPORTS_ALWAYS_ON على false.

‫9.8.5. معرّفات الأجهزة

عمليات تنفيذ الأجهزة:

• [C-0-1] يجب منع التطبيقات من الوصول إلى الرقم التسلسلي للجهاز، ورقم IMEI/MEID، والرقم التسلسلي لشريحة SIM، ومعرّف المشترك الدولي في خدمات الجوّال (IMSI)، حيثما ينطبق ذلك، ما لم يستوفِ أحد المتطلبات التالية:
  • هو تطبيق مشغّل شبكة جوّال موقَّع تم التحقّق منه من قِبل الشركات المصنّعة للأجهزة.
  • تم منح تطبيق "READ_PRIVILEGED_PHONE_STATE" إذن الوصول إلى
  • يتمتّع بامتيازات مشغّل شبكة الجوّال على النحو المحدّد في امتيازات مشغّل شبكة الجوّال في بطاقة UICC.
  • هو مالك جهاز أو مالك ملف شخصي تم منحه إذن READ_PHONE_STATE.
  • (لرقم تسلسلي لبطاقة SIM أو رقم ICCID فقط) يجب أن يلتزم باللوائح التنظيمية المحلية التي تتطلّب أن يرصد التطبيق التغييرات في هوية المشترك.

9.8.6. تسجيل المحتوى

يتيح نظام التشغيل Android، من خلال System API ContentCaptureService أو من خلال وسائل أخرى خاصة، آلية تتيح عمليات تنفيذ الأجهزة تسجيل التفاعلات التالية بين التطبيقات والمستخدم.

• النصوص والرسومات المعروضة على الشاشة، بما في ذلك على سبيل المثال لا الحصر، الإشعارات وبيانات المساعدة من خلال واجهة برمجة التطبيقات AssistStructure
• بيانات الوسائط، مثل الصوت أو الفيديو، التي يسجّلها الجهاز أو يشغّلها
• أحداث الإدخال (مثل المفاتيح والماوس والإيماءات والصوت والفيديو وتسهيل الاستخدام)
• أي أحداث أخرى يوفّرها التطبيق للنظام من خلال واجهة برمجة التطبيقات Content Capture أو واجهة برمجة تطبيقات مماثلة ومملوكة.

في حال جمع عمليات تنفيذ الأجهزة للبيانات المذكورة أعلاه، فإنّها:

• [C-1-1] يجب تشفير جميع هذه البيانات عند تخزينها في الجهاز. يمكن إجراء هذا التشفير باستخدام "التشفير المستند إلى الملفات" في Android أو أي من رموز التشفير المُدرَجة على أنّها الإصدار 26 من واجهة برمجة التطبيقات أو الإصدارات الأحدث كما هو موضّح في Cipher SDK.
• [C-1-2] يجب عدم الاحتفاظ بنسخة احتياطية من البيانات الأولية أو المشفرة باستخدام طُرق الاحتفاظ بنسخة احتياطية في Android أو أي طُرق أخرى للاحتفاظ بنسخة احتياطية.
• [C-1-3] يجب إرسال كل هذه البيانات وسجلّ الجهاز فقط باستخدام آلية تحافظ على الخصوصية. يتم تعريف آلية الحفاظ على الخصوصية بأنّها "الآليات التي تسمح بالتحليل المجمّع فقط وتمنع مطابقة الأحداث المسجّلة أو النتائج المشتقة مع المستخدمين الفرديين"، وذلك لمنع إمكانية فحص أي بيانات لكل مستخدم (على سبيل المثال، يتم تنفيذها باستخدام تكنولوجيا الخصوصية التفاضلية مثل RAPPOR).
• [C-1-4] يجب عدم ربط هذه البيانات بأي هوية مستخدم (مثل Account) على الجهاز، إلا بموافقة صريحة من المستخدم في كل مرة يتم فيها ربط البيانات.
• [C-1-5] يجب عدم مشاركة هذه البيانات مع تطبيقات أخرى، إلا بعد الحصول على موافقة صريحة من المستخدم في كل مرة تتم فيها المشاركة.
• [C-1-6] يجب توفير وسيلة للمستخدم لمحو هذه البيانات التي تجمعها ContentCaptureService أو الوسائل الخاصة إذا كانت البيانات مخزَّنة بأي شكل على الجهاز.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن خدمة تنفّذ System API ContentCaptureService، أو أي خدمة خاصة تجمع البيانات على النحو الموضّح أعلاه، فإنّها:

• [C-2-1] يجب ألا تسمح للمستخدمين باستبدال خدمة تسجيل المحتوى بتطبيق أو خدمة يمكن للمستخدم تثبيتها، ويجب ألا تسمح إلا للخدمة المثبَّتة مسبقًا بتسجيل هذه البيانات.
• [C-2-2] يجب ألا تسمح بأي تطبيقات أخرى غير آلية خدمة التقاط المحتوى المثبّتة مسبقًا بالتقاط هذه البيانات.
• [C-2-3] يجب توفير إمكانية للمستخدم لإيقاف خدمة تسجيل المحتوى.
• [C-2-4] يجب عدم إغفال توفير وسائل تحكّم للمستخدمين لإدارة أذونات Android التي تحتفظ بها خدمة التقاط المحتوى، ويجب اتّباع نموذج أذونات Android كما هو موضّح في الفقرة 9.1. الإذن

• [C-SR] يُنصح بشدة بإبقاء مكونات خدمة تسجيل المحتوى منفصلة، مثلاً عدم ربط الخدمة أو مشاركة أرقام تعريف العمليات، عن مكونات النظام الأخرى باستثناء ما يلي:

  • الاتصال الهاتفي وجهات الاتصال وواجهة مستخدم النظام والوسائط

9.8.7. الوصول إلى الحافظة

عمليات تنفيذ الأجهزة:

• [C-0-1] يجب ألا تعرض التطبيقات بيانات مقصوصة في الحافظة (مثل، من خلال واجهة برمجة التطبيقات ClipboardManager) ما لم يكن التطبيق هو طريقة الإدخال التلقائية أو التطبيق الذي يتم التركيز عليه حاليًا.

9.8.8. الموقع الجغرافي

عمليات تنفيذ الأجهزة:

• [C-0-1] يجب عدم تفعيل/إيقاف إعدادات الموقع الجغرافي للجهاز وإعدادات البحث عن شبكات Wi-Fi/أجهزة البلوتوث بدون موافقة صريحة من المستخدم أو بدون أن يبدأ المستخدم ذلك.
• [C-0-2] يجب توفير أداة تحكّم للمستخدم للوصول إلى المعلومات ذات الصلة بالموقع الجغرافي، بما في ذلك طلبات الموقع الجغرافي الأخيرة والأذونات على مستوى التطبيق واستخدام البحث عن شبكة Wi-Fi/أجهزة Bluetooth لتحديد الموقع الجغرافي.
• [C-0-3] يجب التأكّد من أنّ التطبيق الذي يستخدم واجهة برمجة التطبيقات Emergency Location Bypass API [LocationRequest.setLocationSettingsIgnored()] هو جلسة طوارئ بدأها المستخدم (مثل الاتصال بالرقم 911 أو إرسال رسالة نصية إلى الرقم 911).
• [C-0-4] يجب الحفاظ على قدرة واجهة برمجة التطبيقات Emergency Location Bypass API على تجاوز إعدادات الموقع الجغرافي للجهاز بدون تغيير الإعدادات.
• [C-0-5] يجب جدولة إشعار يذكّر المستخدم بعد أن يصل تطبيق في الخلفية إلى بيانات موقعه الجغرافي باستخدام إذن [ACCESS_BACKGROUND_LOCATION].

‫9.9. تشفير البيانات المخزَّنة

يجب أن تستوفي جميع الأجهزة متطلبات القسم 9.9.1. يُستثنى من متطلبات الأقسام 9.9.2 و9.9.3 الأجهزة التي تم إطلاقها بمستوى واجهة برمجة تطبيقات أقدم من المستوى المذكور في هذا المستند، ويجب بدلاً من ذلك أن تستوفي المتطلبات الواردة في القسم 9.9 من مستند "تعريف التوافق مع Android" الذي يتوافق مع مستوى واجهة برمجة التطبيقات الذي تم إطلاق الجهاز به.

‫9.9.1. التشغيل المباشر

عمليات تنفيذ الأجهزة:

• [C-0-1] يجب تنفيذ واجهات برمجة التطبيقات لوضع "التشغيل المباشر" حتى إذا كانت لا تتيح ميزة "تشفير وحدة التخزين".

• [C-0-2] يجب أن يستمر بث الغرضين ACTION_LOCKED_BOOT_COMPLETED وACTION_USER_UNLOCKED لإعلام التطبيقات المتوافقة مع ميزة "التشغيل المباشر" بأنّ مواقع التخزين المشفرة على الجهاز (DE) والمشفرة ببيانات الاعتماد (CE) متاحة للمستخدم.

‫9.9.2. متطلبات التشفير

عمليات تنفيذ الأجهزة:

• [C-0-1] يجب تشفير بيانات التطبيق الخاصّة (القسم /data)، بالإضافة إلى قسم مساحة التخزين المشتركة للتطبيق (القسم /sdcard) إذا كان جزءًا دائمًا وغير قابل للإزالة من الجهاز.
• [C-0-2] يجب تفعيل تشفير تخزين البيانات تلقائيًا عند اكتمال تجربة الإعداد خارج الصندوق.
• [C-0-3] يجب استيفاء متطلبات تشفير تخزين البيانات المذكورة أعلاه من خلال تنفيذ التشفير المستند إلى الملفات (FBE).

‫9.9.3. التشفير على مستوى الملفات

الأجهزة المشفَّرة:

• [C-1-1] يجب أن يتم التشغيل بدون مطالبة المستخدم بتقديم بيانات الاعتماد والسماح للتطبيقات المتوافقة مع ميزة "التشغيل المباشر" بالوصول إلى مساحة التخزين المشفرة على الجهاز (DE) بعد بث الرسالة ACTION_LOCKED_BOOT_COMPLETED.
• [C-1-2] يجب ألا يسمح بالوصول إلى مساحة التخزين المشفرة ببيانات الاعتماد (CE) إلا بعد أن يفتح المستخدم قفل الجهاز من خلال تقديم بيانات الاعتماد (مثل رمز المرور أو رقم التعريف الشخصي أو النمط أو بصمة الإصبع) ويتم بث الرسالة ACTION_USER_UNLOCKED.
• [C-1-3] يجب ألا يوفّر أي طريقة لفتح مساحة التخزين المحمية بواسطة CE بدون بيانات الاعتماد التي يقدّمها المستخدم أو مفتاح استرداد مسجّل.
• [C-1-4] يجب استخدام "التشغيل المتحقّق منه" والتأكّد من أنّ مفاتيح تشفير البيانات مرتبطة بالجهاز بشكل مشفّر من خلال أساس الثقة للأجهزة.
• [C-1-5] يجب تشفير محتوى الملفات باستخدام AES-256-XTS أو Adiantum. يشير AES-256-XTS إلى معيار التشفير المتقدّم الذي يبلغ طول مفتاح التشفير فيه 256 بت، ويتم تشغيله في وضع XTS، ويبلغ الطول الكامل للمفتاح 512 بت. يشير مصطلح "أديانتوم" إلى Adiantum-XChaCha12-AES، كما هو محدّد في https://github.com/google/adiantum.
• [C-1-6] يجب تشفير أسماء الملفات باستخدام AES-256-CBC-CTS أو Adiantum.

• [C-1-12] يجب استخدام AES-256-XTS لمحتوى الملفات وAES-256-CBC-CTS لأسماء الملفات (بدلاً من Adiantum) إذا كان الجهاز يتضمّن تعليمات معيار التشفير المتقدّم (AES). تعليمات AES هي "إضافات التشفير ARMv8" على الأجهزة المستندة إلى معالِج البيانات ARM، أو AES-NI على الأجهزة المستندة إلى معالِج البيانات x86. إذا لم يكن الجهاز مزوّدًا بتعليمات AES، يجوز له استخدام Adiantum.

• المفاتيح التي تحمي مساحات تخزين CE وDE:

• [C-1-7] يجب أن تكون مرتبطة بشكل مشفّر بـ Keystore مستند إلى الأجهزة.

• [C-1-8] يجب ربط مفاتيح CE ببيانات اعتماد شاشة قفل المستخدم.
• ‫[C-1-9] يجب ربط مفاتيح CE برمز مرور تلقائي عندما لا يحدّد المستخدم بيانات اعتماد شاشة القفل.
• [C-1-10] يجب أن تكون فريدة ومميّزة، أي ألا تتطابق مفاتيح تشفير المحتوى (CE) أو مفاتيح فك التشفير (DE) الخاصة بأي مستخدم مع مفاتيح تشفير المحتوى أو مفاتيح فك التشفير الخاصة بأي مستخدم آخر.
• [C-1-11] يجب استخدام عمليات التشفير وأطوال المفاتيح والأوضاع المتوافقة إلزاميًا.

• [C-SR] يُنصح بشدة بتشفير البيانات الوصفية لنظام الملفات، مثل أحجام الملفات والملكية والأوضاع والسمات الموسّعة (xattrs)، باستخدام مفتاح مرتبط تشفيرًا بجذر الثقة للأجهزة.

• يجب أن تكون التطبيقات الأساسية المثبَّتة مسبقًا (مثل "المنبّه" و"الهاتف" وMessenger) متوافقة مع ميزة "التشغيل المباشر".

يوفّر مشروع Android المفتوح المصدر الأساسي طريقة تنفيذ مفضّلة لهذه الميزة استنادًا إلى ميزة التشفير "fscrypt" في نواة Linux.

‫9.10. سلامة الجهاز

تضمن المتطلبات التالية توفُّر الشفافية بشأن حالة سلامة الجهاز. عمليات تنفيذ الأجهزة:

• [C-0-1] يجب أن يتم الإبلاغ بشكل صحيح من خلال طريقة System API PersistentDataBlockManager.getFlashLockState() عمّا إذا كانت حالة برنامج التشغيل الأوّلي تسمح بتثبيت صورة النظام. الحالة FLASH_LOCK_UNKNOWN مخصّصة لعمليات ترقية الأجهزة من إصدار سابق من Android لم يكن يتضمّن طريقة واجهة برمجة التطبيقات الجديدة هذه.

• [C-0-2] يجب أن يتوافق مع ميزة "التشغيل المتحقَّق منه" لضمان سلامة الجهاز.

إذا تم إطلاق عمليات تنفيذ الأجهزة بدون إتاحة ميزة "التشغيل المتحقّق منه" في إصدار سابق من Android ولا يمكن إضافة دعم لهذه الميزة من خلال تحديث برنامج النظام، يجوز إعفاؤها من هذا الشرط.

"التشغيل المتحقّق منه" هي ميزة تضمن سلامة برنامج الجهاز. إذا كانت عمليات تنفيذ الأجهزة تتيح هذه الميزة، فإنّها:

• [C-1-1] يجب الإفصاح عن علامة ميزة النظام الأساسي android.software.verified_boot.
• ‫[C-1-2] يجب إجراء عملية التحقّق في كل تسلسل تشغيل.
• [C-1-3] يجب بدء عملية التحقّق من مفتاح أمان ثابت غير قابل للتغيير يمثّل مصدر الثقة الأساسي، ثم الانتقال إلى قسم النظام.
• [C-1-4] يجب تنفيذ كل مرحلة من مراحل التحقّق للتأكّد من سلامة جميع وحدات البايت في المرحلة التالية وصحّتها قبل تنفيذ الرمز في المرحلة التالية.
• [C-1-5] يجب استخدام خوارزميات تحقّق بقوة التوصيات الحالية الصادرة عن المعهد الوطني للمعايير والتكنولوجيا (NIST) لخوارزميات التجزئة (SHA-256) وأحجام المفاتيح العامة (RSA-2048).
• [C-1-6] يجب عدم السماح بإكمال عملية التشغيل عند تعذُّر التحقّق من النظام، ما لم يوافق المستخدم على محاولة التشغيل على أي حال، وفي هذه الحالة يجب عدم استخدام البيانات من أي وحدات تخزين لم يتم التحقّق منها.
• [C-1-7] يجب ألا يسمح بتعديل الأقسام التي تم التحقّق منها على الجهاز ما لم يفتح المستخدم برنامج التشغيل بشكل صريح.
• [C-SR] إذا كانت هناك شرائح متعدّدة منفصلة في الجهاز (مثل الراديو ومعالج الصور المتخصّص)، يُنصح بشدة بأن تتحقّق عملية تشغيل كل شريحة من كل مرحلة عند التشغيل.
• [C-1-8] يجب استخدام مساحة تخزين مقاومة للتلاعب: لتخزين ما إذا كان برنامج الإقلاع غير مقفل. تعني مساحة التخزين المقاومة للتلاعب أنّه يمكن لبرنامج التحميل اكتشاف ما إذا تم التلاعب بمساحة التخزين من داخل نظام التشغيل Android.
• ‫[C-1-9] يجب أن يطلب الجهاز من المستخدم أثناء استخدامه تأكيدًا فعليًا قبل السماح بالانتقال من وضع قفل برنامج الإقلاع إلى وضع فتح قفل برنامج الإقلاع.
• ‫[C-1-10] يجب تنفيذ ميزة الحماية من الرجوع إلى إصدار أقدم للأقسام التي يستخدمها Android (مثل أقسام التشغيل والنظام) واستخدام مساحة تخزين مقاومة للتلاعب لتخزين البيانات الوصفية المستخدَمة لتحديد الحد الأدنى المسموح به من إصدار نظام التشغيل.
• [C-SR] يُنصح بشدة بالتحقّق من جميع ملفات APK للتطبيقات ذات الامتيازات باستخدام سلسلة ثقة مستندة إلى أقسام محمية من خلال ميزة "التمهيد المُتحقّق منه".
• [C-SR] يُنصح بشدة بالتحقّق من أي عناصر قابلة للتنفيذ يتم تحميلها بواسطة تطبيق ذي امتيازات من خارج ملف APK الخاص به (مثل الرمز الذي يتم تحميله ديناميكيًا أو الرمز المجمَّع) قبل تنفيذها أو يُنصح بشدة بعدم تنفيذها على الإطلاق.
• يجب تنفيذ ميزة الحماية من الرجوع إلى إصدار أقدم لأي مكوّن يتضمّن برامج ثابتة مستمرة (مثل المودم والكاميرا)، ويجب استخدام وحدة تخزين مقاومة للتلاعب لتخزين بيانات التعريف المستخدَمة في تحديد الحد الأدنى للإصدار المسموح به.

إذا تم إطلاق عمليات تنفيذ الأجهزة بدون دعم المتطلبات من C-1-8 إلى C-1-10 على إصدار سابق من Android ولا يمكن إضافة دعم لهذه المتطلبات من خلال تحديث برنامج النظام، يجوز إعفاؤها من المتطلبات.

يوفّر مشروع Android المفتوح المصدر في المصدر الرئيسي تنفيذًا مفضّلاً لهذه الميزة في مستودع external/avb/، ويمكن دمجه في برنامج التحميل المستخدَم لتحميل نظام التشغيل Android.

عمليات تنفيذ الأجهزة:

• [C-R] يُنصح بتوفير الدعم لواجهة برمجة التطبيقات Android Protected Confirmation API.

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع واجهة برمجة التطبيقات Android Protected Confirmation API، فإنّها:

• [C-3-1] يجب إرسال true إلى واجهة برمجة التطبيقات ConfirmationPrompt.isSupported().

• [C-3-2] يجب التأكّد من أنّ الرمز البرمجي الذي يتم تنفيذه في نظام التشغيل Android، بما في ذلك النواة، سواء كان ضارًا أو غير ذلك، لا يمكنه إنشاء استجابة إيجابية بدون تفاعل المستخدم.

• [C-3-3] يجب التأكّد من أنّ المستخدم تمكّن من مراجعة الرسالة التي تظهر له والموافقة عليها حتى في حال تعرُّض نظام التشغيل Android، بما في ذلك النواة، للاختراق.

‫9.11. المفاتيح وبيانات الاعتماد

يتيح نظام Android Keystore لمطوّري التطبيقات تخزين مفاتيح التشفير في حاوية واستخدامها في عمليات التشفير من خلال KeyChain API أو Keystore API. عمليات تنفيذ الأجهزة:

• [C-0-1] يجب السماح باستيراد أو إنشاء 8,192 مفتاحًا على الأقل.
• ‫[C-0-2] يجب أن يفرض نظام المصادقة على شاشة القفل حدًا أقصى لعدد المحاولات، ويجب أن يتضمّن خوارزمية التراجع الأسي. بعد 150 محاولة فاشلة، يجب أن يكون التأخير 24 ساعة على الأقل لكل محاولة.
• يجب ألا يفرض قيودًا على عدد المفاتيح التي يمكن إنشاؤها

عندما يتيح تنفيذ الجهاز استخدام شاشة قفل آمنة، يجب أن:

• [C-1-1] يجب أن يتم الاحتفاظ بنسخة احتياطية من تنفيذ ملف تخزين المفاتيح في بيئة تنفيذ معزولة.
• [C-1-2] يجب أن تتضمّن عمليات تنفيذ لخوارزميات التشفير RSA وAES وECDSA وHMAC ودوال التجزئة MD5 وSHA1 وSHA-2 لتوفير الدعم المناسب للخوارزميات المتوافقة مع نظام Android Keystore في منطقة معزولة بشكل آمن عن الرمز البرمجي الذي يتم تنفيذه على النواة والإصدارات الأحدث. يجب أن تحظر ميزة العزل الآمن جميع الآليات المحتملة التي يمكن من خلالها أن يصل رمز kernel أو رمز مساحة المستخدم إلى الحالة الداخلية للبيئة المعزولة، بما في ذلك الوصول المباشر إلى الذاكرة (DMA). يستوفي مشروع Android المفتوح المصدر (AOSP) هذا الشرط باستخدام تنفيذ Trusty، ولكن هناك خيارات بديلة أخرى، مثل حلّ آخر يستند إلى ARM TrustZone أو تنفيذ آمن راجعه طرف ثالث لعزل مناسب يستند إلى برنامج مراقبة الأجهزة الافتراضية.
• [C-1-3] يجب إجراء مصادقة شاشة القفل في بيئة التنفيذ المعزولة، ولا يُسمح باستخدام المفاتيح المرتبطة بالمصادقة إلا عند نجاحها. يجب تخزين بيانات اعتماد شاشة القفل بطريقة تسمح لبيئة التنفيذ المعزولة فقط بإجراء مصادقة شاشة القفل. يوفّر مشروع Android مفتوح المصدر طبقة تجريد الأجهزة (HAL) في Gatekeeper وTrusty، ويمكن استخدامهما لاستيفاء هذا الشرط.
• [C-1-4] يجب أن تتوافق مع مصادقة المفتاح حيث يكون مفتاح توقيع المصادقة محميًا بواسطة أجهزة آمنة ويتم التوقيع في أجهزة آمنة. يجب مشاركة مفاتيح توقيع شهادة التصديق على عدد كبير بما يكفي من الأجهزة لمنع استخدام المفاتيح كمعرّفات للأجهزة. إحدى طرق استيفاء هذا الشرط هي مشاركة مفتاح التصديق نفسه ما لم يتم إنتاج 100,000 وحدة على الأقل من رمز تخزين تعريفي معيّن. إذا تم إنتاج أكثر من 100,000 وحدة من رمز التخزين التعريفي، يمكن استخدام مفتاح مختلف لكل 100,000 وحدة.

يُرجى العِلم أنّه إذا تم إطلاق تطبيق على جهاز يعمل بإصدار Android أقدم، يكون هذا الجهاز معفيًا من شرط توفُّر مخزن مفاتيح يستند إلى بيئة تنفيذ معزولة وإتاحة إثبات صحة المفتاح، ما لم يعلن عن ميزة android.hardware.fingerprint التي تتطلّب مخزن مفاتيح يستند إلى بيئة تنفيذ معزولة.

• [C-1-5] يجب أن يسمح للمستخدم باختيار مهلة السكون للانتقال من حالة فتح القفل إلى حالة قفله، مع توفير مهلة دنيا تصل إلى 15 ثانية.

‫9.11.1. قفل الشاشة الآمن والمصادقة

يتّبع تنفيذ AOSP نموذج مصادقة متدرّجًا يمكن فيه دعم المصادقة الأساسية المستندة إلى عامل المعرفة إما من خلال مقاييس حيوية ثانوية قوية أو من خلال طُرق ثالثية أضعف.

عمليات تنفيذ الأجهزة:

• [C-SR] يُنصح بشدة بتحديد إحدى الطرق التالية فقط كطريقة مصادقة أساسية:
  • رقم تعريف شخصي
  • كلمة مرور أبجدية رقمية
  • نمط تمرير سريع على شبكة من 3 × 3 نقاط بالضبط

يُرجى العِلم أنّ طرق المصادقة المذكورة أعلاه يُشار إليها في هذا المستند على أنّها طرق المصادقة الأساسية المقترَحة.

إذا أضافت عمليات تنفيذ الأجهزة طرق المصادقة الأساسية المقترَحة أو عدّلتها واستخدمت طريقة مصادقة جديدة كوسيلة آمنة لقفل الشاشة، يجب أن تستوفي طريقة المصادقة الجديدة ما يلي:

• [C-2-1] يجب أن تكون طريقة مصادقة المستخدم على النحو الموضّح في اشتراط مصادقة المستخدم لاستخدام المفتاح.
• [C-2-2] يجب فتح جميع المفاتيح لتتمكّن تطبيقات المطوّرين الخارجيين من استخدامها عندما يفتح المستخدم قفل الشاشة الآمن. على سبيل المثال، يجب أن تكون جميع المفاتيح متاحة لتطبيق مطوّر تابع لجهة خارجية من خلال واجهات برمجة التطبيقات ذات الصلة، مثل createConfirmDeviceCredentialIntent وsetUserAuthenticationRequired.

إذا أضافت عمليات تنفيذ الأجهزة طرق المصادقة أو عدّلتها لفتح قفل الشاشة استنادًا إلى سر معروف واستخدمت طريقة مصادقة جديدة ليتم التعامل معها كطريقة آمنة لقفل الشاشة:

• ‫[C-3-1] يجب أن تكون إنتروبيا أقصر طول مسموح به للمدخلات أكبر من 10 بت.
• ‫[C-3-2] يجب أن يكون الحدّ الأقصى للإنتروبيا لجميع المدخلات الممكنة أكبر من 18 بت.
• [C-3-3] يجب ألا تحلّ طريقة المصادقة الجديدة محلّ أي من طرق المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) التي تم تنفيذها وتوفيرها في مشروع Android مفتوح المصدر (AOSP).
• [C-3-4] يجب إيقاف طريقة المصادقة الجديدة عندما يضبط تطبيق "وحدة التحكّم بسياسة الجهاز" (DPC) سياسة جودة كلمة المرور من خلال الطريقة DevicePolicyManager.setPasswordQuality() باستخدام ثابت جودة أكثر تقييدًا من PASSWORD_QUALITY_SOMETHING.
• [C-3-5] يجب أن تعود طرق المصادقة الجديدة إلى طرق المصادقة الأساسية المقترَحة (أي رقم التعريف الشخصي أو النمط أو كلمة المرور) مرة واحدة كل 72 ساعة أو أقل، أو أن توضّح للمستخدم أنّ بعض البيانات لن يتم الاحتفاظ بنسخة احتياطية منها للحفاظ على خصوصية بياناته.

إذا أضافت عمليات تنفيذ الأجهزة طرق المصادقة الأساسية المقترَحة أو عدّلتها لفتح قفل الشاشة واستخدام طريقة مصادقة جديدة تستند إلى المقاييس الحيوية ليتم التعامل معها كطريقة آمنة لقفل الشاشة، يجب أن تستوفي الطريقة الجديدة ما يلي:

• [C-4-1] يجب استيفاء جميع المتطلبات الموضّحة في الفقرة 7.3.10 بشأن الراحة.
• [C-4-2] يجب توفير آلية احتياطية لاستخدام إحدى طرق المصادقة الأساسية المقترَحة التي تستند إلى سر معروف.
• يجب إيقاف [C-4-3] وعدم السماح إلا بالمصادقة الأساسية الموصى بها لفتح الشاشة عندما يضبط تطبيق "وحدة التحكّم في سياسة الجهاز" (DPC) سياسة ميزة قفل الشاشة من خلال استدعاء الطريقة DevicePolicyManager.setKeyguardDisabledFeatures()، مع أي من علامات المقاييس الحيوية المرتبطة (أي KEYGUARD_DISABLE_BIOMETRICS أو KEYGUARD_DISABLE_FINGERPRINT أو KEYGUARD_DISABLE_FACE أو KEYGUARD_DISABLE_IRIS).

في حال عدم استيفاء طرق المصادقة بالمقاييس الحيوية لمتطلبات المصادقة القوية على النحو الموضّح في الفقرة 7.3.10:

• [C-5-1] يجب إيقاف الطرق إذا كان تطبيق "وحدة التحكّم بسياسة الجهاز" (DPC) قد ضبط سياسة جودة كلمة المرور من خلال الطريقة DevicePolicyManager.setPasswordQuality() باستخدام ثابت جودة أكثر تقييدًا من PASSWORD_QUALITY_BIOMETRIC_WEAK.
• ‫[C-5-2] يجب أن يُطلب من المستخدم إجراء المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) بعد أي فترة مهلة عدم نشاط تبلغ 4 ساعات. تتم إعادة ضبط مدة المهلة بعد أي تأكيد ناجح لبيانات اعتماد الجهاز.
• [C-5-3] يجب عدم التعامل مع الطرق على أنّها شاشة قفل آمنة، ويجب أن تستوفي المتطلبات التي تبدأ بـ C-8 في هذا القسم أدناه.

إذا أضافت عمليات تنفيذ الأجهزة طرق المصادقة أو عدّلتها لفتح شاشة القفل، وكانت طريقة المصادقة الجديدة تستند إلى رمز مميّز مادي أو الموقع الجغرافي:

• [C-6-1] يجب أن تتضمّن آلية احتياطية لاستخدام إحدى طرق المصادقة الأساسية المقترَحة المستندة إلى سر معروف، وأن تستوفي المتطلبات التي تؤهّلها لأن تُعتبَر شاشة قفل آمنة.
• [C-6-2] يجب إيقاف الطريقة الجديدة وعدم السماح إلا بإحدى طرق المصادقة الأساسية المقترَحة لفتح قفل الشاشة عندما يضبط تطبيق "وحدة التحكّم في سياسة الجهاز" السياسة باستخدام الطريقة DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) أو الطريقة DevicePolicyManager.setPasswordQuality() مع ثابت جودة أكثر تقييدًا من PASSWORD_QUALITY_UNSPECIFIED.
• [C-6-3] يجب أن يُطلب من المستخدم إدخال إحدى طرق المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) مرة واحدة على الأقل كل 4 ساعات أو أقل.
• [C-6-4] يجب ألا يتم التعامل مع الطريقة الجديدة على أنّها شاشة قفل آمنة، ويجب أن تلتزم بالقيود الواردة في القسم C-8 أدناه.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة قفل آمنة وتشمل وكيل ثقة واحدًا أو أكثر، والذي ينفّذ TrustAgentService System API، فإنّها:

• [C-7-1] يجب أن يتضمّن الجهاز إشارة واضحة في قائمة الإعدادات وعلى شاشة القفل عند تأجيل قفل الجهاز أو إبقائه مفتوحًا من خلال عوامل الثقة. على سبيل المثال، يستوفي AOSP هذا الشرط من خلال عرض وصف نصي للإعدادَين "القفل التلقائي" و "القفل الفوري باستخدام زر التشغيل" في قائمة الإعدادات، بالإضافة إلى رمز مميّز على شاشة القفل.
• [C-7-2] يجب احترام جميع واجهات برمجة التطبيقات الخاصة بوكيل الثقة وتنفيذها بالكامل في الفئة DevicePolicyManager، مثل الثابت KEYGUARD_DISABLE_TRUST_AGENTS.
• [C-7-3] يجب عدم تنفيذ وظيفة TrustAgentService.addEscrowToken() بالكامل على جهاز يُستخدم كجهاز شخصي أساسي (مثل جهاز محمول باليد)، ولكن يجوز تنفيذ الوظيفة بالكامل على عمليات تنفيذ الأجهزة التي تتم مشاركتها عادةً (مثل Android Television أو جهاز Automotive).
• [C-7-4] يجب تشفير جميع الرموز المميّزة المخزّنة التي أضافتها TrustAgentService.addEscrowToken().
• [C-7-5] يجب عدم تخزين مفتاح التشفير أو رمز الأمان على الجهاز نفسه الذي يتم فيه استخدام المفتاح. على سبيل المثال، يُسمح باستخدام مفتاح مخزّن على هاتف لفتح حساب مستخدم على تلفزيون.
• [C-7-6] يجب إبلاغ المستخدم بالآثار الأمنية قبل تفعيل الرمز المميز للوصول الاحتياطي من أجل فك تشفير وحدة تخزين البيانات.
• [C-7-7] يجب توفير آلية احتياطية لاستخدام إحدى طرق المصادقة الأساسية المقترَحة.
• [C-7-8] يجب أن يُطلب من المستخدم إكمال إحدى طرق المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) مرة واحدة على الأقل كل 72 ساعة أو أقل، ما لم تكن سلامة المستخدم (مثل تشتيت انتباه السائق) مصدر قلق.
• [C-7-9] يجب أن يُطلب من المستخدم إدخال إحدى طرق المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النمط أو كلمة المرور) بعد أي فترة مهلة لعدم النشاط تبلغ 4 ساعات، ما لم تكن سلامة المستخدم (مثل تشتيت انتباه السائق) مصدر قلق. تتم إعادة ضبط مدة المهلة بعد أي تأكيد ناجح لبيانات اعتماد الجهاز.
• [C-7-10] يجب ألا يتم التعامل معه على أنّه شاشة قفل آمنة، ويجب أن يلتزم بالقيود الواردة في الفقرة C-8 أدناه.
• [C-7-11] يجب عدم السماح لخدمات TrustAgent على الأجهزة الشخصية الأساسية (مثل الأجهزة المحمولة) بفتح قفل الجهاز، ولا يمكن استخدامها إلا لإبقاء الجهاز الذي تم فتح قفله في حالة عدم القفل لمدة تصل إلى 4 ساعات كحد أقصى. يتوافق التنفيذ التلقائي لواجهة TrustManagerService في AOSP مع هذا الشرط.
• ‫[C-7-12] يجب استخدام قناة اتصال آمنة من ناحية التشفير (مثل UKEY2) لتمرير رمز الأمان الاحتياطي من جهاز التخزين إلى الجهاز المستهدف.

إذا أضافت عمليات تنفيذ الأجهزة طرق مصادقة أو عدّلتها لفتح قفل الشاشة غير الآمنة كما هو موضّح أعلاه، واستخدمت طريقة مصادقة جديدة لفتح Keyguard، يجب استيفاء ما يلي:

• [C-8-1] يجب إيقاف الطريقة الجديدة عندما يضبط تطبيق "وحدة التحكّم بسياسة الجهاز" (DPC) سياسة جودة كلمة المرور من خلال الطريقة DevicePolicyManager.setPasswordQuality() باستخدام ثابت جودة أكثر تقييدًا من PASSWORD_QUALITY_UNSPECIFIED.
• [C-8-2] يجب ألا يعيدوا ضبط مؤقتات انتهاء صلاحية كلمات المرور التي تم ضبطها بواسطة DevicePolicyManager.setPasswordExpirationTimeout().
• [C-8-3] يجب ألا تعرض واجهة برمجة تطبيقات لتستخدمها التطبيقات التابعة لجهات خارجية من أجل تغيير حالة القفل.

‫9.11.2. StrongBox

يتيح نظام Android Keystore لمطوّري التطبيقات تخزين مفاتيح التشفير في معالج آمن مخصّص بالإضافة إلى بيئة التنفيذ المعزولة الموضّحة أعلاه. يُطلق على هذا المعالج الآمن المخصّص اسم "StrongBox". تحدّد المتطلبات من C-1-3 إلى C-1-11 أدناه المتطلبات التي يجب أن يستوفيها الجهاز ليكون مؤهلاً كجهاز StrongBox.

عمليات تنفيذ الأجهزة التي تتضمّن معالجًا آمنًا مخصّصًا:

• [C-SR] يُنصح بشدة بأن تتوافق مع StrongBox. من المحتمل أن يصبح استخدام StrongBox شرطًا في إصدار مستقبلي.

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع StrongBox، يجب أن تستوفي ما يلي:

• [C-1-1] يجب الإفصاح عن FEATURE_STRONGBOX_KEYSTORE.

• [C-1-2] يجب توفير جهاز آمن مخصّص يُستخدم لإنشاء نسخة احتياطية من مخزن المفاتيح والمصادقة الآمنة للمستخدم. ويمكن استخدام الأجهزة المخصّصة الآمنة لأغراض أخرى أيضًا.

• [C-1-3] يجب أن تتضمّن وحدة معالجة مركزية منفصلة لا تشارك أي ذاكرة تخزين مؤقت أو ذاكرة وصول عشوائي ديناميكية (DRAM) أو معالجات مساعدة أو موارد أساسية أخرى مع معالج التطبيقات (AP).

• [C-1-4] يجب التأكّد من أنّ أي أجهزة طرفية تتم مشاركتها مع معالج التطبيقات لا يمكنها تغيير معالجة StrongBox بأي شكل من الأشكال، أو الحصول على أي معلومات من StrongBox. يجوز لموفّر التطبيق إيقاف إمكانية الوصول إلى StrongBox أو حظرها.

• [C-1-5] يجب أن يتضمّن الجهاز ساعة داخلية بدقة معقولة (‎±10%) لا يمكن لنقطة الوصول التلاعب بها.

• [C-1-6] يجب أن يتضمّن مولّد أرقام عشوائية حقيقية ينتج عنه ناتج موزّع بشكل منتظم ولا يمكن توقّعه.

• [C-1-7] يجب أن تكون مقاومة للتلاعب، بما في ذلك مقاومة الاختراق المادي والتشويش.

• [C-1-8] يجب أن تتوفّر فيها مقاومة القنوات الجانبية، بما في ذلك مقاومة تسريب المعلومات عبر القنوات الجانبية للطاقة والتوقيت والإشعاع الكهرومغناطيسي والإشعاع الحراري.

• ‫[C-1-9] يجب أن يتضمّن مساحة تخزين آمنة تضمن سرية المحتوى وسلامته وأصالته وتناسقه وحداثته. يجب ألا يكون التخزين قابلاً للقراءة أو التغيير، إلا على النحو المسموح به من خلال واجهات برمجة تطبيقات StrongBox.

• للتحقّق من صحة الامتثال للمتطلبات من [C-1-3] إلى [C-1-9]، يجب أن تتضمّن عمليات تنفيذ الأجهزة ما يلي:

  • [C-1-10] يجب أن يشمل الأجهزة التي تم اعتمادها وفقًا لملف حماية الدوائر المتكاملة الآمنة BSI-CC-PP-0084-2014 أو التي تم تقييمها من قِبل مختبر اختبار معتمد على المستوى الوطني يشتمل على تقييم الثغرات الأمنية ذات احتمالية الهجوم العالية وفقًا لتطبيق المعايير المشتركة لاحتمالية الهجوم على البطاقات الذكية.
  • [C-1-11] يجب أن يتضمّن البرامج الثابتة التي يتم تقييمها من قِبل مختبر اختبار معتمد على المستوى الوطني، مع دمج تقييم الثغرات الأمنية ذات الاحتمال العالي للهجوم وفقًا لمعايير التطبيق المشترك لاحتمال الهجوم على البطاقات الذكية.
  • [C-SR] يُنصح بشدة بتضمين الأجهزة التي يتم تقييمها باستخدام "هدف الأمان"، ومستوى ضمان التقييم (EAL) 5، مع تعزيزه بـ AVA_VAN.5. من المرجّح أن تصبح شهادة EAL 5 من المتطلبات في إصدار مستقبلي.

• يُنصح بشدة باستخدام [C-SR] لتوفير مقاومة لهجمات الموظفين من الداخل (IAR)، ما يعني أنّه لا يمكن لموظف من الداخل لديه إذن الوصول إلى مفاتيح توقيع البرامج الثابتة إنشاء برامج ثابتة تؤدي إلى تسريب أسرار StrongBox أو تجاوز متطلبات الأمان الوظيفية أو السماح بالوصول إلى بيانات المستخدمين الحسّاسة بأي طريقة أخرى. الطريقة المقترَحة لتنفيذ IAR هي السماح بتحديثات البرامج الثابتة فقط عند تقديم كلمة مرور المستخدم الأساسي من خلال IAuthSecret HAL.

‫9.12. حذف البيانات

جميع عمليات تنفيذ الأجهزة:

• [C-0-1] يجب توفير آلية للمستخدمين لإجراء "إعادة الضبط على الإعدادات الأصلية".
• [C-0-2] يجب حذف جميع البيانات من نظام ملفات بيانات المستخدمين.
• [C-0-3] يجب حذف البيانات بطريقة تستوفي معايير المجال ذات الصلة، مثل NIST SP800-88.
• [C-0-4] يجب أن يتم تشغيل عملية "إعادة ضبط بيانات المصنع" المذكورة أعلاه عند استدعاء واجهة برمجة التطبيقات DevicePolicyManager.wipeData() من خلال تطبيق "وحدة التحكّم بسياسة الجهاز" الخاص بالمستخدم الأساسي.
• يمكن أن يوفّر خيارًا سريعًا لمحو البيانات لا يؤدي إلا إلى محو البيانات منطقيًا.

‫9.13. وضع التشغيل الآمن

يوفر نظام التشغيل Android وضع "التشغيل الآمن" الذي يسمح للمستخدمين بالتشغيل في وضع لا يُسمح فيه إلا بتشغيل تطبيقات النظام المثبّتة مسبقًا ويتم إيقاف جميع تطبيقات الجهات الخارجية. يوفّر هذا الوضع، المعروف باسم "وضع التشغيل الآمن"، للمستخدم إمكانية إلغاء تثبيت التطبيقات التابعة لجهات خارجية التي قد تكون ضارة.

تتضمّن عمليات تنفيذ الأجهزة ما يلي:

• [SR] يُنصح بشدة بتفعيل "وضع التشغيل الآمن".

في حال تنفيذ الأجهزة "وضع التشغيل الآمن"، يجب أن تستوفي ما يلي:

• [C-1-1] يجب أن يوفّر للمستخدم خيارًا للدخول إلى "وضع التشغيل الآمن" بطريقة لا يمكن مقاطعتها من خلال التطبيقات الخارجية المثبَّتة على الجهاز، إلا عندما يكون التطبيق الخارجي هو "وحدة التحكّم في سياسة الجهاز" وتم ضبط العلامة UserManager.DISALLOW_SAFE_BOOT على القيمة "صحيح".

• [C-1-2] يجب أن يوفّر للمستخدم إمكانية إلغاء تثبيت أي تطبيقات تابعة لجهات خارجية في الوضع الآمن.

• يجب أن يوفّر للمستخدم خيارًا للدخول إلى "وضع التشغيل الآمن" من قائمة التشغيل باستخدام سير عمل يختلف عن سير عمل التشغيل العادي.

‫9.14. عزل أنظمة المركبات

من المتوقّع أن تتبادل أجهزة Android Automotive البيانات مع الأنظمة الفرعية المهمة في السيارة باستخدام طبقة تجريد الأجهزة (HAL) الخاصة بالمركبة لإرسال الرسائل وتلقّيها عبر شبكات المركبة، مثل ناقل CAN.

يمكن تأمين تبادل البيانات من خلال تنفيذ ميزات الأمان أسفل طبقات إطار عمل Android لمنع التفاعل الضار أو غير المقصود مع هذه الأنظمة الفرعية.

‫9.15. خطط الاشتراك

تشير "خطط الاشتراك" إلى تفاصيل خطة علاقة الفوترة التي يقدّمها مشغّل شبكة الجوّال من خلال SubscriptionManager.setSubscriptionPlans().

جميع عمليات تنفيذ الأجهزة:

• [C-0-1] يجب عرض خطط الاشتراك فقط في تطبيق مشغّل شبكة الجوّال الذي قدّمها في الأصل.
• [C-0-2] يجب عدم الاحتفاظ بنسخة احتياطية أو تحميل خطط الاشتراك عن بُعد.
• [C-0-3] يجب السماح فقط بعمليات الإلغاء، مثل SubscriptionManager.setSubscriptionOverrideCongested()، من تطبيق مشغّل شبكة الجوّال الذي يوفّر حاليًا خطط اشتراك صالحة.

10. اختبار توافق البرامج

يجب أن تجتاز عمليات تنفيذ الأجهزة جميع الاختبارات الموضّحة في هذا القسم. ومع ذلك، يُرجى العِلم أنّه لا توجد حزمة اختبار برامج شاملة تمامًا. لهذا السبب، يُنصح بشدة مصنّعي الأجهزة بإجراء أقل عدد ممكن من التغييرات على التنفيذ المرجعي والمفضّل لنظام Android المتاح من "مشروع Android المفتوح المصدر". سيؤدي ذلك إلى الحدّ من خطر حدوث أخطاء تؤدي إلى عدم التوافق وتتطلّب إعادة العمل وإجراء تحديثات محتملة على الجهاز.

10.1. مجموعة أدوات اختبار التوافق

عمليات تنفيذ الأجهزة:

• ‫[C-0-1] يجب اجتياز مجموعة أدوات اختبار التوافق (CTS) لنظام التشغيل Android المتوفّرة من "المشروع المفتوح المصدر لنظام Android"، وذلك باستخدام برنامج الشحن النهائي على الجهاز.

• [C-0-2] يجب ضمان التوافق في حالات الغموض في مجموعة اختبار التوافق (CTS) وفي أي عمليات إعادة تنفيذ لأجزاء من رمز المصدر المرجعي.

تم تصميم مجموعة اختبار التوافق ليتم تشغيلها على جهاز فعلي. وكما هو الحال مع أي برنامج، قد يحتوي اختبار CTS نفسه على أخطاء. سيتم إصدار مجموعة اختبار التوافق (CTS) بشكل مستقل عن "تعريف التوافق" هذا، وقد يتم إصدار عدة مراجعات من مجموعة اختبار التوافق (CTS) لنظام التشغيل Android 10.

عمليات تنفيذ الأجهزة:

• [C-0-3] يجب اجتياز أحدث إصدار من مجموعة اختبار التوافق (CTS) المتوفّر عند اكتمال برنامج الجهاز.

• يجب استخدام التنفيذ المرجعي في شجرة Android مفتوحة المصدر قدر الإمكان.

10.2. أداة التحقّق في مجموعة أدوات اختبار التوافق (CTS)

يتم تضمين أداة CTS Verifier في مجموعة اختبار التوافق، وهي مصمَّمة ليستخدمها مشغّل بشري لاختبار الوظائف التي لا يمكن اختبارها باستخدام نظام آلي، مثل الأداء السليم للكاميرا وأجهزة الاستشعار.

عمليات تنفيذ الأجهزة:

• [C-0-1] يجب تنفيذ جميع حالات الاختبار السارية في أداة التحقّق من توافق CTS بشكلٍ صحيح.

يحتوي CTS Verifier على اختبارات للعديد من أنواع الأجهزة، بما في ذلك بعض الأجهزة الاختيارية.

عمليات تنفيذ الأجهزة:

• [C-0-2] يجب اجتياز جميع الاختبارات للأجهزة التي تتضمّن أجهزة استشعار. على سبيل المثال، إذا كان الجهاز يتضمّن مقياس تسارع، يجب أن ينفّذ بشكل صحيح حالة اختبار مقياس التسارع في CTS Verifier.

يمكن تخطّي أو حذف حالات الاختبار للميزات التي تم تصنيفها على أنّها اختيارية في "مستند تعريف معايير التوافق".

• [C-0-2] يجب أن يتم تشغيل أداة CTS Verifier بشكل صحيح على كل جهاز وكل إصدار، كما هو موضّح أعلاه. ومع ذلك، بما أنّ العديد من الإصدارات متشابهة جدًا، لا يُتوقّع من مطوّري الأجهزة تشغيل أداة CTS Verifier صراحةً على الإصدارات التي تختلف فقط بطرق بسيطة. على وجه التحديد، يمكن أن تستغني عمليات تنفيذ الأجهزة التي تختلف عن عملية تنفيذ اجتازت اختبار CTS Verifier عن اختبار CTS Verifier، وذلك فقط من خلال مجموعة اللغات المضمّنة والعلامات التجارية وما إلى ذلك.

11. البرامج القابلة للتحديث

• [C-0-1] يجب أن تتضمّن عمليات تنفيذ الأجهزة آلية لاستبدال نظام التشغيل بالكامل. لا يلزم أن تنفّذ الآلية ترقيات "مباشرة"، أي قد تكون إعادة تشغيل الجهاز مطلوبة. يمكن استخدام أي طريقة، شرط أن تتمكّن من استبدال جميع البرامج المثبَّتة مسبقًا على الجهاز. على سبيل المثال، سيستوفي أيّ من الأساليب التالية هذا الشرط:

  • عمليات التنزيل "عبر الهواء" (OTA) مع التحديث بلا إنترنت من خلال إعادة التشغيل
  • التحديثات "المربوطة" عبر USB من جهاز كمبيوتر مضيف
  • التحديثات "بلا إنترنت" من خلال إعادة التشغيل والتحديث من ملف على وحدة تخزين قابلة للإزالة

• [C-0-2] يجب أن تتيح آلية التحديث المستخدَمة إجراء التحديثات بدون محو بيانات المستخدم. أي أنّ آلية التحديث يجب أن تحافظ على بيانات التطبيق الخاصة وبيانات التطبيق المشترَكة. يُرجى العِلم أنّ برنامج Android الأساسي يتضمّن آلية تحديث تستوفي هذا الشرط.

• [C-0-3] يجب توقيع التحديث بالكامل، ويجب أن تتحقّق آلية التحديث على الجهاز من التحديث والتوقيع باستخدام مفتاح عام مخزَّن على الجهاز.

• [C-SR] يُنصح بشدة باستخدام آلية التوقيع لتجزئة التحديث باستخدام SHA-256 والتحقّق من صحة التجزئة باستخدام المفتاح العام من خلال خوارزمية ECDSA NIST P-256.

إذا كانت عمليات تنفيذ الجهاز تتضمّن إمكانية الاتصال بشبكة بيانات غير محدودة، مثل 802.11 أو ملف تعريف شبكة المنطقة الشخصية (PAN) عبر البلوتوث، يجب أن تستوفي ما يلي:

• [C-1-1] يجب أن يتيح تنزيل تحديثات عبر الأثير (OTA) مع إمكانية التحديث بلا إنترنت من خلال إعادة التشغيل.

بالنسبة إلى عمليات تنفيذ الأجهزة التي يتم إطلاقها باستخدام الإصدار 6.0 من نظام التشغيل Android والإصدارات الأحدث، يجب أن تتيح آلية التحديث التحقّق من أنّ صورة النظام متطابقة تمامًا مع النتيجة المتوقّعة بعد إجراء تحديث عبر الأثير. إنّ تنفيذ تحديثات OTA المستندة إلى الحظر في "المشروع المفتوح المصدر لنظام Android"، والذي تمت إضافته منذ الإصدار 5.1 من نظام التشغيل Android، يستوفي هذا الشرط.

يجب أيضًا أن تتوافق عمليات تنفيذ الأجهزة مع تحديثات النظام من النوع أ/ب. ينفّذ AOSP هذه الميزة باستخدام طبقة تجريد الأجهزة (HAL) الخاصة بالتحكّم في عملية التشغيل.

إذا تم رصد خطأ في تنفيذ جهاز بعد طرحه ولكن خلال فترة صلاحية المنتج المعقولة التي يتم تحديدها بالتشاور مع "فريق توافق Android"، وكان هذا الخطأ يؤثر في توافق التطبيقات التابعة لجهات خارجية، سيتم اتّخاذ الإجراءات التالية:

• [C-2-1] على مطوّر الجهاز تصحيح الخطأ من خلال تحديث للبرنامج متاح ويمكن تطبيقه وفقًا للآلية الموضّحة للتو.

يتضمّن نظام التشغيل Android ميزات تسمح لتطبيق "مالك الجهاز" (في حال توفّره) بالتحكّم في تثبيت تحديثات النظام. إذا كان النظام الفرعي لتحديث النظام للأجهزة يعرض android.software.device_admin، يعني ذلك ما يلي:

• [C-3-1] يجب تنفيذ السلوك الموضّح في فئة SystemUpdatePolicy.

12. سجلّ التغييرات في المستند

للاطّلاع على ملخّص للتغييرات التي تم إجراؤها على "مستند تعريف معايير التوافق" في هذا الإصدار، يُرجى الاطّلاع على ما يلي:

• سجلّ التغيير في المستند

للاطّلاع على ملخّص التغييرات في أقسام الأفراد:

1. المقدّمة
2. أنواع الأجهزة
3. البرامج
4. تغليف التطبيق
5. الوسائط المتعددة
6. أدوات وخيارات المطوّرين
7. توافق الأجهزة
8. الأداء والطاقة
9. نموذج الأمان
10. اختبار توافق البرامج
11. البرامج القابلة للتحديث
12. سجلّ تغييرات المستند
13. التواصل معنا

‫12.1. نصائح حول عرض سجلّ التغييرات

يتم وضع علامات على التغييرات على النحو التالي:

• CDD
  تغييرات جوهرية في متطلبات التوافق

• المستندات
  تغييرات متعلقة بالتجميل أو الإنشاء

للحصول على أفضل عرض، أضِف مَعلمات عنوان URL pretty=full وno-merges إلى عناوين URL الخاصة بسجلّ التغيير.

13. التواصل معنا

يمكنك الانضمام إلى منتدى توافق Android وطرح أسئلة للحصول على توضيحات أو الإبلاغ عن أي مشاكل تعتقد أنّ المستند لا يغطيها.