تعریف سازگاری اندروید 2.2

با مجموعه‌ها، منظم بمانید ذخیره و دسته‌بندی محتوا براساس اولویت‌های شما.

حق نشر © 2010، Google Inc. کلیه حقوق محفوظ است.
compatibility@android.com

فهرست مطالب

1. مقدمه
2. منابع
3. نرم افزار
4. سازگاری نرم افزار مرجع
5. سازگاری بسته بندی برنامه
6. سازگاری چند رسانه ای
7. سازگاری با ابزار توسعه دهنده
8. سازگاری سخت افزار
9. سازگاری با عملکرد
10. سازگاری مدل امنیتی
11. مجموعه تست سازگاری
12. نرم افزار قابل به روز رسانی
13. تماس با ما
ضمیمه A - روش تست بلوتوث

1. مقدمه

این سند الزاماتی را برشمرده است که برای سازگاری تلفن های همراه با اندروید 2.2 باید رعایت شوند.

استفاده از "باید"، "نباید"، "لازم"، "باید"، "نباید"، "باید"، "نباید"، "توصیه شده"، "ممکن است" و "اختیاری" طبق استاندارد IETF است. تعریف شده در RFC2119 [ منابع، 1 ].

همانطور که در این سند استفاده می‌شود، «پیاده‌کننده دستگاه» یا «اجراکننده» شخص یا سازمانی است که راه‌حل سخت‌افزار/نرم‌افزاری را با Android 2.2 توسعه می‌دهد. "پیاده سازی دستگاه" یا "پیاده سازی" راه حل سخت افزاری/نرم افزاری است که به این شکل توسعه یافته است.

برای اینکه با Android 2.2 سازگار در نظر گرفته شوند، پیاده سازی های دستگاه:

  • باید الزامات ارائه شده در این تعریف سازگاری را برآورده کند، از جمله هر سندی که از طریق مرجع گنجانده شده است.
  • باید آخرین نسخه مجموعه تست سازگاری اندروید (CTS) موجود در زمان اجرای نرم افزار دستگاه را بگذراند. (CTS به عنوان بخشی از پروژه منبع باز Android [ منابع، 2 ] در دسترس است.) CTS بسیاری از مؤلفه های ذکر شده در این سند، اما نه همه آنها را آزمایش می کند.

در مواردی که این تعریف یا CTS بی‌صدا، مبهم یا ناقص است، این مسئولیت اجرای دستگاه است که از سازگاری با پیاده‌سازی‌های موجود اطمینان حاصل کند. به همین دلیل، پروژه منبع باز اندروید [ منابع، 3 ] هم مرجع و هم پیاده سازی ترجیحی اندروید است. پیاده‌سازان دستگاه به شدت تشویق می‌شوند که پیاده‌سازی‌های خود را بر اساس کد منبع «بالادست» موجود در پروژه منبع باز Android قرار دهند. در حالی که برخی از مؤلفه‌ها می‌توانند به طور فرضی با پیاده‌سازی‌های جایگزین جایگزین شوند، این عمل به شدت منع می‌شود، زیرا گذراندن آزمون‌های CTS به طور قابل‌توجهی دشوارتر می‌شود. این مسئولیت پیاده‌کننده است که از سازگاری کامل رفتاری با پیاده‌سازی استاندارد Android، از جمله و فراتر از مجموعه تست سازگاری اطمینان حاصل کند. در نهایت، توجه داشته باشید که تعویض و اصلاح برخی از اجزا به صراحت توسط این سند ممنوع است.

2. منابع

  1. سطوح مورد نیاز IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
  2. مروری بر برنامه سازگاری اندروید: http://source.android.com/compatibility/index.html
  3. پروژه متن باز اندروید: http://source.android.com/
  4. تعاریف و مستندات API: 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/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: در کد منبع Android در dalvik/docs موجود است
  11. AppWidgets: 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. تصاویر پس زمینه زنده: http://developer.android.com/resources/articles/live-wallpapers.html
  18. برنامه های اندروید: http://code.google.com/p/apps-for-android
  19. مستندات ابزار مرجع (برای adb، aapt، ddms): http://developer.android.com/guide/developing/tools/index.html
  20. توضیحات فایل apk اندروید: http://developer.android.com/guide/topics/fundamentals.html
  21. فایل های مانیفست: http://developer.android.com/guide/topics/manifest/manifest-intro.html
  22. ابزار تست میمون: http://developer.android.com/guide/developing/tools/monkey.html
  23. لیست ویژگی های سخت افزار اندروید: 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. API بلوتوث: http://developer.android.com/reference/android/bluetooth/package-summary.html

بسیاری از این منابع به طور مستقیم یا غیرمستقیم از Android 2.2 SDK مشتق شده اند و از نظر عملکردی با اطلاعات موجود در اسناد آن SDK یکسان خواهند بود. در هر موردی که این تعریف سازگاری یا مجموعه تست سازگاری با مستندات SDK مخالف باشد، اسناد SDK معتبر تلقی می‌شوند. هر گونه جزئیات فنی ارائه شده در مراجع ذکر شده در بالا به عنوان بخشی از این تعریف سازگاری در نظر گرفته می شود.

3. نرم افزار

پلتفرم اندروید شامل مجموعه‌ای از APIهای مدیریت‌شده، مجموعه‌ای از APIهای بومی و مجموعه‌ای از APIهای به اصطلاح «نرم» مانند سیستم Intent و APIهای کاربردی وب است. این بخش APIهای سخت و نرمی را که برای سازگاری یکپارچه هستند، و همچنین برخی دیگر از رفتارهای فنی و رابط کاربری مرتبط را توضیح می دهد. پیاده سازی دستگاه باید با تمام الزامات این بخش مطابقت داشته باشد.

3.1. سازگاری API مدیریت شده

محیط اجرای مدیریت شده (مبتنی بر دالویک) وسیله اصلی برنامه های اندروید است. رابط برنامه نویسی برنامه اندروید (API) مجموعه ای از رابط های پلتفرم اندروید است که در معرض برنامه های کاربردی در حال اجرا در محیط VM مدیریت شده قرار دارند. پیاده‌سازی‌های دستگاه باید پیاده‌سازی کامل، از جمله همه رفتارهای مستند، هر API مستندی را که توسط Android 2.2 SDK در معرض نمایش قرار می‌گیرد [ منابع، 4 ] ارائه دهد.

پیاده‌سازی‌های دستگاه نباید هیچ‌یک از APIهای مدیریت‌شده را حذف کنند، رابط‌ها یا امضاهای API را تغییر دهند، از رفتار مستند منحرف شوند، یا شامل موارد بدون عملیات باشند، مگر در مواردی که به‌طور خاص توسط این تعریف سازگاری مجاز است.

3.2. سازگاری نرم افزار API

علاوه بر APIهای مدیریت شده از بخش 3.1، Android همچنین شامل یک API "نرم" فقط زمان اجرا قابل توجه است، به شکل مواردی مانند Intent ها، مجوزها، و جنبه های مشابه برنامه های Android که در زمان کامپایل برنامه قابل اجرا نیستند. این بخش به جزئیات APIهای "نرم" و رفتارهای سیستم مورد نیاز برای سازگاری با Android 2.2 می پردازد. پیاده سازی دستگاه باید تمام الزامات ارائه شده در این بخش را برآورده کند.

3.2.1. مجوزها

پیاده‌کننده‌های دستگاه باید تمام ثابت‌های مجوز را همانطور که در صفحه مرجع مجوز [ منابع، 5 ] مستند شده است، پشتیبانی و اجرا کنند. توجه داشته باشید که بخش 10 الزامات اضافی مربوط به مدل امنیتی اندروید را فهرست می کند.

3.2.2. ساخت پارامترها

APIهای Android شامل تعدادی ثابت در کلاس android.os.Build [ منابع، 6 ] هستند که برای توصیف دستگاه فعلی در نظر گرفته شده است. برای ارائه مقادیر معنادار و منسجم در بین پیاده‌سازی‌های دستگاه، جدول زیر شامل محدودیت‌های اضافی در قالب‌های این مقادیر است که پیاده‌سازی دستگاه باید با آنها مطابقت داشته باشد.

