Penggunaan “HARUS”, “TIDAK BOLEH”, “WAJIB”, “TIDAK BOLEH”, “TIDAK BOLEH”, “Seharusnya”, “DIREKOMENDASIKAN”, “MUNGKIN”, dan “OPSIONAL” sesuai dengan standar IETF yang ditentukan dalam RFC2119.

Seperti yang digunakan dalam dokumen ini, “pengimplementasikan perangkat” atau “implementasi” adalah orang atau organisasi yang mengembangkan solusi perangkat keras/perangkat lunak yang menjalankan Android 7.0. "Implementasi perangkat" atau "implementasi adalah solusi perangkat keras/perangkat lunak yang dikembangkan.

Agar dianggap kompatibel dengan Android 7.0, implementasi perangkat HARUS memenuhi persyaratan yang diberikan dalam Definisi Kompatibilitas ini, termasuk semua dokumen yang disertakan melalui referensi.

Jika definisi ini atau pengujian software yang dijelaskan di bagian 10 bersifat diam, ambigu, atau tidak lengkap, implementasi perangkat bertanggung jawab untuk memastikan kompatibilitas dengan implementasi yang ada.

Karena alasan ini, Proyek Open Source Android adalah referensi dan implementasi pilihan Android. Pengimplementasi perangkat SANGAT DIREKOMENDASIKAN untuk mendasarkan implementasi mereka sebaik mungkin pada kode sumber “upstream” yang tersedia dari Project Open Source Android. Meskipun beberapa komponen secara hipotesis dapat diganti dengan implementasi alternatif, SANGAT DIREKOMENDASIKAN untuk tidak mengikuti praktik ini, karena lulus pengujian software akan menjadi jauh lebih sulit. Pelaksana bertanggung jawab untuk memastikan kompatibilitas perilaku penuh dengan implementasi Android standar, termasuk dan di luar Compatibility Test Suite. Terakhir, perhatikan bahwa penggantian dan modifikasi komponen tertentu secara eksplisit dilarang oleh dokumen ini.

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

2. Jenis Perangkat

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

Perangkat Genggam Android mengacu pada penerapan perangkat Android yang biasanya digunakan dengan menggenggamnya, seperti pemutar mp3, ponsel, dan tablet. Implementasi Perangkat Genggam Android:

HARUS memiliki layar sentuh yang tertanam di perangkat.
HARUS memiliki sumber listrik yang dapat bergerak, seperti baterai.

Perangkat Android Television mengacu pada penerapan perangkat Android yang merupakan antarmuka hiburan untuk menonton media digital, film, game, aplikasi, dan/atau TV live bagi pengguna yang duduk sekitar sepuluh kaki dari jarak jauh ("antarmuka pengguna yang santai" atau "antarmuka pengguna 10 kaki"). Perangkat Android Television:

HARUS memiliki layar yang tertanam ATAU menyertakan port output video, seperti VGA, HDMI, atau port nirkabel untuk tampilan.
HARUS mendeklarasikan fitur android.software.Kampanye dan android.hardware.type.television.

Perangkat Android Watch mengacu pada implementasi perangkat Android yang dimaksudkan untuk dikenakan pada 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.

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 memiliki layar dengan panjang diagonal fisik sama dengan atau lebih besar dari 6 inci.
HARUS mendeklarasikan fitur android.hardware.type.automotive.
HARUS mendukung uiMode = UI_MODE_TYPE_CAR.
Implementasi Android Automotive HARUS mendukung semua API publik dalam namespace android.car.*.

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

2.1 Konfigurasi Perangkat

Ini adalah ringkasan perbedaan utama dalam konfigurasi hardware berdasarkan jenis perangkat. (Sel kosong menunjukkan “MEI”). Tidak semua konfigurasi dibahas dalam tabel ini; lihat bagian perangkat keras yang relevan untuk detail lebih lanjut.

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		SEHARUSNYA
	Mikrofon	7.8.1 Mikrofon	HARUS	SEHARUSNYA	HARUS	HARUS	SEHARUSNYA
Sensor	Akselerometer	7.3.1 Akselerometer	SEHARUSNYA		SEHARUSNYA		SEHARUSNYA
Sensor	GPS	7.3.3 GPS	SEHARUSNYA			SEHARUSNYA
Konektivitas	Wi-Fi	7.4.2 IEEE 802.11	SEHARUSNYA	SEHARUSNYA		SEHARUSNYA	SEHARUSNYA
	Wi-Fi Direct	7.4.2.1 Wi-Fi Langsung	SEHARUSNYA	SEHARUSNYA			SEHARUSNYA
	Bluetooth	7.4.3. Bluetooth	SEHARUSNYA	HARUS	HARUS	HARUS	SEHARUSNYA
	Bluetooth Hemat Energi	7.4.3. Bluetooth	SEHARUSNYA	HARUS	SEHARUSNYA	SEHARUSNYA	SEHARUSNYA
	Radio seluler	7.4.5. Kemampuan Jaringan Minimum				SEHARUSNYA
	Mode host/periferal USB	7.7. USB	SEHARUSNYA			SEHARUSNYA	SEHARUSNYA
Output	Port output Speaker dan/atau Audio	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. Android application programming interface (API) adalah serangkaian antarmuka platform Android yang diekspos ke aplikasi yang berjalan di lingkungan runtime terkelola. Penerapan perangkat HARUS memberikan penerapan lengkap, termasuk semua perilaku yang didokumentasikan, untuk API terdokumentasi apa pun yang diekspos oleh Android SDK atau API apa pun yang dilengkapi dengan penanda “@SystemApi” di kode sumber Android upstream.

Implementasi perangkat HARUS mendukung/mempertahankan semua class, metode, dan elemen terkait yang ditandai dengan anotasi TestApi (@TestApi).

Implementasi perangkat TIDAK BOLEH menghilangkan API terkelola apa pun, mengubah antarmuka atau tanda tangan API, menyimpang dari perilaku yang didokumentasikan, atau menyertakan tanpa operasi, kecuali jika secara khusus diizinkan oleh Compatibility Definition ini.

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

3.1.1. Ekstensi Android

Android menyertakan dukungan untuk memperluas API terkelola dengan tetap mempertahankan versi API level yang sama. Implementasi perangkat Android HARUS melakukan pramuat implementasi AOSP dari library bersama ExtShared dan layanan ExtServices dengan versi yang lebih tinggi dari atau sama dengan versi minimum yang diizinkan per setiap level API. Misalnya, implementasi perangkat Android 7.0, menjalankan API level 24 HARUS menyertakan setidaknya versi 1.

3.2. Kompatibilitas Soft API

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

3.2.1. Izin

Pengimplementasi perangkat HARUS mendukung dan menerapkan semua konstanta izin seperti yang didokumentasikan oleh Halaman referensi izin. Perlu diperhatikan bahwa pasal 9 mencantumkan persyaratan tambahan terkait model keamanan Android.

3.2.2 Parameter Build

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

Parameter	Detail
VERSION.RELEASE	Versi sistem Android yang saat ini dijalankan, dalam format yang dapat dibaca manusia. Kolom ini HARUS memiliki salah satu nilai string yang ditentukan di 7.0.
VERSION.SDK	Versi sistem Android yang saat ini dijalankan, dalam format yang dapat diakses oleh kode aplikasi pihak ketiga. Untuk Android 7.0, kolom ini HARUS memiliki nilai bilangan bulat 7.0_INT.
VERSION.SDK_INT	Versi sistem Android yang saat ini dijalankan, dalam format yang dapat diakses oleh kode aplikasi pihak ketiga. Untuk Android 7.0, kolom ini HARUS memiliki nilai bilangan bulat 7.0_INT.
VERSION.INCREMENTAL	Nilai yang dipilih oleh pengimplementasi perangkat yang menentukan build spesifik dari sistem Android yang saat ini dijalankan, dalam format yang dapat dibaca manusia. Nilai ini TIDAK BOLEH digunakan kembali untuk build berbeda yang disediakan bagi pengguna akhir. Penggunaan kolom ini biasanya untuk menunjukkan nomor build atau ID perubahan kontrol sumber yang digunakan untuk membuat build. Tidak ada persyaratan untuk format khusus kolom ini, kecuali bahwa format tersebut TIDAK BOLEH berupa null atau string kosong ("").
PAPAN	Nilai yang dipilih oleh implementasi perangkat yang mengidentifikasi hardware internal tertentu yang digunakan oleh perangkat, dalam format yang dapat dibaca manusia. Kolom ini dapat digunakan untuk menunjukkan revisi spesifik dari board yang menjalankan 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 sebagaimana 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_-]+$”.
DIDUKUNG_ABI	Nama kumpulan petunjuk (jenis CPU + konvensi ABI) kode native. Lihat bagian 3.3. Kompatibilitas Native API.
SUPPORTED_32_BIT_ABIS	Nama kumpulan petunjuk (jenis CPU + konvensi ABI) kode native. Lihat bagian 3.3. Kompatibilitas Native API.
SUPPORTED_64_BIT_ABIS	Nama kumpulan petunjuk kedua (jenis CPU + konvensi ABI) kode native. Lihat bagian 3.3. Kompatibilitas Native API.
ABI_CPU	Nama kumpulan petunjuk (jenis CPU + konvensi ABI) kode native. Lihat bagian 3.3. Kompatibilitas Native API.
CPU_ABI2	Nama kumpulan petunjuk kedua (jenis CPU + konvensi ABI) kode native. Lihat bagian 3.3. Kompatibilitas Native API.
PERANGKAT	Nilai yang dipilih oleh pengimplementasikan 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_-]+$”. Nama perangkat ini TIDAK BOLEH berubah selama masa pakai produk.
CETAK JARI	String yang mengidentifikasi build ini secara unik. Harus dapat dibaca oleh manusia. URL HARUS mengikuti {i>template<i} ini: $(BRAND)/$(PRODUCT)/ $(PERANGKAT):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Contoh: acme/myproduct/ mydevice:7.0/LMYXX/3359:userdebug/test-keys Sidik jari TIDAK BOLEH berisi 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 perangkat keras (dari baris perintah {i>kernel<i} atau {i> /proc<i}. Harus dapat dibaca oleh manusia. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9_-]+$”.
HOST	String yang secara unik mengidentifikasi host tempat build dibuat, dalam format yang dapat dibaca manusia. Tidak ada persyaratan untuk format khusus kolom ini, kecuali bahwa format tersebut TIDAK BOLEH berupa null atau string kosong ("").
ID	ID yang dipilih oleh pengimplementasikan perangkat untuk merujuk pada rilis tertentu, dalam format yang dapat dibaca manusia. Kolom ini boleh sama dengan android.os.Build.VERSION.INCREMENTAL, tetapi SEHARUSNYA menjadi nilai yang cukup berarti bagi pengguna akhir agar dapat membedakan berbagai 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 untuk format khusus kolom ini, kecuali bahwa format tersebut TIDAK BOLEH berupa null atau string kosong ("").
MODEL	Nilai yang dipilih oleh pengimplementasi perangkat yang berisi nama perangkat seperti yang diketahui oleh pengguna akhir. Nama ini HARUS sama dengan nama perangkat ini dipasarkan dan dijual kepada pengguna akhir. Tidak ada persyaratan untuk format khusus kolom ini, kecuali bahwa format tersebut TIDAK BOLEH berupa null atau string kosong ("").
PRODUK	Nilai yang dipilih oleh pengimplementasi perangkat yang berisi nama pengembangan atau nama kode produk tertentu (SKU) yang HARUS unik dalam merek yang sama. HARUS dapat dibaca manusia, tetapi tidak 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_-]+$”. Nama produk ini TIDAK BOLEH berubah selama masa pakai produk.
SERI	Nomor seri hardware, yang HARUS tersedia dan unik di seluruh perangkat dengan MODEL dan MANUFACTURER 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 penerapan perangkat yang akan lebih membedakan build. Kolom ini HARUS memiliki salah satu nilai yang sesuai dengan tiga konfigurasi penandatanganan platform Android umum: kunci rilis, kunci dev, kunci pengujian.
WAKTU	Nilai yang mewakili stempel waktu saat build terjadi.
TYPE	Nilai yang dipilih oleh pengimplementasi perangkat yang menentukan konfigurasi runtime build. Kolom ini HARUS memiliki salah satu nilai yang sesuai dengan tiga konfigurasi runtime Android umum: user, userdebug, atau eng.
PENGGUNA	Nama atau ID pengguna pengguna (atau pengguna otomatis) yang membuat build. Tidak ada persyaratan untuk format khusus kolom ini, kecuali bahwa format tersebut TIDAK BOLEH berupa null atau string kosong ("").
PATCH_KEAMANAN	Nilai yang menunjukkan level patch keamanan build. Tanda ini HARUS menunjukkan bahwa build tersebut tidak rentan terhadap masalah apa pun yang dijelaskan melalui Buletin Keamanan Publik Android yang ditetapkan. Nilai ini HARUS dalam format [YYYY-MM-DD], yang cocok dengan string yang ditentukan dan didokumentasikan di Android Public Security Bulletin atau dalam Android Security Advisory, misalnya "2015-11-01".
OS_BASIS	Nilai yang mewakili parameter FINGERPRINT build yang identik dengan build ini, kecuali untuk patch yang disediakan dalam Android Public Security Bulletin. Aplikasi HARUS melaporkan nilai yang benar dan jika build tersebut tidak ada, laporkan string kosong ("").

3.2.3 Kompatibilitas Intent

3.2.3.1 Intent Aplikasi Inti

Intent Android memungkinkan komponen aplikasi meminta fungsionalitas 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
Penelusuran Global
Peluncur
Musik
Setelan

Implementasi perangkat HARUS menyertakan aplikasi Android inti yang sesuai atau komponen yang menerapkan pola intent yang sama dengan yang ditentukan oleh semua komponen Aktivitas atau Layanan dari aplikasi Android inti ini yang diekspos ke aplikasi lain, secara implisit atau eksplisit, melalui atribut android:exported.

3.2.3.2 Resolusi Maksud

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

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

Namun, implementasi perangkat MUNGKIN menyediakan aktivitas default untuk pola URI tertentu (mis. 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. Jika deklarasi otoritatif tersebut ditentukan dalam pola filter intent aplikasi, implementasi perangkat akan:

HARUS mencoba memvalidasi filter intent apa pun dengan melakukan langkah validasi yang ditentukan dalam spesifikasi Digital Asset Links seperti yang diterapkan oleh Pengelola Paket di Project Open Source Android upstream.
HARUS mencoba melakukan validasi filter intent selama penginstalan aplikasi dan menyetel 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 penerapan perangkat melakukannya, penerapan tersebut HARUS memberikan penggantian pola per URI yang sesuai kepada pengguna di menu setelan.
HARUS memberi pengguna kontrol Link Aplikasi per aplikasi di Setelan sebagai berikut:
- Pengguna HARUS dapat mengganti secara menyeluruh perilaku link aplikasi default agar aplikasi menjadi: selalu terbuka, selalu bertanya, atau tidak pernah membuka, yang harus berlaku untuk semua filter intent URI kandidat secara merata.
- Pengguna HARUS dapat melihat daftar filter intent URI kandidat.
- Implementasi perangkat MUNGKIN 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 verifikasi sementara yang lainnya bisa gagal.

3.2.3.3. Namespace Intent

Implementasi perangkat TIDAK BOLEH menyertakan komponen Android apa pun yang mematuhi pola intent siaran atau intent baru menggunakan ACTION, CATEGORY, atau string kunci lainnya di Android. atau com.android.. Pengimplementasikan perangkat TIDAK BOLEH menyertakan komponen Android apa pun yang mematuhi pola intent siaran atau intent baru apa pun menggunakan ACTION, CATEGORY, atau string kunci lainnya dalam ruang paket milik organisasi lain. Pengimplementasikan perangkat TIDAK BOLEH mengubah atau memperluas pola intent apa pun yang digunakan oleh aplikasi inti yang tercantum di bagian 3.2.3.1. Implementasi perangkat MUNGKIN menyertakan pola intent menggunakan namespace yang jelas dan jelas terkait dengan organisasinya sendiri. Larangan ini serupa dengan yang ditetapkan 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 dalam 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 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 ini.

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.
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.
HARUS mematuhi intent android.settings.NFC_PAYMENT_SETTINGS guna menampilkan menu setelan aplikasi default untuk Tempel dan Bayar, jika penerapan perangkat melaporkan android.hardware.nfc.hce.
HARUS mematuhi intent android.telecom.action.CHANGE_DEFAULT_DIALER untuk menampilkan dialog yang memungkinkan pengguna mengubah aplikasi Telepon default, jika implementasi perangkat melaporkan android.hardware.telephony .

3.3. Kompatibilitas Native API

Kompatibilitas kode native sulit dilakukan. Karena alasan ini, pengimplementasi perangkat SANGAT DIREKOMENDASIKAN untuk menggunakan implementasi library yang tercantum di bawah ini dari Project Open Source Android upstream.

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 mendefinisikan sejumlah Antarmuka Biner Aplikasi (ABI) dalam Android NDK. Implementasi perangkat HARUS kompatibel dengan satu atau beberapa ABI yang ditentukan, dan HARUS mengimplementasikan kompatibilitas dengan Android NDK, seperti di bawah ini.

Jika implementasi perangkat menyertakan dukungan untuk ABI Android, implementasi 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 (artinya, 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 ABI 64-bit apa pun didukung.
HARUS melaporkan secara akurat Antarmuka Biner Aplikasi (ABI) native yang didukung perangkat, melalui parameter android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS, dan android.os.Build.SUPPORTED_64_BIT_ABIS, masing-masing merupakan daftar ABI yang dipisahkan koma yang diurutkan dari yang paling banyak hingga yang paling tidak disukai.
HARUS melaporkan, melalui parameter di atas, hanya ABI yang didokumentasikan dan dijelaskan dalam versi terbaru dokumentasi Pengelolaan ABI Android NDK, dan HARUS menyertakan dukungan untuk ekstensi SIMD Lanjutan (alias neon).
HARUS dibuat menggunakan kode sumber dan file header yang tersedia di Project Open Source Android upstream

Perhatikan bahwa rilis Android NDK mendatang mungkin memperkenalkan dukungan untuk ABI tambahan. Jika implementasi perangkat tidak kompatibel dengan ABI yang telah ditetapkan sebelumnya, TIDAK BOLEH melaporkan dukungan untuk ABI apa pun.

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

libandroid.so (dukungan aktivitas Android native)
libc (library C)
libcamera2ndk.so
libdl (penaut dinamis)
libEGL.so (pengelolaan permukaan OpenGL native)
libGLESv1_CM.so (OpenGL ES 1.x)
libGLESv2.so (OpenGL ES 2.0)
libGLESv3.so (OpenGL ES 3.x)
libicui18n.so
libicuuc.so
{i>libjnigraphics.so<i}
liblog (logging Android)
libmediandk.so (dukungan API media native)
libm (perpustakaan matematika)
libOpenMAXAL.so (dukungan OpenMAX AL 1.0.1)
libOpenSLES.so (Dukungan audio OpenSL ES 1.0.1)
libRS.so
mdpi++ (Dukungan minimal untuk C++)
libvulkan.so (Vulkan)
libz (Kompresi zlib)
Antarmuka JNI
Dukungan untuk OpenGL, seperti yang dijelaskan di bawah

Untuk library native yang tercantum di atas, implementasi perangkat TIDAK BOLEH menambahkan atau menghapus fungsi publik.

Library native tidak tercantum di atas tetapi diimplementasikan dan disediakan di AOSP karena library sistem sudah dicadangkan dan TIDAK BOLEH diekspos ke aplikasi pihak ketiga yang menargetkan API level 24 atau yang lebih tinggi.

Implementasi perangkat DAPAT menambahkan library non-AOSP dan menampilkannya secara langsung sebagai API untuk aplikasi pihak ketiga, tetapi library tambahan SEHARUSNYA berada di /vendor/lib atau /vendor/lib64 dan HARUS tercantum di /vendor/etc/public.libraries.txt .

Perhatikan bahwa implementasi perangkat HARUS menyertakan libGLESv3.so dan, pada gilirannya, HARUS mengekspor semua simbol fungsi OpenGL ES 3.1 dan Android Extension Pack seperti yang ditentukan dalam rilis NDK android-24. Meskipun semua simbol harus ada, hanya fungsi yang sesuai untuk versi dan ekstensi OpenGL ES yang benar-benar didukung oleh perangkat yang harus diimplementasikan sepenuhnya.

3.3.1.1 Library Visual

Vulkan adalah API lintas platform dengan overhead rendah untuk grafis 3D berperforma tinggi. Penerapan perangkat, meskipun tidak menyertakan dukungan Vulkan API, HARUS memenuhi persyaratan berikut:

Aplikasi HARUS selalu menyediakan library native bernama libvulkan.so yang mengekspor simbol fungsi untuk Vulkan 1.0 API inti serta ekstensi VK_KHR_surface , VK_KHR_android_surface , dan VK_KHR_swapchain.

Implementasi perangkat, jika menyertakan dukungan Vulkan API:

HARUS melaporkan, satu atau beberapa VkPhysicalDevices melalui panggilan vkEnumeratePhysicalDevices.
Setiap VkPhysicalDevices yang disebutkan HARUS sepenuhnya menerapkan Vulkan 1.0 API.
HARUS melaporkan tombol fitur PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL dan PackageManager#FEATURE_VULKAN_HARDWARE_VERSION yang benar.
HARUS menghitung lapisan, yang terdapat dalam library native bernama libVkLayer*.so dalam direktori library native paket aplikasi, melalui fungsi vkEnumerateInstanceLayerProperties dan vkEnumerateDeviceLayerProperties di libvulkan.so
TIDAK BOLEH menghitung lapisan yang disediakan oleh library di luar paket aplikasi, atau memberikan cara lain untuk melacak atau mencegat Vulkan API, kecuali jika aplikasi tersebut memiliki atribut android:debuggable=”true”.

Penerapan perangkat, jika tidak termasuk dukungan Vulkan API:

HARUS melaporkan 0 VkPhysicalDevices melalui panggilan vkEnumeratePhysicalDevices.
TIDAK BOLEH mendeklarasikan tanda fitur Vulkan PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL dan PackageManager#FEATURE_VULKAN_HARDWARE_VERSION.

3.3.2 Kompatibilitas Kode Native ARM 32-bit

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

Petunjuk SWP dan SWPB
SETEND instruksi
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 dibangun 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.
"Arsitektur CPU: ", diikuti dengan integer yang menjelaskan arsitektur ARM tertinggi yang didukung perangkat (mis., "8" untuk perangkat ARMv8).

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

3.4 Kompatibilitas Web

3.4.1. Kompatibilitas WebView

Perangkat Android Watch MUNGKIN, tetapi semua implementasi perangkat lain HARUS menyediakan implementasi lengkap API android.webkit.Webview API.

Fitur platform android.software.webview HARUS dilaporkan pada perangkat apa pun yang menyediakan implementasi lengkap android.webkit.WebView API, dan TIDAK BOLEH dilaporkan pada perangkat tanpa implementasi API yang lengkap. Implementasi Open Source Android menggunakan kode dari Project Chromium untuk mengimplementasikan android.webkit.WebView. Karena tidak mungkin mengembangkan paket pengujian komprehensif untuk sistem rendering web, pengimplementasi perangkat HARUS menggunakan build upstream tertentu dari Chromium dalam implementasi WebView. Khususnya:

Implementasi android.webkit.WebView perangkat HARUS didasarkan pada build Chromium dari Project Open Source Android upstream untuk Android 7.0. Build ini menyertakan serangkaian fungsi tertentu dan perbaikan keamanan untuk WebView.
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, seperti 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.
- Penerapan perangkat MUNGKIN menghilangkan Seluler dalam string agen pengguna.

Komponen WebView HARUS menyertakan dukungan untuk sebanyak mungkin fitur HTML5 dan jika mendukung fitur tersebut SEHARUSNYA sesuai dengan spesifikasi HTML5.

3.4.2 Kompatibilitas Browser

Implementasi Android Television, Watch, dan Android Automotive MUNGKIN menghilangkan aplikasi browser, tetapi HARUS mendukung pola intent publik seperti yang dijelaskan di bagian 3.2.3.1. Semua jenis implementasi perangkat lainnya HARUS menyertakan aplikasi Browser mandiri untuk penjelajahan web pengguna umum.

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

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

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

Selain itu, implementasi perangkat HARUS mendukung webstorage API HTML5/W3C dan SEHARUSNYA mendukung TensorFlow API HTML5/W3C. Perhatikan bahwa karena badan standar pengembangan web bertransisi untuk mendukung IndexedDB daripada webstorage, IndexedDB diharapkan menjadi komponen yang diperlukan dalam versi Android yang akan datang.

3.5. Kompatibilitas Perilaku API

Perilaku setiap jenis API (terkelola, lunak, native, dan web) harus konsisten dengan implementasi pilihan Project Open Source Android upstream. Beberapa area kompatibilitas tertentu adalah:

Perangkat TIDAK BOLEH mengubah perilaku atau semantik intent standar.
Perangkat TIDAK BOLEH mengubah semantik siklus proses atau 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 sebagian besar platform untuk mengetahui kompatibilitas perilaku, tetapi tidak semuanya. Adalah tanggung jawab pelaksana untuk memastikan kompatibilitas perilaku dengan Project Open Source Android. Karena alasan ini, pengimplementasi perangkat HARUS menggunakan kode sumber yang tersedia melalui Proyek Open Source Android jika memungkinkan, daripada menerapkan kembali bagian penting dari sistem.

3.6. Namespace API

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

java.*
javax.*
matahari.*
Android*.
com.android.*

Perubahan yang dilarang mencakup :

Implementasi perangkat TIDAK BOLEH memodifikasi API yang diekspos secara publik di platform Android dengan mengubah tanda tangan class atau metode apa pun, atau dengan menghapus class atau kolom class.
Pengimplementasikan perangkat DAPAT memodifikasi implementasi dasar API, tetapi modifikasi tersebut TIDAK BOLEH memengaruhi perilaku yang dinyatakan dan tanda tangan bahasa Java dari semua API yang diekspos secara publik.
Pengimplementasi perangkat TIDAK BOLEH menambahkan elemen yang diekspos 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 didekorasi dengan penanda “@hide” seperti yang digunakan dalam kode sumber Android upstream. Dengan kata lain, pengimplementasi perangkat TIDAK BOLEH mengekspos API baru atau mengubah API yang sudah ada dalam namespace yang disebutkan di atas. Pengimplementasikan perangkat DAPAT membuat modifikasi khusus internal, tetapi modifikasi tersebut TIDAK BOLEH diiklankan atau diekspos kepada developer.

Implementasi perangkat DAPAT menambahkan API kustom, tetapi API tersebut TIDAK BOLEH berada dalam namespace yang dimiliki oleh atau merujuk ke organisasi lain. Misalnya, pengimplementasi 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. 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 secara eksplisit menggunakannya (melalui mekanisme <uses-library>) yang terpengaruh oleh peningkatan penggunaan memori API tersebut.

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

Perhatikan, pembatasan 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) penuh dan spesifikasi dan semantik bytecode Dalvik. Pengimplementasikan perangkat HARUS menggunakan ART, implementasi upstream referensi dari Format Dalvik Executable, dan sistem pengelolaan paket untuk implementasi referensi.

Implementasi perangkat HARUS mengonfigurasi waktu proses Dalvik untuk mengalokasikan memori sesuai dengan platform Android upstream, dan seperti yang ditetapkan oleh tabel berikut. (Lihat bagian 7.1.1 untuk definisi ukuran layar dan kepadatan layar.) Perhatikan bahwa nilai memori yang ditetapkan di bawah ini dianggap sebagai nilai minimum dan implementasi perangkat DAPAT mengalokasikan lebih banyak memori per aplikasi.

Tata Letak Layar	Kepadatan Layar	Memori Aplikasi Minimum
Smartwatch Android	120 dpi (ldpi)	32MB
	160 dpi (mdpi)
	213 dpi (tvdpi)
	240 dpi (hdpi)	36MB
	280 dpi (280dpi)	36MB
	320 dpi (xhdpi)	48MB
	360 dpi (360dpi)	48MB
	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)	32MB
	213 dpi (tvdpi)	48MB
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (xhdpi)	80MB
	360 dpi (360dpi)	80MB
	400 dpi (400dpi)	96MB
	420 dpi (420dpi)	112MB
	480 dpi (xxhdpi)	128MB
	560 dpi (560dpi)	192MB
	640 dpi (xxxhdpi)	256MB
