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

1. مقدّمة

يوضِّح هذا المستند المتطلبات التي يجب استيفاؤها لتصبح الأجهزة متوافقة مع Android 10.

إنّ استخدام "يجب" و"يجب ألا" و"مطلوب" و"SHALL" و"SHALL NOT" و"ينبغي" و"يجب عدم" و"الاقتراح" و"أيار" و"اختياري" ينطبق على معيار IETF المحدَّد في RFC2119.

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

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

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

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

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

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

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

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

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

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

يتم تعيين معرّف الطلب لمتطلبات "يجب".

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

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

• رقم تعريف نوع الجهاز (يمكنك الاطّلاع على مزيد من المعلومات في 2. أنواع الأجهزة)
  • ج: الأساسية (المتطلبات التي يتم تطبيقها على أي عمليات تنفيذ لجهاز Android)
  • H: جهاز Android محمول
  • T: جهاز تلفزيون Android
  • A: تنفيذ نظام التشغيل Android Automotive
  • W: استخدام ساعة Android Watch
  • علامة التبويب: استخدام جهاز 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، أي في ظروف السماء المفتوحة بعد تحديد الموقع الجغرافي، بينما تكون السرعة مستقرة أو تتحرك بسرعة أقل من 0.2 متر في الثانية المربعة من التسارع، كافية لحساب الموقع في نطاق 20 مترًا، وأن تكون السرعة في نطاق 0.2 متر لكل ثانية - على الأقل.

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

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

عمليات تنفيذ الأجهزة المحمولة التي يمكن أن تُجري مكالمة صوتية وتحدّد أي قيمة أخرى غير 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] يجب أن يعرض "صحيح" مع ActivityManager.isLowRamDevice() عندما تتوفر مساحة أقل من 1 غيغابايت للذاكرة للنواة kernel ومساحة المستخدم.

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

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

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

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

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

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

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

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

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

• [7.6.1/H-8-1] يجب أن يكون حجم الذاكرة المتاحة للنواة وUserspace 1824 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم درجات دقة مخزن مؤقت للإطارات تصل إلى QUD (على سبيل المثال، 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 المفتوح" (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.

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

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

الوظيفة	عمليات التعيين	السياق	السُلوك
A	صفحة استخدام HID: 0x0C استخدام HID: 0x0CD مفتاح النواة: KEY_PLAYPAUSE مفتاح Android: KEYCODE_MEDIA_PLAY_PAUSE	تشغيل الوسائط	الإدخال: ضغطة قصيرة الإخراج: تشغيل أو إيقاف مؤقت
			الإدخال: اضغط مع الاستمرار الإخراج: تشغيل الطلب الصوتي عمليات الإرسال: android.speech.action.VOICE_SEARCH_HANDS_FREE في حال قفل الجهاز أو إطفاء شاشته. يتم إرسال android.speech.RecognizerIntent.ACTION_WEB_SEARCH في حال لم يتم إرسال الرسالة.
		مكالمة واردة	الإدخال: ضغطة قصيرة المخرج: قبول المكالمة
			الإدخال: اضغط مع الاستمرار الإخراج: رفض المكالمة
		مكالمة جارية	الإدخال: ضغطة قصيرة الناتج: إنهاء المكالمة
			الإدخال: اضغط مع الاستمرار الإخراج: كتم صوت الميكروفون أو إعادته
B	صفحة استخدام HID: 0x0C استخدام HID: 0x0E9 مفتاح النواة: KEY_VOLUMEUP مفتاح Android: VOLUME_UP	تشغيل الوسائط، مكالمة جارية	الإدخال: ضغطة قصيرة أو طويلة الإخراج: يؤدي إلى رفع مستوى صوت النظام أو سماعة الرأس.
C	صفحة استخدام HID: 0x0C استخدام HID: 0x0EA مفتاح النواة: KEY_VOLUMEDOWN مفتاح Android: VOLUME_DOWN	تشغيل الوسائط، مكالمة جارية	الإدخال: ضغطة قصيرة أو طويلة الإخراج: يُخفض مستوى صوت النظام أو سماعة الرأس
D	صفحة استخدام HID: 0x0C استخدام HID: 0x0CF مفتاح النواة: KEY_VOICECOMMAND مفتاح Android: KEYCODE_VOICE_ASSIST	الكل. يمكن أن تظهر في أي حالة.	الإدخال: ضغطة قصيرة أو طويلة الإخراج: تشغيل الطلب الصوتي

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

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

• [7.8.2.2/H-2-1] يجب بث Intent ACTION_HEADSET_PLUG مع "الميكروفون" مجموعة إضافية على 0.

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

• [7.8.2.2/H-3-1] يجب بث Intent ACTION_HEADSET_PLUG مع "الميكروفون" مجموعة إضافية على 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 في أقل من 1,000 ملي ثانية.

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] يُنصح بشدة بأن يتم استخدام مشغّل تطبيقات تلقائي يتيح تثبيت الاختصارات والتطبيقات المصغّرة وميزات الأدوات داخل التطبيق.
• [3.8.1/H-SR] يُنصَح بشدة بأن يتم استخدام مشغّل تطبيقات تلقائي يوفّر إمكانية الوصول السريع إلى الاختصارات الإضافية التي تقدّمها التطبيقات التابعة لجهات خارجية من خلال واجهة برمجة التطبيقات ShortcutManager.
• [3.8.1/H-SR] يُنصَح بشدة بتضمين تطبيق مشغّل تطبيقات تلقائي يعرض شارات لرموز التطبيقات.
• [3.8.2/H-SR] يُنصَح باستخدامها بشدة لإتاحة التطبيقات المصغّرة التابعة لجهات خارجية.
• [3.8.3/H-0-1] يجب أن يسمح للتطبيقات التابعة لجهات خارجية بإشعار المستخدمين بالأحداث المهمة من خلال فئات واجهة برمجة التطبيقات Notification وNotificationManager.
• [3.8.3/H-0-2] يجب أن يتوافق مع الإشعارات الغنية.
• [3.8.3/H-0-3] يجب أن تتوفر إشعارات التنبيه.
• يجب أن يحتوي [3.8.3/H-0-4] على مركز إشعارات، ما يوفّر للمستخدم إمكانية التحكم المباشر في الإشعارات (على سبيل المثال، الرد أو التأجيل أو الإزالة أو الحظر) من خلال عناصر ووظائف المستخدم مثل أزرار الإجراءات أو لوحة التحكم كما هو مُطبق في AOSP.
• [3.8.3/H-0-5] يجب عرض الخيارات المتوفرة من خلال RemoteInput.Builder setChoices() في مركز الإشعارات.
• [3.8.3/H-SR] يُنصح بشدة بعرض الخيار الأول المقدَّم من خلال RemoteInput.Builder setChoices() في مركز الإشعارات بدون تفاعل إضافي من المستخدم.
• [3.8.3/H-SR] يُنصح بشدة بعرض جميع الخيارات المتوفرة من خلال RemoteInput.Builder setChoices() في مركز الإشعارات عندما يوسّع المستخدم كل الإشعارات في مركز الإشعارات.
• [3.8.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] يُنصَح بشدة بتضمين محرك تقنية تحويل النص إلى كلام (TTS) الذي يتوافق مع اللغات المتاحة على الجهاز.
• [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 لقطات في الثانية، ويجب أن يقل عن 1 لقطة في الثانية.
• [8.1/H-0-2] وقت استجابة واجهة المستخدم: يجب أن تضمن عمليات تنفيذ الأجهزة حصول المستخدم على وقت استجابة سريع من خلال تمرير قائمة تضم 10 آلاف إدخال في القائمة على النحو المحدّد في "مجموعة اختبار التوافق مع Android" (CTS) في أقل من 36 ثانية.
• [8.1/H-0-3] تبديل المهام: عند تشغيل عدة تطبيقات، يجب أن تستغرق إعادة تشغيل تطبيق قيد التشغيل بعد تشغيله أقل من ثانية واحدة.

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

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

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

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

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

• يجب أن توفّر [8.4/H-0-1] ملفًا شخصيًا للطاقة لكل مكوّن يحدد قيمة الاستهلاك الحالية لكل مكوّن من مكونات الجهاز واستنزاف البطارية التقريبي الناتج عن المكوّنات بمرور الوقت كما هو موثّق في موقع "مشروع مفتوح المصدر لنظام Android".
• [8.4/H-0-2] يجب أن يتم الإبلاغ عن جميع قيم استهلاك الطاقة بالمللي أمبير في الساعة (mAh).
• [8.4/H-0-3] يجب أن يبلغ عن استهلاك طاقة وحدة المعالجة المركزية (CPU) حسب المعرّف الفريد لكل عملية. يلبي "المشروع المفتوح المصدر لنظام 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 في منطقة معزولة بشكل آمن عن الرمز الذي يعمل على النواة والإصدارات الأحدث. يجب أن تحظر ميزة العزل الآمن جميع الآليات المحتملة التي من خلالها قد يصل رمز النواة أو رمز مساحة المستخدم إلى الحالة الداخلية للبيئة المعزولة، بما في ذلك قانون الأسواق الرقمية. يفي "المشروع المفتوح المصدر لنظام Android" (AOSP) بهذا الشرط من خلال استخدام تنفيذ Trusty، إلا أنّ الخيارات البديلة المتاحة هي أحد الحلول الأخرى المستندة إلى ARM TrustZone أو إحدى الجهات الخارجية التي تمت مراجعتها وفقًا لعزلة مناسبة تستند إلى برنامج Hypervisor (مراقب الأجهزة الظاهرية).
• [9.11/H-0-4]* يجب أن ينفِّذ مصادقة شاشة القفل في بيئة التنفيذ المعزولة، ولا يسمح باستخدام المفاتيح المرتبطة بالمصادقة إلا عند نجاحه. يجب تخزين بيانات اعتماد شاشة القفل بطريقة تسمح فقط لبيئة التنفيذ المعزولة بإجراء مصادقة شاشة القفل. يوفّر "المشروع المفتوح المصدر لنظام Android" الرئيسي طبقة استخلاص أجهزة 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 لمستخدم واجهة الأوامر الذي يتوافق مع مستندات Perfetto.
  • [6.1/H-0-3]* يجب أن يقبل البرنامج الثنائي Perfetto كإدخال إعداد نموذج أوّلي يتوافق مع المخطط المحدّد في مستندات الأداء.
  • [6.1/H-0-4]* يجب أن يكتب البرنامج الثنائي Perfetto كتتبُّع بيانات أوّلي يتوافق مع المخطط المحدّد في مستندات الأداء.
  • يجب أن يوفّر [6.1/H-0-5]* من خلال برنامج Perfetto الثنائي على الأقل مصادر البيانات الموضّحة في مستندات Perfetto.

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

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

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

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

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

2.3.1. الأجهزة

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

• [7.2.2/T-0-1] يجب أن يتوافق مع D-pad.
• [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] يجب أن تكون قادرة على قياس تغييرات الاتجاه بما يصل إلى 1,000 درجة في الثانية.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [5.1/T-0-1] ملف MPEG-4 AAC الشخصي (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 لقطة في الثانية مع الملف الشخصي الأساسي
• [5.3.4/T-1-2] دقة عالية، 1080p بسرعة 60 لقطة في الثانية، باستخدام الملف الشخصي الرئيسي
• [5.3.4/T-1-3] دقة عالية، 1080p بسرعة 60 لقطة في الثانية مع المستوى 4.2 من جودة الملف الشخصي العالي

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

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

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

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

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

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

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

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

إذا كانت عمليات تنفيذ أجهزة التلفزيون لا تتيح فك ترميز المحتوى بدقة فائقة، ولكنّها تتوافق بدلاً من ذلك مع شاشة خارجية متصلة عبر 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 TV تتوافق مع شاشة القفل، سيتم إجراء ما يلي:

• [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] يُنصَح بشدة بتضمين محرك تحويل النص إلى كلام (T-SR) الذي يتوافق مع اللغات المتاحة على الجهاز.
• [3.11/T-1-1] يجب أن يتيح تثبيت محركات تحويل النص إلى كلام التابعة لجهات خارجية.

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

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

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

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

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

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

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

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

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

• [8.3/T-1-3] يجب أن يوفر المستخدم القدرة على عرض جميع التطبيقات المعفاة من وضعي توفير الطاقة في وضع الاستعداد للتطبيقات والقيلولة.

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

• يجب أن يوفّر [8.4/T-0-1] ملفًا شخصيًا للطاقة لكل مكوّن يحدّد قيمة الاستهلاك الحالية لكل مكوّن من مكونات الجهاز واستنزاف البطارية التقريبي الناتج عن المكوّنات بمرور الوقت كما هو موثّق في موقع "مشروع مفتوح المصدر لنظام Android".
• [8.4/T-0-2] يجب أن يتم الإبلاغ عن جميع قيم استهلاك الطاقة بالملي أمبير في الساعة (mAh).
• [8.4/T-0-3] يجب أن يبلغ عن استهلاك طاقة وحدة المعالجة المركزية (CPU) حسب المعرّف الفريد لكل عملية. يلبي "المشروع المفتوح المصدر لنظام 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 في منطقة معزولة بشكل آمن عن الرمز الذي يعمل على النواة والإصدارات الأحدث. يجب أن تحظر ميزة العزل الآمن جميع الآليات المحتملة التي من خلالها قد يصل رمز النواة أو رمز مساحة المستخدم إلى الحالة الداخلية للبيئة المعزولة، بما في ذلك قانون الأسواق الرقمية. يفي "المشروع المفتوح المصدر لنظام Android" (AOSP) بهذا الشرط من خلال استخدام تنفيذ Trusty، إلا أنّ الخيارات البديلة المتاحة هي أحد الحلول الأخرى المستندة إلى ARM TrustZone أو إحدى الجهات الخارجية التي تمت مراجعتها وفقًا لعزلة مناسبة تستند إلى برنامج Hypervisor (مراقب الأجهزة الظاهرية).
• [9.11/T-0-3] يجب أن ينفِّذ مصادقة شاشة القفل في بيئة التنفيذ المعزولة، ولا يسمح باستخدام المفاتيح المرتبطة بالمصادقة إلا عند نجاح هذا الإجراء. يجب تخزين بيانات اعتماد شاشة القفل بطريقة تسمح فقط لبيئة التنفيذ المعزولة بإجراء مصادقة شاشة القفل. يوفّر "المشروع المفتوح المصدر لنظام Android" الرئيسي طبقة استخلاص أجهزة 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 لعناصر التحكم لتمكين /إيقاف المستخدمين الآخرين من الوصول إلى المكالمات الصوتية والرسائل القصيرة SMS.

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

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

• Perfetto
  • [6.1/T-0-1] يجب أن تعرض برنامجًا ثنائيًا /system/bin/perfetto لمستخدم واجهة الأوامر الذي يتوافق مع مستندات الأداء.
  • [6.1/T-0-2] يجب أن يقبل البرنامج الثنائي Perfetto كإدخال إعداد نموذج أوّلي يتوافق مع المخطّط المحدّد في مستندات Perfetto.
  • [6.1/T-0-3] يجب أن يكتب البرنامج الثنائي للأداء كنتائج تتبُّع أوّلية يتوافق مع المخطّط المحدّد في مستندات الأداء.
  • يجب أن يوفّر [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] يُنصَح بشدة بتضمين مقياس تسارع ثلاثي المحاور.

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

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

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

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

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

• [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 (للغات التي يوفّرها محرّك تحويل النص إلى كلام) المثبَّت مسبقًا) أو تجاوزها.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5.1. الأجهزة

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

• [7.1.1.1/A-0-1] يجب أن تحتوي الأجهزة على شاشة لا يقل حجمها عن 6 بوصة (6 بوصة) على الأقل.

• [7.1.1.1/A-0-2] يجب أن يتضمن تنسيق حجم الشاشة 750 بكسل مستقل الكثافة x 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() مع الخريطة.

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

• [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] يُنصح بشدة بضبط نطاق قياس الجيروسكوب ليكون +/-250 بكسل في الثانية لزيادة درجة الدقة الممكنة إلى أقصى حد

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

• [7.4.3/A-0-1] يجب أن يتوافق مع Bluetooth ويجب أن يتوافق مع Bluetooth LE.

• [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] يُنصح بشدة بتوجيهها حتى يتوافق بُعد الكاميرا الطويل مع الأفق.
• [7.5/A-SR] يُنصح بشدة بأن تكون درجة الدقة 1.3 ميغابكسل على الأقل.
• يجب أن يحتوي الجهاز إما على جهاز ذي تركيز ثابت أو EDOF (عمق مجال ممتد).
• قد يتم تنفيذ التركيز التلقائي للجهاز أو التركيز التلقائي للبرامج في برنامج تشغيل الكاميرا.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [7.6.1/A-2-4] يجب أن يكون حجم الذاكرة المتاحة للنواة kernel وUserspace على الأقل 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 وكتم صوت إجراءات الإشعارات بدلاً من الإجراءات المقدمة من خلال Notification.Builder.addAction()
• [3.8.3.1/أ] يجب أن يحظر استخدام مهام الإدارة الغنية، مثل عناصر التحكم في القناة لكل إشعار. قد تستخدم خصائص واجهة المستخدم لكل تطبيق لتقليل عناصر التحكم.

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

• يجب أن يتضمّن [3.14/A-0-1] إطار عمل لواجهة المستخدم من أجل إتاحة استخدام التطبيقات التابعة لجهات خارجية باستخدام واجهات برمجة تطبيقات الوسائط كما هو موضّح في الفقرة 3.14.
• [3.14/A-0-2] يجب أن يسمح للمستخدم بالتفاعل بأمان مع تطبيقات الوسائط أثناء القيادة.
• [3.14/A-0-3] يجب أن يتيح إجراء CAR_INTENT_ACTION_MEDIA_TEMPLATE Intent ضمني مع إضافة 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/أ] قد نفرض قيودًا على طلبات التطبيق للحدّ من القدرة على تغيير الألوان خلف عناصر واجهة مستخدم النظام، وذلك لضمان ظهور هذه العناصر بوضوح في جميع الأوقات، على النحو الموضّح في WindowManager.LayoutParams#FLAG_TRANSLUCENT_STATUS وWindowManager.LayoutParams#FLAG_TRANSLUCENT_NAVIGATION.

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

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

• [8.2/A-0-1] يجب أن يبلغ عدد وحدات البايت التي تمت قراءتها وكتابتها في مساحة تخزين غير متغيّرة وفقًا للمعرّف الفريد لكل عملية، وبالتالي تتوفّر الإحصاءات للمطوّرين من خلال System API 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] يجب أن يبلغ عن استهلاك طاقة وحدة المعالجة المركزية (CPU) حسب المُعرّف الفريد لكل عملية. يلبي "المشروع المفتوح المصدر لنظام Android" المتطلّبات من خلال تنفيذ وحدة نواة uid_cputime.
• [8.4/A] يجب أن تُنسب إلى مكوّن الجهاز نفسه إذا لم تتمكن من إسناد استخدام طاقة مكوِّن الجهاز إلى أحد التطبيقات.
• [8.4/A-0-4] يجب أن يتيح استخدام الطاقة هذا من خلال أمر Shell 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 في منطقة معزولة بشكل آمن عن الرمز الذي يعمل على النواة والإصدارات الأحدث. يجب أن تحظر ميزة العزل الآمن جميع الآليات المحتملة التي من خلالها قد يصل رمز النواة أو رمز مساحة المستخدم إلى الحالة الداخلية للبيئة المعزولة، بما في ذلك قانون الأسواق الرقمية. يفي "المشروع المفتوح المصدر لنظام Android" (AOSP) بهذا الشرط من خلال استخدام تنفيذ Trusty، إلا أنّ الخيارات البديلة المتاحة هي أحد الحلول الأخرى المستندة إلى ARM TrustZone أو إحدى الجهات الخارجية التي تمت مراجعتها وفقًا لعزلة مناسبة تستند إلى برنامج Hypervisor (مراقب الأجهزة الظاهرية).
• [9.11/A-0-3] يجب أن ينفِّذ مصادقة شاشة القفل في بيئة التنفيذ المعزولة، ولا يسمح باستخدام المفاتيح المرتبطة بالمصادقة إلا عند نجاحها. يجب تخزين بيانات اعتماد شاشة القفل بطريقة تسمح فقط لبيئة التنفيذ المعزولة بإجراء مصادقة شاشة القفل. يوفّر "المشروع المفتوح المصدر لنظام Android" الرئيسي طبقة استخلاص أجهزة 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 لمستخدم واجهة الأوامر الذي يتوافق مع مستندات الأداء.
  • [6.1/A-0-2] يجب أن يقبل البرنامج الثنائي Perfetto كإدخال إعداد نموذج أوّلي يتوافق مع المخطّط المحدد في مستندات Perfetto.
  • [6.1/A-0-3] يجب أن يكتب البرنامج الثنائي للأداء كنتائج تتبُّع أوّلية يتوافق مع المخطّط المحدّد في مستندات الأداء.
  • يجب أن يوفّر [6.1/A-0-4] من خلال برنامج Perfetto الثنائي على الأقل مصادر البيانات الموضّحة في مستندات Perfetto.

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

