این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

تعریف سازگاری Android 1.6

تعریف سازگاری اندروید: اندروید 1.6
اندروید 1.6 r2
شرکت گوگل.
compatibility@android.com

1. مقدمه
این سند شرایطی را که باید برای تلفن همراه رعایت شود، برشمرده است
سازگار با اندروید 1.6 این تعریف آشنایی با برنامه سازگاری اندروید را فرض می کند
[منابع، 1].
استفاده از "باید"، "نباید"، "لازم"، "باید"، "نباید"، "نباید"، "نباید"، "توصیه"،
"می" و "اختیاری" طبق استاندارد IETF تعریف شده در RFC2119 [ منابع ، 2] است.
همانطور که در این سند استفاده می شود، "پیاده کننده دستگاه" یا "اجرا کننده" شخص یا سازمانی است که در حال توسعه است
یک راه حل سخت افزاری/نرم افزاری با اندروید 1.6. "پیاده سازی دستگاه" یا "پیاده سازی" است
راه حل سخت افزاری/نرم افزاری تا این حد توسعه یافته است.
برای سازگاری با Android 1.6، پیاده سازی های دستگاه:
1. باید الزامات ارائه شده در این تعریف سازگاری، از جمله هر سندی را برآورده کند
از طریق مرجع گنجانده شده است.
2. باید مجموعه تست سازگاری Android (CTS) را که به عنوان بخشی از Android Open موجود است، بگذرانید
پروژه منبع [ منابع ، 3]. CTS بیشتر، اما نه همه مؤلفه های ذکر شده در این را آزمایش می کند
سند
در صورتی که این تعریف یا CTS بی‌صدا، مبهم یا ناقص باشد، مسئولیت آن بر عهده دستگاه است.
پیاده کننده برای اطمینان از سازگاری با پیاده سازی های موجود. به همین دلیل، Android Open
پروژه منبع [ منابع ، 4] هم مرجع و هم پیاده سازی ترجیحی اندروید است. دستگاه
پیاده‌سازها به شدت تشویق می‌شوند که پیاده‌سازی‌های خود را بر اساس کد منبع «بالادستی» قرار دهند
در دسترس از پروژه متن باز Android. در حالی که برخی از اجزا به صورت فرضی قابل تعویض هستند
با اجرای جایگزین، این عمل به شدت منع می شود، زیرا گذراندن آزمون های CTS تبدیل خواهد شد
به طور قابل ملاحظه ای دشوارتر این مسئولیت اجراکننده است که از سازگاری کامل رفتاری با
اجرای استاندارد اندروید، از جمله و فراتر از مجموعه تست سازگاری.
2. منابع
این تعریف سازگاری به تعدادی از منابعی اشاره می کند که می توان در اینجا به دست آورد.
1. مروری بر برنامه سازگاری اندروید: https://sites.google.com/a/android.com/compatibility/
چگونه کار می کند
2. سطوح مورد نیاز IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
3. مجموعه تست سازگاری: http://sites.google.com/a/android.com/compatibility/compatibility-test-
مجموعه --cts
4. پروژه متن باز اندروید: http://source.android.com/
5. تعاریف و مستندات API: http://developer.android.com/reference/packages.html
6. ارائه دهندگان محتوا: http://code.google.com/android/reference/android/provider/package-
summary.html
7. منابع موجود: http://code.google.com/android/reference/available-resources.html
8. فایل‌های مانیفست اندروید: http://code.google.com/android/devel/bblocks-manifest.html
9. مرجع مجوزهای اندروید: http://developer.android.com/reference/android/
Manifest.permission.html
10. Build Constants: http://developer.android.com/reference/android/os/Build.html
11. WebView: http://developer.android.com/reference/android/webkit/WebView.html
12. برنامه های افزودنی مرورگر Gears: http://code.google.com/apis/gears/

13. مشخصات ماشین مجازی Dalvik، در فهرست راهنمای dalvik/docs یک کد منبع یافت می شود.
وارسی؛ همچنین در http://android.git.kernel.org/?p=platform/ موجود است
dalvik.git;a=tree;f=docs;h=3e2ddbcaf7f370246246f9f03620a7caccbfcb12;hb=HEAD
14. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
15. اعلان ها: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
16. راهنمای سبک نماد نوار وضعیت: http://developer.android.com/guide/practices/ui_guideline
/icon_design.html#statusbarstructure
17. مدیر جستجو: http://developer.android.com/reference/android/app/SearchManager.html
18. نان تست: http://developer.android.com/reference/android/widget/Toast.html
19. برنامه‌ها برای اندروید: http://code.google.com/p/apps-for-android
20. توضیحات فایل apk اندروید: http://developer.android.com/guide/topics/fundamentals.html
21. Android Debug Bridge (adb): http://code.google.com/android/reference/adb.html
22. Dalvik Debug Monitor Service (ddms): http://code.google.com/android/reference/ddms.html
23. میمون: http://developer.android.com/guide/developing/tools/monkey.html
24. مستندات نمایش استقلال:
25. ثابت های پیکربندی: http://developer.android.com/reference/android/content/res/
Configuration.html
26. معیارهای نمایش: http://developer.android.com/reference/android/util/DisplayMetrics.html
27. دوربین: http://developer.android.com/reference/android/hardware/Camera.html
28. فضای مختصات حسگر: http://developer.android.com/reference/android/hardware/
SensorEvent.html
29. مرجع امنیت و مجوزهای اندروید: http://developer.android.com/guide/topics/security/
security.html
بسیاری از این منابع به طور مستقیم یا غیرمستقیم از Android 1.6 SDK مشتق شده اند و خواهند بود
از نظر عملکردی با اطلاعات موجود در اسناد آن SDK یکسان است. در هر موردی که این
تعریف سازگاری با مستندات SDK مخالف است، مستندات SDK در نظر گرفته می شود
معتبر هر گونه جزئیات فنی ارائه شده در مراجع ذکر شده در بالا با گنجاندن در نظر گرفته می شود
بخشی از این تعریف سازگاری باشید.
3. نرم افزار
پلتفرم اندروید شامل مجموعه ای از APIهای مدیریت شده ("سخت") و بدنه ای از API های به اصطلاح "نرم" است.
مانند سیستم Intent، APIهای کد بومی و APIهای کاربردی وب. این بخش جزئیات سخت و
API‌های نرم‌افزاری که در سازگاری و همچنین برخی دیگر از رابط‌های فنی و کاربری مرتبط با سازگاری یکپارچه هستند
رفتار. پیاده سازی دستگاه باید با تمام الزامات این بخش مطابقت داشته باشد.
3.1. سازگاری API مدیریت شده
محیط اجرای مدیریت شده (مبتنی بر دالویک) وسیله اصلی برنامه های اندروید است. را
رابط برنامه نویسی برنامه اندروید (API) مجموعه ای از رابط های پلتفرم اندروید است که در معرض آن قرار می گیرند
برنامه هایی که در محیط VM مدیریت شده اجرا می شوند. پیاده سازی دستگاه باید کامل باشد
پیاده سازی، از جمله تمام رفتارهای مستند، هر API مستندی که توسط Android در معرض دید قرار گرفته است
1.6 SDK، مانند:
1. APIهای اصلی اندروید به زبان جاوا [منابع، 5].
2. ارائه دهندگان محتوا [منابع ، 6].
3. منابع [منابع، 7].
4. ویژگی ها و عناصر AndroidManifest.xml [منابع، 8].