large	120 dpi (ldpi)	32MB
	160 dpi (mdpi)	48MB
	213 dpi (tvdpi)	80MB
	240 dpi (hdpi)	80MB
	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)	96MB
	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 yang menggantikan peluncur perangkat (layar utama). Implementasi perangkat yang memungkinkan aplikasi pihak ketiga menggantikan layar utama perangkat HARUS mendeklarasikan fitur platform android.software.home_screen.

3.8.2 Widget

Widget bersifat opsional untuk semua implementasi perangkat Android, tetapi HARUS didukung di perangkat Genggam Android.

Android menentukan jenis komponen serta API dan siklus proses yang sesuai yang memungkinkan aplikasi menampilkan “AppWidget” kepada pengguna akhir, fitur yang SANGAT DIREKOMENDASIKAN 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 AppWidgets dan menampilkan kemampuan antarmuka pengguna untuk menambahkan, mengonfigurasi, melihat, dan menghapus AppWidgets secara langsung dalam Peluncur.
Implementasi perangkat HARUS mampu merender widget yang berukuran 4 x 4 dalam ukuran petak standar. Lihat Panduan Desain Widget Aplikasi dalam dokumentasi Android SDK untuk mengetahui detailnya.
Penerapan 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 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 terkait HARUS diimplementasikan sebagai tanpa pengoperasian. Perilaku ini dijelaskan lebih lanjut di bagian 7.

Selain itu, implementasi HARUS merender dengan benar semua resource (ikon, file animasi, dll.) yang disediakan dalam API, atau di panduan gaya ikon Status/System Bar, yang pada perangkat Android Television mencakup kemungkinan untuk tidak menampilkan notifikasi. Pengimplementasi perangkat DAPAT memberikan pengalaman pengguna alternatif untuk notifikasi selain yang disediakan oleh penerapan Open Source Android referensi; akan tetapi, sistem notifikasi alternatif tersebut HARUS mendukung resource notifikasi yang ada, seperti di atas.

Implementasi Android Automotive DAPAT mengelola visibilitas dan pengaturan waktu notifikasi untuk mengurangi gangguan bagi pengemudi, tetapi HARUS menampilkan notifikasi yang menggunakan CarExtender saat diminta oleh aplikasi.

Android menyertakan dukungan untuk berbagai notifikasi, seperti:

Notifikasi lengkap . Tampilan Interaktif untuk notifikasi berkelanjutan.
Notifikasi pendahuluan . Pengguna Tampilan Interaktif dapat menindaklanjuti atau menutupnya tanpa keluar dari aplikasi saat ini.
Notifikasi layar kunci . Notifikasi yang ditampilkan di atas layar kunci dengan kontrol visibilitas yang terperinci.

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

Android menyertakan Notification Listener Service API yang memungkinkan aplikasi (setelah diaktifkan secara eksplisit oleh pengguna) untuk menerima salinan semua notifikasi saat diposting atau diupdate. Penerapan perangkat HARUS dengan benar dan segera mengirimkan notifikasi secara keseluruhan ke semua layanan pemroses yang diinstal dan diaktifkan pengguna, termasuk setiap dan semua metadata yang dilampirkan ke objek Notifikasi.

Penerapan perangkat yang mendukung fitur DND (Jangan Ganggu) HARUS memenuhi persyaratan berikut:

HARUS menerapkan aktivitas yang akan merespons intent ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS, yang HARUS berupa aktivitas yang memungkinkan pengguna memberikan atau menolak akses aplikasi ke konfigurasi kebijakan DND untuk implementasi dengan UI_MODE_TYPE_NORMAL.
HARUS, karena jika penerapan perangkat telah menyediakan cara bagi pengguna untuk memberikan atau menolak aplikasi pihak ketiga mengakses konfigurasi kebijakan DND, tampilkan Aturan DND otomatis yang dibuat oleh aplikasi bersama dengan aturan yang dibuat pengguna dan yang telah ditentukan sebelumnya.
HARUS mengikuti nilai suppressedVisualEffects yang diteruskan di NotificationManager.Policy, dan jika aplikasi telah menyetel salah satu tanda SUPPRESSED_Effect_SCREEN_OFF atau SUPPRESSED_Effect_SCREEN_ON, aplikasi SEHARUSNYA menunjukkan kepada pengguna bahwa efek visual disembunyikan di menu setelan DND.

3.8.4. Telusuri

Android menyertakan API yang memungkinkan developer menggabungkan penelusuran ke dalam aplikasi mereka dan mengekspos data aplikasi mereka ke dalam penelusuran sistem global. Secara umum, fungsi ini terdiri atas satu antarmuka pengguna untuk 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 di dalam aplikasi mereka sendiri dan memungkinkan developer memberikan hasil ke antarmuka pengguna penelusuran global umum.

Implementasi perangkat Android SEHARUSNYA menyertakan penelusuran global, satu antarmuka pengguna penelusuran bersama, yang dapat digunakan di seluruh sistem untuk memberikan saran real-time sebagai respons terhadap input pengguna. Implementasi perangkat HARUS menerapkan API yang memungkinkan developer menggunakan kembali antarmuka pengguna ini untuk menyediakan penelusuran di 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 aplikasi dijalankan dalam mode penelusuran global. Jika tidak ada aplikasi pihak ketiga terinstal yang menggunakan fungsi ini, perilaku default SEHARUSNYA menampilkan saran dan hasil mesin telusur web.

Implementasi perangkat Android HARUS, dan implementasi Android Automotive HARUS, menerapkan asisten di perangkat untuk menangani tindakan Bantuan.

Android juga menyertakan Assist API untuk memungkinkan aplikasi memilih berapa banyak informasi dari konteks saat ini yang dibagikan kepada asisten di perangkat. Implementasi perangkat yang mendukung tindakan Assist HARUS menunjukkan dengan jelas kepada pengguna akhir jika konteks dibagikan dengan menampilkan lampu putih di sekitar tepi layar. Untuk memastikan visibilitas yang jelas kepada pengguna akhir, indikasi HARUS memenuhi atau melebihi durasi dan kecerahan implementasi Project Open Source Android.

3.8.5. Toast

Aplikasi dapat menggunakan API “Toast” untuk menampilkan string non-modal pendek kepada pengguna akhir yang menghilang setelah beberapa saat. Implementasi perangkat HARUS menampilkan Toast dari aplikasi kepada pengguna akhir dengan cara yang memiliki visibilitas tinggi.

3.8.6. Tema

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

Android menyertakan kelompok tema “Holo” sebagai sekumpulan gaya yang ditentukan untuk digunakan developer aplikasi jika ingin mencocokkan tampilan dan nuansa tema Holo seperti yang ditentukan oleh Android SDK. Implementasi perangkat TIDAK BOLEH mengubah atribut tema Hollo apa pun yang diekspos ke aplikasi.

Android menyertakan kelompok tema “Material” sebagai serangkaian gaya yang ditentukan untuk digunakan developer aplikasi jika ingin menyesuaikan tampilan dan nuansa tema desain di berbagai jenis perangkat Android. Penerapan perangkat HARUS mendukung jenis tema “Material” dan TIDAK BOLEH mengubah atribut tema Material atau asetnya yang diekspos ke aplikasi.

Android juga menyertakan kelompok tema “Default Perangkat” sebagai serangkaian gaya yang ditentukan untuk digunakan oleh developer aplikasi jika ingin menyesuaikan tampilan dan nuansa tema perangkat seperti yang ditetapkan oleh pengimplementasikan perangkat. Implementasi perangkat DAPAT mengubah Atribut tema default Perangkat yang diekspos ke aplikasi.

Android mendukung tema varian dengan kolom sistem transparan, yang memungkinkan developer aplikasi mengisi area di belakang status dan menu navigasi dengan konten aplikasi mereka. Untuk memungkinkan pengalaman developer yang konsisten dalam konfigurasi ini, gaya ikon status bar harus dipertahankan di berbagai implementasi perangkat. 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 tersebut menunjukkan status bermasalah atau aplikasi meminta status bar lampu menggunakan tanda SYSTEM_UI_FLAG_LIGHT_STATUS_BAR. Saat aplikasi meminta status bar lampu, implementasi perangkat Android HARUS mengubah warna ikon status sistem menjadi hitam (untuk detailnya, lihat R.style ).

3.8.7. Wallpaper Animasi

Android menentukan jenis komponen serta API dan siklus proses yang sesuai yang memungkinkan aplikasi menampilkan satu atau beberapa “Wallpaper Animasi” kepada pengguna akhir. Wallpaper animasi 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 fungsinya, pada kecepatan frame yang wajar tanpa efek buruk pada aplikasi lain. Jika batasan hardware menyebabkan wallpaper dan/atau aplikasi error, tidak berfungsi, mengonsumsi CPU atau daya baterai yang berlebihan, atau berjalan pada kecepatan frame yang sangat rendah, hardware dianggap tidak dapat menjalankan wallpaper animasi. Sebagai contoh, beberapa wallpaper animasi mungkin menggunakan konteks OpenGL 2.0 atau 3.x untuk merender kontennya. Wallpaper animasi tidak akan berjalan dengan andal pada hardware yang tidak mendukung beberapa konteks OpenGL karena penggunaan wallpaper animasi dari konteks OpenGL mungkin bertentangan dengan aplikasi lain yang juga menggunakan konteks OpenGL.

Implementasi perangkat yang mampu menjalankan wallpaper animasi secara andal seperti yang dijelaskan di atas HARUS menerapkan wallpaper animasi, dan jika diterapkan HARUS melaporkan tanda fitur platform android.software.live_wallpaper.

3.8.8. Pengalihan Aktivitas

Karena tombol navigasi fungsi Terbaru adalah OPSIONAL, persyaratan untuk menerapkan layar ringkasan adalah OPSIONAL untuk implementasi Android Watch dan Android Automotive, dan DIREKOMENDASIKAN untuk perangkat Android Television. HARUS tetap ada metode untuk beralih antar-aktivitas pada implementasi Android Automotive.

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

HARUS mendukung setidaknya hingga 6 aktivitas yang ditampilkan.
Setidaknya HARUS menampilkan judul 4 aktivitas sekaligus.
HARUS menerapkan perilaku penyematan ke layar dan berikan menu setelan kepada pengguna untuk mengaktifkan/menonaktifkan fitur.
HARUS menampilkan warna sorotan, ikon, judul layar dalam terbaru.
SEHARUSNYA menampilkan kemampuan penutup ("x") tetapi MUNGKIN menundanya hingga pengguna berinteraksi dengan layar.
HARUS terapkan pintasan untuk beralih dengan mudah ke aktivitas sebelumnya
DAPAT menampilkan konten terbaru yang berafiliasi sebagai kelompok yang bergerak bersama.
HARUS memicu tindakan beralih cepat antara dua aplikasi yang terakhir digunakan, saat tombol fungsi terbaru diketuk dua kali.
HARUS memicu mode multi-aplikasi layar terpisah, jika didukung, saat tombol fungsi terbaru ditekan lama.

Implementasi perangkat SANGAT DIREKOMENDASIKAN untuk menggunakan antarmuka pengguna Android upstream (atau antarmuka berbasis thumbnail yang serupa) bagi layar ringkasan.

3.8.9. Pengelolaan Input

Android menyertakan dukungan untuk Pengelolaan Input dan dukungan untuk editor metode input pihak ketiga. Implementasi perangkat yang memungkinkan pengguna menggunakan metode input pihak ketiga pada perangkat HARUS mendeklarasikan fitur platform android.software.input_Method dan mendukung IME API seperti yang ditetapkan dalam dokumentasi Android SDK.

Implementasi perangkat yang mendeklarasikan fitur android.software.input_method 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 di Android 5.0 dan digantikan oleh Media Notification Template yang memungkinkan aplikasi media berintegrasi dengan kontrol pemutaran yang ditampilkan di layar kunci. Implementasi perangkat yang mendukung layar kunci, kecuali jika implementasi Android Automotive atau Watch, HARUS menampilkan Notifikasi layar kunci termasuk Template Notifikasi Media.

3.8.11. Screensaver (sebelumnya Dreams)

Android menyertakan dukungan untuk screensaver interaktif, yang sebelumnya disebut sebagai Dreams. Screensaver memungkinkan pengguna berinteraksi dengan aplikasi saat perangkat yang terhubung ke sumber daya tidak ada aktivitas atau dipasang ke dok di dok meja. Perangkat Android Watch MUNGKIN mengimplementasikan screensaver, tetapi jenis implementasi perangkat lainnya HARUS menyertakan dukungan untuk screensaver dan menyediakan opsi setelan bagi pengguna untuk mengonfigurasi screensaver 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.

3.8.13. Unicode dan Font

Android menyertakan dukungan untuk karakter emoji yang ditentukan di Unicode 9.0. Semua implementasi perangkat HARUS mampu merender karakter emoji ini dalam glyph warna dan jika implementasi perangkat Android menyertakan IME, implementasi tersebut HARUS menyediakan metode input kepada pengguna untuk karakter emoji ini.

Perangkat genggam Android HARUS mendukung warna kulit dan beragam emoji keluarga seperti yang ditentukan dalam Laporan Teknis Unicode #51.

Android menyertakan dukungan untuk font Roboto 2 dengan bobot yang berbeda—sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-kondensasi-light—yang semuanya HARUS disertakan untuk bahasa yang tersedia pada perangkat dan cakupan penuh Unicode 7.0 dari simbol-simbol Latin, Yunani, dan Cyrillic, termasuk blok Cyrillic dan Cyrillic yang diperluas, termasuk huruf Cyrillic dan Latin Extended.

3.8.14. Multi-aplikasi

Implementasi perangkat DAPAT memilih untuk tidak menerapkan mode multi-aplikasi apa pun, tetapi jika memiliki kemampuan untuk menampilkan beberapa aktivitas sekaligus, aplikasi HARUS mengimplementasikan mode multi-aplikasi tersebut sesuai dengan perilaku aplikasi dan API yang dijelaskan dalam dokumentasi dukungan mode multi-aplikasi Android SDK dan memenuhi persyaratan berikut:

Aplikasi dapat menunjukkan apakah aplikasi dapat beroperasi dalam mode multi-aplikasi di file AndroidManifest.xml, baik secara eksplisit melalui atribut android:resizeableActivity maupun secara implisit dengan memiliki targetSdkVersion > 24. Aplikasi yang secara eksplisit menetapkan atribut ini ke false dalam manifesnya HARUS tidak diluncurkan dalam mode multi-aplikasi. Aplikasi yang tidak menetapkan atribut dalam file manifesnya (targetSdkVersion < 24) dapat diluncurkan dalam mode multi-aplikasi, tetapi sistem HARUS memberikan peringatan bahwa aplikasi mungkin tidak berfungsi seperti yang diharapkan dalam mode multi-aplikasi.
Implementasi perangkat TIDAK BOLEH menawarkan mode layar terpisah atau mode bentuk bebas jika tinggi dan lebar layar kurang dari 440 dp.
Penerapan perangkat dengan ukuran layar xlarge SEHARUSNYA mendukung mode bentuk bebas.
Implementasi perangkat Android Television HARUS mendukung multi-aplikasi mode picture-in-picture (PIP) dan menempatkan multi-aplikasi PIP di pojok kanan atas saat PIP AKTIF.
Implementasi perangkat dengan dukungan multi-aplikasi mode PIP HARUS mengalokasikan minimal 240x135 dp untuk jendela PIP.
Jika mode multi-aplikasi PIP didukung, tombol KeyEvent.KEYCODE_WINDOW HARUS digunakan untuk mengontrol jendela PIP; jika tidak, kunci HARUS tersedia untuk aktivitas latar depan.

3,9. Administrasi Perangkat

Android menyertakan fitur yang memungkinkan aplikasi sadar keamanan untuk menjalankan fungsi administrasi perangkat pada tingkat sistem, seperti menerapkan kebijakan sandi atau melakukan penghapusan total dari jarak jauh, melalui Android Device Administration API. Penerapan perangkat HARUS menyediakan implementasi class DeviceDependencies. Implementasi perangkat yang mendukung layar kunci aman HARUS menerapkan berbagai kebijakan administrasi perangkat yang ditentukan dalam dokumentasi Android SDK 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, implementasi tersebut HARUS mengimplementasikan penyediaan aplikasi Pemilik Perangkat dari aplikasi Klien Kebijakan Perangkat (DPC) seperti yang ditunjukkan di bawah ini:

Jika implementasi perangkat belum memiliki data pengguna yang dikonfigurasi, implementasi tersebut:
- HARUS melaporkan true untuk DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
- HARUS mendaftarkan aplikasi DPC sebagai aplikasi Pemilik Perangkat sebagai respons terhadap tindakan intent android.app.action.PROVISION_MANAGED_DEVICE.
- HARUS mendaftarkan aplikasi DPC sebagai aplikasi Pemilik Perangkat jika perangkat mendeklarasikan dukungan Komunikasi Nirkabel Jarak Dekat (NFC) melalui tombol fitur android.hardware.nfc dan menerima pesan NFC yang berisi data dengan jenis MIME MIME_TYPE_PROVISIONING_NFC.
Jika implementasi perangkat memiliki data pengguna, implementasi tersebut:
- HARUS melaporkan false untuk DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
- HARUS tidak mendaftarkan aplikasi DPC lagi sebagai Aplikasi Pemilik Perangkat.

Implementasi perangkat MUNGKIN memiliki aplikasi bawaan yang menjalankan fungsi administrasi perangkat, tetapi aplikasi ini TIDAK BOLEH disetel sebagai aplikasi Pemilik Perangkat tanpa persetujuan atau tindakan eksplisit dari pengguna atau administrator perangkat.

3.9.1.2 Penyediaan profil terkelola

Jika implementasi perangkat mendeklarasikan android.software.managed_users, aplikasi Pengontrol Kebijakan Perangkat (DPC) harus didaftarkan sebagai pemilik Profil Terkelola baru.

Proses penyediaan profil terkelola (alur yang dimulai oleh android.app.action.PROVISION_MANAGED_PROFILE ) pengalaman pengguna HARUS selaras dengan implementasi AOSP.

Implementasi perangkat HARUS menyediakan kemampuan pengguna berikut dalam antarmuka pengguna Setelan untuk menunjukkan kepada pengguna saat fungsi sistem tertentu telah dinonaktifkan oleh Pengontrol Kebijakan Perangkat (DPC):

Ikon yang konsisten atau kemampuan pengguna lainnya (misalnya ikon info AOSP upstream) untuk mewakili saat setelan tertentu dibatasi oleh Device Admin.
Pesan penjelasan singkat, sebagaimana diberikan oleh Admin Perangkat melalui setShortSupportMessage.
Ikon aplikasi DPC.

3.9.2 Dukungan Profil Terkelola

Perangkat yang mendukung 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 mendukung profil terkelola HARUS:

Deklarasikan tombol fitur platform android.software.managed_users .
Mendukung profil terkelola melalui android.app.admin.DevicePolicyManager API.
Izinkan pembuatan satu dan hanya satu profil terkelola.
Gunakan badge ikon (mirip dengan badge kerja upstream AOSP) untuk mewakili aplikasi dan widget terkelola serta elemen UI dengan badge lainnya seperti Terbaru & Notifikasi.
Tampilkan ikon notifikasi (mirip dengan badge kerja upstream AOSP) untuk menunjukkan kapan 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 ada profil terkelola, tampilkan kemampuan visual di Intent 'Chooser' untuk memungkinkan pengguna meneruskan intent dari profil terkelola ke pengguna utama atau sebaliknya, jika diaktifkan oleh Pengontrol Kebijakan Perangkat.
Jika ada profil terkelola, tampilkan kemampuan pengguna berikut untuk pengguna utama dan profil terkelola:
- Pencatatan terpisah untuk baterai, lokasi, data seluler, dan penggunaan penyimpanan untuk pengguna utama dan profil terkelola.
- Pengelolaan independen atas Aplikasi VPN yang diinstal dalam pengguna utama atau profil terkelola.
- Pengelolaan independen atas aplikasi yang diinstal dalam pengguna utama atau profil terkelola.
- Pengelolaan akun secara independen dalam pengguna utama atau profil terkelola.
Pastikan aplikasi telepon, kontak, dan pesan bawaan dapat menelusuri dan mencari informasi penelepon dari profil terkelola (jika ada) bersama dengan yang ada di profil utama, jika Pengontrol Kebijakan Perangkat mengizinkannya. Jika kontak dari profil terkelola ditampilkan di log panggilan bawaan, UI dalam panggilan, notifikasi panggilan yang sedang berlangsung dan panggilan yang terlewat, aplikasi kontak dan pesan, kontak tersebut SEHARUSNYA diberi badge dengan badge yang sama dengan yang digunakan untuk menunjukkan aplikasi profil terkelola.
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.
Mendukung kemampuan untuk menentukan layar kunci terpisah yang memenuhi persyaratan berikut untuk memberikan akses ke aplikasi yang berjalan di profil terkelola.
- Penerapan perangkat HARUS mematuhi intent DevicePolicyManager.ACTION_SET_NEW_PASSWORD dan menampilkan antarmuka untuk mengonfigurasi kredensial layar kunci yang terpisah untuk profil terkelola.
- Kredensial layar kunci profil terkelola HARUS menggunakan mekanisme penyimpanan dan pengelolaan kredensial yang sama dengan profil induk, seperti yang didokumentasikan di Situs Project Open Source Android
- Kebijakan sandi DPC HARUS berlaku hanya untuk kredensial layar kunci profil terkelola, kecuali jika dipanggil pada instance DevicePolicyManager yang ditampilkan oleh getParentProfileInstance.

3.10. Aksesibilitas

Android menyediakan lapisan aksesibilitas yang membantu pengguna difabel untuk membuka perangkat dengan lebih mudah. Selain itu, Android menyediakan API platform yang memungkinkan penerapan layanan aksesibilitas menerima callback untuk peristiwa pengguna dan sistem serta menghasilkan mekanisme masukan alternatif, seperti text-to-speech, respons haptik, dan navigasi trackball/d-pad.

Implementasi perangkat mencakup persyaratan berikut:

Implementasi Android Automotive HARUS menyediakan implementasi framework aksesibilitas Android yang konsisten dengan implementasi Android default.
Implementasi perangkat (tidak termasuk Android Automotive) HARUS menyediakan implementasi framework aksesibilitas Android yang konsisten dengan implementasi Android default.
Implementasi perangkat (tidak termasuk Android Automotive) HARUS mendukung implementasi layanan aksesibilitas pihak ketiga melalui API android.accessibilityservice.
Implementasi perangkat (tidak termasuk Android Automotive) HARUS membuat 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 pengecualian 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.
Implementasi perangkat Android dengan output audio SANGAT DIREKOMENDASIKAN untuk menyediakan implementasi layanan aksesibilitas pada perangkat yang sebanding dengan atau melebihi fungsi TalkBack** dan layanan aksesibilitas Tombol Akses (https://github.com/google/talkback).
Perangkat Android Watch dengan output audio SEHARUSNYA menyediakan implementasi layanan aksesibilitas pada perangkat yang sebanding dengan atau melebihi fungsi layanan aksesibilitas TalkBack (https://github.com/google/talkback).
Implementasi perangkat HARUS menyediakan mekanisme dalam alur penyiapan siap pakai bagi pengguna untuk mengaktifkan layanan aksesibilitas yang relevan, serta opsi untuk menyesuaikan ukuran font, ukuran layar, dan gestur pembesaran.

** Untuk bahasa yang didukung oleh Text-to-speech.

Selain itu, perhatikan bahwa jika ada layanan aksesibilitas bawaan, layanan tersebut HARUS berupa aplikasi {directBootAware} yang mendukung Direct Boot jika perangkat memiliki penyimpanan terenkripsi menggunakan Enkripsi Berbasis File (FBE).

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. Implementasi perangkat yang melaporkan fitur android.hardware.audio.output HARUS memenuhi persyaratan terkait framework Android TTS.

Implementasi Android Automotive:

HARUS mendukung API framework TTS Android.
Mungkin 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 Android upstream menyertakan implementasi mesin TTS berfitur 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.

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

3.12.1. Aplikasi TV

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

Aplikasi TV HARUS menyediakan fasilitas untuk menginstal dan menggunakan Saluran TV dan memenuhi persyaratan berikut:

Implementasi perangkat HARUS mengizinkan input berbasis TIF pihak ketiga ( input pihak ketiga) untuk diinstal dan dikelola.
Implementasi perangkat DAPAT memberikan pemisahan visual antara input berbasis TIF (input yang diinstal) dan input pihak ketiga yang sudah diinstal sebelumnya.
Penerapan perangkat TIDAK BOLEH menampilkan input pihak ketiga lebih dari satu tindakan navigasi dari Aplikasi TV (yaitu meluaskan daftar input pihak ketiga dari Aplikasi TV).

3.12.1.1 Panduan Program Elektronik

Implementasi perangkat Android Television HARUS menampilkan overlay informasi dan interaktif, yang HARUS menyertakan panduan program elektronik (EPG) yang dihasilkan dari nilai dalam kolom TvContract.Programs. EPG HARUS memenuhi persyaratan berikut:

EPG HARUS menampilkan informasi dari semua input yang diinstal dan input pihak ketiga.
EPG MUNGKIN memberikan pemisahan visual antara input yang diinstal dan input pihak ketiga.
EPG SANGAT DIREKOMENDASIKAN 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 perubahan saluran, implementasi perangkat HARUS menampilkan data EPG untuk program yang sedang diputar.

3.12.1.2. Navigasi

Aplikasi TV HARUS mengizinkan navigasi untuk fungsi berikut melalui tombol D-pad, Back, dan Home pada perangkat input perangkat Android Television (yaitu remote control, aplikasi remote control, atau pengontrol game):

Mengubah saluran TV
Membuka EPG
Mengonfigurasi dan melakukan penyesuaian ke input berbasis TIF pihak ketiga
Membuka menu Setelan

Aplikasi TV HARUS meneruskan peristiwa tombol 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). Aplikasi TV HARUS menampilkan penautan aplikasi input TV jika disediakan.

3.12.1.4. Pergeseran waktu

Implementasi perangkat Android Television HARUS mendukung pergeseran waktu, yang memungkinkan pengguna menjeda dan melanjutkan konten live. Implementasi perangkat HARUS memberi pengguna cara untuk menjeda dan melanjutkan program yang sedang diputar, jika pergeseran waktu untuk program tersebut tersedia.

3.12.1.5. Perekaman TV

Implementasi perangkat Android Television SANGAT DIREKOMENDASIKAN untuk mendukung perekaman TV. Jika input TV mendukung perekaman, EPG MUNGKIN menyediakan cara untuk merekam program jika perekaman program tersebut tidak dilarang. Implementasi perangkat HARUS menyediakan antarmuka pengguna untuk memutar program yang direkam.

3.13. Setelan Cepat

Implementasi perangkat Android HARUS menyertakan komponen UI Setelan Cepat yang memungkinkan akses cepat ke tindakan yang sering digunakan atau sangat dibutuhkan.

Android menyertakan quicksettings API yang memungkinkan aplikasi pihak ketiga menerapkan kartu yang dapat ditambahkan oleh pengguna bersama kartu yang disediakan sistem di komponen UI Setelan Cepat. Jika implementasi perangkat memiliki komponen UI Setelan Cepat, implementasi tersebut:

HARUS mengizinkan pengguna menambahkan atau menghapus kartu dari aplikasi pihak ketiga ke Setelan Cepat.
TIDAK BOLEH menambahkan kartu secara otomatis dari aplikasi pihak ketiga langsung ke Setelan Cepat.
HARUS menampilkan semua kartu yang ditambahkan pengguna dari aplikasi pihak ketiga bersama kartu setelan cepat yang disediakan sistem.

3.14. API UI Kendaraan

3.14.1. UI Media Kendaraan

Setiap implementasi perangkat yang mendeklarasikan dukungan otomotif HARUS menyertakan framework UI untuk mendukung aplikasi pihak ketiga yang menggunakan MediaBrowser dan MediaSession API.

Framework UI yang mendukung aplikasi pihak ketiga yang bergantung pada MediaBrowser dan MediaSession memiliki persyaratan visual berikut:

HARUS menampilkan ikon MediaItem dan ikon notifikasi tanpa diubah.
HARUS menampilkan item tersebut seperti yang dijelaskan oleh MediaSession, misalnya, metadata, ikon, gambar.
HARUS menampilkan judul aplikasi.
HARUS memiliki panel samping untuk menampilkan hierarki MediaBrowser.

4. Kompatibilitas Pengemasan Aplikasi

Penerapan perangkat HARUS menginstal dan menjalankan file “.apk” Android seperti yang dihasilkan oleh alat “aapt” yang disertakan dalam Android SDK resmi. Karena alasan ini, implementasi perangkat HARUS menggunakan sistem pengelolaan paket penerapan referensi.

Pengelola paket HARUS mendukung verifikasi file “.apk” menggunakan APK Signature Scheme v2 dan penandatanganan JAR.

Implementasi perangkat TIDAK BOLEH memperluas format .apk, Manifes Android, Byte Dalvik, atau bytecode RenderScript sedemikian rupa sehingga akan mencegah file tersebut diinstal dan berjalan dengan benar pada perangkat lain yang kompatibel.

5. Kompatibilitas Multimedia

5.1. Codec Media

Implementasi perangkat—

HARUS mendukung format media inti yang ditentukan dalam dokumentasi Android SDK, kecuali jika diizinkan secara eksplisit dalam dokumen ini.
HARUS mendukung format media, encoder, decoder, jenis file, dan format container yang ditentukan dalam tabel di bawah ini dan dilaporkan melalui MediaCodecList.
HARUS juga dapat mendekode semua profil yang dilaporkan di CamcorderProfile
HARUS dapat mendekode semua format yang dapat dienkodenya. Ini mencakup semua bitstream yang dihasilkan encodernya.

Codec HARUS menargetkan latensi codec minimum, dengan kata lain, codec—

TIDAK BOLEH menggunakan dan menyimpan buffer input dan menampilkan buffer input hanya setelah diproses
TIDAK BOLEH menyimpan buffer hasil dekode lebih lama dari yang ditentukan oleh standar (misalnya SPS).
TIDAK BOLEH berpegang pada buffer yang dienkode, lebih lama dari yang dibutuhkan oleh struktur GOP.

Semua codec yang tercantum dalam tabel di bawah disediakan sebagai implementasi software dalam implementasi Android yang disukai dari Project Open Source Android.

Harap diperhatikan bahwa baik Google maupun Open Handset Alliance tidak membuat pernyataan apa pun bahwa codec ini bebas dari paten pihak ketiga. Mereka yang berniat menggunakan kode sumber ini dalam produk perangkat keras atau perangkat lunak disarankan bahwa penerapan kode ini, termasuk dalam perangkat lunak sumber terbuka atau perangkat bersama, 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)	WAJIB ¹	WAJIB	Dukungan untuk konten mono/stereo/5.0/5.1 ² dengan frekuensi pengambilan sampel standar dari 8 hingga 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS AAC mentah (.aac, dekode di Android 3.1+, mengenkode di Android 4.0+, ADIF tidak didukung) MPEG-TS (.ts, tidak dapat dicari, Android 3.0+)
Profil MPEG-4 HE AAC (AAC+)	WAJIB ¹ (Android 4.1+)	WAJIB	Dukungan untuk konten mono/stereo/5.0/5.1 ² dengan frekuensi pengambilan sampel standar dari 16 hingga 48 kHz.
MPEG-4 HE AACv2 Profil (AAC+ yang ditingkatkan)		WAJIB	Dukungan untuk konten mono/stereo/5.0/5.1 ² dengan frekuensi pengambilan sampel standar dari 16 hingga 48 kHz.
AAC ELD (AAC yang ditingkatkan dengan delay rendah)	WAJIB ¹ (Android 4.1+)	WAJIB (Android 4.1+)	Dukungan untuk konten mono/stereo dengan frekuensi pengambilan sampel standar dari 16 hingga 48 kHz.
AMR-NB	WAJIB ³	WAJIB ³	4,75 hingga 12,2 kbps dengan sampel @ 8 kHz	3GPP (.3gp)
AMR-WB	WAJIB ³	WAJIB ³	9 kecepatan dari 6,60 kbit/dtk hingga 23,85 kbit/dtk dengan sampel @ 16 kHz
FLAC		WAJIB (Android 3.1+)	Mono/Stereo (tanpa multisaluran). Frekuensi sampel hingga 48 kHz (tetapi hingga 44,1 kHz DIREKOMENDASIKAN pada perangkat dengan output 44,1 kHz, karena downsampler 48 hingga 44,1 kHz tidak menyertakan filter low-pass). 16-bit DIREKOMENDASIKAN; tidak ada dither yang diterapkan untuk 24-bit.	Khusus FLAC (.flac)
MP3		WAJIB	Konstan Mono/Stereo 8-320 Kbps (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	Ketik 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	WAJIB ⁴ (Android 4.1+)	WAJIB	PCM linear 16-bit (kecepatan hingga batas hardware). Perangkat HARUS mendukung frekuensi pengambilan sampel untuk perekaman PCM mentah pada frekuensi 8000, 11025, 16000, dan 44100 Hz.	WAVE (.wav)
Opus		WAJIB (Android 5.0 dan yang lebih baru)		Matroska (.mkv), Ogg(.ogg)

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

2 Perekaman atau pemutaran MUNGKIN dilakukan dalam mono atau stereo, tetapi decoding buffer input AAC pada streaming multichannel (yaitu lebih dari dua channel) ke PCM melalui decoder audio AAC default di android.media.MediaCodec API, berikut ini HARUS didukung:

decoding dilakukan tanpa downmixing (misalnya streaming 5.0 AAC harus diterjemahkan ke lima saluran PCM, aliran 5.1 AAC harus diterjemahkan ke enam saluran PCM),
metadata rentang dinamis, seperti yang ditentukan dalam "Kontrol Rentang Dinamis (DRC)" di ISO/IEC 14496-3, dan tombol DRC android.media.MediaFormat untuk mengonfigurasi perilaku dekoder audio terkait rentang dinamis. Kunci DRC AAC diperkenalkan di API 21,dan meliputi: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL dan KEY_AAC_ENCODED_TARGET_LEVEL

3 Diperlukan untuk implementasi Perangkat Genggam Android.

4 Diperlukan untuk implementasi perangkat yang menentukan android.hardware.Mikrofon, 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)
Raw		WAJIB		ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)

5.1.3 Codec Video

Codec yang mengiklankan dukungan profil HDR HARUS mendukung penguraian dan penanganan metadata statis HDR.
Jika codec media mengiklankan dukungan refresh intra, maka codec HARUS mendukung periode refresh dalam rentang 10 - 60 frame dan beroperasi secara akurat dalam 20% periode refresh yang dikonfigurasi.
Codec video HARUS mendukung ukuran bytebuffer output dan input yang mengakomodasi frame yang dikompresi dan tidak dikompresi secara terbesar sebagaimana ditentukan oleh standar dan konfigurasi, tetapi juga tidak dialokasikan secara berlebihan.
Encoder dan decoder video HARUS mendukung format warna fleksibel YUV420 (Color_FormatYUV420Fleksibel).

Format/Codec	Encoder	Decoder	Detail	Jenis File yang Didukung/ Format Penampung
H.263	MEI	MEI		3GPP (.3gp) MPEG-4 (.mp4)
AVC H.264	WAJIB ²	WAJIB ²	Lihat bagian 5.2 dan 5.3 untuk mengetahui detailnya	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, hanya audio AAC, tidak dapat dicari, Android 3.0+)
H.265 HEVC		WAJIB ⁵	Lihat bagian 5.3 untuk mengetahui detailnya	MPEG-4 (.mp4)
MPEG-2		REKOMENDASI YANG BAGUS ⁶	Profil Utama	MPEG2-TS
MPEG-4 SP		WAJIB ²		3GPP (.3gp)
VP8 ³	WAJIB ² (Android 4.3+)	WAJIB ² (Android 2.3.3+)	Lihat bagian 5.2 dan 5.3 untuk mengetahui detailnya	WebM (.webm) Matroska (.mkv, Android 4.0+) ⁴
VP9		WAJIB ² (Android 4.4+)	Lihat bagian 5.3 untuk mengetahui detailnya	WebM (.webm) Matroska (.mkv, Android 4.0+) ⁴

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

2 Diperlukan untuk implementasi perangkat kecuali perangkat Android Watch.

3 Untuk layanan streaming video web dan konferensi video dengan kualitas yang dapat diterima, implementasi perangkat HARUS menggunakan codec VP8 hardware yang memenuhi persyaratan.

4 Implementasi perangkat SEHARUSNYA mendukung penulisan file Matroska WebM.

5 SANGAT DIREKOMENDASIKAN 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

Codec video bersifat opsional untuk implementasi perangkat Android Watch.

Encoder video H.264, VP8, VP9 dan HEVC—

HARUS mendukung kecepatan bit yang dapat dikonfigurasi secara dinamis.
HARUS mendukung kecepatan frame variabel, di mana encoder video HARUS menentukan durasi frame instan berdasarkan stempel waktu buffer input, dan mengalokasikan bucket bit-nya berdasarkan durasi frame tersebut.

Encoder video H.263 dan MPEG-4 HARUS mendukung kecepatan bit yang dapat dikonfigurasi secara dinamis.

Semua encoder video HARUS memenuhi target kecepatan bit berikut pada dua jendela geser:

Kecepatan ini HARUS tidak lebih dari ~15% di atas kecepatan bit antara interval intraframe (I-frame).
Harus tidak lebih dari ~100% di atas kecepatan bit pada jendela geser 1 detik.

5.2.1 H.263

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

5.2.2. H-264

Implementasi perangkat Android dengan dukungan codec H.264:

HARUS mendukung Profil Dasar Pengukuran Level 3.
Namun, dukungan untuk ASO (Pemesanan Slice Arbitrer), FMO (Pengurutan Macroblock Fleksibel), dan RS (Slice Redundan) bersifat OPSIONAL. Selain itu, untuk mempertahankan kompatibilitas dengan perangkat Android lain, DIREKOMENDASIKAN bahwa ASO, FMO, dan RS tidak digunakan untuk Profil Dasar Pengukuran oleh encoder.
HARUS mendukung profil encoding video SD (Definisi Standar) di tabel berikut.
HARUS mendukung Profil Utama Level 4.
HARUS mendukung profil encoding video HD (Definisi Tinggi) seperti yang ditunjukkan dalam tabel berikut.
Selain itu, perangkat Android Television SANGAT DIREKOMENDASIKAN untuk mengenkode video HD 1080p pada 30 fps.

	SD (Kualitas rendah)	SD (Kualitas tinggi)	HD 720p ¹	HD 1080p ¹
Resolusi video	320x240 piksel	720x480 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 DIREKOMENDASIKAN untuk perangkat Android Televisi.

5.2.3. VP8

Implementasi perangkat Android dengan dukungan codec VP8 HARUS mendukung profil encoding video SD dan SEHARUSNYA mendukung profil encoding video HD (Definisi Tinggi) berikut.

	SD (Kualitas rendah)	SD (Kualitas tinggi)	HD 720p ¹	HD 1080p ¹
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 perangkat keras.

5.3. Dekode Video

Codec video bersifat opsional untuk implementasi perangkat Android Watch.

Implementasi perangkat—

HARUS mendukung resolusi video dinamis dan peralihan kecepatan frame melalui API Android standar dalam streaming yang sama untuk semua codec VP8, VP9, H.264, dan H.265 secara real time dan hingga resolusi maksimum yang didukung oleh setiap codec pada perangkat.
Implementasi yang mendukung decoder Dolby Vision—
HARUS menyediakan ekstraktor berkemampuan Dolby Vision.
HARUS menampilkan konten Dolby Vision dengan benar di layar perangkat atau di port output video standar (mis., HDMI).
Implementasi yang menyediakan pengekstrak berkemampuan Dolby Vision HARUS menyetel indeks jalur lapisan dasar yang kompatibel dengan versi lama (jika ada) agar sama dengan indeks trek lapisan Dolby Vision gabungan.

5.3.1 MPEG-2

Implementasi perangkat Android dengan decoder MPEG-2 harus mendukung Tingkat Tinggi Profil Utama.

5.3.2 H.263

Implementasi perangkat Android dengan decoder H.263 HARUS mendukung Profil Dasar Pengukuran Level 30 dan Level 45.

5.3.3. MPEG-4

Implementasi perangkat Android dengan decoder MPEG-4 HARUS mendukung Simple Profile Level 3.

5.3.4. H.264

Implementasi perangkat Android dengan decoder H.264:

HARUS mendukung Profil Utama Level 3.1 dan Profil Dasar Pengukuran.
Dukungan untuk ASO (Pemesanan Slice Arbitrer), FMO (Pengurutan Macroblock Fleksibel), dan RS (Slice Redundan) bersifat OPSIONAL.
HARUS mampu mendekode video dengan profil SD (Definisi Standar) yang tercantum dalam tabel berikut dan dienkode dengan Profil Dasar Pengukuran dan Profil Utama Level 3.1 (termasuk 720p30).
HARUS mampu mendekode video dengan profil HD (Definisi Tinggi) seperti yang ditunjukkan dalam tabel berikut.
Selain itu, perangkat Android Television—
- HARUS mendukung Profil Tinggi Level 4.2 dan profil decoding HD 1080p60.
- HARUS mampu mendekode video dengan kedua profil HD seperti yang ditunjukkan dalam tabel berikut dan dienkode dengan Profil Dasar Pengukuran, Profil Utama, atau Profil Tinggi Level 4.2

	SD (Kualitas rendah)	SD (Kualitas tinggi)	HD 720p ¹	HD 1080p ¹
Resolusi video	320x240 piksel	720x480 piksel	1280 x 720 px	1920 x 1080 px
Frekuensi gambar video	30 fps	30 fps	60 fps	30 fps (60 fps ² )
Kecepatan bit video	800 Kbps	2 Mbps	8 Mbps	20 Mbps

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

2 WAJIB untuk implementasi perangkat Android Television.

5.3.5. H.265 (HEVC)

Implementasi perangkat Android, saat mendukung codec H.265 seperti yang dijelaskan di bagian 5.1.3:

HARUS mendukung tingkat Utama Profil Utama Level 3 dan profil decoding video SD seperti yang ditunjukkan dalam tabel berikut.
HARUS mendukung profil decoding HD seperti yang ditunjukkan dalam tabel berikut.
HARUS mendukung profil decoding HD seperti yang ditunjukkan dalam tabel berikut jika terdapat dekoder hardware.
Selain itu, perangkat Android Television:
HARUS mendukung profil decoding HD 720p.
SANGAT DIREKOMENDASIKAN untuk mendukung profil decoding HD 1080p. Jika profil decoding HD 1080p didukung, profil tersebut HARUS mendukung tingkat Utama Profil Utama Level 4.1.
HARUS mendukung profil decoding UHD. Jika profil decoding UHD didukung, codec HARUS mendukung profil Tingkat Utama Main10 Level 5.

	SD (Kualitas rendah)	SD (Kualitas tinggi)	HD 720p	HD 1080p	UHD
Resolusi video	352 x 288 piksel	720x480 piksel	1280 x 720 px	1920 x 1080 px	3840x2160 piksel
Frekuensi gambar video	30 fps	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 WAJIB untuk implementasi perangkat Android Television dengan decoding hardware H.265.

5.3.6. VP8

Implementasi perangkat Android, saat mendukung codec VP8 seperti yang dijelaskan di bagian 5.1.3:

HARUS mendukung profil decoding SD dalam tabel berikut.
HARUS mendukung profil decoding HD dalam tabel berikut.
Perangkat Android TV HARUS mendukung profil decoding HD 1080p60.

	SD (Kualitas rendah)	SD (Kualitas tinggi)	HD 720p ¹	HD 1080p ¹
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 fps ² )	30 (60 fps ² )
Kecepatan bit video	800 Kbps	2 Mbps	8 Mbps	20 Mbps

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

2 WAJIB untuk implementasi perangkat Android Television.

5.3.7. VP9

Implementasi perangkat Android, saat mendukung codec VP9 seperti yang dijelaskan di bagian 5.1.3:

HARUS mendukung profil decoding video SD seperti yang ditunjukkan dalam tabel berikut.
HARUS mendukung profil decoding HD seperti yang ditunjukkan dalam tabel berikut.
HARUS mendukung profil decoding HD seperti yang ditunjukkan dalam tabel berikut, jika terdapat dekoder hardware.
Selain itu, perangkat Android Television:
- HARUS mendukung profil decoding HD 720p.
- SANGAT DIREKOMENDASIKAN untuk mendukung profil decoding HD 1080p.
- HARUS mendukung profil decoding UHD. Jika profil decoding video UHD didukung, profil ini HARUS mendukung kedalaman warna 8-bit dan SEHARUSNYA mendukung VP9 Profile 2 (10-bit).

	SD (Kualitas rendah)	SD (Kualitas tinggi)	HD 720p	HD 1080p	UHD
Resolusi video	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px	3840x2160 piksel
Frekuensi gambar video	30 fps	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 WAJIB untuk implementasi perangkat Android Television dengan decoding hardware VP9.

5.4 Perekaman Audio

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

5.4.1. Perekaman Audio Mentah

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

Format : PCM Linear, 16-bit
Frekuensi pengambilan sampel : 8000, 11025, 16000, 44100
Saluran : Mono

Pengambilan frekuensi sampel di atas HARUS dilakukan tanpa up-sampling, dan setiap down-sampling HARUS menyertakan filter anti-aliasing yang sesuai.

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

Format : PCM Linear, 16-bit
Frekuensi pengambilan sampel : 22050, 48000
Saluran : Stereo

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

5.4.2. Ambil foto untuk Pengenalan Suara

Sumber audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION HARUS mendukung pengambilan sampel di salah satu frekuensi pengambilan sampel, 44100 dan 48000.

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 rata-rata versus frekuensi: khususnya, ±3 dB, dari 100 Hz hingga 4000 Hz.
Sensitivitas input audio HARUS diatur sedemikian rupa sehingga sumber level daya suara (SPL) 90 dB pada 1000 Hz menghasilkan RMS 2500 untuk sampel 16-bit.
Tingkat amplitudo PCM HARUS melacak secara linear perubahan SPL input minimal dalam rentang 30 dB dari -18 dB hingga +12 dB re 90 dB SPL di mikrofon.
Distorsi harmonik total HARUS kurang dari 1% untuk 1 kHz pada level input SPL 90 dB di mikrofon.
Pemrosesan pengurangan bising, jika ada, HARUS dinonaktifkan.
Kontrol penguatan otomatis, 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 deskriptor efek peredam bising HARUS secara unik mengidentifikasi setiap implementasi teknologi peredam bising.

5.4.3. Ambil untuk Mengubah Rute Pemutaran

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

CINCIN_STREAMING
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 Raw

Perangkat HARUS mengizinkan pemutaran konten audio mentah dengan karakteristik berikut:

Format : PCM Linear, 16-bit
Frekuensi pengambilan sampel : 8000, 11025, 16000, 22050, 32000, 44100
Saluran : Mono, Stereo

Perangkat SEHARUSNYA mengizinkan pemutaran konten audio mentah dengan karakteristik berikut:

Frekuensi pengambilan sampel : 24000, 48000

5.5.2. Efek Audio

Android menyediakan API untuk efek audio untuk implementasi perangkat. 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 implementasi 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 Master Volume sistem dan pelemahan volume output audio digital pada output yang didukung, kecuali untuk output passthrough audio yang dikompresi (jika tidak ada decoding audio yang dilakukan pada perangkat).

Implementasi perangkat Android Automotive SEHARUSNYA mengizinkan penyesuaian volume audio secara terpisah untuk setiap streaming audio menggunakan jenis atau penggunaan konten seperti yang ditentukan oleh AudioAttributes dan penggunaan audio mobil seperti yang ditetapkan secara publik di android.car.CarAudioManager .

5.6. Latensi Audio

Latensi audio adalah tunda waktu saat sinyal audio melewati sistem. Banyak kelas aplikasi yang mengandalkan latensi pendek untuk mencapai efek suara real-time.

Untuk tujuan bagian ini, gunakan definisi berikut:

latensi output . Interval antara saat aplikasi menulis frame data berkode PCM dan saat suara yang sesuai disajikan ke lingkungan pada transduser atau sinyal pada perangkat meninggalkan perangkat melalui port dan dapat diamati secara eksternal.
latensi cold output . Latensi output untuk frame pertama, saat sistem output audio tidak ada aktivitas dan dimatikan sebelum permintaan dibuat.
latensi output berkelanjutan . Latensi output untuk frame berikutnya, setelah perangkat memutar audio.
latensi input . Interval antara saat suara disajikan oleh lingkungan ke perangkat pada transduser atau sinyal di perangkat, memasuki perangkat melalui port dan saat aplikasi membaca frame yang sesuai dari data berkode PCM.
kehilangan input . Bagian awal sinyal input yang tidak dapat digunakan atau tidak tersedia.
latensi input cold . 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 menangkap audio.
cold output jitter . Variabilitas di antara pengukuran terpisah dari nilai latensi output cold.
cold input jitter . Variabilitas di antara pengukuran terpisah dari nilai latensi input dingin.
latensi bolak-balik berkelanjutan . Jumlah latensi input berkelanjutan ditambah latensi output berkelanjutan ditambah satu periode buffer. Periode buffer memberikan waktu bagi aplikasi untuk memproses sinyal dan waktu bagi aplikasi untuk mengurangi perbedaan fase antara stream input dan output.
API antrean buffer OpenSL ES PCM . Kumpulan API OpenSL ES terkait PCM dalam Android NDK.

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

