Penggunaan "harus", "tidak boleh", "wajib", "harus", "tidak boleh", "seharusnya", "tidak boleh", "direkomendasikan", "boleh" dan "opsional" sesuai dengan standar IETF didefinisikan dalam RFC2119 [ Sumber Daya, 1 ].

Seperti yang digunakan dalam dokumen ini, "implementer perangkat" atau "implementer" adalah orang atau organisasi yang mengembangkan solusi perangkat keras/perangkat lunak yang menjalankan Android 4.2. Sebuah "implementasi perangkat" atau "implementasi" adalah solusi perangkat keras/perangkat lunak yang dikembangkan.

Agar dianggap kompatibel dengan Android 4.2, implementasi perangkat HARUS memenuhi persyaratan yang disajikan dalam Definisi Kompatibilitas ini, termasuk dokumen apa pun yang digabungkan melalui referensi.

Apabila definisi ini atau pengujian perangkat lunak yang dijelaskan dalam Bagian 10 tidak jelas, ambigu, atau tidak lengkap, maka merupakan tanggung jawab pelaksana perangkat untuk memastikan kompatibilitas dengan implementasi yang ada.

Karena alasan ini, Proyek Sumber Terbuka Android [ Sumber Daya, 3 ] merupakan referensi dan implementasi Android yang disukai. Implementer perangkat sangat dianjurkan untuk mendasarkan implementasi mereka semaksimal mungkin pada kode sumber "upstream" yang tersedia dari Proyek Sumber Terbuka Android. Meskipun beberapa komponen secara hipotetis dapat diganti dengan implementasi alternatif, praktik ini sangat tidak disarankan, karena lulus pengujian perangkat lunak akan menjadi jauh lebih sulit. Implementer bertanggung jawab untuk memastikan kompatibilitas penuh perilaku dengan implementasi Android standar, termasuk dan di luar Compatibility Test Suite. Terakhir, perhatikan bahwa penggantian dan modifikasi komponen tertentu secara eksplisit dilarang oleh dokumen ini.

2. Sumber Daya

Tingkat Persyaratan IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt

Ikhtisar Program Kompatibilitas Android: http://source.android.com/docs/compatibility/index.html

Proyek Sumber Terbuka Android: http://source.android.com/

Definisi dan dokumentasi API: http://developer.android.com/reference/packages.html

Referensi Izin Android: http://developer.android.com/reference/android/Manifest.permission.html

referensi android.os.Build: http://developer.android.com/reference/android/os/Build.html

String versi yang diizinkan Android 4.2: http://source.android.com/docs/compatibility/4.2/versions.html

Skrip Render: http://developer.android.com/guide/topics/graphics/renderscript.html

Akselerasi Perangkat Keras: http://developer.android.com/guide/topics/graphics/hardware-accel.html

kelas android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html

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

Kemampuan offline HTML5: http://dev.w3.org/html5/spec/Overview.html#offline

Label video HTML5: http://dev.w3.org/html5/spec/Overview.html#video

API geolokasi HTML5/W3C: http://www.w3.org/TR/geolocation-API/

API basis data web HTML5/W3C: http://www.w3.org/TR/webdatabase/

API IndexedDB HTML5/W3C: http://www.w3.org/TR/IndexedDB/

Spesifikasi Mesin Virtual Dalvik: tersedia dalam kode sumber Android, di dalvik/docs

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

Pemberitahuan: http://developer.android.com/guide/topics/ui/notifiers/notifications.html

Sumber Daya Aplikasi: http://code.google.com/android/reference/available-resources.html

Panduan gaya ikon Bilah Status: http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html

Manajer Pencarian: http://developer.android.com/reference/android/app/SearchManager.html

Bersulang: http://developer.android.com/reference/android/widget/Toast.html

Tema: http://developer.android.com/guide/topics/ui/themes.html

Kelas R.style: http://developer.android.com/reference/android/R.style.html

Wallpaper Animasi: https://android-developers.googleblog.com/2010/02/live-wallpapers.html

Administrasi Perangkat Android: http://developer.android.com/guide/topics/admin/device-admin.html

Referensi DevicePolicyManager: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html

API Layanan Aksesibilitas Android: http://developer.android.com/reference/android/accessibilityservice/package-summary.html

API Aksesibilitas Android: http://developer.android.com/reference/android/view/accessibility/package-summary.html

Proyek Mata Gratis: http://code.google.com/p/eyes-free

API Text-To-Speech: http://developer.android.com/reference/android/speech/tts/package-summary.html

Dokumentasi alat referensi (untuk adb, aapt, ddms, systrace): http://developer.android.com/guide/developing/tools/index.html

Deskripsi file apk Android: http://developer.android.com/guide/topics/fundamentals.html

File manifes: http://developer.android.com/guide/topics/manifest/manifest-intro.html

Alat pengujian monyet: https://developer.android.com/studio/test/other-testing-tools/monkey

Kelas Android android.content.pm.PackageManager dan Daftar Fitur Perangkat Keras: http://developer.android.com/reference/android/content/pm/PackageManager.html

Mendukung Banyak Layar: http://developer.android.com/guide/practices/screens_support.html

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

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

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

API Bluetooth: http://developer.android.com/reference/android/bluetooth/package-summary.html

Protokol Dorong NDEF: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf

MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf

MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf

MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf

MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf

MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf

MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf

API orientasi kamera: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)

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

Aksesori Terbuka Android: http://developer.android.com/guide/topics/usb/accessory.html

API Host USB: http://developer.android.com/guide/topics/usb/host.html

Referensi Keamanan dan Izin Android: http://developer.android.com/guide/topics/security/security.html

Aplikasi untuk Android: http://code.google.com/p/apps-for-android

Pengelola Unduhan Android: http://developer.android.com/reference/android/app/DownloadManager.html

Transfer File Android: http://www.android.com/filetransfer

Format Media Android: http://developer.android.com/guide/appendix/media-formats.html

Protokol Draf Streaming Langsung HTTP: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03

Penyerahan Koneksi NFC: http://www.nfc-forum.org/specs/spec_list/#conn_handover

Pemasangan Sederhana Aman Bluetooth Menggunakan NFC: http://www.nfc-forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf

Wifi Multicast API: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html

Bantuan Tindakan: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST

Spesifikasi Pengisian USB: http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf

Android Beam: http://developer.android.com/guide/topics/nfc/nfc.html

Audio USB Android: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO

Setelan Berbagi NFC Android: http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS

Wifi Langsung (Wifi P2P): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html

Kunci dan Widget Layar Beranda: http://developer.android.com/reference/android/appwidget/AppWidgetProviderInfo.html

Referensi UserManager: http://developer.android.com/reference/android/os/UserManager.html

Referensi Penyimpanan Eksternal: https://source.android.com/docs/core/storage

API Penyimpanan Eksternal: http://developer.android.com/reference/android/os/Environment.html

Kode Pendek SMS: http://en.wikipedia.org/wiki/Short_code

Klien Kontrol Jarak Jauh Media: http://developer.android.com/reference/android/media/RemoteControlClient.html

Manajer Tampilan: http://developer.android.com/reference/android/hardware/display/DisplayManager.html

Mimpi: http://developer.android.com/reference/android/service/dreams/DreamService.html

Pengaturan Terkait Pengembangan Aplikasi Android: http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS

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

Banyak dari sumber daya ini yang diturunkan secara langsung atau tidak langsung dari Android 4.2 SDK, dan secara fungsional akan identik dengan informasi dalam dokumentasi SDK tersebut. Jika Definisi Kompatibilitas atau Rangkaian Uji Kompatibilitas ini tidak sesuai dengan dokumentasi SDK, dokumentasi SDK dianggap resmi. Detail teknis apa pun yang diberikan dalam referensi yang disertakan di atas dianggap sebagai bagian dari Definisi Kompatibilitas ini.

3. Perangkat Lunak

3.1. Kompatibilitas API Terkelola

Lingkungan eksekusi terkelola (berbasis Dalvik) adalah sarana utama untuk aplikasi Android. Antarmuka pemrograman aplikasi (API) Android adalah kumpulan antarmuka platform Android yang diekspos ke aplikasi yang berjalan di lingkungan VM terkelola. Implementasi perangkat HARUS menyediakan implementasi lengkap, termasuk semua perilaku yang terdokumentasi, dari setiap API terdokumentasi yang diekspos oleh Android 4.2 SDK [ Sumber Daya, 4 ].

Implementasi perangkat TIDAK BOLEH menghilangkan API terkelola apa pun, mengubah antarmuka atau tanda tangan API, menyimpang dari perilaku yang terdokumentasi, atau menyertakan larangan pengoperasian, kecuali jika diizinkan secara khusus oleh Definisi Kompatibilitas ini.

Definisi Kompatibilitas ini mengizinkan beberapa jenis perangkat keras yang Android menyertakan API untuk dihilangkan oleh implementasi perangkat. Dalam kasus seperti ini, API HARUS tetap ada dan berperilaku wajar. Lihat Bagian 7 untuk persyaratan khusus untuk skenario ini.

3.2. Kompatibilitas API Lunak

Selain API terkelola dari Bagian 3.1, Android juga menyertakan API "lunak" khusus runtime yang signifikan, dalam bentuk seperti Intent, izin, dan aspek serupa dari aplikasi Android yang tidak dapat diterapkan pada waktu kompilasi aplikasi.

3.2.1. Izin

Pelaksana perangkat HARUS mendukung dan menegakkan semua konstanta izin seperti yang didokumentasikan oleh halaman referensi Izin [ Sumber Daya, 5 ]. Perhatikan bahwa Bagian 10 mencantumkan persyaratan tambahan terkait model keamanan Android.

3.2.2. Parameter Bangun

Android API menyertakan sejumlah konstanta pada kelas android.os.Build [ Resources, 6 ] yang dimaksudkan untuk mendeskripsikan perangkat saat ini. Untuk memberikan nilai yang konsisten dan bermakna di seluruh penerapan perangkat, tabel di bawah menyertakan batasan tambahan pada format nilai yang HARUS dipatuhi oleh penerapan perangkat.

Parameter	Komentar
android.os.Build.VERSION.RELEASE	Versi sistem Android yang sedang dijalankan, dalam format yang dapat dibaca manusia. Bidang ini HARUS memiliki salah satu nilai string yang ditentukan di [ Sumber Daya, 7 ].
android.os.Build.VERSION.SDK	Versi sistem Android yang sedang dijalankan, dalam format yang dapat diakses oleh kode aplikasi pihak ketiga. Untuk Android 4.2, kolom ini HARUS memiliki nilai integer 17.
android.os.Build.VERSION.SDK_INT	Versi sistem Android yang sedang dijalankan, dalam format yang dapat diakses oleh kode aplikasi pihak ketiga. Untuk Android 4.2, kolom ini HARUS memiliki nilai integer 17.
android.os.Build.VERSION.INCREMENTAL	Nilai yang dipilih oleh pelaksana perangkat yang menunjuk build spesifik sistem Android yang sedang dijalankan, dalam format yang dapat dibaca manusia. Nilai ini TIDAK BOLEH digunakan kembali untuk build berbeda yang tersedia untuk pengguna akhir. Penggunaan umum bidang ini adalah untuk menunjukkan nomor build atau pengidentifikasi perubahan kontrol sumber mana yang digunakan untuk menghasilkan build. Tidak ada persyaratan mengenai format spesifik bidang ini, kecuali TIDAK HARUS berupa null atau string kosong ("").
android.os.Build.BOARD	Nilai yang dipilih oleh pelaksana perangkat yang mengidentifikasi perangkat keras internal spesifik yang digunakan oleh perangkat, dalam format yang dapat dibaca manusia. Kemungkinan penggunaan bidang ini adalah untuk menunjukkan revisi spesifik pada papan yang memberi daya pada perangkat. Nilai bidang ini HARUS dapat dikodekan sebagai ASCII 7-bit dan cocok dengan ekspresi reguler `"^[a-zA-Z0-9.,_-]+$"` .
android.os.Build.MEREK	Nilai yang dipilih oleh pelaksana perangkat yang mengidentifikasi nama perusahaan, organisasi, individu, dll. yang memproduksi perangkat, dalam format yang dapat dibaca manusia. Kemungkinan penggunaan bidang ini adalah untuk menunjukkan OEM dan/atau operator yang menjual perangkat. Nilai bidang ini HARUS dapat dikodekan sebagai ASCII 7-bit dan cocok dengan ekspresi reguler `"^[a-zA-Z0-9.,_-]+$"` .
android.os.Build.CPU_ABI	Nama set instruksi (tipe CPU + konvensi ABI) dari kode asli. Lihat Bagian 3.3: Kompatibilitas API Asli .
android.os.Build.CPU_ABI2	Nama set instruksi kedua (tipe CPU + konvensi ABI) dari kode asli. Lihat Bagian 3.3: Kompatibilitas API Asli .
android.os.Build.DEVICE	Nilai yang dipilih oleh pelaksana perangkat yang mengidentifikasi konfigurasi spesifik atau revisi bodi (terkadang disebut "desain industri") perangkat. Nilai bidang ini HARUS dapat dikodekan sebagai ASCII 7-bit dan cocok dengan ekspresi reguler `"^[a-zA-Z0-9.,_-]+$"` .
android.os.Build.FINGERPRINT	Sebuah string yang secara unik mengidentifikasi bangunan ini. Itu HARUS dapat dibaca manusia secara wajar. Itu HARUS mengikuti templat ini: `$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)` Misalnya: `acme/mydevice/generic:4.2/JRN53/3359:userdebug/test-keys` Sidik jari TIDAK HARUS menyertakan karakter spasi. Jika kolom lain yang disertakan dalam template di atas memiliki karakter spasi, maka kolom tersebut HARUS diganti di sidik jari build dengan karakter lain, misalnya karakter garis bawah ("_"). Nilai bidang ini HARUS dapat dikodekan sebagai ASCII 7-bit.
android.os.Build.PERANGKAT KERAS	Nama perangkat keras (dari baris perintah kernel atau /proc). Itu HARUS dapat dibaca manusia secara wajar. Nilai bidang ini HARUS dapat dikodekan sebagai ASCII 7-bit dan cocok dengan ekspresi reguler `"^[a-zA-Z0-9.,_-]+$"` .
android.os.Build.HOST	Sebuah string yang secara unik mengidentifikasi host tempat build dibangun, dalam format yang dapat dibaca manusia. Tidak ada persyaratan mengenai format spesifik bidang ini, kecuali TIDAK HARUS berupa null atau string kosong ("").
android.os.Build.ID	Pengidentifikasi yang dipilih oleh pelaksana perangkat untuk merujuk pada rilis tertentu, dalam format yang dapat dibaca manusia. Kolom ini bisa sama dengan android.os.Build.VERSION.INCREMENTAL, namun HARUS berupa nilai yang cukup bermakna bagi pengguna akhir untuk membedakan build perangkat lunak. Nilai bidang ini HARUS dapat dikodekan sebagai ASCII 7-bit dan cocok dengan ekspresi reguler `"^[a-zA-Z0-9.,_-]+$"` .
android.os.Build.MANUFACTURER	Nama dagang Produsen Peralatan Asli (OEM) produk. Tidak ada persyaratan mengenai format spesifik bidang ini, kecuali TIDAK HARUS berupa null atau string kosong ("").
android.os.Build.MODEL	Nilai yang dipilih oleh pelaksana perangkat yang berisi nama perangkat yang diketahui oleh pengguna akhir. Nama ini HARUS sama dengan nama perangkat yang dipasarkan dan dijual kepada pengguna akhir. Tidak ada persyaratan mengenai format spesifik bidang ini, kecuali TIDAK HARUS berupa null atau string kosong ("").
android.os.Build.PRODUK	Nilai yang dipilih oleh pelaksana perangkat yang berisi nama pengembangan atau nama kode produk (SKU). HARUS dapat dibaca manusia, namun tidak dimaksudkan untuk dilihat oleh pengguna akhir. Nilai bidang ini HARUS dapat dikodekan sebagai ASCII 7-bit dan cocok dengan ekspresi reguler `"^[a-zA-Z0-9.,_-]+$"` .
android.os.Build.SERIAL	Nomor seri perangkat keras, jika tersedia. Nilai bidang ini HARUS dapat dikodekan sebagai ASCII 7-bit dan cocok dengan ekspresi reguler `"^([a-zA-Z0-9]{0,20})$"` .
android.os.Build.TAGS	Daftar tag yang dipisahkan koma yang dipilih oleh pelaksana perangkat yang selanjutnya membedakan build. Misalnya, "tidak ditandatangani,debug". Nilai bidang ini HARUS dapat dikodekan sebagai ASCII 7-bit dan cocok dengan ekspresi reguler `"^[a-zA-Z0-9.,_-]+$"` .
android.os.Build.TIME	Nilai yang mewakili stempel waktu saat pembangunan terjadi.
android.os.Build.TYPE	Nilai yang dipilih oleh pelaksana perangkat yang menentukan konfigurasi runtime build. Bidang ini HARUS memiliki salah satu nilai yang sesuai dengan tiga konfigurasi runtime Android pada umumnya: "user", "userdebug", atau "eng". Nilai bidang ini HARUS dapat dikodekan sebagai ASCII 7-bit dan cocok dengan ekspresi reguler `"^[a-zA-Z0-9.,_-]+$"` .
android.os.Build.USER	Nama atau ID pengguna dari pengguna (atau pengguna otomatis) yang menghasilkan build. Tidak ada persyaratan mengenai format spesifik bidang ini, kecuali TIDAK HARUS berupa null atau string kosong ("").

