تعريف التوافق مع Android 2.3

حقوق الطبع والنشر © 2010، شركة Google Inc. جميع الحقوق محفوظة.
التوافق@android.com

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

1 المقدمة

يعدد هذا المستند المتطلبات التي يجب استيفاؤها حتى تكون الهواتف المحمولة متوافقة مع Android 2.3.

إن استخدام "يجب" و"يجب ألا" و"مطلوب" و"يجب" و"لا يجوز" و"ينبغي" و"لا ينبغي" و"موصى به" و"يجوز" و"اختياري" يتوافق مع معيار IETF تم تعريفه في RFC2119 [ الموارد، 1 ].

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

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

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

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

2. الموارد

1. مستويات متطلبات IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
2. نظرة عامة على برنامج التوافق مع Android: http://source.android.com/docs/compatibility/index.html
3. مشروع أندرويد مفتوح المصدر: 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 2.3 سلاسل الإصدار المسموح بها: http://source.android.com/docs/compatibility/2.3/versions.html
8. فئة android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html
9. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
10. إمكانات HTML5 في وضع عدم الاتصال: http://dev.w3.org/html5/spec/Overview.html#offline
11. علامة فيديو HTML5: http://dev.w3.org/html5/spec/Overview.html#video
12. واجهة برمجة تطبيقات تحديد الموقع الجغرافي بتنسيق HTML5/W3C: http://www.w3.org/TR/geolocation-API/
13. واجهة برمجة تطبيقات قاعدة بيانات الويب HTML5/W3C: http://www.w3.org/TR/webdatabase/
14. واجهة برمجة تطبيقات HTML5/W3C IndexedDB: http://www.w3.org/TR/IndexedDB/
15. مواصفات Dalvik Virtual Machine: متوفرة في كود مصدر Android، على dalvik/docs
16. أدوات التطبيق: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
17. الإخطارات: http://developer.Android.com/guide/topics/ui/notifiers/notifications.html
18. موارد التطبيق: http://code.google.com/android/reference/available-resources.html
19. دليل نمط رمز شريط الحالة: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
20. مدير البحث: http://developer.android.com/reference/android/app/SearchManager.html
21. الخبز المحمص: http://developer.android.com/reference/android/widget/Toast.html
22. خلفيات حية: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
23. وثائق الأداة المرجعية (لـ adb وaapt وddms): http://developer.android.com/guide/developing/tools/index.html
24. وصف ملف Android APK: http://developer.android.com/guide/topics/fundamentals.html
25. ملفات البيان: http://developer.Android.com/guide/topics/manifest/manifest-intro.html
26. أداة اختبار القرد: https://developer.android.com/studio/test/other-testing-tools/monkey
27. قائمة ميزات أجهزة Android: http://developer.android.com/reference/android/content/pm/PackageManager.html
28. دعم شاشات متعددة: http://developer.android.com/guide/practices/screens_support.html
29. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
30. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
31. مساحة إحداثيات المستشعر: http://developer.android.com/reference/android/hardware/SensorEvent.html
32. واجهة برمجة تطبيقات البلوتوث: http://developer.android.com/reference/android/bluetooth/package-summary.html
33. بروتوكول دفع NDEF: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf
34. ميفار MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
35. ميفار MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
36. ميفار MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
37. ميفار MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
38. ميفار AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf
39. ميفار AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf
40. واجهة برمجة تطبيقات توجيه الكاميرا: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
41. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
42. مرجع أمان Android والأذونات: http://developer.android.com/guide/topics/security/security.html
43. التطبيقات لنظام Android: http://code.google.com/p/apps-for-android

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

3. البرمجيات

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

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

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

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

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

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

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

3.2.1. الأذونات

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

3.2.2. بناء المعلمات

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

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

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

3.2.3.1. نوايا التطبيق الأساسية

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

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

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

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

تشتمل تطبيقات نظام Android الأساسية على العديد من مكونات الأنشطة أو الخدمة التي تعتبر "عامة". أي أن السمة "android:exported" قد تكون غائبة، أو قد تكون قيمتها "صحيح".

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

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

3.2.3.2. تجاوزات النية

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

3.2.3.3. مساحات الأسماء النية

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

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

3.2.3.4. نوايا البث

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

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

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

إذا كان تنفيذ الجهاز يتضمن دعمًا لـ Android ABI، فإنه:

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

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