يشير جهاز Android Tablet إلى عملية تنفيذ جهاز 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 المفتوح (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 لعناصر التحكّم لتمكين /إيقاف المستخدمين الآخرين من الوصول إلى المكالمات الصوتية والرسائل القصيرة SMS.

3- البرامج

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

بيئة تنفيذ رمز بايت Dalvik المُدار هي الأداة الأساسية لتطبيقات Android. واجهة برمجة تطبيقات Android (API) هي مجموعة واجهات نظام 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 والموجودة في مسار فئة التشغيل في AOSP والتي لا تشكِّل جزءًا من حزمة SDK العامة. ويشمل ذلك واجهات برمجة التطبيقات المزيّنة بالتعليق التوضيحي @hide ولكن ليس باستخدام @SystemAPI، كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) وأعضاء الفئة الخاصة والخاصة بالحزمة.

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

  ومع ذلك:

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

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

3.1.1. إضافات Android

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

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

3.1.2. مكتبة Android

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

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

إنّ عملية تنفيذ بروتوكول AOSP تستوفي هذه المتطلّبات.

3.2. التوافق مع Soft API

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

3.2.1. الأذونات

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

3.2.2. مَعلمات الإصدار

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

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

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

3.2.3. التوافق مع الأهداف

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

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

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

  • ساعة مكتب
  • المتصفح
  • التقويم
  • جهات اتصال Google
  • معرض الصور
  • البحث العالمي
  • قاذفة القنابل
  • الموسيقى
  • الإعدادات

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) للبيانات. على سبيل المثال، يكون نمط فلتر الأهداف الذي يحدد عنوان URI للبيانات "http://www.android.com" أكثر تحديدًا من نمط الهدف الأساسي للمتصفّح "http:// ".

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

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

3.2.3.3. مساحات أسماء الأهداف

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

3.2.3.4. نوايا البث

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

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

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

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

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

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

في حال أبلغت عمليات تنفيذ الأجهزة عن android.software.home_screen، سينطبق التالي على:

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

في حال أبلغت عمليات تنفيذ الأجهزة عن android.hardware.telephony، سينطبق التالي على:

• [C-2-1] يجب توفير قائمة إعدادات تطلب RoleManager.createRequestRoleIntent(String) intent مع 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() API.
• [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 للتطبيق كملف ELF .so الذي تم تجميعه من أجل بنية الأجهزة المناسبة. ونظرًا لاعتماد الرمز الأصلي بدرجة كبيرة على تكنولوجيا المعالج الأساسي، يُحدِّد Android عددًا من واجهات التطبيق الثنائية (ABI) في Android NDK.

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

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

• يجب استخدام المَعلمات أعلاه في [C-0-6] للإبلاغ عن مجموعة فرعية من قائمة واجهات التطبيق الثنائية (ABI) التالية ويجب ألا تُبلِغ عن أيّ واجهات تطبيقات ثنائية (ABI) غير مدرَجة في القائمة.

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

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

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

  • libamedi.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 (مكتبة الرياضيات)
  • libneralnetworks.so (واجهة برمجة التطبيقات للشبكات العصبية)
  • libOpenMAXAL.so (دعم OpenMAX AL 1.0.1)
  • libOpenSLES.so (دعم الصوت OpenSL ES 1.0.1)
  • libRS.so
  • libstdc++ (الحد الأدنى من التوافق مع C++)
  • libvulkan.so (Vulkan)
  • libz (ضغط Zlib)
  • واجهة JNI

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

• [C-0-9] يجب أن يُدرج المكتبات الإضافية التي لا تتبع AOSP والمعروضة مباشرةً لتطبيقات تابعة لجهات خارجية في /vendor/etc/public.libraries.txt.
• [C-0-10] يجب ألّا تعرض التطبيقات التابعة لجهات خارجية التي تستهدف المستوى 24 من واجهة برمجة التطبيقات أو مستوى أعلى أي مكتبات أصلية أخرى، تم تنفيذها وتقديمها في AOSP كمكتبات نظام، لأنّها محجوزة.
• [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 بت

في حال أبلغت عمليات تنفيذ الأجهزة عن توافق واجهة التطبيق الثنائية (ABI) مع armeabi، سيتم إجراء ما يلي:

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

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

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

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

• [C-2-2] يجب دائمًا توفير العمليات التالية، حتى في حال تنفيذ واجهة ABI على بنية ARMv8، سواء من خلال دعم وحدة المعالجة المركزية الأصلية أو من خلال محاكاة البرامج:

  • تعليمات محو بيانات المستخدم وميزة 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) متطابقة مع قيمة السمة android.os.Build.ID.
  • يجب أن تكون قيمة السلسلة $(CHROMIUM_VER) هي إصدار Chromium في مشروع Android مفتوح المصدر الرئيسي.
  • قد تحذف عمليات تنفيذ الأجهزة الأجهزة الجوّالة في سلسلة وكيل المستخدم.

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

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

يُرجى العلم أنّه إذا كانت عمليات تنفيذ الأجهزة بنظام 32 بت أو تشير إلى علامة الميزة android.hardware.ram.low، سيتم استثناءها من سياسة C-1-3.

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

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

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

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

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

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

3.5.1. قيود الخلفية

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• يجب أن يستخدم [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. وضع "عدم الإزعاج" (DND)

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

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

3.8.4 بحث

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

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

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

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

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

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

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

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

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

3.8.5 التنبيهات والإشعارات

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

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

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

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

3.8.6. المظاهر

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

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

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

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

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

• قد تؤدي عمليات تنفيذ الأجهزة إلى تعديل سمات المظهر التلقائي للجهاز التي تظهر للتطبيقات.

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

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

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

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

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

تُعتبر الأجهزة قادرة على تشغيل الخلفيات المتحركة بشكل موثوق إذا كان يمكنها تشغيل جميع الخلفيات المتحركة، بدون قيود على وظائفها، وبعدد معقول من اللقطات في الثانية وبدون تأثيرات سلبية في التطبيقات الأخرى. إذا تسبّبت القيود في الأجهزة في تعطُّل الخلفيات و/أو التطبيقات أو تعطُّل وظائفها أو استهلاكها بشكلٍ مفرط في وحدة المعالجة المركزية (CPU) أو طاقة البطارية أو تشغيلها بمعدّلات إطارات منخفضة بشكلٍ غير مقبول، سيُعتبر الجهاز غير قادر على تشغيل الخلفية المتحركة. كمثال على ذلك، قد تستخدم بعض الخلفيات المتحركة سياق 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 استخدام شاشات الاستراحة التفاعلية التي كانت يُشار إليها سابقًا باسم "أحلام". تسمح شاشات الاستراحة للمستخدمين بالتفاعل مع التطبيقات عندما يكون أحد الأجهزة المتصلة بمصدر طاقة غير نشِط لفترة قصيرة أو مثبَّتًا على قاعدة إرساء سطح المكتب. يمكن أن تستخدم أجهزة 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-blue، sans-serif-condensed"، sans-serif-condensed-light للغات المتاحة على الجهاز.
  • تغطية Unicode 7.0 كاملة للّغات اللاتينية واليونانية والسيريلية، بما في ذلك النطاقات اللاتينية الموسَّعة A وB وC وD، وجميع الرموز الرسومية في كتلة رموز العملات في Unicode 7.0.
• يجب أن تكون متوافقة مع درجة لون البشرة والرموز التعبيرية المتنوعة المناسبة للعائلات على النحو المحدّد في تقرير Unicode الفني رقم 51.

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

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

يتيح نظام 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 كما هو موضّح في حزمة تطوير البرامج (SDK) هذه.
• [C-1-3] يجب ألا يتم توفير وضع تقسيم الشاشة أو الشكل الحر إذا كان ارتفاع الشاشة أقل من 440 وحدة بكسل مستقلة الكثافة (dp) وكان عرض الشاشة أقل من 440 وحدة بكسل مستقلة الكثافة (dp).
• [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() API.
• يجب أن يتوافق [C-3-3] مع نِسب عرض إلى ارتفاع أكبر من أو تساوي 1:2.39 وأقل من أو تساوي 2.39:1، على النحو المحدّد في نشاط نافذة ضمن النافذة (PIP) من خلال واجهة برمجة تطبيقات setAspectRatio().
• [C-3-4] يجب استخدام KeyEvent.KEYCODE_WINDOW للتحكم في نافذة نافذة ضمن النافذة (PIP). في حال عدم تنفيذ وضع "نافذة ضمن النافذة"، يجب أن يكون المفتاح متاحًا للنشاط الذي تعمل في المقدّمة.
• [C-3-5] يجب أن تتوفر للمستخدم إمكانية حظر عرض التطبيق في وضع PIP. استيفاء تنفيذ AOSP هذا المطلب من خلال وجود عناصر تحكم في مركز الإشعارات.
• [C-3-6] يجب تخصيص حد أدنى للعرض والارتفاع يبلغ 108 بكسل مستقل الكثافة (dp) للنافذة ضمن النافذة (PIP) والحد الأدنى للعرض وهو 240 بكسل مستقل الكثافة (dp) وارتفاع يبلغ 135 بكسل مستقل الكثافة (dp) للنافذة ضمن النافذة عندما يتم ضبط السمة 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] يجب أن يتيح تسجيل برنامج Device Policy (DPC) باعتباره تطبيق مالك الجهاز كما هو موضح أدناه:
  • في حال عدم ضبط بيانات المستخدمين في عملية تنفيذ الجهاز إلى الآن، سيحدث ما يلي:
    • [C-1-3] يجب الإبلاغ عن true للموقع الإلكتروني DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-4] يجب تسجيل تطبيق وحدة التحكّم بسياسة الجهاز (DPC) كتطبيق مالك الجهاز استجابةً للإجراء المطلوب android.app.action.PROVISION_MANAGED_DEVICE.
    • [C-1-5] يجب تسجيل تطبيق وحدة التحكّم بسياسة الجهاز (DPC) كتطبيق مالك الجهاز إذا أعلن الجهاز عن توفّر ميزة "الاتصالات القريبة المدى" (NFC) من خلال علامة الميزة android.hardware.nfc وتلقّى رسالة NFC تتضمّن سجلّاً من نوع MIME MIME_TYPE_PROVISIONING_NFC.
  • عندما تحتوي عملية تنفيذ الجهاز على بيانات مستخدمين، فإنها:
    • [C-1-6] يجب الإبلاغ عن false في DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-7] يجب ألا يتم بعد الآن تسجيل أي تطبيق لوحدة التحكّم بسياسة الجهاز (DPC) كتطبيق مالك الجهاز.
• [C-1-2] يجب اتخاذ إجراء تأكيدي أثناء عملية توفير المتطلبات اللازمة للموافقة على ضبط التطبيق كمالك للجهاز. ويمكن أن تكون الموافقة من خلال إجراء المستخدم أو من خلال وسائل آلية أثناء توفير المتطلبات اللازمة، ولكن يجب ألا يتم تشفيرها بشكل نهائي أو منع استخدام تطبيقات "مالك الجهاز" الأخرى.

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

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

3.9.1.2 توفير المتطلبات اللازمة للملف الشخصي المُدار

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

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

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

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

  • يشير ذلك المصطلح إلى رمز متّسق أو غير ذلك من بيانات المستخدم (مثل رمز معلومات AOSP الأولية) لتوضيح الحالات التي يقيّد فيها مشرف الجهاز إعدادًا معيّنًا.
  • رسالة توضيحية موجزة يقدِّمها مشرف الجهاز من خلال setShortSupportMessage.
  • رمز تطبيق وحدة التحكّم بسياسة الجهاز (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] رمز إشعار (على غرار شارة العمل الأولية الخاصة ببرنامج AOSP) للإشارة إلى الوقت الذي يكون فيه المستخدم ضمن تطبيق ملف شخصي مُدار.
• [C-1-5] يجب عرض إشعار منبثق يشير إلى أنّ المستخدم ضمن الملف الشخصي المُدار في حال استيقاظ الجهاز (ACTION_USER_PRESENT) ووقت تنشيطه (ACTION_USER_PRESENT) وكان التطبيق الذي يعمل في المقدّمة ضمن الملف الشخصي المُدار.
• [C-1-6] عند وجود ملف شخصي مُدار، يجب أن يُظهر عنصر قوة مرئي في "أداة اختيار الأهداف" للسماح للمستخدم بإعادة توجيه النية من الملف الشخصي المُدار إلى المستخدم الأساسي أو العكس، إذا فعّلتها "وحدة التحكّم بسياسة الجهاز".
• [C-1-7] عند وجود ملف شخصي مُدار، يجب أن يعرض الخصائص التالية للمستخدم لكل من المستخدم الأساسي والملف الشخصي المُدار:
  • فصل المستخدم الأساسي عن بيانات البطارية والموقع الجغرافي وبيانات الجوّال واستخدام مساحة التخزين، بالإضافة إلى حساب المستخدم الأساسي والملف الشخصي المُدار
  • الإدارة المستقلة لتطبيقات الشبكة الافتراضية الخاصة المثبَّتة ضمن المستخدم الأساسي أو الملف الشخصي المُدار
  • إدارة مستقلة للتطبيقات المثبّتة ضمن المستخدم الأساسي أو الملف الشخصي المُدار
  • إدارة مستقلة للحسابات ضمن الملف الشخصي المُدار أو المستخدم الأساسي.
• [C-1-8] يجب التأكّد من أنّ برامج الاتصال وجهات الاتصال والمراسلة المثبَّتة مسبقًا يمكنها البحث عن معلومات المتصل والبحث عنها من الملف الشخصي المُدار (إن وُجد) إلى جانب المعلومات الواردة في الملف الشخصي الأساسي، إذا كانت "وحدة التحكّم في سياسة الجهاز" تسمح بذلك.
• [C-1-9] يجب أن يضمن استيفاء هذا الجهاز لجميع متطلبات الأمان السارية على الجهاز الذي تم تفعيل ميزة العديد من المستخدمين فيه (راجِع القسم 9.5)، حتى إذا لم يتم احتساب الملف الشخصي المُدار كمستخدم آخر إلى جانب المستخدم الأساسي.
• [C-1-10] يجب أن يتيح إمكانية تحديد شاشة قفل منفصلة تستوفي المتطلبات التالية لمنح إذن الوصول إلى التطبيقات التي يتم تشغيلها في ملف شخصي مُدار.
  • يجب أن تراعي عمليات تنفيذ الأجهزة هدف DevicePolicyManager.ACTION_SET_NEW_PASSWORD وأن تعرض واجهة لإعداد بيانات اعتماد منفصلة لشاشة القفل للملف الشخصي المُدار.
  • يجب أن تستخدم بيانات اعتماد شاشة القفل للملف الشخصي المُدار آليات تخزين بيانات الاعتماد والإدارة نفسها المستخدمة في الملف الشخصي الرئيسي، على النحو الموضَّح في موقع مشروع مفتوح المصدر لنظام Android.
  • يجب أن تنطبق سياسات كلمة المرور في وحدة التحكّم بسياسة الجهاز على بيانات اعتماد شاشة القفل للملف الشخصي المُدار فقط ما لم يتم استدعاؤها من خلال المثيل 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 على واجهات برمجة تطبيقات تتيح للتطبيقات استخدام خدمات تحويل النص إلى كلام وتسمح لمقدمي الخدمات بتوفير عمليات تنفيذ خدمات تحويل النص إلى كلام.

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

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

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

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

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

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

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

• [C-1-1] يجب أن يعلن عن ميزة المنصة android.software.live_tv.
• [C-1-2] يجب أن يتوافق مع جميع واجهات TIF API، وبالتالي يمكن تثبيت واستخدام أي تطبيق يستخدم واجهات برمجة التطبيقات هذه وخدمة الإدخالات المستندة إلى 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] يجب ألا تتفاعل التطبيقات الفورية مع التطبيقات المثبّتة باستخدام أهداف ضمنية ما لم ينطبق أي مما يلي:
  • تم الكشف عن فلتر نمط intent للمكوِّن ويحتوي على 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)، كما هي الحال مع المهام الأخرى التي من المتوقّع أن تظل قيد التشغيل، مثل الخدمات التي تعمل في المقدّمة. أثناء تشغيل هذا التطبيق في الخلفية، سيظل بإمكان النظام تطبيق ميزات إدارة الطاقة عليه، مثل تقييد الوصول إلى وحدة المعالجة المركزية (CPU) والشبكة.
• [C-1-2] يجب توفير ميزة واجهة المستخدم لاختيار التطبيق الذي لن يشارك في آلية الحفظ/الاستعادة في الحالة العادية بعد تشغيل المستخدم لتطبيق ثانٍ تم الإعلان عنه باستخدام السمة cantSaveState.
• [C-1-3] يجب ألا يطبِّق تغييرات أخرى في السياسة على التطبيقات التي تحدّد cantSaveState، مثل تغيير أداء وحدة المعالجة المركزية (CPU) أو تغيير أولويات الجدولة.

إذا لم تشير عمليات تنفيذ الأجهزة إلى الميزة FEATURE_CANT_SAVE_STATE، سيتم عندها:

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

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

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

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

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

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

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

• يجب أن يكون لدى [C-0-5] نشاط يعالج الغرض من android.settings.MANAGE_UNKNOWN_APP_SOURCES.

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

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

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

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

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

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

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

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

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

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

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