3.2.3. Kompatibilitas Maksud

Implementasi perangkat HARUS mengikuti sistem Intent yang terhubung secara longgar, seperti yang dijelaskan pada bagian di bawah ini. Yang dimaksud dengan "dihormati" adalah bahwa pelaksana perangkat HARUS menyediakan Aktivitas atau Layanan Android yang menentukan filter Intent yang cocok dan mengikat serta mengimplementasikan perilaku yang benar untuk setiap pola Intent yang ditentukan.

3.2.3.1. Maksud Aplikasi Inti

Proyek upstream Android mendefinisikan sejumlah aplikasi inti, seperti kontak, kalender, galeri foto, pemutar musik, dan sebagainya. Pelaksana perangkat DAPAT mengganti aplikasi ini dengan versi alternatif.

Namun, versi alternatif tersebut HARUS mengikuti pola Intent yang sama yang disediakan oleh proyek hulu. Misalnya, jika perangkat berisi pemutar musik alternatif, perangkat tersebut tetap harus mengikuti pola Intent yang dikeluarkan oleh aplikasi pihak ketiga untuk memilih lagu.

Aplikasi berikut ini dianggap sebagai aplikasi inti sistem Android:

Jam Meja
Peramban
Kalender
Kontak
Galeri
Pencarian Global
Peluncur
Musik
Pengaturan

Aplikasi inti sistem Android mencakup berbagai komponen Aktivitas atau Layanan yang dianggap "publik". Artinya, atribut "android:exported" mungkin tidak ada, atau mungkin memiliki nilai "true".

Untuk setiap Aktivitas atau Layanan yang ditentukan di salah satu aplikasi sistem Android inti yang tidak ditandai sebagai non-publik melalui atribut android:exported dengan nilai "false", implementasi perangkat HARUS menyertakan komponen bertipe sama yang mengimplementasikan filter Intent yang sama pola sebagai aplikasi sistem Android inti.

Dengan kata lain, implementasi perangkat MUNGKIN menggantikan aplikasi inti sistem Android; namun, jika ya, penerapan perangkat HARUS mendukung semua pola Intent yang ditentukan oleh setiap aplikasi sistem Android inti yang diganti.

3.2.3.2. Penggantian Niat

Karena Android adalah platform yang dapat diperluas, implementasi perangkat HARUS mengizinkan setiap pola Intent yang dirujuk di Bagian 3.2.3.2 diganti oleh aplikasi pihak ketiga. Implementasi open source Android upstream mengizinkan hal ini secara default; pelaksana perangkat TIDAK BOLEH memberikan hak istimewa khusus pada penggunaan pola Intent ini oleh aplikasi sistem, atau mencegah aplikasi pihak ketiga mengikat dan mengambil kendali atas pola ini. Larangan ini secara khusus mencakup namun tidak terbatas pada menonaktifkan antarmuka pengguna "Chooser" yang memungkinkan pengguna memilih di antara beberapa aplikasi yang semuanya menangani pola Intent yang sama.

