1. Pengantar

Dokumen ini mencantumkan persyaratan yang harus dipenuhi agar perangkat kompatibel dengan Android 6.0.

Penggunaan “HARUS”, “TIDAK BOLEH”, “WAJIB”, “HARUS”, “TIDAK BOLEH”, “HARUS”, “TIDAK BOLEH”, “DISARANKAN”, “MUNGKIN”, dan “OPSIONAL” sesuai dengan standar IETF yang ditentukan dalam RFC2119 [Referensi, 1].

Seperti yang digunakan dalam dokumen ini, “penerapkan perangkat” atau “penerapkan” adalah orang atau organisasi yang mengembangkan solusi hardware/software yang menjalankan Android 6.0. "Penerapan perangkat" atau "penerapan adalah solusi hardware/software yang dikembangkan.

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

Jika definisi ini atau pengujian software yang dijelaskan dalam bagian 10 tidak jelas, ambigu, atau tidak lengkap, tanggung jawab implementer perangkat adalah untuk memastikan kompatibilitas dengan implementasi yang ada.

Karena alasan ini, Project Open Source Android [Referensi, 2] adalah referensi dan implementasi Android yang lebih disukai. Implementator perangkat SANGAT DISARANKAN untuk mendasarkan implementasi mereka semaksimal mungkin pada kode sumber “upstream” yang tersedia dari Project Open Source Android. Meskipun secara hipotetis beberapa komponen dapat diganti dengan implementasi alternatif, SANGAT DISARANKAN untuk tidak mengikuti praktik ini, karena lulus pengujian software akan menjadi jauh lebih sulit. Implementator bertanggung jawab untuk memastikan kompatibilitas perilaku penuh dengan implementasi Android standar, termasuk dan di luar Compatibility Test Suite. Terakhir, perhatikan bahwa penggantian dan perubahan komponen tertentu secara eksplisit dilarang oleh dokumen ini.

Banyak resource yang tercantum dalam bagian 14 berasal secara langsung atau tidak langsung dari Android SDK, dan akan secara fungsional identik dengan informasi dalam dokumentasi SDK tersebut. Untuk kasus apa pun jika Definisi Kompatibilitas ini atau Compatibility Test Suite tidak sesuai dengan dokumentasi SDK, dokumentasi SDK dianggap otoritatif. Setiap detail teknis yang diberikan dalam referensi yang disertakan dalam bagian 14 dianggap sebagai bagian dari Definisi Kompatibilitas ini.

2. Jenis Perangkat

Meskipun Project Open Source Android telah digunakan dalam implementasi berbagai jenis dan faktor bentuk perangkat, banyak aspek arsitektur dan persyaratan kompatibilitas dioptimalkan untuk perangkat genggam. Mulai dari Android 5.0, Project Open Source Android bertujuan untuk mengakomodasi berbagai jenis perangkat yang lebih luas seperti yang dijelaskan di bagian ini.

Perangkat Genggam Android mengacu pada implementasi perangkat Android yang biasanya digunakan dengan memegangnya di tangan, seperti pemutar mp3, ponsel, dan tablet. Implementasi perangkat Android Handheld:

• HARUS memiliki layar sentuh yang disematkan di perangkat.
• HARUS memiliki sumber daya yang memberikan mobilitas, seperti baterai.

Perangkat Android Television mengacu pada implementasi perangkat Android yang merupakan antarmuka hiburan untuk mengonsumsi media digital, film, game, aplikasi, dan/atau TV live bagi pengguna yang duduk sekitar tiga meter dari perangkat (antarmuka pengguna “santai” atau “10 kaki”). Perangkat Android Television:

• HARUS memiliki layar tersemat ATAU menyertakan port output video, seperti VGA, HDMI, atau port nirkabel untuk tampilan.
• HARUS mendeklarasikan fitur android.software.leanback dan android.hardware.type.television [Referensi, 3].

Perangkat Android Watch mengacu pada implementasi perangkat Android yang dimaksudkan untuk dikenakan di tubuh, mungkin di pergelangan tangan, dan:

• HARUS memiliki layar dengan panjang diagonal fisik dalam rentang dari 1,1 hingga 2,5 inci.
• HARUS mendeklarasikan fitur android.hardware.type.watch.
• HARUS mendukung uiMode = UI_MODE_TYPE_WATCH [Referensi, 4].

Implementasi Android Automotive mengacu pada head unit kendaraan yang menjalankan Android sebagai sistem operasi untuk sebagian atau seluruh sistem dan/atau fungsi infotainmen. Implementasi Android Automotive:

• HARUS mendeklarasikan fitur android.hardware.type.automotive.
• HARUS mendukung uiMode = UI_MODE_TYPE_CAR [Resources, 5].

Semua implementasi perangkat Android yang tidak sesuai dengan jenis perangkat di atas MASIH HARUS memenuhi semua persyaratan dalam dokumen ini agar kompatibel dengan Android 6.0, kecuali jika persyaratan tersebut dijelaskan secara eksplisit hanya berlaku untuk jenis perangkat Android tertentu dari atas.

2.1 Konfigurasi Perangkat

Berikut adalah ringkasan perbedaan utama dalam konfigurasi hardware menurut jenis perangkat. (Sel kosong menunjukkan “MUNGKIN”). Tidak semua konfigurasi tercakup dalam tabel ini; lihat bagian hardware yang relevan untuk mengetahui detail selengkapnya.

Kategori	Fitur	Bagian	Genggam	Televisi	Tonton	Otomotif	Lainnya
Input	D-pad	7.2.2. Navigasi Non-sentuh		HARUS
	Layar sentuh	7.2.4. Input layar sentuh	HARUS		HARUS		HARUS
	Mikrofon	7.8.1. Mikrofon	HARUS	HARUS	HARUS	HARUS	HARUS
Sensor	Akselerometer	7.3.1 Akselerometer	HARUS		HARUS		HARUS
	GPS	7.3.3. GPS	HARUS			HARUS
Konektivitas	Wi-Fi	7.4.2. IEEE 802.11	HARUS	HARUS		HARUS	HARUS
	Wi-Fi Direct	7.4.2.1. Wi-Fi Direct	HARUS	HARUS			HARUS
	Bluetooth	7.4.3. Bluetooth	HARUS	HARUS	HARUS	HARUS	HARUS
	Bluetooth Hemat Energi	7.4.3. Bluetooth	HARUS	HARUS	HARUS	HARUS	HARUS
	Mode periferal/host USB	7.7. USB	HARUS			HARUS	HARUS
Output	Port output Audio dan/atau Speaker	7.8.2. Output Audio	HARUS	HARUS		HARUS	HARUS

3. Software

3.1. Kompatibilitas API Terkelola

Lingkungan eksekusi bytecode Dalvik terkelola adalah kendaraan utama untuk aplikasi Android. Application programming interface (API) Android adalah kumpulan antarmuka platform Android yang diekspos ke aplikasi yang berjalan di lingkungan runtime terkelola. Implementasi perangkat HARUS menyediakan implementasi lengkap, termasuk semua perilaku yang didokumentasikan, dari API yang didokumentasikan yang diekspos oleh Android SDK [Referensi, 6] atau API apa pun yang dihias dengan penanda “@SystemApi” dalam kode sumber Android upstream.

Implementasi perangkat TIDAK BOLEH menghilangkan API terkelola, mengubah antarmuka atau tanda tangan API, menyimpang dari perilaku yang didokumentasikan, atau menyertakan no-ops, kecuali jika diizinkan secara khusus oleh Definisi Kompatibilitas ini.

Definisi Kompatibilitas ini mengizinkan beberapa jenis hardware yang menyertakan API Android untuk dihilangkan oleh implementasi perangkat. Dalam kasus tersebut, API HARUS tetap ada dan berperilaku dengan cara yang wajar. Lihat bagian 7 untuk mengetahui persyaratan spesifik untuk skenario ini.

3.2. Kompatibilitas Soft API

Selain API terkelola dari bagian 3.1, Android juga menyertakan API “soft” khusus runtime yang signifikan, dalam bentuk hal-hal seperti intent, izin, dan aspek serupa dari aplikasi Android yang tidak dapat diterapkan pada waktu kompilasi aplikasi.

3.2.1. Izin

Implementator perangkat HARUS mendukung dan menerapkan semua konstanta izin seperti yang didokumentasikan oleh halaman referensi Izin [Referensi, 7]. Perhatikan bahwa bagian 9 mencantumkan persyaratan tambahan yang terkait dengan model keamanan Android.

3.2.2. Parameter Build

Android API menyertakan sejumlah konstanta di class android.os.Build [Resources, 8] yang dimaksudkan untuk mendeskripsikan perangkat saat ini. Untuk memberikan nilai yang konsisten dan bermakna di seluruh implementasi perangkat, tabel di bawah menyertakan batasan tambahan pada format nilai ini yang HARUS sesuai dengan implementasi perangkat.

Parameter	Detail
VERSION.RELEASE	Versi sistem Android yang sedang dieksekusi, dalam format yang dapat dibaca manusia. Kolom ini HARUS memiliki salah satu nilai string yang ditentukan di [Referensi, 9].
VERSION.SDK	Versi sistem Android yang sedang dieksekusi, dalam format yang dapat diakses oleh kode aplikasi pihak ketiga. Untuk Android 6.0, kolom ini HARUS memiliki nilai bilangan bulat 23.
VERSION.SDK_INT	Versi sistem Android yang sedang dieksekusi, dalam format yang dapat diakses oleh kode aplikasi pihak ketiga. Untuk Android 6.0, kolom ini HARUS memiliki nilai bilangan bulat 23.
VERSION.INCREMENTAL	Nilai yang dipilih oleh implementator perangkat yang menetapkan build tertentu dari sistem Android yang sedang dieksekusi, dalam format yang dapat dibaca manusia. Nilai ini TIDAK BOLEH digunakan kembali untuk build yang berbeda yang tersedia bagi pengguna akhir. Penggunaan umum kolom ini adalah untuk menunjukkan nomor build atau ID perubahan kontrol sumber yang digunakan untuk membuat build. Tidak ada persyaratan pada format khusus kolom ini, kecuali bahwa kolom ini TIDAK BOLEH null atau string kosong ("").
PAPAN	Nilai yang dipilih oleh implementator perangkat yang mengidentifikasi hardware internal tertentu yang digunakan oleh perangkat, dalam format yang dapat dibaca manusia. Kemungkinan penggunaan kolom ini adalah untuk menunjukkan revisi spesifik dari board yang memberi daya pada perangkat. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9_-]+$”.
BRAND	Nilai yang mencerminkan nama merek yang terkait dengan perangkat seperti yang diketahui oleh pengguna akhir. HARUS dalam format yang dapat dibaca manusia dan HARUS mewakili produsen perangkat atau merek perusahaan tempat perangkat dipasarkan. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9_-]+$”.
SUPPORTED_ABIS	Nama set petunjuk (jenis CPU + konvensi ABI) kode native. Lihat bagian 3.3. Kompatibilitas API Native.
SUPPORTED_32_BIT_ABIS	Nama set petunjuk (jenis CPU + konvensi ABI) kode native. Lihat bagian 3.3. Kompatibilitas API Native.
SUPPORTED_64_BIT_ABIS	Nama set petunjuk kedua (jenis CPU + konvensi ABI) dari kode native. Lihat bagian 3.3. Kompatibilitas API Native.
CPU_ABI	Nama set petunjuk (jenis CPU + konvensi ABI) kode native. Lihat bagian 3.3. Kompatibilitas API Native.
CPU_ABI2	Nama set petunjuk kedua (jenis CPU + konvensi ABI) dari kode native. Lihat bagian 3.3. Kompatibilitas API Native.
PERANGKAT	Nilai yang dipilih oleh implementer perangkat yang berisi nama pengembangan atau nama kode yang mengidentifikasi konfigurasi fitur hardware dan desain industri perangkat. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9_-]+$”.
SIdik jari	String yang mengidentifikasi build ini secara unik. File ini HARUS dapat dibaca manusia dengan cukup baik. Template ini HARUS mengikuti template ini: $(BRAND)/$(PRODUCT)/     $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Contoh: acme/myproduct/     mydevice:6.0/LMYXX/3359:userdebug/test-keys Sidik jari TIDAK BOLEH menyertakan karakter spasi kosong. Jika kolom lain yang disertakan dalam template di atas memiliki karakter spasi kosong, kolom tersebut HARUS diganti dalam sidik jari build dengan karakter lain, seperti karakter garis bawah ("_"). Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit.
PERANGKAT KERAS	Nama hardware (dari command line kernel atau /proc). File ini HARUS dapat dibaca manusia secara wajar. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9_-]+$”.
PENYELENGGARA	String yang secara unik mengidentifikasi host tempat build dibuat, dalam format yang dapat dibaca manusia. Tidak ada persyaratan pada format khusus kolom ini, kecuali bahwa kolom ini TIDAK BOLEH null atau string kosong ("").
ID	ID yang dipilih oleh pengimplementasi perangkat untuk merujuk ke rilis tertentu, dalam format yang dapat dibaca manusia. Kolom ini dapat sama dengan android.os.Build.VERSION.INCREMENTAL, tetapi HARUS berupa nilai yang cukup bermakna bagi pengguna akhir untuk membedakan build software. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9._-]+$”.
PRODUSEN	Nama dagang Produsen Peralatan Asli (OEM) produk. Tidak ada persyaratan pada format khusus kolom ini, kecuali bahwa kolom ini TIDAK BOLEH null atau string kosong ("").
MODEL	Nilai yang dipilih oleh implementator perangkat yang berisi nama perangkat seperti yang diketahui oleh pengguna akhir. Nama ini HARUS sama dengan nama yang digunakan untuk memasarkan dan menjual perangkat kepada pengguna akhir. Tidak ada persyaratan pada format khusus kolom ini, kecuali bahwa kolom ini TIDAK BOLEH null atau string kosong ("").
PRODUK	Nilai yang dipilih oleh implementer perangkat yang berisi nama pengembangan atau nama kode produk tertentu (SKU) yang HARUS unik dalam merek yang sama. HARUS dapat dibaca manusia, tetapi tidak selalu dimaksudkan untuk dilihat oleh pengguna akhir. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9_-]+$”.
SERIAL	Nomor seri hardware, yang HARUS tersedia dan unik di seluruh perangkat dengan MODEL dan PRODUSEN yang sama. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^([a-zA-Z0-9]{6,20})$”.
TAG	Daftar tag yang dipisahkan koma yang dipilih oleh implementer perangkat yang lebih lanjut membedakan build. Kolom ini HARUS memiliki salah satu nilai yang sesuai dengan tiga konfigurasi penandatanganan platform Android standar: kunci rilis, kunci developer, kunci pengujian.
WAKTU	Nilai yang mewakili stempel waktu saat build terjadi.
TYPE	Nilai yang dipilih oleh implementator perangkat yang menentukan konfigurasi runtime build. Kolom ini HARUS memiliki salah satu nilai yang sesuai dengan tiga konfigurasi runtime Android standar: user, userdebug, atau eng.
PENGGUNA	Nama atau ID pengguna (atau pengguna otomatis) yang membuat build. Tidak ada persyaratan pada format khusus kolom ini, kecuali bahwa kolom ini TIDAK BOLEH null atau string kosong ("").
SECURITY_PATCH	Nilai yang menunjukkan tingkat patch keamanan build. Hal ini HARUS menunjukkan bahwa build menyertakan semua patch keamanan yang dikeluarkan melalui Buletin Keamanan Publik Android yang ditetapkan. Formatnya HARUS [YYYY-MM-DD], yang cocok dengan salah satu string Tingkat Patch Keamanan Android dari Buletin Keamanan Publik, misalnya "2015-11-01".
BASE_OS	Nilai yang mewakili parameter FINGERPRINT dari build yang identik dengan build ini kecuali untuk patch yang disediakan di Android Public Security Bulletin. Nilai ini HARUS melaporkan nilai yang benar dan jika build tersebut tidak ada, laporkan string kosong ("").

3.2.3. Kompatibilitas Intent

Implementasi perangkat HARUS mematuhi sistem intent pengaitan longgar Android, seperti yang dijelaskan di bagian di bawah. Yang dimaksud dengan "dihormati" adalah bahwa implementer perangkat HARUS menyediakan Aktivitas atau Layanan Android yang menentukan filter intent yang cocok yang mengikat dan menerapkan perilaku yang benar untuk setiap pola intent yang ditentukan.

3.2.3.1. Intent Aplikasi Inti

Intent Android memungkinkan komponen aplikasi meminta fungsi dari komponen Android lainnya. Project upstream Android menyertakan daftar aplikasi yang dianggap sebagai aplikasi Android inti, yang mengimplementasikan beberapa pola intent untuk melakukan tindakan umum. Aplikasi Android intinya adalah:

• Jam Meja
• Browser
• Kalender
• Kontak
• Galeri
• GlobalSearch
• Peluncur
• Musik
• Setelan

Implementasi perangkat HARUS menyertakan aplikasi Android inti sesuai kebutuhan, tetapi HARUS menyertakan komponen yang menerapkan pola intent yang sama yang ditentukan oleh semua komponen Aktivitas atau Layanan "publik" dari aplikasi Android inti ini. Perhatikan bahwa komponen Aktivitas atau Layanan dianggap "publik" jika atribut android:exported tidak ada atau memiliki nilai benar.

3.2.3.2. Resolusi Maksud

Karena Android adalah platform yang dapat diperluas, implementasi perangkat HARUS mengizinkan setiap pola intent yang dirujuk dalam bagian 3.2.3.1 untuk diganti oleh aplikasi pihak ketiga. Implementasi open source Android upstream memungkinkan hal ini secara default; implementer perangkat TIDAK BOLEH melampirkan hak istimewa khusus ke penggunaan pola intent oleh aplikasi sistem, atau mencegah aplikasi pihak ketiga untuk mengikat dan mengambil alih kontrol pola ini. Larangan ini secara khusus mencakup, tetapi tidak terbatas pada, menonaktifkan antarmuka pengguna “Chooser” yang memungkinkan pengguna memilih antara beberapa aplikasi yang semuanya menangani pola intent yang sama.

Implementasi perangkat HARUS menyediakan antarmuka pengguna bagi pengguna untuk mengubah aktivitas default untuk intent.

Namun, implementasi perangkat DAPAT menyediakan aktivitas default untuk pola URI tertentu (misalnya, http://play.google.com) saat aktivitas default menyediakan atribut yang lebih spesifik untuk URI data. Misalnya, pola filter intent yang menentukan URI data “http://www.android.com” lebih spesifik daripada pola intent inti browser untuk “http://”.

Android juga menyertakan mekanisme bagi aplikasi pihak ketiga untuk mendeklarasikan perilaku penautan aplikasi default yang kredibel untuk jenis intent URI web tertentu [Referensi, 140]. Jika deklarasi resmi tersebut ditentukan dalam pola filter intent aplikasi, implementasi perangkat:

• HARUS mencoba memvalidasi filter intent apa pun dengan melakukan langkah-langkah validasi yang ditentukan dalam spesifikasi Digital Asset Links [Referensi, 141] seperti yang diterapkan oleh Pengelola Paket di Project Open Source Android upstream.
• HARUS mencoba validasi filter intent selama penginstalan aplikasi dan menetapkan semua filter intent UIR yang berhasil divalidasi sebagai pengendali aplikasi default untuk UIR-nya.
• DAPAT menetapkan filter intent URI tertentu sebagai pengendali aplikasi default untuk URI-nya, jika berhasil diverifikasi, tetapi filter URI kandidat lainnya gagal dalam verifikasi. Jika implementasi perangkat melakukan hal ini, implementasi tersebut HARUS memberikan penggantian pola per URI yang sesuai kepada pengguna di menu setelan.
• HARUS memberikan kontrol Link Aplikasi per aplikasi kepada pengguna di Setelan sebagai berikut:
  • Pengguna HARUS dapat mengganti perilaku link aplikasi default secara menyeluruh agar aplikasi menjadi: selalu terbuka, selalu bertanya, atau tidak pernah terbuka, yang harus berlaku untuk semua filter intent URI kandidat secara setara.
  • Pengguna HARUS dapat melihat daftar filter intent URI kandidat.
  • Implementasi perangkat DAPAT memberi pengguna kemampuan untuk mengganti filter intent URI kandidat tertentu yang berhasil diverifikasi, berdasarkan filter per intent.
  • Implementasi perangkat HARUS memberi pengguna kemampuan untuk melihat dan mengganti filter intent URI kandidat tertentu jika implementasi perangkat memungkinkan beberapa filter intent URI kandidat berhasil diverifikasi, sementara beberapa filter lainnya dapat gagal.

3.2.3.3. Namespace Intent

Implementasi perangkat TIDAK BOLEH menyertakan komponen Android apa pun yang mematuhi intent baru atau pola intent siaran menggunakan ACTION, CATEGORY, atau string kunci lainnya di namespace android.* atau com.android.*. Implementator perangkat TIDAK BOLEH menyertakan komponen Android apa pun yang mematuhi intent baru atau pola intent siaran menggunakan ACTION, CATEGORY, atau string kunci lainnya di ruang paket milik organisasi lain. Implementer perangkat TIDAK BOLEH mengubah atau memperluas pola intent apa pun yang digunakan oleh aplikasi inti yang tercantum dalam bagian 3.2.3.1. Implementasi perangkat DAPAT menyertakan pola intent menggunakan namespace yang dikaitkan dengan organisasinya sendiri secara jelas. Larangan ini analog dengan yang ditentukan untuk class bahasa Java di bagian 3.6.

3.2.3.4. Intent Siaran

Aplikasi pihak ketiga mengandalkan platform untuk menyiarkan intent tertentu guna memberi tahu mereka tentang perubahan di lingkungan hardware atau software. Perangkat yang kompatibel dengan Android HARUS menyiarkan intent siaran publik sebagai respons terhadap peristiwa sistem yang sesuai. Intent siaran dijelaskan dalam dokumentasi SDK.

3.2.3.5. Setelan Aplikasi Default

Android menyertakan setelan yang memberi pengguna cara mudah untuk memilih aplikasi default, misalnya untuk Layar utama atau SMS. Jika memungkinkan, implementasi perangkat HARUS menyediakan menu setelan yang serupa dan kompatibel dengan pola filter intent dan metode API yang dijelaskan dalam dokumentasi SDK seperti di bawah.

Implementasi perangkat:

• HARUS mematuhi intent android.settings.HOME_SETTINGS untuk menampilkan menu setelan aplikasi default untuk Layar Utama, jika implementasi perangkat melaporkan android.software.home_screen [Resources, 10]
• HARUS menyediakan menu setelan yang akan memanggil intent android.provider.Telephony.ACTION_CHANGE_DEFAULT untuk menampilkan dialog guna mengubah aplikasi SMS default, jika implementasi perangkat melaporkan android.hardware.telephony [Referensi, 11]
• HARUS mematuhi intent android.settings.NFC_PAYMENT_SETTINGS untuk menampilkan menu setelan aplikasi default untuk Pembayaran Nirsentuh, jika implementasi perangkat melaporkan android.hardware.nfc.hce [Referensi, 10]

3.3. Kompatibilitas API Native

3.3.1. Antarmuka Biner Aplikasi

Bytecode Dalvik terkelola dapat memanggil kode native yang disediakan dalam file .apk aplikasi sebagai file .so ELF yang dikompilasi untuk arsitektur hardware perangkat yang sesuai. Karena kode native sangat bergantung pada teknologi prosesor yang mendasarinya, Android menentukan sejumlah Antarmuka Biner Aplikasi (ABI) di Android NDK. Implementasi perangkat HARUS kompatibel dengan satu atau beberapa ABI yang ditentukan, dan HARUS menerapkan kompatibilitas dengan Android NDK, seperti di bawah.

Jika penerapan perangkat menyertakan dukungan untuk ABI Android, penerapan tersebut:

• HARUS menyertakan dukungan untuk kode yang berjalan di lingkungan terkelola untuk memanggil kode native, menggunakan semantik Java Native Interface (JNI) standar
• HARUS kompatibel dengan sumber (yaitu kompatibel dengan header) dan kompatibel dengan biner (untuk ABI) dengan setiap library yang diperlukan dalam daftar di bawah
• HARUS mendukung ABI 32-bit yang setara jika ada ABI 64-bit yang didukung
• HARUS melaporkan Application Binary Interface (ABI) native yang didukung oleh perangkat secara akurat, melalui parameter android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS, dan android.os.Build.SUPPORTED_64_BIT_ABIS, masing-masing adalah daftar ABI yang dipisahkan koma yang diurutkan dari yang paling banyak hingga yang paling sedikit disukai
• HARUS melaporkan, melalui parameter di atas, hanya ABI yang didokumentasikan dan dijelaskan dalam dokumentasi Pengelolaan ABI Android NDK versi terbaru [Referensi, 12], dan HARUS menyertakan dukungan untuk ekstensi Advanced SIMD (alias NEON) [Referensi, 13]
• HARUS dibuat menggunakan kode sumber dan file header yang tersedia di Project Open Source Android upstream

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

• libc (library C)
• libm (library matematika)
• Dukungan minimal untuk C++
• Antarmuka JNI
• liblog (logging Android)
• libz (Kompresi Zlib)
• libdl (dynamic linker)
• libGLESv1_CM.so (OpenGL ES 1.x)
• libGLESv2.so (OpenGL ES 2.0)
• libGLESv3.so (OpenGL ES 3.x)
• libEGL.so (pengelolaan platform OpenGL native)
• libjnigraphics.so
• libOpenSLES.so (dukungan audio OpenSL ES 1.0.1)
• libOpenMAXAL.so (dukungan OpenMAX AL 1.0.1)
• libandroid.so (dukungan aktivitas Android native)
• libmediandk.so (dukungan API media native)
• Dukungan untuk OpenGL, seperti yang dijelaskan di bawah

Perhatikan bahwa rilis Android NDK mendatang dapat memperkenalkan dukungan untuk ABI tambahan. Jika implementasi perangkat tidak kompatibel dengan ABI standar yang ada, implementasi tersebut TIDAK BOLEH melaporkan dukungan untuk ABI apa pun.

Perhatikan bahwa implementasi perangkat HARUS menyertakan libGLESv3.so dan HARUS memiliki symlink (link simbolis) ke libGLESv2.so. Selanjutnya, HARUS mengekspor semua simbol fungsi OpenGL ES 3.1 dan Android Extension Pack [Resources, 14] seperti yang ditentukan dalam rilis NDK android-21. Meskipun semua simbol harus ada, hanya fungsi yang sesuai untuk versi dan ekstensi OpenGL ES yang benar-benar didukung oleh perangkat yang harus sepenuhnya diterapkan.

Implementasi perangkat, jika menyertakan library native dengan nama libvulkan.so, HARUS mengekspor simbol fungsi dan menyediakan implementasi Vulkan 1.0 API dan ekstensi VK_KHR_surface, VK_KHR_swapchain, dan VK_KHR_android_surface seperti yang ditentukan oleh Khronos Group dan lulus pengujian kepatuhan Khronos.

Kompatibilitas kode native sangat sulit. Oleh karena itu, SANGAT DISARANKAN bagi implementer perangkat untuk menggunakan implementasi library yang tercantum di atas dari Project Open Source Android upstream.

3.3.2. Kompatibilitas Kode Native ARM 32-bit

Arsitektur ARMv8 tidak lagi menggunakan beberapa operasi CPU, termasuk beberapa operasi yang digunakan dalam kode native yang ada. Di perangkat ARM 64-bit, operasi yang tidak digunakan lagi berikut HARUS tetap tersedia untuk kode ARM native 32-bit, baik melalui dukungan CPU native maupun melalui emulasi software:

• Instruksi SWP dan SWPB
• Petunjuk SETEND
• Operasi penghalang CP15ISB, CP15DSB, dan CP15DMB

Versi lama Android NDK menggunakan /proc/cpuinfo untuk menemukan fitur CPU dari kode native ARM 32-bit. Untuk kompatibilitas dengan aplikasi yang di-build menggunakan NDK ini, perangkat HARUS menyertakan baris berikut di /proc/cpuinfo saat dibaca oleh aplikasi ARM 32-bit:

• "Fitur: ", diikuti dengan daftar fitur CPU ARMv7 opsional yang didukung oleh perangkat
• "CPU architecture: ", diikuti dengan bilangan bulat yang menjelaskan arsitektur ARM tertinggi yang didukung perangkat (misalnya, "8" untuk perangkat ARMv8)

Persyaratan ini hanya berlaku saat /proc/cpuinfo dibaca oleh aplikasi ARM 32-bit. Perangkat TIDAK BOLEH mengubah /proc/cpuinfo saat dibaca oleh aplikasi ARM 64-bit atau non-ARM.

3.4. Kompatibilitas Web

3.4.1. Kompatibilitas WebView

Fitur platform android.software.webview HARUS dilaporkan di perangkat apa pun yang menyediakan implementasi lengkap android.webkit.WebView API, dan TIDAK BOLEH dilaporkan di perangkat tanpa implementasi lengkap API. Implementasi Open Source Android menggunakan kode dari Project Chromium untuk menerapkan android.webkit.WebView [Referensi, 15]. Karena tidak memungkinkan untuk mengembangkan rangkaian pengujian yang komprehensif untuk sistem rendering web, pengimplementasi perangkat HARUS menggunakan build upstream khusus Chromium dalam implementasi WebView. Khususnya:

• Implementasi android.webkit.WebView perangkat HARUS didasarkan pada build Chromium dari Project Open Source Android upstream untuk Android 6.0. Build ini menyertakan serangkaian fungsi dan perbaikan keamanan tertentu untuk WebView [Referensi, 16].
• String agen pengguna yang dilaporkan oleh WebView HARUS dalam format ini:

  Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD); wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

  • Nilai string $(VERSION) HARUS sama dengan nilai untuk android.os.Build.VERSION.RELEASE.
  • Nilai string $(MODEL) HARUS sama dengan nilai untuk android.os.Build.MODEL.
  • Nilai string $(BUILD) HARUS sama dengan nilai untuk android.os.Build.ID.
  • Nilai string $(CHROMIUM_VER) HARUS berupa versi Chromium di Project Open Source Android upstream.
  • Implementasi perangkat DAPAT menghilangkan Seluler dalam string agen pengguna.

