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

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

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

1 المقدمة

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

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

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

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

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

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

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.2 سلاسل الإصدار المسموح بها: http://source.android.com/docs/compatibility/2.2/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. مواصفات Dalvik Virtual Machine: متوفرة في كود مصدر Android، على dalvik/docs
11. أدوات التطبيق: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
12. الإخطارات: http://developer.Android.com/guide/topics/ui/notifiers/notifications.html
13. موارد التطبيق: http://code.google.com/android/reference/available-resources.html
14. دليل نمط رمز شريط الحالة: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
15. مدير البحث: http://developer.android.com/reference/android/app/SearchManager.html
16. الخبز المحمص: http://developer.android.com/reference/android/widget/Toast.html
17. خلفيات حية: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
18. التطبيقات لنظام Android: http://code.google.com/p/apps-for-android
19. وثائق الأداة المرجعية (لـ adb وaapt وddms): http://developer.android.com/guide/developing/tools/index.html
20. وصف ملف Android APK: http://developer.android.com/guide/topics/fundamentals.html
21. ملفات البيان: http://developer.Android.com/guide/topics/manifest/manifest-intro.html
22. أداة اختبار القرد: https://developer.android.com/studio/test/other-testing-tools/monkey
23. قائمة ميزات أجهزة Android: http://developer.android.com/reference/android/content/pm/PackageManager.html
24. دعم شاشات متعددة: http://developer.android.com/guide/practices/screens_support.html
25. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
26. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
27. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
28. مساحة إحداثيات المستشعر: http://developer.android.com/reference/android/hardware/SensorEvent.html
29. مرجع أمان Android والأذونات: http://developer.android.com/guide/topics/security/security.html
30. واجهة برمجة تطبيقات البلوتوث: http://developer.android.com/reference/android/bluetooth/package-summary.html

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

3. البرمجيات

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

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

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

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

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

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

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:

• ساعة مكتب
• المتصفح
• تقويم
• آلة حاسبة
• آلة تصوير
• جهات الاتصال
• بريد إلكتروني
• صالة عرض
• البحث العالمي
• منصة الإطلاق
• LivePicker (أي تطبيق منتقي Live Wallpaper؛ قد يتم حذفه إذا كان الجهاز لا يدعم Live Wallpapers، وفقًا للقسم 3.8.5.)
• المراسلة (المعروفة أيضًا باسم "MMs")
• موسيقى
• هاتف
• إعدادات
• مسجل الصوت

تشتمل تطبيقات نظام 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 تم تجميعه لبنية أجهزة الجهاز المناسبة. يجب أن تتضمن تطبيقات الأجهزة دعمًا للتعليمات البرمجية التي يتم تشغيلها في البيئة المُدارة لاستدعاء التعليمات البرمجية الأصلية، باستخدام دلالات Java Native Interface (JNI) القياسية. يجب أن تكون واجهات برمجة التطبيقات التالية متاحة للتعليمات البرمجية الأصلية:

• ليبك (مكتبة C)
• ليب (مكتبة الرياضيات)
• واجهة جي ان اي
• libz (ضغط Zlib)
• liblog (تسجيل Android)
• الحد الأدنى من الدعم لC++
• دعم OpenGL، كما هو موضح أدناه

يجب أن تدعم تطبيقات الجهاز OpenGL ES 1.0. يجب على الأجهزة التي تفتقر إلى تسريع الأجهزة أن تقوم بتطبيق OpenGL ES 1.0 باستخدام جهاز عرض البرامج. يجب أن تنفذ تطبيقات الأجهزة قدرًا كبيرًا من OpenGL ES 1.1 الذي تدعمه أجهزة الجهاز. يجب أن توفر تطبيقات الأجهزة تطبيقًا لـ OpenGL ES 2.0، إذا كان الجهاز قادرًا على تقديم أداء معقول على واجهات برمجة التطبيقات هذه.

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

يجب أن تبلغ عمليات تنفيذ الجهاز بدقة عن الواجهة الثنائية للتطبيقات (ABI) الأصلية التي يدعمها الجهاز، عبر android.os.Build.CPU_ABI API. يجب أن يكون ABI أحد الإدخالات الموثقة في أحدث إصدار من Android NDK، في الملف docs/CPU-ARCH-ABIS.txt . لاحظ أن الإصدارات الإضافية من Android NDK قد تقدم دعمًا لواجهات 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.2. يتضمن هذا الإصدار مجموعة محددة من إصلاحات الوظائف والأمان لـ 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 ]. يجب أن يتضمن WebView دعمًا لعلامة HTML5 <video> . يجب تعطيل واجهات برمجة تطبيقات HTML5، مثل جميع واجهات برمجة تطبيقات JavaScript، بشكل افتراضي في WebView، ما لم يقم المطور بتمكينها بشكل صريح عبر واجهات برمجة تطبيقات Android المعتادة.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.1. الحاجيات

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

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

3.8.2. إشعارات

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

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

3.8.3. يبحث

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

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

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

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

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

3.8.5. خلفيات حية

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

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

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

