‫1. مقدّمة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• يجب أن يكون الجهاز مزوّدًا بشاشة يبلغ طولها الأفقي بين 1.1 و2.5 بوصة.
• يجب الإفصاح عن الميزة android.hardware.type.watch.
• يجب أن يكون متوافقًا مع uiMode = UI_MODE_TYPE_WATCH.

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

• يجب أن يكون للجهاز شاشة يبلغ طولها القطري 15.2 سم أو أكثر.
• يجب الإفصاح عن الميزة 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 هي مجموعة من واجهات نظام Android الأساسي التي يتم عرضها للتطبيقات التي تعمل في بيئة التشغيل المُدارة. يجب أن تقدّم عمليات التنفيذ على الأجهزة عمليات تنفيذ كاملة، بما في ذلك جميع السلوكيات الموثَّقة، لأي واجهة برمجة تطبيقات موثَّقة يوفّرها حزمة تطوير برامج Android (SDK) أو أي واجهة برمجة تطبيقات تم تزيينها بالعلامة "‎@SystemApi" في رمز المصدر الأساسي لنظام Android.

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

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

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

3.1.1. إضافات Android

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

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

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

3.2.1. الأذونات

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

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

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

المَعلمة	التفاصيل
VERSION.RELEASE	إصدار نظام Android الذي يتم تنفيذه حاليًا بتنسيق يمكن للمستخدم قراءته يجب أن يحتوي هذا الحقل على إحدى قيم السلاسل المحدّدة في 7.0.
VERSION.SDK	إصدار نظام Android الذي يتم تنفيذه حاليًا بتنسيق يمكن لرمز التطبيق التابع لجهة خارجية الوصول إليه بالنسبة إلى Android 7.0، يجب أن يحتوي هذا الحقل على القيمة الصحيحة 7.0_INT.
VERSION.SDK_INT	إصدار نظام Android الذي يتم تنفيذه حاليًا بتنسيق يمكن لرمز التطبيق التابع لجهة خارجية الوصول إليه بالنسبة إلى Android 7.0، يجب أن يحتوي هذا الحقل على القيمة الصحيحة 7.0_INT.
VERSION.INCREMENTAL	قيمة يختارها مُنفِّذ الجهاز لتحديد الإصدار المحدّد لنظام Android الذي يتم تنفيذه حاليًا، بتنسيق يمكن لشخص عادي قراءته يجب عدم إعادة استخدام هذه القيمة لإصدارات مختلفة يتم توفيرها للمستخدمين النهائيين. يُستخدَم هذا الحقل عادةً للإشارة إلى رقم الإصدار أو معرّف تغيير التحكّم في المصدر الذي تم استخدامه لإنشاء الإصدار. ما مِن متطلبات خاصة بتنسيق هذا الحقل، باستثناء أنّه يجب ألّا يكون فارغًا أو سلسلة فارغة ("").
ألعاب ألواح	قيمة يختارها منفذ الجهاز لتحديد الجهاز الداخلي المحدّد الذي يستخدمه الجهاز، بتنسيق يمكن لشخص عادي قراءته من الاستخدامات المحتملة لهذا الحقل الإشارة إلى المراجعة المحدّدة للوحة التي تشغّل الجهاز. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9_-]+$".
العلامة التجارية	قيمة تعكس اسم العلامة التجارية المرتبط بالجهاز كما هو معروف للمستخدمين النهائيين يجب أن يكون بتنسيق يسهل قراءته، ويجب أن يمثّل الشركة المصنّعة للجهاز أو العلامة التجارية للشركة التي يتم تسويق الجهاز باسمها. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9_-]+$".
SUPPORTED_ABIS	اسم مجموعة التعليمات (نوع وحدة المعالجة المركزية + اصطلاح ABI) للرمز الأصلي راجِع الفقرة 3.3. التوافق مع واجهات برمجة التطبيقات الأصلية:
SUPPORTED_32_BIT_ABIS	اسم مجموعة التعليمات (نوع وحدة المعالجة المركزية + اصطلاح ABI) للرمز الأصلي راجِع الفقرة 3.3. التوافق مع واجهات برمجة التطبيقات الأصلية:
SUPPORTED_64_BIT_ABIS	اسم مجموعة التعليمات الثانية (نوع وحدة المعالجة المركزية + اصطلاح ABI) للرمز البرمجي الأصلي راجِع الفقرة 3.3. التوافق مع واجهات برمجة التطبيقات الأصلية:
CPU_ABI	اسم مجموعة التعليمات (نوع وحدة المعالجة المركزية + اصطلاح ABI) للرمز الأصلي راجِع الفقرة 3.3. التوافق مع واجهات برمجة التطبيقات الأصلية:
CPU_ABI2	اسم مجموعة التعليمات الثانية (نوع وحدة المعالجة المركزية + اصطلاح ABI) للرمز البرمجي الأصلي راجِع الفقرة 3.3. التوافق مع واجهات برمجة التطبيقات الأصلية:
الجهاز	قيمة يختارها منفذ الجهاز تحتوي على اسم التطوير أو الاسم الرمزي الذي يحدِّد إعدادات ميزات الجهاز وتصميمه الصناعي يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9_-]+$". ويجب ألّا يتغيّر اسم الجهاز هذا خلال فترة استخدام المنتج.
بصمة الإصبع	سلسلة تحدّد هذا الإصدار بشكل فريد يجب أن يكون سهل القراءة على الإنسان. يجب أن يتّبع هذا النموذج: $(BRAND)/$(PRODUCT)/     $(DEVICE):$(VERSION.RELEASE)/$(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_-]+$".
HOST	سلسلة تحدِّد بشكل فريد المضيف الذي تم إنشاء الإصدار عليه، بتنسيق يمكن لشخص عادي قراءته ما مِن متطلبات خاصة بتنسيق هذا الحقل، باستثناء أنّه يجب ألّا يكون فارغًا أو سلسلة فارغة ("").
رقم التعريف	معرّف يختاره مُنفِّذ الجهاز للإشارة إلى إصدار معيّن بتنسيق يسهل على المستخدم قراءته يمكن أن يكون هذا الحقل هو نفسه android.os.Build.VERSION.INCREMENTAL، ولكن يجب أن يكون له قيمة ذات مغزى كافٍ للمستخدمين النهائيين من أجل التمييز بين إصدارات البرامج. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9._-]+$".
الشركة المصنّعة	الاسم التجاري للمصنّع الأصلي للجهاز (OEM) ما مِن متطلبات خاصة بتنسيق هذا الحقل، باستثناء أنّه يجب ألّا يكون فارغًا أو سلسلة فارغة ("").
الطراز	قيمة يختارها منفذ الجهاز تحتوي على اسم الجهاز كما يعرفه المستخدم النهائي. يجب أن يكون هذا هو الاسم نفسه الذي يتم بموجبه تسويق الجهاز وبيعه للمستخدمين النهائيين. ما مِن متطلبات خاصة بتنسيق هذا الحقل، باستثناء أنّه يجب ألّا يكون فارغًا أو سلسلة فارغة ("").
المنتج	قيمة يختارها منفذ الجهاز تحتوي على اسم التطوير أو الاسم الرمزي للمنتج المحدّد (رمز التخزين التعريفي) الذي يجب أن يكون فريدًا ضمن العلامة التجارية نفسها. يجب أن تكون قابلة للقراءة من قِبل البشر، ولكن ليس بالضرورة أن تكون مخصّصة للعرض من قِبل المستخدمين النهائيين. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9_-]+$". ويجب ألّا يتغيّر اسم المنتج هذا خلال فترة استخدام المنتج.
SERIAL	رقم تسلسلي للأجهزة، يجب أن يكون متاحًا وفريدًا على جميع الأجهزة التي تحمل الطراز والشركة المصنّعة نفسهما يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي "^([a-zA-Z0-9]{6,20})$".
العلامات	قائمة مفصولة بفواصل بالعلامات التي اختارها مُنفِّذ الجهاز والتي تميّز الإصدار بشكل أكبر يجب أن يحتوي هذا الحقل على إحدى القيم المقابلة لإعدادات التوقيع النموذجية الثلاثة لنظام Android الأساسي: مفاتيح الإصدار، مفاتيح المطوّرين، مفاتيح الاختبار.
الوقت	قيمة تمثّل الطابع الزمني لوقت إنشاء الإصدار
النوع	قيمة يختارها مُنفِّذ الجهاز لتحديد إعدادات وقت التشغيل للإصدار يجب أن يحتوي هذا الحقل على إحدى القيم المقابلة لإعدادات وقت تشغيل Android النموذجية الثلاثة: user أو userdebug أو eng.
المستخدم	اسم أو رقم تعريف المستخدم (أو المستخدم المبرمَج) الذي أنشأ الإصدار ما مِن متطلبات خاصة بتنسيق هذا الحقل، باستثناء أنّه يجب ألّا يكون فارغًا أو سلسلة فارغة ("").
SECURITY_PATCH	قيمة تشير إلى مستوى تصحيح الأمان لإصدار معيّن يجب أن يشير ذلك إلى أنّ الإصدار ليس معرّضًا بأي شكل من الأشكال لأي من المشاكل الموضّحة في نشرة أمان Android العامة المحدّدة. يجب أن تكون بالتنسيق [YYYY-MM-DD]، وأن تتطابق مع سلسلة محدّدة موثّقة في نشرة أمان Android العامة أو في إشعار أمان Android، على سبيل المثال "‎2015-11-01".
BASE_OS	قيمة تمثّل مَعلمة FINGERPRINT للإصدار الذي يتطابق مع هذا الإصدار باستثناء الرقع المقدَّمة في نشرة الأمان العام لنظام التشغيل Android يجب أن يعرض الإصدار القيمة الصحيحة، وإذا لم يكن هذا الإصدار متوفّرًا، يجب أن يعرض سلسلة فارغة ("").

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