Komponen WebView HARUS menyertakan dukungan untuk sebanyak mungkin fitur HTML5 dan jika mendukung fitur tersebut, HARUS sesuai dengan spesifikasi HTML5 [Referensi, 17].

3.4.2. Kompatibilitas Browser

Browser mandiri DAPAT didasarkan pada teknologi browser selain WebKit. Namun, meskipun aplikasi Browser alternatif digunakan, komponen android.webkit.WebView yang disediakan untuk aplikasi pihak ketiga HARUS didasarkan pada WebKit, seperti yang dijelaskan dalam bagian 3.4.1.

Implementasi DAPAT mengirimkan string agen pengguna kustom di aplikasi Browser mandiri.

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

• cache aplikasi/operasi offline [Referensi, 18]
• tag <video> [Referensi, 19]
• geolocation [Resources, 20]

Selain itu, implementasi perangkat HARUS mendukung API webstorage HTML5/W3C [Referensi, 21], dan HARUS mendukung API IndexedDB HTML5/W3C [Referensi, 22]. Perhatikan bahwa karena badan standar pengembangan web bertransisi untuk lebih memilih IndexedDB daripada webstorage, IndexedDB diharapkan menjadi komponen yang diperlukan di versi Android mendatang.

3.5. Kompatibilitas Perilaku API

Perilaku setiap jenis API (terkelola, soft, native, dan web) harus konsisten dengan penerapan Project Open Source Android upstream yang diinginkan [Referensi, 2]. Beberapa area kompatibilitas tertentu adalah:

• Perangkat TIDAK BOLEH mengubah perilaku atau semantik intent standar.
• Perangkat TIDAK BOLEH mengubah siklus proses atau semantik siklus proses dari jenis komponen sistem tertentu (seperti Layanan, Aktivitas, ContentProvider, dll.).
• Perangkat TIDAK BOLEH mengubah semantik izin standar.

Daftar di atas tidak lengkap. Compatibility Test Suite (CTS) menguji bagian platform yang signifikan untuk kompatibilitas perilaku, tetapi tidak semuanya. Implementer bertanggung jawab untuk memastikan kompatibilitas perilaku dengan Project Open Source Android. Oleh karena itu, implementer perangkat HARUS menggunakan kode sumber yang tersedia melalui Project Open Source Android jika memungkinkan, bukan menerapkan ulang bagian penting sistem.

3.6. Namespace API

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

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

Modifikasi yang dilarang mencakup:

• Implementasi perangkat TIDAK BOLEH mengubah API yang ditampilkan secara publik di platform Android dengan mengubah tanda tangan metode atau class, atau dengan menghapus class atau kolom class.
• Implementator perangkat DAPAT mengubah implementasi API yang mendasarinya, tetapi perubahan tersebut TIDAK BOLEH memengaruhi perilaku yang dinyatakan dan tanda tangan bahasa Java dari API apa pun yang diekspos secara publik.
• Implementer perangkat TIDAK BOLEH menambahkan elemen apa pun yang ditampilkan secara publik (seperti class atau antarmuka, atau kolom atau metode ke class atau antarmuka yang ada) ke API di atas.

“Elemen yang ditampilkan secara publik” adalah konstruksi apa pun yang tidak dihiasi dengan penanda “@hide” seperti yang digunakan dalam kode sumber Android upstream. Dengan kata lain, penerapkan perangkat TIDAK BOLEH mengekspos API baru atau mengubah API yang ada di namespace yang disebutkan di atas. Implementator perangkat DAPAT melakukan modifikasi khusus internal, tetapi modifikasi tersebut TIDAK BOLEH diiklankan atau ditampilkan kepada developer.

Implementator perangkat DAPAT menambahkan API kustom, tetapi API tersebut TIDAK BOLEH berada dalam namespace yang dimiliki oleh atau merujuk ke organisasi lain. Misalnya, implementer 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 kustom di luar namespace Android standar, API tersebut HARUS dikemas dalam library bersama Android sehingga hanya aplikasi yang menggunakannya secara eksplisit (melalui mekanisme lt;uses-librarygt;) yang terpengaruh oleh peningkatan penggunaan memori API tersebut.

Jika pengimplementasi perangkat mengusulkan untuk meningkatkan salah satu namespace paket di atas (seperti dengan menambahkan fungsi baru yang berguna ke API yang ada, atau menambahkan API baru), pengimplementasi HARUS mengunjungi source.android.com dan memulai proses untuk berkontribusi pada perubahan dan kode, sesuai dengan informasi di situs tersebut.

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 membuatnya mengikat melalui penyertaan dalam Definisi Kompatibilitas ini.

3.7. Kompatibilitas Runtime

Implementasi perangkat HARUS mendukung format Dalvik Executable (DEX) lengkap serta spesifikasi dan semantik bytecode Dalvik [Referensi, 23]. Implementator perangkat HARUS menggunakan ART, implementasi upstream referensi Format Eksekusi Dalvik, dan sistem pengelolaan paket implementasi referensi.

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

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

Tata Letak Layar	Kepadatan Layar	Memori Aplikasi Minimum
Android Watch	120 dpi (ldpi)	32MB
	160 dpi (mdpi)
	213 dpi (tvdpi)
	240 dpi (hdpi)	36MB
	280 dpi (280dpi)
	320 dpi (xhdpi)	48MB
	360 dpi (360dpi)
	400 dpi (400dpi)	56MB
	420 dpi (420dpi)	64MB
	480 dpi (xxhdpi)	88MB
	560 dpi (560dpi)	112MB
	640 dpi (xxxhdpi)	154MB
kecil/normal	120 dpi (ldpi)	32MB
	160 dpi (mdpi)
	213 dpi (tvdpi)	48MB
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (xhdpi)	80MB
	360 dpi (360dpi)
	400 dpi (400dpi)	96MB
	420 dpi (420dpi)	112MB
	480 dpi (xxhdpi)	128MB
	560 dpi (560dpi)	192MB
	640 dpi (xxxhdpi)	256MB
besar	120 dpi (ldpi)	32MB
	160 dpi (mdpi)	48MB
	213 dpi (tvdpi)	80MB
	240 dpi (hdpi)
	280 dpi (280dpi)	96MB
	320 dpi (xhdpi)	128MB
	360 dpi (360dpi)	160MB
	400 dpi (400dpi)	192MB
	420 dpi (420dpi)	228MB
	480 dpi (xxhdpi)	256MB
	560 dpi (560dpi)	384MB
	640 dpi (xxxhdpi)	512 MB
xlarge	120 dpi (ldpi)	48MB
	160 dpi (mdpi)	80MB
	213 dpi (tvdpi)	96MB
	240 dpi (hdpi)
	280 dpi (280dpi)	144MB
	320 dpi (xhdpi)	192MB
	360 dpi (360dpi)	240MB
	400 dpi (400dpi)	288MB
	420 dpi (420dpi)	336MB
	480 dpi (xxhdpi)	384MB
	560 dpi (560dpi)	576MB
	640 dpi (xxxhdpi)	768MB

3.8. Kompatibilitas Antarmuka Pengguna

3.8.1. Peluncur (Layar Utama)

Android menyertakan aplikasi peluncur (layar utama) dan dukungan untuk aplikasi pihak ketiga guna menggantikan peluncur perangkat (layar utama). Implementasi perangkat yang memungkinkan aplikasi pihak ketiga mengganti layar utama perangkat HARUS mendeklarasikan fitur platform android.software.home_screen.

3.8.2. Widget

Android menentukan jenis komponen serta API dan siklus proses yang sesuai yang memungkinkan aplikasi mengekspos “AppWidget” kepada pengguna akhir [Referensi, 24], sebuah fitur yang SANGAT DISARANKAN untuk didukung pada implementasi Perangkat Genggam. Implementasi perangkat yang mendukung penyematan widget di layar utama HARUS memenuhi persyaratan berikut dan mendeklarasikan dukungan untuk fitur platform android.software.app_widgets.

• Peluncur perangkat HARUS menyertakan dukungan bawaan untuk AppWidget, dan mengekspos fitur antarmuka pengguna untuk menambahkan, mengonfigurasi, melihat, dan menghapus AppWidget langsung dalam Peluncur.
• Implementasi perangkat HARUS dapat merender widget berukuran 4 x 4 dalam ukuran petak standar. Lihat Panduan Desain Widget Aplikasi dalam dokumentasi Android SDK [Referensi, 24] untuk mengetahui detailnya.
• Implementasi perangkat yang menyertakan dukungan untuk layar kunci DAPAT mendukung widget aplikasi di layar kunci.

3.8.3. Notifikasi

Android menyertakan API yang memungkinkan developer memberi tahu pengguna tentang peristiwa penting [Referensi, 25], menggunakan fitur hardware dan software perangkat.

Beberapa API memungkinkan aplikasi melakukan notifikasi atau menarik perhatian menggunakan hardware—khususnya suara, getaran, dan cahaya. Implementasi perangkat HARUS mendukung notifikasi yang menggunakan fitur hardware, seperti yang dijelaskan dalam dokumentasi SDK, dan sejauh mungkin dengan hardware implementasi perangkat. Misalnya, jika implementasi perangkat menyertakan vibrator, implementasi tersebut HARUS mengimplementasikan API getaran dengan benar. Jika implementasi perangkat tidak memiliki hardware, API yang sesuai HARUS diterapkan sebagai no-ops. Perilaku ini dijelaskan lebih lanjut di bagian 7.

Selain itu, implementasi HARUS merender semua resource (ikon, file animasi dll.) dengan benar yang disediakan di API [Resource, 26], atau dalam panduan gaya ikon Status/Panel Sistem [Resource, 27], yang dalam kasus perangkat Android TV mencakup kemungkinan untuk tidak menampilkan notifikasi. Implementator perangkat DAPAT memberikan pengalaman pengguna alternatif untuk notifikasi selain yang disediakan oleh implementasi Android Open Source referensi; namun, sistem notifikasi alternatif tersebut HARUS mendukung resource notifikasi yang ada, seperti di atas.

Android menyertakan dukungan untuk berbagai notifikasi, seperti:

• Notifikasi dinamis. Tampilan Interaktif untuk notifikasi yang sedang berlangsung.
• Notifikasi peringatan dini. Tampilan Interaktif yang dapat ditindaklanjuti atau ditutup oleh pengguna tanpa keluar dari aplikasi saat ini.
• Notifikasi layar kunci. Notifikasi ditampilkan di layar kunci dengan kontrol terperinci pada visibilitas.

Implementasi perangkat Android, saat notifikasi tersebut terlihat, HARUS menjalankan notifikasi Rich dan Heads-up dengan benar serta menyertakan judul/nama, ikon, teks seperti yang didokumentasikan dalam Android API [Referensi, 28].

Android menyertakan Notification Listener Service API yang memungkinkan aplikasi (setelah diaktifkan secara eksplisit oleh pengguna) menerima salinan semua notifikasi saat diposting atau diperbarui. Implementasi perangkat HARUS mengirim notifikasi secara keseluruhan dengan benar dan tepat waktu ke semua layanan pemroses yang diinstal dan diaktifkan pengguna, termasuk semua metadata yang dilampirkan ke objek Notifikasi.

3.8.4. Telusuri

Android menyertakan API [Referensi, 29] yang memungkinkan developer menggabungkan penelusuran ke dalam aplikasi mereka, dan mengekspos data aplikasi mereka ke dalam penelusuran sistem global. Secara umum, fungsi ini terdiri dari satu antarmuka pengguna seluruh sistem yang memungkinkan pengguna memasukkan kueri, menampilkan saran saat pengguna mengetik, dan menampilkan hasil. Android API memungkinkan developer menggunakan kembali antarmuka ini untuk menyediakan penelusuran dalam aplikasi mereka sendiri, dan memungkinkan developer menyediakan hasil ke antarmuka pengguna penelusuran global umum.

Implementasi perangkat Android HARUS menyertakan penelusuran global, antarmuka pengguna penelusuran tunggal, bersama, di seluruh sistem yang mampu memberikan saran real-time sebagai respons terhadap input pengguna. Implementasi perangkat HARUS mengimplementasikan API yang memungkinkan developer menggunakan kembali antarmuka pengguna ini untuk menyediakan penelusuran dalam aplikasi mereka sendiri. Implementasi perangkat yang menerapkan antarmuka penelusuran global HARUS menerapkan API yang memungkinkan aplikasi pihak ketiga menambahkan saran ke kotak penelusuran saat dijalankan dalam mode penelusuran global. Jika tidak ada aplikasi pihak ketiga yang diinstal yang menggunakan fungsi ini, perilaku default HARUS menampilkan hasil dan saran mesin telusur web.

Implementasi perangkat Android HARUS menerapkan asisten di perangkat untuk menangani tindakan Bantuan [Referensi, 30].

Android juga menyertakan Assist API untuk memungkinkan aplikasi memilih jumlah informasi konteks saat ini yang dibagikan dengan asisten di perangkat [Referensi, 31]. Implementasi perangkat yang mendukung tindakan Bantuan HARUS menunjukkan dengan jelas kepada pengguna akhir saat konteks dibagikan dengan menampilkan cahaya putih di sekitar tepi layar. Untuk memastikan visibilitas yang jelas bagi pengguna akhir, indikasi HARUS memenuhi atau melebihi durasi dan kecerahan implementasi Project Open Source Android.

3.8.5. Toast

Aplikasi dapat menggunakan “Toast” API untuk menampilkan string non-modal singkat kepada pengguna akhir, yang menghilang setelah jangka waktu singkat [Resources, 32]. Implementasi perangkat HARUS menampilkan Toast dari aplikasi kepada pengguna akhir dengan cara yang sangat terlihat.

3.8.6. Tema

Android menyediakan “tema” sebagai mekanisme bagi aplikasi untuk menerapkan gaya di seluruh Aktivitas atau aplikasi.

Android menyertakan keluarga tema “Holo” sebagai kumpulan gaya yang ditentukan untuk digunakan developer aplikasi jika mereka ingin mencocokkan tampilan dan nuansa tema Holo seperti yang ditentukan oleh Android SDK [Referensi, 33]. Implementasi perangkat TIDAK BOLEH mengubah atribut tema Holo yang ditampilkan ke aplikasi [Resources, 34].

Android menyertakan keluarga tema “Material” sebagai kumpulan gaya yang ditentukan untuk digunakan developer aplikasi jika mereka ingin mencocokkan tampilan dan nuansa tema desain di berbagai jenis perangkat Android. Implementasi perangkat HARUS mendukung keluarga tema “Material” dan TIDAK BOLEH mengubah atribut tema Material atau asetnya yang ditampilkan ke aplikasi [Referensi, 35].

Android juga menyertakan grup tema “Default Perangkat” sebagai kumpulan gaya yang ditentukan untuk digunakan oleh developer aplikasi jika mereka ingin mencocokkan tampilan dan nuansa tema perangkat seperti yang ditentukan oleh pengimplementasi perangkat. Implementasi perangkat DAPAT mengubah atribut tema Default Perangkat yang ditampilkan ke aplikasi [Referensi, 34].

Android mendukung tema varian dengan panel sistem transparan, yang memungkinkan developer aplikasi mengisi area di belakang status dan panel navigasi dengan konten aplikasi mereka. Untuk mengaktifkan pengalaman developer yang konsisten dalam konfigurasi ini, gaya ikon status bar harus dipertahankan di implementasi perangkat yang berbeda. Oleh karena itu, implementasi perangkat Android HARUS menggunakan warna putih untuk ikon status sistem (seperti kekuatan sinyal dan level baterai) dan notifikasi yang dikeluarkan oleh sistem, kecuali jika ikon menunjukkan status yang bermasalah atau aplikasi meminta status bar terang menggunakan flag SYSTEM_UI_FLAG_LIGHT_STATUS_BAR. Saat aplikasi meminta status bar terang, implementasi perangkat Android HARUS mengubah warna ikon status sistem menjadi hitam [Referensi, 34].

3.8.7. Wallpaper Animasi

Android menentukan jenis komponen serta API dan siklus proses yang sesuai yang memungkinkan aplikasi mengekspos satu atau beberapa “Wallpaper Animasi” kepada pengguna akhir [Referensi, 36]. Wallpaper hidup adalah animasi, pola, atau gambar serupa dengan kemampuan input terbatas yang ditampilkan sebagai wallpaper, di belakang aplikasi lain.

Hardware dianggap mampu menjalankan wallpaper animasi dengan andal jika dapat menjalankan semua wallpaper animasi, tanpa batasan fungsi, pada kecepatan frame yang wajar tanpa efek samping pada aplikasi lain. Jika batasan dalam hardware menyebabkan wallpaper dan/atau aplikasi mengalami error, tidak berfungsi, menggunakan daya CPU atau baterai secara berlebihan, atau berjalan pada kecepatan frame yang tidak dapat diterima, hardware dianggap tidak dapat menjalankan wallpaper hidup. Misalnya, beberapa wallpaper hidup dapat menggunakan konteks OpenGL 2.0 atau 3.x untuk merender kontennya. Wallpaper hidup tidak akan berjalan dengan andal di hardware yang tidak mendukung beberapa konteks OpenGL karena penggunaan konteks OpenGL oleh wallpaper hidup dapat bertentangan dengan aplikasi lain yang juga menggunakan konteks OpenGL.

Implementasi perangkat yang mampu menjalankan wallpaper animasi dengan andal seperti yang dijelaskan di atas HARUS mengimplementasikan wallpaper animasi, dan saat diimplementasikan HARUS melaporkan flag fitur platform android.software.live_wallpaper.

3.8.8. Peralihan Aktivitas

Kode sumber Android upstream menyertakan layar ringkasan [Referensi, 37], antarmuka pengguna tingkat sistem untuk beralih tugas dan menampilkan aktivitas dan tugas yang baru-baru ini diakses menggunakan gambar thumbnail status grafis aplikasi pada saat pengguna terakhir kali keluar dari aplikasi. Implementasi perangkat termasuk tombol navigasi fungsi terbaru seperti yang dijelaskan dalam bagian 7.2.3, DAPAT mengubah antarmuka, tetapi HARUS memenuhi persyaratan berikut:

• HARUS menampilkan video terbaru yang berafiliasi sebagai grup yang bergerak bersama.
• HARUS mendukung minimal hingga 6 aktivitas yang ditampilkan.
• HARUS setidaknya menampilkan judul 4 aktivitas sekaligus.
• HARUS menampilkan warna sorotan, ikon, judul layar di terbaru.
• HARUS menerapkan perilaku penyematan layar [Referensi, 38] dan memberi pengguna menu setelan untuk mengaktifkan/menonaktifkan fitur.
• HARUS menampilkan kemampuan penutupan ("x") tetapi DAPAT menundanya hingga pengguna berinteraksi dengan layar.

IMPLEMENTASI PERANGKAT SANGAT DISARANKAN untuk menggunakan antarmuka pengguna Android upstream (atau antarmuka berbasis thumbnail serupa) untuk layar ringkasan.

3.8.9. Pengelolaan Input

Android menyertakan dukungan untuk Pengelolaan Input dan dukungan untuk editor metode input pihak ketiga [Referensi, 39]. Implementasi perangkat yang memungkinkan pengguna menggunakan metode input pihak ketiga di perangkat HARUS mendeklarasikan fitur platform android.software.input_methods dan mendukung IME API seperti yang ditentukan dalam dokumentasi Android SDK.

Implementasi perangkat yang mendeklarasikan fitur android.software.input_methods HARUS menyediakan mekanisme yang dapat diakses pengguna untuk menambahkan dan mengonfigurasi metode input pihak ketiga. Implementasi perangkat HARUS menampilkan antarmuka setelan sebagai respons terhadap intent android.settings.INPUT_METHOD_SETTINGS.

3.8.10. Kontrol Media Layar Kunci

Remote Control Client API tidak digunakan lagi mulai Android 5.0 dan diganti dengan Template Notifikasi Media yang memungkinkan aplikasi media berintegrasi dengan kontrol pemutaran yang ditampilkan di layar kunci [Referensi, 40] sebagai Notifikasi layar kunci. Implementasi perangkat HARUS merender Template Notifikasi Media secara benar sebagai bagian dari notifikasi Layar kunci yang dijelaskan di bagian 3.8.3.

3.8.11. Mimpi

Android menyertakan dukungan untuk screensaver interaktif yang disebut Dreams [Referensi, 41]. Dreams memungkinkan pengguna berinteraksi dengan aplikasi saat perangkat yang terhubung ke sumber daya tidak ada aktivitas atau disambungkan ke dok meja. Perangkat Android Watch DAPAT menerapkan Dreams, tetapi jenis implementasi perangkat lainnya HARUS menyertakan dukungan untuk Dreams dan memberikan opsi setelan bagi pengguna untuk mengonfigurasi Dreams sebagai respons terhadap intent android.settings.DREAM_SETTINGS.

3.8.12. Lokasi

Jika perangkat memiliki sensor hardware (misalnya GPS) yang mampu memberikan koordinat lokasi, mode lokasi HARUS ditampilkan di menu Lokasi dalam Setelan [Referensi, 42].

3.8.13. Unicode dan Font

Android menyertakan dukungan untuk karakter emoji warna. Jika implementasi perangkat Android menyertakan IME, perangkat HARUS menyediakan metode input kepada pengguna untuk karakter Emoji yang ditentukan dalam Unicode 6.1 [Referensi, 43]. Semua perangkat HARUS dapat merender karakter emoji ini dalam glyph warna.

Android menyertakan dukungan untuk font Roboto 2 dengan ketebalan yang berbeda—sans-serif-tipis, sans-serif-terang, sans-serif-sedang, sans-serif-hitam, sans-serif-rapat, sans-serif-rapat-terang—yang HARUS disertakan untuk bahasa yang tersedia di perangkat dan cakupan Unicode 7.0 lengkap untuk Latin, Yunani, dan Sirilik, termasuk rentang Latin Extended A, B, C, dan D, serta semua glyph dalam blok simbol mata uang Unicode 7.0.

3.9. Administrasi Perangkat

Android menyertakan fitur yang memungkinkan aplikasi yang peka keamanan untuk menjalankan fungsi administrasi perangkat di tingkat sistem, seperti menerapkan kebijakan sandi atau melakukan penghapusan total dari jarak jauh, melalui Android Device Administration API [Referensi, 44]. Implementasi perangkat HARUS menyediakan implementasi class DevicePolicyManager [Referensi, 45]. Implementasi perangkat yang menyertakan dukungan untuk layar kunci berbasis PIN (numerik) atau SANDI (alfanumerik) HARUS mendukung berbagai kebijakan administrasi perangkat yang ditentukan dalam dokumentasi Android SDK [Referensi, 44] dan melaporkan fitur platform android.software.device_admin.

3.9.1 Penyediaan Perangkat

3.9.1.1 Penyediaan pemilik perangkat

Jika implementasi perangkat mendeklarasikan fitur android.software.device_admin, alur penyiapan siap pakai HARUS memungkinkan pendaftaran aplikasi Pengontrol Kebijakan Perangkat (DPC) sebagai aplikasi Pemilik Perangkat [ Referensi, 46]. Implementasi perangkat DAPAT memiliki aplikasi bawaan yang menjalankan fungsi administrasi perangkat, tetapi aplikasi ini TIDAK BOLEH ditetapkan sebagai aplikasi Pemilik Perangkat tanpa izin atau tindakan eksplisit dari pengguna atau administrator perangkat.

Pengalaman pengguna proses penyediaan pemilik perangkat (alur yang dimulai oleh android.app.action.PROVISION_MANAGED_DEVICE [ Resources, 47]) HARUS selaras dengan penerapan AOSP

Jika implementasi perangkat melaporkan android.hardware.nfc, perangkat HARUS mengaktifkan NFC, bahkan selama alur penyiapan siap pakai, untuk memungkinkan penyediaan NFC Pemilik perangkat [Referensi, 48].

3.9.1.2 Penyediaan profil terkelola

Jika implementasi perangkat mendeklarasikan android.software.managed_users, aplikasi Pengontrol Kebijakan Perangkat (DPC) HARUS dapat didaftarkan sebagai pemilik Profil Terkelola baru [ Referensi, 49]

Pengalaman pengguna proses penyediaan profil terkelola (alur yang dimulai oleh android.app.action.PROVISION_MANAGED_PROFILE [ Resource, 50]) HARUS selaras dengan implementasi AOSP

3.9.2 Dukungan Profil Terkelola

Perangkat yang kompatibel dengan profil terkelola adalah perangkat yang:

• Deklarasikan android.software.device_admin (lihat bagian 3.9 Administrasi Perangkat)
• Bukan perangkat dengan RAM rendah (lihat bagian 7.6.1
• Mengalokasikan penyimpanan internal (tidak dapat dilepas) sebagai penyimpanan bersama (lihat bagian 7.6.2)

Perangkat yang kompatibel dengan profil terkelola HARUS:

• Deklarasikan flag fitur platform android.software.managed_users.
• Mendukung profil terkelola melalui API android.app.admin.DevicePolicyManager
• Mengizinkan satu dan hanya satu profil terkelola yang dibuat [Referensi, 50]
• Gunakan badge ikon (mirip dengan badge pekerjaan upstream AOSP) untuk merepresentasikan aplikasi dan widget terkelola serta elemen UI berbadge lainnya seperti Terbaru & Notifikasi
• Menampilkan ikon notifikasi (mirip dengan badge kerja upstream AOSP) untuk menunjukkan saat pengguna berada dalam aplikasi profil terkelola
• Menampilkan toast yang menunjukkan bahwa pengguna berada dalam profil terkelola jika dan saat perangkat aktif (ACTION_USER_PRESENT) dan aplikasi latar depan berada dalam profil terkelola
• Jika profil terkelola ada, tampilkan kemampuan visual di Intent 'Chooser' untuk mengizinkan pengguna meneruskan intent dari profil terkelola ke pengguna utama atau sebaliknya, jika diaktifkan oleh Pengontrol Kebijakan Perangkat
• Jika profil terkelola ada, tampilkan kemampuan pengguna berikut untuk pengguna utama dan profil terkelola:
  • Akuntansi terpisah untuk penggunaan baterai, lokasi, data seluler, dan penyimpanan untuk pengguna utama dan profil terkelola.
  • Pengelolaan independen Aplikasi VPN yang diinstal dalam pengguna utama atau profil terkelola.
  • Pengelolaan independen aplikasi yang diinstal dalam pengguna utama atau profil terkelola.
  • Pengelolaan akun secara independen dalam profil pengguna utama atau terkelola.
• Pastikan dialer default dapat mencari informasi pemanggil dari profil terkelola (jika ada) bersama dengan informasi dari profil utama, jika Pengontrol Kebijakan Perangkat mengizinkannya.
• HARUS memastikan bahwa profil tersebut memenuhi semua persyaratan keamanan yang berlaku untuk perangkat dengan beberapa pengguna yang diaktifkan (lihat bagian 9.5), meskipun profil terkelola tidak dihitung sebagai pengguna lain selain pengguna utama.

3.10. Aksesibilitas

Android menyediakan lapisan aksesibilitas yang membantu pengguna difabel menavigasi perangkat mereka dengan lebih mudah. Selain itu, Android menyediakan API platform yang memungkinkan implementasi layanan aksesibilitas menerima callback untuk peristiwa pengguna dan sistem serta menghasilkan mekanisme masukan alternatif, seperti text-to-speech, haptic feedback, dan navigasi trackball/d-pad [Referensi, 51].

Implementasi perangkat mencakup persyaratan berikut:

• Penerapan Android Automotive HARUS menyediakan penerapan framework aksesibilitas Android yang konsisten dengan penerapan Android default.
• Implementasi perangkat (Android Automotive dikecualikan) HARUS menyediakan implementasi framework aksesibilitas Android yang konsisten dengan implementasi Android default.
• Implementasi perangkat (Android Automotive dikecualikan) HARUS mendukung implementasi layanan aksesibilitas pihak ketiga melalui API android.accessibilityservice [Referensi, 52]
• Implementasi perangkat (Android Automotive dikecualikan) HARUS menghasilkan AccessibilityEvents dan mengirimkan peristiwa ini ke semua implementasi AccessibilityService terdaftar dengan cara yang konsisten dengan implementasi Android default
• Implementasi perangkat (perangkat Android Automotive dan Android Watch tanpa mengecualikan output audio), HARUS menyediakan mekanisme yang dapat diakses pengguna untuk mengaktifkan dan menonaktifkan layanan aksesibilitas, dan HARUS menampilkan antarmuka ini sebagai respons terhadap intent android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS.

Selain itu, implementasi perangkat HARUS menyediakan implementasi layanan aksesibilitas di perangkat, dan HARUS menyediakan mekanisme bagi pengguna untuk mengaktifkan layanan aksesibilitas selama penyiapan perangkat. Implementasi open source layanan aksesibilitas tersedia dari project Eyes Free [Referensi, 53].

3.11. Text-to-Speech

Android menyertakan API yang memungkinkan aplikasi menggunakan layanan text-to-speech (TTS) dan memungkinkan penyedia layanan menyediakan implementasi layanan TTS [Referensi, 54]. Implementasi perangkat yang melaporkan fitur android.hardware.audio.output HARUS memenuhi persyaratan ini yang terkait dengan framework TTS Android.

Implementasi Android Automotive:

• HARUS mendukung API framework TTS Android.
• DAPAT mendukung penginstalan mesin TTS pihak ketiga. Jika didukung, partner HARUS menyediakan antarmuka yang dapat diakses pengguna yang memungkinkan pengguna memilih mesin TTS untuk digunakan di tingkat sistem.

Semua implementasi perangkat lainnya:

• HARUS mendukung API framework TTS Android dan HARUS menyertakan mesin TTS yang mendukung bahasa yang tersedia di perangkat. Perhatikan bahwa software open source upstream Android menyertakan implementasi mesin TTS yang lengkap.
• HARUS mendukung penginstalan mesin TTS pihak ketiga
• HARUS menyediakan antarmuka yang dapat diakses pengguna yang memungkinkan pengguna memilih mesin TTS untuk digunakan di tingkat sistem

3.12. Framework Input TV

Android Television Input Framework (TIF) menyederhanakan pengiriman konten live ke perangkat Android Television. TIF menyediakan API standar untuk membuat modul input yang mengontrol perangkat Android Television. Implementasi perangkat Android Television HARUS mendukung Framework Input TV [Referensi, 55].

Implementasi perangkat yang mendukung TIF HARUS mendeklarasikan fitur platform android.software.live_tv.

3.12.1. Aplikasi TV

Setiap implementasi perangkat yang mendeklarasikan dukungan untuk TV Live HARUS memiliki aplikasi TV (Aplikasi TV) yang diinstal. Project Open Source Android menyediakan implementasi Aplikasi TV.

Aplikasi TV default harus memberikan akses ke saluran dari input yang diinstal dan input pihak ketiga. Perhatikan bahwa input yang diinstal mencakup semua input yang disediakan secara default, baik berbasis TIF maupun tidak.

Aplikasi TV HARUS menyediakan fasilitas untuk menginstal dan menggunakan Saluran TV [Referensi, 56] dan memenuhi persyaratan berikut:

• Implementasi perangkat HARUS mengizinkan input berbasis TIF pihak ketiga (input pihak ketiga) [Referensi, 57] untuk diinstal dan dikelola.
• Implementasi perangkat DAPAT memberikan pemisahan visual antara input berbasis TIF yang telah diinstal sebelumnya (input terinstal) [Referensi, 58] dan input pihak ketiga.
• Implementasi perangkat TIDAK BOLEH menampilkan input pihak ketiga lebih dari satu tindakan navigasi dari Aplikasi TV (yaitu memperluas daftar input pihak ketiga dari Aplikasi TV).

3.12.1.1. Panduan Program Elektronik

Implementasi perangkat Android Television HARUS menampilkan overlay informatif dan interaktif, yang HARUS menyertakan panduan program elektronik (EPG) yang dihasilkan dari nilai di kolom TvContract.Programs [Resources, 59]. EPG HARUS memenuhi persyaratan berikut:

• EPG HARUS menampilkan informasi dari semua input yang diinstal dan input pihak ketiga.
• EPG DAPAT memberikan pemisahan visual antara input yang diinstal dan input pihak ketiga.
• EPG SANGAT DISARANKAN untuk menampilkan input yang diinstal dan input pihak ketiga dengan keterlihatan yang sama. EPG TIDAK BOLEH menampilkan input pihak ketiga lebih dari satu tindakan navigasi dari input yang diinstal di EPG.
• Saat saluran berubah, implementasi perangkat HARUS menampilkan data EPG untuk program yang sedang diputar.

3.12.1.2. Navigasi

Perangkat input perangkat Android Television (yaitu remote control, aplikasi remote control, atau pengontrol game) HARUS mengizinkan navigasi ke semua bagian layar yang dapat ditindaklanjuti melalui D-pad. Tombol arah atas dan bawah HARUS digunakan untuk mengubah saluran TV live jika tidak ada bagian yang dapat ditindaklanjuti di layar.

Aplikasi TV HARUS meneruskan peristiwa utama ke input HDMI melalui CEC.

3.12.1.3. Penautan aplikasi input TV

Implementasi perangkat Android Television HARUS mendukung penautan aplikasi input TV, yang memungkinkan semua input memberikan link aktivitas dari aktivitas saat ini ke aktivitas lain (yaitu link dari program live ke konten terkait) [Referensi, 60]. Aplikasi TV HARUS menampilkan penautan aplikasi input TV saat disediakan.

4. Kompatibilitas Pengemasan Aplikasi

Implementasi perangkat HARUS menginstal dan menjalankan file “.apk” Android seperti yang dihasilkan oleh alat “aapt” yang disertakan dalam Android SDK resmi [Referensi, 61].

Implementasi perangkat TIDAK BOLEH memperluas format .apk [Resources, 62], Manifes Android [Resources, 49], bytecode Dalvik [Resources, 23], atau bytecode RenderScript sedemikian rupa sehingga mencegah file tersebut diinstal dan berjalan dengan benar di perangkat lain yang kompatibel.

5. Kompatibilitas Multimedia

5.1. Codec Media

Implementasi perangkat HARUS mendukung format media inti yang ditentukan dalam dokumentasi Android SDK [Referensi, 64] kecuali jika diizinkan secara eksplisit dalam dokumen ini. Secara khusus, implementasi perangkat HARUS mendukung format media, encoder, decoder, jenis file, dan format penampung yang ditentukan dalam tabel di bawah dan dilaporkan melalui MediaCodecList [Referensi, 65]. Implementasi perangkat JUGA HARUS dapat mendekode semua profil yang dilaporkan di CamcorderProfile-nya [Referensi, 66] dan HARUS dapat mendekode semua format yang dapat dienkode. Semua codec ini disediakan sebagai implementasi software dalam implementasi Android yang diinginkan dari Project Open Source Android.

Perlu diperhatikan bahwa baik Google maupun Open Handset Alliance tidak membuat pernyataan apa pun bahwa codec ini bebas dari paten pihak ketiga. Bagi mereka yang ingin menggunakan kode sumber ini dalam produk hardware atau software, sebaiknya implementasi kode ini, termasuk dalam software open source atau shareware, mungkin memerlukan lisensi paten dari pemegang paten yang relevan.

5.1.1. Codec Audio

Format/Codec	Encoder	Decoder	Detail	Jenis File/Format Penampung yang Didukung
Profil AAC MPEG-4 (AAC LC)	WAJIB1	WAJIB	Dukungan untuk konten mono/stereo/5.0/5.12 dengan frekuensi pengambilan sampel standar dari 8 hingga 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS raw AAC (.aac, dekode di Android 3.1+, enkode di Android 4.0+, ADIF tidak didukung) MPEG-TS (.ts, tidak dapat digeser, Android 3.0+)
Profil MPEG-4 HE AAC (AAC+)	WAJIB1 (Android 4.1+)	WAJIB	Dukungan untuk konten mono/stereo/5.0/5.12 dengan frekuensi pengambilan sampel standar dari 16 hingga 48 kHz.
Profil MPEG-4 HE AACv2 (AAC+ ditingkatkan)		WAJIB	Dukungan untuk konten mono/stereo/5.0/5.12 dengan frekuensi pengambilan sampel standar dari 16 hingga 48 kHz.
AAC ELD (AAC yang ditingkatkan dengan delay rendah)	WAJIB1 (Android 4.1+)	WAJIB (Android 4.1+)	Dukungan untuk konten mono/stereo dengan frekuensi sampling standar dari 16 hingga 48 kHz.
AMR-NB	WAJIB3	WAJIB3	4,75 hingga 12,2 kbps dengan sampel @ 8 kHz	3GPP (.3gp)
AMR-WB	WAJIB3	WAJIB3	9 frekuensi dari 6,60 kbit/dtk hingga 23,85 kbit/dtk dengan sampel @ 16 kHz
FLAC		WAJIB (Android 3.1+)	Mono/Stereo (tanpa multisaluran). Frekuensi pengambilan sampel hingga 48 kHz (tetapi direkomendasikan hingga 44,1 kHz di perangkat dengan output 44,1 kHz, karena penurun sampel 48 hingga 44,1 kHz tidak menyertakan filter tingkat rendah). 16-bit DIUTAMAKAN; tidak ada dither yang diterapkan untuk 24-bit.	Hanya FLAC (.flac)
MP3		WAJIB	Mono/Stereo 8-320 Kbps konstan (CBR) atau kecepatan bit variabel (VBR)	MP3 (.mp3)
MIDI		WAJIB	MIDI Jenis 0 dan 1. DLS Versi 1 dan 2. XMF dan Mobile XMF. Dukungan untuk format nada dering RTTTL/RTX, OTA, dan iMelody	Jenis 0 dan 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) OTA (.ota) iMelody (.imy)
Vorbis		WAJIB		Ogg (.ogg) Matroska (.mkv, Android 4.0+)
PCM/WAVE	WAJIB4 (Android 4.1+)	WAJIB	PCM linear 16-bit (frekuensi hingga batas hardware). Perangkat HARUS mendukung frekuensi sampling untuk perekaman PCM mentah pada frekuensi 8.000, 11.025, 16.000, dan 44.100 Hz.	WAVE (.wav)
Opus		WAJIB (Android 5.0+)		Matroska (.mkv)

1 Diperlukan untuk implementasi perangkat yang menentukan android.hardware.microphone, tetapi opsional untuk implementasi perangkat Android Watch.

2 Hanya downmix konten 5.0/5.1 yang diperlukan; perekaman atau rendering lebih dari 2 saluran bersifat opsional.

3 Diperlukan untuk penerapan perangkat Genggam Android.

4 Diperlukan untuk implementasi perangkat yang menentukan android.hardware.microphone, termasuk implementasi perangkat Android Watch.

5.1.2. Codec Gambar

Format/Codec	Encoder	Decoder	Detail	Jenis File/Format Penampung yang Didukung
JPEG	WAJIB	WAJIB	Dasar+progresif	JPEG (.jpg)
GIF		WAJIB		GIF (.gif)
PNG	WAJIB	WAJIB		PNG (.png)
BMP		WAJIB		BMP (.bmp)
WebP	WAJIB	WAJIB		WebP (.webp)

5.1.3. Codec Video