يُرجى ملاحظة أنّه لا توجد أي إقرارات من 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 (وفقًا لمعيار ISO/IEC 23003-3 Extended HE AAC Profile، والذي يتضمّن الملف الشخصي المرجعي في 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 API، يجب استخدام ما يلي:

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

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

• [C-3-1] يجب تفسير البيانات الوصفية لارتفاع مستوى الصوت وجمهورية الكونغو الديمقراطية وتطبيقها وفقًا للمستوى 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:

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

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

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 x 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. تفاصيل برامج ترميز الصور

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

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

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

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

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

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

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

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

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

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

• [C-1-3] يجب أن تتوافق برامج ترميز الفيديو وبرامج فك ترميزها مع تنسيق ألوان YUV420 مستوٍ أو شبه مستوٍ 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.

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

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

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

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

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

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

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

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

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

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

يتيح نظام التشغيل Android استخدام OMX، وهي واجهة برمجة تطبيقات لتسريع الوسائط المتعددة عبر الأنظمة الأساسية، بالإضافة إلى Codec 2.0، وهي واجهة برمجة تطبيقات لتسريع الوسائط المتعددة تعمل بمنتهى السهولة.

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

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

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

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

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

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

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

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

	SD (جودة منخفضة)	SD (جودة عالية)	دقة عالية - 720p	دقة عالية - 1080p	دقة فائقة
دقة الفيديو	176 × 144 بكسل (H263 أو MPEG2 أو MPEG4) 352 × 288 بكسل (برنامج ترميز MPEG4 أو H263 أو MPEG2) 320 × 180 بكسل (VP8 وVP8) 320 × 240 بكسل (غير ذلك)	704 × 576 بكسل (H263) 640 × 360 بكسل (VP8 وVP9) 640 × 480 بكسل (برنامج ترميز MPEG4) 720 × 480 بكسل (غير ذلك)	1408 × 1152 بكسل (H263) 1280 × 720 بكسل (غير ذلك)	1920 × 1080 بكسل (بخلاف MPEG4)	3840 × 2160 بكسل (HEVC وVP9)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.2.3. نموذج الفيديو 8 (VP8)

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

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

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

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

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

5.2.4. نموذج الفيديو 9 (VP9)

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

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

	دقة عادية	دقة عالية - 720p	دقة عالية - 1080p	دقة فائقة
دقة الفيديو	720 × 480 بكسل	1280 × 720 بكسل	1920 × 1080 بكسل	3840 × 2160 بكسل
عدد اللقطات في الثانية للفيديو	30 إطارًا في الثانية	30 إطارًا في الثانية	30 إطارًا في الثانية	30 إطارًا في الثانية
معدّل نقل بيانات الفيديو	1.6 ميغابت في الثانية	‫4 ميغابت في الثانية	5 ميغابت في الثانية	20 ميغابت في الثانية

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

• يتوفّر الدعم لتنسيق 12 بت بشكلٍ اختياري.

5.2.5. بروتوكول H.265

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

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

	دقة عادية	دقة عالية - 720p	دقة عالية - 1080p	دقة فائقة
دقة الفيديو	720 × 480 بكسل	1280 × 720 بكسل	1920 × 1080 بكسل	3840 × 2160 بكسل
عدد اللقطات في الثانية للفيديو	30 إطارًا في الثانية	30 إطارًا في الثانية	30 إطارًا في الثانية	30 إطارًا في الثانية
معدّل نقل بيانات الفيديو	1.6 ميغابت في الثانية	‫4 ميغابت في الثانية	5 ميغابت في الثانية	20 ميغابت في الثانية

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] يجب أن يتوافق مع المستوى 3 من الملف الشخصي البسيط.

5.3.4 H.264

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

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

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

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

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

5.3.5. ‫H.265 (HEVC)

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

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

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

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

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

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

• [C-3-1] يجب أن تقبل عمليات تنفيذ الأجهزة البيانات الوصفية المطلوبة للنطاق العالي الديناميكية (MediaFormat#KEY_HDR_StatIC_INFO لكل الملفات الشخصية ذات تنسيق HDR) من التطبيق باستخدام واجهة برمجة التطبيقات MediaCodec API، بالإضافة إلى إتاحة استخراج البيانات الوصفية ذات تنسيق HDR المطلوبة (MediaFormat#KEY_HDR_PSTIC_INFO لجميع ملفات HDR الشخصية، بالإضافة إلى MediaFormat#KEY_INFO10_PLUS_0المواصفات ذات الصلة في الحاوية. ويجب أن تتيح أيضًا إخراج البيانات الوصفية المطلوبة ذات تنسيق HDR (MediaFormat#KEY_HDR_StatIC_INFO لجميع الملفات الشخصية بنطاق HDR) من البث المباشر و/أو الحاوية على النحو المحدّد في المواصفات ذات الصلة.

• [C-SR] ننصح بشدة بعمليات تنفيذ الأجهزة لإتاحة إخراج البيانات الوصفية MediaFormat#KEY_HDR10_PLUS_INFO للملفات الشخصية بتقنية HDR10Plus عبر MediaCodec#getOutputFormat(int)..

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

• [C-SR] يُنصَح بشدة بإجراءات تنفيذ الأجهزة لعرض محتوى النطاق العالي الديناميكية بشكل صحيح للملف الشخصي على HEVCProfileMain10HDR10Plus على شاشة الجهاز أو على منفذ إخراج الفيديو العادي (مثل HDMI).

5.3.6. نموذج الفيديو 8 (VP8)

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

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

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

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

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

5.3.7. نموذج الفيديو 9 (VP9)

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

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

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

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

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

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

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

إذا ادّعت عمليات تنفيذ الأجهزة أنّها تتيح VP9Profile2 أو VP9Profile3 من خلال واجهات برمجة تطبيقات الوسائط 'CodecProfileLevel:

• يتوفّر الدعم لتنسيق 12 بت بشكلٍ اختياري.

إذا ادّعت عمليات تنفيذ الأجهزة أنّها تتيح ملف شخصي بنطاق عالي الديناميكية (VP9Profile2HDR أو VP9Profile2HDR10Plus أو VP9Profile3HDR أو VP9Profile3HDR10Plus) من خلال واجهات برمجة التطبيقات للوسائط:

• [C-4-1] يجب أن تقبل عمليات تنفيذ الأجهزة البيانات الوصفية المطلوبة للنطاق العالي الديناميكية (MediaFormat#KEY_HDR_STATIC_INFO لكل الملفات الشخصية ذات النطاق العالي الديناميكية، بالإضافة إلى المَعلمة MediaCodec#PARAMETER_KEY_HDR10_PLUS_INFO للملفات الشخصية HDR10Plus) من التطبيق باستخدام MediaCodec API، بالإضافة إلى إتاحة استخراج البيانات الوصفية المطلوبة ذات تنسيق HDR (MediaFormat#KEY_HDR_STATIC_INFO لجميع الملفات الشخصية ذات النطاق العالي الديناميكية، بالإضافة إلى MediaFormat#KEY_HDR10_PLUS_INFO للملفات الشخصية للنطاق HDR10Plus) من مصدر البيانات و/أو الحاوية ذات الصلة على النحو المحدّد من مصدر البيانات و/أو الحاوية ذات الصلة. يجب أن تتيح أيضًا إخراج البيانات الوصفية المطلوبة ذات تنسيق HDR (MediaFormat#KEY_HDR_STATIC_INFO لكل الملفات الشخصية ذات النطاق العالي الديناميكية) من البث المباشر و/أو الحاوية على النحو المحدّد في المواصفات ذات الصلة.

• [C-4-2] يجب أن تعرض عمليات تنفيذ الأجهزة محتوى النطاق العالي الديناميكية بشكل صحيح للملفين الشخصيين 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] يجب أن يتوافق مع الملف الشخصي 0، بما في ذلك محتوى 10 بت.

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

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

5.4.1. معلومات تسجيل الصوت والميكروفونات الأولية

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

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

  • التنسيق: PCM خطي، 16 بت
  • معدلات أخذ العينات: 8000، 11025، 16000، 44100، 48,000 هرتز
  • القنوات: أحادي

• "ينبغي" السماح بالتقاط محتوى صوتي غير واضح يحتوي على الخصائص التالية:

  • التنسيق: PCM الخطي، 16 بت و24 بت
  • معدلات أخذ العينات: 8000، 11025، 16000، 22050، 24000، 32,000، 44100، 48,000 هرتز
  • القنوات: عدد القنوات الذي يساوي عدد الميكروفونات على الجهاز

• [C-1-2] يجب أن يتم التقاطها بمعدلات عينة أعلى من دون زيادة العينات.

• يجب أن يشتمل [C-1-3] على فلتر مناسب للحماية من التشويش عند تسجيل معدلات العينات الموضحة أعلاه باستخدام العينات المنخفضة.

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

  • التنسيق: 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 هرتز إلى 4,000 هرتز.
• "ينبغي" تسجيل بث الصوت لميزة "التعرّف على الصوت" مع ضبط حساسية الإدخال، بحيث ينتج عن مصدر طاقة صوت بتردد 90 ديسيبل عند مستوى 1000 هرتز 2500 رمز ثابت معدَّل للعينات ذات 16 بت.
• يجب تسجيل البث الصوتي لميزة "التعرّف على الصوت" كي تتغير مستويات اتساع صوت PCM خطيًا لنطاق SPL للإدخال الذي يزيد عن 30 ديسيبل على الأقل من -18 ديسيبل إلى +12 ديسيبل re 90 ديسيبل SPL في الميكروفون.
• يجب تسجيل البث الصوتي لميزة "التعرّف على الصوت" مع تشويه إجمالي أقل من% 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] يتم strongLY_RECOMMENDED للإبلاغ عن ذلك باستخدام طريقة واجهة برمجة التطبيقات AcousticEchoCanceler AcousticEchoCanceler.isAvailable()
• إنّ [C-SR] مضبوطة على strongLY_RECOMMENDED للسماح بالتحكّم في هذا التأثير الصوتي باستخدام واجهة برمجة التطبيقات AcousticEchoCanceler.
• [C-SR] يجب أن تُستخدَم strongLY_RECOMMENDED لتحديد كل تطبيق من تقنيات AEC بشكل فريد عبر الحقل AudioEffect.Descriptor.uuid.

5.4.5. التقاط متزامن

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

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

  • تنسيقات المصدر: PCM الخطي، 16 بت، 8 بت، عائم
  • القنوات: يمكنك ضبط ما يصل إلى 8 قنوات على إعدادات أحادية وستيريو وقنوات متعددة صالحة.
  • معدّلات أخذ العينات (بالهرتز):
    • 8000 و11025 و16000 و22050 و32000 و44100 و48000 في إعدادات القناة المذكورة أعلاه
    • 96000 في وضع أحادي وستيريو

• "يجب السماح" بتشغيل محتوى صوتي غير منسق بالخصائص التالية:

  • معدلات أخذ العينات: 24,000

5.5.2 التأثيرات الصوتية

يوفر Android واجهة برمجة تطبيقات للتأثيرات الصوتية لعمليات تنفيذ الأجهزة.

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

• [C-1-1] يجب أن يتوافق مع عمليتَي تنفيذ EFFECT_TYPE_EQUALIZER وEFFECT_TYPE_LOUDNESS_ENHANCER التي يمكن التحكم فيها من خلال الفئتين الفرعيتين AudioEffect (Equalizer) وLoudnessEnhancer.
• [C-1-2] يجب أن يتيح تنفيذ واجهة برمجة تطبيقات العروض المرئية، ويمكن التحكّم فيها من خلال فئة Visualizer.
• [C-1-3] يجب أن يتوافق مع تنفيذ EFFECT_TYPE_DYNAMICS_PROCESSING الذي يمكن التحكم فيه من خلال الفئة الفرعية AudioEffect DynamicsProcessing.
• يجب أن تتوافق مع عمليات التنفيذ EFFECT_TYPE_BASS_BOOST وEFFECT_TYPE_ENV_REVERB وEFFECT_TYPE_PRESET_REVERB وEFFECT_TYPE_VIRTUALIZER التي يمكن التحكّم فيها من خلال الفئات الفرعية AudioEffect BassBoost وEnvironmentalReverb وPresetReverb وVirtualizer.
• [C-SR] يُنصَح باستخدامها بشدة لإتاحة التأثيرات في النقطة العائمة والقنوات المتعدّدة.

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

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

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

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

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

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

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

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

• [C-SR] يُنصح بشدة بالإبلاغ عن وقت الاستجابة البطيء من خلال الإعلان عن علامة ميزة android.hardware.audio.low_latency.
• [C-SR] يُنصح بشدة باستيفاء متطلبات وقت الاستجابة السريع الصوتي عبر AAudio API.
• [C-SR] ننصح بشدة بالتأكّد من أنّ القيمة التي يعرضها AAudioStream_getFramesPerBurst() تكون أقلّ من أو تساوي القيمة التي يعرضها android.media.AudioManager.getProperty(String) لمفتاح الموقع AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER في مصادر البيانات التي تعرض AAUDIO_PERFORMANCE_MODE_LOW_LATENCY من AAudioStream_getPerformanceMode().

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

تنسيقات شرائح الوسائط

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

بروتوكول النقل في الوقت الفعلي (RTP)، أو بروتوكول البث المباشر على الإنترنت (SDP)

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

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

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

• [C-1-1] يجب أن يعلن عن دعمه لـ Display.FLAG_SECURE.

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

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

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

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

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

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

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

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

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

• [C-1-3] يجب أن يتضمن libamedi.so (دعم MIDI الأصلي)

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

في حال إبلاغ عمليات تنفيذ الأجهزة عن توافق ميزة "android.hardware.audio.pro" من خلال فئة android.content.pm.PackageManager، سيتم ما يلي:

• [C-1-1] يجب الإبلاغ عن إتاحة الميزة android.hardware.audio.low_latency.
• يجب أن يتوفّر وقت استجابة الصوت ذهابًا وإيابًا بشكل متواصل في [C-1-2]، كما هو محدَّد في وقت استجابة الصوت في القسم 5.6، وأن يبلغ 20 ملي ثانية أو أقل، على أن يكون 10 ملي ثانية أو أقل خلال مسار واحد متوافق على الأقل.
• [C-1-3] يجب أن يشتمل على منافذ USB تتوافق مع وضع مضيف USB ووضع الأجهزة الملحقة عبر USB.
• [C-1-4] يجب الإبلاغ عن إتاحة الميزة android.software.midi.
• يجب أن يستوفي [C-1-5] وقت الاستجابة ومتطلبات صوت USB باستخدام كلٍّ من واجهة برمجة تطبيقات قائمة انتظار المخزن المؤقت OpenSL ES PCM ومسار واحد على الأقل لواجهة برمجة التطبيقات AAudio asset audio.
• [التسجيل الصوتي] يُنصَح باستخدامها بشدة لاستيفاء أوقات الاستجابة ومتطلبات صوت USB باستخدام واجهة برمجة التطبيقات AAudio asset audio على مسار MMAP.
• [C-1-6] يجب أن يبلغ وقت استجابة إخراج الصوت البارد 200 ملّي ثانية أو أقل.
• [C-1-7] يجب أن يبلغ وقت استجابة إدخال "البارد" 200 ملّي ثانية أو أقل.
• [SR] يُوصى بشدة بتوفير مستوى ثابت من أداء وحدة المعالجة المركزية (CPU) عندما يكون الصوت نشطًا ويختلف حِمل وحدة المعالجة المركزية (CPU). يجب اختبار ذلك باستخدام إصدار تطبيق Android من رقم تعريف إتمام SynthMark 09b13c6f49ea089f8c31e5d035f912cc405b7ab8. يستخدم SynthMark أداة توليف برامج تعمل على إطار عمل محاكاة الصوت ويقيس أداء النظام. يجب تشغيل تطبيق SynthMark باستخدام خيار "الاختبار المبرمَج" وتحقيق النتائج التالية:
  • Voicemark.90 >= 32 صوتًا
  • timemark.fixed.little <= 15 مللي ثانية
  • timemark.dynamic.little <= 50 ميللي ثانية

اطّلِع على مستندات SynthMark للحصول على شرح لمقاييس الأداء.

• يجب تقليل دقة ساعة الصوت وانحرافها بالنسبة إلى الوقت القياسي.
• يجب تقليل تغيُّر ساعة الصوت إلى أدنى حد ممكن مقارنةً بوحدة المعالجة المركزية (CPU) 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 ملم من 4 موصّلات من الأجهزة تتضمن منافذ USB تتوافق مع وضع مضيف USB، ينطبق ما يلي:

• [C-3-1] يجب تنفيذ فئة الصوت على USB.
• يجب أن يكون لدى [C-3-2] وقت استجابة صوت ذهاب وعودة مستمر لمدة 20 ملّي ثانية أو أقل عبر منفذ وضع مضيف USB باستخدام فئة الصوت على USB.
• يجب أن يكون وقت الاستجابة المستمر للصوت ذهابًا وإيابًا 10 ملي ثانية أو أقل عبر منفذ وضع مضيف USB باستخدام فئة صوت USB.
• [C-SR] يُنصَح باستخدامها بشدة لإتاحة وحدات الإدخال/الإخراج المتزامنة بما يصل إلى 8 قنوات في كل اتجاه، ومعدل عينة بتردد 96 كيلوهرتز، وبعمق 24 بت أو 32 بت، عند استخدامها مع أجهزة USB الطرفية الملحقة التي تستوفي هذه المتطلبات أيضًا.

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

• "يُفترض أن" يتوافق مع الإخراج في وضع الاستيريو وثمانية قنوات بعمق 20 بت أو 24 بت و192 كيلوهرتز بدون فقدان عمق البت أو إعادة أخذ عينات منه، وذلك في إعداد واحد على الأقل.

5.11. التقاط لم تتم معالجته

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

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

• [C-1-1] يجب الإبلاغ عن الدعم من خلال موقع android.media.AudioManager Property_SUPPORT_AUDIO_SOURCE_UNPROCESSED.

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

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

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

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

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

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

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