• ليبك (مكتبة C)
• ليب (مكتبة الرياضيات)
• الحد الأدنى من الدعم لC++
• واجهة جي ان اي
• 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 (دعم الصوت لمكتبة الصوت المفتوحة)
• libandroid.so (دعم نشاط Android الأصلي)
• دعم OpenGL، كما هو موضح أدناه

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

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

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

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

3.4.1. التوافق مع عرض الويب

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

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

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

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

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

يجب تعطيل واجهات برمجة تطبيقات HTML5، مثل جميع واجهات برمجة تطبيقات JavaScript، بشكل افتراضي في WebView، ما لم يقم المطور بتمكينها بشكل صريح عبر واجهات برمجة تطبيقات Android المعتادة.

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

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

قد تقوم عمليات التنفيذ بشحن سلسلة وكيل مستخدم مخصصة في تطبيق المتصفح المستقل.

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

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

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

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

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

• يجب ألا تغير الأجهزة سلوك أو دلالات النية القياسية
• يجب ألا تغير الأجهزة دورة الحياة أو دلالات دورة الحياة لنوع معين من مكونات النظام (مثل الخدمة، والنشاط، وContentProvider، وما إلى ذلك)
• يجب ألا تغير الأجهزة دلالات الإذن القياسي

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

3.6. مساحات أسماء API

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

• جافا.*
• جافاكس.*
• شمس.*
• ذكري المظهر.*
• com.android.*

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

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

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

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

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

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

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

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

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

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

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

3.8.1. الحاجيات

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

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

3.8.2. إشعارات

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

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

3.8.3. يبحث

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

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

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

3.8.4. الخبز المحمص

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

3.8.5. خلفيات حية

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

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

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

4. توافق تعبئة التطبيقات

يجب على تطبيقات الأجهزة تثبيت ملفات Android ".APK" كما تم إنشاؤها بواسطة أداة "AAPT" المدرجة في Android SDK الرسمية [ الموارد ، 23 ].

يجب ألا تقوم تطبيقات الأجهزة بتمديد إما .APK [ الموارد ، 24 ] ، و Android Driesest [ الموارد ، 25 ] ، أو Dalvik Bytecode [ الموارد ، 15 ] تنسيقات من شأنها منع تلك الملفات من التثبيت وتشغيلها بشكل صحيح على الأجهزة المتوافقة الأخرى . يجب على منفذي الأجهزة استخدام تنفيذ مرجع Dalvik المرجعي ، ونظام إدارة حزم التنفيذ المرجعي.

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

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

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

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

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

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

5.1.1. فك تشفير الوسائط

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

5.1.2. الترميز وسائل الإعلام

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

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

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

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

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

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

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

5.3. الكمون الصوتي

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

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

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

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

• زمن انتقال الإخراج البارد 100 ميلي ثانية أو أقل
• زمن انتقال الإخراج الدافئ 10 مللي ثانية أو أقل
• زمن انتقال الإخراج المستمر من 45 ميلي ثانية أو أقل
• زمن انتقال المدخلات الباردة 100 ميلي ثانية أو أقل
• الكمون المستمر مدخلات من 50 ميلي ثانية أو أقل

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

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

6. توافق أداة المطور

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

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

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

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

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

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

• يجب أن تظل تعريفات الفئة الكاملة (كما هو موثق من قبل SDK) لواجهة برمجة التطبيقات للمكون موجودة
• يجب تنفيذ سلوكيات واجهة برمجة التطبيقات على أنها عدم وجود OPS بطريقة معقولة
• يجب أن تُرجع طرق API قيمًا فارغة حيث يسمح بها وثائق SDK
• يجب أن تعيد طرق API تطبيقات عدم وجود فئات لا يسمح بها القيم الخالية من خلال وثائق SDK
• يجب ألا ترمي أساليب API استثناءات غير موثقة بواسطة وثائق SDK

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

يجب أن تقوم تطبيقات الجهاز بالإبلاغ بدقة عن معلومات تكوين الأجهزة الدقيقة عبر أساليب getSystemAvailableFeatures() وطرق hasSystemFeature(String) على فصل android.content.pm.PackageManager . [ الموارد ، 27 ]

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

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

7.1.1. تكوينات الشاشة

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

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

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

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

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

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

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

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

7.1.3. دعم الشاشة المعلن

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

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

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