Format/Codec	Encoder	Decoder	Detail	Jenis File/ Format Penampung yang Didukung
H.263	WAJIB1	WAJIB2		3GPP (.3gp) MPEG-4 (.mp4)
H.264 AVC	WAJIB2	WAJIB2	Lihat bagian 5.2 dan 5.3 untuk mengetahui detailnya	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, AAC hanya audio, tidak dapat digeser, Android 3.0+)
H.265 HEVC		WAJIB5	Lihat bagian 5.3 untuk mengetahui detailnya	MPEG-4 (.mp4)
MPEG-2		SANGAT DIREKOMENDASIKAN6	Profil Utama	MPEG2-TS
MPEG-4 SP		WAJIB2		3GPP (.3gp)
VP83	WAJIB2 (Android 4.3+)	WAJIB2 (Android 2.3.3+)	Lihat pasal 5.2 dan 5.3 untuk mengetahui detailnya	WebM (.webm) [Referensi, 67 Matroska (.mkv, Android 4.0+)4
VP9		WAJIB2 (Android 4.4+)	Lihat bagian 5.3 untuk mengetahui detailnya	WebM (.webm) [Referensi, 67] Matroska (.mkv, Android 4.0+)4

1 Diperlukan untuk implementasi perangkat yang menyertakan hardware kamera dan menentukan android.hardware.camera atau android.hardware.camera.front.

2 Diperlukan untuk penerapan perangkat, kecuali perangkat Android Watch.

3 Untuk kualitas streaming video web dan layanan konferensi video yang dapat diterima, implementasi perangkat HARUS menggunakan codec VP8 hardware yang memenuhi persyaratan di [Referensi, 68].

4 Implementasi perangkat HARUS mendukung penulisan file Matroska WebM.

5 SANGAT DIUTAMAKAN untuk Android Automotive, opsional untuk Android Watch, dan diperlukan untuk semua jenis perangkat lainnya.

6 Hanya berlaku untuk implementasi perangkat Android Television.

5.2. Encoding Video

Penerapan perangkat Android dengan encoder H.263, HARUS mendukung Profil Dasar Pengukuran Level 45.

Implementasi perangkat Android dengan dukungan codec H.264, HARUS mendukung Profil Dasar Pengukuran Level 3 dan profil encoding video SD (Standar Definisi) berikut dan HARUS mendukung Profil Utama Level 4 dan profil encoding video HD (High Definition) berikut. Perangkat Android TV SANGAT DISARANKAN untuk mengenkode video HD 1080p pada kecepatan 30 fps.

	SD (Kualitas rendah)	SD (Kualitas tinggi)	HD 720p1	HD 1080p1
Resolusi video	320 x 240 px	720 x 480 piksel	1280 x 720 px	1920 x 1080 px
Frekuensi gambar video	20 fps	30 fps	30 fps	30 fps
Kecepatan bit video	384 Kbps	2 Mbps	4 Mbps	10 Mbps

1 Jika didukung oleh hardware, tetapi SANGAT DISARANKAN untuk perangkat Android Television.

Implementasi perangkat Android dengan dukungan codec VP8 HARUS mendukung profil encoding video SD dan HARUS mendukung profil encoding video HD (High Definition) berikut.

	SD (Kualitas rendah)	SD (Kualitas tinggi)	HD 720p1	HD 1080p1
Resolusi video	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px
Frekuensi gambar video	30 fps	30 fps	30 fps	30 fps
Kecepatan bit video	800 Kbps	2 Mbps	4 Mbps	10 Mbps

1 Jika didukung oleh hardware.

5.3. Dekode Video

Implementasi perangkat HARUS mendukung resolusi video dinamis dan peralihan frekuensi gambar melalui API Android standar dalam aliran yang sama untuk semua codec VP8, VP9, H.264, dan H.265 secara real time dan hingga resolusi maksimal yang didukung oleh setiap codec di perangkat.

Implementasi perangkat Android dengan dekoder H.263, HARUS mendukung Profil Dasar Pengukuran Level 30.

Implementasi perangkat Android dengan dekoder MPEG-4, HARUS mendukung Profil Sederhana Level 3.

Penerapan perangkat Android dengan decoder H.264, HARUS mendukung Profil Utama Level 3.1 dan profil decoding video SD berikut dan HARUS mendukung profil decoding HD. Perangkat Android Television HARUS mendukung Profil Tinggi Level 4.2 dan profil decoding HD 1080p.

	SD (Kualitas rendah)	SD (Kualitas tinggi)	HD 720p1	HD 1080p1
Resolusi video	320 x 240 px	720 x 480 piksel	1280 x 720 px	1920 x 1080 px
Frekuensi gambar video	30 fps	30 fps	60 fps	30 fps / 60 fps2
Kecepatan bit video	800 Kbps	2 Mbps	8 Mbps	20 Mbps

1 WAJIB untuk saat tinggi seperti yang dilaporkan oleh metode Display.getSupportedModes() sama dengan atau lebih besar dari resolusi video.

2 DIPERLUKAN untuk penerapan perangkat Android Television.

Implementasi perangkat Android saat mendukung codec VP8 seperti yang dijelaskan dalam bagian 5.1.3, HARUS mendukung profil decoding SD berikut dan HARUS mendukung profil decoding HD. Perangkat Android Television HARUS mendukung profil dekode HD 1080p.

	SD (Kualitas rendah)	SD (Kualitas tinggi)	HD 720p1	HD 1080p1
Resolusi video	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px
Frekuensi gambar video	30 fps	30 fps	30 fps / 60 fps2	30 / 60 fps2
Kecepatan bit video	800 Kbps	2 Mbps	8 Mbps	20 Mbps

1 WAJIB untuk saat tinggi seperti yang dilaporkan oleh metode Display.getSupportedModes() sama dengan atau lebih besar dari resolusi video.

2 DIPERLUKAN untuk penerapan perangkat Android Television.

Implementasi perangkat Android, saat mendukung codec VP9 seperti yang dijelaskan di bagian 5.1.3, HARUS mendukung profil decoding video SD berikut dan HARUS mendukung profil decoding HD. Perangkat Android Television SANGAT DIUJAMI untuk mendukung profil decoding HD 1080p dan HARUS mendukung profil decoding UHD. Jika didukung, profil decoding video UHD HARUS mendukung kedalaman warna 8-bit dan HARUS mendukung Profil VP9 2 (10-bit).

	SD (Kualitas rendah)	SD (Kualitas tinggi)	HD 720p1	HD 1080p2	UHD2
Resolusi video	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 piksel
Frekuensi gambar video	30 fps	30 fps	30 fps	60 fps	60 fps
Kecepatan bit video	600 Kbps	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

1 Diperlukan untuk implementasi perangkat Android Television, tetapi untuk jenis perangkat lain hanya jika didukung oleh hardware.

2 SANGAT DISARANKAN untuk implementasi perangkat Android Television yang ada jika didukung oleh hardware.

Implementasi perangkat Android, saat mendukung codec H.265 seperti yang dijelaskan dalam bagian 5.1.3, HARUS mendukung tingkat Utama Profil Utama Level 3 dan profil decoding video SD berikut dan HARUS mendukung profil decoding HD. Perangkat Android TV SANGAT DIUJAMI untuk mendukung profil decoding UHD dan profil decoding HD 1080p. Jika didukung, profil decoding HD 1080p HARUS mendukung tingkat Utama Profil Utama Level 4.1. Jika dekode UHD didukung, dekode UHD HARUS mendukung profil Tingkat Utama Main10 Level 5.

	SD (Kualitas rendah)	SD (Kualitas tinggi)	HD 720p1	HD 1080p2	UHD2
Resolusi video	352 x 288 piksel	640 x 360 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 piksel
Frekuensi gambar video	30 fps	30 fps	30 fps	60 fps2	60 fps
Kecepatan bit video	600 Kbps	1,6 Mbps	4 Mbps	10 Mbps	20 Mbps

1 Diperlukan untuk implementasi perangkat Android Television, tetapi untuk jenis perangkat lain hanya jika didukung oleh hardware.

2 SANGAT DISARANKAN untuk implementasi perangkat Android Television yang ada jika didukung oleh hardware.

5.4. Perekaman Audio

Meskipun beberapa persyaratan yang diuraikan di bagian ini dinyatakan sebagai HARUS sejak Android 4.3, Definisi Kompatibilitas untuk versi mendatang direncanakan untuk mengubahnya menjadi HARUS. Perangkat Android yang ada dan baru SANGAT DISARANKAN untuk memenuhi persyaratan ini yang dinyatakan sebagai HARUS, atau perangkat tidak akan dapat mencapai kompatibilitas Android saat diupgrade ke versi mendatang.

5.4.1. Perekaman Audio Mentah

Implementasi perangkat yang mendeklarasikan android.hardware.microphone HARUS mengizinkan perekaman konten audio mentah dengan karakteristik berikut:

• Format: PCM Linear, 16-bit
• Frekuensi sampling: 8000, 11025, 16000, 44100
• Saluran: Mono

Perekaman untuk frekuensi sampel di atas HARUS dilakukan tanpa up-sampling, dan down-sampling apa pun HARUS menyertakan filter anti-aliasing yang sesuai.

Implementasi perangkat yang mendeklarasikan android.hardware.microphone HARUS mengizinkan perekaman konten audio mentah dengan karakteristik berikut:

• Format: PCM Linear, 16-bit
• Frekuensi sampling: 22050, 48000
• Saluran: Stereo

Jika pengambilan untuk frekuensi sampel di atas didukung, pengambilan HARUS dilakukan tanpa up-sampling pada rasio apa pun yang lebih tinggi dari 16000:22050 atau 44100:48000. Setiap upsampling atau downsampling HARUS menyertakan filter anti-aliasing yang sesuai.

5.4.2. Merekam untuk Pengenalan Suara

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

• Perangkat HARUS menunjukkan karakteristik amplitudo versus frekuensi yang kira-kira datar: khususnya, ±3 dB, dari 100 Hz hingga 4.000 Hz.
• Sensitivitas input audio HARUS disetel sedemikian rupa sehingga sumber level daya suara (SPL) 90 dB pada 1.000 Hz menghasilkan RMS 2.500 untuk sampel 16-bit.
• Level amplitudo PCM HARUS melacak perubahan SPL input secara linear dalam rentang setidaknya 30 dB dari -18 dB hingga +12 dB re 90 dB SPL di mikrofon.
• Total harmonic distortion HARUS kurang dari 1% untuk 1 kHz pada level input SPL 90 dB di mikrofon.
• Pemrosesan pengurangan bising, jika ada, HARUS dinonaktifkan.
• Automatic gain control, jika ada, HARUS dinonaktifkan

Jika platform mendukung teknologi peredam bising yang disesuaikan untuk pengenalan ucapan, efeknya HARUS dapat dikontrol dari android.media.audiofx.NoiseSuppressor API. Selain itu, kolom UUID untuk deskripsi efek peredam bising HARUS mengidentifikasi setiap implementasi teknologi peredam bising secara unik.

5.4.3. Perekaman untuk Pemutaran yang Diarahkan Ulang

Class android.media.MediaRecorder.AudioSource menyertakan sumber audio REMOTE_SUBMIX. Perangkat yang mendeklarasikan android.hardware.audio.output HARUS menerapkan sumber audio REMOTE_SUBMIX dengan benar sehingga saat aplikasi menggunakan android.media.AudioRecord API untuk merekam dari sumber audio ini, aplikasi dapat merekam gabungan semua streaming audio kecuali untuk hal berikut:

• STREAM_RING
• STREAM_ALARM
• STREAM_NOTIFICATION

5.5. Pemutaran Audio

Implementasi perangkat yang mendeklarasikan android.hardware.audio.output HARUS sesuai dengan persyaratan di bagian ini.

5.5.1. Pemutaran Audio Mentah

Perangkat HARUS mengizinkan pemutaran konten audio mentah dengan karakteristik berikut:

• Format: PCM Linear, 16-bit
• Rasio sampling: 8000, 11025, 16000, 22050, 32000, 44100
• Saluran: Mono, Stereo

Perangkat HARUS mengizinkan pemutaran konten audio mentah dengan karakteristik berikut:

• Rasio sampling: 24.000, 48.000

5.5.2. Efek Audio

Android menyediakan API untuk efek audio untuk implementasi perangkat [Referensi, 69]. Implementasi perangkat yang mendeklarasikan fitur android.hardware.audio.output:

• HARUS mendukung implementasi EFFECT_TYPE_EQUALIZER dan EFFECT_TYPE_LOUDNESS_ENHANCER yang dapat dikontrol melalui subclass AudioEffect Equalizer, LoudnessEnhancer.
• HARUS mendukung penerapan API visualizer, yang dapat dikontrol melalui class Visualizer.
• HARUS mendukung implementasi EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB, dan EFFECT_TYPE_VIRTUALIZER yang dapat dikontrol melalui sub-class AudioEffect BassBoost, EnvironmentalReverb, PresetReverb, dan Virtualizer.

5.5.3. Volume Output Audio

Implementasi perangkat Android Television HARUS menyertakan dukungan untuk Volume Master sistem dan atenuasi volume output audio digital pada output yang didukung, kecuali untuk output passthrough audio yang dikompresi (jika tidak ada dekode audio yang dilakukan di perangkat).

5.6. Latensi Audio

Latensi audio adalah penundaan waktu saat sinyal audio melewati sistem. Banyak class aplikasi mengandalkan latensi singkat, untuk mendapatkan efek suara real-time.

Untuk tujuan bagian ini, gunakan definisi berikut:

• latensi output. Interval antara saat aplikasi menulis frame data yang dienkode PCM dan saat suara yang sesuai dapat didengar oleh pemroses eksternal atau diamati oleh transduser.
• latensi output dingin. Latensi output untuk frame pertama, saat sistem output audio telah tidak ada aktivitas dan dimatikan sebelum permintaan.
• latensi output berkelanjutan. Latensi output untuk frame berikutnya, setelah perangkat memutar audio.
• latensi input. Interval antara saat suara eksternal ditampilkan ke perangkat dan saat aplikasi membaca frame data yang dienkode PCM yang sesuai.
• latensi input dingin. Jumlah waktu input yang hilang dan latensi input untuk frame pertama, saat sistem input audio tidak ada aktivitas dan dimatikan sebelum permintaan.
• latensi input berkelanjutan. Latensi input untuk frame berikutnya, saat perangkat merekam audio.
• jitter output dingin. Variansi di antara pengukuran terpisah dari nilai latensi output dingin.
• jitter input dingin. Varians di antara pengukuran terpisah dari nilai latensi input dingin.
• latensi bolak-balik berkelanjutan. Jumlah latensi input berkelanjutan ditambah latensi output berkelanjutan ditambah satu periode buffering. Istilah periode buffering memungkinkan waktu pemrosesan untuk aplikasi dan untuk mengurangi perbedaan fase antara aliran input dan output.
• OpenSL ES PCM buffer queue API. Kumpulan OpenSL ES API terkait PCM dalam Android NDK; lihat NDK_root/docs/opensles/index.html.

Implementasi perangkat yang mendeklarasikan android.hardware.audio.output SANGAT DISARANKAN untuk memenuhi atau melebihi persyaratan output audio ini:

• latensi output cold 100 milidetik atau kurang
• latensi output kontinu sebesar 45 milidetik atau kurang
• meminimalkan jitter output dingin

Jika implementasi perangkat memenuhi persyaratan bagian ini setelah kalibrasi awal saat menggunakan API antrean buffering PCM OpenSL ES, untuk latensi output berkelanjutan dan latensi output dingin di setidaknya satu perangkat output audio yang didukung, SANGAT DISARANKAN untuk melaporkan dukungan untuk audio latensi rendah, dengan melaporkan fitur android.hardware.audio.low_latency melalui class android.content.pm.PackageManager [Resources, 70]. Sebaliknya, jika implementasi perangkat tidak memenuhi persyaratan ini, Perangkat TIDAK BOLEH melaporkan dukungan untuk audio latensi rendah.

Implementasi perangkat yang menyertakan android.hardware.microphone SANGAT DISARANKAN untuk memenuhi persyaratan audio input ini:

• latensi input cold 100 milidetik atau kurang
• latensi input berkelanjutan 30 milidetik atau kurang
• latensi bolak-balik berkelanjutan sebesar 50 milidetik atau kurang
• meminimalkan jitter input dingin

5.7. Protokol Jaringan

Perangkat HARUS mendukung protokol jaringan media untuk pemutaran audio dan video seperti yang ditentukan dalam dokumentasi Android SDK [Referensi, 64]. Secara khusus, perangkat HARUS mendukung protokol jaringan media berikut:

• RTSP (RTP, SDP)
• Streaming progresif HTTP(S)
• Protokol draf Streaming Live HTTP(S), Versi 3 [Referensi, 71]

5,8. Media Aman

Implementasi perangkat yang mendukung output video aman dan mampu mendukung platform aman HARUS mendeklarasikan dukungan untuk Display.FLAG_SECURE. Implementasi perangkat yang mendeklarasikan dukungan untuk Display.FLAG_SECURE, jika mendukung protokol tampilan nirkabel, HARUS mengamankan link dengan mekanisme kriptografis yang kuat seperti HDCP 2.x atau yang lebih tinggi untuk layar nirkabel Miracast. Demikian pula, jika mendukung layar eksternal berkabel, implementasi perangkat HARUS mendukung HDCP 1.2 atau yang lebih tinggi. Penerapan perangkat Android Television HARUS mendukung HDCP 2.2 untuk perangkat yang mendukung resolusi 4K dan HDCP 1.4 atau yang lebih baru untuk resolusi yang lebih rendah. Implementasi open source Android upstream mencakup dukungan untuk layar nirkabel (Miracast) dan berkabel (HDMI) yang memenuhi persyaratan ini.

5.9. Musical Instrument Digital Interface (MIDI)

Jika implementasi perangkat mendukung transpor software MIDI antar-aplikasi (perangkat MIDI virtual), dan mendukung MIDI melalui semua transpor hardware yang kompatibel dengan MIDI berikut yang menyediakan konektivitas non-MIDI generik, SANGAT DISARANKAN untuk melaporkan dukungan untuk fitur android.software.midi melalui class android.content.pm.PackageManager [Resources, 70].

Transpor hardware yang kompatibel dengan MIDI adalah:

• Mode host USB (bagian 7.7 USB)
• Mode periferal USB (bagian 7.7 USB)

Sebaliknya, jika implementasi perangkat menyediakan konektivitas non-MIDI generik melalui transpor hardware tertentu yang kompatibel dengan MIDI yang tercantum di atas, tetapi tidak mendukung MIDI melalui transpor hardware tersebut, perangkat TIDAK BOLEH melaporkan dukungan untuk fitur android.software.midi.

MIDI melalui Bluetooth LE yang bertindak dalam peran sentral (bagian 7.4.3 Bluetooth) berada dalam status penggunaan uji coba. Implementasi perangkat yang melaporkan fitur android.software.midi, dan yang menyediakan konektivitas non-MIDI umum melalui Bluetooth LE, HARUS mendukung MIDI melalui Bluetooth LE.

5.10. Audio Profesional

Jika implementasi perangkat memenuhi semua persyaratan berikut, SANGAT DISARANKAN untuk melaporkan dukungan untuk fitur android.hardware.audio.pro melalui class android.content.pm.PackageManager [Resources, 70].

• Implementasi perangkat HARUS melaporkan dukungan untuk fitur android.hardware.audio.low_latency.
• Latensi audio bolak-balik kontinu, seperti yang ditentukan dalam bagian 5.6 Latensi Audio, HARUS 20 milidetik atau kurang dan HARUS 10 milidetik atau kurang melalui setidaknya satu jalur yang didukung.
• Jika perangkat menyertakan jack audio 3,5 mm dengan 4 konduktor, latensi audio bolak-balik kontinu HARUS 20 milidetik atau kurang melalui jalur jack audio, dan HARUS 10 milidetik atau kurang melalui jalur jack audio.
• Implementasi perangkat HARUS menyertakan port USB yang mendukung mode host USB dan mode periferal USB.
• Mode host USB HARUS menerapkan class audio USB.
• Jika perangkat menyertakan port HDMI, implementasi perangkat HARUS mendukung output dalam stereo dan delapan saluran dengan kedalaman 20-bit atau 24-bit dan 192 kHz tanpa kehilangan kedalaman bit atau pengambilan sampel ulang.
• Implementasi perangkat HARUS melaporkan dukungan untuk fitur android.software.midi.
• Jika perangkat menyertakan jack audio 3,5 mm 4 konduktor, implementasi perangkat SANGAT DISARANKAN untuk mematuhi bagian Spesifikasi perangkat seluler (jack) dari Spesifikasi Headset Audio Berkabel (v1.1).

6. Kompatibilitas Alat dan Opsi Developer

6.1. Alat Pengembang

Implementasi perangkat HARUS mendukung Alat Developer Android yang disediakan di Android SDK. Perangkat yang kompatibel dengan Android HARUS kompatibel dengan:

• Android Debug Bridge (adb) [Referensi, 72]

Implementasi perangkat HARUS mendukung semua fungsi adb seperti yang didokumentasikan dalam Android SDK termasuk dumpsys [Resources, 73]. Daemon adb sisi perangkat HARUS tidak aktif secara default dan HARUS ada mekanisme yang dapat diakses pengguna untuk mengaktifkan Android Debug Bridge. Jika implementasi perangkat menghilangkan mode periferal USB, implementasi tersebut HARUS mengimplementasikan Android Debug Bridge melalui jaringan area lokal (seperti Ethernet atau 802.11).

Android menyertakan dukungan untuk adb aman. adb aman mengaktifkan adb di host yang diautentikasi dan dikenal. Implementasi perangkat HARUS mendukung adb aman.

• Dalvik Debug Monitor Service (ddms) [Resources, 74]

Penerapan perangkat HARUS mendukung semua fitur ddms seperti yang didokumentasikan dalam Android SDK. Karena ddm menggunakan adb, dukungan untuk ddm HARUS tidak aktif secara default, tetapi HARUS didukung setiap kali pengguna mengaktifkan Android Debug Bridge, seperti di atas.

• Monkey [Resources, 75]

Implementasi perangkat HARUS menyertakan framework Monkey, dan menyediakannya untuk digunakan aplikasi.

• SysTrace [Referensi, 76]

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 mengaktifkan Systrace.

Sebagian besar sistem berbasis Linux dan sistem Apple Macintosh mengenali perangkat Android menggunakan alat Android SDK standar, tanpa dukungan tambahan; tetapi sistem Microsoft Windows biasanya memerlukan driver untuk perangkat Android baru. (Misalnya, ID vendor baru dan terkadang ID perangkat baru memerlukan driver USB kustom untuk sistem Windows.) Jika implementasi perangkat tidak dikenali oleh alat adb seperti yang disediakan di Android SDK standar, pengimplementasi perangkat HARUS menyediakan driver Windows yang memungkinkan developer terhubung ke perangkat menggunakan protokol adb. Driver ini HARUS disediakan untuk Windows XP, Windows Vista, Windows 7, Windows 8, dan Windows 10 dalam versi 32-bit dan 64-bit.

6.2. Opsi Developer

Android menyertakan dukungan bagi developer untuk mengonfigurasi setelan terkait pengembangan aplikasi. Implementasi perangkat HARUS mematuhi intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS untuk menampilkan setelan terkait pengembangan aplikasi [Referensi, 77]. Implementasi Android upstream menyembunyikan menu Opsi Developer secara default dan memungkinkan pengguna meluncurkan Opsi Developer setelah menekan tujuh (7) kali pada item menu Setelan > Tentang Perangkat > Nomor Build. Implementasi perangkat HARUS memberikan pengalaman yang konsisten untuk Opsi Developer. Secara khusus, implementasi perangkat HARUS menyembunyikan Opsi Developer secara default dan HARUS menyediakan mekanisme untuk mengaktifkan Opsi Developer yang konsisten dengan implementasi Android upstream.

7. Kompatibilitas Hardware

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

• Definisi class lengkap (seperti yang didokumentasikan oleh SDK) untuk API komponen HARUS tetap ditampilkan.
• Perilaku API HARUS diterapkan sebagai no-ops dengan cara yang wajar.
• Metode API HARUS menampilkan nilai null jika diizinkan oleh dokumentasi SDK.
• Metode API HARUS menampilkan implementasi class tanpa operasi jika nilai null tidak diizinkan oleh dokumentasi SDK.
• Metode API TIDAK BOLEH menampilkan pengecualian yang tidak didokumentasikan oleh dokumentasi SDK.

Contoh umum skenario tempat persyaratan ini berlaku adalah API telepon: bahkan di perangkat non-ponsel, API ini harus diterapkan sebagai no-op yang wajar.

Implementasi perangkat HARUS secara konsisten melaporkan informasi konfigurasi hardware yang akurat melalui metode getSystemAvailableFeatures() dan hasSystemFeature(String) di class android.content.pm.PackageManager untuk sidik jari build yang sama. [Referensi, 70]

7.1. Layar dan Grafis

Android menyertakan fasilitas yang secara otomatis menyesuaikan aset aplikasi dan tata letak UI dengan tepat untuk perangkat, guna memastikan aplikasi pihak ketiga berjalan dengan baik di berbagai konfigurasi hardware [Referensi, 78]. Perangkat HARUS menerapkan API dan perilaku ini dengan benar, seperti yang dijelaskan di bagian ini.

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

• ukuran diagonal fisik. Jarak dalam inci antara dua sudut yang berlawanan dari bagian layar yang diterangi.
• titik per inci (dpi). Jumlah piksel yang dicakup oleh rentang horizontal atau vertikal linear 1”. Jika nilai dpi tercantum, dpi horizontal dan vertikal harus berada dalam rentang.
• rasio aspek. Rasio piksel dimensi yang lebih panjang terhadap dimensi layar yang lebih pendek. Misalnya, layar 480x854 piksel akan menjadi 854/480 = 1,779, atau kira-kira “16:9”.
• piksel kepadatan mandiri (dp) Satuan piksel virtual yang dinormalisasi ke layar 160 dpi, dihitung sebagai: piksel = dps * (kepadatan/160).

7.1.1. Konfigurasi Layar

7.1.1.1. Ukuran Layar

Framework UI Android mendukung berbagai ukuran layar, dan memungkinkan aplikasi mengkueri 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 seperti yang ditentukan dalam dokumentasi Android SDK [Referensi, 78] dan ditentukan oleh platform Android upstream. Secara khusus, implementasi perangkat HARUS melaporkan ukuran layar yang benar sesuai dengan dimensi layar piksel kepadatan mandiri (dp) logis berikut.

• Perangkat HARUS memiliki ukuran layar minimal 426 dp x 320 dp (‘kecil’), kecuali perangkat Android Watch.
• Perangkat yang melaporkan ukuran layar 'normal' HARUS memiliki ukuran layar minimal 480 dp x 320 dp.
• Perangkat yang melaporkan ukuran layar 'besar' HARUS memiliki ukuran layar minimal 640 dp x 480 dp.
• Perangkat yang melaporkan ukuran layar 'xlarge' HARUS memiliki ukuran layar minimal 960 dp x 720 dp.

Selain itu,

• Perangkat Android Watch HARUS memiliki layar dengan ukuran diagonal fisik dalam rentang 1,1 hingga 2,5 inci.
• Jenis implementasi perangkat Android lainnya, dengan layar yang terintegrasi secara fisik, HARUS memiliki layar dengan ukuran diagonal fisik minimal 2,5 inci.

Perangkat TIDAK BOLEH mengubah ukuran layar yang dilaporkan kapan saja.

Aplikasi secara opsional menunjukkan ukuran layar yang didukung melalui atribut <supports-screens> dalam file AndroidManifest.xml. Implementasi perangkat HARUS mematuhi dukungan yang dinyatakan aplikasi untuk layar kecil, normal, besar, dan ekstra besar dengan benar, seperti yang dijelaskan dalam dokumentasi Android SDK.

7.1.1.2. Rasio Aspek Layar

Rasio aspek layar HARUS berupa nilai dari 1,3333 (4:3) hingga 1,86 (kira-kira 16:9), tetapi perangkat Android Watch DAPAT memiliki rasio aspek 1,0 (1:1) karena implementasi perangkat tersebut akan menggunakan UI_MODE_TYPE_WATCH sebagai android.content.res.Configuration.uiMode.

7.1.1.3. Kepadatan Layar

Framework UI Android menentukan kumpulan kepadatan logis standar untuk membantu developer aplikasi menargetkan resource aplikasi. Implementasi perangkat HARUS hanya melaporkan salah satu kepadatan framework Android logis berikut melalui API android.util.DisplayMetrics, dan HARUS menjalankan aplikasi pada kepadatan standar ini dan TIDAK BOLEH mengubah nilai kapan saja untuk layar default.

• 120 dpi (ldpi)
• 160 dpi (mdpi)
• 213 dpi (tvdpi)
• 240 dpi (hdpi)
• 280 dpi (280dpi)
• 320 dpi (xhdpi)
• 360 dpi (360dpi)
• 400 dpi (400dpi)
• 420 dpi (420dpi)
• 480 dpi (xxhdpi)
• 560 dpi (560dpi)
• 640 dpi (xxxhdpi)

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

7.1.2. Metrik Display

Implementasi perangkat HARUS melaporkan nilai yang benar untuk semua metrik tampilan yang ditentukan di android.util.DisplayMetrics [Resources, 79] dan HARUS melaporkan nilai yang sama, terlepas dari apakah layar tersemat atau eksternal digunakan sebagai tampilan default.

7.1.3. Orientasi Layar

Perangkat HARUS melaporkan orientasi layar yang didukung (android.hardware.screen.portrait dan/atau android.hardware.screen.landscape) dan HARUS melaporkan minimal satu orientasi yang didukung. Misalnya, perangkat dengan layar lanskap orientasi tetap, seperti televisi atau laptop, HANYA HARUS melaporkan android.hardware.screen.landscape.

Perangkat yang melaporkan kedua orientasi layar HARUS mendukung orientasi dinamis oleh aplikasi ke orientasi layar potret atau lanskap. Artinya, perangkat harus mematuhi 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, setiap kali dikueri 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.

7.1.4. Akselerasi Grafis 2D dan 3D

Implementasi perangkat HARUS mendukung OpenGL ES 1.0 dan 2.0, seperti yang diwujudkan dan dijelaskan dalam dokumentasi Android SDK. Implementasi perangkat HARUS mendukung OpenGL ES 3.0 atau 3.1 di perangkat yang mampu mendukungnya. Implementasi perangkat JUGA HARUS mendukung Android RenderScript, seperti yang dijelaskan dalam dokumentasi Android SDK [Referensi, 80].

Implementasi perangkat JUGA HARUS mengidentifikasi dirinya dengan benar sebagai mendukung OpenGL ES 1.0, OpenGL ES 2.0, OpenGL ES 3.0, atau OpenGL 3.1. Artinya:

• API terkelola (seperti melalui metode GLES10.getString()) HARUS melaporkan dukungan untuk OpenGL ES 1.0 dan OpenGL ES 2.0.
• API OpenGL C/C++ native (API yang tersedia untuk aplikasi melalui libGLES_v1CM.so, libGLES_v2.so, atau libEGL.so) HARUS melaporkan dukungan untuk OpenGL ES 1.0 dan OpenGL ES 2.0.
• Implementasi perangkat yang mendeklarasikan dukungan untuk OpenGL ES 3.0 atau 3.1 HARUS mendukung API terkelola yang sesuai dan menyertakan dukungan untuk API C/C++ native. Pada implementasi perangkat yang mendeklarasikan dukungan untuk OpenGL ES 3.0 atau 3.1, libGLESv2.so HARUS mengekspor simbol fungsi yang sesuai selain simbol fungsi OpenGL ES 2.0.

Selain OpenGL ES 3.1, Android menyediakan paket ekstensi dengan antarmuka Java [Referensi, 81] dan dukungan native untuk fungsi grafis lanjutan seperti tessellation dan format kompresi tekstur ASTC. Implementasi perangkat Android DAPAT mendukung paket ekstensi ini, dan—hanya jika diimplementasikan sepenuhnya—HARUS mengidentifikasi dukungan melalui flag fitur android.hardware.opengles.aep.

Selain itu, implementasi perangkat DAPAT menerapkan ekstensi OpenGL ES yang diinginkan. Namun, implementasi perangkat HARUS melaporkan melalui API native dan yang dikelola OpenGL ES semua string ekstensi yang didukungnya, dan sebaliknya TIDAK BOLEH melaporkan string ekstensi yang tidak didukungnya.

Perhatikan bahwa Android menyertakan dukungan untuk aplikasi agar secara opsional menentukan bahwa aplikasi memerlukan format kompresi tekstur OpenGL tertentu. Format ini biasanya khusus vendor. Implementasi perangkat tidak diperlukan oleh Android untuk menerapkan format kompresi tekstur tertentu. Namun, API tersebut HARUS melaporkan format kompresi tekstur apa pun yang didukungnya secara akurat, melalui metode getString() di OpenGL API.

Android menyertakan mekanisme bagi aplikasi untuk mendeklarasikan bahwa aplikasi ingin mengaktifkan akselerasi hardware untuk grafik 2D di tingkat Aplikasi, Aktivitas, Jendela, atau Tampilan melalui penggunaan tag manifes android:hardwareAccelerated atau panggilan API langsung [Referensi, 82].

Implementasi perangkat HARUS mengaktifkan akselerasi hardware secara default, dan HARUS menonaktifkan akselerasi hardware jika developer memintanya dengan menetapkan android:hardwareAccelerated="false” atau menonaktifkan akselerasi hardware secara langsung melalui Android View API.

Selain itu, implementasi perangkat HARUS menunjukkan perilaku yang konsisten dengan dokumentasi Android SDK tentang akselerasi hardware [Referensi, 82].

Android menyertakan objek TextureView yang memungkinkan developer mengintegrasikan tekstur OpenGL ES yang diakselerasi hardware secara langsung sebagai target rendering dalam hierarki UI. Implementasi perangkat HARUS mendukung TextureView API, dan HARUS menunjukkan perilaku yang konsisten dengan implementasi Android upstream.

Android menyertakan dukungan untuk EGL_ANDROID_RECORDABLE, atribut EGLConfig yang menunjukkan apakah EGLConfig mendukung rendering ke ANativeWindow yang merekam gambar ke video. Implementasi perangkat HARUS mendukung ekstensi EGL_ANDROID_RECORDABLE [Referensi, 83].

7.1.5. Mode Kompatibilitas Aplikasi Lama

Android menentukan “mode kompatibilitas” tempat framework beroperasi dalam mode ukuran layar 'normal' yang setara (lebar 320 dp) untuk kepentingan aplikasi lama yang tidak dikembangkan untuk Android versi lama yang sudah ada sebelum kemerdekaan ukuran layar.

• Android Automotive tidak mendukung mode kompatibilitas lama.
• Semua implementasi perangkat lainnya HARUS menyertakan dukungan untuk mode kompatibilitas aplikasi lama seperti yang diterapkan oleh kode open source Android upstream. Artinya, implementasi perangkat TIDAK BOLEH mengubah pemicu atau nilai minimum saat mode kompatibilitas diaktifkan, dan TIDAK BOLEH mengubah perilaku mode kompatibilitas itu sendiri.

7.1.6. Teknologi Layar

Platform Android menyertakan API yang memungkinkan aplikasi merender grafis lengkap ke layar. Perangkat HARUS mendukung semua API ini seperti yang ditentukan oleh Android SDK, kecuali jika secara khusus diizinkan dalam dokumen ini.

• Perangkat HARUS mendukung layar yang mampu merender grafis warna 16-bit dan HARUS mendukung layar yang mampu merender grafis warna 24-bit.
• Perangkat HARUS mendukung layar yang mampu merender animasi.
• Teknologi layar yang digunakan HARUS memiliki rasio aspek piksel (PAR) antara 0,9 dan 1,15. Artinya, rasio aspek piksel HARUS mendekati persegi (1,0) dengan toleransi 10 ~ 15%.

7.1.7. Layar Sekunder

Android menyertakan dukungan untuk layar sekunder guna mengaktifkan kemampuan berbagi media dan API developer untuk mengakses layar eksternal. Jika perangkat mendukung layar eksternal melalui koneksi layar tambahan berkabel, nirkabel, atau tersemat, implementasi perangkat HARUS mengimplementasikan API pengelola layar seperti yang dijelaskan dalam dokumentasi Android SDK [Referensi, 84].

7.2. Perangkat Masukan

Perangkat HARUS mendukung layar sentuh atau memenuhi persyaratan yang tercantum dalam 7.2.2 untuk navigasi non-sentuh.

7.2.1. Keyboard

Implementasi perangkat:

• HARUS menyertakan dukungan untuk Framework Pengelolaan Input (yang memungkinkan developer pihak ketiga membuat Editor Metode Input—yaitu keyboard virtual) seperti yang dijelaskan di http://developer.android.com.
• HARUS menyediakan minimal satu implementasi keyboard virtual (terlepas dari apakah keyboard fisik ada atau tidak) kecuali untuk perangkat Android Watch dengan ukuran layar yang membuat keyboard virtual kurang wajar.
• DAPAT menyertakan implementasi keyboard virtual tambahan.
• DAPAT menyertakan keyboard hardware.
• TIDAK BOLEH menyertakan keyboard hardware yang tidak cocok dengan salah satu format yang ditentukan di android.content.res.Configuration.keyboard [Resources, 85] (QWERTY atau 12 tombol).

7.2.2. Navigasi Non-sentuh

Implementasi perangkat:

• DAPAT menghilangkan opsi navigasi non-sentuh (trackball, d-pad, atau roda) jika implementasi perangkat bukan perangkat Android Television.
• HARUS melaporkan nilai yang benar untuk android.content.res.Configuration.navigation [Resources, 85].
• HARUS menyediakan mekanisme antarmuka pengguna alternatif yang wajar untuk pemilihan dan pengeditan teks, yang kompatibel dengan Mesin Pengelolaan Input. Implementasi open source Android upstream menyertakan mekanisme pemilihan yang cocok untuk digunakan dengan perangkat yang tidak memiliki input navigasi non-sentuh.

7.2.3. Tombol Navigasi

Fungsi Beranda, Terbaru, dan Kembali (masing-masing dipetakan ke peristiwa kunci KEYCODE_HOME, KEYCODE_APP_SWITCH, KEYCODE_BACK) sangat penting bagi paradigma navigasi Android, sehingga:

• Implementasi perangkat Genggam Android HARUS menyediakan fungsi Layar Utama, Terbaru, dan Kembali.
• Implementasi perangkat Android Television HARUS menyediakan fungsi Utama dan Kembali.
• Implementasi perangkat Android Watch HARUS memiliki fungsi Home yang tersedia untuk pengguna, dan fungsi Kembali kecuali saat berada dalam UI_MODE_TYPE_WATCH.
• Implementasi Android Automotive HARUS menyediakan fungsi Beranda dan DAPAT menyediakan fungsi Kembali dan Terbaru.
• Semua jenis implementasi perangkat lainnya HARUS menyediakan fungsi Rumah dan Kembali.

Fungsi ini DAPAT diterapkan melalui tombol fisik khusus (seperti tombol sentuh mekanis atau kapasitif), atau DAPAT diterapkan menggunakan tombol software khusus di bagian layar, gestur, panel sentuh, dll. yang berbeda. Android mendukung kedua penerapan tersebut. Semua fungsi ini HARUS dapat diakses dengan satu tindakan (misalnya ketuk, klik dua kali, atau gestur) saat terlihat.

Fungsi Terbaru, jika disediakan, HARUS memiliki tombol atau ikon yang terlihat, kecuali jika disembunyikan bersama dengan fungsi navigasi lainnya dalam mode layar penuh. Hal ini tidak berlaku untuk perangkat yang diupgrade dari versi Android sebelumnya yang memiliki tombol fisik untuk navigasi dan tidak memiliki tombol terbaru.

Fungsi Beranda dan Kembali, jika disediakan, HARUS memiliki tombol atau ikon yang terlihat, kecuali jika disembunyikan bersama dengan fungsi navigasi lainnya dalam mode layar penuh atau saat uiMode UI_MODE_TYPE_MASK disetel ke UI_MODE_TYPE_WATCH.

Fungsi Menu tidak digunakan lagi dan diganti dengan panel tindakan sejak Android 4.0. Oleh karena itu, implementasi perangkat baru yang dikirimkan dengan Android 6.0 dan yang lebih baru TIDAK BOLEH menerapkan tombol fisik khusus untuk fungsi Menu. Implementasi perangkat lama TIDAK BOLEH menerapkan tombol fisik khusus untuk fungsi Menu, tetapi jika tombol Menu fisik diterapkan dan perangkat menjalankan aplikasi dengan targetSdkVersion > 10, implementasi perangkat:

• HARUS menampilkan tombol menu tambahan tindakan di panel tindakan saat terlihat dan pop-up menu tambahan tindakan yang dihasilkan tidak kosong. Untuk penerapan perangkat yang diluncurkan sebelum Android 4.4, tetapi diupgrade ke Android 6.0, hal ini DISARANKAN.
• TIDAK BOLEH mengubah posisi pop-up tambahan tindakan yang ditampilkan dengan memilih tombol tambahan di panel tindakan.
• DAPAT merender pop-up tambahan tindakan pada posisi yang diubah di layar saat ditampilkan dengan memilih tombol menu fisik.

Untuk kompatibilitas mundur, implementasi perangkat HARUS membuat fungsi Menu tersedia untuk aplikasi jika targetSdkVersion kurang dari 10, baik dengan tombol fisik, kunci software, maupun gestur. Fungsi Menu ini harus ditampilkan kecuali jika disembunyikan bersama dengan fungsi navigasi lainnya.

Implementasi perangkat Android dengan dukungan tindakan Assist [Referensi, 30] HARUS membuatnya dapat diakses dengan satu tindakan (misalnya, ketuk, klik dua kali, atau gestur) saat tombol navigasi lainnya terlihat, dan SANGAT DISARANKAN untuk menggunakan tekan lama pada tombol Home atau tombol software sebagai satu tindakan.

Implementasi perangkat DAPAT menggunakan bagian layar yang berbeda untuk menampilkan kunci navigasi, tetapi jika demikian, HARUS memenuhi persyaratan ini:

• Tombol navigasi implementasi perangkat HARUS menggunakan bagian layar yang berbeda, tidak tersedia untuk aplikasi, dan TIDAK BOLEH mengaburkan atau mengganggu bagian layar yang tersedia untuk aplikasi.
• Implementasi perangkat HARUS menyediakan sebagian tampilan untuk aplikasi yang memenuhi persyaratan yang ditentukan dalam bagian 7.1.1.
• Implementasi perangkat HARUS menampilkan tombol navigasi saat aplikasi tidak menentukan mode UI sistem, atau menentukan SYSTEM_UI_FLAG_VISIBLE.
• Implementasi perangkat HARUS menampilkan tombol navigasi dalam mode “profil rendah” (misalnya, dimmed) yang tidak mengganggu saat aplikasi menentukan SYSTEM_UI_FLAG_LOW_PROFILE.
• Implementasi perangkat HARUS menyembunyikan tombol navigasi saat aplikasi menentukan SYSTEM_UI_FLAG_HIDE_NAVIGATION.

7.2.4. Input Layar Sentuh

Implementasi perangkat HARUS memiliki sistem input pointer (seperti mouse atau sentuh). Namun, jika implementasi perangkat tidak mendukung sistem input pointer, implementasi tersebut TIDAK BOLEH melaporkan konstanta fitur android.hardware.touchscreen atau android.hardware.faketouch. Implementasi perangkat yang menyertakan sistem input pointer:

• HARUS mendukung pointer yang dilacak sepenuhnya secara independen, jika sistem input perangkat mendukung beberapa pointer.
• HARUS melaporkan nilai android.content.res.Configuration.touchscreen [Resources, 85] yang sesuai dengan jenis layar sentuh tertentu di perangkat.

Android menyertakan dukungan untuk berbagai layar sentuh, touchpad, dan perangkat input sentuh palsu. Implementasi perangkat berbasis layar sentuh dikaitkan dengan layar [Referensi, 86] sehingga pengguna memiliki kesan memanipulasi item secara langsung di layar. Karena pengguna langsung menyentuh layar, sistem tidak memerlukan kemampuan tambahan untuk menunjukkan objek yang sedang dimanipulasi. Sebaliknya, antarmuka sentuh palsu menyediakan sistem input pengguna yang memperkirakan subset kemampuan layar sentuh. Misalnya, mouse atau remote control yang menggerakkan kursor di layar mendekati sentuhan, tetapi mengharuskan pengguna untuk terlebih dahulu mengarahkan atau memfokuskan, lalu mengklik. Banyak perangkat input seperti mouse, trackpad, mouse udara berbasis giroskop, pointer giroskop, joystick, dan trackpad multi-kontrol dapat mendukung interaksi sentuh palsu. Android menyertakan konstanta fitur android.hardware.faketouch, yang sesuai dengan perangkat input non-sentuh (berbasis pointer) fidelitas tinggi seperti mouse atau trackpad yang dapat mengemulasikan input berbasis sentuh secara memadai (termasuk dukungan gestur dasar), dan menunjukkan bahwa perangkat mendukung subset fungsi layar sentuh yang diemulasikan. Implementasi perangkat yang mendeklarasikan fitur sentuhan palsu HARUS memenuhi persyaratan sentuhan palsu di bagian 7.2.5.

Implementasi perangkat HARUS melaporkan fitur yang benar sesuai dengan jenis input yang digunakan. Implementasi perangkat yang menyertakan layar sentuh (sentuhan tunggal atau lebih baik) HARUS melaporkan konstanta fitur platform android.hardware.touchscreen. Implementasi perangkat yang melaporkan konstanta fitur platform android.hardware.touchscreen JUGA HARUS melaporkan konstanta fitur platform android.hardware.faketouch. Implementasi perangkat yang tidak menyertakan layar sentuh (dan hanya mengandalkan perangkat pointer) TIDAK BOLEH melaporkan fitur layar sentuh apa pun, dan HANYA BOLEH melaporkan android.hardware.faketouch jika memenuhi persyaratan sentuh palsu di bagian 7.2.5.

7.2.5. Input Sentuh Palsu

Implementasi perangkat yang mendeklarasikan dukungan untuk android.hardware.faketouch:

• HARUS melaporkan posisi layar X dan Y absolut dari lokasi pointer dan menampilkan pointer visual di layar [Referensi, 87].
• HARUS melaporkan peristiwa sentuh dengan kode tindakan yang menentukan perubahan status yang terjadi pada kursor yang bergerak ke bawah atau ke atas di layar [Referensi, 87].
• HARUS mendukung pointer ke bawah dan ke atas pada objek di layar, yang memungkinkan pengguna mengemulasi ketukan pada objek di layar.
• HARUS mendukung pointer ke bawah, pointer ke atas, pointer ke bawah, lalu pointer ke atas di tempat yang sama pada objek di layar dalam batas waktu, yang memungkinkan pengguna mengemulasi ketuk dua kali pada objek di layar [Referensi, 87].
• HARUS mendukung kursor ke bawah pada titik arbitrer di layar, kursor bergerak ke titik arbitrer lainnya di layar, diikuti dengan kursor ke atas, yang memungkinkan pengguna mengemulasi tarikan sentuh.
• HARUS mendukung pointer ke bawah, lalu memungkinkan pengguna memindahkan objek dengan cepat ke posisi yang berbeda di layar, lalu pointer ke atas di layar, yang memungkinkan pengguna melempar objek di layar.

Perangkat yang mendeklarasikan dukungan untuk android.hardware.faketouch.multitouch.distinct HARUS memenuhi persyaratan untuk faketouch di atas, dan JUGA HARUS mendukung pelacakan yang berbeda dari dua atau beberapa input pointer independen.

7.2.6. Dukungan Pengontrol Game

Implementasi perangkat Android Television HARUS mendukung pemetaan tombol untuk pengontrol game seperti yang tercantum di bawah. Implementasi Android upstream mencakup implementasi untuk pengontrol game yang memenuhi persyaratan ini.

7.2.6.1. Pemetaan Tombol

Implementasi perangkat Android Television HARUS mendukung pemetaan kunci berikut:

Tombol	Penggunaan HID2	Tombol Android
A1	0x09 0x0001	KEYCODE_BUTTON_A (96)
B1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X1	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y1	0x09 0x0005	KEYCODE_BUTTON_Y (100)
D-pad atas1 D-pad bawah1	0x01 0x00393	AXIS_HAT_Y4
Tombol arah kiri1 Tombol arah kanan1	0x01 0x00393	AXIS_HAT_X4
Tombol bahu kiri1	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Tombol bahu kanan1	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Klik tongkat kiri1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Klik tongkat kanan1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Beranda1	0x0c 0x0223	KEYCODE_HOME (3)
Back1	0x0c 0x0224	KEYCODE_BACK (4)

1 [Referensi, 88]

2 Penggunaan HID di atas harus dideklarasikan dalam CA Gamepad (0x01 0x0005).

3 Penggunaan ini harus memiliki Minimum Logika 0, Maksimum Logika 7, Minimum Fisik 0, Maksimum Fisik 315, Unit dalam Derajat, dan Ukuran Laporan 4. Nilai logika ditentukan sebagai rotasi searah jarum jam dari sumbu vertikal; misalnya, nilai logika 0 mewakili tidak ada rotasi dan tombol atas ditekan, sedangkan nilai logika 1 mewakili rotasi 45 derajat dan tombol atas dan kiri ditekan.

4 [Referensi, 87]

Kontrol Analog1	Penggunaan HID	Tombol Android
Pemicu Kiri	0x02 0x00C5	AXIS_LTRIGGER
Pemicu Kanan	0x02 0x00C4	AXIS_RTRIGGER
Joystick Kiri	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
Joystick Kanan	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

1 [Referensi, 87]

7.2.7. Remote Control

Implementasi perangkat Android Television HARUS menyediakan remote control untuk memungkinkan pengguna mengakses antarmuka TV. Remote control DAPAT berupa remote fisik atau dapat berupa remote berbasis software yang dapat diakses dari ponsel atau tablet. Remote control HARUS memenuhi persyaratan yang ditentukan di bawah.

• Affordance penelusuran. Implementasi perangkat HARUS memicu KEYCODE_SEARCH (atau KEYCODE_ASSIST jika perangkat mendukung asisten) saat pengguna memanggil penelusuran suara di remote fisik atau berbasis software.
• Navigasi. Semua remote Android Television HARUS menyertakan tombol Kembali, Beranda, dan Pilih serta dukungan untuk peristiwa D-pad [Referensi, 88].

7.3. Sensor

Android menyertakan API untuk mengakses berbagai jenis sensor. Implementasi perangkat umumnya DAPAT menghilangkan sensor ini, seperti yang disediakan dalam subbagian berikut. Jika perangkat menyertakan jenis sensor tertentu yang memiliki API yang sesuai untuk developer pihak ketiga, implementasi perangkat HARUS menerapkan API tersebut seperti yang dijelaskan dalam dokumentasi Android SDK dan dokumentasi Open Source Android tentang sensor [Referensi, 89]. Misalnya, implementasi perangkat:

• HARUS melaporkan keberadaan atau ketiadaan sensor secara akurat sesuai dengan class android.content.pm.PackageManager [Resources, 70].
• HARUS menampilkan daftar sensor yang didukung secara akurat melalui SensorManager.getSensorList() dan metode serupa.
• HARUS berperilaku wajar untuk semua API sensor lainnya (misalnya, dengan menampilkan true atau false sebagaimana mestinya saat aplikasi mencoba mendaftarkan pemroses, tidak memanggil pemroses sensor saat sensor yang sesuai tidak ada; dll.).
• HARUS melaporkan semua pengukuran sensor menggunakan nilai Sistem Satuan Internasional (metrik) yang relevan untuk setiap jenis sensor seperti yang ditentukan dalam dokumentasi Android SDK [Referensi, 90].
• HARUS melaporkan waktu peristiwa dalam nanodetik seperti yang ditentukan dalam dokumentasi Android SDK, yang mewakili waktu terjadinya peristiwa dan disinkronkan dengan jam SystemClock.elapsedRealtimeNano(). Perangkat Android yang ada dan baru SANGAT DISARANKAN untuk memenuhi persyaratan ini sehingga dapat diupgrade ke rilis platform mendatang yang mungkin menjadi komponen WAJIB. Error sinkronisasi HARUS di bawah 100 milidetik [Referensi, 91].
• HARUS melaporkan data sensor dengan latensi maksimum 100 milidetik + 2 * sample_time untuk kasus sensor yang di-streaming dengan latensi minimum yang diperlukan 5 md + 2 * sample_time saat prosesor aplikasi aktif. Keterlambatan ini tidak mencakup keterlambatan pemfilteran.
• HARUS melaporkan sampel sensor pertama dalam waktu 400 milidetik + 2 * sample_time sensor yang diaktifkan. Sampel ini dapat memiliki akurasi 0.

Daftar di atas tidak komprehensif; perilaku yang didokumentasikan dari Android SDK dan Dokumentasi Open Source Android tentang Sensor [Referensi, 89] harus dianggap kredibel.

Beberapa jenis sensor bersifat komposit, yang berarti dapat berasal dari data yang disediakan oleh satu atau beberapa sensor lainnya. (Contohnya mencakup sensor orientasi, dan sensor akselerasi linear.) Implementasi perangkat HARUS mengimplementasikan jenis sensor ini, jika menyertakan sensor fisik prasyarat seperti yang dijelaskan di [Referensi, 92]. Jika implementasi perangkat menyertakan sensor komposit, implementasi tersebut HARUS menerapkan sensor seperti yang dijelaskan dalam dokumentasi Open Source Android tentang sensor komposit [Referensi, 92].

Beberapa sensor Android mendukung mode pemicu “kontinu”, yang menampilkan data secara terus-menerus [Referensi, 93]. Untuk API apa pun yang ditunjukkan oleh dokumentasi Android SDK sebagai sensor kontinu, implementasi perangkat HARUS terus memberikan sampel data berkala yang HARUS memiliki jitter di bawah 3%, dengan jitter didefinisikan sebagai deviasi standar dari perbedaan nilai stempel waktu yang dilaporkan antara peristiwa berturut-turut.

Perhatikan bahwa implementasi perangkat HARUS memastikan bahwa aliran peristiwa sensor HARUS TIDAK mencegah CPU perangkat memasuki status penangguhan atau aktif dari status penangguhan.

Terakhir, saat beberapa sensor diaktifkan, konsumsi daya TIDAK BOLEH melebihi jumlah konsumsi daya yang dilaporkan oleh setiap sensor.

7.3.1. Akselerometer

Implementasi perangkat HARUS menyertakan akselerometer 3 sumbu. Perangkat Android Handheld dan perangkat Android Watch SANGAT DIUJAMI untuk menyertakan sensor ini. Jika implementasi perangkat menyertakan akselerometer 3 sumbu, implementasi tersebut:

• HARUS menerapkan dan melaporkan sensor TYPE_ACCELEROMETER [Referensi, 94].
• HARUS dapat melaporkan peristiwa hingga frekuensi minimal 50 Hz untuk perangkat Android Watch karena perangkat tersebut memiliki batasan daya yang lebih ketat dan 100 Hz untuk semua jenis perangkat lainnya.
• HARUS melaporkan peristiwa hingga minimal 200 Hz.
• HARUS mematuhi sistem koordinat sensor Android seperti yang dijelaskan dalam Android API [Referensi, 90].
• HARUS dapat mengukur dari jatuh bebas hingga empat kali gravitasi (4g) atau lebih pada sumbu mana pun.
• HARUS memiliki resolusi minimal 12-bit dan HARUS memiliki resolusi minimal 16-bit.
• HARUS dikalibrasi saat digunakan jika karakteristik berubah selama siklus proses dan dikompensasi, serta mempertahankan parameter kompensasi di antara perangkat yang dimulai ulang.
• HARUS dikompensasi suhu.
• HARUS memiliki deviasi standar tidak lebih besar dari 0,05 m/s^, dengan deviasi standar harus dihitung berdasarkan per sumbu pada sampel yang dikumpulkan selama periode minimal 3 detik pada kecepatan sampling tercepat.
• HARUS menerapkan sensor komposit TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER seperti yang dijelaskan dalam dokumen Android SDK. Perangkat Android yang ada dan baru SANGAT DISARANKAN untuk mengimplementasikan sensor komposit TYPE_SIGNIFICANT_MOTION. Jika salah satu sensor ini diterapkan, jumlah konsumsi dayanya HARUS selalu kurang dari 4 mW dan HARUS masing-masing di bawah 2 mW dan 0,5 mW saat perangkat dalam kondisi dinamis atau statis.
• Jika sensor giroskop disertakan, HARUS menerapkan sensor komposit TYPE_GRAVITY dan TYPE_LINEAR_ACCELERATION dan HARUS menerapkan sensor komposit TYPE_GAME_ROTATION_VECTOR. Perangkat Android lama dan baru SANGAT DISARANKAN untuk menerapkan sensor TYPE_GAME_ROTATION_VECTOR.
• HARUS menerapkan sensor gabungan TYPE_ROTATION_VECTOR, jika sensor giroskop dan sensor magnetometer juga disertakan.

7.3.2. Magnetometer

Implementasi perangkat HARUS menyertakan magnetometer (kompas) 3 sumbu. Jika perangkat menyertakan magnetometer 3 sumbu, perangkat tersebut:

• HARUS menerapkan sensor TYPE_MAGNETIC_FIELD dan JUGA HARUS menerapkan sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED. Perangkat Android yang ada dan baru SANGAT DIUJI untuk menerapkan sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED.
• HARUS dapat melaporkan peristiwa hingga frekuensi minimal 10 Hz dan HARUS melaporkan peristiwa hingga minimal 50 Hz.
• HARUS mematuhi sistem koordinat sensor Android seperti yang dijelaskan dalam Android API [Referensi, 90].
• HARUS dapat mengukur antara -900 µT dan +900 µT pada setiap sumbu sebelum jenuh.
• HARUS memiliki nilai offset besi keras kurang dari 700 µT dan HARUS memiliki nilai di bawah 200 µT, dengan menempatkan magnetometer jauh dari medan magnet dinamis (yang disebabkan oleh arus) dan statis (yang disebabkan oleh magnet).
• HARUS memiliki resolusi yang sama atau lebih padat dari 0,6 µT dan HARUS memiliki resolusi yang sama atau lebih padat dari 0,2 µ.
• HARUS dikompensasi suhu.
• HARUS mendukung kalibrasi dan kompensasi online untuk bias hard iron, dan mempertahankan parameter kompensasi di antara mulai ulang perangkat.
• HARUS menerapkan kompensasi besi lunak—kalibrasi dapat dilakukan saat digunakan atau selama produksi perangkat.
• HARUS memiliki simpangan baku, yang dihitung berdasarkan per sumbu pada sampel yang dikumpulkan selama minimal 3 detik pada kecepatan sampling tercepat, tidak lebih besar dari 0,5 µT.
• HARUS menerapkan sensor gabungan TYPE_ROTATION_VECTOR, jika sensor akselerometer dan sensor giroskop juga disertakan.
• DAPAT menerapkan sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR jika sensor akselerometer juga diterapkan. Namun, jika diterapkan, sensor HARUS menggunakan daya kurang dari 10 mW dan HARUS menggunakan daya kurang dari 3 mW saat sensor terdaftar untuk mode batch pada 10 Hz.

7.3.3. GPS

Implementasi perangkat HARUS menyertakan penerima GPS. Jika implementasi perangkat menyertakan penerima GPS, implementasi tersebut HARUS menyertakan beberapa bentuk teknik “GPS berbantuan” untuk meminimalkan waktu penguncian GPS.

7.3.4. Giroskop

Implementasi perangkat HARUS menyertakan giroskop (sensor perubahan sudut). Perangkat TIDAK BOLEH menyertakan sensor giroskop kecuali jika akselerometer 3 sumbu juga disertakan. Jika implementasi perangkat menyertakan giroskop, perangkat tersebut:

• HARUS menerapkan sensor TYPE_GYROSCOPE dan JUGA HARUS menerapkan sensor TYPE_GYROSCOPE_UNCALIBRATED. Perangkat Android lama dan baru SANGAT DIUJI untuk menerapkan sensor SENSOR_TYPE_GYROSCOPE_UNCALIBRATED.
• HARUS dapat mengukur perubahan orientasi hingga 1.000 derajat per detik.
• HARUS dapat melaporkan peristiwa hingga frekuensi minimal 50 Hz untuk perangkat Android Watch karena perangkat tersebut memiliki batasan daya yang lebih ketat dan 100 Hz untuk semua jenis perangkat lainnya.
• HARUS melaporkan peristiwa hingga minimal 200 Hz.
• HARUS memiliki resolusi 12-bit atau lebih dan HARUS memiliki resolusi 16-bit atau lebih.
• HARUS memiliki kompensasi suhu.
• HARUS dikalibrasi dan dikompensasi saat digunakan, serta mempertahankan parameter kompensasi di antara mulai ulang perangkat.
• HARUS memiliki varians tidak lebih besar dari 1e-7 rad^2 / s^2 per Hz (varians per Hz, atau rad^2 / s). Varians diizinkan untuk bervariasi dengan frekuensi sampling, tetapi harus dibatasi oleh nilai ini. Dengan kata lain, jika Anda mengukur varians giroskopi pada kecepatan sampling 1 Hz, nilainya tidak boleh lebih besar dari 1e-7 rad^2/s^2.
• HARUS menerapkan sensor gabungan TYPE_ROTATION_VECTOR, jika sensor akselerometer dan sensor magnetometer juga disertakan.
• Jika sensor akselerometer disertakan, HARUS menerapkan sensor komposit TYPE_GRAVITY dan TYPE_LINEAR_ACCELERATION dan HARUS menerapkan sensor komposit TYPE_GAME_ROTATION_VECTOR. Perangkat Android lama dan baru SANGAT DISARANKAN untuk menerapkan sensor TYPE_GAME_ROTATION_VECTOR.

7.3.5. Barometer

Implementasi perangkat HARUS menyertakan barometer (sensor tekanan udara sekitar). Jika implementasi perangkat menyertakan barometer, perangkat tersebut:

• HARUS menerapkan dan melaporkan sensor TYPE_PRESSURE.
• HARUS dapat mengirimkan peristiwa pada kecepatan 5 Hz atau lebih.
• HARUS memiliki presisi yang memadai untuk memungkinkan estimasi ketinggian.
• HARUS memiliki kompensasi suhu.

7.3.6. Thermometer

Implementasi perangkat DAPAT menyertakan termometer ambien (sensor suhu). Jika ada, SENSOR_TYPE_AMBIENT_TEMPERATURE HARUS ditentukan dan HARUS mengukur suhu ruangan (sekitar) dalam derajat Celcius.

Implementasi perangkat DAPAT tetapi TIDAK BOLEH menyertakan sensor suhu CPU. Jika ada, SENSOR_TYPE_TEMPERATURE HARUS ditentukan, HARUS mengukur suhu CPU perangkat, dan TIDAK BOLEH mengukur suhu lainnya. Perhatikan bahwa jenis sensor SENSOR_TYPE_TEMPERATURE tidak digunakan lagi di Android 4.0.

7.3.7. Fotometer

Implementasi perangkat DAPAT menyertakan fotometer (sensor cahaya sekitar).

7.3.8. Sensor Kedekatan

Implementasi perangkat DAPAT menyertakan sensor kedekatan. Perangkat yang dapat melakukan panggilan suara dan menunjukkan nilai selain PHONE_TYPE_NONE di getPhoneType HARUS menyertakan sensor kedekatan. Jika implementasi perangkat menyertakan sensor kedekatan, implementasi tersebut:

• HARUS mengukur kedekatan objek dalam arah yang sama dengan layar. Artinya, sensor kedekatan HARUS diorientasikan untuk mendeteksi objek yang dekat dengan layar, karena intent utama jenis sensor ini adalah mendeteksi ponsel yang digunakan oleh pengguna. Jika implementasi perangkat menyertakan sensor kedekatan dengan orientasi lain, sensor tersebut TIDAK BOLEH diakses melalui API ini.
• HARUS memiliki akurasi 1-bit atau lebih.

7.3.9. Sensor Akurasi Tinggi

Implementasi perangkat yang mendukung serangkaian sensor berkualitas lebih tinggi yang dapat memenuhi semua persyaratan yang tercantum di bagian ini HARUS mengidentifikasi dukungan melalui tanda fitur android.hardware.sensor.hifi_sensors.

Perangkat yang mendeklarasikan android.hardware.sensor.hifi_sensors HARUS mendukung semua jenis sensor berikut yang memenuhi persyaratan kualitas seperti di bawah ini:

• SENSOR_TYPE_ACCELEROMETER
  • HARUS memiliki rentang pengukuran antara minimal -8g dan +8g
  • HARUS memiliki resolusi pengukuran minimal 1024 LSB/G
  • HARUS memiliki frekuensi pengukuran minimum 12,5 Hz atau lebih rendah
  • HARUS memiliki frekuensi pengukuran maksimum 200 Hz atau lebih tinggi
  • HARUS memiliki derau pengukuran tidak lebih dari 400uG/√Hz
  • HARUS menerapkan bentuk non-wake-up sensor ini dengan kemampuan buffering minimal 3.000 peristiwa sensor
  • HARUS memiliki konsumsi daya pengelompokan tidak lebih buruk dari 3 mW
• SENSOR_TYPE_GYROSCOPE
  • HARUS memiliki rentang pengukuran antara minimal -1.000 dan +1.000 dps
  • HARUS memiliki resolusi pengukuran minimal 16 LSB/dps
  • HARUS memiliki frekuensi pengukuran minimum 12,5 Hz atau lebih rendah
  • HARUS memiliki frekuensi pengukuran maksimum 200 Hz atau lebih tinggi
  • HARUS memiliki derau pengukuran tidak lebih dari 0,014°/s/√Hz
• SENSOR_TYPE_GYROSCOPE_UNCALIBRATED dengan persyaratan kualitas yang sama dengan SENSOR_TYPE_GYROSCOPE
• SENSOR_TYPE_GEOMAGNETIC_FIELD
  • HARUS memiliki rentang pengukuran antara minimal -900 dan +900 uT
  • HARUS memiliki resolusi pengukuran minimal 5 LSB/uT
  • HARUS memiliki frekuensi pengukuran minimum 5 Hz atau lebih rendah
  • HARUS memiliki frekuensi pengukuran maksimum 50 Hz atau lebih tinggi
  • HARUS memiliki derau pengukuran tidak lebih dari 0,5 uT
• SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED dengan persyaratan kualitas yang sama dengan SENSOR_TYPE_GEOMAGNETIC_FIELD dan selain itu:
  • HARUS menerapkan bentuk non-wake-up sensor ini dengan kemampuan buffering minimal 600 peristiwa sensor
• SENSOR_TYPE_PRESSURE
  • HARUS memiliki rentang pengukuran antara minimal 300 dan 1100 hPa
  • HARUS memiliki resolusi pengukuran minimal 80 LSB/hPa
  • HARUS memiliki frekuensi pengukuran minimum 1 Hz atau lebih rendah
  • HARUS memiliki frekuensi pengukuran maksimum 10 Hz atau lebih tinggi
  • HARUS memiliki derau pengukuran tidak lebih dari 2 Pa/√Hz
  • HARUS menerapkan bentuk non-wake-up sensor ini dengan kemampuan buffering minimal 300 peristiwa sensor
  • HARUS memiliki konsumsi daya pengelompokan tidak lebih buruk dari 2 mW
• TYPE_GAME_ROTATION_VECTOR
  • HARUS menerapkan bentuk non-wake-up sensor ini dengan kemampuan buffering minimal 300 peristiwa sensor.
  • HARUS memiliki konsumsi daya pengelompokan yang tidak lebih buruk dari 4 mW.
• SENSOR_TYPE_SIGNIFICANT_MOTION
  • HARUS memiliki konsumsi daya tidak lebih buruk dari 0,5 mW saat perangkat statis dan 1,5 mW saat perangkat bergerak
• SENSOR_TYPE_STEP_DETECTOR
  • HARUS menerapkan bentuk non-wake-up sensor ini dengan kemampuan buffering minimal 100 peristiwa sensor
  • HARUS memiliki konsumsi daya tidak lebih buruk dari 0,5 mW saat perangkat statis dan 1,5 mW saat perangkat bergerak
  • HARUS memiliki konsumsi daya pengelompokan tidak lebih buruk dari 4 mW
• SENSOR_TYPE_STEP_COUNTER
  • HARUS memiliki konsumsi daya tidak lebih buruk dari 0,5 mW saat perangkat statis dan 1,5 mW saat perangkat bergerak
• SENSOR_TILT_DETECTOR
  • HARUS memiliki konsumsi daya tidak lebih buruk dari 0,5 mW saat perangkat statis dan 1,5 mW saat perangkat bergerak

Selain itu, perangkat tersebut HARUS memenuhi persyaratan subsistem sensor berikut:

• Stempel waktu peristiwa dari peristiwa fisik yang sama yang dilaporkan oleh sensor Akselerasi, Giroskop, dan Magnetometer HARUS berada dalam jarak 2,5 milidetik satu sama lain.
• Stempel waktu peristiwa sensor Giroskop HARUS berada pada basis waktu yang sama dengan subsistem kamera dan dalam error 1 milidetik.
• Latensi pengiriman sampel ke HAL HARUS di bawah 5 milidetik sejak saat data tersedia di hardware sensor fisik.
• Konsumsi daya TIDAK BOLEH lebih tinggi dari 0,5 mW saat perangkat statis dan 2,0 mW saat perangkat bergerak jika kombinasi sensor berikut diaktifkan:
  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS

Perhatikan bahwa semua persyaratan konsumsi daya di bagian ini tidak mencakup konsumsi daya dari Application Processor. Ini mencakup daya yang diambil oleh seluruh rantai sensor - sensor, sirkuit pendukung, sistem pemrosesan sensor khusus, dll.

Jenis sensor berikut JUGA DAPAT didukung pada implementasi perangkat yang mendeklarasikan android.hardware.sensor.hifi_sensors, tetapi jika jenis sensor ini ada, jenis sensor tersebut HARUS memenuhi persyaratan kemampuan buffering minimum berikut:

• SENSOR_TYPE_PROXIMITY: 100 peristiwa sensor

7.3.10. Sensor Sidik Jari

Implementasi perangkat dengan layar kunci yang aman HARUS menyertakan sensor sidik jari. Jika implementasi perangkat menyertakan sensor sidik jari dan memiliki API yang sesuai untuk developer pihak ketiga, implementasi tersebut:

• HARUS mendeklarasikan dukungan untuk fitur android.hardware.fingerprint.
• HARUS sepenuhnya menerapkan API yang sesuai seperti yang dijelaskan dalam dokumentasi Android SDK [Referensi, 95].
• HARUS memiliki rasio penerimaan palsu tidak lebih tinggi dari 0,002%.
• SANGAT DIUTAMAKAN untuk memiliki rasio penolakan palsu kurang dari 10%, seperti yang diukur di perangkat
• SANGAT DIUJAMI untuk memiliki latensi di bawah 1 detik, diukur dari saat sensor sidik jari disentuh hingga layar dibuka kuncinya, untuk satu jari yang terdaftar.
• HARUS membatasi upaya rating selama minimal 30 detik setelah lima percobaan palsu untuk verifikasi sidik jari.
• HARUS memiliki implementasi keystore yang didukung hardware, dan melakukan pencocokan sidik jari di Trusted Execution Environment (TEE) atau di chip dengan saluran aman ke TEE.
• HARUS memiliki semua data sidik jari yang dapat diidentifikasi yang dienkripsi dan diautentikasi secara kriptografis sehingga tidak dapat diperoleh, dibaca, atau diubah di luar Trusted Execution Environment (TEE) seperti yang didokumentasikan dalam panduan penerapan di situs Android Open Source Project [Referensi, 96].
• HARUS mencegah penambahan sidik jari tanpa terlebih dahulu membuat rantai kepercayaan dengan meminta pengguna mengonfirmasi kredensial perangkat yang ada atau menambahkan kredensial perangkat baru (PIN/pola/sandi) yang diamankan oleh TEE; implementasi Project Open Source Android menyediakan mekanisme dalam framework untuk melakukannya.
• TIDAK BOLEH mengaktifkan aplikasi pihak ketiga untuk membedakan setiap sidik jari.
• HARUS mematuhi tanda DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT.
• HARUS, saat diupgrade dari versi yang lebih lama dari Android 6.0, data sidik jari dimigrasikan dengan aman untuk memenuhi persyaratan di atas atau dihapus.
• HARUS menggunakan ikon Sidik Jari Android yang disediakan di Project Open Source Android.

7.4. Konektivitas Data

7.4.1. Telepon

“Telepon” seperti yang digunakan oleh Android API dan dokumen ini secara khusus merujuk pada hardware yang terkait dengan melakukan panggilan suara dan mengirim pesan SMS melalui jaringan GSM atau CDMA. Meskipun panggilan suara ini mungkin atau mungkin tidak menggunakan packet-switched, panggilan tersebut untuk tujuan Android dianggap independen dari konektivitas data apa pun yang dapat diterapkan menggunakan jaringan yang sama. Dengan kata lain, fungsi dan API “telepon” Android secara khusus merujuk pada 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 perangkat menggunakan jaringan seluler untuk konektivitas data.

Android DAPAT digunakan di perangkat yang tidak menyertakan hardware telefoni. Artinya, Android kompatibel dengan perangkat yang bukan ponsel. Namun, jika penerapan perangkat menyertakan telepon GSM atau CDMA, penerapan tersebut HARUS menerapkan dukungan lengkap untuk API untuk teknologi tersebut. Implementasi perangkat yang tidak menyertakan hardware telefoni HARUS menerapkan API lengkap sebagai no-ops.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementasi perangkat Android Television HARUS menyertakan dukungan untuk satu atau beberapa bentuk 802.11 (b/g/a/n, dll.) dan jenis implementasi perangkat Android lainnya HARUS menyertakan dukungan untuk satu atau beberapa bentuk 802.11. Jika penerapan perangkat menyertakan dukungan untuk 802.11 dan mengekspos fungsi ke aplikasi pihak ketiga, penerapan tersebut HARUS mengimplementasikan Android API yang sesuai dan:

• HARUS melaporkan flag fitur hardware android.hardware.wifi.
• HARUS menerapkan multicast API seperti yang dijelaskan dalam dokumentasi SDK [Referensi, 97].
• HARUS mendukung DNS multicast (mDNS) dan TIDAK BOLEH memfilter paket mDNS (224.0.0.251) kapan saja selama operasi, termasuk:
  • Bahkan saat layar tidak dalam status aktif.
  • Untuk penerapan perangkat Android Television, bahkan saat dalam status daya siaga.

7.4.2.1. Wi-Fi Direct

Implementasi perangkat HARUS menyertakan dukungan untuk Wi-Fi Direct (Wi-Fi peer-to-peer). Jika implementasi perangkat menyertakan dukungan untuk Wi-Fi Direct, implementasi tersebut HARUS menerapkan Android API yang sesuai seperti yang dijelaskan dalam dokumentasi SDK [Referensi, 98]. Jika implementasi perangkat menyertakan dukungan untuk Wi-Fi Direct, perangkat tersebut:

• HARUS melaporkan fitur hardware android.hardware.wifi.direct.
• HARUS mendukung operasi Wi-Fi reguler.
• HARUS mendukung operasi Wi-Fi dan Wi-Fi Direct serentak.

7.4.2.2. Penyiapan Link Langsung Wi-Fi dengan Tunnel

Implementasi perangkat Android Television HARUS menyertakan dukungan untuk Wi-Fi Tunneled Direct Link Setup (TDLS) dan jenis implementasi perangkat Android lainnya HARUS menyertakan dukungan untuk Wi-Fi TDLS seperti yang dijelaskan dalam Dokumentasi Android SDK [Referensi, 99]. Jika implementasi perangkat menyertakan dukungan untuk TDLS dan TDLS diaktifkan oleh WiFiManager API, perangkat:

• HARUS menggunakan TDLS hanya jika memungkinkan DAN bermanfaat.
• HARUS memiliki beberapa heuristik dan TIDAK menggunakan TDLS jika performanya mungkin lebih buruk daripada melalui titik akses Wi-Fi.

7.4.3. Bluetooth

Android menyertakan dukungan untuk Bluetooth dan Bluetooth Hemat Energi [Referensi, 100]. Implementasi perangkat yang menyertakan dukungan untuk Bluetooth dan Bluetooth Hemat Energi HARUS mendeklarasikan fitur platform yang relevan (masing-masing android.hardware.bluetooth dan android.hardware.bluetooth_le) dan mengimplementasikan API platform. Implementasi perangkat HARUS menerapkan profil Bluetooth yang relevan seperti A2DP, AVCP, OBEX, dll. sesuai dengan perangkat. Penerapan perangkat Android Television HARUS mendukung Bluetooth dan Bluetooth LE.

Implementasi perangkat termasuk dukungan untuk Bluetooth Hemat Energi:

• HARUS mendeklarasikan fitur hardware android.hardware.bluetooth_le.
• HARUS mengaktifkan API Bluetooth berbasis GATT (profil atribut generik) seperti yang dijelaskan dalam dokumentasi SDK dan [Referensi, 100].
• SANGAT DIUJAMI untuk menerapkan waktu tunggu Alamat Pribadi yang Dapat Di-resolve (RPA) tidak lebih dari 15 menit dan merotasi alamat saat waktu tunggu berakhir untuk melindungi privasi pengguna.
• HARUS mendukung offloading logika pemfilteran ke chipset bluetooth saat menerapkan ScanFilter API [Referensi, 101], dan HARUS melaporkan nilai yang benar tempat logika pemfilteran diterapkan setiap kali dikueri melalui metode android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported().
• HARUS mendukung penghapusan pemindaian batch ke chipset bluetooth, tetapi jika tidak didukung, HARUS melaporkan 'false' setiap kali dikueri melalui metode android.bluetooth.BluetoothAdapater.isOffloadedScanBatchingSupported() .
• HARUS mendukung multi-iklan dengan minimal 4 slot, tetapi jika tidak didukung, HARUS melaporkan 'false' setiap kali dikueri melalui metode android.bluetooth.BluetoothAdapter.isMultipleAdvertisementSupported().

7.4.4. Komunikasi Nirkabel Jarak Dekat

Implementasi perangkat HARUS menyertakan transceiver dan hardware terkait untuk Komunikasi Nirkabel Jarak Dekat (NFC). Jika implementasi perangkat menyertakan hardware NFC dan berencana menyediakannya untuk aplikasi pihak ketiga, maka:

• HARUS melaporkan fitur android.hardware.nfc dari metode android.content.pm.PackageManager.hasSystemFeature() [Resources, 70].
• HARUS dapat membaca dan menulis pesan NDEF melalui standar NFC berikut:
  • HARUS dapat bertindak sebagai pembaca/penulis Forum NFC (sebagaimana ditentukan oleh spesifikasi teknis Forum NFC NFCForum-TS-DigitalProtocol-1.0) melalui standar NFC berikut:
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS X 6319-4)
    • IsoDep (ISO 14443-4)
    • Jenis Tag NFC Forum 1, 2, 3, 4 (ditentukan oleh NFC Forum)
  • SANGAT DISARANKAN agar dapat membaca dan menulis pesan NDEF serta data mentah melalui standar NFC berikut. Perhatikan bahwa meskipun standar NFC di bawah dinyatakan sebagai SANGAT DIUJI, Definisi Kompatibilitas untuk versi mendatang direncanakan untuk mengubahnya menjadi HARUS. Standar ini bersifat opsional dalam versi ini, tetapi akan diperlukan dalam versi mendatang. Perangkat lama dan baru yang menjalankan versi Android ini sangat disarankan untuk memenuhi persyaratan ini sekarang sehingga perangkat tersebut dapat diupgrade ke rilis platform mendatang.
    • NfcV (ISO 15693)
  • HARUS dapat membaca kode batang dan URL (jika dienkode) dari produk Kode Batang NFC Thinfilm [Referensi, 102].
  • HARUS dapat mengirimkan dan menerima data melalui standar dan protokol peer-to-peer berikut:
    • ISO 18092
    • LLCP 1.2 (ditentukan oleh NFC Forum)
    • SDP 1.0 (ditentukan oleh NFC Forum)
    • NDEF Push Protocol [Referensi, 103]
    • SNEP 1.0 (ditentukan oleh NFC Forum)
  • HARUS menyertakan dukungan untuk Android Beam [Referensi, 104]:
    • HARUS menerapkan server default SNEP. Pesan NDEF yang valid yang diterima oleh server SNEP default HARUS dikirim ke aplikasi menggunakan intent android.nfc.ACTION_NDEF_DISCOVERED. Menonaktifkan Android Beam di setelan TIDAK BOLEH menonaktifkan pengiriman pesan NDEF yang masuk.
    • HARUS mematuhi intent android.settings.NFCSHARING_SETTINGS untuk menampilkan setelan berbagi NFC [Referensi, 105].
    • HARUS menerapkan server NPP. Pesan yang diterima oleh server NPP HARUS diproses dengan cara yang sama seperti server default SNEP.
    • HARUS menerapkan klien SNEP dan mencoba mengirim NDEF P2P keluar ke server SNEP default saat Android Beam diaktifkan. Jika tidak ada server SNEP default yang ditemukan, klien HARUS mencoba mengirim ke server NPP.
    • HARUS mengizinkan aktivitas latar depan untuk menetapkan pesan NDEF P2P keluar menggunakan android.nfc.NfcAdapter.setNdefPushMessage, dan android.nfc.NfcAdapter.setNdefPushMessageCallback, dan android.nfc.NfcAdapter.enableForegroundNdefPush.
    • HARUS menggunakan gestur atau konfirmasi di layar, seperti 'Sentuh untuk Beam', sebelum mengirim pesan NDEF P2P keluar.
    • HARUS mengaktifkan Android Beam secara default dan HARUS dapat mengirim dan menerima menggunakan Android Beam, meskipun mode P2P NFC eksklusif lainnya diaktifkan.
    • HARUS mendukung pengalihan Koneksi NFC ke Bluetooth saat perangkat mendukung Profil Push Objek Bluetooth. Implementasi perangkat HARUS mendukung pengalihan koneksi ke Bluetooth saat menggunakan android.nfc.NfcAdapter.setBeamPushUris, dengan menerapkan spesifikasi “Connection Handover version 1.2” [Resources, 106] dan “Bluetooth Secure Simple Pairing Using NFC version 1.0” [Resources, 107] dari NFC Forum. Implementasi tersebut HARUS menerapkan layanan LLCP handover dengan nama layanan “urn:nfc:sn:handover” untuk bertukar permintaan/data pilih handover melalui NFC, dan HARUS menggunakan Profil Push Objek Bluetooth untuk transfer data Bluetooth yang sebenarnya. Untuk alasan lama (agar tetap kompatibel dengan perangkat Android 4.1), implementasi HARUS tetap menerima permintaan GET SNEP untuk bertukar permintaan handover/data tertentu melalui NFC. Namun, implementasi itu sendiri TIDAK BOLEH mengirim permintaan GET SNEP untuk melakukan pengalihan koneksi.
  • HARUS melakukan polling untuk semua teknologi yang didukung saat dalam mode penemuan NFC.
  • HARUS dalam mode penemuan NFC saat perangkat aktif dengan layar aktif dan layar kunci tidak terkunci.