• [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 Debug Bridge (adb)

  • يجب أن يتوافق [C-0-2] مع أداة adb كما هو موثَّق في حزمة تطوير البرامج (SDK) لنظام التشغيل Android وأوامر Shell المتوفرة في AOSP، والتي يمكن لمطوّري التطبيقات استخدامها، بما في ذلك dumpsys cmd stats
  • [C-SR] يُنصَح باستخدامه بشكل كبير لإتاحة أمر Shell cmd testharness.
  • [C-0-3] يجب ألا يغير تنسيق أو محتويات أحداث نظام الجهاز (بطارية أو قرص تخزين بيانات أو بصمة الإصبع أو إحصاءات الرسومات أو netstats أو الإشعارات أو Procstats) التي يتم تسجيلها من خلال الأمر dumpsys.
  • يجب أن يسجّل [C-0-10] الأحداث التالية بدون حذف، ويتيح الوصول إلى الأحداث التالية وأن تكون متاحة لأمر Shell وفئة StatsManager System API.cmd stats
    • تم تغيير حالة ActivityForegroundState.
    • تم رصد قيمة شاذة
    • تم الإبلاغ عن مسار تنقل التطبيق
    • حدث AppCrashOccurred
    • حدث AppStartOccurred
    • تم تغيير مستوى البطارية
    • البطاريةSaverModeStateChanged
    • تم تلقّي نتيجة BleScanResult
    • BleScanStateChanged
    • تم تغيير حالة الشحن
    • DeviceIdleModeStateChanged
    • .ForegroundServiceStateChanged
    • GpsScanStateChanged
    • تم تغيير JobState
    • plgedStateChanged
    • scheduleJobStateChanged
    • تم تغيير حالة الشاشة
    • SyncStateChanged
    • SystemEboundedRealtime (الوقت الفعلي للنظام)
    • UidProcessStateChanged
    • تم تغيير حالة WakelockState
    • حدث منبّه الصباح
    • تم تغيير حالة WifiLockState
    • تم تغيير حالة WifiMulticastLock
    • تم تغيير حالة Wi-FiScanState
  • [C-0-4] يجب أن يكون البرنامج الخفي لـ adb من جهة الجهاز غير نشط بشكل تلقائي ويجب أن تكون هناك آلية يمكن للمستخدمين الوصول إليها لتفعيل Android Debug Bridge.
  • [C-0-5] يجب أن يتيح استخدام adb. يشمل Android استخدام أداة Adb الآمنة. يفعِّل Adb الآمن واجهة برمجة التطبيقات (ADb) على المضيفات المعروفة التي تمت مصادقتها.

  • [C-0-6] يجب أن يوفّر آلية تسمح باتصال Adb من جهاز مضيف. مثلاً:

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

• خدمة Dalvik Debug Monitor (ddms)

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

• Perfetto

  • [C-SR] يُنصح بشدة بعرض برنامج ثنائي /system/bin/perfetto لمستخدم واجهة الأوامر الذي يتوافق مع cmdline مع مستندات الأداء.
  • [C-SR] ننصح بشدة بقبول البرنامج الثنائي للأداء كإدخال إعداد نموذج أوّلي يتوافق مع المخطط المحدّد في مستندات الأداء.
  • [C-SR] ننصح بشدة بكتابة بيانات تتبُّع أوّلية متوافقة مع المخطط المحدّد في مستندات الأداء كبرنامج ثنائي الأداء.
  • [C-SR] يُنصَح بشدة بتقديم مصادر البيانات الموضَّحة في مستندات Perfetto على الأقل من خلال البرنامج الثنائي للأداء.

• وضع مفعِّل الاختبار

  إذا كانت عمليات تنفيذ الأجهزة تتوافق مع أمر واجهة المستخدم cmd testharness وتم تشغيل cmd testharness enable، سيتم ما يلي:

  • [C-2-1] يجب عرض true لمدة ActivityManager.isRunningInUserTestHarness()
  • [C-2-2] يجب تنفيذ "وضع مفعِّل الاختبار" كما هو موضَّح في مستندات وضع "تسخير" البيانات.

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

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

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

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

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

• يجب أن يلتزم [C-0-1] بالهدف android.settings.APPLICATION_DEVELOPMENT_SETTINGS لعرض الإعدادات المتعلقة بتطوير التطبيقات. تُخفي عملية تنفيذ Android الأولية قائمة "خيارات المطوّرين" تلقائيًا وتمكِّن المستخدمين من تشغيل "خيارات المطوّرين" بعد الضغط سبع (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 لملف مرجعي الإصدار نفسه.

ومن الأمثلة النموذجية على السيناريو الذي يتم فيه تطبيق هذه المتطلبات هي واجهة برمجة التطبيقات telephony API: حتى على الأجهزة بخلاف الهواتف، يجب تنفيذ واجهات برمجة التطبيقات هذه في حالة بيئة مستقلة.

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

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

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

• الحجم القطري الفعلي. المسافة بالبوصة بين زاوية مواجهة للجزء المضيء من الشاشة.
• نقاط لكل بوصة (dpi). عدد وحدات البكسل التي يحتوي عليها نطاق خطي أو عمودي أو أفقي بمقدار 1 بوصة عند سرد قيم النقاط لكل بوصة (DPI)، يجب أن تقع كل من النقاط الأفقية والرأسية ضمن النطاق.
• نسبة العرض إلى الارتفاع يشير إلى نسبة وحدات البكسل للبُعد الأطول إلى بُعد الأقصر للشاشة. على سبيل المثال، ستكون نسبة العرض 480×854 بكسل 854/480 = 1.779، أو 16:9 تقريبًا.
• وحدة بكسل مستقلة الكثافة (dp) وحدة البكسل الافتراضية التي تمت تسويتها إلى شاشة تبلغ 160 نقطة لكل بوصة، ويتم احتسابها على النحو التالي: بكسل = dps * (الكثافة/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 بكسل مستقل الكثافة (dp).
  • يجب أن تحتوي الأجهزة التي يبلغ حجمها large على Configuration.screenLayout بدقة 640 بكسل مستقل الكثافة × 480 بكسل مستقل الكثافة (dp).
  • يجب أن تتضمّن الأجهزة التي يبلغ حجمها 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 وواجهات برمجة تطبيقات الإعداد، المتطلبات التالية:

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

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

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

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

• يجب أن تتوافق مع الإصدار 1.1 من Vulkan.

في حال اشتملت عمليات تنفيذ الجهاز على دعم 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().

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

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

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

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

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

جميع الشاشات المتوافقة مع 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 لعمليات تنفيذ أجهزة التلفزيون. يجب أن تكون الدالة Home الآلية لهذه الوظيفة التي يمكن لهذا المستخدم الوصول إليها.
• يجب توفير أزرار لوظيفة "الأخيرة" و"الرجوع".

إذا تم توفير وظيفتَي "الصفحة الرئيسية" و"الأخيرة" و"رجوع"، سيتم ما يلي:

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

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

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

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

• [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. الإدخال باللمس الزائف

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

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

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

إذا كانت عمليات تنفيذ الأجهزة تشير إلى توافقها مع android.hardware.faketouch، سيحدث ما يلي:

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

إذا كانت عمليات تنفيذ الأجهزة تشير إلى توافقها مع android.hardware.faketouch.multitouch.distinct، سيحدث ما يلي:

• [C-2-1] يجب أن يعلن عن دعمه لـ android.hardware.faketouch.
• [C-2-2] يجب أن يتيح التتبع المميز لاثنين أو أكثر من إدخالات المؤشر المستقلة.

إذا كانت عمليات تنفيذ الأجهزة تشير إلى توافقها مع android.hardware.faketouch.multitouch.jazzhand، سيحدث ما يلي:

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

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

7.2.6.1. تعيينات الأزرار

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

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

زرّ	استخدام أجهزة HID2	زر Android
أ1	0x09 0x0001	KEYCODE_button_A (96)
ب1	0x09 0x0002	KEYCODE_button_B (97)
X1	0x09 0x0004	KEYCODE_button_X (99)
ش1	0x09 0x0005	KEYCODE_button_Y (100)
لوحة التحكّم1 لوحة التحكّم1	0x01 0x00393	AXIS_HAT_Y4
لوحة التحكّم لليسار1 لوحة التحكّم اليمنى1	0x01 0x00393	AXIS_HAT_X4
زر الكتف الأيسر1	0x09 0x0007	KEYCODE_button_L1 (102)
زر الكتف الأيمن1	0x09 0x0008	KEYCODE_button_R1 (103)
النقر على الذراع اليسرى1	0x09 0x000E	KEYCODE_button_THUMBL (106)
النقر بزر الماوس الأيمن1	0x09 0x000F	KEYCODE_button_THUMBR (107)
الصفحة الرئيسية1	0x0c 0x0223	KEYCODE_Home (3)
رجوع1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

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

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

4 MotionEvent

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

1 MotionEvent

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

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

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

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

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

• [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] يجب ألّا يمنع بث حدث أداة الاستشعار وحدة المعالجة المركزية (CPU) من إدخال حالة التعليق أو الاستيقاظ من حالة التعليق.

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

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

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

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

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

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

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

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

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

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

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

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

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

• [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 (نظام تحديد المواقع العالمي (GPS)) وتُبلغ التطبيقات عن الإمكانية من خلال علامة ميزة android.hardware.location.gps، سيتم إجراء ما يلي:

• [C-1-1] يجب أن يوفّر نتائج الموقع الجغرافي بمعدّل لا يقل عن 1 هرتز عند طلبه عبر "LocationManager#requestLocationUpdate".
• [C-1-2] يجب أن يتمكن من تحديد الموقع في ظروف السماء المفتوحة (الإشارات القوية، والمسارات المتعددة المهمة، وتقنية HDOP أقل من 2) في غضون 10 ثوانٍ (الوقت الأسرع لإصلاحه لأول مرة)، عند الاتصال باتصال إنترنت بسرعة بيانات 0.5 ميغابت في الثانية أو أكثر. يتم تلبية هذا الشرط عادةً من خلال استخدام أحد أشكال تقنية نظام تحديد المواقع العالمي (GPS)/نظام GNSS المدعومة أو المتوقعة لخفض وقت قفل نظام تحديد المواقع العالمي (GPS)/نظام GNSS (تشمل بيانات المساعدة الوقت المرجعي، والموقع المرجعي، وساعة القمر الصناعي المؤقت).
  • [C-1-6] بعد إجراء عملية حسابية للموقع الجغرافي، يجب أن تحدد عمليات تنفيذ الأجهزة موقعه الجغرافي في مكان مفتوح خلال 5 ثوانٍ من إعادة تشغيل طلبات الموقع الجغرافي، بعد ما يصل إلى ساعة من الحساب الأولي للموقع، حتى عند تقديم طلب لاحق بدون اتصال بيانات و/أو بعد دورة الطاقة.

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

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

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] يُنصَح بشدة بأن تكون قادرًا على الإبلاغ عن قياسات الضغط في النطاق الذي يتراوح بين 300hPa إلى 1100hPa.
• "ينبغي" الحصول على دقة مطلقة تبلغ 1hPa.
• يجب أن تكون الدقة النسبية 0.12hPa أعلى من نطاق 20hPa (أي ما يعادل حوالي 1 متر وتغير حوالي 200 متر على مستوى سطح البحر).

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

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

• قد يشتمل هذا التطبيق على ميزان حرارة محيط (جهاز استشعار الحرارة).
• قد يشمل ذلك جهاز استشعار لدرجة حرارة وحدة المعالجة المركزية (CPU).

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

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

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

7.3.7. مقياس ضوء

• وقد تشمل إجراءات استخدام الجهاز مقياس ضوء (أداة استشعار الضوء المحيط).

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

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

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

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

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

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

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

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

• يجب أن يتضمّن [C-2-1] جهاز استشعار "TYPE_ACCELEROMETER" ينطبق عليه ما يلي:

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

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

• يجب أن يتضمّن [C-2-3] أداة استشعار TYPE_GYROSCOPE وهي:

  • يجب أن يتراوح نطاق القياس بين -1000 و +1000 نقطة في الثانية على الأقل.
  • يجب أن تكون درجة دقة القياس 16 LSB/dps على الأقل.
  • يجب أن يكون الحد الأدنى لتكرار القياس 12.5 هرتز أو أقل.
  • يجب أن يبلغ الحد الأقصى لتردد القياس 400 هرتز أو أعلى. يجب أن تتوافق مع جهاز SensorDirectChannel RATE_VERY_FAST.
  • يجب أن يكون هناك تشويش في قياس حالة الجهاز لا يزيد عن 0.014 درجة/ثانية/وإعادة هرتز.
  • [C-SR] يُنصَح بشدة بأن يتضمّن معدل نقل بيانات قياس 3dB بنسبة لا تقل عن 80% من تردد Nyquist، وطيف ضوضاء أبيض ضمن معدل نقل البيانات هذا.
  • يجب أن يكون معدّل المشي العشوائي أقلّ من 0.001 درجة/ثانية ©Hz تم اختباره في درجة حرارة الغرفة.
  • يُفترض أن يكون هناك تغيُّر في الانحياز مقارنةً بدرجة الحرارة التي تبلغ ≤ +/- 0.05 درجة/ ثانية / درجة مئوية.
  • من المفترض أن يتغيّر مستوى الحساسية مقارنةً بدرجة الحرارة التي تقل عن 0.02% / درجة مئوية.
  • يُفترض أن يحتوي الخط غير الخطي على أفضل ملائمة، وهو ≤ 0.2%.
  • من المفترض أن تكون كثافة الضوضاء 0.007 درجة/ثانية/وإعادة هرتز أو أقل.
  • من المفترض أن يحدث خطأ في المعايرة يقل عن 0.002 راد/ثانية في نطاق درجة حرارة يتراوح بين 10 و40 درجة مئوية عندما يكون الجهاز ثابتًا.
  • يجب أن تكون حساسية g-g أقل من 0.1 درجة/s/g.
  • يجب أن تكون حساسية المحور المتقاطع < 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 وحدة uT.

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

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

• يجب أن يستوفي [C-0-2] متطلبات الحصول على قوي على النحو المحدّد في هذا المستند.

علاوةً على ذلك:

• يجب إقران [C-0-3] بإجراء تأكيد صريح (مثل الضغط على زر) إذا كان المقياس الحيوي القوي سلبيًا (على سبيل المثال، وجه أو قزحية لا تتوفّر فيها إشارة صريحة إلى نية المستخدم).
  • [C-SR] يُنصَح بشدة بتأمين الإجراء المتّبع للمقاييس الحيوية السلبية كي لا يمكن انتحال صفة نظام التشغيل أو اختراق النواة. وهذا يعني مثلاً أنّ إجراء التأكيد المستند إلى زر فعلي يتم توجيهه من خلال دبوس إدخال/إخراج (GPIO) للإدخال فقط للأغراض العامة (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 وهذا المستند تحديدًا إلى الأجهزة المتعلقة بإجراء مكالمات صوتية وإرسال رسائل قصيرة SMS عبر شبكة GSM أو CDMA. على الرغم من أنّ هذه المكالمات الصوتية قد يتم تبديلها بين حِزم البيانات أو لا، فإنّها لأغراض Android مستقلة عن أي اتصال بيانات قد يتم تنفيذه باستخدام الشبكة نفسها. بمعنى آخر، تشير وظيفة "الهاتف" وواجهات برمجة التطبيقات في Android على وجه التحديد إلى المكالمات الصوتية والرسائل القصيرة SMS. على سبيل المثال، لا تُعتبر عمليات تنفيذ الأجهزة التي لا يمكنها إجراء مكالمات أو إرسال/استقبال رسائل 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] يجب حظر جميع المكالمات والرسائل من رقم هاتف في BlockNumberProvider. بدون أي تفاعل مع التطبيقات. والاستثناء الوحيد هو عندما يتم رفع حظر الرقم مؤقتًا كما هو موضّح في مستندات حزمة تطوير البرامج (SDK).
• [C-1-4] يجب ألّا يتواصل مع موفِّر خدمة سجلّ المكالمات في النظام الأساسي بشأن مكالمة محظورة.
• [C-1-5] يجب ألّا يتواصل مع مقدِّم خدمات الاتصال الهاتفي بشأن رسالة محظورة.
• [C-1-6] يجب تنفيذ واجهة مستخدم لإدارة الأرقام المحظورة، والتي يتم فتحها بهدف العرض باستخدام طريقة TelecomManager.createManageBlockedNumbersIntent().
• [C-1-7] يجب ألا يسمح للمستخدمين الثانويين بعرض الأرقام المحظورة على الجهاز أو تعديلها، حيث يفترض نظام Android الأساسي أن المستخدم الأساسي يتمتع بالتحكم الكامل في خدمات الاتصال الهاتفي، في نسخة واحدة، على الجهاز. يجب إخفاء جميع واجهات المستخدم ذات الصلة التي تؤدي إلى حظر الوصول إلى المستخدمين الثانويين، كما يجب احترام القائمة المحظورة.
• "يجب نقل الأرقام المحظورة إلى مقدّم الخدمة عند تحديث الجهاز إلى الإصدار Android 7.0.

7.4.1.2. واجهة برمجة تطبيقات الاتصالات

في حال أبلغت عمليات تنفيذ الأجهزة عن 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] يجب أن يستخدم multicast API كما هو موضّح في مستندات حزمة SDK.
• [C-1-4] يجب أن يتوافق مع نظام أسماء النطاقات ذي البث المتعدد (mDNS) ويجب ألا يصف حزم mDNS (224.0.0.251) في أي وقت من التشغيل، بما في ذلك:
  • حتى عندما لا تكون الشاشة في حالة نشطة.
  • لتطبيقات أجهزة Android TV، حتى عندما يكون الجهاز في حالة وضع الاستعداد
• [C-1-5] يجب ألا يتم التعامل مع طلب طريقة واجهة برمجة التطبيقات WifiManager.enableNetwork() باعتباره مؤشرًا كافيًا لتبديل Network النشط حاليًا والذي يتم استخدامه تلقائيًا لعدد زيارات التطبيقات ويتم عرضه من خلال طرق واجهة برمجة التطبيقات ConnectivityManager مثل getActiveNetwork وregisterDefaultNetworkCallback. بمعنى آخر، قد توقِف هذه التطبيقات إمكانية الوصول إلى الإنترنت من خلال أي مزوّد شبكة آخر (على سبيل المثال، بيانات الجوّال) إذا تم التحقّق بنجاح من أنّ شبكة Wi-Fi توفّر إمكانية الوصول إلى الإنترنت.
• [C-1-6] يُنصح بشدة باستخدامها عند الحاجة إلى استخدام طريقة واجهة برمجة التطبيقات ConnectivityManager.reportNetworkConnectivity()، لذا يجب إعادة تقييم الاتصال بالإنترنت على Network، وبعد أن يحدّد التقييم أنّ Network الحالي لم يعد يوفّر إمكانية الاتصال بالإنترنت، يمكنك التبديل إلى أي شبكة أخرى متاحة (مثل بيانات الجوّال) توفّر الاتصال بالإنترنت.
• [C-SR] يُنصح بشدة بإجراء عنوان MAC للمصدر ورقم تسلسل إطارات طلبات الفحص عشوائيًا، مرة في بداية كل عملية فحص، بينما يتم فصل STA.
  • يجب أن تستخدم كل مجموعة من إطارات طلبات الفحص التي تتألف من عملية فحص واحدة عنوان MAC واحدًا متسقًا (يجب ألا يتم توزيع عنوان MAC عشوائيًا في منتصف عملية الفحص).
  • يجب تكرار رقم تسلسل طلب الفحص كالمعتاد (بشكل تسلسلي) بين طلبات الفحص في الفحص.
  • يجب أن يتم ترتيب رقم تسلسل طلب الفحص عشوائيًا بين طلب الفحص الأخير في الفحص وطلب الفحص الأول في عملية الفحص التالية.
• [C-SR] يُنصَح باستخدامه بشكل كبير، بينما تكون STA غير متصلة، للسماح بالعناصر التالية فقط في إطارات طلبات التحقيق:
  • مجموعة معلمات SSID (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 (WIFI_MODE_FULL_LOW_LATENCY) أقل من وقت الاستجابة أثناء وضع "قفل الأداء العالي لشبكة Wi-Fi" (WIFI_MODE_FULL_HIGH_PERF).
• [C-SR] يُنصح بشدة بتقليل وقت استجابة Wi-Fi ذهابًا وإيابًا عند الحصول على قفل وقت الاستجابة المنخفض (WIFI_MODE_FULL_LOW_LATENCY) وتفعيله.

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

• [C-2-1] يجب أن يتيح للمستخدم تفعيل/إيقاف القيمة المقروءة من خلال طريقة واجهة برمجة التطبيقات WifiManager.isScanAlwaysAvailable.

7.4.2.1. اتصال Wi-Fi مباشر

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

• يجب أن يشمل ذلك الدعم لاتصال Wi-Fi المباشر (شبكة Wi-Fi من نظير إلى نظير).

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

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

7.4.2.2. إعداد رابط مباشر عبر أنفاق شبكة Wi-Fi

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

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

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

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

7.4.2.3. التعرُّف على شبكة Wi-Fi

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

• يجب أن تتوافق مع خدمة Wi-Fi Aware.

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

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

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

• [C-2-1] يجب تنفيذ واجهات برمجة التطبيقات لميزة "اكتشاف المواقع الجغرافية": setRangingEnabled وsetMinDimensionMm وsetMaxSpaceMm وonServiceDiscoveredWithinRange.

7.4.2.4. نقطة مرور Wi-Fi

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

• يجب أن يتوافق مع نقطة مرور Wi-Fi.

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

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

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

• [C-2-1] يجب أن يظهر UnsupportedOperationException في تنفيذ واجهات برمجة تطبيقات WifiManager المرتبطة بنقطة المرور.

7.4.2.5. موقع Wi-Fi (وقت الذهاب والعودة عند الاتصال بشبكة Wi-Fi: ميزة "المراسلة النصية في الوقت الفعلي")

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

• يجب أن تتوافق مع ميزة الموقع الجغرافي لشبكة Wi-Fi.

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

• [C-1-1] يجب أن ينفِّذ واجهات برمجة تطبيقات WifiRttManager كما هو موضّح في مستندات حزمة تطوير البرامج (SDK).
• [C-1-2] يجب أن يعلن عن علامة الميزة android.hardware.wifi.rtt.
• [C-1-3] يجب أن عشوائيًا عنوان MAC المصدر لكل سلسلة رسائل RTT يتم تنفيذها عندما تكون واجهة Wi-Fi التي يتم تنفيذ ميزة "المراسلة النصية في الوقت الفعلي" عليها غير مرتبطة بنقطة وصول.

7.4.2.6. إيقاف نقل بيانات شبكة Wi-Fi Keepalive

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

• يجب أن يشمل ذلك الدعم لنقل بيانات رسالة التحقُّق من الاتصال بشبكة Wi-Fi.

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

• [C-1-1] يجب أن يتوافق مع واجهة برمجة تطبيقات SocketKeepAlive.

• [C-1-2] يجب أن يتوفّر على الأقل ثلاث خانات متزامنة للبقاء على الاتصال عبر شبكة Wi-Fi ومنفذ واحد على الأقل لرسالة التحقّق من الاتصال عبر شبكة الجوّال.

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

• [C-2-1] يجب أن يعرض ERROR_UNSUPPORTED.

7.4.2.7. الاتصال السهل عبر Wi-Fi (بروتوكول توفير المتطلبات اللازمة للأجهزة)

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

• يجب أن يتوافق مع بروتوكول Wi-Fi Easy Connect (DPP).

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

• [C-1-1] يجب أن ينفِّذ واجهات برمجة تطبيقات Intent Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI كما هو موضّح في مستندات حزمة تطوير البرامج (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] يجب أن يتوافق مع Bluetooth 4.2 وBluetooth LE Data Length.

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

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

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

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

• يجب أن يُعلِن [C-3-1] عن ميزة الأجهزة "android.hardware.bluetooth_le".
• [C-3-2] يجب تفعيل واجهات برمجة تطبيقات البلوتوث المستندة إلى GATT (الملف الشخصي للسمات العامة) كما هو موضح في مستندات حزمة تطوير البرامج (SDK) وandroid.Bluetooth.
• [C-3-3] يجب أن يبلغ القيمة الصحيحة لـ BluetoothAdapter.isOffloadedFilteringSupported() للإشارة إلى ما إذا كان منطق الفلترة لفئات واجهة برمجة التطبيقات ScanFilter قد تم تنفيذه.
• [C-3-4] يجب الإبلاغ عن القيمة الصحيحة لـ BluetoothAdapter.isMultipleAdvertisementSupported() للإشارة إلى ما إذا كانت إعلانات Low Energy Advertising متاحة.
• يجب أن تتوافق مع إلغاء تحميل منطق الفلترة إلى مجموعة شرائح البلوتوث عند تنفيذ ScanFilter API.
• يجب أن يتيح تحميل المسح المجمَّع إلى شريحة البلوتوث.

• يجب أن يدعم الإعلان المتعدد في 4 خانات على الأقل.

• [SR] يُنصَح بشدة بتنفيذ مهلة عنوان خاص قابل للتحليل لا تزيد عن 15 دقيقة وتدوير العنوان عند انتهاء المهلة لحماية خصوصية المستخدم.

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

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

إذا كانت عمليات تنفيذ الأجهزة تتضمّن توافقًا مع البلوتوث المنخفض الطاقة وملف تعريف سماعات الأذن الطبية (Hearing Aids Profile) كما هو موضَّح في مقالة Hearing Aid Audio Support باستخدام 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 حتى إذا لم يتوافقا مع تقنية الاتصال القصير المدى (NFC) أو تشيران إلى ميزة android.hardware.nfc بأنّ الفئات تمثّل تنسيقًا لتمثيل البيانات مستقلاً عن البروتوكول.

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

• [C-1-1] يجب الإبلاغ عن الميزة android.hardware.nfc من خلال طريقة android.content.pm.PackageManager.hasSystemFeature().
• يجب أن تكون قادرًا على قراءة رسائل NDEF وكتابتها عبر معايير NFC التالية على النحو التالي:
• [C-1-2] يجب أن يكون قادرًا على العمل كقارئ أو كاتب منتدى NFC (على النحو المحدد في المواصفات الفنية لمنتدى NFCForum-TS-DigitalProtocol-1.0) من خلال معايير NFC التالية:
  • NFCA (ISO14443-3A)
  • NFCB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • أنواع علامات منتدى NFC 1 و2 و3 و4 و5 (يحدّدها منتدى NFC)

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

• [C-1-13] يجب إجراء استطلاع لكل التكنولوجيات المتوافقة أثناء استخدام وضع اكتشاف NFC.

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

تجدر الإشارة إلى أنّ الروابط المتاحة للجميع لا تتوفّر لمواصفات منتدى JIS وISO وNFC المذكورة أعلاه.

يتيح Android استخدام وضع محاكاة بطاقة مضيف NFC (HCE).

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

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

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

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

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

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

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

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

• [C-0-1] يجب أن يتضمن الدعم لشكل واحد أو أكثر من أشكال شبكات البيانات. على وجه التحديد، يجب أن تتضمن عمليات تنفيذ الأجهزة التوافق مع معيار بيانات واحد على الأقل قادر على 200 كيلوبت في الثانية أو أكثر. تشمل أمثلة التكنولوجيات التي تستوفي هذا الشرط EDGE وHSPA وEV-DO و802.11g وإيثرنت ورقم 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 تستخدم عمر RAW لا يقل عن 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] يجب أن يتأكد من أنّ تطبيق الكاميرا التلقائي المثبَّت مسبقًا الذي يتعامل مع عناصر intent 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] يجب عدم استخدام كاميرا أمامية كإعداد تلقائي لواجهة برمجة التطبيقات للكاميرا، ويجب عدم ضبط واجهة برمجة التطبيقات للتعامل مع الكاميرا الأمامية كالكاميرا الخلفية التلقائية، حتى لو كانت الكاميرا الوحيدة على الجهاز.
• [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 (UVC 1.0 أو الإصدارات الأحدث) في حال اتصال الكاميرا الخارجية من خلال منفذ مضيف USB.
• [C-1-3] يجب اجتياز اختبارات CTS للكاميرا باستخدام جهاز كاميرا خارجي متصل. تتوفّر تفاصيل اختبار CTS للكاميرا على source.android.com.
• يجب أن يتيح ضغط الفيديو مثل MJPEG لنقل عمليات البث عالية الجودة غير المرمّزة (أي مجموعات بث الصور الأولية أو المضغوطة بشكل مستقل).
• قد تتوافق مع عدة كاميرات.
• قد يتم دعم ترميز الفيديو المستند إلى الكاميرا.

إذا كان ترميز الفيديو المستند إلى الكاميرا متوافقًا:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.8. الصوت

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

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

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

إذا حذفَت عمليات تنفيذ الجهاز ميكروفونًا، سيحدث ما يلي:

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

7.8.2 إخراج الصوت

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

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

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

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

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

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

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

• [C-SR] يُنصح بشدة بأن يتضمّن منفذًا واحدًا على الأقل من منافذ الصوت ليكون مقبس صوت بأبعاد 4 موصّلات مقاس 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] يُنصح بشدّة لإتاحة تسجيل الصوت من سماعات رأس استيريو تتضمّن ميكروفونًا.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقبس صوت مقاس 4 موصّلات مقاس 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 هي "صحيح"، يجب استيفاء المتطلبات التالية في مصدرَي الصوت VOICE_RECOGNITION وUNPROCESSED:

• [C-1-1] يجب ألا تتجاوز استجابة طاقة الميكروفون في النطاق بين 18.5 كيلوهرتز إلى 20 كيلوهرتز أكثر من 15 ديسيبل أسفل الاستجابة عند 2 كيلوهرتز.
• [C-1-2] يجب ألا تقل نسبة الإشارة إلى الضوضاء غير المرجحة في الميكروفون عن 18.5 إلى 20 كيلوهرتز بالنسبة إلى نغمة 19 كيلوهرتز عند -26 ديسيبل، يجب ألا تقل عن 50 ديسيبل.

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

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

وضع الأداء	المشاركة	معدّل النسبة المئوية خارج العينة	في تشان	ترانيم الفرقعة
وقت استجابة سريع	حصري	غير محدّد	1	2
وقت استجابة سريع	حصري	غير محدّد	2	1
وقت استجابة سريع	مشترك	غير محدّد	1	2
وقت استجابة سريع	مشترك	غير محدّد	2	1
لم يتم اختيار لون	مشترك	48000	1	2
لم يتم اختيار لون	مشترك	48000	2	1
لم يتم اختيار لون	مشترك	44100	1	2
لم يتم اختيار لون	مشترك	44100	2	1
لم يتم اختيار لون	مشترك	16000	1	2
لم يتم اختيار لون	مشترك	16000	2	1

يجب أن يستوفي البث الموثوق به المعايير التالية المتعلّقة بنسبة الإشارة إلى الضوضاء (SNR) والتشوّه التوافقي الكلي (THD) لصوت الجيب بقوة 2000 هرتز.

محوّل طاقة	60	معدّل الضوضاء الديناميكي
مكبّر صوت أساسي مدمج، يتم قياسه باستخدام ميكروفون مرجعي خارجي	< 3.0%	>= 50 ديسيبل
ميكروفون أساسي مدمج، يتم قياسه باستخدام مكبّر صوت مرجعي خارجي	< 3.0%	>= 50 ديسيبل
مقابس تناظرية مدمجة مقاس 3.5 ملم، تم اختبارها باستخدام محوّل استرجاعي	أقل من %1	>= 60 ديسيبل
محوّلات USB المرفقة مع الهاتف، وتم اختبارها باستخدام محوّل الاسترجاع	< 1.0%	>= 60 ديسيبل

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

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

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

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

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

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

• [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 تضم اثنين على الأقل.
• [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] يُنصَح بشدة بإتاحة تخصيص AHardwareBuffer مع أكثر من طبقة واحدة وعلامات وتنسيق محدّد في C-1-10
• [C-1-11] يجب أن يتيح فك ترميز H.264 بمعدّل لا يقل عن 3840 × 2160 ميغابت في الثانية بمعدّل 30 لقطة في الثانية، مضغوطًا إلى متوسط 40 ميغابت في الثانية (ما يعادل 4 نُسخ من الفيديو بتنسيق 1920 × 1080 بمعدّل 30 لقطة في الثانية - 10 ميغابت في الثانية أو نسختَين من 1920 × 1920 × 4 مثيل).
• [C-1-12] يجب أن يتوافق مع HEVC وVP9، ويجب أن يكون قادرًا على فك الترميز بمعدّل لا يقل عن 1920 × 1080 ميغابت في الثانية بمعدّل 1920 × 1080 ميغابت في الثانية بمعدل 10 ميغابت في الثانية ومعدّل 10 ميغابت في الثانية، ومن المفترض أن يكون قادرًا على فك الترميز 3840 × 2160 بمعدل 30 لقطة في الثانية - 20 ميغابت في الثانية.
• [C-1-13] يجب أن يتوافق مع واجهة برمجة التطبيقات HardwarePropertiesManager.getDeviceTemperatures وأن يعرض قيمًا دقيقة لدرجة حرارة الجلد.
• [C-1-14] يجب أن يحتوي على شاشة مضمّنة، ويجب ألا تقل درجة دقته عن 1920 × 1080.
• [C-SR] يُنصح بشدة بأن تكون دقة العرض 2560 × 1440 على الأقل.
• [C-1-15] يجب أن يتم تحديث الشاشة بتردد 60 هرتز على الأقل أثناء استخدام وضع الواقع الافتراضي (VR).
• [C-1-17] يجب أن تكون الشاشة متوافقة مع وضع التدرُّب المنخفض لمدة تقل عن 5 ملي ثانية أو أقل، ويتم تعريفها بأنّها الفترة الزمنية التي تنبعث فيها وحدة البكسل الضوء.
• [C-1-18] يجب أن يتوافق مع Bluetooth 4.2 وملحق Bluetooth LE Data Length الفقرة 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 لعرض أرقام نوى وحدة المعالجة المركزية (CPU) الحصرية للتطبيق الذي يعمل في المقدّمة.

إذا كان الدعم الحصري متاحًا، فإن الطريقة الأساسية:

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

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

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

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

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

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

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

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

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

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

• [C-1-1] يجب ألا يحيد عن تنفيذ AOSP في ما يتعلق بتشغيل خوارزميات التشغيل والصيانة والاستيقاظ واستخدام إعدادات النظام العامة لوضعي وضع الاستعداد للتطبيقات وتوفير الطاقة.
• [C-1-2] يجب ألا تنحرف عن تنفيذ AOSP في ما يتعلق باستخدام الإعدادات العامة لإدارة تقييد المهام والمنبّه والشبكة للتطبيقات في كل حزمة لوضع الاستعداد للتطبيقات.
• [C-1-3] يجب ألا يحيد عن تنفيذ AOSP لعدد حزم تطبيقات وضع الاستعداد المستخدمة في وضع الاستعداد للتطبيقات.
• [C-1-4] يجب تنفيذ حزم تطبيقات وضع الاستعداد وميزة "القيلولة" كما هو موضح في إدارة الطاقة.
• [C-1-5] يجب عرض true للعميل PowerManager.isPowerSaveMode() عندما يكون الجهاز في وضع توفير الطاقة.
• [C-SR] يُنصَح باستخدامها بشدة لتمكين المستخدمين من تفعيل ميزة "توفير شحن البطارية" وإيقافها.
• [C-SR] يُنصَح بشدة بإتاحة إمكانية عرض جميع التطبيقات المستثناة من وضعَي توفير الطاقة في وضع الاستعداد للتطبيقات والقيلولة.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [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. على سبيل المثال، تتطلب TechnicalManager#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] نشاط يعالج نمط النية بالشراء android.settings.ACTION_USAGE_ACCESS_SETTINGS، ولكن يجب تنفيذه في حالة حظر المستخدم، أي سلوك مكافئ لسلوك المستخدم عند رفض وصول المستخدم.

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

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

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

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

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

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

يجب أن تضمن عمليات تنفيذ الأجهزة الامتثال لميزات الأمان في كل من النواة والنظام الأساسي كما هو موضَّح أدناه.

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

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

تعتبر ميزات السلامة والحماية الذاتية في Kernel جزءًا لا يتجزأ من أمان 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] عملية التحقّق من حدود حجم العنصر الثابت والديناميكي في النُسخ بين مساحة المستخدم ومساحة kernel-space (مثل CONFIG_HARDENED_USERCOPY) على الأجهزة التي يتم شحنها في الأصل باستخدام المستوى 28 من واجهة برمجة التطبيقات أو المستويات الأحدث.
• [C-0-10] يجب ألا يتم تنفيذ ذاكرة مساحة المستخدم عند التنفيذ في وضع kernel (مثل PXN للأجهزة، أو التي تتم محاكاتها عبر CONFIG_CPU_SW_DOMAIN_PAN أو CONFIG_ARM64_SW_TTBR0_PAN) على الأجهزة التي يتم شحنها في الأصل بالمستوى 28 من واجهة برمجة التطبيقات أو المستويات الأحدث.
• [C-0-11] يجب ألا تتم قراءة أو كتابة ذاكرة مساحة المستخدم في النواة خارج واجهات برمجة التطبيقات للوصول العادي إلى نسخة المستخدم (مثل رقم الحساب الدائم للأجهزة، أو التي تتم محاكاتها عبر CONFIG_CPU_SW_DOMAIN_PAN أو CONFIG_ARM64_SW_TTBR0_PAN) على الأجهزة التي يتم شحنها في الأصل باستخدام المستوى 28 من واجهة برمجة التطبيقات أو المستويات الأعلى.
• يجب أن ينفِّذ [C-0-12] عزل جدول صفحات النواة إذا كان الجهاز معرَّضًا لـ 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] يُنصَح بشدة بالاحتفاظ ببيانات kernel التي تتم كتابتها فقط أثناء وضع علامة للقراءة فقط بعد الإعداد (مثل __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] يُنصح بشدة بعدم إيقاف Control-Flow Integrity (CFI) أو ميزة Shadow Call Stack (SCS) أو ميزة Integer Overflow Sanitization (IntSan) في المكوّنات التي تم تفعيلها.
• [C-SR] يُنصَح بشدة بتفعيل CFI وSCS وIntSan لأي مكوّنات إضافية في مساحة المستخدم حسّاسة للأمان كما هو موضّح في CFI وIntSan.

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

• [C-1-1] يجب تنفيذ SELinux.
• [C-1-2] يجب تعيين SELinux على وضع الفرض العام.
• [C-1-3] يجب إعداد جميع النطاقات في وضع الفرض. ولا يُسمح بالنطاقات الخاصة بوضع التساهل، بما في ذلك النطاقات الخاصة بجهاز أو مورِّد.
• [C-1-4] يجب ألا يجري تعديل أو حذف أو استبدال قواعد findallow الموجودة في مجلد System/sepolicy المقدَّم في "مشروع مفتوح المصدر لنظام Android" (AOSP) والسياسة يجب أن يتم تجميعها مع جميع القواعد "Neverallow" (عدم السماح أبدًا) لنطاقات AOSP SELinux والنطاقات الخاصة بالأجهزة/المورّدين.
• [C-1-5] يجب تشغيل تطبيقات الجهات الخارجية التي تستهدف المستوى 28 من واجهة برمجة التطبيقات أو المستويات الأعلى في وضع الحماية الخاص بـ SELinux لكل تطبيق مع فرض قيود SELinux على كل تطبيق على دليل البيانات الخاص لكل تطبيق.
• "يجب أن" يتم الاحتفاظ بسياسة SELinux التلقائية المتوفّرة في مجلد system/sepolicy ضمن "المشروع المفتوح المصدر لنظام Android" الرئيسي وإضافة المزيد من هذه السياسة إلى هذه السياسة من أجل عملية الإعداد الخاصة بالجهاز.

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

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

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

يحتوي Android على العديد من ميزات الدفاع العميق التي تشكِّل جزءًا لا يتجزأ من أمان الجهاز.

9.8. الخصوصية

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

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

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

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

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

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

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

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

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

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

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

• [C-0-3] يجب إرسال إشعار مستمر للمستخدم أثناء تفعيل بث الشاشة أو تسجيل الشاشة. وتستوفي خدمة AOSP هذا الشرط من خلال عرض رمز إشعار مستمر في شريط الحالة.

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

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

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

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

9.8.3. إمكانية الاتصال

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

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

9.8.4. حركة بيانات الشبكة

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

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

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

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

• [C-0-1] يجب ألا يفعّل أو يوقف إعداد الموقع الجغرافي للجهاز وإعدادات البحث عن شبكات Wi-Fi/البلوتوث بدون موافقة صريحة من المستخدم أو بدء المستخدم.
• [C-0-2] يجب أن تتوفر للمستخدم إمكانية الوصول إلى المعلومات المتعلقة بالموقع الجغرافي، بما في ذلك طلبات الموقع الجغرافي الأخيرة والأذونات على مستوى التطبيق واستخدام البحث عن شبكات Wi-Fi والبلوتوث لتحديد الموقع الجغرافي.
• [C-0-3] يجب أن يتأكّد من أنّ التطبيق الذي يستخدم واجهة برمجة التطبيقات "واجهة برمجة التطبيقات لتجاوز الموقع في حالات الطوارئ" [LocationRequest.setLocationSettingsDetailsd()] هو جلسة طوارئ يبدأها المستخدم (مثلاً، الاتصال برقم 911 أو إرسال رسالة نصية إلى الرقم 911).
• [C-0-4] يجب الحفاظ على إمكانية تجاوز إعدادات الموقع الجغرافي للجهاز بدون تغيير الإعدادات من واجهة برمجة التطبيقات Virtual 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] يجب استخدام ميزة "التشغيل المتحقّق منه" والتأكّد من أنّ مفاتيح DE ترتبط بالتشفير بجذر ثقة جهاز الجهاز.
• [C-1-5] يجب تشفير محتوى الملف باستخدام AES-256-XTS أو Adiantum. يشير معيار AES-256-XTS إلى معيار التشفير المتقدِّم بطول مفتاح تشفير 256 بت، ويتم تشغيله في وضع XTS. فإن الطول الكامل للمفتاح هو 512 بت. يشير مصطلح "Adiantum" إلى 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] يجب أن يكون مرتبطًا بالتشفير بوحدة تخزين مفاتيح مدعومة بالأجهزة.

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

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

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

