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

1. مقدّمة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • أن يكون مزوّدًا بمصدر طاقة يتيح إمكانية التنقل، مثل بطارية
  • أن يكون حجم الشاشة القطري الفعلي في النطاق الذي يتراوح بين 4 بوصة 3.3 بوصة (أو 2.5 بوصة لعمليات تنفيذ الأجهزة التي تم شحنها بالإصدار 29 من واجهة برمجة التطبيقات أو إصدار سابق) و8 بوصة
  • أن تتضمّن واجهة إدخال تعمل باللمس:

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

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

2.2.1. الأجهزة

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

  • [7.1.1.1/H-0-1] يجب أن يكون الجهاز مزوّدًا بشاشة متوافقة مع Android على الأقل تستوفي جميع المتطلبات описанة في هذا المستند. يجب أن يكون حجم الشاشة 5.6 سم على الأقل على الحافة القصيرة و8.6 سم على الحافة الطويلة.
  • [7.1.1.3/H-SR-1] يُنصح بشدة بمنح المستخدمين إمكانية تغيير حجم الشاشة (كثافة الشاشة).

  • [7.1.1.1/H-0-2] يجب أن تتيح وحدة معالجة الرسومات إنشاء ملف تعريف رسومات بحجم لا يقل عن أعلى درجة دقة لأي شاشة مدمجة.

بدء متطلبات جديدة

  • [7.1.1.1/H-0-3]* يجب ربط كل UI_MODE_NORMAL شاشة متوفّرة للتطبيقات التابعة لجهات خارجية بمنطقة شاشة جسدية بدون عائق مساحتها 5.6 سم على الأقل على الحافة القصيرة و8.6 سم على الحافة الطويلة.

  • [7.1.1.3/H-0-1]* يجب ضبط قيمة DENSITY_DEVICE_STABLE لتكون ‎92% أو أعلى من الكثافة الفعلية للشاشة المقابلة.

إنهاء المتطلبات الجديدة

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

  • [7.1.1.1/H-1-1]* يجب أن تكون الشاشة المنطقية التي تتوفّر لتطبيقات الجهات الخارجية لا تقلّ عن 5.08 سم على ناحية الجانب القصير و6.86 سم على ناحية الجانب الطويل. قد يتم استثناء الأجهزة التي تم شحنها باستخدام المستوى 29 أو إصدار أقدم من واجهة برمجة التطبيقات (API) من هذا الشرط.

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

  • [7.1.1.1/H-2-1]* يجب أن تكون الشاشة المنطقية التي تتوفّر للتطبيقات التابعة لجهات خارجية 2.7 بوصة على الأقل على الحواف القصيرة. قد يتم استثناء الأجهزة التي تم شحنها باستخدام المستوى 29 أو إصدار أقدم من واجهة برمجة التطبيقات (API) من هذا الشرط.

بدء متطلبات جديدة

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

إنهاء المتطلبات الجديدة

إذا كانت عمليات تنفيذ الأجهزة الجوّالة تدّعي توفّر شاشات مزوّدة بتقنية النطاق العالي الديناميكية من خلال 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.4.6/H-0-1] يجب الإبلاغ عمّا إذا كان الجهاز يتوافق مع ميزة إعداد ملفّات تعريف وحدة معالجة الرسومات من خلال خاصيّة نظام graphics.gpu.profiler.support.

إذا كانت عمليات تنفيذ الأجهزة الجوّالة تعلن عن التوافق من خلال خاصية نظام graphics.gpu.profiler.support، يجب أن تستوفي الشروط التالية:

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

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

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

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

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

  • [7.3.3/H-2-1] يجب الإبلاغ عن قياسات GNSS فور العثور عليها، حتى إذا لم يتم الإبلاغ عن موقع جغرافي تم احتسابه من نظام تحديد المواقع العالمي (GPS) أو نظام تحديد المواقع العالمي عبر الأقمار الصناعية (GNSS) بعد.
  • [7.3.3/H-2-2] يجب الإبلاغ عن نطاقات GNSS الزائفة ومعدّلات النطاق الزائف، والتي تكون كافية لاحتساب الموقع الجغرافي ضمن 20 مترًا والسرعة ضمن 0.2 متر في الثانية في ‎95% من الوقت على الأقل، وذلك في ظروف السماء المفتوحة بعد تحديد الموقع الجغرافي، سواء كان الجهاز مثبّتًا أو متحركًا بمعدّل تسارع أقل من 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-1] يُنصح بشدة بتوفير ميزة استشعار الوضع باستخدام 6 درجات من الحرية.
  • [7.4.3/H] يجب أن يتضمّن الإصدار تقنية البلوتوث وتكنولوجيا ‎Bluetooth LE.

إذا كانت الأجهزة متوافقة مع بروتوكول WiFi Neighbor Awareness Networking (NAN) من خلال إعلامهاPackageManager.FEATURE_WIFI_AWARE وموقع Wi-Fi (Wi-Fi Round Trip Time - RTT) من خلال إعلامهاPackageManager.FEATURE_WIFI_RTT، فإنّها:

  • [7.4.2.5/H-1-1] يجب أن يُبلغ الجهاز عن النطاق بدقة وبمقدار +/-1 متر عند عرض النطاق 160 ميغاهرتز في الشريحة المئوية 68 (كما يتم احتسابه باستخدام دالة التوزيع التجميعي)، وبمقدار +/-2 متر عند عرض النطاق 80 ميغاهرتز في الشريحة المئوية 68، وبمقدار +/-4 متر عند عرض النطاق 40 ميغاهرتز في الشريحة المئوية 68، وبمقدار +/-8 متر عند عرض النطاق 20 ميغاهرتز في الشريحة المئوية 68 على مسافات 10 سم و1 متر و3 أمتار و5 أمتار، كما تم رصده من خلال WifiRttManager#startRanging Android API.

  • [7.4.2.5/H-SR-1] يُنصح بشدة بالإبلاغ عن النطاق بدقة ضمن نطاق ±1 متر عند عرض النطاق 160 ميغاهرتز عند المائة المئوية التسعون (كما تم احتسابه باستخدام دالة التوزيع التراكمي)، و ±2 متر عند عرض النطاق 80 ميغاهرتز عند المائة المئوية التسعون، و ±4 متر عند عرض النطاق 40 ميغاهرتز عند المائة المئوية التسعون، و ±8 متر عند عرض النطاق 20 ميغاهرتز عند المائة المئوية التسعون على مسافات 10 سم، كما لوحظ من خلال WifiRttManager#startRanging Android API.

ننصحك بشدة باتّباع خطوات إعداد القياس المحدّدة في مقالة معايرة بيانات الحضور.

بدء متطلبات جديدة

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

  • [7.4.3/H-1-3] يجب قياس ناتج Rx المعدَّل وتعويضه لضمان أن يكون متوسّط RSSI لتقنية BLE هو -50 ديسي بل +/-15 ديسي بل على مسافة 1 متر من جهاز مرجعي يُرسِل البيانات بسرعة ADVERTISE_TX_POWER_HIGH.
  • [7.4.3/H-1-4] يجب قياس ناتج الإرسال المتغيّر وتعويضه لضمان أن يكون متوسّط مؤشر RSSI لتقنية BLE هو -50 ديسي بل +/-15 ديسي بل عند البحث من جهاز مرجعي على مسافة متر واحد ويُرسِل البيانات بسرعة ADVERTISE_TX_POWER_HIGH.

إنهاء المتطلبات الجديدة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [7.6.1/H-SR-1] يُنصح بشدة بتوفير مساحة المستخدم بنظام 32 بت فقط (كل من التطبيقات ورموز النظام)

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

  • [7.6.1/H-1-1] يجب أن تتوافق مع واجهة برمجة تطبيقات ثنائية واحدة فقط (إما 64 بت فقط أو 32 بت فقط).

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

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

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

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

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

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

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

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

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

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

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

  • [7.8.2.2/H-1-1] يجب توفير ربط البرامج التالي لرموز HID:
الوظيفة عمليات الربط السياق السُلوك
A صفحة استخدام HID: 0x0C
استخدام HID: 0x0CD
مفتاح kernel: 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
مفتاح kernel: KEY_VOLUMEUP
مفتاح Android: VOLUME_UP
تشغيل الوسائط، مكالمة جارية الإدخال: الضغط لفترة قصيرة أو طويلة
الإخراج: رفع مستوى صوت النظام أو سماعة الرأس
C صفحة استخدام HID: 0x0C
استخدام HID: 0x0EA
مفتاح kernel: KEY_VOLUMEDOWN
مفتاح Android: VOLUME_DOWN
تشغيل الوسائط، مكالمة جارية الإدخال: الضغط لفترة قصيرة أو طويلة
الإخراج: خفض مستوى صوت النظام أو سماعة الرأس
D صفحة استخدام HID: 0x0C
استخدام HID: 0x0CF
مفتاح kernel: 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 لسمة "microphone" الإضافية.

عند رصد أنواع وحدات تحكّم الصوت عبر USB‏ 0x0402، يتم تنفيذ ما يلي:

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

عند استدعاء واجهة برمجة التطبيقات 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-1] يُنصح بشدة عند توصيل جهاز محيطي للصوت بمنفذ USB-C بإجراء عملية سرد لموصّفات USB وتحديد أنواع المحطات وبث Intent ACTION_HEADSET_PLUG في أقل من 1000 ملي ثانية.

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

  • [5.6/H-1-1] يجب أن يكون متوسّط وقت الاستجابة المستمر للرحلة المتبادلة 300 ملي ثانية أو أقل على مدار 5 قياسات، مع متوسّط انحراف مطلق أقل من 30 ملي ثانية، على مدار مسارات البيانات التالية: "مكبّر الصوت إلى الميكروفون"، محوّل حلقة 3.5 ملم (في حال توفّره)، حلقة USB (في حال توفّرها).

  • [5.6/H-1-2] يجب أن يكون متوسّط وقت استجابة النقر إلى النغمة 300 ملي ثانية أو أقل على مدار 5 قياسات على الأقل على مسار بيانات مكبّر الصوت إلى الميكروفون.

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

المحرّك الخطي للمعايرة (LRA) هو نظام زنبرك ذو كتلة واحدة يمتلك ترددًا مميّزًا للمعايرة حيث تتحرك الكتلة في اتجاه الحركة المطلوبة.

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

بدء متطلبات جديدة

  • [7.10/ح] يجب وضع المحرِّك بالقرب من الموقع الذي يتم عادةً فيه حمل الجهاز أو لمسه باليدين.

إنهاء المتطلبات الجديدة

  • [7.10/ساعة] من المفترض أن يحرك المحرِّك اللمسي على محور X (من اليمين إلى اليسار) في الوضع الطبيعي العمودي للجهاز.

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

  • [7.10/ساعة] يجب أن يكون تردد الرنين لوحدة LRA في محور X أقل من 200 هرتز.

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

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 Profile (AAC LC)
  • [5.1/H-0-4] MPEG-4 HE AAC Profile (AAC+)
  • [5.1/H-0-5] ‫AAC ELD (ترميز AAC المحسّن المنخفض التأخير)

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

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

بدء متطلبات جديدة

  • [5.2/H-0-3] AV1

إنهاء المتطلبات الجديدة

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

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

بدء متطلبات جديدة

  • [5.3/H-0-6] AV1

إنهاء المتطلبات الجديدة

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.2.3.1/H-0-2]* يجب تحميل تطبيقات أو مكونات خدمة واحدة أو أكثر مزوّدة بمعالج للطلبات، وذلك لتطبيق جميع أنماط فلاتر الطلبات العامة التي تحدّدها طلبات التطبيق التالية المدرَجة هنا.
  • [3.2.3.1/H-SR-1] يُنصح بشدة بتحميل تطبيق بريد إلكتروني مسبقًا يمكنه معالجة نوايا ACTION_SENDTO أو ACTION_SEND أو ACTION_SEND_MULTIPLE لإرسال رسالة إلكترونية.
  • [3.4.1/H-0-1] يجب أن يوفّر التطبيق تنفيذًا كاملاً لواجهة برمجة تطبيقات android.webkit.Webview.
  • [3.4.2/H-0-1] يجب أن يتضمّن التطبيق متصفحًا مستقلاً لتصفّح الويب من قِبل المستخدمين بشكل عام.
  • [3.8.1/H-SR-1] يُنصح بشدة باستخدام مشغّل افتراضي يتيح تثبيت الاختصارات والتطبيقات المصغّرة وwidgetFeatures داخل التطبيق.
  • [3.8.1/H-SR-2] يُنصح بشدة باستخدام مشغّل افتراضي يتيح الوصول السريع إلى ال اختصارات إضافية التي تقدّمها التطبيقات التابعة لجهات خارجية من خلال واجهة برمجة التطبيقات ShortcutManager.
  • [3.8.1/H-SR-3] يُنصح بشدة بتضمين تطبيق مشغّل تلقائي يعرض شارات لرمز التطبيق.
  • [3.8.2/H-SR-1] يُنصح بشدة بإتاحة التطبيقات المصغّرة التابعة لجهات خارجية.
  • [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] يجب أن يتضمّن ظلّ الإشعارات، ما يمنح المستخدم إمكانية التحكّم مباشرةً في الإشعارات (مثل الردّ أو الإيقاف المؤقت أو الإغلاق أو الحظر) من خلال ميزات مساعدة المستخدم، مثل buttons buttons أو لوحة التحكّم كما هو مُطبَّق في AOSP.
  • [3.8.3/H-0-5] يجب عرض الخيارات المقدَّمة من خلال RemoteInput.Builder setChoices() في مركز الإشعارات.
  • [3.8.3/H-SR-1] يُنصح بشدة بعرض الخيار الأول المقدَّم من خلال RemoteInput.Builder setChoices() في نافذة الإشعارات بدون تفاعل إضافي من المستخدم.
  • [3.8.3/H-SR-2] يُنصح بشدة بعرض جميع الخيارات المقدَّمة من خلال RemoteInput.Builder setChoices() في مركز الإشعارات عندما يوسّع المستخدم جميع الإشعارات في مركز الإشعارات.
  • [3.8.3.1/H-SR-1] يُنصح بشدة بعرض الإجراءات التي تم ضبط Notification.Action.Builder.setContextual على أنّها true مع الردّات التي يعرضها Notification.Remoteinput.Builder.setChoices.
  • [3.8.4/H-SR-1] يُنصح بشدة بتنفيذ مساعد على الجهاز لمعالجة الإجراء المساعد.

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

  • [3.8.3.1/H-SR-2] يُنصح بشدة بتوفير ميزة للمستخدم (مثل مبدِّل الإخراج) يمكن الوصول إليه من واجهة مستخدم النظام، ما يسمح للمستخدمين بالتبديل بين مسارات الوسائط المتاحة المناسبة (مثل أجهزة Bluetooth والمسارات المقدَّمة لتطبيق MediaRouter2Manager) عندما ينشر أحد التطبيقات إشعارًا MediaStyle يتضمّن رمز MediaSession.

بدء متطلبات جديدة

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

  • [3.8.3/H-1-1] يجب تنفيذ سلوك تثبيت الشاشة وتزويد المستخدم بقائمة إعدادات لتفعيل الميزة أو إيقافها.

إنهاء المتطلبات الجديدة

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

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

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

  • [3.8.4/H-1-1]* يجب عرض إشعارات المحادثات قبل الإشعارات غير المتعلّقة بالمحادثات، باستثناء إشعارات الخدمات التي تعمل في المقدّمة وإشعارات importance:high.

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

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

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

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

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

  • [3.8.16/H-1-1] يجب الإفصاح عن علامة الميزة android.software.controls وضبطها على true.
  • [3.8.16/H-1-2] يجب أن يوفّر التطبيق للمستخدم ميزات تتيح له إضافة عناصر التحكّم المفضّلة لديه في الجهاز وتعديلها واختيارها وتشغيلها من عناصر التحكّم المسجّلة من خلال التطبيقات التابعة لجهات خارجية من خلال واجهات برمجة التطبيقات ControlsProviderService وControl.
  • [3.8.16/H-1-3] يجب توفير إمكانية الوصول إلى هذه الميزة للمستخدم في غضون ثلاث تفاعلات من مشغّل التطبيقات التلقائي.
  • [3.8.16/H-1-4] يجب أن يعرض هذا العنصر المتاح للمستخدمين اسم كل تطبيق تابع لجهة خارجية يقدّم عناصر تحكّم من خلال واجهة برمجة التطبيقات ControlsProviderService بالإضافة إلى أي حقول محدّدة تقدّمها واجهات برمجة التطبيقات Control بدقة.

  • [3.8.16/H-1-5] يجب أن يوفّر التطبيق للمستخدمين إمكانية إيقاف عناصر التحكّم في الجهاز غير المهمة لتوفير إمكانية المصادقة من خلال عناصر التحكّم المسجّلة من قِبل التطبيقات التابعة لجهات خارجية من خلال واجهتَي برمجة التطبيقات ControlsProviderService وControl Control.isAuthRequired.

بدء متطلبات جديدة

  • [3.8.16/H-1-6] يجب أن تعرض عمليات تنفيذ الأجهزة إمكانية استخدام العنصر بدقة على النحو التالي:
    • إذا ضبط الجهاز القيمة config_supportsMultiWindow=true وأعلن التطبيق عن البيانات الوصفية META_DATA_PANEL_ACTIVITY في ملف تعريف الارتباط ControlsProviderService ، بما في ذلك ComponentName لنشاط صالح (على النحو المحدّد في واجهة برمجة التطبيقات)، يجب أن يضمِّن التطبيق النشاط المذكور في ميزة المستخدم هذه.
    • إذا لم يعلن التطبيق عن البيانات الوصفية META_DATA_PANEL_ACTIVITY، يجب أن يعرض الحقول المحدّدة كما تقدّمها واجهة برمجة التطبيقات ControlsProviderService بالإضافة إلى أي حقول محدّدة تقدّمها واجهات برمجة التطبيقات Control.
  • [3.8.16/H-1-7] إذا كان التطبيق يعلن عن البيانات الوصفية META_DATA_PANEL_ACTIVITY، يجب أن يُرسِل قيمة الإعداد المحدّدة في [3.8.16/H-1-5] باستخدام EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS عند بدء النشاط المضمّن.

إنهاء المتطلبات الجديدة

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

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

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

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

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

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

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

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

  • [7.2.3/H] يجب ألا يزيد ارتفاع منطقة التعرّف على الإيماءات لميزة "منزل" عن 32 dp من أسفل الشاشة.

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

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

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

  • [3.9/H-1-2] يجب الإفصاح عن توفّر الملفات الشخصية المُدارة من خلال علامة ميزة android.software.managed_users.

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

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

بدء متطلبات جديدة

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

إنهاء المتطلبات الجديدة

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

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

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

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

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

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

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

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

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

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

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

  • [8.5/H-0-1] يجب أن يوفّر التطبيق إمكانية للمستخدم في قائمة "الإعدادات" لعرض جميع التطبيقات التي تعمل فيها خدمات نشطة في المقدّمة أو مهام بدأها المستخدم، بما في ذلك مدة كل خدمة مماثلة منذ بدء تشغيلها كما هو موضّح في مستند حزمة تطوير البرامج (SDK). وإمكانية إيقاف تطبيق يعمل فيه خدمة نشطة في المقدّمة أو مهمة بدأها المستخدممع إمكانية إيقاف تطبيق يعمل فيه خدمة نشطة في المقدّمة وعرض جميع التطبيقات التي تعمل فيها خدمات نشطة في المقدّمة ومدة كل خدمة مماثلة منذ بدء تشغيلها كما هو موضّح في مستند حزمة تطوير البرامج (SDK).
    • قد يتم إعفاء بعض التطبيقات من إيقافها أو إدراجها في ميزة المستخدم هذه كما هو موضّح في مستند حزمة SDK.

بدء متطلبات جديدة

  • [8.5/H-0-2]يجب أن يقدّم التطبيق للمستخدم إمكانية إيقاف تطبيق يشغّل خدمة تعمل في المقدّمة أو مهمة بدأها المستخدم.

إنهاء المتطلبات الجديدة

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

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

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

بدء متطلبات جديدة

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

  • [9.5/H-1-1] يجب عدم ضبط UserManager.isHeadlessSystemUserMode على true.

إنهاء المتطلبات الجديدة

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

  • [9.11/H-0-2] يجب الاحتفاظ بنسخة احتياطية من عملية تنفيذ ملف تخزين المفاتيح باستخدام بيئة تنفيذ معزولة.
  • [9.11/H-0-3] يجب أن تتضمّن عمليات تنفيذ خوارزميات التشفير RSA وAES وECDSA وHMAC ووظائف التجزئة من مجموعة MD5 وSHA1 وSHA-2 لتتوافق بشكل صحيح مع خوارزميات المتاحة في نظام "متجر مفاتيح Android" في منطقة معزولة بشكل آمن عن الرمز البرمجي الذي يعمل على النواة والإصدارات الأحدث. يجب أن تحظر ميزة "العزل الآمن" جميع الآليات المحتملة التي يمكن من خلالها لرمز kernel أو مساحة المستخدم الوصول إلى الحالة الداخلية للبيئة المعزولة، بما في ذلك DMA. يستوفي "المشروع المفتوح المصدر لنظام Android" (AOSP) هذا الشرط من خلال استخدام عملية تنفيذ Trusty، ولكن هناك خياران بديلة هما حلّ آخر يستند إلى ARM TrustZone أو عملية تنفيذ آمنة تمت مراجعتها من قِبل جهة خارجية لتوفير عزل مناسب يستند إلى أداة إدارة الأجهزة الافتراضية.
  • [9.11/H-0-4] يجب تنفيذ مصادقة شاشة القفل في بيئة التنفيذ المعزولة، والسماح باستخدام المفاتيح المرتبطة بالمصادقة فقط عند اختلاف. يجب تخزين بيانات اعتماد شاشة القفل بطريقة لا تسمح إلا لبيئة التنفيذ المعزولة بإجراء مصادقة شاشة القفل. يقدّم مشروع Android Open Source Project الإصدارات السابقة من Gatekeeper Hardware Abstraction Layer (HAL) و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 المتطلّبات المتعلقة بوضع التأمين.

بدء متطلبات جديدة

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

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

إنهاء المتطلبات الجديدة

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

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

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

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

بدء متطلبات جديدة

إذا كانت عمليات تنفيذ الأجهزة الجوّالة تضبط UserManager.isHeadlessSystemUserMode على true،

  • [9.5/H-4-1] يجب ألا يتضمّن الجهاز إمكانية استخدام شرائح eUICC أو شرائح eSIM المزوّدة بإمكانية الاتصال.
  • [9.5/H-4-2] يجب عدم الإفصاح عن توفّر ميزة android.hardware.telephony.

إنهاء المتطلبات الجديدة

يتيح نظام التشغيل Android من خلال واجهة برمجة التطبيقات System API VoiceInteractionService آلية لكشف الكلمات المهمة الصوتية بشكل آمن وتلقائي بدون الإشارة إلى الوصول إلى الميكروفون،واكتشاف طلبات البحث بشكل تلقائي بدون الإشارة إلى الوصول إلى الميكروفون أو الكاميرا.

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

  • [9.8/H-1-1] يجب التأكّد من أنّ خدمة رصد الكلمات الرئيسية لا يمكنها نقل سوى البيانات إلى النظام أو ContentCaptureService أو أو خدمة التعرّف على الكلام على الجهاز التي أنشأها SpeechRecognizer#createOnDeviceSpeechRecognizer().
  • [9.8/H-1-2] يجب التأكّد من أنّ خدمة رصد الكلمات الرئيسية لا يمكنها نقل سوى data الصوتية من الميكروفون أو البيانات المستمدة منها إلى خادم النظام من خلال واجهة برمجة التطبيقات HotwordDetectionService، أو إلى ContentCaptureService من خلال واجهة برمجة التطبيقات ContentCaptureManager.
  • [9.8/H-1-3] يجب عدم توفير صوت من الميكروفون أطول من 30 ثانية لطلب individual individual hardware-triggered request إلى خدمة رصد الكلمات الرئيسية.
  • [9.8/H-1-4] يجب عدم تقديم صوت من الميكروفون تم تخزينه مؤقتًا ويبلغ عمره أكثر من 8 ثوانٍ لطلب individual request إلى خدمة رصد الكلمات المهمة.
  • [9.8/H-1-5] يجب عدم إرسال تسجيلات صوتية مسجّلة من الميكروفون أقدم من 30 ثانية إلى خدمة التفاعل الصوتي أو كيان مشابه.
  • [9.8/H-1-6] يجب عدم السماح بنقل أكثر من 100 بايت من البيانات خارج خدمة رصد الكلمات الرئيسية في كل نتيجة ناجحة لكلمة رئيسيةباستثناء بيانات الصوت التي يتم تمريرها من خلال HotwordAudioStream.
  • [9.8/H-1-7] يجب عدم السماح بنقل أكثر من 5 بت من البيانات خارج خدمة رصد الكلمات الرئيسية في كل نتيجة سلبية للكلمة الرئيسية.
  • [9.8/H-1-8] يجب عدم السماح بنقل البيانات خارج خدمة الكشف عن الكلمات المميّزة إلا عند تلقّي طلب التحقّق من الكلمة المميّزة من خادم النظام.
  • [9.8/H-1-9] يجب عدم السماح لتطبيق يمكن للمستخدم تثبيته بتقديم خدمة رصد الكلمات الرئيسية.
  • [9.8/H-1-10] يجب عدم عرض بيانات كمية عن استخدام الميكروفون من قِبل خدمة رصد الكلمات الرئيسية في واجهة المستخدم.
  • [9.8/H-1-11] يجب تسجيل عدد البايتات المضمّنة في كل عملية إرسال من خدمة رصد الكلمات الرئيسية للسماح بفحصها من قِبل باحثي الأمان.
  • [9.8/H-1-12] يجب أن يتيح وضع تصحيح الأخطاء تسجيل المحتوى الأوّلي لكل عملية إرسال من خدمة رصد الكلمات الرئيسية للسماح لباحثي الأمان بالفحص.
  • [9.8/H-1-14] يجب عرض مؤشر الميكروفون، كما هو موضّح في القسم 9.8.2، عند إرسال نتيجة كلمة تشغيل ناجحة إلى خدمة التفاعل الصوتي أو كيان مشابه.

بدء متطلبات جديدة

  • [9.8/H-1-15] يجب التأكّد من أنّ عمليات نقل البث الصوتي المقدَّمة عند رصد كلمة مفتاح ناجحة تتم في اتجاه واحد من خدمة رصد الكلمة المفتاح إلى خدمة التفاعل بالصوت.

إنهاء المتطلبات الجديدة

  • [9.8/H-SR-1] يُنصح بشدة بإشعار المستخدمين قبل ضبط التطبيق كمقدّم خدمة رصد الكلمات الرئيسية.
  • [9.8/H-SR-2] يُنصح بشدة بعدم السماح بإرسال data غير منظَّمة خارج خدمة رصد الكلمات الرئيسية.
  • [9.8/H-SR-3] يُنصح بشدة بإعادة تشغيل العملية التي تستضيف خدمة رصد الكلمات الرئيسية مرة واحدة على الأقل كل ساعة أو بعد 30 حدث يتم تشغيله بالأجهزة، أيهما أقرب.

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

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

