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

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

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

تعريف التوافق مع Android 4.1
المراجعة 3
تاريخ التعديل الأخير: 24 حزيران (يونيو) 2013
حقوق الطبع والنشر © 2012، Google Inc. جميع الحقوق محفوظة.
compatibility@android.com
جدول المحتويات
1. المقدّمة
2- الموارد
3- البرامج
3.1. توافقواجهة برمجة التطبيقات المُدارة
3.2. توافق واجهة برمجة التطبيقات
3.2.1. الأذونات
3.2.2. إنشاء المعلَمات
3.2.3. توافق النوايا
3.2.3.1. Intentsالأساسية للتطبيق
3.2.3.2. Intent Overrides
3.2.3.3. مساحات أسماء Intent
3.2.3.4. Broadcast Intents
3.3. توافق واجهات برمجة التطبيقات الأصلية
3.3.1 واجهات التطبيقات الثنائية
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. المظاهر
3.8.6. Live Wal papers
3.8.7. أحدث إصدارلتطبيق Display
3.8.8. إعدادات إدارة الإدخال
3.8.9. Lock Screen Remote Control (التحكم عن بُعد في شاشة القفل)
3.9 Device Administration (إدارة الجهاز)
3.10 Accessibility (تسهيل الاستخدام)
3.11 Text-to-Speech (تحويل النص إلى كلام)
4. توافق حزمة التطبيق
5- التوافق مع الوسائط المتعددة
5.1. برامج ترميز الوسائط
5.2. ترميز الفيديو
5.3. التسجيل الصوتي
5.4. وقت استجابة الصوت
5.5 بروتوكولات الشبكة
6- توافق أدوات المطوّرين
7. توافق الأجهزة
7.1. الشاشة والرسومات
7.1.1. إعدادات الشاشةعلى
7.1.2. مقاييس الشبكة الإعلانية
7.1.3. اتجاه الشاشة
7.1.4. تسريع الرسومات ثنائية الأبعاد والثلاثية الأبعاد
7 .1.5. وضع التوافق للتطبيقات القديمة
7.1.6. أنواع الشاشة
7.1.7. تكنولوجيا الشاشة
7.2. فيالأجهزة
7.2.1. لوحة المفاتيح
7.2.2. التنقّل بدون لمس
7.2.3. مفاتيح التنقّل
7.2.4. إدخال الشاشة التي تعمل باللمس
7.2.5. إدخال باللمس مزوَّر
7.2.6. الميكروفون
7.3. أجهزة الاستشعار
7.3.1. مقياس التسارع

7.3.1. مقياس التسارع
7.3.2. مقياس المغناطيسية
7.3.3. نظام تحديد المواقع العالمي (GPS)
7.3.4. Gyroscope
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.2.1. Wi-Fi Direct
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 Verifier
10.3. التطبيقات المرجعية
11. البرامج القابلة للتحديث
12. التواصل معنا
الملحق (أ) - إجراءات اختبار البلوتوث

1- مقدّمة
يسرد هذا المستند المتطلبات التي يجب استيفاؤها لكي تكون الأجهزة
متوافقة مع Android 4.1.
يتم استخدام "يجب" و"يجب عدم" و"مطلوب" و"يجب " و"يجب  عدم" و"يجب" و"يجب عدم"
"مُستحسَن" و"يجوز" و "اختياري" وفقًا لمعيار IETF المحدَّد في RFC2119
[الموارد، 1].
وفقًا للاستخدام في هذا المستند، يشير مصطلح "منفذ الجهاز" أو "منفذ" إلى شخص أو
مؤسسة تطوّر حلّاً للأجهزة/البرامج يعمل بنظام Android 4.1. "تنفيذ
الجهاز" أو "التنفيذ" هو الحلّ للأجهزة/البرامج الذي تم تطويره.
لكي يكون التطبيق متوافقًا مع Android 4.1، يجب أن تستوفي عمليات تنفيذ التطبيق
المتطلبات الموضّحة في تعريف التوافق هذا، بما في ذلك أي مستندات
تم دمجها من خلال الإشارة.
في حال عدم توفّر أي معلومات أو في حال عدم وضوح أو اكتمال هذا التعريف أو اختبارات البرامج الموضّحة في الفقرة 10، تقع مسؤولية ضمان
التوافق مع عمليات التنفيذ الحالية على عاتق مطوّرالجهاز.

لهذا السبب، يُعدّ "المشروع المفتوح المصدر لنظام Android" [المراجع، 3] الإصدار المرجعي
والإصدار المفضّل من Android. ننصحبشدة
مطوّري الأجهزة باستناد عمليات التنفيذ إلى أكبر قدر ممكن من
الرمز المصدر "الأساسي" المتاح من "المشروع المفتوح المصدر لنظام Android". على الرغم من أنّه يمكن نظريًا استبدال بعض
المكوّنات بعمليات تنفيذ بديلة، لا ننصح بهذه
الممارسة بشدة، لأنّ اجتياز اختبارات البرامج سيصبح أكثر
صعوبة. تقع على عاتق منفذ التطبيق مسؤولية ضمان التوافق السلوكي الكامل مع الإصدار العادي من Android، بما في ذلك وغير ذلك
مجموعة اختبار التوافق.
أخيرًا، يُرجى العِلم أنّ هذا المستند يحظر بوضوح بعض عمليات استبدال المكونات و
التعديلات.
2- الموارد
1-  مستويات متطلبات RFC2119 من IETF: http://www.ietf.org/rfc/rfc2119.txt
2-  نظرة عامة حول برنامج التوافق مع Android:
http://source.android.com/compatibility/index.html
3.  مشروع Android المفتوح المصدر: http://source.android.com/
4-  تعريفات واجهة برمجة التطبيقات ومستنداتها:
http://developer.android.com/reference/packages.html
5-  مرجع أذونات Android:
http://developer.android.com/reference/android/Manifest.permission.html
6.  مرجع android.os.Build:
http://developer.android.com/reference/android/os/Build.html
7-  سلسلات الإصدارات المطلوبة لنظام Android 4.1:
http://source.android.com/compatibility/4.1/versions.html
8.  Renderscript:
http://developer.android.com/guide/topics/graphics/renderscript.html
9.  تسريع الأجهزة:
http://developer.android.com/guide/topics/graphics/hardware-accel.html
10.  فئة android.webkit.WebView:
http://developer.android.com/reference/android/webkit/WebView.html
11.  HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
12.  إمكانات HTML5 بلا إنترنت: http://dev.w3.org/html5/spec/Overview.html#offline
13.  علامة فيديو HTML5: http://dev.w3.org/html5/spec/Overview.html#video
14.  HTML5/W3C geolocation API: http://www.w3.org/TR/geolocation-API/
15.  HTML5/W3C webdatabase API: http://www.w3.org/TR/webdatabase/
16.  HTML5/W3C IndexedDB API: http://www.w3.org/TR/IndexedDB/
17.  مواصفات آلة Dalvik الافتراضية: متوفّرة في رمز مصدر Android، على
dalvik/docs
18.  تطبيقات التطبيقات المصغّرة:
http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
19.  الإشعارات:
http://developer.android.com/guide/topics/ui/notifiers/notifications.html
20.  مراجع التطبيق: http://code.google.com/android/reference/available-
resources.html
21.  دليل نمط رمز شريط الحالة:
http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html
22.  Search Manager:
http://developer.android.com/reference/android/app/SearchManager.html
23.  الرسائل المنبثقة: http://developer.android.com/reference/android/widget/Toast.html
24.  المظاهر: http://developer.android.com/guide/topics/ui/themes.html

25.  فئة R.style: http://developer.android.com/reference/android/R.style.html
26.  خلفيات Wal المتغيّرة: http://developer.android.com/resources/articles/live-
wal papers.html
27.  إدارة أجهزة Android:
http://developer.android.com/guide/topics/admin/device-admin.html
28.  فئة android.app.admin.DevicePolicyManager:
http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html
29.  واجهات برمجة التطبيقات لـ Android Accessibility Service:
http://developer.android.com/reference/android/accessibilityservice/package-
summary.html
30.  واجهات برمجة التطبيقات للتسهيل الاستخدام في Android:
http://developer.android.com/reference/android/view/accessibility/package-
summary.html
31.  مشروع Eyes Free: http://code.google.com/p/eyes-free
32.  واجهات برمجة التطبيقات لتحويل النص إلى كلام:
http://developer.android.com/reference/android/speech/tts/package-
summary.html
33.  مستندات الأدوات المرجعية (لـ adb وaapt وddms):
http://developer.android.com/guide/developing/tools/index.html
34.  وصف ملف apk لنظام Android:
http://developer.android.com/guide/topics/fundamentals.html
35.  ملفات البيان: http://developer.android.com/guide/topics/manifest/manifest-
intro.html
36.  أداة اختبار Monkey:
https://developer.android.com/studio/test/other-testing-tools/monkey
37.  فئة android.content.pm.PackageManager وميزات الأجهزة
في Android:
http://developer.android.com/reference/android/content/pm/PackageManager.html
38.  إتاحة استخدام شاشات متعدّدة:
http://developer.android.com/guide/practices/screens_support.html
39.  android.util.DisplayMetrics:
http://developer.android.com/reference/android/util/DisplayMetrics.html
40.  android.content.res.Configuration:
http://developer.android.com/reference/android/content/res/Configuration.html
41.  android.hardware.SensorEvent:
http://developer.android.com/reference/android/hardware/SensorEvent.html
42.  واجهة برمجة التطبيقات للبلوتوث:
http://developer.android.com/reference/android/bluetooth/package-summary.html
43.  بروتوكول دفع NDEF: http://source.android.com/compatibility/ndef-push-
protocol.pdf
44.  MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
45.  MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
46.  MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
47.  MIFARE MF0ICU2:
http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
48.  MIFARE AN130511:
http://www.nxp.com/documents/application_note/AN130511.pdf
49.  MIFARE AN130411:
http://www.nxp.com/documents/application_note/AN130411.pdf
50.  Camera orientation API:
http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
51.  android.hardware.Camera:
http://developer.android.com/reference/android/hardware/Camera.html
52.  ملحقات Android المفتوحة:
http://developer.android.com/guide/topics/usb/accessory.html
53.  USB Host API: http://developer.android.com/guide/topics/usb/host.html
54.  مرجع أمان Android والأذونات:
http://developer.android.com/guide/topics/security/security.html
55.  تطبيقات Android: http://code.google.com/p/apps-for-android
56.  فئة android.app.DownloadManager:
http://developer.android.com/reference/android/app/DownloadManager.html
57.  Android File Transfer: http://www.android.com/filetransfer
58.  تنسيقات الوسائط في Android: http://developer.android.com/guide/appendix/media-
formats.html
59.  بروتوكول Draft لبث الوسائط عبر بروتوكول HTTP: http://tools.ietf.org/html/draft-pantos-http-
live-streaming-03
60.  NFC Connection Handover: http://www.nfc-
forum.org/specs/spec_list/#conn_handover
61.  الاقتران الآمن والبسيط عبر البلوتوث باستخدام NFC: http://www.nfc-
forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf
62.  Wifi Multicast API:
http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html

63.  Action Assist:
http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST
64.  مواصفات الشحن عبر USB:
http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf
65.  Android Beam: http://developer.android.com/guide/topics/nfc/nfc.html
66.  مكبّر صوت USB في Android:
http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO
67.  إعدادات المشاركة عبر NFC في Android:
http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS
68.  Wifi Direct (Wifi P2P):
http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html
69.  Media Remote Control Client:
http://developer.android.com/reference/android/media/RemoteControlClient.html
70.  Motion Event API:
http://developer.android.com/reference/android/view/MotionEvent.html
71.  إعدادات إدخال اللمس: http://source.android.com/tech/input/touch-
devices.html
تم استخراج العديد من هذه المراجع بشكل مباشر أو غير مباشر من حزمة SDK لنظام Android 4.1،
و ستتطابق وظيفيًا مع المعلومات الواردة في مستندات حزمة SDK. في أيّ
حالات يتعارض فيها تعريف التوافق هذا أو مجموعة أدوات اختبار التوافق مع
مستندات حزمة SDK، تُعتبَر مستندات حزمة SDK هي المرجعية. أي
تفاصيل فنية مقدَّمة في المراجع المضمّنة أعلاه تُعتبر من خلال
التضمين جزءًا من تعريف التوافق هذا.
3- البرامج
3.1. توافق واجهات برمجة التطبيقات المُدارة
بيئة التنفيذ المُدارة (المستندة إلى Dalvik) هي الوسيط الأساسي لتطبيقات Android
. واجهة برمجة تطبيقات Android هي مجموعة من
واجهات نظام Android المكشوفة للتطبيقات التي تُشغَّل في بيئة الأجهزة الافتراضية المُدارة
. يجب أن توفّر عمليات التنفيذ على الأجهزة عمليات تنفيذ كاملة،
بما في ذلك جميع السلوكيات الموثَّقة لأي واجهة برمجة تطبيقات موثَّقة تعرضها حزمة تطوير البرامج (SDK) لنظام Android
4.1 [المراجع، 4].
يجب ألا تحذف عمليات تنفيذ التطبيقات على الأجهزةأي واجهات برمجة تطبيقات مُدارة أو تُغيّر واجهات برمجة التطبيقات أو
التوقيعات أو تخرج عن السلوك المُسجّل أو تُدرِج عمليات لا تؤدي إلى أي نتيجة، إلا في الحالات التي يسمح بها
تحديدًا هذا التعريف للتوافق.
يسمح تعريف التوافق هذا بحذف بعض أنواع الأجهزة التي يتضمن Android
واجهات برمجة التطبيقات من خلال عمليات تنفيذ الأجهزة. في مثل هذه الحالات، يجب
أن تظل واجهات برمجة التطبيقات متوفّرة وتتصرّف بطريقة معقولة. اطّلِع على الفقرة 7 لمعرفة
المتطلبات المحددة لهذا السيناريو.
3.2. توافق واجهات برمجة التطبيقات "غير الحاسمة"
بالإضافة إلى واجهات برمجة التطبيقات المُدارة من القسم 3.1، يشتمل Android أيضًا على واجهة برمجة تطبيقات "غير حاسمة" مُهمّة
في وقت التشغيل فقط، على شكل عناصر مثل Intents والأذونات و
العناصر المشابهة لتطبيقات Android التي لا يمكن فرضها في وقت تجميع التطبيق
.
3.2.1. الأذونات
يجب أن توفّر جهات تنفيذ التطبيقات جميع الثوابت للأذونات وتعمل على فرضها على النحو
الموضّح في صفحة مرجع الأذونات [المراجع، 5]. يُرجى العِلم أنّ القسم 10
يسرد متطلبات إضافية متعلّقة بنموذج أمان Android.
3.2.2. مَعلمات الإصدار
تتضمّن واجهات برمجة تطبيقات Android عددًا من الثوابت في فئة android.os.Build
[Resources, 6] المخصّصة لوصف الجهاز الحالي. لتوفير قيم متسقة
ومفيدة في جميع عمليات تنفيذ الأجهزة، يتضمّن الجدول أدناه
قيودًا إضافية على تنسيقات هذه القيم التي يجب أن تلتزم بها عمليات تنفيذ الأجهزة
.
المَعلمة
التعليقات
يشير هذا الحقل إلى إصدار نظام Android الذي يتم تنفيذه حاليًا، بتنسيق يمكن لشخص عادي قراءته. يجب أن يحتوي هذا الحقل على
android.os.Build.VERSION.RELEASE
من قيم السلسلة المحدّدة في [Resources, 7].
يشير هذا المَعلمة إلى إصدار نظام Android الذي يتم تنفيذه حاليًا، بتنسيق يمكن لرمز التطبيق التابعة لجهة خارجية الوصول إليه.
android.os.Build.VERSION.SDK
بالنسبة إلى Android 4.1، يجب أن يحتوي هذا المَعلمة على القيمة الصحيحة 16.

إصدار نظام التشغيل Android الذي يتم تنفيذه حاليًا، بتنسيق يمكن لرمز التطبيق التابع لجهة خارجية الوصول إليه
android.os.Build.VERSION.SDK_INT
بالنسبة إلى Android 4.1، يجب أن يحتوي هذا الحقل على القيمة الصحيحة 16.
قيمة يختارها منفذ الجهاز لتحديد الإصدار المحدد من نظام Android
الذي يتم تنفيذه حاليًا، بتنسيق يسهل قراءته. يجب عدم إعادة استخدام هذه القيمة لإصدارات مختلفة تتوفّر لـ
android.os.Build.VERSION.INCREMENTAL
المستخدمين النهائيين. ومن الاستخدامات الشائعة لهذا الحقل الإشارة إلى رقم الإصدار أو معرّف تغيير نظام إدارة المصدر الذي
تم استخدامه لإنشاء الإصدار. لا توجد متطلبات محددة لتنسيق هذا الحقل، باستثناء أنّه يجب
ألا يكون قيمة فارغة أو سلسلة فارغة ("").
قيمة يختارها منفذ الجهاز لتحديد الأجهزة الداخلية المحددة التي يستخدمها الجهاز، ب
تنسيق يسهل قراءته من الاستخدامات المحتمَلة لهذا الحقل الإشارة إلى الإصدار المحدّد لللوحة التي تشغّل
android.os.Build.BOARD
الجهاز. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCI بسعة 7 بت وتتطابق مع التعبير العادي
"^[a-zA-Z0-9.,_-]+$".
قيمة يختارها منفذ الجهاز لتحديد اسم الشركة أو المؤسسة أو الشخص أو غيرهم
الذين أنتجوا الجهاز، بتنسيق يسهل قراءته من الاستخدامات المحتمَلة لهذا الحقل الإشارة إلى المصنع الأصلي
android.os.Build.BRAND
و/أو شركة الاتصال التي باعت الجهاز. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCI بسعة 7 بت وأن تطابق
التعبير العادي "^[a-zA-Z0-9.,_-]+$".
اسم مجموعة التعليمات (نوع وحدة المعالجة المركزية + اتفاقية ABI) للترميز التلقائي. راجِع الفقرة 3.3: توافق واجهة برمجة التطبيقات المضمّنة
android.os.Build.CPU_ABI
.
اسم مجموعة التعليمات الثانية (نوع وحدة المعالجة المركزية + اتفاقية ABI) للرمز البرمجي الأصلي راجِع القسم 3.3: التوافق مع
android.os.Build.CPU_ABI2
API البرمجي.
قيمة يختارها مُنفِّذ الجهاز لتحديد الإعداد أو الإصدار المحدد للجسم
android.os.Build.DEVICE
(يُشار إلى هذا الاسم أحيانًا بـ "التصميم الصناعي") للجهاز. يجب أن تكون قيمة هذا الحقل قابلة للترميز باستخدام
ASCI بسعة 7 بت وتتطابق مع التعبير العادي "^[a-zA-Z0-9.,_-]+$".
سلسلة تُعرّف هذه الإصدارة بشكل فريد ويجب أن يكون مفهومًا للبشر بدرجة معقولة. ويجب أن يتّبع هذا
النمط:
$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
على سبيل المثال:
android.os.Build.FINGERPRINT
acme/mydevice/generic:4.1/JRN53/3359:userdebug/test-keys
يجب ألا يتضمّن معرف الجهاز أحرف مسافات بيضاء. إذا تضمّنت الحقول الأخرى المضمّنة في النموذج أعلاه
أحرف مسافات بيضاء، يجب استبدالها في بصمة الإصدار بحرف آخر، مثل
الشرطة السفلية ("_"). يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCI بسعة 7 بت.
اسم الأجهزة (من سطر أوامر النواة أو /proc) يجب أن يكون
android.os.Build.HARDWARE
مفهومًا بشكل معقول للمستخدمين. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCI بسعة 7 بت وتتطابق مع التعبير العادي "^[a-
zA-Z0-9.,_-]+$".
سلسلة تُعرِّف بشكلٍ فريد المضيف الذي تم إنشاء الإصدار عليه، بتنسيق يمكن لشخص عادي قراءته لا تفرض
android.os.Build.HOST
متطلبات على التنسيق المحدد لهذا الحقل، باستثناء أنّه يجب ألا يكون قيمة فارغة أو سلسلة فارغة ("").
معرّف اختاره مُنفِّذ الجهاز للإشارة إلى إصدار معيّن، بتنسيق يمكن للشخص قراءته. يمكن أن يكون
هذا الحقل مطابقًا لـ android.os.Build.VERSION.INCREMENTAL، ولكن يجب أن يكون
android.os.Build.ID
ذا قيمة مفيدة للمستخدمين الأخيرين لتمييز إصدارات البرامج. يجب أن تكون قيمة هذا الحقل قابلة للترميز
بترميز ASCI بسعة 7 بت وأن تطابق التعبير العادي "^[a-zA-Z0-9.,_-]+$".
الاسم التجاري للمصنّع الأصلي للجهاز الذي ينتمي إليه المنتج. لا توجد متطلبات على
android.os.Build.MANUFACTURER
التنسيق المحدد لهذا الحقل، باستثناء أنّه يجب ألا يكون قيمة فارغة أو سلسلة فارغة ("").
قيمة يختارها مُنفِّذ الجهاز وتحتوي على اسم الجهاز على النحو المعروف للمستخدم الأخير. يجب أن يكون
android.os.Build.MODEL
هو الاسم نفسه الذي يتم تسويق الجهاز بموجبه وبيعه للمستخدمين النهائيين. لا توجد
متطلبات محددة لتنسيق هذا الحقل، باستثناء أنّه يجب ألا يكون قيمة فارغة أو سلسلة فارغة ("").
قيمة يختارها مطوّر الجهاز وتحتوي على اسم التطوير أو الاسم الرمزي للمنتج
android.os.Build.PRODUCT
(رمز التخزين التعريفي). يجب أن يكون مفهومًا للمستخدمين، ولكن لا يكون مقصودًا بالضرورة لعرضه على المستخدمين النهائيين. يجب أن تكون قيمة هذا
الحقل قابلة للترميز بترميز ASCI بسعة 7 بت وأن تطابق التعبير العادي "^[a-zA-Z0-9.,_-]+$".
الرقم التسلسلي للمعدات، إن توفّر. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCI بسعة 7 بت وأن تطابق
android.os.Build.SERIAL
التعبير العادي "^([a-zA-Z0-9]{0,20})$".
قائمة مفصولة بفاصلة للعلامات التي اختارها منفذ الجهاز لتوضيح الإصدار بدقة على سبيل المثال، "unsigned,debug" في
android.os.Build.TAGS
. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCI بسعة 7 بت وتتطابق مع
التعبير العادي "^[a-zA-Z0-9.,_-]+$".
android.os.Build.TIME
قيمة تمثّل الطابع الزمني لوقت إنشاء الإصدار
قيمة يختارها منفذ الجهاز تحدد إعدادات وقت التشغيل للإصدار. يجب أن يحتوي هذا الحقل
على إحدى القيم المتوافقة مع الإعدادات الثلاثة النموذجية لوقت تشغيل Android: "user"،
android.os.Build.TYPE
"userdebug"، أو "eng". يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCI بسعة 7 بت وأن تطابق
التعبير العادي "^[a-zA-Z0-9.,_-]+$".
اسم أو رقم تعريف مستخدم (أو مستخدم مبرمَج) أنشأ الإصدار لا توجد متطلبات على
android.os.Build.USER
التنسيق المحدد لهذا الحقل، باستثناء أنّه يجب ألا يكون قيمة فارغة أو سلسلة فارغة ("").
3.2.3. توافق Intent
يجب أن تلتزم عمليات تنفيذ التطبيقات بنظام Intent المرتبط بأجهزة Android على النحو