يوفّر المشروع المفتوح المصدر لنظام Android التنفيذ المفضّل لهذه الميزة استنادًا إلى نواة Linux ("fscrypt") تشفير المشروع.

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 Verification API.

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

• [C-3-1] يجب الإبلاغ عن true لواجهة برمجة تطبيقات ConfirmationPrompt.isSupported().

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

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

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

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

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

عندما يكون تنفيذ الجهاز متوافقًا مع شاشة قفل آمنة:

• [C-1-1] يجب إجراء نسخ احتياطي لتنفيذ ملف تخزين المفاتيح في بيئة تنفيذ معزولة.
• يجب أن يتضمن [C-1-2] تطبيقات لخوارزميات التشفير RSA وAES وECDSA وHMAC، بالإضافة إلى وظائف التجزئة MD5 وSHA1 وSHA-2 للتوافق بشكل مناسب مع الخوارزميات المتوافقة مع نظام Android Keystore في منطقة معزولة بشكل آمن عن الرمز الذي يعمل على النواة والإصدارات الأحدث. يجب أن تحظر ميزة العزل الآمن جميع الآليات المحتملة التي من خلالها قد يصل رمز النواة أو رمز مساحة المستخدم إلى الحالة الداخلية للبيئة المعزولة، بما في ذلك قانون الأسواق الرقمية. يفي "المشروع المفتوح المصدر لنظام Android" (AOSP) بهذا الشرط من خلال استخدام تنفيذ Trusty، إلا أنّ الخيارات البديلة المتاحة هي أحد الحلول الأخرى المستندة إلى ARM TrustZone أو إحدى الجهات الخارجية التي تمت مراجعتها وفقًا لعزلة مناسبة تستند إلى برنامج Hypervisor (مراقب الأجهزة الظاهرية).
• يجب إجراء مصادقة شاشة القفل في بيئة التنفيذ المعزولة [C-1-3] والسماح باستخدام المفاتيح المرتبطة بالمصادقة فقط. يجب تخزين بيانات اعتماد شاشة القفل بطريقة تسمح فقط لبيئة التنفيذ المعزولة بإجراء مصادقة شاشة القفل. يوفّر "المشروع المفتوح المصدر لنظام Android" الرئيسي طبقة استخلاص أجهزة 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] يجب ألا تحلّ طريقة المصادقة الجديدة محلّ أي طريقة من طرق المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي والنمط وكلمة المرور) التي تم تنفيذها وتقديمها في "بروتوكول 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] يجب إيقاف الطريقة الجديدة والسماح فقط باستخدام إحدى طرق المصادقة الأساسية المقترَحة لفتح قفل الشاشة عندما يضبط تطبيق وحدة التحكّم بسياسة الجهاز (DPC) السياسة باستخدام الطريقة 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 أو جهاز 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] يجب ألا يسمح لموظّفي الدعم الموثوق بهم على الأجهزة الشخصية الأساسية (مثل حمل الجهاز باليد) بفتح قفل الجهاز، ولا يمكنهم استخدامه إلا للاحتفاظ بجهاز غير مقفَل مسبقًا في حالة فتح القفل لمدة تصل إلى 4 ساعات كحد أقصى. يستوفي التنفيذ التلقائي لـ TrustManagerService في AOSP هذا الشرط.
• [C-7-12] يجب أن يستخدم قناة اتصال آمنة من ناحية التشفير (مثل UKEY2) لتمرير رمز الضمان من جهاز التخزين إلى الجهاز المستهدف.

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

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