بدء متطلبات جديدة

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

  • [9.8/H-3-1] يجب التأكّد من أنّ خدمة رصد طلبات البحث لا يمكنها نقل سوى البيانات إلى النظام أو ContentCaptureService أو خدمة معالجة التحدّث على الجهاز (التي أنشأها SpeechRecognizer#createOnDeviceSpeechRecognizer()).
  • [9.8/H-3-2] يجب عدم السماح بنقل أي معلومات صوتية أو فيديو خارج VisualQueryDetectionService، باستثناء ContentCaptureService أو خدمة التعرّف على الكلام على الجهاز.
  • [9.8/H-3-3] يجب عرض إشعار للمستخدم في واجهة مستخدم النظام عندما يرصد الجهاز نية المستخدم في التفاعل مع تطبيق المساعد الرقمي (مثلاً من خلال رصد وجود المستخدم عبر الكاميرا).
  • [9.8/H-3-4] يجب عرض مؤشر الميكروفون وعرض طلب البحث الذي تم رصده في واجهة المستخدم مباشرةً بعد رصد طلب البحث.
  • [9.8/H-3-5] يجب عدم السماح لتطبيق يمكن للمستخدم تثبيته بتقديم خدمة رصد طلبات البحث المرئية.

إنهاء المتطلبات الجديدة

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

  • [9.8.2/H-4-1] يجب عرض مؤشر الميكروفون عندما يحصل تطبيق على بيانات صوتية من الميكروفون، ولكن ليس عندما يتم الوصول إلى الميكروفون من خلال HotwordDetectionService أو SOURCE_HOTWORD أوContentCaptureService أو التطبيقات التي تمتلك الأدوار المذكورة في الفقرة 9.1 باستخدام معرّف CDD‏ [C-4-X].
  • [9.8.2/H-4-2] يجب عرض قائمة التطبيقات المستخدَمة مؤخرًا والنشطة التي تستخدم الميكروفون كما هو موضّح في PermissionManager.getIndicatorAppOpUsageData()، بالإضافة إلى أي رسائل تحديد مصدر مرتبطة بها.

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

  • [9.8.2/H-5-1] يجب عرض مؤشر الكاميرا عندما يحصل أحد التطبيقات على بيانات الكاميرا المباشرة، ولكن ليس عندما تحصل التطبيقات التي تمتلك الأدوار المذكورة في الفقرة 9.1 باستخدام معرّف CDD‏ [C-4-X] على بيانات الكاميرا فقط.
  • [9.8.2/H-5-2] يجب عرض التطبيقات المستخدَمة مؤخرًا والتطبيقات النشطة التي تستخدم الكاميرا كما هو موضّح في PermissionManager.getIndicatorAppOpUsageData()، بالإضافة إلى أي رسائل تحديد مصدر مرتبطة بها.

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

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

  • [6.1/H-0-1]* يجب أن يكون متوافقًا مع الأمر shell cmd testharness.

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

  • Perfetto
    • [6.1/H-0-2]* يجب أن يعرض /system/bin/perfetto ملفًا ثنائيًا لمستخدم shell يكون cmdline متوافقًا مع مستندات perfetto.
    • [6.1/H-0-3]* يجب أن يقبل ملف perfetto الثنائي كأحد المدخلات ملف إعدادات protobuf متوافقًا مع المخطّط المحدّد في مستندات perfetto.
    • [6.1/H-0-4]* يجب أن يكتب ملف perfetto الثنائي أثر protobuf كأحد المخرجات يتوافق مع المخطط المحدّد في مستندات perfetto.
    • [6.1/H-0-5]* يجب أن يوفّر، من خلال ملف برمجي binar‎o لـ perfetto، على الأقل مصادر البيانات الموضّحة في مستندات perfetto.
    • [6.1/H-0-6]* يجب أن يكون العميل المُتتبّع في perfetto مفعّلاً تلقائيًا (خاصية النظام persist.traced.enable).

2.2.7. فئة أداء الوسائط على الأجهزة الجوّالة

راجِع الفقرة 7.11 للاطّلاع على تعريف فئة أداء الوسائط.

2.2.7.1. الوسائط

إذا كانت عمليات تنفيذ الأجهزة الجوّالة تعرض android.os.Build.VERSION_CODES.T لـ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS، يعني ذلك أنّها:

بدء متطلبات جديدة

إذا كانت عمليات تنفيذ الأجهزة الجوّالة تعرض android.os.Build.VERSION_CODES.U لحالة android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS، يعني ذلك أنّها:

  • [5.1/H-1-1] يجب الإعلان عن الحد الأقصى لعدد جلسات فك ترميز الفيديو في الأجهزة التي يمكن تشغيلها بشكل متزامن في أي مجموعة من برامج الترميز من خلال الطريقتَين CodecCapabilities.getMaxSupportedInstances() و VideoCapabilities.getSupportedPerformancePoints().
  • [5.1/H-1-2] يجب أن يكون الجهاز مزوّدًا بـ 6 جلسات لفك ترميز الفيديوهات باستخدام الأجهزة بدقة 8 بت (النطاق الديناميكي العادي) (AVC أو HEVC أو VP9 أو AV1 أو الإصدارات الأحدث) في أي مجموعة من برامج الترميز التي تعمل بالتزامن مع 3 جلسات بدقة 1080p بمعدّل 30 لقطة في الثانية و3 جلسات بدقة 4K بمعدّل 30 لقطة في الثانية. يجب أن تكون برامج ترميز AV1 متوافقة فقط مع درجة الدقة 1080p، ولكن يجب أن تكون متوافقة أيضًا مع 6 عمليات ترميز بمعدل 1080p30fps.
  • [5.1/H-1-3] يجب الإعلان عن الحد الأقصى لعدد جلسات تحويل ترميز الفيديو في الأجهزة التي يمكن تشغيلها بشكل متزامن في أي مجموعة من برامج الترميز من خلال الطريقتَين CodecCapabilities.getMaxSupportedInstances() و VideoCapabilities.getSupportedPerformancePoints().
  • [5.1/H-1-4] يجب أن يكون الجهاز مزوّدًا بـ 6 جلسات لترميز الفيديوهات باستخدام الأجهزة بدقة 8 بت (النطاق الديناميكي العادي) (AVC أو HEVC أو VP9 أو AV1 أو الإصدارات الأحدث) في أي مجموعة من برامج الترميز التي تعمل بالتزامن مع 4 جلسات بدقة 1080p بمعدّل 30 لقطة في الثانية وجلستَين بدقة 4K بمعدّل 30 لقطة في الثانية. يجب أن تكون برامج ترميز AV1 متوافقة فقط مع درجة الدقة 1080p، ولكن يجب أن تكون متوافقة أيضًا مع 6 عمليات ترميز بمعدل 1080p30fps.
  • [5.1/H-1-5] يجب الإعلان عن الحد الأقصى لعدد جلسات ترميز و decode للفيديو في الأجهزة التي يمكن تشغيلها بشكل متزامن في أي مجموعة من برامج الترميز من خلال CodecCapabilities.getMaxSupportedInstances() وVideoCapabilities.getSupportedPerformancePoints().
  • [5.1/H-1-6] يجب أن يكون متوافقًا مع 6 عمليات فك ترميز فيديو بترميز 8 بت (SDR) وجلسات ترميز فيديو (AVC أو HEVC أو VP9 أو AV1 أو الإصدارات الأحدث) في أي تركيبة ترميز يتم تشغيلها بشكل متزامن مع 3 جلسات بدقة 4K@30fps ، على أن تكون جلستا ترميز على الأكثر و3 جلسات بدقة 1080p. يجب أن تكون برامج ترميز AV1 متوافقة فقط مع درجة الدقة 1080p، ولكن يجب أن تكون متوافقة أيضًا مع 6 عمليات ترميز بمعدل 1080p30fps.
  • [5.1/H-1-19] يجب أن يكون متوافقًا مع 3 عمليات فك ترميز فيديو بمعيار 10 بت (HDR) في الأجهزة وجلسات ترميز الفيديو في الأجهزة (AVC أو HEVC أو VP9 أو AV1 أو الإصدارات الأحدث) في أي مجموعة برامج ترميز تعمل بشكل متزامن بدقة 4K بمعدّل 30 لقطة في الثانية وتكون جلسة ترميز واحدة منها على الأكثر، ويمكن ضبطها في تنسيق إدخال RGBA_1010102 من خلال سطح GL. لا يلزم إنشاء البيانات الوصفية لميزة النطاق العالي الديناميكية من قِبل برنامج الترميز في حال الترميز من سطح GL. لا يُشترط استخدام جلسات ترميز AV1 إلا لتلبية متطلبات دقة 1080p حتى إذا كانت هذه المتطلبات تتطلّب دقة 4K.
  • [5.1/H-1-7] يجب أن يكون وقت استجابة إعداد ترميز الفيديو 40 ملي ثانية أو أقل لجلسة ترميز فيديو بدقة 1080p أو أقل لجميع برامج ترميز الفيديوهات المزوّدة بالأجهزة عند معالجة حمولة. يتم تعريف "التحميل" هنا على أنّه جلسة تحويل ترميز متزامنة للفيديوهات فقط من دقة 1080p إلى 720p باستخدام برامج ترميز الفيديو على الأجهزة مع بدء تسجيل الصوت والفيديو بدقة 1080p. بالنسبة إلى برنامج ترميز Dolby Vision، يجب أن يكون وقت استجابة بدء تشغيل برنامج الترميز 50 ملي ثانية أو أقل.
  • [5.1/H-1-8] يجب أن يكون وقت استجابة إعداد ترميز الصوت 30 ملي ثانية أو أقل لجلسة ترميز صوت بمعدل 128 كيلوبت في الثانية أو أقل لجميع برامج ترميز الصوت عند بدء التشغيل. يتم تعريف "التحميل" هنا على أنّه جلسة تحويل ترميز متزامنة للفيديوهات فقط من دقة 1080p إلى 720p باستخدام برامج ترميز الفيديو على الأجهزة مع بدء تسجيل الصوت والفيديو بدقة 1080p.
  • [5.1/H-1-9] يجب أن يكون الجهاز مزوّدًا بجلستَين لفك ترميز الفيديو الآمن في الأجهزة (AVC أو HEVC أو VP9 أو AV1 أو الإصدارات الأحدث) في أي مجموعة من برامج الترميز التي تعمل معًا ويُجري الجهاز فك الترميز بشكل متزامن بدقة 1080p بمعدّل 30 لقطة في الثانية لكل من المحتوى بدقة 8 بت (النطاق الديناميكي العادي) و10 بت بنطاق عالي الديناميكية.
  • [5.1/H-1-10] يجب أن يكون متوافقًا مع 3 جلسات فك ترميز فيديو غير آمنة في الأجهزة بالإضافة إلى جلسة واحدة فك ترميز فيديو آمنة في الأجهزة (4 جلسات في المجمل) (AVC أو HEVC أو VP9 أو AV1 أو الإصدارات الأحدث) في أي مجموعة من برامج الترميز يتم تشغيلها بشكل متزامن مع 3 جلسات بدقة 4K ومعدل 30 لقطة في الثانية تتضمّن جلسة واحدة لفك الترميز الآمن وجلسة واحدة غير آمنة بدقة 1080p ومعدل 30 لقطة في الثانية، حيث يمكن أن تكون جلستان بحد أقصى بتنسيق HDR بدقة 10 بت. لا يلزم استخدام جلسات ترميز AV1 إلا لتلبية متطلبات دقة 1080p حتى إذا كانت هذه المتطلبات تتطلّب دقة 4K.
  • [5.1/H-1-11] يجب أن يكون الجهاز مزوّدًا بوحدة فك ترميز آمنة لكل وحدة فك ترميز AVC أو HEVC أو VP9 أو AV1 على الجهاز.
  • [5.1/H-1-12] يجب أن يكون وقت استجابة إعداد ترميز الفيديو 40 ملي ثانية أو أقل لجلسة فك ترميز فيديو بدقة 1080p أو أقل لجميع برامج فك ترميز الفيديوهات المزوّدة بالأجهزة عند بدء التشغيل. يتم تعريف "الحمل" هنا على أنّه جلسة تحويل ترميز متزامنة للفيديوهات فقط من دقة 1080p إلى 720p باستخدام برامج ترميز الفيديو على الأجهزة مع بدء تشغيل الصوت والفيديو بدقة 1080p. بالنسبة إلى برنامج ترميز Dolby Vision، يجب أن يكون وقت استجابة بدء تشغيل برنامج الترميز 50 ملي ثانية أو أقل.
  • [5.1/H-1-13] يجب أن يكون وقت استجابة إعداد ترميز الصوت 30 ملي ثانية أو أقل لجلسة فك ترميز صوت بمعدل 128 كيلوبت في الثانية أو أقل لجميع برامج فك ترميز الصوت عند معالجة حمولة. يتم تعريف "التحميل" هنا على أنّه جلسة تحويل ترميز متزامنة للفيديوهات فقط من دقة 1080p إلى 720p باستخدام برامج ترميز الفيديو على الأجهزة مع بدء تشغيل محتوى صوتي وفيديو بدقة 1080p.
  • [5.1/H-1-14] يجب أن يكون متوافقًا مع وحدة فك ترميز AV1 للأجهزة Main 10 والمستوى 4.1 وفيلم الحبوب.
  • [5.1/H-1-15] يجب أن يتضمّن الجهاز وحدة فك ترميز فيديو واحدة على الأقل تتوافق مع دقة 4K60.
  • [5.1/H-1-16] يجب أن يتضمّن الجهاز وحدة ترميز فيديو واحدة على الأقل متوافقة مع دقة 4K60.
  • [5.3/H-1-1] يجب ألا يتم إسقاط أكثر من لقطة واحدة في 10 ثوانٍ (أي أقل من 0.167 في المئة من إسقاط اللقطات) لجلسة فيديو بدقة 4K بمعدّل 60 لقطة في الثانية أثناء التحميل.
  • [5.3/H-1-2] يجب عدم إسقاط أكثر من لقطة واحدة في 10 ثوانٍ أثناء تغيير دقة الفيديو في جلسة فيديو بمعدل 60 لقطة في الثانية أثناء تحميل جلسة بدقة 4K.
  • [5.6/H-1-1] يجب أن يكون وقت استجابة النقر إلى النغمة 80 ملي ثانية أو أقل باستخدام اختبار النقر إلى النغمة في أداة التحقّق من CTS.
  • [5.6/H-1-2] يجب أن يكون وقت استجابة الصوت ذهابًا وإيابًا 80 ملي ثانية أو أقل على مسار بيانات متوافق واحد على الأقل.
  • [5.6/H-1-3] يجب أن يكون الجهاز متوافقًا مع تنسيق صوت بمعدل 24 بت أو أعلى لإخراج صوت استيريو عبر مقبس صوت بمنفذ 3.5 مم إذا كان متوفّرًا، وعبر منفذ صوت USB إذا كان متوفّرًا في مسار نقل البيانات بالكامل، وذلك لخفض وقت الاستجابة وضبط إعدادات البث. لضبط وقت الاستجابة المنخفض، يجب أن يستخدم التطبيق AAudio في وضع callback لوقت الاستجابة المنخفض. بالنسبة إلى إعدادات البث، يجب أن يستخدم التطبيق Java AudioTrack. في كل من إعدادات وقت الاستجابة المنخفض وإعدادات البث، يجب أن يقبل مجمع مخرج HAL إما AUDIO_FORMAT_PCM_24_BIT أو AUDIO_FORMAT_PCM_24_BIT_PACKED أو AUDIO_FORMAT_PCM_32_BIT أو AUDIO_FORMAT_PCM_FLOAT لتنسيق الإخراج المستهدَف.
  • [5.6/H-1-4] يجب أن يكون متوافقًا مع أجهزة صوت USB التي تتضمّن 4 قنوات أو أكثر (يستخدم أدوات التحكّم في موسيقى الدي جي هذه الميزة لمعاينة الأغاني).
  • [5.6/H-1-5] يجب أن يكون متوافقًا مع أجهزة MIDI المتوافقة مع الفئة وأن يعلن عن علامة ميزة MIDI.
  • [5.6/H-1-9] يجب أن يكون الجهاز متوافقًا مع 12 قناة على الأقل. ويشير ذلك إلى إمكانية فتح مقطع صوتي باستخدام قناع قنوات 7.1.4 و التحويل إلى صوت محيطي أو تقليل جودة جميع القنوات إلى صوت استيريو بشكل صحيح.
  • [5.6/H-SR] يُنصح بشدة بتوفير إمكانية مزج 24 قناة مع إتاحة استخدام قناتَي 9.1.6 و22.2 على الأقل.
  • [5.7/H-1-2] يجب أن يكون الجهاز متوافقًا مع MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL مع توفُّر إمكانات فك تشفير المحتوى التالية.
الحد الأدنى لحجم العيّنة 4 ميغابايت
الحد الأدنى لعدد العيّنات الفرعية - H264 أو HEVC 32
الحد الأدنى لعدد العيّنات الفرعية - VP9 9
الحد الأدنى لعدد العيّنات الفرعية - AV1 288
الحد الأدنى لحجم ذاكرة التخزين المؤقت للعيّنة الفرعية 1 ميغابايت
الحد الأدنى لحجم ذاكرة التخزين المؤقت لتشفير البيانات العامة 500 كيلوبايت
الحد الأدنى لعدد الجلسات المتزامنة 30
الحد الأدنى لعدد المفاتيح لكل جلسة 20
الحد الأدنى لإجمالي عدد المفاتيح (جميع الجلسات) 80
الحد الأدنى للعدد الإجمالي لمفاتيح إدارة الحقوق الرقمية (جميع الجلسات) 6
حجم الرسالة 16 كيلوبايت
عدد اللقطات في الثانية التي تم فك تشفيرها 60 لقطة في الثانية
  • [5.1/H-1-17] يجب أن يتضمّن الجهاز وحدة فك ترميز للصور تتوافق مع AVIF Baseline Profile.
  • [5.1/H-1-18] يجب أن يكون متوافقًا مع برنامج ترميز AV1 الذي يمكنه ترميز ما يصل إلى دقة 480p بسرعة 30 لقطة في الثانية وسرعة 1 ميغا بت في الثانية.
  • [5.12/H-1-1] يجب [5.12/H-SR] يُنصح بشدة بتفعيل ميزة Feature_HdrEditing لجميع برامج ترميز AV1 وHEVC للأجهزة المتوفّرة على الجهاز.
  • [5.12/H-1-2] يجب أن يكون الجهاز متوافقًا مع تنسيق الألوان RGBA_1010102 لجميع برامج ترميز AV1 و HEVC المضمّنة في الجهاز.
  • [5.12/H-1-3] يجب الإعلان عن توفّر إضافة EXT_YUV_target لجمع عيّنات من صور YUV بتنسيق 8 و10 بت.
  • [7.1.4/H-1-1] يجب أن يتضمّن الجهاز 6 طبقات رسومات على الأقل في وحدة معالجة الشاشة (DPU)، على أن يكون اثنان منها على الأقل قادرَين على عرض محتوى فيديو بدقة 10 بت.

إذا كانت عمليات تنفيذ الأجهزة الجوّالة تعرض القيمة android.os.Build.VERSION_CODES.U لandroid.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS وكانت تتضمّن ميزة إتاحة برنامج ترميز AVC أو HEVC للأجهزة، يعني ذلك أنّها:

إنهاء المتطلبات الجديدة

2.2.7.2. الكاميرا

إذا كانت عمليات تنفيذ الأجهزة الجوّالة تعرض android.os.Build.VERSION_CODES.T لـ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS، يعني ذلك أنّها:

بدء متطلبات جديدة

إذا كانت عمليات تنفيذ الأجهزة الجوّالة تعرض android.os.Build.VERSION_CODES.U لحالة android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS، يعني ذلك أنّها:

  • [7.5/H-1-1] يجب أن يتضمّن الجهاز كاميرا خلفية أساسية بدرجة دقة لا تقل عن 12 ميغابكسل وتتيح تسجيل الفيديو بدقة 4K بمعدل 30 لقطة في الثانية. الكاميرا الخلفية الأساسية هي الكاميرا الخلفية التي تحمل رقم تعريف الكاميرا الأقل.
  • [7.5/H-1-2] يجب أن تتضمّن كاميرا أمامية أساسية بدقة ‎6 ميغابكسل على الأقل وأن تتيح تسجيل الفيديوهات بدقة 1080p بمعدل 30 لقطة في الثانية. الكاميرا الأمامية الأساسية هي الكاميرا الأمامية التي تحمل رقم تعريف الكاميرا الأقل.
  • [7.5/H-1-3] يجب أن تكون الكاميرا الأمامية الأساسية متوافقة مع android.info.supportedHardwareLevel بدرجة FULL أو أفضل، ويجب أن تكون الكاميرا الخلفية الأساسية متوافقة مع LIMITED أو أفضل.
  • [7.5/H-1-4] يجب أن يكون الجهاز متوافقًا مع ميزة CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME لكل من الكاميرات الأساسية.
  • [7.5/H-1-5] يجب أن يكون وقت استجابة التقاط الصور بتنسيق JPEG في الكاميرا 2 أقل من 1000 900 ملي ثانية بدقة 1080p، كما تم قياسه من خلال اختبار أداء الكاميرا في CTS في ظل ظروف الإضاءة (3000K) لكلتا الكاميرتين الأساسيتين.
  • [7.5/H-1-6] يجب أن يكون وقت استجابة بدء تشغيل الكاميرا2 (فتح الكاميرا إلى أول ملف شخصي للمعاينة) أقل من 500 ملي ثانية، كما تم قياسه من خلال اختبار أداء الكاميرا في CTS في ظل ظروف الإضاءة ITS (3000K) لكلتا الكاميرتَين الأساسيتَين.
  • [7.5/H-1-8] يجب أن تكون الكاميرا الخلفية الأساسية متوافقة مع CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW وandroid.graphics.ImageFormat.RAW_SENSOR.
  • [7.5/H-1-9] يجب أن تتضمّن الكاميرا الأساسية الخلفية دقة 720p أو 1080p بسرعة 240 لقطة في الثانية.
  • [7.5/H-1-10] يجب أن يكون الحد الأدنى لنسبة التكبير ZOOM_RATIO أقل من 1.0 للكاميرات الأساسية إذا كانت هناك كاميرا RGB عريضة جدًا مواجهة للاتجاه نفسه.
  • [7.5/H-1-11] يجب تنفيذ بث متزامن للأمام والخلف في الكاميرات primary.
  • [7.5/H-1-12] يجب أن يكون الجهاز متوافقًا مع CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION لكل من الكاميرتين الأمامية والخلفية الأساسيتَين.
  • [7.5/H-1-13] يجب أن تتوفّر ميزة LOGICAL_MULTI_CAMERA للكاميرا الخلفية الأساسية إذا كانت هناك أكثر من كاميرا RGB واحدة خلفية.
  • [7.5/H-1-14] يجب أن تتوفّر إمكانية STREAM_USE_CASE لكل من الكاميرتين الأساسية الأمامية والأساسية الخلفية.
  • [7.5/H-1-15] يجب أن تتيح إضافات "الخلفية الضبابية" و "وضع الليل" من خلال كلّ من CameraX وCamera2 لإضافات الكاميرات الأساسية.
  • [7.5/H-1-16] يجب أن تكون الكاميرات الأساسية مزوّدة بإمكانية DYNAMIC_RANGE_TEN_BIT.
  • [7.5/H-1-17] يجب أن تكون الكاميرات الأساسية متوافقة مع CONTROL_SCENE_MODE_FACE_PRIORITY وميزة "اكتشاف الوجوه" (STATISTICS_FACE_DETECT_MODE_SIMPLE أو STATISTICS_FACE_DETECT_MODE_FULL) .

إنهاء المتطلبات الجديدة

2.2.7.3. الأجهزة

إذا كانت عمليات تنفيذ الأجهزة الجوّالة تعرض android.os.Build.VERSION_CODES.T لحالة android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS، يعني ذلك أنّها:

بدء متطلبات جديدة

إذا كانت عمليات تنفيذ الأجهزة الجوّالة تعرض android.os.Build.VERSION_CODES.U لحالة android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS، يعني ذلك أنّها:

  • [7.1.1.1/H-2-1] يجب أن تكون درجة دقة الشاشة 1080p على الأقل.
  • [7.1.1.3/H-2-1] يجب أن تكون كثافة الشاشة 400 نقطة لكل بوصة على الأقل.
  • [7.1.1.3/H-3-1] يجب أن تتضمّن شاشة بتقنية HDR سطوعًا لا يقل عن 1,000 nits في المتوسط.
  • [7.6.1/H-2-1] يجب أن يتضمّن الجهاز ذاكرة أساسية بسعة 8 غيغابايت على الأقل.

إنهاء المتطلبات الجديدة

2.2.7.4. الأداء

إذا كانت عمليات تنفيذ الأجهزة الجوّالة تعرض android.os.Build.VERSION_CODES.T لحالة android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS، يعني ذلك أنّها:

بدء متطلبات جديدة

إذا كانت عمليات تنفيذ الأجهزة الجوّالة تعرض android.os.Build.VERSION_CODES.U لحالة android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS، يعني ذلك أنّها:

  • [8.2/H-1-1] يجب أن يضمن أداء الكتابة التسلسلي سرعة لا تقل عن 150 ميغابايت في الثانية.
  • [8.2/H-1-2] يجب أن يضمن أداء الكتابة العشوائي سرعة لا تقل عن 10 ميغابايت في الثانية.
  • [8.2/H-1-3] يجب أن يضمن أداء القراءة التسلسلي سرعة لا تقل عن 250 ميغابايت في الثانية.
  • [8.2/H-1-4] يجب أن يضمن أداء القراءة العشوائية سرعة لا تقل عن 100 ميغابايت في الثانية.
  • [8.2/H-1-5] يجب أن يضمن الأداء التسلسلي المتوازي للقراءة والكتابة بسرعة قراءة تبلغ ضعف سرعة الكتابة وسرعة كتابة تبلغ مرة واحدة على الأقل 50 ميغابايت في الثانية.

إنهاء المتطلبات الجديدة

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

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

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

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

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

2.3.1. الأجهزة

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

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

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

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

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

  • [7.4.3/T-0-1] يجب أن يكون الجهاز متوافقًا مع البلوتوث وتكنولوجيا ‎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] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 896 ميغابايت على الأقل في حال استخدام أي من الكثافات التالية:

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

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

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

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

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

بدء متطلبات جديدة

  • [5.2/T-0-3] AV1

إنهاء المتطلبات الجديدة

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

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

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

بدء متطلبات جديدة

إنهاء المتطلبات الجديدة

يجب أن تتيح عمليات تنفيذ أجهزة التلفزيون فك ترميز 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 من High Profile

يجب أن تتيح عمليات تنفيذ أجهزة التلفزيون المزوّدة ببرامج فك ترميز الأجهزة لتنسيق 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 لقطة في الثانية باستخدام ملف تعريف Main10 من المستوى 5 من الفئة الرئيسية

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3.3. البرامج

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

  • [3/T-0-1] يجب الإفصاح عن الميزتَين android.software.leanback وandroid.hardware.type.television.
  • [3.2.3.1/T-0-1] يجب تحميل تطبيق واحد أو أكثر أو مكونات خدمة واحدة أو أكثر مسبقًا باستخدام معالِج طلبات بحث، وذلك لجميع أنماط فلاتر طلبات البحث العامة التي تحدّدها طلبات بحث التطبيقات التالية المُدرَجة هنا.
  • [3.4.1/T-0-1] يجب توفير تنفيذ كامل لواجهة برمجة تطبيقات android.webkit.Webview.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [8.3/T-1-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] يجب أن يتيح مطوّر التطبيقات استخدام الطاقة هذا من خلال الأمر adb shell dumpsys batterystats في واجهة سطر الأوامر.

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

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

  • [9/T-0-1] يجب الإفصاح عن ميزة android.hardware.security.model.compatible.
  • [9.11/T-0-1] يجب الاحتفاظ بنسخة احتياطية من عملية تنفيذ ملف تخزين المفاتيح باستخدام بيئة تنفيذ معزولة.
  • [9.11/T-0-2] يجب أن تتضمّن عمليات تنفيذ خوارزميات التشفير RSA وAES وECDSA وHMAC ووظائف التجزئة من مجموعة MD5 وSHA1 وSHA-2 لدعم خوارزميات نظام "متجر مفاتيح Android" المتاحة بشكلٍ سليم في منطقة معزولة بشكلٍ آمن عن الرمز البرمجي الذي يعمل على النواة والإصدارات الأحدث. يجب أن تحظر ميزة "العزل الآمن" جميع الآليات المحتملة التي يمكن من خلالها لرمز kernel أو مساحة المستخدم الوصول إلى الحالة الداخلية للبيئة المعزولة، بما في ذلك DMA. يستوفي "المشروع المفتوح المصدر لنظام Android" (AOSP) هذا الشرط من خلال استخدام عملية تنفيذ Trusty، ولكن هناك خياران بديلة هما حلّ آخر يستند إلى ARM TrustZone أو عملية تنفيذ آمنة تمت مراجعتها من قِبل جهة خارجية لتوفير عزل مناسب يستند إلى أداة إدارة الأجهزة الافتراضية.
  • [9.11/T-0-3] يجب تنفيذ مصادقة شاشة القفل في بيئة التنفيذ المعزولة، وعند نجاح المصادقة فقط، يجب السماح باستخدام المفاتيح المرتبطة بالمصادقة. يجب تخزين بيانات اعتماد شاشة القفل بطريقة لا تسمح إلا لبيئة التنفيذ المعزولة بإجراء مصادقة شاشة القفل. يقدّم مشروع Android Open Source Project الإصدارات السابقة من Gatekeeper Hardware Abstraction Layer (HAL) و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 في تنفيذ عناصر التحكّم للسماح للمستخدمين الآخرين بالوصول إلى المكالمات الصوتية والرسائل القصيرة أو حظر وصولهم إليها.

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

  • [9.8.2/T-4-1] يجب عرض مؤشر الميكروفون عندما يحصل تطبيق على بيانات صوتية من الميكروفون، ولكن ليس عندما يتم الوصول إلى الميكروفون من خلال HotwordDetectionService أو SOURCE_HOTWORD أو ContentCaptureService أو التطبيقات التي تمتلك الأدوار المذكورة في القسم 9.1 أذونات مع معرّف CDD C-3-X].
  • [9.8.2/T-4-2] يجب عدم إخفاء مؤشر الميكروفون لتطبيقات النظام التي تتضمّن واجهات مستخدم مرئية أو تفاعلًا مباشرًا مع المستخدم.

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

  • [9.8.2/T-5-1] يجب عرض مؤشر الكاميرا عندما يحصل أحد التطبيقات على بيانات الكاميرا المباشرة، ولكن ليس عندما يحصل على بيانات الكاميرا فقط تطبيقات تمتلك الأدوار الموضّحة في القسم 9.1. ينبغي أن يكون لدى التطبيقات التي تحصل على بيانات الكاميرا معرّف CDD‏ [C-3-X].
  • [9.8.2/T-5-2] يجب عدم إخفاء مؤشر الكاميرا ل تطبيقات النظام التي تتضمّن واجهات مستخدم مرئية أو تفاعلًا مباشرًا مع المستخدم.

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

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

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

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

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

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

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

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

2.4.1. الأجهزة

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

  • [7.1.1.1/W-0-1] يجب أن يكون الجهاز مزوّدًا بشاشة قياسها قطريًا بين 1.1 و2.5 بوصة.

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

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

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

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

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

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

  • [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.2.3.1/W-0-1] يجب تحميل تطبيقات أو مكونات خدمة واحدة أو أكثر مسبقًا باستخدام معالِج طلبات بحث، وذلك لتطبيق جميع أنماط فلاتر طلبات البحث المتاحة للجميع والمحدّدة من خلال طلبات البحث التالية للتطبيق والمدرَجة هنا.

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [9/W-0-1] يجب الإفصاح عن ميزة android.hardware.security.model.compatible.

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

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

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

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

بدء متطلبات جديدة

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

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

إنهاء المتطلبات الجديدة

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

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

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

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

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

2.5.1. الأجهزة

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

  • [7.1.1.1/A-0-1] يجب أن يكون حجم الشاشة على الأقل 6 بوصة في شكلها العمودي.
  • [7.1.1.1/A-0-2] يجب أن يتضمّن تنسيق حجم الشاشة ‫750 dp x ‏480 dp على الأقل.
  • [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-SR1] يجوز تحديد الموقع الجغرافي باستخدام تقنية التوقّع التقريبي من خلال دمج نظام تحديد المواقع العالمي (GPS)/نظام تحديد المواقع العالمي لنظام التموضع العالمي (GNSS) مع أجهزة استشعار إضافية. إذا تم احتساب الموقع الجغرافي باستخدام طريقة التقدير التقريبي، ننصحك بشدة بتنفيذ وتسجيل أنواع الاستشعار المقابلة و/أو أرقام تعريف خصائص المركبات المستخدَمة.
  • [7.3/A-0-4] الموقع الجغرافي الذي تم طلبه من خلال LocationManager#requestLocationUpdates()‎ يجب ألّا يكون مطابقًا للخريطة.

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

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

  • [7.3/A-SR-2] يُنصح بشدة بتنفيذ قياسات TYPE_HEADING والإبلاغ عنها.

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

  • [7.1.4.1/A-0-1] يجب الإفصاح عن استخدام OpenGL ES 3.1 أو إصدار أحدث.
  • [7.1.4.1/A-0-2] يجب أن يكون متوافقًا مع Vulkan 1.1.
  • [7.1.4.1/A-0-3] يجب أن يتضمّن أداة تحميل Vulkan وتصدير جميع الرموز.

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

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

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

  • [7.3.1/A-SR-1] يُنصح بشدة بتنفيذ أداة الاستشعار المركبة لمقياس التسارع المحدود المحاور.

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

  • [7.3.1/A-1-3] يجب تنفيذ قياس TYPE_ACCELEROMETER_LIMITED_AXES والإبلاغ عنه.
  • [7.3.1/A-1-4] يجب تنفيذ قياس TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED والإبلاغ عنه.

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

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

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

  • [7.3.4/A-SR-2] يُنصح بشدة بتنفيذ الاستشعار المركب لجهاز جيروسكوب المحاور المحدودة.

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

  • [7.3.4/A-4-1] يجب تنفيذ قياس TYPE_GYROSCOPE_LIMITED_AXES والإبلاغ عنه.
  • [7.3.4/A-4-2] يجب تنفيذ قياس TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED والإبلاغ عنه.

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

  • [7.3.3/أ-3-1] يجب تحديد الموقع الجغرافي في المرة الأولى التي يتم فيها تشغيل جهاز استقبال نظام تحديد المواقع العالمي (GPS) أو بعد 4 أيام أو أكثر خلال 60 ثانية.
  • [7.3.3/أ-3-2] يجب استيفاء معايير وقت الإصلاح الأول كما هو описан في 7.3.3/ج-1-2 و7.3.3/ج-1-6 لجميع طلبات تحديد الموقع الجغرافي الأخرى (أي الطلبات التي ليست المرة الأولى على الإطلاق أو بعد 4 أيام أو أكثر). يتم عادةً استيفاء المتطلب 7.3.3/C-1-2 في المركبات التي لا تتيح إمكانية الاتصال بالبيانات المستندة إلى شبكة الجوّال، وذلك باستخدام توقّعات مدارات نظام تحديد المواقع العالمي (GNSS) المحسوبة على جهاز الاستقبال، أو باستخدام آخر موقع جغرافي معروف للمركبة بالإضافة إلى إمكانية استخدام طريقة التقدير التقريبي لمدة 60 ثانية على الأقل بدقة موقع جغرافي تستوفي 7.3.3/C-1-3، أو باستخدام كليهما.

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

  • [7.3.4/A-4-3] يجب أن يكون الجهاز قادرًا على تسجيل الأحداث بمعدّل تكرار لا يقل عن 1 هرتز.
  • [7.3.4/A-SR-3] يُنصح بشدة بالإبلاغ عن الأحداث التي تصل إلى معدل قياس تردد لا يقل عن 10 هرتز.
  • يجب أن تكون الإشارة إلى الشمال الحقيقي.
  • يجب أن تكون ميزة "القيادة بدون يدين" متاحة حتى عندما تكون المركبة متوقفة.
  • يجب أن تكون درجة الدقة 1 درجة على الأقل.

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

  • [7.4.3/A-0-1] يجب أن يكون الجهاز متوافقًا مع البلوتوث ويجب أن يكون متوافقًا مع البلوتوث منخفض الطاقة.
  • [7.4.3/A-0-2] يجب أن تتوافق عمليات تنفيذ Android Automotive مع ملفات تعريف البلوتوث التالية:
    • إجراء مكالمات هاتفية عبر ملف الإعدادات بدون لمس الجهاز (HFP)
    • تشغيل الوسائط عبر ملف تعريف توزيع الصوت (A2DP)
    • التحكّم في تشغيل الوسائط من خلال ملف التحكم عن بُعد (AVRCP)
    • مشاركة جهات الاتصال باستخدام ملف الوصول إلى دفتر العناوين (PBAP)
  • [7.4.3/A-SR-1] يُنصح بشدة بتوفير ملف التعريف الخاص بالوصول إلى الرسائل (MAP).

  • [7.4.5/أ] يجب أن يتضمّن الجهاز إمكانية الربط بشبكة بيانات جوّال.

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

بدء متطلبات جديدة

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

  • [7.4.10/A-0-1] يجب الإفصاح عن توافق التطبيق مع FEATURE_BROADCAST_RADIO.

إنهاء المتطلبات الجديدة

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

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

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

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

  • [7.5/A-1-1] يجب ألّا تتيح كاميرات الرؤية الخارجية الوصول إليها من خلال واجهات برمجة تطبيقات كاميرا Android، ما لم تكن متوافقة مع المتطلبات الأساسية للكاميرا.
  • [7.5/A-SR-1] يُنصح بشدة بعدم تدوير معاينة الكاميرا أو عكسها أفقيًا.

  • [7.5/A-SR-2] يُنصح بشدة بأن تكون درجة دقة الصور 1.3 ميغابكسل على الأقل.

  • يجب أن يكون مزوّدًا بأجهزة ذات تركيز ثابت أو بميزة "عمق مجال الصورة الموسّع".

  • قد تتضمّن ميزة التركيز التلقائي للأجهزة أو التركيز التلقائي للبرامج في برنامج تشغيل الكاميرا.

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

  • [7.5/أ-2-1] يجب عدم تدوير معاينة الكاميرا أو عكسها أفقيًا.

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

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

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

  • [7.5/أ-3-1] يجب الإبلاغ عن علامة الميزة android.hardware.camera.any.
  • [7.5/أ-3-2] يجب عدم الإفصاح عن الكاميرا على أنّها كاميرا نظام.
  • قد تتيح استخدام الكاميرات الخارجية الموضّحة في الفقرة 7.5.3.
  • قد تتضمّن ميزات (مثل التركيز التلقائي وما إلى ذلك) متاحة للكاميرات المُوجَّهة للخلف كما هو موضّح في الفقرة 7.5.1.

بدء متطلبات جديدة

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

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

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

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

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

  • [7.5/A-1-1] يجب توجيه الكاميرا بحيث يكون الجانب الطويل منها موازٍ لمستوى X-Y في محاور أدوات استشعار Android Automotive.
  • [7.5/A-SR-3] يُنصح بشدة باستخدام أجهزة ذات تركيز ثابت أو ذات عمق مجال ممتد (EDOF).
  • [7.5/أ-1-2] يجب أن تتضمّن الكاميرا الأساسية المواجهة للخارج كاميرا مواجهة للخارج بأدنى رقم تعريف كاميرا.

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

  • [7.5/أ-2-1] يجب أن تكون الكاميرا الأساسية التي تواجه المستخدم هي كاميرا rivolta التي لها رقم تعريف الكاميرا الأقل.
  • يمكن توجيهها بحيث يكون الجانب الطويل من الكاميرا متوافقًا مع مستوى X-Y لمحورَي استشعار Android Automotive.

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

  • [7.5/أ-3-1] يجب أن تكون متوافقة مع المتطلبات الأساسية للكاميرا الواردة في القسم 7.5.

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

  • [7.5/أ-4-1] يجب أن يكون بالإمكان الوصول إلى التطبيق من خلال خدمة نظام العرض الموسّع.

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

  • [7.5/أ-5-1] يجب عدم تدوير معاينة الكاميرا أو عكسها أفقيًا.
  • [7.5/A-SR-4] يُنصح بشدة بدرجة دقة لا تقل عن 1.3 ميغابكسل.

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

  • [7.5/A-6-1] يجب الإبلاغ عن معرّف الكاميرا نفسه.

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

  • [7.5/A-7-1] يجب تنفيذ واجهة برمجة تطبيقات الكاميرا هذه باستخدام واجهة برمجة التطبيقات android.hardware.camera2 أو واجهة برمجة التطبيقات لنظام العرض الموسّع.

إنهاء المتطلبات الجديدة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [5.1/A-0-1] MPEG-4 AAC Profile (AAC LC)
  • [5.1/A-0-2] MPEG-4 HE AAC Profile (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-1] ‫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.*.

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

  • [3/أ-1-1] يجب عدم ربط امتيازات خاصة باستخدام تطبيق النظام لهذه السمات، أو منع التطبيقات التابعة لجهات خارجية من استخدام هذه السمات.
  • [3/أ-1-2] يجب عدم تكرار سمة مركبة متوفرة في حزمة SDK.

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

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

  • [3.2.3.1/A-0-1] يجب تحميل تطبيق واحد أو أكثر أو مكونات خدمة واحدة أو أكثر مسبقًا باستخدام معالِج طلبات بحث، وذلك لجميع أنماط فلاتر طلبات البحث العامة التي تحدّدها طلبات بحث التطبيقات التالية المُدرَجة هنا.

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

بدء متطلبات جديدة

  • [3.8/A-0-1] يجب عدم السماح للمستخدمين الثانويين الكاملين الذين ليسوا المستخدم الحالي في المقدّمة بتشغيل الأنشطة والوصول إلى واجهة المستخدم على أي شاشات.

إنهاء المتطلبات الجديدة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

بدء متطلبات جديدة

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

  • [9.8.2/أ-1-1] يجب عرض مؤشر الميكروفون عندما يحصل تطبيق على بيانات صوتية من الميكروفون، ولكن ليس عندما يتم استخدام الميكروفون من قِبل HotwordDetectionService أو SOURCE_HOTWORD أو ContentCaptureService أو التطبيقات التي تمتلك الأدوار المذكورة في الفقرة 9.1 باستخدام معرّف CDD‏ [C-4-X].
  • [9.8.2/أ-1-2] يجب عدم إخفاء مؤشر الميكروفون ل تطبيقات النظام التي تتضمّن واجهات مستخدم مرئية أو تفاعلًا مباشرًا مع المستخدم.
  • [9.8.2/أ-1-3] يجب توفير عنصر تحكم للمستخدم لتفعيل أو إيقاف الميكروفون في تطبيق "الإعدادات".

إنهاء المتطلبات الجديدة

إذا كانت عمليات تنفيذ الأجهزة في السيارات تحدّد android.hardware.camera.any، عندئذٍ:

  • [9.8.2/A-2-1] يجب عرض مؤشر الكاميرا عندما يحصل أحد التطبيقات على إذن بالوصول إلى بيانات الكاميرا المباشرة، ولكن ليس عندما يحصل على إذن بالوصول إلى الكاميرا فقط تطبيقات تمتلك الأدوار المحدّدة المُشار إليها في القسم 9.1 "الأذونات" باستخدام معرّف CDD‏ [C-4-X][C-3-X].
  • [9.8.2/أ-2-2] يجب عدم إخفاء مؤشر الكاميرا في تطبيقات النظام التي تتضمّن واجهات مستخدم مرئية أو تفاعلًا مباشرًا مع المستخدم.

بدء متطلبات جديدة

  • [9.8.2/أ-2-3] يجب توفير عنصر تحكم للمستخدم لتفعيل الكاميرا وإيقافها في تطبيق "الإعدادات".
  • [9.8.2/أ-2-4] يجب عرض التطبيقات المستخدَمة مؤخرًا والنشطة باستخدام الكاميرا كما هو معروض فيPermissionManager.getIndicatorAppOpUsageData()، بالإضافة إلى أي رسائل تحديد مصدر مرتبطة بها.

إنهاء المتطلبات الجديدة

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

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

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

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

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

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

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

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

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

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

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

  • أن يكون حجم شاشة العرض أكبر من 7 بوصات وأصغر من 18 بوصة، ويتم قياسه قطريًا

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

2.6.1. الأجهزة