پارامتر نظرات
android.os.Build.VERSION.RELEASE نسخه سیستم اندروید در حال اجرا، در قالب قابل خواندن توسط انسان. این فیلد باید دارای یکی از مقادیر رشته تعریف شده در [ منابع، 7 ] باشد.
android.os.Build.VERSION.SDK نسخه سیستم Android در حال اجرا، در قالبی که برای کد برنامه شخص ثالث قابل دسترسی است. برای اندروید 2.2، این فیلد باید دارای عدد صحیح 8 باشد.
android.os.Build.VERSION.INCREMENTAL مقداری که توسط پیاده‌کننده دستگاه انتخاب شده است که ساختار خاص سیستم Android در حال اجرا را در قالب قابل خواندن توسط انسان تعیین می‌کند. این مقدار نباید برای ساخت‌های مختلفی که در دسترس کاربران نهایی قرار گرفته‌اند دوباره استفاده شود. یک استفاده معمولی از این فیلد این است که نشان دهد کدام شماره ساخت یا شناسه تغییر منبع-کنترل برای تولید بیلد استفاده شده است. هیچ الزامی برای قالب خاص این فیلد وجود ندارد، به جز اینکه نباید خالی یا رشته خالی ("") باشد.
android.os.Build.BOARD مقداری که توسط پیاده‌کننده دستگاه انتخاب می‌شود و سخت‌افزار داخلی خاص مورد استفاده دستگاه را در قالب قابل خواندن توسط انسان شناسایی می‌کند. یکی از کاربردهای احتمالی این فیلد نشان دادن بازبینی خاص برد تغذیه کننده دستگاه است. هیچ الزامی برای قالب خاص این فیلد وجود ندارد، به جز اینکه نباید خالی یا رشته خالی ("") باشد.
android.os.Build.BRAND مقداری که توسط پیاده‌کننده دستگاه انتخاب می‌شود و نام شرکت، سازمان، فردی و غیره را که دستگاه را تولید کرده است، در قالب قابل خواندن توسط انسان مشخص می‌کند. استفاده احتمالی از این فیلد نشان دادن OEM و/یا حاملی است که دستگاه را فروخته است. هیچ الزامی برای قالب خاص این فیلد وجود ندارد، به جز اینکه نباید خالی یا رشته خالی ("") باشد.
android.os.Build.DEVICE مقداری که توسط پیاده‌کننده دستگاه انتخاب می‌شود و پیکربندی یا بازبینی خاص بدنه (که گاهی «طراحی صنعتی» نامیده می‌شود) دستگاه را مشخص می‌کند. هیچ الزامی برای قالب خاص این فیلد وجود ندارد، به جز اینکه نباید خالی یا رشته خالی ("") باشد.
android.os.Build.FINGERPRINT رشته ای که به طور منحصر به فرد این ساخت را شناسایی می کند. باید به طور منطقی برای انسان قابل خواندن باشد. باید از این الگو پیروی کند:
$(BRAND)/$(PRODUCT)/$(DEVICE)/$(BOARD):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
مثلا:
acme/mydevice/generic/generic:2.2/ERC77/3359:userdebug/test-keys
اثر انگشت نباید شامل کاراکترهای فضای خالی باشد. اگر سایر فیلدهای موجود در الگوی بالا دارای نویسه‌های فضای خالی هستند، آنها باید در اثر انگشت ساخت با نویسه دیگری مانند نویسه زیرخط ("_") جایگزین شوند.
android.os.Build.HOST رشته ای که به طور منحصر به فرد میزبانی را که ساخت بر روی آن ساخته شده است، در قالب قابل خواندن توسط انسان، شناسایی می کند. هیچ الزامی برای قالب خاص این فیلد وجود ندارد، به جز اینکه نباید خالی یا رشته خالی ("") باشد.
android.os.Build.ID شناسه‌ای که توسط پیاده‌کننده دستگاه برای ارجاع به یک نسخه خاص، در قالب قابل خواندن توسط انسان انتخاب شده است. این فیلد می تواند همان android.os.Build.VERSION.INCREMENTAL باشد، اما باید مقداری باشد که به اندازه کافی معنی دار باشد تا کاربران نهایی بتوانند بین ساخت های نرم افزار تمایز قائل شوند. هیچ الزامی برای قالب خاص این فیلد وجود ندارد، به جز اینکه نباید خالی یا رشته خالی ("") باشد.
android.os.Build.MODEL مقداری که توسط پیاده‌کننده دستگاه انتخاب شده و حاوی نام دستگاهی است که کاربر نهایی آن را می‌شناسد. این باید همان نامی باشد که دستگاه تحت آن به بازار عرضه شده و به کاربران نهایی فروخته می شود. هیچ الزامی برای قالب خاص این فیلد وجود ندارد، به جز اینکه نباید خالی یا رشته خالی ("") باشد.
android.os.Build.PRODUCT مقداری که توسط پیاده‌کننده دستگاه انتخاب می‌شود و حاوی نام توسعه یا نام کد دستگاه است. باید برای انسان قابل خواندن باشد، اما لزوماً برای مشاهده توسط کاربران نهایی در نظر گرفته نشده است. هیچ الزامی برای قالب خاص این فیلد وجود ندارد، به جز اینکه نباید خالی یا رشته خالی ("") باشد.
android.os.Build.TAGS فهرستی از برچسب‌های جدا شده با کاما که توسط پیاده‌کننده دستگاه انتخاب شده‌اند که ساخت را بیشتر متمایز می‌کند. به عنوان مثال، "unsigned, debug". این فیلد نباید تهی یا رشته خالی ("") باشد، اما یک تگ واحد (مانند "release") خوب است.
android.os.Build.TIME مقداری که نشان‌دهنده مُهر زمانی زمان وقوع ساخت است.
android.os.Build.TYPE مقداری که توسط پیاده‌کننده دستگاه انتخاب شده و پیکربندی زمان اجرا ساخت را مشخص می‌کند. این فیلد باید یکی از مقادیر مربوط به سه پیکربندی معمول زمان اجرا اندروید را داشته باشد: "user"، "userdbug"، یا "eng".
android.os.Build.USER نام یا شناسه کاربری کاربر (یا کاربر خودکار) که ساخت را ایجاد کرده است. هیچ الزامی برای قالب خاص این فیلد وجود ندارد، به جز اینکه نباید خالی یا رشته خالی ("") باشد.

3.2.3. سازگاری قصد

Android از Intent برای دستیابی به یکپارچگی آزادانه بین برنامه‌ها استفاده می‌کند. این بخش الزامات مربوط به الگوهای Intent را شرح می دهد که باید توسط پیاده سازی دستگاه رعایت شوند. منظور از "honored" این است که پیاده‌کننده دستگاه باید یک فعالیت یا سرویس Android ارائه دهد که فیلتر Intent منطبق را مشخص می‌کند و به هر الگوی Intent مشخص شده متصل می‌شود و رفتار صحیح را اجرا می‌کند.

3.2.3.1. اهداف اصلی برنامه

پروژه بالادستی اندروید تعدادی برنامه اصلی مانند شماره گیر تلفن، تقویم، کتاب مخاطبین، پخش کننده موسیقی و غیره را تعریف می کند. پیاده‌کننده‌های دستگاه ممکن است این برنامه‌ها را با نسخه‌های جایگزین جایگزین کنند.

با این حال، هر گونه نسخه جایگزین باید از همان الگوهای Intent ارائه شده توسط پروژه بالادستی استفاده کند. به عنوان مثال، اگر دستگاهی حاوی یک پخش کننده موسیقی جایگزین باشد، همچنان باید الگوی Intent صادر شده توسط برنامه های شخص ثالث را برای انتخاب آهنگ رعایت کند.

برنامه های زیر به عنوان برنامه های اصلی سیستم اندروید در نظر گرفته می شوند:

  • ساعت رومیزی
  • مرورگر
  • تقویم
  • ماشین حساب
  • دوربین
  • مخاطب
  • پست الکترونیک
  • گالری
  • جستجوی جهانی
  • پرتاب کننده
  • LivePicker (یعنی برنامه انتخابگر تصویر زمینه زنده؛ ممکن است در صورت عدم پشتیبانی دستگاه از تصاویر پس زمینه زنده، طبق بخش 3.8.5 حذف شود.)
  • پیام رسانی (با نام مستعار "Mms")
  • موسیقی
  • تلفن
  • تنظیمات
  • ضبط کننده صدا

برنامه های اصلی سیستم اندروید شامل اجزای مختلف Activity یا Service هستند که "عمومی" در نظر گرفته می شوند. به این معنی که ویژگی "android:exported" ممکن است وجود نداشته باشد یا مقدار "true" را داشته باشد.

برای هر فعالیت یا سرویسی که در یکی از برنامه‌های اصلی سیستم Android تعریف شده است و از طریق ویژگی android:exported با مقدار "false" به‌عنوان غیرعمومی علامت‌گذاری نشده است، پیاده‌سازی دستگاه باید شامل یک مولفه از همان نوع باشد که فیلتر Intent یکسان را اجرا می‌کند. الگوها به عنوان برنامه اصلی سیستم اندروید.

به عبارت دیگر، پیاده سازی دستگاه ممکن است جایگزین برنامه های اصلی سیستم اندروید شود. با این حال، اگر چنین باشد، پیاده‌سازی دستگاه باید از همه الگوهای Intent که توسط هر برنامه اصلی سیستم اندرویدی که جایگزین می‌شود، پشتیبانی کند.

3.2.3.2. نادیده گرفتن قصد

از آنجایی که Android یک پلتفرم توسعه‌پذیر است، پیاده‌کننده‌های دستگاه باید اجازه دهند هر الگوی Intent که در بخش 3.2.3.1 به آن اشاره شده است، توسط برنامه‌های شخص ثالث لغو شود. پروژه منبع باز Android Upstream به طور پیش فرض این امکان را می دهد. پیاده‌کننده‌های دستگاه نباید امتیازات ویژه‌ای را به استفاده برنامه‌های سیستمی از این الگوهای Intent اختصاص دهند یا از اتصال برنامه‌های شخص ثالث به این الگوها و کنترل آن‌ها جلوگیری کنند. این ممنوعیت به طور خاص شامل غیرفعال کردن رابط کاربری "انتخاب کننده" است که به کاربر اجازه می دهد بین برنامه های متعددی که همه یک الگوی Intent را مدیریت می کنند، انتخاب کند، اما محدود به آن نمی شود.

3.2.3.3. Intent Namespaces

پیاده‌کننده‌های دستگاه نباید هیچ مؤلفه Android را دربرگیرند که الگوهای Intent یا Broadcast Intent جدید را با استفاده از ACTION، CATEGORY یا رشته کلیدهای دیگر در فضای نام android.* مورد احترام قرار دهد. پیاده‌کننده‌های دستگاه نباید دارای اجزای Android باشند که از الگوهای Intent یا Broadcast Intent با استفاده از ACTION، CATEGORY یا رشته‌های کلیدی دیگر در فضای بسته متعلق به سازمان دیگری استفاده می‌کنند. پیاده‌کننده‌های دستگاه نباید هیچ یک از الگوهای Intent را که توسط برنامه‌های اصلی فهرست‌شده در بخش 3.2.3.1 استفاده می‌شود، تغییر داده یا گسترش دهند.

این ممنوعیت مشابه آن چیزی است که برای کلاس های زبان جاوا در بخش 3.6 مشخص شده است.

3.2.3.4. اهداف پخش

برنامه های شخص ثالث برای پخش Intent های خاص به پلتفرم متکی هستند تا تغییرات در محیط سخت افزاری یا نرم افزاری را به آنها اطلاع دهند. دستگاه های سازگار با Android باید Intent های پخش عمومی را در پاسخ به رویدادهای سیستم مناسب پخش کنند. اهداف پخش در مستندات SDK توضیح داده شده است.

3.3. سازگاری Native API

کدهای مدیریت شده در حال اجرا در Dalvik می توانند به کد بومی ارائه شده در فایل apk برنامه کاربردی به عنوان یک فایل ELF .so که برای معماری سخت افزاری مناسب دستگاه کامپایل شده است فراخوانی کند. پیاده سازی دستگاه باید شامل پشتیبانی از کدهای در حال اجرا در محیط مدیریت شده برای فراخوانی کد بومی با استفاده از معناشناسی استاندارد Java Native Interface (JNI) باشد. APIهای زیر باید برای کد بومی در دسترس باشند:

  • libc (کتابخانه C)
  • libm (کتابخانه ریاضی)
  • رابط JNI
  • libz (فشرده سازی Zlib)
  • liblog (لاگ اندروید)
  • حداقل پشتیبانی از C++
  • پشتیبانی از OpenGL، همانطور که در زیر توضیح داده شده است