الموضّح في الأقسام أدناه. يُقصد بـ "الالتزام" أنّه على مطوّر التطبيق
توفير نشاط أو خدمة Android تحدّد فلتر أهداف مطابقًا و
ترتبط بالسلوك الصحيح وتنفّذه لكل نمط أهداف محدد.
3.2.3.1. Intents للتطبيقات الأساسية
يحدِّد مشروع Android upstream عددًا من التطبيقات الأساسية، مثل جهات الاتصال
والتقويم ومعرض الصور ومشغِّل الموسيقى وما إلى ذلك. يجوز لمُنفِّذِي الأجهزة استبدال
هذه التطبيقات بإصدارات بديلة.
ومع ذلك، يجب أن تلتزم أي إصدارات بديلة بأنماط Intent نفسها المتوفّرة
في المشروع الأساسي. على سبيل المثال، إذا كان الجهاز يحتوي على مشغّل موسيقى بديل،
يجب أن يحترم الجهاز نمط Intent الذي تصدره التطبيقات التابعة لجهات خارجية لاختيار أغنية.
تُعد التطبيقات التالية تطبيقات أساسية لنظام Android:
ساعة المكتب
المتصفّح
التقويم
جهات الاتصال
المعرض
البحث العمومي
المشغِّل
الموسيقى
الإعدادات
تتضمّن تطبيقات نظام Android الأساسية مكونات مختلفة لنشاط أو خدمة
تُعدّ "عامة". أي أنّ السمة "android:exported" قد لا تكون متوفّرة، أو
قد يكون لها القيمة "true".
بالنسبة إلى كل نشاط أو خدمة محدَّدَين في أحد تطبيقات نظام Android الأساسية التي لم يتم
وضع علامة "غير عام" عليهما من خلال السمة android:exported بالقيمة "false"، يجب أن تتضمن عمليات
تنفيذ التطبيق على الجهاز مكوّنًا من النوع نفسه ينفِّذ
أنماط فلتر الأهداف نفسها مثل تطبيق نظام Android الأساسي.
بمعنى آخر، يجوز أن تحلّ عمليات تنفيذ التطبيق على الجهاز مكان تطبيقات نظام Android الأساسية،
ولكن في هذه الحالة، يجب أن تتوافق عمليات تنفيذ التطبيق على الجهاز مع جميع أنماط الأهداف المحدَّدة
من خلال كل تطبيق نظام Android أساسي يتم استبداله.
3.2.3.2. إلغاء Intent
بما أنّ Android هو منصّة قابلة للتوسيع، يجب أن تسمح عمليات تنفيذ الأجهزة بإلغاء كل نمط Intent
المُشار إليه في الفقرة 3.2.3.2 من خلال تطبيقات تابعة لجهات خارجية. يسمح
الإصدار الأحدث من الإصدار المفتوح لنظام Android بهذا تلقائيًا، ويجب على
مطوّري التطبيقات عدم منح امتيازات خاصة لتطبيقات النظام لاستخدام
نماذج Intent هذه، أو منع التطبيقات التابعة لجهات خارجية من الربط بهذه النماذج واستخدامها.
ويشمل هذا الحظر تحديدًا ولكن ليس حصرًا
إيقاف واجهة مستخدم "أداة الاختيار" التي تسمح للمستخدم باختيار أحد
التطبيقات المتعددة التي تعالج نمط Intent نفسه.
ومع ذلك، قد توفّر عمليات تنفيذ الأجهزة أنشطة تلقائية لأشكال معيّنة من عناوين URL
(مثل http://play.google.com) إذا كان النشاط التلقائي يوفّر فلترًا أكثر تحديدًا
لعنوان URL البيانات. على سبيل المثال، فلتر النوايا الذي يحدّد معرّف المورد المطلق للبيانات
"http://www.android.com" يكون أكثر تحديدًا من فلتر المتصفّح لـ "http://". يجب أن توفّر عمليات تنفيذ التطبيقات على الأجهزة واجهة مستخدم للمستخدمين لتعديل النشاط التلقائي
للنوايا.

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

بالتغييرات في بيئة الأجهزة أو البرامج. يجب أن تبث الأجهزة المتوافقة مع Android
Intents البث العلني استجابةً لأحداث
النظام المناسبة. يتم وصف إشارات البث في مستندات حزمة تطوير البرامج (SDK).
3.3. توافق واجهات برمجة التطبيقات الأصلية
3.3.1 واجهات التطبيقات الثنائية
يمكن للرمز المُدار الذي يعمل في Dalvik التحويل إلى رمز برمجي أصلي مُقدَّم في ملف التطبيق
.apk كملف ELF ‎ .so من المجمَّع لبنية أجهزة الجهاز المعنية.
بما أنّ الرمز البرمجي الأصلي يعتمد بشكلٍ كبير على تكنولوجيا المعالج الأساسية، يحدِّد نظام Android
عددًا من واجهات التطبيقات الثنائية (ABIs) في مجموعة تطوير البرامج (NDK) لنظام Android، في الملف
docs/CPU-ARCH-ABIS.html. إذا كان تطبيق الجهاز متوافقًا مع واحد أو أكثر
من معرّفات ABI المحدّدة، يجب أن يتوافق مع مجموعة تطوير البرامج (NDK) لنظام Android، على النحو الموضّح أدناه.
إذا كان تطبيق الجهاز يتضمّن دعمًا لواجهة التطبيق الثنائية (ABI) لنظام Android، يجب أن:
يتضمّن دعمًا للرموز البرمجية التي تُشغّل في البيئة المُدارة لتحويلها إلى
رموز برمجية أصلية، باستخدام معاني واجهة Java البرمجية الأصلية (JNI)
يكون متوافقًا مع الرمز المصدر (أي متوافقًا مع الرأس) ومتوافقًا مع الثنائي (ل
واجهة التطبيق الثنائية) مع كل مكتبة مطلوب استخدامها في القائمة أدناه
يُبلِغ بدقة عن واجهة التطبيق الثنائية (ABI) الأصلية المتوافقة
مع الجهاز، من خلال واجهة برمجة التطبيقات android.os.Build.CPU_ABI
يُبلِغ فقط عن واجهات التطبيق الثنائية المُوثَّقة في أحدث إصدار من
مجموعة تطوير البرامج (NDK) لنظام Android، في الملف 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 (دعم الصوت OpenSL ES 1.0.1)
libOpenMAXAL.so (دعم OpenMAX AL 1.0.1)
libandroid.so (دعم نشاط Android الأصلي)
دعم OpenGL، على النحو الموضّح أدناه
يُرجى العِلم أنّ الإصدارات المستقبلية من مجموعة تطوير البرامج (NDK) لنظام Android قد توفّر دعمًا لواجهات تطبيق ثنائية (ABI) إضافية.
إذا لم يكن تطبيق الجهاز متوافقًا مع معرّف بنية أساسية محدّد مسبقًا،
يجب عدم الإبلاغ عن توافقه مع أي معرّف بنية أساسية على الإطلاق .
إنّ التوافق مع الرموز البرمجية التلقائية هو تحدٍّ. لهذا السبب، يجب التذكير بأنّه
يُنصح بشدة لمطوّري الأجهزة باستخدام عمليات الطرح
للمكتبات المُدرَجة أعلاه للمساعدة في ضمان التوافق.
3.4. توافق الويب
3.4.1. توافق WebView
يستخدم الإصدار المفتوح المصدر من Android محرك عرض WebKit ل
تنفيذ android.webkit.WebView. بما أنّه من غير الممكن تطوير
مجموعة اختبارات شاملة لنظام عرض الويب، يجب على مطوّري الأجهزة استخدام
الإصدار المحدد من WebKit في تنفيذ WebView. على وجه التحديد:
يجب أن تستند عمليات تنفيذ android.webkit.WebView لعمليات تنفيذ الأجهزة
إلى الإصدار 534.30 من WebKit من شجرة الإصدارات السابقة لمشروع Android المفتوح المصدر
لنظام Android 4.1. يتضمّن هذا الإصدار مجموعة معيّنة من
إصلاحات الوظائف والأمان لـ WebView. يجوز لمطوّري التطبيقات على الأجهزة إدراج تخصيصات لتطبيق
WebKit، ولكن يجب ألا تؤدي أي من هذه التخصيصات إلى تغيير
سلوك WebView، بما في ذلك سلوك العرض.
يجب أن تكون سلسلة وكيل المستخدِم التي يعرضها WebView بهذا التنسيق:
Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL)
Build/$(BUILD)) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.1
Mobile Safari/534.30
يجب أن تكون قيمة سلسلة $(VERSION) متطابقة مع القيمة في

يجب أن تكون قيمة سلسلة $(VERSION) متطابقة مع القيمة في
android.os.Build.VERSION.RELEASE
يجب أن تكون قيمة سلسلة $(LOCALE) متطابقة مع المعيار ISO لترميز
رمز البلد واللغة، ويجب أن تشير إلى اللغة
المحددة حاليًا على الجهاز
يجب أن تكون قيمة سلسلة $(MODEL) متطابقة مع القيمة في
android.os.Build.MODEL
يجب أن تكون قيمة سلسلة $(BUILD) متطابقة مع القيمة في
android.os.Build.ID
يجوز لتطبيقات الأجهزة حذف كلمة Mobile في سلسلة وكيل المستخدِم
يجب أن يتضمّن مكوّن WebView دعمًا لأكبر قدر ممكّن من HTML5
[Resources, 11] على الأقل، يجب أن تتوافق عمليات تنفيذ التطبيقات على الأجهزة مع كل من
واجهات برمجة التطبيقات هذه المرتبطة بHTML5 في WebView:
ذاكرة التطبيق المؤقتة/العمل بلا اتصال بالإنترنت [المراجع، 12]
علامة <video> [المراجع، 13]
الموقع الجغرافي [المراجع، 14]
بالإضافة إلى ذلك، يجب أن تتوافق عمليات تنفيذ التطبيقات على الأجهزة مع واجهة برمجة تطبيقات webstorage في HTML5/W3C
[المراجع، 15] ويجب أن تتوافق مع واجهة برمجة تطبيقات IndexedDB في HTML5/W3C [المراجع،
16]. يُرجى العِلم أنّه مع انتقال هيئات معايير تطوير الويب إلى استخدام
IndexedDB بدلاً من webstorage، من المتوقّع أن يصبح IndexedDB مكوّنًا
مطلوبًا في إصدار مستقبلي من Android.
يجب إيقاف واجهات برمجة تطبيقات HTML5 بشكل تلقائي في WebView،
ما لم يفعّلها المطوّر بشكل واضح من خلال واجهات برمجة تطبيقات Android المعروفة.
3.4.2. توافق المتصفّح
يجب أن تتضمّن عمليات تثبيت الأجهزة تطبيق متصفّح مستقل لتصفّح
الويب العامة للمستخدمين. يجوز أن يستند المتصفّح المستقل إلى تكنولوجيا متصفّح
غير WebKit. ومع ذلك، حتى في حال استخدام تطبيق متصفّح بديل، يجب أن يكون مكوّن
android.webkit.WebView المقدَّم للتطبيقات التابعة لجهات خارجية
استنادًا إلى WebKit، على النحو الموضّح في الفقرة 3.4.1.
يجوز لعمليات التثبيت إرسال سلسلة وكيل مستخدم مخصّصة في تطبيق المتصفّح
المستقل.
يجب أن يتضمّن تطبيق المتصفّح المستقل (سواء كان مستندًا إلى تطبيق
WebKit Browser
أو بديلاً تابعًا لجهة خارجية) أكبر قدر ممكن من
HTML5‏[Resources, 11] على الأقل، يجب أن تتوافق عمليات تنفيذ التطبيقات مع
كل واجهة برمجة تطبيقات من هذه الواجهات المرتبطة بHTML5:
ذاكرة التخزين المؤقتة للتطبيق/العمل بلا اتصال بالإنترنت [المراجع، 12]
علامة <video> [المراجع، 13]
الموقع الجغرافي [المراجع، 14]
بالإضافة إلى ذلك، يجب أن تتوافق عمليات تنفيذ التطبيقات مع واجهة برمجة تطبيقات Webstorage في HTML5/W3C
[المراجع، 15]، ويجب أن تتوافق أيضًا مع واجهة برمجة تطبيقات IndexedDB في HTML5/W3C [المراجع،
16]. يُرجى العِلم أنّه مع انتقال هيئات معايير تطوير الويب إلى استخدام
IndexedDB بدلاً من webstorage، من المتوقّع أن يصبح
IndexedDB مكوّنًا مطلوبًا في إصدار مستقبلي من Android.
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>
).
إذا اقترح مُنفِّذ الأجهزة تحسين أحد نطاقات أسماء الحِزم المذكورة أعلاه
(مثلاً من خلال إضافة وظيفة جديدة ومفيدة إلى واجهة برمجة تطبيقات حالية أو إضافة واجهة برمجة تطبيقات جديدة)، على
المنفِّذ الانتقال إلى source.android.com وبدء عملية المساهمة
بالتغييرات والرموز البرمجية، وفقًا للمعلومات المتوفّرة على هذا الموقع.
يُرجى العلم أنّ القيود المذكورة أعلاه تتوافق مع الاتفاقيات العادية لتسمية واجهات برمجة التطبيقات في
لغة البرمجة Java. يهدف هذا القسم ببساطة إلى تعزيز هذه
الاتّفاقيات وجعلها ملزمة من خلال تضمينها في تعريف التوافق هذا.
3.7. توافق الأجهزة الافتراضية
يجب أن تتوافق عمليات تنفيذ التطبيقات على الأجهزة مع مواصفات الرمز البرمجي لملف Dalvik Executable (DEX)
ودلالات Dalvik Virtual Machine [Resources, 17].
يجب ضبط عمليات تنفيذ التطبيقات على Dalvik لتحديد مكان الذاكرة وفقًا
لنظام Android الأساسي، وكما هو موضح في الجدول التالي. (اطّلِع على
الفقرة 7.1.1 لمعرفة تعريفات حجم الشاشة وكثافة الشاشة).
يُرجى العِلم أنّ قيم الذاكرة المُحدَّدة أدناه تُعتبَر الحدّ الأدنى للقيم، وقد يُخصّص
تنفيذ الجهاز مزيدًا من الذاكرة لكل تطبيق.
حجم الشاشة
كثافة الشاشة
ذاكرة التطبيق
صغير  / عادي / كبير
ldpi / mdpi
16 ميغابايت
صغير  / عادي / كبير
tvdpi / hdpi
32 ميغابايت
صغير  / عادي / كبير
xhdpi
64 ميغابايت
كبير جدًا
mdpi
32 ميغابايت
كبير جدًا
tvdpi / hdpi
64 ميغابايت
كبير جدًا
xhdpi
128 ميغابايت
3.8. توافق واجهة المستخدم
3.8.1. تطبيقات المصغّرات
يحدِّد نظام Android نوع المكوّن وواجهة برمجة التطبيقات ودورة الحياة المقابلة التي تسمح