Namun, penerapan perangkat MUNGKIN menyediakan aktivitas default untuk pola URI tertentu (misalnya http://play.google.com) jika aktivitas default menyediakan filter yang lebih spesifik untuk URI data. Misalnya, filter maksud yang menentukan URI data "http://www.android.com" lebih spesifik dibandingkan filter browser untuk "http://". Implementasi perangkat HARUS menyediakan antarmuka pengguna bagi pengguna untuk mengubah aktivitas default untuk maksud.

3.2.3.3. Ruang Nama Maksud

Implementasi perangkat TIDAK BOLEH menyertakan komponen Android apa pun yang mengikuti pola Intent atau Intent Siaran baru menggunakan ACTION, CATEGORY, atau string kunci lainnya di namespace android.* atau com.android.*. Implementer perangkat TIDAK BOLEH menyertakan komponen Android apa pun yang mengikuti pola Intent atau Intent Siaran baru menggunakan ACTION, CATEGORY, atau string kunci lainnya dalam ruang paket milik organisasi lain. Pelaksana perangkat TIDAK BOLEH mengubah atau memperluas pola Intent apa pun yang digunakan oleh aplikasi inti yang tercantum di Bagian 3.2.3.1. Implementasi perangkat MUNGKIN menyertakan pola Intent yang menggunakan namespace yang jelas dan jelas terkait dengan organisasinya sendiri.

Larangan ini serupa dengan yang ditentukan untuk kelas bahasa Java di Bagian 3.6.

3.2.3.4. Maksud Siaran

Aplikasi pihak ketiga mengandalkan platform untuk menyiarkan Intent tertentu guna memberi tahu mereka tentang perubahan dalam lingkungan perangkat keras atau perangkat lunak. Perangkat yang kompatibel dengan Android HARUS menyiarkan Intent siaran publik sebagai respons terhadap kejadian sistem yang sesuai. Intent Siaran dijelaskan dalam dokumentasi SDK.

3.3. Kompatibilitas API Asli

3.3.1 Antarmuka Biner Aplikasi

Kode terkelola yang berjalan di Dalvik dapat memanggil kode asli yang disediakan dalam file .apk aplikasi sebagai file ELF .so yang dikompilasi untuk arsitektur perangkat keras perangkat yang sesuai. Karena kode asli sangat bergantung pada teknologi prosesor yang mendasarinya, Android mendefinisikan sejumlah Antarmuka Biner Aplikasi (ABI) di Android NDK, dalam file docs/CPU-ARCH-ABIS.html . Jika implementasi perangkat kompatibel dengan satu atau beberapa ABI yang ditentukan, implementasi tersebut HARUS mengimplementasikan kompatibilitas dengan Android NDK, seperti di bawah ini.

Jika implementasi perangkat menyertakan dukungan untuk Android ABI, maka:

HARUS menyertakan dukungan untuk kode yang berjalan di lingkungan terkelola untuk memanggil kode asli, menggunakan semantik Java Native Interface (JNI) standar.
HARUS kompatibel dengan sumber (yaitu kompatibel dengan header) dan kompatibel dengan biner (untuk ABI) dengan setiap pustaka yang diperlukan dalam daftar di bawah
HARUS melaporkan secara akurat Application Binary Interface (ABI) asli yang didukung oleh perangkat, melalui android.os.Build.CPU_ABI API
HARUS melaporkan hanya ABI yang didokumentasikan dalam versi terbaru Android NDK, dalam file docs/CPU-ARCH-ABIS.txt
HARUS dibuat menggunakan kode sumber dan file header yang tersedia di proyek sumber terbuka Android hulu

API kode asli berikut HARUS tersedia untuk aplikasi yang menyertakan kode asli:

libc (perpustakaan C)
libm (perpustakaan matematika)
Dukungan minimal untuk C++
antarmuka JNI
liblog (pencatatan Android)
libz (kompresi Zlib)
libdl (penghubung dinamis)
libGLESv1_CM.so (OpenGL ES 1.0)
libGLESv2.so (OpenGL ES 2.0)
libEGL.so (manajemen permukaan OpenGL asli)
libjnigraphics.so
libOpenSLES.so (dukungan audio OpenSL ES 1.0.1)
libOpenMAXAL.so (dukungan OpenMAX AL 1.0.1)
libandroid.so (dukungan aktivitas Android asli)
Dukungan untuk OpenGL, seperti dijelaskan di bawah

Perlu diperhatikan bahwa rilis Android NDK di masa mendatang mungkin memperkenalkan dukungan untuk ABI tambahan. Jika implementasi perangkat tidak kompatibel dengan ABI yang telah ditentukan sebelumnya, maka implementasi tersebut TIDAK HARUS melaporkan dukungan untuk ABI apa pun sama sekali.

Kompatibilitas kode asli merupakan suatu tantangan. Oleh karena itu, harus diulangi bahwa pelaksana perangkat SANGAT dianjurkan untuk menggunakan implementasi hulu dari perpustakaan yang tercantum di atas untuk membantu memastikan kompatibilitas.

3.4. Kompatibilitas Web

3.4.1. Kompatibilitas Tampilan Web

Implementasi Android Open Source menggunakan mesin rendering WebKit untuk mengimplementasikan android.webkit.WebView . Karena tidak layak untuk mengembangkan rangkaian pengujian komprehensif untuk sistem rendering web, pelaksana perangkat HARUS menggunakan versi hulu WebKit yang spesifik dalam implementasi WebView. Secara khusus:

Implementasi android.webkit.WebView implementasi perangkat HARUS didasarkan pada build WebKit 534.30 dari pohon Sumber Terbuka Android upstream untuk Android 4.2. Versi ini mencakup serangkaian fungsionalitas dan perbaikan keamanan khusus untuk WebView. Pelaksana perangkat MUNGKIN menyertakan penyesuaian pada implementasi WebKit; namun, penyesuaian apa pun TIDAK BOLEH mengubah perilaku WebView, termasuk perilaku rendering.
String agen pengguna yang dilaporkan oleh WebView HARUS dalam format ini:
Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.2 Mobile Safari/534.30
- Nilai string $(VERSION) HARUS sama dengan nilai untuk android.os.Build.VERSION.RELEASE
- Nilai string $(LOCALE) HARUS mengikuti konvensi ISO untuk kode negara dan bahasa, dan HARUS mengacu pada konfigurasi lokal perangkat saat ini
- Nilai string $(MODEL) HARUS sama dengan nilai untuk android.os.Build.MODEL
- Nilai string $(BUILD) HARUS sama dengan nilai untuk android.os.Build.ID
- Implementasi perangkat MUNGKIN menghilangkan Mobile dalam string agen pengguna

Komponen WebView HARUS menyertakan dukungan untuk HTML5 sebanyak mungkin [ Sumber Daya, 11 ]. Minimal, implementasi perangkat HARUS mendukung setiap API yang terkait dengan HTML5 di WebView:

cache aplikasi/operasi offline [ Sumber Daya, 12 ]
tag <video> [ Sumber Daya, 13 ]
geolokasi [ Sumber Daya, 14 ]

Selain itu, implementasi perangkat HARUS mendukung API penyimpanan web HTML5/W3C [ Sumber Daya, 15 ], dan HARUS mendukung API IndexedDB HTML5/W3C [ Sumber Daya, 16 ]. Perlu diperhatikan bahwa seiring dengan transisi badan standar pengembangan web yang lebih mengutamakan IndexedDB dibandingkan penyimpanan web, IndexedDB diperkirakan akan menjadi komponen wajib dalam versi Android mendatang.

API HTML5, seperti semua API JavaScript, HARUS dinonaktifkan secara default di WebView, kecuali jika pengembang secara eksplisit mengaktifkannya melalui API Android biasa.

3.4.2. Kompatibilitas Peramban

Implementasi perangkat HARUS menyertakan aplikasi Browser mandiri untuk penjelajahan web pengguna umum. Browser mandiri MUNGKIN didasarkan pada teknologi browser selain WebKit. Namun, meskipun aplikasi Browser alternatif digunakan, komponen android.webkit.WebView yang disediakan untuk aplikasi pihak ketiga HARUS berbasis WebKit, seperti dijelaskan di Bagian 3.4.1.

Implementasi MUNGKIN mengirimkan string agen pengguna khusus dalam aplikasi Browser mandiri.

Aplikasi Browser mandiri (baik berdasarkan aplikasi Browser WebKit upstream atau pengganti pihak ketiga) HARUS menyertakan dukungan untuk HTML5 sebanyak mungkin [ Sumber Daya, 11 ] . Minimal, implementasi perangkat HARUS mendukung setiap API yang terkait dengan HTML5 berikut:

cache aplikasi/operasi offline [ Sumber Daya, 12 ]
tag <video> [ Sumber Daya, 13 ]
geolokasi [ Sumber Daya, 14 ]

3.5. Kompatibilitas Perilaku API

Perilaku masing-masing jenis API (terkelola, lunak, asli, dan web) harus konsisten dengan implementasi pilihan proyek sumber terbuka Android upstream [ Sumber Daya, 3 ]. Beberapa area kompatibilitas tertentu adalah:

Perangkat TIDAK BOLEH mengubah perilaku atau semantik Intent standar
Perangkat TIDAK BOLEH mengubah siklus hidup atau semantik siklus hidup jenis komponen sistem tertentu (seperti Layanan, Aktivitas, ContentProvider, dll.)
Perangkat TIDAK HARUS mengubah semantik izin standar

Daftar di atas tidak lengkap. Compatibility Test Suite (CTS) menguji sebagian besar platform untuk kompatibilitas perilaku, namun tidak semuanya. Implementer bertanggung jawab memastikan kompatibilitas perilaku dengan Proyek Sumber Terbuka Android. Oleh karena itu, pelaksana perangkat HARUS menggunakan kode sumber yang tersedia melalui Proyek Sumber Terbuka Android jika memungkinkan, daripada mengimplementasikan ulang bagian penting dari sistem.

3.6. Ruang Nama API

Android mengikuti konvensi namespace paket dan kelas yang ditentukan oleh bahasa pemrograman Java. Untuk memastikan kompatibilitas dengan aplikasi pihak ketiga, pelaksana perangkat TIDAK BOLEH melakukan modifikasi apa pun yang dilarang (lihat di bawah) pada namespace paket ini:

Jawa.*
javax.*
matahari.*
android.*
com.android.*

Modifikasi yang dilarang antara lain:

Implementasi perangkat TIDAK BOLEH mengubah API yang diekspos secara publik di platform Android dengan mengubah metode atau tanda tangan kelas apa pun, atau dengan menghapus kelas atau kolom kelas.
Pelaksana perangkat MUNGKIN memodifikasi implementasi dasar API, namun modifikasi tersebut TIDAK BOLEH berdampak pada perilaku yang dinyatakan dan tanda tangan bahasa Java dari API apa pun yang diekspos secara publik.
Pelaksana perangkat TIDAK BOLEH menambahkan elemen apa pun yang diekspos secara publik (seperti kelas atau antarmuka, atau bidang atau metode ke kelas atau antarmuka yang ada) ke API di atas.

"Elemen yang diekspos secara publik" adalah konstruksi apa pun yang tidak dihiasi dengan penanda "@hide" seperti yang digunakan dalam kode sumber Android upstream. Dengan kata lain, pelaksana perangkat TIDAK BOLEH mengekspos API baru atau mengubah API yang sudah ada di namespace yang disebutkan di atas. Pelaksana perangkat MUNGKIN melakukan modifikasi internal saja, namun modifikasi tersebut TIDAK BOLEH diiklankan atau diekspos ke pengembang.

Pelaksana perangkat MUNGKIN menambahkan API khusus, namun API tersebut TIDAK BOLEH berada dalam namespace yang dimiliki atau mengacu pada organisasi lain. Misalnya, pelaksana perangkat TIDAK BOLEH menambahkan API ke com.google.* atau namespace serupa; hanya Google yang dapat melakukannya. Demikian pula, Google TIDAK BOLEH menambahkan API ke namespace perusahaan lain. Selain itu, jika implementasi perangkat menyertakan API khusus di luar namespace Android standar, API tersebut HARUS dikemas dalam pustaka bersama Android sehingga hanya aplikasi yang menggunakannya secara eksplisit (melalui mekanisme <uses-library> ) yang terpengaruh oleh peningkatan penggunaan memori API tersebut.

Jika pelaksana perangkat mengusulkan untuk meningkatkan salah satu namespace paket di atas (misalnya dengan menambahkan fungsi baru yang berguna ke API yang sudah ada, atau menambahkan API baru), pelaksana HARUS mengunjungi source.android.com dan memulai proses untuk memberikan kontribusi perubahan dan kode, menurut informasi di situs itu.

Perhatikan bahwa batasan di atas sesuai dengan konvensi standar untuk penamaan API dalam bahasa pemrograman Java; bagian ini hanya bertujuan untuk memperkuat konvensi tersebut dan menjadikannya mengikat melalui penyertaan dalam definisi kompatibilitas ini.

3.7. Kompatibilitas Mesin Virtual

Implementasi perangkat HARUS mendukung spesifikasi bytecode Dalvik Executable (DEX) penuh dan semantik Mesin Virtual Dalvik [ Sumber Daya, 17 ].

Implementasi perangkat HARUS mengonfigurasi Dalvik untuk mengalokasikan memori sesuai dengan platform Android upstream, dan sebagaimana ditentukan oleh tabel berikut. (Lihat Bagian 7.1.1 untuk mengetahui ukuran layar dan definisi kepadatan layar.)

Perhatikan bahwa nilai memori yang ditentukan di bawah ini dianggap sebagai nilai minimum, dan implementasi perangkat MUNGKIN mengalokasikan lebih banyak memori per aplikasi.

Ukuran layar	Kepadatan Layar	Memori Aplikasi
kecil / normal / besar	ldpi / mdpi	16MB
kecil / normal / besar	tvdpi / hdpi	32MB
kecil / normal / besar	xhdpi	64MB
xbesar	mdpi	32MB
xbesar	tvdpi / hdpi	64MB
xbesar	xhdpi	128MB

3.8. Kompatibilitas Antarmuka Pengguna

3.8.1. Widget

Android mendefinisikan tipe komponen dan API serta siklus hidup terkait yang memungkinkan aplikasi mengekspos "AppWidget" ke pengguna akhir [ Sumber Daya, 18 ]. Rilis referensi Sumber Terbuka Android mencakup aplikasi Peluncur yang mencakup keterjangkauan antarmuka pengguna yang memungkinkan pengguna untuk menambah, melihat, dan menghapus AppWidgets dari layar beranda.

Implementasi perangkat MUNGKIN menggantikan alternatif Peluncur referensi (yaitu layar beranda). Peluncur Alternatif HARUS menyertakan dukungan bawaan untuk AppWidgets, dan memaparkan kemampuan antarmuka pengguna untuk menambah, mengonfigurasi, melihat, dan menghapus AppWidgets langsung di dalam Peluncur. Peluncur Alternatif MUNGKIN menghilangkan elemen antarmuka pengguna ini; namun, jika dihilangkan, implementasi perangkat HARUS menyediakan aplikasi terpisah yang dapat diakses dari Peluncur yang memungkinkan pengguna untuk menambah, mengonfigurasi, melihat, dan menghapus AppWidgets.

Implementasi perangkat HARUS mampu merender widget berukuran 4 x 4 dalam ukuran grid standar. (Lihat Pedoman Desain Widget Aplikasi dalam dokumentasi Android SDK [ Sumber Daya, 18 ] untuk detailnya.

3.8.2. Pemberitahuan

Android menyertakan API yang memungkinkan pengembang memberi tahu pengguna tentang peristiwa penting [ Sumber Daya, 19 ], menggunakan fitur perangkat keras dan perangkat lunak perangkat.

Beberapa API memungkinkan aplikasi melakukan notifikasi atau menarik perhatian menggunakan perangkat keras, khususnya suara, getaran, dan cahaya. Implementasi perangkat HARUS mendukung notifikasi yang menggunakan fitur perangkat keras, seperti yang dijelaskan dalam dokumentasi SDK, dan sedapat mungkin dengan perangkat keras implementasi perangkat. Misalnya, jika implementasi perangkat menyertakan vibrator, maka perangkat tersebut HARUS mengimplementasikan API getaran dengan benar. Jika implementasi perangkat tidak memiliki perangkat keras, API terkait HARUS diimplementasikan sebagai tanpa operasi. Perhatikan bahwa perilaku ini dirinci lebih lanjut di Bagian 7.

Selain itu, penerapannya HARUS merender dengan benar semua sumber daya (ikon, file suara, dll.) yang disediakan dalam API [ Sumber Daya, 20 ], atau dalam panduan gaya ikon Status/Bilah Sistem [ Sumber Daya, 21 ]. Implementer perangkat MUNGKIN memberikan pengalaman pengguna alternatif untuk notifikasi selain yang disediakan oleh referensi penerapan Sumber Terbuka Android; namun, sistem notifikasi alternatif tersebut HARUS mendukung sumber notifikasi yang ada, seperti di atas.

Android 4.2 menyertakan dukungan untuk notifikasi yang kaya, seperti Tampilan interaktif untuk notifikasi yang sedang berlangsung. Implementasi perangkat HARUS menampilkan dan menjalankan notifikasi kaya dengan benar, seperti yang didokumentasikan dalam API Android.

3.8.3. Mencari

Android menyertakan API [ Sumber Daya, 22 ] yang memungkinkan pengembang memasukkan penelusuran ke dalam aplikasi mereka, dan mengekspos data aplikasi mereka ke dalam penelusuran sistem global. Secara umum, fungsi ini terdiri dari antarmuka pengguna tunggal di seluruh sistem yang memungkinkan pengguna memasukkan kueri, menampilkan saran saat pengguna mengetik, dan menampilkan hasil. API Android memungkinkan pengembang untuk menggunakan kembali antarmuka ini untuk menyediakan pencarian dalam aplikasi mereka sendiri, dan memungkinkan pengembang untuk memberikan hasil ke antarmuka pengguna pencarian global yang umum.

Implementasi perangkat HARUS mencakup antarmuka pengguna pencarian tunggal, bersama, dan seluruh sistem yang mampu memberikan saran secara real-time sebagai respons terhadap masukan pengguna. Implementasi perangkat HARUS mengimplementasikan API yang memungkinkan pengembang menggunakan kembali antarmuka pengguna ini untuk menyediakan pencarian dalam aplikasi mereka sendiri. Implementasi perangkat HARUS mengimplementasikan API yang memungkinkan aplikasi pihak ketiga menambahkan saran ke kotak pencarian ketika dijalankan dalam mode pencarian global. Jika tidak ada aplikasi pihak ketiga yang diinstal yang menggunakan fungsi ini, perilaku default HARUS menampilkan hasil dan saran mesin pencari web.

3.8.4. Bersulang

Aplikasi dapat menggunakan API "Toast" (didefinisikan di [ Sumberdaya, 23 ]) untuk menampilkan string non-modal pendek kepada pengguna akhir, yang hilang setelah beberapa saat. Implementasi perangkat HARUS menampilkan Toast dari aplikasi ke pengguna akhir dengan cara yang terlihat jelas.

3.8.5. Tema

Android menyediakan "tema" sebagai mekanisme bagi aplikasi untuk menerapkan gaya di seluruh Aktivitas atau aplikasi. Android 4.2 menyertakan tema "Holo" atau "holografik" sebagai sekumpulan gaya yang ditentukan untuk digunakan pengembang aplikasi jika mereka ingin mencocokkan tampilan dan nuansa tema Holo seperti yang ditentukan oleh Android SDK [ Sumber Daya, 24 ]. Implementasi perangkat TIDAK BOLEH mengubah atribut tema Holo apa pun yang diekspos ke aplikasi [ Sumber Daya, 25 ].

Android 4.2 menyertakan tema "Default Perangkat" baru sebagai sekumpulan gaya yang ditentukan untuk digunakan pengembang aplikasi jika mereka ingin mencocokkan tampilan dan nuansa tema perangkat seperti yang ditentukan oleh pelaksana perangkat. Implementasi perangkat MUNGKIN mengubah atribut tema DeviceDefault yang diekspos ke aplikasi [ Sumber Daya, 25 ].

3.8.6. Wallpaper Hidup

Android mendefinisikan jenis komponen dan API serta siklus hidup terkait yang memungkinkan aplikasi mengekspos satu atau lebih "Wallpaper Animasi" kepada pengguna akhir [ Sumber Daya, 26 ]. Wallpaper Animasi adalah animasi, pola, atau gambar serupa dengan kemampuan masukan terbatas yang ditampilkan sebagai wallpaper, di belakang aplikasi lain.

Perangkat keras dianggap mampu menjalankan wallpaper hidup dengan andal jika dapat menjalankan semua wallpaper hidup, tanpa batasan fungsionalitas, pada framerate wajar tanpa dampak buruk pada aplikasi lain. Jika keterbatasan pada perangkat keras menyebabkan wallpaper dan/atau aplikasi mogok, tidak berfungsi, menghabiskan daya CPU atau baterai secara berlebihan, atau berjalan pada kecepatan bingkai yang sangat rendah, perangkat keras tersebut dianggap tidak mampu menjalankan wallpaper hidup. Sebagai contoh, beberapa wallpaper animasi mungkin menggunakan konteks Open GL 1.0 atau 2.0 untuk merender kontennya. Wallpaper hidup tidak akan berjalan dengan andal pada perangkat keras yang tidak mendukung beberapa konteks OpenGL karena penggunaan wallpaper hidup dalam konteks OpenGL mungkin bertentangan dengan aplikasi lain yang juga menggunakan konteks OpenGL.

Implementasi perangkat yang mampu menjalankan wallpaper hidup dengan andal seperti dijelaskan di atas HARUS menerapkan wallpaper hidup. Implementasi perangkat ditentukan untuk tidak menjalankan wallpaper hidup dengan andal seperti yang dijelaskan di atas TIDAK BOLEH menerapkan wallpaper hidup.

3.8.7. Tampilan Aplikasi Terbaru

Kode sumber Android 4.2 upstream menyertakan antarmuka pengguna untuk menampilkan aplikasi terbaru menggunakan gambar thumbnail status grafis aplikasi pada saat terakhir pengguna meninggalkan aplikasi. Implementasi perangkat DAPAT mengubah atau menghilangkan antarmuka pengguna ini; namun, versi Android mendatang direncanakan untuk memanfaatkan fungsi ini secara lebih luas. Implementasi perangkat sangat dianjurkan untuk menggunakan antarmuka pengguna Android 4.2 upstream (atau antarmuka berbasis thumbnail serupa) untuk aplikasi terbaru, jika tidak, aplikasi tersebut mungkin tidak kompatibel dengan versi Android yang akan datang.

3.8.8. Pengaturan Manajemen Masukan

Android 4.2 menyertakan dukungan untuk Mesin Manajemen Input. API Android 4.2 memungkinkan IME aplikasi khusus menentukan setelan yang dapat disesuaikan pengguna. Penerapan perangkat HARUS menyertakan cara bagi pengguna untuk mengakses pengaturan IME setiap saat ketika IME yang menyediakan pengaturan pengguna tersebut ditampilkan.

3.8.9. Kunci dan Widget Layar Beranda

Android 4.2 menyertakan dukungan untuk widget aplikasi yang dapat disematkan pengguna di layar beranda atau layar kunci (Lihat Pedoman Desain Widget Aplikasi dalam dokumentasi Android SDK [ Sumber Daya, 69 ] untuk detailnya). Widget aplikasi memungkinkan akses cepat ke data dan layanan aplikasi tanpa meluncurkan aktivitas baru. Widget mendeklarasikan dukungan untuk penggunaan di layar beranda atau layar kunci dengan mendeklarasikan tag manifes android:widgetCategory yang memberi tahu sistem di mana widget dapat ditempatkan. Secara khusus, implementasi perangkat HARUS memenuhi persyaratan berikut.

Implementasi perangkat HARUS mendukung widget aplikasi di layar beranda.
Implementasi perangkat HARUS mendukung layar kunci. Jika implementasi perangkat menyertakan dukungan untuk layar kunci, maka implementasi perangkat HARUS mendukung widget aplikasi di layar kunci.

3.8.10. Kontrol Jarak Jauh Media Layar Kunci

Android 4.2 menyertakan dukungan untuk Remote Control API yang memungkinkan aplikasi media berintegrasi dengan kontrol pemutaran yang ditampilkan dalam tampilan jarak jauh seperti layar kunci perangkat[ Sumber Daya, 74 ]. Implementasi perangkat HARUS menyertakan dukungan untuk menyematkan kendali jarak jauh di layar kunci perangkat.

3.8.11. Mimpi

Android 4.2 menyertakan dukungan untuk screensaver interaktif yang disebut Dreams [ Resources, 76 ]. Dreams memungkinkan pengguna untuk berinteraksi dengan aplikasi saat perangkat pengisi daya tidak digunakan, atau dipasang di dok meja. Implementasi perangkat HARUS menyertakan dukungan untuk Dreams dan menyediakan opsi pengaturan bagi pengguna untuk mengonfigurasi Dreams.

3.9 Administrasi Perangkat

Android 4.2 menyertakan fitur yang memungkinkan aplikasi sadar keamanan menjalankan fungsi administrasi perangkat di tingkat sistem, seperti menerapkan kebijakan kata sandi atau melakukan penghapusan jarak jauh, melalui Android Device Administration API [ Sumber Daya, 27 ]. Implementasi perangkat HARUS menyediakan implementasi kelas DevicePolicyManager [ Resources, 28 ], dan HARUS mendukung seluruh kebijakan administrasi perangkat yang ditentukan dalam dokumentasi Android SDK [ Resources, 27 ].

Catatan: meskipun beberapa persyaratan yang diuraikan di atas dinyatakan sebagai "HARUS" untuk Android 4.2, penerapan perangkat yang mendukung layar kunci HARUS mendukung kebijakan perangkat untuk mengelola widget di layar kunci seperti yang ditentukan dalam dokumentasi Android SDK [ Sumber Daya, 27 ].

Catatan: meskipun beberapa persyaratan yang diuraikan di atas dinyatakan sebagai "HARUS" untuk Android 4.2, Definisi Kompatibilitas untuk versi mendatang direncanakan akan mengubahnya menjadi "HARUS". Artinya, persyaratan ini bersifat opsional di Android 4.2 namun akan diwajibkan pada versi mendatang. Perangkat lama dan baru yang menjalankan Android 4.2 sangat disarankan untuk memenuhi persyaratan ini di Android 4.2 , atau perangkat tersebut tidak akan dapat memperoleh kompatibilitas Android saat ditingkatkan ke versi mendatang.

3.10 Aksesibilitas

Android 4.2 menyediakan lapisan aksesibilitas yang membantu pengguna penyandang disabilitas menavigasi perangkat mereka dengan lebih mudah. Selain itu, Android 4.2 menyediakan API platform yang memungkinkan implementasi layanan aksesibilitas menerima callback untuk kejadian pengguna dan sistem serta menghasilkan mekanisme masukan alternatif, seperti text-to-speech, masukan haptik, dan navigasi trackball/d-pad [ Sumber Daya, 29 ] . Implementasi perangkat HARUS menyediakan implementasi framework aksesibilitas Android yang konsisten dengan implementasi default Android. Secara khusus, implementasi perangkat HARUS memenuhi persyaratan berikut.

Implementasi perangkat HARUS mendukung implementasi layanan aksesibilitas pihak ketiga melalui API android.accessibilityservice [ Sumber Daya, 30 ].
Implementasi perangkat HARUS menghasilkan AccessibilityEvents dan mengirimkan peristiwa ini ke semua implementasi AccessibilityService yang terdaftar dengan cara yang konsisten dengan implementasi Android default.
Implementasi perangkat HARUS menyediakan mekanisme yang dapat diakses pengguna untuk mengaktifkan dan menonaktifkan layanan aksesibilitas, dan HARUS menampilkan antarmuka ini sebagai respons terhadap maksud android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS .

Selain itu, implementasi perangkat HARUS menyediakan implementasi layanan aksesibilitas pada perangkat, dan HARUS menyediakan mekanisme bagi pengguna untuk mengaktifkan layanan aksesibilitas selama penyiapan perangkat. Implementasi layanan aksesibilitas sumber terbuka tersedia dari proyek Eyes Free [ Sumber Daya, 31 ].

3.11 Teks-ke-Ucapan

Android 4.2 menyertakan API yang memungkinkan aplikasi menggunakan layanan text-to-speech (TTS), dan memungkinkan penyedia layanan menyediakan implementasi layanan TTS [ Sumberdaya, 32 ]. Implementasi perangkat HARUS memenuhi persyaratan berikut terkait dengan framework Android TTS:

Implementasi perangkat HARUS mendukung API framework Android TTS dan HARUS menyertakan mesin TTS yang mendukung bahasa yang tersedia di perangkat. Perhatikan bahwa perangkat lunak sumber terbuka Android hulu menyertakan implementasi mesin TTS berfitur lengkap.
Implementasi perangkat HARUS mendukung pemasangan mesin TTS pihak ketiga.
Implementasi perangkat HARUS menyediakan antarmuka yang dapat diakses pengguna yang memungkinkan pengguna memilih mesin TTS untuk digunakan pada tingkat sistem.

4. Kompatibilitas Kemasan Aplikasi

Implementasi perangkat HARUS menginstal dan menjalankan file ".apk" Android seperti yang dihasilkan oleh alat "aapt" yang disertakan dalam SDK Android resmi [ Sumber Daya, 33 ].

Implementasi perangkat TIDAK HARUS memperluas format .apk [ Resources, 34 ], Android Manifest [ Resources, 35 ], Dalvik bytecode [ Resources, 17 ], atau renderscript bytecode sedemikian rupa sehingga mencegah file tersebut dipasang dan dijalankan dengan benar di perangkat lain yang kompatibel. Pelaksana perangkat HARUS menggunakan implementasi referensi hulu Dalvik, dan sistem manajemen paket implementasi referensi.

5. Kompatibilitas Multimedia

Implementasi perangkat HARUS mencakup setidaknya satu bentuk output audio, seperti speaker, jack headphone, sambungan speaker eksternal, dll.

5.1. Codec Media

Implementasi perangkat HARUS mendukung format media inti yang ditentukan dalam dokumentasi Android SDK [ Sumber Daya, 58 ] kecuali jika diizinkan secara eksplisit dalam dokumen ini. Secara khusus, implementasi perangkat HARUS mendukung format media, encoder, decoder, jenis file, dan format kontainer yang ditentukan dalam tabel di bawah. Semua codec ini disediakan sebagai implementasi perangkat lunak dalam implementasi Android pilihan dari Proyek Sumber Terbuka Android.

Harap dicatat bahwa baik Google maupun Open Handset Alliance tidak membuat pernyataan apa pun bahwa codec ini tidak terbebani oleh paten pihak ketiga. Mereka yang ingin menggunakan kode sumber ini dalam produk perangkat keras atau perangkat lunak disarankan bahwa penerapan kode ini, termasuk dalam perangkat lunak sumber terbuka atau shareware, mungkin memerlukan lisensi paten dari pemegang paten terkait.

Perhatikan bahwa tabel ini tidak mencantumkan persyaratan kecepatan bit tertentu untuk sebagian besar codec video karena perangkat keras perangkat saat ini belum tentu mendukung kecepatan bit yang dipetakan secara tepat ke kecepatan bit yang diperlukan yang ditentukan oleh standar yang relevan. Sebaliknya, implementasi perangkat HARUS mendukung bitrate tertinggi pada perangkat keras, hingga batas yang ditentukan oleh spesifikasi.

Jenis	Format / Kodek	Pembuat enkode	Dekoder	Detail	Jenis File / Format Kontainer
Audio	Profil AAC MPEG-4 (AAC LC)	DIPERLUKAN Diperlukan untuk implementasi perangkat yang menyertakan hardware mikrofon dan mendefinisikan `android.hardware.microphone` .	DIPERLUKAN	Dukungan untuk konten mono/stereo/5.0/5.1* dengan laju pengambilan sampel standar dari 8 hingga 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS raw AAC (.aac, decode di Android 3.1+, encode di Android 4.0+, ADIF tidak didukung) MPEG-TS (.ts, tidak dapat dicari, Android 3.0+)
	Profil MPEG-4 HE AAC (AAC+)	DIPERLUKAN untuk implementasi perangkat yang menyertakan hardware mikrofon dan mendefinisikan android.hardware.microphone	DIPERLUKAN	Dukungan untuk konten mono/stereo/5.0/5.1* dengan laju pengambilan sampel standar dari 16 hingga 48 kHz.
	Profil MPEG-4 HE AAC v2 (AAC+ yang ditingkatkan)		DIPERLUKAN	Dukungan untuk konten mono/stereo/5.0/5.1* dengan laju pengambilan sampel standar dari 16 hingga 48 kHz.
	Objek Audio MPEG-4 Tipe ER AAC ELD (AAC Penundaan Rendah yang Ditingkatkan)	DIPERLUKAN untuk implementasi perangkat yang menyertakan hardware mikrofon dan mendefinisikan android.hardware.microphone	DIPERLUKAN	Dukungan untuk konten mono/stereo dengan laju pengambilan sampel standar dari 16 hingga 48 kHz.
	AMR-NB	DIPERLUKAN Diperlukan untuk implementasi perangkat yang menyertakan hardware mikrofon dan mendefinisikan `android.hardware.microphone` .	DIPERLUKAN	Sampel 4,75 hingga 12,2 kbps @ 8kHz	3GPP (.3gp)
	AMR-WB	DIPERLUKAN Diperlukan untuk implementasi perangkat yang menyertakan hardware mikrofon dan mendefinisikan `android.hardware.microphone` .	DIPERLUKAN	9 kecepatan dari 6,60 kbit/s hingga 23,85 kbit/s sampel @ 16kHz	3GPP (.3gp)
	FLAC		DIPERLUKAN (Android 3.1+)	Mono/Stereo (tanpa multisaluran). Kecepatan sampel hingga 48 kHz (tetapi disarankan hingga 44,1 kHz pada perangkat dengan output 44,1 kHz, karena downsampler 48 hingga 44,1 kHz tidak menyertakan filter low-pass). direkomendasikan 16-bit; tidak ada keragu-raguan yang diterapkan untuk 24-bit.	FLAC (.flac) saja
	MP3		DIPERLUKAN	Konstanta Mono/Stereo 8-320Kbps (CBR) atau kecepatan bit variabel (VBR)	MP3 (.mp3)
	MIDI		DIPERLUKAN	MIDI Tipe 0 dan 1. DLS Versi 1 dan 2. XMF dan Mobile XMF. Dukungan untuk format nada dering RTTTL/RTX, OTA, dan iMelody	Ketik 0 dan 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) OTA (.ota) iMelody (.imy)
	Vorbis		DIPERLUKAN		Ogg (.ogg) Matroska (.mkv)
	PCM/GELOMBANG	DIPERLUKAN	DIPERLUKAN	PCM linier 8-bit dan 16-bit** (kecepatan hingga batas perangkat keras). Perangkat HARUS mendukung kecepatan pengambilan sampel untuk perekaman PCM mentah pada frekuensi 8000,16000 dan 44100 Hz	GELOMBANG (.wav)
Gambar	jpeg	DIPERLUKAN	DIPERLUKAN	Basis+progresif	JPEG (.jpg)
	GIF		DIPERLUKAN		GIF (.gif)
	PNG	DIPERLUKAN	DIPERLUKAN		PNG (.png)
	BMP		DIPERLUKAN		BMP (.bmp)
	WEBP	DIPERLUKAN	DIPERLUKAN		WebP (.webp)
Video	H.263	DIPERLUKAN Diperlukan untuk implementasi perangkat yang menyertakan hardware kamera dan mendefinisikan `android.hardware.camera` atau `android.hardware.camera.front` .	DIPERLUKAN		3GPP (.3gp) MPEG-4 (.mp4)
	H.264 AVC	DIPERLUKAN Diperlukan untuk implementasi perangkat yang menyertakan hardware kamera dan mendefinisikan `android.hardware.camera` atau `android.hardware.camera.front` .	DIPERLUKAN	Profil Dasar (BP)	3GPP (.3gp) MPEG-4 (.mp4) MPEG-TS (.ts, hanya audio AAC, tidak dapat dicari, Android 3.0+)
	MPEG-4SP		DIPERLUKAN		3GPP (.3gp)
	Wakil Presiden8		DIPERLUKAN (Android 2.3.3+)		WebM (.webm) dan Matroska (.mkv, Android 4.0+)

*Catatan: Hanya diperlukan downmix konten 5.0/5.1; merekam atau merender lebih dari 2 saluran adalah opsional. **Catatan: Pengambilan PCM linier 16-bit wajib dilakukan. Pengambilan PCM linier 8-bit tidak wajib.

5.2 Pengkodean Video

Implementasi perangkat Android yang menyertakan kamera menghadap ke belakang dan mendeklarasikan android.hardware.camera HARUS mendukung profil enkode video berikut.

	SD (Kualitas rendah)	SD (Kualitas tinggi)	HD (Bila didukung oleh perangkat keras)
Kodek video	Profil Dasar H.264	Profil Dasar H.264	Profil Dasar H.264
Resolusi video	176x144 piksel	480x360 piksel	1280x720 piksel
Kecepatan bingkai video	12fps	30fps	30fps
Kecepatan bit video	56 Kbps	500 Kbps atau lebih tinggi	2Mbps atau lebih tinggi
Kodek audio	AAC-LC	AAC-LC	AAC-LC
Saluran audio	1 (mono)	2 (stereo)	2 (stereo)
Kecepatan bit audio	24Kbps	128 Kbps	192Kbps

5.3 Penguraian Kode Video

Implementasi perangkat Android HARUS mendukung profil decoding video VP8 berikut.

	SD (Kualitas rendah)	SD (Kualitas tinggi)	HD 720p (Bila didukung oleh perangkat keras)	HD 1080p (Bila didukung oleh perangkat keras)
Resolusi video	320x180 piksel	640x360 piksel	1280x720 piksel	1920x1080 piksel
Kecepatan bingkai video	30fps	30fps	30fps	30fps
Kecepatan bit video	800 Kbps	2Mbps	8Mbps	20Mbps

5.4. Rekaman audio

Jika aplikasi telah menggunakan android.media.AudioRecord API untuk mulai merekam streaming audio, implementasi perangkat yang menyertakan hardware mikrofon dan mendeklarasikan android.hardware.microphone HARUS mengambil sampel dan merekam audio dengan masing-masing perilaku berikut:

Perangkat HARUS menunjukkan karakteristik amplitudo versus frekuensi yang kira-kira datar; khususnya, ±3 dB, dari 100 Hz hingga 4000 Hz
Sensitivitas input audio HARUS diatur sedemikian rupa sehingga sumber tingkat daya suara (SPL) 90 dB pada 1000 Hz menghasilkan RMS 2500 untuk sampel 16-bit.
Tingkat amplitudo PCM HARUS melacak perubahan SPL input secara linier pada rentang setidaknya 30 dB dari -18 dB hingga +12 dB hingga 90 dB SPL di mikrofon.
Distorsi harmonik total HARUS kurang dari 1% untuk 1Khz pada tingkat input SPL 90 dB.

Selain spesifikasi perekaman di atas, ketika aplikasi sudah mulai merekam streaming audio menggunakan sumber audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION :

Pemrosesan pengurangan kebisingan, jika ada, HARUS dinonaktifkan.
Kontrol penguatan otomatis, jika ada, HARUS dinonaktifkan.

Catatan: meskipun beberapa persyaratan yang diuraikan di atas dinyatakan sebagai "HARUS" untuk Android 4.2, Definisi Kompatibilitas untuk versi mendatang direncanakan akan mengubahnya menjadi "HARUS". Artinya, persyaratan ini bersifat opsional di Android 4.2 namun akan diwajibkan pada versi mendatang. Perangkat yang ada dan baru yang menjalankan Android 4.2 sangat dianjurkan untuk memenuhi persyaratan ini di Android 4.2 , atau mereka tidak akan dapat mencapai kompatibilitas Android ketika ditingkatkan ke versi masa depan.

5.5. Latensi audio

Latensi audio adalah penundaan waktu ketika sinyal audio melewati sistem. Banyak kelas aplikasi bergantung pada latensi pendek, untuk mencapai efek waktu nyata seperti efek suara atau komunikasi VoIP.

Untuk keperluan bagian ini:

"Latensi keluaran" didefinisikan sebagai interval antara ketika aplikasi menulis bingkai data kode PCM dan ketika suara yang sesuai dapat didengar oleh pendengar eksternal atau diamati oleh transduser
"Latensi Output Dingin" didefinisikan sebagai latensi output untuk frame pertama, ketika sistem output audio telah menganggur dan didukung sebelum permintaan
"Latensi Output Berkelanjutan" didefinisikan sebagai latensi output untuk frame berikutnya, setelah perangkat sudah bermain audio
"Latensi input" adalah interval antara ketika suara eksternal disajikan ke perangkat dan ketika aplikasi membaca bingkai yang sesuai dari data kode PCM
"Latensi Input Dingin" didefinisikan sebagai jumlah waktu input yang hilang dan latensi input untuk bingkai pertama, ketika sistem input audio telah menganggur dan dimatikan sebelum permintaan
"Latensi Input Berkelanjutan" didefinisikan sebagai latensi input untuk frame berikutnya, sedangkan perangkat sudah menangkap audio
"OpenSL ES PCM Buffer Queue API" adalah himpunan Opensl ES terkait PCM di dalam Android NDK; Lihat ndk_root /docs/opensles/index.html

Per bagian 5 , semua implementasi perangkat yang kompatibel harus mencakup setidaknya satu bentuk output audio. Implementasi perangkat harus memenuhi atau melampaui persyaratan latensi output ini:

latensi output dingin 100 milidetik atau kurang
Latensi keluaran terus menerus dari 45 milidetik atau kurang

Jika implementasi perangkat memenuhi persyaratan bagian ini setelah kalibrasi awal saat menggunakan OpenSl ES PCM Buffer Queue API, untuk latensi output berkelanjutan dan latensi output dingin pada setidaknya satu perangkat output audio yang didukung, itu dapat melaporkan dukungan untuk audio latensi rendah rendah latensi rendah , dengan melaporkan fitur "android.hardware.audio.low-latency" melalui kelas android.content.pm.PackageManager . [ Sumber Daya, 37 ] Sebaliknya, jika implementasi perangkat tidak memenuhi persyaratan ini, ia tidak boleh melaporkan dukungan untuk audio latensi rendah.

Per bagian 7.2.5 , perangkat keras mikrofon dapat dihilangkan dengan implementasi perangkat.

Implementasi perangkat yang mencakup perangkat keras mikrofon dan mendeklarasikan android.hardware.microphone harus memenuhi persyaratan latensi audio input ini:

latensi input dingin 100 milidetik atau kurang
latensi input kontinu 50 milidetik atau kurang

5.6. Protokol Jaringan

Perangkat harus mendukung protokol jaringan media untuk pemutaran audio dan video sebagaimana ditentukan dalam dokumentasi Android SDK [ Resources, 58 ]. Secara khusus, perangkat harus mendukung protokol jaringan media berikut:

RTSP (RTP, SDP)
Http (s) streaming progresif
HTTP (S) Live Streaming Draft Protocol, Versi 3 [ Sumber Daya, 59 ]

6. Kompatibilitas Alat dan Opsi Pengembang

6.1 Alat Pengembang

Implementasi perangkat harus mendukung alat pengembang Android yang disediakan di Android SDK. Secara khusus, perangkat yang kompatibel dengan Android harus kompatibel dengan:

Android Debug Bridge (dikenal sebagai ADB) [ Sumber Daya, 33 ]
Implementasi perangkat harus mendukung semua fungsi adb seperti yang didokumentasikan dalam Android SDK. Daemon adb sisi perangkat harus tidak aktif secara default, dan harus ada mekanisme yang dapat diakses pengguna untuk menyalakan jembatan debug Android.

Android 4.2.2 termasuk dukungan untuk ADB yang aman. Secure ADB Mengaktifkan ADB pada host yang diotentikasi yang diketahui. Perangkat yang ada dan baru yang menjalankan Android 4.2.2 sangat dianjurkan untuk memenuhi persyaratan ini di Android 4.2 , atau mereka tidak akan dapat mencapai kompatibilitas Android ketika ditingkatkan ke versi masa depan.

Dalvik Debug Monitor Service (dikenal sebagai DDMS) [ Sumber Daya, 33 ]
Implementasi perangkat harus mendukung semua fitur ddms seperti yang didokumentasikan dalam Android SDK. Karena ddms menggunakan adb , dukungan untuk ddms harus tidak aktif secara default, tetapi harus didukung setiap kali pengguna mengaktifkan jembatan Android Debug, seperti di atas.
Monyet [ Sumber Daya, 36 ]
Implementasi perangkat harus mencakup kerangka kerja monyet, dan membuatnya tersedia untuk aplikasi untuk digunakan.
Systrace [ Sumber Daya, 33 ]
Implementasi perangkat harus mendukung alat Systrace seperti yang didokumentasikan dalam Android SDK. Systrace harus tidak aktif secara default, dan harus ada mekanisme yang dapat diakses pengguna untuk menyalakan Systrace.

Sebagian besar sistem berbasis Linux dan sistem Apple Macintosh mengenali perangkat Android menggunakan alat Android SDK standar, tanpa dukungan tambahan; Namun sistem Microsoft Windows biasanya memerlukan driver untuk perangkat Android baru. (Misalnya, ID vendor baru dan kadang -kadang ID perangkat baru memerlukan driver USB khusus untuk sistem Windows.) Jika implementasi perangkat tidak diakui oleh alat adb sebagaimana disediakan dalam SDK Android standar, pelaksana perangkat harus menyediakan driver Windows yang memungkinkan pengembang untuk terhubung ke Perangkat menggunakan protokol adb . Driver ini harus disediakan untuk Windows XP, Windows Vista, Windows 7, dan Windows 8, dalam versi 32-bit dan 64-bit.

6.2 Opsi Pengembang

Android 4.2 termasuk dukungan bagi pengembang untuk mengonfigurasi pengaturan terkait pengembangan aplikasi. Implementasi perangkat harus menghormati Android.settings.application_development_settings Niat untuk menunjukkan pengaturan terkait pengembangan aplikasi [ Sumber Daya, 77 ]. Implementasi Android hulu menyembunyikan menu Opsi Pengembang secara default, dan memungkinkan pengguna untuk meluncurkan opsi pengembang setelah menekan tujuh (7) kali pada pengaturan> tentang perangkat> Build Number Menu item. Implementasi perangkat harus memberikan pengalaman yang konsisten untuk opsi pengembang. Secara khusus, implementasi perangkat harus menyembunyikan opsi pengembang secara default dan harus memberikan mekanisme untuk memungkinkan opsi pengembang yang konsisten dengan implementasi Android hulu.

7. Kompatibilitas perangkat keras

Jika perangkat menyertakan komponen perangkat keras tertentu yang memiliki API yang sesuai untuk pengembang pihak ketiga, implementasi perangkat harus mengimplementasikan API tersebut seperti yang dijelaskan dalam dokumentasi Android SDK. Jika API di SDK berinteraksi dengan komponen perangkat keras yang dinyatakan sebagai opsional dan implementasi perangkat tidak memiliki komponen itu:

Definisi kelas lengkap (seperti yang didokumentasikan oleh SDK) untuk API komponen masih harus ada
Perilaku API harus diimplementasikan sebagai tidak ada ops dengan cara yang masuk akal
Metode API harus mengembalikan nilai nol jika diizinkan oleh dokumentasi SDK
Metode API Harus Mengembalikan Implementasi Kelas No-Op di mana nilai nol tidak diizinkan oleh dokumentasi SDK
Metode API tidak boleh melempar pengecualian yang tidak didokumentasikan oleh dokumentasi SDK

Contoh khas dari skenario di mana persyaratan ini berlaku adalah API Telephony: Bahkan pada perangkat non-telepon, API ini harus diimplementasikan sebagai no-op yang masuk akal.

Implementasi Perangkat harus secara akurat melaporkan informasi konfigurasi perangkat keras yang akurat melalui metode getSystemAvailableFeatures() dan hasSystemFeature(String) di kelas android.content.pm.PackageManager . [ Sumber Daya, 37 ]

7.1. Tampilan dan Grafik

Android 4.2 mencakup fasilitas yang secara otomatis menyesuaikan aset aplikasi dan tata letak UI secara tepat untuk perangkat, untuk memastikan bahwa aplikasi pihak ketiga berjalan dengan baik pada berbagai konfigurasi perangkat keras [ sumber daya, 38 ]. Perangkat harus mengimplementasikan API dan perilaku ini dengan benar, sebagaimana dirinci dalam bagian ini.

Unit yang dirujuk oleh persyaratan di bagian ini didefinisikan sebagai berikut:

"Ukuran diagonal fisik" adalah jarak dalam inci antara dua sudut yang berlawanan dari bagian layar yang diterangi.
"DPI" (artinya "titik per inci") adalah jumlah piksel yang dicakup oleh rentang horizontal atau vertikal linier 1 ". Di mana nilai DPI terdaftar, baik DPI horizontal dan vertikal harus berada dalam kisaran.
"Rasio aspek" adalah rasio dimensi yang lebih panjang dari layar terhadap dimensi yang lebih pendek. Misalnya, tampilan 480x854 piksel adalah 854 /480 = 1.779, atau kira -kira "16: 9".
"Pixel-independen-kepadatan" atau ("DP") adalah unit piksel virtual yang dinormalisasi ke layar 160 dpi, dihitung sebagai: pixels = dps * (density / 160) .

7.1.1. Konfigurasi Layar

Ukuran layar

Kerangka kerja Android UI mendukung berbagai ukuran layar yang berbeda, dan memungkinkan aplikasi untuk menanyakan ukuran layar perangkat (alias "tata letak layar") melalui android.content.res.Configuration.screenLayout dengan SCREENLAYOUT_SIZE_MASK . Implementasi perangkat harus melaporkan ukuran layar yang benar sebagaimana didefinisikan dalam dokumentasi Android SDK [ Sumber Daya, 38 ] dan ditentukan oleh platform Android hulu. Secara khusus, implementasi perangkat harus melaporkan ukuran layar yang benar sesuai dengan dimensi layar piksel-independen-independen (DP).

Perangkat harus memiliki ukuran layar minimal 426 dp x 320 dp ('kecil')
Perangkat yang melaporkan ukuran layar 'normal' harus memiliki ukuran layar setidaknya 480 dp x 320 dp
Perangkat yang melaporkan ukuran layar 'besar' harus memiliki ukuran layar setidaknya 640 dp x 480 dp
Perangkat yang melaporkan ukuran layar 'xlarge' harus memiliki ukuran layar setidaknya 960 dp x 720 dp

Selain itu, perangkat harus memiliki ukuran layar minimal 2,5 inci dalam ukuran diagonal fisik.

Perangkat tidak boleh mengubah ukuran layar yang dilaporkan kapan saja.

Aplikasi secara opsional menunjukkan ukuran layar mana yang mereka dukung melalui atribut <supports-screens> di file androidmanifest.xml. Implementasi perangkat harus menghormati aplikasi yang dinyatakan dengan benar untuk layar kecil, normal, besar, dan xlarge, seperti yang dijelaskan dalam dokumentasi Android SDK.

Rasio Aspek Layar

Rasio aspek harus antara 1,3333 (4: 3) dan 1,85 (16: 9).

Kepadatan Layar

Kerangka kerja Android UI mendefinisikan serangkaian kepadatan logis standar untuk membantu pengembang aplikasi menargetkan sumber daya aplikasi. Implementasi perangkat harus melaporkan salah satu dari kepadatan kerangka kerja Android logis berikut melalui android.util.DisplayMetrics API, dan harus menjalankan aplikasi pada kepadatan standar ini.

120 dpi, dikenal sebagai 'LDPI'
160 dpi, dikenal sebagai 'mdpi'
213 dpi, dikenal sebagai 'tvdpi'
240 dpi, dikenal sebagai 'hdpi'
320 dpi, dikenal sebagai 'xhdpi'
480 dpi, dikenal sebagai 'xxhdpi'

Implementasi perangkat harus menentukan kerapatan kerangka Android standar yang secara numerik terdekat dengan kepadatan fisik layar, kecuali kepadatan logis itu mendorong ukuran layar yang dilaporkan di bawah minimum yang didukung. Jika kepadatan kerangka Android standar yang paling dekat dengan kepadatan fisik menghasilkan ukuran layar yang lebih kecil dari ukuran layar kompatibel yang kompatibel dengan terkecil (lebar 320 dp), implementasi perangkat harus melaporkan kepadatan kerangka Android standar terendah berikutnya.

7.1.2. Metrik Tampilan

Implementasi perangkat harus melaporkan nilai yang benar untuk semua metrik tampilan yang ditentukan dalam android.util.DisplayMetrics [ Sumber Daya, 39 ].

7.1.3. Orientasi layar

Perangkat harus mendukung orientasi dinamis berdasarkan aplikasi untuk orientasi potret atau orientasi layar lansekap. Artinya, perangkat harus menghormati permintaan aplikasi untuk orientasi layar tertentu. Implementasi perangkat dapat memilih orientasi potret atau lanskap sebagai default.

Perangkat harus melaporkan nilai yang benar untuk orientasi perangkat saat ini, kapan pun ditanya melalui android.content.res.configuration.orientation, android.view.display.getorientation (), atau API lainnya.

Perangkat tidak boleh mengubah ukuran atau kepadatan layar yang dilaporkan saat mengubah orientasi.

Perangkat harus melaporkan orientasi layar mana yang mereka dukung ( android.hardware.screen.portrait dan/atau android.hardware.screen.landscape ) dan harus melaporkan setidaknya satu orientasi yang didukung. Misalnya, perangkat dengan layar lansekap orientasi tetap, seperti televisi atau laptop, hanya harus melaporkan android.hardware.screen.landscape .

7.1.4. Akselerasi Grafik 2D dan 3D

Implementasi perangkat harus mendukung OpenGL ES 1.0 dan 2.0, sebagaimana diwujudkan dan dirinci dalam dokumentasi Android SDK. Implementasi perangkat juga harus mendukung Android RenderScript, sebagaimana dirinci dalam dokumentasi Android SDK [ Sumber Daya, 8 ].

Implementasi perangkat juga harus mengidentifikasi diri mereka dengan benar sebagai mendukung OpenGL ES 1.0 dan 2.0. Itu adalah:

API yang dikelola (seperti melalui metode GLES10.getString() ) harus melaporkan dukungan untuk OpenGL ES 1.0 dan 2.0
API OpenGL C/C ++ asli (yaitu, yang tersedia untuk aplikasi melalui libgles_v1cm.so, libgles_v2.so, atau libegl.so) harus melaporkan dukungan untuk OpenGL ES 1.0 dan 2.0.

Implementasi perangkat dapat mengimplementasikan ekstensi OpenGL ES yang diinginkan. Namun, implementasi perangkat harus melaporkan melalui OpenGL ES yang dikelola dan API asli semua string ekstensi yang mereka dukung, dan sebaliknya tidak boleh melaporkan string ekstensi yang tidak mereka dukung.

Perhatikan bahwa Android 4.2 termasuk dukungan untuk aplikasi untuk secara opsional menentukan bahwa mereka memerlukan format kompresi tekstur openGL tertentu. Format ini biasanya spesifik vendor. Implementasi perangkat tidak diperlukan oleh Android 4.2 untuk mengimplementasikan format kompresi tekstur tertentu. Namun, mereka harus secara akurat melaporkan format kompresi tekstur apa pun yang mereka dukung, melalui metode getString() di API OpenGL.

Android 4.2 mencakup mekanisme untuk aplikasi untuk menyatakan bahwa mereka ingin mengaktifkan akselerasi perangkat keras untuk grafik 2D di level aplikasi, aktivitas, jendela atau tampilan melalui penggunaan tag manifes android:hardwareAccelerated atau API panggilan API [ Sumber Daya, 9 ].

Di Android 4.2, implementasi perangkat harus mengaktifkan akselerasi perangkat keras secara default, dan harus menonaktifkan akselerasi perangkat keras jika pengembang jadi meminta dengan mengatur android:hardwareAccelerated="false" atau menonaktifkan akselerasi perangkat keras langsung melalui API Android View.

Selain itu, implementasi perangkat harus menunjukkan perilaku yang konsisten dengan dokumentasi Android SDK tentang akselerasi perangkat keras [ Sumber Daya, 9 ].

Android 4.2 termasuk objek TextureView yang memungkinkan pengembang secara langsung mengintegrasikan tekstur OpenGl ES yang dipercepat dengan perangkat keras sebagai target rendering dalam hierarki UI. Implementasi perangkat harus mendukung API TextureView , dan harus menunjukkan perilaku yang konsisten dengan implementasi Android hulu.

7.1.5. Mode Kompatibilitas Aplikasi Legacy

Android 4.2 menentukan "mode kompatibilitas" di mana kerangka kerja beroperasi dalam mode ukuran layar 'normal' yang setara (lebar 320dp) untuk manfaat aplikasi warisan yang tidak dikembangkan untuk versi lama Android yang pra-tanggal independensi ukuran layar. Implementasi perangkat harus mencakup dukungan untuk mode kompatibilitas aplikasi Legacy seperti yang diimplementasikan oleh kode sumber terbuka Android hulu. Artinya, implementasi perangkat tidak boleh mengubah pemicu atau ambang batas di mana mode kompatibilitas diaktifkan, dan tidak boleh mengubah perilaku mode kompatibilitas itu sendiri.

7.1.6. Jenis layar

Layar implementasi perangkat diklasifikasikan sebagai salah satu dari dua jenis:

Implementasi tampilan pixel tetap: Layar adalah panel tunggal yang hanya mendukung lebar dan tinggi piksel tunggal. Biasanya layar terintegrasi secara fisik dengan perangkat. Contohnya termasuk ponsel, tablet, dan sebagainya.
Implementasi tampilan variabel-pixel: Implementasi perangkat tidak memiliki layar tertanam dan menyertakan port output video seperti VGA, HDMI atau port nirkabel untuk ditampilkan, atau memiliki layar tertanam yang dapat mengubah dimensi piksel. Contohnya termasuk televisi, set-top box, dan sebagainya.

Implementasi Perangkat Pixel Tetap

Implementasi perangkat pixel tetap dapat menggunakan layar dari dimensi piksel apa pun, asalkan mereka memenuhi persyaratan yang ditentukan definisi kompatibilitas ini.

Implementasi pixel tetap dapat mencakup port output video untuk digunakan dengan tampilan eksternal. Namun, jika tampilan itu pernah digunakan untuk menjalankan aplikasi, perangkat harus memenuhi persyaratan berikut:

Perangkat harus melaporkan konfigurasi layar yang sama dan menampilkan metrik, sebagaimana dirinci dalam Bagian 7.1.1 dan 7.1.2, seperti tampilan pixel tetap.
Perangkat harus melaporkan kepadatan logis yang sama dengan tampilan piksel tetap.
Perangkat harus melaporkan dimensi layar yang sama dengan, atau sangat dekat dengan, tampilan piksel tetap.

Misalnya, tablet dengan ukuran diagonal 7 "dengan resolusi 1024x600 piksel dianggap sebagai implementasi tampilan MDPI besar piksel tetap. Jika berisi port output video yang ditampilkan pada 720p atau 1080p, implementasi perangkat harus skala output sehingga yaitu Aplikasi hanya dieksekusi di jendela MDPI besar, terlepas dari apakah tampilan pixel tetap atau port output video sedang digunakan.

Implementasi perangkat variabel-pixel

Implementasi perangkat variabel-pixel harus mendukung salah satu atau keduanya dari 1280x720, atau 1920x1080 (yaitu, 720p atau 1080p). Implementasi perangkat dengan tampilan variabel-pixel tidak boleh mendukung konfigurasi atau mode layar lainnya. Implementasi perangkat dengan layar variabel-pixel dapat mengubah konfigurasi layar atau mode saat runtime atau boot-time. Misalnya, pengguna set-top box dapat menggantikan layar 720p dengan tampilan 1080p, dan implementasi perangkat dapat menyesuaikannya.

Selain itu, implementasi perangkat piksel variabel harus melaporkan ember konfigurasi berikut untuk dimensi piksel ini:

1280x720 (juga dikenal sebagai 720p): ukuran layar 'besar', 'TVDPI' (213 dpi) kepadatan
1920x1080 (juga dikenal sebagai 1080p): ukuran layar 'besar', 'xhdpi' (320 dpi) kepadatan

Untuk kejelasan, implementasi perangkat dengan dimensi piksel variabel dibatasi untuk 720p atau 1080p di Android 4.2, dan harus dikonfigurasi untuk melaporkan ukuran layar dan ember kepadatan seperti disebutkan di atas.

7.1.7. Teknologi Layar

Platform Android mencakup API yang memungkinkan aplikasi untuk membuat grafik yang kaya ke layar. Perangkat harus mendukung semua API ini sebagaimana didefinisikan oleh Android SDK kecuali diizinkan secara khusus dalam dokumen ini. Secara khusus:

Perangkat harus mendukung tampilan yang mampu memberikan grafik warna 16-bit dan harus mendukung tampilan yang mampu dari grafik warna 24-bit.
Perangkat harus mendukung tampilan yang mampu membuat animasi.
Teknologi tampilan yang digunakan harus memiliki rasio aspek piksel (PAR) antara 0,9 dan 1,1. Artinya, rasio aspek piksel harus dekat persegi (1.0) dengan toleransi 10%.

7.1.8. Tampilan eksternal

Android 4.2 termasuk dukungan untuk tampilan sekunder untuk memungkinkan kemampuan berbagi media dan API pengembang untuk mengakses tampilan eksternal. Jika perangkat mendukung tampilan eksternal baik melalui kabel, nirkabel, atau koneksi tampilan tambahan yang disematkan maka implementasi perangkat harus mengimplementasikan API Manajer Tampilan seperti yang dijelaskan dalam dokumentasi Android SDK [ Sumber Daya, 75 ]. Implementasi perangkat yang mendukung output video yang aman dan mampu mendukung permukaan yang aman harus menyatakan dukungan untuk Display.SECURE_FLAG . Secara khusus, implementasi perangkat yang mendeklarasikan dukungan untuk Display.SECURE_FLAG , harus mendukung HDCP 2.x atau lebih tinggi untuk tampilan nirkabel miracast atau HDCP 1.2 atau lebih tinggi untuk tampilan kabel. Implementasi sumber terbuka Android hulu mencakup dukungan untuk tampilan nirkabel (miracast) dan kabel (HDMI) yang memenuhi persyaratan ini.

7.2. Perangkat masukan

7.2.1. Papan ketik

Implementasi Perangkat:

Harus mencakup dukungan untuk kerangka kerja manajemen input (yang memungkinkan pengembang pihak ketiga untuk membuat mesin manajemen input - IE Soft Keyboard) sebagaimana dirinci di http://developer.android.com
Harus memberikan setidaknya satu implementasi keyboard lunak (terlepas dari apakah ada keyboard yang keras)
Mungkin termasuk implementasi keyboard lunak tambahan
Mungkin termasuk keyboard perangkat keras
Tidak boleh menyertakan keyboard perangkat keras yang tidak cocok dengan salah satu format yang ditentukan dalam android.content.res.Configuration.keyboard [ sumber daya, 40 ] (yaitu, qwerty, atau 12-key))