پیاده سازی دستگاه باید از OpenGL ES 1.0 پشتیبانی کند. دستگاه‌هایی که فاقد شتاب سخت‌افزاری هستند، باید OpenGL ES 1.0 را با استفاده از رندر نرم‌افزار پیاده‌سازی کنند. پیاده سازی های دستگاه باید به همان اندازه OpenGL ES 1.1 را اجرا کند که سخت افزار دستگاه پشتیبانی می کند. اگر سخت‌افزار قادر به عملکرد معقول در آن APIها باشد، پیاده‌سازی‌های دستگاه باید یک پیاده‌سازی برای OpenGL ES 2.0 ارائه دهند.

این کتابخانه ها باید با نسخه های ارائه شده در Bionic توسط پروژه منبع باز Android سازگار با منبع (به عنوان مثال سازگار با هدر) و سازگار با دودویی (برای معماری پردازنده معین) باشند. از آنجایی که پیاده‌سازی‌های 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.webkit.WebView باشد که با نرم‌افزار بالادستی Android سازگار است، و باید شامل یک مرورگر مدرن با قابلیت HTML5 باشد، همانطور که در زیر توضیح داده شد.

3.4.1. سازگاری WebView

اجرای متن باز Android از موتور رندر WebKit برای پیاده سازی android.webkit.WebView استفاده می کند. از آنجایی که امکان توسعه یک مجموعه آزمایشی جامع برای یک سیستم رندر وب وجود ندارد، پیاده‌کنندگان دستگاه باید از ساخت بالادستی خاص WebKit در پیاده‌سازی WebView استفاده کنند. به طور مشخص:

  • اجرای پیاده‌سازی‌های دستگاه android.webkit.WebView باید بر اساس ساخت WebKit 533.1 از درخت متن باز 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، حافظه پنهان برنامه، و APIهای مکان جغرافیایی باشد [ منابع، 9 ]. WebView باید از تگ <video> HTML5 پشتیبانی کند. APIهای HTML5، مانند همه APIهای جاوا اسکریپت، باید به طور پیش‌فرض در WebView غیرفعال شوند، مگر اینکه توسعه‌دهنده صریحاً آنها را از طریق APIهای معمول Android فعال کند.

3.4.2. سازگاری مرورگر

پیاده سازی دستگاه باید شامل یک برنامه مرورگر مستقل برای مرور وب کاربر عمومی باشد. ممکن است مرورگر مستقل مبتنی بر فناوری مرورگری غیر از WebKit باشد. با این حال، حتی اگر یک برنامه مرورگر جایگزین ارسال شود، مؤلفه android.webkit.WebView ارائه شده به برنامه های شخص ثالث باید بر اساس WebKit باشد، همانطور که در بخش 3.4.1 توضیح داده شد.

پیاده سازی ها ممکن است یک رشته عامل کاربر سفارشی را در برنامه مرورگر مستقل ارسال کنند.

برنامه مرورگر مستقل (چه بر اساس برنامه مرورگر WebKit بالادست یا یک جایگزین شخص ثالث) باید تا حد امکان از HTML5 [ منابع، 9 ] پشتیبانی کند. حداقل، پیاده‌سازی دستگاه باید از موقعیت جغرافیایی HTML5، حافظه پنهان برنامه، و APIهای پایگاه داده و تگ <video> در برنامه مرورگر مستقل پشتیبانی کند.

3.5. سازگاری رفتاری API

رفتارهای هر یک از انواع API (مدیریت شده، نرم، بومی و وب) باید با اجرای ترجیحی پروژه منبع باز Android بالادستی مطابقت داشته باشد [ Resources, 3 ]. برخی از زمینه های خاص سازگاری عبارتند از:

  • دستگاه ها نباید رفتار یا معنای یک Intent استاندارد را تغییر دهند
  • دستگاه ها نباید چرخه عمر یا چرخه حیات معنایی نوع خاصی از اجزای سیستم (مانند سرویس، فعالیت، ارائه دهنده محتوا و غیره) را تغییر دهند.
  • دستگاه ها نباید معنای یک مجوز خاص را تغییر دهند

فهرست بالا جامع نیست و مسئولیت اطمینان از سازگاری رفتاری بر عهده پیاده‌کنندگان دستگاه است. به همین دلیل، پیاده‌کننده‌های دستگاه باید در صورت امکان از کد منبع موجود از طریق پروژه منبع باز Android استفاده کنند، نه اینکه بخش‌های مهمی از سیستم را دوباره پیاده‌سازی کنند.

مجموعه تست سازگاری (CTS) بخش های قابل توجهی از پلت فرم را برای سازگاری رفتاری آزمایش می کند، اما نه همه آنها. اطمینان از سازگاری رفتاری با پروژه متن باز اندروید بر عهده مجری است.

3.6. فضاهای نام API

اندروید از قراردادهای فضای نام بسته و کلاس تعریف شده توسط زبان برنامه نویسی جاوا پیروی می کند. برای اطمینان از سازگاری با برنامه‌های شخص ثالث، پیاده‌کننده‌های دستگاه نباید هیچ گونه تغییر ممنوعه (به زیر را ببینید) در این فضاهای نام بسته ایجاد کنند:

  • جاوا.*
  • javax.*
  • آفتاب.*
  • اندروید.*
  • com.android.*

تغییرات ممنوعه عبارتند از:

  • پیاده‌سازی‌های دستگاه نباید با تغییر هر روش یا امضای کلاس، یا با حذف کلاس‌ها یا فیلدهای کلاس، APIهای در معرض عموم در پلتفرم Android را تغییر دهند.
  • پیاده‌کننده‌های دستگاه ممکن است پیاده‌سازی اساسی APIها را تغییر دهند، اما چنین تغییراتی نباید بر رفتار بیان‌شده و امضای زبان جاوا هر یک از API‌های در معرض عموم تأثیر بگذارد.
  • پیاده‌کننده‌های دستگاه نباید هیچ عنصری که به‌صورت عمومی در معرض دید قرار می‌گیرد (مانند کلاس‌ها یا رابط‌ها، یا فیلدها یا روش‌ها به کلاس‌ها یا رابط‌های موجود) به APIهای بالا اضافه کنند.

"عنصر در معرض عموم" هر ساختاری است که با نشانگر "@hide" در کد منبع بالادست Android تزئین نشده باشد. به عبارت دیگر، پیاده‌کننده‌های دستگاه نباید APIهای جدید را افشا کنند یا APIهای موجود را در فضاهای نام ذکر شده در بالا تغییر دهند. پیاده‌کننده‌های دستگاه ممکن است تغییراتی را فقط داخلی انجام دهند، اما این تغییرات نباید تبلیغ شوند یا در معرض دید توسعه‌دهندگان قرار گیرند.

پیاده‌کننده‌های دستگاه ممکن است APIهای سفارشی اضافه کنند، اما چنین API‌هایی نباید در فضای نام متعلق به سازمان دیگری باشند یا به آن ارجاع دهند. برای مثال، پیاده‌کننده‌های دستگاه نباید API را به com.google.* یا فضای نام مشابه اضافه کنند. فقط گوگل می تواند این کار را انجام دهد. به طور مشابه، Google نباید API را به فضای نام شرکت‌های دیگر اضافه کند.

اگر پیاده‌کننده دستگاه پیشنهاد کند یکی از فضاهای نام بسته بالا را بهبود بخشد (مانند افزودن عملکرد مفید جدید به یک API موجود، یا افزودن یک API جدید)، پیاده‌کننده باید از source.android.com بازدید کند و فرآیند ایجاد تغییرات و تغییرات را آغاز کند. کد، با توجه به اطلاعات آن سایت.

توجه داشته باشید که محدودیت‌های بالا با قراردادهای استاندارد برای نام‌گذاری APIها در زبان برنامه‌نویسی جاوا مطابقت دارد. هدف این بخش صرفاً تقویت آن قراردادها و الزام آور ساختن آنها از طریق گنجاندن در این تعریف سازگاری است.

3.7. سازگاری با ماشین مجازی

پیاده‌سازی‌های دستگاه باید از مشخصات بایت کد کامل Dalvik Executable (DEX) و معناشناسی ماشین مجازی Dalvik پشتیبانی کنند [ منابع، 10 ].

پیاده سازی دستگاه با صفحه نمایش طبقه بندی شده به عنوان تراکم متوسط ​​یا کم باید Dalvik را طوری پیکربندی کند که حداقل 16 مگابایت حافظه به هر برنامه اختصاص دهد. پیاده سازی دستگاه با صفحه نمایش طبقه بندی شده به عنوان با چگالی بالا باید Dalvik را برای تخصیص حداقل 24 مگابایت حافظه به هر برنامه پیکربندی کند. توجه داشته باشید که پیاده سازی دستگاه ممکن است حافظه بیشتری نسبت به این ارقام اختصاص دهد.

3.8. سازگاری با رابط کاربری

پلتفرم اندروید شامل برخی از API های توسعه دهنده است که به توسعه دهندگان اجازه می دهد تا به رابط کاربری سیستم متصل شوند. پیاده‌سازی دستگاه باید این APIهای استاندارد UI را در رابط‌های کاربری سفارشی که در زیر توضیح داده شده است، بگنجانند.

3.8.1. ابزارک ها

Android یک نوع مؤلفه و API و چرخه حیات متناظر را تعریف می‌کند که به برنامه‌ها اجازه می‌دهد «AppWidget» را در معرض کاربر نهایی قرار دهند [ Resources, 11 ]. نسخه مرجع منبع باز Android شامل یک برنامه راه‌انداز است که شامل عناصر رابط کاربری است که به کاربر اجازه می‌دهد AppWidgets را از صفحه اصلی اضافه، مشاهده و حذف کند.