latensi output cold 100 milidetik atau kurang
latensi output berkelanjutan 45 milidetik atau kurang
meminimalkan jitter output dingin

Jika implementasi perangkat memenuhi persyaratan bagian ini setelah kalibrasi awal saat menggunakan API antrean buffer OpenSL ES PCM, untuk latensi output berkelanjutan dan latensi output cold pada setidaknya satu perangkat output audio yang didukung, SANGAT DIREKOMENDASIKAN untuk melaporkan dukungan audio latensi rendah, dengan melaporkan fitur android.hardware.audio.low_Latensi melalui class android.content.pm.PackageManager. Sebaliknya, jika implementasi perangkat tidak memenuhi persyaratan ini, implementasi tersebut TIDAK BOLEH melaporkan dukungan untuk audio latensi rendah.

Implementasi perangkat yang menyertakan android.hardware.Mikrofon SANGAT DIREKOMENDASIKAN untuk memenuhi persyaratan audio input ini:

latensi input cold 100 milidetik atau kurang
latensi input berkelanjutan 30 milidetik atau kurang
latensi bolak-balik berkelanjutan 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. Secara khusus, perangkat HARUS mendukung protokol jaringan media berikut:

Streaming progresif HTTP(S)
Semua codec dan format penampung yang diperlukan di bagian 5.1 HARUS didukung melalui HTTP(S)
Protokol draf HTTP Live Streaming, Versi 7
Format segmen media berikut HARUS didukung:

Format segmen	Referensi	Dukungan codec yang diperlukan
Aliran Transpor MPEG-2	ISO 13818	Codec video: AVC H264 MPEG-4 SP MPEG-2 Lihat bagian 5.1.3 untuk mengetahui detail tentang H264 AVC, MPEG2-4 SP, dan MPEG-2. Codec audio: AAC Lihat bagian 5.1.1 untuk mengetahui detail tentang AAC dan variannya.
AAC dengan penyesuaian frame ADTS dan tag ID3	ISO 13818-7	Lihat bagian 5.1.1 untuk mengetahui detail tentang AAC dan variannya
WebVTT	WebVTT

Format segmen

Referensi

Dukungan codec yang diperlukan

Aliran Transpor MPEG-2

ISO 13818

Codec video:

AVC H264
MPEG-4 SP
MPEG-2

Lihat bagian 5.1.3 untuk mengetahui detail tentang H264 AVC, MPEG2-4 SP,
dan MPEG-2.

Codec audio:

Lihat bagian 5.1.1 untuk mengetahui detail tentang AAC dan variannya.

AAC dengan penyesuaian frame ADTS dan tag ID3

ISO 13818-7

Lihat bagian 5.1.1 untuk mengetahui detail tentang AAC dan variannya

WebVTT

RTSP (RTP, SDP)

Profil video audio RTP berikut dan codec terkait HARUS didukung. Untuk pengecualian, lihat catatan kaki tabel di bagian 5.1.

Nama profil	Referensi	Dukungan codec yang diperlukan
AVC H264	RFC 6184	Lihat bagian 5.1.3 untuk mengetahui detail tentang AVC H264
MP4A-LATM	RFC 6416	Lihat bagian 5.1.1 untuk mengetahui detail tentang AAC dan variannya
H263-1998	RFC 3551 RFC 4629 RFC 2190	Lihat bagian 5.1.3 untuk mengetahui detail tentang H263
H263-2000	RFC 4629	Lihat bagian 5.1.3 untuk mengetahui detail tentang H263
AMR	RFC 4867	Lihat bagian 5.1.1 untuk mengetahui detail tentang AMR-NB
AMR-WB	RFC 4867	Lihat bagian 5.1.1 untuk mengetahui detail tentang AMR-WB
MP4V-ES	RFC 6416	Lihat bagian 5.1.3 untuk detail tentang MPEG-4 SP
mpeg4-generik	RFC 3640	Lihat bagian 5.1.1 untuk mengetahui detail tentang AAC dan variannya
MP2T	RFC 2250	Lihat MPEG-2 Transport Stream di bawah HTTP Live Streaming untuk mengetahui detailnya

5.8. Media yang 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 yang kuat secara kriptografis 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. Implementasi 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 transport software MIDI antar-aplikasi (perangkat MIDI virtual), dan mendukung MIDI pada semua transport hardware berkemampuan MIDI berikut, yang menyediakan konektivitas non-MIDI generik, SANGAT DIREKOMENDASIKAN untuk melaporkan dukungan untuk fitur android.software.midi melalui class android.content.pm.PackageManager.

Transportasi hardware yang mendukung MIDI adalah:

Mode host USB (USB bagian 7.7)
Mode periferal USB (USB bagian 7.7)
MIDI melalui Bluetooth LE yang bertindak dalam peran sentral (bagian 7.4.3 Bluetooth)

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

5.10. Audio Profesional

Jika implementasi perangkat memenuhi semua persyaratan berikut, SANGAT DIREKOMENDASIKAN untuk melaporkan dukungan bagi fitur android.hardware.audio.pro melalui class android.content.pm.PackageManager.

Implementasi perangkat HARUS melaporkan dukungan untuk fitur android.hardware.audio.low_Latensi.
Latensi audio bolak-balik berkelanjutan, seperti yang ditetapkan di bagian 5.6 Latensi Audio, HARUS 20 milidetik atau kurang dan SEHARUSNYA 10 milidetik atau kurang pada setidaknya satu jalur yang didukung.
Jika perangkat dilengkapi colokan audio 3,5 mm konduktor 4, latensi audio bolak-balik HARUS 20 milidetik atau kurang dari jalur colokan audio, dan HARUS 10 milidetik atau kurang dari jalur colokan audio.
Implementasi perangkat HARUS menyertakan port USB yang mendukung mode host USB dan mode periferal USB.
Mode host USB HARUS mengimplementasikan class audio USB.
Jika perangkat menyertakan port HDMI, implementasi perangkat HARUS mendukung output dalam stereo dan delapan saluran pada kedalaman 20-bit atau 24-bit dan 192 kHz tanpa kehilangan kedalaman bit atau resampling.
Implementasi perangkat HARUS melaporkan dukungan untuk fitur android.software.midi.
Jika perangkat dilengkapi colokan audio 3,5 mm konduktor 4, penerapan perangkat SANGAT DIREKOMENDASIKAN untuk mematuhi bagian Spesifikasi perangkat seluler (colokan) pada Spesifikasi Headset Audio Berkabel (v1.1).

Persyaratan audio USB dan latensi HARUS dipenuhi menggunakan API antrean buffer PCM OpenSL ES.

Selain itu, penerapan perangkat yang melaporkan dukungan untuk fitur ini HARUS:

Memberikan tingkat performa CPU yang berkelanjutan saat audio aktif.
Minimalkan ketidakakuratan dan penyimpangan jam audio relatif terhadap waktu standar.
Minimalkan penyimpangan jam audio relatif terhadap CLOCK_MONOTONIC CPU saat keduanya aktif.
Minimalkan latensi audio pada transduser di perangkat.
Minimalkan latensi audio pada audio digital USB.
Mendokumentasikan pengukuran latensi audio pada semua jalur.
Minimalkan jitter dalam waktu entri callback penyelesaian buffer audio, karena hal ini memengaruhi persentase bandwidth CPU penuh yang dapat digunakan oleh callback.
Memberikan nol underrun (output) audio atau overrun (input) dalam penggunaan normal pada latensi yang dilaporkan.
Tidak memberikan perbedaan latensi antar-saluran.
Meminimalkan latensi rata-rata MIDI pada semua transpor.
Meminimalkan variabilitas latensi MIDI di bagian beban (jitter) pada semua transpor.
Memberikan stempel waktu MIDI yang akurat pada semua transpor.
Minimalkan derau sinyal audio pada transduser di perangkat, termasuk periode segera setelah cold start.
Berikan perbedaan jam audio nol antara sisi input dan output dari titik akhir yang sesuai, saat keduanya aktif. Contoh titik akhir yang sesuai mencakup mikrofon dan speaker di perangkat, atau input dan output colokan audio.
Tangani callback penyelesaian buffer audio untuk sisi input dan output dari titik akhir yang sesuai pada thread yang sama saat keduanya aktif, dan masukkan callback output segera setelah ditampilkan dari callback input. Atau jika tidak memungkinkan untuk menangani callback pada thread yang sama, maka masukkan callback output segera setelah memasukkan callback input untuk mengizinkan aplikasi memiliki waktu yang konsisten dari sisi input dan output.
Minimalkan perbedaan fase antara buffering audio HAL untuk sisi input dan output dari titik akhir yang terkait.
Meminimalkan latensi sentuh.
Meminimalkan variabilitas latensi sentuh saat terjadi pemuatan (jitter).

5.11. Ambil untuk Belum Diproses

Mulai Android 7.0, sumber rekaman baru telah ditambahkan. File ini dapat diakses menggunakan sumber audio android.media.MediaRecorder.AudioSource.UNPROCESSED. Di OpenSL ES, akses ini dapat diakses dengan preset rekaman SL_ANDROID_RECORDING_PRESET_UNPROCESSED .

Perangkat HARUS memenuhi semua persyaratan berikut untuk melaporkan dukungan sumber audio yang belum diproses melalui properti android.media.AudioManager PROPERTI_SUPPORT_AUDIO_SOURCE_UNPROSES:

Perangkat HARUS menunjukkan karakteristik amplitudo-versus frekuensi yang kira-kira datar dalam rentang frekuensi menengah: khususnya ±10 dB dari 100 Hz hingga 7000 Hz.
Perangkat HARUS menunjukkan tingkat amplitudo dalam rentang frekuensi rendah: khususnya dari ±20 dB dari 5 Hz hingga 100 Hz dibandingkan dengan rentang frekuensi menengah.
Perangkat HARUS menunjukkan tingkat amplitudo dalam rentang frekuensi tinggi: khususnya dari ±30 dB dari 7000 Hz hingga 22 KHz dibandingkan dengan rentang frekuensi menengah.
Sensitivitas input audio HARUS diatur sedemikian rupa sehingga sumber nada sinusoidal 1000 Hz yang diputar pada Level Tekanan Suara (SPL) 94 dB akan menghasilkan respons dengan RMS 520 untuk sampel 16 bit (atau Skala Penuh -36 dB untuk sampel floating point/presisi ganda).
SNR > 60 dB (selisih antara SPL 94 dB dan SPL self noise yang setara, A-weighted).
Total distorsi harmonik HARUS kurang dari 1% untuk 1 kHZ pada level input SPL 90 dB di mikrofon.
Satu-satunya pemrosesan sinyal yang diizinkan di jalur adalah pengganda level untuk membawa level ke rentang yang diinginkan. Pengganda level ini TIDAK BOLEH menimbulkan penundaan atau latensi ke jalur sinyal.
Tidak ada pemrosesan sinyal lain yang diizinkan di jalur tersebut, seperti Kontrol Penguatan Otomatis, Filter Tingkat Tinggi, atau Pembatalan Echo. Jika ada pemrosesan sinyal di arsitektur untuk alasan apa pun, pemrosesan tersebut HARUS dinonaktifkan dan secara efektif menimbulkan penundaan nol atau latensi tambahan ke jalur sinyal.

Semua pengukuran SPL dilakukan langsung di sebelah mikrofon yang diuji.

Untuk beberapa konfigurasi mikrofon, persyaratan ini berlaku untuk setiap mikrofon.

SANGAT DIREKOMENDASIKAN bahwa perangkat memenuhi sebanyak mungkin persyaratan jalur sinyal untuk sumber rekaman yang belum diproses; tetapi, perangkat harus memenuhi semua persyaratan yang tercantum di atas, jika perangkat mengklaim mendukung sumber audio yang tidak diproses.

6. Kompatibilitas Opsi dan Developer Tools

6.1. Alat Pengembang

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

Android Debug Bridge (adb)
- Implementasi perangkat HARUS mendukung semua fungsi adb seperti yang didokumentasikan di Android SDK, termasuk dumpsys.
- 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 memungkinkan adb pada host terautentikasi yang dikenal. Implementasi perangkat HARUS mendukung adb aman.
Layanan Pemantau Debug Dalvik (ddms)
- Implementasi perangkat HARUS mendukung semua fitur ddms seperti yang didokumentasikan dalam Android SDK.
- Karena ddms menggunakan adb, dukungan untuk ddms SEHARUSNYA tidak aktif secara default, tetapi HARUS didukung setiap kali pengguna mengaktifkan Android Debug Bridge, seperti di atas.
Implementasi perangkat Monkey HARUS menyertakan framework Monkey, dan menyediakannya untuk digunakan oleh aplikasi.
SysTrace
- Implementasi perangkat HARUS mendukung alat systrace seperti yang didokumentasikan di Android SDK. Systrace harus tidak aktif secara default, dan HARUS ada mekanisme yang dapat diakses oleh pengguna untuk mengaktifkan Systrace.
- Sebagian besar sistem berbasis Linux dan sistem Apple Macintosh mengenali perangkat Android menggunakan Android SDK Tools standar, tanpa dukungan tambahan; namun sistem Microsoft Windows biasanya memerlukan {i>driver<i} untuk perangkat Android baru. (Misalnya, ID vendor baru dan terkadang ID perangkat baru memerlukan driver USB khusus untuk sistem Windows.)
- Jika implementasi perangkat tidak dikenali oleh alat adb seperti yang diberikan dalam 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. Implementasi Android upstream menyembunyikan menu Opsi Developer secara default dan memungkinkan pengguna meluncurkan Opsi Developer setelah menekan tujuh (7) kali pada Setelan > Tentang Perangkat > Item menu Build Number. 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.

Implementasi Android Automotive DAPAT membatasi akses ke menu Opsi Developer dengan menyembunyikan atau menonaktifkan menu secara visual saat kendaraan sedang bergerak.

7. Kompatibilitas Perangkat Keras

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 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 tanpa pengoperasian dengan cara yang wajar.
Metode API HARUS menampilkan nilai null jika diizinkan oleh dokumentasi SDK.
Metode API HARUS menampilkan implementasi class tanpa pengoperasian, yang mana nilai null tidak diizinkan oleh dokumentasi SDK.
Metode API TIDAK BOLEH menampilkan pengecualian yang tidak didokumentasikan oleh dokumentasi SDK.

Contoh umum skenario saat persyaratan ini berlaku adalah API telepon: Bahkan pada perangkat non-ponsel, API ini harus diimplementasikan sebagai tanpa pengoperasian yang wajar.

Penerapan perangkat HARUS secara konsisten melaporkan informasi konfigurasi hardware yang akurat melalui metode getSystemAvailableFeatures() dan hasSystemFeature(String) pada class android.content.pm.PackageManager untuk sidik jari build yang sama.

7.1. Tampilan dan Grafis

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

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

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

7.1.1 Konfigurasi Layar

7.1.1.1 Ukuran Layar

Perangkat Android Watch (diuraikan di bagian 2) MUNGKIN memiliki ukuran layar yang lebih kecil seperti yang dijelaskan di bagian ini.