الجيروسكوب

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.6.2. البرامج

  • [3.2.3.1/Tab-0-1] يجب تحميل تطبيقات أو مكونات خدمة واحدة أو أكثر مسبقًا باستخدام معالِج أهداف، وذلك لجميع نماذج فلاتر الأهداف العامة التي تحدّدها أهداف التطبيقات التالية المدرَجة هنا.

3- البرامج

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

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

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

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

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

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

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

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

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

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

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

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

بدء متطلبات جديدة

  • [C-0-8] يجب ألّا يسمح الجهاز بتثبيت التطبيقات التي تستهدف مستوى واجهة برمجة التطبيقات أقل من 23.

إنهاء المتطلبات الجديدة

3.1.1. إضافات Android

يتيح Android توسيع نطاق واجهة برمجة التطبيقات المُدارة لمستوى معيّن من واجهة برمجة التطبيقات من خلال تعديل إصدار الإضافة لهذا المستوى من واجهة برمجة التطبيقات. تعرض واجهة برمجة التطبيقات android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) إصدار الإضافةapiLevel المقدَّم، في حال توفّر إضافات لمستوى واجهة برمجة التطبيقات هذا.

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

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

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

  • [C-0-3] يجب أن تتوافق مع جميع واجهات برمجة التطبيقات المحدّدة من خلال إصدارات الإضافة التي يعرضها android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) بالطريقة نفسها التي تتوافق بها واجهات برمجة التطبيقات المُدارة الأخرى، وذلك باتّباع requirements في الفقرة 3.1.

3.1.2. مكتبة Android

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

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

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

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

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

3.2.1. الأذونات

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

3.2.2. مَعلمات التصميم

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

  • [C-0-1] لتوفير قيم متسقة وذات مغزى في جميع عمليات تنفيذ الأجهزة، يتضمّن الجدول أدناه قيودًا إضافية على تنسيقات هذه القيم التي يجب أن تتوافق معها عمليات تنفيذ الأجهزة.
المَعلمة التفاصيل
VERSION.RELEASE إصدار نظام Android الذي يتم تنفيذه حاليًا بتنسيق يمكن للمستخدمين قراءته يجب أن يحتوي هذا الحقل على إحدى قيم السلاسل المحدّدة في سلاسل الإصدارات المسموح بها لنظام التشغيل Android 14.
VERSION.SDK إصدار نظام Android الذي يتم تنفيذه حاليًا بتنسيق يمكن لرمز التطبيق التابع لجهة خارجية الوصول إليه بالنسبة إلى Android 14، يجب أن يحتوي هذا الحقل على القيمة الصحيحة 14_INT.
VERSION.SDK_INT إصدار نظام Android الذي يتم تنفيذه حاليًا بتنسيق يمكن لرمز التطبيق التابع لجهة خارجية الوصول إليه بالنسبة إلى Android 14، يجب أن يحتوي هذا الحقل على القيمة الصحيحة 14_INT.
VERSION.INCREMENTAL قيمة يختارها مُنفِّذ الجهاز لتحديد الإصدار المحدد من نظام Android الذي يتم تنفيذه حاليًا، بتنسيق يمكن لشخص عادي قراءته يجب عدم إعادة استخدام هذه القيمة في الإصدارات المختلفة المتاحة للمستخدمين النهائيين. أحد استخدامات هذا الحقل المعتادة هي الإشارة إلى رقم الإصدار أو معرّف تغيير التحكّم في المصدر الذي تم استخدامه لإنشاء الإصدار. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII القابل للطباعة المكوّن من 7 بتات وأن تتطابق مع العبارة العادية "^[^ :\/~]+$".
ألعاب ألواح قيمة يختارها منفذ الجهاز لتحديد المكونات الداخلية المحدّدة التي يستخدمها الجهاز، بتنسيق يمكن لشخص عادي قراءته من بين الاستخدامات المحتملة لهذا الحقل الإشارة إلى المراجعة المحدّدة للوحة التي توفّر питаниеً للجهاز. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بت ويجب أن تتماثل مع التعبير العادي "^[a-zA-Z0-9_-]+$".
العلامة التجارية قيمة تعكس اسم العلامة التجارية المرتبط بالجهاز كما هو معروف للمستخدمين النهائيين يجب أن يكون بتنسيق يسهل قراءته ويجب أن يمثّل الشركة المصنّعة للجهاز أو علامة الشركة التجارية التي يتم تحتها التسويق للجهاز. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9_-]+$".
SUPPORTED_ABIS اسم مجموعة التعليمات (نوع وحدة المعالجة المركزية + اصطلاح ABI) للرمز المبرمَج الأصلي راجِع الفقرة 3.3. توافق واجهة برمجة التطبيقات المدمجة
SUPPORTED_32_BIT_ABIS اسم مجموعة التعليمات (نوع وحدة المعالجة المركزية + اصطلاح ABI) للرمز المبرمَج الأصلي راجِع الفقرة 3.3. توافق واجهة برمجة التطبيقات المدمجة
SUPPORTED_64_BIT_ABIS اسم مجموعة التعليمات الثانية (نوع وحدة المعالجة المركزية + اصطلاح ABI) للرمز البرمجي الأصلي راجِع الفقرة 3.3. التوافق مع واجهة برمجة التطبيقات الأساسية
CPU_ABI اسم مجموعة التعليمات (نوع وحدة المعالجة المركزية + اصطلاح ABI) للرمز المبرمَج الأصلي راجِع الفقرة 3.3. توافق واجهة برمجة التطبيقات المدمجة
CPU_ABI2 اسم مجموعة التعليمات الثانية (نوع وحدة المعالجة المركزية + اصطلاح ABI) للرمز البرمجي الأصلي راجِع الفقرة 3.3. التوافق مع واجهة برمجة التطبيقات الأساسية
الجهاز قيمة يختارها منفذ الجهاز تحتوي على اسم التطوير أو الاسم الرمزي الذي يحدِّد إعدادات ميزات الجهاز والتصميم الصناعي للجهاز. يجب أن تكون قيمة هذا الحقل قابلة للترميز على أنّها 7 بت ASCII وأن تتطابق مع التعبير العادي “^[a-zA-Z0-9_-]+$”. يجب ألّا يتغيّر اسم الجهاز هذا أثناء فترة استخدام المنتج.
بصمة الإصبع سلسلة تحدّد هذا الإصدار بشكل فريد يجب أن يكون سهل القراءة إلى حدٍّ معقول. يجب أن يتّبع هذا النموذج:

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

مثلاً:

acme/myproduct/
    mydevice:14/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._-]+$”.
الشركة المصنّعة الاسم التجاري للمصنّع الأصلي للجهاز الذي يصنع المنتج ما مِن متطلبات حول التنسيق المحدّد لهذا الحقل، باستثناء أنّه يجب ألّا يكون فارغًا أو سلسلة فارغة (""). يجب ألّا يتغيّر هذا الحقل خلال فترة توفّر المنتج.
SOC_MANUFACTURER الاسم التجاري للشركة المصنّعة للمنظومة الأساسية على الرقاقة (SoC) المستخدَمة في المنتج. يجب أن تستخدم الأجهزة التي تحمل الشركة المصنّعة نفسها للنظام على الرقاقة القيمة الثابتة نفسها. يُرجى طلب المتغيّر الصحيح من الشركة المصنّعة لوحدة التحكّم في الشريحة. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات، ويجب أن تتطابق مع التعبير العادي "^([0-9A-Za-z ]+)"، ويجب ألّا تبدأ بمسافة أو تنتهي بها، ويجب ألّا تساوي "غير معروف". ويجب ألّا يتغيّر هذا الحقل خلال فترة استخدام المنتج.
SOC_MODEL اسم طراز المنظومة الأساسية على الرقاقة (SoC) المستخدَمة في المنتج. يجب أن تستخدم الأجهزة التي تتضمّن طراز وحدة المعالجة المركزية (SOC) نفسه القيمة الثابتة نفسها. يُرجى سؤال الشركة المصنّعة لوحدة التحكّم في الشريحة عن القيمة الثابتة الصحيحة التي يجب استخدامها. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي "^([0-9A-Za-z ._/+-]+)$"، ويجب ألّا تبدأ أو تنتهي بمسافة بيضاء، ويجب ألّا تساوي "غير معروف". يجب ألّا يتغيّر هذا الحقل أثناء فترة استخدام المنتج.
الطراز قيمة يختارها منفذ الجهاز تحتوي على اسم الجهاز كما يعرفه المستخدم النهائي. يجب أن يكون هذا هو الاسم نفسه الذي يتم بموجبه تسويق الجهاز وبيعه للمستخدمين النهائيين. ما مِن متطلبات تتعلّق بالتنسيق المحدّد لهذا الحقل، باستثناء أنّه يجب ألا يكون فارغًا أو سلسلة فارغة (""). يجب ألا يتغيّر هذا الحقل خلال فترة توفّر المنتج.
المنتج قيمة يختارها مُنفِّذ الجهاز تحتوي على اسم التطوير أو الاسم الرمزي للمنتج المحدّد (رمز التخزين التعريفي) الذي يجب أن يكون فريدًا ضمن العلامة التجارية نفسها. يجب أن تكون قابلة للقراءة من قِبل البشر، ولكن ليس بالضرورة أن تكون مخصّصة للعرض من قِبل المستخدمين النهائيين. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بت ويجب أن تتطابق مع التعبير العادي "^[a-zA-Z0-9_-]+$". ويجب ألّا يتغيّر اسم المنتج خلال فترة استخدام المنتج.
ODM_SKU قيمة اختيارية يختارها منفذ الجهاز تحتوي على رمز التخزين التعريفي (SKU) المستخدَم لتتبُّع إعدادات محدّدة للجهاز، مثل أي أجهزة ملحقة مضمّنة مع الجهاز عند بيعه. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي ^([0-9A-Za-z.,_-]+)$.
SERIAL يجب أن يعرض العنصر القيمة "UNKNOWN".
العلامات قائمة مفصولة بفواصل بالعلامات التي اختارها مُنفِّذ الجهاز والتي تُميِّز الإصدار بشكلٍ أكبر يجب أن تكون العلامات قابلة للترميز بترميز ASCII المكوّن من 7 بت وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9._-]+"، ويجب أن تتضمن إحدى القيم المقابلة لإعدادات توقيع نظام التشغيل Android الثلاثة النموذجية: مفاتيح الإصدار ومفاتيح المطوّرين ومفاتيح الاختبار.
الوقت قيمة تمثّل الطابع الزمني لوقت إنشاء الإصدار
النوع قيمة يختارها مُنفِّذ الجهاز لتحديد إعدادات وقت التشغيل للإصدار يجب أن يحتوي هذا الحقل على إحدى القيم التالية التي تتوافق مع الإعدادات الثلاثة المعتادة لوقت تشغيل Android: user أو userdebug أو eng.
المستخدم اسم أو رقم تعريف المستخدم (أو المستخدم المبرمَج) الذي أنشأ النسخة ما مِن متطلبات بشأن التنسيق المحدّد لهذا الحقل، باستثناء أنّه يجب ألّا يكون فارغًا أو سلسلة فارغة ("").
SECURITY_PATCH قيمة تشير إلى مستوى تصحيح الأمان لإصدار معيّن يجب أن يشير ذلك إلى أنّ الإصدار ليس معرّضًا بأي شكل من الأشكال لأي من المشاكل الموضّحة في نشرة أمان Android العامة المحدّدة. يجب أن تكون بالتنسيق [YYYY-MM-DD]، وأن تتطابق مع سلسلة محدّدة موثّقة في نشرة أمان Android العامة أو في إشعار أمان Android، على سبيل المثال "‎2015-11-01".
BASE_OS قيمة تمثّل مَعلمة FINGERPRINT للإصدار الذي هو مطابق لهذا الإصدار باستثناء الرقع المقدَّمة في نشرة الأمان العام لنظام التشغيل Android يجب أن يعرض الإصدار القيمة الصحيحة، وإذا لم يكن هذا الإصدار متوفّرًا، يجب عرض سلسلة فارغة ("").
برنامج تحميل التشغيل قيمة يختارها منفذ الجهاز لتحديد إصدار bootloader الداخلي المُستخدَم في الجهاز بتنسيق يمكن لشخص عادي قراءته يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9._-]+$".
getRadioVersion() يجب أن تكون (أو تعرض) قيمة يختارها منفذ الجهاز لتحديد إصدار الراديو/المودم الداخلي المحدّد المستخدَم في الجهاز، بتنسيق يمكن لشخص عادي قراءته. إذا لم يكن الجهاز يحتوي على أي إشارة تردد لاسلكي/مودم داخلي، يجب أن يعرض القيمة NULL. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي “^[a-zA-Z0-9._-,]+$”.
getSerial()‎ يجب أن يكون (أو يعرض) رقمًا تسلسليًا للأجهزة، ويجب أن يكون متاحًا وفريدًا على مستوى الأجهزة التي تحمل الطراز والشركة المصنّعة نفسها. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي “^[a-zA-Z0-9]+$”.

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

3.2.3.1. نوايا التطبيقات الشائعة

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

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

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

يُرجى الرجوع إلى القسم 2 للاطّلاع على أذونات التطبيقات الإلزامية لكل نوع من أنواع الأجهزة.

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

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

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

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

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

  • [C-0-4] يجب محاولة التحقّق من صحة أي فلاتر أهداف من خلال تنفيذ خطوات التحقّق المحدّدة في مواصفات روابط التنقل إلى مواد العرض الرقمية كما نفّذها "مدير الحِزم" في "مشروع Android Open Source" المرتبط.
  • [C-0-5] يجب محاولة التحقّق من فلاتر الأهداف أثناء تثبيت التطبيق وضبط جميع فلاتر أهداف عناوين URL التي تم التحقّق منها بنجاح على أنّها معالجات التطبيقات التلقائية لعناوين URL الخاصة بها.
  • يجوز لها ضبط فلاتر أهداف معيّنة لعناوين URL كمعالِجات تطبيق تلقائية لمعرّفات URL الخاصة بها، إذا تم التحقّق منها بنجاح ولكن تعذّر التحقّق من فلاتر عناوين URL المعنيّة الأخرى. إذا كان تنفيذ الجهاز يفعل ذلك، يجب أن يقدّم عمليات إلغاء أنماط لكل معرّف موارد منتظم (URI) مناسبة للمستخدم في قائمة الإعدادات.
  • يجب أن يوفّر التطبيق للمستخدم عناصر تحكّم في "روابط التطبيقات" لكل تطبيق في "الإعدادات" على النحو التالي:
    • [C-0-6] يجب أن يتمكّن المستخدم من إلغاء السلوك التلقائي ل روابط التطبيقات بشكل كامل لكي يكون التطبيق: مفتوحًا دائمًا أو يسأل المستخدم دائمًا أو لا يفتح أبدًا، وذلك يجب أن ينطبق على جميع فلاتر الأغراض لمعرّفات الموارد المنتظمة المعنيّة بالتساوي.
    • [C-0-7] يجب أن يتمكّن المستخدم من الاطّلاع على قائمة بفلاتر بنية 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). تعتمد بعض نوايا البث أيضًا على توفُّر الأجهزة اللازمة، فإذا كان الجهاز يتضمّن الأجهزة اللازمة، يجب أن يبث رسائل برمجية لتنفيذ هذه النوايا وأن يقدّم السلوك بما يتوافق مع مستندات حزمة SDK.
3.2.3.5. نوايا التطبيقات المشروطة

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

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

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

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

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

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

  • [C-3-1] يجب الالتزام بهدف android.settings.NFC_PAYMENT_SETTINGS لعرض قائمة إعدادات تلقائية للتطبيق للدفع بدون تلامس الأجهزة.
  • [C-3-2] يجب الالتزام بغرض android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT لعرض نشاط يفتح مربّع حوار لطلب المستخدم تغيير خدمة محاكاة البطاقات التلقائية لفئة معيّنة كما هو موضّح في حزمة تطوير البرامج (SDK).

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

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

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

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

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

  • [C-7-1] يجب توفير آلية يمكن للمستخدم الوصول إليها لإضافة أساليب إدخال تابعة لجهات خارجية وضبطها استجابةً لمحاولة android.settings.INPUT_METHOD_SETTINGS التفاعل.

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

  • [C-8-1] يجب الالتزام android.settings.ACCESSIBILITY_SETTINGS بهدف توفير آلية يمكن للمستخدم الوصول إليها لتفعيل خدمات تسهيل الاستخدام التابعة لجهات خارجية وإيقافها إلى جانب خدمات تسهيل الاستخدام المثبَّتة مسبقًا.

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-16-1] يجب عرض هذه الروابط لجميع خدمات الملء التلقائي المثبَّتة.

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

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

  • [C-SR-3] يُنصح بشدة بتوفير نشاط لتنفيذ طلبات android.intent.action.TTS_SERVICE و android.speech.tts.engine.INSTALL_TTS_DATA و android.speech.tts.engine.GET_SAMPLE_TEXT كما هو موضّح في حزمة تطوير البرامج (SDK) هنا.

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

  • يجب أن تتضمّن ميزة توفير خلفيات شاشة وأن تقدّم خيار إعدادات لسماح للمستخدمين بضبط خلفيات الشاشة استجابةً لintent android.settings.DREAM_SETTINGS.

بدء متطلبات جديدة

إذا أبلغت عمليات تنفيذ الأجهزة عن android.hardware.nfc.uicc أو android.hardware.nfc.ese، يحدث ما يلي:

إنهاء المتطلبات الجديدة

3.2.4. الأنشطة على الشاشات الثانوية/المتعدّدة

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-0-9] يجب إدراج مكتبات إضافية غير تابعة لمشروع AOSP ومفتوحة مباشرةً أمام التطبيقات التابعة لجهات خارجية في /vendor/etc/public.libraries.txt.

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

  • [C-0-11] يجب تصدير جميع رموز دوال OpenGL ES 3.1 ومجموعة ملحقات Android ، كما هو محدّد في حزمة NDK، من خلال مكتبة libGLESv3.so. يُرجى العلم أنّه على الرغم من أنّه يجب أن تكون جميع الرموز متوفّرة، يصف القسم 7.1.4.1 بمزيد من التفصيل متطلبات وقت التنفيذ الكامل لكلٍّ من الدوالّ المقابلة.

  • [C-0-12] يجب تصدير رموز الدوالّ الأساسية لإصدار Vulkan 1.0 Vulkan 1.1 ، بالإضافة إلى رموز الدوالّ الموسّعة VK_KHR_surface وVK_KHR_android_surface VK_KHR_swapchain وVK_KHR_maintenance1 VK_KHR_get_physical_device_properties2 من خلال مكتبة libvulkan.so. يُرجى العِلم أنّه على الرغم من أنّه يجب أن تكون جميع الرموز متوفّرة، فإنه في الفقرة 7.1.4.2 описано بمزيد من التفصيل متطلبات تنفيذ كل دالة مقابلة بشكل كامل.

  • يجب إنشاؤها باستخدام رمز المصدر وملفات الرأس المتاحة في الإصدار الأحدث من مشروع Android Open Source Project.

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

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

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

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

إذا أبلغت عمليات تنفيذ الأجهزة عن توافقها مع ABI‏ armeabi-v7a، بالنسبة إلى التطبيقات التي تستخدم ABI هذا، يتم تنفيذ ما يلي:

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

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

    • تعليمات SWP وSWPB
    • عمليات الحواجز 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" في الإصدار 14 من Android لتنفيذ واجهة برمجة التطبيقات 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.
    • قد تحذف عمليات تنفيذ الأجهزة كلمة Mobile في سلسلة وكيل المستخدم.
  • يجب أن يتضمّن مكوّن WebView ميزات HTML5 بقدرٍ كبيرٍ ممكن، وإذا كان يتيح استخدام ميزة معيّنة، يجب أن يكون متوافقًا مع مواصفات HTML5.

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

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

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

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

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

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

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

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

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

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

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

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

إذا كانت عمليات تنفيذ الأجهزة تُنفِّذ آلية خاصة بحظر التطبيقات (مثل تغيير سلوكيات واجهة برمجة التطبيقات أو حظرها والتي описанة في حزمة تطوير البرامج (SDK)) وكانت هذه الآلية أكثر تقييدًا من مجموعة التطبيقات المحظورة في وضع الاستعداد، يجب استيفاء الشروط التالية:

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

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

  • [C-1-5] يجب إبلاغ المستخدمين إذا تم تطبيق هذه القيود المتعلقة بالملكية على تطبيق تلقائيًا. يجب تقديم هذه المعلومات خلال فترة 24 ساعة قبل تطبيق هذه القيود المتعلقة بالملكية.

  • [C-1-6] يجب أن تُعرِض القيمة true لطريقة ActivityManager.isBackgroundRestricted()‎ لأي طلبات بيانات من واجهة برمجة التطبيقات من أحد التطبيقات.

  • [C-1-7] يجب عدم حظر التطبيق الأهم في المقدّمة والذي يستخدمه المستخدم صراحةً.

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

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

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

إذا كان التطبيق مثبّتًا مسبقًا على الجهاز ولم يستخدمه أحد المستخدمين بشكل صريح لأكثر من 30 يومًا، يتم استثناء [C-1-3] [C-1-5].

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

  • [C-2-1]يجب اتّباع خطوات التنفيذ الموضّحة في هذا المستند.

3.5.2. إسبات التطبيق

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

  • يجب أن يستوفي [C-1-1] جميع المتطلبات الواردة في القسم 3.5.1 باستثناء [C-1-6] و[C-1-3].
  • [C-1-2] يجب عدم تطبيق القيود على التطبيق إلا إذا توفّر دليل على أنّ المستخدم لم يستخدم التطبيق لفترة زمنية معيّنة. ننصح بشدة بأن تكون هذه المدة شهرًا واحدًا أو أكثر. يجب تحديد الاستخدام إما من خلال تفاعل المستخدم الصريح من خلال واجهة برمجة التطبيقات UsageStats#getLastTimeVisible() أو أي إجراء قد يتسبب في خروج التطبيق من حالة الإيقاف القسري، بما في ذلك عمليات ربط الخدمات وعمليات ربط موفّري المحتوى وعمليات البث الصريحة وما إلى ذلك، وسيتم تتبُّعها من خلال واجهة برمجة التطبيقات الجديدة UsageStats#getLastTimeAnyComponentUsed().
  • [C-1-3] يجب عدم تطبيق القيود التي تؤثر في جميع مستخدمي الجهاز إلا عند توفُّر دليل على عدم استخدام أي مستخدم للحزمة لفترة معيّنة من الزمن. ننصحك بشدة بأن تكون هذه المدة شهرًا واحدًا أو أكثر.
  • [C-1-4] يجب ألّا تؤدي إلى منع التطبيق من الاستجابة لطلبات النشاط أو عمليات ربط الخدمات أو طلبات مقدّمي المحتوى أو عمليات البث الصريحة.

تستوفي ميزة "وضع السكون للتطبيقات" في AOSP المتطلبات المذكورة أعلاه.

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

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

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

وهذا يعني أنّها:

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

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

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

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

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

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

  • [C-1-1] يجب ألّا تكون في مكتبة NDK أو مكتبة مملوكة لمؤسسة أخرى كما هو موضّح هنا.

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

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

3.7 التوافق مع بيئة التشغيل

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-6-1] يجب عدم استخدامها إلا عندما يفعّلها المستخدم صراحةً (مثلاً من خلال الإعدادات أو قائمة اختيار الخلفية).

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

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

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

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

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

  • قد تتيح التطبيقات المصغّرة على شاشة القفل.

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

3.8.3. الإشعارات

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

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

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

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

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

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

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

  • يجب أن تتيح إرسال إشعارات غنية.

  • يجب عرض بعض الإشعارات ذات الأولوية الأعلى كإشعارات تنبيه.

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

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

يقدّم الإصدار 11 من Android ميزة إشعارات المحادثات، وهي إشعارات تستخدِم MessagingStyle وتوفّر معرّف اختصار الأشخاص منشورًا.

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

  • [C-SR-4] يُنصح بشدة بتجميع إشعارات conversation notifications وعرضها قبل الإشعارات غير المتعلّقة بالمحادثات، باستثناء إشعارات الخدمات التي تعمل في المقدّمة وإشعارات importance:high.

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

  • [C-SR-5] يُنصح بشدة بعرض هذه المحادثة كفقاعة محادثة. يستوفي تطبيق AOSP هذه المتطلبات من خلال واجهة المستخدم التلقائية للنظام والإعدادات وقاذفة التطبيقات.

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

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

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

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

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

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

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

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

3.8.4. واجهات برمجة تطبيقات Assist

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

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

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

3.8.5. التنبيهات والرسائل المنبثقة

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

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

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

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

3.8.6. المظاهر

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

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

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

  • [C-1-1] يجب عدم تغيير أي من سمات مظهر Holo المعروضة للتطبيقات.
  • [C-1-2] يجب أن تكون متوافقة مع عائلة المظاهر "المادية"، ويجب ألّا تغيّر أيًا من سمات المظهر المادي أو مواد العرض المعروضة للتطبيقات.
  • [C-1-3] يجب ضبط عائلة الخطوط "sans-serif" على الإصدار 2.x من Roboto للغات التي يتوافق معها Roboto، أو توفير عنصر تحكم للمستخدم لتغيير الخط المستخدَم لعائلة الخطوط "sans-serif" إلى الإصدار 2.x من Roboto للغات التي يتوافق معها Roboto.

  • [C-1-4] يجب إنشاء لوحات ألوان ديناميكية كما هو محدّد في مستندات AOSP الخاصة بـ Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (راجِع android.theme.customization.system_palette و android.theme.customization.theme_style).

  • [C-1-5] يجب إنشاء لوحات ألوان ديناميكية باستخدام أنماط مظاهر الألوان المُدرَجة في مستندات Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (راجِع android.theme.customization.theme_styles)، مثل TONAL_SPOT وVIBRANT وEXPRESSIVE وSPRITZ وRAINBOW وFRUIT_SALAD ووMONOCHROMATIC.

    "لون المصدر" المستخدَم لإنشاء لوحات ألوان ديناميكية عند إرسالها مع android.theme.customization.system_palette (كما هو موضّح في Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES).

  • [C-1-6] يجب أن تكون قيمة معلومات CAM16 اللونية 5 أو أكبر.

    • يجب أن يتم استخراجه من الخلفية من خلال com.android.systemui.monet.ColorScheme#getSeedColors، الذي يقدّم عدة ألوان مصدر صالحة للاختيار من بينها.

    • يجب استخدام القيمة 0xFF1B6EF3 إذا لم تستوفِ أي من الألوان المقدَّمة متطلبات لون المصدر أعلاه.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-1-1] يجب أن تتيح عرض ما يصل إلى 7 أنشطة على الأقل.
  • يجب أن يعرض عنوان 4 أنشطة على الأقل في المرة الواحدة.

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

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

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

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

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

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

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

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

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

راجِع القسم 3.2.3.5 للاطّلاع على إعدادات intent لضبط حوامل الشاشة.

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

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

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

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

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

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

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

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

يتيح نظام التشغيل Android عرض خطوط ميانمار. تستخدم ميانمار عدة خطوط غير متوافقة مع Unicode، وتُعرف هذه الخطوط عادةً باسم "Zawgyi"، وهي مخصّصة لعرض محتوى بلغات ميانمار.

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

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

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

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

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

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

  • [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 كما هو موضح في نشاط وضع الصورة في الصورة الحالي من خلال واجهة برمجة التطبيقات setActions().
  • [C-3-3] يجب أن تتيح استخدام نسب عرض إلى ارتفاع أكبر من أو تساوي 1:2.39 وأصغر من أو تساوي 2.39:1، كما هو محدّد في نشاط "صورة داخل صورة" من خلال واجهة برمجة التطبيقات setAspectRatio().
  • [C-3-4] يجب استخدام KeyEvent.KEYCODE_WINDOW للتحكّم في نافذة الصورة في الصورة. وفي حال عدم تنفيذ وضع الصورة في الصورة، يجب أن يكون المفتاح متاحًا للنشاط الذي يظهر في المقدّمة.
  • [C-3-5] يجب أن يقدّم التطبيق ميزة تتيح للمستخدم حظر عرض التطبيق في وضع "صورة في صورة"، ويلبي تطبيق AOSP هذا الشرط من خلال توفير عناصر تحكّم في نافذة الإشعارات.
  • [C-3-6] يجب تخصيص الحد الأدنى التالي للعرض والارتفاع لملف PIP العرضي عندما لا يعلن التطبيق عن أي قيمة لسمتي AndroidManifestLayout_minWidth وAndroidManifestLayout_minHeight:

    • بالنسبة إلى الأجهزة التي تم ضبط ‎Configuration.uiMode فيها على قيمة غير UI_MODE_TYPE_TELEVISION ، يجب أن يكون الحد الأدنى للعرض والارتفاع 108 dp.
    • بالنسبة إلى الأجهزة التي تم ضبط Configuration.uiMode فيها على UI_MODE_TYPE_TELEVISION ، يجب أن يكون الحد الأدنى للعرض 240 بكسل مستقل الكثافة والحد الأدنى للارتفاع 135 بكسل مستقل الكثافة.

3.8.15. جزء مقتطع من الشاشة

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

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

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

3.8.16. عناصر التحكّم بالأجهزة

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

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

3.8.17. الحافظة

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

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

إذا كانت عمليات تنفيذ الأجهزة تنشئ معاينة مرئية للمستخدم عند نسخ المحتوى إلى الحافظة لأي عنصر ClipData حيث يحتوي ClipData.getDescription().getExtras() على android.content.extra.IS_SENSITIVE، فإنّها:

  • [C-1-1] يجب إخفاء المعاينة الظاهرة للمستخدم

يستوفي التنفيذ المرجعي لنظام التشغيل AOSP متطلبات الحافظة هذه.

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

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

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

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

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

3.9.1.1 إعداد حساب مالك الجهاز

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

  • [C-1-1] يجب أن يتيح التطبيق تسجيل "وحدة تحكّم بسياسة الجهاز" (DPC) كأحد تطبيقات مالك الجهاز على النحو الموضّح أدناه:
    • عندما لا يتضمّن تنفيذ الجهاز مستخدمين أو بيانات مستخدمين تم ضبطها، يتم تنفيذ ما يلي:
      • [C-1-5] يجب تسجيل تطبيق إدارة الخدمات الجوّالة للمؤسسات (DPC) كتطبيق "مالك الجهاز" أو تفعيل تطبيق إدارة الخدمات الجوّالة للمؤسسات (DPC) لاختيار ما إذا كان يريد أن يصبح "مالك جهاز" أو "مالك ملف شخصي"، إذا كان الجهاز يعلن عن توفّر تقنية "الاتصال القريب المدى" (NFC) من خلال علامة ميزة android.hardware.nfc ويتلقّى رسالة NFC تحتوي على سجلّ بنوع MIME MIME_TYPE_PROVISIONING_NFC.
      • [C-1-8] يجب إرسال ACTION_GET_PROVISIONING_MODE intent بعد بدء عملية إعداد مالك الجهاز حتى تتمكّن تطبيق DPC من اختيار ما إذا كان سيصبح مالك جهاز أو ملف شخصي مالكًا، استنادًا إلى قيم android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES، ما لم يكن من الممكن تحديد السياق أنّ هناك خيارًا صالحًا واحدًا فقط.
      • [C-1-9] يجب إرسال ACTION_ADMIN_POLICY_COMPLIANCE بهدف إلى تطبيق "مالك الجهاز" في حال تم إنشاء مالك جهاز أثناء عملية الإعداد بغض النظر عن طريقة الإعداد المستخدَمة. يجب ألا يتمكّن المستخدم من المتابعة في معالج الإعداد إلى أن ينتهي تطبيق "مالك الجهاز".
    • عندما يتضمّن تطبيق الجهاز مستخدمين أو بيانات مستخدمين، يتم تنفيذ ما يلي:
      • [C-1-7] يجب عدم تسجيل أي تطبيق DPC كتطبيق "مالك الجهاز" بعد الآن.
  • [C-1-2] يجب أن يعرض إشعار إفصاح مناسبًا (مثل ما هو مذكور في AOSP) وأن يحصل على موافقة إيجابية من المستخدم النهائي قبل تحديد أحد التطبيقات بصفته مالك الجهاز، ما لم يتم ضبط الجهاز آليًا على وضع العرض التجريبي للبيع بالتجزئة قبل تفاعل المستخدم النهائي على الشاشة. إذا كانت عمليات تنفيذ الأجهزة تُعلن عن android.software.device_admin، ولكنها أيضًا تتضمّن حلّ إدارة جهاز ملكيًا وتوفر آلية لتعزيز تطبيق تم ضبطه في حلّها على أنّه "مكافئ مالك الجهاز" للتطبيق العادي "مالك الجهاز" كما هو معترف به من واجهات برمجة التطبيقات العادية لنظام التشغيل Android DevicePolicyManager، يجب أن تستوفي المتطلبات التالية:

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

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

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

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
    • رمز تطبيق "مركز التحكّم في البيانات"
  • [C-1-4] يجب تشغيل معالِج طلب ACTION_PROVISIONING_SUCCESSFUL في الملف الشخصي للعمل في حال تم إنشاء مالك ملف شخصي عند بدء عملية الإعداد من خلال طلب android.app.action.PROVISION_MANAGED_PROFILE وتنفيذ وحدة التحكّم في نقطة النهاية (DPC) للمعالِج.

  • [C-1-5] يجب إرسال بث ACTION_PROFILE_PROVISIONING_COMPLETE إلى DPC الخاص بملف العمل عند بدء عملية الإعداد من خلال android.app.action.PROVISION_MANAGED_PROFILE intent.

  • [C-1-6] يجب إرسال ACTION_GET_PROVISIONING_MODE intent بعد بدء عملية إعداد مالك الملف الشخصي حتى تتمكّن تطبيق إدارة الخدمات الجوّالة للمؤسسات (DPC) من اختيار ما إذا كان يريد أن يصبح مالك جهاز أو مالك ملف شخصي، باستثناء الحالات التي يتم فيها بدء عملية الإعداد من خلال android.app.action.PROVISION_MANAGED_PROFILE.

  • [C-1-7] يجب إرسال ACTION_ADMIN_POLICY_COMPLIANCE القصد إلى الملف الشخصي للعمل عند إنشاء مالك ملف أثناء الإعداد بغض النظر عن طريقة الإعداد المستخدَمة إلا عند بدء الإعداد من خلال القصد android.app.action.PROVISION_MANAGED_PROFILE. يجب ألا يتمكّن المستخدم من المتابعة في معالج الإعداد إلى أن ينتهي تطبيق "ملف العميل المالك".

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

بدء متطلبات جديدة

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

إنهاء المتطلبات الجديدة

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

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

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

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

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

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

  • [C-SR-1] يُنصح بشدة بعرض بيانات الإفصاح عن الموافقة على AOSP Device نفسها التي تم عرضها في العملية التي بدأها android.app.action.PROVISION_MANAGED_DEVICE، قبل السماح بإضافة حسابات في المستخدم الثانوي الجديد، لكي يفهم المستخدمون أنّ الجهاز مُدار.

3.9.4 متطلبات دور "إدارة سياسات الجهاز"

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

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

في حال عدم تحديد اسم حزمة لـ config_devicePolicyManagement كما هو описан أعلاه:

إذا تم تحديد اسم حزمة لـ config_devicePolicyManagement كما هو موضّح أعلاه:

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

في حال تحديد اسم حزمة لـ config_devicePolicyManagementUpdater كما هو описан أعلاه:

  • [C-4-1] يجب أن يكون التطبيق مثبَّتًا مسبقًا على الجهاز.
  • [C-4-2] يجب أن ينفِّذ التطبيق فلتر طلبات بحث يحلّ android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER.

بدء متطلبات جديدة

3.9.5 إطار عمل حلّ المشاكل في سياسة الجهاز

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

إنهاء المتطلبات الجديدة

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

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

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

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

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

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

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

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

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

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

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

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

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

إذا كانت عمليات تنفيذ الأجهزة متوافقة مع 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-1-1] يجب عدم منح التطبيقات الفورية سوى الأذونات التي تم ضبط android:protectionLevel على "instant".
  • [C-1-2] يجب ألّا تتفاعل التطبيقات الفورية مع التطبيقات المثبّتة من خلال المهام الضمنية ما لم يكن أحد الشروط التالية صحيحًا:
    • يتم عرض فلتر نمط أهداف المكوّن ويتضمّن CATEGORY_BROWSABLE.
    • الإجراء هو أحد الإجراءات التالية: ACTION_SEND أو ACTION_SENDTO أو ACTION_SEND_MULTIPLE
    • يتم عرض الهدف بشكل صريح باستخدام android:visibleToInstantApps
  • [C-1-3] يجب ألّا تتفاعل التطبيقات الفورية بشكل صريح مع التطبيقات المثبّتة ما لم يتم عرض العنصر باستخدام android:visibleToInstantApps.
  • [C-1-4] يجب ألا تظهر تفاصيل عن التطبيقات الفورية على الجهاز للتطبيقات المثبَّتة ما لم يتصل التطبيق الفوري بالتطبيق المثبَّت بشكل صريح.
  • يجب أن توفّر عمليات التنفيذ على الأجهزة ميزات الاستخدام التالية للمستخدمين من أجل التفاعل مع التطبيقات الفورية. يستوفي AOSP المتطلبات من خلال واجهة المستخدم و"الإعدادات" و"المشغِّل" التلقائيَين للنظام. عمليات التنفيذ على الأجهزة:

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

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

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

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