پیاده‌کننده‌های دستگاه ممکن است جایگزینی را برای راه‌انداز مرجع (یعنی صفحه اصلی) جایگزین کنند. راه‌اندازهای جایگزین باید شامل پشتیبانی داخلی برای AppWidgets باشند و عناصر رابط کاربری را برای افزودن، پیکربندی، مشاهده و حذف AppWidgets مستقیماً در Launcher در معرض دید قرار دهند. راه‌اندازهای جایگزین ممکن است این عناصر رابط کاربری را حذف کنند. با این حال، اگر آنها حذف شوند، پیاده‌کننده دستگاه باید یک برنامه کاربردی جداگانه در دسترس از راه‌انداز ارائه دهد که به کاربران اجازه می‌دهد AppWidgets را اضافه، پیکربندی، مشاهده و حذف کنند.

3.8.2. اطلاعیه

Android شامل APIهایی است که به توسعه دهندگان اجازه می دهد تا کاربران را از رویدادهای قابل توجه آگاه کنند [ منابع، 12 ]. پیاده‌کننده‌های دستگاه باید برای هر کلاس از اعلان‌های تعریف شده پشتیبانی ارائه دهند. به طور خاص: صداها، لرزش، نور و نوار وضعیت.

به‌علاوه، پیاده‌سازی باید به‌درستی تمام منابع (آیکون‌ها، فایل‌های صوتی و غیره) ارائه‌شده در APIها [ منابع، 13 ]، یا در راهنمای سبک نماد نوار وضعیت [ منابع، 14 ] را به‌درستی ارائه کند. پیاده‌کننده‌های دستگاه ممکن است یک تجربه کاربری جایگزین برای اعلان‌ها نسبت به آنچه که توسط پیاده‌سازی منبع باز Android ارائه می‌شود، ارائه دهند. با این حال، چنین سیستم های اعلان جایگزین باید منابع اعلان موجود را پشتیبانی کنند.

Android شامل APIهایی است [ منابع، 15 ] که به توسعه دهندگان اجازه می دهد جستجو را در برنامه های خود بگنجانند و داده های برنامه خود را در جستجوی سیستم جهانی قرار دهند. به طور کلی، این عملکرد از یک رابط کاربری واحد و گسترده تشکیل شده است که به کاربران امکان می دهد پرس و جوها را وارد کنند، پیشنهادات را در حین تایپ کاربران نمایش دهد و نتایج را نمایش دهد. APIهای Android به توسعه دهندگان این امکان را می دهند که از این رابط برای ارائه جستجو در برنامه های خود مجدد استفاده کنند و به توسعه دهندگان اجازه می دهد تا نتایج را به رابط کاربری مشترک جستجوی جهانی ارائه دهند.

پیاده‌سازی دستگاه باید شامل یک رابط کاربری جستجوی واحد، مشترک و در سراسر سیستم باشد که قادر به ارائه پیشنهادات بلادرنگ در پاسخ به ورودی کاربر باشد. پیاده‌سازی‌های دستگاه باید API‌هایی را پیاده‌سازی کنند که به توسعه‌دهندگان اجازه می‌دهد تا از این رابط کاربری مجدد برای ارائه جستجو در برنامه‌های خود استفاده کنند. پیاده‌سازی‌های دستگاه باید APIهایی را اجرا کنند که به برنامه‌های شخص ثالث اجازه می‌دهند تا پیشنهاداتی را به جعبه جستجو در حالت جستجوی سراسری اجرا کنند. اگر هیچ برنامه شخص ثالثی نصب نشده است که از این قابلیت استفاده کند، رفتار پیش فرض باید نمایش نتایج و پیشنهادات موتور جستجوی وب باشد.

پیاده‌سازی‌های دستگاه ممکن است رابط‌های کاربر جستجوی جایگزین ارسال کنند، اما باید شامل یک دکمه جستجوی اختصاصی سخت یا نرم باشد که می‌تواند در هر زمان در هر برنامه برای فراخوانی چارچوب جستجو، با رفتار ارائه‌شده در اسناد API استفاده شود.

3.8.4. نان تست

برنامه ها می توانند از "Toast" API (تعریف شده در [ منابع، 16 ]) برای نمایش رشته های کوتاه غیرمدال به کاربر نهایی استفاده کنند که پس از مدت کوتاهی ناپدید می شوند. پیاده‌سازی دستگاه باید نان تست‌ها را از برنامه‌ها برای کاربران نهایی به شیوه‌ای با دید بالا نمایش دهد.

3.8.5. تصاویر پس زمینه زنده

Android یک نوع مؤلفه و API و چرخه حیات متناظر را تعریف می‌کند که به برنامه‌ها اجازه می‌دهد یک یا چند «تصویر زمینه زنده» را در معرض دید کاربر نهایی قرار دهند [ منابع، 17 ]. تصاویر پس زمینه زنده انیمیشن ها، الگوها یا تصاویر مشابه با قابلیت های ورودی محدود هستند که به عنوان تصویر زمینه پشت برنامه های دیگر نمایش داده می شوند.

سخت افزار در صورتی که بتواند تمام تصاویر پس زمینه زنده را بدون محدودیت در عملکرد، با نرخ فریم معقول و بدون تأثیر منفی بر سایر برنامه ها اجرا کند، می تواند به طور قابل اعتماد تصاویر پس زمینه زنده را اجرا کند. اگر محدودیت‌های سخت‌افزاری باعث از کار افتادن والپیپرها و/یا برنامه‌ها، اختلال در عملکرد، مصرف بیش از حد پردازنده یا انرژی باتری یا اجرا با نرخ فریم غیرقابل قبول پایین شود، سخت‌افزار در اجرای تصویر زمینه زنده ناتوان در نظر گرفته می‌شود. به عنوان مثال، برخی از تصاویر پس زمینه زنده ممکن است از یک زمینه Open GL 1.0 یا 2.0 برای ارائه محتوای خود استفاده کنند. کاغذدیواری زنده روی سخت‌افزاری که از چندین زمینه OpenGL پشتیبانی نمی‌کند، قابل اطمینان اجرا نمی‌شود، زیرا استفاده از کاغذدیواری زنده از یک زمینه OpenGL ممکن است با سایر برنامه‌هایی که از زمینه OpenGL نیز استفاده می‌کنند تضاد داشته باشد.

پیاده‌سازی‌های دستگاهی که قادر به اجرای مطمئن تصاویر پس زمینه زنده هستند، همانطور که در بالا توضیح داده شد، باید تصاویر پس زمینه زنده را اجرا کنند. پیاده‌سازی‌های دستگاهی که تصمیم گرفته‌اند والپیپرهای زنده را به‌طور قابل اعتماد اجرا نکنند، همانطور که در بالا توضیح داده شد، نباید والپیپرهای زنده را اجرا کنند.

4. سازگاری نرم افزار مرجع

پیاده‌کننده‌های دستگاه باید سازگاری پیاده‌سازی را با استفاده از برنامه‌های منبع باز زیر آزمایش کنند:

  • ماشین حساب (شامل در SDK)
  • لندر قمری (شامل در SDK)
  • برنامه های کاربردی "برنامه های اندروید" [ منابع، 18 ].
  • Replica Island (موجود در Android Market؛ فقط برای پیاده‌سازی دستگاهی که از OpenGL ES 2.0 پشتیبانی می‌کند لازم است)

هر برنامه فوق باید راه اندازی شود و در اجرای آن به درستی رفتار کند تا پیاده سازی سازگار در نظر گرفته شود.

علاوه بر این، پیاده‌سازی دستگاه باید هر آیتم منو (از جمله همه زیر منوها) هر یک از این برنامه‌های تست دود را آزمایش کند:

  • ApiDemos (شامل در SDK)
  • ManualSmokeTests (شامل در CTS)

هر مورد آزمایشی در برنامه های فوق باید به درستی در اجرای دستگاه اجرا شود.

5. سازگاری بسته بندی برنامه

پیاده‌سازی‌های دستگاه باید فایل‌های Android ".apk" را همانطور که توسط ابزار "aapt" موجود در SDK رسمی Android [ منابع، 19 ] تولید می‌شود، نصب و اجرا کنند.

پیاده‌سازی دستگاه‌ها نباید فرمت‌های apk [ Resources, 20 ]، Android Manifest [ Resources, 21 ]، یا بایت کد Dalvik [ Resources, 10 ] را به گونه‌ای گسترش دهند که از نصب و اجرای صحیح آن فایل‌ها در سایر دستگاه‌های سازگار جلوگیری کند. . پیاده‌کننده‌های دستگاه باید از پیاده‌سازی بالادستی مرجع Dalvik و سیستم مدیریت بسته پیاده‌سازی مرجع استفاده کنند.

6. سازگاری چند رسانه ای

پیاده سازی دستگاه باید به طور کامل همه API های چند رسانه ای را پیاده سازی کند. پیاده سازی دستگاه باید شامل پشتیبانی از همه کدک های چندرسانه ای شرح داده شده در زیر باشد، و باید دستورالعمل های پردازش صدا را که در زیر توضیح داده شده است رعایت کند.

6.1. کدک های رسانه ای

پیاده سازی دستگاه باید از کدک های چند رسانه ای زیر پشتیبانی کند. همه این کدک ها به عنوان پیاده سازی نرم افزار در پیاده سازی ترجیحی اندروید از پروژه متن باز اندروید ارائه شده اند.

لطفاً توجه داشته باشید که نه Google و نه Open Handset Alliance هیچ اظهارنظری مبنی بر اینکه این کدک‌ها توسط پتنت‌های شخص ثالث بدون محدودیت هستند، ارائه نمی‌کنند. به کسانی که قصد استفاده از این کد منبع را در محصولات سخت‌افزاری یا نرم‌افزاری دارند، توصیه می‌شود که اجرای این کد، از جمله در نرم‌افزار منبع باز یا اشتراک‌افزار، ممکن است به مجوزهای پتنت از دارندگان پتنت مربوطه نیاز داشته باشد.