9.11.2. جهاز strongBox

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

• يجب أن يحتوي [C-1-5] على ساعة داخلية بدقة معقولة (+-10%) تكون محصنة من التلاعب بواسطة AP.

• يجب أن يحتوي [C-1-6] على أداة إنشاء أرقام عشوائية حقيقية تُنتج مخرجات موزّعة بشكل موحّد وغير متوقعة.

• يجب أن يكون لدى [C-1-7] مقاومة للتلاعب، بما في ذلك مقاومة الاختراق الجسدي والأعطال.

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

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

• للتحقّق من الامتثال لمعيار [C-1-3] إلى [C-1-9]، يجب تنفيذ ما يلي:

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

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

تم تصميم 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)" يتم تحديثها بلا اتصال بالإنترنت عن طريق إعادة التشغيل.
  • يتم تحديث "Tethered" عبر USB من جهاز كمبيوتر مضيف.
  • يتم تحديث "بلا اتصال بالإنترنت" عن طريق إعادة التشغيل والتحديث من ملف على وحدة تخزين قابلة للإزالة.

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

• [C-0-3] يجب أن يتم توقيع التحديث بالكامل ويجب أن تتحقّق آلية التحديث على الجهاز من التحديث والتوقيع على مفتاح عام مخزَّن على الجهاز.

• [C-SR] يُنصَح بشدة باستخدام آلية التوقيع لتجزئة التحديث باستخدام SHA-256 والتحقق من صحة التجزئة وفقًا للمفتاح العام باستخدام معيار ECDSA NIST P-256.

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

• [C-1-1] يجب إتاحة عمليات التنزيل عبر الهواء مع التحديث بلا اتصال بالإنترنت عن طريق إعادة التشغيل.

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

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

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

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

يتضمن Android ميزات تسمح لتطبيق "مالك الجهاز" (إذا كان متوفرًا) بالتحكّم في تثبيت تحديثات النظام. إذا أبلغ النظام الفرعي لتحديث النظام للأجهزة عن android.software.device_admin حينها، سيتم:

• يجب أن ينفِّذ [C-3-1] السلوك الموضّح في الفئة SystemUpdatePolicy.

12. سجل التغييرات في المستند

للحصول على ملخص بالتغييرات التي طرأت على تعريف التوافق في هذا الإصدار:

• سجلّ تغييرات المستند

للحصول على ملخص للتغييرات التي تطرأ على أقسام الأفراد:

1. المقدّمة
2. أنواع الأجهزة
3. البرامج
4. حزمة التطبيقات
5. الوسائط المتعددة
6. أدوات المطوّرين وخياراتهم
7. توافق الأجهزة
8. الأداء والقوة
9. نموذج الأمان
10. اختبار التوافق مع البرامج
11. برامج Updatable
12. سجلّ تغييرات المستند
13. التواصل معنا

12.1. نصائح حول عرض سجلّ التغييرات

ويتم تمييز التغييرات على النحو التالي:

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

• مستندات
  مستحضرات التجميل أو التغييرات ذات الصلة.

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

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

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