3.18. جهات الاتصال

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

تكون RawContacts "مرتبطة" أو "مخزّنة في" Account عندما تتطابق أعمدة ACCOUNT_NAME وACCOUNT_TYPE لجهات الاتصال الأوّلية مع حقلَي Account.name وAccount.type المرتبطَين بالحساب.

الحساب المحلي التلقائي: حساب للجهات التي لم تتم معالجتها والتي يتم تخزينها فقط على الجهاز وغير مرتبطة بحساب في AccountManager، والذي يتم إنشاؤه باستخدام قيم null للعمودين ACCOUNT_NAME، و ACCOUNT_TYPE.

حساب محلي مخصّص: حساب للجهات التي لم تتم معالجتها والتي يتم تخزينها فقط على الجهاز وغير مرتبطة بحساب في AccountManager، ويتم إنشاؤها باستخدام قيمة واحدة على الأقل غير صفرية للعمودين ACCOUNT_NAME و ACCOUNT_TYPE.

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

  • [C-SR-1] يُنصح بشدة بعدم إنشاء حسابات محلية مخصّصة.

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

  • [C-1-1] يجب أن يتم إرجاع ACCOUNT_NAME، من الحساب المحلي المخصّص من قِبل ContactsContract.RawContacts.getLocalAccountName
  • [C-1-2] يجب أن يتم إرجاع ACCOUNT_TYPE، من الحساب المحلي المخصّص من قِبل ContactsContract.RawContacts.getLocalAccountType
  • [C-1-3] يجب إدراج جهات الاتصال الأوّلية التي تُدرجها تطبيقات تابعة لجهات خارجية باستخدام الحساب المحلي التلقائي (أي من خلال ضبط قيم فارغة لملفَّي ACCOUNT_NAME وACCOUNT_TYPE) في الحساب المحلي المخصّص .
  • [C-1-4] يجب عدم إزالة جهات الاتصال الأوّلية التي تم إدراجها في الحساب المحلي المخصّص عند إضافة حسابات أو إزالتها.
  • [C-1-5] يجب أن تؤدي عمليات الحذف التي يتم إجراؤها على الحساب المحلي المخصّص إلى محو جهات الاتصال الأوّلية على الفور (كما لو تم ضبط المَعلمة CALLER_IS_SYNCADAPTER على true)، حتى إذا تم ضبط المَعلمة CALLER\_IS\_SYNCADAPTER على false أو لم يتم تحديدها.

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

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

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

    • بما أنّ الشرط أعلاه قد يكون صعبًا، ننصح باستخدام نظام إدارة الحِزم في التنفيذ المرجعي لنظام التشغيل AOSP عند تنفيذ الأجهزة.
  • [C-0-2] يجب أن تتيح عملية التحقّق من ملفات "‎.apk" باستخدام الإصدار 3.1 من مخطّط توقيع حِزم APK، الإصدار 3 من مخطّط توقيع حِزم APK، الإصدار 2 من مخطّط توقيع حِزم APK وتوقيع JAR.

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

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

  • [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 نفسها على أنّه قد يكون ضارًا.

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

  • [C-0-8] يجب توفير إمكانية استخدام نظام الملفات المتزايد كما هو موضّح في المستندات هنا.

  • [C-0-9] يجب أن يتيح التطبيق التحقّق من ملفات apk .باستخدام الإصدار 4 من مخطّط توقيع حِزم APK و الإصدار 4.1 من مخطّط توقيع حِزم APK.

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

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

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

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

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

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

  • [C-7-1] يجب أن يكون بإمكان التطبيق ضبط عملية فك التشفير باستخدام المفتاح KEY_MAX_OUTPUT_CHANNEL_COUNT للتحكّم في ما إذا كان سيتم تقليل جودة المحتوى إلى صوت استيريو (عند استخدام القيمة 2) أو يتم إخراجه باستخدام العدد الأصلي للقنوات (عند استخدام قيمة مساوية أو أكبر من هذا العدد). على سبيل المثال، ستؤدي القيمة 6 أو أكثر إلى ضبط أداة فك التشفير لإخراج 6 قنوات عند تزويدها بمحتوى بدقة 5.1.
  • [C-7-2] عند فك التشفير، يجب أن يعلن برنامج فك التشفير عن قناع القناة المستخدَم في تنسيق الإخراج باستخدام مفتاح KEY_CHANNEL_MASK ، وذلك باستخدام الثوابت android.media.AudioFormat (على سبيل المثال: CHANNEL_OUT_5POINT1).

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

  • [C-SR-2] يُنصح بشدة بأن يكون من الممكن للتطبيق ضبط وحدة الترميز باستخدام KEY_MAX_OUTPUT_CHANNEL_COUNT للتحكّم في ما إذا كان سيتم تقليل جودة المحتوى إلى صوت استيريو (عند استخدام القيمة 2) أو يتم إخراجه باستخدام العدد الأصلي للقنوات (عند استخدام قيمة مساوية أو أكبر من هذا العدد). على سبيل المثال، ستؤدي القيمة 6 أو أكثر إلى ضبط أداة فك التشفير لإخراج 6 قنوات عند تزويدها بمحتوى بدقة 5.1.
  • [C-SR-3] عند فك التشفير، يُنصح بشدة باستخدام وحدة فك التشفير للإعلان عن قناع القناة المستخدَم في تنسيق الإخراج باستخدام KEY_CHANNEL_MASK المفتاح، وذلك باستخدام الثوابت android.media.AudioFormat (مثال: CHANNEL_OUT_5POINT1).

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

التنسيق/برنامج الترميز التفاصيل أنواع الملفات/تنسيقات الحاويات المتوافقة
الملف الشخصي لبرنامج الترميز المتقدّم للصوت (AAC) في MPEG-4
(AAC LC)
إتاحة المحتوى أحادي الصوت/ستيريو/5.0/5.1 بمعدّلات قياسية للتسجيل من 8 إلى 48 كيلوهرتز
  • 3GPP (‎.3gp)
  • ‫MPEG-4 (‎.mp4 و‎.m4a)
  • ‫ADTS raw AAC (‎.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
الملف الشخصي (الترميز المحسّن للصوت بترميز متقدّم)
إتاحة محتوى صوت أحادي/استيريو/5.0/5.1 بمعدّلات قياسية للبيانات في الملف الصوتي من 16 إلى 48 كيلوهرتز
  • 3GPP (‎.3gp)
  • ‫MPEG-4 (‎.mp4 و‎.m4a)
الترميز المتقدّم للصوت بوقت استجابة منخفض (AAC ELD) إتاحة المحتوى الصوتي الأحادي أو الاستيريو بمعدّلات بيانات عادية تتراوح بين 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 كيلوبت في الثانية (معدل نقل بيانات ثابت) أو بمعدّل نقل بيانات متغيّر (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)
  • iMelody ‏(‎.imy)
Vorbis فك التشفير: يتيح الجهاز فك تشفير المحتوى الأحادي الصوت والصوت الاستيريو وصوت 5.0 و5.1 بمعدّلات قياس إشارة تبلغ 8000 و12000 و16000 و24000 و48000 هرتز.
تشفير الصوت: يتيح الجهاز تشفير المحتوى الأحادي الصوت والصوت الاستيريو بمعدّلات قياس إشارة تبلغ 8000 و12000 و16000 و24000 و48000 هرتز.
  • Ogg (‎.ogg)
  • ‫MPEG-4 (‎.mp4 و‎.m4a، فك التشفير فقط)
  • Matroska (‎.mkv)
  • Webm ‏(‎.webm)
PCM/WAVE يجب أن يتيح برنامج ترميز PCM تنسيق PCM الخطي بترميز 16 بت وتنسيق PCM العائم بترميز 16 بت. يجب أن يتيح مستخرج WAVE ترميز PCM الخطي بسعة 16 بت و24 بت و32 بت وتنسيق PCM المتغير بسعة 32 بت (بمعدلات تصل إلى الحد الأقصى للأجهزة). يجب أن تكون معدّلات أخذ العينات متوافقة من 8 كيلوهرتز إلى 192 كيلوهرتز. WAVE (‎.wav)
Opus فك التشفير: يتيح الجهاز فك تشفير المحتوى الأحادي الصوت والصوت الاستيريو وصوت 5.0 و5.1 بمعدّلات أخذ العينات 8000 و12000 و16000 و24000 و48000 هرتز.
التشفير: يتيح الجهاز تشفير المحتوى الأحادي الصوت والصوت الاستيريو بمعدّلات أخذ العينات 8000 و12000 و16000 و24000 و48000 هرتز.
  • 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

بدء متطلبات جديدة

  • [C-0-4] AVIF
    • يجب أن تتوافق الأجهزة مع BITRATE_MODE_CQ و"ملف العمل الأساسي".

إنهاء المتطلبات الجديدة

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

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

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

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

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

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

إذا كانت عمليات تنفيذ الأجهزة تتيح فك ترميز الفيديو بتنسيق HEVC، يجب أن تستوفي المتطلبات التالية: * [C-1-1] يجب أن تتيح فك ترميز الصور بتنسيق HEIF (HEIC).

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

  • [C-2-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)
AVIF (الملف الشخصي الأساسي) ملف مرجعي للصور ومجموعات الصور وتسلسل الصور حاوية HEIF (‎.avif)

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

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

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

  • [C-1-3] يجب أن يكون الجهاز متوافقًا مع أحد تنسيقَي ‎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 8:8:8 المسطحة أو شبه المسطحة: COLOR_FormatYUV420PackedPlanar (المكافئ COLOR_FormatYUV420Planar) أو COLOR_FormatYUV420PackedSemiPlanar (المكافئ COLOR_FormatYUV420SemiPlanar). ننصح بشدة باستخدام كليهما.

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

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

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

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

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

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

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

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

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

التنسيق/برنامج الترميز التفاصيل أنواع الملفات/تنسيقات الحاويات المتوافقة
‫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، فك التشفير فقط)
VP8 راجِع الفقرة 5.2 و 5.3 للاطّلاع على التفاصيل.
VP9 راجِع الفقرة 5.3 لمعرفة التفاصيل.
AV1 راجِع الفقرة 5.2 والفقرة 5.3 للاطّلاع على التفاصيل.
  • MPEG-4 (‎.mp4)
  • Matroska (‎.mkv، فك التشفير فقط)

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

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

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

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

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

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

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

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

  • [C-3-1] يجب أن يتضمّن البرنامج برنامج ترميز Codec 2.0 المقابل من مشروع Android Open Source Project (إذا كان متاحًا) لكل تنسيق وسائط ونوعها (برنامج ترميز أو فك ترميز) متوافق مع الجهاز.
  • [C-3-2] يجب أن تتضمّن برامج الترميز 2.0 برامج الترميز البرمجية في عملية الترميز البرمجي كما هو موضّح في مشروع Android Open Source Project لكي يصبح من الممكن منح إذن الوصول إلى برامج الترميز البرمجية بشكل أكثر تقييدًا.
  • [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 ويجب أن تتوافق الأسماء مع إرشادات تسمية Codec 2.0 لنظام التشغيل Android.
  • [C-1-4] برامج الترميز التي تحمل أسماء تبدأ بـ "OMX.google." أو "c2.android." يجب عدم تصنيفها على أنّها من المورّدين أو مُسرَّعة بالأجهزة.
  • [C-1-5] يجب عدم تحديد برامج الترميز التي تعمل في عملية ترميز (للمورّد أو النظام) والتي يمكنها الوصول إلى برامج تشغيل الأجهزة غير أدوات تخصيص الذاكرة وربطها على أنّها برامج فقط.
  • [C-1-6] يجب تصنيف برامج الترميز التي لا تتوفّر في مشروع Android Open Source Project أو التي لا تستند إلى رمز المصدر في هذا المشروع على أنّها برامج تابعة لمورّد.
  • [C-1-7] يجب أن يتم تصنيف برامج الترميز التي تستخدم ميزة "تسريع الأجهزة" على أنّها مسرَّعة على الأجهزة.
  • [C-1-8] يجب ألّا تكون أسماء برامج الترميز مضلِّلة. على سبيل المثال، يجب أن تتيح برامج الترميز المُسمّاة "برامج فك الترميز" فك الترميز، ويجب أن تتيح تلك المُسمّاة "برامج الترميز" التشفير. يجب أن تكون برامج الترميز التي تحمل أسماء تحتوي على تنسيقات الوسائط متوافقة مع هذين التنسيقَين.

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

  • [C-2-1] يجب أن تنشر جميع برامج ترميز الفيديو بيانات معدل عرض اللقطات الذي يمكن تحقيقه للأحجام التالية إذا كانت برامج الترميز متوافقة معها:
الدقة العادية (جودة منخفضة) الدقة العادية (جودة عالية) دقة عالية - 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 بكسل (غير ذلك، AV1)
  • ‫‎1408 × 1152 بكسل (H263)
  • ‫‎1280 × 720 بكسل (غير ذلك، AV1)
‫‎1920 × 1080 بكسل (باستثناء MPEG4 وAV1) ‫‎3840 × 2160 بكسل (HEVC وVP9 وAV1)
  • [C-2-2] يجب أن تنشر برامج ترميز الفيديو التي يتم تصنيفها على أنّها مسرَّعة على الأجهزة معلومات نقاط الأداء. ويجب أن يُدرج كلّ منها جميع نقاط الأداء العادية المتوافقة (المدرَجة في واجهة برمجة التطبيقات PerformancePoint )، ما لم تكن مضمّنة في نقطة أداء عادية أخرى متوافقة.
  • بالإضافة إلى ذلك، يجب أن تنشر نقاط أداء إضافية إذا كانت توفّر ميزة تحسين الأداء المستمر في الفيديوهات غير تلك المُدرَجة في النقاط العادية.

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

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

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

بدء متطلبات جديدة

إذا كانت عمليات تنفيذ الأجهزة متوافقة مع أيّ برنامج ترميز فيديو وتوفّره لتطبيقات خارجية، وتم ضبط
MediaFormat.KEY_BITRATE_MODE على BITRATE_MODE_VBR لكي يعمل برنامج الترميز في وضع معدل نقل البيانات المتغيّر، فإنّه، ما دام ذلك لا يؤثّر في الحدّ الأدنى للجودة، يكون معدل نقل البيانات المشفَّر :

  • [C-5-1] يجب ألا يزيد معدل نقل البيانات في كل ملف على ملف سابق بنسبة تزيد عن% 15 خلال فواصل ملف الترميز الداخلي (I-frame).
  • [C-5-2] يجب ألا تتجاوز نسبته 100% من معدل نقل البيانات خلال فترة زمنية متحركة تبلغ ثانية واحدة.

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

  • [C-6-1] يجب [C-SR-2] يُنصح بشدة ألا يزيد عن ‎15% من معدل نقل البيانات المستهدَف على مدار فترة زمنية متحركة تبلغ ثانية واحدة.

إنهاء المتطلبات الجديدة

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

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

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

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

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

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

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

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

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

  • [C-SR-1] يُنصح بشدة بتوفير مكوّن إضافي لواجهة برمجة التطبيقات لتحويل الترميز بسلاسة من تنسيق HDR إلى تنسيق SDR.

5.2.1. ‫H.263

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

  • [C-1-1] يجب أن يكون الجهاز متوافقًا مع درجة دقة QCIF (176 x ‏144) باستخدام المستوى 45 من الملف الشخصي الأساسي. درجة دقة SQCIF اختيارية.
  • يجب أن تتيح ضبط معدلات نقل البيانات ديناميكيًا لبرنامج الترميز المتوافق.

5.2.2. H.264

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

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

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

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

5.2.3. VP8

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

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

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

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

5.2.4. VP9

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

  • [C-1-2] يجب أن يكون متوافقًا مع الملف الشخصي 0، المستوى 3.
  • [C-1-1] يجب أن تتيح كتابة ملفات Matroska WebM.
  • [C-1-3] يجب إنشاء بيانات CodecPrivate.
  • يجب أن تتيح الملفات الشخصية لفك ترميز المحتوى بدقة عالية كما هو موضّح في الجدول التالي.
  • [C-SR-1] يُنصح بشدة بتوفير ملفات تعريف فك ترميز الفيديوهات بدقة عالية كما هو موضح في الجدول التالي في حال توفّر برنامج ترميز للأجهزة.
دقة عادية دقة عالية - 720p دقة عالية - 1080p دقة فائقة
دقة الفيديو ‫720 × 480 بكسل ‫1280 × 720 بكسل ‫‎1920 × 1080 بكسل ‎3840 × 2160 بكسل
عدد اللقطات في الثانية في الفيديو 30 إطارًا في الثانية 30 إطارًا في الثانية 30 إطارًا في الثانية 30 إطارًا في الثانية
معدّل نقل بيانات الفيديو 1.6 ميغابت في الثانية ‫4 ميغابت في الثانية 5 ميغابت في الثانية 20 ميغابت في الثانية

إذا كانت عمليات تنفيذ الأجهزة تدّعي أنّها متوافقة مع الملف الشخصي 2 أو الملف الشخصي 3 من خلال Media APIs:

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

5.2.5. H.265

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

  • [C-1-1] يجب أن يكون متوافقًا مع المستوى 3 من الملف الشخصي الرئيسي حتى درجة دقة 512 x ‏512.
  • يجب أن تكون متوافقة مع ملفات ترميز الفيديوهات العالية الدقة كما هو موضّح في الجدول التالي.
  • [C-SR-1] يُنصح بشدة بتوفّر ملف التعريف بدقة عادية 720 x ‏480 و ملفّات ترميز بدقة عالية كما هو موضّح في الجدول التالي في حال توفّر برنامج ترميز للأجهزة.
دقة عادية دقة عالية - 720p دقة عالية - 1080p دقة فائقة
دقة الفيديو ‫720 × 480 بكسل ‫1280 × 720 بكسل ‫‎1920 × 1080 بكسل ‎3840 × 2160 بكسل
عدد اللقطات في الثانية في الفيديو 30 إطارًا في الثانية 30 إطارًا في الثانية 30 إطارًا في الثانية 30 إطارًا في الثانية
معدّل نقل بيانات الفيديو 1.6 ميغابت في الثانية ‫4 ميغابت في الثانية 5 ميغابت في الثانية 20 ميغابت في الثانية

بدء متطلبات جديدة

5.2.6. AV1

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

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

  • [C-1-3] يجب قبول البيانات الوصفية ذات تنسيق HDR وإخراجها إلى بث البتات

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

  • [C-2-1] يجب أن يكون متوافقًا مع الملف الشخصي لتشفير HD1080p وما يصل إليه من ملف شخصي من جدول المعلومات أدناه:
دقة عادية دقة عالية - 720p دقة عالية - 1080p دقة فائقة
دقة الفيديو ‫720 × 480 بكسل ‫1280 × 720 بكسل ‫‎1920 × 1080 بكسل ‎3840 × 2160 بكسل
عدد اللقطات في الثانية في الفيديو 30 إطارًا في الثانية 30 إطارًا في الثانية 30 إطارًا في الثانية 30 إطارًا في الثانية
معدّل نقل بيانات الفيديو 5 ميغابت في الثانية ‫8 ميغابت في الثانية 16 ميغابت في الثانية ‫50 ميغابت في الثانية

إنهاء المتطلبات الجديدة

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 من الملف الشخصي الأساسي (دقة CIF وQCIF وSQCIF بمعدّل 30 لقطة في الثانية 384 كيلوبت في الثانية) والمستوى 45 (دقة QCIF وSQCIF بمعدّل 30 لقطة في الثانية 128 كيلوبت في الثانية).

5.3.3. MPEG-4

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

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

5.3.4. H.264

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

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

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

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

5.3.5. ‫H.265 (HEVC)

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

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

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

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

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

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

5.3.6. VP8

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

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

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

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

5.3.7. VP9

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

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

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

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

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

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

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

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

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

  • [C-4-1] يجب أن تقبل عمليات تنفيذ الأجهزة البيانات الوصفية المطلوبة لميزة HDR (KEY_HDR_STATIC_INFO لجميع الملفات الشخصية لميزة HDR، بالإضافة إلى 'KEY_HDR10_PLUS_INFO' لملفّات HDR10Plus الشخصية) من التطبيق. ويجب أن تتيح أيضًا استخراج البيانات الوصفية المطلوبة لتقنية HDR وإخراجها من بث البتات و/أو الحاوية.
  • [C-4-2] يجب أن تعرض عمليات تنفيذ الأجهزة محتوى HDR بشكل صحيح على شاشة الجهاز أو على منفذ إخراج فيديو عادي (مثل منفذ 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 بت.

بدء متطلبات جديدة

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

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

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

  • [C-2-1] يجب أن يكون الجهاز قادرًا على فك ترميز ملفات الفيديو بدقة عالية 720p على الأقل من جدول الإعدادات أدناه عندما يكون الارتفاع الذي تم قياسه باستخدام طريقة Display.getSupportedModes() يساوي 720p أو يزيد عنه.
  • [C-2-2] يجب أن يكون الجهاز قادرًا على فك ترميز ملفات الفيديو بدقة عالية 1080p على الأقل من الجدول أدناه عندما يكون الارتفاع الذي تُبلغ عنه طريقة Display.getSupportedModes() يساوي 1080p أو أكبر.
دقة عادية دقة عالية - 720p دقة عالية - 1080p دقة فائقة
دقة الفيديو ‫720 × 480 بكسل ‫1280 × 720 بكسل ‫‎1920 × 1080 بكسل ‎3840 × 2160 بكسل
عدد اللقطات في الثانية في الفيديو 30 إطارًا في الثانية 30 إطارًا في الثانية 30 إطارًا في الثانية 30 إطارًا في الثانية
معدّل نقل بيانات الفيديو 5 ميغابت في الثانية ‫8 ميغابت في الثانية 16 ميغابت في الثانية ‫50 ميغابت في الثانية

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

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

إنهاء المتطلبات الجديدة

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

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

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

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

  • [C-1-1] يجب السماح بتسجيل محتوى صوتي خام ل أي بث INPUT من النوع AudioRecord أو AAudio تم فتحه بنجاح. يجب أن تكون السمات التالية متاحة على الأقل:

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

    • التنسيق: Linear PCM و16 بت و24 بت
    • معدّلات أخذ العينات: 8000 و11025 و16000 و22050 و24000 و32000 و44100 48000 هرتز
    • القنوات: عدد القنوات يساوي عدد الميكروفونات في الجهاز
  • [C-1-2] يجب تسجيل المحتوى بمعدّلات أعلى من معدّلات أخذ العينات بدون زيادة معدّل أخذ العينات.

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

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

    • التنسيق: Linear PCM، بسعة 16 بت
    • معدّلات أخذ العينات: 22050 و48000 هرتز
    • القنوات: صوت استيريو
  • [C-1-4] يجب الالتزام لواجهة برمجة التطبيقات MicrophoneInfo وملء معلومات الميكروفونات المتاحة على الجهاز التي يمكن للتطبيقات التابعة لجهات خارجية الوصول إليها من خلال واجهة برمجة التطبيقات AudioManager.getMicrophones() لتسجيل الصوت باستخدام MediaRecorder.AudioSources DEFAULT أو MIC أو CAMCORDER أو VOICE_RECOGNITION VOICE_COMMUNICATION أو UNPROCESSED أو VOICE_PERFORMANCE. إذا كانت عمليات تنفيذ الأجهزة تسمح بتسجيل محتوى صوتي بدائي بجودة راديو AM وأقراص DVD، يجب أن تستوفي المتطلبات التالية:

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

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

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

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

  • [C-1-1] يجب تسجيل android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION مصدر الصوت عند أحد معدّلات أخذ العينات، 44100 و48000.
  • [C-1-2] يجب إيقاف أي معالجة صوتية للحد من الضوضاء تلقائيًا عند تسجيل بث صوتي من مصدر AudioSource.VOICE_RECOGNITION الصوت.
  • [C-1-3] يجب إيقاف أيّ ميزة تلقائية للتحكّم في مستوى الصوت تلقائيًا عند تسجيل بثّ صوتي من مصدر الصوت AudioSource.VOICE_RECOGNITION.

  • يجب أن يُظهر خصائص تقريبية مسطّحة للسعة مقابل التردد في نطاق التردد المتوسط: على وجه التحديد ±3 ديسيبل من 100 هرتز إلى 4000 هرتز لكل وكل ميكروفون مستخدَم لتسجيل مصدر الصوت الخاص بميزة التعرّف على الصوت.

  • [C-SR-1] يُنصح بشدة بعرض مستويات السعة في نطاق التردد المنخفض: على وجه التحديد من ±20 ديسيبل من 30 هرتز إلى 100 هرتز مقارنةً بنطاق التردد المتوسط لكل ميكروفون مستخدَم لتسجيل مصدر ملف صوتي لخدمة التعرّف على الكلام.

  • [C-SR-2] يُنصح بشدة بعرض مستويات السعة في نطاق التردد العالي: على وجه التحديد من ±30 ديسيبل من 4000 هرتز إلى 22 كيلوهرتز مقارنةً بنطاق التردد المتوسط لكل ميكروفون مستخدَم لتسجيل مصدر ملف صوتي لخدمة التعرّف على الكلام.

  • يجب ضبط حساسية إدخال الصوت بحيث ينتج مصدر النغمات الجيبية بمقدار 1000 هرتز عند مستوى ضغط صوتي يبلغ 90 ديسيبل (SPL) (يتم قياسه على مسافة 30 سم من بجانب الميكروفون) استجابة مثالية بمقدار 2500 ذروة متوسطة مربّعة (RMS) ضمن نطاق يتراوح بين 1770 و3530 لعيّنات 16 بت (أو -22.35 ديسيبل ±3 ديسيبل على النطاق الكامل لعيّنات النقطة العائمة/الدقة المزدوجة) لكل ميكروفون مستخدَم لتسجيل مصدر ملف صوتي التعرّف على الكلام.

  • يجب تسجيل بث الصوت لميزة التعرّف على الصوت بحيث تتتبّع مستويات كثافة PCM الصوتية بشكل خطي تغييرات مستوى الضغط الصوتي (SPL) للإدخال على نطاق 30 ديسيبل على الأقل من -18 ديسيبل إلى +12 ديسيبل مقارنةً بمستوى الضغط الصوتي البالغ 90 ديسيبل عند الميكروفون.

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

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

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

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

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

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

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

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

5.4.4. ميزة "إلغاء الصدى الصوتي"

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

  • يجب استخدام تقنية إلغاء الصدى الصوتي (AEC) التي تم ضبطها للتواصل الصوتي وتطبيقها على مسار الالتقاط عند الالتقاط باستخدام AudioSource.VOICE_COMMUNICATION.

إذا كانت عمليات تنفيذ الأجهزة توفّر ميزة "إلغاء الصدى الصوتي" التي يتم إدراجها في مسار الصوت الذي يتم تسجيله عند اختيار AudioSource.VOICE_COMMUNICATION ، يتم تنفيذ ما يلي:

  • [C-SR-1] يُنصح بشدة بتحديد ذلك من خلال AcousticEchoCanceler طريقة واجهة برمجة التطبيقات AcousticEchoCanceler.isAvailable()
  • [C-SR-2] يُنصح بشدة بالسماح بالتحكم في تأثير الصوت هذا باستخدام واجهة برمجة التطبيقات AcousticEchoCanceler.
  • [C-SR-3] يُنصح بشدة بتحديد كل عملية تنفيذ لتكنولوجيا AEC بشكل فريد من خلال الحقل AudioEffect.Descriptor.uuid.

5.4.5. التسجيل المتزامن

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

  • [C-1-1] يجب السماح بالوصول المتزامن إلى الميكروفون من خلال خدمة تسهيل الاستخدام التي تسجِّل باستخدام AudioSource.VOICE_RECOGNITION وتطبيق واحد على الأقل يسجِّل باستخدام أي AudioSource.
  • [C-1-2] يجب السماح بالوصول المتزامن إلى الميكروفون من خلال تطبيق pre-installed يحمل دور "مساعد 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.5. تشغيل الصوت

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

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

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

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

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

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

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

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

  • [C-1-1] يجب أن يتيح التطبيق تنفيذ EFFECT_TYPE_EQUALIZER و EFFECT_TYPE_LOUDNESS_ENHANCER القابلَين للتحكّم من خلال Equalizer وLoudnessEnhancer، وهما فئتا فرعيتان من فئة AudioEffect.
  • [C-1-2] يجب أن تتيح تنفيذ واجهة برمجة التطبيقات لعرض البيانات، والتي يمكن التحكّم فيها من خلال فئة Visualizer.
  • [C-1-3] يجب أن تتيح تنفيذ EFFECT_TYPE_DYNAMICS_PROCESSING التي يمكن التحكّم فيها من خلال فئة فرعية من AudioEffect‏ DynamicsProcessing.

بدء متطلبات جديدة

  • [C-1-4] يجب أن تتيح التأثيرات الصوتية باستخدام إدخال وإخراج باستخدام النقطة العائمة.
  • [C-1-5] يجب التأكّد من أنّ التأثيرات الصوتية تتيح استخدام قنوات متعددة حتى عدد قنوات الخلاط المعروف أيضًا باسم FCC_LIMIT.

إنهاء المتطلبات الجديدة

  • يجب أن تتوافق مع عمليات تنفيذ EFFECT_TYPE_BASS_BOOST وEFFECT_TYPE_ENV_REVERB EFFECT_TYPE_PRESET_REVERB وEFFECT_TYPE_VIRTUALIZER التي يمكن التحكّم فيها من خلال الفئات الفرعية AudioEffect BassBoost EnvironmentalReverb وPresetReverb وVirtualizer.
  • [C-SR-1] يُنصح بشدة بتوفّر تأثيرات بتنسيق النقطة العائمة و قنوات المتعددة.

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

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

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

5.5.4. إزالة المحتوى الصوتي

إذا كانت عمليات تنفيذ الأجهزة تتيح تشغيل الصوت المُنزَّل، فإنّها:

  • [C-SR-1] يُنصح بشدة بقطع المحتوى الصوتي الذي يتم تشغيله بدون انقطاع بين مقطعَين بالتنسيق نفسه عند تحديد ذلك من خلال واجهة برمجة التطبيقات AudioTrack gapless API وحاوية الوسائط في MediaPlayer.

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

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

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

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

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

  • واجهة برمجة التطبيقات لصفيف ذاكرة التخزين المؤقت لـ PCM في OpenSL ES مجموعة واجهات برمجة تطبيقات OpenSL ES ذات الصلة بتنسيق PCM ضمن Android NDK

  • واجهة برمجة التطبيقات لنظام AAudio الصوتي الأصلي مجموعة واجهتَي برمجة تطبيقات AAudio ضمن Android NDK

  • الطابع الزمني: زوج يتألف من موضع إطار نسبي ضمن البث والوقت المقدَّر الذي يدخل فيه هذا الإطار أو يغادر فيه مسار معالجة الصوت على نقطة النهاية المرتبطة راجِع أيضًا AudioTimestamp.

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

  • متوسّط الانحراف المطلق متوسّط القيمة المطلقة للانحرافات عن المتوسط لمجموعة من القيم

  • وقت استجابة ميزة "النقر للتحدث" الوقت المستغرَق بين النقر على الشاشة وسماع نغمة تم إنشاؤها نتيجةً لذلك النقر على مكبّر الصوت

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

  • [C-1-1] يجب أن يكون الطابع الزمني الناتج الذي يعرضه كل من AudioTrack.getTimestamp وAAudioStream_getTimestamp دقيقًا بمعدل ± 2 ملي ثانية.
  • [C-1-2] وقت استجابة الإخراج على البارد يبلغ 500 مللي ثانية أو أقل

  • [C-1-3] يجب ألا يستغرق فتح بث إخراج باستخدام AAudioStreamBuilder_openStream() أقل من 1000 ملي ثانية.

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

  • [C-SR-1] يجب أن يكون وقت استجابة الإخراج بدون محتوى 100 ملي ثانية أو أقل على مسار بيانات مكبّر الصوت.
  • [C-SR-2] يجب أن يكون وقت استجابة ميزة "النقر للتشغيل" 80 ملي ثانية أو أقل.

  • [C-SR-4] يجب أن يكون الطابع الزمني الناتج الذي يعرضه كل من AudioTrack.getTimestamp وAAudioStream_getTimestamp دقيقًا بمعدل ± 1 ملي ثانية.

بدء متطلبات جديدة

  • [C-SR-4] يُنصح بشدة بأن تكون أوقات الاستجابة المحسوبة للذهاب والعودة استنادًا إلى علامات توقيت الإدخال والإخراج التي يعرضها AAudioStream_getTimestamp ضمن 30 ملي ثانية من وقت الاستجابة المقاس للذهاب والعودة لAAUDIO_PERFORMANCE_MODE_NONE وAAUDIO_PERFORMANCE_MODE_LOW_LATENCY للمكبّرات الصوت وسماعات الرأس السلكية واللاسلكية.

إنهاء المتطلبات الجديدة

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

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

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

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

  • [C-3-1] يجب الحد من الخطأ في الطوابع الزمنية للإدخال، كما تظهر في القيمة التي تعرِضها AudioRecord.getTimestamp أو AAudioStream_getTimestamp، إلى ± 2 ملي ثانية. ويشير "الخطأ" هنا إلى الانحراف عن القيمة الصحيحة.
  • [C-3-2] وقت استجابة الإدخال غير المتوفّر في الذاكرة 500 مللي ثانية أو أقل
  • [C-3-3] يجب ألا يستغرق فتح مصدر إدخال باستخدام AAudioStreamBuilder_openStream() أقل من 1000 ملي ثانية.

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

  • [C-SR-8] وقت استجابة الإدخال بدون تحضير يبلغ 100 ملي ثانية أو أقل عبر مسار بيانات الميكروفون

  • [C-SR-11] يجب الحد من الخطأ في الطوابع الزمنية للدخل، كما تظهر في AudioRecord.getTimestamp أو AAudioStream_getTimestamp، إلى ± 1 ملي ثانية.

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

  • [C-SR-12] يُنصح بشدة بتحقيق متوسّط وقت استجابة إرسال البيانات واستقبالها المستمر الذي يبلغ 50 ملي ثانية أو أقل على مدار 5 قياسات، مع متوسّط انحراف مطلق أدنى من 10 ملي ثانية، على مسار واحد متوافق على الأقل.

5.7. بروتوكولات الشبكة

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

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

  • [C-1-1] يجب أن يكون متوافقًا مع برنامج الترميز أو الحاوية هذاَين عبر بروتوكولَي HTTP وHTTPS.

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

  • [C-1-3] يجب أن يكون متوافقًا مع تنسيقات حمولة RTSP المقابلة كما هو موضّح في جدول RTSP أدناه. للاطّلاع على الاستثناءات، يُرجى الاطّلاع على حواشي الجدول في القسم 5.1.

تنسيقات مقاطع الوسائط

تنسيقات الشرائح المراجع توفُّر برامج الترميز المطلوبة
MPEG-2 Transport Stream ISO 13818 برامج ترميز الفيديو:
  • ‫H264 AVC
  • MPEG-4 SP
  • MPEG-2
راجِع الفقرة 5.1.8 لمعرفة تفاصيل عن H264 AVC وMPEG2-4 SP
وMPEG-2.

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

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

RTSP (RTP وSDP)

اسم الملف الشخصي المراجع توفُّر برامج الترميز المطلوبة
‫H264 AVC RFC 6184 راجِع القسم 5.1.8 للاطّلاع على تفاصيل عن H264 AVC.
MP4A-LATM RFC 6416 راجِع الفقرة 5.1.3 للاطّلاع على تفاصيل حول الترميز المتقدّم للصوت (AAC) وأنواعه.
‫H263-1998 RFC 3551
RFC 4629
RFC 2190
راجِع الفقرة 5.1.8 للاطّلاع على تفاصيل عن H263.
‫H263-2000 RFC 4629 راجِع الفقرة 5.1.8 للاطّلاع على تفاصيل عن H263.
AMR RFC 4867 راجِع القسم 5.1.3 للاطّلاع على تفاصيل حول AMR-NB.
AMR-WB RFC 4867 راجِع الفقرة 5.1.3 للاطّلاع على تفاصيل حول AMR-WB.
MP4V-ES RFC 6416 راجِع القسم 5.1.8 للاطّلاع على تفاصيل عن MPEG-4 SP.
mpeg4-generic RFC 3640 راجِع الفقرة 5.1.3 للاطّلاع على تفاصيل حول الترميز المتقدّم للصوت (AAC) وأنواعه.
MP2T RFC 2250 راجِع MPEG-2 Transport Stream ضمن "البث المباشر عبر HTTP" للاطّلاع على التفاصيل.

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

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

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

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

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

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

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

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

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

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

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

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

  • يجب أن يكون متوافقًا مع وضع MIDI عبر USB الملحق، الفقرة 7.7

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

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

  • [C-1-1] يجب الإبلاغ عن توفّر ميزة android.hardware.audio.low_latency.
  • [C-1-2] يجب أن يكون وقت استجابة إرسال البيانات واستقبالها للصوت مستمرًا، كما هو محدّد في القسم 5.6 وقت استجابة إرسال البيانات واستقبالها للصوت، بمقدار 25 ملي ثانية أو أقل على مسار واحد متوافق على الأقل.
  • [C-1-3] يجب أن يتضمّن الجهاز منافذ USB متوافقة مع وضع مضيف USB ووضع جهاز USB محيطي.
  • [C-1-4] يجب الإبلاغ عن توفّر الميزة android.software.midi.
  • [C-1-5] يجب استيفاء متطلبات وقت الاستجابة والصوت عبر USB باستخدام واجهة برمجة التطبيقات AAudio native audio وAAUDIO_PERFORMANCE_MODE_LOW_LATENCY.
  • [C-1-6] يجب أن يكون وقت استجابة الإخراج غير القابل للتقديم أو الإيقاف 200 ملي ثانية أو أقل.
  • [C-1-7] يجب أن يكون وقت استجابة الإدخال في وضع "التشغيل لأول مرة" 200 ملي ثانية أو أقل.
  • [C-1-8] يجب أن يكون متوسط وقت الاستجابة من النقر إلى ظهور الصوت 80 ملي ثانية أو أقل على مدار 5 قياسات على الأقل على مسار بيانات مكبّر الصوت إلى الميكروفون.

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

  • [C-SR-2] يُنصح بشدة باستيفاء متطلبات Pro Audio لوقت الاستجابة المستمر للصوت في كل اتجاه ووقت الاستجابة عند بدء تشغيل الإدخال ووقت الاستجابة عند بدء تشغيل الإخراج ومتطلبات الصوت عبر USB باستخدام واجهة برمجة التطبيقات AAudio native audio على مسار MMAP.

  • [C-SR-3] يُنصح بشدة بتوفير مستوى ثابت من أداء وحدة المعالجة المركزية أثناء تشغيل الصوت وتغيُّر حمولة وحدة المعالجة المركزية. يجب اختبار ذلك باستخدام تطبيق Android SynthMark. تستخدِم أداة SynthMark برنامجًا مركبًا يعمل على إطار عمل صوتي اصطناعي يقيس أداء النظام. اطّلِع على مستندات SynthMark للحصول على شرح لمقاييس الأداء. يجب تشغيل تطبيق SynthMark باستخدام خيار "الاختبار المبرمَج" وتحقيق النتائج التالية:

    • ‫voicemark.90 >= 32 صوتًا
    • ‫latencymark.fixed.little <= 15 msec
    • ‫latencymark.dynamic.little <= 50 msec
  • يجب تقليل عدم دقة الساعة الصوتية وانحرافها مقارنةً بالوقت العادي.

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

  • يجب تقليل وقت استجابة الصوت عبر محوِّلات الطاقة على الجهاز.

  • يجب أن تقلّل من وقت استجابة الصوت عبر الصوت الرقمي عبر USB.

  • يجب تسجيل قياسات وقت استجابة الصوت على جميع المسارات.

  • يجب تقليل الارتعاش في أوقات إدخال طلب معاودة الاتصال لإكمال ذاكرة التخزين المؤقت للصوت، لأنّ ذلك يؤثر في النسبة المئوية القابلة للاستخدام من معدل نقل البيانات الكامل لوحدة المعالجة المركزية من خلال طلب معاودة الاتصال.

  • يجب ألا يتضمّن أي مشاكل في الصوت أثناء الاستخدام العادي وفقًا لوقت الاستجابة المسجَّل.

  • يجب ألا يختلف وقت الاستجابة بين القنوات.

  • يجب تقليل متوسط وقت استجابة MIDI على جميع عمليات النقل.

  • يجب تقليل التباين في وقت استجابة MIDI أثناء التحميل (التشويش) على جميع عمليات النقل.

  • يجب أن يوفّر الطوابع الزمنية MIDI دقيقة على جميع عمليات النقل.

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

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

  • يجب أن تعالج عمليات تسجيل الإشعارات عند اكتمال تخزين مؤقت للصوت في جانبَي الإدخال والإخراج للنقاط الطرفية المقابلة في سلسلة المحادثات نفسها عندما يكون كلاهما نشطًا، ويجب إدخال إشعار الإدخال فورًا بعد العودة من إشعار الإخراج. أو إذا لم يكن من الممكن معالجة طلبات الاستدعاء في سلسلة المهام نفسها، أدخِل طلب استدعاء الإخراج بعد وقت قصير من إدخال طلب استدعاء الإدخال للسماح للتطبيق بتحديد توقيت متسق لكل من جانبَي الإدخال والإخراج.

  • يجب تقليل الفرق في الطور بين التخزين المؤقت للصوت في HAL لكل من جانبَي الإدخال والإخراج في نقاط النهاية المقابلة.

  • يجب أن تقلِّل من وقت استجابة اللمس.

  • يجب تقليل التباين في وقت استجابة اللمس أثناء التحميل (التشويش).

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

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

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

  • [C-3-1] يجب تنفيذ فئة الصوت في USB.
  • [C-3-2] يجب أن يكون متوسّط وقت استجابة الصوت المستمر لإرسال البيانات واستقبالها هو 25 ملي ثانية أو أقل، على مدار 5 قياسات مع متوسّط انحراف مطلق أدنى من 5 ملي ثانية عبر منفذ وضع مضيف USB باستخدام فئة الصوت في USB. (يمكن قياس ذلك باستخدام محوِّل USB-3.5 ملم وجهاز تحكم بديل لإعادة توجيه الصوت ، أو باستخدام واجهة صوت USB مع كابلات توصيل تربط المدخلات بالمخارج).
  • [C-SR-6] يُنصح بشدة بتوفير إمكانية نقل البيانات في كل من الاتجاهين في ما يصل إلى 8 قنوات في كل اتجاه، بمعدّل أخذ عينات يبلغ 96 كيلوهرتز وعمق 24 أو 32 بت، عند استخدامها مع أجهزة صوتية USB خارجية تتوافق أيضًا مع هذه المتطلبات.
  • [C-SR-7] يُنصح بشدة باستيفاء هذه المجموعة من المتطلبات باستخدام واجهة برمجة التطبيقات الأصلية للصوت AAudio على مسار MMAP.

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

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

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

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

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

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

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

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

5.12. فيديو بنطاق عالي الديناميكية

يتوافق نظام التشغيل Android 13 مع تقنيات HDR كما هو موضّح في مستند قادم.

تنسيق البكسل

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

  • [C-1-1] يجب أن يكون متوافقًا مع تنسيق P010 لقراءة وحدة المعالجة المركزية (ImageReader وMediaImage و ByteBuffer). في Android 13، تمّ تخفيف القيود المفروضة على P010 للسماح بخطوة عشوائية لمستوىَي Y وUV.

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

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

  • [C-2-1] يجب أن يكون متوافقًا مع تنسيق RGBA_1010102 لسطح الإخراج ويجب أن يكون قابلاً للقراءة من وحدة المعالجة المركزية (إخراج ByteBuffer).

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

  • [C-3-1] يجب أن يكون متوافقًا مع تنسيق P010 لسطح العرض المُدخل وملف الوسائط الذي يمكن لوحدة المعالجة المركزية كتابة بيانات فيه (ImageWriter وMediaImage وByteBuffer).

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

  • [C-4-1] يجب أن يكون متوافقًا مع تنسيق RGBA_1010102 لسطح العرض المُدخل وملف المعالجة المكتوبة (ImageWriter وByteBuffer). ملاحظة: لا يُشترط أن تُجري برامج الترميز عملية تحويل بين منحنيات نقل ملف الوسائط المختلفة.

متطلبات تسجيل الفيديوهات بنطاق عالي الديناميكية (HDR)

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

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

  • يجب تجميع البيانات الوصفية الديناميكية لتقنية HDR لإنشاء بيانات وصفية ثابتة ومناسبه لتقنية HDR في أحداث البث المشفَّرة، ويجب عرضها في نهاية كل جلسة ترميز.

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

  • [C-6-1] يجب أن تتيح الكاميرا أيضًا التقاط الصور بنطاق ديناميكي عالي من خلال واجهات برمجة التطبيقات Camera2 API.

  • [C-6-2] يجب أن يتضمّن الجهاز برنامج ترميز فيديو واحدًا على الأقل مُسرَّعًا بالأجهزة لكل تكنولوجيا HDR متوافقة.

  • [C-6-3] يجب أن يكون الجهاز متوافقًا مع وضع التصوير بتنسيق HLG (على الأقل).

  • [C-6-4] يجب أن تتيح كتابة البيانات الوصفية ذات تنسيق HDR (إذا كان ذلك منطبقًا على تكنولوجيا HDR) في ملف الفيديو الذي تم تسجيله. بالنسبة إلى AV1 وHEVC وDolbyVision، يعني ذلك تضمين البيانات الوصفية في بث البتات المشفَّرة.

  • [C-6-5] يجب أن يكون متوافقًا مع التنسيقَين P010 وCOLOR_FormatYUVP010.

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

متطلبات تعديل الفيديوهات بنطاق عالي الديناميكية (HDR)

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

  • يجب استخدام الحد الأدنى من وقت الاستجابة لإنشاء البيانات الوصفية لنطاق HDR عندما لا تكون متوفّرة، ويجب التعامل بسلاسة مع الحالات التي تكون فيها البيانات الوصفية متوفّرة لبعض اللقطات وليس غيرها. يجب أن تكون هذه البيانات الوصفية دقيقة (على سبيل المثال، повинна أن تمثل ذروة الإضاءة الفعلية ورسم المخطّط البياني للإطار).

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

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

  • [C-7-2] يجب أن يكون برنامج الترميز متوافقًا مع FEATURE_HdrEditing لجميع الملفات الشخصية لتنسيق HDR التي يعلن عنها هذا البرنامج. بعبارة أخرى، يجب أن يكون متوافقًا مع إنشاء البيانات الوصفية لتنسيق HDR عند عدم توفّرها لجميع الملفات الشخصية المتوافقة لتنسيق HDR التي تستخدم البيانات الوصفية لتنسيق HDR.

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

    • ‫RGBA_1010102 (متوفّر حاليًا في منحنى النقل المستهدَف) لكلٍّ من سطح الادخال وByteBuffer، ويجب الإعلان عن توفّر التنسيق COLOR_Format32bitABGR2101010.

إذا كان تنفيذ الجهاز يتضمّن برامج ترميز متوافقة مع FEATURE_HdrEditing، عندئذٍ: يُطبّق الجهاز ما يلي:

  • [C-7-4] يجب الإعلان عن توافق الجهاز مع إضافة OpenGL EXT_YUV_target.

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-0-11] يجب أن يكون متوافقًا مع الأمر cmd testharness في shell. قد يتم استثناء عمليات ترقية عمليات تنفيذ الأجهزة من إصدار Android أقدم بدون توفُّر كتلة بيانات دائمة من C-0-11.
    • [C-0-3] يجب عدم تغيير تنسيق أو محتوى أحداث نظام الجهاز (batterystats وdiskstats وfingerprint وgraphicsstats وnetstats وnotification وprocstats) التي يتم تسجيلها من خلال الأمر dumpsys.
    • [C-0-10] يجب تسجيل الأحداث التالية بدون حذفها وإتاحة الوصول إليها من خلال الأمر cmd stats shell وStatsManager فئة System API.
      • ActivityForegroundStateChanged
      • AnomalyDetected
      • AppBreadcrumbReported
      • AppCrashOccurred
      • AppStartOccurred
      • BatteryLevelChanged
      • BatterySaverModeStateChanged
      • BleScanResultReceived
      • BleScanStateChanged
      • ChargingStateChanged
      • DeviceIdleModeStateChanged
      • ForegroundServiceStateChanged
      • GpsScanStateChanged
      • JobStateChanged
      • PluggedStateChanged
      • ScheduledJobStateChanged
      • ScreenStateChanged
      • SyncStateChanged
      • SystemElapsedRealtime
      • UidProcessStateChanged
      • WakelockStateChanged
      • WakeupAlarmOccurred
      • WifiLockStateChanged
      • WifiMulticastLockStateChanged
      • WifiScanStateChanged
    • [C-0-4] يجب أن يكون برنامج adb الخفي غير مفعّل تلقائيًا على الجهاز، ويجب أن تتوفّر آلية يمكن للمستخدم الوصول إليها لتفعيل أداة Android Debug Bridge.
    • [C-0-5] يجب أن يكون متوافقًا مع adb الآمن. يتيح نظام Android استخدام أداة adb الآمنة. تفعِّل أداة adb الآمنة أداة adb على المضيفين المعروفين الذين تمّت مصادقتهم.
    • [C-0-6] يجب توفير آلية تسمح بربط adb من جهاز مضيف. وعلى وجه التحديد:

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

    • [C-3-1] يجب تنفيذ adb عبر شبكة منطقة محلية (مثل إيثرنت أو Wi-Fi).
    • [C-3-2] يجب توفير برامج تشغيل لنظام التشغيل Windows 7 و8 و10، ما يسمح للمطوّرين بالاتصال بالجهاز باستخدام بروتوكول adb.

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

    • [C-4-1] يجب أن تتضمّن الطريقة AdbManager#isAdbWifiSupported() true.

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

    • [C-5-1] يجب أن تؤدي الطريقة AdbManager#isAdbWifiQrSupported() إلى عرض القيمة true.
  • Dalvik Debug Monitor Service ‏ (ddms)

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

    • [C-0-9] يجب أن تكون متوافقة مع أداة systrace كما هو موضّح في حزمة تطوير البرامج (SDK) لنظام التشغيل Android. يجب أن تكون أداة Systrace غير مفعّلة تلقائيًا ويجب أن تتوفّر آلية يمكن للمستخدم تفعيلها.
  • Perfetto

    • [C-SR-1] يُنصح بشدة بعرض /system/bin/perfetto ملف ثنائي لمستخدم shell يكون cmdline متوافقًا مع مستندات perfetto.
    • [C-SR-2] يُنصح بشدة بقبول ملف ثنائي لبرنامج perfetto كإدخال لملف برمجة protobuf متوافق مع المخطط المحدّد في مستندات perfetto.
    • [C-SR-3] يُنصح بشدة باستخدام ملف perfetto الثنائي لكتابة أثر protobuf يتوافق مع المخطّط المحدّد في مستندات perfetto.
    • [C-SR-4] يُنصح بشدة بتوفير، من خلال ملفّ perfetto الثنائي، على الأقل مصادر البيانات الموضّحة في مستندات perfetto.
  • Low Memory Killer

    • [C-0-12] يجب كتابة LMK_KILL_OCCURRED_FIELD_NUMBER Atom في ملف تسجيل statsd عند إنهاء أحد التطبيقات بواسطة Low Memory Killer.
  • وضع "مفعّل الاختبار" إذا كانت عمليات تنفيذ الأجهزة تتيح استخدام الأمر cmd testharness وcmd testharness enable في ملف شل، يمكنها تنفيذ ما يلي:

  • معلومات عن عمل وحدة معالجة الرسومات

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

    • [C-0-13] يجب تنفيذ الأمر dumpsys gpu --gpuwork في واجهة الصدفة لعرض بيانات عمل وحدة معالجة الرسومات المجمّعة التي يعرضها نقطة تتبُّع power/gpu_work_period في kernel، أو عدم عرض أي بيانات إذا كانت نقطة التتبُّع غير متوافقة. إصدار AOSP هو frameworks/native/services/gpuservice/gpuwork/.

إذا أبلغت عمليات تنفيذ الأجهزة عن توفّر 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] يجب أن ينفِّذ تطبيق الجهاز واجهة برمجة التطبيقات (IDE) هذه كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

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

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

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

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

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

بدء متطلبات جديدة

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

  • [C-0-1] يجب أن يتم عرض التطبيقات التابعة لجهات خارجية تلقائيًا على الشاشات المتوافقة مع Android فقط.

إنهاء المتطلبات الجديدة

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

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

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

7.1.1.1. حجم الشاشة وشكلها

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

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

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

    • يجب أن تكون الأجهزة التي تم ضبط Configuration.uiMode فيها على أي قيمة غير UI_MODE_TYPE_WATCH، والتي تُبلغ عن حجم small لسمة Configuration.screenLayout، أبعادها 426 dp x ‏320 dp على الأقل.
    • بالنسبة إلى الأجهزة التي تُبلغ عن حجم normal للشاشةConfiguration.screenLayout، يجب أن يكون حجم الشاشة فيها 480 نقطة لكل بوصة × 320 نقطة لكل بوصة على الأقل.
    • بالنسبة إلى الأجهزة التي تُبلغ عن حجم large للشاشةConfiguration.screenLayout، يجب أن يكون حجم الشاشة فيها 640 dp x ‏480 dp على الأقل.
    • يجب أن تكون الأجهزة التي تُبلغ عن حجم xlarge لشاشة Configuration.screenLayout، بدقة 960 نقطة لكل بوصة × 720 نقطة لكل بوصة على الأقل.
  • [C-0-2] يجب أن تتوافق التطبيقات بشكلٍ صحيح مع أحجام الشاشة المُعلَن عنها من خلال سمة <supports-screens> في ملف AndroidManifest.xml، كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

  • يمكن أن تتضمّن شاشات متوافقة مع Android وزوايا دائرية.

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

  • [C-1-1] يجب التأكّد من استيفاء أحد المتطلبات التالية على الأقل لكل شاشة من هذا النوع:

    • أن يكون نصف قطر الزوايا المستديرة أقل من أو يساوي 38 وحدة بكسل
    • عند تثبيت صندوق أبعاده 1518 dp × 1518 dp في كلّ زاوية من الزوايا في الشاشة المنطقية، يظهر بكسل واحد على الأقل من كلّ صندوق على الشاشة.
  • يجب أن تتضمّن إمكانات الاستخدام التي يحصل عليها المستخدم للتبديل إلى وضع العرض مع الزوايا المستطيلة.

بدء متطلبات جديدة

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

  • [C-4-1] يجب أن يكون حجم التنسيق، باستثناء أيّ أجزاء مُقتطعة من الشاشة، هو 596 dp × 384 dp أو أكبر.

إنهاء المتطلبات الجديدة

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

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

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

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

بدء متطلبات جديدة

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منطقة عرض واحدة أو أكثر متوافقة مع Android قابلة للطي، أو تتضمّن مفصلاً قابلاً للطي بين مناطق متعددة لوحة عرض متوافقة مع Android وجعل مناطق العرض هذه متاحة للتطبيقات، يجب استيفاء الشروط التالية:

إنهاء المتطلبات الجديدة

7.1.1.2. نسبة العرض إلى الارتفاع للشاشة

على الرغم من عدم فرض أي قيود على نسبة العرض إلى الارتفاع للشاشة الفعلية للشاشات المتوافقة مع Android، يجب أن تستوفي نسبة العرض إلى الارتفاع للشاشة المنطقية التي يتم عرض التطبيقات التابعة لجهات خارجية عليها، والتي يمكن اشتقاقها من قيم الارتفاع والعرض التي يتم الإبلاغ عنها من خلال واجهات برمجة تطبيقات view.Display وConfiguration ، المتطلبات التالية:

  • [C-0-1] في عمليات تنفيذ الأجهزة التي تم ضبط Configuration.uiMode فيها على UI_MODE_TYPE_NORMAL، يجب أن تكون قيمة نسبة العرض إلى الارتفاع أقل من أو تساوي 1.86 (‎16:9 تقريبًا)، ما لم يستوفِ التطبيق أحد الشروط التالية:

    • أعلن التطبيق أنّه يتوافق مع نسبة عرض إلى ارتفاع أكبر للشاشة من خلال قيمة البيانات الوصفية android.max_aspect.
    • يُعلِن التطبيق أنّه يمكن تغيير حجمه من خلال السمة android:resizeableActivity.
    • يستهدف التطبيق المستوى 24 من واجهة برمجة التطبيقات أو المستويات الأعلى ولا يعلن عن android:maxAspectRatio يؤدي إلى تقييد نسبة العرض إلى الارتفاع المسموح بها.
  • [C-0-3] في عمليات تنفيذ الأجهزة التي تم ضبط Configuration.uiMode فيها على UI_MODE_TYPE_WATCH، يجب ضبط قيمة نسبة العرض إلى الارتفاع على 1.0 (1:1).

7.1.1.3. كثافة الشاشة

يحدِّد إطار عمل واجهة مستخدم Android مجموعة من الكثافات المنطقية العادية لمساعدة مطوّري التطبيقات في استهداف موارد التطبيقات.

عمليات تنفيذ الأجهزة:

  • [C-0-1] يجب أن تُبلغ عمليات تنفيذ الأجهزة تلقائيًا عن واحدة فقط من كثافات شاشة إطار عمل Android المُدرَجة في DisplayMetrics من خلال واجهة برمجة التطبيقات DENSITY_DEVICE_STABLE ويجب أن تكون هذه القيمة ثابتة لكل شاشة خارجية. يجب ألا تتغيّر في أي وقت، ومع ذلك، يجوز للجهاز تسجيل كثافة عشوائية DisplayMetrics.density مختلفة وفقًا لتغييرات إعدادات الشاشة التي أجراها المستخدم (مثل حجم الشاشة) التي تم ضبطها بعد التشغيل الأولي.

  • يجب أن تحدِّد عمليات تنفيذ الأجهزة كثافة إطار عمل Android العادية التي تكون الأقرب رقميًا إلى الكثافة الفعلية للشاشة، ما لم تؤدي كثافة المنطق إلى خفض حجم الشاشة المسجَّل إلى ما دون الحد الأدنى المسموح به. إذا كانت كثافة إطار عمل Android العادية الأقرب رقميًا إلى الكثافة الفعلية تؤدي إلى حجم شاشة أصغر من أصغر حجم شاشة متوافق متوافق (320 نقطة لكل بوصة)، يجب أن تُبلغ عمليات تنفيذ الأجهزة عن كثافة إطار عمل Android العادية الأقل تاليًا.

بدء متطلبات جديدة

  • يجب أن تحدِّد كثافة إطار عمل Android العادية التي تكون العددية اقرب إلى الكثافة الفعلية للشاشة، أو قيمة يمكن ربطها بقياسات مجال الرؤية الزاوي المكافئ نفسه لجهاز محمول.

إنهاء المتطلبات الجديدة

إذا كانت عمليات تنفيذ الأجهزة توفّر إمكانية تغيير حجم شاشة الجهاز ، يجب أن تستوفي المتطلبات التالية:

  • [C-1-1] يجب عدم تغيير حجم الشاشة يجب عدم تغيير حجم الشاشة بمقدار أكبر من 1.5 مرة DENSITY_DEVICE_STABLE الكثافة الأصلية أو إنتاج الحد الأدنى الفعال لسمة الشاشة الأصغر من 320dp (أي ما يعادل مُحدِّد المورد sw320dp)، أيهما أقرب.
  • [C-1-2] يجب عدم تغيير حجم الشاشة يجب عدم تغيير حجم الشاشة بمقدار أقل من 0.85 مرة من DENSITY_DEVICE_STABLE الكثافة الأصلية.
  • لضمان سهولة الاستخدام وأحجام الخطوط المتسقة، ننصحك بتقديم الحجم التالي لخيارات العرض الأصلية (مع الالتزام بالحدود المذكورة أعلاه):
    • صغير: 0.85x
    • الإعداد التلقائي: 1x (مقياس الشاشة الأصلي)
    • كبير: 1.15x
    • أكبر: 1.3x
    • أكبر حجمًا 1.45x

7.1.2. مقاييس الشبكة الإعلانية

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشات متوافقة مع Android أو إخراج الفيديو إلى شاشات العرض المتوافقة مع Android، يجب استيفاء الشروط التالية:

  • [C-1-1] يجب الإبلاغ عن قيم صحيحة لجميع مقاييس شاشة التوافقية مع Android المحدّدة في واجهة برمجة التطبيقات android.util.DisplayMetrics.

إذا لم تتضمّن عمليات تنفيذ الأجهزة شاشة أو إخراج فيديو مضمّنًا، يجب مراعاة ما يلي:

  • [C-2-1] يجب عرض القيم الصحيحة للشاشة المتوافقة مع Android كما هو محدّد في واجهة برمجة التطبيقات android.util.DisplayMetrics للشاشة التلقائية المحاكية view.Display.

7.1.3. اتجاه الشاشة

عمليات التنفيذ على الأجهزة:

  • [C-0-1] يجب الإبلاغ عن أوضاع الشاشة المتاحة (android.hardware.screen.portrait و/أو android.hardware.screen.landscape) ويجب الإبلاغ عن اتجاه واحد على الأقل متاح. على سبيل المثال، يجب أن يُبلغ الجهاز الذي يتضمّن شاشة عمودية ثابتة، مثل التلفزيون أو الكمبيوتر المحمول، عن android.hardware.screen.landscape فقط.
  • [C-0-2] يجب عرض القيمة الصحيحة لاتجاه الجهاز الحالي، عند الاستعلام من خلال android.content.res.Configuration.orientation أو android.view.Display.getOrientation() أو واجهات برمجة تطبيقات أخرى.

إذا كانت عمليات تنفيذ الأجهزة تتيح وضعَي الشاشة، يجب أن:

  • [C-1-1] يجب أن تتيح التطبيقات اتجاهًا ديناميكيًا للشاشة سواءً كان عموديًا أو أفقيًا. وهذا يعني أنّه يجب أن يراعي الجهاز طلب التطبيق باتجاه شاشة محدّد.
  • [C-1-2] يجب عدم تغيير حجم الشاشة أو كثافتها المُبلَّغ عنها عند تغيير الاتجاه.
  • يمكن اختيار الاتجاه العمودي أو الأفقي كإعداد تلقائي.

7.1.4. ميزة "تسريع الرسومات" ثنائية وثلاثية الأبعاد

‎7.1.4.1 OpenGL ES

عمليات التنفيذ على الأجهزة:

  • [C-0-1] يجب تحديد إصدارات OpenGL ES المتوافقة (1.1 و2.0 و3.0 و3.1 و3.2) بشكل صحيح من خلال واجهات برمجة التطبيقات المُدارة (مثلاً من خلال GLES10.getString()) وواجهات برمجة التطبيقات الأصلية.
  • [C-0-2] يجب أن تتضمّن التوافق مع جميع واجهات برمجة التطبيقات المُدارة المقابلة و واجهات برمجة التطبيقات الأصلية لكل إصدارات OpenGL ES التي تم تحديدها للتوافق معها.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة أو إخراج فيديو، يجب أن تستوفي الشروط التالية:

يتم تقسيم اختبارات OpenGL ES dEQP إلى عدد من قوائم الاختبارات، ولكل منها تاريخ أو رقم إصدار مرتبط. يمكنك العثور على هذه المراجع في شجرة مصدر Android على الرابط external/deqp/android/cts/main/glesXX-main-YYYY-MM-DD.txt. يشير الجهاز الذي يتوافق مع OpenGL ES على مستوى تم الإبلاغ عنه ذاتيًا إلى أنّه يمكنه اجتياز اختبارات dEQP في جميع قوائم الاختبارات من هذا المستوى والإصدارات الأقدم.

إذا كانت عمليات تنفيذ الأجهزة متوافقة مع أي من إصدارات 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-2-3] يجب الإبلاغ عن الحد الأقصى لإصدار اختبارات dEQP في OpenGL ES المتوافقة من خلال علامة ميزة android.software.opengles.deqp.level.
  • [C-2-4] يجب أن يكون متوافقًا مع الإصدار 132383489 على الأقل (اعتبارًا من 1 آذار (مارس) 2020) كما هو مذكور في علامة ميزة android.software.opengles.deqp.level.
  • [C-2-5] يجب اجتياز جميع اختبارات dEQP في OpenGL ES في قوائم الاختبار بين الإصدار 132383489 والإصدار المحدّد في علامة ميزة android.software.opengles.deqp.level، لكل إصدار متوافق من OpenGL ES.
  • [C-SR-2] يُنصح بشدة بتوفّر الإضافتَين EGL_KHR_partial_update و OES_EGL_image_external.
  • يجب الإبلاغ بدقة من خلال طريقة getString() عن أي تنسيق ضغط رسومات يتوافق معه التطبيق، والذي يكون عادةً خاصًا بالمورّد.

  • يجب أن تكون متوافقة مع الإضافتَين EGL_IMG_context_priority و EGL_EXT_protected_content.