سمعی
نام رمزگذار رمزگشا جزئیات فرمت فایل/کانتینر
AAC LC/LTP ایکس محتوای مونو/استریو در هر ترکیبی از نرخ بیت استاندارد تا 160 کیلوبیت بر ثانیه و نرخ نمونه برداری بین 8 تا 48 کیلوهرتز 3GPP (.3gp) و MPEG-4 (.mp4، .m4a). بدون پشتیبانی از AAC خام (.aac)
HE-AACv1 (AAC+) ایکس
HE-AACv2 (AAC+ پیشرفته) ایکس
AMR-NB ایکس ایکس نمونه برداری از 4.75 تا 12.2 کیلوبیت بر ثانیه @ 8kHz 3GPP (.3gp)
AMR-WB ایکس 9 نرخ از 6.60 کیلوبیت بر ثانیه تا 23.85 کیلوبیت بر ثانیه نمونه برداری در 16 کیلوهرتز 3GPP (.3gp)
MP3 ایکس ثابت مونو/استریو 8-320 کیلوبیت بر ثانیه (CBR) یا نرخ بیت متغیر (VBR) MP3 (mp3.)
MIDI ایکس MIDI نوع 0 و 1. DLS نسخه 1 و 2. XMF و Mobile XMF. پشتیبانی از فرمت های آهنگ زنگ RTTTL/RTX، OTA و iMelody نوع 0 و 1 (mid، .xmf، .mxmf). همچنین RTTTL/RTX (rtttl، .rtx)، OTA (ota.) و iMelody (imy.)
اوگ وربیس ایکس Ogg (.ogg)
PCM ایکس PCM خطی 8 و 16 بیتی (نرخ تا سقف سخت افزار) موج (.wav)
تصویر
JPEG ایکس ایکس پایه + پیشرو
GIF ایکس
PNG ایکس ایکس
BMP ایکس
ویدئو
H.263 ایکس ایکس فایل های 3GPP (.3gp).
H.264 ایکس فایل های 3GPP (.3gp) و MPEG-4 (.mp4).
نمایه ساده MPEG4 ایکس فایل 3GPP (.3gp).

توجه داشته باشید که جدول بالا الزامات نرخ بیت خاصی را برای اکثر کدک های ویدیویی فهرست نمی کند. دلیل این امر این است که در عمل، سخت افزار دستگاه فعلی لزوماً از بیت ریت هایی پشتیبانی نمی کند که دقیقاً مطابق با بیت ریت های مورد نیاز تعیین شده توسط استانداردهای مربوطه نگاشت شوند. درعوض، پیاده‌سازی‌های دستگاه باید بالاترین نرخ بیت عملی را در سخت‌افزار، تا حد تعیین‌شده توسط مشخصات، پشتیبانی کنند.

6.2. ضبط صدا

وقتی برنامه‌ای از android.media.AudioRecord API برای شروع ضبط یک جریان صوتی استفاده می‌کند، پیاده‌سازی‌های دستگاه باید با هر یک از این رفتارها صدا را نمونه‌برداری و ضبط کنند:

  • پردازش کاهش نویز، در صورت وجود، باید غیرفعال شود.
  • کنترل بهره خودکار، در صورت وجود، باید غیرفعال شود.
  • دستگاه باید دامنه تقریباً مسطح نسبت به ویژگی های فرکانس را نشان دهد. به طور خاص، ± dB، از 100 هرتز تا 4000 هرتز
  • حساسیت ورودی صدا باید به گونه ای تنظیم شود که یک منبع سطح توان صوتی 90 دسی بل (SPL) در 1000 هرتز RMS 5000 را برای نمونه های 16 بیتی ارائه دهد.
  • سطوح دامنه PCM باید تغییرات SPL ورودی را حداقل در محدوده 30 دسی بل از 18- تا 12 دسی بل و 90 دسی بل SPL در میکروفون به صورت خطی ردیابی کند.
  • اعوجاج هارمونیک کل باید از 100 هرتز تا 4000 هرتز در سطح ورودی 90 دسی بل SPL کمتر از 1٪ باشد.

توجه: در حالی که الزامات ذکر شده در بالا به عنوان "SHOULD" برای Android 2.2 بیان شده است، تعریف سازگاری برای نسخه آینده برنامه ریزی شده است که این موارد را به "MUST" تغییر دهد. یعنی این الزامات در اندروید 2.2 اختیاری هستند اما در نسخه بعدی مورد نیاز خواهند بود. دستگاه‌های موجود و جدید که Android 2.2 Android را اجرا می‌کنند، بسیار تشویق می‌شوند که این الزامات را در Android 2.2 برآورده کنند ، یا در صورت ارتقا به نسخه آینده، نمی‌توانند به سازگاری Android دست یابند.

6.3. تأخیر صوتی

تأخیر صوتی به طور کلی به عنوان فاصله زمانی بین زمانی که یک برنامه کاربردی یک عملیات پخش یا ضبط صدا را درخواست می کند و زمانی که پیاده سازی دستگاه عملاً عملیات را آغاز می کند، تعریف می شود. بسیاری از کلاس‌های برنامه‌ها برای دستیابی به جلوه‌های بلادرنگ مانند جلوه‌های صوتی یا ارتباطات VOIP به تأخیرهای کوتاه متکی هستند. پیاده‌سازی دستگاه باید تمام الزامات تأخیر صوتی را که در این بخش بیان شده است برآورده کند.

برای اهداف این بخش:

  • "تأخیر خروجی سرد" به فاصله زمانی بین زمانی که یک برنامه پخش صدا را درخواست می کند و زمانی که صدا شروع به پخش می کند، زمانی که سیستم صوتی قبل از درخواست بیکار بوده و خاموش شده است، تعریف می شود.
  • "تأخیر خروجی گرم" به فاصله زمانی بین زمانی که یک برنامه درخواست پخش صدا می کند و زمانی که صدا شروع به پخش می کند، زمانی که سیستم صوتی اخیرا استفاده شده است اما در حال حاضر بیکار است (یعنی بی صدا) تعریف می شود.
  • "تأخیر خروجی پیوسته" به فاصله زمانی بین زمانی که یک برنامه یک نمونه برای پخش صادر می کند و زمانی که بلندگو به صورت فیزیکی صدای مربوطه را پخش می کند، در حالی که دستگاه در حال پخش صدا است، تعریف می شود.
  • "تأخیر ورودی سرد" به فاصله زمانی بین زمانی که یک برنامه درخواست ضبط صدا می کند و زمانی که اولین نمونه از طریق تماس برگشتی به برنامه تحویل داده می شود، زمانی که سیستم صوتی و میکروفون قبل از درخواست بیکار بوده و خاموش شده اند، تعریف می شود.
  • «تأخیر ورودی پیوسته» زمانی تعریف می‌شود که صدایی از محیط رخ می‌دهد و زمانی که نمونه متناظر با آن صدا از طریق تماس برگشتی به برنامه ضبط تحویل داده می‌شود، در حالی که دستگاه در حالت ضبط است.

با استفاده از تعاریف بالا، پیاده سازی دستگاه باید هر یک از این ویژگی ها را نشان دهد:

  • تأخیر خروجی سرد 100 میلی ثانیه یا کمتر
  • تأخیر خروجی گرم 10 میلی ثانیه یا کمتر
  • تأخیر خروجی پیوسته 45 میلی ثانیه یا کمتر
  • تأخیر ورودی سرد 100 میلی ثانیه یا کمتر
  • تأخیر ورودی پیوسته 50 میلی ثانیه یا کمتر

توجه: در حالی که الزامات ذکر شده در بالا به عنوان "SHOULD" برای Android 2.2 بیان شده است، تعریف سازگاری برای نسخه آینده برنامه ریزی شده است که این موارد را به "MUST" تغییر دهد. یعنی این الزامات در اندروید 2.2 اختیاری هستند اما در نسخه بعدی مورد نیاز خواهند بود. دستگاه‌های موجود و جدید که Android 2.2 Android را اجرا می‌کنند، بسیار تشویق می‌شوند که این الزامات را در Android 2.2 برآورده کنند ، یا در صورت ارتقا به نسخه آینده، نمی‌توانند به سازگاری Android دست یابند.

7. سازگاری با ابزار توسعه دهنده

پیاده سازی دستگاه باید از ابزارهای توسعه دهنده Android ارائه شده در Android SDK پشتیبانی کند. به طور خاص، دستگاه های سازگار با Android باید با:

  • پل اشکال زدایی اندروید (معروف به adb) [ منابع، 19 ]
    پیاده سازی دستگاه باید از همه عملکردهای adb همانطور که در Android SDK مستند شده است پشتیبانی کند. adb سمت دستگاه باید به‌طور پیش‌فرض غیرفعال باشد، اما باید مکانیزمی در دسترس کاربر برای روشن کردن Android Debug Bridge وجود داشته باشد.
  • Dalvik Debug Monitor Service (معروف به ddms) [ منابع، 19 ]
    پیاده سازی دستگاه باید از همه ویژگی های ddms همانطور که در Android SDK مستند شده است پشتیبانی کند. از آنجایی که ddms از adb استفاده می کند، پشتیبانی از ddms باید به طور پیش فرض غیرفعال باشد، اما هر زمان که کاربر پل اشکال زدایی اندروید را فعال کرده باشد، باید پشتیبانی شود.
  • میمون [ منابع، 22 ]
    پیاده سازی دستگاه باید چارچوب Monkey را شامل شود و آن را برای استفاده برنامه ها در دسترس قرار دهد.

8. سازگاری سخت افزار

اندروید برای پشتیبانی از پیاده‌سازان دستگاه‌ها در نظر گرفته شده است که فاکتورها و پیکربندی‌های نوآورانه را ایجاد می‌کنند. در عین حال، توسعه دهندگان اندروید انتظار سخت افزار، حسگرها و API های خاصی را در تمام دستگاه های اندرویدی دارند. این بخش ویژگی‌های سخت‌افزاری را فهرست می‌کند که همه دستگاه‌های سازگار با Android 2.2 باید از آن‌ها پشتیبانی کنند.

اگر دستگاهی شامل یک جزء سخت افزاری خاص است که دارای یک API مربوطه برای توسعه دهندگان شخص ثالث است، پیاده سازی دستگاه باید آن API را همانطور که در مستندات Android SDK تعریف شده است پیاده سازی کند. اگر یک API در SDK با یک مؤلفه سخت افزاری که اختیاری است و پیاده سازی دستگاه آن مؤلفه را ندارد تعامل داشته باشد:

  • تعاریف کلاس برای APIهای مؤلفه باید وجود داشته باشد
  • رفتارهای API باید به صورت بدون عملیات به روشی معقول اجرا شوند
  • روش‌های API باید مقادیر تهی را در مواردی که توسط اسناد SDK مجاز است، برگردانند
  • روش‌های API باید پیاده‌سازی‌های بدون عملیات کلاس‌هایی را که در آن‌ها مقادیر تهی توسط اسناد SDK مجاز نیستند، برگردانند.