پیاده سازی دستگاه نباید هیچ گونه API مدیریت شده را حذف کند، رابط ها یا امضاهای API را تغییر دهد، منحرف شود
از رفتار مستند، یا شامل موارد بدون عملیات، به جز مواردی که به طور خاص توسط این سازگاری مجاز است
تعریف.
3.2. سازگاری نرم افزار API
علاوه بر APIهای مدیریت شده از بخش 3.1، Android همچنین دارای یک "نرم" فقط زمان اجرا قابل توجه است.
API، در قالب مواردی مانند Intent ها، مجوزها و جنبه های مشابه برنامه های Android
که در زمان کامپایل برنامه قابل اجرا نیست. این بخش به جزئیات APIها و سیستم "نرم" می پردازد
رفتارهای مورد نیاز برای سازگاری با Android 1.6. پیاده سازی دستگاه باید تمام موارد را برآورده کند
الزامات ارائه شده در این بخش
3.2.1. مجوزها
پیاده‌کننده‌های دستگاه باید تمام ثابت‌های مجوز را همانطور که توسط سازمان ثبت شده است، پشتیبانی و اجرا کنند
صفحه مرجع مجوز [ منابع ، 9]. توجه داشته باشید که بخش 10 الزامات اضافی مربوط به را فهرست می کند
مدل امنیتی اندروید
3.2.2. ساخت پارامترها
APIهای Android شامل تعدادی ثابت در کلاس android.os.Build [Resources, 10] هستند که
برای توصیف دستگاه فعلی در نظر گرفته شده است. برای ارائه مقادیر ثابت و معنادار در سراسر دستگاه
جدول زیر شامل محدودیت‌های اضافی در قالب‌های این مقادیر است
پیاده سازی دستگاه باید مطابقت داشته باشد.
پارامتر
نظرات
نسخه سیستم اندروید در حال اجرا، به صورت انسانی
android.os.Build.VERSION.RELEASE
قالب قابل خواندن برای Android 1.6، این فیلد باید دارای مقدار رشته باشد
"1.6".
نسخه سیستم اندروید در حال اجرا، در قالب
android.os.Build.VERSION.SDK
برای کد برنامه شخص ثالث قابل دسترسی است. برای اندروید 1.6 این فیلد
باید مقدار صحیح 4 را داشته باشد.
مقداری که توسط پیاده‌کننده دستگاه انتخاب می‌شود که ساخت خاص را تعیین می‌کند
از سیستم اندروید در حال اجرا، در قالب قابل خواندن توسط انسان.
این مقدار نباید برای ساخت‌های مختلفی که تا انتها ارسال می‌شوند دوباره استفاده شود
کاربران android.os.Build.VERSION.INCREMENTAL. یک استفاده معمولی از این فیلد نشان دادن شماره ساخت یا
شناسه تغییر منبع-کنترل برای تولید بیلد استفاده شد. آنجا
هیچ الزامی در قالب خاص این زمینه وجود ندارد، به جز اینکه آن
نباید تهی یا رشته خالی ("") باشد.
مقداری که توسط پیاده‌کننده دستگاه انتخاب می‌شود که داخلی خاص را شناسایی می‌کند
سخت افزار مورد استفاده دستگاه، در قالب قابل خواندن توسط انسان. یک استفاده احتمالی
android.os.Build.BOARD
این فیلد برای نشان دادن تجدید نظر خاص برد تغذیه کننده است
دستگاه هیچ الزامی در قالب خاص این زمینه وجود ندارد،
به جز اینکه نباید تهی یا رشته خالی ("") باشد.
مقداری که توسط پیاده‌کننده دستگاه انتخاب شده و نام آن را مشخص می‌کند
android.os.Build.BRAND
شرکت، سازمان، فرد و غیره که دستگاه را تولید کرده اند، در
قالب قابل خواندن برای انسان استفاده ممکن از این فیلد نشان دادن OEM است

