اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.

تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

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

جدول المحتويات

1. المقدّمة
2- المراجع
3- البرامج

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

3.2.1. الأذونات
3.2.2. مَعلمات الإنشاء
3.2.3. توافق النية

3.2.3.1. نوايا التطبيقات الأساسية
3.2.3.2. إلغاء النية
3.2.3.3. مساحات أسماء الأهداف
3.2.3.4. نوايا البث

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

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

3.5. التوافق السلوكي لواجهة برمجة التطبيقات
3.6. مساحات أسماء واجهة برمجة التطبيقات
3.7. توافق الأجهزة الافتراضية
3.8. توافق واجهة المستخدم

3.8.1. التطبيقات المصغّرة
3.8.2. الإشعارات
3.8.3. البحث
3.8.4. رسائل التذكير
3.8.5. الخلفيات المتحركة

‫4. توافق حِزم التطبيقات
5- التوافق مع الوسائط المتعددة

5.1. برامج ترميز الوسائط
5.1.1. برامج ترميز الوسائط
5.1.2. برامج ترميز الوسائط
5.2. التسجيل الصوتي
5.3. وقت استجابة الصوت

‫6. توافق أدوات المطوّرين
7- التوافق مع الأجهزة

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

7.1.1. إعدادات الشاشة
7.1.2. مقاييس الشبكة الإعلانية
7.1.3. التوافق مع الشاشة المعلَن عنه
7.1.4. اتجاه الشاشة
7.1.5. تسريع الرسومات الثلاثية الأبعاد

7.2. أجهزة الإدخال

7.2.1. لوحة المفاتيح
7.2.2. التنقّل بدون لمس الشاشة
7.2.3. مفاتيح التنقّل
7.2.4. الإدخال باللمس

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

7.3.1. مقياس التسارع
7.3.2. مقياس المغناطيسية
7.3.3. نظام تحديد المواقع العالمي (GPS)
7.3.4. الجيروسكوب
7.3.5. مقياس الضغط الجوي
7.3.6. الترمومتر
7.3.7. مقياس الإضاءة
7.3.8. أداة استشعار التقارب

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

7.4.1. الاتصال الهاتفي
7.4.2. معيار IEEE 802.11 (WiFi)
7.4.3. البلوتوث
7.4.4. تكنولوجيا الاتصال القصير المدى
7.4.5. الحد الأدنى لإمكانية الاتصال بالشبكة

7.5. الكاميرات

7.5.1. الكاميرا الخلفية
7.5.2. الكاميرا الأمامية
7.5.3. سلوك Camera API
7.5.4. اتجاه الكاميرا

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

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

7.7. USB

‫8. التوافق مع الأداء
9- توافق نموذج الأمان

9.1. الأذونات
9.2. المعرّف الفريد لعزل العمليات
9.3. أذونات نظام الملفات
9.4. بيئات التنفيذ البديلة

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

10.1. مجموعة أدوات اختبار التوافق
10.2. أداة التحقّق من توافق الأجهزة مع مجموعة أدوات اختبار التوافق (CTS)
10.3. التطبيقات المرجعية

‫11. البرامج القابلة للتحديث
12- التواصل معنا
الملحق أ: إجراء اختبار البلوتوث

‫1. مقدّمة

يسرد هذا المستند المتطلبات التي يجب استيفاؤها لكي تكون الهواتف الجوّالة متوافقة مع الإصدار 2.3 من نظام التشغيل Android.

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

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

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

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

يُرجى العِلم أنّه تم إصدار تعريف التوافق هذا ليتوافق مع تحديث Android 2.3.3، وهو المستوى 10 لواجهة برمجة التطبيقات. يحلّ هذا التعريف محل تعريف التوافق لإصدارات Android 2.3 الأقدم من 2.3.3 ويُنهي صلاحيته. (أي أنّ الإصدارَين 2.3.1 و2.3.2 قديمان). يجب أن تكون الأجهزة المتوافقة مع Android القادمة التي تعمل بالإصدار 2.3 مزوّدة بالإصدار 2.3.3 أو إصدار أحدث.

‫2- المراجع

مستويات متطلبات RFC2119 من IETF: http://www.ietf.org/rfc/rfc2119.txt

نظرة عامة على "برنامج التوافق مع Android": http://source.android.com/docs/compatibility/index.html

مشروع مفتوح المصدر لنظام Android: http://source.android.com/

تعريفات واجهات برمجة التطبيقات ومستنداتها: http://developer.android.com/reference/packages.html

مرجع أذونات Android: http://developer.android.com/reference/android/Manifest.permission.html

مرجع android.os.Build: http://developer.android.com/reference/android/os/Build.html

سلاسل الإصدارات المسموح بها لنظام التشغيل Android 2.3: http://source.android.com/docs/compatibility/2.3/versions.html

فئة android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html

HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/

إمكانات HTML5 بلا إنترنت: http://dev.w3.org/html5/spec/Overview.html#offline

علامة فيديو HTML5: http://dev.w3.org/html5/spec/Overview.html#video

واجهة برمجة التطبيقات لتحديد الموقع الجغرافي في HTML5/W3C: http://www.w3.org/TR/geolocation-API/

واجهة برمجة التطبيقات لقاعدة بيانات الويب HTML5/W3C: http://www.w3.org/TR/webdatabase/

واجهة برمجة التطبيقات IndexedDB في HTML5/W3C: http://www.w3.org/TR/IndexedDB/

مواصفات جهاز Dalvik الافتراضي: متوفّرة في رمز مصدر Android، على dalvik/docs

التطبيقات المصغّرة: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html

الإشعارات: http://developer.android.com/guide/topics/ui/notifiers/notifications.html

موارد التطبيق: http://code.google.com/android/reference/available-resources.html

دليل أسلوب رموز شريط الحالة: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure

Search Manager: ‏ http://developer.android.com/reference/android/app/SearchManager.html

الرسائل المنبثقة: http://developer.android.com/reference/android/widget/Toast.html

الخلفيات المتحركة: https://android-developers.googleblog.com/2010/02/live-wallpapers.html

مستندات الأداة المرجعية (لبرنامج adb وaapt وddms): http://developer.android.com/guide/developing/tools/index.html

وصف ملف apk لنظام التشغيل Android: http://developer.android.com/guide/topics/fundamentals.html

ملفات البيان: http://developer.android.com/guide/topics/manifest/manifest-intro.html

أداة اختبار Monkey: https://developer.android.com/studio/test/other-testing-tools/monkey

قائمة ميزات أجهزة Android: http://developer.android.com/reference/android/content/pm/PackageManager.html

التوافق مع شاشات متعددة: http://developer.android.com/guide/practices/screens_support.html

‫android.util.DisplayMetrics: ‏ http://developer.android.com/reference/android/util/DisplayMetrics.html

‫android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html

مساحة إحداثيات أداة الاستشعار: http://developer.android.com/reference/android/hardware/SensorEvent.html

واجهة برمجة تطبيقات البلوتوث: http://developer.android.com/reference/android/bluetooth/package-summary.html

بروتوكول دفع NDEF: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf

شريحة MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf

شريحة MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf

‫MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf

‫MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf

MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf

MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf

واجهة برمجة التطبيقات لاتجاه الكاميرا: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)

‫android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html

مرجع أمان Android وأذوناته: http://developer.android.com/guide/topics/security/security.html

التطبيقات لنظام التشغيل Android: http://code.google.com/p/apps-for-android

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

3- البرامج

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

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

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

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

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

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

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

3.2.1. الأذونات

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

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

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