Framework UI Android mendukung berbagai ukuran layar, dan memungkinkan aplikasi membuat kueri ukuran layar perangkat (disebut juga "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 dan ditentukan oleh platform Android upstream. Secara khusus, penerapan 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 jika perangkat tersebut adalah perangkat Smartwatch Android.
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 'ekstra besar' 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.
Perangkat Android Automotive HARUS memiliki layar dengan ukuran diagonal fisik lebih besar dari atau sama dengan 6 inci.
Perangkat Android Automotive HARUS memiliki ukuran layar minimal 750 dp x 480 dp.
Jenis implementasi perangkat Android lainnya, dengan layar yang terintegrasi secara fisik, HARUS memiliki layar minimal 2,5 inci dalam ukuran diagonal fisik.

Perangkat TIDAK BOLEH mengubah ukuran layar yang dilaporkan.

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

7.1.1.2. Rasio Aspek Layar

Meskipun tidak ada batasan terhadap nilai rasio aspek layar tampilan layar fisik, rasio aspek layar platform tempat aplikasi pihak ketiga dirender dan yang dapat berasal dari nilai yang dilaporkan melalui DisplayMetrics HARUS memenuhi persyaratan berikut:

Jika uiMode dikonfigurasi sebagai UI_MODE_TYPE_WATCH, nilai rasio aspek MUNGKIN ditetapkan sebagai 1.0 (1:1).
Jika aplikasi pihak ketiga menunjukkan bahwa ukuran aplikasi dapat diubah melalui atribut android:resizeableActivity, tidak ada batasan untuk nilai rasio aspek.
Untuk semua kasus lainnya, rasio aspek HARUS berupa nilai antara 1,3333 (4:3) dan 1,86 (sekitar 16:9) kecuali jika aplikasi telah menunjukkan secara eksplisit bahwa aplikasi mendukung rasio aspek layar yang lebih tinggi melalui nilai metadata maxAspectRatio.

7.1.1.3. Kepadatan Layar

Framework UI Android mendefinisikan serangkaian kepadatan logis standar untuk membantu developer aplikasi menargetkan resource aplikasi. Implementasi perangkat HARUS melaporkan salah satu kepadatan framework Android logis berikut melalui API android.util.DisplayMetrics, dan HARUS mengeksekusi aplikasi dengan kepadatan standar ini dan TIDAK BOLEH mengubah nilai kapan saja untuk tampilan 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 tersebut mendorong ukuran layar yang dilaporkan di bawah ukuran 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 kompatibel dan didukung (lebar 320 dp), implementasi perangkat SEHARUS melaporkan kepadatan framework Android standar terendah berikutnya.

Penerapan perangkat SANGAT DIREKOMENDASIKAN untuk memberikan setelan kepada pengguna guna mengubah ukuran layar. Jika ada implementasi untuk mengubah ukuran layar perangkat, implementasi tersebut HARUS selaras dengan implementasi AOSP seperti yang ditunjukkan di bawah:

Ukuran layar TIDAK BOLEH diskalakan lebih besar dari 1,5 kali kepadatan native atau menghasilkan dimensi layar minimum efektif yang lebih kecil dari 320 dp (setara dengan penentu resource sw320dp), mana saja yang lebih dulu.
Ukuran tampilan TIDAK BOLEH diskalakan lebih kecil dari 0,85 kali kepadatan native.
Untuk memastikan kegunaan yang baik dan ukuran font yang konsisten, DIREKOMENDASIKAN untuk menyediakan penskalaan opsi Tampilan Native berikut (sekaligus mematuhi batas yang ditentukan di atas)
Kecil: 0,85x
Default: 1x (Skala tampilan native)
Besar: 1,15x
Lebih besar: 1,3x
Terbesar 1,45x

7.1.2. Metrik Display

Implementasi perangkat HARUS melaporkan nilai yang benar untuk semua metrik tampilan yang ditentukan dalam android.util.DisplayMetrics 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 setidaknya satu orientasi yang didukung. Misalnya, perangkat dengan layar lanskap orientasi tetap, seperti televisi atau laptop, SEHARUSNYA hanya melaporkan android.hardware.screen.landscape.

Perangkat yang melaporkan kedua orientasi layar HARUS mendukung orientasi dinamis menurut aplikasi untuk orientasi layar potret atau lanskap. Artinya, perangkat harus mengikuti 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 kepadatan atau ukuran 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 tercakup dan dijelaskan dalam dokumentasi Android SDK. Implementasi perangkat HARUS mendukung OpenGL ES 3.0, 3.1, atau 3.2 pada perangkat yang bisa mendukungnya. Implementasi perangkat juga HARUS mendukung Android RenderScript, seperti yang dijelaskan dalam dokumentasi Android SDK.

Implementasi perangkat HARUS juga mengidentifikasi dirinya dengan benar sebagai pendukung OpenGL ES 1.0, OpenGL ES 2.0, OpenGL ES 3.0, OpenGL 3.1, atau OpenGL 3.2. Yaitu:

API yang dikelola (seperti melalui metode GLES10.getString()) HARUS melaporkan dukungan untuk OpenGL ES 1.0 dan OpenGL ES 2.0.
API OpenGL C/C++ native (API 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, 3.1, atau 3.2 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, 3.1, atau 3.2 libGLESv2.so HARUS mengekspor simbol fungsi yang sesuai selain simbol fungsi OpenGL ES 2.0.

Android menyediakan paket ekstensi OpenGL ES dengan antarmuka Java dan dukungan native untuk fungsi grafis lanjutan seperti teselasi dan format kompresi tekstur ASTC. Implementasi perangkat Android HARUS mendukung paket ekstensi jika perangkat mendukung OpenGL ES 3.2 dan BISA mendukungnya. Jika paket ekstensi didukung secara keseluruhan, perangkat HARUS mengidentifikasi dukungan melalui tombol fitur android.hardware.opengles.aep.

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

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

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

Implementasi perangkat HARUS mengaktifkan akselerasi hardware secara default, dan HARUS menonaktifkan akselerasi hardware jika developer memintanya dengan menyetel 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.

Android menyertakan objek TextureView yang memungkinkan developer mengintegrasikan tekstur OpenGL ES dengan akselerasi 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. Penerapan perangkat HARUS mendukung ekstensi EGL_ANDROID_RECORDABLE.

7.1.5. Mode Kompatibilitas Aplikasi Lama

Android menentukan “mode kompatibilitas” tempat framework beroperasi dalam lingkungan 'normal' mode setara ukuran layar (lebar 320 dp) untuk kepentingan aplikasi lama yang tidak dikembangkan untuk versi Android lama yang lebih lama dari kemandirian ukuran layar.

Android Automotive tidak mendukung mode kompatibilitas lama.
Semua penerapan 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 grafik yang kaya ke layar. Perangkat HARUS mendukung semua API ini sebagaimana ditetapkan oleh Android SDK, kecuali jika diizinkan secara khusus dalam dokumen ini.

Perangkat HARUS mendukung layar yang mampu merender grafis berwarna 16-bit dan SEHARUSNYA mendukung layar yang dapat menampilkan grafis berwarna 24-bit.
Perangkat HARUS mendukung layar yang mampu merender animasi.
Teknologi tampilan 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 tampilan sekunder guna mengaktifkan kemampuan berbagi media dan API developer untuk mengakses tampilan eksternal. Jika perangkat mendukung layar eksternal baik melalui koneksi berkabel, nirkabel, atau layar tambahan yang disematkan, implementasi perangkat HARUS menerapkan display manager API seperti yang dijelaskan dalam dokumentasi Android SDK.

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 Android Watch dan Android Automotive MUNGKIN menerapkan keyboard virtual. Semua implementasi perangkat lainnya HARUS mengimplementasikan keyboard virtual dan:

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 ada keyboard fisik atau tidak) kecuali untuk perangkat Android Watch yang ukuran layarnya membuat keyboard virtual kurang masuk akal.
DAPAT mencakup implementasi keyboard virtual tambahan.
MUNGKIN menyertakan keyboard hardware.
TIDAK BOLEH menyertakan keyboard hardware yang tidak sesuai dengan salah satu format yang ditentukan dalam android.content.res.Configuration.keyboard (QWERTY atau 12 tombol).

7.2.2. Navigasi Non-sentuh

Perangkat Android Television HARUS mendukung D-pad.

Implementasi perangkat:

MUNGKIN 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.
HARUS menyediakan mekanisme antarmuka pengguna alternatif yang wajar untuk pemilihan dan pengeditan teks, yang kompatibel dengan Input Management Engine. 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

Persyaratan ketersediaan dan visibilitas fungsi Beranda, Terbaru, dan Kembali berbeda-beda untuk setiap jenis perangkat seperti yang dijelaskan di bagian ini.

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

Implementasi perangkat Genggam Android HARUS menyediakan fungsi Beranda, Terbaru, dan Kembali.
Implementasi perangkat Android Television HARUS menyediakan fungsi Layar Utama dan Kembali.
Implementasi perangkat Android Watch HARUS memiliki fungsi Beranda yang tersedia bagi pengguna, dan fungsi Kembali, kecuali jika berada dalam UI_MODE_TYPE_WATCH .
Implementasi perangkat Android Watch, dan tidak ada jenis perangkat Android lainnya, MUNGKIN menggunakan peristiwa tekan lama pada peristiwa tombol KEYCODE_BACK dan menghilangkannya agar tidak dikirim ke aplikasi latar depan.
Implementasi Android Automotive HARUS menyediakan fungsi Beranda dan MUNGKIN menyediakan fungsi Kembali dan Terbaru.
Semua jenis implementasi perangkat lainnya HARUS menyediakan fungsi Beranda dan Kembali.

Fungsi ini DAPAT diimplementasikan melalui tombol fisik khusus (seperti tombol sentuh mekanis atau kapasitif), atau DAPAT diimplementasikan menggunakan tombol software khusus di bagian layar, gestur, panel sentuh yang berbeda, dll. Android mendukung kedua implementasi 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 mengupgrade dari versi Android sebelumnya yang memiliki tombol fisik untuk navigasi dan tidak memiliki tombol terbaru.

Fungsi Beranda dan Kembali, jika disediakan, masing-masing 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 digantikan oleh panel tindakan sejak Android 4.0. Oleh karena itu, implementasi perangkat baru yang dikirim dengan Android 7.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 tindakan tambahan pada panel tindakan jika terlihat dan pop-up menu tambahan tindakan yang dihasilkan tidak kosong. Untuk implementasi perangkat yang diluncurkan sebelum Android 4.4 tetapi meningkatkan ke Android 7.0, hal ini DIREKOMENDASIKAN.
TIDAK BOLEH mengubah posisi pop-up tindakan tambahan yang ditampilkan dengan memilih tombol tambahan di kolom tindakan.
DAPAT merender pop-up tindakan tambahan pada posisi yang dimodifikasi di layar saat ditampilkan dengan memilih tombol menu fisik.

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

Penerapan perangkat Android yang mendukung tindakan Bantuan dan/atau VoiceInteractionService HARUS dapat meluncurkan aplikasi bantuan dengan satu interaksi (misalnya, ketuk, klik dua kali, atau gestur) saat tombol navigasi lain terlihat. SANGAT DIREKOMENDASIKAN untuk menggunakan tekan lama pada layar utama sebagai interaksi ini. Interaksi yang ditetapkan HARUS meluncurkan aplikasi bantuan yang dipilih pengguna, dengan kata lain aplikasi yang menerapkan VoiceInteractionService, atau aktivitas yang menangani intent ACTION_ASSIST.

Implementasi perangkat MUNGKIN menggunakan bagian layar yang berbeda untuk menampilkan tombol navigasi, tetapi jika ya, HARUS memenuhi persyaratan berikut:

Tombol navigasi penerapan 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 pasal 7.1.1.
Implementasi perangkat HARUS menampilkan kunci navigasi jika aplikasi tidak menentukan mode UI sistem, atau menentukan SYSTEM_UI_FLAG_VISIBLE.
Implementasi perangkat HARUS menyajikan tombol navigasi dalam mode "profil rendah" yang tidak mengganggu (misalnya, redup) 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

Perangkat Genggam dan Jam Tangan Android HARUS mendukung input layar sentuh.

Implementasi perangkat SEHARUSNYA 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 secara independen sepenuhnya, jika sistem input perangkat mendukung beberapa pointer.
HARUS melaporkan nilai android.content.res.Configuration.touchscreen yang sesuai dengan jenis layar sentuh tertentu di perangkat.

Android menyertakan dukungan untuk berbagai layar sentuh, touchpad, dan perangkat input sentuh palsu. Penerapan perangkat berbasis layar sentuh dikaitkan dengan tampilan sedemikian rupa sehingga pengguna memiliki kesan memanipulasi item di layar secara langsung. 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 mendekati subset kemampuan layar sentuh. Misalnya, mouse atau remote control yang menggerakkan kursor pada layar mendekati sentuhan, tetapi mengharuskan pengguna untuk terlebih dahulu menunjuk atau memfokuskan kemudian mengklik. Banyak perangkat input seperti mouse, trackpad, air mouse berbasis giroskop, gyro-pointer, joystick, dan trackpad multi-sentuh dapat mendukung interaksi sentuh palsu. Android menyertakan konstanta fitur android.hardware.faketouch, yang sesuai dengan perangkat input non-sentuh (berbasis pointer) dengan fidelitas tinggi seperti mouse atau trackpad yang dapat secara memadai mengemulasi input berbasis sentuh (termasuk dukungan gestur dasar), dan menunjukkan bahwa perangkat mendukung subset fungsi layar sentuh yang diemulasikan. Implementasi perangkat yang mendeklarasikan fitur sentuh palsu HARUS memenuhi persyaratan sentuhan palsu di pasal 7.2.5.

Implementasi perangkat HARUS melaporkan fitur yang benar sesuai dengan jenis input yang digunakan. Implementasi perangkat yang menyertakan layar sentuh (satu sentuhan atau lebih baik) HARUS melaporkan konstanta fitur platform android.hardware.touchscreen. Implementasi perangkat yang melaporkan konstanta fitur platform android.hardware.touchscreen 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 HARUS melaporkan hanya android.hardware.faketouch jika memenuhi persyaratan sentuhan palsu di pasal 7.2.5.

7.2.5. Input Sentuhan Palsu

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

HARUS melaporkan posisi layar X dan Y absolut lokasi pointer dan menampilkan pointer visual di layar.
HARUS melaporkan peristiwa sentuh dengan kode tindakan yang menentukan perubahan status yang terjadi pada pointer yang turun atau naik di layar.
HARUS mendukung pointer ke bawah dan ke atas pada objek di layar, yang memungkinkan pengguna mengemulasikan ketukan pada objek di layar.
HARUS mendukung pointer ke bawah, mengarahkan ke atas, mengarahkan ke bawah, lalu mengarahkan ke atas di tempat yang sama pada objek di layar dalam batas waktu, yang memungkinkan pengguna mengemulasi ketuk dua kali pada objek di layar.
HARUS mendukung pointer ke bawah pada titik arbitrer di layar, pointer bergerak ke titik arbitrer lainnya di layar, diikuti dengan pointer ke atas, yang memungkinkan pengguna mengemulasikan tarik sentuh.
HARUS mendukung pointer ke bawah agar pengguna dapat dengan cepat memindahkan objek ke posisi yang berbeda pada layar, lalu mengarahkan ke atas di layar, yang memungkinkan pengguna melemparkan sebuah objek di layar.

Perangkat yang mendeklarasikan dukungan untuk android.hardware.faketouch.multitouch.distinct HARUS memenuhi persyaratan untuk faulttouch di atas, dan 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 menyertakan implementasi untuk pengontrol game yang memenuhi persyaratan ini.

7.2.6.1. Pemetaan Tombol

Implementasi perangkat Android Television HARUS mendukung konfigurasi tombol berikut:

Tombol	Penggunaan HID ²	Tombol Android
J ¹	0x09 0x0001	KEYCODE_BUTTON_A (96)
B ¹	0x09 0x0002	KEYCODE_BUTTON_B (97)
X ¹	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y ¹	0x09 0x0005	KEYCODE_BUTTON_Y (100)
D-pad atas ¹ D-pad bawah ¹	0x01 0x0039 ³	AXIS_HAT_Y ⁴
D-pad kiri 1 D-pad kanan ¹	0x01 0x0039 ³	AXIS_HAT_X ⁴
Tombol bahu kiri ¹	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Tombol bahu kanan ¹	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Klik stik kiri ¹	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Klik stik kanan ¹	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Beranda ¹	0x0c 0x0223	KEYCODE_HOME (3)
Kembali ¹	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

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

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

4 MotionEvent

Kontrol Analog ¹	Penggunaan HID	Tombol Android
Pemicu Kiri	Info tambahan 0x02 0x00C5	AXIS_LTRIGGER
Pemicu Kanan	0x02 0x00C4	AXIS_RTRIGGER
Joystick Kiri	0x01 0x0030 0x01 0x0031	AXIS_X AKSI_Y
Joystick Kanan	0x01 0x0032 0x01 0x0035	AXIS_Z RZ_AXIS

1 MotionEvent

7.2.7. Remote Control

Implementasi perangkat Android Television HARUS menyediakan remote control agar pengguna dapat 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 ditetapkan di bawah ini.

Keterjangkauan penelusuran . Implementasi perangkat HARUS mengaktifkan KEYCODE_SEARCH saat pengguna memanggil penelusuran suara di remote berbasis fisik atau software.
Navigasi . Semua remote Android Television HARUS menyertakan tombol Kembali, Beranda, dan Pilih serta dukungan untuk peristiwa D-pad.

7.3. Sensor

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

HARUS melaporkan ada atau tidaknya sensor secara akurat per class android.content.pm.PackageManager.
HARUS menampilkan daftar akurat sensor yang didukung melalui SensorManager.getSensorList() dan metode serupa.
HARUS berperilaku wajar untuk semua API sensor lainnya (misalnya, dengan menampilkan true (benar) atau false (salah) sebagaimana mestinya saat aplikasi mencoba mendaftarkan pemroses, bukan memanggil pemroses sensor saat sensor yang sesuai tidak ada; dll.).
HARUS melaporkan semua pengukuran sensor menggunakan nilai Sistem Unit Internasional (metrik) yang relevan untuk setiap jenis sensor seperti yang ditentukan dalam dokumentasi Android SDK.
HARUS melaporkan waktu peristiwa dalam nanodetik seperti yang ditentukan dalam dokumentasi Android SDK, yang menampilkan waktu terjadinya peristiwa dan disinkronkan dengan jam SystemClock.elapsedRealtimeNano(). Perangkat Android yang sudah ada dan baru DIREKOMENDASIKAN untuk memenuhi persyaratan ini sehingga dapat melakukan upgrade ke rilis platform mendatang yang mungkin menjadi komponen WAJIB. Error sinkronisasi SEHARUSNYA di bawah 100 milidetik.
HARUS melaporkan data sensor dengan latensi maksimum 100 milidetik + 2 * sample_time untuk kasus sensor yang di-streaming dengan latensi minimum yang diperlukan sebesar 5 md + 2 * sample_time saat prosesor aplikasi aktif. Penundaan ini tidak termasuk penundaan pemfilteran.
HARUS melaporkan sampel sensor pertama dalam waktu 400 milidetik + 2 * sample_time sensor yang diaktifkan. Sampel ini boleh memiliki akurasi 0.

Daftar di atas tidak komprehensif; perilaku Android SDK yang didokumentasikan dan Dokumentasi Open Source Android tentang sensor harus dianggap otoritatif.

Beberapa jenis sensor bersifat komposit, artinya sensor tersebut dapat diambil dari data yang disediakan oleh satu atau beberapa sensor lainnya. (Contohnya termasuk sensor orientasi dan sensor akselerasi linear.) Implementasi perangkat HARUS menerapkan jenis sensor ini, jika jenis sensor tersebut menyertakan sensor fisik prasyarat seperti yang dijelaskan dalam jenis sensor. Jika implementasi perangkat menyertakan sensor komposit, sensor tersebut HARUS menerapkan sensor seperti yang dijelaskan dalam dokumentasi Open Source Android tentang sensor komposit.

Beberapa sensor Android mendukung mode pemicu “kontinu”, yang menampilkan data secara terus-menerus. Untuk setiap API yang ditunjukkan oleh dokumentasi Android SDK sebagai sensor berkelanjutan, implementasi perangkat HARUS terus menyediakan sampel data berkala yang SEHARUSNYA memiliki jitter di bawah 3%, dengan jitter didefinisikan sebagai simpangan baku dari perbedaan nilai stempel waktu yang dilaporkan di antara peristiwa berturut-turut.

Perhatikan bahwa implementasi perangkat HARUS memastikan aliran peristiwa sensor TIDAK BOLEH mencegah CPU perangkat memasuki status ditangguhkan atau bangun dari status ditangguhkan.

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

7.3.1. Akselerometer

Implementasi perangkat HARUS menyertakan akselerometer 3 sumbu. Perangkat Genggam Android, implementasi Android Automotive, dan perangkat Android Watch SANGAT DIREKOMENDASIKAN untuk menyertakan sensor ini. Jika implementasi perangkat menyertakan akselerometer 3-sumbu, maka implementasi perangkat:

HARUS menerapkan dan melaporkan sensor TYPE_ACCELEROMETER.
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 API Android. Implementasi Android Automotive HARUS mematuhi sistem koordinat sensor mobil Android.
HARUS mampu mengukur dari terjun bebas hingga empat kali gravitasi (4g) atau lebih pada sumbu apa pun.
HARUS memiliki resolusi minimal 12-bit dan HARUS memiliki resolusi minimal 16-bit.
HARUS dikalibrasi saat digunakan jika karakteristiknya berubah selama siklus proses dan diberi kompensasi, serta mempertahankan parameter kompensasi setelah perangkat dimulai ulang.
HARUS diberi kompensasi suhu.
HARUS memiliki deviasi standar tidak lebih dari 0,05 m/s^, dengan deviasi standar harus dihitung berdasarkan per sumbu pada sampel yang dikumpulkan selama periode minimal 3 detik pada frekuensi pengambilan sampel tercepat.
HARUS menerapkan sensor gabungan TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER seperti yang dijelaskan dalam dokumen SDK Android. Perangkat Android yang sudah ada dan yang baru SANGAT DIREKOMENDASIKAN untuk menerapkan sensor komposit TYPE_SIGNIFICANT_MOTION. Jika salah satu sensor ini diterapkan, jumlah konsumsi dayanya HARUS selalu kurang dari 4 mW dan masing-masing harus di bawah 2 mW dan 0,5 mW untuk saat perangkat dalam kondisi dinamis atau statis.
Jika sensor giroskop disertakan, HARUS menerapkan sensor komposit TYPE_GRAVITY dan TYPE_LINEAR_ACCELERATION dan SEHARUSNYA menerapkan sensor komposit TYPE_GAME_ROTATION_VECTOR. Perangkat Android yang sudah ada dan yang baru SANGAT DIREKOMENDASIKAN untuk menerapkan sensor TYPE_GAME_ROTATION_VECTOR.
HARUS menerapkan sensor komposit 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 SEHARUSNYA juga menerapkan sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED. Perangkat Android yang sudah ada dan yang baru SANGAT DIREKOMENDASIKAN untuk menerapkan sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED.
HARUS dapat melaporkan peristiwa hingga frekuensi setidaknya 10 Hz dan HARUS melaporkan peristiwa hingga setidaknya 50 Hz.
HARUS mematuhi sistem koordinat sensor Android seperti yang dijelaskan dalam API Android.
HARUS mampu mengukur antara -900 μT dan +900 μT pada setiap sumbu sebelum saturasi.
HARUS memiliki nilai offset besi keras kurang dari 700 μT dan SEHARUSNYA memiliki nilai di bawah 200 μT, dengan menempatkan magnetometer jauh dari medan magnet dinamis (diinduksi arus) dan statis (diinduksi 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 μT.
HARUS diberi kompensasi suhu.
HARUS mendukung kalibrasi online dan kompensasi bias hard iron, serta mempertahankan parameter kompensasi di antara proses mulai ulang perangkat.
HARUS menerapkan kompensasi soft iron—kalibrasi dapat dilakukan saat digunakan atau selama produksi perangkat.
HARUS memiliki deviasi standar, dihitung per sumbu pada sampel yang dikumpulkan selama periode minimal 3 detik pada frekuensi pengambilan sampel tercepat, tidak lebih dari 0,5 μT.
HARUS menerapkan sensor komposit TYPE_ROTATION_VECTOR, jika sensor akselerometer dan sensor giroskop juga disertakan.
DAPAT mengimplementasikan sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR jika sensor akselerometer juga diimplementasikan. Namun jika diimplementasikan, sensor ini HARUS menggunakan kurang dari 10 mW dan SEHARUSNYA kurang dari 3 mW saat sensor didaftarkan untuk mode batch pada 10 Hz.

7.3.3. GPS

Implementasi perangkat HARUS menyertakan penerima GPS/GNSS. Jika implementasi perangkat menyertakan penerima GPS/GNSS dan melaporkan kemampuan ke aplikasi melalui flag fitur android.hardware.location.gps:

SANGAT DIREKOMENDASIKAN agar perangkat terus memberikan output GPS/GNSS normal ke aplikasi selama panggilan telepon darurat dan output lokasi tidak terhalang selama panggilan telepon darurat.
Ini HARUS mendukung output lokasi pada kecepatan minimal 1 Hz saat diminta melalui LocationManager#requestLocationUpdate .
Harus dapat menentukan lokasi dalam kondisi langit terbuka (sinyal kuat, multijalur dapat diabaikan, HDOP < 2) dalam 10 detik (waktu cepat untuk perbaikan pertama), saat terhubung ke 0,5 Mbps atau koneksi internet kecepatan data lebih cepat. Persyaratan ini biasanya dipenuhi dengan penggunaan beberapa bentuk teknik GPS/GNSS Terbantu atau Prediksi untuk meminimalkan waktu penguncian GPS/GNSS (Data Bantuan mencakup Waktu Referensi, Lokasi Referensi, dan Ephemeris/Jam Satelit).
- Setelah membuat perhitungan lokasi seperti itu, SANGAT DIREKOMENDASIKAN agar perangkat dapat menentukan lokasinya, di langit terbuka, dalam waktu 10 detik, saat permintaan lokasi dimulai ulang, hingga satu jam setelah perhitungan lokasi awal, bahkan saat permintaan selanjutnya dibuat tanpa koneksi data, dan/atau setelah siklus daya.
Dalam kondisi langit terbuka setelah menentukan lokasi, saat diam atau bergerak dengan percepatan kurang dari 1 meter per detik kuadrat:
- Harus dapat menentukan lokasi dalam jarak 20 meter, dan kecepatan dalam 0,5 meter per detik, setidaknya 95% dari waktu.
- Satelit HARUS melacak dan melaporkan secara bersamaan melalui GnssStatus.Callback setidaknya 8 satelit dari satu konstelasi.
- Satelit harus dapat melacak setidaknya 24 satelit secara bersamaan, dari berbagai rasi bintang (misalnya GPS + setidaknya salah satu dari Glonass, Beidou, Galileo).
Aplikasi HARUS melaporkan pembuatan teknologi GNSS melalui API pengujian 'getGnssYearOfHardware'.
SANGAT DIREKOMENDASIKAN untuk memenuhi dan HARUS memenuhi semua persyaratan di bawah ini jika generasi teknologi GNSS dilaporkan sebagai tahun "2016" atau yang lebih baru.
- GPS HARUS melaporkan pengukuran GPS, segera setelah ditemukan, meskipun lokasi yang dihitung dari GPS/GNSS belum dilaporkan.
- Ia HARUS melaporkan tingkat pseudorange dan pseudorange GPS, bahwa, dalam kondisi langit terbuka setelah menentukan lokasi, saat diam atau bergerak dengan akselerasi kurang dari 0,2 meter per detik kuadrat, cukup untuk menghitung posisi dalam jarak 20 meter, dan kecepatan dalam jarak 0,2 meter per detik, setidaknya 95% dari waktu.

Perhatikan bahwa meskipun beberapa persyaratan GPS di atas dinyatakan SANGAT DIREKOMENDASIKAN, Compatibility Definition untuk versi utama berikutnya diharapkan untuk mengubahnya menjadi HARUS.

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, implementasi tersebut:

HARUS menerapkan sensor TYPE_GYROSCOPE dan SEHARUSNYA juga menerapkan sensor TYPE_GYROSCOPE_UNCALIBRATED. Perangkat Android yang sudah ada dan yang baru SANGAT DIREKOMENDASIKAN untuk menerapkan sensor SENSOR_TYPE_GYROSCOPE_UNCALIBRATED.
HARUS mampu 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 SEHARUSNYA memiliki resolusi 16-bit atau lebih.
HARUS diberi kompensasi suhu.
HARUS dikalibrasi dan diberi kompensasi saat digunakan, dan mempertahankan parameter kompensasi antara perangkat dimulai ulang.
HARUS memiliki varians tidak lebih besar dari 1e-7 rad^2 / s^2 per Hz (varian per Hz, atau rad^2 / s). Varian diperbolehkan untuk bervariasi dengan frekuensi sampling, tetapi harus dibatasi oleh nilai ini. Dengan kata lain, jika Anda mengukur varians gyro pada frekuensi sampling 1 Hz, seharusnya tidak lebih besar dari 1e-7 rad^2/s^2.
HARUS menerapkan sensor komposit 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 SEHARUSNYA menerapkan sensor komposit TYPE_GAME_ROTATION_VECTOR. Perangkat Android yang sudah ada dan yang baru SANGAT DIREKOMENDASIKAN 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, implementasi tersebut:

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

7.3.6. Thermometer

Implementasi perangkat MUNGKIN menyertakan termometer ruangan (sensor suhu). Jika ada, parameter HARUS ditetapkan sebagai SENSOR_TYPE_AMBIENT_SUHU dan HARUS mengukur suhu sekitar (kamar) dalam derajat Celsius.

Implementasi perangkat MUNGKIN, tetapi TIDAK BOLEH menyertakan sensor suhu CPU. Jika ada, parameter HARUS ditetapkan sebagai SENSOR_TYPE_SUHU, HARAP mengukur suhu CPU perangkat, dan TIDAK BOLEH mengukur suhu lain. Perhatikan bahwa jenis sensor SENSOR_TYPE_GENIE sudah tidak digunakan lagi di Android 4.0.

Untuk implementasi Android Automotive, SENSOR_TYPE_AMBIENT_SUHU HARUS mengukur suhu di dalam kabin kendaraan.

7.3.7. Fotometer

Implementasi perangkat MUNGKIN menyertakan fotometer (sensor cahaya sekitar).

7.3.8. Sensor Kedekatan

Implementasi perangkat MUNGKIN mencakup sensor kedekatan. Perangkat yang dapat melakukan panggilan suara dan menunjukkan nilai apa pun selain PHONE_TYPE_NONE dalam getPhoneType SHOULD akan menyertakan sensor kedekatan. Jika implementasi perangkat menyertakan sensor kedekatan, implementasi tersebut:

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

7.3.9. Sensor Fidelitas Tinggi

Implementasi perangkat yang mendukung serangkaian sensor berkualitas lebih tinggi yang dapat memenuhi semua persyaratan yang tercantum di bagian ini HARUS mengidentifikasi dukungan melalui tombol 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 +8 g.
- HARUS memiliki resolusi pengukuran minimal 1024 LSB/G.
- HARUS memiliki frekuensi pengukuran minimum 12,5 Hz atau lebih rendah.
- HARUS memiliki frekuensi pengukuran maksimum 400 Hz atau lebih tinggi.
- HARUS memiliki derau pengukuran yang tidak di atas 400 uG/✓Hz.
- HARUS mengimplementasikan bentuk non-bangun dari sensor ini dengan kemampuan buffering minimal 3000 peristiwa sensor.
- HARUS memiliki konsumsi daya pengelompokan tidak lebih buruk dari 3 mW.
- SEHARUSNYA memiliki stabilitas bias kebisingan stasioner \<15 μg ✓Hz dari {i>dataset<i} statis 24 jam.
- HARUS memiliki perubahan bias vs. suhu ≤ +/- 1mg / °C.
- HARUS memiliki garis non-linearitas terbaik ≤ 0,5%, dan perubahan sensitivitas vs. suhu ≤ 0,03%/C °.
SENSOR_TYPE_GYROSCOPE
- HARUS memiliki rentang pengukuran antara minimal -1.000 dan +1.000 dp.
- HARUS memiliki resolusi pengukuran minimal 16 LSB/dp.
- HARUS memiliki frekuensi pengukuran minimum 12,5 Hz atau lebih rendah.
- HARUS memiliki frekuensi pengukuran maksimum 400 Hz atau lebih tinggi.
- HARUS memiliki derau pengukuran yang tidak di atas 0,014 °/s/{4}Hz.
- HARUS memiliki stabilitas bias stasioner sebesar < 0,0002 °/s ✓Hz dari {i>dataset<i} statis 24 jam.
- HARUS memiliki perubahan bias vs. suhu ≤ +/- 0,05 °/ s / °C.
- HARUS memiliki perubahan sensitivitas vs. suhu ≤ 0,02% / °C.
- HARUS memiliki garis non-linearitas terbaik ≤ 0,2%.
- SEHARUSNYA memiliki kepadatan kebisingan ≤ 0,007 °/s/✓Hz.
SENSOR_TYPE_GYROSCOPE_UNCALIBRATED dengan persyaratan kualitas yang sama seperti SENSOR_TYPE_GYROSCOPE.
SENSOR_TYPE_GEOMAGNETIC_FIELD
- HARUS memiliki rentang pengukuran minimal antara -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 yang tidak di atas 0,5 uT.
SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED dengan persyaratan kualitas yang sama seperti SENSOR_TYPE_GEOMAGNETIC_FIELD dan selain itu:
- HARUS mengimplementasikan bentuk non-bangun dari sensor ini dengan kemampuan buffering minimal 600 peristiwa sensor.
SENSOR_TYPE_PRESSURE
- HARUS memiliki rentang pengukuran minimal antara 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 yang tidak lebih dari 2 Pa/✓Hz.
- HARUS mengimplementasikan bentuk non-bangun dari sensor ini dengan kemampuan buffering minimal 300 peristiwa sensor.
- HARUS memiliki konsumsi daya pengelompokan tidak lebih buruk dari 2 mW.
SENSOR_TYPE_GAME_ROTATION_VECTOR
- HARUS mengimplementasikan bentuk non-bangun dari sensor ini dengan kemampuan buffering minimal 300 peristiwa sensor.
- HARUS memiliki konsumsi daya pengelompokan 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 mengimplementasikan bentuk non-bangun dari 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 semacam itu HARUS memenuhi persyaratan subsistem sensor berikut:

Stempel waktu peristiwa untuk peristiwa fisik yang sama yang dilaporkan oleh Akselerometer, sensor Giroskop, dan Magnetometer HARUS dalam waktu 2,5 milidetik satu sama lain.
Stempel waktu peristiwa sensor Giroskop HARUS pada basis waktu yang sama dengan subsistem kamera dan dalam waktu 1 milidetik jika terjadi error.
Sensor Fidelitas Tinggi HARUS mengirimkan sampel ke aplikasi dalam waktu 5 milidetik sejak data tersedia di sensor fisik ke aplikasi.
Konsumsi daya TIDAK BOLEH lebih tinggi dari 0,5 mW saat perangkat statis dan 2,0 mW saat perangkat bergerak jika kombinasi apa pun dari sensor berikut diaktifkan:
- SENSOR_TYPE_SIGNIFICANT_MOTION
- SENSOR_TYPE_STEP_DETECTOR
- SENSOR_TYPE_STEP_COUNTER
- SENSOR_TILT_DETECTOR

Perhatikan bahwa semua persyaratan konsumsi daya di bagian ini tidak mencakup konsumsi daya Prosesor Aplikasi. Jumlah ini mencakup daya yang diambil oleh seluruh rantai sensor—sensor, sirkuit pendukung, sistem pemrosesan sensor khusus, dll.

Jenis sensor berikut mungkin juga didukung pada implementasi perangkat yang mendeklarasikan android.hardware.sensor.hifi_sensors, tetapi jika ada jenis sensor ini, 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 SEHARUSNYA 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 menerapkan API yang sesuai sepenuhnya seperti yang dijelaskan dalam dokumentasi Android SDK.
HARUS memiliki tingkat penerimaan palsu yang tidak lebih tinggi dari 0,002%.
SANGAT DIREKOMENDASIKAN untuk memiliki rasio penolakan palsu kurang dari 10%, seperti yang diukur di perangkat
SANGAT DIREKOMENDASIKAN untuk memiliki latensi di bawah 1 detik, yang diukur dari saat sensor sidik jari disentuh hingga layar tidak terkunci, untuk satu jari yang terdaftar.
HARUS mencoba batas kapasitas minimal selama 30 detik setelah lima uji coba palsu untuk verifikasi sidik jari.
HARUS memiliki implementasi keystore yang didukung hardware, dan melakukan pencocokan sidik jari di Trusted Execution Environment (TEE) atau pada chip dengan saluran yang 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 Proyek Open Source Android.
HARUS mencegah penambahan sidik jari tanpa terlebih dahulu membuat rantai kepercayaan dengan meminta pengguna mengonfirmasi keberadaan atau menambahkan kredensial perangkat baru (PIN/pola/sandi) yang diamankan oleh TEE; implementasi Proyek Open Source Android menyediakan mekanisme dalam kerangka kerja untuk melakukannya.
TIDAK BOLEH mengaktifkan aplikasi pihak ketiga untuk membedakan antara masing-masing sidik jari.
HARUS mematuhi tanda Device disusupi.KEYGUARD_DISABLE_FINGERPRINT.
Jika diupgrade dari versi yang lebih lama dari Android 6.0, data sidik jari harus dimigrasikan dengan aman agar memenuhi persyaratan di atas atau dihapus.
HARUS menggunakan ikon Sidik Jari Android yang disediakan di Project Open Source Android.

7.3.11. Sensor khusus Android Automotive

Sensor khusus otomotif ditentukan dalam android.car.CarSensorManager API .

7.3.11.1. Roda Gigi Saat Ini

Implementasi Android Automotive HARUS menyediakan roda gigi saat ini sebagai SENSOR_TYPE_GEAR.

7.3.11.2. Mode Siang/Malam

Implementasi Android Automotive HARUS mendukung mode siang/malam yang ditentukan sebagai SENSOR_TYPE_NIGHT. Nilai tanda ini HARUS konsisten dengan mode siang/malam dasbor dan HARUS didasarkan pada input sensor cahaya sekitar. Sensor cahaya sekitar yang mendasarinya MUNGKIN sama dengan Photometer.

7.3.11.3. Status Mengemudi

Implementasi Android Automotive HARUS mendukung status mengemudi yang ditetapkan sebagai SENSOR_TYPE_DRIVING_STATUS, dengan nilai default Drive_STATUS_UNLIMITED saat kendaraan berhenti dan diparkir sepenuhnya. Produsen perangkat bertanggung jawab untuk mengonfigurasi SENSOR_TYPE_DRIVING_STATUS sesuai dengan semua hukum dan peraturan yang berlaku di pasar tempat produk tersebut dikirimkan.

7.3.11.4. Kecepatan Roda

Implementasi Android Automotive HARUS memberikan kecepatan kendaraan yang ditetapkan sebagai SENSOR_TYPE_CAR_SPEED.

7.3.12. Sensor Pose

Implementasi perangkat MUNGKIN mendukung sensor pose dengan 6 derajat kebebasan. Perangkat Genggam Android DIREKOMENDASIKAN untuk mendukung sensor ini. Jika implementasi perangkat mendukung sensor pose dengan 6 derajat kebebasan, implementasi tersebut:

HARUS menerapkan dan melaporkan sensor TYPE_POSE_6DOF.
HARUS lebih akurat daripada vektor rotasi saja.

7.4. Konektivitas Data

7.4.1. Telepon

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

Android MUNGKIN digunakan pada perangkat yang tidak termasuk hardware telepon. Artinya, Android kompatibel dengan perangkat selain ponsel. Namun, jika implementasi perangkat menyertakan telepon GSM atau CDMA, implementasi harus mengimplementasikan dukungan penuh bagi API untuk teknologi tersebut. Implementasi perangkat yang tidak menyertakan hardware telepon HARUS mengimplementasikan API lengkap sebagai tanpa pengoperasian.

7.4.1.1. Kompatibilitas Pemblokiran Nomor

Implementasi perangkat Telepon Android HARUS menyertakan dukungan pemblokiran nomor dan:

HARUS sepenuhnya mengimplementasikan BlockedNumberContract dan API yang sesuai seperti yang dijelaskan dalam dokumentasi SDK.
HARUS memblokir semua panggilan dan pesan dari nomor telepon di 'BlockedNumberProvider' tanpa interaksi apa pun dengan aplikasi. Satu-satunya pengecualian adalah saat pemblokiran nomor dihentikan sementara seperti yang dijelaskan dalam dokumentasi SDK.
TIDAK BOLEH menulis ke penyedia log panggilan platform untuk panggilan yang diblokir.
TIDAK BOLEH menulis ke Penyedia telepon untuk pesan yang diblokir.
HARUS mengimplementasikan UI pengelolaan nomor yang diblokir, yang dibuka dengan intent yang ditampilkan oleh metode TelecomManager.createManageBlockedNumbersIntent().
TIDAK BOLEH mengizinkan pengguna sekunder untuk melihat atau mengedit nomor yang diblokir di perangkat karena platform Android beranggapan bahwa pengguna utama memiliki kontrol penuh atas layanan telepon, satu instance, pada perangkat. Semua UI terkait pemblokiran HARUS disembunyikan untuk pengguna sekunder dan daftar yang diblokir HARUS tetap dipatuhi.
HARUS migrasikan nomor yang diblokir ke penyedia saat perangkat diupdate ke Android 7.0.

7.4.2. IEEE 802.11 (Wi-Fi)

Semua implementasi perangkat Android HARUS menyertakan dukungan untuk satu atau beberapa bentuk 802.11. Jika implementasi perangkat menyertakan dukungan untuk 802.11 dan mengekspos fungsionalitas ke aplikasi pihak ketiga, implementasi tersebut HARUS mengimplementasikan Android API yang sesuai dan:

HARUS melaporkan tanda fitur hardware android.hardware.wifi.
HARUS mengimplementasikan multicast API seperti yang dijelaskan dalam dokumentasi SDK.
HARUS mendukung multicast DNS (mDNS) dan TIDAK BOLEH memfilter paket mDNS (224.0.0.251) setiap saat operasi termasuk:
- Bahkan saat layar tidak dalam status aktif.
- Untuk implementasi perangkat Android Televisi, bahkan saat dalam status daya standby.

7.4.2.1. Wi-Fi Direct

Penerapan perangkat HARUS menyertakan dukungan untuk Wi-Fi Langsung (Wi-Fi peer-to-peer). Jika implementasi perangkat menyertakan dukungan untuk Wi-Fi Langsung, implementasi tersebut HARUS mengimplementasikan Android API yang sesuai seperti yang dijelaskan dalam dokumentasi SDK. Jika implementasi perangkat menyertakan dukungan untuk Wi-Fi Langsung, implementasi tersebut:

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

7.4.2.2. Pengaturan Wi-Fi Tunneled Direct Link

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

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

7.4.3. Bluetooth

Implementasi Android Watch HARUS mendukung Bluetooth. Implementasi Android Television HARUS mendukung Bluetooth dan Bluetooth LE. Implementasi Android Automotive HARUS mendukung Bluetooth dan SEHARUSNYA mendukung Bluetooth LE.

Implementasi perangkat yang mendukung fitur android.hardware.vr.high_performance HARUS mendukung Bluetooth 4.2 dan Ekstensi Panjang Data Bluetooth LE.

Android menyertakan dukungan untuk Bluetooth dan Bluetooth Energi Rendah. 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. yang sesuai untuk perangkat.

Implementasi Android Automotive HARUS mendukung Message Access Profile (MAP). Implementasi Android Automotive HARUS mendukung profil Bluetooth berikut:

Panggilan telepon melalui Profil Hands-Free (HFP).
Pemutaran media melalui Profil Distribusi Audio (A2DP).
Kontrol pemutaran media atas Profil Remote Control (AVRCP).
Berbagi kontak menggunakan Profil Akses Buku Telepon (PBAP).

Implementasi perangkat termasuk dukungan untuk Bluetooth Hemat Energi:

HARUS mendeklarasikan fitur hardware android.hardware.bluetooth_le.
HARUS mengaktifkan Bluetooth API berbasis GATT (profil atribut umum) seperti yang dijelaskan dalam dokumentasi SDK dan android.bluetooth.
SANGAT DIREKOMENDASIKAN untuk mengimplementasikan waktu tunggu Resolvable Private Address (RPA) tidak lebih dari 15 menit dan merotasi alamat pada waktu tunggu untuk melindungi privasi pengguna.
HARUS mendukung pemindahan logika pemfilteran ke chipset bluetooth saat menerapkan ScanFilter API, dan HARUS melaporkan nilai yang benar terkait tempat logika pemfilteran diterapkan setiap kali dikueri melalui metode android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported().
HARUS mendukung pemindahan pemindaian batch ke chipset bluetooth, tetapi jika tidak didukung, HARUS melaporkan 'false' setiap kali dikueri melalui metode android.bluetooth.BluetoothAdapter.isOffloadedScanBatchingSupported().
SEHARUSNYA mendukung multi-iklan dengan minimal 4 slot, tetapi jika tidak didukung, HARUS melaporkan 'false' setiap kali dikueri melalui metode android.bluetooth.BluetoothAdapter.isMultipleAdvertisingmentSupported().

7.4.4. Komunikasi Nirkabel Jarak Dekat

Implementasi perangkat HARUS menyertakan pengirim dan penerima sinyal dan hardware terkait untuk Komunikasi Nirkabel Jarak Dekat (NFC). Jika penerapan perangkat menyertakan hardware NFC dan rencana untuk menyediakannya untuk aplikasi pihak ketiga, maka:

HARUS melaporkan fitur android.hardware.nfc dari metode android.content.pm.PackageManager.hasSystemFeature().
HARUS mampu membaca dan menulis pesan NDEF melalui standar NFC berikut:
- HARUS mampu bertindak sebagai pembaca/penulis Forum NFC (sebagaimana didefinisikan oleh spesifikasi teknis Forum NFC NFCForum-TS-DigitalProtocol-1.0) melalui standar NFC berikut:
  - NfcA (ISO14443-3A)
  - NfcB (ISO14443-3B)
  - NfcF (JIS X 6319-4)
  - IsoDep (ISO 14443-4)
  - Tag Forum NFC Jenis 1, 2, 3, 4 (ditentukan oleh Forum NFC)
- SANGAT DIREKOMENDASIKAN agar dapat membaca dan menulis pesan NDEF serta data mentah melalui standar NFC berikut. Perhatikan bahwa meskipun standar NFC di bawah ini SANGAT DIREKOMENDASIKAN, Compatibility Definition untuk versi mendatang direncanakan untuk mengubahnya menjadi HARUS. Standar ini bersifat opsional dalam versi ini, tetapi akan diwajibkan pada versi mendatang. Perangkat lama dan baru yang menjalankan versi Android ini sangat dianjurkan untuk memenuhi persyaratan tersebut sekarang agar dapat melakukan upgrade ke rilis platform mendatang.
  - NfcV (ISO 15693)
- HARUS mampu membaca kode batang dan URL (jika dienkode) produk Thinfilm NFC Barcode.
- HARUS mampu mengirimkan dan menerima data melalui standar dan protokol peer-to-peer berikut:
  - ISO 18092
  - LLCP 1.2 (ditentukan oleh Forum NFC)
  - SDP 1.0 (ditentukan oleh Forum NFC)
  - Protokol Push NDEF
  - SNEP 1.0 (ditentukan oleh Forum NFC)
- HARUS menyertakan dukungan untuk Android Beam.
- HARUS mengimplementasikan server default SNEP. Pesan NDEF valid yang diterima oleh server SNEP default HARUS dikirim ke aplikasi yang 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.
- HARUS mengimplementasikan server NPP. Pesan yang diterima oleh server NPP HARUS diproses dengan cara yang sama seperti server default SNEP.
- HARUS menerapkan klien SNEP dan berupaya mengirim P2P NDEF keluar ke server SNEP default saat Android Beam diaktifkan. Jika tidak ada server SNEP default yang ditemukan, klien HARUS mencoba untuk mengirim ke server NPP.
- HARUS mengizinkan aktivitas latar depan untuk menyetel pesan NDEF P2P keluar menggunakan android.nfc.NfcAdapter.setNdefPushMessage, dan android.nfc.NfcAdapter.setNdefPushMessageCallback, serta android.nfc.NfcAdapter.enableForegroundNdefPush.
- HARUS menggunakan gestur atau konfirmasi di layar, seperti 'Sentuh untuk Melakukan Beam', sebelum mengirim pesan P2P NDEF keluar.
- HARUS mengaktifkan Android Beam secara default dan HARUS dapat mengirim serta menerima menggunakan Android Beam, meskipun mode P2p NFC eksklusif lainnya diaktifkan.
- HARUS mendukung pengalihan Koneksi NFC ke Bluetooth jika perangkat mendukung Profil Dorong Objek Bluetooth. Implementasi perangkat HARUS mendukung pengalihan koneksi ke Bluetooth saat menggunakan android.nfc.NfcAdapter.setBeamPushUris, dengan menerapkan spesifikasi “ Connection Handover version 1.2 ” dan “ Bluetooth Secure Simple Pairing Using NFC versi 1.0 ” dari Forum NFC. Implementasi tersebut HARUS menerapkan layanan LLCP penyerahan dengan nama layanan “urn:nfc:sn:handover” untuk menukar permintaan pengalihan/kumpulan data pilihan melalui NFC, dan HARUS menggunakan Profil Dorong Objek Bluetooth untuk transfer data Bluetooth yang sebenarnya. Untuk alasan lama (agar tetap kompatibel dengan perangkat Android 4.1), penerapan HARUS tetap menerima permintaan SNEP GET untuk menukar data pilihan/permintaan serah terima melalui NFC. Namun, penerapan itu sendiri TIDAK BOLEH mengirim permintaan SNEP GET untuk melakukan pengalihan koneksi.
- HARUS melakukan polling untuk semua teknologi yang didukung saat dalam mode penemuan NFC.
- HARUS berada dalam mode penemuan NFC saat perangkat aktif dengan layar aktif dan layar kunci tidak terkunci.

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

Android menyertakan dukungan untuk mode NFC Host Card Emulation (HCE). Jika penerapan perangkat menyertakan chipset pengontrol NFC yang mendukung HCE (untuk NfcA dan/atau NfcB) dan mendukung perutean ID Aplikasi (AID), maka penerapan tersebut:

HARUS melaporkan konstanta fitur android.hardware.nfc.hce.
HARUS mendukung NFC HCE API seperti yang ditentukan di Android SDK.

Jika penerapan perangkat menyertakan chipset pengontrol NFC yang mendukung HCE untuk NfcF, dan menerapkan fitur tersebut untuk aplikasi pihak ketiga, penerapan fitur tersebut akan:

HARUS melaporkan konstanta fitur android.hardware.nfc.hcef.
HARUS menerapkan NfcF Card Emulation API seperti yang ditetapkan di Android SDK.

Selain itu, penerapan perangkat MUNGKIN menyertakan dukungan pembaca/penulis untuk teknologi MIFARE berikut.

MIFARE Klasik
Ultra ringan MIFARE
NDEF di MIFARE Klasik

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(). Perhatikan bahwa ini bukan fitur Android standar, dan karenanya tidak muncul sebagai konstanta di class android.content.pm.PackageManager.
TIDAK BOLEH menerapkan API Android yang sesuai atau melaporkan fitur com.nxp.mifare, kecuali jika fitur tersebut juga menerapkan 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(), dan HARUS menerapkan Android NFC API sebagai tanpa pengoperasian.

Karena class android.nfc.NdefMessage dan android.nfc.NdefRecord mewakili format representasi data yang tidak bergantung 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/dtk atau lebih besar. Contoh teknologi yang memenuhi persyaratan ini mencakup EDGE, HSPA, EV-DO, 802.11g, Ethernet, Bluetooth PAN, dll.

Implementasi perangkat dengan standar jaringan fisik (seperti Eternet) sebagai koneksi data utama SEHARUSNYA juga menyertakan dukungan untuk setidaknya satu standar data nirkabel yang 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 yang dikelola, seperti java.net.Socket dan java.net.URLConnection , serta API native, seperti soket AF_INET6. Tingkat dukungan IPv6 yang diperlukan bergantung pada jenis jaringan, seperti berikut:

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

IPv6 HARUS diaktifkan secara default.

Untuk memastikan bahwa komunikasi IPv6 dapat diandalkan seperti IPv4, paket IPv6 unicast yang dikirim ke perangkat TIDAK BOLEH dibuang, bahkan ketika layar tidak dalam keadaan aktif. Paket IPv6 multicast yang redundan, seperti Iklan Router identik berulang, MUNGKIN dibatasi kapasitasnya pada hardware atau firmware jika hal itu diperlukan untuk menghemat daya. Dalam kasus tersebut, pembatasan kapasitas TIDAK BOLEH menyebabkan perangkat kehilangan konektivitas IPv6 pada jaringan yang mematuhi IPv6 yang menggunakan masa aktif RA minimal 180 detik.

Konektivitas IPv6 HARUS dipertahankan dalam mode istirahatkan.

7.4.6. Setelan Sinkronisasi

Penerapan perangkat HARUS mengaktifkan setelan sinkronisasi otomatis master secara default agar metode getMasterSyncAutomatically() menampilkan “true”.

7.4.7. Penghemat Data

Implementasi perangkat dengan koneksi berkuota SANGAT DIREKOMENDASIKAN untuk menyediakan mode penghemat data.

Jika implementasi perangkat menyediakan mode penghemat data, implementasi tersebut:

HARUS mendukung semua API di class ConnectivityManager seperti yang dijelaskan dalam dokumentasi SDK
HARUS menyediakan antarmuka pengguna di setelan, yang memungkinkan pengguna menambahkan aplikasi ke atau menghapus aplikasi dari daftar yang diizinkan.

Sebaliknya, jika implementasi perangkat tidak menyediakan mode penghemat data, penerapan tersebut:

HARUS menampilkan nilai RESTRICT_BACKGROUND_STATUS_DISABLED untuk ConnectivityManager.getRestrictBackgroundStatus()
HARUS tidak menyiarkan ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED
HARUS memiliki aktivitas yang menangani intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, tetapi DAPAT menerapkannya sebagai tanpa pengoperasian.

7.5. Kamera

Implementasi perangkat HARUS menyertakan kamera belakang dan MUNGKIN menyertakan kamera depan. Kamera belakang adalah kamera yang terletak pada sisi perangkat di seberang layar; yaitu, gambar pemandangan 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 membuat gambar pengguna, seperti untuk konferensi video dan aplikasi serupa.

Jika implementasi perangkat menyertakan setidaknya satu kamera, aplikasi HARUS secara bersamaan mengalokasikan 3 bitmap RGBA_8888 yang sama dengan ukuran gambar yang dihasilkan oleh sensor kamera beresolusi terbesar pada perangkat, saat kamera terbuka untuk keperluan pratinjau dasar dan masih menangkap.

7.5.1. Kamera Belakang

Implementasi perangkat SEHARUSNYA menyertakan kamera belakang. Jika penerapan perangkat menyertakan setidaknya satu kamera belakang, penerapan tersebut:

HARUS melaporkan tombol fitur android.hardware.camera dan android.hardware.camera.any.
HARUS memiliki resolusi minimal 2 megapiksel.
HARUS menerapkan fokus otomatis hardware atau fokus otomatis software di driver kamera (transparan untuk software aplikasi).
MUNGKIN memiliki hardware fokus tetap atau EDOF (extended depth of field).
MUNGKIN menyertakan flash. Jika Kamera menyertakan flash, lampu flash TIDAK BOLEH menyala saat instance android.hardware.Camera.PreviewCallback telah didaftarkan pada platform pratinjau Kamera, kecuali jika aplikasi telah mengaktifkan flash secara eksplisit 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 MUNGKIN mencakup kamera depan. Jika penerapan perangkat menyertakan setidaknya satu kamera depan, penerapan tersebut:

HARUS melaporkan tombol 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 kamera tersebut adalah satu-satunya kamera pada perangkat.
DAPAT mencakup fitur (seperti fokus otomatis, flash, dll.) yang tersedia untuk kamera belakang seperti yang dijelaskan di bagian 7.5.1.
HARUS mencerminkan secara horizontal (yaitu mencerminkan) streaming yang ditampilkan oleh aplikasi di CameraPreview, sebagai berikut:
- Jika implementasi perangkat dapat diputar oleh pengguna (seperti secara otomatis melalui akselerometer atau secara manual melalui input pengguna), pratinjau kamera HARUS dicerminkan secara horizontal sesuai dengan orientasi perangkat saat ini.
- Jika aplikasi saat ini telah secara eksplisit meminta agar tampilan Kamera diputar melalui panggilan ke metode android.hardware.Camera.setDisplayOrientation(), pratinjau kamera HARUS dicerminkan secara horizontal sesuai dengan orientasi yang ditentukan oleh aplikasi.
- Jika tidak, pratinjau HARUS dicerminkan di sepanjang sumbu horizontal default perangkat.
HARUS mencerminkan gambar yang ditampilkan oleh tayangan postingan dengan cara yang sama seperti streaming gambar pratinjau kamera. Jika implementasi perangkat tidak mendukung postback, persyaratan ini jelas tidak berlaku.
TIDAK BOLEH mencerminkan streaming video atau gambar diam akhir yang diambil, yang dikembalikan ke callback aplikasi atau di-commit untuk penyimpanan media.

7.5.3. Kamera Eksternal

Penerapan perangkat MUNGKIN mencakup dukungan untuk kamera eksternal yang tidak selalu terhubung. Jika perangkat menyertakan dukungan untuk kamera eksternal, perangkat:

HARUS mendeklarasikan tombol fitur platform android.hardware.camera.external dan android.hardware camera.any .
MUNGKIN mendukung beberapa kamera.
HARUS mendukung USB Video Class (UVC 1.0 atau yang lebih baru) jika kamera eksternal terhubung melalui port USB.
HARUS mendukung kompresi video seperti MJPEG untuk mengaktifkan transfer streaming berkualitas tinggi yang tidak dienkode (yaitu streaming gambar mentah atau yang dikompresi secara terpisah).
Mungkin mendukung encoding video berbasis kamera. Jika didukung, streaming MJPEG / yang tidak dienkode secara bersamaan (resolusi QVGA atau lebih besar) HARUS dapat diakses oleh implementasi perangkat.

7.5.4. Perilaku Camera API

Android menyertakan dua paket API untuk mengakses kamera. API android.hardware.camera2 yang lebih baru mengekspos kontrol kamera tingkat rendah ke aplikasi, termasuk alur burst/streaming nol salinan yang efisien serta kontrol eksposur, penguatan, keseimbangan white balance, konversi warna, denoise, penajaman, dan lainnya.

Paket API lama, android.hardware.Camera, ditandai sebagai tidak digunakan lagi di Android 5.0, namun masih akan tersedia bagi aplikasi yang menggunakan implementasi perangkat Android HARUS memastikan dukungan berkelanjutan atas API 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() lebih lanjut harus dalam format encoding NV21. Artinya, NV21 HARUS menjadi default.
Untuk android.hardware.Camera, implementasi perangkat HARUS mendukung format YV12 (sebagaimana ditandai dengan konstanta android.graphics.ImageFormat.YV12) untuk pratinjau kamera bagi kamera depan dan belakang. (Encoder dan kamera video hardware dapat menggunakan format piksel native apa pun, tetapi implementasi 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 API android.media.ImageReader.

Implementasi perangkat HARUS tetap menerapkan Camera API lengkap yang disertakan dalam dokumentasi Android SDK, terlepas dari apakah perangkat menyertakan fokus otomatis hardware atau kemampuan lainnya. Misalnya, kamera yang tidak memiliki fokus otomatis HARUS memanggil instance android.hardware.Camera.AutoFocusCallback apa pun yang terdaftar (meskipun ini tidak memiliki relevansi 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 tetap harus "palsu" seperti yang dijelaskan.

Implementasi perangkat HARUS mengenali dan mematuhi setiap nama parameter yang ditetapkan sebagai konstanta di class android.hardware.Camera.Parameters, jika hardware yang mendasarinya mendukung fitur tersebut. Jika hardware perangkat tidak mendukung suatu fitur, API harus berperilaku seperti yang didokumentasikan. Sebaliknya, implementasi perangkat TIDAK BOLEH mengikuti 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.

Karena tidak semua implementasi perangkat dapat sepenuhnya mendukung semua fitur API android.hardware.camera2, implementasi perangkat HARUS melaporkan tingkat dukungan yang sesuai dengan properti android.info.supportedHardwareLevel seperti yang dijelaskan dalam Android SDK dan melaporkan flag fitur framework yang sesuai.

Implementasi perangkat juga HARUS mendeklarasikan kemampuan kamera individualnya android.hardware.camera2 melalui properti android.request.availableKeahlian dan mendeklarasikan tombol fitur yang sesuai; sebuah perangkat harus menentukan tombol fitur jika ada perangkat kamera yang terpasang mendukung fitur tersebut.

Implementasi perangkat HARUS menyiarkan intent Camera.ACTION_NEW_PICTURE setiap kali gambar baru diambil oleh kamera dan entri gambar 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. Ini berlaku terlepas dari orientasi alami perangkat; yaitu, hal ini berlaku untuk perangkat utama lanskap serta perangkat utama potret.

7.6. Memori dan Penyimpanan

7.6.1 Memori dan Penyimpanan Minimum

Perangkat Android Television HARUS memiliki minimal 4 GB penyimpanan non-volatil yang tersedia untuk data pribadi aplikasi.

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

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

Nilai memori minimum HARUS merupakan tambahan untuk setiap ruang memori yang sudah didedikasikan untuk komponen perangkat keras seperti radio, video, dan seterusnya yang tidak berada di bawah kontrol {i>kernel<i}.

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

Perangkat Android Television HARUS memiliki minimal 4 GB dan implementasi perangkat lainnya HARUS memiliki penyimpanan non-volatil minimal 3 GB yang tersedia untuk data pribadi aplikasi. Artinya, partisi /data HARUS berukuran minimal 4 GB untuk perangkat Android Television dan setidaknya 3 GB untuk implementasi perangkat lainnya. Implementasi perangkat yang menjalankan Android SANGAT DIREKOMENDASIKAN untuk memiliki setidaknya 4 GB penyimpanan non-volatil untuk data pribadi aplikasi agar dapat diupgrade ke rilis platform mendatang.

Android API menyertakan Pengelola Download yang MUNGKIN digunakan aplikasi untuk mendownload file data. Implementasi perangkat Pengelola Download HARUS dapat mendownload file individual berukuran minimal 100 MB ke lokasi “cache” default.

7.6.2. Penyimpanan Bersama Aplikasi

Implementasi perangkat HARUS menawarkan penyimpanan bersama untuk aplikasi yang sering disebut sebagai "penyimpanan eksternal bersama".

Implementasi perangkat HARUS dikonfigurasi dengan penyimpanan bersama yang dipasang secara default, "siap pakai". Jika penyimpanan bersama tidak dipasang pada Linuxpath /sdcard, perangkat HARUS menyertakan link simbolis Linux dari /sdcard ke direktori pemasangan yang sebenarnya.

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

HARUS menerapkan antarmuka pengguna toast atau pop-up yang memperingatkan pengguna saat tidak ada kartu SD.
HARUS menyertakan kartu SD berformat FAT berukuran 1GB atau lebih besar ATAU yang ditunjukkan di kotak dan materi lain yang tersedia pada saat pembelian, sehingga 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 dan implementasi perangkat lunak ini. Jika implementasi perangkat menggunakan penyimpanan internal (tidak dapat dilepas) untuk memenuhi persyaratan penyimpanan bersama, sementara penyimpanan tersebut MUNGKIN berbagi ruang dengan data pribadi aplikasi, perangkat HARUS berukuran setidaknya 1GB 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 pada penyimpanan bersama ini, sebagaimana yang didokumentasikan. Penyimpanan bersama HARUS dapat ditulis oleh semua aplikasi yang mendapatkan izin tersebut.

Implementasi perangkat yang menyertakan beberapa jalur penyimpanan bersama (seperti slot kartu SD dan penyimpanan internal bersama) HARUS mengizinkan penginstalan sebelumnya & aplikasi Android dengan hak istimewa 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 kedua 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 MUNGKIN menggunakan penyimpanan massal USB, tetapi HARUS menggunakan Media Transfer Protocol untuk memenuhi persyaratan ini. Jika implementasi perangkat mendukung Media Transfer Protocol, implementasi tersebut:

HARUS kompatibel dengan host MTP Android referensi, Android File Transfer.
HARUS melaporkan kelas perangkat USB 0x00.
HARUS melaporkan nama antarmuka USB 'MTP'.

7.6.3. Penyimpanan yang Dapat Diadopsi

Implementasi perangkat SANGAT DIREKOMENDASIKAN untuk menerapkan penyimpanan yang dapat diadopsi jika port perangkat penyimpanan yang dapat dilepas berada di lokasi stabil jangka panjang, seperti di dalam kompartemen baterai atau penutup pelindung lainnya.

Implementasi perangkat seperti televisi, MUNGKIN memungkinkan adopsi melalui port USB karena perangkat diharapkan bersifat statis, bukan seluler. Namun, untuk implementasi perangkat lain yang bersifat seluler, SANGAT DIREKOMENDASIKAN untuk mengimplementasikan penyimpanan yang dapat diadopsi di lokasi yang stabil untuk jangka panjang, karena secara tidak sengaja memutuskan koneksi dapat menyebabkan kehilangan/kerusakan data.

7.7. USB

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

7.7.1 Mode periferal USB

Jika implementasi perangkat menyertakan port USB yang mendukung mode periferal:

Port HARUS dapat dihubungkan ke host USB yang memiliki port USB tipe-A atau tipe-C standar.
Port HARUS menggunakan faktor bentuk USB mikro-B, mikro-AB, atau Tipe-C. Perangkat Android lama dan baru DIREKOMENDASIKAN untuk memenuhi persyaratan ini sehingga dapat diupgrade ke rilis platform mendatang.
Port SEHARUSNYA berada di bagian bawah perangkat (sesuai dengan orientasi alami) atau mengaktifkan rotasi layar software untuk semua aplikasi (termasuk layar utama), sehingga tampilan menggambar dengan benar saat perangkat diorientasikan dengan port di bagian bawah. Perangkat Android lama dan baru DIREKOMENDASIKAN untuk memenuhi persyaratan ini sehingga dapat diupgrade ke rilis platform mendatang.
Ini HARUS mengizinkan host USB yang terhubung dengan perangkat Android untuk mengakses konten volume penyimpanan bersama menggunakan penyimpanan massal USB atau Media Transfer Protocol.
Aplikasi HARUS menerapkan Android Open Accessory API (AOA) dan spesifikasi seperti yang didokumentasikan dalam dokumentasi Android SDK, dan jika berupa perangkat Genggam Android, aplikasi HARUS menerapkan AOA API. Implementasi perangkat yang menerapkan spesifikasi AOA:
- HARUS mendeklarasikan dukungan untuk fitur hardware android.hardware.usb.accessory.
- HARUS menerapkan class audio USB seperti yang didokumentasikan dalam dokumentasi Android SDK.
- Kelas penyimpanan massal USB HARUS menyertakan string "android" di akhir deskripsi antarmuka iInterface string penyimpanan massal USB
Perangkat ini HARUS mengimplementasikan dukungan untuk menggambar arus 1,5 A selama kicauan dan traffic HS seperti yang ditentukan dalam spesifikasi Pengisian Daya Baterai USB, revisi 1.2. Perangkat Android baru dan lama DIREKOMENDASIKAN untuk memenuhi persyaratan ini sehingga dapat diupgrade ke rilis platform mendatang.
Perangkat Tipe-C HARUS mendeteksi pengisi daya 1,5A dan 3,0A per standar resistor Tipe-C dan harus mendeteksi perubahan dalam iklan.
Perangkat Type-C yang juga mendukung mode host USB SANGAT DIREKOMENDASIKAN untuk mendukung Pengiriman Daya untuk pertukaran peran data dan daya.
Perangkat Tipe-C HARUS mendukung Pengiriman Daya untuk pengisian daya voltase tinggi dan dukungan untuk Mode Alternatif seperti layar keluar.
Nilai iSerialNumber di deskriptor perangkat standar USB HARUS sama dengan nilai android.os.Build.SERIAL.
Perangkat Type-C SANGAT DIREKOMENDASIKAN untuk tidak mendukung metode pengisian daya eksklusif yang memodifikasi voltase Vbus di luar level default, atau mengubah peran sink/sumber sehingga dapat mengakibatkan masalah interoperabilitas dengan pengisi daya atau perangkat yang mendukung metode Pengiriman Daya USB standar. Meskipun hal ini disebut "SANGAT DIREKOMENDASIKAN", dalam versi Android mendatang, kami mungkin MEMERLUKAN semua perangkat type-C untuk mendukung interoperabilitas penuh dengan pengisi daya type-C standar.

7.7.2. Mode host USB

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

HARUS menggunakan port USB tipe-C, jika implementasi perangkat mendukung USB 3.1.
MUNGKIN 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.
MUNGKIN menggunakan port USB mikro-AB, tetapi jika demikian HARUS kirimkan dengan kabel atau kabel yang menyesuaikan port ke port USB tipe-A atau tipe-C standar.
DIREKOMENDASIKAN untuk menerapkan class audio USB seperti yang didokumentasikan dalam dokumentasi Android SDK.
HARUS mengimplementasikan API host USB Android seperti yang didokumentasikan dalam Android SDK, dan HARUS mendeklarasikan dukungan untuk fitur hardware android.hardware.usb.host.
HARUS mendukung pengisian daya perangkat saat dalam mode host; mengiklankan arus sumber minimal 1, 5A sebagaimana ditentukan di bagian Parameter Penghentian pada [Revisi Spesifikasi Kabel USB Type-C dan Konektor 1.2] (http://www.usb.org/developers/docs/usb_31_021517.zip) untuk konektor USB Type-C atau menggunakan rentang saat ini output Pengisian Daya Downstream Port(CDP) sebagaimana ditentukan dalam spesifikasi revisi Pengisian Daya Baterai Mikro1 untuk spesifikasi revisi AB2 untuk konektor USB Type-C.

Perangkat USB Type-C SANGAT DIREKOMENDASIKAN untuk mendukung DisplayPort, HARUS mendukung Kecepatan Data Super Kecepatan USB, dan SANGAT DIREKOMENDASIKAN untuk mendukung Pengiriman Daya untuk pertukaran data dan peran daya.

Perangkat dengan port tipe-A atau tipe-AB TIDAK BOLEH dikirim dengan adaptor yang dikonversi dari port ini ke stopkontak tipe-C.

HARUS mengenali perangkat MTP (Media Transfer Protocol) yang terhubung dari jarak jauh dan membuat kontennya dapat diakses melalui intent ACTION_GET_CONTENT , ACTION_OPEN_DOCUMENT , dan ACTION_CREATE_DOCUMENT, jika Storage Access Framework (SAF) didukung.

HARUS, jika menggunakan port USB Type-C dan termasuk dukungan untuk mode periferal, terapkan fungsi Dual Role Port sebagaimana ditetapkan oleh spesifikasi USB Type-C (bagian 4.5.1.3.3).

SEHARUSNYA, jika fungsi Dual Role Port didukung, terapkan model Coba.* yang paling sesuai untuk faktor bentuk perangkat. Misalnya, perangkat genggam SEHARUSNYA menerapkan model Coba.SNK.

7.8. Audio

7.8.1. Mikrofon

Implementasi Perangkat Genggam Android, Smartwatch, dan Otomotif HARUS menyertakan mikrofon.

Implementasi perangkat MUNGKIN menghilangkan mikrofon. Namun, jika implementasi perangkat menghilangkan mikrofon, implementasi tersebut TIDAK BOLEH melaporkan konstanta fitur android.hardware.signal, dan HARUS mengimplementasikan API perekaman audio setidaknya sebagai tanpa pengoperasian, sesuai dengan bagian 7. Sebaliknya, implementasi perangkat yang memiliki mikrofon:

HARUS melaporkan konstanta fitur android.hardware.Mikrofon.
HARUS memenuhi persyaratan perekaman audio di pasal 5.4.
HARUS memenuhi persyaratan latensi audio di bagian 5.6.
SANGAT DIREKOMENDASIKAN untuk mendukung perekaman mendekati ultrasonik seperti yang dijelaskan dalam bagian 7.8.3.

7.8.2. Output Audio

Perangkat Android Watch MUNGKIN menyertakan output audio.

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

HARUS melaporkan konstanta fitur android.hardware.audio.output.
HARUS memenuhi persyaratan pemutaran audio di pasal 5.5.
HARUS memenuhi persyaratan latensi audio di bagian 5.6.
SANGAT DIREKOMENDASIKAN untuk mendukung pemutaran mendekati ultrasonik seperti dijelaskan dalam 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 mengimplementasikan API terkait Output Audio setidaknya sebagai tanpa operasi.

Implementasi perangkat Android Watch MUNGKIN TIDAK 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, jika implementasi perangkat menyertakan satu atau beberapa port audio analog, setidaknya salah satu port audio HARUS berupa colokan audio 3,5 mm konduktor 4. Jika implementasi perangkat memiliki colokan audio 3,5 mm konduktor 4, maka:

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-out CTIA, dan HARUS mendukung steker audio dengan urutan pin-out OMTP.
HARUS mendukung deteksi mikrofon pada aksesori audio yang dicolokkan, jika penerapan perangkat mendukung mikrofon, dan menyiarkan android.intent.action.HEADSET_PLUG dengan mikrofon nilai ekstra yang disetel sebagai 1.
HARUS mendukung deteksi dan pemetaan ke kode tombol untuk 3 rentang impedansi setara 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
SANGAT DIREKOMENDASIKAN untuk mendeteksi dan memetakan ke kode tombol untuk rentang impedansi setara berikut antara mikrofon dan konduktor pentanahan pada steker audio:
- 110-180 Ohm: KEYCODE_VOICE_ASSIST
HARUS memicu ACTION_HEADSET_PLUG pada steker steker, tetapi hanya setelah semua kontak pada steker menyentuh segmen terkait pada steker.
HARUS mampu mengemudi setidaknya 150mV ± 10% dari tegangan output pada impedansi speaker 32 Ohm.
HARUS memiliki tegangan bias mikrofon antara 1.8V ~ 2.9V.

7.8.3. Dekat Ultrasonik

Audio Near-Ultrasonik adalah pita 18,5 kHz hingga 20 kHz. Implementasi perangkat HARUS melaporkan dengan benar dukungan kemampuan audio yang mendekati ultrasonik melalui AudioManager.getProperty API sebagai berikut:

Jika PROPERTI_SUPPORT_MIC_NEAR_ULTRASOUND adalah "benar", persyaratan berikut harus dipenuhi oleh sumber audio VOICE_RECOGNITION dan UNPROGRESSED:
- Rata-rata respons daya mikrofon dalam band 18,5 kHz hingga 20 kHz HARUS tidak lebih dari 15 dB di bawah respons pada 2 kHz.
- Rasio sinyal tanpa bobot mikrofon terhadap kebisingan di atas 18,5 kHz hingga 20 kHz untuk nada 19 kHz pada -26 dBFS HARUS tidak lebih rendah dari 50 dB.
Jika PROPERTI_SUPPORT_SPEAKER_NEAR_ULTRASOUND bernilai "true", maka respons rata-rata speaker dalam rentang 18,5 kHz - 20 kHz HARUS tidak lebih rendah dari 40 dB di bawah respons pada 2 kHz.

7.9. Virtual Reality

Android menyertakan API dan fasilitas untuk membangun "Virtual Reality" Aplikasi (VR) termasuk pengalaman VR seluler berkualitas tinggi. Implementasi perangkat HARUS menerapkan API dan perilaku ini dengan benar, seperti yang dijelaskan di bagian ini.

7.9.1. Mode Virtual Reality

Implementasi perangkat genggam Android yang mendukung mode untuk aplikasi VR yang menangani rendering notifikasi stereoskopis dan menonaktifkan komponen UI sistem monokular, sementara aplikasi VR memiliki fokus pengguna HARUS mendeklarasikan fitur android.software.vr.mode. Perangkat mendeklarasikan fitur ini HARUS menyertakan aplikasi yang menerapkan android.service.vr.VrListenerService yang dapat diaktifkan oleh aplikasi VR melalui android.app.Activity#setVrModeEnabled .

7.9.2. Performa Tinggi Virtual Reality

Implementasi perangkat genggam Android HARUS mengidentifikasi dukungan virtual reality berperforma tinggi untuk periode pengguna yang lebih lama melalui tombol fitur android.hardware.vr.high_performance dan memenuhi persyaratan berikut.

Implementasi perangkat HARUS memiliki minimal 2 core fisik.
Implementasi perangkat HARUS mendeklarasikan fitur android.software.VR.mode.
Implementasi perangkat DAPAT memberikan inti eksklusif ke aplikasi latar depan dan DAPAT mendukung Process.getEksklusifCores API untuk menampilkan jumlah core CPU yang eksklusif untuk aplikasi latar depan teratas. Jika inti eksklusif didukung, maka inti HARUS tidak mengizinkan proses userspace lain untuk berjalan di dalamnya (kecuali driver perangkat yang digunakan oleh aplikasi), tetapi BISA memungkinkan beberapa proses kernel berjalan sesuai kebutuhan.
Implementasi perangkat HARUS mendukung mode performa berkelanjutan.
Implementasi perangkat HARUS mendukung OpenGL ES 3.2.
Implementasi perangkat HARUS mendukung Hardware Vulkan Level 0 dan SEHARUSNYA mendukung Hardware Vulkan Level 1.
Implementasi perangkat HARUS mengimplementasikan EGL_KHR_mutable_render_buffer dan EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_create_native_client_buffer, EGL_KHR_fence_sync, dan EGL_KHR_wait_sync agar dapat digunakan untuk Mode Buffer Bersama, serta mengekspos ekstensi dalam daftar ekstensi EGL yang tersedia.
GPU dan layar HARUS dapat menyinkronkan akses ke buffer depan bersama sehingga rendering konten VR yang bolak-balik pada konten VR pada 60 fps dengan dua konteks render akan ditampilkan tanpa artefak sobek yang terlihat.
Implementasi perangkat HARUS mengimplementasikan EGL_IMG_context_priority, dan menampilkan ekstensi dalam daftar ekstensi EGL yang tersedia.
Implementasi perangkat HARUS mengimplementasikan GL_EXT_multisampled_render_to_texture, GL_OVR_multiview, GL_OVR_multiview2, dan GL_OVR_multiview_multisampled_render_to_texture, serta menampilkan ekstensi dalam daftar ekstensi GL yang tersedia.
Implementasi perangkat HARUS mengimplementasikan EGL_EXT_Protect_content dan GL_EXT_ dilindungi_textures agar dapat digunakan untuk Pemutaran Video Tekstur Aman, dan mengekspos ekstensi dalam daftar ekstensi EGL dan GL yang tersedia.
Implementasi perangkat HARUS mendukung decoding H.264 setidaknya 3840x2160@30fps-40Mbps (setara dengan 4 instance 1920x1080@30fps-10Mbps atau 2 instance 1920x1080@60fps-20Mbps).
Implementasi perangkat HARUS mendukung HEVC dan VP9, HARUS mampu mendekode setidaknya 1920x1080@30fps-10Mbps dan SEHARUSNYA mampu mendekode 3840x2160@30fps-20Mbps (setara dengan 4 instance 1920x1080@30fps).
Implementasi perangkat SANGAT DIREKOMENDASIKAN untuk mendukung fitur android.hardware.sensor.hifi_sensors dan HARUS memenuhi persyaratan terkait giroskop, akselerometer, dan magnetometer untuk android.hardware.hifi_sensors.
Implementasi perangkat HARUS mendukung HardwarePropertiesManager.getDeviceTemperatures API dan menampilkan nilai yang akurat untuk suhu kulit.
Implementasi perangkat HARUS memiliki layar yang tertanam, dan resolusinya setidaknya HARUS FullHD(1080p) dan SANGAT DIREKOMENDASIKAN UNTUK MENJADI QuadHD (1440p) atau lebih tinggi.
Layar HARUS berukuran antara 4,7" dan 6" diagonal.
Layar HARUS diperbarui minimal 60 Hz saat berada dalam Mode VR.
Latensi tampilan pada waktu peralihan Abu-abu ke Abu-abu, Putih ke Hitam, dan Hitam ke Putih HARUS ≤ 3 md.
Layar HARUS mendukung mode persistensi rendah dengan persistensi ≤5 md,persistensi didefinisikan sebagai jumlah waktu saat sebuah piksel memancarkan cahaya.
Implementasi perangkat HARUS mendukung Ekstensi Panjang Data Bluetooth 4 dan Bluetooth LE pasal 7.4.3.

8. Performa dan Kekuatan

Beberapa kriteria performa dan daya minimum sangat penting untuk pengalaman pengguna dan memengaruhi asumsi dasar pengukuran yang mungkin 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 menyediakan 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 dari 5 frame dalam satu detik, dan HARUS di bawah 1 frame dalam satu detik.
Latensi antarmuka pengguna . Implementasi perangkat HARUS memastikan pengalaman pengguna berlatensi rendah dengan men-scroll daftar 10 ribu entri daftar seperti yang ditentukan oleh Android Compatibility Test Suite (CTS) dalam waktu kurang dari 36 detik.
Pengalihan tugas . Saat beberapa aplikasi diluncurkan, meluncurkan kembali aplikasi yang sudah berjalan setelah diluncurkan HARUS memakan 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 penulisan berurutan setidaknya 5 MB/dtk untuk file 256 MB yang menggunakan buffer tulis 10 MB.
Penulisan acak . Implementasi perangkat HARUS memastikan performa tulis acak setidaknya 0,5MB/dtk untuk file 256MB menggunakan buffer tulis 4KB.
Pembacaan berurutan . Implementasi perangkat HARUS memastikan performa baca berurutan setidaknya 15 MB/dtk untuk file 256 MB yang menggunakan buffer tulis 10 MB.
Pembacaan acak . Implementasi perangkat HARUS memastikan performa baca acak setidaknya 3,5 MB/dtk untuk file 256 MB yang menggunakan buffer tulis 4KB.

8.3. Mode Hemat Daya

Android 6.0 memperkenalkan mode hemat daya Aplikasi Standby dan Istirahatkan untuk mengoptimalkan penggunaan baterai. Semua Aplikasi yang dikecualikan dari mode ini HARUS terlihat oleh pengguna akhir. Selain itu, algoritma pemicu, pemeliharaan, bangun, dan penggunaan setelan sistem global mode hemat daya ini TIDAK BOLEH menyimpang dari Proyek Open Source Android.

Selain mode hemat daya, implementasi perangkat Android DAPAT mengimplementasikan salah satu atau semua 4 status daya tidur seperti yang ditentukan oleh Advanced Configuration and Power Interface (ACPI), tetapi jika mengimplementasikan status daya S3 dan S4, implementasi perangkat hanya dapat memasuki status ini saat menutup penutup yang secara fisik merupakan bagian dari perangkat.

8.4. Akuntansi Pemakaian Daya

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

HARUS dapat melacak penggunaan daya komponen hardware dan atribut yang mendukung penggunaan daya ke aplikasi tertentu. Secara khusus, implementasi:
- HARUS menyediakan profil daya per komponen yang menentukan nilai konsumsi saat ini untuk setiap komponen hardware dan perkiraan pengurasan baterai yang disebabkan oleh komponen dari waktu ke waktu, seperti yang didokumentasikan di situs Project Open Source Android.
- HARUS melaporkan semua nilai konsumsi daya dalam miliampere jam (mAh).
- HARUS dikaitkan dengan 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 implementasi modul kernel uid_cputime.
HARUS menyediakan penggunaan daya ini melalui perintah shell adb shell dumpsys batterystats untuk developer aplikasi.
HARUS mematuhi intent android.intent.action.POWER_USAGE_SUMMARY dan menampilkan menu setelan yang menunjukkan penggunaan daya ini.

8.5. Performa yang Konsisten

Performa dapat berfluktuasi secara dramatis untuk aplikasi berperforma tinggi yang berjalan lama, baik karena aplikasi lain berjalan di latar belakang atau throttling CPU akibat batas suhu. Android menyertakan antarmuka terprogram sehingga jika perangkat mendukung, aplikasi latar depan teratas dapat meminta agar sistem mengoptimalkan alokasi resource untuk mengatasi fluktuasi tersebut.

Implementasi perangkat SEHARUSNYA mendukung Mode Performa Berkelanjutan yang dapat memberikan tingkat performa yang konsisten untuk aplikasi latar depan teratas dalam waktu yang lama jika diminta melalui metode Window.setSustainedPerformanceMode() API. Implementasi Perangkat HARUS melaporkan dukungan Mode Performa Berkelanjutan secara akurat melalui metode API PowerManager.isSustainedPerformanceModeSupported().

Implementasi perangkat dengan dua inti CPU atau lebih HARUS menyediakan setidaknya satu inti eksklusif yang dapat dicadangkan oleh aplikasi latar depan teratas. Jika disediakan, penerapan HARUS memenuhi persyaratan berikut:

Implementasi HARUS melaporkan nomor ID dari core eksklusif yang dapat dipesan oleh aplikasi latar depan atas melalui metode Process.getExclusiveCores() API.
Implementasi perangkat HARUS tidak mengizinkan proses ruang pengguna apa pun kecuali driver perangkat yang digunakan oleh aplikasi untuk berjalan pada inti eksklusif, tetapi DAPAT memungkinkan beberapa proses kernel berjalan sesuai kebutuhan.

Jika implementasi perangkat tidak mendukung inti eksklusif, implementasi tersebut HARUS menampilkan daftar kosong melalui metode API Process.getExclusiveCores().

9. Kompatibilitas Model Keamanan

Implementasi perangkat HARUS menerapkan model keamanan yang konsisten dengan model keamanan platform Android seperti yang dijelaskan dalam dokumen referensi Keamanan dan Izin dalam API di 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 dalam subbagian berikut.

9.1. Izin

Implementasi perangkat HARUS mendukung model izin Android seperti yang ditentukan dalam dokumentasi developer Android. 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 ada di namespace android.*.

Izin dengan protectionLevel 'PROTECTION_FLAG_PRIVILEGED' hanya boleh diberikan ke aplikasi yang dimuat sebelumnya di jalur hak istimewa yang diizinkan dari image sistem, seperti jalur system/priv-app dalam implementasi AOSP.

Izin dengan tingkat perlindungan berbahaya adalah izin runtime. Permohonan dengan targetSdkVersion > 22 meminta mereka 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:
- izin pengguna dapat diperoleh sebelum aplikasi menggunakannya
- izin runtime dikaitkan dengan pola intent yang aplikasi bawaannya telah disetel sebagai pengendali default

9.2. UID dan Isolasi Proses

Implementasi perangkat HARUS mendukung model sandbox aplikasi Android, dengan setiap aplikasi berjalan sebagai UID Unixstyle unik dan dalam proses terpisah. Implementasi perangkat HARUS mendukung pengoperasian beberapa aplikasi sebagai ID pengguna Linux yang sama, asalkan aplikasi ditandatangani dan dibuat dengan benar, seperti yang ditetapkan dalam referensi Keamanan dan Izin.

9.3. Izin Sistem File

Implementasi perangkat HARUS mendukung model izin akses file Android seperti yang ditentukan dalam referensi Keamanan dan Izin.

9.4. Lingkungan Eksekusi Alternatif

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

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

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

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 dalam sandbox Android terpisah (ID pengguna Linux, dll.).
MUNGKIN menyediakan satu sandbox Android yang digunakan bersama oleh semua aplikasi yang menggunakan runtime alternatif.
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 hak istimewa apa pun kepada aplikasi lain dari 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 sumber daya perangkat yang memiliki izin Android yang sesuai (seperti Kamera, GPS, dll.), waktu proses alternatif HARUS memberi tahu pengguna bahwa aplikasi akan bisa mengakses sumber daya tersebut. Jika lingkungan runtime tidak merekam kemampuan aplikasi dengan cara ini, lingkungan runtime HARUS mencantumkan semua izin yang dimiliki oleh runtime itu sendiri saat menginstal aplikasi apa pun yang menggunakan runtime tersebut.

9,5. Dukungan Multipengguna

Fitur ini bersifat opsional untuk semua jenis perangkat.

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

Implementasi perangkat Android Automotive dengan dukungan multipengguna aktif HARUS menyertakan akun tamu yang mengizinkan semua fungsi yang disediakan oleh sistem kendaraan tanpa mengharuskan pengguna untuk login.
Implementasi perangkat yang tidak mendeklarasikan tanda fitur android.hardware.telephony HARUS mendukung profil yang dibatasi, yaitu 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 batasan yang lebih mendetail dalam aplikasi yang tersedia di lingkungan tersebut.
Sebaliknya, implementasi perangkat yang mendeklarasikan tombol fitur android.hardware.telephony TIDAK BOLEH mendukung profil terbatas 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 dalam API.
Setiap instance pengguna di perangkat Android HARUS memiliki direktori penyimpanan eksternal yang terpisah dan terisolasi. Penerapan perangkat DAPAT menyimpan beberapa pengguna data pada volume atau sistem file yang sama. Namun, penerapan perangkat HARUS memastikan bahwa aplikasi yang dimiliki oleh 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 lainnya melalui PC host. Oleh karena itu, implementasi perangkat yang menggunakan media lepas-pasang untuk API penyimpanan eksternal HARUS mengenkripsi konten kartu SD jika multipengguna diaktifkan menggunakan kunci yang hanya disimpan pada media yang tidak dapat dilepas dan hanya dapat diakses oleh sistem. Karena ini akan membuat media tidak dapat dibaca oleh PC host, implementasi perangkat akan diperlukan untuk beralih ke MTP atau sistem serupa untuk menyediakan akses ke data pengguna saat ini kepada PC host. Oleh karena itu, implementasi perangkat MUNGKIN, tetapi TIDAK BOLEH mengaktifkan multi-pengguna jika menggunakan media yang dapat dilepas untuk penyimpanan eksternal utama.

9.6. Peringatan SMS Premium

Android menyertakan dukungan untuk memperingatkan pengguna tentang setiap pesan SMS premium keluar. Pesan SMS Premium adalah pesan teks yang dikirim ke layanan yang terdaftar dengan operator yang mungkin dikenakan 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

Android Sandbox menyertakan fitur yang menggunakan sistem kontrol akses wajib (MAC) Security-Enhanced Linux (SELinux), sandbox seccomp, dan fitur keamanan lainnya di kernel Linux. SELinux atau fitur keamanan lain yang diimplementasikan 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 MUNGKIN memiliki antarmuka pengguna yang terlihat saat terjadi pelanggaran keamanan yang dibatalkan pemblokirannya, sehingga berhasil diterapkan.
SEHARUSNYA TIDAK dapat dikonfigurasi oleh pengguna atau developer.

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

Perangkat HARUS mengimplementasikan 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 memodifikasi, menghilangkan, atau mengganti aturan neverallow yang ada dalam folder sistem/sepolicy yang disediakan di Proyek Open Source Android (AOSP) upstream dan kebijakan ini HARUS dikompilasi dengan semua aturan yang tidak diizinkan yang ada, baik untuk domain SELinux AOSP serta domain khusus perangkat/vendor.
HARUS membagi framework media menjadi beberapa proses sehingga dapat memberikan akses secara lebih sempit untuk setiap proses seperti yang dijelaskan di situs Project Open Source Android.

Implementasi perangkat HARUS mempertahankan kebijakan SELinux default yang disediakan dalam folder sistem/sepolicy Project Open Source Android upstream dan hanya menambahkan kebijakan ini ke kebijakan ini untuk konfigurasi khusus perangkatnya sendiri. Implementasi perangkat HARUS kompatibel dengan Project Open Source Android upstream.

Perangkat HARUS menerapkan mekanisme sandbox aplikasi kernel yang memungkinkan pemfilteran panggilan sistem menggunakan kebijakan yang dapat dikonfigurasi dari program multi-thread. Project Open Source Android upstream memenuhi persyaratan ini dengan mengaktifkan seccomp-BPF dengan sinkronisasi threadgroup (TSYNC) seperti yang dijelaskan di bagian Konfigurasi Kernel di source.android.com.

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 penerapan perangkat memiliki mekanisme yang mengarahkan traffic data jaringan melalui server proxy atau gateway VPN secara default (misalnya, pramuat layanan VPN dengan android.permission.CONTROL_VPN diberikan), penerapan perangkat HARUS meminta izin pengguna sebelum mengaktifkan mekanisme tersebut, kecuali jika VPN diaktifkan oleh Pengontrol Kebijakan Perangkat melalui DevicePolicyManager.setAlwaysOnVpnPackage(), dalam hal ini pengguna tidak perlu memberikan izin terpisah, tetapi HARUS diberi tahu hanya.

Penerapan perangkat HARUS dikirimkan dengan penyimpanan Certificate Authority (CA) kosong yang ditambahkan pengguna, dan HARUS menginstal root certificate yang sama untuk penyimpanan CA tepercaya sistem seperti yang disediakan di Project Open Source Android upstream.

Jika perangkat dirutekan melalui VPN, atau CA root pengguna diinstal, implementasi HARUS menampilkan peringatan yang menunjukkan bahwa traffic jaringan mungkin dipantau oleh pengguna.

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

9,9. Enkripsi Penyimpanan Data

Opsional untuk implementasi perangkat Android tanpa layar kunci yang aman.

Jika implementasi perangkat mendukung layar kunci aman seperti yang dijelaskan di bagian 9.11.1, maka perangkat HARUS mendukung enkripsi penyimpanan data untuk data pribadi aplikasi (partisi / data), serta partisi penyimpanan bersama aplikasi (partisi / sdcard) jika merupakan bagian perangkat yang permanen dan tidak dapat dilepas.

Untuk implementasi perangkat yang mendukung enkripsi penyimpanan data dan dengan performa kriptografi Advanced Encryption Standard (AES) di atas 50 MiB/dtk, enkripsi penyimpanan data HARUS diaktifkan secara default pada saat pengguna telah menyelesaikan proses penyiapan siap pakai. Jika implementasi perangkat sudah diluncurkan pada versi Android sebelumnya dengan enkripsi dinonaktifkan secara default, perangkat tersebut tidak dapat memenuhi persyaratan melalui update software sistem sehingga MUNGKIN dikecualikan.

Implementasi perangkat HARUS memenuhi persyaratan enkripsi penyimpanan data di atas melalui penerapan Enkripsi Berbasis File (FBE).

9.9.1 Direct Boot

Semua perangkat HARUS menerapkan API mode Booting Langsung meskipun tidak mendukung Enkripsi Penyimpanan. Secara khusus, Intent LOCKED_BOOT_COMPLETED dan ACTION_USER_UNLOCKED harus tetap disiarkan untuk memberi sinyal pada aplikasi yang mendukung Direct Boot bahwa lokasi penyimpanan Device Encrypted (DE) dan Credential Encrypted (CE) tersedia bagi pengguna.

9.9.2. Enkripsi Berbasis File

Implementasi perangkat yang mendukung FBE:

HARUS melakukan booting tanpa meminta kredensial pengguna dan mengizinkan aplikasi yang sadar Direct Boot mengakses ke penyimpanan Device Encrypted (DE) setelah pesan LOCKED_BOOT_COMPLETED disiarkan.
HARUS mengizinkan akses ke penyimpanan Credential Encrypted (CE) hanya setelah pengguna membuka kunci perangkat dengan memberikan kredensial (misalnya, kode sandi, pin, pola, atau sidik jari) dan pesan ACTION_USER_UNLOCKED disiarkan. Implementasi perangkat TIDAK BOLEH menawarkan metode apa pun untuk membuka penyimpanan yang dilindungi CE tanpa kredensial yang diberikan pengguna.
HARUS mendukung Booting Terverifikasi dan memastikan bahwa kunci DE terikat secara kriptografis dengan root of trust hardware perangkat.
HARUS mendukung enkripsi konten file menggunakan AES dengan panjang kunci 256-bit dalam mode XTS.
HARUS mendukung enkripsi nama file menggunakan AES dengan panjang kunci 256 bit dalam mode CBC-CTS.
Mampu mendukung cipher alternatif, panjang kunci, dan mode untuk konten file dan enkripsi nama file, tetapi secara default HARUS menggunakan cipher, panjang kunci, dan mode yang didukung secara wajib.
HARUS buat aplikasi penting yang dipramuat (misalnya Alarm, Telepon, Messenger) Langsung Booting.

Kunci yang melindungi area penyimpanan CE dan DE:

HARUS terikat secara kriptografis ke Keystore yang didukung hardware. Kunci CE harus terikat dengan kredensial layar kunci pengguna. Jika pengguna tidak menentukan kredensial layar kunci, kunci CE HARUS terikat dengan kode sandi default.
HARUS unik dan berbeda, dengan kata lain, tidak ada kunci CE atau DE pengguna yang boleh cocok dengan kunci CE atau DE pengguna lainnya.

Project Open Source Android upstream menyediakan implementasi yang lebih disukai dari fitur ini berdasarkan fitur enkripsi ext4 kernel Linux.

9.9.3. Enkripsi Disk Penuh

Implementasi perangkat yang mendukung enkripsi disk penuh (FDE). 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 pun tanpa dienkripsi. Selain saat digunakan secara aktif, kunci enkripsi SEHARUSNYA dienkripsi AES dengan kredensial layar kunci yang direntangkan menggunakan algoritma peregangan lambat (misalnya PBKDF2 atau scrypt). Jika pengguna belum menentukan kredensial 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 keluar perangkat (bahkan saat digabungkan dengan kode sandi pengguna dan/atau kunci yang terikat hardware). Project Open Source Android upstream menyediakan implementasi yang lebih disukai dari fitur ini berdasarkan fitur kernel Linux dm-crypt.

9.10. Integritas Perangkat

Persyaratan berikut memastikan adanya transparansi terhadap status integritas perangkat.

Implementasi perangkat HARUS melaporkan dengan benar melalui metode System API PersistentDataBlockManager.getFlashLockState() apakah status bootloader-nya memungkinkan flash image sistem. Status FLASH_LOCK_UNKNOWN dicadangkan untuk implementasi perangkat yang diupgrade dari versi Android sebelumnya saat metode API sistem baru ini tidak ada.

Booting terverifikasi adalah fitur yang menjamin integritas software perangkat. Jika implementasi perangkat mendukung fitur tersebut, implementasi tersebut HARUS:

Deklarasikan tanda fitur platform android.software.verify_boot.
Menjalankan verifikasi pada setiap urutan booting.
Memulai verifikasi dari kunci hardware yang tidak dapat diubah yang merupakan akar kepercayaan dan berlanjut hingga ke partisi sistem.
Terapkan setiap tahap verifikasi untuk memeriksa integritas dan keaslian semua byte di tahap berikutnya sebelum mengeksekusi 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).
TIDAK BOLEH mengizinkan booting selesai jika verifikasi sistem gagal, kecuali jika pengguna setuju untuk tetap mencoba melakukan booting, dalam hal ini data dari blok penyimpanan yang tidak terverifikasi TIDAK BOLEH digunakan.
TIDAK BOLEH mengizinkan partisi terverifikasi pada perangkat untuk dimodifikasi kecuali pengguna telah membuka kunci boot loader secara eksplisit.

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

Mulai Android 6.0, implementasi perangkat dengan performa kriptografi 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 pada versi Android yang lebih lama, perangkat tersebut tidak dapat menambahkan dukungan untuk fitur ini dengan update software sistem sehingga dikecualikan dari persyaratan tersebut.

9.11. Kunci dan Kredensial

Sistem Android Keystore memungkinkan developer aplikasi menyimpan kunci kriptografis dalam penampung dan menggunakannya dalam operasi kriptografi melalui KeyChain API atau Keystore API.

Semua implementasi perangkat Android HARUS memenuhi persyaratan berikut:

SEHARUSNYA tidak membatasi jumlah kunci yang dapat dihasilkan, dan setidaknya HARUS mengizinkan lebih dari 8.192 kunci untuk diimpor.
Upaya pembatasan kapasitas autentikasi layar kunci HARUS dan HARUS memiliki algoritma backoff eksponensial. Di atas 150 upaya gagal, penundaan HARUS minimal 24 jam per upaya.
Jika implementasi perangkat mendukung layar kunci yang aman, implementasi tersebut HARUS mencadangkan implementasi keystore dengan hardware aman dan memenuhi persyaratan berikut:
- HARUS memiliki implementasi algoritma kriptografi RSA, AES, ECDSA, dan HMAC yang didukung hardware, serta fungsi hash MD5, SHA1, SHA-2 Family untuk mendukung algoritma yang didukung sistem Android Keystore dengan benar.
- HARUS melakukan otentikasi layar kunci pada hardware yang aman dan hanya jika berhasil, izinkan kunci yang terikat otentikasi untuk digunakan. Project Open Source Android upstream menyediakan Gatekeeper Hardware Abstraksi Layer (HAL) yang dapat digunakan untuk memenuhi persyaratan ini.

Perhatikan bahwa jika implementasi perangkat sudah diluncurkan pada versi Android sebelumnya, perangkat tersebut dikecualikan dari persyaratan untuk memiliki keystore yang didukung hardware, kecuali jika mendeklarasikan fitur android.hardware.fingerprint yang memerlukan keystore yang didukung hardware.

9.11.1. Layar Kunci Aman

Penerapan perangkat DAPAT menambahkan atau mengubah metode autentikasi untuk membuka kunci layar kunci, tetapi HARUS tetap memenuhi persyaratan berikut:

Metode autentikasi, jika didasarkan pada rahasia yang diketahui, TIDAK BOLEH diperlakukan sebagai layar kunci aman, kecuali jika memenuhi semua persyaratan berikut:
- Entropi panjang input terpendek yang diizinkan HARUS lebih besar dari 10 bit.
- Entropi maksimum dari semua input yang memungkinkan HARUS lebih besar dari 18 bit.
- TIDAK BOLEH menggantikan metode autentikasi apa pun yang ada (PIN, pola, sandi) yang diimplementasikan dan disediakan dalam AOSP.
- HARUS dinonaktifkan jika aplikasi Pengontrol Kebijakan Perangkat (DPC) telah menetapkan kebijakan kualitas sandi melalui metode DevicePolicyManager.setPasswordQuality() dengan konstanta kualitas yang lebih ketat daripada PASSWORD_QUALITY_SOMETHING .
Metode autentikasi, jika didasarkan pada token fisik atau lokasi, TIDAK BOLEH diperlakukan sebagai layar kunci aman kecuali jika memenuhi semua persyaratan berikut:
- Perangkat harus memiliki mekanisme fallback untuk menggunakan salah satu metode autentikasi utama yang didasarkan pada rahasia yang diketahui dan memenuhi persyaratan untuk diperlakukan sebagai layar kunci yang aman.
- Kunci ini HARUS dinonaktifkan dan hanya mengizinkan autentikasi utama untuk membuka kunci layar jika aplikasi Pengontrol Kebijakan Perangkat (DPC) telah menyetel kebijakan dengan metode DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) atau metode DevicePolicyManager.setPasswordQuality() dengan konstanta kualitas yang lebih ketat daripada PASSWORD_QUALITY_UNSPECIFIED .
Metode autentikasi, jika didasarkan pada biometrik, TIDAK BOLEH diperlakukan sebagai layar kunci aman, kecuali jika memenuhi semua persyaratan berikut:
- Perangkat harus memiliki mekanisme fallback untuk menggunakan salah satu metode autentikasi utama yang didasarkan pada rahasia yang diketahui dan memenuhi persyaratan untuk diperlakukan sebagai layar kunci yang aman.
- Kunci ini HARUS dinonaktifkan dan hanya mengizinkan autentikasi utama untuk membuka kunci layar jika aplikasi Pengontrol Kebijakan Perangkat (DPC) telah menetapkan kebijakan fitur keguard dengan memanggil metode DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT).
- Kunci ini HARUS memiliki tingkat penerimaan palsu yang sama atau lebih kuat dari yang diperlukan untuk sensor sidik jari seperti yang dijelaskan di bagian 7.3.10, atau HARUS dinonaktifkan dan hanya mengizinkan autentikasi utama untuk membuka kunci layar saat aplikasi Pengontrol Kebijakan Perangkat (DPC) telah menetapkan kebijakan kualitas sandi melalui metode DevicePolicyManager.setPasswordQuality() dengan konstanta kualitas yang lebih ketat daripada PASSWORD_QUALITY_BIOMETRIC_WEAK .
Jika metode autentikasi tidak dapat diperlakukan sebagai layar kunci aman, metode tersebut:
- HARUS menampilkan false untuk metode KeyguardManager.isKeyguardSecure() dan KeyguardManager.isDeviceSecure().
- HARUS dinonaktifkan jika aplikasi Pengontrol Kebijakan Perangkat (DPC) telah menetapkan kebijakan kualitas sandi melalui metode DevicePolicyManager.setPasswordQuality() dengan konstanta kualitas yang lebih ketat daripada PASSWORD_QUALITY_UNSPECIFIED .
- TIDAK BOLEH mereset timer masa berlaku sandi yang disetel oleh DevicePolicyManager.setPasswordExpirationTimeout().
- TIDAK BOLEH mengautentikasi akses ke keystore jika aplikasi telah memanggil KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true) ).
Jika metode autentikasi didasarkan pada token fisik, lokasi, atau biometrik yang memiliki tingkat penerimaan palsu lebih tinggi daripada yang diperlukan untuk sensor sidik jari seperti dijelaskan dalam pasal 7.3.10, maka metode tersebut:
- TIDAK BOLEH mereset timer masa berlaku sandi yang disetel oleh DevicePolicyManager.setPasswordExpirationTimeout().
- TIDAK BOLEH mengautentikasi akses ke keystore jika aplikasi telah memanggil KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true).