إذا كانت عمليات تنفيذ الأجهزة تعلن عن توافقها مع OpenGL ES 3.0 أو 3.1 أو 3.2، يجب أن تستوفي المتطلبات التالية:

  • [C-3-1] يجب تصدير رموز الدوالّ المقابلة لهذه الإصدارات بالإضافة إلى رموز دوالّ OpenGL ES 2.0 في مكتبة libGLESv2.so.
  • [C-SR-3] يُنصح بشدة بتوفُّر إضافة OES_EGL_image_external_essl3.

إذا كانت عمليات تنفيذ الأجهزة متوافقة مع OpenGL ES 3.2، يجب أن تستوفي الشروط التالية:

  • [C-4-1] يجب أن يكون متوافقًا مع حزمة OpenGL ES Android Extension Pack بالكامل.

إذا كانت عمليات تنفيذ الأجهزة متوافقة مع مجموعة إضافات Android لـ OpenGL ES بالكامل، يجب أن تستوفي الشروط التالية:

  • [C-5-1] يجب تحديد مدى توفّر الميزة من خلال android.hardware.opengles.aep علامة الميزة.

إذا كانت عمليات تنفيذ الأجهزة تتيح استخدام الإضافة EGL_KHR_mutable_render_buffer ، فإنّها:

  • [C-6-1] يجب أن تتيح أيضًا إضافة EGL_ANDROID_front_buffer_auto_refresh.
7.1.4.2 Vulkan

يتيح نظام التشغيل Android استخدام Vulkan ، وهي واجهة برمجة تطبيقات متعددة المنصات ذات تكلفة منخفضة للرسومات الثلاثية الأبعاد العالية الأداء.

إذا كانت عمليات تنفيذ الأجهزة متوافقة مع OpenGL ES 3.1، يجب أن تستوفي الشروط التالية:

  • [C-SR-1] يُنصح بشدة بتضمين الدعم لـ Vulkan 1.3.
  • [C-4-1] يجب ألّا يكون متوافقًا مع إصدار متغير من Vulkan (أي يجب أن يكون الجزء المتغير من إصدار Vulkan الأساسي صفرًا).

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة أو إخراج فيديو، يجب أن تستوفي الشروط التالية:

  • [C-SR-2] يُنصح بشدة بتضمين ميزة استخدام Vulkan 1.3.

يتم تقسيم اختبارات Vulkan dEQP إلى عدد من قوائم الاختبارات، ولكل منها تاريخ أو إصدار مرتبط. يمكنك العثور على هذه المراجع في شجرة مصدر Android على الرابط external/deqp/android/cts/main/vk-main-YYYY-MM-DD.txt. يشير الجهاز الذي يتوافق مع Vulkan على مستوى تم الإبلاغ عنه ذاتيًا إلى أنّه يمكنه اجتياز اختبارات dEQP في جميع قوائم الاختبار من هذا المستوى والإصدارات الأقدم.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن توافقًا مع 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 Vulkan 1.1 بالكامل لكل VkPhysicalDevice مُدرَج.
  • [C-1-4] يجب إدراج الطبقات، المضمّنة في المكتبات المجمّعة من رموز برمجية أصلية والتي تحمل الاسم libVkLayer*.so في دليل المكتبة المجمّعة من رموز برمجية أصلية لحزمة التطبيق، من خلال واجهات برمجة التطبيقات المجمّعة من رموز برمجية أصلية لـ Vulkan vkEnumerateInstanceLayerProperties() وvkEnumerateDeviceLayerProperties().
  • [C-1-5] يجب عدم إدراج الطبقات التي تقدّمها المكتبات خارج حزمة التطبيق، أو توفير طرق أخرى لتتبُّع واجهة برمجة التطبيقات Vulkan أو اعتراضها، ما لم يكن التطبيق يحتوي على سمة android:debuggable مُعدّة على القيمة true أو البيانات الوصفية com.android.graphics.injectLayers.enable مُعدّة على القيمة true .
  • [C-1-6] يجب الإبلاغ عن جميع سلاسل الإضافات التي تتوافق معها عبر واجهات برمجة تطبيقات Vulkan الأصلية، وفي المقابل يجب ألا تبلغ عن سلاسل الإضافات التي لا تتوافق معها بشكل صحيح.
  • [C-1-7] يجب أن يكون متوافقًا مع إضافات VK_KHR_surface وVK_KHR_android_surface وVK_KHR_swapchain وVK_KHR_incremental_present.
  • [C-1-8] يجب الإبلاغ عن الحد الأقصى لإصدار اختبارات Vulkan dEQP المتوافقة من خلال علامة ميزة android.software.vulkan.deqp.level.
  • [C-1-9] يجب أن يكون متوافقًا مع الإصدار 132317953 على الأقل (اعتبارًا من 1 آذار (مارس) 2019) كما هو مذكور في علامة ميزة android.software.vulkan.deqp.level.
  • [C-1-10] يجب اجتياز جميع اختبارات Vulkan dEQP في قوائم الاختبار بين الإصدار 132317953 والإصدار المحدّد في علامة ميزة android.software.vulkan.deqp.level.
  • [C-1-11] يجب عدم إدراج توافق مع الإضافات VK_KHR_video_queue أو VK_KHR_video_decode_queue أو VK_KHR_video_encode_queue.
  • [C-SR-3] يُنصح بشدة بتوفّر الإضافتَين VK_KHR_driver_properties وVK_GOOGLE_display_timing.

  • يجب أن يكون متوافقًا مع VkPhysicalDeviceProtectedMemoryFeatures و VK_EXT_global_priority.

  • [C-1-12] يجب عدم إدراج إمكانية استخدام إضافة VK_KHR_performance_query.