للتطبيقات بعرض "تطبيق مصغّر" للمستخدم الأخير [Resources, 18]. يتضمّن الإصدار المرجعي لنظام Android
المفتوح الرمز المصدر تطبيق مشغّل يتضمن عناصر تفاعل
واجهة المستخدم التي تسمح للمستخدم بإضافة "تطبيقات مصغّرة" وعرضها وإزالتها من
الشاشة الرئيسية.
يجوز لعمليات تنفيذ التطبيقات على الأجهزة استبدال بديل لمشغّل التطبيقات المرجعي (أي
الشاشة الرئيسية). يجب أن تتضمّن تطبيقات الإطلاق البديلة دعمًا مضمّنًا لتطبيقات AppWidget،
وأن توفّر عناصر تفاعل لواجهة المستخدم لإضافة تطبيقات AppWidget وضبطها وعرضها وإزالتها مباشرةً داخل تطبيق الإطلاق.
يجوز لتطبيقات الإطلاق البديلة حذف عناصر
واجهة المستخدم هذه، ولكن في حال حذفها، يجب أن يوفّر تطبيق الجهاز
تطبيقًا منفصلاً يمكن الوصول إليه من تطبيق الإطلاق ويتيح للمستخدمين إضافة تطبيقات صغيرة
وضبطها وعرضها وإزالتها.
يجب أن تكون عمليات تثبيت التطبيق على الأجهزة قادرة على عرض تطبيقات صغيرة بحجم 4 × 4 في
حجم الشبكة العادي. (اطّلِع على إرشادات تصميم تطبيقات الأدوات في مستندات حزمة Android SDK
[المراجع، 18] لمعرفة التفاصيل.
3.8.2. الإشعارات
يحتوي Android على واجهات برمجة تطبيقات تتيح للمطوّرين إرسال إشعارات إلى المستخدمين بشأن الأحداث البارزة
[مراجع، 19] باستخدام ميزات الجهاز والبرامج.
تسمح بعض واجهات برمجة التطبيقات للتطبيقات بعرض إشعارات أو جذب الانتباه باستخدام
الأجهزة، وتحديدًا الصوت والاهتزاز والضوء. يجب أن تتيح عمليات التنفيذ على الأجهزة
استخدام الإشعارات التي تستخدِم ميزات الأجهزة، على النحو الموضَّح في مستندات حزمة تطوير البرامج (SDK)
، وإلى أقصى حدّ ممكن مع الأجهزة المستخدَمة في تنفيذ التطبيق على الجهاز.
على سبيل المثال، إذا تضمّنت عملية التنفيذ على الجهاز مُشغِّل اهتزاز، يجب
تنفيذ واجهات برمجة تطبيقات الاهتزاز بشكلٍ صحيح. إذا كان تنفيذ الجهاز لا يتضمّن معدات، يجب تنفيذ
واجهات برمجة التطبيقات المقابلة كعمليات لا تتطلّب تفاعلاً. يُرجى العِلم أنّ هذا السلوك
موضَّح بمزيد من التفاصيل في القسم 7.
بالإضافة إلى ذلك، يجب أن تعرض التنفيذ بشكل صحيح جميع الموارد (الرموز وملفات
الصوت وما إلى ذلك) المتوفّرة في واجهات برمجة التطبيقات [الموارد، 20] أو في دليل
أسلوب رموز شريط الحالة/النظام [الموارد، 21]. يجوز لمطوّري الأجهزة تقديم
تجربة مستخدم بديلة للإشعارات عن تلك التي يوفّرها الإصدار المرجعي من Android المفتوح
المصدر، ولكن يجب أن تتوافق أنظمة الإشعارات البديلة هذه مع
موارد الإشعارات الحالية، على النحو الموضَّح أعلاه.
يتيح نظام Android 4.1 عرض إشعارات غنية، مثل العروض التفاعلية
للإشعارات المستمرة. يجب أن تعرض عمليات تنفيذ التطبيقات على الأجهزة بشكل صحيح إشعارات
المزوّدة بمحتوى مرئي، على النحو الموضّح في واجهات برمجة تطبيقات Android.
3.8.3. البحث
يحتوي Android على واجهات برمجة تطبيقات [Resources, 22] تتيح للمطوّرين دمج ميزة البحث في
تطبيقاتهم، وعرض بيانات تطبيقاتهم في البحث العام على النظام.
بشكل عام، تتألف هذه الالوظيفة من واجهة مستخدم واحدة على مستوى النظام
تتيح للمستخدمين إدخال طلبات البحث وعرض اقتراحات أثناء كتابتها وعرض
النتائج. تتيح واجهات برمجة تطبيقات Android للمطوّرين إعادة استخدام هذه الواجهة لتوفير ميزة البحث
داخل تطبيقاتهم، وتتيح للمطوّرين تقديم النتائج إلى واجهة مستخدم البحث العامة
.
يجب أن تتضمّن عمليات التثبيت على الأجهزة واجهة بحث مستخدم
واحدة ومشترَكة على مستوى النظام وتكون قادرة على تقديم اقتراحات في الوقت الحقيقي استجابةً لإدخال المستخدم. يجب أن تنفِّذ عمليات
تنفيذ التطبيقات على الأجهزة واجهات برمجة التطبيقات التي تسمح للمطوّرين بإعادة استخدام هذه
واجهة المستخدم لتوفير ميزة البحث داخل تطبيقاتهم. يجب أن تنفِّذ عمليات التثبيت على الأجهزة
واجهات برمجة التطبيقات التي تسمح للتطبيقات التابعة لجهات خارجية بإضافة اقتراحات إلى
مربّع البحث عند تشغيله في وضع البحث العمومي. إذا لم يتم
تثبيت تطبيقات تابعة لجهات خارجية تستخدم هذه الوظيفة، من المفترَض أن يكون السلوك التلقائي هو عرض
نتائج ومقترَحات محرك بحث الويب.
3.8.4. الرسائل المنبثقة
يمكن للتطبيقات استخدام Toast API (المحدّد في [Resources, 23]) لعرض سلسلة قصيرة غير
متعدّدة النوافذ للمستخدم الأخير، تختفي بعد فترة قصيرة من الوقت. يجب أن تعرِض عمليات
تنفيذ التطبيقات إشعارات Toast من التطبيقات إلى المستخدمين الأخيرين بطريقة
مرئية بشدة.
3.8.5. المظاهر
يوفّر نظام التشغيل Android "المظاهر" كآلية للتطبيقات لتطبيق أنماط على
نشاط أو تطبيق كاملَين. قدّم نظام Android 3.0
مظهرًا جديدًا "هولوجرافيك" أو "هولوجرامي" كمجموعة من الأنماط المحددة التي يمكن لمطوّري التطبيقات استخدامها إذا أرادوا مطابقة
مظهر مظهر مظهر Holo وأسلوبه على النحو الذي حدّدته حزمة تطوير برامج Android SDK [المراجع، 24]. يجب ألا تؤدي عمليات تنفيذ
على الأجهزة إلى تغيير أي من سمات مظهر Holo المعروضة في

التطبيقات [الموارد، 25].
أدخَل نظام Android 4.0 مظهرًا جديدًا "تلقائي على الجهاز" كمجموعة من أنماط محددة ليكون متاحًا لـ
مطوّري التطبيقات لاستخدامه إذا أرادوا مطابقة مظهر وأسلوب مظهر
الجهاز على النحو الذي حدّده منفِّذ الجهاز. يجوز لعمليات تنفيذ التطبيقات على الأجهزة تعديل سمات
DeviceDefault theme المعروضة للتطبيقات [Resources, 25].
3.8.6. الخلفيات المتحرّكة
تحدّد نظام التشغيل Android نوع المكوّن وواجهة برمجة التطبيقات ودورة الحياة المقابلة التي تسمح
للتطبيقات بعرض خلفية واحدة أو أكثر "متحرّكة" للمستخدم النهائي [المراجع، 26].
الخلفيات المتحرّكة هي رسوم متحرّكة أو نماذج أو صور مشابهة بإمكانات إدخال
محدودة تظهر كخلفية خلف التطبيقات الأخرى.
يُعتبر الجهاز قادرًا على عرض خلفيات حية بشكل موثوق إذا كان بإمكانه عرض جميع
خلفيات الحية، بدون قيود على الوظائف، بمعدل عرض إطارات معقول وبدون
تأثيرات سلبية على التطبيقات الأخرى. إذا تسبّبت قيود الأجهزة في تعطُّل خلفيات الشاشة
و/أو التطبيقات أو حدوث عيوب فيها أو استهلاكها لطاقة مفرطة من وحدة المعالجة المركزية أو البطارية أو
تشغيلها بمعدلات عرض إطارات منخفضة بشكلٍ غير مقبول، يُعتبَر الجهاز غير قادر على عرض
خلفية شاشة حية. على سبيل المثال، قد تستخدم بعض خلفيات الشاشة الحية سياق Open GL 1.0 أو 2.0
لعرض المحتوى. لن يعمل جدران الصور الحية بشكل موثوق على الأجهزة التي
لا تتوافق مع سياقات OpenGL المتعدّدة لأنّ استخدام جدران الصور الحية ل
سياق OpenGL قد يتعارض مع التطبيقات الأخرى التي تستخدم أيضًا سياق OpenGL.
يجب أن توفّر عمليات تثبيت الأجهزة القادرة على عرض خلفيات حية بشكل موثوق كما هو موضّح
أعلاه خلفيات حية. يجب عدم استخدام خلفيات الحائط الحية في عمليات تنفيذ التطبيقات على الأجهزة التي تبيّن أنّها لا
تعمل بطريقة موثوقة كما هو موضح أعلاه.
3.8.7. عرض التطبيقات المستخدمة مؤخرًا
يتضمّن رمز المصدر لنظام Android 4.1 الإصدار الأساسي واجهة مستخدم لعرض التطبيقات
المستخدمة مؤخرًا باستخدام صورة صغيرة لحالة التطبيق الرسومية في
اللحظة التي غادر المستخدم التطبيق فيها مؤخرًا. قد تؤدي عمليات تنفيذ التطبيق على الأجهزة إلى تغيير هذه واجهة المستخدم أو
إزالتها، ومع ذلك، من المخطَّط إطلاق إصدار مستقبلي من Android للاستفادة
بشكل أوسع من هذه الوظيفة. ننصح بشدة
باستخدام واجهة مستخدم Android 4.1 الأحدث (أو واجهة مشابهة
تستند إلى الملصقات المصغّرة) للتطبيقات الحديثة، وإلا قد لا تكون متوافقة مع
إصدار Android المستقبلي.
3.8.8. إعدادات إدارة الإدخال
يتضمن Android 4.1 دعمًا لمحرّكات إدارة الإدخال. تتيح واجهات برمجة تطبيقات Android 4.1
لتطبيقات محرّرات النص المتعدّدة اللغات المخصّصة تحديد إعدادات يمكن للمستخدم ضبطها. يجب أن تتضمّن عمليات تنفيذ التطبيقات على الأجهزة
طريقة يتيح بها المستخدم الوصول إلى إعدادات محرّر النص التلقائي في جميع الأوقات عندما يتم عرض محرّر نص تلقائي
يوفّر هذه الإعدادات للمستخدم.
3.8.9. عناصر التحكّم عن بُعد في شاشة القفل
قدّم نظام Android 4.0 دعمًا لواجهة برمجة التطبيقات Remote Control API التي تسمح لتطبيقات الوسائط
بالدمج مع عناصر التحكّم في التشغيل التي تظهر في عرض عن بُعد، مثل شاشة
القفل الجهاز [المراجع، 69]. يجب أن تتضمن عمليات تثبيت التطبيق على الأجهزة إمكانية
دمج عناصر التحكّم عن بُعد في شاشة قفل الجهاز.
3.9 إدارة الجهاز
يحتوي Android 4.1 على ميزات تسمح للتطبيقات المدركة للأمان بتنفيذ وظائف
إدارة الجهاز على مستوى النظام، مثل فرض سياسات كلمات المرور أو
تنفيذ محو البيانات عن بُعد، من خلال واجهة برمجة تطبيقات إدارة الأجهزة في Android [المراجع،
27]. يجب أن توفّر عمليات تنفيذ التطبيقات على الأجهزة تنفيذًا لفئة
DevicePolicyManager [Resources, 28]، ويجب أن تتوافق مع مجموعة
سياسات إدارة الأجهزة المحدّدة في مستندات حزمة تطوير برامج Android SDK [Resources,
27].
ملاحظة: على الرغم من أنّ بعض المتطلبات الموضّحة أعلاه مُدرَجة على أنّها "يجب" لنظام
Android 4.1، من المخطّط تغيير هذه المتطلبات
إلى "يجب" في الإصدارات المستقبلية. بمعنى آخر، هذه المتطلبات اختيارية في Android 4.1 ولكن ستكون
مطلوبة في إصدار مستقبلي. ننصح بشدة
باستيفاء هذه المتطلبات في Android 4.1 على الأجهزة الحالية والجديدة التي تعمل بهذا الإصدار، وإلا لن
يتمكنوا من تحقيق التوافق مع Android عند الترقية إلى الإصدار المستقبلي.
3.10 تسهيل الاستخدام
يوفّر نظام Android 4.1 طبقة تسهيل الاستخدام التي تساعد المستخدمين ذوي الإعاقات في التنقّل في
أجهزتهم بسهولة أكبر. بالإضافة إلى ذلك، يوفّر Android 4.1 واجهات برمجة تطبيقات لنظام العمل تتيح

لعمليات تنفيذ خدمة تسهيل الاستخدام تلقّي إشعارات بأحداث المستخدم والنظام
وإنشاء آليات ردود بديلة، مثل تحويل النص إلى صوت، والردود
اللمسية، والتنقّل باستخدام الكرة التتبُّع أو أزرار التوجيه [Resources, 29].يجب أن توفّر عمليات تنفيذ الأجهزة
تنفيذًا لإطار عمل تسهيل الاستخدام في Android متوافقًا
مع التنفيذ التلقائي لنظام Android. وعلى وجه التحديد، يجب أن تستوفي عمليات تنفيذ الأجهزة
المتطلبات التالية.
يجب أن تتوافق عمليات تنفيذ الميزات على الأجهزة مع عمليات تنفيذ خدمات تسهيل الاستخدام التابعة لجهات خارجية
من خلال واجهات برمجة التطبيقات android.accessibilityservice [Resources,
30].
يجب أن تُنشئ عمليات تنفيذ الميزات على الأجهزة أحداث تسهيل الاستخدام وتعرض
هذه الأحداث لجميع عمليات تنفيذ AccessibilityService المسجَّلة بطريقة
متسقة مع طريقة تنفيذ Android التلقائية.
يجب أن توفِّر عمليات تنفيذ الميزات على الأجهزة آلية يمكن للمستخدم الوصول إليها لتفعيل
خدمات تسهيل الاستخدام وتعطيلها، ويجب عرض هذه الواجهة استجابةً
لطلب android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS.
بالإضافة إلى ذلك، يجب أن توفّر عمليات تنفيذ الأجهزة تنفيذًا لإحدى
خدمات تسهيل الاستخدام على الجهاز، ويجب أن توفّر آلية للمستخدمين
لتفعيل خدمة تسهيل الاستخدام أثناء إعداد الجهاز. يتوفر تطبيق مفتوح المصدر
لخدمة تسهيل الاستخدام من مشروع Eyes Free [Resources, 31].
3.11 تحويل النص إلى كلام
يحتوي الإصدار 4.1 من نظام التشغيل Android على واجهات برمجة تطبيقات تسمح للتطبيقات باستخدام خدمات تحويل النص إلى كلام
، وتسمح لمقدّمي الخدمات بتوفير عمليات تنفيذ لخدمات تحويل النص إلى كلام
[المراجع، 32]. يجب أن تستوفي عمليات تنفيذ التطبيق على الأجهزة هذه المتطلبات المرتبطة بإطار عمل
تحويل النص إلى كلام في Android:
يجب أن تتوافق عمليات تنفيذ التطبيق على الأجهزة مع واجهات برمجة تطبيقات إطار عمل تحويل النص إلى كلام في Android و
يجب أن تتضمن محركًا لتحويل النص إلى كلام يتوافق مع اللغات المتوفّرة على
الجهاز. يُرجى العِلم أنّ الإصدار الأساسي من برنامج Android المفتوح الرمز المصدر يتضمّن تنفيذًا شاملاً لمحرك
التحويل التلقائي للكلام.
يجب أن تتوافق عمليات تنفيذ البرنامج على الأجهزة مع تركيب محركات التحويل التلقائي للكلام التابعة لجهات خارجية.
يجب أن توفّر عمليات تنفيذ البرنامج على الأجهزة واجهة يمكن للمستخدم الوصول إليها وتسمح
للمستخدمين باختيار محرك التحويل التلقائي للكلام لاستخدامه على مستوى النظام.
4. توافق حِزم التطبيقات
يجب أن تثبِّت عمليات نشر التطبيقات ملفات Android ‎ ".apk" وتشغِّلها على النحو الذي تنشئه أداة
"aapt" المضمَّنة في حزمة SDK الرسمية لنظام Android [المراجع، 33].
يجب ألا تتجاوز عمليات تنفيذ التطبيقات على الأجهزة أيًا من تنسيقات ملف ‎ .apk [Resources, 34] أو بيان
Android [Resources, 35] أو الرمز البرمجي للغة Dalvik [Resources, 17] أو الرمز البرمجي للغة renderscript
بطريقة تمنع تثبيت هذه الملفات وتشغيلها بشكلصحيح
على أجهزة أخرى متوافقة. يجب أن يستخدِم مطوّرو التطبيقات على الأجهزةالإصدار المرجعي
من Dalvik ونظام إدارة
الحِزم في الإصدار المرجعي.
5. توافق الوسائط المتعددة
يجب أن تتضمن عمليات تنفيذ الأجهزة طريقةً واحدة على الأقل لإخراج الصوت، مثل
السماعات ومقبس سماعات الرأس ومكبّرات الصوت الخارجية وما إلى ذلك.
5.1. برامج ترميز الوسائط
يجب أن تتوافق عمليات تنفيذ الأجهزة مع تنسيقات الوسائط الأساسية المحدّدة في
مستندات حزمة تطوير برامج Android SDK [المراجع، 58] إلا في الحالات التي يُسمح بها بوضوح في هذا
المستند. وبالتحديد، يجب أن تتوافق عمليات تنفيذ الأجهزة مع تنسيقات الوسائط، و
برامج التشفير وفك التشفير، وأنواع الملفات وتنسيقات حاويات الوسائط المحدّدة في الجداول أدناه. يتم توفير
جميع برامج ترميز الصوت والفيديو هذه كعمليات تنفيذللبرامج في الإصدار المفضّل من
Android من "المشروع المفتوح المصدر لنظام Android".
يُرجى العِلم أنّه لا تُقدّم "Google" أو "تحالف الهواتف الذكية المفتوحة" أي
بيان يفيد بأنّ برامج ترميز الصوت والفيديو هذه غير مرتبطة بتراخيص براءات اختراع تابعة لجهات خارجية.
ننصح مستخدمي هذا الرمز المصدر في منتجات الأجهزة أو البرامج
بأنّ تنفيذ هذا الرمز، بما في ذلك في البرامج المفتوحة المصدر
أو برامج المشاركة، قد يتطلّب تراخيص براءات اختراع من أصحاب براءات الاختراع المعنيين.
يُرجى العلم أنّ هذه الجداول لا تُدرج متطلبات محددة لمعدل نقل البيانات لمعظم برامج ترميز الفيديوهات
لأنّ معدات الأجهزة الحالية لا تتوافق بالضرورة مع معدلات نقل البيانات التي تتوافق
تمامًا مع معدلات نقل البيانات المطلوبة والمحددة بواسطة المعايير ذات الصلة. وبدلاً من ذلك، يجب أن تتوافق عمليات
تنفيذ الأجهزة مع أعلى معدل نقل بيانات عملي على الأجهزة، وذلك حتى

الحدّ الأعلى الذي تحدّده المواصفات.

أنواع الملفات /
التنسيق /
النوع
برنامج الترميز
برنامج الترميز العكسي
التفاصيل
حاوية
ترميز
التنسيقات
التوافق مع
مطلوب
الصوت الأحادي/المجسم/5.0/5.1*
MPEG-4
مطلوب لعمليات تنفيذ الأجهزة
المحتوى الذي يتضمّن
ملف التعريف AAC
الذي يتضمّن معدات الميكروفون
مطلوب
معدل الاستيلاء العادي
(AAC LC)
وتحديد
3GPP
المعدلات من 8 إلى 48
android.hardware.microphone.
(‎.3gp)
kHz.
MPEG-4
التوافق مع
(‎.mp4,
MPEG-4
mono/stereo/5.0/5.1*
.m4a)
HE AAC
المحتوى مع
ADTS الخام

مطلوب
الملف الشخصي
معيار الاستناد
AAC (‎.aac,
(AAC+)
معدلات من 16 إلى 48
فك الترميز في
kHz
الإصدار 3.1 من نظام التشغيل Android أو الإصدارات الأحدث،
يجب أن يكون نظام التشغيل متوافقًا مع
MPEG-4
لترميز الجهاز
بتنسيق
مونو/ستيريو/5.0/5.1*
HE AAC v2
الإصدارات التي تتضمّن
محتوى
Android
باستخدام
Profile
معدات الميكروفون

4.0 والإصدارات الأحدث، ADIF
معيار أخذ العينات
(لا
يحدد
معدلات من 16 إلى 48
AAC+)
android.hardware.microphone
غير متوافقة)
kHz.

MPEG-TS
MPEG-4
(‎.ts، وليس
الصوت
مطلوب للجهاز
التوافق مع
عمليات تنفيذ
نوع العنصر
التي تتضمن
محتوى مونو/ستيريو
Android
ER AAC
معيار
الأجهزة المزوّدة بميكروفون
مطلوب
مع الإصدار
3.0+
ELD
تحديد
معدلات أخذ العيّنات من
(مُحسَّن
android.hardware.microphone
16 إلى 48 kHz.
معدّل تأخُّر منخفض
ترميز الصوت المتقدّم (AAC)
مطلوب
مطلوب لعمليات تنفيذ الأجهزة
من 4.75 إلى 12.2 كيلوبت في الثانية
AMR-NB
التي تتضمن أجهزة الميكروفون
مطلوب
تنسيق 3GPP (‎.3gp)
يتم تحليله بمعدل 8 كيلوهرتز
وتحديد
android.hardware.microphone.
مطلوبة
مطلوبة لعمليات تنفيذ الأجهزة
9 معدلات من 6.60
AMR-WB
التي تشمل معدات الميكروفون
مطلوبة
kbit/s إلى 23.85 kbit/s
3GPP (‎.3gp)
وتحديد
يتم أخذ عيّنات بمعدل 16 كيلوهرتز
android.hardware.microphone.
صوت أحادي/استيريو (بدون
قنوات متعددة)
معدّلات البيانات في الملف الصوتي
لغاية
48 كيلوهرتز (ولكن يُنصح
باستخدام معدّل لغاية
44.1 كيلوهرتز على
الأجهزة التي تستخدم

تنسيق FLAC

بسرعة 44.1 كيلوهرتز، لأنّ تنسيق
FLAC (‎.flac)
(الإصدار 3.1 من نظام التشغيل Android والإصدارات الأحدث)
يستخدم
معدّل تقليل البيانات إلى
44.1 كيلوهرتز ولا
يتضمّن
فلترًا للترددات
الدنيا). يُنصح باستخدام 16
بت، ولا يتم تطبيق
تمويه على 24
بت.
صوت أحادي/صوت استيريو بمعدل ثابت من 8 إلى
320 كيلوبت في الثانية
تنسيق
MP3

مطلوبة
تنسيق
MP3 (‎.mp3)
(مع معدل نقل بيانات ثابت) أو
بمعدل نقل بيانات متغير
النوع 0 و
النوع 0 و1 من تنسيق
MIDI
1 (‎.mid,
الإصدار 1 من DLS و
‎.xmf, .mxmf)
2. XMF وMobile
RTTTL/RTX
MIDI

مطلوب
XMF. إتاحة تنسيقات
(‎.rtttl و‎.rtx)
نغمات الرنين
OTA (‎.ota)
RTTTL/RTX وOTA و
iMelody
وiMelody
(‎.imy)

Ogg (‎.ogg)
Vorbis

مطلوب

Matroska
(‎.mkv)
الترميز
الصوتي
المباشر
بترميز
PCM‏ 8 و16 بت** (بمعدلات
تصل إلى الحد الأقصى
للأجهزة). يجب أن تتيح الأجهزة

PCM/WAVE
مطلوب
مطلوب
WAVE (‎.wav)
معدلات
تسجيل

الصوت
المباشر
بترميز
PCM‏ 8 و16 بت** (بمعدلات
تصل إلى الحد الأقصى
للأجهزة). يجب أن تتيح الأجهزة
JPEG
مطلوب
مطلوب
Base+progressive
JPEG (‎.jpg)
GIF

مطلوب

GIF (‎.gif)
صورة
PNG
مطلوب
مطلوب

PNG (‎.png)
BMP

مطلوب

BMP (‎.bmp)
WEBP
مطلوب
مطلوب

WebP (‎.webp)
مطلوب
مطلوب لعمليات تنفيذ الأجهزة
3GPP
التي تتضمن معدات الكاميرا و
(‎.3gp)
H.263
مطلوب

تحديد android.hardware.camera
MPEG-4
أو
(‎.mp4)
android.hardware.camera.front.
3GPP
(‎.3gp)
مطلوب
MPEG-4
(‎.mp4)
مطلوب لعمليات تنفيذ الأجهزة
MPEG-TS
التي تتضمن معدات الكاميرا و
الملفّ الشخصي الأساسي
الفيديو
H.264 AVC
مطلوب
(‎.ts, AAC
يحدِّد android.hardware.camera
(BP)
الصوت فقط،
أو
ليس
android.hardware.camera.front.
قابلاً للتقديم/الترجيع،
Android
3.0+)
MPEG-4

مطلوب

3GPP (‎.3gp)
SP
WebM (‎.webm)
مطلوب
وMatroska
VP8

(Android

(‎.mkv, Android
2.3.3+)
4.0+)
*ملاحظة: لا يُشترط سوى تقليل جودة المحتوى الذي يبلغ مستوى 5.0/5.1، وتسجيل أو عرض أكثر من
قناة واحدة اختياري. **ملاحظة: يجب تسجيل الصوت بتنسيق PCM الخطّي بدقة 16 بت. تسجيل الصوت بتنسيق PCM
الاستيفاءي بترميز 8 بت غير إلزامي.
5.2 ترميز الفيديو
يجب أن تتوافق عمليات تنفيذ أجهزة Android التي تتضمن كاميرا خلفية وتُعلن
android.hardware.camera مع الملفات التعريفية التالية لترميز الفيديو.
عالية الدقة (عند توفّرها)

منخفضة الدقة (جودة منخفضة) منخفضة الدقة (جودة عالية)
الأجهزة)
ملف التعريف المبدئي بتنسيق H.264
ملف التعريف المبدئي بتنسيق H.264
برنامج ترميز الفيديو
ملف التعريف المبدئي بتنسيق H.264
ملف التعريف
ملف التعريف
الفيديو
176 × 144 بكسل
480 × 360 بكسل
1280 × 720 بكسل
درجة الدقة
معدل اللقطات في الفيديو 12 لقطة في الثانية
30 لقطة في الثانية
30 لقطة في الثانية

500 كيلوبت في الثانية أو
معدل نقل بيانات الفيديو 56 كيلوبت في الثانية
2 ميغابت في الثانية أو أكثر
أكثر
برنامج ترميز الصوت AAC-LC
AAC-LC
AAC-LC

الصوت
1 (صوت أحادي)
2 (صوت ستيريو)
2 (صوت ستيريو)
قناة
معدل نقل بيانات الصوت 24 كيلوبت في الثانية
128 كيلوبت في الثانية
192 كيلوبت في الثانية
5.3. تسجيل الصوت
عندما يستخدِم التطبيق واجهة برمجة التطبيقات android.media.AudioRecord لبدء تسجيل
بث صوتي، يجب أن تستخدِم عمليات تنفيذ التطبيق التي تتضمن معدات الميكروفون و
تُعلِن عن android.hardware.microphone لتحليل الصوت وتسجيله باستخدام كل من
السلوكيات التالية:
يجب أن يُظهِر الجهاز خصائص موج صوتية مسطّحة تقريبًا مقارنةً بتردده
، وتحديدًا ±3 ديسيبل من 100 هرتز إلى 4000 هرتز.
يجب ضبط حساسية إدخال الصوت بحيث ينتج عن مصدر طاقة صوتية بمستوى 90 ديسيبل
(SPL) عند 1000 هرتز قيمة متوسطة مربّعة للطاقة تبلغ 2500 لعيّنات بسعة 16 بت.
يجب أن تتبّع مستويات سعة الصوت في الترميز المتقدّم للصوت (PCM) تغييرات مستوى SPL للإدخال بشكلٍ خطي على مدار
نطاق 30 ديسيبل على الأقل من -18 ديسيبل إلى +12 ديسيبل مقارنةً بمستوى 90 ديسيبل SPL في الميكروفون.
يجب أن يكون التشويش المتوافق مع الترددات الهارمونية الإجمالي أقل من% 1 لتردد 1 كيلوهرتز عند مستوى إدخال 90 ديسيبل
.
بالإضافة إلى مواصفات التسجيل الموضَّحة أعلاه، عند بدء تطبيق
تسجيل بث صوتي باستخدام
android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION كأحد مصادر الصوت:
يجب إيقاف معالجة تقليل الضوضاء، إذا كانت متوفّرة.
يجب إيقاف التحكّم التلقائي في مستوى الصوت، إذا كان متوفّرًا.
ملاحظة: على الرغم من أنّ بعض المتطلبات الموضّحة أعلاه مُدرَجة على أنّها "يجب" لنظام
Android 4.1، من المخطّط تغيير هذه المتطلبات
إلى "يجب" في الإصدارات المستقبلية. بمعنى آخر، هذه المتطلبات اختيارية في Android 4.1 ولكن ستكون
مطلوبة في إصدار مستقبلي. ننصح بشدة
باستيفاء هذه المتطلبات في Android 4.1 على الأجهزة الحالية والجديدة التي تعمل بهذا الإصدار، وإلا لن
يتمكنوا من تحقيق التوافق مع Android عند الترقية إلى الإصدار المستقبلي.
5.4. وقت استجابة الصوت
يتم تعريف وقت استجابة الصوت على نطاق واسع على أنّه الفاصل بين وقت طلب التطبيق
إجراء تشغيل الصوت أو تسجيله، ووقت بدء تنفيذ الجهاز للإجراء بشكل فعلي
. تعتمد العديد من فئات التطبيقات على وقت استجابة قصير، لتحقيق
تأثيرات في الوقت الحقيقي، مثل التأثيرات الصوتية أو التواصل عبر بروتوكول صوت على الإنترنت. يجب أن تستوفي عمليات تنفيذ الأجهزة
التي تتضمن معدات الميكروفون وتُعلن عن android.hardware.microphone
جميع متطلبات وقت استجابة الصوت الموضَّحة في هذا القسم. يُرجى الاطّلاع على الفقرة 7
لمعرفة التفاصيل حول الشروط التي قد تؤدي إلى حذف معدات الميكروفون من خلال
عمليات تنفيذ الأجهزة.
لأغراض هذا القسم:
يتم تعريف "وقت الاستجابة في إخراج الصوت" على أنّه الفاصل الزمني بين وقت طلب التطبيق
لتشغيل الصوت ووقت بدء تشغيله، وذلك عندما يكون نظام الصوت
في وضع السكون ويكون الجهاز مطفأً.
يتم تعريف"وقت الاستجابة في إخراج الصوت" على أنّه الفاصل الزمني بين وقت طلب التطبيق
لتشغيل الصوت ووقت بدء تشغيله، وذلك عندما يكون نظام الصوت
قد تم استخدامه مؤخرًا ولكنّه في وضع السكون حاليًا (أي صامت).
يتم تعريف"وقت الاستجابة في إخراج الصوت" على أنّه الفاصل الزمني بين وقت طلب التطبيق
لتشغيل الصوت ووقت بدء تشغيله، وذلك عندما يكون الجهاز في وضع تشغيل الصوت.
يتم تعريف"وقت الاستجابة في إدخال الصوت" على أنّه الفاصل الزمني بين وقت طلب التطبيق
لتسجيل الصوت ووقت إرسال العيّنة الأولى إلى التطبيق
عبر واجهة برمجة التطبيقات، وذلك عندما يكون نظام الصوت والميكروفون
في وضع السكون ويكون الجهاز مطفأً.
يتم تعريف"وقت الاستجابة في إدخال الصوت" على أنّه الفاصل الزمني بين وقت حدوث صوت محيطي ووقت إرسال العيّنة المقابلة لهذا الصوت إلى تطبيق
التسجيل عبر واجهة برمجة التطبيقات، وذلك عندما يكون الجهاز في وضع التسجيل.
استنادًا إلى التعريفات أعلاه، يجب أن توفّر عمليات تنفيذ الأجهزة كلًا من
السمات التالية:
وقت استجابة إخراج الصوت عند عدم استخدام الجهاز لمدة 100 مللي ثانية أو أقل
وقت استجابة إخراج الصوت عند استخدام الجهاز مؤخرًا لمدة 10 مللي ثانية أو أقل
وقت استجابة إخراج الصوت المستمر لمدة 45 مللي ثانية أو أقل
وقت استجابة إدخال الصوت عند عدم استخدام الجهاز لمدة 100 مللي ثانية أو أقل
وقت استجابة إدخال الصوت المستمر لمدة 50 مللي ثانية أو أقل
ملاحظة: على الرغم من أنّ المتطلبات الموضّحة أعلاه مُدرجة على أنّها "يجب" استيفاؤها في نظام التشغيل Android 4.1،

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

ننصح بشدة
باستيفاء هذه المتطلبات في Android 4.1 على الأجهزة الحالية والجديدة التي تعمل بهذا الإصدار، وإلا لن يكون بإمكانها
تحقيق التوافق مع Android عند الترقية إلى الإصدار المستقبلي.
إذا كان تطبيق الجهاز يستوفي متطلبات هذا القسم، قد يُبلغ
عن توفُّر ميزة الصوت بوقت استجابة منخفض، من خلال الإبلاغ عن الميزة "android.hardware.audio.low-
latency" عبر فئة android.content.pm.PackageManager. [Resources, 37]
بالمقابل، إذا لم يستوفِ تنفيذ الجهاز هذه المتطلبات، يجب
عدم الإبلاغ عن توفّر الصوت بوقت استجابة منخفض.
5.5. بروتوكولات الشبكة
يجب أن تتوافق الأجهزة مع بروتوكولات شبكة الوسائط لتشغيل الصوت والفيديو على النحو
الموضَّح في مستندات حزمة تطوير برامج الوسائط لنظام Android [المراجع، 58]. على وجه التحديد، يجب أن تكون الأجهزة
متوافقة مع البروتوكولات التالية لشبكة الوسائط:
بروتوكول RTSP (RTP وSDP)
البث المتزايد ببروتوكول HTTP(S)
بروتوكول مسودة البث المباشر ببروتوكول HTTP(S)، الإصدار 3 [Resources, 59]
6. توافق أدوات المطوّر
يجب أن تتوافق عمليات تنفيذ الأجهزة مع أدوات مطوّري برامج Android المتوفّرة في
حزمة تطوير برامج (SDK) لنظام Android. على وجه التحديد، يجب أن تكون الأجهزة المتوافقة مع Android متوافقة مع:
Android Debug Bridge (المعروف بـ adb) [المراجع، 33]
يجب أن تتوافق عمليات تنفيذ الأجهزة مع جميع وظائف adb كما هو موضَّح في
حزمة تطوير برامج (SDK) لنظام Android. يجب أن يكون برنامج adb الخدمي على الجهاز غير نشط تلقائيًا، و
يجب أن تتوفّر آلية يمكن للمستخدم الوصول إليها لتفعيل
جسر تصحيح الأخطاء في Android.
خدمة مراقبة تصحيح الأخطاء في Dalvik (المعروفة بـ ddms) [المراجع، 33]
يجب أن تتوافق عمليات تنفيذ التطبيقات على الأجهزة مع جميع ميزات ddms على النحو الموضَّح في
حزمة تطوير برامج Android SDK. بما أنّ ddms يستخدِم adb، من المفترَض أن يكون استخدام ddms غير نشط بشكلٍ
تلقائي، ولكن يجب أن يكون متاحًا عندما يفعِّل المستخدم
Debug Bridge في Android، كما هو موضح أعلاه.
Monkey [Resources, 36]
يجب أن تتضمن عمليات تنفيذ التطبيقات إطار عمل Monkey، وإتاحته
للتطبيقات لاستخدامه.
تتعرّف معظم الأنظمة المستندة إلى Linux وأنظمة Apple Macintosh على أجهزة Android
باستخدام أدوات حِزم تطوير البرامج (SDK) العادية لنظام Android، بدون دعم إضافي. ومع ذلك، تتطلّب أنظمة Microsoft
Windows عادةً برنامج تشغيل لأجهزة Android الجديدة. (على سبيل المثال،
تتطلّب معرّفات المورّدين الجديدة وأحياناً معرّفات الأجهزة الجديدة برامج تشغيل USB مخصّصة لأنظمة
Windows.) إذا لم تتعرّف أداة adb على عملية تنفيذ الجهاز على النحو
الموضّح في حزمة تطوير برامج Android المعيار، على منفّذِي الأجهزة توفير برامج التشغيل
لنظام التشغيل Windows للسماح للمطوّرين بالاتصال بالجهاز باستخدام بروتوكول adb. يجب توفير هذه
برامج التشغيل لنظام Windows XP وWindows Vista وWindows 7 بكلٍّ من
الإصدارَين 32 بت و64 بت.
7. التوافق مع المعدّات
إذا كان الجهاز يتضمّن مكوّن معدّات معيّنًا يتضمّن واجهة برمجة تطبيقات مقابلة ل
المطوّرين الجهات الخارجية، يجب أن تنفّذ واجهة برمجة التطبيقات هذه على الجهاز على النحو
الموضّح في مستندات حزمة تطوير برامج Android SDK. إذا كانت واجهة برمجة التطبيقات في حزمة SDK تتفاعل مع
مكوّن أجهزة يُعتبر اختياريًا وإذا لم تضمّن طريقة تنفيذ الجهاز
هذا المكوّن:
يجب أن تظل تعريفات الفئات كاملة (على النحو الموضّح في مستندات حزمة SDK) لواجهات برمجة التطبيقات في المكوّن
يجب تنفيذ سلوكيات واجهة برمجة التطبيقات على أنّها عمليات لا تؤدي إلى أي إجراء بطريقة
معقولة
يجب أن تُعرِض طُرق واجهة برمجة التطبيقات قيمًا فارغة
حيث يسمح بهذا مستند حزمة SDK
يجب أن تُعرِض طُرق واجهة برمجة التطبيقات عمليات تنفيذ لا تؤدي إلى أي إجراء
حيث لا يسمح بهذا مستند حزمة SDK
يجب ألا تُعرِض طُرق واجهة برمجة التطبيقات استثناءات غير مُوثَّقة في مستند حزمة SDK
من الأمثلة الشائعة على السيناريوهات التي تنطبق عليها هذه المتطلبات واجهة برمجة تطبيقات الهاتف:
حتى على الأجهزة غير الهواتف، يجب تنفيذ واجهات برمجة التطبيقات هذه على أنّها عمليات لا تؤدي إلى أي إجراء بطريقة معقولة.

يجب أن تُبلغ عمليات تنفيذ الأجهزة بدقة عن معلومات ضبط الأجهزة
من خلال الاستعانة بمنهجَي getSystemAvailableFeatures() وhasSystemFeature(String)
في الفئة android.content.pm.PackageManager. [مرجعالمصادر، 37]
7.1. الشاشة والرسومات
يحتوي Android 4.1 على تسهيلات تعمل تلقائيًا على تعديل مواد عرض التطبيقات وتنسيقات
واجهة المستخدم بشكل مناسب للجهاز، لضمان عمل التطبيقات التابعة لجهات خارجية بشكل جيد على
مجموعة متنوعة من إعدادات الأجهزة [المراجع، 38]. يجب أن تنفذ الأجهزة بشكل سليم
هذه واجهات برمجة التطبيقات والسلوكيات، على النحو الموضّح في هذا القسم.
يتم تحديد الوحدات المُشار إليها في المتطلبات في هذا القسم على النحو التالي:
"الحجم الجانبي العامودي للشاشة" هو المسافة بالبوصة بين الزواويتين المتقابلتَين
للجزء المضاء من الشاشة.
"النقاط لكل بوصة" (dpi) هي عدد وحدات البكسل المُضمّنة في مساحة خطية
أفقية أو عمودية بطول 1". في الأماكن التي تُدرَج فيها قيم نقاط الدقة، يجب أن تقع قيم نقاط الدقة الأفقية و
الرأسية في النطاق.
"نسبة العرض إلى الارتفاع" هي نسبة السمت الأطول للشاشة إلى السمت الأقصر.
على سبيل المثال، شاشة بدقة 480×854 بكسل ستكون 854 / 480 =
1.779، أو تقريبًا "16:9".
"وحدة البكسل المستقلة عن الكثافة" أو ("dp") هي وحدة البكسل الافتراضية المعدّلة لتناسب شاشة بكثافة 160
نقطة في البوصة، وتُحتسب على النحو التالي: البكسل = وحدة الكثافة * (الكثافة / 160).
7.1.1. إعدادات الشاشة
حجم الشاشة
تتيح إطار عمل واجهة مستخدم Android استخدام مجموعة متنوعة من أحجام الشاشات المختلفة، وتسمح
للتطبيقات بطلب حجم شاشة الجهاز (المعروف أيضًا باسم "تنسيق الشاشة") من خلال
android.content.res.Configuration.screenLayout مع
SCREENLAYOUT_SIZE_MASK. يجب أن تُبلغ عمليات تنفيذ الأجهزة عن حجم الشاشة
الصحيح على النحو الموضَّح في مستندات حزمة تطوير برامج Android SDK [المراجع، 38] والذي تحدِّده
منصّة Android الأساسية. على وجه التحديد، يجب أن تُبلغ عمليات تنفيذ الأجهزة عن
حجم الشاشة الصحيح وفقًا للأبعاد التالية للشاشة اللوجستية المستقلة عن الكثافة بالبكسل (dp).

يجب أن تكون أحجام شاشات الأجهزة التي يتم إدراجها على أنّها "صغيرة" على الأقل 426 dp x ‏320 dp.
يجب أن تكون أحجام شاشات الأجهزة التي يتم إدراجها على أنّها "عادية" على الأقل 480 dp x ‏320 dp.
يجب أن تكون أحجام شاشات الأجهزة التي يتم إدراجها على أنّها "كبيرة" على الأقل 640 dp x ‏480 dp.
يجب أن تكون أحجام شاشات الأجهزة التي يتم إدراجها على أنّها "كبيرة جدًا" على الأقل 960 dp x ‏720 dp.
بالإضافة إلى ذلك، يجب أن تكون أحجام شاشات الأجهزة على الأقل 2.5 بوصة في الحجم القطري.

يجب ألا تغيّر الأجهزة حجم الشاشة المُبلَّغ عنه في أي وقت.
يمكن للتطبيقات اختياريًا تحديد أحجام الشاشة التي تتوافق معها من خلال السمة <supports-
screens> في ملف AndroidManifest.xml. يجب أن تلتزم عمليات نشر التطبيقات
بشكل صحيح بتوافق التطبيقات المُعلَن عنه مع الشاشات smal وnormal وlarge وxlarge
، على النحو الموضَّح في مستندات Android SDK.
نسبة عرض الشاشة إلى ارتفاعها
يجب أن تتراوح نسبة العرض إلى الارتفاع بين 1.3333 (4:3) و1.85 (16:9).
كثافة الشاشة
يحدِّد إطار عمل واجهة مستخدم Android مجموعة من الكثافات المنطقية المعيارِية لمساعدة
مطوّري التطبيقات في استهداف موارد التطبيقات. يجب أن تُبلغ عمليات تنفيذ التطبيقات على الأجهزة
عن أحد الكثافات المنطقية التالية لإطار عمل Android من خلال واجهات برمجة التطبيقات
android.util.DisplayMetrics، ويجب تنفيذ التطبيقات بهذه الكثافة
المعيارية.
120 dpi، المعروفة بـ 'ldpi'
160 dpi، المعروفة بـ 'mdpi'
213 dpi، المعروفة بـ 'tvdpi'
240 dpi، المعروفة بـ 'hdpi'
320 dpi، المعروفة بـ 'xhdpi'
480 dpi، المعروفة بـ 'xxhdpi'
يجب أن تحدّد عمليات تنفيذ التطبيقات كثافة إطار عمل Android العادي التي
تكون رقميًا أقرب إلى الكثافة الفعلية للشاشة، ما لم تؤدي هذه الكثافة المنطقية
إلى خفض حجم الشاشة المُبلَّغ عنه إلى أقل من الحدّ الحدّ الأدنى المتوافق.

إذا كانت كثافة
إطار عمل Android العادي الأكثر تطابقًا رقميًا مع الكثافة الفعلية تؤدي إلى حجم شاشة
أصغر من أصغر حجم شاشة متوافق متوافق (320 dp عرض)،
يجب أن تُبلغ عمليات تنفيذ الأجهزة عن كثافة
إطار عمل Android العادي الأدنى التالي.
7.1.2. مقاييس الشاشة
يجب أن تُبلغ عمليات تنفيذ التطبيقات على الأجهزة عن قيم صحيحة لجميع مقاييس الشاشة المحدّدة في
android.util.DisplayMetrics [Resources, 39].
7.1.3. اتجاه الشاشة
يجب أن تتيح الأجهزة تغيير اتجاه الشاشة ديناميكيًا حسب التطبيقات ليكون إما رأسيًا أو
أفقيًا. بمعنى آخر، يجب أن يلتزم الجهاز
بطلب التطبيق لاتجاه شاشة معيّن. يجوز لعمليات تنفيذ التطبيق اختيار
الاتجاه العمودي أو الأفقي كالإعداد التلقائي.
يجب أن تُبلغ الأجهزة عن القيمة الصحيحة لاتجاه الجهاز الحالي، عند
الاستعلام من خلال android.content.res.Configuration.orientation أو
android.view.Display.getOrientation() أو غيرها من واجهات برمجة التطبيقات.
يجب ألا تغيّر الأجهزة حجم الشاشة أو كثافتها المُبلّغ عنها عند تغيير
الاتجاه.
يجب أن تُبلغ الأجهزة عن اتجاهات الشاشة التي تتوافق معها (
android.hardware.screen.portrait و/أو android.hardware.screen.landscape)
ويجب أن تُبلغ عن اتجاه واحد على الأقل متوافق. على سبيل المثال، يجب أن يُبلغ الجهاز الذي يتضمّن شاشة
أفقية باتجاه ثابت، مثل التلفزيون أو الكمبيوتر اللابتوب، فقط عن
android.hardware.screen.landscape.
7.1.4. تسريع الرسومات ثنائية وثلاثية الأبعاد
يجب أن تكون عمليات تنفيذ التطبيقات متوافقة مع كلٍّ من OpenGL ES 1.0 و2.0، على النحو الموضَّح
والمفصَّل في مستندات "حِزم تطوير البرامج (SDK) لنظام Android". يجب أيضًا أن تتوافق عمليات تنفيذ التطبيق على الأجهزة مع
Android Renderscript، على النحو الموضَّح في مستندات حزمة تطوير برامج Android
[المراجع، 8].
يجب أيضًا أن تحدِّد عملياتتنفيذ الأجهزة بوضوح أنها تتوافق مع
OpenGL ES 1.0 و2.0. أي أنّه:
يجب أن تُبلغ واجهات برمجة التطبيقات المُدارة (مثل تلك التي تُستخدَم من خلال الطريقة GLES10.getString())
بإمكانية استخدام OpenGL ES 1.0 و2.0
يجب أن تُبلغ واجهات برمجة التطبيقات الأصلية للغة C/C++ OpenGL (أي تلك المتوفّرة للتطبيقات من خلال
libGLES_v1CM.so أو libGLES_v2.so أو libEGL.so)
بإمكانية استخدام OpenGL ES 1.0 و2.0.
يجوز لعمليات تنفيذ التطبيقات على الأجهزة تنفيذ أي إضافات OpenGL ES مطلوبَة.
ومع ذلك، يجب على عمليات تنفيذ التطبيقات على الأجهزة الإبلاغ من خلال واجهات برمجة التطبيقات المُدارة و
المُضمّنة في OpenGL ES عن جميع سلاسل الإضافات التي تتوافق معها، وعلى العكس من ذلك، يجب عدم الإبلاغ عن
سلاسل الإضافات التي لا تتوافق معها.
يُرجى العلم أنّ Android 4.1 يتضمّن دعمًا للتطبيقات لتحديد ما إذا كانت
تتطلّب تنسيقات ضغط معيّنة لبنية OpenGL. وهذه التنسيقات هي عادةً
خاصة بالمورّدين. لا يتطلّب نظام Android 4.1 من عمليات تنفيذ التطبيقات استخدام
أي تنسيق معيّن لضغط الصور. ومع ذلك، يجب الإبلاغ بدقة عن أيّ
تنسيقات ضغط للبنية تتيحها الوحدة، من خلال الطريقة getString() في
OpenGL API.
يحتوي Android 4.1 على آلية للتطبيقات للإعلان عن أنّها تريد
تفعيل التسريع المعالج لرسومات 2D على مستوى التطبيق أو النشاط أو النافذة أو
مستوى العرض من خلال استخدام علامة بيان android:hardwareAccelerated أو
طلبات بيانات البرمجة المباشرة [Resources, 9].
في Android 4.1، يجب أن تفعِّل عمليات تنفيذ التطبيقات على الأجهزة ميزة "تسريع الأجهزة" بشكلٍ
تلقائي، ويجب إيقاف ميزة "تسريع الأجهزة" إذا طلب المطوِّر ذلك من خلال
ضبط android:hardwareAccelerated="false" أو إيقاف ميزة "تسريع الأجهزة"
مباشرةً من خلال واجهات برمجة تطبيقات Android View.
بالإضافة إلى ذلك، يجب أن تُظهر عمليات تنفيذ الأجهزة سلوكًا متوافقًا مع مستندات Android
SDK حول تسريع الأجهزة [المراجع، 9].
يحتوي Android 4.1 على عنصر TextureView الذي يتيح للمطوّرين دمج
ملفات الاستنساخ OpenGL ES المعزّزة بالأجهزة بشكل مباشر كأهداف لعرض الرسوم في تدرّج واجهة المستخدم.
يجب أن تتوافق عمليات تنفيذ التطبيقات على الأجهزة مع واجهة برمجة تطبيقات TextureView، و يجب أن تظهر

سلوكًا متسقًا مع عمليات تنفيذ Android الأساسية.
7.1.5. وضع التوافق مع التطبيقات القديمة
يحدّد Android 4.1 "وضع التوافق" الذي يعمل فيه إطار العمل في وضع
حجم شاشة "عادي" (بعرض 320dp) لمصلحة
التطبيقات القديمة التي لم تُطوَّر لإصدارات Android القديمة التي تعود إلى ما قبل استقلالية
حجم الشاشة. يجب أن تتضمن عمليات تنفيذ التطبيقات على الأجهزة إمكانية استخدام
وضع التوافق مع التطبيقات القديمة على النحو المنفَّذ من خلال رمز Android المفتوح المصدر. بمعنى آخر،
يجب ألا تغيّر عمليات تنفيذ الأجهزة العوامل المشغِّلة أو الحدود الحدّية التي يتم عندها تفعيل
وضع التوافق، وألّا تغيّر سلوك
وضع التوافق نفسه.
7.1.6. أنواع الشاشة
يتم تصنيف شاشات تنفيذ الأجهزة على أنّها نوعان:
عمليات تنفيذ شاشة البكسل الثابت: تكون الشاشة لوحة واحدة تتيح
عرض عرض وارتفاع بكسل واحد فقط. وعادةً ما تكون الشاشة مدمجة
بالجهاز. ومن الأمثلة على ذلك الهواتف الذكية والأجهزة اللوحيّة وما إلى ذلك.
عمليات تنفيذ شاشة العرض المتغيّرة الكثافة: إما أنّ تنفيذ الجهاز لا يتضمّن
شاشة مضمّنة ويتضمّن منفذ إخراج فيديو مثل VGA أو HDMI أو
منفذ لاسلكي لعرض الفيديو، أو أنّه يتضمّن شاشة مضمّنة يمكنها تغيير أبعاد
البكسل. ومن الأمثلة على ذلك أجهزة التلفزيون وأجهزة الاستقبال الرقمية وما إلى ذلك.
عمليات تنفيذ الأجهزة المزوّدة بوحدات بكسل ثابتة
يجوز أن تستخدم عمليات تنفيذ الأجهزة المزوّدة بوحدات بكسل ثابتة شاشات بأي أبعاد لوحدات البكسل،
شرط أن تستوفي المتطلبات المحدّدة في تعريف التوافق.
قد تتضمن عمليات تنفيذ الشاشة المزوّدة بوحدات بكسل ثابتة منفذ إخراج فيديو للاستخدام مع شاشة
خارجية. ومع ذلك، إذا تم استخدام هذه الشاشة لتشغيل التطبيقات، يجب أن يستوفي الجهاز
المتطلبات التالية:
يجب أن يُبلغ الجهاز عن إعدادات الشاشة ومقاييس العرض نفسها، كما هو موضّح بالتفصيل في الفقرة 7.1.1 والفقرة 7.1.2، مثل شاشة النقاط الثابتة.
يجب أن يُبلغ الجهاز عن الكثافة اللوجستية نفسها مثل شاشة النقاط الثابتة.
يجب أن يُبلغ الجهاز عن أبعاد الشاشة نفسها أو أبعاد قريبة جدًا
من شاشة النقاط الثابتة.

على سبيل المثال، يُعتبر الجهاز اللوحي الذي يبلغ حجمه أفقيًا 7 بوصة ودرجة دقة الشاشة فيه 1024×600 بكسل
شاشة كبيرة بكثافة بكسل متوسطة (mdpi) مزوّدة بوحدات بكسل ثابتة. إذا كان يحتوي على منفذ
إخراج فيديو يعرض بدقة 720p أو 1080p، يجب أن يُجري الجهاز عملية تصغير
للإخراج كي لا يتم تنفيذ التطبيقات إلا في نافذة كبيرة بكثافة بكسل متوسطة، بغض النظر عن
ما إذا كان يتم استخدام شاشة البكسل الثابت أو منفذ إخراج الفيديو.
عمليات تنفيذ الأجهزة المزوّدة بوحدات بكسل متغيرة
يجب أن تتوافق عمليات تنفيذ الأجهزة المزوّدة بوحدات بكسل متغيرة مع دقة 1280×720 أو
1920×1080 (أي 720p أو 1080p). يجب ألا تتيح عمليات تثبيت الأجهزة التي تستخدم
شاشات بوحدات بكسل متغيرة أي إعداد أو وضع شاشة آخرَين. قد تؤدي عمليات
تنفيذ الأجهزة التي تستخدم شاشات بوحدات بكسل متغيرة إلى تغيير إعدادات الشاشة أو
وضعها أثناء وقت التشغيل أو وقت التشغيل. على سبيل المثال، قد يحلّ مستخدم وحدة تحكم في الوسائط
شاشة بدقة 720p بشاشة بدقة 1080p، وقد يتم تعديل عمل الجهاز
وفقًا لذلك.
بالإضافة إلى ذلك، يجب أن تُبلغ عمليات تنفيذ الأجهزة التي تتضمّن أبعاد متغيرة لوحدات البكسل عن المجموعات التالية
للإعدادات لهذه الأبعاد لوحدات البكسل:
1280x720 (المعروفة أيضًا بـ 720p): حجم شاشة "كبير"، كثافة "tvdpi" (213 نقاط في الملليمتر)
1920x1080 (المعروفة أيضًا بـ 1080p): حجم شاشة "كبير"، كثافة "xhdpi" (320 نقاط في الملليمتر)
للتوضيح، إنّ عمليات تنفيذ الأجهزة التي تتضمّن أبعادًا متغيرة لوحدات البكسل محدودة ب
720p أو 1080p في Android 4.1، ويجب ضبطها لإبلاغ عن حجم الشاشة ومجموعات
الكثافة على النحو المذكور أعلاه.
7.1.7. تكنولوجيا الشاشة
تتضمّن منصّة Android واجهات برمجة تطبيقات تسمح للتطبيقات بعرض رسومات غنية على
الشاشة. يجب أن تتوافق الأجهزة مع جميع واجهات برمجة التطبيقات هذه على النحو المحدّد من خلال حزمة تطوير برامج (SDK) لنظام Android
ما لم يُذكر خلاف ذلك بشكل واضح في هذا المستند. على وجه التحديد:
يجب أن تكون الأجهزة متوافقة مع الشاشات القادرة على عرض الرسومات الملوّنة بدقة 16 بت، و
يجب أن تكون متوافقة مع الشاشات القادرة على عرض الرسومات الملوّنة بدقة 24 بت.
يجب أن تكون الأجهزة متوافقة مع الشاشات القادرة على عرض الرسومات المتحركة.
يجب أن تكون تكنولوجيا الشاشة المستخدَمة ذات نسبة عرض إلى ارتفاع بكسل (PAR) تتراوح بين 0.9

و1.1. أي أنّ نسبة عرض إلى ارتفاع البكسل يجب أن تكون قريبة من المربّع (1.0) مع سماح بنسبة خطأ%10
.
7.2. أجهزة الإدخال
7.2.1. لوحة المفاتيح
عمليات التثبيت على الأجهزة:
يجب أن تتضمن دعمًا لإطار عمل إدارة الإدخال (الذي يتيح ل
المطوّرين الطرف الثالث إنشاء محركات إدارة الإدخال، أي لوحة المفاتيح البرمجية) على النحو الموضّح في http://developer.android.com
يجب أن توفّر عملية تثبيت واحدة على الأقل لوحة مفاتيح برمجية (بغض النظر عمّا إذا كانت لوحة مفاتيح معدّية)
يجوز أن تتضمن عمليات تثبيت لوحة مفاتيح برمجية إضافية
يجوز أن تتضمن لوحة مفاتيح معدّة
يجب ألا تتضمن لوحة مفاتيح معدّة لا تطابق أحد التنسيقات
المحدّدة في android.content.res.Configuration.keyboard [Resources, 40]
(أي QWERTY أو 12 مفتاحًا)
7.2.2.

التنقّل بدون لمس
عمليات تنفيذ الأجهزة:
يجوز حذف خيار تنقّل بدون لمس (أي يجوز حذف كرة التتبّع أو أداة التوجيه أو
العجلة)
يجب إدخال القيمة الصحيحة ل
android.content.res.Configuration.navigation [Resources, 40]
يجب توفير آلية بديلة معقولة لواجهة المستخدم لاختيار النص وتعديله
، متوافقة مع محرّكات إدارة الإدخال. يحتوي
الإصدار الأساسي من برنامج Android المفتوح الرمز المصدر على آلية اختيار
مناسبة للاستخدام مع الأجهزة التي لا تتضمّن إدخالات تنقّل غير اللمسية.
7.2.3. مفاتيح التنقّل
وظائف الصفحة الرئيسية والقائمة والرجوع أساسية لنموذج التنقّل في Android
. يجب أن تتيح عمليات تنفيذ التطبيقات على الأجهزة هذه الوظائف للمستخدم
في جميع الأوقات عند تشغيل التطبيقات. يجوز تنفيذ هذه الوظائف من خلال
أزرار مخصّصة للأجهزة (مثل الأزرار الميكانيكية أو أزرار اللمس الاستاتيكية)، أو يجوز
تنفيذها باستخدام مفاتيح برامج مخصّصة وإيماءات وشاشة لمس وغير ذلك. يتوافق نظام Android
4.1 مع كلا طريقتَي التنفيذ.
يتيح الإصدار 4.1 من نظام Android استخدام الإجراءات المساعدة [Resources, 63]. يجب أن تتيح
عمليات التثبيت على الأجهزة إجراء المساعدة للمستخدم في جميع الأوقات عند
تشغيل التطبيقات. يجوز تنفيذ هذه الوظيفة من خلال مفاتيحالأجهزة أو البرامج
.
يجوز لعمليات تنفيذ التطبيقات استخدام جزء مميّز من الشاشة لعرض
مفاتيح التنقّل، ولكن في هذه الحالة، يجب استيفاء المتطلبات التالية:
يجب أن تستخدم عمليات تنفيذ التطبيقات مفتاحَي التنقّل في جزء مميّز من
الشاشة، غير متاح للتطبيقات، ويجب ألا تُخفي أو
تداخل مع الجزء من الشاشة المتاح للتطبيقات.
يجب أن توفّر عمليات تنفيذ التطبيقات جزءًا من الشاشة
للتطبيقات التي تستوفي المتطلبات المحدّدة في الفقرة 7.1.1.
يجب أن تعرض عمليات تنفيذ التطبيقات مفاتيح التنقّل عندما لا
تحدّد التطبيقات وضع واجهة مستخدم النظام، أو تحدّد SYSTEM_UI_FLAG_VISIBLE.
يجب أن تعرض عمليات تنفيذ التطبيقات مفاتيح التنقّل في وضع"منخفض الظهور" (مثل مطفأ) غيرمزعِج
عندما تحدّد التطبيقات
SYSTEM_UI_FLAG_LOW_PROFILE.
يجب أن تخفي عمليات تنفيذ التطبيقات مفاتيح التنقّل عندما تحدّد التطبيقات SYSTEM_UI_FLAG_HIDE_NAVIGATION.
يجب أن تعرِض عمليات تنفيذ التطبيقات مفتاح القائمة للتطبيقات عندما يكون
targetSdkVersion <= 10 ويجب ألا تعرِض مفتاح القائمة عندما يكون
targetSdkVersion > 10.
يجب أن توفّر عمليات تنفيذ التطبيقات جزءًا من الشاشة ل
التطبيقات التي تستوفي المتطلبات المحدّدة في الفقرة 7.1.1.

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

تتضمّن نظام إدخال مؤشر:
يجب أن تتيح إمكانية تتبُّع المؤشرات بشكل كامل ومستقل، إذا كان نظام إدخال الجهاز
يتوافق مع مؤشرات متعدّدة
يجب إدراج قيمة android.content.res.Configuration.touchscreen
[Resources, 40] cالمتوافقة مع نوع شاشة اللمس المحددة على
الجهاز
يتضمن Android 4.0 توافقًا مع مجموعة متنوعة من شاشات اللمس واللوحات اللمس وأجهزة إدخال اللمس
المزيفة. ترتبط عمليات تنفيذ الأجهزة التي تعتمد على الشاشة اللمسية ب
شاشة [Resources, 71] بحيث يحصل المستخدم على انطباع بإمكانية التعامل مباشرةً مع
العناصر على الشاشة. بما أنّ المستخدم يلمس الشاشة مباشرةً، لا يحتاج النظام
إلى أي عناصر إضافية للإشارة إلى العناصر التي يتم التلاعب بها. في
المقابل، توفّر واجهة اللمس الزائفة نظامًا لإدخال المستخدم يشبه
مجموعة فرعية من إمكانات الشاشة اللمسية. على سبيل المثال، يُعدّ الماوس أو جهاز التحكّم عن بُعد الذي يشغِّل
مؤشرًا على الشاشة أقرب إلى اللمس، ولكنه يتطلّب من المستخدم الإشارة أو التركيز أولاً
ثم النقر. تتيح العديد من أجهزة الإدخال، مثل الماوس ولوحة اللمس والفأرة الهوائية المستندة إلى أداة الاستشعار الدوراني
ومؤشر أداة الاستشعار الدوراني وعصا التحكم ولوحة اللمس المتعدّدة اللمس، التفاعلات التي تعتمد على لمسة زائفة.يتضمّن الإصدار 4.0 من نظام التشغيل 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 للشاشة لمكان المؤشر و
تعرض مؤشرًا بصريًا على الشاشة[Resources, 70]
يجب أن تُبلغ عن حدث اللمس باستخدام رمز الإجراء [Resources, 70] الذي يحدّد
تغيير الحالة الذي يحدث للمؤشر عندالانتقال للأسفل أو لأعلى على الشاشة
[Resources, 70]
يجب أن تتوافق مع مؤشر الانتقال للأسفل أو لأعلى على جسم على الشاشة، ما يسمح
لمستخدمي الجهاز بمحاكاة النقر على جسم على الشاشة
يجب أن تتوافق مع مؤشر الانتقال للأسفل أو لأعلى ثم الانتقال للأسفل أو لأعلى في المكان
نفسه على جسم على الشاشة خلال حدّ وقتي، ما يسمح
لمستخدمي الجهاز بمحاكاة النقر المرّتين على جسم على الشاشة [Resources, 70]
يجب أن تتوافق مع مؤشر الانتقال للأسفل على نقطة عشوائية على الشاشة، وانتقال المؤشر إلى
أي نقطة عشوائية أخرى على الشاشة، ثم الانتقال للأسفل على الشاشة، ما يسمح
لمستخدمي الجهاز بمحاكاة السحب باللمس
يجب أن تتوافق مع مؤشر الانتقال للأسفل ثم السماح للمستخدمين بتحريك الجسم بسرعة إلى
موضع مختلف على الشاشة ثم الانتقال للأسفل على الشاشة، ما يسمح
لمستخدمي الجهاز برمي جسم على الشاشة
يجب أن تستوفي الأجهزة التي تعلن عن توافقها مع android.hardware.faketouch.multitouch.distinct
المتطلبات الخاصة بلمسات الشاشة المزيفة المذكورة أعلاه، ويجب أن تتوافق أيضًا مع ميزة
التتبّع الواضح لمدخلات مؤشرَين مستقلَّين أو أكثر.
7.2.6. الميكروفون
قد تحذف عمليات تنفيذ التطبيق الميكروفون. ومع ذلك، إذا تجاهلت إحدى عمليات تنفيذ الأجهزة
استخدام الميكروفون، يجب ألا تُبلغ عن ثابت الميزة android.hardware.microphone
، ويجب تنفيذ واجهة برمجة التطبيقات لتسجيل الصوت كعمليات لا تؤدي إلى أي إجراء، وفقًا للفقرة 7.
على العكس، في عمليات تنفيذ الأجهزة التي تستخدم الميكروفون:
يجب الإبلاغ عن ثابت الميزة android.hardware.microphone
يجب استيفاء متطلبات جودة الصوت في الفقرة 5.4
يجب استيفاء متطلبات وقت استجابة الصوت في الفقرة 5.5
7.3. أجهزة الاستشعار

يتضمّن الإصدار 4.1 من نظام Android واجهات برمجة تطبيقات للوصول إلى مجموعة متنوعة من أنواع أجهزة الاستشعار. قد تغفل عمليات
تنفيذ الأجهزة بشكل عام عن هذه أجهزة الاستشعار، على النحو الموضَّح في الفقرات الفرعية التالية
. إذا كان الجهاز يتضمّن نوعًا معيّنًا من أجهزة الاستشعار التي تمتلك واجهة برمجة تطبيقات مقابلة
للمطوّرين الجهات الخارجية، يجب أن ينفّذ الجهاز واجهة برمجة التطبيقات هذه على النحو
الموضّح في مستندات حزمة تطوير برامج Android SDK. على سبيل المثال، عمليات تنفيذ الأجهزة:
يجب الإبلاغ بدقة عن توفّر أدوات الاستشعار أو عدم توفّرها وفقًا للصفّة
android.content.pm.PackageManager. [الموارد، 37]
يجب عرض قائمة دقيقة لأجهزة الاستشعار المتوافقة من خلال
SensorManager.getSensorList() والطُرق المشابهة
يجب أن يعمل بشكل معقول مع جميع واجهات برمجة التطبيقات الأخرى لأجهزة الاستشعار (على سبيل المثال، من خلال عرض true
أو false حسب الضرورة عندما تحاول التطبيقات تسجيل المستمعين، وعدم استدعاء
مستمعي أجهزة الاستشعار عندما لا تكون أجهزة الاستشعار المقابلة متوفّرة، وما إلى ذلك)
يجب تسجيل جميع قياسات أجهزة الاستشعار باستخدام قيم النظام الدولي المعني
للوحدات (أي النظام المتري) لكل نوع من أنواع أجهزة الاستشعار على النحو الموضَّح في مستندات Android SDK
[الموارد، 41]
القائمة أعلاه ليست شاملة، ويجب اعتبار السلوك الموثَّق لـ Android SDK
موثوقًا.
تكون بعض أنواع الأجهزة الاستشعارية اصطناعية، أي يمكن استنتاجها من البيانات التي يوفّرها
جهاز استشعاري واحد أو أكثر. (تشمل الأمثلة جهاز استشعار الاتجاه وجهاز استشعار التسارع
الخطّي). يجب أن تنفِّذ عمليات تنفيذ الأجهزة هذه الأنواع من أجهزة
الاستشعار، عندما تتضمن أجهزة الاستشعار اللازمة.
توفّر واجهات برمجة التطبيقات لنظام Android 4.1 مفهومًا لجهاز استشعار "البث"، وهو جهاز
يعرض البيانات بشكل متواصل، وليس فقط عند تغيير البيانات. يجب أن تقدّم عمليات تنفيذ الأجهزة
بشكل متواصل عيّنات بيانات دورية لأي واجهة برمجة تطبيقات
يُشار إلى أنّها جهاز استشعار بث في مستندات مجموعة تطوير البرامج (SDK) لنظام Android 4.1.
7.3.1. مقياس التسارع
يجب أن تتضمّن عمليات تنفيذ الأجهزة مقياس تسارع ثلاثي المحاور. إذا كان
تنفيذ الجهاز يتضمّن مقياس تسارع بثلاثة محاور، يجب أن:
يكون قادرًا على إرسال الأحداث بمعدل 120 هرتز أو أكثر. يُرجى ملاحظة أنّه على الرغم من أنّه قد تم تحديد
تردد مقياس التسارع أعلاه على أنّه "يجب" لنظام Android 4.1، من المخطَّط تغيير
تعريف التوافق لإصدار مستقبلي ليصبح
"يجب". بمعنى آخر، هذه المعايير اختيارية في Android 4.1 ولكن ستكون
مطلوبة في الإصدارات المستقبلية. ننصح
بشدة باستيفاء هذه المتطلبات في Android 4.1 على الأجهزة الحالية والجديدة التي تعمل بنظام Android 4.1 لكي
يتمكنوا من الترقية إلى إصدارات النظام المستقبلية
يجب أن تتوافق مع نظام إحداثيات أجهزة استشعار Android على النحو الموضَّح في
واجهات برمجة تطبيقات Android (راجِع [المراجع، 41])
يجب أن تكون قادرة على القياس من السقوط الحر حتى ضعف قوة الجاذبية (2g) أو أكثر على
أي ثلاثة متجهات ثلاثية الأبعاد
يجب أن تبلغ درجة الدقة 8 بت أو أكثر
يجب أن تبلغ الانحراف المعياري مقدارًا لا يتجاوز 0.05 م/ث^2
7.3.2. مقياس المغناطيسية
يجب أن تتضمّن عمليات تنفيذ الأجهزة مقياس مغناطيسية بثلاثة محاور (أي بوصلة). إذا كان
الجهاز يتضمّن مقياسًا مغناطيسيًا بثلاثة محاور، يجب أن:
يكون قادرًا على إرسال الأحداث بمعدل 10 هرتز أو أكثر
يجب أن يلتزم بنظام إحداثيات أجهزة استشعار Android على النحو الموضّح في
واجهات برمجة تطبيقات Android (راجِع [المراجع، 41]).
يجب أن يكون قادرًا على تحليل عيّنات من مجموعة من قِيَم شدة المجال المغناطيسي التي تكفي لتغطية
المجال المغناطيسي الأرضي
يجب أن يكون دقيقًا بدرجة 8 بت أو أكثر
يجب أن يكون مقياسًا مغناطيسيًا بمتوسط انحراف لا يزيد عن 0.5 µT
7.3.3. نظام تحديد المواقع العالمي (GPS)
يجب أن تتضمّن عمليات تنفيذ الأجهزة جهاز استقبال نظام تحديد المواقع العالمي (GPS). إذا كان تطبيق الجهاز
يتضمّن جهاز استقبال نظام تحديد الموقع الجغرافي، يجب أن يتضمّن بعض أشكال تقنية "نظام تحديد الموقع الجغرافي المساعد"
لتقليل وقت الربط بنظام تحديد الموقع الجغرافي.
7.3.4. الاستشعار الدوراني
يجب أن تتضمّن عمليات تنفيذ الأجهزة استشعارًا دورانيًا (أي أداة استشعار التغيير الزاوي).
يجب ألّا تتضمّن الأجهزة أداة استشعار دورانيًا ما لم يتم تضمين مقياس تسارع بثلاثة محاور
أيضًا. إذا تضمّن تطبيق الجهاز جهاز جيروسكوب، يجب أن:

يتم تصحيحه حسب درجة الحرارة
يجب أن يكون قادرًا على قياس تغييرات الاتجاه حتى 5.5*باي
راديان في الثانية (أي 1,000 درجة تقريبًا في الثانية)
يجب أن يكون قادرًا على إرسال الأحداث بمعدل 200 هرتز أو أكثر. يُرجى ملاحظة أنّه على الرغم من أنّ
تردد الجيروسكوب المذكور أعلاه مُدرَج على أنّه "يجب" لنظام Android 4.1، من المخطَّط تغيير
تعريف التوافق لإصدار مستقبلي ليصبح
"يجب". بمعنى آخر، هذه المعايير اختيارية في Android 4.1 ولكن ستكون
مطلوبة في الإصدارات المستقبلية. ننصح
بشدة باستيفاء هذه المتطلبات في Android 4.1 على الأجهزة الحالية والجديدة التي تعمل بنظام Android 4.1 لكي
يتمكن المستخدمون من الترقية إلى إصدارات النظام الأساسي المستقبلية.
يجب أن تبلغ درجة الدقة 12 بت أو أكثر
يجب أن لا يتجاوز التفاوت 1e-7 rad^2 / s^2 per Hz (التفاوت per Hz،
أو rad^2 / s). من المفترَض أن يتغيّر التباين حسب معدل التحليل، ولكن يجب أن يكون
محدودًا بهذه القيمة. بمعنى آخر، إذا كنت تقيس التباين في الاستشعار الدوّار
بمعدل أخذ عيّنات 1 هرتز، يجب ألا يكون أكبر من 1e-7 rad^2/s^2.
يجب أن تتضمّن طوابع زمنية أقرب ما يمكن إلى وقت حدوث الحدث في الأجهزة
. يجب إزالة وقت الاستجابة الثابت.
7.3.5. مقياس الضغط الجوي
قد تتضمن عمليات تنفيذ الأجهزة مقياس ضغط جويًا (أي أداة استشعار ضغط الهواء المحيط). إذا
تضمّن تطبيق الجهاز مقياس ضغط جويًا، يجب أن:
يكون قادرًا على إرسال الأحداث بمعدل 5 هرتز أو أكثر
يجب أن يكون دقيقًا بما يكفي للسماح بتقدير الارتفاع
يجب تصحيحه حسب درجة الحرارة
7.3.7. ميزان الحرارة
يجوز لعمليات تنفيذ الأجهزة استخدام ميزان حرارة (أي
جهاز استشعار درجة الحرارة)، ولكن لا ينبغي ذلك. إذا تضمّن تطبيق الجهاز مقياس حرارة، يجب
قياس درجة حرارة وحدة المعالجة المركزية للجهاز. ويجب ألا يقيس أي درجة
حرارة أخرى. (يُرجى العلم أنّه تم إيقاف نوع المستشعر هذا نهائيًا في واجهات برمجة تطبيقات Android 4.1.)
7.3.7. مقياس الإضاءة
يجوز أن تتضمّن عمليات تنفيذ الأجهزة مقياس الإضاءة (أي أداة استشعار الضوء المحيط).
7.3.8. أداة استشعار التقارب
قد تتضمن عمليات تنفيذ الأجهزة أداة استشعار التقارب. إذا كان تطبيق الجهاز
يتضمّن أداة استشعار تقارب، يجب قياس مدى قرب الجسم في
الاتجاه نفسه الذي تظهر فيه الشاشة. بمعنى آخر، يجب توجيه حساس المسافة لرصد
الأجسام القريبة من الشاشة، لأنّ الغرض الأساسي من هذا النوع من الحساسات هو رصد
الهاتف الذي يستخدِمه المستخدم. إذا تضمّن تنفيذ الجهاز مستشعر قرب باستخدام
أي اتجاه آخر، يجب عدم السماح بالوصول إلى هذا الجهاز من خلال واجهة برمجة التطبيقات هذه. إذا كان
تنفيذ الجهاز يحتوي على أداة استشعار تقارب، يجب أن يكون دقيقًا بدرجة بت واحد أو أكثر.
7.4. إمكانية الاتصال بالبيانات
7.4.1. الاتصال الهاتفي
"الاتصال الهاتفي" على النحو المستخدَم في واجهات برمجة تطبيقات Android 4.1 وهذا المستند يشير تحديدًا إلى
الأجهزة المرتبطة بإجراء المكالمات الصوتية وإرسال الرسائل القصيرة عبر شبكة GSM أو
CDMA. مع أنّ هذه المكالمات الصوتية قد تكون أو لا تكون مُدارة بتقنية تبديل الحِزم، يتم
لأغراض Android 4.1 اعتبارها مستقلة عن أي اتصال ببيانات
قد يتم تنفيذه باستخدام الشبكة نفسها. بمعنى آخر، تشير وظائف "الهاتف"
وواجهات برمجة التطبيقات في Android تحديدًا إلى المكالمات الصوتية والرسائل القصيرة. على سبيل المثال، يجب ألا تُبلغ
عمليات تنفيذ الأجهزة التي لا يمكنها إجراء مكالمات أو إرسال رسائل قصيرة أو تلقّيها عن ميزة "android.hardware.telephony" أو أي ميزات فرعية، بغض النظر عن
ما إذا كانت تستخدم شبكة جوّال لربط البيانات.

يجوز استخدام Android 4.1 على الأجهزة التي لا تتضمن معدات الاتصال الهاتفي. بمعنى آخر،
Android 4.1 متوافق مع الأجهزة التي ليست هواتف. ومع ذلك، إذا كان
تنفيذ الجهاز يتضمّن شبكة GSM أو CDMA للاتصالات، يجب أن يتضمّن الجهاز دعمًا شاملاً
لواجهة برمجة التطبيقات لهذه التكنولوجيا. يجب أن تنفِّذ عمليات تنفيذ الأجهزة التي لا تتضمن معدات الاتصال
واجهات برمجة التطبيقات الكاملة كعمليات لا تتطلّب تدخلًا.
7.4.2. IEEE 802.11 (WiFi)
يجب أن تتضمّن عمليات تثبيت أجهزة Android 4.1 إمكانية استخدام شكل واحد أو أكثر
من 802.11 (b/g/a/n وغير ذلك). إذا كان تنفيذ الجهاز يتضمّن دعمًا لبروتوكول 802.11،
يجب تنفيذ واجهة برمجة التطبيقات المقابلة لنظام Android.

يجب أن تُنفِّذ عمليات تنفيذ الأجهزة واجهة برمجة التطبيقات لميزة البث المتعدد على النحو الموضَّح في مستندات حزمة تطوير البرامج (SDK)
[الموارد، 62]. يجب أن تتوافقعمليات تنفيذ الأجهزة التي تتضمّن دعم Wi-Fi
مع نظام أسماء النطاقات البرمجي (mDNS). يجب ألا تفلتر عمليات تنفيذ الأجهزة حِزم mDNS
(224.0.0.251) في أي وقت من وقت العمل، بما في ذلك عندما لا تكون الشاشة في حالة
نشطة.
7.4.2.1. اتصال Wi-Fi المباشر
يجب أن تتضمّن عمليات تنفيذ الأجهزة إمكانية الاتصال بشبكة Wi-Fi المباشرة (Wifi peer-to-peer). إذا كان
تطبيق الجهاز يتضمّن إمكانية الاتصال بشبكة Wifi مباشرةً، يجب أن ينفّذ
واجهة برمجة تطبيقات Android المقابلة على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK) [المراجع، 68]. إذا
تضمّن تطبيق الجهاز دعمًا لشبكة Wifi Direct، يجب أن:
يكون متوافقًا مع عمل شبكة Wifi العادي
يجب أن يكون متوافقًا مع عمل شبكة Wifi وWifi Direct بالتزامن
7.4.3. البلوتوث
يجب أن تتضمّن عمليات تنفيذ الأجهزة جهاز إرسال واستقبال بلوتوث. يجب أن تتضمّن عمليات
تنفيذ الأجهزة التي تتضمّن جهاز إرسال واستقبال بلوتوث واجهة برمجة تطبيقات بلوتوث المستندة إلى
‏RFCOMM على النحو الموضّح في مستندات حِزم تطوير البرامج [المراجع، 42]. يجب أن تنفِّذ عمليات
تنفيذ الأجهزة ملفات البلوتوث ذات الصلة، مثل A2DP،
AVRCP، OBEX، وما إلى ذلك حسب ما يناسب الجهاز.
تتضمّن مجموعة أدوات اختبار التوافق حالات تغطي التشغيل الأساسي لواجهة برمجة تطبيقات Android
RFCOMM Bluetooth. ومع ذلك، بما أنّ البلوتوث هو بروتوكول اتصالات
بين الأجهزة، لا يمكن اختباره بشكل كامل من خلال اختبارات الوحدات التي تُجري على جهاز واحد.
نتيجةً لذلك، يجب أن تجتاز عمليات تنفيذ الأجهزة أيضًا إجراء اختبار البلوتوث
الذي يُجريه المستخدم والذي تم وصفه في الملحق (أ).
7.4.4. الاتصال القصير المدى
يجب أن تتضمن عمليات تنفيذ الأجهزة جهاز إرسال واستقبال ومعدات مرتبطة بتقنية
الاتصال القصير المدى (NFC). إذا تضمّن تطبيق الجهاز جهاز NFC
، يجب أن:
يُبلغ عن السمة android.hardware.nfc من الطريقة
android.content.pm.PackageManager.hasSystemFeature()‎.
[Resources, 37]
يجب أن يكون قادرًا على قراءة وكتابة رسائل NDEF من خلال المعايير التالية لتقنية
NFC:
يجب أن يكون قادرًا على التصرف بصفته قارئًا/كاتبًا في منتدى NFC (على النحو الذي حدّده
المواصفات الفنية لمنتدى NFC NFCForum-TS-DigitalProtocol-1.0)
من خلال المعايير التالية لتقنية
NFC:
NfcA (ISO14443-3A)
NfcB (ISO14443-3B)
NfcF (JIS 6319-4)
IsoDep (ISO 14443-4)
أنواع العلامات في منتدى NFC 1 و2 و3 و4 (حدّدها منتدى NFC)
يجب أن يكون قادرًا على قراءة وكتابة رسائل NDEF من خلال المعايير التالية
لتقنية NFC. يُرجى ملاحظة أنّه على الرغم من أنّ معايير NFC الموضَّحة أدناه مُدرَجة على أنّها
"يجب" لنظام Android 4.1، فإنّه من المخطَّط
تغيير هذه المعايير إلى "يجب" في الإصدارات المستقبلية. بمعنى آخر، هذه المعايير اختيارية في
Android 4.1 ولكن ستكون مطلوبة في الإصدارات المستقبلية. ننصح بشدة باستيفاء هذه
المتطلبات في Android 4.1 على الأجهزة الحالية والجديدة
التي تعمل بنظام Android 4.1 لكي تتمكّن من الترقية إلى إصدارات
النظام الأساسي المستقبلية.
يجب أن تكون تقنية NfcV‏ (ISO‏ 15693)
قادرة على إرسال البيانات واستلامها من خلال المعايير والبروتوكولات التالية بين الأجهزة المشابهة
:
ISO‏ 18092
LLCP‏ 1.0 (حدّده منتدى NFC)
SDP‏ 1.0 (حدّده منتدى NFC)
بروتوكول دفع NDEF [المراجع، 43]
SNEP‏ 1.0 (حدّده منتدى NFC)
يجب أن تتضمّن تقنية NfcV إمكانية استخدام تقنية Android Beam‏ [المراجع، 65]:
يجب أن توفّر تقنية NfcV إمكانية استخدام خادم SNEP التلقائي. يجب إرسال رسائل NDEF الصالحة
التي يتلقّاها خادم SNEP التلقائي إلى التطبيقات
باستخدام Intent android.nfc.ACTION_NDEF_DISCOVERED. يجب ألا يؤدي إيقاف
Android Beam في الإعدادات إلى إيقاف إرسال رسالة NDEF
الواردة.
يجب أن تلتزم عمليات تنفيذ التطبيقات بهدف
android.settings.NFCSHARING_SETTINGS لعرض إعدادات مشاركة NFC

[Resources, 67].
يجب تنفيذ خادم NPP. يجب
معالجة الرسائل التي يتلقّاها خادم NPP
بالطريقة نفسها التي يعالج بها خادم SNEP التلقائي.
يجب تنفيذ عميل SNEP ومحاولة إرسال حزمة NDEF للاتصال المباشر
إلى خادم SNEP التلقائي عند تفعيل Android Beam. إذا لم يتم العثور على خادم
SNEP تلقائي، يجب على العميل محاولة الإرسال إلى خادم
NPP.
يجب السماح للأنشطة الأولوية بضبط رسالة NDEF P2P المُرسَلة
باستخدام android.nfc.NfcAdapter.setNdefPushMessage، و
android.nfc.NfcAdapter.setNdefPushMessageCal back، و
android.nfc.NfcAdapter.enableForegroundNdefPush.
يجب استخدام إيماءة أو تأكيد على الشاشة، مثل "اللمس ل
الربط"، قبل إرسال رسائل NDEF P2P المُرسَلة.
يجب تفعيل Android Beam تلقائيًا.
يجب أن تتوافق مع تسليم اتصال NFC إلى البلوتوث عندما يكون الجهاز
متوافقًا مع ملف البروتوكول Bluetooth Object Push Profile. يجب أن تتيح عمليات تنفيذ الأجهزة
تسليم الاتصال إلى البلوتوث عند استخدام
android.nfc.NfcAdapter.setBeamPushUris، من خلال تنفيذ مواصفات
"تسليم الاتصال الإصدار 1.2" [المراجع، 60] و "إقران Bluetooth آمن
بسيط باستخدام NFC الإصدار 1.0" [المراجع، 61] من
NFC Forum. يستخدم هذا التطبيق الخاص بنقل البيانات اللاسلكي (SHO)ULD طلبات SNEP GET
لتبادل طلب التسليم / اختيار السجلات عبر NFC، و
يجب استخدام ملف البروتوكول لدفع العناصر عبر البلوتوث لنقل بيانات البلوتوث
الفعلية.
يجب البحث عن جميع التقنيات المتوافقة أثناء استخدام وضع اكتشاف NFC.
يجب استخدام وضع اكتشاف NFC عندما يكون الجهاز مشغّلاً وشاشة
نشطة وقفل الشاشة غير مُقفَل.
(يُرجى العِلم أنّ الروابط المتاحة للجميع غير متوفّرة لمواصفات JIS وISO وNFC Forum
المذكورة أعلاه.)
بالإضافة إلى ذلك، قد تتضمن عمليات تنفيذ الأجهزة إمكانية استخدام قارئ/كاتب لتقنيات
MIFARE التالية.
MIFARE Classic (NXP MF1S503x [Resources, 44], MF1S703x [Resources, 44])
MIFARE Ultralight (NXP MF0ICU1 [Resources, 46], MF0ICU2 [Resources, 46])
NDEF على MIFARE Classic (NXP AN130511 [Resources, 48], AN130411
[Resources, 49])
يُرجى العِلم أنّ Android 4.1 يتضمّن واجهات برمجة التطبيقات لأنواع MIFARE هذه. إذا كان
تنفيذ الجهاز يتوافق مع MIFARE في دور القارئ/الكاتب، يجب أن:
يجب تنفيذ واجهات برمجة التطبيقات المتوافقة مع Android على النحو الموضَّح في
حِزم تطوير البرامج (SDK) لنظام Android
يجب الإبلاغ عن الميزة com.nxp.mifare من الطريقة
android.content.pm.PackageManager.hasSystemFeature()‎.
[Resources, 37] يُرجى العِلم أنّ هذه الميزة ليست ميزة قياسية في Android، وبالتالي
لا تظهر كقيمة ثابتة في فئة PackageManager.
يجب عدم تنفيذ واجهات برمجة التطبيقات المتوافقة مع Android أو الإبلاغ عن ميزة
com.nxp.mifare ما لم يتم تنفيذ دعم NFC بشكل عام على النحو
الموضَّح في هذا القسم.
إذا لم تتضمن طريقة تنفيذ الجهاز معدات NFC، يجب عدم تحديد
android.hardware.nfc الميزة من
android.content.pm.PackageManager.hasSystemFeature() الطريقة [Resources, 37]
ويجب تنفيذ واجهة برمجة التطبيقات NFC في Android 4.1 كإجراء غير ذي فائدة.
بما أنّ فئتَي android.nfc.NdefMessage وandroid.nfc.NdefRecord تمثّلان
تنسيقًا لتمثيل البيانات لا يعتمد على بروتوكول، يجب أن تنفِّذ عمليات تنفيذ الأجهزة
واجهات برمجة التطبيقات هذه حتى إذا لم تتضمن دعمًا لتقنية NFC أو لم تحدِّد ميزة
android.hardware.nfc.
7.4.5. الحدّ الأدنى لإمكانية الاتصال بالشبكة
يجب أن تتضمن عمليات تنفيذ الأجهزة إمكانية استخدام شكل واحد أو أكثر من أشكال
الاتصال بالشبكة. وبالتحديد، يجب أن تتضمن عمليات تنفيذ الأجهزة توافقًا مع
معيار بيانات واحد على الأقل يمكنه نقل 200 كيلوبت في الثانية أو أكثر. ومن أمثلة التقنيات التي
تستوفي هذا المتطلب EDGE وHSPA وEV-DO و802.11g وEthernet وما إلى ذلك.
يجب أيضًا أن تتضمّن عمليات تنفيذ الأجهزة التي يكون فيها معيار الشبكة المادي (مثل Ethernet)
الاتصال الأساسي بالبيانات إمكانية استخدام
معيار بيانات لاسلكي شائع واحد على الأقل، مثل 802.11 (WiFi).
يجوز للأجهزة استخدام أكثر من شكل واحد لربط البيانات.

7.5. الكاميرات
يجب أن تتضمّن عمليات تثبيت الأجهزة كاميرا خلفية، وقد تتضمّن
كاميرا أمامية. الكاميرا الخلفية هي كاميرا تقع على جانب
الجهاز المقابل للشاشة، أي أنّها تصوّر المشاهد على الجانب الخلفي من الجهاز، مثل
الكاميرا التقليدية. الكاميرا الأمامية هي كاميرا تقع على الجانب نفسه من
الجهاز الذي تقع عليه الشاشة، أي كاميرا تُستخدَم عادةً لتصوير المستخدم، مثل
مؤتمرات الفيديو والتطبيقات المشابهة.
7.5.1. الكاميرا الخلفية
يجب أن تتضمّن عمليات تثبيت الأجهزة كاميرا خلفية. إذا كان
تنفيذ الجهاز يتضمّن كاميرا خلفية، يجب أن:
يكون بدقة لا تقل عن ميغابيكسلَين
يجب أن يكون مزوّدًا بميزة التركيز التلقائي البرمجي أو التركيز التلقائي الأجهزة
في برنامج تشغيل الكاميرا (شفّاف لبرنامج التطبيق)
يمكن أن يكون مزوّدًا بميزة التركيز الثابت أو ميزة EDOF (عمق مجال موسّع)
يمكن أن يتضمّن فلاشًا. إذا كانت الكاميرا تتضمّن فلاشًا، يجب عدم
إضاءة مصباح الفلاش أثناء تسجيل مثيل android.hardware.Camera.PreviewCal في الخلفية
على سطح معاينة الكاميرا، ما لم يفعِّل التطبيق
بوضوح الفلاش من خلال تفعيل السمة FLASH_MODE_AUTO أو FLASH_MODE_ON
لعنصر Camera.Parameters. يُرجى العِلم أنّ هذا القيود لا ينطبق على
تطبيق كاميرا النظام المضمّن في الجهاز، ولكن على التطبيقات التابعة لجهات خارجية فقط
التي تستخدِم Camera.PreviewCallback.
7.5.2. الكاميرا الأمامية
يجوز أن تتضمّن عمليات تثبيت الأجهزة كاميرا أمامية. إذا كان تطبيق الجهاز
يتضمّن كاميرا أمامية، يجب أن:
يكون بدقة VGA على الأقل (أي 640×480 بكسل)
يجب ألا يستخدِم الكاميرا الأمامية كالكاميرا التلقائية لواجهة برمجة تطبيقات الكاميرا. بمعنى آخر،
تتوفّر واجهة برمجة التطبيقات للكاميرا في Android 4.1 لتوفير دعم محدّد للكاميرات الأمامية، و
يجب عدم ضبط عمليات تنفيذ الجهاز لواجهة برمجة التطبيقات لمعالجة
الكاميرا الأمامية كالكاميرا الخلفية التلقائية، حتى إذا كانت هي الكاميرا الوحيدة في
الجهاز.
يجوز تضمين ميزات (مثل التركيز التلقائي والفلاش وما إلى ذلك) متوفّرة للكاميرات الخلفية
كما هو موضّح في الفقرة 7.5.1.
يجب عرض البث الذي يعرضه أحد التطبيقات في
CameraPreview بشكل معكوس أفقيًا (أي بطريقة مرآة)، على النحو التالي:
إذا كان بإمكان المستخدم تدوير الجهاز (مثلاً
تلقائيًا من خلال مقياس التسارع أو يدويًا من خلال إدخال المستخدم)، يجب عرض
معاينة الكاميرا بشكل معكوس أفقيًا بالنسبة إلى
اتجاه الجهاز الحالي.
إذا طلب التطبيق الحالي بوضوح
تدوير شاشة الكاميرا من خلال استدعاء
android.hardware.Camera.setDisplayOrientation() [Resources, 50]
الطريقة، يجب عرض
معاينة الكاميرا بشكل معكوس أفقيًا بالنسبة إلى
الاتجاه الذي حدّده التطبيق.
بخلاف ذلك، يجب عرض معاينة الكاميرا بشكل معكوس على طول
المحور الأفقي التلقائي للجهاز.
يجب أن تعكس الصورة المعروضة في معاينة المشاركة بالطريقة نفسها مثل
بث صورة معاينة الكاميرا. (إذا لم تسمح طريقة تنفيذ التطبيق
بعرض الصور بعد تسجيلها، من الواضح أنّ هذا المتطلب لا ينطبق.)
يجب عدم مطابقة الصورة الثابتة أو بث الفيديو النهائي المُسجَّل الذي يتم إرساله إلى
عمليات الحفظ في التطبيق أو إرساله إلى مساحة تخزين الوسائط
7.5.3. سلوك Camera API
يجب أن تتضمّن عمليات تنفيذ الأجهزة السلوكيات التالية لواجهات برمجة التطبيقات المتعلّقة بالكاميرا
، لكلٍّ من الكاميرات الأمامية والخلفية:
1-  إذا لم يسبق لتطبيق استخدام
android.hardware.Camera.Parameters.setPreviewFormat(int)، يجب على
الجهاز استخدام android.hardware.PixelFormat.YCbCr_420_SP لعرض
البيانات التي يتم تقديمها لعمليات الاستدعاء في التطبيق.
2.  إذا سجّل التطبيق مثيلًا لـ android.hardware.Camera.PreviewCallback
وطلب النظام استخدام الطريقة onPreviewFrame() عندما يكون تنسيق العرض
هو YCbCr_420_SP، يجب أن تكون البيانات في السلسلة byte[] المُرسَلة إلى onPreviewFrame()
بالإضافة إلى ذلك بتنسيق ترميز NV21. أي أنّه يجب أن يكون NV21 هو الإعداد التلقائي.
3.  يجب أن تتوافق عمليات تنفيذ الأجهزة مع تنسيق YV12 (كما هو موضح في الثابت

android.graphics.ImageFormat.YV12) لمعاينات الكاميرا في كلٍّ من
الكاميرات الأمامية والخلفية. (يمكن لجهاز فك ترميز الفيديو والكاميرا
استخدام أي تنسيق أصلي للبكسل، ولكن يجب أن يتيح تطبيق الجهاز
التحويل إلى YV12).
يجب أن تتضمّن عمليات تنفيذ الأجهزة واجهة برمجة التطبيقات الكاملة لكاميرا Android المضمّنة في مستندات حزمة SDK لنظام Android
4.1 [Resources, 51]،بغض النّظر عمّا إذا كان الجهاز يتضمّن
إمكانية ضبط التركيز التلقائي بالأجهزة أو إمكانات أخرى. على سبيل المثال، يجب أن تستدعي الكاميرات التي لا تستخدم ميزة ضبط التركيز التلقائي
أي مثيل مسجَّل من android.hardware.Camera.AutoFocusCallback
(على الرغم من أنّ هذا لا علاقة له باستخدام كاميرا لا تستخدم ميزة ضبط التركيز التلقائي). يُرجى العِلم أنّ
هذا ينطبق على الكاميرات الأمامية، على سبيل المثال، على الرغم من أنّ معظم الكاميرات الأمامية
لا توفّر ميزة ضبط التركيز التلقائي، يجب أن تظل عمليات الاستدعاء لواجهة برمجة التطبيقات "مزوّرة" على النحو
الموضّح.
يجب أن تتعرّف عمليات تنفيذ الأجهزة على كل اسم مَعلمة محدَّد على أنّه
ثابت في فئة android.hardware.Camera.Parameters، إذا كان
الجهاز الأساسي يتوافق مع الميزة. إذا لم تتوافق إحدى الميزات مع معدات الجهاز، يجب أن تتصرف
واجهة برمجة التطبيقات على النحو الموضَّح في المستندات. بالمقابل، يجب ألا تلتزم عمليات تنفيذ الأجهزة
بقواعد أو تتعرّف على ثوابت السلسلة المُرسَلة إلى
الطريقة android.hardware.Camera.setParameters() باستثناء تلك المُوثَّقة ك
ثوابت في android.hardware.Camera.Parameters. بمعنى آخر، يجب أن تتوافق عمليات تنفيذ
الأجهزة مع جميع مَعلمات الكاميرا العادية إذا سمح الجهاز
بذلك، ويجب ألا تتوافق مع أنواع مَعلمات الكاميرا المخصّصة.
يجب أن تبث عمليات تنفيذ التطبيقات على الأجهزة Intent Camera.ACTION_NEW_PICTURE
عند التقاط صورة جديدة بالكاميرا وإضافة إدخال الصورة
إلى متجر الوسائط.
يجب أن تبث عمليات تنفيذ التطبيقات على الأجهزة هدف Camera.ACTION_NEW_VIDEO
عند تسجيل فيديو جديد بالكاميرا وإضافة إدخال الصورة
إلى متجر الوسائط.
7.5.4. اتجاه الكاميرا
يجب توجيه كل من الكاميرا الأمامية والكاميرا الخلفية، في حال توفّرهما، بحيث تتعامد الجانب
الطولي للكاميرا مع الجانب الطولي للشاشة. أي أنّه عند حمل
الجهاز في الوضع الأفقي، يجب أن تلتقط الكاميرات الصور في
الوضع الأفقي. ينطبق هذا بغض النّظر عن اتجاه الجهاز الطبيعي، أي
ينطبق على الأجهزة التي يكون اتجاهها الأصلي أفقيًا بالإضافة إلى الأجهزة التي يكون اتجاهها الأصلي عموديًا.
7.6. الذاكرة ومساحة التخزين
7.6.1. الحدّ الأدنى للذاكرة ومساحة التخزين
يجب أن تتوفّر لعمليات تنفيذ الأجهزة ذاكرة بسعة 340 ميغابايت على الأقل للنواة
ومساحة مستخدم. يجب أن تكون مساحة التخزين البالغة 340 ميغابايت بالإضافة إلى أي مساحة تخزين مخصّصة
لمكونات الأجهزة مثل الراديو والفيديو وما إلى ذلك التي لا تخضع
لتحكم النواة.
يجب أن تتوفّر في عمليات تثبيت التطبيق مساحة تخزين غير متغيّرة بسعة 350 ميغابايت على الأقل
لبيانات التطبيق الخاصة. أي أنّ حجم قسم /data يجب أن يكون 350 ميغابايت على الأقل.
تتضمّن واجهات برمجة تطبيقات Android مدير تنزيل قد تستخدمه التطبيقات لتنزيل
ملفات البيانات [المراجع، 56]. يجب أن يكون تطبيق "مدير التنزيل"
على الجهاز قادرًا على تنزيل ملفات فردية بحجم 100 ميغابايت على الأقل إلى
الموقع التلقائي "للذاكرة المؤقتة".
7.6.2. مساحة التخزين المشترَكة للتطبيقات
يجب أن تتيح عمليات تثبيت الأجهزة مساحة تخزين مشترَكة للتطبيقات. يجب أن يكون حجم مساحة التخزين
المشترَكة متوفّرة بسعة 1 غيغابايت على الأقل.
يجب ضبط عمليات تنفيذ الأجهزة باستخدام مساحة تخزين مشترَكة تم تركيبها تلقائيًا،
"بدون أي إعدادات مسبقة". إذا لم يتم تثبيت مساحة التخزين المشترَكة على مسار Linux /sdcard، يجب
أن يتضمّن الجهاز رابطًا رمزيًا لنظام Linux من /sdcard إلى نقطة التثبيت الفعلية.
يجب أن تفرض عمليات تنفيذ التطبيقات على مساحة التخزين المشترَكة إذن
android.permission.WRITE_EXTERNAL_STORAGE كما هو موثَّق.
يجب أن يكون بإمكان أي تطبيق يحصل على إذن
الكتابة في مساحة التخزين المشترَكة.
قد تتضمّن عمليات تثبيت الأجهزة معدات لتخزين متحرك يمكن للمستخدم الوصول إليه،
مثل بطاقة Secure Digital. وبدلاً من ذلك، يجوز لعمليات نشر الأجهزة تخصيص
مساحة التخزين الداخلية (غير القابلة للإزالة) كمساحة تخزين مشترَكة للتطبيقات.

بغض النظر عن شكل مساحة التخزين المشتركة المستخدَمة، يجب أن يوفّر تنفيذ الجهاز
آلية للوصول إلى محتوى مساحة التخزين المشتركة من جهاز كمبيوتر مضيف
، مثل مساحة التخزين الضخمة عبر USB (UMS) أو بروتوكول نقل الوسائط (MTP).
يجوز لعمليات تنفيذ الجهاز استخدام مساحة التخزين الضخمة عبر USB، ولكن يجب استخدام بروتوكول
نقل الوسائط. إذا كان تطبيق الجهاز يتوافق مع بروتوكول نقل الوسائط:
يجب أن يكون تطبيق الجهاز متوافقًا مع الإصدار المرجعي من Android
‏MTP host، Android File Transfer [Resources, 57].
يجب أن يُبلغ تطبيق الجهاز عن فئة جهاز USB بقيمة 0x00.
يجب أن يُبلغ تطبيق الجهاز عن اسم واجهة USB بقيمة MTP.
إذا لم تتوفر منافذ USB في عملية تنفيذ الجهاز، يجب أن يوفر جهاز كمبيوتر مستضيفًا
بإمكانية الوصول إلى محتوى مساحة التخزين المشترَكة بوسائل أخرى، مثل نظام ملف
على الشبكة.
يُرجى الاطّلاع على مثالَين شائعَين لفهم الأمر. إذا تضمّن تنفيذ الجهاز
فتحة بطاقة SD لتلبية متطلّبات مساحة التخزين المشترَكة، يجب تضمين بطاقة SD بتنسيق FAT
بحجم 1 غيغابايت أو أكبر مع الجهاز كما يتم بيعه للمستخدمين، ويجب
تركيبها تلقائيًا. وبدلاً من ذلك، إذا كان تطبيق الجهاز يستخدِم مساحة تخزين ثابتة داخلية
لتلبية هذا المتطلب، يجب أن يكون حجم مساحة التخزين هذا 1 غيغابايت أو أكبر و
مثبَّتًا على /sdcard (أو يجب أن يكون /sdcard رابطًا رمزيًا للموقع الجغرافي إذا تم
تركيبه في مكان آخر).
يجب تعديل التطبيقات الأساسية مثل
أداة فحص الوسائط وContentProvider لتتمكّن بشفافية من الوصول إلى الملفات المخزّنة في كلا
المواضع في حال تضمين عمليات تنفيذ الأجهزة مسارات متعددة لمساحة التخزين المشترَكة (مثل كلٍّ من
فتحة بطاقة SD ومساحة التخزين الداخلية المشترَكة).
7.7. USB
يجب أن تتضمّن عمليات تنفيذ الأجهزة منفذ عميل USB، ويجب أن تتضمّن
منفذ مضيف USB.
إذا تضمّن تنفيذ الجهاز منفذ عميل USB:
يجب أن يكون المنفذ قابلاً للتوصيل بجهاز استضافة USB مزوّد بمنفذ USB-A عادي
يجب أن يستخدم المنفذ شكل USB المصغر على جانب الجهاز. ننصح بشدة
بالالتزام
بهذه المتطلبات في نظام التشغيل Android 4.1 على الأجهزة الحالية
والجديدة التي تعمل بنظام التشغيل Android 4.1، وذلك لكي تتمكّن من الترقية إلى الإصدارات المستقبلية
من النظام الأساسي
. يجب أن يكون المنفذ في منتصف الحافة. يجب أن تضع عمليات تثبيت الأجهزة
منفذ الشحن في أسفل الجهاز (وفقًا لاتجاه
الجهاز الطبيعي) أو تفعِّل ميزة تبديل اتجاه الشاشة البرمجي لجميع التطبيقات (بما في ذلك الشاشة
الرئيسية)، كي يتم عرض المحتوى على الشاشة بشكل صحيح عندما يكون اتجاه الجهاز بحيث يكون
منفذ الشحن في أسفله. ننصح بشدة
باستيفاء الأجهزة الحالية والجديدة التي تعمل بنظام Android 4.1 لهذه المتطلبات في Android 4.1 كي تتمكّن
من الترقية إلى إصدارات النظام الأساسي المستقبلية.
إذا كان الجهاز يحتوي على منافذ أخرى (مثل منفذ شحن غير USB) يجب أن يكون
على الحافة نفسها التي يقع على جانبها منفذ USB المصغر
يجب أن يسمح لجهاز الاستضافة المتصل بالجهاز بالوصول إلى محتوى
وحدة التخزين المشترَكة باستخدام إما وحدة تخزين USB الجماعية أو بروتوكول
نقل الوسائط
يجب أن ينفِّذ واجهة برمجة التطبيقات لجهاز استضافة USB في Android على النحو الموضَّح في مستندات
حزمة تطوير البرامج (SDK) لنظام Android، ويجب أن يعلن عن توافقه مع
ميزة الأجهزة
android.hardware.usb.host [Resources, 52]
يجب أن ينفِّذ فئة الصوت في USB على النحو الموضَّح في مستندات
حزمة تطوير البرامج (SDK) لنظام Android [Resources, 66]
يجب أن ينفِّذ واجهة برمجة التطبيقات لميزة شحن البطارية عبر USB على
[Resources, 64] ننصح بشدة
باستيفاء الأجهزة الحالية والجديدة التي تعمل بنظام Android 4.1 لهذه المتطلبات في Android 4.1 كي تتمكّن
من الترقية إلى إصدارات النظام الأساسي المستقبلية.
إذا كان تطبيق الجهاز يتضمّن منفذ استضافة USB:
يجوز استخدام شكل منفذ غير عادي، ولكن في هذه الحالة يجب شحن الجهاز مع كابل أو
كابلات تتيح تحويل المنفذ إلى منفذ USB-A عادي
يجب أن ينفِّذ واجهة برمجة التطبيقات لجهاز استضافة USB في Android على النحو الموضَّح في مستندات
حزمة تطوير البرامج (SDK) لنظام Android، ويجب أن يعلن عن توافقه مع
ميزة الأجهزة
android.hardware.usb.host [Resources, 53]
يجب أن تنفِّذ تطبيقات الأجهزة واجهة Android Debug Bridge. إذا تجاهل
تنفيذ الجهاز منفذ عميل USB، يجب تنفيذ Android Debug Bridge
عبر شبكة المنطقة المحلية (مثل Ethernet أو 802.11)

8. التوافق مع الأداء
يجب أن تستوفي عمليات تنفيذ التطبيقات مقاييس الأداء الرئيسية لجهاز متوافق مع الإصدار 4.1
من نظام Android والمُحدَّدة في الجدول أدناه:
المقياس
الحدّ الحدّ الأدنى للأداء
التعليقات
يجب تشغيل التطبيقات التالية
خلال المدة
المحددة.
يتم قياس وقت التشغيل على أنّه
الوقت الإجمالي لإكمال تحميل
المتصفّح: أقل من
النشاط التلقائي للتطبيق،
التطبيق
1300 ملي ثانية
بما في ذلك الوقت الذي يستغرقه بدء
وقت التشغيل
جهات الاتصال: أقل من
عملية Linux، تحميل حزمة
700 ملي ثانية
Android إلى الآلة الافتراضية Dalvik، وcal
الإعدادات: أقل من
onCreate.
700 ملي ثانية
عند
إطلاق تطبيقات متعدّدة، يجب أن يستغرق
إعادة إطلاق تطبيق
قيد التشغيل
في وقت متزامن
بعد

إطلاق التطبيقات

أقل من وقت الإطلاق
الأصلي.
9. توافق نموذج الأمان
يجب أن تنفِّذ عمليات تنفيذ الأجهزة نموذج أمان متوافقًا مع نموذج أمان نظام Android
الأساسي على النحو الموضَّح في مستند المراجع لأمان الأذونات في
واجهات برمجة التطبيقات [المراجع، 54] في مستندات مطوّري تطبيقات Android. يجب أن تتيح
عمليات تثبيت الأجهزة تثبيت التطبيقات الموقَّعة ذاتيًا بدون
طلب أي أذونات أو شهادات إضافية من أي جهات خارجية أو هيئات.
وعلى وجه التحديد، يجب أن تتوافق الأجهزة مع آليات الأمان الموضَّحة في
الأقسام الفرعية التالية.
9.1. الأذونات
يجب أن تتوافق عمليات تنفيذ التطبيقات على الأجهزة مع نموذج أذونات Android على النحو الموضَّح في
مستندات مطوّري تطبيقات Android [المراجع، 54]. على وجه التحديد، يجب أن تفرض عمليات التنفيذ
كل إذن محدّد على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK)، ولا يجوز حذف أي
إذن أو تغييره أو تجاهله. يجوز لعملياتالتنفيذ إضافة أذونات
إضافية، بشرط ألا تكون سلسلات معرّفات الأذونات الجديدة في نطاق android.*
.
9.2. معرّف المستخدم وعزلة العمليات
يجب أن تتوافق عمليات تنفيذ التطبيقات على الأجهزة مع نموذج وضع التعلُّم العزلي لتطبيقات Android، حيث
يتم تشغيل كل تطبيق باستخدام معرّف مستخدم فريد على طراز Unix وداخل عملية مفصولة.
يجب أن تتوافق عمليات تنفيذ التطبيقات على الأجهزة مع تشغيل تطبيقات متعدّدة باستخدام معرّف مستخدم Linux نفسه، بشرط أن تكون التطبيقات موقَّعة ومصمّمة بشكلٍ صحيح، على النحو الموضّح في مرجع الأمان والأذونات [المراجع، 54].

