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

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

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

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

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

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

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

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

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

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

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

يجب أن يشتمل على شاشة مضمّنة أو منفذ إخراج الفيديو مثل VGA أو HDMI أو منفذ لاسلكي للعرض.
يجب أن يفصح عن الميزتين android.software.leanback وandroid.hardware.type.television.

يشير جهاز Android Watch إلى ارتداء جهاز Android حول ارتداء الجهاز على الجسم ربما على المعصم، و:

يجب أن يحتوي على شاشة بطول قطري محدد يتراوح بين 1.1 و2.5 بوصة.
يجب أن يفصح عن الميزة android.hardware.type.watch.
يجب أن يكون متوافقًا مع uiMode = UI_mode_TYPE_watch.

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

يجب أن تحتوي على شاشة بطول قطري فعلي يساوي 6 بوصات أو أكبر منه.
يجب أن تفصح عن الميزة android.hardware.type.automotive.
يجب أن يكون متوافقًا مع uiMode = UI_mode_TYPE_CAR.
يجب أن تتوافق عمليات تنفيذ Android Automotive مع جميع واجهات برمجة التطبيقات العلنية في مساحة الاسم android.car.*.

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

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

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

الفئة	الميزة	القسم	حمل الكاميرا يدويًا	التلفزيون	مشاهدة	Automotive	غير ذلك
الإدخال	لوحة التحكّم	7.2.2. التنقّل بدون لمس		يجب
	الشاشة التي تعمل باللمس	7.2.4. إدخال البيانات على الشاشة التي تعمل باللمس	يجب		يجب		يجب
	الميكروفون	7.8.1. الميكروفون	يجب	يجب	يجب	يجب	يجب
أجهزة الاستشعار	مقياس التسارع	7.3.1 مقياس التسارع	يجب		يجب		يجب
أجهزة الاستشعار	نظام تحديد المواقع العالمي (GPS)	7.3.3. نظام تحديد المواقع العالمي (GPS)	يجب			يجب
إمكانية الاتصال	Wi-Fi	7.4.2 معيار IEEE 802.11	يجب	يجب		يجب	يجب
	اتصال Wi-Fi مباشر	7.4.2.1. اتصال Wi-Fi مباشر	يجب	يجب			يجب
	البلوتوث	7.4.3. البلوتوث	يجب	يجب	يجب	يجب	يجب
	بلوتوث منخفض الطاقة	7.4.3. البلوتوث	يجب	يجب	يجب	يجب	يجب
	راديو الجوال	7.4.5 الحد الأدنى لإمكانات الشبكة				يجب
	وضع USB للأجهزة الملحقة/المضيف	7.7. USB	يجب			يجب	يجب
الإخراج	منافذ إخراج الصوت و/أو مكبّر الصوت	7.8.2: مصدر إخراج الصوت	يجب	يجب		يجب	يجب

3- البرامج

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

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

يجب أن تدعم عمليات تنفيذ الأجهزة/تحافظ على جميع الفئات والطرق والعناصر المرتبطة التي تم وضع علامة عليها بالتعليق التوضيحي TestApi (@TestApi).

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

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

3.1.1. إضافات Android

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

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

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

3.2.1. الأذونات

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

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

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

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

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

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

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

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

يجب أن تشمل عمليات تنفيذ الأجهزة تطبيقات Android الأساسية على النحو المناسب أو على مكوِّن ينفِّذ أنماط النية نفسها المحدّدة في جميع مكوّنات النشاط أو الخدمة لتطبيقات Android الأساسية هذه التي عُرضت تطبيقات أخرى، بشكلٍ ضمني أو صريح، من خلال السمة android:exported.

3.2.3.2. دقة الأهداف

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

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

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

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

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

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

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

3.2.3.4. نوايا البث

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

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

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

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

يجب أن يلتزم بالهدف android.settings.home_SETTINGS من أجل عرض قائمة إعدادات التطبيق التلقائية للشاشة الرئيسية، إذا كانت عملية تنفيذ الجهاز تشير إلى android.software.home_screen.
يجب توفير قائمة إعدادات تطلب الإذن android.provider.Technical.ACTION_CHANGE_DEFAULT الإذن لعرض مربّع حوار لتغيير تطبيق الرسائل القصيرة SMS التلقائي، في حال كانت إعدادات الجهاز تعرض رسالة android.hardware.telephony.
يجب أن تلتزم بالهدف android.settings.NFC_PAYMENT_SETTINGS لعرض قائمة إعدادات التطبيق التلقائية لميزة "انقر وادفع"، إذا كانت إعدادات الجهاز تعرض android.hardware.nfc.hce.
يجب أن يلتزم بالهدف android.telecom.action.CHANGE_DEFAULT_DIALER لعرض مربّع حوار للسماح للمستخدم بتغيير تطبيق "الهاتف" التلقائي، في حال كانت تقارير تنفيذ الجهاز android.hardware.telephony .

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

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

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

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

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

يجب أن يتيح هذا الإذن تشغيل الرموز البرمجية التي يتم تشغيلها في البيئة المُدارة لاستدعاء الرموز الأصلية، وذلك باستخدام دلالات واجهة Java الأصلية (JNI) العادية.
يجب أن تكون هذه التطبيقات متوافقة مع المصدر (أي العنوان) ومتوافقة مع النظام الثنائي (بالنسبة إلى واجهة التطبيق الثنائية (ABI)) مع كل مكتبة مطلوبة في القائمة أدناه.
يجب أن يتوافق مع واجهة التطبيق الثنائية (ABI) المكافئة 32 بت في حال توفُّر أي واجهة تطبيق ثنائية (ABI) 64 بت.
يجب أن يتم الإبلاغ بدقة عن واجهة التطبيق الثنائية (ABI) الأصلية التي يتوافق معها الجهاز، وذلك من خلال معلمات android.os.Build.SUPPORTED_ABIS وandroid.os.Build.SUPPORTED_32_BIT_ABIS وandroid.os.Build.SUPPORTED_64_BIT_ABIS، كل قائمة مفصولة بفواصل من واجهات ABI وترتيبها من الأكثر إلى الأقل تفضيلاً.
من خلال المَعلمات المذكورة أعلاه، يجب عدم الإبلاغ عن واجهات التطبيق الثنائية (ABI) سوى تلك الموثَّقة والموضّحة في أحدث إصدار من مستندات إدارة واجهة التطبيق الثنائية (ABI) في Android، كما يجب أن تشمل التوافق مع إضافة شريحة SIM المتقدّمة (المعروفة أيضًا باسم NEON).
يجب أن يتم إنشاؤه باستخدام رمز المصدر وملفات العناوين المتاحة في "مشروع مفتوح المصدر لنظام Android"

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

يجب أن تكون واجهات برمجة التطبيقات التالية التي تتضمّن رموزًا برمجية أصلية متاحة للتطبيقات التي تتضمّن رمزًا برمجيًا أصليًا:

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

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

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

قد تضيف عمليات تنفيذ الأجهزة مكتبات لا تتوافق مع بروتوكول AOSP وتعرضها مباشرةً كواجهة برمجة تطبيقات للتطبيقات التابعة لجهات خارجية، ولكن يجب أن تكون المكتبات الإضافية متوفّرة في /vendor/lib أو /vendor/lib64 ويجب إدراجها في /vendor/etc/public.libraries.txt .

تجدر الإشارة إلى أنّ عمليات تنفيذ الأجهزة يجب أن تتضمّن libGLESv3.so، وبالتالي، يجب تصدير جميع رموز الدوال OpenGL ES 3.1 وAndroid Extension Pack على النحو المحدَّد في إصدار NDK android-24. على الرغم من ضرورة توفُّر جميع الرموز، يجب تنفيذ الوظائف المعنيّة بالكامل فقط في إصدارات OpenGL ES والإضافات المتوافقة مع الجهاز.

3.3.1.1 مكتبات تصويرية

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

ويجب أن توفّر دائمًا مكتبة أصلية باسم libvulkan.so تصدِّر رموز الدوال لواجهة برمجة تطبيقات Vulkan 1.0 الأساسية بالإضافة إلى الإضافات VK_KHR_surface وVK_KHR_android_surface وVK_KHR_swapchain.

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

يجب الإبلاغ عن VkPhysicalDevices واحد أو أكثر من خلال مكالمة vkEnumeratePhysicalDevices.
يجب تنفيذ واجهة برمجة تطبيقات Vulkan 1.0 API بشكل كامل من VkPhysicalDevices مع تعداد.
يجب الإبلاغ عن العلامتين الصحيحتين للميزتَين PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL وPackageManager#FEATURE_VULKAN_HARDWARE_VERSION.
يجب تعداد الطبقات، المضمّنة في المكتبات الأصلية المسماة libVkLayer*.so في دليل المكتبة الأصلي لحزمة التطبيق، من خلال الدالتَين vkEnumerateInstanceLayerProperties وvkEnumerateDeviceLayerProperties في libvulkan.so.
يجب عدم تعداد الطبقات التي توفّرها المكتبات خارج حزمة التطبيق أو توفير طرق أخرى لتتبُّع أو اعتراض واجهة برمجة تطبيقات Vulkan، ما لم يكن التطبيق يحتوي على السمة android:debuggable=”true”.

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

يجب الإبلاغ عن القيمة 0 VkPhysicalDevices من خلال مكالمة vkEnumeratePhysicalDevices.
يجب عدم الإعلان عن أي من علامات ميزة Vulkan PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL وPackageManager#FEATURE_VULKAN_HARDWARE_VERSION.

3.3.2 التوافق مع الرموز البرمجية المستندة إلى معالجات ARM 32 بت

إنّ بنية ARMv8 تؤدي إلى إيقاف العديد من عمليات وحدة المعالجة المركزية (CPU)، بما في ذلك بعض العمليات المُستخدَمة في الرموز البرمجية الأصلية الحالية. على الأجهزة التي تتضمّن معالجات ARM بسعة 64 بت، يجب أن تظل العمليات التالية المتوقّفة متاحة لرمز ARM الأصلي لنظام 32 بت، إما من خلال دعم وحدة المعالجة المركزية الأصلية أو من خلال محاكاة البرامج:

تعليمات محو بيانات المستخدم وميزة SWPB
SETEND التعليمات
عمليات حاجز CP15ISB وCP15DSB وCP15DMB

تُستخدَم الإصدارات القديمة من Android NDK مع استخدام /proc/cpuinfo لاكتشاف ميزات وحدة المعالجة المركزية (CPU) من خلال الرموز البرمجية المستندة إلى معالجات ARM بتقنية 32 بت. للتوافق مع التطبيقات التي تم إنشاؤها باستخدام NDK هذا، يجب أن تتضمن الأجهزة الأسطر التالية في /proc/cpuinfo عند قراءتها باستخدام تطبيقات ARM 32 بت:

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

لا تسري هذه المتطلبات إلا عند قراءة /proc/cpuinfo باستخدام تطبيقات ARM 32 بت. "ينبغي" ألا تغيّر الأجهزة ملفات /proc/cpuinfo عند قراءتها باستخدام تطبيقات معالجات ARM أو تطبيقات أخرى غير ARM.

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

3.4.1. التوافق مع WebView

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

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

يجب أن تستند عمليات تنفيذ android.webkit.WebView على إصدار Chromium من "مشروع مفتوح المصدر لنظام Android" الرئيسي لنظام التشغيل Android 7.0. يتضمّن هذا الإصدار مجموعة محدَّدة من الوظائف وإصلاحات الأمان لمكوّن WebView.
يجب أن تكون سلسلة وكيل المستخدم التي تم الإبلاغ عنها من خلال WebView بهذا التنسيق:

Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD); wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- يجب أن تكون قيمة السلسلة $(VERSION) مماثلة لقيمة android.os.Build.VERSION.Release.
- يجب أن تكون قيمة السلسلة $(MODEL) مماثلة لقيمة android.os.Build.MODEL.
- يجب أن تكون قيمة السلسلة $(BUILD) مماثلة لقيمة android.os.Build.ID.
- يجب أن تكون قيمة السلسلة $(CHROMIUM_VER) هي إصدار Chromium في مشروع Android مفتوح المصدر الرئيسي.
- قد تحذف عمليات تنفيذ الأجهزة الأجهزة الجوّالة في سلسلة وكيل المستخدم.

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

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

قد تغفل عمليات تنفيذ Android TV وWatch وAndroid Automotive تطبيق المتصفِّح، ولكن يجب أن تتيح أنماط النية العامة كما هو موضَّح في القسم 3.2.3.1. ويجب أن تشتمل جميع الأنواع الأخرى من عمليات تنفيذ الجهاز على تطبيق متصفح مستقل لتصفح الويب العام للمستخدم.

وقد يستند المتصفح المستقل إلى تقنية متصفح أخرى غير WebKit. ومع ذلك، حتى في حال استخدام تطبيق متصفح بديل، يجب أن يكون المكوِّن android.webkit.WebView الذي يتم توفيره لتطبيقات الجهات الخارجية مستندًا إلى WebKit، كما هو موضح في القسم 3.4.1.

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

يجب أن يتيح تطبيق المتصفح المستقل (سواء كان يعتمد على تطبيق متصفح WebKit الرئيسي أو بديل من جهة خارجية) التوافق مع أكبر قدر ممكن من محتوى HTML5. الحد الأدنى، يجب أن تدعم عمليات تنفيذ الأجهزة كل واجهة من واجهات برمجة التطبيقات هذه المرتبطة بـ HTML5:

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

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

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

يجب ألا تغيّر الأجهزة سلوكًا أو دلالات النية العادية.
يجب ألا تغيّر الأجهزة دلالات دورة الحياة أو مراحل النشاط لنوع معيّن من مكوّنات النظام (مثل Service وactivity وContentProvider، وما إلى ذلك).
يجب ألا تغيّر الأجهزة دلالات الإذن العادي.

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

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

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

java.*
javax.*
شمس.*
android.*
com.android.*

تشمل التعديلات المحظورة ما يلي :

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

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

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

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

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

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

يجب أن تتوافق عمليات تنفيذ الأجهزة مع تنسيق Dalvik التنفيذي بالكامل (DEX) ومواصفات رمز بايت Dalvik ودلالات الدلالة. من المفترض أن يستخدم القائمون على تنفيذ الأجهزة ART، والتنفيذ الرئيسي لتنسيق Dalvik التنفيذي، ونظام إدارة حزمة تنفيذ المرجع.

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

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

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

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

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

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

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

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

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

3.8.3. الإشعارات

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

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

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

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

يتيح نظام التشغيل Android إرسال إشعارات متنوعة، مثل:

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

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

يشتمل Android على واجهات برمجة التطبيقات Notification Listener Service API التي تسمح للتطبيقات (بمجرد أن يفعّلها المستخدم صراحةً) بتلقّي نسخة من جميع الإشعارات عند نشرها أو تعديلها. يجب أن تؤدي عمليات تنفيذ الأجهزة إلى إرسال الإشعارات بشكل صحيح وفورية إلى جميع خدمات المستمعين التي ثبَّتها أو يفعّلها المستخدم، بما في ذلك جميع البيانات الوصفية المرتبطة بعنصر "الإشعار".

يجب أن تستوفي عمليات تنفيذ الأجهزة التي تتيح ميزة "عدم الإزعاج" (DND) المتطلبات التالية:

يجب تنفيذ نشاط يتجاوب مع الغرض ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS، والذي يجب أن يكون نشاطًا يمكن للمستخدم من خلاله منح إعدادات سياسة DND أو منعه من الوصول إلى عمليات ضبط سياسة DND.
يجب عرض قواعد DND التلقائية التي أنشأتها التطبيقات إلى جانب القواعد التي أنشأها المستخدم والقواعد المحدّدة مسبقًا عندما يوفّر تنفيذ الجهاز وسيلة للمستخدم لمنح تطبيقات الجهات الخارجية أو منعها من الوصول إلى إعدادات سياسة DND.
يجب أن يتم الالتزام بقيم suppressedVisualEffects التي تم تمريرها في NotificationManager.Policy، وإذا ضبط التطبيق أيًا من علامات SUPPRESSED_Effect_SCREEN_OFF أو SUPPRESSED_مرة_SCREEN_ON، يجب أن يوضح للمستخدم أنه تم منع التأثيرات المرئية في قائمة إعدادات DND.

3.8.4 بحث

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

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

"ينبغي" لعمليات تنفيذ أجهزة Android، وعمليات تنفيذ Android Automotive، استخدام مساعد على الجهاز للتعامل مع إجراء المساعدة.

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

3.8.5 الخبز المحمص

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

3.8.6. المظاهر

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

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

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

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

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

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

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

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

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

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

بما أنّ مفتاح تنقّل الدالة "الأخيرة" هو "اختياري"، يكون مطلوبًا تنفيذ شاشة النظرة العامة "اختياري" لعمليات تنفيذ Android Watch وAndroid Automotive، و"يُنصَح به" لأجهزة Android TV. لا تزال هناك طريقة للتبديل بين الأنشطة على تطبيقات Android Automotive.

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

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

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

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

يتيح Android استخدام إدارة الإدخال ومحرّري أساليب الإدخال التابعة لجهات خارجية. إنّ عمليات تنفيذ الأجهزة التي تسمح للمستخدمين باستخدام أساليب إدخال تابعة لجهات خارجية على الجهاز يجب أن تشير إلى أنّ ميزة النظام الأساسي android.software.input_methods متوافقة مع واجهات برمجة تطبيقات IME على النحو المحدّد في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

إنّ عمليات تنفيذ الأجهزة التي تُعلِن عن الميزة android.software.input_methods يجب أن توفّر آلية يمكن للمستخدم الوصول إليها لإضافة أساليب إدخال تابعة لجهات خارجية وضبطها. يجب أن تعرض عمليات تنفيذ الأجهزة واجهة الإعدادات استجابةً للغرض android.settings.INPUT_Method_SETTINGS.

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

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

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

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

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

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

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

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

يجب أن تكون أجهزة Android المحمولة متوافقة مع درجة لون البشرة والرموز التعبيرية المتنوعة المناسبة للعائلات على النحو المحدّد في تقرير Unicode الفني رقم 51.

يشمل نظام التشغيل Android توافقًا مع خط Roboto 2 بأوزان مختلفة، مثل sans-serif-thin و sans-serif-light وsans-serif-medium و sans-serif-blue وSans-serif-condensed" و sans-serif-condensed-light (والتي يجب تضمينها كلها للغات المتاحة على الجهاز والتغطية الكاملة لـ Unicode 7.0 للنطاقات اللاتينية واليونانية والسيريلية.

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

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

يمكن أن تشير التطبيقات إلى ما إذا كانت قادرة على العمل في وضع النوافذ المتعددة في ملف AndroidManifest.xml، إما بشكل صريح من خلال السمة android:resizeableActivity أو ضمنيًا من خلال تضمين targetSdkVersion > 24- ويجب عدم تشغيل التطبيقات التي تضبط هذه السمة صراحةً على "خطأ" في ملف البيان في وضع النوافذ المتعددة. يمكن تشغيل التطبيقات التي لا تضبط السمة في ملف البيان (targetSdkVersion < 24) في وضع النوافذ المتعددة، ولكن يجب أن يعرض النظام تحذيرًا بأنّ التطبيق قد لا يعمل على النحو المتوقَّع في وضع النوافذ المتعددة.
يجب ألا توفّر عمليات تنفيذ الأجهزة وضع تقسيم الشاشة أو وضع الشكل الحر إذا كان ارتفاع الشاشة وعرضها أقل من 440 بكسل مستقل الكثافة (dp).
يجب أن تتوافق عمليات تنفيذ الأجهزة بحجم الشاشة xlarge مع وضع الشكل الحر.
يجب أن تتوافق تطبيقات أجهزة Android TV مع وضع "نافذة ضمن النافذة" (PIP) في نوافذ متعددة، كما يجب وضع نافذة "نافذة ضمن النافذة" متعددة في أعلى يسار الشاشة عندما تكون ميزة "نافذة ضمن النافذة" مفعّلة.
في عمليات تنفيذ الأجهزة التي تتيح استخدام ميزة النوافذ المتعددة في وضع "نافذة ضمن النافذة (PIP)"، يجب أن يتم تخصيص نسبة 240x135 بكسل مستقل الكثافة على الأقل للنافذة ضمن النافذة (PIP).
إذا كان وضع "نافذة ضمن النافذة" (PIP) متاحًا، يجب استخدام مفتاح KeyEvent.KEYCODE_WINDOW للتحكّم في النافذة المتعددة داخل النافذة (PIP). وبخلاف ذلك، يجب أن يكون المفتاح متاحًا للنشاط الذي تعمل في المقدّمة.

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

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

3.9.1 توفير المتطلبات اللازمة للأجهزة

3.9.1.1 توفير المتطلبات اللازمة لمالك الجهاز

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

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

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

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

إذا أوضح تنفيذ الجهاز للمستخدم android.software.managed_users، يجب تسجيل تطبيق "وحدة التحكّم بسياسة الجهاز" (DPC) باعتباره مالك الملف الشخصي المُدار الجديد.

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

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

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

3.9.2 دعم الملفات الشخصية المُدارة

الأجهزة المتوافقة مع الملف الشخصي المُدار هي الأجهزة التي:

أوضح android.software.device_admin (راجع القسم 3.9 إدارة الأجهزة ).
إذا لم تكن أجهزة ذات ذاكرة وصول عشوائي (RAM) منخفضة (راجع القسم 7.6.1 ).
تخصيص وحدة تخزين داخلية (غير قابلة للإزالة) كوحدة تخزين مشتركة (راجع القسم 7.6.2 ).

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