(Perhatikan bahwa link yang tersedia untuk publik tidak tersedia untuk spesifikasi Forum JIS, ISO, dan NFC yang dikutip di atas.)

Android menyertakan dukungan untuk mode Host Card Emulation (HCE) NFC. Jika penerapan perangkat menyertakan chipset pengontrol NFC yang mampu melakukan perutean HCE dan ID Aplikasi (AID), maka:

• HARUS melaporkan konstanta fitur android.hardware.nfc.hce.
• HARUS mendukung NFC HCE API seperti yang ditentukan dalam Android SDK [Referensi, 108].

Selain itu, implementasi perangkat DAPAT menyertakan dukungan pembaca/penulis untuk teknologi MIFARE berikut.

• MIFARE Classic
• MIFARE Ultralight
• NDEF di MIFARE Classic

Perhatikan bahwa Android menyertakan API untuk jenis MIFARE ini. Jika implementasi perangkat mendukung MIFARE dalam peran pembaca/penulis, implementasi tersebut:

• HARUS mengimplementasikan Android API yang sesuai seperti yang didokumentasikan oleh Android SDK.
• HARUS melaporkan fitur com.nxp.mifare dari metode android.content.pm.PackageManager.hasSystemFeature() [Resources, 70]. Perhatikan bahwa ini bukan fitur Android standar sehingga tidak muncul sebagai konstanta di class android.content.pm.PackageManager.
• TIDAK BOLEH mengimplementasikan API Android yang sesuai atau melaporkan fitur com.nxp.mifare kecuali jika juga mengimplementasikan dukungan NFC umum seperti yang dijelaskan di bagian ini.