Implementasi Perangkat:

Dapat menghilangkan opsi navigasi non-sentuh (yaitu, dapat menghilangkan trackball, d-pad, atau roda)
Harus melaporkan nilai yang benar untuk android.content.res.Configuration.navigation [ Sumber Daya, 40 ]
Harus memberikan mekanisme antarmuka pengguna alternatif yang masuk akal untuk pemilihan dan pengeditan teks, kompatibel dengan mesin manajemen input. Implementasi sumber terbuka Android hulu mencakup mekanisme pemilihan yang cocok untuk digunakan dengan perangkat yang tidak memiliki input navigasi non-sentuhan.

Fungsi rumah, menu, dan punggung sangat penting untuk paradigma navigasi Android. Implementasi perangkat harus membuat fungsi -fungsi ini tersedia untuk pengguna setiap saat saat menjalankan aplikasi. Fungsi -fungsi ini dapat diimplementasikan melalui tombol fisik khusus (seperti tombol sentuh mekanik atau kapasitif), atau dapat diimplementasikan menggunakan kunci perangkat lunak khusus, gerakan, panel sentuh, dll. Android 4.2 mendukung kedua implementasi.

Android 4.2 termasuk dukungan untuk bantuan bantuan [ Sumber Daya, 63 ]. Implementasi perangkat harus membuat tindakan bantuan tersedia untuk pengguna setiap saat saat menjalankan aplikasi. Fungsi ini dapat diimplementasikan melalui tombol perangkat keras atau perangkat lunak.