تعريف علامة ميزة المنصة android.software.managed_users
دعم الملفات الشخصية المُدارة عبر واجهات برمجة تطبيقات android.app.admin.DevicePolicyManager.
يمكنك السماح بإنشاء ملف شخصي مُدار واحد فقط.
استخدام شارة رمز (على غرار شارة العمل الرئيسي الخاصة بخدمة AOSP) لتمثيل التطبيقات والتطبيقات المصغّرة المُدارة وغيرها من عناصر واجهة المستخدم التي تحمل شارة، مثل "التطبيقات المستخدَمة مؤخرًا" الإشعارات.
يمكنك عرض رمز إشعار (على نحو يشبه شارة العمل الأولي لإدارة AOSP) للإشارة إلى ما إذا كان المستخدم داخل تطبيق ملف شخصي مُدار.
عرض إشعار منبثق يشير إلى أنّ المستخدم ينتمي إلى الملف الشخصي المُدار في حال استيقاظ الجهاز ووقته (ACTION_USER_PRESENT) وأنّ التطبيق الذي يعمل في المقدّمة ضمن الملف الشخصي المُدار
عند وجود ملف شخصي مُدار، يجب عرض عناصر وظيفية مرئية في "أداة اختيار الهدف" للسماح للمستخدم بإعادة توجيه النية من الملف الشخصي المُدار إلى المستخدم الأساسي أو العكس، إذا فعّلتها "وحدة التحكّم بسياسة الجهاز".
عند وجود ملف شخصي مُدار، اعرض الخصائص التالية للمستخدم لكل من المستخدم الأساسي والملف الشخصي المُدار:
- فصل المستخدم الأساسي عن بيانات البطارية والموقع الجغرافي وبيانات الجوّال واستخدام مساحة التخزين، بالإضافة إلى حساب المستخدم الأساسي والملف الشخصي المُدار
- الإدارة المستقلة لتطبيقات الشبكة الافتراضية الخاصة المثبَّتة ضمن المستخدم الأساسي أو الملف الشخصي المُدار
- إدارة مستقلة للتطبيقات المثبّتة ضمن المستخدم الأساسي أو الملف الشخصي المُدار
- إدارة مستقلة للحسابات ضمن الملف الشخصي المُدار أو المستخدم الأساسي.
تأكَّد من أنّ تطبيقات الاتصال وجهات الاتصال والمراسلة المثبَّتة مسبقًا يمكنها البحث عن معلومات المتصل والبحث عنها من الملف الشخصي المُدار (إن وُجد) إلى جانب المعلومات الواردة في الملف الشخصي الأساسي، إذا سمحت "وحدة التحكّم في سياسة الجهاز" بذلك. عند عرض جهات الاتصال من الملف الشخصي المُدار في سجلّ المكالمات المثبَّت مسبقًا وواجهة المستخدم أثناء المكالمة والإشعارات التي تكون قيد التقدّم أو المكالمات الفائتة وجهات الاتصال وتطبيقات المراسلة، يجب وضع الشارة نفسها المستخدَمة للإشارة إلى تطبيقات الملف الشخصي المُدارة.
يجب أن تتأكد من توافقه مع جميع متطلبات الأمان السارية على جهاز تم تفعيل ميزة العديد من المستخدمين فيه (راجِع القسم 9.5)، حتى إذا لم يتم احتساب الملف الشخصي المُدار كمستخدم آخر إلى جانب المستخدم الأساسي.
إتاحة إمكانية تحديد شاشة قفل منفصلة تستوفي المتطلبات التالية لمنح إذن الوصول إلى التطبيقات التي يتم تشغيلها في ملف شخصي مُدار
- يجب أن تراعي عمليات تنفيذ الأجهزة هدف DevicePolicyManager.ACTION_SET_NEW_PASSWORD وأن تعرض واجهة لإعداد بيانات اعتماد منفصلة لشاشة القفل للملف الشخصي المُدار.
- يجب أن تستخدم بيانات اعتماد شاشة القفل للملف الشخصي المُدار آليات تخزين بيانات الاعتماد والإدارة نفسها المستخدمة في الملف الشخصي الرئيسي، على النحو الموضَّح في موقع مشروع مفتوح المصدر لنظام Android.
- يجب أن تنطبق سياسات كلمة المرور في وحدة التحكّم بسياسة الجهاز على بيانات اعتماد شاشة القفل للملف الشخصي المُدار فقط ما لم يتم استدعاؤها من خلال المثيل DevicePolicyManager الذي يعرضه getParentProfileInstance.

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

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

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