Jika implementasi perangkat tidak menyertakan hardware NFC, implementasi tersebut TIDAK BOLEH mendeklarasikan fitur android.hardware.nfc dari metode android.content.pm.PackageManager.hasSystemFeature() [Referensi, 70], dan HARUS menerapkan Android NFC API sebagai no-op.

Karena class android.nfc.NdefMessage dan android.nfc.NdefRecord mewakili format representasi data yang tidak bergantung pada protokol, implementasi perangkat HARUS menerapkan API ini meskipun tidak menyertakan dukungan untuk NFC atau mendeklarasikan fitur android.hardware.nfc.

7.4.5. Kemampuan Jaringan Minimum

Implementasi perangkat HARUS menyertakan dukungan untuk satu atau beberapa bentuk jaringan data. Secara khusus, implementasi perangkat HARUS menyertakan dukungan untuk setidaknya satu standar data yang mampu mencapai 200 Kbit/detik atau lebih tinggi. Contoh teknologi yang memenuhi persyaratan ini mencakup EDGE, HSPA, EV-DO, 802.11g, Ethernet, Bluetooth PAN, dll.

Implementasi perangkat dengan standar jaringan fisik (seperti Ethernet) adalah koneksi data utama HARUS juga menyertakan dukungan untuk setidaknya satu standar data nirkabel umum, seperti 802.11 (Wi-Fi).

Perangkat DAPAT menerapkan lebih dari satu bentuk konektivitas data.

Perangkat HARUS menyertakan stack jaringan IPv6 dan mendukung komunikasi IPv6 menggunakan API terkelola, seperti java.net.Socket dan java.net.URLConnection, serta API native, seperti socket AF_INET6. Tingkat dukungan IPv6 yang diperlukan bergantung pada jenis jaringan, sebagai berikut:

• Perangkat yang mendukung jaringan Wi-Fi HARUS mendukung operasi dual-stack dan khusus IPv6 di Wi-Fi.
• Perangkat yang mendukung jaringan Ethernet HARUS mendukung operasi stack ganda di Ethernet.
• Perangkat yang mendukung data seluler HARUS mendukung operasi IPv6 (khusus IPv6 dan mungkin dual-stack) pada data seluler.
• Saat perangkat terhubung secara bersamaan ke lebih dari satu jaringan (mis., Wi-Fi dan data seluler), aplikasi HARUS secara bersamaan memenuhi persyaratan ini di setiap jaringan yang terhubung.

IPv6 HARUS diaktifkan secara default.

Untuk memastikan komunikasi IPv6 sama andal dengan IPv4, paket IPv6 unicast yang dikirim ke perangkat TIDAK BOLEH dihapus, meskipun layar tidak dalam status aktif. Paket IPv6 multicast redundan, seperti Pengumuman Router yang berulang dan identik, DAPAT dibatasi kecepatannya di hardware atau firmware jika hal itu diperlukan untuk menghemat daya. Dalam kasus tersebut, pembatasan kapasitas TIDAK BOLEH menyebabkan perangkat kehilangan konektivitas IPv6 di jaringan yang mematuhi IPv6 yang menggunakan masa aktif RA minimal 180 detik.

Konektivitas IPv6 HARUS dipertahankan dalam mode tidur.

7.4.6. Setelan Sinkronisasi

Implementasi perangkat HARUS mengaktifkan setelan sinkronisasi otomatis master secara default sehingga metode getMasterSyncAutomatically() menampilkan “true” [Resources, 109].

7.5. Kamera

Implementasi perangkat HARUS menyertakan kamera belakang dan DAPAT menyertakan kamera depan. Kamera belakang adalah kamera yang terletak di sisi perangkat yang berlawanan dengan layar; yaitu, kamera ini mengambil gambar di sisi jauh perangkat, seperti kamera tradisional. Kamera depan adalah kamera yang terletak di sisi perangkat yang sama dengan layar; yaitu, kamera yang biasanya digunakan untuk mengambil gambar pengguna, seperti untuk konferensi video dan aplikasi yang serupa.

Jika implementasi perangkat menyertakan minimal satu kamera, aplikasi HARUS dapat mengalokasikan 3 bitmap secara bersamaan yang sama dengan ukuran gambar yang dihasilkan oleh sensor kamera resolusi terbesar di perangkat.

7.5.1. Kamera Belakang

Implementasi perangkat HARUS menyertakan kamera belakang. Jika implementasi perangkat menyertakan minimal satu kamera belakang, perangkat tersebut:

• HARUS melaporkan flag fitur android.hardware.camera dan android.hardware.camera.any.
• HARUS memiliki resolusi minimal 2 megapiksel.
• HARUS memiliki fokus otomatis hardware atau fokus otomatis software yang diterapkan di driver kamera (transparan untuk software aplikasi).
• MUNGKIN memiliki hardware fokus tetap atau EDOF (extended depth of field).
• DAPAT menyertakan flash. Jika Kamera menyertakan flash, lampu flash TIDAK BOLEH menyala saat instance android.hardware.Camera.PreviewCallback telah terdaftar di platform pratinjau Kamera, kecuali jika aplikasi telah secara eksplisit mengaktifkan flash dengan mengaktifkan atribut FLASH_MODE_AUTO atau FLASH_MODE_ON dari objek Camera.Parameters. Perhatikan bahwa batasan ini tidak berlaku untuk aplikasi kamera sistem bawaan perangkat, tetapi hanya untuk aplikasi pihak ketiga yang menggunakan Camera.PreviewCallback.

7.5.2. Kamera Depan

Implementasi perangkat DAPAT menyertakan kamera depan. Jika implementasi perangkat menyertakan minimal satu kamera depan, perangkat tersebut:

• HARUS melaporkan flag fitur android.hardware.camera.any dan android.hardware.camera.front.
• HARUS memiliki resolusi minimal VGA (640x480 piksel).
• TIDAK BOLEH menggunakan kamera depan sebagai default untuk Camera API. API kamera di Android memiliki dukungan khusus untuk kamera depan dan implementasi perangkat TIDAK BOLEH mengonfigurasi API untuk memperlakukan kamera depan sebagai kamera belakang default, meskipun itu satu-satunya kamera di perangkat.
• DAPAT menyertakan fitur (seperti fokus otomatis, flash, dll.) yang tersedia untuk kamera belakang seperti yang dijelaskan dalam bagian 7.5.1.
• HARUS mencerminkan (yaitu menduplikasi) streaming yang ditampilkan oleh aplikasi di CameraPreview secara horizontal, sebagai berikut:
  • Jika implementasi perangkat dapat diputar oleh pengguna (seperti otomatis melalui akselerometer atau secara manual melalui input pengguna), pratinjau kamera HARUS dicerminkan secara horizontal relatif terhadap orientasi perangkat saat ini.
  • Jika aplikasi saat ini telah secara eksplisit meminta agar tampilan Kamera diputar melalui panggilan ke metode android.hardware.Camera.setDisplayOrientation()[Resources, 110], pratinjau kamera HARUS dicerminkan secara horizontal relatif terhadap orientasi yang ditentukan oleh aplikasi.
  • Jika tidak, pratinjau HARUS dicerminkan di sepanjang sumbu horizontal default perangkat.
• HARUS mencerminkan gambar yang ditampilkan oleh postview dengan cara yang sama seperti streaming gambar pratinjau kamera. Jika implementasi perangkat tidak mendukung postview, persyaratan ini jelas tidak berlaku.
• TIDAK BOLEH mencerminkan gambar diam atau streaming video akhir yang diambil dan ditampilkan ke callback aplikasi atau di-commit ke penyimpanan media.

7.5.3. Kamera Eksternal

Implementasi perangkat dengan mode host USB DAPAT menyertakan dukungan untuk kamera eksternal yang terhubung ke port USB. Jika perangkat menyertakan dukungan untuk kamera eksternal, perangkat tersebut:

• HARUS mendeklarasikan fitur platform android.hardware.camera.external dan android.hardware camera.any.
• HARUS mendukung USB Video Class (UVC 1.0 atau yang lebih tinggi).
• DAPAT mendukung beberapa kamera.

Dukungan kompresi video (seperti MJPEG) DISARANKAN untuk memungkinkan transfer streaming berkualitas tinggi yang tidak dienkode (yaitu streaming gambar mentah atau yang dikompresi secara independen). Encoding video berbasis kamera MUNGKIN didukung. Jika demikian, streaming MJPEG/ tidak dienkode serentak (resolusi QVGA atau lebih tinggi) HARUS dapat diakses oleh implementasi perangkat.

7.5.4. Perilaku Camera API

Android menyertakan dua paket API untuk mengakses kamera, android.hardware.camera2 API yang lebih baru mengekspos kontrol kamera tingkat rendah ke aplikasi, termasuk alur burst/streaming zero-copy yang efisien dan kontrol per frame eksposur, gain, gain white balance, konversi warna, denoising, sharpening, dan lainnya.

Paket API lama, android.hardware.Camera, ditandai sebagai tidak digunakan lagi di Android 5.0, tetapi karena masih harus tersedia bagi aplikasi untuk menggunakan implementasi perangkat Android, HARUS memastikan dukungan API yang berkelanjutan seperti yang dijelaskan di bagian ini dan di Android SDK.

Implementasi perangkat HARUS menerapkan perilaku berikut untuk API terkait kamera, untuk semua kamera yang tersedia:

• Jika aplikasi belum pernah memanggil android.hardware.Camera.Parameters.setPreviewFormat(int), perangkat HARUS menggunakan android.hardware.PixelFormat.YCbCr_420_SP untuk data pratinjau yang diberikan ke callback aplikasi.
• Jika aplikasi mendaftarkan instance android.hardware.Camera.PreviewCallback dan sistem memanggil metode onPreviewFrame() saat format pratinjau adalah YCbCr_420_SP, data dalam byte[] yang diteruskan ke onPreviewFrame() harus lebih lanjut berada dalam format encoding NV21. Artinya, NV21 HARUS menjadi default.
• Untuk android.hardware.Camera, implementasi perangkat HARUS mendukung format YV12 (seperti yang ditunjukkan oleh konstanta android.graphics.ImageFormat.YV12) untuk pratinjau kamera untuk kamera depan dan belakang. (Encoder video hardware dan kamera dapat menggunakan format piksel native apa pun, tetapi penerapan perangkat HARUS mendukung konversi ke YV12.)
• Untuk android.hardware.camera2, implementasi perangkat harus mendukung format android.hardware.ImageFormat.YUV_420_888 dan android.hardware.ImageFormat.JPEG sebagai output melalui android.media.ImageReader API.

Implementasi perangkat HARUS tetap menerapkan Camera API lengkap yang disertakan dalam dokumentasi Android SDK [Referensi, 111], terlepas dari apakah perangkat menyertakan fokus otomatis hardware atau kemampuan lainnya. Misalnya, kamera yang tidak memiliki fokus otomatis HARUS tetap memanggil instance android.hardware.Camera.AutoFocusCallback yang terdaftar (meskipun hal ini tidak relevan dengan kamera non-fokus otomatis.) Perhatikan bahwa hal ini berlaku untuk kamera depan; misalnya, meskipun sebagian besar kamera depan tidak mendukung fokus otomatis, callback API masih harus “dipalsukan” seperti yang dijelaskan.

Implementasi perangkat HARUS mengenali dan mematuhi setiap nama parameter yang ditentukan sebagai konstanta di class android.hardware.Camera.Parameters, jika hardware yang mendasarinya mendukung fitur tersebut. Jika hardware perangkat tidak mendukung fitur, API harus berperilaku seperti yang didokumentasikan. Sebaliknya, implementasi perangkat TIDAK BOLEH mematuhi 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 hardware memungkinkan, dan TIDAK BOLEH mendukung jenis parameter Kamera kustom. Misalnya, implementasi perangkat yang mendukung pengambilan gambar menggunakan teknik pencitraan rentang dinamis tinggi (HDR) HARUS mendukung parameter kamera Camera.SCENE_MODE_HDR [Resources, 112].

Karena tidak semua implementasi perangkat dapat sepenuhnya mendukung semua fitur android.hardware.camera2 API, implementasi perangkat HARUS melaporkan level dukungan yang tepat dengan properti android.info.supportedHardwareLevel seperti yang dijelaskan di Android SDK [Referensi, 113] dan melaporkan flag fitur framework yang sesuai [Referensi, 114].

Implementasi perangkat JUGA HARUS mendeklarasikan kemampuan kamera Individualnya dari android.hardware.camera2 melalui properti android.request.availableCapabilities dan mendeklarasikan flag fitur yang sesuai [Referensi, 114]; perangkat harus menentukan flag fitur jika ada perangkat kamera yang terpasang yang mendukung fitur tersebut.

Implementasi perangkat HARUS menyiarkan intent Camera.ACTION_NEW_PICTURE setiap kali foto baru diambil oleh kamera dan entri foto telah ditambahkan ke penyimpanan media.

Implementasi perangkat HARUS menyiarkan intent Camera.ACTION_NEW_VIDEO setiap kali video baru direkam oleh kamera dan entri gambar telah ditambahkan ke penyimpanan media.

7.5.5. Orientasi Kamera

Kamera depan dan belakang, jika ada, HARUS diorientasikan sehingga dimensi panjang kamera sejajar dengan dimensi panjang layar. Artinya, saat perangkat dipegang dalam orientasi lanskap, kamera HARUS mengambil gambar dalam orientasi lanskap. Hal ini berlaku terlepas dari orientasi alam perangkat; yaitu, berlaku untuk perangkat utama lanskap serta perangkat utama potret.

7.6. Memori dan Penyimpanan

7.6.1. Memori dan Penyimpanan Minimum

Memori yang tersedia untuk kernel dan ruang pengguna pada implementasi perangkat HARUS setidaknya sama dengan atau lebih besar dari nilai minimum yang ditentukan oleh tabel berikut. (Lihat bagian 7.1.1 untuk mengetahui definisi ukuran dan kepadatan layar.)

Kepadatan dan ukuran layar	Perangkat 32-bit	Perangkat 64-bit
Perangkat Android Watch (karena layar yang lebih kecil)	416MB	Tidak berlaku
280 dpi atau lebih rendah di layar kecil/normal mdpi atau lebih rendah di perangkat layar besar ldpi atau lebih rendah di perangkat layar ekstra besar	424MB	704MB
xhdpi atau lebih tinggi di perangkat berlayar kecil/normal hdpi atau lebih tinggi di perangkat layar besar mdpi atau lebih tinggi di perangkat layar ekstra besar	512 MB	832MB
400 dpi atau lebih tinggi di layar kecil/normal xhdpi atau yang lebih tinggi di layar besar tvdpi atau yang lebih tinggi di layar ekstra besar	896MB	1.280 MB
560 dpi atau lebih tinggi pada layar kecil/normal 400 dpi atau lebih tinggi di perangkat layar besar xhdpi atau yang lebih tinggi di layar ekstra besar	1344MB	1824MB

Nilai memori minimum HARUS ditambahkan ke ruang memori yang sudah didedikasikan untuk komponen hardware seperti radio, video, dan sebagainya yang tidak dikontrol kernel.

Implementasi perangkat dengan memori kurang dari 512 MB yang tersedia untuk kernel dan ruang pengguna, kecuali Android Watch, HARUS menampilkan nilai "true" untuk ActivityManager.isLowRamDevice().

Perangkat Android Television HARUS memiliki penyimpanan minimal 5 GB dan penerapan perangkat lainnya HARUS memiliki penyimpanan non-volatil minimal 1,5 GB yang tersedia untuk data pribadi aplikasi. Artinya, partisi /data HARUS minimal 5 GB untuk perangkat Android Television dan minimal 1,5 GB untuk implementasi perangkat lainnya. Implementasi perangkat yang menjalankan Android SANGAT DISARANKAN untuk memiliki penyimpanan non-volatil minimal 3 GB untuk data pribadi aplikasi sehingga perangkat tersebut dapat diupgrade ke rilis platform mendatang.