9.12. Penghapusan Data

Perangkat HARUS menyediakan mekanisme kepada pengguna untuk melakukan "Reset ke Setelan Pabrik" yang memungkinkan penghapusan logis dan fisik atas semua data kecuali untuk hal berikut:

Image sistem
Semua file sistem operasi yang dibutuhkan oleh image sistem

Semua data yang dibuat pengguna HARUS dihapus. Ini HARUS memenuhi standar industri yang relevan untuk penghapusan data seperti NIST SP800-88. Fitur ini HARUS digunakan untuk penerapan API hapusData() (bagian dari Android Device Administration API) yang dijelaskan di bagian 3.9 Administrasi Perangkat.

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

9.13. Mode Booting Aman

Android menyediakan mode yang memungkinkan pengguna melakukan booting ke mode yang hanya mengizinkan aplikasi sistem bawaan untuk dijalankan dan semua aplikasi pihak ketiga dinonaktifkan. Mode ini, yang dikenal sebagai "Mode Booting Aman", memberi pengguna kemampuan untuk meng-uninstal aplikasi pihak ketiga yang berpotensi berbahaya.

Implementasi perangkat Android SANGAT REKOMENDASI untuk menerapkan Mode Booting Aman dan memenuhi persyaratan berikut:

Implementasi perangkat SEHARUSNYA memberi pengguna opsi untuk masuk ke Mode Booting Aman dari menu booting yang dapat dijangkau melalui alur kerja yang berbeda dengan booting normal.
Implementasi perangkat HARUS memberi pengguna opsi untuk masuk ke Mode Booting Aman dengan cara yang tidak terganggu oleh aplikasi pihak ketiga yang diinstal di perangkat, kecuali jika aplikasi pihak ketiga adalah Pengontrol Kebijakan Perangkat dan telah menetapkan tanda UserManager.DISALLOW_SAFE_BOOT sebagai benar (true).
Penerapan perangkat HARUS memberikan kemampuan kepada pengguna untuk meng-uninstal aplikasi pihak ketiga apa pun dalam Mode Aman.