يجب أن توفّر عمليات تنفيذ Android Automotive تنفيذ إطار عمل تسهيل الاستخدام في نظام التشغيل Android بما يتماشى مع طريقة التنفيذ التلقائية لنظام التشغيل Android.
يجب أن توفّر عمليات تنفيذ الأجهزة (باستثناء نظام التشغيل Android Automotive) تنفيذًا لإطار عمل تسهيل الاستخدام في Android بما يتوافق مع آلية التنفيذ التلقائية في نظام التشغيل Android.
يجب أن تكون عمليات تنفيذ الأجهزة (باستثناء نظام التشغيل Android Automotive) متوافقة مع عمليات تنفيذ خدمات تسهيل الاستخدام التابعة لجهات خارجية من خلال واجهات برمجة تطبيقات android.accessibilityservice.
يجب أن تنشئ عمليات تنفيذ الأجهزة (باستثناء نظام التشغيل Android Automotive) أحداث Accessibilityالأحداث وتعرض هذه الأحداث على جميع عمليات تنفيذ AccessibilityService المسجّلة بطريقة تتوافق مع طريقة التنفيذ التلقائية لنظام التشغيل Android.
يجب أن توفّر عمليات تنفيذ الأجهزة (أجهزة Android Automotive وAndroid Watch التي لا يتم فيها استبعاد أي إخراج صوت) آلية يمكن للمستخدم الوصول إليها لتفعيل خدمات تسهيل الاستخدام وإيقافها، ويجب أن تعرض هذه الواجهة استجابةً للغرض android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS.
ننصح بشدة بإجراء عمليات تنفيذ على أجهزة Android مزوّدة بإخراج الصوت لتوفير خدمات تسهيل الاستخدام على الجهاز يمكن مقارنتها بوظائف TalkBack** و"الوصول عبر مفتاح تحكّم" أو تجاوزها (https://github.com/google/talkback).
يجب أن توفّر أجهزة Android Watch المزوّدة بتقنية إخراج الصوت تنفيذات لخدمة تسهيل الاستخدام على الجهاز يمكن مقارنتها بوظائف خدمة تسهيل الاستخدام في TalkBack أو بتجاوزها (https://github.com/google/talkback).
ويجب أن توفر عمليات تنفيذ الأجهزة آلية في خطوات الإعداد غير المتاحة للمستخدمين لتفعيل خدمات تسهيل الاستخدام ذات الصلة، بالإضافة إلى خيارات ضبط حجم الخط وحجم العرض وإيماءات التكبير.

** للغات المتاحة من خلال ميزة تحويل النص إلى كلام.

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

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

يشتمل Android على واجهات برمجة تطبيقات تتيح للتطبيقات استخدام خدمات تحويل النص إلى كلام وتسمح لمقدمي الخدمات بتوفير عمليات تنفيذ خدمات تحويل النص إلى كلام. يجب أن تستوفي عمليات تنفيذ الأجهزة التي تُبلغ عن الميزة android.hardware.audio.output هذه المتطلبات ذات الصلة بإطار عمل "تحويل النص إلى كلام" على Android.

آليات استخدام Android Automotive:

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

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

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

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

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

إنّ عمليات تنفيذ الأجهزة التي تتوافق مع إطار TIF يجب أن تشير إلى ميزة النظام الأساسي android.software.live_tv.

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

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

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

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

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

في عمليات تنفيذ أجهزة Android TV، يجب أن يظهر عرض مركّب معلوماتي وتفاعلي، ويجب أن يتضمّن دليل البرامج الإلكتروني (EPG) الذي تم إنشاؤه من القيم الواردة في حقول Tvct.Programs. يجب أن يفي وضع EPG بالمتطلبات التالية:

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

3.12.1.2. التنقّل

يجب أن يسمح تطبيق البث التلفزيوني بالتنقّل في الوظائف التالية من خلال مفاتيح أزرار التحكّم(D-pad) و"رجوع" و"الشاشة الرئيسية" على أجهزة إدخال أجهزة Android TV (مثل أدوات التحكّم عن بُعد أو تطبيق التحكّم عن بُعد أو وحدة تحكّم الألعاب):

تغيير قنوات التلفزيون
فتح EPG
ضبط مصادر الإدخال المستندة إلى TIF التابعة لجهات خارجية وضبطها
فتح قائمة الإعدادات

"ينبغي" أن يمرّر تطبيق البث التلفزيوني الأحداث الرئيسية إلى مصادر إدخال HDMI من خلال CEC.

3.12.1.3. ربط تطبيق إدخال التلفزيون

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

3.12.1.4. تغيير الوقت

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

3.12.1.5. تسجيل التلفزيون

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

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

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

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

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

3.14. واجهات المستخدم الخاصة بالمركبة

3.14.1. واجهة مستخدم وسائط المركبة

يجب أن تتضمّن أي عملية تنفيذ على الجهاز تُعلِن عن التوافق مع أنظمة التشغيل الآلي إطار عمل لواجهة مستخدم من أجل دعم التطبيقات التابعة لجهات خارجية التي تستهلك واجهتَي برمجة التطبيقات MediaBrowser وMediaSession.

هناك المتطلبات المرئية التالية لإطار عمل واجهة المستخدم الذي يتيح تطبيقات الجهات الخارجية التي تعتمد على MediaBrowser وMediaSession:

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

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

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

يجب أن يتيح مدير الحِزم إثبات ملكية ملفات " .apk" باستخدام الإصدار 2 من مخطّط توقيع حِزم APK وتوقيع JAR.

يجب ألا توسّع عمليات تنفيذ الأجهزة تنسيق رمز البايت .apk أو بيان Android أو Dalvik bytecode أو RenderScript بطريقة قد تمنع تثبيت هذه الملفات وتشغيلها بشكل صحيح على الأجهزة المتوافقة الأخرى.

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

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

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

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

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

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

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

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

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

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

1 مطلوبة لعمليات تنفيذ الأجهزة التي تعرِّف android.hardware.microphone ولكنها اختيارية لعمليات تنفيذ أجهزة Android Watch.

2 يمكن إجراء التسجيل أو التشغيل في وضع أحادي أو استيريو، ولكن يجب توفير ما يلي:

يتم تنفيذ فك الترميز بدون تخفيض المزج (على سبيل المثال، يجب فك ترميز بث AAC 5.0 إلى خمس قنوات من PCM، ويجب فك ترميز بث AAC 5.1 إلى ست قنوات من PCM).
البيانات الوصفية للنطاق الديناميكي، كما هو موضح في "التحكم في النطاق الديناميكي (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_LEVEL_ENCODED_

3 مطلوب لعمليات تنفيذ أجهزة Android المحمولة.

4 مطلوبة لعمليات تنفيذ الأجهزة التي تعرِّف android.hardware.microphone، بما في ذلك عمليات تنفيذ أجهزة Android Watch.

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

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

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

يجب أن تتيح برامج ترميز الإعلانات الخاصة بالملف الشخصي بنطاق عالي الديناميكية (HDR) تحليل البيانات الوصفية الثابتة ومعالجتها.
إذا كان برنامج ترميز الوسائط يعلن عن توفّر إعادة التحميل داخل التطبيق، يجب أن يتوافق مع فترات إعادة التحميل في نطاق يتراوح بين 10 و60 إطارًا، وأن يعمل بدقة خلال% 20 من فترة إعادة التحميل التي تم ضبطها.
يجب أن تتيح برامج ترميز الفيديو أحجام تخزين بايتي الإدخال والإخراج التي تتلاءم مع أكبر إطار ممكن مضغوطًا وغير مضغوط وفقًا لما يحدده المعيار والضبط، ولكن ليس بشكل عام أيضًا.
يجب أن تتوافق برامج ترميز الفيديو وفك ترميزها مع تنسيق الألوان YUV420 المرن (Color_FormatYUV420flex).

التنسيق/برنامج الترميز	برنامج الترميز	جهاز فك الترميز	التفاصيل	أنواع الملفات المتوافقة/ تنسيقات الحاوية
بروتوكول H.263	مايو	مايو		3GPP (.3gp) MPEG-4 (.mp4)
H.264 AVC	مطلوب ²	مطلوب ²	راجِع القسم 5.2 و5.3 لمعرفة التفاصيل.	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts، صوت AAC فقط، غير قابل للإتاحة، Android 3.0 أو إصدار أحدث)
H.265 HEVC		مطلوب ⁵	راجِع القسم 5.3 لمعرفة التفاصيل.	MPEG-4 (.mp4)
MPEG-2		موصى به بشدة ⁶	الجودة الرئيسية	MPEG2-TS
MPEG-4 SP		مطلوب ²		3GPP (.3gp)
VP8 ³	مطلوب ² (Android 4.3 والإصدارات الأحدث)	مطلوب ² (Android 2.3.3 والإصدارات الأحدث)	راجِع القسم 5.2 و5.3 لمعرفة التفاصيل.	WebM (.webm) Matroska (.mkv، الإصدار 4.0 من نظام التشغيل Android والإصدارات الأحدث) ⁴
نموذج الفيديو 9 (VP9)		مطلوب ² (Android 4.4 والإصدارات الأحدث)	راجِع القسم 5.3 لمعرفة التفاصيل.	WebM (.webm) Matroska (.mkv، الإصدار 4.0 من نظام التشغيل Android والإصدارات الأحدث) ⁴

1 مطلوبة لعمليات تنفيذ الأجهزة التي تشمل معدّات الكاميرا وتعريف android.hardware.camera أو android.hardware.camera.front.

2 مطلوب لعمليات تنفيذ الأجهزة باستثناء أجهزة Android Watch.

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

4 يجب أن تدعم عمليات تنفيذ الأجهزة كتابة ملفات Matroska WebM.

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

6 ينطبق هذا الإعداد على عمليات تنفيذ أجهزة Android TV فقط.

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

تكون برامج ترميز الفيديو اختيارية لعمليات التنفيذ على أجهزة Android Watch.

برامج ترميز الفيديو H.264 وVP8 وVP9 وHEVC:

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

يجب أن يتوافق برنامج ترميز الفيديو H.263 وMPEG-4 مع معدّلات نقل البيانات القابلة للضبط ديناميكيًا.

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

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

5.2.1. بروتوكول H.263

عمليات التنفيذ على أجهزة Android باستخدام برامج الترميز H.263 يجب أن تتوافق مع المستوى 45 للملف الشخصي الأساسي.

5.2.2. H-264

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

يجب أن يتوافق مع المستوى 3 للملف الشخصي الأساسي.
ومع ذلك، فإن دعم ASO (ترتيب الشرائح العشوائي) وFMO (الترتيب المرن للكتلة الفائقة) وRS (الشرائح المتكررة) اختياري. بالإضافة إلى ذلك، للحفاظ على التوافق مع أجهزة Android الأخرى، يُنصح بعدم استخدام برامج الترميز ASO وFMO وRS في الملف الشخصي الأساسي.
يجب أن يتوافق مع الملفات الشخصية لترميز الفيديو بدقة عادية (SD) في الجدول التالي.
يجب أن يتوافق مع المستوى 4 للملف الشخصي الرئيسي.
يجب أن تكون متوافقة مع الملفات الشخصية لترميز الفيديو بدقة عالية (HD) كما هو موضّح في الجدول التالي.
بالإضافة إلى ذلك، يُنصَح بشدة باستخدام أجهزة Android TV بترميز الفيديوهات بدقة عالية تبلغ 1080p بمعدّل 30 لقطة في الثانية.

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

1 عندما يكون متوافقًا مع الأجهزة، ولكن يُنصح به بشدة لأجهزة تلفزيون Android

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

يجب أن تتوافق عمليات التنفيذ على أجهزة Android باستخدام برنامج ترميز VP8 مع الملفات الشخصية لترميز الفيديو بدقة عادية، كما يجب أن تتوافق مع الملفات الشخصية لترميز الفيديوهات ذات الدقة العالية (HD) (عالية الوضوح).

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

1 عندما يكون متوافقًا مع الأجهزة.

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

تكون برامج ترميز الفيديو اختيارية لعمليات التنفيذ على أجهزة Android Watch.

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

يجب أن يتيح التبديل بين درجة دقة الفيديو وعدد اللقطات في الثانية من خلال واجهات برمجة تطبيقات Android العادية ضمن البث نفسه لجميع برامج الترميز VP8 وVP9 وH.264 وH.265 في الوقت الفعلي وبوصولاً إلى الحدّ الأقصى لدرجة الدقة المتوافقة مع كل برنامج ترميز على الجهاز.
عمليات التنفيذ التي تتوافق مع برنامج فك ترميز Dolby Vision:
يجب توفير أداة استخراج تتوافق مع تقنية Dolby Vision.
يجب عرض محتوى Dolby Vision بشكل صحيح على شاشة الجهاز أو على منفذ إخراج الفيديو العادي (مثل HDMI).
يجب أن تضبط عمليات التنفيذ التي توفّر أداة استخراج تتوافق مع تقنية Dolby Vision فهرس المسار للطبقات الأساسية المتوافقة مع الأنظمة القديمة (في حال توفُّرها) ليكون مطابقًا لفهرس التتبع لطبقة Dolby Vision المدمجة.

5.3.1. MPEG-2

يجب أن تتوافق عمليات تنفيذ أجهزة Android باستخدام برامج فك ترميز MPEG-2 مع الملف الشخصي الرئيسي العالي المستوى.

5.3.2 بروتوكول H.263

عمليات تنفيذ أجهزة Android باستخدام برامج فك ترميز H.263 يجب أن تتوافق مع المستوى 30 والمستوى 45 من الملف الشخصي الأساسي.

5.3.3. MPEG-4

يجب أن تتوافق عمليات تنفيذ أجهزة Android باستخدام برامج فك ترميز MPEG-4 مع المستوى 3 من الملف الشخصي البسيط.

5.3.4 H.264

عمليات تنفيذ أجهزة Android باستخدام برامج فك ترميز H.264:

يجب أن يتوافق مع المستوى 3.1 للملف الشخصي الرئيسي والملف الشخصي الأساسي.
يتوفر دعم ASO (ترتيب الشرائح العشوائي) وFMO (الترتيب المرن للكتلة الفائقة) وRS (الشرائح المتكررة) اختياري.
يجب أن يكون قادرًا على فك ترميز الفيديوهات باستخدام الملفات الشخصية ذات الدقة العادية (SD) والمدرَجة في الجدول التالي وترميزها باستخدام ملفَي تعريف الأساس والملف الشخصي الرئيسي 3.1 (بما في ذلك 720p30).
"يجب أن تكون قادرًا على فك ترميز الفيديوهات" باستخدام الملفات الشخصية ذات الدقة العالية (HD) كما هو موضَّح في الجدول التالي.
بالإضافة إلى ذلك، يمكن لأجهزة تلفزيون Android
- يجب أن يتوافق مع المستوى 4.2 من ملف تعريف الارتباط العالي المستوى وملف فك الترميز بدقة عالية 1080p60.
- يجب أن يكون قادرًا على فك ترميز الفيديوهات باستخدام كل من ملفات التعريف بدقة عالية كما هو موضح في الجدول التالي، وتم ترميزها باستخدام الملف الشخصي الأساسي أو الملف الشخصي الرئيسي أو المستوى 4.2 من مستوى الملف الشخصي العالي.

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

1 مطلوب عندما يكون الارتفاع كما تم الإبلاغ عنه بواسطة طريقة Display.getsupportedModes() مساويًا لدرجة دقة الفيديو أو أكبر منه.

2 مطلوب لعمليات تنفيذ أجهزة Android TV.

5.3.5. ‫H.265 (HEVC)

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

يجب أن يتوافق مع المستوى الرئيسي للملف الشخصي الرئيسي من المستوى 3 والملفات الشخصية لفك ترميز الفيديوهات بدقة عادية كما هو موضّح في الجدول التالي.
"يُفترض" أن تتيح استخدام الملفات الشخصية لفك ترميز المحتوى بدقة عالية كما هو موضّح في الجدول التالي.
يجب أن يدعم الملفات الشخصية لفك الترميز بالدقة العالية كما هو موضح في الجدول التالي إذا كان هناك برنامج فك ترميز للأجهزة.
بالإضافة إلى ذلك، يمكن لأجهزة تلفزيون Android:
يجب أن يتوافق مع الملف الشخصي لفك ترميز المحتوى بدقة عالية وبدقة 720p.
يُنصح بشدة بأن يتوافق مع الملف الشخصي لفك الترميز بدقة عالية 1080p. إذا كان الملف الشخصي لفك ترميز المحتوى بدقة عالية 1080p متوافقًا، يجب أن يتوافق مع المستوى الرئيسي 4.1 للملف الشخصي الرئيسي.
يجب أن يتوافق مع الملف الشخصي لفك ترميز المحتوى بدقة فائقة. إذا كان الملف الشخصي لفك ترميز المحتوى بدقة فائقة متاحًا، يجب أن يتوافق برنامج الترميز مع الملف الشخصي للفئة الرئيسية من المستوى 5 من المستوى الرئيسي Main10.

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

1 مطلوب لعمليات تنفيذ أجهزة Android TV مع فك ترميز أجهزة H.265.

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

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

يجب أن يتوافق مع الملفات الشخصية لفك ترميز المحتوى بدقة عادية في الجدول التالي.
يجب أن تتوفر الملفات الشخصية لفك ترميز المحتوى بدقة عالية في الجدول التالي.
يجب أن يكون الملف الشخصي لفك ترميز المحتوى بدقة عالية 1080p60 متوافقًا مع أجهزة Android TV.

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

2 مطلوب لعمليات تنفيذ أجهزة Android TV.

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

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

يجب أن يتوافق مع الملفات الشخصية لفك ترميز الفيديوهات بدقة عادية كما هو موضّح في الجدول التالي.
"يُفترض" أن تتيح استخدام الملفات الشخصية لفك ترميز المحتوى بدقة عالية كما هو موضّح في الجدول التالي.
يجب أن يدعم الملفات الشخصية لفك الترميز بالدقة العالية كما هو موضح في الجدول التالي، في حالة وجود برنامج لفك ترميز الأجهزة.
بالإضافة إلى ذلك، يمكن لأجهزة تلفزيون Android:
- يجب أن يتوافق مع الملف الشخصي لفك ترميز المحتوى بدقة عالية وبدقة 720p.
- يُنصح بشدة بأن يتوافق مع الملف الشخصي لفك الترميز بدقة عالية 1080p.
- يجب أن يتوافق مع الملف الشخصي لفك ترميز المحتوى بدقة فائقة. إذا كان الملف الشخصي لفك ترميز الفيديو بدقة فائقة متاحًا، يجب أن يتيح عرض الألوان بعمق 8 بت ويجب أن يكون متوافقًا مع VP9 Profile 2 (10 بت).

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

1 مطلوب لعمليات تنفيذ أجهزة Android TV مع فك ترميز أجهزة VP9.

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

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

5.4.1. التقاط صوت غير معدَّل

يجب أن تسمح عمليات استخدام الأجهزة التي تُعلِن عن android.hardware.microphone بالتقاط محتوى صوتي غير معدَّل بالخصائص التالية:

التنسيق : PCM خطي، 16 بت
معدلات أخذ العينات : 8000، 11025، 16000، 44100
القنوات : أحادي

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

إنّ تطبيقات الأجهزة التي تُعلِن عن android.hardware.microphone يجب أن تسمح بالتقاط محتوى صوتي غير معدَّل بالخصائص التالية:

التنسيق : PCM خطي، 16 بت
معدلات أخذ العينات : 22050، 48000
القنوات : استيريو

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

5.4.2. الالتقاط للتعرف على الصوت

يجب أن يتيح مصدر الصوت في android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION التقاط الصوت بأحد معدلات العيّنات: 44100 و48, 000.

بالإضافة إلى مواصفات التسجيل المذكورة أعلاه، عند بدء التطبيق في تسجيل بث صوتي باستخدام مصدر الصوت android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION:

من المفترض أن يكون للجهاز اتساع مسطّح تقريبًا مقابل خصائص التردد: على وجه التحديد، أكثر من 3 ديسيبل، من 100 هرتز إلى 4000 هرتز.
يجب ضبط حساسية إدخال الصوت كي ينتج عن مصدر طاقة الصوت (SPL) الذي يبلغ 90 ديسيبل عند 1000 هرتز 2,500 دولار أمريكي للعينات ذات 16 بت.
يجب أن تتتبّع مستويات ضوء PCM خطيًا تغييرات مستوى الصوت المنخفض (SPL) على الأقل خلال نطاق لا يقل عن 30 ديسيبل ويتراوح من -18 ديسيبل إلى +12 ديسيبل re 90 ديسيبل لمستوى الصوت العادي عند الميكروفون.
يجب أن يكون التشوّه التوافقي الكلي أقل من% 1 عند تردد 1 كيلوهرتز عند مستوى إدخال مستوى الصوت SPL 90 ديسيبل عند الميكروفون.
يجب إيقاف معالجة تقليل الضوضاء، في حال توفّرها.
يجب إيقاف التحكم التلقائي في الصوت، إن وجد.

إذا كان النظام الأساسي متوافقًا مع تقنيات كتم الضوضاء التي تم ضبطها لميزة "التعرّف على الكلام"، يجب التحكّم في التأثير من واجهة برمجة التطبيقات android.media.audiofx.NoiseSuppressor API. علاوة على ذلك، يجب أن يحدد حقل UUID الخاص بواصف تأثير كتم الضوضاء بشكل فريد كل تنفيذ لتقنية منع الضوضاء.

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

تشتمل الفئة android.media.MediaRecorder.AudioSource على مصدر الصوت REMOTE_SUBMIX. يجب أن تستخدم الأجهزة التي تعلن عن android.hardware.audio.output مصدر الصوت REMOTE_SUBMIX بشكل صحيح، بحيث عندما يستخدم أحد التطبيقات واجهة برمجة التطبيقات android.media.AudioRecord API للتسجيل من مصدر الصوت هذا، يمكنه التقاط مزيج من كل عمليات البث الصوتي باستثناء ما يلي:

حلقة_البث
البث_ALARM
STREAM_NOTIFICATION

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

يجب أن تتوافق عمليات تنفيذ الأجهزة التي تُعلِن عن android.hardware.audio.output مع المتطلبات الواردة في هذا القسم.

5.5.1. تشغيل الصوت الأولي

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

التنسيق : PCM خطي، 16 بت
معدلات أخذ العينات : 8000، 11025، 16000، 22050، 32000، 44100
القنوات : أحادي، استيريو

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

معدلات أخذ العينات : 24000، 48000

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

يوفر Android واجهة برمجة تطبيقات للتأثيرات الصوتية لعمليات تنفيذ الأجهزة. عمليات تنفيذ الأجهزة التي تُعلِن عن الميزة android.hardware.audio.output:

يجب أن يتوافق مع عمليتَي تنفيذ مؤثرات عرض النتائج، مثل تأثير الصوت والمؤثرات، ومؤثرات الصوت من النوع LoudNESS_ENHANCER والتي يمكن التحكم فيها من خلال الفئتين الفرعيتين AudioEffect، والمعادِلة، و LoudnessOptimizationr.
يجب أن يتوافق مع تنفيذ واجهة برمجة تطبيقات العروض المرئية، والتي يمكن التحكم فيها من خلال فئة Visualizer.
يجب أن يتوافق مع عمليات التنفيذ العام

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

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

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

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

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

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

وقت استجابة الناتج . الفاصل الزمني بين وقت كتابة أحد التطبيقات لإطار بيانات بترميز PCM ووقت تقديم الصوت المقابل إلى البيئة في محوّل أو إشارة على الجهاز يخرج من الجهاز عبر منفذ ويمكن ملاحظته خارجيًا.
وقت استجابة الإخراج البارد . وقت استجابة الإخراج للإطار الأول، عندما يكون نظام إخراج الصوت في وضع عدم النشاط وإيقاف التشغيل قبل الطلب.
وقت استجابة الإخراج المستمر . وقت استجابة إخراج الإطارات اللاحقة بعد تشغيل الجهاز للصوت
وقت استجابة الإدخال . يشير ذلك المصطلح إلى الفاصل الزمني بين وقت إرسال الصوت من خلال البيئة إلى الجهاز في محوّل الطاقة أو الإشارة داخل الجهاز عبر منفذ، وعندما يقرأ التطبيق الإطار المقابل لبيانات PCM المرمّزة.
فقدان الإدخال . الجزء الأول من إشارة إدخال غير قابل للاستخدام أو غير متاح.
وقت استجابة الإدخال البارد . مجموع وقت الإدخال المفقود ووقت استجابة الإدخال للإطار الأول، عندما يكون نظام الإدخال الصوتي في وضع عدم النشاط وإيقاف التشغيل قبل الطلب.
وقت استجابة الإدخال المستمر . وقت استجابة الإدخال للّقطات اللاحقة، بينما يلتقط الجهاز الصوت.
عدم استقرار الإخراج البارد . التباين بين القياسات المنفصلة لقيم وقت استجابة الإخراج البارد.
عدم استقرار المدخلات الباردة . يشير إلى التباين بين القياسات المنفصلة لقيم وقت استجابة الإدخال البارد.
وقت استجابة الذهاب والعودة المستمر مجموع وقت استجابة الإدخال المستمر بالإضافة إلى وقت استجابة الإخراج المستمر بالإضافة إلى فترة مخزن مؤقت واحدة. تتيح فترة التخزين المؤقت وقتًا للتطبيق لمعالجة الإشارة والوقت الذي يقضيه التطبيق في الحدّ من الفروق بين مصادر الإدخال والإخراج.
OpenSL ES PCM buffer playlist API . مجموعة واجهات برمجة تطبيقات OpenSL ES ذات الصلة بـ PCM ضمن Android NDK.

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

وقت استجابة الإخراج البارد يبلغ 100 مللي ثانية أو أقل
وقت استجابة إخراج مستمر يبلغ 45 مللي ثانية أو أقل
تقليل عدم استقرار الإخراج البارد

إذا استوفى تنفيذ الجهاز متطلبات هذا القسم بعد إجراء أي معايرة أولية عند استخدام واجهة برمجة تطبيقات قائمة انتظار المخزن المؤقت OpenSL ES PCM، ولتوفير وقت استجابة مستمر للإخراج ووقت استجابة الإخراج البارد على جهاز إخراج صوت متوافق واحد على الأقل، يُنصح بشدة بالإبلاغ عن إتاحة الصوت ذي وقت الاستجابة المنخفض من خلال الإبلاغ عن الميزة android.hardware.audio.low_latency عبر android.class.audio.low_latency عبر android.classcontent.pm.pm.pm. وفي المقابل، إذا لم يستوفِ تطبيق الجهاز هذه المتطلبات، يجب ألا يبلغ عن إتاحة الصوت لوقت الاستجابة المنخفض.

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

وقت استجابة الإدخال البارد يبلغ 100 مللي ثانية أو أقل
وقت استجابة الإدخال المستمر البالغ 30 مللي ثانية أو أقل
وقت استجابة الذهاب والعودة المستمر الذي يبلغ 50 مللي ثانية أو أقل
تقليل عدم استقرار الإدخال البارد

5.7. بروتوكولات الشبكة

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

البث التدريجي لبروتوكول HTTP(S)
يجب أن تتوافق جميع برامج الترميز وتنسيقات الحاويات المطلوبة في القسم 5.1 عبر بروتوكول HTTP(S).
بروتوكول مسودة البث المباشر عبر HTTP، الإصدار 7
يجب أن تكون تنسيقات شرائح الوسائط التالية متوافقة:

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

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

المَراجع

توفُّر برنامج ترميز مطلوب

MPEG-2 Transport Stream

ISO 13818

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

H264 AVC
MPEG-4 SP
MPEG-2

يمكنك مراجعة الفقرة 5.1.3 للحصول على تفاصيل حول H264 AVC وMPEG2-4 SP
. وMPEG-2.

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

الترميز المتقدّم للصوت

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

الترميز المتقدّم للصوت مع إطارات ADTS وعلامات رقم التعريف 3 (ID3)

ISO 13818-7

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

WebVTT

بروتوكول RTSP (RTP، بروتوكول SDP)

يجب أن يكون الملف الشخصي التالي للصوت بتنسيق RTP وبرامج الترميز ذات الصلة متاحة. بالنسبة إلى الاستثناءات، يُرجى مراجعة الحواشي السفلية للجدول في القسم 5.1.

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

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

إنّ عمليات تنفيذ الأجهزة التي تتيح إخراج الفيديو الآمن والتي يمكنها دعم مساحات العرض الآمنة يجب أن تشير إلى توافقها مع Display.FLAG_SECURE. في حال توافق تطبيقات الأجهزة التي تشير إلى توافقها مع Display.FLAG_SECURE، إذا كانت متوافقة مع بروتوكول العرض اللاسلكي، يجب أن يتم تأمين الرابط باستخدام آلية تشفير قوية، مثل HDCP 2.x أو أعلى لشاشات Miracast اللاسلكية. وبالمثل، إذا كانت تدعم شاشة عرض خارجية سلكية، يجب أن تتوافق عمليات تنفيذ الأجهزة مع HDCP 1.2 أو الإصدارات الأحدث. يجب أن تكون أجهزة Android TV متوافقة مع الإصدار 2.2 من HDCP 2.2 للأجهزة التي تتيح البث بدرجة دقة 4K وHDCP 1.4 أو أعلى لدرجات دقة أقل. تشمل عملية التنفيذ المفتوحة المصدر لنظام Android التشغيلية لشاشات العرض اللاسلكية (Miracast) والشاشات السلكية (HDMI) التي تستوفي هذا الشرط.

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

إذا كان الجهاز متوافقًا مع نقل برامج MIDI بين التطبيقات (أجهزة MIDI الافتراضية)، وكان متوافقًا مع MIDI على جميع عمليات نقل الأجهزة التالية المتوافقة مع MIDI والتي يوفّر لها اتصال عام غير MIDI، يُنصَح بشدة بالإبلاغ عن إتاحة الميزة android.content.pm.PackageManager.

في ما يلي وسائل نقل الأجهزة المتوافقة مع MIDI:

وضع مضيف USB (القسم 7.7 USB)
وضع USB الطرفي (القسم 7.7 USB)
عمل MIDI عبر Bluetooth LE في دور مركزي (القسم 7.4.3 Bluetooth)

في المقابل، إذا كان تنفيذ الجهاز يوفّر اتصالاً عامًا غير MIDI عبر عملية نقل أجهزة MIDI المذكورة أعلاه، ولكنّها لا تتوافق مع MIDI خلال نقل الأجهزة، يجب ألا تبلغ عن إتاحة الميزة android.software.midi.

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

إذا استوفى تنفيذ الجهاز جميع المتطلبات التالية، يُنصَح بشدة بالإبلاغ عن إتاحة الميزة android.hardware.audio.pro من خلال الفئة android.content.pm.PackageManager.

يجب أن تُبلِغ عملية تنفيذ الجهاز عن توافق الميزة android.hardware.audio.low_latency.
يجب أن يكون وقت الاستجابة المستمر للصوت ذهابًا وإيابًا، كما هو محدّد في الفقرة 5.6، "وقت استجابة الصوت" يبلغ 20 مللي ثانية أو أقل، ويجب أن يكون 10 مللي ثانية أو أقل عبر مسار واحد متوافق على الأقل.
إذا كان الجهاز يتضمن مقبس صوت مقاس 3.5 ملم بموصّل 4، يجب أن يكون وقت استجابة الصوت المستمر ذهابًا وإيابًا 20 ملي ثانية أو أقل عبر مسار مقبس الصوت، وأن يكون 10 ملي ثانية أو أقل في مسار مقبس الصوت.
يجب أن يشتمل تنفيذ الجهاز على منافذ USB تتوافق مع وضع مضيف USB ووضع الجهاز الطرفي عبر USB.
يجب أن يستخدم وضع مضيف USB فئة صوت USB.
إذا كان الجهاز يتضمن منفذ HDMI، يجب أن يدعم تنفيذ الجهاز إخراج الصوت الاستيريو و ثماني قنوات بعمق 20 بت أو 24 بت و192 كيلوهرتز بدون فقدان عمق البت أو إعادة أخذ عينات منه.
يجب أن تُبلِغ عملية تنفيذ الجهاز عن توافق الميزة android.software.modi.
إذا كان الجهاز يتضمّن مقبس صوت مقاس 3.5 ملم بمقابس ذات 4 موصّلات، يُنصَح بشدة بأن يتوافق الجهاز مع قسم مواصفات الأجهزة الجوّالة (المقبس) ضِمن مواصفات سماعات الرأس السلكية (الإصدار 1.1).

يجب استيفاء أوقات الاستجابة ومتطلبات صوت USB باستخدام واجهة برمجة تطبيقات قائمة انتظار المخزن المؤقت OpenSL ES PCM.

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

يمكنك توفير مستوى مستدام من أداء وحدة المعالجة المركزية (CPU) عندما يكون الصوت نشطًا.
يمكنك تقليل دقة ساعة الصوت وعدم الانحراف عن الوقت القياسي.
يمكنك تقليل اهتزاز ساعة الصوت بالنسبة إلى وحدة المعالجة المركزية (CPU) CLOCK_MONOTONIC عندما يكون كلّ منهما نشط.
تقليل وقت استجابة الصوت إلى أدنى حدّ عبر محوّلات التحويل على الجهاز
تقليل وقت استجابة الصوت إلى أدنى حدّ عبر صوت USB الرقمي
قياسات وقت استجابة الصوت في جميع المسارات
يجب تقليل عدم التردّد في أوقات إدخال طلب إكمال المخزن المؤقت الصوتي، لأنّ ذلك يؤثر في النسبة القابلة للاستخدام من معدّل نقل بيانات وحدة المعالجة المركزية الكامل من خلال معاودة الاتصال.
يجب ألا يتم خفض مدّة تشغيل الصوت (المخرجات) أو تجاوز (الإدخال) في حال الاستخدام العادي في وقت الاستجابة الذي تم الإبلاغ عنه.
تقديم صفر فارق في وقت الاستجابة بين القنوات.
تقليل وقت استجابة MIDI في جميع عمليات النقل
يجب تقليل تغيُّر وقت استجابة MIDI أثناء التحميل (عدم الاستقرار) في جميع وسائل النقل.
تقديم طوابع زمنية دقيقة لـ MIDI في جميع عمليات النقل
قلِّل ضوضاء الإشارة الصوتية في محوّلات الجهاز، بما في ذلك الفترة التي تسبق التشغيل على البارد مباشرةً.
توفير فرق الساعة الصوتية الصفرية بين جانبَي الإدخال والإخراج لنقاط النهاية المقابلة عندما يكون كلاهما نشطًا. وتشمل أمثلة نقاط النهاية المقابلة الميكروفون ومكبّر الصوت المتوفّرَين على الجهاز أو مصادر الإدخال والإخراج في مقبس الصوت.
التعامل مع استدعاءات إكمال المخزن المؤقت للصوت جانبَي الإدخال والإخراج لنقاط النهاية المقابلة في سلسلة المحادثات نفسها عندما يكون كلاهما نشطًا، وإدخال طلب معاودة الاتصال بالإخراج مباشرةً بعد العودة من معاودة الاتصال بالإدخال أو إذا لم يكن من الممكن معالجة عمليات الاستدعاء في سلسلة المحادثات نفسها، يمكنك إدخال معاودة الاتصال للمخرجات بعد وقت قصير من إدخال استدعاء الإدخال للسماح للتطبيق بأن يكون لدى التطبيق توقيت ثابت لجانبَي الإدخال والإخراج.
عليك تقليل فرق الطور بين التخزين المؤقت للصوت HAL في جانبَي الإدخال والإخراج لنقاط النهاية المقابلة.
تقليل وقت استجابة اللمس
يجب تقليل تغيُّر وقت استجابة اللمس عند التحميل (عدم الاستقرار).

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

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

يجب أن يستوفي الجهاز جميع المتطلبات التالية للإبلاغ عن توافُق مصدر الصوت الذي لم تتم معالجته عبر سمة android.media.AudioManager Property_SUPPORT_AUDIO_SOURCE_UNPROCESSED:

يجب أن يعرض الجهاز خصائص اتساع مسطّح مقابل تردد مسطّح تقريبًا في نطاق التردد المتوسط: على وجه التحديد أكثر من 10 ديسيبل من 100 هرتز إلى 7000 هرتز.
يجب أن يعرض الجهاز مستويات سعة شدة في نطاق التردد المنخفض، خاصةً من 20 ديسيبل بدءًا من 5 هرتز إلى 100 هرتز مقارنةً بنطاق التردد المتوسط.
يجب أن يعرض الجهاز مستويات سعة تردد في نطاق التردد العالي: من + 30 ديسيبل تحديدًا بدءًا من 7000 هرتز إلى 22 كيلوهرتز مقارنةً بنطاق التردد المتوسط.
يجب ضبط حساسية إدخال الصوت كي ينتج عن مصدر نغمة جيبية بتردد 1000 هرتز يتم تشغيله عند مستوى ضغط الصوت (SPL) 94 ديسيبل استجابة بقيمة متوسطية 520 للعينات التي يبلغ حجمها 16 بت (أو مقياس كامل يبلغ -36 ديسيبل لعينات النقطة العائمة/الدقة المزدوجة).
SNR > 60 ديسيبل (الفرق بين مستوى الصوت العادي لمستوى الصوت SPL و94 ديسيبل ومؤشر مستوى الخدمة نفسه من الضوضاء الذاتية، بتقدير A)
يجب أن يكون إجمالي التشوّه التوافقي أقل من% 1 لصوت 1 كيلوهرتز عند مستوى إدخال مستوى الصوت SPL 90 ديسيبل عند استخدام الميكروفون.
معالجة الإشارة الوحيدة المسموح بها في المسار هي مُضاعِف المستوى للوصول إلى المستوى المطلوب. يجب ألا يتسبب مضاعف المستوى هذا في حدوث تأخير أو وقت استجابة لمسار الإشارة.
ولا يُسمح بمعالجة أي إشارة أخرى في المسار، مثل التحكّم التلقائي في مستوى الكسب أو فلتر التمرير المرتفع أو إلغاء الصدى. في حال توفُّر أي معالجة إشارات في البنية لأي سبب من الأسباب، يجب أن يتم إيقافها وترك أي تأخير أو وقت استجابة إضافي بفعالية في مسار الإشارة.

يتم إجراء جميع قياسات مستوى العميل (SPL) مباشرةً بجانب الميكروفون قيد الاختبار.

بالنسبة إلى إعدادات الميكروفون المتعددة، تنطبق هذه المتطلبات على كل ميكروفون.

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

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

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

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

Android Debug Bridge (adb)
- يجب أن تتوافق عمليات تنفيذ الأجهزة مع جميع وظائف adb كما هو موثّق في حزمة تطوير البرامج (SDK) لنظام التشغيل Android، بما في ذلك ملف dumpsys.
- يجب أن يكون البرنامج الخفي لـ adb من جهة الجهاز غير نشط بشكل تلقائي ويجب أن تكون هناك آلية يمكن للمستخدم الوصول إليها لتفعيل Android Debug Bridge. إذا حذف تنفيذ جهاز وضع الجهاز الملحق بمنفذ USB، يجب تنفيذ جسر تصحيح أخطاء Android Debug Bridge عبر شبكة محلية (مثل Ethernet أو 802.11).
- يشمل Android استخدام أداة Adb الآمنة. يفعِّل Adb الآمن واجهة برمجة التطبيقات (ADb) على المضيفات المعروفة التي تمت مصادقتها. يجب أن تتيح عمليات تنفيذ الأجهزة استخدام Adb الآمن.
خدمة Dalvik Debug Monitor (ddms)
- يجب أن تتوافق عمليات تنفيذ الأجهزة مع جميع ميزات نظام إدارة المحتوى (ddms) كما هو موثّق في حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
- بما أنّ نظام dms يستخدِم أداة adb، يُفترَض أن يكون الدعم لنظام ddms غير نشط تلقائيًا، ولكن يجب أن يكون متوافقًا عندما ينشط المستخدم Android Debug Bridge، على النحو الوارد أعلاه.
Monkey يجب أن تتضمن عمليات تنفيذ الأجهزة إطار عمل Monkey، وإتاحتها للتطبيقات لاستخدامها.
تتبُّع النظام (SysTrace)
- يجب أن تدعم عمليات تنفيذ الأجهزة أداة تتبُّع النظم كما هو موثّق في حزمة تطوير البرامج (SDK) لنظام التشغيل Android. يجب أن يكون النظام غير نشط بشكل افتراضي، ويجب أن تكون هناك آلية يمكن للمستخدم الوصول إليها لتفعيل Systrace.
- تتعرّف معظم الأنظمة المستندة إلى Linux وأنظمة Apple Macintosh على أجهزة Android باستخدام أدوات حزمة تطوير البرامج (SDK) العادية لنظام التشغيل Android، بدون أي دعم إضافي. ولكن أنظمة Microsoft Windows تتطلب عادةً برنامج تشغيل لأجهزة Android الجديدة. (على سبيل المثال، تتطلب معرِّفات المورِّدين الجديدة وأحيانًا معرِّفات الأجهزة الجديدة برامج تشغيل USB مخصصة لأنظمة التشغيل Windows.)
- إذا لم تتعرّف أداة adb على عملية تنفيذ الجهاز على النحو الموضَّح في حزمة تطوير البرامج (SDK) العادية لنظام التشغيل Android، على أدوات تنفيذ الأجهزة أن توفّر برامج تشغيل Windows تسمح للمطوّرين بالاتصال بالجهاز باستخدام بروتوكول adb. يجب توفير برامج التشغيل هذه لأنظمة التشغيل Windows XP وWindows Vista وWindows 7 وWindows 8 وWindows 10 في كل من الإصدارين 32 بت و64 بت.

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

يتيح Android للمطوّرين ضبط الإعدادات المتعلّقة بتطوير التطبيقات. يجب أن تفي عمليات تنفيذ الأجهزة بالهدف android.settings.APPLICATION_DEVELOPMENT_SETTINGS لعرض الإعدادات المتعلقة بتطوير التطبيقات. تُخفي عملية تنفيذ Android الأولية قائمة "خيارات المطوّرين" تلقائيًا وتتيح للمستخدمين تشغيل "خيارات المطوّرين" بعد الضغط سبع (7) مرات في الإعدادات > لمحة عن الجهاز > عنصر القائمة رقم الإصدار يجب أن توفر عمليات تنفيذ الأجهزة تجربة متسقة لخيارات المطوّرين. على وجه التحديد، يجب أن تخفي عمليات تنفيذ الأجهزة "خيارات المطوّرين" تلقائيًا ويجب أن توفّر آلية لتفعيل "خيارات المطوّرين" بما يتوافق مع عملية تنفيذ Android الرئيسية.

قد تؤدي عمليات تنفيذ Android Automotive إلى تقييد الوصول إلى قائمة "خيارات المطوّرين" من خلال إخفاء القائمة أو إيقافها بصريًا عندما تكون المركبة تتحرك.

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

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

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

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

يجب أن تُبلغ عمليات تنفيذ الأجهزة باستمرار عن معلومات إعداد الأجهزة الدقيقة من خلال الطريقتين getSystemavailableFeatures() وhasSystemFeature(String) في الفئة android.content.pm.PackageManager لبصمة الإصدار نفسها.

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

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

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

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

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

7.1.1.1. حجم الشاشة

قد تكون شاشات أجهزة Android Watch (الموضّحة في القسم 2) أصغر حجمًا على النحو الموضَّح في هذا القسم.

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

يجب أن يبلغ حجم شاشة الأجهزة 426 بكسل مستقل الكثافة × 320 بكسل مستقل الكثافة على الأقل ("الصغيرة")، إلّا إذا كان الجهاز ساعة تعمل بنظام التشغيل Android.
يجب أن يبلغ حجم الشاشة في الأجهزة التي تُبلغ عن حجم الشاشة "عادي" 480 بكسل مستقل الكثافة × 320 بكسل مستقل الكثافة (dp).
يجب أن يبلغ حجم الشاشة في الأجهزة التي تُبلغ عن حجم الشاشة "كبير" 640 بكسل مستقل الكثافة × 480 بكسل مستقل الكثافة (dp).
يجب أن يبلغ حجم الشاشة في الأجهزة التي تُبلغ عن حجم الشاشة "كبير جدًا" 960 بكسل مستقل الكثافة × 720 بكسل مستقل الكثافة (dp).

بالإضافة إلى ذلك:

يجب أن تحتوي أجهزة Android Watch على شاشة بحجم قطري يتراوح بين 1.1 و2.5 بوصة.
يجب أن تحتوي أجهزة Android Automotive على شاشة أن يكون حجم قطرها الفعلي أكبر من أو يساوي 6 بوصات.
يجب أن يبلغ حجم شاشة أجهزة Android Automotive 750 بكسل مستقل الكثافة x 480 بكسل مستقل الكثافة على الأقل.
يجب أن تحتوي الأنواع الأخرى من عمليات تنفيذ أجهزة Android، التي تتضمن شاشة مدمجة فعليًا، على شاشة لا يقل حجمها عن 2.5 بوصة في الحجم القطري الفعلي.

يجب ألا تغيّر الأجهزة في أي وقت حجم الشاشة الذي تم الإبلاغ عنه.

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

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

على الرغم من عدم فرض قيود على قيمة نسبة العرض إلى الارتفاع لشاشة العرض الفعلية، يجب أن تستوفي نسبة العرض إلى الارتفاع لشاشة العرض التي يتم عرض التطبيقات التابعة لجهات خارجية عليها والتي يمكن اشتقاقها من القيم التي يتم الإبلاغ عنها من خلال DisplayMetrics المتطلبات التالية:

إذا تم ضبط uiMode على UI_mode_TYPE_Watch، قد يتم ضبط قيمة نسبة العرض إلى الارتفاع على 1.0 (1:1).
إذا أشار التطبيق التابع لجهة خارجية إلى أنّه يمكن تغيير حجمه من خلال السمة android:resizeableActivity، ما مِن قيود على قيمة نسبة العرض إلى الارتفاع.
أمّا في جميع الحالات الأخرى، فيجب أن تتراوح نسبة العرض إلى الارتفاع بين 1.3333 (4:3) و1.86 (16:9 تقريبًا) ما لم يشر التطبيق صراحةً إلى أنّه يتيح زيادة نسبة العرض إلى الارتفاع للشاشة من خلال قيمة البيانات الوصفية maxAspectRatio.

7.1.1.3. كثافة الشاشة

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

120 نقطة لكل بوصة (ldpi)
160 نقطة لكل بوصة (mdpi)
213 نقطة لكل بوصة (tvdpi)
240 نقطة لكل بوصة (hdpi)
280 نقطة لكل بوصة (280 نقطة لكل بوصة)
320 نقطة لكل بوصة (xhdpi)
360 نقطة لكل بوصة (360 نقطة لكل بوصة)
400 نقطة لكل بوصة (400 نقطة لكل بوصة)
420 نقطة لكل بوصة (420 نقطة لكل بوصة)
480 نقطة لكل بوصة (xxhdpi)
560 نقطة لكل بوصة (560 نقطة لكل بوصة)
640 نقطة لكل بوصة (xxxhdpi)

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

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

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

7.1.2. مقاييس العرض

يجب أن تعرض عمليات تنفيذ الأجهزة القيم الصحيحة لجميع مقاييس العرض المحدّدة في android.util.DisplayMetrics ويجب أن تبلغ عن القيم نفسها بغض النظر عما إذا كانت الشاشة المضمَّنة أو الخارجية تُستخدم كشاشة العرض التلقائية.

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

يجب أن تُبلغ الأجهزة عن اتجاهات الشاشة المتوافقة معها (android.hardware.screen.portrait و/أو android.hardware.screen.landscape)، ويجب أن تعرض على الأقل اتجاهًا متوافقًا واحدًا على الأقل. على سبيل المثال، يجب أن يبلغ الجهاز ذو الشاشة الأفقية ذات الاتجاه الثابت، مثل تلفزيون أو كمبيوتر محمول، عن الجهاز android.hardware.screen.landscape فقط.

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

يجب أن تعرض الأجهزة القيمة الصحيحة للاتجاه الحالي للجهاز، في حال طلبها من خلال android.content.res.Configuration.orientation أو android.view.Display.getOrientation() أو واجهات برمجة تطبيقات أخرى.

يجب ألا تغيّر الأجهزة حجم الشاشة أو كثافتها التي يتم الإبلاغ عنها عند تغيير الاتجاه.

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

يجب أن تتوافق عمليات تنفيذ الأجهزة مع كل من OpenGL ES 1.0 و2.0، كما هو موضّح ومفصَّل في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android. يجب أن تتوافق عمليات تنفيذ الأجهزة مع OpenGL ES 3.0 أو 3.1 أو 3.2 على الأجهزة المتوافقة معه. يجب أن تتوافق عمليات تنفيذ الأجهزة أيضًا مع Android RenderScript، كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

يجب أن تشير عمليات تنفيذ الأجهزة إلى أنّها متوافقة مع OpenGL ES 1.0 أو OpenGL ES 2.0 أو OpenGL ES 3.0 أو OpenGL 3.1 أو OpenGL 3.2. وهي:

يجب أن تقدّم واجهات برمجة التطبيقات المُدارة (مثلاً من خلال طريقة GLES10.getString() ) توافقًا مع OpenGL ES 1.0 وOpenGL ES 2.0.
يجب أن تشير واجهات برمجة التطبيقات الأصلية C/C++ OpenGL (واجهات برمجة التطبيقات المتاحة للتطبيقات عبر libGLES_v1CM.so أو libGLES_v2.so أو libEGL.so) إلى أنّها تدعم OpenGL ES 1.0 و OpenGL ES 2.0.
إنّ عمليات تنفيذ الأجهزة التي تشير إلى توافقها مع OpenGL ES 3.0 أو 3.1 أو 3.2 يجب أن تتوافق مع واجهات برمجة التطبيقات المُدارة ذات الصلة وأن تشمل إمكانية استخدام واجهات برمجة التطبيقات الأصلية C/C++. في عمليات تنفيذ الأجهزة التي تُعلِن عن توافقها مع OpenGL ES 3.0 أو 3.1 أو 3.2 libGLESv2.so، يجب تصدير رموز الوظائف المقابلة بالإضافة إلى رموز الوظائف OpenGL ES 2.0.

ويوفر Android حزمة إضافات OpenGL ES مع واجهات Java ودعم أصلي لوظائف الرسومات المتقدمة مثل التوريد وتنسيق ضغط بنية ASTC. يجب أن تتوافق عمليات تنفيذ أجهزة Android مع حزمة الإضافات إذا كان الجهاز متوافقًا مع OpenGL ES 3.2 وقد يتيح ذلك. إذا كانت حزمة الإضافات متوافقة بالكامل، يجب أن يتعرّف الجهاز على الدعم من خلال علامة الميزات android.hardware.opengles.aep.

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

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

يشتمل Android على آلية للتطبيقات توضح أنها تريد تفعيل تسريع الأجهزة للرسومات الثنائية الأبعاد على مستوى التطبيق أو النشاط أو النافذة أو العرض من خلال استخدام علامة البيان android:hardwareAccelerated أو طلبات البيانات المباشرة من واجهة برمجة التطبيقات.

يجب أن تؤدي عمليات تنفيذ الأجهزة إلى تفعيل تسريع الأجهزة تلقائيًا، ويجب إيقاف تسريع الأجهزة إذا طلب مطوّر البرامج ذلك من خلال ضبط android:hardwareAccelerated="false" أو إيقاف تسريع الأجهزة مباشرةً من خلال واجهات برمجة تطبيقات Android View.

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

يتضمّن Android عنصر TextureView يتيح للمطوّرين دمج زخارف OpenGL ES التي يتم تسريعها بالأجهزة كأهداف عرض في تسلسل هرمي لواجهة المستخدم. يجب أن تتوافق عمليات تنفيذ الأجهزة مع واجهة برمجة التطبيقات TextureView API، ويجب أن تكون متوافقة مع سلوك التطبيق الرئيسي في Android.

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

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

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

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

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

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

يجب أن تتوافق الأجهزة مع شاشات يمكنها عرض رسومات ملونة بـ 16 بت ويجب أن تدعم الشاشات التي يمكنها عرض رسومات ملونة بـ 24 بت.
يجب أن تتوافق الأجهزة مع الشاشات التي يمكنها عرض الصور المتحركة.
يجب أن تتراوح نسبة العرض إلى الارتفاع (PAR) لتكنولوجيا العرض المستخدَمة بين 0.9 و1.15. وهذا يعني أنّ نسبة العرض إلى الارتفاع للبكسل يجب أن تكون قريبة من المربّع (1.0) مع تفاوت يتراوح بين %10 و%15.

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

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

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

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

7.2.1. لوحة المفاتيح

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

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

يجب أن يتوافق مع "إطار إدارة الإدخال" (الذي يسمح للمطوّرين التابعين لجهات خارجية بإنشاء "أدوات تحرير أساليب الإدخال"، أي لوحة المفاتيح الافتراضية) كما هو موضَّح على الرابط http://developer.android.com.
يجب أن يتم استخدام لوحة مفاتيح افتراضية واحدة على الأقل (بغض النظر عمّا إذا كانت هناك لوحة مفاتيح ثابتة أم لا) باستثناء أجهزة ساعة Android Watch التي يقل حجم الشاشة فيها استخدام لوحة مفاتيح افتراضية.
وقد يتضمن ذلك عمليات تنفيذ إضافية للوحة مفاتيح soft.
وقد يشتمل على لوحة مفاتيح خارجية.
يجب ألا تتضمّن لوحة مفاتيح خارجية لا تتطابق مع أحد التنسيقات المحدّدة في android.content.res.Configuration.keyboard (QWERTY أو مكوّن من 12 مفتاحًا).

7.2.2. التنقُّل بدون لمس

يجب أن تكون أجهزة Android TV متوافقة مع لوحة التحكّم.

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

قد تحذف خيار التنقُّل الذي لا يعمل باللمس (كرة التعقّب أو لوحة التحكّم أو العجلة) إذا لم يكن تنفيذ الجهاز على جهاز Android TV.
يجب الإبلاغ عن القيمة الصحيحة في android.content.res.Configuration.navigation.
يجب توفير آلية معقولة لواجهة مستخدم بديلة لاختيار النص وتعديله، وأن تكون هذه الآلية متوافقة مع "محركات إدارة الإدخال". تتضمّن عملية التنفيذ المفتوحة المصدر لنظام Android آلية اختيار مناسبة للاستخدام مع الأجهزة التي لا تتضمّن إدخالات للتنقل لا تعمل باللمس.

7.2.3. مفاتيح التنقل

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

تُعد وظائف "الصفحة الرئيسية" و"العناصر الأخيرة" و"رجوع" (التي تم تعيينها إلى الأحداث الرئيسية KEYCODE_Home وKEYCODE_APP_SWITCH وKEYCODE_BACK، على التوالي) أساسية في نموذج التنقل في Android، وبالتالي:

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

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

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

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

تم إيقاف وظيفة "القائمة" لصالح شريط الإجراءات بدءًا من Android 4.0. لذلك، يجب ألا يتم استخدام زر مادي مخصّص لوظيفة "القائمة" في عمليات الشحن التي تتم باستخدام الإصدار Android 7.0 والإصدارات الأحدث من الجهاز. ينبغي ألا تنفذ عمليات تنفيذ الأجهزة القديمة زرًا فعليًا مخصصًا لوظيفة القائمة، ولكن إذا تم تنفيذ زر القائمة الفعلي وكان الجهاز يشغِّل تطبيقات تحتوي على targetSdkVersion > 10، تنفيذ الجهاز:

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

للتوافق مع الأنظمة القديمة، يجب أن تؤدي عمليات تنفيذ الأجهزة إلى إتاحة وظيفة "القائمة" للتطبيقات عندما تكون قيمة targetSdkVersion أقل من 10، إما عن طريق زر فعلي أو مفتاح برنامج أو إيماءات. يجب عرض دالة "القائمة" هذه ما لم تكن مخفية مع وظائف التنقل الأخرى.

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

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

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

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

يجب أن يكون إدخال الشاشة التي تعمل باللمس يتيح استخدام أجهزة Android المحمولة والساعات.

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

يجب أن تدعم المؤشرات التي يتم تتبُّعها بشكل مستقل تمامًا، إذا كان نظام إدخال الجهاز يتيح استخدام مؤشرات متعددة.
يجب أن يتم الإبلاغ عن قيمة android.content.res.Configuration.Touchscreen المقابلة لنوع الشاشة التي تعمل باللمس المحدّدة على الجهاز.

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

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

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

عمليات تنفيذ الأجهزة التي تعلن أنّها تتوافق مع android.hardware.fake touch:

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

يجب أن تستوفي الأجهزة التي تعلن عن توافقها مع android.hardware.fakeTouch.multi touch.distinct متطلبات ميزة fake touch أعلاه، ويجب أن تتيح أيضًا إمكانية تتبُّع مختلف لإدخالات المؤشر المستقلة أو أكثر.

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

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

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

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

زرّ	استخدام الواجهة البشرية (HID) ²	زر Android
أ ¹	0x09 0x0001	KEYCODE_button_A (96)
ب ¹	0x09 0x0002	KEYCODE_button_B (97)
X ¹	0x09 0x0004	KEYCODE_button_X (99)
س ¹	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 0x0223	KEYCODE_Home (3)
رجوع ¹	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. جهاز التحكّم عن بُعد

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

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

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

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

يجب أن تُبلِغ بدقة عن توفُّر أو عدم توفُّر أجهزة استشعار وفقًا للفئة android.content.pm.PackageManager.
يجب عرض قائمة دقيقة بأجهزة الاستشعار المتوافقة من خلال SensorManager.getSensorList() وطرق مشابهة.
يجب أن يعمل الجهاز بشكل معقول مع جميع واجهات برمجة تطبيقات أدوات الاستشعار الأخرى (على سبيل المثال، من خلال عرض القيمة true أو false على النحو المناسب عندما تحاول التطبيقات تسجيل أدوات معالجة البيانات، وليس الاتصال بأدوات استشعار المحتوى عندما تكون أدوات الاستشعار المقابلة غير متوفّرة، وما إلى ذلك).
يجب الإبلاغ عن كل قياسات أجهزة الاستشعار باستخدام قيم النظام الدولي للوحدات (المقاييس) ذات الصلة لكل نوع من أنواع أجهزة الاستشعار على النحو المحدّد في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
يجب الإبلاغ عن وقت الحدث بالثواني كما هو محدّد في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android، وهو ما يمثّل وقت وقوع الحدث ومزامنته مع ساعة SystemClock.elapsedRealtimeNano() . ننصح بشدة بأن تستوفي أجهزة Android الحالية والجديدة هذه المتطلبات حتى تتمكّن تلك الأجهزة من الترقية إلى إصدارات النظام الأساسي المستقبلية التي قد يصبح فيها هذا المكوّن مطلوبًا. ينبغي أن يكون خطأ المزامنة أقل من 100 مللي ثانية.
يجب أن يتم الإبلاغ عن بيانات جهاز الاستشعار التي يبلغ وقت الاستجابة لها 100 ملي ثانية كحد أقصى + 2 * sample_time في حالة جهاز الاستشعار الذي يتم بثه بأقل وقت استجابة مطلوب يبلغ 5 ملي ثانية + 2 * sample_time عندما يكون معالج التطبيقات نشطًا. ولا يشمل هذا التأخير أي تأخير في الفلترة.
يجب الإبلاغ عن أول عينة أداة استشعار خلال 400 مللي ثانية + 2 * sample_time لجهاز الاستشعار الذي يتم تشغيله. ومن المقبول أن تكون دقة هذه العيّنة 0.

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

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

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

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

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

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

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

يجب استخدام أداة استشعار TYPE_ACCELEROMETER والإبلاغ عنها.
يجب أن يكون قادرًا على الإبلاغ عن الأحداث التي تصل مدتها إلى 50 هرتز على الأقل لأجهزة Android Watch، لأنّ هذه الأجهزة تخضع لقيود أكثر صرامة في ما يتعلق بالطاقة و100 هرتز لجميع أنواع الأجهزة الأخرى.
"يجب" الإبلاغ عن الأحداث التي تصل ترددها إلى 200 هرتز على الأقل.
يجب أن يتوافق مع نظام إحداثيات أداة استشعار Android كما هو موضّح في واجهات برمجة تطبيقات Android. يجب أن تتوافق عمليات تنفيذ Android Automotive مع نظام إحداثيات أداة استشعار السيارة من Android.
يجب أن يكون قادرًا على القياس من السقوط الحر لما يصل إلى أربعة أضعاف الجاذبية (4 غرام) أو أكثر على أي محور.
يجب أن تكون دقة الصورة 12 بت على الأقل، وأن تصل إلى 16 بت على الأقل.
وينبغي معايرته أثناء الاستخدام إذا تغيرت الخصائص على مدار دورة الحياة وتم تعويضها، مع الحفاظ على معلمات التعويض بين عمليات إعادة تشغيل الجهاز.
يجب تعويض درجة الحرارة.
يجب أن لا يزيد الانحراف المعياري عن 0.05 م/ث^، حيث يجب حساب الانحراف المعياري على أساس كل محور في العينات التي تم جمعها خلال فترة لا تقل عن 3 ثوانٍ وبأسرع معدل عيّنات.
يجب تنفيذ أدوات الاستشعار المُركّبة TYPE_SIGNIFICANT_MOTION وTYPE_TILT_DETECTOR وTYPE_STEP_DETECTOR وTYPE_STEP_COUNTER كما هو موضح في مستند Android SDK. يُنصَح بشدة باستخدام أجهزة Android الحالية والجديدة لتنفيذ أداة الاستشعار المركّب TYPE_SIGNIFICANT_MOTION. وفي حال استخدام أي من أدوات الاستشعار هذه، يجب أن يكون مجموع استهلاك الطاقة دائمًا أقل من 4 ميغاواط وأن يكون لكلّ منها أقل من 2 ميغاواط و0.5 ميغاواط عندما يكون الجهاز في حالة ديناميكية أو ثابتة.
في حال تضمين مستشعر الجيروسكوب، يجب استخدام المستشعرَين المركّبين TYPE_GRAVITY وTYPE_LINEAR_ACCELERATION ومن "يُفترض" تثبيت أداة الاستشعار المركّبة TYPE_GAME_ROTATION_VECTOR. يُنصَح بشدة بأن تستخدم أجهزة Android الحالية والجديدة لتشغيل أداة الاستشعار TYPE_GAME_ROTATION_VECTOR.
يجب استخدام جهاز استشعار مركّب TYPE_ROTATION_VECTOR، في حال تضمين جهاز استشعار جيروسكوب وجهاز استشعار المغناطيسية.

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

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

يجب تنفيذ أداة استشعار TYPE_MAGNETIC_FIELD ومن المفترض أن تستخدم أيضًا أداة الاستشعار TYPE_MAGNETIC_FIELD_UNCALIBRATED. يُنصَح بشدة بأن تستخدم أجهزة Android الحالية والجديدة لتشغيل أداة الاستشعار TYPE_MAGNETIC_FIELD_UNCALIBRATED.
يجب أن تتمكّن من الإبلاغ عن أحداث تصل ترددها إلى 10 هرتز على الأقل، ويجب أن تُبلِغ عن أحداث تصل ترددها إلى 50 هرتز على الأقل.
يجب أن يتوافق مع نظام إحداثيات أداة استشعار Android كما هو موضّح في واجهات برمجة تطبيقات Android.
يجب أن يكون قادرًا على القياس بين -900 ميكرومتر و+900 ميكرومتر على كل محور قبل التشبع.
يجب أن تكون قيمة إزاحة الحديد الصلب أقل من 700 ميكرو طن، ويجب أن تكون قيمتها أقل من 200 ميكرو طن، عن طريق وضع مقياس المغناطيسية بعيدًا عن المجالات المغناطيسية الديناميكية (التي يتسبب فيها الحالي) والمجال المغناطيسي الثابت (الناتج عن المغناطيس).
يجب أن تكون درجة الدقة تساوي 0.6 ميكرومتر أو أكثر كثافة، ويجب أن تكون درجة الدقة تساوي 0.2 ميكرومتر أو أكثر كثافة.
يجب تعويض درجة الحرارة.
يجب أن يتيح المعايرة والتعويض على الإنترنت لتحيز الحديد الصلب، وأن يحتفظ بمعلمات التعويض بين عمليات إعادة تشغيل الجهاز.
يجب تطبيق التعويض باستخدام الحديد الناعم - يمكن إجراء المعايرة أثناء الاستخدام أو أثناء إنتاج الجهاز.
يجب أن يكون هناك انحراف معياري، يتم حسابه على أساس كل محور في العينات التي تم جمعها على مدى 3 ثوانٍ على الأقل في أسرع معدل أخذ بيانات، لا يزيد عن 0.5 ميكرومتر.
يجب استخدام جهاز استشعار مركّب TYPE_ROTATION_VECTOR، في حال تضمين جهاز استشعار لمقياس التسارع ومستشعر جيروسكوب.
قد يتم استخدام أداة استشعار TYPE_GeoMAGNETIC_ROTATION_VECTOR إذا تم أيضًا تشغيل جهاز استشعار لمقياس التسارع. ومع ذلك، في حال تطبيق هذا الوضع، يجب أن يستهلك أقل من 10 ميغاواط ومن المفترض أن يستهلك أقل من 3 ميغاواط عندما تكون أداة الاستشعار مسجَّلة في وضع الدفع عند 10 هرتز.

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

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

وننصح بشدة بأن يستمر الجهاز في إرسال مخرجات نظام تحديد المواقع العالمي (GPS)/ GNSS العادية إلى التطبيقات أثناء مكالمة هاتفية في حالات الطوارئ وعدم حظر إخراج الموقع الجغرافي أثناء مكالمة هاتفية للطوارئ.
يجب أن يتيح ذلك توفير نتائج الموقع الجغرافي بمعدّل لا يقل عن 1 هرتز عند طلبه من خلال "LocationManager#requestLocationUpdate".
يجب أن يتمكن هذا النظام من تحديد الموقع في ظروف السماء المفتوحة (الإشارات القوية، والمسارات المتعددة المهمة، وتقنية HDOP أقل من 2) في غضون 10 ثوانٍ (وقت أسرع للإصلاح الأول)، عند الاتصال باتصال إنترنت بسرعة 0.5 ميغابت في الثانية أو أكثر. يتم تلبية هذا الشرط عادةً من خلال استخدام أحد أشكال تقنية نظام تحديد المواقع العالمي (GPS)/نظام GNSS المدعومة أو المتوقعة لخفض وقت قفل نظام تحديد المواقع العالمي (GPS)/نظام GNSS (تشمل بيانات المساعدة الوقت المرجعي، والموقع المرجعي، وساعة القمر الصناعي المؤقت).
- بعد إجراء عملية حسابية للموقع الجغرافي، يُوصى بشدة أن يتمكن الجهاز من تحديد موقعه، في مكان مفتوح، خلال 10 ثوانٍ، عند إعادة تشغيل طلبات الموقع، وذلك بعد ساعة من الحساب الأولي للموقع، حتى عندما يتم تقديم الطلب اللاحق بدون اتصال بيانات و/أو بعد دورة الطاقة.
في السماء المفتوحة بعد تحديد الموقع الجغرافي، أثناء كونك ثابتًا أو متحركًا بسرعة تقل عن متر واحد في الثانية من التسارع:
- يجب أن يتمكن الجهاز من تحديد الموقع الجغرافي في نطاق 20 مترًا، وأن تكون سرعته ضمن نطاق 0.5 متر في الثانية، لا يقل عن 95% من الوقت.
- يجب أن يتتبع في وقت واحد ما لا يقل عن 8 أقمار صناعية من مجموعة نجوم واحدة وإعداد تقارير عنها عبر GnssStatus.Callback.
- وينبغي أن يكون قادرًا على تتبع ما لا يقل عن 24 قمرًا صناعيًا في وقت واحد، من مجموعات نجمية متعددة (على سبيل المثال، نظام تحديد المواقع العالمي (GPS) + واحد على الأقل من أقمار "غلوناس"، وبيدو، وغاليليو.
يجب أن يقدِّم التطبيق تقريرًا عن إنشاء تقنية GNSS من خلال واجهة برمجة التطبيقات الاختبارية "getGnssYearOfDevice".
من المستحسن بشدة استيفاء جميع المتطلبات أدناه ويجب استيفاؤها في حال تم الإبلاغ عن إنشاء تقنية GNSS على أنها العام "2016" أو الأحدث.
- يجب أن يبلغ عن قياسات GPS، فور العثور عليها، حتى إذا لم يتم الإبلاغ عن موقع تم حسابه من GPS/GNSS بعد.
- يجب أن يتم الإبلاغ عن النطاقات الزائفة ومعدلات النطاق الزائف في نظام تحديد المواقع العالمي (GPS) إذا كانت السرعة مستقرة أو تتحرك بسرعة أقل من 0.2 متر في الثانية المربعة بعد تحديد الموقع الجغرافي، وذلك في ظروف السماء المفتوحة بعد تحديد الموقع الجغرافي، والتي تكفي لحساب الموقع في نطاق 20 مترًا والسرعة في نطاق 0.2 متر في الثانية، بما لا يقل عن 95% من الوقت.

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

7.3.4 الجيروسكوب

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

يجب تنفيذ أداة استشعار TYPE_GYROSCOPE وينبغي أيضًا تنفيذ أداة الاستشعار TYPE_GYROSCOPE_UNCALIBRATED. يُنصَح بشدة بأن تستخدم أجهزة Android الحالية والجديدة لتشغيل أداة الاستشعار SENSOR_TYPE_GYROSCOPE_UNCALIBRATED.
يجب أن يكون قادرًا على قياس تغييرات الاتجاه لتصل إلى 1000 درجة في الثانية.
يجب أن يكون قادرًا على الإبلاغ عن الأحداث التي تصل مدتها إلى 50 هرتز على الأقل لأجهزة Android Watch، لأنّ هذه الأجهزة تخضع لقيود أكثر صرامة في ما يتعلق بالطاقة و100 هرتز لجميع أنواع الأجهزة الأخرى.
"يجب" الإبلاغ عن الأحداث التي تصل ترددها إلى 200 هرتز على الأقل.
يجب أن تكون دقة الفيديو 12 بت أو أكثر، وأن تكون ذات دقة 16 بت أو أكثر.
يجب تعويض درجة الحرارة فيه.
يجب معايرته وتعويضه أثناء الاستخدام، ويجب الاحتفاظ بمعلمات التعويض بين عمليات إعادة تشغيل الجهاز.
يجب أن يكون هناك تباين لا يزيد عن 1e-7 rad^2 / s^2 لكل هرتز (التباين لكل هرتز أو rad^2 / s) يُسمح بأن يختلف التباين باختلاف معدل أخذ العينات، ولكن يجب أن يكون مقيدًا بهذه القيمة. بمعنى آخر، إذا كنت تقيس تباين الجيروسكوب بمعدل أخذ عينات 1 هرتز، يجب ألا يزيد عن 1e-7 rad^2/s^2.
يجب استخدام جهاز الاستشعار المركّب TYPE_ROTATION_VECTOR في حال تضمين جهاز استشعار لمقياس التسارع وجهاز استشعار المغناطيسية.
في حال تضمين جهاز استشعار لمقياس التسارع، يجب استخدام المستشعرَين المركّبَين TYPE_GRAVITY وTYPE_LINEAR_ACCELERATION، ويجب تثبيت أداة الاستشعار المركّبة TYPE_GAME_ROTATION_VECTOR. يُنصَح بشدة بأن تستخدم أجهزة Android الحالية والجديدة لتشغيل أداة الاستشعار TYPE_GAME_ROTATION_VECTOR.

7.3.5. مقياس الضغط الجوي

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

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

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

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

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

بالنسبة إلى تطبيقات Android Automotive، يجب قياس درجة الحرارة داخل كابينة المركبة SENSOR_TYPE_AMBIENT_ الضرائب.

7.3.7. مقياس ضوء

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

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

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

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

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

في عمليات تنفيذ الأجهزة التي تتوافق مع مجموعة من أدوات الاستشعار ذات الجودة الأعلى التي يمكنها استيفاء جميع المتطلبات المدرَجة في هذا القسم، يجب أن يتم تحديد الدعم من خلال علامة الميزة android.hardware.sensor.hifi_sensors.

يجب أن يتوافق الجهاز الذي يعرّف عن أجهزة android.hardware.sensor.hifi_sensors مع جميع أنواع أدوات الاستشعار التالية التي تستوفي متطلبات الجودة على النحو التالي:

جهاز استشعار من النوع ACCELEROMETER
- يجب أن يتراوح نطاق القياس بين -8 غرام و+8 غرام على الأقل.
- يجب أن تكون درجة دقة القياس 1024 LSB/G على الأقل.
- يجب أن يكون الحد الأدنى لتكرار القياس 12.5 هرتز أو أقل.
- يجب أن يبلغ الحد الأقصى لتردد القياس 400 هرتز أو أعلى.
- يجب أن يكون هناك تشويش في القياس ليس أعلى من 400 uG/بإدارة هرتز.
- يجب استخدام نموذج لا يتطلب تنشيطًا لهذا المستشعر مع إمكانية تخزين مؤقت لما لا يقل عن 3000 حدث استشعار.
- يجب أن يكون استهلاك الطاقة بالدفعة أقل من 3 ميغاواط.
- من المفترض أن يكون لها ثبات في انحياز الضوضاء الثابت بقيمة \<15 ميكروغرام لأعضاء الشاشة منتج ظرفاء تردديء من مجموعة البيانات الثابتة التي تبلغ 24 ساعة.
- يُفترض أن يكون هناك تغيُّر في الانحياز مقارنةً بدرجة الحرارة التي تبلغ ≤ +/- 1 مليغرام / درجة مئوية.
- يجب أن يكون الخط غير الخطي الأكثر ملاءمة بنسبة ≤ 0.5%، وتغيّر الحساسية مقابل درجة الحرارة 0.03%/درجة مئوية أو أقل.
جهاز استشعار SENSOR_TYPE_GYROSCOPE
- يجب أن يتراوح نطاق القياس بين -1000 و +1000 نقطة في الثانية على الأقل.
- يجب أن تكون درجة دقة القياس 16 LSB/dps على الأقل.
- يجب أن يكون الحد الأدنى لتكرار القياس 12.5 هرتز أو أقل.
- يجب أن يبلغ الحد الأقصى لتردد القياس 400 هرتز أو أعلى.
- يجب أن يكون هناك تشويش في قياس حالة الجهاز لا يزيد عن 0.014 درجة/ثانية/وإعادة هرتز.
- "ينبغي" أن يحتوي على استقرار تحيز ثابت لـ < 0.0002 °/s لأعضاء ©Hz من مجموعة البيانات الثابتة لمدة 24 ساعة
- يُفترض أن يكون هناك تغيُّر في الانحياز مقارنةً بدرجة الحرارة التي تبلغ ≤ +/- 0.05 درجة/ ثانية / درجة مئوية.
- من المفترض أن يتغيّر مستوى الحساسية مقارنةً بدرجة الحرارة التي تقل عن 0.02% / درجة مئوية.
- يُفترض أن يحتوي الخط غير الخطي على أفضل ملاءمة، وهو ≤ 0.2%.
- من المفترض أن تكون كثافة الضوضاء 0.007 درجة/ثانية/وإعادة هرتز أو أقل.
SENSOR_TYPE_GYROSCOPE_UNCALIBRATED تستوفي متطلبات الجودة نفسها مثل SENSOR_TYPE_GYROSCOPE.
SENSOR_TYPE_geoMAGNETIC_FIELD
- يجب أن يتراوح نطاق القياس بين -900 و +900 uT على الأقل.
- يجب أن تكون درجة دقة القياس 5 LSB/uT على الأقل.
- يجب أن يكون الحد الأدنى لتكرار القياس 5 هرتز أو أقل.
- يجب أن يبلغ الحد الأقصى لتردد القياس 50 هرتز أو أعلى.
- يجب أن يكون هناك تشويش في القياس ليس أعلى من 0.5 وحدة uT.
SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED تنطبق عليهم متطلبات الجودة نفسها المذكورة في SENSOR_TYPE_GEOMAGNETIC_FIELD بالإضافة إلى ما يلي:
- يجب استخدام نموذج لا يتطلب تنشيطًا لهذا المستشعر مع إمكانية تخزين مؤقت لما لا يقل عن 600 حدث استشعار.
SENSOR_TYPE_PRESSURE
- يجب أن يتراوح نطاق القياس بين 300 و1100 هيلتر باسك على الأقل.
- يجب أن تكون درجة دقة القياس 80 LSB/hPa على الأقل.
- يجب أن يكون الحد الأدنى لتكرار القياس 1 هرتز أو أقل.
- يجب أن يبلغ الحد الأقصى لتردد القياس 10 هرتز أو أعلى.
- يجب أن يكون هناك تشويش في القياس ليس أعلى من 2 Pa/fill هرتز.
- يجب استخدام نموذج لا يتطلب تنشيطًا لهذا المستشعر مع إمكانية تخزين مؤقت لما لا يقل عن 300 حدث استشعار.
- يجب أن يكون استهلاك الطاقة بالدفعة أقل من 2 ميغاواط.
SENSOR_TYPE_GAME_ROTATION_VECTOR
- يجب استخدام نموذج لا يتطلب تنشيطًا لهذا المستشعر مع إمكانية تخزين مؤقت لما لا يقل عن 300 حدث استشعار.
- يجب أن يكون استهلاك الطاقة بالدفعة أقل من 4 ميغاواط.
SENSOR_TYPE_SIGNIFICANT_MOTION
- يجب ألا يقل استهلاك الطاقة عن 0.5 مللي واط عندما يكون الجهاز ثابتًا و1.5 مللي واط عند تحرك الجهاز.
جهاز استشعار SENSOR_TYPE_STEP_DETECTOR
- يجب استخدام نموذج لا يتطلب تنشيطًا لهذا المستشعر مع إمكانية تخزين مؤقت لما لا يقل عن 100 حدث استشعار.
- يجب ألا يقل استهلاك الطاقة عن 0.5 مللي واط عندما يكون الجهاز ثابتًا و1.5 مللي واط عند تحرك الجهاز.
- يجب أن يكون استهلاك الطاقة بالدفعة أقل من 4 ميغاواط.
SENSOR_TYPE_STEP_COUNTER
- يجب ألا يقل استهلاك الطاقة عن 0.5 مللي واط عندما يكون الجهاز ثابتًا و1.5 مللي واط عند تحرك الجهاز.
SENSOR_TILT_DETECTOR
- يجب ألا يقل استهلاك الطاقة عن 0.5 مللي واط عندما يكون الجهاز ثابتًا و1.5 مللي واط عند تحرك الجهاز.

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

يجب أن يكون الطابع الزمني للحدث نفسه الذي تم الإبلاغ عنه من خلال مقياس التسارع وأداة استشعار الجيروسكوب ومقياس المغناطيسية في نطاق 2.5 ملي ثانية من بعضها بعضًا.
يجب أن تكون الطوابع الزمنية لحدث أداة استشعار الجيروسكوب في نفس القاعدة الزمنية للنظام الفرعي للكاميرا، وأن تكون خلال 1 ملي ثانية من الخطأ.
يجب أن تسلم أجهزة الاستشعار عالية الدقة عينات إلى التطبيقات خلال 5 ملي ثانية من وقت توفر البيانات في أداة الاستشعار الفعلية إلى التطبيق.
يجب ألا يزيد استهلاك الطاقة عن 0.5 مللي واط عندما يكون الجهاز ثابتًا و2.0 ميغاواط عند تحرك الجهاز عند تفعيل أي مجموعة من أدوات الاستشعار التالية:
- SENSOR_TYPE_SIGNIFICANT_MOTION
- جهاز استشعار SENSOR_TYPE_STEP_DETECTOR
- SENSOR_TYPE_STEP_COUNTER
- جهاز الاستشعار

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

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

SENSOR_TYPE_PROXIMITY: 100 حدث من أحداث أداة الاستشعار

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

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

يجب أن تعلن عن توافقها مع ميزة android.hardware.fingerprint.
يجب أن يتم تنفيذ واجهة برمجة التطبيقات المناظرة بالكامل كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
يجب أن يكون معدل قبول خاطئ لا يزيد عن 0.002%.
يُنصح بشدة بأن يكون معدّل الرفض الخاطئ أقل من %10 وفقًا لقياسه على الجهاز.
يُنصح بشدة بأن يكون وقت الاستجابة أقل من ثانية واحدة، ويتم قياسه من وقت لمس أداة استشعار بصمة الإصبع إلى أن يتم فتح قفل الشاشة، وذلك لإصبع واحد مسجَّل.
يجب أن يبلغ الحد الأقصى لمعدّل الزحف 30 ثانية على الأقل بعد خمس محاولات خاطئة لإثبات الهوية باستخدام بصمة الإصبع.
يجب أن يتوفّر ملف تخزين مفاتيح مستنِد إلى الجهاز وإجراء مطابقة بصمة الإصبع في بيئة تنفيذ موثوقة (TEE) أو على شريحة ذات قناة آمنة إلى TEE.
يجب أن يتم تشفير جميع بيانات بصمات الأصابع التي يمكن التعرّف عليها والمصادقة عليها بطريقة مشفّرة بحيث لا يمكن الحصول عليها أو قراءتها أو تغييرها خارج بيئة التنفيذ الموثوقة (TEE) على النحو الموضَّح في إرشادات التنفيذ على موقع "المشروع المفتوح المصدر" لنظام التشغيل Android.
يجب أن يتم منع إضافة بصمة إصبع بدون إنشاء سلسلة من الثقة أولاً من خلال مطالبة المستخدم بتأكيد وجود بيانات اعتماد حالية أو إضافة بيانات اعتماد جديدة للجهاز (رقم التعريف الشخصي أو النقش أو كلمة المرور) مؤمّنة بواسطة TEE. ويوفّر تنفيذ "مشروع مفتوح المصدر لنظام Android" الآلية في إطار العمل لإجراء ذلك.
يجب ألا تمكّن تطبيقات الجهات الخارجية من التمييز بين بصمات الأصابع الفردية.
يجب الالتزام بعلامة DevicePolicyManager.KEYGUARD_DISABLE_FINGERPrint.
عند الترقية من إصدار أقدم من Android 6.0، يجب نقل بيانات بصمة الإصبع بأمان لاستيفاء المتطلبات المذكورة أعلاه أو إزالتها.
يجب استخدام رمز بصمة الإصبع في Android الوارد في "المشروع المفتوح المصدر لنظام Android".

7.3.11. أدوات الاستشعار في Android Automotive فقط

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

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

يجب توفير الأدوات الحالية مثل SENSOR_TYPE_GEAR في عمليات تنفيذ Android Automotive.

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

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

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

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

7.3.11.4. سرعة العجلة

يجب أن توفّر عمليات تنفيذ Android Automotive سرعة المركبة المحددة على أنها SENSOR_TYPE_CAR_SPEED.

7.3.12. أداة استشعار الوضعية

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

يجب استخدام أداة استشعار TYPE_POSE_6DOF والإبلاغ عنها.
يجب أن يكون أكثر دقة من متجه الدوران وحده.

7.4. إمكانية اتصال البيانات

7.4.1. الاتصالات الهاتفية

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

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

7.4.1.1. التوافق مع حظر الأرقام

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

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

7.4.2 معيار IEEE 802.11 (لشبكات Wi-Fi)

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

يجب الإبلاغ عن الميزة android.hardware.wifi.
يجب تنفيذ multicast API كما هو موضّح في مستندات حزمة تطوير البرامج (SDK).
يجب أن يتوافق مع نظام أسماء النطاقات ذي البث المتعدد (mDNS) ويجب ألا يصف حزم mDNS (224.0.0.251) في أي وقت من التشغيل، بما في ذلك:
- حتى عندما لا تكون الشاشة في حالة نشطة.
- لتطبيقات أجهزة Android TV، حتى عندما يكون الجهاز في حالة وضع الاستعداد

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

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

يجب الإبلاغ عن ميزة الأجهزة android.hardware.wifi.direct.
يجب أن يدعم التشغيل العادي لشبكة Wi-Fi.
"ينبغي" أن يسمح بتشغيل Wi-Fi وWi-Fi Direct في الوقت نفسه.

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

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

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

7.4.3. البلوتوث

يجب أن تكون التطبيقات في Android Watch متوافقة مع البلوتوث. يجب أن تكون تطبيقات Android TV متوافقة مع البلوتوث وتقنية Bluetooth LE. يجب أن تكون عمليات تنفيذ Android Automotive متوافقة مع البلوتوث، كما يجب أن تكون متوافقة مع تقنية Bluetooth LE.

إنّ عمليات تنفيذ الأجهزة التي تتيح استخدام ميزة android.hardware.vr.high_performance يجب أن تتوافق مع Bluetooth 4.2 وBluetooth LE Data Length.

يتيح Android استخدام البلوتوث والبلوتوث منخفض الطاقة. في عمليات تنفيذ الأجهزة التي تتيح استخدام البلوتوث وتقنية البلوتوث منخفض الطاقة، يجب توضيح ميزات النظام الأساسي ذات الصلة (android.hardware.Bluetooth وandroid.hardware.Bluetooth_le على التوالي) وتنفّذ واجهات برمجة التطبيقات للنظام الأساسي. يجب أن تنفِّذ عمليات تنفيذ الأجهزة ملفات بلوتوث ذات صلة، مثل A2DP وAVCP وOBEX وما إلى ذلك حسب ما يتناسب مع الجهاز.

يجب أن تتيح عمليات تنفيذ Android Automotive استخدام ملف الوصول إلى الرسائل (MAP). يجب أن تتيح عمليات تنفيذ Android Automotive استخدام ملفات البلوتوث التالية:

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

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

يجب أن تفصح عن ميزة الجهاز android.hardware.Bluetooth_le.
يجب تفعيل واجهات برمجة تطبيقات البلوتوث المستندة إلى GATT (الملف الشخصي للسمات العامة) كما هو موضَّح في مستندات حزمة تطوير البرامج (SDK) وandroid.Bluetooth.
يُوصى بشدة بتنفيذ مهلة عنوان خاص قابل للتحليل لا تزيد عن 15 دقيقة، وتدوير العنوان عند انتهاء المهلة لحماية خصوصية المستخدم.
يجب أن تتوافق مع إلغاء تحميل منطق الفلترة إلى مجموعة شرائح البلوتوث عند تنفيذ ScanFilter API، ويجب أن يتم الإبلاغ عن القيمة الصحيحة لمكان تنفيذ منطق الفلترة عند طلب البحث باستخدام الطريقة android.Bluetooth.BluetoothAdapter.isOffloadingFilteringsupported() .
"يجب توفير" إلغاء تحميل المسح المجمّع إلى مجموعة شرائح البلوتوث، ولكن إذا لم يكن متوافقًا، يجب الإبلاغ عن القيمة "خطأ" عند طلب البحث باستخدام الطريقة android.Bluetooth.BluetoothAdapter.isOffloadingScanBatchingSupported() .
"يجب أن تتيح الإعلانات المتعدّدة" باستخدام 4 خانات على الأقل، ولكن إذا لم تكن متوافقة، يجب الإبلاغ عن القيمة "خطأ" عند طلب البحث عبر طريقة android.Bluetooth.BluetoothAdapter.isMultipleAdvertisingmentSupported() .

7.4.4 الاتصالات القريبة المدى

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

يجب الإبلاغ عن ميزة android.hardware.nfc من طريقة android.content.pm.PackageManager.hasSystemFeature().
يجب أن تكون قادرًا على قراءة رسائل NDEF وكتابتها باستخدام معايير NFC التالية:
- يجب أن تتوفر لديه القدرة على العمل كقارئ أو كاتب في منتدى NFC (وفقًا للمواصفات الفنية لمنتدى NFCForum-TS-DigitalProtocol-1.0) من خلال معايير NFC التالية:
  - NFCA (ISO14443-3A)
  - NFCB (ISO14443-3B)
  - NfcF (JIS X 6319-4)
  - IsoDep (ISO 14443-4)
  - أنواع علامات منتدى NFC 1 و2 و3 و4 (يحدّدها منتدى NFC)
- يُنصح بشدة بأن تكون قادرًا على قراءة رسائل NDEF وكتابتها وكذلك البيانات الأولية عبر معايير NFC التالية. تجدر الإشارة إلى أنّه على الرغم من أنّ معايير الاتصال القصير المدى (NFC) الواردة أدناه موصى بها بشدة، فمن المقرر تغييرها في "تعريف التوافق" لإصدار مستقبلي. هذه المعايير اختيارية في هذا الإصدار، ولكنّها ستكون مطلوبة في الإصدارات المستقبلية. ننصح بشدة الأجهزة الحالية والجديدة التي تعمل على هذا الإصدار من Android باستيفاء هذه المتطلبات الآن حتى تتمكّن هذه الأجهزة من الترقية إلى إصدارات النظام الأساسي المستقبلية.
  - NfcV (ISO 15693)
- يجب أن تكون قادرة على قراءة الرمز الشريطي وعنوان URL (إذا كانا مشفّرين) لمنتجات الرمز الشريطي لتقنية NFC (إذا كانت مشفّرة).
- يجب أن تكون قادرة على نقل البيانات واستلامها عبر المعايير والبروتوكولات التالية:
  - ISO 18092
  - الإصدار 1.2 من LLCP (مُحدَّد من قِبل منتدى NFC)
  - بروتوكول SDP 1.0 (محدد من قِبل منتدى NFC)
  - بروتوكول الدفع NDEF
  - SNEP 1.0 (تم تعريفه من قِبل منتدى NFC)
- يجب أن يتوفر الدعم لـ شعاع Android.
- يجب تنفيذ خادم SNEP التلقائي. يجب إرسال رسائل NDEF الصالحة التي يستلمها خادم SNEP التلقائي إلى التطبيقات باستخدام الغرض android.nfc.ACTION_NDEF_DISCOVERED. يجب ألا يؤدي إيقاف شعاع Android في الإعدادات إلى إيقاف إرسال رسالة NDEF الواردة.
- يجب أن يلتزم بالهدف android.settings.NFCSHARING_SETTINGS من أجل عرض إعدادات المشاركة عبر NFC.
- يجب تنفيذ خادم NPP. يجب معالجة الرسائل المُستلَمة على خادم NPP بالطريقة نفسها التي تتم بها معالجة خادم SNEP التلقائي.
- يجب تنفيذ برنامج SNEP ومحاولة إرسال P2P NDEF الصادر إلى خادم SNEP التلقائي عند تفعيل ميزة شعاع Android. في حال عدم العثور على خادم SNEP تلقائي، على العميل محاولة الإرسال إلى خادم NPP.
- يجب السماح بالأنشطة التي تعمل في المقدّمة لضبط رسالة NDEF P2P الصادرة باستخدام android.nfc.NfcAdapter.setNdefPushMessage وandroid.nfc.NfcAdapter.setNdefPushMessageCallback وandroid.nfc.NfcAdapter.enableForegroundNdefPush.
- يجب استخدام إيماءة أو تأكيد على الشاشة، مثل "Touch to Beam"، قبل إرسال رسائل P2P NDEF الصادرة.
- "يجب تفعيل شعاع Android" تلقائيًا ويجب أن تتمكن من الإرسال والاستقبال باستخدام شعاع Android، حتى عند تفعيل وضع P2p آخر خاص بتقنية NFC.
- يجب أن يتيح تسليم اتصال NFC إلى البلوتوث عندما يكون الجهاز متوافقًا مع ملف تعريف الدفع لعناصر البلوتوث. يجب أن تتيح عمليات تنفيذ الأجهزة تسليم الاتصال بالبلوتوث عند استخدام تقنية android.nfc.NfcAdapter.setBeamPushUris، من خلال تطبيق مواصفات " الإصدار 1.2 من عملية نقل الاتصال " و" إقران البلوتوث الآمن باستخدام الإصدار 1.0 " من منتدى NFC. يجب أن يؤدي هذا التنفيذ إلى تنفيذ خدمة شركة ذات مسؤولية محدودة (LLP) للتسليم باسم الخدمة "urn:nfc:sn:handover" لتبديل سجلات طلب/نقل البيانات عبر NFC، كما يجب أن تستخدم ملف Bluetooth Object Push Profile (ملف الدفع بواسطة عنصر البلوتوث) لنقل البيانات الفعلية عبر البلوتوث. لأسباب قديمة (للحفاظ على التوافق مع الأجهزة التي تعمل بالإصدار 4.1 من نظام التشغيل Android)، يجب أن يقبل التنفيذ طلبات SNEP GET لتبادل طلبات التسليم/السجلات المحددة عبر NFC. ومع ذلك، ينبغي ألا يرسل التنفيذ نفسه طلبات SNEP GET لإجراء نقل الاتصال.
- يجب إجراء استطلاع لكل التكنولوجيات المتوافقة أثناء استخدام وضع اكتشاف NFC.
- يجب أن يكون في وضع الاكتشاف عبر NFC عندما يكون الجهاز نشطًا وشاشته نشطة ومقفلة.

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

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

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

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

يجب الإبلاغ عن قيمة ثابتة لميزة android.hardware.nfc.hcef.
يجب تنفيذ واجهات برمجة تطبيقات NfcF Card Emulation API على النحو المحدّد في حزمة تطوير البرامج (SDK) لنظام التشغيل Android.

بالإضافة إلى ذلك، قد تشمل عمليات تنفيذ الأجهزة دعم القارئ/الكاتب لتقنيات MIFARE التالية.

الإصدار الكلاسيكي من MiFARE
عدسة خفيف جدًا
NDEF على MIFARE Classic

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

يجب تنفيذ واجهات برمجة تطبيقات Android المقابلة كما هو مُوثَّق في حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
يجب الإبلاغ عن الميزة com.nxp.mifare من خلال الإجراء android.content.pm.PackageManager.hasSystemFeature(). يُرجى العِلم أنّ هذه الميزة ليست ضمن ميزات Android العادية، وبالتالي لا تظهر بشكل ثابت في الفئة android.content.pm.PackageManager.
يجب ألا تستخدم واجهات برمجة تطبيقات Android المقابلة أو تبلغ عن ميزة com.nxp.mifare ما لم تستخدم أيضًا دعمًا عامًا لتقنية NFC كما هو موضّح في هذا القسم.

إذا كان الجهاز المستخدَم لا يتضمّن أجهزة NFC، يجب ألا يفصح عن ميزة android.hardware.nfc من خلال الطريقة android.content.pm.PackageManager.hasSystemFeature()، ويجب أن تستخدم Android NFC API بدون وظيفة.

بما أنّ الفئتَين android.nfc.NdefMessage وandroid.nfc.NdefRecord يمثّلان تنسيقًا لتمثيل البيانات مستقلاً عن البروتوكول، يجب أن تستخدم عمليات تنفيذ الأجهزة واجهات برمجة التطبيقات هذه حتى إذا كانت لا تتيح استخدام تقنية NFC أو تعرض السمة android.hardware.nfc.

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

يجب أن تشتمل عمليات تنفيذ الأجهزة على دعم لشكل واحد أو أكثر من أشكال شبكات البيانات. ويجب أن تتضمّن عمليات تنفيذ الأجهزة على وجه التحديد توافقًا لمعيار بيانات واحد على الأقل بسرعة 200 كيلوبت في الثانية أو أكثر. تشمل أمثلة التكنولوجيات التي تستوفي هذا الشرط EDGE وHSPA وEV-DO و802.11g وإيثرنت ورقم PAN للبلوتوث وما إلى ذلك.

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

قد تنفِّذ الأجهزة أكثر من شكل من أشكال اتصال البيانات.

يجب أن تشتمل الأجهزة على حزمة شبكات IPv6، وأن تتيح اتصال IPv6 باستخدام واجهات برمجة التطبيقات المُدارة، مثل java.net.Socket وjava.net.URLConnection، بالإضافة إلى واجهات برمجة التطبيقات الأصلية، مثل مقابس AF_INET6. ويعتمد المستوى المطلوب من دعم IPv6 على نوع الشبكة، كما يلي:

يجب أن تتوافق الأجهزة التي تتوافق مع شبكات Wi-Fi مع بروتوكولَي IPv6 وحزمتَي الحزم فقط عبر شبكة Wi-Fi.
يجب أن تتيح الأجهزة التي تدعم شبكات الإيثرنت عملية التكديس المزدوج على إيثرنت.
يجب أن تتيح الأجهزة التي تتوافق مع بيانات شبكة الجوّال تشغيل بروتوكول IPv6 (إصدار IPv6 فقط وربما تكديس مزدوج) على بيانات شبكة الجوّال.
عند اتصال جهاز بأكثر من شبكة في الوقت نفسه (على سبيل المثال، Wi-Fi وبيانات شبكة الجوّال)، يجب أن تستوفي هذه الأجهزة في وقت واحد هذه المتطلبات على كل شبكة تتصل بها.

يجب تمكين IPv6 افتراضيًا.

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

يجب الحفاظ على اتصال IPv6 في وضع القيلولة.

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

يجب تفعيل إعداد المزامنة التلقائية الرئيسي تلقائيًا في عمليات تنفيذ الأجهزة لكي تعرض الطريقة getMasterSyncAutomatic() القيمة "true".

7.4.7. توفير البيانات

يُنصَح بشدة بإجراءات تنفيذ الأجهزة التي تستخدم اتصال تفرض تكلفة استخدام لتوفير وضع "توفير البيانات".

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

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

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

يجب عرض القيمة RESTRICT_BACKGROUND_STATUS_DISABLED في ConnectivityManager.getRestrictBackgroundStatus()
يجب ألا يتم بث ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED
يجب أن يكون لديك نشاط يعالج هدف Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS، ولكن قد يتم تنفيذه مؤقتًا.

7.5. الكاميرات

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

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

7.5.1. الكاميرا الخلفية

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

يجب الإبلاغ عن علامة الميزة android.hardware.camera وandroid.hardware.camera.any.
يجب أن تبلغ دقة الفيديو 2 ميغابكسل على الأقل.
يجب أن يتوفر إما التركيز التلقائي للجهاز أو التركيز التلقائي للبرامج في برنامج تشغيل الكاميرا (الشفاف لبرامج التطبيق).
قد يحتوي على أجهزة ذات تركيز ثابت أو EDOF (عمق مجال ممتد).
وقد يتضمن فلاشًا. إذا كانت الكاميرا تشتمل على وميض، يجب ألا تتم إضاءة ضوء الفلاش أثناء تسجيل مثيل android.hardware.Camera.PreviewCallback على سطح معاينة الكاميرا، ما لم يفعِّل التطبيق الفلاش بشكل صريح من خلال تفعيل السمتَين FLASH_mode_OFF أو FLASH_mode_ON لكائن Camera.parameters. تجدر الإشارة إلى أنّ هذا القيد لا ينطبق على تطبيق الكاميرا المضمَّن في النظام، بل فقط على التطبيقات التابعة لجهات خارجية التي تستخدم Camera.PreviewCallback.

7.5.2 الكاميرا الأمامية

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

يجب الإبلاغ عن علامة الميزة android.hardware.camera.any وandroid.hardware.camera.front.
يجب أن تكون دقة VGA (640×480 بكسل) على الأقل.
يجب ألا تستخدم كاميرا أمامية كإعداد تلقائي لواجهة برمجة تطبيقات الكاميرا. توفِّر واجهة برمجة التطبيقات للكاميرا في Android دعمًا خاصًا للكاميرات الأمامية، ويجب ألا تضبط واجهة برمجة التطبيقات واجهة برمجة التطبيقات للتعامل مع الكاميرا الأمامية باعتبارها الكاميرا الخلفية التلقائية، حتى إذا كانت الكاميرا الوحيدة على الجهاز.
قد تتضمّن ميزات (مثل التركيز التلقائي والفلاش وما إلى ذلك) المتوفّرة للكاميرات الخلفية كما هو موضَّح في القسم 7.5.1.
يجب أن يعكس البث أفقيًا (أي أن يعكس المحتوى المطابق) الذي يعرضه التطبيق في CameraPreview على النحو التالي:
- إذا كان بإمكان المستخدم تدوير تصميم الجهاز (مثلاً من خلال مقياس التسارع أو يدويًا من خلال إدخال المستخدم)، يجب أن يتم عكس معاينة الكاميرا أفقيًا بالنسبة إلى الاتجاه الحالي للجهاز.
- إذا طلب التطبيق الحالي صراحةً تدوير شاشة الكاميرا عبر استدعاء الإجراء android.hardware.camera.setDisplayOrientation()، يجب أن يتم عكس معاينة الكاميرا أفقيًا بالنسبة إلى الاتجاه المحدّد من خلال التطبيق.
- وبخلاف ذلك، يجب عكس المعاينة على طول المحور الأفقي التلقائي للجهاز.
يجب أن تعكس الصورة المعروضة من خلال مشاهدة المشاركة بالطريقة نفسها التي تظهر بها في بث صورة معاينة الكاميرا. إذا كان تنفيذ الجهاز لا يوفِّر ميزة ما بعد المشاهدة، من الواضح أنّه لا ينطبق هذا الشرط.
يجب ألا تعكس عمليات بث الفيديو أو الصور الثابتة النهائية التي تم التقاطها والتي تم إرجاعها إلى عمليات معاودة الاتصال بالتطبيق أو المرتبطة بمساحة تخزين الوسائط.

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

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

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

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

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

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

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

إذا لم يطلق أحد التطبيقات استدعاء android.hardware.camera.parameters.setPreviewFormat(int)، يجب أن يستخدم الجهاز android.hardware.PixelFormat.YCbCr_420_SP لبيانات المعاينة المقدَّمة لعمليات معاودة الاتصال بالتطبيق.
إذا سجّل أحد التطبيقات مثيل android.hardware.camera.PreviewCallback واستدعيت النظام طريقة onPreviewFrame() عندما يكون تنسيق المعاينة هو YCbCr_420_SP، فيجب أن تكون البيانات في البايت[] التي يتم تمريرها إلى onPreviewFrame() بتنسيق ترميز NV21. بمعنى آخر، يجب أن يكون NV21 هو الإعداد التلقائي.
بالنسبة إلى android.hardware.camera، يجب أن تتيح عمليات تنفيذ الأجهزة استخدام تنسيق YV12 (كما هو موضّح على الشكل الثابت android.graphics.ImageFormat.YV12) لمعاينات الكاميرا لكلّ من الكاميرات الأمامية والخلفية. (قد يستخدم برنامج ترميز الفيديو والكاميرا في الجهاز أيّ تنسيق بكسل أصلي، ولكن يجب أن يتيح تنفيذ الجهاز التحويل إلى YV12).
بالنسبة إلى الأجهزة android.hardware.camera2، يجب أن تتيح عمليات تنفيذ الأجهزة استخدام التنسيقَين android.hardware.ImageFormat.YUV_420_888 وandroid.hardware.ImageFormat.JPEG كمخرجات من خلال واجهة برمجة التطبيقات android.media.ImageReader.

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

يجب أن تتعرّف عمليات تنفيذ الأجهزة على كل اسم مَعلمة يتمّ تحديدها كقيمة ثابتة في فئة android.hardware.camera.رامs إذا كانت الأجهزة الأساسية تتيح هذه الميزة. إذا لم تكن معدّات الجهاز تتيح استخدام إحدى الميزات، يجب أن تعمل واجهة برمجة التطبيقات على النحو الموضّح في المستندات. في المقابل، يجب ألا تلتزم عمليات تنفيذ الأجهزة بثوابت السلسلة التي يتم تمريرها إلى الطريقة android.hardware.camera.setparameters() غير تلك الموثَّقة كثوابت في android.hardware.camera.parameters. ويعني هذا أنّ عمليات تنفيذ الأجهزة يجب أن تتوافق مع جميع مَعلمات "الكاميرا" العادية إذا كان الجهاز يسمح بذلك، ويجب ألا تتيح استخدام أنواع مَعلمات "الكاميرا" المخصَّصة. على سبيل المثال، يجب أن تتوافق التطبيقات على الأجهزة التي تتيح التقاط الصور باستخدام تقنيات التصوير بنطاق عالي الديناميكية (HDR) مع مَعلمة الكاميرا Camera.SCENE_mode_HDR.

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

يجب أن تشير عمليات تنفيذ الأجهزة أيضًا إلى إمكانات الكاميرا الفردية الخاصة بـ android.hardware.camera2 من خلال السمة android.request.availableCapabilities وتعرض علامات الميزات المناسبة. على الجهاز تحديد علامة الميزة إذا كان أي من أجهزة الكاميرا المتصلة به يتيح هذه الميزة.

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

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

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

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

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

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

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

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

الكثافة وحجم الشاشة	جهاز 32 بت	جهاز 64 بت
أجهزة Android Watch (بسبب شاشاتها الأصغر)	416 ميغابايت	غير سارٍ
280 نقطة لكل بوصة أو أقل على الشاشات الصغيرة أو العادية mdpi أو أقل على الشاشات الكبيرة ldpi أو أقل على الشاشات الكبيرة جدًا	512 ميغابايت	816 ميغابايت
xhdpi أو أعلى على الشاشات الصغيرة/العادية hdpi أو أعلى على الشاشات الكبيرة mdpi أو أعلى على الشاشات الكبيرة جدًا	608 ميغابايت	944 ميغابايت
400 نقطة لكل بوصة أو أعلى على الشاشات الصغيرة أو العادية xhdpi أو أعلى على الشاشات الكبيرة tvdpi أو أعلى على الشاشات الكبيرة جدًا	896 ميغابايت	1280 ميغابايت
560 نقطة لكل بوصة أو أعلى على الشاشات الصغيرة أو العادية 400 نقطة لكل بوصة أو أكثر على الشاشات الكبيرة xhdpi أو أعلى على الشاشات الكبيرة جدًا	1344 ميغابايت	1824 ميغابايت

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

عمليات تنفيذ الأجهزة التي تتوفّر بها ذاكرة أقل من 512 ميغابايت للنواة ومساحة المستخدم، ما لم يجب أن تعرض ساعة Android Watch القيمة "صحيح" لـ ActivityManager.isLowRamDevice().

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

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

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

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

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

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

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

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

يجب تنفيذ عمليات تنفيذ الأجهزة على النحو الموثَّق على الإذن android.permission.WRITE_EXTERNAL_STORAGE في مساحة التخزين المشتركة هذه. يجب أن تكون مساحة التخزين المشتركة قابلة للكتابة من خلال أي تطبيق يحصل على هذا الإذن.

يجب أن تكون عمليات تنفيذ الأجهزة التي تتضمّن مسارات تخزين مشتركة متعددة (مثل فتحة بطاقة SD ووحدة تخزين داخلية مشتركة) مسموحًا بها فقط تطبيقات Android بامتيازات خاصة لديها إذن WRITE_EXTERNAL_STORAGE بالكتابة في وحدة التخزين الخارجية الثانوية، باستثناء عند الكتابة إلى الأدلة الخاصة بالحزمة أو داخل URI التي يتم عرضها عن طريق تنشيط ACTION_OPEN_DOCUMENT_TREE intent.

ومع ذلك، يجب أن تعرض عمليات تنفيذ الأجهزة المحتوى من كلا مسارَي التخزين بشفافية من خلال خدمة فحص الوسائط من Android وandroid.provider.MediaStore.

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

يجب أن يكون متوافقًا مع مضيف بروتوكول نقل الوسائط (MTP) المرجعي لنظام التشغيل Android، وهو نقل ملفات Android.
يجب أن يتم الإبلاغ عن فئة جهاز USB بقيمة 0x00.
يجب الإبلاغ عن اسم واجهة USB بتنسيق "MTP".

7.6.3. مساحة تخزين قابلة للاستخدام

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

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

7.7. USB

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

7.7.1. وضع الأجهزة الملحقة بكابل USB

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

يجب أن يكون المنفذ قابلاً للاتصال بمضيف USB يحتوي على منفذ USB عادي من النوع A أو من النوع C.
يجب أن يستخدم المنفذ جهاز USB مصغر-B أو مايكرو AB أو نوع C. يُنصَح بشدة باستيفاء هذه المتطلبات على أجهزة Android الحالية والجديدة حتى تتمكّن هذه الأجهزة من الترقية إلى إصدارات النظام الأساسي المستقبلية.
يجب أن يكون المنفذ في أسفل الجهاز (وفقًا للاتجاه الطبيعي) أو أن يعمل على تفعيل دوران شاشة البرنامج في جميع التطبيقات (بما في ذلك الشاشة الرئيسية)، لكي يتم رسم الشاشة بشكل صحيح عندما يكون الجهاز موجهًا إلى المنفذ في الأسفل. يُنصَح بشدة باستيفاء هذه المتطلبات على أجهزة Android الحالية والجديدة حتى تتمكّن هذه الأجهزة من الترقية إلى إصدارات الأنظمة الأساسية المستقبلية.
يجب أن يسمح لمضيف USB المتصل بجهاز Android بالوصول إلى محتوى وحدة تخزين التخزين المشتركة باستخدام وحدة تخزين USB الكبيرة أو بروتوكول نقل الوسائط.
يجب أن توفّر واجهة برمجة التطبيقات لـ Android Open Accessory (AOA) والمواصفات كما هو موثّق في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android، وإذا كان جهازًا محمولاً في نظام التشغيل Android، يجب أن يستخدم واجهة برمجة التطبيقات AOA. عمليات تنفيذ الأجهزة التي تنفِّذ مواصفات AOA:
- يجب أن تعلن عن توافقها مع ميزة الأجهزة android.hardware.usb.accessory.
- يجب تنفيذ فئة صوت USB كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
- يجب أن تتضمن فئة تخزين USB الكبيرة السلسلة "android" في نهاية وصف الواجهة سلسلة iInterface من وحدة تخزين USB الكبيرة
من المفترض أن يتم توفير إمكانية رسم تيار بقوة 1.5 أمبير أثناء اهتزاز HS وحركة البيانات على النحو المحدّد في مواصفات شحن بطارية USB، النسخة 1.2. يُنصَح بشدة باستيفاء هذه المتطلبات على أجهزة Android الحالية والجديدة حتى تتمكّن هذه الأجهزة من الترقية إلى إصدارات النظام الأساسي المستقبلية.
يجب أن ترصد الأجهزة من النوع C شاحن بقوة 1.5 أمبير و3.0 أمبير وفقًا لمعيار المقاومة من نوع C، كما يجب أن ترصد التغييرات في الإعلانات.
يُنصَح بشدة بأن تكون الأجهزة من النوع C التي تتيح وضع مضيف USB موصى بها لتوفير ميزة "الشحن الفائق" لإتاحة البيانات وتبديل أدوار الطاقة.
يجب أن تتوافق الأجهزة من النوع C مع ميزة "الشحن بالطاقة" لشحن الجهد العالي ودعم الأوضاع البديلة مثل العرض الخارجي.
يجب أن تكون قيمة iSerialNumber في واصف جهاز USB العادي مساوية لقيمة android.os.Build.SERIAL.
يُنصَح بشدة بعدم توافق الأجهزة من النوع C مع طرق الشحن الخاصة بها والتي تعدّل الجهد الكهربائي لـ Vbus بدرجة خارج المستويات التلقائية، أو تغيّر أدوار الحوض/المصدر، ما قد يؤدي إلى حدوث مشاكل في إمكانية التشغيل التفاعلي مع الشواحن أو الأجهزة التي تتوافق مع الطُرق العادية لشحن الطاقة عبر USB. على الرغم من أن ذلك يسمى بـ "موصى به بشدة"، إلا أننا قد نطلب في إصدارات Android المستقبلية من جميع الأجهزة من النوع C أن تتيح إمكانية التشغيل التفاعلي الكامل مع أجهزة الشحن القياسية من النوع C.

7.7.2 وضع مضيف USB

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

يجب استخدام منفذ USB من النوع C، إذا كان تنفيذ الجهاز يتوافق مع USB 3.1.
قد تستخدم شكل منفذ غير عادي، ولكن يجب شحنه مع كابل أو كابلات تضبط المنفذ مع منفذ USB عادي من النوع A أو من النوع C.
قد تستخدم منفذ USB مصغر AB، ولكن يجب شحنه مع كابل أو كابلات تضبط المنفذ مع منفذ USB عادي من النوع A أو من النوع C.
يُنصح بشدة بتنفيذ فئة USB Audio كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
يجب تنفيذ واجهة برمجة تطبيقات مضيف USB لنظام التشغيل Android كما هو موثّق في حزمة تطوير البرامج (SDK) لنظام التشغيل Android، كما يجب الإعلان عن توافقه مع ميزة الأجهزة android.hardware.usb.host.
"يجب أن يتم توفير شحن الجهاز" أثناء استخدام وضع المضيف. يُعلِن عن مصدر تيار لا يقل عن 1.5 أمبير كما هو محدّد في قسم "مَعلَمات الإنهاء" في [الإصدار 1.2 من كبل USB من نوع C ومواصفات الموصّل 1.2] (http://www.usb.org/developers/docs/usb_31_021517.zip) لموصّلات USB من نوع C أو باستخدام الإصدار الحالي لموصّل منفذ USB من النوع C، أو باستخدام الإصدار الحالي لمنفذ شحن موصّل USB من نوع C والإصدار 1 من موصّل شحن البطارية حسب المواصفات المحددة في المواصفات.
يُنصَح بشدة بأن تكون الأجهزة المزوَّدة بمنفذ USB من النوع C متوافقة مع DisplayPort، ويجب أن تتوافق مع معدلات البيانات الفائقة السرعة على USB، ويُنصَح بشدة بأن تكون متوافقة مع ميزة "الشحن الفائق" لإتاحة البيانات وتبديل أدوار الطاقة.
يجب عدم شحن الأجهزة ذات المنافذ من النوع A أو من النوع AB مع محوّل يحوّل من هذا المنفذ إلى وعاء من النوع C.
يجب التعرّف على أي أجهزة بروتوكول نقل الوسائط (MTP) المتصلة عن بُعد والسماح بالوصول إلى محتواها من خلال الأهداف ACTION_GET_CONTENT وACTION_OPEN_DOCUMENT وACTION_CREATE_DOCUMENT، إذا كان إطار عمل الوصول إلى مساحة التخزين (SAF) متوافقًا.
في حال استخدام منفذ USB من النوع C وإتاحة وضع الجهاز الملحق، يجب تنفيذ وظيفة "منفذ الدور المزدوج" على النحو المحدَّد في مواصفات USB من النوع C (الفقرة 4.5.1.3.3).
"ينبغي"، إذا كانت وظيفة المنفذ المزدوج متاحة متاحة، يجب تنفيذ نموذج Try.* الأكثر ملاءمةً لشكل الجهاز. على سبيل المثال، "ينبغي" أن يستخدم جهاز محمول باليد طراز Try.SNK.

7.8. الصوت

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

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

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

يجب الإبلاغ عن قيمة ثابتة لميزة android.hardware.microphone.
يجب أن يستوفي متطلبات التسجيل الصوتي الواردة في القسم 5.4.
يجب أن يستوفي متطلبات وقت استجابة الصوت الواردة في القسم 5.6.
يُنصح بشدة لإتاحة التسجيل بالموجات فوق الصوتية كما هو موضّح في القسم 7.8.3.

7.8.2 إخراج الصوت

قد تشتمل أجهزة Android Watch على إخراج صوتي.

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

يجب الإبلاغ عن قيمة ثابتة لميزة android.hardware.audio.output.
يجب أن يستوفي متطلبات تشغيل الصوت الواردة في القسم 5.5.
يجب أن يستوفي متطلبات وقت استجابة الصوت الواردة في القسم 5.6.
يُنصح بشدة لإتاحة التشغيل بالموجات فوق الصوتية تقريبًا كما هو موضَّح في الفقرة 7.8.3.

وفي المقابل، إذا كان تنفيذ الجهاز لا يشتمل على منفذ لإخراج الصوت أو مكبّر صوت، يجب ألا يبلِّغ عن ميزة إخراج الصوت android.hardware.audio، ويجب أن يستخدم واجهات برمجة التطبيقات ذات الصلة بـ "إخراج الصوت" في حال عدم توفُّرها على الأقل.

من الممكن أن يتم تشغيل جهاز Android Watch على جهاز Android Watch، لكن من المفترض ألا يحتوي على إخراج صوتي، ولكن يجب أن يتوفر إخراج صوتي في الأنواع الأخرى من تطبيقات Android Watch مع تعريف android.hardware.audio.output.

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

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

يجب تشغيل الصوت على سماعات رأس استيريو وسماعات رأس استيريو مع ميكروفون، كما يجب أن يدعم تسجيل الصوت من سماعات رأس استيريو مع ميكروفون.
يجب أن يتوافق مع مقابس صوت TRRS مع طلب تثبيت CTIA، وأن تتوافق مع مقابس الصوت مع ترتيب تثبيت OMTP.
يجب أن يتيح رصد الميكروفون في ملحق الصوت المتّصل، إذا كان الجهاز يتيح استخدام ميكروفون، وبث android.intent.action.HEADSET_PLUG مع ضبط الميكروفون الذي يتضمّن القيمة الإضافية على القيمة 1.
يجب أن يتيح رصد الرموز الرئيسية وربطها برموز المفاتيح للنطاقات الثلاثة التالية من المعاوقة المكافئة بين الميكروفون والموصّلات الأرضية في مقبس الصوت:
- 70 أوم أو أقل : KEYCODE_HEADSETHOOK
- 210-290 أوم : KEYCODE_VOLUME_UP
- 360-680 أوم : KEYCODE_VOLUME_DOWN
يُنصح بشدة برصد رمز المفتاح وربطه بالنطاق التالي للمعاوقة المكافئة بين الميكروفون والموصّلات الأرضية في مقبس الصوت:
- 110-180 أوم: KEYCODE_VOICE_ASSIST
يجب تشغيل ACTION_HEADSET_PLUG عند إدخال قابس، ولكن فقط بعد أن تلمس جميع جهات الاتصال على المقبس الأجزاء ذات الصلة بالمقبس.
يجب أن تكون قادرة على دفع ما لا يقل عن 150 ملي فولت أو 10% من الجهد الكهربي للإخراج من خلال مقاومة مكبّر الصوت التي تبلغ شدتها 32 أوم.
يجب أن يحتوي على جهد كهربائي لانحياز الميكروفون يتراوح بين 1.8 فولت و2.9 فولت.

7.8.3. الموجات فوق الصوتية القريبة

الصوت القريب من الموجات فوق الصوتية هو نطاق يتراوح بين 18.5 كيلوهرتز و20 كيلوهرتز. يجب أن تُبلِغ عمليات تنفيذ الأجهزة عن توافق الإمكانية الصوتية للموجات فوق الصوتية القريبة عبر واجهة برمجة التطبيقات AudioManager.getProperty على النحو التالي:

إذا كانت قيمة Property_SUPPORT_MIC_NEAR_ULTRACONTENT هي "صحيح"، يجب استيفاء المتطلبات التالية في مصدرَي الصوت VOICE_RECOGNITION وUNPROCESSED.
- يجب ألا يزيد متوسط استجابة الميكروفون في النطاق بين 18.5 كيلوهرتز إلى 20 كيلوهرتز عن 15 ديسيبل أسفل الاستجابة عند 2 كيلوهرتز.
- يجب ألا تقل نسبة الضوضاء غير المرجحة في الميكروفون التي تزيد عن 18.5 كيلوهرتز إلى 20 كيلوهرتز بالنسبة إلى نغمة 19 كيلوهرتز عند -26 ديسيبل عن 50 ديسيبل.
إذا كانت قيمة السمة Property_SUPPORT_SPEAKER_NEAR_ULTRACONTENT هي "صحيح"، يجب ألا تقل سرعة استجابة مكبّر الصوت عن 18.5 كيلوهرتز إلى 20 كيلوهرتز عن 40 ديسيبل أسفل الاستجابة عند 2 كيلوهرتز.

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

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

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

إنّ ابتكارات أجهزة Android المحمولة التي تتيح وضع تطبيقات الواقع الافتراضي التي تعالج العرض المجسَّم للإشعارات وتوقف مكوّنات واجهة مستخدم النظام الأحادي في حين أنّ تطبيقات الواقع الافتراضي التي تركّز على المستخدمين يجب أن تتضمّن ميزة "android.software.vr.mode". يجب أن تتضمّن الأجهزة التي تعلن عن هذه الميزة تطبيقًا ينفذ android.service.vr.VrListenerService يمكن لتطبيقات الواقع الافتراضي تفعيله من خلال android.app.Activity#setVrModeEnabled .

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

يجب أن تشير عمليات تنفيذ أجهزة Android المحمولة إلى توافق الواقع الافتراضي العالي الأداء لفترات أطول للمستخدمين من خلال علامة ميزة android.hardware.vr.high_performance وأن تستوفي المتطلبات التالية.

يجب أن تتضمن عمليات تنفيذ الأجهزة نوى مادية على الأقل.
يجب أن تشير عمليات تنفيذ الأجهزة إلى ميزة android.software.vr.mode
قد توفّر عمليات تنفيذ الأجهزة وحدة أساسية حصرية للتطبيق الذي يعمل في المقدّمة، وقد تتوافق مع واجهة برمجة التطبيقات Process.get ينطبق الحصرية الأساسية على عرض عدد نوى وحدة المعالجة المركزية التي تتوفّر حصريًا للتطبيق الذي يعمل في المقدّمة. إذا كان النظام الأساسي الحصري متوافقًا، يجب ألا يسمح الأساسي بتشغيل أي عمليات أخرى لمساحة المستخدم (باستثناء برامج تشغيل الأجهزة التي يستخدمها التطبيق)، ولكن قد يسمح بتشغيل بعض عمليات kernel حسب الضرورة.
يجب أن تدعم عمليات تنفيذ الأجهزة وضع الأداء المستمر.
يجب أن تتوافق عمليات تنفيذ الأجهزة مع OpenGL ES 3.2.
يجب أن تتوافق عمليات تنفيذ الأجهزة مع المستوى 0 من أجهزة Vulkan وأن تكون متوافقة مع المستوى 1 من أجهزة Vulkan.
يجب أن تنفّذ عمليات تنفيذ الأجهزة EGL_KHR_mutable_render_buffer وEGL_ANDROID_front_buffer_auto_refresh وEGL_ANDROID_create_native_client_buffer وEGL_KHR_fence_sync وEGL_KHR_wait_sync بحيث يمكن استخدامهما في وضع المخزن المؤقت المشترك وعرض الإضافات في قائمة إضافات EGL المتاحة.
يجب أن تتمكن وحدة معالجة الرسومات وشاشة العرض من مزامنة الوصول إلى المخزن المؤقت المشترك، لكي يتم عرض العرض بالعين المتبادل لمحتوى الواقع الافتراضي بمعدل 60 لقطة في الثانية مع سياقين للعرض بدون أي عناصر تمزيق مرئية.
يجب أن تنفذ عمليات تنفيذ الأجهزة EGL_IMG_context_priority، وتعرض الإضافة في قائمة إضافات EGL المتاحة.
يجب أن تنفِّذ عمليات تنفيذ الأجهزة GL_EXT_multi sampled_render_to_texture وGL_OVR_multiview وGL_OVR_multiview2 وGL_OVR_multiview_multi sampled_render_to_texture، وتعرض الإضافات في قائمة إضافات GL المتاحة.
يجب أن تنفذ عمليات تنفيذ الأجهزة EGL_EXT_Protect_content وGL_EXT_Protect_textures كي يتم استخدامها لتشغيل فيديو الهيئة الآمنة وإظهار الإضافات في قائمة إضافات EGL وGL المتاحة.
يجب أن تتيح عمليات تنفيذ الأجهزة فك ترميز H.264 بمعدّل لا يقل عن 3840x2160 بسرعة 30fps-40 ميغابت في الثانية (ما يعادل 4 نُسخ من 1920x1080@30fps-10 ميغابت في الثانية أو مثيلَين من 1920x1080@60fps-20 ميغابت في الثانية).
يجب أن تتوافق عمليات تنفيذ الأجهزة مع HEVC وVP9، ويجب أن تكون قادرة على فك ترميز ما لا يقل عن 1920x1080@30fps-10 ميغابت في الثانية، ويجب أن تكون قادرة على فك ترميز 3840x2160@30fps-20 ميغابت في الثانية (ما يعادل 4 مثيلات بتنسيق 1920x1080@3).
ننصح بشدة بأن تكون عمليات تنفيذ الأجهزة متوافقة مع ميزة android.hardware.sensor.hifi_sensors، ويجب أن تستوفي المتطلبات المتعلّقة بالجيروسكوب ومقياس التسارع ومقياس المغناطيسية لاستخدام android.hardware.hifi_sensors.
يجب أن تتوافق عمليات تنفيذ الأجهزة مع واجهة برمجة التطبيقات AppliancePropertiesManager.getDeviceLevels API وتعرض قيمًا دقيقة لدرجة حرارة الجلد.
يجب أن يتضمّن الجهاز شاشة مضمّنة، ويجب ألا تقل دقته عن دقة فائقة(1080p) وأن تكون بدقة QuadHD (1440p) أو أعلى.
يجب أن يتراوح قياس الشاشة بين 4.7 بوصة. و6 بوصة قُطريًا.
يجب أن يتم تحديث الشاشة بمعدّل 60 هرتز على الأقل أثناء استخدام وضع الواقع الافتراضي (VR).
يجب أن يكون وقت استجابة العرض عند التبديل بين "الرمادي إلى الرمادي" و"الأبيض إلى الأسود" و"الأبيض إلى أبيض" ≤ 3 ملي ثانية.
يجب أن تتوافق الشاشة مع وضع التردّد المنخفض الذي لا يقل عن 5 ملي ثانية، ويتم تعريف المثابرة على أنّها مقدار الوقت الذي ينبعث منه بكسل الضوء.
يجب أن تكون عمليات تنفيذ الأجهزة متوافقة مع الإصدار 4.2 من البلوتوث والإضافة الخاصة بمدة بيانات Bluetooth LE Data الفقرة 7.4.3.

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

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

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

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

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

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

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

الكتابة التسلسلية . يجب أن تضمن عمليات تنفيذ الأجهزة تحقيق أداء كتابة تسلسلي لا يقل عن 5 ميغابايت/ثانية لملف بحجم 256 ميغابايت يستخدم مخزنًا مؤقتًا بحجم 10 ميغابايت.
الكتابة العشوائية . يجب أن تضمن عمليات تنفيذ الأجهزة تحقيق أداء كتابة عشوائي لا يقل عن 0.5 ميغابايت في الثانية لملف بحجم 256 ميغابايت باستخدام مخزن مؤقت للكتابة بحجم 4 كيلوبايت.
القراءة التسلسلية . يجب أن تضمن عمليات تنفيذ الأجهزة أداء قراءة تسلسلي لا يقل عن 15 ميغابايت/ثانية لملف بحجم 256 ميغابايت يستخدم مخزنًا مؤقتًا بحجم 10 ميغابايت.
القراءة العشوائية . يجب أن تضمن عمليات تنفيذ الأجهزة تحقيق أداء قراءة عشوائي لا يقل عن 3.5 ميغابايت/ثانية لملف بحجم 256 ميغابايت باستخدام مخزن مؤقت للكتابة بحجم 4 كيلوبايت.

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

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

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

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

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

يجب أن يكون قادرًا على تتبع استخدام الطاقة لمكونات الجهاز وسمات استخدام الطاقة لتطبيقات معينة. على وجه التحديد، عمليات التنفيذ:
- يجب توفير ملف شخصي للطاقة لكل مكون يحدد قيمة الاستهلاك الحالية لكل مكون من مكونات الجهاز واستنزاف البطارية التقريبي الناتج عن المكونات بمرور الوقت كما هو موثق في موقع المشروع المفتوح المصدر لنظام Android.
- يجب أن يتم الإبلاغ عن جميع قيم استهلاك الطاقة بالمللي أمبير في الساعة (mAh).
- يجب أن يُنسب إلى مكون الجهاز نفسه إذا لم يتمكن من عزو استخدام طاقة مكون الجهاز إلى أحد التطبيقات.
- يجب الإبلاغ عن استهلاك طاقة وحدة المعالجة المركزية (CPU) حسب المُعرّف الفريد لكل عملية. يلبي "المشروع المفتوح المصدر لنظام Android" المتطلّبات من خلال تنفيذ وحدة نواة uid_cputime.
يجب إتاحة استخدام الطاقة هذا من خلال أمر adb shell dumpsys batterystats Shell لمطوِّر التطبيق.
يجب أن يلتزم بالهدف android.intent.action.POWER_USAGE_SUMMARY وأن يعرض قائمة إعدادات توضح استخدام الطاقة هذا.

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

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

يجب أن تتوافق عمليات تنفيذ الأجهزة مع "وضع الأداء المستدام" الذي يمكن أن يوفّر مستوى أداء ثابتًا للتطبيق الذي تعمل في المقدّمة لفترة طويلة من الوقت عندما يتم طلبه باستخدام طريقة واجهة برمجة التطبيقات Window.setSustainedPerformanceMode(). يجب أن تُبلِغ عملية تنفيذ الجهاز عن توافق "وضع الأداء المستدام" بدقة من خلال طريقة واجهة برمجة التطبيقات PowerManager.isSustainedPerformanceModeSupported().

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

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

إذا كان تنفيذ الجهاز لا يتيح استخدام بنية أساسية حصرية، يجب أن يعرض قائمة فارغة باستخدام طريقة واجهة برمجة التطبيقات Process.getExclusiveCores().

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

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

9.1. الأذونات

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

يجب عدم منح الأذونات التي تتضمن protectionLevel إذن 'PROTECTION_FLAG_PRIVILEGED' إلا للتطبيقات التي تم تحميلها مسبقًا في المسارات المميزة ضمن القائمة المسموح بها لصورة النظام، مثل مسار system/priv-app في تنفيذ بروتوكول AOSP.

أما الأذونات التي لها مستوى حماية من الخطورة، فهي أذونات التشغيل. التطبيقات التي تتضمّن targetSdkVersion > 22 طلبًا في وقت التشغيل. عمليات تنفيذ الأجهزة:

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

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

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

9.3. أذونات نظام الملفات

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

9.4. بيئات التنفيذ البديلة

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

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

يجب عدم منح بيئات التشغيل البديلة إمكانية الوصول إلى الموارد المحمية بموجب أذونات لم يتم طلبها في ملف AndroidManifest.xml الخاص ببيئة التشغيل من خلال الإذن <uses-permission> الآلية.

يجب ألا تسمح بيئات التشغيل البديلة للتطبيقات باستخدام الميزات المحمية بواسطة أذونات Android المقصورة على تطبيقات النظام.

يجب أن تلتزم بيئات التشغيل البديلة بنموذج وضع الحماية لنظام التشغيل Android. على وجه التحديد، بيئات التشغيل البديلة:

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

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

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

9.5. دعم عدة مستخدمين

وهذه الميزة اختيارية لجميع أنواع الأجهزة.

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

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

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

يتيح Android تحذير المستخدمين من أي رسالة SMS مميّزة صادرة. الرسائل القصيرة برسوم إضافية هي رسائل نصية يتم إرسالها إلى خدمة مسجّلة لدى مشغّل شبكة الجوّال وقد تفرض رسومًا على المستخدم. يجب أن تحذّر عمليات تنفيذ الأجهزة التي تعلن عن إتاحة android.hardware.telephony المستخدمين قبل إرسال رسالة SMS إلى الأرقام التي تم تحديدها بواسطة التعبيرات العادية المحدّدة في ملف /data/misc/sms/codes.xml على الجهاز. يوفّر "المشروع المفتوح المصدر لنظام Android" عملية تنفيذ تستوفي هذا الشرط.

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

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

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

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

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

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

يجب ضبط SELinux على وضع الفرض العام.
يجب إعداد كل النطاقات في وضع الفرض. ولا يُسمح بالنطاقات الخاصة بوضع التساهل، بما في ذلك النطاقات الخاصة بجهاز أو مورِّد.
يجب ألا تُجري تعديلاً أو حذف أو استبدال قواعدNeverallow المتوفرة في مجلد System/sepolicy المقدَّم في "المشروع المفتوح المصدر لنظام Android" (AOSP) والتأكُّد من تجميع السياسة مع أي قواعد لا تسمح مطلقًا في كل من نطاقات SELinux على AOSP والنطاقات الخاصة بالأجهزة/المورِّدين.
يجب تقسيم إطار عمل الوسائط إلى عمليات متعددة حتى يكون من الممكن منح إذن الوصول بشكل أكثر تحديدًا لكل عملية على النحو الموضّح في موقع "مشروع مفتوح المصدر لنظام Android".

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

يجب أن تنفّذ الأجهزة آلية وضع الحماية لتطبيق النواة تسمح بفلترة طلبات النظام باستخدام سياسة قابلة للضبط من البرامج المتعدّدة السلاسل. يلبي "المشروع المفتوح المصدر لنظام Android" هذا الشرط من خلال تفعيل seccomp-BPF بمزامنة سلسلة المحادثات (TSYNC) كما هو موضَّح في قسم "ضبط النواة" على source.android.com.

9.8. الخصوصية

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

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

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

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

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

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

اختياري لعمليات تنفيذ أجهزة Android بدون شاشة قفل آمنة.

إذا كان تنفيذ الجهاز يتوافق مع شاشة قفل آمنة كما هو موضح في الفقرة 9.11.1، يجب أن يتيح الجهاز تشفير مساحة تخزين البيانات الخاصة بالتطبيق (قسم/قسم البيانات)، بالإضافة إلى قسم مساحة التخزين المشتركة للتطبيق (قسم/sdcard) إذا كان جزءًا دائمًا غير قابل للإزالة من الجهاز.

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

يجب أن تستوفي عمليات تنفيذ الأجهزة متطلبات تشفير تخزين البيانات المذكورة أعلاه من خلال تنفيذ التشفير المستند إلى الملف (FBE).

9.9.1. التشغيل المباشر

يجب أن تنفّذ جميع الأجهزة واجهات برمجة تطبيقات وضع التشغيل المباشر حتى إذا لم تكن تدعم تشفير مساحة التخزين. وعلى وجه الخصوص، يجب أن يستمر بث هدفَي Intent LOCKED_BOOT_COMPLETED وACTION_USER_UNLOCKED للإشارة إلى التطبيقات المستندة إلى التمهيد المباشر بأنّ مواقع التخزين باستخدام تشفير الجهاز (DE) وتشفير بيانات الاعتماد (CE) متاحتان للمستخدم.

9.9.2. التشفير المستنِد إلى الملفات

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

يجب بدء التشغيل بدون تحدي المستخدم في ما يتعلق ببيانات الاعتماد والسماح للتطبيقات التي تستنِد إلى ميزة "التشغيل المباشر" بالوصول إلى مساحة تخزين الجهاز المشفَّرة (DE) بعد بث الرسالة LOCKED_BOOT_COMPLETED.
يجب السماح بالوصول إلى وحدة تخزين بيانات الاعتماد المشفَّرة (CE) فقط بعد أن يلغي المستخدم قفل الجهاز من خلال تقديم بيانات الاعتماد (مثل رمز المرور أو رقم التعريف الشخصي أو النقش أو بصمة الإصبع) وبث رسالة ACTION_USER_UNLOCKED. يجب ألا توفر عمليات تنفيذ الأجهزة أي طريقة لإلغاء قفل وحدة التخزين المحمية بموجب بروتوكول CE بدون بيانات الاعتماد المقدّمة من المستخدم.
يجب أن يتوافق مع "التشغيل المتحقّق منه" والتأكّد من أنّ مفاتيح DE ترتبط بالتشفير بجذر ثقة جهاز الجهاز.
يجب أن يتيح تشفير محتوى الملف باستخدام معيار التشفير المتقدّم (AES) الذي يبلغ طول مفتاحه 256 بت في وضع XTS.
يجب أن يتيح تشفير اسم الملف باستخدام AES مع مفتاح بطول 256 بت في وضع CBC-CTS.
قد يتيح استخدام رموز بديلة وأطوال المفاتيح وأوضاعها لمحتوى الملف وتشفير اسم الملف، ولكن يجب أن يستخدم تلقائيًا أنواع التشفير وأطوال المفاتيح والأوضاع المتوافقة بشكل إلزامي.
"يجب" أن تكون التطبيقات الأساسية المُحمَّلة مسبقًا (مثل المنبّه والهاتف والمراسلة) متوافقة مع ميزة "التشغيل المباشر".

المفاتيح التي تحمي منطقتَي التخزين CE وDE:

يجب أن يكون مرتبطًا بتشفير "ملف تخزين مفاتيح" مستند إلى الأجهزة. يجب ربط مفاتيح التشفير التام ببيانات اعتماد شاشة القفل لدى المستخدم. إذا لم يحدد المستخدم أي بيانات اعتماد لشاشة القفل، يجب ربط مفاتيح CE برمز مرور تلقائي.
يجب أن يكون المفتاح فريدًا ومتميزًا، أي أنّه لا يمكن أن يتطابق مفتاح CE أو DE لأي مستخدم مع أي من مفاتيح CE أو DE لأي مستخدم آخر.

يوفّر مشروع برنامج مفتوح المصدر لنظام Android التنفيذ المفضّل لهذه الميزة استنادًا إلى ميزة تشفير Linux kernel ext4.

9.9.3. تشفير القرص الكامل

عمليات تنفيذ الأجهزة التي تتيح تشفير الأقراص الكاملة (FDE) يجب استخدام معيار AES مع مفتاح يبلغ 128 بت (أو أكثر) ووضع مصمَّم للتخزين (مثل AES-XTS أو AES-CBC-ESSIV). يجب عدم كتابة مفتاح التشفير في وحدة التخزين في أي وقت بدون تشفيره. ما لم يكن مفتاح التشفير قيد الاستخدام النشط، يجب أن يكون مشفَّرًا بتقنية AES مع بيانات اعتماد شاشة القفل تم تمديدها باستخدام خوارزمية تمديد بطيء (مثل PBKDF2 أو scrypt). إذا لم يحدد المستخدم بيانات اعتماد شاشة القفل أو أوقف استخدام رمز المرور للتشفير، على النظام استخدام رمز مرور تلقائي لربط مفتاح التشفير. إذا كان الجهاز يوفر ملف تخزين مفاتيح مستنِد إلى الجهاز، يجب أن تكون خوارزمية تمديد كلمة المرور مرتبطة بملف تخزين المفاتيح هذا من خلال التشفير. يجب عدم إرسال مفتاح التشفير خارج الجهاز (حتى عند إحاطته برمز مرور المستخدم و/أو مفتاح مرتبط بالجهاز). يوفر مشروع برنامج مفتوح المصدر لنظام Android التنفيذ المفضل لهذه الميزة استنادًا إلى ميزة نواة Linux باستخدام التشفير dm-crypt.

9.10. سلامة الجهاز

تضمن المتطلبات التالية شفافية حالة سلامة الجهاز.

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

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

يُرجى تعريف علامة ميزة النظام الأساسي android.software.verify_boot.
أجرِ عملية التحقق في كل تسلسل تمهيد.
يمكنك بدء عملية إثبات الملكية من خلال مفتاح جهاز غير قابل للتغيير يمثّل جذر الثقة وصولاً إلى قسم النظام.
نفِّذ كل مرحلة من مراحل التحقّق للتأكّد من صحة ومصداقية جميع وحدات البايت في المرحلة التالية قبل تنفيذ الرمز البرمجي في المرحلة التالية.
استخدِم خوارزميات التحقّق بشكل قوي مثل الاقتراحات الحالية الصادرة عن المعهد الوطني للمعايير والتكنولوجيا (NIST) بشأن خوارزميات التجزئة (SHA-256) وأحجام المفاتيح العامة (RSA-2048).
يجب عدم السماح بإكمال التمهيد عند تعذُّر التحقق من النظام، ما لم يوافق المستخدم على محاولة التشغيل على أي حال، وفي هذه الحالة يجب عدم استخدام البيانات من أي مجموعات تخزين لم يتم التحقق منها.
يجب ألا يسمح بتعديل الأقسام التي تم التحقّق منها على الجهاز ما لم يفتح المستخدم قفل برنامج الإقلاع بشكل صريح.

يوفر المشروع المفتوح المصدر لنظام Android التنفيذ الأمثل لهذه الميزة استنادًا إلى ميزة نواة Linux مع dm-verity.

بدءًا من نظام التشغيل Android 6.0، يجب أن تتيح عمليات تنفيذ الأجهزة التي يكون أداء التشفير فيها بمعيار التشفير المتقدّم (AES) والتي تزيد عن 50 مبيبايت في الثانية مع التشغيل المُتحقَّق منه لسلامة الجهاز.

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

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

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

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

"ينبغي ألا تحد من عدد المفاتيح التي يمكن إنشاؤها، ويجب أن تسمح على الأقل باستيراد أكثر من 8,192 مفتاحًا.
يجب أن تحد المصادقة على شاشة القفل من عدد المحاولات ويجب أن تتضمن خوارزمية تراجع هائلة. ولتجاوز 150 محاولة فاشلة، يجب أن يكون التأخير 24 ساعة على الأقل لكل محاولة.
عندما يتيح تنفيذ الجهاز استخدام شاشة قفل آمنة، يجب أن يتم إنشاء نسخة احتياطية من عملية تنفيذ ملف تخزين المفاتيح باستخدام أجهزة آمنة وأن تستوفي المتطلبات التالية:
- يجب أن تتوفر لديهم تطبيقات متوافقة مع الأجهزة لخوارزميات التشفير RSA وAES وECDSA وHMAC، بالإضافة إلى وظائف التجزئة MD5 وSHA1 وSHA-2 Family للتوافق بشكل صحيح مع خوارزميات نظام تخزين مفاتيح Android المتوافقة.
- يجب إجراء مصادقة شاشة القفل في الأجهزة الآمنة وفقط في حال السماح باستخدام المفاتيح المرتبطة بالمصادقة. يوفّر "المشروع المفتوح المصدر لنظام Android" طبقة تجريد أجهزة بوابة حماية (HAL) التي يمكن استخدامها لاستيفاء هذا الشرط.

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

9.11.1. شاشة القفل الآمنة

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

يجب عدم التعامل مع طريقة المصادقة كشاشة قفل آمنة إذا كانت تستند إلى سر معروف، ما لم تستوفِ جميع المتطلبات التالية:
- يجب أن يكون قصور أقصر طول مسموح به للمدخلات أكبر من 10 بت.
- يجب أن يكون الحد الأقصى لقصور جميع الإدخالات المحتملة أكبر من 18 بت.
- يجب ألا يحلّ محلّ أي طريقة من طرق المصادقة الحالية (رقم التعريف الشخصي أو النقش أو كلمة المرور) التي تم تنفيذها وتقديمها في بروتوكول AOSP.
- يجب إيقاف هذه الميزة عندما يضبط تطبيق "وحدة التحكّم بسياسة الجهاز" (DPC) سياسة جودة كلمة المرور عبر الطريقة DevicePolicyManager.setPasswordQuality() باستخدام ثابت جودة أكثر تقييدًا من PASSWORD_QUALITY_SOMETHING .
يجب عدم التعامل مع طريقة المصادقة باعتبارها شاشة قفل آمنة ما لم تستوفِ جميع المتطلبات التالية:
- يجب أن تتوفّر في هذا الجهاز آلية احتياطية لاستخدام إحدى طرق المصادقة الأساسية التي تستند إلى مفتاح سرّي معروف وتفي بالمتطلبات اللازمة ليتم التعامل معها على أنّها شاشة قفل آمنة.
- يجب إيقاف هذا الإعداد وعدم السماح للمصادقة الأساسية بفتح قفل الشاشة إلا عندما يحدِّد تطبيق وحدة التحكّم بسياسة الجهاز (DPC) السياسة باستخدام الطريقة DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) أو الطريقة DevicePolicyManager.setPasswordQuality() مع ضبط جودة ثابتة أكثر من PASSWORD_QUALITY_UNSPECIFIED .
يجب عدم التعامل مع طريقة المصادقة كشاشة قفل آمنة، إذا كانت تستند إلى المقاييس الحيوية، ما لم تستوفِ جميع المتطلبات التالية:
- يجب أن تتوفّر في هذا الجهاز آلية احتياطية لاستخدام إحدى طرق المصادقة الأساسية التي تستند إلى مفتاح سرّي معروف وتفي بالمتطلبات اللازمة ليتم التعامل معها على أنّها شاشة قفل آمنة.
- يجب أن يكون هذا الإعداد غير مفعَّل ولا يسمح للمصادقة الأساسية بفتح قفل الشاشة إلا إذا ضبط تطبيق وحدة التحكّم بسياسة الجهاز (DPC) سياسة ميزة حماية المفاتيح من خلال استدعاء طريقة DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT).
- يجب أن تتضمّن معدّل قبول خاطئ تساوي أو أقوى من المطلوب في أداة استشعار بصمة الإصبع كما هو موضّح في الفقرة 7.3.10، أو يجب أن يكون غير مفعّل ولا يسمح للمصادقة الأساسية بفتح قفل الشاشة إلا عندما يحدِّد تطبيق وحدة التحكّم بسياسة الجهاز (DPC) سياسة جودة كلمة المرور من خلال طريقة DevicePolicyManager.setPasswordQuality() مع مستوى جودة ثابت أكثر من PASSWORD_QUALITY_BIOMETRIC_WEAK .
إذا تعذّر التعامل مع طريقة المصادقة كشاشة قفل آمنة، سيحدث ما يلي:
- يجب عرض false لكل من الطريقتين KeyguardManager.isKeyguardSecure() وKeyguardManager.isDeviceSecure().
- يجب إيقاف هذه الميزة عندما يضبط تطبيق "وحدة التحكّم بسياسة الجهاز" (DPC) سياسة جودة كلمة المرور عبر الطريقة DevicePolicyManager.setPasswordQuality() باستخدام ثابت جودة أكثر تقييدًا من PASSWORD_QUALITY_UNSPECIFIED .
- يجب عدم إعادة ضبط موقّتات انتهاء صلاحية كلمة المرور التي تم ضبطها من خلال DevicePolicyManager.setPasswordExpirationTimeout().
- يجب ألا يصادق الوصول إلى ملفات تخزين المفاتيح في حال طلب التطبيق KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true) ).
إذا كانت طريقة المصادقة مستندة إلى رمز مميّز مادي أو موقع جغرافي أو مقاييس حيوية ذات معدّل قبول خاطئ أعلى مما هو مطلوب لأجهزة استشعار بصمة الإصبع كما هو موضَّح في الفقرة 7.3.10، يجب الالتزام بما يلي:
- يجب عدم إعادة ضبط موقّتات انتهاء صلاحية كلمة المرور التي تم ضبطها من خلال DevicePolicyManager.setPasswordExpirationTimeout().
- يجب ألا يصادق على الوصول إلى ملفات تخزين المفاتيح في حال طلب التطبيق KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true).

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

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