9.3. أذونات نظام الملفات
يجب أن تتوافق عمليات تنفيذ التطبيقات على الأجهزة مع نموذج أذونات الوصول إلى الملفات في نظام Android على النحو
الموضَّح في مرجع الأمان والأذونات [المراجع، 54].
9.4. بيئات التنفيذ البديلة
قد تتضمن عمليات تنفيذ التطبيقات على الأجهزة بيئات وقت التشغيل التي تنفذ التطبيقات
باستخدام بعض البرامج أو التكنولوجيات غير الآلة الافتراضية Dalvik أو الرمز
الأصلي. ومع ذلك، يجب ألا تؤدي بيئات التنفيذ البديلة هذه إلى انتهاك
نموذج أمان Android أو أمان تطبيقات Android المُثبَّتة، كما هو موضَّح
في هذا القسم.
يجب أن تكون بيئات التشغيل البديلة هي نفسها تطبيقات Android، وأن تلتزم
بنموذج أمان Android العادي، على النحو الموضَّح في مكان آخر في القسم 9.
يجب عدم منح أوقات التشغيل البديلة إذن الوصول إلى الموارد المحمية بواسطة
أذونات لم يتم طلبها في ملف AndroidManifest.xml لوقت التشغيل من خلال آلية <uses-
permission>.

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