بدء متطلبات جديدة

  • [C-SR-5] يُنصح بشدة بتوفّر VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory وVK_EXT_global_priority.

  • [C-SR-6] يُنصح بشدة باستخدام SkiaVk مع HWUI.

إنهاء المتطلبات الجديدة

إذا لم تتضمّن عمليات تنفيذ الأجهزة ميزة التوافق مع 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 إشارة الانتظار الخارجية وhandle وإضافة VK_ANDROID_external_memory_android_hardware_buffer.

بدء متطلبات جديدة

  • [C-SR-7] يُنصح بشدة بتوفير إضافة VK_KHR_external_fence_fd للتطبيقات التابعة لجهات خارجية وتفعيل التطبيق لتصدير الحمولة إلى وصفاء الحدود واستيرادها من وصفاءملف POSIX كما هو موضّح هنا.

إنهاء المتطلبات الجديدة

7.1.4.3 RenderScript
  • [C-0-1] يجب أن تكون عمليات تنفيذ الأجهزة متوافقة مع Android RenderScript، على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
7.1.4.4 ميزة "تسريع الرسومات ثنائية الأبعاد"

يتضمّن نظام التشغيل Android آلية تتيح للتطبيقات الإفصاح عن رغبتها في تفعيل ميزة "التسريع بالأجهزة" للرسومات ثنائية الأبعاد على مستوى التطبيق أو النشاط أو النافذة أو العرض من خلال استخدام علامة البيان android:hardwareAccelerated أو طلبات مباشرة لواجهة برمجة التطبيقات.

عمليات التنفيذ على الأجهزة:

  • [C-0-1] يجب تفعيل ميزة "تسريع الأجهزة" تلقائيًا، ويجب إيقافها إذا طلب المطوِّر ذلك من خلال ضبط قيمة android:hardwareAccelerated="false” أو إيقافها مباشرةً من خلال واجهات برمجة التطبيقات Android View APIs.
  • [C-0-2] يجب أن يعرض التطبيق سلوكًا متوافقًا مع مستندات IDE لنظام التشغيل Android بشأن تسريع الأجهزة.

يتضمّن Android عنصر TextureView الذي يتيح للمطوّرين دمج ملمس OpenGL ES المُسرَّع بالأجهزة مباشرةً كأهداف للعرض في التسلسل الهرمي لواجهة المستخدم.

عمليات التنفيذ على الأجهزة:

  • [C-0-3] يجب أن يكون متوافقًا مع واجهة برمجة التطبيقات TextureView API، ويجب أن يعرض سلوكًا متناسقًا مع التنفيذ في 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-1] يُنصح بشدة بتوفّر GL_EXT_sRGB.

في المقابل، إذا كانت عمليات تنفيذ الأجهزة لا تتيح استخدام شاشات النطاق اللوني الواسع، يتم تنفيذ ما يلي:

  • [C-2-1] يجب أن تغطي نسبة% 100 أو أكثر من sRGB في مساحة CIE 1931 xyY، على الرغم من أنّه لم يتم تحديد نطاق ألوان الشاشة.

7.1.5. وضع التوافق مع التطبيقات القديمة

يحدِّد Android "وضع التوافق" الذي يعمل فيه إطار العمل في وضع مكافئ لحجم الشاشة "العادي" (بعرض 320dp) لمنفعة التطبيقات القديمة التي لم يتم تطويرها لإصدارات Android القديمة التي تسبق الاستقلالية عن حجم الشاشة.

7.1.6. تكنولوجيا الشاشة

تتضمّن منصة Android واجهات برمجة تطبيقات تتيح للتطبيقات عرض رسومات غنية على شاشة متوافقة مع Android. يجب أن تكون الأجهزة متوافقة مع كل واجهات برمجة التطبيقات هذه على النحو المحدّد في حزمة تطوير البرامج (SDK) لنظام التشغيل Android، ما لم يُسمح بذلك تحديدًا في هذا المستند.

جميع شاشات التنفيذ المتوافقة مع Android للجهاز:

  • [C-0-1] يجب أن يكون الجهاز قادرًا على عرض رسومات ملونة بدقة 16 بت.
  • يجب أن تكون متوافقة مع الشاشات التي يمكنها عرض الرسومات الملوّنة بدقة 24 بت.
  • [C-0-2] يجب أن يكون الجهاز قادرًا على عرض الرسوم المتحركة.
  • [C-0-3] يجب أن تكون نسبة العرض إلى الارتفاع (PAR) للبكسل بين 0.9 و1.15. وهذا يعني أنّ نسبة عرض البكسل إلى ارتفاعه يجب أن تكون قريبة من نسبة العرض إلى الارتفاع المربّع (1.0) مع هامش خطأ يتراوح بين ‎10% و‎15%.

7.1.7. الشاشات الثانوية

يتيح نظام التشغيل Android استخدام شاشات ثانوية متوافقة معه لتفعيل ميزات مشاركة الوسائط وواجهات برمجة التطبيقات للمطوّرين للوصول إلى الشاشات الخارجية.

إذا كانت عمليات تنفيذ الأجهزة تتيح استخدام شاشة خارجية عبر اتصال سلكي أو لاسلكي أو اتصال بشاشة إضافية مدمجة، يجب أن تستوفي الشروط التالية:

  • [C-1-1] يجب تنفيذ خدمة النظام DisplayManager وواجهة برمجة التطبيقات على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

7.2. أجهزة إدخال بيانات

عمليات التنفيذ على الأجهزة:

7.2.1. لوحة المفاتيح

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة استخدام تطبيقات محرر أسلوب الإدخال (IME) التابعة لجهات خارجية، يجب أن تستوفي المتطلبات التالية:

عمليات التنفيذ على الأجهزة:

  • [C-0-1] يجب عدم تضمين لوحة مفاتيح أجهزة لا تتطابق مع أحد التنسيقات المحدّدة في android.content.res.Configuration.keyboard (QWERTY أو 12 مفتاحًا).
  • يجب أن تتضمّن عمليات تنفيذ إضافية للوحة المفاتيح.
  • قد تتضمّن لوحة مفاتيح جهاز.

7.2.2. التنقّل بدون لمس الشاشة

يتيح نظام التشغيل Android استخدام لوحة التوجيه وكرة التتبُّع والعجلة كآليات للتنقّل بدون لمس الشاشة.

عمليات التنفيذ على الأجهزة:

إذا كانت عمليات تنفيذ الأجهزة لا تتضمّن طرق تنقّل بدون لمس، فإنّها:

  • [C-1-1] يجب توفير آلية بديلّة معقولة لواجهة المستخدم لتحديد النص وتعديله، وأن تكون متوافقة مع محرّكات إدارة الإدخال. يتضمّن الإصدار الأحدث من الإصدار المفتوح المصدر من Android آلية اختيار مناسبة للاستخدام مع الأجهزة التي لا تتضمّن إدخالات تنقّل غير تعمل باللمس.

7.2.3. مفاتيح التنقل

إنّ وظائف الصفحة الرئيسية والتطبيقات المستخدَمة مؤخرًا والرجوع ، التي يتم توفيرها عادةً من خلال التفاعل مع زرّ فعلي مخصّص أو جزء محدّد من شاشة اللمس، هي وظائف أساسية لنموذج التنقل في Android وبالتالي لعمليات تنفيذ الأجهزة:

  • [C-0-1] يجب توفير عنصر تحكم للمستخدم لتشغيل التطبيقات المثبَّتة التي لها نشاط مع <intent-filter> تم ضبطه على ACTION=MAIN و CATEGORY=LAUNCHER أو CATEGORY=LEANBACK_LAUNCHER لعمليات تنفيذ أجهزة التلفزيون. يجب أن تكون وظيفة "المنزل" هي الآلية التي توفّر هذا الخيار للمستخدم.
  • يجب أن يوفّر التطبيق زرَّين للوظيفتَين "التطبيقات المستخدَمة مؤخرًا" و"الرجوع".

في حال توفّر وظائف "الصفحة الرئيسية" أو "العناصر الأخيرة" أو "رجوع"، يجب أن تستوفي الشروط التالية:

  • [C-1-1] يجب أن يكون بالإمكان الوصول إلى العناصر باستخدام إجراء واحد (مثل النقر أو النقر مرّتين أو إيماءة) عندما يكون بالإمكان الوصول إلى أيّ منها.
  • [C-1-2] يجب تقديم إشارة واضحة إلى الإجراء الفردي الذي يؤدي إلى بدء كل وظيفة. ومن الأمثلة على ذلك تضمين رمز مرئي على الزر، أو عرض رمز برنامج على جزء شريط التنقّل من الشاشة، أو توجيه المستخدم خلال مجرى توضيحي إرشادي خطوة بخطوة أثناء تجربة الإعداد خارج العلبة.

عمليات التنفيذ على الأجهزة:

  • [C-SR-1] يُنصح بشدة بعدم توفير آلية الإدخال لسمة وظيفة القائمة لأنّها متوقّفة نهائيًا لصالح شريط الإجراءات منذ Android 4.0.

  • [C-SR-2] يُنصح بشدة بتوفير جميع وظائف التنقّل على أنّها قابلة للإلغاء. يتم تعريف "قابل للإلغاء" على أنّه قدرة المستخدم على منع تنفيذ وظيفة التنقّل (مثل الانتقال إلى الصفحة الرئيسية أو الرجوع إلى الخلف وما إلى ذلك) في حال عدم رفع إصبع المستخدم عن الشاشة بعد مرور حدّ معيّن.

إذا كانت عمليات تنفيذ الأجهزة توفّر وظيفة "القائمة"، يجب أن:

  • [C-2-1] يجب عرض زر القائمة المنبثقة لعرض المزيد من الإجراءات عندما لا تكون القائمة المنبثقة لعرض المزيد من الإجراءات فارغة ويكون شريط الإجراءات مرئيًا.
  • [C-2-2] يجب عدم تعديل موضع النافذة المنبثقة لعرض الإجراءات الإضافية التي يتم عرضها من خلال النقر على زر القائمة في شريط الإجراءات، ولكن يجوز عرض النافذة المنبثقة لعرض الإجراءات الإضافية في موضع معدَّل على الشاشة عند عرضها من خلال النقر على وظيفة القائمة.

إذا لم توفّر عمليات تنفيذ الأجهزة وظيفة Menu، يجب أن تلتزم بما يلي للحفاظ على التوافق مع الإصدارات القديمة:

  • [C-3-1] يجب إتاحة وظيفة "القائمة" للتطبيقات عندما يكون عدد التطبيقات المثبَّتة على الجهاز هو targetSdkVersion أقل من 10، إما من خلال زرّ خارجي أو مفتاح برمجي أو إيماءات. يجب أن تكون وظيفة القائمة هذه متاحة للوصول إليها ما لم يتم إخفاؤها مع وظائف التنقّل الأخرى.

إذا كانت عمليات تنفيذ الأجهزة توفّر وظيفة المساعدة، يجب أن تستوفي الشروط التالية:

  • [C-4-1] يجب أن تتيح إمكانية الوصول إلى وظيفة "المساعدة" من خلال إجراء واحد (مثل النقر أو النقر مرّتين أو إيماءة) عندما يمكن الوصول إلى مفاتيح التنقّل الأخرى.
  • [C-SR-3] يُنصح بشدة باستخدام الضغط مع الاستمرار على وظيفة HOME لأنّه التفاعل المحدّد.

إذا كانت عمليات تنفيذ الأجهزة تستخدِم جزءًا محددًا من الشاشة لعرض مفاتيح التنقّل، يجب أن تستوفي المتطلبات التالية:

  • [C-5-1] يجب أن تستخدم مفاتيح التنقّل جزءًا محددًا من الشاشة غير متاح للتطبيقات، ويجب ألّا تحجب أو تتداخل مع الجزء من الشاشة المتاح للتطبيقات.
  • [C-5-2] يجب أن يتيح الجهاز جزءًا من الشاشة للتطبيقات التي تفي بالمتطلبات المحدّدة في الفقرة 7.1.1.
  • [C-5-3] يجب أن يراعي التطبيق العلامات التي يضبطها من خلال View.setSystemUiVisibility() طريقة واجهة برمجة التطبيقات، وذلك لإخفاء هذا الجزء الواضح من الشاشة (المعروف أيضًا باسم شريط التنقّل) بشكلٍ سليم كما هو موضّح في مستندات IDE.

إذا تم توفير وظيفة التنقّل كإجراء على الشاشة يستند إلى الإيماءات:

  • [C-6-1] WindowInsets#getMandatorySystemGestureInsets() يجب استخدام هذا الرمز فقط للإبلاغ عن منطقة التعرّف على إيماءات Home.
  • [C-6-2] يجب عدم اعتراض الإيماءات التي تبدأ داخل مستطيل استبعاد كما يقدّمها التطبيق الذي يعمل في المقدّمة من خلال View#setSystemGestureExclusionRects()، ولكن خارج WindowInsets#getMandatorySystemGestureInsets()، لوظيفة التنقّل ما دام مستطيل الاستبعاد مسموحًا به ضمن الحد الأقصى للاستبعاد على النحو المحدّد في مستندات View#setSystemGestureExclusionRects().
  • [C-6-3] يجب إرسال حدث MotionEvent.ACTION_CANCEL إلى التطبيق المعروض في المقدّمة بعد بدء اعتراض اللمسات لتنفيذ إيماءة نظام، إذا سبق أن تم إرسال حدث MotionEvent.ACTION_DOWN إلى التطبيق المعروض في المقدّمة.
  • [C-6-4] يجب أن توفّر ميزة للمستخدم للتبديل إلى تنقّل على الشاشة يستند إلى buttons (مثلاً، في الإعدادات).
  • يجب أن توفّر وظيفة "الشاشة الرئيسية" من خلال التمرير سريعًا من الحافة السفلية لاتجاه الشاشة الحالي.
  • يجب أن توفّر وظيفة "التطبيقات المستخدَمة مؤخرًا" من خلال التمرير سريعًا للأعلى مع الاستمرار قبل تحرير الإصبع، من المنطقة نفسها التي يتم فيها استخدام إيماءة "الرجوع إلى الشاشة الرئيسية".
  • يجب ألا تتأثر الإيماءات التي تبدأ في WindowInsets#getMandatorySystemGestureInsets() بأشكال الاستبعاد التي يوفّرها التطبيق في المقدّمة من خلال View#setSystemGestureExclusionRects().

إذا تم توفير وظيفة تنقّل من أي مكان على الحافتَين اليسرى واليمنى لاتجاه الشاشة الحالي:

  • [C-7-1] يجب أن تكون وظيفة التنقّل هي "رجوع" وأن يتم توفيرها من خلال التمرير سريعًا من الحافتَين اليمنى واليسرى للاتجاه الحالي للشاشة.
  • [C-7-2] في حال توفُّر لوحات نظام مخصّصة يمكن التمرير عليها على الحافة اليسرى أو اليمنى، يجب وضعها في الثلث العلوي من الشاشة مع تقديم إشارة مرئية واضحة ومستمرة بأنّ سحب المحتوى سيؤدي إلى عرض اللوحات المذكورة أعلاه، وبالتالي لن يؤدي إلى عرض رمز الرجوع. يجوز للمستخدم ضبط لوحة النظام بحيث تقع أسفل ثلث أعلى شاشة الحواف، ولكن يجب ألا تستخدم لوحة النظام أكثر من ثلث الحواف.
  • [C-7-3] عندما يكون للتطبيق الذي يعمل في المقدّمة علامة التمييز View.SYSTEM_UI_FLAG_IMMERSIVE أو View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY أو WindowInsetsController.BEHAVIOR_DEFAULT أو WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE، يجب أن يكون سلوك التمرير السريع من الحواف كما هو مُطبَّق في AOSP، وهو مُوثَّق في حِزمة تطوير البرامج (SDK).
  • [C-7-4] عندما يكون للتطبيق الذي يعمل في المقدّمة علامة ‎ View.SYSTEM_UI_FLAG_IMMERSIVE أو ‎View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY أو ‎ WindowInsetsController.BEHAVIOR_DEFAULT أو ‎ WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE، يجب إخفاء لوحات النظام المخصّصة التي يمكن التمرير عليها إلى أن يعرض المستخدم بارات النظام (المعروفة أيضًا باسم شريط التنقّل وشريط الحالة) أو يزيل تمويهها كما هو معمول به في AOSP.

إذا تم توفير وظيفة التنقّل للخلف وألغى المستخدم إيماءة الرجووع، في هذه الحالة:

  • [C-8-1] يجب استدعاء OnBackInvokedCallback.onBackCancelled().
  • [C-8-2] يجب عدم استدعاء OnBackInvokedCallback.onBackInvoked().
  • [C-8-3] يجب عدم إرسال الحدث KEYCODE_BACK.

إذا تم توفير وظيفة التنقّل للخلف ولكن تطبيق المقدّمة ليس لديهOnBackInvokedCallback مسجَّل، في هذه الحالة:

  • من المفترض أن يعرض النظام صورة متحركة للتطبيق الذي يعمل في المقدّمة تشير إلى أنّ المستخدم سيعود إلى الخلف، كما هو موضح في AOSP.

إذا كانت عمليات تنفيذ الأجهزة تتيح استخدام واجهة برمجة التطبيقات setNavBarMode للنظام بهدف السماح لأي تطبيق نظام لديه إذن android.permission.STATUS_BAR بضبط وضع شريط التنقّل، يجب أن تستوفي العمليات المتطلبات التالية:

  • [C-9-1] يجب أن يتيح استخدام الرموز الملائمة للأطفال أو التنقل بالاستناد إلى buttons كما هو موضّح في رمز AOSP.

7.2.4. الإدخال من خلال شاشة تعمل باللمس

يتيح Android استخدام مجموعة متنوعة من أنظمة إدخال المؤشر، مثل الشاشات التي تعمل باللمس ولوحات اللمس وأجهزة إدخال اللمس الزائف. عمليات تنفيذ الأجهزة المستندة إلى الشاشة التي تعمل باللمس: تكون مرتبطة بشاشة بحيث يشعر المستخدم أنّه يشغّل العناصر على الشاشة مباشرةً. بما أنّ المستخدم يلمس الشاشة مباشرةً، لا يتطلّب النظام أيّ عناصر تحكم إضافية للإشارة إلى الأجسام التي يتم التحكّم فيها.

عمليات التنفيذ على الأجهزة:

  • يجب أن يتضمّن نظام إدخال مؤشر من نوع ما (إما مثل الماوس أو باللمس).
  • يجب أن تتيح استخدام مؤشرات يتم تتبُّعها بشكل مستقل بالكامل.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة تعمل باللمس (شاشة تعمل باللمس بلمسة واحدة أو أفضل) على شاشة أساسية متوافقة مع Android، يجب استيفاء الشروط التالية:

  • [C-1-1] يجب الإبلاغ عن TOUCHSCREEN_FINGER لحقل واجهة برمجة التطبيقات Configuration.touchscreen.
  • [C-1-2] يجب الإبلاغ عن علامتَي ميزة android.hardware.touchscreen و android.hardware.faketouch.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة تعمل باللمس يمكنها تتبُّع أكثر من لمسة واحدة على شاشة أساسية متوافقة مع Android، يجب استيفاء الشروط التالية:

  • [C-2-1] يجب الإبلاغ عن علامات الميزات المناسبة android.hardware.touchscreen.multitouch، android.hardware.touchscreen.multitouch.distinct، android.hardware.touchscreen.multitouch.jazzhand التي تتوافق مع نوع الشاشة التي تعمل باللمس المحدّدة على الجهاز.

إذا كانت عمليات تنفيذ الأجهزة تعتمد على جهاز إدخال خارجي، مثل الماوس أو كرة المسار (أي عدم لمس الشاشة مباشرةً) لإدخال البيانات على شاشة primary متوافقة مع Android واستيفاء متطلبات اللمس الزائف في الفقرة 7.2.5، يجب استيفاء الشروط التالية:

  • [C-3-1] يجب عدم الإبلاغ عن أي علامة ميزة تبدأ بالرمز android.hardware.touchscreen.
  • [C-3-2] يجب الإبلاغ عن android.hardware.faketouch فقط.
  • [C-3-3] يجب الإبلاغ عن TOUCHSCREEN_NOTOUCH لحقل Configuration.touchscreen واجهة برمجة التطبيقات.

7.2.5. الإدخال باللمس الزائف

توفّر واجهة اللمس الزائف نظامًا لإدخال المستخدمين يقارب مجموعة فرعية من إمكانات الشاشة التي تعمل باللمس. على سبيل المثال، يُعدّ الماوس أو جهاز التحكّم عن بُعد الذي يشغّل مؤشرًا على الشاشة مشابهًا لللمس، ولكنّه يتطلّب من المستخدم أولاً الإشارة أو التركيز ثم النقر. يمكن أن تتيح العديد من أجهزة الإدخال، مثل الماوس ولوحة اللمس واللوحة التصويرية المزوّدة بجهاز استشعار الدوران وماوس الهواء المزوّد بجهاز استشعار الدوران والمؤشر المزوّد بجهاز استشعار الدوران وعصا التحكم ولوحة اللمس المزوّدة بتقنية اللمس المتعدّد، تفاعلات مماثلة لللمس. يتضمّن نظام التشغيل Android الثابت المتعلق بالميزة android.hardware.faketouch، والذي يتوافق مع جهاز إدخال عالي الدقة غير مستنِد إلى اللمس (يستند إلى المؤشر)، مثل الماوس أو لوحة اللمس، والذي يمكنه محاكاة الإدخال المستنِد إلى اللمس بشكلٍ كافٍ (بما في ذلك إتاحة الإيماءات الأساسية)، ويشير إلى أنّه يتوافق الجهاز مع مجموعة فرعية محاكية من وظائف الشاشة التي تعمل باللمس.

إذا كانت عمليات تنفيذ الأجهزة لا تتضمّن شاشة تعمل باللمس ولكن تتضمّن نظام إدخال مؤشر آخر يريدون إتاحته، عليهم اتّباع الخطوات التالية:

  • يجب الإفصاح عن توافق التطبيق مع علامة ميزة android.hardware.faketouch.

إذا كانت عمليات تنفيذ الأجهزة تعلن عن توافقها مع android.hardware.faketouch، يجب أن تستوفي الشروط التالية:

  • [C-1-1] يجب الإبلاغ عن الموضع المطلق للشاشة على محورَي X وY لموضع المؤشر وعرض مؤشر مرئي على الشاشة.
  • [C-1-2] يجب الإبلاغ عن حدث اللمس باستخدام رمز الإجراء الذي يحدّد تغيير الحالة الذي يحدث على المؤشر عند الانتقال للأسفل أو للأعلى على الشاشة.
  • [C-1-3] يجب أن تتيح أدوات التحكم تحريك المؤشر للأسفل وللأعلى على عنصر على الشاشة، ما يسمح للمستخدمين بمحاكاة النقر على عنصر على الشاشة.
  • [C-1-4] يجب أن يتيح استخدام مؤشر الماوس للأسفل ثم للأعلى ثم للأسفل ثم للأعلى في المكان نفسه على عنصر على الشاشة خلال حد زمني معيّن، ما يسمح للمستخدمين بمحاكاة النقر مرّتين على عنصر على الشاشة.
  • [C-1-5] يجب أن يتيح المؤشر الانتقال للأسفل في نقطة عشوائية على الشاشة، وانتقال المؤشر إلى أي نقطة عشوائية أخرى على الشاشة، ثم الانتقال للأعلى، ما يتيح للمستخدمين محاكاة السحب باللمس.
  • [C-1-6] يجب أن يتيح المؤشر للأسفل للمستخدمين تحريك العنصر بسرعة إلى موضع مختلف على الشاشة ثم المؤشر للأعلى على الشاشة، ما يسمح للمستخدمين برمي عنصر على الشاشة.

إذا كانت عمليات تنفيذ الأجهزة تعلن عن توافقها مع 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. عمليات ربط الأزرار

عمليات التنفيذ على الأجهزة:

  • [C-1-1] يجب أن يكون النظام قادرًا على ربط أحداث HID بثوابت InputEvent المقابلة كما هو موضّح في الجداول أدناه. يستوفي تطبيق Android هذا الشرط.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن وحدة تحكّم أو يتم شحنها مع وحدة تحكّم منفصلة في العلبة توفّر وسائل لإدخال جميع الأحداث المدرَجة في الجداول أدناه، يجب استيفاء الشروط التالية:

  • [C-2-1] يجب الإفصاح عن علامة الميزة android.hardware.gamepad
زرّ استخدام 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 0x0224 KEYCODE_BACK (4)

‫1 KeyEvent

2 يجب الإفصاح عن استخدامات HID المذكورة أعلاه ضمن CA لجهاز تحكّم في الألعاب (0x01 0x0005).

3 يجب أن يكون الحد الأدنى المنطقي لهذا الاستخدام هو 0، والحد الأقصى المنطقي هو 7، والحد الأدنى المادي هو 0، والحد الأقصى المادي هو 315، والوحدات بالدرجات، وحجم التقرير هو 4. يتم تعريف القيمة المنطقية على أنّها الدوران باتجاه عقارب الساعة بعيدًا عن المحور العمودي. على سبيل المثال، تمثل القيمة المنطقية 0 عدم دوران ويتم الضغط على الزر "أعلى"، في حين تمثل القيمة المنطقية 1 دورانًا بزاوية 45 درجة ويتم الضغط على كل من الزرَّين "أعلى" و"يسار".

‫4 MotionEvent

عناصر التحكّم التناظرية1 استخدام HID زر Android
المشغِّل الأيسر 0x02 0x00C5 AXIS_LTRIGGER
مشغِّل الإجراء الأيمن 0x02 0x00C4 AXIS_RTRIGGER
ذراع التحكّم الأيسر 0x01 0x0030
0x01 0x0031
AXIS_X
AXIS_Y
ذراع التحكّم الأيمن 0x01 0x0032
0x01 0x0035
AXIS_Z
AXIS_RZ

‫1 MotionEvent

7.2.7. جهاز التحكّم عن بُعد

اطّلِع على الفقرة 2.3.1 لمعرفة المتطلبات الخاصة بالأجهزة.

7.3. أجهزة الاستشعار

إذا كانت عمليات تنفيذ الأجهزة تتضمّن نوعًا معيّنًا من أجهزة الاستشعار يتضمّن واجهة برمجة تطبيقات مقابلة للمطوّرين التابعين لجهات خارجية، يجب أن تُنفِّذ عملية تنفيذ الجهاز واجهة برمجة التطبيقات هذه على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android ومستندات أجهزة الاستشعار في المصدر المفتوح لنظام التشغيل Android.

عمليات التنفيذ على الأجهزة:

  • [C-0-1] يجب الإبلاغ بدقة عن توفّر أدوات الاستشعار أو عدم توفّرها وفقًا ل android.content.pm.PackageManager الفئة.
  • [C-0-2] يجب أن يعرض التطبيق قائمة دقيقة بأجهزة الاستشعار المتوافقة من خلال SensorManager.getSensorList() والطرق المشابهة.
  • [C-0-3] يجب أن تعمل بشكل معقول مع جميع واجهات برمجة التطبيقات الأخرى الخاصة بأجهزة الاستشعار (على سبيل المثال، عن طريق عرض true أو false حسب الاقتضاء عندما تحاول التطبيقات تسجيل المستمعين، وعدم استدعاء مستمعي أجهزة الاستشعار عندما لا تكون أجهزة الاستشعار المقابلة متوفّرة، وما إلى ذلك).

إذا كانت عمليات تنفيذ الأجهزة تتضمّن نوعًا معيّنًا من أجهزة الاستشعار التي تحتوي على IDE corresponding API للمطوّرين التابعين لجهات خارجية، عليهم:

  • [C-1-1] يجب الإبلاغ عن جميع قياسات أجهزة الاستشعار باستخدام قيم النظام الدولي للوحدات (المقياس) ذات الصلة لكل نوع من أجهزة الاستشعار كما هو محدّد في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
  • [C-1-2] يجب الإبلاغ عن بيانات أجهزة الاستشعار بحد أقصى لمُدد الاستجابة يبلغ 100 ملي ثانية + 2 * وقت_التحليل في حال بث بيانات أجهزة الاستشعار بحد أقصى لمُدد الاستجابة المطلوبة يبلغ 0 ملي ثانية عندما يكون معالج التطبيقات نشطًا. ولا يشمل هذا التأخير أي تأخيرات في الفلترة.
  • [C-1-3] يجب الإبلاغ عن أول عيّنة من بيانات المستشعر في غضون 400 ملي ثانية + 2 * وقت_العيّنة من وقت تفعيل المستشعر. من المقبول أن تبلغ دقة هذه العيّنة 0.
  • [C-1-4] بالنسبة إلى أيّ واجهة برمجة تطبيقات يشير مستند حزمة تطوير البرامج (SDK) لنظام التشغيل Android إلى أنّها جهاز استشعار مستمر، يجب أن تقدّم عمليات تنفيذ الأجهزة باستمرار عيّنات بيانات دورية يجب أن يكون لها انحرافًا أقل من %3، حيث يتم تعريف الانحراف على أنّه التباين المعياري للفرق بين قيم الطوابع الزمنية المسجّلة بين الأحداث المتتالية.
  • [C-1-5] يجب التأكّد من أنّه يجب ألا يمنع بث أحداث الاستشعار وحدة المعالجة المركزية (CPU) في الجهاز من الدخول في حالة تعليق أو الاستيقاظ من حالة تعليق.
  • [C-1-6] يجب تسجيل وقت الحدث بالنانو ثانية كما هو محدّد في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android، ما يمثّل وقت وقوع الحدث ومزامنة مع الساعة SystemClock.elapsedRealtimeNano()‎.
  • [C-SR-1] يُنصح بشدة بأن يكون خطأ مزامنة الطابع الزمني أقل من 100 مللي ثانية، ويجب أن يكون خطأ مزامنة الطابع الزمني أقل من 1 مللي ثانية.
  • عند تفعيل عدة أدوات استشعار، يجب ألا يتجاوز استهلاك الطاقة مجموع استهلاك الطاقة المسجَّل لكل أداة استشعار فردية.

القائمة أعلاه ليست شاملة، ويجب اعتبار السلوك الموثَّق لحزمة SDK لنظام التشغيل Android ومستندات Android Open Source حول أجهزة الاستشعار مرجعيًا.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن نوعًا معيّنًا من أجهزة الاستشعار التي تحتوي على IDE corresponding API للمطوّرين التابعين لجهات خارجية، عليهم:

  • [C-1-6] يجب ضبط درجة دقة غير صفرية لجميع أجهزة الاستشعار والإبلاغ عن القيمة من خلال Sensor.getResolution() طريقة واجهة برمجة التطبيقات.

بعض أنواع أجهزة الاستشعار مركبة، ما يعني أنّه يمكن الحصول عليها من بيانات يوفّرها جهاز استشعار واحد أو أكثر. (تشمل الأمثلة أداة استشعار الاتجاه ومقاييس التسارع الخطي).

عمليات التنفيذ على الأجهزة:

  • يجب تنفيذ أنواع أجهزة الاستشعار هذه، عندما تشمل أجهزة الاستشعار المادية المطلوبة كما هو موضّح في أنواع أجهزة الاستشعار.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن أداة استشعار مركبة، يجب استيفاء الشروط التالية:

  • [C-2-1] يجب تنفيذ أداة الاستشعار كما هو موضّح في مستندات أجهزة الاستشعار المركبة المتوفّرة في المصدر المفتوح لنظام التشغيل Android.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن نوعًا معيّنًا من أجهزة الاستشعار يحتوي على واجهة برمجة تطبيقات مكافئة للمطوّرين التابعين لجهات خارجية، ولا يُبلِغ جهاز الاستشعار إلا عن قيمة واحدة، تكون عمليات تنفيذ الأجهزة:

  • [C-3-1] يجب ضبط درجة الدقة على 1 لجهاز الاستشعار والإبلاغ عن القيمة من خلال طريقة واجهة برمجة التطبيقات Sensor.getResolution().

إذا كانت عمليات تنفيذ الأجهزة تتضمّن نوعًا معيّنًا من أجهزة الاستشعار يتيح استخدام SensorAdditionalInfo#TYPE_VEC3_CALIBRATION وكانت أجهزة الاستشعار متاحة للمطوّرين التابعين لجهات خارجية، يمكنهم إجراء ما يلي:

  • [C-4-1] يجب عدم تضمين أي مَعلمات قياس ثابتة تحدّدها الشركة المصنّعة في البيانات المقدَّمة.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مجموعة من أدوات قياس التسارع بثلاثة محاور أو جهاز استشعار جيروسكوب بثلاثة محاور أو جهاز استشعار مقياس مغناطيسي، تكون على النحو التالي:

  • [C-SR-2] يُنصح بشدة بضمان أن يكون لمقياس التسارع والجيروسكوب ومقاييس المغناطيسية موضع نسبي ثابت، بحيث إذا كان الجهاز قابلاً للتحويل (مثلاً قابلاً للطي)، تظل محاور أداة الاستشعار متوافقة ومتسقة مع نظام إحداثيات أداة الاستشعار في جميع حالات التحويل المحتمَلة للجهاز.

7.3.1. مقياس التسارع

عمليات التنفيذ على الأجهزة:

  • [C-SR-1] يُنصح بشدة بتضمين مقياس تسارع ثلاثي المحاور.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن أداة قياس السرعة، يجب استيفاء الشروط التالية:

  • [C-1-1] يجب أن يكون الجهاز قادرًا على تسجيل الأحداث بمعدّل تكرار لا يقل عن 50 هرتز.
  • [C-1-3] يجب أن تكون متوافقة مع نظام إحداثيات أدوات استشعار Android كما هو موضّح في واجهات برمجة تطبيقات Android.
  • [C-1-4] يجب أن يكون الجهاز قادرًا على قياس التسارع من السقوط الحر إلى أربع مرات كثافة الجاذبية(4g) أو أكثر على أي محور.
  • [C-1-5] يجب أن تكون درجة دقة الصورة 12 بت على الأقل.
  • [C-1-6] يجب أن يكون التباين المعياري لا يزيد عن 0.05 متر في الثانية المربعة، حيث يجب احتساب التباين المعياري لكل محور على أساس عيّنات يتم جمعها على مدار 3 ثوانٍ على الأقل بأسرع معدّل تحليل.
  • يجب الإبلاغ عن الأحداث التي تصل إلى 200 هرتز على الأقل.
  • يجب أن تكون درجة دقتها 16 بت على الأقل.
  • يجب معايرة هذه الخصائص أثناء الاستخدام إذا تغيّرت على مدار دورة الحياة، ويجب تعويضها والحفاظ على مَعلمات التعويض بين عمليات إعادة تشغيل الجهاز.
  • يجب أن يتم تصحيحها حسب درجة الحرارة.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس تسارع ثلاثي المحاور، يجب استيفاء الشروط التالية:

  • [C-2-1] يجب تنفيذ TYPE_ACCELEROMETER sensor والإبلاغ عنه.
  • [C-SR-4] يُنصح بشدة بتنفيذ TYPE_SIGNIFICANT_MOTION أداة الاستشعار المركبة.
  • [C-SR-5] يُنصح بشدة بتنفيذ رصد TYPE_ACCELEROMETER_UNCALIBRATED والإبلاغ عنه. ننصح بشدة باستيفاء أجهزة Android لهذا الشرط حتى تتمكّن من الترقية إلى إصدار المنصة المستقبلي الذي قد يصبح فيه هذا الشرط مطلوبًا.
  • يجب تنفيذ TYPE_SIGNIFICANT_MOTION وTYPE_TILT_DETECTOR TYPE_STEP_DETECTOR وTYPE_STEP_COUNTER الأجهزة الاستشعارية المركبة كما هو موضّح في مستند حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن أداة قياس سرعة تتضمّن أقل من 3 محاور، يجب استيفاء الشروط التالية:

  • [C-3-1] يجب تنفيذ TYPE_ACCELEROMETER_LIMITED_AXES sensor والإبلاغ عنه.
  • [C-SR-6] يُنصح بشدة بتنفيذ رصد TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED والإبلاغ عنه.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن أداة تسارع 3 محاور وأيًا من أجهزة الاستشعار المركبة TYPE_SIGNIFICANT_MOTION وTYPE_TILT_DETECTOR وTYPE_STEP_DETECTOR TYPE_STEP_COUNTER:

  • [C-4-1] يجب أن يكون مجموع استهلاك الطاقة أقل من 4 ملي واط في أي وقت.
  • يجب أن يكون كل منهما أقل من 2 ملي واط و0.5 ملي واط عندما يكون الجهاز في حالة ديناميكية أو ساكنة.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس تسارع ثلاثي المحاور وجهاز استشعار جيروسكوب ثلاثي المحاور، يجب أن:

  • [C-5-1] يجب تنفيذ TYPE_GRAVITY وTYPE_LINEAR_ACCELERATION أجهزة الاستشعار المركبة.
  • [C-SR-7] يُنصح بشدة بتنفيذ أداة الاستشعار المركبة TYPE_GAME_ROTATION_VECTOR.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس تسارع ثلاثي المحاور وجهاز استشعار جيروسكوب ثلاثي المحاور وجهاز استشعار للمغناطيسية، يجب استيفاء الشروط التالية:

  • [C-6-1] يجب استخدام أداة استشعار مركبة TYPE_ROTATION_VECTOR.