Android API menyertakan Download Manager yang DAPAT digunakan aplikasi untuk mendownload file data [Referensi, 115]. Implementasi perangkat Download Manager HARUS mampu mendownload setiap file berukuran minimal 100 MB ke lokasi "cache" default.

7.6.2. Penyimpanan Bersama Aplikasi

Implementasi perangkat HARUS menawarkan penyimpanan bersama untuk aplikasi yang juga sering disebut sebagai “penyimpanan eksternal bersama”.

Implementasi perangkat HARUS dikonfigurasi dengan penyimpanan bersama yang dipasang secara default, “langsung pakai”. Jika penyimpanan bersama tidak dipasang di jalur Linux /sdcard, perangkat HARUS menyertakan link simbolis Linux dari /sdcard ke titik pemasangan yang sebenarnya.

Implementasi perangkat DAPAT memiliki hardware untuk penyimpanan yang dapat dilepas dan dapat diakses pengguna, seperti slot kartu Secure Digital (SD). Jika slot ini digunakan untuk memenuhi persyaratan penyimpanan bersama, implementasi perangkat:

• HARUS menerapkan antarmuka pengguna toast atau pop-up yang memperingatkan pengguna saat tidak ada kartu SD.
• HARUS menyertakan kartu SD berformat FAT berukuran 1 GB atau lebih besar ATAU menunjukkan pada kotak dan materi lain yang tersedia pada saat pembelian bahwa kartu SD harus dibeli secara terpisah.
• HARUS memasang kartu SD secara default.

Atau, implementasi perangkat DAPAT mengalokasikan penyimpanan internal (tidak dapat dilepas) sebagai penyimpanan bersama untuk aplikasi seperti yang disertakan dalam Project Open Source Android upstream; implementasi perangkat HARUS menggunakan konfigurasi ini dan implementasi software. Jika implementasi perangkat menggunakan penyimpanan internal (tidak dapat dilepas) untuk memenuhi persyaratan penyimpanan bersama, meskipun penyimpanan tersebut DAPAT berbagi ruang dengan data pribadi aplikasi, penyimpanan tersebut HARUS berukuran setidaknya 1 GB dan dipasang di /sdcard (atau /sdcard HARUS berupa link simbolis ke lokasi fisik jika dipasang di tempat lain).

Implementasi perangkat HARUS menerapkan izin android.permission.WRITE_EXTERNAL_STORAGE seperti yang didokumentasikan pada penyimpanan bersama ini. Penyimpanan bersama HARUS dapat ditulis oleh aplikasi apa pun yang mendapatkan izin tersebut.

Implementasi perangkat yang menyertakan beberapa jalur penyimpanan bersama (seperti slot kartu SD dan penyimpanan internal bersama) HARUS hanya mengizinkan aplikasi Android bawaan & berhak istimewa dengan izin WRITE_EXTERNAL_STORAGE untuk menulis ke penyimpanan eksternal sekunder, kecuali saat menulis ke direktori khusus paket atau dalam URI yang ditampilkan dengan mengaktifkan intent ACTION_OPEN_DOCUMENT_TREE.

Namun, implementasi perangkat HARUS mengekspos konten dari jalur penyimpanan secara transparan melalui layanan pemindai media Android dan android.provider.MediaStore.

Terlepas dari bentuk penyimpanan bersama yang digunakan, jika implementasi perangkat memiliki port USB dengan dukungan mode periferal USB, implementasi tersebut HARUS menyediakan beberapa mekanisme untuk mengakses konten penyimpanan bersama dari komputer host. Implementasi perangkat DAPAT menggunakan penyimpanan massal USB, tetapi HARUS menggunakan Media Transfer Protocol untuk memenuhi persyaratan ini. Jika penerapan perangkat mendukung Media Transfer Protocol, perangkat tersebut:

• HARUS kompatibel dengan host MTP Android referensi, Android File Transfer [Referensi, 116].
• HARUS melaporkan class perangkat USB 0x00.
• HARUS melaporkan nama antarmuka USB 'MTP'.

7.6.3. Penyimpanan yang Dapat Diadaptasi

IMPLEMENTASI PERANGKAT SANGAT DISARANKAN untuk menerapkan penyimpanan yang dapat diadopsi jika port perangkat penyimpanan yang dapat dilepas berada di lokasi yang stabil dalam jangka panjang, seperti dalam kompartemen baterai atau penutup pelindung lainnya [Referensi, 117].

Implementasi perangkat seperti televisi, DAPAT memungkinkan adopsi melalui port USB karena perangkat diharapkan bersifat statis dan tidak bergerak. Namun, untuk implementasi perangkat lain yang bersifat seluler, SANGAT DISARANKAN untuk menerapkan penyimpanan yang dapat diadopsi di lokasi stabil jangka panjang, karena secara tidak sengaja memutuskan hubungannya dapat menyebabkan kehilangan/kerusakan data.

7.7. USB

Implementasi perangkat HARUS mendukung mode periferal USB dan HARUS mendukung mode host USB.

Jika implementasi perangkat menyertakan port USB yang mendukung mode periferal:

• Port HARUS dapat dihubungkan ke host USB yang memiliki port USB type-A atau type -C standar.
• Port HARUS menggunakan faktor bentuk USB micro-B, micro-AB, atau Type-C. Perangkat Android yang ada dan baru SANGAT DISARANKAN untuk memenuhi persyaratan ini sehingga dapat diupgrade ke rilis platform mendatang.
• Port HARUS berada di bagian bawah perangkat (sesuai dengan orientasi alam) atau mengaktifkan rotasi layar software untuk semua aplikasi (termasuk layar utama), sehingga layar digambar dengan benar saat perangkat diorientasikan dengan port di bagian bawah. Perangkat Android yang ada dan baru SANGAT DISARANKAN untuk memenuhi persyaratan ini sehingga dapat diupgrade ke rilis platform mendatang.
• Perangkat HARUS menerapkan API dan spesifikasi Android Open Accessory (AOA) seperti yang didokumentasikan dalam dokumentasi Android SDK, dan jika merupakan perangkat Android Handheld, perangkat HARUS menerapkan AOA API. Implementasi perangkat yang menerapkan spesifikasi AOA:
  • HARUS mendeklarasikan dukungan untuk fitur hardware android.hardware.usb.accessory [Referensi, 118].
  • HARUS mendukung pembentukan komunikasi berbasis protokol AOA saat pertama kali terhubung dengan mesin host USB yang berfungsi sebagai aksesori, tanpa perlu pengguna mengubah mode USB default.
  • HARUS menerapkan class audio USB seperti yang didokumentasikan dalam dokumentasi Android SDK [Referensi, 119].
  • Dan juga class penyimpanan massal USB, HARUS menyertakan string "android" di akhir string iInterface deskripsi antarmuka penyimpanan massal USB
• Perangkat HARUS menerapkan dukungan untuk menarik arus 1,5 A selama chirp dan traffic HS seperti yang ditentukan dalam Spesifikasi Pengisian Daya Baterai USB, Revisi 1.2 [Referensi, 120]. Perangkat Android yang ada dan baru SANGAT DISARANKAN untuk memenuhi persyaratan ini sehingga dapat diupgrade ke rilis platform mendatang.
standar resistor Type-C.
• Nilai iSerialNumber dalam deskripsi perangkat standar USB HARUS sama dengan nilai android.os.Build.SERIAL.

Jika implementasi perangkat menyertakan port USB yang mendukung mode host, port tersebut:

• HARUS menggunakan port USB type-C, jika implementasi perangkat mendukung USB 3.1.
• BOLEH menggunakan faktor bentuk port non-standar, tetapi jika demikian, HARUS dikirimkan dengan kabel atau kabel yang menyesuaikan port ke port USB tipe A atau tipe C standar.
• BOLEH menggunakan port USB micro-AB, tetapi jika demikian, HARUS dilengkapi dengan kabel atau kabel yang menyesuaikan port ke port USB type-A atau type-C standar.
• SANGAT DIUJAMI untuk menerapkan class audio USB seperti yang didokumentasikan dalam dokumentasi Android SDK [Referensi, 119].
• HARUS menerapkan API host USB Android seperti yang didokumentasikan di Android SDK, dan HARUS mendeklarasikan dukungan untuk fitur hardware android.hardware.usb.host [Referensi, 121].
• HARUS mendukung pengisian daya perangkat saat dalam mode host; mengiklankan arus sumber minimal 1,5 A seperti yang ditentukan di bagian Parameter Penghentian dalam Spesifikasi Konektor dan Kabel USB Type-C, Revisi 1.2 [] untuk konektor USB Type-C atau menggunakan rentang arus output Port Arus Turun Pengisian Daya(CDP) seperti yang ditentukan dalam Spesifikasi Pengisian Daya Baterai USB, Revisi 1.2 [Referensi, 120] untuk konektor Micro-AB.

7.8. Audio

7.8.1. Mikrofon

Implementasi perangkat DAPAT menghilangkan mikrofon. Namun, jika penerapan perangkat menghilangkan mikrofon, penerapan tersebut TIDAK BOLEH melaporkan konstanta fitur android.hardware.microphone, dan HARUS menerapkan API perekaman audio setidaknya sebagai no-ops, sesuai bagian 7. Sebaliknya, implementasi perangkat yang memiliki mikrofon:

• HARUS melaporkan konstanta fitur android.hardware.microphone
• HARUS memenuhi persyaratan perekaman audio di bagian 5.4
• HARUS memenuhi persyaratan latensi audio di bagian 5.6
• SANGAT DIUJAMI untuk mendukung perekaman near-ultrasound seperti yang dijelaskan di bagian 7.8.3

7.8.2. Output Audio

Implementasi perangkat termasuk speaker atau dengan port output audio/multimedia untuk periferal output audio seperti headset atau speaker eksternal:

• HARUS melaporkan konstanta fitur android.hardware.audio.output.
• HARUS memenuhi persyaratan pemutaran audio di bagian 5.5.
• HARUS memenuhi persyaratan latensi audio di bagian 5.6.
• SANGAT DIUJAMI untuk mendukung pemutaran hampir ultrasound seperti yang dijelaskan di bagian 7.8.3

Sebaliknya, jika implementasi perangkat tidak menyertakan port output speaker atau audio, implementasi tersebut TIDAK BOLEH melaporkan fitur output android.hardware.audio, dan HARUS menerapkan API terkait Output Audio setidaknya sebagai no-ops.

Implementasi perangkat Android Watch BOLEH, tetapi TIDAK BOLEH memiliki output audio, tetapi jenis implementasi perangkat Android lainnya HARUS memiliki output audio dan mendeklarasikan android.hardware.audio.output.

7.8.2.1. Port Audio Analog

Agar kompatibel dengan headset dan aksesori audio lainnya yang menggunakan colokan audio 3,5 mm di seluruh ekosistem Android [Referensi, 122], jika implementasi perangkat menyertakan satu atau beberapa port audio analog, setidaknya salah satu port audio HARUS berupa jack audio 3,5 mm 4 konduktor. Jika implementasi perangkat memiliki jack audio 3,5 mm 4 konduktor, perangkat tersebut:

• HARUS mendukung pemutaran audio ke headphone stereo dan headset stereo dengan mikrofon, dan HARUS mendukung perekaman audio dari headset stereo dengan mikrofon.
• HARUS mendukung steker audio TRRS dengan urutan pin CTIA, dan HARUS mendukung steker audio dengan urutan pin OMTP.
• HARUS mendukung deteksi mikrofon pada aksesori audio yang dicolokkan, jika implementasi perangkat mendukung mikrofon, dan menyiarkan android.intent.action.HEADSET_PLUG dengan mikrofon nilai tambahan yang ditetapkan sebagai 1.
• HARUS mendukung deteksi dan pemetaan ke kode kunci untuk 3 rentang impedansi ekuivalen berikut antara mikrofon dan konduktor ground pada steker audio:
  • 70 ohm atau kurang: KEYCODE_HEADSETHOOK
  • 210-290 Ohm: KEYCODE_VOLUME_UP
  • 360-680 Ohm: KEYCODE_VOLUME_DOWN
• HARUS mendukung deteksi dan pemetaan ke kode kunci untuk rentang impedansi setara berikut antara konduktor mikrofon dan ground pada steker audio:
  • 110-180 Ohm: KEYCODE_VOICE_ASSIST
• HARUS memicu ACTION_HEADSET_PLUG saat steker dimasukkan, tetapi hanya setelah semua kontak pada steker menyentuh segmen yang relevan di jack.
• HARUS dapat menggerakkan setidaknya 150 mV ± 10% tegangan output pada impedansi speaker 32 Ohm.
• HARUS memiliki voltase bias mikrofon antara 1,8 V ~ 2,9 V.

7.8.3. Ultrasonografi Dekat

Audio Near-Ultrasound adalah band 18,5 kHz hingga 20 kHz. Implementasi perangkat HARUS melaporkan dukungan kemampuan audio near-ultrasound dengan benar melalui AudioManager.getProperty API sebagai berikut:

• Jika PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND adalah "true", maka
  • Respons daya rata-rata mikrofon dalam band 18,5 kHz hingga 20 kHz HARUS tidak lebih dari 15 dB di bawah respons pada 2 kHz.
  • Rasio sinyal-ke-derau (SNR) mikrofon yang tidak tertimbang di atas 18,5 kHz hingga 20 kHz untuk nada 19 kHz pada -26 dBFS HARUS tidak lebih rendah dari 50 dB.
• Jika PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND bernilai "true", respons rata-rata speaker dalam 18,5 kHz - 20 kHz HARUS tidak lebih rendah dari 40 dB di bawah respons pada 2 kHz.

8. Performa dan Daya

Beberapa kriteria performa dan daya minimum sangat penting untuk pengalaman pengguna dan memengaruhi asumsi dasar yang akan dimiliki developer saat mengembangkan aplikasi. Perangkat Android Watch HARUS dan jenis implementasi perangkat lainnya HARUS memenuhi kriteria berikut:

8.1. Konsistensi Pengalaman Pengguna

Implementasi perangkat HARUS memberikan antarmuka pengguna yang lancar dengan memastikan kecepatan frame dan waktu respons yang konsisten untuk aplikasi dan game. Implementasi perangkat HARUS memenuhi persyaratan berikut:

• Latensi frame yang konsisten. Latensi frame yang tidak konsisten atau penundaan untuk merender frame TIDAK BOLEH terjadi lebih sering dari 5 frame dalam satu detik, dan HARUS di bawah 1 frame dalam satu detik.
• Latensi antarmuka pengguna. Implementasi perangkat HARUS memastikan pengalaman pengguna latensi rendah dengan men-scroll daftar 10 ribu entri daftar seperti yang ditentukan oleh Android Compatibility Test Suite (CTS) dalam waktu kurang dari 36 detik.
• Peralihan tugas. Jika beberapa aplikasi telah diluncurkan, meluncurkan ulang aplikasi yang sudah berjalan setelah diluncurkan HARUS memerlukan waktu kurang dari 1 detik.

8.2. Performa Akses I/O File

Implementasi perangkat HARUS memastikan konsistensi performa akses file penyimpanan internal untuk operasi baca dan tulis.

• Penulisan berurutan. Implementasi perangkat HARUS memastikan performa operasi tulis berurutan minimal 5 MB/detik untuk file 256 MB menggunakan buffering operasi tulis 10 MB.
• Penulisan acak. Implementasi perangkat HARUS memastikan performa penulisan acak minimal 0,5 MB/s untuk file 256 MB menggunakan buffering penulisan 4 KB.
• Pembacaan berurutan. Implementasi perangkat HARUS memastikan performa operasi baca berurutan minimal 15 MB/s untuk file 256 MB menggunakan buffering operasi tulis 10 MB.
• Pembacaan acak. Implementasi perangkat HARUS memastikan performa pembacaan acak minimal 3,5 MB/dtk untuk file 256 MB menggunakan buffering tulis 4 KB.

8.3. Mode Hemat Daya

Semua aplikasi yang dikecualikan dari mode Standby Aplikasi dan/atau Mode tidur HARUS terlihat oleh pengguna akhir. Selain itu, algoritma pemicu, pemeliharaan, dan pengaktifan serta penggunaan setelan sistem Global dari mode hemat daya ini TIDAK BOLEH menyimpang dari Project Open Source Android.

8.4. Akuntansi Konsumsi Daya

Pencatatan dan pelaporan konsumsi daya yang lebih akurat memberikan insentif dan alat kepada developer aplikasi untuk mengoptimalkan pola penggunaan daya aplikasi. Oleh karena itu, implementasi perangkat:

• HARUS dapat melacak penggunaan daya komponen hardware dan mengatribusikan penggunaan daya tersebut ke aplikasi tertentu. Secara khusus, penerapan:
  • HARUS memberikan profil daya per komponen yang menentukan nilai konsumsi saat ini untuk setiap komponen hardware dan perkiraan pemakaian baterai yang disebabkan oleh komponen dari waktu ke waktu seperti yang didokumentasikan di situs Android Open Source Project [Referensi, 123].
  • HARUS melaporkan semua nilai konsumsi daya dalam miliamper jam (mAh)
  • HARUS diatribusikan ke komponen hardware itu sendiri jika tidak dapat mengatribusikan penggunaan daya komponen hardware ke aplikasi.
  • HARUS melaporkan konsumsi daya CPU per UID setiap proses. Project Open Source Android memenuhi persyaratan melalui penerapan modul kernel uid_cputime.
• HARUS menyediakan penggunaan daya ini melalui perintah shell adb shell dumpsys batterystats kepada developer aplikasi [Referensi, 124].
• HARUS mematuhi intent android.intent.action.POWER_USAGE_SUMMARY dan menampilkan menu setelan yang menampilkan penggunaan daya ini [Referensi, 125].

9. Kompatibilitas Model Keamanan

Implementasi perangkat HARUS menerapkan model keamanan yang konsisten dengan model keamanan platform Android seperti yang ditentukan dalam dokumen referensi Keamanan dan Izin di API [Referensi, 126] dalam dokumentasi developer Android. Implementasi perangkat HARUS mendukung penginstalan 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 di subbagian berikut.

9.1. Izin

Implementasi perangkat HARUS mendukung model izin Android seperti yang ditentukan dalam dokumentasi developer Android [Referensi, 126]. Secara khusus, implementasi HARUS menerapkan setiap izin yang ditentukan seperti yang dijelaskan dalam dokumentasi SDK; tidak ada izin yang boleh dihilangkan, diubah, atau diabaikan. Implementasi DAPAT menambahkan izin tambahan, asalkan string ID izin baru tidak berada dalam namespace android.*.

Izin dengan tingkat perlindungan berbahaya adalah izin runtime. Aplikasi dengan targetSdkVersion > 22 memintanya saat runtime. Implementasi perangkat:

• HARUS menampilkan antarmuka khusus bagi pengguna untuk memutuskan apakah akan memberikan izin runtime yang diminta dan juga menyediakan antarmuka bagi pengguna untuk mengelola izin runtime.
• HARUS memiliki satu dan hanya satu implementasi dari kedua antarmuka pengguna.
• TIDAK BOLEH memberikan izin runtime apa pun ke aplikasi bawaan kecuali jika:
  • izin pengguna dapat diperoleh sebelum aplikasi menggunakannya
  • izin runtime dikaitkan dengan pola intent yang aplikasi bawaannya ditetapkan sebagai pengendali default

9.2. Isolasi UID dan Proses

Implementasi perangkat HARUS mendukung model sandbox aplikasi Android, yang menjalankan setiap aplikasi sebagai UID gaya Unix yang unik dan dalam proses terpisah. Implementasi perangkat HARUS mendukung beberapa aplikasi yang berjalan sebagai ID pengguna Linux yang sama, asalkan aplikasi ditandatangani dan dibuat dengan benar, seperti yang ditentukan dalam referensi Keamanan dan Izin [Referensi, 126].

9.3. Izin Sistem File

Implementasi perangkat HARUS mendukung model izin akses file Android seperti yang ditentukan dalam referensi Keamanan dan Izin [Referensi, 126].

9.4. Lingkungan Eksekusi Alternatif

Implementasi perangkat DAPAT menyertakan lingkungan runtime yang mengeksekusi aplikasi menggunakan beberapa software atau teknologi selain Format Eksekusi Dalvik atau kode native. Namun, lingkungan eksekusi alternatif tersebut TIDAK BOLEH mengancam model keamanan Android atau keamanan aplikasi Android yang diinstal, seperti yang dijelaskan di bagian ini.

Runtime alternatif HARUS berupa aplikasi Android, dan mematuhi model keamanan Android standar, seperti yang dijelaskan di tempat lain dalam bagian 9.

Runtime alternatif TIDAK BOLEH diberi akses ke resource yang dilindungi oleh izin yang tidak diminta dalam file AndroidManifest.xml runtime melalui mekanisme <uses-permission>.

Runtime alternatif TIDAK BOLEH mengizinkan aplikasi menggunakan fitur yang dilindungi oleh izin Android yang dibatasi untuk aplikasi sistem.

Runtime alternatif HARUS mematuhi model sandbox Android. Secara khusus, runtime alternatif:

• HARUS menginstal aplikasi melalui PackageManager ke sandbox Android terpisah (ID pengguna Linux, dll.).
• DAPAT menyediakan satu sandbox Android yang digunakan bersama oleh semua aplikasi yang menggunakan runtime alternatif.
• dan aplikasi terinstal yang menggunakan runtime alternatif, TIDAK BOLEH menggunakan kembali sandbox aplikasi lain yang diinstal di perangkat, kecuali melalui mekanisme Android standar untuk ID pengguna bersama dan sertifikat penandatanganan.
• TIDAK BOLEH diluncurkan dengan, memberikan, atau diberi akses ke sandbox yang sesuai dengan aplikasi Android lainnya.
• TIDAK BOLEH diluncurkan dengan, diberikan, atau memberikan kepada aplikasi lain hak istimewa superuser (root), atau ID pengguna lainnya.

File .apk runtime alternatif DAPAT disertakan dalam image 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 izin pengguna untuk izin Android yang digunakan oleh aplikasi. Jika aplikasi perlu menggunakan resource perangkat yang memiliki izin Android yang sesuai (seperti Kamera, GPS, dll.), runtime alternatif HARUS memberi tahu pengguna bahwa aplikasi akan dapat mengakses resource tersebut. Jika lingkungan runtime tidak mencatat kemampuan aplikasi dengan cara ini, lingkungan runtime HARUS mencantumkan semua izin yang dimiliki oleh runtime itu sendiri saat menginstal aplikasi apa pun menggunakan runtime tersebut.

9.5. Dukungan Multi-Pengguna

Android menyertakan dukungan untuk beberapa pengguna dan memberikan dukungan untuk isolasi pengguna penuh [Referensi, 127]. Implementasi perangkat DAPAT mengaktifkan beberapa pengguna, tetapi jika diaktifkan, HARUS memenuhi persyaratan berikut yang terkait dengan dukungan multi-pengguna [Referensi, 128]:

• Implementasi perangkat yang tidak mendeklarasikan flag fitur android.hardware.telephony HARUS mendukung profil yang dibatasi, fitur yang memungkinkan pemilik perangkat mengelola pengguna tambahan dan kemampuan mereka di perangkat. Dengan profil yang dibatasi, pemilik perangkat dapat dengan cepat menyiapkan lingkungan terpisah bagi pengguna tambahan untuk bekerja, dengan kemampuan untuk mengelola pembatasan yang lebih terperinci dalam aplikasi yang tersedia di lingkungan tersebut.
• Sebaliknya, implementasi perangkat yang mendeklarasikan flag fitur android.hardware.telephony TIDAK BOLEH mendukung profil yang dibatasi, tetapi HARUS selaras dengan implementasi kontrol AOSP untuk mengaktifkan /menonaktifkan pengguna lain agar tidak mengakses panggilan suara dan SMS.
• Implementasi perangkat HARUS, untuk setiap pengguna, menerapkan model keamanan yang konsisten dengan model keamanan platform Android seperti yang ditentukan dalam dokumen referensi Keamanan dan Izin di API [Referensi, 126].
• Setiap instance pengguna di perangkat Android HARUS memiliki direktori penyimpanan eksternal yang terpisah dan terisolasi. Implementasi perangkat DAPAT menyimpan beberapa data pengguna di volume atau sistem file yang sama. Namun, implementasi perangkat HARUS memastikan bahwa aplikasi yang dimiliki dan berjalan atas nama pengguna tertentu tidak dapat mencantumkan, membaca, atau menulis ke data yang dimiliki oleh pengguna lain. Perhatikan bahwa media yang dapat dilepas, seperti slot kartu SD, dapat memungkinkan satu pengguna mengakses data pengguna lain melalui PC host. Oleh karena itu, implementasi perangkat yang menggunakan media yang dapat dilepas untuk API penyimpanan eksternal utama HARUS mengenkripsi konten kartu SD jika multi-pengguna diaktifkan menggunakan kunci yang hanya disimpan di media yang tidak dapat dilepas dan hanya dapat diakses oleh sistem. Karena hal ini akan membuat media tidak dapat dibaca oleh PC host, penerapan perangkat akan diwajibkan untuk beralih ke MTP atau sistem serupa untuk memberikan akses ke data pengguna saat ini kepada PC host. Oleh karena itu, implementasi perangkat DAPAT tetapi TIDAK BOLEH mengaktifkan multi-pengguna jika menggunakan media yang dapat dilepas [Referensi, 129] untuk penyimpanan eksternal utama.

9.6. Peringatan SMS Premium

Android menyertakan dukungan untuk memperingatkan pengguna tentang pesan SMS premium keluar [Referensi, 130]. Pesan SMS Premium adalah pesan teks yang dikirim ke layanan yang terdaftar dengan operator yang dapat dikenai biaya kepada pengguna. Implementasi perangkat yang mendeklarasikan dukungan untuk android.hardware.telephony HARUS memperingatkan pengguna sebelum mengirim pesan SMS ke nomor yang diidentifikasi oleh ekspresi reguler yang ditentukan dalam file /data/misc/sms/codes.xml di perangkat. Project Open Source Android upstream menyediakan implementasi yang memenuhi persyaratan ini.

9.7. Fitur Keamanan Kernel

Sandbox Android menyertakan fitur yang menggunakan sistem kontrol akses wajib (MAC) Security-Enhanced Linux (SELinux) dan fitur keamanan lainnya di kernel Linux. SELinux atau fitur keamanan lainnya yang diterapkan di bawah framework Android:

• HARUS mempertahankan kompatibilitas dengan aplikasi yang ada.
• TIDAK BOLEH memiliki antarmuka pengguna yang terlihat saat pelanggaran keamanan terdeteksi dan berhasil diblokir, tetapi DAPAT memiliki antarmuka pengguna yang terlihat saat pelanggaran keamanan yang tidak diblokir terjadi sehingga mengakibatkan eksploitasi yang berhasil.
• TIDAK BOLEH dikonfigurasi oleh pengguna atau developer.

Jika API untuk konfigurasi kebijakan diekspos ke aplikasi yang dapat memengaruhi aplikasi lain (seperti Device Administration API), API TIDAK BOLEH mengizinkan konfigurasi yang merusak kompatibilitas.

Perangkat HARUS menerapkan SELinux atau, jika menggunakan kernel selain Linux, sistem kontrol akses wajib yang setara. Perangkat JUGA HARUS memenuhi persyaratan berikut, yang dipenuhi oleh implementasi referensi di Project Open Source Android upstream.

Implementasi perangkat:

• HARUS menetapkan SELinux ke mode penerapan global.
• HARUS mengonfigurasi semua domain dalam mode penerapan. Tidak ada domain mode permisif yang diizinkan, termasuk domain khusus untuk perangkat/vendor.
• TIDAK BOLEH mengubah, menghapus, atau mengganti aturan neverallow yang ada dalam folder external/sepolicy yang disediakan di Project Open Source Android (AOSP) upstream dan kebijakan HARUS dikompilasi dengan semua aturan neverallow yang ada, baik untuk domain AOSP SELinux maupun domain khusus perangkat/vendor.

Implementasi perangkat HARUS mempertahankan kebijakan SELinux default yang disediakan di folder external/sepolicy dari Project Open Source Android upstream dan hanya menambahkan kebijakan ini lebih lanjut untuk konfigurasi khusus perangkat mereka sendiri. Implementasi perangkat HARUS kompatibel dengan Project Open Source Android upstream.