يجوز تضمين ملفات ‎ .apk لأوقات التشغيل البديلة في صورة النظام لتطبيق
على الجهاز، ولكن يجب توقيعها بمفتاح مختلف عن المفتاح المستخدَم لتوقيع
التطبيقات الأخرى المضمّنة في تطبيق الجهاز.
عند تثبيت التطبيقات، يجب أن تحصل بيئات التشغيل البديلة على موافقة المستخدِم على
أذونات Android التي يستخدِمها التطبيق. أي أنّه إذا كان التطبيق بحاجة إلى
استخدام أحد موارد الجهاز التي يتوفر لها إذن Android مقابل (مثل
الكاميرا ونظام تحديد الموقع الجغرافي وما إلى ذلك)، يجب أن يُعلم الوقت البديل للتنفيذ المستخدم بأنّ التطبيق
سيكون بإمكانه الوصول إلى هذا المورد. إذا لم تسجِّل بيئة وقت التشغيل
إمكانات التطبيق بهذه الطريقة، يجب أن تُدرِج بيئة وقت التشغيل جميع
الأذونات التي يمتلكها وقت التشغيل نفسها عند تثبيت أي تطبيق يستخدِم وقت التشغيل هذا.
10. اختبار التوافق مع البرامج
يجب أن تجتاز عمليات تنفيذ الأجهزة جميع الاختبارات الموضّحة في هذا القسم.
يُرجى العلم أنّه لا توجد حزمة اختبار برامج شاملة تمامًا. لهذا السبب،
ننصح بشدة مطوّري الأجهزة بإجراء أقل عدد ممكّن من
التغييرات على الإصدار المرجعي والمفضّل من Android 4.1
المتاح من مشروع Android Open Source. سيؤدي ذلك إلى تقليل خطر
ظهور أخطاء تؤدي إلى عدم التوافق وتتطلّب إعادة التصميم وإجراء تحديثات احتمالية على
الجهاز.
10.1. مجموعة أدوات اختبار التوافق
يجب أن تجتاز عمليات نشر الأجهزة مجموعة أدوات اختبار التوافق مع Android (CTS)
[مراجع، 2] المتوفّرة من مشروع Android المفتوح المصدر، باستخدام الإصدار النهائي
من البرامج المتوفّرة على الجهاز. بالإضافة إلى ذلك، على مطوّري الأجهزة استخدام
الإصدار الترميزي المرجعي في شجرة الرمز المفتوح لنظام Android قدر الإمكان، و
يجب ضمان التوافق في حالات التباس في مجموعة أدوات اختبار التوافق ولأي
عمليات إعادة تنفيذ لأجزاء من الرمز الترميزي المرجعي.
تم تصميم CTS لتشغيله على جهاز حقيقي. ومثل أي برنامج، قد
يحتوي CTS نفسه على أخطاء. سيتم إصدار CTS بإصدارات مستقلة عن هذا
تعريف التوافق، وقد يتم إصدار مراجعات متعددة من CTS لنظام Android 4.1. يجب أن تجتاز عمليات تنفيذ
الأجهزة أحدث إصدار من CTS متاح في وقت إكمال برنامج
الجهاز.
10.2. أداة التحقّق من التوافق (CTS)
يجب أن تنفِّذ عمليات تنفيذ الأجهزة بشكلٍ صحيح كل الحالات السارِية في أداة التحقّق من التوافق (CTS)
. يتم تضمين أداة التحقّق من التوافق (CTS Verifier) مع مجموعة أدوات اختبار التوافق، والمقصود
بهذه الأداة أن يستخدمها مشغّل بشري لاختبار الوظائف التي لا يمكن اختبارها من خلال
نظام آلي، مثل الأداء السليم للكاميرا والأجهزة الاستشعارية.
يتضمّن أداة التحقّق من توافق البرامج المعيارية اختبارات لأنواع متعددة من الأجهزة، بما في ذلك بعض الأجهزة التي
تكون اختيارية. يجب اجتياز عمليات تنفيذ الأجهزة لجميع اختبارات الأجهزة التي
تمتلكها، على سبيل المثال، إذا كان الجهاز يمتلك مقياس تسارع، يجب
تنفيذ نموذج اختبار مقياس التسارع بشكلٍ صحيح في أداة التحقّق من توافق الأجهزة (CTS). قد يتم تخطّي أو حذف حالات الاختبار للميزات المُشار إلى أنّها
اختيارية في هذا المستند لتعريف التوافق.
يجب أن يشغّل كل جهاز وكل إصدار أداة CTS Verifier بشكل صحيح، كما هو مذكور أعلاه.
ومع ذلك، بما أنّ العديد من الإصدارات تشبه بعضها جدًا، لا يُتوقّع من منفّذِي الأجهزة
تشغيل أداة CTS Verifier بشكل واضح على الإصدارات التي تختلف فقط بطرق بسيطة. على وجه التحديد،
عمليات تنفيذ الأجهزة التي تختلف عن عملية تنفيذ اجتازت
أداة التحقّق من التوافق (CTS) فقط بسبب مجموعة اللغات والعلامات التجارية والمعلومات الأخرى المضمّنة يجوز لها حذف اختبار أداة التحقّق من التوافق (CTS)