3.2.3.1. أغراض التطبيقات الأساسية

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

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

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

3.2.3.2. حلّ النية

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

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

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

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

• يجب محاولة التحقّق من صحة أي فلاتر أهداف من خلال تنفيذ خطوات التحقّق المحدّدة في مواصفات روابط مواد العرض الرقمية على النحو الذي نفّذه "مدير الحِزم" في مشروع Android Open Source Project.
• يجب محاولة التحقّق من فلاتر الأهداف أثناء تثبيت التطبيق وضبط جميع فلاتر أهداف UIR التي تم التحقّق منها بنجاح كمعالجات تطبيقات تلقائية لعناوين UIR الخاصة بها.
• يجوز لها ضبط فلاتر أهداف معيّنة لعناوين URL كمعالِجات تطبيق تلقائية لمعرّفات URL الخاصة بها، إذا تم التحقّق منها بنجاح ولكن تعذّر التحقّق من فلاتر عناوين URL المعنيّة الأخرى. إذا كان تنفيذ الجهاز يفعل ذلك، يجب أن يقدّم للمستخدم عمليات إلغاء أنماط لكل عنوان URL في قائمة الإعدادات.
• يجب أن يقدّم التطبيق للمستخدم عناصر تحكّم في "روابط التطبيقات" لكل تطبيق في "الإعدادات" على النحو التالي:
  • يجب أن يتمكّن المستخدم من إلغاء السلوك التلقائي لـ "روابط التطبيقات" بشكل كامل لكي يكون التطبيق: مفتوحًا دائمًا أو يطلب الإذن دائمًا أو لا يفتح أبدًا، ويجب أن ينطبق ذلك على جميع فلاتر أغراض معرّفات الموارد المنتظمة (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.Telephony.ACTION_CHANGE_DEFAULT لعرض مربّع حوار لتغيير تطبيق الرسائل القصيرة التلقائي، إذا كان تنفيذ الجهاز يُبلغ عن android.hardware.telephony.
• يجب أن يحترم التطبيق النية android.settings.NFC_PAYMENT_SETTINGS لعرض قائمة إعدادات التطبيق التلقائية لميزة "الدفع بدون تلامس"، إذا كان تنفيذ الجهاز يُبلغ عن android.hardware.nfc.hce.
• يجب أن يحترم التطبيق النية android.telecom.action.CHANGE_DEFAULT_DIALER لعرض مربّع حوار للسماح للمستخدم بتغيير تطبيق "الهاتف" التلقائي، إذا أبلغ تنفيذ الجهاز عن android.hardware.telephony .

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

إنّ توافق الرموز البرمجية الأصلية يشكّل تحديًا. لهذا السبب، ننصح بشدة جهات تنفيذ الأجهزة باستخدام عمليات تنفيذ المكتبات المدرَجة أدناه من مشروع Android Open Source Project.

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

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

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

• يجب أن تتضمّن واجهة برمجة التطبيقات إمكانية استخدام الرمز البرمجي الذي يتم تشغيله في البيئة المُدارة لاستدعاء الرمز البرمجي الأصلي، وذلك باستخدام دلالات Java Native Interface (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 NDK فقط، ويجب أن تتضمّن دعمًا لإضافة Advanced SIMD (المعروفة أيضًا باسم NEON).
• يجب إنشاؤها باستخدام رمز المصدر وملفات الرأس المتاحة في مشروع Android Open Source Project

يُرجى العِلم أنّ الإصدارات المستقبلية من Android NDK قد توفّر دعمًا لتعريفات 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 كما هو محدّد في إصدار 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.
• يجب أن ينفذ كل VkPhysicalDevices مُدرَج واجهة برمجة التطبيقات Vulkan 1.0 بالكامل.
• يجب الإبلاغ عن علامتَي ميزة PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL وPackageManager#FEATURE_VULKAN_HARDWARE_VERSION الصحيحتَين.
• يجب إدراج الطبقات، المضمّنة في المكتبات المجمّعة من رموز برمجية أصلية باسم libVkLayer*.so في دليل المكتبة المجمّعة من رموز برمجية أصلية لحزمة التطبيق، من خلال الدالتَين vkEnumerateInstanceLayerProperties وvkEnumerateDeviceLayerProperties في libvulkan.so.
• يجب عدم إدراج الطبقات التي تقدّمها المكتبات خارج حزمة التطبيق، أو توفير طرق أخرى لتتبُّع Vulkan API أو اعتراضها، ما لم يكن التطبيق يتضمّن السمة android:debuggable=”true”.

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

• يجب الإبلاغ عن 0 VkPhysicalDevices من خلال مكالمة vkEnumeratePhysicalDevices.
• يجب عدم الإفصاح عن أي من علامتَي Vulkan المميّزتين PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL وPackageManager#FEATURE_VULKAN_HARDWARE_VERSION.

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

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

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

كانت الإصدارات القديمة من حزمة Android NDK تستخدِم /proc/cpuinfo لاكتشاف ميزات وحدة المعالجة المركزية من الرمز البرمجي الأصلي بنظام ARM‏ 32 بت. للتوافق مع التطبيقات التي تم إنشاؤها باستخدام حزمة NDK هذه، يجب أن تتضمّن الأجهزة السطور التالية في ‎ /proc/cpuinfo عند قراءتها بواسطة تطبيقات ARM 32 بت:

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

لا تنطبق هذه المتطلبات إلا عندما تقرأ تطبيقات ARM ذات الـ 32 بت ملف /proc/cpuinfo. من المفترض ألا تغيّر الأجهزة ملف ‎ /proc/cpuinfo عند قراءته من خلال تطبيقات ARM أو تطبيقات غير متوافقة مع ARM بإصدار 64 بت.

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

3.4.1. توافق WebView

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

• يجب أن تستند عمليات تنفيذ android.webkit.WebView على الجهاز إلى إصدار Chromium من مشروع Android Open Source Project (مشروع 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 Open Source Project.
  • قد تحذف عمليات تنفيذ الأجهزة كلمة Mobile في سلسلة وكيل المستخدم.

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

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

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

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

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

• ذاكرة التخزين المؤقت للتطبيق/العمل بلا إنترنت
• علامة<video>
• geolocation

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.3. الإشعارات

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

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

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

يتيح Android إرسال إشعارات مختلفة، مثل:

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

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

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

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

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

3.8.4. البحث

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

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

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

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

3.8.5. النخب

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

3.8.6. المظاهر

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

يتيح نظام التشغيل Android استخدام الخط Roboto 2 بدرجات مختلفة، مثل sans-serif-thin وsans-serif-light وsans-serif-medium وsans-serif-black وsans-serif-condensed وsans-serif-condensed-light، ويجب تضمين كل هذه الخطوط للغات المتوفّرة على الجهاز وتغطية Unicode 7.0 الكاملة للغة اللاتينية واليونانية والسيريلية، بما في ذلك النطاقات A وB وC وD للغة اللاتينية الموسّعة، وجميع الأحرف الرسومية في مجموعة رموز العملات في Unicode 7.0.

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

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

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

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
• رمز تطبيق "مركز التحكّم في البيانات"

3.9.2 توافق الملف الشخصي المُدار

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

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

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

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

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

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

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

• من المفترض أن توفّر عمليات التنفيذ في Android Automotive إطار عمل تسهيل الاستخدام في Android متوافقًا مع عملية التنفيذ التلقائية في Android.
• يجب أن تقدّم عمليات التنفيذ على الأجهزة (باستثناء Android Automotive) تنفيذًا لإطار عمل تسهيل الاستخدام في Android متوافقًا مع التنفيذ التلقائي لنظام Android.
• يجب أن تتيح عمليات تنفيذ الخدمات على الأجهزة (باستثناء Android Automotive) تنفيذ خدمات تسهيل الاستخدام التابعة لجهات خارجية من خلال واجهات برمجة تطبيقات android.accessibilityservice.
• يجب أن تُنشئ عمليات تنفيذ التطبيق على الأجهزة (باستثناء Android Automotive) أحداث AccessibilityEvents وأن ترسلها إلى جميع عمليات تنفيذ 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 واجهات برمجة تطبيقات تتيح للتطبيقات الاستفادة من خدمات تحويل النص إلى كلام (TTS) وتسمح لمقدّمي الخدمات بتوفير عمليات تنفيذ لخدمات تحويل النص إلى كلام. يجب أن تستوفي عمليات تنفيذ الأجهزة التي تُبلغ عن الميزة android.hardware.audio.output هذه المتطلبات المتعلقة بإطار عمل تحويل النص إلى كلام في Android.

عمليات تنفيذ Android Automotive:

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

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

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

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

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

يجب أن تعلن عمليات تنفيذ الأجهزة المتوافقة مع TIF عن ميزة المنصة android.software.live_tv.

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

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

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

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

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

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

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

3.12.1.2. التنقّل

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

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

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

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

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

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

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

3.12.1.5. تسجيل المحتوى على التلفزيون

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

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 أو الرمز الثنائي لـ RenderScript بطريقة تمنع تثبيت هذه الملفات وتشغيلها بشكل صحيح على الأجهزة المتوافقة الأخرى.

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

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

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

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

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

• يجب أن يكون قادرًا أيضًا على فك ترميز جميع الملفات الشخصية التي تم الإبلاغ عنها في CamcorderProfile

• يجب أن يكون بإمكانه فك ترميز جميع التنسيقات التي يمكنه ترميزها. ويشمل ذلك جميع سلاسل البتات التي تُنشئها برامج الترميز.

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

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

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

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

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

التنسيق/برنامج الترميز	برنامج الترميز	برنامج فك الترميز	التفاصيل	أنواع الملفات/تنسيقات الحاويات المتوافقة
الملف الشخصي لترميز MPEG-4 AAC (AAC LC)	مطلوب 1	مطلوب	إتاحة محتوى صوتي أحادي/استيريو/5.0/5.1 2 بمعدّلات بيانات في الملف الصوتي عادية تتراوح بين 8 و48 كيلوهرتز	3GPP (‎.3gp) ‫MPEG-4 (‎.mp4 و‎.m4a) تنسيق ADTS raw AAC (‎.aac، يمكن فك ترميزه في الإصدار 3.1 من نظام التشغيل Android والإصدارات الأحدث، ويمكن ترميزه في الإصدار 4.0 من نظام التشغيل Android والإصدارات الأحدث، ولا يتوفّر تنسيق ADIF) ‫MPEG-TS (بتنسيق ‎.ts، لا يمكن تقديمه أو ترجيعه، Android 3.0 والإصدارات الأحدث)
الملف الشخصي MPEG-4 HE AAC (AAC+)	مطلوب 1 (Android 4.1 والإصدارات الأحدث)	مطلوب	إتاحة محتوى صوتي أحادي/استيريو/5.0/5.1 2 بمعدّلات بيانات في الملف الصوتي عادية تتراوح بين 16 و48 كيلوهرتز
MPEG-4 HE AACv2 ملف التعريف (الترميز المحسّن لصوت AAC)		مطلوب	إتاحة محتوى صوتي أحادي/استيريو/5.0/5.1 2 بمعدّلات بيانات في الملف الصوتي عادية تتراوح بين 16 و48 كيلوهرتز
الترميز المتقدّم للصوت بوقت استجابة منخفض (AAC ELD)	مطلوب 1 (Android 4.1 والإصدارات الأحدث)	مطلوب (Android 4.1 والإصدارات الأحدث)	إتاحة المحتوى الأحادي/الإستيريو بمعدّلات بيانات في الملف الصوتي عادية تتراوح بين 16 و48 كيلوهرتز
AMR-NB	مطلوب 3	مطلوب 3	من 4.75 إلى 12.2 كيلوبت في الثانية بمعدل أخذ عينات يبلغ 8 كيلوهرتز	3GPP (‎.3gp)
AMR-WB	مطلوب 3	مطلوب 3	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 كيلوبت في الثانية (معدل نقل بيانات ثابت) أو بمعدّل نقل بيانات متغيّر (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)
Vorbis		مطلوب		Ogg (‎.ogg) Matroska (‎.mkv, Android 4.0 والإصدارات الأحدث)
PCM/WAVE	مطلوب 4 (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 للبث الصوتي المتعدّد القنوات (أي أكثر من قناتين) إلى PCM من خلال برنامج ترميز الصوت التلقائي بتنسيق AAC في واجهة برمجة التطبيقات android.media.MediaCodec، ويجب أن يكون ما يلي متوافقًا:

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

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 تحليل البيانات الوصفية الثابتة لتنسيق HDR ومعالجتها.

• إذا كان برنامج ترميز الوسائط يعلن عن توفّر ميزة التحديث الداخلي، يجب أن يتيح فترات التحديث في النطاق من 10 إلى 60 لقطة وأن يعمل بدقة في غضون% 20 من فترة التحديث التي تم ضبطها.

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

• يجب أن تكون برامج ترميز الفيديو وفك ترميزه متوافقة مع تنسيق الألوان المرن YUV420 (COLOR_FormatYUV420Flexible).

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

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

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

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

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

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

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

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

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

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

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

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

• يجب ألا يزيد عن 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 لملف Baseline Profile من قِبل برامج الترميز.
• يجب أن تكون متوافقة مع الملفات الشخصية لترميز الفيديوهات بدقة عادية (SD) الواردة في الجدول التالي.
• يجب أن يكون متوافقًا مع المستوى 4 من الملف الشخصي الرئيسي.
• يجب أن تتيح هذه الأجهزة استخدام الملفات الشخصية لترميز الفيديوهات العالية الدقة كما هو موضّح في الجدول التالي.
• بالإضافة إلى ذلك، ننصح بشدة باستخدام أجهزة Android TV لتشفير الفيديوهات بدقة عالية 1080p بمعدّل 30 لقطة في الثانية.

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

1 عند توفّر الميزة على الجهاز، ولكن يُنصح بشدة باستخدامها على أجهزة Android Television.

5.2.3. VP8

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

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

1 عندما يكون ذلك متاحًا على الجهاز

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

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

• يجب أن تتيح إمكانية تغيير درجة دقة الفيديو الديناميكية ومعدّل عرض اللقطات من خلال واجهات برمجة التطبيقات العادية لنظام التشغيل 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 Television:
  • يجب أن يكون متوافقًا مع High Profile Level 4.2 وملف ترميز/فك ترميز HD 1080p60.
  • يجب أن يكون الجهاز قادرًا على فك ترميز الفيديوهات باستخدام ملفّي التعريف HD كما هو موضّح في الجدول التالي، وأن يكون مُشفَّرًا باستخدام ملف التعريف الأساسي أو ملف التعريف الرئيسي أو ملف التعريف العالي المستوى 4.2.

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

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

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

5.3.5. ‫H.265 (HEVC)

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

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

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

1 مطلوب لعمليات تنفيذ أجهزة Android Television التي تتضمّن فك ترميز الأجهزة باستخدام H.265.

5.3.6. VP8

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

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

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

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

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

5.3.7. ‫VP9

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

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

• بالإضافة إلى ذلك، يمكن لأجهزة Android Television تنفيذ ما يلي:

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

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

1 مطلوب لعمليات تنفيذ أجهزة Android Television التي تتضمّن فك ترميز VP9 باستخدام الأجهزة.

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

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

5.4.1. تسجيل الصوت بجودة عالية

يجب أن تسمح عمليات تنفيذ الجهاز التي تعلن عن android.hardware.microphone بتسجيل محتوى صوتي خام بالخصائص التالية:

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

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

يجب أن تسمح عمليات تنفيذ الأجهزة التي تعلن عن android.hardware.microphone بتسجيل محتوى صوتي خام بالخصائص التالية:

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

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

5.4.2. تسجيل الصوت للتعرّف عليه

يجب أن يتيح مصدر الصوت android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION تسجيل الصوت بمعدّل من بين معدّلَي البيانات في الملف الصوتي 44100 و48000.

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

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

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

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

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

• STREAM_RING
• STREAM_ALARM
• STREAM_NOTIFICATION

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

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

5.5.1. تشغيل الصوت غير المعالج

يجب أن يسمح الجهاز بتشغيل المحتوى الصوتي الأوّلي الذي يتسم بالسمات التالية:

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

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

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

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

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

• يجب أن تتيح تنفيذَي EFFECT_TYPE_EQUALIZER وEFFECT_TYPE_LOUDNESS_ENHANCER اللذَين يمكن التحكّم فيهما من خلال الفئتَين الفرعيتَين AudioEffect، وهما Equalizer وLoudnessEnhancer.
• يجب أن تتيح تنفيذ واجهة برمجة التطبيقات الخاصة بتطبيق Visualizer، والذي يمكن التحكّم فيه من خلال فئة Visualizer.
• يجب أن تتيح تنفيذات EFFECT_TYPE_BASS_BOOST وEFFECT_TYPE_ENV_REVERB وEFFECT_TYPE_PRESET_REVERB وEFFECT_TYPE_VIRTUALIZER التي يمكن التحكّم فيها من خلال الفئات الفرعية AudioEffect BassBoost وEnvironmentalReverb وPresetReverb وVirtualizer.

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

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

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

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

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

لأغراض هذا القسم، يُرجى استخدام التعريفات التالية:

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

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

• وقت استجابة الإخراج على البارد بمقدار 100 ملي ثانية أو أقل
• وقت استجابة مستمر للإخراج يبلغ 45 ملي ثانية أو أقل
• تقليل التقلّبات في إخراج الجهاز في وضع "الاستعداد"

إذا كان تطبيق الجهاز يستوفي متطلبات هذا القسم بعد أي عملية معايرة أولية عند استخدام واجهة برمجة التطبيقات OpenSL ES PCM buffer queue API، لوقت الاستجابة المستمر للإخراج ووقت الاستجابة للإخراج عند التشغيل لأول مرة على جهاز واحد على الأقل متوافق لإخراج الصوت، يُنصح بشدة بالإبلاغ عن توفُّر ميزة الصوت بوقت استجابة منخفض، وذلك من خلال الإبلاغ عن الميزة android.hardware.audio.low_latency عبر فئة android.content.pm.PackageManager. في المقابل، إذا لم يستوفِ تنفيذ الجهاز هذه المتطلبات، يجب عدم الإبلاغ عن توفّر ميزة الصوت بوقت استجابة منخفض.

يُنصح بشدة بأن تستوفي عمليات تنفيذ الأجهزة التي تتضمّن 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 لمعرفة تفاصيل عن الترميز المتقدّم للصوت (AAC) وأشكاله المختلفة.
الترميز المتقدّم للصوت مع إطارات ADTS وعلامات ID3	ISO 13818-7	راجِع الفقرة 5.1.1 لمعرفة تفاصيل عن الترميز المتقدّم للصوت وأنواعه.
WebVTT	WebVTT

• بروتوكول RTSP (بروتوكول النقل في الوقت الفعلي وبروتوكول وصف الجلسة)

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

اسم الملف الشخصي	المراجع	توافق برامج الترميز المطلوبة
‫H264 AVC	RFC 6184	راجِع القسم 5.1.3 للاطّلاع على تفاصيل عن H264 AVC.
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-generic	RFC 3640	راجِع الفقرة 5.1.1 لمعرفة تفاصيل عن الترميز المتقدّم للصوت وأنواعه.
MP2T	RFC 2250	راجِع MPEG-2 Transport Stream ضمن "البث المباشر عبر HTTP" للاطّلاع على التفاصيل.

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

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

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

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

في ما يلي وسائل نقل البيانات المتوافقة مع MIDI:

• وضع مضيف USB (القسم 7.7 USB)
• وضع جهاز USB الملحق (القسم 7.7 USB)
• استخدام بروتوكول MIDI عبر Bluetooth LE في دور مركزي (القسم 7.4.3 البلوتوث)

في المقابل، إذا كان تنفيذ الجهاز يوفر اتصالاً عامًا غير 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 ملم مزوّدًا بأربعة موصلات، يجب أن يكون وقت استجابة الصوت المستمر في كل اتجاه 20 ملي ثانية أو أقل على مسار مقبس الصوت، ويجب أن يكون 10 ملي ثانية أو أقل على مسار مقبس الصوت.
• يجب أن يتضمّن تنفيذ الجهاز منافذ USB متوافقة مع وضع مضيف USB ووضع جهاز USB الملحق.
• يجب أن ينفذ وضع مضيف USB فئة الصوت عبر USB.
• إذا كان الجهاز يتضمّن منفذ HDMI، يجب أن يتيح تنفيذ الجهاز الإخراج بصوت استيريو وثماني قنوات بعمق 20 بت أو 24 بت وبمعدل 192 كيلوهرتز بدون فقدان عمق البت أو إعادة أخذ العينات.
• يجب أن يُبلغ تطبيق الجهاز عن توافقه مع ميزة android.software.midi.
• إذا كان الجهاز يتضمّن مقبس صوت 3.5 ملم مزوّدًا بأربعة موصلات، يُنصح بشدة بتنفيذ الجهاز بما يتوافق مع قسم مواصفات الجهاز الجوّال (المقابس) في مواصفات سماعات الرأس السلكية للصوت (الإصدار 1.1).

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

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

• توفير مستوى مستدام لأداء وحدة المعالجة المركزية (CPU) عندما يكون الصوت مفعّلاً
• تقليل عدم دقة الساعة الصوتية وانحرافها عن التوقيت الرسمي
• تقليل انحراف ساعة الصوت بالنسبة إلى وحدة المعالجة المركزية CLOCK_MONOTONIC عندما يكون كلاهما نشطًا
• تقليل وقت استجابة الصوت عبر محوِّلات الطاقة على الجهاز
• تقليل وقت استجابة الصوت عبر الصوت الرقمي عبر USB
• توثيق قياسات وقت استجابة الصوت على جميع المسارات
• عليك تقليل الارتعاش في أوقات إدخال طلب الاستدعاء لإكمال التخزين المؤقت للصوت، لأنّ ذلك يؤثر في النسبة المئوية القابلة للاستخدام من معدل نقل البيانات الكامل لوحدة المعالجة المركزية (CPU) من خلال طلب الاستدعاء.
• عدم حدوث أي تأخير في عرض الصوت (الإخراج) أو تأخير في تسجيله (الإدخال) أثناء الاستخدام العادي وفقًا لوقت الاستجابة المسجَّل
• يجب أن يكون وقت الاستجابة متطابقًا بين القنوات.
• تقليل متوسط وقت استجابة 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 هرتز يتم تشغيله عند مستوى ضغط صوتي يبلغ 94 ديسيبل استجابة بمتوسط طاقة 520 لمعاينات بسعة 16 بت (أو -36 ديسيبل على النطاق الكامل لمعاينات النقطة العائمة/الدقة المزدوجة).

• ‫SNR > 60 ديسيبل (الفرق بين 94 ديسيبل SPL وSPL المكافئ للضوضاء الذاتية، مقسومًا على A)

• يجب أن يكون إجمالي التشويه التوافقي أقل من% 1 عند تردد 1 كيلوهرتز ومستوى إدخال 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 Service ‏ (ddms)
  • يجب أن تتيح عمليات تنفيذ الأجهزة جميع ميزات ddms كما هو موضّح في حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
  • بما أنّ أداة ddms تستخدم adb، من المفترض أن تكون أداة ddms غير مفعّلة تلقائيًا، ولكن يجب أن تكون مفعّلة عندما يفعّل المستخدم "جسر تصحيح أخطاء Android"، كما هو موضّح أعلاه.
• Monkey يجب أن تتضمّن عمليات تنفيذ الأجهزة إطار عمل Monkey وأن تتيح للتطبيقات استخدامه.
• SysTrace
  • يجب أن تتيح عمليات تنفيذ الأجهزة استخدام أداة systrace كما هو موضّح في حزمة تطوير البرامج (SDK) لنظام التشغيل Android. يجب أن يكون Systrace غير مفعَّل تلقائيًا، ويجب أن تتوفّر آلية يمكن للمستخدم تفعيل 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 الأساسية قائمة "خيارات المطوّرين" تلقائيًا وتتيح للمستخدمين تشغيل "خيارات المطوّرين" بعد الضغط سبع مرات على عنصر القائمة الإعدادات > لمحة عن الجهاز > رقم الإصدار. يجب أن تقدّم عمليات تنفيذ الأجهزة تجربة متّسقة لخيارات المطوّرين. على وجه التحديد، يجب أن تخفي عمليات تنفيذ الأجهزة "خيارات المطوّرين" تلقائيًا، ويجب أن توفّر آلية لتفعيل "خيارات المطوّرين" تكون متسقة مع عملية تنفيذ Android الأساسية.

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

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

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

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

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

7.1. الشاشة والرسومات

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

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

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

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

7.1.1.1. حجم الشاشة

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

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

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

• يجب أن تحتوي أجهزة Android Watch على شاشة أبعادها القطرية تتراوح بين 1.1 و2.5 بوصة.
• يجب أن تتضمّن أجهزة Android Automotive شاشة أبعادها القطرية أكبر من أو تساوي 6 بوصات.
• يجب أن تكون شاشة أجهزة Android Automotive بحجم 750 وحدة بكسل مستقلة الكثافة × 480 وحدة بكسل مستقلة الكثافة على الأقل.
• بالنسبة إلى الأنواع الأخرى من عمليات تنفيذ أجهزة Android التي تتضمّن شاشة مدمجة، يجب أن يكون حجم الشاشة على الأقل 2.5 بوصة (6.35 سم) في الاتجاه القطري.

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

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

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 نقطة لكل بوصة (دقة عالية)
• 280 نقطة لكل بوصة (280dpi)
• 320 نقطة لكل بوصة (xhdpi)
• 360 نقطة في البوصة (360dpi)
• 400 نقطة لكل بوصة (400dpi)
• 420 نقطة لكل بوصة (420dpi)
• 480 نقطة لكل بوصة (xxhdpi)
• 560 نقطة في البوصة (560dpi)
• 640 نقطة لكل بوصة (xxxhdpi)

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

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

• يجب عدم تكبير حجم الشاشة أكثر من 1.5 مرة من الكثافة الأصلية أو إنتاج الحد الأدنى من أبعاد الشاشة الفعالة التي تقل عن 320dp (أي ما يعادل مؤهّل المورد 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، كما هو موضّح بالتفصيل في مستندات Android SDK. يجب أن تكون عمليات تنفيذ الأجهزة متوافقة مع 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.
• يجب أن تُبلغ واجهات برمجة تطبيقات OpenGL الأصلية المكتوبة بلغة C أو C++ (واجهات برمجة التطبيقات المتاحة للتطبيقات من خلال 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 API.

يتضمّن نظام التشغيل 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. لوحة المفاتيح

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

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

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

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

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

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

إنّ وظائف "الصفحة الرئيسية" و"التطبيقات المستخدَمة مؤخرًا" و"الرجوع" (المرتبطة بأحداث المفاتيح KEYCODE_HOME وKEYCODE_APP_SWITCH وKEYCODE_BACK على التوالي) أساسية لنموذج التنقّل في Android، وبالتالي:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

يجب أن تستوفي الأجهزة التي تعلن عن توافقها مع android.hardware.faketouch.multitouch.distinct متطلبات faketouch المذكورة أعلاه، ويجب أن تتيح أيضًا تتبُّعًا متميزًا لمدخلات مؤشرَين مستقلَّين أو أكثر.

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

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

7.2.6.1. عمليات ربط الأزرار

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

زرّ	استخدام HID 2	زر Android
أ 1	0x09 0x0001	KEYCODE_BUTTON_A (96)
ب 1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X 1	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y 1	0x09 0x0005	KEYCODE_BUTTON_Y (100)
D-pad up (أعلى لوحة D) 1 D-pad down (أسفل لوحة D) 1	0x01 0x0039 3	AXIS_HAT_Y 4
لوحة التحكم في الاتجاهات اليمنى أو اليسرى 1 لوحة التحكم في الاتجاهات اليمنى أو اليسرى 1	0x01 0x0039 3	AXIS_HAT_X 4
زر الكتف الأيسر 1	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
زرّ أعلى ذراع التحكّم الأيمن 1	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
النقر على العصا اليسرى 1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
النقر على ذراع التحكم الأيمن 1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
المنزل 1	0x0c 0x0223	KEYCODE_HOME (3)
رجوع 1	0x0c 0x0224	KEYCODE_BACK (4)

‫1 KeyEvent

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

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

‫4 MotionEvent

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

‫1 MotionEvent

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

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

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

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

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

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

القائمة أعلاه ليست شاملة، ويجب اعتبار السلوك المُسجَّل لحزمة SDK لنظام التشغيل Android ومستندات Android Open Source حول أجهزة الاستشعار موثوقًا به.

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

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

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

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

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

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

• يجب تنفيذ TYPE_ACCELEROMETER sensor والإبلاغ عنه.
• يجب أن يكون بإمكانه تسجيل الأحداث بمعدّل تكرار لا يقل عن 50 هرتز لأجهزة Android Watch لأنّ هذه الأجهزة تفرض قيودًا أكثر صرامة على الطاقة، و100 هرتز لجميع أنواع الأجهزة الأخرى.
• يجب أن تُبلغ عن الأحداث التي تصل إلى 200 هرتز على الأقل.
• يجب أن تكون متوافقة مع نظام إحداثيات أدوات استشعار Android كما هو موضّح بالتفصيل في واجهات برمجة تطبيقات Android. يجب أن تكون عمليات تنفيذ Android Automotive متوافقة مع نظام إحداثيات أدوات استشعار السيارات في Android.
• يجب أن يكون قادرًا على القياس من السقوط الحر إلى أربع مرات من الجاذبية (4g) أو أكثر على أي محور.
• يجب أن تكون درجة دقتها 12 بت على الأقل، ويُفضَّل أن تكون 16 بت على الأقل.
• يجب معايرة هذه الأدوات أثناء استخدامها إذا تغيّرت الخصائص على مدار دورة الاستخدام، ويجب تعويضها والحفاظ على مَعلمات التعويض بين عمليات إعادة تشغيل الجهاز.
• يجب أن تكون مصحَّحة حسب درجة الحرارة.
• يجب أن يكون الانحراف المعياري لا يزيد عن 0.05 متر في الثانية^، ويجب احتساب الانحراف المعياري لكل محور استنادًا إلى العيّنات التي تم جمعها على مدار 3 ثوانٍ على الأقل بأسرع معدّل تحليل.
• يجب تنفيذ أدوات الاستشعار المركبة TYPE_SIGNIFICANT_MOTION وTYPE_TILT_DETECTOR وTYPE_STEP_DETECTOR وTYPE_STEP_COUNTER كما هو موضّح في مستند حزمة تطوير البرامج (SDK) لنظام التشغيل Android. ننصح بشدة باستخدام أجهزة Android الحالية والجديدة مع أداة الاستشعار المركبة TYPE_SIGNIFICANT_MOTION. في حال استخدام أيّ من هذه الحساسات، يجب أن يكون مجموع استهلاك الطاقة أقل من 4 ملي واط في جميع الأوقات، ويجب أن يكون استهلاك كلّ منها أقل من 2 ملي واط و0.5 ملي واط عندما يكون الجهاز في حالة ديناميكية أو ثابتة.
• في حال تضمين أداة استشعار جيروسكوب، يجب تنفيذ أداة الاستشعار المركبة TYPE_GRAVITY وأداة الاستشعار المركبة TYPE_LINEAR_ACCELERATION، ويجب تنفيذ أداة الاستشعار المركبة TYPE_GAME_ROTATION_VECTOR. ننصح بشدة باستخدام أداة استشعار TYPE_GAME_ROTATION_VECTOR على أجهزة Android الحالية والجديدة.
• يجب تنفيذ مستشعر مركب من النوع 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) ونظام واحد على الأقل من GLONASS وBeidou وGalileo).
• يجب أن يُبلغ عن الجيل من تكنولوجيا GNSS من خلال واجهة برمجة التطبيقات الاختبارية "getGnssYearOfHardware".
• يُنصح بشدة باستيفاء جميع المتطلبات أدناه، ويجب استيفاؤها إذا تم الإبلاغ عن الجيل من تكنولوجيا نظام تحديد المواقع العالمي (GNSS) على أنّه العام "2016" أو إصدار أحدث.
  • يجب أن يُبلغ التطبيق عن قياسات نظام تحديد المواقع العالمي (GPS) فور العثور عليها، حتى إذا لم يتم الإبلاغ عن موقع جغرافي تم احتسابه من نظام تحديد المواقع العالمي (GPS) أو نظام تحديد المواقع العالمي (GNSS) بعد.
  • يجب أن يُبلغ عن نطاقات GPS الزائفة ومعدّلات النطاقات الزائفة، والتي تكون كافية لاحتساب الموقع الجغرافي ضمن 20 مترًا والسرعة ضمن 0.2 متر في الثانية، في ‎95% من الوقت على الأقل، وذلك في ظروف السماء المفتوحة بعد تحديد الموقع الجغرافي، أثناء الثبات أو التحرك بسرعة تسارع أقل من 0.2 متر في الثانية المربعة.

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

7.3.4. الجيروسكوب

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

• يجب أن توفّر أداة الاستشعار TYPE_GYROSCOPE، ويجب أيضًا أن توفّر أداة الاستشعار TYPE_GYROSCOPE_UNCALIBRATED. ننصحك بشدة باستخدام أداة الاستشعار SENSOR_TYPE_GYROSCOPE_UNCALIBRATED على أجهزة Android الحالية والجديدة.
• يجب أن يكون قادرًا على قياس تغييرات الاتجاه بما يصل إلى 1,000 درجة في الثانية.
• يجب أن يكون بإمكانه تسجيل الأحداث بمعدّل تكرار لا يقل عن 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. ننصح بشدة باستخدام أداة استشعار TYPE_GAME_ROTATION_VECTOR على أجهزة Android الحالية والجديدة.

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

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

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

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

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

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

7.3.7. مقياس الإضاءة

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

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

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

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

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

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

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

• SENSOR_TYPE_ACCELEROMETER
  • يجب أن يكون نطاق القياس بين -8 غرام و+8 غرام على الأقل.
  • يجب أن يكون دقة القياس 1024 LSB/G على الأقل.
  • يجب أن يكون الحد الأدنى لعدد مرات القياس 12.5 هرتز أو أقل.
  • يجب أن يكون الحد الأقصى لعدد مرات القياس 400 هرتز أو أعلى.
  • يجب أن يكون التشويش في القياس أقل من 400 ميكرو غاوس/√هرتز.
  • يجب استخدام شكل غير مُشغِّل لهذا المستشعر مع إمكانية تخزين مؤقت لما لا يقل عن 3000 حدث مستشعر.
  • يجب أن يكون استهلاك الطاقة في وضع "المعالجة المجمّعة" لا يزيد عن 3 ملي واط.
  • يجب أن يكون هناك ثبات في خطأ التشويش الثابت الذي يقل عن 15 μg √Hz من مجموعة البيانات الثابتة التي تبلغ مدتها 24 ساعة.
  • من المفترض أن يكون هناك تغيير في الانحياز مقابل درجة الحرارة بمقدار ‎1mg / °C أو أقل أو أكثر.
  • يجب أن يكون خط أفضل الملاءمة غير خطي بنسبة ≤ 0.5%، ويجب أن يكون تغيير الحساسية حسب درجة الحرارة ≤ 0.03%/درجة مئوية.

• SENSOR_TYPE_GYROSCOPE

  • يجب أن يكون نطاق القياس بين -1000 و1000 دورة في الثانية على الأقل.
  • يجب أن تكون دقة القياس 16 LSB/dps على الأقل.
  • يجب أن يكون الحد الأدنى لعدد مرات القياس 12.5 هرتز أو أقل.
  • يجب أن يكون الحد الأقصى لعدد مرات القياس 400 هرتز أو أعلى.
  • يجب أن يكون التشويش في القياس أقل من 0.014 درجة في الثانية لكل جذر هرتز.
  • يجب أن يكون ثبات الانحياز الثابت أقل من 0.0002 درجة في الثانية √هرتز من مجموعة البيانات الثابتة التي تبلغ مدتها 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 ميكرو تسلا.
• ‫SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED مع متطلبات الجودة نفسها مثل SENSOR_TYPE_GEOMAGNETIC_FIELD بالإضافة إلى ما يلي:
  • يجب استخدام شكل غير نشط من هذا المستشعر مع إمكانية تخزين مؤقت لما لا يقل عن 600 حدث مستشعر.
• SENSOR_TYPE_PRESSURE
  • يجب أن يكون نطاق القياس بين 300 و1100 hPa على الأقل.
  • يجب أن يكون دقة القياس 80 LSB/hPa على الأقل.
  • يجب أن يكون الحد الأدنى لعدد مرات القياس 1 هرتز أو أقل.
  • يجب أن يكون الحد الأقصى لعدد مرات القياس 10 هرتز أو أعلى.
  • يجب أن يكون التشويش في القياس أقل من 2 باسكال/√هرتز.
  • يجب استخدام شكل غير مُشغِّل لهذا المستشعر مع قدرة تخزين مؤقت لا تقل عن 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
  • SENSOR_TILT_DETECTORS

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

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

• ‫SENSOR_TYPE_PROXIMITY: 100 حدث لجهاز الاستشعار

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

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

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

7.3.11. أجهزة الاستشعار المخصّصة لنظام التشغيل Android Automotive فقط

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

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

من المفترض أن تقدّم عمليات تنفيذ Android Automotive الترس الحالي على أنّه SENSOR_TYPE_GEAR.

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

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

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

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

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

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

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

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

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

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

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

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

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

• يجب استخدام بروتوكول TDLS فقط عندما يكون ذلك ممكنًا ومفيدًا.
• يجب أن يتضمّن بعض الأساليب الاستقرائية وألا يستخدم بروتوكول TDLS عندما يكون أداؤه أسوأ من الاتصال عبر نقطة وصول Wi-Fi.

7.4.3. البلوتوث

يجب أن تكون عمليات تنفيذ الأجهزة المتوافقة مع ميزة android.hardware.vr.high_performance متوافقة مع Bluetooth 4.2 وBluetooth LE Data Length Extension.

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

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

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

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

• يجب الإفصاح عن ميزة الجهاز android.hardware.bluetooth_le.
• يجب تفعيل واجهات برمجة تطبيقات Bluetooth المستندة إلى GATT (ملف الخصائص العام) كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) وandroid.bluetooth.
• ننصح بشدة بتطبيق مهلة لعنوان IP الخاص القابل للحل (RPA) لا تزيد عن 15 دقيقة وتغيير العنوان عند انتهاء المهلة لحماية خصوصية المستخدم.
• يجب أن تتيح هذه الواجهة تفريغ منطق الفلترة إلى شريحة البلوتوث عند تنفيذ ScanFilter API، ويجب أن تُبلغ عن القيمة الصحيحة لمكان تنفيذ منطق الفلترة عند الاستعلام من خلال الطريقة android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported()‎.
• يجب أن تتيح هذه الواجهة نقل المسح الضوئي المجمّع إلى مجموعة شرائح البلوتوث، ولكن في حال عدم توفّر هذه الميزة، يجب أن تُبلغ عن قيمة "false" عند الاستعلام من خلال الطريقة android.bluetooth.BluetoothAdapter.isOffloadedScanBatchingSupported()‎.
• يجب أن يكون متوافقًا مع الإعلانات المتعددة التي تتضمّن 4 خانات على الأقل، ولكن في حال عدم التوافق، يجب الإبلاغ عن "خطأ" عند الاستعلام من خلال الطريقة android.bluetooth.BluetoothAdapter.isMultipleAdvertisementSupported()‎.

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

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

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

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

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

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

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

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

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

• MIFARE Classic
• MIFARE Ultralight
• تنسيق 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()‎، ويجب تنفيذ واجهة برمجة التطبيقات NFC في Android كإجراء لا يؤدي إلى أيّ تأثير.

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

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

يجب أن تتضمّن عمليات تنفيذ الأجهزة إمكانية استخدام شكل واحد أو أكثر من أشكال شبكات البيانات. وعلى وجه التحديد، يجب أن تتضمّن عمليات تنفيذ الأجهزة معيار بيانات واحدًا على الأقل يمكنه نقل البيانات بسرعة 200 كيلوبت في الثانية أو أكثر. تشمل الأمثلة على التقنيات التي تستوفي هذا الشرط EDGE وHSPA وEV-DO و802.11g وEthernet وBluetooth 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 تستخدم مدد صلاحية RA لا تقل عن 180 ثانية.

يجب الحفاظ على إمكانية الاتصال بموجب بروتوكول IPv6 في وضع السكون.

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

يجب أن تكون إعدادات المزامنة التلقائية الرئيسية مفعَّلة تلقائيًا في عمليات تنفيذ الأجهزة حتى تُعرِض الطريقة getMasterSyncAutomatically()‎ القيمة "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 ميغابكسل على الأقل.
• يجب أن يتضمّن برنامج تشغيل الكاميرا ميزة التركيز التلقائي بالأجهزة أو البرامج (بشكل شفاف لبرنامج التطبيق).
• قد تحتوي على أجهزة ذات تركيز ثابت أو ميزة "عمق مجال ممتد".
• قد تتضمّن وميضًا. إذا كانت الكاميرا تتضمّن فلاشًا، يجب ألّا يكون مصباح الفلاش مضاءً أثناء تسجيل مثيل android.hardware.Camera.PreviewCallback على سطح معاينة الكاميرا، ما لم يفعّل التطبيق الفلاش صراحةً من خلال تفعيل السمتَين FLASH_MODE_AUTO أو FLASH_MODE_ON لعنصر Camera.Parameters. يُرجى العِلم أنّ هذا القيد لا ينطبق على تطبيق كاميرا النظام المضمّن في الجهاز، بل على التطبيقات التابعة لجهات خارجية فقط التي تستخدم Camera.PreviewCallback.

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

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

• يجب الإبلاغ عن علامة الميزة android.hardware.camera.any وandroid.hardware.camera.front.
• يجب أن تكون دقة الشاشة VGA على الأقل (640×480 بكسل).
• يجب عدم استخدام الكاميرا الأمامية كإعداد تلقائي لواجهة برمجة التطبيقات Camera API. توفّر واجهة برمجة التطبيقات للكاميرا في 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. سلوك Camera API

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

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

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

• إذا لم يسبق للتطبيق استدعاء android.hardware.Camera.Parameters.setPreviewFormat(int)، يجب أن يستخدم الجهاز android.hardware.PixelFormat.YCbCr_420_SP لبيانات المعاينة المقدَّمة إلى عمليات استدعاء التطبيق.
• إذا سجّل تطبيق مثيلًا من android.hardware.Camera.PreviewCallback واستدعى النظام الطريقة onPreviewFrame() عندما يكون تنسيق المعاينة هو YCbCr_420_SP، يجب أن تكون البيانات في السلسلة byte[] التي تم تمريرها إلى 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.

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

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

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

يجب أيضًا أن تحدِّد عمليات تنفيذ الأجهزة إمكانات الكاميرا الفردية من android.hardware.camera2 من خلال السمة android.request.availableCapabilities وأن تحدِّد رموز الميزة المناسبة، ويجب أن يحدِّد الجهاز رمز الميزة إذا كانت أي من كاميراته المُرفَقة تتيح هذه الميزة.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

بدلاً من ذلك، يجوز لعمليات تنفيذ الأجهزة تخصيص مساحة تخزين داخلية (غير قابلة للإزالة) كمساحة تخزين مشترَكة للتطبيقات كما هو مضمّن في مشروع Android Open Source Project الأساسي. ويجب أن تستخدِم عمليات تنفيذ الأجهزة هذا الإعداد وتنفيذ البرامج. إذا كان تطبيق معيّن على الجهاز يستخدم مساحة تخزين داخلية (غير قابلة للإزالة) لاستيفاء متطلبات مساحة التخزين المشتركة، على الرغم من أنّه يجوز لمساحة التخزين هذه مشاركة المساحة مع البيانات الخاصة بالتطبيق، يجب أن يكون حجمها 1 غيغابايت على الأقل وأن يتم تركيبها على ‎ /sdcard (أو يجب أن يكون ‎ /sdcard رابطًا رمزيًا للموقع الجغرافي إذا تم تركيبه في مكان آخر).

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

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

ومع ذلك، من المفترض أن تعرض عمليات تنفيذ الأجهزة المحتوى من كلا مسارَي التخزين بشكل شفاف من خلال خدمة "أداة فحص الوسائط" في 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 micro-B أو micro-AB أو Type-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 chirp ووقت نقل البيانات كما هو محدّد في مواصفات شحن البطارية عبر USB، المراجعة 1.2. ننصح بشدة بتوافق أجهزة Android الحالية والجديدة مع هذه المتطلبات حتى تتمكّن من الترقية إلى إصدارات المنصة المستقبلية.
• يجب أن ترصد أجهزة Type-C شواحن بقدرة 1.5 أمبير و3.0 أمبير وفقًا لمعيار المقاوم Type-C، ويجب أن ترصد التغييرات في الإعلان.
• يُنصح بشدة بتوفير ميزة "إرسال الطاقة" في أجهزة USB من النوع C التي تتيح أيضًا وضع مضيف USB من أجل تبادل دور الطاقة والبيانات.
• يجب أن تتوافق أجهزة Type-C مع بروتوكول Power Delivery للشحن بفولتية عالية ويجب أن تتوافق مع الأوضاع البديلة، مثل إخراج الشاشة.
• يجب أن تكون قيمة iSerialNumber في وصف جهاز USB العادي مساوية لقيمة android.os.Build.SERIAL.
• يُنصح بشدة بعدم استخدام طرق الشحن الحصرية التي تعدّل جهد Vbus إلى ما بعد المستويات التلقائية أو تُغيّر أدوار مصدر الطاقة أو المستهلك، لأنّ ذلك قد يؤدي إلى مشاكل في التشغيل التفاعلي مع الشواحن أو الأجهزة التي تتيح طرق إرسال الطاقة عبر USB العادية. على الرغم من أنّنا ننصحك بشدة باستخدام هذه الميزة، قد نشترط في الإصدارات المستقبلية من Android أن تتيح جميع الأجهزة التي تستخدم موصلات من النوع C إمكانية التشغيل التفاعلي الكامل مع شواحن من النوع C عادية.

7.7.2. وضع مضيف USB

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

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

7.8. الصوت

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

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

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

7.8.2. إخراج الصوت

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

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

في المقابل، إذا لم يتضمّن تنفيذ الجهاز مكبّر صوت أو منفذ إخراج صوت، يجب ألّا يُبلغ عن ميزة إخراج الصوت android.hardware.audio، ويجب تنفيذ واجهات برمجة التطبيقات ذات الصلة بإخراج الصوت على أنّها عمليات لا تؤدي إلى أيّ إجراء على الأقل.

قد يتضمّن تطبيق Android Watch إخراجًا للصوت، ولكن لا يُنصَح بذلك، في حين يجب أن يتضمّن تطبيق أنواع أخرى من أجهزة Android إخراجًا للصوت وأن يعلن عن 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 Ohm : KEYCODE_VOLUME_UP
  • ‫‎360-680 Ohm : 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_ULTRASOUND هي "صحيح"، يجب أن تستوفي مصادر الصوت VOICE_RECOGNITION وUNPROCESSED المتطلبات التالية:
  • يجب ألا يقلّ متوسط استجابة الطاقة للميكروفون في النطاق من 18.5 كيلوهرتز إلى 20 كيلوهرتز عن 15 ديسيبل عن الاستجابة عند 2 كيلوهرتز.
  • يجب ألا تقل نسبة الإشارة إلى الضوضاء غير المحسوبة للميكروفون عن 50 ديسيبل عند تردد يتراوح بين 18.5 كيلوهرتز و20 كيلوهرتز لنغمة 19 كيلوهرتز عند -26 ديسيبل عادي.
• إذا كان PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND يساوي "true"، يجب ألا يقلّ متوسّط استجابة مكبّر الصوت في النطاق من 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.getExclusiveCores لعرض أرقام أنوية وحدة المعالجة المركزية الحصرية للتطبيق الأهم الذي يعمل في المقدّمة. إذا كان استخدام النواة الحصرية متاحًا، يجب ألا تسمح النواة بتشغيل أي عمليات أخرى في مساحة المستخدم (باستثناء برامج تشغيل الأجهزة التي يستخدمها التطبيق)، ولكن يجوز لها السماح بتشغيل بعض عمليات النواة حسب الضرورة.
• يجب أن تتيح عمليات تنفيذ الأجهزة وضع الأداء المستدام.
• يجب أن تكون آليات التنفيذ على الأجهزة متوافقة مع OpenGL ES 3.2.
• يجب أن تتوافق عمليات تنفيذ الأجهزة مع المستوى 0 من Vulkan Hardware ويجب أن تتوافق مع المستوى 1 من Vulkan Hardware.
• يجب أن توفّر عمليات تنفيذ الأجهزة 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_multisampled_render_to_texture وGL_OVR_multiview وGL_OVR_multiview2 وGL_OVR_multiview_multisampled_render_to_texture، وأن تُظهر الإضافات في قائمة إضافات GL المتاحة.
• يجب أن تُنفِّذ عمليات تنفيذ الأجهزة واجهة EGL_EXT_protected_content وGL_EXT_protected_textures لكي يمكن استخدامها لتشغيل الفيديوهات ذات النسيج الآمن، ويجب عرض الإضافات في قائمة إضافات EGL وGL المتاحة.
• يجب أن تتيح عمليات تنفيذ الأجهزة فك ترميز H.264 بمعدّل لا يقل عن 3840×2160 بمعدل 30 لقطة في الثانية وسرعة 40 ميغابت في الثانية (أي ما يعادل 4 عمليات فك ترميز بدقة 1920×1080 بمعدل 30 لقطة في الثانية وسرعة 10 ميغابت في الثانية أو عمليتَي فك ترميز بدقة 1920×1080 بمعدل 60 لقطة في الثانية وسرعة 20 ميغابت في الثانية).
• يجب أن تكون عمليات تنفيذ الأجهزة متوافقة مع HEVC وVP9، ويجب أن تكون قادرة على فك ترميز 1920×1080 بمعدل 30 لقطة في الثانية وسرعة 10 ميغابت في الثانية على الأقل، ويجب أن تكون قادرة على فك ترميز 3840×2160 بمعدل 30 لقطة في الثانية وسرعة 20 ميغابت في الثانية (أي ما يعادل 4 عمليات فك ترميز بدقة 1920×1080 بمعدل 30 لقطة في الثانية وسرعة 5 ميغابت في الثانية).
• ننصح بشدة بتوفير ميزة android.hardware.sensor.hifi_sensors في عمليات تنفيذ الأجهزة، ويجب أن تستوفي هذه العمليات المتطلبات المتعلقة بجهاز الاستشعار الدوراني ومقياس التسارع ومقياس المغناطيسية لميزة android.hardware.sensor.hifi_sensors.
• يجب أن تتوافق عمليات تنفيذ الأجهزة مع واجهة برمجة التطبيقات HardwarePropertiesManager.getDeviceTemperatures وأن تعرِض قيمًا دقيقة لدرجة حرارة الجلد.
• يجب أن يتضمّن تطبيق الجهاز شاشة مدمجة، ويجب أن تكون درجة دقتها FullHD(1080p) على الأقل، ويُنصح بشدة باستخدام دقة QuadHD (1440p) أو أعلى.
• يجب أن يتراوح حجم الشاشة بين 4.7 و6 بوصات (12 و15 سم) قطريًا.
• يجب أن يتم تعديل الشاشة بمعدّل 60 هرتز على الأقل أثناء استخدام "وضع الواقع الافتراضي".
• يجب أن يكون وقت استجابة الشاشة في ما يتعلّق بتغيير اللون من الرمادي إلى الرمادي، ومن الأبيض إلى الأسود، ومن الأسود إلى الأبيض أقل من 3 مللي ثانية.
• يجب أن تتيح الشاشة وضعًا بفترة بقاء منخفضة لا تزيد عن 5 ملي ثانية، وفترة البقاء هي الوقت الذي يُصدر فيه بكسل ضوءًا.
• يجب أن تكون عمليات تنفيذ الأجهزة متوافقة مع معيار Bluetooth 4.2 وإضافة طول البيانات في Bluetooth LE الفقرة 7.4.3.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9.1. الأذونات

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

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

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

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

9.2. رقم تعريف المستخدم (UID) وعزل العمليات

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

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

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

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

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

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

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

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

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

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

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

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

9.5. ميزة "الوصول المتعدد"

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

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

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

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

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

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

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

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

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

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

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

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

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

9.8. الخصوصية

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

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

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

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

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

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

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

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

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

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

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

9.9.2. التشفير على مستوى الملفات

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

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

مفاتيح حماية مساحتَي التخزين CE وDE:

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

يقدّم مشروع Android Open Source الإصدار الأصلي من هذه الميزة استنادًا إلى ميزة التشفير ext4 في نواة Linux.

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

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

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

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

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

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

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

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

بدءًا من Android 6.0، يجب أن تتيح عمليات تنفيذ الأجهزة التي تزيد فيها سرعة التشفير وفقًا لمعيار Advanced Encryption Standard (AES) عن 50 ميغابايت في الثانية ميزة "التمهيد التحقق منه" للحفاظ على سلامة الجهاز.

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

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

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

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

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

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

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

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

• إذا كانت طريقة المصادقة تستند إلى سر معروف، يجب عدم التعامل معها على أنّها شاشة قفل آمنة ما لم تستوفِ جميع المتطلبات التالية:
  • يجب أن تكون قيمة الانتروبي لأقصر طول مسموح به للعناصر أكبر من 10 بت.
  • يجب أن يكون الحد الأقصى للانتروبيا لجميع الإدخالات المحتملة أكبر من 18 بت.
  • يجب ألّا تحلّ محل أي من طرق المصادقة الحالية (رقم التعريف الشخصي أو النمط أو كلمة المرور) التي تم تنفيذها وتوفيرها في AOSP.
  • يجب إيقافه عندما يضبط تطبيق "وحدة التحكّم بسياسة الجهاز" سياسة جودة كلمة المرور من خلال طريقة DevicePolicyManager.setPasswordQuality() باستخدام ثابت جودة أكثر تقييدًا من PASSWORD_QUALITY_SOMETHING .
• يجب عدم التعامل مع طريقة المصادقة على أنّها شاشة قفل آمنة إذا كانت تستند إلى رمز مميّز مادي أو الموقع الجغرافي، ما لم تستوفِ جميع المتطلبات التالية:
  • يجب أن تتضمّن آلية احتياطية لاستخدام إحدى طرق المصادقة الأساسية التي تستند إلى سر معروف وتستوفي المتطلبات لمعالجتها كشاشة قفل آمنة.
  • يجب إيقاف هذه الميزة والسماح للمصادقة الأساسية فقط بإلغاء قفل الشاشة عندما يضبط تطبيق "وحدة التحكّم في سياسة الجهاز" (DPC) السياسة باستخدام طريقة DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) أو طريقة DevicePolicyManager.setPasswordQuality() مع ثابت جودة أكثر تقييدًا من PASSWORD_QUALITY_UNSPECIFIED .
• يجب عدم التعامل مع طريقة المصادقة، إذا كانت تستند إلى المقاييس الحيوية، كشاشة قفل آمنة ما لم تستوفِ جميع المتطلبات التالية:
  • يجب أن تتضمّن آلية احتياطية لاستخدام إحدى طرق المصادقة الأساسية التي تستند إلى سر معروف وتستوفي المتطلبات لمعالجتها كشاشة قفل آمنة.
  • يجب إيقاف هذه الميزة والسماح للمصادقة الأساسية فقط بفتح قفل الشاشة عندما يضبط تطبيق Device Policy Controller (DPC) سياسة ميزة keguard من خلال استدعاء الطريقة DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT).
  • يجب أن يكون معدّل القبول الخاطئ مساويًا أو أقوى من المعدّل المطلوب لجهاز استشعار بصمة الإصبع كما هو موضّح في القسم 7.3.10، أو يجب إيقافه وعدم السماح إلا بالمصادقة الأساسية لفتح قفل الشاشة عندما يضبط تطبيق Device Policy Controller (DPC) سياسة جودة كلمة المرور من خلال طريقة DevicePolicyManager.setPasswordQuality() باستخدام ثابت جودة أكثر تقييدًا من PASSWORD_QUALITY_BIOMETRIC_WEAK .
• إذا تعذّر التعامل مع طريقة المصادقة كشاشة قفل آمنة، يتم تنفيذ ما يلي:
  • يجب أن تُعرِض الطريقة KeyguardManager.isKeyguardSecure() والطريقة KeyguardManager.isDeviceSecure() القيمة false.
  • يجب إيقافه عندما يضبط تطبيق "وحدة التحكّم بسياسة الجهاز" سياسة جودة كلمة المرور من خلال طريقة 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. يجب استخدام هذا الإجراء لتنفيذ واجهة برمجة التطبيقات wipeData()‎ (جزء من واجهة برمجة التطبيقات Android Device Administration API) الموضّحة في القسم 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 Verifier) بشكل صحيح. يتم تضمين أداة التحقّق من CTS في مجموعة اختبار التوافق، ومن المفترض أن يشغّلها مشغل بشري لاختبار الوظائف التي لا يمكن اختبارها من خلال نظام آلي، مثل الأداء الصحيح للكاميرا وأجهزة الاستشعار.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. المقدّمة
2. أنواع الأجهزة
3. البرامج
4. تجميع التطبيقات
5. الوسائط المتعددة
6. أدوات المطوّرين وخياراتهم
7. توافق الأجهزة
8. الأداء واستهلاك الطاقة
9. نموذج الأمان
10. اختبار توافق البرامج
11. البرامج القابلة للتحديث
12. سجلّ تغييرات المستندات
13. التواصل معنا

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

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

• CDD
  التغييرات الجوهرية في متطلبات التوافق

• مستندات Google
  التغييرات المتعلقة بالمظهر أو التصميم

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

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

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