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

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

1. معرفی

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

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

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

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

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

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

2. منابع
  • IETF RFC2119 سطوح مورد نیاز: http://www.ietf.org/rfc/rfc2119.txt
  • مروری بر برنامه سازگاری اندروید: http://source.android.com/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.1: http://source.android.com/docs/compatibility/2.1/versions .html
  • کلاس android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html
  • HTML5: http://www.whatwg.org/specs/web-apps/current-work/
  • مشخصات ماشین مجازی 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/ میمون
  • از چندین صفحه پشتیبانی می کند: 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
  • مرجع امنیت و مجوزهای اندروید: http://developer.android.com/guide/topics/security/security.html
  • بلوتوث API: http://developer.android.com/reference/android/bluetooth/package-summary.html

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

    3. نرم افزار

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

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

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

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

    3.2. سازگاری Soft API

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

    3.2.1. مجوزها

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

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

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

    نظرات پارامتر
    android.os.Build.VERSION.RELEASE نسخه سیستم Android در حال اجرا، در قالب قابل خواندن توسط انسان. این فیلد باید دارای یکی از مقادیر رشته تعریف شده در [ منابع، 7 ] باشد.
    android.os.Build.VERSION.SDK نسخه سیستم Android در حال اجرا، در قالبی که برای کد برنامه شخص ثالث قابل دسترسی است. برای Android 2.1، این فیلد باید دارای مقدار صحیح 7 باشد.
    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.1-update1/ERC77/3359:userdebug/test-keys
    اثر انگشت نباید دارای فاصله باشد. اگر سایر فیلدهای موجود در الگوی بالا دارای فاصله هستند، باید با نویسه زیرخط ASCII ("_") در اثر انگشت جایگزین شوند.
    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. سازگاری Intent

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

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

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

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

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

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

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

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

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

    3.2.3.2. Intent Overrides

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

    توجه: این بخش توسط Erratum EX6580 اصلاح شده است.

    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 (Logging اندروید)
    • حداقل پشتیبانی از 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. سازگاری Web API

    بسیاری از توسعه‌دهندگان و برنامه‌های کاربردی برای رابط‌های کاربری خود به رفتار کلاس android.webkit.WebView [ Resources, 8 ] تکیه می‌کنند، بنابراین پیاده‌سازی WebView باید با پیاده‌سازی‌های Android سازگار باشد. پیاده سازی متن باز اندروید از موتور رندر WebKit برای پیاده سازی WebView استفاده می کند.

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

    • WebView باید از بیلد 530.17 WebKit از درخت متن باز Android بالادستی برای Android 2.1 استفاده کند. این ساخت شامل مجموعه خاصی از عملکردها و اصلاحات امنیتی برای WebView است.
    • رشته عامل کاربر گزارش شده توسط WebView باید در این قالب باشد:
      Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17
      • مقدار رشته $(VERSION) باید با مقدار android.os.Build.VERSION.RELEASE یکسان باشد
      • . از دستگاه
      • مقدار رشته $(MODEL) باید با مقدار android.os.Build.MODEL یکسان باشد
      • مقدار رشته $(BUILD) باید با مقدار android.os.Build.ID
    پیاده سازی
      • android.os.Build.ID

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

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

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

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

    • دستگاه‌ها
    • نباید رفتار یا معنای یک Intent استاندارد را تغییر دهند
    • .
    • تغییر معنای یک مجوز خاص

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

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

    3.6. API Namespaces

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

    • java.*
    • javax.*
    • sun.*
    • android.*
    • com.android.*

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

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

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

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

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

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

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

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

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

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

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

    3.8.1. ابزارک‌ها

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

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

    3.8.2. اعلان‌ها

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

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

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

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

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

    3.8.4. Toasts

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

    3.8.5. Live Wallpapers

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

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

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

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

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

    • ماشین حساب (شامل در SDK)
    • Lunar Lander (شامل در SDK)
    • برنامه های "برنامه های اندروید" [ منابع، 18 ].

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

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

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

    هر مورد آزمایشی در برنامه‌های بالا باید به درستی روی دستگاه اجرا شود. پیاده سازی.

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

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

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

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

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

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

    رمزگذار نام محتوای 9 از 6.60 کیلوبیت بر ثانیه تا 23.85 کیلوبیت بر ثانیه نمونه برداری شده @ 16 کیلوهرتز
    صوتی
    جزئیات رسیور فرمت فایل /کانتینر
    AAC LC/LTP  X Mono/Stereo در هر ترکیبی از نرخ بیت استاندارد تا 160 کیلوبیت بر ثانیه و نرخ نمونه برداری بین 8 تا 48 کیلوهرتز 3GPP (.3gp) و MPEG-4 (.mp4، 0.m4a). بدون پشتیبانی از AAC خام (.aac)
    HE-AACv1 (AAC+)   X
    HE-AACv2 (AAC+ پیشرفته)   X
    AMR-NB X X 4.75 تا 12.2 کیلوبیت بر ثانیه نمونه برداری شده @ 8kHz 3GPP (.3gp)
    AMR-WB   نرخ X3GPP (.3gp)
    MP3   X Mono/Stereo 8-320Kbps ثابت (CBR) یا نرخ بیت متغیر (VBR) MP3 (.mp3)
    MIDI   X 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 vorbis   ایکس   Ogg (.ogg)
    PCM   X 8- و 16 بیتی خطی PCM (نرخ تا حد سخت افزاری) موج (.WAV)
    تصویر
    JPEG X X Base+Progressive  
    GIF   ایکس   
    png x x   
    BMP   ایکس   
    ویدیوی
    H.263 X X   پرونده های 3gpp (.3gp)
    H.264   ایکس   پرونده های 3GPP (.3GP) و MPEG-4 (.mp4)
    پروفایل ساده MPEG4   ایکس   پرونده 3GPP (.3GP)

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

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

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

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

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

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

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

    • تعاریف کلاس برای API های مؤلفه باید
    • رفتارهای API را ارائه دهد ، باید در برخی از موارد معقول و منطقی اجرا شود.
    • روشهای API باید مقادیر تهی را در جایی که توسط مستندات SDK
    • API مجاز است ، برگرداند و باید اجرای No-Op از کلاس ها را برگرداند که مقادیر تهی توسط مستندات SDK

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

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

    8.1. نمایش

    Android 2.1 شامل امکاناتی است که تحت برخی شرایط عملیات مقیاس بندی و تحول اتوماتیک را انجام می دهد تا اطمینان حاصل شود که برنامه های شخص ثالث به طور منطقی در انواع تنظیمات سخت افزاری اجرا می شوند [ منابع ، 23 ]. دستگاه ها باید این رفتارها را به درستی اجرا کنند ، همانطور که در این بخش شرح داده شده است.

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

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

    بزرگ مربوط به یکی از تنظیمات استاندارد فوق باید پیکربندی شود تا اندازه صفحه نمایش نشان داده شده از طریق android.content.res.Configuration [ منابع ، 24 ] را گزارش کند.

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

    • اجرای دستگاه باید منابع را در یک .APK که فاقد صلاحیت چگالی هستند به عنوان پیش فرض "متوسط" (معروف به "MDPI" در مستندات SDK) تفسیر کنند
    • . صفحه نمایش ، اجرای دستگاه باید دارایی های متوسط/MDPI را با ضریب 0.75 کاهش دهد.
    • هنگام کار بر روی صفحه چگالی "بالا" ، پیاده سازی دستگاه باید دارایی های متوسط/MDPI را با ضریب 1.5 مقیاس کند.
    • اجرای دستگاه نباید دارایی های مقیاس را در محدوده چگالی مقیاس کند و دقیقاً باید دارایی ها را با این عوامل بین محدوده چگالی مقیاس کند.

    8.1.2. تنظیمات نمایشگر غیر استاندارد

    پیکربندی هایی را نشان می دهد که با یکی از تنظیمات استاندارد ذکر شده در بخش 8.1.1 مطابقت ندارد. مجریان دستگاه باید با تیم سازگاری Android همانطور که در بخش 12 پیش بینی شده است تماس بگیرند تا طبقه بندی برای سطل اندازه صفحه ، تراکم و ضریب مقیاس گذاری به دست آورند. در صورت ارائه این اطلاعات ، اجرای دستگاه باید آنها را مطابق آنچه مشخص شده است پیاده سازی کند.

    توجه داشته باشید که برخی از تنظیمات نمایشگر (مانند صفحه های بسیار بزرگ یا بسیار کوچک و برخی نسبت های ابعاد) اساساً با Android 2.1 ناسازگار هستند. بنابراین به مجریان دستگاه تشویق می شوند تا در اسرع وقت در فرآیند توسعه با تیم سازگاری اندروید تماس بگیرند.

    8.1.3.

    نمایشگر دستگاه های

    نمایشگر

    باید مقادیر صحیح را برای کلیه معیارهای نمایشگر تعریف شده در android.util.DisplayMetrics [ منابع ، 25 ] گزارش دهد.

    8.2.

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

    صفحه کلید

    :

    • باید شامل پشتیبانی از چارچوب مدیریت ورودی (که به توسعه دهندگان شخص ثالث اجازه می دهد موتورهای مدیریت ورودی ایجاد کنند - یعنی صفحه کلید نرم) همانطور که در Developer.android.com
    • باید حداقل یک اجرای صفحه کلید نرم را ارائه دهد (صرف نظر از این صفحه کلید سخت وجود دارد)
    • ممکن است شامل پیاده سازی های اضافی صفحه کلید نرم
    • ممکن است شامل یک صفحه کلید سخت افزاری
    • نباشد که نباید شامل یک صفحه کلید سخت افزاری باشد که با یکی از فرمت های مشخص شده در android.content.res.Configuration.keyboard [ منابع ، 24 ] مطابقت نداشته باشد (یعنی ، 24] Qwerty ، یا 12-key)

    8.3.

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

    ناوبری غیر لمسی

    :

    • ممکن است گزینه های ناوبری غیر لمسی (یعنی ممکن است یک پیست ، D-PAD یا چرخ را حذف کند)
    • باید مقدار صحیح را برای android.content.res.Configuration.navigation گزارش کند [ منابع ، 24 ]

    8.4.

    دستگاه های سازگار

    با جهت گیری صفحه نمایش

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

    دستگاه ها باید هر زمان که از طریق Android.content.res.configuration.orientation ، android.view.display.getorientation () یا سایر API ها پرس و جو شوند ، مقدار صحیح را برای جهت گیری فعلی دستگاه گزارش دهند.

    8.5.

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

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

    :

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

    8.6 است.

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

    USB

    :

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

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

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

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

    8.8.

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

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

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

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

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

    8.9.

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

    دوربین

    باید شامل یک دوربین باشد. دوربین شامل:

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

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

    1. اگر یک برنامه هرگز Android.hardware.camera.parameters.setPreviewFormat (int) را نامیده نشده است ، سپس دستگاه باید از Android.hardware.pixelformat.ycbcr_420_sp برای داده های پیش نمایش ارائه شده استفاده کند. تماسهای برگشتی برنامه.
    2. اگر یک برنامه یک Android.Hardware.Camera.PreviewCallback را ثبت کند و سیستم روش OnPreviewFrame () را فراخوانی می کند وقتی که فرمت پیش نمایش YCBCR_420_SP است ، داده های موجود در Byte [] به OnPreviewFrame منتقل می شود () باید بیشتر در قالب رمزگذاری NV21 باشد. (این فرمی است که به طور بومی توسط خانواده سخت افزار 7K استفاده می شود.) یعنی NV21 باید پیش فرض باشد.

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

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

    8.10.

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

    شتاب سنج

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

    8.11.

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

    قطب نما

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

    8.12.

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

    GPS

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

    8.13. تلفن

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

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

    8.14.

    اجرای دستگاه

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

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

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

    توجه: این بخش توسط Erratum ex6580 اصلاح شده است.

    8.15.

    برنامه های

    کاربردی مشترک

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

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

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

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

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

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

    . : این بخش توسط Erratum ex6580 اضافه شد.

    8.16.

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

    بلوتوث

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

    توجه: این بخش توسط Erratum ex6580 اضافه شده است.

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

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

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

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

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

    10.1.

    اجرای دستگاه

    مجوزها

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

    10.2.

    اجرای دستگاه های

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

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

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

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

    11. سازگاری دستگاه تست سازگاری

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

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

    12.

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

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

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

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

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

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

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