یک مثال معمولی از سناریویی که در آن این الزامات اعمال می‌شود، API تلفنی است: حتی در دستگاه‌های غیر تلفنی، این APIها باید به‌عنوان برنامه‌های بدون عملیات معقول اجرا شوند.

پیاده‌سازی‌های دستگاه باید اطلاعات دقیق پیکربندی سخت‌افزار را از طریق متدهای getSystemAvailableFeatures() و hasSystemFeature(String) در کلاس android.content.pm.PackageManager گزارش دهند. [ منابع، 23 ]

8.1. نمایش دادن

Android 2.2 شامل امکاناتی است که تحت برخی شرایط عملیات مقیاس‌گذاری و تبدیل خودکار خاص را انجام می‌دهند تا اطمینان حاصل شود که برنامه‌های شخص ثالث به خوبی بر روی انواع پیکربندی‌های سخت‌افزاری اجرا می‌شوند [ Resources, 24 ]. دستگاه ها باید به درستی این رفتارها را که در این بخش توضیح داده شده است، اجرا کنند.

برای Android 2.2، اینها رایج ترین پیکربندی های صفحه نمایش هستند:

نوع صفحه نمایش عرض (پیکسل) ارتفاع (پیکسل) محدوده طول مورب (اینچ) گروه اندازه صفحه نمایش گروه تراکم صفحه نمایش
QVGA 240 320 2.6 - 3.0 کم اهمیت کم
WQVGA 240 400 3.2 - 3.5 طبیعی کم
FWQVGA 240 432 3.5 - 3.8 طبیعی کم
HVGA 320 480 3.0 - 3.5 طبیعی متوسط
WVGA 480 800 3.3 - 4.0 طبیعی بالا
FWVGA 480 854 3.5 - 4.0 طبیعی بالا
WVGA 480 800 4.8 - 5.5 بزرگ متوسط
FWVGA 480 854 5.0 - 5.8 بزرگ متوسط

پیاده‌سازی دستگاه مربوط به یکی از پیکربندی‌های استاندارد بالا باید طوری پیکربندی شود که اندازه صفحه نمایش مشخص شده را از طریق کلاس android.content.res.Configuration [ Resources, 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 گزارش کنند [ Resources, 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 یا چرخ را حذف کند)
  • باید مقدار صحیح را برای android.content.res.Configuration.navigation گزارش کند [ Resources, 25 ]

8.4. جهت صفحه نمایش

دستگاه‌های سازگار باید از جهت‌گیری پویا توسط برنامه‌ها برای جهت‌گیری صفحه عمودی یا افقی پشتیبانی کنند. یعنی دستگاه باید به درخواست برنامه برای جهت گیری صفحه نمایش خاص احترام بگذارد. پیاده سازی دستگاه ممکن است جهت عمودی یا افقی را به عنوان پیش فرض انتخاب کند.

هر زمان که از طریق android.content.res.Configuration.orientation، android.view.Display.getOrientation() یا سایر APIها درخواست شود، دستگاه ها باید مقدار صحیح جهت جهت فعلی دستگاه را گزارش کنند.

8.5. ورودی صفحه لمسی

پیاده سازی دستگاه:

  • باید صفحه نمایش لمسی داشته باشد
  • ممکن است صفحه نمایش لمسی خازنی یا مقاومتی داشته باشد
  • باید مقدار android.content.res.Configuration [ منابع، 25 ] را گزارش کند که منعکس کننده نوع صفحه لمسی خاص در دستگاه است.
  • اگر صفحه لمسی از چند نشانگر پشتیبانی می کند، باید از نشانگرهای کاملاً مستقل ردیابی شده پشتیبانی کند

8.6. یو اس بی

پیاده سازی دستگاه:

  • باید یک سرویس گیرنده USB، قابل اتصال به یک میزبان USB با یک پورت USB-A استاندارد، اجرا شود
  • باید پل اشکال زدایی اندروید را از طریق USB پیاده سازی کنید (همانطور که در بخش 7 توضیح داده شد)
  • باید مشخصات ذخیره سازی انبوه USB را پیاده سازی کند تا به میزبان متصل به دستگاه اجازه دهد به محتویات حجم /sdcard دسترسی داشته باشد.
  • باید از فرم فاکتور میکرو USB در سمت دستگاه استفاده کنید
  • ممکن است دارای یک پورت غیر استاندارد در سمت دستگاه باشد، اما اگر چنین است، باید با کابلی ارسال شود که بتواند پین اوت سفارشی را به درگاه USB-A استاندارد متصل کند.
  • باید پشتیبانی از مشخصات USB Mass Storage را اجرا کند (به طوری که حافظه قابل جابجایی یا ثابت در دستگاه را بتوان از رایانه میزبان دسترسی داشت)

8.7. کلیدهای ناوبری

عملکردهای Home، Menu و Back برای پارادایم ناوبری اندروید ضروری هستند. پیاده سازی دستگاه باید این توابع را بدون توجه به وضعیت برنامه، همیشه در دسترس کاربر قرار دهد. این عملکردها باید از طریق دکمه های اختصاصی اجرا شوند. آنها ممکن است با استفاده از نرم افزار، حرکات، پانل لمسی و غیره پیاده سازی شوند، اما در این صورت باید همیشه در دسترس باشند و در ناحیه نمایش برنامه موجود مبهم یا تداخل نداشته باشند.

پیاده‌کننده‌های دستگاه نیز باید یک کلید جستجوی اختصاصی ارائه دهند. پیاده‌کننده‌های دستگاه ممکن است کلیدهای ارسال و پایان را برای تماس‌های تلفنی نیز ارائه دهند.

8.8. شبکه داده های بی سیم

پیاده سازی دستگاه باید شامل پشتیبانی از شبکه های داده پرسرعت بی سیم باشد. به طور خاص، پیاده سازی دستگاه باید شامل پشتیبانی از حداقل یک استاندارد داده بی سیم با قابلیت 200 کیلوبیت بر ثانیه یا بیشتر باشد. نمونه هایی از فناوری هایی که این نیاز را برآورده می کنند عبارتند از EDGE، HSPA، EV-DO، 802.11g و غیره.

اگر پیاده‌سازی دستگاه شامل مدالیتی خاص باشد که Android SDK برای آن یک API (یعنی WiFi، GSM یا CDMA) را شامل شود، پیاده‌سازی باید از API پشتیبانی کند.

دستگاه ها ممکن است بیش از یک شکل از اتصال داده بی سیم را اجرا کنند. ممکن است دستگاه‌ها اتصال داده‌های سیمی (مانند اترنت) را پیاده‌سازی کنند، اما با این وجود باید حداقل یک شکل از اتصال بی‌سیم را مانند بالا داشته باشند.

8.9. دوربین

پیاده سازی دستگاه باید شامل یک دوربین پشتی باشد. دوربین عقب شامل:

  • باید دارای وضوح حداقل 2 مگاپیکسل باشد
  • باید فوکوس خودکار سخت‌افزاری یا فوکوس خودکار نرم‌افزاری را در درایور دوربین (شفاف برای نرم‌افزار کاربردی) داشته باشد.
  • ممکن است سخت افزار با فوکوس ثابت یا EDOF (عمق میدان گسترده) داشته باشد
  • ممکن است شامل یک فلاش باشد. اگر دوربین دارای فلاش باشد، لامپ فلاش نباید روشن شود در حالی که یک نمونه android.hardware.Camera.PreviewCallback روی سطح پیش نمایش دوربین ثبت شده است، مگر اینکه برنامه به صراحت با فعال کردن ویژگی های FLASH_MODE_AUTO یا FLASH_MODE_ON یک فلاش را فعال کرده باشد. شئ Camera.Parameters . توجه داشته باشید که این محدودیت برای برنامه دوربین سیستم داخلی دستگاه اعمال نمی شود، بلکه فقط برای برنامه های شخص ثالث با استفاده از Camera.PreviewCallback می شود.

پیاده سازی های دستگاه باید رفتارهای زیر را برای API های مرتبط با دوربین اجرا کنند:

  1. اگر برنامه‌ای هرگز android.hardware.Camera.Parameters.setPreviewFormat(int) را فراخوانی نکرده است، دستگاه باید از android.hardware.PixelFormat.YCbCr_420_SP برای داده‌های پیش‌نمایش ارائه‌شده به تماس‌های برنامه کاربردی استفاده کند.
  2. اگر برنامه‌ای یک نمونه android.hardware.Camera.PreviewCallback را ثبت کند و زمانی که فرمت پیش‌نمایش YCbCr_420_SP است، سیستم متد onPreviewFrame() را فراخوانی کند، داده‌های موجود در بایت[] ارسال شده به ()onPreviewFrame باید در قالب کدگذاری NV21 باشد. (این فرمتی است که به طور بومی توسط خانواده سخت افزار 7k استفاده می شود.) یعنی NV21 باید پیش فرض باشد.

پیاده‌سازی‌های دستگاه باید API کامل دوربین موجود در مستندات Android 2.2 SDK [ منابع، 27 ] را اجرا کنند، صرف نظر از اینکه دستگاه دارای فوکوس خودکار سخت‌افزاری یا سایر قابلیت‌ها باشد. به عنوان مثال، دوربین‌هایی که فاقد فوکوس خودکار هستند، همچنان باید هر نمونه ثبت‌شده android.hardware.Camera.AutoFocusCallback را فراخوانی کنند (حتی اگر این هیچ ارتباطی با دوربین‌های بدون فوکوس خودکار ندارد.)

اگر سخت‌افزار زیربنایی از این ویژگی پشتیبانی می‌کند، پیاده‌سازی‌های دستگاه باید هر نام پارامتری را که به‌عنوان یک ثابت در کلاس android.hardware.Camera.Parameters تعریف شده است، بشناسد و به آن احترام بگذارد. اگر سخت‌افزار دستگاه از یک ویژگی پشتیبانی نمی‌کند، API باید مطابق مستندات رفتار کند. برعکس، پیاده‌سازی‌های دستگاه نباید ثابت‌های رشته‌ای را که به متد android.hardware.Camera.setParameters() ارسال می‌شود، غیر از مواردی که به‌عنوان ثابت در android.hardware.Camera.Parameters مستند شده‌اند، احترام یا تشخیص دهند. به این معنا که اگر سخت‌افزار اجازه می‌دهد، پیاده‌سازی دستگاه باید از تمام پارامترهای استاندارد دوربین پشتیبانی کند و نباید از انواع پارامترهای دوربین سفارشی پشتیبانی کند.

پیاده سازی دستگاه ممکن است شامل یک دوربین جلو باشد. با این حال، اگر پیاده‌سازی دستگاه شامل دوربین جلویی باشد، API دوربین که بر روی دستگاه پیاده‌سازی شده است نباید به‌طور پیش‌فرض از دوربین جلو استفاده کند. یعنی دوربین API در اندروید 2.2 فقط برای دوربین‌های پشتی است و پیاده‌سازی دستگاه نباید از API مجدداً استفاده کند یا آن را بیش از حد بارگذاری کند تا روی دوربین جلویی، در صورت وجود، عمل کند. توجه داشته باشید که هر API سفارشی که توسط پیاده‌کننده‌های دستگاه برای پشتیبانی از دوربین‌های جلو اضافه شده است، باید از بخش‌های 3.5 و 3.6 پیروی کند. برای مثال، اگر یک زیر کلاس سفارشی android.hardware.Camera یا Camera.Parameters برای پشتیبانی از دوربین های جلو ارائه شده باشد، نباید در فضای نام موجود، همانطور که در بخش های 3.5 و 3.6 توضیح داده شده است، قرار گیرد. توجه داشته باشید که گنجاندن دوربین جلو الزامی را برآورده نمی کند که دستگاه ها دارای دوربین عقب باشند.

8.10. شتاب سنج

پیاده سازی دستگاه باید شامل یک شتاب سنج 3 محوره باشد و باید بتواند رویدادها را با فرکانس 50 هرتز یا بیشتر ارائه دهد. سیستم مختصاتی که توسط شتاب‌سنج استفاده می‌شود باید با سیستم مختصات حسگر Android مطابق با جزئیات در APIهای Android مطابقت داشته باشد (به [ منابع، 28 ] مراجعه کنید).

8.11. قطب نما

پیاده سازی دستگاه باید دارای قطب نما 3 محوره باشد و باید بتواند رویدادهای 10 هرتز یا بیشتر را ارائه دهد. سیستم مختصاتی که توسط قطب نما استفاده می شود باید با سیستم مختصات حسگر Android همانطور که در API Android تعریف شده است مطابقت داشته باشد (به [ منابع، 28 ] مراجعه کنید).

8.12. جی پی اس

پیاده سازی دستگاه باید شامل گیرنده GPS باشد، و باید نوعی تکنیک "GPS کمکی" را برای به حداقل رساندن زمان قفل شدن GPS داشته باشد.

8.13. تلفن

Android 2.2 ممکن است در دستگاه‌هایی که شامل سخت‌افزار تلفن نیستند استفاده شود. یعنی اندروید 2.2 با دستگاه هایی که گوشی نیستند سازگار است. با این حال، اگر پیاده‌سازی دستگاه شامل تلفن GSM یا CDMA باشد، باید پشتیبانی کامل از API برای آن فناوری را اجرا کند. پیاده‌سازی‌های دستگاهی که شامل سخت‌افزار تلفن نمی‌شوند، باید APIهای کامل را به‌عنوان بدون عملیات اجرا کنند.

همچنین به بخش 8.8، شبکه داده های بی سیم مراجعه کنید.

8.14. حافظه و ذخیره سازی

پیاده سازی دستگاه باید حداقل 92 مگابایت حافظه در دسترس هسته و فضای کاربر داشته باشد. 92 مگابایت باید علاوه بر هر حافظه اختصاص داده شده به اجزای سخت افزاری مانند رادیو، حافظه و غیره باشد که تحت کنترل هسته نیست.

پیاده سازی های دستگاه باید حداقل 150 مگابایت فضای ذخیره سازی غیر فرار برای داده های کاربر در دسترس داشته باشند. یعنی پارتیشن /data باید حداقل 150 مگابایت باشد.

فراتر از الزامات بالا، پیاده‌سازی‌های دستگاه باید حداقل 128 مگابایت حافظه در دسترس هسته و فضای کاربر، به اضافه هر حافظه اختصاص داده شده به اجزای سخت‌افزاری که تحت کنترل هسته نیستند، داشته باشند. پیاده سازی های دستگاه باید حداقل 1 گیگابایت فضای ذخیره سازی غیر فرار برای داده های کاربر در دسترس داشته باشند. توجه داشته باشید که این الزامات بالاتر برای تبدیل شدن به حداقل های سخت در نسخه آینده اندروید برنامه ریزی شده است. اجرای دستگاه‌ها به شدت تشویق می‌شوند که اکنون این الزامات را برآورده کنند، در غیر این صورت ممکن است واجد شرایط سازگاری با نسخه آینده Android نباشند.

8.15. برنامه ذخیره سازی مشترک

پیاده سازی دستگاه باید فضای ذخیره سازی مشترک را برای برنامه ها ارائه دهد. فضای ذخیره سازی مشترک ارائه شده باید حداقل 2 گیگابایت باشد.

پیاده سازی های دستگاه باید با ذخیره سازی مشترک که به طور پیش فرض نصب شده است، "خارج از جعبه" پیکربندی شوند. اگر فضای ذخیره‌سازی مشترک روی مسیر لینوکس /sdcard نصب نشده باشد، دستگاه باید یک پیوند نمادین لینوکس از /sdcard به نقطه اتصال واقعی داشته باشد.

پیاده‌سازی‌های دستگاه باید طبق مستندات، مجوز android.permission.WRITE_EXTERNAL_STORAGE را در این فضای ذخیره‌سازی مشترک اعمال کنند. در غیر این صورت، هر برنامه‌ای که این مجوز را دریافت می‌کند، باید فضای ذخیره‌سازی مشترک قابل نوشتن باشد.

ممکن است پیاده‌سازی‌های دستگاه دارای سخت‌افزاری برای ذخیره‌سازی قابل جابجایی قابل دسترس کاربر، مانند کارت دیجیتال امن باشد. روش دیگر، پیاده‌سازی دستگاه ممکن است فضای ذخیره‌سازی داخلی (غیرقابل جابجایی) را به عنوان فضای ذخیره‌سازی مشترک برای برنامه‌ها اختصاص دهد.

صرف نظر از شکل ذخیره سازی مشترک استفاده شده، فضای ذخیره سازی مشترک باید ذخیره سازی انبوه USB را اجرا کند، همانطور که در بخش 8.6 توضیح داده شده است. همانطور که خارج از جعبه ارسال می شود، فضای ذخیره سازی مشترک باید با سیستم فایل FAT نصب شود.

در نظر گرفتن دو مثال رایج توضیحی است. اگر یک دستگاه پیاده‌سازی شامل یک اسلات کارت SD برای برآورده کردن نیاز ذخیره‌سازی مشترک باشد، یک کارت SD با فرمت FAT با اندازه 2 گیگابایت یا بزرگتر باید همراه دستگاه باشد که به کاربران فروخته می‌شود و باید به طور پیش‌فرض نصب شود. از طرف دیگر، اگر پیاده‌سازی دستگاه از حافظه داخلی ثابت برای برآورده کردن این نیاز استفاده می‌کند، آن فضای ذخیره‌سازی باید 2 گیگابایت یا بزرگ‌تر باشد، به صورت FAT قالب‌بندی شده باشد و بر روی /sdcard /sdcard باید یک پیوند نمادین به مکان فیزیکی باشد. در جای دیگری نصب شده است.)