7.3.2. مقياس المغناطيسية

عمليات التنفيذ على الأجهزة:

  • [C-SR-1] يُنصح بشدة بتضمين مقياس مغناطيسي ثلاثي المحاور (بوصلة).

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس مغناطيسية بثلاثة محاور، يجب استيفاء الشروط التالية:

  • [C-1-1] يجب تنفيذ أداة استشعار TYPE_MAGNETIC_FIELD.
  • [C-1-2] يجب أن يكون الجهاز قادرًا على تسجيل الأحداث بمعدّل تكرار لا يقل عن 10 هرتز، ويجب أن يسجِّل الأحداث بمعدّل تكرار لا يقل عن 50 هرتز.
  • [C-1-3] يجب أن يكون متوافقًا مع نظام إحداثيات أدوات استشعار Android كما هو موضّح بالتفصيل في واجهات برمجة تطبيقات Android.
  • [C-1-4] يجب أن يكون الجهاز قادرًا على قياس قيم تتراوح بين -900 و+900 µT على كل محور قبل الوصول إلى التشبع.
  • [C-1-5] يجب أن تكون قيمة إزاحة الحديد الصلب أقل من 700 ميكرو تسلا، ويجب أن تكون قيمتها أقل من 200 ميكرو تسلا، وذلك من خلال وضع مقياس المغناطيسية بعيدًا عن الحقول المغناطيسية الديناميكية (المُنشأة بالتيار الكهربي) والثابتة (المُنشأة بالمغناطيس).
  • [C-1-6] يجب أن تكون درجة الدقة مساوية أو أعلى من 0.6 ميكرو تسلا.
  • [C-1-7] يجب أن يتيح الجهاز معايرة الانحراف المغناطيسي للحديد الصلب وإصلاحه على الإنترنت، والحفاظ على مَعلمات التعويض بين عمليات إعادة تشغيل الجهاز.
  • [C-1-8] يجب تطبيق التعويض عن الحديد اللين، ويمكن إجراء المعايرة أثناء الاستخدام أو أثناء إنتاج الجهاز.
  • [C-1-9] يجب أن يكون الانحراف المعياري، الذي يتم احتسابه لكل محور على أساس العينات التي تم جمعها على مدار فترة لا تقل عن 3 ثوانٍ بأسرع معدل جمع عينات، لا يزيد عن 1.5 ميكرو تسلا، ويجب أن يكون الانحراف المعياري لا يزيد عن 0.5 ميكرو تسلا.
  • [C-1-10] يجب تنفيذ ميزة TYPE_MAGNETIC_FIELD_UNCALIBRATED الاستشعار.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس مغناطيسية ثلاثي المحاور ومقياس تسارع وجهاز استشعار جيروسكوب ثلاثي المحاور، يجب استيفاء الشروط التالية:

  • [C-2-1] يجب تنفيذ أداة استشعار مركبة TYPE_ROTATION_VECTOR.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس مغناطيسية ثلاثي المحاور ومقياس تسارع، يجب استيفاء الشروط التالية:

  • يجوز تنفيذ أداة استشعار TYPE_GEOMAGNETIC_ROTATION_VECTOR.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس مغناطيسية ثلاثي المحاور ومقياس تسارع وجهاز استشعار TYPE_GEOMAGNETIC_ROTATION_VECTOR، يجب استيفاء الشروط التالية:

  • [C-3-1] يجب أن يستهلك الجهاز طاقة أقل من 10 ملي واط.
  • يجب أن يستهلك طاقة أقل من 3 ملي واط عند تسجيل المستشعر في وضع الحِزم بمعدل 10 هرتز.

7.3.3. نظام تحديد المواقع العالمي (GPS)

عمليات التنفيذ على الأجهزة:

  • [C-SR-1] يُنصح بشدة بتضمين جهاز استقبال GPS/GNSS.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن جهاز استقبال لنظام تحديد المواقع العالمي (GPS) أو نظام تحديد المواقع العالمي (GNSS) وتُبلغ عن إمكانية استخدام التطبيقات من خلال علامة ميزة android.hardware.location.gps، يجب استيفاء الشروط التالية:

  • [C-1-1] يجب أن تتيح مخرجات الموقع الجغرافي بمعدّل لا يقل عن 1 هرتز عند طلبها من خلال LocationManager#requestLocationUpdate.
  • [C-1-2] يجب أن يكون الجهاز قادرًا على تحديد الموقع الجغرافي في ظروف السماء المفتوحة (إشارات قوية، ومسارات متعددة لا يُعتد بها، وHDOP < 2) في غضون 10 ثوانٍ (وقت تحديد الموقع الجغرافي الأول سريع)، عند الاتصال بالإنترنت بسرعة بيانات تبلغ 0.5 ميغابت في الثانية أو أكثر. يتم عادةً استيفاء هذا الشرط من خلال استخدام أحد أشكال تقنية GPS/GNSS المساعدة أو المتوقّعة لخفض وقت الربط بنظام GPS/GNSS إلى الحد الأدنى (تشمل بيانات المساعدة الوقت المرجعي والموقع الجغرافي المرجعي وجدول المدّ والجزر للأقمار الصناعية/الساعة).
    • [C-1-6] بعد إجراء عملية احتساب الموقع الجغرافي هذه، يجب أن تحدِّد عمليات تنفيذ التطبيقات على الجهاز موقعه الجغرافي في السماء المفتوحة في غضون 5 ثوانٍ عند إعادة تشغيل طلبات الموقع الجغرافي، ويجب أن يتم ذلك في غضون ساعة واحدة كحد أقصى من احتساب الموقع الجغرافي الأولي، حتى في حال إجراء الطلب التالي بدون اتصال بالبيانات و/أو بعد إعادة تشغيل الجهاز.
  • في ظروف السماء المفتوحة بعد تحديد الموقع الجغرافي، أثناء الثبات أو الحركة بسرعة تسارع أقل من متر واحد في الثانية المربعة:

    • [C-1-3] يجب أن يكون الجهاز قادرًا على تحديد الموقع الجغرافي ضمن نطاق 20 مترًا، وسرعة التنقّل ضمن نطاق 0.5 متر في الثانية، في% 95 من الوقت على الأقل.
    • [C-1-4] يجب تتبُّع 8 أقمار صناعية على الأقل من مجموعة نجوم واحدة والإبلاغ عنها في الوقت نفسه من خلال GnssStatus.Callback.
    • يجب أن يكون الجهاز قادرًا على تتبُّع 24 قمرًا صناعيًا على الأقل في وقت واحد من أنظمة تحديد المواقع المتعدّدة (مثل نظام تحديد المواقع العالمي (GPS) ونظام GLONASS ونظام Beidou ونظام Galileo على الأقل).
  • [C-SR-2] يُنصح بشدة بمواصلة عرض نتائج الموقع الجغرافي العادية من خلال واجهات برمجة التطبيقات GNSS Location Provider API أثناء مكالمة هاتفية للطوارئ.

  • [C-SR-3] يُنصح بشدة بالإبلاغ عن قياسات نظام تحديد المواقع العالمي (GNSS) من جميع المجموعات النجمية التي يتم تتبُّعها (كما هو موضّح في رسائل GnssStatus)، باستثناء نظام SBAS.

  • [C-SR-4] يُنصح بشدة بالإبلاغ عن AGC ومعدّل قياس GNSS.

  • [C-SR-5] يُنصح بشدة بالإبلاغ عن جميع تقديرات الدقة (بما في ذلك الاتجاه والسرعة والقيمة العمودية) كجزء من كل موقع جغرافي لنظام تحديد المواقع العالمي (GPS) أو نظام تحديد المواقع العالمي (GNSS).

  • [C-SR-6] يُنصح بشدة بالإبلاغ عن قياسات نظام تحديد المواقع العالمي (GNSS) فورًا عند العثور عليها، حتى إذا لم يتم الإبلاغ عن موقع جغرافي تم احتسابه من نظام تحديد المواقع العالمي (GPS)/نظام تحديد المواقع العالمي (GNSS).

  • [C-SR-7] يُنصح بشدة بالإبلاغ عن نطاقات GNSS الزائفة ومقدّرات النطاقات الزائفة، والتي تكون كافية لاحتساب الموقع الجغرافي ضمن 20 مترًا والسرعة ضمن 0.2 متر في الثانية في ‎95% من الوقت على الأقل، وذلك في ظروف السماء المفتوحة بعد تحديد الموقع الجغرافي، سواء كان الجهاز ثابتًا أو متحركًا بمعدّل تسارع أقل من 0.2 متر في الثانية المربعة.

7.3.4. الجيروسكوب

عمليات التنفيذ على الأجهزة:

  • [C-SR-1] يُنصح بشدة بتضمين أداة استشعار جيروسكوب.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن جيروسكوبًا، يجب استيفاء الشروط التالية:

  • [C-1-1] يجب أن يكون الجهاز قادرًا على تسجيل الأحداث بمعدّل تكرار لا يقل عن 50 هرتز.
  • [C-1-4] يجب أن تكون درجة دقة الصورة 12 بت أو أكثر.
  • [C-1-5] يجب أن يكون مُعدَّلاً للحرارة.
  • [C-1-6] يجب معايرة الجهاز وتعويضه أثناء الاستخدام، والحفاظ على مَعلمات التعويض بين عمليات إعادة تشغيل الجهاز.
  • [C-1-7] يجب ألا يزيد التباين عن 1e-7 rad^2 / s^2 لكل هرتز (التباين لكل هرتز أو rad^2 / s). يُسمح باختلاف التباين مع معدل أخذ العينات، ولكن يجب أن يكون مقيّدًا بهذه القيمة. بعبارة أخرى، إذا measuredيتم قياس التباين في أداة الاستشعار الدوراني بمعدّل أخذ عينات يبلغ 1 هرتز، يجب ألا يزيد عن 1e-7 rad^2/s^2.
  • [C-SR-2] يُنصح بشدة بأن يكون خطأ المعايرة أقل من 0.01 راد/ث عندما يكون الجهاز ثابتًا في درجة حرارة الغرفة.
  • [C-SR-3] يُنصح بشدة بدرجة دقة 16 بت أو أكثر.
  • يجب الإبلاغ عن الأحداث التي تصل إلى 200 هرتز على الأقل.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن جيروسكوبًا ثلاثي المحاور، يجب استيفاء الشروط التالية:

  • [C-2-1] يجب تنفيذ أداة استشعار TYPE_GYROSCOPE.
  • [C-SR-4] يُنصح بشدة بتنفيذ أداة الاستشعار TYPE_GYROSCOPE_UNCALIBRATED.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن جيروسكوبًا يحتوي على أقل من 3 محاور، يجب استيفاء الشروط التالية:

  • [C-3-1] يجب تنفيذ TYPE_GYROSCOPE_LIMITED_AXES sensor والإبلاغ عنه.
  • [C-SR-5] ننصح بشدة بتنفيذ قياسات TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED والإبلاغ عنها.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن جيروسكوبًا ثلاثي المحاور وجهاز استشعار تسارع وجهاز استشعار مغناطيسية، يجب استيفاء الشروط التالية:

  • [C-4-1] يجب استخدام أداة استشعار مركبة TYPE_ROTATION_VECTOR.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس تسارع ثلاثي المحاور وجهاز استشعار دوار ثلاثي المحاور، يجب استيفاء الشروط التالية:

  • [C-5-1] يجب تنفيذ TYPE_GRAVITY وTYPE_LINEAR_ACCELERATION أجهزة الاستشعار المركبة.
  • [C-SR-6] يُنصح بشدة بتنفيذ أداة الاستشعار المركبة TYPE_GAME_ROTATION_VECTOR.

7.3.5. مقياس الضغط الجوي

عمليات التنفيذ على الأجهزة:

  • [C-SR-1] يُنصح بشدة بتضمين مقياس ضغط جوي (جهاز استشعار ضغط الهواء المحيط).

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس ضغط جوي، يجب استيفاء الشروط التالية:

  • [C-1-1] يجب تنفيذ TYPE_PRESSURE sensor والإبلاغ عنه.
  • [C-1-2] يجب أن يكون الجهاز قادرًا على إرسال الأحداث بمعدّل 5 هرتز أو أكثر.
  • [C-1-3] يجب أن يكون مُعدَّلاً للحرارة.
  • [C-SR-2] يُنصح بشدة بإمكانية تسجيل قياسات الضغط في النطاق من 300hPa إلى 1100hPa.
  • يجب أن تكون الدقة المطلقة 1hPa.
  • يجب أن تكون الدقة النسبية 0.12hPa على نطاق 20hPa (أي ما يعادل دقة متر واحد تقريبًا على نطاق 200 متر تقريبًا على مستوى سطح البحر).

7.3.6. مقياس درجة الحرارة

إذا كانت عمليات تنفيذ الأجهزة تتضمّن ميزان حرارة للبيئة المحيطة (أداة استشعار درجة الحرارة)، يجب أن تستوفي الشروط التالية:

  • [C-1-1] يجب تحديد SENSOR_TYPE_AMBIENT_TEMPERATURE لجهاز استشعار درجة الحرارة المحيطة، ويجب أن يقيس الجهاز درجة الحرارة المحيطة (درجة حرارة الغرفة أو مقصورة المركبة) من حيث يتفاعل المستخدم مع الجهاز بالدرجات المئوية.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن أداة استشعار ميزان حرارة تقيس درجة حرارة غير درجة الحرارة المحيطة، مثل درجة حرارة وحدة المعالجة المركزية، يجب استيفاء الشروط التالية:

إذا كانت عمليات تنفيذ الأجهزة تتضمّن أداة استشعار لمراقبة درجة حرارة الجلد، يجب استيفاء الشروط التالية:

7.3.7. مقياس الإضاءة

  • قد تتضمّن عمليات تنفيذ الأجهزة مقياسًا للضوء (أداة استشعار الضوء المحيط).

7.3.8. أداة استشعار التقارب

  • قد تتضمّن عمليات تنفيذ الأجهزة أداة استشعار التقارب.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن أداة استشعار التقارب ولا تُبلغ إلا عن قراءة ثنائية "قريب" أو "بعيد"، يجب أن تستوفي الشروط التالية:

  • [C-1-1] يجب قياس مدى قرب الجسم من الشاشة في الاتجاه نفسه. وهذا يعني أنّه يجب توجيه أداة استشعار التقارب لرصد الأجسام بالقرب من الشاشة، لأنّ الغرض الأساسي من هذا النوع من أدوات الاستشعار هو رصد هاتف يستخدمه المستخدم. إذا كانت عمليات تنفيذ الأجهزة تتضمّن مستشعر قرب مع أي اتجاه آخر، يجب عدم السماح بالوصول إليه من خلال واجهة برمجة التطبيقات هذه.
  • [C-1-2] يجب أن يكون دقيقًا بدرجة بت واحد أو أكثر.
  • [C-1-3] يجب استخدام 0 سنتيمتر كقراءة قريبة و5 سنتيمترات كقراءة بعيدة.
  • [C-1-4] يجب أن يُبلغ عن الحد الأقصى للنطاق ودرجة الدقة 5.

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/g على الأقل.
    • يجب أن يكون الحد الأدنى لعدد مرات القياس 12.5 هرتز أو أقل.
    • يجب أن يكون الحد الأقصى لعدد مرات القياس 400 هرتز أو أعلى، ويجب أن يكون متوافقًا مع SensorDirectChannel RATE_VERY_FAST.
    • يجب أن يكون التشويش في القياس أقل من 400 ميكروغرام/√هرتز.
    • يجب استخدام شكل غير مُشغِّل لهذا المستشعر مع ميزة معالجة مؤقتة لأحداث المستشعر التي لا تقل عن 3000 حدث.
    • يجب أن يكون استهلاك الطاقة في وضع "المعالجة المجمّعة" لا يزيد عن 3 ملي واط.
    • [C-SR-1] يُنصح بشدة بتوفير نطاق قياس 3 ديسيبل لا يقل عن% 80 من تردد Nyquist، ويجب أن يكون نطاق الضوضاء البيضاء ضمن هذا النطاق.
    • يجب أن يكون هناك انحراف عشوائي للتسارع أقل من 30 μg √Hz تم اختباره عند درجة حرارة الغرفة.
    • من المفترض أن يكون هناك تغيير في الانحياز مقابل درجة الحرارة بمقدار 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-2] يُنصح بشدة بتوفير نطاق قياس 3 ديسيبل لا يقل عن% 80 من تردد Nyquist، ويجب أن يكون نطاق قياس الضوضاء البيضاء ضمن هذا النطاق.
    • يجب أن يكون معدل التنقّل العشوائي أقل من 0.001 درجة/ثانية √هرتز عند اختباره في درجة حرارة الغرفة.
    • يجب أن يكون هناك تغيير في الانحياز مقارنةً بدرجة الحرارة بمقدار ‎0.05 درجة / ثانية / درجة مئوية كحد أقصى أو أدنى.
    • يجب أن يكون هناك تغيير في الحساسية مقارنةً بدرجة الحرارة بمقدار 0.02% / درجة مئوية كحد أقصى.
    • يجب أن يكون الخط الأنسب غير خطي بنسبة لا تزيد عن %0.2.
    • يجب أن تكون كثافة الضوضاء ≤ 0.007 درجة/ثانية/√هرتز.
    • يجب أن يكون خطأ المعايرة أقل من 0.002 راد/ثانية في نطاق درجة الحرارة من 10 إلى 40 درجة مئوية عندما يكون الجهاز ثابتًا.
    • يجب أن تكون حساسية التسارع أقل من 0.1 درجة في الثانية لكل متر في الثانية.
    • يجب أن تكون الحساسية على جميع المحاور أقل من % 4.0 وأن يكون التباين في الحساسية على جميع المحاور أقل من% 0.3 في نطاق درجة حرارة تشغيل الجهاز.
  • [C-2-4] يجب أن يتضمّن TYPE_GYROSCOPE_UNCALIBRATED متطلبات الجودة نفسها التي يتضمّنها TYPE_GYROSCOPE.

  • [C-2-5] يجب أن يكون الجهاز مزوّدًا بمستشعر TYPE_GEOMAGNETIC_FIELD يستوفي الشروط التالية:

    • يجب أن يكون نطاق القياس بين -900 و+900 μT على الأقل.
    • يجب أن يكون دقة القياس 5 LSB/uT على الأقل.
    • يجب أن يكون الحد الأدنى لعدد مرات القياس 5 هرتز أو أقل.
    • يجب أن يكون الحد الأقصى لعدد مرات القياس 50 هرتز أو أعلى.
    • يجب أن يكون التشويش في القياس أقل من 0.5 ميكرو تسلا.
  • [C-2-6] يجب أن يتضمّن TYPE_MAGNETIC_FIELD_UNCALIBRATED متطلبات الجودة نفسها التي يتضمّنها TYPE_GEOMAGNETIC_FIELD، بالإضافة إلى ما يلي:

    • يجب استخدام شكل غير مُشغِّل لهذا المستشعر مع ميزة معالجة مؤقتة لأحداث المستشعر التي لا تقل عن 600 حدث.
    • [C-SR-3] يُنصح بشدة بتوفير نطاق للضوضاء البيضاء من 1 هرتز إلى 10 هرتز على الأقل عندما يكون معدّل الإبلاغ 50 هرتز أو أعلى.
  • [C-2-7] يجب أن يتضمّن جهاز TYPE_PRESSURE أداة استشعار تستوفي الشروط التالية:

    • يجب أن يكون نطاق القياس بين 300 و1100 hPa على الأقل.
    • يجب أن يكون دقة القياس 80 LSB/hPa على الأقل.
    • يجب أن يكون الحد الأدنى لعدد مرات القياس 1 هرتز أو أقل.
    • يجب أن يكون الحد الأقصى لعدد مرات القياس 10 هرتز أو أعلى.
    • يجب أن يكون التشويش في القياس أقل من 2 باسكال/√هرتز.
    • يجب استخدام شكل غير مُشغِّل لهذا المستشعر مع ميزة معالجة مؤقتة تسمح بتسجيل 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 ملي ثانية من بعضها. يجب أن يكون الطابع الزمني للحدث المادي نفسه الذي يُبلغ عنه كل من accelerometer وgyroscope ضمن 0.25 ملي ثانية من بعضهم.

  • [C-2-14] يجب أن تتضمّن الطوابع الزمنية لأحداث جهاز استشعار الدوران قاعدة زمنية مماثلة لقاعدة الوقت في النظام الفرعي للكاميرا ويجب ألا يتجاوز الخطأ ملي ثانية واحدة.

  • [C-2-15] يجب إرسال عيّنات إلى التطبيقات في غضون 5 مللي ثانية من الوقت الذي تتوفّر فيه البيانات على أي من أجهزة الاستشعار البدنية المذكورة أعلاه إلى التطبيق.

  • [C-2-16] يجب ألا يتجاوز استهلاك الطاقة 0.5 ملي واط عندما يكون الجهاز ثابتًا و2.0 ملي واط عندما يكون الجهاز متحركًا عند تفعيل أي مجموعة من أجهزة الاستشعار التالية:

    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS
  • [C-2-17] يجوز أن يتضمّن جهاز التحكّم في السرعة أداة استشعار TYPE_PROXIMITY، ولكن في حال توفّرها، يجب أن توفّر سعة تخزين مؤقت لا تقل عن 100 حدث استشعار.

يُرجى العلم أنّ جميع متطلبات استهلاك الطاقة الواردة في هذا القسم لا تشمل استهلاك الطاقة لمعالج التطبيقات. ويشمل ذلك الطاقة التي يتم سحبها من خلال سلسلة أجهزة الاستشعار بالكامل، أي جهاز الاستشعار وأي دوائر كهربائية داعمة وأي نظام مخصّص لمعالجة بيانات أجهزة الاستشعار وما إلى ذلك.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة استخدام أداة الاستشعار مباشرةً، يجب أن تستوفي ما يلي:

  • [C-3-1] يجب أن يُعلن التطبيق بشكل صحيح عن توفّر أنواع القنوات المباشرة ومستوى تقارير معدلات التحويل المباشرة من خلال واجهتَي برمجة التطبيقات isDirectChannelTypeSupported وgetHighestDirectReportRateLevel.
  • [C-3-2] يجب أن يكون متوافقًا مع نوع واحد على الأقل من نوعَي قناة الاستشعار المباشر لجميع أدوات الاستشعار التي تعلن عن توافقها مع قناة الاستشعار المباشر.
  • يجب أن تتيح أداة الاستشعار إعداد تقارير الأحداث من خلال قناة الاستشعار المباشرة لأداة الاستشعار الأساسية (الصيغة غير المخصّصة للتنشيط) من الأنواع التالية:
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. أجهزة الاستشعار الحيوية

للحصول على معلومات إضافية عن قياس أمان ميزة "فتح الجهاز ببصمة الإصبع"، يُرجى الاطّلاع على مستندات قياس أمان المقاييس الحيوية.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة قفل آمنة، يجب استيفاء الشروط التالية:

  • يجب أن يتضمّن جهاز استشعار حيويًا

يمكن تصنيف أدوات الاستشعار الحيوية على أنّها من الفئة 3 (المعروفة سابقًا باسم قويةالفئة 2 (المعروفة سابقًا باسم ضعيفة)، أو الفئة 1 (المعروفة سابقًا باسم سهلة الاستخدام) استنادًا إلى معدّلات قبول عمليات التزوير والتزييف، وإلى أمان مسار المعالجة المتعلّق بالمقاييس الحيوية. يحدِّد هذا التصنيف إمكانات المستشعر البيومتري للتفاعل مع المنصة وتطبيقات الجهات الخارجية. يجب أن تستوفي أدوات الاستشعار متطلبات إضافية على النحو الموضّح أدناه إذا كانت تريد أن تصنَّف على أنّها الفئة 1 أو الفئة 2 أو الفئة 3. تحصل المقاييس الحيوية من الفئة 2 والفئة 3 على ميزات إضافية كما هو موضح أدناه.

إذا كانت عمليات تنفيذ الأجهزة تتيح أداة استشعار المقاييس الحيوية لتطبيقات تابعة لجهات خارجية من خلال android.hardware.biometrics.BiometricManager، android.hardware.biometrics.BiometricPrompt، وandroid.provider.Settings.ACTION_BIOMETRIC_ENROLL، يجب أن تستوفي التطبيقات المتطلبات التالية:

  • [C-4-1] يجب أن تستوفي المتطلبات المتعلقة بالمقاييس الحيوية من الفئة 3 أو الفئة 2 كما هو محدّد في هذا المستند.
  • [C-4-2] يجب التعرّف على كل اسم مَعلمة محدّد كثابت في فئة المصادقين وأي مجموعات منه والامتثال له. في المقابل، يجب عدم الامتثال أو التعرّف على الثوابت الصحيحة التي يتم تمريرها إلى الأسلوبين canAuthenticate(int) وsetAllowedAuthenticators(int) بخلاف تلك التي تم توثيقها كثوابت عامة في Authenticators وأي مجموعات منها.
  • [C-4-3] يجب تنفيذ الإجراء ACTION_BIOMETRIC_ENROLL على الأجهزة التي تتضمّن مقاييس حيوية من الفئة 3 أو الفئة 2. يجب أن يقدّم هذا الإجراء نقاط دخول التسجيل فقط لتقنيات الفئة 3 أو الفئة 2 البيومترية.

إذا كانت عمليات تنفيذ الأجهزة تتيح استخدام المقاييس الحيوية غير التفاعلية، يجب أن تستوفي الشروط التالية:

  • [C-5-1] يجب أن تتطلّب تلقائيًا خطوة تأكيد إضافية (مثل الضغط على زر).
  • [C-SR-1] يُنصح بشدة بتوفير إعداد للسماح للمستخدمين بتجاوز الإعدادات المفضّلة للتطبيق وفرض خطوة تأكيد مصاحبة دائمًا.
  • [C-SR-2] يُنصح بشدة بتأمين إجراء التأكيد كي لا يتم خداعه من خلال اختراق نظام التشغيل أو نواة النظام. على سبيل المثال، يعني ذلك أنّ إجراء التأكيد المستنِد إلى زرّ مادي يتم توجيهه من خلال دبوس إدخال/إخراج (GPIO) للأغراض العامة المخصّص للإدخال فقط في عنصر آمن (SE) لا يمكن تشغيله بأي وسيلة أخرى غير الضغط على زرّ مادي.
  • [C-5-2] يجب أيضًا تنفيذ عملية مصادقة ضمنية (بدون خطوة تأكيد) تتوافق مع setConfirmationRequired(boolean)، التي يمكن للتطبيقات ضبطها لاستخدامها في عمليات تسجيل الدخول.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن أدوات استشعار متعددة للمقاييس الحيوية، يجب أن تستوفي المتطلبات التالية:

بدء متطلبات جديدة

  • [C-7-1] يجب أيضًا أن يتم قفل جميع المقاييس الحيوية الأخرى من فئة المقاييس الحيوية الأقل أمانًا عندما يكون أحد المقاييس الحيوية محظورًا (أي أنّه تم إيقاف المقاييس الحيوية إلى أن يفتح المستخدم القفل باستخدام المصادقة الأساسية) أو محظورًا لفترة زمنية معيّنة (أي أنّه تم إيقاف المقاييس الحيوية مؤقتًا إلى أن ينتظر المستخدم فاصلاً زمنيًا) بسبب عدد كبير جدًا من المحاولات غير الناجحة. في حال فرض قفل مؤقت، يجب أن يكون وقت الانتظار للمصادقة باستخدام المقاييس الحيوية هو الحد الأقصى لوقت الانتظار لجميع المقاييس الحيوية في القفل المؤقت.

  • [C-SR-12] يُنصح بشدة، عند قفل المقاييس الحيوية (أي يتم إيقاف المقاييس الحيوية إلى أن يفتح المستخدم القفل باستخدام المصادقة الأساسية) أو عند قفل المقاييس الحيوية لفترة زمنية محددة (أي يتم إيقاف المقاييس الحيوية مؤقتًا إلى أن ينتظر المستخدم فاصلاً زمنيًا) بسبب عدد كبير جدًا من المحاولات غير الناجحة، بأن يتم أيضًا قفل جميع المقاييس الحيوية الأخرى من فئة المقاييس الحيوية نفسها. في حال تطبيق قفل مؤقت مرتبط بوقت معيّن، يُنصح بشدة بأن يكون وقت الانتظار للمصادقة باستخدام المقاييس الحيوية هو الحد الأقصى لوقت الانتظار لجميع المقاييس الحيوية في حالة القفل المؤقت المرتبط بوقت معيّن.

  • [C-7-2] يجب أن يطلب الجهاز من المستخدم المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) لإعادة ضبط مقياس عدد عمليات القفل المتعلّقة بالمقياس الحيوي الذي تم حظره. قد يُسمح للمقاييس الحيوية من الفئة 3 بإعادة ضبط عداد عمليات القفل لمقاييس حيوية مقفلة من الفئة نفسها أو فئة أدنى. يجب عدم السماح للمقاييس الحيوية من الفئة 2 أو الفئة 1 بإكمال عملية إعادة ضبط ميزة قفل الشاشة لأي مقاييس حيوية.

إنهاء المتطلبات الجديدة

  • [C-SR-3] يُنصح بشدة بطلب تأكيد مقياس حيوي واحد فقط لكل عملية مصادقة (على سبيل المثال، إذا كانت أداتا استشعار بصمة الإصبع والوجه متوفرة على الجهاز، يجب إرسال onAuthenticationSucceeded بعد تأكيد أيٍّ منهما).

لكي تسمح عمليات تنفيذ الأجهزة بالوصول إلى مفاتيح ملف تخزين المفاتيح لتطبيقات تابعة لجهات خارجية، يجب أن تستوفي الشروط التالية:

  • [C-6-1] يجب أن تستوفي المتطلبات الخاصة بالفئة 3 على النحو المحدّد في هذا القسم أدناه.
  • [C-6-2] يجب تقديم المقاييس الحيوية من الفئة 3 فقط عندما تتطلّب المصادقة BIOMETRIC_STRONG، أو يتمّ استدعاء المصادقة باستخدام CryptoObject.

إذا أرادت عمليات تنفيذ الأجهزة التعامل مع أداة استشعار المقاييس الحيوية على أنّها من الفئة 1 (المعروفة سابقًا باسم الراحة)، يجب أن تستوفي المتطلبات التالية:

  • [C-1-1] يجب أن يكون معدّل القبول الخاطئ أقل من 0.002%.
  • [C-1-2] يجب الإفصاح عن أنّ هذا الوضع قد يكون أقل أمانًا من استخدام رقم تعريف شخصي أو نقش أو كلمة مرور قويَين، ويجب سرد مخاطر تفعيله بوضوح، إذا كانت معدلات قبول عمليات التزوير والتصيّد الاحتيالي أعلى من% 7 وفقًا لما يتم قياسه في بروتوكولات اختبار المقاييس الحيوية في Android.
  • [C-1-9] يجب أن يطلب الجهاز من المستخدم إجراء المصادقة الأساسية المُقترَحة (مثل رقم التعريف الشخصي أو النمط أو كلمة المرور) بعد إجراء عشرين محاولة غير ناجحة كحد أقصى وبفاصل زمني لا يقل عن تسعين ثانية لإجراء عملية التحقّق من المقاييس الحيوية، حيث تكون المحاولة غير الناجحة هي محاولة ذات جودة تسجيل مناسبة (BIOMETRIC_ACQUIRED_GOOD) لا تتطابق مع المقاييس الحيوية المسجَّلة.
  • [C-SR-4] يُنصح بشدة بخفض إجمالي عدد التجارب الخاطئة لإثبات الهوية بالاستناد إلى المقاييس الحيوية المحدّدة في [C-1-9] إذا كانت معدّلات قبول المحاكاة والتزوير أعلى من% 7 وفقًا لبروتوكولات اختبار المقاييس الحيوية في Android.
  • [C-1-3] يجب تحديد عدد المحاولات المسموح به لإجراء عملية إثبات الهوية باستخدام المقاييس الحيوية، حيث تكون المحاولة خاطئة إذا كانت جودة التسجيل مناسبة (BIOMETRIC_ACQUIRED_GOOD) ولا تتطابق مع المقاييس الحيوية المسجَّلة.
  • [C-SR-5] يُنصح بشدة بتحديد عدد المحاولات في الدقيقة لمدة 30 ثانية على الأقل بعد خمس محاولات خاطئة للتحقّق من المقاييس الحيوية للوصول إلى الحد الأقصى لعدد المحاولات الخاطئة وفقًا لما هو موضّح في [C-1-9]، حيث تكون المحاولة الخاطئة هي التي تتسم بجودة تسجيل مناسبة (BIOMETRIC_ACQUIRED_GOOD) ولا تتطابق مع مقياس حيوي مسجَّل.
  • [C-SR-6] يُنصح بشدة بتضمين كل منطق الحدّ من معدّل نقل البيانات في TEE.
  • [C-1-10] يجب إيقاف المقاييس الحيوية بعد بدء المدة الزمنية الإضافية للمصادقة الأساسية للمرة الأولى على النحو الموضّح في [C-0-2] من القسم 9.11.

  • [C-1-11] يجب أن يكون معدّل قبول المحاكاة والتزوير أقل من %30، مع (1) معدّل قبول المحاكاة والتزوير لأنواع أدوات هجمات عرض المستوى (PAI) من الفئة (أ) أقل من %30، و(2) معدّل قبول المحاكاة والتزوير لأنواع أدوات هجمات عرض المستوى (PAI) من الفئة (ب) أقل من %40، كما هو مُقاس من خلال بروتوكولات اختبار المقاييس الحيوية في Android.

  • [C-1-4] يجب منع إضافة مقاييس حيوية جديدة بدون إنشاء سلسلسة ثقة أولاً من خلال مطالبة المستخدم بتأكيد بيانات اعتماد الجهاز الحالية أو إضافة بيانات اعتماد جديدة (رقم التعريف الشخصي أو النمط أو كلمة المرور) التي تم تأمينها من خلال TEE، ويوفر تنفيذ مشروع Android Open sourced في إطار العمل آلية للقيام بذلك.

  • [C-1-5] يجب إزالة جميع البيانات البيومترية القابلة للتحديد الخاصة بالمستخدم بالكامل عند إزالة حساب المستخدم (بما في ذلك من خلال إعادة الضبط على الإعدادات الأصلية).

  • [C-1-6] يجب الالتزام بالعلامة الفردية للمقياس الحيوي (أي DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT أو DevicePolicymanager.KEYGUARD_DISABLE_FACE أو DevicePolicymanager.KEYGUARD_DISABLE_IRIS ).

  • [C-1-7] يجب أن يطلب التطبيق من المستخدم المصادقة الأساسية المُقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) مرة واحدة كل 24 ساعة أو أقل. ملاحظة: عند ترقية الأجهزة التي تعمل بالإصدار 9 من Android أو الإصدارات الأقدم، يجب أن تطلب من المستخدم مصادقة أساسية مقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) مرة واحدة كل 72 ساعة أو أقل.

  • [C-1-8] يجب أن يطلب التطبيق من المستخدم إدخال مصادقة أساسية مقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) أو مصادقة حيوية من الفئة 3 (قوية) بعد حدوث أحد الإجراءَين التاليَين:

    • مهلة عدم النشاط لمدة 4 ساعات
    • 3 محاولات مصادقة بالمقاييس الحيوية غير ناجحة
    • تتم إعادة ضبط فترة الانتظار في حالة عدم النشاط وعدد عمليات المصادقة غير الناجحة بعد أي تأكيد ناجح لبيانات اعتماد الجهاز. ملاحظة: قد يتم استثناء ترقية الأجهزة التي تم إطلاقها باستخدام الإصدار 9 من Android أو الإصدارات الأقدم من C-1-8.
  • [C-SR-7] يُنصح بشدة باستخدام المنطق في إطار العمل الذي يوفّره مشروع Android Open Source لفرض القيود المحدّدة في [C-1-7] و[C-1-8] للأجهزة الجديدة.

  • [C-SR-8] يُنصح بشدة بأن يكون معدّل الرفض الخاطئ أقل من 10%، كما يتم قياسه على الجهاز.

  • [C-SR-9] يُنصح بشدة بخفض وقت الاستجابة إلى أقل من ثانية واحدة، ويتم قياسه من وقت رصد المقياس الحيوي إلى وقت فتح قفل الشاشة لكل مقياس حيوي مسجَّل.