صورة النظام
أي ملفات نظام تشغيل مطلوبة من خلال نسخة النظام

يجب حذف جميع البيانات التي ينشئها المستخدم. يجب أن يستوفي هذا معايير المجال ذات الصلة لحذف البيانات، مثل NIST SP800-88. يجب استخدام ذلك لتنفيذ واجهة برمجة التطبيقات cacheData() (جزء من واجهة برمجة التطبيقات لإدارة أجهزة Android) الموضحة في الفقرة 3.9 إدارة الأجهزة.

قد توفر الأجهزة مسحًا سريعًا للبيانات يؤدي إلى محو البيانات بشكل منطقي.

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

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

يُنصَح بشدة بإجراء عمليات تنفيذ أجهزة Android لتنفيذ "وضع التشغيل الآمن" واستيفاء المتطلبات التالية:

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

9.14. عزل أنظمة المركبات في السيارات

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

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

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

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

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

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

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

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

10.2. أداة التحقّق من CTS

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

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

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

11. برامج قابلة للتحديث

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

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

عمليات تنزيل "عبر شبكة غير سلكيّة" (OTA)" يتم تحديثها بلا اتصال بالإنترنت عن طريق إعادة التشغيل.
يتم تحديث "Tethered" عبر USB من جهاز كمبيوتر مضيف.
يتم تحديث "بلا اتصال بالإنترنت" من خلال إعادة التشغيل والتحديث من ملف على وحدة تخزين قابلة للإزالة.

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

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

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

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

يتضمن Android ميزات تسمح لتطبيق "مالك الجهاز" (إذا كان متوفرًا) بالتحكّم في تثبيت تحديثات النظام. لتسهيل ذلك، يجب أن ينفِّذ النظام الفرعي لتحديث النظام للأجهزة التي تُبلغ عن android.software.device_admin السلوك الموضّح في الفئة SystemUpdatePolicy.

12. سجل التغييرات في المستند

للحصول على ملخص بالتغييرات التي طرأت على تعريف التوافق في هذا الإصدار:

سجلّ تغييرات المستند

للحصول على ملخص للتغييرات التي تطرأ على أقسام الأفراد:

12.1. نصائح حول عرض سجلّ التغييرات

ويتم تمييز التغييرات على النحو التالي:

CDD
تغييرات جوهرية في متطلبات التوافق.
مستندات
مستحضرات التجميل أو التغييرات ذات الصلة.

للحصول على أفضل عرض، أضِف مَعلمتَي عناوين URL pretty=full وno-merges إلى عناوين URL لسجلّ التغييرات.

13. التواصل معنا

يمكنك الانضمام إلى منتدى التوافق مع Android وطلب توضيحات أو طرح أي مشاكل تعتقد أنّ المستند لا يغطيها.