پیاده‌سازی دستگاهی که شامل چندین مسیر ذخیره‌سازی مشترک (مانند اسلات کارت SD و حافظه داخلی مشترک) است، باید برنامه‌های اصلی مانند اسکنر رسانه و ContentProvider را برای پشتیبانی شفاف از فایل‌های قرار داده شده در هر دو مکان تغییر دهد.

8.16. بلوتوث

پیاده سازی دستگاه باید شامل یک گیرنده بلوتوث باشد. پیاده‌سازی‌های دستگاه باید API بلوتوث مبتنی بر RFCOMM را همانطور که در مستندات SDK توضیح داده شده فعال کنند [ منابع، 30 ]. پیاده سازی های دستگاه باید پروفایل های بلوتوث مربوطه مانند A2DP، AVRCP، OBEX، و غیره را مطابق با دستگاه اجرا کنند.

مجموعه تست سازگاری شامل مواردی است که عملکرد اصلی API بلوتوث RFCOMM Android را پوشش می دهد. با این حال، از آنجایی که بلوتوث یک پروتکل ارتباطی بین دستگاه‌ها است، نمی‌توان آن را به طور کامل با آزمایش‌های واحدی که روی یک دستگاه اجرا می‌شود، آزمایش کرد. در نتیجه، پیاده‌سازی دستگاه باید روش تست بلوتوث مبتنی بر انسان شرح داده شده در ضمیمه A را نیز پشت سر بگذارد.

9. سازگاری با عملکرد

یکی از اهداف برنامه سازگاری اندروید این است که تجربه برنامه کاربردی را برای مصرف کنندگان فراهم کند. پیاده سازی های سازگار نه تنها باید اطمینان حاصل کنند که برنامه ها به سادگی بر روی دستگاه اجرا می شوند، بلکه باید این کار را با عملکرد معقول و در کل تجربه کاربری خوب انجام دهند. پیاده سازی دستگاه باید معیارهای عملکرد کلیدی دستگاه سازگار با Android 2.2 را که در جدول زیر تعریف شده است، داشته باشد:

متریک آستانه عملکرد نظرات
زمان راه اندازی برنامه برنامه های زیر باید در مدت زمان مشخص شده راه اندازی شوند.
  • مرورگر: کمتر از 1300 میلی‌ثانیه
  • MMS/SMS: کمتر از 700ms
  • ساعت زنگ دار: کمتر از 650 میلی ثانیه
زمان راه‌اندازی به عنوان کل زمان برای تکمیل بارگیری فعالیت پیش‌فرض برای برنامه، از جمله زمانی که طول می‌کشد برای شروع فرآیند لینوکس، بارگیری بسته Android در Dalvik VM و فراخوانی onCreate اندازه‌گیری می‌شود.
برنامه های کاربردی همزمان هنگامی که چندین برنامه راه اندازی شده اند، راه اندازی مجدد یک برنامه در حال اجرا پس از راه اندازی باید کمتر از زمان راه اندازی اولیه باشد.