و/یا شرکت مخابراتی که دستگاه را فروخته است. هیچ الزامی در مورد وجود ندارد
فرمت خاص این فیلد، با این تفاوت که نباید خالی یا خالی باشد
رشته ("").
مقداری که توسط پیاده‌کننده دستگاه انتخاب می‌شود و مشخص می‌شود
پیکربندی یا تجدید نظر بدن (که گاهی اوقات به آن "صنعتی" می گویند
android.os.Build.DEVICE
طراحی") دستگاه. هیچ الزامی در قالب خاص وجود ندارد
از این فیلد، با این تفاوت که نباید تهی یا رشته خالی ("") باشد.
رشته ای که به طور منحصر به فرد این ساخت را مشخص می کند. باید منطقی باشد
قابل خواندن برای انسان باید از این الگو پیروی کند:
$(PRODUCT_BRAND)/$(PRODUCT_NAME)/$(PRODUCT_DEVICE)/
$(TARGET_BOOTLOADER_BOARD_NAME):$(PLATFORM_VERSION)/
$(BUILD_ID)/$(BUILD_NUMBER):$(TARGET_BUILD_VARIANT)/
android.os.Build.FINGERPRINT
$(BUILD_VERSION_TAGS)
به عنوان مثال: acme/mydevicel/generic/generic:donut/ERC77/
3359:usrdbug/test-keys
اثر انگشت نباید دارای فاصله باشد. اگر فیلدهای دیگری در
الگوی بالا دارای فاصله است، آنها باید با ASCII جایگزین شوند
کاراکتر زیر خط ("_") در اثر انگشت.
رشته ای که به طور منحصر به فرد میزبانی را که ساخت بر روی آن ساخته شده است، در انسان شناسایی می کند
android.os.Build.HOST
قالب قابل خواندن هیچ الزامی در قالب خاص این وجود ندارد
فیلد، با این تفاوت که نباید تهی یا رشته خالی ("") باشد.
شناسه ای که توسط پیاده کننده دستگاه برای ارجاع به یک مورد خاص انتخاب شده است
انتشار، در قالب قابل خواندن توسط انسان. این فیلد می تواند با همان
android.os.Build.VERSION.INCREMENTAL، اما باید یک مقدار باشد
android.os.Build.ID
در نظر گرفته شده است که تا حدودی برای کاربران نهایی معنادار باشد. وجود ندارد
الزامات مربوط به فرمت خاص این زمینه، با این تفاوت که نباید
null یا رشته خالی ("") باشد.
مقداری که توسط پیاده‌کننده دستگاه انتخاب شده و حاوی نام
دستگاهی که برای کاربر نهایی شناخته شده است. این باید به همین نام باشد
android.os.Build.MODEL
که تحت آن دستگاه به بازار عرضه شده و به کاربران نهایی فروخته می شود. وجود ندارد
الزامات مربوط به فرمت خاص این زمینه، با این تفاوت که نباید
null یا رشته خالی ("") باشد.
یک مقدار انتخاب شده توسط پیاده‌کننده دستگاه که شامل توسعه است
نام یا رمز دستگاه باید برای انسان قابل خواندن باشد، اما اینطور نیست
android.os.Build.PRODUCT
لزوما برای مشاهده توسط کاربران نهایی در نظر گرفته شده است. هیچ الزامی وجود ندارد
در قالب خاص این فیلد، با این تفاوت که نباید null یا null باشد
رشته خالی ("").
فهرستی از برچسب‌های جدا شده با کاما که توسط پیاده‌کننده دستگاه انتخاب شده است
ساخت را بیشتر متمایز می کند. به عنوان مثال، "unsigned, debug". این زمینه
android.os.Build.TAGS
نباید تهی یا رشته خالی ("") باشد، بلکه یک تگ واحد (مانند
"رها") خوب است.
android.os.Build.TIME
مقداری که نشان‌دهنده مُهر زمانی زمان وقوع ساخت است.
مقداری که توسط پیاده‌کننده دستگاه انتخاب شده و زمان اجرا را مشخص می‌کند
پیکربندی ساخت. این فیلد باید یکی از مقادیر را داشته باشد
android.os.Build.TYPE
مربوط به سه پیکربندی معمول زمان اجرا اندروید: "user"،
"userdbug" یا "eng".
نام یا شناسه کاربری کاربر (یا کاربر خودکار) که آن را ایجاد کرده است
android.os.Build.USER
ساختن. هیچ الزامی در قالب خاص این زمینه وجود ندارد،
به جز اینکه نباید تهی یا رشته خالی ("") باشد.

3.2.3. سازگاری قصد
Android از Intent برای دستیابی به یکپارچگی آزادانه بین برنامه‌ها استفاده می‌کند. این بخش توضیح می دهد
الزامات مربوط به الگوهای Intent که باید توسط پیاده سازی دستگاه رعایت شوند. توسط
"با افتخار"، منظور این است که پیاده‌کننده دستگاه باید یک فعالیت، سرویس یا موارد دیگر Android ارائه دهد
مؤلفه‌ای که یک فیلتر Intent منطبق را مشخص می‌کند و به آن متصل می‌شود و رفتار صحیح را برای هر کدام پیاده‌سازی می‌کند
الگوی هدف مشخص شده
3.2.3.1. اهداف اصلی برنامه
پروژه بالادستی اندروید تعدادی برنامه اصلی را تعریف می کند، مانند شماره گیر تلفن، تقویم،
کتاب مخاطبین، پخش کننده موسیقی و غیره. پیاده‌کننده‌های دستگاه ممکن است این برنامه‌ها را جایگزین کنند
نسخه های جایگزین
با این حال، هر گونه نسخه جایگزین باید از همان الگوهای Intent ارائه شده توسط بالادست پیروی کند
پروژه (به عنوان مثال، اگر دستگاهی حاوی یک پخش کننده موسیقی جایگزین باشد، همچنان باید الگوی Intent را رعایت کند
توسط برنامه های شخص ثالث برای انتخاب آهنگ صادر شده است.) پیاده سازی دستگاه باید از همه الگوهای Intent پشتیبانی کند.
فهرست شده در ضمیمه A.
3.2.3.2. نادیده گرفتن قصد
از آنجایی که اندروید یک پلتفرم قابل توسعه است، پیاده‌کننده‌های دستگاه باید به هر الگوی Intent که در آن توضیح داده شده است اجازه دهند
ضمیمه A باید توسط برنامه های شخص ثالث لغو شود. پروژه منبع باز اندروید بالادست
به طور پیش فرض این اجازه را می دهد. پیاده‌کننده‌های دستگاه نباید امتیازات خاصی را به برنامه‌های سیستمی متصل کنند.
استفاده از این الگوهای Intent، یا جلوگیری از اتصال برنامه های شخص ثالث به آنها و کنترل آن ها
این الگوها این ممنوعیت به طور خاص شامل غیرفعال کردن رابط کاربری "انتخاب کننده" است که اجازه می دهد
کاربر بین برنامه های متعددی که همگی الگوی Intent یکسانی دارند، انتخاب کند.
3.2.3.3. Intent Namespaces
پیاده‌کننده‌های دستگاه نباید هیچ مؤلفه Android را که هر قصد یا Intent جدید را رعایت می‌کند، شامل شوند
پخش الگوهای هدف با استفاده از ACTION، CATEGORY یا رشته کلیدهای دیگر در فضای نام android.*.
پیاده‌کننده‌های دستگاه نباید شامل هیچ مؤلفه‌ای برای Android باشند که به هر Intent یا جدید احترام می‌گذارد
الگوهای هدف پخش با استفاده از ACTION، CATEGORY یا رشته کلیدهای دیگر در فضای بسته
متعلق به سازمان دیگری پیاده‌کننده‌های دستگاه نباید هیچ یک از Intent را تغییر داده یا گسترش دهند
الگوهای ذکر شده در ضمیمه های A یا B.
این ممنوعیت مشابه آن چیزی است که برای کلاس های زبان جاوا در بخش 3.6 مشخص شده است.

3.2.3.4. اهداف پخش
برنامه های شخص ثالث برای پخش Intent های خاص به پلتفرم متکی هستند تا تغییرات در آن را به آنها اطلاع دهند
محیط سخت افزاری یا نرم افزاری دستگاه های سازگار با Android باید پخش عمومی را پخش کنند
مقاصد در پاسخ به رویدادهای سیستم مناسب. فهرستی از اهداف پخش مورد نیاز در ارائه شده است
ضمیمه B؛ با این حال، توجه داشته باشید که SDK ممکن است اهداف پخش اضافی را تعریف کند، که باید نیز باشد
مفتخر شد.
3.3. سازگاری Native API
کدهای مدیریت شده در حال اجرا در Dalvik می توانند به کد بومی ارائه شده در فایل apk. برنامه به عنوان ELF فراخوانی کنند.
فایل .so برای معماری سخت افزاری دستگاه مناسب کامپایل شده است. پیاده سازی دستگاه باید شامل باشد
پشتیبانی از کدهای در حال اجرا در محیط مدیریت شده برای فراخوانی کد بومی با استفاده از جاوا استاندارد
معناشناسی رابط بومی (JNI). APIهای زیر باید برای کد بومی در دسترس باشند:
• libc (کتابخانه C)
• libm (کتابخانه ریاضی)
• رابط JNI
• libz (فشرده سازی Zlib)
• liblog (ورود به سیستم اندروید)
• حداقل پشتیبانی از C++
• OpenGL ES 1.1
این کتابخانه ها باید با منبع سازگار (به عنوان مثال سازگار با هدر) و سازگار با دودویی (برای یک مورد خاص) باشند.
معماری پردازنده) با نسخه های ارائه شده در Bionic توسط پروژه متن باز اندروید. از آنجا که
پیاده سازی های Bionic به طور کامل با سایر پیاده سازی ها مانند GNU C سازگار نیستند
کتابخانه، پیاده‌کنندگان دستگاه باید از پیاده‌سازی اندروید استفاده کنند. اگر مجریان دستگاه از الف استفاده کنند
اجرای متفاوت این کتابخانه ها، باید از سازگاری هدر و باینری اطمینان حاصل کنند.
سازگاری کد بومی چالش برانگیز است. به همین دلیل، ما می خواهیم تکرار کنیم که پیاده کننده های دستگاه هستند
به شدت تشویق می شود که از پیاده سازی های بالادستی کتابخانه های ذکر شده در بالا برای کمک استفاده کنید
اطمینان از سازگاری
3.4. سازگاری Web API
بسیاری از توسعه دهندگان و برنامه ها به رفتار کلاس android.webkit.WebView [ منابع ،
11] برای رابط کاربری آنها، بنابراین پیاده سازی WebView باید در سراسر Android سازگار باشد
پیاده سازی ها پیاده سازی متن باز اندروید از نسخه موتور رندر WebKit استفاده می کند
WebView را پیاده سازی کنید.
از آنجا که توسعه یک مجموعه آزمایشی جامع برای یک مرورگر وب، پیاده‌کننده‌های دستگاه، امکان‌پذیر نیست
باید از ساخت بالادستی خاص WebKit در پیاده سازی WebView استفاده کنید. به طور مشخص:
• WebView باید از ساخت 528.5+ WebKit از درخت متن باز Android بالادستی استفاده کند.
اندروید 1.6. این ساخت شامل مجموعه خاصی از عملکردها و اصلاحات امنیتی برای WebView است.
• رشته عامل کاربر گزارش شده توسط WebView باید در این قالب باشد:
Mozilla/5.0 (Linux; U; Android 1.6; <language>-<country>; <device
نام>; Build/<build ID>) AppleWebKit/528.5+ (KHTML، مانند Gecko)
نسخه/3.1.2 موبایل سافاری/525.20.1