4. توافق البرامج المرجعية

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

• الآلة الحاسبة (مضمنة في SDK)
• مركبة الهبوط القمرية (مضمنة في SDK)
• تطبيقات "تطبيقات Android" [ الموارد، 18 ].
• Replica Island (متوفر في Android Market؛ مطلوب فقط لتطبيقات الأجهزة التي تدعم OpenGL ES 2.0)

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

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

• ApiDemos (مضمن في SDK)
• اختبارات الدخان اليدوية (مضمنة في CTS)

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

5. توافق تغليف التطبيقات

يجب أن تقوم تطبيقات الأجهزة بتثبيت وتشغيل ملفات Android ".apk" كما تم إنشاؤها بواسطة أداة "aapt" المضمنة في Android SDK الرسمي [ الموارد، 19 ].

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

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

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

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

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

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

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

6.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.2 ، إلا أنه من المخطط تعريف التوافق لإصدار مستقبلي لتغيير هذه إلى "يجب". أي أن هذه المتطلبات اختيارية في Android 2.2 ولكن ستكون مطلوبة من خلال إصدار مستقبلي. يتم تشجيع الأجهزة الحالية والجديدة التي تدير Android 2.2 Android بشدة على تلبية هذه المتطلبات في Android 2.2 ، أو لن تكون قادرة على توافق Android عند ترقيتها إلى الإصدار المستقبلي.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8.1. عرض

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

لنظام Android 2.2 ، هذه هي أكثر تكوينات العرض شيوعًا:

يجب تكوين تطبيقات الجهاز المقابلة لأحد التكوينات القياسية أعلاه للإبلاغ عن حجم الشاشة المشار إليها للتطبيقات عبر الفئة android.content.res.Configuration [ الموارد ، 24 ].

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

• يجب أن تفسر تطبيقات الأجهزة الموارد في .APK تفتقر إلى مؤهل الكثافة على أنه أمر مخيف لـ "المتوسط" (المعروف باسم "MDPI" في وثائق SDK.)
• عند التشغيل على شاشة "منخفضة" الكثافة ، يجب أن تقطع تطبيقات الأجهزة أصول متوسطة/MDPI بعامل 0.75.
• عند التشغيل على شاشة "عالية الكثافة عالية" ، يجب أن تزيد تطبيقات الأجهزة من الأصول المتوسطة/MDPI بعامل 1.5.
• يجب ألا تقوم تطبيقات الأجهزة بتوسيع نطاق الأصول ضمن نطاق الكثافة ، ويجب أن تقوم بتوسيع نطاق الأصول بواسطة هذه العوامل بالضبط بين نطاقات الكثافة.

8.1.2. تكوينات العرض غير القياسية

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8.6. USB

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

• يجب تنفيذ عميل USB ، قابل للاتصال بمضيف USB مع منفذ USB-A قياسي
• يجب تنفيذ جسر Debug Android على USB (كما هو موضح في القسم 7)
• يجب تنفيذ مواصفات التخزين الشامل USB ، للسماح لمضيف متصل بالجهاز بالوصول إلى محتويات وحدة التخزين /SDCARD
• يجب استخدام عامل شكل USB الصغير على جانب الجهاز
• قد يتضمن منفذًا غير قياسي على جانب الجهاز ، ولكن إذا كان الأمر كذلك ، فيجب شحن كابل قادر على توصيل pinout المخصص إلى منفذ USB-A القياسي
• يجب تنفيذ دعم مواصفات التخزين الشامل USB (بحيث يمكن الوصول إلى سعة تخزين قابلة للإزالة أو ثابتة على الجهاز من جهاز كمبيوتر مضيف)

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

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

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

8.8. شبكات البيانات اللاسلكية

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

إذا كان تطبيق الجهاز يتضمن طريقة معينة تتضمنها Android SDK واجهة برمجة تطبيقات (أي WiFi أو GSM أو CDMA) ، يجب أن يدعم التطبيق واجهة برمجة التطبيقات.

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

8.9. آلة تصوير

يجب أن تتضمن تطبيقات الجهاز كاميرا خلفية. الكاميرا الخلفية المضمنة:

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

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

1. إذا لم يطلق أي تطبيق على Android.hardware.camera.parameters.setpreviewformat (int) ، فيجب على الجهاز استخدام Android.hardware.pixelformat.ycbcr_420_sp لبيانات المعاينة المتوفرة لتراجعات التطبيق.
2. إذا قام أحد التطبيقات بتسجيل مثيل Android.hardware.camera.previewCallback ويقوم النظام باستدعاء طريقة OnPreviewFrame () عندما يكون تنسيق المعاينة YCBCR_420_SP ، يجب أن تكون البيانات الموجودة في البايت [] تم تمريرها إلى OnPreviewFrame () في شكل ترميز NV21. (هذا هو التنسيق الذي يستخدمه عائلة أجهزة 7K.) أي NV21 يجب أن يكون الافتراضي.

