اعتبارًا من عام 2026، ولضمان توافقنا مع نموذج التطوير الثابت الرئيسي وضمان استقرار المنصة في المنظومة المتكاملة، سننشر الرمز المصدري في "مشروع Android مفتوح المصدر" (AOSP) في الربع الثاني والربع الرابع. لإنشاء AOSP والمساهمة فيه، ننصحك باستخدام android-latest-release بدلاً من aosp-main. سيشير فرع البيان android-latest-release دائمًا إلى أحدث إصدار تم إرساله إلى AOSP. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في مشروع Android المفتوح المصدر (AOSP).

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

تعريف التوافق مع الإصدار 17 من نظام التشغيل Android [معاينة]

1. مقدمة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.1. الأجهزة

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

‫[7.1.1.1/H-0-1] يجب أن يتضمّن الجهاز شاشة واحدة على الأقل متوافقة مع Android، ويبلغ قياسها 2.2 بوصة على الأقل من الحافة القصيرة و3.4 بوصة من الحافة الطويلة.
‫[7.1.1.3/H-SR-1] يُنصح بشدة بتوفير وسيلة للمستخدمين لتغيير حجم العرض (كثافة الشاشة).
‫[7.1.1.1/H-0-2] يجب أن يتيح الجهاز استخدام وحدة معالجة الرسومات لتركيب مخازن مؤقتة للرسومات بحجم لا يقل عن أعلى دقة لأي شاشة مدمجة.
‫[7.1.1.1/H-0-3]^* يجب أن يتم ربط كل شاشة UI_MODE_NORMAL يتم توفيرها للتطبيقات التابعة لجهات خارجية بمساحة عرض فعلية غير محجوبة لا تقل عن 2.2 بوصة على الحافة القصيرة و3.4 بوصة على الحافة الطويلة.
[7.1.1.3/H-0-1]^* يجب ضبط DENSITY_DEVICE_STABLE على% 92 أو أكثر من الكثافة الفعلية لشاشة العرض المعنية.

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

[7.1.4.2/H-1-1] يجب استيفاء المتطلبات المحدّدة في الملف الشخصي Android Baseline 2021.

إذا كانت عمليات تنفيذ الأجهزة المحمولة تعلن عن توفير أي واجهة التطبيق الثنائية (ABI) لنظام 64 بت (مع أو بدون أي واجهة التطبيق الثنائية (ABI) لنظام 32 بت) وتعرض false لقيمة ActivityManager.isLowRamDevice()، فإنها:

[7.1.4.2/H-2-1] يجب أن يتوافق مع الإصدار 1.1 من 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.4.6/H-1-1] يجب أن يتم عرض تقرير كناتج يتضمّن تتبُّعًا بتنسيق Protobuf يتوافق مع المخطط الخاص بعدّادات وحدة معالجة الرسومات ومراحل العرض في وحدة معالجة الرسومات المحدّدة في مستندات Perfetto.
[7.1.4.6/H-1-2] يجب إرسال قيم متوافقة لعدّادات وحدة معالجة الرسومات في الجهاز وفقًا لحزمة gpu counter trace الأولية.
[7.1.4.6/H-1-3] يجب عرض قيم متوافقة لمراحل العرض في وحدة معالجة الرسومات بالجهاز وفقًا لبروتوكول حزمة تتبُّع مراحل العرض.
[7.1.4.6/H-1-4] يجب تسجيل نقطة تتبُّع "تردد وحدة معالجة الرسومات" بالتنسيق المحدّد: power/gpu_frequency.

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

[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] يجب أن يكون الجهاز قادرًا على قياس التغييرات في الاتجاه بما يصل إلى 1000 درجة في الثانية.

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

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

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

[7.3.11/H-SR-1] يُنصح بشدة بتوفير دعم لمستشعر تحديد الوضعية مع 6 درجات حرية.

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

‫[7.4.1/H-1-1] يجب الإفصاح عن علامة ميزة android.hardware.telephony.data.

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

[7.4.3/H-SR-1] يُنصح بشدة بتوفير إمكانية تمديد طول حزمة بيانات بلوتوث منخفض الطاقة.

ملاحظة: سيصبح هذا الشرط [7.4.3/H-SR-1] إلزاميًا في إصدار مستقبلي من Android.

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

[7.4.2.4/H-1-1] يجب أن يتضمّن دعمًا لمعيار Wi-Fi Passpoint.

إذا كانت الأجهزة تتوافق مع بروتوكول اتصال مباشر بمحطات لاسلكية مجاورة (NAN) من خلال تعريف PackageManager.FEATURE_WIFI_AWARE وبروتوكول Wi-Fi Location (وقت الاستجابة لطلب Wi-Fi) من خلال تعريف PackageManager.FEATURE_WIFI_RTT، فإنّها:

‫[7.4.2.5/H-1-1] يجب أن يتم عرض النطاق بدقة ضمن هامش خطأ يبلغ +/- متر واحد عند عرض النطاق الترددي 160 ميغاهرتز عند النسبة المئوية الـ 68 (كما هو محسوب باستخدام دالة التوزيع التراكمي)، وضمن هامش خطأ يبلغ +/- مترَين عند عرض النطاق الترددي 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.

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

إذا كانت الأجهزة المحمولة تتوافق مع بروتوكول "رصد التقارب" (PD) عبر شبكة Wi-Fi من خلال تعريف PackageManager.FEATURE_WIFI_PD و"الموقع الجغرافي" (Wi-Fi Round Trip Time — RTT) عبر شبكة Wi-Fi من خلال تعريف PackageManager.FEATURE_WIFI_RTT، فإنّها:

‫[7.4.2.10/H-1-1] يجب استخدام معدل نقل بيانات بتردد 160 ميغاهرتز على الأقل.
‫[7.4.2.10/H-1-2] يجب عرض النطاق بدقة في حدود ‎+/-0.25 متر عند نطاق ترددي يبلغ 160 ميغاهرتز عند النسبة المئوية الـ 68 (كما يتم احتسابها باستخدام دالة التوزيع التراكمي)، وذلك كما هو ملاحظ من خلال WifiRttManager#startRanging Android API.

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

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

‫[7.4.3/H-1-3] يجب قياس إزاحة Rx والتعويض عنها لضمان أن يكون متوسط قوة إشارة RSSI لتقنية البلوتوث المنخفض الطاقة (BLE) هو ‎-50 ديسيبل ميلي واط ±15 ديسيبل ميلي واط على مسافة متر واحد من جهاز مرجعي يرسل البيانات بمعدل ADVERTISE_TX_POWER_HIGH.
‫[7.4.3/H-1-4] يجب قياس إزاحة الإرسال والتعويض عنها لضمان أن يكون متوسط قوة الإشارة المستلَمة (RSSI) بتقنية Bluetooth منخفضة الطاقة (BLE) هو ‎-50 ديسيبل ميلي واط ±15 ديسيبل عند إجراء عملية البحث من جهاز مرجعي موضوع على مسافة متر واحد وإرسال الإشارة بمعدل ADVERTISE_TX_POWER_HIGH.

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

[7.5.1/H-1-1] يجب أن تبلغ درجة الدقة 2 ميغابكسل على الأقل.

إذا كانت عمليات تنفيذ الأجهزة المحمولة باليد تتضمّن جهاز كاميرا منطقيًا يعرض قائمة بالإمكانات باستخدام 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 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم دقة إطارات تصل إلى qHD (مثل FWVGA).
‫[7.6.1/H-2-1] يجب أن تبلغ سعة الذاكرة المتاحة للنواة ومساحة المستخدم 592 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم دقة إطارات تصل إلى HD+‎ (مثل HD وWSVGA).
‫[7.6.1/H-3-1] يجب أن تبلغ سعة الذاكرة المتاحة للنواة ومساحة المستخدم 896 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم دقة إطارات تصل إلى FHD (مثل WSXGA+).
‫[7.6.1/H-4-1] يجب أن تبلغ سعة الذاكرة المتاحة للنواة ومساحة المستخدم 1344 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم دقة تصل إلى QHD (مثل QWXGA).

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

‫[7.6.1/H-5-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 816 ميغابايت على الأقل إذا كان العرض التلقائي يستخدم دقة إطارات الفيديو تصل إلى qHD (مثل FWVGA).
‫[7.6.1/H-6-1] يجب أن تبلغ سعة الذاكرة المتاحة للنواة ومساحة المستخدم 944 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم دقة إطارات تصل إلى HD+‎ (مثل HD وWSVGA).
[7.6.1/H-7-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 1280 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم دقة إطارات فيديو تصل إلى FHD (مثل WSXGA+).
‫[7.6.1/H-8-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 1824 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم دقة إطارات فيديو تصل إلى QHD (مثل QWXGA).

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

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

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

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

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

إذا كانت عمليات تنفيذ الأجهزة المحمولة تتضمّن ذاكرة متاحة للنواة ومساحة المستخدم تبلغ 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 يمكن لتطبيقات الواقع الافتراضي تفعيله من خلال android.app.Activity#setVrModeEnabled.

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

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

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

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

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

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

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

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

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

[7.8.2.2/H-4-1] يجب إدراج جهاز من النوع AudioDeviceInfo.TYPE_USB_HEADSET والدور isSink() إذا كان حقل نوع طرفية الصوت عبر USB هو 0x0302.
‫[7.8.2.2/H-4-2] يجب إدراج جهاز من النوع AudioDeviceInfo.TYPE_USB_HEADSET والدور isSink() إذا كان حقل نوع طرفية الصوت عبر USB هو 0x0402.
‫[7.8.2.2/H-4-3] يجب إدراج جهاز من النوع AudioDeviceInfo.TYPE_USB_HEADSET والدور isSource() إذا كان حقل نوع طرفية الصوت عبر USB هو 0x0402.
[7.8.2.2/H-4-4] يجب إدراج جهاز من النوع AudioDeviceInfo.TYPE_USB_DEVICE والدور isSink() إذا كان حقل نوع طرفية الصوت عبر USB هو 0x603.
[7.8.2.2/H-4-5] يجب إدراج جهاز من النوع AudioDeviceInfo.TYPE_USB_DEVICE والدور isSource() إذا كان حقل نوع طرفية الصوت عبر USB هو 0x604.
‫[7.8.2.2/H-4-6] يجب إدراج جهاز من النوع AudioDeviceInfo.TYPE_USB_DEVICE والدور isSink() إذا كان حقل نوع طرفية الصوت عبر USB هو 0x400.
[7.8.2.2/H-4-7] يجب إدراج جهاز من النوع AudioDeviceInfo.TYPE_USB_DEVICE والدور isSource() إذا كان حقل نوع طرفية الصوت عبر USB هو 0x400.
[7.8.2.2/H-SR-1] يُنصح بشدة عند توصيل جهاز ملحق صوتي بمنفذ USB-C بإجراء تعداد لأوصاف USB وتحديد أنواع المحطات الطرفية وبث Intent ACTION_HEADSET_PLUG في أقل من 1,000 مللي ثانية.

بالنسبة إلى عمليات تنفيذ الأجهزة المحمولة التي تحدّد android.hardware.audio.output وandroid.hardware.microphone، يُرجى الاطّلاع على متطلبات RTL وTTL في القسم 5.6.

المشغّل الرنان الخطي (LRA) هو نظام زنبركي أحادي الكتلة يتضمّن ترددًا رنّانًا سائدًا تتحرك فيه الكتلة في اتجاه الحركة المطلوبة.

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

[7.10/H] يجب وضع مشغّل الجهاز بالقرب من المكان الذي يتم عادةً حمل الجهاز أو لمسه فيه.
‫[7.10/H] يجب تحريك المحرّك اللمسي على المحور X (من اليسار إلى اليمين) في الاتجاه الطبيعي للجهاز.

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

‫[7.10/H] يجب أن يكون التردد الرنيني لمشغّل الرنين الخطي على المحور X أقل من 200 هرتز.

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

[7.10/H]^* يجب التحقّق من حالة التنفيذ من خلال تشغيل واجهتَي برمجة التطبيقات android.os.Vibrator.areAllEffectsSupported() وandroid.os.Vibrator.arePrimitivesSupported().
[7.10/H]^* يجب إجراء تقييم للجودة للمتغيرات الحسية.
‫[7.10/H]^* يجب التحقّق من إعدادات التوافق مع الإصدارات السابقة وتعديلها إذا لزم الأمر، وذلك بالنسبة إلى العناصر الأساسية غير المتوافقة كما هو موضّح في إرشادات التنفيذ الخاصة بالثوابت.

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

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

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

[5.1/H-0-6] MPEG-D USAC with MPEG-D DRC (Extended High Efficiency AAC)

2.2.3. برامج

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

‫[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]^* يجب التحميل المُسبَق لتطبيق واحد أو أكثر أو لمكوّنات خدمة تتضمّن معالج أهداف، وذلك لجميع أنماط intent filter العامة المحدّدة من خلال أهداف التطبيقات التالية المدرَجة هنا. ملاحظة: ستتضمّن صفحة "أهداف التطبيقات الشائعة" الهدف الإلزامي الجديد "android.settings.VPN_APP_EXCLUSION_SETTINGS".

[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-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.2/H-0-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] يجب أن يتضمّن مركز إشعارات يتيح للمستخدم التحكّم مباشرةً في الإشعارات (مثل الرد أو تأجيل الإشعار أو تجاهله أو حظره) من خلال إمكانية الوصول إلى المستخدم، مثل أزرار الإجراءات أو لوحة التحكّم كما هو موضّح في "مشروع Android المفتوح المصدر" (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.

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

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

[3.8.3.1/H-0-1] يجب عرض إشعار "تحديث مباشر" مُروَّج له في مكان بارز على شاشة القفل.
[3.8.3.1/H-0-12] يجب أن يظهر في أعلى حزمة الإشعارات الإشعار العائم وفوق الإشعارات الملوّنة (حيث setColorized هو true) عند عرض إشعار "التحديثات الفورية" المُروَّج له بين الإشعارات الأخرى.
- قد يحدّد ترتيب تسلسل "الإشعارات بشأن التحديثات الفورية المقترَحة" المعروضة في مركز الإشعارات وشاشة القفل عندما يكون أكثر من تطبيق واحد مؤهلاً لتلقّي "إشعار بشأن تحديث فوري مقترَح".
[3.8.3.1/H-0-2] يجب عرض إشعار "تحديث مباشر" مُحسَّن في الحالة الموسّعة.
[3.8.3.1/H-0-3] يجب عدم توفير وسيلة تتيح للمستخدم تصغير الإشعار الموسّع أعلاه.
[3.8.3.1/H-0-4] يجب عرض الأنماط الأساسية (الخط الغامق والمائل والتسطير) لمحتوى النص في إشعار التحديث المباشر المُروَّج له، كما هو مقدَّم من خلال StyleSpan أو UnderlineSpan.
[3.8.3.1/H-0-5] يجب عرض عناصر الإجراءات العادية فقط (من خلال Notification.Action)، ويجب إخفاء عناصر الإجراءات غير العادية، مثل مربّعات الإدخال وأزرار الرد والإجراءات السياقية (من خلال addRemoteInput() وsetContextual()) في إشعار "آخر الأخبار" الترويجي، حتى عندما يتضمّن الإشعار هذه العناصر.
[3.8.3.1/H-0-6] يجب عرض تمثيل مضغوط، يُشار إليه أيضًا باسم شريحة الحالة في مستندات حزمة تطوير البرامج (SDK)، لإشعار بتحديث مباشر مُروَّج له يجب أن يتضمّن Notification.getSmallIcon().
- [3.8.3.1/H-0-7] الحقول الأخرى اختيارية في التمثيل المكثّف، ولكن عندما يكون من الممكن توسيع التمثيل المكثّف، يجب عرض Notification.getShortCriticalText() إذا كان متوفّرًا، أو Notification.when إذا لم يكن Notification.getShortCriticalText متوفّرًا.
- [3.8.3.1/H-0-8] عند توفّر أكثر من إشعار واحد بشأن "التحديثات المباشرة" المروّجة، يجب عرض إشعار واحد على الأقل في شريط الحالة كتمثيل مضغوط.
- [3.8.3.1/H-0-9] يجب إما عرض الإشعار المرتبط (الخيار المفضّل) أو فتح التطبيق المرتبط (من خلال Notification.contentIntent)، عندما ينقر المستخدم على التمثيل المضغوط.
- [3.8.3.1/H-0-13] يجب عرض كل المحتوى نفسه في الإشعار المرتبط كما هو في مركز الإشعارات.
[3.8.3.1/H-0-10] يجب توفير وسيلة للمستخدمين لإيقاف العرض الترويجي لإشعارات التطبيقات الفردية وتفعيله.
[3.8.3.1/H-0-11] يجب عرض جميع "إشعارات المعلومات الحية" بشكل صحيح، بما في ذلك على سبيل المثال لا الحصر "إشعارات المعلومات الحية" غير الترويجية التي لا تستوفي أو تستوفي جزئيًا فقط خصائص الترويج. يجب عرض هذه الإشعارات غير الترويجية في حالة غير ترويجية.

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

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

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

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

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

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

في حال كانت عمليات تنفيذ أجهزة 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.16/H-2-1] يجب الإبلاغ عن null لواجهتَي برمجة التطبيقات ControlsProviderService وControl.
[3.8.16/H-2-2] يجب الإفصاح عن علامة الميزة android.software.controls وضبطها على false.

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

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

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

[3.10/H-0-1] يجب أن تتوافق مع خدمات تسهيل الاستخدام التابعة لجهات خارجية.
[3.10/H-SR-1] يُنصح بشدة بتثبيت خدمات تسهيل الاستخدام مسبقًا على الجهاز، على أن تكون هذه الخدمات مماثلة أو أفضل من خدمات "الوصول عبر مفتاح تحويل" وTalkBack (بالنسبة إلى اللغات التي يتوافق معها محرّك تحويل النص إلى كلام المثبَّت مسبقًا) كما هو موضّح في مشروع 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] يجب أن يتيح الجهاز المساعد إمكانية إقران الأجهزة.

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

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

‫[3.20.1/H-0-1] يجب استيفاء جميع متطلبات "بث الصوت في مساعد Google".

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

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

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

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

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

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

[7.5.4/H-1-1] يجب الالتزام بنية android.media.action.STILL_IMAGE_CAMERA وandroid.media.action.STILL_IMAGE_CAMERA_SECURE وتشغيل الكاميرا في وضع الصور الثابتة كما هو موضّح في حزمة تطوير البرامج (SDK).
[7.5.4/H-1-2] يجب أن يلتزم android.media.action.VIDEO_CAMERA بالنية في تشغيل الكاميرا في وضع الفيديو كما هو موضّح في حزمة تطوير البرامج (SDK).

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

[3.2.3.1/ H-1-1] يجب أن يتضمّن التطبيق نشاطًا يعالج الغرض Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY عندما تكون وظيفة التقسيم مفعّلة. يجب أن تكون "النشاط" محمية بواسطة android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK، ويجب أن تبدأ نشاط Intent الذي تم تحليله من Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.

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

[7.4.1.2/H-0-1] يجب الإفصاح عن علامة الميزة android.software.telecom.

[7.4.1.2/H-0-2] يجب تنفيذ إطار عمل الاتصالات.

‫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 ميغابايت في الثانية على الأقل.

إذا كانت عمليات تنفيذ الأجهزة المحمولة باليد تتضمّن ميزات لتحسين إدارة طاقة الجهاز مضمّنة في مشروع Android مفتوح المصدر (AOSP) أو توسّع الميزات المضمّنة في مشروع Android مفتوح المصدر (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) لكل معرّف UID خاص بكل عملية. يستوفي "مشروع Android المفتوح المصدر" هذا الشرط من خلال تنفيذ وحدة النواة uid_cputime.
[8.4/H-0-4] يجب أن يتيح الجهاز للمطوّر إمكانية الوصول إلى بيانات استهلاك الطاقة من خلال الأمر adb shell dumpsys batterystats في واجهة سطر الأوامر.
[8.4/H] يجب أن يتم تحديد مصدر استهلاك الطاقة على أنّه مكوّن الجهاز نفسه إذا تعذّر تحديد مصدر استهلاك الطاقة على أنّه تطبيق.

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

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

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

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

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

[9.1/H-0-2] يجب عدم منح ACCESS_FINE_LOCATION كإذن تلقائي لهذا التطبيق.

يجب أن توضّح عمليات تنفيذ الأجهزة أنّها متوافقة مع android.software.credentials وأن تستوفي ما يلي:

‫[9/H-0-2] يجب الالتزام android.settings.CREDENTIAL_PROVIDER بالسماح باختيار مقدّم خدمة مفضّل في Credential Manager. سيتم تفعيل مقدّم الخدمة هذا لميزة "الملء التلقائي"، وسيكون أيضًا الموقع الجغرافي التلقائي لحفظ بيانات الاعتماد الجديدة التي يتم إدخالها من خلال Credential Manager.
‫[9/H-0-3] يجب أن يتيح الجهاز استخدام مزوّدَي بيانات اعتماد متزامنين على الأقل، ويجب أن يوفّر للمستخدمين إمكانية تفعيل المزوّدين أو إيقافهم في تطبيق "الإعدادات".
[‫9.5/H-1-1] تمت إزالة هذا الشرط في Android 16.

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

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

ملاحظة: لاستيفاء هذا الشرط، يجب مشاركة مفتاح التصديق نفسه لرمز تخزين تعريفي معيّن ما لم يتم إنتاج 100,000 وحدة على الأقل من رمز التخزين التعريفي هذا. إذا تم إنتاج أكثر من 100,000 وحدة من رمز التخزين التعريفي هذا، يمكن استخدام مفتاح مختلف لكل مجموعة من 100,000 وحدة بعد ذلك. بدلاً من ذلك، يمكن استخدام حلّ Remote Key Provisioning لتوفير مفاتيح تصديق قصيرة الأمد للجهاز.

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

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

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

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

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

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

[9.11.1/H-1-1] يجب استدعاء TrustManagerService.revokeTrust() بعد أيّ من الحالتين التاليتين:
- يجب أن يكون الحد الأقصى 24 ساعة من تاريخ منح الثقة.
- مهلة عدم نشاط لمدة 8 ساعات

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

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

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

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

حظر المشاركة من خلال الإعدادات

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

أن يتم تثبيته بعد تنزيله من خلال تطبيق (مثل تطبيق مراسلة أو متصفّح) غير تطبيق "متجر التطبيقات" الذي تحدّده PackageManager على أنّه PACKAGE_DOWNLOADED_FILE.
أنّه تم تثبيته من ملف محلي (على سبيل المثال، تم تحميل التطبيق من مصدر غير معروف) ويتم تحديد ذلك من خلال PackageManager على أنّه PACKAGE_SOURCE_LOCAL_FILE.

أي من الأذونات المفروضة والمعرّفات المرتبطة بها والمدرَجة في [9.8/H-0-5] أدناه

ويتم تصنيف هذه التطبيقات على أنّها "تطبيقات مشمولة" في ما يتعلّق بالمتطلبات المدرَجة في هذا القسم.

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

[9.8/H-0-1] يجب تنفيذ "الإعدادات المقيدة" على النحو الموضّح أعلاه لما يلي:
- الأذونات الخاصة
  - تسهيل الاستخدام (AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE)
  - مستمع الإشعارات (AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS)
  - تطبيقات مشرف الجهاز (Manifest.permission.BIND_DEVICE_ADMIN)
  - العرض فوق التطبيقات الأخرى (AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW)
  - إذن الوصول إلى بيانات الاستخدام (AppOpsManager.OPSTR_GET_USAGE_STATS)
- الأدوار (التطبيقات التلقائية)
  - ‫Dialer‏ (‎RoleManager.ROLE_DIALER)
  - رسالة قصيرة (RoleManager.ROLE_SMS)
- أذونات التشغيل
  - مدة تشغيل الرسالة القصيرة (Manifest.permission_group.SMS)
‫[9.8/H-0-2] يجب تفعيل "الإعدادات المحظورة" كإعداد تلقائي، ويُنصح بشدة بعدم توفير أي وسيلة تتيح للمستخدم إيقاف "الإعدادات المحظورة" لجميع التطبيقات.
‫[9.8/H-0-3] يجب التأكّد من الحصول على تأكيد المستخدم لكل تطبيق خاضع للتغطية قبل منح أي من الأذونات المفروضة.
‫[9.8/H-0-4] يجب السماح فقط بالحصول على تأكيد المستخدم لتفعيل الإعدادات المحظورة من صفحة AppInfo الخاصة بالتطبيق المشمول باستخدام واجهة برمجة التطبيقات EnhancedConfirmationManager.
[‫9.8/H-0-5] يُنصح بشدة بالدمج مع EnhancedConfirmationManager واستدعائه لجميع الأذونات الخاصة، وذلك لتحديد ما إذا كانت إعدادات مقيّدة بشكل ديناميكي.
- المنبّهات والتذكيرات: AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
- الوصول إلى كل الملفات: AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
- الظهور فوق التطبيقات الأخرى: AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
- تثبيت التطبيقات غير المعروفة: AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
- إدارة الوسائط: AppOpsManager.OPSTR_MANAGE_MEDIA
- تعديل إعدادات النظام: AppOpsManager.OPSTR_WRITE_SETTINGS
- نافذة ضمن النافذة: AppOpsManager.OPSTR_PICTURE_IN_PICTURE
- تشغيل الشاشة: AppOpsManager.OPSTR_TURN_SCREEN_ON
- الإشعارات بملء الشاشة: AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
- التحكّم في شبكة Wi-Fi: AppOpsManager.OPSTR_CHANGE_WIFI_STATE
- تسهيل الاستخدام: AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
- برنامج تلقّي الإشعارات: AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
- إذن الوصول إلى بيانات الاستخدام: AppOpsManager.OPSTR_GET_USAGE_STATS
- مشرف الجهاز: Manifest.permission.BIND_DEVICE_ADMIN
- عدم الإزعاج: Manifest.permission.MANAGE_NOTIFICATIONS

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

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

[‫9.8/H-1-1] يجب التأكّد من أنّ خدمة رصد الكلمات المحفّزة يمكنها نقل البيانات إلى النظام أو ContentCaptureService أو خدمة التعرّف على الكلام على الجهاز التي أنشأتها SpeechRecognizer#createOnDeviceSpeechRecognizer() فقط.
‫[9.8/H-1-2] يجب التأكّد من أنّ خدمة رصد الكلمات المحفّزة لا يمكنها إرسال بيانات الصوت من الميكروفون أو البيانات المستمدّة منه إلى خادم النظام إلا من خلال واجهة برمجة التطبيقات HotwordDetectionService أو إلى ContentCaptureService من خلال واجهة برمجة التطبيقات ContentCaptureManager.
[9.8/H-1-3] يجب عدم تقديم صوت من الميكروفون لمدة تزيد عن 30 ثانية لطلب فردي يتم تنشيطه من خلال الجهاز إلى خدمة رصد الكلمات الرئيسية.
[9.8/H-1-4] يجب عدم توفير صوت مخزّن مؤقتًا من الميكروفون أقدم من 8 ثوانٍ لطلب فردي إلى خدمة اكتشاف الكلمات المهمة.
‫[9.8/H-1-5] يجب عدم تزويد خدمة التفاعل الصوتي أو جهة مشابهة ببيانات صوتية مخزّنة مؤقتًا من الميكروفون أقدم من 30 ثانية.
‫[9.8/H-1-6] يجب ألا يسمح بنقل أكثر من 100 بايت من البيانات (باستثناء بث الصوت) خارج خدمة رصد الكلمات المحفّزة في كل نتيجة ناجحة للكلمة المحفّزة.
‫[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] يُنصح بشدة بعدم السماح بنقل البيانات غير المنظَّمة خارج خدمة رصد الكلمات المحفّزة.
‫[9.8/H-SR-3] يُنصح بشدة بإعادة تشغيل العملية التي تستضيف خدمة رصد الكلمات المحفّزة مرة واحدة على الأقل كل ساعة أو كل 30 حدثًا من أحداث التشغيل بواسطة الأجهزة، أيهما أقرب.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن تطبيقًا يستخدم واجهة برمجة التطبيقات للنظام 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()، بالإضافة إلى أي رسائل تحديد مصدر مرتبطة بها.
[9.8.2/H-4-3] يجب عدم إخفاء مؤشر الميكروفون لتطبيقات النظام التي تتضمّن واجهات مستخدم مرئية أو تفاعلاً مباشرًا مع المستخدم.
[9.8.2/H-4-4] يجب عرض قائمة بالتطبيقات الحديثة والنشطة التي تستخدم الميكروفون، وذلك على النحو الذي تم إرجاعه من خلال PermissionManager.getIndicatorAppOpUsageData()، بالإضافة إلى أي رسائل تحديد مصدر مرتبطة بها.

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

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

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

[9.8.8/H-6-1] يجب عرض مؤشر مرئي للمستخدم.

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

[9.10/H-1-1] يجب التحقّق من صحة جميع الأقسام التي يمكن القراءة منها فقط والتي تم تثبيتها أثناء تسلسل تشغيل Android، ويجب أن يتضمّن ملخّص VBMeta جميع هذه الأقسام التي تم التحقّق من صحتها في عملية احتسابه.

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

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

[6.1/H-0-1]* يجب أن يتيح تنفيذ أمر shell cmd testharness.

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

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

أجرينا تغييرات كبيرة على بنية متطلبات فئة "أداء الوسائط". بدءًا من المستوى 37 لواجهة برمجة التطبيقات، أضفنا المستويات الجديدة 1 و10 و20 و37. لقد خفّضنا أيضًا من تعقيد المتطلبات من خلال الرجوع إلى صفحة قياسات فئة أداء الوسائط التي توضّح بالتفصيل كل متطلب يتم قياسه حسب مستوى MPC.

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

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

2.2.7.1. الوسائط

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

يجب استيفاء جميع متطلبات الوسائط المدرَجة في القسم 2.2.7.1 من مستند تعريف التوافق مع Android 17 بما يتوافق مع مستوى فئة أداء الوسائط المعلَن للجهاز.
‫[5.1/H-1-1] يجب الإعلان عن الحد الأقصى لعدد جلسات فك ترميز الفيديو للأجهزة التي يمكن تشغيلها بشكل متزامن في أي مجموعة برامج ترميز من خلال الطريقتَين CodecCapabilities.getMaxSupportedInstances() وVideoCapabilities.getSupportedPerformancePoints() المتوافقتَين مع مستوى فئة أداء الوسائط المعلَن عنه للجهاز.
‫[5.1/H-1-2] يجب أن تتوافق مع جلسات فك ترميز الفيديو على مستوى الجهاز (AVC أو HEVC أو VP9 أو AV1 أو الإصدارات الأحدث)، ومع الحالات المتزامنة وانخفاض عدد اللقطات في الثانية بما يتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.1/H-1-3] يجب الإعلان عن الحد الأقصى لعدد جلسات ترميز الفيديو باستخدام الأجهزة التي يمكن تشغيلها بشكل متزامن في أي مجموعة برامج ترميز من خلال طريقتَي CodecCapabilities.getMaxSupportedInstances() وVideoCapabilities.getSupportedPerformancePoints() المتوافقتَين مع مستوى فئة أداء الوسائط المعلَن للجهاز.
‫[5.1/H-1-4] يجب أن تتوافق مع جلسات برنامج ترميز الفيديو للأجهزة (AVC أو HEVC أو VP9 أو AV1 أو الإصدارات الأحدث)، والعمليات المتزامنة، وإطارات الفيديو التي تم إسقاطها بما يتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.1/H-1-5] يجب الإعلان عن الحد الأقصى لعدد جلسات ترميز الفيديو وفك ترميزه المتزامنة للأجهزة في أي مجموعة برامج ترميز من خلال الطريقتَين CodecCapabilities.getMaxSupportedInstances() وVideoCapabilities.getSupportedPerformancePoints() المتوافقتَين مع مستوى فئة أداء الوسائط الذي تم الإعلان عنه للجهاز.
‫[5.1/H-1-6] يجب أن يتيح الجهاز جلسات لبرنامج فك ترميز الفيديو وبرنامج ترميز الفيديو على مستوى الأجهزة (AVC أو HEVC أو VP9 أو AV1 أو الإصدارات الأحدث)، بالإضافة إلى مثيلات متزامنة وعمليات إسقاط إطارات تتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.1/H-1-7] يجب أن يكون هناك وقت استجابة لتهيئة برنامج الترميز لجلسة ترميز فيديو بدقة 1080p أو أقل لجميع برامج ترميز الفيديو للأجهزة عند التحميل بما يتوافق مع مستوى فئة أداء الوسائط المعلَن للجهاز.
‫[5.1/H-1-8] يجب أن يكون هناك تأخير في بدء تشغيل برنامج الترميز لجلسة ترميز صوتي بمعدل 128 كيلوبت في الثانية أو أقل لجميع برامج الترميز الصوتية عند التحميل بما يتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.1/H-1-9] يجب أن يتيح الجهاز مثيلَين لجلسات فك ترميز الفيديو الآمنة على مستوى الأجهزة (AVC أو HEVC أو VP9 أو AV1 أو الإصدارات الأحدث) وإسقاط اللقطات بما يتوافق مع فئة أداء الوسائط المحدّدة للجهاز.
‫[5.1/H-1-10] يجب أن يتيح الجهاز 3 جلسات لبرنامج فك ترميز الفيديو غير الآمن على مستوى الجهاز، بالإضافة إلى جلسة واحدة لبرنامج فك ترميز الفيديو الآمن على مستوى الجهاز (4 جلسات إجمالاً) (AVC أو HEVC أو VP9 أو AV1 أو الإصدارات الأحدث)، والدقّات، وعمليات إسقاط الإطارات التي تتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.1/H-1-11] يجب توفير برنامج ترميز آمن لكل برنامج ترميز للأجهزة AVC أو HEVC أو VP9 أو AV1 يتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.1/H-1-12] يجب أن يكون هناك وقت استجابة لتهيئة برنامج الترميز لجلسة فك ترميز فيديو بدقة 1080 بكسل أو أقل لجميع برامج فك ترميز الفيديو على الأجهزة عندما يكون الجهاز تحت الحمل الذي يتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.1/H-1-13] يجب أن يكون هناك وقت استجابة لتهيئة برنامج الترميز لجلسة فك ترميز الصوت بمعدل نقل بيانات يبلغ 128 كيلوبت في الثانية أو أقل لجميع برامج فك ترميز الصوت عند التحميل بما يتوافق مع مستوى فئة أداء الوسائط الذي تم الإعلان عنه للجهاز.
‫[5.1/H-1-14] يجب أن يتوافق مع ملف تعريف برنامج ترميز AV1 وميزاته وطريقة العرض بما يتوافق مع فئة مستوى أداء الوسائط المحدّدة للجهاز.
‫[5.1/H-1-15] يجب أن يتضمّن الجهاز برنامج ترميز فيديو واحدًا على الأقل للأجهزة المتوافقة مع دقة 4K60 يتوافق مع فئة مستوى أداء الوسائط المحدّدة للجهاز.
‫[5.1/H-1-16] يجب أن يتضمّن الجهاز برنامج ترميز فيديو واحدًا على الأقل للأجهزة المتوافقة مع دقة 4K60 بما يتوافق مع فئة أداء الوسائط المحدّدة للجهاز.
[5.1/H-1-17] يجب أن يتضمّن الجهاز برنامج ترميز صور للأجهزة واحدًا على الأقل متوافقًا مع ملف تعريف AVIF الأساسي بما يتوافق مع مستوى فئة أداء الوسائط الذي تم الإعلان عنه للجهاز.
‫[5.1/H-1-18] يجب أن يتوافق مع برنامج ترميز AV1 الذي يستوفي متطلبات معدل نقل البيانات والإطارات في الثانية والدقة التي تتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.1/H-1-19] يجب أن يتيح الجهاز 3 مثيلات من جلسات برنامج ترميز الفيديو وفك ترميز الفيديو للأجهزة (AVC أو HEVC أو VP9 أو AV1 أو الإصدارات الأحدث) بدقة 10 بت (HDR)، وأن يتيح عدد اللقطات في الثانية وعدد اللقطات التي تم إسقاطها بما يتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.1/H-1-20] يجب أن تتوافق جميع برامج ترميز AV1 وHEVC للأجهزة المتوفرة على الجهاز مع الميزة Feature_HdrEditing المتوافقة مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.1/H-1-21] يجب أن تتوافق FEATURE_DynamicColorAspect مع جميع برامج فك ترميز الفيديو للأجهزة (AVC أو HEVC أو VP9 أو AV1 أو الإصدارات الأحدث) التي تتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.1/H-1-22] يجب أن يتيح الجهاز ترميز محتوى الفيديو وفك ترميزه وتعديله باستخدام وحدة معالجة الرسومات وعرضه بنسبة عرض إلى ارتفاع عمودية تتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
[5.2/H-2-1] إذا كان تصميم الجهاز يتيح استخدام برامج ترميز AVC أو HEVC المستندة إلى الأجهزة، يجب أن يستوفي الحد الأدنى من معايير الجودة المحدّدة من خلال منحنيات معدل تشويه برنامج ترميز الفيديو لهذين البرنامجين، بما يتوافق مع مستوى فئة أداء الوسائط المعلَن للجهاز.

‫[5.2/H-2-2] يجب أن تتوافق مع MMAP على مسار السماعة الذي يتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.

‫[5.3/H-1-1] يجب استيفاء متطلبات أداء جلسة الفيديو ومعدّل انخفاض اللقطات بما يتوافق مع مستوى فئة أداء الوسائط الذي تم الإعلان عنه للجهاز.
‫[5.3/H-1-2] يجب استيفاء متطلبات الأداء المتعلقة بتغيير درجة دقة الفيديو المناسبة لمستوى فئة أداء الوسائط الذي تم الإعلان عنه للجهاز.
‫[5.6/H-1-1] يجب استيفاء متطلبات وقت الاستجابة عند النقر على الشاشة لإصدار صوت بما يتوافق مع مستوى فئة أداء الوسائط الذي تم الإعلان عنه للجهاز.
‫[5.6/H-1-2] يجب استيفاء متطلبات وقت استجابة الصوت ذهابًا وإيابًا بما يتوافق مع مستوى فئة أداء الوسائط المعلَن للجهاز.
‫[5.6/H-1-3] يجب استيفاء متطلبات الصوت بدقة 24 بت بما يتوافق مع فئة مستوى أداء الوسائط المحدّدة للجهاز.
‫[5.6/H-1-4] يجب أن تتوافق مع أجهزة صوت USB التي تتضمّن 4 قنوات أو أكثر، بما يتوافق مع مستوى فئة أداء الوسائط المحدّد في الجهاز.
[5.6/H-1-5] يجب أن تتوافق الأجهزة مع أجهزة MIDI المتوافقة مع الفئة، ويجب أن تحدّد علامة ميزة MIDI التي تتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.6/H-1-9] يجب أن يتيح الجهاز دمج 12 قناة على الأقل بما يتوافق مع مستوى فئة أداء الوسائط المحدّد في الجهاز.

‫[5.6/H-3-1] يجب أن يكون الجهاز قادرًا على التبديل بين تشغيل الموجات الجيبية بدون حدوث نقص في مخازن الصوت المؤقتة التي تتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.6/H-3-2] يجب استيفاء متطلبات قنوات إخراج جهاز الصوت عبر USB المتوافقة مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.6/H-3-3] يجب استيفاء متطلبات قنوات إدخال جهاز الصوت عبر USB المتوافقة مع مستوى فئة أداء الوسائط المحدّد للجهاز.

[5.6/H-SR-1] يُنصح بشدة بتوفير إمكانية دمج قنوات الصوت بما يتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.7/H-1-2] يجب أن تتوافق مع MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL مع إمكانات فك التشفير المتوافقة مع مستوى فئة أداء الوسائط المحدّد للجهاز.
[5.12/H-1-2] يجب استيفاء متطلبات تنسيق الألوان لأجهزة ترميز AV1 وHEVC بما يتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[5.12/H-1-3] يجب الإعلان عن إتاحة استخدام الإضافة EXT_YUV_target المتوافقة مع مستوى فئة أداء الوسائط المحدّد في الجهاز.
‫[7.1.4/H-1-1] يجب استيفاء متطلبات وحدة معالجة العرض (DPU) التي تتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.

2.2.7.2. الكاميرا

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

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

‫[7.5/H-1-1] يجب أن تستوفي الكاميرا الأساسية الخلفية متطلبات دقة الوضوح وتسجيل الفيديو التي تتوافق مع مستوى فئة أداء الوسائط المعلَن للجهاز.
[7.5/H-1-2] يجب أن تستوفي الكاميرا الأمامية الرئيسية متطلبات دقة العرض وتسجيل الفيديو المتوافقة مع مستوى فئة أداء الوسائط المعلَن للجهاز.
‫[7.5/H-1-3] يجب أن تتوافق مع متطلبات السمة android.info.supportedHardwareLevel التي تتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
[7.5/H-1-4] يجب أن تتوافق CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME مع كلتا الكاميرتَين الأساسيتَين المتوافقتَين مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[7.5/H-1-5] يجب استيفاء متطلبات وقت استجابة التقاط صور JPEG باستخدام Camera2 بما يتوافق مع مستوى فئة أداء الوسائط الذي تم الإعلان عنه للجهاز.
‫[7.5/H-1-6] يجب استيفاء متطلبات وقت الاستجابة عند بدء تشغيل camera2 التي تتوافق مع مستوى فئة أداء الوسائط المعلَن للجهاز.
[7.5/H-1-8] يجب استيفاء متطلبات التقاط الصور بتنسيق RAW بما يتوافق مع فئة مستوى أداء الوسائط المعلَن عنها للجهاز.
[7.5/H-1-9] يجب استيفاء متطلبات تسجيل الفيديو عالي السرعة باستخدام الكاميرا الأساسية الخلفية بما يتوافق مع مستوى فئة أداء الوسائط الذي تم الإعلان عنه للجهاز.
‫[7.5/H-1-10] يجب استيفاء الحد الأدنى لمتطلبات نسبة التكبير/التصغير المناسبة لمستوى فئة أداء الوسائط المحدّد للجهاز.
‫[7.5/H-1-11] يجب تنفيذ البث المتزامن من الكاميرات الأمامية والخلفية على الكاميرات الأساسية التي تتوافق مع مستوى فئة أداء الوسائط المعلَن للجهاز.
[7.5/H-1-12] يجب أن تتوافق الكاميرا الخلفية الأساسية مع ميزة تثبيت الفيديو بما يتوافق مع مستوى فئة أداء الوسائط الذي تم الإعلان عنه للجهاز.
‫[7.5/H-1-13] يجب أن تتوافق الكاميرا الخلفية الأساسية مع إمكانية LOGICAL_MULTI_CAMERA المحدّدة بمستوى فئة أداء الوسائط المعلَن للجهاز.
[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] يجب أن تتوافق الكاميرات الأساسية مع ميزات التعرّف على الوجوه بما يتوافق مع مستوى فئة أداء الوسائط الذي تم الإعلان عنه للجهاز.
‫[7.5/H-1-18] يجب أن تتوافق الكاميرات الخلفية والأمامية الأساسية مع JPEG_R، وذلك بما يتوافق مع مستوى فئة أداء الوسائط الذي تم الإعلان عنه للجهاز.
‫[7.5/H-1-19] يجب أن تتوافق CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION مع الكاميرا الخلفية الأساسية التي تتوافق مع مستوى فئة أداء الوسائط الذي تم الإعلان عنه للجهاز.
[7.5/H-1-20] يجب أن تعرض كاميرا الجهاز الخلفية الأساسية والكاميرا الأمامية الأساسية في تطبيق الكاميرا الأصلي القيمة JPEG_R تلقائيًا، بما يتوافق مع مستوى فئة أداء الوسائط الذي تم الإعلان عنه للجهاز.

[7.5/H-1-21] يجب أن يتضمّن الجهاز كاميرا واحدة على الأقل مواجهة للأمام أو كاميرا مواجهة للخلف تتوافق مع فئة مستوى أداء الوسائط المحدّدة للجهاز.

‫2.2.7.3. الأجهزة

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

يجب استيفاء متطلبات الأجهزة المُدرَجة في القسم 2.2.7.3 من مستند تعريف التوافق لنظام Android 17 المتوافقة مع مستوى فئة أداء الوسائط المحدّد للجهاز.

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

[7.1.1.1/H-1-1] تم تخطّي هذا العنصر عمدًا.
‫[7.1.1.1/H-2-1] يجب أن تكون درجة دقة الشاشة متوافقة مع مستوى فئة أداء الوسائط المعلَن للجهاز.
[7.1.1.3/H-1-1] تم تخطّي هذا العنصر عمدًا.
[7.1.1.3/H-2-1] يجب أن تتوافق كثافة الشاشة مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[7.1.1.3/H-3-1] يجب أن تتوافق مع متطلبات العرض بنطاق عالي الديناميكية (HDR) التي تتوافق مع مستوى فئة أداء الوسائط المحدَّد للجهاز.
[7.6.1/H-1-1] تم تخطّي هذا العنصر عمدًا.
‫[7.6.1/H-2-1] يجب استيفاء متطلبات الذاكرة التي تتوافق مع فئة مستوى أداء الوسائط المعلَن عنها للجهاز.

‫2.2.7.4. الأداء

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

‫[8.2/H-1-1] يجب التأكّد من توفُّر أداء كتابة تسلسلي يتوافق مع مستوى فئة أداء الوسائط المعلَن للجهاز.
‫[8.2/H-1-2] يجب التأكّد من توفّر أداء كتابة عشوائية يتوافق مع مستوى فئة أداء الوسائط المعلَن عنه للجهاز.
‫[8.2/H-1-3] يجب ضمان أداء قراءة تسلسلية يتوافق مع مستوى فئة أداء الوسائط المعلَن عنه في الجهاز.
‫[8.2/H-1-4] يجب التأكّد من توفّر أداء قراءة عشوائية يتوافق مع فئة مستوى أداء الوسائط المعلَن عنها للجهاز.
‫[8.2/H-1-5] يجب التأكّد من توفُّر أداء متوازٍ للقراءة والكتابة المتسلسلتَين يتوافق مع مستوى فئة أداء الوسائط الذي تم الإعلان عنه للجهاز.

‫2.2.7.5. الرسومات

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

‫[7.1.4.1/H-1-2] يجب أن تتوافق مع إضافات EGL المطلوبة التي تتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.
‫[7.1.4.1/H-1-3] يجب أن تتوافق الأجهزة مع ميزات Vulkan المطلوبة التي تتوافق مع مستوى فئة أداء الوسائط المحدّد للجهاز.

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

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

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

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

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

‫1.3.2. الأجهزة

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

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

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

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

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

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

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

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

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

‫[7.6.1/T-1-1] يجب أن تكون الذاكرة المتاحة لنواة النظام ومساحة المستخدم 896 ميغابايت على الأقل في حال استخدام أي من الكثافات التالية:
- ‫400 نقطة لكل بوصة أو أكثر على الشاشات الصغيرة/العادية
- xhdpi أو أعلى على الشاشات الكبيرة
- tvddpi أو أعلى على الشاشات الكبيرة جدًا

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

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

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

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

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

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

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

[5.1/T-0-4] MPEG-D USAC مع MPEG-D DRC (ترميز 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] يُنصح بشدة بتوفير إمكانية ترميز فيديوهات بدقة 720p و1080p باستخدام H.264 بمعدل 30 لقطة في الثانية.

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

يجب أن تتيح عمليات تنفيذ أجهزة التلفزيون فك ترميز 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 إطارًا في الثانية مع Main Profile
‫[5.3.4/T-1-3] دقة عالية 1080p بمعدل 60 إطارًا في الثانية مع High Profile Level 4.2

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

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

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

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

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

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

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

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

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

[5.3.7/T-2-1] يجب أن تتوافق مع ملف تعريف فك الترميز بدقة UHD بمعدل 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 هرتز للشاشة الخارجية، وذلك حسب معدّل تحديث الفيديو في المنطقة التي يُباع فيها الجهاز.
[‫5.8/T-SR-1] يُنصح بشدة بتوفير أداة اختيار معدّل تحديث HDMI قابلة للضبط من قِبل المستخدم.
[5.8] يجب ضبط معدّل تحديث وضع إخراج HDMI على 50 هرتز أو 60 هرتز، حسب معدّل تحديث الفيديو في المنطقة التي يتم بيع الجهاز فيها.

[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] يجب التحميل المُسبَق لتطبيق واحد أو أكثر أو لمكوّنات خدمة تتضمّن معالج intent، وذلك لجميع أنماط intent filter العامة المحدّدة من خلال نوايا التطبيق التالية المدرَجة هنا.
[3.4.1/T-0-1] يجب توفير تنفيذ كامل لواجهة برمجة التطبيقات android.webkit.Webview.

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

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

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

[3.8.14/T-SR-1] يُنصح بشدة بتوفير وضع النوافذ المتعدّدة في وضع "نافذة ضمن النافذة".
[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] يجب أن يتيح تثبيت محركات تحويل النص إلى كلام تابعة لجهات خارجية.

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

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

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

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

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

[3/T-1-1] يجب أن تتوافق جميع واجهات برمجة التطبيقات في Tuner Framework مع الجهاز، ما يتيح تثبيت أي تطبيق يستخدم هذه الواجهات واستخدامه على الجهاز.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[9.1/T-0-1] يجب عدم منح ACCESS_FINE_LOCATION كإذن تلقائي لهذا التطبيق.

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

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

ملاحظة: لاستيفاء هذا الشرط، يجب مشاركة مفتاح التصديق نفسه لرمز تخزين تعريفي معيّن ما لم يتم إنتاج 100,000 وحدة على الأقل من رمز التخزين التعريفي هذا. إذا تم إنتاج أكثر من 100,000 وحدة من رمز التخزين التعريفي هذا، يمكن استخدام مفتاح مختلف لكل مجموعة من 100,000 وحدة بعد ذلك. بدلاً من ذلك، يمكن استخدام حلّ Remote Key Provisioning لتوفير مفاتيح تصديق قصيرة الأمد للجهاز.

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

[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 "الأذونات" مع معرّف مستند تعريف التوافق [C-3-X] إلى الكاميرا فقط.
[9.8.2/T-5-2] يجب عدم إخفاء مؤشر استخدام الكاميرا لتطبيقات النظام التي تتضمّن واجهات مستخدم مرئية أو تفاعلاً مباشرًا مع المستخدم.

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

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

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

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

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

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

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

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

2.4.1. الأجهزة

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

[7.1.1.1/W-0-1] يجب أن يتضمّن الجهاز شاشة يتراوح حجمها القطري الفعلي بين 1.1 و2.5 بوصة.
‫[7.2.3/W-0-1] يجب أن تتوفّر للمستخدم وظيفة "الصفحة الرئيسية" ووظيفة "رجوع" باستثناء الحالات التي تكون فيها في UI_MODE_TYPE_WATCH.
‫[7.2.4/W-0-1] يجب أن يتيح إدخال البيانات باستخدام شاشة اللمس.
[7.3.1/W-SR-1] يُنصح بشدة بتضمين مقياس تسارع ثلاثي المحاور.

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

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

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

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

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

[7.4.1/W-1-1] يجب الإفصاح عن ميزة android.hardware.telephony.data.

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

[7.4.3/W-0-1] يجب أن تتوافق مع تقنية Bluetooth.
‫[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] يجب التحميل المُسبَق لتطبيق واحد أو أكثر أو لمكوّنات خدمة تتضمّن معالجًا لـ intent، وذلك لجميع أنماط intent filter العامة المحدّدة من خلال intent التطبيقات التالية المدرَجة هنا.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[9.1/W-0-1] يجب عدم منح ACCESS_FINE_LOCATION كإذن تلقائي لهذا التطبيق.

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

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

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

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

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

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

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

[‫9.11.1/W-2-1] يجب استيفاء الشروط التالية لاستدعاء grantTrust() باستخدام هذا العلامة:
- أن يكون الجهاز متصلاً بجهاز أساسي محمول قريب مزوّد بشاشة قفل خاصة به
- أثبت المستخدم هويته باستخدام شاشة القفل أو المقاييس الحيوية من الفئة 3 خلال آخر 30 ثانية.
[9.11.1/W-2-2] يجب ضبط حالة الجهاز على TrustState.TRUSTABLE عندما تتم إزالة الجهاز القابل للارتداء من المعصم أو الجسم ولم يلغِ TrustAgent حالة الثقة.

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

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

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

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

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

‫2.5.1. الأجهزة

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

[7.1.1.1/A-0-1] يجب أن يتضمّن الجهاز شاشة لا يقل حجمها القطري عن 6 بوصات.
[7.1.1.1/A-0-2] يجب أن يتضمّن الجهاز تصميمًا لحجم الشاشة لا يقل عن 750 وحدة بكسل مستقلة عن الكثافة × 480 وحدة بكسل مستقلة عن الكثافة.
‫[7.1.1.1/A-0-3] يجب أن يتيح الجهاز إنشاء تركيبة من مخازن مؤقتة للرسومات باستخدام وحدة معالجة الرسومات (GPU) على الأقل بحجم أعلى دقة لأي شاشة مدمجة.

إذا كانت عمليات تنفيذ أجهزة Automotive تتوافق مع ميزة "استخدام عدة مستخدمين في الوقت نفسه" (حيث يمكن لعدة مستخدمي Android التفاعل مع الجهاز في الوقت نفسه، ويستخدم كل منهم شاشته الخاصة عند تفعيل config_multiuserVisibleBackgroundUsers)، يجب أن تستوفي ما يلي:

[7.1.1.1/A-1-1] يجب أن تتضمّن كل منطقة مخصّصة للركاب شاشة منفصلة لا يقلّ حجمها القطري عن 6 بوصات. يجب وضع العلامة CarOccupantZoneManager.DISPLAY_TYPE_MAIN لكل منطقة مخصّصة للركاب.
[7.1.1.1/A-1-2] يجب أن يتضمّن الجهاز تصميمًا بحجم شاشة لا يقل عن 750 وحدة بكسل مستقل الكثافة × 480 وحدة بكسل مستقل الكثافة لكل شاشة عرض رئيسية.

إذا كانت عمليات تنفيذ أجهزة Automotive تتوافق مع 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 وأن تصدّر جميع الرموز.

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

[7.1.4.2/A-1-1] يجب استيفاء المتطلبات المحدّدة في الملف الشخصي Android Baseline 2021.

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

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

إذا كانت عمليات تنفيذ أجهزة Automotive تعلن عن إتاحة ميزة "التحكّم في السيارة" من خلال إحدى سمات النظام graphics.gpu.profiler.support، يجب أن تستوفي ما يلي:

[7.1.4.6/A-1-1] يجب أن يتم عرض تقرير كناتج يتضمّن تتبُّعًا بتنسيق Protobuf يتوافق مع مخطط عدّادات وحدة معالجة الرسومات ومراحل العرض في وحدة معالجة الرسومات المحدّدة في مستندات Perfetto.
[7.1.4.6/A-1-2] يجب إرسال قيم متوافقة لعدّادات وحدة معالجة الرسومات في الجهاز وفقًا حزمة gpu counter trace الأولية.
[7.1.4.6/A-1-3] يجب عرض قيم متوافقة لمراحل العرض في وحدة معالجة الرسومات بالجهاز وفقًا لحزمة بروتوكول تتبُّع مراحل العرض.
[7.1.4.6/A-1-4] يجب تسجيل نقطة تتبُّع لتردد وحدة معالجة الرسومات (GPU) بالتنسيق التالي: power/gpu_frequency.

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

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

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

‫[7.1.7/A-0-1] يجب ضبط الشاشات الثانوية في مجال رؤية السائق على FLAG_PRIVATE.
‫[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 المستشعر.

[7.3/A-1-1] يجب ضبط قيمة العلامة NIGHT_MODE بشكل متسق مع وضع النهار/الليل في لوحة البيانات على جميع الشاشات، بما في ذلك شاشات المقعد الخلفي.

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

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

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

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

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

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

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

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

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

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

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

[7.3.4/A-4-1] يجب تنفيذ جِهَازُ اسْتِشْعَارْ TYPE_GYROSCOPE_LIMITED_AXES وإعداد تقرير عنه.
[7.3.4/A-4-2] يجب تنفيذ جهاز استشعار TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED والإبلاغ عنه.

إذا كانت عمليات تنفيذ أجهزة Automotive تتضمّن جهاز استقبال GPS/GNSS، ولكنها لا تتضمّن إمكانية الاتصال بالبيانات المستندة إلى شبكة الجوّال، فإنّها:

‫[7.3.3/A-3-1] يجب تحديد الموقع الجغرافي في المرة الأولى التي يتم فيها تشغيل جهاز استقبال نظام تحديد المواقع العالمي (GPS) أو نظام الملاحة العالمي عبر الأقمار الصناعية (GNSS)، أو بعد 4 أيام أو أكثر في غضون 60 ثانية.
[7.3.3/A-3-2] يجب استيفاء معايير وقت تحديد الموقع لأول مرة كما هو موضح في 7.3.3/C-1-2 و7.3.3/C-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 هرتز على الأقل.
يجب أن يشير إلى الشمال الحقيقي.
يجب أن يكون هذا الإجراء متاحًا حتى عندما تكون المركبة متوقفة.
يجب أن تكون درجة الدقة درجة واحدة على الأقل.

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

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

[7.4.3/A-1-1] يجب أن يكون الاختبار مستقلاً وألا يتداخل مع تجربة المستخدمين الآخرين في استخدام البلوتوث.

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

[7.4.5/A] يجب أن يتضمّن دعمًا للاتصال بالبيانات المستند إلى شبكة الجوّال.
[7.4.5/A] يمكن استخدام الثابت System API NetworkCapabilities#NET_CAPABILITY_OEM_PAID للشبكات التي يجب أن تكون متاحة لتطبيقات النظام.

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

[7.4/A-1-1] يجب الإعلان عن دعم FEATURE_BROADCAST_RADIO.

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

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

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

‫[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/A-1-2] يجب أن تكون الكاميرا الأساسية المواجهة للخارج هي الكاميرا المواجهة للخارج التي تحمل أصغر رقم تعريف.

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

‫[7.5/A-2-1] يجب أن تكون الكاميرا الأساسية المواجهة للمستخدم هي الكاميرا المواجهة للمستخدم التي تحمل أصغر رقم تعريف.
يجب أن يكون اتجاهها بحيث يتوافق البُعد الأطول للكاميرا مع مستوى X-Y لمحاور أجهزة الاستشعار في Android Automotive.

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

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

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

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

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

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

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

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

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

‫[7.5/A-7-1] يجب تنفيذ واجهة برمجة تطبيقات الكاميرا هذه باستخدام واجهة برمجة التطبيقات android.hardware.camera2 أو واجهة برمجة التطبيقات Extended View System API.

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

‫[7.6.1/A-0-1] يجب أن تتوفّر مساحة تخزين غير متطايرة بسعة 4 غيغابايت على الأقل لبيانات التطبيق الخاصة (قسم /data).
[7.6.1/A] يجب تنسيق قسم البيانات لتحسين الأداء وإطالة عمر التخزين المؤقت (على سبيل المثال، باستخدام نظام الملفات f2fs).

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

[7.6.1/A-SR-1] يُنصح بشدة بتقليل وقت المعالجة المطلوب لإجراء عمليات الإدخال/الإخراج على وحدة التخزين الخارجية، مثلاً من خلال استخدام SDCardFS.

‫[7.6.1/A-1-1] يجب أن تتوفّر في مثيل واحد من AAOS مساحة تخزين غير متطايرة لا تقل عن 4 غيغابايت لكل مستخدم Android متزامن، وتكون هذه المساحة متاحة لبيانات التطبيقات الخاصة (القسم /data).

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

[7.6.1/A-2-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 816 ميغابايت على الأقل لكل شاشة عرض رئيسية في حال استخدام أي من الكثافات التالية:
- ‫280 نقطة لكل بوصة أو أقل على الشاشات الصغيرة/العادية
- ldpi أو أقل على الشاشات الكبيرة جدًا
- mdpi أو أقل على الشاشات الكبيرة
‫[7.6.1/A-2-2] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 944 ميغابايت على الأقل لكل شاشة عرض رئيسية في حال استخدام أي من الكثافات التالية:
- xhdpi أو أعلى على الشاشات الصغيرة/العادية
- hdpi أو أعلى على الشاشات الكبيرة
- mdpi أو أعلى على الشاشات الكبيرة جدًا
‫[7.6.1/A-2-3] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 1280 ميغابايت على الأقل لكل شاشة عرض رئيسية في حال استخدام أي من الكثافات التالية:
- ‫400 نقطة لكل بوصة أو أكثر على الشاشات الصغيرة/العادية
- xhdpi أو أعلى على الشاشات الكبيرة
- tvddpi أو أعلى على الشاشات الكبيرة جدًا
‫[7.6.1/A-2-4] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 1824 ميغابايت على الأقل لكل شاشة عرض رئيسية في حال استخدام أي من الكثافات التالية:
- ‫560 نقطة لكل بوصة أو أكثر على الشاشات الصغيرة/العادية
- 400 نقطة في البوصة أو أكثر على الشاشات الكبيرة
- xhdpi أو أعلى على الشاشات الكبيرة جدًا

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

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

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

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

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

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

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

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

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

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

[7.8.2/A-1-1] يجب توفير مصدر إخراج الصوت لكل شاشة عرض رئيسية في أنظمة تعدُّد المستخدمين المتزامنة.
[7.8.2/A-1-2] يجب أن تتضمّن السيارة منطقة صوتية خاصة بالسائق تغطي مكبّر الصوت العام في المقصورة. يمكن لمنطقة الراكب الأمامي مشاركة منطقة الصوت الخاصة بالسائق أو يمكن أن يكون لها مصدر إخراج صوت خاص بها.

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

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

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

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

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

‫[5.1/A-0-4] MPEG-D USAC مع MPEG-D DRC (ترميز 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

[5.5.3/A-1-1] يجب تحديد منحنيات مستوى صوت متطابقة لجميع مصادر إخراج الصوت التي يتم ربطها بمجموعة مستوى الصوت نفسها على النحو المحدّد في ملف إعدادات صوت السيارة.

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

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

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

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

[3.2.1/A-0-1] يجب أن تتوافق مع جميع ثوابت الأذونات وأن تفرضها على النحو الموضّح في صفحة مرجع أذونات السيارات.
[3.2.3.1/A-0-1] يجب التحميل مسبقًا لتطبيق واحد أو أكثر أو لمكوّنات خدمة تتضمّن معالج intent، وذلك لجميع أنماط intent filter العامة المحدّدة من خلال intents التطبيقات التالية المدرَجة هنا.
[3.2.3.1/A-0-2] يجب أن يتضمّن الجهاز تطبيقًا يتعامل مع أغراض ACTION_GET_CONTENT وACTION_OPEN_DOCUMENT وACTION_OPEN_DOCUMENT_TREE وACTION_CREATE_DOCUMENT كما هو موضّح في مستندات حزمة SDK، وأن يوفّر للمستخدم إمكانية الوصول إلى بيانات موفّر المستندات باستخدام واجهة برمجة التطبيقات DocumentsProvider.

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

[3.2.3.1/A-1-1] يجب أن يتضمّن التطبيق نشاطًا يعالج الغرض Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY عند تفعيل وظيفة التقسيم. يجب أن يكون النشاط محميًا بواسطة android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK، ويجب أن يبدأ نشاط Intent الذي تم تحليله من Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.
‫[3.4.1/A-0-1] يجب توفير تنفيذ كامل لواجهة برمجة التطبيقات android.webkit.Webview.

[3.8/A-1-1] يجب تنفيذ القائمة المحدّدة مسبقًا التالية من UserRestrictions للمستخدمين الثانويين الكاملين الذين ليسوا المستخدمين الحاليين في المقدّمة، ولكن لديهم إذن الوصول إلى واجهة المستخدم على الشاشة المخصّصة لهم. قائمة UserRestrictions هي DISALLOW_CONFIG_LOCALE و DISALLOW_CONFIG_BLUETOOTH و DISALLOW_BLUETOOTH و DISALLOW_CAMERA_TOGGLE و DISALLOW_MICROPHONE_TOGGLE.
[3.8/A-1-2] يجب عدم السماح للمستخدمين الثانويين الكاملين الذين ليسوا المستخدمين الحاليين في المقدّمة ولكن لديهم إذن الوصول إلى واجهة المستخدم على الشاشة المخصّصة لهم بتغيير وضع النهار/الليل أو اللغة أو التاريخ أو الوقت أو المنطقة الزمنية أو ميزات ألوان الشاشة (بما في ذلك "السطوع" و"الإضاءة الليلية" و"الرفاهية الرقمية" بالأبيض والأسود و"تقليل الألوان الساطعة") لأي مستخدم آخر من خلال "الإعدادات" أو من خلال واجهة برمجة تطبيقات.

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

[3.8.3/A-0-1] يجب عرض الإشعارات التي تستخدم واجهة برمجة التطبيقات Notification.CarExtender عند طلبها من تطبيقات تابعة لجهات خارجية.
‫[3.8.4/A-SR-1] يُنصح بشدة بتنفيذ مساعد على الجهاز للتعامل مع إجراء المساعدة.

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

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

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

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

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

[3.9.3/A-1-1] يجب تنفيذ جميع سمات مراحل نشاط المستخدم: INITIAL_USER_INFO وSWITCH_USER وCREATE_USER وREMOVE_USER.

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

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

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

[3.14/A-0-8] يجب الإعلان عن علامة الميزة android.software.car.templates_host.
[3.14/A-0-9] يجب الإعلان عن علامة الميزة com.android.car.background_audio_while_driving.
[3.14/A-0-10] يجب الإعلان عن علامة الميزة android.software.car.templates_host.media.

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

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

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

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

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

[7.1.1/A-0-1] يجب الإعلان عن علامة الميزة android.software.car.display_compatibility.

أثناء تشغيل التطبيقات في المقدّمة باستخدام ميزة android.software.car.display_compatibility أو التطبيقات بدون ميزة android.hardware.type.automotive، يجب مراعاة ما يلي في أجهزة السيارات:

‫[7.1.1/A-1-1] يجب توفير وظيفة "الرجوع".

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

[7.4.1.2/A-1-1] يجب الإعلان عن علامة الميزة android.software.telecom.

[7.4.1.2/A-1-2] يجب تنفيذ إطار عمل الاتصالات.

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

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

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

[8.2/A-0-1] يجب تسجيل عدد وحدات البايت التي تمت قراءتها وكتابتها في وحدة التخزين غير المتطايرة لكل معرّف مستخدم (UID) خاص بكل عملية، وذلك حتى يتمكّن المطوّرون من الوصول إلى الإحصاءات من خلال واجهة برمجة التطبيقات android.car.storagemonitoring.CarStorageMonitoringManager. يستوفي "مشروع مفتوح المصدر لنظام Android" هذا الشرط من خلال وحدة النواة uid_sys_stats.
[8.2/A-0-2] يجب ضمان أداء كتابة تسلسلي لا يقل عن 5 ميغابايت/ثانية.
[8.2/A-0-3] يجب ضمان أداء كتابة عشوائية لا يقل عن 0.5 ميغابايت/ثانية.
[8.2/A-0-4] يجب ضمان أداء قراءة تسلسلية لا يقل عن 15 ميغابايت/ثانية.
[8.2/A-0-5] يجب ضمان أداء قراءة عشوائية لا يقل عن 3.5 ميغابايت/ثانية.

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

[8.2/A-1-1] يجب ضمان أداء كتابة تسلسلي يبلغ 150 ميغابايت في الثانية على الأقل.
[8.2/A-1-2] يجب ضمان أداء كتابة عشوائية لا يقل عن 10 ميغابايت/ثانية.
[8.2/A-1-3] يجب ضمان أداء قراءة تسلسلية لا يقل عن 250 ميغابايت في الثانية.
[8.2/A-1-4] يجب ضمان أداء قراءة عشوائية لا يقل عن 100 ميغابايت/ثانية.
[8.2/A-1-5] يجب ضمان أداء قراءة وكتابة متوازٍ ومتسلسل بمعدّل قراءة مضاعف ومعدّل كتابة واحد، وبمعدّل 50 ميغابايت في الثانية على الأقل.
[8.3/A-1-3] يجب أن يتوافق مع وضع المرآب.
[8.3/A] يجب أن يكون الجهاز في "وضع المرآب" لمدة 15 دقيقة على الأقل بعد كل رحلة ما لم:
- تم استنزاف شحن البطارية.
- لا تتم جدولة أي مهام غير نشطة.
- يخرج السائق من "وضع المرآب".
[8.4/A-0-1] يجب توفير ملف تعريف طاقة لكل مكوّن يحدّد قيمة استهلاك التيار لكل مكوّن من مكوّنات الجهاز ومعدّل استنزاف البطارية التقريبي الذي تسبّبه المكوّنات بمرور الوقت كما هو موضّح في موقع "مشروع مفتوح المصدر لنظام Android".
[8.4/A-0-2] يجب عرض جميع قيم استهلاك الطاقة بوحدة ميلي أمبير في الساعة (mAh).
[8.4/A-0-3] يجب تسجيل استهلاك طاقة وحدة المعالجة المركزية (CPU) لكل معرّف UID خاص بكل عملية. يستوفي "مشروع Android المفتوح المصدر" هذا الشرط من خلال تنفيذ وحدة النواة uid_cputime.
[8.4/A] يجب أن يتم تحديد مصدرها على أنّه مكوّن الجهاز نفسه إذا تعذّر تحديد مصدر استهلاك الطاقة لأحد التطبيقات.
‫[8.4/A-0-4] يجب إتاحة معلومات استهلاك الطاقة هذه لمطوّر التطبيق من خلال أمر adb shell dumpsys batterystats في واجهة سطر الأوامر.

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

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

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

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

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

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

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

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

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

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

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

ملاحظة: لاستيفاء هذا الشرط، يجب مشاركة مفتاح التصديق نفسه لرمز تخزين تعريفي معيّن ما لم يتم إنتاج 100,000 وحدة على الأقل من رمز التخزين التعريفي هذا. إذا تم إنتاج أكثر من 100,000 وحدة من رمز التخزين التعريفي هذا، يمكن استخدام مفتاح مختلف لكل مجموعة من 100,000 وحدة بعد ذلك. بدلاً من ذلك، يمكن استخدام حلّ Remote Key Provisioning لتوفير مفاتيح تصديق قصيرة الأمد للجهاز.

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

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

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

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

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

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

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

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

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

2.6.1. الأجهزة

الجيروسكوب

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

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

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

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

وضع الواقع الافتراضي (الفقرة 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] يجب التحميل المُسبَق لتطبيق واحد أو أكثر أو لمكوّنات خدمة تتضمّن معالج intent، وذلك لجميع أنماط intent filter العامة المحدّدة من خلال intents التطبيقات التالية المدرَجة هنا.

3- برامج

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

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

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

[C-0-1] يجب توفير عمليات تنفيذ كاملة، بما في ذلك جميع السلوكيات الموثّقة، لأي واجهة برمجة تطبيقات موثّقة يتم عرضها من خلال حزمة تطوير البرامج (SDK) لنظام التشغيل Android أو أي واجهة برمجة تطبيقات مزيّنة بعلامة "‎@SystemApi" في رمز المصدر العلوي لنظام التشغيل Android.
[C-0-2] يجب أن تتوافق/تحتفظ بجميع الفئات والطرق والعناصر المرتبطة بها التي تم وضع علامة عليها باستخدام التعليق التوضيحي TestApi (@TestApi).
[C-0-3] يجب عدم حذف أي واجهات برمجة تطبيقات مُدارة أو تغيير واجهات برمجة التطبيقات أو توقيعاتها أو الانحراف عن السلوك الموثّق أو تضمين عمليات غير ضرورية، إلا في الحالات التي يسمح بها تعريف التوافق هذا على وجه التحديد.
[C-0-4] يجب أن تظل واجهات برمجة التطبيقات متوفرة وتعمل بشكل معقول، حتى عند حذف بعض ميزات الأجهزة التي يتضمّنها نظام التشغيل Android. راجِع الفقرة 7 لمعرفة المتطلبات المحدّدة لهذا السيناريو.
[C-0-5] يجب عدم السماح لتطبيقات الجهات الخارجية باستخدام واجهات غير متوفرة في حزمة SDK، ويُقصد بها الطرق والحقول في حِزم لغة Java التي تقع في مسار فئة التمهيد في مشروع Android مفتوح المصدر (AOSP)، والتي لا تشكّل جزءًا من حزمة SDK العامة. ويشمل ذلك واجهات برمجة التطبيقات التي تم تزيينها بالتعليق التوضيحي @hide ولكن ليس بالتعليق التوضيحي @SystemAPI، كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) وأعضاء الفئات الخاصة وعلى مستوى الحزمة.
[C-0-6] يجب أن يتم شحنها مع كل واجهة غير تابعة لحزمة تطوير البرامج (SDK) في القوائم المحظورة نفسها التي يتم توفيرها من خلال علامات القائمة المؤقتة وقائمة الحظر في مسار prebuilts/runtime/appcompat/hiddenapi-flags.csv لمستوى واجهة برمجة التطبيقات المناسب في مشروع Android المفتوح المصدر (AOSP).
[C-0-7] يجب أن تتوافق مع آلية التعديل الديناميكي لإعدادات التكوين الموقَّعة لإزالة الواجهات غير المتوفّرة في حزمة SDK من قائمة محظورة من خلال تضمين إعدادات التكوين الموقَّعة في أي حزمة APK، باستخدام المفاتيح العامة الحالية المتوفّرة في مشروع Android مفتوح المصدر (AOSP).

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

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

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] يجب ألا تعرض إلا رقم إصدار صالحًا للامتداد تم تعريفه بواسطة مشروع Android المفتوح المصدر (AOSP).
[C-0-3] يجب أن تتوافق مع جميع واجهات برمجة التطبيقات المحدّدة في إصدارات الإضافة التي تعرضها android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) بالطريقة نفسها التي تتوافق بها مع واجهات برمجة التطبيقات المُدارة الأخرى، وذلك وفقًا للمتطلبات الواردة في الفقرة 3.1.

3.1.2. مكتبة Android

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

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

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

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

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

3.2.1. الأذونات

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

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

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

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

المَعلمة	التفاصيل
VERSION.RELEASE	إصدار نظام التشغيل Android الذي يتم تنفيذه حاليًا، بتنسيق يمكن للمستخدمين قراءته يجب أن يحتوي هذا الحقل على إحدى قيم السلسلة المحدّدة في سلاسل الإصدارات المسموح بها لنظام التشغيل Android 17.
VERSION.SDK	يمثّل هذا الحقل إصدار نظام التشغيل Android الذي يتم تنفيذه حاليًا، وذلك بتنسيق يمكن الوصول إليه من خلال الرمز البرمجي للتطبيق التابع لجهة خارجية. في نظام التشغيل Android 17، يجب أن يحتوي هذا الحقل على القيمة الصحيحة 17_INT.
VERSION.SDK&lowbar;INT	يمثّل هذا الحقل إصدار نظام التشغيل Android الذي يتم تنفيذه حاليًا، وذلك بتنسيق يمكن الوصول إليه من خلال الرمز البرمجي للتطبيق التابع لجهة خارجية. في Android 17، يجب أن يحتوي هذا الحقل على القيمة الصحيحة 17&lowbar;INT.
VERSION.INCREMENTAL	قيمة يختارها مطوّر الجهاز لتحديد الإصدار المحدّد من نظام Android الذي يتم تنفيذه حاليًا، وذلك بتنسيق يمكن للمستخدمين قراءته. ويجب عدم إعادة استخدام هذه القيمة في إصدارات مختلفة يتم توفيرها للمستخدمين النهائيين. يُستخدَم هذا الحقل عادةً للإشارة إلى رقم الإصدار أو معرّف تغيير نظام التحكّم بالمصادر الذي تم استخدامه لإنشاء الإصدار. يجب أن تكون قيمة هذا الحقل قابلة للترميز كـ ASCII قابل للطباعة من 7 بت وأن تتطابق مع التعبير العادي `^[^ :\/~]+$`.
ألعاب ألواح	قيمة يختارها مطوّر الجهاز لتحديد الأجهزة الداخلية المحدّدة التي يستخدمها الجهاز، وذلك بتنسيق يمكن للمستخدمين قراءته. من الاستخدامات المحتملة لهذا الحقل الإشارة إلى المراجعة المحدّدة للوحة التي تشغّل الجهاز. يجب أن تكون قيمة هذا الحقل قابلة للترميز باستخدام ASCII ذي 7 بتات وأن تتطابق مع التعبير العادي `^[a-zA-Z0-9_-]+$`.
العلامة التجارية	قيمة تعكس اسم العلامة التجارية المرتبط بالجهاز كما يعرفه المستخدمون النهائيون. يجب أن يكون بالتنسيق القابل للقراءة ويجب أن يمثّل الشركة المصنّعة للجهاز أو العلامة التجارية للشركة التي يتم تسويق الجهاز بموجبها. يجب أن تكون قيمة هذا الحقل قابلة للترميز باستخدام ASCII ذي 7 بت وأن تتطابق مع التعبير العادي `^[a-zA-Z0-9_-]+$`.
SUPPORTED&lowbar;ABIS	اسم مجموعة التعليمات (نوع وحدة المعالجة المركزية + اصطلاح واجهة التطبيق الثنائية (ABI)) للرمز البرمجي الأصلي يُرجى الاطّلاع على الفقرة 3.3. توافق واجهة برمجة التطبيقات الأصلية
SUPPORTED&lowbar;32&lowbar;BIT&lowbar;ABIS	اسم مجموعة التعليمات (نوع وحدة المعالجة المركزية + اصطلاح واجهة التطبيق الثنائية (ABI)) للرمز البرمجي الأصلي يُرجى الاطّلاع على الفقرة 3.3. توافق واجهة برمجة التطبيقات الأصلية
SUPPORTED&lowbar;64&lowbar;BIT&lowbar;ABIS	تمثّل هذه السمة اسم مجموعة التعليمات الثانية (نوع وحدة المعالجة المركزية + اصطلاح واجهة التطبيق الثنائية (ABI)) للرمز البرمجي الأصلي. يُرجى الاطّلاع على الفقرة 3.3. توافق واجهة برمجة التطبيقات مع التطبيقات الأصلية
CPU&lowbar;ABI	اسم مجموعة التعليمات (نوع وحدة المعالجة المركزية + اصطلاح واجهة التطبيق الثنائية (ABI)) للرمز البرمجي الأصلي يُرجى الاطّلاع على الفقرة 3.3. توافق واجهة برمجة التطبيقات الأصلية
CPU&lowbar;ABI2	تمثّل هذه السمة اسم مجموعة التعليمات الثانية (نوع وحدة المعالجة المركزية + اصطلاح واجهة التطبيق الثنائية (ABI)) للرمز البرمجي الأصلي. يُرجى الاطّلاع على الفقرة 3.3. توافق واجهة برمجة التطبيقات مع التطبيقات الأصلية
الجهاز	قيمة يختارها مطوّر الجهاز وتحتوي على الاسم التطويري أو الاسم الرمزي الذي يحدّد إعدادات ميزات الأجهزة والتصميم الصناعي للجهاز. يجب أن تكون قيمة هذا الحقل قابلة للترميز باستخدام ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي `^[a-zA-Z0-9_-]+$`. يجب ألا يتغيّر اسم الجهاز هذا خلال عمر المنتج.
FINGERPRINT	سلسلة تحدّد هذا الإصدار بشكل فريد. يجب أن يكون النص قابلاً للقراءة بشكل معقول. يجب أن يتبع هذا النموذج: $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) على سبيل المثال: acme/myproduct/ mydevice:17/LMYXX/3359:userdebug/test-keys يجب ألا تتضمّن البصمة الرقمية مسافات بيضاء. يجب أن تكون قيمة هذا الحقل قابلة للترميز باستخدام ASCII ذي 7 بت.
الأجهزة	اسم الجهاز (من سطر أوامر النواة أو /proc) ويجب أن تكون قابلة للقراءة بشكل معقول. يجب أن تكون قيمة هذا الحقل قابلة للترميز باستخدام ASCII ذي 7 بت وأن تتطابق مع التعبير العادي `^[a-zA-Z0-9_-]+$`.
HOST	سلسلة تحدّد بشكل فريد المضيف الذي تم إنشاء الإصدار عليه، وذلك بتنسيق يمكن للمستخدم قراءته. لا توجد متطلبات بشأن التنسيق المحدّد لهذا الحقل، باستثناء أنّه يجب ألا يكون فارغًا أو سلسلة فارغة ("").
رقم التعريف	معرّف يختاره مطوّر الجهاز للإشارة إلى إصدار معيّن، ويكون بتنسيق يمكن قراءته. يمكن أن يكون هذا الحقل هو نفسه android.os.Build.VERSION.INCREMENTAL، ولكن يجب أن تكون القيمة ذات دلالة كافية للمستخدمين النهائيين للتمييز بين إصدارات البرامج. يجب أن تكون قيمة هذا الحقل قابلة للترميز باستخدام ASCII ذي 7 بت وأن تتطابق مع التعبير العادي `^[a-zA-Z0-9._-]+$`.
الشركة المصنّعة	الاسم التجاري للمصنّع الأصلي للجهاز (OEM) الخاص بالمنتج لا توجد متطلبات بشأن التنسيق المحدّد لهذا الحقل، باستثناء أنّه يجب ألا تكون قيمته فارغة أو السلسلة الفارغة ("")، ويجب ألا يتغيّر هذا الحقل خلال مدة توفّر المنتج.
SOC&lowbar;MANUFACTURER	تمثّل هذه السمة اسم العلامة التجارية للشركة المصنّعة لنظام التشغيل الأساسي على الرقاقة (SOC) المستخدَم في المنتج. يجب أن تستخدم الأجهزة التي تحمل اسم الشركة المصنّعة نفسها للمنظومة على الرقاقة (SOC) القيمة الثابتة نفسها. يُرجى التواصل مع الشركة المصنّعة لنظام SOC للحصول على الثابت الصحيح الذي يجب استخدامه. يجب أن تكون قيمة هذا الحقل قابلة للترميز باستخدام ASCII المكوّن من 7 بت، ويجب أن تتطابق مع التعبير العادي `^([0-9A-Za-z ]+)`، ويجب ألّا تبدأ أو تنتهي بمسافة بيضاء، ويجب ألّا تكون مساوية للقيمة "unknown". يجب ألا يتغير هذا الحقل خلال مدة توفّر المنتج.
SOC&lowbar;MODEL	اسم طراز المنظومة الأساسية على رقاقة (SOC) المستخدَمة في المنتج. يجب أن تستخدم الأجهزة التي تتضمّن طراز SOC نفسه القيمة الثابتة نفسها. يُرجى التواصل مع الشركة المصنّعة لنظام SOC للحصول على الثابت الصحيح الذي يجب استخدامه. يجب أن تكون قيمة هذا الحقل قابلة للترميز باستخدام ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي `^([0-9A-Za-z ._/+-]+)$`، ويجب ألّا تبدأ أو تنتهي بمسافة بيضاء، ويجب ألّا تكون مساوية للقيمة "unknown". يجب ألا يتغير هذا الحقل خلال مدة توفّر المنتج.
MODEL	قيمة يختارها مطوّر الجهاز تتضمّن اسم الجهاز كما يظهر للمستخدم النهائي. يجب أن يكون هذا الاسم هو نفسه الاسم الذي يتم تسويق الجهاز وبيعه للمستخدمين النهائيين بموجبه. لا توجد متطلبات بشأن التنسيق المحدّد لهذا الحقل، باستثناء أنّه يجب ألا تكون قيمته فارغة أو السلسلة الفارغة (""). يُنصح بشدة بعدم تغيير قيمة هذا الحقل خلال مدة توفّر المنتج.
المنتج	قيمة يختارها منفِّذ الجهاز تتضمّن الاسم التطويري أو الاسم الرمزي للمنتج المحدّد (رمز التخزين التعريفي) الذي يجب أن يكون فريدًا ضمن العلامة التجارية نفسها. يجب أن يكون قابلاً للقراءة من قِبل الإنسان، ولكن ليس بالضرورة أن يكون مخصّصًا للعرض للمستخدمين النهائيين. يجب أن تكون قيمة هذا الحقل قابلة للترميز باستخدام ASCII ذي 7 بتات وأن تتطابق مع التعبير العادي `^[a-zA-Z0-9_-]+$`. يجب ألا يتغيّر اسم المنتج هذا خلال فترة صلاحيته.
ODM&lowbar;SKU	قيمة اختيارية يختارها مطوّر الجهاز وتحتوي على رمز التخزين التعريفي (SKU) المستخدَم لتتبُّع إعدادات معيّنة للجهاز، مثل أي أجهزة ملحقة مضمّنة مع الجهاز عند بيعه. يجب أن تكون قيمة هذا الحقل قابلة للترميز باستخدام ASCII ذي 7 بت وأن تتطابق مع التعبير العادي `^([0-9A-Za-z.,_-]+)$`.
SERIAL	يجب أن تعرض القيمة "UNKNOWN".
العلامات	تمثّل هذه السمة قائمة قيم مفصولة بفاصلة من العلامات اختارها مطوّر الجهاز لتحديد الإصدار بشكل أكبر. يجب أن تكون العلامات قابلة للترميز بتنسيق ASCII ذي 7 بت وأن تتطابق مع التعبير العادي `^[a-zA-Z0-9._-]+`، ويجب أن تتضمّن إحدى القيم المتوافقة مع إعدادات التحقق الثلاثة الشائعة لنظام Android الأساسي: release-keys وdev-keys وtest-keys.
الوقت	قيمة تمثّل الطابع الزمني لوقت حدوث الإنشاء.
النوع	قيمة يختارها منفِّذ الجهاز لتحديد إعدادات وقت التشغيل للنسخة. يجب أن يحتوي هذا الحقل على إحدى القيم التي تتوافق مع إعدادات وقت التشغيل الثلاثة الشائعة لنظام Android: user أو userdebug أو eng.
المستخدم	اسم أو معرّف المستخدم (أو المستخدم الآلي) الذي أنشأ الإصدار لا توجد متطلبات بشأن التنسيق المحدّد لهذا الحقل، باستثناء أنّه يجب ألا يكون قيمة فارغة أو سلسلة فارغة ("").
SECURITY&lowbar;PATCH	قيمة تشير إلى مستوى رمز تصحيح الأمان لإصدار معيّن. ويجب أن يشير إلى أنّ الإصدار ليس عرضة بأي شكل من الأشكال لأي من المشاكل الموضّحة في "نشرة أمان Android العامة" المحدّدة. يجب أن يكون بالتنسيق [YYYY-MM-DD]، وأن يتطابق مع سلسلة محدّدة موثّقة في نشرة أمان Android العامة أو في إشعار أمان Android، مثل "2015-11-01".
BASE&lowbar;OS	قيمة تمثّل المَعلمة FINGERPRINT للإصدار الذي يكون مطابقًا لهذا الإصدار باستثناء حِزم التصحيح المتوفّرة في "نشرة أمان Android العلنية". ويجب أن تعرض القيمة الصحيحة، وإذا لم يكن هذا الإصدار متوفّرًا، يجب عرض سلسلة فارغة ("").
برنامج الإقلاع	قيمة يختارها مطوّر الجهاز وتحدّد إصدار برنامج الإقلاع الداخلي المحدّد المستخدَم في الجهاز، وذلك بتنسيق يمكن لشخص عادي قراءته. يجب أن تكون قيمة هذا الحقل قابلة للترميز باستخدام ASCII ذي 7 بت وأن تتطابق مع التعبير العادي `^[a-zA-Z0-9._-]+$`.
getRadioVersion()	يجب أن تكون القيمة التي تعرضها هذه السمة هي قيمة يختارها مطوّر الجهاز وتحدّد إصدار الراديو/المودم الداخلي المستخدَم في الجهاز، ويجب أن تكون بالتنسيق الذي يمكن للمستخدمين قراءته. إذا لم يكن الجهاز مزوّدًا بأي جهاز راديو/مودم داخلي، يجب أن يعرض القيمة NULL. يجب أن تكون قيمة هذا الحقل قابلة للترميز باستخدام ASCII ذي 7 بت وأن تتطابق مع التعبير العادي `^[a-zA-Z0-9._-,]+$`.
getSerial()	يجب أن يكون (أو يعرض) رقمًا تسلسليًا للأجهزة، ويجب أن يكون متاحًا وفريدًا على مستوى الأجهزة التي تحمل MODEL وMANUFACTURER نفسيهما. يجب أن تكون قيمة هذا الحقل قابلة للترميز باستخدام ASCII ذي 7 بت وأن تتطابق مع التعبير العادي `^[a-zA-Z0-9]+$`.
STRONGBOX&lowbar;MANUFACTURER	الاسم التجاري للشركة المصنّعة لشريحة StrongBox المستخدَمة في المنتج يوفّر مورّد StrongBox الثابت الصحيح. يجب أن تستخدم الأجهزة التي لديها المورّد نفسه لـ StrongBox القيمة الثابتة نفسها. يجب أن تتطابق قيمة هذا الحقل مع التعبير العادي `^([0-9A-Za-z ]+)`، ويجب ألا تكون مساوية للقيمة "unsupported". يجب ألا يتغير هذا الحقل خلال مدة توفّر المنتج.
STRONGBOX&lowbar;MODEL	اسم طراز شريحة StrongBox المستخدَمة في المنتج: يوفّر مورّد StrongBox الثابت الصحيح. يجب أن تستخدم الأجهزة التي لديها مورّد StrongBox نفسه القيمة الثابتة نفسها. يجب أن تتطابق قيمة هذا الحقل مع التعبير العادي `^([0-9A-Za-z ._/+-]+)$`، ويجب ألا تكون مساوية للقيمة "unsupported". يجب ألا يتغير هذا الحقل خلال مدة توفّر المنتج.

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

3.2.3.1. أهداف التطبيقات الشائعة

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

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

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

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

‫3.2.3.2. حلّ النية

[C-0-1] بما أنّ Android نظام أساسي قابل للتوسيع، يجب أن تسمح عمليات تنفيذ الأجهزة بتجاوز كل نمط من أنماط intent المشار إليها في الفقرة 3.2.3.1، باستثناء الإعدادات، من خلال تطبيقات تابعة لجهات خارجية. تسمح عملية التنفيذ المفتوحة المصدر لنظام التشغيل Android بذلك تلقائيًا.
[C-0-2] يجب ألا يمنح مطوّرو الأجهزة امتيازات خاصة لتطبيقات النظام عند استخدام أنماط الأهداف هذه، أو يمنعوا التطبيقات التابعة لجهات خارجية من الربط بهذه الأنماط والتحكّم فيها. ويشمل هذا الحظر على وجه التحديد، على سبيل المثال لا الحصر، إيقاف واجهة المستخدم "أداة الاختيار" التي تتيح للمستخدم الاختيار بين تطبيقات متعددة تتعامل جميعها مع نمط الغرض نفسه.
[C-0-3] يجب أن توفّر عمليات تنفيذ الأجهزة واجهة مستخدم تتيح للمستخدمين تعديل النشاط التلقائي للأهداف.
ومع ذلك، قد توفّر عمليات تنفيذ الأجهزة أنشطة تلقائية لأنماط URI معيّنة (مثل http://play.google.com) عندما يوفّر النشاط التلقائي سمة أكثر تحديدًا لعنوان URI الخاص بالبيانات. على سبيل المثال، يكون نمط intent filter الذي يحدّد معرّف الموارد المنتظم للبيانات "http://www.android.com" أكثر تحديدًا من نمط intent الأساسي للمتصفّح الذي يحدّد "http://".

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

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

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

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

‫3.2.3.4. Broadcast Intents

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

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

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

‫3.2.3.5. Conditional Application Intents

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

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

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

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

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

[C-2-1] يجب توفير قائمة إعدادات تستدعي الغرض android.provider.Telephony.ACTION_CHANGE_DEFAULT لعرض مربّع حوار لتغيير تطبيق SMS التلقائي.
[C-2-2] يجب الالتزام بطلب android.telecom.action.CHANGE_DEFAULT_DIALER لعرض مربّع حوار يتيح للمستخدم تغيير تطبيق "الهاتف" التلقائي.
- يجب استخدام واجهة المستخدم لتطبيق "الهاتف" التلقائي الذي يختاره المستخدم للمكالمات الواردة والصادرة، باستثناء مكالمات الطوارئ التي سيتم إجراؤها باستخدام تطبيق "الهاتف" المثبَّت مسبقًا.
[C-2-3] يجب أن يستجيب التطبيق للغرض android.telecom.action.CHANGE_PHONE_ACCOUNTS لتوفير إمكانية للمستخدمين من أجل ضبط ConnectionServices المرتبط PhoneAccounts، بالإضافة إلى حساب PhoneAccount تلقائي سيستخدمه مقدّم خدمة الاتصالات لإجراء المكالمات الصادرة. يتوافق تطبيق AOSP مع هذا الشرط من خلال تضمين قائمة "خيارات حسابات الاتصال" ضمن قائمة إعدادات "المكالمات".
[C-2-4] يجب السماح باستخدام android.telecom.CallRedirectionService في تطبيق لديه الدور android.app.role.CALL_REDIRECTION.
[C-2-5] يجب توفير أداة تحكّم للمستخدم لاختيار تطبيق لديه الدور android.app.role.CALL_REDIRECTION.
[C-2-6] يجب أن يلتزم التطبيق بتنفيذ الغرضين android.intent.action.SENDTO وandroid.intent.action.VIEW وأن يوفّر نشاطًا لإرسال رسائل SMS وعرضها.
[C-SR-1] يُنصح بشدة بتنفيذ أغراض android.intent.action.ANSWER وandroid.intent.action.CALL وandroid.intent.action.CALL_BUTTON وandroid.intent.action.VIEW وandroid.intent.action.DIAL باستخدام تطبيق لوحة الاتصال مثبَّت مسبقًا يمكنه التعامل مع هذه الأغراض وتوفير التنفيذ كما هو موضّح في حزمة تطوير البرامج (SDK).

إذا كان تقرير عمليات تنفيذ الأجهزة 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، يعني ذلك ما يلي:

[C-4-1] يجب أن يلتزم الجهاز بهذه الأهداف android.nfc.action.NDEF_DISCOVERED وandroid.nfc.action.TAG_DISCOVERED وandroid.nfc.action.TECH_DISCOVERED، لعرض نشاط يلبّي توقعات المطوّرين بشأن هذه الأهداف كما هو موضّح في حزمة تطوير البرامج (SDK).

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

[C-5-1] يجب الاستجابة لطلب 'android.bluetooth.adapter.action.REQUEST_ENABLE' وعرض نشاط النظام للسماح للمستخدم بتفعيل البلوتوث.
[C-5-2] يجب أن يستجيب الجهاز لطلب 'android.bluetooth.adapter.action.REQUEST_DISCOVERABLE' وأن يعرض نشاطًا على النظام يطلب تفعيل وضع العثور على الجهاز.

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

[C-6-1] يجب تنفيذ نشاط يستجيب للغرض 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" وتوفّر الوظيفة للتطبيقات التابعة لجهات خارجية، يجب أن تستوفي ما يلي:

[C-9-1] يجب تنفيذ واجهات برمجة التطبيقات Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI Intent كما هو موضّح في مستندات حزمة تطوير البرامج (SDK).

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

[C-10-1] يجب توفير واجهة مستخدم في الإعدادات تتعامل مع الغرض Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS، ما يتيح للمستخدمين إضافة تطبيقات إلى القائمة المسموح بها أو إزالتها منها.

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

[C-11-1] يجب أن يتضمّن التطبيق نشاطًا يعالج الغرض Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS ولكن يجوز تنفيذه كعملية غير نشطة.

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

[C-12-3] يجب أن يتم التعامل مع تطبيقات Android المثبَّتة مسبقًا فقط والسماح لها بالتعامل مع النوايا التالية MediaStore.ACTION_IMAGE_CAPTURE وMediaStore.ACTION_IMAGE_CAPTURE_SECURE وMediaStore.ACTION_VIDEO_CAPTURE على النحو الموضّح في مستند حزمة تطوير البرامج (SDK).

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

[C-13-1] يجب أن يتم تنفيذ الغرض android.app.action.ADD_DEVICE_ADMIN لاستدعاء واجهة مستخدم لإرشاد المستخدم خلال عملية إضافة مشرف الجهاز إلى النظام (أو السماح له برفض ذلك).
[C-13-2] يجب أن تتوافق مع أغراض android.app.action.PROVISION_MANAGED_PROFILE وandroid.app.action.SET_NEW_PARENT_PROFILE_PASSWORD وandroid.app.action.SET_NEW_PASSWORD وandroid.app.action.START_ENCRYPTION، وأن تتضمّن نشاطًا لتنفيذ هذه الأغراض على النحو الموضّح في حزمة تطوير البرامج (SDK) هنا.

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

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

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

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

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

[C-19-1] يجب تنفيذ NfcAdapter.ACTION_TRANSACTION_DETECTED Intent API (باسم "EVT_TRANSACTION" كما هو محدّد في المواصفات الفنية الصادرة عن جمعية بروتوكول GSM‏ TS.26 - متطلبات هواتف NFC).

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

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

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

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

[C-0-1] يجب أن يكون متوافقًا مع واحد أو أكثر من واجهات التطبيق الثنائية (ABI) في Android NDK المحدّدة.
[C-0-2] يجب أن يتضمّن دعمًا لتشغيل الرمز في البيئة المُدارة من أجل استدعاء الرموز البرمجية الأصلية، وذلك باستخدام دلالات Java Native Interface (JNI) العادية.
‫[C-0-3] يجب أن يكون الجهاز متوافقًا مع المصدر (أي متوافقًا مع العناوين) ومتوافقًا مع الرمز الثنائي (بالنسبة إلى واجهة التطبيق الثنائية) مع كل مكتبة مطلوبة في القائمة أدناه.
[C-0-5] يجب أن يقدّم الجهاز تقريرًا دقيقًا عن واجهة التطبيق الثنائية (ABI) الأصلية المتوافقة مع الجهاز، وذلك من خلال المَعلمات android.os.Build.SUPPORTED_ABIS وandroid.os.Build.SUPPORTED_32_BIT_ABIS وandroid.os.Build.SUPPORTED_64_BIT_ABIS، وكلّ منها عبارة عن قائمة بواجهات التطبيق الثنائية مفصولة بفواصل ومرتّبة من الأكثر تفضيلاً إلى الأقل تفضيلاً.
[C-0-6] يجب الإبلاغ، من خلال المَعلمات المذكورة أعلاه، عن مجموعة فرعية من قائمة واجهات التطبيق الثنائية (ABI) التالية، ويجب عدم الإبلاغ عن أي واجهة تطبيق ثنائية غير مدرَجة في القائمة.
- ‫armeabi (لم يعُد هذا الإصدار متاحًا كإصدار مستهدف من خلال حزمة NDK)
- armeabi-v7a
- arm64-v8a
- x86
- x86-64
- riscv64
[C-0-7] يجب إتاحة جميع المكتبات التالية التي توفّر واجهات برمجة تطبيقات أصلية للتطبيقات التي تتضمّن رموزًا برمجية أصلية:
- libaaudio.so (دعم الصوت الأصلي في AAudio)
- libamidi.so (إتاحة MIDI الأصلية، إذا تم طلب الميزة android.software.midi كما هو موضّح في القسم 5.9)
- libandroid.so (التوافق مع أنشطة Android الأصلية)
- libc (مكتبة C)
- libcamera2ndk.so
- libdl (رابط ديناميكي)
- ‫libEGL.so (إدارة مساحة OpenGL الأصلية)
- libGLESv1_CM.so (OpenGL ES 1.x)
- libGLESv2.so (OpenGL ES 2.0)
- libGLESv3.so (OpenGL ES 3.x)
- libicui18n.so
- libicuuc.so
- libjnigraphics.so
- liblog (تسجيل البيانات في Android)
- libmediandk.so (إتاحة واجهات برمجة تطبيقات الوسائط الأصلية)
- libm (مكتبة الرياضيات)
- libneuralnetworks.so (Neural Networks API)
- libOpenMAXAL.so (دعم OpenMAX AL 1.0.1)
- libOpenSLES.so (التوافق مع OpenSL ES 1.0.1)
- libRS.so
- libstdc++‎ (الحد الأدنى من التوافق مع C++)
- libvulkan.so (Vulkan)
- libz (ضغط Zlib)
- واجهة JNI
[C-0-8] يجب عدم إضافة أو إزالة الدوال العامة للمكتبات الأصلية المدرَجة أعلاه.
[C-0-9] يجب إدراج المكتبات الإضافية غير التابعة لمشروع Android مفتوح المصدر (AOSP) والتي يتم عرضها مباشرةً للتطبيقات التابعة لجهات خارجية في /vendor/etc/public.libraries.txt.
[C-0-10] يجب عدم عرض أي مكتبات مجمّعة من رموز برمجية أصلية أخرى، تم تنفيذها وتوفيرها في مشروع AOSP كمكتبات نظام، للتطبيقات التابعة لجهات خارجية التي تستهدف المستوى 24 من واجهة برمجة التطبيقات أو أعلى، لأنّها محجوزة.
[C-0-11] يجب تصدير جميع رموز الدوال في OpenGL ES 3.1 وAndroid Extension Pack، كما هو محدّد في NDK، من خلال المكتبة libGLESv3.so. يُرجى العِلم أنّه يجب توفُّر جميع الرموز، ولكن يوضّح القسم 7.1.4.1 بالتفصيل المتطلبات المتعلقة بالحالات التي يُتوقّع فيها التنفيذ الكامل لكل وظيفة من الوظائف المعنية.
[C-0-12] يجب تصدير رموز الدوال الأساسية في Vulkan 1.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.

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

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

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

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

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

[C-2-1] يجب تضمين الأسطر التالية في /proc/cpuinfo، ويجب عدم تغيير القيم على الجهاز نفسه، حتى عندما تتم قراءتها بواسطة واجهات ABI أخرى.
- ‫Features:، متبوعًا بقائمة بأي ميزات اختيارية لوحدة المعالجة المركزية ARMv7 يتوافق معها الجهاز.
- CPU architecture:، متبوعًا بعدد صحيح يصف أعلى بنية ARM متوافقة مع الجهاز (مثلاً، "8" للأجهزة التي تستخدم ARMv8).
[C-2-2] يجب إتاحة العمليات التالية دائمًا، حتى في حال تنفيذ واجهة التطبيق الثنائية (ABI) على بنية ARMv8، سواء من خلال توفير وحدة معالجة مركزية متوافقة أو من خلال محاكاة البرامج:
- تعليمات 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 الأساسي على فرع Android 17 لتنفيذ واجهة برمجة التطبيقات android.webkit.WebView.
[C-1-3] يجب أن يكون سلسلة وكيل المستخدم التي تعرضها WebView للتطبيقات التي تستهدف المستوى 35 من حزمة تطوير البرامج (SDK) والإصدارات الأقدم بالتنسيق التالي:

Mozilla/5.0 (Linux; Android $(VERSION); \[$(MODEL)\] \[Build/$(BUILD)\]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- يجب أن تكون قيمة السلسلة $(VERSION) هي نفسها قيمة android.os.Build.VERSION.RELEASE.
- قد تكون السلسلة $(MODEL) فارغة، ولكن إذا لم تكن فارغة، يجب أن تتضمّن القيمة نفسها التي تتضمّنها android.os.Build.MODEL.
- يمكن حذف "Build/$(BUILD)"، ولكن في حال توفّره، يجب أن يكون السلسلة $(BUILD) هي نفسها قيمة android.os.Build.ID.
- يجب أن تكون قيمة السلسلة $(CHROMIUM_VER) هي إصدار Chromium في مشروع مفتوح المصدر لنظام Android.
- يمكن أن تحذف عمليات تنفيذ الأجهزة كلمة "الجهاز الجوّال" من سلسلة وكيل المستخدم.
يجب أن يتضمّن مكوّن WebView دعمًا لأكبر عدد ممكن من ميزات HTML5، وفي حال توفّر الميزة، يجب أن يتوافق مع مواصفات HTML5.
[C-1-4] يجب عرض المحتوى المقدَّم أو محتوى عنوان URL البعيد في عملية منفصلة عن التطبيق الذي ينشئ WebView. ويجب أن يكون لدى عملية العرض المنفصلة امتيازات أقل، وأن يتم تشغيلها باستخدام رقم تعريف مستخدم منفصل، وألا يكون لديها إذن بالوصول إلى دليل بيانات التطبيق، وألا يكون لديها إذن بالوصول المباشر إلى الشبكة، وأن يكون لديها إذن بالوصول إلى الحد الأدنى من خدمات النظام المطلوبة عبر Binder فقط. يتوافق تطبيق WebView في AOSP مع هذا الشرط.

[C-1-5] يجب أن يكون تنسيق سلسلة وكيل المستخدم التلقائية للنظام التي تعرضها WebView للتطبيقات التي تستهدف المستوى 36 من حزمة SDK والإصدارات الأحدث على النحو التالي:
```
Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) ; wv)
AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0
$(CHROMIUM_MAJOR_VER).0.0.0 Mobile Safari/537.36
```
- يجب أن تكون قيمة $(VERSION) هي القيمة الثابتة 10.
- يجب أن يكون $(MODEL) هو الحرف الثابت K.
- $(CHROMIUM_MAJOR_VER) يجب أن يكون رقم الإصدار الرئيسي من Chromium في مشروع مفتوح المصدر لنظام Android.
- يمكن أن تحذف عمليات تنفيذ الأجهزة كلمة "الجهاز الجوّال" من سلسلة وكيل المستخدم.

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

[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. قيود التطبيق

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

[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].

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

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

‫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 bytecode.
[C-0-2] يجب ضبط أوقات تشغيل Dalvik لتخصيص الذاكرة وفقًا لنظام Android الأساسي الأصلي، وكما هو محدّد في الجدول التالي. (راجِع الفقرة 7.1.1 للتعرّف على تعريفات حجم الشاشة وكثافة الشاشة).
يجب استخدام وقت تشغيل Android ‏ (ART)، وهو التنفيذ المرجعي للمصدر العلوي لتنسيق Dalvik القابل للتنفيذ، ونظام إدارة الحِزم المرجعي.
يجب إجراء اختبارات التشويش في أوضاع تنفيذ مختلفة وعلى بنى مستهدَفة متنوعة لضمان استقرار وقت التشغيل. يمكنك الرجوع إلى JFuzz وDexFuzz في الموقع الإلكتروني لمشروع مفتوح المصدر لنظام Android.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[C-1-4] يجب أن تتيح عرض معاينات التطبيقات المصغّرة التي يتم إنشاؤها ديناميكيًا.
[C-1-5] يجب أن تتوفّر إمكانية تفاعل المستخدم مع المعاينة من خلال مطالبة المستخدم قبل إضافة أداة طلبتها التطبيقات عبر AppWidgetManager.requestPinAppWidget().
[C-1-6] يجب أن يتيح تثبيت التطبيقات المصغّرة داخل التطبيق.
[C-1-7] يجب الإبلاغ عن true مقابل AppWidgetManager.html.isRequestPinAppWidgetSupported().

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

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

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

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

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

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

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

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

يتيح نظام التشغيل Android 11 استخدام إشعارات المحادثات، وهي إشعارات تستخدم 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.3.4. حماية الإشعارات الحسّاسة

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

[C-1-1] يجب إخفاء محتوى معلومات الإشعارات الحسّاسة عند نقلها إلى متتبِّعي الإشعارات، إلا إذا كانت خدمة الاستماع إحدى الخدمات التالية:
- تطبيقات النظام الموقَّعة التي تحمل قيمة uid < 10000
- واجهة مستخدِم النظام
- محارة
- تطبيق الجهاز المصاحب المحدّد (المحدّد بواسطة CompanionDeviceManager)
- دور SYSTEM_AUTOMOTIVE_PROJECTION
- دور SYSTEM_NOTIFICATION_INTELLIGENCE
- دور HOME

يُعد تنفيذ NotificationAssistantServices في AOSP مثالاً على استيفاء هذه المتطلبات. يمكنك الاطّلاع على android.ext.services.notification للحصول على مثال.

‫4.8.3. واجهات برمجة التطبيقات الخاصة بالمساعدة

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

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

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

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

[C-2-2] يجب أن يؤدي التفاعل المحدّد لتشغيل تطبيق المساعدة على النحو الموضّح في الفقرة 7.2.3 إلى تشغيل تطبيق المساعدة الذي اختاره المستخدم، أي التطبيق الذي ينفّذ VoiceInteractionService أو نشاط يعالج الغرض ACTION_ASSIST.

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

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

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

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

‫3.8.6. المظاهر

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

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

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

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

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

راجِع الفقرة 3.2.3.5 لمعرفة إعدادات نية ضبط شاشات التوقف.

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

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

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

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

يتيح نظام التشغيل Android استخدام رموز الإيموجي المحدّدة في Unicode 10.0.

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

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

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

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

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

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

[C-2-1] يجب عرض النص بخط متوافق مع Unicode تلقائيًا، ويجب عدم ضبط خط غير متوافق مع Unicode كخط تلقائي إلا إذا اختاره المستخدم في أداة اختيار اللغة.
‫[C-2-2] يجب أن يتوافق مع خط Unicode وخط غير متوافق مع Unicode إذا كان الجهاز يتيح استخدام خط غير متوافق مع 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 16.
[C-1-3] يجب عدم توفير وضع تقسيم الشاشة أو وضع النافذة الحرة إذا كان ارتفاع الشاشة أقل من 440 وحدة بكسل مستقلة الكثافة وعرض الشاشة أقل من 440 وحدة بكسل مستقلة الكثافة.
[C-1-4] يجب ألا يتم تغيير حجم النشاط ليصبح أصغر من 220 وحدة بكسل مستقلة الكثافة في أوضاع النوافذ المتعددة باستثناء وضع "نافذة ضمن النافذة".

[C-1-5] يجب عرض المهام التي تتضمّن السمة selfMovable بدرجة عتامة كاملة، مع زخرفة مميّزة وثابتة (مثل شريط العنوان)، وطريقة لإغلاق هذه المهام من خلال الزخارف الثابتة.

يجب أن تتوافق عمليات تنفيذ الأجهزة التي تتضمّن حجم شاشة 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] يجب تخصيص الحدّ الأدنى التالي للعرض والارتفاع لنافذة "الصورة داخل الصورة" عندما لا يحدّد التطبيق أي قيمة لـ AndroidManifestLayout_minWidth وAndroidManifestLayout_minHeight:
- يجب أن تخصّص الأجهزة التي تم ضبط Configuration.uiMode فيها على قيمة أخرى غير UI_MODE_TYPE_TELEVISION الحد الأدنى للعرض والارتفاع وهو 108 وحدة بكسل مستقلة عن الكثافة.
- يجب أن تخصص الأجهزة التي تم ضبط Configuration.uiMode فيها على UI_MODE_TYPE_TELEVISION عرضًا لا يقل عن 240 وحدة بكسل مستقلة الكثافة وارتفاعًا لا يقل عن 135 وحدة بكسل مستقلة الكثافة.

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

[C-4-1] يجب أن يتيح وضع النوافذ المتعددة.

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

[C-5-1] يجب تنفيذ الإصدار الصحيح من مستوى واجهة برمجة التطبيقات Window Manager Extensions كما هو موضّح في WindowManager الإضافات.

‫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.8.18. زر الموقع الجغرافي

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

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

[C-0-1] يجب عدم إضافة خيارات التخصيص المقدَّمة لمطوّري التطبيقات لزر مشاركة الموقع الجغرافي أو تعديلها أو إزالتها.

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

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

‫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 بعد بدء عملية توفير الجهاز للمالك، ليتمكّن تطبيق DPC من اختيار ما إذا كان سيصبح مالك الجهاز أو مالك الملف الشخصي، وذلك استنادًا إلى قيم android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES، ما لم يكن من الممكن تحديد خيار واحد صالح من السياق.
  - [C-1-9] يجب إرسال الغرض ACTION_ADMIN_POLICY_COMPLIANCE إلى تطبيق "مالك الجهاز" إذا تم إعداد "مالك الجهاز" أثناء عملية الإعداد بغض النظر عن طريقة الإعداد المستخدَمة. يجب ألا يتمكّن المستخدم من المتابعة في "معالج الإعداد" إلى أن ينتهي تطبيق "مالك الجهاز".
- عندما يتضمّن تنفيذ الجهاز مستخدمين أو بيانات مستخدمين، فإنّه:
  - [C-1-7] يجب عدم تسجيل أي تطبيق لوحدة التحكّم بسياسة الجهاز (DPC) كتطبيق مالك الجهاز بعد الآن.
[C-1-2] تمت إزالة هذا الشرط في الإصدار Android 15.
[C-2-1] تمت إزالة هذا الشرط في Android 15.
[C-2-2] تمت إزالة هذا الشرط في Android 15.
[C-2-3] تمت إزالة هذا الشرط في Android 15.

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

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

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

في حال تضمين عمليات تنفيذ الأجهزة للتعريفين android.software.managed_users وandroid.software.secure_lock_screen، يجب أن تستوفي ما يلي:

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

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

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

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

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

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

‫3.9.4. متطلبات دور إدارة سياسات الأجهزة

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

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

في حال عدم تحديد اسم حزمة config_devicePolicyManagement كما هو موضّح أعلاه:

[C-2-1] يجب أن تتيح عمليات تنفيذ الأجهزة توفيرها بدون تطبيق لصاحب دور إدارة سياسة الجهاز (يوفر مشروع AOSP تنفيذًا مرجعيًا).

إذا تم تحديد اسم حزمة config_devicePolicyManagement كما هو موضح أعلاه:

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

في حال تحديد اسم حزمة config_devicePolicyManagementUpdater كما هو موضح أعلاه:

[C-4-1] يجب أن يكون التطبيق مثبَّتًا مسبقًا على الجهاز.
[C-4-2] يجب أن ينفّذ التطبيق فلتر intent يحلّ android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER.

‫3.9.5. إطار عمل حلّ المشاكل في سياسات الجهاز

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

[C-1-1] يجب حل تعارضات سياسات الأجهزة على النحو الموضّح في إطار عمل حل تعارضات سياسات الأجهزة.

‫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-1-1] يجب أن تتوافق مع واجهات برمجة التطبيقات لإطار عمل تحويل النص إلى كلام في Android.

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

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

‫3.12. لا ينطبق

‫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) هنا وإتاحة الأهداف للتطبيقات الفورية.

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

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

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

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

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

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

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

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

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

‫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] يجب إدراج جهات الاتصال الأولية التي يتم إدراجها بواسطة تطبيقات تابعة لجهات خارجية بدون تحديد حساب في حساب جهات الاتصال التلقائي للجهاز. إذا كان حساب جهات الاتصال التلقائي هو DEFAULT_ACCOUNT_STATE_LOCAL أو DEFAULT_ACCOUNT_STATE_NOT_SET، يجب تخزين جهات الاتصال الأولية هذه في الحساب المحلي المخصّص.
[C-1-4] يجب عدم إزالة جهات الاتصال الأولية التي تم إدراجها في الحساب المحلي المخصّص عند إضافة حسابات أو إزالتها.
[C-1-5] يجب أن تؤدي عمليات الحذف التي يتم تنفيذها على حساب محلي مخصّص إلى إزالة جهات الاتصال الأولية على الفور (كما لو تم ضبط المَعلمة CALLER_IS_SYNCADAPTER على "صحيح")، حتى إذا تم ضبط المَعلمة CALLER_IS_SYNCADAPTER على "خطأ" أو لم يتم تحديدها.

حسابات شرائح SIM: حسابات لجهات الاتصال الأولية التي يتم نسخها من واحدة أو أكثر من شرائح SIM الفعلية المُدرَجة في الجهاز والتي لا تكون مرتبطة بحساب في AccountManager

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

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

[C-1-6] يجب إرجاع حسابات شرائح SIM بحلول ContactsContract.SimContacts.getSimAccounts.

‫3.18.2. أداة اختيار جهات الاتصال المضمّنة في النظام

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

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

[C-1-1] يجب تنفيذ "أداة اختيار جهات الاتصال في النظام" (com.android.contactspicker) للتطبيقات التي تستهدف المستوى 37 أو أعلى لواجهة برمجة التطبيقات.
[C-1-2] يجب تنفيذ الغرض Intent.ACTION_PICK_CONTACTS.

‫3.19. إعدادات اللغة

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

[C-0-1] يجب عدم توفير أي وسيلة للمستخدم لاختيار معالجة لغوية خاصة بالجنس للغات التي لا تتيح ترجمات خاصة بالجنس. يمكنك الاطّلاع على مراجع نحوية لمزيد من المعلومات.

‫3.20. التجارب المستندة إلى "مساعد Google"

يتيح إطار عمل تطوير مساعد Android التحكّم في تطبيقات Android باستخدام الصوت. باستخدام "مساعد Google"، يمكن للمستخدمين استخدام صوتهم لتشغيل التطبيقات وتنفيذ المهام والوصول إلى المحتوى وغير ذلك.

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

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

‫3.20.1. متطلبات بث الصوت من "مساعد Google"

تطبيق لديه إذن MANAGE_ASSISTANT_AUDIO:

[C-0-1] يجب السماح بتغيير مستوى صوت STREAM_ASSISTANT آليًا.

إذا لم تحدّد عمليات تنفيذ الأجهزة android.hardware.type.watch، ولم تكن ذات مستوى صوت ثابت أو مستوى صوت واحد أو مستوى صوت كامل، فإنّها:

[C-1-1] يجب تنفيذ STREAM_ASSISTANT كبث صوتي منفصل ويجب عدم ربطه بأي بث آخر.
[C-1-2] يجب التأكّد من أنّ مستوى صوت تشغيل الصوت باستخدام AudioAttributes مع USAGE_ASSISTANT يتم التحكّم فيه من خلال STREAM_ASSISTANT.
[C-1-3] يجب التأكّد من أنّه بالنسبة إلى سماعة رأس بلوتوث معيّنة، يظل مؤشر مستوى الصوت STREAM_ASSISTANT كما هو عندما تنتقل سماعة الرأس بين ملفات تعريف الصوت A2DP وHFP.
[C-1-4] يجب منع أي بث آخر غير STREAM_ASSISTANT من تغيير مستوى صوت STREAM_ASSISTANT أو مستوى التخفيف المطبّق على تشغيل USAGE_ASSISTANT، أثناء نشاط MODE_ASSISTANT_CONVERSATION.
[C-1-5] يجب تغيير مستوى صوت بث STREAM_ASSISTANT فقط وعدم تغيير مستويات صوت أي بث آخر عند ضبط مستوى الصوت باستخدام مفاتيح مستوى الصوت في الجهاز أو الجهاز الطرفي (مثل سماعة رأس تعمل بالبلوتوث) وعند استيفاء الشروط التالية:
- MODE_ASSISTANT_CONVERSATION مفعّلة، و
- لا يتوفّر تخصيص خاص بالتطبيق أو تشغيل نشط عن بُعد.
‫[C-1-6] يجب أن تعكس واجهة المستخدم أي تغيير في مستوى صوت المساعد.

‫3.21. ميزات "مزامنة الجهاز المصاحب" المتوافقة

يتضمّن Android إمكانية استخدام ميزات مزامنة البيانات على الأجهزة المصاحبة.

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

[C-1-1] يجب تنفيذ واجهة برمجة التطبيقات ContextualModeManager#isModeSyncSupported.
[C-1-2] يجب مزامنة الإعداد الذي يشير إلى تفعيل ميزة "عدم الإزعاج" من خلال قناة CompanionDeviceManager الآمنة باستخدام تنسيق بيانات متوافق مع التنفيذ التلقائي CompanionDeviceManagerService.
[C-1-3] يجب تفعيل هذه المزامنة إذا كان ContextualModeManager#isModeSyncEnabled يعرض true.

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

[C-1-4] يجب مزامنة الإعداد الذي يشير إلى أنّ "وضع الطيران" مفعّل من خلال القناة الآمنة CompanionDeviceManager باستخدام تنسيق بيانات متوافق مع التنفيذ التلقائي CompanionDeviceManagerService.
[C-1-5] يجب تفعيل هذه المزامنة في حال تفعيل Settings.Global.AIRPLANE_MODE_SYNC.

‫3.22. ComputerControls API

تسمح واجهة برمجة التطبيقات ComputerControls API للوكلاء المتوافقين باتّخاذ إجراءات مستقلة وغير مبرمَجة نيابةً عن المستخدم لإكمال المهام على جهاز Android.

[C-1-1] إذا كانت عمليات تنفيذ الأجهزة تحمّل مسبقًا مكتبة الإضافات com.android.extensions.computercontrol لتوفير إمكانية استخدام ComputerControl، عليها استيفاء ما يلي:

يجب تفعيل android.software.activities_on_secondary_display.
يجب عرض ميزة النظام com.android.extensions.computercontrol على أنّها متاحة.
يجب تفعيل VirtualDeviceManager.
يجب تضمين com.android.extensions.computercontrol في القائمة التي تعرضها الدالة PackageManager#getSharedLibraries().
يجب التحميل المُسبَق لتطبيق النظام الأساسي com.android.virtualdevicemanager (إصدار الاستهداف VirtualDeviceManager).

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

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

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

[C-0-2] يجب أن يتيح التحقّق من صحة ملفات "‎.apk" باستخدام الإصدار 3.2 من مخطّط توقيع حِزم APK والإصدار 3.1 من مخطّط توقيع حِزم APK والإصدار 3 من مخطّط توقيع حِزم APK والإصدار 2 من مخطّط توقيع حِزم APK وتوقيع JAR.

[C-0-3] يجب ألا يتم توسيع نطاق أي من تنسيقات .apk أو بيان Android أو رمز Dalvik البايت أو رمز RenderScript البايت بطريقة تمنع تثبيت هذه الملفات وتشغيلها بشكل صحيح على الأجهزة المتوافقة الأخرى.
[C-0-4] يجب ألا تسمح التطبيقات الأخرى غير "برنامج التثبيت التلقائي" الحالي للحزمة بإلغاء تثبيت التطبيق بدون أي تأكيد من المستخدم، كما هو موضّح في حزمة تطوير البرامج (SDK) للإذن DELETE_PACKAGE. الاستثناءات الوحيدة هي تطبيق التحقّق من حِزم النظام الذي يتعامل مع الغرض PACKAGE_NEEDS_VERIFICATION وأداة إدارة مساحة التخزين التي تتعامل مع الغرض ACTION_MANAGE_STORAGE.
[C-0-5] يجب أن يتضمّن تطبيقك نشاطًا يعالج الغرض android.settings.MANAGE_UNKNOWN_APP_SOURCES.
[C-0-6] يجب عدم تثبيت حِزم التطبيقات من مصادر غير معروفة، إلا إذا كان التطبيق الذي يطلب التثبيت يستوفي جميع المتطلبات التالية:
- يجب أن يوضّح REQUEST_INSTALL_PACKAGES الإذن أو أن تكون قيمة android:targetSdkVersion مضبوطة على 24 أو أقل.
- يجب أن يكون المستخدم قد منح التطبيق الإذن بتثبيت تطبيقات من مصادر غير معروفة.
يجب توفير أداة للمستخدمين لمنح/إلغاء إذن تثبيت التطبيقات من مصادر غير معروفة لكل تطبيق، ولكن يمكن اختيار تنفيذ ذلك كعملية غير نشطة وعرض RESULT_CANCELED في startActivityForResult()، إذا كان تنفيذ الجهاز لا يريد السماح للمستخدمين بهذا الخيار. ومع ذلك، حتى في مثل هذه الحالات، يجب أن يوضّحوا للمستخدم سبب عدم توفّر هذا الخيار.
[C-0-7] يجب عرض مربّع حوار تحذيري يتضمّن سلسلة التحذير المقدَّمة من خلال واجهة برمجة التطبيقات PackageManager.setHarmfulAppWarning الخاصة بالنظام للمستخدم قبل بدء نشاط في تطبيق تم تصنيفه على أنّه قد يكون ضارًا من خلال واجهة برمجة التطبيقات PackageManager.setHarmfulAppWarning نفسها.
يجب توفير وسيلة للمستخدمين تتيح لهم اختيار إلغاء تثبيت تطبيق أو تشغيله من خلال مربّع حوار التحذير.
‫[C-0-8] يجب توفير دعم لنظام الملفات التزايدي كما هو موضّح هنا.
[C-0-9] يجب أن يتيح التحقّق من ملفات ‎ .apk باستخدام الإصدار 4 من مخطّط توقيع حِزم APK والإصدار 4.1 من مخطّط توقيع حِزم APK.

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

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

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

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

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

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

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

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

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

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

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

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

‫[C-1-4] MPEG-D USAC مع MPEG-D DRC (برنامج ترميز AAC عالي الكفاءة وموسّع)

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

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

عند ترميز صوت MPEG-D USAC باستخدام MPEG-D DRC (برنامج ترميز AAC عالي الكفاءة الموسّع):

[C-3-2] يجب أن تحتوي جميع تدفقات البتات على مجموعات البيانات الوصفية المتوافقة مع ملف تعريف التحكّم في مستوى الصوت MPEG-D أو ملف تعريف التحكّم في النطاق الديناميكي MPEG-D، المستوى 1 أو أعلى، وفقًا للمعيار ISO/IEC 23003-4.

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

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

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

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

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

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

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

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

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

قد يتيح الجهاز التحكّم في مستوى الصوت ونطاق الديناميكية باستخدام معيار ISO/IEC 23003-4 Dynamic Range Control Profile.

في حال توفّر معيار 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).

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

[C-8-1] يجب أن يتيح فك ترميز الإصدار 1.0 من تنسيق IAMF الذي يتضمّن بثًا صوتيًا مرمّزًا بتنسيق AAC أو FLAC أو Opus أو PCM، ويجب أن يوفّر برنامج فك ترميز IAMF من خلال واجهة برمجة التطبيقات android.media.MediaCodec.
[C-8-2] يجب التأكّد من أنّ برنامج فك ترميز IAMF يلتزم بقناع القناة المستخدَم لضبطه من خلال المفتاح KEY_CHANNEL_MASK، وذلك باستخدام الثوابت android.media.AudioFormat مثلCHANNEL_OUT_5POINT1.
[C-8-3] يجب التأكّد من أنّ برنامج فك ترميز IAMF يعلن عن قناع القناة النشط في تنسيق الإخراج من خلال المفتاح 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. تفاصيل برامج ترميز الصوت

التنسيق/برنامج الترميز	التفاصيل	أنواع الملفات/تنسيقات الحاويات التي يجب توفيرها
G.711 μ-law وA-law	إتاحة المحتوى الأحادي/الاستيريو/5.1 الذي تم أخذ عينات منه بمعدّل 8 كيلوهرتز	‫WAVE ‏(‎.wav)
ملف تعريف الترميز المتقدّم للصوت (AAC) بتنسيق MPEG-4 (الترميز المتقدّم للصوت منخفض التعقيد)	إتاحة المحتوى أحادي القناة أو الثنائي القناة أو 5.0 أو 5.1 مع معدّلات بيانات في الملف الصوتي تتراوح بين 8 و48 كيلوهرتز	3GPP‏ (‎.3gp) MPEG-4 ‏(‎.mp4، ‏‎.m4a) ملف ADTS AAC الأولي (لا يمكن استخدام ADIF) ‫MPEG-TS (.ts، لا يمكن البحث فيه، فك الترميز فقط) ‫Matroska (.mkv، فك التشفير فقط)
ملف تعريف MPEG-4 HE AAC (AAC+)	إتاحة المحتوى الأحادي/الاستيريو/5.0/5.1 بمعدّلات بيانات في الملف الصوتي تتراوح بين 16 و48 كيلوهرتز.	3GPP‏ (‎.3gp) MPEG-4 ‏(‎.mp4، ‏‎.m4a)
ملف تعريف MPEG-4 HE AACv2 (enhanced AAC+)	إتاحة المحتوى الأحادي/الاستيريو/5.0/5.1 بمعدّلات بيانات في الملف الصوتي تتراوح بين 16 و48 كيلوهرتز.	3GPP‏ (‎.3gp) MPEG-4 ‏(‎.mp4، ‏‎.m4a)
الترميز المتقدّم للصوت (AAC) ذو التأخير المنخفض المحسّن	يتوافق مع المحتوى الأحادي/الاستيريو بمعدّلات بيانات في الملف الصوتي تتراوح بين 16 و48 كيلوهرتز.	3GPP‏ (‎.3gp) MPEG-4 ‏(‎.mp4، ‏‎.m4a)
USAC MPEG-D USAC مع MPEG-D DRC (ترميز AAC عالي الكفاءة الموسّع)	فك التشفير: إتاحة المحتوى الأحادي/الاستيريو بمعدّلات بيانات في الملف الصوتي عادية تتراوح بين 7.35 و48 كيلوهرتز الترميز: يتوافق مع المحتوى الأحادي أو الاستيريو بمعدّلات أخذ العينات تبلغ 44.1 و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	صوت أحادي/استيريو بمعدل نقل بيانات ثابت (CBR) أو متغيّر (VBR) يتراوح بين 8 و320 كيلوبت في الثانية	MP3 ‏(‎.mp3) ‫MPEG-4 ‏(‎.mp4 و‎.m4a، فك التشفير فقط) ‫Matroska (.mkv، فك التشفير فقط)
MIDI	النوعان 0 و1 من ملفات MIDI الإصداران 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 بت و16 بت للفاصلة العائمة. يجب أن يتيح برنامج استخراج بيانات WAVE استخدام ترميز PCM خطي بمعدّل 16 بت و24 بت و32 بت، بالإضافة إلى معدّل 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 (الملف الشخصي للمرجع)

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

‫[C-1-1] يجب أن يتيح فك ترميز صور HEIF (HEIC).

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

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

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

التنسيق/برنامج الترميز	التفاصيل	أنواع الملفات/تنسيقات الحاويات المتوافقة
JPEG	Base+progressive	JPEG‏ (‎.jpg)
GIF		GIF ‏(‎.gif)
PNG		PNG‏ (‎.png)
BMP		BMP‏ (‎.bmp)
تنسيق WebP		WebP ‏(‎.webp)
عناوين أوّلية		ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
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] يجب أن تتوافق برامج ترميز الفيديو مع أحجام bytebuffer للإخراج والإدخال التي تستوعب أكبر إطار مضغوط وغير مضغوط ممكن وفقًا للمعيار والإعدادات، ولكن بدون تخصيص مساحة أكبر من اللازم.
‫[C-1-2] يجب أن تتوافق برامج ترميز الفيديو وفك ترميزه مع تنسيقات الألوان المرنة YUV420 8:8:8 (COLOR_FormatYUV420Flexible) من خلال CodecCapabilities.
[C-1-3] يجب أن تتوافق برامج ترميز الفيديو وفك ترميزه مع تنسيق ألوان YUV420 8:8:8 المسطّح أو شبه المسطّح على الأقل: COLOR_FormatYUV420PackedPlanar (ما يعادل COLOR_FormatYUV420Planar) أو COLOR_FormatYUV420PackedSemiPlanar (ما يعادل COLOR_FormatYUV420SemiPlanar). ويُنصح بشدة بأن تتوافق مع كليهما.
[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.

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

[C-5-1] يجب أن تستوفي برامج ترميز الفيديو التي تستخدم تكنولوجيا ترميز من عام 2003 أو إصدار أحدث (مثل AV1 أو AVC أو HEVC أو VP8 أو VP9 أو VVC) ما يلي:
- أن تتوافق مع الحد الأدنى للحجم وهو 144 × 144 بكسل
- يمكنك الإعلان عن هذه الميزة من خلال VideoCapabilities API، مثل الطريقتَين getSupportedWidths() وgetSupportedHeightsFor().
[C-5-2] يجب أن تستوفي برامج ترميز الفيديو التي تستخدم تكنولوجيا ترميز من عام 2003 أو إصدار أحدث (مثل AV1 أو AVC أو HEVC أو VP8 أو VP9 أو VVC) ما يلي:
- يجب أن يكون الحدّ الأدنى لحجم إدخال Support Surface لكل برنامج ترميز على النحو التالي:
  - AVC: 160x160 بكسل
  - ‫VP8 وHEVC وVP9 (في حال توفّر برنامج الترميز): 160×160 بكسل
  - ‫AV1 (في حال توفّر برنامج ترميز): 256x256 بكسل
- يمكن أن تنتج دفق بيانات بحجم إطار أكبر من الحد الأدنى، شرط أن يتم ترميز الحجم المناسب باستخدام معلومات مستطيل الاقتصاص.

‫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 للحصول على التفاصيل.	WebM ‎(.webm) Matroska‏ (‎.mkv)
VP9	يمكنك الاطّلاع على الفقرة 5.3 لمعرفة التفاصيل.	WebM ‎(.webm) Matroska‏ (‎.mkv)
AV1	راجِع الفقرة 5.2 والفقرة 5.3 للحصول على التفاصيل.	MPEG-4 ‏(‎.mp4) ‫Matroska (.mkv، فك التشفير فقط)

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

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

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

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

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

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

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

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

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

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

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

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

	الدقة العادية (جودة منخفضة)	الدقة العادية (جودة عالية)	دقة عالية - 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. ترميز الفيديو

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع أي برنامج ترميز فيديو وتتيحه للتطبيقات التابعة لجهات خارجية، وتم ضبط
MediaFormat.KEY_BITRATE_MODE على BITRATE_MODE_VBR لكي يعمل برنامج الترميز في وضع معدل نقل البيانات المتغيّر، عندئذٍ، طالما أنّ ذلك لا يؤثّر في الحد الأدنى للجودة، يكون معدل نقل البيانات المرمَّز :

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

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

يُنصح بشدة بعدم تجاوز [C-SR-2] %15 من معدّل نقل البيانات المستهدف خلال فترة زمنية متغيرة تبلغ ثانية واحدة.

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

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

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

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

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

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

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

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

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

[C-SR-1] يُنصح بشدة بتوفير إضافة لواجهة برمجة التطبيقات الخاصة بالترميز والتغيير السلسَين لتحويل المحتوى من تنسيق HDR إلى تنسيق SDR.

5.2.1. H.263

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

[C-1-1] يجب أن تتوافق مع درجة الدقة QCIF (‏176 × 144) باستخدام المستوى 45 من الملف الشخصي للمرجع. درجة دقة SQCIF اختيارية.

5.2.2. H.264

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

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

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

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

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

‫5.2.3. VP8

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

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

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

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

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

‫5.2.4. VP9

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

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

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

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

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

‫5.2.5. H.265

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

[C-1-1] يجب أن يتوافق مع "الملف الشخصي الرئيسي" المستوى 3 حتى درجة دقة 512 × 512.
[C-SR-1] يُنصح بشدة بتوفير دعم لملف تعريف SD بدقة 720 × 480 وملفات تعريف الترميز بدقة عالية الوضوح (HD) كما هو موضّح في الجدول التالي في حال توفّر برنامج ترميز للأجهزة.

	دقة عادية	دقة عالية - 720p	دقة عالية - 1080p	دقة فائقة
دقة الفيديو	‫720 × 480 بكسل	‫1280 × 720 بكسل	‫‎1920 x 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 x 1080 بكسل	‫3840 × 2160 بكسل
عدد اللقطات في الثانية في الفيديو	30 إطارًا في الثانية	30 إطارًا في الثانية	30 إطارًا في الثانية	30 إطارًا في الثانية
معدّل نقل بيانات الفيديو	5 ميغابت في الثانية	‫8 ميغابت في الثانية	16 ميغابت في الثانية	‫50 ميغابت في الثانية

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

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

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

‫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) مدرَجة في الجدول التالي وتم ترميزها باستخدام الملف الشخصي للمرجع وMain Profile Level 3.1 (بما في ذلك 720p30).
يجب أن يكون الجهاز قادرًا على فك ترميز الفيديوهات باستخدام ملفات تعريف الدقة العالية (HD) كما هو موضّح في الجدول التالي.

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

‫[C-2-1] يجب أن تتوافق مع ملفات فك ترميز الفيديو بدقة 720p عالية الدقة الواردة في الجدول أدناه.
[C-2-2] يجب أن تتوافق مع ملفات تعريف فك ترميز الفيديو بدقة 1080p عالية الوضوح الواردة في الجدول التالي.

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

5.3.5. ‫H.265 (HEVC)

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

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

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

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

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

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

[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 x 1080 بكسل
عدد اللقطات في الثانية في الفيديو	30 إطارًا في الثانية	30 إطارًا في الثانية	‫30 لقطة في الثانية (‫60 لقطة في الثانية^{تلفزيون})	‫30 (60 لقطة في الثانية^{تلفزيون})
معدّل نقل بيانات الفيديو	‫800 كيلوبت في الثانية	‫2 ميغابت في الثانية	‫8 ميغابت في الثانية	20 ميغابت في الثانية

5.3.7. VP9

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

‫[C-1-1] يجب أن تتوافق مع ملفات تعريف فك ترميز الفيديو بدقة عادية (SD) كما هو موضّح في الجدول التالي.
يجب أن تتوافق مع ملفات تعريف فك الترميز بدقة عالية كما هو موضّح في الجدول التالي.

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

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

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

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

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

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

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

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

[C-4-1] يجب أن تقبل عمليات تنفيذ الأجهزة البيانات الوصفية المطلوبة ذات النطاق العالي الديناميكية (KEY_HDR_STATIC_INFO لجميع ملفات تعريف النطاق العالي الديناميكية، بالإضافة إلى ‎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] يجب أن تتوافق مع "الملف الشخصي الرئيسي"، بما في ذلك المحتوى بدقة 8 بت و10 بت.

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

[C-2-1] يجب أن يكون الجهاز قادرًا على فك ترميز ملفات الفيديو بدقة 720p عالية الوضوح على الأقل من الجدول أدناه عندما يكون الارتفاع الذي تعرضه الطريقة Display.getSupportedModes() مساويًا أو أكبر من 720p.
[C-2-2] يجب أن يكون الجهاز قادرًا على فك ترميز ملفات الفيديو بدقة 1080p عالية الدقة على الأقل من الجدول أدناه عندما يكون الارتفاع الذي تعرضه الطريقة Display.getSupportedModes() مساويًا أو أكبر من 1080p.

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

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

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

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

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

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

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

[C-1-1] يجب السماح بتسجيل محتوى الصوت الخام لأي دفق إدخال AudioRecord أو AAudio يتم فتحه بنجاح. يجب أن تتوفّر الخصائص التالية كحدّ أدنى:
- التنسيق: Linear PCM، ‏16 بت
- معدّلات أخذ العينات: 8000 و11025 و16000 و44100 و48000 هرتز
- القنوات: أحادية
- مصادر الصوت: DEFAULT أو MIC أو CAMCORDER أو VOICE_RECOGNITION أو VOICE_COMMUNICATION أو UNPROCESSED أو VOICE_PERFORMANCE ينطبق ذلك أيضًا على إعدادات Input Presets المكافئة في AAudio، مثل AAUDIO_INPUT_PRESET_CAMCORDER.
يجب السماح بتسجيل المحتوى الصوتي الأولي الذي يتضمّن الخصائص التالية:
- التنسيق: 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 ديسيبل (يتم قياسه بجانب الميكروفون) إلى استجابة مثالية تبلغ 2500 RMS ضمن نطاق يتراوح بين 1770 و3530 لعينات 16 بت (أو -22.35 ديسيبل ±3 ديسيبل على المقياس الكامل لعينات النقطة العائمة/الدقة المزدوجة) لكل ميكروفون مستخدَم لتسجيل مصدر الصوت الخاص بالتعرّف على الصوت.
يجب أن يسجّل الميكروفون بث الصوت الخاص بالتعرّف على الصوت، وذلك لكي تتتبّع مستويات سعة نبضة الترميز (PCM) بشكل خطي التغييرات في مستوى ضغط الصوت (SPL) الواردة على مدى نطاق 30 ديسيبل على الأقل من -18 ديسيبل إلى +12 ديسيبل بالنسبة إلى 90 ديسيبل SPL عند الميكروفون.
يجب أن تسجّل بث الصوت الخاص بميزة "التعرّف على الصوت" مع تشويه توافقي إجمالي (THD) أقل من% 1 عند 1 كيلو هرتز ومستوى إدخال يبلغ 90 ديسيبل SPL في الميكروفون.

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

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

5.4.3. التقاط المحتوى لإعادة توجيه التشغيل

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

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

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

5.4.4. إلغاء الصدى

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

يجب تنفيذ تكنولوجيا إلغاء الصدى الصوتي (AEC) التي تم ضبطها للاتصال الصوتي وتطبيقها على مسار الالتقاط عند الالتقاط باستخدام AudioSource.VOICE_COMMUNICATION.

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

[C-SR-1] [C-1-1] يُنصح بشدة يجب الإفصاح عن ذلك من خلال طريقة واجهة برمجة التطبيقات AcousticEchoCanceler AcousticEchoCanceler.isAvailable() التي تعرض القيمة true.

[C-1-2] يجب أن يعكس تفعيل ميزة AEC في مسار الصوت من خلال طريقة AcousticEchoCanceler API AcousticEchoCanceler.getEnabled()، والتي يجب أن تعرض true عند التفعيل، وfalse عند عدم التفعيل.

ننصح بشدة باستخدام [C-SR-2] [C-SR-1] للسماح بالتحكّم في هذا التأثير الصوتي باستخدام واجهة برمجة التطبيقات AcousticEchoCanceler.
يُنصح بشدة باستخدام [C-SR-3] [C-SR-2] لتحديد كل عملية تنفيذ لتكنولوجيا AEC بشكل فريد من خلال الحقل AudioEffect.Descriptor.uuid.

5.4.5. التسجيل المتزامن

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

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

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

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

5.5.1. تشغيل الصوت الخام

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

[C-1-1] يجب أن يسمح الجهاز بتشغيل محتوى صوتي غير معدَّل يتضمّن الخصائص التالية:
- تنسيقات المصدر: Linear PCM، و16 بت، و8 بت، وfloat
- القنوات: أحادية، استيريو، إعدادات صالحة متعددة القنوات تتضمّن 8 قنوات كحدّ أقصى
- معدّلات أخذ العيّنات (بالهرتز):
  - ‫8000 و11025 و16000 و22050 و24000 و32000 و44100 و48000 في إعدادات القناة المذكورة أعلاه
  - ‫96000 في وضع الصوت الأحادي والاستيريو

5.5.2. المؤثرات الصوتية

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

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

[C-1-1] يجب أن تتوافق مع عمليات التنفيذ EFFECT_TYPE_EQUALIZER وEFFECT_TYPE_LOUDNESS_ENHANCER التي يمكن التحكّم فيها من خلال الفئات الفرعية AudioEffect Equalizer وLoudnessEnhancer.
‫[C-1-2] يجب أن يتيح تنفيذ واجهة برمجة التطبيقات الخاصة بأداة العرض المرئي، ويمكن التحكّم فيها من خلال الفئة Visualizer.
[C-1-3] يجب أن تتوافق مع تنفيذ EFFECT_TYPE_DYNAMICS_PROCESSING الذي يمكن التحكّم فيه من خلال الفئة الفرعية AudioEffect DynamicsProcessing.
[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.
[C-SR-2] يُنصح بشدة بتنفيذ ميزة "تشغيل المحتوى بدون اتصال بالإنترنت" للتنسيقات AAC وMP3 وOPUS وPCM.

إذا كانت عمليات تنفيذ الأجهزة تعلن عن إتاحة إمكانية تخفيف الحِمل لبيانات PCM الخاصة بـ MMAP (يتم الإعلان عنها من خلال منفذ مختلط يتضمّن علامات تحتوي على AUDIO_OUTPUT_FLAG_COMPRESS_OFFLOAD وAUDIO_OUTPUT_FLAG_MMAP_NOIRQ)، فإنّها:

[C-1-1] يجب أن تتوافق مع AUDIO_FORMAT_PCM_16_BIT على الأقل، بمعدّل 44.1 كيلوهرتز و48 كيلوهرتز للصوت الاستيريو والأحادي.
[C-1-2] يجب أن يكون حجم المخزن المؤقت قادرًا على تخزين ما لا يقل عن 5 ثوانٍ من الصوت بمعدل 48 كيلوهرتز استيريو PCM 16 بت لكل عينة.

5.5.5. مَعلمات التشغيل

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع PlaybackParams API، ستكون معلمات التشغيل:

‫[C-1-1] يجب أن تتوافق مع السرعات بين 0.5 و2.0 مع درجة صوت تبلغ 1.0.

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

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

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

وقت استجابة الإخراج الفاصل الزمني بين كتابة تطبيق لإطار بيانات مرمز بتنسيق PCM وعرض الصوت المقابل في البيئة باستخدام محوّل طاقة على الجهاز فقط أو مغادرة الإشارة للجهاز عبر منفذ وإمكانية ملاحظتها خارجيًا
وقت استجابة الإخراج البارد الوقت بين بدء بث الإخراج ووقت عرض الإطار الأول استنادًا إلى الطوابع الزمنية، عندما يكون نظام إخراج الصوت غير نشط وتم إيقاف تشغيله قبل الطلب.
وقت استجابة الناتج المتواصل وقت الاستجابة الناتج عن عرض اللقطات اللاحقة، بعد أن يبدأ الجهاز في تشغيل الصوت
وقت استجابة الإدخال الفاصل الزمني بين وقت عرض الصوت من خلال البيئة إلى الجهاز في محوّل طاقة على الجهاز فقط أو إدخال إشارة إلى الجهاز عبر منفذ، ووقت قراءة تطبيق لإطار البيانات المقابل المرمّز بتنسيق PCM.
فقدان البيانات الجزء الأوّلي من إشارة الإدخال الذي لا يمكن استخدامه أو غير متوفّر.
وقت استجابة الإدخال البارد الوقت بين بدء البث واستلام أول إطار صالح، عندما يكون نظام إدخال الصوت غير نشط وتم إيقاف تشغيله قبل الطلب
وقت استجابة الإدخال المتواصل وقت الاستجابة للإدخال في اللقطات اللاحقة، أثناء تسجيل الجهاز للصوت
وقت الاستجابة المتواصل بين الجهازين مجموع وقت استجابة الإدخال المتواصل ووقت استجابة الإخراج المتواصل بالإضافة إلى فترة تخزين مؤقت واحدة تتيح فترة التخزين المؤقت للتطبيق وقتًا لمعالجة الإشارة ووقتًا للحد من فرق الطور بين تدفقات الإدخال والإخراج.
OpenSL ES PCM API قائمة انتظار المخزن المؤقت مجموعة واجهات برمجة التطبيقات ذات الصلة بترميز PCM في OpenSL ES ضمن Android NDK
واجهة برمجة التطبيقات الأصلية للصوت AAudio مجموعة واجهات برمجة التطبيقات AAudio ضمن Android NDK
الطابع الزمني زوج يتألف من موضع إطار نسبي ضمن بث ووقت تقديري لدخول هذا الإطار إلى مسار معالجة الصوت أو خروجه منه على نقطة النهاية المرتبطة. راجِع أيضًا AudioTimestamp.
glitch انقطاع مؤقت أو قيمة عيّنة غير صحيحة في إشارة الصوت، ويحدث ذلك عادةً بسبب نقص في المخزن المؤقت عند الإخراج، أو زيادة في المخزن المؤقت عند الإدخال، أو أي مصدر آخر للضوضاء الرقمية أو التناظرية.
متوسط الانحراف المطلق (MAD) متوسط القيمة المطلقة للانحرافات عن المتوسط لمجموعة من القيم
وقت استجابة النقر إلى إصدار الصوت (TTL)، كما يتم قياسه باستخدام CTS Verifier، هو الوقت الفاصل بين النقر على الشاشة وسماع صوت ناتج عن هذا النقر على مكبّر الصوت. يتم حساب هذا المتوسط على مدار 5 قياسات باستخدام واجهة برمجة التطبيقات الأصلية للصوت AAudio للإخراج.
وقت الاستجابة الكامل (RTL)، كما يتم قياسه باستخدام CTS Verifier، هو متوسط وقت الاستجابة المستمر على مدار 5 قياسات، ويتم قياسه على مسار إعادة توجيه يعيد إرسال الناتج إلى الإدخال، وذلك باستخدام واجهة برمجة التطبيقات الأصلية AAudio.

مسارات الاسترجاع هي:
- مكبّر الصوت/الميكروفون: مكبّر صوت مدمج إلى ميكروفون مدمج
- الوضع التناظري: مقبس تناظري مقاس 3.5 ملم ومحوّل ربط حلقي
- USB: محوّل من USB إلى 3.5 ملم ومحوّل تسجيل الصوت أو واجهة صوت USB وكابلات تسجيل الصوت
‫FEATURE_AUDIO_LOW_LATENCY تم الإعلان عن ميزة android.hardware.audio.low_latency.
‫FEATURE_AUDIO_PRO تم الإعلان عن ميزة android.hardware.audio.pro.
MPC. فئة أداء الوسائط
وقت استجابة تتبُّع حركة الرأس تمثّل هذه السمة الوقت الذي يستغرقه رصد التغيير في الصوت الناتج عن حركة الرأس، وذلك بدءًا من رصد وحدة قياس القصور الذاتي (IMU) لحركة الرأس وحتى رصد محوّلات الطاقة في سماعات الرأس لهذا التغيير.

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

[C-0-1] يجب التأكّد من أنّه عند استدعاء تطبيق android.media.AudioManager.setCommunicationDevice() باستخدام device متوافق (مثل سمّاعات الرأس السلكية أو مكبّرات الصوت أو سمّاعات الأذن المدمجة أو سمّاعات الرأس USB)، يتم استدعاء android.media.AudioManager.OnCommunicationDeviceChangedListener.onCommunicationDeviceChanged() مع جهاز الصوت هذا في غضون 1500 ملي ثانية من عرض true عند إرجاع استدعاء setCommunicationDevice().

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

[C-1-1] تمت إزالة هذا الشرط في Android 15.
‫[C-1-2] وقت استجابة الإخراج البارد يبلغ 500 مللي ثانية أو أقل.
[C-1-3] يجب أن يستغرق فتح بث إخراج باستخدام AAudioStreamBuilder_openStream() أقل من 1000 مللي ثانية.
[C-1-4] يجب أن تكون مدة الاستجابة المحسوبة للذهاب والعودة استنادًا إلى الطوابع الزمنية للإدخال والإخراج التي تعرضها AAudioStream_getTimestamp في حدود 200 مللي ثانية من مدة الاستجابة المقاسة للذهاب والعودة في AAUDIO_PERFORMANCE_MODE_NONE وAAUDIO_PERFORMANCE_MODE_LOW_LATENCY للسماعات ومجموعات سماعات الرأس السلكية واللاسلكية.
[C-SR-1] تمت إزالة هذا الشرط في Android 15.
[C-SR-2] تمت إزالة هذا الشرط في الإصدار Android 15.
[C-SR-4] تمت إزالة هذا الشرط في Android 15.
[C-SR-5] تمت إزالة هذا الشرط في Android 15.
[C-SR-6] تمت إزالة هذا الشرط في Android 15.
[C-SR-7] تمت إزالة هذا الشرط في Android 15.
[C-2-1] تمت إزالة هذا الشرط في Android 15.

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

[C-3-1] تمت إزالة هذا الشرط في Android 15.
‫[C-3-2] وقت استجابة الإدخال البارد يبلغ 500 مللي ثانية أو أقل.
[C-3-3] يجب ألا يستغرق فتح بث إدخال باستخدام AAudioStreamBuilder_openStream() أقل من 1000 مللي ثانية.
[C-SR-8] تمت إزالة هذا الشرط في Android 15.
[C-SR-11] تمت إزالة هذا الشرط في الإصدار 15 من نظام التشغيل Android.
[C-SR-12] تمت إزالة هذا الشرط في Android 15.

يحدّد الجدول التالي متطلبات الكتابة من اليمين إلى اليسار لعمليات التنفيذ على الأجهزة المحمولة كما هو محدّد في 2.2.1 التي تعرّف android.hardware.audio.output وandroid.hardware.microphone.

الجهاز والإشعارات	RTT (بالمللي ثانية)	MAD (مللي ثانية)	مسارات الاسترجاع
حمل الكاميرا يدويًا	200	25	مكبّر الصوت/الميكروفون، مقبس صوت تناظري 3.5 ملم (إذا كان متوافقًا)، منفذ USB (إذا كان متوافقًا)
‫MPC_C (الإصدار 17) والإصدارات الأحدث	65	10	جميع مسارات البيانات المتوافقة
‫>= MPC_T (13) من خلال MPC_B (16)	80	15	مسار واحد على الأقل
FEATURE_AUDIO_LOW_LATENCY	50	10	مسار واحد على الأقل
FEATURE_AUDIO_PRO	25	5	مسار واحد على الأقل
FEATURE_AUDIO_PRO	20	5	تناظري (في حال توفّره)
FEATURE_AUDIO_PRO	25	5	USB (في حال عدم توفّر إخراج صوت تناظري)

يحدّد الجدول التالي متطلبات TTL لعمليات تنفيذ الأجهزة المحمولة كما هو محدّد في 2.2.1 التي تحدّد android.hardware.audio.output وandroid.hardware.microphone.

الجهاز والإشعارات	مدة البقاء (بالملّي ثانية)
حمل الكاميرا يدويًا	250
‫MPC_C (الإصدار 17) والإصدارات الأحدث	65
‫>= MPC_T (13) من خلال MPC_B (16)	80
MPC_S (12)	100
FEATURE_AUDIO_PRO	80

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة spatial audio مع تتبُّع حركة الرأس وتحدّد العلامة PackageManager.FEATURE_AUDIO_SPATIAL_HEADTRACKING_LOW_LATENCY، عليها استيفاء ما يلي:

‫[C-4-1] يجب أن يكون الحد الأقصى لوقت استجابة تتبُّع الرأس لتحديث الصوت أقل من 300 مللي ثانية.

‫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. برامج ترميز الصوت: الترميز المتقدّم للصوت (AAC) راجِع الفقرة 5.1.3 للحصول على تفاصيل حول ترميز AAC وأشكاله المختلفة.
ملف AAC مع إطارات ADTS وعلامات ID3	ISO 13818-7	يمكنك الاطّلاع على الفقرة 5.1.1 لمزيد من التفاصيل حول ترميز AAC وأشكاله المختلفة.
WebVTT	WebVTT

أشكال الشرائح

المراجع

برامج الترميز المتوافقة المطلوبة

MPEG-2 Transport Stream

ISO 13818

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

H264 AVC
MPEG-4 SP
MPEG-2

راجِع الفقرة 5.1.8 للحصول على تفاصيل حول H264 AVC وMPEG2-4 SP
وMPEG-2.

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

الترميز المتقدّم للصوت (AAC)

راجِع الفقرة 5.1.3 للحصول على تفاصيل حول ترميز AAC وأشكاله المختلفة.

ملف AAC مع إطارات ADTS وعلامات ID3

ISO 13818-7

يمكنك الاطّلاع على الفقرة 5.1.1 لمزيد من التفاصيل حول ترميز AAC وأشكاله المختلفة.

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 Live Streaming للحصول على التفاصيل.

‫5.8. Secure Media

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

[C-1-1] يجب الإفصاح عن إتاحة Display.FLAG_SECURE.

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

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

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

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

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

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

[C-1-1] يجب أن تتوافق مع MIDI عبر جميع عمليات نقل الأجهزة المتوافقة مع MIDI والتي توفّر لها إمكانية اتصال عامة غير MIDI، حيث تكون عمليات النقل هذه كما يلي:
- وضع مضيف USB، الفقرة 7.7
- الواجهة الرقمية للآلات الموسيقية (MIDI) عبر بلوتوث منخفض الطاقة التي تعمل في دور مركزي، الفقرة 7.4.3
[C-1-2] يجب أن تتوافق مع نقل برامج MIDI بين التطبيقات (أجهزة MIDI الافتراضية)
[C-1-3] يجب تضمين libamidi.so (توافق MIDI الأصلي)
يجب أن تتوافق مع وضع أجهزة USB الخارجية في MIDI، الفقرة 7.7

‫5.10. Professional Audio

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

[C-1-1] يجب الإبلاغ عن توفّر ميزة android.hardware.audio.low_latency.
[C-1-2] يجب استيفاء متطلبات وقت الاستجابة FEATURE_AUDIO_PRO على النحو المحدّد في القسم 5.6 وقت استجابة الصوت .
[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 ملي ثانية أو أقل.

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

[C-2-2] يجب الالتزام بالقسم مواصفات الأجهزة الجوّالة (المقبس) من مواصفات سماعات الرأس السلكية (الإصدار 1.1).

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

‫[C-3-1] يجب تنفيذ فئة الصوت عبر USB.

‫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 RMS لعينات 16 بت (أو -36 ديسيبل من المقياس الكامل لعينات النقطة العائمة/الدقة المزدوجة) لكل ميكروفون مستخدَم لتسجيل مصدر الصوت غير المعالج.
[C-1-6] يجب أن تتوفّر نسبة الإشارة إلى الضوضاء (SNR) عند 60 ديسيبل أو أعلى لكل ميكروفون مستخدَم لتسجيل مصدر الصوت غير المعالج. (بينما يتم قياس نسبة الإشارة إلى الضوضاء على أنّها الفرق بين مستوى ضغط الصوت البالغ 94 ديسيبل ومستوى ضغط الصوت المكافئ للضوضاء الذاتية، مع ترجيح A).
[C-1-7] يجب أن يكون إجمالي التشوه التوافقي (THD) أقل من 1% عند 1 كيلو هرتز ومستوى ضغط صوتي (SPL) يبلغ 90 ديسيبل عند كل ميكروفون مستخدَم لتسجيل مصدر الصوت غير المعالج.
[C-1-8] يجب ألا يتضمّن أي معالجة أخرى للإشارات (مثل التحكّم التلقائي في مستوى الصوت أو فلتر الترددات العالية أو إلغاء الصدى) في المسار باستثناء مضاعف المستوى لضبط المستوى على النطاق المطلوب. وبعبارة أخرى:
- [C-1-9] إذا كانت هناك أي معالجة للإشارات في البنية لأي سبب، يجب إيقافها وعدم إضافة أي تأخير أو زمن انتقال إضافي إلى مسار الإشارة.
- [C-1-10] يجب ألا يؤدي مضاعف المستوى، مع السماح بوجوده في المسار، إلى حدوث تأخير أو بطء في مسار الإشارة.

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

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

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

‫5.12 فيديو HDR

يتوافق نظام التشغيل 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، يجب أن تستوفي ما يلي:

[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] يجب أن تتوافق مع ميزة "ربط درجات الألوان" من النطاق العالي الديناميكية إلى النطاق العادي الديناميكية في برنامج فك الترميز التلقائي المُسّرع للأجهزة للملف الشخصي الذي تم التقاطه. بعبارة أخرى، إذا كان الجهاز قادرًا على تسجيل محتوى HEVC بتنسيق HDR10+‎، يجب أن يكون برنامج فك ترميز 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.

متطلبات شاشة HDR

إذا تلقّت عمليات تنفيذ الأجهزة محتوى مخزّنًا مؤقتًا مشفّرًا باستخدام ADATASPACE_TRANSFER_HLG، وتم إرسال هذا المحتوى إلى الشاشة من خلال SurfaceControl.Transaction#setBuffer، يجب أن:

[C-8-1] يجب اتّباع توصية اللون الأبيض في الرسومات الواردة في المعيار BT. 2408-7، وعرض المحتوى بما لا يزيد عن 4.926 مرة من محتوى النطاق الديناميكي العادي (SDR).

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

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

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

[C-0-1] يجب أن تتوافق مع "أدوات مطوّري Android" المتوفّرة في حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
Android Debug Bridge (adb)
[C-0-2] يجب أن تتوافق مع أداة تصحيح الأخطاء Android Debug Bridge (adb) كما هو موضّح في حزمة تطوير البرامج (SDK) لنظام التشغيل Android وأوامر shell المتوفّرة في مشروع Android مفتوح المصدر (AOSP)، والتي يمكن أن يستخدمها مطوّرو التطبيقات، بما في ذلك dumpsys وcmd stats وSimpleperf.
[C-0-11] يجب أن يتوافق مع أمر shell cmd testharness. قد يتم إعفاء عمليات ترقية تنفيذ الأجهزة من إصدار 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
- InputDeviceUsageReported
- JobStateChanged
- KeyboardConfigured
- KeyboardSystemsEventReported
- PluggedStateChanged
- PressureStallInformation
- ScheduledJobStateChanged
- ScreenStateChanged
- SyncStateChanged
- SystemElapsedRealtime
- TouchpadUsage
- 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 عبر شبكة المنطقة المحلية (مثل Ethernet أو Wi-Fi).
[C-3-2] يجب توفير برامج تشغيل لنظام التشغيل Windows 7 و8 و10، ما يتيح للمطوّرين الاتصال بالجهاز باستخدام بروتوكول adb.

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

[C-4-1] يجب أن تعرض الطريقة AdbManager#isAdbWifiSupported() القيمة true.

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

[C-5-1] يجب أن تعرض الطريقة AdbManager#isAdbWifiQrSupported() القيمة true.
خدمة مراقبة تصحيح الأخطاء في Dalvik (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 يتوافق مع سطر الأوامر في مستندات 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.
وضع مفعِّل الاختبار

إذا كانت عمليات تنفيذ الأجهزة تتيح أمر shell cmd testharness وتشغّل cmd testharness enable، يجب أن تستوفي ما يلي:
- [C-2-1] يجب إرجاع true مقابل ActivityManager.isRunningInUserTestHarness()
- [C-2-2] يجب تنفيذ "وضع مفعِّل الاختبار" كما هو موضّح في مستندات "وضع مفعِّل الاختبار".
معلومات عن عمل وحدة معالجة الرسومات

عمليات تنفيذ الجهاز:
- [C-0-13] يجب تنفيذ أمر shell dumpsys gpu --gpuwork لعرض بيانات عمل وحدة معالجة الرسومات المجمّعة التي تم إرجاعها من نقطة تتبُّع النواة power/gpu_work_period، أو عدم عرض أي بيانات إذا كانت نقطة التتبُّع غير متاحة. تكون عملية التنفيذ في AOSP frameworks/native/services/gpuservice/gpuwork/.

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

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

إذا ضبطت عمليات تنفيذ الأجهزة سمتَي النظام graphics.gpu.profiler.support وgraphics.gpu.profiler.support.gpu_frequency على true، عليها استيفاء ما يلي:

[C-6-1] يجب تسجيل نقطة تتبُّع "معدّل تكرار وحدة معالجة الرسومات" بالتنسيق power/gpu_frequency المحدّد في power.proto.

إذا ضبطت عمليات تنفيذ الأجهزة سمتَي النظام graphics.gpu.profiler.support وgraphics.gpu.profiler.support.gpu_counters على true، عليها استيفاء ما يلي:

[C-7-1] يجب توفير أداة إنشاء بيانات Perfetto لمصدر بيانات باسم gpu.counters، ويمكن طلب البحث عنه باستخدام: perfetto --query.
[C-7-2] يجب الإبلاغ عن أوصاف عدّادات وحدة معالجة الرسومات بما يتوافق مع بروتوكول حزمة تتبُّع عدّادات وحدة معالجة الرسومات.
[C-7-3] يجب الإبلاغ عن قيم متوافقة لعدّادات وحدة معالجة الرسومات (GPU) بالجهاز باتّباع بروتوكول حزمة تتبُّع عدّاد وحدة معالجة الرسومات.
[C-7-4] يجب تسجيل الأوصاف النصية لجميع عدّادات وحدة معالجة الرسومات المفعَّلة بدون طابع زمني لتتبُّع perfetto.
[C-7-6] يجب توفير مجموعة تلقائية غير فارغة من عدّادات أداء وحدة معالجة الرسومات لأغراض تحديد المشاكل، كما هو موضّح في GpuCounterSpec#select_by_default.
- يجب أن يكون من الممكن تفعيل جميع العدادات التلقائية هذه في الوقت نفسه.
- يجب أن تُرسِل جميعها قيمًا إلى Perfetto عند تفعيلها.
[C-7-7] يجب أن يعرض استخدام وحدة معالجة الرسومات لعداد واحد على الأقل يتم اختياره تلقائيًا، وذلك باستخدام GpuCounterSpec#select_by_default.

إذا ضبطت عمليات تنفيذ الأجهزة سمتَي النظام graphics.gpu.profiler.support وgraphics.gpu.profiler.support.gpu_counters.period على true، عليها استيفاء ما يلي:

[C-8-1] يجب الالتزام counter_period_ns بمعدّل أخذ عيّنات عدّادات وحدة معالجة الرسومات. يجب أن يكون معدّل أخذ العينات المتوافق ملي ثانية واحدة أو أسرع.
[C-SR-1] يُنصح بشدة بتوفير معدّل أخذ عيّنات يبلغ 0.2 ملّي ثانية أو أسرع.

إذا ضبطت عمليات تنفيذ الأجهزة سمتَي النظام graphics.gpu.profiler.support وgraphics.gpu.profiler.support.gpu_counters.groups على true، عليها استيفاء ما يلي:

[C-9-1] يجب أن يتضمّن كل من مجموعات عدّادات وحدة معالجة الرسومات التالية عدّادًا واحدًا على الأقل، كما هو محدّد في GpuCounterSpec: COMPUTE وFRAGMENTS وMEMORY وPRIMITIVES وVERTICES.

إذا ضبطت عمليات تنفيذ الأجهزة كلتا سمتَي النظام graphics.gpu.profiler.support وgraphics.gpu.profiler.support.gpu_counters.groups على true، وكان الجهاز متوافقًا مع تتبُّع الأشعة، فإنّها:

[C-10-1] يجب أن يتضمّن RAY_TRACING عدّادًا.

إذا ضبطت عمليات تنفيذ الأجهزة سمتَي النظام graphics.gpu.profiler.support وgraphics.gpu.profiler.support.gpu_counters.zeroes_optimization على true، عليها استيفاء ما يلي:
[C-11-1] ضِمن جلسة تتبُّع Perfetto نفسها، يجب ألا تعرض عدّادات وحدة معالجة الرسومات قيمًا صفرية إلا إذا كانت القيمة السابقة أو اللاحقة المعروضة غير صفرية.

إذا ضبطت عمليات تنفيذ الأجهزة سمتَي النظام graphics.gpu.profiler.support وgraphics.gpu.profiler.support.render_stages على true، عليها استيفاء ما يلي:

[C-12-1] يجب توفير أداة إنشاء بيانات Perfetto لمصدر بيانات باسم gpu.renderstages، ويمكن طلب البحث فيه باستخدام perfetto --query.
[C-12-2] يجب إعداد تقارير عن القيم المتوافقة لمراحل العرض على وحدة معالجة الرسومات (GPU) باتّباع نموذج أوّلي لحدث مرحلة العرض على وحدة معالجة الرسومات.

إذا ضبطت عمليات تنفيذ الأجهزة سمتَي النظام graphics.gpu.profiler.support وgraphics.gpu.profiler.support.render_stages.queue_submit على true، عليها استيفاء ما يلي:

[C-13-1] لكل طلب إرسال إلى قائمة انتظار Vulkan، يجب أن يصدر برنامج تشغيل Vulkan حدث تتبُّع Perfetto وفقًا لمواصفات رسالة حدث Vulkan API.
- يجب أن يحتوي هذا الحدث على submission_id فريد ومتزايد بشكل رتيب يتطابق مع submission_id في حدث مرحلة العرض المقابل على وحدة معالجة الرسومات.

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

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

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

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

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

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

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

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

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

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

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

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

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

[C-0-1] يجب، بشكلٍ تلقائي، عرض تطبيقات الجهات الخارجية على شاشات متوافقة مع Android فقط.

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

الحجم القطري الفعلي المسافة بالبوصة بين زاويتين متقابلتين من الجزء المضاء في الشاشة
الكثافة عدد وحدات البكسل التي يشملها مدى أفقي أو عمودي خطي يبلغ بوصة واحدة، ويتم التعبير عنه بوحدات البكسل لكل بوصة (ppi أو dpi). عند إدراج قيم النقاط لكل بوصة (ppi) والنقاط في البوصة (dpi)، يجب أن تندرج كل من قيم النقاط في البوصة الأفقية والعمودية ضمن النطاق المُدرَج.
نسبة العرض إلى الارتفاع نسبة وحدات البكسل في البُعد الأطول إلى البُعد الأقصر للشاشة على سبيل المثال، إذا كانت الشاشة تعرض 480 × 854 بكسل، ستكون نسبة العرض إلى الارتفاع 854 / 480 = 1.779، أو "16:9" تقريبًا.
وحدة بكسل مستقلة الكثافة (dp) وحدة بكسل افتراضية تمّت تسويتها لتناسب كثافة شاشة تبلغ 160. بالنسبة إلى بعض الكثافات d وعدد وحدات البكسل p، يتم احتساب عدد وحدات البكسل المستقلة عن الكثافة dp على النحو التالي: 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 بكسل مستقل الكثافة × 320 بكسل مستقل الكثافة على الأقل.
- يجب أن يكون حجم normal الذي تعرضه Configuration.screenLayout 480 وحدة بكسل مستقلة عن الكثافة × 320 وحدة بكسل مستقلة عن الكثافة على الأقل.
- يجب أن يكون حجم Configuration.screenLayout الذي تعرضه الأجهزة large 640 بكسل مستقل الكثافة × 480 بكسل مستقل الكثافة على الأقل.
- يجب أن تتضمّن الأجهزة التي تعرض حجم xlarge للسمة Configuration.screenLayout على الأقل 960 وحدة بكسل مستقلة عن الكثافة × 720 وحدة بكسل مستقلة عن الكثافة.
[C-0-2] يجب أن يلتزم الجهاز بشكل صحيح ببيان التطبيقات عن توافقها مع أحجام الشاشات من خلال السمة <supports-screens> في AndroidManifest.xml، كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) لنظام Android.
قد تتضمّن شاشات متوافقة مع Android بزوايا دائرية.

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

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

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

[C-4-1] يجب أن يكون حجم التصميم، باستثناء أي فتحات عرض، 596 وحدة بكسل مستقلة الكثافة × 384 وحدة بكسل مستقلة الكثافة على الأقل أو أكبر.

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

[C-4-1] تمت إزالة هذا الشرط في Android 15.

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

تمت إزالة هذا القسم في نظام التشغيل Android 14.

‫7.1.1.3. كثافة الشاشة

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

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

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

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

[C-1-1] يجب ألا يتم توسيع العرض بمقدار أكبر من 1.5 مرة DENSITY_DEVICE_STABLE أو إنتاج حد أدنى فعّال لأبعاد الشاشة أصغر من 320 وحدة بكسل مستقلة الكثافة (أي ما يعادل مؤهّل الموارد 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] تمت إزالة هذا الشرط في الإصدار Android 16.
[C-1-2] يجب عدم تغيير حجم الشاشة أو كثافتها عند تغيير اتجاهها.
يمكن اختيار الاتجاه العمودي أو الأفقي كإعداد تلقائي.

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

‫7.1.4.1. OpenGL ES

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

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

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

[C-1-1] يجب أن تتوافق مع OpenGL ES 1.1 و2.0 و3.0 و3.1، كما هو موضح بالتفصيل في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
[C-SR-1] تمت إزالة هذا الشرط في Android 15.
يجب أن يتوافق مع OpenGL ES 3.2.

يتم تقسيم اختبارات dEQP الخاصة بـ OpenGL ES إلى عدد من قوائم الاختبارات، ولكل منها تاريخ أو رقم إصدار مرتبط. ويمكن العثور عليها في شجرة المصدر لنظام Android على الرابط external/deqp/android/cts/main/glesXX-master-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.

يتم تقسيم اختبارات dEQP في Vulkan إلى عدد من قوائم الاختبارات، ولكل منها تاريخ/إصدار مرتبط. ويمكن العثور عليها في شجرة المصدر لنظام Android على الرابط external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt. يشير الجهاز المتوافق مع Vulkan على مستوى تم الإبلاغ عنه ذاتيًا إلى أنّه يمكنه اجتياز اختبارات dEQP في جميع قوائم الاختبارات من هذا المستوى والمستويات السابقة.

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

[C-1-1] يجب عرض قيمة العدد الصحيح الصحيحة باستخدام علامتَي الميزة android.hardware.vulkan.level وandroid.hardware.vulkan.version.
[C-1-2] يجب تعداد VkPhysicalDevice واحدة على الأقل لواجهة برمجة التطبيقات الأصلية vkEnumeratePhysicalDevices() الخاصة بـ Vulkan.
[C-1-3] يجب تنفيذ واجهات برمجة التطبيقات Vulkan 1.1 بالكامل لكل VkPhysicalDevice تم تعدادها.
[C-1-4] يجب تعداد الطبقات المضمّنة في المكتبات المجمّعة من رموز برمجية أصلية والتي تحمل الاسم libVkLayer*.so في دليل المكتبات المجمّعة من رموز برمجية أصلية الخاص بحزمة التطبيق، وذلك من خلال واجهات برمجة التطبيقات الأصلية vkEnumerateInstanceLayerProperties() وvkEnumerateDeviceLayerProperties() الخاصة بـ Vulkan.

[C-1-5] يجب عدم تعداد الطبقات التي توفّرها المكتبات خارج حزمة التطبيق، أو توفير طرق أخرى لتتبُّع واجهة برمجة تطبيقات Vulkan أو اعتراضها، ما لم يتم ضبط السمة android:debuggable للتطبيق على true أو ضبط البيانات الوصفية com.android.graphics.injectLayers.enable على true ، باستثناء طبقات مصنّع المعدات الأصلية والمنصّة وفقًا لمستندات تنفيذ Vulkan.

[C-1-6] يجب عرض جميع سلاسل الإضافات المتوافقة من خلال واجهات برمجة التطبيقات الأصلية في Vulkan، ويجب عدم عرض سلاسل الإضافات غير المتوافقة.

[C-1-7] يجب أن تتوافق مع الإضافات التالية:
- VK_EXT_present_mode_fifo_latest_ready
- VK_KHR_present_wait2
- VK_KHR_android_surface
- VK_KHR_incremental_present
- VK_KHR_present_id
- VK_KHR_present_id2
- VK_KHR_surface
- VK_KHR_swapchain

[C-1-8] يجب الإبلاغ عن الحد الأقصى لإصدار "اختبارات dEQP" في Vulkan المتوافقة من خلال علامة الميزة android.software.vulkan.deqp.level.
[C-1-9] يجب أن يتوافق مع الإصدار 132317953 على الأقل (اعتبارًا من 1 آذار (مارس) 2019) كما هو موضّح في علامة الميزة android.software.vulkan.deqp.level.
[C-1-10] يجب اجتياز جميع اختبارات dEQP في Vulkan في قوائم الاختبارات بين الإصدار 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_EXT_present_timing
- VK_GOOGLE_display_timing
- VK_KHR_driver_properties

[C-1-12] يجب عدم إدراج دعم الإضافة VK_KHR_performance_query.
[C-SR-4] يُنصَح بشدة بتلبية المتطلبات المحدّدة في الملف الشخصي Android Baseline 2022.
[C-SR-5] يُنصح بشدة بتوفير الدعم VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory وVK_EXT_global_priority.
[C-SR-6] يُنصح بشدة باستخدام SkiaVk مع HWUI.

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

[C-SR-8] يُنصح بشدة بعدم تعديل برنامج تحميل Vulkan.
[C-1-14] يجب عدم تعداد إضافات جهاز Vulkan من النوع "KHR" أو "GOOGLE" أو "ANDROID" ما لم يتم تضمين هذه الإضافات في علامة الميزة android.software.vulkan.deqp.level.

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

[C-2-1] يجب عدم الإفصاح عن أي من علامات ميزات Vulkan (مثل android.hardware.vulkan.level وandroid.hardware.vulkan.version).
[C-2-2] يجب عدم تعداد أي VkPhysicalDevice لواجهة Vulkan الأصلية API vkEnumeratePhysicalDevices().

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

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

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

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

[C-0-3] يجب أن تتوافق مع واجهة برمجة التطبيقات TextureView، ويجب أن يكون سلوكها متوافقًا مع تنفيذ Android في المصدر.

‫7.1.4.5. شاشات العرض ذات التدرّج اللوني الواسع

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

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

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

[C-2-1] يجب أن تغطي مساحة الألوان sRGB بالكامل أو أكثر في مساحة CIE 1931 xyY، على الرغم من أنّ نطاق ألوان الشاشة غير محدّد.

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

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

‫7.1.6. تقنية الشاشة

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

جميع شاشات عرض الأجهزة المتوافقة مع Android:

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

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

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

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

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

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

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

[C-0-1] يجب أن يتضمّن آلية إدخال، مثل شاشة تعمل باللمس أو تنقّل غير مستند إلى اللمس، للتنقّل بين عناصر واجهة المستخدم.

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

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

[C-1-1] يجب الإفصاح عن علامة الميزة android.software.input_methods.
[C-1-2] يجب تنفيذ Input Management Framework بالكامل
[C-1-3] يجب أن يتضمّن لوحة مفاتيح افتراضية مثبَّتة مسبقًا.

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

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

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

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

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

[C-0-1] يجب عرض القيمة الصحيحة لـ android.content.res.Configuration.navigation.

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

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

‫7.2.3. مفاتيح التنقل

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

[C-0-1] يجب توفير وسيلة تتيح للمستخدم تشغيل التطبيقات المثبَّتة التي تتضمّن نشاطًا تم ضبط <intent-filter> فيه على ACTION=MAIN وCATEGORY=LAUNCHER أو CATEGORY=LEANBACK_LAUNCHER في عمليات تنفيذ تطبيقات أجهزة التلفزيون. يجب أن تكون وظيفة "الصفحة الرئيسية" هي الآلية التي تتيح للمستخدم الاستفادة من هذه الميزة.
يجب توفير أزرار لوظيفتَي "التطبيقات المستخدَمة مؤخرًا" و"الرجوع".

في حال توفّر وظائف "الشاشة الرئيسية" أو "التطبيقات الحديثة" أو "الرجوع"، يجب أن:

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

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

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

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

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

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

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

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

[C-6-1] يجب استخدام WindowInsets#getMandatorySystemGestureInsets() للإبلاغ عن منطقة التعرّف على إيماءة "الرجوع إلى الشاشة الرئيسية" فقط.
[C-6-2] يجب عدم اعتراض الإيماءات التي تبدأ داخل مستطيل استبعاد تقدّمه التطبيقات التي تعمل في المقدّمة من خلال View#setSystemGestureExclusionRects()، ولكن خارج WindowInsets#getMandatorySystemGestureInsets()، لوظيفة التنقّل طالما أنّ مستطيل الاستبعاد مسموح به ضمن الحد الأقصى للاستبعاد المحدّد في مستندات View#setSystemGestureExclusionRects().
[C-6-3] يجب إرسال حدث MotionEvent.ACTION_CANCEL إلى التطبيق الذي يعمل في المقدّمة عند بدء اعتراض اللمسات لتنفيذ إيماءة نظام التشغيل، إذا سبق أن تم إرسال حدث MotionEvent.ACTION_DOWN إلى التطبيق الذي يعمل في المقدّمة.
[C-6-4] يجب توفير وسيلة تتيح للمستخدم التبديل إلى التنقّل المستند إلى الأزرار على الشاشة (على سبيل المثال، في "الإعدادات").
يجب توفير وظيفة "الشاشة الرئيسية" من خلال التمرير سريعًا من الحافة السفلية للشاشة إلى أعلاها في الاتجاه الحالي للشاشة.
يجب توفير وظيفة "التطبيقات الحديثة" من خلال التمرير سريعًا للأعلى مع الاستمرار في الضغط قبل رفع الإصبع، وذلك من المنطقة نفسها التي يتم منها تنفيذ إيماءة "الصفحة الرئيسية".
يجب ألا تتأثر الإيماءات التي تبدأ ضمن WindowInsets#getMandatorySystemGestureInsets() بمستطيلات الاستبعاد التي يوفّرها التطبيق الذي يعمل في المقدّمة من خلال View#setSystemGestureExclusionRects().

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

[C-7-1] يجب أن تكون وظيفة التنقّل هي "رجوع"، ويجب توفيرها من خلال التمرير السريع من الحافتين اليمنى واليسرى للشاشة في اتجاهها الحالي.
[C-7-2] في حال توفير لوحات نظام مخصّصة يمكن التمرير سريعًا عليها على الحافتين اليمنى أو اليسرى، يجب وضعها ضمن الثلث العلوي من الشاشة مع توفير إشارة مرئية واضحة وثابتة تشير إلى أنّ السحب سيؤدي إلى استدعاء اللوحات المذكورة أعلاه، وبالتالي لن يتم الرجوع إلى الخلف. يمكن للمستخدم ضبط لوحة النظام بحيث تظهر أسفل الثلث العلوي من حواف الشاشة، ولكن يجب ألا تستخدم لوحة النظام أكثر من ثلث الحواف.
[C-7-3] عندما يكون التطبيق الذي يعمل في المقدّمة قد تم ضبطه على إحدى العلامات View.SYSTEM_UI_FLAG_IMMERSIVE أو View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY أو WindowInsetsController.BEHAVIOR_DEFAULT أو WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE، يجب أن يكون سلوك التمرير السريع من الحواف مطابقًا لما تم تنفيذه في مشروع Android المفتوح المصدر (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، يجب إخفاء لوحات النظام المخصّصة القابلة للتمرير السريع إلى أن يعرض المستخدم أشرطة النظام أو يزيل تعتيمها (المعروفة أيضًا باسم شريطَي التنقّل والحالة) كما هو موضّح في مشروع Android المفتوح المصدر (AOSP).

في حال توفير وظيفة التنقّل للخلف وألغى المستخدم إيماءة الرجوع، سيحدث ما يلي:

يجب استدعاء [C-8-1] OnBackInvokedCallback.onBackCancelled().
[C-8-2] يجب عدم استدعاء OnBackInvokedCallback.onBackInvoked().
[C-8-3] يجب عدم إرسال الحدث KEYCODE_BACK.

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

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

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

[C-9-1] يجب توفير دعم للرموز المناسبة للأطفال أو التنقّل المستند إلى الأزرار كما هو موضّح في رمز 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 التي تتوافق مع نوع شاشة اللمس المحدّدة على الجهاز.

إذا كانت عمليات تنفيذ الأجهزة تعتمد على جهاز إدخال خارجي، مثل الماوس أو كرة التتبُّع (أي عدم لمس الشاشة مباشرةً) للإدخال على شاشة أساسية متوافقة مع 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

زرّ	استخدام HID²	زر Android
A¹	0x09 0x0001	KEYCODE_BUTTON_A (96)
B¹	0x09 0x0002	KEYCODE_BUTTON_B (97)
X¹	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y¹	0x09 0x0005	KEYCODE_BUTTON_Y (100)
لوحة التحكم للأعلى¹ لوحة التحكم للأسفل¹	0x01 0x0039³	AXIS_HAT_Y⁴
لوحة التحكم لليسار1 لوحة التحكم لليمين¹	0x01 0x0039³	AXIS_HAT_X⁴
زر الكتف الأيسر¹	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
زر الكتف الأيمن¹	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
النقر على عصا التحكّم اليسرى¹	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
النقر على عصا التحكّم اليمنى¹	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
رجوع¹	0x0c 0x0224	KEYCODE_BACK (4)

‫1 KeyEvent

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

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

‫4 MotionEvent

عناصر التحكّم التناظرية¹	استخدام 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. أجهزة الاستشعار

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

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

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

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

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

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

[C-1-6] يجب ضبط دقة غير صفرية لجميع المستشعرات، والإبلاغ عن القيمة باستخدام طريقة واجهة برمجة التطبيقات Sensor.getResolution().

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

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

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

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

‫[C-2-1] يجب تنفيذ أداة الاستشعار على النحو الموضّح في مستندات Android Open Source حول أدوات الاستشعار المركّبة.

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

[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] يجب أن يكون الجهاز قادرًا على قياس التسارع الناتج عن السقوط الحر حتى أربعة أضعاف gravity(4g) أو أكثر على أي محور.
[C-1-5] يجب أن تكون درجة الدقة 12 بت على الأقل.
[C-1-6] يجب أن يكون الانحراف المعياري أقل من أو يساوي 0.05 م/ث^2، حيث يجب احتساب الانحراف المعياري لكل محور على أساس العيّنات التي تم جمعها على مدار 3 ثوانٍ على الأقل بأسرع معدّل أخذ عيّنات.
يجب أن يتم تسجيل الأحداث بمعدّل 200 هرتز على الأقل.
يجب أن تكون درجة الدقة 16 بت على الأقل.
يجب معايرته أثناء الاستخدام إذا تغيرت الخصائص على مدار دورة الحياة وتعويضها، ويجب الاحتفاظ بمعلمات التعويض بين عمليات إعادة تشغيل الجهاز.
يجب أن يكون مزوّدًا بمُعدِّل حرارة.

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

[C-2-1] يجب تنفيذ جهاز استشعار TYPE_ACCELEROMETER وإعداد تقرير عنه.
[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 وإعداد تقرير عنه.
[C-SR-6] يُنصح بشدة بتنفيذ TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED والإبلاغ عن بياناته.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس تسارع ثلاثي المحاور وأي من أجهزة الاستشعار المركّبة 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 µT و‎+900 µT على كل محور قبل التشبع.
[C-1-5] يجب أن تكون قيمة إزاحة الحديد الصلب أقل من 700 µT، ويجب أن تكون القيمة أقل من 200 µT، وذلك عن طريق وضع مقياس المغناطيسية بعيدًا عن المجالات المغناطيسية الديناميكية (الناتجة عن التيار) والثابتة (الناتجة عن المغناطيس).
‫[C-1-6] يجب أن تكون درجة الدقة مساوية لـ 0.6 µT أو أعلى.
[C-1-7] يجب أن يتيح الجهاز إجراء المعايرة والتعويض على الإنترنت عن انحراف الحديد الصلب، وأن يحتفظ بمعلمات التعويض بين عمليات إعادة تشغيل الجهاز.
[C-1-8] يجب تطبيق تعويض الحديد اللين، ويمكن إجراء المعايرة أثناء الاستخدام أو أثناء إنتاج الجهاز.
[C-1-9] يجب أن يكون هناك انحراف معياري محسوب على أساس كل محور من العينات التي تم جمعها على مدار فترة لا تقل عن 3 ثوانٍ بأسرع معدل أخذ عينات، ولا يزيد عن 1.5 µT، ويجب أن يكون هناك انحراف معياري لا يزيد عن 0.5 µT.
[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] يجب أن يكون الجهاز قادرًا على تحديد الموقع الجغرافي في ظروف السماء المفتوحة (إشارات قوية، وتعدد مسارات ضئيل، ودقة أفقية للتخفيف من حدة التدهور < 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] يُنصح بشدة بمواصلة تقديم نواتج الموقع الجغرافي العادية لنظام تحديد المواقع العالمي (GPS) أو نظام الملاحة العالمي عبر الأقمار الصناعية (GNSS) من خلال واجهات برمجة التطبيقات الخاصة بمزوّد خدمة الموقع الجغرافي لنظام GNSS أثناء مكالمة هاتفية للطوارئ.
[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 متر في الثانية، وذلك في ظروف السماء المفتوحة بعد تحديد الموقع الجغرافي، سواء كان الجهاز ثابتًا أو يتحرّك بمعدّل تسارع أقل من 0.2 متر في الثانية المربعة، على أن يتم ذلك بنسبة% 95 من الوقت على الأقل.

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

عمليات تنفيذ الأجهزة التي تعرّف خاصية النظام sensor.barometer.high_quality.implemented:

‫[C-2-1] يجب أن تعرض القياسات في نطاق يتراوح بين 300 هكتوباسكال و1100 هكتوباسكال، مع دقة مطلقة تبلغ ‎+/- 1 هكتوباسكال.
[C-2-2] يجب أن تبلغ الدقة النسبية 0.15 هكتوباسكال على مدى 100 هكتوباسكال، أي ما يعادل دقة تبلغ مترًا واحدًا تقريبًا على مدى تغيير يبلغ 1, 000 متر تقريبًا عند مستوى سطح البحر.
‫[C-2-3] يجب أن يكون الضغط الجوي ثابتًا في نطاق ‎+/- 0.5 hPa عندما ينقر المستخدم على الجهاز أو يضغط عليه أو يعصره.
‫[C-2-4] يجب أن يكون مستقرًا في حدود ‎+/- 0.15 hPa عندما يمشي المستخدم حاملاً الجهاز في يده أو في جيبه.
[C-2-5] يجب عدم تنعيمها بثابت زمني يزيد عن 300 مللي ثانية لعمليات التفعيل التي تزيد عن 5 هرتز، ويجب ألا يؤدي التنعيم إلى تداخل عمليات تفعيل المستشعر.
‫[C-2-6] يجب أن يكون مستقرًا في نطاق ‎+/- 0.15 hPa عند تعرّضه للإضاءة اليومية والترددات اللاسلكية الصادرة عن مصادر شائعة، مثل البلوتوث أو الاتصال بشبكة الجوّال أو شبكة Wi-Fi.

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

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

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

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

[C-2-1] يجب عدم تحديد SENSOR_TYPE_AMBIENT_TEMPERATURE لجهاز استشعار الحرارة.

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

[C-SR-1] يُنصح بشدة بتوفير واجهة برمجة التطبيقات PowerManager.getThermalHeadroom.

‫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 التي:
- يجب أن يتوفّر نطاق قياس بين ‎-8g و‎+8g على الأقل، ويُنصح بشدة أن يتوفّر نطاق قياس بين ‎-16g و‎+16g على الأقل.
- يجب أن تبلغ درجة دقة القياس 2048 LSB/g على الأقل.
- يجب أن يكون الحدّ الأدنى لتردّد القياس 12.5 هرتز أو أقل.
- يجب أن يكون الحدّ الأقصى لوتيرة القياس 400 هرتز أو أكثر. يجب أن يتوافق مع SensorDirectChannel RATE_VERY_FAST.
- يجب ألا يتجاوز تشويش القياس 400 μg/√Hz.
- يجب تنفيذ شكل غير مُفعِّل لهذا المستشعر مع إمكانية التخزين المؤقت لما لا يقل عن 3000 حدث من أحداث المستشعر.
- يجب ألا يزيد استهلاك الطاقة في عملية تجميع البيانات عن 3 ملّي واط.
- [C-SR-1] يُنصح بشدة أن يكون عرض نطاق القياس عند 3 ديسيبل بنسبة% 80 على الأقل من تردد نيكويست، وأن يكون طيف الضوضاء البيضاء ضمن عرض النطاق هذا.
- يجب أن يكون معدّل التغيّر العشوائي في التسارع أقل من 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&°/s/√Hz.
- [C-SR-2] يُنصح بشدة أن يكون عرض نطاق قياس 3 ديسيبل بنسبة% 80 على الأقل من تردد نيكويست، وأن يكون طيف الضوضاء البيضاء ضمن عرض النطاق هذا.
- يجب أن يكون معدّل المشي العشوائي أقل من 0.001&°/s √Hz عند اختباره في درجة حرارة الغرفة.
- يجب أن يكون التغيّر في الانحياز مقارنةً بدرجة الحرارة ≤ +/- 0.05&°/ s / °C.
- يجب أن يكون معدّل تغيُّر الحساسية مقارنةً بدرجة الحرارة ≤ 0.02% / درجة مئوية.
- يجب أن يكون الانحراف عن الخطية لأفضل خط مناسب ≤ 0.2%.
- يجب أن تبلغ كثافة الضوضاء فيها ‎≤ 0.007&°/s/√Hz.
- يجب أن يكون خطأ المعايرة أقل من 0.002 راديان/ثانية في نطاق درجة الحرارة من 10 إلى 40 درجة مئوية عندما يكون الجهاز ثابتًا.
- يجب أن تكون حساسية التسارع أقل من 0.1&°/s/g.
- يجب أن تبلغ حساسية المحور المتقاطع أقل من % 4.0 وأن يكون تفاوت حساسية المحور المتقاطع أقل من% 0.3 في نطاق درجة حرارة تشغيل الجهاز.
[C-2-4] يجب أن يحتوي على TYPE_GYROSCOPE_UNCALIBRATED يستوفي متطلبات الجودة نفسها التي يستوفيها TYPE_GYROSCOPE.
[C-2-5] يجب أن يحتوي على أداة استشعار TYPE_GEOMAGNETIC_FIELD التي:
- يجب أن يتضمّن نطاق قياس بين 900- و900+ ميكرو تسلا على الأقل.
- يجب أن تبلغ درجة دقة القياس 5 LSB/uT على الأقل.
- يجب أن يكون الحد الأدنى لتكرار القياس 5 هرتز أو أقل.
- يجب أن يكون الحد الأقصى لوتيرة القياس 50 هرتز أو أكثر.
- يجب ألا يتجاوز التشويش في القياس 0.5 ميكرو تسلا.
[C-2-6] يجب أن تتضمّن TYPE_MAGNETIC_FIELD_UNCALIBRATED بالجودة نفسها التي تتطلّبها TYPE_GEOMAGNETIC_FIELD، بالإضافة إلى ما يلي:
- يجب تنفيذ شكل غير مفعّل من هذا المستشعر مع إمكانية التخزين المؤقت لما لا يقل عن 600 حدث من أحداث المستشعر.
- [C-SR-3] يُنصح بشدة بأن يتضمّن الطيف الضوضائي الأبيض نطاقًا من 1 هرتز إلى 10 هرتز على الأقل عندما يكون معدّل إعداد التقارير 50 هرتز أو أعلى.
[C-2-7] يجب أن يحتوي على أداة استشعار TYPE_PRESSURE التي:
- يجب أن يتراوح نطاق القياس بين 300 و1100 هكتوباسكال على الأقل.
- يجب أن تبلغ دقة القياس 80 LSB/hPa على الأقل.
- يجب أن يكون الحدّ الأدنى لتكرار القياس 1 هرتز أو أقل.
- يجب أن يكون الحد الأقصى لعدد مرات القياس 10 هرتز أو أكثر.
- يجب ألا يزيد مستوى التشويش في القياس عن 2 Pa/√Hz.
- يجب تنفيذ شكل غير مفعّل لهذا المستشعر مع إمكانية التخزين المؤقت لما لا يقل عن 300 حدث من أحداث المستشعر.
- يجب أن يكون استهلاك الطاقة في عملية تجميع البيانات لا يزيد عن 2 ملّي واط.
[C-2-8] يجب أن يحتوي على مستشعر TYPE_GAME_ROTATION_VECTOR.
[C-2-9] يجب أن يحتوي الجهاز على أداة استشعار TYPE_SIGNIFICANT_MOTION التي:
- يجب ألا يزيد استهلاك الطاقة عن 0.5 ملّي واط عندما يكون الجهاز ثابتًا، وعن 1.5 ملّي واط عندما يكون الجهاز متحركًا.
[C-2-10] يجب أن يحتوي على أداة استشعار TYPE_STEP_DETECTOR تتضمّن ما يلي:
- يجب تنفيذ شكل غير مفعّل من أداة الاستشعار هذه مع إمكانية التخزين المؤقت لما لا يقل عن 100 حدث من أحداث أداة الاستشعار.
- يجب ألا يزيد استهلاك الطاقة عن 0.5 ملّي واط عندما يكون الجهاز ثابتًا، وعن 1.5 ملّي واط عندما يكون الجهاز متحركًا.
- يجب ألا يزيد استهلاك الطاقة في عملية تجميع البيانات عن 4 ملّي واط.
[C-2-11] يجب أن يحتوي على أداة استشعار TYPE_STEP_COUNTER التي:
- يجب ألا يزيد استهلاك الطاقة عن 0.5 ملّي واط عندما يكون الجهاز ثابتًا، وعن 1.5 ملّي واط عندما يكون الجهاز متحركًا.
[C-2-12] يجب أن يحتوي على أداة استشعار TILT_DETECTOR تعمل على النحو التالي:
- يجب ألا يزيد استهلاك الطاقة عن 0.5 ملّي واط عندما يكون الجهاز ثابتًا، وعن 1.5 ملّي واط عندما يكون الجهاز متحركًا.
[C-2-13] يجب أن يكون الطابع الزمني للحدث نفسه الذي تم تسجيله بواسطة مقياس التسارع والجيروسكوب ومقياس المغناطيسية في حدود 2.5 ملي ثانية من بعضها البعض. يجب أن يكون الطابع الزمني للحدث الفعلي نفسه الذي تم تسجيله بواسطة مقياس التسارع والجيروسكوب في نطاق 0.25 مللي ثانية من بعضهما البعض.
[C-2-14] يجب أن تتضمّن أحداث مستشعر الجيروسكوب طوابع زمنية تستند إلى قاعدة الوقت نفسها التي يستند إليها نظام الكاميرا الفرعي، وأن يكون الخطأ في حدود 1 ملي ثانية.
[C-2-15] يجب أن يتم تسليم العيّنات إلى التطبيقات في غضون 5 مللي ثانية من وقت توفّر البيانات على أي من أجهزة الاستشعار المادية المذكورة أعلاه للتطبيق.
[C-2-16] يجب ألا يزيد استهلاك الطاقة عن 0.5 ملّي واط عندما يكون الجهاز ثابتًا و2.0 ملّي واط عندما يكون الجهاز متحركًا عند تفعيل أي مجموعة من أجهزة الاستشعار التالية:
- SENSOR_TYPE_SIGNIFICANT_MOTION
- SENSOR_TYPE_STEP_DETECTOR
- SENSOR_TYPE_STEP_COUNTER
- SENSOR_TILT_DETECTORS
[C-2-17] قد يتضمّن جهاز الاستشعار TYPE_PROXIMITY، ولكن في حال توفّره، يجب أن تتوفّر فيه سعة تخزين مؤقت لا تقل عن 100 حدث من أحداث جهاز الاستشعار.

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

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

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

‫7.3.10. أجهزة استشعار المقاييس الحيوية

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

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

يجب أن يتضمّن مستشعرًا للمقاييس الحيوية

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

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

[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) ألا يزيد معدّل قبول الانتحال في فئة أدوات الهجوم من المستوى A للعرض التقديمي (PAI) عن ‎30%، و(2) ألا يزيد معدّل قبول الانتحال في فئة أدوات الهجوم من المستوى B للعرض التقديمي (PAI) عن ‎40%، وذلك وفقًا لما تحدّده بروتوكولات اختبار المقاييس الحيوية في Android.
[C-1-4] يجب منع إضافة مقاييس حيوية جديدة بدون إنشاء سلسلة ثقة أولاً من خلال مطالبة المستخدم بتأكيد بيانات اعتماد الجهاز الحالية أو إضافة بيانات اعتماد جديدة (رقم تعريف شخصي أو نقش أو كلمة مرور) يتم تأمينها بواسطة بيئة التنفيذ الموثوقة (TEE). يوفّر تنفيذ "مشروع Android المفتوح المصدر" الآلية اللازمة في إطار العمل لإجراء ذلك.
[C-1-5] يجب إزالة جميع بيانات المقاييس الحيوية التي يمكن التعرّف منها على المستخدم بشكل كامل عند إزالة حساب المستخدم (بما في ذلك من خلال إعادة الضبط على الإعدادات الأصلية) أو عند إزالة طريقة المصادقة الأساسية الموصى بها (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور).
[C-1-6] يجب الالتزام بالعلامة الفردية الخاصة بالمقاييس الحيوية (مثل DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT أو DevicePolicymanager.KEYGUARD_DISABLE_FACE أو DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
[C-1-7] يجب أن يطلب الجهاز من المستخدم إكمال عملية المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) مرة واحدة كل 24 ساعة أو أقل.
[C-1-8] يجب أن تطلب المصادقة الأساسية الموصى بها (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) أو المقاييس الحيوية من الفئة 3 (قوية) بعد حدوث أي مما يلي:
- فترة مهلة عدم النشاط لمدة 4 ساعات
- 3 محاولات فاشلة للمصادقة باستخدام المقاييس الحيوية
- تتم إعادة ضبط مدة المهلة عند عدم النشاط وعدد محاولات المصادقة غير الناجحة بعد أي تأكيد ناجح لبيانات اعتماد الجهاز.
[C-SR-7] يُنصح بشدة باستخدام المنطق الوارد في إطار العمل الذي يوفّره "مشروع مفتوح المصدر لنظام Android" لفرض القيود المحدّدة في [C-1-7] و[C-1-8] على الأجهزة الجديدة.
[C-SR-8] يُنصح بشدة بأن يكون معدّل الرفض الخاطئ أقل من %10، وذلك وفقًا لما يتم قياسه على الجهاز.
[C-SR-9] يُنصح بشدة أن يكون وقت الاستجابة أقل من ثانية واحدة، ويتم قياسه من وقت رصد المقاييس الحيوية إلى وقت فتح قفل الشاشة، وذلك لكل مقياس حيوي تم تسجيله.
[C-1-12] يجب ألا تزيد نسبة قبول عمليات الانتحال والتزوير عن %40 لكل نوع من أدوات الهجوم باستخدام العرض التقديمي (PAI)، وذلك وفقًا لما تحدّده بروتوكولات اختبار المقاييس الحيوية في Android.
[C-SR-13] يُنصح بشدة بأن يكون معدّل قبول عمليات الانتحال والتزوير أقل من %30 لكل نوع من أدوات هجوم العرض التقديمي (PAI)، وذلك وفقًا لما تحدّده بروتوكولات اختبار المقاييس الحيوية في Android.
[C-SR-8] يُنصح بشدة بأن يكون معدّل الرفض الخاطئ أقل من %10، وذلك وفقًا لما يتم قياسه على الجهاز.
‫[C-1-15] يجب أن تسمح للمستخدمين بإزالة عمليات تسجيل بيانات بيومترية فردية أو متعددة.
[C-SR-14] يُنصح بشدة بالإفصاح عن فئة المقاييس الحيوية لأداة استشعار المقاييس الحيوية والمخاطر المرتبطة بتفعيلها.
‫[C-SR-17] يُنصح بشدة بتنفيذ واجهات AIDL الجديدة (مثل IFace.aidl وIFingerprint.aidl).

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

[C-2-1] يجب استيفاء جميع متطلبات الفئة 1 أعلاه.
[C-2-2] يجب ألا يزيد معدّل قبول عمليات الانتحال عن ‎20%، مع (1) ألا يزيد معدّل قبول عمليات الانتحال باستخدام أدوات هجوم العرض التقديمي (PAI) من الفئة A عن ‎20%، و (2) ألا يزيد معدّل قبول عمليات الانتحال باستخدام أدوات هجوم العرض التقديمي من الفئة B عن ‎30%، وذلك وفقًا لما هو موضّح في بروتوكولات اختبار المقاييس الحيوية في Android.
[C-SR-15] يُنصح بشدة بأن لا تتجاوز نسبة قبول عمليات الانتحال والتزوير %20 لكل نوع من أدوات الهجوم باستخدام العرض التقديمي (PAI)، وذلك وفقًا لما تم قياسه باستخدام بروتوكولات اختبار المقاييس الحيوية في Android.
[C-2-3] يجب إجراء مطابقة المقاييس الحيوية في بيئة تنفيذ معزولة خارج مساحة المستخدم أو النواة في نظام التشغيل Android، مثل بيئة التنفيذ الموثوقة (TEE)، على شريحة تتضمّن قناة آمنة إلى بيئة التنفيذ المعزولة أو على جهاز افتراضي محمي يستوفي المتطلبات الواردة في القسم 9.17.
[C-2-4] يجب تشفير جميع البيانات التي يمكن تحديد هوية صاحبها والمصادقة عليها باستخدام التشفير، وذلك لضمان عدم إمكانية الحصول عليها أو قراءتها أو تعديلها خارج بيئة التنفيذ المعزولة أو شريحة مزوّدة بقناة آمنة إلى بيئة التنفيذ المعزولة كما هو موضّح في إرشادات التنفيذ على موقع مشروع Android مفتوح المصدر أو جهاز افتراضي محمي يتحكّم فيه مراقب الأجهزة الافتراضية يستوفي المتطلبات الواردة في الفقرة 9.17.
‫[C-2-5] بالنسبة إلى المقاييس الحيوية المستندة إلى الكاميرا، أثناء إجراء المصادقة أو التسجيل باستخدام المقاييس الحيوية:
- يجب تشغيل الكاميرا في وضع يمنع قراءة أو تعديل إطارات الكاميرا خارج بيئة التنفيذ المعزولة أو شريحة مزوّدة بقناة آمنة إلى بيئة التنفيذ المعزولة أو جهاز افتراضي محمي يتحكّم فيه برنامج مراقبة الأجهزة الافتراضية الذي يستوفي المتطلبات الواردة في الفقرة 9.17.
- بالنسبة إلى حلول الكاميرا الواحدة التي تستخدم النموذج اللوني أحمر أخضر أزرق، يمكن أن تكون إطارات الكاميرا قابلة للقراءة خارج بيئة التنفيذ المعزولة من أجل دعم عمليات مثل المعاينة للتسجيل، ولكن يجب ألا تكون قابلة للتغيير.
[C-2-6] يجب ألا تسمح التطبيقات التابعة لجهات خارجية بالتمييز بين عمليات تسجيل البيانات البيومترية الفردية.
[C-2-7] يجب عدم السماح بالوصول غير المشفّر إلى بيانات المقاييس الحيوية التي يمكن التعرّف على هوية صاحبها أو أي بيانات مشتقة منها (مثل عمليات التضمين) إلى معالج التطبيقات خارج سياق بيئة التنفيذ الموثوقة (TEE) أو الجهاز الافتراضي المحمي الذي يتحكّم فيه برنامج Hypervisor الذي يستوفي المتطلبات الواردة في الفقرة 9.17. لا يتم إعفاء الأجهزة التي تم إطلاقها بالإصدار 9 من نظام التشغيل Android أو الإصدارات الأقدم من [C-2-7].
[C-2-8] يجب أن يتضمّن الجهاز مسار معالجة آمنًا لا يسمح باختراق نظام التشغيل أو النواة لإدخال البيانات مباشرةً بهدف المصادقة بشكل زائف على أنّها بيانات المستخدم.

ملاحظة: إذا تم إطلاق عمليات تنفيذ الأجهزة على الإصدار 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) ألا يزيد معدّل قبول عمليات الانتحال باستخدام أدوات هجوم العرض التقديمي من الفئة B عن %20، وذلك وفقًا لما تحدّده بروتوكولات اختبار المقاييس الحيوية في Android.
‫[C-3-4] يجب أن تطلب المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) من المستخدم مرة واحدة كل 72 ساعة أو أقل.
[C-3-5] يجب إعادة إنشاء معرّف المصادقة لجميع المقاييس الحيوية من الفئة 3 المتوافقة مع الجهاز في حال إعادة تسجيل أي منها.
[C-3-6] يجب تفعيل مفاتيح مخزن المفاتيح المحمي بالمقاييس الحيوية للتطبيقات التابعة لجهات خارجية.
[C-SR-16] يُنصح بشدة بأن يكون معدّل قبول عمليات الانتحال والتزوير أقل من % 7 لكل نوع من أدوات الهجوم باستخدام العرض التقديمي (PAI)، وذلك وفقًا لما تم قياسه باستخدام بروتوكولات اختبار المقاييس الحيوية في Android.

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

[C-SR-11] يُنصح بشدة بتجنُّب تداخل مساحة اللمس الخاصة بأداة استشعار بصمة الإصبع تحت الشاشة (UDFPS) مع التنقّل باستخدام ثلاثة أزرار (وهي ميزة قد يحتاج إليها بعض المستخدمين لأغراض تسهيل الاستخدام).

‫7.3.11. مستشعر الوضع

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

قد تتوافق مع أداة استشعار الوضع التي تتضمّن 6 درجات حرية.

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

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

‫7.3.12. مستشعر زاوية المفصلة

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

[C-1-1] يجب تنفيذ TYPE_HINGE_ANGLE وإعداد تقرير عنه.
[C-1-2] يجب أن يتيح الجهاز قراءتَين على الأقل بين 0 و360 درجة (بما في ذلك 0 و360 درجة).
[C-1-3] يجب أن تعرض أداة استشعار getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE) wakeup.

‫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_RANGING (ضمن مجموعة الأذونات NEARBY_DEVICES).

يساعد اجتياز اختبارات المطابقة والشهادات ذات الصلة التي تحدّدها المؤسسات المعيارية، بما في ذلك FIRA وCCC وCSA، في ضمان عمل معيار 802.1.15.4 بشكل صحيح.

‫7.3.14. أجهزة الاستشعار المخصّصة

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

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

[C-0-1] يجب أن تكون القيمة أكبر من 65536.

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

[C-0-2] يجب أن تكون محمية إما بإذن من المنصة أو بإذن من النظام.

‫7.4. اتصال البيانات

‫7.4.1. الاتصالات الهاتفية

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

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

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

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

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

[C-2-1] يجب تنفيذ واجهات برمجة التطبيقات الكاملة كعمليات غير فعّالة.

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع بطاقات eUICC أو شرائح eSIM/شرائح SIM المضمّنة وتتضمّن آلية خاصة لإتاحة وظائف شريحة eSIM للمطوّرين التابعين لجهات خارجية، يجب أن تستوفي ما يلي:

[C-3-1] يجب الإفصاح عن android.hardware.telephony.euicc علامة الميزة.

إذا لم تضبط عمليات تنفيذ الأجهزة سمة النظام ro.telephony.iwlan_operation_mode على legacy، فإنّها:

[C-4-1] يجب عدم إرسال NETWORK_TYPE_IWLAN عبر NetworkRegistrationInfo#getAccessNetworkTechnology() عندما يتم إرسال NetworkRegistrationInfo#getTransportType() على أنّه TRANSPORT_TYPE_WWAN لنسخة NetworkRegistrationInfo نفسها.

إذا كانت عمليات تنفيذ الأجهزة تتيح عملية تسجيل واحدة في نظام IP Multimedia Subsystem (IMS) لكل من ميزات خدمة الاتصالات الهاتفية عبر الوسائط المتعددة (MMTEL) وخدمات الاتصالات التفاعلية (RCS)، وكان من المتوقّع أن تتوافق مع متطلبات مشغّل شبكة الجوّال بشأن استخدام عملية تسجيل واحدة في نظام IMS لجميع حركة بيانات إشارات IMS، يجب أن تستوفي ما يلي:

[C-5-1] يجب الإعلان عن علامة الميزة android.hardware.telephony.ims وتوفير عملية تنفيذ كاملة لواجهة برمجة التطبيقات ImsService API لكل من واجهة برمجة التطبيقات لتبادل إمكانات مستخدمي MMTEL وRCS.
[C-5-2] يجب الإفصاح عن علامة الميزة android.hardware.telephony.ims.singlereg وتوفير عملية تنفيذ كاملة لواجهة برمجة التطبيقات SipTransport API وواجهة برمجة التطبيقات GbaService API ومؤشرات الحامل المخصّص باستخدام طبقة تجريد الأجهزة (HAL) IRadio 1.6، وتوفير الخدمة من خلال خادم الإعداد التلقائي (ACS) أو آلية توفير خدمة خاصة أخرى باستخدام IMS Configuration API.

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

[C-6-1] يجب أن يؤدي SmsManager#sendTextMessage وSmsManager#sendMultipartTextMessage إلى إجراء مكالمات مقابلة إلى CarrierMessagingService لتوفير وظيفة المراسلة النصية. يجب أن يؤدي SmsManager#sendMultimediaMessage وSmsManager#downloadMultimediaMessage إلى إجراء مكالمات مماثلة إلى CarrierMessagingService لتوفير وظيفة رسائل الوسائط المتعددة.
[C-6-2] يجب أن يستخدم التطبيق المحدّد من خلال android.provider.Telephony.Sms#getDefaultSmsPackage واجهات برمجة التطبيقات SmsManager عند إرسال رسائل SMS وMMS واستلامها. يستوفي تنفيذ AOSP المرجعي في packages/apps/Messaging هذا الشرط.
[C-6-3] يجب أن يتيح التطبيق الذي يستجيب للرمز Intent#ACTION_DIAL إدخال رموز برنامج الاتصال العشوائية المنسَّقة على النحو *#*#CODE#*#*، وأن يؤدي إلى إطلاق TelephonyManager#ACTION_SECRET_CODE رسالة بث مطابقة.
[C-6-4] يجب أن يستخدم التطبيق الذي يستجيب لطلب Intent#ACTION_DIAL VoicemailContract.Voicemails#TRANSCRIPTION لعرض نص البريد الصوتي المرئي للمستخدمين إذا كان يتيح تحويل البريد الصوتي المرئي إلى نص.
[C-6-5] يجب عرض جميع SubscriptionInfo التي تتضمّن معرّفات UUID للمجموعة المكافئة كاشتراك واحد في جميع عناصر واجهة المستخدم الظاهرة للمستخدمين والتي تعرض معلومات شريحة SIM وتتيح التحكّم فيها. وتشمل الأمثلة على هذه الميزات واجهات الإعدادات التي تتطابق مع Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS أو EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS.
[C-6-6] يجب عدم عرض أو السماح بالتحكّم في أي SubscriptionInfo يتضمّن معرّف UUID للمجموعة غير فارغ وبتة انتهازية في أي عناصر مرئية للمستخدم تتيح ضبط إعدادات شريحة SIM أو التحكّم فيها.

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

[C-10-1] يجب الإفصاح عن علامة الميزة android.hardware.telephony.euicc.mep.

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

[C-SR-11] يُنصح بشدة بتضمين الميزة android.hardware.telephony.data.

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

[C-12-1] يجب أن يتيح الجهاز إجراء اتصالَين متزامنين على الأقل بشبكة بيانات الجوّال، مثل سياقات PDP واتصالات PDN واتصالات DN.

7.4.1.1. التوافق مع ميزة حظر الأرقام

في حال تضمين عمليات تنفيذ الأجهزة لميزة android.hardware.telephony.calling، يجب أن تستوفي ما يلي:

[C-1-1] يجب أن يتضمّن دعمًا لحظر الأرقام
[C-1-2] يجب تنفيذ BlockedNumberContract وواجهة برمجة التطبيقات المقابلة بالكامل على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK).
[C-1-3] يجب حظر جميع المكالمات والرسائل الواردة من رقم هاتف في BlockedNumberProvider بدون أي تفاعل مع التطبيقات. الاستثناء الوحيد هو عندما يتم رفع الحظر مؤقتًا كما هو موضح في مستندات حزمة SDK.
[C-1-4] يجب الكتابة إلى مقدّم سجلّ المكالمات على المنصة بشأن المكالمة المحظورة، ويجب فلترة المكالمات التي تتضمّن BLOCKED_TYPE من عرض سجلّ المكالمات التلقائي في تطبيق برنامج الاتصال المثبَّت مسبقًا.
[C-1-5] يجب عدم الكتابة إلى مزوّد خدمة الاتصال الهاتفي للحصول على رسالة محظورة.
[C-1-6] يجب تنفيذ واجهة مستخدم لإدارة الأرقام المحظورة، يتم فتحها باستخدام النية التي تعرضها الطريقة TelecomManager.createManageBlockedNumbersIntent().
[C-1-7] يجب ألا تسمح للمستخدمين الثانويين بعرض الأرقام المحظورة أو تعديلها على الجهاز، لأنّ نظام Android الأساسي يفترض أنّ المستخدم الأساسي لديه إمكانية التحكّم الكامل في خدمات الاتصال الهاتفي، وهي مثيل واحد على الجهاز. يجب إخفاء جميع عناصر واجهة المستخدم ذات الصلة بالحظر عن المستخدمين الثانويين، ويجب الالتزام بقائمة المستخدمين المحظورين.
يجب نقل الأرقام المحظورة إلى موفّر الخدمة عند تحديث الجهاز إلى الإصدار 7.0 من نظام التشغيل Android.
يجب توفير عنصر تحكّم للمستخدم لعرض المكالمات المحظورة في تطبيق الاتصال المثبَّت مسبقًا.

‫7.4.1.2. Telecom API

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

[7.4.1.2/C-0-1] يجب الإعلان عن علامة الميزة android.software.telecom.
‫[7.4.1.2/C-0-2] يجب تنفيذ إطار عمل الاتصالات.

إذا كان تقرير عمليات تنفيذ الأجهزة 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 على النحو التالي:
- Call Connection.onDisconnect() عند رصد ضغطة قصيرة على حدث رئيسي أثناء مكالمة جارية.
- يتم استدعاء Connection.onAnswer() عند رصد ضغطة قصيرة على حدث المفتاح أثناء مكالمة واردة.
- يتم استدعاء Connection.onReject() عند رصد ضغطة طويلة على حدث المفتاح أثناء مكالمة واردة.
- تبديل حالة كتم الصوت في CallAudioState

7.4.1.3. تخفيف حِمل رسالة التحقّق من الاتصال NAT-T على شبكة الجوّال

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

يجب أن تتضمّن إمكانية تخفيف الحِمل لرسالة تحقّق من الاتصال بالشبكة الخلوية.

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

‫[C-1-1] يجب أن تتوافق مع واجهة برمجة التطبيقات SocketKeepAlive.
‫[C-1-2] يجب أن يتيح الجهاز فتح خانة واحدة على الأقل لإبقاء الاتصال نشطًا بشكل متزامن عبر شبكة الجوّال.
[C-1-3] MUST support as many concurrent cellular keepalive slots as are supported by the Cellular Radio 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) في أي وقت أثناء التشغيل، بما في ذلك عندما تكون الشاشة غير نشطة، ما لم يكن قفل البث المتعدد غير مفعّل ويتم تصفية الحِزم بواسطة "تصفية حِزم التطبيقات" (APF). ولا يُشترط أن تستوفي الحِزم أي عمليات mDNS تطلبها التطبيقات حاليًا من خلال واجهات برمجة التطبيقات NsdManager. ومع ذلك، يجوز للجهاز فلترة حِزم mDNS إذا كان ذلك ضروريًا للبقاء ضمن نطاقات استهلاك الطاقة التي تتطلّبها المتطلبات التنظيمية السارية في السوق المستهدَف.
[C-1-5] يجب عدم اعتبار طلب إجراء WifiManager.enableNetwork() في واجهة برمجة التطبيقات مؤشرًا كافيًا لتبديل Network النشط حاليًا والذي يتم استخدامه تلقائيًا في عدد الزيارات إلى التطبيق ويتم عرضه من خلال طرق واجهة برمجة التطبيقات ConnectivityManager، مثل getActiveNetwork وregisterDefaultNetworkCallback. بعبارة أخرى، يجوز لهم إيقاف إمكانية الوصول إلى الإنترنت التي يوفّرها أي مزوّد شبكة آخر (مثل بيانات الجوّال) فقط إذا تمكّنوا من إثبات أنّ شبكة Wi-Fi توفّر إمكانية الوصول إلى الإنترنت.
[C-1-6] يُنصح بشدة بأن يتم، عند استدعاء طريقة ConnectivityManager.reportNetworkConnectivity() في واجهة برمجة التطبيقات، إعادة تقييم إمكانية الوصول إلى الإنترنت على Network، وعندما يتبين من التقييم أنّ Network الحالي لم يعُد يتيح الوصول إلى الإنترنت، يتم التبديل إلى أي شبكة أخرى متاحة (مثل بيانات الجوّال) تتيح الوصول إلى الإنترنت.
‫[C-1-7] يجب إنشاء أرقام عشوائية لعنوان MAC المصدر ورقم التسلسل الخاصين بإطارات طلبات البحث، وذلك مرة واحدة في بداية كل عملية فحص، عندما يكون الجهاز غير متصل.
[C-1-8] يجب استخدام عنوان MAC واحد متسق (يجب عدم تغيير عنوان MAC بشكل عشوائي في منتصف عملية البحث).
‫[C-1-9] يجب تكرار رقم تسلسل طلب الفحص كالمعتاد (بالترتيب) بين طلبات الفحص في عملية البحث.
[C-1-10] يجب أن يتم اختيار رقم تسلسل طلب الفحص عشوائيًا بين آخر طلب فحص لعملية مسح وأول طلب فحص لعملية المسح التالية.
[C-SR-1] يُنصح بشدة بتوزيع عنوان MAC المصدر المستخدَم بشكل عشوائي في جميع عمليات التواصل بين محطة (STA) ونقطة وصول (AP) أثناء الربط وبعد الربط.
- يجب أن يستخدم الجهاز عنوان MAC عشوائيًا مختلفًا لكل SSID (FQDN لـ Passpoint) يتواصل معه.
- يجب أن يوفّر الجهاز للمستخدم خيارًا للتحكّم في العشوائية لكل معرّف SSID (اسم المجال المؤهّل بالكامل لشبكة 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 Low Latency Lock (WIFI_MODE_FULL_LOW_LATENCY) أقل من وقت الاستجابة أثناء وضع قفل Wi-Fi High Perf Lock (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 مباشر (Wi-Fi من جهاز إلى جهاز).

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

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

‫7.4.2.2. إعداد رابط مباشر عبر شبكة Wi-Fi

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

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

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

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

‫7.4.2.3. Wi-Fi Aware

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

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

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

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

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

[C-2-1] يجب تنفيذ واجهات برمجة التطبيقات التي تتيح الاستكشاف المستند إلى الموقع الجغرافي: setRangingEnabled وsetMinDistanceMm وsetMaxDistanceMm وonServiceDiscoveredWithinRange.

‫7.4.2.4. Wi-Fi Passpoint

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

يجب أن تتضمّن إمكانية استخدام Wi-Fi Passpoint.

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

[C-1-2] يجب تنفيذ واجهات برمجة التطبيقات ذات الصلة بمعيار Passpoint WifiManager كما هو موضح في مستندات حزمة تطوير البرامج (SDK).
[C-1-3] يجب أن يتوافق مع معيار IEEE 802.11u، وتحديدًا ما يتعلق باكتشاف الشبكة واختيارها، مثل خدمة الإعلانات الشاملة (GAS) وبروتوكول طلب شبكة الوصول (ANQP).
[C-1-4] يجب الإفصاح عن علامة الميزة android.hardware.wifi.passpoint.
[C-1-5] يجب اتّباع عملية التنفيذ في AOSP لاكتشاف شبكات Passpoint ومطابقتها وربطها.
[C-1-6] يجب أن تتوافق مع المجموعة الفرعية التالية على الأقل من بروتوكولات توفير الأجهزة كما هو محدّد في الإصدار 2 من معيار Passpoint الصادر عن تحالف Wi-Fi: مصادقة EAP-TTLS وSOAP-XML.
‫[C-1-7] يجب معالجة شهادة خادم AAA كما هو موضح في مواصفات Hotspot 2.0 الإصدار 3.
‫[C-1-8] يجب أن يتيح للمستخدم التحكّم في عملية التوفير من خلال أداة اختيار شبكة Wi-Fi.
[C-1-9] يجب الحفاظ على إعدادات Passpoint ثابتة عند إعادة التشغيل.
[C-SR-1] يُنصح بشدة بتوفير ميزة قبول الأحكام والشروط.
[C-SR-2] يُنصح بشدة بتوفير ميزة معلومات المكان.

في حال توفُّر مفتاح تحكّم عالمي لإيقاف Passpoint، يجب أن تتضمّن عمليات التنفيذ ما يلي:

‫[C-3-1] يجب تفعيل Passpoint تلقائيًا.

7.4.2.5. الموقع الجغرافي عبر شبكة Wi-Fi (المدة بين نقطتَي البداية والنهاية لشبكة Wi-Fi)

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

يجب أن تتضمّن إمكانية استخدام الموقع الجغرافي عبر شبكة Wi-Fi.

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

[C-1-1] يجب تنفيذ واجهات برمجة التطبيقات WifiRttManager على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK).
[C-1-2] يجب الإفصاح عن علامة الميزة android.hardware.wifi.rtt.
[C-1-3] يجب أن يتم اختيار عنوان MAC المصدر بشكل عشوائي لكل سلسلة RTT يتم تنفيذها عندما لا تكون واجهة Wi-Fi التي يتم تنفيذ RTT عليها مرتبطة بنقطة وصول.
[C-1-4] يجب أن تكون دقيقة في حدود مترَين عند نطاق ترددي يبلغ 80 ميجاهرتز عند الشريحة المئوية رقم 68 (كما هو محسوب باستخدام دالة التوزيع التراكمي).
[C-SR-1] يُنصح بشدة بالإبلاغ عن الموقع الجغرافي بدقة تصل إلى 1.5 متر عند نطاق ترددي يبلغ 80 ميغاهرتز عند النسبة المئوية الـ 68 (كما هو محسوب باستخدام دالة التوزيع التراكمي).

‫7.4.2.6. تخفيف حِمل رسالة تحقّق من الاتصال لشبكة Wi-Fi

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

يجب أن تتضمّن إمكانية إيقاف تحميل Wi-Fi keepalive.

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

[C-1-1] يجب أن تتوافق مع واجهة برمجة التطبيقات SocketKeepAlive.
[C-1-2] يجب أن يتيح الجهاز ثلاث فترات متزامنة على الأقل لإبقاء الاتصال نشطًا عبر شبكة Wi-Fi

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

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

‫7.4.2.7. Wi-Fi Easy Connect (بروتوكول توفير المتطلبات اللازمة للأجهزة)

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

يجب أن تتضمّن دعمًا لميزة Wi-Fi Easy Connect (بروتوكول DPP).

[C-1-1] يجب أن تعرض الدالة WifiManager#isEasyConnectSupported()‎ القيمة true.

‫7.4.2.8. التحقّق من صحة شهادة خادم Wi-Fi في المؤسسة

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

[C-SR-1] يُنصح بشدة بعدم توفير خيار للمستخدم لإضافة شبكة Wi-Fi خاصة بالمؤسسة يدويًا في تطبيق "الإعدادات".

‫7.4.2.9. الثقة في أول استخدام (TOFU)

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع ميزة "الوثوق عند الاستخدام لأول مرة" (TOFU) وتسمح للمستخدم بتحديد إعدادات WPA/WPA2/WPA3-Enterprise، يجب أن تستوفي الشروط التالية:

[C-4-1] يجب أن يوفّر للمستخدم خيارًا لتحديد استخدام TOFU.

‫7.4.2.10. رصد الأجهزة القريبة عبر شبكة Wi-Fi

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

[C-1-1] يجب أن تتضمّن دعم رصد الأجهزة القريبة.
[C-1-2] يجب الإفصاح عن علامة الميزة android.hardware.wifi.rtt.
[C-1-3] يجب أن تعرض الطريقة WifiRttManager#getProximityDetectionCharacteristics() قيمة غير فارغة.
[C-1-4] يجب تنفيذ واجهات برمجة التطبيقات WifiRttManager الخاصة بتحديد المدى بشكل مستمر.
‫[C-1-5] يجب أن تتوافق مع عمليات Wi-Fi وعمليات رصد التقارب عبر Wi-Fi في الوقت نفسه.
‫[C-1-6] يجب أن تكون الدقة في حدود مترَين عند نطاق ترددي يبلغ 80 ميغاهرتز عند الشريحة المئوية رقم 68 (كما يتم احتسابها باستخدام دالة التوزيع التراكمي).
[C-1-7] يجب إجراء تحديد المدى باستخدام ميزة "الرصد القريب" (PD) في أعلى نطاق تردد متاح (6 غيغاهرتز أو 5 غيغاهرتز أو 2.4 غيغاهرتز) باستخدام الحد الأقصى لعرض النطاق الترددي المتاح بالترتيب التالي حسب الأولوية: 160 ميغاهرتز و80 ميغاهرتز و40 ميغاهرتز و20 ميغاهرتز.
[C-SR-1] يُنصح بشدة بالإبلاغ عن الموقع الجغرافي بدقة ضمن نطاق 1.5 متر عند نطاق ترددي يبلغ 80 ميجاهرتز عند النسبة المئوية الـ 68 (كما هو محسوب باستخدام دالة التوزيع التراكمي).
‫[C-SR-2] يُنصح بشدة بتوفير نطاق 802.11az NTB.

‫7.4.3. بلوتوث

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

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

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

يجب أن يتيح ربط 5 أجهزة متصلة على الأقل.

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

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

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

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

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

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

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

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

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

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

[C-5-1] يجب عرض true لـ BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).

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

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

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

[C-6-2] يجب حصر إذن الوصول إلى البلوتوث من خلال android.permission.ACCESS_FINE_LOCATION.

إذا كانت عمليات تنفيذ الأجهزة تعرض true لواجهة برمجة التطبيقات BluetoothAdapter.isLeAudioSupported()، فإنّها:

[C-7-1] يجب أن يتيح استخدام عميل البث الأحادي.
‫[C-7-2] يجب أن تتوافق مع الطبقة الفيزيائية 2M.
‫[C-7-3] يجب أن يتيح الجهاز استخدام الإعلانات الموسّعة بتقنية Bluetooth منخفضة الطاقة.
‫[C-7-4] يجب أن يتيح الجهاز ربط جهازي CIS على الأقل في مجموعة CIG.
[C-7-5] يجب تفعيل عميل البث الأحادي BAP ومنسّق مجموعة CSIP وخادم MCP ووحدة التحكّم VCP وخادم CCP في الوقت نفسه.
[C-SR-1] يُنصح بشدة بتفعيل عميل البث الأحادي HAP.

إذا كانت عمليات تنفيذ الأجهزة تعرض true لواجهة برمجة التطبيقات BluetoothAdapter.isLeAudioBroadcastSourceSupported()، فإنّها:

[C-8-1] يجب أن تتوافق مع رابطَي BIS على الأقل في BIG.
‫[C-8-2] يجب تفعيل مصدر بث BAP ومساعد بث BAP في الوقت نفسه.
[C-8-3] يجب أن تتوافق مع الإعلانات الدورية منخفضة الطاقة (LE).

إذا كانت عمليات تنفيذ الأجهزة تعرض true لواجهة برمجة التطبيقات BluetoothAdapter.isLeAudioBroadcastAssistantSupported()، فإنّها:

‫[C-9-1] يجب أن تتوافق مع PAST (نقل البيانات المتزامن للإعلانات الدورية).
[C-9-2] يجب أن تتوافق مع ميزة "الإعلانات الدورية" في وضع الطاقة المنخفضة (LE).

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

[C-10-1] يجب أن تكون قياسات قوة الإشارة المستلَمة (RSSI) ضِمن نطاق ‎+/-9 ديسيبل بالنسبة إلى% 95 من القياسات على مسافة متر واحد من جهاز مرجعي يرسل الإشارة عند ADVERTISE_TX_POWER_HIGH في بيئة خط البصر.
[C-10-2] يجب تضمين تصحيحات Rx/Tx لتقليل الانحرافات لكل قناة بحيث تكون القياسات على كل قناة من القنوات الثلاث، وعلى كل هوائي (في حال استخدام هوائيات متعددة)، في نطاق +/-3 ديسيبل من بعضها البعض بنسبة% 95 من القياسات.

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

[C-11-1] يجب الإبلاغ عن علامة ميزة الجهاز android.hardware.bluetooth_le.channel_sounding.
[C-11-2] يجب أن يتم عرض النطاق بدقة في حدود ‎+/- 0.5 متر عند المعدّل المئوي التسعين، وذلك حسب ما يتم حسابه باستخدام دالة التوزيع التراكمي، عند مسافة متر واحد.

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

[C-SR-2] يُنصح بشدة بقياس قيمة الإزاحة في الإشارة المستلَمة وتعويضها لضمان أن يكون متوسط قوة الإشارة المستلَمة (RSSI) عبر البلوتوث المنخفض الطاقة (BLE) هو ‎-60 ديسيبل (dBm) ±10 ديسيبل على مسافة متر واحد من جهاز مرجعي يرسل الإشارة عند ADVERTISE_TX_POWER_HIGH، مع توجيه الأجهزة بحيث تكون على "مستويات متوازية" وتكون الشاشات متجهة إلى الاتجاه نفسه.
[C-SR-3] يُنصح بشدة بقياس قيمة الإزاحة في الإرسال والتعويض عنها لضمان أن يكون متوسط قوة الإشارة المستلَمة (RSSI) عبر البلوتوث منخفض الطاقة (BLE) هو ‎-60 ديسيبل (dBm) +/-10 ديسيبل عند إجراء عملية البحث من جهاز مرجعي موضوع على مسافة متر واحد ويبث عند ADVERTISE_TX_POWER_HIGH، مع توجيه الأجهزة بحيث تكون على "مستويات متوازية" وتكون الشاشات متجهة إلى الاتجاه نفسه.

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

‫7.4.4. اتصالات المجال القريب

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

يجب أن يتضمّن جهاز إرسال واستقبال وأجهزة ذات صلة بتقنية الاتصال القريب المدى (NFC).
[C-0-1] يجب تنفيذ واجهات برمجة التطبيقات android.nfc.NdefMessage وandroid.nfc.NdefRecord حتى إذا لم تتضمّن دعمًا لاتصال المجال القريب (NFC) أو الإعلان عن ميزة android.hardware.nfc، لأنّ الفئات تمثّل تنسيقًا لعرض البيانات مستقل عن البروتوكول.

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

[C-1-1] يجب الإبلاغ عن ميزة android.hardware.nfc من خلال الطريقة android.content.pm.PackageManager.hasSystemFeature().
يجب أن يكون الجهاز قادرًا على قراءة رسائل NDEF وكتابتها من خلال معايير NFC التالية كما هو موضّح أدناه:
[C-1-2] يجب أن يكون الجهاز قادرًا على العمل كقارئ/كاتب NFC Forum (على النحو المحدّد في المواصفات الفنية لمنتدى NFC NFCForum-TS-DigitalProtocol-1.0) من خلال معايير NFC التالية:
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NfcF (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- أنواع علامات NFC Forum‏ 2 و3 و4 و5 (المحدّدة من قِبل NFC Forum)
[C-SR-1] يُنصح بشدة أن يكون الجهاز قادرًا على قراءة رسائل NDEF وكتابتها، بالإضافة إلى البيانات الأولية، وذلك باستخدام معايير NFC التالية. يُرجى العِلم أنّه على الرغم من أنّ معايير NFC مُحدّدة على أنّها يُنصَح بها بشدة، من المخطّط أن يتم تغييرها إلى معايير إلزامية في تعريف التوافق لإصدار مستقبلي. هذه المعايير اختيارية في هذا الإصدار، ولكن سيتم فرضها في الإصدارات المستقبلية. ننصح بشدة بأن تستوفي الأجهزة الحالية والجديدة التي تعمل بهذا الإصدار من Android هذه المتطلبات الآن حتى تتمكّن من الترقية إلى إصدارات المنصة المستقبلية.
[C-1-13] يجب إجراء عملية بحث عن جميع التقنيات المتوافقة أثناء تفعيل وضع البحث عن أجهزة NFC.
يجب أن يكون الجهاز في وضع اكتشاف NFC أثناء تنشيطه مع تفعيل الشاشة وفتح قفل شاشة القفل.
يجب أن يكون الجهاز قادرًا على قراءة الرمز الشريطي وعنوان URL (في حال ترميزه) الخاصين بمنتجات Thinfilm NFC Barcode.

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

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

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

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

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

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

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

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

‫7.4.5. بروتوكولات الشبكة وواجهات برمجة التطبيقات

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

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

[C-0-1] يجب أن يتضمّن دعمًا لشكل واحد أو أكثر من أشكال ربط البيانات بالشبكة. على وجه التحديد، يجب أن تتضمّن عمليات تنفيذ الأجهزة إمكانية استخدام معيار واحد على الأقل للبيانات قادر على نقل 200 كيلوبت في الثانية أو أكثر. وتشمل الأمثلة على التقنيات التي تستوفي هذا الشرط كلاً من EDGE وHSPA وEV-DO و802.11g وEthernet وBluetooth PAN.
يجب أن يتضمّن الجهاز أيضًا إمكانية استخدام معيار واحد على الأقل من معايير البيانات اللاسلكية الشائعة، مثل 802.11 (Wi-Fi)، عندما يكون معيار الشبكات المادية (مثل Ethernet) هو اتصال البيانات الأساسي.
يمكن أن تنفّذ أكثر من شكل واحد من أشكال ربط البيانات.

‫7.4.5.2. ‫IPv6

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

[C-0-2] يجب أن يتضمّن حزمة شبكات IPv6 وأن يتيح الاتصال عبر IPv6 باستخدام واجهات برمجة التطبيقات المُدارة، مثل java.net.Socket وjava.net.URLConnection، بالإضافة إلى واجهات برمجة التطبيقات الأصلية، مثل مقابس AF_INET6.
[C-0-3] يجب تفعيل بروتوكول IPv6 تلقائيًا.
يجب التأكّد من أنّ الاتصال عبر IPv6 موثوق به مثل IPv4، على سبيل المثال:
[C-0-4] يجب الحفاظ على إمكانية الاتصال ببروتوكول IPv6 في وضع "السكون".
[C-0-5] يجب ألا يؤدي الحدّ من المعدّل إلى فقدان الجهاز إمكانية الاتصال عبر الإصدار السادس من بروتوكول الإنترنت (IPv6) على أي شبكة متوافقة مع IPv6 تستخدم مدة صلاحية إعلانات الموجه (RA) لا تقل عن 180 ثانية.
[C-0-6] يجب أن توفّر التطبيقات التابعة لجهات خارجية إمكانية الاتصال المباشر بشبكة الإصدار السادس من بروتوكول الإنترنت (IPv6) عند الاتصال بشبكة الإصدار السادس من بروتوكول الإنترنت (IPv6)، بدون أي شكل من أشكال ترجمة العناوين أو المنافذ على الجهاز. يجب أن تعرض كل من واجهات برمجة التطبيقات المُدارة، مثل Socket#getLocalAddress أو Socket#getLocalPort، وواجهات برمجة التطبيقات الخاصة بحزمة تطوير البرامج الأصلية (NDK)، مثل getsockname() أو IPV6_PKTINFO، عنوان IP والمنفذ المستخدَمين فعليًا لإرسال الحِزم واستلامها على الشبكة، واللذين يظهران كعنوان IP ومنفذ المصدر لخوادم الإنترنت (الويب).

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

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

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

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

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

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

[C-3-1] يجب أن يتيح الجهاز تشغيل IPv6 (IPv6 فقط وربما ثنائي الحزمة) على شبكة الجوّال.

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

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

7.4.5.3. المداخل المشروط الوصول إليها

يشير المدخل المشروط الوصول إليه إلى شبكة تتطلّب تسجيل الدخول من أجل الوصول إلى الإنترنت.

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

[C-1-1] يجب توفير تطبيق بوابة أسيرة للتعامل مع الغرض ACTION_CAPTIVE_PORTAL_SIGN_IN وعرض صفحة تسجيل الدخول إلى البوابة الأسيرة، وذلك عن طريق إرسال هذا الغرض، عند استدعاء System API ConnectivityManager#startCaptivePortalApp(Network, Bundle).
[C-1-2] يجب أن يتم رصد المدخل المشروط الوصول إليه وإتاحة تسجيل الدخول من خلال تطبيق المدخل المشروط الوصول إليه عندما يكون الجهاز متصلاً بأي نوع من الشبكات، بما في ذلك شبكة الجوّال أو شبكة Wi-Fi أو شبكة إيثرنت أو البلوتوث.
[C-1-3] يجب أن يتيح تسجيل الدخول إلى مداخل مشروطة الوصول إليها باستخدام نظام أسماء النطاقات بنص غير مرمّز عندما يكون الجهاز مضبوطًا على استخدام وضع التدقيق الصارم لنظام أسماء النطاقات الخاص.
[C-1-4] يجب استخدام نظام أسماء نطاقات مشفّر وفقًا لمستندات حزمة تطوير البرامج (SDK) الخاصة بـ android.net.LinkProperties.getPrivateDnsServerName وandroid.net.LinkProperties.isPrivateDnsActive لجميع حركة بيانات الشبكة التي لا تتواصل بشكل صريح مع بوابة الأسير.
[C-1-5] يجب التأكّد من أنّه أثناء تسجيل دخول المستخدم إلى بوابة أسيرة، تكون الشبكة التلقائية التي تستخدمها التطبيقات (كما يتم عرضها من خلال ConnectivityManager.getActiveNetwork وConnectivityManager.registerDefaultNetworkCallback والتي تستخدمها تلقائيًا واجهات برمجة تطبيقات Java للشبكات، مثل java.net.Socket، وواجهات برمجة التطبيقات الأصلية، مثل connect()) هي أي شبكة أخرى متاحة توفّر إمكانية الوصول إلى الإنترنت، إذا كانت متاحة.

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

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

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

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

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

[C-SR-1] يُنصح بشدة بتوفير وضع توفير البيانات.

إذا كانت عمليات تنفيذ الأجهزة توفّر وضع "توفير البيانات"، فإنّها:

[C-1-1] يجب أن تتوافق مع جميع واجهات برمجة التطبيقات في فئة ConnectivityManager على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK)

إذا لم توفّر عمليات تنفيذ الأجهزة وضع "توفير البيانات"، عليها استيفاء الشروط التالية:

[C-2-1] يجب أن تعرض القيمة RESTRICT_BACKGROUND_STATUS_DISABLED عند ConnectivityManager.getRestrictBackgroundStatus()
‫[C-2-2] يجب عدم بث ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

‫7.4.8. العناصر الآمنة

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع عناصر آمنة متوافقة مع Open Mobile API وتتيحها للتطبيقات التابعة لجهات خارجية، يجب أن تستوفي ما يلي:

‫[C-1-1] يجب إدراج جميع قارئات العناصر الآمنة المتاحة من خلال واجهة برمجة التطبيقات android.se.omapi.SEService.getReaders().
[C-1-2] يجب الإفصاح عن علامات الميزات الصحيحة من خلال android.hardware.se.omapi.uicc للجهاز الذي يتضمّن عناصر آمنة مستندة إلى UICC، android.hardware.se.omapi.ese للجهاز الذي يتضمّن عناصر آمنة مستندة إلى eSE، android.hardware.se.omapi.sd للجهاز الذي يتضمّن عناصر آمنة مستندة إلى بطاقة SD.

‫7.4.9. النطاق الفائق العرض (UWB)

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة معيار 802.1.15.4 وتوفير الوظيفة لتطبيق تابع لجهة خارجية، يجب أن تستوفي ما يلي:

[C-1-1] يجب تنفيذ واجهة برمجة تطبيقات Android المقابلة في android.uwb.
[C-1-2] يجب الإبلاغ عن علامة ميزة الأجهزة android.hardware.uwb.
‫[C-1-3] يجب أن تتوافق مع جميع ملفات تعريف النطاق الفائق العرض (UWB) ذات الصلة المحدّدة في تنفيذ Android.
[C-1-4] يجب توفير وسيلة تتيح للمستخدم التبديل بين حالتي تشغيل/إيقاف راديو UWB.
[C-1-5] يجب فرض حصول التطبيقات التي تستخدم موجات الراديو الفائقة العرض على إذن UWB_RANGING (ضمن مجموعة أذونات NEARBY_DEVICES).
[C-SR-1] يُنصح بشدة باجتياز اختبارات التوافق والشهادات ذات الصلة التي تحدّدها المؤسسات المعيارية، بما في ذلك FIRA وCCC وCSA.
[C-1-6] يجب التأكّد من أنّ قياسات المسافة تقع ضمن نطاق ‎+/-15 سم بنسبة% 95 من القياسات في بيئة خط البصر على مسافة متر واحد في غرفة غير عاكسة.
[C-1-7] يجب التأكّد من أنّ متوسط قياسات المسافة على بُعد متر واحد من الجهاز المرجعي يقع ضمن النطاق [0.75 متر، 1.25 متر]، حيث يتم قياس المسافة الحقيقية من الحافة العلوية للجهاز الخاضع للاختبار.
[C-SR-2] يُنصح بشدة باتّباع خطوات إعداد القياس الموضّحة في متطلبات معايرة الحضور.

‫7.5 كاميرات

إذا كانت عمليات تنفيذ الأجهزة تتضمّن كاميرا واحدة على الأقل، يجب أن تستوفي ما يلي:

[C-1-1] يجب الإفصاح عن علامة الميزة android.hardware.camera.any.
[C-1-2] يجب أن يتمكّن التطبيق من تخصيص 3 RGBA_8888 صور نقطية في الوقت نفسه بحجم الصور التي تنتجها أداة استشعار الكاميرا ذات أعلى دقة على الجهاز، وذلك أثناء فتح الكاميرا لغرض المعاينة الأساسية والتقاط الصور الثابتة.
[C-1-3] يجب التأكّد من أنّ تطبيق الكاميرا التلقائي المثبَّت مسبقًا الذي يعالج الأهداف MediaStore.ACTION_IMAGE_CAPTURE أو MediaStore.ACTION_IMAGE_CAPTURE_SECURE أو MediaStore.ACTION_VIDEO_CAPTURE هو المسؤول عن إزالة الموقع الجغرافي للمستخدم من البيانات الوصفية للصورة قبل إرسالها إلى التطبيق المستلِم عندما لا يتضمّن التطبيق المستلِم ACCESS_FINE_LOCATION.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن كاميرا واحدة على الأقل، وكان تطبيق الكاميرا المثبَّت مسبقًا يعالج الأهداف MediaStore.ACTION_MOTION_PHOTO_CAPTURE أو MediaStore.ACTION_MOTION_PHOTO_CAPTURE_SECURE، يجب أن تستوفي ما يلي:

[C-1-4] يجب التأكّد من أنّه عند التعامل مع هذه الأهداف، يزيل تطبيق الكاميرا المثبَّت مسبقًا الموقع الجغرافي للمستخدم من البيانات الوصفية للصورة قبل إرسالها إلى التطبيقات المستلِمة التي لا يتوفّر لها الإذن ACCESS_FINE_LOCATION.
[C-1-5] يجب التأكّد من أنّ الصورة المتحركة التي تم إرجاعها تستخدم مواصفات تنسيق الصورة المتحركة 1.0.

[C-1-6] يجب تصنيف كل نوع من أنواع أجهزة الكاميرا باستخدام الحقل CameraCharacteristics.INFO_DEVICE_TYPE على أنّه BUILT_IN أو EXTERNAL أو VIRTUAL. يجب أيضًا تصنيف كل لقطة من مخرجات الكاميرا باستخدام الحقل CaptureResult.INFO_DEVICE_TYPE.
من المهم بشكل خاص التأكّد من تصنيف CaptureResult.INFO_DEVICE_TYPE بشكل صحيح في الحالات التي تتم فيها إعادة ربط معرّف الكاميرا بشكل ديناميكي بمصدر كاميرا مختلف.

في حال توفّر إمكانية إخراج فيديو 10 بت بنطاق عالي الديناميكية في عمليات تنفيذ الأجهزة، يجب أن تتوفّر الشروط التالية:

[C-2-1] يجب أن تتوافق جميع أجهزة الكاميرا التي تتيح إخراج بيانات 10 بت مع ملف تعريف HLG HDR على الأقل.
[C-2-2] يجب أن يتيح الجهاز إخراج بيانات بعمق 10 بت لكل من الكاميرا الخلفية الأساسية أو الكاميرا الأمامية الأساسية.
[C-SR-1] يُنصح بشدة بتوفير إخراج بيانات بمعدل 10 بت لكلتا الكاميرتين الأساسيتين.
[C-2-3] يجب أن تتوافق جميع الكاميرات الفرعية المادية التي يمكنها استخدام BACKWARD_COMPATIBLE مع ملفات تعريف HDR نفسها الخاصة بالكاميرا المجمّعة.

بالنسبة إلى أجهزة الكاميرا المنطقية التي تتوافق مع تقنية HDR بمعدل 10 بت وتنفّذ واجهة برمجة التطبيقات android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO، يجب أن تستوفي ما يلي:

[C-3-1] يجب أن يتيح التبديل بين جميع الكاميرات المادية المتوافقة مع الإصدارات القديمة من خلال عنصر التحكّم CONTROL_ZOOM_RATIO في الكاميرا المنطقية.

‫7.5.1. الكاميرا الخلفية

الكاميرا الخلفية هي كاميرا تواجه العالم وتصوّر المشاهد على الجانب البعيد من الجهاز، مثل الكاميرا التقليدية. وفي الأجهزة المحمولة، تكون الكاميرا الخلفية على الجانب المقابل للشاشة.

عمليات تنفيذ الجهاز:

يجب أن يتضمّن كاميرا خلفية.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن كاميرا واحدة على الأقل مواجهة للخلف، يجب أن:

[C-1-1] يجب الإبلاغ عن علامة الميزة android.hardware.camera وandroid.hardware.camera.any.

~~[C-1-2] يجب أن تبلغ درجة الدقة 2 ميغابكسل على الأقل.~~

يجب أن تتضمّن الكاميرا ميزة التركيز التلقائي للأجهزة أو البرامج في برنامج تشغيل الكاميرا (بشكل غير مرئي لبرامج التطبيقات).
قد تحتوي على أجهزة تركيز ثابت أو EDOF (عُمق مجال موسّع).
قد تتضمّن فلاشًا.

إذا كانت الكاميرا تتضمّن فلاشًا:

[C-2-1] يجب ألا يضيء مصباح الفلاش أثناء تسجيل مثيل على مساحة معاينة الكاميرا، ما لم يفعّل التطبيق الفلاش صراحةً من خلال تفعيل السمتَين FLASH_MODE_AUTO أو FLASH_MODE_ON لكائن Camera.Parameters.android.hardware.Camera.PreviewCallback يُرجى العِلم أنّ هذا القيد لا ينطبق على تطبيق الكاميرا المضمّن في الجهاز، بل ينطبق فقط على التطبيقات التابعة لجهات خارجية التي تستخدم Camera.PreviewCallback.

‫7.5.2. الكاميرا الأمامية

الكاميرا الأمامية هي كاميرا موجّهة نحو المستخدم تُستخدَم عادةً لتصويره، مثلاً في مؤتمرات الفيديو والتطبيقات المشابهة. وفي الأجهزة المحمولة، تكون الكاميرا الأمامية على الجانب نفسه من الجهاز الذي تظهر عليه الشاشة.

عمليات تنفيذ الجهاز:

قد تتضمّن كاميرا أمامية.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن كاميرا واحدة على الأقل مواجهة للشاشة، يجب أن تستوفي ما يلي:

[C-1-1] يجب الإبلاغ عن علامة الميزة android.hardware.camera.any وandroid.hardware.camera.front.
[C-1-2] يجب أن تكون درجة الدقة VGA (640x480 بكسل) على الأقل.
[C-1-3] يجب عدم استخدام الكاميرا الأمامية كإعداد تلقائي لواجهة برمجة التطبيقات الخاصة بالكاميرا، ويجب عدم ضبط واجهة برمجة التطبيقات على اعتبار الكاميرا الأمامية هي الكاميرا الخلفية التلقائية، حتى إذا كانت الكاميرا الوحيدة على الجهاز.
[C-1-4] يجب أن تكون معاينة الكاميرا معكوسة أفقيًا بالنسبة إلى الاتجاه الذي يحدّده التطبيق عندما يطلب التطبيق الحالي بشكل صريح تدوير شاشة الكاميرا من خلال استدعاء الطريقة android.hardware.Camera.setDisplayOrientation(). في المقابل، يجب أن تكون المعاينة معكوسة على طول المحور الأفقي التلقائي للجهاز عندما لا يطلب التطبيق الحالي بشكل صريح تدوير شاشة الكاميرا من خلال استدعاء الطريقة android.hardware.Camera.setDisplayOrientation().
[C-1-5] يجب ألا يتم عرض صورة ثابتة أو بث فيديو نهائيين تم التقاطهما في عمليات معاودة الاتصال التي يتم إرجاعها إلى التطبيق أو في عمليات الحفظ في مساحة تخزين الوسائط.
[C-1-6] يجب أن تعكس الصورة المعروضة في العرض بعد الالتقاط بالطريقة نفسها التي تعكس بها دفق صورة معاينة الكاميرا.
قد تتضمّن ميزات (مثل التركيز التلقائي والفلاش وما إلى ذلك) متاحة للكاميرات الخلفية كما هو موضّح في الفقرة 7.5.1.

إذا كانت عمليات تنفيذ الجهاز قابلة للتدوير من قِبل المستخدم (مثل التدوير تلقائيًا باستخدام مقياس تسارع أو يدويًا من خلال بيانات أدخلها المستخدم):

[C-2-1] يجب أن يتم عكس معاينة الكاميرا أفقيًا بالنسبة إلى اتجاه الجهاز الحالي.

‫7.5.3. الكاميرا الخارجية

الكاميرا الخارجية هي كاميرا يمكن توصيلها أو فصلها فعليًا عن الجهاز في أي وقت، ويمكن توجيهها في أي اتجاه، مثل كاميرات USB.

عمليات تنفيذ الجهاز:

قد يشمل ذلك إمكانية استخدام كاميرا خارجية غير متصلة دائمًا.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية استخدام كاميرا خارجية، يجب أن تتضمّن ما يلي:

[C-1-1] يجب الإعلان عن علامة ميزة النظام الأساسي android.hardware.camera.external وandroid.hardware camera.any.
[C-1-2] يجب أن يتوافق الجهاز مع فئة فيديو USB (الإصدار 1.0 أو إصدار أحدث) إذا كانت الكاميرا الخارجية متصلة بمنفذ مضيف USB.
[C-1-3] يجب اجتياز اختبارات CTS للكاميرا باستخدام جهاز كاميرا خارجية فعلية متصلة. تتوفّر تفاصيل اختبار مجموعة أدوات اختبار التوافق (CTS) للكاميرا على source.android.com.
يجب أن تتوافق مع عمليات ضغط الفيديو، مثل MJPEG، لتتيح نقل تدفقات غير مشفّرة عالية الجودة (أي تدفقات الصور الأولية أو المضغوطة بشكل مستقل).
قد تتيح استخدام كاميرات متعددة.
قد يتيح MAY ترميز الفيديو المستند إلى الكاميرا.

في حال توفّر ترميز الفيديو المستند إلى الكاميرا:

[C-2-1] يجب أن يكون الجهاز قادراً على الوصول إلى بث متزامن غير مشفّر / MJPEG (بدقة QVGA أو أعلى).

7.5.4. سلوك Camera API

يتضمّن Android حزمتَي واجهات برمجة تطبيقات للوصول إلى الكاميرا، وهما واجهة برمجة التطبيقات الأحدث android.hardware.camera2 التي تتيح للتطبيق التحكّم في الكاميرا على مستوى أدنى، بما في ذلك عمليات نقل البيانات الفعّالة بدون نسخ، وعمليات البث المتسلسل أو المتتابع، وعناصر التحكّم في كل إطار من حيث التعريض والزيادة ومكاسب توازن اللون الأبيض وتحويل الألوان وإزالة التشويش والحدة وغير ذلك.

تم وضع علامة "متوقّف نهائيًا" على حزمة واجهة برمجة التطبيقات القديمة، android.hardware.Camera، في Android 5.0، ولكن من المفترض أن تظل متاحة للتطبيقات. يجب أن تضمن عمليات تنفيذ أجهزة Android استمرار توفّر واجهة برمجة التطبيقات كما هو موضّح في هذا القسم وفي حزمة تطوير البرامج (SDK) لنظام Android.

يجب أن تتوفّر في كلتا واجهتَي برمجة التطبيقات جميع الميزات المشتركة بين الفئة android.hardware.Camera التي تم إيقافها نهائيًا والحزمة android.hardware.camera2 الأحدث، مع توفير أداء وجودة مماثلَين. على سبيل المثال، مع الإعدادات المكافئة، يجب أن تكون سرعة التركيز التلقائي ودقته متطابقتَين، ويجب أن تكون جودة الصور الملتقطة هي نفسها. لا يُشترط أن تتطابق السرعة أو الجودة في الميزات التي تعتمد على الدلالات المختلفة لواجهتَي برمجة التطبيقات، ولكن يجب أن تتطابق بأكبر قدر ممكن.

يجب أن تنفّذ عمليات تنفيذ الأجهزة السلوكيات التالية لواجهات برمجة التطبيقات ذات الصلة بالكاميرا، وذلك لجميع الكاميرات المتاحة. عمليات تنفيذ الجهاز:

[C-0-1] يجب استخدام android.hardware.PixelFormat.YCbCr_420_SP لمعاينة البيانات المقدَّمة إلى عمليات رد الاتصال في التطبيق عندما لم يسبق للتطبيق استدعاء android.hardware.Camera.Parameters.setPreviewFormat(int).
[C-0-2] يجب أن يكون التنسيق NV21 أيضًا عند تسجيل تطبيق مثيلاً android.hardware.Camera.PreviewCallback واستدعاء النظام الطريقة onPreviewFrame() وتنسيق المعاينة YCbCr_420_SP، والبيانات في byte[] التي تم تمريرها إلى onPreviewFrame(). أي أنّ NV21 يجب أن يكون التنسيق التلقائي.
[C-0-3] يجب أن تتوافق الكاميرات الأمامية والخلفية في android.hardware.Camera مع تنسيق YV12 (كما هو موضّح في الثابت android.graphics.ImageFormat.YV12) لمعاينات الكاميرا. (قد يستخدم برنامج ترميز الفيديو والكاميرا أي تنسيق بكسل أصلي، ولكن يجب أن يتيح تنفيذ الجهاز التحويل إلى YV12).
[C-0-4] يجب أن تتوافق الأجهزة التي تعلن عن إمكانية REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE في android.request.availableCapabilities مع تنسيقي android.hardware.ImageFormat.YUV_420_888 وandroid.hardware.ImageFormat.JPEG كناتجَين من خلال واجهة برمجة التطبيقات android.media.ImageReader للأجهزة android.hardware.camera2.
[C-0-5] يجب أن يظل الجهاز ينفّذ واجهة برمجة التطبيقات الخاصة بالكاميرا الكاملة المضمّنة في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android، بغض النظر عمّا إذا كان الجهاز يتضمّن ميزة التركيز التلقائي للأجهزة أو إمكانات أخرى. على سبيل المثال، يجب أن تستدعي الكاميرات التي لا تتضمّن ميزة التركيز التلقائي أي مثيلات android.hardware.Camera.AutoFocusCallback مسجّلة (على الرغم من أنّ ذلك لا صلة له بالكاميرا التي لا تتضمّن ميزة التركيز التلقائي). يُرجى العِلم أنّ هذا ينطبق على الكاميرات الأمامية. على سبيل المثال، على الرغم من أنّ معظم الكاميرات الأمامية لا تتوافق مع التركيز التلقائي، يجب أن يتم "تزييف" عمليات معاودة الاتصال لواجهة برمجة التطبيقات كما هو موضّح.
[C-0-6] يجب التعرّف على كل اسم مَعلمة محدّد كثابت في الفئة android.hardware.Camera.Parameters والفئة android.hardware.camera2.CaptureRequest والالتزام به. في المقابل، يجب ألا تنفّذ الأجهزة أو تتعرّف على الثوابت النصية التي يتم تمريرها إلى طريقة android.hardware.Camera.setParameters() بخلاف تلك الموثّقة كثوابت في android.hardware.Camera.Parameters. أي أنّ عمليات تنفيذ الأجهزة يجب أن تتوافق مع جميع مَعلمات الكاميرا العادية إذا كان الجهاز يتيح ذلك، ويجب ألا تتوافق مع أنواع مَعلمات الكاميرا المخصّصة. على سبيل المثال، يجب أن تتوافق عمليات تنفيذ الأجهزة التي تتيح التقاط الصور باستخدام تقنيات التصوير بنطاق عالي الديناميكية (HDR) مع مَعلمة الكاميرا Camera.SCENE_MODE_HDR.
[C-0-7] يجب الإبلاغ عن مستوى التوافق المناسب باستخدام السمة android.info.supportedHardwareLevel كما هو موضّح في حزمة تطوير البرامج (SDK) لنظام التشغيل Android، والإبلاغ عن علامات ميزات إطار العمل المناسبة.
[C-0-8] يجب أيضًا الإفصاح عن إمكانات الكاميرا الفردية android.hardware.camera2 من خلال السمة android.request.availableCapabilities والإفصاح عن علامات الميزات المناسبة، ويجب تحديد علامة الميزة إذا كان أي من أجهزة الكاميرا المرفقة يتيح استخدام الميزة.
[C-0-9] يجب أن يبث Camera.ACTION_NEW_PICTURE intent كلما تم التقاط صورة جديدة بالكاميرا وتمت إضافة إدخال الصورة إلى مستودع الوسائط.
[C-0-10] يجب بث الغرض Camera.ACTION_NEW_VIDEO عندما تسجّل الكاميرا فيديو جديدًا وتتم إضافة إدخال الصورة إلى "متجر الوسائط".
[C-0-11] يجب أن تكون جميع الكاميرات التي يمكن الوصول إليها من خلال واجهة برمجة التطبيقات القديمة android.hardware.Camera متاحة أيضًا من خلال واجهة برمجة التطبيقات android.hardware.camera2.
[C-0-12] يجب التأكّد من عدم تعديل مظهر الوجه، بما في ذلك على سبيل المثال لا الحصر، تعديل شكل الوجه أو درجة لون بشرة الوجه أو تنعيم بشرة الوجه لأي واجهة برمجة تطبيقات android.hardware.camera2 أو android.hardware.Camera.
[C-SR-1] بالنسبة إلى الأجهزة التي تتضمّن كاميرات RGB متعددة متجاورة وموجّهة في الاتجاه نفسه، يُنصح بشدة بتوفير جهاز كاميرا منطقي يعرض الإمكانية CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA، ويتألف من جميع كاميرات RGB الموجّهة في هذا الاتجاه كأجهزة فرعية مادية.

إذا كانت عمليات تنفيذ الأجهزة توفّر واجهة برمجة تطبيقات خاصة بالكاميرا لتطبيقات الجهات الخارجية، يجب أن تستوفي ما يلي:

[C-1-1] يجب تنفيذ واجهة برمجة تطبيقات الكاميرا هذه باستخدام واجهة برمجة التطبيقات android.hardware.camera2.
يمكن تقديم علامات المورّدين و/أو الإضافات إلى واجهة برمجة التطبيقات android.hardware.camera2.

إذا كانت عمليات تنفيذ الأجهزة تضبط مسار الكاميرا التابع لجهة خارجية ليكون متوافقًا مع مسار الكاميرا المدمجة للكاميرا الأمامية الأساسية والكاميرا الخلفية الأساسية، فإنّها:

[C-2-1] يجب الإعلان عن سمة النظام ro.camera.default_app_social_media_parity_enabled.

‫7.5.5. اتجاه الكاميرا

إذا كانت عمليات تنفيذ الأجهزة تتضمّن كاميرا أمامية أو خلفية، يجب أن تستوفي هذه الكاميرات ما يلي:

[C-1-1] يجب أن يكون اتجاه الكاميرا بحيث يتوافق البُعد الأطول للكاميرا مع البُعد الأطول للشاشة. أي عندما يكون الجهاز في الوضع الأفقي، يجب أن تلتقط الكاميرات الصور في الوضع الأفقي. وينطبق ذلك بغض النظر عن الاتجاه الطبيعي للجهاز، أي أنّه ينطبق على الأجهزة التي يكون اتجاهها الأساسي أفقيًا وكذلك الأجهزة التي يكون اتجاهها الأساسي عموديًا.

يُستثنى من هذا الشرط الأجهزة التي تستوفي أيًا من المعايير التالية:
- أن يتضمّن الجهاز شاشات ذات أشكال متغيرة، مثل الشاشات القابلة للطي أو المزودة بمفصلات، وأن ينتقل الجهاز بين الوضعَين الرأسي والأفقي (أو العكس) عند تغيير حالة الطي أو المفصلة.
- عمليات تنفيذ الأجهزة التي لا يمكن للمستخدم تدويرها، مثل أجهزة السيارات

‫7.6. الذاكرة ومساحة التخزين

‫7.6.1. الحد الأدنى من الذاكرة ومساحة التخزين

عمليات تنفيذ الجهاز:

[C-0-1] يجب أن يتضمّن مدير تنزيل يمكن للتطبيقات استخدامه لتنزيل ملفات البيانات، ويجب أن يكون قادرًا على تنزيل ملفات فردية بحجم 100 ميغابايت على الأقل إلى موقع "ذاكرة التخزين المؤقت" التلقائي.

‫7.6.2. مساحة التخزين المشتركة للتطبيقات

عمليات تنفيذ الجهاز:

[C-0-1] يجب توفير مساحة تخزين يمكن للتطبيقات مشاركتها، ويُشار إليها أيضًا باسم "مساحة التخزين الخارجية المشتركة" أو "مساحة التخزين المشتركة للتطبيقات" أو مسار Linux "/sdcard" الذي يتم تركيبها عليه.
[C-0-2] يجب أن يتم ضبطه على وحدة تخزين مشتركة يتم تركيبها تلقائيًا، أي "بدون أي إعدادات إضافية"، بغض النظر عمّا إذا كانت وحدة التخزين مدمجة في أحد مكونات وحدة التخزين الداخلية أو في وسيط تخزين قابل للإزالة (مثل فتحة بطاقة Secure Digital).
[C-0-3] يجب ربط مساحة التخزين المشتركة للتطبيق مباشرةً بمسار Linux sdcard أو تضمين رابط رمزي لنظام Linux من sdcard إلى نقطة الربط الفعلية.
[C-0-4] يجب تفعيل ميزة "التخزين المحصور" تلقائيًا لجميع التطبيقات التي تستهدف المستوى 29 أو أعلى من واجهة برمجة التطبيقات، باستثناء الحالة التالية:
- عندما يطلب التطبيق android:requestLegacyExternalStorage="true" في بيان التطبيق
[C-0-5] يجب إخفاء البيانات الوصفية للموقع الجغرافي، مثل علامات Exif لنظام تحديد المواقع العالمي (GPS)، المخزَّنة في ملفات الوسائط عند الوصول إلى هذه الملفات من خلال MediaStore، باستثناء الحالات التي يملك فيها التطبيق الذي يطلب الوصول إذن ACCESS_MEDIA_LOCATION.

يمكن أن تستوفي عمليات تنفيذ الأجهزة المتطلبات المذكورة أعلاه باستخدام أي مما يلي:

مساحة تخزين قابلة للإزالة يمكن للمستخدم الوصول إليها، مثل فتحة بطاقة Secure Digital (SD).
جزء من وحدة التخزين الداخلية (غير القابلة للإزالة) كما هو موضّح في "المشروع المفتوح المصدر لنظام Android" ‏ (AOSP)

إذا كانت عمليات تنفيذ الأجهزة تستخدم مساحة تخزين قابلة للإزالة لاستيفاء المتطلبات المذكورة أعلاه، يجب أن تستوفي ما يلي:

[C-1-1] يجب تنفيذ واجهة مستخدم تعرض إشعارًا منبثقًا أو رسالة تحذيرية للمستخدم عندما لا يكون هناك وسيط تخزين مُدرَج في الفتحة.
[C-1-2] يجب أن يتضمّن وسيط تخزين منسَّقًا بتنسيق FAT (مثل بطاقة SD) أو أن يوضّح على العلبة والمواد الأخرى المتوفّرة عند الشراء أنّه يجب شراء وسيط التخزين بشكل منفصل.

إذا كانت عمليات تنفيذ الأجهزة تستخدم جزءًا من مساحة التخزين غير القابلة للإزالة لاستيفاء المتطلبات المذكورة أعلاه، يجب أن:

يجب استخدام تطبيق AOSP لوحدة التخزين المشترَكة للتطبيق الداخلي.
قد تتم مشاركة مساحة التخزين مع البيانات الخاصة بالتطبيق.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB يتيح وضع الجهاز الطرفي USB، يجب أن تستوفي ما يلي:

[C-3-1] يجب توفير آلية للوصول إلى البيانات في مساحة التخزين المشتركة للتطبيق من جهاز كمبيوتر مضيف.
يجب أن يعرض المحتوى من كلا مسارَي التخزين بشفافية من خلال خدمة "ماسح الوسائط" في Android وandroid.provider.MediaStore.
يمكن استخدام وحدة تخزين USB، ولكن يجب استخدام بروتوكول نقل الوسائط لتلبية هذا الشرط.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB مع وضع الجهاز الطرفي USB وتتوافق مع بروتوكول نقل الوسائط، فإنّها:

يجب أن يكون متوافقًا مع المرجع المضيف لبروتوكول نقل الوسائط (MTP) على Android، وهو نقل ملفات Android.
يجب الإبلاغ عن فئة جهاز USB بقيمة 0x00.
يجب الإبلاغ عن اسم واجهة USB باسم "MTP".

‫7.6.3. وحدة تخزين قابلة للاستخدام

إذا كان من المتوقّع أن يكون الجهاز جوّالاً بطبيعته على عكس التلفزيون، تكون عمليات تنفيذ الجهاز كما يلي:

[C-SR-1] يُنصح بشدة بتنفيذ ميزة "وحدة التخزين القابلة للنقل" في موقع جغرافي ثابت على المدى الطويل، لأنّ فصلها عن طريق الخطأ قد يؤدي إلى فقدان البيانات أو تلفها.

إذا كان منفذ جهاز التخزين القابل للإزالة في مكان ثابت على المدى الطويل، مثل داخل حجرة البطارية أو غطاء واقٍ آخر، يجب أن تتضمّن عمليات تنفيذ الجهاز ما يلي:

[C-SR-2] يُنصح بشدة بتنفيذ وحدة تخزين قابلة للاستخدام.

7.7. USB

التعريفات

وضع مضيف USB هو عندما يعمل تنفيذ الجهاز كمضيف USB، ويوفر الطاقة على الناقل، ويتواصل مع الأجهزة الطرفية.
وضع جهاز USB (المعروف أيضًا باسم وضع جهاز USB الطرفي) هو عندما يعمل تنفيذ الجهاز كجهاز USB طرفي، ويتصل بمضيف عبر منفذ المنبع، ويستجيب للطلبات الواردة من المضيف.
يُعرَّف منفذ USB على أنّه آلية لتوفير اتصال USB، سواء كان مقبس USB فعليًا أو واجهة غير عادية (على سبيل المثال، دبابيس توصيل).

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB، يجب أن:

يجب أن يتيح وضع "جهاز USB".
يجب أن يتيح وضع مضيف USB.
يجب أن يتيح إيقاف إشارات البيانات عبر USB.

‫7.7.1. وضع جهاز USB

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB متوافقًا مع وضع الجهاز الملحق الجهاز:

[C-1-1] يجب أن يكون المنفذ قابلاً للتوصيل بمضيف USB يحتوي على منفذ USB من النوع A أو النوع C.
[C-1-2] يجب عرض القيمة الصحيحة iSerialNumber في واصف جهاز USB القياسي من خلال android.os.Build.SERIAL.
‫[C-1-3] يجب أن يرصد الجهاز الشواحن بقدرة 1.5 أمبير و3.0 أمبير وفقًا لمعيار مقاومة النوع C، ويجب أن يرصد التغييرات في الإعلان إذا كان متوافقًا مع منفذ USB من النوع C.

[C-SR-1] يجب أن يستخدم المنفذ عامل الشكل micro-B أو micro-AB أو USB من النوع C. يُنصح بشدة بأن تستوفي أجهزة Android الحالية والجديدة هذه المتطلبات لتتمكّن من الترقية إلى إصدارات المنصة المستقبلية.

[C-SR-2] يجب أن يكون المنفذ في أسفل الجهاز (وفقًا للاتجاه الطبيعي) أو يجب تفعيل تدوير الشاشة باستخدام البرامج لجميع التطبيقات (بما في ذلك الشاشة الرئيسية)، وذلك لكي يتم عرض المحتوى بشكل صحيح عندما يكون الجهاز في وضع يكون فيه المنفذ في الأسفل. يُنصح بشدة بأن تستوفي أجهزة Android الحالية والجديدة هذه المتطلبات لكي تتمكّن من الترقية إلى إصدارات المنصة المستقبلية.
[C-SR-3] يجب أن يتيح الجهاز سحب تيار بقوة 1.5 أمبير أثناء إرسال إشارة صوتية عالية السرعة وحركة البيانات كما هو محدّد في مواصفات شحن البطارية عبر منفذ USB، الإصدار 1.2. يُنصح بشدة بأن تستوفي أجهزة Android الحالية والجديدة هذه المتطلبات لكي تتمكّن من الترقية إلى إصدارات المنصة المستقبلية.
[C-SR-4] يُنصح بشدة بعدم توفير طرق شحن خاصة تعدّل جهد Vbus بما يتجاوز المستويات التلقائية، أو تغيّر أدوار المصدر/المستقبِل، لأنّ ذلك قد يؤدي إلى حدوث مشاكل في إمكانية التشغيل التفاعلي مع الشواحن أو الأجهزة التي تتوافق مع طرق الشحن السريع بمعيار USB العادية. على الرغم من أنّنا نؤكّد على أنّ هذا الإجراء "مُوصى به بشدة"، قد نَشترط في إصدارات Android المستقبلية أن تتوافق جميع الأجهزة من النوع C بشكل كامل مع الشواحن العادية من النوع C.
[C-SR-5] يُنصح بشدة بتوفير ميزة الشحن الفائق السرعة لتبديل دور البيانات والطاقة عند توفير منفذ USB من النوع C ووضع مضيف USB.
يجب أن يدعم الشحن الفائق السرعة للشحن بجهد عالٍ، وأن يدعم أوضاعًا بديلة، مثل عرض المحتوى على شاشة خارجية.
يجب تنفيذ واجهة برمجة التطبيقات (API) ومواصفات Android Open Accessory (AOA) على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB وتنفّذ مواصفات AOA ، فإنّها:

[C-2-1] يجب الإفصاح عن إمكانية استخدام ميزة الجهاز android.hardware.usb.accessory.
‫[C-2-2] يجب أن يتضمّن فئة التخزين الكبير عبر USB السلسلة "android" في نهاية سلسلة وصف الواجهة iInterface الخاصة بالتخزين الكبير عبر USB

‫7.7.2. وضع مستضيف USB

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB متوافقًا مع وضع المضيف، يجب أن:

[C-1-1] يجب تنفيذ واجهة برمجة تطبيقات مضيف USB لنظام التشغيل Android على النحو الموضّح في حزمة تطوير البرامج (SDK) لنظام التشغيل Android، ويجب الإعلان عن إتاحة ميزة الأجهزة android.hardware.usb.host.
[C-1-2] يجب توفير إمكانية توصيل الأجهزة الطرفية العادية بمنفذ USB. يجب أن تتضمّن إحدى المعلومات التالية:
- أن يتضمّن منفذ USB من النوع C على الجهاز فقط أو أن يكون مزوّدًا بكابلات تحوّل منفذًا خاصًا بالجهاز إلى منفذ USB من النوع C (جهاز USB من النوع C).
- منفذ USB من النوع A على الجهاز فقط أو كابلات تحويل منفذ خاص على الجهاز إلى منفذ USB من النوع A عادي
- منفذ micro-AB USB على الجهاز فقط، والذي من المفترض أن يتم شحنه مع كابل يتوافق مع منفذ USB من النوع A العادي
[C-1-3] يجب ألا يتم شحن الأجهزة مع محوّل يحوّل من منافذ USB من النوع A أو micro-AB إلى منفذ USB من النوع C (مقبس).
[C-SR-1] يُنصح بشدة بتنفيذ فئة صوت USB على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
يجب أن يتيح شحن جهاز USB الطرفي المتصل أثناء وضع المضيف، وأن يعلن عن تيار مصدر لا يقل عن 1.5 أمبير على النحو المحدّد في قسم "معلمات الإنهاء" من مواصفات كابل وموصل USB من النوع C، الإصدار 1.2 لموصلات USB من النوع C أو باستخدام نطاق تيار الإخراج لمنفذ الشحن السفلي (CDP) على النحو المحدّد في مواصفات شحن بطارية USB، الإصدار 1.2 لموصلات Micro-AB.
يجب تنفيذ معايير USB من النوع C وتوفير الدعم لها.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB يتيح وضع المضيف وفئة صوت USB، يجب أن:

[C-2-1] يجب أن يتوافق مع فئة أجهزة واجهة المستخدم البشرية (HID) عبر USB.
[C-2-2] يجب أن يتيح رصد حقول بيانات HID التالية وتعيينها المحدّدة في جداول استخدام USB HID وطلب استخدام الأوامر الصوتية إلى الثوابت KeyEvent كما هو موضّح أدناه:
- صفحة الاستخدام (0xC) معرّف الاستخدام (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
- صفحة الاستخدام (0xC) معرّف الاستخدام (0x0E9): KEYCODE_VOLUME_UP
- صفحة الاستخدام (0xC) رقم تعريف الاستخدام (0x0EA): KEYCODE_VOLUME_DOWN
- صفحة الاستخدام (0xC) معرّف الاستخدام (0x0CF): KEYCODE_VOICE_ASSIST

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB يتيح وضع المضيف وStorage Access Framework (SAF)، فإنّها:

[C-3-1] يجب أن يتعرّف الجهاز على أي أجهزة متصلة عن بُعد تستخدم بروتوكول نقل الوسائط (MTP) وأن يتيح الوصول إلى محتواها من خلال أغراض ACTION_GET_CONTENT وACTION_OPEN_DOCUMENT وACTION_CREATE_DOCUMENT.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB متوافقًا مع وضع المضيف ومنفذ USB من النوع C، يجب أن تستوفي ما يلي:

[C-4-1] يجب تنفيذ وظيفة "الطاقة المزدوجة الدور" (DRP) على النحو المحدّد في مواصفات USB Type-C (القسم 4.5.1.3.3). بالنسبة إلى منافذ DRP، على الأجهزة التي تتضمّن مقبس صوت 3.5 ملم، قد يكون رصد مصدر طاقة USB (وضع المضيف) متوقفًا تلقائيًا، ولكن يجب أن يتمكّن المستخدم من تفعيله.
[C-SR-2] يُنصح بشدة بتوفير دعم DisplayPort.
- يجب أن تتوافق مع معدّلات نقل البيانات SuperSpeed عبر USB.
- يُنصح بشدة باستخدامها لدعم ميزة الشحن الفائق السرعة وإتاحة تبديل أدوار البيانات والطاقة.
[C-SR-3] يُنصح بشدة بعدم توفير وضع ملحق محوّل الصوت كما هو موضّح في الملحق A من مواصفات الكابل والموصل من النوع USB Type-C، الإصدار 1.2.
يجب تنفيذ نموذج Try.* الأكثر ملاءمةً لشكل الجهاز. على سبيل المثال، يجب أن يتيح الجهاز المحمول استخدام نموذج Try.SNK.

‫7.7.3. الشحن السريع بمعيار USB

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB من النوع C، يجب أن تستوفي ما يلي:

[C-SR-1] يُنصح بشدة بتنفيذ فئة موصّل USB من النوع C في النواة وتنفيذ العُقد اللازمة التي تصف اتصالات USB من النوع C وأدوار الطاقة والبيانات. يُرجى الرجوع إلى مستندات Android USB Type-C لمعرفة تفاصيل التنفيذ.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB من النوع C وتتيح توصيل الطاقة، فإنّها:

‫[C-SR-2] يُنصح بشدة بتنفيذ جميع العُقد التي تصف الشحن السريع بمعيار USB. يُرجى الرجوع إلى مستندات Android USB PD للحصول على تفاصيل التنفيذ.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB من النوع C وتتيح استخدام أوضاع بديلة، يجب أن تستوفي ما يلي:

[C-SR-3] يُنصح بشدة بتنفيذ "الأوضاع البديلة" والخصائص ذات الصلة بالهوية في فئة موصّل USB من النوع C في النواة. يُرجى الرجوع إلى مستندات Android USB Type-C لمعرفة تفاصيل التنفيذ.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB من النوع C وتتيح وضع Thunderbolt 3 البديل، يجب أن تستوفي ما يلي:

[C-SR-4] يُنصح بشدة بتنفيذ إمكانية إلغاء الوضع البديل الحالي من خلال فئة موصّل النوع C.

‫7.8. الصوت

‫7.8.1. الميكروفون

إذا كانت عمليات تنفيذ الأجهزة تتضمّن ميكروفونًا، يجب أن تستوفي ما يلي:

[C-1-1] يجب عرض ثابت ميزة android.hardware.microphone.
[C-1-2] يجب استيفاء متطلبات التسجيل الصوتي الواردة في الفقرة 5.4.
[C-1-3] يجب استيفاء متطلبات وقت استجابة الصوت المحدّدة في الفقرة 5.6.
[C-SR-1] يُنصح بشدة بتوفير إمكانية تسجيل الصوت القريب من نطاق الموجات فوق الصوتية على النحو الموضّح في الفقرة 7.8.3.

إذا كانت عمليات تنفيذ الأجهزة لا تتضمّن ميكروفونًا، يجب أن:

[C-2-1] يجب عدم عرض الثابت الخاص بميزة android.hardware.microphone.
[C-2-2] يجب تنفيذ واجهة برمجة التطبيقات لتسجيل الصوت كعمليات غير فعّالة على الأقل، وذلك وفقًا للفقرة 7.

‫7.8.2. إخراج الصوت

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مكبّر صوت أو منفذ إخراج صوتي/متعدّد الوسائط لمصدر إخراج الصوت، مثل مقبس صوت رباعي الموصلات بطول 3.5 ملم أو منفذ وضع مضيف USB باستخدام فئة صوت USB، يجب أن تستوفي ما يلي:

[C-1-1] يجب عرض ثابت ميزة android.hardware.audio.output.
[C-1-2] يجب أن يستوفي متطلبات تشغيل الصوت الواردة في الفقرة 5.5.
[C-1-3] يجب استيفاء متطلبات وقت استجابة الصوت المحدّدة في الفقرة 5.6.
[C-SR-1] يُنصح بشدة بتوفير إمكانية تشغيل الصوت القريب من نطاق ما فوق الصوتي على النحو الموضّح في الفقرة 7.8.3.

إذا لم تتضمّن عمليات تنفيذ الأجهزة مكبّر صوت أو مصدر إخراج الصوت، يجب أن:

[C-2-1] يجب عدم الإبلاغ عن ميزة android.hardware.audio.output.
[C-2-2] يجب تنفيذ واجهات برمجة التطبيقات ذات الصلة بإخراج الصوت كعمليات غير فعّالة على الأقل.

لأغراض هذا القسم، "منفذ الإخراج" هو واجهة فعلية مثل مقبس صوت 3.5 ملم أو HDMI أو منفذ وضع المضيف USB مع فئة صوت USB. لا يُعدّ توفير مصدر إخراج الصوت عبر بروتوكولات مستندة إلى الراديو، مثل Bluetooth أو Wi-Fi أو شبكة الجوّال، بمثابة تضمين "منفذ إخراج".

‫7.8.2.1. منافذ الصوت التناظري

لكي تكون سماعات الرأس وملحقات الصوت الأخرى متوافقة مع مقبس الصوت 3.5 ملم في جميع أنحاء منظومة Android المتكاملة، إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذًا واحدًا أو أكثر من منافذ الصوت التناظرية، يجب أن تستوفي ما يلي:

[C-SR-1] يُنصح بشدة بتضمين منفذ واحد على الأقل من منافذ الصوت على أن يكون مقبس صوت 3.5 ملم بـ 4 موصلات.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقبس صوت رباعي الموصلات مقاس 3.5 ملم، يجب أن تستوفي ما يلي:

‫[C-1-1] يجب أن يتيح الجهاز تشغيل الصوت على سمّاعات رأس استيريو وسمّاعات أذن استيريو مزوّدة بميكروفون.
[C-1-2] يجب أن تتوافق الأجهزة مع مقابس الصوت TRRS بترتيب دبابيس CTIA.
[C-1-3] يجب أن يتيح الجهاز رصد نطاقات المعاوقة المكافئة الثلاثة التالية بين الميكروفون وموصلات التأريض على قابس الصوت، وربطها برموز المفاتيح:
- ‫70 أوم أو أقل: KEYCODE_HEADSETHOOK
- من 210 إلى 290 أوم: KEYCODE_VOLUME_UP
- من 360 إلى 680 أوم: KEYCODE_VOLUME_DOWN
[C-1-4] يجب أن يتم تشغيل ACTION_HEADSET_PLUG عند إدخال القابس، ولكن فقط بعد أن تلامس جميع نقاط التوصيل الموجودة على القابس الأجزاء ذات الصلة بها في المقبس.
[C-1-5] يجب أن يكون الجهاز قادرًا على توفير جهد كهربائي خارج يبلغ 150 ملي فولت ±% 10 على الأقل عند مقاومة سماعة تبلغ 32 أوم.
[C-1-6] يجب أن يتراوح جهد انحياز الميكروفون بين 1.8 و2.9 فولت.
[C-1-7] يجب أن يرصد الجهاز نطاق المعاوقة المكافئة التالي بين موصّلي الميكروفون والأرضي في قابس الصوت وأن يربطه برمز المفتاح:
- من 110 إلى 180 أوم: KEYCODE_VOICE_ASSIST
[C-SR-2] يُنصح بشدة بتوفير مقابس صوتية متوافقة مع ترتيب دبابيس OMTP.
[C-SR-3] يُنصح بشدة بتوفير إمكانية تسجيل الصوت من سمّاعات رأس ستيريو مزوّدة بميكروفون.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقبس صوت رباعي الموصلات مقاس 3.5 ملم ويتوافق مع ميكروفون، وتبث android.intent.action.HEADSET_PLUG مع قيمة إضافية للميكروفون تم ضبطها على 1، فإنّها:

[C-2-1] يجب أن يتيح رصد الميكروفون في ملحق الصوت الموصّل.

‫7.8.2.2. منافذ الصوت الرقمي

راجِع القسم 2.2.1 لمعرفة المتطلبات الخاصة بالأجهزة.

‫7.8.3. الموجات فوق الصوتية القريبة

النطاق الصوتي القريب من الموجات فوق الصوتية هو النطاق من 18.5 كيلوهرتز إلى 20 كيلوهرتز.

عمليات تنفيذ الجهاز:

يجب أن تعرض واجهة برمجة التطبيقات AudioManager.getProperty إمكانية استخدام الصوت القريب من الموجات فوق الصوتية بشكل صحيح على النحو التالي:

إذا كانت قيمة PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND هي "true"، يجب أن تستوفي مصادر الصوت VOICE_RECOGNITION وUNPROCESSED المتطلبات التالية:

[C-1-1] يجب ألا يقل متوسط استجابة الطاقة للميكروفون في النطاق من 18.5 كيلو هرتز إلى 20 كيلو هرتز عن 15 ديسيبل مقارنةً بالاستجابة عند 2 كيلو هرتز.
‫[C-1-2] يجب ألا تقل نسبة الإشارة إلى الضوضاء غير المرجّحة للميكروفون في نطاق التردد من 18.5 كيلو هرتز إلى 20 كيلو هرتز بالنسبة إلى نغمة بتردد 19 كيلو هرتز عند مستوى -26 ديسيبل عن 50 ديسيبل.

إذا كانت قيمة PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND هي "true":

‫[C-2-1] يجب ألا يقل متوسط استجابة السمّاعة في نطاق التردد من 18.5 كيلو هرتز إلى 20 كيلو هرتز عن 40 ديسيبل تحت الاستجابة عند 2 كيلو هرتز.

‫7.8.4. سلامة الإشارة

عمليات تنفيذ الجهاز:

يجب توفير مسار إشارة صوتية خالٍ من الأخطاء لكل من تدفقات الإدخال والإخراج على الأجهزة المحمولة، كما هو محدّد بعدم حدوث أي أخطاء تم قياسها خلال اختبار لمدة دقيقة واحدة لكل مسار. اختبِر باستخدام OboeTester "اختبار الأخطاء المبرمَج".

يتطلّب الاختبار مفتاح إلكتروني لتكرار الصوت، يتم استخدامه مباشرةً في مقبس 3.5 ملم، و/أو مع محوّل من منفذ USB-C إلى 3.5 ملم. يجب اختبار جميع مصادر إخراج الصوت.

يتوافق OboeTester حاليًا مع مسارات AAudio، لذا يجب اختبار المجموعات التالية بحثًا عن أخطاء باستخدام AAudio:

وضع الأداء	المشاركة	معدّل البيانات في الملف الصوتي	في قنوات	Out Chans
LOW_LATENCY	EXCLUSIVE	غير محدّد	1	2
LOW_LATENCY	EXCLUSIVE	غير محدّد	2	1
LOW_LATENCY	مشترك	غير محدّد	1	2
LOW_LATENCY	مشترك	غير محدّد	2	1
NONE	مشترك	48000	1	2
NONE	مشترك	48000	2	1
NONE	مشترك	44100	1	2
NONE	مشترك	44100	2	1
NONE	مشترك	16000	1	2
NONE	مشترك	16000	2	1

يجب أن يستوفي البث الموثوق المعايير التالية المتعلقة بنسبة الإشارة إلى الضوضاء (SNR) والتشويه التوافقي الكلي (THD) لموجة جيبية بتردد 2000 هرتز.

محوّل الطاقة	THD	SNR
مكبّر الصوت الأساسي المدمج، ويتم قياسه باستخدام ميكروفون مرجعي خارجي	أقل من %3.0	‫>= 50 ديسيبل
الميكروفون الأساسي المُدمَج، ويتم قياسه باستخدام مكبّر صوت مرجعي خارجي	أقل من %3.0	‫>= 50 ديسيبل
مقابس تناظرية مدمجة مقاس 3.5 ملم، تم اختبارها باستخدام محوّل loopback	أقل من %1	‫‎>= 60 ديسيبل
محوّلات USB المرفقة مع الهاتف، تم اختبارها باستخدام محوّل loopback	أقل من %1.0	‫‎>= 60 ديسيبل

‫7.9. الواقع الافتراضي

يتضمّن نظام التشغيل Android واجهات برمجة تطبيقات ومرافق لإنشاء تطبيقات "الواقع الافتراضي" (VR)، بما في ذلك تجارب الواقع الافتراضي عالية الجودة على الأجهزة الجوّالة. يجب أن تنفّذ الأجهزة هذه الواجهات والسلوكيات بشكل سليم، كما هو موضّح بالتفصيل في هذا القسم.

‫7.9.1. وضع الواقع الافتراضي

يتوافق نظام التشغيل Android مع وضع الواقع الافتراضي، وهي ميزة تعالج العرض المجسّم للإشعارات وتوقف مكوّنات واجهة مستخدم النظام أحادية العين عندما يكون تطبيق الواقع الافتراضي هو التطبيق النشط.

‫7.9.2. وضع الواقع الافتراضي - أداء عالٍ

إذا كانت عمليات تنفيذ الأجهزة تتيح وضع الواقع الافتراضي، يجب أن:

[C-1-1] يجب أن تتضمّن وحدتا معالجة مركزية مادية على الأقل.
[C-1-2] يجب الإفصاح عن ميزة android.hardware.vr.high_performance.
[C-1-3] يجب أن يتوافق الجهاز مع وضع الأداء المستدام.
[C-1-4] يجب أن يتوافق مع OpenGL ES 3.2.
[C-1-5] يجب أن تتوافق مع android.hardware.vulkan.level 0.
يجب أن تتوافق مع الإصدار 1 من android.hardware.vulkan.level أو إصدار أحدث.
[C-1-6] يجب تنفيذ EGL_KHR_mutable_render_buffer و EGL_ANDROID_front_buffer_auto_refresh و EGL_ANDROID_get_native_client_buffer و EGL_KHR_fence_sync و EGL_KHR_wait_sync و EGL_IMG_context_priority و EGL_EXT_protected_content و EGL_EXT_image_gl_colorspace، وعرض الإضافات في قائمة إضافات EGL المتاحة.
[C-1-8] يجب تنفيذ GL_EXT_multisampled_render_to_texture2 و GL_OVR_multiview و GL_OVR_multiview2 و GL_EXT_protected_textures، وعرض الإضافات في قائمة إضافات GL المتاحة.
[C-SR-1] يُنصح بشدة بتنفيذ GL_EXT_external_buffer و GL_EXT_EGL_image_array و GL_OVR_multiview_multisampled_render_to_texture، وعرض الإضافات في قائمة إضافات GL المتاحة.
‫[C-SR-2] يُنصح بشدة بتوفير إمكانية استخدام Vulkan 1.1.
[C-SR-3] يُنصح بشدة بتنفيذ VK_ANDROID_external_memory_android_hardware_buffer و VK_GOOGLE_display_timing و VK_KHR_shared_presentable_image وعرضها في قائمة إضافات Vulkan المتاحة.
[C-SR-4] يُنصح بشدة بعرض مجموعة واحدة على الأقل من قوائم انتظار Vulkan التي تحتوي فيها flags على كل من VK_QUEUE_GRAPHICS_BIT وVK_QUEUE_COMPUTE_BIT، وأن تكون قيمة queueCount هي 2 على الأقل.
‫[C-1-7] يجب أن يكون بإمكان وحدة معالجة الرسومات والشاشة مزامنة الوصول إلى المخزن المؤقت الأمامي المشترك، وذلك لضمان عرض محتوى الواقع الافتراضي بمعدل 60 إطارًا في الثانية مع سياقَي عرض بالتناوب بين العينين بدون أي تشوّهات مرئية.
[C-1-9] يجب توفير دعم لعلامات AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER وAHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA وAHARDWAREBUFFER_USAGE_PROTECTED_CONTENT على النحو الموضّح في NDK.
[C-1-10] يجب توفير إمكانية استخدام AHardwareBuffer مع أي مجموعة من علامات الاستخدام AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT وAHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE وAHARDWAREBUFFER_USAGE_PROTECTED_CONTENT للتنسيقات التالية على الأقل: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM وAHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM وAHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM وAHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
[C-SR-5] يُنصح بشدة بتوفير إمكانية تخصيص AHardwareBuffers بأكثر من طبقة واحدة، بالإضافة إلى العلامات والتنسيقات المحدّدة في C-1-10.
[C-1-11] يجب أن يتوافق مع فك ترميز H.264 بدقة 3840 × 2160 على الأقل بمعدل 30 إطارًا في الثانية، مع ضغط بمعدل 40 ميغابت في الثانية في المتوسط (أي ما يعادل 4 حالات بدقة 1920 × 1080 بمعدل 30 إطارًا في الثانية وبمعدل 10 ميغابت في الثانية أو حالتين بدقة 1920 × 1080 بمعدل 60 إطارًا في الثانية وبمعدل 20 ميغابت في الثانية).
‫[C-1-12] يجب أن يتوافق الجهاز مع ترميز HEVC وVP9، ويجب أن يكون قادرًا على فك ترميز محتوى بدقة 1920 × 1080 بمعدل 30 إطارًا في الثانية مضغوطًا بمعدل 10 ميغابت في الثانية في المتوسط، ويجب أن يكون قادرًا على فك ترميز محتوى بدقة 3840 × 2160 بمعدل 30 إطارًا في الثانية بمعدل 20 ميغابت في الثانية (أي ما يعادل 4 حالات بدقة 1920 × 1080 بمعدل 30 إطارًا في الثانية بمعدل 5 ميغابت في الثانية).
[C-1-13] يجب أن تتوافق مع واجهة برمجة التطبيقات HardwarePropertiesManager.getDeviceTemperatures وأن تعرض قيمًا دقيقة لدرجة حرارة الجلد.
‫[C-1-14] يجب أن يتضمّن شاشة مدمجة، ويجب أن تكون درجة الدقة 1920 × 1080 على الأقل.
[C-SR-6] يُنصح بشدة أن تكون دقة العرض 2560 × 1440 على الأقل.
‫[C-1-15] يجب أن يتم تعديل الشاشة بمعدّل 60 هرتز على الأقل أثناء وضع الواقع الافتراضي.
‫[C-1-17] يجب أن تتيح الشاشة وضعًا منخفض الثبات مع ثبات ≤ 5 مللي ثانية، ويُعرَّف الثبات على أنّه مقدار الوقت الذي ينبعث فيه الضوء من البكسل.
[C-1-18] يجب أن يتوافق الجهاز مع الإصدار 4.2 من البلوتوث ومعيار Bluetooth LE Data Length Extension الفقرة 7.4.3.
[C-1-19] يجب أن يتيح الجهاز عرض نوع القناة المباشرة بشكل صحيح لجميع أنواع المستشعرات التلقائية التالية:
- TYPE_ACCELEROMETER
- TYPE_ACCELEROMETER_UNCALIBRATED
- TYPE_GYROSCOPE
- TYPE_GYROSCOPE_UNCALIBRATED
- TYPE_MAGNETIC_FIELD
- TYPE_MAGNETIC_FIELD_UNCALIBRATED
[C-SR-7] يُنصح بشدة بتوفير TYPE_HARDWARE_BUFFER نوع القناة المباشرة لجميع أنواع القنوات المباشرة المذكورة أعلاه.
[C-1-21] يجب استيفاء المتطلبات المتعلقة بالجيروسكوب ومقياس التسارع ومقياس المغناطيسية في android.hardware.hifi_sensors، كما هو محدّد في الفقرة 7.3.9.
[C-SR-8] يُنصح بشدة بتوفير ميزة android.hardware.sensor.hifi_sensors.
[C-1-22] يجب ألا يزيد وقت استجابة الحركة من البداية إلى النهاية عن 28 ملي ثانية.
[C-SR-9] يُنصح بشدة أن يكون وقت استجابة الحركة إلى الفوتون من البداية إلى النهاية أقل من 20 مللي ثانية.
[C-1-23] يجب أن تتوفّر نسبة الإطار الأول، وهي النسبة بين سطوع وحدات البكسل في الإطار الأول بعد الانتقال من اللون الأسود إلى اللون الأبيض وسطوع وحدات البكسل البيضاء في الحالة الثابتة، بنسبة %85 على الأقل.
[C-SR-10] يُنصح بشدة أن تكون نسبة الإطار الأول %90 على الأقل.
يمكن توفير نواة حصرية للتطبيق الذي يعمل في المقدّمة، ويمكن إتاحة استخدام واجهة برمجة التطبيقات Process.getExclusiveCores لعرض أرقام نوى وحدة المعالجة المركزية الحصرية للتطبيق الذي يعمل في المقدّمة.

في حال توفّر النواة الحصرية، يجب أن تستوفي النواة الشروط التالية:

[C-2-1] يجب ألا يسمح بتشغيل أي عمليات أخرى في مساحة المستخدم (باستثناء برامج تشغيل الأجهزة التي يستخدمها التطبيق)، ولكن يجوز له السماح بتشغيل بعض عمليات النواة حسب الضرورة.

‫7.10. تقنية اللمس

قد تتضمّن الأجهزة التي يمكن حملها باليد أو ارتداؤها مشغّلاً حسّيًا للأغراض العامة، وهو متاح للتطبيقات لأغراض تشمل جذب الانتباه من خلال نغمات الرنين والمنبّهات والإشعارات، بالإضافة إلى تقديم ملاحظات عامة عند اللمس.

إذا لم تتضمّن عمليات تنفيذ الأجهزة مشغّلاً لمسياً عام الأغراض، يجب أن:

[7.10/C] MUST return false for Vibrator.hasVibrator().

إذا كانت عمليات تنفيذ الأجهزة تتضمّن على الأقل مشغّلاً واحدًا من هذا النوع للأغراض العامة، يجب أن تستوفي ما يلي:

[C-1-1] يجب أن تعرض القيمة "صحيح" لـ Vibrator.hasVibrator().
يجب عدم استخدام مشغّل لمس ERM (محرك اهتزاز).
يجب تنفيذ جميع الثوابت العامة لردود الفعل اللمسية الواضحة في android.view.HapticFeedbackConstants وهي (CLOCK_TICK وCONTEXT_CLICK وKEYBOARD_PRESS وKEYBOARD_RELEASE وKEYBOARD_TAP وLONG_PRESS وTEXT_HANDLE_MOVE وVIRTUAL_KEY وVIRTUAL_KEY_RELEASE وCONFIRM وREJECT وGESTURE_START وGESTURE_END).
يجب تنفيذ جميع الثوابت العامة الخاصة باللمسات الواضحة في android.os.VibrationEffect وهي (EFFECT_TICK وEFFECT_CLICK وEFFECT_HEAVY_CLICK وEFFECT_DOUBLE_CLICK) وجميع الثوابت العامة الممكنة PRIMITIVE_* الخاصة باللمسات الغنية في android.os.VibrationEffect.Composition وهي (CLICK وTICK وLOW_TICK وQUICK_FALL وQUICK_RISE وSLOW_RISE وSPIN وTHUD). قد لا تكون بعض هذه العناصر الأساسية، مثل LOW_TICK وSPIN، ممكنة إلا إذا كان المحرك الاهتزازي يتيح استخدام ترددات منخفضة نسبيًا.
يجب اتّباع إرشادات ربط الثوابت العامة في android.view.HapticFeedbackConstants بالثوابت android.os.VibrationEffect المقترَحة، مع علاقات السعة المقابلة.
يجب استخدام عمليات الربط الثابتة الحسية المرتبطة هذه.
يجب اتّباع تقييم الجودة لواجهات برمجة التطبيقات createOneShot() وcreateWaveform().
يجب التأكّد من أنّ نتيجة واجهة برمجة التطبيقات العامة android.os.Vibrator.hasAmplitudeControl() تعكس إمكانات جهاز الاهتزاز بشكل صحيح.
يجب التحقّق من إمكانات قابلية توسيع نطاق السعة من خلال تنفيذ android.os.Vibrator.hasAmplitudeControl().

إذا كانت عمليات تنفيذ الأجهزة تتّبع عملية ربط الثوابت الحسية، فإنّها:

يجب التحقّق من حالة التنفيذ من خلال تشغيل واجهات برمجة التطبيقات android.os.Vibrator.areAllEffectsSupported() وandroid.os.Vibrator.arePrimitivesSupported().
يجب إجراء تقييم للجودة للمتغيرات الحسية.
يجب التحقّق من إعدادات التراجع للعناصر الأساسية غير المتوافقة وتعديلها إذا لزم الأمر، كما هو موضّح في إرشادات التنفيذ للثوابت.
يجب توفير دعم احتياطي للحدّ من مخاطر الفشل كما هو موضّح هنا.

‫7.11. فئة أداء الوسائط

يمكن الحصول على فئة أداء الوسائط لتنفيذ الجهاز من واجهة برمجة التطبيقات android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS. يتم تحديد متطلبات فئة أداء الوسائط لكل إصدار من Android بدءًا من الإصدار R (الإصدار 30). تشير القيمة الخاصة 0 إلى أنّ الجهاز ليس من فئة أداء وسائط.

إذا كانت عمليات تنفيذ الأجهزة تعرض قيمة غير صفرية لـ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS، يجب أن تستوفي ما يلي:

[C-1-1] يجب أن تعرض على الأقل القيمة android.os.Build.VERSION_CODES.R.
[C-1-2] يجب أن يكون الجهاز قابلاً للحمل باليد.
[C-1-3] يجب استيفاء جميع متطلبات "فئة أداء الوسائط" الموضّحة في الفقرة 2.2.7.

بعبارة أخرى، لا يتم تحديد فئة أداء الوسائط في Android T إلا للأجهزة المحمولة التي تعمل بالإصدار T أو S أو R.

راجِع الفقرة 2.2.7 لمعرفة المتطلبات الخاصة بالأجهزة.

8. الأداء والطاقة

تُعد بعض معايير الأداء والطاقة الدنيا ضرورية لتجربة المستخدم، كما أنّها تؤثر في الافتراضات الأساسية التي يضعها المطوّرون عند تطوير تطبيق.

‫8.1. اتّساق تجربة المستخدم

يمكن توفير واجهة مستخدم سلسة للمستخدم النهائي إذا توفّرت بعض المتطلبات الدنيا لضمان عدد اللقطات في الثانية متّسق وأوقات استجابة للتطبيقات والألعاب. قد تتضمّن عمليات تنفيذ الأجهزة، وفقًا لنوع الجهاز، متطلبات قابلة للقياس بشأن وقت استجابة واجهة المستخدم وتبديل المهام على النحو الموضّح في القسم 2.

‫8.2. أداء الوصول إلى ملفات الإدخال والإخراج

يسمح توفير أساس مشترك لأداء متسق في الوصول إلى الملفات في مساحة تخزين البيانات الخاصة بالتطبيق (قسم /data) لمطوّري التطبيقات بوضع توقعات مناسبة تساعد في تصميم برامجهم. قد تتضمّن عمليات تنفيذ الأجهزة، حسب نوع الجهاز، متطلبات معيّنة موضّحة في القسم 2 لعمليات القراءة والكتابة التالية:

أداء الكتابة التسلسلية: يتم قياس ذلك من خلال كتابة ملف بحجم 256 ميغابايت باستخدام مخزن مؤقت للكتابة بحجم 10 ميغابايت.
أداء الكتابة العشوائية: يتم قياسها من خلال كتابة ملف بحجم 256 ميغابايت باستخدام مخزن مؤقت للكتابة بحجم 4 كيلوبايت.
أداء القراءة التسلسلية: يتم قياسها من خلال قراءة ملف بحجم 256 ميغابايت باستخدام ذاكرة تخزين مؤقت للكتابة بحجم 10 ميغابايت.
أداء القراءة العشوائية يتم قياسها من خلال قراءة ملف بحجم 256 ميغابايت باستخدام ذاكرة تخزين مؤقت للكتابة بحجم 4 كيلوبايت.

8.3. أوضاع توفير الطاقة

إذا كانت عمليات تنفيذ الأجهزة تتضمّن ميزات لتحسين إدارة طاقة الجهاز المضمّنة في مشروع Android المفتوح المصدر (AOSP) (مثل "حزمة تطبيقات وضع الاستعداد" و"قيلولة") أو توسيع الميزات لتطبيق قيود أكثر صرامة من حزمة تطبيقات وضع الاستعداد "مقيّد"، يجب أن تستوفي ما يلي:

[C-1-1] يجب ألا تنحرف عن تنفيذ مشروع Android المفتوح المصدر (AOSP) لآليات التشغيل والصيانة والتنشيط، واستخدام إعدادات النظام العامة أو DeviceConfig لوضعَي "تطبيقات وضع الاستعداد" و"قيلولة" لتوفير الطاقة.
[C-1-2] يجب عدم الانحراف عن تنفيذ AOSP لاستخدام الإعدادات العامة أو DeviceConfig لإدارة تقييد المهام والتنبيهات والشبكة للتطبيقات في كل حزمة في وضع "التطبيق في وضع الاستعداد".
[C-1-3] يجب عدم الانحراف عن تنفيذ AOSP لعدد حِزم وضع التطبيق في وضع الاستعداد المستخدَمة لوضع التطبيق في وضع الاستعداد.
[C-1-4] يجب تنفيذ حِزم وضع "استعداد التطبيق" ووضع "القيلولة" كما هو موضّح في إدارة الطاقة.
[C-1-5] يجب أن تعرض true القيمة PowerManager.isPowerSaveMode() عندما يكون الجهاز في وضع توفير الطاقة.
[C-1-6] يجب توفير إمكانية وصول المستخدم لعرض جميع التطبيقات المستثناة من وضعَي توفير الطاقة، وهما وضع الاستعداد للتطبيق ووضع السكون، أو أي تحسينات أخرى للبطارية، ويجب تنفيذ الغرض ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS لطلب موافقة المستخدم على السماح لأحد التطبيقات بتجاهل تحسينات البطارية.
[C-SR-1] يُنصح بشدة بتوفير إمكانية للمستخدمين لتفعيل ميزة "توفير شحن البطارية" وإيقافها.
[C-SR-2] يُنصح بشدة بتوفير إمكانية للمستخدم لعرض جميع التطبيقات المستثناة من وضعَي "تطبيقات وضع الاستعداد" و"قيلولة" و"وضع توفير الطاقة".

إذا كانت عمليات تنفيذ الأجهزة توسّع ميزات إدارة الطاقة المضمَّنة في مشروع Android المفتوح المصدر (AOSP)، وكان هذا التوسيع يفرض قيودًا أكثر صرامة من حزمة تطبيقات وضع الاستعداد النادرة، يُرجى الرجوع إلى الفقرة 3.5.1.

بالإضافة إلى أوضاع توفير الطاقة، يمكن أن تنفّذ أجهزة Android أيًا من حالات الطاقة الأربع الخاصة بوضع السكون أو جميعها، وذلك على النحو المحدّد في واجهة الإعدادات المتقدّمة والطاقة (ACPI).

إذا كانت عمليات تنفيذ الأجهزة تنفّذ حالات الطاقة S4 على النحو المحدّد في ACPI، فإنّها:

[C-1-1] يجب ألا يتم الانتقال إلى هذه الحالة إلا بعد أن يتّخذ المستخدم إجراءً صريحًا لوضع الجهاز في حالة غير نشطة (مثل إغلاق غطاء يشكّل جزءًا ماديًا من الجهاز أو إيقاف تشغيل مركبة أو تلفزيون) وقبل أن يعيد المستخدم تنشيط الجهاز (مثل فتح الغطاء أو إعادة تشغيل المركبة أو التلفزيون).

إذا كانت عمليات تنفيذ الأجهزة تنفّذ حالات الطاقة S3 على النحو المحدّد في ACPI، فإنّها:

[C-2-1] يجب استيفاء المتطلبات الواردة في الفقرة C-1-1 أعلاه، أو يجب الانتقال إلى حالة S3 فقط عندما لا تحتاج تطبيقات الجهات الخارجية إلى موارد النظام (مثل الشاشة ووحدة المعالجة المركزية).

في المقابل، يجب الخروج من حالة S3 عندما تحتاج تطبيقات تابعة لجهات خارجية إلى موارد النظام، كما هو موضّح في حزمة SDK هذه.

على سبيل المثال، بينما تطلب التطبيقات التابعة لجهات خارجية إبقاء الشاشة مضاءة من خلال FLAG_KEEP_SCREEN_ON أو إبقاء وحدة المعالجة المركزية قيد التشغيل من خلال PARTIAL_WAKE_LOCK، يجب ألا يدخل الجهاز في حالة S3 إلا إذا اتّخذ المستخدم إجراءً صريحًا لوضع الجهاز في حالة غير نشطة، كما هو موضّح في C-1-1. في المقابل، عند تشغيل مهمة تنفّذها تطبيقات تابعة لجهات خارجية من خلال JobScheduler أو عند إرسال رسالة من مراسلة Firebase السحابية إلى تطبيقات تابعة لجهات خارجية، يجب أن يخرج الجهاز من حالة S3 ما لم يضعه المستخدم في حالة غير نشطة. هذه ليست أمثلة شاملة، إذ تنفّذ AOSP إشارات تنبيه شاملة تؤدي إلى التنبيه من هذه الحالة.

‫8.4. محاسبة استهلاك الطاقة

يوفّر تدوين سجلات الاستخدام وإعداد التقارير عن استهلاك الطاقة بشكل أكثر دقة لمطوّر تطبيقات الحوافز والأدوات اللازمة لتحسين نمط استخدام الطاقة في التطبيق.

عمليات تنفيذ الجهاز:

[C-SR-1] يُنصح بشدة بتوفير ملف تعريف طاقة لكل مكوّن يحدّد قيمة استهلاك التيار لكل مكوّن من مكونات الجهاز ومعدّل استنزاف البطارية التقريبي الذي تسببه المكونات بمرور الوقت كما هو موثّق في موقع "مشروع مفتوح المصدر لنظام Android".
[C-SR-2] يُنصح بشدة بتسجيل جميع قيم استهلاك الطاقة بوحدة ميلي أمبير في الساعة (mAh).
[C-SR-3] يُنصح بشدة بالإبلاغ عن استهلاك وحدة المعالجة المركزية للطاقة لكل معرّف مستخدم (UID) خاص بكل عملية. يستوفي "مشروع مفتوح المصدر لنظام Android" هذا الشرط من خلال تنفيذ وحدة النواة uid_cputime.
[C-SR-4] يُنصح بشدة بإتاحة معلومات استهلاك الطاقة هذه من خلال الأمر adb shell dumpsys batterystats في واجهة سطر الأوامر لمطوّر التطبيق.
يجب أن يُنسَب إلى مكوّن الجهاز نفسه إذا تعذّر تحديد التطبيق المسؤول عن استخدام الطاقة.

‫8.5. الأداء المتّسق

يمكن أن يتفاوت الأداء بشكل كبير في التطبيقات التي تعمل لفترة طويلة وتتطلّب أداءً عاليًا، إما بسبب التطبيقات الأخرى التي تعمل في الخلفية أو بسبب تقييد سرعة وحدة المعالجة المركزية نتيجةً لحدود درجة الحرارة. يتضمّن نظام التشغيل Android واجهات برمجية، وبالتالي عندما يكون الجهاز متوافقًا، يمكن للتطبيق الذي يظهر في المقدّمة أن يطلب من النظام تحسين عملية تخصيص الموارد للتعامل مع هذه التقلبات.

عمليات تنفيذ الجهاز:

[C-0-1] يجب أن يتم الإبلاغ عن إمكانية استخدام "وضع الأداء المستدام" بدقة من خلال طريقة واجهة برمجة التطبيقات PowerManager.isSustainedPerformanceModeSupported().
يجب أن يتوافق مع "وضع الأداء المستدام".

في حال إبلاغ عمليات تنفيذ الأجهزة بتوافقها مع "وضع الأداء المستدام"، يجب أن:

[C-1-1] يجب أن يوفّر التطبيق الذي يظهر في المقدّمة أعلى مستوى أداء ثابتًا لمدة 30 دقيقة على الأقل، وذلك عندما يطلب التطبيق ذلك.
[C-1-2] يجب أن يلتزم Window.setSustainedPerformanceMode() وغيره من واجهات برمجة التطبيقات ذات الصلة.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن نواتَين أو أكثر لوحدة المعالجة المركزية، يجب أن تستوفي ما يلي:

يجب توفير نواة حصرية واحدة على الأقل يمكن للتطبيق الأعلى أولوية في المقدّمة حجزها.

إذا كانت عمليات تنفيذ الأجهزة تتيح حجز نواة حصرية واحدة لأهم تطبيق يعمل في المقدّمة، يجب أن:

[C-2-1] يجب إعداد تقارير من خلال طريقة واجهة برمجة التطبيقات Process.getExclusiveCores() عن أرقام تعريف النوى الحصرية التي يمكن حجزها من خلال التطبيق الذي يعمل في المقدّمة.
[C-2-2] يجب ألا يسمح بأي عمليات في مساحة المستخدم باستثناء برامج تشغيل الأجهزة التي يستخدمها التطبيق للتشغيل على النوى الحصرية، ولكن يجوز السماح بتشغيل بعض عمليات النواة حسب الضرورة.

إذا كانت عمليات تنفيذ الأجهزة لا تتوافق مع نواة حصرية، يجب أن:

[C-3-1] يجب عرض قائمة فارغة من خلال طريقة واجهة برمجة التطبيقات Process.getExclusiveCores().

‫8.6. الحدود القصوى لذاكرة التطبيقات

سيتم فرض قيود على مقدار ذاكرة الوصول العشوائي الديناميكية (DRAM) المستخدَمة لكل عملية تطبيق فردية، وذلك من خلال MemoryLimiter، وهو مكوّن جديد من ActivityManagerService، وحدود الذاكرة التلقائية للتطبيقات، والتي يتم استخلاصها من الذاكرة الفعلية المتاحة. ينطبق هذا القيد على جميع الذاكرة المخصّصة ضمن عملية التطبيق، ما يضمن عمل الحدود كأحد السلوكيات التعاقدية المهمة مع مطوّري التطبيقات.

عمليات تنفيذ الجهاز:

[C-0-1] يجب عدم استخدام أي طرق أو قوائم سماح أو سياسات لتجاوز حدود ذاكرة وقت التشغيل المحدّدة للتطبيقات.

9. التوافق مع نموذج الأمان

عمليات تنفيذ الجهاز:

[C-0-1] يجب تنفيذ نموذج أمان متوافق مع نموذج أمان نظام Android الأساسي على النحو المحدّد في مستند مرجع الأمان والأذونات ضمن واجهات برمجة التطبيقات في مستندات مطوّري برامج Android.
‫[C-0-2] يجب أن يتيح تثبيت التطبيقات الموقَّعة ذاتيًا بدون الحاجة إلى أي أذونات أو شهادات إضافية من أي جهات خارجية أو سلطات.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن بيانًا عن الميزة android.hardware.security.model.compatible، فإنّها:

[C-1-1] يجب أن تتوافق مع المتطلبات الواردة في الأقسام الفرعية التالية.

‫9.1. الأذونات

عمليات تنفيذ الجهاز:

[C-0-1] يجب أن تتوافق مع نموذج أذونات Android ونموذج أدوار Android على النحو المحدّد في مستندات مطوّري Android. وعلى وجه التحديد، يجب أن تفرض هذه التطبيقات كل إذن ودور محدّدَين كما هو موضح في مستندات حزمة تطوير البرامج (SDK)، ولا يجوز حذف أي أذونات أو أدوار أو تغييرها أو تجاهلها.
يمكن إضافة أذونات إضافية، بشرط ألا تكون سلاسل معرّفات الأذونات الجديدة في مساحة الاسم android.\*.
[C-0-2] يجب ألا يتم منح الأذونات التي تتضمّن protectionLevel بقيمة PROTECTION_FLAG_PRIVILEGED إلا للتطبيقات المثبَّتة مسبقًا في مسارات ذات امتيازات خاصة ضمن صورة النظام (بالإضافة إلى ملفات APEX)، ويجب أن تكون ضمن المجموعة الفرعية من الأذونات المدرَجة صراحةً في القائمة البيضاء لكل تطبيق. يتوافق تنفيذ AOSP مع هذا الشرط من خلال قراءة الأذونات المدرَجة في القائمة البيضاء لكل تطبيق من الملفات في المسار etc/permissions/ والالتزام بها، واستخدام المسار system/priv-app كمسار ذي امتيازات خاصة.
[C-SR-1] يُنصح بشدة بمنح الأذونات التي تتضمّن protectionLevel من PROTECTION_SIGNATURE لأحد الخيارَين التاليَين فقط:
- التطبيقات المثبَّتة مسبقًا على صورة النظام (بالإضافة إلى ملفات APEX)
- التطبيقات المُدرَجة في القائمة المسموح بها مع الأذونات المسموح بها إذا لم تكن مضمّنة في صورة النظام
ملاحظة: يتوافق تنفيذ AOSP مع هذا الشرط من خلال قراءة الأذونات المدرَجة في القائمة المسموح بها لكل تطبيق والالتزام بها من الملفات في المسار etc/permissions/.

الأذونات التي يكون مستوى الحماية فيها خطيرًا هي أذونات وقت التشغيل. تطلب التطبيقات التي تتضمّن targetSdkVersion > 22 هذه الأذونات في وقت التشغيل.

عمليات تنفيذ الجهاز:

[C-0-3] يجب عرض واجهة مخصّصة للمستخدم ليقرّر ما إذا كان سيمنح أذونات التشغيل المطلوبة، ويجب أيضًا توفير واجهة للمستخدم لإدارة أذونات التشغيل.
[C-0-5] يجب عدم منح أي أذونات وقت التشغيل للتطبيقات إلا في الحالات التالية:
- يتم تثبيتها عند شحن الجهاز، و
- يمكن الحصول على موافقة المستخدم قبل أن يستخدم التطبيق الإذن،
أو
- يتم منح أذونات وقت التشغيل بواسطة سياسة منح الأذونات التلقائية أو عند الحصول على دور في النظام الأساسي.
[C-0-6] يجب منح إذن android.permission.RECOVER_KEYSTORE لتطبيقات النظام فقط التي تسجّل "وكيل استرداد" آمنًا بشكل صحيح. يُعرَّف "وكيل الاسترداد" المحمي بشكل صحيح على أنّه وكيل برنامج على الجهاز فقط تتم مزامنته مع مساحة تخزين بعيدة خارج الجهاز، ومزوّد بأجهزة آمنة توفّر حماية مماثلة أو أقوى من الحماية الموضّحة في خدمة Google Cloud Key Vault لمنع هجمات القوة العمياء على عامل المعرفة الخاص بشاشة القفل.

عمليات تنفيذ الجهاز:

[C-0-7] يجب الالتزام بخصائص إذن تحديد الموقع الجغرافي على Android عندما يطلب تطبيق بيانات الموقع الجغرافي أو بيانات نشاط المستخدم من خلال واجهة برمجة تطبيقات Android العادية أو آلية خاصة. تشمل هذه البيانات على سبيل المثال لا الحصر ما يلي:
- الموقع الجغرافي للجهاز (مثل خط العرض وخط الطول) كما هو موضح في الفقرة 9.8.8
- المعلومات التي يمكن استخدامها لتحديد موقع الجهاز أو تقديره (مثل معرّف SSID أو BSSID أو معرّف الخلية أو موقع الشبكة التي يتصل بها الجهاز)
- النشاط البدني للمستخدم أو تصنيف النشاط البدني

على وجه التحديد، يجب أن تتضمّن عمليات تنفيذ الأجهزة ما يلي:

[C-0-8] يجب الحصول على موافقة المستخدم للسماح لأحد التطبيقات بالوصول إلى بيانات الموقع الجغرافي أو بيانات نشاط المستخدم.
[C-0-9] يجب منح إذن التشغيل للتطبيق الذي لديه إذن كافٍ فقط، كما هو موضّح في حزمة تطوير البرامج (SDK). على سبيل المثال، تتطلّب الدالة TelephonyManager#getServiceState الإذن android.permission.ACCESS_FINE_LOCATION.

الاستثناءات الوحيدة لخصائص أذونات تحديد الموقع الجغرافي على Android المذكورة أعلاه هي التطبيقات التي لا تصل إلى بيانات الموقع الجغرافي لاستنتاج موقع المستخدم أو تحديده، وتحديدًا:

عندما تملك التطبيقات إذن RADIO_SCAN_WITHOUT_LOCATION
لأغراض إعداد الجهاز وضبطه، حيث تحتفظ تطبيقات النظام بإذن NETWORK_SETTINGS أو NETWORK_SETUP_WIZARD

يمكن وضع علامة "مقيّد" على الأذونات لتغيير سلوكها.

[C-0-10] يجب عدم منح التطبيق الأذونات التي تحمل العلامة hardRestricted إلا في الحالات التالية:
- ملف APK لأحد التطبيقات في قسم تطبيقات النظام
- يحدّد المستخدم دورًا مرتبطًا بأذونات hardRestricted لأحد التطبيقات.
- يمنح برنامج التثبيت hardRestricted لأحد التطبيقات.
- تم منح التطبيق الإذن hardRestricted على إصدار Android أقدم.
[C-0-11] يجب أن تحصل التطبيقات التي لديها إذن softRestricted على إذن وصول محدود فقط، ويجب ألّا تحصل على إذن وصول كامل إلا بعد إضافتها إلى القائمة المسموح بها كما هو موضّح في حزمة تطوير البرامج (SDK)، حيث يتم تحديد إذن الوصول الكامل والمحدود لكل إذن softRestricted (على سبيل المثال، READ_EXTERNAL_STORAGE).
[C-0-12] يجب عدم توفير أي دوال مخصّصة أو واجهات برمجة تطبيقات لتجاوز قيود الأذونات المحدّدة في واجهتَي برمجة التطبيقات setPermissionPolicy وsetPermissionGrantState.
[C-0-13] يجب استخدام واجهات برمجة التطبيقات AppOpsManager لتسجيل وتتبُّع كل عملية وصول آلي إلى البيانات المحمية بأذونات خطيرة من أنشطة وخدمات Android.
[C-0-14] يجب عدم منح الأدوار إلا للتطبيقات التي تتضمّن وظائف تستوفي متطلبات الدور.
[C-0-15] يجب عدم تحديد أدوار مكرّرة أو وظائف مجموعة فرعية من الأدوار التي يحدّدها النظام الأساسي.

إذا كانت الأجهزة تتضمّن أجهزة استشعار بيانات تعرض مقاييس حيوية متعلقة بالصحة، مثل معدّل نبضات القلب أو درجة حرارة الجلد، يجب استيفاء الشروط التالية:

[C-0-16] يجب أن تكون محمية بأذونات النظام الأساسي من android.permission-group.HEALTH، إذا كان هناك إذن مطابق في HealthPermissions.
[C-0-17] يجب أن يكون الوصول إلى نوع البيانات المطلوب محميًا بإذن نظام مخصّص في حال عدم توفّر إذن منصة يطابق نوع البيانات المطلوب. (مثلاً، ELECTROCARDIOGRAM.)

إذا كانت الأجهزة تعرض android.software.managed_users، يعني ذلك أنّها:

[C-1-1] يجب ألا يتم منح الأذونات التالية بدون علم المستخدم من قِبل المشرف:
- الموقع الجغرافي (ACCESS_BACKGROUND_LOCATION، ACCESS_COARSE_LOCATION، ACCESS_FINE_LOCATION)
- الكاميرا (CAMERA)
- الميكروفون (RECORD_AUDIO)
- جهاز استشعار الجسم (BODY_SENSORS)
- الصحة (HealthPermissions)
- النشاط البدني (ACTIVITY_RECOGNITION)

إذا كانت الأجهزة تعرض android.software.managed_users، يعني ذلك أنّها:

[C-1-1] يجب ألا يتم منح الأذونات التالية بدون علم المستخدم من قِبل المشرف:
- الموقع الجغرافي (ACCESS_BACKGROUND_LOCATION، ACCESS_COARSE_LOCATION، ACCESS_FINE_LOCATION)
- الكاميرا (CAMERA)
- الميكروفون (RECORD_AUDIO)
- جهاز استشعار الجسم (BODY_SENSORS)
- النشاط البدني (ACTIVITY_RECOGNITION)

إذا كانت عمليات تنفيذ الأجهزة توفّر للمستخدمين تلميحات مرئية لاختيار التطبيقات التي يمكنها الرسم فوق التطبيقات الأخرى باستخدام نشاط يعالج الغرض ACTION_MANAGE_OVERLAY_PERMISSION، يجب أن تستوفي ما يلي:

[C-2-1] يجب التأكّد من أنّ جميع الأنشطة التي تتضمّن فلاتر الأهداف الخاصة بالهدف ACTION_MANAGE_OVERLAY_PERMISSION تعرض شاشة واجهة المستخدم نفسها، بغض النظر عن التطبيق الذي بدأ النشاط أو أي معلومات يقدّمها.

إذا كان تقرير عمليات تنفيذ الأجهزة android.software.device_admin، يعني ذلك ما يلي:

[C-3-1] يجب عرض بيان إخلاء مسؤولية أثناء إعداد الجهاز المُدار بالكامل (إعداد مالك الجهاز) يوضّح أنّ مشرف تكنولوجيا المعلومات سيتمكّن من السماح للتطبيقات بالتحكّم في إعدادات الهاتف، بما في ذلك الميكروفون والكاميرا والموقع الجغرافي، مع توفير خيارات للمستخدم لمواصلة عملية الإعداد أو الخروج منها، ما لم يوقف المشرف إمكانية التحكّم في الأذونات على الجهاز.

إذا كانت عمليات تنفيذ الأجهزة تثبّت مسبقًا أي حِزم تتضمّن أيًا من أدوار واجهة مستخدِم النظام Intelligence أو System Ambient Audio Intelligence أو System Audio Intelligence أو System Notification Intelligence أو System Text Intelligence أو System Visual Intelligence، يجب أن تستوفي الحِزم ما يلي:

[C-4-1] يجب استيفاء جميع المتطلبات الموضّحة لعمليات تنفيذ الأجهزة في الفقرات 9.8.6. بيانات على مستوى نظام التشغيل والبيانات المحيطة و9.8.15 عمليات تنفيذ Sandboxed API

‫9.2. المعرّف الفريد وعزل العمليات

عمليات تنفيذ الجهاز:

[C-0-1] يجب أن تتوافق مع نموذج الحماية في نظام Android، حيث يتم تشغيل كل تطبيق Android بمعرّف UID فريد بنمط Unix وفي عملية منفصلة.
[C-0-2] يجب أن يتيح تشغيل تطبيقات متعددة باستخدام معرّف مستخدم Linux نفسه، بشرط أن تكون التطبيقات موقَّعة ومصمَّمة بشكل صحيح، كما هو موضّح في مرجع الأمان والأذونات.

‫9.3. أذونات نظام الملفات

عمليات تنفيذ الجهاز:

[C-0-1] يجب أن يتوافق الجهاز مع نموذج أذونات الوصول إلى الملفات في Android على النحو المحدّد في مرجع الأمان والأذونات.

‫9.4. بيئات التنفيذ البديلة

يجب أن تحافظ عمليات تنفيذ الأجهزة على اتساق نموذج الأمان والأذونات في Android، حتى إذا كانت تتضمّن بيئات وقت التشغيل التي تنفّذ التطبيقات باستخدام برامج أو تكنولوجيا أخرى غير تنسيق Dalvik Executable أو الرمز البرمجي الأصلي. وبعبارة أخرى:

[C-0-1] يجب أن تكون بيئات التشغيل البديلة نفسها تطبيقات Android، ويجب أن تلتزم بنموذج أمان Android العادي، كما هو موضّح في مكان آخر في القسم 9.
[C-0-2] يجب ألا يتم منح أوقات التشغيل البديلة إذن الوصول إلى الموارد المحمية بأذونات لم يتم طلبها في ملف AndroidManifest.xml لوقت التشغيل من خلال آلية <uses-permission>.
[C-0-3] يجب ألا تسمح بيئات التشغيل البديلة للتطبيقات باستخدام الميزات المحمية بأذونات Android المحصورة على تطبيقات النظام.
[C-0-4] يجب أن تلتزم بيئات التشغيل البديلة بنموذج وضع الحماية في Android، ويجب ألا تعيد التطبيقات المثبَّتة باستخدام بيئة تشغيل بديلة استخدام وضع الحماية لأي تطبيق آخر مثبَّت على الجهاز، إلا من خلال آليات Android العادية لمعرّف المستخدم المشترَك وشهادة التوقيع.
[C-0-5] يجب ألا يتم تشغيل أوقات التشغيل البديلة مع الوصول إلى البيئات المعزولة الخاصة بتطبيقات Android الأخرى أو منح هذا الوصول أو الحصول عليه.
[C-0-6] يجب ألا يتم تشغيل أوقات التشغيل البديلة مع أي امتيازات خاصة بالمستخدم المتميّز (الجذر) أو أي معرّف مستخدم آخر، كما يجب ألا يتم منح هذه الامتيازات أو الحصول عليها من تطبيقات أخرى.
[C-0-7] عند تضمين ملفات .apk لأوقات تشغيل بديلة في صورة نظام عمليات تنفيذ الأجهزة، يجب توقيعها باستخدام مفتاح يختلف عن المفتاح المستخدَم لتوقيع التطبيقات الأخرى المضمّنة في عمليات تنفيذ الأجهزة.
[C-0-8] عند تثبيت التطبيقات، يجب أن تحصل أوقات التشغيل البديلة على موافقة المستخدم على أذونات Android التي يستخدمها التطبيق.
[C-0-9] عندما يحتاج تطبيق إلى استخدام أحد موارد الجهاز التي يتوفّر لها إذن Android مطابق (مثل الكاميرا ونظام تحديد المواقع العالمي (GPS) وما إلى ذلك)، يجب أن يُعلم وقت التشغيل البديل المستخدم بأنّ التطبيق سيتمكّن من الوصول إلى هذا المورد.
[C-0-10] عندما لا يسجّل بيئة وقت التشغيل إمكانات التطبيق بهذه الطريقة، يجب أن تُدرِج بيئة وقت التشغيل جميع الأذونات التي تحتفظ بها عند تثبيت أي تطبيق يستخدم بيئة وقت التشغيل هذه.
يجب أن تثبّت أوقات التشغيل البديلة التطبيقات من خلال PackageManager في مساحات معزولة منفصلة لنظام Android (معرّفات مستخدمي Linux وما إلى ذلك).
قد توفّر أوقات التشغيل البديلة بيئة اختبار واحدة على Android تشترك فيها جميع التطبيقات التي تستخدم وقت التشغيل البديل.

‫9.5. إتاحة استخدام الجهاز من قِبل عدة مستخدمين

يتضمّن نظام التشغيل Android إمكانية استخدام عدة مستخدمين، كما يوفّر إمكانية عزل المستخدمين بشكل كامل واستنساخ ملفات شخصية للمستخدمين مع عزل جزئي (أي ملف شخصي إضافي واحد للمستخدم من النوع android.os.usertype.profile.CLONE).

يمكن أن تتيح عمليات تنفيذ الأجهزة ميزة تعدد المستخدمين، ولكن لا يُنصح بذلك إذا كانت تستخدم وسائط قابلة للإزالة كمساحة تخزين خارجية أساسية.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية استخدام عدة مستخدمين، يجب أن تستوفي ما يلي:

[C-1-2] يجب أن يتم تنفيذ نموذج أمان متوافق مع نموذج أمان نظام Android الأساسي المحدّد في مستند مرجع الأمان والأذونات في واجهات برمجة التطبيقات لكل مستخدم.
[C-1-3] يجب أن تتضمّن مساحة تخزين منفصلة ومعزولة للتطبيقات المشترَكة (المعروفة أيضًا باسم أدلة /sdcard) لكل مثيل من المستخدمين.
[C-1-4] يجب التأكّد من أنّ التطبيقات التي يملكها مستخدم معيّن ويتم تشغيلها نيابةً عنه لا يمكنها عرض الملفات التي يملكها أي مستخدم آخر أو قراءتها أو الكتابة فيها، حتى إذا تم تخزين بيانات كلا المستخدمَين على وحدة تخزين أو نظام ملفات واحد.
[C-1-5] يجب تشفير محتويات بطاقة SD عند تفعيل ميزة "استخدام عدة مستخدمين" باستخدام مفتاح مخزَّن فقط على وسائط غير قابلة للإزالة ولا يمكن الوصول إليها إلا من خلال النظام، وذلك في حال كانت عمليات تنفيذ الأجهزة تستخدم وسائط قابلة للإزالة لواجهات برمجة التطبيقات الخاصة بوحدة التخزين الخارجية. وبما أنّ ذلك سيجعل الوسائط غير قابلة للقراءة من خلال جهاز الكمبيوتر المضيف، يجب أن تتضمّن عمليات تنفيذ الأجهزة إمكانية التبديل إلى بروتوكول نقل الوسائط (MTP) أو نظام مشابه لتوفير إمكانية وصول أجهزة الكمبيوتر المضيفة إلى بيانات المستخدم الحالي.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية استخدام عدة مستخدمين، فإنّه بالنسبة إلى جميع المستخدمين باستثناء المستخدمين الذين تم إنشاؤهم خصيصًا لتشغيل مثيلات مزدوجة من التطبيق نفسه، يجب استيفاء ما يلي:

[C-2-1] يجب أن تتضمّن مساحات تخزين منفصلة ومعزولة للتطبيقات المشترَكة (المعروفة أيضًا باسم /sdcard) لكل مثيل مستخدم.
[C-2-2] يجب التأكّد من أنّ التطبيقات التي يملكها مستخدم معيّن ويتم تشغيلها نيابةً عنه لا يمكنها عرض الملفات التي يملكها أي مستخدم آخر أو قراءتها أو الكتابة فيها، حتى إذا تم تخزين بيانات كلا المستخدمَين على وحدة تخزين أو نظام ملفات واحد.

يمكن أن تنشئ عمليات تنفيذ الأجهزة ملفًا شخصيًا إضافيًا واحدًا للمستخدم من النوع android.os.usertype.profile.CLONE مقابل المستخدم الأساسي (وفقط مقابل المستخدم الأساسي) بغرض تشغيل مثيلَين متزامنين من التطبيق نفسه. وتتشارك هذه المثيلات المتزامنة مساحة تخزين معزولة جزئيًا، ويتم عرضها للمستخدم النهائي في مشغّل التطبيقات في الوقت نفسه، كما تظهر في طريقة العرض نفسها للتطبيقات الحديثة. على سبيل المثال، يمكن استخدام ذلك للسماح للمستخدم بتثبيت نسختَين منفصلتَين من تطبيق واحد على جهاز مزوّد بشريحتَي SIM.

في حال إنشاء عمليات تنفيذ الأجهزة لملف المستخدم الإضافي الموضّح أعلاه، يجب أن:

[C-3-1] يجب ألا يوفّر إمكانية الوصول إلا إلى مساحة التخزين أو البيانات التي يمكن الوصول إليها من ملف المستخدم الرئيسي أو التي يملكها ملف المستخدم الإضافي هذا مباشرةً.
[C-3-2] يجب ألا يكون هذا الملف هو ملف العمل.
[C-3-3] يجب أن تتضمّن أدلة بيانات التطبيقات الخاصة المعزولة من حساب المستخدم الرئيسي.
[C-3-4] يجب عدم السماح بإنشاء ملف مستخدم إضافي إذا تم توفير "مالك الجهاز" (راجِع القسم 3.9.1) أو السماح بتوفير "مالك الجهاز" بدون إزالة ملف المستخدم الإضافي أولاً.

في حال إنشاء عمليات تنفيذ الأجهزة لملف المستخدم الإضافي الموضّح أعلاه، يجب أن:

[C-4-1] يجب السماح للتطبيقات الخاصة بالمستخدم الأساسي على الجهاز بمعالجة النوايا التالية الواردة من الملف الإضافي:
- Intent.ACTION_VIEW
- Intent.ACTION_SENDTO
- Intent.ACTION_SEND
- Intent.ACTION_EDIT
- Intent.ACTION_INSERT
- Intent.ACTION_INSERT_OR_EDIT
- Intent.ACTION_SEND_MULTIPLE
- Intent.ACTION_PICK
- Intent.ACTION_GET_CONTENT
- MediaStore.ACTION_IMAGE_CAPTURE
- MediaStore.ACTION_VIDEO_CAPTURE
[C-4-2] يجب أن يرث جميع قيود المستخدمين في سياسة الجهاز وrestrictions(list below) المحدّدة غير الخاصة بالمستخدمين والمطبّقة على المستخدم الأساسي للجهاز في ملف المستخدم الإضافي هذا.
[C-4-3] يجب السماح فقط بكتابة جهات الاتصال من هذا الملف الشخصي الإضافي من خلال الأهداف التالية:
[C-4-4] يجب ألا يتم تشغيل عمليات مزامنة جهات الاتصال للتطبيقات التي تعمل في ملف المستخدم الإضافي هذا.
[C-4-5] يجب ألا تسمح إلا للتطبيقات في الملف الإضافي التي تتضمّن نشاطًا خاصًا بمشغّل التطبيقات بالوصول إلى جهات الاتصال التي يمكن لملف المستخدم الرئيسي الوصول إليها.

إذا كانت عمليات تنفيذ الأجهزة تنشئ ملف المستخدم الإضافي المذكور أعلاه، وتتضمّن كاميرا واحدة على الأقل، وكان تطبيق الكاميرا المثبَّت مسبقًا يتعامل مع الأهداف MediaStore.ACTION_MOTION_PHOTO_CAPTURE أو MediaStore.ACTION_MOTION_PHOTO_CAPTURE_SECURE، يجب أن تستوفي ما يلي:

[C-5-1] يجب السماح لتطبيقات المستخدم الأساسي بمعالجة هذه الأهداف الناشئة من ملف المستخدم الإضافي هذا.

‫9.6. تحذير بشأن الرسائل القصيرة برسوم إضافية

يتيح نظام التشغيل Android تحذير المستخدمين من أي رسالة قصيرة برسوم إضافية صادرة. الرسائل القصيرة برسوم إضافية هي رسائل نصية يتم إرسالها إلى خدمة مسجَّلة لدى مشغّل شبكة جوّال، وقد يتم تحصيل رسوم من المستخدم مقابلها.

إذا كانت عمليات تنفيذ الأجهزة تعلن عن توفّر android.hardware.telephony، عليها استيفاء ما يلي:

[C-1-1] يجب تحذير المستخدمين قبل إرسال رسالة SMS إلى أرقام محدّدة بتعبيرات عادية معرَّفة في ملف /data/misc/sms/codes.xml على الجهاز. يوفّر "المشروع المفتوح المصدر لنظام Android" (AOSP) إصدارًا يستوفي هذا الشرط.

‫9.7. ميزات الأمان

يجب أن تضمن عمليات تنفيذ الأجهزة التوافق مع ميزات الأمان في كل من النواة والنظام الأساسي كما هو موضّح أدناه.

يتضمّن وضع الحماية في Android ميزات تستخدم نظام التحكّم الإلزامي في الوصول (MAC) المستند إلى Security-Enhanced Linux (SELinux)، ووضع الحماية seccomp، وميزات أمان أخرى في نواة Linux. عمليات تنفيذ الجهاز:

[C-0-1] يجب الحفاظ على التوافق مع التطبيقات الحالية، حتى عند تنفيذ SELinux أو أي ميزات أمان أخرى أسفل إطار عمل Android.
[C-0-2] يجب ألا تتضمّن واجهة مستخدم مرئية عند رصد انتهاك أمني وحظره بنجاح من خلال ميزة الأمان التي تم تنفيذها أسفل إطار عمل Android، ولكن يجوز أن تتضمّن واجهة مستخدم مرئية عند حدوث انتهاك أمني لم يتم حظره وأدّى إلى استغلال ناجح.
[C-0-3] يجب ألا يتم السماح للمستخدم أو مطوّر التطبيق بضبط SELinux أو أي ميزات أمان أخرى تم تنفيذها أسفل إطار عمل Android.
[C-0-4] يجب ألا تسمح بتطبيق يمكنه التأثير في تطبيق آخر من خلال واجهة برمجة تطبيقات (مثل واجهة برمجة تطبيقات إدارة الأجهزة) لضبط سياسة تؤدي إلى عدم التوافق.
[C-0-5] يجب تقسيم إطار عمل الوسائط إلى عمليات متعددة حتى يمكن منح إذن الوصول لكل عملية بشكل أكثر تحديدًا على النحو الموضّح في موقع "مشروع Android المفتوح المصدر".
‫[C-0-6] يجب تنفيذ آلية حماية التطبيقات في النواة تسمح بفلترة طلبات النظام باستخدام سياسة قابلة للإعداد من البرامج المتعددة مؤشرات الترابط. يستوفي مشروع Android المفتوح المصدر هذا الشرط من خلال تفعيل seccomp-BPF مع مزامنة مجموعة سلاسل العمليات (TSYNC) على النحو الموضّح في قسم "إعدادات النواة" من source.android.com.

تُعد ميزات سلامة النواة والحماية الذاتية جزءًا لا يتجزأ من أمان Android. عمليات تنفيذ الجهاز:

‫[C-0-7] يجب تنفيذ آليات الحماية من تجاوز المخزن المؤقت للحزمة في النواة. ومن الأمثلة على هذه الآليات CC_STACKPROTECTOR_REGULAR وCONFIG_CC_STACKPROTECTOR_STRONG.
[C-0-8] يجب تنفيذ إجراءات حماية صارمة لذاكرة النواة، بحيث يكون الرمز القابل للتنفيذ للقراءة فقط، والبيانات للقراءة فقط غير قابلة للتنفيذ وغير قابلة للكتابة، والبيانات القابلة للكتابة غير قابلة للتنفيذ (على سبيل المثال، يجب تفعيل كل من rodata وCONFIG_STRICT_KERNEL_RWX).
[C-0-9] يجب تنفيذ عملية التحقّق من الحدود الثابتة والديناميكية لحجم العناصر التي يتم نسخها بين مساحة المستخدم ومساحة النواة (مثل CONFIG_HARDENED_USERCOPY) على الأجهزة التي تم شحنها في الأصل مع مستوى واجهة برمجة التطبيقات 28 أو إصدار أحدث.
[C-0-10] يجب عدم تنفيذ ذاكرة مساحة المستخدم عند التنفيذ في وضع النواة (على سبيل المثال، PXN للأجهزة أو المحاكي من خلال CONFIG_CPU_SW_DOMAIN_PAN أو CONFIG_ARM64_SW_TTBR0_PAN) على الأجهزة التي تم شحنها في الأصل بمستوى واجهة برمجة التطبيقات 28 أو أعلى.
[C-0-11] يجب عدم قراءة أو كتابة بيانات في مساحة ذاكرة المستخدم في النواة خارج واجهات برمجة التطبيقات العادية للوصول إلى usercopy (مثل PAN للأجهزة أو المحاكي عبر CONFIG_CPU_SW_DOMAIN_PAN أو CONFIG_ARM64_SW_TTBR0_PAN) على الأجهزة التي تم شحنها في الأصل بمستوى واجهة برمجة التطبيقات 28 أو أعلى.
[C-0-12] يجب تنفيذ ميزة "عزل جداول صفحات النواة" إذا كان الجهاز عرضة للثغرة الأمنية CVE-2017-5754 على جميع الأجهزة التي تم شحنها في الأصل بمستوى واجهة برمجة التطبيقات 28 أو مستوى أحدث (مثل CONFIG_PAGE_TABLE_ISOLATION أو CONFIG_UNMAP_KERNEL_AT_EL0).
[C-0-13] يجب تنفيذ إجراءات تقوية التنبؤ بالتفرّع إذا كان الجهاز عرضة للثغرة الأمنية CVE-2017-5715 على جميع الأجهزة التي تم شحنها في الأصل مع مستوى واجهة برمجة التطبيقات 28 أو أعلى (مثل CONFIG_HARDEN_BRANCH_PREDICTOR).
[C-SR-1] يُنصح بشدة بإبقاء بيانات النواة التي تتم كتابتها فقط أثناء عملية الإعداد، مع وضع علامة القراءة فقط عليها بعد عملية الإعداد (مثلاً، __ro_after_init).
[C-SR-2] يُنصح بشدة بتوزيع تخطيط رمز النواة والذاكرة بشكل عشوائي، وتجنُّب أي عمليات إفصاح قد تؤدي إلى اختراق التوزيع العشوائي (مثل CONFIG_RANDOMIZE_BASE مع إنتروبيا برنامج التحميل عبر /chosen/kaslr-seed Device Tree node أو EFI_RNG_PROTOCOL).
[C-SR-3] يُنصح بشدة بتفعيل ميزة "سلامة تدفق التحكّم" (CFI) في النواة لتوفير حماية إضافية ضد هجمات إعادة استخدام الرموز (مثل CONFIG_CFI_CLANG وCONFIG_SHADOW_CALL_STACK).
[C-SR-4] يُنصح بشدة بعدم إيقاف ميزة "سلامة تدفق التحكّم" (CFI) أو "مكدس استدعاء الظل" (SCS) أو "تنظيف تجاوز سعة الأعداد الصحيحة" (IntSan) في المكوّنات التي تم تفعيلها فيها.
[C-SR-5] يُنصح بشدة بتفعيل ميزات CFI وSCS وIntSan لأي مكونات إضافية في مساحة المستخدم تتطلّب مستوى أمان عاليًا، كما هو موضّح في CFI وIntSan.
[C-SR-6] يُنصح بشدة بتفعيل إعدادات بدء تشغيل الحزمة في النواة لمنع استخدام المتغيرات المحلية غير المهيأة (CONFIG_INIT_STACK_ALL أو CONFIG_INIT_STACK_ALL_ZERO). بالإضافة إلى ذلك، يجب ألا تفترض عمليات تنفيذ الأجهزة القيمة التي يستخدمها المترجم البرمجي لتهيئة المتغيرات المحلية.
[C-SR-7] يُنصح بشدة بتفعيل عملية إعداد الذاكرة المؤقتة في النواة لمنع استخدام عمليات تخصيص الذاكرة المؤقتة غير المعدّة (CONFIG_INIT_ON_ALLOC_DEFAULT_ON)، ويجب عدم افتراض القيمة التي تستخدمها النواة لإعداد عمليات التخصيص هذه.

إذا كانت عمليات تنفيذ الأجهزة تستخدم نواة Linux يمكنها توفير توافق مع SELinux، فإنّها:

[C-1-1] يجب تنفيذ SELinux.
[C-1-2] يجب ضبط SELinux على وضع التنفيذ العام.
[C-1-3] يجب ضبط جميع النطاقات في وضع التنفيذ. لا يُسمح بأي نطاقات في الوضع المتساهل، بما في ذلك النطاقات الخاصة بجهاز أو مورّد معيّن.

[C-1-4] يجب عدم:
- تعديل أو حذف أو استبدال قواعد neverallow المتوفّرة في مجلد system/sepolicy المقدَّم في مشروع Android المفتوح المصدر (AOSP)
- إضافة تصنيفات AOSP SELinux بشكل غير صحيح إلى مكونات غير AOSP
يجب أن تتوافق السياسة مع جميع قواعد neverallow المتوفّرة، وذلك لكل من نطاقات SELinux في AOSP والنطاقات الخاصة بالجهاز أو المورّد.

[C-1-5] يجب تشغيل التطبيقات التابعة لجهات خارجية التي تستهدف مستوى واجهة برمجة التطبيقات 28 أو أعلى في بيئات وضع الحماية SELinux لكل تطبيق مع فرض قيود SELinux على كل تطبيق في دليل البيانات الخاصة بكل تطبيق.
يجب الاحتفاظ بسياسة SELinux التلقائية المتوفّرة في المجلد system/sepolicy الخاص بمشروع مفتوح المصدر لنظام Android وإضافة المزيد إلى هذه السياسة فقط من أجل الإعداد الخاص بالجهاز.

في حال استخدام عمليات تنفيذ الأجهزة لنواة أخرى غير Linux أو Linux بدون SELinux، يجب استيفاء ما يلي:

[C-2-1] يجب استخدام نظام تحكّم إلزامي في الوصول يكون مكافئًا لنظام SELinux.

إذا كانت عمليات تنفيذ الأجهزة تستخدم أجهزة إدخال/إخراج يمكنها الوصول المباشر إلى الذاكرة، عليها استيفاء ما يلي:

[C-SR-9] يُنصح بشدة بعزل كل جهاز إدخال/إخراج قادر على الوصول المباشر إلى الذاكرة (DMA)، باستخدام وحدة إدارة الإدخال/الإخراج (IOMMU) (مثل ARM SMMU).

يتضمّن Android ميزات متعددة للدفاع العميق تشكّل جزءًا لا يتجزأ من أمان الجهاز. بالإضافة إلى ذلك، يركّز Android على الحدّ من الفئات الرئيسية للأخطاء الشائعة التي تؤدي إلى انخفاض الجودة والأمان.

للحدّ من أخطاء الذاكرة، يجب أن تتضمّن عمليات تنفيذ الأجهزة ما يلي:

[C-SR-10] يُنصح بشدة باختبارها باستخدام أدوات رصد أخطاء الذاكرة في مساحة المستخدم، مثل MTE لأجهزة ARMv9 أو HWASan لأجهزة ARMv8+ أو ASan لأنواع الأجهزة الأخرى.
[C-SR-11] يُنصح بشدة باختبارها باستخدام أدوات رصد أخطاء ذاكرة النواة، مثل KASAN (CONFIG_KASAN وCONFIG_KASAN_HW_TAGS لأجهزة ARMv9 وCONFIG_KASAN_SW_TAGS لأجهزة ARMv8 أو CONFIG_KASAN_GENERIC لأنواع الأجهزة الأخرى).
[C-SR-12] يُنصح بشدة باستخدام أدوات رصد أخطاء الذاكرة في مرحلة الإنتاج، مثل MTE وGWP-ASan وKFENCE.

في حال استخدام عمليات تنفيذ الأجهزة لبيئة تنفيذ موثوقة (TEE) تستند إلى Arm TrustZone، يجب أن تستوفي ما يلي:

[C-SR-13] يُنصح بشدة باستخدام بروتوكول عادي لمشاركة الذاكرة بين Android وبيئة التنفيذ الموثوقة (TEE)، مثل Arm Firmware Framework for Armv8-A (FF-A).
[C-SR-14] يُنصح بشدة بتقييد التطبيقات الموثوق بها بحيث لا يمكنها الوصول إلا إلى الذاكرة التي تمت مشاركتها معها بشكل صريح من خلال البروتوكول المذكور أعلاه. إذا كان الجهاز يتيح استخدام مستوى الاستثناء Arm S-EL2، يجب أن يفرض مدير الأقسام الآمنة هذا المستوى. وفي ما عدا ذلك، يجب أن يفرض نظام التشغيل TEE هذا الإجراء.

تكنولوجيا أمان الذاكرة هي تكنولوجيا تقلّل من احتمالية حدوث فئات الأخطاء التالية بنسبة عالية (> 90%) في التطبيقات التي تستخدم خيار android:memtagMode في ملف البيان:

فائض سعة المخزن المؤقت في الذاكرة الرئيسية
استخدام بعد انتهاء الفترة المجانية
تحرير مزدوج
wild free (free of a non-malloc pointer)

عمليات تنفيذ الجهاز:

[C-SR-15] يُنصح بشدة بضبط ro.arm64.memtag.bootctl_supported.

إذا ضبطت عمليات تنفيذ الأجهزة سمة النظام ro.arm64.memtag.bootctl_supported على "صحيح"، عليها استيفاء ما يلي:

[C-3-1] يجب أن تسمح السمة arm64.memtag.bootctl بقبول قائمة قيم مفصولة بفاصلة للقيم التالية، مع تطبيق التأثير المطلوب عند إعادة التشغيل التالية:
- ‫memtag: تم تفعيل تكنولوجيا "أمان الذاكرة" على النحو المحدّد أعلاه
- ‫memtag-once: تم تفعيل إحدى تقنيات "أمان الذاكرة" المحدّدة أعلاه بشكل مؤقت، ويتم إيقافها تلقائيًا عند إعادة التشغيل التالية
- ‫memtag-off: تم إيقاف تكنولوجيا "أمان الذاكرة" على النحو المحدّد أعلاه
[C-3-2] يجب أن يسمح مستخدم shell بتعيين arm64.memtag.bootctl.
‫[C-3-3] يجب السماح لأي عملية بقراءة arm64.memtag.bootctl.
[C-3-4] يجب ضبط arm64.memtag.bootctl على الحالة المطلوبة حاليًا عند بدء التشغيل، ويجب أيضًا تعديل السمة إذا كان تنفيذ الجهاز يسمح بتعديل الحالة بدون تغيير سمة النظام.
[C-SR-16] يُنصح بشدة بعرض إعدادات المطوّرين التي تضبط memtag-once وتعيد تشغيل الجهاز. باستخدام برنامج إقلاع متوافق، يستوفي مشروع مفتوح المصدر لنظام Android المتطلبات المذكورة أعلاه من خلال بروتوكول برنامج إقلاع MTE.

إذا كان الجهاز يعرّف android.hardware.telephony، ويتوافق مع إمكانية الراديو CAPABILITY_USES_ALLOWED_NETWORK_TYPES_BITMASK، ويتضمّن مودمًا خلويًا متوافقًا مع اتصالات الجيل الثاني، يجب أن يتضمّن تنفيذ الجهاز ما يلي:

[C-SR-17] يُنصح بشدة بتوفير إمكانية للمستخدمين لإيقاف شبكة الجيل الثاني وتفعيلها.
[C-SR-18] يُنصح بشدة بعدم تجاهل إمكانية إيقاف شبكة الجيل الثاني وتفعيلها من خلال أي كيان جهاز آخر باستثناء مشرف الجهاز باستخدام UserManager.DISALLOW_CELLULAR_2G.
[C-SR-19] يُنصح بشدة بإجراء مكالمة إلى TelephonyManager.setAllowedNetworkTypesForReason مع ذكر السبب ALLOWED_NETWORK_TYPES_REASON_ENABLE_2G لتحقيق هذا المطلب.
[C-SR-20] يُنصح بشدة بتحديد ما إذا كان مودم شبكة الجوّال يتيح استخدام شبكة الجيل الثاني من خلال الاتصال بالرقم TelephonyManager.getSupportedRadioAccessFamily. لمزيد من التفاصيل، يُرجى الاطّلاع على مقالة إيقاف شبكة الجيل الثاني (2G).

‫9.8. الخصوصية

‫9.8.1. سجلّ الاستخدام

يخزِّن نظام التشغيل Android سجلّ خيارات المستخدم ويديره من خلال UsageStatsManager.

عمليات تنفيذ الجهاز:

[C-0-1] يجب الحفاظ على فترة تخزين معقولة لسجلّ المستخدم هذا.
[C-SR-1] يُنصح بشدة بالاحتفاظ بفترة التخزين لمدة 14 يومًا كما هو محدّد تلقائيًا في تطبيق مشروع Android المفتوح المصدر (AOSP).

يخزِّن نظام التشغيل Android أحداث النظام باستخدام StatsLog المعرّفات، ويدير هذا السجلّ من خلال StatsManager وواجهة برمجة التطبيقات IncidentManager للنظام.

عمليات تنفيذ الجهاز:

[C-0-2] يجب أن يتضمّن فقط الحقول التي تم وضع علامة DEST_AUTOMATIC عليها في بلاغ عن حادثة الذي تم إنشاؤه بواسطة فئة واجهة برمجة التطبيقات للنظام IncidentManager.
[C-0-3] يجب عدم استخدام معرّفات أحداث النظام لتسجيل أي حدث آخر غير ما هو موضح في مستندات StatsLog حزمة تطوير البرامج (SDK). إذا تم تسجيل أحداث نظام إضافية، يجوز لها استخدام معرّف عنصر مختلف في النطاق بين 100,000 و200,000.

‫9.8.2. جارٍ التسجيل

عمليات تنفيذ الجهاز:

[C-0-1] يجب عدم تحميل مكوّنات البرامج مسبقًا أو توزيعها خارج الصندوق إذا كانت ترسل المعلومات الخاصة بالمستخدم (مثل ضغطات المفاتيح أو النص المعروض على الشاشة أو تقرير الأخطاء) إلى خارج الجهاز بدون موافقة المستخدم أو إشعارات مستمرة وواضحة.
[C-0-2] يجب عرض تحذير للمستخدم والحصول على موافقته الصريحة للسماح بتسجيل أي معلومات حساسة معروضة على شاشة المستخدم في كل مرة يتم فيها تفعيل جلسة لتسجيل الشاشة أو بثها من خلال MediaProjection.createVirtualDisplay() أو واجهات برمجة التطبيقات الخاصة.
[C-0-3] يجب عرض إشعار بنشاط مستمر في الخلفية للمستخدم أثناء تفعيل ميزة مشاركة الشاشة أو تسجيلها. يستوفي AOSP هذا الشرط من خلال عرض رمز إشعار بنشاط مستمر في الخلفية في شريط الحالة.
[C-SR-1] يُنصح بشدة بعرض تحذير للمستخدم يتضمّن الرسالة نفسها تمامًا التي تم تنفيذها في مشروع Android المفتوح المصدر (AOSP)، ولكن يمكن تغييرها طالما أنّ الرسالة تحذّر المستخدم بوضوح من أنّه يتم تسجيل أي معلومات حساسة تظهر على شاشة المستخدم.
[C-0-4] تمت إزالة هذا الشرط في Android 16.

عمليات تنفيذ الجهاز:

[C-0-7] يجب عدم تسجيل معلومات حساسة أو عرضها أو بثّها، مثل:
- محتوى الإشعارات الحسّاسة المدرَج في الفقرة 3.8.3.4 "حماية الإشعارات الحسّاسة"
- نوافذ نشاط التطبيق التي تحتوي على كلمات مرور صالحة لمرة واحدة
- المحتوى الحسّاس، مثل اسم المستخدم وكلمة المرور ومعلومات بطاقة الائتمان

إذا كانت عمليات تنفيذ الأجهزة تتضمّن وظائف في النظام تعمل على تسجيل المحتوى المعروض على الشاشة و/أو تسجيل بث الصوت المشغّل على الجهاز بطريقة أخرى غير System API ContentCaptureService، أو وسائل أخرى خاصة موضّحة في القسم 9.8.6 بيانات على مستوى نظام التشغيل والبيانات المحيطة، يجب أن تستوفي ما يلي:

[C-1-1] يجب عرض إشعار بنشاط مستمر في الخلفية للمستخدم عند تفعيل هذه الوظيفة وعندما تكون عملية التسجيل أو الالتقاط نشطة.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن مكونًا مفعَّلاً فور إخراجه من العلبة، وقادرًا على تسجيل الصوت المحيط و/أو تسجيل الصوت الذي يتم تشغيله على الجهاز لاستنتاج معلومات مفيدة حول سياق المستخدم، يجب أن تستوفي ما يلي:

[C-2-1] يجب عدم تخزين الصوت الخام المسجَّل أو أي تنسيق يمكن تحويله مرة أخرى إلى الصوت الأصلي أو نسخة طبق الأصل تقريبًا في وحدة تخزين دائمة على الجهاز فقط أو إرساله خارج الجهاز، إلا بموافقة المستخدم الصريحة.

يشير "مؤشر الميكروفون" إلى طريقة عرض على الشاشة تكون مرئية باستمرار للمستخدم ولا يمكن حجبها، ويفهم المستخدمون من خلالها أنّ الميكروفون قيد الاستخدام(من خلال نص أو لون أو رمز فريد أو مجموعة من هذه العناصر).

يشير "مؤشر استخدام الكاميرا" إلى طريقة عرض على الشاشة تكون مرئية للمستخدم باستمرار ولا يمكن حجبها، ويفهم المستخدمون أنّ الكاميرا قيد الاستخدام (من خلال نص أو لون أو رمز فريد أو مزيج من هذه العناصر).

بعد عرض المؤشر لمدة ثانية واحدة، يمكن أن يتغير مظهره، مثلاً، يصبح أصغر حجمًا، وليس من الضروري أن يظهر كما تم عرضه وفهمه في الأصل.

يمكن دمج مؤشر الميكروفون مع مؤشر الكاميرا المعروض بشكل نشط، بشرط أن تشير النصوص أو الرموز أو الألوان إلى المستخدم بأنّه قد بدأ استخدام الميكروفون.

قد يتم دمج مؤشر استخدام الكاميرا مع مؤشر الميكروفون المعروض بشكل نشط، بشرط أن تشير النصوص أو الرموز أو الألوان إلى المستخدم بأنّه قد بدأ استخدام الكاميرا.

إذا كانت عمليات تنفيذ الأجهزة تعرّف android.hardware.microphone، عليها استيفاء ما يلي:

[C-SR-1] يُنصح بشدة بعرض مؤشر الميكروفون عندما يصل تطبيق إلى بيانات الصوت من الميكروفون، ولكن ليس عندما يصل إلى الميكروفون فقط HotwordDetectionService أو SOURCE_HOTWORD أو ContentCaptureService أو التطبيقات التي لديها الأدوار المحدّدة في القسم 9.1 "الأذونات" مع معرّف توافق تعريف الجهاز [C-3-X].
[C-SR-2] يُنصح بشدة بعرض قائمة التطبيقات الحديثة والنشطة التي تستخدم الميكروفون، وذلك وفقًا لما يتم عرضه من PermissionManager.getIndicatorAppOpUsageData()، بالإضافة إلى أي رسائل تحديد مصدر مرتبطة بها.
[C-SR-3] يُنصح بشدة بعدم إخفاء مؤشر الميكروفون للتطبيقات التابعة للنظام التي تتضمّن واجهات مستخدم مرئية أو تتطلّب تفاعلاً مباشرًا من المستخدم.

إذا كانت عمليات تنفيذ الأجهزة تعرّف android.hardware.camera.any، عليها استيفاء ما يلي:

[C-SR-4] يُنصح بشدة بعرض مؤشر استخدام الكاميرا عندما يصل تطبيق إلى بيانات الكاميرا المباشرة، ولكن ليس عندما تصل التطبيقات التي تحمل الأدوار المحددة في القسم 9.1 "الأذونات" مع معرّف CDD [C-3-X] إلى الكاميرا فقط.
[C-SR-5] يُنصح بشدة بعرض التطبيقات الحديثة والنشطة التي تستخدم الكاميرا كما هو معروض من PermissionManager.getIndicatorAppOpUsageData()، بالإضافة إلى أي رسائل تحديد مصدر مرتبطة بها.
[C-SR-6] يُنصح بشدة بعدم إخفاء مؤشر استخدام الكاميرا لتطبيقات النظام التي تتضمّن واجهات مستخدم مرئية أو تفاعل المستخدم المباشر.

‫9.8.3. إمكانية الاتصال

إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB يتيح وضع الجهاز الطرفي USB، يجب أن تستوفي ما يلي:

[C-1-1] يجب عرض واجهة مستخدم تطلب موافقة المستخدم قبل السماح بالوصول إلى محتوى وحدة التخزين المشتركة عبر منفذ USB.

‫9.8.4. حركة بيانات الشبكة

عمليات تنفيذ الجهاز:

[C-0-1] يجب أن يتم تثبيت مسبقًا لشهادات الجذر نفسها الخاصة بمخزن مراجع التصديق (CA) الموثوق بها من النظام، وذلك على النحو المحدّد في مشروع Android مفتوح المصدر.
[C-0-2] يجب أن يتم شحن الجهاز مع متجر فارغ لشهادات المراجع المصدقة الجذرية للمستخدمين.
[C-0-3] يجب عرض تحذير للمستخدم يشير إلى أنّه قد تتم مراقبة حركة بيانات الشبكة، وذلك عند إضافة شهادة مرجع تصديق جذر للمستخدم.

إذا تم توجيه حركة بيانات الجهاز من خلال شبكة VPN، ستكون عمليات تنفيذ الجهاز على النحو التالي:

[C-1-1] يجب عرض تحذير للمستخدم يشير إلى أحد الخيارَين التاليَين:
- قد يتم رصد حركة بيانات الشبكة هذه.
- يتم توجيه حركة بيانات الشبكة هذه من خلال تطبيق VPN المحدّد الذي يوفّر شبكة VPN.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن آلية مفعَّلة تلقائيًا عند إخراج الجهاز من العلبة، وتعمل على توجيه زيارات بيانات الشبكة عبر خادم وكيل أو بوابة شبكة VPN (على سبيل المثال، التحميل المُسبَق لخدمة VPN مع منح الإذن android.permission.CONTROL_VPN)، يجب أن تستوفي ما يلي:

[C-2-1] يجب طلب موافقة المستخدم قبل تفعيل هذه الآلية، إلا إذا تم تفعيل شبكة VPN من خلال "وحدة التحكُّم بسياسة الجهاز" باستخدام DevicePolicyManager.setAlwaysOnVpnPackage()، وفي هذه الحالة، لا يحتاج المستخدم إلى تقديم موافقة منفصلة، ولكن يجب إعلامه فقط.

إذا كانت عمليات تنفيذ الأجهزة توفّر للمستخدمين إمكانية تفعيل وظيفة "شبكة VPN قيد التشغيل دائمًا" في تطبيق شبكة VPN تابع لجهة خارجية، يجب أن تستوفي ما يلي:

[C-3-1] يجب إيقاف إمكانية استخدام هذه الميزة للتطبيقات التي لا تتوافق مع خدمة الشبكة الافتراضية الخاصة (VPN) التي تعمل دائمًا في ملف AndroidManifest.xml من خلال ضبط السمة SERVICE_META_DATA_SUPPORTS_ALWAYS_ON على false.

‫9.8.5. معرّفات الأجهزة

عمليات تنفيذ الجهاز:

[C-0-1] يجب منع التطبيقات من الوصول إلى الرقم التسلسلي للجهاز، ورقم IMEI/MEID، والرقم التسلسلي لشريحة SIM، ومعرّف المشترك الدولي في خدمات الجوّال (IMSI)، حيثما ينطبق ذلك، ما لم يستوفِ أحد المتطلبات التالية:
- هو تطبيق مشغّل شبكة جوّال موقَّع تم التحقّق منه من قِبل الشركات المصنّعة للأجهزة.
- تم منح تطبيق "READ_PRIVILEGED_PHONE_STATE" إذن الوصول إلى
- يتمتّع بامتيازات مشغّل شبكة الجوّال على النحو المحدّد في امتيازات مشغّل شبكة الجوّال في بطاقة UICC.
- أن يكون مالك جهاز أو مالك ملف شخصي تم منحه إذن READ_PHONE_STATE.
- (لرقم تسلسلي لبطاقة SIM/رقم ICCID فقط) يجب أن يلتزم التطبيق باللوائح التنظيمية المحلية التي تتطلّب منه رصد التغييرات في هوية المشترك.

‫9.8.6. أداة الحماية على مستوى نظام التشغيل والبيانات المحيطة

يتيح نظام التشغيل Android، من خلال واجهات برمجة التطبيقات الخاصة بالنظام، آلية تتيح عمليات تنفيذ الأجهزة تسجيل البيانات الحساسة التالية:

النصوص والرسومات المعروضة على الشاشة، بما في ذلك على سبيل المثال لا الحصر، الإشعارات وبيانات المساعدة من خلال AssistStructure APIوأنشطة التقاط مخزن الشاشة المؤقت وتسجيل محتوى شاشة الجهاز.

بيانات الوسائط، مثل الصوت أو الفيديو، التي يسجّلها الجهاز أو يشغّلها
أحداث الإدخال (مثل المفتاح والماوس والإيماءة والصوت والفيديو وإمكانية الوصول)
أي شاشة أو بيانات أخرى يتم إرسالها عبر AugmentedAutofillService إلى النظام
أي شاشة أو بيانات أخرى يمكن الوصول إليها من خلال Content Capture واجهات برمجة التطبيقات
أي بيانات تطبيقات يتم تمريرها إلى النظام من خلال واجهة برمجة التطبيقات AppSearchManager ويمكن الوصول إليها من خلال AppSearchGlobalManager.query
أي نص أو بيانات أخرى يتم إرسالها عبر TextClassifier API إلى خدمة System TextClassifier، أي إلى خدمة النظام لفهم معنى النص، بالإضافة إلى إنشاء الإجراءات التالية المتوقّعة استنادًا إلى النص.
البيانات التي تم فهرستها من خلال تنفيذ AppSearch على النظام الأساسي، بما في ذلك على سبيل المثال لا الحصر، النصوص أو الرسومات أو بيانات الوسائط أو البيانات المشابهة الأخرى
البيانات الصوتية التي يتم الحصول عليها نتيجة استخدام SpeechRecognizer#onDeviceSpeechRecognizer() من خلال تنفيذ أداة التعرّف على الكلام
بيانات الصوت التي يتم الحصول عليها في الخلفية (بشكل مستمر) من خلال AudioRecord أو SoundTrigger أو واجهات برمجة تطبيقات أخرى خاصة بالصوت، والتي لا تؤدي إلى ظهور مؤشر مرئي للمستخدم
بيانات الكاميرا التي يتم الحصول عليها في الخلفية (بشكل مستمر) من خلال CameraManager أو واجهات برمجة تطبيقات أخرى خاصة بالكاميرا، ولا تؤدي إلى ظهور مؤشر مرئي للمستخدم

أي بيانات يتم جمعها بواسطة DynamicInstrumentationEventService

إذا كانت عمليات تنفيذ الأجهزة تجمع أو تشارك أيًا من البيانات الحسّاسة المذكورة أعلاه، عليها: بدون إشارة واضحة ومستقلة إلى نية المستخدم أو مؤشر خصوصية مرئي للمستخدم، يجب معالجة البيانات في بيئة تنفيذ محمية. هذه البيئة:

[C-1-1] يجب تشفير جميع هذه البيانات عند تخزينها في الجهاز أو أثناء نقلها. يمكن إجراء هذا التشفير باستخدام ميزة "التشفير المستند إلى الملفات" في Android أو أي من برامج التشفير المدرَجة على أنّها الإصدار 26 من واجهة برمجة التطبيقات أو الإصدارات الأحدث، كما هو موضّح في Cipher SDK.
[C-1-2] يجب عدم الاحتفاظ بنسخة احتياطية من البيانات الأولية أو المشفرة باستخدام الاحتفاظ بنسخة احتياطية من البيانات في جهاز Android أو أي طرق أخرى للاحتفاظ بنسخة احتياطية للبيانات الحسّاسة، كما هو موضّح أعلاه.

[C-1-3] يجب عدم إرسال هذه البيانات خارج الجهاز إلا في إحدى الحالات التالية:
- عندما يبدأ المستخدم بشكل صريح عملية ^* الحساب المحدّد في كل مرة تتم فيها مشاركة البيانات.
- عند استخدام آلية للحفاظ على الخصوصية، مثل تقنيات الخصوصية التفاضلية، مثل RAPPOR أو الحسابات الموحَّدة السرية
- عند معالجة البيانات في بيئة تنفيذ محمية تحميها من مقدّم الخدمة والبنية الأساسية، مثل عدم توفّر إذن وصول للمشرف، والجهاز الافتراضي السري، وإثبات صحة البيانات عن بُعد، وعدم إمكانية نقل البيانات الخاصة، وإيقاف التسجيل، وإخفاء عنوان IP، والتشفير
  - يجب أن يوفّر أي تنفيذ يستخدم هذه الطريقة وسيلة للمستخدمين لإيقافها.

[C-1-3] يجوز معالجة البيانات من خلال بيئة سحابية أساسية موثوقة للحوسبة تحميها من مقدّم الخدمة والبنية الأساسية (على سبيل المثال، عدم توفّر إذن وصول للمشرف، وآلة افتراضية سرية، وإثبات صحة عن بُعد، وعدم إمكانية نقل البيانات الخاصة، وإيقاف التسجيل، وإخفاء عنوان IP، والتشفير). أي عملية تنفيذ تستخدم هذه الطريقة:
- يجب توفير وسيلة للمستخدمين لإيقاف الميزة، و
- يجب توفير طريقة للمستخدمين لإنشاء سجلّات شاملة يسهل الوصول إليها وتتضمّن تفاصيل حول دخول البيانات إلى البيئة وخروجها منها.

[C-1-4] يجب عدم ربط هذه البيانات بأي هوية مستخدم (مثل Account) على الجهاز، إلا بموافقة صريحة من المستخدم في كل مرة يتم فيها الربط بين البيانات.

[C-1-4] قد يتم عرض هذه البيانات على مساحات عرض واجهة المستخدم التي يملكها النظام.

[C-1-5] يجب عدم مشاركة ربط هذه البيانات بأي هوية مستخدم (مثل Account)، إلا بموافقة المستخدم الصريحة في كل مرة تتم فيها المشاركة في كل مرة يتم فيها الربط، وإلا لن يتم نقل الربط إلى مكونات نظام التشغيل الأخرى التي لا تلتزم بالمتطلبات الموضّحة في القسم الحالي (‫9.8.6 البيانات على مستوى نظام التشغيل والبيانات المحيطة) في كل مرة تتم فيها المشاركة. ما لم يتم إنشاء هذه الوظيفة كواجهة برمجة تطبيقات لحزمة تطوير البرامج (SDK) لنظام التشغيل Android (AmbientContext،HotwordDetectionService).
[C-1-6] يجب توفير وسيلة للمستخدم لمحو هذه البيانات التي تجمعها عملية التنفيذ أو الوسائل الخاصة عند تخزين البيانات بأي شكل من الأشكال على الجهاز أو في بيئة السحابة الإلكترونية لقاعدة الحوسبة الموثوقة. إذا اختار المستخدم محو البيانات، يجب إزالة جميع البيانات السابقة التي تم جمعها.

[C-1-7] يجب توفير وسيلة تحكّم للمستخدم لإيقاف عرض البيانات التي تم جمعها من خلال AppSearch أو وسائل خاصة على نظام Android الأساسي (مثل مشغّل التطبيقات).

‫[C-1-8] يجب توفير طريقة لإنشاء سجلّات شاملة يمكن الوصول إليها تتضمّن تفاصيل دخول البيانات وخروجها من البيئة.
[C-1-9] يجب ألا يكون لديه إمكانية الوصول المباشر إلى الإنترنت.
[C-1-10] يجوز عرض واجهة المستخدم عن بُعد طالما أنّه لا يتم إتاحة أي بيانات لحزمة APK المضيفة التي تعرض واجهة المستخدم.
[C-1-11] يجب إبقاء الخدمات منفصلة عن مكوّنات النظام الأخرى (على سبيل المثال، عدم ربط الخدمة أو مشاركة أرقام تعريف العمليات مع عمليات التنفيذ غير الموجودة في بيئة التنفيذ المحمية).
[C-1-12] يجب ألا يتم السماح بخروج البيانات الحسّاسة إلا في الحالات التالية:
- أن يتمّ بدء عملية المشاركة بشكلٍ صريح من خلال نية المستخدم* في إجراء عملية حسابية محدّدة في كل مرة تتم فيها مشاركة البيانات، أو
- استخدام آلية للحفاظ على الخصوصية (مثل تقنيات الخصوصية التفاضلية، مثل RAPPOR أو الحسابات الموحّدة السرية)
[C-1-13] يجب ألا تسمح إلا باستخراج البيانات الحسّاسة من خلال:
- خدمة تابعة لنظام التشغيل مُدرَجة في القائمة المسموح بها في خدمة نظام PCCSandbox وتستوفي متطلبات بيئة التنفيذ المحمية (9.8.6)، أو
- حزمة APK لبوابة "نظام الحوسبة الخاصة" (PCC) المحدّدة (الموضّحة في الفقرة 9.8.15)
[C-1-14] يجب عدم إجراء عمليات احتياطية على السحابة الإلكترونية للبيانات المستنتَجة من البيانات الحسّاسة ما لم يتم تشفيرها بشكل تام بين الأطراف (على سبيل المثال، باستخدام Android Backup Service).

[C-SR-1] يُنصح بشدة بعدم طلب إذن الوصول إلى الإنترنت.
[C-SR-2] يُنصح بشدة بعدم الوصول إلى الإنترنت إلا من خلال واجهات برمجة التطبيقات المنظَّمة التي تستند إلى عمليات تنفيذ مفتوحة المصدر ومتاحة للجميع.
[C-SR-4] يُنصح بشدة بتنفيذها باستخدام واجهة برمجة التطبيقات (API) لحزمة تطوير البرامج (SDK) لنظام التشغيل Android أو مستودع مفتوح المصدر مماثل تملكه الشركة المصنّعة الأصلية للأجهزة (OEM)، و / أو تنفيذها في بيئة معزولة (راجِع القسم 9.8.15 "عمليات تنفيذ واجهات برمجة التطبيقات في البيئة المعزولة").

إذا كانت عمليات تنفيذ الأجهزة تتضمّن خدمة تنفّذ System API ContentCaptureService، AppSearchManager.index، DynamicInstrumentationEventService، أو أي خدمة خاصة تجمع البيانات على النحو الموضّح أعلاه، يجب أن تستوفي ما يلي:

[C-2-1] يجب ألا تسمح الأجهزة للمستخدمين باستبدال الخدمات بتطبيق أو خدمة يمكن للمستخدم تثبيتها، ويجب أن تسمح فقط للخدمات المثبَّتة مسبقًا بجمع هذه البيانات.
[C-2-2] يجب ألا تسمح بأي تطبيقات أخرى غير آلية الخدمات المثبَّتة مسبقًا بالتقاط هذه البيانات.
[C-2-3] يجب توفير وسيلة استخدام واضحة وسهلة للمستخدم لإيقاف الخدمات.
[C-2-4] يجب عدم إغفال توفير وسائل تحكّم للمستخدمين لإدارة أذونات Android التي تحتفظ بها الخدمات، ويجب اتّباع نموذج أذونات Android كما هو موضّح في الفقرة 9.1. الإذن
[C-SR-3] يُنصح بشدة بإبقاء الخدمات منفصلة عن مكونات النظام الأخرى (على سبيل المثال، عدم ربط الخدمة أو مشاركة أرقام تعريف العمليات) باستثناء ما يلي:
- الاتصال الهاتفي وجهات الاتصال وواجهة مستخدم النظام والوسائط

‫9.8.7. الوصول إلى الحافظة

عمليات تنفيذ الجهاز:

[C-0-1] يجب عدم عرض بيانات مقتطعة من الحافظة (مثلاً، من خلال واجهة برمجة التطبيقات ClipboardManager ) ما لم يكن تطبيق الجهة الخارجية هو طريقة الإدخال التلقائية أو التطبيق الذي يتم التركيز عليه حاليًا.
[C-0-2] يجب محو بيانات الحافظة بعد 60 دقيقة على الأكثر من آخر مرة تم فيها وضع البيانات في الحافظة أو قراءتها منها.

‫9.8.8. الموقع الجغرافي

يتضمّن الموقع الجغرافي معلومات في فئة الموقع الجغرافي على Android( مثل خطوط الطول والعرض والارتفاع)، بالإضافة إلى المعرّفات التي يمكن تحويلها إلى موقع جغرافي. يمكن أن يكون الموقع الجغرافي دقيقًا مثل نظام تحديد المواقع العالمي التفاضلي (DGPS) أو غير دقيق مثل المواقع الجغرافية على مستوى البلد (مثل الموقع الجغرافي لرمز البلد - MCC - رمز البلد على الأجهزة الجوّالة).

في ما يلي قائمة بأنواع المواقع الجغرافية التي تستند مباشرةً إلى الموقع الجغرافي للمستخدم أو يمكن تحويلها إلى الموقع الجغرافي للمستخدم. هذه القائمة ليست شاملة، ولكن يجب استخدامها كمثال على المعلومات التي يمكن استنتاجها بشكل مباشر أو غير مباشر من الموقع الجغرافي:

نظام تحديد المواقع العالمي (GPS) / نظام GNSS/نظام DGPS/نظام PPP
- نظام تحديد المواقع العالمي أو نظام الملاحة العالمي عبر الأقمار الصناعية أو نظام تحديد المواقع العالمي التفاضلي
- ويشمل ذلك أيضًا "قياسات GNSS الأولية" و"حالة GNSS".
  - يمكن استخلاص "الموقع الجغرافي الدقيق" من "قياسات GNSS الأولية"
التقنيات اللاسلكية التي تتضمّن معرّفات فريدة، مثل:
- نقاط وصول Wi-Fi (عنوان MAC أو BSSID أو الاسم أو SSID)
- البلوتوث/تقنية BLE (عنوان MAC أو معرّف مجموعة الخدمات الأساسية أو الاسم أو معرّف مجموعة الخدمات)
- النطاق الفائق العرض (MAC أو BSSID أو الاسم أو SSID)
- معرّف برج الاتصالات (الجيل الثالث والرابع والخامس وما إلى ذلك، بما في ذلك جميع تقنيات مودم شبكة الجوّال المستقبلية التي تتضمّن معرّفات فريدة)

للحصول على مرجع أساسي، اطّلِع على واجهات برمجة التطبيقات لنظام التشغيل Android التي تتطلّب أذونات ACCESS_FINE_Location أو ACCESS_COARSE_Location.

عمليات تنفيذ الجهاز:

[C-0-1] يجب عدم تفعيل/إيقاف إعدادات الموقع الجغرافي للجهاز وإعدادات البحث عن شبكات Wi-Fi/البلوتوث بدون موافقة صريحة من المستخدم أو بدون أن يبدأ المستخدم ذلك.
[C-0-2] يجب توفير عنصر تحكُّم للمستخدم للوصول إلى المعلومات ذات الصلة بالموقع الجغرافي، بما في ذلك طلبات الموقع الجغرافي الحديثة والأذونات على مستوى التطبيق واستخدام البحث عن بلوتوث لتحديد الموقع الجغرافي.
[C-0-3] يجب التأكّد من أنّ التطبيق الذي يستخدم واجهة برمجة التطبيقات Emergency Location Bypass API LocationRequest.setLocationSettingsIgnored() هو جلسة طوارئ بدأها المستخدم (مثل الاتصال بالرقم 911 أو إرسال رسالة نصية إلى الرقم 911). ومع ذلك، بالنسبة إلى Automotive، يجوز للمركبة بدء جلسة طوارئ بدون تفاعل المستخدم النشط في حال رصد حادث (مثل استيفاء متطلبات نظام eCall).
[C-0-4] يجب الحفاظ على إمكانية واجهات برمجة التطبيقات الخاصة بتجاوز إعدادات الموقع الجغرافي في حالات الطوارئ لتجاوز إعدادات الموقع الجغرافي للجهاز بدون تغيير الإعدادات.
[C-0-5] يجب جدولة إشعار لتذكير المستخدم بعد أن يصل تطبيق يعمل في الخلفية إلى بيانات موقعه الجغرافي باستخدام إذن ACCESS_BACKGROUND_LOCATION.

عندما يصل تطبيق غير تابع للنظام ويعمل في المقدّمة إلى الموقع الجغرافي الدقيق لجهاز، يكون الجهاز:

[C-SR-1] يُنصح بشدة بعرض مؤشر مرئي للمستخدم

‫9.8.9. التطبيقات المثبّتة

لا يمكن لتطبيقات Android التي تستهدف المستوى 30 من واجهة برمجة التطبيقات أو مستوى أعلى الاطّلاع على تفاصيل حول التطبيقات الأخرى المثبَّتة تلقائيًا (راجِع مستوى ظهور الحِزم في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android).

عمليات تنفيذ الجهاز:

[C-0-1] يجب عدم عرض تفاصيل حول أي تطبيق آخر مثبَّت لأي تطبيق يستهدف المستوى 30 أو أعلى لواجهة برمجة التطبيقات، إلا إذا كان التطبيق قادرًا بالفعل على الاطّلاع على تفاصيل حول التطبيق الآخر المثبَّت من خلال واجهات برمجة التطبيقات المُدارة. ويشمل ذلك، على سبيل المثال لا الحصر، التفاصيل التي تعرضها أي واجهات برمجة تطبيقات مخصّصة أضافها مطوّر الجهاز أو يمكن الوصول إليها من خلال نظام الملفات.
[C-0-2] يجب عدم منح أي تطبيق إذن الوصول للقراءة أو الكتابة إلى الملفات في أي دليل مخصّص خاص بالتطبيق تابع لتطبيق آخر ضمن وحدة التخزين الخارجية. الاستثناءات الوحيدة هي كما يلي:
- سلطة مقدم مساحة التخزين الخارجية (مثل تطبيقات DocumentsUI)
- تنزيل موفّر يستخدم سلطة موفّر "عمليات التنزيل" لتنزيل الملفات إلى مساحة تخزين التطبيق
- تطبيقات بروتوكول نقل الوسائط (MTP) الموقّعة من المنصة والتي تستخدم الإذن المميز ACCESS_MTP لتفعيل نقل الملفات إلى جهاز آخر
- يمكن للتطبيقات التي تثبّت تطبيقات أخرى ولديها إذن INSTALL_PACKAGES الوصول إلى أدلة "obb" فقط بغرض إدارة ملفات بيانات APK الموسّعة.

‫9.8.10. تقرير أخطاء الاتصال

إذا كانت عمليات تنفيذ الأجهزة تعرّف علامة الميزة android.hardware.telephony، عليها استيفاء ما يلي:

[C-1-1] يجب إتاحة إنشاء تقارير أخطاء الاتصال من خلال BUGREPORT_MODE_TELEPHONY باستخدام BugreportManager.
[C-1-2] يجب الحصول على موافقة المستخدم في كل مرة يتم فيها استخدام BUGREPORT_MODE_TELEPHONY لإنشاء تقرير، ويجب عدم مطالبة المستخدم بالموافقة على جميع الطلبات المستقبلية من التطبيق.
[C-1-3] يجب عدم إرجاع التقرير الذي تم إنشاؤه إلى التطبيق الذي أرسل الطلب بدون الحصول على موافقة المستخدم الصريحة.
[C-1-4] يجب أن تحتوي التقارير التي يتم إنشاؤها باستخدام BUGREPORT_MODE_TELEPHONY على المعلومات التالية على الأقل:
- TelephonyDebugService dump
- TelephonyRegistry dump
- WifiService dump
- ConnectivityService dump
- عرض لنموذج CarrierService الخاص بحزمة الاتصال (في حال الربط)
- مخزن مؤقت لسجل الراديو
- SubscriptionManagerService dump
[C-1-5] يجب عدم تضمين ما يلي في التقارير التي يتم إنشاؤها:
- أي نوع من المعلومات غير المرتبطة مباشرةً بتصحيح أخطاء الاتصال
- أي نوع من سجلّات زيارات التطبيقات التي يثبّتها المستخدم أو الملفات الشخصية التفصيلية للتطبيقات/الحِزم التي يثبّتها المستخدم (لا بأس بمعرّفات UID، ولكن لا يُسمح بأسماء الحِزم)
قد تتضمّن معلومات إضافية غير مرتبطة بأي هوية مستخدم. (مثل سجلات المورّدين).

إذا كانت عمليات تنفيذ الأجهزة تتضمّن معلومات إضافية (مثل سجلّات المورّدين) في تقارير الأخطاء وكان لهذه المعلومات تأثير على الخصوصية أو الأمان أو البطارية أو مساحة التخزين أو الذاكرة، يجب أن تستوفي ما يلي:

[C-SR-1] يُنصح بشدة بأن يكون إعداد المطوّرين مضبوطًا تلقائيًا على إيقاف. تستوفي عملية التنفيذ المرجعية في AOSP هذا الشرط من خلال توفير الخيار Enable verbose vendor logging في إعدادات المطوّرين لتضمين سجلّات مورّدين إضافية خاصة بالجهاز في تقارير الأخطاء.

‫9.8.11. مشاركة كتل البيانات

يتيح نظام التشغيل Android للتطبيقات المساهمة في إنشاء كتل بيانات يمكن مشاركتها مع مجموعة محددة من التطبيقات، وذلك من خلال BlobStoreManager.

إذا كانت عمليات تنفيذ الأجهزة تتيح استخدام وحدات البيانات المشتركة على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK)، فإنّها:

[C-1-1] يجب عدم مشاركة وحدات البيانات الثنائية الكبيرة الخاصة بالتطبيقات بما يتجاوز ما كان من المفترض السماح به (أي نطاق الوصول التلقائي وأوضاع الوصول الأخرى التي يمكن تحديدها باستخدام BlobStoreManager.session#allowPackageAccess() أو BlobStoreManager.session#allowSameSignatureAccess() أو BlobStoreManager.session#allowPublicAccess()). ويجب عدم تعديلها. يستوفي التنفيذ المرجعي لنظام التشغيل AOSP هذه المتطلبات.
[C-1-2] يجب عدم إرسال تجزئات البيانات الآمنة (المستخدَمة للتحكّم في الوصول) خارج الجهاز أو مشاركتها مع تطبيقات أخرى.

‫9.8.12. Music Recognition

يتيح نظام التشغيل Android، من خلال واجهة برمجة التطبيقات للنظام MusicRecognitionManager، آلية تتيح عمليات تنفيذ الأجهزة طلب التعرّف على الموسيقى، وذلك عند توفّر تسجيل صوتي، كما يتيح تفويض عملية التعرّف على الموسيقى إلى تطبيق يتمتع بامتيازات وينفّذ واجهة برمجة التطبيقات MusicRecognitionService.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن خدمة تنفّذ واجهة برمجة التطبيقات System API MusicRecognitionManager أو أي خدمة خاصة تبث بيانات صوتية كما هو موضح أعلاه، يجب أن تستوفي ما يلي:

[C-1-1] يجب فرض أن يكون لدى المتصل بـ MusicRecognitionManager الإذن MANAGE_MUSIC_RECOGNITION
[C-1-2] يجب فرض أن يطبّق تطبيق واحد مثبّت مسبقًا للتعرّف على الموسيقى MusicRecognitionService.
[C-1-3] يجب ألا تسمح للمستخدمين باستبدال MusicRecognitionManagerService أو MusicRecognitionService بتطبيق أو خدمة يمكن للمستخدم تثبيتها.
[C-1-4] يجب التأكّد من أنّه عند وصول خدمة MusicRecognitionManagerService إلى تسجيل الصوت وإعادة توجيهه إلى التطبيق الذي ينفّذ MusicRecognitionService، يتم تتبُّع إذن الوصول إلى الصوت من خلال استدعاءات AppOpsManager.noteOp / startOp.

في حال كانت عمليات تنفيذ MusicRecognitionManagerService أو MusicRecognitionService على الأجهزة تخزّن أي بيانات صوتية تم تسجيلها، يجب أن تستوفي ما يلي:

[C-2-1] يجب عدم تخزين أي بيانات صوتية أولية أو بصمات صوتية على القرص على الإطلاق، أو في الذاكرة لمدة تزيد عن 14 يومًا.
[C-2-2] يجب عدم مشاركة هذه البيانات خارج MusicRecognitionService، إلا بعد الحصول على موافقة المستخدم الصريحة في كل مرة تتم فيها المشاركة.

‫9.8.13. SensorPrivacyManager

إذا كانت عمليات تنفيذ الأجهزة توفّر للمستخدم أداة برمجية لإيقاف إدخال الكاميرا و/أو الميكروفون في عملية تنفيذ الجهاز، يجب أن:

[C-1-1] يجب أن تعرض الطريقة ذات الصلة في واجهة برمجة التطبيقات supportsSensorToggle() القيمة "true" بدقة.
[C-1-2] يجب أن يتم عرض عنصر تحكّم غير قابل للإغلاق للمستخدم عندما يحاول تطبيق الوصول إلى ميكروفون أو كاميرا محظورَين، ويجب أن يشير عنصر التحكّم بوضوح إلى أنّ أداة الاستشعار محظورة ويتطلّب اختيارًا لمواصلة الحظر أو إزالته وفقًا لتنفيذ مشروع Android المفتوح المصدر (AOSP) الذي يستوفي هذا الشرط.
[C-1-3] يجب ألا يتم تمرير سوى بيانات فارغة (أو وهمية) للكاميرا والصوت إلى التطبيقات وألا يتم عرض رمز خطأ بسبب عدم تفعيل المستخدم للكاميرا أو الميكروفون من خلال عنصر التحكّم الذي يتم عرضه وفقًا لما ورد في [C-1-2] أعلاه.

‫9.8.14. لا ينطبق

‫9.8.15. عمليات تنفيذ "نظام الحوسبة الخاصة" و"تطبيق البوابة"

يوفّر Android، من خلال مجموعة من واجهات برمجة التطبيقات المفوضة، آلية لمعالجة البيانات الآمنة على مستوى نظام التشغيل والبيانات المحيطة. يمكن تفويض عملية المعالجة هذه إلى حزمة APK مثبَّتة مسبقًا تتضمّن إذن وصول مميّزًا وإمكانات تواصل محدودة، وتُعرف باسم "تنفيذ واجهة برمجة التطبيقات المحمية".

ننصح بشدة باستخدام إطار عمل "نظام الحوسبة الخاصة" (PCC) الموضّح أدناه في عمليات تنفيذ الأجهزة التي تتضمّن تطبيقات تعالج البيانات الحساسة على الجهاز كما هو موضّح في القسم 9.8.6 (بيانات على مستوى نظام التشغيل والبيانات المحيطة).

أي عناصر تنفيذ لواجهة Sandboxed API في بيئة PCC:

[C-0-1] يجب عدم طلب إذن الوصول إلى الإنترنت.

يجب تعريف [C-0-1] باستخدام السمة android:isPrivateComputeCoreProcess="true" في تعريف البيان.

[C-0-2] يجب ألا يتم الوصول إلى الإنترنت إلا من خلال واجهات برمجة تطبيقات منظَّمة تستند إلى عمليات تنفيذ مفتوحة المصدر متاحة للجميع تستخدم آليات تحافظ على الخصوصية، أو بشكل غير مباشر من خلال واجهات برمجة تطبيقات حزمة تطوير البرامج (SDK) لنظام التشغيل Android. يتم تعريف آلية الحفاظ على الخصوصية بأنّها "الآليات التي تسمح بالتحليل المجمّع فقط وتمنع مطابقة الأحداث المسجّلة أو النتائج المشتقة مع المستخدمين الفرديين"، وذلك لمنع إمكانية فحص أي بيانات لكل مستخدم (على سبيل المثال، يتم تنفيذها باستخدام تكنولوجيا الخصوصية التفاضلية مثل RAPPOR).

[C-0-2] يجب أن يكون مُحمَّلاً مسبقًا على صورة نظام الجهاز.

[C-0-3] يجب إبقاء الخدمات منفصلة عن مكوّنات النظام الأخرى (مثل عدم ربط الخدمة أو مشاركة أرقام تعريف العمليات باستثناء ما يلي:
- الاتصال الهاتفي وجهات الاتصال وواجهة مستخدم النظام والوسائط التي لا يتم تنفيذها كمعرّف UID لـ PCC).
[C-0-4] يجب ألا تسمح للمستخدمين باستبدال الخدمات بتطبيق أو خدمة يمكن للمستخدم تثبيتها
[C-0-5] يجب ألا يسمح إلا للخدمات المثبَّتة مسبقًا التي يعيّنها المصنّع الأصلي للجهاز (الذي لديه دور نظام مناسب محدّد في "خدمة نظام إدارة PCC")، والتي لديها الأذونات المناسبة، بجمع هذه البيانات. ما لم تكن إمكانية الاستبدال مضمّنة في AOSP (مثل تطبيقات المساعد الرقمي) البيانات المحيطة الحسّاسة كما هو موضّح في القسم 9.8.6
[C-0-6] يجب ألا تسمح بأي تطبيقات أخرى غير آلية الخدمات المثبَّتة مسبقًا بالتقاط هذه البيانات. ما لم يتم تنفيذ إمكانية الالتقاط هذه باستخدام واجهة برمجة تطبيقات Android SDK.
[C-0-7] يجب توفير إمكانية للمستخدم لإيقاف الخدمات.
[C-0-8] يجب عدم إغفال توفير إمكانية للمستخدمين لإدارة أذونات Android التي تحتفظ بها الخدمات، ويجب اتّباع نموذج أذونات Android كما هو موضّح في الفقرة 9.1. الإذن

[C-0-9] يجب أن يتم تشغيلها في عملية مخصّصة باستخدام معرّف فريد (UID) تحدّده البنية الأساسية، ويكون منفصلاً عن عملية التطبيق الرئيسية والمكوّنات الأخرى التي تعمل في وضع الحماية.

يجب أن يتم توجيه أي وصول إلى الشبكة تتطلبه مكونات بيئة "السيارة المتصلة" من خلال حِزمة APK مخصّصة تعمل كتطبيق بوابة "السيارة المتصلة". المكوّنات المحدّدة:

[C-1-1] يجب منح إذن android.permission.PROVIDE_PRIVATE_COMPUTE_SERVICES المميز. يصنّف هذا الإذن التطبيق كتطبيق بوابة PCC.
[C-1-2] يجب إتاحة رمز المصدر للتحقّق منه بشكل علني.
[C-1-3] يجب استخدام آليات الحفاظ على الخصوصية لأي عملية نقل بيانات خارج الجهاز، كما هو موضّح في الفقرة 9.8.6
[C-1-4] يجب أن يتيح وضع التدقيق في إطار عمل PCC، والذي يتضمّن تسجيل طلبات الشبكة ونقاط نهاية الخادم وغيرها من البيانات ذات الصلة بالتحقّق من السلوك الذي يحافظ على الخصوصية عند تفعيله

‫9.8.16. بيانات الصوت والكاميرا المستمرة

إذا كانت عمليات تنفيذ الأجهزة تسجّل أيًا من البيانات الموضّحة في الفقرة 9.8.2 أو الفقرة 9.8.6، وإذا كانت عمليات التنفيذ هذه تستخدم بيانات الصوت التي يتم الحصول عليها في الخلفية (بشكل مستمر) من خلال AudioRecord أو SoundTrigger أو واجهات برمجة تطبيقات أخرى خاصة بالصوت، أو بيانات الكاميرا التي يتم الحصول عليها في الخلفية (بشكل مستمر) من خلال CameraManager أو واجهات برمجة تطبيقات أخرى خاصة بالكاميرا، يجب أن تستوفي ما يلي:

[C-0-1] يجب فرض مؤشر مطابق (الكاميرا و/أو الميكروفون كما هو موضح في القسم 9.8.2 التسجيل)، إلا في الحالات التالية:
- يتم منح هذا الإذن في عملية تنفيذ ضمن بيئة معزولة (راجِع الفقرة 9.8.15 "تنفيذ واجهة برمجة التطبيقات في بيئة معزولة")، وذلك من خلال حزمة تتضمّن أحد الأدوار التالية أو أكثر: الذكاء الاصطناعي لواجهة مستخدم النظام أو الذكاء الاصطناعي للصوت المحيطي في النظام أو الذكاء الاصطناعي للصوت في النظام أو الذكاء الاصطناعي للإشعارات في النظام أو الذكاء الاصطناعي للنصوص في النظام أو الذكاء الاصطناعي للمرئيات في النظام.
- يتم تنفيذ عملية الوصول من خلال وضع الحماية، ويتم تنفيذها وفرضها من خلال آليات في مشروع AOSP (HotwordDetectionService وWearableSensingService وVisualQueryDetector).
- يتم الوصول إلى الصوت لأغراض متعلقة بتسهيل الاستخدام من خلال تطبيق "المساعد الرقمي" الذي يوفّر SOURCE_HOTWORD كمصدر للصوت.
- يتم تنفيذ عملية الوصول من خلال النظام وتنفيذها باستخدام رمز مفتوح المصدر.
[C-SR-1] يُنصح بشدة بطلب موافقة المستخدم على كل وظيفة تستخدم هذه البيانات، ويجب أن تكون هذه الوظيفة غير مفعّلة تلقائيًا.
[C-SR-2] يُنصح بشدة بتطبيق المعالجة نفسها (أي اتّباع القيود الموضّحة في البنود 9.8.2 التسجيل و9.8.6 البيانات على مستوى نظام التشغيل والبيانات المحيطة و9.8.15 عمليات تنفيذ واجهات برمجة التطبيقات المحمية و9.8.16 البيانات المستمرة للصوت والكاميرا) على بيانات الكاميرا الواردة من جهاز قابل للارتداء عن بُعد.

إذا كانت عمليات تنفيذ الأجهزة تتلقّى بيانات الكاميرا أو الميكروفون من جهاز قابل للارتداء عن بُعد ويتم الوصول إلى البيانات بشكل غير مشفّر خارج نظام التشغيل Android أو عملية التنفيذ المعزولة أو الوظيفة المعزولة التي أنشأتها WearableSensingManager، يجب أن تستوفي ما يلي:

[C-1-1] يجب إرسال إشارة إلى الجهاز القابل للارتداء البعيد لعرض مؤشر إضافي عليه.

إذا كانت الأجهزة توفّر إمكانية التفاعل مع تطبيق "مساعد رقمي" بدون الكلمة الرئيسية المحدّدة (إما من خلال معالجة طلبات البحث العامة للمستخدمين أو تحليل حضور المستخدمين من خلال الكاميرا)، فإنّها:

[C-2-1] يجب التأكّد من أنّ الحزمة التي تتضمّن الدور android.app.role.ASSISTANT توفّر عملية التنفيذ هذه.
[C-2-2] يجب التأكّد من أنّ عملية التنفيذ هذه تستخدم واجهات برمجة التطبيقات HotwordDetectionService و/أو VisualQueryDetectionService لنظام التشغيل Android.

‫9.8.17. Telemetry

يخزِّن نظام التشغيل Android سجلّات النظام والتطبيقات باستخدام واجهات برمجة التطبيقات StatsLog. تتم إدارة هذه السجلات من خلال واجهات برمجة التطبيقات StatsManager التي يمكن أن تستخدمها تطبيقات النظام المزوّدة بأذونات مميّزة.

توفّر StatsManager أيضًا طريقة لجمع البيانات المصنّفة على أنّها حساسة للخصوصية من الأجهزة التي تتضمّن آلية للحفاظ على الخصوصية. على وجه الخصوص، تتيح واجهة برمجة التطبيقات StatsManager::query إمكانية طلب البحث عن فئات المقاييس المحظورة المحدّدة في StatsLog.

أي عملية تنفيذ تستعلم عن المقاييس المحظورة وتجمعها من StatsManager:

[C-0-1] يجب أن يكون التطبيق/التنفيذ الوحيد على الجهاز وأن يحمل إذن READ_RESTRICTED_STATS.
[C-0-2] يجب إرسال بيانات القياس عن بُعد وسجلّ الجهاز فقط باستخدام آلية تحافظ على الخصوصية. يتم تعريف آلية الحفاظ على الخصوصية بأنّها "الآليات التي تسمح بالتحليل المجمّع فقط وتمنع مطابقة الأحداث المسجّلة أو النتائج المشتقة مع المستخدمين الفرديين"، وذلك لمنع إمكانية فحص أي بيانات خاصة بكل مستخدم (على سبيل المثال، يتم تنفيذها باستخدام تكنولوجيا الخصوصية التفاضلية مثل RAPPOR).
[C-0-3] يجب عدم ربط هذه البيانات بأي هوية مستخدم (مثل الحساب) على الجهاز.
[C-0-4] يجب عدم مشاركة هذه البيانات مع مكونات نظام التشغيل الأخرى التي لا تلتزم بالمتطلبات الموضّحة في القسم الحالي (9.8.17. القياس عن بُعد).
[C-0-5] يجب توفير وسيلة تتيح للمستخدم تفعيل/إيقاف جمع بيانات القياس عن بُعد التي تحافظ على الخصوصية واستخدامها ومشاركتها.
[C-0-6] يجب توفير وسيلة للمستخدم لمحو البيانات التي تجمعها عملية التنفيذ إذا كانت البيانات مخزّنة بأي شكل على الجهاز. إذا اختار المستخدم محو البيانات، يجب إزالة جميع البيانات المخزَّنة حاليًا على الجهاز.
[C-0-7] يجب الإفصاح عن تنفيذ البروتوكول الأساسي للحفاظ على الخصوصية في مستودع مفتوح المصدر.
[C-0-8] يجب فرض سياسات نقل البيانات خارج الجهاز في هذا القسم للتحكّم في جمع البيانات ضمن فئات المقاييس المحظورة المحدّدة في StatsLog.

‫9.8.18. خصوصية الوظائف المستندة إلى الذكاء الاصطناعي الوكيل

عمليات تنفيذ الجهاز:

[C-0-1] يجب التأكّد من أنّ أي مكوّنات تنفّذ AppFunctions لديها إذن EXECUTE_APP_FUNCTIONS أو EXECUTE_APP_FUNCTIONS_SYSTEM.
[C-0-2] يجب ألا يتم استدعاء AppFunction إلا كنتيجة مباشرة لإجراء صريح من المستخدم، ويجب أن يوضّح هذا الإجراء للمستخدم التطبيق الذي يتم استدعاؤه والإجراء الأساسي الذي سيتم تنفيذه داخل هذا التطبيق.
[C-0-3] يجب عدم توجيه طلب تطبيق تابع لجهة خارجية أو تعديله للعثور على AppFunctions أو تنفيذها، ما لم يتم استيفاء الشرطَين [C-0-1] و[C-0-2].
[C-0-4] يجب ألا تسمح باستخدام البيانات الحساسة على مستوى نظام التشغيل أو البيانات المحيطة (على النحو المحدّد في 9.8.6 حماية البيانات الحساسة على مستوى نظام التشغيل والبيانات المحيطة) أو مشتقاتها من قِبل مكوّنات النظام لإنشاء إشعارات تنبيهية أو تحديد مَعلمات لها، إلا إذا كانت مكوّنات النظام تعمل في بيئة تنفيذ محمية على النحو المحدّد في 9.8.6.

المصطلح الأساسي: يُعرَّف مصطلح "تذكير" بأنّه نقطة دخول يتم إنشاؤها بشكل استباقي إلى تطبيق من مساحة عرض في النظام، ويتم بدءها بدون إجراء مباشر من المستخدم يسبقها. تُقدّم التنبيهات اقتراحات للمستخدم أو ترشده إلى اتّخاذ إجراء معيّن بدون تقييد حرية الاختيار.

‫9.9. تشفير البيانات المخزَّنة

يجب أن تستوفي جميع الأجهزة متطلبات القسم 9.9.1. يتم إعفاء الأجهزة التي تم إطلاقها بمستوى واجهة برمجة تطبيقات أقدم من المستوى المذكور في هذا المستند من متطلبات الفقرتين 9.9.2 و9.9.3، ويجب بدلاً من ذلك أن تستوفي المتطلبات الواردة في الفقرة 9.9 من مستند "تعريف التوافق مع Android" الذي يتوافق مع مستوى واجهة برمجة التطبيقات الذي تم إطلاق الجهاز به.

‫9.9.1. التشغيل المباشر

عمليات تنفيذ الجهاز:

[C-0-1] يجب تنفيذ واجهات برمجة التطبيقات لوضع التشغيل المباشر حتى إذا كانت لا تتوافق مع ميزة "تشفير وحدة التخزين".
[C-0-2] يجب أن يستمر بث الغرضين ACTION_LOCKED_BOOT_COMPLETED وACTION_USER_UNLOCKED للإشارة إلى التطبيقات المتوافقة مع "الوضع المباشر" بأنّ مواقع التخزين المشفرة على الجهاز (DE) والمشفرة ببيانات الاعتماد (CE) متاحة للمستخدم.

‫9.9.2. متطلبات التشفير

عمليات تنفيذ الجهاز:

[C-0-1] يجب تشفير بيانات التطبيق الخاصّة (القسم /data)، بالإضافة إلى قسم مساحة التخزين المشتركة للتطبيق (القسم /sdcard) إذا كان جزءًا دائمًا وغير قابل للإزالة من الجهاز.
[C-0-2] يجب تفعيل تشفير تخزين البيانات تلقائيًا عند إكمال المستخدم تجربة الإعداد الجاهز للاستخدام.
[C-0-3] يجب استيفاء متطلبات تشفير تخزين البيانات المذكورة أعلاه من خلال تنفيذ إحدى طريقتَي التشفير التاليتَين:
- التشفير على مستوى الملفات (FBE) وتشفير البيانات الوصفية كما هو موضّح في الفقرة 9.9.3.1
- التشفير على مستوى الحظر لكل مستخدم، كما هو موضّح في الفقرة 9.9.3.2

‫9.9.3. طُرق التشفير

إذا كانت عمليات تنفيذ الجهاز مشفَّرة، فإنّها:

[C-1-1] يجب أن يتم التشغيل بدون مطالبة المستخدم بتقديم بيانات الاعتماد، وأن يسمح للتطبيقات المتوافقة مع ميزة "التشغيل المباشر" بالوصول إلى مساحة التخزين المشفرة على الجهاز (DE) بعد بث الرسالة ACTION_LOCKED_BOOT_COMPLETED.
[C-1-2] يجب عدم السماح بالوصول إلى مساحة تخزين "بيانات الاعتماد المشفرة" (CE) إلا بعد استيفاء الشرطين التاليين:
- يفتح المستخدم قفل الجهاز باستخدام طريقة مصادقة أساسية (مثل كلمة المرور أو النقش أو رقم التعريف الشخصي).
- يتم بثّ الرسالة ACTION_USER_UNLOCKED.
[C-1-13] يجب عدم توفير أي طريقة لفتح وحدة التخزين المحمية بواسطة CE بدون بيانات الاعتماد التي يقدّمها المستخدم أو مفتاح استرداد مسجّل أو تنفيذ ميزة "استئناف عند إعادة التشغيل" التي تستوفي المتطلبات الواردة في الفقرة 9.9.4.
[C-1-4] يجب استخدام ميزة "التشغيل المتحقَّق منه".

‫9.9.3.1. التشفير على مستوى الملفات باستخدام تشفير البيانات الوصفية

في حال استخدام عمليات تنفيذ الأجهزة ميزة "التشفير على مستوى الملفات" مع ميزة "تشفير البيانات الوصفية"، يجب استيفاء ما يلي:

[C-1-5] يجب تشفير محتوى الملفات والبيانات الوصفية لنظام الملفات باستخدام AES-256-XTS أو Adiantum. يشير AES-256-XTS إلى معيار التشفير المتقدّم (AES) مع طول مفتاح تشفير يبلغ 256 بت، ويتم تشغيله في وضع XTS، ويبلغ الطول الكامل للمفتاح 512 بت.يشير Adiantum إلى Adiantum-XChaCha12-AES، كما هو محدّد في https://github.com/google/adiantum. البيانات الوصفية لنظام الملفات هي بيانات مثل أحجام الملفات والملكية والأوضاع والسمات الموسّعة (xattrs).
[C-1-6] يجب تشفير أسماء الملفات باستخدام AES-256-CBC-CTS أو AES-256-HCTR2 أو Adiantum.
[C-1-12] إذا كان الجهاز يتضمّن تعليمات مقاييس التشفير المتقدّمة (AES) (مثل "إضافات التشفير" في ARMv8 على الأجهزة المستندة إلى ARM أو AES-NI على الأجهزة المستندة إلى x86)، يجب استخدام خيارات AES المذكورة أعلاه لتشفير اسم الملف ومحتوى الملف وبيانات نظام الملفات الوصفية، وليس Adiantum.
[C-1-13] يجب استخدام دالة اشتقاق مفتاح قوية من ناحية التشفير وغير قابلة للعكس (مثل HKDF-SHA512) لاشتقاق أي مفاتيح فرعية مطلوبة (مثل المفاتيح الخاصة بكل ملف) من مفتاحَي CE وDE. يشير مصطلح "قوي من الناحية التشفيرية وغير قابل للعكس" إلى أنّ دالة اشتقاق المفتاح تتمتّع بقوة أمان تبلغ 256 بت على الأقل وتعمل كمجموعة دوال عشوائية زائفة على مدخلاتها.
[C-1-14] يجب عدم استخدام مفاتيح أو مفاتيح فرعية لتشفير الملفات (FBE) نفسها لأغراض تشفير مختلفة (مثل التشفير واشتقاق المفاتيح، أو لخوارزميتَي تشفير مختلفتَين).
[C-1-15] يجب التأكّد من أنّ جميع أجزاء محتوى الملف المشفّر غير المحذوفة في مساحة التخزين الثابتة قد تم تشفيرها باستخدام مجموعات من مفتاح التشفير ومتجه التهيئة (IV) الذي يعتمد على كل من الملف والإزاحة داخل الملف. بالإضافة إلى ذلك، يجب أن تكون جميع هذه المجموعات مميزة، إلا في الحالات التي يتم فيها التشفير باستخدام أجهزة تشفير مضمّنة لا تتوافق إلا مع طول متّجه تهيئة يبلغ 32 بت.
[C-1-16] يجب التأكّد من أنّ جميع أسماء الملفات المشفَّرة غير المحذوفة والمخزَّنة بشكل دائم في أدلة مختلفة قد تم تشفيرها باستخدام مجموعات مختلفة من مفتاح التشفير ومتّجه التهيئة (IV).
[C-1-17] يجب التأكّد من أنّ جميع كتل البيانات الوصفية لنظام الملفات المشفّرة على مساحة التخزين الثابتة مشفّرة باستخدام مجموعات مميزة من مفتاح التشفير ومتجه التهيئة (IV).
المفاتيح التي تحمي مساحات تخزين CE وDE وبيانات تعريف نظام الملفات:
- [C-1-7] يجب أن تكون مرتبطة بشكل مشفَّر بـ "ملف تخزين المفاتيح" المستند إلى الأجهزة. يجب أن يكون ملف تخزين المفاتيح هذا مرتبطًا بميزة "التشغيل المتحقَّق منه" وجذر الثقة لأجهزة الجهاز.
- [C-1-8] يجب ربط مفاتيح CE ببيانات اعتماد شاشة قفل المستخدم.
- ‫[C-1-9] يجب ربط مفاتيح CE بكلمة مرور تلقائية عندما لا يحدّد المستخدم بيانات اعتماد شاشة القفل.
- [C-1-10] يجب أن يكون المعرّف فريدًا ومميّزًا، أي ألا يتطابق مفتاح CE أو DE الخاص بأي مستخدم مع مفاتيح CE أو DE الخاصة بأي مستخدم آخر.
- [C-1-11] يجب استخدام التشفيرات وأطوال المفاتيح والأوضاع المتوافقة إلزاميًا.
- [C-1-12] يجب محو البيانات بشكل آمن أثناء فتح قفل برنامج الإقلاع وإغلاقه كما هو موضّح هنا.
يجب أن تكون التطبيقات الأساسية المثبَّتة مسبقًا (مثل المنبّه والهاتف والمراسلة) متوافقة مع ميزة "التشغيل المباشر".

يوفّر مشروع Android مفتوح المصدر الأساسي عملية تنفيذ مفضّلة للتشفير على مستوى الملفات استنادًا إلى ميزة التشفير "fscrypt" في نواة Linux، ولتشفير البيانات الوصفية استنادًا إلى ميزة "dm-default-key" في نواة Linux.

‫9.9.3.2. التشفير على مستوى الحظر لكل مستخدم

إذا كانت عمليات تنفيذ الأجهزة تستخدم التشفير على مستوى الكتل لكل مستخدم، يجب أن:

[C-1-1] يجب توفير إمكانية استخدام عدة مستخدمين كما هو موضّح في القسم 9.5.
[C-1-2] يجب توفير أقسام لكل مستخدم، إما باستخدام أقسام أولية أو وحدات تخزين منطقية.
[C-1-3] يجب استخدام مفاتيح تشفير فريدة ومميّزة لكل مستخدم لتشفير أجهزة الكتل الأساسية.
‫[C-1-4] يجب استخدام AES-256-XTS للتشفير على مستوى الحظر لأقسام المستخدم.
المفاتيح التي تحمي الأجهزة المشفّرة على مستوى الحظر لكل مستخدم:
- [C-1-5] يجب أن يكون مرتبطًا بشكل مشفَّر بـ Keystore مستند إلى الأجهزة. يجب أن يكون ملف تخزين المفاتيح هذا مرتبطًا بميزة "التشغيل المتحقَّق منه" وجذر الثقة لأجهزة الجهاز.
- [C-1-6] يجب أن تكون مرتبطة ببيانات اعتماد شاشة القفل الخاصة بالمستخدم المعنيّ.

يمكن تنفيذ التشفير على مستوى الحظر لكل مستخدم باستخدام ميزة "dm-crypt" في نواة Linux على الأقسام الخاصة بكل مستخدم.

‫9.9.4. استئناف التشغيل عند إعادة التشغيل

تتيح ميزة "استئناف عمل التطبيقات بعد إعادة التشغيل" فتح مساحة تخزين بيانات الاعتماد (CE) لجميع التطبيقات، بما في ذلك التطبيقات التي لا تتوافق بعد مع ميزة "التشغيل المباشر"، وذلك بعد إعادة التشغيل التي يتم إجراؤها من خلال تحديث عبر الأثير (OTA). تتيح هذه الميزة للمستخدمين تلقّي إشعارات من التطبيقات المثبَّتة بعد إعادة التشغيل.

يجب أن يستمر تنفيذ ميزة "استئناف التشغيل عند إعادة التشغيل" في ضمان أنّه عندما يقع الجهاز في أيدي مهاجم، يصعب على هذا المهاجم استرداد بيانات المستخدم المشفرة باستخدام بيانات اعتماد، حتى إذا كان الجهاز قيد التشغيل وتم فتح قفل مساحة التخزين المشفرة باستخدام بيانات الاعتماد وفتح المستخدم قفل الجهاز بعد تلقّي تحديث عبر الأثير. لضمان مقاومة الهجمات الداخلية، نفترض أيضًا أنّ المهاجم يمكنه الوصول إلى مفاتيح التوقيع المشفرة للبث.

وعلى وجه التحديد:

[C-0-1] يجب ألا يكون من الممكن قراءة بيانات التشفير من جهة العميل حتى بالنسبة إلى المهاجم الذي يملك الجهاز فعليًا، والذي لديه الإمكانات والقيود التالية:
- يمكن استخدام مفتاح التوقيع الخاص بأي بائع أو شركة لتوقيع الرسائل العشوائية.
- يمكن أن يؤدي إلى تلقّي الجهاز لتحديث عبر الأثير.
- يمكن تعديل تشغيل أي أجهزة (نقطة وصول، تثبيت ذاكرة ROM، وما إلى ذلك) باستثناء ما هو موضّح أدناه، ولكن يتضمّن هذا التعديل تأخيرًا لمدة ساعة واحدة على الأقل ودورة تشغيل تؤدي إلى محو محتويات ذاكرة الوصول العشوائي.
- لا يمكن تعديل طريقة عمل الأجهزة المقاومة للتلاعب (مثل Titan M).
- يتعذّر قراءة ذاكرة الوصول العشوائي (RAM) للجهاز المباشر.
- لا يمكن الحصول على بيانات اعتماد المستخدم (رقم التعريف الشخصي أو النقش أو كلمة المرور) أو إدخالها بأي طريقة أخرى.

على سبيل المثال، سيكون تصميم الجهاز الذي يتضمّن جميع الأوصاف الواردة هنا ومتوافقًا معها متوافقًا مع [C-0-1].

‫9.10. سلامة الجهاز

تضمن المتطلبات التالية توفُّر الشفافية بشأن حالة سلامة الجهاز. عمليات تنفيذ الجهاز:

[C-0-1] يجب أن يتم الإبلاغ بشكل صحيح من خلال طريقة System API PersistentDataBlockManager.getFlashLockState() عما إذا كانت حالة برنامج الإقلاع تسمح بتثبيت صورة النظام.
[C-0-2] يجب أن يتوافق مع ميزة "التشغيل المتحقَّق منه" لضمان سلامة الجهاز.

إذا تم إطلاق عمليات تنفيذ الأجهزة بدون توفير إمكانية "التشغيل المتحقّق منه" في إصدار سابق من Android ولم يكن من الممكن إضافة إمكانية استخدام هذه الميزة من خلال تحديث برنامج النظام، يجوز إعفاؤها من هذا الشرط.

"التشغيل المتحقّق منه" هي ميزة تضمن سلامة برنامج الجهاز. إذا كانت عمليات تنفيذ الأجهزة تتيح هذه الميزة، فإنّها:

[C-1-1] يجب الإعلان عن علامة ميزة النظام الأساسي android.software.verified_boot.
[C-1-2] يجب إجراء عملية التحقّق في كل تسلسل تشغيل.
‫[C-1-3] يجب بدء عملية التحقّق من مفتاح أمان ثابت للأجهزة يمثّل أساس الثقة، ثم الانتقال إلى قسم النظام.
[C-1-4] يجب تنفيذ كل مرحلة من مراحل التحقّق للتأكّد من سلامة جميع وحدات البايت في المرحلة التالية وصحتها قبل تنفيذ الرمز في المرحلة التالية.
[C-1-5] يجب استخدام خوارزميات تحقّق بقوة الخوارزميات الحالية التي توصي بها NIST لخوارزميات التجزئة (SHA-256) وأحجام المفاتيح العامة (RSA-2048).
[C-1-6] يجب ألا يسمح الجهاز بإكمال عملية التشغيل عند تعذُّر إثبات صحة النظام، إلا إذا وافق المستخدم على محاولة التشغيل على أي حال، وفي هذه الحالة، يجب عدم استخدام البيانات من أي وحدات تخزين لم يتم إثبات صحتها.
[C-1-7] يجب ألا يسمح بتعديل الأقسام التي تم التحقّق منها على الجهاز إلا إذا فتح المستخدم برنامج التشغيل بشكل صريح.
[C-1-8] يجب استخدام مساحة تخزين مقاومة للتلاعب: لتخزين ما إذا كان برنامج الإقلاع غير مقفل. تعني مساحة التخزين المقاومة للتلاعب أنّه يمكن لبرنامج إقلاع التحقّق من داخل نظام التشغيل Android مما إذا تم التلاعب بمساحة التخزين.
‫[C-1-9] يجب أن يطلب الجهاز من المستخدم تأكيدًا ماديًا أثناء استخدامه قبل السماح بالانتقال من وضع قفل برنامج الإقلاع إلى وضع فتح قفل برنامج الإقلاع.
[C-1-10] يجب تنفيذ ميزة الحماية من الرجوع إلى إصدار أقدم للأقسام التي يستخدمها Android (مثل أقسام التشغيل والنظام) واستخدام مساحة تخزين مقاومة للتلاعب لتخزين البيانات الوصفية المستخدَمة لتحديد الحد الأدنى المسموح به من إصدار نظام التشغيل.
[C-1-11] يجب محو جميع بيانات المستخدمين بشكل آمن أثناء فتح برنامج الإقلاع وقفل الجهاز، وذلك وفقًا للبند 9.12. حذف البيانات (بما في ذلك قسم بيانات المستخدم وأي مساحات NVRAM).
[C-1-14] يجب التحقّق من التوقيع مرة واحدة على الأقل في كل عملية تشغيل للحِزم المدرَجة في القائمة المسموح بها والتي تم إدراجها على أنّها require-strict-signature في إعدادات النظام.
[C-SR-2] يُنصح بشدة بالتحقّق من جميع ملفات APK الخاصة بالتطبيقات ذات الامتيازات باستخدام سلسلة ثقة تستند إلى الأقسام المحمية من خلال ميزة "التشغيل المتحقّق منه".
[C-SR-3] يُنصح بشدة بالتحقّق من أي عناصر قابلة للتنفيذ يتم تحميلها بواسطة تطبيق ذي امتيازات من خارج ملف APK الخاص به (مثل الرمز الذي يتم تحميله ديناميكيًا أو الرمز المجمّع) قبل تنفيذها، أو يُنصح بشدة بعدم تنفيذها على الإطلاق.
يجب تنفيذ ميزة الحماية من الرجوع إلى إصدار أقدم لأي مكوّن يتضمّن برامج ثابتة مستمرة (مثل المودم والكاميرا)، ويجب استخدام مساحة تخزين مقاومة للتلاعب لتخزين البيانات الوصفية المستخدَمة في تحديد الحد الأدنى للإصدار المسموح به.

يوفر مشروع مفتوح المصدر لنظام Android (AOSP) عملية تنفيذ مفضّلة لهذه الميزة في مستودع external/avb/، ويمكن دمجها في برنامج إقلاع المستخدَم لتحميل Android.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية التحقّق من محتوى الملف على أساس كل صفحة، يجب أن تستوفي ما يلي:

‫[C-2-1] إتاحة إمكانية التحقّق من صحة محتوى الملفات باستخدام التشفير بدون قراءة الملف بأكمله
[C-2-2] يجب ألا يسمح بنجاح طلبات القراءة على ملف محمي عندما لا يتم التحقّق من صحة المحتوى المقروء وفقًا لما ورد في [C-2-1] أعلاه.
[C-2-4] يجب عرض المجموع الاختباري للملف في O(1) للملفات المفعّلة.

إذا تم إطلاق عمليات تنفيذ الأجهزة بدون إمكانية التحقّق من محتوى الملفات باستخدام مفتاح موثوق به على إصدار Android أقدم، ولم يكن من الممكن إضافة دعم لهذه الميزة من خلال تحديث برنامج النظام، يجوز إعفاؤها من هذا الشرط. يوفّر مشروع Android مفتوح المصدر الأساسي عملية تنفيذ مفضّلة لهذه الميزة استنادًا إلى ميزة fs-verity في نواة Linux.

‫9.11. المفاتيح وبيانات الاعتماد

يتيح نظام Android Keystore لمطوّري التطبيقات تخزين مفاتيح التشفير في حاوية واستخدامها في عمليات التشفير من خلال KeyChain API أو Keystore API. عمليات تنفيذ الجهاز:

[C-0-1] يجب السماح باستيراد أو إنشاء 8,192 مفتاحًا على الأقل.
[C-0-2] يجب أن تتضمّن مصادقة شاشة القفل فاصلًا زمنيًا بين المحاولات غير الناجحة. إذا كان n هو عدد المحاولات الفاشلة، يجب ألا يقل الفاصل الزمني عن 30 ثانية إذا كان 9 < n < 30. بالنسبة إلى n > 29، يجب أن تكون قيمة الفاصل الزمني 30*2^floor((n-30)/10) ثانية على الأقل أو 24 ساعة على الأقل، أيهما أصغر.
يجب عدم وضع حدّ لعدد المفاتيح التي يمكن إنشاؤها.

عندما يتيح تنفيذ الجهاز استخدام شاشة قفل آمنة، يجب أن يستوفي ما يلي:

[C-1-1] يجب أن يتم الاحتفاظ بنسخة احتياطية من تنفيذ ملف تخزين المفاتيح في بيئة تنفيذ معزولة.

[C-1-2] يجب أن تتضمّن عمليات تنفيذ خوارزميات التشفير RSA وAES وECDSA وECDH (في حال توفُّر IKeyMintDevice) و3DES وHMAC ودوال التجزئة MD5 وSHA-1 وعائلة SHA-2 خوارزميات التشفير ودوال التجزئة المطلوبة من خلال إصدار IKeyMintDevice أو IKeymasterDevice المتوافق لتوفير الدعم المناسب للخوارزميات المتوافقة مع نظام Android Keystore في منطقة معزولة بشكل آمن عن الرمز البرمجي الذي يتم تنفيذه على النواة وما فوقها. يجب أن تحظر ميزة العزل الآمن جميع الآليات المحتملة التي يمكن من خلالها أن يصل رمز kernel أو userspace إلى الحالة الداخلية للبيئة المعزولة، بما في ذلك الوصول المباشر إلى الذاكرة (DMA). يستوفي مشروع Android المفتوح المصدر (AOSP) هذا الشرط باستخدام تنفيذ Trusty، ولكن هناك خيارات بديلة أخرى، مثل حلول أخرى تستند إلى ARM TrustZone أو تنفيذ آمن راجعه طرف ثالث لعزل مناسب يستند إلى برنامج مراقبة الأجهزة الافتراضية.

[C-1-3] يجب إجراء مصادقة شاشة القفل في بيئة التنفيذ المعزولة، ولا يُسمح باستخدام المفاتيح المرتبطة بالمصادقة إلا عند نجاحها. يجب تخزين بيانات اعتماد شاشة القفل بطريقة لا تسمح إلا لبيئة التنفيذ المعزولة بإجراء مصادقة شاشة القفل. يوفر مشروع Android مفتوح المصدر طبقة تجريد الأجهزة (HAL) في Gatekeeper وTrusty، ويمكن استخدامهما لاستيفاء هذا الشرط.
[C-1-4] يجب أن تتوافق مع مصادقة المفتاح حيث يكون مفتاح التوقيع الخاص بالمصادقة محميًا بواسطة أجهزة آمنة ويتم التوقيع في أجهزة آمنة. يجب منع استخدام مفاتيح توقيع شهادة التصديق كمعرّفات دائمة للأجهزة.

ملاحظة: لاستيفاء هذا الشرط، يجب مشاركة مفتاح التصديق نفسه لرمز تخزين تعريفي معيّن ما لم يتم إنتاج 100,000 وحدة على الأقل من رمز التخزين التعريفي هذا. إذا تم إنتاج أكثر من 100,000 وحدة من رمز التخزين التعريفي هذا، يمكن استخدام مفتاح مختلف لكل مجموعة من 100,000 وحدة بعد ذلك. بدلاً من ذلك، يمكن استخدام حل Remote Key Provisioning لتوفير مفاتيح تصديق قصيرة الأمد للجهاز.

[C-1-5] يجب أن يسمح للمستخدم باختيار مهلة السكون للانتقال من حالة فتح القفل إلى حالة قفل الشاشة، مع توفير حد أدنى مسموح به للمهلة يصل إلى 15 ثانية. قد لا تتضمّن أجهزة السيارات التي تقفل الشاشة عند إيقاف تشغيل الوحدة الرئيسية أو تبديل المستخدم إعدادات مهلة السكون.
[C-1-6] يجب أن يتوافق مع الإصدار 3.0 من IKeymasterDevice أو الإصدارات الأحدث، أو الإصدار 1 من IKeyMintDevice أو الإصدارات الأحدث.

[C-SR-1] يُنصح بشدة بفرض حد أدنى للفاصل الزمني بين المحاولات الفاشلة الفريدة لطرق المصادقة الأساسية (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور)، وذلك استنادًا إلى ما يلي:

عدد المحاولات الفريدة غير الناجحة	الحدّ الأدنى لمهلة انتهاء الوقت
0-4	0
5	دقيقة واحدة
6	5 دقائق
7	‫15 دقيقة
8	30 دقيقة
9	‫90 دقيقة
10	4 ساعات
11	12 ساعة
12	24 ساعة
13	4 أيام
14	13 يومًا
15	41 يومًا
16	‫123 يومًا
17	سنة واحدة
18	‫3 سنوات
19	9 سنوات

‫9.11.1. تأمين قفل الجهاز والمصادقة والأجهزة الافتراضية

يتّبع تطبيق AOSP نموذج مصادقة متعدد المستويات، حيث يمكن دعم المصادقة الأساسية المستندة إلى عامل المعرفة إما من خلال مقياس حيوي ثانوي قوي أو من خلال طُرق ثالثية أضعف.

عمليات تنفيذ الجهاز:

[C-SR-1] يُنصح بشدة بتحديد إحدى الطرق التالية فقط كطريقة مصادقة أساسية:
- رقم تعريف شخصي
- كلمة مرور أبجدية رقمية
- نمط تمرير سريع على شبكة من 3 × 3 نقاط بالضبط
يُرجى العِلم أنّ طرق المصادقة المذكورة أعلاه يُشار إليها في هذا المستند على أنّها طرق المصادقة الأساسية المقترَحة.
[C-0-1] يجب الحدّ من عدد محاولات المصادقة الأساسية الفاشلة.
[C-SR-5] يُنصح بشدة بتطبيق حدّ أقصى يبلغ 20 محاولة فاشلة للمصادقة الأساسية، وفي حال موافقة المستخدمين على الميزة وتفعيلها، يجب إجراء "إعادة الضبط على الإعدادات الأصلية" بعد تجاوز الحدّ الأقصى لعدد محاولات المصادقة الأساسية الفاشلة.

إذا كانت عمليات تنفيذ الأجهزة تضبط رقم تعريف شخصي رقميًا كطريقة المصادقة الأساسية المقترَحة، يجب استيفاء ما يلي:

[C-SR-6] يُنصح بشدة بأن يتضمّن رقم التعريف الشخصي 6 أرقام على الأقل، أو ما يعادل ذلك من 20 بت من البيانات العشوائية.
[C-SR-7] يُنصح بشدة بعدم السماح بإدخال رقم التعريف الشخصي تلقائيًا بدون تفاعل المستخدم إذا كان طوله أقل من 6 أرقام، وذلك لتجنُّب الكشف عن طول رقم التعريف الشخصي.

إذا أضافت عمليات تنفيذ الأجهزة طرق المصادقة الأساسية المقترَحة أو عدّلتها واستخدمت طريقة مصادقة جديدة كوسيلة آمنة لقفل الشاشة، يجب أن تستوفي طريقة المصادقة الجديدة ما يلي:

[C-2-1] يجب أن تكون طريقة مصادقة المستخدم على النحو الموضّح في اشتراط مصادقة المستخدم لاستخدام المفتاح.

إذا أضافت عمليات تنفيذ الأجهزة طرق مصادقة أو عدّلتها لفتح قفل الشاشة استنادًا إلى سر معروف واستخدمت طريقة مصادقة جديدة يتم التعامل معها على أنّها طريقة آمنة لقفل الشاشة، يجب استيفاء ما يلي:

‫[C-3-1] يجب أن يكون حجم البيانات العشوائية لأقصر طول مسموح به للإدخالات أكبر من 10 بت.
‫[C-3-2] يجب أن يكون الحد الأقصى للإنتروبيا لجميع المدخلات الممكنة أكبر من 18 بت.
[C-3-3] يجب ألا تحل طريقة المصادقة الجديدة محل أي من طرق المصادقة الأساسية الموصى بها (أي رقم التعريف الشخصي أو النقش أو كلمة المرور) التي تم تنفيذها وتوفيرها في مشروع Android مفتوح المصدر (AOSP).
[C-3-4] يجب إيقاف طريقة المصادقة الجديدة عندما يضبط تطبيق وحدة التحكّم بسياسة الجهاز (DPC) سياسة متطلبات كلمة المرور من خلال DevicePolicyManager.setRequiredPasswordComplexity() باستخدام ثابت تعقيد أكثر تقييدًا من PASSWORD_COMPLEXITY_NONE أو من خلال طريقة DevicePolicyManager.setPasswordQuality() باستخدام ثابت أكثر تقييدًا من PASSWORD_QUALITY_BIOMETRIC_WEAK.
[C-3-5] يجب أن تعود طرق المصادقة الجديدة إلى طرق المصادقة الأساسية المقترَحة (أي رقم التعريف الشخصي أو النمط أو كلمة المرور) مرة واحدة كل 72 ساعة أو أقل، أو أن توضّح للمستخدم أنّ بعض البيانات لن يتم الاحتفاظ بنسخة احتياطية منها للحفاظ على خصوصية بياناته.

إذا أضافت عمليات تنفيذ الأجهزة طرق المصادقة الأساسية المقترَحة أو عدّلتها لفتح قفل الشاشة واستخدام طريقة مصادقة جديدة تستند إلى المقاييس الحيوية ليتم التعامل معها كطريقة آمنة لقفل الشاشة، يجب أن تستوفي الطريقة الجديدة ما يلي:

[C-4-1] يجب استيفاء جميع المتطلبات الموضّحة في الفقرة 7.3.10 للفئة 1 (المعروفة سابقًا باسم الراحة).
[C-4-2] يجب توفير آلية احتياطية لاستخدام إحدى طرق المصادقة الأساسية الموصى بها والتي تستند إلى سر معروف.
يجب تعطيل [C-4-3] والسماح فقط بالمصادقة الأساسية الموصى بها لفتح قفل الشاشة عندما يضبط تطبيق وحدة التحكّم بسياسة الجهاز (DPC) سياسة ميزة قفل الشاشة من خلال استدعاء الطريقة DevicePolicyManager.setKeyguardDisabledFeatures()، مع أي من العلامات الحيوية المرتبطة (أي KEYGUARD_DISABLE_BIOMETRICS أو KEYGUARD_DISABLE_FINGERPRINT أو KEYGUARD_DISABLE_FACE أو KEYGUARD_DISABLE_IRIS).

إذا لم تستوفِ طرق المصادقة بالمقاييس الحيوية متطلبات الفئة 3 (المعروفة سابقًا باسم قوية) كما هو موضّح في الفقرة 7.3.10:

[C-5-1] يجب إيقاف الطريقتين إذا كان تطبيق وحدة التحكُّم بسياسة الجهاز (DPC) قد ضبط سياسة جودة متطلبات كلمة المرور باستخدام DevicePolicyManager.setRequiredPasswordComplexity()‎ مع مجموعة تعقيد أكثر تقييدًا من PASSWORD_COMPLEXITY_LOW أو باستخدام الطريقة DevicePolicyManager.setPasswordQuality()‎ مع ثابت جودة أكثر تقييدًا من PASSWORD_QUALITY_BIOMETRIC_WEAK.
[C-5-2] يجب أن يُطلب من المستخدم إكمال عملية المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) على النحو الموضّح في [C-1-7] و[C-1-8] في الفقرة 7.3.10.
[C-5-3] يجب عدم التعامل مع الطرق على أنّها شاشة قفل آمنة، ويجب أن تستوفي المتطلبات التي تبدأ بـ C-8 في هذا القسم أدناه.

إذا أضافت عمليات تنفيذ الأجهزة طرق المصادقة أو عدّلتها لفتح شاشة القفل، وكانت طريقة المصادقة الجديدة تستند إلى رمز مميّز مادي أو الموقع الجغرافي، يجب استيفاء ما يلي:

[C-6-1] يجب أن تتضمّن آلية احتياطية لاستخدام إحدى طرق المصادقة الأساسية الموصى بها والتي تستند إلى سر معروف وتستوفي المتطلبات التي تؤهّلها لأن تُعتبَر شاشة قفل آمنة.
[C-6-2] يجب إيقاف الطريقة الجديدة وعدم السماح إلا بإحدى طرق المصادقة الأساسية الموصى بها لفتح قفل الشاشة عندما يضبط تطبيق "وحدة التحكّم بسياسة الجهاز" (DPC) السياسة باستخدام أحد الخيارَين التاليَين:
- الطريقة DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS)
- الطريقة DevicePolicyManager.setPasswordQuality() التي تتضمّن ثابت جودة أكثر تقييدًا من PASSWORD_QUALITY_NONE.
- الطريقة DevicePolicyManager.setRequiredPasswordComplexity() التي تتضمّن مجموعة تعقيد أكثر تقييدًا من PASSWORD_COMPLEXITY_NONE.
[C-6-3] يجب أن يُطلب من المستخدم إثبات هويته باستخدام إحدى طرق المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) مرة واحدة على الأقل كل 4 ساعات أو أقل. عندما يستوفي الرمز المميّز الفعلي متطلبات عمليات تنفيذ TrustAgent في C-X، يتم تطبيق قيود المهلة المحدّدة في [C-9-5] بدلاً من ذلك.
[C-6-4] يجب ألا يتم التعامل مع الطريقة الجديدة على أنّها شاشة قفل آمنة، ويجب أن تلتزم بالقيود الواردة في الفقرة C-8 أدناه.

[C-7-1] يجب أن يتضمّن الجهاز إشارة واضحة في قائمة الإعدادات وعلى شاشة القفل عندما يتم تأجيل قفل الجهاز أو عندما يمكن فتح قفله باستخدام الوكيل المعتمد. على سبيل المثال، يستوفي AOSP هذا الشرط من خلال عرض وصف نصي لـ "إعداد القفل التلقائي" و "القفل الفوري باستخدام زر التشغيل" في قائمة الإعدادات ورمز مميّز على شاشة القفل.
[C-7-2] يجب احترام جميع واجهات برمجة التطبيقات الخاصة بوكيل الثقة وتنفيذها بالكامل في الفئة DevicePolicyManager، مثل الثابت KEYGUARD_DISABLE_TRUST_AGENTS.
[C-7-3] يجب عدم تنفيذ وظيفة TrustAgentService.addEscrowToken() بالكامل على جهاز يُستخدم كجهاز شخصي أساسي (مثل جهاز محمول باليد)، ولكن يجوز تنفيذ الوظيفة بالكامل على الأجهزة التي تتم مشاركتها عادةً (مثل Android TV أو جهاز Automotive).
[C-7-4] يجب تشفير جميع الرموز المميّزة المخزّنة التي أضافها TrustAgentService.addEscrowToken().
[C-7-5] يجب عدم تخزين مفتاح التشفير أو رمز الإيداع على الجهاز نفسه الذي يتم استخدام المفتاح عليه. على سبيل المثال، يُسمح باستخدام مفتاح مخزّن على هاتف لفتح قفل حساب مستخدم على تلفزيون. بالنسبة إلى أجهزة Automotive، لا يُسمح بتخزين رمز الإيداع على أي جزء من المركبة.
[C-7-6] يجب إبلاغ المستخدم بالآثار الأمنية قبل تفعيل الرمز المميز للاسترداد من أجل فك تشفير وحدة تخزين البيانات.
[C-7-7] يجب توفير آلية احتياطية لاستخدام إحدى طرق المصادقة الأساسية المقترَحة.
[C-7-9] يجب أن يُطلب من المستخدم إكمال إحدى طرق المصادقة الأساسية المقترَحة (مثل رقم التعريف الشخصي أو النمط أو كلمة المرور) كما هو موضّح في [C-1-7] و[C-1-8] في القسم 7.3.10، ما لم يكن هناك ما يدعو إلى القلق بشأن سلامة المستخدم (مثل تشتيت انتباه السائق).
[C-7-10] يجب ألا يتم التعامل معه على أنّه شاشة قفل آمنة، ويجب أن يلتزم بالقيود الواردة في الفقرة C-8 أدناه.
[C-7-11] يجب عدم السماح لـ TrustAgents على الأجهزة الشخصية الأساسية (مثل الأجهزة المحمولة) بفتح قفل الجهاز، ولا يمكن استخدامها إلا لإبقاء الجهاز الذي تم فتح قفله في حالة عدم القفل لمدة تصل إلى 4 ساعات كحد أقصى. يتوافق التنفيذ التلقائي لواجهة TrustManagerService في مشروع Android مفتوح المصدر (AOSP) مع هذا الشرط.
[C-7-12] يجب استخدام قناة اتصال آمنة من ناحية التشفير (مثل UKEY2) لتمرير رمز الإيداع من جهاز التخزين إلى جهاز الاختبار.

إذا أضافت عمليات تنفيذ الأجهزة طرق مصادقة أو عدّلتها لفتح شاشة القفل التي ليست شاشة قفل آمنة كما هو موضّح أعلاه، واستخدمت طريقة مصادقة جديدة لفتح Keyguard، يجب استيفاء ما يلي:

[C-8-1] يجب إيقاف الطريقة الجديدة عندما يضبط تطبيق "وحدة التحكّم بسياسة الجهاز" (DPC) سياسة جودة كلمة المرور باستخدام الطريقة DevicePolicyManager.setPasswordQuality() مع ثابت جودة أكثر تقييدًا من PASSWORD_QUALITY_NONE أو باستخدام الطريقة DevicePolicyManager.setRequiredPasswordComplexity() مع ثابت تعقيد أكثر تقييدًا من PASSWORD_COMPLEXITY_NONE.
[C-8-2] يجب ألا يعيدوا ضبط مؤقتات انتهاء صلاحية كلمات المرور التي تم ضبطها بواسطة DevicePolicyManager.setPasswordExpirationTimeout().
[C-8-3] يجب ألا يتم توفير واجهة برمجة تطبيقات يمكن أن تستخدمها تطبيقات تابعة لجهات خارجية لتغيير حالة القفل.

إذا كانت عمليات تنفيذ الأجهزة تسمح للتطبيقات بإنشاء شاشات عرض افتراضية ثانوية ولا تتيح أحداث الإدخال المرتبطة بها، مثل تلك التي تتم عبر VirtualDeviceManager، يجب أن:

[C-9-1] يجب قفل شاشات العرض الثانوية الافتراضية هذه عندما تكون شاشة العرض التلقائية للجهاز مقفلة، وفتح قفل شاشات العرض الثانوية الافتراضية هذه عندما تكون شاشة العرض التلقائية للجهاز مفتوحة.

إذا كانت عمليات تنفيذ الأجهزة تسمح للتطبيقات بإنشاء شاشات عرض افتراضية ثانوية وتتيح أحداث الإدخال المرتبطة بها، مثل تلك التي تتم من خلال VirtualDeviceManager، يجب أن تستوفي ما يلي:

[C-10-1] يجب أن تتوافق مع حالات قفل منفصلة لكل جهاز افتراضي
[C-10-2] تمت إزالة هذا الشرط في الإصدار 16 من نظام التشغيل Android.
[C-10-3] تمت إزالة هذا الشرط في الإصدار 16 من نظام التشغيل Android.
[C-10-4] يجب قفل جميع الشاشات عندما يبدأ المستخدم عملية الحظر، بما في ذلك من خلال أداة الحظر التي يجب توفيرها للأجهزة المحمولة (راجِع الفقرة 2.2.5[9.11/H-1-2]).
[C-10-5] يجب توفير نُسخ منفصلة من الأجهزة الافتراضية لكل مستخدم
‫[C-10-6] يجب إيقاف بث التطبيقات على النحو الموضّح في DevicePolicyManager.setNearbyAppStreamingPolicy.
[C-10-7] تمت إزالة هذا الشرط في الإصدار Android 16.
[C-10-11] يجب إيقاف واجهة مستخدم المصادقة على الأجهزة الافتراضية، بما في ذلك إدخال عامل المعرفة وطلب المقاييس الحيوية
[C-10-12] تمت إزالة هذا الشرط في الإصدار Android 16.
[C-10-13] يجب عدم استخدام حالة قفل الجهاز الافتراضي كإذن مصادقة للمستخدم مع نظام Android Keystore. يمكنك الاطّلاع على KeyGenParameterSpec.Builder.setUserAuthentication*.
[C-10-14] يجب توفير أداة تحكّم للمستخدمين تتيح مشاركة الحافظة بين الأجهزة قبل مشاركة بيانات الحافظة بين الأجهزة المادية والأجهزة الافتراضية، وذلك إذا كان الجهاز يتيح استخدام حافظة مشتركة.
[C-10-15] يجب عرض إشعارات عند الوصول إلى بيانات الحافظة على كل من الجهاز الذي تم الوصول إليها منه والجهاز الذي تم نسخ البيانات منه.

عندما تسمح عمليات تنفيذ الأجهزة للمستخدم بنقل عامل المعرفة الخاص بالمصادقة الأساسية من جهاز مصدر إلى جهاز مستهدف، مثلاً لإعداد الجهاز المستهدف في البداية، يجب أن تستوفي ما يلي:

[C-11-1] يجب تشفير عامل المعرفة بضمانات حماية مشابهة لتلك الموضّحة في التقرير الموجز حول الأمان الخاص بخدمة Google Cloud Key Vault عند نقل عامل المعرفة من الجهاز المصدر إلى الجهاز المستهدف، وذلك بطريقة لا يمكن من خلالها فك تشفير عامل المعرفة عن بُعد أو استخدامه لفتح قفل أي من الجهازين عن بُعد.
[C-11-2] يجب أن يطلب الجهاز المصدر من المستخدم تأكيد عامل المعرفة الخاص بالجهاز المصدر قبل نقل عامل المعرفة إلى الجهاز المستهدف.
‫[C-11-3] يجب أن يطلب الجهاز المستهدف الذي لا يتضمّن أي عامل معرفة تم ضبطه للمصادقة الأساسية من المستخدم تأكيد عامل المعرفة الذي تم نقله على الجهاز المستهدف قبل ضبط عامل المعرفة هذا كعامل معرفة أساسي للمصادقة على الجهاز المستهدف وقبل إتاحة أي بيانات تم نقلها من جهاز مصدر.

إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة قفل آمنة وتشمل وكيل ثقة واحدًا أو أكثر، وتستدعي واجهة برمجة التطبيقات TrustAgentService.grantTrust() System مع العلامة FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE، فإنّها:

[C-12-1] يجب عدم استدعاء grantTrust() مع العلامة إلا عند الاتصال بجهاز فعلي قريب مزوّد بشاشة قفل خاصة به، وعندما يثبت المستخدم هويته من خلال شاشة القفل هذه. يمكن للأجهزة القريبة استخدام آليات اكتشاف الجهاز أثناء حمله أو على المعصم بعد أن يفتح المستخدم قفل الجهاز لمرة واحدة لاستيفاء شرط مصادقة المستخدم.
[C-12-2] يجب أن تضع عملية تنفيذ الجهاز في حالة TrustState.TRUSTABLE عندما تكون الشاشة مطفأة (مثل الضغط على زر أو انتهاء مهلة العرض) ولم يلغِ TrustAgent الثقة. يستوفي مشروع AOSP هذا الشرط.
[C-12-3] يجب ألا يتم نقل الجهاز من الحالة TrustState.TRUSTABLE إلى الحالة TrustState.TRUSTED إلا إذا كان TrustAgent لا يزال يمنح الثقة استنادًا إلى المتطلبات الواردة في [C-12-1].

[C-12-4] يجب استدعاء TrustManagerService.revokeTrust() إذا كانت عمليات التنفيذ لا تستخدم تحديد المدى الدقيق والآمن من ناحية التشفير على النحو المحدّد في [C-12-5]:
- بعد 24 ساعة كحد أقصى من منح الثقة، أو
- بعد مرور 8 ساعات من عدم النشاط
- إذا كانت عمليات التنفيذ لا تستخدم تحديد المدى الدقيق والآمن من ناحية التشفير على النحو المحدّد في [C-12-5]، عندما يتم فقدان الاتصال الأساسي بالجهاز المادي القريب.

[C-12-5] يجب أن تستخدم عمليات التنفيذ التي تعتمد على تحديد المدى الآمن والدقيق لاستيفاء متطلبات [C-12-4] أحد الحلول التالية:
- عمليات التنفيذ باستخدام تقنية النطاق الفائق العرض (UWB):
  - يجب استيفاء متطلبات التوافق والشهادة والدقة والمعايرة الخاصة بتقنية النطاق الفائق العرض (UWB) الموضّحة في 7.4.9.
  - يجب استخدام أحد أوضاع أمان P-STS المدرَجة في 7.4.9.
- عمليات التنفيذ التي تستخدم ميزة "الاتصال المباشر بمحطات لاسلكية مجاورة" عبر Wi-Fi:
  - يجب أن يستوفي متطلبات الدقة الواردة في 2.2.1 [7.4.2.5/H-SR-1]، وأن يستخدم النطاق الترددي 160 ميغاهرتز (أو أعلى)، وأن يتّبع خطوات إعداد القياس المحدّدة في معايرة الاستشعار عن القُرب.
  - يجب استخدام Secure LTF كما هو محدّد في IEEE 802.11az.

إذا كانت عمليات تنفيذ الأجهزة تسمح للتطبيقات بإنشاء شاشات عرض افتراضية ثانوية وتتيح أحداث الإدخال المرتبطة بها، مثل تلك التي تتم من خلال VirtualDeviceManager، ولم يتم وضع علامة VIRTUAL_DISPLAY_FLAG_SECURE على شاشات العرض، فإنّها:

[C-13-8] يجب حظر بدء الأنشطة التي تتضمّن السمة android:canDisplayOnRemoteDevices أو البيانات الوصفية android.activity.can_display_on_remote_devices التي تم ضبطها على "false" على الجهاز الافتراضي.
[C-13-9] يجب حظر الأنشطة التي لا تتيح البث بشكل صريح والتي تشير إلى أنّها تعرض محتوى حسّاسًا، بما في ذلك من خلال SurfaceView#setSecure وFLAG_SECURE، من بدء التشغيل على الجهاز الافتراضي.

إذا كانت عمليات تنفيذ الأجهزة تتيح حالات طاقة منفصلة للشاشة من خلال DeviceStateManager وتتيح حالات قفل منفصلة للشاشة من خلال KeyguardDisplayManager، يجب أن تستوفي ما يلي:

[C-SR-2] يُنصح بشدة باستخدام بيانات اعتماد تستوفي المتطلبات المحدّدة في القسم 9.11.1 أو بيانات اعتماد بيومترية تستوفي على الأقل مواصفات الفئة 1 المحدّدة في القسم 7.3.10 للسماح بفتح القفل بشكل مستقل عن شاشة الجهاز التلقائية.
[C-SR-3] يُنصح بشدة بفرض قيود على فتح قفل شاشة العرض المنفصلة من خلال مهلة عرض محدّدة.
[C-SR-4] يُنصح بشدة بالسماح للمستخدم بقفل جميع الشاشات على مستوى العالم من خلال وضع "الحظر" من الجهاز المحمول الأساسي.

‫9.11.2. StrongBox

يتيح نظام Android Keystore لمطوّري التطبيقات تخزين مفاتيح التشفير في معالج آمن مخصّص، بالإضافة إلى بيئة التنفيذ المعزولة الموضّحة أعلاه. يُطلق على هذا المعالج الآمن المخصّص اسم StrongBox. تحدّد المتطلبات من C-1-3 إلى C-1-11 أدناه المتطلبات التي يجب أن يستوفيها الجهاز ليكون مؤهلاً كجهاز StrongBox.

عمليات تنفيذ الأجهزة التي تتضمّن معالجًا آمنًا مخصّصًا:

[C-SR-1] يُنصح بشدة بتوفير StrongBox. من المرجّح أن يصبح استخدام StrongBox شرطًا في إصدار مستقبلي.

إذا كانت عمليات تنفيذ الأجهزة تتوافق مع StrongBox، يجب أن:

[C-1-1] يجب الإفصاح عن FEATURE_STRONGBOX_KEYSTORE.
‫[C-1-2] يجب توفير جهاز آمن مخصّص يُستخدم لتخزين keystore ولإجراء مصادقة آمنة للمستخدم. ويمكن استخدام الأجهزة المخصّصة الآمنة لأغراض أخرى أيضًا.
[C-1-3] يجب أن تتضمّن وحدة معالجة مركزية منفصلة لا تشارك أي ذاكرة تخزين مؤقت أو ذاكرة وصول عشوائي ديناميكية (DRAM) أو معالجات مساعدة أو موارد أساسية أخرى مع معالج التطبيقات (AP).
[C-1-4] يجب التأكّد من أنّ أي أجهزة طرفية تتم مشاركتها مع نقطة الوصول لا يمكنها تغيير معالجة StrongBox بأي شكل من الأشكال، أو الحصول على أي معلومات من StrongBox. يجوز لموفّر التطبيق إيقاف إمكانية الوصول إلى StrongBox أو حظرها.
[C-1-5] يجب أن يتضمّن ساعة داخلية بدقة معقولة (‎+/- 10%) محصّنة ضد التلاعب بها من خلال نقطة الوصول.
[C-1-6] يجب أن يتضمّن مولّد أرقام عشوائية حقيقية ينتج ناتجًا غير متوقّع وموزّعًا بشكل منتظم.
[C-1-7] يجب أن تتوفّر فيها مقاومة للتلاعب، بما في ذلك مقاومة الاختراق المادي والتشويش.
[C-1-8] يجب أن تتوفّر فيه مقاومة القنوات الجانبية، بما في ذلك مقاومة تسريب المعلومات عبر القنوات الجانبية المتعلقة بالطاقة والتوقيت والإشعاع الكهرومغناطيسي والإشعاع الحراري.
[C-1-9] يجب توفير مساحة تخزين آمنة تضمن سرية المحتوى وسلامته وأصالته واتساقه وحداثته. يجب ألا يكون من الممكن قراءة وحدة التخزين أو تعديلها، إلا بما تسمح به واجهات برمجة التطبيقات StrongBox.

لإثبات الامتثال للمتطلبات من [C-1-3] إلى [C-1-9]، يجب أن تتضمّن عمليات تنفيذ الأجهزة ما يلي:

[C-1-10] يجب أن يتضمّن الجهاز الأجهزة التي تم اعتمادها وفقًا لملف حماية الدوائر المتكاملة الآمنة BSI-CC-PP-0084-2014 أو BSI-CC-PP-0117-2022، أو أن يتم تقييمه من خلال مختبر اختبار معتمد على المستوى الوطني يشتمل على تقييم الثغرات الأمنية ذات احتمالية الهجوم العالية وفقًا لمعايير التطبيق المشترك لاحتمالية الهجوم على البطاقات الذكية.
[C-1-11] يجب أن يتضمّن البرنامج الثابت الذي يتم تقييمه من خلال مختبر اختبار معتمد على المستوى الوطني تقييمًا لنقاط الضعف التي قد تؤدي إلى هجمات محتملة عالية وفقًا لمعايير التطبيق المشترك لاحتمال الهجوم على البطاقات الذكية.
‫[C-SR-2] يُنصح بشدة بتضمين الأجهزة التي تم تقييمها باستخدام معيار أمان ومستوى تقييم ضمان (EAL) 5، مع إضافة AVA_VAN.5. من المرجّح أن تصبح شهادة الاعتماد بمستوى تقييم الأمان 5 من المتطلبات في إصدار مستقبلي.
[C-SR-3] يُنصح بشدة بتوفير مقاومة للهجمات الداخلية (IAR)، ما يعني أنّه لا يمكن لأي شخص من الداخل لديه إذن بالوصول إلى مفاتيح توقيع البرامج الثابتة إنشاء برامج ثابتة تؤدي إلى تسريب أسرار StrongBox أو تجاوز متطلبات الأمان الوظيفي أو السماح بالوصول إلى بيانات المستخدمين الحسّاسة بأي طريقة أخرى. الطريقة المقترَحة لتنفيذ IAR هي السماح بتحديثات البرامج الثابتة فقط عند تقديم كلمة مرور المستخدم الأساسي من خلال IAuthSecret HAL.

‫9.11.3. بيانات اعتماد الهوية

يتم تحديد نظام بيانات اعتماد الهوية وتحقيقه من خلال تنفيذ جميع واجهات برمجة التطبيقات في حزمة android.security.identity.*. تتيح واجهات برمجة التطبيقات هذه لمطوّري التطبيقات تخزين مستندات تعريف هوية المستخدم واستردادها. عمليات تنفيذ الجهاز:

[C-SR-1] يُنصح بشدة بتنفيذ نظام بيانات اعتماد الهوية.

في حال تنفيذ أنظمة بيانات اعتماد الهوية على الأجهزة، يجب أن تتضمّن ما يلي:

[C-1-1] يجب أن تعرض الطريقة IdentityCredentialStore#getInstance() قيمة غير خالية.
[C-1-2] يجب تنفيذ نظام بيانات اعتماد الهوية (مثل واجهات برمجة التطبيقات android.security.identity.*) باستخدام رمز يتواصل مع تطبيق موثوق به في منطقة معزولة بشكل آمن عن الرمز الذي يتم تنفيذه على النواة وما فوقها. يجب أن يحظر العزل الآمن جميع الآليات المحتملة التي قد يصل من خلالها رمز kernel أو رمز مساحة المستخدم إلى الحالة الداخلية للبيئة المعزولة، بما في ذلك الوصول المباشر إلى الذاكرة (DMA).
[C-1-3] يجب تنفيذ عمليات التشفير اللازمة لتنفيذ نظام بيانات الاعتماد (مثل واجهات برمجة التطبيقات android.security.identity.*) بالكامل في التطبيق الموثوق به، ويجب ألا تغادر مواد المفتاح الخاص بيئة التنفيذ المعزولة أبدًا إلا إذا كانت مطلوبة تحديدًا من خلال واجهات برمجة التطبيقات ذات المستوى الأعلى (مثل طريقة createEphemeralKeyPair()).
[C-1-4] يجب تنفيذ التطبيق الموثوق به بطريقة لا تتأثر فيها خصائص الأمان (على سبيل المثال، لا يتم إصدار بيانات الاعتماد إلا عند استيفاء شروط التحكّم في الوصول، ولا يمكن إنشاء رموز MAC لبيانات عشوائية) حتى إذا كان Android يتصرف بشكل غير سليم أو تم اختراقه.

يوفّر مشروع Android مفتوح المصدر نموذجًا مرجعيًا لتطبيق موثوق به (libeic) يمكن استخدامه لتنفيذ نظام "مستند تعريف الهوية".

‫9.12. حذف البيانات

جميع عمليات تنفيذ الأجهزة:

[C-0-1] يجب توفير آلية للمستخدمين لإجراء "إعادة الضبط على الإعدادات الأصلية".
[C-0-2] يجب حذف جميع البيانات في نظام ملفات بيانات المستخدمين عند إجراء "إعادة الضبط على الإعدادات الأصلية".
[C-0-3] يجب حذف البيانات بطريقة تستوفي معايير الصناعة ذات الصلة، مثل معيار NIST SP800-88، عند إجراء "إعادة ضبط المصنع".
[C-0-4] يجب أن يتم تشغيل عملية "إعادة الضبط على الإعدادات الأصلية" المذكورة أعلاه عند استدعاء واجهة برمجة التطبيقات DevicePolicyManager.wipeData() من خلال تطبيق "وحدة التحكّم بسياسة الجهاز" الخاص بالمستخدم الأساسي.
يمكن أن يوفّر خيارًا سريعًا لمحو البيانات لا ينفّذ سوى محوًا منطقيًا للبيانات.

‫9.13. وضع التشغيل الآمن

يتوفّر في Android "وضع التشغيل الآمن" الذي يتيح للمستخدمين تشغيل الجهاز في وضع لا يسمح إلا بتشغيل تطبيقات النظام المثبّتة مسبقًا، ويتم فيه إيقاف جميع التطبيقات التابعة لجهات خارجية. يوفّر هذا الوضع، المعروف باسم "وضع التشغيل الآمن"، للمستخدم إمكانية إلغاء تثبيت التطبيقات التابعة لجهات خارجية التي قد تتسبّب بضرر.

تتضمّن عمليات تنفيذ الأجهزة ما يلي:

[C-SR-1] يُنصح بشدة بتفعيل "وضع التشغيل الآمن".

في حال تنفيذ الأجهزة "وضع التشغيل الآمن"، يجب أن تستوفي ما يلي:

[C-1-1] يجب أن يوفّر الجهاز للمستخدم خيارًا للدخول إلى "وضع التشغيل الآمن" بطريقة لا يمكن مقاطعتها من خلال التطبيقات التابعة لجهات خارجية المثبَّتة على الجهاز، إلا إذا كان التطبيق التابع لجهة خارجية هو "وحدة التحكُّم بسياسة الجهاز" وتم ضبط العلامة UserManager.DISALLOW_SAFE_BOOT على "صحيح".
[C-1-2] يجب أن يوفّر الوضع الآمن للمستخدم إمكانية إلغاء تثبيت أي تطبيقات تابعة لجهات خارجية.
يجب أن يوفّر للمستخدم خيارًا للدخول إلى "الوضع الآمن" من قائمة التشغيل باستخدام سير عمل يختلف عن سير عمل التشغيل العادي.

‫9.14. عزل أنظمة المركبات

من المتوقّع أن تتبادل أجهزة Android Automotive البيانات مع الأنظمة الفرعية المهمة في المركبة باستخدام طبقة تجريد الأجهزة في المركبة لإرسال الرسائل وتلقّيها عبر شبكات المركبة، مثل ناقل CAN.

يمكن تأمين عملية تبادل البيانات من خلال تنفيذ ميزات أمان أسفل طبقات إطار عمل Android لمنع التفاعل الضار أو غير المقصود مع هذه الأنظمة الفرعية.

‫9.15. خطط الاشتراك

تشير "خطط الاشتراك" إلى تفاصيل خطة علاقة الفوترة التي يقدّمها مشغّل شبكة جوّال من خلال SubscriptionManager.setSubscriptionPlans().

جميع عمليات تنفيذ الأجهزة:

[C-0-1] يجب عرض خطط الاشتراك في تطبيق مشغّل شبكة الجوّال الذي قدّمها في الأصل فقط.
[C-0-2] يجب عدم الاحتفاظ بنسخة احتياطية أو تحميل خطط الاشتراك عن بُعد.
[C-0-3] يجب السماح فقط بتجاوز القيود، مثل SubscriptionManager.setSubscriptionOverrideCongested()، من تطبيق مشغّل شبكة الجوّال الذي يوفّر حاليًا خطط اشتراك صالحة.

‫9.16. نقل بيانات التطبيق

إذا كانت عمليات تنفيذ الأجهزة تتضمّن إمكانية نقل البيانات من جهاز إلى آخر ولا تقتصر على بيانات التطبيق التي يتم نسخها إلى ما تم ضبطه من قِبل مطوّر التطبيق في ملف البيان من خلال السمة android:fullBackupContent، فإنّها:

[C-1-1] يجب عدم بدء عمليات نقل بيانات التطبيق من الأجهزة التي لم يضبط فيها المستخدم مصادقة أساسية كما هو موضح في ‫9.11.1 قفل الشاشة والمصادقة الآمنة.
[C-1-2] يجب تأكيد عملية المصادقة الأساسية بشكل آمن على الجهاز المصدر، والتأكّد من نية المستخدم في نسخ البيانات على الجهاز المصدر قبل نقل أي بيانات.
[C-1-3] يجب استخدام تصديق مفتاح الأمان للتأكّد من أنّ الجهاز المصدر والجهاز المستهدف في عملية نقل البيانات من جهاز إلى آخر هما جهازان شرعيان من أجهزة Android وبرنامج الإقلاع فيهما مقفل.
[C-1-4] يجب ألا يتم نقل بيانات التطبيق إلا إلى التطبيق نفسه على جهاز الاختبار، مع اسم الحزمة وشهادة التوقيع نفسها.
[C-1-5] يجب عرض إشارة في قائمة الإعدادات إلى أنّه تم نقل البيانات من الجهاز المصدر إلى الجهاز الجديد باستخدام ميزة نقل البيانات من جهاز إلى جهاز. يجب ألا يتمكّن المستخدم من إزالة هذا المؤشر.

‫9.17. ‫Android Virtualization Framework

تتيح واجهات برمجة التطبيقات الخاصة بإطار عمل المحاكاة الافتراضية لنظام التشغيل Android (AVF) (android.system.virtualmachine.*) للتطبيقات إنشاء أجهزة افتراضية (VM) محمية (pVM) وغير محمية (non-pVM) على الجهاز فقط، ويتم تحميل وتشغيل الملفات الثنائية الأصلية كحمولة.

إذا ضبطت عمليات تنفيذ الأجهزة FEATURE_VIRTUALIZATION_FRAMEWORK على true، ستكون على النحو التالي:

[C-1-1] يجب التأكّد من أنّ android.system.virtualmachine.VirtualMachineManager.getCapabilities() تعرض إحدى القيم التالية:
- CAPABILITY_PROTECTED_VM
- CAPABILITY_NON_PROTECTED_VM
- CAPABILITY_NON_PROTECTED_VM | CAPABILITY_PROTECTED_VM

‫9.18. التحقق من مطوّر البرامج

عمليات تنفيذ الأجهزة التي تحدّد مستوى واجهة برمجة التطبيقات 36.1 أو مستوى أعلى:

قد تتضمّن دعمًا لخدمة التحقّق من المطوّرين للتأكّد من أنّ التطبيقات صادرة عن مطوّر معروف.

عمليات تنفيذ الأجهزة التي تحدّد مستوى واجهة برمجة التطبيقات 36.1 أو مستوى أعلى وتضبط أداة التحقّق الخاصة بالمطوّرين من خلال تحديد config_developerVerificationServiceProviderPackageName في config.xml:

[9.18/C-1-1] يجب استدعاء android.content.pm.verify.developer.DeveloperVerifierService الذي تم ضبطه لكل عملية تثبيت لحزمة تطبيق، بما في ذلك عمليات التثبيت الجديدة وتحديثات التطبيقات الحالية.

عمليات تنفيذ الأجهزة التي تحدّد مستوى واجهة برمجة التطبيقات 36.1 أو مستوى أعلى:

يمكن أن يضبط MAY أيضًا مفوّضًا لضبط السياسة النشطة من خلال تحديد config_developerVerificationPolicyDelegatePackageName في config.xml.

في حال ضبط أداة التحقّق من المطورين، يجب أن تتضمّن عمليات تنفيذ الجهاز ما يلي:

‫[9.18/C-2-1] يجب ألا تسمح إلا لأداة التحقّق من المطوّر أو المفوّض الذي تم إعداده بتحديد سياسة التثبيت على النحو المحدّد في android.content.pm.PackageInstaller.

إذا تم استدعاء أداة التحقّق كجزء من جلسة تثبيت حزمة، يجب أن تتضمّن عمليات تنفيذ الجهاز ما يلي:

[9.18/C-3-1] يجب منع تثبيت حزمة تطبيق في الحالات التالية:
- يتعذّر إثبات هوية المطوّر أثناء عملية التثبيت.
- تم ضبط سياسة التحقّق من هوية المطوِّر لجلسة التثبيت على أي قيمة أخرى غير DEVELOPER_VERIFICATION_POLICY_NONE.
- ما لم تنطبق الفقرة 9.18/C-3-2 أو الفقرة 9.18/C-3-3.

[9.18/C-3-2] يجب عدم منع تثبيت حزمة تطبيق بغض النظر عن السياسة أو حالة التحقّق في الحالات التالية:
- يتم تثبيت الحزمة من خلال أداة Android Debug Bridge (ADB).
- الحزمة هي أداة التحقّق التي أعدّها المطوّر أو أداة التثبيت الخاصة بها.

[9.18/C-3-3] يجب ألا يتم منع تثبيت حزمة تطبيق عند استيفاء جميع الشروط التالية:
- تم ضبط السياسة على DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_WARN أو DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_OPEN.
- يتم تسجيل حالة التحقّق على أنّها غير مكتملة.
- يشير برنامج التثبيت إلى أنّ المستخدم طلب صراحةً مواصلة عملية التثبيت من خلال إرسال القيمة DEVELOPER_VERIFICATION_USER_RESPONSE_INSTALL_ANYWAY.

قد يسمح بتثبيت حِزمة تطبيق بغض النظر عن السياسة أو حالة التحقّق لعمليات التثبيت التي يبدأها مالك الجهاز على جهاز مُدار أو مالك الملف الشخصي على ملف شخصي مُدار، ولكن يُنصح بشدة بمنع عمليات التثبيت كما هو موضّح في 9.18/C-3-1.

10. اختبار توافق البرامج

يجب أن تجتاز عمليات تنفيذ الأجهزة جميع الاختبارات الموضّحة في هذا القسم. ومع ذلك، يُرجى العِلم أنّه لا توجد حزمة اختبار برامج شاملة تمامًا. لهذا السبب، يُنصح بشدة مصنّعي الأجهزة بإجراء أقل عدد ممكن من التغييرات على التنفيذ المرجعي والمفضّل لنظام Android المتاح من "مشروع مفتوح المصدر لنظام Android". سيؤدي ذلك إلى تقليل خطر حدوث أخطاء تؤدي إلى عدم التوافق وتتطلّب إعادة العمل والتحديثات المحتملة للجهاز.

10.1. مجموعة أدوات اختبار التوافق

عمليات تنفيذ الجهاز:

[C-0-1] يجب اجتياز مجموعة أدوات اختبار التوافق (CTS) لنظام التشغيل Android المتاحة من "المشروع المفتوح المصدر لنظام Android"، وذلك باستخدام برنامج الشحن النهائي على الجهاز.
‫[C-0-2] يجب ضمان التوافق في حالات الغموض في مجموعة اختبار التوافق (CTS) وفي أي عمليات إعادة تنفيذ لأجزاء من رمز المصدر المرجعي.

تم تصميم مجموعة اختبار التوافق (CTS) ليتم تشغيلها على جهاز فعلي. وكما هو الحال مع أي برنامج، قد يحتوي CTS على أخطاء. سيتم إصدار إصدارات مختلفة من مجموعة اختبار التوافق بشكل مستقل عن تعريف التوافق هذا، وقد يتم إصدار مراجعات متعددة من مجموعة اختبار التوافق لنظام التشغيل Android 17.

عمليات تنفيذ الجهاز:

[C-0-3] يجب اجتياز أحدث إصدار من مجموعة أدوات اختبار التوافق (CTS) المتوفّرة عند اكتمال برنامج الجهاز.
يجب استخدام التنفيذ المرجعي في شجرة Android Open Source قدر الإمكان.

10.2. أداة التحقّق في مجموعة أدوات اختبار التوافق (CTS)

يتم تضمين أداة CTS Verifier في مجموعة أدوات اختبار التوافق، وهي مصمّمة ليستخدمها عامل تشغيل بشري لاختبار الوظائف التي لا يمكن اختبارها باستخدام نظام آلي، مثل الأداء السليم للكاميرا وأجهزة الاستشعار.

عمليات تنفيذ الجهاز:

[C-0-1] يجب تنفيذ جميع حالات الاختبار السارية في أداة CTS Verifier بشكل صحيح.

يحتوي تطبيق CTS Verifier على اختبارات للعديد من أنواع الأجهزة، بما في ذلك بعض الأجهزة الاختيارية.

عمليات تنفيذ الجهاز:

[C-0-2] يجب اجتياز جميع الاختبارات الخاصة بالمكونات المادية المتوفرة في الجهاز، على سبيل المثال، إذا كان الجهاز مزودًا بمقياس تسارع، يجب أن ينفّذ بشكل صحيح حالة اختبار مقياس التسارع في CTS Verifier.

يمكن تخطّي أو حذف حالات الاختبار للميزات التي تم تصنيفها على أنّها اختيارية في "مستند تعريف التوافق".

[C-0-2] يجب أن يتم تشغيل أداة CTS Verifier بشكل صحيح على كل جهاز وكل إصدار، كما هو موضّح أعلاه. ومع ذلك، بما أنّ العديد من الإصدارات متشابهة جدًا، لا يُتوقّع من مطوّري الأجهزة تشغيل أداة CTS Verifier بشكل صريح على الإصدارات التي تختلف فقط بطرق بسيطة. وعلى وجه التحديد، يمكن أن تتجاهل عمليات تنفيذ الأجهزة التي تختلف عن عملية تنفيذ اجتازت اختبار CTS Verifier مجموعة اللغات المضمّنة والعلامات التجارية وما إلى ذلك.

11. البرامج القابلة للتحديث

[C-0-1] يجب أن تتضمّن عمليات تنفيذ الأجهزة آلية لاستبدال نظام التشغيل بأكمله. ولا يشترط أن تنفّذ الآلية ترقيات "مباشرة"، أي قد يكون من الضروري إعادة تشغيل الجهاز. يمكن استخدام أي طريقة، شرط أن تتمكّن من استبدال كل البرامج المثبّتة مسبقًا على الجهاز. على سبيل المثال، يمكن استيفاء هذا الشرط باتّباع أي من الطرق التالية:
- عمليات التنزيل "عبر شبكة غير سلكية (OTA)" مع تحديث بلا إنترنت من خلال إعادة التشغيل
- التحديثات "المربوطة" عبر USB من جهاز كمبيوتر مضيف
- التحديثات "بلا إنترنت" من خلال إعادة التشغيل والتحديث من ملف على وحدة تخزين قابلة للإزالة
[C-0-2] يجب أن تتيح آلية التحديث المستخدَمة إجراء التحديثات بدون محو بيانات المستخدم. أي أنّ آلية التحديث يجب أن تحافظ على البيانات الخاصة بالتطبيق والبيانات المشترَكة للتطبيق. يُرجى العِلم أنّ برنامج Android الأساسي يتضمّن آلية تحديث تستوفي هذا الشرط.
[C-0-3] يجب توقيع التحديث بالكامل، ويجب أن تتحقّق آلية التحديث على الجهاز فقط من التحديث والتوقيع باستخدام مفتاح عام مخزَّن على الجهاز.
[C-SR-1] يُنصح بشدة باستخدام آلية التوقيع لتجزئة التحديث باستخدام SHA-256 والتحقّق من صحة التجزئة باستخدام المفتاح العام من خلال خوارزمية ECDSA NIST P-256.

إذا كانت عمليات تنفيذ الجهاز تتضمّن إمكانية استخدام اتصال بيانات غير محدود، مثل 802.11 أو ملف تعريف شبكة المنطقة الشخصية (PAN) عبر البلوتوث، فإنّها:

[C-1-1] يجب أن يتيح تنزيل تحديثات عبر الأثير (OTA) مع إمكانية التحديث بلا إنترنت من خلال إعادة التشغيل.

يجب أن تتحقّق عمليات تنفيذ الأجهزة من أنّ صورة النظام متطابقة ثنائيًا مع النتيجة المتوقّعة بعد إجراء تحديث عبر الأثير. إنّ تنفيذ تحديثات OTA المستندة إلى الحظر في مشروع مفتوح المصدر لنظام Android، والذي تمت إضافته منذ الإصدار 5.1 من نظام Android، يستوفي هذا الشرط.

يجب أيضًا أن تتوافق عمليات تنفيذ الأجهزة مع تحديثات النظام من النوع أ/ب. تنفّذ حزمة AOSP هذه الميزة باستخدام طبقة تجريد الأجهزة (HAL) الخاصة بالتحكّم في عملية التشغيل.

إذا تم رصد خطأ في تنفيذ جهاز بعد طرحه ولكن خلال فترة عمره المعقولة المحددة بالتشاور مع فريق توافق Android، وكان هذا الخطأ يؤثر في توافق التطبيقات التابعة لجهات خارجية، فسيتم اتّخاذ الإجراءات التالية:

[C-2-1] على مطوّر الجهاز تصحيح الخطأ من خلال توفير تحديث للبرنامج يمكن تطبيقه وفقًا للآلية الموضّحة أعلاه.

يتضمّن نظام التشغيل Android ميزات تتيح لتطبيق "مالك الجهاز" (في حال توفّره) التحكّم في تثبيت تحديثات النظام. إذا كان النظام الفرعي لتحديث النظام للأجهزة يبلغ عن android.software.device_admin، يعني ذلك ما يلي:

[C-3-1] يجب تنفيذ السلوك الموضّح في فئة SystemUpdatePolicy.

12. سجلّ التغييرات في المستند

بدءًا من Android 16، لن يتم الاحتفاظ بسجلّ تغييرات بشكل منفصل. يتم تمييز جميع التغييرات من الإصدار السابق داخل هذا المستند.

13. التواصل معنا

يمكنك الانضمام إلى منتدى توافق Android وطرح أسئلة للحصول على توضيحات أو الإبلاغ عن أي مشاكل تعتقد أنّ المستند لا يغطّيها.

تعريف التوافق مع الإصدار 17 من نظام التشغيل Android [معاينة] تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

1. مقدمة

‫1.1 بنية المستند

‫1.1.1. المتطلبات حسب نوع الجهاز

‫1.1.2. معرّف المتطلبات

‫1.1.3. معرّف المتطلبات في القسم 2

2. أنواع الأجهزة

‫2.1 إعدادات الجهاز

2.2. متطلبات الأجهزة المحمولة

2.2.1. الأجهزة

2.2.2. وسائط متعددة

2.2.3. برامج

2.2.3. برامج

‫2.2.4. الأداء والطاقة

‫2.2.5. نموذج الأمان

حظر المشاركة من خلال الإعدادات

‫2.2.6. التوافق مع أدوات وخيارات المطوّرين

‫2.2.7. فئة أداء الوسائط على الأجهزة الجوّالة

2.2.7.1. الوسائط

2.2.7.2. الكاميرا

‫2.2.7.3. الأجهزة

‫2.2.7.4. الأداء

‫2.2.7.5. الرسومات

‫2.3. متطلبات التلفزيون

‫1.3.2. الأجهزة

‫2.3.2. وسائط متعددة

‫2.3.3. برامج

‫2.3.4. الأداء والطاقة

‫2.3.5. نموذج الأمان

‫2.3.6. التوافق مع أدوات وخيارات المطوّرين

‫2.4. متطلبات المشاهدة

2.4.1. الأجهزة

‫2.4.2. وسائط متعددة

‫2.4.3. برامج

2.4.4. الأداء والطاقة

2.4.5. نموذج الأمان

‫2.5. متطلبات السيارات

‫2.5.1. الأجهزة

‫2.5.2. وسائط متعددة

‫2.5.3. برامج

2.5.4. الأداء والطاقة

‫2.5.5. نموذج الأمان

2.5.6. التوافق مع أدوات وخيارات المطوّرين

‫2.6. متطلبات الجهاز اللوحي

2.6.1. الأجهزة

‫2.6.2. نموذج الأمان

‫2.6.2. برامج

3- برامج

‫3.1. التوافق مع واجهة برمجة التطبيقات المُدارة

3.1.1. إضافات Android

3.1.2. مكتبة Android

3.2. توافق واجهة برمجة التطبيقات غير الصارم

3.2.1. الأذونات

‫3.2.2. مَعلمات الإنشاء

‫3.2.3. توافق النية

3.2.3.1. أهداف التطبيقات الشائعة

‫3.2.3.2. حلّ النية

‫3.2.3.3. مساحات أسماء Intent

‫3.2.3.4. Broadcast Intents

‫3.2.3.5. Conditional Application Intents

‫3.2.4. الأنشطة على شاشات العرض الثانوية/المتعددة

‫3.3. توافق واجهة برمجة التطبيقات الأصلية

‫3.3.1. واجهات التطبيق الثنائية

‫3.3.2. توافق الرمز البرمجي الأصلي ARM بنظام 32 بت

‫3.4. توافق الويب

‫3.4.1. توافق WebView

‫3.4.2. توافق المتصفّح

‫3.5. توافُق سلوك واجهة برمجة التطبيقات

‫3.5.1. قيود التطبيق

‫3.5.2. إسبات التطبيق

‫3.6. مساحات أسماء واجهة برمجة التطبيقات

‫3.7. التوافق مع وقت التشغيل

‫3.8. توافق واجهة المستخدم

‫3.8.1. مشغّل التطبيقات (الشاشة الرئيسية)

‫3.8.2. التطبيقات المصغَّرة

‫3.8.3. الإشعارات

‫3.8.3.1. عرض الإشعارات

‫3.8.3.2. خدمة متتبِّع الإشعارات

‫3.8.3.3. وضع "عدم الإزعاج" / وضع الأولوية

‫3.8.3.4. حماية الإشعارات الحسّاسة

تعريف التوافق مع الإصدار 17 من نظام التشغيل Android [معاينة]