◦ رشته "<Device name>" باید با مقدار برای یکسان باشد
android.os.Build.MODEL
◦ رشته "<build ID>" باید با مقدار android.os.Build.ID یکسان باشد.
◦ رشته های "<language>" و "<country>" باید از قراردادهای معمول برای
کد کشور و زبان، و SHOULD به محلی فعلی دستگاه در
زمان درخواست
پیاده سازی ها ممکن است یک رشته عامل کاربر سفارشی را در برنامه مرورگر مستقل ارسال کنند. چه
بیشتر، ممکن است مرورگر مستقل مبتنی بر فناوری مرورگر جایگزین (مانند فایرفاکس،
Opera، و غیره) با این حال، حتی اگر یک برنامه مرورگر جایگزین ارسال شود، مؤلفه WebView
همانطور که در بالا به برنامه های شخص ثالث ارائه می شود، باید براساس WebKit باشد.
برنامه مرورگر مستقل باید شامل پشتیبانی از Gears [ Resources, 12] و MAY باشد.
شامل پشتیبانی از برخی یا همه HTML5 باشد.
3.5. سازگاری رفتاری API
رفتارهای هر یک از انواع API (مدیریت شده، نرم، بومی و وب) باید با
پیاده سازی ترجیحی اندروید از پروژه منبع باز Android در دسترس است.
برخی از زمینه های خاص سازگاری عبارتند از:
• دستگاه ها نباید رفتار یا معنای یک هدف استاندارد را تغییر دهند
• دستگاه ها نباید چرخه حیات یا چرخه حیات معنایی نوع خاصی از سیستم را تغییر دهند
جزء (مانند سرویس، فعالیت، ارائه دهنده محتوا و غیره)
• دستگاه ها نباید معنای یک مجوز خاص را تغییر دهند
لیست بالا جامع نیست و مسئولیت اطمینان از رفتار بر عهده پیاده‌کنندگان دستگاه است
سازگاری به همین دلیل، پیاده‌کنندگان دستگاه باید از کد منبع موجود از طریق استفاده کنند
پروژه متن باز Android در صورت امکان، به جای اجرای مجدد بخش های قابل توجهی از سیستم.
مجموعه تست سازگاری (CTS) بخش های قابل توجهی از پلتفرم را برای سازگاری رفتاری آزمایش می کند.
اما نه همه اطمینان از سازگاری رفتاری با اندروید بر عهده اجراکننده است
پروژه متن باز
3.6. فضاهای نام API
اندروید از قراردادهای فضای نام بسته و کلاس تعریف شده توسط برنامه نویسی جاوا پیروی می کند
زبان برای اطمینان از سازگاری با برنامه‌های شخص ثالث، اجراکنندگان دستگاه نباید بسازند
هر گونه تغییر ممنوعه (به زیر مراجعه کنید) در این فضاهای نام بسته:
• جاوا.*
• javax.*
• آفتاب.*
• اندروید.*
• com.android.*
تغییرات ممنوعه عبارتند از:
• پیاده سازی های دستگاه نباید API های در معرض عموم را در پلت فرم Android تغییر دهند
با تغییر هر روش یا امضای کلاس، یا با حذف کلاس ها یا فیلدهای کلاس.

• پیاده‌کننده‌های دستگاه ممکن است اجرای اساسی APIها را تغییر دهند، اما چنین است
تغییرات نباید بر رفتار بیان شده و امضای زبان جاوا تأثیر بگذارد
API های در معرض عموم
• پیاده‌کننده‌های دستگاه نباید هیچ عنصری که به‌صورت عمومی در معرض دید قرار می‌گیرد (مانند کلاس‌ها یا.) اضافه کنند
رابط‌ها، یا فیلدها یا روش‌های کلاس‌ها یا رابط‌های موجود) به APIهای بالا.
"عنصر در معرض عموم" هر ساختاری است که با نشانگر "@hide" در
کد منبع بالادستی اندروید به عبارت دیگر، پیاده‌کننده‌های دستگاه نباید APIهای جدید یا افشا کنند
APIهای موجود را در فضاهای نام ذکر شده در بالا تغییر دهید. پیاده‌کننده‌های دستگاه ممکن است فقط داخلی بسازند
تغییرات، اما این اصلاحات نباید تبلیغ شوند یا در معرض دید توسعه دهندگان قرار گیرند.
پیاده‌کننده‌های دستگاه ممکن است API‌های سفارشی اضافه کنند، اما چنین API‌هایی نباید در یک فضای نام متعلق به خود باشند.
توسط یا ارجاع به سازمان دیگری. برای مثال، پیاده‌کننده‌های دستگاه نباید API را به آن اضافه کنند
com.google.* یا فضای نام مشابه؛ فقط گوگل می تواند این کار را انجام دهد. به طور مشابه، Google نباید API را به آن اضافه کند
فضای نام شرکت های دیگر
اگر یک پیاده‌کننده دستگاه پیشنهاد بهبود یکی از فضاهای نام بسته بالا را بدهد (مانند افزودن
عملکرد جدید مفید به یک API موجود، یا افزودن یک API جدید)، پیاده‌کننده باید بازدید کند
source.android.com و فرآیند کمک به تغییرات و کد را با توجه به
اطلاعات آن سایت
توجه داشته باشید که محدودیت‌های بالا با قراردادهای استاندارد برای نام‌گذاری APIها در جاوا مطابقت دارد
زبان برنامه نویسی؛ هدف این بخش صرفاً تقویت آن قراردادها و الزام آور ساختن آنهاست
از طریق گنجاندن در این تعریف سازگاری.
3.7. سازگاری با ماشین مجازی
یک دستگاه Android سازگار باید از مشخصات بایت کد کامل Dalvik Executable (DEX) پشتیبانی کند
معناشناسی ماشین مجازی دالویک [منابع، 13].
3.8. سازگاری با رابط کاربری
پلتفرم اندروید شامل برخی از API های توسعه دهنده است که به توسعه دهندگان اجازه می دهد تا به کاربر سیستم متصل شوند
رابط. پیاده‌سازی‌های دستگاه باید این APIهای استاندارد UI را در رابط‌های کاربر سفارشی بگنجانند
همانطور که در زیر توضیح داده شده است، توسعه می یابند.
3.8.1. ابزارک ها
Android یک نوع مؤلفه و API و چرخه حیات مربوطه را تعریف می کند که به برنامه ها اجازه می دهد تا در معرض دید قرار گیرند
یک "AppWidget" برای کاربر نهایی [منابع ، 14] . نسخه مرجع منبع باز اندروید شامل یک
برنامه راه‌اندازی که شامل عناصر رابط کاربری است که به کاربر امکان افزودن، مشاهده و حذف را می‌دهد
AppWidgets از صفحه اصلی.
پیاده‌کننده‌های دستگاه ممکن است جایگزینی را برای راه‌انداز مرجع (یعنی صفحه اصلی) جایگزین کنند.
راه‌اندازهای جایگزین باید شامل پشتیبانی داخلی برای AppWidgets باشند و رابط کاربری را در معرض نمایش قرار دهند
عناصری برای افزودن، مشاهده و حذف AppWidgets مستقیماً در Launcher. پرتاب کننده های جایگزین ممکن است
این عناصر رابط کاربری را حذف کنید. با این حال، اگر آنها حذف شوند، پیاده‌کننده دستگاه باید a
برنامه جداگانه قابل دسترسی از Launcher که به کاربران امکان افزودن، مشاهده و حذف را می دهد
AppWidgets.