بدء متطلبات جديدة

  • [C-1-12] يجب ألا يزيد معدّل قبول عمليات التزوير والتصيّد الاحتيالي عن %40 لكل نوع من أدوات هجمات المحاكاة، وذلك وفقًا لما يتم قياسه في بروتوكولات اختبار المقاييس الحيوية في Android.

  • [C-SR-13] يُنصح بشدة بأن يكون معدّل قبول المحاكاة والتزوير لا يزيد عن% 30 لكل نوع من أدوات هجمات المحاكاة (PAI)، كما يتم قياسه من خلال بروتوكولات اختبار المقاييس الحيوية في Android.

  • [C-SR-14] يُنصح بشدة بالكشف عن فئة المقاييس الحيوية لجهاز قياس المقاييس الحيوية والمخاطر المرتبطة بتفعيله.

  • [C-SR-17] ننصح بشدة بتنفيذ واجهات AIDL الجديدة (مثل IFace.aidl وIFingerprint.aidl).

إنهاء المتطلبات الجديدة

إذا أرادت عمليات تنفيذ الأجهزة التعامل مع أداة استشعار المقاييس الحيوية على أنّها من الفئة 2 (المعروفة سابقًا باسم ضعيفة)، يجب أن تستوفي ما يلي:

  • [C-2-1] يجب استيفاء جميع متطلبات الفئة 1 أعلاه.

  • [C-2-2] يجب أن يكون معدّل قبول المحاكاة والتزوير أقل من %20، مع (1) معدّل قبول المحاكاة والتزوير لأنواع أدوات هجمات المحاكاة (PAI) من المستوى "أ" أقل من %20، و(2) معدّل قبول المحاكاة والتزوير لأنواع أدوات هجمات المحاكاة (PAI) من المستوى "ب" أقل من %30، وفقًا لما يتم قياسه في بروتوكولات اختبار المقاييس الحيوية في Android.

بدء متطلبات جديدة

إنهاء المتطلبات الجديدة

  • [C-2-3] يجب تنفيذ عملية مطابقة المقاييس الحيوية في بيئة تنفيذ معزولة خارج مساحة مستخدم Android أو مساحة نظام التشغيل، مثل بيئة التنفيذ الموثوقة (TEE)، أو على شريحة تتضمّن قناة آمنة تؤدي إلى بيئة التنفيذ المعزولة أو على جهاز افتراضي محمي يستوفي المتطلبات الواردة في القسم 9.17.
  • [C-2-4] يجب أن تكون جميع البيانات التعريفية مشفَّرة ومصادق عليها cryptographically بحيث لا يمكن الحصول عليها أو قراءتها أو تغييرها خارج بيئة التنفيذ المعزولة أو شريحة تتضمّن قناة آمنة تؤدي إلى بيئة التنفيذ المعزولة كما هو موضّح في إرشادات التنفيذ على الموقع الإلكتروني لمشروع Android Open Source Project أو آلة افتراضية محمية يتحكّم فيها نظام التشغيل الظاهري وتستوفي المتطلبات الواردة في القسم 9.17.
  • [C-2-5] بالنسبة إلى المقاييس الحيوية المستندة إلى الكاميرا، أثناء المصادقة أو التسجيل المستندَين إلى المقاييس الحيوية:
    • يجب تشغيل الكاميرا في وضع يمنع قراءة إطارات الكاميرا أو تعديلها خارج بيئة التنفيذ المعزول أو شريحة تتضمّن قناة آمنة تؤدي إلى بيئة التنفيذ المعزول أو جهاز افتراضي محمي يتحكّم فيه نظام التشغيل الظاهري ويستوفي المتطلبات الواردة في القسم 9.17.
    • بالنسبة إلى حلول الكاميرا الواحدة ذات الإضاءة الملوّنة (RGB)، يمكن قراءة إطارات الكاميرا خارج بيئة التنفيذ المعزولة لدعم العمليات، مثل المعاينة للتسجيل، ولكن يجب ألّا تكون قابلة للتغيير.
  • [C-2-6] يجب عدم السماح للتطبيقات التابعة لجهات خارجية بالتمييز بين عمليات التسجيل البيومتري الفردية.
  • [C-2-7] يجب عدم السماح بالوصول غير المشفَّر إلى البيانات الحيوية القابلة للتحديد أو أي بيانات مشتقة منها (مثل البيانات المضمَّنة) إلى "معالج التطبيقات" خارج سياق "بيئة التنفيذ الموثوقة" أو "الجهاز الافتراضي المحمي" الذي يتحكّم فيه "برنامج التشغيل الظاهري" ويستوفي المتطلبات الواردة في "الفقرة 9.17". لا يتم استثناء الأجهزة التي تم ترقيتها من الإصدار 9 من نظام التشغيل Android أو الإصدارات الأقدم من C-2-7.
  • [C-2-8] يجب أن يتضمّن مسار معالجة آمنًا بحيث لا تؤدي عملية اختراق لنظام التشغيل أو kernel إلى السماح بإدخال البيانات مباشرةً لإجراء مصادقة زائفة على أنّه المستخدم. ملاحظة: إذا سبق أن تم إطلاق عمليات تنفيذ الأجهزة على الإصدار 9 أو إصدار أقدم من نظام التشغيل Android وتعذّر استيفاء الشرط C-2-8 من خلال تحديث لبرنامج النظام ، قد يتم إعفاؤها من الشرط.

  • [C-SR-10] يُنصح بشدة بتضمين ميزة "التحقق من صحة التفاعل" لجميع الوضعيات المقاييس الحيوية وميزة "التعرّف على الانتباه" للمقاييس الحيوية للوجه.

  • [C-2-9] يجب إتاحة أداة الاستشعار الحيوية للتطبيقات التابعة لجهات خارجية.

إذا أرادت عمليات تنفيذ الأجهزة التعامل مع أداة استشعار المقاييس الحيوية على أنّها من الفئة 3 (المعروفة سابقًا باسم قوية)، يجب أن تستوفي المتطلبات التالية:

  • يجب أن يستوفي [C-3-1] جميع متطلبات الفئة 2 أعلاه، باستثناء [C-1-7] و[C-1-8].
  • [C-3-2] يجب أن يكون هناك تطبيق لمستودع مفاتيح مستند إلى الأجهزة.
  • [C-3-3] يجب ألا يزيد معدّل قبول عمليات التزوير والتصيّد الاحتيالي عن %7، مع (1) عدم تجاوز معدّل قبول عمليات التزوير والتصيّد الاحتيالي لأنواع أدوات هجمات المحاكاة (PAI) من المستوى A %7، (2) عدم تجاوز معدّل قبول عمليات التزوير والتصيّد الاحتيالي لأنواع أدوات هجمات المحاكاة (PAI) من المستوى B %20، وفقًا لما يتم قياسه في بروتوكولات اختبار المقاييس الحيوية في Android.
  • [C-3-4] يجب أن يطلب الجهاز من المستخدم إدخال مصادقة أساسية مقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) مرة واحدة كل 72 ساعة أو أقل.
  • [C-3-5] يجب إعادة إنشاء معرّف المصادقة لجميع ميزات المقاييس الحيوية من الفئة 3 المتوافقة على الجهاز في حال إعادة تسجيل أي منها.
  • [C-3-6] يجب تفعيل مفاتيح ملف تخزين المفاتيح المستندة إلى المقاييس الحيوية لتطبيقات الجهات الخارجية.

بدء متطلبات جديدة

إنهاء المتطلبات الجديدة

إذا كانت عمليات تنفيذ الأجهزة تحتوي على أداة استشعار بصمة الإصبع تحت الشاشة (UDFPS)، يجب مراعاة ما يلي:

  • [C-SR-11] يُنصح بشدة بمنع المنطقة القابلة للمس في UDFPS من التدخل في التنقّل باستخدام 3 أزرار (الذي قد يحتاجه بعض المستخدمين لأغراض تسهيل الاستخدام).

7.3.11. أداة استشعار الوضعية

عمليات التنفيذ على الأجهزة:

  • قد تتيح استخدام أداة استشعار الوضع بـ 6 درجات من الحرية.

إذا كانت عمليات تنفيذ الأجهزة تتيح استخدام أداة استشعار الوضع بـ 6 درجات من الحرية، يجب استيفاء الشروط التالية:

  • [C-1-1] يجب تنفيذ TYPE_POSE_6DOF جهاز الاستشعار والإبلاغ عنه.
  • [C-1-2] يجب أن تكون أكثر دقة من متجه الدوران وحده.

7.3.12. أداة استشعار زاوية المفصل

إذا كانت عمليات تنفيذ الأجهزة تتيح استخدام أداة استشعار زاوية المفصل، يجب أن تستوفي الشروط التالية:

7.3.13. IEEE 802.1.15.4 (النطاق الفائق العرض)

إذا كانت عمليات تنفيذ الأجهزة تتضمّن توافقًا مع معيار 802.1.15.4 وتعرض الوظيفة لتطبيق تابع لجهة خارجية، يجب استيفاء الشروط التالية:

بدء متطلبات جديدة

  • [C-1-2] يجب الإبلاغ عن علامة ميزة الجهاز android.hardware.uwb.
  • [C-1-3] يجب أن تتوافق مع جميع مجموعات الإعدادات التالية (مجموعات مُحدَّدة مسبقًا لمَعلمات FIRA UCI) المحدَّدة في عملية تنفيذ AOSP.
    • CONFIG_ID_1: قياس المسافة عبر بث STATIC STS DS-TWR أحادي الوجهة تحدّده جمعية FiRa، الوضع المؤجّل، الفاصل الزمني لقياس المسافة 240 ملي ثانية
    • CONFIG_ID_2: قياس المسافة من جهاز إلى عدة أجهزة STATIC STS DS-TWR وفقًا لمعيار FiRa، الوضع المؤجل، الفاصل الزمني لقياس المسافة 200 ملي ثانية. حالة الاستخدام المعتادة: هاتف ذكي يتفاعل مع العديد من الأجهزة الذكية.
    • CONFIG_ID_3: الإجراء نفسه المُتّبع في CONFIG_ID_1، باستثناء أنّه لا يتم تسجيل بيانات ∡ زاوية الوصول (AoA).
    • CONFIG_ID_4: القيمة نفسها المُستخدَمة في CONFIG_ID_1، باستثناء أنّه تم تفعيل وضع أمان P-STS.
    • CONFIG_ID_5: القيمة نفسها المُستخدَمة في CONFIG_ID_2، باستثناء أنّه تم تفعيل وضع أمان P-STS.
    • CONFIG_ID_6: القيمة نفسها المُستخدَمة في CONFIG_ID_3، باستثناء أنّه تم تفعيل وضع أمان P-STS.
    • CONFIG_ID_7: يشبه CONFIG_ID_2، باستثناء أنّه تم تفعيل وضع مفتاح التحكّم الفردي في P-STS.
  • [C-1-4] يجب توفير عنصر تحكم للمستخدم للسماح له بتفعيل/إيقاف تكنولوجيا UWB الراديو.
  • [C-1-5] يجب فرض أن تحصل التطبيقات التي تستخدم شبكة UWB اللاسلكية على إذن UWB_RANGING (ضمن مجموعة أذونات NEARBY_DEVICES).

يساعد اجتياز اختبارات الامتثال والاعتماد ذات الصلة التي تحدّدها منظمات المعايير، بما في ذلك FIRA وCCC وCSA، في ضمان عمل معيار 802.1.15.4 بشكل صحيح.

إنهاء المتطلبات الجديدة

7.4. إمكانية الوصول إلى البيانات

7.4.1. الاتصالات الهاتفية

يشير مصطلح "الهاتف" كما تستخدمه واجهات برمجة تطبيقات Android وهذا المستند تحديدًا إلى الأجهزة ذات الصلة بإجراء المكالمات الصوتية وإرسال الرسائل القصيرة أو إعداد بيانات الجوّال عبر شبكة الجوّال (مثل GSM أو CDMA أو LTE أو NR). يمكن للجهاز المتوافق مع "الاتصال الهاتفي" اختيار تقديم بعض خدمات المكالمات والمراسلة والبيانات أو جميعها بما يتناسب مع المنتج.

عبر شبكة GSM أو CDMA على الرغم من أنّ هذه المكالمات الصوتية قد تكون أو لا تكون مُدارة عبر تبديل الحِزم، إلا أنّها تُعتبر لأغراض Android مستقلة عن أي اتصال بيانات قد يتم تنفيذه باستخدام الشبكة نفسها. بعبارة أخرى، تشير وظائف "الهاتف" وواجهات برمجة التطبيقات في Android تحديدًا إلى المكالمات الصوتية والرسائل القصيرة. على سبيل المثال، لا تُعدّ عمليات تنفيذ الأجهزة التي لا يمكنها إجراء مكالمات أو إرسال رسائل SMS أو تلقّيها أجهزة اتصال هاتفي، بغض النظر عمّا إذا كانت تستخدم شبكة جوّالًا للاتصال بالبيانات.

  • يجوز استخدام Android على الأجهزة التي لا تتضمّن أجهزة اتصال هاتفي. وهذا يعني أنّ نظام Android متوافق مع الأجهزة غير الهواتف.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن خدمات الهاتف الجوّال GSM أو CDMA، يجب استيفاء الشروط التالية:

  • [C-1-1] يجب الإفصاح عن علامة ميزة android.hardware.telephony وغيرها من علامات الميزات الفرعية وفقًا للتكنولوجيا.
  • [C-1-2] يجب توفير دعم كامل لواجهة برمجة التطبيقات لهذه التكنولوجيا.
  • يجب أن يسمح بالاتصال بجميع أنواع خدمات الجوّال المتاحة (الجيل الثاني والثالث والرابع والخامس وما إلى ذلك) أثناء المكالمات في حالات الطوارئ (بغض النظر عن أنواع الشبكات التي تم ضبطها من قِبل SetAllowedNetworkTypeBitmap()).

إذا لم تتضمّن عمليات تنفيذ الأجهزة أجهزة اتصال هاتفي، يجب استيفاء الشروط التالية:

  • [C-2-1] يجب تنفيذ واجهات برمجة التطبيقات الكاملة كعمليات لا تتطلّب تدخلًا.

إذا كانت عمليات تنفيذ الأجهزة متوافقة مع شرائح eUICC أو شرائح eSIM/شرائح SIM المضمّنة وتتضمن آلية خاصة بحقوق الملكية لتوفير وظائف شرائح eSIM لمطوّري التطبيقات التابعين لجهات خارجية، يجب أن:

إذا لم تضبط عمليات تنفيذ الأجهزة سمة النظام ro.telephony.iwlan\_operation\_mode على "قديم"، فإنّها:

إذا كانت عمليات تنفيذ الأجهزة تتيح تسجيلًا واحدًا لنظام IP Multimedia Subsystem (IMS) لكل من خدمة الهاتف الجوّال للوسائط المتعددة (MMTEL) وميزات خدمة الاتصالات التفاعلية (RCS) ومن المتوقّع أن تمتثل لمتطلبات مشغّل شبكة الجوّال في ما يتعلّق باستخدام تسجيل واحد لنظام IMS لجميع عمليات إرسال الإشارات في IMS، يجب أن تستوفي الأجهزة المتطلبات التالية:

إذا أبلغت عمليات تنفيذ الأجهزة عن ميزة android.hardware.telephony، ينطبق ما يلي:

إذا كانت عمليات تنفيذ الأجهزة تُبلغ عن ميزة android.hardware.telephony وتوفّر شريط حالة النظام، يجب اتّباع الخطوات التالية:

  • [C-7-1] يجب اختيار اشتراك نشط تمثيلي لمعرّف UUID للمجموعة معيّن بهدف عرضه للمستخدم في أي ميزات تقدّم معلومات عن حالة شريحة SIM. وتشمل الأمثلة على هذه العناصر رمز إشارة شبكة الجوّال في شريط الحالة أو مربّع الإعدادات السريعة.
  • [C-SR-1] يُنصح بشدة بأن يكون اشتراك الممثِّل هو اشتراك البيانات النشط ما لم يكن الجهاز في مكالمة صوتية، وفي هذه الحالة يُنصح بشدة بأن يكون اشتراك الممثِّل هو اشتراك البيانات النشط.

إذا أبلغت عمليات تنفيذ الأجهزة عن ميزة android.hardware.telephony، ينطبق ما يلي:

  • [C-6-7] يجب أن يكون الجهاز قادرًا على فتح الحد الأقصى لعدد القنوات المنطقية (20 قناة في المجمل) لكل شريحة UICC واستخدامها بشكل متزامن وفقًا لمعيار ETSI TS 102 221.
  • [C-6-8] يجب عدم تطبيق أي من السلوكيات التالية على تطبيقات مشغّلي شبكات الجوّال النشطين (على النحو المحدّد من قِبل TelephonyManager#getCarrierServicePackageName) تلقائيًا أو بدون تأكيد صريح من المستخدم:
    • إبطال إذن الوصول إلى الشبكة أو تقييده
    • إبطال الأذونات
    • تقييد تنفيذ التطبيقات في المقدّمة أو الخلفية خارج نطاق ميزات إدارة الطاقة الحالية المضمّنة في AOSP
    • إيقاف التطبيق أو إلغاء تثبيته

إذا أبلغت عمليات تنفيذ الأجهزة عن ميزة android.hardware.telephony و تم إيقاف جميع الاشتراكات النشطة، غير المخصّصة للأجهزة الجوّالة التي تشترك في معرّف UUID للمجموعة، أو تمّت إزالتها من الجهاز أو وضع علامة عليها بأنّها مخصّصة للأجهزة الجوّالة، اتّبع الجهاز الخطوات التالية:

  • [C-8-1] يجب إيقاف جميع الاشتراكات الانتهازية النشطة المتبقية في المجموعة نفسها تلقائيًا.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن خدمات اتصال GSM ولكنّها لا تتضمّن خدمات اتصال CDMA، يجب استيفاء الشروط التالية:

  • [C-9-1] يجب عدم الإفصاح عن PackageManager#FEATURE_TELEPHONY_CDMA.
  • [C-9-2] يجب أن يُرسِل الجهاز IllegalArgumentException عند محاولات ضبط أي أنواع شبكات 3GPP2 في أقنعة بت لأنواع الشبكات المفضّلة أو المسموح بها.
  • [C-9-3] يجب أن تعرض سلسلة فارغة من TelephonyManager#getMeid.

إذا كانت عمليات تنفيذ الأجهزة تتيح استخدام شرائح eUICC التي تتضمّن منافذ وملفات شخصية متعددة، يجب أن تستوفي المتطلبات التالية:

7.4.1.1. توافق حظر الأرقام

إذا أبلغت عمليات تنفيذ الأجهزة عن ميزة android.hardware.telephony.calling، يعني ذلك أنّها:

  • [C-1-1] يجب أن تتضمّن ميزة حظر الأرقام
  • [C-1-2] يجب تنفيذ BlockedNumberContract وواجهة برمجة التطبيقات المقابلة لها بالكامل على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK).
  • [C-1-3] يجب حظر جميع المكالمات والرسائل الواردة من رقم هاتف في ملف "موفِّر الأرقام المحظورة" بدون أي تفاعل مع التطبيقات. ويتمثل الاستثناء الوحيد في رفع حظر الأرقام مؤقتًا كما هو موضّح في مستندات SDK.

  • [C-1-4] يجب إرسال رسالة إلى مقدّم خدمة سجلّ المكالمات على المنصة بشأن المكالمة المحظورة، ويجب فلترة المكالمات التي تتضمّن BLOCKED_TYPE من عرض سجلّ المكالمات التلقائي في تطبيق برنامج الاتصال المثبَّت مسبقًا.

  • [C-1-5] يجب عدم الكتابة إلى مقدّم خدمة الاتصال الهاتفي بشأن رسالة محظورة.

  • [C-1-6] يجب تنفيذ واجهة مستخدم لإدارة الأرقام المحظورة، والتي يتم فتحها باستخدام النية التي تعرضها طريقة TelecomManager.createManageBlockedNumbersIntent().

  • [C-1-7] يجب عدم السماح للمستخدمين الثانويين بالاطّلاع على الأرقام المحظورة أو تعديلها على الجهاز لأنّ نظام Android يفترض أنّ المستخدم الأساسي لديه إمكانية التحكّم الكامل في خدمات الهاتف، وهي نسخة واحدة على الجهاز. يجب أن تكون كل واجهة مستخدم مرتبطة بحظر المحتوى مخفية للمستخدمين الثانويين، ويجب أن تظل القائمة المحظورة مفعّلة.

  • من المفترض نقل الأرقام المحظورة إلى مقدّم الخدمة عند تحديث أحد الأجهزة إلى Android 7.0.

  • يجب أن يقدّم التطبيق ميزة للمستخدم لعرض المكالمات المحظورة في تطبيق DIALER المثبَّت مسبقًا.

7.4.1.2. Telecom API

إذا أبلغت عمليات تنفيذ الأجهزة عن android.hardware.telephony.calling، يعني ذلك ما يلي:

  • [C-1-1] يجب أن تتوافق مع واجهات برمجة تطبيقات ConnectionService الموضّحة في حزمة تطوير البرامج (SDK).
  • [C-1-2] يجب عرض مكالمة واردة جديدة وتوفير إمكانات للمستخدم لقبول المكالمة الواردة أو رفضها عندما يكون المستخدم في مكالمة جارية يجريها تطبيق تابع لجهة خارجية لا يتيح ميزة الانتظار المحدَّدة من خلال CAPABILITY_SUPPORT_HOLD.
  • [C-1-3] يجب أن يتضمّن التطبيق فئة برمجة التطبيقات InCallService.
  • [C-SR-1] يُنصح بشدة بإعلام المستخدم بأنّ الردّ على مكالمة واردة سيؤدي إلى إنهاء مكالمة حالية.

    يستوفي تنفيذ AOSP هذه المتطلبات من خلال إشعار تنبيه يشير إلى المستخدم بأنّ الردّ على مكالمة واردة سيؤدي إلى إنهاء المكالمة الأخرى.

  • [C-SR-2] يُنصح بشدة بتثبيت تطبيق الاتصال التلقائي الذي يعرض إدخال سجلّ المكالمات واسم تطبيق تابع لجهة خارجية في سجلّ المكالمات عند ضبط التطبيق التابع لجهة خارجية لمفتاح EXTRA_LOG_SELF_MANAGED_CALLS الإضافات على PhoneAccount إلى true.

  • [C-SR-3] يُنصح بشدة بمعالجة حدثَي KEYCODE_MEDIA_PLAY_PAUSE وKEYCODE_HEADSETHOOK لسماعات الرأس الصوتية في واجهات برمجة التطبيقات android.telecom على النحو التالي:

    • اتصل بالرقم Connection.onDisconnect() عند رصد ضغطة قصيرة على الحدث الرئيسي أثناء مكالمة جارية.
    • اتصل بالرقم Connection.onAnswer() عند رصد ضغطة قصيرة على الحدث الرئيسي أثناء مكالمة واردة.
    • اتصل بالرقم Connection.onReject() عند رصد الضغط مع الاستمرار على الحدث الرئيسي أثناء مكالمة واردة.
    • فعِّل أو أوقِف ميزة كتم الصوت في CallAudioState.
7.4.1.3. نقل بيانات رسالة التحقّق من الاتصال في بروتوكول NAT-T على شبكة الجوّال

عمليات التنفيذ على الأجهزة:

  • يجب أن يتضمّن ذلك إمكانية إيقاف خدمة "إبقاء الاتصال بالإنترنت" على شبكة الجوّال.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة ميزة "إبقاء الاتصال بالإنترنت" على شبكة الجوّال و تتيح هذه الميزة للتطبيقات التابعة لجهات خارجية، يجب استيفاء الشروط التالية:

  • [C-1-1] يجب أن تكون متوافقة مع واجهة برمجة التطبيقات SocketKeepAlive API.
  • [C-1-2] يجب أن تتيح فتحة واحدة على الأقل للاحتفاظ بحالة الاتصال في الوقت الفعلي بشكل متزامن عبر شبكة الجوّال.
  • [C-1-3] يجب أن تتيح أكبر عدد ممكن من خانات keepalive الخلوية المتزامنة التي يسمح بها واجهة HAL لجهاز الراديو الخلوي.
  • [C-SR-1] يُنصح بشدة بتوفير ثلاث خانات على الأقل للحفاظ على الاتصال الخلوي لكل مثيل من جهاز البث.

إذا لم تتضمّن عمليات تنفيذ الأجهزة ميزة تفريغ عمليات الاحتفاظ بالاتصال الخلوي، يحدث ما يلي:

  • [C-2-1] يجب عرض ERROR_UNSUPPORTED.

7.4.2. معيار IEEE 802.11 (لشبكات Wi-Fi)

عمليات التنفيذ على الأجهزة:

  • يجب أن تتضمّن إتاحة استخدام شكل واحد أو أكثر من 802.11.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة 802.11 وتعرض الوظيفة لتطبيق تابع لجهة خارجية، يجب استيفاء الشروط التالية:

  • [C-1-1] يجب تنفيذ واجهة برمجة تطبيقات Android المقابلة.
  • [C-1-2] يجب الإبلاغ عن علامة ميزة الجهاز android.hardware.wifi.
  • [C-1-3] يجب تنفيذ واجهة برمجة التطبيقات لبث الوسائط المتعدّدة على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK).
  • [C-1-4] يجب أن يكون الجهاز متوافقًا مع نظام أسماء النطاقات ذي البث المتعدد (mDNS) ويجب عدم فلترة حزم mDNS (224.0.0.251 أو ff02::fb) في أي وقت من أوقات التشغيل، بما في ذلك عندما تكون الشاشة في حالة غير نشطة، ما لم يكن إسقاط هذه الحِزم أو تصفيتها ضروريًا للبقاء ضمن نطاقات استهلاك الطاقة المطلوبة بموجب المتطلبات التنظيمية السارِية في السوق المستهدَف. في عمليات تنفيذ أجهزة Android Television، حتى في حالات الطاقة الاحتياطية
  • [C-1-5] يجب عدم التعامل مع طلب بيانات من واجهة برمجة التطبيقات WifiManager.enableNetwork() كإشارة كافية لتبديلNetwork النشط حاليًا والذي يتم استخدامه تلقائيًا للزيارات الواردة إلى التطبيق ويتم إرجاعه بواسطة طرق واجهة برمجة التطبيقات ConnectivityManager مثل getActiveNetwork وregisterDefaultNetworkCallback. بعبارة أخرى، يجوز لهم إيقاف إمكانية الوصول إلى الإنترنت المقدَّمة من أي مزوّد شبكة آخر (مثل بيانات الجوّال) فقط إذا تم التحقّق بنجاح من أنّ شبكة Wi-Fi توفّر إمكانية الوصول إلى الإنترنت.
  • [C-1-6] يُنصح بشدة بإعادة تقييم إمكانية الوصول إلى الإنترنت على Network عند استدعاء ConnectivityManager.reportNetworkConnectivity() طريقة واجهة برمجة التطبيقات، وبالتبديل إلى أي شبكة أخرى متاحة (مثل بيانات الشبكة اللاسلكية للأجهزة الجوّالة) تتيح الوصول إلى الإنترنت بعد أن يحدِّد التقييم أنّ Network الحالية لم تعُد تتيح الوصول إلى الإنترنت.
  • [C-1-7] يجب إنشاء عنوان MAC المصدر ورقم التسلسل لإطارات طلب الفحص بشكل عشوائي، مرة واحدة في بداية كل عملية بحث، عندما يكون STA غير متصل.
  • [C-1-8] يجب استخدام عنوان MAC واحد ثابت (يجب عدم إنشاء عنوان MAC عشوائي في منتصف عملية البحث).
  • [C-1-9] يجب تكرار رقم تسلسل طلب الفحص كالمعتاد (بشكل تسلسلي) بين طلبات الفحص في عملية الفحص.
  • [C-1-10] يجب أن يكون رقم تسلسل طلب الفحص عشوائيًا بين طلب الفحص المُرسَل الأخير لعملية مسح وأول طلب فحص لمُهمّة المسح التالية.
  • [C-SR-1] يُنصح بشدة بتعيين عنوان MAC المصدر بشكل عشوائي ليستخدمه كل جهاز STA للتواصل مع نقطة وصول (AP) أثناء الربط والربط.
    • يجب أن يستخدم الجهاز عنوان MAC عشوائيًا مختلفًا لكل SSID (FQDN لبروتوكول Passpoint) يتواصل معه.
    • يجب أن يقدّم الجهاز للمستخدم خيارًا للتحكّم في عملية التبديل العمياء لكل معرّف SSID (FQDN لبروتوكول Passpoint) من خلال خيارات غير عشوائية وأخرى عشوائية، ويجب ضبط الوضع التلقائي لعمليات ضبط Wi-Fi الجديدة على أن تكون عشوائية.
  • [C-SR-2] ننصح بشدة باستخدام معرّف BSSID عشوائي لأي نقطة اتصال يتم إنشاؤها.
    • يجب أن يكون عنوان MAC عشوائيًا ومستمرًا لكل SSID يستخدمه العميل.
    • يجوز للجهاز أن يقدّم للمستخدم خيارًا لإيقاف هذه الميزة. في حال توفّر هذا الخيار، يجب تفعيل وضع "العرض العشوائي" تلقائيًا.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة وضع توفير الطاقة في Wi-Fi كما هو محدّد في معيار IEEE 802.11، يجب أن تستوفي ما يلي:

  • يجب إيقاف وضع "توفير الطاقة في 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-3] يُنصح بشدة بتقليل وقت استجابة جولة Wi-Fi بالكامل عند الحصول على قفل وقت الاستجابة المنخفض (WIFI_MODE_FULL_LOW_LATENCY) وبدء تطبيقه.

إذا كانت عمليات تنفيذ الأجهزة تتيح استخدام شبكة Wi-Fi وتستخدمها للبحث عن الموقع الجغرافي، يجب أن تستوفي ما يلي:

  • [C-2-1] يجب توفير عنصر تحكم للمستخدم لتفعيل/إيقاف قراءة القيمة من خلال طريقة واجهة برمجة التطبيقات WifiManager.isScanAlwaysAvailable.
7.4.2.1. اتصال Wi-Fi مباشر

عمليات التنفيذ على الأجهزة:

  • يجب أن تتضمّن تقنية Wi-Fi Direct (الاتصال المباشر عبر Wi-Fi).

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة تقنية Wi-Fi Direct، يجب أن تستوفي الشروط التالية:

  • [C-1-1] يجب تنفيذ واجهة برمجة تطبيقات Android المقابلة كما هو موضّح في مستندات حزمة تطوير البرامج (SDK).
  • [C-1-2] يجب الإبلاغ عن ميزة الجهاز android.hardware.wifi.direct.
  • [C-1-3] يجب أن يكون الجهاز متوافقًا مع شبكة Wi-Fi العادية.
  • [C-1-4] يجب أن يكون الجهاز متوافقًا مع شبكة Wi-Fi وعمليات Wi-Fi Direct في الوقت نفسه.
  • [C-SR-1] يُنصح بشدة باختيار عنوان MAC المصدر بشكل عشوائي لجميع عمليات الربط التي تم إنشاؤها حديثًا باستخدام Wi-Fi Direct.

عمليات التنفيذ على الأجهزة:

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة بروتوكول TDLS وتم تفعيله من خلال واجهة برمجة التطبيقات WiFiManager API، يتم تنفيذ ما يلي:

  • [C-1-1] يجب الإفصاح عن توفّر بروتوكول TDLS من خلال WifiManager.isTdlsSupported.
  • يجب استخدام بروتوكول TDLS فقط عندما يكون ذلك ممكنًا ومفيدًا.
  • يجب أن يتضمّن بعض الأساليب الاستقرائية وألا يستخدم بروتوكول TDLS عندما يكون أداؤه أسوأ من استخدام نقطة وصول Wi-Fi.
7.4.2.3. Wi-Fi Aware

عمليات التنفيذ على الأجهزة:

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة استخدام ميزة Wi-Fi Aware وعرض الوظائف للتطبيقات التابعة لجهات خارجية، يجب أن تستوفي المتطلبات التالية:

  • [C-1-1] يجب تنفيذ واجهات برمجة تطبيقات WifiAwareManager على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK).
  • [C-1-2] يجب الإفصاح عن علامة ميزة android.hardware.wifi.aware.
  • [C-1-3] يجب أن يكون متوافقًا مع عمليات Wi-Fi وWi-Fi Aware في الوقت نفسه.
  • [C-1-4] يجب إنشاء عنوان واجهة إدارة Wi-Fi Aware بشكل عشوائي على فترات زمنية لا تزيد عن 30 دقيقة وكلما تم تفعيل Wi-Fi Aware ما لم تكن عملية الاستكشاف قيد التنفيذ أو كان مسار بيانات Aware نشطًا (لا يُتوقّع استخدام الترتيب العشوائي طيلة فترة نشاط مسار البيانات).

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة ميزتَي "الاستشعار عبر Wi-Fi" و "تحديد الموقع الجغرافي عبر Wi-Fi" كما هو موضّح في الفقرة 7.4.2.5 وكانت تتيح هذه الوظائف للتطبيقات التابعة لجهات خارجية، يجب أن تستوفي المتطلبات التالية:

7.4.2.4. Wi-Fi Passpoint

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة استخدام معيار 802.11 (Wi-Fi)، يجب أن تستوفي المتطلبات التالية:

  • [C-1-1] يجب أن تتضمّن Wi-Fi Passpoint.
  • [C-1-2] يجب تنفيذ واجهات برمجة التطبيقات WifiManager ذات الصلة ببرنامج Passpoint كما هو описан في مستندات حزمة تطوير البرامج (SDK).
  • [C-1-3] يجب أن يكون متوافقًا مع معيار IEEE 802.11u، خاصةً في ما يتعلّق باكتشاف الشبكة واختيارها، مثل "خدمة الإعلانات الشاملة" (GAS) و"بروتوكول طلب الوصول إلى الشبكة" (ANQP).
  • [C-1-4] يجب الإفصاح عن علامة ميزة android.hardware.wifi.passpoint.
  • [C-1-5] يجب اتّباع عملية التنفيذ في AOSP للتعرّف على شبكات Passpoint ومطابقتها وربطها بها.
  • [C-1-6] يجب