9.14. Isolasi Sistem Kendaraan Otomotif

Perangkat Android Automotive diharapkan bertukar data dengan subsistem kendaraan penting, misalnya, dengan menggunakan vehicle HAL untuk mengirim dan menerima pesan melalui jaringan kendaraan seperti bus CAN. Implementasi perangkat Android Automotive HARUS menerapkan fitur keamanan di bawah lapisan framework Android untuk mencegah interaksi berbahaya atau tidak disengaja antara framework Android atau aplikasi pihak ketiga dan subsistem kendaraan. Fitur keamanan tersebut adalah sebagai berikut:

Pesan gateway dari subsistem kendaraan framework Android, misalnya, mengizinkan jenis pesan dan sumber pesan yang diizinkan.
Watchdog terhadap serangan denial of service dari framework Android atau aplikasi pihak ketiga. Tindakan ini melindungi jaringan dari software berbahaya yang membanjiri jaringan kendaraan dengan traffic, yang dapat menyebabkan kerusakan subsistem kendaraan.

10. Pengujian Kompatibilitas Software

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

Namun, perhatikan bahwa tidak ada paket pengujian perangkat lunak yang sepenuhnya komprehensif. Karena alasan ini, pengimplementasi perangkat DIREKOMENDASIKAN untuk membuat sesedikit mungkin perubahan pada referensi dan implementasi pilihan Android yang tersedia dari Project Open Source Android. Hal ini akan meminimalkan risiko timbulnya bug yang menimbulkan inkompatibilitas yang memerlukan pengerjaan ulang dan potensi update perangkat.