3.8.2. اطلاعیه
Android شامل APIهایی است که به توسعه دهندگان اجازه می دهد تا کاربران را از رویدادهای قابل توجه مطلع کنند [منابع، 15]. دستگاه
پیاده‌کننده‌ها باید برای هر دسته از اعلان‌هایی که به این شکل تعریف شده است، پشتیبانی ارائه دهند. به طور خاص: صداها،
لرزش، نور و نوار وضعیت.
علاوه بر این، پیاده سازی باید به درستی رندر شود و همه منابع (آیکون ها، فایل های صوتی و غیره)
در APIها [منابع، 7]، یا در راهنمای سبک نماد نوار وضعیت [منابع ، 16] ارائه شده است. دستگاه
پیاده‌کننده‌ها ممکن است یک تجربه کاربری جایگزین برای اعلان‌ها نسبت به تجربه ارائه‌شده توسط سازمان ارائه دهند
مرجع اجرای متن باز اندروید; با این حال، چنین سیستم های اطلاع رسانی جایگزین باید
همانطور که در بالا ذکر شد، از منابع اطلاع رسانی موجود پشتیبانی کنید.
3.8.3. جستجو کردن
Android شامل APIهایی است [منابع، 17] که به توسعه دهندگان اجازه می دهد جستجو را در برنامه های خود بگنجانند،
و داده های برنامه خود را در جستجوی سیستم جهانی قرار دهند. به طور کلی، این قابلیت
متشکل از یک رابط کاربری واحد و در سطح سیستم است که به کاربران اجازه می دهد پرس و جوها را وارد کنند، پیشنهادات را نمایش دهند
as users type, and displays results. The Android APIs allow developers to reuse this interface to provide
search within their own apps, and allow developers to supply results to the common global search user
interface.
Device implementations MUST include a single, shared, system-wide search user interface capable of
real-time suggestions in response to user input. Device implementations MUST implement the APIs that
allow developers to reuse this user interface to provide search within their own applications.
Device implementations MUST implement the APIs that allow third-party applications to add suggestions
to the search box when it is run in global search mode. If no third-party applications are installed that
make use of this functionality, the default behavior SHOULD be to display web search engine results and
suggestions.
Device implementations MAY ship alternate search user interfaces, but SHOULD include a hard or soft
dedicated search button, that can be used at any time within any app to invoke the search framework,
with the behavior provided for in the API documentation.
3.8.4. Toasts
Applications can use the "Toast" API (defined in [ Resources, 18]) to display short non-modal strings to the
end user, that disappear after a brief period of time. Device implementations MUST display Toasts from
applications to end users in some high-visibility manner.
4. Reference Software Compatibility
Device implementers MUST test implementation compatibility using the following open-source
applications:
• Calculator (included in SDK)
• Lunar Lander (included in SDK)
• ApiDemos (included in SDK)
• The "Apps for Android" applications [ Resources, 19]
Each app above MUST launch and behave correctly on the implementation, for the implementation to be

considered compatible.
5. Application Packaging Compatibility
Device implementations MUST install and run Android ".apk" files as generated by the "aapt" tool
included in the official Android SDK [ Resources , 20].
Devices implementations MUST NOT extend either the .apk, Android Manifest, or Dalvik bytecode
formats in such a way that would prevent those files from installing and running correctly on other
compatible devices. Device implementers SHOULD use the reference upstream implementation of Dalvik,
and the reference implementation's package management system.
6. Multimedia Compatibility
A compatible Android device must support the following multimedia codecs. All of these codecs are
provided as software implementations in the preferred Android implementation from the Android Open
Source Project [ Resources , 4].
Please note that neither Google nor the Open Handset Alliance make any representation that these
codecs are unencumbered by third-party patents. Those intending to use this source code in hardware or
software products are advised that implementations of this code, including in open source software or
shareware, may require patent licenses from the relevant patent holders.
Audio
Name
Encoder Decoder Details
Files Supported
Mono/Stereo content in any
3GPP (.3gp) and
combination of standard bit rates
MPEG-4 (.mp4, .m4a)
AAC LC/LTP
X
up to 160 kbps and sampling rates files. No support for raw
between 8 to 48kHz
AAC (.aac)
Mono/Stereo content in any
3GPP (.3gp) and
HE-AACv1
combination of standard bit rates
MPEG-4 (.mp4, .m4a)
X
(AAC+)
up to 96 kbps and sampling rates files. No support for raw
between 8 to 48kHz
AAC (.aac)
Mono/Stereo content in any
HE-AACv2
3GPP (.3gp) and
combination of standard bit rates
(enhanced
MPEG-4 (.mp4, .m4a)
X
up to 96 kbps and sampling rates
AAC+)
files. No support for raw
between 8 to 48kHz
AAC (.aac)
AMR-NB
4.75 to 12.2 kbps sampled @
3GPP (.3gp) files
X
X
8kHz
AMR-WB
9 rates from 6.60 kbit/s to 23.85
-3GPP (.3gp) files
X
kbit/s sampled @ 16kHz
MP3
Mono/Stereo 8-320Kbps constant MP3 (.mp3) files
X
(CBR) or variable bit-rate (VBR)
Type 0 and 1 (.mid, .xmf,
MIDI Type 0 and 1. DLS Version 1
MIDI
X
.mxmf). Also RTTTL/RTX
and 2. XMF and Mobile XMF.
(.rtttl, .rtx), OTA (.ota),

Support for ringtone formats
and iMelody (.imy)
RTTTL/RTX, OTA, and iMelody
Ogg Vorbis
.ogg
X
8- and 16-bit linear PCM (rates up
PCM
X
WAVE
to limit of hardware)
Image
Files
Name
Encoder Decoder Details
Supported
JPEG
X
X
base+progressive
GIF
X
PNG
X
X
BMP
X
Video
Files
Name
Encoder Decoder Details
Supported
3GPP (.3gp)
H.263
X
X
files
3GPP (.3gp)
H.264
X
and MPEG-4
(.mp4) files
MPEG4
X
3GPP (.3gp) file
SP
7. Developer Tool Compatibility
Device implementations MUST support the Android Developer Tools provided in the Android SDK.
Specifically, Android-compatible devices MUST be compatible with:
• Android Debug Bridge or adb [Resources , 21]
Device implementations MUST support all adb functions as documented in the Android
SDK. The device-side adb daemon SHOULD be inactive by default, but there MUST be a user-
accessible mechanism to turn on the Android Debug Bridge.
• Dalvik Debug Monitor Service or ddms [Resources , 22]
Device implementations MUST support all ddms features as documented in the Android SDK.
As ddms uses adb, support for ddms SHOULD be inactive by default, but MUST be supported
whenever the user has activated the Android Debug Bridge, as above.

• Monkey [Resources, 23]
Device implementations MUST include the Monkey framework, and make it available for
applications to use.
8. Hardware Compatibility
Android is intended to support device implementers creating innovative form factors and configurations.
At the same time Android developers expect certain hardware, sensors and APIs across all Android
device. This section lists the hardware features that all Android 1.6 compatible devices must support. In
Android 1.6, the majority of hardware features (such as WiFi, compass, and accelerometer) are required.
If a device includes a particular hardware component that has a corresponding API for third-party
developers, the device implementation MUST implement that API as defined in the Android SDK
documentation.
8.1. Display
Android 1.6 includes facilities that perform certain automatic scaling and transformation operations under
some circumstances, to ensure that third-party applications run reasonably well on hardware
configurations for which they were not necessarily explicitly designed [Resources, 24] . Devices MUST
properly implement these behaviors, as detailed in this section.
8.1.1. Standard Display Configurations
This table lists the standard screen configurations considered compatible with Android:
Diagonal
Screen Size
Screen Density
Screen Type
Width (Pixels)
Height (Pixels)
Length Range
Group
Group
(inches)
QVGA
240
320
2.6 - 3.0
Small
Low
WQVGA
240
400
3.2 - 3.5
Normal
Low
FWQVGA
240
432
3.5 - 3.8
Normal
Low
HVGA
320
480
3.0 - 3.5
Normal
Medium
WVGA
480
800
3.3 - 4.0
Normal
High
FWVGA
480
854
3.5 - 4.0
Normal
High
WVGA
480
800
4.8 - 5.5
Large
Medium
FWVGA
480
854
5.0 - 5.8
Large
Medium
Device implementations corresponding to one of the standard configurations above MUST be configured
to report the indicated screen size to applications via the android.content.res.Configuration [ Resources,
25] class.
Some .apk packages have manifests that do not identify them as supporting a specific density range.
When running such applications, the following constraints apply:

• Device implementations MUST interpret any resources that are present as defaulting to
"medium" (known as "mdpi" in the SDK documentation.)
• When operating on a "low" density screen, device implementations MUST scale down medium/
mdpi assets by a factor of 0.75.
• When operating on a "high" density screen, device implementations MUST scale up medium/
mdpi assets by a factor of 1.5.
• Device implementations MUST NOT scale assets within a density range, and MUST scale
assets by exactly these factors between density ranges.
8.1.2. Non-Standard Display Configurations
Display configurations that do not match one of the standard configurations listed in Section 8.2.1 require
additional consideration and work to be compatible. Device implementers MUST contact Android
Compatibility Team as provided for in Section 12 to obtain classifications for screen-size bucket, density,
and scaling factor. When provided with this information, device implementations MUST implement them
as specified.
Note that some display configurations (such as very large or very small screens, and some aspect ratios)
are fundamentally incompatible with Android 1.6; therefore device implementers are encouraged to
contact Android Compatibility Team as early as possible in the development process.
8.1.3. Display Metrics
Device implementations MUST report correct values for all display metrics defined in
android.util.DisplayMetrics [Resources , 26].
8.2. Keyboard
Device implementations:
• MUST include support for the Input Management Framework (which allows third party
developers to create Input Management Engines -- ie soft keyboard) as detailed at
developer.android.com
• MUST provide at least one soft keyboard implementation (regardless of whether a hard
keyboard is present)
• MAY include additional soft keyboard implementations
• MAY include a hardware keyboard
• MUST NOT include a hardware keyboard that does not match one of the formats specified
in android.content.res.Configuration [ Resources, 25] (that is, QWERTY, or 12-key)
8.3. Non-touch Navigation
Device implementations:
• MAY omit non-touch navigation options (that is, may omit a trackball, 5-way directional pad, or
wheel)
• MUST report via android.content.res.Configuration [Resources , 25] the correct value for the
device's hardware

8.4. Screen Orientation
Compatible devices MUST support dynamic orientation by applications to either portrait or landscape
screen orientation. That is, the device must respect the application's request for a specific screen
orientation. Device implementations MAY select either portrait or landscape orientation as the default.
Devices MUST report the correct value for the device's current orientation, whenever queried via the
android.content.res.Configuration.orientation, android.view.Display.getOrientation(), or other APIs.
8.5. Touchscreen input
Device implementations:
• MUST have a touchscreen
• MAY have either capacative or resistive touchscreen
• MUST report the value of android.content.res.Configuration [ Resources, 25] reflecting
corresponding to the type of the specific touchscreen on the device
8.6. USB
Device implementations:
• MUST implement a USB client, connectable to a USB host with a standard USB-A port
• MUST implement the Android Debug Bridge over USB (as described in Section 7)
• MUST implement a USB mass storage client for the removable/media storage is present in the
device
• SHOULD use the micro USB form factor on the device side
• SHOULD implement support for the USB Mass Storage specification (so that either removable
or fixed storage on the device can be accessed from a host PC)
• MAY include a non-standard port on the device side, but if so MUST ship with a cable capable of
connecting the custom pinout to standard USB-A port
8.7. Navigation keys
The Home, Menu and Back functions are essential to the Android navigation paradigm. Device
implementations MUST make these functions available to the user at all times, regardless of application
state. These functions SHOULD be implemented via dedicated buttons. They MAY be implemented
using software, gestures, touch panel, etc., but if so they MUST be always accessible and not obscure or
interfere with the available application display area.
Device implementers SHOULD also provide a dedicated search key. Device implementers MAY also
provide send and end keys for phone calls.
8.8. WiFi
Device implementations MUST support 802.11b and 802.11g, and MAY support 802.11a.

8.9. Camera
Device implementations MUST include a camera. The included camera:
• MUST have a resolution of at least 2 megapixels
• SHOULD have either hardware auto-focus, or software auto-focus implemented in the camera
driver (transparent to application software)
• MAY have fixed-focus or EDOF (extended depth of field) hardware
• MAY include a flash. If the Camera includes a flash, the flash lamp MUST NOT be lit while an
android.hardware.Camera.PreviewCallback instance has been registered on a Camera preview
surface.
Device implementations MUST implement the following behaviors for the camera-related APIs
[Resources, 27] :
1. If an application has never called android.hardware.Camera.Parameters.setPreviewFormat(int),
then the device MUST use android.hardware.PixelFormat.YCbCr_420_SP for preview data
provided to application callbacks.
2. If an application registers an android.hardware.Camera.PreviewCallback instance and the
system calls the onPreviewFrame() method when the preview format is YCbCr_420_SP, the
data in the byte[] passed into onPreviewFrame() must further be in the NV21 encoding format.
(This is the format used natively by the 7k hardware family.) That is, NV21 MUST be the default.
8.9.1. Non-Autofocus Cameras
If a device lacks an autofocus camera, the device implementer MUST meet the additional requirements in
this section. Device implementations MUST implement the full Camera API included in the Android 1.6
SDK documentation in some reasonable way, regardless of actual camera hardware's capabilities.
For Android 1.6, if the camera lacks auto-focus, the device implementation MUST adhere to the following:
1. The system MUST include a read-only system property named "ro.workaround.noautofocus"
with the value of "1". This value is intended to be used by applications such as Android Market to
selectively identify device capabilities, and will be replaced in a future version of Android with a
robust API.
2. If an application calls android.hardware.Camera.autoFocus(), the system MUST call the
onAutoFocus() callback method on any registered
android.hardware.Camera.AutoFocusCallback instances, even though no focusing actually
happened. This is to avoid having existing applications break by waiting forever for an autofocus
callback that will never come.
3. The call to the AutoFocusCallback.onAutoFocus() method MUST be triggered by the driver or
framework in a new event on the main framework Looper thread. That is, Camera.autoFocus()
MUST NOT directly call AutoFocusCallback.onAutoFocus() since this violates the Android
framework threading model and will break apps.
8.10. Accelerometer
Device implementations MUST include a 3-axis accelerometer and MUST be able to deliver events at at
least 50 Hz. The coordinate system used by the accelerometer MUST comply with the Android sensor
coordinate system as detailed in the Android API s [Resources , 28].

8.11. Compass
Device implementations MUST include a 3-axis compass and MUST be able to deliver events at at least
10 Hz. The coordinate system used by the compass MUST comply with the Android sensor coordinate
system as defined in the Android API [Resources , 28].
8.12. GPS
Device implementations MUST include a GPS, and SHOULD include some form of "assisted GPS"
technique to minimize GPS lock-on time.
8.13. Telephony
Device implementations:
• MUST include either GSM or CDMA telephony
• MUST implement the appropriate APIs as detailed in the Android SDK documentation at
developer.android.com
Note that this requirement implies that non-phone devices are not compatible with Android 1.6; Android
1.6 devices MUST include telephony hardware. Please see Appendix C for information on non-phone
devices.
8.14. Volume controls
Android-compatible devices MUST include a mechanism to allow the user to increase and decrease the
audio volume. Device implementations MUST make these functions available to the user at all times,
regardless of application state. These functions MAY be implemented using physical hardware keys,
software, gestures, touch panel, etc., but they MUST be always accessible and not obscure or interfere
with the available application display area (see Display above).
When these buttons are used, the corresponding key events MUST be generated and sent to the
foreground application. If the event is not intercepted and sunk by the application then device
implementation MUST handle the event as a system volume control.
9. Performance Compatibility
One of the goals of the Android Compatibility Program is to ensure a consistent application experience for
consumers. Compatible implementations must ensure not only that applications simply run correctly on
the device, but that they do so with reasonable performance and overall good user experience.
Device implementations MUST meet the key performance metrics of an Android 1.6 compatible device,
as in the table below:
Metric
Performance Threshold
Comments