.
10.3. التطبيقات المرجعية
على مطوّري الأجهزة اختبار توافق التطبيق باستخدام التطبيقات التالية المفتوحة
المصدر:
تطبيقات "التطبيقات لنظام Android" [Resources, 55]
Replica Island (متاحة في Android Market)
يجب تشغيل كل تطبيق من التطبيقات المذكورة أعلاه ويعمل بشكل صحيح عند التنفيذ، لكي يكون
التنفيذ متوافقًا.
11. البرامج القابلة للتحديث
يجب أن تتضمّن عمليات نشر الأجهزة آلية لاستبدال
برامج النظام بالكامل. ولا يلزم أن تُجري آلية الترقية عمليات ترقية "مباشرة"، أي أنّه قد يكون من الضروري
إعادة تشغيل الجهاز.
يمكن استخدام أي طريقة، بشرط أن تستبدل البرنامج
المُثبَّت مسبقًا على الجهاز. على سبيل المثال، أي من الطرق التالية ستلبي
هذا المتطلب:
عمليات التنزيل عبر شبكة غير سلكيّة (OTA) مع التحديث بلا اتصال بالإنترنت من خلال إعادة تشغيل
التحديثات"المرتبطة" عبر USB من جهاز كمبيوتر مضيف
التحديثات"بلا اتصال بالإنترنت" من خلال إعادة تشغيل والتحديث من ملف على مساحة تخزين قابلة للإزالة
يجب أن تتوافق آلية التحديث المستخدَمة مع التحديثات بدون محو بيانات المستخدم. بمعنى آخر،
يجب أن تحافظ آلية التحديث على البيانات الخاصة بالتطبيق و
البيانات المشترَكة للتطبيق. يُرجى العِلم أنّ الإصدار الأساسي من نظام Android يتضمّن آلية تحديث
تستوفي هذا المتطلب.
إذا تم رصد خطأ في تنفيذ الجهاز بعد إصداره ولكن خلال
فترة الضمان المعقولة للمنتج التي يتم تحديدها بالتشاور مع
فريق التوافق في Android لتأثيرها في توافق التطبيقات التابعة لجهات خارجية، على
منفذ الجهاز تصحيح الخطأ من خلال تحديث برنامج متاح يمكن
تطبيقه وفقًا للآلية الموضّحة توًا.
‫12. التواصل معنا
يمكنك التواصل مع مؤلفي المستند على compatibility@android.com للحصول على توضيحات
و لطرح أي مشاكل تعتقد أنّ المستند لم يتناولها.