10. سازگاری مدل امنیتی

پیاده‌سازی‌های دستگاه باید یک مدل امنیتی مطابق با مدل امنیتی پلتفرم Android را که در سند مرجع امنیت و مجوزها در APIها [ منابع، 29 ] در اسناد توسعه‌دهنده Android تعریف شده است، پیاده‌سازی کنند. پیاده‌سازی دستگاه باید از نصب برنامه‌های خود امضا شده بدون نیاز به مجوزها/گواهی‌های اضافی از طرف شخص/مقام ثالث پشتیبانی کند. به طور خاص، دستگاه های سازگار باید از مکانیسم های امنیتی شرح داده شده در زیر بخش های زیر پشتیبانی کنند.

10.1. مجوزها

پیاده‌سازی دستگاه باید از مدل مجوزهای Android همانطور که در مستندات توسعه‌دهنده Android تعریف شده است [ منابع، 29 ] پشتیبانی کند. به طور خاص، پیاده سازی ها باید هر مجوزی را که در مستندات SDK تعریف شده است، اعمال کنند. هیچ مجوزی را نمی توان حذف، تغییر داد یا نادیده گرفت. پیاده‌سازی‌ها ممکن است مجوزهای اضافی اضافه کنند، مشروط بر اینکه رشته‌های شناسه مجوز جدید در فضای نام android.* نباشد.

10.2. UID و جداسازی فرآیند

پیاده سازی دستگاه باید از مدل سندباکس برنامه اندروید پشتیبانی کند، که در آن هر برنامه به عنوان یک UID منحصر به فرد به سبک یونیکس و در یک فرآیند جداگانه اجرا می شود. پیاده سازی دستگاه باید از اجرای چندین برنامه به عنوان شناسه کاربر لینوکس یکسان پشتیبانی کند، مشروط بر اینکه برنامه ها به درستی امضا و ساخته شده باشند، همانطور که در مرجع امنیت و مجوزها [ منابع، 29 ] تعریف شده است.

10.3. مجوزهای سیستم فایل

پیاده‌سازی دستگاه باید از مدل مجوزهای دسترسی به فایل Android همانطور که در مرجع امنیت و مجوزها تعریف شده است [ منابع، 29 ] پشتیبانی کند.

10.4. محیط های اجرایی جایگزین

پیاده‌سازی دستگاه ممکن است شامل محیط‌های زمان اجرا باشد که برنامه‌ها را با استفاده از نرم‌افزار یا فناوری دیگری غیر از ماشین مجازی Dalvik یا کد بومی اجرا می‌کنند. با این حال، چنین محیط‌های اجرای جایگزین نباید مدل امنیتی Android یا امنیت برنامه‌های Android نصب شده را به خطر بیاندازند، همانطور که در این بخش توضیح داده شد.

زمان‌های اجرا جایگزین باید خود برنامه‌های Android باشند و از مدل امنیتی استاندارد Android پیروی کنند، همانطور که در بخش 10 توضیح داده شد.

زمان‌های اجرا جایگزین نباید از طریق مکانیسم <uses-permission> به منابع محافظت شده توسط مجوزهایی که در فایل AndroidManifest.xml زمان اجرا درخواست نشده است دسترسی داشته باشند.

زمان‌های اجرا جایگزین نباید به برنامه‌ها اجازه استفاده از ویژگی‌های محافظت شده توسط مجوزهای Android محدود به برنامه‌های سیستمی را بدهد.

زمان اجراهای جایگزین باید از مدل سندباکس اندروید پیروی کنند. به طور مشخص:

  • زمان‌های اجرا جایگزین باید برنامه‌ها را از طریق PackageManager در جعبه‌های سندباکس جداگانه اندروید (یعنی شناسه‌های کاربری لینوکس و غیره) نصب کنند.
  • زمان‌های اجرا جایگزین ممکن است یک سندباکس اندرویدی به اشتراک گذاشته شده توسط همه برنامه‌ها با استفاده از زمان اجرا جایگزین ارائه دهد.
  • زمان‌های اجرا و برنامه‌های نصب‌شده جایگزین با استفاده از زمان اجرا جایگزین، نباید از جعبه ایمنی برنامه‌های دیگر نصب‌شده روی دستگاه استفاده مجدد کنند، مگر از طریق مکانیسم‌های استاندارد Android شناسه کاربر مشترک و گواهی امضا
  • زمان‌های اجرا جایگزین نباید با جعبه‌های ایمنی مربوط به سایر برنامه‌های Android راه‌اندازی شوند، به آن‌ها اجازه داده شود یا به آنها دسترسی داده شود.

زمان‌های اجرا جایگزین نباید با برنامه‌های کاربردی دیگر راه‌اندازی شود، امتیازی از سوپرکاربر (ریشه) یا هر شناسه کاربری دیگری به آن اعطا شود.

فایل‌های apk. زمان‌های اجرا جایگزین ممکن است در تصویر سیستم پیاده‌سازی دستگاه گنجانده شوند، اما باید با کلیدی متمایز از کلید مورد استفاده برای امضای سایر برنامه‌های موجود در پیاده‌سازی دستگاه امضا شوند.

هنگام نصب برنامه‌ها، زمان‌های اجرای متناوب باید رضایت کاربر را برای مجوزهای Android مورد استفاده برنامه دریافت کنند. به این معنا که اگر برنامه‌ای نیاز به استفاده از منبع دستگاهی داشته باشد که مجوز Android مربوطه برای آن وجود دارد (مانند دوربین، GPS و غیره)، زمان اجرا جایگزین باید به کاربر اطلاع دهد که برنامه می‌تواند به آن منبع دسترسی پیدا کند. . اگر محیط زمان اجرا قابلیت های برنامه را به این روش ثبت نمی کند، محیط زمان اجرا باید تمام مجوزهایی را که زمان اجرا در هنگام نصب هر برنامه ای با استفاده از آن زمان اجرا در اختیار دارد، فهرست کند.

11. مجموعه تست سازگاری

پیاده‌سازی‌های دستگاه باید مجموعه تست سازگاری Android (CTS) [ منابع، 2 ] موجود در پروژه منبع باز Android را با استفاده از نرم‌افزار ارسال نهایی بر روی دستگاه بگذرانند. علاوه بر این، پیاده‌کننده‌های دستگاه باید تا حد امکان از پیاده‌سازی مرجع در درخت منبع باز Android استفاده کنند، و باید از سازگاری در موارد ابهام در CTS و هرگونه پیاده‌سازی مجدد بخش‌هایی از کد منبع مرجع اطمینان حاصل کنند.

CTS برای اجرا بر روی یک دستگاه واقعی طراحی شده است. مانند هر نرم افزاری، CTS ممکن است خود دارای اشکال باشد. CTS مستقل از این تعریف سازگاری نسخه می شود و ممکن است چندین نسخه از CTS برای Android 2.2 منتشر شود. پیاده سازی دستگاه باید آخرین نسخه CTS موجود در زمان تکمیل نرم افزار دستگاه را پاس کند.

12. نرم افزار قابل به روز رسانی

پیاده سازی دستگاه باید دارای مکانیزمی برای جایگزینی کل نرم افزار سیستم باشد. این مکانیسم نیازی به ارتقای "زنده" ندارد - یعنی ممکن است نیاز به راه اندازی مجدد دستگاه باشد.

از هر روشی می توان استفاده کرد، مشروط بر اینکه بتواند کل نرم افزار از پیش نصب شده روی دستگاه را جایگزین کند. به عنوان مثال، هر یک از رویکردهای زیر این نیاز را برآورده می کند:

  • بارگیری از طریق هوا (OTA) با به‌روزرسانی آفلاین از طریق راه‌اندازی مجدد
  • به‌روزرسانی‌های «Tethered» از طریق USB از رایانه میزبان
  • "آفلاین" از طریق راه اندازی مجدد و به روز رسانی از یک فایل در حافظه قابل جابجایی به روز می شود

مکانیزم به‌روزرسانی استفاده شده باید از به‌روزرسانی‌ها بدون پاک کردن اطلاعات کاربر پشتیبانی کند. توجه داشته باشید که نرم افزار بالادستی اندروید دارای مکانیزم به روز رسانی است که این نیاز را برآورده می کند.

اگر پس از انتشار، خطایی در پیاده‌سازی دستگاه پیدا شود، اما در طول عمر محصول معقول آن که با مشورت تیم سازگاری Android تعیین شده است بر سازگاری برنامه‌های شخص ثالث تأثیر بگذارد، پیاده‌کننده دستگاه باید خطا را از طریق یک نرم‌افزار تصحیح کند. به روز رسانی در دسترس است که می تواند بر اساس مکانیسمی که توضیح داده شد اعمال شود.

13. تماس با ما

می‌توانید با نویسندگان سند در compatibility@android.com تماس بگیرید تا توضیحات لازم را ارائه کنید و هر مشکلی را که فکر می‌کنید سند پوشش نمی‌دهد، مطرح کنید.

ضمیمه A - روش تست بلوتوث

مجموعه تست سازگاری شامل مواردی است که عملکرد اصلی API بلوتوث RFCOMM Android را پوشش می دهد. با این حال، از آنجایی که بلوتوث یک پروتکل ارتباطی بین دستگاه‌ها است، نمی‌توان آن را به طور کامل با آزمایش‌های واحدی که روی یک دستگاه اجرا می‌شود، آزمایش کرد. در نتیجه، پیاده‌سازی دستگاه باید از روش تست بلوتوث مبتنی بر انسان که در زیر توضیح داده شده است، عبور کند.

روش آزمایش بر اساس برنامه نمونه بلوتوث چت موجود در درخت پروژه متن باز اندروید است. این روش به دو دستگاه نیاز دارد:

  • اجرای یک دستگاه کاندید اجرای ساخت نرم افزار برای آزمایش
  • یک پیاده سازی دستگاه جداگانه که قبلاً به عنوان سازگار شناخته شده است، و یک مدل از پیاده سازی دستگاه در حال آزمایش -- یعنی پیاده سازی دستگاه "خوب شناخته شده"

روش تست زیر به این دستگاه ها به ترتیب به عنوان دستگاه های "کاندیدا" و "خوب شناخته شده" اشاره می کند.

راه اندازی و نصب

  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.