10.1. Compatibility Test Suite (CTS)

Implementasi perangkat HARUS lulus Compatibility Test Suite (CTS) Android yang tersedia dari Project Open Source Android, menggunakan software pengiriman akhir di perangkat. Selain itu, pengimplementasi perangkat HARUS menggunakan implementasi referensi di pohon Open Source Android sebanyak mungkin, dan HARUS memastikan kompatibilitas jika terjadi ambiguitas dalam CTS dan untuk implementasi ulang bagian-bagian kode sumber referensi.

CTS dirancang untuk dijalankan pada perangkat yang sebenarnya. Seperti perangkat lunak lainnya, CTS mungkin memiliki bug. CTS akan diversikan secara terpisah dari Compatibility Definition (Definisi Kompatibilitas) ini, dan beberapa revisi dari CTS dapat dirilis untuk Android 7.0. Implementasi perangkat HARUS lulus versi CTS terbaru yang tersedia pada saat software perangkat selesai.

10.2. Pemverifikasi CTS

Implementasi perangkat HARUS mengeksekusi semua kasus yang berlaku di CTS Verifier dengan benar. CTS Verifier disertakan dalam Compatibility Test Suite (CTS), dan ditujukan untuk dijalankan oleh operator manusia guna menguji fungsionalitas yang tidak dapat diuji oleh sistem otomatis, seperti fungsi kamera dan sensor yang benar.

CTS Verifier memiliki pengujian untuk berbagai jenis perangkat keras, termasuk beberapa perangkat keras yang bersifat opsional. Implementasi perangkat HARUS lulus semua pengujian hardware yang dimiliki; Misalnya, jika perangkat memiliki akselerometer, perangkat HARUS menjalankan kasus pengujian Akselerometer dengan benar di CTS Verifier. Kasus pengujian untuk fitur yang dianggap opsional oleh Dokumen Definisi Kompatibilitas ini DAPAT dilewati atau dihilangkan.

Setiap perangkat dan setiap build HARUS menjalankan CTS Verifier dengan benar, seperti yang disebutkan di atas. Namun, karena banyak build sangat mirip, pengimplementasi perangkat tidak diharapkan untuk secara eksplisit menjalankan CTS Verifier pada build yang hanya berbeda dalam hal yang sepele. Secara khusus, implementasi perangkat yang berbeda dari implementasi yang telah lulus CTS Verifier hanya oleh kumpulan lokalitas yang disertakan, branding, dll. MUNGKIN menghilangkan uji CTS Verifier.

11. Software yang Dapat Diperbarui

Implementasi perangkat HARUS menyertakan mekanisme untuk mengganti keseluruhan software sistem. Mekanismenya tidak perlu melakukan upgrade “langsung”—artinya, perangkat yang dimulai ulang MUNGKIN diperlukan.

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

Download “over the air (OTA)” dengan update offline melalui reboot.
Pembaruan “Tethered” melalui USB dari PC host.
Update “Offline” melalui reboot dan update dari file pada penyimpanan yang dapat dilepas.

Namun, jika implementasi perangkat menyertakan dukungan untuk koneksi data tidak berbayar seperti profil 802.11 atau Bluetooth PAN (Jaringan Area Pribadi), implementasi HARUS mendukung download OTA dengan update offline melalui mulai ulang.

Mekanisme pembaruan yang digunakan HARUS mendukung pembaruan tanpa menghapus total data pengguna. Artinya, mekanisme update HARUS mempertahankan data pribadi aplikasi dan data bersama aplikasi. Perlu diketahui bahwa software Android upstream menyertakan mekanisme update yang memenuhi persyaratan ini.

Untuk implementasi perangkat yang diluncurkan dengan Android 7.0 dan yang lebih baru, mekanisme update SEHARUSNYA mendukung verifikasi bahwa image sistem biner 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 ditemukan error dalam implementasi perangkat setelah dirilis, tetapi dalam masa pakai produk yang wajar yang ditentukan melalui konsultasi dengan Tim Kompatibilitas Android untuk memengaruhi kompatibilitas aplikasi pihak ketiga, pengimplementasi perangkat HARUS memperbaiki error tersebut melalui update software yang tersedia dan dapat diterapkan sesuai 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.

12. Log Perubahan Dokumen

Untuk ringkasan perubahan pada Compatibility Definition dalam rilis ini:

Log perubahan dokumen

Untuk ringkasan perubahan pada masing-masing bagian:

12.1. Tips Melihat Log Perubahan

Perubahan ditandai sebagai berikut:

CDD
Perubahan substantif pada persyaratan kompatibilitas.
Dokumen
Perubahan terkait tampilan atau kosmetik.

Untuk tampilan terbaik, tambahkan parameter URL pretty=full dan no-merges ke URL log perubahan Anda.

13. Hubungi Kami

Anda dapat bergabung ke forum kompatibilitas android dan meminta klarifikasi atau mengemukakan masalah apa pun yang menurut Anda tidak dicakup dalam dokumen tersebut.