9.8. Privasi

Jika perangkat menerapkan fungsi dalam sistem yang merekam konten yang ditampilkan di layar dan/atau merekam streaming audio yang diputar di perangkat, perangkat HARUS terus memberi tahu pengguna setiap kali fungsi ini diaktifkan dan secara aktif merekam/merekam.

Jika implementasi perangkat memiliki mekanisme yang merutekan traffic data jaringan melalui server proxy atau gateway VPN secara default (misalnya, memuat layanan VPN secara otomatis dengan android.permission.CONTROL_VPN yang diberikan), implementasi perangkat HARUS meminta izin pengguna sebelum mengaktifkan mekanisme tersebut.

Jika implementasi perangkat memiliki port USB dengan dukungan mode periferal USB, perangkat HARUS menampilkan antarmuka pengguna yang meminta izin pengguna sebelum mengizinkan akses ke konten penyimpanan bersama melalui port USB.

9.9. Enkripsi Disk Penuh

Jika implementasi perangkat mendukung layar kunci aman yang melaporkan "true" untuk KeyguardManager.isDeviceSecure() [Referensi, 131], dan bukan perangkat dengan memori terbatas seperti yang dilaporkan melalui metode ActivityManager.isLowRamDevice(), perangkat HARUS mendukung enkripsi disk penuh [Referensi, 132] data pribadi aplikasi (partisi /data), serta aplikasi partisi penyimpanan bersama (partisi /sdcard) jika merupakan bagian perangkat yang permanen dan tidak dapat dilepas.

Untuk implementasi perangkat yang mendukung enkripsi disk penuh dan dengan performa kripto Advanced Encryption Standard (AES) di atas 50 MiB/detik, enkripsi disk penuh HARUS diaktifkan secara default saat pengguna menyelesaikan pengalaman penyiapan siap pakai. Jika implementasi perangkat sudah diluncurkan pada versi Android sebelumnya dengan enkripsi disk penuh dinonaktifkan secara default, perangkat tersebut tidak dapat memenuhi persyaratan melalui update software sistem sehingga DAPAT dikecualikan.

Enkripsi HARUS menggunakan AES dengan kunci 128-bit (atau lebih besar) dan mode yang dirancang untuk penyimpanan (misalnya, AES-XTS, AES-CBC-ESSIV). Kunci enkripsi TIDAK BOLEH ditulis ke penyimpanan kapan saja tanpa dienkripsi. Selain saat digunakan secara aktif, kunci enkripsi HARUS dienkripsi AES dengan kode sandi layar kunci yang diregangkan menggunakan algoritma peregangan lambat (misalnya PBKDF2 atau scrypt). Jika pengguna belum menentukan kode sandi layar kunci atau telah menonaktifkan penggunaan kode sandi untuk enkripsi, sistem HARUS menggunakan kode sandi default untuk menggabungkan kunci enkripsi. Jika perangkat menyediakan keystore yang didukung hardware, algoritma peregangan sandi HARUS terikat secara kriptografis ke keystore tersebut. Kunci enkripsi TIDAK BOLEH dikirim dari perangkat (bahkan jika digabungkan dengan kode sandi pengguna dan/atau kunci yang terikat hardware). Project Open Source Android upstream menyediakan implementasi fitur ini yang lebih disukai berdasarkan fitur kernel Linux dm-crypt.

9.10. Booting Terverifikasi

Booting terverifikasi adalah fitur yang menjamin integritas software perangkat. Jika penerapan perangkat mendukung fitur ini, perangkat HARUS:

• Mendeklarasikan flag fitur platform android.software.verified_boot
• Melakukan verifikasi pada setiap urutan booting
• Mulai verifikasi dari kunci hardware yang tidak dapat diubah yang merupakan root of trust, dan lanjutkan hingga ke partisi sistem
• Terapkan setiap tahap verifikasi untuk memeriksa integritas dan keaslian semua byte di tahap berikutnya sebelum menjalankan kode di tahap berikutnya
• Gunakan algoritma verifikasi yang sekuat rekomendasi saat ini dari NIST untuk algoritma hashing (SHA-256) dan ukuran kunci publik (RSA-2048)

Project Open Source Android upstream menyediakan implementasi yang lebih disukai untuk fitur ini berdasarkan fitur kernel Linux dm-verity.

Mulai Android 6.0, implementasi perangkat dengan performa kripto Advanced Encryption Standard (AES) di atas 50 MiB/detik HARUS mendukung booting terverifikasi untuk integritas perangkat. Jika implementasi perangkat sudah diluncurkan tanpa mendukung booting terverifikasi di versi Android sebelumnya, perangkat tersebut tidak dapat menambahkan dukungan untuk fitur ini dengan update software sistem sehingga dikecualikan dari persyaratan.

9.11. Kunci dan Kredensial

Sistem Android Keystore [Referensi, 133] memungkinkan developer aplikasi menyimpan kunci kriptografis dalam penampung dan menggunakannya dalam operasi kriptografis melalui KeyChain API [Referensi, 134] atau Keystore API [Referensi, 135].

Semua implementasi perangkat Android HARUS memenuhi persyaratan berikut:

• TIDAK BOLEH membatasi jumlah kunci yang dapat dihasilkan, dan HARUS setidaknya mengizinkan lebih dari 8.192 kunci untuk diimpor.
• Autentikasi layar kunci HARUS membatasi percobaan dan HARUS memiliki algoritma backoff eksponensial seperti yang diterapkan di Project Open Source Android.
• Jika implementasi perangkat mendukung layar kunci aman dan memiliki hardware aman seperti Elemen Pengaman (SE) tempat Trusted Execution Environment (TEE) dapat diterapkan, perangkat tersebut:
  • SANGAT DISARANKAN untuk mencadangkan implementasi keystore dengan hardware yang aman. Project Open Source Android upstream menyediakan implementasi Keymaster Hardware Abstraction Layer (HAL) yang dapat digunakan untuk memenuhi persyaratan ini.
  • HARUS melakukan autentikasi layar kunci di hardware aman jika perangkat memiliki penerapan keystore yang didukung hardware dan hanya jika berhasil mengizinkan kunci yang terikat autentikasi untuk digunakan. Project Open Source Android upstream menyediakan Gatekeeper Hardware Abstraction Layer (HAL) yang dapat digunakan untuk memenuhi persyaratan ini [Referensi, 136].

Perhatikan bahwa meskipun persyaratan terkait TEE di atas dinyatakan sebagai SANGAT DIUJUDKAN, Definisi Kompatibilitas untuk versi API berikutnya direncanakan untuk mengubahnya menjadi DIWAJIBKAN. Jika implementasi perangkat sudah diluncurkan pada versi Android sebelumnya dan belum menerapkan sistem operasi tepercaya di hardware yang aman, perangkat tersebut mungkin tidak dapat memenuhi persyaratan melalui update software sistem, sehingga SANGAT DISARANKAN untuk menerapkan TEE.

9.12. Penghapusan Data

Perangkat HARUS memberikan mekanisme kepada pengguna untuk melakukan "Reset Data Pabrik" yang memungkinkan penghapusan logis dan fisik semua data kecuali image sistem dan data di partisi lain yang dapat dianggap sebagai bagian dari image sistem. Hal ini HARUS memenuhi standar industri yang relevan untuk penghapusan data seperti NIST SP800-88. Ini HARUS digunakan untuk implementasi wipeData() API (bagian dari Android Device Administration API) yang dijelaskan di bagian 3.9 Device Administration.

Perangkat DAPAT menyediakan penghapusan total data cepat yang melakukan penghapusan data logis.

10. Pengujian Kompatibilitas Software

Implementasi perangkat HARUS lulus semua pengujian yang dijelaskan di bagian ini.

Namun, perlu diperhatikan bahwa tidak ada paket pengujian software yang sepenuhnya komprehensif. Karena alasan ini, pengimplementasi perangkat SANGAT DISARANKAN untuk membuat jumlah perubahan minimum sebanyak mungkin pada referensi dan implementasi Android pilihan yang tersedia dari Project Open Source Android. Tindakan ini akan meminimalkan risiko munculnya bug yang menyebabkan inkompatibilitas yang memerlukan pengerjaan ulang dan potensi update perangkat.

10.1. Compatibility Test Suite (CTS)

Implementasi perangkat HARUS lulus Android Compatibility Test Suite (CTS) [Referensi, 137] yang tersedia dari Android Open Source Project, menggunakan software pengiriman final di perangkat. Selain itu, implementator perangkat HARUS menggunakan implementasi referensi di hierarki Open Source Android sebanyak mungkin, dan HARUS memastikan kompatibilitas jika terjadi ambiguitas di CTS dan untuk implementasi ulang bagian kode sumber referensi.

CTS dirancang untuk dijalankan di perangkat yang sebenarnya. Seperti software lainnya, CTS sendiri mungkin berisi bug. CTS akan diberi versi secara terpisah dari Definisi Kompatibilitas ini, dan beberapa revisi CTS dapat dirilis untuk Android 6.0. Implementasi perangkat HARUS lulus versi CTS terbaru yang tersedia saat software perangkat selesai.

10.2. Pemverifikasi CTS

Implementasi perangkat HARUS menjalankan semua kasus yang berlaku dengan benar di Verifikator CTS. CTS Verifier disertakan dengan Compatibility Test Suite, dan dimaksudkan untuk dijalankan oleh operator manusia untuk menguji fungsi yang tidak dapat diuji oleh sistem otomatis, seperti fungsi kamera dan sensor yang benar.

CTS Verifier memiliki pengujian untuk berbagai jenis hardware, termasuk beberapa hardware yang bersifat opsional. Implementasi perangkat HARUS lulus semua pengujian untuk hardware yang dimilikinya; misalnya, jika perangkat memiliki akselerometer, perangkat HARUS menjalankan kasus pengujian Akselerasi dengan benar di CTS Verifier. Kasus pengujian untuk fitur yang dicatat sebagai opsional oleh Dokumen Definisi Kompatibilitas ini DAPAT dilewatkan atau dihilangkan.

Setiap perangkat dan setiap build HARUS menjalankan CTS Verifier dengan benar, seperti yang disebutkan di atas. Namun, karena banyak build yang sangat mirip, implementer perangkat tidak diharapkan untuk menjalankan Verifikator CTS secara eksplisit pada build yang hanya berbeda dengan cara yang tidak penting. Secara khusus, implementasi perangkat yang berbeda dari implementasi yang telah lulus CTS Verifier hanya dengan kumpulan lokalitas, branding, dan sebagainya yang disertakan DAPAT menghilangkan pengujian CTS Verifier.

11. Software yang Dapat Diupdate

Implementasi perangkat HARUS menyertakan mekanisme untuk mengganti seluruh software sistem. Mekanisme ini tidak perlu melakukan upgrade “langsung”—yaitu, memulai ulang perangkat MUNGKIN diperlukan.

Metode apa pun dapat digunakan, asalkan dapat menggantikan seluruh software yang diprainstal di perangkat. Misalnya, salah satu pendekatan berikut akan memenuhi persyaratan ini:

• Download “Over-the-air (OTA)” dengan update offline melalui mulai ulang
• Update “Tethered” melalui USB dari PC host
• Update “Offline” melalui mulai ulang dan update dari file di penyimpanan yang dapat dilepas

Namun, jika implementasi perangkat menyertakan dukungan untuk koneksi data tanpa kuota seperti profil 802.11 atau Bluetooth PAN (Personal Area Network):

• Implementasi Android Automotive HARUS mendukung download OTA dengan update offline melalui mulai ulang.
• Semua implementasi perangkat lainnya HARUS mendukung download OTA dengan update offline melalui mulai ulang.

Mekanisme update yang digunakan HARUS mendukung update tanpa menghapus data pengguna. Artinya, mekanisme update HARUS mempertahankan data pribadi aplikasi dan data yang dibagikan aplikasi. Perhatikan bahwa software Android upstream menyertakan mekanisme update yang memenuhi persyaratan ini.

Untuk implementasi perangkat yang diluncurkan dengan Android 6.0 dan yang lebih baru, mekanisme update HARUS mendukung verifikasi bahwa image sistem adalah biner yang identik dengan hasil yang diharapkan setelah OTA. Implementasi OTA berbasis blok di Project Open Source Android upstream, yang ditambahkan sejak Android 5.1, memenuhi persyaratan ini.

Jika error ditemukan dalam penerapan perangkat setelah dirilis, tetapi dalam masa aktif produk yang wajar yang ditentukan melalui konsultasi dengan Tim Kompatibilitas Android untuk memengaruhi kompatibilitas aplikasi pihak ketiga, pelaksana perangkat HARUS memperbaiki error melalui update software yang tersedia dan dapat diterapkan sesuai dengan mekanisme yang baru saja dijelaskan.

Android menyertakan fitur yang memungkinkan aplikasi Pemilik Perangkat (jika ada) mengontrol penginstalan update sistem. Untuk memfasilitasi hal ini, subsistem update sistem untuk perangkat yang melaporkan android.software.device_admin HARUS mengimplementasikan perilaku yang dijelaskan dalam class SystemUpdatePolicy [ Resource, 138].

12. Log Perubahan Dokumen

Tabel berikut berisi ringkasan perubahan pada Definisi Kompatibilitas dalam rilis ini.

Bagian	Ringkasan perubahan
Bervariasi	Mengganti instance istilah "dianjurkan" dengan "DISARANKAN"
2. Jenis Perangkat	Update untuk penerapan Android Automotive
3.2.2. Parameter Build	Penambahan untuk nomor seri hardware dan untuk tingkat patch keamanan build
3.2.3.2. Resolusi Maksud	Bagian diganti namanya dari "Intent Overrides" menjadi "Intent Resolution", dengan persyaratan baru yang terkait dengan penautan aplikasi default yang kredibel
3.3.1. Antarmuka Biner Aplikasi	Penambahan untuk dukungan ABI Android; perubahan terkait nama library Vulkan
3.4.1. Kompatibilitas WebView	Perubahan untuk string agen pengguna yang dilaporkan oleh WebView
3.7. Kompatibilitas Runtime	Pembaruan pada tabel alokasi memori
3.8.4. Telusuri	Info terbaru terkait persyaratan Asisten
3.8.6. Tema	Menambahkan persyaratan untuk mendukung ikon sistem hitam saat diminta oleh flag SYSTEM_UI_FLAG_LIGHT_STATUS_BAR
3.8.8. Peralihan Aktivitas	Persyaratan jumlah judul Ringkasan yang diperlonggar.
3.8.10. Kontrol Media Layar Kunci	Lock Screen Media Control untuk merujuk ke 3.8.3 secara mendetail.
3.9.1. Penyediaan Perangkat	Berisi bagian baru untuk penyediaan pemilik perangkat dan penyediaan profil terkelola
3.9.2. Dukungan Profil Terkelola	Bagian baru dengan persyaratan untuk dukungan perangkat terhadap fungsi profil terkelola
3.12.1. Aplikasi TV	Menambahkan bagian untuk memperjelas persyaratan Aplikasi TV untuk perangkat Android Television
3.12.1.1. Panduan Program Elektronik	Menambahkan bagian untuk memperjelas persyaratan EPG untuk perangkat Android Television
3.12.1.2. Navigasi	Menambahkan bagian untuk memperjelas persyaratan navigasi Aplikasi TV untuk perangkat Android TV
3.12.1.3. Penautan aplikasi input TV	Menambahkan bagian untuk memperjelas persyaratan dukungan penautan aplikasi input TV untuk perangkat Android Television
5.1. Codec Media	Pembaruan terkait dukungan untuk format media inti dan decoding.
5.1.3. Codec Video	Perubahan dan penambahan yang terkait dengan Android TV
5.2. Encoding Video	Perubahan untuk encoder
5.3. Dekode Video	Perubahan untuk dekoder, termasuk terkait dukungan untuk resolusi video dinamis, pengalihan kecepatan frame, dan lainnya
5.4. Perekaman Audio	Penambahan yang terkait dengan perekaman audio
5.6. Latensi Audio	Pembaruan terkait pelaporan dukungan untuk audio latensi rendah
5.10. Audio Profesional	Update umum untuk dukungan audio profesional; update untuk spesifikasi perangkat seluler (jack), mode host audio USB, dan update lainnya
5.9. Musical Instrument Digital Interface (MIDI)	Menambahkan bagian baru tentang dukungan Musical Instrument Digital Interface (MIDI) opsional
6.1. Alat Pengembang	Update untuk driver yang mendukung Windows 10
7.1.1.3. Kepadatan Layar	Update untuk kepadatan layar, misalnya terkait smartwatch Android
7.2.3. Tombol Navigasi	Persyaratan yang diperbarui untuk implementasi perangkat yang menyertakan tindakan Bantuan
7.3. Sensor (dan subbagian)	Persyaratan baru untuk beberapa jenis sensor
7.3.9. Sensor Akurasi Tinggi	Bagian baru dengan persyaratan untuk perangkat yang mendukung sensor fidelitas tinggi
7.3.10. Sensor Sidik Jari	Bagian baru tentang persyaratan terkait sensor sidik jari
7.4.2. IEEE 802.11 (Wi-Fi)	Pembaruan terkait dukungan untuk multicast DNS (mDNS)
7.4.3. Bluetooth	Penambahan yang terkait dengan Alamat Pribadi yang Dapat Di-resolve (RPA) untuk Bluetooth Hemat Energi (BLE)
7.4.4. Komunikasi Nirkabel Jarak Dekat	Penambahan persyaratan untuk Komunikasi Nirkabel Jarak Dekat (NFC)
7.4.5. Kemampuan Jaringan Minimum	Menambahkan persyaratan untuk dukungan IPv6
7.6.3. Penyimpanan yang Dapat Diadaptasi	Bagian baru untuk penerapan penyimpanan yang dapat diadaptasi
7.7. USB	Persyaratan terkait penerapan spesifikasi AOA
7.8.3. Ultrasonografi Dekat	Penambahan yang terkait dengan rekaman, pemutaran, dan audio near-ultrasound	Melonggarkan persyaratan SNR mikrofon Near-ultrasound.
8.3. Mode Hemat Daya	Bagian baru dengan persyaratan terkait mode Aplikasi Standby dan Istirahatkan
8.4. Akuntansi Konsumsi Daya	Bagian baru dengan persyaratan untuk melacak penggunaan daya komponen hardware dan mengatribusikan penggunaan daya tersebut ke aplikasi tertentu
9.1. Izin	Penambahan pada persyaratan Izin
9.7. Fitur Keamanan Kernel	Update SE Linux
9.8. Privasi	Penambahan terkait izin pengguna untuk mengakses penyimpanan bersama melalui port USB
9.9. Enkripsi Disk Penuh	Persyaratan terkait enkripsi disk penuh
9.10. Booting Terverifikasi	Persyaratan tambahan untuk booting terverifikasi
9.11. Kunci dan Kredensial	Bagian persyaratan baru yang terkait dengan kunci dan kredensial
9.12. Penghapusan Data	Bagian baru untuk "Reset Data Pabrik"
11. Software yang Dapat Diupdate	Persyaratan terkait kebijakan update sistem yang ditetapkan oleh pemilik perangkat

13. Hubungi Kami

Anda dapat bergabung ke forum kompatibilitas Android [Referensi, 139] dan meminta klarifikasi atau menyampaikan masalah apa pun yang menurut Anda tidak tercakup dalam dokumen.

14. Referensi

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

2. Project Open Source Android: http://source.android.com/

3. Fitur Android Television: http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_LEANBACK

4. Fitur Android Watch: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_WATCH

5. Android UI_MODE_TYPE_CAR API: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_CAR

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

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

8. Referensi android.os.Build: http://developer.android.com/reference/android/os/Build.html

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

10. Setelan Developer Android: http://developer.android.com/reference/android/provider/Settings.html

11. Penyedia Layanan Telepon: http://developer.android.com/reference/android/provider/Telephony.html

12. Pengelolaan ABI Android NDK: https://developer.android.com/ndk/guides/abis.html

13. Arsitektur SIMD lanjutan: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388f/Beijfcja.html

14. Paket Ekstensi Android: http://developer.android.com/guide/topics/graphics/opengl.html#aep

15. Class android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html

16. Kompatibilitas WebView: http://www.chromium.org/

17. HTML5: http://html.spec.whatwg.org/multipage/

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

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

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

21. API webstorage HTML5/W3C: http://www.w3.org/TR/webstorage/

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

23. Format Dalvik Executable dan spesifikasi bytecode: tersedia di kode sumber Android, di dalvik/docs

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

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

26. Resource Aplikasi: https://developer.android.com/guide/topics/resources/available-resources.html

27. Panduan gaya ikon Status Bar: http://developer.android.com/design/style/iconography.html

28. Referensi Notifikasi: https://developer.android.com/design/patterns/notifications.html

29. Pengelola Penelusuran: http://developer.android.com/reference/android/app/SearchManager.html

30. Action Assist: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST

31. Android Assist API: https://developer.android.com/reference/android/app/assist/package-summary.html

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

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

34. Class R.style: http://developer.android.com/reference/android/R.style.html

35. Desain material: http://developer.android.com/reference/android/R.style.html#Theme_Material

36. Wallpaper Animasi: http://developer.android.com/reference/android/service/wallpaper/WallpaperService.html

37. Referensi layar ringkasan: http://developer.android.com/guide/components/recents.html

38. Sematkan ke layar: https://developer.android.com/about/versions/android-5.0.html#ScreenPinning

39. Metode input: http://developer.android.com/guide/topics/text/creating-input-method.html

40. Notifikasi Media: https://developer.android.com/reference/android/app/Notification.MediaStyle.html

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

42. Settings.Secure LOCATION_MODE: http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE

43. Unicode 6.1.0: http://www.unicode.org/versions/Unicode6.1.0/

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

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

46. Aplikasi Pemilik Perangkat: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)

47. Alur Penyediaan Pemilik Perangkat Android: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_DEVICE

48. Penyediaan Pemilik Perangkat melalui NFC: /devices/tech/admin/provision.html#device_owner_provisioning_via_nfc

49. Aplikasi Pemilik Profil Android:http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isProfileOwnerApp(java.lang.String)

50. Alur Penyediaan Profil Terkelola Android: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_PROFILE

51. API Layanan Aksesibilitas Android: http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html

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

53. Project Eyes Free: http://code.google.com/p/eyes-free

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

55. Framework Input Televisi: /devices/tv/index.html

56. Channel Aplikasi TV: http://developer.android.com/reference/android/media/tv/TvContract.Channels.html

57. Input TV pihak ketiga: /devices/tv/index.html#third-party_input_example

58. Input TV: /devices/tv/index.html#tv_inputs

59. Kolom EPG saluran TV: https://developer.android.com/reference/android/media/tv/TvContract.Programs.html

60. Penautan aplikasi input TV: http://developer.android.com/reference/android/media/tv/TvContract.Channels.html#COLUMN_APP_LINK_INTENT_URI

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

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

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

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

65. Android MediaCodecList API: http://developer.android.com/reference/android/media/MediaCodecList.html

66. Android CamcorderProfile API: http://developer.android.com/reference/android/media/CamcorderProfile.html

67. Project WebM: http://www.webmproject.org/

68. Persyaratan Coding Hardware RTC: http://www.webmproject.org/hardware/rtc-coding-requirements/

69. AudioEffect API: http://developer.android.com/reference/android/media/audiofx/AudioEffect.html

70. Class android.content.pm.PackageManager Android dan Daftar Fitur Hardware: http://developer.android.com/reference/android/content/pm/PackageManager.html

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

72. ADB: http://developer.android.com/tools/help/adb.html

73. Dumpsys: /devices/input/diagnostics.html

74. DDMS: http://developer.android.com/tools/debugging/ddms.html

75. Alat pengujian Monkey: http://developer.android.com/tools/help/monkey.html

76. Alat SysyTrace: http://developer.android.com/tools/help/systrace.html

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

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

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

80. RenderScript: http://developer.android.com/guide/topics/renderscript/

81. Paket ekstensi Android untuk OpenGL ES: https://developer.android.com/reference/android/opengl/GLES31Ext.html

82. Akselerasi Hardware: http://developer.android.com/guide/topics/graphics/hardware-accel.html

83. Ekstensi EGL-EGL_ANDROID_RECORDABLE: http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt

84. Pengelola Layar: http://developer.android.com/reference/android/hardware/display/DisplayManager.html

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

86. Konfigurasi Input Sentuh: http://source.android.com/docs/core/interaction/input/touch-devices

87. Motion Event API: http://developer.android.com/reference/android/view/MotionEvent.html

88. Key Event API: http://developer.android.com/reference/android/view/KeyEvent.html

89. Sensor Open Source Android: http://source.android.com/docs/core/interaction/sensors

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

91. Peristiwa sensor stempel waktu: http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp

92. Sensor gabungan Open Source Android: /docs/core/interaction/sensors/sensor-types#composite_sensor_type_summary

93. Mode pemicu berkelanjutan: http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER

95. Android Fingerprint API: https://developer.android.com/reference/android/hardware/fingerprint/package-summary.html

96. HAL Sidik Jari Android: /devices/tech/security/authentication/fingerprint-hal.html

97. Wi-Fi Multicast API: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html

98. Wi-Fi Direct (Wi-Fi P2P): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html

99. WifiManager API: http://developer.android.com/reference/android/net/wifi/WifiManager.html

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

101. Bluetooth ScanFilter API: https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html

102. Kode Batang NFC: http://developer.android.com/reference/android/nfc/tech/NfcBarcode.html

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

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

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

106. NFC Connection Handover: http://members.nfc-forum.org/specs/spec_list/#conn_handover

107. Penyambungan Bluetooth Aman dan Sederhana Menggunakan NFC: http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf

108. Emulasi Kartu Berbasis Host: http://developer.android.com/guide/topics/connectivity/nfc/hce.html

109. Resolver Konten: http://developer.android.com/reference/android/content/ContentResolver.html

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

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

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

113. Tingkat hardware kamera: https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#INFO_SUPPORTED_HARDWARE_LEVEL

114. Dukungan versi kamera: http://source.android.com/docs/core/camera/versioning

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

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

117. Penyimpanan yang dapat diadopsi: http://source.android.com/docs/core/storage/adoptable

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

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

120. Spesifikasi Pengisian Daya Baterai USB, Revisi 1.2: http://www.usb.org/developers/docs/devclass_docs/BCv1.2_070312.zip

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

122. Headset audio berkabel: http://source.android.com/docs/core/interaction/accessories/headset/plug-headset-spec

123. Komponen profil daya: http://source.android.com/docs/core/power/values

124. Batterystats: https://developer.android.com/tools/dumpsys#battery

125. Ringkasan penggunaan daya: http://developer.android.com/reference/android/content/Intent.html#ACTION_POWER_USAGE_SUMMARY

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

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

128. Referensi Penyimpanan Eksternal: http://source.android.com/docs/core/storage/traditional

129. External Storage API: http://developer.android.com/reference/android/os/Environment.html

130. Kode Singkat SMS: http://en.wikipedia.org/wiki/Short_code

131. Pelaporan layar kunci aman: http://developer.android.com/reference/android/app/KeyguardManager.html#isDeviceSecure()

132. Enkripsi Open Source Android: http://source.android.com/docs/security/features/encryption

133. Sistem Android Keystore: https://developer.android.com/training/articles/keystore.html

134. KeyChain API: https://developer.android.com/reference/android/security/KeyChain.html

135. Keystore API: https://developer.android.com/reference/java/security/KeyStore.html

136. HAL Gatekeeper: http://source.android.com/docs/security/features/authentication/gatekeeper

137. Ringkasan Program Kompatibilitas Android: http://source.android.com/docs/compatibility

138. Class SystemUpdatePolicy: http://developer.android.com/reference/android/app/admin/SystemUpdatePolicy.html

139. Forum Kompatibilitas Android: https://groups.google.com/forum/#!forum/android-compatibility

140. Menangani link aplikasi: https://developer.android.com/training/app-links/index.html

141. Digital Asset Links Google: https://developers.google.com/digital-asset-links

Banyak dari resource ini berasal secara langsung atau tidak langsung dari Android SDK, dan akan identik secara fungsional dengan informasi dalam dokumentasi SDK tersebut. Jika Definisi Kompatibilitas ini atau Compatibility Test Suite tidak sesuai dengan dokumentasi SDK, dokumentasi SDK dianggap kredibel. Setiap detail teknis yang diberikan dalam referensi yang disertakan di atas dianggap sebagai bagian dari Definisi Kompatibilitas ini.