الملحق أ - إجراء اختبار البلوتوث
تتضمّن مجموعة أدوات اختبار التوافق حالات تغطي التشغيل الأساسي لواجهة برمجة تطبيقات البلوتوث
RFCOMM في نظام Android. ومع ذلك، بما أنّ البلوتوث هو بروتوكول اتصالات
بين الأجهزة، لا يمكن اختباره بشكل كامل من خلال اختبارات الوحدات التي تُجري على جهاز واحد.
نتيجةً لذلك، يجب أن تجتاز عمليات تنفيذ الأجهزة أيضًا إجراء اختبار البلوتوث
الذي يُجريه المستخدم والذي سيتم وصفه أدناه.
يستند إجراء الاختبار إلى نموذج تطبيق BluetoothChat المضمّن في شجرة مشروع الرمز المفتوح
لنظام التشغيل Android. يتطلّب الإجراء استخدام جهازَين:
تنفيذ جهاز مرشح يعمل بإصدار البرنامج المراد اختباره
تنفيذ جهاز منفصل معروف أنّه متوافق، و
طراز من تنفيذ الجهاز الذي يتم اختباره، أي تنفيذ جهاز "معروف
أنّه جيد"
يشير إجراء الاختبار أدناه إلى هذان الجهازان على أنّهما الجهازان "المرشح" و "
المعروف أنّه جيد"، على التوالي.
الإعداد والتثبيت
1.  أنشئ ملف BluetoothChat.apk من خلال "إنشاء عيّنات" من شجرة رمز مصدر Android
2.  ثبِّت  ملف BluetoothChat.apk على الجهاز المعروف بأنّه يعمل بشكل سليم.
3.  ثبِّت  ملف BluetoothChat.apk على الجهاز المعنيّ
اختبار التحكّم في البلوتوث من خلال التطبيقات
1.  شغِّل BluetoothChat على الجهاز المعني، مع إيقاف البلوتوث
2.  تحقَّق من أنّ الجهاز المعني إما يفعِّل البلوتوث أو يطلب من المستخدم
عرض مربّع حوار لتشغيل البلوتوث
اختبار الإقران والاتصال
1.  شغِّل تطبيق "المحادثة عبر البلوتوث" على كلا الجهازَين
2.  اجعل الجهاز المعروف صالحًا للاكتشاف من داخل BluetoothChat (باستخدام
القائمة)
3.  على الجهاز المعني، ابحث عن أجهزة البلوتوث من داخل BluetoothChat
(باستخدام القائمة) واقترِن بالجهاز الذي يعمل بشكلٍ سليم
4.  أرسِل 10 رسائل أو أكثر من كل جهاز، وتأكَّد من أنّ الجهاز الآخر
يتلقّاها بشكلٍ صحيح
5.  أغلِق تطبيق BluetoothChat على كلا الجهازين بالضغط على Home
6.  ألغِ إقران كل جهاز بالآخر، باستخدام تطبيق "إعدادات الجهاز"
اختبار الإقران والاتصال بالاتجاه
العكس
1.  افتح تطبيق "المحادثة عبر البلوتوث" على كلا الجهازين.
2.  اجعل الجهاز المرشح قابلاً للاكتشاف من داخل BluetoothChat (باستخدام
القائمة).
3.  على الجهاز المعروف أنّه يعمل بشكلٍ سليم، ابحث عن أجهزة البلوتوث من داخل BluetoothChat
(باستخدام القائمة) واقترِن بالجهاز المعني.
4.  أرسِل 10 رسائل أو أكثر من كل جهاز، وتأكَّد من أنّ الجهاز الآخر
يتلقّاها بشكلٍ صحيح.
‫5.  أغلِق تطبيق "محادثة البلوتوث" على كلا الجهازَين بالضغط على "رجوع" بشكل متكرّر ل
الوصول إلى مشغِّل التطبيقات.
اختبار عمليات إعادة الإطلاق
1.  أعِد تشغيل تطبيق "المحادثة عبر البلوتوث" على كلا الجهازَين.
2.  أرسِل 10 رسائل أو أكثر من كل جهاز، وتأكَّد من أنّ الجهاز الآخر
يتلقّاها بشكلٍ صحيح.
ملاحظة: تتضمّن الاختبارات المذكورة أعلاه بعض الحالات التي تنتهي بقسم اختبار باستخدام الصفحة الرئيسية، و
بعض الحالات باستخدام الرجوع. هذه الاختبارات ليست مكرّرة وليست اختيارية: والهدف هو
التحقّق من عمل واجهة برمجة تطبيقات Bluetooth والحزمة بشكل صحيح في كلٍّ من حالتَي
إنهاء الأنشطة بشكل صريح (من خلال ضغط المستخدم على الزر "رجوع" الذي يؤدي إلى إنهاء النشاط) وإرسالها بشكل ضمني
إلى الخلفية (من خلال ضغط المستخدم على الزر "الصفحة الرئيسية"). يجب تنفيذ كل تسلسل اختبار
على النحو الموضَّح.

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

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