This is tested by CTS.
The following applications
The launch time is measured as the total time to
should launch within the
complete loading the default activity for the
Application
specified time.
application, including the time it takes to start the
Launch Time
Browser: less than 1300ms
Linux process, load the Android package into the
MMS/SMS: less than 700ms
Dalvik VM, and call onCreate.
AlarmClock: less than 650ms
Multiple applications will be
This is tested by CTS.
launched. Re-launching the
Simultaneous first application should
Applications
complete taking less than the
original launch time.
10. Security Model Compatibility
Device implementations MUST implement a security model consistent with the Android platform security
model as defined in Security and Permissions reference document in the APIs [Resources, 29] in the
Android developer documentation. Device implementations MUST support installation of self-signed
applications without requiring any additional permissions/certificates from any third parties/authorities.
Specifically, compatible devices MUST support the following security mechanisms:
10.1. Permissions
Device implementations MUST support the Android permissions model as defined in the Android
developer documentation [ Resources , 9]. Specifically, implementations MUST enforce each permission
defined as described in the SDK documentation; no permissions may be omitted, altered, or ignored.
Implementations MAY add additional permissions, provided the new permission ID strings are not in the
android.* namespace.
10.2. User and Process Isolation
Device implementations MUST support the Android application sandbox model, in which each application
runs as a unique Unix-style UID and in a separate process.
Device implementations MUST support running multiple applications as the same Linux user ID, provided
that the applications are properly signed and constructed, as defined in the Security and Permissions
reference [ Resources , 29].

10.3. Filesystem Permissions
Device implementations MUST support the Android file access permissions model as defined in as
defined in the Security and Permissions reference [Resources , 29].
11. Compatibility Test Suite
Device implementations MUST pass the Android Compatibility Test Suite (CTS) [ Resources, 3] available
from the Android Open Source Project, using the final shipping software on the device. Additionally,
device implementers SHOULD use the reference implementation in the Android Open Source tree as
much as possible, and MUST ensure compatibility in cases of ambiguity in CTS and for any
reimplementations of parts of the reference source code.
The CTS is designed to be run on an actual device. Like any software, the CTS may itself contain bugs.
The CTS will be versioned independently of this Compatibility Definition, and multiple revisions of the
CTS may be released for Android 1.6. However, such releases will only fix behavioral bugs in the CTS
tests and will not impose any new tests, behaviors or APIs for a given platform release.
12. Contact Us
You can contact the Android Compatibility Team at compatibility@android.com for clarifications related to
this Compatibiltiy Definition and to provide feedback on this Definition.