Implementasi perangkat dapat menggunakan bagian yang berbeda dari layar untuk menampilkan kunci navigasi, tetapi jika demikian, harus memenuhi persyaratan ini:

Kunci navigasi implementasi perangkat harus menggunakan bagian yang berbeda dari layar, tidak tersedia untuk aplikasi, dan tidak boleh mengaburkan atau mengganggu bagian layar yang tersedia untuk aplikasi.
Implementasi perangkat harus menyediakan sebagian tampilan ke aplikasi yang memenuhi persyaratan yang ditentukan dalam Bagian 7.1.1 .
Implementasi perangkat harus menampilkan tombol navigasi ketika aplikasi tidak menentukan mode Sistem UI, atau menentukan SYSTEM_UI_FLAG_VISIBLE .
Implementasi perangkat harus menyajikan tombol navigasi dalam mode "low profile" (mis. Dimmed) yang tidak mencolok saat aplikasi menentukan SYSTEM_UI_FLAG_LOW_PROFILE .
Implementasi perangkat harus menyembunyikan tombol navigasi saat aplikasi menentukan SYSTEM_UI_FLAG_HIDE_NAVIGATION .
Implementasi perangkat harus menyajikan tombol menu untuk aplikasi saat targetSDKVersion <= 10 dan tidak boleh menyajikan tombol menu saat targetSDKVersion> 10.