المَعلمة	التعليقات
android.os.Build.VERSION.RELEASE	إصدار نظام Android الذي يتم تنفيذه حاليًا بتنسيق يمكن للمستخدم قراءته يجب أن يحتوي هذا الحقل على إحدى قيم السلاسل المحدّدة في [الموارد، 7].
android.os.Build.VERSION.SDK	إصدار نظام Android الذي يتم تنفيذه حاليًا بتنسيق يمكن لرمز التطبيق التابع لجهة خارجية الوصول إليه بالنسبة إلى Android 2.3، يجب أن يحتوي هذا الحقل على القيمة الصحيحة 9.
android.os.Build.VERSION.INCREMENTAL	قيمة يختارها مُنفِّذ الجهاز لتحديد الإصدار المحدّد من نظام Android الذي يتم تنفيذه حاليًا، بتنسيق يمكن لشخص عادي قراءته يجب عدم إعادة استخدام هذه القيمة لإصدارات مختلفة يتم توفيرها للمستخدمين النهائيين. من الاستخدامات الشائعة لهذا الحقل الإشارة إلى رقم الإصدار أو معرّف تغيير تحكّم المصدر المستخدَم لإنشاء الإصدار. ما مِن متطلبات تتعلّق بالتنسيق المحدد لهذا الحقل، باستثناء أنّه يجب ألّا يكون فارغًا أو سلسلة ملف فارغة ("").
android.os.Build.BOARD	قيمة يختارها منفذ الجهاز لتحديد الجهاز الداخلي المُحدَّد الذي يستخدمه الجهاز، بتنسيق يمكن لشخص عادي قراءته من الاستخدامات المحتملة لهذا الحقل هو الإشارة إلى المراجعة المحدّدة للوحة التي تشغّل الجهاز. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.BRAND	قيمة يختارها مُنفِّذ الجهاز لتحديد اسم الشركة أو المؤسسة أو الفرد أو غير ذلك الذي أنتج الجهاز، بتنسيق يمكن لشخص عادي قراءته من الاستخدامات المحتملة لهذا الحقل الإشارة إلى المصنّع الأصلي للجهاز و/أو مشغّل شبكة الجوّال الذي باع الجهاز. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.DEVICE	قيمة يختارها منفذ الجهاز لتحديد الإعدادات أو المراجعة المحدّدة للجسم (يُشار إليها أحيانًا باسم "التصميم الصناعي") للجهاز يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بت ويجب أن تتطابق مع التعبير العادي `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.FINGERPRINT	سلسلة تحدّد هذا الإصدار بشكل فريد يجب أن يكون التنسيق سهل القراءة. يجب أن يتّبع هذا النموذج: `$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)` على سبيل المثال: `acme/mydevice/generic/generic:2.3/ERC77/3359:userdebug/test-keys` يجب ألّا يتضمّن الملف المرجعي أحرف مسافات بيضاء. إذا كانت الحقول الأخرى المضمّنة في النمط أعلاه تحتوي على أحرف مسافات بيضاء، يجب استبدالها في بصمة الإصدار بحرف آخر، مثل الشرطة السفلية ("_"). يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات.
android.os.Build.HOST	سلسلة تحدِّد بشكل فريد المضيف الذي تم إنشاء الإصدار عليه، بتنسيق يمكن لشخص عادي قراءته لا توجد متطلبات بشأن التنسيق المحدّد لهذا الحقل، باستثناء أنّه يجب ألّا يكون فارغًا أو سلسلة فارغة ("").
android.os.Build.ID	معرّف يختاره مُنفِّذ الجهاز للإشارة إلى إصدار معيّن، بتنسيق يمكن للمستخدم قراءته يمكن أن يكون هذا الحقل هو نفسه android.os.Build.VERSION.INCREMENTAL، ولكن يجب أن يكون له قيمة مفيدة بما يكفي للمستخدمين النهائيين من أجل التمييز بين إصدارات البرامج. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.MODEL	قيمة يختارها منفذ الجهاز تحتوي على اسم الجهاز كما يعرفه المستخدم النهائي. يجب أن يكون هذا هو الاسم نفسه الذي يتم بموجبه تسويق الجهاز وبيعه للمستخدمين النهائيين. ما مِن متطلبات بشأن التنسيق المحدد لهذا الحقل، باستثناء أنّه يجب ألّا يكون فارغًا أو سلسلة فارغة ("").
android.os.Build.PRODUCT	قيمة يختارها مُنفِّذ الجهاز تحتوي على اسم التطوير أو الاسم الرمزي للجهاز. يجب أن تكون قابلة للقراءة من قِبل البشر، ولكن ليس بالضرورة أن تكون مقصودة لعرضها على المستخدمين النهائيين. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.TAGS	قائمة مفصولة بفواصل بالعلامات التي اختارها مُنفِّذ الجهاز والتي تُميِّز الإصدار بشكلٍ أكبر. على سبيل المثال، "unsigned,debug". يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.TIME	قيمة تمثّل الطابع الزمني لوقت إنشاء الإصدار
android.os.Build.TYPE	قيمة يختارها مُنفِّذ الجهاز لتحديد إعدادات وقت التشغيل للإصدار يجب أن يحتوي هذا الحقل على إحدى القيم التالية المتوافقة مع الإعدادات الثلاثة المعتادة لوقت تشغيل Android: "user" أو "userdebug" أو "eng". يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.USER	اسم أو معرّف مستخدم (أو مستخدم مبرمَج) أنشأ الإصدار ما مِن متطلبات بشأن التنسيق المحدّد لهذا الحقل، باستثناء أنّه يجب ألّا يكون فارغًا أو سلسلة فارغة ("").

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

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

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

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

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

تُعد التطبيقات التالية من تطبيقات نظام Android الأساسية:

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

تتضمّن تطبيقات نظام Android الأساسية مكوّنات مختلفة من النشاط أو الخدمة والتي تُعدّ "عامة". وهذا يعني أنّ السمة "android:exported" قد تكون غير متوفّرة، أو قد تكون قيمتها "true".

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

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

3.2.3.2. عمليات إلغاء النية

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

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

يجب ألا يُدرِج مورّدو الأجهزة أي مكوّن Android يراعي أي تصاميم جديدة لIntent أو Intent البث باستخدام سلسلة مفتاح ACTION أو CATEGORY أو غيرها في مساحة الاسم android.*. يجب ألّا يُدرِج مورّدو الأجهزة أيّ مكوّنات Android تلتزم بأيّ أنماط جديدة لIntent أو Broadcast Intent باستخدام سلسلة مفتاح ACTION أو CATEGORY أو سلسلة مفتاح أخرى في مساحة حزمة تنتمي إلى مؤسسة أخرى. على جهات تنفيذ الأجهزة عدم تغيير أو توسيع أي من أنماط Intent المستخدَمة من قِبل التطبيقات الأساسية المُدرَجة في القسم 3.2.3.1.

يشبه هذا الحظر الحظر المحدّد لفئات لغة Java في القسم 3.6.

3.2.3.4. نوايا البث

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

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

يمكن للرمز المُدار الذي يعمل في Dalvik طلب رمز أصلي مُقدَّم فيملف APK .‎ application كملف ELF .‎ so تم تجميعه للبنية المتوافقة مع الأجهزة الجهاز. بما أنّ الرموز البرمجية الأصلية تعتمد بشكل كبير على تكنولوجيا المعالج الأساسية، يحدِّد نظام Android عددًا من واجهات التطبيق الثنائية (ABI) في حزمة تطوير البرامج (NDK) لنظام Android، في الملف docs/CPU-ARCH-ABIS.txt. إذا كان تطبيق الجهاز متوافقًا مع واجهة برمجة تطبيقات واحدة أو أكثر محدّدة، يجب أن يتوافق مع IDE لنظام التشغيل Android NDK، كما هو موضّح أدناه.

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

يجب أن تتضمّن واجهة برمجة تطبيقات متوافقة مع الرموز البرمجية التي تعمل في البيئة المُدارة للاتّصال بالرمز البرمجي الأصلي، وذلك باستخدام بنية Java Native Interface (JNI) المعيارية.
يجب أن يكون متوافقًا مع المصدر (أي متوافقًا مع العنوان) ومتوافقًا مع الثنائي (لمعيار ABI) مع كل مكتبة مطلوبة في القائمة أدناه
يجب أن يُبلغ التطبيق بدقة عن واجهة برمجة التطبيقات (ABI) المحلية المتوافقة مع الجهاز من خلال واجهة برمجة التطبيقات android.os.Build.CPU_ABI .
يجب الإبلاغ فقط عن واجهات التطبيق الثنائية (ABI) الموثَّقة في أحدث إصدار من Android NDK، في الملف docs/CPU-ARCH-ABIS.txt
يجب إنشاؤها باستخدام رمز المصدر وملفات الرأس المتاحة في المشروع المفتوح المصدر لنظام التشغيل Android

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

libc (مكتبة C)
libm (مكتبة الرياضيات)
الحد الأدنى من التوافق مع C++
واجهة JNI
liblog (تسجيل Android)
libz (ضغط Zlib)
libdl (الرابط الديناميكي)
libGLESv1_CM.so (OpenGL ES 1.0)
libGLESv2.so (OpenGL ES 2.0)
libEGL.so (إدارة سطح OpenGL الأصلي)
libjnigraphics.so
libOpenSLES.so (دعم الصوت في مكتبة Open Sound Library)
libandroid.so (لتوفير وظائف الأنشطة الأصلية في Android)
توفُّر OpenGL، كما هو موضّح أدناه

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

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

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

يعتمد العديد من المطوّرين والتطبيقات على سلوك فئة android.webkit.WebView [Resources, 8] لواجهات المستخدم الخاصة بهم، لذا يجب أن يكون تنفيذ WebView متوافقًا مع جميع عمليات تنفيذ Android. وبالمثل، يُعدّ متصفّح الويب المتكامل الحديث أمرًا أساسيًا لتجربة مستخدم Android. يجب أن تتضمّن عمليات تنفيذ التطبيقات على الأجهزة إصدارًا من android.webkit.WebView متوافقًا مع الإصدار الأحدث من برنامج Android، ويجب أن تتضمّن متصفّحًا حديثًا متوافقًا مع HTML5، كما هو описан أدناه.

3.4.1. توافق WebView

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

android.webkit.WebViewيجب أن تستند عمليات تنفيذ android.webkit.WebView الأجهزة إلى الإصدار 533.1 من WebKit من شجرة Android Open Source المتوفّرة في الإصدارات السابقة لنظام التشغيل Android 2.3. يتضمّن هذا الإصدار مجموعة محدّدة من الإصلاحات المتعلقة بالوظائف والأمان في WebView. يجوز لمطوّري الأجهزة تضمين تخصيصات لتنفيذ WebKit، ولكن يجب ألا تؤدي أي من هذه التخصيصات إلى تغيير سلوك WebView، بما في ذلك سلوك المعالجة.
يجب أن تكون سلسلة وكيل المستخدم التي يُبلغ عنها WebView بالتنسيق التالي:
Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
- يجب أن تكون قيمة سلسلة $(VERSION) مطابقة لقيمة android.os.Build.VERSION.RELEASE.
- يجب أن تتّبع قيمة السلسلة $(LOCALE) اصطلاحات ISO الخاصة برمز البلد واللغة، ويجب أن تشير إلى اللغة المُعدّة حاليًا على الجهاز.
- يجب أن تكون قيمة سلسلة $(MODEL) مطابقة لقيمة android.os.Build.MODEL.
- يجب أن تكون قيمة السلسلة $(BUILD) هي نفسها قيمة android.os.Build.ID.

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

ذاكرة التخزين المؤقت للتطبيق/العمل بلا إنترنت [الموارد، 10]
علامة <video> [الموارد، 11]
تحديد الموقع الجغرافي [المَراجع، 12]

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

يجب إيقاف واجهات برمجة تطبيقات HTML5 تلقائيًا في WebView، مثل جميع واجهات برمجة تطبيقات JavaScript، ما لم يفعّلها المطوّر صراحةً من خلال واجهات برمجة تطبيقات Android المعتادة.

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

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

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

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

ذاكرة التخزين المؤقت للتطبيق/العمل بلا إنترنت [الموارد، 10]
علامة <video> [الموارد، 11]
تحديد الموقع الجغرافي [المَراجع، 12]

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

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

يجب ألا تغيّر الأجهزة سلوك Intent العادي أو دلالته.
يجب ألّا تغيّر الأجهزة دورة الحياة أو دلالات دورة الحياة لنوع معيّن من مكوّنات النظام (مثل 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>mechanism) بزيادة استخدام الذاكرة لهذه الواجهات.

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

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

3.7 توافق الآلة الافتراضية

يجب أن تتوافق عمليات تنفيذ التطبيقات على الأجهزة مع مواصفات رمز bytecode الكامل لملف Dalvik القابل للتنفيذ (DEX) ودلالات Dalvik Virtual Machine [Resources, 15].

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

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

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

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

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

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

3.8.2. الإشعارات

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

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

3.8.3. البحث

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

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

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

3.8.4. النخب

يمكن للتطبيقات استخدام واجهة برمجة التطبيقات Toast (المحدّدة في [Resources, 21]) لعرض سلاسل قصيرة غير مشروطة للمستخدم النهائي، والتي تختفي بعد فترة زمنية قصيرة. يجب أن تعرِض عمليات تنفيذ الأجهزة إشعارات Toast من التطبيقات للمستخدمين النهائيين بطريقة واضحة جدًا.

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

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

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

يجب أن تتضمّن عمليات تنفيذ الأجهزة التي يمكنها تشغيل الخلفيات المتحركة بشكل موثوق كما هو описан أعلاه ميزة الخلفيات المتحركة. يجب عدم تنفيذ الخلفيات المتحركة في عمليات تنفيذ الأجهزة التي تم تحديد أنّها لا تعمل بالخلفيات المتحركة بشكل موثوق كما هو موضّح أعلاه.

‫4- توافق حِزم التطبيقات

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

يجب ألا تؤدي عمليات تنفيذ الأجهزة إلى توسيع تنسيقات ملف ‎ .apk [Resources, 24] أو بيان Android [Resources, 25] أو رمز Dalvik البرمجي [Resources, 15] بطريقة تمنع تثبيت هذه الملفات وتشغيلها بشكل صحيح على الأجهزة المتوافقة الأخرى. على مطوّري التطبيقات المتوافقة مع الأجهزة استخدام التنفيذ المرجعي لنظام Dalvik و نظام إدارة الحِزم المرجعي.

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

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

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

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

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

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

5.1.1. برامج فك ترميز الوسائط

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

الصوت
	الاسم	التفاصيل	تنسيق الملف/الحاوية
	‫AAC LC/LTP	محتوى صوت أحادي/استيريو بأي مجموعة من معدلات نقل البيانات العادية التي تصل إلى 160 كيلوبت في الثانية ومعدّلات أخذ العينات التي تتراوح بين 8 و48 كيلوهرتز	‫3GPP (‎.3gp) وMPEG-4 (‎.mp4 و‎.m4a) لا تتوفّر إمكانية استخدام ملفات AAC غير المُعدَّلة (‎.aac).
	‫HE-AACv1 (AAC+)
	HE-AACv2 (الترميز المتقدّم للصوت المحسّن)
	AMR-NB	من 4.75 إلى 12.2 كيلوبت في الثانية بمعاينة بمعدل 8 كيلوهرتز	3GPP (‎.3gp)
	AMR-WB	9 معدّلات تتراوح بين 6.60 كيلوبت في الثانية و23.85 كيلوبت في الثانية بمعدّل أخذ عينات يبلغ 16 كيلوهرتز	3GPP (‎.3gp)
	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).
	Ogg Vorbis		Ogg (‎.ogg)
	إدارة إمكانية وصول الشركاء إلى الأجهزة الذكية (PCM)	تنسيق PCM الخطي بترميز 8 و16 بت (بمعدلات تصل إلى الحد الأقصى للأجهزة)	WAVE (‎.wav)
الصورة
	JPEG	base+progressive
	ملف GIF
	PNG
	BMP
الفيديو
	‫H.263		ملفات 3GPP (‎.3gp)
	H.264		ملفات 3GPP (‎.3gp) وMPEG-4 (‎.mp4)
	الملف الشخصي البسيط لـ MPEG4		ملف 3GPP ‏(‎.3gp)

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

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

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

الصوت
	الاسم	التفاصيل	تنسيق الملف/الحاوية	الشروط
	AMR-NB	من 4.75 إلى 12.2 كيلوبت في الثانية بمعاينة بمعدل 8 كيلوهرتز	3GPP (‎.3gp)	يجب أن تتضمّن عمليات تنفيذ الأجهزة التي تتضمّن أجهزة ميكروفون وتحدِّد `android.hardware.microphone` برامج ترميز لتنسيقات الصوت هذه.
	AMR-WB	9 معدّلات تتراوح بين 6.60 كيلوبت في الثانية و23.85 كيلوبت في الثانية بمعدّل أخذ عينات يبلغ 16 كيلوهرتز	3GPP (‎.3gp)
	‫AAC LC/LTP	محتوى صوت أحادي/استيريو بأي مجموعة من معدلات نقل البيانات العادية التي تصل إلى 160 كيلوبت في الثانية ومعدّلات أخذ العينات التي تتراوح بين 8 و48 كيلوهرتز	‫3GPP (‎.3gp) وMPEG-4 (‎.mp4 و‎.m4a)
الصورة	JPEG	base+progressive		يجب أن تتضمّن جميع عمليات تنفيذ الأجهزة برامج ترميز لتنسيقات الصور هذه، لأنّ نظام التشغيل Android 2.3 يتضمّن واجهات برمجة تطبيقات يمكن للتطبيقات استخدامها ل إنشاء ملفات من هذه الأنواع آليًا.
الصورة	PNG
الفيديو	‫H.263		ملفات 3GPP (‎.3gp)	يجب أن تتضمّن عمليات تنفيذ الأجهزة التي تتضمّن أجهزة الكاميرا وتحدِّد إما `android.hardware.camera` أو `android.hardware.camera.front` برامج ترميز لتنسيقات الفيديو هذه.

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

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

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

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

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

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

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

لأغراض هذا القسم:

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

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

وقت استجابة الإخراج على البارد بمقدار 100 ملي ثانية أو أقل
وقت استجابة الإخراج المُعدّ مسبقًا يبلغ 10 ملي ثانية أو أقل
وقت استجابة مستمر للإخراج يبلغ 45 ملي ثانية أو أقل
وقت استجابة إدخال على البارد يبلغ 100 ملي ثانية أو أقل
وقت استجابة إدخال مستمر يبلغ 50 ملي ثانية أو أقل

إذا كان تطبيق الجهاز يستوفي متطلبات هذا القسم، قد يُبلغ عن توفّر ميزة الصوت المنخفض الاستجابة من خلال الإبلاغ عن الميزة "android.hardware.audio.low-latency" عبر فئة android.content.pm.PackageManager. [Resources, 27] في المقابل، إذا لم يستوفِ تنفيذ الجهاز هذه المتطلبات، يجب عدم الإبلاغ عن توفُّر ميزة الصوت بوقت استجابة منخفض.

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

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

Android Debug Bridge (المعروف باسم adb) [Resources, 23]
يجب أن تتوافق عمليات تنفيذ الأجهزة مع جميع وظائف adb كما هو موضح في حزمة تطوير البرامج (SDK) لنظام التشغيل Android. من المفترض أن يكون خادم adb على الجهاز غير نشط تلقائيًا، ولكن يجب أن تتوفّر آلية يمكن للمستخدم من خلالها تفعيل "جسر تصحيح أخطاء Android".
خدمة Dalvik Debug Monitor (المعروفة باسم ddms) [الموارد، 23]
يجب أن تتيح عمليات تنفيذ الأجهزة جميع ميزات ddms كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android. بما أنّ ddms يستخدم adb، من المفترض أن يكون استخدام ddms غير مفعّل تلقائيًا، ولكن يجب أن يكون مفعّلاً عندما يفعّل المستخدم "جسر debugging" لنظام Android، كما هو موضّح أعلاه.
Monkey [Resources, 26]
يجب أن تتضمّن عمليات تنفيذ الأجهزة إطار عمل Monkey وأن تجعله متاحًا للتطبيقات لاستخدامه.

تتعرّف معظم الأنظمة المستندة إلى Linux وأنظمة Apple Macintosh على أجهزة Android باستخدام أدوات حزمة تطوير البرامج (SDK) العادية لنظام Android، بدون دعم إضافي، ولكن أنظمة Microsoft Windows تتطلّب عادةً برنامج تشغيل لأجهزة Android الجديدة. (على سبيل المثال، تتطلّب معرّفات المورّدين الجديدة ومعرّفات الأجهزة الجديدة أحيانًا برامج تشغيل USB مخصّصة لأنظمة التشغيل Windows). إذا لم تتعرّف أداة adb على عملية تنفيذ جهاز كما هو موضح في حزمة تطوير البرامج (SDK) العادية لنظام التشغيل Android ، على جهات تنفيذ الأجهزة توفير برامج تشغيل Windows التي تسمح للمطوّرين بالربط بالجهاز باستخدام بروتوكول adb. يجب توفير برامج التشغيل هذه لنظام التشغيل Windows XP وWindows Vista وWindows 7، بكل من إصدارَي 32 بت و64 بت.

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

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

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

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

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

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

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

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

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

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

يجب أن يكون حجم الشاشة على الأقل 6.35 سم (2.5 بوصة)
يجب أن تكون الكثافة 100 نقطة لكل بوصة على الأقل.
يجب أن تتراوح نسبة العرض إلى الارتفاع بين 1.333 (4:3) و1.779 (16:9).
تكنولوجيا العرض المستخدَمة تتألف من وحدات بكسل مربّعة

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

يتم تعريف الوحدات المستخدَمة في المتطلبات أعلاه على النحو التالي:

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

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

7.1.2. مقاييس الشبكة الإعلانية

يجب أن تُبلغ عمليات تنفيذ الأجهزة عن قيم صحيحة لجميع مقاييس العرض المحدّدة في android.util.DisplayMetrics [الموارد، 29].

7.1.3. التوافق مع الشاشة المعلَن عنه

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

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

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

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

7.1.5. ميزة "تسريع الرسومات الثلاثية الأبعاد"

يجب أن تكون عمليات تنفيذ الأجهزة متوافقة مع OpenGL ES 1.0، على النحو المطلوب من واجهات برمجة التطبيقات Android 2.3. بالنسبة إلى الأجهزة التي لا تتضمّن أجهزة تسريع ثلاثي الأبعاد، يقدّم مشروع Android Open-Source (المشروع المفتوح المصدر) برمجيًا تنفيذًا لـ OpenGL ES 1.0. يجب أن تكون آليات التنفيذ على الأجهزة متوافقة مع OpenGL ES 2.0.

يجوز لعمليات التنفيذ حذف معلومات التوافق مع Open GL ES 2.0، ولكن في حال حذفها، يجب ألا تُبلغ عمليات التنفيذ على الجهاز بأنّه متوافق مع OpenGL ES 2.0. على وجه التحديد، إذا كانت عمليات تنفيذ الأجهزة لا تتيح استخدام OpenGL ES 2.0:

واجهات برمجة التطبيقات المُدارة (مثلاً من خلال طريقة GLES10.getString()) يجب ألّا تُبلغ عن توفّر OpenGL ES 2.0
يجب ألّا تُبلغ واجهات برمجة تطبيقات OpenGL الأصلية المكتوبة بلغة C أو C++ (أي تلك المتاحة للتطبيقات من خلال libGLES_v1CM.so أو libGLES_v2.so أو libEGL.so) عن توافقها مع OpenGL ES 2.0.

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

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

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

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

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

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

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

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

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

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

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

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

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

يجب أن يكون الجهاز مزوّدًا بشاشة تعمل باللمس.
قد تحتوي على شاشة تعمل باللمس تستخدم إما أسلوب التكثيف أو المقاومة
يجب أن يتم إدخال قيمة android.content.res.Configuration [Resources, 30] التي تشير إلى نوع الشاشة التي تعمل باللمس على الجهاز.
يجب أن يتيح استخدام مؤشرات يتم تتبُّعها بشكل مستقل تمامًا، إذا كانت الشاشة تعمل باللمس تتيح استخدام مؤشرات متعددة.

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

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

يجب الإبلاغ بدقة عن توفّر أدوات الاستشعار أو عدم توفّرها وفقًا لفئة android.content.pm.PackageManager. [Resources, 27]
يجب أن يعرض التطبيق قائمة دقيقة بأجهزة الاستشعار المتوافقة من خلال ‎ SensorManager.getSensorList() وطرق مشابهة.
يجب أن تعمل بشكل معقول مع جميع واجهات برمجة التطبيقات الأخرى لأدوات الاستشعار (على سبيل المثال، من خلال عرض true أو false حسب الاقتضاء عندما تحاول التطبيقات تسجيل المستمعين، وعدم استدعاء مستمعي أدوات الاستشعار عندما لا تكون أدوات الاستشعار المقابلة متوفّرة، وما إلى ذلك)

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

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

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

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

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

يجب أن يكون الجهاز قادرًا على إرسال الأحداث بمعدّل 50 هرتز أو أكثر.
يجب أن تكون متوافقة مع نظام إحداثيات أجهزة استشعار Android كما هو موضّح بالتفصيل في واجهات برمجة تطبيقات Android (راجِع [الموارد، 31])
يجب أن يكون قادرًا على القياس من السقوط الحر إلى ضعف قوة الجاذبية (2g) أو أكثر على أيّ خطّ متّجه ثلاثي الأبعاد.
يجب أن تكون دقة القياس 8 بت أو أكثر.
يجب أن يكون الانحراف المعياري لا يزيد عن 0.05 متر/ثانية^2

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

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

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

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

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

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

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

يجب أن يكون الجهاز قادرًا على قياس تغييرات الاتجاه بما يصل إلى 5.5*Pi راديان في الثانية (أي 1,000 درجة في الثانية تقريبًا).
يجب أن يكون بإمكانه إرسال الأحداث بمعدّل 100 هرتز أو أكثر.
يجب أن تكون دقة القياس 8 بت أو أكثر.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.4.2. IEEE 802.11 (WiFi)

يجب أن تتضمّن عمليات تنفيذ أجهزة Android 2.3 إمكانية استخدام شكل واحد أو أكثر من 802.11 (b/g/a/n وما إلى ذلك). إذا كان تنفيذ الجهاز يتضمّن توافقًا مع 802.11، يجب أن ينفِّذ واجهة برمجة التطبيقات Android API المقابلة.

7.4.3. البلوتوث

يجب أن تتضمّن عمليات تنفيذ الأجهزة جهاز إرسال واستقبال بلوتوث. في عمليات تنفيذ التطبيقات التي تتضمّن جهاز إرسال واستقبال بلوتوث، يجب تفعيل واجهة برمجة التطبيقات Bluetooth API المستندة إلى RFCOMM كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) [الموارد، 32]. يجب أن تُنفِّذ عمليات تنفيذ الأجهزة ملفات تعريف البلوتوث ذات الصلة، مثل A2DP وAVRCP وOBEX وما إلى ذلك، على النحو المناسب للجهاز.

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

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

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

يجب الإبلاغ عن ميزة android.hardware.nfc من الطريقة android.content.pm.PackageManager.hasSystemFeature(). [Resources, 27]

يجب أن يكون الجهاز قادرًا على قراءة رسائل NDEF وكتابتها من خلال معايير NFC التالية:

يجب أن يكون الجهاز قادرًا على العمل كقارئ/كاتب في NFC Forum (على النحو المحدّد في المواصفة الفنية لـ NFC Forum NFCForum-TS-DigitalProtocol-1.0) من خلال معايير NFC التالية:
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NfcF (JIS 6319-4)
- NfcV (المعيار الدولي 15693)
- IsoDep (ISO 14443-4)
- أنواع علامات NFC Forum‏ 1 و2 و3 و4 (حدّدها NFC Forum)
يجب أن تكون قادرة على نقل البيانات واستلامها من خلال المعايير والبروتوكولات التالية للاتصال المباشر بين الأجهزة:
- ISO 18092
- LLCP 1.0 (حدّده NFC Forum)
- SDP 1.0 (حدّده NFC Forum)
- بروتوكول إرسال البيانات غير القابلة للتغيير (NDEF) [الموارد، 33]
يجب البحث عن جميع التقنيات المتوافقة أثناء تفعيل وضع رصد NFC.
يجب أن يكون الجهاز في وضع رصد تقنية NFC عندما يكون مفعّلاً وشاشة العرض نشطة.

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

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

MIFARE Classic (NXP MF1S503x [Resources, 34]، MF1S703x [Resources, 35])
MIFARE Ultralight (NXP MF0ICU1 [Resources, 36]، MF0ICU2 [Resources, 37])
NDEF على MIFARE Classic (NXP AN130511 [Resources, 38]، AN130411 [Resources, 39])

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

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

إذا كان تنفيذ الجهاز لا يتضمّن أجهزة NFC، يجب عدم الإعلان عن ميزة android.hardware.nfc من خلال الأسلوب android.content.pm.PackageManager.hasSystemFeature() [Resources, 27]، ويجب تنفيذ واجهة برمجة التطبيقات NFC في Android 2.3 كإجراء لا يؤدي إلى أيّ إجراء.

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

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

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

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

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

7.5. الكاميرات

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

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

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

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

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

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

يجب أن تكون دقة الشاشة VGA على الأقل (أي 640×480 بكسل).
يجب عدم استخدام الكاميرا الأمامية كإعداد تلقائي لواجهة برمجة التطبيقات Camera API. وهذا يعني أنّ واجهة برمجة تطبيقات الكاميرا في Android 2.3 تتيح استخدام كاميرات الالتقاط الأمامي، ويجب ألا تضبط عمليات تنفيذ الأجهزة واجهة برمجة التطبيقات لمعالجة كاميرا الالتقاط الأمامي على أنّها الكاميرا الخلفية التلقائية، حتى إذا كانت كاميرا الالتقاط الأمامي هي كاميرا الجهاز الوحيدة.
قد تتضمّن ميزات (مثل التركيز التلقائي والفلاش وما إلى ذلك) متوفّرة للكاميرات الخلفية كما هو موضّح في القسم 7.5.1.
يجب أن يعكس التطبيق البث المعروض في ملف CameraPreview أفقيًا (أي يعكسه) على النحو التالي:

إذا كان من الممكن أن يغيّر المستخدم اتجاه الجهاز (مثل تلقائيًا من خلال مقياس التسارع أو يدويًا من خلال إدخال المستخدم)، يجب أن تتم عكس معاينة الكاميرا أفقيًا بالنسبة إلى اتجاه الجهاز الحالي.
إذا طلب التطبيق الحالي صراحةً تدوير شاشة الكاميرا من خلال طلب إلى الأسلوب android.hardware.Camera.setDisplayOrientation() [Resources, 40]، يجب أن تتم إمالة معاينة الكاميرا أفقيًا بالنسبة إلى الاتجاه الذي حدّده التطبيق.
بخلاف ذلك، يجب أن تكون المعاينة مُعكوسة على طول المحور الأفقي التلقائي للجهاز.

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

7.5.3. سلوك Camera API

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

إذا لم يسبق للتطبيق استدعاء ‎varied.hardware.Camera.Parameters.setPreviewFormat(int)، يجب أن يستخدم الجهاز ‎varied.hardware.PixelFormat.YCbCr_420_SP لبيانات المعاينة المقدَّمة إلى ‎varied.application.callbacks.
إذا سجّل تطبيق مثيلًا من android.hardware.Camera.PreviewCallback وطلب النظام طريقة onPreviewFrame() عندما يكون تنسيق المعاينة هو YCbCr_420_SP، يجب أن تكون البيانات في صفيف البايتات التي تم تمريرها إلى onPreviewFrame() بالإضافة إلى ذلك بتنسيق ترميز NV21. وهذا يعني أنّه يجب أن يكون NV21 هو الإعداد التلقائي.
يجب أن تتيح عمليات تنفيذ الأجهزة استخدام تنسيق YV12 (كما هو موضّح في الثابت android.graphics.ImageFormat.YV12) لمعاينات الكاميرا للكاميرات الأمامية والخلفية. يُرجى العلم أنّه من المخطّط تغيير هذا الشرط إلى "يجب" في تعريف التوافق لإصدار مستقبلي. وهذا يعني أنّ استخدام YV12 اختياري في Android 2.3، ولكن سيكون مطلوبًا في إصدار مستقبلي. بالنسبة إلى الأجهزة الحالية والجديدة التي تعمل بالإصدار 2.3 من Android، ننصح بشدة باستيفاء هذا الشرط في الإصدار 2.3 من Android، وإلا لن تتمكّن من التوافق مع Android عند الترقية إلى الإصدار المستقبلي.

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

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

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

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

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

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

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

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

يجب أن تتضمّن عمليات تنفيذ الأجهزة مساحة تخزين غير متقلبة تبلغ 150 ميغابايت على الأقل تتوفّر لبيانات المستخدمين. وهذا يعني أنّه يجب أن يكون حجم القسم /data 150 ميغابايت على الأقل.

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

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

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

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

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

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

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

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

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

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

7.7. USB

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

يجب تنفيذ برنامج تشغيل USB لعميل يمكن توصيله بمضيف USB باستخدام منفذ UME-A عادي.
يجب تنفيذ أداة Android Debug Bridge عبر USB (كما هو موضّح في القسم 7).
يجب تنفيذ مواصفات "التخزين الكبير السعة عبر USB" للسماح للمضيف المتصل بالجهاز بالوصول إلى محتوى وحدة التخزين /sdcard.
يجب استخدام شكل موصل USB صغير على جانب الجهاز.
يجوز تضمين منفذ غير عادي على جانب الجهاز، ولكن في هذه الحالة يجب أن يتم شحنه مع كابل يمكنه توصيل دبوس الإخراج المخصّص بمنفذ USB-A العادي.

8. التوافق مع الأداء

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

المقياس	الحدّ الأدنى للأداء	التعليقات
وقت بدء تشغيل التطبيق	من المفترض أن يتم تشغيل التطبيقات التالية في غضون الوقت المحدّد. المتصفّح: أقل من 1300 ملي ثانية رسائل الوسائط المتعددة/الرسائل القصيرة: أقل من 700 مللي ثانية AlarmClock: أقل من 650 ملي ثانية	يتم قياس وقت الإطلاق على أنّه إجمالي الوقت الذي يستغرقه اكتمال تحميل النشاط التلقائي للتطبيق، بما في ذلك الوقت الذي يستغرقه بدء عملية Linux وتحميل حزمة Android في بيئة التشغيل الافتراضية Dalvik وتشغيل onCreate.
التطبيقات المتزامنة	عند تشغيل تطبيقات متعددة، يجب أن يستغرق إعادة تشغيل أحد التطبيقات التي كانت تعمل في السابق وقتًا أقل من وقت التشغيل الأصلي.

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

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

9.1. الأذونات

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

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

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

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

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

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

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

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

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

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

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

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

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

10.2. أداة إثبات ملكية CTS

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

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

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

10.3. التطبيقات المرجعية

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

تطبيقات "تطبيقات Android" [الموارد، 43]
Replica Island (متاح في Android Market، مطلوب فقط لعمليات تكامل الأجهزة المتوافقة مع OpenGL ES 2.0)

يجب أن يتم تشغيل كل تطبيق من التطبيقات المذكورة أعلاه وأن يعمل بشكل صحيح عند التنفيذ، لكي يتم اعتبار التنفيذ متوافقًا.

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

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

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

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

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

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

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

يمكنك التواصل مع مؤلفي المستند على العنوان compatibility@android.com للحصول على توضيحات وطرح أي مشاكل تعتقد أنّ المستند لا يتناولها.

الملحق أ: إجراء اختبار البلوتوث

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

يستند إجراء الاختبار إلى تطبيق BluetoothChat النموذجي المُدرَج في ملف شجيرة مشروع Android المفتوح المصدر. تتطلّب العملية استخدام جهازَين:

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

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

الإعداد والتركيب

أنشئ حزمة BluetoothChat.apk من خلال "إنشاء عيّنات" من شجرة رمز مصدر Android.
ثبِّت حزمة BluetoothChat.apk على الجهاز الذي يعمل بشكل سليم.
ثبِّت حزمة BluetoothChat.apk على الجهاز المعني.

اختبار ميزة "التحكّم في البلوتوث من خلال التطبيقات"

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

اختبار الإقران والاتصال

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

اختبار الإقران والاتصال في الاتجاه المعاكس

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

إعادة إطلاق الاختبار

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

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

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

جدول المحتويات

‫1. مقدّمة

‫2- المراجع

3- البرامج

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

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

3.2.1. الأذونات

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

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

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

3.2.3.2. عمليات إلغاء النية

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

3.2.3.4. نوايا البث

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

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

3.4.1. توافق WebView

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

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

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

3.7 توافق الآلة الافتراضية

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

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

3.8.2. الإشعارات

3.8.3. البحث

3.8.4. النخب

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

‫4- توافق حِزم التطبيقات

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

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

5.1.1. برامج فك ترميز الوسائط

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

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

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

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

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

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

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

7.1.2. مقاييس الشبكة الإعلانية

7.1.3. التوافق مع الشاشة المعلَن عنه

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

7.1.5. ميزة "تسريع الرسومات الثلاثية الأبعاد"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.4.2. IEEE 802.11 (WiFi)

7.4.3. البلوتوث

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

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

7.5. الكاميرات

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

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

7.5.3. سلوك Camera API

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

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

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

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

7.7. USB

8. التوافق مع الأداء

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

9.1. الأذونات

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

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

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

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

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

10.2. أداة إثبات ملكية CTS

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