Appendix A: Required Application Intents
NOTE: this list is provisional, and will be updated in the future.
Application Actions
Schemes MIME Types
(none)
text/plain
http
text/html
Browser
android.intent.action.VIEW
https
application/xhtml+xml
application/
vnd.wap.xhtml+xml
(none)
android.intent.action.WEB_SEARCH
http
(none)
https
android.media.action.IMAGE_CAPTURE
android.media.action.STILL_IMAGE_CAMERA
Camera
android.media.action.VIDEO_CAMERA
android.media.action.VIDEO_CAPTURE
vnd.android.cursor.dir/
android.intent.action.VIEW
image
android.intent.action.GET_CONTENT
vnd.android.cursor.dir/
android.intent.action.PICK
video
android.intent.action.ATTACH_DATA
image/*
video/*
android.intent.action.VIEW
rtsp
video/mp4
video/3gp
android.intent.action.VIEW
http
video/3gpp
video/3gpp2
android.intent.action.DIAL
Phone /
android.intent.action.VIEW
tel
Contacts
android.intent.action.CALL
android.intent.action.DIAL
vnd.android.cursor.dir/
android.intent.action.VIEW
person

vnd.android.cursor.dir/
person
vnd.android.cursor.dir/
android.intent.action.PICK
phone
vnd.android.cursor.dir/
postal-address
vnd.android.cursor.item/
person
vnd.android.cursor.item/
android.intent.action.GET_CONTENT
phone
vnd.android.cursor.item/
postal-address
text/plain
Email
android.intent.action.SEND
image/*
video/*
android.intent.action.VIEW
mailto
android.intent.action.SENDTO
sms
android.intent.action.VIEW
smsto
SMS / MMS android.intent.action.SENDTO
mms
mmsto
audio/*
application/ogg
Music
android.intent.action.VIEW
file
application/x-ogg
application/itunes
audio/mp3
audio/x-mp3
android.intent.action.VIEW
http
audio/mpeg
audio/mp4
audio/mp4a-latm
vnd.android.cursor.dir/
artistalbum
vnd.android.cursor.dir/
album
vnd.android.cursor.dir/
android.intent.action.PICK
nowplaying
vnd.android.cursor.dir/
track
nd.android.cursor.dir/
playlist
vnd.android.cursor.dir/
video
media/*
audio/*
android.intent.action.GET_CONTENT
application/ogg
application/x-ogg
video/*

content
Package
android.intent.action.VIEW
file
Installer
package
file
android.intent.action.PACKAGE_INSTALL
http
https
android.intent.action.ALL_APPS
android.settings.SETTINGS
android.settings.WIRELESS_SETTINGS
android.settings.AIRPLANE_MODE_SETTINGS
android.settings.WIFI_SETTINGS
android.settings.APN_SETTINGS
android.settings.BLUETOOTH_SETTINGS
android.settings.DATE_SETTINGS
android.settings.LOCALE_SETTINGS
Settings
android.settings.INPUT_METHOD_SETTINGS
com.android.settings.SOUND_SETTINGS
com.android.settings.DISPLAY_SETTINGS
android.settings.SECURITY_SETTING
android.settings.LOCATION_SOURCE_SETTINGS
android.settings.INTERNAL_STORAGE_SETTINGS
android.settings.MEMORY_CARD_SETTINGS
android.intent.action.SET_WALLPAPER
Search
android.intent.action.SEARCH
query
android.intent.action.SEARCH_LONG_PRESS
Voice
android.intent.action.VOICE_COMMAND
Contacts Management
Intent Action
Description
Starts an Activity that lets the user pick
ATTACH_IMAGE
a contact to attach an image to.
Used
EXTRA_CREATE_DESCRIPTION
with SHOW_OR_CREATE_CONTACT to
specify an exact description to be

shown when prompting user about
creating a new contact.
Used
with SHOW_OR_CREATE_CONTACT to
EXTRA_FORCE_CREATE
force creating a new contact if no
matching contact found.
This is the intent that is fired when a
SEARCH_SUGGESTION_CLICKED
search suggestion is clicked on.
This is the intent that is fired when a
SEARCH_SUGGESTION_CREATE_CONTACT_CLICKED search suggestion for creating a
contact is clicked on.
This is the intent that is fired when a
SEARCH_SUGGESTION_DIAL_NUMBER_CLICKED
search suggestion for dialing a number
is clicked on.
Takes as input a data URI with a mailto:
SHOW_OR_CREATE_CONTACT
or tel: scheme.

Appendix B: Required Broadcast Intents NOTE: this list is provisional, and will be
updated in the future.
Intent Action
Description
Broadcast Action: This is broadcast once, after the
ACTION_BOOT_COMPLETED
system has finished booting.
Broadcast Action: This is broadcast once, when a
ACTION_CALL_BUTTON
call is received.
Broadcast Action: The "Camera Button" was
ACTION_CAMERA_BUTTON
pressed.
Broadcast Action: The current
ACTION_CONFIGURATION_CHANGED
device Configuration (orientation, locale, etc) has
changed.
ACTION_DATE_CHANGED
Broadcast Action: The date has changed.
Broadcast Action: Indicates low memory condition
ACTION_DEVICE_STORAGE_LOW
on the device
Broadcast Action: Indicates low memory condition
ACTION_DEVICE_STORAGE_OK
on the device no longer exists
Broadcast Action: Wired Headset plugged in or
ACTION_HEADSET_PLUG
unplugged.
Broadcast Action: An input method has been
ACTION_INPUT_METHOD_CHANGED
changed.
Broadcast Action: External media was removed
ACTION_MEDIA_BAD_REMOVAL
from SD card slot, but mount point was not
unmounted.
Broadcast Action: The "Media Button" was
ACTION_MEDIA_BUTTON
pressed.
Broadcast Action: External media is present, and
being disk-checked The path to the mount point for
ACTION_MEDIA_CHECKING
the checking media is contained in the
Intent.mData field.
Broadcast Action: User has expressed the desire to
ACTION_MEDIA_EJECT
remove the external storage media.
Broadcast Action: External media is present and
ACTION_MEDIA_MOUNTED
mounted at its mount point.
Broadcast Action: External media is present, but is
using an incompatible fs (or is blank) The path to
ACTION_MEDIA_NOFS
the mount point for the checking media is
contained in the Intent.mData field.
Broadcast Action: External media has been
ACTION_MEDIA_REMOVED
removed.
Broadcast Action: The media scanner has finished
ACTION_MEDIA_SCANNER_FINISHED
scanning a directory.
Broadcast Action: Request the media scanner to
ACTION_MEDIA_SCANNER_SCAN_FILE
scan a file and add it to the media database.

Broadcast Action: The media scanner has started
ACTION_MEDIA_SCANNER_STARTED
scanning a directory.
Broadcast Action: External media is unmounted
ACTION_MEDIA_SHARED
because it is being shared via USB mass storage.
Broadcast Action: External media is present but
ACTION_MEDIA_UNMOUNTABLE
cannot be mounted.
Broadcast Action: External media is present, but
ACTION_MEDIA_UNMOUNTED
not mounted at its mount point.
Broadcast Action: An outgoing call is about to be
ACTION_NEW_OUTGOING_CALL
placed.
Broadcast Action: A new application package has
ACTION_PACKAGE_ADDED
been installed on the device.
Broadcast Action: An existing application package
ACTION_PACKAGE_CHANGED
has been changed (eg a component has been
enabled or disabled.
Broadcast Action: The user has cleared the data of
a package. This should be preceded
by ACTION_PACKAGE_RESTARTED, after which
ACTION_PACKAGE_DATA_CLEARED
all of its persistent data is erased and this
broadcast sent. Note that the cleared package
does not receive this broadcast. The data contains
the name of the package.
Broadcast Action: An existing application package
has been removed from the device. The data
ACTION_PACKAGE_REMOVED
contains the name of the package. The package
that is being installed does not receive this Intent.
Broadcast Action: A new version of an application
ACTION_PACKAGE_REPLACED
package has been installed, replacing an existing
version that was previously installed.
Broadcast Action: The user has restarted a
package, and all of its processes have been killed.
All runtime state associated with it (processes,
ACTION_PACKAGE_RESTARTED
alarms, notifications, etc) should be removed. Note
that the restarted package does not receive this
broadcast. The data contains the name of the
package.
Broadcast Action: Some content providers have
parts of their namespace where they publish new
ACTION_PROVIDER_CHANGED
events or items that the user may be especially
interested in.
ACTION_SCREEN_OFF
Broadcast Action: Sent after the screen turns off.
ACTION_SCREEN_ON
Broadcast Action: Sent after the screen turns on.
Broadcast Action: A user ID has been removed
ACTION_UID_REMOVED
from the system.
Broadcast Action: The device has entered USB
ACTION_UMS_CONNECTED
Mass Storage mode.

Broadcast Action: The device has exited USB
ACTION_UMS_DISCONNECTED
Mass Storage mode.
Broadcast Action: Sent when the user is present
ACTION_USER_PRESENT
after device wakes up (eg when the keyguard is
gone).
Broadcast Action: The current system wallpaper
ACTION_WALLPAPER_CHANGED
has changed.
ACTION_TIME_CHANGED
Broadcast Action: The time was set.
ACTION_TIME_TICK
Broadcast Action: The current time has changed.
ACTION_TIMEZONE_CHANGED
Broadcast Action: The timezone has changed.
Broadcast Action: The charging state, or charge
ACTION_BATTERY_CHANGED
level of the battery has changed.
Broadcast Action: Indicates low battery condition
ACTION_BATTERY_LOW
on the device. This broadcast corresponds to the
"Low battery warning" system dialog.
Broadcast Action: Indicates the battery is now okay
after being low. This will be sent
ACTION_BATTERY_OKAY
after ACTION_BATTERY_LOW once the battery
has gone back up to an okay state.
Network State
Intent Action
Description
Broadcast intent action indicating that the
NETWORK_STATE_CHANGED_ACTION
state of Wi-Fi connectivity has changed.
Broadcast intent action indicating that the
RSSI_CHANGED_ACTION
RSSI (signal strength) has changed.
Broadcast intent action indicating that a
SUPPLICANT_STATE_CHANGED_ACTION
connection to the supplicant has been
established or lost.
Broadcast intent action indicating that Wi-Fi
WIFI_STATE_CHANGED_ACTION
has been enabled, disabled, enabling,
disabling, or unknown.
The network IDs of the configured networks
NETWORK_IDS_CHANGED_ACTION
could have changed.
Broadcast intent action indicating that the
ACTION_BACKGROUND_DATA_SETTING_CHANGED setting for background data usage has
changed values.
Broadcast intent indicating that a change in
CONNECTIVITY_ACTION
network connectivity has occurred.
Broadcast Action: The user has switched the
ACTION_AIRPLANE_MODE_CHANGED
phone into or out of Airplane Mode.

Appendix C: Future Considerations This appendix clarifies certain portions of this Android
1.6 Compatibility Definition, and in some cases discusses anticipated or planned changes intended for a
future version of the Android platform. This appendix is for informational and planning purposes only, and
is not part of the Compatibility Definition for Android 1.6.
1. Non-telephone Devices
Android 1.6 is intended exclusively for telephones; telephony functionality is not optional. Future versions
of the Android platform are expected to make telephony optional (and thus allow for non-phone Android
devices), but only phones are compatible with Android 1.6.
2. Bluetooth Compatibility
The Android 1.6 release of Android does not support Bluetooth APIs, so from a compatibility perspective
Bluetooth does not impose any considerations for this version of the platform. However, a future version
of Android will introduce Bluetooth APIs. At that point, supporting Bluetooth will become mandatory for
compatibility.
Consequently, we strongly recommend that Android 1.6 devices include Bluetooth, so that they will be
compatible with future versions of Android that require Bluetooth.
3. Required Hardware Components
All hardware components in Section 8 (including WiFi, magnetometer/compass, accelerometer, etc.) are
required and may not be omitted. Future versions of Android are expected to make some (but not all) of
these components optional, in tandem with corresponding tools for third-party developers to handle these
changes.
4. Sample Applications
The Compatibility Definition Document for a future version of Android will include a more extensive and
representative list of applications than the ones listed in Section 4, above. For Android 1.6, the
applications listed in Section 4 must be tested.
5. Touch Screens
Future versions of the Compatibility Definition may or may not allow for devices to omit touchscreens.
However, currently much of the Android framework implementation assumes the existence of a
touchscreen; omitting a touchscreen would break substantially all current third-party Android applications,
so in Android 1.6 a touchscreen is required for compatibility.

6. Performance
Future versions of CTS will also measure the CPU utilization and performance of the following
components of an implementation:
• 2D graphics
• 3D graphics
• Video playback
• Audio playback
• Bluetooth A2DP playback

تعریف سازگاری Android 1.6

Document Outline