7.2.4. Masukan layar sentuh

Implementasi Perangkat:

Harus memiliki sistem input pointer semacam (baik seperti mouse, atau sentuhan)
Mungkin memiliki layar sentuh modalitas apa pun (seperti kapasitif atau resistif)
Harus mendukung pointer yang dilacak secara mandiri sepenuhnya, jika layar sentuh mendukung beberapa pointer
Harus melaporkan nilai android.content.res.Configuration [ sumber daya, 39 ] yang mencerminkan sesuai dengan jenis layar sentuh spesifik pada perangkat

Implementasi perangkat harus melaporkan fitur yang benar sesuai dengan jenis input yang digunakan. Perhatikan bahwa Android 4.2 mencakup fitur android.hardware.faketouch , yang sesuai dengan perangkat input non-sentuh (yaitu, pointer-berbasis pointer) seperti mouse atau trackpad yang dapat secara memadai dapat meniru input berbasis sentuh (termasuk dasar Dukungan Gesture), dan menunjukkan bahwa perangkat mendukung subset yang ditiru dari fungsi layar sentuh. Implementasi perangkat yang menyertakan layar sentuh (sentuhan tunggal atau lebih baik) juga harus melaporkan android.hardware.faketouch. Implementasi perangkat yang tidak termasuk layar sentuh (dan hanya mengandalkan perangkat pointer) tidak boleh melaporkan fitur layar sentuh, dan hanya harus melaporkan android.hardware.faketouch .

7.2.5. Mikropon

Implementasi perangkat dapat menghilangkan mikrofon. Namun, jika implementasi perangkat menghilangkan mikrofon , ia tidak boleh melaporkan android.hardware.microphone . Sebaliknya, implementasi perangkat yang memiliki mikrofon:

Harus melaporkan konstanta fitur android.hardware.microphone
Harus memenuhi persyaratan kualitas audio di Bagian 5.4
Harus memenuhi persyaratan latensi audio di Bagian 5.5

7.3. Sensor

Android 4.2 termasuk API untuk mengakses berbagai jenis sensor. Implementasi perangkat umumnya dapat menghilangkan sensor -sensor ini, sebagaimana ditentukan dalam subbagian berikut. Jika perangkat menyertakan jenis sensor tertentu yang memiliki API yang sesuai untuk pengembang pihak ketiga, implementasi perangkat harus menerapkan API itu seperti yang dijelaskan dalam dokumentasi Android SDK. Misalnya, implementasi perangkat:

Harus secara akurat melaporkan ada atau tidak adanya sensor sesuai kelas android.content.pm.PackageManager . [ Sumber Daya, 37 ]
Harus mengembalikan daftar sensor yang didukung yang akurat melalui SensorManager.getSensorList() dan metode serupa
Harus berperilaku wajar untuk semua API sensor lainnya (misalnya, dengan mengembalikan true atau false yang sesuai ketika aplikasi mencoba mendaftarkan pendengar, tidak memanggil pendengar sensor ketika sensor yang sesuai tidak ada; dll.)
Harus melaporkan semua pengukuran sensor menggunakan sistem unit internasional yang relevan (yaitu metrik) nilai untuk setiap jenis sensor sebagaimana didefinisikan dalam dokumentasi Android SDK [ Sumber Daya, 41 ]

Daftar di atas tidak komprehensif; Perilaku yang terdokumentasi dari Android SDK akan dianggap otoritatif.

Beberapa jenis sensor bersifat sintetis, artinya mereka dapat diturunkan dari data yang disediakan oleh satu atau lebih sensor lainnya. (Contohnya termasuk sensor orientasi, dan sensor akselerasi linier.) Implementasi perangkat harus mengimplementasikan jenis sensor ini, ketika mereka memasukkan sensor fisik prasyarat.

Android 4.2 mencakup gagasan sensor "streaming", yang merupakan yang mengembalikan data secara terus menerus, daripada hanya ketika data berubah. Implementasi perangkat harus terus memberikan sampel data periodik untuk setiap API yang ditunjukkan oleh Dokumentasi Android 4.2 SDK untuk menjadi sensor streaming. Perhatikan bahwa implementasi perangkat harus memastikan bahwa aliran sensor tidak boleh mencegah perangkat CPU memasuki status penangguhan atau bangun dari keadaan penangguhan.

7.3.1. Akselerometer

Implementasi perangkat harus mencakup accelerometer 3-sumbu. Jika implementasi perangkat mencakup accelerometer 3-sumbu, itu:

Harus dapat menyampaikan acara di 120 Hz atau lebih besar. Perhatikan bahwa sementara frekuensi accelerometer di atas dinyatakan sebagai "harus" untuk Android 4.2, definisi kompatibilitas untuk versi masa depan direncanakan untuk mengubahnya menjadi "harus". Artinya, standar -standar ini opsional di Android 4.2 tetapi akan diperlukan dalam versi mendatang. Perangkat yang ada dan baru yang menjalankan Android 4.2 sangat dianjurkan untuk memenuhi persyaratan ini di Android 4.2 sehingga mereka akan dapat meningkatkan ke rilis platform masa depan
Harus mematuhi sistem koordinat sensor android sebagaimana dirinci di API Android (lihat [ Sumber Daya, 41 ])
Harus mampu mengukur dari jatuh bebas hingga dua kali gravitasi (2g) atau lebih pada vektor tiga dimensi
Harus memiliki akurasi 8-bit atau lebih
Harus memiliki standar deviasi yang tidak lebih dari 0,05 m/s^2

7.3.2. magnetometer

Implementasi perangkat harus mencakup magnetometer 3-sumbu (IE Compass.) Jika suatu perangkat mencakup magnetometer 3-sumbu, itu:

Harus dapat memberikan acara pada 10 Hz atau lebih besar
Harus mematuhi sistem koordinat sensor android sebagaimana dirinci dalam API Android (lihat [ Sumber Daya, 41 ]).
Harus mampu mencicipi berbagai kekuatan medan yang memadai untuk menutupi bidang geomagnetik
Harus memiliki akurasi 8-bit atau lebih
Harus memiliki standar deviasi yang tidak lebih dari 0,5 μt

7.3.3. GPS

Implementasi perangkat harus mencakup penerima GPS. Jika implementasi perangkat mencakup penerima GPS, itu harus mencakup beberapa bentuk teknik "GPS dibantu" untuk meminimalkan waktu penguncian GPS.

7.3.4. Giroskop

Implementasi perangkat harus mencakup perangkat giroskop (yaitu sensor perubahan sudut.) Perangkat tidak boleh menyertakan sensor giroskop kecuali jika akselerometer 3-sumbu juga disertakan. Jika implementasi perangkat menyertakan giroskop, itu:

Harus dikompensasi suhu
Harus mampu mengukur perubahan orientasi hingga 5,5*pi radian/detik (yaitu, sekitar 1.000 derajat per detik)
Harus dapat memberikan acara pada 200 Hz atau lebih besar. Perhatikan bahwa sementara frekuensi giroskop di atas dinyatakan sebagai "harus" untuk Android 4.2, definisi kompatibilitas untuk versi masa depan direncanakan untuk mengubahnya menjadi "harus". Artinya, standar -standar ini opsional di Android 4.2 tetapi akan diperlukan dalam versi mendatang. Perangkat yang ada dan baru yang menjalankan Android 4.2 sangat dianjurkan untuk memenuhi persyaratan ini di Android 4.2 sehingga mereka akan dapat meningkatkan ke rilis platform masa depan
Harus memiliki akurasi 12-bit atau lebih
Harus memiliki varians tidak lebih dari 1e-7 rad^2 / s^2 per Hz (varians per Hz, atau rad^2 / s). Varians dibiarkan bervariasi dengan laju pengambilan sampel, tetapi harus dibatasi oleh nilai ini. Dengan kata lain, jika Anda mengukur varian gyro pada 1 Hz laju pengambilan sampel, maka tidak akan lebih besar dari 1e-7 rad^2/s^2.
Harus memiliki cap waktu sedekat mungkin ketika peristiwa perangkat keras terjadi. Latensi konstan harus dihapus.

7.3.5. Barometer

Implementasi perangkat dapat mencakup barometer (yaitu sensor tekanan udara ambient.) Jika implementasi perangkat mencakup barometer, itu:

Harus dapat menyampaikan acara di 5 Hz atau lebih besar
Harus memiliki ketepatan yang memadai untuk memungkinkan memperkirakan ketinggian
Harus dikompensasi suhu

7.3.7. Termometer

Implementasi perangkat mungkin tetapi tidak boleh menyertakan termometer (yaitu sensor suhu.) Jika implementasi perangkat mencakup termometer, ia harus mengukur suhu CPU perangkat. Itu tidak boleh mengukur suhu lain. (Perhatikan bahwa jenis sensor ini sudah usang di Android 4.2 API.)

7.3.7. Fotometer

Implementasi perangkat dapat mencakup fotometer (yaitu sensor cahaya ambient.)

7.3.8. Sensor jarak

Implementasi perangkat dapat mencakup sensor kedekatan. Jika implementasi perangkat mencakup sensor kedekatan, ia harus mengukur kedekatan objek dalam arah yang sama dengan layar. Artinya, sensor kedekatan harus berorientasi untuk mendeteksi objek yang dekat dengan layar, karena maksud utama dari jenis sensor ini adalah untuk mendeteksi telepon yang digunakan oleh pengguna. Jika implementasi perangkat mencakup sensor kedekatan dengan orientasi lain, itu tidak boleh diakses melalui API ini. Jika implementasi perangkat memiliki sensor kedekatan, ia harus memiliki akurasi 1-bit atau lebih.

7.4. Konektivitas Data

7.4.1. Telepon

"Telepon" seperti yang digunakan oleh Android 4.2 API dan dokumen ini mengacu secara khusus pada perangkat keras yang terkait dengan menempatkan panggilan suara dan mengirim pesan SMS melalui jaringan GSM atau CDMA. Meskipun panggilan suara ini mungkin atau mungkin tidak di masukan, mereka untuk keperluan Android 4.2 yang dianggap independen dari konektivitas data apa pun yang dapat diimplementasikan menggunakan jaringan yang sama. Dengan kata lain, fungsionalitas "telepon" android dan API merujuk secara khusus untuk panggilan suara dan SMS; Misalnya, implementasi perangkat yang tidak dapat melakukan panggilan atau mengirim/menerima pesan SMS tidak boleh melaporkan fitur "android.hardware.telephony" atau sub-fitur apa pun, terlepas dari apakah mereka menggunakan jaringan seluler untuk konektivitas data.

