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

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

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

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

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

2. منابع

سطوح مورد نیاز IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt

مروری بر برنامه سازگاری اندروید: http://source.android.com/docs/compatibility/index.html

پروژه متن باز اندروید: http://source.android.com/

تعاریف و مستندات API: http://developer.android.com/reference/packages.html

مرجع مجوزهای Android: http://developer.android.com/reference/android/Manifest.permission.html

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

رشته های نسخه مجاز Android 2.2: http://source.android.com/docs/compatibility/2.2/versions.html

کلاس android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html

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

مشخصات ماشین مجازی Dalvik: در کد منبع Android در dalvik/docs موجود است

AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html

اعلان ها: http://developer.android.com/guide/topics/ui/notifiers/notifications.html

منابع برنامه: http://code.google.com/android/reference/available-resources.html

راهنمای سبک نماد نوار وضعیت: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure

مدیر جستجو: http://developer.android.com/reference/android/app/SearchManager.html

نان تست: http://developer.android.com/reference/android/widget/Toast.html

تصاویر پس زمینه زنده: https://android-developers.googleblog.com/2010/02/live-wallpapers.html

برنامه های اندروید: http://code.google.com/p/apps-for-android

مستندات ابزار مرجع (برای adb، aapt، ddms): http://developer.android.com/guide/developing/tools/index.html

توضیحات فایل apk اندروید: http://developer.android.com/guide/topics/fundamentals.html

فایل های مانیفست: http://developer.android.com/guide/topics/manifest/manifest-intro.html

ابزار تست میمون: https://developer.android.com/studio/test/other-testing-tools/monkey

لیست ویژگی های سخت افزار اندروید: http://developer.android.com/reference/android/content/pm/PackageManager.html

پشتیبانی از چند صفحه: http://developer.android.com/guide/practices/screens_support.html

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

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

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

فضای مختصات حسگر: http://developer.android.com/reference/android/hardware/SensorEvent.html

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

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 ارائه می‌شود، ارائه دهند. با این حال، چنین سیستم های اعلان جایگزین باید منابع اعلان موجود را پشتیبانی کنند.

3.8.3. جستجو کردن

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 میلی ثانیه یا کمتر

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 کلیدی) مطابقت نداشته باشد.

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