يجب أن تنفذ تطبيقات الأجهزة واجهة برمجة تطبيقات الكاميرا الكاملة المضمنة في وثائق Android 2.2 SDK [ الموارد ، 27 ]) ، بغض النظر عما إذا كان الجهاز يتضمن ضبطًا تلقائيًا للأجهزة أو غيرها من القدرات. على سبيل المثال ، لا يزال يتعين على الكاميرات التي تفتقر إلى التركيز التلقائيات الاتصال بأي مثيلات مسجلة android.hardware.Camera.AutoFocusCallback (على الرغم من أن هذا ليس له صلة بكاميرا غير Autofocus.)

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

قد تتضمن تطبيقات الأجهزة كاميرا أمامية. ومع ذلك ، إذا كان تطبيق الجهاز يشتمل على كاميرا أمامية ، فيجب ألا تستخدم API للكاميرا كما تم تنفيذها على الجهاز الكاميرا الأمامية افتراضيًا. أي أن API Camera API في Android 2.2 مخصص للكاميرات الخلفية فقط ، ويجب ألا تعيد تطبيقات الأجهزة أو زيادة تحميل واجهة برمجة التطبيقات للتصرف على كاميرا أمامية ، في حالة وجودها. لاحظ أن أي واجهات برمجة التطبيقات المخصصة التي تمت إضافتها من قبل منفذي الأجهزة لدعم الكاميرات الأمامية يجب أن تلتزم بأقسام 3.5 و 3.6 ؛ على Camera.Parameters المثال ، إذا تم توفير الفئة الفرعية المخصصة android.hardware.Camera . لاحظ أن إدراج كاميرا أمامية لا يفي بالمتطلبات التي تشمل الأجهزة كاميرا خلفية.

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

يجب أن تتضمن تطبيقات الأجهزة مقياس تسارع 3 محاور ويجب أن تكون قادرة على تقديم الأحداث بسرعة 50 هرتز أو أكثر. يجب أن يتوافق نظام الإحداثيات المستخدمة من قبل مقياس التسارع مع نظام إحداثيات Android على النحو المفصل في واجهات برمجة التطبيقات Android (انظر [ الموارد ، 28 ]).

8.11. بوصلة

يجب أن تتضمن تطبيقات الأجهزة بوصلة 3 محاور ويجب أن تكون قادرة على تقديم الأحداث 10 هرتز أو أكثر. يجب أن يتوافق نظام الإحداثيات المستخدمة من قبل البوصلة مع نظام الإحداثيات المستشعر Android على النحو المحدد في API Android (انظر [ الموارد ، 28 ]).

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

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

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

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

انظر أيضًا القسم 8.8 ، شبكات البيانات اللاسلكية.

8.14. الذاكرة والتخزين

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

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

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

8.15. تخزين مشترك التطبيق

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

يجب تكوين تطبيقات الجهاز من خلال التخزين المشترك المثبت بشكل افتراضي ، "Out Of the Box". إذا لم يتم تركيب التخزين المشترك على مسار Linux /sdcard ، فيجب أن يتضمن الجهاز ارتباطًا رمزيًا Linux من /sdcard إلى نقطة التثبيت الفعلية.

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

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

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

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

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

8.16. بلوتوث

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

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

9. توافق الأداء

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

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

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

10.1. الأذونات

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

10.2. UID وعزل العملية

يجب أن تدعم تطبيقات الجهاز نموذج صندوق الرمال Android ، حيث يتم تشغيل كل تطبيق باعتباره UID فريدًا من طراز UNIX وفي عملية منفصلة. يجب أن تدعم تطبيقات الجهاز تشغيل تطبيقات متعددة مثل معرف مستخدم Linux نفسه ، شريطة أن يتم توقيع التطبيقات وبناءها بشكل صحيح ، على النحو المحدد في مرجع الأمن والأذونات [ الموارد ، 29 ].

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

يجب أن تدعم تطبيقات الجهاز نموذج أذونات الوصول إلى ملف Android على النحو المحدد في مرجع الأمان والأذونات [ الموارد ، 29 ].

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

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

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

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

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

يجب أن تلتزم أوقات التشغيل البديلة بنموذج صندوق الرمل Android. خاصة:

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

يجب عدم إطلاق أوقات التشغيل البديلة أو منحها أو منحها للتطبيقات الأخرى أي امتيازات لـ Superuser (ROOT) أو أي معرف مستخدم آخر.

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

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

11. جناح اختبار التوافق

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

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

12. برنامج محدث

يجب أن تتضمن تطبيقات الأجهزة آلية لاستبدال برنامج النظام بالكامل. لا تحتاج الآلية إلى إجراء ترقيات "Live" - ​​أي قد تكون هناك حاجة إلى إعادة تشغيل الجهاز.

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

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

يجب أن تدعم آلية التحديث المستخدمة التحديثات دون مسح بيانات المستخدم. لاحظ أن برنامج Android المنبع يتضمن آلية تحديث يفي بهذا المطلب.

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

13. اتصل بنا

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

التذييل أ - إجراء اختبار بلوتوث

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

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

• تطبيق جهاز مرشح يقوم بتشغيل بنية البرنامج ليتم اختباره
• 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.