Android 4.2 dapat digunakan pada perangkat yang tidak termasuk perangkat keras telepon. Artinya, Android 4.2 kompatibel dengan perangkat yang bukan telepon. Namun, jika implementasi perangkat mencakup telepon GSM atau CDMA, ia harus menerapkan dukungan penuh untuk API untuk teknologi itu. Implementasi perangkat yang tidak termasuk perangkat keras telepon harus mengimplementasikan API penuh sebagai tidak ada ops.

7.4.2. IEEE 802.11 (WiFi)

Implementasi perangkat Android 4.2 harus mencakup dukungan untuk satu atau lebih bentuk 802.11 (b/g/a/n, dll.) Jika implementasi perangkat memang mencakup dukungan untuk 802.11, ia harus mengimplementasikan API Android yang sesuai.

Implementasi perangkat harus mengimplementasikan API multicast seperti yang dijelaskan dalam dokumentasi SDK [ Sumber Daya, 62 ]. Implementasi perangkat yang mencakup dukungan WiFi harus mendukung DNS multicast (MDNS). Implementasi perangkat tidak boleh memfilter paket MDNS (224.0.0.251) setiap saat operasi termasuk ketika layar tidak dalam keadaan aktif.

7.4.2.1. Wi-Fi Langsung

Implementasi perangkat harus mencakup dukungan untuk WiFi Direct (wifi peer-to-peer). Jika implementasi perangkat mencakup dukungan untuk WiFi Direct, ia harus mengimplementasikan API Android yang sesuai seperti yang dijelaskan dalam dokumentasi SDK [ Sumber Daya, 68 ]. Jika implementasi perangkat mencakup dukungan untuk WiFi Direct, maka itu:

Harus mendukung operasi wifi reguler
Harus mendukung operasi langsung WiFi dan WiFi bersamaan

7.4.3. Bluetooth

Implementasi perangkat harus mencakup transceiver Bluetooth. Implementasi perangkat yang mencakup transceiver Bluetooth harus memungkinkan Bluetooth API berbasis RFCOMM seperti yang dijelaskan dalam dokumentasi SDK [ Sumber Daya, 42 ]. Implementasi perangkat harus mengimplementasikan profil Bluetooth yang relevan, seperti A2DP, AVRCP, OBEX, dll. Sesuai untuk perangkat.

Rangkaian uji kompatibilitas mencakup kasus yang mencakup operasi dasar API Android RFComm Bluetooth. Namun, karena Bluetooth adalah protokol komunikasi antar perangkat, ia tidak dapat sepenuhnya diuji dengan unit tes yang berjalan pada satu perangkat. Akibatnya, implementasi perangkat juga harus melewati prosedur uji Bluetooth yang digerakkan manusia yang dijelaskan dalam Lampiran A.

7.4.4. Komunikasi dekat lapangan

Implementasi perangkat harus mencakup transceiver dan perangkat keras terkait untuk komunikasi dekat-lapangan (NFC). Jika implementasi perangkat mencakup perangkat keras NFC, maka itu:

Harus melaporkan fitur android.hardware.nfc dari metode android.content.pm.PackageManager.hasSystemFeature() . [ Sumber Daya, 37 ]
Harus mampu membaca dan menulis pesan NDEF melalui standar NFC berikut:
- Harus mampu bertindak sebagai pembaca/penulis forum NFC (sebagaimana didefinisikan oleh spesifikasi teknis Forum NFC NFCFORUM-TS-DigitalProtocol-1.0) melalui standar NFC berikut:
  - NFCA (ISO14443-3A)
  - NFCB (ISO14443-3B)
  - NFCF (JIS 6319-4)
  - Isodep (ISO 14443-4)
  - Jenis Tag Forum NFC 1, 2, 3, 4 (ditentukan oleh Forum NFC)
Harus mampu membaca dan menulis pesan NDEF melalui standar NFC berikut. Perhatikan bahwa sementara standar NFC di bawah ini dinyatakan sebagai "harus" untuk Android 4.2, definisi kompatibilitas untuk versi masa depan direncanakan untuk mengubah ini menjadi "harus". Artinya, standar -standar ini opsional di Android 4.2 tetapi akan diperlukan dalam versi mendatang. Perangkat yang ada dan baru yang menjalankan Android 4.2 sangat dianjurkan untuk memenuhi persyaratan ini di Android 4.2 sehingga mereka akan dapat meningkatkan ke rilis platform di masa depan.
- NFCV (ISO 15693)
Harus mampu mentransmisikan dan menerima data melalui standar dan protokol peer-to-peer berikut:
- ISO 18092
- LLCP 1.0 (ditentukan oleh forum NFC)
- SDP 1.0 (ditentukan oleh forum NFC)
- Protokol Push NDEF [ Sumber Daya, 43 ]
- Snep 1.0 (ditentukan oleh forum NFC)
Harus menyertakan dukungan untuk balok android [ sumber daya, 65 ]:
- Harus mengimplementasikan server default snep. Valid NDEF messages received by the default SNEP server MUST be dispatched to applications using the android.nfc.ACTION_NDEF_DISCOVERED intent. Disabling Android Beam in settings MUST NOT disable dispatch of incoming NDEF message.
- Device implementations MUST honor the android.settings.NFCSHARING_SETTINGS intent to show NFC sharing settings [ Resources, 67 ].
- MUST implement the NPP server. Messages received by the NPP server MUST be processed the same way as the SNEP default server.
- MUST implement a SNEP client and attempt to send outbound P2P NDEF to the default SNEP server when Android Beam is enabled. If no default SNEP server is found then the client MUST attempt to send to an NPP server.
- MUST allow foreground activities to set the outbound P2P NDEF message using android.nfc.NfcAdapter.setNdefPushMessage, and android.nfc.NfcAdapter.setNdefPushMessageCallback, and android.nfc.NfcAdapter.enableForegroundNdefPush.
- SHOULD use a gesture or on-screen confirmation, such as 'Touch to Beam', before sending outbound P2P NDEF messages.
- SHOULD enable Android Beam by default
- MUST support NFC Connection handover to Bluetooth when the device supports Bluetooth Object Push Profile. Device implementations must support connection handover to Bluetooth when using android.nfc.NfcAdapter.setBeamPushUris, by implementing the "Connection Handover version 1.2" [ Resources, 60 ] and "Bluetooth Secure Simple Pairing Using NFC version 1.0" [ Resources, 61 ] specs from Forum NFC. Such an implementation SHOULD use SNEP GET requests for exchanging the handover request / select records over NFC, and it MUST use the Bluetooth Object Push Profile for the actual Bluetooth data transfer.
MUST poll for all supported technologies while in NFC discovery mode.
SHOULD be in NFC discovery mode while the device is awake with the screen active and the lock-screen unlocked.

(Note that publicly available links are not available for the JIS, ISO, and NFC Forum specifications cited above.)

Additionally, device implementations MAY include reader/writer support for the following MIFARE technologies.

MIFARE Classic (NXP MF1S503x [ Resources, 44 ], MF1S703x [ Resources, 44 ])
MIFARE Ultralight (NXP MF0ICU1 [ Resources, 46 ], MF0ICU2 [ Resources, 46 ])
NDEF on MIFARE Classic (NXP AN130511 [ Resources, 48 ], AN130411 [ Resources, 49 ])

Note that Android 4.2 includes APIs for these MIFARE types. If a device implementation supports MIFARE in the reader/writer role, it:

MUST implement the corresponding Android APIs as documented by the Android SDK
MUST report the feature com.nxp.mifare from the android.content.pm.PackageManager.hasSystemFeature() method. [ Resources, 37 ] Note that this is not a standard Android feature, and as such does not appear as a constant on the PackageManager class.
MUST NOT implement the corresponding Android APIs nor report the com.nxp.mifare feature unless it also implements general NFC support as described in this section

If a device implementation does not include NFC hardware, it MUST NOT declare the android.hardware.nfc feature from the android.content.pm.PackageManager.hasSystemFeature() method [ Resources, 37 ], and MUST implement the Android 4.2 NFC API as a no-op.

As the classes android.nfc.NdefMessage and android.nfc.NdefRecord represent a protocol-independent data representation format, device implementations MUST implement these APIs even if they do not include support for NFC or declare the android.hardware.nfc feature.

7.4.5. Minimum Network Capability

Device implementations MUST include support for one or more forms of data networking. Specifically, device implementations MUST include support for at least one data standard capable of 200Kbit/sec or greater. Examples of technologies that satisfy this requirement include EDGE, HSPA, EV-DO, 802.11g, Ethernet, etc.

Device implementations where a physical networking standard (such as Ethernet) is the primary data connection SHOULD also include support for at least one common wireless data standard, such as 802.11 (WiFi).

Devices MAY implement more than one form of data connectivity.

7.5. Kamera

Device implementations SHOULD include a rear-facing camera, and MAY include a front-facing camera. A rear-facing camera is a camera located on the side of the device opposite the display; that is, it images scenes on the far side of the device, like a traditional camera. A front-facing camera is a camera located on the same side of the device as the display; that is, a camera typically used to image the user, such as for video conferencing and similar applications.

7.5.1. Rear-Facing Camera

Device implementations SHOULD include a rear-facing camera. If a device implementation includes a rear-facing camera, it:

Harus memiliki resolusi setidaknya 2 megapiksel
Harus memiliki fokus otomatis perangkat keras, atau fokus otomatis perangkat lunak yang diimplementasikan di driver kamera (transparan ke perangkat lunak aplikasi)
Mungkin memiliki fokus tetap atau perangkat keras EDOF (kedalaman panjang bidang)
Mungkin termasuk flash. Jika kamera menyertakan FLASH_MODE_AUTO FLASH_MODE_ON lampu flash tidak boleh menyala saat instance android Objek Camera.Parameters . Perhatikan bahwa kendala ini tidak berlaku untuk aplikasi kamera sistem bawaan perangkat, tetapi hanya untuk aplikasi pihak ketiga menggunakan Camera.PreviewCallback .

7.5.2. Kamera Menghadap Depan

Implementasi perangkat dapat mencakup kamera yang menghadap ke depan. If a device implementation includes a front-facing camera, it:

MUST have a resolution of at least VGA (that is, 640x480 pixels)
MUST NOT use a front-facing camera as the default for the Camera API. That is, the camera API in Android 4.2 has specific support for front-facing cameras, and device implementations MUST NOT configure the API to to treat a front-facing camera as the default rear-facing camera, even if it is the only camera on perangkat.
MAY include features (such as auto-focus, flash, etc.) available to rear-facing cameras as described in Section 7.5.1.
MUST horizontally reflect (ie mirror) the stream displayed by an app in a CameraPreview, as follows:

If the device implementation is capable of being rotated by user (such as automatically via an accelerometer or manually via user input), the camera preview MUST be mirrored horizontally relative to the device's current orientation.
If the current application has explicitly requested that the Camera display be rotated via a call to the android.hardware.Camera.setDisplayOrientation() [ Resources, 50 ] method, the camera preview MUST be mirrored horizontally relative to the orientation specified by the application.
Otherwise, the preview MUST be mirrored along the device's default horizontal axis.

MUST mirror the image displayed by the postview in the same manner as the camera preview image stream. (If the device implementation does not support postview, this requirement obviously does not apply.)
MUST NOT mirror the final captured still image or video streams returned to application callbacks or committed to media storage

7.5.3. Camera API Behavior

Device implementations MUST implement the following behaviors for the camera-related APIs, for both front- and rear-facing cameras:

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.
Jika suatu aplikasi mendaftarkan instance android.hardware.Camera.PreviewCallback dan sistem memanggil metode onPreviewFrame() ketika format pratinjau adalah ycbcr_420_sp, data dalam byte[] diteruskan ke onPreviewFrame() harus lebih jauh dalam format encoding NV21. That is, NV21 MUST be the default.
Device implementations MUST support the YV12 format (as denoted by the android.graphics.ImageFormat.YV12 constant) for camera previews for both front- and rear-facing cameras. (The hardware video encoder and camera may use any native pixel format, but the device implementation MUST support conversion to YV12.)

Device implementations MUST implement the full Camera API included in the Android 4.2 SDK documentation [ Resources, 51 ]), regardless of whether the device includes hardware autofocus or other capabilities. For instance, cameras that lack autofocus MUST still call any registered android.hardware.Camera.AutoFocusCallback instances (even though this has no relevance to a non-autofocus camera.) Note that this does apply to front-facing cameras; for instance, even though most front-facing cameras do not support autofocus, the API callbacks must still be "faked" as described.

Implementasi perangkat harus mengenali dan menghormati setiap nama parameter yang didefinisikan sebagai konstan pada kelas android.hardware.Camera.Parameters , jika perangkat keras yang mendasarinya mendukung fitur tersebut. Jika perangkat keras perangkat tidak mendukung fitur, API harus berperilaku seperti yang didokumentasikan. Sebaliknya, implementasi perangkat tidak boleh menghormati atau mengenali konstanta string yang diteruskan ke metode android.hardware.Camera.setParameters() selain yang didokumentasikan sebagai konstanta di android.hardware.Camera.Parameters . Artinya, implementasi perangkat harus mendukung semua parameter kamera standar jika perangkat keras memungkinkan, dan tidak boleh mendukung jenis parameter kamera khusus. For instance, device implementations that support image capture using high dynamic range (HDR) imaging techniques MUST support camera parameter Camera.SCENE_MODE_HDR [ Resources, 78 ]).

Device implementations MUST broadcast the Camera.ACTION_NEW_PICTURE intent whenever a new picture is taken by the camera and the entry of the picture has been added to the media store.

Device implementations MUST broadcast the Camera.ACTION_NEW_VIDEO intent whenever a new video is recorded by the camera and the entry of the picture has been added to the media store.

7.5.4. Camera Orientation

Both front- and rear-facing cameras, if present, MUST be oriented so that the long dimension of the camera aligns with the screen's long dimension. That is, when the device is held in the landscape orientation, cameras MUST capture images in the landscape orientation. This applies regardless of the device's natural orientation; that is, it applies to landscape-primary devices as well as portrait-primary devices.

7.6. Memori dan Penyimpanan

7.6.1. Minimum Memory and Storage

Device implementations MUST have at least 340MB of memory available to the kernel and userspace. The 340MB MUST be in addition to any memory dedicated to hardware components such as radio, video, and so on that is not under the kernel's control.

Device implementations MUST have at least 350MB of non-volatile storage available for application private data. That is, the /data partition MUST be at least 350MB.

The Android APIs include a Download Manager that applications may use to download data files [ Resources, 56 ]. The device implementation of the Download Manager MUST be capable of downloading individual files of at least 100MB in size to the default "cache" location.

7.6.2. Penyimpanan Bersama Aplikasi

Implementasi perangkat harus menawarkan penyimpanan bersama untuk aplikasi. The shared storage provided MUST be at least 1GB in size.

Implementasi perangkat harus dikonfigurasi dengan penyimpanan bersama yang dipasang secara default, "di luar kotak". Jika penyimpanan bersama tidak dipasang pada jalur Linux /sdcard , maka perangkat harus menyertakan tautan simbolik Linux dari /sdcard ke titik pemasangan yang sebenarnya.

Implementasi perangkat harus menegakkan seperti yang didokumentasikan izin android.permission.WRITE_EXTERNAL_STORAGE pada penyimpanan bersama ini. Penyimpanan bersama harus dapat ditulis dengan aplikasi apa pun yang memperoleh izin itu.

Implementasi perangkat mungkin memiliki perangkat keras untuk penyimpanan yang dapat dilepas yang dapat diakses pengguna, seperti kartu digital yang aman. Atau, implementasi perangkat dapat mengalokasikan penyimpanan internal (tidak dapat dilepas) sebagai penyimpanan bersama untuk aplikasi.

Regardless of the form of shared storage used, device implementations MUST provide some mechanism to access the contents of shared storage from a host computer, such as USB mass storage (UMS) or Media Transfer Protocol (MTP). Device implementations MAY use USB mass storage, but SHOULD use Media Transfer Protocol. If the device implementation supports Media Transfer Protocol:

The device implementation SHOULD be compatible with the reference Android MTP host, Android File Transfer [ Resources, 57 ].
The device implementation SHOULD report a USB device class of 0x00 .
The device implementation SHOULD report a USB interface name of 'MTP'.

If the device implementation lacks USB ports, it MUST provide a host computer with access to the contents of shared storage by some other means, such as a network file system.

Ini adalah ilustratif untuk mempertimbangkan dua contoh umum. If a device implementation includes an SD card slot to satisfy the shared storage requirement, a FAT-formatted SD card 1GB in size or larger MUST be included with the device as sold to users, and MUST be mounted by default. Alternatively, if a device implementation uses internal fixed storage to satisfy this requirement, that storage MUST be 1GB in size or larger and mounted on /sdcard (or /sdcard MUST be a symbolic link to the physical location if it is mounted elsewhere.)

Implementasi perangkat yang mencakup beberapa jalur penyimpanan bersama (seperti slot kartu SD dan penyimpanan internal bersama) harus memodifikasi aplikasi inti seperti pemindai media dan contentProvider untuk mendukung file yang ditempatkan di kedua lokasi secara transparan.

7.7. USB

Device implementations SHOULD include a USB client port, and SHOULD include a USB host port.

If a device implementation includes a USB client port:

the port MUST be connectable to a USB host with a standard USB-A port
the port SHOULD use the micro USB form factor on the device side. Existing and new devices that run Android 4.2 are very strongly encouraged to meet these requirements in Android 4.2 so they will be able to upgrade to the future platform releases
the port SHOULD be centered in the middle of an edge. Device implementations SHOULD either locate the port on the bottom of the device (according to natural orientation) or enable software screen rotation for all apps (including home screen), so that the display draws correctly when the device is oriented with the port at bottom. Existing and new devices that run Android 4.2 are very strongly encouraged to meet these requirements in Android 4.2 so they will be able to upgrade to future platform releases.
if the device has other ports (such as a non-USB charging port) it SHOULD be on the same edge as the micro-USB port
it MUST allow a host connected to the device to access the contents of the shared storage volume using either USB mass storage or Media Transfer Protocol
it MUST implement the Android Open Accessory API and specification as documented in the Android SDK documentation, and MUST declare support for the hardware feature android.hardware.usb.accessory [ Resources, 52 ]
it MUST implement the USB audio class as documented in the Android SDK documentation [ Resources, 66 ]
it SHOULD implement support for USB battery charging specification [ Resources, 64 ] Existing and new devices that run Android 4.2 are very strongly encouraged to meet these requirements in Android 4.2 so they will be able to upgrade to the future platform releases

If a device implementation includes a USB host port:

it MAY use a non-standard port form factor, but if so MUST ship with a cable or cables adapting the port to standard USB-A
it MUST implement the Android USB host API as documented in the Android SDK, and MUST declare support for the hardware feature android.hardware.usb.host [ Resources, 53 ]

Device implementations MUST implement the Android Debug Bridge. If a device implementation omits a USB client port, it MUST implement the Android Debug Bridge via local-area network (such as Ethernet or 802.11)

8. Performance Compatibility

Device implementations MUST meet the key performance metrics of an Android 4.2 compatible device defined in the table below:

Metrik	Ambang kinerja	Komentar
Waktu peluncuran aplikasi	Aplikasi berikut harus diluncurkan dalam waktu yang ditentukan. Browser: kurang dari 1300ms Contacts: less than 700ms Settings: less than 700ms	Waktu peluncuran diukur sebagai total waktu untuk menyelesaikan pemuatan aktivitas default untuk aplikasi, termasuk waktu yang diperlukan untuk memulai proses Linux, memuat paket Android ke Dalvik VM, dan memanggil OnCreate.
Aplikasi simultan	Ketika beberapa aplikasi telah diluncurkan, meluncurkan kembali aplikasi yang sudah berjalan setelah diluncurkan harus memakan waktu kurang dari waktu peluncuran asli.

9. 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, 54 ] in the Android developer documentation. Implementasi perangkat harus mendukung pemasangan aplikasi yang ditandatangani sendiri tanpa memerlukan izin/sertifikat tambahan dari pihak ketiga/otoritas mana pun. Secara khusus, perangkat yang kompatibel harus mendukung mekanisme keamanan yang dijelaskan dalam sub-bagian berikut.

9.1. Izin

Device implementations MUST support the Android permissions model as defined in the Android developer documentation [ Resources, 54 ]. Secara khusus, implementasi harus menegakkan setiap izin yang ditentukan seperti yang dijelaskan dalam dokumentasi SDK; Tidak ada izin yang dapat dihilangkan, diubah, atau diabaikan. Implementasi dapat menambahkan izin tambahan, asalkan string ID izin baru tidak ada di Android.* Namespace.

9.2. UID dan Isolasi Proses

Implementasi perangkat harus mendukung model Sandbox Aplikasi Android, di mana setiap aplikasi berjalan sebagai UID gaya Unix yang unik dan dalam proses yang terpisah. 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, 54 ].

9.3. Izin Sistem File

Device implementations MUST support the Android file access permissions model as defined in as defined in the Security and Permissions reference [ Resources, 54 ].

9.4. Lingkungan Eksekusi Alternatif

Implementasi perangkat dapat mencakup lingkungan runtime yang menjalankan aplikasi menggunakan beberapa perangkat lunak atau teknologi lain selain mesin virtual Dalvik atau kode asli. Namun, lingkungan eksekusi alternatif seperti itu tidak boleh mengkompromikan model keamanan Android atau keamanan aplikasi Android yang diinstal, seperti yang dijelaskan dalam bagian ini.

Alternate runtimes MUST themselves be Android applications, and abide by the standard Android security model, as described elsewhere in Section 9.

Runtime alternatif tidak boleh diberikan akses ke sumber daya yang dilindungi oleh izin yang tidak diminta dalam file runtime androidmanifest.xml melalui mekanisme <uses-permission> .

Runtime alternatif tidak boleh mengizinkan aplikasi untuk menggunakan fitur yang dilindungi oleh izin android yang terbatas pada aplikasi sistem.

Runtime alternatif harus mematuhi model Android Sandbox. Secara khusus:

Alternatif RunTimes harus menginstal aplikasi melalui PackageManager ke kotak pasir Android yang terpisah (yaitu, ID Pengguna Linux, dll.)
Alternate runtimes MAY provide a single Android sandbox shared by all applications using the alternate runtime
Alternatif runtime dan aplikasi yang diinstal menggunakan runtime alternatif tidak boleh menggunakan kembali kotak pasir dari aplikasi lain yang diinstal pada perangkat, kecuali melalui mekanisme android standar ID pengguna bersama dan sertifikat penandatanganan
Alternate runtimes MUST NOT launch with, grant, or be granted access to the sandboxes corresponding to other Android applications

Runtime alternatif tidak boleh diluncurkan dengan, diberikan, atau diberikan kepada aplikasi lain setiap hak istimewa superuser (root), atau ID pengguna lainnya.

File .apk dari runtime alternatif dapat dimasukkan dalam gambar sistem implementasi perangkat, tetapi harus ditandatangani dengan kunci yang berbeda dari kunci yang digunakan untuk menandatangani aplikasi lain yang disertakan dengan implementasi perangkat.

Saat menginstal aplikasi, runtime alternatif harus mendapatkan persetujuan pengguna untuk izin Android yang digunakan oleh aplikasi. Yaitu, jika aplikasi perlu memanfaatkan sumber daya perangkat yang ada izin Android yang sesuai (seperti kamera, GPS, dll.), Runtime alternatif harus memberi tahu pengguna bahwa aplikasi akan dapat mengakses sumber daya itu . Jika lingkungan runtime tidak merekam kemampuan aplikasi dengan cara ini, lingkungan runtime harus mencantumkan semua izin yang dipegang oleh runtime itu sendiri saat menginstal aplikasi apa pun menggunakan runtime itu.

9.5. Dukungan Multi-Pengguna

Android 4.2 includes support for multiple users and provides support for full user isolation [ Resources, 70 ].

Device implementations MUST meet these requirements related to multi-user support[ Resources, 71 ]:

As the behavior of the telephony APIs on devices with multiple users is currently undefined, device implementations that declare android.hardware.telephony MUST NOT enable multi-user support.
Device implementations MUST, for each user, implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [Resources, 54]

Each user instance on an Android device MUST have separate and isolated external storage directories. Device implementations MAY store multiple users' data on the same volume or filesystem. However, the device implementation MUST ensure that applications owned by and running on behalf a given user cannot list, read, or write to data owned by any other user. Note that removable media, such as SD card slots, can allow one user to access another's data by means of a host PC. For this reason, device implementations that use removable media for the external storage APIs MUST encrypt the contents of the SD card if multi-user is enabled using a key stored only on non-removable media accessible only to the system. As this will make the media unreadable by a host PC, device implementations will be required to switch to MTP or a similar system to provide host PCs with access to the current user's data. Accordingly, device implementations MAY but SHOULD NOT enable multi-user if they use removable media [ Resources, 72 ] for primary external storage. The upstream Android open-source project includes an implementation that uses internal device storage for application external storage APIs; device implementations SHOULD use this configuration and software implementation. Device implementations that include multiple external storage paths MUST NOT allow Android applications to write to the secondary external storage

9.6. Premium SMS Warning

Android 4.2 includes support for warning users for any outgoing premium SMS message. Premium SMS messages are text messages sent to a service registered with a carrier that may incur a charge to the user. Device implementations that declare support for android.hardware.telephony MUST warn users before sending a SMS message to numbers identified by regular expressions defined in /data/misc/sms/codes.xml file in the device. The upstream Android open-source project provides an implementation that satisfies this requirement.

10. Software Compatibility Testing

Device implementations MUST pass all tests described in this section.

However, note that no software test package is fully comprehensive. For this reason, device implementers are very strongly encouraged to make the minimum number of changes as possible to the reference and preferred implementation of Android 4.2 available from the Android Open Source Project. This will minimize the risk of introducing bugs that create incompatibilities requiring rework and potential device updates.

10.1. Compatibility Test Suite

Implementasi perangkat harus melewati Android Compatibility Test Suite (CTS) [ Sumber Daya, 2 ] yang tersedia dari proyek Open Source Android, menggunakan perangkat lunak pengiriman akhir pada perangkat. Selain itu, pelaksana perangkat harus menggunakan implementasi referensi di pohon open source Android sebanyak mungkin, dan harus memastikan kompatibilitas dalam kasus ambiguitas dalam CTS dan untuk setiap penerimaan kembali bagian -bagian dari kode sumber referensi.

CTS dirancang untuk dijalankan pada perangkat yang sebenarnya. Seperti halnya perangkat lunak apa pun, CTS itu sendiri mungkin mengandung bug. The CTS will be versioned independently of this Compatibility Definition, and multiple revisions of the CTS may be released for Android 4.2. Implementasi perangkat harus lulus versi CTS terbaru yang tersedia pada saat perangkat lunak perangkat selesai.

10.2. Pemverifikasi CTS

Device implementations MUST correctly execute all applicable cases in the CTS Verifier. The CTS Verifier is included with the Compatibility Test Suite, and is intended to be run by a human operator to test functionality that cannot be tested by an automated system, such as correct functioning of a camera and sensors.

The CTS Verifier has tests for many kinds of hardware, including some hardware that is optional. Device implementations MUST pass all tests for hardware which they possess; for instance, if a device possesses an accelerometer, it MUST correctly execute the Accelerometer test case in the CTS Verifier. Test cases for features noted as optional by this Compatibility Definition Document MAY be skipped or omitted.

Every device and every build MUST correctly run the CTS Verifier, as noted above. However, since many builds are very similar, device implementers are not expected to explicitly run the CTS Verifier on builds that differ only in trivial ways. Specifically, device implementations that differ from an implementation that has passed the CTS Verfier only by the set of included locales, branding, etc. MAY omit the CTS Verifier test.

10.3. Reference Applications

Device implementers MUST test implementation compatibility using the following open source applications:

The "Apps for Android" applications [ Resources, 55 ]
Replica Island (available in Android Market)

Setiap aplikasi di atas HARUS diluncurkan dan berperilaku benar pada implementasinya, agar implementasinya dianggap kompatibel.

11. Updatable Software

Implementasi perangkat harus mencakup mekanisme untuk menggantikan keseluruhan perangkat lunak sistem. The mechanism need not perform "live" upgrades - that is, a device restart MAY be required.

Metode apa pun dapat digunakan, asalkan dapat menggantikan keseluruhan perangkat lunak yang diinstal pada perangkat. Misalnya, salah satu dari pendekatan berikut akan memenuhi persyaratan ini:

Unduhan over-the-air (OTA) dengan pembaruan offline melalui reboot
Pembaruan "tertambat" melalui USB dari pc host
Pembaruan "offline" melalui reboot dan perbarui dari file di penyimpanan yang dapat dilepas

Mekanisme pembaruan yang digunakan harus mendukung pembaruan tanpa menyeka data pengguna. That is, the update mechanism MUST preserve application private data and application shared data. Perhatikan bahwa perangkat lunak Android hulu mencakup mekanisme pembaruan yang memenuhi persyaratan ini.

If an error is found in a device implementation after it has been released but within its reasonable product lifetime that is determined in consultation with the Android Compatibility Team to affect the compatibility of third-party applications, the device implementer MUST correct the error via a software Pembaruan tersedia yang dapat diterapkan sesuai mekanisme yang baru saja dijelaskan.

12. Hubungi Kami

Anda dapat menghubungi penulis dokumen di kompatibilitas@android.com untuk klarifikasi dan untuk memunculkan masalah yang menurut Anda tidak mencakup dokumen tersebut.

Lampiran A - Prosedur Pengujian Bluetooth

Rangkaian uji kompatibilitas mencakup kasus yang mencakup operasi dasar API Android RFComm Bluetooth. Namun, karena Bluetooth adalah protokol komunikasi antar perangkat, ia tidak dapat sepenuhnya diuji dengan unit tes yang berjalan pada satu perangkat. Consequently, device implementations MUST also pass the human-operated Bluetooth test procedure described below.

The test procedure is based on the BluetoothChat sample app included in the Android open source project tree. Prosedur ini membutuhkan dua perangkat:

Implementasi perangkat kandidat yang menjalankan perangkat lunak yang akan diuji
a separate device implementation already known to be compatible, and of a model from the device implementation being tested - that is, a "known good" device implementation

Prosedur pengujian di bawah ini masing -masing menyebut perangkat ini sebagai perangkat "kandidat" dan "diketahui baik".

Pengaturan dan Instalasi

Build BluetoothChat.apk via 'make samples' from an Android source code tree
Install BluetoothChat.apk on the known-good device
Install BluetoothChat.apk on the candidate device

Uji kontrol bluetooth dengan aplikasi

Launch BluetoothChat on the candidate device, while Bluetooth is disabled
Verify that the candidate device either turns on Bluetooth, or prompts the user with a dialog to turn on Bluetooth

Uji pasangan dan komunikasi

Launch the Bluetooth Chat app on both devices
Make the known-good device discoverable from within BluetoothChat (using the Menu)
On the candidate device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the known-good device
Send 10 or more messages from each device, and verify that the other device receives them correctly
Close the BluetoothChat app on both devices by pressing Home
Unpair each device from the other, using the device Settings app

Test Pairing and Communication in the Reverse Direction

Luncurkan aplikasi obrolan Bluetooth di kedua perangkat.
Make the candidate device discoverable from within BluetoothChat (using the Menu).
On the known-good device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the candidate device.
Send 10 or messages from each device, and verify that the other device receives them correctly.
Close the Bluetooth Chat app on both devices by pressing Back repeatedly to get to the Launcher.

Test Re-Launches

Re-launch the Bluetooth Chat app on both devices.
Send 10 or messages from each device, and verify that the other device receives them correctly.

Note: the above tests have some cases which end a test section by using Home, and some using Back. These tests are not redundant and are not optional: the objective is to verify that the Bluetooth API and stack works correctly both when Activities are explicitly terminated (via the user pressing Back, which calls finish()), and implicitly sent to background (via the user pressing Home.) Each test sequence MUST be performed as described.