ممکن است گزینه‌های ناوبری غیرلمسی را حذف کند (یعنی ممکن است یک گوی، 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 را اجرا کند (به طوری که حافظه قابل جابجایی یا ثابت در دستگاه را بتوان از رایانه میزبان دسترسی داشت)

عملکردهای 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 های مرتبط با دوربین اجرا کنند:

اگر برنامه‌ای هرگز android.hardware.Camera.Parameters.setPreviewFormat(int) را فراخوانی نکرده است، دستگاه باید از android.hardware.PixelFormat.YCbCr_420_SP برای داده‌های پیش‌نمایش ارائه‌شده به تماس‌های برنامه کاربردی استفاده کند.
اگر یک برنامه یک Android.Hardware.Camera.PreviewCallback را ثبت کند و سیستم روش OnPreviewFrame () را فراخوانی می کند وقتی که فرمت پیش نمایش YCBCR_420_SP است ، داده های موجود در Byte [] به 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 دوربین در Android 2.2 فقط برای دوربین های عقب است و پیاده سازی دستگاه ها نباید از API استفاده مجدد یا بارگذاری مجدد برای عملکرد در دوربین جلوی آن ، در صورت وجود. توجه داشته باشید که هر API های سفارشی اضافه شده توسط مجریان دستگاه برای پشتیبانی از دوربین های جلوی جلوی باید از بخش های 3.5 و 3.6 پیروی کنند. به عنوان مثال ، اگر یک زیر کلاس android.hardware.Camera یا Camera.Parameters برای پشتیبانی از دوربین های جلوی ارائه شده ارائه شده باشد ، نباید در یک فضای نام موجود قرار گیرد ، همانطور که در بخش های 3.5 و 3.6 توضیح داده شده است. توجه داشته باشید که گنجاندن یک دوربین جلوی آن ، الزامی را برآورده نمی کند که دستگاه ها شامل یک دوربین عقب باشند.

8.10. شتاب سنج

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

8.11. قطب نما

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

8.12. جی پی اس

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

8.13. تلفن

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

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

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

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

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

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

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

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

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

اجرای دستگاه باید به صورت مستند android.permission.WRITE_EXTERNAL_STORAGE در این ذخیره سازی مشترک اجرا شود. ذخیره مشترک باید در غیر این صورت با هر برنامه ای که این مجوز را بدست می آورد ، قابل ارسال باشد.

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

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

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

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

8.16. بلوتوث

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

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

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

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

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

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

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

10.1. مجوزها

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

10.2. uid و انزوا پردازش

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

10.3. مجوزهای سیستم پرونده

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

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

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

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

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

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

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

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

زمان های متناوب نباید با هرگونه امتیاز از Superuser (ROOT) یا هر شناسه کاربر دیگر ، به برنامه های دیگر اعطا شود ، یا به برنامه های دیگر اعطا شود.

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

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

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

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

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

12. نرم افزار به روز شده

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

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

بارگیری از طریق هوا (OTA) با بروزرسانی آفلاین از طریق راه اندازی مجدد
"Tethered" به روزرسانی های USB از یک کامپیوتر میزبان
به روزرسانی های "آفلاین" از طریق راه اندازی مجدد و به روزرسانی از یک پرونده در ذخیره سازی قابل جابجایی

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

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

13. با ما تماس بگیرید

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

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

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

روش تست مبتنی بر برنامه نمونه BluetoothChat است که در درخت پروژه منبع باز اندروید موجود است. این روش به دو دستگاه نیاز دارد:

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

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

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

bluetoothchat.apk را از طریق "نمونه" از درخت کد منبع اندرویدی بسازید.
BluetoothChat.apk را روی دستگاه شناخته شده خوب نصب کنید.
BluetoothChat.apk را در دستگاه کاندید نصب کنید.

کنترل بلوتوث را توسط برنامه ها آزمایش کنید

BluetoothChat را روی دستگاه کاندیدای راه اندازی کنید ، در حالی که بلوتوث غیرفعال است.
تأیید کنید که دستگاه نامزد یا بلوتوث را روشن می کند ، یا کاربر را با یک گفت و گو برای روشن کردن بلوتوث سوق می دهد.

تست جفت و ارتباطات

برنامه چت بلوتوث را در هر دو دستگاه راه اندازی کنید.
دستگاه خوب شناخته شده را از درون Bluetoothchat (با استفاده از منو) کشف کنید.
در دستگاه نامزد ، دستگاه های بلوتوث را از داخل Bluetoothchat (با استفاده از منو) اسکن کرده و با دستگاه شناخته شده خوب جفت کنید.
از هر دستگاه 10 یا بیشتر پیام ارسال کنید و تأیید کنید که دستگاه دیگر آنها را به درستی دریافت می کند.
برنامه BluetoothChat را در هر دو دستگاه با فشار دادن به خانه ببندید.
با استفاده از برنامه تنظیمات دستگاه ، هر دستگاه را از دیگری استفاده کنید.

تست جفت و ارتباط در جهت معکوس

برنامه چت بلوتوث را در هر دو دستگاه راه اندازی کنید.
دستگاه نامزد را از درون Bluetoothchat (با استفاده از منو) قابل کشف کنید.
در دستگاه خوب شناخته شده ، دستگاه های بلوتوث را از داخل Bluetoothchat (با استفاده از منو) اسکن کرده و با دستگاه کاندیدای جفت کنید.
از هر دستگاه 10 یا پیام ارسال کنید و تأیید کنید که دستگاه دیگر آنها را به درستی دریافت می کند.
برنامه چت بلوتوث را در هر دو دستگاه با فشار دادن بارها و بارها برای رسیدن به پرتابگر ببندید.

آزمایش مجدد

برنامه چت بلوتوث را در هر دو دستگاه دوباره راه اندازی کنید.
از هر دستگاه 10 یا پیام ارسال کنید و تأیید کنید که دستگاه دیگر آنها را به درستی دریافت می کند.

توجه: آزمایش های فوق مواردی دارند که با استفاده از خانه و برخی از آنها از پشت به یک بخش آزمایش پایان می دهند. این تست ها زائد نیستند و اختیاری نیستند: هدف این است که تأیید کنیم که API بلوتوث و پشته به درستی کار می کنند ، هر دو فعالیت به صراحت خاتمه می یابد (از طریق فشار کاربر به عقب ، که به پایان می رسد () و به طور ضمنی به پس زمینه ارسال می شود (از طریق کاربر فشار به خانه.) هر دنباله آزمون باید مطابق توضیحات انجام شود.