يجب أن تقوم الأجهزة بالإبلاغ عن القيمة الصحيحة للاتجاه الحالي للجهاز ، كلما تم الاستعلام عنها عبر Android.content.res.configuration.orientation ، Android.view.display.getorientation () ، أو واجهات برمجة التطبيقات الأخرى.

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

يجب أن تدعم تطبيقات الأجهزة OpenGL ES 1.0 ، كما هو مطلوب من قبل واجهات برمجة التطبيقات Android 2.3. بالنسبة للأجهزة التي تفتقر إلى أجهزة التسارع ثلاثي الأبعاد ، يتم توفير تطبيق برنامج OpenGL ES 1.0 من خلال مشروع Optrem Android مفتوح المصدر. يجب أن تدعم تطبيقات الجهاز OpenGL ES 2.0.

قد تغلب التطبيقات على دعم GL ES 2.0 المفتوح ؛ ومع ذلك ، إذا تم حذف الدعم ، فيجب ألا تقوم تطبيقات الجهاز بالإبلاغ عن دعم OpenGL ES 2.0. على وجه التحديد ، إذا كانت تطبيقات الجهاز تفتقر إلى دعم OpenGL ES 2.0:

• يجب ألا تقوم واجهات برمجة التطبيقات المدارة (مثل عبر طريقة GLES10.getString() ) الإبلاغ عن دعم OpenGL ES 2.0
• يجب ألا تقوم APIs الأصليين C/C ++ OpenGL (أي تلك المتاحة للتطبيقات عبر libgles_v1c.so أو libgles_v2.so أو libegl.so) الإبلاغ عن دعم OpenGL ES 2.0.

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

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

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

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

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

تطبيقات الجهاز:

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

7.2.2. الملاحة غير الملمس

تطبيقات الجهاز:

• قد يحذف خيار التنقل غير اللعين (أي قد يحذف كرة التتبع أو D-Pad أو Wheel)
• يجب الإبلاغ عن القيمة الصحيحة لـ android.content.res.Configuration.navigation [ الموارد ، 30 ]
• يجب أن توفر آلية واجهة مستخدم بديلة معقولة لاختيار وتحرير النص ، متوافق مع محركات إدارة الإدخال. يتضمن رمز Opstream Android مفتوح المصدر آلية اختيار مناسبة للاستخدام مع الأجهزة التي تفتقر إلى مدخلات التنقل غير اللمسة.

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

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

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

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

تطبيقات الجهاز:

• يجب أن يكون لديك شاشة تعمل باللمس
• قد يكون لها شاشة لمس بالسعة أو مقاومة
• يجب الإبلاغ عن قيمة android.content.res.Configuration [ الموارد ، 30 ] تعكس المقابلة لنوع الشاشة التي تعمل باللمس المحددة على الجهاز
• يجب أن تدعم المؤشرات التي تم تتبعها بشكل مستقل ، إذا كانت الشاشة التي تعمل باللمس تدعم مؤشرات متعددة

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

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

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

القائمة أعلاه ليست شاملة. يجب اعتبار السلوك الموثق لنظام Android SDK موثوقًا.

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

تقدم واجهات برمجة تطبيقات Android 2.3 فكرة عن مستشعر "تدفق" ، وهو جهاز يرجع البيانات بشكل مستمر ، وليس فقط عندما تتغير البيانات. يجب أن توفر تطبيقات الأجهزة بشكل مستمر عينات بيانات دورية لأي واجهة برمجة تطبيقات تشير إليها وثائق Android 2.3 SDK لتكون مستشعر تدفق.

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

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

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

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

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

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

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

يجب أن تتضمن تطبيقات الأجهزة جهاز استقبال GPS. إذا كان تطبيق الجهاز يتضمن جهاز استقبال GPS ، فيجب أن يتضمن شكلاً من أشكال تقنية "GPS" لتقليل وقت قفل GPS.

7.3.4. جيروسكوب

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

• يجب أن تكون قادرة على قياس تغييرات الاتجاه حتى 5.5*pi radians/ثانية (أي حوالي 1000 درجة في الثانية)
• يجب أن تكون قادرة على تقديم الأحداث بسرعة 100 هرتز أو أكبر
• يجب أن يكون لديك 8 بتات من الدقة أو أكثر

7.3.5. بارومتر

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

• يجب أن تكون قادرة على تقديم الأحداث عند 5 هرتز أو أكبر
• يجب أن يكون لديك دقة كافية لتمكين تقدير الارتفاع

7.3.7. ميزان الحرارة

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

7.3.7. مضواء

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

7.3.8. مستشعر القرب

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

7.4. اتصال البيانات

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

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

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

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

7.4.2. IEEE 802.11 (wifi)

يجب أن تتضمن تطبيقات جهاز Android 2.3 دعمًا لنموذج واحد أو أكثر من 802.11 (B/G/A/N ، وما إلى ذلك) إذا كان تطبيق الجهاز يتضمن دعمًا لـ 802.11 ، فيجب عليه تنفيذ واجهة برهجة Android المقابلة.

7.4.3. بلوتوث

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

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

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

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

• يجب الإبلاغ عن ميزة Android.hardware.nfc من طريقة android.content.pm.PackageManager.hasSystemFeature() . [ الموارد ، 27 ]
• يجب أن تكون قادرة على قراءة وكتابة رسائل NDEF عبر معايير NFC التالية:
  • يجب أن تكون قادرة على التصرف كقارئ/كاتب منتدى NFC (على النحو المحدد في مواصفات NFC Forum التقنية NFCForum-TS-DIGITALPROTOCOL-1.0) عبر معايير NFC التالية:
    • NFCA (ISO14443-3A)
    • NFCB (ISO14443-3B)
    • NFCF (JIS 6319-4)
    • NFCV (ISO 15693)
    • isodep (ISO 14443-4)
    • أنواع علامات منتدى NFC 1 ، 2 ، 3 ، 4 (حددها منتدى NFC)
  • يجب أن تكون قادرة على نقل وتلقي البيانات عبر معايير وبروتوكولات نظير إلى نظير التالي:
    • ISO 18092
    • LLCP 1.0 (محدده منتدى NFC)
    • SDP 1.0 (محدده منتدى NFC)
    • بروتوكول دفع NDEF [ الموارد ، 33 ]
  • يجب أن تفحص جميع التقنيات المدعومة في وضع اكتشاف NFC.
  • يجب أن يكون في وضع اكتشاف NFC بينما يكون الجهاز مستيقظًا مع نشط الشاشة.

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

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

  • Mifare Classic (NXP MF1S503X [ الموارد ، 34 ] ، MF1S703X [ الموارد ، 35 ])
  • Mifare Ultralight (NXP MF0ICU1 [ الموارد ، 36 ] ، MF0ICU2 [ الموارد ، 37 ])
  • NDEF على Mifare Classic (NXP AN130511 [ Resources ، 38 ] ، AN130411 [ Resources ، 39 ])

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

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

  إذا لم يتضمن تطبيق الجهاز أجهزة NFC ، فيجب ألا يعلن عن ميزة Android.hardware.nfc من android.content.pm.PackageManager.hasSystemFeature() ( الموارد ، 27 ] ، ويجب تنفيذ Android 2.3 API As As عدم وجود op.

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

  7.4.5. الحد الأدنى من القدرة على الشبكة

  يجب أن تتضمن تطبيقات الأجهزة دعمًا لشبكة شبكات البيانات أو أكثر. على وجه التحديد ، يجب أن تتضمن تطبيقات الأجهزة دعمًا لمعايير بيانات واحدة على الأقل قادرة على 200 كيلو بايت/ثانية أو أكثر. Examples of technologies that satisfy this requirement include EDGE, HSPA, EV-DO, 802.11g, Ethernet, etc.

  Device implementations where a physical networking standard (such as Ethernet) is the primary data connection SHOULD also include support for at least one common wireless data standard, such as 802.11 (WiFi).

  Devices MAY implement more than one form of data connectivity.

  7.5. الكاميرات

  Device implementations SHOULD include a rear-facing camera, and MAY include a front-facing camera. A rear-facing camera is a camera located on the side of the device opposite the display; that is, it images scenes on the far side of the device, like a traditional camera. A front-facing camera is a camera located on the same side of the device as the display; that is, a camera typically used to image the user, such as for video conferencing and similar applications.

  7.5.1. الكاميرا الخلفية المواجهة

  Device implementations SHOULD include a rear-facing camera. If a device implementation includes a rear-facing camera, it:

  • MUST have a resolution of at least 2 megapixels
  • SHOULD have either hardware auto-focus, or software auto-focus implemented in the camera driver (transparent to application software)
  • MAY have fixed-focus or EDOF (extended depth of field) hardware
  • MAY include a flash. If the Camera includes a flash, the flash lamp MUST NOT be lit while an android.hardware.Camera.PreviewCallback instance has been registered on a Camera preview surface, unless the application has explicitly enabled the flash by enabling the FLASH_MODE_AUTO or FLASH_MODE_ON attributes of a Camera.Parameters object. Note that this constraint does not apply to the device's built-in system camera application, but only to third-party applications using Camera.PreviewCallback .

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

  Device implementations MAY include a front-facing camera. If a device implementation includes a front-facing camera, it:

  • MUST have a resolution of at least VGA (that is, 640x480 pixels)
  • MUST NOT use a front-facing camera as the default for the Camera API. That is, the camera API in Android 2.3 has specific support for front-facing cameras, and device implementations MUST NOT configure the API to to treat a front-facing camera as the default rear-facing camera, even if it is the only camera on الجهاز.
  • MAY include features (such as auto-focus, flash, etc.) available to rear-facing cameras as described in Section 7.5.1.
  • MUST horizontally reflect (ie mirror) the stream displayed by an app in a CameraPreview, as follows:
  • If the device implementation is capable of being rotated by user (such as automatically via an accelerometer or manually via user input), the camera preview MUST be mirrored horizontally relative to the device's current orientation.
  • If the current application has explicitly requested that the Camera display be rotated via a call to the android.hardware.Camera.setDisplayOrientation() [ Resources, 40 ] method, the camera preview MUST be mirrored horizontally relative to the orientation specified by the application.
  • Otherwise, the preview MUST be mirrored along the device's default horizontal axis.
  • MUST mirror the image data returned to any "postview" camera callback handlers, in the same manner as the camera preview image stream. (If the device implementation does not support postview callbacks, this requirement obviously does not apply.)
  • MUST NOT mirror the final captured still image or video streams returned to application callbacks or committed to media storage

  7.5.3. Camera API Behavior

  Device implementations MUST implement the following behaviors for the camera-related APIs, for both front- and rear-facing cameras:

  1. If an application has never called android.hardware.Camera.Parameters.setPreviewFormat(int), then the device MUST use android.hardware.PixelFormat.YCbCr_420_SP for preview data provided to application callbacks.
  2. If an application registers an android.hardware.Camera.PreviewCallback instance and the system calls the onPreviewFrame() method when the preview format is YCbCr_420_SP, the data in the byte[] passed into onPreviewFrame() must further be in the NV21 encoding format. That is, NV21 MUST be the default.
  3. Device implementations SHOULD support the YV12 format (as denoted by the android.graphics.ImageFormat.YV12 constant) for camera previews for both front- and rear-facing cameras. Note that the Compatibility Definition for a future version is planned to change this requirement to "MUST". That is, YV12 support is optional in Android 2.3 but will be required by a future version. Existing and new devices that run Android 2.3 are very strongly encouraged to meet this requirement in Android 2.3 , or they will not be able to attain Android compatibility when upgraded to the future version.

  Device implementations MUST implement the full Camera API included in the Android 2.3 SDK documentation [ Resources, 41 ]), regardless of whether the device includes hardware autofocus or other capabilities. For instance, cameras that lack autofocus MUST still call any registered android.hardware.Camera.AutoFocusCallback instances (even though this has no relevance to a non-autofocus camera.) Note that this does apply to front-facing cameras; for instance, even though most front-facing cameras do not support autofocus, the API callbacks must still be "faked" as described.

  Device implementations MUST recognize and honor each parameter name defined as a constant on the android.hardware.Camera.Parameters class, if the underlying hardware supports the feature. If the device hardware does not support a feature, the API must behave as documented. Conversely, Device implementations MUST NOT honor or recognize string constants passed to the android.hardware.Camera.setParameters() method other than those documented as constants on the android.hardware.Camera.Parameters . That is, device implementations MUST support all standard Camera parameters if the hardware allows, and MUST NOT support custom Camera parameter types.

  7.5.4. Camera Orientation

  Both front- and rear-facing cameras, if present, MUST be oriented so that the long dimension of the camera aligns with the screen's long dimension. That is, when the device is held in the landscape orientation, a cameras MUST capture images in the landscape orientation. This applies regardless of the device's natural orientation; that is, it applies to landscape-primary devices as well as portrait-primary devices.

  7.6. Memory and Storage

  The fundamental function of Android 2.3 is to run applications. Device implementations MUST the requirements of this section, to ensure adequate storage and memory for applications to run properly.

  7.6.1. Minimum Memory and Storage

  Device implementations MUST have at least 128MB of memory available to the kernel and userspace. The 128MB MUST be in addition to any memory dedicated to hardware components such as radio, memory, and so on that is not under the kernel's control.

  Device implementations MUST have at least 150MB of non-volatile storage available for user data. That is, the /data partition MUST be at least 150MB.

  Beyond the requirements above, device implementations SHOULD have at least 1GB of non-volatile storage available for user data. Note that this higher requirement is planned to become a hard minimum in a future version of Android. Device implementations are strongly encouraged to meet these requirements now, or else they may not be eligible for compatibility for a future version of Android.

  The Android APIs include a Download Manager that applications may use to download data files. The Download Manager implementation MUST be capable of downloading individual files 55MB in size, or larger. The Download Manager implementation SHOULD be capable of downloading files 100MB in size, or larger.

  7.6.2. Application Shared Storage

  Device implementations MUST offer shared storage for applications. The shared storage provided MUST be at least 1GB in size.

  Device implementations MUST be configured with shared storage mounted by default, "out of the box". If the shared storage is not mounted on the Linux path /sdcard , then the device MUST include a Linux symbolic link from /sdcard to the actual mount point.

  Device implementations MUST enforce as documented the android.permission.WRITE_EXTERNAL_STORAGE permission on this shared storage. Shared storage MUST otherwise be writable by any application that obtains that permission.

  Device implementations MAY have hardware for user-accessible removable storage, such as a Secure Digital card. Alternatively, device implementations MAY allocate internal (non-removable) storage as shared storage for apps.

  Regardless of the form of shared storage used, device implementations MUST provide some mechanism to access the contents of shared storage from a host computer, such as USB mass storage or Media Transfer Protocol.

  It is illustrative to consider two common examples. If a device implementation includes an SD card slot to satisfy the shared storage requirement, a FAT-formatted SD card 1GB in size or larger MUST be included with the device as sold to users, and MUST be mounted by default. Alternatively, if a device implementation uses internal fixed storage to satisfy this requirement, that storage MUST be 1GB in size or larger and mounted on /sdcard (or /sdcard MUST be a symbolic link to the physical location if it is mounted elsewhere.)

  Device implementations that include multiple shared storage paths (such as both an SD card slot and shared internal storage) SHOULD modify the core applications such as the media scanner and ContentProvider to transparently support files placed in both locations.

  7.7. USB

  تطبيقات الجهاز:

  • MUST implement a USB client, connectable to a USB host with a standard USB-A port
  • MUST implement the Android Debug Bridge over USB (as described in Section 7)
  • MUST implement the USB mass storage specification, to allow a host connected to the device to access the contents of the /sdcard volume
  • SHOULD use the micro USB form factor on the device side
  • MAY include a non-standard port on the device side, but if so MUST ship with a cable capable of connecting the custom pinout to standard USB-A port

  8. Performance Compatibility

  Compatible implementations must ensure not only that applications simply run correctly on the device, but that they do so with reasonable performance and overall good user experience. Device implementations MUST meet the key performance metrics of an Android 2.3 compatible device defined in the table below:

  قياس	عتبة الأداء	تعليقات
  Application Launch Time	The following applications should launch within the specified time. Browser: less than 1300ms MMS/SMS: less than 700ms AlarmClock: less than 650ms	The launch time is measured as the total time to complete loading the default activity for the application, including the time it takes to start the Linux process, load the Android package into the Dalvik VM, and call onCreate.
  Simultaneous Applications	When multiple applications have been launched, re-launching an already-running application after it has been launched must take less than the original launch time.

  9. Security Model Compatibility

  Device implementations MUST implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [ Resources, 42 ] in the Android developer documentation. Device implementations MUST support installation of self-signed applications without requiring any additional permissions/certificates from any third parties/authorities. Specifically, compatible devices MUST support the security mechanisms described in the follow sub-sections.

  9.1. الأذونات

  Device implementations MUST support the Android permissions model as defined in the Android developer documentation [ Resources, 42 ]. Specifically, implementations MUST enforce each permission defined as described in the SDK documentation; no permissions may be omitted, altered, or ignored. Implementations MAY add additional permissions, provided the new permission ID strings are not in the android.* namespace.

  9.2. UID and Process Isolation

  Device implementations MUST support the Android application sandbox model, in which each application runs as a unique Unix-style UID and in a separate process. Device implementations MUST support running multiple applications as the same Linux user ID, provided that the applications are properly signed and constructed, as defined in the Security and Permissions reference [ Resources, 42 ].

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

  Device implementations MUST support the Android file access permissions model as defined in as defined in the Security and Permissions reference [ Resources, 42 ].

  9.4. Alternate Execution Environments

  Device implementations MAY include runtime environments that execute applications using some other software or technology than the Dalvik virtual machine or native code. However, such alternate execution environments MUST NOT compromise the Android security model or the security of installed Android applications, as described in this section.

  Alternate runtimes MUST themselves be Android applications, and abide by the standard Android security model, as described elsewhere in Section 9.

  Alternate runtimes MUST NOT be granted access to resources protected by permissions not requested in the runtime's AndroidManifest.xml file via the <uses-permission> mechanism.

  Alternate runtimes MUST NOT permit applications to make use of features protected by Android permissions restricted to system applications.

  Alternate runtimes MUST abide by the Android sandbox model. خاصة:

  • Alternate runtimes SHOULD install apps via the PackageManager into separate Android sandboxes (that is, Linux user IDs, etc.)
  • Alternate runtimes MAY provide a single Android sandbox shared by all applications using the alternate runtime.
  • Alternate runtimes and installed applications using an alternate runtime MUST NOT reuse the sandbox of any other app installed on the device, except through the standard Android mechanisms of shared user ID and signing certificate
  • Alternate runtimes MUST NOT launch with, grant, or be granted access to the sandboxes corresponding to other Android applications.

  Alternate runtimes MUST NOT be launched with, be granted, or grant to other applications any privileges of the superuser (root), or of any other user ID.

  The .apk files of alternate runtimes MAY be included in the system image of a device implementation, but MUST be signed with a key distinct from the key used to sign other applications included with the device implementation.

  When installing applications, alternate runtimes MUST obtain user consent for the Android permissions used by the application. That is, if an application needs to make use of a device resource for which there is a corresponding Android permission (such as Camera, GPS, etc.), the alternate runtime MUST inform the user that the application will be able to access that resource . If the runtime environment does not record application capabilities in this manner, the runtime environment MUST list all permissions held by the runtime itself when installing any application using that runtime.

  10. Software Compatibility Testing

  The Android Open-Source Project includes various testing tools to verify that device implementations are compatible. Device implementations MUST pass all tests described in this section.

  However, note that no software test package is fully comprehensive. For this reason, device implementers are very strongly encouraged to make the minimum number of changes as possible to the reference and preferred implementation of Android 2.3 available from the Android Open-Source Project. This will minimize the risk of introducing bugs that create incompatibilities requiring rework and potential device updates.

  10.1. Compatibility Test Suite

  Device implementations MUST pass the Android Compatibility Test Suite (CTS) [ Resources, 2 ] available from the Android Open Source Project, using the final shipping software on the device. Additionally, device implementers SHOULD use the reference implementation in the Android Open Source tree as much as possible, and MUST ensure compatibility in cases of ambiguity in CTS and for any reimplementations of parts of the reference source code.

  The CTS is designed to be run on an actual device. Like any software, the CTS may itself contain bugs. The CTS will be versioned independently of this Compatibility Definition, and multiple revisions of the CTS may be released for Android 2.3. Device implementations MUST pass the latest CTS version available at the time the device software is completed.

  MUST pass the most recent version of the Android Compatibility Test Suite (CTS) available at the time of the device implementation's software is completed. (The CTS is available as part of the Android Open Source Project [ Resources, 2 ].) The CTS tests many, but not all, of the components outlined in this document.

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

  Device implementations MUST correctly execute all applicable cases in the CTS Verifier. The CTS Verifier is included with the Compatibility Test Suite, and is intended to be run by a human operator to test functionality that cannot be tested by an automated system, such as correct functioning of a camera and sensors.

  The CTS Verifier has tests for many kinds of hardware, including some hardware that is optional. Device implementations MUST pass all tests for hardware which they possess; for instance, if a device possesses an accelerometer, it MUST correctly execute the Accelerometer test case in the CTS Verifier. Test cases for features noted as optional by this Compatibility Definition Document MAY be skipped or omitted.

  Every device and every build MUST correctly run the CTS Verifier, as noted above. However, since many builds are very similar, device implementers are not expected to explicitly run the CTS Verifier on builds that differ only in trivial ways. Specifically, device implementations that differ from an implementation that has passed the CTS Verfier only by the set of included locales, branding, etc. MAY omit the CTS Verifier test.

  10.3. Reference Applications

  Device implementers MUST test implementation compatibility using the following open-source applications:

  • The "Apps for Android" applications [ Resources, 43 ].
  • Replica Island (available in Android Market; only required for device implementations that support with OpenGL ES 2.0)

  Each app above MUST launch and behave correctly on the implementation, for the implementation to be considered compatible.

  11. Updatable Software

  Device implementations MUST include a mechanism to replace the entirety of the system software. The mechanism need not perform "live" upgrades -- that is, a device restart MAY be required.

  Any method can be used, provided that it can replace the entirety of the software preinstalled on the device. For instance, any of the following approaches will satisfy this requirement:

  • Over-the-air (OTA) downloads with offline update via reboot
  • "Tethered" updates over USB from a host PC
  • "Offline" updates via a reboot and update from a file on removable storage

  The update mechanism used MUST support updates without wiping user data. Note that the upstream Android software includes an update mechanism that satisfies this requirement.

  If an error is found in a device implementation after it has been released but within its reasonable product lifetime that is determined in consultation with the Android Compatibility Team to affect the compatibility of third-party applications, the device implementer MUST correct the error via a software update available that can be applied per the mechanism just described.

  12. Contact Us

  You can contact the document authors at compatibility@android.com for clarifications and to bring up any issues that you think the document does not cover.

  Appendix A - Bluetooth Test Procedure

  The Compatibility Test Suite includes cases that cover basic operation of the Android RFCOMM Bluetooth API. However, since Bluetooth is a communications protocol between devices, it cannot be fully tested by unit tests running on a single device. Consequently, device implementations MUST also pass the human-operated Bluetooth test procedure described below.

  The test procedure is based on the BluetoothChat sample app included in the Android open-source project tree. The procedure requires two devices:

  • a candidate device implementation running the software build to be tested
  • a separate device implementation already known to be compatible, and of a model from the device implementation being tested -- that is, a "known good" device implementation

  The test procedure below refers to these devices as the "candidate" and "known good" devices, respectively.

  Setup and Installation

  1. Build BluetoothChat.apk via 'make samples' from an Android source code tree.
  2. Install BluetoothChat.apk on the known-good device.
  3. Install BluetoothChat.apk on the candidate device.

  Test Bluetooth Control by Apps

  1. Launch BluetoothChat on the candidate device, while Bluetooth is disabled.
  2. Verify that the candidate device either turns on Bluetooth, or prompts the user with a dialog to turn on Bluetooth.

  Test Pairing and Communication

  1. Launch the Bluetooth Chat app on both devices.
  2. Make the known-good device discoverable from within BluetoothChat (using the Menu).
  3. On the candidate device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the known-good device.
  4. Send 10 or more messages from each device, and verify that the other device receives them correctly.
  5. Close the BluetoothChat app on both devices by pressing Home .
  6. Unpair each device from the other, using the device Settings app.

  Test Pairing and Communication in the Reverse Direction

  1. Launch the Bluetooth Chat app on both devices.
  2. Make the candidate device discoverable from within BluetoothChat (using the Menu).
  3. On the known-good device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the candidate device.
  4. Send 10 or messages from each device, and verify that the other device receives them correctly.
  5. Close the Bluetooth Chat app on both devices by pressing Back repeatedly to get to the Launcher.

  Test Re-Launches

  1. Re-launch the Bluetooth Chat app on both devices.
  2. Send 10 or messages from each device, and verify that the other device receives them correctly.

  Note: the above tests have some cases which end a test section by using Home, and some using Back. These tests are not redundant and are not optional: the objective is to verify that the Bluetooth API and stack works correctly both when Activities are explicitly terminated (via the user pressing Back, which calls finish()), and implicitly sent to background (via the user pressing Home.) Each test sequence MUST be performed as described.