Definisi Kompatibilitas Android 17 [PRATINJAU]

1. Pengantar

Dokumen ini menguraikan persyaratan yang harus dipenuhi agar perangkat kompatibel dengan Android 17.

Penggunaan "HARUS", "TIDAK BOLEH", "WAJIB", "HARUS", "TIDAK BOLEH", "SEBAIKNYA", "SEBAIKNYA TIDAK", "DIREKOMENDASIKAN", "MUNGKIN", dan "OPSIONAL" sesuai dengan standar IETF yang ditentukan dalam RFC2119.

Seperti yang digunakan dalam dokumen ini, "pelaksana perangkat" atau "pelaksana" adalah orang atau organisasi yang mengembangkan solusi hardware/software yang menjalankan Android 17. "Implementasi perangkat" atau "implementasi" adalah solusi hardware/software yang dikembangkan.

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

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

Oleh karena itu, Project Open Source Android adalah referensi dan implementasi pilihan Android. Direkomendasikan SANGAT KUAT agar penerapan perangkat didasarkan semaksimal mungkin pada kode sumber "upstream" yang tersedia dari Project Open Source Android. Meskipun beberapa komponen secara hipotetis dapat diganti dengan implementasi alternatif, SANGAT DISARANKAN untuk tidak mengikuti praktik ini, karena lulus pengujian software akan menjadi jauh lebih sulit. Implementor 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 referensi yang ditautkan dalam dokumen ini berasal secara langsung atau tidak langsung dari Android SDK dan akan berfungsi sama dengan informasi dalam dokumentasi SDK tersebut. Dalam kasus apa pun jika Definisi Kompatibilitas ini atau Compatibility Test Suite tidak sesuai dengan dokumentasi SDK, dokumentasi SDK dianggap sebagai yang paling berwenang. Semua detail teknis yang diberikan dalam referensi tertaut di seluruh dokumen ini dianggap sebagai bagian dari Definisi Kompatibilitas ini.

1.1 Struktur Dokumen

1.1.1. Persyaratan menurut Jenis Perangkat

Bagian 2 berisi semua persyaratan yang berlaku untuk jenis perangkat tertentu. Setiap sub-bagian Bagian 2 dikhususkan untuk jenis perangkat tertentu.

Semua persyaratan lainnya, yang berlaku secara universal untuk semua penerapan perangkat Android, tercantum di bagian setelah Bagian 2. Persyaratan ini dirujuk sebagai "Persyaratan Inti" dalam dokumen ini.

1.1.2. ID Persyaratan

ID persyaratan ditetapkan untuk persyaratan WAJIB.

• ID hanya ditetapkan untuk persyaratan WAJIB.
• Persyaratan STRONGLY RECOMMENDED ditandai sebagai [SR], tetapi ID tidak ditetapkan.
• ID terdiri dari : ID Jenis Perangkat - ID Kondisi - ID Persyaratan (misalnya, C-0-1).

Setiap ID ditentukan seperti di bawah:

• ID Jenis Perangkat (lihat selengkapnya di 2. Jenis Perangkat)
  • C: Inti (Persyaratan yang diterapkan pada semua implementasi perangkat Android)
  • H: Perangkat Genggam Android
  • T: Perangkat Android TV
  • J: Implementasi Android Automotive
  • W: Penerapan Android Watch
  • Tab: Penerapan Tablet Android
• ID Kondisi
  • Jika persyaratan tidak bersyarat, ID ini ditetapkan sebagai 0.
  • Jika persyaratan bersifat kondisional, 1 ditetapkan untuk kondisi ke-1 dan angka bertambah 1 dalam bagian yang sama dan jenis perangkat yang sama.
• ID Persyaratan
  • ID ini dimulai dari 1 dan bertambah 1 dalam bagian yang sama dan kondisi yang sama.

1.1.3. ID Persyaratan di Bagian 2

ID Persyaratan di Bagian 2 memiliki dua bagian. Yang pertama sesuai dengan ID bagian seperti yang dijelaskan di atas. Bagian kedua mengidentifikasi faktor bentuk dan persyaratan khusus faktor bentuk.

ID bagian yang diikuti dengan ID Persyaratan yang dijelaskan di atas.

• ID di Bagian 2 terdiri dari: ID Bagian / ID Jenis Perangkat - ID Kondisi - ID Persyaratan (mis. 7.4.3/A-0-1).

2. Jenis Perangkat

Proyek Open Source Android menyediakan tumpukan perangkat lunak yang dapat digunakan untuk berbagai jenis perangkat dan faktor bentuk. Untuk mendukung keamanan di perangkat, stack software, termasuk OS pengganti atau implementasi kernel alternatif, diharapkan berjalan di lingkungan yang aman seperti yang dijelaskan di bagian 9 dan di tempat lain dalam CDD ini. Ada beberapa jenis perangkat yang memiliki ekosistem distribusi aplikasi yang relatif lebih mapan.

Bagian ini menjelaskan jenis perangkat tersebut, serta persyaratan dan rekomendasi tambahan yang berlaku untuk setiap jenis perangkat.

Semua implementasi perangkat Android yang tidak sesuai dengan salah satu jenis perangkat yang dijelaskan HARUS tetap memenuhi semua persyaratan di bagian lain dalam Definisi Kompatibilitas ini.

2.1 Konfigurasi Perangkat

Untuk mengetahui perbedaan utama dalam konfigurasi hardware menurut jenis perangkat, lihat persyaratan khusus perangkat yang ada di bagian ini.

2.2. Persyaratan Perangkat Genggam

Perangkat Genggam Android mengacu pada penerapan perangkat Android yang biasanya digunakan dengan memegangnya di tangan, seperti pemutar mp3, ponsel, atau tablet.

Implementasi perangkat Android diklasifikasikan sebagai Genggam jika memenuhi semua kriteria berikut:

• Memiliki sumber listrik yang memberikan mobilitas, seperti baterai.
• Memiliki ukuran layar diagonal fisik dalam rentang 4 inci hingga 8 inci.
• Memiliki antarmuka input layar sentuh.

Persyaratan tambahan di bagian ini khusus untuk penerapan perangkat Genggam Android.

2.2.1. Hardware

Implementasi perangkat genggam:

• [7.1.1.1/H-0-1] HARUS memiliki minimal satu layar yang kompatibel dengan Android yang berukuran minimal 2,2 inci di tepi pendek dan 3,4 inci di tepi panjang.

• [7.1.1.3/H-SR-1] SANGAT DISARANKAN untuk memberikan kemudahan bagi pengguna untuk mengubah ukuran tampilan (kepadatan layar).

• [7.1.1.1/H-0-2] HARUS mendukung komposisi GPU buffer grafis yang setidaknya sebesar resolusi tertinggi dari layar bawaan mana pun.

• [7.1.1.1/H-0-3]^* HARUS memetakan setiap tampilan UI_MODE_NORMAL yang tersedia untuk aplikasi pihak ketiga ke area tampilan fisik yang tidak terhalang yang berukuran minimal 2,2 inci di tepi pendek dan 3,4 inci di tepi panjang.

• [7.1.1.3/H-0-1]^* HARUS menetapkan DENSITY_DEVICE_STABLE menjadi 92% atau lebih besar dari kepadatan fisik sebenarnya dari layar yang sesuai.

Jika implementasi perangkat genggam mencakup dukungan untuk Vulkan, maka:

• [7.1.4.2/H-1-1] HARUS memenuhi persyaratan yang ditentukan oleh profil Dasar Pengukuran Android 2021.

Jika implementasi perangkat Genggam mengklaim dukungan untuk layar rentang dinamis tinggi melalui Configuration.isScreenHdr(), maka:

• [7.1.4.5/H-1-1] HARUS mengiklankan dukungan untuk ekstensi EGL_EXT_gl_colorspace_bt2020_pq, EGL_EXT_surface_SMPTE2086_metadata, EGL_EXT_surface_CTA861_3_metadata, VK_EXT_swapchain_colorspace, dan VK_EXT_hdr_metadata.

Implementasi perangkat genggam:

• [7.1.4.6/H-0-1] HARUS melaporkan apakah perangkat mendukung kemampuan pembuatan profil GPU melalui properti sistem graphics.gpu.profiler.support.

Jika implementasi Perangkat genggam menyatakan dukungan melalui properti sistem graphics.gpu.profiler.support, maka:

• [7.1.4.6/H-1-1] HARUS melaporkan sebagai output rekaman aktivitas protobuf yang mematuhi skema untuk penghitung GPU dan tahap perenderan GPU yang ditentukan dalam dokumentasi Perfetto.

• [7.1.4.6/H-1-2] HARUS melaporkan nilai yang sesuai untuk penghitung GPU perangkat setelah gpu counter trace packet proto.

• [7.1.4.6/H-1-3] HARUS melaporkan nilai yang sesuai untuk RenderStage GPU perangkat setelah render stage trace packet proto.

• [7.1.4.6/H-1-4] HARUS melaporkan titik rekaman aktivitas Frekuensi GPU seperti yang ditentukan oleh format: power/gpu_frequency.

Implementasi perangkat genggam:

• [7.1.5/H-0-1] HARUS menyertakan dukungan untuk mode kompatibilitas aplikasi lama sebagaimana diterapkan oleh kode sumber terbuka 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.2.1/H-0-1] HARUS menyertakan dukungan untuk aplikasi Editor Metode Input (IME) pihak ketiga.

• [7.2.3/H-0-2] HARUS mengirimkan peristiwa tekan normal dan lama fungsi Kembali (KEYCODE_BACK) ke aplikasi latar depan. Peristiwa ini TIDAK BOLEH digunakan oleh sistem dan DAPAT dipicu dari luar perangkat Android (misalnya, keyboard hardware eksternal yang terhubung ke perangkat Android).

• [7.2.3/H-0-3] HARUS menyediakan fungsi Beranda di semua layar yang kompatibel dengan Android yang menyediakan layar utama.

• [7.2.3/H-0-4] HARUS menyediakan fungsi Kembali di semua layar yang kompatibel dengan Android dan fungsi Terbaru di setidaknya salah satu layar yang kompatibel dengan Android.

• [7.2.4/H-0-1] HARUS mendukung input layar sentuh.

• [7.2.4/H-SR-1] SANGAT DISARANKAN untuk meluncurkan aplikasi bantuan yang dipilih pengguna; dengan kata lain, aplikasi yang menerapkan VoiceInteractionService, atau aktivitas yang menangani ACTION_ASSIST saat menekan lama KEYCODE_MEDIA_PLAY_PAUSE atau KEYCODE_HEADSETHOOK jika aktivitas latar depan tidak menangani peristiwa tekan lama tersebut.

• [7.3.1/H-SR-1] SANGAT DISARANKAN untuk menyertakan akselerometer 3 sumbu.

Jika penerapan Perangkat genggam mencakup akselerometer 3 sumbu, maka:

• [7.3.1/H-1-1] HARUS dapat melaporkan peristiwa hingga frekuensi minimal 100 Hz.

Jika implementasi Perangkat genggam mencakup penerima GPS/GNSS dan melaporkan kemampuan ke aplikasi melalui tanda fitur android.hardware.location.gps, implementasi tersebut:

• [7.3.3/H-2-1] HARUS melaporkan pengukuran GNSS, segera setelah ditemukan, meskipun lokasi yang dihitung dari GPS/GNSS belum dilaporkan.

• [7.3.3/H-2-2] HARUS melaporkan pseudojarak dan laju pseudojarak GNSS, yang dalam kondisi langit terbuka setelah menentukan lokasi, saat stasioner atau bergerak dengan percepatan 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.

Jika implementasi Perangkat genggam mencakup giroskop 3 sumbu, maka:

• [7.3.4/H-3-1] HARUS dapat melaporkan peristiwa hingga frekuensi minimal 100 Hz.

• [7.3.4/H-3-2] HARUS dapat mengukur perubahan orientasi hingga 1000 derajat per detik.

Implementasi perangkat genggam yang dapat melakukan panggilan suara dan menunjukkan nilai selain PHONE_TYPE_NONE di getPhoneType:

• [7.3.8/H] HARUS menyertakan sensor kedekatan.

Implementasi perangkat genggam:

• [7.3.11/H-SR-1] SANGAT DISARANKAN untuk mendukung sensor postur dengan 6 derajat kebebasan.

Implementasi perangkat genggam yang mencakup dukungan untuk Bluetooth LE:

• [7.4.3/H-SR-1] SANGAT DISARANKAN untuk mendukung Ekstensi Panjang Paket Data Bluetooth LE.

Jika implementasi perangkat mencakup dukungan untuk 802.11 (Wi-Fi), maka:

• [7.4.2.4/H-1-1] HARUS menyertakan dukungan untuk Wi-Fi Passpoint.

Jika perangkat mendukung protokol Wi-Fi Neighbor Awareness Networking (NAN) dengan mendeklarasikan PackageManager.FEATURE_WIFI_AWARE dan Wi-Fi Location (Wi-Fi Round Trip Time — RTT) dengan mendeklarasikan PackageManager.FEATURE_WIFI_RTT, perangkat tersebut:

• [7.4.2.5/H-1-1] HARUS melaporkan rentang secara akurat dalam +/-1 meter pada bandwidth 160 MHz pada persentil ke-68 (seperti yang dihitung dengan Cumulative Distribution Function), +/-2 meter pada bandwidth 80 MHz pada persentil ke-68, +/-4 meter pada bandwidth 40 MHz pada persentil ke-68, dan +/-8 meter pada bandwidth 20 MHz pada persentil ke-68 pada jarak 10 cm, 1 m, 3 m, dan 5 m, seperti yang diamati melalui WifiRttManager#startRanging Android API.

• [7.4.2.5/H-SR-1] SANGAT DISARANKAN untuk melaporkan rentang secara akurat dalam +/-1 meter pada bandwidth 160 MHz pada persentil ke-90 (seperti yang dihitung dengan Fungsi Distribusi Kumulatif), +/-2 meter pada bandwidth 80 MHz pada persentil ke-90, +/-4 meter pada bandwidth 40 MHz pada persentil ke-90, dan +/-8 meter pada bandwidth 20 MHz pada persentil ke-90 pada jarak 10 cm, seperti yang diamati melalui WifiRttManager#startRanging Android API.

SANGAT DISARANKAN untuk mengikuti langkah-langkah penyiapan pengukuran yang ditentukan dalam artikel Kalibrasi Kehadiran.

Jika implementasi Perangkat genggam mendeklarasikan FEATURE_BLUETOOTH_LE, implementasi tersebut:

• [7.4.3/H-1-3] HARUS mengukur dan mengompensasi offset Rx untuk memastikan median RSSI BLE adalah -50 dBm +/-15 dB pada jarak 1 m dari perangkat referensi yang mentransmisikan pada ADVERTISE_TX_POWER_HIGH.

• [7.4.3/H-1-4] HARUS mengukur dan mengompensasi offset Tx untuk memastikan median RSSI BLE adalah -50 dBm +/-15 dB saat memindai dari perangkat referensi yang diposisikan pada jarak 1 m dan mentransmisikan pada ADVERTISE_TX_POWER_HIGH.

Jika implementasi Perangkat genggam mencakup perangkat kamera logis yang mencantumkan kemampuan menggunakan CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, maka:

• [7.5.4/H-1-1] HARUS memiliki ruang pandang (FOV) normal secara default dan HARUS antara 50 dan derajat.

Implementasi perangkat genggam:

• [7.6.1/H-0-1] HARUS memiliki penyimpanan tidak mudah berubah minimal 4 GB yang tersedia untuk data pribadi aplikasi (alias partisi /data).

• [7.6.1/H-0-2] HARUS menampilkan "true" untuk ActivityManager.isLowRamDevice() jika memori yang tersedia untuk kernel dan ruang pengguna kurang dari 1 GB.

Jika implementasi perangkat Genggam mendeklarasikan dukungan hanya untuk ABI 32-bit:

• [7.6.1/H-1-1] Memori yang tersedia untuk kernel dan userspace HARUS minimal 416 MB jika layar default menggunakan resolusi framebuffer hingga qHD (misalnya, FWVGA).

• [7.6.1/H-2-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 592 MB jika layar default menggunakan resolusi framebuffer hingga HD+ (misalnya, HD, WSVGA).

• [7.6.1/H-3-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 896 MB jika layar default menggunakan resolusi framebuffer hingga FHD (misalnya, WSXGA+).

• [7.6.1/H-4-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 1344 MB jika layar default menggunakan resolusi framebuffer hingga QHD (misalnya, QWXGA).

Jika penerapan Perangkat genggam menyatakan dukungan ABI 64-bit (dengan atau tanpa ABI 32-bit):

• [7.6.1/H-5-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS berukuran minimal 816 MB jika layar default menggunakan resolusi framebuffer hingga qHD (misalnya, FWVGA).

• [7.6.1/H-6-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 944 MB jika layar default menggunakan resolusi framebuffer hingga HD+ (misalnya, HD, WSVGA).

• [7.6.1/H-7-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 1280 MB jika layar default menggunakan resolusi framebuffer hingga FHD (misalnya, WSXGA+).

• [7.6.1/H-8-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 1824 MB jika layar default menggunakan resolusi framebuffer hingga QHD (misalnya, QWXGA).

Perhatikan bahwa "memori yang tersedia untuk kernel dan ruang pengguna" di atas mengacu pada ruang memori yang disediakan selain memori yang sudah dikhususkan untuk komponen hardware seperti radio, video, dan sebagainya yang tidak berada di bawah kontrol kernel pada penerapan perangkat.

Jika implementasi Perangkat genggam menyertakan memori yang tersedia untuk kernel dan ruang pengguna kurang dari atau sama dengan 1 GB, maka:

• [7.6.1/H-9-1] HARUS mendeklarasikan tombol fitur android.hardware.ram.low.

• [7.6.1/H-9-2] HARUS memiliki penyimpanan tidak mudah berubah minimal 1,1 GB untuk data pribadi aplikasi (alias partisi "/data").

Jika implementasi Perangkat genggam mencakup lebih dari 1 GB memori yang tersedia untuk kernel dan ruang pengguna, maka:

• [7.6.1/H-10-1] HARUS memiliki setidaknya 4 GB penyimpanan non-volatile yang tersedia untuk data pribadi aplikasi (alias partisi "/data").

• HARUS mendeklarasikan tanda fitur android.hardware.ram.normal.

Jika implementasi Perangkat genggam mencakup memori yang tersedia untuk kernel dan ruang pengguna lebih besar dari atau sama dengan 2 GB dan kurang dari 4 GB, maka:

• [7.6.1/H-SR-1] SANGAT DISARANKAN untuk mendukung hanya ruang pengguna 32-bit (kode aplikasi dan sistem)

Jika implementasi Perangkat genggam mencakup memori kurang dari 2 GB yang tersedia untuk kernel dan ruang pengguna, maka:

• [7.6.1/H-1-1] HANYA boleh mendukung satu ABI (khusus 64-bit atau khusus 32-bit).

Implementasi perangkat genggam:

• [7.6.2/H-0-1] TIDAK BOLEH menyediakan penyimpanan bersama aplikasi yang lebih kecil dari 1 GiB.

• [7.7.1/H] HARUS menyertakan port USB yang mendukung mode periferal.

Jika implementasi perangkat genggam menyertakan port USB dengan pengontrol yang beroperasi dalam mode periferal, maka:

• [7.7.1/H-1-1] HARUS menerapkan Android Open Accessory (AOA) API.

Jika implementasi Perangkat genggam mencakup port USB yang mendukung mode host, maka:

• [7.7.2/H-1-1] HARUS menerapkan class audio USB seperti yang didokumentasikan dalam dokumentasi Android SDK.

Implementasi perangkat genggam:

• [7.8.1/H-0-1] HARUS menyertakan mikrofon.

• [7.8.2/H-0-1] HARUS memiliki output audio dan mendeklarasikan android.hardware.audio.output.

Jika penerapan Perangkat seluler mampu memenuhi semua persyaratan performa untuk mendukung mode VR dan menyertakan dukungan untuknya, maka:

• [7.9.1/H-1-1] HARUS mendeklarasikan tombol fitur android.hardware.vr.high_performance.

• [7.9.1/H-1-2] HARUS menyertakan penerapan aplikasi yang menerapkan android.service.vr.VrListenerService yang dapat diaktifkan oleh aplikasi VR melalui android.app.Activity#setVrModeEnabled.

Jika implementasi Perangkat genggam menyertakan satu atau beberapa port USB-C dalam mode host dan mengimplementasikan (kelas audio USB), selain persyaratan dalam bagian 7.7.2, perangkat tersebut:

• [7.8.2.2/H-1-1] HARUS menyediakan pemetaan software berikut dari kode HID:

Fungsi	Pemetaan	Konteks	Perilaku
A	Halaman penggunaan HID: 0x0C Penggunaan HID: 0x0CD Kunci kernel: KEY_PLAYPAUSE Kunci Android: KEYCODE_MEDIA_PLAY_PAUSE	Pemutaran media	Input: Tekan sebentar Output: Putar atau jeda
			Input: Tekan lama Output: Luncurkan perintah suara Mengirim: android.speech.action.VOICE_SEARCH_HANDS_FREE jika perangkat dikunci atau layarnya nonaktif. Mengirim android.speech.RecognizerIntent.ACTION_WEB_SEARCH jika tidak
		Panggilan masuk	Input: Tekan sebentar Output: Terima panggilan
			Input: Tekan lama Output: Tolak panggilan
		Panggilan sedang berlangsung	Input: Tekan sebentar Output: Akhiri panggilan
			Input: Tekan lama Output: Bisukan atau bunyikan mikrofon
B	Halaman penggunaan HID: 0x0C Penggunaan HID: 0x0E9 Kunci kernel: KEY_VOLUMEUP Kunci Android: VOLUME_UP	Pemutaran media, Panggilan sedang berlangsung	Input: Tekan sebentar atau lama Output: Menaikkan volume sistem atau headset
C	Halaman penggunaan HID: 0x0C Penggunaan HID: 0x0EA Kunci kernel: KEY_VOLUMEDOWN Kunci Android: VOLUME_DOWN	Pemutaran media, Panggilan sedang berlangsung	Input: Tekan sebentar atau lama Output: Menurunkan volume sistem atau headset
D	Halaman penggunaan HID: 0x0C Penggunaan HID: 0x0CF Kunci kernel: KEY_VOICECOMMAND Kunci Android: KEYCODE_VOICE_ASSIST	Semua. Dapat dipicu di instance mana pun.	Input: Tekan sebentar atau lama Output: Luncurkan perintah suara

• [7.8.2.2/H-1-2] HARUS memicu ACTION_HEADSET_PLUG saat steker dimasukkan, tetapi hanya setelah antarmuka dan endpoint audio USB dienumerasi dengan benar untuk mengidentifikasi jenis terminal yang terhubung.

Saat terminal audio USB jenis 0x0302 terdeteksi, terminal tersebut:

• [7.8.2.2/H-2-1] HARUS menyiarkan Intent ACTION_HEADSET_PLUG dengan setelan tambahan "microphone" ke 0.

Saat terminal audio USB jenis 0x0402 terdeteksi, terminal tersebut:

• [7.8.2.2/H-3-1] HARUS menyiarkan Intent ACTION_HEADSET_PLUG dengan setelan tambahan "microphone" ke 1.

Saat API AudioManager.getDevices() dipanggil saat periferal USB terhubung, API tersebut:

• [7.8.2.2/H-4-1] HARUS mencantumkan perangkat berjenis AudioDeviceInfo.TYPE_USB_HEADSET dan peran isSink() jika kolom jenis terminal audio USB adalah 0x0302.

• [7.8.2.2/H-4-2] HARUS mencantumkan perangkat berjenis AudioDeviceInfo.TYPE_USB_HEADSET dan peran isSink() jika kolom jenis terminal audio USB adalah 0x0402.

• [7.8.2.2/H-4-3] HARUS mencantumkan perangkat berjenis AudioDeviceInfo.TYPE_USB_HEADSET dan peran isSource() jika kolom jenis terminal audio USB adalah 0x0402.

• [7.8.2.2/H-4-4] HARUS mencantumkan perangkat berjenis AudioDeviceInfo.TYPE_USB_DEVICE dan peran isSink() jika kolom jenis terminal audio USB adalah 0x603.

• [7.8.2.2/H-4-5] HARUS mencantumkan perangkat berjenis AudioDeviceInfo.TYPE_USB_DEVICE dan peran isSource() jika kolom jenis terminal audio USB adalah 0x604.

• [7.8.2.2/H-4-6] HARUS mencantumkan perangkat berjenis AudioDeviceInfo.TYPE_USB_DEVICE dan peran isSink() jika kolom jenis terminal audio USB adalah 0x400.

• [7.8.2.2/H-4-7] HARUS mencantumkan perangkat berjenis AudioDeviceInfo.TYPE_USB_DEVICE dan peran isSource() jika kolom jenis terminal audio USB adalah 0x400.

• [7.8.2.2/H-SR-1] SANGAT DISARANKAN saat menghubungkan periferal audio USB-C, untuk melakukan enumerasi deskriptor USB, mengidentifikasi jenis terminal, dan menyiarkan Intent ACTION_HEADSET_PLUG dalam waktu kurang dari 1000 milidetik.

Untuk penerapan perangkat Genggam yang mendeklarasikan android.hardware.audio.output dan android.hardware.microphone, lihat persyaratan RTL dan TTL di bagian 5.6.

Aktuator resonansi linear (LRA) adalah sistem pegas massa tunggal yang memiliki frekuensi resonansi dominan di mana massa bergerak ke arah gerakan yang diinginkan.

Jika penerapan Perangkat genggam mencakup setidaknya satu aktuator resonansi linear 7.10 serbaguna, maka:

• [7.10/H] HARUS memosisikan penempatan aktuator di dekat lokasi tempat perangkat biasanya dipegang atau disentuh dengan tangan.

• [7.10/H] HARUS menggerakkan aktuator haptik pada sumbu X (kiri-kanan) dari orientasi alami perangkat.

Jika penerapan Perangkat genggam memiliki aktuator haptik serbaguna yang merupakan aktuator resonansi linear (LRA) sumbu X, maka:

• [7.10/H] HARUS memiliki frekuensi resonansi LRA sumbu X di bawah 200 Hz.

Jika penerapan perangkat genggam mengikuti pemetaan konstanta haptik, maka:

• [7.10/H]^* HARUS memverifikasi status penerapan dengan menjalankan API android.os.Vibrator.areAllEffectsSupported() dan android.os.Vibrator.arePrimitivesSupported().

• [7.10/H]^* HARUS melakukan penilaian kualitas untuk konstanta haptik.

• [7.10/H]^* HARUS memverifikasi dan memperbarui jika diperlukan konfigurasi penggantian untuk primitif yang tidak didukung seperti yang dijelaskan dalam panduan penerapan untuk konstanta.

2.2.2. Multimedia

Penerapan perangkat genggam HARUS mendukung format encoding dan decoding audio berikut serta menyediakannya untuk aplikasi pihak ketiga:

• [5.1/H-0-1] AMR-NB
• [5.1/H-0-2] AMR-WB
• [5.1/H-0-3] Profil AAC MPEG-4 (AAC LC)
• [5.1/H-0-4] Profil MPEG-4 HE AAC (AAC+)
• [5.1/H-0-5] AAC ELD (AAC yang ditingkatkan dengan delay rendah)

2.2.3. Software

Penerapan perangkat genggam HARUS mendukung format encoding video berikut dan menyediakannya untuk aplikasi pihak ketiga:

• [5.2/H-0-1] H.264 AVC
• [5.2/H-0-2] VP8
• [5.2/H-0-3] AV1

Penerapan perangkat genggam HARUS mendukung format decoding video berikut dan menyediakannya untuk aplikasi pihak ketiga:

• [5.3/H-0-1] H.264 AVC
• [5.3/H-0-2] H.265 HEVC
• [5.3/H-0-3] MPEG-4 SP
• [5.3/H-0-4] VP8
• [5.3/H-0-5] VP9
• [5.3/H-0-6] AV1

2.2.3. Software

Implementasi perangkat genggam:

• [3.2.3.1/H-0-1] HARUS memiliki aplikasi yang menangani intent ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE, dan ACTION_CREATE_DOCUMENT seperti yang dijelaskan dalam dokumen SDK, dan menyediakan kemudahan bagi pengguna untuk mengakses data penyedia dokumen menggunakan DocumentsProvider API.

• [3.2.3.1/H-SR-1] SANGAT DISARANKAN untuk memuat aplikasi email yang dapat menangani maksud ACTION_SENDTO atau ACTION_SEND atau ACTION_SEND_MULTIPLE untuk mengirim email.

• [3.4.1/H-0-1] HARUS menyediakan implementasi lengkap android.webkit.Webview API.

• [3.4.2/H-0-1] HARUS menyertakan aplikasi Browser mandiri untuk penjelajahan web pengguna umum.

• [3.8.1/H-SR-1] SANGAT DISARANKAN untuk menerapkan peluncur default yang mendukung penyematan pintasan, widget, dan widgetFeatures dalam aplikasi.

• [3.8.1/H-SR-2] SANGAT DISARANKAN untuk menerapkan peluncur default yang menyediakan akses cepat ke pintasan tambahan yang disediakan oleh aplikasi pihak ketiga melalui API ShortcutManager.

• [3.8.1/H-SR-3] SANGAT DISARANKAN untuk menyertakan aplikasi peluncur default yang menampilkan badge untuk ikon aplikasi.

• [3.8.3/H-0-1] HARUS mengizinkan aplikasi pihak ketiga memberi tahu pengguna tentang peristiwa penting melalui class API Notification dan NotificationManager.

• [3.8.3/H-0-2] HARUS mendukung notifikasi lengkap.

• [3.8.3/H-0-3] HARUS mendukung notifikasi pop-up.

• [3.8.3/H-0-4] HARUS menyertakan menu notifikasi, yang memberi pengguna kemampuan untuk mengontrol notifikasi secara langsung (misalnya, membalas, menunda, menutup, memblokir) melalui kemudahan pengguna seperti tombol tindakan atau panel kontrol sebagaimana diterapkan di AOSP.

• [3.8.3/H-0-5] HARUS menampilkan pilihan yang diberikan melalui RemoteInput.Builder setChoices() di panel notifikasi.

• [3.8.3/H-SR-1] SANGAT DISARANKAN untuk menampilkan pilihan pertama yang diberikan melalui RemoteInput.Builder setChoices() di panel notifikasi tanpa interaksi pengguna tambahan.

• [3.8.3/H-SR-2] SANGAT DISARANKAN untuk menampilkan semua pilihan yang diberikan melalui RemoteInput.Builder setChoices() di menu notifikasi saat pengguna meluaskan semua notifikasi di menu notifikasi.

• [3.8.3.1/H-SR-1] SANGAT DISARANKAN untuk menampilkan tindakan yang Notification.Action.Builder.setContextual ditetapkan sebagai true sejalan dengan balasan yang ditampilkan oleh Notification.Remoteinput.Builder.setChoices.

• [3.8.4/H-SR-1] SANGAT DISARANKAN untuk menerapkan asisten di perangkat guna menangani tindakan Bantu.

Jika penerapan perangkat Genggam mendukung notifikasi MediaStyle maka:

• [3.8.3.1/H-SR-2] SANGAT DISARANKAN untuk menyediakan kemudahan pengguna (misalnya, pengalih output) yang diakses dari UI sistem yang memungkinkan pengguna beralih di antara rute media yang tersedia dan sesuai (misalnya, perangkat dan rute Bluetooth yang disediakan untuk MediaRouter2Manager) saat aplikasi memposting notifikasi MediaStyle dengan token MediaSession.

Notifikasi Update Langsung aplikasi dapat dipromosikan jika aplikasi memenuhi semua karakteristik promosi. Notifikasi tersebut dijelaskan sebagai Notifikasi Update Langsung yang Dipromosikan dalam dokumen ini. Implementasi perangkat genggam HARUS menampilkan Notifikasi Update Langsung yang Dipromosikan secara jelas sesuai dengan persyaratan berikut.

Jika implementasi perangkat Genggam mendeklarasikan level API 36.1 atau yang lebih tinggi, maka:

• [3.8.3.1/H-0-1] HARUS menampilkan Notifikasi Update Langsung yang Dipromosikan di tempat yang terlihat jelas di layar kunci.

• [3.8.3.1/H-0-12] HARUS ditampilkan di bagian atas tumpukan notifikasi Notifikasi Pendahuluan dan di atas notifikasi berwarna (jika setColorized adalah true) saat Notifikasi Info Terbaru Live yang Dipromosikan ditampilkan di antara notifikasi lainnya.

  • DAPAT menentukan urutan notifikasi Update Langsung yang Dipromosikan yang ditampilkan di area notifikasi dan layar kunci jika lebih dari satu aplikasi memenuhi syarat untuk Notifikasi Update Langsung yang Dipromosikan.

• [3.8.3.1/H-0-2] HARUS menampilkan Notifikasi Info Terbaru Live yang Dipromosikan dalam status yang diperluas.

• [3.8.3.1/H-0-3] TIDAK BOLEH menyediakan kemudahan pengguna untuk menciutkan notifikasi yang diperluas di atas.

• [3.8.3.1/H-0-4] HARUS menampilkan gaya dasar (tebal, miring, dan garis bawah) konten teks dalam Notifikasi Info Terbaru Live yang Dipromosikan, sebagaimana disediakan oleh StyleSpan atau UnderlineSpan.

• [3.8.3.1/H-0-5] HARUS menampilkan hanya objek tindakan standar (melalui Notification.Action), dan HARUS menyembunyikan objek tindakan non-standar seperti kotak input, tombol balas, dan tindakan kontekstual (melalui addRemoteInput() dan setContextual()) dalam Notifikasi Info Terbaru Live yang Dipromosikan, meskipun notifikasi tersebut memuatnya.

• [3.8.3.1/H-0-6] HARUS menampilkan Representasi Ringkas, yang juga disebut sebagai Chip Status dalam dokumentasi SDK, untuk Notifikasi Update Langsung yang Dipromosikan yang HARUS mencakup Notification.getSmallIcon().

  • [3.8.3.1/H-0-7] Kolom lain bersifat opsional untuk Representasi Ringkas, tetapi setiap kali representasi ringkas dapat diperluas, HARUS menampilkan Notification.getShortCriticalText() jika ada, atau Notification.when jika Notification.getShortCriticalText tidak ada.

  • [3.8.3.1/H-0-8] Jika ada lebih dari satu notifikasi Update Langsung yang Dipromosikan, HARUS menampilkan setidaknya salah satunya di status bar sebagai Representasi Ringkas.

  • [3.8.3.1/H-0-9] HARUS menampilkan notifikasi terkait (lebih disukai) atau membuka aplikasi terkait (melalui Notification.contentIntent), saat pengguna mengetuk Representasi Ringkas.

  • [3.8.3.1/H-0-13] HARUS menampilkan semua konten yang sama di notifikasi terkait seperti yang tersedia di panel notifikasi.

• [3.8.3.1/H-0-10] HARUS menyediakan kemudahan bagi pengguna untuk menonaktifkan dan mengaktifkan tampilan yang dipromosikan dari notifikasi aplikasi individual.

• [3.8.3.1/H-0-11] HARUS merender semua Notifikasi Info Terbaru dengan benar, termasuk, tetapi tidak terbatas pada Notifikasi Info Terbaru yang tidak dipromosikan yang tidak atau hanya sebagian memenuhi karakteristik promosi. Notifikasi yang tidak dipromosikan tersebut HARUS ditampilkan dalam status tidak dipromosikan.

Jika penerapan perangkat yang menyertakan tombol navigasi fungsi recent seperti yang dijelaskan dalam bagian 7.2.3 mengubah antarmuka, maka:

• [3.8.3/H-1-1] HARUS menerapkan perilaku penyematan layar dan menyediakan menu setelan kepada pengguna untuk mengaktifkan/menonaktifkan fitur tersebut.

Jika implementasi perangkat Genggam mendukung tindakan Bantu, maka:

• [3.8.4/H-SR-2] SANGAT DISARANKAN untuk menggunakan tekan lama pada tombol HOME sebagai interaksi yang ditetapkan untuk meluncurkan aplikasi bantuan seperti yang dijelaskan dalam bagian 7.2.3. HARUS meluncurkan aplikasi bantuan yang dipilih pengguna; dengan kata lain, aplikasi yang menerapkan VoiceInteractionService, atau aktivitas yang menangani intent ACTION_ASSIST.

Jika implementasi Perangkat genggam mendukung conversation notifications dan mengelompokkannya ke dalam bagian terpisah dari notifikasi peringatan dan non-percakapan senyap, maka:

• [3.8.4/H-1-1]^* HARUS menampilkan notifikasi percakapan sebelum notifikasi non-percakapan dengan pengecualian notifikasi layanan latar depan yang sedang berlangsung dan notifikasi importance:high.

Jika implementasi perangkat Genggam Android mendukung layar kunci, maka:

• [3.8.10/H-1-1] HARUS menampilkan Notifikasi Layar kunci termasuk Template Notifikasi Media.

Jika implementasi perangkat Genggam mendukung layar kunci yang aman, maka:

• [3.9/H-1-1] HARUS menerapkan berbagai kebijakan administrasi perangkat yang ditentukan dalam dokumentasi Android SDK.

Jika penerapan Perangkat genggam mencakup dukungan untuk ControlsProviderService dan Control API serta mengizinkan aplikasi pihak ketiga untuk memublikasikan kontrol perangkat, maka:

• [3.8.16/H-1-1] HARUS mendeklarasikan tanda fitur android.software.controls dan menyetelnya ke true.

• [3.8.16/H-1-2] HARUS menyediakan kemudahan pengguna dengan kemampuan untuk menambahkan, mengedit, memilih, dan mengoperasikan kontrol perangkat favorit pengguna dari kontrol yang didaftarkan oleh aplikasi pihak ketiga melalui ControlsProviderService dan Control API.

• [3.8.16/H-1-3] HARUS menyediakan akses ke kemampuan pengguna ini dalam tiga interaksi dari Peluncur default.

• [3.8.16/H-1-4] HARUS merender secara akurat dalam kemampuan pengguna ini nama dan ikon setiap aplikasi pihak ketiga yang menyediakan kontrol melalui ControlsProviderService API serta kolom tertentu yang disediakan oleh Control API.

• [3.8.16/H-1-5] HARUS menyediakan kemudahan pengguna untuk memilih tidak menggunakan kontrol perangkat sepele yang ditetapkan aplikasi dari kontrol yang didaftarkan oleh aplikasi pihak ketiga melalui ControlsProviderService dan Control Control.isAuthRequired API.

• [3.8.16/H-1-6] Implementasi perangkat HARUS merender keunggulan pengguna secara akurat sebagai berikut:

  • Jika perangkat telah menyetel config_supportsMultiWindow=true dan aplikasi mendeklarasikan metadata META_DATA_PANEL_ACTIVITY dalam deklarasi ControlsProviderService, termasuk ComponentName dari aktivitas yang valid (seperti yang ditentukan oleh API), maka aplikasi HARUS menyematkan aktivitas tersebut dalam kemudahan pengguna ini.
  • Jika aplikasi tidak mendeklarasikan metadata META_DATA_PANEL_ACTIVITY, maka aplikasi HARUS merender kolom yang ditentukan sebagaimana disediakan oleh ControlsProviderService API serta kolom yang ditentukan yang disediakan oleh Control API.

• [3.8.16/H-1-7] Jika aplikasi mendeklarasikan metadata META_DATA_PANEL_ACTIVITY, aplikasi HARUS meneruskan setelan yang ditentukan dalam [3.8.16/H-1-5] menggunakan EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS saat meluncurkan aktivitas yang disematkan.

Sebaliknya, jika penerapan Perangkat genggam tidak menerapkan kontrol tersebut, maka:

• [3.8.16/H-2-1] HARUS melaporkan null untuk ControlsProviderService dan Control API.

• [3.8.16/H-2-2] HARUS mendeklarasikan tanda fitur android.software.controls dan menyetelnya ke false.

Jika penerapan perangkat genggam tidak berjalan dalam mode tugas terkunci, saat konten disalin ke papan klip, konten tersebut:

• [3.8.17/H-1-1] HARUS menampilkan konfirmasi kepada pengguna bahwa data telah disalin ke papan klip (misalnya, thumbnail atau pemberitahuan "Konten disalin"). Selain itu, sertakan di sini indikasi apakah data papan klip akan disinkronkan di seluruh perangkat.

Implementasi perangkat genggam:

• [3.10/H-0-1] HARUS mendukung layanan aksesibilitas pihak ketiga.

• [3.10/H-SR-1] SANGAT DISARANKAN untuk memuat layanan aksesibilitas di perangkat yang sebanding dengan atau melebihi fungsionalitas layanan aksesibilitas Tombol Akses dan TalkBack (untuk bahasa yang didukung oleh mesin Text-to-speech yang telah diinstal sebelumnya) sebagaimana disediakan dalam project open source TalkBack.

• [3.11/H-0-1] HARUS mendukung penginstalan mesin TTS pihak ketiga.

• [3.11/H-SR-1] SANGAT DISARANKAN untuk menyertakan mesin TTS yang mendukung bahasa yang tersedia di perangkat.

• [3.13/H-SR-1] SANGAT DISARANKAN untuk menyertakan komponen UI Setelan Cepat.

Jika penerapan perangkat seluler Android mendeklarasikan dukungan FEATURE_BLUETOOTH atau FEATURE_WIFI, maka:

• [3.16/H-1-1] HARUS mendukung fitur penyambungan perangkat pendamping.

Jika fungsi navigasi disediakan sebagai tindakan berbasis gestur di layar:

• [7.2.3/H] Area pengenalan gestur untuk fungsi Beranda SEBAIKNYA tidak lebih tinggi dari 32 dp dari bagian bawah layar.

Jika penerapan Perangkat genggam menyediakan fungsi navigasi sebagai gestur dari mana saja di tepi kiri dan kanan layar:

• [7.2.3/H-0-1] Area gestur fungsi navigasi HARUS kurang dari 40 dp lebarnya di setiap sisi. Area gestur SEHARUSNYA berukuran lebar 24 dp secara default.

Jika penerapan Perangkat genggam mendukung layar kunci yang aman dan memiliki memori lebih besar dari atau sama dengan 2 GB yang tersedia untuk kernel dan ruang pengguna, perangkat tersebut:

• [3.9/H-1-2] HARUS mendeklarasikan dukungan profil terkelola melalui flag fitur android.software.managed_users.

Jika penerapan perangkat genggam Android mendeklarasikan dukungan untuk kamera melalui android.hardware.camera.any, maka:

• [7.5.4/H-1-1] HARUS mematuhi android.media.action.STILL_IMAGE_CAMERA dan android.media.action.STILL_IMAGE_CAMERA_SECURE maksud dan meluncurkan kamera dalam mode gambar diam seperti yang dijelaskan dalam SDK.

• [7.5.4/H-1-2] HARUS mematuhi maksud android.media.action.VIDEO_CAMERA untuk meluncurkan kamera dalam mode video seperti yang dijelaskan dalam SDK.

Jika aplikasi setelan implementasi perangkat menerapkan fungsi pemisahan, menggunakan penyematan aktivitas, aplikasi tersebut:

• [3.2.3.1/ H-1-1] HARUS memiliki aktivitas yang menangani intent Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY saat fungsi pemisahan aktif. Aktivitas HARUS dilindungi oleh android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK, dan HARUS memulai aktivitas Intent yang diuraikan dari Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.

2.2.4. Performa dan Daya

• [8.1/H-0-1] Latensi frame yang konsisten. Latensi frame yang tidak konsisten atau penundaan untuk merender frame TIDAK BOLEH terjadi lebih sering daripada 5 frame dalam satu detik, dan SEBAIKNYA di bawah 1 frame dalam satu detik.

• [8.1/H-0-2] Latensi antarmuka pengguna. Implementasi perangkat HARUS memastikan pengalaman pengguna dengan latensi rendah dengan men-scroll daftar 10.000 entri daftar sebagaimana ditentukan oleh Android Compatibility Test Suite (CTS) dalam waktu kurang dari 36 detik.

• [8.1/H-0-3] Pengalihan tugas. Jika beberapa aplikasi telah diluncurkan, peluncuran ulang aplikasi yang sudah berjalan setelah diluncurkan HARUS memakan waktu kurang dari 1 detik.

Implementasi perangkat genggam:

• [8.2/H-0-1] HARUS memastikan performa tulis berurutan minimal 5 MB/dtk.

• [8.2/H-0-2] HARUS memastikan performa penulisan acak minimal 0,5 MB/dtk.

• [8.2/H-0-3] HARUS memastikan performa baca berurutan minimal 15 MB/dtk.

• [8.2/H-0-4] HARUS memastikan performa baca acak minimal 3,5 MB/s.

Jika implementasi perangkat Genggam mencakup fitur untuk meningkatkan pengelolaan daya perangkat yang disertakan dalam AOSP atau memperluas fitur yang disertakan dalam AOSP, maka:

• [8.3/H-1-1] HARUS menyediakan kemudahan pengguna untuk mengaktifkan dan menonaktifkan fitur penghemat baterai.

• [8.3/H-1-2] HARUS menyediakan kemudahan pengguna untuk menampilkan semua aplikasi yang dikecualikan dari mode hemat daya Istirahatkan dan Aplikasi Standby.

Implementasi perangkat genggam:

• [8.4/H-0-1] HARUS menyediakan profil daya per komponen yang menentukan nilai konsumsi arus untuk setiap komponen hardware dan perkiraan pengurasan baterai yang disebabkan oleh komponen dari waktu ke waktu seperti yang didokumentasikan di situs Android Open Source Project.

• [8.4/H-0-2] HARUS melaporkan semua nilai konsumsi daya dalam miliampere jam (mAh).

• [8.4/H-0-3] HARUS melaporkan konsumsi daya CPU per UID setiap proses. Project Open Source Android memenuhi persyaratan melalui penerapan modul kernel uid_cputime.

• [8.4/H-0-4] HARUS menyediakan penggunaan daya ini melalui perintah shell adb shell dumpsys batterystats kepada developer aplikasi.

• [8.4/H] HARUS diatribusikan ke komponen hardware itu sendiri jika tidak dapat mengatribusikan penggunaan daya komponen hardware ke aplikasi.

Jika implementasi perangkat Genggam mencakup output layar atau video, maka:

• [8.4/H-1-1] HARUS mematuhi maksud android.intent.action.POWER_USAGE_SUMMARY dan menampilkan menu setelan yang menunjukkan penggunaan daya ini.

Implementasi perangkat genggam:

• [8.5/H-0-1] HARUS menyediakan kemudahan pengguna untuk melihat semua aplikasi dengan layanan latar depan aktif atau tugas yang dimulai pengguna, termasuk durasi setiap layanan ini sejak dimulai seperti yang dijelaskan dalam dokumen SDK.

• [8.5/H-0-2]HARUS menyediakan kemudahan pengguna untuk menghentikan aplikasi yang menjalankan layanan latar depan atau tugas yang dimulai pengguna.

2.2.5. Model Keamanan

Implementasi perangkat genggam:

• [9/H-0-1] HARUS mendeklarasikan fitur android.hardware.security.model.compatible.

• [9.1/H-0-1] HARUS mengizinkan aplikasi pihak ketiga mengakses statistik penggunaan melalui izin android.permission.PACKAGE_USAGE_STATS dan menyediakan mekanisme yang dapat diakses pengguna untuk memberikan atau mencabut akses ke aplikasi tersebut sebagai respons terhadap maksud android.settings.ACTION_USAGE_ACCESS_SETTINGS.

Jika penerapan Perangkat genggam menyertakan aplikasi default untuk mendukung VoiceInteractionService, maka:

• [9.1/H-0-2] TIDAK BOLEH memberikan ACCESS_FINE_LOCATION sebagai default untuk aplikasi tersebut.

Implementasi perangkat HARUS menyatakan dukungan untuk android.software.credentials dan:

• [9/H-0-2] HARUS mematuhi maksud android.settings.CREDENTIAL_PROVIDER untuk mengizinkan pemilihan penyedia pilihan untuk Pengelola Kredensial. Penyedia ini akan diaktifkan untuk Isi Otomatis dan juga akan menjadi lokasi default untuk menyimpan kredensial baru yang dimasukkan melalui Pengelola Kredensial.

• [9/H-0-3] HARUS mendukung minimal 2 penyedia kredensial serentak dan menyediakan kemudahan pengguna di aplikasi Setelan untuk mengaktifkan atau menonaktifkan penyedia.

• [9.5/H-1-1] Persyaratan dihapus di Android 16.

Implementasi perangkat genggam:

• [9.11/H-0-2] HARUS mencadangkan penerapan keystore dengan lingkungan eksekusi yang terisolasi.

• [9.11/H-0-3] HARUS memiliki penerapan algoritma kriptografi RSA, AES, ECDSA, dan HMAC serta fungsi hash MD5, SHA-1, dan SHA-2 untuk mendukung algoritma yang didukung sistem Android Keystore dengan benar di area yang terisolasi secara aman dari kode yang berjalan di kernel dan di atasnya. Isolasi aman HARUS memblokir semua potensi mekanisme yang memungkinkan kode kernel atau ruang pengguna mengakses status internal lingkungan yang diisolasi, termasuk DMA. Android Open Source Project (AOSP) upstream memenuhi persyaratan ini dengan menggunakan implementasi Trusty, tetapi solusi lain berbasis ARM TrustZone atau implementasi aman yang ditinjau pihak ketiga dari isolasi berbasis hypervisor yang tepat adalah opsi alternatif.

• [9.11/H-0-4] HARUS melakukan autentikasi layar kunci di lingkungan eksekusi yang terisolasi dan hanya jika berhasil, mengizinkan penggunaan kunci yang terikat dengan autentikasi. Kredensial layar kunci HARUS disimpan dengan cara yang hanya memungkinkan lingkungan eksekusi terisolasi melakukan autentikasi layar kunci. Proyek Open Source Android upstream menyediakan Hardware Abstraction Layer (HAL) Gatekeeper dan Trusty, yang dapat digunakan untuk memenuhi persyaratan ini.

• [9.11/H-0-5] HARUS mendukung pengesahan kunci dengan kunci penandatanganan pengesahan dilindungi oleh hardware aman dan penandatanganan dilakukan di hardware aman. Kunci penandatanganan pengesahan TIDAK BOLEH digunakan sebagai ID perangkat permanen.

Perhatikan bahwa jika implementasi perangkat sudah diluncurkan di versi Android sebelumnya, perangkat tersebut dikecualikan dari persyaratan untuk memiliki keystore yang didukung oleh lingkungan eksekusi terisolasi dan mendukung pengesahan kunci, kecuali jika perangkat tersebut mendeklarasikan fitur android.hardware.fingerprint yang memerlukan keystore yang didukung oleh lingkungan eksekusi terisolasi.

Jika implementasi perangkat Genggam mendukung layar kunci yang aman, maka:

• [9.11/H-1-1] HARUS mengizinkan pengguna memilih waktu tunggu tidur terpendek, yaitu waktu transisi dari status tidak terkunci ke status terkunci, yaitu 15 detik atau kurang.

• [9.11/H-1-2] HARUS menyediakan kemudahan pengguna untuk menyembunyikan notifikasi dan menonaktifkan semua bentuk autentikasi kecuali autentikasi utama yang dijelaskan dalam 9.11.1 Layar Kunci Aman. AOSP memenuhi persyaratan sebagai mode kunci total.

Jika penerapan Perangkat genggam mencakup beberapa pengguna dan tidak mendeklarasikan tanda fitur android.hardware.telephony, maka:

• [9.5/H-2-1] HARUS mendukung profil terbatas, fitur yang memungkinkan pemilik perangkat mengelola pengguna tambahan dan kemampuannya di perangkat. Dengan profil yang dibatasi, pemilik perangkat dapat dengan cepat menyiapkan lingkungan terpisah bagi pengguna tambahan untuk bekerja, dengan kemampuan untuk mengelola pembatasan yang lebih mendetail dalam aplikasi yang tersedia di lingkungan tersebut.

Jika penerapan Perangkat genggam mencakup beberapa pengguna dan mendeklarasikan tanda fitur android.hardware.telephony, maka:

• [9.5/H-3-1] TIDAK BOLEH mendukung profil terbatas, tetapi HARUS selaras dengan penerapan kontrol AOSP untuk mengaktifkan /menonaktifkan pengguna lain mengakses panggilan suara dan SMS.

• [9.5/H-4-1] Persyaratan dihapus di Android 16.

• [9.5/H-4-2] Persyaratan dihapus di Android 16.

Setelan dibatasi

Setelan Terbatas memberikan peringatan yang terlihat kepada pengguna dan meminta konfirmasi pengguna untuk memberikan izin bagi setiap aplikasi yang:

• Diinstal setelah didownload melalui aplikasi (misalnya, aplikasi pesan atau browser) selain aplikasi "app store" yang diidentifikasi oleh PackageManager sebagai PACKAGE_DOWNLOADED_FILE.

• Diinstal dari file lokal (misalnya, aplikasi di-sideload) yang diidentifikasi oleh PackageManager sebagai PACKAGE_SOURCE_LOCAL_FILE.

Untuk setiap Izin yang Diterapkan dan ID terkaitnya yang tercantum dalam [9.8/H-0-5] di bawah.

Aplikasi tersebut diberi label "Aplikasi yang Tercakup" untuk persyaratan yang tercantum di bagian ini.

Implementasi perangkat:

• [9.8/H-0-1] HARUS menerapkan Setelan Terbatas seperti yang diuraikan di atas untuk hal berikut:

  • Izin khusus

    • Aksesibilitas (AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE)
    • Pendengar notifikasi (AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS)
    • Aplikasi admin perangkat (Manifest.permission.BIND_DEVICE_ADMIN)
    • Tampilkan di atas aplikasi lain (AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW)
    • Akses penggunaan (AppOpsManager.OPSTR_GET_USAGE_STATS)

  • Peran (Aplikasi default)

    • Ponsel (RoleManager.ROLE_DIALER)
    • SMS (RoleManager.ROLE_SMS)

  • Izin runtime

    • Durasi SMS (Manifest.permission_group.SMS)

• [9.8/H-0-2] HARUS mengaktifkan Setelan Terbatas sebagai default dan SANGAT DISARANKAN untuk tidak memiliki kemampuan pengguna yang memungkinkan pengguna menonaktifkan Setelan Terbatas untuk semua aplikasi.

• [9.8/H-0-3] HARUS memastikan konfirmasi pengguna diperoleh untuk setiap Aplikasi yang Tercakup sebelum Izin yang Diberlakukan dapat diberikan.

• [9.8/H-0-4] HANYA boleh mengizinkan konfirmasi pengguna untuk mengaktifkan setelan terbatas diperoleh dari halaman AppInfo Aplikasi yang Tercakup, menggunakan API EnhancedConfirmationManager.

• [9.8/H-0-5] SANGAT DISARANKAN untuk diintegrasikan dengan dan memanggil EnhancedConfirmationManager untuk semua izin khusus, guna menentukan secara dinamis apakah izin tersebut merupakan setelan terbatas.

  • Alarm dan pengingat: AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
  • Akses semua file: AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
  • Tampilkan menindih aplikasi lain: AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
  • Menginstal aplikasi yang tidak dikenal: AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
  • Mengelola media: AppOpsManager.OPSTR_MANAGE_MEDIA
  • Ubah setelan sistem: AppOpsManager.OPSTR_WRITE_SETTINGS
  • Picture-in-picture: AppOpsManager.OPSTR_PICTURE_IN_PICTURE
  • Aktifkan layar: AppOpsManager.OPSTR_TURN_SCREEN_ON
  • Notifikasi layar penuh: AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
  • Kontrol Wi-Fi: AppOpsManager.OPSTR_CHANGE_WIFI_STATE
  • Aksesibilitas: AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
  • Pendengar notifikasi: AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
  • Akses penggunaan: AppOpsManager.OPSTR_GET_USAGE_STATS
  • Admin perangkat: Manifest.permission.BIND_DEVICE_ADMIN
  • Jangan ganggu: Manifest.permission.MANAGE_NOTIFICATIONS

Android, melalui VoiceInteractionService API Sistem, mendukung mekanisme untuk deteksi frasa pengaktif suara yang selalu aktif dan aman tanpa indikasi akses mikrofon dan deteksi kueri yang selalu aktif, tanpa indikasi akses mikrofon atau kamera.

Jika implementasi perangkat Genggam mendukung System API HotwordDetectionService atau mekanisme lain untuk deteksi kata kunci tanpa indikasi akses mikrofon, implementasi tersebut:

• [9.8/H-1-1] HARUS memastikan layanan deteksi kata kunci hanya dapat mengirimkan data ke Sistem, ContentCaptureService, atau layanan pengenalan ucapan di perangkat yang dibuat oleh SpeechRecognizer#createOnDeviceSpeechRecognizer().

• [9.8/H-1-2] HARUS memastikan layanan deteksi kata kunci hanya dapat mengirimkan data audio mikrofon atau data yang berasal darinya ke server sistem melalui HotwordDetectionService API, atau ke ContentCaptureService melalui ContentCaptureManager API.

• [9.8/H-1-3] TIDAK BOLEH menyediakan audio mikrofon yang lebih panjang dari 30 detik untuk setiap permintaan yang dipicu hardware ke layanan deteksi kata kunci.

• [9.8/H-1-4] TIDAK BOLEH menyediakan audio mikrofon yang di-buffer yang lebih lama dari 8 detik untuk permintaan individual ke layanan deteksi frasa pengaktif suara.

• [9.8/H-1-5] TIDAK BOLEH menyediakan audio mikrofon yang di-buffer lebih dari 30 detik ke layanan interaksi suara atau entitas serupa.

• [9.8/H-1-6] TIDAK BOLEH mengizinkan lebih dari 100 byte data (tidak termasuk streaming audio) ditransmisikan dari layanan deteksi hotword pada setiap hasil hotword yang berhasil.

• [9.8/H-1-7] TIDAK BOLEH mengizinkan lebih dari 5 bit data dikirimkan dari layanan deteksi frasa pengaktif pada setiap hasil frasa pengaktif negatif.

• [9.8/H-1-8] HANYA boleh mengizinkan transmisi data keluar dari layanan deteksi hotword pada permintaan validasi hotword dari server sistem.

• [9.8/H-1-9] TIDAK BOLEH mengizinkan aplikasi yang dapat diinstal pengguna untuk menyediakan layanan deteksi kata kunci.

• [9.8/H-1-10] TIDAK BOLEH menampilkan data kuantitatif tentang penggunaan mikrofon oleh layanan deteksi frasa pengaktif di UI.

• [9.8/H-1-11] HARUS mencatat jumlah byte yang disertakan dalam setiap transmisi dari layanan deteksi kata kunci untuk memungkinkan peneliti keamanan memeriksa.

• [9.8/H-1-12] HARUS mendukung mode debug yang mencatat konten mentah setiap transmisi dari layanan deteksi frasa pengaktif untuk memungkinkan inspeksi oleh peneliti keamanan.

• [9.8/H-1-14] HARUS menampilkan indikator mikrofon, seperti yang dijelaskan di bagian 9.8.2, saat hasil kata kunci aktif yang berhasil dikirimkan ke layanan interaksi suara atau entitas serupa.

• [9.8/H-1-15] HARUS memastikan bahwa aliran audio yang diberikan pada hasil frasa pengaktif yang berhasil dikirimkan satu arah dari layanan deteksi frasa pengaktif ke layanan interaksi suara.

• [9.8/H-SR-1] SANGAT DISARANKAN untuk memberi tahu pengguna sebelum menetapkan aplikasi sebagai penyedia layanan deteksi kata kunci.

• [9.8/H-SR-2] SANGAT DISARANKAN untuk melarang transmisi data tidak terstruktur dari layanan deteksi hotword.

• [9.8/H-SR-3] SANGAT DISARANKAN untuk memulai ulang proses yang menghosting layanan deteksi kata kunci setidaknya sekali setiap jam atau setiap 30 peristiwa pemicu hardware, mana saja yang lebih dulu.

Jika implementasi perangkat menyertakan aplikasi yang menggunakan System API HotwordDetectionService, atau mekanisme serupa untuk deteksi kata kunci tanpa indikasi penggunaan mikrofon, aplikasi tersebut:

• [9.8/H-2-1] HARUS memberikan pemberitahuan eksplisit kepada pengguna untuk setiap frasa kata kunci yang didukung.

• [9.8/H-2-2] TIDAK BOLEH menyimpan data audio mentah, atau data yang berasal darinya, melalui layanan deteksi kata kunci.

• [9.8/H-2-3] TIDAK BOLEH mengirimkan dari layanan deteksi kata kunci, data audio, data yang dapat digunakan untuk merekonstruksi (seluruhnya atau sebagian) audio, atau konten audio yang tidak terkait dengan kata kunci itu sendiri, kecuali ke layanan pengenalan ucapan ContentCaptureService atau di perangkat.

Jika implementasi Perangkat genggam mendukung API Sistem VisualQueryDetectionService atau mekanisme lain untuk deteksi kueri tanpa indikasi akses mikrofon dan/atau kamera, maka:

• [9.8/H-3-1] HARUS memastikan layanan deteksi kueri hanya dapat mengirimkan data ke Sistem, atau ContentCaptureService, atau layanan pengenalan ucapan di perangkat (dibuat oleh SpeechRecognizer#createOnDeviceSpeechRecognizer()).

• [9.8/H-3-2] TIDAK BOLEH mengizinkan informasi audio atau video apa pun dikirimkan keluar dari VisualQueryDetectionService, kecuali ke ContentCaptureService atau layanan pengenalan ucapan di perangkat.

• [9.8/H-3-3] HARUS menampilkan pemberitahuan pengguna di UI Sistem saat perangkat mendeteksi niat pengguna untuk berinteraksi dengan Aplikasi Asisten Digital (misalnya, dengan mendeteksi kehadiran pengguna melalui kamera).

• [9.8/H-3-4] HARUS menampilkan indikator mikrofon dan menampilkan kueri pengguna yang terdeteksi di UI tepat setelah kueri pengguna terdeteksi.

• [9.8/H-3-5] TIDAK BOLEH mengizinkan aplikasi yang dapat diinstal pengguna untuk menyediakan layanan deteksi kueri visual.

Jika implementasi Perangkat genggam mendeklarasikan android.hardware.microphone, implementasi tersebut:

• [9.8.2/H-4-1] HARUS menampilkan indikator mikrofon saat aplikasi mengakses data audio dari mikrofon, tetapi tidak saat mikrofon hanya diakses oleh HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService, atau aplikasi yang memiliki peran yang disebutkan di bagian 9.1 dengan ID CDD [C-4-X].

• [9.8.2/H-4-2] HARUS menampilkan daftar aplikasi Terbaru dan Aktif yang menggunakan mikrofon seperti yang ditampilkan dari PermissionManager.getIndicatorAppOpUsageData(), beserta pesan atribusi yang terkait dengannya.

• [9.8.2/H-4-3] TIDAK BOLEH menyembunyikan indikator mikrofon untuk aplikasi sistem yang memiliki antarmuka pengguna yang terlihat atau interaksi pengguna langsung.

• [9.8.2/H-4-4] HARUS menampilkan daftar aplikasi Terbaru dan Aktif yang menggunakan mikrofon seperti yang ditampilkan dari PermissionManager.getIndicatorAppOpUsageData(), beserta pesan atribusi yang terkait dengannya.

Jika implementasi Perangkat genggam mendeklarasikan android.hardware.camera.any, implementasi tersebut:

• [9.8.2/H-5-1] HARUS menampilkan indikator kamera saat aplikasi mengakses data kamera live, tetapi tidak saat kamera hanya diakses oleh aplikasi yang memiliki peran yang disebutkan di bagian 9.1 dengan ID CDD [C-4-X].

• [9.8.2/H-5-2] HARUS menampilkan Aplikasi Terbaru dan Aktif menggunakan kamera seperti yang ditampilkan dari PermissionManager.getIndicatorAppOpUsageData(), bersama dengan pesan atribusi yang terkait dengannya.

• [9.8.2/H-5-3] TIDAK BOLEH menyembunyikan indikator kamera untuk aplikasi sistem yang memiliki antarmuka pengguna yang terlihat atau interaksi pengguna langsung.

Booting Terverifikasi adalah fitur yang memastikan integritas software perangkat. Jika implementasi perangkat mendukung fitur ini, maka:

• [9.10/H-1-1] HARUS memverifikasi semua partisi hanya baca yang di-mount selama urutan booting Android, dan ringkasan VBMeta harus menyertakan semua partisi yang diverifikasi ini dalam perhitungannya.

2.2.6. Kompatibilitas Alat dan Opsi Developer

Implementasi perangkat genggam (* Tidak berlaku untuk Tablet):

• [6.1/H-0-1]* HARUS mendukung perintah shell cmd testharness.

Implementasi perangkat genggam:

• Perfetto

  • [6.1/H-0-2] HARUS mengekspos biner /system/bin/perfetto kepada pengguna shell yang cmdlinenya sesuai dengan dokumentasi perfetto.

  • [6.1/H-0-3] Biner perfetto HARUS menerima sebagai input konfigurasi protobuf yang sesuai dengan skema yang ditentukan dalam dokumentasi perfetto.

  • [6.1/H-0-4] Biner perfetto HARUS menulis sebagai output rekaman aktivitas protobuf yang sesuai dengan skema yang ditentukan dalam dokumentasi perfetto.

  • [6.1/H-0-5] HARUS menyediakan, melalui biner perfetto, setidaknya sumber data yang dijelaskan dalam dokumentasi perfetto.

  • [6.1/H-0-6] Daemon perekaman aktivitas perfetto HARUS diaktifkan secara default (properti sistem persist.traced.enable).

2.2.7. Class Performa Media Genggam

Lihat bagian 7.11 untuk mengetahui definisi class performa media dan Definisi Class Performa Media untuk semua pengukuran.

2.2.7.1. Media

Jika penerapan Perangkat seluler menampilkan nilai bukan nol untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, maka:

• HARUS memenuhi semua persyaratan media yang tercantum di bagian 2.2.7.1 CDD Android 17 yang sesuai dengan Tingkat Class Performa Media yang dinyatakan perangkat.

• [5.1/H-1-1] HARUS mengiklankan jumlah maksimum sesi dekoder video hardware yang dapat dijalankan secara bersamaan dalam kombinasi codec apa pun melalui metode CodecCapabilities.getMaxSupportedInstances() dan VideoCapabilities.getSupportedPerformancePoints() yang sesuai dengan Tingkat Class Performa Media yang dideklarasikan perangkat.

• [5.1/H-1-2] HARUS mendukung sesi dekoder video hardware (AVC, HEVC, VP9, AV1, atau yang lebih baru), instance serentak, dan frame drop yang sesuai dengan Tingkat Kelas Performa Media yang dideklarasikan perangkat.

• [5.1/H-1-3] HARUS mengiklankan jumlah maksimum sesi encoder video hardware yang dapat dijalankan secara bersamaan dalam kombinasi codec apa pun melalui metode CodecCapabilities.getMaxSupportedInstances() dan VideoCapabilities.getSupportedPerformancePoints() yang sesuai dengan Tingkat Class Performa Media yang dideklarasikan perangkat.

• [5.1/H-1-4] HARUS mendukung sesi encoder video hardware (AVC, HEVC, VP9, AV1, atau yang lebih baru), instance serentak, dan frame drop yang sesuai dengan Tingkat Kelas Performa Media yang dinyatakan perangkat.

• [5.1/H-1-5] HARUS mengiklankan jumlah maksimum sesi encoder dan decoder video hardware serentak dalam kombinasi codec apa pun melalui metode CodecCapabilities.getMaxSupportedInstances() dan VideoCapabilities.getSupportedPerformancePoints() yang sesuai dengan Tingkat Class Performa Media yang dinyatakan perangkat.

• [5.1/H-1-6] HARUS mendukung sesi hardware video decoder dan hardware video encoder (AVC, HEVC, VP9, AV1, atau yang lebih baru), instance serentak, dan frame drop yang sesuai dengan Tingkat Kelas Performa Media yang dinyatakan perangkat.

• [5.1/H-1-7] HARUS memiliki latensi inisialisasi codec untuk sesi encoding video 1080p atau yang lebih kecil untuk semua encoder video hardware saat berada di bawah beban yang sesuai dengan Tingkat Class Performa Media yang dinyatakan perangkat.

• [5.1/H-1-8] HARUS memiliki latensi inisialisasi codec untuk sesi encoding audio bitrate 128 kbps atau lebih rendah untuk semua encoder audio saat dalam beban yang sesuai dengan Tingkat Kelas Performa Media yang dideklarasikan perangkat.

• [5.1/H-1-9] HARUS mendukung 2 instance sesi dekoder video hardware yang aman (AVC, HEVC, VP9, AV1, atau yang lebih baru) dan frame drop yang sesuai dengan Tingkat Kelas Performa Media yang dinyatakan perangkat.

• [5.1/H-1-10] HARUS mendukung 3 instance sesi dekoder video hardware tidak aman bersama dengan 1 instance sesi dekoder video hardware aman (total 4 instance) (AVC, HEVC, VP9, AV1, atau yang lebih baru), resolusi, dan penurunan frame yang sesuai dengan Tingkat Kelas Performa Media yang dideklarasikan perangkat.

• [5.1/H-1-11] HARUS mendukung dekoder yang aman untuk setiap dekoder AVC, HEVC, VP9, atau AV1 hardware yang sesuai dengan Tingkat Class Performa Media yang dideklarasikan perangkat.

• [5.1/H-1-12] HARUS memiliki latensi inisialisasi codec untuk sesi dekode video 1080p atau yang lebih kecil untuk semua dekoder video hardware saat dalam beban yang sesuai dengan Tingkat Class Performa Media yang dideklarasikan perangkat.

• [5.1/H-1-13] HARUS memiliki latensi inisialisasi codec untuk sesi decoding audio bitrate 128 kbps atau lebih rendah untuk semua dekoder audio saat dalam beban yang sesuai dengan Tingkat Kelas Performa Media yang dinyatakan perangkat.

• [5.1/H-1-14] HARUS mendukung profil, fitur, dan metode tampilan dekoder hardware AV1 yang sesuai dengan Tingkat Class Performa Media yang dideklarasikan perangkat.

• [5.1/H-1-15] HARUS memiliki minimal 1 dekoder video hardware yang mendukung 4K60 sesuai dengan Tingkat Class Performa Media yang dinyatakan perangkat.

• [5.1/H-1-16] HARUS memiliki minimal 1 encoder video hardware yang mendukung 4K60 yang sesuai dengan Tingkat Class Performa Media yang dideklarasikan perangkat.

• [5.1/H-1-17] HARUS memiliki minimal 1 dekoder gambar hardware yang mendukung Profil Dasar AVIF yang sesuai dengan Tingkat Class Performa Media yang dinyatakan perangkat.

• [5.1/H-1-18] HARUS mendukung encoder AV1 yang memenuhi persyaratan bitrate, frame per detik, dan resolusi yang sesuai dengan Tingkat Class Performa Media yang dideklarasikan perangkat.

• [5.1/H-1-19] HARUS mendukung 3 instance sesi encoder video hardware 10-bit (HDR) dan decoder video hardware (AVC, HEVC, VP9, AV1, atau yang lebih baru), resolusi, dan frame drop yang sesuai dengan Tingkat Kelas Performa Media yang dideklarasikan perangkat.

• [5.1/H-1-20] HARUS mendukung fitur Feature_HdrEditing untuk semua encoder AV1 dan HEVC hardware yang ada di perangkat yang sesuai dengan Tingkat Class Performa Media yang dideklarasikan perangkat.

• [5.1/H-1-21] HARUS mendukung FEATURE_DynamicColorAspect untuk semua dekoder video hardware (AVC, HEVC, VP9, AV1, atau yang lebih baru) yang sesuai dengan Tingkat Kelas Performa Media yang dinyatakan perangkat.

• [5.1/H-1-22] HARUS mendukung encoding, decoding, pengeditan GPU, dan menampilkan konten video dalam rasio aspek potret yang sesuai dengan Tingkat Class Performa Media yang dinyatakan perangkat.

• [5.2/H-2-1] Jika implementasi perangkat mendukung encoder AVC atau HEVC hardware, implementasi tersebut HARUS memenuhi target kualitas minimum yang ditentukan oleh kurva distorsi laju encoder video untuk codec tersebut, yang sesuai dengan Tingkat Kelas Performa Media yang dideklarasikan perangkat.

• [5.3/H-1-1] HARUS memenuhi persyaratan performa sesi video dan penurunan frame yang sesuai dengan Tingkat Class Performa Media yang dideklarasikan perangkat.

• [5.3/H-1-2] HARUS memenuhi persyaratan performa perubahan resolusi video yang sesuai dengan Tingkat Class Performa Media yang dideklarasikan perangkat.

• [5.6/H-1-1] HARUS memenuhi persyaratan latensi ketuk-ke-nada yang sesuai dengan Tingkat Class Performa Media yang dinyatakan perangkat.

• [5.6/H-1-2] HARUS memenuhi persyaratan latensi audio pulang pergi yang sesuai dengan Tingkat Class Performa Media yang dinyatakan perangkat.

• [5.6/H-1-3] HARUS memenuhi persyaratan audio 24-bit yang sesuai dengan Tingkat Class Performa Media yang dinyatakan perangkat.

• [5.6/H-1-4] HARUS mendukung perangkat audio USB >= 4 saluran yang sesuai dengan Tingkat Class Performa Media yang dideklarasikan perangkat.

• [5.6/H-1-5] HARUS mendukung perangkat MIDI yang sesuai dengan class dan mendeklarasikan tanda fitur MIDI yang sesuai dengan Tingkat Class Performa Media yang dideklarasikan perangkat.

• [5.6/H-1-9] HARUS mendukung pencampuran minimal 12 saluran yang sesuai dengan Tingkat Kelas Performa Media yang dideklarasikan perangkat.

• [5.6/H-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung pencampuran saluran audio yang sesuai dengan Tingkat Class Performa Media yang dinyatakan perangkat.

• [5.7/H-1-2] HARUS mendukung MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL dengan kemampuan dekripsi yang sesuai dengan Tingkat Class Performa Media yang dideklarasikan perangkat.

• [5.12/H-1-2] HARUS memenuhi persyaratan format warna untuk encoder AV1 dan HEVC hardware yang sesuai dengan Tingkat Class Performa Media yang dinyatakan perangkat.

• [5.12/H-1-3] HARUS mengiklankan dukungan untuk ekstensi EXT_YUV_target yang sesuai dengan Tingkat Class Performa Media yang dideklarasikan perangkat.

• [7.1.4/H-1-1] HARUS memenuhi persyaratan unit pemrosesan layar (DPU) yang sesuai dengan Tingkat Class Performa Media yang dinyatakan perangkat.

2.2.7.2. Kamera

Jika penerapan Perangkat seluler menampilkan nilai bukan nol untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, maka:

• HARUS memenuhi persyaratan kamera yang tercantum di bagian 2.2.7.2 CDD Android 17 yang sesuai dengan Tingkat Class Performa Media yang dideklarasikan perangkat.

Jika penerapan Perangkat seluler menampilkan nilai bukan nol untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, maka:

• [7.5/H-1-1] HARUS memenuhi persyaratan pengambilan video dan resolusi kamera belakang utama yang sesuai dengan Tingkat Class Performa Media yang dinyatakan perangkat.

• [7.5/H-1-2] HARUS memenuhi persyaratan resolusi kamera depan utama dan pengambilan video yang sesuai dengan Tingkat Class Performa Media yang dinyatakan perangkat.

• [7.5/H-1-3] HARUS mendukung persyaratan properti android.info.supportedHardwareLevel yang sesuai dengan Tingkat Class Performa Media yang dideklarasikan perangkat.

• [7.5/H-1-4] HARUS mendukung CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME untuk kamera utama yang sesuai dengan Tingkat Class Performa Media yang dinyatakan perangkat.

• [7.5/H-1-5] HARUS memenuhi persyaratan latensi pengambilan JPEG camera2 yang sesuai dengan Tingkat Class Performa Media yang dideklarasikan perangkat.

• [7.5/H-1-6] HARUS memenuhi persyaratan latensi peluncuran camera2 yang sesuai dengan Tingkat Class Performa Media yang dinyatakan perangkat.

• [7.5/H-1-8] HARUS memenuhi persyaratan pengambilan gambar kamera RAW yang sesuai dengan Tingkat Class Performa Media yang dinyatakan perangkat.

• [7.5/H-1-9] HARUS memenuhi persyaratan pengambilan video kecepatan tinggi kamera utama yang menghadap ke belakang yang sesuai dengan Tingkat Class Performa Media yang dinyatakan perangkat.

• [7.5/H-1-10] HARUS memenuhi persyaratan rasio zoom minimum yang sesuai dengan Tingkat Class Performa Media yang dinyatakan perangkat.

• [7.5/H-1-11] HARUS menerapkan streaming depan-belakang serentak pada kamera utama yang sesuai dengan Tingkat Class Performa Media yang dinyatakan perangkat.

• [7.5/H-1-12] HARUS mendukung stabilisasi video untuk kamera belakang utama yang sesuai dengan Tingkat Class Performa Media yang dinyatakan perangkat.

• [7.5/H-1-13] HARUS mendukung kemampuan LOGICAL_MULTI_CAMERA untuk kamera belakang utama yang sesuai dengan Tingkat Class Performa Media yang dinyatakan perangkat.

• [7.5/H-1-14] HARUS mendukung kemampuan STREAM_USE_CASE untuk kamera depan utama dan kamera belakang utama yang sesuai dengan Tingkat Class Performa Media yang dideklarasikan perangkat.

• [7.5/H-1-15] HARUS mendukung ekstensi Mode malam melalui ekstensi CameraX dan Camera2 untuk kamera utama yang sesuai dengan Tingkat Class Performa Media yang dinyatakan perangkat.

• [7.5/H-1-16] HARUS mendukung kemampuan DYNAMIC_RANGE_TEN_BIT untuk kamera utama yang sesuai dengan Tingkat Class Performa Media yang dideklarasikan perangkat.

• [7.5/H-1-17] HARUS mendukung fitur deteksi wajah untuk kamera utama yang sesuai dengan Tingkat Class Performa Media yang dinyatakan perangkat.

• [7.5/H-1-18] HARUS mendukung JPEG_R untuk kamera belakang utama dan kamera depan utama yang sesuai dengan Tingkat Kelas Performa Media yang dinyatakan perangkat.

• [7.5/H-1-19] HARUS mendukung CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION untuk kamera belakang utama yang sesuai dengan Tingkat Class Performa Media yang dinyatakan perangkat.

• [7.5/H-1-20] HARUS secara default menghasilkan JPEG_R untuk kamera belakang utama dan kamera depan utama di aplikasi kamera bawaan yang sesuai dengan Tingkat Class Performa Media yang dideklarasikan perangkat.

2.2.7.3. Hardware

Jika penerapan Perangkat seluler menampilkan nilai bukan nol untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, maka:

• HARUS memenuhi persyaratan hardware yang tercantum di bagian 2.2.7.3 CDD Android 17 yang sesuai dengan Tingkat Class Performa Media yang dinyatakan perangkat.

Jika penerapan Perangkat seluler menampilkan nilai bukan nol untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, maka:

• [7.1.1.1/H-1-1] Item ini sengaja dilewati.

• [7.1.1.1/H-2-1] HARUS memiliki resolusi layar yang sesuai dengan Tingkat Class Performa Media yang dinyatakan perangkat.

• [7.1.1.3/H-1-1] Item ini sengaja dilewati.

• [7.1.1.3/H-2-1] HARUS memiliki kepadatan layar yang sesuai dengan Tingkat Class Performa Media yang dideklarasikan perangkat.

• [7.1.1.3/H-3-1] HARUS mendukung persyaratan tampilan HDR yang sesuai dengan Tingkat Class Performa Media yang dideklarasikan perangkat.

• [7.6.1/H-1-1] Item ini sengaja dilewati.

• [7.6.1/H-2-1] HARUS memenuhi persyaratan memori yang sesuai dengan Tingkat Class Performa Media yang dinyatakan perangkat.

2.2.7.4. Performa

Jika penerapan Perangkat seluler menampilkan nilai bukan nol untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, maka:

• HARUS memenuhi persyaratan performa yang tercantum di bagian 2.2.7.4 CDD Android 17 yang sesuai dengan Tingkat Class Performa Media yang dideklarasikan perangkat.

Jika penerapan Perangkat seluler menampilkan nilai bukan nol untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, maka:

• [8.2/H-1-1] HARUS memastikan performa penulisan berurutan yang sesuai dengan Tingkat Class Performa Media yang dinyatakan perangkat.

• [8.2/H-1-2] HARUS memastikan performa penulisan acak yang sesuai dengan Tingkat Class Performa Media yang dinyatakan perangkat.

• [8.2/H-1-3] HARUS memastikan performa baca berurutan yang sesuai dengan Tingkat Class Performa Media yang dideklarasikan perangkat.

• [8.2/H-1-4] HARUS memastikan performa baca acak yang sesuai dengan Tingkat Class Performa Media yang dinyatakan perangkat.

• [8.2/H-1-5] HARUS memastikan performa baca dan tulis berurutan paralel yang sesuai dengan Tingkat Class Performa Media yang dideklarasikan perangkat.

2.2.7.5. Grafik

Jika penerapan Perangkat seluler menampilkan nilai bukan nol untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, maka:

• [7.1.4.1/H-1-2] HARUS mendukung ekstensi EGL yang diperlukan yang sesuai dengan Tingkat Class Performa Media yang dideklarasikan perangkat.

• [7.1.4.1/H-1-3] HARUS mendukung fitur Vulkan yang diperlukan yang sesuai dengan Tingkat Class Performa Media yang dideklarasikan perangkat.

2.3. Persyaratan Televisi

Perangkat Android TV mengacu pada penerapan perangkat Android yang merupakan antarmuka hiburan untuk menggunakan media digital, film, game, aplikasi, dan/atau TV live bagi pengguna yang duduk sekitar sepuluh kaki jauhnya (antarmuka pengguna "lean back" atau "10 kaki").

Implementasi perangkat Android diklasifikasikan sebagai Televisi jika memenuhi semua kriteria berikut:

• Telah menyediakan mekanisme untuk mengontrol antarmuka pengguna yang dirender dari jarak jauh di layar yang mungkin berjarak tiga meter dari pengguna.
• Memiliki layar tersemat dengan panjang diagonal lebih dari 24 inci ATAU menyertakan port output video, seperti VGA, HDMI, DisplayPort, atau port nirkabel untuk layar.

Persyaratan tambahan di bagian ini lainnya khusus untuk penerapan perangkat Android TV.

2.3.1. Hardware

Implementasi perangkat televisi:

• [7.2.2/T-0-1] HARUS mendukung D-pad.
• [7.2.3/T-0-1] HARUS menyediakan fungsi Beranda dan Kembali.
• [7.2.3/T-0-2] HARUS mengirimkan peristiwa tekan lama dan normal dari fungsi Kembali (KEYCODE_BACK) ke aplikasi latar depan.
• [7.2.6.1/T-0-1] HARUS menyertakan dukungan untuk pengontrol game dan mendeklarasikan flag fitur android.hardware.gamepad.
• [7.2.7/T] HARUS menyediakan kontrol jarak jauh yang memungkinkan pengguna mengakses navigasi non-sentuh dan input tombol navigasi inti.

Jika implementasi perangkat Televisi mencakup giroskop 3 sumbu, perangkat tersebut:

• [7.3.4/T-1-1] HARUS dapat melaporkan peristiwa hingga frekuensi minimal 100 Hz.
• [7.3.4/T-1-2] HARUS dapat mengukur perubahan orientasi hingga 1000 derajat per detik.

Implementasi perangkat televisi:

• [7.4.3/T-0-1] HARUS mendukung Bluetooth dan Bluetooth LE.
• [7.6.1/T-0-1] HARUS memiliki penyimpanan non-volatile minimal 4 GB yang tersedia untuk data pribadi aplikasi (alias partisi "/data").

Jika implementasi perangkat Televisi mencakup port USB yang mendukung mode host, maka:

• [7.5.3/T-1-1] HARUS menyertakan dukungan untuk kamera eksternal yang terhubung melalui port USB ini, tetapi tidak harus selalu terhubung.

Jika implementasi perangkat TV adalah 32-bit:

• [7.6.1/T-1-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 896 MB jika salah satu kepadatan berikut digunakan:

  • 400 dpi atau lebih tinggi pada layar kecil/normal
  • xhdpi atau lebih tinggi di layar besar
  • tvdpi atau lebih tinggi pada layar ekstra besar

Jika implementasi perangkat TV adalah 64-bit:

• [7.6.1/T-2-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 1280 MB jika salah satu kepadatan berikut digunakan:

  • 400 dpi atau lebih tinggi pada layar kecil/normal
  • xhdpi atau lebih tinggi di layar besar
  • tvdpi atau lebih tinggi pada layar ekstra besar

Perhatikan bahwa "memori yang tersedia untuk kernel dan ruang pengguna" di atas mengacu pada ruang memori yang disediakan selain memori yang sudah dikhususkan untuk komponen hardware seperti radio, video, dan sebagainya yang tidak berada di bawah kontrol kernel pada penerapan perangkat.

Implementasi perangkat televisi:

• [7.8.1/T] HARUS menyertakan mikrofon.
• [7.8.2/T-0-1] HARUS memiliki output audio dan menyatakan android.hardware.audio.output.

2.3.2. Multimedia

Penerapan perangkat televisi HARUS mendukung format encoding dan decoding audio berikut serta menyediakannya untuk aplikasi pihak ketiga:

• [5.1/T-0-1] Profil AAC MPEG-4 (AAC LC)
• [5.1/T-0-2] MPEG-4 HE AAC Profile (AAC+)
• [5.1/T-0-3] AAC ELD (AAC yang ditingkatkan dengan delay rendah)

Penerapan perangkat televisi HARUS mendukung format encoding video berikut dan menyediakannya untuk aplikasi pihak ketiga:

• [5.2/T-0-1] H.264
• [5.2/T-0-2] VP8
• [5.2/T-0-3] AV1

Implementasi perangkat televisi:

• [5.2.2/T-SR-1] SANGAT DISARANKAN untuk mendukung encoding H.264 untuk video beresolusi 720p dan 1080p pada 30 frame per detik.

Implementasi perangkat televisi HARUS mendukung format decoding video berikut dan menyediakannya untuk aplikasi pihak ketiga:

• [5.3.3/T-0-1] MPEG-4 SP
• [5.3.4/T-0-2] H.264 AVC
• [5.3.5/T-0-3] H.265 HEVC
• [5.3.6/T-0-4] VP8
• [5.3.7/T-0-5] VP9
• [5.3.1/T-0-6] MPEG-2
• [5.3.2/T-0-7] AV1

Penerapan perangkat televisi HARUS mendukung dekode MPEG-2, seperti yang dijelaskan dalam Pasal 5.3.1, pada kecepatan frame video standar dan resolusi hingga dan termasuk:

• [5.3.1/T-1-1] HD 1080p pada 29,97 frame per detik dengan Main Profile High Level.
• [5.3.1/T-1-2] HD 1080i pada 59,94 frame per detik dengan Main Profile High Level. Mereka HARUS menghilangkan interlace pada video MPEG-2 yang di-interlace dan menyediakannya untuk aplikasi pihak ketiga.

Penerapan perangkat televisi HARUS mendukung decoding H.264, seperti yang dijelaskan dalam Pasal 5.3.4, pada kecepatan frame video standar dan resolusi hingga dan termasuk:

• [5.3.4/T-1-1] HD 1080p pada 60 frame per detik dengan Baseline Profile
• [5.3.4/T-1-2] HD 1080p pada 60 frame per detik dengan Main Profile
• [5.3.4/T-1-3] HD 1080p pada 60 frame per detik dengan High Profile Level 4.2

Penerapan perangkat televisi dengan dekoder hardware H.265 HARUS mendukung decoding H.265, seperti yang dijelaskan dalam Bagian 5.3.5, pada frekuensi gambar video standar dan resolusi hingga dan termasuk:

• [5.3.5/T-1-1] HD 1080p pada 60 frame per detik dengan Main Profile Level 4.1

Jika penerapan perangkat Televisi dengan dekoder hardware H.265 mendukung decoding H.265 dan profil decoding UHD, maka:

• [5.3.5/T-2-1] HARUS mendukung profil dekode UHD pada 60 frame per detik dengan profil Main Tier Level 5 Main10

Penerapan perangkat televisi HARUS mendukung dekode VP8, sebagaimana dijelaskan dalam Pasal 5.3.6, pada kecepatan frame video standar dan resolusi hingga dan termasuk:

• [5.3.6/T-1-1] Profil dekode HD 1080p pada 60 frame per detik

Penerapan perangkat televisi dengan dekoder hardware VP9 HARUS mendukung dekoding VP9, seperti yang dijelaskan dalam Bagian 5.3.7, pada frekuensi gambar video standar dan resolusi hingga dan termasuk:

• [5.3.7/T-1-1] HD 1080p pada 60 frame per detik dengan profil 0 (kedalaman warna 8 bit)

Jika penerapan perangkat Televisi dengan dekoder hardware VP9 mendukung dekode VP9 dan profil dekode UHD, maka:

• [5.3.7/T-2-1] HARUS mendukung profil dekode UHD pada 60 frame per detik dengan profil 0 (kedalaman warna 8 bit).
• [5.3.7/T-SR1] SANGAT DISARANKAN untuk mendukung profil dekode UHD pada 60 frame per detik dengan profil 2 (kedalaman warna 10 bit).

Implementasi perangkat televisi:

• [5.5/T-0-1] HARUS menyertakan dukungan untuk Peredaman Volume Master sistem dan volume output audio digital pada output yang didukung, kecuali untuk output passthrough audio terkompresi (tempat tidak ada decoding audio yang dilakukan di perangkat).

Jika implementasi perangkat Televisi tidak memiliki layar bawaan, tetapi mendukung layar eksternal yang terhubung melalui HDMI, maka:

• [5.8/T-0-1] HARUS menyetel mode output HDMI ke resolusi tertinggi untuk format piksel yang dipilih yang kompatibel dengan kecepatan refresh 50 Hz atau 60 Hz untuk layar eksternal, bergantung pada kecepatan refresh video untuk wilayah tempat perangkat dijual.
• [5.8/T-SR-1] SANGAT DISARANKAN untuk menyediakan pemilih kecepatan refresh HDMI yang dapat dikonfigurasi pengguna.
• [5.8] HARUS menyetel kecepatan refresh mode output HDMI ke 50 Hz atau 60 Hz, bergantung pada kecepatan refresh video untuk wilayah tempat perangkat dijual.

Jika implementasi perangkat Televisi tidak memiliki layar bawaan, tetapi mendukung layar eksternal yang terhubung melalui HDMI, maka:

• [5.8/T-1-1] HARUS mendukung HDCP 2.2.

Jika implementasi perangkat Televisi tidak mendukung decoding UHD, tetapi mendukung layar eksternal yang terhubung melalui HDMI, maka:

• [5.8/T-2-1] HARUS mendukung HDCP 1.4

2.3.3. Software

Implementasi perangkat televisi:

• [3/T-0-1] HARUS mendeklarasikan fitur android.software.leanback dan android.hardware.type.television.
• [3.2.3.1/T-0-1] HARUS memuat satu atau beberapa aplikasi atau komponen layanan dengan pengendali intent, untuk semua pola filter intent publik yang ditentukan oleh intent aplikasi berikut yang tercantum di sini.
• [3.4.1/T-0-1] HARUS menyediakan implementasi lengkap android.webkit.Webview API.

Jika implementasi perangkat Android Television mendukung layar kunci, maka:

• [3.8.10/T-1-1] HARUS menampilkan Notifikasi layar kunci termasuk Template Notifikasi Media.

Implementasi perangkat televisi:

• [3.8.14/T-SR-1] SANGAT DISARANKAN untuk mendukung multi-aplikasi mode picture-in-picture (PIP).
• [3.10/T-0-1] HARUS mendukung layanan aksesibilitas pihak ketiga.
• [3.10/T-SR-1] SANGAT DISARANKAN untuk memuat layanan aksesibilitas di perangkat yang sebanding dengan atau melebihi fungsi layanan aksesibilitas Tombol Akses dan TalkBack (untuk bahasa yang didukung oleh mesin Text-to-speech yang sudah diinstal sebelumnya) sebagaimana disediakan dalam project open source TalkBack.

Jika implementasi perangkat Televisi melaporkan fitur android.hardware.audio.output, maka:

• [3.11/T-SR-1] SANGAT DISARANKAN untuk menyertakan mesin TTS yang mendukung bahasa yang tersedia di perangkat.
• [3.11/T-1-1] HARUS mendukung penginstalan mesin TTS pihak ketiga.

Framework Input Televisi Android (TIF) menyederhanakan penyampaian konten live ke perangkat Televisi Android. TIF menyediakan API standar untuk membuat modul input yang mengontrol perangkat Televisi Android.

Implementasi perangkat televisi:

• [3/T-0-2] HARUS mendeklarasikan fitur platform android.software.live_tv.
• [3/T-0-3] HARUS mendukung semua TIF API sehingga aplikasi yang menggunakan API ini dan layanan input berbasis TIF pihak ketiga dapat diinstal dan digunakan di perangkat.

Framework Tuner Televisi Android (TF) menyatukan penanganan konten live dari Tuner dengan konten streaming dari IP di perangkat Televisi Android. Tuner Framework menyediakan API standar untuk membuat layanan input yang menggunakan Tuner Televisi Android.

Jika implementasi perangkat mendukung Tuner, perangkat tersebut:

• [3/T-1-1] HARUS mendukung semua API Framework Tuner sehingga aplikasi yang menggunakan API ini dapat diinstal dan digunakan di perangkat.

2.3.4. Performa dan Daya

• [8.1/T-0-1] Latensi frame yang konsisten. Latensi frame yang tidak konsisten atau penundaan untuk merender frame TIDAK BOLEH terjadi lebih sering daripada 5 frame dalam satu detik, dan SEBAIKNYA di bawah 1 frame dalam satu detik.
• [8.2/T-0-1] HARUS memastikan performa penulisan berurutan minimal 5 MB/dtk.
• [8.2/T-0-2] HARUS memastikan performa penulisan acak minimal 0,5 MB/dtk.
• [8.2/T-0-3] HARUS memastikan performa baca berurutan minimal 15 MB/dtk.
• [8.2/T-0-4] HARUS memastikan performa baca acak minimal 3,5 MB/dtk.

Jika implementasi perangkat Televisi menyertakan fitur untuk meningkatkan pengelolaan daya perangkat yang disertakan dalam AOSP atau memperluas fitur yang disertakan dalam AOSP, implementasi tersebut:

• [8.3/T-1-1] HARUS menyediakan kemampuan pengguna untuk mengaktifkan dan menonaktifkan fitur penghemat baterai.

Jika implementasi perangkat Televisi tidak memiliki baterai, maka:

• [8.3/T-1-2] HARUS mendaftarkan perangkat sebagai perangkat tanpa baterai seperti yang dijelaskan dalam Mendukung Perangkat Tanpa Baterai.

Jika implementasi perangkat Televisi memiliki baterai, maka:

• [8.3/T-1-3] HARUS menyediakan kemudahan pengguna untuk menampilkan semua aplikasi yang dikecualikan dari mode hemat daya Istirahatkan dan Aplikasi Standby.

Implementasi perangkat televisi:

• [8.4/T-0-1] HARUS menyediakan profil daya per komponen yang menentukan nilai konsumsi arus untuk setiap komponen hardware dan perkiraan pengurasan baterai yang disebabkan oleh komponen dari waktu ke waktu seperti yang didokumentasikan di situs Proyek Open Source Android.
• [8.4/T-0-2] HARUS melaporkan semua nilai konsumsi daya dalam satuan miliampere jam (mAh).
• [8.4/T-0-3] HARUS melaporkan konsumsi daya CPU per UID setiap proses. Android Open Source Project memenuhi persyaratan melalui penerapan modul kernel uid_cputime.
• [8.4/T] HARUS diatribusikan ke komponen hardware itu sendiri jika tidak dapat mengatribusikan penggunaan daya komponen hardware ke aplikasi.
• [8.4/T-0-4] HARUS menyediakan penggunaan daya ini melalui perintah shell adb shell dumpsys batterystats kepada developer aplikasi.

2.3.5. Model Keamanan

Implementasi perangkat televisi:

• [9/T-0-1] HARUS mendeklarasikan fitur android.hardware.security.model.compatible.

Jika implementasi perangkat Televisi menyertakan aplikasi default untuk mendukung VoiceInteractionService, aplikasi tersebut:

• [9.1/T-0-1] TIDAK BOLEH memberikan ACCESS_FINE_LOCATION sebagai default untuk aplikasi tersebut.

Implementasi perangkat televisi:

• [9.11/T-0-1] HARUS mencadangkan penerapan keystore dengan lingkungan eksekusi terisolasi.
• [9.11/T-0-2] HARUS memiliki penerapan algoritma kriptografi RSA, AES, ECDSA, dan HMAC serta fungsi hash MD5, SHA-1, dan SHA-2 untuk mendukung algoritma yang didukung sistem Android Keystore dengan benar di area yang terisolasi secara aman dari kode yang berjalan di kernel dan yang lebih tinggi. Isolasi aman HARUS memblokir semua potensi mekanisme yang memungkinkan kode kernel atau ruang pengguna mengakses status internal lingkungan yang terisolasi, termasuk DMA. Project Open Source Android (AOSP) upstream memenuhi persyaratan ini dengan menggunakan implementasi Trusty, tetapi solusi lain berbasis ARM TrustZone atau implementasi aman yang ditinjau pihak ketiga dari isolasi berbasis hypervisor yang tepat adalah opsi alternatif.
• [9.11/T-0-3] HARUS melakukan autentikasi layar kunci di lingkungan eksekusi yang terisolasi dan hanya jika berhasil, mengizinkan penggunaan kunci yang terikat dengan autentikasi. Kredensial layar kunci HARUS disimpan dengan cara yang hanya memungkinkan lingkungan eksekusi terisolasi melakukan autentikasi layar kunci. Proyek Open Source Android upstream menyediakan Gatekeeper Hardware Abstraction Layer (HAL) dan Trusty, yang dapat digunakan untuk memenuhi persyaratan ini.

• [9.11/T-0-4] HARUS mendukung pengesahan kunci dengan kunci penandatanganan pengesahan dilindungi oleh hardware aman dan penandatanganan dilakukan di hardware aman. Kunci penandatanganan pengesahan TIDAK BOLEH digunakan sebagai ID perangkat permanen.

Perhatikan bahwa jika implementasi perangkat sudah diluncurkan di versi Android sebelumnya, perangkat tersebut dikecualikan dari persyaratan untuk memiliki keystore yang didukung oleh lingkungan eksekusi terisolasi dan mendukung pengesahan kunci, kecuali jika perangkat tersebut mendeklarasikan fitur android.hardware.fingerprint yang memerlukan keystore yang didukung oleh lingkungan eksekusi terisolasi.

Jika implementasi perangkat Televisi mendukung layar kunci yang aman, maka:

• [9.11/T-1-1] HARUS mengizinkan pengguna memilih waktu tunggu Tidur untuk transisi dari status tidak terkunci ke status terkunci, dengan waktu tunggu minimum yang diizinkan hingga 15 detik atau kurang.

Jika implementasi perangkat Televisi mencakup beberapa pengguna dan tidak mendeklarasikan tanda fitur android.hardware.telephony, maka:

• [9.5/T-2-1] HARUS mendukung profil terbatas, fitur yang memungkinkan pemilik perangkat mengelola pengguna tambahan dan kemampuannya di perangkat. Dengan profil yang dibatasi, pemilik perangkat dapat dengan cepat menyiapkan lingkungan terpisah bagi pengguna tambahan untuk bekerja, dengan kemampuan untuk mengelola pembatasan yang lebih mendetail dalam aplikasi yang tersedia di lingkungan tersebut.

Jika implementasi perangkat Televisi mencakup beberapa pengguna dan mendeklarasikan tanda fitur android.hardware.telephony, maka:

• [9.5/T-3-1] TIDAK BOLEH mendukung profil terbatas, tetapi HARUS selaras dengan penerapan kontrol AOSP untuk mengaktifkan /menonaktifkan pengguna lain agar tidak mengakses panggilan suara dan SMS.

Jika implementasi perangkat Televisi mendeklarasikan android.hardware.microphone, maka:

• [9.8.2/T-4-1] HARUS menampilkan indikator mikrofon saat aplikasi mengakses data audio dari mikrofon, tetapi tidak saat mikrofon hanya diakses oleh HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService, atau aplikasi yang memiliki peran yang disebutkan dalam Izin Bagian 9.1 dengan ID CDD C-3-X.
• [9.8.2/T-4-2] TIDAK BOLEH menyembunyikan indikator mikrofon untuk aplikasi sistem yang memiliki antarmuka pengguna yang terlihat atau interaksi pengguna langsung.

Jika implementasi perangkat Televisi mendeklarasikan android.hardware.camera.any, maka:

• [9.8.2/T-5-1] HARUS menampilkan indikator kamera saat aplikasi mengakses data kamera live, tetapi tidak saat kamera hanya diakses oleh aplikasi yang memiliki peran yang disebutkan dalam Izin Bagian 9.1 dengan ID CDD [C-3-X].
• [9.8.2/T-5-2] TIDAK BOLEH menyembunyikan indikator kamera untuk aplikasi sistem yang memiliki antarmuka pengguna yang terlihat atau interaksi pengguna langsung.

2.3.6. Kompatibilitas Alat dan Opsi Developer

Implementasi perangkat televisi:

• Perfetto

  • [6.1/T-0-1] HARUS mengekspos biner /system/bin/perfetto kepada pengguna shell yang cmdlinenya sesuai dengan dokumentasi perfetto.
  • [6.1/T-0-2] Biner perfetto HARUS menerima sebagai input konfigurasi protobuf yang sesuai dengan skema yang ditentukan dalam dokumentasi perfetto.
  • [6.1/T-0-3] Biner perfetto HARUS menulis sebagai output rekaman aktivitas protobuf yang sesuai dengan skema yang ditentukan dalam dokumentasi perfetto.
  • [6.1/T-0-4] HARUS menyediakan, melalui biner perfetto, setidaknya sumber data yang dijelaskan dalam dokumentasi perfetto.
  • [6.1/T-0-5] Daemon perekam aktivitas perfetto HARUS diaktifkan secara default (properti sistem persist.traced.enable).

2.4. Persyaratan Smartwatch

Perangkat Android Watch mengacu pada penerapan perangkat Android yang dimaksudkan untuk dipakai di tubuh, mungkin di pergelangan tangan.

Penerapan perangkat Android diklasifikasikan sebagai Smartwatch jika memenuhi semua kriteria berikut:

• Memiliki layar dengan panjang diagonal fisik dalam rentang 1,1 hingga 2,5 inci.
• Memiliki mekanisme yang disediakan untuk dipakai di tubuh.

Persyaratan tambahan di bagian ini selanjutnya khusus untuk penerapan perangkat Android Watch.

2.4.1. Hardware

Tonton implementasi perangkat:

• [7.1.1.1/W-0-1] HARUS memiliki layar dengan ukuran diagonal fisik dalam rentang 1,1 hingga 2,5 inci.

• [7.2.3/W-0-1] HARUS menyediakan fungsi Beranda kepada pengguna, dan fungsi Kembali kecuali saat berada di UI_MODE_TYPE_WATCH.

• [7.2.4/W-0-1] HARUS mendukung input layar sentuh.

• [7.3.1/W-SR-1] SANGAT DISARANKAN untuk menyertakan akselerometer 3 sumbu.

Jika implementasi perangkat Wearable menyertakan penerima GPS/GNSS dan melaporkan kemampuan ke aplikasi melalui tanda fitur android.hardware.location.gps, maka:

• [7.3.3/W-1-1] HARUS melaporkan pengukuran GNSS, segera setelah ditemukan, meskipun lokasi yang dihitung dari GPS/GNSS belum dilaporkan.
• [7.3.3/W-1-2] HARUS melaporkan pseudojarak dan laju pseudojarak GNSS, yang dalam kondisi langit terbuka setelah menentukan lokasi, saat stasioner atau bergerak dengan percepatan 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.

Jika implementasi perangkat Wearable mencakup giroskop 3 sumbu, maka:

• [7.3.4/W-2-1] HARUS dapat mengukur perubahan orientasi hingga 1000 derajat per detik.

Tonton implementasi perangkat:

• [7.4.3/W-0-1] HARUS mendukung Bluetooth.

• [7.6.1/W-0-1] HARUS memiliki minimal 1 GB penyimpanan non-volatile yang tersedia untuk data pribadi aplikasi (alias partisi "/data").

• [7.6.1/W-0-2] HARUS memiliki setidaknya 416 MB memori yang tersedia untuk kernel dan ruang pengguna.

• [7.8.1/W-0-1] HARUS menyertakan mikrofon.

• [7.8.2/W] MUNGKIN memiliki output audio.

2.4.2. Multimedia

Tidak ada persyaratan tambahan.

2.4.3. Software

Tonton implementasi perangkat:

• [3/W-0-1] HARUS mendeklarasikan fitur android.hardware.type.watch.
• [3/W-0-2] HARUS mendukung uiMode = UI_MODE_TYPE_WATCH.
• [3.2.3.1/W-0-1] HARUS memuat satu atau beberapa komponen aplikasi atau layanan dengan pengendali intent, untuk semua pola filter intent publik yang ditentukan oleh intent aplikasi berikut yang tercantum di sini.

Tonton implementasi perangkat:

• [3.8.4/W-SR-1] SANGAT DISARANKAN untuk menerapkan asisten di perangkat guna menangani tindakan Bantuan.

Amati penerapan perangkat yang mendeklarasikan flag fitur android.hardware.audio.output:

• [3.10/W-1-1] HARUS mendukung layanan aksesibilitas pihak ketiga.
• [3.10/W-SR-1] SANGAT DISARANKAN untuk memuat layanan aksesibilitas di perangkat yang sebanding dengan atau melebihi fungsi layanan aksesibilitas Tombol Akses dan TalkBack (untuk bahasa yang didukung oleh mesin Text-to-speech yang sudah diinstal sebelumnya) seperti yang disediakan dalam project open source TalkBack.

Jika implementasi perangkat Watch melaporkan fitur android.hardware.audio.output, maka:

• [3.11/W-SR-1] SANGAT DISARANKAN untuk menyertakan mesin TTS yang mendukung bahasa yang tersedia di perangkat.

• [3.11/W-0-1] HARUS mendukung penginstalan mesin TTS pihak ketiga.

2.4.4. Performa dan Daya

Jika implementasi perangkat Wearable mencakup fitur untuk meningkatkan pengelolaan daya perangkat yang disertakan dalam AOSP atau memperluas fitur yang disertakan dalam AOSP, maka:

• [8.3/W-SR-1] SANGAT DISARANKAN untuk memberikan kemudahan pengguna dalam menampilkan semua aplikasi yang dikecualikan dari mode penghemat daya Tidur Aplikasi dan Tidur singkat.
• [8.3/W-SR-2] SANGAT DISARANKAN untuk menyediakan kemudahan pengguna untuk mengaktifkan dan menonaktifkan fitur penghemat baterai.

Tonton implementasi perangkat:

• [8.4/W-0-1] HARUS menyediakan profil daya per komponen yang menentukan nilai konsumsi arus untuk setiap komponen hardware dan perkiraan pengurasan baterai yang disebabkan oleh komponen dari waktu ke waktu seperti yang didokumentasikan di situs Android Open Source Project.
• [8.4/W-0-2] HARUS melaporkan semua nilai konsumsi daya dalam satuan miliampere jam (mAh).
• [8.4/W-0-3] HARUS melaporkan konsumsi daya CPU per UID setiap proses. Android Open Source Project memenuhi persyaratan melalui penerapan modul kernel uid_cputime.
• [8.4/W-0-4] HARUS menyediakan penggunaan daya ini melalui perintah shell adb shell dumpsys batterystats kepada developer aplikasi.
• [8.4/W] HARUS diatribusikan ke komponen hardware itu sendiri jika tidak dapat mengatribusikan penggunaan daya komponen hardware ke aplikasi.

2.4.5. Model Keamanan

Tonton implementasi perangkat:

• [9/W-0-1] HARUS mendeklarasikan fitur android.hardware.security.model.compatible.

Jika implementasi perangkat Wearable menyertakan aplikasi default untuk mendukung VoiceInteractionService, aplikasi tersebut:

• [9.1/W-0-1] TIDAK BOLEH memberikan ACCESS_FINE_LOCATION sebagai default untuk aplikasi tersebut.

Jika implementasi perangkat Wearable mencakup beberapa pengguna dan tidak mendeklarasikan tanda fitur android.hardware.telephony, maka:

• [9.5/W-1-1] HARUS mendukung profil terbatas, fitur yang memungkinkan pemilik perangkat mengelola pengguna tambahan dan kemampuannya di perangkat. Dengan profil yang dibatasi, pemilik perangkat dapat dengan cepat menyiapkan lingkungan terpisah bagi pengguna tambahan untuk bekerja, dengan kemampuan untuk mengelola pembatasan yang lebih mendetail dalam aplikasi yang tersedia di lingkungan tersebut.

Jika implementasi perangkat Wearable mencakup beberapa pengguna dan mendeklarasikan tanda fitur android.hardware.telephony, maka:

• [9.5/W-2-1] TIDAK BOLEH mendukung profil terbatas, tetapi HARUS selaras dengan penerapan kontrol AOSP untuk mengaktifkan /menonaktifkan pengguna lain agar tidak mengakses panggilan suara dan SMS.

Jika implementasi perangkat memiliki layar kunci yang aman dan menyertakan satu atau beberapa agen tepercaya, yang mengimplementasikan TrustAgentServiceSystem API, maka:

2.5. Persyaratan Otomotif

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

Implementasi perangkat Android diklasifikasikan sebagai Otomotif jika mendeklarasikan fitur android.hardware.type.automotive atau memenuhi semua kriteria berikut.

• Disematkan sebagai bagian dari, atau dapat dicolokkan ke, kendaraan otomotif.

• Menggunakan layar di baris kursi pengemudi sebagai layar utama.

Persyaratan tambahan di bagian lainnya dalam bagian ini khusus untuk penerapan perangkat Android Automotive.

2.5.1. Hardware

Implementasi perangkat otomotif:

• [7.1.1.1/A-0-1] HARUS memiliki layar dengan ukuran diagonal fisik minimal 6 inci.

• [7.1.1.1/A-0-2] HARUS memiliki tata letak ukuran layar minimal 750 dp x 480 dp.

• [7.1.1.1/A-0-3] HARUS mendukung komposisi GPU buffer grafis yang setidaknya sebesar resolusi tertinggi dari layar bawaan mana pun.

Jika implementasi perangkat Otomotif mendukung Multi-pengguna Serentak (tempat beberapa pengguna Android dapat berinteraksi dengan perangkat secara serentak, masing-masing menggunakan layarnya sendiri saat config_multiuserVisibleBackgroundUsers diaktifkan), perangkat tersebut:

• [7.1.1.1/A-1-1] HARUS memiliki layar terpisah dengan ukuran diagonal fisik minimal 6 inci untuk setiap zona penumpang pada tampilan utama. Ini harus diberi tag sebagai CarOccupantZoneManager.DISPLAY_TYPE_MAIN untuk setiap zona penghuni.

• [7.1.1.1/A-1-2] HARUS memiliki tata letak ukuran layar minimal 750 dp x 480 dp untuk setiap tampilan utama.

Jika implementasi perangkat Otomotif mendukung OpenGL ES 3.1, maka:

• [7.1.4.1/A-0-1] HARUS mendeklarasikan OpenGL ES 3.1 atau yang lebih tinggi.

• [7.1.4.1/A-0-2] HARUS mendukung Vulkan 1.1.

• [7.1.4.1/A-0-3] HARUS menyertakan pemuat Vulkan dan mengekspor semua simbol.

Jika implementasi perangkat Otomotif menyertakan dukungan untuk Vulkan, maka:

• [7.1.4.2/A-1-1] HARUS memenuhi persyaratan yang ditentukan oleh profil Dasar Pengukuran Android 2021.

Jika implementasi perangkat Otomotif mengklaim dukungan untuk tampilan rentang dinamis tinggi melalui Configuration.isScreenHdr(), maka:

• [7.1.4.5/A-1-1] HARUS mengiklankan dukungan untuk ekstensi EGL_EXT_gl_colorspace_bt2020_pq, EGL_EXT_surface_SMPTE2086_metadata, EGL_EXT_surface_CTA861_3_metadata, VK_EXT_swapchain_colorspace, dan VK_EXT_hdr_metadata.

Implementasi perangkat otomotif:

• [7.1.4.6/A-0-1] HARUS melaporkan apakah perangkat mendukung kemampuan pembuatan profil GPU melalui properti sistem graphics.gpu.profiler.support.

Jika implementasi perangkat Otomotif menyatakan dukungan melalui properti sistem graphics.gpu.profiler.support, maka:

• [7.1.4.6/A-1-1] HARUS melaporkan sebagai output rekaman aktivitas protobuf yang mematuhi skema untuk penghitung GPU dan GPU RenderStage yang ditentukan dalam dokumentasi Perfetto.

• [7.1.4.6/A-1-2] HARUS melaporkan nilai yang sesuai untuk penghitung GPU perangkat setelah gpu counter trace packet proto.

• [7.1.4.6/A-1-3] HARUS melaporkan nilai yang sesuai untuk RenderStage GPU perangkat setelah render stage trace packet proto.

• [7.1.4.6/A-1-4] HARUS melaporkan titik rekaman aktivitas Frekuensi GPU seperti yang ditentukan oleh format: power/gpu_frequency.

Implementasi perangkat otomotif:

• [7.1.5/A-0-1] HARUS menyertakan dukungan untuk mode kompatibilitas aplikasi lama sebagaimana diimplementasikan 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.

Implementasi perangkat otomotif:

• [7.1.7/A-0-1] HARUS mengonfigurasi tampilan sekunder dalam pandangan pengemudi sebagai FLAG_PRIVATE.

• [7.2.3/A-0-1] HARUS menyediakan fungsi Beranda dan DAPAT menyediakan fungsi Kembali dan Terbaru.

• [7.2.3/A-0-2] HARUS mengirimkan peristiwa tekan lama dan normal fungsi Kembali (KEYCODE_BACK) ke aplikasi latar depan.

• [7.3/A-0-1] HARUS menerapkan dan melaporkan GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED dan PARKING_BRAKE_ON.

• [7.3/A-0-2] Nilai flag NIGHT_MODE HARUS konsisten dengan mode siang/malam dasbor dan SEBAIKNYA didasarkan pada input sensor cahaya sekitar. Sensor cahaya sekitar yang mendasarinya MUNGKIN sama dengan Fotometer.

• [7.3/A-0-3] HARUS menyediakan kolom info tambahan sensor TYPE_SENSOR_PLACEMENT sebagai bagian dari SensorAdditionalInfo untuk setiap sensor yang disediakan.

• [7.3/A-SR1] MAY dead reckon Location dengan menggabungkan GPS/GNSS dengan sensor tambahan. Jika Lokasi diperkirakan, SANGAT DISARANKAN untuk menerapkan dan melaporkan jenis Sensor dan/atau ID Properti Kendaraan yang digunakan.

• [7.3/A-0-4] Lokasi yang diminta melalui LocationManager#requestLocationUpdates() TIDAK BOLEH dicocokkan dengan peta.

• [7.3.1/A-0-4] HARUS mematuhi sistem koordinat sensor mobil Android.

• [7.3/A-SR-1] SANGAT DISARANKAN untuk menyertakan akselerometer 3 sumbu dan giroskop 3 sumbu.

• [7.3/A-SR-2] SANGAT DISARANKAN untuk menerapkan dan melaporkan sensor TYPE_HEADING.

Jika implementasi perangkat Otomotif mendukung Multi-pengguna Serentak (tempat beberapa pengguna Android dapat berinteraksi dengan perangkat secara serentak, masing-masing menggunakan layarnya sendiri saat config_multiuserVisibleBackgroundUsers diaktifkan), perangkat tersebut:

• [7.3/A-1-1] HARUS menetapkan nilai flag NIGHT_MODE secara konsisten dengan mode siang/malam dasbor di semua layar, termasuk layar kursi belakang.

Jika penerapan perangkat Otomotif mencakup akselerometer, maka:

• [7.3.1/A-1-1] HARUS dapat melaporkan peristiwa hingga frekuensi minimal 100 Hz.

Jika implementasi perangkat menyertakan akselerometer 3 sumbu, maka:

• [7.3.1/A-SR-1] SANGAT DISARANKAN untuk menerapkan sensor gabungan untuk akselerometer dengan sumbu terbatas.

Jika implementasi perangkat Otomotif mencakup akselerometer dengan kurang dari 3 sumbu, maka:

• [7.3.1/A-1-3] HARUS menerapkan dan melaporkan sensor TYPE_ACCELEROMETER_LIMITED_AXES.

• [7.3.1/A-1-4] HARUS menerapkan dan melaporkan sensor TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

Jika implementasi perangkat Otomotif mencakup giroskop, maka:

• [7.3.4/A-2-1] HARUS dapat melaporkan peristiwa hingga frekuensi minimal 100 Hz.

• [7.3.4/A-2-3] HARUS mampu mengukur perubahan orientasi hingga 250 derajat per detik.

• [7.3.4/A-SR-1] SANGAT DISARANKAN untuk mengonfigurasi rentang pengukuran giroskop ke +/-250 dps guna memaksimalkan resolusi yang mungkin.

Jika penerapan perangkat Otomotif mencakup giroskop 3 sumbu, perangkat tersebut:

• [7.3.4/A-SR-2] SANGAT DISARANKAN untuk menerapkan sensor gabungan untuk giroskop sumbu terbatas.

Jika penerapan perangkat Otomotif mencakup giroskop dengan kurang dari 3 sumbu, maka:

• [7.3.4/A-4-1] HARUS menerapkan dan melaporkan sensor TYPE_GYROSCOPE_LIMITED_AXES.

• [7.3.4/A-4-2] HARUS menerapkan dan melaporkan sensor TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

Jika implementasi perangkat Otomotif mencakup penerima GPS/GNSS, tetapi tidak mencakup konektivitas data berbasis jaringan seluler, maka:

• [7.3.3/A-3-1] HARUS menentukan lokasi pada saat pertama kali penerima GPS/GNSS diaktifkan atau setelah 4+ hari dalam waktu 60 detik.

• [7.3.3/A-3-2] HARUS memenuhi kriteria waktu untuk perbaikan pertama seperti yang dijelaskan dalam 7.3.3/C-1-2 dan 7.3.3/C-1-6 untuk semua permintaan lokasi lainnya (yaitu permintaan yang bukan pertama kali atau setelah 4+ hari). Persyaratan 7.3.3/C-1-2 biasanya dipenuhi di kendaraan tanpa konektivitas data berbasis jaringan seluler, dengan menggunakan prediksi orbit GNSS yang dihitung di penerima, atau menggunakan lokasi kendaraan terakhir yang diketahui bersama dengan kemampuan untuk memperkirakan posisi selama minimal 60 detik dengan akurasi posisi yang memenuhi 7.3.3/C-1-3, atau kombinasi keduanya.

Jika penerapan perangkat otomotif mencakup sensor TYPE_HEADING, perangkat tersebut:

• [7.3.4/A-4-3] HARUS dapat melaporkan peristiwa hingga frekuensi minimal 1 Hz.

• [7.3.4/A-SR-3] SANGAT DISARANKAN untuk melaporkan peristiwa hingga frekuensi minimal 10 Hz.

• HARUS mengacu pada arah utara sebenarnya.

• HARUS tersedia meskipun kendaraan dalam keadaan diam.

• HARUS memiliki resolusi minimal 1 derajat.

Implementasi perangkat otomotif:

• [7.4.3/A-0-1] HARUS mendukung Bluetooth dan SEBAIKNYA mendukung Bluetooth LE.

• [7.4.3/A-0-2] Implementasi Android Automotive HARUS mendukung profil Bluetooth berikut:

  • Panggilan telepon melalui Profil Handsfree (HFP).
  • Pemutaran media melalui Audio Distribution Profile (A2 DP).
  • Kontrol pemutaran media melalui Remote Control Profile (AVRCP).
  • Berbagi kontak menggunakan Phone Book Access Profile (PBAP).

• [7.4.3/A-SR-1] SANGAT DISARANKAN untuk mendukung Message Access Profile (MAP) jika perangkat memiliki zona penumpang pengemudi.

Jika implementasi perangkat Otomotif mendukung Multi-pengguna Serentak (tempat beberapa pengguna Android dapat berinteraksi dengan perangkat secara serentak, masing-masing menggunakan layarnya sendiri saat config_multiuserVisibleBackgroundUsers diaktifkan), perangkat tersebut:

• [7.4.3/A-1-1] HARUS independen dan TIDAK mengganggu pengalaman BT pengguna lain.

Implementasi perangkat otomotif:

• [7.4.5/A] HARUS mencakup dukungan untuk konektivitas data berbasis jaringan seluler.

• [7.4.5/A] DAPAT menggunakan konstanta NetworkCapabilities#NET_CAPABILITY_OEM_PAID System API untuk jaringan yang harus tersedia untuk aplikasi sistem.

Jika implementasi perangkat menyertakan dukungan untuk radio siaran AM/FM dan mengekspos fungsi ke aplikasi apa pun, maka:

• [7.4/A-1-1] HARUS menyatakan dukungan untuk FEATURE_BROADCAST_RADIO.

Kamera belakang berarti kamera yang menghadap ke luar yang dapat ditempatkan di mana saja di kendaraan dan menghadap ke luar kabin kendaraan; yaitu, kamera ini merekam gambar di sisi jauh bodi kendaraan, seperti kamera tampilan belakang.

Kamera depan berarti kamera yang menghadap pengguna yang dapat ditempatkan di mana saja di kendaraan dan menghadap ke dalam kabin kendaraan; yaitu kamera tersebut mengambil gambar pengguna, seperti untuk konferensi video dan aplikasi serupa.

Implementasi perangkat otomotif:

• [7.5/A-SR-1] SANGAT DISARANKAN untuk menyertakan satu atau beberapa kamera yang menghadap ke luar.

• MUNGKIN menyertakan satu atau beberapa kamera yang menghadap pengguna.

• [7.5/A-SR-2] SANGAT DISARANKAN untuk mendukung streaming serentak dari beberapa kamera.

Jika implementasi perangkat Otomotif mencakup setidaknya satu kamera yang menghadap ke luar, maka untuk kamera tersebut, implementasi:

• [7.5/A-1-1] HARUS diorientasikan sehingga dimensi panjang kamera sejajar dengan bidang X-Y sumbu sensor otomotif Android.

• [7.5/A-SR-3] SANGAT DIREKOMENDASIKAN untuk memiliki hardware fokus tetap atau EDOF (Extended Depth of Field).

• [7.5/A-1-2] HARUS memiliki kamera utama yang menghadap dunia sebagai kamera yang menghadap dunia dengan ID kamera terendah.

Jika implementasi perangkat Otomotif mencakup setidaknya satu kamera yang menghadap pengguna, maka untuk kamera tersebut:

• [7.5/A-2-1] Kamera utama yang menghadap pengguna HARUS berupa kamera yang menghadap pengguna dengan ID kamera terendah.

• DAPAT diorientasikan sehingga dimensi panjang kamera sejajar dengan bidang X-Y sumbu sensor otomotif Android.

Jika implementasi perangkat Otomotif menyertakan kamera yang dapat diakses melalui API android.hardware.Camera atau android.hardware.camera2, maka:

• [7.5/A-3-1] HARUS mematuhi persyaratan kamera inti di bagian 7.5.

Jika implementasi perangkat Otomotif mencakup satu atau beberapa kamera yang dapat diakses melalui Layanan Sistem Tampilan yang Diperluas, untuk kamera tersebut, kamera tersebut:

• [7.5/A-5-1] TIDAK BOLEH memutar atau mencerminkan pratinjau kamera secara horizontal.

• [7.5/A-SR-4] SANGAT DISARANKAN untuk memiliki resolusi minimal 1,3 megapiksel.

Jika penerapan perangkat otomotif mencakup satu atau beberapa kamera yang dapat diakses melalui Extended View System Service dan android.hardware.Camera atau android.hardware.Camera2 API, maka untuk kamera tersebut, kamera tersebut:

• [7.5/A-6-1] HARUS melaporkan ID Kamera yang sama.

Jika implementasi perangkat Otomotif menyediakan API kamera eksklusif, maka:

• [7.5/A-7-1] HARUS menerapkan Camera API tersebut menggunakan android.hardware.camera2 API atau Extended View System API.

Implementasi perangkat otomotif:

• [7.6.1/A-0-1] HARUS memiliki minimal 4 GB penyimpanan non-volatile yang tersedia untuk data pribadi aplikasi (partisi /data).

• [7.6.1/A] HARUS memformat partisi data untuk menawarkan performa dan daya tahan yang lebih baik pada penyimpanan flash (misalnya, menggunakan sistem file f2fs).

Jika implementasi perangkat Otomotif menyediakan penyimpanan eksternal bersama melalui sebagian penyimpanan internal yang tidak dapat dilepas, maka:

• [7.6.1/A-SR-1] SANGAT DISARANKAN untuk mengurangi overhead I/O pada operasi yang dilakukan di penyimpanan eksternal, misalnya dengan menggunakan SDCardFS.

Jika implementasi perangkat Otomotif mendukung Multi-pengguna Serentak (tempat beberapa pengguna Android dapat berinteraksi dengan perangkat secara serentak, masing-masing menggunakan layarnya sendiri saat config_multiuserVisibleBackgroundUsers diaktifkan), perangkat tersebut:

• [7.6.1/A-1-1] HARUS memiliki, pada satu instance AAOS, minimal 4 GB untuk setiap pengguna Android serentak dari penyimpanan non-volatile yang tersedia untuk data pribadi aplikasi (partisi /data).

Jika implementasi perangkat Otomotif adalah 64-bit:

• [7.6.1/A-2-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 816 MB per layar utama jika salah satu kepadatan berikut digunakan:

  • 280 dpi atau lebih rendah pada layar kecil/normal
  • ldpi atau lebih rendah pada layar ekstra besar
  • mdpi atau lebih rendah di layar besar

• [7.6.1/A-2-2] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 944 MB per layar utama jika salah satu kepadatan berikut digunakan:

  • xhdpi atau lebih tinggi pada layar kecil/normal
  • hdpi atau lebih tinggi di layar besar
  • mdpi atau lebih tinggi di layar ekstra besar

• [7.6.1/A-2-3] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 1280 MB per layar utama jika salah satu kepadatan berikut digunakan:

  • 400 dpi atau lebih tinggi pada layar kecil/normal
  • xhdpi atau lebih tinggi di layar besar
  • tvdpi atau lebih tinggi pada layar ekstra besar

• [7.6.1/A-2-4] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 1824 MB per layar utama jika salah satu kepadatan berikut digunakan:

  • 560 dpi atau lebih tinggi pada layar kecil/normal
  • 400 dpi atau lebih tinggi di layar besar
  • xhdpi atau lebih tinggi pada layar ekstra besar

Perhatikan bahwa "memori yang tersedia untuk kernel dan ruang pengguna" di atas mengacu pada ruang memori yang disediakan selain memori yang sudah dikhususkan untuk komponen hardware seperti radio, video, dan sebagainya yang tidak berada di bawah kontrol kernel pada penerapan perangkat.

Implementasi perangkat otomotif:

• [7.7.1/A] HARUS menyertakan port USB yang mendukung mode periferal.

Jika implementasi perangkat Otomotif mencakup port USB dengan pengontrol yang beroperasi dalam mode periferal, maka:

• [7.7.1/A-1-1] HARUS menerapkan Android Open Accessory (AOA) API.

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

• [7.7.2/A-1-1] HARUS menerapkan class audio USB seperti yang dijelaskan dalam dokumentasi Android SDK.

Implementasi perangkat otomotif:

• [7.8.1/A-0-1] HARUS menyertakan mikrofon.

Implementasi perangkat otomotif:

• [7.8.2/A-0-1] HARUS memiliki output audio dan menyatakan android.hardware.audio.output.

Jika implementasi perangkat Otomotif mendukung Multi-pengguna Serentak (tempat beberapa pengguna Android dapat berinteraksi dengan perangkat secara serentak, masing-masing menggunakan layarnya sendiri saat config_multiuserVisibleBackgroundUsers diaktifkan), perangkat tersebut:

• [7.8.2/A-1-1] HARUS memiliki perangkat output audio untuk setiap tampilan utama untuk sistem multi-pengguna serentak.

• [7.8.2/A-1-2] HARUS memiliki zona audio Pengemudi yang mencakup speaker kabin global. Zona penumpang depan dapat berbagi zona audio pengemudi atau memiliki output audio sendiri.

Saat API AudioManager.getDevices() dipanggil saat periferal USB terhubung, API tersebut akan:

• [7.8.2.2/A-1-1] HARUS mencantumkan perangkat berjenis AudioDeviceInfo.TYPE_USB_HEADSET dan peran isSink() jika kolom jenis terminal audio USB adalah 0x0302.

• [7.8.2.2/A-1-2] HARUS mencantumkan perangkat berjenis AudioDeviceInfo.TYPE_USB_HEADSET dan peran isSink() jika kolom jenis terminal audio USB adalah 0x0402.

• [7.8.2.2/A-1-3] HARUS mencantumkan perangkat berjenis AudioDeviceInfo.TYPE_USB_HEADSET dan peran isSink() jika kolom jenis terminal audio USB adalah 0x0603.

• [7.8.2.2/A-1-4] HARUS mencantumkan perangkat berjenis AudioDeviceInfo.TYPE_USB_HEADSET dan peran isSink() jika kolom jenis terminal audio USB adalah 0x0400.

2.5.2. Multimedia

Implementasi perangkat otomotif HARUS mendukung format encoding dan decoding audio berikut serta menyediakannya untuk aplikasi pihak ketiga:

• [5.1/A-0-1] Profil AAC MPEG-4 (AAC LC)

• [5.1/A-0-2] Profil MPEG-4 HE AAC (AAC+)

• [5.1/A-0-3] AAC ELD (AAC yang ditingkatkan dengan delay rendah)

Implementasi perangkat otomotif HARUS mendukung format encoding video berikut dan menyediakannya untuk aplikasi pihak ketiga:

• [5.2/A-0-1] H.264 AVC

• [5.2/A-0-2] VP8

Implementasi perangkat otomotif HARUS mendukung format decoding video berikut dan menyediakannya untuk aplikasi pihak ketiga:

• [5.3/A-0-1] H.264 AVC

• [5.3/A-0-2] MPEG-4 SP

• [5.3/A-0-3] VP8

• [5.3/A-0-4] VP9

Implementasi perangkat otomotif SANGAT DISARANKAN untuk mendukung dekode video berikut:

• [5.3/A-SR-1] H.265 HEVC

Jika implementasi perangkat Otomotif mendukung Multi-pengguna Serentak (tempat beberapa pengguna Android dapat berinteraksi dengan perangkat secara serentak, masing-masing menggunakan layarnya sendiri saat config_multiuserVisibleBackgroundUsers diaktifkan), perangkat tersebut:

• [5.5.3/A-1-1] HARUS menentukan kurva volume yang identik untuk semua streaming output audio yang dipetakan ke grup volume yang sama seperti yang ditentukan dalam file konfigurasi audio mobil.

2.5.3. Software

Implementasi perangkat otomotif:

• [3/A-0-1] HARUS mendeklarasikan fitur android.hardware.type.automotive.

• [3/A-0-2] HARUS mendukung uiMode = UI_MODE_TYPE_CAR.

• [3/A-0-3] HARUS mendukung semua API publik di namespace android.car.*.

Jika implementasi perangkat Otomotif menyediakan API eksklusif menggunakan android.car.CarPropertyManager dengan android.car.VehiclePropertyIds, maka:

• [3/A-1-1] TIDAK BOLEH melampirkan hak istimewa khusus pada penggunaan properti ini oleh aplikasi sistem, atau mencegah aplikasi pihak ketiga menggunakan properti ini.

• [3/A-1-2] TIDAK BOLEH mereplikasi properti kendaraan yang sudah ada di SDK.

Implementasi perangkat otomotif:

• [3.2.1/A-0-1] HARUS mendukung dan menerapkan semua konstanta izin seperti yang didokumentasikan oleh halaman referensi Izin Otomotif.

• [3.2.3.1/A-0-1] HARUS memuat satu atau beberapa komponen aplikasi atau layanan dengan pengendali intent, untuk semua pola filter intent publik yang ditentukan oleh intent aplikasi berikut yang tercantum di sini.

• [3.2.3.1/A-0-2] HARUS memiliki aplikasi yang menangani intent ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE, dan ACTION_CREATE_DOCUMENT seperti yang dijelaskan dalam dokumen SDK, dan menyediakan kemudahan bagi pengguna untuk mengakses data penyedia dokumen menggunakan API DocumentsProvider.

Jika aplikasi setelan implementasi perangkat Otomotif menerapkan fungsi pemisahan, menggunakan penyematan aktivitas, maka:

• [3.2.3.1/A-1-1] HARUS memiliki aktivitas yang menangani intent Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY saat fungsi split aktif. Aktivitas HARUS dilindungi oleh android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK, dan HARUS memulai aktivitas Intent yang diuraikan dari Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.

• [3.4.1/A-0-1] HARUS menyediakan implementasi lengkap dari android.webkit.Webview API.

Jika implementasi perangkat Otomotif mendukung Multi-pengguna Serentak (tempat beberapa pengguna Android dapat berinteraksi dengan perangkat secara serentak, masing-masing menggunakan layarnya sendiri saat config_multiuserVisibleBackgroundUsers diaktifkan), perangkat tersebut:

• [3.8/A-1-1] HARUS menerapkan daftar UserRestrictions yang telah ditentukan sebelumnya berikut untuk pengguna sekunder penuh yang bukan pengguna latar depan saat ini, tetapi memiliki akses UI ke layar yang ditetapkan kepada mereka. Daftar UserRestrictions adalah DISALLOW_CONFIG_LOCALE, DISALLOW_CONFIG_BLUETOOTH, DISALLOW_BLUETOOTH, DISALLOW_CAMERA_TOGGLE, dan DISALLOW_MICROPHONE_TOGGLE.

• [3.8/A-1-2] TIDAK BOLEH mengizinkan pengguna sekunder penuh yang bukan pengguna latar depan saat ini, tetapi memiliki akses UI ke layar yang ditetapkan untuk mereka, mengubah mode siang/malam, lokalitas, tanggal, waktu, zona waktu, atau fitur warna layar (termasuk Kecerahan, Cahaya Malam, skala abu-abu Digital Wellbeing, dan Kurangi Warna Cerah) untuk pengguna lain melalui Setelan atau dari API.

Implementasi perangkat otomotif:

• [3.8.3/A-0-1] HARUS menampilkan notifikasi yang menggunakan Notification.CarExtender API saat diminta oleh aplikasi pihak ketiga.

• [3.8.4/A-SR-1] SANGAT DISARANKAN untuk menerapkan asisten di perangkat guna menangani tindakan Bantu.

Jika penerapan perangkat Otomotif mencakup tombol tekan untuk bicara, perangkat tersebut:

• [3.8.4/A-1-1] HARUS menggunakan penekanan singkat tombol bicara sebagai interaksi yang ditetapkan untuk meluncurkan aplikasi bantuan yang dipilih pengguna, dengan kata lain aplikasi yang menerapkan VoiceInteractionService.

Implementasi perangkat otomotif:

• [3.8.3.1/A-0-1] HARUS merender resource dengan benar seperti yang dijelaskan dalam dokumentasi SDK Notifications on Automotive OS.

• [3.8.3.1/A-0-2] HARUS menampilkan PUTAR dan SENYAP untuk tindakan notifikasi, bukan tindakan yang diberikan melalui Notification.Builder.addAction()

• [3.8.3.1/A] HARUS membatasi penggunaan tugas pengelolaan yang kompleks seperti kontrol per saluran notifikasi. DAPAT menggunakan afordans UI per aplikasi untuk mengurangi kontrol.

Jika implementasi perangkat Otomotif mendukung properti HAL Pengguna, maka:

• [3.9.3/A-1-1] HARUS menerapkan semua Properti siklus proses pengguna: INITIAL_USER_INFO, SWITCH_USER, CREATE_USER, dan REMOVE_USER.

Implementasi perangkat otomotif:

• [3.14/A-0-1] HARUS menyertakan framework UI untuk mendukung aplikasi pihak ketiga yang menggunakan media API seperti yang dijelaskan di bagian 3.14.

• [3.14/A-0-2] HARUS mengizinkan pengguna berinteraksi dengan Aplikasi Media secara aman saat mengemudi.

• [3.14/A-0-3] HARUS mendukung tindakan Intent implisit CAR_INTENT_ACTION_MEDIA_TEMPLATE dengan ekstra CAR_EXTRA_MEDIA_PACKAGE.

• [3.14/A-0-4] HARUS menyediakan kemampuan untuk membuka aktivitas preferensi Aplikasi Media, tetapi HANYA boleh mengaktifkannya jika Pembatasan UX Mobil tidak berlaku.

• [3.14/A-0-5] HARUS menampilkan pesan error yang ditetapkan oleh Aplikasi Media, dan HARUS mendukung ekstra opsional ERROR_RESOLUTION_ACTION_LABEL dan ERROR_RESOLUTION_ACTION_INTENT.

• [3.14/A-0-6] HARUS mendukung penawaran penelusuran dalam aplikasi untuk aplikasi yang mendukung penelusuran.

• [3.14/A-0-7] HARUS mematuhi CONTENT_STYLE_BROWSABLE_HINT dan CONTENT_STYLE_PLAYABLE_HINT definisi saat menampilkan hierarki MediaBrowser.

Jika implementasi perangkat Otomotif menyertakan aplikasi peluncur default, aplikasi tersebut:

• [3.14/A-1-1] HARUS menyertakan layanan media dan membukanya dengan maksud CAR_INTENT_ACTION_MEDIA_TEMPLATE.

Implementasi perangkat otomotif:

• [3.8/A] DAPAT membatasi permintaan aplikasi untuk masuk ke mode layar penuh seperti yang dijelaskan dalam immersive documentation.

• [3.8/A] DAPAT mempertahankan status bar dan menu navigasi agar selalu terlihat.

• [3.8/A] DAPAT membatasi permintaan aplikasi untuk mengubah warna di balik elemen UI sistem, guna memastikan elemen tersebut selalu terlihat jelas.

2.5.4. Performa dan Daya

• [8.1/A-0-1] Latensi frame yang konsisten. Latensi frame yang tidak konsisten atau penundaan untuk merender frame TIDAK BOLEH terjadi lebih sering daripada 5 frame dalam satu detik, dan SEBAIKNYA di bawah 1 frame dalam satu detik.

• [8.1/A-0-2] Latensi antarmuka pengguna. Implementasi perangkat HARUS memastikan pengalaman pengguna dengan latensi rendah dengan men-scroll daftar 10.000 entri daftar sebagaimana ditentukan oleh Android Compatibility Test Suite (CTS) dalam waktu kurang dari 36 detik.

• [8.1/A-0-3] Pengalihan tugas. Saat beberapa aplikasi telah diluncurkan, peluncuran ulang aplikasi yang sudah berjalan setelah diluncurkan HARUS membutuhkan waktu kurang dari 1 detik.

Implementasi perangkat otomotif:

• [8.2/A-0-1] HARUS melaporkan jumlah byte yang dibaca dan ditulis ke penyimpanan non-volatile per UID setiap proses sehingga statistik tersedia bagi developer melalui API Sistem android.car.storagemonitoring.CarStorageMonitoringManager. Android Open Source Project memenuhi persyaratan melalui modul kernel uid_sys_stats.

• [8.2/A-0-2] HARUS memastikan performa penulisan berurutan minimal 5 MB/dtk.

• [8.2/A-0-3] HARUS memastikan performa penulisan acak minimal 0,5 MB/s.

• [8.2/A-0-4] HARUS memastikan performa baca berurutan minimal 15 MB/dtk.

• [8.2/A-0-5] HARUS memastikan performa baca acak minimal 3,5 MB/s.

Jika penerapan perangkat Otomotif menampilkan android.os.Build.VERSION_CODES.U atau lebih besar untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, maka:

• [8.2/A-1-1] HARUS memastikan performa penulisan berurutan minimal 150 MB/dtk.

• [8.2/A-1-2] HARUS memastikan performa penulisan acak minimal 10 MB/dtk.

• [8.2/A-1-3] HARUS memastikan performa baca berurutan minimal 250 MB/dtk.

• [8.2/A-1-4] HARUS memastikan performa baca acak minimal 100 MB/s.

• [8.2/A-1-5] HARUS memastikan performa baca dan tulis berurutan paralel dengan performa baca 2x dan performa tulis 1x minimal 50 MB/dtk.

• [8.3/A-1-3] HARUS mendukung Mode Garasi.

• [8.3/A] HARUS dalam Mode Garasi setidaknya selama 15 menit setelah setiap perjalanan, kecuali:

  • Daya baterai habis.
  • Tidak ada tugas tidak aktif yang dijadwalkan.
  • Pengemudi keluar dari Mode Garasi.

• [8.4/A-0-1] HARUS menyediakan profil daya per komponen yang menentukan nilai konsumsi arus untuk setiap komponen hardware dan perkiraan pengurasan baterai yang disebabkan oleh komponen dari waktu ke waktu seperti yang didokumentasikan di situs Android Open Source Project.

• [8.4/A-0-2] HARUS melaporkan semua nilai konsumsi daya dalam miliampere jam (mAh).

• [8.4/A-0-3] HARUS melaporkan konsumsi daya CPU per UID setiap proses. Project Open Source Android memenuhi persyaratan melalui penerapan modul kernel uid_cputime.

• [8.4/A] HARUS diatribusikan ke komponen hardware itu sendiri jika tidak dapat mengatribusikan penggunaan daya komponen hardware ke aplikasi.

• [8.4/A-0-4] HARUS menyediakan penggunaan daya ini melalui perintah shell adb shell dumpsys batterystats kepada developer aplikasi.

2.5.5. Model Keamanan

Jika implementasi perangkat Otomotif mendukung beberapa pengguna, perangkat tersebut:

• [9.5/A-1-1] TIDAK BOLEH mengizinkan pengguna berinteraksi dengan atau beralih ke Pengguna Sistem Tanpa Layar, kecuali untuk penyiapan perangkat.

• [9.5/A-1-2] HARUS beralih ke Pengguna Sekunder sebelum BOOT_COMPLETED.

• [9.5/A-1-3] HARUS mendukung kemampuan untuk membuat Pengguna Tamu bahkan saat jumlah maksimum Pengguna di perangkat telah tercapai.

Jika implementasi perangkat Otomotif mendukung API Sistem VisualQueryDetectionService atau mekanisme lain untuk deteksi kueri tanpa indikasi akses mikrofon dan/atau kamera, maka:

• [9.8/A-1-1] HARUS memastikan layanan deteksi kueri hanya dapat mengirimkan data ke Sistem, ContentCaptureService, atau layanan pengenalan ucapan di perangkat (dibuat oleh SpeechRecognizer#createOnDeviceSpeechRecognizer()).

• [9.8/A-1-2] TIDAK BOLEH mengizinkan informasi audio atau video apa pun dikirim keluar dari VisualQueryDetectionService, kecuali ke ContentCaptureService atau layanan pengenalan ucapan di perangkat.

• [9.8/A-1-3] HARUS menampilkan pemberitahuan pengguna di UI Sistem saat perangkat mendeteksi niat pengguna untuk berinteraksi dengan Aplikasi Asisten Digital (seperti dengan mendeteksi kehadiran pengguna melalui kamera).

• [9.8/A-1-4] HARUS menampilkan indikator mikrofon dan menampilkan kueri pengguna yang terdeteksi di UI segera setelah kueri pengguna terdeteksi.

• [9.8/A-1-5] TIDAK BOLEH mengizinkan aplikasi yang dapat diinstal pengguna untuk menyediakan layanan deteksi kueri visual.

Jika penerapan perangkat Otomotif mendeklarasikan android.hardware.microphone, maka:

• [9.8.2/A-1-1] HARUS menampilkan indikator mikrofon saat aplikasi mengakses data audio dari mikrofon, tetapi tidak saat mikrofon hanya diakses oleh HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService atau aplikasi yang memiliki peran yang disebutkan di bagian 9.1 dengan ID CDD [C-4-X].

• [9.8.2/A-1-2] TIDAK BOLEH menyembunyikan indikator mikrofon untuk aplikasi sistem yang memiliki antarmuka pengguna yang terlihat atau interaksi pengguna langsung.

• [9.8.2/A-1-3] HARUS menyediakan kemudahan pengguna untuk mengaktifkan/menonaktifkan mikrofon di aplikasi Setelan.

Jika penerapan perangkat Otomotif mendeklarasikan android.hardware.camera.any, maka:

• [9.8.2/A-2-1] HARUS menampilkan indikator kamera saat aplikasi mengakses data kamera live, tetapi tidak saat kamera hanya diakses oleh aplikasi yang memiliki peran sebagaimana ditentukan dalam Bagian 9.1 Izin dengan ID CDD [C-4-X].

• [9.8.2/A-2-2] TIDAK BOLEH menyembunyikan indikator kamera untuk aplikasi sistem yang memiliki antarmuka pengguna yang terlihat atau interaksi pengguna langsung.

• [9.8.2/A-2-3] HARUS menyediakan kemudahan pengguna untuk mengalihkan kamera di aplikasi Setelan.

• [9.8.2/A-2-4] HARUS menampilkan aplikasi Terbaru dan Aktif menggunakan kamera seperti yang ditampilkan dari PermissionManager.getIndicatorAppOpUsageData(), bersama dengan pesan atribusi yang terkait dengannya.

Implementasi perangkat otomotif:

• [9/A-0-1] HARUS mendeklarasikan fitur android.hardware.security.model.compatible.

• [9.11/A-0-1] HARUS mencadangkan penerapan keystore dengan lingkungan eksekusi yang terisolasi.

• [9.11/A-0-2] HARUS memiliki penerapan algoritma kriptografi RSA, AES, ECDSA, dan HMAC serta fungsi hash MD5, SHA-1, dan SHA-2 untuk mendukung algoritma yang didukung sistem Android Keystore dengan benar di area yang terisolasi secara aman dari kode yang berjalan di kernel dan yang lebih tinggi. Isolasi aman HARUS memblokir semua potensi mekanisme yang memungkinkan kode kernel atau ruang pengguna mengakses status internal lingkungan yang diisolasi, termasuk DMA. Android Open Source Project (AOSP) upstream memenuhi persyaratan ini dengan menggunakan implementasi Trusty, tetapi solusi lain berbasis ARM TrustZone atau implementasi aman yang ditinjau pihak ketiga dari isolasi berbasis hypervisor yang tepat adalah opsi alternatif.

• [9.11/A-0-3] HARUS melakukan autentikasi layar kunci di lingkungan eksekusi yang terisolasi dan hanya jika berhasil, mengizinkan penggunaan kunci yang terikat dengan autentikasi. Kredensial layar kunci HARUS disimpan dengan cara yang hanya memungkinkan lingkungan eksekusi terisolasi melakukan autentikasi layar kunci. Proyek Open Source Android upstream menyediakan Hardware Abstraction Layer (HAL) Gatekeeper dan Trusty, yang dapat digunakan untuk memenuhi persyaratan ini.

• [9.11/A-0-4] HARUS mendukung pengesahan kunci dengan kunci penandatanganan pengesahan dilindungi oleh hardware yang aman dan penandatanganan dilakukan di hardware yang aman. Kunci penandatanganan pengesahan TIDAK BOLEH digunakan sebagai ID perangkat permanen.

Perhatikan bahwa jika implementasi perangkat sudah diluncurkan di versi Android sebelumnya, perangkat tersebut dikecualikan dari persyaratan untuk memiliki keystore yang didukung oleh lingkungan eksekusi terisolasi dan mendukung pengesahan kunci, kecuali jika perangkat tersebut mendeklarasikan fitur android.hardware.fingerprint yang memerlukan keystore yang didukung oleh lingkungan eksekusi terisolasi.

Implementasi perangkat otomotif:

• [9.14/A-0-1] HARUS membatasi pesan dari subsistem kendaraan framework Android (misalnya, mengizinkan jenis pesan dan sumber pesan yang diizinkan).

• [9.14/A-0-2] HARUS melakukan pengawasan terhadap serangan penolakan layanan dari framework Android atau aplikasi pihak ketiga. Hal ini melindungi dari software berbahaya yang membanjiri jaringan kendaraan dengan traffic, yang dapat menyebabkan gangguan fungsi subsistem kendaraan.

2.5.6. Kompatibilitas Alat dan Opsi Developer

Implementasi perangkat otomotif:

• Perfetto

  • [6.1/A-0-1] HARUS mengekspos biner /system/bin/perfetto kepada pengguna shell yang cmdlinenya sesuai dengan dokumentasi perfetto.

  • [6.1/A-0-2] Biner perfetto HARUS menerima sebagai input konfigurasi protobuf yang sesuai dengan skema yang ditentukan dalam dokumentasi perfetto.

  • [6.1/A-0-3] Biner perfetto HARUS menulis sebagai output rekaman aktivitas protobuf yang sesuai dengan skema yang ditentukan dalam dokumentasi perfetto.

  • [6.1/A-0-4] HARUS menyediakan, melalui biner perfetto, setidaknya sumber data yang dijelaskan dalam dokumentasi perfetto.

  • [6.1/A-0-5] Daemon perekaman aktivitas perfetto HARUS diaktifkan secara default (properti sistem persist.traced.enable).

2.6. Persyaratan Tablet

Perangkat Tablet Android mengacu pada implementasi perangkat Android yang biasanya memenuhi semua kriteria berikut:

• Digunakan dengan memegangnya di kedua tangan.
• Tidak memiliki konfigurasi clamshell atau convertible.
• Implementasi keyboard fisik yang digunakan dengan perangkat terhubung melalui koneksi standar (mis. USB, Bluetooth).
• Memiliki sumber listrik yang memberikan mobilitas, seperti baterai.
• Memiliki ukuran tampilan layar lebih besar dari 7" dan kurang dari 18", diukur secara diagonal.

Implementasi perangkat tablet memiliki persyaratan yang serupa dengan implementasi perangkat genggam. Pengecualian ditunjukkan dengan tanda * di bagian tersebut dan dicatat sebagai referensi di bagian ini.

2.6.1. Hardware

Giroskop

Jika implementasi perangkat Tablet menyertakan giroskop 3 sumbu, maka:

• [7.3.4/Tab-1-1] HARUS dapat mengukur perubahan orientasi hingga 1000 derajat per detik.

Memori dan Penyimpanan Minimum (Pasal 7.6.1)

Kepadatan layar yang tercantum untuk layar kecil/normal dalam persyaratan perangkat genggam tidak berlaku untuk tablet.

Mode Virtual Reality (Pasal 7.9.1)

Performa Tinggi Virtual Reality (Pasal 7.9.2)

Persyaratan virtual reality tidak berlaku untuk tablet.

2.6.2. Model Keamanan

Kunci dan Kredensial (Pasal 9.11)

Lihat Bagian [9.11].

Jika implementasi perangkat Tablet mencakup beberapa pengguna dan tidak mendeklarasikan tanda fitur android.hardware.telephony, maka:

• [9.5/T-1-1] HARUS mendukung profil terbatas, fitur yang memungkinkan pemilik perangkat mengelola pengguna tambahan dan kemampuannya di perangkat. Dengan profil yang dibatasi, pemilik perangkat dapat dengan cepat menyiapkan lingkungan terpisah bagi pengguna tambahan untuk bekerja, dengan kemampuan untuk mengelola pembatasan yang lebih mendetail dalam aplikasi yang tersedia di lingkungan tersebut.

Jika implementasi perangkat Tablet mencakup beberapa pengguna dan mendeklarasikan tanda fitur android.hardware.telephony, maka:

• [9.5/T-2-1] TIDAK BOLEH mendukung profil terbatas, tetapi HARUS selaras dengan penerapan kontrol AOSP untuk mengaktifkan /menonaktifkan pengguna lain agar tidak mengakses panggilan suara dan SMS.

2.6.2. Software

• [3.2.3.1/Tab-0-1] HARUS memuat satu atau beberapa aplikasi atau komponen layanan dengan pengendali intent, untuk semua pola filter intent publik yang ditentukan oleh intent aplikasi berikut yang tercantum di sini.

3. Software

3.1. Kompatibilitas API Terkelola

Lingkungan eksekusi bytecode Dalvik terkelola adalah mekanisme utama untuk aplikasi Android. Application programming interface (API) Android adalah kumpulan antarmuka platform Android yang diekspos ke aplikasi yang berjalan di lingkungan runtime terkelola.

Implementasi perangkat:

• [C-0-1] HARUS menyediakan penerapan lengkap, termasuk semua perilaku yang didokumentasikan, dari setiap API yang didokumentasikan yang diekspos oleh Android SDK atau API apa pun yang dihiasi dengan penanda "@SystemApi" dalam kode sumber Android upstream.

• [C-0-2] HARUS mendukung/mempertahankan semua class, metode, dan elemen terkait yang ditandai dengan anotasi TestApi (@TestApi).

• [C-0-3] TIDAK BOLEH menghilangkan API terkelola, mengubah antarmuka atau tanda tangan API, menyimpang dari perilaku yang didokumentasikan, atau menyertakan operasi kosong, kecuali jika diizinkan secara khusus oleh Definisi Kompatibilitas ini.

• [C-0-4] HARUS tetap menampilkan dan berperilaku dengan wajar, meskipun beberapa fitur hardware yang API-nya disertakan di Android dihilangkan. Lihat bagian 7 untuk mengetahui persyaratan khusus untuk skenario ini.

• [C-0-5] TIDAK BOLEH mengizinkan aplikasi pihak ketiga menggunakan antarmuka non-SDK, yang ditentukan sebagai metode dan kolom dalam paket bahasa Java yang ada di boot classpath di AOSP, dan yang tidak menjadi bagian dari SDK publik. Hal ini mencakup API yang dihiasi dengan anotasi @hide, tetapi tidak dengan @SystemAPI, seperti yang dijelaskan dalam dokumen SDK dan anggota class pribadi dan package-private.

• [C-0-6] HARUS dikirimkan dengan setiap antarmuka non-SDK dalam daftar yang dibatasi yang sama seperti yang diberikan melalui tanda sementara dan tanda daftar yang ditolak di jalur prebuilts/runtime/appcompat/hiddenapi-flags.csv untuk cabang level API yang sesuai di AOSP.

• [C-0-7] HARUS mendukung mekanisme update dinamis konfigurasi bertanda tangan untuk menghapus antarmuka non-SDK dari daftar yang dibatasi dengan menyematkan konfigurasi bertanda tangan di APK apa pun, menggunakan kunci publik yang ada di AOSP.

  Namun, mereka:

  • MAY, jika API tersembunyi tidak ada atau diimplementasikan secara berbeda pada implementasi perangkat, pindahkan API tersembunyi ke daftar yang ditolak atau hapus dari semua daftar yang dibatasi.
  • MAY, jika API tersembunyi belum ada di AOSP, tambahkan API tersembunyi ke salah satu daftar yang dibatasi.

3.1.1. Ekstensi Android

Android mendukung perluasan permukaan API terkelola dari level API tertentu dengan memperbarui versi ekstensi untuk level API tersebut. API android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) menampilkan versi ekstensi dari apiLevel yang diberikan, jika ada ekstensi untuk level API tersebut.

Implementasi perangkat Android:

• [C-0-1] HARUS memuat terlebih dahulu implementasi AOSP dari library bersama ExtShared dan layanan ExtServices dengan versi yang lebih besar dari atau sama dengan versi minimum yang diizinkan per setiap level API. Misalnya, implementasi perangkat Android 7.0 yang menjalankan level API 24 HARUS menyertakan setidaknya versi 1.

• [C-0-2] HANYA boleh menampilkan nomor versi ekstensi valid yang telah ditentukan oleh AOSP.

• [C-0-3] HARUS mendukung semua API yang ditentukan oleh versi ekstensi yang ditampilkan oleh android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) dengan cara yang sama seperti API terkelola lainnya didukung, dengan mengikuti persyaratan di bagian 3.1.

3.1.2. Library Android

Karena penghentian penggunaan klien HTTP Apache, implementasi perangkat:

• [C-0-1] TIDAK BOLEH menempatkan library org.apache.http.legacy di bootclasspath.
• [C-0-2] HARUS menambahkan library org.apache.http.legacy ke classpath aplikasi hanya jika aplikasi memenuhi salah satu kondisi berikut:
  • Menargetkan level API 28 atau yang lebih rendah.
  • Mendeklarasikan dalam manifesnya bahwa aplikasi memerlukan library dengan menetapkan atribut android:name dari <uses-library> ke org.apache.http.legacy.

Implementasi AOSP memenuhi persyaratan ini.

3.2. Kompatibilitas API Ringan

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

3.2.1. Izin

• [C-0-1] Penerap perangkat HARUS mendukung dan menerapkan semua konstanta izin seperti yang didokumentasikan oleh halaman referensi Izin. Perhatikan bahwa bagian 9 mencantumkan persyaratan tambahan terkait model keamanan Android.

3.2.2. Parameter Build

Android API mencakup sejumlah konstanta di class android.os.Build yang dimaksudkan untuk mendeskripsikan perangkat saat ini.

3.2.3. Kompatibilitas Maksud

3.2.3.1. Intent Aplikasi Umum

Intent Android memungkinkan komponen aplikasi meminta fungsi dari komponen Android lain. Project upstream Android menyertakan daftar aplikasi yang menerapkan beberapa pola intent untuk melakukan tindakan umum.

Implementasi perangkat:

• [C-SR-1] SANGAT DISARANKAN untuk memuat satu atau beberapa aplikasi atau komponen layanan dengan pengendali intent, untuk semua pola filter intent publik yang ditentukan oleh intent aplikasi berikut yang tercantum di sini dan memberikan pemenuhan, yaitu memenuhi ekspektasi developer untuk intent aplikasi umum ini seperti yang dijelaskan dalam SDK.

Lihat Bagian 2 untuk mengetahui maksud aplikasi wajib untuk setiap jenis perangkat.

3.2.3.2. Penyelesaian Intent

• [C-0-1] Karena Android adalah platform yang dapat di-extend, implementasi perangkat HARUS mengizinkan setiap pola intent yang dirujuk di bagian 3.2.3.1, kecuali Setelan, untuk diganti oleh aplikasi pihak ketiga. Implementasi open source Android upstream memungkinkan hal ini secara default.

• [C-0-2] Penerapan perangkat TIDAK BOLEH melampirkan hak istimewa khusus pada penggunaan pola intent ini oleh aplikasi sistem, atau mencegah aplikasi pihak ketiga terikat ke dan mengambil kontrol atas pola ini. Larangan ini secara khusus mencakup, tetapi tidak terbatas pada, menonaktifkan antarmuka pengguna "Pemilih" yang memungkinkan pengguna memilih di antara beberapa aplikasi yang menangani pola intent yang sama.

• [C-0-3] Implementasi perangkat HARUS menyediakan antarmuka pengguna bagi pengguna untuk mengubah aktivitas default untuk intent.

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

Android juga menyertakan mekanisme bagi aplikasi pihak ketiga untuk mendeklarasikan perilaku penautan aplikasi default yang tepercaya untuk jenis intent URI web tertentu. Jika deklarasi otoritatif tersebut ditentukan dalam pola filter intent aplikasi, penerapan perangkat:

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

3.2.3.3. Namespace Intent

• [C-0-1] Implementasi perangkat TIDAK BOLEH menyertakan komponen Android apa pun yang mematuhi pola intent atau intent siaran baru menggunakan ACTION, CATEGORY, atau string kunci lainnya di namespace android.* atau com.android.*.
• [C-0-2] Penerapan perangkat TIDAK BOLEH menyertakan komponen Android apa pun yang mematuhi intent baru atau pola intent siaran menggunakan ACTION, CATEGORY, atau string kunci lainnya di ruang paket milik organisasi lain.
• [C-0-3] Penerapan perangkat TIDAK BOLEH mengubah atau memperluas pola intent yang tercantum di pasal 3.2.3.1.
• Implementasi perangkat DAPAT mencakup pola intent menggunakan namespace yang jelas dan jelas terkait dengan organisasi mereka sendiri. Larangan ini serupa dengan yang ditentukan untuk class bahasa Java di bagian 3.6.

3.2.3.4. Intent Siaran

Aplikasi pihak ketiga mengandalkan platform untuk menyiarkan intent tertentu guna memberi tahu mereka tentang perubahan di lingkungan hardware atau software.

Implementasi perangkat:

• [C-0-1] HARUS menyiarkan intent siaran publik yang tercantum di sini sebagai respons terhadap peristiwa sistem yang sesuai seperti yang dijelaskan dalam dokumentasi SDK. Perhatikan bahwa persyaratan ini tidak bertentangan dengan pasal 3.5 karena batasan untuk aplikasi latar belakang juga dijelaskan dalam dokumentasi SDK. Selain itu, maksud siaran tertentu bersifat kondisional berdasarkan dukungan hardware. Jika perangkat mendukung hardware yang diperlukan, perangkat tersebut HARUS menyiarkan maksud dan memberikan perilaku sesuai dengan dokumentasi SDK.

3.2.3.5. Intent Aplikasi Bersyarat

Android menyertakan setelan yang memberi pengguna cara mudah untuk memilih aplikasi default mereka, misalnya untuk Layar utama atau SMS.

Jika memungkinkan, implementasi perangkat HARUS menyediakan menu setelan yang serupa dan kompatibel dengan pola filter intent dan metode API yang dijelaskan dalam dokumentasi SDK seperti di bawah.

Jika implementasi perangkat melaporkan android.software.home_screen, berarti perangkat tersebut:

• [C-1-1] HARUS mematuhi maksud android.settings.HOME_SETTINGS untuk menampilkan menu setelan aplikasi default untuk Layar Utama.

Jika implementasi perangkat melaporkan android.hardware.telephony.calling, berarti perangkat tersebut:

• [C-2-1] HARUS menyediakan menu setelan yang akan memanggil android.provider.Telephony.ACTION_CHANGE_DEFAULT intent untuk menampilkan dialog guna mengubah aplikasi SMS default.

• [C-2-2] HARUS mematuhi maksud android.telecom.action.CHANGE_DEFAULT_DIALER untuk menampilkan dialog yang memungkinkan pengguna mengubah aplikasi Telepon default.

  • HARUS menggunakan UI aplikasi Telepon default yang dipilih pengguna untuk panggilan masuk dan keluar, kecuali panggilan darurat, yang akan menggunakan aplikasi Telepon bawaan.

• [C-2-3] HARUS mematuhi intent android.telecom.action.CHANGE_PHONE_ACCOUNTS untuk memberikan kemudahan pengguna dalam mengonfigurasi ConnectionServices yang terkait dengan PhoneAccounts, serta PhoneAccount default yang akan digunakan penyedia layanan telekomunikasi untuk melakukan panggilan keluar. Implementasi AOSP memenuhi persyaratan ini dengan menyertakan menu "Opsi Akun Panggilan" dalam menu setelan "Panggilan".

• [C-2-4] HARUS mengizinkan android.telecom.CallRedirectionService untuk aplikasi yang memiliki peran android.app.role.CALL_REDIRECTION.

• [C-2-5] HARUS menyediakan kemampuan pengguna untuk memilih aplikasi yang memiliki peran android.app.role.CALL_REDIRECTION.

• [C-2-6] HARUS mematuhi intent android.intent.action.SENDTO dan android.intent.action.VIEW serta menyediakan aktivitas untuk mengirim/menampilkan pesan SMS.

• [C-SR-1] SANGAT DISARANKAN untuk mematuhi intent android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW & android.intent.action.DIAL dengan aplikasi dialer yang sudah dimuat sebelumnya yang dapat menangani intent ini dan memberikan pemenuhan seperti yang dijelaskan dalam SDK.

Jika implementasi perangkat melaporkan android.hardware.nfc.hce, berarti perangkat tersebut:

• [C-3-1] HARUS mematuhi intent android.settings.NFC_PAYMENT_SETTINGS untuk menampilkan menu setelan aplikasi default untuk Pembayaran nirsentuh.
• [C-3-2] HARUS mematuhi intent android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT untuk menampilkan aktivitas yang membuka dialog guna meminta pengguna mengubah layanan emulasi kartu default untuk kategori tertentu seperti yang dijelaskan dalam SDK.

Jika implementasi perangkat melaporkan android.hardware.nfc, berarti perangkat tersebut:

• [C-4-1] HARUS mematuhi intent android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED & android.nfc.action.TECH_DISCOVERED, untuk menampilkan aktivitas yang memenuhi ekspektasi developer untuk intent ini seperti yang dijelaskan dalam SDK.

Jika implementasi perangkat melaporkan android.hardware.bluetooth, berarti perangkat tersebut:

• [C-5-1] HARUS mematuhi intent 'android.bluetooth.adapter.action.REQUEST_ENABLE' dan menampilkan aktivitas sistem untuk mengizinkan pengguna mengaktifkan Bluetooth.
• [C-5-2] HARUS mematuhi intent 'android.bluetooth.adapter.action.REQUEST_DISCOVERABLE' dan menampilkan aktivitas sistem yang meminta mode dapat ditemukan.

Jika implementasi perangkat mendukung fitur DND, maka:

• [C-6-1] HARUS menerapkan aktivitas yang akan merespons intent ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS, yang untuk penerapan dengan UI_MODE_TYPE_NORMAL HARUS berupa aktivitas tempat pengguna dapat memberikan atau menolak akses aplikasi ke konfigurasi kebijakan DND.

Jika implementasi perangkat mengizinkan pengguna menggunakan metode input pihak ketiga di perangkat, pengguna:

• [C-7-1] HARUS menyediakan mekanisme yang dapat diakses pengguna untuk menambahkan dan mengonfigurasi metode input pihak ketiga sebagai respons terhadap maksud android.settings.INPUT_METHOD_SETTINGS.

Jika penerapan perangkat mendukung layanan aksesibilitas pihak ketiga, perangkat tersebut:

• [C-8-1] HARUS mematuhi maksud android.settings.ACCESSIBILITY_SETTINGS untuk menyediakan mekanisme yang dapat diakses pengguna untuk mengaktifkan dan menonaktifkan layanan aksesibilitas pihak ketiga bersama dengan layanan aksesibilitas yang telah dimuat sebelumnya.

Jika penerapan perangkat mencakup dukungan untuk Wi-Fi Easy Connect dan mengekspos fungsi ke aplikasi pihak ketiga, perangkat tersebut:

• [C-9-1] HARUS menerapkan API Intent Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI seperti yang dijelaskan dalam dokumentasi SDK.

Jika implementasi perangkat menyediakan mode penghemat data, maka:

• [C-10-1] HARUS menyediakan antarmuka pengguna di setelan, yang menangani intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, yang memungkinkan pengguna menambahkan aplikasi ke atau menghapus aplikasi dari daftar yang diizinkan.

Jika implementasi perangkat tidak menyediakan mode penghemat data, maka:

• [C-11-1] HARUS memiliki aktivitas yang menangani intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS tetapi DAPAT menerapkannya sebagai operasi no-op.

Jika implementasi perangkat menyatakan dukungan untuk kamera melalui android.hardware.camera.any, maka:

• [C-12-3] HARUS menangani dan HANYA mengizinkan aplikasi Android bawaan untuk menangani intent berikut MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE, dan MediaStore.ACTION_VIDEO_CAPTURE seperti yang dijelaskan dalam dokumen SDK.

Jika implementasi perangkat melaporkan android.software.device_admin, berarti perangkat tersebut:

• [C-13-1] HARUS mematuhi maksud android.app.action.ADD_DEVICE_ADMIN untuk memanggil UI guna memandu pengguna menambahkan administrator perangkat ke sistem (atau mengizinkan mereka menolaknya).

• [C-13-2] HARUS mematuhi intent android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD & android.app.action.START_ENCRYPTION dan memiliki aktivitas untuk memenuhi intent ini seperti yang dijelaskan di SDK di sini.

Jika implementasi perangkat menyatakan tanda fitur android.software.autofill, maka:

• [C-14-1] HARUS menerapkan sepenuhnya API AutofillService dan AutofillManager serta mematuhi intent android.settings.REQUEST_SET_AUTOFILL_SERVICE untuk menampilkan menu setelan aplikasi default guna mengaktifkan dan menonaktifkan isi otomatis serta mengubah layanan isi otomatis default bagi pengguna.

Jika implementasi perangkat menyertakan aplikasi yang sudah diinstal sebelumnya atau ingin mengizinkan aplikasi pihak ketiga mengakses statistik penggunaan, maka:

• [C-SR-2] SANGAT DISARANKAN untuk menyediakan mekanisme yang dapat diakses pengguna untuk memberikan atau mencabut akses ke statistik penggunaan sebagai respons terhadap intent android.settings.ACTION_USAGE_ACCESS_SETTINGS untuk aplikasi yang mendeklarasikan izin android.permission.PACKAGE_USAGE_STATS.

Jika implementasi perangkat bermaksud melarang aplikasi apa pun, termasuk aplikasi bawaan, mengakses statistik penggunaan, maka:

• [C-15-1] HARUS tetap memiliki aktivitas yang menangani pola intent android.settings.ACTION_USAGE_ACCESS_SETTINGS, tetapi HARUS menerapkannya sebagai operasi no-op, yaitu memiliki perilaku yang setara seperti saat pengguna ditolak aksesnya.

Jika implementasi perangkat menampilkan link ke aktivitas yang ditentukan oleh AutofillService_passwordsActivity di Setelan atau link ke sandi pengguna melalui mekanisme serupa, maka:

• [C-16-1] HARUS menampilkan link tersebut untuk semua layanan isi otomatis yang diinstal.

Jika implementasi perangkat mendukung VoiceInteractionService dan memiliki lebih dari satu aplikasi yang menggunakan API ini yang diinstal sekaligus, maka:

• [C-18-1] HARUS mematuhi maksud android.settings.ACTION_VOICE_INPUT_SETTINGS untuk menampilkan menu setelan aplikasi default untuk input suara dan bantuan.

Jika implementasi perangkat melaporkan fitur android.hardware.audio.output, maka:

• [C-SR-3] SANGAT DISARANKAN untuk mematuhi android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA & android.speech.tts.engine.GET_SAMPLE_TEXT intent memiliki aktivitas untuk memberikan pemenuhan intent ini seperti yang dijelaskan dalam SDK di sini.

Android menyertakan dukungan untuk screensaver interaktif, yang sebelumnya disebut sebagai Impian. Screensaver memungkinkan pengguna berinteraksi dengan aplikasi saat perangkat yang terhubung ke sumber listrik tidak ada aktivitas atau terpasang di dok meja. Implementasi Perangkat:

• HARUS menyertakan dukungan untuk screensaver dan menyediakan opsi setelan bagi pengguna untuk mengonfigurasi screensaver sebagai respons terhadap intent android.settings.DREAM_SETTINGS.

Jika implementasi perangkat melaporkan android.hardware.nfc.uicc atau android.hardware.nfc.ese, maka:

• [C-19-1] HARUS menerapkan NfcAdapter.ACTION_TRANSACTION_DETECTED Intent API (sebagai "EVT_TRANSACTION" yang ditentukan oleh spesifikasi teknis GSM Association TS.26 - NFC Handset Requirements).

3.2.4. Aktivitas di layar sekunder/beberapa layar

Jika implementasi perangkat memungkinkan peluncuran Aktivitas Android normal di lebih dari satu layar, maka:

• [C-1-1] HARUS menetapkan tombol fitur android.software.activities_on_secondary_displays.
• [C-1-2] HARUS menjamin kompatibilitas API yang serupa dengan aktivitas yang berjalan di tampilan utama.
• [C-1-3] HARUS menampilkan aktivitas baru di layar yang sama dengan aktivitas yang meluncurkannya, saat aktivitas baru diluncurkan tanpa menentukan target tampilan melalui API ActivityOptions.setLaunchDisplayId().
• [C-1-4] HARUS menghancurkan semua aktivitas, saat tampilan dengan tanda Display.FLAG_PRIVATE dihapus.
• [C-1-5] HARUS menyembunyikan konten dengan aman di semua layar saat perangkat dikunci dengan layar kunci yang aman, kecuali jika aplikasi memilih untuk ditampilkan di atas layar kunci menggunakan API Activity#setShowWhenLocked().
• HARUS memiliki android.content.res.Configuration yang sesuai dengan tampilan tersebut agar dapat ditampilkan, beroperasi dengan benar, dan mempertahankan kompatibilitas jika aktivitas diluncurkan di tampilan sekunder.

Jika implementasi perangkat memungkinkan peluncuran Aktivitas Android normal di layar sekunder dan layar sekunder memiliki tanda android.view.Display.FLAG_PRIVATE:

• [C-3-1] Hanya pemilik layar, sistem, dan aktivitas yang sudah ada di layar tersebut yang DAPAT meluncurkan ke layar tersebut. Semua orang dapat meluncurkan ke tampilan yang memiliki tanda android.view.Display.FLAG_PUBLIC.

3.3. Kompatibilitas Native API

Kompatibilitas kode native merupakan tantangan. Oleh karena itu, implementor perangkat:

• [C-SR-1] SANGAT DISARANKAN untuk menggunakan implementasi library yang tercantum di bawah dari Android Open Source Project upstream.

3.3.1. Antarmuka Biner Aplikasi

Bytecode Dalvik terkelola dapat memanggil kode native yang disediakan dalam file .apk aplikasi sebagai file ELF .so yang dikompilasi untuk arsitektur hardware perangkat yang sesuai. Karena kode native sangat bergantung pada teknologi prosesor yang mendasarinya, Android menentukan sejumlah Application Binary Interface (ABI) di Android NDK.

Implementasi perangkat:

• [C-0-1] HARUS kompatibel dengan satu atau beberapa ABI NDK Android yang ditentukan.
• [C-0-2] HARUS menyertakan dukungan untuk kode yang berjalan di lingkungan terkelola untuk memanggil kode native, menggunakan semantik Java Native Interface (JNI) standar.
• [C-0-3] HARUS kompatibel dengan sumber (yaitu kompatibel dengan header) dan kompatibel dengan biner (untuk ABI) dengan setiap library yang diperlukan dalam daftar di bawah.

• [C-0-5] HARUS melaporkan secara akurat Application Binary Interface (ABI) native yang didukung oleh perangkat, melalui parameter android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS, dan android.os.Build.SUPPORTED_64_BIT_ABIS, yang masing-masing merupakan daftar ABI yang dipisahkan koma dan diurutkan dari yang paling disukai hingga yang paling tidak disukai.

• [C-0-6] HARUS melaporkan, melalui parameter di atas, subset dari daftar ABI berikut dan TIDAK BOLEH melaporkan ABI apa pun yang tidak ada dalam daftar.

  • armeabi (tidak lagi didukung sebagai target oleh NDK)
  • armeabi-v7a
  • arm64-v8a
  • x86
  • x86-64
  • riscv64

• [C-0-7] HARUS menyediakan semua library berikut, yang menyediakan API native, untuk aplikasi yang menyertakan kode native:

  • libaaudio.so (dukungan audio native AAudio)
  • libamidi.so (dukungan MIDI native, jika fitur android.software.midi diklaim seperti yang dijelaskan di Bagian 5.9)
  • libandroid.so (dukungan aktivitas Android native)
  • libc (library C)
  • libcamera2ndk.so
  • libdl (linker 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
  • libjnigraphics.so
  • liblog (logging Android)
  • libmediandk.so (dukungan API media native)
  • libm (pustaka matematika)
  • libneuralnetworks.so (Neural Networks API)
  • libOpenMAXAL.so (dukungan OpenMAX AL 1.0.1)
  • libOpenSLES.so (dukungan audio OpenSL ES 1.0.1)
  • libRS.so
  • libstdc++ (Dukungan minimal untuk C++)
  • libvulkan.so (Vulkan)
  • libz (Kompresi Zlib)
  • Antarmuka JNI

• [C-0-8] TIDAK BOLEH menambahkan atau menghapus fungsi publik untuk library native yang tercantum di atas.

• [C-0-9] HARUS mencantumkan library non-AOSP tambahan yang diekspos langsung ke aplikasi pihak ketiga di /vendor/etc/public.libraries.txt.

• [C-0-10] TIDAK BOLEH mengekspos library native lainnya, yang diimplementasikan dan disediakan di AOSP sebagai library sistem, ke aplikasi pihak ketiga yang menargetkan level API 24 atau yang lebih tinggi karena library tersebut dicadangkan.

• [C-0-11] HARUS mengekspor semua simbol fungsi OpenGL ES 3.1 dan Android Extension Pack, sebagaimana ditentukan dalam NDK, melalui library libGLESv3.so. Perhatikan bahwa meskipun semua simbol HARUS ada, bagian 7.1.4.1 menjelaskan secara lebih mendetail persyaratan untuk kapan penerapan penuh setiap fungsi yang sesuai diharapkan.

• [C-0-12] HARUS mengekspor simbol fungsi untuk simbol fungsi Vulkan 1.1 inti, serta ekstensi VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1, dan VK_KHR_get_physical_device_properties2 melalui library libvulkan.so. Perhatikan bahwa meskipun semua simbol HARUS ada, bagian 7.1.4.2 menjelaskan secara lebih mendetail persyaratan kapan implementasi penuh setiap fungsi yang sesuai diharapkan.

• HARUS dibuat menggunakan kode sumber dan file header yang tersedia di Proyek Open Source Android upstream.

Perhatikan bahwa rilis Android mendatang dapat memperkenalkan dukungan untuk ABI tambahan.

3.3.2. Kompatibilitas Kode Native ARM 32-bit

Jika implementasi perangkat melaporkan dukungan ABI armeabi, maka:

• [C-3-1] JUGA harus mendukung armeabi-v7a dan melaporkan dukungannya, karena armeabi hanya untuk kompatibilitas mundur dengan aplikasi lama.

Jika implementasi perangkat melaporkan dukungan ABI armeabi-v7a, untuk aplikasi yang menggunakan ABI ini, aplikasi tersebut:

• [C-2-1] HARUS menyertakan baris berikut dalam /proc/cpuinfo, dan SEBAIKNYA TIDAK mengubah nilai pada perangkat yang sama, meskipun dibaca oleh ABI lain.

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

• [C-2-2] HARUS selalu menyediakan operasi berikut, bahkan jika ABI diterapkan pada arsitektur ARMv8, baik melalui dukungan CPU native atau melalui emulasi software:

  • Instruksi SWP dan SWPB.
  • Operasi penghalang CP15ISB, CP15DSB, dan CP15DMB.

• [C-2-3] HARUS menyertakan dukungan untuk ekstensi Advanced SIMD (alias NEON).

3.4. Kompatibilitas Web

3.4.1. Kompatibilitas WebView

Jika implementasi perangkat menyediakan implementasi lengkap API android.webkit.Webview, maka:

• [C-1-1] HARUS melaporkan android.software.webview.

• [C-1-2] HARUS menggunakan build Project Chromium dari Project Open Source Android upstream di cabang Android 17 untuk penerapan API android.webkit.WebView.

• [C-1-3] String agen pengguna yang dilaporkan oleh WebView untuk aplikasi yang menargetkan level SDK 35 dan yang lebih rendah HARUS dalam format berikut:

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

  • Nilai string $(VERSION) HARUS sama dengan nilai untuk android.os.Build.VERSION.RELEASE.

  • String $(MODEL) BOLEH kosong, tetapi jika tidak kosong, string tersebut HARUS memiliki nilai yang sama dengan android.os.Build.MODEL.

  • "Build/$(BUILD)" DAPAT dihilangkan, tetapi jika ada, string $(BUILD) HARUS sama dengan nilai untuk android.os.Build.ID.

  • Nilai string $(CHROMIUM_VER) HARUS berupa versi Chromium di Android Open Source Project upstream.

  • Implementasi perangkat DAPAT menghilangkan Mobile dalam string agen pengguna.

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

• [C-1-4] HARUS merender konten yang disediakan atau konten URL jarak jauh dalam proses yang berbeda dari aplikasi yang membuat instance WebView. Secara khusus, proses perender terpisah HARUS memiliki hak istimewa yang lebih rendah, berjalan sebagai ID pengguna terpisah, tidak memiliki akses ke direktori data aplikasi, tidak memiliki akses jaringan langsung, dan hanya memiliki akses ke layanan sistem yang diperlukan minimum melalui Binder. Penerapan WebView AOSP memenuhi persyaratan ini.

Perhatikan bahwa jika implementasi perangkat adalah 32-bit atau mendeklarasikan flag fitur android.hardware.ram.low, implementasi tersebut dikecualikan dari C-1-3.

3.4.2. Kompatibilitas Browser

Jika penerapan perangkat menyertakan aplikasi Browser mandiri untuk penjelajahan web umum, perangkat tersebut:

• [C-1-1] HARUS mendukung setiap API yang terkait dengan HTML5 berikut:

  • cache aplikasi/operasi offline
  • Tag <video>
  • geolocation

• [C-1-2] HARUS mendukung webstorage API HTML5/W3C dan SEBAIKNYA mendukung IndexedDB API HTML5/W3C. Perhatikan bahwa karena badan standar pengembangan web sedang beralih untuk lebih memilih IndexedDB daripada webstorage, IndexedDB diharapkan menjadi komponen wajib dalam versi Android mendatang.

• MUNGKIN mengirimkan string agen pengguna kustom di aplikasi Browser mandiri.

• HARUS menerapkan dukungan untuk sebanyak mungkin HTML5 di aplikasi Browser mandiri (baik berdasarkan aplikasi Browser WebKit upstream atau pengganti pihak ketiga).

Namun, jika penerapan perangkat tidak menyertakan aplikasi Browser mandiri, perangkat tersebut:

• [C-2-1] HARUS tetap mendukung pola maksud publik seperti yang dijelaskan di bagian 3.2.3.1.

3.5. Kompatibilitas Perilaku API

Implementasi perangkat:

• [C-0-9] HARUS memastikan bahwa kompatibilitas perilaku API diterapkan untuk semua aplikasi yang diinstal, kecuali jika dibatasi seperti yang dijelaskan dalam Bagian 3.5.1.
• [C-0-10] TIDAK BOLEH menerapkan pendekatan daftar yang diizinkan yang memastikan kompatibilitas perilaku API hanya untuk aplikasi yang dipilih oleh pelaksana perangkat.

Perilaku setiap jenis API (terkelola, ringan, native, dan web) harus konsisten dengan penerapan pilihan dari Project Open Source Android hulu. Beberapa area spesifik kompatibilitas adalah:

• [C-0-1] Perangkat TIDAK BOLEH mengubah perilaku atau semantik maksud standar.
• [C-0-2] Perangkat TIDAK BOLEH mengubah siklus proses atau semantik siklus proses jenis komponen sistem tertentu (seperti Layanan, Aktivitas, ContentProvider, dll.).
• [C-0-3] Perangkat TIDAK BOLEH mengubah semantik izin standar.
• Perangkat TIDAK BOLEH mengubah batasan yang diterapkan pada aplikasi latar belakang. Lebih khusus lagi, untuk aplikasi latar belakang:
  • [C-0-4] HARUS menghentikan eksekusi callback yang didaftarkan oleh aplikasi untuk menerima output dari GnssMeasurement dan GnssNavigationMessage.
  • [C-0-5] mereka HARUS membatasi frekuensi pembaruan yang diberikan ke aplikasi melalui class API LocationManager atau metode WifiManager.startScan().
  • [C-0-6] Jika aplikasi menargetkan API level 25 atau yang lebih tinggi, aplikasi tersebut TIDAK BOLEH mengizinkan pendaftaran penerima siaran untuk siaran implisit dari intent Android standar dalam manifes aplikasi, kecuali jika intent siaran memerlukan izin "signature" atau "signatureOrSystem" protectionLevel atau ada dalam daftar pengecualian.
  • [C-0-7] Jika aplikasi menargetkan level API 25 atau yang lebih tinggi, aplikasi tersebut HARUS menghentikan layanan latar belakang aplikasi, sama seperti jika aplikasi telah memanggil metode stopSelf() layanan, kecuali jika aplikasi ditempatkan dalam daftar yang diizinkan sementara untuk menangani tugas yang terlihat oleh pengguna.
  • [C-0-8] Jika aplikasi menargetkan level API 25 atau yang lebih tinggi, aplikasi tersebut HARUS melepaskan wakelock yang ditahan aplikasi.
• [C-0-11] Perangkat HARUS menampilkan penyedia keamanan berikut sebagai tujuh nilai array pertama dari metode Security.getProviders(), dalam urutan tertentu dan dengan nama tertentu (seperti yang ditampilkan oleh Provider.getName()) dan class, kecuali jika aplikasi telah mengubah daftar melalui insertProviderAt() atau removeProvider(). Perangkat DAPAT menampilkan penyedia tambahan setelah daftar penyedia yang ditentukan di bawah.
  1. AndroidNSSP - android.security.net.config.NetworkSecurityConfigProvider
  2. AndroidOpenSSL - com.android.org.conscrypt.OpenSSLProvider
  3. CertPathProvider - sun.security.provider.CertPathProvider
  4. AndroidKeyStoreBCWorkaround - android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
  5. BC - com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
  6. HarmonyJSSE - com.android.org.conscrypt.JSSEProvider
  7. AndroidKeyStore - android.security.keystore.AndroidKeyStoreProvider

Daftar di atas tidak lengkap. Compatibility Test Suite (CTS) menguji sebagian besar platform untuk kompatibilitas perilaku, tetapi tidak semuanya. Pelaksana bertanggung jawab untuk memastikan kompatibilitas perilaku dengan Android Open Source Project. Oleh karena itu, pengimplementasi perangkat SEBAIKNYA menggunakan kode sumber yang tersedia melalui Android Open Source Project jika memungkinkan, daripada mengimplementasikan ulang bagian penting sistem.

3.5.1. Pembatasan Aplikasi

Jika implementasi perangkat menerapkan mekanisme eksklusif untuk membatasi aplikasi (misalnya, mengubah atau membatasi perilaku API yang dijelaskan dalam SDK) dan mekanisme tersebut lebih ketat daripada Bucket Aplikasi Standby yang Dibatasi, maka:

• [C-1-1] HARUS mengizinkan pengguna melihat daftar aplikasi yang dibatasi.
• [C-1-2] HARUS menyediakan kemudahan pengguna untuk mengaktifkan / menonaktifkan semua batasan kepemilikan ini di setiap aplikasi.

• [C-1-3] TIDAK BOLEH menerapkan batasan kepemilikan ini secara otomatis tanpa bukti perilaku kondisi sistem yang buruk, tetapi BOLEH menerapkan batasan pada aplikasi setelah mendeteksi perilaku kondisi sistem yang buruk seperti wakelock yang macet, layanan yang berjalan lama, dan kriteria lainnya. Kriteria DAPAT ditentukan oleh penerapan perangkat, tetapi HARUS terkait dengan dampak aplikasi terhadap kesehatan sistem. Kriteria lain yang tidak murni terkait dengan kesehatan sistem, seperti kurangnya popularitas aplikasi di pasar, TIDAK BOLEH digunakan sebagai kriteria.

• [C-1-4] TIDAK BOLEH menerapkan pembatasan eksklusif ini secara otomatis untuk aplikasi jika pengguna telah menonaktifkan pembatasan aplikasi secara manual, dan DAPAT menyarankan pengguna untuk menerapkan pembatasan eksklusif ini.

• [C-1-5] HARUS memberi tahu pengguna jika batasan kepemilikan ini diterapkan ke aplikasi secara otomatis. Informasi tersebut HARUS diberikan dalam jangka waktu 24 jam sebelum penerapan pembatasan eksklusif ini.

• [C-1-6] HARUS menampilkan nilai benar untuk metode ActivityManager.isBackgroundRestricted() untuk setiap panggilan API dari aplikasi.

• [C-1-7] TIDAK BOLEH membatasi aplikasi latar depan teratas yang digunakan secara eksplisit oleh pengguna.

• [C-1-8] HARUS menangguhkan batasan kepemilikan ini pada aplikasi setiap kali pengguna mulai menggunakan aplikasi secara eksplisit, sehingga menjadikannya aplikasi latar depan teratas.

• [C-1-10] HARUS menyediakan dokumen atau situs web publik dan jelas yang menjelaskan cara penerapan pembatasan kepemilikan. Dokumen atau situs ini HARUS dapat ditautkan dari dokumen Android SDK dan HARUS menyertakan:

  • Kondisi pemicu untuk pembatasan eksklusif.
  • Apa dan bagaimana aplikasi dapat dibatasi.
  • Cara aplikasi dapat dikecualikan dari batasan tersebut.
  • Cara aplikasi dapat meminta pengecualian dari batasan kepemilikan, jika aplikasi tersebut mendukung pengecualian untuk aplikasi yang dapat diinstal pengguna.

Jika aplikasi sudah diinstal di perangkat dan tidak pernah digunakan secara eksplisit oleh pengguna selama lebih dari 30 hari, [C-1-3] [C-1-5] tidak berlaku.

Jika implementasi perangkat memperluas batasan aplikasi yang diterapkan di AOSP, implementasi tersebut:

• [C-2-1]HARUS mengikuti penerapan yang dijelaskan dalam dokumen ini.

3.5.2. Hibernasi Aplikasi

Jika implementasi perangkat menyertakan Hibernasi Aplikasi yang disertakan dalam AOSP atau memperluas fitur yang disertakan dalam AOSP, maka implementasi tersebut:

• [C-1-1] HARUS memenuhi semua persyaratan di bagian 3.5.1, kecuali untuk [C-1-6] dan [C-1-3].
• [C-1-2] HANYA boleh menerapkan pembatasan pada aplikasi untuk pengguna jika ada bukti bahwa pengguna belum menggunakan aplikasi selama jangka waktu tertentu. Durasi ini SANGAT DISARANKAN untuk satu bulan atau lebih. Penggunaan HARUS ditentukan oleh interaksi pengguna eksplisit melalui API UsageStats#getLastTimeVisible() atau apa pun yang akan menyebabkan aplikasi keluar dari status dihentikan paksa, termasuk binding layanan, binding penyedia konten, siaran eksplisit, dll., yang akan dilacak oleh API baru UsageStats#getLastTimeAnyComponentUsed().
• [C-1-3] HANYA boleh menerapkan batasan yang memengaruhi semua pengguna perangkat jika ada bukti bahwa paket belum digunakan oleh PENGGUNA MANAPUN selama jangka waktu tertentu. Durasi ini SANGAT DISARANKAN untuk satu bulan atau lebih.
• [C-1-4] TIDAK BOLEH membuat aplikasi tidak dapat merespons intent aktivitas, binding layanan, permintaan penyedia konten, atau siaran eksplisit.

Hibernasi Aplikasi di AOSP memenuhi persyaratan di atas.

3.6. Namespace API

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

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

Artinya, mereka:

• [C-0-1] TIDAK BOLEH mengubah API yang diekspos secara publik di platform Android dengan mengubah tanda tangan metode atau class, atau dengan menghapus class atau kolom class.
• [C-0-2] TIDAK BOLEH menambahkan elemen yang diekspos secara publik (seperti class atau antarmuka, atau kolom atau metode ke class atau antarmuka yang ada) atau API Pengujian atau Sistem ke API di namespace di atas. "Elemen yang diekspos secara publik" adalah konstruksi apa pun yang tidak dihiasi dengan penanda "@hide" seperti yang digunakan dalam kode sumber Android upstream.

Implementor perangkat DAPAT mengubah implementasi dasar API, tetapi perubahan tersebut:

• [C-0-3] TIDAK BOLEH memengaruhi perilaku yang dinyatakan dan tanda tangan bahasa Java dari API yang diekspos secara publik.
• [C-0-4] TIDAK BOLEH diiklankan atau diekspos kepada developer.

Namun, pengimplementasi perangkat DAPAT menambahkan API kustom di luar namespace Android standar, tetapi API kustom:

• [C-0-5] TIDAK BOLEH berada di namespace yang dimiliki oleh atau merujuk ke organisasi lain. Misalnya, pengimplementasi perangkat TIDAK BOLEH menambahkan API ke namespace com.google.* atau yang serupa: hanya Google yang boleh melakukannya. Demikian pula, Google TIDAK BOLEH menambahkan API ke namespace perusahaan lain.
• [C-0-6] HARUS dikemas dalam library bersama Android sehingga hanya aplikasi yang menggunakannya secara eksplisit (melalui mekanisme <uses-library>) yang terpengaruh oleh peningkatan penggunaan memori API tersebut.

Pengimplementasi perangkat DAPAT menambahkan API kustom dalam bahasa native, di luar API NDK, tetapi API kustom:

• [C-1-1] TIDAK BOLEH berada di library NDK atau library yang dimiliki oleh organisasi lain seperti yang dijelaskan di sini.

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

Perhatikan bahwa batasan di atas sesuai dengan konvensi standar untuk penamaan API dalam bahasa pemrograman Java; bagian ini hanya bertujuan untuk memperkuat konvensi tersebut dan mengikatnya melalui penyertaan dalam Definisi Kompatibilitas ini.

3.7. Kompatibilitas Runtime

Implementasi perangkat:

• [C-0-1] HARUS mendukung format Dalvik Executable (DEX) lengkap dan spesifikasi serta semantik bytecode Dalvik.

• [C-0-2] HARUS mengonfigurasi runtime Dalvik untuk mengalokasikan memori sesuai dengan platform Android upstream, dan seperti yang ditentukan oleh tabel berikut. (Lihat bagian 7.1.1 untuk definisi ukuran layar dan kepadatan layar.)

• HARUS menggunakan Android RunTime (ART), implementasi upstream referensi Format Dalvik Executable, dan sistem pengelolaan paket implementasi referensi.

• HARUS menjalankan pengujian fuzz dalam berbagai mode eksekusi dan arsitektur target untuk memastikan stabilitas runtime. Lihat JFuzz dan DexFuzz di situs Android Open Source Project.

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

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

3.8. Kompatibilitas Antarmuka Pengguna

3.8.1. Peluncur (Layar Beranda)

Android menyertakan aplikasi peluncur (layar utama) dan dukungan untuk aplikasi pihak ketiga untuk menggantikan peluncur perangkat (layar utama).

Jika implementasi perangkat mengizinkan aplikasi pihak ketiga mengganti layar utama perangkat, aplikasi tersebut:

• [C-1-1] HARUS mendeklarasikan fitur platform android.software.home_screen.

• [C-1-2] HARUS menampilkan objek AdaptiveIconDrawable saat aplikasi pihak ketiga menggunakan tag <adaptive-icon> untuk memberikan ikonnya, dan metode PackageManager untuk mengambil ikon dipanggil.

Jika implementasi perangkat menyertakan peluncur default yang mendukung penyematan pintasan dalam aplikasi, implementasi tersebut:

• [C-2-1] HARUS melaporkan true untuk ShortcutManager.isRequestPinShortcutSupported().

• [C-2-2] HARUS memiliki kemudahan pengguna yang menanyakan kepada pengguna sebelum menambahkan pintasan yang diminta oleh aplikasi melalui metode API ShortcutManager.requestPinShortcut().

• [C-2-3] HARUS mendukung pintasan yang dipasangi pin serta pintasan dinamis dan statis seperti yang didokumentasikan di halaman Pintasan Aplikasi.

Sebaliknya, jika penerapan perangkat tidak mendukung penyematan pintasan dalam aplikasi, maka:

• [C-3-1] HARUS melaporkan false untuk ShortcutManager.isRequestPinShortcutSupported().

Jika implementasi perangkat menerapkan peluncur default yang menyediakan akses cepat ke pintasan tambahan yang disediakan oleh aplikasi pihak ketiga melalui API ShortcutManager, implementasi tersebut:

• [C-4-1] HARUS mendukung semua fitur pintasan yang didokumentasikan (misalnya, pintasan statis dan dinamis, menyematkan pintasan) dan mengimplementasikan sepenuhnya API class ShortcutManager API.

Jika implementasi perangkat menyertakan aplikasi peluncur default yang menampilkan badge untuk ikon aplikasi, maka:

• [C-5-1] HARUS mematuhi metode API NotificationChannel.setShowBadge(). Dengan kata lain, tampilkan afordans visual yang terkait dengan ikon aplikasi jika nilai ditetapkan sebagai true, dan jangan tampilkan skema badge ikon aplikasi apa pun jika semua channel notifikasi aplikasi telah menetapkan nilai sebagai false.

• DAPAT mengganti badge ikon aplikasi dengan skema pemberian badge eksklusif mereka jika aplikasi pihak ketiga menunjukkan dukungan skema pemberian badge eksklusif melalui penggunaan API eksklusif, tetapi HARUS menggunakan resource dan nilai yang disediakan melalui API badge notifikasi yang dijelaskan dalam SDK, seperti Notification.Builder.setNumber() dan Notification.Builder.setBadgeIconType() API.

Jika penerapan perangkat mendukung ikon monokromatik, ikon ini:

• [C-6-1] HARUS digunakan hanya saat pengguna mengaktifkannya secara eksplisit (misalnya, melalui menu Setelan atau pemilih wallpaper).

3.8.2. Widget

Android mendukung widget aplikasi pihak ketiga dengan menentukan jenis komponen dan API serta siklus proses yang sesuai yang memungkinkan aplikasi mengekspos "AppWidget" kepada pengguna akhir.

Jika penerapan perangkat mendukung widget aplikasi pihak ketiga, perangkat tersebut:

• MUNGKIN mendukung widget aplikasi di layar kunci.

Jika implementasi perangkat mendukung widget aplikasi pihak ketiga dan penyematan pintasan dalam aplikasi, maka:

• [C-2-1] HARUS melaporkan true untuk AppWidgetManager.html.isRequestPinAppWidgetSupported().

• [C-2-2] HARUS memiliki kejelasan pengguna yang meminta pengguna sebelum menambahkan pintasan yang diminta oleh aplikasi melalui metode API AppWidgetManager.requestPinAppWidget().

3.8.3. Notifikasi

Android menyertakan API Notification dan NotificationManager yang memungkinkan developer aplikasi pihak ketiga memberi tahu pengguna tentang peristiwa penting dan menarik perhatian pengguna menggunakan komponen hardware (misalnya, suara, getaran dan cahaya) serta fitur software (misalnya, panel notifikasi, kolom sistem) di perangkat.

3.8.3.1. Penyajian Notifikasi

Jika implementasi perangkat mengizinkan aplikasi pihak ketiga untuk memberi tahu pengguna tentang peristiwa penting, maka:

• [C-1-1] HARUS mendukung notifikasi yang menggunakan fitur hardware, seperti yang dijelaskan dalam dokumentasi SDK, dan sejauh mungkin dengan hardware implementasi perangkat. Misalnya, jika penerapan perangkat mencakup vibrator, perangkat tersebut HARUS menerapkan API getaran dengan benar. Jika implementasi perangkat tidak memiliki hardware, API yang sesuai HARUS diimplementasikan sebagai operasi kosong (no-op). Perilaku ini dijelaskan lebih lanjut di bagian 7.

• [C-1-2] HARUS merender semua resource (ikon, file animasi, dll.) yang disediakan dalam API, atau dalam panduan gaya ikon Status/Bilah Sistem, meskipun mereka DAPAT memberikan pengalaman pengguna alternatif untuk notifikasi daripada yang disediakan oleh implementasi Android Open Source referensi.

• [C-1-3] HARUS mematuhi dan menerapkan dengan benar perilaku yang dijelaskan untuk API guna memperbarui, menghapus, dan mengelompokkan notifikasi.

• [C-1-4] HARUS memberikan perilaku lengkap API NotificationChannel yang didokumentasikan dalam SDK.

• [C-1-5] HARUS menyediakan kemudahan pengguna untuk memblokir dan mengubah notifikasi aplikasi pihak ketiga tertentu per setiap saluran dan tingkat paket aplikasi.

• [C-1-6] JUGA HARUS menyediakan kemampuan pengguna untuk menampilkan saluran notifikasi yang dihapus.

• [C-1-7] HARUS merender semua resource (gambar, stiker, ikon, dll.) yang diberikan melalui Notification.MessagingStyle dengan benar bersama teks notifikasi tanpa interaksi pengguna tambahan. Misalnya, HARUS menampilkan semua resource termasuk ikon yang disediakan melalui android.app.Person dalam percakapan grup yang disetel melalui setGroupConversation.

• [C-SR-1] SANGAT DISARANKAN untuk menyediakan kemampuan bagi pengguna untuk mengontrol notifikasi yang diekspos ke aplikasi yang telah diberi izin Pendengar Notifikasi. Granularitas HARUS sedemikian rupa sehingga pengguna dapat mengontrol jenis notifikasi yang diteruskan ke pemroses ini untuk setiap pemroses notifikasi tersebut. Jenisnya HARUS mencakup notifikasi "conversations", "alerting", "silent", dan "important ongoing".

• [C-SR-2] SANGAT DIREKOMENDASIKAN untuk menyediakan kemampuan bagi pengguna untuk menentukan aplikasi yang akan dikecualikan dari mengirimkan notifikasi ke pemroses notifikasi tertentu.

• [C-SR-3] SANGAT DISARANKAN untuk secara otomatis memunculkan kemudahan pengguna untuk memblokir notifikasi aplikasi pihak ketiga tertentu di setiap saluran dan tingkat paket aplikasi setelah pengguna menutup notifikasi tersebut beberapa kali.

• HARUS mendukung notifikasi lengkap.

• HARUS menampilkan beberapa notifikasi prioritas yang lebih tinggi sebagai notifikasi pendahuluan.

• HARUS memiliki kemampuan pengguna untuk menunda notifikasi.

• MAY hanya mengelola visibilitas dan waktu saat aplikasi pihak ketiga dapat memberi tahu pengguna tentang peristiwa penting untuk mengurangi masalah keselamatan seperti gangguan pengemudi.

Android 11 memperkenalkan dukungan untuk notifikasi percakapan, yaitu notifikasi yang menggunakan MessagingStyle dan menyediakan ID Pintasan Orang yang dipublikasikan.

Implementasi perangkat:

• [C-SR-4] SANGAT DISARANKAN untuk mengelompokkan dan menampilkan conversation notifications sebelum notifikasi non-percakapan, kecuali notifikasi layanan latar depan yang sedang berlangsung dan notifikasi importance:high.

Jika implementasi perangkat mendukung conversation notifications dan aplikasi menyediakan data yang diperlukan untuk bubbles, maka:

• [C-SR-5] SANGAT DISARANKAN untuk menampilkan percakapan ini sebagai balon. Implementasi AOSP memenuhi persyaratan ini dengan UI Sistem, Setelan, dan Peluncur default.

Jika implementasi perangkat mendukung notifikasi multimedia, perangkat tersebut:

• [C-2-1] HARUS menggunakan resource yang sama persis seperti yang disediakan melalui class API Notification.Style dan subclass-nya untuk elemen resource yang ditampilkan.

• HARUS menampilkan setiap elemen resource (misalnya, ikon, judul, dan teks ringkasan) yang ditentukan dalam class API Notification.Style dan subclass-nya.

Notifikasi peringatan dini adalah notifikasi yang ditampilkan kepada pengguna saat notifikasi masuk secara terpisah dari platform yang digunakan pengguna. Jika implementasi perangkat mendukung notifikasi pendahuluan, maka:

• [C-3-1] HARUS menggunakan tampilan dan resource notifikasi peringatan dini seperti yang dijelaskan dalam class API Notification.Builder saat notifikasi peringatan dini ditampilkan.

• [C-3-2] HARUS menampilkan tindakan yang diberikan melalui Notification.Builder.addAction() bersama dengan konten notifikasi tanpa interaksi pengguna tambahan seperti yang dijelaskan dalam SDK.

3.8.3.2. Layanan Pendengar Notifikasi

Android menyertakan NotificationListenerService API yang memungkinkan aplikasi (setelah diaktifkan secara eksplisit oleh pengguna) menerima salinan semua notifikasi saat diposting atau diupdate.

Implementasi perangkat:

• [C-0-1] HARUS memperbarui notifikasi dengan benar dan segera secara keseluruhan ke semua layanan pendengar yang diinstal dan diaktifkan pengguna tersebut, termasuk semua metadata yang dilampirkan ke objek Notifikasi.

• [C-0-2] HARUS mematuhi panggilan API snoozeNotification(), menutup notifikasi, dan melakukan callback setelah durasi tunda yang ditetapkan dalam panggilan API.

Jika implementasi perangkat memiliki kemudahan pengguna untuk menunda notifikasi, maka:

• [C-1-1] HARUS mencerminkan status notifikasi yang ditunda dengan benar melalui API standar seperti NotificationListenerService.getSnoozedNotifications().

• [C-1-2] HARUS menyediakan kemampuan pengguna ini untuk menunda notifikasi dari setiap aplikasi pihak ketiga yang diinstal, kecuali jika notifikasi tersebut berasal dari layanan persisten/latar depan.

3.8.3.3. DND (Jangan Ganggu) / Mode Prioritas

Jika implementasi perangkat mendukung fitur DND (juga disebut Mode Prioritas), perangkat tersebut:

• [C-1-1] HARUS, jika penerapan perangkat telah menyediakan cara bagi pengguna untuk memberikan atau menolak akses aplikasi pihak ketiga ke konfigurasi kebijakan DND, menampilkan Aturan DND otomatis yang dibuat oleh aplikasi bersama dengan aturan yang dibuat pengguna dan telah ditentukan sebelumnya.

• [C-1-3] HARUS mematuhi nilai suppressedVisualEffects yang diteruskan bersama NotificationManager.Policy dan jika aplikasi telah menyetel salah satu tanda SUPPRESSED_EFFECT_SCREEN_OFF atau SUPPRESSED_EFFECT_SCREEN_ON, aplikasi TERSEBUT HARUS menunjukkan kepada pengguna bahwa efek visual dinonaktifkan di menu setelan JANGAN GANGGU.

3.8.3.4. Perlindungan Notifikasi Sensitif

Informasi notifikasi sensitif mencakup konten seperti sandi sekali pakai, kode konfirmasi sekali pakai, dan kode autentikasi atau reset serupa yang dapat muncul di notifikasi kepada pengguna.

Jika implementasi perangkat mengizinkan aplikasi pihak ketiga untuk memberi tahu pengguna tentang peristiwa penting, maka:

• [C-1-1] HARUS menyamarkan informasi notifikasi sensitif agar tidak diteruskan ke pemroses notifikasi, kecuali jika layanan pemroses adalah salah satu dari:

  • Aplikasi yang ditandatangani sistem dengan uid < 10000
  • UI Sistem
  • Kerang
  • Aplikasi Perangkat Pendamping yang Ditunjuk (ditetapkan oleh CompanionDeviceManager)
  • Peran SYSTEM_AUTOMOTIVE_PROJECTION
  • Peran SYSTEM_NOTIFICATION_INTELLIGENCE
  • Peran HOME

Implementasi AOSP NotificationAssistantServices mencontohkan dan memenuhi persyaratan ini. Lihat android.ext.services.notification untuk melihat contoh.

3.8.4. Assist API

Android menyertakan Assist API untuk memungkinkan aplikasi memilih seberapa banyak informasi konteks saat ini yang dibagikan ke asisten di perangkat.

• [C-2-2] Interaksi yang ditetapkan untuk meluncurkan aplikasi bantuan seperti yang dijelaskan di bagian 7.2.3 HARUS meluncurkan aplikasi bantuan yang dipilih pengguna, dengan kata lain aplikasi yang menerapkan VoiceInteractionService, atau aktivitas yang menangani intent ACTION_ASSIST.

3.8.5. Pemberitahuan dan Toast

Aplikasi dapat menggunakan Toast API untuk menampilkan string non-modal pendek kepada pengguna akhir yang akan hilang setelah jangka waktu singkat, dan menggunakan TYPE_APPLICATION_OVERLAY API jenis jendela untuk menampilkan jendela pemberitahuan sebagai overlay di atas aplikasi lain.

Jika implementasi perangkat mencakup layar atau output video, perangkat tersebut:

• [C-1-1] HARUS menyediakan kemudahan pengguna untuk memblokir aplikasi agar tidak menampilkan jendela peringatan yang menggunakan TYPE_APPLICATION_OVERLAY. Penerapan AOSP memenuhi persyaratan ini dengan memiliki kontrol di panel notifikasi.

• [C-1-2] HARUS mematuhi Toast API dan menampilkan Toast dari aplikasi kepada pengguna akhir dengan cara yang sangat terlihat.

3.8.6. Tema

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

Android menyertakan keluarga tema "Holo" dan "Material" sebagai serangkaian gaya yang ditentukan untuk digunakan oleh developer aplikasi jika mereka ingin mencocokkan tampilan dan nuansa tema Holo seperti yang ditentukan oleh Android SDK.

Jika implementasi perangkat mencakup layar atau output video, perangkat tersebut:

• [C-1-1] TIDAK BOLEH mengubah salah satu atribut tema Holo yang diekspos ke aplikasi.

• [C-1-2] HARUS mendukung keluarga tema "Material" dan TIDAK BOLEH mengubah atribut tema Material atau asetnya yang diekspos ke aplikasi.

• [C-1-3] HARUS menyetel jenis font "sans-serif" ke Roboto versi 2.x untuk bahasa yang didukung Roboto, atau menyediakan kemudahan pengguna untuk mengubah font yang digunakan untuk jenis font "sans-serif" ke Roboto versi 2.x untuk bahasa yang didukung Roboto.

• [C-1-4] HARUS menghasilkan palet warna tone dinamis seperti yang ditentukan dalam dokumentasi AOSP Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (lihat android.theme.customization.system_palette dan android.theme.customization.theme_style).

• [C-1-5] HARUS membuat palet warna tonal dinamis menggunakan gaya tema warna yang tercantum dalam dokumentasi Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (lihat android.theme.customization.theme_styles), yaitu TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD, dan MONOCHROMATIC.

  "Warna sumber" yang digunakan untuk membuat palet tone warna dinamis saat dikirim dengan android.theme.customization.system_palette (seperti yang didokumentasikan dalam Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES).

• [C-1-6] HARUS memiliki nilai chroma CAM16 sebesar 5 atau lebih besar.

  • HARUS berasal dari wallpaper melalui com.android.systemui.monet.ColorScheme#getSeedColors, yang menyediakan beberapa warna sumber yang valid untuk dipilih.

  • HARUS menggunakan nilai 0xFF1B6EF3, jika tidak ada warna yang diberikan yang memenuhi persyaratan warna sumber di atas.

Android juga menyertakan keluarga tema "Default Perangkat" sebagai serangkaian gaya yang ditentukan untuk digunakan oleh developer aplikasi jika mereka ingin mencocokkan tampilan dan nuansa tema perangkat sebagaimana ditentukan oleh penerap 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 kolom navigasi dengan konten aplikasi mereka. Untuk memungkinkan pengalaman developer yang konsisten dalam konfigurasi ini, penting agar gaya ikon status dipertahankan di berbagai penerapan perangkat.

Jika implementasi perangkat menyertakan status bar sistem, implementasi tersebut:

• [C-2-1] HARUS menggunakan warna putih untuk ikon status sistem (seperti kekuatan sinyal dan level baterai) serta notifikasi yang dikeluarkan oleh sistem, kecuali jika ikon menunjukkan status yang bermasalah atau aplikasi meminta status bar terang menggunakan tanda WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS.

• [C-2-2] Implementasi perangkat Android HARUS mengubah warna ikon status sistem menjadi hitam (untuk mengetahui detailnya, lihat R.style) saat aplikasi meminta status bar terang.

3.8.7. Wallpaper Animasi

Android menentukan jenis komponen dan API serta siklus proses yang sesuai yang memungkinkan aplikasi mengekspos 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 pada fungsi, pada kecepatan frame yang wajar tanpa efek buruk pada aplikasi lain. Jika batasan pada hardware menyebabkan error pada wallpaper dan/atau aplikasi, tidak berfungsi, mengonsumsi CPU atau daya baterai yang berlebihan, atau berjalan pada kecepatan frame yang sangat rendah, hardware tersebut dianggap tidak mampu menjalankan live wallpaper. Sebagai contoh, beberapa wallpaper animasi dapat menggunakan konteks OpenGL 2.0 atau 3.x untuk merender kontennya. Wallpaper animasi tidak akan berjalan dengan andal di hardware yang tidak mendukung beberapa konteks OpenGL karena penggunaan konteks OpenGL oleh wallpaper animasi dapat berkonflik dengan aplikasi lain yang juga menggunakan konteks OpenGL.

• Penerapan perangkat yang mampu menjalankan wallpaper animasi secara andal seperti yang dijelaskan di atas HARUS menerapkan wallpaper animasi.

Jika implementasi perangkat menerapkan wallpaper animasi, perangkat tersebut:

• [C-1-1] HARUS melaporkan flag fitur platform android.software.live_wallpaper.

3.8.8. Pergantian Aktivitas

Kode sumber Android upstream mencakup layar ringkasan, antarmuka pengguna tingkat sistem untuk mengganti tugas dan menampilkan aktivitas dan tugas yang baru diakses menggunakan gambar thumbnail status grafis aplikasi pada saat pengguna terakhir kali keluar dari aplikasi.

Implementasi perangkat termasuk tombol navigasi fungsi terbaru seperti yang dijelaskan dalam bagian 7.2.3 DAPAT mengubah antarmuka.

Jika implementasi perangkat yang menyertakan tombol navigasi fungsi recent seperti yang dijelaskan dalam bagian 7.2.3 mengubah antarmuka, maka:

• [C-1-1] HARUS mendukung hingga minimal 7 aktivitas yang ditampilkan.

• SETIDAKNYA menampilkan judul 4 aktivitas sekaligus.

• HARUS menampilkan warna sorotan, ikon, judul layar di layar terbaru.

• HARUS menampilkan penutupan ("x") tetapi DAPAT menunda penutupan ini hingga pengguna berinteraksi dengan layar.

• HARUS menerapkan pintasan untuk beralih dengan mudah ke aktivitas sebelumnya.

• HARUS memicu tindakan peralihan 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.

• DAPAT menampilkan item terbaru afiliasi sebagai grup yang bergerak bersama.

• [C-SR-1] SANGAT DISARANKAN untuk menggunakan antarmuka pengguna Android upstream (atau antarmuka berbasis thumbnail yang serupa) untuk layar ringkasan.

3.8.9. Pengelolaan Input

Android menyertakan dukungan untuk Pengelolaan Input dan dukungan untuk editor metode input pihak ketiga.

Jika implementasi perangkat mengizinkan pengguna menggunakan metode input pihak ketiga di perangkat, pengguna:

• [C-1-1] HARUS mendeklarasikan fitur platform android.software.input_methods dan mendukung IME API seperti yang ditentukan dalam dokumentasi Android SDK.

3.8.10. Kontrol Media Layar Kunci

Remote Control Client API tidak digunakan lagi mulai dari Android 5.0 dan digantikan oleh Template Notifikasi Media yang memungkinkan aplikasi media terintegrasi dengan kontrol pemutaran yang ditampilkan di layar kunci.

3.8.11. Screensaver (sebelumnya Dreams)

Lihat bagian 3.2.3.5 untuk setelan maksud untuk mengonfigurasi screen saver.

3.8.12. Lokasi

Jika implementasi perangkat mencakup sensor hardware (misalnya, GPS) yang dapat memberikan koordinat lokasi, maka:

• [C-1-2] HARUS menampilkan status lokasi saat ini di menu Lokasi dalam Setelan.

• [C-1-3] TIDAK BOLEH menampilkan mode lokasi di menu Lokasi dalam Setelan.

3.8.13. Unicode dan Font

Android menyertakan dukungan untuk karakter emoji yang ditentukan dalam Unicode 10.0.

Jika implementasi perangkat mencakup layar atau output video, perangkat tersebut:

• [C-1-1] HARUS dapat merender karakter emoji ini dalam glif berwarna.

• [C-1-2] HARUS menyertakan dukungan untuk:

  • Font Roboto 2 dengan berbagai ketebalan—sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light untuk bahasa yang tersedia di perangkat.

  • Cakupan Unicode 7.0 penuh untuk Latin, Yunani, dan Kiril, termasuk rentang Latin Extended A, B, C, dan D, serta semua glif dalam blok simbol mata uang Unicode 7.0.

• [C-1-3] TIDAK BOLEH menghapus atau mengubah NotoColorEmoji.tff di image sistem. (Menambahkan font emoji baru untuk mengganti emoji di NotoColorEmoji.tff dapat diterima)

• HARUS mendukung emoji warna kulit dan keluarga yang beragam seperti yang ditentukan dalam Unicode Technical Report #51.

Jika penerapan perangkat mencakup IME, maka:

• HARUS menyediakan metode input kepada pengguna untuk karakter emoji ini.

Android menyertakan dukungan untuk merender font Myanmar. Myanmar memiliki beberapa font yang tidak mematuhi Unicode, yang umumnya dikenal sebagai "Zawgyi", untuk merender bahasa Myanmar.

Jika implementasi perangkat mencakup dukungan untuk bahasa Burma, maka:

• [C-2-1] HARUS merender teks dengan font yang kompatibel dengan Unicode sebagai default; font yang tidak kompatibel dengan Unicode TIDAK BOLEH ditetapkan sebagai font default kecuali jika pengguna memilihnya di pemilih bahasa.

• [C-2-2] HARUS mendukung font Unicode dan font yang tidak kompatibel dengan Unicode jika font yang tidak kompatibel dengan Unicode didukung di perangkat. Font yang kompatibel dengan Non-Unicode TIDAK BOLEH menghapus atau mengganti font Unicode.

• [C-2-3] HARUS merender teks dengan font yang kompatibel dengan non-Unicode HANYA JIKA kode bahasa dengan kode skrip Qaag ditentukan (misalnya, my-Qaag). Tidak ada kode bahasa atau wilayah ISO lain (baik yang ditetapkan, tidak ditetapkan, atau dicadangkan) yang dapat digunakan untuk merujuk ke font yang tidak kompatibel dengan Unicode untuk Myanmar. Developer aplikasi dan penulis halaman web dapat menentukan my-Qaag sebagai kode bahasa yang ditetapkan seperti yang mereka lakukan untuk bahasa lain.

3.8.14. Multi-aplikasi

Jika implementasi perangkat memiliki kemampuan untuk menampilkan beberapa aktivitas secara bersamaan, perangkat tersebut:

• [C-1-1] HARUS menerapkan mode multi-aplikasi tersebut sesuai dengan perilaku aplikasi dan API yang dijelaskan dalam dokumentasi dukungan mode multi-aplikasi Android SDK dan memenuhi persyaratan berikut:

• [C-1-2] Persyaratan dihapus di Android 16.

• [C-1-3] TIDAK BOLEH menawarkan mode layar terpisah atau bentuk bebas jika tinggi layar kurang dari 440 dp dan lebar layar kurang dari 440 dp.

• [C-1-4] Aktivitas TIDAK BOLEH diubah ukurannya menjadi lebih kecil dari 220 dp dalam mode multi-aplikasi selain Picture-in-Picture.

• Implementasi perangkat dengan ukuran layar xlarge HARUS mendukung mode bentuk bebas.

Jika implementasi perangkat mendukung mode multi-aplikasi, dan mode layar terpisah, perangkat tersebut:

• [C-2-2] HARUS memangkas aktivitas yang di-dock pada multi-aplikasi layar terpisah, tetapi HARUS menampilkan beberapa kontennya, jika aplikasi Peluncur adalah jendela yang difokuskan.

• [C-2-3] HARUS mematuhi nilai AndroidManifestLayout_minWidth dan AndroidManifestLayout_minHeight yang dideklarasikan oleh aplikasi peluncur pihak ketiga dan tidak mengganti nilai ini selama menampilkan beberapa konten aktivitas yang di-dock.

Jika implementasi perangkat mendukung mode multi-aplikasi dan mode multi-aplikasi Picture-in-Picture, perangkat tersebut:

• [C-3-1] HARUS meluncurkan aktivitas dalam mode multi-aplikasi picture-in-picture saat aplikasi:

  • Menargetkan API level 26 atau yang lebih tinggi dan mendeklarasikan android:supportsPictureInPicture

  • Menargetkan level API 25 atau yang lebih rendah dan mendeklarasikan android:resizeableActivity dan android:supportsPictureInPicture.

• [C-3-2] HARUS mengekspos tindakan di SystemUI-nya seperti yang ditentukan oleh aktivitas PIP saat ini melalui API setActions().

• [C-3-3] HARUS mendukung rasio aspek yang lebih besar dari atau sama dengan 1:2,39 dan kurang dari atau sama dengan 2,39:1, seperti yang ditentukan oleh aktivitas PIP melalui API setAspectRatio().

• [C-3-4] HARUS menggunakan KeyEvent.KEYCODE_WINDOW untuk mengontrol jendela PIP; jika mode PIP tidak diterapkan, tombol HARUS tersedia untuk aktivitas latar depan.

• [C-3-5] HARUS menyediakan kemampuan pengguna untuk memblokir aplikasi agar tidak ditampilkan dalam mode PIP; penerapan AOSP memenuhi persyaratan ini dengan memiliki kontrol di panel notifikasi.

• [C-3-6] HARUS mengalokasikan lebar dan tinggi minimum berikut untuk jendela PIP saat aplikasi tidak mendeklarasikan nilai apa pun untuk AndroidManifestLayout_minWidth dan AndroidManifestLayout_minHeight:

  • Perangkat dengan Configuration.uiMode yang disetel selain UI_MODE_TYPE_TELEVISION HARUS mengalokasikan lebar dan tinggi minimum 108 dp.

  • Perangkat dengan Configuration.uiMode yang disetel ke UI_MODE_TYPE_TELEVISION HARUS mengalokasikan lebar minimum 240 dp dan tinggi minimum 135 dp.

Jika implementasi perangkat menyertakan lebih dari satu area tampilan yang kompatibel dengan Android dan menyediakan area tersebut untuk aplikasi, maka:

• [C-4-1] HARUS mendukung mode multi-aplikasi.

Jika implementasi perangkat mendukung mode multi-aplikasi, perangkat tersebut:

• [C-5-1] HARUS menerapkan level API Ekstensi Pengelola Jendela versi yang benar seperti yang dijelaskan dalam Ekstensi WindowManager.

3.8.15. Potongan Layar

Android mendukung potongan Layar seperti yang dijelaskan dalam dokumen SDK. API DisplayCutout menentukan area di tepi layar yang mungkin tidak berfungsi untuk aplikasi karena potongan layar atau layar melengkung di tepi.

Jika penerapan perangkat mencakup potongan layar, perangkat tersebut:

• [C-1-5] TIDAK BOLEH memiliki potongan jika rasio aspek perangkat adalah 1.0 (1:1).

• [C-1-2] TIDAK BOLEH memiliki lebih dari satu potongan per tepi.

• [C-1-3] HARUS mematuhi tanda potongan layar yang ditetapkan oleh aplikasi melalui API WindowManager.LayoutParams seperti yang dijelaskan dalam SDK.

• [C-1-4] HARUS melaporkan nilai yang benar untuk semua metrik potongan yang ditentukan dalam API DisplayCutout.

3.8.16. Kontrol Perangkat

Android menyertakan API ControlsProviderService dan Control untuk memungkinkan aplikasi pihak ketiga memublikasikan kontrol perangkat untuk status dan tindakan cepat bagi pengguna.

Lihat Bagian 2_2_3 untuk mengetahui persyaratan khusus perangkat.

3.8.17. Papan klip

Implementasi perangkat:

• [C-0-1] TIDAK BOLEH mengirim data papan klip ke komponen, aktivitas, layanan, atau di seluruh koneksi jaringan mana pun, tanpa tindakan pengguna yang jelas (misalnya, menekan tombol pada overlay) atau indikasi konten yang dikirim, kecuali untuk layanan yang disebutkan dalam 9.8.6 Pengambilan Konten dan Penelusuran Aplikasi.

Jika penerapan perangkat menghasilkan pratinjau yang terlihat oleh pengguna saat konten disalin ke papan klip untuk item ClipData apa pun yang ClipData.getDescription().getExtras() berisi android.content.extra.IS_SENSITIVE, maka:

• [C-1-1] HARUS menyamarkan pratinjau yang dapat dilihat pengguna

Implementasi referensi AOSP memenuhi persyaratan papan klip ini.

3.8.18. Tombol Lokasi

3.9. Administrasi Perangkat

Android menyertakan fitur yang memungkinkan aplikasi pengontrol kebijakan perangkat melakukan fungsi administrasi perangkat di tingkat sistem, seperti menerapkan kebijakan sandi atau melakukan penghapusan total dari jarak jauh, melalui API Pengelola Kebijakan Perangkat.

3.9.1. Penyediaan Perangkat

3.9.1.1. Penyediaan pemilik perangkat

Jika implementasi perangkat mendeklarasikan android.software.device_admin, implementasi tersebut:

• [C-1-1] HARUS mendukung pendaftaran Pengontrol Kebijakan Perangkat (DPC) sebagai aplikasi Pemilik Perangkat seperti yang dijelaskan di bawah:

  • Jika penerapan perangkat tidak mengonfigurasi pengguna maupun data pengguna, perangkat tersebut akan:

    • [C-1-5] HARUS mendaftarkan aplikasi DPC sebagai aplikasi Pemilik Perangkat atau mengaktifkan aplikasi DPC untuk memilih apakah akan menjadi Pemilik Perangkat atau Pemilik Profil, jika perangkat menyatakan dukungan Komunikasi Nirkabel Jarak Dekat (NFC) melalui flag fitur android.hardware.nfc dan menerima pesan NFC yang berisi data dengan jenis MIME MIME_TYPE_PROVISIONING_NFC.

    • [C-1-8] HARUS mengirim intent ACTION_GET_PROVISIONING_MODE setelah penyediaan pemilik perangkat dipicu sehingga aplikasi DPC dapat memilih apakah akan menjadi Pemilik Perangkat atau Pemilik Profil, bergantung pada nilai android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES, kecuali jika dapat ditentukan dari konteks bahwa hanya ada satu opsi yang valid.

    • [C-1-9] HARUS mengirim intent ACTION_ADMIN_POLICY_COMPLIANCE ke aplikasi Pemilik Perangkat jika Pemilik Perangkat ditetapkan selama penyediaan, terlepas dari metode penyediaan yang digunakan. Pengguna tidak boleh dapat melanjutkan di Wizard Penyiapan hingga aplikasi Pemilik Perangkat selesai.

  • Jika penerapan perangkat memiliki pengguna atau data pengguna, perangkat tersebut:

    • [C-1-7] TIDAK BOLEH mendaftarkan aplikasi DPC sebagai Aplikasi Pemilik Perangkat lagi.

• [C-1-2] Persyaratan dihapus di Android 15.

• [C-2-1] Persyaratan dihapus di Android 15.

• [C-2-2] Persyaratan dihapus di Android 15.

• [C-2-3] Persyaratan dihapus di Android 15.

3.9.1.2. Penyediaan profil terkelola

Jika implementasi perangkat mendeklarasikan android.software.managed_users, implementasi tersebut:

• [C-1-1] HARUS mendeklarasikan android.software.device_admin dan menerapkan API yang memungkinkan aplikasi Pengontrol Kebijakan Perangkat (DPC) menjadi pemilik Profil Terkelola baru.

• [C-1-2] Persyaratan dihapus di Android 16.

• [C-1-3] HARUS menyediakan kemampuan pengguna berikut dalam 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 menunjukkan kapan setelan tertentu dibatasi oleh Admin Perangkat.
  • Pesan penjelasan singkat, sebagaimana diberikan oleh Admin Perangkat melalui setShortSupportMessage.
  • Ikon aplikasi DPC.

• [C-1-4] HARUS meluncurkan handler untuk intent ACTION_PROVISIONING_SUCCESSFUL di profil kerja jika Pemilik Profil ditetapkan saat penyediaan dimulai oleh intent android.app.action.PROVISION_MANAGED_PROFILE dan DPC telah menerapkan handler.

• [C-1-5] HARUS mengirim siaran ACTION_PROFILE_PROVISIONING_COMPLETE ke DPC profil kerja saat penyediaan dimulai oleh intent android.app.action.PROVISION_MANAGED_PROFILE.

• [C-1-6] HARUS mengirimkan intent ACTION_GET_PROVISIONING_MODE setelah penyediaan pemilik profil dipicu sehingga aplikasi DPC dapat memilih apakah akan menjadi Pemilik Perangkat atau Pemilik Profil, kecuali jika penyediaan dipicu oleh intent android.app.action.PROVISION_MANAGED_PROFILE.

• [C-1-7] HARUS mengirimkan intent ACTION_ADMIN_POLICY_COMPLIANCE ke profil kerja saat Pemilik Profil ditetapkan selama penyediaan, terlepas dari metode penyediaan yang digunakan, kecuali saat penyediaan dipicu oleh intent android.app.action.PROVISION_MANAGED_PROFILE. Pengguna tidak boleh melanjutkan di Wizard Penyiapan hingga aplikasi Pemilik Profil selesai.

• [C-1-8] HARUS mengirim siaran ACTION_MANAGED_PROFILE_PROVISIONED ke DPC profil pribadi saat Pemilik Profil ditetapkan, terlepas dari metode penyediaan yang digunakan.

3.9.2. Dukungan Profil Terkelola

Jika implementasi perangkat mendeklarasikan android.software.managed_users, implementasi tersebut:

• [C-1-1] HARUS mendukung profil terkelola melalui API android.app.admin.DevicePolicyManager.

• [C-1-2] HARUS mengizinkan satu dan hanya satu profil terkelola untuk dibuat.

• [C-1-3] HARUS menggunakan badge ikon (mirip dengan badge kerja upstream AOSP) untuk merepresentasikan aplikasi dan widget terkelola serta elemen UI berbadge lainnya seperti "Terbaru & Notifikasi".

• [C-1-4] HARUS menampilkan ikon notifikasi (mirip dengan badge tugas upstream AOSP) untuk menunjukkan kapan pengguna berada dalam aplikasi profil terkelola.

• [C-1-5] HARUS menampilkan toast yang menunjukkan bahwa pengguna berada di profil terkelola jika dan saat perangkat diaktifkan (ACTION_USER_PRESENT) dan aplikasi latar depan berada dalam profil terkelola.

• [C-1-6] Jika profil terkelola ada, HARUS menampilkan afordans visual di 'Pemilih' Intent untuk mengizinkan pengguna meneruskan intent dari profil terkelola ke pengguna utama atau sebaliknya, jika diaktifkan oleh Pengontrol Kebijakan Perangkat.

• [C-1-7] Jika profil terkelola ada, HARUS mengekspos kemampuan pengguna berikut untuk pengguna utama dan profil terkelola:

  • Akuntansi terpisah untuk penggunaan baterai, lokasi, data seluler, dan penyimpanan untuk pengguna utama dan profil terkelola.
  • Pengelolaan independen Aplikasi VPN yang diinstal dalam profil pengguna utama atau profil terkelola.
  • Pengelolaan independen aplikasi yang diinstal dalam profil pengguna utama atau profil terkelola.
  • Pengelolaan akun secara independen dalam profil pengguna utama atau terkelola.

• [C-1-8] HARUS memastikan aplikasi kontak, pesan, dan dialer yang sudah diinstal sebelumnya dapat menelusuri dan mencari informasi penelepon dari profil terkelola (jika ada) bersama dengan informasi dari profil utama, jika Pengontrol Kebijakan Perangkat mengizinkannya.

• [C-1-9] HARUS memastikan bahwa perangkat 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.

• [C-1-10] HARUS memastikan bahwa data screenshot disimpan di penyimpanan profil kerja saat screenshot diambil dengan jendela topActivity yang memiliki fokus (yang terakhir berinteraksi dengan pengguna di antara semua aktivitas) dan termasuk dalam aplikasi profil kerja.

• [C-1-11] TIDAK BOLEH merekam konten layar lainnya (status bar, notifikasi, atau konten profil pribadi apa pun) kecuali jendela/jendela aplikasi profil kerja saat menyimpan screenshot ke profil kerja (untuk memastikan bahwa data profil pribadi tidak disimpan di profil kerja).

Jika implementasi perangkat mendeklarasikan android.software.managed_users dan android.software.secure_lock_screen, maka:

• [C-2-1] HARUS mendukung kemampuan untuk menentukan rapat layar kunci terpisah yang memenuhi persyaratan berikut untuk memberikan akses ke aplikasi yang berjalan di profil terkelola saja.

  • Implementasi perangkat HARUS mematuhi maksud DevicePolicyManager.ACTION_SET_NEW_PASSWORD dan menampilkan antarmuka untuk mengonfigurasi kredensial layar kunci terpisah untuk profil terkelola.

  • Kredensial layar kunci profil terkelola HARUS menggunakan mekanisme pengelolaan dan penyimpanan kredensial yang sama dengan profil induk, seperti yang didokumentasikan di Situs Project Open Source Android.

  • Kebijakan sandi DPC HARUS diterapkan hanya pada kredensial layar kunci profil terkelola, kecuali dipanggil pada instance DevicePolicyManager yang ditampilkan oleh getParentProfileInstance.

• Saat kontak dari profil terkelola ditampilkan di log panggilan yang sudah diinstal, UI dalam panggilan, notifikasi panggilan tidak terjawab dan sedang berlangsung, aplikasi kontak dan pesan, kontak tersebut HARUS diberi badge yang sama dengan badge yang digunakan untuk menunjukkan aplikasi profil terkelola.

3.9.3. Dukungan Pengguna Terkelola

Jika implementasi perangkat mendeklarasikan android.software.managed_users, implementasi tersebut:

• [C-1-1] HARUS menyediakan kemudahan pengguna untuk logout dari pengguna saat ini dan beralih kembali ke pengguna utama dalam sesi multi-pengguna saat isLogoutEnabled kembali true. Afordans pengguna HARUS dapat diakses dari layar kunci tanpa membuka kunci perangkat.

Jika implementasi perangkat mendeklarasikan android.software.device_admin dan menyediakan kemudahan pengguna di perangkat untuk menambahkan Pengguna sekunder tambahan, perangkat tersebut:

• [C-SR-1] SANGAT DISARANKAN untuk menampilkan pengungkapan izin Pemilik Perangkat AOSP yang sama yang ditampilkan dalam alur yang dimulai oleh android.app.action.PROVISION_MANAGED_DEVICE, sebelum mengizinkan akun ditambahkan di Pengguna sekunder baru, sehingga pengguna memahami bahwa perangkat dikelola.

3.9.4. Persyaratan Peran Pengelolaan Kebijakan Perangkat

Jika implementasi perangkat mendeklarasikan android.software.device_admin, implementasi tersebut:

• [C-1-1] HARUS mendukung peran pengelolaan kebijakan perangkat sebagaimana ditentukan dalam Bagian 9.1. Aplikasi yang memiliki peran pengelolaan kebijakan perangkat DAPAT ditentukan dengan menyetel config_devicePolicyManagement ke nama paket. Nama paket HARUS diikuti dengan titik dua (:) dan sertifikat penandatanganan, kecuali jika aplikasi sudah dimuat sebelumnya.

Jika nama paket tidak ditentukan untuk config_devicePolicyManagement seperti yang dijelaskan di atas:

• [C-2-1] Implementasi perangkat HARUS mendukung penyediaan tanpa aplikasi pemegang peran pengelolaan kebijakan perangkat (AOSP menyediakan implementasi referensi).

Jika nama paket ditentukan untuk config_devicePolicyManagement seperti yang dijelaskan di atas:

• [C-3-1] Aplikasi HARUS diinstal di semua profil untuk pengguna.

• [C-3-2] Penerapan perangkat DAPAT menentukan aplikasi yang memperbarui pemegang peran pengelolaan kebijakan perangkat sebelum penyediaan dengan menetapkan config_devicePolicyManagementUpdater.

Jika nama paket ditentukan untuk config_devicePolicyManagementUpdater seperti yang dijelaskan di atas:

• [C-4-1] Aplikasi HARUS diprainstal di perangkat.

• [C-4-2] Aplikasi HARUS menerapkan filter intent yang menyelesaikan android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER.

3.9.5. Framework Penyelesaian Kebijakan Perangkat

Jika implementasi perangkat mendeklarasikan android.software.device_admin, implementasi tersebut:

• [C-1-1] HARUS menyelesaikan konflik kebijakan perangkat seperti yang didokumentasikan dalam Framework Penyelesaian Kebijakan Perangkat.

3.10. Aksesibilitas

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

Jika penerapan perangkat mendukung layanan aksesibilitas pihak ketiga, perangkat tersebut:

• [C-1-1] HARUS menyediakan penerapan framework aksesibilitas Android seperti yang dijelaskan dalam dokumentasi SDK API aksesibilitas.
• [C-1-2] HARUS membuat peristiwa aksesibilitas dan mengirimkan AccessibilityEvent yang sesuai ke semua implementasi AccessibilityService yang terdaftar sebagaimana didokumentasikan dalam SDK.
• [C-1-4] HARUS menyediakan kemudahan pengguna untuk mengontrol layanan aksesibilitas yang mendeklarasikan AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON. Perhatikan bahwa untuk penerapan perangkat dengan kolom navigasi sistem, perangkat TERSEBUT HARUS mengizinkan pengguna memiliki opsi untuk tombol di kolom navigasi sistem guna mengontrol layanan ini.

Jika implementasi perangkat menyertakan layanan aksesibilitas yang sudah diinstal sebelumnya, layanan tersebut:

• [C-2-1] HARUS menerapkan layanan aksesibilitas bawaan ini sebagai aplikasi Kompatibel dengan Direct Boot saat penyimpanan data dienkripsi dengan Enkripsi Berbasis File (FBE).
• HARUS menyediakan mekanisme dalam alur penyiapan langsung bagi pengguna untuk mengaktifkan layanan aksesibilitas yang relevan, serta opsi untuk menyesuaikan ukuran font, ukuran tampilan, dan gestur pembesaran.

3.11. Text-to-Speech

Android menyertakan API yang memungkinkan aplikasi menggunakan layanan text-to-speech (TTS) dan memungkinkan penyedia layanan menyediakan penerapan layanan TTS.

Jika implementasi perangkat melaporkan fitur android.hardware.audio.output, maka:

• [C-1-1] HARUS mendukung API framework TTS Android.

Jika implementasi perangkat mendukung penginstalan mesin TTS pihak ketiga, maka:

• [C-2-1] HARUS menyediakan kemudahan pengguna untuk memungkinkan pengguna memilih mesin TTS untuk digunakan di tingkat sistem.

3.12. T/A

3.13. Setelan Cepat

Android menyediakan komponen UI Setelan Cepat yang memungkinkan akses cepat ke tindakan yang sering digunakan atau sangat diperlukan.

Jika implementasi perangkat menyertakan komponen UI Setelan Cepat dan mendukung Setelan Cepat pihak ketiga, perangkat tersebut:

• [C-1-1] HARUS mengizinkan pengguna menambahkan atau menghapus kartu yang disediakan melalui quicksettings API dari aplikasi pihak ketiga.
• [C-1-2] TIDAK BOLEH menambahkan kartu dari aplikasi pihak ketiga secara otomatis langsung ke Setelan Cepat.
• [C-1-3] HARUS menampilkan semua kartu yang ditambahkan pengguna dari aplikasi pihak ketiga bersama dengan kartu setelan cepat yang disediakan sistem.

3.14. UI Media

Jika implementasi perangkat mencakup aplikasi yang tidak diaktifkan dengan suara (Aplikasi) yang berinteraksi dengan aplikasi pihak ketiga melalui MediaBrowser atau MediaSession, Aplikasi:

• [C-1-2] HARUS menampilkan ikon yang diperoleh melalui getIconBitmap() atau getIconUri() dan judul yang diperoleh melalui getTitle() dengan jelas seperti yang dijelaskan dalam MediaDescription. Dapat memperpendek judul untuk mematuhi peraturan keselamatan (mis. gangguan pengemudi).

• [C-1-3] HARUS menampilkan ikon aplikasi pihak ketiga setiap kali menampilkan konten yang disediakan oleh aplikasi pihak ketiga ini.

• [C-1-4] HARUS mengizinkan pengguna berinteraksi dengan seluruh hierarki MediaBrowser. DAPAT membatasi akses ke sebagian hierarki untuk mematuhi peraturan keselamatan (misalnya, gangguan pengemudi), tetapi TIDAK BOLEH memberikan perlakuan istimewa berdasarkan konten atau penyedia konten.

• [C-1-5] HARUS mempertimbangkan ketukan dua kali pada KEYCODE_HEADSETHOOK atau KEYCODE_MEDIA_PLAY_PAUSE sebagai KEYCODE_MEDIA_NEXT untuk MediaSession.Callback#onMediaButtonEvent.

3.15. Aplikasi Instan

Jika implementasi perangkat mendukung Aplikasi Instan, implementasi tersebut HARUS memenuhi persyaratan berikut:

• [C-1-1] Aplikasi Instan HANYA boleh diberi izin yang memiliki android:protectionLevel ditetapkan ke "instant".
• [C-1-2] Aplikasi Instan TIDAK BOLEH berinteraksi dengan aplikasi terinstal melalui intent implisit kecuali jika salah satu kondisi berikut terpenuhi:
  • Filter pola intent komponen diekspos dan memiliki CATEGORY_BROWSABLE
  • Tindakan ini adalah salah satu dari ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
  • Target diekspos secara eksplisit dengan android:visibleToInstantApps
• [C-1-3] Aplikasi Instan TIDAK BOLEH berinteraksi secara eksplisit dengan aplikasi terinstal kecuali jika komponen diekspos melalui android:visibleToInstantApps.
• [C-1-4] Aplikasi Terinstal TIDAK BOLEH melihat detail tentang Aplikasi Instan di perangkat kecuali jika Aplikasi Instan terhubung secara eksplisit ke aplikasi terinstal.

• Implementasi perangkat HARUS menyediakan kemampuan pengguna berikut untuk berinteraksi dengan Aplikasi Instan. AOSP memenuhi persyaratan dengan UI Sistem, Setelan, dan Peluncur default. Implementasi perangkat:

  • [C-1-5] HARUS menyediakan kemudahan pengguna untuk melihat dan menghapus Aplikasi Instan yang di-cache secara lokal untuk setiap paket aplikasi.
  • [C-1-6] HARUS memberikan notifikasi pengguna persisten yang dapat diciutkan saat Aplikasi Instan berjalan di latar depan. Notifikasi pengguna ini HARUS menyertakan bahwa Aplikasi Instan tidak memerlukan penginstalan dan menyediakan kemampuan pengguna yang mengarahkan pengguna ke layar info aplikasi di Setelan. Untuk Aplikasi Instan yang diluncurkan melalui intent web, sebagaimana ditentukan dengan menggunakan intent yang tindakan ditetapkan ke Intent.ACTION_VIEW dan dengan skema "http" atau "https", kemampuan pengguna tambahan HARUS memungkinkan pengguna untuk tidak meluncurkan Aplikasi Instan dan meluncurkan link terkait dengan browser web yang dikonfigurasi, jika browser tersedia di perangkat.
  • [C-1-7] HARUS mengizinkan Aplikasi Instan yang sedang berjalan diakses dari fungsi Terbaru jika fungsi Terbaru tersedia di perangkat.

• [C-1-8] HARUS memuat satu atau beberapa aplikasi atau komponen layanan dengan pengendali intent untuk intent yang tercantum di SDK di sini dan membuat intent terlihat untuk Aplikasi Instan.

3.16. Penyambungan Perangkat Pendamping

Android menyertakan dukungan untuk penyambungan perangkat pendamping guna mengelola asosiasi dengan perangkat pendamping secara lebih efektif dan menyediakan API CompanionDeviceManager untuk diakses aplikasi guna menggunakan fitur ini.

Jika implementasi perangkat mendukung fitur penyambungan perangkat pendamping, maka:

• [C-1-1] HARUS mendeklarasikan tanda fitur FEATURE_COMPANION_DEVICE_SETUP.

• [C-1-2] HARUS memastikan bahwa API dalam paket android.companion diimplementasikan sepenuhnya.

• [C-1-3] HARUS menyediakan kemudahan bagi pengguna untuk memilih/mengonfirmasi bahwa perangkat pendamping ada dan beroperasi, yang HARUS menggunakan pesan yang sama seperti yang diterapkan di AOSP tanpa penambahan atau modifikasi.

3.17. Aplikasi Berat

Jika implementasi perangkat mendeklarasikan fitur FEATURE_CANT_SAVE_STATE, maka perangkat tersebut:

• [C-1-1] HARUS hanya memiliki satu aplikasi terinstal yang menentukan cantSaveState yang berjalan dalam sistem dalam satu waktu. Jika pengguna keluar dari aplikasi tersebut tanpa keluar secara eksplisit (misalnya dengan menekan tombol beranda saat keluar dari aktivitas aktif, bukan menekan kembali tanpa aktivitas aktif yang tersisa dalam sistem), maka implementasi perangkat HARUS memprioritaskan aplikasi tersebut di RAM seperti yang dilakukan untuk hal lain yang diharapkan tetap berjalan, seperti layanan latar depan. Saat aplikasi tersebut berada di latar belakang, sistem tetap dapat menerapkan fitur pengelolaan daya padanya, seperti membatasi akses CPU dan jaringan.
• [C-1-2] HARUS menyediakan kemudahan UI untuk memilih aplikasi yang tidak akan berpartisipasi dalam mekanisme penyimpanan/pemulihan status normal setelah pengguna meluncurkan aplikasi kedua yang dideklarasikan dengan atribut cantSaveState.
• [C-1-3] TIDAK BOLEH menerapkan perubahan kebijakan lain pada aplikasi yang menentukan cantSaveState, seperti mengubah performa CPU atau mengubah prioritas penjadwalan.

Jika implementasi perangkat tidak mendeklarasikan fitur FEATURE_CANT_SAVE_STATE, maka:

• [C-1-1] HARUS mengabaikan atribut cantSaveState yang ditetapkan oleh aplikasi dan TIDAK BOLEH mengubah perilaku aplikasi berdasarkan atribut tersebut.

3.18. Kontak

Android menyertakan Contacts Provider API untuk mengizinkan aplikasi mengelola informasi kontak yang disimpan di perangkat. Data kontak yang dimasukkan langsung ke perangkat biasanya disinkronkan dengan layanan web, tetapi data tersebut MUNGKIN juga hanya berada secara lokal di perangkat. Kontak yang hanya disimpan di perangkat disebut sebagai kontak lokal.

RawContacts dikaitkan dengan atau disimpan di Akun jika kolom ACCOUNT_NAME, dan ACCOUNT_TYPE, untuk kontak mentah cocok dengan kolom Account.name dan Account.type yang sesuai dari akun.

Akun lokal default: Akun untuk kontak mentah yang hanya disimpan di perangkat dan tidak dikaitkan dengan Akun di AccountManager, yang dibuat dengan nilai null untuk kolom ACCOUNT_NAME dan ACCOUNT_TYPE.

Akun lokal kustom: Akun untuk kontak mentah yang hanya disimpan di perangkat dan tidak dikaitkan dengan Akun di AccountManager, yang dibuat dengan nilai non-null untuk kolom ACCOUNT_NAME dan ACCOUNT_TYPE.

Implementasi perangkat:

• [C-SR-1] SANGAT DISARANKAN untuk tidak membuat akun lokal kustom.

Jika penerapan perangkat menggunakan akun lokal kustom:

• [C-1-1] ACCOUNT_NAME, dari akun lokal kustom HARUS ditampilkan oleh ContactsContract.RawContacts.getLocalAccountName

• [C-1-2] ACCOUNT_TYPE, akun lokal kustom HARUS ditampilkan oleh ContactsContract.RawContacts.getLocalAccountType

• [C-1-3] Kontak mentah yang dimasukkan oleh aplikasi pihak ketiga tanpa menentukan akun HARUS dimasukkan ke akun kontak default perangkat. Jika akun kontak default adalah DEFAULT_ACCOUNT_STATE_LOCAL atau DEFAULT_ACCOUNT_STATE_NOT_SET, kontak mentah ini HARUS disimpan di akun lokal kustom.

• [C-1-4] Kontak mentah yang dimasukkan ke akun lokal kustom TIDAK BOLEH dihapus saat akun ditambahkan atau dihapus.

• [C-1-5] Operasi penghapusan yang dilakukan terhadap akun lokal kustom HARUS menyebabkan kontak mentah segera dihapus (seolah-olah parameter CALLER_IS_SYNCADAPTER disetel ke benar), meskipun parameter CALLER_IS_SYNCADAPTER disetel ke salah atau tidak ditentukan.

3.18.2. Pemilih Kontak Sistem

3.19. Setelan Bahasa

Implementasi perangkat:

• [C-0-1] TIDAK BOLEH menyediakan kemudahan pengguna untuk memilih perlakuan bahasa khusus gender untuk bahasa yang tidak mendukung terjemahan khusus gender. Lihat resource tata bahasa untuk mengetahui informasi selengkapnya.

3.20. Pengalaman berbasis Asisten

3.20.1. Persyaratan Streaming Audio Asisten

3.21. Dukungan Fitur Sinkronisasi Perangkat Pendamping

3.22. ComputerControls API

4. Kompatibilitas Pengemasan Aplikasi

Implementasi perangkat:

• [C-0-1] HARUS dapat menginstal dan menjalankan file ".apk" Android sebagaimana dihasilkan oleh alat "aapt" yang disertakan dalam Android SDK resmi.
  • Karena persyaratan di atas mungkin sulit dipenuhi, implementasi perangkat DISARANKAN untuk menggunakan sistem pengelolaan paket implementasi referensi AOSP.

• [C-0-3] TIDAK BOLEH memperluas format .apk, Manifes Android, bytecode Dalvik, atau bytecode RenderScript sedemikian rupa sehingga mencegah file tersebut diinstal dan berjalan dengan benar di perangkat kompatibel lainnya.

• [C-0-4] TIDAK BOLEH mengizinkan aplikasi selain "penginstal resmi" untuk paket saat ini meng-uninstal aplikasi secara diam-diam tanpa konfirmasi pengguna, seperti yang didokumentasikan dalam SDK untuk izin DELETE_PACKAGE. Satu-satunya pengecualian adalah aplikasi verifikasi paket sistem yang menangani intent PACKAGE_NEEDS_VERIFICATION dan aplikasi pengelola penyimpanan yang menangani intent ACTION_MANAGE_STORAGE.

• [C-0-5] HARUS memiliki aktivitas yang menangani intent android.settings.MANAGE_UNKNOWN_APP_SOURCES.

• [C-0-6] TIDAK BOLEH menginstal paket aplikasi dari sumber yang tidak dikenal, kecuali jika aplikasi yang meminta penginstalan memenuhi semua persyaratan berikut:

  • HARUS mendeklarasikan izin REQUEST_INSTALL_PACKAGES atau menetapkan android:targetSdkVersion ke 24 atau lebih rendah.
  • Aplikasi HARUS telah diberi izin oleh pengguna untuk menginstal aplikasi dari sumber yang tidak dikenal.

• HARUS menyediakan kemudahan pengguna untuk memberikan/mencabut izin menginstal aplikasi dari sumber tidak dikenal per aplikasi, tetapi DAPAT memilih untuk menerapkan ini sebagai operasi no-op dan menampilkan RESULT_CANCELED untuk startActivityForResult(), jika penerapan perangkat tidak ingin mengizinkan pengguna memiliki pilihan ini. Namun, bahkan dalam kasus tersebut, mereka HARUS menunjukkan kepada pengguna alasan tidak ada pilihan tersebut.

• [C-0-7] HARUS menampilkan dialog peringatan dengan string peringatan yang disediakan melalui API sistem PackageManager.setHarmfulAppWarning kepada pengguna sebelum meluncurkan aktivitas dalam aplikasi yang telah ditandai oleh API sistem PackageManager.setHarmfulAppWarning yang sama sebagai berpotensi membahayakan.

• HARUS menyediakan kemudahan bagi pengguna untuk memilih meng-uninstal atau meluncurkan aplikasi pada dialog peringatan.

• [C-0-8] HARUS menerapkan dukungan untuk Sistem File Incremental seperti yang didokumentasikan di sini.

• [C-0-9] HARUS mendukung verifikasi file .apk menggunakan APK Signature Scheme v4 dan APK Signature Scheme v4.1.

5. Kompatibilitas Multimedia

Implementasi perangkat:

• [C-0-1] HARUS mendukung format media, encoder, decoder, jenis file, dan format penampung yang ditentukan dalam bagian 5.1 untuk setiap codec yang dideklarasikan oleh MediaCodecList.
• [C-0-2] HARUS mendeklarasikan dan melaporkan dukungan encoder, dekoder yang tersedia untuk aplikasi pihak ketiga melalui MediaCodecList.
• [C-0-3] HARUS dapat mendekode dan menyediakan semua format yang dapat dienkode ke aplikasi pihak ketiga dengan benar. Hal ini mencakup semua bitstream yang dihasilkan encoder-nya dan profil yang dilaporkan di CamcorderProfile-nya.

Implementasi perangkat:

• HARUS bertujuan untuk meminimalkan latensi codec, dengan kata lain, mereka
  • TIDAK BOLEH menggunakan dan menyimpan buffer input serta hanya menampilkan buffer input setelah diproses.
  • TIDAK BOLEH menyimpan buffer yang didekode lebih lama dari yang ditentukan oleh standar (misalnya, SPS).
  • TIDAK BOLEH menyimpan buffer yang dienkode lebih lama dari yang diperlukan oleh struktur GOP.

Semua codec yang tercantum di bagian di bawah disediakan sebagai implementasi software dalam implementasi Android pilihan dari Proyek Open Source Android.

Perlu diperhatikan bahwa baik Google maupun Open Handset Alliance tidak membuat pernyataan bahwa codec ini bebas dari paten pihak ketiga. Pihak yang berniat menggunakan kode sumber ini dalam produk hardware atau software disarankan bahwa penerapan kode ini, termasuk dalam software open source atau shareware, mungkin memerlukan lisensi paten dari pemegang paten yang relevan.

5.1. Codec Media

5.1.1. Encoding Audio

Lihat detail selengkapnya di 5.1.3. Detail Codec Audio.

Jika implementasi perangkat mendeklarasikan android.hardware.microphone, perangkat tersebut HARUS mendukung encoding format audio berikut dan menyediakannya untuk aplikasi pihak ketiga:

• [C-1-1] PCM/WAVE
• [C-1-2] FLAC
• [C-1-3] Opus

Semua encoder audio HARUS mendukung:

• [C-3-1] Frame audio urutan byte native 16-bit PCM melalui android.media.MediaCodec API.

5.1.2. Dekode Audio

Lihat detail selengkapnya di 5.1.3. Detail Codec Audio.

Jika penerapan perangkat menyatakan dukungan untuk fitur android.hardware.audio.output, perangkat tersebut harus mendukung decoding format audio berikut:

• [C-1-1] Profil AAC MPEG-4 (AAC LC)
• [C-1-2] Profil MPEG-4 HE AAC (AAC+)
• [C-1-3] Profil MPEG-4 HE AACv2 (AAC+ yang ditingkatkan)
• [C-1-4] AAC ELD (AAC yang ditingkatkan dengan delay rendah)
• [C-1-5] FLAC
• [C-1-6] MP3
• [C-1-7] MIDI
• [C-1-8] Vorbis
• [C-1-9] PCM/WAVE termasuk format audio beresolusi tinggi hingga 24 bit, frekuensi sampling 192 kHz, dan 8 saluran. Perhatikan bahwa persyaratan ini hanya untuk decoding, dan perangkat diizinkan untuk melakukan downsampling dan downmix selama fase pemutaran.
• [C-1-10] Opus
• [C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile, yang mencakup USAC Baseline Profile, dan ISO/IEC 23003-4 Dynamic Range Control Profile)

Jika implementasi perangkat mendukung decoding buffer input AAC dari streaming multisaluran (yaitu lebih dari dua saluran) ke PCM melalui decoder audio AAC default di API android.media.MediaCodec, hal berikut HARUS didukung:

• [C-2-1] Dekode HARUS dilakukan tanpa downmixing (misalnya, stream AAC 5.0 harus didekode ke lima channel PCM, stream AAC 5.1 harus didekode ke enam channel PCM).

• [C-2-2] Metadata rentang dinamis HARUS seperti yang ditentukan dalam "Dynamic Range Control (DRC)" di ISO/IEC 14496-3, dan kunci DRC android.media.MediaFormat untuk mengonfigurasi perilaku terkait rentang dinamis decoder audio. Kunci DRC AAC diperkenalkan di API 21, dan adalah: 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.

• [C-SR-1] SANGAT DISARANKAN agar persyaratan C-2-1 dan C-2-2 di atas dipenuhi oleh semua decoder audio AAC.

Saat mendekodekan audio USAC, MPEG-D (ISO/IEC 23003-4):

• [C-3-1] Metadata Loudness dan DRC HARUS ditafsirkan dan diterapkan sesuai dengan MPEG-D DRC Dynamic Range Control Profile Level 1.

• [C-3-2] Dekoder HARUS berperilaku sesuai dengan konfigurasi yang ditetapkan dengan kunci android.media.MediaFormat berikut: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL dan KEY_AAC_DRC_EFFECT_TYPE.

Decoder profil MPEG-4 AAC, HE AAC, dan HE AACv2:

• MAY mendukung kontrol rentang dinamis dan keras suara menggunakan Profil Kontrol Rentang Dinamis ISO/IEC 23003-4.

Jika ISO/IEC 23003-4 didukung dan jika metadata ISO/IEC 23003-4 dan ISO/IEC 14496-3 ada dalam bitstream yang didekode, maka:

• Metadata ISO/IEC 23003-4 HARUS diutamakan.

Semua dekoder audio HARUS mendukung output:

• [C-6-1] Frame audio dengan urutan byte native 16-bit PCM melalui android.media.MediaCodec API.

Jika implementasi perangkat mendukung decoding buffer input AAC dari streaming multisaluran (yaitu lebih dari dua saluran) ke PCM melalui decoder audio AAC default di API android.media.MediaCodec, maka hal berikut HARUS didukung:

• [C-7-1] HARUS dapat dikonfigurasi oleh aplikasi menggunakan decoding dengan kunci KEY_MAX_OUTPUT_CHANNEL_COUNT untuk mengontrol apakah konten di-downmix ke stereo (saat menggunakan nilai 2) atau dikeluarkan menggunakan jumlah saluran native (saat menggunakan nilai yang sama dengan atau lebih besar dari jumlah tersebut). Misalnya, nilai 6 atau lebih tinggi akan mengonfigurasi decoder untuk menghasilkan 6 saluran saat diberi konten 5.1.

• [C-7-2] Saat mendekode, dekoder HARUS mengiklankan mask channel yang digunakan pada format output dengan kunci KEY_CHANNEL_MASK, menggunakan konstanta android.media.AudioFormat (contoh: CHANNEL_OUT_5POINT1).

Jika implementasi perangkat mendukung decoder audio selain decoder audio AAC default dan mampu menghasilkan output audio multi-channel (yaitu lebih dari 2 channel) saat diberi konten multi-channel yang dikompresi, maka:

• [C-SR-2] Decoder SANGAT DISARANKAN agar dapat dikonfigurasi oleh aplikasi menggunakan decoding dengan kunci KEY_MAX_OUTPUT_CHANNEL_COUNT untuk mengontrol apakah konten di-downmix ke stereo (saat menggunakan nilai 2) atau dikeluarkan menggunakan jumlah saluran asli (saat menggunakan nilai yang sama dengan atau lebih besar dari jumlah tersebut). Misalnya, nilai 6 atau lebih tinggi akan mengonfigurasi decoder untuk menghasilkan 6 saluran saat diberi konten 5.1.

• [C-SR-3] Saat mendekode, decoder SANGAT DISARANKAN untuk mengiklankan masker saluran yang digunakan pada format output dengan kunci KEY_CHANNEL_MASK, menggunakan konstanta android.media.AudioFormat (contoh: CHANNEL_OUT_5POINT1).

5.1.3. Detail Codec Audio

5.1.4. Encoding Gambar

Lihat detail selengkapnya di 5.1.6. Detail Codec Gambar.

Penerapan perangkat HARUS mendukung encoding gambar berikut:

• [C-0-1] JPEG
• [C-0-2] PNG
• [C-0-3] WebP
• [C-0-4] AVIF
  • Perangkat harus mendukung BITRATE_MODE_CQ dan Profil Dasar Pengukuran.

Jika penerapan perangkat mendukung encoding HEIC melalui android.media.MediaCodec untuk jenis media MIMETYPE_IMAGE_ANDROID_HEIC, maka:

• [C-1-1] HARUS menyediakan codec encoder HEVC yang dipercepat hardware yang mendukung mode kontrol bitrate BITRATE_MODE_CQ, profil HEVCProfileMainStill, dan ukuran frame 512 x 512 px.

5.1.5. Dekode Gambar

Lihat detail selengkapnya di 5.1.6. Detail Codec Gambar.

Penerapan perangkat HARUS mendukung decoding encoding gambar berikut:

• [C-0-1] JPEG

• [C-0-2] GIF

• [C-0-3] PNG

• [C-0-4] BMP

• [C-0-5] WebP

• [C-0-6] Raw

• [C-0-7] AVIF (Profil Dasar Pengukuran)

Jika penerapan perangkat mendukung decoding video HEVC, perangkat tersebut:

• [C-1-1] HARUS mendukung decoding gambar HEIF (HEIC).

Dekoder gambar yang mendukung format bit-depth tinggi (9+ bit per saluran):

• [C-2-1] HARUS mendukung output format setara 8-bit jika diminta oleh aplikasi, misalnya, melalui konfigurasi ARGB_8888 android.graphics.Bitmap.

5.1.6. Detail Codec Gambar

Format/Codec	Detail	Jenis File/Format Penampung yang Didukung
JPEG	Dasar+progresif	JPEG (.jpg)
GIF		GIF (.gif)
PNG		PNG (.png)
BMP		BMP (.bmp)
WebP		WebP (.webp)
Mentah		ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
HEIF	Gambar, Koleksi gambar, Urutan gambar	HEIF (.heif), HEIC (.heic)
AVIF (Profil Dasar Pengukuran)	Profil Dasar Pengukuran Gambar, Kumpulan gambar, Urutan gambar	Container HEIF (.avif)

Encoder dan decoder gambar yang diekspos melalui MediaCodec API

• [C-1-1] HARUS mendukung format warna fleksibel YUV420 8:8:8 (COLOR_FormatYUV420Flexible) melalui CodecCapabilities.

• [C-SR-1] SANGAT DISARANKAN untuk mendukung format warna RGB888 untuk mode input Surface.

• [C-1-3] HARUS mendukung setidaknya salah satu format warna YUV420 8:8:8 planar atau semiplanar: COLOR_FormatYUV420PackedPlanar (setara dengan COLOR_FormatYUV420Planar) atau COLOR_FormatYUV420PackedSemiPlanar (setara dengan COLOR_FormatYUV420SemiPlanar). Sangat DISARANKAN untuk mendukung keduanya.

5.1.7. Codec Video

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

Jika implementasi perangkat mencakup decoder atau encoder video:

• [C-1-1] Codec video HARUS mendukung ukuran bytebuffer output dan input yang mengakomodasi frame terkompresi dan tidak terkompresi terbesar yang layak sebagaimana ditentukan oleh standar dan konfigurasi, tetapi juga tidak mengalokasikan secara berlebihan.

• [C-1-2] Encoder dan dekoder video HARUS mendukung format warna fleksibel YUV420 8:8:8 (COLOR_FormatYUV420Flexible) melalui CodecCapabilities.

• [C-1-3] Encoder dan dekoder video HARUS mendukung setidaknya satu format warna YUV420 8:8:8 planar atau semiplanar: COLOR_FormatYUV420PackedPlanar(setara dengan COLOR_FormatYUV420Planar) atau COLOR_FormatYUV420PackedSemiPlanar (setara dengan COLOR_FormatYUV420SemiPlanar). Sebaiknya DUKUNG KEDUANYA.

• [C-SR-1] Encoder dan dekoder video SANGAT DIREKOMENDASIKAN untuk mendukung setidaknya salah satu format warna YUV420 8:8:8 planar atau semiplanar yang dioptimalkan hardware (YV12, NV12, NV21, atau format yang dioptimalkan vendor yang setara).

• [C-1-5] Dekoder video yang mendukung format bit-depth tinggi (9+ bit per saluran) HARUS mendukung output format yang setara dengan 8-bit jika diminta oleh aplikasi. Hal ini HARUS tercermin dengan mendukung format warna YUV420 8:8:8 melalui android.media.MediaCodecInfo.

Jika implementasi perangkat mengiklankan dukungan profil HDR melalui Display.HdrCapabilities, maka:

• [C-2-1] HARUS mendukung parsing dan penanganan metadata statis HDR.

Jika implementasi perangkat mengiklankan dukungan refresh intra melalui FEATURE_IntraRefresh di class MediaCodecInfo.CodecCapabilities, perangkat tersebut:

• [C-3-1] HARUS mendukung periode refresh dalam rentang 10 - 60 frame dan beroperasi secara akurat dalam 20% dari periode refresh yang dikonfigurasi.

Kecuali jika aplikasi menentukan sebaliknya menggunakan kunci format KEY_COLOR_FORMAT, penerapan dekoder video:

• [C-4-1] HARUS menggunakan format warna default yang dioptimalkan untuk tampilan hardware jika dikonfigurasi menggunakan output Surface.

• [C-4-2] HARUS menggunakan format warna YUV420 8:8:8 secara default yang dioptimalkan untuk pembacaan CPU jika dikonfigurasi untuk tidak menggunakan output Surface.

5.1.8. Daftar Codec Video

Format/Codec	Detail	Jenis File/Format Penampung yang akan didukung
H.263		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, hanya dekode)
H.264 AVC	Lihat pasal 5.2 dan 5.3 untuk mengetahui detailnya	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, tidak dapat digeser) Matroska (.mkv, hanya dekode)
H.265 HEVC	Lihat bagian 5.3 untuk mengetahui detailnya	MPEG-4 (.mp4) Matroska (.mkv, hanya dekode)
MPEG-2	Profil Utama	MPEG2-TS (.ts, tidak dapat digeser) MPEG-4 (.mp4, hanya dekode) Matroska (.mkv, hanya dekode)
MPEG-4 SP		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, hanya dekode)
VP8	Lihat pasal 5.2 dan 5.3 untuk mengetahui detailnya	WebM (.webm) Matroska (.mkv)
VP9	Lihat bagian 5.3 untuk mengetahui detailnya	WebM (.webm) Matroska (.mkv)
AV1	Lihat pasal 5.2 dan pasal 5.3 untuk mengetahui detailnya	MPEG-4 (.mp4) Matroska (.mkv, hanya dekode)

5.1.9. Keamanan Codec Media

Implementasi perangkat HARUS memastikan kepatuhan terhadap fitur keamanan codec media seperti yang dijelaskan di bawah.

Android menyertakan dukungan untuk OMX, API akselerasi multimedia lintas platform, serta Codec 2.0, API akselerasi multimedia overhead rendah.

Jika implementasi perangkat mendukung multimedia, implementasi tersebut:

• [C-1-1] HARUS menyediakan dukungan untuk codec media melalui API OMX atau Codec 2.0 (atau keduanya) seperti dalam Project Open Source Android dan tidak menonaktifkan atau mengakali perlindungan keamanan. Hal ini secara khusus tidak berarti bahwa setiap codec HARUS menggunakan OMX atau Codec 2.0 API, hanya saja dukungan untuk setidaknya salah satu API ini HARUS tersedia, dan dukungan untuk API yang tersedia HARUS mencakup perlindungan keamanan yang ada.

• [C-SR-1] SANGAT DISARANKAN untuk menyertakan dukungan untuk Codec 2.0 API.

Jika implementasi perangkat tidak mendukung Codec 2.0 API, maka:

• [C-2-1] HARUS menyertakan codec software OMX yang sesuai dari Android Open Source Project (jika tersedia) untuk setiap format dan jenis media (encoder atau decoder) yang didukung oleh perangkat.

• [C-2-2] Codec yang memiliki nama yang diawali dengan "OMX.google." HARUS didasarkan pada kode sumber Project Open Source Android mereka.

• [C-SR-2] SANGAT DISARANKAN agar codec software OMX berjalan dalam proses codec yang tidak memiliki akses ke driver hardware selain pemeta memori.

Jika implementasi perangkat mendukung Codec 2.0 API, maka:

• [C-3-1] HARUS menyertakan codec software Codec 2.0 yang sesuai dari Android Open Source Project (jika tersedia) untuk setiap format dan jenis media (encoder atau decoder) yang didukung oleh perangkat.

• [C-3-2] HARUS menampung codec software Codec 2.0 dalam proses codec software sebagaimana disediakan dalam Android Open Source Project agar memungkinkan pemberian akses yang lebih sempit ke codec software.

• [C-3-3] Codec yang namanya diawali dengan "c2.android." HARUS didasarkan pada kode sumber Project Open Source Android mereka.

5.1.10. Karakterisasi Codec Media

Jika penerapan perangkat mendukung codec media, maka:

• [C-1-1] HARUS menampilkan nilai yang benar dari karakterisasi codec media melalui API MediaCodecInfo.

Khususnya:

• [C-1-2] Codec dengan nama yang diawali dengan "OMX." HARUS menggunakan API OMX dan memiliki nama yang sesuai dengan pedoman penamaan OMX IL.

• [C-1-3] Codec dengan nama yang diawali dengan "c2." HARUS menggunakan Codec 2.0 API dan memiliki nama yang sesuai dengan panduan penamaan Codec 2.0 untuk Android.

• [C-1-4] Codec dengan nama yang diawali dengan "OMX.google." atau "c2.android." TIDAK BOLEH ditandai sebagai vendor atau sebagai akselerasi hardware.

• [C-1-5] Codec yang berjalan dalam proses codec (vendor atau sistem) yang memiliki akses ke driver hardware selain pengalokasi dan pemeta memori TIDAK BOLEH dikategorikan sebagai hanya software.

• [C-1-6] Codec yang tidak ada di Proyek Open Source Android atau tidak didasarkan pada kode sumber dalam project tersebut HARUS dikategorikan sebagai vendor.

• [C-1-7] Codec yang menggunakan akselerasi hardware HARUS ditandai sebagai akselerasi hardware.

• [C-1-8] Nama codec TIDAK BOLEH menyesatkan. Misalnya, codec bernama "decoder" HARUS mendukung decoding, dan codec bernama "encoder" HARUS mendukung encoding. Codec dengan nama yang berisi format media HARUS mendukung format tersebut.

Jika penerapan perangkat mendukung codec video:

• [C-2-1] Semua codec video HARUS memublikasikan data kecepatan frame yang dapat dicapai untuk ukuran berikut jika didukung oleh codec:

	SD (kualitas rendah)	SD (kualitas tinggi)	HD 720p	HD 1080p	UHD
Resolusi video	176 x 144 px (H263, MPEG2, MPEG4) 352 x 288 px (encoder MPEG4, H263, MPEG2) 320 x 180 px (VP8, VP8) 320 x 240 px (lainnya)	704 x 576 px (H263) 640 x 360 px (VP8, VP9) 640 x 480 piksel (encoder MPEG4) 720 x 480 px (lainnya, AV1)	1408 x 1152 px (H263) 1280 x 720 px (lainnya, AV1)	1920 x 1080 px (selain MPEG4, AV1)	3840 x 2160 px (HEVC, VP9, AV1)

• [C-2-2] Codec video yang dicirikan sebagai akselerasi hardware HARUS memublikasikan informasi poin performa. Setiap codec HARUS mencantumkan semua poin performa standar yang didukung (dicantumkan dalam API PerformancePoint), kecuali jika codec tersebut tercakup oleh poin performa standar lain yang didukung.

• Selain itu, mereka HARUS memublikasikan poin performa yang diperluas jika mereka mendukung performa video berkelanjutan selain salah satu performa standar yang tercantum.

5.2. Encoding Video

Jika implementasi perangkat mendukung encoder video apa pun dan menyediakannya untuk aplikasi pihak ketiga, serta menyetel
MediaFormat.KEY_BITRATE_MODE ke BITRATE_MODE_VBR agar encoder beroperasi dalam mode Kecepatan bit variabel, maka, selama tidak memengaruhi batas kualitas minimum, kecepatan bit yang dienkode :

• TIDAK BOLEH, dalam satu periode geser, lebih dari 15% di atas kecepatan bit antara interval intraframe (I-frame).
• TIDAK BOLEH lebih dari 100% di atas bitrate selama periode 1 detik.

Jika penerapan perangkat mendukung encoder video apa pun dan menyediakannya untuk aplikasi pihak ketiga serta menetapkan MediaFormat.KEY_BITRATE_MODE ke BITRATE_MODE_CBR sehingga encoder beroperasi dalam mode kecepatan bit konstan, maka kecepatan bit yang dienkode:

• [C-SR-2] SANGAT DISARANKAN agar TIDAK lebih dari 15% di atas target bitrate selama periode geser 1 detik.

Jika implementasi perangkat menyertakan tampilan layar tersemat dengan panjang diagonal minimal 2,5 inci atau menyertakan port output video atau mendeklarasikan dukungan kamera melalui tanda fitur android.hardware.camera.any, perangkat tersebut:

• [C-1-1] HARUS menyertakan dukungan setidaknya salah satu encoder video VP8 atau H.264, dan menyediakannya untuk aplikasi pihak ketiga.
• HARUS mendukung encoder video VP8 dan H.264, serta menyediakannya untuk aplikasi pihak ketiga.

Jika penerapan perangkat mendukung salah satu encoder video H.264, VP8, VP9, atau HEVC dan menyediakannya untuk aplikasi pihak ketiga, maka:

• [C-2-1] HARUS mendukung bitrate yang dapat dikonfigurasi secara dinamis.
• HARUS mendukung kecepatan frame variabel, dengan encoder video HARUS menentukan durasi frame instan berdasarkan stempel waktu buffer input, dan mengalokasikan bucket bit berdasarkan durasi frame tersebut.

Jika implementasi perangkat mendukung encoder video MPEG-4 SP dan menyediakannya untuk aplikasi pihak ketiga, maka:

• HARUS mendukung bitrate yang dapat dikonfigurasi secara dinamis untuk encoder yang didukung.

Jika implementasi perangkat menyediakan encoder video atau gambar yang dipercepat hardware, dan mendukung satu atau beberapa kamera hardware yang terpasang atau dapat dipasang yang diekspos melalui API android.camera:

• [C-4-1] semua encoder video dan gambar dengan akselerasi hardware HARUS mendukung encoding frame dari kamera hardware.
• HARUS mendukung encoding frame dari kamera hardware melalui semua encoder video atau gambar.

Jika implementasi perangkat menyediakan encoding HDR, maka:

• [C-SR-1] SANGAT DISARANKAN untuk menyediakan plugin bagi API transcoding yang lancar untuk mengonversi dari format HDR ke format SDR.

5.2.1. H.263

Jika implementasi perangkat mendukung encoder H.263 dan menyediakannya untuk aplikasi pihak ketiga, maka:

• [C-1-1] HARUS mendukung resolusi QCIF (176 x 144) menggunakan Level Profil Dasar Pengukuran 45. Resolusi SQCIF bersifat opsional.

5.2.2. H.264

Jika penerapan perangkat mendukung codec H.264, perangkat tersebut:

• [C-1-1] HARUS mendukung Profil Dasar Pengukuran Level 3. Namun, dukungan untuk ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering), dan RS (Redundant Slices) bersifat OPSIONAL. Selain itu, untuk mempertahankan kompatibilitas dengan perangkat Android lainnya, ASO, FMO, dan RS TIDAK DISARANKAN untuk digunakan pada Profil Dasar Pengukuran oleh encoder.
• [C-1-2] HARUS mendukung profil encoding video SD (Standard Definition) dalam tabel berikut.
• HARUS mendukung Profil Utama Level 4.
• HARUS mendukung profil encoding video HD (High Definition) seperti yang ditunjukkan dalam tabel berikut.

Jika penerapan perangkat melaporkan dukungan encoding H.264 untuk video beresolusi 720p atau 1080p melalui API media, maka:

• [C-2-1] HARUS mendukung profil encoding dalam tabel berikut.

	SD (Kualitas rendah)	SD (Kualitas tinggi)	HD 720p	HD 1080p
Resolusi video	320 x 240 px	720 x 480 px	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

5.2.3. VP8

Jika penerapan perangkat mendukung codec VP8, maka:

• [C-1-1] HARUS mendukung profil encoding video SD.
• HARUS mendukung profil encoding video HD (High Definition) berikut.
• [C-1-2] HARUS mendukung penulisan file WebM Matroska.
• HARUS menyediakan codec VP8 hardware yang memenuhi persyaratan coding hardware RTC project WebM, untuk memastikan kualitas layanan streaming video web dan konferensi video yang dapat diterima.

Jika penerapan perangkat melaporkan dukungan encoding VP8 untuk video beresolusi 720p atau 1080p melalui API media, maka:

• [C-2-1] HARUS mendukung profil encoding dalam tabel 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

5.2.4. VP9

Jika penerapan perangkat mendukung codec VP9, perangkat tersebut:

• [C-1-2] HARUS mendukung Profil 0 Level 3.
• [C-1-1] HARUS mendukung penulisan file WebM Matroska.
• [C-1-3] HARUS membuat data CodecPrivate.
• HARUS mendukung profil decoding HD seperti yang ditunjukkan dalam tabel berikut.
• [C-SR-1] SANGAT DISARANKAN untuk mendukung profil decoding HD seperti yang ditunjukkan dalam tabel berikut jika ada encoder hardware.

	SD	HD 720p	HD 1080p	UHD
Resolusi video	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Frekuensi gambar video	30 fps	30 fps	30 fps	30 fps
Kecepatan bit video	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

Jika implementasi perangkat mengklaim mendukung Profil 2 atau Profil 3 melalui Media API:

• Dukungan untuk format 12-bit bersifat OPSIONAL.

5.2.5. H.265

Jika penerapan perangkat mendukung codec H.265, perangkat tersebut:

• [C-1-1] HARUS mendukung Profil Utama Level 3 hingga resolusi 512 x 512.
• [C-SR-1] SANGAT DISARANKAN untuk mendukung profil SD 720 x 480 dan profil encoding HD seperti yang ditunjukkan dalam tabel berikut jika ada encoder hardware.

	SD	HD 720p	HD 1080p	UHD
Resolusi video	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Frekuensi gambar video	30 fps	30 fps	30 fps	30 fps
Kecepatan bit video	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

5.2.6. AV1

Jika implementasi perangkat mendukung codec AV1, maka:

• [C-1-1] HARUS mendukung Profil Utama termasuk konten 8-bit dan 10-bit.

• [C-1-2] HARUS memublikasikan data performa, yaitu melaporkan data performa melalui getSupportedFrameRatesFor() atau getSupportedPerformancePoints() API untuk resolusi yang didukung dalam tabel di bawah.

• [C-1-3] HARUS menerima metadata HDR dan mengirimkannya ke bitstream

Jika encoder AV1 diakselerasi dengan hardware, maka:

• [C-2-1] HARUS mendukung profil encoding hingga dan termasuk HD1080p dari tabel di bawah:

	SD	HD 720p	HD 1080p	UHD
Resolusi video	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Frekuensi gambar video	30 fps	30 fps	30 fps	30 fps
Kecepatan bit video	5 Mbps	8 Mbps	16 Mbps	50 Mbps

5.3. Dekode Video

5.3.1. MPEG-2

Jika penerapan perangkat mendukung decoder MPEG-2, maka:

• [C-1-1] HARUS mendukung Level Tinggi Profil Utama.

5.3.2. H.263

Jika penerapan perangkat mendukung decoder H.263, maka:

• [C-1-1] HARUS mendukung Profil Dasar Pengukuran Level 30 (resolusi CIF, QCIF, dan SQCIF @ 30 fps 384 kbps) dan Level 45 (resolusi QCIF dan SQCIF @ 30 fps 128 kbps).

5.3.3. MPEG-4

Jika menerapkan perangkat dengan dekoder MPEG-4, perangkat tersebut:

• [C-1-1] HARUS mendukung Simple Profile Level 3.

5.3.4. H.264

Jika penerapan perangkat mendukung decoder H.264, maka:

• [C-1-1] HARUS mendukung Profil Utama Level 3.1 dan Profil Dasar Pengukuran. Dukungan untuk ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering), dan RS (Redundant Slices) bersifat OPSIONAL.
• [C-1-2] HARUS dapat mendekode video dengan profil SD (Standard Definition) yang tercantum dalam tabel berikut dan dienkode dengan Profil Dasar dan Profil Utama Level 3.1 (termasuk 720p30).
• HARUS dapat mendekode video dengan profil HD (High Definition) seperti yang ditunjukkan dalam tabel berikut.

Jika tinggi yang dilaporkan oleh metode Display.getSupportedModes() sama dengan atau lebih besar dari resolusi video, implementasi perangkat:

• [C-2-1] HARUS mendukung profil decoding video HD 720p dalam tabel berikut.
• [C-2-2] HARUS mendukung profil decoding video HD 1080p dalam tabel berikut.

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

5.3.5. H.265 (HEVC)

Jika penerapan perangkat mendukung codec H.265, perangkat tersebut:

• [C-1-1] 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.
• [C-1-2] HARUS mendukung profil dekode HD seperti yang ditunjukkan dalam tabel berikut jika ada dekoder hardware.

Jika tinggi yang dilaporkan oleh metode Display.getSupportedModes() sama dengan atau lebih besar dari resolusi video, maka:

• [C-2-1] Penerapan perangkat HARUS mendukung decoding H.265 atau VP9 dengan profil 720, 1080, dan UHD.

	SD (Kualitas rendah)	SD (Kualitas tinggi)	HD 720p	HD 1080p	UHD
Resolusi video	352 x 288 px	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Frekuensi gambar video	30 fps	30 fps	30 fps	30/60 fps (60 fpsTelevisi dengan decoding hardware H.265)	60 fps
Kecepatan bit video	600 Kbps	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

Jika implementasi perangkat mengklaim mendukung Profil HDR melalui Media API:

• [C-3-1] Implementasi perangkat HARUS menerima metadata HDR yang diperlukan dari aplikasi, serta mendukung ekstraksi dan output metadata HDR yang diperlukan dari bitstream dan/atau penampung.
• [C-3-2] Implementasi perangkat HARUS menampilkan konten HDR dengan benar di layar perangkat atau di port output video standar (misalnya, HDMI).

5.3.6. VP8

Jika penerapan perangkat mendukung codec VP8, maka:

• [C-1-1] HARUS mendukung profil decoding SD dalam tabel berikut.
• HARUS menggunakan codec VP8 hardware yang memenuhi persyaratan.
• HARUS mendukung profil decoding HD dalam tabel berikut.

Jika tinggi yang dilaporkan oleh metode Display.getSupportedModes() sama dengan atau lebih besar dari resolusi video, maka:

• [C-2-1] Implementasi perangkat HARUS mendukung profil 720p dalam tabel berikut.
• [C-2-2] Implementasi perangkat HARUS mendukung profil 1080p dalam tabel 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 (60 fpsTelevisi)	30 (60 fpsTelevisi)
Kecepatan bit video	800 Kbps	2 Mbps	8 Mbps	20 Mbps

5.3.7. VP9

Jika penerapan perangkat mendukung codec VP9, perangkat tersebut:

• [C-1-1] HARUS mendukung profil decoding video SD seperti yang ditunjukkan dalam tabel berikut.
• HARUS mendukung profil decoding HD seperti yang ditunjukkan dalam tabel berikut.

Jika penerapan perangkat mendukung codec VP9 dan dekoder hardware:

• [C-2-1] HARUS mendukung profil dekode HD seperti yang ditunjukkan dalam tabel berikut.

Jika tinggi yang dilaporkan oleh metode Display.getSupportedModes() sama dengan atau lebih besar dari resolusi video, maka:

• [C-3-1] Penerapan perangkat HARUS mendukung decoding VP9 atau H.265 dari profil 720, 1080, dan UHD.

	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	3840 x 2160 px
Frekuensi gambar video	30 fps	30 fps	30 fps	30 fps (60 fpsTelevisi dengan dekode hardware VP9)	60 fps
Kecepatan bit video	600 Kbps	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

Jika implementasi perangkat mengklaim mendukung VP9Profile2 atau VP9Profile3 melalui API media 'CodecProfileLevel':

• Dukungan untuk format 12-bit bersifat OPSIONAL.

Jika implementasi perangkat mengklaim mendukung Profil HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) melalui API media:

• [C-4-1] Implementasi perangkat HARUS menerima metadata HDR yang diperlukan (KEY_HDR_STATIC_INFO untuk semua profil HDR, serta 'KEY_HDR10_PLUS_INFO' untuk profil HDR10Plus) dari aplikasi. Perangkat juga HARUS mendukung ekstraksi dan output metadata HDR yang diperlukan dari bitstream dan/atau container.
• [C-4-2] Implementasi perangkat HARUS menampilkan konten HDR dengan benar di layar perangkat atau di port output video standar (misalnya, HDMI).

5.3.8. Dolby Vision

Jika penerapan perangkat menyatakan dukungan untuk decoder Dolby Vision melalui HDR_TYPE_DOLBY_VISION, maka:

• [C-1-1] HARUS menyediakan ekstraktor dengan kemampuan Dolby Vision.

• [C-1-2] HARUS menampilkan konten Dolby Vision dengan benar di layar perangkat atau di layar eksternal yang terhubung melalui port output video standar (seperti HDMI).

• [C-1-3] HARUS menyetel ID trek lapisan dasar yang kompatibel mundur (jika ada) agar sama dengan ID trek lapisan Dolby Vision gabungan.

5.3.9. AV1

Jika implementasi perangkat mendukung codec AV1 dan menyediakannya untuk aplikasi pihak ketiga, maka:

• [C-1-1] HARUS mendukung Profil Utama termasuk konten 8-bit dan 10-bit.

Jika penerapan perangkat memberikan dukungan untuk codec AV1 dengan decoder yang dipercepat hardware, maka:

• [C-2-1] HARUS dapat mendekode setidaknya profil dekode video HD 720p dari tabel di bawah saat tinggi yang dilaporkan oleh metode Display.getSupportedModes() sama dengan atau lebih besar dari 720p.
• [C-2-2] HARUS dapat mendekode profil dekode video HD 1080p setidaknya dari tabel di bawah saat tinggi yang dilaporkan oleh metode Display.getSupportedModes() sama dengan atau lebih besar dari 1080p.

	SD	HD 720p	HD 1080p	UHD
Resolusi video	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Frekuensi gambar video	30 fps	30 fps	30 fps	30 fps
Kecepatan bit video	5 Mbps	8 Mbps	16 Mbps	50 Mbps

Jika implementasi perangkat mendukung Profil HDR melalui Media API, maka:

• [C-3-1] HARUS mendukung ekstraksi dan output metadata HDR dari bitstream dan/atau penampung.

• [C-3-2] HARUS menampilkan konten HDR dengan benar di layar perangkat atau di port output video standar (misalnya, HDMI).

5.4. Perekaman Audio

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

5.4.1. Pengambilan Audio Mentah dan Informasi Mikrofon

Jika implementasi perangkat mendeklarasikan android.hardware.microphone, implementasi tersebut:

• [C-1-1] HARUS mengizinkan pengambilan konten audio mentah untuk setiap aliran INPUT AudioRecord atau AAudio yang berhasil dibuka. Minimal, karakteristik berikut HARUS didukung:

  • Format: PCM Linear, 16-bit
  • Frekuensi sampling: 8.000, 11.025, 16.000, 44.100, 48.000 Hz
  • Channel: Mono
  • Sumber Audio: DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED, atau VOICE_PERFORMANCE. Hal ini juga berlaku untuk Preset Input yang setara di AAudio, misalnya, AAUDIO_INPUT_PRESET_CAMCORDER.

• HARUS mengizinkan perekaman konten audio mentah dengan karakteristik berikut:

  • Format: PCM Linear, 16-bit dan 24-bit
  • Frekuensi sampling: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 Hz
  • Saluran: Sebanyak jumlah mikrofon di perangkat

• [C-1-2] HARUS direkam pada frekuensi sampel di atas tanpa up-sampling.

• [C-1-3] HARUS menyertakan filter anti-aliasing yang sesuai saat sample rate yang diberikan di atas diambil dengan down-sampling.

• HARUS mengizinkan pengambilan konten audio mentah berkualitas radio AM dan DVD, yang berarti karakteristik berikut:

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

• [C-1-4] HARUS mematuhi API MicrophoneInfo dan mengisi informasi dengan benar untuk mikrofon yang tersedia di perangkat yang dapat diakses oleh aplikasi pihak ketiga melalui API AudioManager.getMicrophones(), untuk AudioRecord aktif menggunakan MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED, atau VOICE_PERFORMANCE. Jika implementasi perangkat memungkinkan penangkapan konten audio mentah berkualitas DVD dan radio AM, maka:

• [C-2-1] HARUS merekam tanpa up-sampling pada rasio yang lebih tinggi dari 16000:22050 atau 44100:48000.

• [C-2-2] HARUS menyertakan filter anti-aliasing yang sesuai untuk setiap peningkatan kualitas atau penurunan kualitas.

5.4.2. Perekaman untuk Pengenalan Suara

Jika implementasi perangkat mendeklarasikan android.hardware.microphone, implementasi tersebut:

• [C-1-1] HARUS merekam sumber audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION pada salah satu frekuensi sampling, 44100 dan 48000.
• [C-1-2] HARUS, secara default, menonaktifkan pemrosesan audio peredam bising saat merekam streaming audio dari sumber audio AudioSource.VOICE_RECOGNITION.

• [C-1-3] HARUS, secara default, menonaktifkan kontrol penguatan otomatis saat merekam streaming audio dari sumber audio AudioSource.VOICE_RECOGNITION.

• HARUS menunjukkan karakteristik amplitudo versus frekuensi yang kira-kira datar dalam rentang frekuensi tengah: khususnya ±3dB dari 100 Hz hingga 4000 Hz untuk setiap mikrofon yang digunakan untuk merekam sumber audio pengenalan suara.

• [C-SR-1] SANGAT DISARANKAN untuk menunjukkan tingkat amplitudo dalam rentang frekuensi rendah: khususnya dari ±20 dB dari 30 Hz hingga 100 Hz dibandingkan dengan rentang frekuensi menengah untuk setiap mikrofon yang digunakan untuk merekam sumber audio pengenalan suara.

• [C-SR-2] SANGAT DISARANKAN untuk menunjukkan tingkat amplitudo dalam rentang frekuensi tinggi: khususnya dari ±30 dB dari 4000 Hz hingga 22 KHz dibandingkan dengan rentang frekuensi menengah untuk setiap mikrofon yang digunakan untuk merekam sumber audio pengenalan suara.

• HARUS menyetel sensitivitas input audio sehingga sumber nada sinusoidal 1000 Hz yang diputar pada Tingkat Tekanan Suara (SPL) 90 dB (diukur di samping mikrofon) menghasilkan respons RMS 2500 yang ideal dalam rentang 1770 dan 3530 untuk sampel 16 bit (atau -22,35 dB ±3 dB Skala Penuh untuk sampel floating point/presisi ganda) untuk setiap mikrofon yang digunakan untuk merekam sumber audio pengenalan suara.

• HARUS merekam aliran audio pengenalan suara sehingga tingkat amplitudo PCM melacak perubahan SPL input secara linear dalam rentang setidaknya 30 dB dari -18 dB hingga +12 dB re 90 dB SPL di mikrofon.

• HARUS merekam aliran audio pengenalan suara dengan total distorsi harmonik (THD) kurang dari 1% untuk 1 kHz pada tingkat input SPL 90 dB di mikrofon.

Jika implementasi perangkat mendeklarasikan teknologi android.hardware.microphone dan peredam (pengurangan) bising yang disesuaikan untuk pengenalan ucapan, maka:

• [C-2-1] HARUS mengizinkan efek audio ini dikontrol dengan API android.media.audiofx.NoiseSuppressor.
• [C-2-2] HARUS mengidentifikasi setiap penerapan teknologi peredam bising secara unik melalui kolom AudioEffect.Descriptor.uuid.

5.4.3. Perekaman untuk Pengalihan Pemutaran

Class android.media.MediaRecorder.AudioSource mencakup sumber audio REMOTE_SUBMIX.

Jika implementasi perangkat mendeklarasikan android.hardware.audio.output dan android.hardware.microphone, perangkat tersebut:

• [C-1-1] HARUS menerapkan sumber audio REMOTE_SUBMIX dengan benar sehingga saat aplikasi menggunakan android.media.AudioRecord API untuk merekam dari sumber audio ini, aplikasi akan merekam campuran semua aliran audio kecuali yang berikut:

  • AudioManager.STREAM_RING
  • AudioManager.STREAM_ALARM
  • AudioManager.STREAM_NOTIFICATION

5.4.4. Peredam Gema Akustik

Jika implementasi perangkat mendeklarasikan android.hardware.microphone, implementasi tersebut:

• HARUS menerapkan teknologi Acoustic Echo Canceler (AEC) yang disesuaikan untuk komunikasi suara dan diterapkan ke jalur pengambilan saat merekam menggunakan AudioSource.VOICE_COMMUNICATION.

5.4.5. Perekaman Serentak

Jika implementasi perangkat mendeklarasikan android.hardware.microphone, implementasi tersebut HARUS menerapkan pengambilan serentak seperti yang dijelaskan dalam dokumen ini. Khususnya:

• [C-1-1] HARUS mengizinkan akses serentak ke mikrofon oleh layanan aksesibilitas yang merekam dengan AudioSource.VOICE_RECOGNITION dan setidaknya satu aplikasi yang merekam dengan AudioSource apa pun.
• [C-1-2] HARUS mengizinkan akses mikrofon secara bersamaan oleh aplikasi bawaan yang memiliki peran Asisten dan setidaknya satu aplikasi yang merekam dengan AudioSource apa pun kecuali AudioSource.VOICE_COMMUNICATION atau AudioSource.CAMCORDER.
• [C-1-3] HARUS membisukan perekaman audio untuk aplikasi lain, kecuali untuk layanan aksesibilitas, saat aplikasi merekam dengan AudioSource.VOICE_COMMUNICATION atau AudioSource.CAMCORDER. Namun, saat aplikasi merekam melalui AudioSource.VOICE_COMMUNICATION, aplikasi lain dapat merekam panggilan suara jika merupakan aplikasi istimewa (bawaan) dengan izin CAPTURE_AUDIO_OUTPUT.

• [C-1-4] Jika dua atau lebih aplikasi merekam secara bersamaan dan jika tidak ada aplikasi yang memiliki UI di atas, aplikasi yang memulai perekaman paling baru akan menerima audio.

5.5. Pemutaran Audio

Android menyertakan dukungan untuk mengizinkan aplikasi memutar audio melalui periferal output audio seperti yang ditentukan dalam bagian 7.8.2.

5.5.1. Pemutaran Audio Mentah

Jika implementasi perangkat mendeklarasikan android.hardware.audio.output, implementasi tersebut:

• [C-1-1] HARUS mengizinkan pemutaran konten audio mentah dengan karakteristik berikut:

  • Format sumber: PCM Linear, 16-bit, 8-bit, float
  • Saluran: Mono, Stereo, konfigurasi multisaluran yang valid dengan hingga 8 saluran
  • Frekuensi pengambilan sampel (dalam Hz):
    • 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 pada konfigurasi saluran yang tercantum di atas
    • 96000 dalam mono dan stereo

5.5.2. Efek Audio

Android menyediakan API untuk efek audio untuk penerapan perangkat.

Jika implementasi perangkat mendeklarasikan fitur android.hardware.audio.output, maka:

• [C-1-1] HARUS mendukung implementasi EFFECT_TYPE_EQUALIZER dan EFFECT_TYPE_LOUDNESS_ENHANCER yang dapat dikontrol melalui subclass AudioEffect Equalizer dan LoudnessEnhancer.

• [C-1-2] HARUS mendukung penerapan Visualizer API, yang dapat dikontrol melalui class Visualizer.

• [C-1-3] HARUS mendukung penerapan EFFECT_TYPE_DYNAMICS_PROCESSING yang dapat dikontrol melalui subkelas AudioEffect DynamicsProcessing.

• [C-1-4] HARUS mendukung efek audio dengan input dan output floating point, saat hasil efek ditampilkan ke pipeline audio framework. Bagian ini mengacu pada efek insert atau aux standar seperti equalizer. Perilaku yang setara sangat direkomendasikan saat hasil efek tidak terlihat oleh pipeline audio framework, seperti efek pasca-pemrosesan atau yang di-offload.

• [C-1-5] HARUS memastikan bahwa efek audio mendukung beberapa saluran hingga jumlah saluran mixer yang juga dikenal sebagai FCC_LIMIT, saat hasil efek dikembalikan ke pipeline audio framework. Hal ini mengacu pada efek sisipan atau aux yang umum, tetapi tidak termasuk efek khusus seperti downmix, upmix, atau efek spasialisasi yang mengubah jumlah saluran. Perilaku yang setara direkomendasikan saat efek tidak terlihat oleh pipeline audio framework, seperti efek pasca-pemrosesan atau yang di-offload.

• HARUS mendukung implementasi EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB, dan EFFECT_TYPE_VIRTUALIZER yang dapat dikontrol melalui subclass AudioEffect BassBoost, EnvironmentalReverb, PresetReverb, dan Virtualizer.

• [C-SR-1] SANGAT DISARANKAN untuk mendukung efek dalam floating-point dan multisaluran.

5.5.3. Volume Output Audio

Implementasi perangkat otomotif:

• HARUS mengizinkan penyesuaian volume audio secara terpisah untuk setiap streaming audio menggunakan jenis konten atau penggunaan seperti yang ditentukan oleh AudioAttributes dan penggunaan audio mobil seperti yang ditentukan secara publik di android.car.CarAudioManager.

5.5.4. Pengurangan Beban Audio

Jika implementasi perangkat mendukung pemutaran offload audio, maka:

• [C-SR-1] SANGAT DISARANKAN untuk memangkas konten audio gapless yang diputar di antara dua klip dengan format yang sama jika ditentukan oleh API gapless AudioTrack dan penampung media untuk MediaPlayer.

• [C-SR-2] SANGAT DISARANKAN untuk menerapkan pemutaran yang di-offload untuk format AAC, MP3, OPUS, dan PCM.

5.5.5. Parameter Pemutaran

5.6. Latensi Audio

Latensi audio adalah penundaan waktu saat sinyal audio melewati sistem. Banyak class aplikasi 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 yang dikodekan PCM dan saat suara yang sesuai ditampilkan ke lingkungan pada transduser di perangkat atau sinyal meninggalkan perangkat melalui port dan dapat diamati secara eksternal.

• latensi output dingin. Waktu antara memulai aliran output dan waktu presentasi frame pertama berdasarkan stempel waktu, saat sistem output audio telah tidak aktif dan dimatikan sebelum permintaan.

• latensi output berkelanjutan. Latensi output untuk frame berikutnya, setelah perangkat memutar audio.

• latensi input. Interval antara saat suara disajikan oleh lingkungan ke perangkat di transduser dalam perangkat atau sinyal memasuki perangkat melalui port dan saat aplikasi membaca frame data yang dikodekan PCM yang sesuai.

• input yang hilang. Bagian awal sinyal input yang tidak dapat digunakan atau tidak tersedia.

• latensi input dingin. Waktu antara memulai streaming dan saat frame valid pertama diterima, saat sistem input audio telah tidak aktif dan dimatikan sebelum permintaan.

• latensi input berkelanjutan. Latensi input untuk frame berikutnya, saat perangkat merekam audio.

• latensi bolak-balik berkelanjutan. Jumlah latensi input berkelanjutan ditambah latensi output berkelanjutan ditambah satu periode buffer. Periode buffer memungkinkan waktu bagi aplikasi untuk memproses sinyal dan waktu bagi aplikasi untuk mengurangi perbedaan fase antara aliran input dan output.

• OpenSL ES PCM buffer queue API. Kumpulan API OpenSL ES terkait PCM dalam Android NDK.

• AAudio native audio API. Kumpulan AAudio API dalam Android NDK.

• Timestamp. Pasangan yang terdiri dari posisi frame relatif dalam streaming dan perkiraan waktu saat frame tersebut masuk atau keluar dari pipeline pemrosesan audio di endpoint terkait. Lihat juga AudioTimestamp.

• glitch. Gangguan sementara atau nilai sampel yang salah dalam sinyal audio, biasanya disebabkan oleh buffer underrun untuk output, buffer overrun untuk input, atau sumber noise digital atau analog lainnya.

• simpangan mutlak rata-rata (MAD). Rata-rata nilai absolut dari simpangan dari nilai rata-rata untuk sekumpulan nilai.

• Latensi ketuk-ke-nada (TTL), sebagaimana diukur oleh CTS Verifier, adalah waktu antara saat layar diketuk dan saat nada yang dihasilkan sebagai akibat dari ketukan tersebut terdengar di speaker. Latensi ini dirata-ratakan selama 5 pengukuran menggunakan AAudio Native Audio API untuk output.

• latensi pulang pergi (RTL), sebagaimana diukur oleh CTS Verifier, adalah latensi Berkelanjutan Rata-Rata selama 5 pengukuran, yang diukur melalui jalur loopback yang mengembalikan output ke input, menggunakan AAudio native audio API.

  Jalur loopback adalah:

  • Speaker/mikrofon: Speaker bawaan ke mikrofon bawaan.
  • Analog: Colokan analog 3,5 mm dan adaptor loopback.
  • USB: Adaptor USB ke 3,5 mm dan adaptor loopback atau antarmuka audio USB dan kabel loopback.

• FEATURE_AUDIO_LOW_LATENCY. Fitur android.hardware.audio.low_latency dideklarasikan.

• FEATURE_AUDIO_PRO. Fitur android.hardware.audio.pro dideklarasikan.

• MPC. Class Performa Media.

• latensi pelacakan kepala. Waktu yang diperlukan dari gerakan kepala yang direkam oleh unit pengukuran inersia (IMU) hingga deteksi perubahan suara yang disebabkan oleh gerakan ini oleh transduser headphone.

Jika implementasi perangkat mendeklarasikan android.hardware.audio.output, implementasi tersebut HARUS memenuhi atau melampaui persyaratan berikut:

• [C-1-1] Persyaratan dihapus di Android 15.

• [C-1-2] Latensi output dingin 500 milidetik atau kurang.

• [C-1-3] Membuka aliran output menggunakan AAudioStreamBuilder_openStream() HARUS memerlukan waktu kurang dari 1.000 milidetik.

• [C-1-4] Latensi bolak-balik yang dihitung berdasarkan stempel waktu input dan output yang ditampilkan oleh AAudioStream_getTimestamp HARUS berada dalam 200 md dari latensi bolak-balik yang diukur untuk AAUDIO_PERFORMANCE_MODE_NONE dan AAUDIO_PERFORMANCE_MODE_LOW_LATENCY untuk speaker, headset berkabel, dan headset nirkabel.

• [C-SR-1] Persyaratan dihapus di Android 15.

• [C-SR-2] Persyaratan dihapus di Android 15.

• [C-SR-4] Persyaratan dihapus di Android 15.

• [C-SR-5] Persyaratan dihapus di Android 15.

• [C-SR-6] Persyaratan dihapus di Android 15.

• [C-SR-7] Persyaratan dihapus di Android 15.

• [C-2-1] Persyaratan dihapus di Android 15.

Jika implementasi perangkat mencakup android.hardware.microphone, perangkat tersebut HARUS memenuhi persyaratan audio input berikut:

• [C-3-1] Persyaratan dihapus di Android 15.

• [C-3-2] Latensi input dingin 500 milidetik atau kurang.

• [C-3-3] Membuka aliran input menggunakan AAudioStreamBuilder_openStream() HARUS memerlukan waktu kurang dari 1000 milidetik.

• [C-SR-8] Persyaratan dihapus di Android 15.

• [C-SR-11] Persyaratan dihapus di Android 15.

• [C-SR-12] Persyaratan dihapus di Android 15.

Tabel berikut menentukan persyaratan RTL untuk penerapan perangkat Genggam seperti yang ditentukan dalam 2.2.1 yang mendeklarasikan android.hardware.audio.output dan android.hardware.microphone.

Tabel berikut menentukan persyaratan untuk TTL untuk penerapan perangkat Genggam sebagaimana ditentukan dalam 2.2.1 yang mendeklarasikan android.hardware.audio.output dan android.hardware.microphone.

Jika implementasi perangkat menyertakan dukungan untuk spatial audio dengan pelacakan kepala dan mendeklarasikan tanda PackageManager.FEATURE_AUDIO_SPATIAL_HEADTRACKING_LOW_LATENCY, maka:

• [C-4-1] HARUS menunjukkan latensi maksimum pelacakan kepala ke pembaruan audio sebesar 300 md.

5.7. Protokol Jaringan

Implementasi perangkat HARUS mendukung protokol jaringan media untuk pemutaran audio dan video seperti yang ditentukan dalam dokumentasi Android SDK.

Untuk setiap codec dan format penampung yang harus didukung oleh penerapan perangkat, penerapan perangkat:

• [C-1-1] HARUS mendukung codec atau container tersebut melalui HTTP dan HTTPS.

• [C-1-2] HARUS mendukung format segmen media yang sesuai seperti yang ditunjukkan dalam tabel format segmen media di bawah melalui draf protokol HTTP Live Streaming, Versi 7.

• [C-1-3] HARUS mendukung format payload RTSP yang sesuai seperti yang ditunjukkan dalam tabel RTSP di bawah. Untuk pengecualian, lihat catatan kaki tabel di pasal 5.1.

Format Segmen Media

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

RTSP (RTP, SDP)

Nama profil	Referensi	Dukungan codec yang diperlukan
H264 AVC	RFC 6184	Lihat bagian 5.1.8 untuk mengetahui detail tentang H264 AVC
MP4A-LATM	RFC 6416	Lihat bagian 5.1.3 untuk mengetahui detail tentang AAC dan variannya
H263-1998	RFC 3551 RFC 4629 RFC 2190	Lihat bagian 5.1.8 untuk mengetahui detail tentang H263
H263-2000	RFC 4629	Lihat bagian 5.1.8 untuk mengetahui detail tentang H263
AMR	RFC 4867	Lihat bagian 5.1.3 untuk mengetahui detail tentang AMR-NB
AMR-WB	RFC 4867	Lihat bagian 5.1.3 untuk mengetahui detail tentang AMR-WB
MP4V-ES	RFC 6416	Lihat bagian 5.1.8 untuk mengetahui detail tentang MPEG-4 SP
mpeg4-generic	RFC 3640	Lihat bagian 5.1.3 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 Aman

Jika implementasi perangkat mendukung output video aman dan dapat mendukung permukaan aman, maka:

• [C-1-1] HARUS mendeklarasikan dukungan untuk Display.FLAG_SECURE.

Jika implementasi perangkat menyatakan dukungan untuk Display.FLAG_SECURE dan mendukung protokol tampilan nirkabel, maka:

• [C-2-1] HARUS mengamankan link dengan mekanisme kriptografi yang kuat seperti HDCP 2.x atau yang lebih tinggi untuk layar yang terhubung melalui protokol nirkabel seperti Miracast.

Jika implementasi perangkat menyatakan dukungan untuk Display.FLAG_SECURE dan mendukung tampilan eksternal berkabel, perangkat tersebut:

• [C-3-1] HARUS mendukung HDCP 1.2 atau yang lebih tinggi untuk semua tampilan eksternal yang terhubung melalui port berkabel yang dapat diakses pengguna.

5.9. Musical Instrument Digital Interface (MIDI)

Jika implementasi perangkat melaporkan dukungan untuk fitur android.software.midi melalui class android.content.pm.PackageManager, perangkat tersebut:

• [C-1-1] HARUS mendukung MIDI melalui semua transmisi hardware yang kompatibel dengan MIDI yang menyediakan konektivitas non-MIDI generik, dengan transmisi tersebut adalah:

  • Mode host USB, bagian 7.7
  • MIDI melalui Bluetooth LE yang berperan sebagai pusat, bagian 7.4.3

• [C-1-2] HARUS mendukung transport software MIDI antar-aplikasi (perangkat MIDI virtual)

• [C-1-3] HARUS menyertakan libamidi.so (dukungan MIDI native)

• HARUS mendukung mode periferal MIDI melalui USB, bagian 7.7

5.10. Audio Profesional

Jika implementasi perangkat melaporkan dukungan untuk fitur android.hardware.audio.pro melalui class android.content.pm.PackageManager, perangkat tersebut:

• [C-1-1] HARUS melaporkan dukungan untuk fitur android.hardware.audio.low_latency.

• [C-1-2] HARUS memenuhi persyaratan latensi untuk FEATURE_AUDIO_PRO sebagaimana ditentukan dalam bagian 5.6 Latensi Audio .

• [C-1-3] HARUS menyertakan port USB yang mendukung mode host USB dan mode periferal USB.

• [C-1-4] HARUS melaporkan dukungan untuk fitur android.software.midi.

• [C-1-5] HARUS memenuhi persyaratan latensi audio USB menggunakan AAudio native audio API dan AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.

• [C-1-6] HARUS memiliki latensi output Dingin 200 milidetik atau kurang.

• [C-1-7] HARUS memiliki Latensi input dingin 200 milidetik atau kurang.

Jika implementasi perangkat mencakup colokan audio 3,5 mm 4 konduktor, maka:

• [C-2-2] HARUS mematuhi bagian Spesifikasi perangkat seluler (jack) dari Spesifikasi Headset Audio Berkabel (v1.1).

Jika implementasi perangkat tidak menyertakan jack audio 3,5 mm 4 konduktor dan menyertakan port USB yang mendukung mode host USB, maka:

• [C-3-1] HARUS menerapkan class audio USB.

5.11. Pengambilan untuk Belum Diproses

Android menyertakan dukungan untuk merekam audio yang tidak diproses melalui sumber audio android.media.MediaRecorder.AudioSource.UNPROCESSED. Di OpenSL ES, mikrofon dapat diakses dengan preset rekaman SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

Jika penerapan perangkat bermaksud mendukung sumber audio yang tidak diproses dan menyediakannya untuk aplikasi pihak ketiga, perangkat tersebut:

• [C-1-1] HARUS melaporkan dukungan melalui properti android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.

• [C-1-2] HARUS menunjukkan karakteristik amplitudo versus frekuensi yang kira-kira datar dalam rentang frekuensi tengah: khususnya ±10 dB dari 100 Hz hingga 7000 Hz untuk setiap mikrofon yang digunakan untuk merekam sumber audio yang tidak diproses.

• [C-1-3] HARUS menunjukkan tingkat amplitudo dalam rentang frekuensi rendah: khususnya dari ±20 dB dari 5 Hz hingga 100 Hz dibandingkan dengan rentang frekuensi menengah untuk setiap mikrofon yang digunakan untuk merekam sumber audio yang tidak diproses.

• [C-1-4] HARUS menunjukkan tingkat amplitudo dalam rentang frekuensi tinggi: khususnya dari ±30 dB dari 7.000 Hz hingga 22 KHz dibandingkan dengan rentang frekuensi menengah untuk setiap mikrofon yang digunakan untuk merekam sumber audio yang tidak diproses.

• [C-1-5] HARUS menyetel sensitivitas input audio sehingga sumber nada sinusoidal 1000 Hz yang diputar pada Tingkat Tekanan Suara (SPL) 94 dB menghasilkan respons dengan RMS 520 untuk sampel 16 bit (atau -36 dB Skala Penuh untuk sampel presisi floating point/ganda) untuk setiap mikrofon yang digunakan untuk merekam sumber audio yang tidak diproses.

• [C-1-6] HARUS memiliki rasio signal-to-noise (SNR) sebesar 60 dB atau lebih tinggi untuk setiap mikrofon yang digunakan untuk merekam sumber audio yang tidak diproses. (sedangkan SNR diukur sebagai perbedaan antara 94 dB SPL dan SPL setara dari derau sendiri, yang diberi bobot A).

• [C-1-7] HARUS memiliki total distorsi harmonik (THD) kurang dari 1% untuk 1 kHz pada tingkat input SPL 90 dB di setiap mikrofon yang digunakan untuk merekam sumber audio yang tidak diproses.

• [C-1-8] TIDAK BOLEH memiliki pemrosesan sinyal lain (misalnya, Kontrol Penguatan Otomatis, Filter Lolos Tinggi, atau Pembatalan gema) di jalur selain pengganda level untuk membawa level ke rentang yang diinginkan. Dengan kata lain:

  • [C-1-9] Jika pemrosesan sinyal ada dalam arsitektur karena alasan apa pun, pemrosesan sinyal tersebut HARUS dinonaktifkan dan secara efektif tidak menimbulkan penundaan atau latensi tambahan pada jalur sinyal.
  • [C-1-10] Pengali level, meskipun diizinkan berada di jalur, TIDAK BOLEH memperkenalkan penundaan atau latensi pada jalur sinyal.

Semua pengukuran SPL dilakukan langsung di samping mikrofon yang sedang diuji. Untuk beberapa konfigurasi mikrofon, persyaratan ini berlaku untuk setiap mikrofon.

Jika implementasi perangkat mendeklarasikan android.hardware.microphone tetapi tidak mendukung sumber audio yang tidak diproses, maka:

• [C-2-1] HARUS menampilkan null untuk metode API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) guna menunjukkan dengan benar kurangnya dukungan.

• [C-SR-1] masih SANGAT DISARANKAN untuk memenuhi sebanyak mungkin persyaratan untuk jalur sinyal sumber rekaman yang belum diproses.

5.12. Video HDR

Android 13 mendukung teknologi HDR seperti yang dijelaskan dalam dokumen mendatang.

Format Piksel

Jika decoder video mengiklankan dukungan untuk COLOR_FormatYUVP010, maka:

• [C-1-1] HARUS mendukung format P010 untuk bacaan CPU (ImageReader, MediaImage, ByteBuffer). Di Android 13, P010 dilonggarkan untuk memungkinkan langkah arbitrer untuk bidang Y dan UV.

• [C-1-2] Buffer output P010 HARUS dapat diambil sampelnya oleh GPU (saat dialokasikan dengan penggunaan GPU_SAMPLING). Hal ini memungkinkan komposisi GPU dan pemetaan nada kustom oleh aplikasi.

Jika mendekode video mengiklankan dukungan untuk COLOR_Format32bitABGR2101010, maka:

• [C-2-1] HARUS mendukung format RGBA_1010102 untuk output permukaan dan output yang dapat dibaca CPU (output ByteBuffer).

Jika encoder video mengiklankan dukungan untuk COLOR_FormatYUVP010, maka:

• [C-3-1] HARUS mendukung format P010 untuk input permukaan dan input yang dapat ditulis CPU (ImageWriter, MediaImage, ByteBuffer).

Jika encoder video mengiklankan dukungan untuk COLOR_Format32bitABGR2101010, maka:

• [C-4-1] HARUS mendukung format RGBA_1010102 untuk input permukaan dan input yang dapat ditulis CPU (ImageWriter, ByteBuffer). Catatan: Konversi antara berbagai kurva transfer TIDAK diperlukan untuk encoder.

Persyaratan Perekaman HDR

Untuk semua encoder video yang mendukung profil HDR, penerapan perangkat:

• [C-5-1] TIDAK BOLEH mengasumsikan bahwa metadata HDR akurat. Misalnya, frame yang dienkode dapat memiliki piksel di luar tingkat luminans puncak, atau histogram mungkin tidak mewakili frame.

• HARUS menggabungkan metadata dinamis HDR untuk menghasilkan metadata statis HDR yang sesuai untuk streaming yang dienkode, dan harus menayangkannya di akhir setiap sesi encoding.

Jika implementasi perangkat mendukung perekaman HDR menggunakan CamcorderProfile API, maka:

• [C-6-1] HARUS mendukung pengambilan gambar HDR melalui Camera2 API juga.

• [C-6-2] HARUS mendukung minimal satu encoder video yang diakselerasi hardware untuk setiap teknologi HDR yang didukung.

• [C-6-3] HARUS mendukung (setidaknya) pengambilan gambar HLG.

• [C-6-4] HARUS mendukung penulisan metadata HDR (jika berlaku untuk teknologi HDR) ke dalam file video yang direkam. Untuk AV1, HEVC, dan DolbyVision, hal ini berarti menyertakan metadata ke dalam bitstream yang dienkode.

• [C-6-5] HARUS mendukung P010 dan COLOR_FormatYUVP010.

• [C-6-6] HARUS mendukung pemetaan tone HDR ke SDR di decoder default dengan akselerasi hardware untuk profil yang direkam. Dengan kata lain, jika perangkat dapat merekam HEVC HDR10+, decoder HEVC default HARUS dapat mendekodekan streaming yang direkam dalam SDR.

Persyaratan Pengeditan HDR

Jika penerapan perangkat mencakup encoder video yang mendukung pengeditan HDR, maka:

• HARUS menggunakan latensi minimal untuk membuat metadata HDR jika tidak ada, dan HARUS menangani situasi dengan baik saat metadata ada untuk beberapa frame dan tidak ada untuk frame lainnya. Metadata ini HARUS akurat (misalnya, merepresentasikan histogram dan luminans puncak aktual frame).

Jika implementasi perangkat mencakup codec yang mendukung FEATURE_HdrEditing, maka codec tersebut:

• [C-7-1] HARUS mendukung setidaknya satu profil HDR.

• [C-7-2] HARUS mendukung FEATURE_HdrEditing untuk semua profil HDR yang diiklankan oleh codec tersebut. Dengan kata lain, codec tersebut HARUS mendukung pembuatan metadata HDR jika tidak ada untuk semua profil HDR yang didukung yang menggunakan metadata HDR.

• [C-7-3] HARUS mendukung format input encoder video berikut yang sepenuhnya mempertahankan sinyal yang didekode HDR:

  • RGBA_1010102 (sudah ada di kurva transfer target) untuk input surface dan ByteBuffer serta HARUS mengiklankan dukungan untuk COLOR_Format32bitABGR2101010.

Jika implementasi perangkat mencakup codec yang mendukung FEATURE_HdrEditing, maka perangkat:

• [C-7-4] HARUS mengiklankan dukungan untuk ekstensi OpenGL EXT_YUV_target.

Persyaratan Layar HDR

Jika implementasi perangkat menerima konten buffer yang dienkode dengan ADATASPACE_TRANSFER_HLG, dan konten tersebut dikirim ke layar melalui SurfaceControl.Transaction#setBuffer, maka:

• [C-8-1] HARUS mengikuti rekomendasi putih grafis dalam BT. 2408-7, dan hanya menampilkan konten tersebut agar paling banyak lebih besar 4,926 kali lipat dari konten SDR.

6. Kompatibilitas Alat dan Opsi Developer

6.1. Developer Tools

Implementasi perangkat:

• [C-0-1] HARUS mendukung Alat Developer Android yang disediakan di Android SDK.

• Android Debug Bridge (adb)

• [C-0-2] HARUS mendukung adb seperti yang didokumentasikan dalam Android SDK dan perintah shell yang disediakan di AOSP, yang dapat digunakan oleh developer aplikasi, termasuk dumpsys, cmd stats, dan Simpleperf.

• [C-0-11] HARUS mendukung perintah shell cmd testharness. Mengupgrade implementasi perangkat dari versi Android sebelumnya tanpa blok data persisten MUNGKIN dikecualikan dari C-0-11.

• [C-0-3] TIDAK BOLEH mengubah format atau konten peristiwa sistem perangkat (batterystats, diskstats, fingerprint, graphicsstats, netstats, notification, procstats) yang dicatat melalui perintah dumpsys.

• [C-0-10] HARUS merekam, tanpa menghilangkan, dan membuat peristiwa berikut dapat diakses dan tersedia untuk perintah shell cmd stats dan class System API StatsManager.

  • ActivityForegroundStateChanged
  • AnomalyDetected
  • AppBreadcrumbReported
  • AppCrashOccurred
  • AppStartOccurred
  • BatteryLevelChanged
  • BatterySaverModeStateChanged
  • BleScanResultReceived
  • BleScanStateChanged
  • ChargingStateChanged
  • DeviceIdleModeStateChanged
  • ForegroundServiceStateChanged
  • GpsScanStateChanged
  • InputDeviceUsageReported
  • JobStateChanged
  • KeyboardConfigured
  • KeyboardSystemsEventReported
  • PluggedStateChanged
  • PressureStallInformation
  • ScheduledJobStateChanged
  • ScreenStateChanged
  • SyncStateChanged
  • SystemElapsedRealtime
  • TouchpadUsage
  • UidProcessStateChanged
  • WakelockStateChanged
  • WakeupAlarmOccurred
  • WifiLockStateChanged
  • WifiMulticastLockStateChanged
  • WifiScanStateChanged

• [C-0-4] HARUS membuat daemon adb sisi perangkat tidak aktif secara default dan HARUS ada mekanisme yang dapat diakses pengguna untuk mengaktifkan Android Debug Bridge.

• [C-0-5] HARUS mendukung adb yang aman. Android menyertakan dukungan untuk adb yang aman. Adb aman mengaktifkan adb di host yang diautentikasi dan dikenal.

• [C-0-6] HARUS menyediakan mekanisme yang memungkinkan adb terhubung dari komputer host. Khususnya:

Jika penerapan perangkat tanpa port USB mendukung mode periferal, perangkat tersebut:

• [C-3-1] HARUS menerapkan adb melalui jaringan area lokal (seperti Ethernet atau Wi-Fi).

• [C-3-2] HARUS menyediakan driver untuk Windows 7, 8, dan 10, yang memungkinkan developer terhubung ke perangkat menggunakan protokol adb.

Jika implementasi perangkat mendukung koneksi adb ke mesin host melalui Wi-Fi atau Ethernet, maka:

• [C-4-1] HARUS membuat metode AdbManager#isAdbWifiSupported() menampilkan true.

Jika implementasi perangkat mendukung koneksi adb ke mesin host melalui Wi-Fi atau Ethernet, dan menyertakan setidaknya satu kamera, maka:

• [C-5-1] HARUS membuat metode AdbManager#isAdbWifiQrSupported() menampilkan true.

• Dalvik Debug Monitor Service (ddms)

  • [C-0-7] 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.

• SysTrace

  • [C-0-9] HARUS mendukung alat systrace seperti yang didokumentasikan dalam Android SDK. Systrace harus tidak aktif secara default dan HARUS ada mekanisme yang dapat diakses pengguna untuk mengaktifkan Systrace.

• Perfetto

  • [C-SR-1] SANGAT DISARANKAN untuk mengekspos biner /system/bin/perfetto ke pengguna shell yang cmdlinenya sesuai dengan dokumentasi perfetto.

  • [C-SR-2] Biner perfetto SANGAT DISARANKAN untuk menerima sebagai input konfigurasi protobuf yang mematuhi skema yang ditentukan dalam dokumentasi perfetto.

  • [C-SR-3] Biner Perfetto SANGAT DISARANKAN untuk menulis sebagai output rekaman aktivitas protobuf yang mematuhi skema yang ditentukan dalam dokumentasi Perfetto.

  • [C-SR-4] SANGAT DISARANKAN untuk menyediakan, melalui biner perfetto, setidaknya sumber data yang dijelaskan dalam dokumentasi perfetto.

• Low Memory Killer

  • [C-0-12] HARUS menulis LMK_KILL_OCCURRED_FIELD_NUMBER Atom ke log statsd saat aplikasi dihentikan oleh Low Memory Killer.

• Mode Test Harness

  Jika implementasi perangkat mendukung perintah shell cmd testharness dan menjalankan cmd testharness enable, maka:

  • [C-2-1] HARUS menampilkan true untuk ActivityManager.isRunningInUserTestHarness()

  • [C-2-2] HARUS menerapkan Mode Tes Otomatis seperti yang dijelaskan dalam dokumentasi Mode Tes Otomatis.

• Informasi tugas GPU

  Implementasi perangkat:

  • [C-0-13] HARUS menerapkan perintah shell dumpsys gpu --gpuwork untuk menampilkan data kerja GPU gabungan yang ditampilkan oleh titik rekaman aktivitas kernel power/gpu_work_period, atau tidak menampilkan data jika titik rekaman aktivitas tidak didukung. Implementasi AOSP adalah frameworks/native/services/gpuservice/gpuwork/.

Jika implementasi perangkat melaporkan dukungan Vulkan 1.0 atau yang lebih tinggi melalui tanda fitur android.hardware.vulkan.version, maka:

• [C-1-1] HARUS menyediakan kemampuan bagi developer aplikasi untuk mengaktifkan/menonaktifkan lapisan debug GPU.

• [C-1-2] HARUS, saat lapisan debug GPU diaktifkan, mencantumkan lapisan di library yang disediakan oleh alat eksternal (yaitu, bukan bagian dari platform atau paket aplikasi) yang ditemukan di direktori dasar aplikasi yang dapat di-debug untuk mendukung metode API vkEnumerateInstanceLayerProperties() dan vkCreateInstance().

6.2. Opsi Developer

Android menyertakan dukungan bagi developer untuk mengonfigurasi setelan terkait pengembangan aplikasi.

Implementasi perangkat HARUS memberikan pengalaman yang konsisten untuk Opsi Developer, yaitu:

• [C-0-1] 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 item menu Setelan > Tentang Perangkat > Nomor Versi.
• [C-0-2] HARUS menyembunyikan Opsi Developer secara default.
• [C-0-3] HARUS menyediakan mekanisme yang jelas yang tidak memberikan perlakuan istimewa pada satu aplikasi pihak ketiga dibandingkan dengan aplikasi pihak ketiga lainnya untuk mengaktifkan Opsi Developer. HARUS memberikan dokumen atau situs yang dapat dilihat publik yang menjelaskan cara mengaktifkan Opsi Developer. Dokumen atau situs ini HARUS dapat ditautkan dari dokumen Android SDK.
• HARUS memiliki notifikasi visual berkelanjutan kepada pengguna saat Opsi Developer diaktifkan dan keselamatan pengguna menjadi perhatian.
• MAY dapat membatasi akses ke menu Opsi Developer untuk sementara, dengan menyembunyikan atau menonaktifkan menu secara visual, untuk mencegah gangguan dalam skenario yang mengkhawatirkan keselamatan pengguna.

7. Kompatibilitas Hardware

Jika perangkat menyertakan komponen hardware tertentu yang memiliki API terkait untuk developer pihak ketiga:

• [C-0-1] Implementasi perangkat HARUS menerapkan 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:

• [C-0-2] Definisi class lengkap (seperti yang didokumentasikan oleh SDK) untuk API komponen HARUS tetap ditampilkan.
• [C-0-3] Perilaku API HARUS diimplementasikan sebagai no-op dengan cara yang wajar.
• [C-0-4] Metode API HARUS menampilkan nilai null jika diizinkan oleh dokumentasi SDK.
• [C-0-5] Metode API HARUS menampilkan implementasi no-op dari class yang nilai null-nya tidak diizinkan oleh dokumentasi SDK.
• [C-0-6] Metode API TIDAK BOLEH menampilkan pengecualian yang tidak didokumentasikan oleh dokumentasi SDK.
• [C-0-7] Implementasi perangkat HARUS melaporkan informasi konfigurasi hardware yang akurat secara konsisten melalui metode getSystemAvailableFeatures() dan hasSystemFeature(String) pada class android.content.pm.PackageManager untuk sidik jari build yang sama.

Contoh umum skenario saat persyaratan ini berlaku adalah Telephony API: Bahkan di perangkat non-ponsel, API ini harus diterapkan sebagai operasi no-op yang wajar.

7.1. Tampilan dan Grafis

Android menyertakan fasilitas yang secara otomatis menyesuaikan aset aplikasi dan tata letak UI dengan tepat untuk perangkat guna memastikan aplikasi pihak ketiga berjalan dengan baik di berbagai konfigurasi dan tampilan hardware. Layar yang kompatibel dengan Android adalah layar yang menerapkan semua perilaku dan API yang dijelaskan dalam Android Developers - Screen compatibility overview, bagian ini (7.1) dan subbagiannya, serta perilaku khusus jenis perangkat tambahan yang didokumentasikan dalam bagian 2 CDD ini.

Implementasi perangkat:

• [C-0-1] HARUS, secara default, merender aplikasi pihak ketiga hanya ke layar yang kompatibel dengan Android.

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

• ukuran diagonal fisik. Jarak dalam inci antara dua sudut berlawanan dari bagian layar yang menyala.

• density. Jumlah piksel yang dicakup oleh rentang horizontal atau vertikal linear 1", dinyatakan sebagai piksel per inci (ppi atau dpi). Jika nilai ppi dan dpi dicantumkan, dpi horizontal dan vertikal harus berada dalam rentang yang dicantumkan.

• rasio aspek. Rasio piksel dimensi yang lebih panjang terhadap dimensi yang lebih pendek pada layar. Misalnya, tampilan 480 x 854 piksel adalah 854 / 480 = 1,779, atau kira-kira "16:9".

• piksel kepadatan mandiri (dp). Satuan piksel virtual yang dinormalisasi ke kepadatan layar 160. Untuk kepadatan d tertentu, dan jumlah piksel p, jumlah piksel kepadatan mandiri dp, dihitung sebagai: dp = (160 / d) * p.

7.1.1. Konfigurasi Layar

7.1.1.1. Ukuran dan Bentuk Layar

Framework UI Android mendukung berbagai ukuran tata letak layar logis yang berbeda, dan memungkinkan aplikasi mengkueri ukuran tata letak layar konfigurasi saat ini melalui Configuration.screenLayout dengan SCREENLAYOUT_SIZE_MASK dan Configuration.smallestScreenWidthDp.

Implementasi perangkat:

• [C-0-1] HARUS melaporkan ukuran tata letak yang benar untuk Configuration.screenLayout sebagaimana ditentukan dalam dokumentasi Android SDK. Secara khusus, implementasi perangkat HARUS melaporkan dimensi layar piksel mandiri (dp) logis yang benar seperti di bawah:

  • Perangkat dengan Configuration.uiMode yang ditetapkan sebagai nilai selain UI_MODE_TYPE_WATCH, dan melaporkan ukuran small untuk Configuration.screenLayout, HARUS memiliki ukuran minimal 426 dp x 320 dp.

  • Perangkat yang melaporkan ukuran normal untuk Configuration.screenLayout, HARUS memiliki ukuran minimal 480 dp x 320 dp.

  • Perangkat yang melaporkan ukuran large untuk Configuration.screenLayout, HARUS memiliki minimal 640 dp x 480 dp.

  • Perangkat yang melaporkan ukuran xlarge untuk Configuration.screenLayout, HARUS memiliki minimal 960 dp x 720 dp.

• [C-0-2] HARUS mematuhi dengan benar dukungan yang dinyatakan aplikasi untuk ukuran layar melalui atribut <supports-screens> dalam AndroidManifest.xml, seperti yang dijelaskan dalam dokumentasi Android SDK.

• MUNGKIN memiliki layar yang kompatibel dengan Android dengan sudut bulat.

Jika implementasi perangkat mendukung layar yang mampu melakukan konfigurasi ukuran UI_MODE_TYPE_NORMAL dan menggunakan layar fisik dengan sudut bulat untuk merender layar ini, maka:

• [C-1-1] HARUS memastikan bahwa setidaknya salah satu persyaratan berikut dipenuhi untuk setiap tampilan tersebut:

  • Radius sudut melengkung kurang dari atau sama dengan 38 dp.

  • Saat kotak 18 dp x 18 dp ditambatkan di setiap sudut tampilan logis, setidaknya satu piksel dari setiap kotak terlihat di layar.

• HARUS menyertakan kemudahan pengguna untuk beralih ke mode tampilan dengan sudut persegi panjang.

Jika implementasi perangkat hanya mampu melakukan konfigurasi keyboard NO_KEYS, dan bermaksud melaporkan dukungan untuk konfigurasi mode UI UI_MODE_TYPE_NORMAL, maka:

• [C-4-1] HARUS memiliki ukuran tata letak, tidak termasuk potongan layar, minimal 596 dp x 384 dp atau lebih besar.

Untuk mengetahui detail tentang cara menerapkan API sidecar atau ekstensi dengan benar, lihat dokumentasi publik Window Manager Jetpack.

• [C-4-1] Persyaratan dihapus di Android 15.

7.1.1.2. Rasio Aspek Layar

Bagian ini dihapus di Android 14.

7.1.1.3. Kepadatan Layar

Framework UI Android menentukan serangkaian kepadatan logis standar untuk membantu developer aplikasi menargetkan resource aplikasi.

Implementasi Perangkat:

• [C-0-1] HARUS melaporkan salah satu kepadatan framework Android yang tercantum di DisplayMetrics melalui DENSITY_DEVICE_STABLE API dan nilai ini harus berupa nilai statis untuk setiap tampilan fisik. Namun, perangkat MUNGKIN melaporkan DisplayMetrics.density yang berbeda sesuai dengan perubahan konfigurasi tampilan yang dilakukan oleh pengguna (misalnya, ukuran tampilan) yang ditetapkan setelah booting awal.

• HARUS menentukan kepadatan framework Android standar yang secara numerik paling mendekati kepadatan fisik layar, atau nilai yang akan dipetakan ke pengukuran sudut pandang sudut yang setara dari perangkat genggam.

Jika implementasi perangkat menyediakan kemampuan untuk mengubah ukuran tampilan perangkat, implementasi tersebut:

• [C-1-1] TIDAK BOLEH menskalakan tampilan lebih besar dari 1,5 kali DENSITY_DEVICE_STABLE atau menghasilkan dimensi layar minimum efektif yang lebih kecil dari 320 dp (setara dengan penentu resource sw320dp), mana pun yang lebih dulu.

• [C-1-2] TIDAK BOLEH menskalakan tampilan lebih kecil dari 0,85 kali DENSITY_DEVICE_STABLE.

• Untuk memastikan kegunaan yang baik dan ukuran font yang konsisten, SEBAIKNYA skala opsi Tampilan Native berikut disediakan (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

Jika implementasi perangkat mencakup output video atau layar yang kompatibel dengan Android ke layar yang kompatibel dengan Android, implementasi tersebut:

• [C-1-1] HARUS melaporkan nilai yang benar untuk semua metrik tampilan yang kompatibel dengan Android yang ditentukan dalam API android.util.DisplayMetrics.

Jika implementasi perangkat tidak menyertakan layar tersemat atau output video, perangkat tersebut:

• [C-2-1] HARUS melaporkan nilai yang benar dari layar yang kompatibel dengan Android seperti yang ditentukan dalam android.util.DisplayMetrics API untuk view.Display default yang diemulasi.

7.1.3. Orientasi Layar

Implementasi perangkat:

• [C-0-1] 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 berorientasi tetap, seperti televisi atau laptop, HANYA BOLEH melaporkan android.hardware.screen.landscape.

• [C-0-2] 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.

Jika implementasi perangkat mendukung kedua orientasi layar, maka:

• [C-1-1] Persyaratan dihapus di Android 16.

• [C-1-2] TIDAK BOLEH mengubah ukuran atau kepadatan layar yang dilaporkan saat mengubah orientasi.

• DAPAT memilih orientasi potret atau lanskap sebagai default.

7.1.4. Akselerasi Grafis 2D dan 3D

7.1.4.1. OpenGL ES

Implementasi perangkat:

• [C-0-1] HARUS mengidentifikasi versi OpenGL ES yang didukung (1.1, 2.0, 3.0, 3.1, 3.2) dengan benar melalui API terkelola (seperti melalui metode GLES10.getString()) dan API native.

• [C-0-2] HARUS menyertakan dukungan untuk semua Managed API dan Native API yang sesuai untuk setiap versi OpenGL ES yang diidentifikasi untuk didukung.

Jika implementasi perangkat mencakup layar atau output video, perangkat tersebut:

• [C-1-1] HARUS mendukung OpenGL ES 1.1, 2.0, 3.0, dan 3.1, sebagaimana diwujudkan dan dijelaskan dalam dokumentasi Android SDK.

• [C-SR-1] Persyaratan dihapus di Android 15.

• HARUS mendukung OpenGL ES 3.2.

Pengujian dEQP OpenGL ES dibagi menjadi sejumlah daftar pengujian, yang masing-masing memiliki nomor versi/tanggal terkait. File ini ada di hierarki sumber Android di external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt. Perangkat yang mendukung OpenGL ES pada level yang dilaporkan sendiri menunjukkan bahwa perangkat tersebut dapat lulus uji dEQP di semua daftar pengujian dari level ini dan yang lebih lama.

Jika implementasi perangkat mendukung salah satu versi OpenGL ES, maka:

• [C-2-1] HARUS melaporkan melalui API terkelola OpenGL ES dan API native ekstensi OpenGL ES lainnya yang telah mereka terapkan, dan sebaliknya TIDAK HARUS melaporkan string ekstensi yang tidak mereka dukung.

• [C-2-2] HARUS mendukung ekstensi EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable, dan EGL_ANDROID_GLES_layers.

• [C-2-3] HARUS melaporkan versi maksimum pengujian dEQP OpenGL ES yang didukung melalui tanda fitur android.software.opengles.deqp.level.

• [C-2-4] HARUS mendukung setidaknya versi 132383489 (mulai 1 Maret 2020) seperti yang dilaporkan di flag fitur android.software.opengles.deqp.level.

• [C-2-5] HARUS lulus semua Tes dEQP OpenGL ES dalam daftar pengujian antara versi 132383489 dan versi yang ditentukan dalam tanda fitur android.software.opengles.deqp.level, untuk setiap versi OpenGL ES yang didukung.

• [C-SR-2] SANGAT DISARANKAN untuk mendukung ekstensi EGL_KHR_partial_update dan OES_EGL_image_external.

• HARUS melaporkan secara akurat melalui metode getString(), format kompresi tekstur apa pun yang didukungnya, yang biasanya khusus vendor.

• HARUS mendukung ekstensi EGL_IMG_context_priority dan EGL_EXT_protected_content.

Jika implementasi perangkat menyatakan dukungan untuk OpenGL ES 3.0, 3.1, atau 3.2, maka:

• [C-3-1] HARUS mengekspor simbol fungsi yang sesuai untuk versi ini selain simbol fungsi OpenGL ES 2.0 di library libGLESv2.so.

• [C-SR-3] SANGAT DIREKOMENDASIKAN untuk mendukung ekstensi OES_EGL_image_external_essl3.

Jika implementasi perangkat mendukung OpenGL ES 3.2, maka:

• [C-4-1] HARUS mendukung OpenGL ES Android Extension Pack secara keseluruhan.

Jika implementasi perangkat mendukung Android Extension Pack OpenGL ES secara keseluruhan, maka:

• [C-5-1] HARUS mengidentifikasi dukungan melalui flag fitur android.hardware.opengles.aep.

Jika penerapan perangkat mengekspos dukungan untuk ekstensi EGL_KHR_mutable_render_buffer, maka:

• [C-6-1] JUGA harus mendukung ekstensi EGL_ANDROID_front_buffer_auto_refresh.

7.1.4.2. Vulkan

Android menyertakan dukungan untuk Vulkan, API lintas platform dengan overhead rendah untuk grafis 3D berperforma tinggi.

Jika implementasi perangkat mendukung OpenGL ES 3.1, maka:

• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menyertakan dukungan bagi Vulkan 1.3.

• [C-4-1] TIDAK BOLEH mendukung versi varian Vulkan (yaitu bagian varian dari versi inti Vulkan HARUS nol).

Jika implementasi perangkat mencakup layar atau output video, perangkat tersebut:

• [C-SR-2] SANGAT DIREKOMENDASIKAN untuk menyertakan dukungan untuk Vulkan 1.3.

Pengujian dEQP Vulkan dipartisi ke dalam sejumlah daftar pengujian, yang masing-masing memiliki tanggal/versi terkait. File ini ada di hierarki sumber Android di external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt. Perangkat yang mendukung Vulkan pada tingkat yang dilaporkan sendiri menunjukkan bahwa perangkat tersebut dapat lulus uji dEQP di semua daftar pengujian dari tingkat ini dan sebelumnya.

Jika implementasi perangkat mencakup dukungan untuk Vulkan, maka:

• [C-1-1] HARUS melaporkan nilai bilangan bulat yang benar dengan tanda fitur android.hardware.vulkan.level dan android.hardware.vulkan.version.

• [C-1-2] HARUS mencantumkan setidaknya satu VkPhysicalDevice untuk Vulkan native API vkEnumeratePhysicalDevices().

• [C-1-3] HARUS menerapkan sepenuhnya Vulkan 1.1 API untuk setiap enumerasi VkPhysicalDevice.

• [C-1-4] HARUS mencantumkan lapisan, yang ada dalam library native yang diberi nama libVkLayer*.so di direktori library native paket aplikasi, melalui API native Vulkan vkEnumerateInstanceLayerProperties() dan vkEnumerateDeviceLayerProperties().

• [C-1-6] HARUS melaporkan semua string ekstensi yang didukungnya melalui API native Vulkan , dan sebaliknya TIDAK BOLEH melaporkan string ekstensi yang tidak didukungnya dengan benar.

• [C-1-8] HARUS melaporkan versi maksimum Tes dEQP Vulkan yang didukung melalui flag fitur android.software.vulkan.deqp.level.

• [C-1-9] HARUS mendukung setidaknya versi 132317953 (mulai 1 Maret 2019) seperti yang dilaporkan dalam tanda fitur android.software.vulkan.deqp.level.

• [C-1-10] HARUS lulus semua Pengujian dEQP Vulkan dalam daftar pengujian antara versi 132317953 dan versi yang ditentukan dalam flag fitur android.software.vulkan.deqp.level.

• [C-1-11] TIDAK BOLEH mencantumkan dukungan untuk ekstensi VK_KHR_video_queue, VK_KHR_video_decode_queue, atau VK_KHR_video_encode_queue.

• [C-1-12] TIDAK BOLEH mencantumkan dukungan untuk ekstensi VK_KHR_performance_query.

• [C-SR-4] SANGAT DISARANKAN untuk memenuhi persyaratan yang ditentukan oleh profil Dasar Pengukuran Android 2022.

• [C-SR-5] SANGAT DISARANKAN untuk mendukung VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory dan VK_EXT_global_priority.

• [C-SR-6] SANGAT DISARANKAN untuk menggunakan SkiaVk dengan HWUI.

Jika implementasi perangkat mencakup dukungan untuk Vulkan, maka:

• [C-SR-8] SANGAT DISARANKAN untuk tidak mengubah loader Vulkan.

• [C-1-14] TIDAK BOLEH melakukan enumerasi ekstensi Perangkat Vulkan berjenis "KHR", "GOOGLE", atau "ANDROID", kecuali jika ekstensi ini disertakan dalam tombol fitur android.software.vulkan.deqp.level.

Jika implementasi perangkat tidak menyertakan dukungan untuk Vulkan 1.0, maka:

• [C-2-1] TIDAK BOLEH mendeklarasikan tombol fitur Vulkan apa pun (misalnya, android.hardware.vulkan.level, android.hardware.vulkan.version).

• [C-2-2] TIDAK BOLEH mengenumerasi VkPhysicalDevice untuk Vulkan Native API vkEnumeratePhysicalDevices().

7.1.4.3. RenderScript

Implementasi perangkat:

• [C-0-1] HARUS mendukung Android RenderScript, seperti yang dijelaskan dalam dokumentasi Android SDK.

7.1.4.4. Akselerasi Grafis 2D

Android menyertakan mekanisme bagi aplikasi untuk menyatakan 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:

• [C-0-1] 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.

• [C-0-2] HARUS menunjukkan perilaku yang konsisten dengan dokumentasi Android SDK tentang akselerasi hardware.

Android menyertakan objek TextureView yang memungkinkan developer mengintegrasikan tekstur OpenGL ES yang diakselerasi hardware secara langsung sebagai target rendering dalam hierarki UI.

Implementasi perangkat:

• [C-0-3] HARUS mendukung TextureView API, dan HARUS menunjukkan perilaku yang konsisten dengan implementasi Android upstream.

7.1.4.5. Layar Wide-gamut

Jika implementasi perangkat mengklaim dukungan untuk layar gamut lebar melalui Configuration.isScreenWideColorGamut(), maka:

• [C-1-1] HARUS memiliki layar yang dikalibrasi warnanya.

• [C-1-2] HARUS memiliki layar yang gamutnya mencakup gamut warna sRGB sepenuhnya dalam ruang xyY CIE 1931.

• [C-1-3] HARUS memiliki layar yang gamutnya memiliki area minimal 90% dari DCI-P3 dalam ruang xyY CIE 1931.

• [C-1-4] HARUS mendukung OpenGL ES 3.1 atau 3.2 dan melaporkannya dengan benar.

• [C-1-5] HARUS mengiklankan dukungan untuk ekstensi EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear, dan EGL_EXT_gl_colorspace_display_p3_passthrough.

• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung GL_EXT_sRGB.

Sebaliknya, jika implementasi perangkat tidak mendukung layar gamut lebar, perangkat tersebut:

• [C-2-1] HARUS mencakup 100% atau lebih sRGB dalam ruang xyY CIE 1931, meskipun gamut warna layar tidak ditentukan.

7.1.5. Mode Kompatibilitas Aplikasi Lama

Android menentukan "mode kompatibilitas" yang membuat framework beroperasi dalam mode setara ukuran layar "normal" (lebar 320 dp) untuk aplikasi lama yang tidak dikembangkan untuk Android versi lama yang mendahului independensi ukuran layar.

7.1.6. Teknologi Layar

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

Semua layar yang kompatibel dengan Android dari penerapan perangkat:

• [C-0-1] HARUS dapat merender grafis warna 16-bit.

• HARUS mendukung tampilan yang mampu menampilkan grafis warna 24-bit.

• [C-0-2] HARUS dapat merender animasi.

• [C-0-3] HARUS memiliki rasio aspek piksel (PAR) antara 0,9 dan 1,15. Artinya, rasio aspek piksel HARUS mendekati persegi (1,0) dengan toleransi 10 ~ 15%.

7.1.7. Layar Sekunder

Android menyertakan dukungan untuk layar sekunder yang kompatibel dengan Android untuk mengaktifkan kemampuan berbagi media dan API developer untuk mengakses layar eksternal.

Jika implementasi perangkat mendukung layar eksternal baik melalui koneksi kabel, nirkabel, atau koneksi layar tambahan tersemat, perangkat tersebut:

• [C-1-1] HARUS menerapkan layanan sistem dan API DisplayManager seperti yang dijelaskan dalam dokumentasi Android SDK.

7.2. Perangkat Masukan

Implementasi perangkat:

• [C-0-1] HARUS menyertakan mekanisme input, seperti layar sentuh atau navigasi non-sentuh, untuk menavigasi di antara elemen UI.

7.2.1. Keyboard

Jika implementasi perangkat menyertakan dukungan untuk aplikasi Editor Metode Input (IME) pihak ketiga, maka:

• [C-1-1] HARUS mendeklarasikan tanda fitur android.software.input_methods.
• [C-1-2] HARUS menerapkan Input Management Framework sepenuhnya
• [C-1-3] HARUS memiliki keyboard software yang sudah diinstal sebelumnya.

Implementasi perangkat:

• [C-0-1] TIDAK BOLEH menyertakan keyboard hardware yang tidak cocok dengan salah satu format yang ditentukan dalam android.content.res.Configuration.keyboard (QWERTY atau 12 tombol).
• HARUS menyertakan penerapan keyboard virtual tambahan.
• MUNGKIN menyertakan keyboard hardware.

7.2.2. Navigasi Non-sentuh

Android menyertakan dukungan untuk d-pad, trackball, dan roda sebagai mekanisme untuk navigasi non-sentuh.

Implementasi perangkat:

• [C-0-1] HARUS melaporkan nilai yang benar untuk android.content.res.Configuration.navigation.

Jika implementasi perangkat tidak memiliki navigasi non-sentuh, maka:

• [C-1-1] HARUS menyediakan mekanisme antarmuka pengguna alternatif yang wajar untuk pemilihan dan pengeditan teks, yang kompatibel dengan Mesin Pengelolaan Input. Implementasi open source Android upstream mencakup mekanisme pemilihan yang cocok untuk digunakan dengan perangkat yang tidak memiliki input navigasi non-sentuh.

7.2.3. Kunci Navigasi

Fungsi Beranda, Aplikasi Terbaru, dan Kembali yang biasanya disediakan melalui interaksi dengan tombol fisik khusus atau bagian layar sentuh yang berbeda, sangat penting untuk paradigma navigasi Android dan oleh karena itu, implementasi perangkat:

• [C-0-1] HARUS menyediakan kemudahan pengguna untuk meluncurkan aplikasi terinstal yang memiliki aktivitas dengan <intent-filter> yang ditetapkan dengan ACTION=MAIN dan CATEGORY=LAUNCHER atau CATEGORY=LEANBACK_LAUNCHER untuk penerapan perangkat Televisi. Fungsi Beranda HARUS menjadi mekanisme untuk kemudahan pengguna ini.
• HARUS menyediakan tombol untuk fungsi Terbaru dan Kembali.

Jika fungsi Beranda, Terbaru, atau Kembali disediakan, fungsi tersebut:

• [C-1-1] HARUS dapat diakses dengan satu tindakan (misalnya, ketuk, klik dua kali, atau gestur) saat salah satunya dapat diakses.
• [C-1-2] HARUS memberikan indikasi yang jelas tentang satu tindakan yang akan memicu setiap fungsi. Memiliki ikon yang terlihat tercetak pada tombol, menampilkan ikon software di bagian menu navigasi layar, atau memandu pengguna melalui alur demo langkah demi langkah yang terpandu selama pengalaman penyiapan langsung adalah contoh indikasi tersebut.

Implementasi perangkat:

• [C-SR-1] SANGAT DISARANKAN untuk tidak menyediakan mekanisme input untuk fungsi Menu karena tidak digunakan lagi dan digantikan dengan panel tindakan sejak Android 4.0.

• [C-SR-2] SANGAT DISARANKAN untuk menyediakan semua fungsi navigasi yang dapat dibatalkan. 'Dapat dibatalkan' didefinisikan sebagai kemampuan pengguna untuk mencegah fungsi navigasi dijalankan (misalnya, kembali ke layar utama, kembali, dll.) jika gesekan tidak dilepaskan melewati batas tertentu.

Jika implementasi perangkat menyediakan fungsi Menu, perangkat tersebut:

• [C-2-1] HARUS menampilkan tombol menu tambahan tindakan setiap kali pop-up menu tambahan tindakan tidak kosong dan panel tindakan terlihat.
• [C-2-2] TIDAK BOLEH mengubah posisi pop-up tambahan tindakan yang ditampilkan dengan memilih tombol tambahan di panel tindakan, tetapi DAPAT merender pop-up tambahan tindakan pada posisi yang diubah di layar saat ditampilkan dengan memilih fungsi Menu.

Jika implementasi perangkat tidak menyediakan fungsi Menu, untuk kompatibilitas mundur, implementasi tersebut:

• [C-3-1] HARUS menyediakan fungsi Menu untuk aplikasi saat targetSdkVersion kurang dari 10, baik dengan tombol fisik, tombol software, atau gestur. Fungsi Menu ini harus dapat diakses kecuali jika disembunyikan bersama dengan fungsi navigasi lainnya.

Jika penerapan perangkat menyediakan fungsi Bantuan, maka:

• [C-4-1] HARUS membuat fungsi Bantuan dapat diakses dengan satu tindakan (mis. ketuk, klik dua kali, atau gestur) saat tombol navigasi lainnya dapat diakses.
• [C-SR-3] SANGAT DISARANKAN untuk menggunakan fungsi tekan lama pada BERANDA sebagai interaksi yang ditetapkan ini.

Jika implementasi perangkat menggunakan bagian layar yang berbeda untuk menampilkan tombol navigasi, maka:

• [C-5-1] Tombol navigasi HARUS menggunakan bagian layar yang berbeda, tidak tersedia untuk aplikasi, dan TIDAK BOLEH menutupi atau mengganggu bagian layar yang tersedia untuk aplikasi.
• [C-5-2] HARUS menyediakan sebagian layar untuk aplikasi yang memenuhi persyaratan yang ditentukan dalam bagian 7.1.1.
• [C-5-3] HARUS mematuhi tanda yang ditetapkan oleh aplikasi melalui metode API View.setSystemUiVisibility(), sehingga bagian layar yang berbeda ini (alias panel navigasi) disembunyikan dengan benar seperti yang didokumentasikan di SDK.

Jika fungsi navigasi disediakan sebagai tindakan berbasis gestur di layar:

• [C-6-1] WindowInsets#getMandatorySystemGestureInsets() HANYA boleh digunakan untuk melaporkan area pengenalan gestur Beranda.
• [C-6-2] Gestur yang dimulai dalam persegi panjang pengecualian sebagaimana disediakan oleh aplikasi latar depan melalui View#setSystemGestureExclusionRects(), tetapi di luar WindowInsets#getMandatorySystemGestureInsets(), TIDAK BOLEH dicegat untuk fungsi navigasi selama persegi panjang pengecualian diizinkan dalam batas pengecualian maksimum sebagaimana ditentukan dalam dokumentasi untuk View#setSystemGestureExclusionRects().
• [C-6-3] HARUS mengirimkan peristiwa MotionEvent.ACTION_CANCEL ke aplikasi latar depan setelah sentuhan mulai dicegat untuk gestur sistem, jika aplikasi latar depan sebelumnya dikirimi peristiwa MotionEvent.ACTION_DOWN.
• [C-6-4] HARUS menyediakan kemampuan pengguna untuk beralih ke navigasi berbasis tombol di layar (misalnya, di Setelan).
• HARUS menyediakan fungsi Layar utama dengan menggeser ke atas dari tepi bawah orientasi layar saat ini.
• HARUS menyediakan fungsi Terbaru sebagai geser ke atas dan tahan sebelum rilis, dari area yang sama dengan gestur Beranda.
• Gestur yang dimulai dalam WindowInsets#getMandatorySystemGestureInsets() TIDAK BOLEH terpengaruh oleh persegi pengecualian yang disediakan oleh aplikasi latar depan melalui View#setSystemGestureExclusionRects().

Jika fungsi navigasi disediakan dari mana saja di tepi kiri dan kanan orientasi layar saat ini:

• [C-7-1] Fungsi navigasi HARUS Kembali dan disediakan sebagai geser dari tepi kiri dan kanan orientasi layar saat ini.
• [C-7-2] Jika panel sistem geser kustom disediakan di tepi kiri atau kanan, panel tersebut HARUS ditempatkan dalam 1/3 bagian atas layar dengan indikasi visual yang jelas dan persisten bahwa menarik ke dalam akan memanggil panel yang disebutkan di atas, dan oleh karena itu bukan Kembali. Panel sistem DAPAT dikonfigurasi oleh pengguna sehingga berada di bawah 1/3 tepi layar bagian atas, tetapi panel sistem TIDAK BOLEH menggunakan lebih dari 1/3 tepi layar.
• [C-7-3] Jika aplikasi latar depan memiliki setelan tanda View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT, atau WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE, menggeser dari tepi HARUS berperilaku seperti yang diterapkan di AOSP, yang didokumentasikan di SDK.
• [C-7-4] Jika aplikasi latar depan memiliki tanda View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT, atau WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE yang ditetapkan, panel sistem yang dapat di-swipe kustom HARUS disembunyikan hingga pengguna memunculkan atau membuat panel sistem (alias panel navigasi dan status) tidak redup seperti yang diterapkan di AOSP.

Jika fungsi navigasi kembali disediakan dan pengguna membatalkan gestur Kembali, maka:

• [C-8-1] OnBackInvokedCallback.onBackCancelled() HARUS dipanggil.
• [C-8-2] OnBackInvokedCallback.onBackInvoked() TIDAK BOLEH dipanggil.
• [C-8-3] Peristiwa KEYCODE_BACK TIDAK BOLEH dikirim.

Jika fungsi navigasi kembali disediakan, tetapi aplikasi latar depan TIDAK memiliki OnBackInvokedCallback yang terdaftar, maka:

• Sistem HARUS menyediakan animasi untuk aplikasi latar depan yang menunjukkan bahwa pengguna akan kembali, seperti yang disediakan di AOSP.

Jika implementasi perangkat memberikan dukungan untuk API sistem setNavBarMode untuk mengizinkan aplikasi sistem apa pun dengan izin android.permission.STATUS_BAR untuk menyetel mode panel navigasi, maka implementasi tersebut:

• [C-9-1] HARUS memberikan dukungan untuk ikon yang cocok untuk anak-anak atau navigasi berbasis tombol seperti yang disediakan dalam kode AOSP.

7.2.4. Input Layar Sentuh

Android menyertakan dukungan untuk berbagai sistem input penunjuk, seperti layar sentuh, panel sentuh, dan perangkat input sentuh palsu. Implementasi perangkat berbasis layar sentuh dikaitkan dengan layar sehingga pengguna memiliki kesan memanipulasi item di layar secara langsung. Karena pengguna menyentuh layar secara langsung, sistem tidak memerlukan afordans tambahan untuk menunjukkan objek yang sedang dimanipulasi.

Implementasi perangkat:

• HARUS memiliki sistem input penunjuk dalam bentuk apa pun (seperti mouse atau sentuh).
• HARUS mendukung penunjuk yang dilacak sepenuhnya secara independen.

Jika implementasi perangkat menyertakan layar sentuh (sentuhan tunggal atau yang lebih baik) di layar utama yang kompatibel dengan Android, maka:

• [C-1-1] HARUS melaporkan TOUCHSCREEN_FINGER untuk kolom API Configuration.touchscreen.
• [C-1-2] HARUS melaporkan flag fitur android.hardware.touchscreen dan android.hardware.faketouch.

Jika implementasi perangkat mencakup layar sentuh yang dapat melacak lebih dari satu sentuhan pada layar utama yang kompatibel dengan Android, maka:

• [C-2-1] HARUS melaporkan flag fitur yang sesuai android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand yang sesuai dengan jenis layar sentuh tertentu di perangkat.

Jika implementasi perangkat mengandalkan perangkat input eksternal seperti mouse atau trackball (yaitu tidak menyentuh layar secara langsung) untuk input pada layar utama yang kompatibel dengan Android dan memenuhi persyaratan sentuhan palsu di bagian 7.2.5, maka:

• [C-3-1] TIDAK BOLEH melaporkan tanda fitur yang diawali dengan android.hardware.touchscreen.
• [C-3-2] HANYA boleh melaporkan android.hardware.faketouch.
• [C-3-3] HARUS melaporkan TOUCHSCREEN_NOTOUCH untuk kolom API Configuration.touchscreen.

7.2.5. Input Sentuh Palsu

Antarmuka sentuh palsu menyediakan sistem input pengguna yang memperkirakan subset kemampuan layar sentuh. Misalnya, mouse atau remote control yang menggerakkan kursor pada layar mendekati sentuhan, tetapi mengharuskan pengguna untuk mengarahkan atau memfokuskan, lalu mengklik terlebih dahulu. Berbagai perangkat input seperti mouse, trackpad, mouse udara berbasis giroskop, penunjuk giroskop, joystick, dan trackpad multisentuh 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 mengemulasi input berbasis sentuhan secara memadai (termasuk dukungan gestur dasar), dan menunjukkan bahwa perangkat mendukung subset fungsionalitas layar sentuh yang diemulasi.

Jika implementasi perangkat tidak menyertakan layar sentuh, tetapi menyertakan sistem input penunjuk lain yang ingin mereka sediakan, mereka:

• HARUS mendeklarasikan dukungan untuk flag fitur android.hardware.faketouch.

Jika penerapan perangkat menyatakan dukungan untuk android.hardware.faketouch, maka:

• [C-1-1] HARUS melaporkan posisi layar X dan Y absolut dari lokasi pointer dan menampilkan pointer visual di layar.
• [C-1-2] HARUS melaporkan peristiwa sentuh dengan kode tindakan yang menentukan perubahan status yang terjadi pada penunjuk saat turun atau naik di layar.
• [C-1-3] HARUS mendukung pointer turun dan naik pada objek di layar, yang memungkinkan pengguna meniru ketukan pada objek di layar.
• [C-1-4] HARUS mendukung pointer turun, pointer naik, pointer turun lalu pointer naik di tempat yang sama pada objek di layar dalam batas waktu, yang memungkinkan pengguna mengemulasi ketuk ganda pada objek di layar.
• [C-1-5] HARUS mendukung pointer turun pada titik arbitrer di layar, pointer berpindah ke titik arbitrer lain di layar, diikuti dengan pointer naik, yang memungkinkan pengguna meniru penarikan sentuh.
• [C-1-6] HARUS mendukung pointer turun, lalu memungkinkan pengguna memindahkan objek dengan cepat ke posisi yang berbeda di layar, lalu pointer naik di layar, yang memungkinkan pengguna melemparkan objek di layar.

Jika penerapan perangkat menyatakan dukungan untuk android.hardware.faketouch.multitouch.distinct, perangkat tersebut:

• [C-2-1] HARUS mendeklarasikan dukungan untuk android.hardware.faketouch.
• [C-2-2] HARUS mendukung pelacakan yang berbeda dari dua atau beberapa input penunjuk independen.

Jika penerapan perangkat menyatakan dukungan untuk android.hardware.faketouch.multitouch.jazzhand, perangkat tersebut:

• [C-3-1] HARUS mendeklarasikan dukungan untuk android.hardware.faketouch.
• [C-3-2] HARUS mendukung pelacakan berbeda dari 5 (melacak jari tangan) atau lebih input penunjuk secara sepenuhnya independen.

7.2.6. Dukungan Pengontrol Game

7.2.6.1. Pemetaan Tombol

Implementasi perangkat:

• [C-1-1] HARUS dapat memetakan peristiwa HID ke konstanta InputEvent yang sesuai seperti yang tercantum dalam tabel di bawah. Implementasi Android upstream memenuhi persyaratan ini.

Jika implementasi perangkat menyematkan pengontrol atau dikirim dengan pengontrol terpisah dalam kotak yang akan menyediakan cara untuk memasukkan semua peristiwa yang tercantum dalam tabel di bawah, maka:

• [C-2-1] HARUS mendeklarasikan tanda fitur android.hardware.gamepad

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

1 KeyEvent

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

3 Penggunaan ini harus memiliki Logical Minimum 0, Logical Maximum 7, Physical Minimum 0, Physical Maximum 315, Satuan dalam Derajat, dan Ukuran Laporan 4. Nilai logis ditentukan sebagai rotasi searah jarum jam dari sumbu vertikal; misalnya, nilai logis 0 menunjukkan tidak ada rotasi dan tombol atas ditekan, sedangkan nilai logis 1 menunjukkan rotasi 45 derajat dan tombol atas serta kiri ditekan bersamaan.

4 MotionEvent

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

1 MotionEvent

7.2.7. Remote Control

Lihat Bagian 2.3.1 untuk mengetahui persyaratan khusus perangkat.

7.3. Sensor

Jika implementasi perangkat menyertakan jenis sensor tertentu yang memiliki API terkait untuk developer pihak ketiga, implementasi perangkat HARUS menerapkan API tersebut seperti yang dijelaskan dalam dokumentasi Android SDK dan dokumentasi Android Open Source tentang sensor.

Implementasi perangkat:

• [C-0-1] HARUS melaporkan secara akurat ada atau tidaknya sensor per kelas android.content.pm.PackageManager.

• [C-0-2] HARUS menampilkan daftar akurat sensor yang didukung melalui SensorManager.getSensorList() dan metode serupa.

• [C-0-3] HARUS berperilaku wajar untuk semua API sensor lainnya (misalnya, dengan menampilkan true atau false sebagaimana mestinya saat aplikasi mencoba mendaftarkan pemroses, tidak memanggil pemroses sensor saat sensor yang bersangkutan tidak ada; dll.).

Jika implementasi perangkat menyertakan jenis sensor tertentu yang memiliki API terkait untuk developer pihak ketiga, maka:

• [C-1-1] HARUS melaporkan semua pengukuran sensor menggunakan nilai Satuan Internasional (metrik) yang relevan untuk setiap jenis sensor sebagaimana ditentukan dalam dokumentasi Android SDK.

• [C-1-2] HARUS melaporkan data sensor dengan latensi maksimum 100 milidetik + 2 * sample_time untuk kasus streaming sensor dengan latensi maksimum yang diminta 0 mdk saat prosesor aplikasi aktif. Penundaan ini tidak mencakup penundaan pemfilteran.

• [C-1-3] HARUS melaporkan sampel sensor pertama dalam waktu 400 milidetik + 2 * sample_time setelah sensor diaktifkan. Sampel ini dapat diterima jika memiliki akurasi 0.

• [C-1-4] Untuk setiap API yang ditunjukkan oleh dokumentasi Android SDK sebagai sensor berkelanjutan, implementasi perangkat HARUS terus-menerus memberikan sampel data berkala yang SEBAIKNYA memiliki jitter di bawah 3%, dengan jitter didefinisikan sebagai standar deviasi perbedaan nilai stempel waktu yang dilaporkan antara peristiwa berurutan.

• [C-1-5] HARUS memastikan bahwa aliran peristiwa sensor TIDAK BOLEH mencegah CPU perangkat memasuki status ditangguhkan atau mengaktifkan dari status ditangguhkan.

• [C-1-6] HARUS melaporkan waktu peristiwa dalam nanodetik seperti yang ditentukan dalam dokumentasi Android SDK, yang merepresentasikan waktu terjadinya peristiwa dan disinkronkan dengan clock SystemClock.elapsedRealtimeNano().

• [C-SR-1] SANGAT DISARANKAN untuk memiliki error sinkronisasi stempel waktu di bawah 100 milidetik, dan SEBAIKNYA memiliki error sinkronisasi stempel waktu di bawah 1 milidetik.

• Saat beberapa sensor diaktifkan, konsumsi daya TIDAK BOLEH melebihi jumlah konsumsi daya yang dilaporkan oleh masing-masing sensor.

Daftar di atas tidak lengkap; perilaku yang didokumentasikan dari Android SDK dan Dokumentasi Open Source Android tentang sensor harus dianggap sebagai sumber tepercaya.

Jika implementasi perangkat menyertakan jenis sensor tertentu yang memiliki API terkait untuk developer pihak ketiga, maka:

• [C-1-6] HARUS menetapkan resolusi bukan nol untuk semua sensor, dan melaporkan nilai melalui metode API Sensor.getResolution().

Beberapa jenis sensor bersifat komposit, yang berarti dapat diperoleh dari data yang disediakan oleh satu atau beberapa sensor lainnya. (Contohnya mencakup sensor orientasi dan sensor akselerasi linier.)

Implementasi perangkat:

• HARUS menerapkan jenis sensor ini, jika menyertakan sensor fisik prasyarat seperti yang dijelaskan dalam jenis sensor.

Jika penerapan perangkat mencakup sensor komposit, maka:

• [C-2-1] HARUS menerapkan sensor seperti yang dijelaskan dalam dokumentasi Android Open Source tentang sensor komposit.

Jika implementasi perangkat menyertakan jenis sensor tertentu yang memiliki API terkait untuk developer pihak ketiga dan sensor hanya melaporkan satu nilai, maka implementasi perangkat:

• [C-3-1] HARUS menetapkan resolusi ke 1 untuk sensor dan melaporkan nilai melalui metode API Sensor.getResolution().

Jika implementasi perangkat menyertakan jenis sensor tertentu yang mendukung SensorAdditionalInfo#TYPE_VEC3_CALIBRATION dan sensor tersebut diekspos ke developer pihak ketiga, mereka:

• [C-4-1] TIDAK BOLEH menyertakan parameter kalibrasi tetap yang ditentukan pabrik dalam data yang diberikan.

Jika implementasi perangkat mencakup kombinasi akselerometer 3 sumbu, sensor giroskop 3 sumbu, atau sensor magnetometer, maka:

• [C-SR-2] SANGAT DIREKOMENDASIKAN untuk memastikan akselerometer, giroskop, dan magnetometer memiliki posisi relatif tetap, sehingga jika perangkat dapat diubah bentuknya (misalnya, perangkat foldable), sumbu sensor tetap selaras dan konsisten dengan sistem koordinat sensor di semua kemungkinan status transformasi perangkat.

7.3.1. Akselerometer

Implementasi perangkat:

• [C-SR-1] SANGAT DISARANKAN untuk menyertakan akselerometer 3 sumbu.

Jika penerapan perangkat mencakup akselerometer, perangkat tersebut:

• [C-1-1] HARUS dapat melaporkan peristiwa hingga frekuensi minimal 50 Hz.

• [C-1-3] HARUS mematuhi sistem koordinat sensor Android seperti yang dijelaskan dalam Android API.

• [C-1-4] HARUS mampu mengukur dari jatuh bebas hingga empat kali gravity(4g) atau lebih pada sumbu mana pun.

• [C-1-5] HARUS memiliki resolusi minimal 12 bit.

• [C-1-6] HARUS memiliki standar deviasi tidak lebih besar dari 0,05 m/s^, dengan standar deviasi harus dihitung per sumbu pada sampel yang dikumpulkan selama minimal 3 detik pada kecepatan pengambilan sampel tercepat.

• HARUS melaporkan peristiwa hingga setidaknya 200 Hz.

• HARUS memiliki resolusi minimal 16 bit.

• HARUS dikalibrasi saat digunakan jika karakteristiknya berubah selama siklus proses dan dikompensasi, serta mempertahankan parameter kompensasi di antara proses mulai ulang perangkat.

• HARUS dikompensasi suhunya.

Jika implementasi perangkat menyertakan akselerometer 3 sumbu, maka:

• [C-2-1] HARUS menerapkan dan melaporkan sensor TYPE_ACCELEROMETER.

• [C-SR-4] SANGAT DISARANKAN untuk menerapkan sensor gabungan TYPE_SIGNIFICANT_MOTION.

• [C-SR-5] SANGAT DISARANKAN untuk menerapkan dan melaporkan sensor TYPE_ACCELEROMETER_UNCALIBRATED. Perangkat Android SANGAT DISARANKAN untuk memenuhi persyaratan ini sehingga perangkat tersebut dapat diupgrade ke rilis platform mendatang yang mungkin MENSYARATKAN hal ini.

• HARUS menerapkan sensor komposit TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER seperti yang dijelaskan dalam dokumen Android SDK.

Jika implementasi perangkat menyertakan akselerometer dengan kurang dari 3 sumbu, maka:

• [C-3-1] HARUS menerapkan dan melaporkan sensor TYPE_ACCELEROMETER_LIMITED_AXES.

• [C-SR-6] SANGAT DISARANKAN untuk menerapkan dan melaporkan sensor TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

Jika implementasi perangkat mencakup akselerometer 3 sumbu dan salah satu sensor komposit TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER diimplementasikan:

• [C-4-1] Jumlah konsumsi daya mereka HARUS selalu kurang dari 4 mW.

• HARUS masing-masing di bawah 2 mW dan 0,5 mW saat perangkat dalam kondisi dinamis atau statis.

Jika implementasi perangkat mencakup sensor akselerometer 3 sumbu dan giroskop 3 sumbu, maka:

• [C-5-1] HARUS menerapkan sensor komposit TYPE_GRAVITY dan TYPE_LINEAR_ACCELERATION.

• [C-SR-7] SANGAT DISARANKAN untuk menerapkan sensor komposit TYPE_GAME_ROTATION_VECTOR.

Jika implementasi perangkat mencakup sensor akselerometer 3 sumbu, sensor giroskop 3 sumbu, dan sensor magnetometer, maka:

• [C-6-1] HARUS menerapkan sensor gabungan TYPE_ROTATION_VECTOR.

7.3.2. Magnetometer

Implementasi perangkat:

• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menyertakan magnetometer 3 sumbu (kompas).

Jika implementasi perangkat mencakup magnetometer 3 sumbu, perangkat tersebut:

• [C-1-1] HARUS menerapkan sensor TYPE_MAGNETIC_FIELD.

• [C-1-2] HARUS dapat melaporkan peristiwa hingga frekuensi minimal 10 Hz dan SEBAIKNYA melaporkan peristiwa hingga minimal 50 Hz.

• [C-1-3] HARUS mematuhi sistem koordinat sensor Android seperti yang dijelaskan dalam Android API.

• [C-1-4] HARUS mampu mengukur antara -900 µT dan +900 µT pada setiap sumbu sebelum mencapai saturasi.

• [C-1-5] HARUS memiliki nilai offset besi keras kurang dari 700 µT dan SEBAIKNYA memiliki nilai di bawah 200 µT, dengan menempatkan magnetometer jauh dari medan magnet dinamis (akibat arus) dan statis (akibat magnet).

• [C-1-6] HARUS memiliki resolusi yang sama atau lebih padat dari 0,6 µT.

• [C-1-7] HARUS mendukung kalibrasi dan kompensasi online terhadap bias besi keras, serta mempertahankan parameter kompensasi di antara proses mulai ulang perangkat.

• [C-1-8] HARUS menerapkan kompensasi besi lunak—kalibrasi dapat dilakukan saat digunakan atau selama produksi perangkat.

• [C-1-9] HARUS memiliki simpangan baku, yang dihitung berdasarkan per sumbu pada sampel yang dikumpulkan selama jangka waktu minimal 3 detik pada kecepatan pengambilan sampel tercepat, tidak lebih besar dari 1,5 µT; SEBAIKNYA memiliki simpangan baku tidak lebih besar dari 0,5 µT.

• [C-1-10] HARUS menerapkan sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED.

Jika implementasi perangkat mencakup magnetometer 3 sumbu, sensor akselerometer, dan sensor giroskop 3 sumbu, maka:

• [C-2-1] HARUS menerapkan sensor gabungan TYPE_ROTATION_VECTOR.

Jika implementasi perangkat mencakup magnetometer 3 sumbu dan akselerometer, maka:

• MAY mengimplementasikan sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Jika implementasi perangkat menyertakan magnetometer 3 sumbu, akselerometer, dan sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR, maka:

• [C-3-1] HARUS menggunakan daya kurang dari 10 mW.

• HARUS mengonsumsi daya kurang dari 3 mW saat sensor didaftarkan untuk mode batch pada 10 Hz.

7.3.3. GPS

Implementasi perangkat:

• [C-SR-1] SANGAT DISARANKAN untuk menyertakan penerima GPS/GNSS.

Jika implementasi perangkat mencakup penerima GPS/GNSS dan melaporkan kemampuan ke aplikasi melalui flag fitur android.hardware.location.gps, maka:

• [C-1-1] HARUS mendukung output lokasi dengan kecepatan minimal 1 Hz saat diminta melalui LocationManager#requestLocationUpdate.

• [C-1-2] HARUS dapat menentukan lokasi dalam kondisi langit terbuka (sinyal kuat, multipath dapat diabaikan, HDOP < 2) dalam waktu 10 detik (waktu untuk mendapatkan perbaikan pertama yang cepat), saat terhubung ke koneksi internet berkecepatan data 0,5 Mbps atau lebih cepat. Persyaratan ini biasanya dipenuhi dengan penggunaan beberapa bentuk teknik GPS/GNSS yang Dibantu atau Diprediksi untuk meminimalkan waktu penguncian GPS/GNSS (Data bantuan mencakup Waktu Referensi, Lokasi Referensi, dan Efemeris/Waktu Satelit).

  • [C-1-6] Setelah melakukan penghitungan lokasi tersebut, implementasi perangkat HARUS menentukan lokasinya, di ruang terbuka, dalam waktu 5 detik, saat permintaan lokasi dimulai ulang, hingga satu jam setelah penghitungan lokasi awal, meskipun permintaan berikutnya dilakukan 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:

  • [C-1-3] HARUS dapat menentukan lokasi dalam jarak 20 meter, dan kecepatan dalam 0,5 meter per detik, setidaknya 95% dari waktu.

  • [C-1-4] HARUS secara bersamaan melacak dan melaporkan melalui GnssStatus.Callback setidaknya 8 satelit dari satu konstelasi.

  • HARUS dapat melacak setidaknya 24 satelit secara bersamaan, dari beberapa konstelasi (misalnya, GPS + setidaknya salah satu dari Glonass, Beidou, Galileo).

• [C-SR-2] SANGAT DISARANKAN untuk terus memberikan output lokasi GPS/GNSS normal melalui API Penyedia Lokasi GNSS selama panggilan telepon darurat.

• [C-SR-3] SANGAT DISARANKAN untuk melaporkan pengukuran GNSS dari semua konstelasi yang dilacak (seperti yang dilaporkan dalam pesan GnssStatus), kecuali SBAS.

• [C-SR-4] SANGAT DISARANKAN untuk melaporkan AGC, dan Frekuensi pengukuran GNSS.

• [C-SR-5] SANGAT DISARANKAN untuk melaporkan semua estimasi akurasi (termasuk Arah, Kecepatan, dan Vertikal) sebagai bagian dari setiap lokasi GPS/GNSS.

• [C-SR-6] SANGAT DISARANKAN untuk melaporkan pengukuran GNSS, segera setelah ditemukan, meskipun lokasi yang dihitung dari GPS/GNSS belum dilaporkan.

• [C-SR-7] SANGAT DISARANKAN untuk melaporkan pseudorange dan laju pseudorange GNSS, yang, dalam kondisi langit terbuka setelah menentukan lokasi, saat stasioner atau bergerak dengan percepatan kurang dari 0,2 meter per detik kuadrat, sudah cukup untuk menghitung posisi dalam jarak 20 meter, dan kecepatan dalam jarak 0,2 meter per detik, setidaknya 95% dari waktu.

7.3.4. Giroskop

Implementasi perangkat:

• [C-SR-1] SANGAT DISARANKAN untuk menyertakan sensor giroskop.

Jika implementasi perangkat mencakup giroskop, perangkat tersebut:

• [C-1-1] HARUS dapat melaporkan peristiwa hingga frekuensi minimal 50 Hz.

• [C-1-4] HARUS memiliki resolusi 12 bit atau lebih.

• [C-1-5] HARUS dikompensasi suhunya.

• [C-1-6] HARUS dikalibrasi dan dikompensasi saat digunakan, serta mempertahankan parameter kompensasi di antara proses mulai ulang perangkat.

• [C-1-7] HARUS memiliki varians tidak lebih besar dari 1e-7 rad^2 / s^2 per Hz (varians per Hz, atau rad^2 / s). Varians diizinkan bervariasi dengan rasio pengambilan sampel, tetapi HARUS dibatasi oleh nilai ini. Dengan kata lain, jika Anda mengukur varians giroskop pada frekuensi pengambilan sampel 1 Hz, varians tersebut SEHARUSNYA tidak lebih besar dari 1e-7 rad^2/s^2.

• [C-SR-2] Error kalibrasi SANGAT DISARANKAN agar kurang dari 0,01 rad/s saat perangkat tidak bergerak pada suhu ruangan.

• [C-SR-3] SANGAT DISARANKAN untuk memiliki resolusi 16 bit atau lebih.

• HARUS melaporkan peristiwa hingga setidaknya 200 Hz.

Jika implementasi perangkat mencakup giroskop 3 sumbu, perangkat tersebut:

• [C-2-1] HARUS menerapkan sensor TYPE_GYROSCOPE.

• [C-SR-4] Sangat Direkomendasikan untuk menerapkan sensor TYPE_GYROSCOPE_UNCALIBRATED.

Jika implementasi perangkat menyertakan giroskop dengan kurang dari 3 sumbu, maka:

• [C-3-1] HARUS menerapkan dan melaporkan sensor TYPE_GYROSCOPE_LIMITED_AXES.

• [C-SR-5] SANGAT DISARANKAN untuk menerapkan dan melaporkan sensor TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

Jika implementasi perangkat mencakup giroskop 3 sumbu, sensor akselerometer, dan sensor magnetometer, maka:

• [C-4-1] HARUS menerapkan sensor gabungan TYPE_ROTATION_VECTOR.

Jika implementasi perangkat mencakup sensor akselerometer 3 sumbu dan giroskop 3 sumbu, maka:

• [C-5-1] HARUS menerapkan sensor komposit TYPE_GRAVITY dan TYPE_LINEAR_ACCELERATION.

• [C-SR-6] SANGAT DISARANKAN untuk menerapkan sensor gabungan TYPE_GAME_ROTATION_VECTOR.

7.3.5. Barometer

Implementasi perangkat:

• [C-SR-1] SANGAT DISARANKAN untuk menyertakan barometer (sensor tekanan udara sekitar).

Jika implementasi perangkat menyertakan barometer, perangkat tersebut:

• [C-1-1] HARUS menerapkan dan melaporkan sensor TYPE_PRESSURE.

• [C-1-2] HARUS dapat mengirimkan peristiwa pada 5 Hz atau lebih tinggi.

• [C-1-3] HARUS dikompensasi suhunya.

• [C-SR-2] SANGAT DISARANKAN agar dapat melaporkan pengukuran tekanan dalam rentang 300 hPa hingga 1100 hPa.

• HARUS memiliki akurasi absolut 1 hPa.

• HARUS memiliki akurasi relatif 0,12 hPa dalam rentang 20 hPa (setara dengan akurasi ~1 m dalam perubahan ~200 m di permukaan laut).

Implementasi perangkat yang mendeklarasikan properti sistem sensor.barometer.high_quality.implemented:

• [C-2-1] HARUS melaporkan pengukuran tekanan dalam rentang 300 hPa hingga 1.100 hPa, dengan akurasi mutlak +/- 1 hPa.

• [C-2-2] HARUS memiliki akurasi relatif 0,15 hPa dalam rentang 100 hPa, yang setara dengan akurasi ~1 m dalam perubahan ~1.000 m di permukaan laut.

• [C-2-3] HARUS stabil dalam +/- 0,5 hPa saat pengguna mengetuk, menekan, atau meremas perangkat.

• [C-2-4] HARUS stabil dalam +/- 0,15 hPa saat pengguna berjalan dengan perangkat di tangan atau di saku.

• [C-2-5] TIDAK BOLEH dihaluskan dengan konstanta waktu lebih dari 300 md untuk aktivasi di atas 5 Hz, dan penghalusan TIDAK BOLEH bocor di seluruh aktivasi sensor.

• [C-2-6] HARUS stabil dalam +/- 0,15 hPa saat terpapar cahaya dan frekuensi radio sehari-hari yang berasal dari sumber umum seperti Bluetooth, koneksi seluler, atau Wi-Fi.

7.3.6. Thermometer

Jika implementasi perangkat menyertakan termometer sekitar (sensor suhu), perangkat tersebut:

• [C-1-1] HARUS menentukan SENSOR_TYPE_AMBIENT_TEMPERATURE untuk sensor suhu sekitar dan sensor HARUS mengukur suhu sekitar (kabin ruangan/kendaraan) dari tempat pengguna berinteraksi dengan perangkat dalam derajat Celcius.

Jika implementasi perangkat menyertakan sensor termometer yang mengukur suhu selain suhu sekitar, seperti suhu CPU, maka:

• [C-2-1] TIDAK BOLEH menentukan SENSOR_TYPE_AMBIENT_TEMPERATURE untuk sensor suhu.

Jika implementasi perangkat menyertakan sensor untuk memantau suhu kulit, maka:

• [C-SR-1] SANGAT DISARANKAN untuk mendukung API PowerManager.getThermalHeadroom.

7.3.7. Fotometer

• Implementasi perangkat DAPAT mencakup fotometer (sensor cahaya sekitar).

7.3.8. Sensor Kedekatan

• Implementasi perangkat DAPAT mencakup sensor kedekatan.

Jika implementasi perangkat menyertakan sensor kedekatan dan hanya melaporkan pembacaan biner "dekat" atau "jauh", maka:

• [C-1-1] HARUS mengukur kedekatan objek dalam arah yang sama dengan layar. Artinya, sensor jarak HARUS diorientasikan untuk mendeteksi objek yang dekat dengan layar, karena tujuan utama jenis sensor ini adalah untuk mendeteksi ponsel yang sedang digunakan oleh pengguna. Jika penerapan perangkat menyertakan sensor jarak dengan orientasi lain, sensor tersebut TIDAK BOLEH dapat diakses melalui API ini.

• [C-1-2] HARUS memiliki akurasi 1 bit atau lebih.

• [C-1-3] HARUS menggunakan 0 sentimeter sebagai jarak baca dekat dan 5 sentimeter sebagai jarak baca jauh.

• [C-1-4] HARUS melaporkan rentang dan resolusi maksimum 5.

7.3.9. Sensor Akurasi Tinggi

Jika implementasi perangkat menyertakan serangkaian sensor berkualitas lebih tinggi seperti yang ditentukan dalam bagian ini, dan menyediakannya untuk aplikasi pihak ketiga, maka:

• [C-1-1] HARUS mengidentifikasi kemampuan melalui flag fitur android.hardware.sensor.hifi_sensors.

Jika implementasi perangkat mendeklarasikan android.hardware.sensor.hifi_sensors, maka:

• [C-2-1] HARUS memiliki sensor TYPE_ACCELEROMETER yang:

  • HARUS memiliki rentang pengukuran antara -8 g dan +8 g, dan SANGAT DISARANKAN untuk memiliki rentang pengukuran antara -16 g dan +16 g.

  • HARUS memiliki resolusi pengukuran minimal 2048 LSB/g.

  • HARUS memiliki frekuensi pengukuran minimum 12,5 Hz atau lebih rendah.

  • HARUS memiliki frekuensi pengukuran maksimum 400 Hz atau lebih tinggi; HARUS mendukung SensorDirectChannel RATE_VERY_FAST.

  • HARUS memiliki derau pengukuran tidak lebih dari 400 μg/√Hz.

  • HARUS menerapkan bentuk sensor ini yang tidak mengaktifkan perangkat dengan kemampuan buffering minimal 3.000 peristiwa sensor.

  • HARUS memiliki konsumsi daya batching yang tidak lebih buruk dari 3 mW.

  • [C-SR-1] SANGAT DISARANKAN untuk memiliki bandwidth pengukuran 3 dB minimal 80% dari frekuensi Nyquist, dan spektrum derau putih dalam bandwidth ini.

  • HARUS memiliki jalan acak akselerasi kurang dari 30 μg √Hz yang diuji pada suhu ruangan.

  • HARUS memiliki perubahan bias vs. suhu ≤ +/- 1 mg/°C.

  • HARUS memiliki non-linearitas garis kecocokan terbaik ≤ 0,5%, dan perubahan sensitivitas vs. suhu ≤ 0,03%/C°.

  • HARUS memiliki sensitivitas lintas sumbu < 2,5 % dan variasi sensitivitas lintas sumbu < 0,2% dalam rentang suhu operasi perangkat.

• [C-2-2] HARUS memiliki TYPE_ACCELEROMETER_UNCALIBRATED dengan persyaratan kualitas yang sama seperti TYPE_ACCELEROMETER.

• [C-2-3] HARUS memiliki sensor TYPE_GYROSCOPE yang:

  • HARUS memiliki rentang pengukuran antara -1.000 dan +1.000 dps.

  • HARUS memiliki resolusi pengukuran minimal 16 LSB/dps.

  • HARUS memiliki frekuensi pengukuran minimum 12,5 Hz atau lebih rendah.

  • HARUS memiliki frekuensi pengukuran maksimum 400 Hz atau lebih tinggi; HARUS mendukung SensorDirectChannel RATE_VERY_FAST.

  • HARUS memiliki derau pengukuran tidak lebih dari 0,014&°/s/√Hz.

  • [C-SR-2] SANGAT DISARANKAN untuk memiliki bandwidth pengukuran 3 dB minimal 80% dari frekuensi Nyquist, dan spektrum derau putih dalam bandwidth ini.

  • HARUS memiliki jalan acak laju kurang dari 0,001&°/s √Hz yang diuji pada suhu ruangan.

  • HARUS memiliki perubahan bias vs. suhu ≤ +/- 0,05&°/ s / °C.

  • HARUS memiliki perubahan sensitivitas vs. suhu ≤ 0,02% / °C.

  • HARUS memiliki non-linearitas garis kecocokan terbaik ≤ 0,2%.

  • HARUS memiliki kepadatan derau ≤ 0,007&°/s/√Hz.

  • HARUS memiliki error kalibrasi kurang dari 0,002 rad/s dalam rentang suhu 10 ~ 40 ℃ saat perangkat tidak bergerak.

  • HARUS memiliki sensitivitas g kurang dari 0,1&°/s/g.

  • HARUS memiliki sensitivitas lintas sumbu < 4,0 % dan variasi sensitivitas lintas sumbu < 0,3% dalam rentang suhu pengoperasian perangkat.

• [C-2-4] HARUS memiliki TYPE_GYROSCOPE_UNCALIBRATED dengan persyaratan kualitas yang sama dengan TYPE_GYROSCOPE.

• [C-2-5] HARUS memiliki sensor TYPE_GEOMAGNETIC_FIELD yang:

  • HARUS memiliki rentang pengukuran antara minimal -900 dan +900 μT.

  • HARUS memiliki resolusi pengukuran minimal 5 LSB/uT.

  • HARUS memiliki frekuensi pengukuran minimum 5 Hz atau lebih rendah.

  • HARUS memiliki frekuensi pengukuran maksimum 50 Hz atau lebih tinggi.

  • HARUS memiliki derau pengukuran tidak lebih dari 0,5 uT.

• [C-2-6] HARUS memiliki TYPE_MAGNETIC_FIELD_UNCALIBRATED dengan persyaratan kualitas yang sama dengan TYPE_GEOMAGNETIC_FIELD dan selain itu:

  • HARUS menerapkan bentuk sensor ini yang tidak mengaktifkan perangkat dengan kemampuan buffering minimal 600 peristiwa sensor.

  • [C-SR-3] SANGAT DISARANKAN untuk memiliki spektrum derau putih dari 1 Hz hingga minimal 10 Hz saat kecepatan pelaporan adalah 50 Hz atau lebih tinggi.

• [C-2-7] HARUS memiliki sensor TYPE_PRESSURE yang:

  • HARUS memiliki rentang pengukuran antara minimal 300 dan 1.100 hPa.

  • HARUS memiliki resolusi pengukuran minimal 80 LSB/hPa.

  • HARUS memiliki frekuensi pengukuran minimum 1 Hz atau lebih rendah.

  • HARUS memiliki frekuensi pengukuran maksimum 10 Hz atau lebih tinggi.

  • HARUS memiliki derau pengukuran tidak lebih dari 2 Pa/√Hz.

  • HARUS menerapkan bentuk sensor ini yang tidak mengaktifkan perangkat dengan kemampuan buffering minimal 300 peristiwa sensor.

  • HARUS memiliki konsumsi daya batching tidak lebih buruk dari 2 mW.

• [C-2-8] HARUS memiliki sensor TYPE_GAME_ROTATION_VECTOR.

• [C-2-9] HARUS memiliki sensor TYPE_SIGNIFICANT_MOTION yang:

  • HARUS memiliki konsumsi daya tidak lebih buruk dari 0,5 mW saat perangkat statis dan 1,5 mW saat perangkat bergerak.

• [C-2-10] HARUS memiliki sensor TYPE_STEP_DETECTOR yang:

  • HARUS menerapkan bentuk sensor ini yang tidak mengaktifkan perangkat 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 batching yang tidak lebih buruk dari 4 mW.

• [C-2-11] HARUS memiliki sensor TYPE_STEP_COUNTER yang:

  • HARUS memiliki konsumsi daya tidak lebih buruk dari 0,5 mW saat perangkat statis dan 1,5 mW saat perangkat bergerak.

• [C-2-12] HARUS memiliki sensor TILT_DETECTOR yang:

  • HARUS memiliki konsumsi daya tidak lebih buruk dari 0,5 mW saat perangkat statis dan 1,5 mW saat perangkat bergerak.

• [C-2-13] Stempel waktu peristiwa dari peristiwa fisik yang sama yang dilaporkan oleh Akselerometer, Giroskop, dan Magnetometer HARUS berada dalam selisih 2,5 milidetik satu sama lain. Stempel waktu peristiwa fisik yang sama yang dilaporkan oleh Akselerometer dan Giroskop HARUS berada dalam 0,25 milidetik satu sama lain.

• [C-2-14] HARUS memiliki stempel waktu peristiwa sensor Giroskop pada basis waktu yang sama dengan subsistem kamera dan dengan error dalam 1 milidetik.

• [C-2-15] HARUS mengirimkan sampel ke aplikasi dalam waktu 5 milidetik sejak data tersedia di salah satu sensor fisik di atas ke aplikasi.

• [C-2-16] TIDAK BOLEH memiliki konsumsi daya lebih tinggi dari 0,5 mW saat perangkat statis dan 2,0 mW saat perangkat bergerak saat kombinasi sensor berikut diaktifkan:

  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS

• [C-2-17] MUNGKIN memiliki sensor TYPE_PROXIMITY, tetapi jika ada HARUS memiliki kemampuan buffer minimum 100 peristiwa sensor.

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

Jika penerapan perangkat mencakup dukungan sensor langsung, perangkat tersebut:

• [C-3-1] HARUS mendeklarasikan dukungan jenis saluran langsung dan tingkat rasio pelaporan langsung dengan benar melalui API isDirectChannelTypeSupported dan getHighestDirectReportRateLevel.

• [C-3-2] HARUS mendukung setidaknya salah satu dari dua jenis saluran langsung sensor untuk semua sensor yang menyatakan dukungan untuk saluran langsung sensor.

  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE

• HARUS mendukung pelaporan peristiwa melalui saluran langsung sensor untuk sensor utama (varian non-wake-up) dari jenis berikut:

  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Sensor Biometrik

Untuk mengetahui latar belakang tambahan tentang Mengukur Keamanan Buka Kunci Biometrik, lihat dokumentasi Mengukur Keamanan Biometrik.

Jika implementasi perangkat menyertakan layar kunci yang aman, maka:

• HARUS menyertakan sensor biometrik

Sensor biometrik dapat diklasifikasikan sebagai Class 3 (sebelumnya Kuat),

Class 2 (sebelumnya Lemah), atau Class 1 (sebelumnya Praktis) berdasarkan tingkat penerimaan penipuan dan pemalsuan mereka, serta keamanan pipeline biometrik. Klasifikasi ini menentukan kemampuan yang dimiliki sensor biometrik untuk berinteraksi dengan platform dan dengan aplikasi pihak ketiga. Sensor harus memenuhi persyaratan tambahan seperti yang dijelaskan di bawah jika ingin diklasifikasikan sebagai Kelas 1, Kelas 2, atau Kelas 3. Biometrik Class 2 dan Class 3 mendapatkan kemampuan tambahan seperti yang dijelaskan di bawah.

Jika implementasi perangkat menyediakan sensor biometrik untuk aplikasi pihak ketiga melalui android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt, dan android.provider.Settings.ACTION_BIOMETRIC_ENROLL, maka:

• [C-4-1] HARUS memenuhi persyaratan untuk biometrik Class 3 atau Class 2 seperti yang ditentukan dalam dokumen ini.

• [C-4-2] HARUS mengenali dan mematuhi setiap nama parameter yang ditentukan sebagai konstanta dalam class Authenticator dan kombinasi apa pun darinya. Sebaliknya, JANGAN mematuhi atau mengenali konstanta bilangan bulat yang diteruskan ke metode canAuthenticate(int) dan setAllowedAuthenticators(int) selain yang didokumentasikan sebagai konstanta publik di Authenticators dan kombinasi apa pun darinya.

• [C-4-3] HARUS mengimplementasikan tindakan ACTION_BIOMETRIC_ENROLL di perangkat yang memiliki biometrika Kelas 3 atau Kelas 2. Tindakan ini HANYA boleh menampilkan titik entri pendaftaran untuk biometrik Kelas 3 atau Kelas 2.

• [C-4-4] HARUS mengizinkan aplikasi menambahkan konten kustom ke BiometricPrompt menggunakan format tampilan konten PromptContentView. Format tampilan konten TIDAK BOLEH diperluas untuk memungkinkan gambar, link, konten interaktif, atau bentuk media lain yang belum menjadi bagian dari BiometricPrompt API. Penyesuaian gaya yang tidak mengubah, mengaburkan, atau memotong konten ini dapat dilakukan (seperti mengubah posisi, padding, margin, dan tipografi).

Jika penerapan perangkat mendukung biometrik pasif, perangkat tersebut:

• [C-5-1] HARUS secara default mewajibkan langkah konfirmasi tambahan (misalnya, menekan tombol).

• [C-SR-1] SANGAT DISARANKAN untuk memiliki setelan yang memungkinkan pengguna mengganti preferensi aplikasi dan selalu memerlukan langkah konfirmasi yang menyertainya.

• [C-SR-2] SANGAT DISARANKAN agar tindakan konfirmasi diamankan sehingga tidak dapat dipalsukan oleh kompromi sistem operasi atau kernel. Misalnya, ini berarti bahwa tindakan konfirmasi berdasarkan tombol fisik dirutekan melalui pin input/output (GPIO) serbaguna hanya input dari elemen aman (SE) yang tidak dapat didorong dengan cara lain selain penekanan tombol fisik.

• [C-5-2] HARUS juga menerapkan alur autentikasi implisit (tanpa langkah konfirmasi) yang sesuai dengan setConfirmationRequired(boolean), yang dapat ditetapkan aplikasi untuk digunakan dalam alur login.

Jika penerapan perangkat memiliki beberapa sensor biometrik, perangkat tersebut:

• [C-7-1] HARUS, saat biometrik dalam keadaan terkunci (yaitu biometrik dinonaktifkan hingga pengguna membuka kunci dengan autentikasi utama) atau terkunci karena batas waktu (yaitu biometrik dinonaktifkan sementara hingga pengguna menunggu interval waktu) karena terlalu banyak upaya yang gagal, juga mengunci semua biometrik lain dengan kelas biometrik yang lebih rendah. Dalam kasus penguncian terikat waktu, waktu backoff untuk verifikasi biometrik HARUS merupakan waktu backoff maksimum dari semua biometrik dalam penguncian terikat waktu.

• [C-SR-12] SANGAT DISARANKAN, saat biometrik terkunci (yaitu biometrik dinonaktifkan hingga pengguna membuka kunci dengan autentikasi utama) atau terkunci karena batas waktu (yaitu biometrik dinonaktifkan sementara hingga pengguna menunggu interval waktu) karena terlalu banyak upaya gagal, untuk juga mengunci semua biometrik lain dari class biometrik yang sama. Dalam kasus penguncian terbatas waktu, waktu mundur untuk verifikasi biometrik SANGAT DISARANKAN menjadi waktu mundur maksimum semua biometrik dalam penguncian terbatas waktu.

• [C-7-2] HARUS meminta pengguna untuk melakukan autentikasi utama yang direkomendasikan (seperti PIN, pola, atau sandi) untuk mereset penghitung penguncian jika biometrik dikunci. Biometrik Class 3 MUNGKIN diizinkan untuk mereset penghitung penguncian untuk biometrik terkunci dengan class yang sama atau lebih rendah. Biometrik Class 2 atau Class 1 TIDAK BOLEH diizinkan untuk menyelesaikan operasi penguncian ulang untuk biometrik apa pun.

• [C-SR-3] SANGAT DISARANKAN untuk hanya mewajibkan satu biometrik dikonfirmasi per autentikasi (misalnya, jika sensor sidik jari dan wajah tersedia di perangkat, onAuthenticationSucceeded harus dikirim setelah salah satunya dikonfirmasi).

Agar implementasi perangkat mengizinkan akses ke kunci keystore untuk aplikasi pihak ketiga, implementasi tersebut:

• [C-6-1] HARUS memenuhi persyaratan untuk Kelas 3 sebagaimana ditentukan dalam bagian di bawah ini.

• [C-6-2] HARUS menampilkan hanya biometrik Kelas 3 saat autentikasi memerlukan BIOMETRIC_STRONG, atau autentikasi dipanggil dengan CryptoObject.

Jika ingin memperlakukan sensor biometrik sebagai Class 1 (sebelumnya Convenience), implementasi perangkat harus:

• [C-1-1] HARUS memiliki rasio penerimaan salah kurang dari 0,002%.

• [C-1-2] HARUS mengungkapkan bahwa mode ini mungkin kurang aman dibandingkan dengan PIN, pola, atau sandi yang kuat dan mencantumkan dengan jelas risiko mengaktifkannya, jika tingkat penerimaan peniruan dan penipuan lebih tinggi dari 7% sebagaimana diukur oleh Protokol Pengujian Biometrik Android.

• [C-1-9] HARUS menantang pengguna untuk melakukan autentikasi utama yang direkomendasikan (misalnya, PIN, pola, sandi) setelah tidak lebih dari dua puluh percobaan gagal dan waktu tunggu tidak kurang dari sembilan puluh detik untuk verifikasi biometrik - dengan percobaan gagal adalah percobaan dengan kualitas pengambilan yang memadai (BIOMETRIC_ACQUIRED_GOOD) yang tidak cocok dengan biometrik yang terdaftar.

• [C-SR-4] SANGAT DISARANKAN untuk menurunkan jumlah total percobaan palsu untuk verifikasi biometrik yang ditentukan dalam [C-1-9] jika tingkat penerimaan spoof dan penipu lebih tinggi dari 7% sebagaimana diukur oleh Protokol Pengujian Biometrik Android.

• [C-1-3] HARUS membatasi laju percobaan verifikasi biometrik - dengan percobaan salah adalah percobaan dengan kualitas pengambilan yang memadai (BIOMETRIC_ACQUIRED_GOOD) yang tidak cocok dengan biometrik yang terdaftar.

• [C-SR-5] SANGAT DISARANKAN untuk membatasi laju percobaan selama minimal 30 detik setelah lima percobaan salah untuk verifikasi biometrik dengan jumlah maksimum percobaan salah per [C-1-9] - dengan percobaan salah adalah percobaan dengan kualitas pengambilan yang memadai (BIOMETRIC_ACQUIRED_GOOD) yang tidak cocok dengan biometrik yang terdaftar.

• [C-SR-6] SANGAT DISARANKAN untuk memiliki semua logika pembatasan kecepatan di TEE.

• [C-1-10] HARUS menonaktifkan biometrik setelah penundaan autentikasi utama dipicu terlebih dahulu seperti yang dijelaskan dalam [C-0-2] bagian 9.11.

• [C-1-11] HARUS memiliki tingkat penerimaan penipuan dan peniruan identitas tidak lebih tinggi dari 30%, dengan (1) tingkat penerimaan penipuan dan peniruan identitas untuk spesies instrumen serangan presentasi (PAI) Level A tidak lebih tinggi dari 30%, dan (2) tingkat penerimaan penipuan dan peniruan identitas spesies PAI Level B tidak lebih tinggi dari 40%, sebagaimana diukur oleh Protokol Pengujian Biometrik Android.

• [C-1-4] HARUS mencegah penambahan biometrik baru tanpa terlebih dahulu membuat rantai kepercayaan dengan meminta pengguna mengonfirmasi kredensial perangkat yang ada atau menambahkan kredensial perangkat baru (PIN/pola/sandi) yang diamankan oleh TEE; penerapan Android Open Source Project menyediakan mekanisme dalam framework untuk melakukannya.

• [C-1-5] HARUS menghapus sepenuhnya semua data biometrik yang dapat mengidentifikasi pengguna saat akun pengguna dihapus (termasuk melalui reset ke setelan pabrik) atau saat autentikasi utama yang direkomendasikan (seperti PIN, pola, sandi) dihapus.

• [C-1-6] HARUS mematuhi tanda individual untuk biometrik tersebut (yaitu DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE, atau DevicePolicymanager.KEYGUARD_DISABLE_IRIS).

• [C-1-7] HARUS meminta pengguna untuk melakukan autentikasi utama yang direkomendasikan (seperti PIN, pola, sandi) sekali setiap 24 jam atau kurang.

• [C-1-8] HARUS menantang pengguna untuk melakukan autentikasi utama yang direkomendasikan (seperti PIN, pola, sandi) atau biometrik Class 3 (KUAT) setelah salah satu hal berikut terjadi:

  • Periode waktu tunggu nonaktif 4 jam.
  • 3 upaya autentikasi biometrik yang gagal.
  • Periode waktu tunggu tidak ada aktivitas dan jumlah autentikasi yang gagal akan direset setelah konfirmasi kredensial perangkat berhasil.

• [C-SR-7] SANGAT DISARANKAN untuk menggunakan logika di framework yang disediakan oleh Android Open Source Project untuk menerapkan batasan yang ditentukan dalam [C-1-7] dan [C-1-8] untuk perangkat baru.

• [C-SR-8] SANGAT DISARANKAN untuk memiliki tingkat penolakan salah kurang dari 10%, sebagaimana diukur di perangkat.

• [C-SR-9] SANGAT DISARANKAN untuk memiliki latensi di bawah 1 detik, diukur dari saat biometrik terdeteksi, hingga layar tidak terkunci, untuk setiap biometrik yang terdaftar.

• [C-1-12] HARUS memiliki tingkat penerimaan peniruan dan pemalsuan tidak lebih tinggi dari 40% per spesies alat serangan presentasi (PAI), sebagaimana diukur oleh Protokol Pengujian Biometrik Android.

• [C-SR-13] SANGAT DISARANKAN untuk memiliki tingkat penerimaan penipuan dan peniruan identitas tidak lebih tinggi dari 30% per spesies instrumen serangan presentasi (PAI), sebagaimana diukur oleh Protokol Pengujian Biometrik Android.

• [C-SR-8] SANGAT DISARANKAN untuk memiliki tingkat penolakan salah kurang dari 10%, sebagaimana diukur di perangkat.

• [C-1-15] HARUS mengizinkan pengguna menghapus pendaftaran biometrik tunggal atau ganda.

• [C-SR-14] SANGAT DISARANKAN untuk mengungkapkan kelas biometrik sensor biometrik dan risiko yang sesuai jika mengaktifkannya.

• [C-SR-17] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan antarmuka AIDL baru (seperti, IFace.aidl dan IFingerprint.aidl).

Jika implementasi perangkat ingin memperlakukan sensor biometrik sebagai Class 2 (sebelumnya Lemah), maka:

• [C-2-1] HARUS memenuhi semua persyaratan untuk Kelas 1 di atas.

• [C-2-2] HARUS memiliki tingkat penerimaan penipuan dan peniruan identitas tidak lebih tinggi dari 20%, dengan (1) tingkat penerimaan penipuan dan peniruan identitas untuk spesies instrumen serangan presentasi (PAI) Level A tidak lebih tinggi dari 20%, dan (2) tingkat penerimaan penipuan dan peniruan identitas spesies PAI Level B tidak lebih tinggi dari 30%, sebagaimana diukur oleh Protokol Pengujian Biometrik Android.

• [C-SR-15] SANGAT DISARANKAN untuk memiliki tingkat penerimaan peniruan dan penipu tidak lebih tinggi dari 20% per spesies instrumen serangan presentasi (PAI), sebagaimana diukur oleh Protokol Pengujian Biometrik Android.

• [C-2-3] HARUS melakukan pencocokan biometrik di lingkungan eksekusi terisolasi di luar ruang pengguna atau kernel Android, seperti Trusted Execution Environment (TEE), pada chip dengan saluran aman ke lingkungan eksekusi terisolasi atau pada Protected Virtual Machine yang memenuhi persyaratan dalam Bagian 9.17.

• [C-2-4] HARUS mengenkripsi semua data yang dapat diidentifikasi dan mengautentikasi secara kriptografis sehingga data tersebut tidak dapat diperoleh, dibaca, atau diubah di luar lingkungan eksekusi terisolasi atau chip dengan saluran aman ke lingkungan eksekusi terisolasi seperti yang didokumentasikan dalam pedoman penerapan di situs Android Open Source Project atau Mesin Virtual yang Dilindungi yang dikontrol oleh hypervisor yang memenuhi persyaratan dalam Pasal 9.17.

• [C-2-5] Untuk biometrik berbasis kamera, saat autentikasi atau pendaftaran berbasis biometrik sedang terjadi:

  • HARUS mengoperasikan kamera dalam mode yang mencegah frame kamera dibaca atau diubah di luar lingkungan eksekusi yang terisolasi atau chip dengan saluran aman ke lingkungan eksekusi yang terisolasi atau Mesin Virtual yang Dilindungi yang dikontrol oleh hypervisor yang memenuhi persyaratan dalam Bagian 9.17.

  • Untuk solusi kamera tunggal RGB, frame kamera DAPAT dibaca di luar lingkungan eksekusi terisolasi untuk mendukung operasi seperti pratinjau untuk pendaftaran, tetapi TETAP TIDAK BOLEH diubah.

• [C-2-6] TIDAK BOLEH mengizinkan aplikasi pihak ketiga untuk membedakan pendaftaran biometrik individu.

• [C-2-7] TIDAK BOLEH mengizinkan akses yang tidak dienkripsi ke data biometrik yang dapat diidentifikasi atau data apa pun yang berasal darinya (seperti penyematan) ke Prosesor Aplikasi di luar konteks TEE atau Mesin Virtual yang Dilindungi yang dikontrol oleh hypervisor yang memenuhi persyaratan dalam Bagian 9.17. Mengupgrade perangkat yang diluncurkan di Android versi 9 atau yang lebih lama tidak dikecualikan dari [C-2-7].

• [C-2-8] HARUS memiliki pipeline pemrosesan yang aman sehingga kompromi sistem operasi atau kernel tidak dapat memungkinkan data disuntikkan secara langsung untuk melakukan autentikasi palsu sebagai pengguna.

• [C-SR-10] SANGAT DISARANKAN untuk menyertakan deteksi keaktifan untuk semua modalitas biometrik dan deteksi perhatian untuk Biometrik wajah.

• [C-2-9] HARUS menyediakan sensor biometrik untuk aplikasi pihak ketiga.

Jika implementasi perangkat ingin memperlakukan sensor biometrik sebagai Class 3 (sebelumnya Kuat), maka:

• [C-3-1] HARUS memenuhi semua persyaratan Kelas 2 di atas, kecuali [C-1-7] dan [C-1-8].

• [C-3-2] HARUS memiliki implementasi keystore yang didukung hardware.

• [C-3-3] HARUS memiliki tingkat penerimaan penipuan dan peniruan identitas tidak lebih tinggi dari 7%, dengan (1) tingkat penerimaan penipuan dan peniruan identitas untuk spesies instrumen serangan presentasi (PAI) Level A tidak lebih tinggi dari 7%, dan (2) tingkat penerimaan penipuan dan peniruan identitas spesies PAI Level B tidak lebih tinggi dari 20%, sebagaimana diukur oleh Protokol Pengujian Biometrik Android.

• [C-3-4] HARUS menantang pengguna untuk melakukan autentikasi utama yang direkomendasikan (seperti PIN, pola, sandi) sekali setiap 72 jam atau kurang.

• [C-3-5] HARUS membuat ulang ID Pengautentikasi untuk semua biometrik Kelas 3 yang didukung di perangkat jika salah satunya didaftarkan ulang.

• [C-3-6] Harus mengaktifkan kunci keystore yang didukung biometrik untuk aplikasi pihak ketiga.

• [C-SR-16] SANGAT DIREKOMENDASIKAN untuk memiliki tingkat penerimaan peniruan dan penipu tidak lebih tinggi dari 7% per spesies instrumen serangan presentasi (PAI), sebagaimana diukur oleh Protokol Pengujian Biometrik Android.

Jika implementasi perangkat berisi sensor sidik jari di bawah layar (UDFPS), perangkat tersebut:

• [C-SR-11] SANGAT DISARANKAN untuk mencegah area yang dapat disentuh UDFPS mengganggu navigasi 3 tombol (yang mungkin diperlukan oleh beberapa pengguna untuk tujuan aksesibilitas).

7.3.11. Sensor Pose

Implementasi perangkat:

• MAY mendukung sensor postur dengan 6 derajat kebebasan.

Jika implementasi perangkat mendukung sensor postur dengan 6 derajat kebebasan, maka:

• [C-1-1] HARUS menerapkan dan melaporkan TYPE_POSE_6DOF sensor.

• [C-1-2] HARUS lebih akurat daripada vektor rotasi saja.

7.3.12. Sensor Sudut Engsel

Jika penerapan perangkat mendukung sensor sudut engsel, perangkat tersebut:

• [C-1-1] HARUS menerapkan dan melaporkan TYPE_HINGE_ANGLE.

• [C-1-2] HARUS mendukung setidaknya dua pembacaan antara 0 dan 360 derajat (inklusif, yaitu termasuk 0 dan 360 derajat).

• [C-1-3] HARUS menampilkan sensor aktivasi untuk getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

7.3.13. IEEE 802.1.15.4 (UWB)

Jika implementasi perangkat mencakup dukungan untuk 802.1.15.4 dan mengekspos fungsi ke aplikasi pihak ketiga, maka:

• [C-1-2] HARUS melaporkan flag fitur hardware android.hardware.uwb.

• [C-1-3] HARUS mendukung semua set konfigurasi berikut (kombinasi parameter FIRA UCI yang telah ditentukan sebelumnya) yang ditentukan dalam penerapan AOSP.

  • CONFIG_ID_1: Pengukuran jarak STATIC STS DS-TWR unicast yang ditentukan FiRa, mode yang ditangguhkan, interval pengukuran jarak 240 md.

  • CONFIG_ID_2: Pengukuran jarak STATIC STS DS-TWR satu ke banyak yang ditentukan FiRa, mode tertunda, interval pengukuran jarak 200 md. Kasus penggunaan umum: smartphone berinteraksi dengan banyak perangkat smart.

  • CONFIG_ID_3: Sama seperti CONFIG_ID_1, kecuali data Angle-of-arrival (AoA) tidak dilaporkan.

  • CONFIG_ID_4: Sama seperti CONFIG_ID_1, kecuali mode keamanan P-STS diaktifkan.

  • CONFIG_ID_5: Sama seperti CONFIG_ID_2, kecuali mode keamanan P-STS diaktifkan.

  • CONFIG_ID_6: Sama seperti CONFIG_ID_3, kecuali mode keamanan P-STS diaktifkan.

  • CONFIG_ID_7: Sama seperti CONFIG_ID_2, kecuali mode kunci penerima kontrol individu P-STS diaktifkan.

• [C-1-4] HARUS menyediakan kemampuan pengguna untuk mengizinkan pengguna mengaktifkan/menonaktifkan status radio UWB.

• [C-1-5] HARUS memastikan bahwa aplikasi yang menggunakan radio UWB memiliki izin UWB_RANGING (dalam grup izin NEARBY_DEVICES).

Lulus pengujian kesesuaian dan sertifikasi yang relevan yang ditentukan oleh organisasi standar, termasuk FIRA, CCC, dan CSA, membantu memastikan fungsi 802.1.15.4 dengan benar.

7.3.14. Sensor kustom

Untuk membantu memberikan pengalaman yang berbeda, implementasi perangkat DAPAT menyertakan sensor tambahan yang tidak tercakup oleh Android atau Wear OS, yang dapat diakses oleh aplikasi yang sudah dimuat sebelumnya.

Untuk sensor tersebut, ID sensor:

• [C-0-1] HARUS lebih tinggi dari 65536.

Jika sensor kustom ditujukan untuk tujuan terkait kesehatan atau kebugaran, sensor tersebut:

• [C-0-2] HARUS dilindungi oleh izin platform atau izin sistem.

7.4. Konektivitas Data

7.4.1. Telepon

"Telepon" sebagaimana digunakan oleh Android API dan dokumen ini secara khusus merujuk pada hardware yang terkait dengan melakukan panggilan suara dan mengirim pesan SMS, atau membuat koneksi data seluler melalui jaringan GSM atau CDMA seluler (misalnya, GSM, CDMA, LTE, NR). Perangkat yang mendukung "Telepon" dapat memilih untuk menawarkan sebagian atau semua layanan panggilan, pesan, dan data sesuai dengan produknya.

• Android DAPAT digunakan di perangkat yang tidak menyertakan hardware telepon. Artinya, Android kompatibel dengan perangkat selain ponsel.

Jika implementasi perangkat mencakup telepon GSM atau CDMA, maka:

• [C-1-1] HARUS mendeklarasikan flag fitur android.hardware.telephony dan flag sub-fitur lainnya sesuai dengan teknologi.

• [C-1-2] HARUS menerapkan dukungan penuh untuk API teknologi tersebut.

• HARUS mengizinkan semua jenis layanan seluler yang tersedia (2G, 3G, 4G, 5G, dll.) selama panggilan darurat (terlepas dari jenis jaringan yang ditetapkan oleh SetAllowedNetworkTypeBitmap()).

Jika implementasi perangkat tidak menyertakan hardware teleponi, perangkat tersebut:

• [C-2-1] HARUS menerapkan API lengkap sebagai operasi no-op.

Jika implementasi perangkat mendukung eUICC atau eSIM/SIM tersemat dan menyertakan mekanisme eksklusif untuk menyediakan fungsi eSIM bagi developer pihak ketiga, implementasi tersebut:

• [C-3-1] HARUS mendeklarasikan flag fitur android.hardware.telephony.euicc.

Jika implementasi perangkat tidak menyetel properti sistem ro.telephony.iwlan_operation_mode ke legacy, maka:

• [C-4-1] TIDAK BOLEH melaporkan NETWORK_TYPE_IWLAN melalui NetworkRegistrationInfo#getAccessNetworkTechnology() jika NetworkRegistrationInfo#getTransportType() dilaporkan sebagai TRANSPORT_TYPE_WWAN untuk instance NetworkRegistrationInfo yang sama.

Jika implementasi perangkat mendukung pendaftaran IP Multimedia Subsystem (IMS) tunggal untuk fitur layanan telepon multimedia (MMTEL) dan rich communication service (RCS) serta diharapkan mematuhi persyaratan operator seluler terkait penggunaan pendaftaran IMS tunggal untuk semua traffic pensinyalan IMS, maka:

• [C-5-1] HARUS mendeklarasikan tanda fitur android.hardware.telephony.ims dan memberikan penerapan lengkap ImsService API untuk MMTEL dan RCS User Capability Exchange API.

• [C-5-2] HARUS mendeklarasikan flag fitur android.hardware.telephony.ims.singlereg dan memberikan penerapan lengkap SipTransport API, GbaService API, indikasi pembawa khusus menggunakan IRadio 1.6 HAL, dan penyediaan melalui Auto Configuration Server (ACS) atau mekanisme penyediaan eksklusif lainnya menggunakan IMS Configuration API.

Jika implementasi perangkat melaporkan fitur android.hardware.telephony, maka:

• [C-6-1] SmsManager#sendTextMessage dan SmsManager#sendMultipartTextMessage HARUS menghasilkan panggilan yang sesuai ke CarrierMessagingService untuk menyediakan fungsi pesan teks. SmsManager#sendMultimediaMessage dan SmsManager#downloadMultimediaMessage HARUS menghasilkan panggilan yang sesuai ke CarrierMessagingService untuk menyediakan fungsi pesan multimedia.

• [C-6-2] Aplikasi yang ditetapkan oleh android.provider.Telephony.Sms#getDefaultSmsPackage HARUS menggunakan API SmsManager saat mengirim dan menerima pesan SMS dan MMS. Implementasi referensi AOSP di packages/apps/Messaging memenuhi persyaratan ini.

• [C-6-3] Aplikasi yang merespons Intent#ACTION_DIAL HARUS mendukung entri kode dialer arbitrer yang diformat sebagai *#*#CODE#*#* dan memicu siaran TelephonyManager#ACTION_SECRET_CODE yang sesuai.

• [C-6-4] Aplikasi yang merespons Intent#ACTION_DIAL HARUS menggunakan VoicemailContract.Voicemails#TRANSCRIPTION untuk menampilkan transkripsi pesan suara visual kepada pengguna jika mendukung transkripsi pesan suara visual.

• [C-6-5] HARUS menampilkan semua SubscriptionInfo dengan UUID grup yang setara sebagai satu langganan di semua penawaran yang terlihat oleh pengguna yang menampilkan dan mengontrol informasi kartu SIM. Contoh kemampuan tersebut mencakup antarmuka setelan yang cocok dengan Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS atau EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS.

• [C-6-6] TIDAK BOLEH menampilkan atau mengizinkan kontrol SubscriptionInfo apa pun dengan UUID grup non-null dan bit oportunistik dalam penawaran yang terlihat pengguna yang mengizinkan konfigurasi atau kontrol setelan kartu SIM.

Jika implementasi perangkat melaporkan fitur android.hardware.telephony dan menyediakan status bar sistem, maka:

• [C-7-1] HARUS memilih langganan aktif yang representatif untuk UUID grup tertentu untuk ditampilkan kepada pengguna di setiap penawaran yang memberikan informasi status SIM. Contoh kemampuan tersebut mencakup ikon sinyal seluler status bar atau tile setelan cepat.

• [C-SR-1] SANGAT DISARANKAN agar langganan perwakilan dipilih sebagai langganan data aktif kecuali jika perangkat sedang melakukan panggilan suara, yang selama itu SANGAT DISARANKAN agar langganan perwakilan adalah langganan suara aktif.

Jika implementasi perangkat melaporkan fitur android.hardware.telephony, maka:

• [C-6-7] HARUS dapat membuka dan menggunakan secara bersamaan jumlah maksimum saluran logis (total 20) untuk setiap UICC per ETSI TS 102 221.

• [C-6-8] TIDAK BOLEH menerapkan perilaku berikut ke aplikasi operator aktif (sebagaimana ditetapkan oleh TelephonyManager#getCarrierServicePackageName) secara otomatis atau tanpa konfirmasi eksplisit dari pengguna:

  • Mencabut atau membatasi akses jaringan
  • Mencabut izin
  • Membatasi eksekusi aplikasi di latar belakang atau latar depan di luar fitur pengelolaan daya yang ada yang disertakan dalam AOSP
  • Menonaktifkan atau meng-uninstal aplikasi

Jika penerapan perangkat melaporkan fitur android.hardware.telephony dan semua langganan aktif, non-oportunistik yang berbagi UUID grup dinonaktifkan, dihapus secara fisik dari perangkat, atau ditandai sebagai oportunistik, maka perangkat:

• [C-8-1] HARUS otomatis menonaktifkan semua langganan oportunistis aktif yang tersisa dalam grup yang sama.

Jika penerapan perangkat mencakup telepon GSM, tetapi tidak mencakup telepon CDMA, maka:

• [C-9-1] TIDAK BOLEH mendeklarasikan PackageManager#FEATURE_TELEPHONY_CDMA.

• [C-9-2] HARUS menampilkan IllegalArgumentException saat mencoba menyetel jenis jaringan 3GPP2 apa pun dalam bitmask jenis jaringan pilihan atau yang diizinkan.

• [C-9-3] HARUS menampilkan string kosong dari TelephonyManager#getMeid.

Jika penerapan perangkat mendukung eUICC dengan beberapa port dan profil, perangkat tersebut:

• [C-10-1] HARUS mendeklarasikan flag fitur android.hardware.telephony.euicc.mep.

7.4.1.1. Kompatibilitas Pemblokiran Nomor

Jika implementasi perangkat melaporkan fitur android.hardware.telephony.calling, maka:

• [C-1-1] HARUS menyertakan dukungan pemblokiran nomor

• [C-1-2] HARUS menerapkan BlockedNumberContract dan API yang sesuai sepenuhnya seperti yang dijelaskan dalam dokumentasi SDK.

• [C-1-3] HARUS memblokir semua panggilan dan pesan dari nomor telepon di BlockedNumberProvider tanpa interaksi apa pun dengan aplikasi. Satu-satunya pengecualian adalah saat pemblokiran nomor dicabut untuk sementara seperti yang dijelaskan dalam dokumentasi SDK.

• [C-1-4] HARUS menulis ke penyedia log panggilan platform untuk panggilan yang diblokir dan HARUS memfilter panggilan dengan BLOCKED_TYPE dari tampilan log panggilan default di aplikasi dialer bawaan.

• [C-1-5] TIDAK BOLEH menulis ke Penyedia layanan telepon untuk pesan yang diblokir.

• [C-1-6] HARUS menerapkan UI pengelolaan nomor yang diblokir, yang dibuka dengan intent yang ditampilkan oleh metode TelecomManager.createManageBlockedNumbersIntent().

• [C-1-7] TIDAK BOLEH mengizinkan pengguna sekunder melihat atau mengedit nomor yang diblokir di perangkat karena platform Android mengasumsikan pengguna utama memiliki kontrol penuh atas layanan telepon, satu instance, di perangkat. Semua UI terkait pemblokiran HARUS disembunyikan untuk pengguna sekunder dan daftar yang diblokir HARUS tetap dipatuhi.

• HARUS memigrasikan nomor yang diblokir ke penyedia saat perangkat diupdate ke Android 7.0.

• HARUS menyediakan kemudahan pengguna untuk menampilkan panggilan yang diblokir di aplikasi dialer yang sudah diinstal sebelumnya.

7.4.1.2. Telecom API

Jika implementasi perangkat melaporkan android.hardware.telephony.calling, berarti perangkat tersebut:

• [C-1-1] HARUS mendukung API ConnectionService yang dijelaskan dalam SDK.

• [C-1-2] HARUS menampilkan panggilan masuk baru dan memberikan kemudahan pengguna untuk menerima atau menolak panggilan masuk saat pengguna sedang melakukan panggilan berlangsung yang dilakukan oleh aplikasi pihak ketiga yang tidak mendukung fitur tahan yang ditentukan melalui CAPABILITY_SUPPORT_HOLD.

• [C-1-3] HARUS memiliki aplikasi yang menerapkan InCallService.

• [C-SR-1] SANGAT DISARANKAN untuk memberi tahu pengguna bahwa menjawab panggilan masuk akan mengakhiri panggilan yang sedang berlangsung.

  Implementasi AOSP memenuhi persyaratan ini dengan notifikasi pendahuluan yang menunjukkan kepada pengguna bahwa menjawab panggilan masuk akan menyebabkan panggilan lain dihentikan.

• [C-SR-2] SANGAT DISARANKAN untuk memuat aplikasi dialer default yang menampilkan entri log panggilan dan nama aplikasi pihak ketiga di log panggilannya saat aplikasi pihak ketiga menyetel kunci ekstra EXTRA_LOG_SELF_MANAGED_CALLS di PhoneAccount-nya ke true.

• [C-SR-3] SANGAT DISARANKAN untuk menangani peristiwa KEYCODE_MEDIA_PLAY_PAUSE dan KEYCODE_HEADSETHOOK headset audio untuk API android.telecom seperti di bawah:

  • Panggil Connection.onDisconnect() saat penekanan singkat peristiwa tombol terdeteksi selama panggilan sedang berlangsung.

  • Panggil Connection.onAnswer() saat penekanan singkat peristiwa tombol terdeteksi selama panggilan masuk.

  • Panggil Connection.onReject() saat tombol ditekan lama selama panggilan masuk.

  • Mengalihkan status nonaktif CallAudioState.

7.4.1.3. Offload Keepalive NAT-T Seluler

Implementasi perangkat:

• HARUS mencakup dukungan untuk offload keepalive seluler.

Jika implementasi perangkat mencakup dukungan untuk pengalihan nonaktif keepalive seluler dan mengekspos fungsi ke aplikasi pihak ketiga, maka:

• [C-1-1] HARUS mendukung SocketKeepAlive API.

• [C-1-2] HARUS mendukung setidaknya satu slot keepalive serentak melalui seluler.

• [C-1-3] HARUS mendukung sebanyak mungkin slot keepalive seluler serentak yang didukung oleh HAL Radio Seluler.

• [C-SR-1] SANGAT DISARANKAN untuk mendukung minimal tiga slot tetap aktif seluler per instance radio.

Jika implementasi perangkat tidak menyertakan dukungan untuk offload keepalive seluler, maka:

• [C-2-1] HARUS menampilkan ERROR_UNSUPPORTED.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementasi perangkat:

• HARUS mencakup dukungan untuk satu atau beberapa bentuk 802.11.

Jika implementasi perangkat mencakup dukungan untuk 802.11 dan mengekspos fungsi ke aplikasi pihak ketiga, maka:

• [C-1-1] HARUS menerapkan Android API yang sesuai.

• [C-1-2] HARUS melaporkan flag fitur hardware android.hardware.wifi.

• [C-1-3] HARUS menerapkan multicast API seperti yang dijelaskan dalam dokumentasi SDK.

• [C-1-4] HARUS mendukung mDNS dan TIDAK BOLEH memfilter paket mDNS (224.0.0.251 atau ff02::fb) kapan saja selama pengoperasian, termasuk saat layar tidak dalam status aktif, kecuali jika kunci multicast tidak dipegang dan paket difilter oleh APF. Paket tidak diperlukan untuk memenuhi operasi mDNS yang saat ini diminta oleh aplikasi melalui API NsdManager. Namun, perangkat DAPAT memfilter paket mDNS jika hal tersebut diperlukan agar tetap berada dalam rentang konsumsi daya yang diperlukan oleh persyaratan peraturan yang berlaku untuk target pasar.

• [C-1-5] TIDAK BOLEH memperlakukan panggilan metode API WifiManager.enableNetwork() sebagai indikasi yang cukup untuk mengganti Network yang saat ini aktif yang digunakan secara default untuk traffic aplikasi dan ditampilkan oleh metode API ConnectivityManager seperti getActiveNetwork dan registerDefaultNetworkCallback. Dengan kata lain, aplikasi HANYA DAPAT menonaktifkan akses Internet yang disediakan oleh penyedia jaringan lain (misalnya, data seluler) jika berhasil memvalidasi bahwa jaringan Wi-Fi menyediakan akses Internet.

• [C-1-6] SANGAT DISARANKAN untuk, saat metode ConnectivityManager.reportNetworkConnectivity() API dipanggil, mengevaluasi ulang akses Internet di Network dan, setelah evaluasi menentukan bahwa Network saat ini tidak lagi menyediakan akses Internet, beralih ke jaringan lain yang tersedia (misalnya, data seluler) yang menyediakan akses Internet.

• [C-1-7] HARUS mengacak alamat MAC sumber dan nomor urut frame permintaan probe, sekali di awal setiap pemindaian, saat STA terputus.

• [C-1-8] HARUS menggunakan satu alamat MAC yang konsisten (SEBAIKNYA TIDAK mengacak alamat MAC di tengah pemindaian).

• [C-1-9] HARUS mengulangi nomor urut permintaan probe seperti biasa (secara berurutan) di antara permintaan probe dalam pemindaian.

• [C-1-10] HARUS mengacak nomor urut permintaan Probe antara permintaan probe terakhir dari pemindaian dan permintaan probe pertama dari pemindaian berikutnya.

• [C-SR-1] SANGAT DISARANKAN untuk mengacak alamat MAC sumber yang digunakan untuk semua komunikasi STA ke Access Point (AP) saat mengaitkan dan terkait.

  • Perangkat HARUS menggunakan alamat MAC acak yang berbeda untuk setiap SSID (FQDN untuk Passpoint) yang berkomunikasi dengannya.

  • Perangkat HARUS memberi pengguna opsi untuk mengontrol pengacakan per SSID (FQDN untuk Passpoint) dengan opsi yang tidak diacak dan diacak, dan HARUS menyetel mode default untuk konfigurasi Wi-Fi baru menjadi diacak.

• [C-SR-2] SANGAT DISARANKAN untuk menggunakan BSSID acak untuk AP apa pun yang mereka buat.

  • Alamat MAC HARUS diacak dan dipertahankan per SSID yang digunakan oleh AP.

  • PERANGKAT DAPAT memberi pengguna opsi untuk menonaktifkan fitur ini. Jika opsi tersebut disediakan, pengacakan HARUS diaktifkan secara default.

Jika implementasi perangkat mencakup dukungan untuk mode hemat daya Wi-Fi sebagaimana ditentukan dalam standar IEEE 802.11, perangkat tersebut:

• HARUS menonaktifkan mode hemat daya Wi-Fi setiap kali aplikasi mendapatkan kunci WIFI_MODE_FULL_HIGH_PERF atau kunci WIFI_MODE_FULL_LOW_LATENCY melalui API WifiManager.createWifiLock() danWifiManager.WifiLock.acquire() dan kunci aktif.

• [C-3-2] Latensi pulang pergi rata-rata antara perangkat dan titik akses saat perangkat berada dalam mode Penguncian Latensi Rendah Wi-Fi (WIFI_MODE_FULL_LOW_LATENCY) HARUS lebih kecil daripada latensi selama mode Penguncian Performa Tinggi Wi-Fi (WIFI_MODE_FULL_HIGH_PERF).

• [C-SR-3] SANGAT DISARANKAN untuk meminimalkan latensi perjalanan pulang pergi Wi-Fi setiap kali Kunci Latensi Rendah (WIFI_MODE_FULL_LOW_LATENCY) diperoleh dan diterapkan.

Jika implementasi perangkat mendukung Wi-Fi dan menggunakan Wi-Fi untuk pemindaian lokasi, perangkat tersebut:

• [C-2-1] HARUS menyediakan kemudahan pengguna untuk mengaktifkan/menonaktifkan pembacaan nilai melalui metode API WifiManager.isScanAlwaysAvailable.

7.4.2.1. Wi-Fi Direct

Implementasi perangkat:

• HARUS menyertakan dukungan untuk Wi-Fi Direct (Wi-Fi peer-to-peer).

Jika penerapan perangkat mencakup dukungan untuk Wi-Fi Direct, perangkat tersebut:

• [C-1-1] HARUS menerapkan Android API yang sesuai seperti yang dijelaskan dalam dokumentasi SDK.

• [C-1-2] HARUS melaporkan fitur hardware android.hardware.wifi.direct.

• [C-1-3] HARUS mendukung operasi Wi-Fi reguler.

• [C-1-4] HARUS mendukung operasi Wi-Fi dan Wi-Fi Direct secara bersamaan.

• [C-SR-1] SANGAT DISARANKAN untuk mengacak alamat MAC sumber untuk semua koneksi Wi-Fi Direct yang baru terbentuk.

7.4.2.2. Penyiapan Wi-Fi Tunneled Direct Link

Implementasi perangkat:

• HARUS menyertakan dukungan untuk Penyiapan Link Langsung yang Ditunnelkan Wi-Fi (TDLS) seperti yang dijelaskan dalam Dokumentasi Android SDK.

Jika implementasi perangkat menyertakan dukungan untuk TDLS dan TDLS diaktifkan oleh WiFiManager API, maka:

• [C-1-1] HARUS mendeklarasikan dukungan untuk TDLS melalui WifiManager.isTdlsSupported.

• HARUS menggunakan TDLS hanya jika memungkinkan DAN bermanfaat.

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

7.4.2.3. Wi-Fi Aware

Implementasi perangkat:

• HARUS menyertakan dukungan untuk Wi-Fi Aware.

Jika implementasi perangkat mencakup dukungan untuk Wi-Fi Aware dan mengekspos fungsi ke aplikasi pihak ketiga, maka:

• [C-1-1] HARUS menerapkan API WifiAwareManager seperti yang dijelaskan dalam dokumentasi SDK.

• [C-1-2] HARUS mendeklarasikan flag fitur android.hardware.wifi.aware.

• [C-1-3] HARUS mendukung operasi Wi-Fi dan Wi-Fi Aware secara bersamaan.

• [C-1-4] HARUS mengacak alamat antarmuka pengelolaan Wi-Fi Aware pada interval tidak lebih dari 30 menit dan setiap kali Wi-Fi Aware diaktifkan, kecuali jika operasi pengukuran jarak Aware sedang berlangsung atau jalur data Aware aktif (pengacakan tidak diharapkan selama jalur data aktif).

Jika implementasi perangkat menyertakan dukungan untuk Wi-Fi Aware dan Wi-Fi Location seperti yang dijelaskan dalam Bagian 7.4.2.5 dan mengekspos fungsi ini ke aplikasi pihak ketiga, maka:

• [C-2-1] HARUS menerapkan API penemuan yang mengetahui lokasi: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm, dan onServiceDiscoveredWithinRange.

7.4.2.4. Passpoint Wi-Fi

Jika implementasi perangkat mencakup dukungan untuk 802.11 (Wi-Fi), maka:

• HARUS mencakup dukungan untuk Wi-Fi Passpoint.

Jika implementasi perangkat mencakup dukungan untuk Wi-Fi Passpoint, maka:

• [C-1-2] HARUS mengimplementasikan API WifiManager terkait Passpoint seperti yang dijelaskan dalam dokumentasi SDK.

• [C-1-3] HARUS mendukung standar IEEE 802.11u, khususnya terkait dengan Penemuan dan Pemilihan Jaringan, seperti Generic Advertisement Service (GAS) dan Access Network Query Protocol (ANQP).

• [C-1-4] HARUS mendeklarasikan tanda fitur android.hardware.wifi.passpoint.

• [C-1-5] HARUS mengikuti penerapan AOSP untuk menemukan, mencocokkan, dan mengaitkan ke jaringan Passpoint.

• [C-1-6] HARUS mendukung setidaknya subset protokol penyediaan perangkat berikut sebagaimana ditentukan dalam Passpoint R2 Wi-Fi Alliance: autentikasi EAP-TTLS dan SOAP-XML.

• [C-1-7] HARUS memproses sertifikat server AAA seperti yang dijelaskan dalam spesifikasi Hotspot 2.0 R3.

• [C-1-8] HARUS mendukung kontrol pengguna atas penyediaan melalui pemilih Wi-Fi.

• [C-1-9] HARUS mempertahankan konfigurasi Passpoint tetap ada setelah perangkat dimulai ulang.

• [C-SR-1] SANGAT DISARANKAN untuk mendukung fitur persetujuan persyaratan dan ketentuan.

• [C-SR-2] SANGAT DISARANKAN untuk mendukung fitur informasi Tempat.

Jika tombol kontrol pengguna nonaktif Passpoint global disediakan, penerapan:

• [C-3-1] HARUS mengaktifkan Passpoint secara default.

7.4.2.5. Lokasi Wi-Fi (Wi-Fi Round Trip Time - RTT)

Implementasi perangkat:

• HARUS mencakup dukungan untuk Lokasi Wi-Fi.

Jika penerapan perangkat mencakup dukungan untuk Lokasi Wi-Fi dan mengekspos fungsi ke aplikasi pihak ketiga, maka:

• [C-1-1] HARUS menerapkan API WifiRttManager seperti yang dijelaskan dalam dokumentasi SDK.

• [C-1-2] HARUS mendeklarasikan flag fitur android.hardware.wifi.rtt.

• [C-1-3] HARUS mengacak alamat MAC sumber untuk setiap burst RTT yang dieksekusi saat antarmuka Wi-Fi tempat RTT dieksekusi tidak dikaitkan ke Titik Akses.

• [C-1-4] HARUS akurat dalam jarak 2 meter pada bandwidth 80 MHz pada persentil ke-68 (seperti yang dihitung dengan Fungsi Distribusi Kumulatif).

• [C-SR-1] SANGAT DISARANKAN untuk melaporkannya secara akurat dalam jarak 1,5 meter pada bandwidth 80 MHz pada persentil ke-68 (seperti yang dihitung dengan Fungsi Distribusi Kumulatif).

7.4.2.6. Offload Keepalive Wi-Fi

Implementasi perangkat:

• HARUS mencakup dukungan untuk offload keepalive Wi-Fi.

Jika penerapan perangkat mencakup dukungan untuk offload keepalive Wi-Fi dan mengekspos fungsi ke aplikasi pihak ketiga, maka:

• [C-1-1] HARUS mendukung SocketKeepAlive API.

• [C-1-2] HARUS mendukung minimal tiga slot keep-alive serentak melalui Wi-Fi

Jika implementasi perangkat tidak menyertakan dukungan untuk offload aktif Wi-Fi, maka:

• [C-2-1] HARUS menampilkan ERROR_UNSUPPORTED.

7.4.2.7. Wi-Fi Easy Connect (Protokol Penyediaan Perangkat)

Implementasi perangkat:

• HARUS menyertakan dukungan untuk Wi-Fi Easy Connect (DPP).

Jika penerapan perangkat mencakup dukungan untuk Wi-Fi Easy Connect dan mengekspos fungsi ke aplikasi pihak ketiga, perangkat tersebut:

• [C-1-1] HARUS membuat metode WifiManager#isEasyConnectSupported() menampilkan true.

7.4.2.8. Validasi Sertifikat Server Wi-Fi Perusahaan

Jika sertifikat server Wi-Fi tidak divalidasi atau nama domain server Wi-Fi tidak ditetapkan, implementasi perangkat:

• [C-SR-1] SANGAT DISARANKAN untuk tidak memberi pengguna opsi untuk menambahkan jaringan Wi-Fi Enterprise secara manual di aplikasi Setelan.

7.4.2.9. Percayai pada Penggunaan Pertama (TOFU)

Jika implementasi perangkat mendukung Trust on first usage (TOFU) dan mengizinkan pengguna menentukan konfigurasi WPA/WPA2/WPA3-Enterprise, maka:

• [C-4-1] HARUS memberi pengguna opsi untuk memilih menggunakan TOFU.

7.4.2.10. Deteksi Kedekatan Wi-Fi

7.4.3. Bluetooth

Jika implementasi perangkat mendukung profil Audio Bluetooth, perangkat tersebut:

• HARUS mendukung Codec Audio Lanjutan dan Codec Audio Bluetooth (misalnya, LDAC).

Jika implementasi perangkat mendukung HFP, A2DP, dan AVRCP, maka:

• HARUS mendukung total minimal 5 perangkat yang terhubung.

Jika implementasi perangkat mendeklarasikan fitur android.hardware.vr.high_performance, maka:

• [C-1-1] HARUS mendukung Bluetooth 4.2 dan Ekstensi Panjang Data Bluetooth LE.

Android menyertakan dukungan untuk Bluetooth dan Bluetooth Hemat Energi.

Jika implementasi perangkat mencakup dukungan untuk Bluetooth dan Bluetooth Hemat Energi, perangkat tersebut:

• [C-2-1] HARUS mendeklarasikan fitur platform yang relevan (android.hardware.bluetooth dan android.hardware.bluetooth_le masing-masing) dan menerapkan API platform.

• HARUS menerapkan profil Bluetooth yang relevan seperti A2DP, AVRCP, OBEX, HFP, dll. sebagaimana mestinya untuk perangkat.

Jika implementasi perangkat menyertakan dukungan untuk Bluetooth Hemat Energi (BLE), maka:

• [C-3-1] HARUS mendeklarasikan fitur hardware android.hardware.bluetooth_le.

• [C-3-2] HARUS mengaktifkan API Bluetooth berbasis GATT (generic attribute profile) seperti yang dijelaskan dalam dokumentasi SDK dan android.bluetooth.

• [C-3-3] HARUS melaporkan nilai yang benar untuk BluetoothAdapter.isOffloadedFilteringSupported() untuk menunjukkan apakah logika pemfilteran untuk class API ScanFilter diterapkan.

• [C-3-4] HARUS melaporkan nilai yang benar untuk BluetoothAdapter.isMultipleAdvertisementSupported() untuk menunjukkan apakah Low Energy Advertising didukung.

• [C-3-5] HARUS menerapkan waktu tunggu Resolvable Private Address (RPA) tidak lebih dari 15 menit dan mengganti alamat saat waktu tunggu untuk melindungi privasi pengguna saat perangkat secara aktif menggunakan BLE untuk pemindaian atau penayangan iklan. Untuk mencegah serangan pengaturan waktu, interval waktu tunggu habis JUGA HARUS diacak antara 5 dan 15 menit.

• HARUS mendukung penonaktifan logika pemfilteran ke chipset bluetooth saat menerapkan ScanFilter API.

• HARUS mendukung pelepasan pemindaian yang dikelompokkan ke chipset bluetooth.

• HARUS mendukung beberapa iklan dengan minimal 4 slot.

Jika implementasi perangkat mendukung Bluetooth LE dan menggunakan Bluetooth LE untuk pemindaian lokasi, perangkat tersebut:

• [C-4-1] HARUS menyediakan keleluasaan pengguna untuk mengaktifkan/menonaktifkan nilai yang dibaca melalui BluetoothAdapter.isBleScanAlwaysAvailable() System API.

Jika implementasi perangkat mencakup dukungan untuk Bluetooth LE dan Profil Alat Bantu Dengar, seperti yang dijelaskan dalam Dukungan Audio Alat Bantu Dengar Menggunakan Bluetooth LE, maka:

• [C-5-1] HARUS menampilkan true untuk BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).

Jika implementasi perangkat mencakup dukungan untuk Bluetooth atau Bluetooth Hemat Energi, maka:

• [C-6-1] HARUS membatasi akses ke metadata Bluetooth apa pun (seperti hasil pemindaian) yang dapat digunakan untuk mendapatkan lokasi perangkat, kecuali jika aplikasi yang meminta berhasil lulus pemeriksaan izin android.permission.ACCESS_FINE_LOCATION berdasarkan status latar depan/latar belakangnya saat ini.

Jika implementasi perangkat mencakup dukungan untuk Bluetooth atau Bluetooth Hemat Energi dan manifes aplikasi tidak menyertakan pernyataan dari developer yang menyatakan bahwa mereka tidak mendapatkan lokasi dari Bluetooth, maka:

• [C-6-2] HARUS membatasi akses Bluetooth di belakang android.permission.ACCESS_FINE_LOCATION.

Jika implementasi perangkat menampilkan true untuk BluetoothAdapter.isLeAudioSupported() API, maka:

• [C-7-1] HARUS mendukung klien unicast.

• [C-7-2] HARUS mendukung PHY 2M.

• [C-7-3] HARUS mendukung iklan yang Diperluas LE.

• [C-7-4] HARUS mendukung minimal 2 koneksi CIS dalam CIG.

• [C-7-5] HARUS mengaktifkan klien unicast BAP, koordinator set CSIP, server MCP, pengontrol VCP, server CCP secara bersamaan.

• [C-SR-1] SANGAT DISARANKAN untuk mengaktifkan klien unicast HAP.

Jika implementasi perangkat menampilkan true untuk BluetoothAdapter.isLeAudioBroadcastSourceSupported() API, maka:

• [C-8-1] HARUS mendukung minimal 2 link BIS dalam BIG.

• [C-8-2] HARUS mengaktifkan sumber siaran BAP, asisten siaran BAP secara bersamaan.

• [C-8-3] HARUS mendukung iklan Berkala LE.

Jika implementasi perangkat menampilkan true untuk BluetoothAdapter.isLeAudioBroadcastAssistantSupported() API, maka:

• [C-9-1] HARUS mendukung PAST (Periodic Advertising Sync Transfer).

• [C-9-2] HARUS mendukung iklan Berkala LE.

Jika implementasi perangkat mendeklarasikan FEATURE_BLUETOOTH_LE, implementasi tersebut:

• [C-10-1] HARUS memiliki pengukuran RSSI dalam +/-9 dB untuk 95% pengukuran pada jarak 1 m dari perangkat referensi yang mentransmisikan pada ADVERTISE_TX_POWER_HIGH di lingkungan line of sight.

• [C-10-2] HARUS menyertakan koreksi Rx/Tx untuk mengurangi deviasi per saluran sehingga pengukuran pada setiap 3 saluran, pada setiap antena (jika beberapa antena digunakan), berada dalam +/-3 dB satu sama lain untuk 95% pengukuran.

Jika implementasi perangkat mendeklarasikan FEATURE_BLUETOOTH_LE_CHANNEL_SOUNDING, implementasi tersebut:

• [C-11-1] HARUS melaporkan flag fitur hardware android.hardware.bluetooth_le.channel_sounding.

• [C-11-2] HARUS melaporkan rentang secara akurat dalam +/- 0,5 m pada persentil ke-90, sebagaimana dihitung dengan Fungsi Distribusi Kumulatif, pada jarak 1 m.

Jika implementasi perangkat mendeklarasikan FEATURE_BLUETOOTH_LE, implementasi tersebut:

• [C-SR-2] SANGAT DISARANKAN untuk mengukur dan mengompensasi offset Rx guna memastikan median BLE RSSI adalah -60 dBm +/-10 dB pada jarak 1 m dari perangkat referensi yang mentransmisikan pada ADVERTISE_TX_POWER_HIGH, dengan perangkat diorientasikan sedemikian rupa sehingga berada di 'bidang paralel' dengan layar menghadap ke arah yang sama.

• [C-SR-3] SANGAT DISARANKAN untuk mengukur dan mengompensasi offset Tx untuk memastikan RSSI BLE median adalah -60 dBm +/-10 dB saat memindai dari perangkat referensi yang diposisikan pada jarak 1 m dan mentransmisikan pada ADVERTISE_TX_POWER_HIGH, dengan perangkat diorientasikan sedemikian rupa sehingga berada di 'bidang paralel' dengan layar menghadap ke arah yang sama.

SANGAT DISARANKAN untuk mengikuti langkah-langkah penyiapan pengukuran yang ditentukan dalam Persyaratan Kalibrasi Kehadiran.

7.4.4. Komunikasi Nirkabel Jarak Dekat

Implementasi perangkat:

• HARUS mencakup pemancar-penerima sinyal dan hardware terkait untuk Komunikasi Nirkabel Jarak Dekat (NFC).

• [C-0-1] HARUS menerapkan API android.nfc.NdefMessage dan android.nfc.NdefRecord meskipun tidak menyertakan dukungan untuk NFC atau mendeklarasikan fitur android.hardware.nfc karena class merepresentasikan format representasi data yang independen terhadap protokol.

Jika implementasi perangkat menyertakan hardware NFC dan berencana untuk menyediakannya bagi aplikasi pihak ketiga, maka:

• [C-1-1] HARUS melaporkan fitur android.hardware.nfc dari metode android.content.pm.PackageManager.hasSystemFeature().

• HARUS dapat membaca dan menulis pesan NDEF melalui standar NFC berikut seperti di bawah:

• [C-1-2] HARUS dapat bertindak sebagai pembaca/penulis Forum NFC (seperti yang ditentukan oleh spesifikasi teknis Forum NFC NFCForum-TS-DigitalProtocol-1.0) melalui standar NFC berikut:

  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • Jenis Tag Forum NFC 2, 3, 4, 5 (ditetapkan oleh Forum NFC)

• [C-SR-1] SANGAT DISARANKAN agar dapat membaca dan menulis pesan NDEF serta data mentah melalui standar NFC berikut. Perhatikan bahwa meskipun standar NFC dinyatakan sebagai SANGAT DISARANKAN, Definisi Kompatibilitas untuk versi mendatang berencana mengubahnya menjadi HARUS. Standar ini bersifat opsional dalam versi ini, tetapi akan diwajibkan dalam versi mendatang. Perangkat lama dan baru yang menjalankan Android versi ini sangat disarankan untuk memenuhi persyaratan ini sekarang agar dapat mengupgrade ke rilis platform mendatang.

• [C-1-13] HARUS melakukan polling untuk semua teknologi yang didukung saat dalam mode penemuan NFC.

• HARUS dalam mode penemuan NFC saat perangkat aktif dengan layar aktif dan layar kunci tidak terkunci.

• HARUS dapat membaca kode batang dan URL (jika dienkode) dari produk Thinfilm NFC Barcode.

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

Android menyertakan dukungan untuk mode Emulasi Kartu Host (HCE) NFC.

Jika implementasi perangkat menyertakan chipset pengontrol NFC yang mampu HCE (untuk NfcA dan/atau NfcB) dan mendukung perutean ID Aplikasi (AID), maka:

• [C-2-1] HARUS melaporkan konstanta fitur android.hardware.nfc.hce.

• [C-2-2] HARUS mendukung NFC HCE API seperti yang ditentukan dalam Android SDK.

Jika implementasi perangkat menyertakan chipset pengontrol NFC yang mendukung HCE untuk NfcF, dan mengimplementasikan fitur untuk aplikasi pihak ketiga, maka:

• [C-3-1] HARUS melaporkan konstanta fitur android.hardware.nfc.hcef.

• [C-3-2] HARUS menerapkan NfcF Card Emulation API seperti yang ditentukan dalam Android SDK.

Jika implementasi perangkat mencakup dukungan NFC umum seperti yang dijelaskan di bagian ini dan mendukung teknologi MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF di MIFARE Classic) dalam peran pembaca/penulis, maka:

• [C-4-1] HARUS mengimplementasikan Android API yang sesuai seperti yang didokumentasikan oleh Android SDK.

• [C-4-2] HARUS melaporkan fitur com.nxp.mifare dari metode android.content.pm.PackageManager.hasSystemFeature(). Perhatikan bahwa ini bukan fitur Android standar dan oleh karena itu tidak muncul sebagai konstanta di class android.content.pm.PackageManager.

7.4.5. API dan protokol jaringan

7.4.5.1. Kemampuan Jaringan Minimum

Implementasi perangkat:

• [C-0-1] HARUS mencakup 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. Contoh teknologi yang memenuhi persyaratan ini mencakup EDGE, HSPA, EV-DO, 802.11g, Ethernet, dan Bluetooth PAN.

• JUGA harus menyertakan dukungan untuk setidaknya satu standar data nirkabel umum, seperti 802.11 (Wi-Fi), saat standar jaringan fisik (seperti Ethernet) adalah koneksi data utama.

• DAPAT menerapkan lebih dari satu bentuk konektivitas data.

7.4.5.2. IPv6

Implementasi perangkat:

• [C-0-2] HARUS menyertakan stack jaringan IPv6 dan mendukung komunikasi IPv6 menggunakan API terkelola, seperti java.net.Socket dan java.net.URLConnection, serta API native, seperti soket AF_INET6.

• [C-0-3] HARUS mengaktifkan IPv6 secara default.

• HARUS memastikan bahwa komunikasi IPv6 sama andalnya dengan IPv4, misalnya:

• [C-0-4] HARUS mempertahankan konektivitas IPv6 dalam mode istirahat.

• [C-0-5] Pembatasan kecepatan TIDAK BOLEH menyebabkan perangkat kehilangan konektivitas IPv6 di jaringan yang kompatibel dengan IPv6 yang menggunakan masa aktif RA minimal 180 detik.

• [C-0-6] HARUS menyediakan konektivitas IPv6 langsung ke jaringan untuk aplikasi pihak ketiga saat terhubung ke jaringan IPv6, tanpa ada bentuk terjemahan alamat atau port yang terjadi secara lokal di perangkat. Baik API terkelola seperti Socket#getLocalAddress atau Socket#getLocalPort dan NDK API seperti getsockname() atau IPV6_PKTINFO HARUS menampilkan alamat IP dan port yang sebenarnya digunakan untuk mengirim dan menerima paket di jaringan dan terlihat sebagai IP dan port sumber ke server internet (web).

Tingkat dukungan IPv6 yang diperlukan bergantung pada jenis jaringan, seperti yang ditunjukkan dalam persyaratan berikut.

Jika implementasi perangkat mendukung Wi-Fi, perangkat tersebut:

• [C-1-1] HARUS mendukung operasi stack ganda dan khusus IPv6 di Wi-Fi.

Jika penerapan perangkat mendukung Ethernet, perangkat tersebut:

• [C-2-1] HARUS mendukung operasi stack ganda dan khusus IPv6 di Ethernet.

Jika implementasi perangkat mendukung Data seluler, maka:

• [C-3-1] HARUS mendukung operasi IPv6 (khusus IPv6 dan mungkin stack ganda) di jaringan seluler.

Jika implementasi perangkat mendukung lebih dari satu jenis jaringan (misalnya, Wi-Fi dan data seluler), perangkat tersebut:

• [C-4-1] HARUS memenuhi persyaratan di atas secara bersamaan di setiap jaringan saat perangkat terhubung secara bersamaan ke lebih dari satu jenis jaringan.

7.4.5.3. Captive Portal

Captive portal mengacu pada jaringan yang memerlukan login untuk mendapatkan akses internet.

Jika implementasi perangkat menyediakan implementasi lengkap android.webkit.Webview API, implementasi tersebut:

• [C-1-1] HARUS menyediakan aplikasi captive portal untuk menangani intent ACTION_CAPTIVE_PORTAL_SIGN_IN dan menampilkan halaman login captive portal, dengan mengirimkan intent tersebut, saat panggilan ke System API ConnectivityManager#startCaptivePortalApp(Network, Bundle).

• [C-1-2] HARUS melakukan deteksi captive portal dan mendukung login melalui aplikasi captive portal saat perangkat terhubung ke jenis jaringan apa pun, termasuk jaringan seluler/mobile, Wi-Fi, Ethernet atau Bluetooth.

• [C-1-3] HARUS mendukung login ke portal captive menggunakan DNS cleartext saat perangkat dikonfigurasi untuk menggunakan mode ketat DNS pribadi.

• [C-1-4] HARUS menggunakan DNS terenkripsi sesuai dokumentasi SDK untuk android.net.LinkProperties.getPrivateDnsServerName dan android.net.LinkProperties.isPrivateDnsActive untuk semua traffic jaringan yang tidak secara eksplisit berkomunikasi dengan portal captive.

• [C-1-5] HARUS memastikan bahwa, saat pengguna login ke portal penangkap, jaringan default yang digunakan oleh aplikasi (seperti yang ditampilkan oleh ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback, dan digunakan secara default oleh API jaringan Java seperti java.net.Socket, dan API native seperti connect()) adalah jaringan lain yang tersedia yang menyediakan akses internet, jika tersedia.

7.4.6. Setelan Sinkronisasi

Implementasi perangkat:

• [C-0-1] HARUS mengaktifkan setelan sinkronisasi otomatis utama secara default sehingga metode getMasterSyncAutomatically() menampilkan "true".

7.4.7. Penghemat Data

Jika implementasi perangkat mencakup koneksi berbayar, maka:

• [C-SR-1] SANGAT DISARANKAN untuk menyediakan mode hemat data.

Jika implementasi perangkat menyediakan mode penghemat data, maka:

• [C-1-1] HARUS mendukung semua API di class ConnectivityManager seperti yang dijelaskan dalam dokumentasi SDK

Jika implementasi perangkat tidak menyediakan mode penghemat data, maka:

• [C-2-1] HARUS menampilkan nilai RESTRICT_BACKGROUND_STATUS_DISABLED untuk ConnectivityManager.getRestrictBackgroundStatus()

• [C-2-2] TIDAK BOLEH menyiarkan ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

7.4.8. Elemen Pengamanan

Jika penerapan perangkat mendukung elemen aman yang kompatibel dengan Open Mobile API dan menyediakannya untuk aplikasi pihak ketiga, perangkat tersebut:

• [C-1-1] HARUS mencantumkan pembaca elemen aman yang tersedia melalui android.se.omapi.SEService.getReaders() API.

• [C-1-2] HARUS mendeklarasikan tanda fitur yang benar melalui android.hardware.se.omapi.uicc untuk perangkat dengan elemen pengaman berbasis UICC, android.hardware.se.omapi.ese untuk perangkat dengan elemen pengaman berbasis eSE, dan android.hardware.se.omapi.sd untuk perangkat dengan elemen pengaman berbasis SD.

7.4.9. UWB

Jika implementasi perangkat mencakup dukungan untuk 802.1.15.4 dan mengekspos fungsi ke aplikasi pihak ketiga, maka:

• [C-1-1] HARUS menerapkan Android API yang sesuai di android.uwb.

• [C-1-2] HARUS melaporkan flag fitur hardware android.hardware.uwb.

• [C-1-3] HARUS mendukung semua profil UWB yang relevan yang ditentukan dalam implementasi Android.

• [C-1-4] HARUS menyediakan kemampuan pengguna untuk mengizinkan pengguna mengaktifkan/menonaktifkan status radio UWB.

• [C-1-5] HARUS memastikan bahwa aplikasi yang menggunakan radio UWB memiliki izin UWB_RANGING (dalam grup izin NEARBY_DEVICES).

• [C-SR-1] SANGAT DISARANKAN untuk lulus uji kesesuaian dan sertifikasi yang relevan yang ditentukan oleh organisasi standar, termasuk FIRA, CCC, dan CSA.

• [C-1-6] HARUS memastikan pengukuran jarak berada dalam +/-15 cm untuk 95% pengukuran dalam lingkungan garis pandang pada jarak 1 m dalam ruang non-reflektif.

• [C-1-7] HARUS memastikan bahwa median pengukuran jarak pada 1 m dari perangkat referensi berada dalam [0,75 m, 1,25 m], dengan jarak sebenarnya diukur dari tepi atas DUT.

• [C-SR-2] SANGAT DISARANKAN untuk mengikuti langkah-langkah penyiapan pengukuran yang ditentukan dalam Persyaratan Kalibrasi Kehadiran.

7.5. Kamera

Jika implementasi perangkat mencakup setidaknya satu kamera, perangkat tersebut:

• [C-1-1] HARUS mendeklarasikan tanda fitur android.hardware.camera.any.

• [C-1-2] HARUS memungkinkan aplikasi mengalokasikan 3 RGBA_8888 bitmap secara bersamaan yang sama dengan ukuran gambar yang dihasilkan oleh sensor kamera beresolusi terbesar di perangkat, saat kamera dibuka untuk tujuan pratinjau dasar dan pengambilan gambar diam.

• [C-1-3] HARUS memastikan bahwa aplikasi kamera default yang sudah diinstal sebelumnya yang menangani intent MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE, atau MediaStore.ACTION_VIDEO_CAPTURE, bertanggung jawab untuk menghapus lokasi pengguna dalam metadata gambar sebelum mengirimkannya ke aplikasi penerima jika aplikasi penerima tidak memiliki ACCESS_FINE_LOCATION.

Jika implementasi perangkat menyertakan setidaknya satu kamera, dan aplikasi kamera yang sudah diinstal menangani intent MediaStore.ACTION_MOTION_PHOTO_CAPTURE atau MediaStore.ACTION_MOTION_PHOTO_CAPTURE_SECURE, maka:

• [C-1-4] HARUS memastikan bahwa saat menangani intent ini, aplikasi kamera bawaan menghapus lokasi pengguna dalam metadata gambar sebelum mengirimkannya ke aplikasi penerima yang tidak memiliki ACCESS_FINE_LOCATION.

• [C-1-5] HARUS memastikan bahwa foto bergerak yang ditampilkan menggunakan spesifikasi format Foto Bergerak 1.0.

Jika implementasi perangkat mendukung kemampuan output HDR 10-bit, maka:

• [C-2-1] HARUS mendukung setidaknya profil HDR HLG untuk setiap perangkat kamera yang mendukung output 10-bit.

• [C-2-2] HARUS mendukung output 10-bit untuk kamera belakang utama atau kamera depan utama.

• [C-SR-1] SANGAT DISARANKAN untuk mendukung output 10-bit untuk kedua kamera utama.

• [C-2-3] HARUS mendukung profil HDR yang sama untuk semua sub-kamera fisik yang kompatibel dengan BACKWARD_COMPATIBLE dari kamera logis, dan kamera logis itu sendiri.

Untuk perangkat kamera Logis yang mendukung HDR 10-bit yang mengimplementasikan API android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO, perangkat tersebut:

• [C-3-1] HARUS mendukung peralihan antara semua kamera fisik yang kompatibel mundur melalui kontrol CONTROL_ZOOM_RATIO pada kamera logis.

7.5.1. Kamera Belakang

Kamera belakang adalah kamera yang menghadap dunia yang memotret pemandangan di sisi jauh perangkat, seperti kamera tradisional; pada perangkat genggam, kamera tersebut adalah kamera yang terletak di sisi perangkat yang berlawanan dengan layar.

Implementasi perangkat:

• HARUS menyertakan kamera belakang.

Jika implementasi perangkat menyertakan setidaknya satu kamera belakang, maka:

• [C-1-1] HARUS melaporkan flag fitur android.hardware.camera dan android.hardware.camera.any.

• 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:

• [C-2-1] lampu flash TIDAK BOLEH menyala saat instance android.hardware.Camera.PreviewCallback telah didaftarkan di permukaan 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

Kamera depan adalah kamera yang menghadap pengguna yang biasanya digunakan untuk mengambil gambar pengguna, seperti untuk konferensi video dan aplikasi serupa; pada perangkat genggam, kamera tersebut adalah kamera yang terletak di sisi perangkat yang sama dengan layar.

Implementasi perangkat:

• MUNGKIN menyertakan kamera depan.

Jika implementasi perangkat menyertakan minimal satu kamera depan, maka:

• [C-1-1] HARUS melaporkan flag fitur android.hardware.camera.any dan android.hardware.camera.front.

• [C-1-2] HARUS memiliki resolusi minimal VGA (640x480 piksel).

• [C-1-3] TIDAK BOLEH menggunakan kamera depan sebagai default untuk Camera API dan TIDAK BOLEH mengonfigurasi API untuk memperlakukan kamera depan sebagai kamera belakang default, meskipun kamera tersebut adalah satu-satunya kamera di perangkat.

• [C-1-4] Pratinjau kamera HARUS dicerminkan secara horizontal relatif terhadap orientasi yang ditentukan oleh aplikasi saat aplikasi saat ini telah secara eksplisit meminta agar tampilan Kamera diputar melalui panggilan ke metode android.hardware.Camera.setDisplayOrientation(). Sebaliknya, pratinjau HARUS dicerminkan di sepanjang sumbu horizontal default perangkat saat aplikasi saat ini tidak secara eksplisit meminta agar tampilan Kamera diputar melalui panggilan ke metode android.hardware.Camera.setDisplayOrientation().

• [C-1-5] TIDAK BOLEH mencerminkan gambar diam atau streaming video yang diambil akhir dan dikembalikan ke callback aplikasi atau di-commit ke penyimpanan media.

• [C-1-6] HARUS mencerminkan gambar yang ditampilkan oleh postview dengan cara yang sama seperti aliran gambar pratinjau kamera.

• DAPAT mencakup fitur (seperti fokus otomatis, flash, dll.) yang tersedia untuk kamera belakang sebagaimana dijelaskan dalam pasal 7.5.1.

Jika implementasi perangkat dapat diputar oleh pengguna (seperti secara otomatis melalui akselerometer atau secara manual melalui input pengguna):

• [C-2-1] Pratinjau kamera HARUS dicerminkan secara horizontal relatif terhadap orientasi perangkat saat ini.

7.5.3. Kamera Eksternal

Kamera eksternal adalah kamera yang dapat dipasang atau dilepas secara fisik dari implementasi perangkat kapan saja dan dapat menghadap ke arah mana pun; seperti kamera USB.

Implementasi perangkat:

• MUNGKIN mencakup dukungan untuk kamera eksternal yang tidak selalu terhubung.

Jika implementasi perangkat menyertakan dukungan untuk kamera eksternal, maka:

• [C-1-1] HARUS mendeklarasikan flag fitur platform android.hardware.camera.external dan android.hardware camera.any.

• [C-1-2] HARUS mendukung USB Video Class (UVC 1.0 atau yang lebih tinggi) jika kamera eksternal terhubung melalui port host USB.

• [C-1-3] HARUS lulus pengujian CTS kamera dengan perangkat kamera eksternal fisik yang terhubung. Detail pengujian CTS kamera tersedia di source.android.com.

• HARUS mendukung kompresi video seperti MJPEG untuk memungkinkan transfer streaming yang tidak dienkode berkualitas tinggi (yaitu streaming gambar mentah atau yang dikompresi secara independen).

• DAPAT mendukung beberapa kamera.

• MUNGKIN mendukung encoding video berbasis kamera.

Jika encoding video berbasis kamera didukung:

• [C-2-1] Aliran MJPEG / tidak dienkode simultan (resolusi QVGA atau lebih tinggi) HARUS dapat diakses oleh penerapan 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 bawah ke aplikasi, termasuk alur burst/streaming tanpa salinan yang efisien dan kontrol per frame untuk eksposur, gain, gain white balance, konversi warna, peredam bising, penajaman, dan lainnya.

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

Semua fitur yang umum antara class android.hardware.Camera yang tidak digunakan lagi dan paket android.hardware.camera2 yang lebih baru HARUS memiliki performa dan kualitas yang setara di kedua API. Misalnya, dengan setelan yang setara, kecepatan dan akurasi fokus otomatis harus identik, dan kualitas gambar yang diambil harus sama. Fitur yang bergantung pada semantik kedua API yang berbeda tidak harus memiliki kecepatan atau kualitas yang sama, tetapi HARUS sama sedekat mungkin.

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

• [C-0-1] HARUS menggunakan android.hardware.PixelFormat.YCbCr_420_SP untuk data pratinjau yang diberikan ke callback aplikasi saat aplikasi belum pernah memanggil android.hardware.Camera.Parameters.setPreviewFormat(int).

• [C-0-2] HARUS lebih lanjut dalam format encoding NV21 saat aplikasi mendaftarkan instance android.hardware.Camera.PreviewCallback dan sistem memanggil metode onPreviewFrame() dan format pratinjau adalah YCbCr_420_SP, data dalam byte[] yang diteruskan ke onPreviewFrame(). Artinya, NV21 HARUS menjadi default.

• [C-0-3] HARUS mendukung format YV12 (seperti yang ditunjukkan oleh konstanta android.graphics.ImageFormat.YV12) untuk pratinjau kamera depan dan belakang untuk android.hardware.Camera. (Encoder video dan kamera hardware dapat menggunakan format piksel native apa pun, tetapi implementasi perangkat HARUS mendukung konversi ke YV12.)

• [C-0-4] HARUS mendukung format android.hardware.ImageFormat.YUV_420_888 dan android.hardware.ImageFormat.JPEG sebagai output melalui API android.media.ImageReader untuk perangkat android.hardware.camera2 yang mengiklankan kemampuan REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE di android.request.availableCapabilities.

• [C-0-5] 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 TETAP HARUS memanggil instance android.hardware.Camera.AutoFocusCallback yang terdaftar (meskipun tidak relevan dengan kamera non-fokus otomatis.) Perhatikan bahwa hal ini berlaku untuk kamera depan; misalnya, meskipun sebagian besar kamera depan tidak mendukung fokus otomatis, callback API tetap harus "dipalsukan" seperti yang dijelaskan.

• [C-0-6] HARUS mengenali dan mematuhi setiap nama parameter yang ditentukan sebagai konstanta dalam class android.hardware.Camera.Parameters dan class android.hardware.camera2.CaptureRequest. Sebaliknya, implementasi perangkat TIDAK BOLEH mematuhi atau mengenali konstanta string yang diteruskan ke metode android.hardware.Camera.setParameters() selain yang didokumentasikan sebagai konstanta di android.hardware.Camera.Parameters. Artinya, implementasi perangkat HARUS mendukung semua parameter Kamera standar jika hardware memungkinkan, dan TIDAK BOLEH mendukung jenis parameter Kamera kustom. Misalnya, penerapan perangkat yang mendukung pengambilan gambar menggunakan teknik pencitraan rentang dinamis tinggi (HDR) HARUS mendukung parameter kamera Camera.SCENE_MODE_HDR.

• [C-0-7] HARUS melaporkan tingkat dukungan yang tepat dengan properti android.info.supportedHardwareLevel seperti yang dijelaskan dalam Android SDK dan melaporkan flag fitur framework yang sesuai.

• [C-0-8] JUGA harus mendeklarasikan kemampuan kamera individualnya android.hardware.camera2 melalui properti android.request.availableCapabilities dan mendeklarasikan flag fitur yang sesuai; HARUS menentukan flag fitur jika ada perangkat kamera terpasang yang mendukung fitur tersebut.

• [C-0-9] HARUS menyiarkan maksud Camera.ACTION_NEW_PICTURE setiap kali gambar baru diambil oleh kamera dan entri gambar telah ditambahkan ke penyimpanan media.

• [C-0-10] HARUS menyiarkan maksud Camera.ACTION_NEW_VIDEO setiap kali video baru direkam oleh kamera dan entri gambar telah ditambahkan ke penyimpanan media.

• [C-0-11] HARUS memiliki semua kamera yang dapat diakses melalui API android.hardware.Camera yang tidak digunakan lagi juga dapat diakses melalui API android.hardware.camera2.

• [C-0-12] HARUS memastikan bahwa penampilan wajah TIDAK dimodifikasi, termasuk, tetapi tidak terbatas pada, memodifikasi geometri wajah, warna kulit wajah, atau penghalusan kulit wajah untuk API android.hardware.camera2 atau android.hardware.Camera apa pun.

• [C-SR-1] Untuk perangkat dengan beberapa kamera RGB yang berdekatan dan menghadap ke arah yang sama, SANGAT DISARANKAN untuk mendukung perangkat kamera logis yang mencantumkan kemampuan CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, yang terdiri dari semua kamera RGB yang menghadap ke arah tersebut sebagai sub-perangkat fisik.

Jika implementasi perangkat menyediakan API kamera eksklusif untuk aplikasi pihak ketiga, implementasi tersebut:

• [C-1-1] HARUS menerapkan API kamera tersebut menggunakan android.hardware.camera2 API.

• DAPAT memberikan tag dan/atau ekstensi vendor ke android.hardware.camera2 API.

7.5.5. Orientasi Kamera

Jika implementasi perangkat memiliki kamera depan atau belakang, kamera tersebut:

• [C-1-1] HARUS diorientasikan sehingga dimensi panjang kamera sejajar dengan dimensi panjang layar. Artinya, saat perangkat dipegang dalam orientasi lanskap, kamera HARUS mengambil gambar dalam orientasi lanskap. Hal ini berlaku terlepas dari orientasi alami perangkat; yaitu, berlaku untuk perangkat dengan orientasi lanskap utama serta perangkat dengan orientasi potret utama.

  Perangkat yang memenuhi salah satu kriteria berikut dikecualikan dari persyaratan ini:

  • Perangkat menerapkan layar geometri variabel, seperti layar foldable atau berengsel, DAN saat status lipatan atau engsel perangkat berubah, perangkat beralih antara orientasi potret-primer ke lanskap-primer (atau sebaliknya).

  • Implementasi perangkat yang tidak dapat diputar oleh pengguna, seperti perangkat otomotif.

7.6. Memori dan Penyimpanan

7.6.1. Memori dan Penyimpanan Minimum

Implementasi perangkat:

• [C-0-1] HARUS menyertakan Pengelola Download yang DAPAT digunakan aplikasi untuk mendownload file data dan aplikasi tersebut HARUS dapat mendownload file individual berukuran minimal 100 MB ke lokasi "cache" default.

7.6.2. Penyimpanan Bersama Aplikasi

Implementasi perangkat:

• [C-0-1] HARUS menawarkan penyimpanan yang akan dibagikan oleh aplikasi, yang juga sering disebut sebagai "penyimpanan eksternal bersama", "penyimpanan bersama aplikasi", atau berdasarkan jalur Linux "/sdcard" tempat penyimpanan tersebut dipasang.
• [C-0-2] HARUS dikonfigurasi dengan penyimpanan bersama yang di-mount secara default, dengan kata lain "langsung dapat digunakan", terlepas dari apakah penyimpanan diimplementasikan pada komponen penyimpanan internal atau media penyimpanan yang dapat dilepas (misalnya, slot kartu Secure Digital).
• [C-0-3] HARUS memasang penyimpanan bersama aplikasi langsung di jalur Linux sdcard atau menyertakan link simbolis Linux dari sdcard ke titik pemasangan sebenarnya.
• [C-0-4] HARUS mengaktifkan penyimpanan tercakup secara default untuk semua aplikasi yang menargetkan API level 29 atau yang lebih tinggi, kecuali dalam situasi berikut:
  • Jika aplikasi telah meminta android:requestLegacyExternalStorage="true" dalam manifesnya.
• [C-0-5] HARUS menyunting metadata lokasi, seperti tag Exif GPS, yang disimpan dalam file media saat file tersebut diakses melalui MediaStore, kecuali saat aplikasi yang memanggil memiliki izin ACCESS_MEDIA_LOCATION.

Implementasi perangkat DAPAT memenuhi persyaratan di atas menggunakan salah satu dari berikut:

• Penyimpanan portabel yang dapat diakses pengguna, seperti slot kartu Secure Digital (SD).
• Sebagian penyimpanan internal (tidak dapat dilepas) seperti yang diterapkan di Project Open Source Android (AOSP).

Jika implementasi perangkat menggunakan penyimpanan yang dapat dilepas untuk memenuhi persyaratan di atas, perangkat tersebut:

• [C-1-1] HARUS menerapkan antarmuka pengguna toast atau pop-up yang memperingatkan pengguna jika tidak ada media penyimpanan yang dimasukkan ke dalam slot.
• [C-1-2] HARUS menyertakan media penyimpanan berformat FAT (mis. kartu SD) atau menunjukkan pada kotak dan materi lain yang tersedia pada saat pembelian bahwa media penyimpanan harus dibeli secara terpisah.

Jika penerapan perangkat menggunakan sebagian penyimpanan yang tidak dapat dilepas untuk memenuhi persyaratan di atas, maka:

• HARUS menggunakan penerapan AOSP untuk penyimpanan bersama aplikasi internal.
• DAPAT membagikan ruang penyimpanan dengan data pribadi aplikasi.

Jika penerapan perangkat memiliki port USB dengan dukungan mode periferal USB, perangkat tersebut:

• [C-3-1] HARUS menyediakan mekanisme untuk mengakses data di penyimpanan bersama aplikasi dari komputer host.
• HARUS mengekspos konten dari kedua jalur penyimpanan secara transparan melalui layanan pemindai media Android dan android.provider.MediaStore.
• DAPAT menggunakan penyimpanan massal USB, tetapi SEBAIKNYA menggunakan Media Transfer Protocol untuk memenuhi persyaratan ini.

Jika implementasi perangkat memiliki port USB dengan mode periferal USB dan mendukung Media Transfer Protocol, perangkat tersebut:

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

7.6.3. Penyimpanan yang Dapat Diadaptasi

Jika perangkat diharapkan bersifat seluler, tidak seperti Televisi, implementasi perangkat adalah:

• [C-SR-1] SANGAT DISARANKAN untuk menerapkan penyimpanan yang dapat diadaptasi di lokasi yang stabil dalam jangka panjang, karena jika terputus secara tidak sengaja dapat menyebabkan kehilangan/kerusakan data.

Jika port perangkat penyimpanan yang dapat dilepas berada di lokasi yang stabil dalam jangka panjang, seperti di dalam kompartemen baterai atau penutup pelindung lainnya, implementasi perangkat adalah:

• [C-SR-2] SANGAT DISARANKAN untuk menerapkan penyimpanan yang dapat diadaptasi.

7.7. USB

Jika implementasi perangkat memiliki port USB, perangkat tersebut:

• HARUS mendukung mode perangkat USB.

• HARUS mendukung mode host USB.

• HARUS mendukung penonaktifan sinyal data melalui USB.

7.7.1. Mode perangkat USB

Jika implementasi perangkat menyertakan port USB dan mengimplementasikan spesifikasi AOA, maka:

• [C-2-1] HARUS mendeklarasikan dukungan untuk fitur hardware android.hardware.usb.accessory.
• [C-2-2] Class penyimpanan massal USB HARUS menyertakan string "android" di akhir string iInterface deskripsi antarmuka penyimpanan massal USB

7.7.2. Mode host USB

Jika implementasi perangkat mencakup port USB yang mendukung mode host, maka:

• [C-1-1] HARUS menerapkan Android USB host API seperti yang didokumentasikan di Android SDK dan HARUS mendeklarasikan dukungan untuk fitur hardware android.hardware.usb.host.
• [C-1-2] HARUS menerapkan dukungan untuk menghubungkan periferal USB standar. Mereka HARUS memiliki salah satu dari hal berikut:
  • Port USB Type-C di perangkat atau dikirim dengan kabel yang mengadaptasi port eksklusif di perangkat ke port USB Type-C standar (perangkat USB Type-C).
  • Port USB Type-A di perangkat atau disertakan dengan kabel yang mengadaptasi port eksklusif di perangkat ke port USB Type-A standar.
  • Port USB mikro-AB di perangkat, yang HARUS dikirimkan dengan kabel yang mengadaptasi ke port USB Type-A standar.
• [C-1-3] TIDAK BOLEH dikirim dengan adaptor yang mengonversi dari port USB Type-A atau micro-AB ke port USB Type-C (soket).
• [C-SR-1] SANGAT DISARANKAN untuk menerapkan class audio USB seperti yang didokumentasikan dalam dokumentasi Android SDK.
• HARUS mendukung pengisian daya perangkat periferal USB yang terhubung saat dalam mode host; mengiklankan arus sumber minimal 1,5 A sebagaimana ditentukan dalam bagian Parameter Penghentian Spesifikasi Kabel dan Konektor USB Type-C Revisi 1.2 untuk konektor USB Type-C atau menggunakan rentang arus output Charging Downstream Port (CDP) sebagaimana ditentukan dalam spesifikasi Pengisian Daya Baterai USB, revisi 1.2 untuk konektor Micro-AB.
• HARUS menerapkan dan mendukung standar USB Type-C.

Jika implementasi perangkat mencakup port USB yang mendukung mode host dan class audio USB, perangkat tersebut:

• [C-2-1] HARUS mendukung class HID USB.
• [C-2-2] HARUS mendukung deteksi dan pemetaan kolom data HID berikut yang ditentukan dalam Tabel Penggunaan HID USB dan Permintaan Penggunaan Perintah Suara ke konstanta KeyEvent seperti di bawah ini:
  • Halaman Penggunaan (0xC) ID Penggunaan (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • Halaman Penggunaan (0xC) ID Penggunaan (0x0E9): KEYCODE_VOLUME_UP
  • Halaman Penggunaan (0xC) ID Penggunaan (0x0EA): KEYCODE_VOLUME_DOWN
  • Halaman Penggunaan (0xC) ID Penggunaan (0x0CF): KEYCODE_VOICE_ASSIST

Jika implementasi perangkat mencakup port USB yang mendukung mode host dan Storage Access Framework (SAF), maka:

• [C-3-1] 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 implementasi perangkat mencakup port USB yang mendukung mode host dan USB Type-C, perangkat tersebut:

• [C-4-1] HARUS menerapkan fungsi Dual Role Power (DRP) sebagaimana ditentukan oleh spesifikasi USB Type-C (bagian 4.5.1.3.3). Untuk port DRP, pada perangkat yang menyertakan jack audio 3,5 mm, deteksi penerima daya USB (mode host) MUNGKIN dinonaktifkan secara default, tetapi pengguna HARUS dapat mengaktifkannya.
• [C-SR-2] SANGAT DIREKOMENDASIKAN untuk mendukung DisplayPort.
  • HARUS mendukung Kecepatan Data SuperSpeed USB.
  • SANGAT DISARANKAN untuk mendukung Pengiriman Daya untuk pertukaran peran daya dan data.
• [C-SR-3] SANGAT DISARANKAN untuk TIDAK mendukung Mode Aksesori Adaptor Audio seperti yang dijelaskan dalam Lampiran A dari Spesifikasi Kabel dan Konektor USB Type-C Revisi 1.2.
• HARUS menerapkan model Try.* yang paling sesuai untuk faktor bentuk perangkat. Misalnya, perangkat genggam HARUS menerapkan model Try.SNK.

7.7.3. USB Power Delivery

7.8. Audio

7.8.1. Mikrofon

Jika implementasi perangkat menyertakan mikrofon, perangkat tersebut:

• [C-1-1] HARUS melaporkan konstanta fitur android.hardware.microphone.
• [C-1-2] HARUS memenuhi persyaratan rekaman audio di bagian 5.4.
• [C-1-3] HARUS memenuhi persyaratan latensi audio di bagian 5.6.
• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung perekaman near-ultrasound seperti yang dijelaskan di bagian 7.8.3.

Jika implementasi perangkat tidak menyertakan mikrofon, perangkat tersebut:

• [C-2-1] TIDAK BOLEH melaporkan konstanta fitur android.hardware.microphone.
• [C-2-2] HARUS menerapkan API perekaman audio setidaknya sebagai operasi no-op, sesuai dengan bagian 7.

7.8.2. Output Audio

Jika implementasi perangkat mencakup speaker atau port output audio/multimedia untuk periferal output audio seperti colokan audio 3,5 mm 4 konduktor atau port mode host USB menggunakan kelas audio USB, maka:

• [C-1-1] HARUS melaporkan konstanta fitur android.hardware.audio.output.
• [C-1-2] HARUS memenuhi persyaratan pemutaran audio di bagian 5.5.
• [C-1-3] HARUS memenuhi persyaratan latensi audio di bagian 5.6.
• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung pemutaran hampir ultrasonik seperti yang dijelaskan di bagian 7.8.3.

Jika implementasi perangkat tidak menyertakan speaker atau port output audio, perangkat tersebut:

• [C-2-1] TIDAK BOLEH melaporkan fitur android.hardware.audio.output.
• [C-2-2] HARUS menerapkan API terkait Output Audio setidaknya sebagai operasi no-op.

Untuk tujuan bagian ini, "port output" adalah antarmuka fisik seperti colokan audio 3,5 mm, HDMI, atau port mode host USB dengan class audio USB. Dukungan untuk output audio melalui protokol berbasis radio seperti Bluetooth, Wi-Fi, atau jaringan seluler tidak memenuhi syarat sebagai menyertakan "port 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, port tersebut:

• [C-SR-1] SANGAT DISARANKAN untuk menyertakan setidaknya satu port audio yang berupa jack audio 3,5 mm 3 konduktor.

Jika implementasi perangkat memiliki jack audio 3,5 mm 4 konduktor, maka:

• [C-1-1] HARUS mendukung pemutaran audio ke headphone stereo dan headset stereo dengan mikrofon.
• [C-1-2] HARUS mendukung jack audio TRRS dengan urutan pin CTIA.
• [C-1-3] 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
• [C-1-4] HARUS memicu ACTION_HEADSET_PLUG saat steker dimasukkan, tetapi hanya setelah semua kontak pada steker menyentuh segmen yang relevan pada jack.
• [C-1-5] HARUS mampu menggerakkan tegangan output minimal 150 mV ± 10% pada impedansi speaker 32 ohm.
• [C-1-6] HARUS memiliki tegangan bias mikrofon antara 1,8 V ~ 2,9 V.
• [C-1-7] HARUS mendeteksi dan memetakan ke kode tombol untuk rentang impedansi setara berikut antara mikrofon dan konduktor ground pada steker audio:
  • 110-180 ohm: KEYCODE_VOICE_ASSIST
• [C-SR-2] SANGAT DISARANKAN untuk mendukung colokan audio dengan urutan pin-out OMTP.
• [C-SR-3] SANGAT DISARANKAN untuk mendukung perekaman audio dari headset stereo dengan mikrofon.

Jika implementasi perangkat memiliki jack audio 3,5 mm 4 konduktor dan mendukung mikrofon, serta menyiarkan android.intent.action.HEADSET_PLUG dengan mikrofon nilai ekstra yang ditetapkan sebagai 1, maka:

• [C-2-1] HARUS mendukung deteksi mikrofon pada aksesori audio yang dicolokkan.

7.8.2.2. Port Audio Digital

Lihat Bagian 2.2.1 untuk mengetahui persyaratan khusus perangkat.

7.8.3. Dekat Ultrasonik

Audio Near-Ultrasound adalah band 18,5 kHz hingga 20 kHz.

Implementasi perangkat:

• HARUS melaporkan dukungan kemampuan audio near-ultrasound dengan benar melalui API AudioManager.getProperty sebagai berikut:

Jika PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND adalah "true", persyaratan berikut HARUS dipenuhi oleh sumber audio VOICE_RECOGNITION dan UNPROCESSED:

• [C-1-1] Respons daya rata-rata mikrofon dalam rentang 18,5 kHz hingga 20 kHz HARUS tidak lebih dari 15 dB di bawah respons pada 2 kHz.
• [C-1-2] Rasio sinyal terhadap derau yang tidak berbobot pada mikrofon di atas 18,5 kHz hingga 20 kHz untuk nada 19 kHz pada -26 dBFS HARUS tidak lebih rendah dari 50 dB.

Jika PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND adalah "true":

• [C-2-1] 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.8.4. Integritas Sinyal

Implementasi perangkat:

• HARUS menyediakan jalur sinyal audio bebas gangguan untuk aliran input dan output pada perangkat genggam, sebagaimana ditentukan oleh nol gangguan yang diukur selama pengujian satu menit per jalur. Uji menggunakan OboeTester "Automated Glitch Test".

Pengujian ini memerlukan dongle loopback audio, yang digunakan langsung di colokan 3,5 mm, dan/atau bersama dengan adaptor USB-C ke 3,5 mm. Semua port output audio HARUS diuji.

OboeTester saat ini mendukung jalur AAudio, jadi kombinasi berikut HARUS diuji untuk mengetahui apakah ada gangguan menggunakan AAudio:

Mode Performa	Berbagi	Frekuensi Sampling Keluar	Di Chans	Out Chans
LATENSI_RENDAH	EKSKLUSIF	TIDAK DITENTUKAN	1	2
LATENSI_RENDAH	EKSKLUSIF	TIDAK DITENTUKAN	2	1
LATENSI_RENDAH	DIBAGIKAN	TIDAK DITENTUKAN	1	2
LATENSI_RENDAH	DIBAGIKAN	TIDAK DITENTUKAN	2	1
TIDAK ADA	DIBAGIKAN	48000	1	2
TIDAK ADA	DIBAGIKAN	48000	2	1
TIDAK ADA	DIBAGIKAN	44100	1	2
TIDAK ADA	DIBAGIKAN	44100	2	1
TIDAK ADA	DIBAGIKAN	16000	1	2
TIDAK ADA	DIBAGIKAN	16000	2	1

Streaming yang andal HARUS memenuhi kriteria berikut untuk Rasio Sinyal terhadap Derau (SNR) dan Total Harmonic Distortion (THD) untuk sinus 2000 Hz.

Transduser	THD	SNR
speaker bawaan utama, diukur menggunakan mikrofon referensi eksternal	< 3,0%	>= 50 dB
mikrofon bawaan utama, diukur menggunakan speaker referensi eksternal	< 3,0%	>= 50 dB
colokan analog 3,5 mm bawaan, diuji menggunakan adaptor loopback	< 1%	>= 60 dB
Adaptor USB yang disertakan dengan ponsel, diuji menggunakan adaptor loopback	< 1,0%	>= 60 dB

7.9. Virtual Reality

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

7.9.1. Mode Virtual Reality

Android menyertakan dukungan untuk Mode VR, fitur yang menangani rendering stereoskopik notifikasi dan menonaktifkan komponen UI sistem monokular saat aplikasi VR memiliki fokus pengguna.

7.9.2. Mode Virtual Reality - Performa Tinggi

Jika implementasi perangkat mendukung mode VR, perangkat tersebut:

• [C-1-1] HARUS memiliki minimal 2 core fisik.
• [C-1-2] HARUS mendeklarasikan fitur android.hardware.vr.high_performance.
• [C-1-3] HARUS mendukung mode performa berkelanjutan.
• [C-1-4] HARUS mendukung OpenGL ES 3.2.
• [C-1-5] HARUS mendukung android.hardware.vulkan.level 0.
• HARUS mendukung android.hardware.vulkan.level 1 atau yang lebih tinggi.
• [C-1-6] HARUS menerapkan EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace, dan mengekspos ekstensi dalam daftar ekstensi EGL yang tersedia.
• [C-1-8] HARUS menerapkan GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_EXT_protected_textures, dan mengekspos ekstensi dalam daftar ekstensi GL yang tersedia.
• [C-SR-1] SANGAT DISARANKAN untuk menerapkan GL_EXT_external_buffer, GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture, dan mengekspos ekstensi dalam daftar ekstensi GL yang tersedia.
• [C-SR-2] SANGAT DISARANKAN untuk mendukung Vulkan 1.1.
• [C-SR-3] SANGAT DISARANKAN untuk menerapkan VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image, dan menampilkannya dalam daftar ekstensi Vulkan yang tersedia.
• [C-SR-4] SANGAT DISARANKAN untuk mengekspos setidaknya satu keluarga antrean Vulkan yang flags berisi VK_QUEUE_GRAPHICS_BIT dan VK_QUEUE_COMPUTE_BIT, dan queueCount minimal 2.
• [C-1-7] GPU dan layar HARUS dapat menyinkronkan akses ke buffer depan bersama sehingga rendering mata bergantian konten VR pada 60 fps dengan dua konteks rendering akan ditampilkan tanpa artefak tearing yang terlihat.
• [C-1-9] HARUS menerapkan dukungan untuk tanda AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA, dan AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT seperti yang dijelaskan dalam NDK.
• [C-1-10] HARUS menerapkan dukungan untuk AHardwareBuffer dengan kombinasi flag penggunaan AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT untuk setidaknya format berikut: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
• [C-SR-5] SANGAT DIREKOMENDASIKAN untuk mendukung alokasi AHardwareBuffer dengan lebih dari satu lapisan dan flag serta format yang ditentukan dalam C-1-10.
• [C-1-11] HARUS mendukung decoding H.264 minimal 3840 x 2160 pada 30 fps, dikompresi hingga rata-rata 40 Mbps (setara dengan 4 instance 1920 x 1080 pada 30 fps-10 Mbps atau 2 instance 1920 x 1080 pada 60 fps-20 Mbps).
• [C-1-12] HARUS mendukung HEVC dan VP9, HARUS mampu mendekode setidaknya 1920 x 1080 pada 30 fps yang dikompresi hingga rata-rata 10 Mbps dan SEBAIKNYA mampu mendekode 3840 x 2160 pada 30 fps-20 Mbps (setara dengan 4 instance 1920 x 1080 pada 30 fps-5 Mbps).
• [C-1-13] HARUS mendukung API HardwarePropertiesManager.getDeviceTemperatures dan menampilkan nilai yang akurat untuk suhu kulit.
• [C-1-14] HARUS memiliki layar yang disematkan, dan resolusinya HARUS minimal 1920 x 1080.
• [C-SR-6] SANGAT DISARANKAN untuk memiliki resolusi layar minimal 2560 x 1440.
• [C-1-15] Layar HARUS diupdate minimal 60 Hz saat dalam Mode VR.
• [C-1-17] Layar HARUS mendukung mode persistensi rendah dengan persistensi ≤ 5 milidetik, dengan persistensi ditentukan sebagai jumlah waktu selama piksel memancarkan cahaya.
• [C-1-18] HARUS mendukung Bluetooth 4.2 dan Ekstensi Panjang Data Bluetooth LE pasal 7.4.3.
• [C-1-19] HARUS mendukung dan melaporkan dengan benar Jenis Saluran Langsung untuk semua jenis sensor default berikut:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR-7] SANGAT DIREKOMENDASIKAN untuk mendukung jenis saluran langsung TYPE_HARDWARE_BUFFER untuk semua Jenis Saluran Langsung yang tercantum di atas.
• [C-1-21] HARUS memenuhi persyaratan terkait giroskop, akselerometer, dan magnetometer untuk android.hardware.hifi_sensors, sebagaimana ditentukan dalam pasal 7.3.9.
• [C-SR-8] SANGAT DIREKOMENDASIKAN untuk mendukung fitur android.hardware.sensor.hifi_sensors.
• [C-1-22] HARUS memiliki latensi gerak ke foton end-to-end tidak lebih tinggi dari 28 milidetik.
• [C-SR-9] SANGAT DISARANKAN untuk memiliki latensi gerakan ke foton end-to-end tidak lebih tinggi dari 20 milidetik.
• [C-1-23] HARUS memiliki rasio frame pertama, yaitu rasio antara kecerahan piksel pada frame pertama setelah transisi dari hitam ke putih dan kecerahan piksel putih dalam kondisi stabil, minimal 85%.
• [C-SR-10] SANGAT DISARANKAN untuk memiliki rasio frame pertama minimal 90%.
• DAPAT menyediakan inti eksklusif untuk aplikasi latar depan dan DAPAT mendukung Process.getExclusiveCores API untuk menampilkan jumlah inti CPU yang eksklusif untuk aplikasi latar depan teratas.

Jika core eksklusif didukung, maka core:

• [C-2-1] TIDAK BOLEH mengizinkan proses ruang pengguna lain berjalan di dalamnya (kecuali driver perangkat yang digunakan oleh aplikasi), tetapi MUNGKIN mengizinkan beberapa proses kernel berjalan sesuai kebutuhan.

7.10. Sentuhan

Perangkat yang dimaksudkan untuk dipegang atau dipakai dapat mencakup aktuator haptik serbaguna, yang tersedia untuk aplikasi dengan tujuan termasuk menarik perhatian melalui nada dering, alarm, notifikasi, serta umpan balik sentuhan umum.

Jika implementasi perangkat TIDAK menyertakan aktuator haptik serbaguna seperti itu, maka:

• [7.10/C] HARUS menampilkan nilai salah (false) untuk Vibrator.hasVibrator().

Jika penerapan perangkat MENYERTAKAN setidaknya satu aktuator haptik serbaguna seperti itu, maka:

• [C-1-1] HARUS menampilkan benar (true) untuk Vibrator.hasVibrator().
• TIDAK BOLEH menggunakan aktuator haptik (vibrator) massa berputar eksentrik (ERM).
• HARUS menerapkan semua konstanta publik untuk haptik yang jelas di android.view.HapticFeedbackConstants yaitu (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START, dan GESTURE_END).
• HARUS menerapkan semua konstanta publik untuk haptik yang jelas di android.os.VibrationEffect yaitu (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK, dan EFFECT_DOUBLE_CLICK) dan semua konstanta PRIMITIVE_* publik yang memungkinkan untuk haptik kaya di android.os.VibrationEffect.Composition yaitu (CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). Beberapa primitif ini, seperti LOW_TICK dan SPIN, hanya dapat diterapkan jika vibrator dapat mendukung frekuensi yang relatif rendah.
• HARUS mengikuti panduan untuk memetakan konstanta publik di android.view.HapticFeedbackConstants ke konstanta android.os.VibrationEffect yang direkomendasikan, dengan hubungan amplitudo yang sesuai.
• HARUS menggunakan pemetaan konstanta haptik tertaut ini.
• HARUS mengikuti penilaian kualitas untuk API createOneShot() dan createWaveform().
• HARUS memverifikasi bahwa hasil API android.os.Vibrator.hasAmplitudeControl() publik mencerminkan kemampuan vibratornya dengan benar.
• HARUS memverifikasi kemampuan untuk skalabilitas amplitudo dengan menjalankan android.os.Vibrator.hasAmplitudeControl().

Jika implementasi perangkat mengikuti pemetaan konstanta haptik, maka:

• HARUS memverifikasi status penerapan dengan menjalankan API android.os.Vibrator.areAllEffectsSupported() dan android.os.Vibrator.arePrimitivesSupported().
• HARUS melakukan penilaian kualitas untuk konstanta haptik.
• HARUS memverifikasi dan memperbarui jika diperlukan konfigurasi penggantian untuk primitif yang tidak didukung seperti yang dijelaskan dalam panduan penerapan untuk konstanta.
• HARUS menyediakan dukungan penggantian untuk mengurangi risiko kegagalan seperti yang dijelaskan di sini.

7.11. Kelas Performa Media

Class performa media implementasi perangkat dapat diperoleh dari API android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS. Persyaratan untuk class performa media ditentukan untuk setiap versi Android mulai dari R (versi 30). Nilai khusus 0 menunjukkan bahwa perangkat bukan merupakan kelas performa media.

Jika implementasi perangkat menampilkan nilai bukan nol untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, maka:

• [C-1-1] HARUS menampilkan setidaknya nilai android.os.Build.VERSION_CODES.R.

• [C-1-2] HARUS berupa implementasi perangkat genggam.

• [C-1-3] HARUS memenuhi semua persyaratan untuk "Class Performa Media" yang dijelaskan di bagian 2.2.7.

Dengan kata lain, class performa media di Android T hanya ditentukan untuk perangkat genggam pada versi T, S, atau R.

Lihat bagian 2.2.7 untuk mengetahui persyaratan khusus perangkat.

8. Performa dan Daya

Beberapa kriteria performa dan daya minimum sangat penting untuk pengalaman pengguna dan memengaruhi asumsi dasar yang akan dimiliki developer saat mengembangkan aplikasi.

8.1. Konsistensi Pengalaman Pengguna

Antarmuka pengguna yang lancar dapat diberikan kepada pengguna akhir jika ada persyaratan minimum tertentu untuk memastikan kecepatan frame dan waktu respons yang konsisten untuk aplikasi dan game. Implementasi perangkat, bergantung pada jenis perangkat, MUNGKIN memiliki persyaratan yang dapat diukur untuk latensi antarmuka pengguna dan pengalihan tugas seperti yang dijelaskan di bagian 2.

8.2. Performa Akses I/O File

Menyediakan dasar umum untuk performa akses file yang konsisten pada penyimpanan data pribadi aplikasi (partisi /data) memungkinkan developer aplikasi menetapkan ekspektasi yang tepat yang akan membantu desain software mereka. Implementasi perangkat, bergantung pada jenis perangkat, MUNGKIN memiliki persyaratan tertentu yang dijelaskan di bagian 2 untuk operasi baca dan tulis berikut:

• Performa penulisan berurutan. Diukur dengan menulis file 256 MB menggunakan buffer tulis 10 MB.
• Performa penulisan acak. Diukur dengan menulis file 256 MB menggunakan buffer penulisan 4 KB.
• Performa baca berurutan. Diukur dengan membaca file 256 MB menggunakan buffer tulis 10 MB.
• Performa baca acak. Diukur dengan membaca file 256 MB menggunakan buffer tulis 4 KB.

8.3. Mode Hemat Daya

Jika implementasi perangkat menyertakan fitur untuk meningkatkan pengelolaan daya perangkat yang disertakan dalam AOSP (misalnya, Bucket Aplikasi Standby, Mode Tidur) atau memperluas fitur untuk menerapkan batasan yang lebih ketat daripada Bucket Aplikasi Standby yang DIBATASI, maka:

• [C-1-1] TIDAK BOLEH menyimpang dari penerapan AOSP untuk pemicuan, pemeliharaan, algoritma bangun, dan penggunaan setelan sistem global atau DeviceConfig mode hemat daya App Standby dan Istirahatkan.
• [C-1-2] TIDAK BOLEH menyimpang dari penerapan AOSP untuk penggunaan setelan global atau DeviceConfig guna mengelola pembatasan tugas, alarm, dan jaringan untuk aplikasi di setiap bucket untuk fitur Penghemat daya aplikasi.
• [C-1-3] TIDAK BOLEH menyimpang dari implementasi AOSP untuk jumlah Bucket Aplikasi Standby yang digunakan untuk Aplikasi Standby.
• [C-1-4] HARUS menerapkan Grup Aplikasi Standby dan Mode Istirahatkan seperti yang dijelaskan dalam Pengelolaan Daya.
• [C-1-5] HARUS menampilkan true untuk PowerManager.isPowerSaveMode() saat perangkat dalam mode hemat daya.
• [C-1-6] HARUS menyediakan kemudahan pengguna untuk menampilkan semua aplikasi yang dikecualikan dari mode hemat daya App Standby dan Doze atau pengoptimalan baterai apa pun dan HARUS menerapkan intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS untuk meminta pengguna mengizinkan aplikasi mengabaikan pengoptimalan baterai.
• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk memberikan kemampuan pengguna dalam mengaktifkan dan menonaktifkan fitur penghemat baterai.
• [C-SR-2] SANGAT DISARANKAN untuk memberikan kemudahan pengguna dalam menampilkan semua aplikasi yang dikecualikan dari mode hemat daya App Standby dan Doze.

Jika implementasi perangkat memperluas fitur pengelolaan daya yang disertakan dalam AOSP dan ekstensi tersebut menerapkan batasan yang lebih ketat daripada Bucket Aplikasi Standby Langka, lihat bagian 3.5.1.

Selain mode hemat daya, implementasi perangkat Android DAPAT mengimplementasikan salah satu atau semua dari 4 status daya tidur seperti yang ditentukan oleh Advanced Configuration and Power Interface (ACPI).

Jika implementasi perangkat menerapkan status daya S4 seperti yang ditentukan oleh ACPI, maka:

• [C-1-1] HARUS memasuki status ini hanya setelah pengguna melakukan tindakan eksplisit untuk membuat perangkat dalam status tidak aktif (misalnya, dengan menutup penutup yang merupakan bagian fisik perangkat atau mematikan kendaraan atau televisi) dan sebelum pengguna mengaktifkan kembali perangkat (misalnya, dengan membuka penutup atau menyalakan kembali kendaraan atau televisi).

Jika implementasi perangkat menerapkan status daya S3 seperti yang ditentukan oleh ACPI, maka:

• [C-2-1] HARUS memenuhi C-1-1 di atas, atau, HARUS memasuki status S3 hanya jika aplikasi pihak ketiga tidak memerlukan resource sistem (misalnya, layar, CPU).

  Sebaliknya, HARUS keluar dari status S3 saat aplikasi pihak ketiga memerlukan resource sistem, seperti yang dijelaskan di SDK ini.

  Misalnya, saat aplikasi pihak ketiga meminta agar layar tetap aktif melalui FLAG_KEEP_SCREEN_ON atau agar CPU tetap berjalan melalui PARTIAL_WAKE_LOCK, perangkat TIDAK BOLEH memasuki status S3 kecuali, seperti yang dijelaskan dalam C-1-1, pengguna telah melakukan tindakan eksplisit untuk membuat perangkat dalam status tidak aktif. Sebaliknya, saat tugas yang diterapkan aplikasi pihak ketiga melalui JobScheduler dipicu atau Firebase Cloud Messaging dikirim ke aplikasi pihak ketiga, perangkat HARUS keluar dari status S3 kecuali pengguna telah menempatkan perangkat dalam status tidak aktif. Ini bukan contoh yang komprehensif dan AOSP menerapkan sinyal aktif yang ekstensif yang memicu pengaktifan dari status ini.

8.4. Akuntansi Konsumsi Daya

Akuntansi dan pelaporan konsumsi daya yang lebih akurat memberikan insentif dan alat kepada developer aplikasi untuk mengoptimalkan pola penggunaan daya aplikasi.

Implementasi perangkat:

• [C-SR-1] SANGAT DISARANKAN untuk menyediakan profil daya per komponen yang menentukan nilai konsumsi arus untuk setiap komponen hardware dan perkiraan pengurasan baterai yang disebabkan oleh komponen dari waktu ke waktu seperti yang didokumentasikan di situs Android Open Source Project.
• [C-SR-2] SANGAT DISARANKAN untuk melaporkan semua nilai konsumsi daya dalam satuan miliampere jam (mAh).
• [C-SR-3] SANGAT DISARANKAN untuk melaporkan konsumsi daya CPU per UID setiap proses. Project Open Source Android memenuhi persyaratan melalui penerapan modul kernel uid_cputime.
• [C-SR-4] SANGAT DIREKOMENDASIKAN untuk membuat penggunaan daya ini tersedia melalui perintah shell adb shell dumpsys batterystats bagi developer aplikasi.
• HARUS dikaitkan dengan komponen hardware itu sendiri jika tidak dapat mengatribusikan penggunaan daya komponen hardware ke aplikasi.

8.5. Performa yang Konsisten

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

Implementasi perangkat:

• [C-0-1] HARUS melaporkan dukungan Mode Performa Berkelanjutan secara akurat melalui metode API PowerManager.isSustainedPerformanceModeSupported().

• HARUS mendukung Mode Performa Berkelanjutan.

Jika implementasi perangkat melaporkan dukungan Mode Performa Berkelanjutan, maka:

• [C-1-1] HARUS memberikan tingkat performa yang konsisten untuk aplikasi latar depan teratas selama setidaknya 30 menit, saat aplikasi memintanya.
• [C-1-2] HARUS mematuhi Window.setSustainedPerformanceMode() API dan API terkait lainnya.

Jika implementasi perangkat menyertakan dua atau lebih inti CPU, maka:

• HARUS menyediakan setidaknya satu inti eksklusif yang dapat dicadangkan oleh aplikasi latar depan teratas.

Jika implementasi perangkat mendukung pencadangan satu core eksklusif untuk aplikasi latar depan teratas, maka:

• [C-2-1] HARUS melaporkan melalui metode API Process.getExclusiveCores() nomor ID core eksklusif yang dapat dicadangkan oleh aplikasi latar depan teratas.
• [C-2-2] TIDAK BOLEH mengizinkan proses ruang pengguna apa pun kecuali driver perangkat yang digunakan oleh aplikasi untuk berjalan di core eksklusif, tetapi MUNGKIN mengizinkan beberapa proses kernel berjalan sesuai kebutuhan.

Jika penerapan perangkat tidak mendukung core eksklusif, maka:

• [C-3-1] HARUS menampilkan daftar kosong melalui metode API Process.getExclusiveCores().

8.6. Batas Memori Aplikasi

9. Kompatibilitas Model Keamanan

Implementasi perangkat:

• [C-0-1] HARUS menerapkan model keamanan yang konsisten dengan model keamanan platform Android sebagaimana ditentukan dalam dokumen referensi Keamanan dan Izin di API dalam dokumentasi developer Android.

• [C-0-2] HARUS mendukung penginstalan aplikasi yang ditandatangani sendiri tanpa memerlukan izin/sertifikat tambahan dari pihak ketiga/otoritas mana pun.

Jika implementasi perangkat menyatakan fitur android.hardware.security.model.compatible, maka:

• [C-1-1] HARUS mendukung persyaratan yang tercantum dalam subbagian berikut.

9.1. Izin

Implementasi perangkat:

• [C-0-1] HARUS mendukung model izin Android dan Model Peran Android seperti yang ditentukan dalam dokumentasi developer Android. Khususnya, mereka HARUS menerapkan setiap izin dan peran yang ditentukan seperti yang dijelaskan dalam dokumentasi SDK; tidak ada izin dan tidak ada peran yang boleh dihilangkan, diubah, atau diabaikan.

• DAPAT menambahkan izin tambahan, asalkan string ID izin baru tidak berada di namespace android.\*.

• [C-0-2] Izin dengan protectionLevel PROTECTION_FLAG_PRIVILEGED HANYA boleh diberikan kepada aplikasi yang sudah diinstal sebelumnya di jalur istimewa image sistem (serta file APEX) dan berada dalam subset izin yang secara eksplisit diizinkan untuk setiap aplikasi. Implementasi AOSP memenuhi persyaratan ini dengan membaca dan mematuhi izin yang diizinkan secara eksplisit untuk setiap aplikasi dari file di jalur etc/permissions/ dan menggunakan jalur system/priv-app sebagai jalur istimewa.

• [C-SR-1] Izin dengan protectionLevel PROTECTION_SIGNATURE SANGAT DISARANKAN untuk hanya diberikan kepada:

  • Aplikasi yang sudah diinstal di image sistem (serta file APEX).

  • Aplikasi yang diizinkan dengan izin yang diizinkan jika tidak disertakan dalam image sistem.

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

Implementasi perangkat:

• [C-0-3] 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.

• [C-0-5] TIDAK BOLEH memberikan izin runtime apa pun ke aplikasi kecuali:

  • Aplikasi diinstal pada saat pengiriman perangkat, DAN
  • Izin pengguna dapat diperoleh sebelum aplikasi menggunakan izin,

  ATAU

  • Izin runtime diberikan oleh kebijakan pemberian izin default atau untuk memegang peran platform.

• [C-0-6] HARUS memberikan izin android.permission.RECOVER_KEYSTORE hanya kepada aplikasi sistem yang mendaftarkan Agen Pemulihan yang diamankan dengan benar. Agen Pemulihan yang diamankan dengan benar didefinisikan sebagai agen software di perangkat yang disinkronkan dengan penyimpanan jarak jauh di luar perangkat, yang dilengkapi dengan hardware aman dengan perlindungan yang setara atau lebih kuat daripada yang dijelaskan dalam Layanan Google Cloud Key Vault untuk mencegah serangan brute force pada faktor pengetahuan layar kunci.

Implementasi perangkat:

• [C-0-7] HARUS mematuhi properti izin akses lokasi Android saat aplikasi meminta data lokasi atau aktivitas fisik melalui API Android standar atau mekanisme eksklusif. Data tersebut mencakup, tetapi tidak terbatas pada:

  • Lokasi perangkat (misalnya, lintang dan bujur) seperti yang dijelaskan dalam Pasal 9.8.8.

  • Informasi yang dapat digunakan untuk menentukan atau memperkirakan lokasi perangkat (misalnya, SSID, BSSID, ID Sel, atau lokasi jaringan yang terhubung ke perangkat).

  • Aktivitas fisik pengguna atau klasifikasi aktivitas fisik.

Secara khusus, penerapan perangkat:

• [C-0-8] HARUS mendapatkan izin pengguna untuk mengizinkan aplikasi mengakses data lokasi atau aktivitas fisik.

• [C-0-9] HARUS memberikan izin runtime HANYA kepada aplikasi yang memiliki izin yang memadai seperti yang dijelaskan di SDK. Misalnya, TelephonyManager#getServiceState memerlukan android.permission.ACCESS_FINE_LOCATION.

Satu-satunya pengecualian untuk properti izin lokasi Android di atas adalah untuk aplikasi yang tidak mengakses Lokasi untuk mendapatkan atau mengidentifikasi lokasi pengguna; khususnya:

• Saat aplikasi memiliki izin RADIO_SCAN_WITHOUT_LOCATION.

• Untuk tujuan konfigurasi dan penyiapan perangkat, tempat aplikasi sistem memiliki izin NETWORK_SETTINGS atau NETWORK_SETUP_WIZARD.

Izin dapat ditandai sebagai dibatasi sehingga mengubah perilakunya.

• [C-0-10] Izin yang ditandai dengan tanda hardRestricted TIDAK BOLEH diberikan ke aplikasi kecuali:

  • File APK aplikasi berada di partisi sistem.

  • Pengguna menetapkan peran yang terkait dengan izin hardRestricted ke aplikasi.

  • Penginstal memberikan hardRestricted ke aplikasi.

  • Aplikasi diberi hardRestricted pada versi Android sebelumnya.

• [C-0-11] Aplikasi yang memiliki izin softRestricted HANYA boleh mendapatkan akses terbatas dan TIDAK boleh mendapatkan akses penuh hingga dimasukkan dalam daftar yang diizinkan seperti yang dijelaskan dalam SDK, yang mana akses penuh dan terbatas ditentukan untuk setiap izin softRestricted (misalnya, READ_EXTERNAL_STORAGE).

• [C-0-12] TIDAK BOLEH menyediakan fungsi atau API kustom apa pun untuk melewati batasan izin yang ditentukan dalam API setPermissionPolicy dan setPermissionGrantState.

• [C-0-13] HARUS menggunakan AppOpsManager API untuk mencatat dan melacak setiap akses data terprogram yang dilindungi oleh izin berbahaya dari aktivitas dan layanan Android.

• [C-0-14] HANYA boleh menetapkan peran ke aplikasi dengan fungsi yang memenuhi persyaratan peran.

• [C-0-15] TIDAK BOLEH menentukan peran yang merupakan duplikat atau fungsi superset dari peran yang ditentukan oleh platform.

Jika perangkat menyertakan sensor data yang mengekspos biometrik terkait kesehatan seperti detak jantung atau suhu kulit, biometrik tersebut:

• [C-0-16] HARUS dilindungi oleh izin platform dari android.permission-group.HEALTH, jika ada izin yang sesuai di HealthPermissions.

• [C-0-17] HARUS, jika tidak ada izin platform yang cocok dengan jenis data yang diinginkan, dilindungi oleh izin sistem kustom. (Misalnya, ELECTROCARDIOGRAM.)

Jika perangkat melaporkan android.software.managed_users, perangkat tersebut:

• [C-1-1] TIDAK BOLEH memiliki izin berikut yang diberikan secara diam-diam oleh admin:

  • Lokasi (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
  • Kamera (CAMERA)
  • Mikrofon (RECORD_AUDIO)
  • Sensor tubuh (BODY_SENSORS)
  • Kesehatan (HealthPermissions)
  • Aktivitas fisik (ACTIVITY_RECOGNITION)

Jika perangkat melaporkan android.software.managed_users, perangkat tersebut:

• [C-1-1] TIDAK BOLEH memiliki izin berikut yang diberikan secara diam-diam oleh admin:

  • Lokasi (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
  • Kamera (CAMERA)
  • Mikrofon (RECORD_AUDIO)
  • Sensor tubuh (BODY_SENSORS)
  • Aktivitas fisik (ACTIVITY_RECOGNITION)

Jika implementasi perangkat menyediakan kemudahan pengguna untuk memilih aplikasi mana yang dapat menggambar di atas aplikasi lain dengan aktivitas yang menangani intent ACTION_MANAGE_OVERLAY_PERMISSION, aplikasi tersebut:

• [C-2-1] HARUS memastikan bahwa semua aktivitas dengan filter intent untuk intent ACTION_MANAGE_OVERLAY_PERMISSION memiliki layar UI yang sama, terlepas dari aplikasi yang memulai atau informasi yang diberikannya.

Jika implementasi perangkat melaporkan android.software.device_admin, berarti perangkat tersebut:

• [C-3-1] HARUS menampilkan pernyataan penyangkalan selama penyiapan perangkat yang dikelola sepenuhnya (penyiapan pemilik perangkat) yang menyatakan bahwa admin IT akan memiliki kemampuan untuk mengizinkan aplikasi mengontrol setelan di ponsel termasuk mikrofon, kamera, dan lokasi, dengan opsi bagi pengguna untuk melanjutkan penyiapan atau keluar dari penyiapan KECUALI jika admin telah memilih tidak mengizinkan kontrol izin di perangkat.

Jika penerapan perangkat menginstal sebelumnya paket apa pun yang memiliki peran Inti UI Sistem, Inti Audio Ambient Sistem, Inti Audio Sistem, Inti Notifikasi Sistem, Inti Teks Sistem, atau Inti Visual Sistem, paket tersebut:

• [C-4-1] HARUS memenuhi semua persyaratan yang diuraikan untuk penerapan perangkat di bagian 9.8.6. Data tingkat OS dan sekitar dan 9.8.15. Penerapan API dengan sandbox.

9.2. UID dan Isolasi Proses

Implementasi perangkat:

• [C-0-1] HARUS mendukung model sandbox aplikasi Android, yang setiap aplikasinya berjalan sebagai UID gaya Unix yang unik dan dalam proses terpisah.
• [C-0-2] HARUS mendukung menjalankan beberapa aplikasi sebagai ID pengguna Linux yang sama, asalkan aplikasi ditandatangani dan dibuat dengan benar, sebagaimana ditentukan dalam referensi Keamanan dan Izin.

9.3. Izin Sistem File

Implementasi perangkat:

• [C-0-1] HARUS mendukung model izin akses file Android seperti yang ditentukan dalam referensi Keamanan dan Izin.

9.4. Lingkungan Eksekusi Alternatif

Implementasi perangkat HARUS menjaga konsistensi model keamanan dan izin Android, meskipun menyertakan lingkungan runtime yang menjalankan aplikasi menggunakan software atau teknologi lain selain Format yang Dapat Dieksekusi Dalvik atau kode native. Dengan kata lain:

• [C-0-1] Lingkungan runtime alternatif itu sendiri HARUS berupa aplikasi Android, dan mematuhi model keamanan Android standar, seperti yang dijelaskan di tempat lain dalam bagian 9.

• [C-0-2] Lingkungan runtime alternatif TIDAK BOLEH diberi akses ke resource yang dilindungi oleh izin yang tidak diminta dalam file AndroidManifest.xml lingkungan runtime melalui mekanisme <uses-permission>.

• [C-0-3] Lingkungan runtime alternatif TIDAK BOLEH mengizinkan aplikasi menggunakan fitur yang dilindungi oleh izin Android yang dibatasi untuk aplikasi sistem.

• [C-0-4] Lingkungan runtime alternatif HARUS mematuhi model sandbox Android dan aplikasi yang diinstal menggunakan lingkungan runtime alternatif TIDAK BOLEH menggunakan kembali sandbox aplikasi lain yang diinstal di perangkat, kecuali melalui mekanisme standar Android berupa ID pengguna bersama dan sertifikat penandatanganan.

• [C-0-5] Lingkungan runtime alternatif TIDAK BOLEH diluncurkan dengan, memberikan, atau diberikan akses ke sandbox yang sesuai dengan aplikasi Android lainnya.

• [C-0-6] Lingkungan runtime alternatif TIDAK BOLEH diluncurkan dengan, diberi, atau memberikan hak istimewa superuser (root), atau ID pengguna lainnya, kepada aplikasi lain.

• [C-0-7] Jika file .apk runtime alternatif disertakan dalam image sistem implementasi perangkat, file tersebut HARUS ditandatangani dengan kunci yang berbeda dari kunci yang digunakan untuk menandatangani aplikasi lain yang disertakan dengan implementasi perangkat.

• [C-0-8] Saat menginstal aplikasi, runtime alternatif HARUS mendapatkan izin pengguna untuk izin Android yang digunakan oleh aplikasi.

• [C-0-9] Saat aplikasi perlu menggunakan resource perangkat yang memiliki izin Android yang sesuai (seperti Kamera, GPS, dll.), runtime alternatif HARUS memberi tahu pengguna bahwa aplikasi akan dapat mengakses resource tersebut.

• [C-0-10] Jika lingkungan runtime tidak mencatat kemampuan aplikasi dengan cara ini, lingkungan runtime HARUS mencantumkan semua izin yang dimiliki oleh runtime itu sendiri saat menginstal aplikasi apa pun menggunakan runtime tersebut.

• Lingkungan runtime alternatif HARUS menginstal aplikasi melalui PackageManager ke dalam sandbox Android terpisah (ID pengguna Linux, dll.).

• Runtime alternatif DAPAT menyediakan satu sandbox Android yang digunakan bersama oleh semua aplikasi yang menggunakan runtime alternatif.

9.5. Dukungan Multi-Pengguna

Android menyertakan dukungan untuk beberapa pengguna dan memberikan dukungan untuk isolasi pengguna penuh dan profil pengguna clone dengan isolasi parsial (yaitu satu profil pengguna tambahan berjenis android.os.usertype.profile.CLONE).

• Implementasi perangkat DAPAT tetapi SEBAIKNYA TIDAK mengaktifkan multi-pengguna jika menggunakan media yang dapat dilepas untuk penyimpanan eksternal utama.

Jika implementasi perangkat mencakup dukungan untuk beberapa pengguna, implementasi tersebut:

• [C-1-2] HARUS, untuk setiap pengguna, menerapkan model keamanan yang konsisten dengan model keamanan platform Android sebagaimana ditentukan dalam dokumen referensi Keamanan dan Izin di API.

• [C-1-3] HARUS memiliki direktori penyimpanan aplikasi bersama yang terpisah dan terisolasi (alias /sdcard) untuk setiap instance pengguna.

• [C-1-4] HARUS memastikan bahwa aplikasi yang dimiliki dan berjalan atas nama pengguna tertentu tidak dapat mencantumkan, membaca, atau menulis ke file yang dimiliki oleh pengguna lain, meskipun data kedua pengguna disimpan di volume atau sistem file yang sama.

• [C-1-5] HARUS mengenkripsi konten kartu SD saat multi-pengguna diaktifkan menggunakan kunci yang disimpan hanya di media yang tidak dapat dilepas yang hanya dapat diakses oleh sistem jika implementasi perangkat menggunakan media yang dapat dilepas untuk API penyimpanan eksternal. Karena tindakan ini akan membuat media tidak dapat dibaca oleh PC host, implementasi perangkat akan diwajibkan untuk beralih ke MTP atau sistem serupa untuk memberi PC host akses ke data pengguna saat ini.

Jika implementasi perangkat mencakup dukungan untuk beberapa pengguna, maka untuk semua pengguna kecuali pengguna yang dibuat secara khusus untuk menjalankan instance ganda dari aplikasi yang sama, mereka:

• [C-2-1] HARUS memiliki direktori penyimpanan aplikasi bersama yang terpisah dan terisolasi (alias /sdcard) untuk setiap instance pengguna.

• [C-2-2] HARUS memastikan bahwa aplikasi yang dimiliki dan berjalan atas nama pengguna tertentu tidak dapat mencantumkan, membaca, atau menulis ke file yang dimiliki oleh pengguna lain, meskipun data kedua pengguna disimpan di volume atau sistem file yang sama.

Implementasi perangkat DAPAT membuat satu profil pengguna tambahan berjenis android.os.usertype.profile.CLONE terhadap pengguna utama (dan hanya terhadap pengguna utama) untuk tujuan menjalankan dua instance aplikasi yang sama. Dua instance ini berbagi penyimpanan yang sebagian terisolasi, ditampilkan kepada pengguna akhir di peluncur secara bersamaan dan muncul di tampilan terbaru yang sama. Misalnya, hal ini dapat digunakan untuk mendukung pengguna menginstal dua instance terpisah dari satu aplikasi di perangkat dual-SIM.

Jika implementasi perangkat membuat profil pengguna tambahan yang dibahas di atas, maka:

• [C-3-1] HANYA boleh memberikan akses ke penyimpanan atau data yang sudah dapat diakses oleh profil pengguna induk atau dimiliki langsung oleh profil pengguna tambahan ini.

• [C-3-2] TIDAK BOLEH memiliki ini sebagai profil kerja.

• [C-3-3] HARUS mengisolasi direktori data aplikasi pribadi dari akun pengguna induk.

• [C-3-4] TIDAK BOLEH mengizinkan pembuatan profil pengguna tambahan jika ada Pemilik Perangkat yang di-provisioning (lihat bagian 3.9.1) atau mengizinkan Pemilik Perangkat di-provisioning tanpa menghapus profil pengguna tambahan terlebih dahulu.

Jika implementasi perangkat membuat profil pengguna tambahan yang dibahas di atas, maka:

• [C-4-1] HARUS mengizinkan intent di bawah yang berasal dari profil tambahan ditangani oleh aplikasi pengguna utama di perangkat:

  • Intent.ACTION_VIEW
  • Intent.ACTION_SENDTO
  • Intent.ACTION_SEND
  • Intent.ACTION_EDIT
  • Intent.ACTION_INSERT
  • Intent.ACTION_INSERT_OR_EDIT
  • Intent.ACTION_SEND_MULTIPLE
  • Intent.ACTION_PICK
  • Intent.ACTION_GET_CONTENT
  • MediaStore.ACTION_IMAGE_CAPTURE
  • MediaStore.ACTION_VIDEO_CAPTURE

• [C-4-2] HARUS mewarisi semua batasan pengguna kebijakan perangkat dan restrictions(list below) non-pengguna yang dipilih yang diterapkan pada pengguna utama perangkat ke profil pengguna tambahan ini.

  • setScreenCaptureDisabled
  • setAccountManagementDisabled
  • setCameraDisabled
  • setPermittedInputMethods
  • setApplicationHidden
  • setPersonalAppsSuspended

• [C-4-3] HANYA boleh mengizinkan penulisan kontak dari profil tambahan ini melalui intent berikut:

  • ContactsContract.Intents.Insert.ACTION
  • Intent.ACTION_PICK
  • Intent.ACTION_EDIT
  • Intent.ACTION_INSERT_OR_EDIT

• [C-4-4] TIDAK BOLEH menjalankan sinkronisasi kontak untuk aplikasi yang berjalan di profil pengguna tambahan ini.

• [C-4-5] HANYA boleh mengizinkan aplikasi di profil tambahan yang memiliki aktivitas peluncur untuk mengakses kontak yang sudah dapat diakses oleh profil pengguna induk.

Jika implementasi perangkat membuat profil pengguna tambahan yang dibahas di atas, implementasi tersebut mencakup setidaknya satu kamera, dan aplikasi kamera yang telah diinstal sebelumnya menangani intent MediaStore.ACTION_MOTION_PHOTO_CAPTURE atau MediaStore.ACTION_MOTION_PHOTO_CAPTURE_SECURE, maka:

• [C-5-1] HARUS mengizinkan aplikasi pengguna utama menangani intent ini yang berasal dari profil pengguna tambahan tersebut.

9.6. Peringatan SMS Premium

Android menyertakan dukungan untuk memperingatkan pengguna tentang pesan SMS premium keluar. Pesan SMS Premium adalah pesan teks yang dikirim ke layanan yang terdaftar pada operator yang mungkin menimbulkan biaya bagi pengguna.

Jika penerapan perangkat menyatakan dukungan untuk android.hardware.telephony, maka:

• [C-1-1] 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 penerapan yang memenuhi persyaratan ini.

9.7. Fitur Keamanan

Implementasi perangkat HARUS memastikan kepatuhan terhadap fitur keamanan di kernel dan platform seperti yang dijelaskan di bawah.

Sandbox Android mencakup fitur yang menggunakan sistem kontrol akses wajib (MAC) Security-Enhanced Linux (SELinux), sandbox seccomp, dan fitur keamanan lainnya di kernel Linux. Implementasi perangkat:

• [C-0-1] HARUS mempertahankan kompatibilitas dengan aplikasi yang ada, bahkan saat SELinux atau fitur keamanan lainnya diterapkan di bawah framework Android.

• [C-0-2] TIDAK BOLEH memiliki antarmuka pengguna yang terlihat saat pelanggaran keamanan terdeteksi dan berhasil diblokir oleh fitur keamanan yang diterapkan di bawah framework Android, tetapi MUNGKIN memiliki antarmuka pengguna yang terlihat saat pelanggaran keamanan yang tidak diblokir terjadi sehingga menyebabkan eksploitasi yang berhasil.

• [C-0-3] TIDAK BOLEH membuat SELinux atau fitur keamanan lainnya yang diterapkan di bawah framework Android dapat dikonfigurasi oleh pengguna atau developer aplikasi.

• [C-0-4] TIDAK BOLEH mengizinkan aplikasi yang dapat memengaruhi aplikasi lain melalui API (seperti Device Administration API) untuk mengonfigurasi kebijakan yang merusak kompatibilitas.

• [C-0-5] HARUS membagi framework media menjadi beberapa proses sehingga setiap proses dapat diberi akses yang lebih terbatas seperti yang dijelaskan di situs Proyek Open Source Android.

• [C-0-6] HARUS menerapkan mekanisme sandbox aplikasi kernel yang memungkinkan pemfilteran panggilan sistem menggunakan kebijakan yang dapat dikonfigurasi dari program multithread. 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.

Fitur perlindungan mandiri dan integritas kernel merupakan bagian integral dari keamanan Android. Implementasi perangkat:

• [C-0-7] HARUS menerapkan mekanisme perlindungan buffer overflow stack kernel. Contoh mekanisme tersebut adalah CC_STACKPROTECTOR_REGULAR dan CONFIG_CC_STACKPROTECTOR_STRONG.

• [C-0-8] HARUS menerapkan perlindungan memori kernel yang ketat di mana kode yang dapat dieksekusi bersifat hanya baca, data hanya baca tidak dapat dieksekusi dan tidak dapat ditulis, serta data yang dapat ditulis tidak dapat dieksekusi (misalnya, rodata dan CONFIG_STRICT_KERNEL_RWX diaktifkan).

• [C-0-9] HARUS menerapkan pemeriksaan batas ukuran objek statis dan dinamis salinan antara ruang pengguna dan ruang kernel (misalnya, CONFIG_HARDENED_USERCOPY) di perangkat yang awalnya dikirim dengan level API 28 atau yang lebih tinggi.

• [C-0-10] TIDAK BOLEH mengeksekusi memori ruang pengguna saat dieksekusi dalam mode kernel (misalnya, PXN hardware, atau diemulasi melalui CONFIG_CPU_SW_DOMAIN_PAN atau CONFIG_ARM64_SW_TTBR0_PAN) di perangkat yang awalnya dikirim dengan API level 28 atau yang lebih tinggi.

• [C-0-11] TIDAK BOLEH membaca atau menulis memori ruang pengguna di kernel di luar API akses usercopy normal (misalnya, PAN hardware, atau diemulasi melalui CONFIG_CPU_SW_DOMAIN_PAN atau CONFIG_ARM64_SW_TTBR0_PAN) di perangkat yang awalnya dikirim dengan level API 28 atau yang lebih tinggi.

• [C-0-12] HARUS menerapkan isolasi tabel halaman kernel jika hardware rentan terhadap CVE-2017-5754 di semua perangkat yang awalnya dikirim dengan level API 28 atau yang lebih tinggi (misalnya, CONFIG_PAGE_TABLE_ISOLATION atau CONFIG_UNMAP_KERNEL_AT_EL0).

• [C-0-13] HARUS menerapkan penguatan prediksi cabang jika hardware rentan terhadap CVE-2017-5715 di semua perangkat yang awalnya dikirim dengan level API 28 atau yang lebih tinggi (misalnya, CONFIG_HARDEN_BRANCH_PREDICTOR).

• [C-SR-1] SANGAT DISARANKAN untuk menjaga data kernel yang ditulis hanya selama inisialisasi ditandai hanya baca setelah inisialisasi (misalnya, __ro_after_init).

• [C-SR-2] SANGAT DISARANKAN untuk mengacak tata letak kode kernel dan memori, serta untuk menghindari eksposur yang akan membahayakan pengacakan (misalnya, CONFIG_RANDOMIZE_BASE dengan entropi bootloader melalui /chosen/kaslr-seed Device Tree node atau EFI_RNG_PROTOCOL).

• [C-SR-3] SANGAT DISARANKAN untuk mengaktifkan integritas alur kontrol (CFI) di kernel untuk memberikan perlindungan tambahan terhadap serangan penggunaan ulang kode (misalnya, CONFIG_CFI_CLANG dan CONFIG_SHADOW_CALL_STACK).

• [C-SR-4] SANGAT DISARANKAN untuk tidak menonaktifkan Control-Flow Integrity (CFI), Shadow Call Stack (SCS), atau Integer Overflow Sanitization (IntSan) pada komponen yang mengaktifkannya.

• [C-SR-5] SANGAT DISARANKAN untuk mengaktifkan CFI, SCS, dan IntSan untuk komponen ruang pengguna tambahan yang sensitif terhadap keamanan seperti yang dijelaskan dalam CFI dan IntSan.

• [C-SR-6] SANGAT DISARANKAN untuk mengaktifkan inisialisasi stack di kernel untuk mencegah penggunaan variabel lokal yang belum diinisialisasi (CONFIG_INIT_STACK_ALL atau CONFIG_INIT_STACK_ALL_ZERO). Selain itu, implementasi perangkat SEBAIKNYA TIDAK mengasumsikan nilai yang digunakan oleh kompiler untuk menginisialisasi lokal.

• [C-SR-7] SANGAT DISARANKAN untuk mengaktifkan inisialisasi heap di kernel untuk mencegah penggunaan alokasi heap yang belum diinisialisasi (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) dan TIDAK BOLEH mengasumsikan nilai yang digunakan oleh kernel untuk menginisialisasi alokasi tersebut.

Jika implementasi perangkat menggunakan kernel Linux yang dapat mendukung SELinux, maka:

• [C-1-1] HARUS menerapkan SELinux.

• [C-1-2] HARUS menetapkan SELinux ke mode pemberlakuan global.

• [C-1-3] HARUS mengonfigurasi semua domain dalam mode penerapan. Tidak ada domain mode permisif yang diizinkan, termasuk domain khusus untuk perangkat/vendor.

• [C-1-5] HARUS menjalankan aplikasi pihak ketiga yang menargetkan level API 28 atau yang lebih tinggi di sandbox SELinux per aplikasi dengan batasan SELinux per aplikasi pada direktori data pribadi setiap aplikasi.

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

Jika implementasi perangkat menggunakan kernel selain Linux atau Linux tanpa SELinux, maka:

• [C-2-1] HARUS menggunakan sistem kontrol akses wajib yang setara dengan SELinux.

Jika implementasi perangkat menggunakan perangkat I/O yang mendukung DMA, maka:

• [C-SR-9] SANGAT DISARANKAN untuk mengisolasi setiap perangkat I/O yang mendukung DMA, menggunakan IOMMU (misalnya, ARM SMMU).

Android berisi beberapa fitur pertahanan mendalam yang merupakan bagian integral dari keamanan perangkat. Selain itu, Android berfokus pada pengurangan kelas utama bug umum yang berkontribusi pada kualitas dan keamanan yang buruk.

Untuk mengurangi bug memori, implementasi perangkat:

• [C-SR-10] SANGAT DISARANKAN untuk diuji menggunakan alat deteksi error memori ruang pengguna seperti MTE untuk perangkat ARMv9, HWASan untuk perangkat ARMv8+, atau ASan untuk jenis perangkat lainnya.

• [C-SR-11] SANGAT DISARANKAN untuk diuji menggunakan alat deteksi error memori kernel seperti KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS untuk perangkat ARMv9, CONFIG_KASAN_SW_TAGS untuk perangkat ARMv8, atau CONFIG_KASAN_GENERIC untuk jenis perangkat lainnya).

• [C-SR-12] SANGAT DISARANKAN untuk menggunakan alat deteksi error memori dalam produksi seperti MTE, GWP-ASan, dan KFENCE.

Jika implementasi perangkat menggunakan TEE berbasis Arm TrustZone, implementasi tersebut:

• [C-SR-13] SANGAT DISARANKAN untuk menggunakan protokol standar untuk berbagi memori, antara Android dan TEE, seperti Arm Firmware Framework untuk Armv8-A (FF-A).

• [C-SR-14] SANGAT DISARANKAN untuk membatasi aplikasi tepercaya agar hanya mengakses memori yang telah dibagikan secara eksplisit kepada aplikasi tersebut melalui protokol di atas. Jika perangkat memiliki dukungan untuk tingkat pengecualian Arm S-EL2, hal ini harus diterapkan oleh pengelola partisi aman. Jika tidak, hal ini harus diterapkan oleh TEE OS.

Teknologi Keamanan Memori adalah teknologi yang memitigasi setidaknya kelas bug berikut dengan probabilitas tinggi (> 90%) dalam aplikasi yang menggunakan opsi manifes android:memtagMode:

• luapan buffer heap
• penggunaan setelah tersedia
• gratis ganda
• wild free (membebaskan pointer non-malloc)

Implementasi perangkat:

• [C-SR-15] SANGAT DISARANKAN untuk menetapkan ro.arm64.memtag.bootctl_supported.

Jika implementasi perangkat menyetel properti sistem ro.arm64.memtag.bootctl_supported ke benar (true), maka:

• [C-3-1] HARUS mengizinkan properti sistem arm64.memtag.bootctl menerima daftar nilai berikut yang dipisahkan koma, dengan efek yang diinginkan diterapkan pada reboot berikutnya:

  • memtag: teknologi Keamanan Memori seperti yang dijelaskan di atas diaktifkan

  • memtag-once: teknologi Keamanan Memori seperti yang dijelaskan di atas diaktifkan untuk sementara, dan dinonaktifkan secara otomatis saat booting ulang berikutnya

  • memtag-off: teknologi Keamanan Memori seperti yang dijelaskan di atas dinonaktifkan

• [C-3-2] HARUS mengizinkan pengguna shell untuk menyetel arm64.memtag.bootctl.

• [C-3-3] HARUS mengizinkan proses apa pun untuk membaca arm64.memtag.bootctl.

• [C-3-4] HARUS menyetel arm64.memtag.bootctl ke status yang saat ini diminta saat booting, dan HARUS juga mengupdate properti, jika implementasi perangkat memungkinkan untuk mengubah status tanpa mengubah properti sistem.

• [C-SR-16] SANGAT DISARANKAN untuk menampilkan Setelan Developer yang menyetel memtag-once dan memulai ulang perangkat. Dengan bootloader yang kompatibel, Android Open Source Project memenuhi persyaratan di atas melalui protokol bootloader MTE.

Jika perangkat menyatakan android.hardware.telephony, mendukung kemampuan radio CAPABILITY_USES_ALLOWED_NETWORK_TYPES_BITMASK, dan menyertakan modem seluler yang mendukung koneksi 2G, penerapan perangkat:

• [C-SR-17] SANGAT DIREKOMENDASIKAN untuk memberikan kemudahan pengguna dalam menonaktifkan dan mengaktifkan 2G.

• [C-SR-18] SANGAT DISARANKAN untuk tidak mengganti kemampuan pengguna untuk menonaktifkan dan mengaktifkan 2G melalui entitas perangkat lain, kecuali oleh admin perangkat menggunakan UserManager.DISALLOW_CELLULAR_2G.

• [C-SR-19] SANGAT DISARANKAN untuk memanggil TelephonyManager.setAllowedNetworkTypesForReason dengan alasan ALLOWED_NETWORK_TYPES_REASON_ENABLE_2G untuk memenuhi persyaratan ini.

• [C-SR-20] SANGAT DISARANKAN untuk menentukan dukungan modem Seluler untuk 2G dengan memanggil TelephonyManager.getSupportedRadioAccessFamily. Lihat Menonaktifkan 2G untuk mengetahui detailnya.

9.8. Privasi

9.8.1. Histori Penggunaan

Android menyimpan histori pilihan pengguna dan mengelola histori tersebut dengan UsageStatsManager.

Implementasi perangkat:

• [C-0-1] HARUS menyimpan histori pengguna tersebut selama periode retensi yang wajar.

• [C-SR-1] SANGAT DISARANKAN untuk mempertahankan periode retensi 14 hari seperti yang dikonfigurasi secara default dalam penerapan AOSP.

Android menyimpan peristiwa sistem menggunakan ID StatsLog, dan mengelola histori tersebut melalui StatsManager dan IncidentManager System API.

Implementasi perangkat:

• [C-0-2] HANYA boleh menyertakan kolom yang ditandai dengan DEST_AUTOMATIC dalam laporan insiden yang dibuat oleh class IncidentManager System API.

• [C-0-3] TIDAK BOLEH menggunakan ID peristiwa sistem untuk mencatat peristiwa lain selain yang dijelaskan dalam dokumen SDK StatsLog. Jika peristiwa sistem tambahan dicatat ke dalam log, peristiwa tersebut MUNGKIN menggunakan ID atom yang berbeda dalam rentang antara 100.000 dan 200.000.

9.8.2. Merekam

Implementasi perangkat:

• [C-0-1] TIDAK BOLEH memuat ulang atau mendistribusikan komponen software di luar kotak yang mengirimkan informasi pribadi pengguna (misalnya, penekanan tombol, teks yang ditampilkan di layar, laporan bug) dari perangkat tanpa izin pengguna atau pemberitahuan berkelanjutan yang jelas.

• [C-0-2] HARUS menampilkan peringatan kepada pengguna dan mendapatkan izin eksplisit pengguna yang mengizinkan informasi sensitif apa pun yang ditampilkan di layar pengguna untuk direkam setiap kali sesi untuk merekam atau mentransmisikan layar diaktifkan melalui MediaProjection.createVirtualDisplay() atau API eksklusif.

• [C-0-3] HARUS memiliki notifikasi berkelanjutan kepada pengguna saat transmisi layar atau perekaman layar diaktifkan. AOSP memenuhi persyaratan ini dengan menampilkan ikon notifikasi berkelanjutan di status bar.

• [C-SR-1] SANGAT DISARANKAN untuk menampilkan peringatan pengguna yang pesannya PERSIS SAMA dengan yang diterapkan di AOSP, tetapi DAPAT diubah selama pesan tersebut dengan jelas memperingatkan pengguna bahwa informasi sensitif apa pun di layar pengguna sedang direkam.

• [C-0-4] Persyaratan dihapus di Android 16.

Implementasi perangkat:

• [C-0-7] TIDAK BOLEH merekam, memproyeksikan, atau mentransmisikan informasi sensitif seperti:

  • Konten notifikasi sensitif yang tercantum dalam Bagian 3.8.3.4 Perlindungan Notifikasi Sensitif
  • Jendela aktivitas aplikasi yang berisi sandi sekali pakai
  • Konten sensitif seperti nama pengguna, sandi, dan informasi kartu kredit

Jika implementasi perangkat menyertakan fungsi dalam sistem yang menangkap konten yang ditampilkan di layar dan/atau merekam aliran audio yang diputar di perangkat selain melalui ContentCaptureService System API, atau cara berpemilik lainnya yang dijelaskan dalam Bagian 9.8.6 Data tingkat OS dan sekitar, maka:

• [C-1-1] HARUS memiliki notifikasi berkelanjutan kepada pengguna setiap kali fungsi ini diaktifkan dan secara aktif merekam/merekam.

Jika implementasi perangkat menyertakan komponen yang diaktifkan langsung, yang dapat merekam audio sekitar dan/atau merekam audio yang diputar di perangkat untuk menyimpulkan informasi yang berguna tentang konteks pengguna, maka:

• [C-2-1] TIDAK BOLEH menyimpan di penyimpanan persisten di perangkat atau mengirimkan audio mentah yang direkam atau format apa pun yang dapat dikonversi kembali menjadi audio asli atau hampir sama, kecuali dengan izin eksplisit dari pengguna.

"Indikator mikrofon" mengacu pada tampilan di layar, yang terus terlihat oleh pengguna dan tidak dapat terhalang, yang dipahami pengguna sebagai mikrofon sedang digunakan(melalui teks, warna, ikon, atau beberapa kombinasi yang unik).

"Indikator kamera" mengacu pada tampilan di layar, yang terus terlihat oleh pengguna dan tidak dapat ditutupi, yang dipahami pengguna sebagai kamera sedang digunakan (melalui teks, warna, ikon, atau beberapa kombinasi yang unik).

Setelah satu detik pertama ditampilkan, indikator dapat berubah secara visual, seperti menjadi lebih kecil, dan tidak harus ditampilkan seperti yang disajikan dan dipahami semula.

Indikator mikrofon dapat digabungkan dengan indikator kamera yang ditampilkan secara aktif, asalkan teks, ikon, atau warna menunjukkan kepada pengguna bahwa penggunaan mikrofon telah dimulai.

Indikator kamera dapat digabungkan dengan indikator mikrofon yang ditampilkan secara aktif, asalkan teks, ikon, atau warna menunjukkan kepada pengguna bahwa penggunaan kamera telah dimulai.

Jika implementasi perangkat mendeklarasikan android.hardware.microphone, implementasi tersebut:

• [C-SR-1] SANGAT DISARANKAN untuk menampilkan indikator mikrofon saat aplikasi mengakses data audio dari mikrofon, tetapi tidak saat mikrofon hanya diakses oleh HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService, atau aplikasi yang memiliki peran yang disebutkan dalam Izin Bagian 9.1 dengan ID CDD [C-3-X].

• [C-SR-2] SANGAT DISARANKAN untuk menampilkan daftar aplikasi Terbaru dan Aktif yang menggunakan mikrofon seperti yang ditampilkan dari PermissionManager.getIndicatorAppOpUsageData(), beserta pesan atribusi yang terkait dengannya.

• [C-SR-3] SANGAT DISARANKAN untuk tidak menyembunyikan indikator mikrofon untuk aplikasi sistem yang memiliki antarmuka pengguna yang terlihat atau interaksi pengguna langsung.

Jika implementasi perangkat mendeklarasikan android.hardware.camera.any, implementasi tersebut:

• [C-SR-4] SANGAT DISARANKAN untuk menampilkan indikator kamera saat aplikasi mengakses data kamera live, tetapi tidak saat kamera hanya diakses oleh aplikasi yang memiliki peran yang disebutkan dalam Izin Bagian 9.1 dengan ID CDD [C-3-X].

• [C-SR-5] SANGAT DISARANKAN untuk menampilkan aplikasi Terbaru dan Aktif menggunakan kamera seperti yang ditampilkan dari PermissionManager.getIndicatorAppOpUsageData(), bersama dengan pesan atribusi apa pun yang terkait dengannya.

• [C-SR-6] SANGAT DISARANKAN untuk tidak menyembunyikan indikator kamera untuk aplikasi sistem yang memiliki antarmuka pengguna yang terlihat atau interaksi pengguna langsung.

9.8.3. Konektivitas

Jika penerapan perangkat memiliki port USB dengan dukungan mode periferal USB, perangkat tersebut:

• [C-1-1] HARUS menampilkan antarmuka pengguna yang meminta izin pengguna sebelum mengizinkan akses ke konten penyimpanan bersama melalui port USB.

9.8.4. Traffic Jaringan

Implementasi perangkat:

• [C-0-1] HARUS menginstal sebelumnya sertifikat root yang sama untuk penyimpanan Certificate Authority (CA) yang dipercaya sistem seperti yang disediakan dalam Proyek Open Source Android upstream.

• [C-0-2] HARUS dikirimkan dengan penyimpanan CA root pengguna yang kosong.

• [C-0-3] HARUS menampilkan peringatan kepada pengguna yang menunjukkan bahwa traffic jaringan dapat dipantau, saat CA root pengguna ditambahkan.

Jika traffic perangkat dirutekan melalui VPN, penerapan perangkat:

• [C-1-1] HARUS menampilkan peringatan kepada pengguna yang menunjukkan salah satu dari:
  • Traffic jaringan tersebut dapat dipantau.
  • Traffic jaringan tersebut dirutekan melalui aplikasi VPN tertentu yang menyediakan VPN.

Jika implementasi perangkat memiliki mekanisme, yang diaktifkan secara langsung secara default, yang merutekan traffic data jaringan melalui server proxy atau gateway VPN (misalnya, memuat layanan VPN dengan android.permission.CONTROL_VPN yang diberikan), maka:

• [C-2-1] HARUS meminta izin pengguna sebelum mengaktifkan mekanisme tersebut, kecuali jika VPN tersebut diaktifkan oleh Pengontrol Kebijakan Perangkat melalui DevicePolicyManager.setAlwaysOnVpnPackage(), dalam hal ini pengguna tidak perlu memberikan izin terpisah, tetapi HANYA perlu diberi tahu.

Jika implementasi perangkat menerapkan kemudahan pengguna untuk mengaktifkan/menonaktifkan fungsi "VPN selalu aktif" aplikasi VPN pihak ketiga, implementasi tersebut:

• [C-3-1] HARUS menonaktifkan kemudahan pengguna ini untuk aplikasi yang tidak mendukung layanan VPN yang selalu aktif dalam file AndroidManifest.xml dengan menyetel atribut SERVICE_META_DATA_SUPPORTS_ALWAYS_ON ke false.

9.8.5. ID Perangkat

Implementasi perangkat:

• [C-0-1] HARUS mencegah akses ke nomor seri perangkat dan, jika berlaku, IMEI/MEID, nomor seri SIM, dan International Mobile Subscriber Identity (IMSI) dari aplikasi, kecuali jika aplikasi tersebut memenuhi salah satu persyaratan berikut:
  • adalah aplikasi operator yang ditandatangani dan diverifikasi oleh produsen perangkat.
  • telah diberi izin READ_PRIVILEGED_PHONE_STATE.
  • memiliki hak istimewa operator seperti yang ditentukan dalam Hak Istimewa Operator UICC.
  • adalah pemilik perangkat atau pemilik profil yang telah diberi izin READ_PHONE_STATE.
  • (Khusus untuk nomor seri SIM/ICCID) memiliki persyaratan peraturan setempat bahwa aplikasi mendeteksi perubahan identitas pelanggan.

9.8.6. Pelindung data tingkat OS dan sekitar

Android, melalui System API, mendukung mekanisme bagi penerapan perangkat untuk merekam data sensitif berikut:

• Data media, seperti audio atau video, yang direkam atau diputar oleh perangkat.

• Peristiwa input (misalnya, tombol, mouse, gestur, suara, video, dan aksesibilitas).

• Layar atau data lain yang dikirim melalui AugmentedAutofillService ke sistem.

• Layar atau data lain yang dapat diakses melalui Content Capture API.

• Semua data aplikasi yang diteruskan ke sistem melalui AppSearchManager API dan dapat diakses melalui AppSearchGlobalManager.query.

• Teks atau data lain yang dikirim melalui TextClassifier API ke TextClassifier Sistem, yaitu ke layanan sistem untuk memahami makna teks, serta membuat prediksi tindakan berikutnya berdasarkan teks.

• Data yang diindeks oleh implementasi AppSearch platform, termasuk, tetapi tidak terbatas pada teks, grafis, data media, atau data serupa lainnya.

• Data audio yang diperoleh sebagai hasil penggunaan SpeechRecognizer#onDeviceSpeechRecognizer() oleh Penerapan Speech Recognizer.

• Data audio yang diperoleh di latar belakang (secara terus-menerus) melalui AudioRecord, SoundTrigger atau Audio API lainnya, dan tidak menghasilkan indikator yang terlihat oleh pengguna

• Data kamera yang diperoleh di latar belakang (secara terus-menerus) melalui CameraManager atau API Kamera lainnya, dan tidak menghasilkan indikator yang terlihat oleh pengguna

• [C-1-7] HARUS menyediakan kemudahan pengguna untuk menonaktifkan data yang dikumpulkan melalui AppSearch atau cara eksklusif agar tidak ditampilkan di platform Android (misalnya, peluncur).

• [C-SR-1] SANGAT TIDAK DISARANKAN untuk meminta izin INTERNET.

• [C-SR-2] SANGAT DISARANKAN untuk hanya mengakses internet melalui API terstruktur yang didukung oleh implementasi open source yang tersedia secara publik.

• [C-SR-4] SANGAT DISARANKAN untuk diterapkan dengan Android SDK API atau repositori open source milik OEM yang serupa; dan / atau dilakukan dalam penerapan Sandbox (lihat 9.8.15 Penerapan API Sandbox).

9.8.7. Akses Papan Klip

Implementasi perangkat:

• [C-0-1] TIDAK BOLEH menampilkan data yang dipangkas dari papan klip (misalnya, melalui ClipboardManager API) kecuali jika aplikasi pihak ketiga adalah IME default atau aplikasi yang saat ini memiliki fokus.

• [C-0-2] HARUS menghapus data papan klip paling lambat 60 menit setelah terakhir kali ditempatkan di papan klip atau dibaca dari papan klip.

9.8.8. Lokasi

Lokasi mencakup informasi dalam class Android Location( seperti Lintang, Bujur, Ketinggian), serta ID yang dapat dikonversi ke Lokasi. Lokasi dapat berupa DGPS (Differential Global Positioning System) yang akurat atau lokasi tingkat negara yang tidak akurat (seperti lokasi kode negara - MCC - Mobile Country Code).

Berikut adalah daftar jenis lokasi yang secara langsung memperoleh lokasi pengguna atau dapat dikonversi ke lokasi pengguna. Ini bukan daftar lengkap, tetapi harus digunakan sebagai contoh tentang apa yang dapat diperoleh secara langsung atau tidak langsung dari Lokasi:

• GPS/GNSS/DGPS/PPP

  • Global Positioning Solution atau Global Navigation Satellite System atau Differential Global Positioning Solution
  • Hal ini juga mencakup Pengukuran GNSS Mentah dan Status GNSS
    • Lokasi Akurat dapat diperoleh dari Pengukuran GNSS Mentah

• Teknologi Nirkabel dengan ID unik seperti:

  • Titik akses Wi-Fi (MAC, BSSID, Nama, atau SSID)
  • Bluetooth/BLE (MAC, BSSID, Nama, atau SSID)
  • UWB (MAC, BSSID, Nama, atau SSID)
  • ID Menara Seluler (3G, 4G, 5G, dll., termasuk semua teknologi Modem Seluler mendatang yang memiliki ID unik)

Sebagai titik referensi utama, lihat Android API yang memerlukan izin ACCESS_FINE_Location atau ACCESS_COARSE_Location.

Implementasi perangkat:

• [C-0-1] TIDAK BOLEH mengaktifkan/menonaktifkan setelan lokasi perangkat dan setelan pemindaian Wi-Fi/Bluetooth tanpa izin eksplisit dari pengguna atau inisiasi pengguna.

• [C-0-2] HARUS menyediakan aksesibilitas pengguna untuk mengakses informasi terkait lokasi, termasuk permintaan lokasi terbaru, izin tingkat aplikasi, dan penggunaan pemindaian Wi-Fi/Bluetooth untuk menentukan lokasi.

• [C-0-3] HARUS memastikan bahwa aplikasi yang menggunakan Emergency Location Bypass API LocationRequest.setLocationSettingsIgnored() adalah sesi darurat yang dimulai pengguna (misalnya, menelepon 911 atau mengirim SMS ke 911). Namun, untuk Automotive, kendaraan DAPAT memulai sesi darurat tanpa interaksi pengguna aktif jika terjadi kecelakaan/tabrakan (seperti untuk memenuhi persyaratan eCall).

• [C-0-4] HARUS mempertahankan kemampuan API Penggantian Lokasi Darurat untuk mengganti setelan lokasi perangkat tanpa mengubah setelan.

• [C-0-5] HARUS menjadwalkan notifikasi yang mengingatkan pengguna setelah aplikasi di latar belakang mengakses lokasi mereka menggunakan izin ACCESS_BACKGROUND_LOCATION.

9.8.9. Aplikasi terinstal

Aplikasi Android yang menargetkan level API 30 atau yang lebih tinggi tidak dapat melihat detail tentang aplikasi lain yang diinstal secara default (lihat Visibilitas paket dalam dokumentasi SDK Android).

Implementasi perangkat:

• [C-0-1] TIDAK BOLEH mengekspos detail tentang aplikasi terinstal lainnya ke aplikasi yang menargetkan level API 30 atau yang lebih tinggi, kecuali jika aplikasi tersebut sudah dapat melihat detail tentang aplikasi terinstal lainnya melalui API terkelola. Hal ini mencakup, tetapi tidak terbatas pada, detail yang diekspos oleh API kustom apa pun yang ditambahkan oleh pelaksana perangkat atau dapat diakses melalui sistem file.

• [C-0-2] TIDAK BOLEH memberikan akses baca atau tulis ke file di direktori tetap khusus aplikasi milik aplikasi lain di penyimpanan eksternal. Pengecualiannya hanyalah sebagai berikut:

  • Otoritas penyedia penyimpanan eksternal (misalnya, aplikasi seperti DocumentsUI).

  • Download Provider yang menggunakan otoritas penyedia "download" untuk mendownload file ke penyimpanan aplikasi.

  • Aplikasi protokol transfer media (MTP) yang ditandatangani platform yang menggunakan izin istimewa ACCESS_MTP untuk mengaktifkan transfer file ke perangkat lain.

  • Aplikasi yang menginstal aplikasi lain dan memiliki izin INSTALL_PACKAGES hanya dapat mengakses direktori "obb" untuk tujuan mengelola file ekspansi APK.

9.8.10. Laporan Bug Konektivitas

Jika penerapan perangkat menyatakan tanda fitur android.hardware.telephony, maka:

• [C-1-1] HARUS mendukung pembuatan laporan bug konektivitas melalui BUGREPORT_MODE_TELEPHONY dengan BugreportManager.

• [C-1-2] HARUS mendapatkan izin pengguna setiap kali BUGREPORT_MODE_TELEPHONY digunakan untuk membuat laporan dan TIDAK BOLEH meminta pengguna untuk menyetujui semua permintaan mendatang dari aplikasi.

• [C-1-3] TIDAK BOLEH menampilkan laporan yang dibuat ke aplikasi yang meminta tanpa izin eksplisit dari pengguna.

• [C-1-4] Laporan yang dibuat menggunakan BUGREPORT_MODE_TELEPHONY HARUS berisi setidaknya informasi berikut:

  • TelephonyDebugService dump
  • TelephonyRegistry dump
  • WifiService dump
  • ConnectivityService dump
  • Dump instance CarrierService paket panggilan (jika terikat)
  • Buffer log radio
  • SubscriptionManagerService dump

• [C-1-5] TIDAK BOLEH menyertakan hal berikut dalam laporan yang dihasilkan:

  • Jenis informasi apa pun yang tidak terkait langsung dengan proses debug konektivitas.

  • Semua jenis log traffic aplikasi yang diinstal pengguna atau profil mendetail aplikasi/paket yang diinstal pengguna (UID tidak masalah, nama paket tidak boleh).

• MUNGKIN menyertakan informasi tambahan yang tidak terkait dengan identitas pengguna mana pun. (misalnya, log vendor).

Jika implementasi perangkat menyertakan informasi tambahan (misalnya, log vendor) dalam laporan bug dan informasi tersebut berdampak pada privasi/keamanan/baterai/penyimpanan/memori, maka:

• [C-SR-1] SANGAT DISARANKAN agar setelan developer dinonaktifkan secara default. Implementasi referensi AOSP memenuhi persyaratan ini dengan menyediakan opsi Enable verbose vendor logging di setelan developer untuk menyertakan log vendor tambahan khusus perangkat dalam laporan bug.

9.8.11. Berbagi blob data

Android, melalui BlobStoreManager memungkinkan aplikasi menyumbangkan blob data ke Sistem untuk dibagikan dengan serangkaian aplikasi yang dipilih.

Jika implementasi perangkat mendukung blob data bersama seperti yang dijelaskan dalam dokumentasi SDK, maka:

• [C-1-1] TIDAK BOLEH membagikan blob data milik aplikasi di luar yang ingin diizinkan (yaitu cakupan akses default dan mode akses lainnya yang dapat ditentukan menggunakan BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess(), atau BlobStoreManager.session#allowPublicAccess() TIDAK BOLEH diubah). Implementasi referensi AOSP memenuhi persyaratan ini.

• [C-1-2] TIDAK BOLEH mengirimkan ke luar perangkat atau membagikan ke aplikasi lain hash aman blob data (yang digunakan untuk mengontrol akses).

9.8.12. Pengenalan Musik

Android, melalui System API MusicRecognitionManager, mendukung mekanisme bagi implementasi perangkat untuk meminta pengenalan musik, mengingat rekaman audio, dan mendelegasikan pengenalan musik ke aplikasi istimewa yang menerapkan MusicRecognitionService API.

Jika implementasi perangkat menyertakan layanan yang mengimplementasikan System API MusicRecognitionManager atau layanan eksklusif yang melakukan streaming data audio seperti yang dijelaskan di atas, implementasi tersebut:

• [C-1-1] HARUS memastikan bahwa pemanggil MusicRecognitionManager memiliki izin MANAGE_MUSIC_RECOGNITION

• [C-1-2] HARUS memastikan bahwa satu aplikasi pengenalan musik yang telah diinstal sebelumnya menerapkan MusicRecognitionService.

• [C-1-3] TIDAK BOLEH mengizinkan pengguna mengganti MusicRecognitionManagerService atau MusicRecognitionService dengan aplikasi atau layanan yang dapat diinstal pengguna.

• [C-1-4] HARUS memastikan bahwa saat MusicRecognitionManagerService mengakses rekaman audio dan meneruskannya ke aplikasi yang menerapkan MusicRecognitionService, akses audio dilacak melalui pemanggilan AppOpsManager.noteOp / startOp.

Jika penerapan MusicRecognitionManagerService atau MusicRecognitionService di perangkat menyimpan data audio yang direkam, maka:

• [C-2-1] TIDAK BOLEH menyimpan audio mentah atau sidik jari audio apa pun di disk sama sekali, atau dalam memori selama lebih dari 14 hari.

• [C-2-2] TIDAK BOLEH membagikan data tersebut di luar MusicRecognitionService, kecuali dengan izin eksplisit pengguna setiap kali data tersebut dibagikan.

9.8.13. SensorPrivacyManager

Jika implementasi perangkat memberi pengguna kemampuan software untuk menonaktifkan input kamera dan/atau mikrofon untuk implementasi perangkat, maka:

• [C-1-1] HARUS menampilkan 'true' secara akurat untuk metode API supportsSensorToggle() yang relevan.

• [C-1-2] HARUS, saat aplikasi mencoba mengakses mikrofon atau kamera yang diblokir, menampilkan ke pengguna kemampuan pengguna yang tidak dapat ditutup yang dengan jelas menunjukkan bahwa sensor diblokir dan memerlukan pilihan untuk terus memblokir atau membuka blokir sesuai dengan penerapan AOSP yang memenuhi persyaratan ini.

• [C-1-3] HANYA boleh meneruskan data audio dan kamera kosong (atau palsu) ke aplikasi dan tidak melaporkan kode error karena pengguna tidak mengaktifkan kamera atau mikrofon melalui kemudahan pengguna yang ditampilkan sesuai dengan [C-1-2] di atas.

9.8.14. T/A

9.8.15. Implementasi Aplikasi Gateway dan Private Compute Core

9.8.16. Data Audio dan Kamera Berkelanjutan

Jika implementasi perangkat merekam data apa pun seperti yang dijelaskan di bagian 9.8.2 atau bagian 9.8.6, dan jika implementasi tersebut menggunakan Data audio yang diperoleh di latar belakang (secara terus-menerus) melalui AudioRecord, SoundTrigger, atau Audio API lainnya ATAU Data kamera yang diperoleh di latar belakang (secara terus-menerus) melalui CameraManager atau Camera API lainnya, maka:

• [C-0-1] HARUS menerapkan indikator yang sesuai (kamera dan/atau mikrofon sebagaimana tercantum dalam bagian 9.8.2 Perekaman), kecuali:

  • Akses ini dilakukan dalam penerapan dengan Sandbox (lihat 9.8.15 Penerapan API dengan Sandbox), melalui paket yang memiliki satu atau beberapa peran berikut: System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence, atau System Visual Intelligence.

  • Akses dilakukan melalui sandbox, yang diimplementasikan dan diterapkan melalui mekanisme di AOSP (HotwordDetectionService, WearableSensingService, VisualQueryDetector).

  • Akses audio dilakukan untuk tujuan bantuan oleh aplikasi Asisten Digital, yang menyediakan SOURCE_HOTWORD sebagai sumber audio.

  • Akses dilakukan oleh sistem dan diimplementasikan dengan kode open source.

• [C-SR-1] SANGAT DISARANKAN untuk mewajibkan izin pengguna untuk setiap fungsi yang menggunakan data tersebut, dan dinonaktifkan secara default.

• [C-SR-2] SANGAT DISARANKAN untuk menerapkan perlakuan yang sama (yaitu mengikuti batasan yang diuraikan dalam 9.8.2 Perekaman, 9.8.6 Data tingkat OS dan sekitar, 9.8.15 Penerapan API yang di-sandbox, dan 9.8.16 Data Audio dan Kamera Berkelanjutan) ke data Kamera yang berasal dari perangkat wearable jarak jauh.

Jika implementasi perangkat menerima data Kamera atau Mikrofon dari perangkat wearable jarak jauh dan data diakses dalam bentuk tidak terenkripsi di luar Android OS, implementasi sandbox, atau fungsi sandbox yang dibuat oleh WearableSensingManager, implementasi tersebut:

• [C-1-1] HARUS menunjukkan ke perangkat wearable jarak jauh untuk menampilkan indikator tambahan di sana.

Jika perangkat menyediakan kemampuan untuk berinteraksi dengan Aplikasi Asisten Digital tanpa kata kunci yang ditetapkan (baik menangani kueri pengguna umum, atau menganalisis kehadiran pengguna melalui kamera), perangkat tersebut:

• [C-2-1] HARUS memastikan bahwa penerapan tersebut disediakan oleh paket yang memiliki peran android.app.role.ASSISTANT.

• [C-2-2] HARUS memastikan bahwa implementasi tersebut menggunakan API Android HotwordDetectionService dan/atau VisualQueryDetectionService.

9.8.17. Telemetri

Android menyimpan log sistem dan aplikasi menggunakan StatsLog API. Log ini dikelola melalui API StatsManager yang dapat digunakan oleh aplikasi sistem dengan hak istimewa.

StatsManager juga menyediakan cara untuk mengumpulkan data yang dikategorikan sebagai data sensitif privasi dari perangkat dengan mekanisme yang menjaga privasi. Khususnya, API StatsManager::query memberikan kemampuan untuk membuat kueri kategori metrik yang dibatasi yang ditentukan di StatsLog.

Penerapan apa pun yang mengirim kueri dan mengumpulkan metrik terbatas dari StatsManager:

• [C-0-1] HARUS menjadi satu-satunya aplikasi/penerapan di perangkat dan memegang izin READ_RESTRICTED_STATS.

• [C-0-2] HANYA boleh mengirim data telemetri dan log perangkat menggunakan mekanisme yang menjaga privasi. Mekanisme yang menjaga privasi didefinisikan sebagai "mekanisme yang hanya memungkinkan analisis secara gabungan dan mencegah pencocokan peristiwa yang dicatat atau hasil turunan dengan pengguna individual", untuk mencegah data per pengguna dapat diintrospeksi (misalnya, diterapkan menggunakan teknologi privasi diferensial seperti RAPPOR).

• [C-0-3] TIDAK BOLEH mengaitkan data tersebut dengan identitas pengguna mana pun (seperti Akun) di perangkat.

• [C-0-4] TIDAK BOLEH membagikan data tersebut kepada komponen OS lain yang tidak mengikuti persyaratan yang diuraikan dalam bagian saat ini (9.8.17. Telemetri).

• [C-0-5] HARUS menyediakan kemudahan bagi pengguna untuk mengaktifkan/menonaktifkan pengumpulan, penggunaan, dan pembagian telemetri yang menjaga privasi.

• [C-0-6] HARUS menyediakan kemudahan pengguna untuk menghapus data yang dikumpulkan implementasi tersebut jika data disimpan dalam bentuk apa pun di perangkat. Jika pengguna memilih untuk menghapus data, HARUS menghapus semua data yang saat ini disimpan di perangkat.

• [C-0-7] HARUS mengungkapkan penerapan protokol perlindungan privasi yang mendasarinya di repositori open source.

• [C-0-8] HARUS menerapkan kebijakan keluar data di bagian ini untuk membatasi pengumpulan data dalam kategori metrik terbatas yang ditentukan di StatsLog.

9.8.18. Privasi Fungsi Agentik

9.9. Enkripsi Penyimpanan Data

Semua perangkat HARUS memenuhi persyaratan bagian 9.9.1. Perangkat yang diluncurkan pada level API yang lebih awal daripada dokumen ini dikecualikan dari persyaratan bagian 9.9.2 dan 9.9.3; sebagai gantinya, perangkat tersebut HARUS memenuhi persyaratan di bagian 9.9 dokumen Android Compatibility Definition yang sesuai dengan level API saat perangkat diluncurkan.

9.9.1. Booting Langsung

Implementasi perangkat:

• [C-0-1] HARUS menerapkan API mode Booting Langsung meskipun tidak mendukung Enkripsi Penyimpanan.

• [C-0-2] Intent ACTION_LOCKED_BOOT_COMPLETED dan ACTION_USER_UNLOCKED HARUS tetap disiarkan untuk memberi sinyal kepada aplikasi yang kompatibel dengan Booting Langsung bahwa lokasi penyimpanan yang Di-Enkripsi Perangkat (DE) dan Di-Enkripsi Kredensial (CE) tersedia untuk pengguna.

9.9.2. Persyaratan enkripsi

Implementasi perangkat:

• [C-0-1] HARUS mengenkripsi data pribadi aplikasi (partisi /data), serta partisi penyimpanan bersama aplikasi (partisi /sdcard) jika merupakan bagian permanen dan tidak dapat dilepas dari perangkat.
• [C-0-2] HARUS mengaktifkan enkripsi penyimpanan data secara default pada saat pengguna telah menyelesaikan pengalaman penyiapan langsung.

• [C-0-3] HARUS memenuhi persyaratan enkripsi penyimpanan data di atas dengan menerapkan salah satu dari dua metode enkripsi berikut:

  • Enkripsi Berbasis File (FBE) dan Enkripsi Metadata seperti yang dijelaskan di bagian 9.9.3.1.
  • Enkripsi Tingkat Blok Per Pengguna seperti yang dijelaskan di bagian 9.9.3.2.

9.9.3. Metode Enkripsi

Jika implementasi perangkat dienkripsi, maka:

• [C-1-1] HARUS melakukan booting tanpa meminta kredensial pengguna dan mengizinkan aplikasi yang kompatibel dengan Booting Langsung mengakses penyimpanan yang Di-Enkripsi Perangkat (DE) setelah pesan ACTION_LOCKED_BOOT_COMPLETED disiarkan.

• [C-1-2] TIDAK BOLEH mengizinkan akses ke penyimpanan yang Dienkripsi Kredensial (CE) hingga keduanya:

  • Pengguna membuka kunci perangkat menggunakan metode autentikasi utama (seperti sandi, pola, atau PIN).
  • Pesan ACTION_USER_UNLOCKED disiarkan.

• [C-1-13] TIDAK BOLEH menawarkan metode apa pun untuk membuka kunci penyimpanan yang dilindungi CE tanpa kredensial yang diberikan pengguna, kunci escrow terdaftar, atau implementasi melanjutkan setelah melakukan booting ulang yang memenuhi persyaratan dalam bagian 9.9.4.

• [C-1-4] HARUS menggunakan Booting Terverifikasi.

9.9.3.1. Enkripsi Berbasis File dengan Enkripsi Metadata

Jika implementasi perangkat menggunakan Enkripsi Berbasis File dengan Enkripsi Metadata, maka:

• [C-1-5] HARUS mengenkripsi konten file dan metadata sistem file menggunakan AES-256-XTS atau Adiantum. AES-256-XTS mengacu pada Advanced Encryption Standard dengan panjang kunci cipher 256 bit, yang dioperasikan dalam mode XTS; panjang penuh kunci adalah 512 bit.Adiantum mengacu pada Adiantum-XChaCha12-AES, sebagaimana ditentukan di https://github.com/google/adiantum. Metadata sistem file adalah data seperti ukuran file, kepemilikan, mode, dan atribut yang diperluas (xattrs).
• [C-1-6] HARUS mengenkripsi nama file menggunakan AES-256-CBC-CTS, AES-256-HCTR2, atau Adiantum.
• [C-1-12] Jika perangkat memiliki petunjuk Advanced Encryption Standard (AES) (seperti Ekstensi Kriptografi ARMv8 di perangkat berbasis ARM, atau AES-NI di perangkat berbasis x86), maka opsi berbasis AES di atas untuk enkripsi nama file, konten file, dan metadata sistem file HARUS digunakan, bukan Adiantum.
• [C-1-13] HARUS menggunakan fungsi turunan kunci yang kuat secara kriptografis dan tidak dapat dibalik (misalnya, HKDF-SHA512) untuk mendapatkan subkunci yang diperlukan (misalnya, kunci per file) dari kunci CE dan DE. "Kuat secara kriptografis dan tidak dapat dibalik" berarti fungsi turunan kunci memiliki kekuatan keamanan minimal 256 bit dan berperilaku sebagai keluarga fungsi pseudorandom atas inputnya.
• [C-1-14] TIDAK BOLEH menggunakan kunci atau subkunci Enkripsi Berbasis File (FBE) yang sama untuk tujuan kriptografi yang berbeda (misalnya, untuk enkripsi dan turunan kunci, atau untuk dua algoritma enkripsi yang berbeda).
• [C-1-15] HARUS memastikan bahwa semua blok konten file terenkripsi yang tidak dihapus di penyimpanan persisten dienkripsi menggunakan kombinasi kunci enkripsi dan vektor inisialisasi (IV) yang bergantung pada file dan offset dalam file. Selain itu, semua kombinasi tersebut HARUS berbeda, kecuali jika enkripsi dilakukan menggunakan hardware enkripsi inline yang hanya mendukung panjang IV 32 bit.
• [C-1-16] HARUS memastikan bahwa semua nama file terenkripsi yang tidak dihapus di penyimpanan persisten dalam direktori yang berbeda dienkripsi menggunakan kombinasi kunci enkripsi dan vektor inisialisasi (IV) yang berbeda.

• [C-1-17] HARUS memastikan bahwa semua blok metadata sistem file terenkripsi di penyimpanan persisten dienkripsi menggunakan kombinasi kunci enkripsi dan vektor inisialisasi (IV) yang berbeda.

• Kunci yang melindungi area penyimpanan CE dan DE serta metadata sistem file:

  • [C-1-7] HARUS terikat secara kriptografis ke Keystore yang didukung hardware. Keystore ini HARUS terikat ke Booting Terverifikasi dan root of trust hardware perangkat.
  • [C-1-8] Kunci CE HARUS terikat dengan kredensial layar kunci pengguna.
  • [C-1-9] Kunci CE HARUS terikat ke sandi default jika pengguna belum menentukan kredensial layar kunci.
  • [C-1-10] HARUS unik dan berbeda, dengan kata lain tidak ada kunci CE atau DE pengguna yang cocok dengan kunci CE atau DE pengguna lain.
  • [C-1-11] HARUS menggunakan sandi, panjang kunci, dan mode yang didukung secara wajib.
  • [C-1-12] HARUS dihapus dengan aman selama pembukaan kunci dan penguncian bootloader seperti yang dijelaskan di sini.

• HARUS membuat aplikasi penting yang sudah diinstal sebelumnya (mis. Alarm, Telepon, Messenger) dapat mendeteksi Booting Langsung.

Project Android Open Source upstream menyediakan implementasi pilihan untuk Enkripsi Berbasis File berdasarkan fitur enkripsi "fscrypt" kernel Linux, dan Enkripsi Metadata berdasarkan fitur "dm-default-key" kernel Linux.

9.9.3.2. Enkripsi Tingkat Blok Per Pengguna

Jika implementasi perangkat menggunakan enkripsi tingkat blok per pengguna, perangkat tersebut:

• [C-1-1] HARUS mengaktifkan dukungan multi-pengguna seperti yang dijelaskan di bagian 9.5.
• [C-1-2] HARUS menyediakan partisi per pengguna, baik menggunakan partisi mentah maupun volume logis.
• [C-1-3] HARUS menggunakan kunci enkripsi yang unik dan berbeda per pengguna untuk enkripsi perangkat blok yang mendasarinya.

• [C-1-4] HARUS menggunakan AES-256-XTS untuk enkripsi tingkat blok partisi pengguna.

• Kunci yang melindungi perangkat terenkripsi tingkat blok per pengguna:

  • [C-1-5] HARUS terikat secara kriptografis ke Keystore yang didukung hardware. Keystore ini HARUS terikat ke Booting Terverifikasi dan root of trust hardware perangkat.
  • [C-1-6] HARUS terikat dengan kredensial layar kunci pengguna yang sesuai.

Enkripsi tingkat blok per pengguna dapat diterapkan menggunakan fitur "dm-crypt" kernel Linux melalui partisi per pengguna.

9.9.4. Lanjutkan saat Reboot

Lanjutkan saat Reboot memungkinkan pembukaan kunci penyimpanan CE semua aplikasi, termasuk aplikasi yang belum mendukung Direct Boot, setelah reboot yang dimulai oleh OTA. Fitur ini memungkinkan pengguna menerima notifikasi dari aplikasi yang diinstal setelah perangkat dimulai ulang.

Penerapan Lanjutkan saat Reboot harus terus memastikan bahwa saat perangkat jatuh ke tangan penyerang, penyerang akan sangat kesulitan memulihkan data yang dienkripsi CE milik pengguna, meskipun perangkat dihidupkan, penyimpanan CE dibuka kuncinya, dan pengguna telah membuka kunci perangkat setelah menerima OTA. Untuk ketahanan terhadap serangan orang dalam, kami juga mengasumsikan penyerang mendapatkan akses ke kunci penandatanganan kriptografi siaran.

Khususnya:

• [C-0-1] Penyimpanan CE TIDAK BOLEH dapat dibaca bahkan oleh penyerang yang secara fisik memiliki perangkat dan kemudian memiliki kemampuan dan batasan berikut:

  • Dapat menggunakan kunci penandatanganan vendor atau perusahaan mana pun untuk menandatangani pesan arbitrer.
  • Dapat menyebabkan OTA diterima oleh perangkat.
  • Dapat mengubah operasi hardware apa pun (AP, flash, dll.) kecuali seperti yang dijelaskan di bawah, tetapi modifikasi tersebut melibatkan penundaan setidaknya satu jam dan siklus daya yang menghancurkan konten RAM.
  • Tidak dapat mengubah operasi hardware yang tahan terhadap gangguan (misalnya, Titan M).
  • Tidak dapat membaca RAM perangkat aktif.
  • Tidak dapat memperoleh kredensial pengguna (PIN, pola, sandi) atau menyebabkan kredensial tersebut dimasukkan.

Sebagai contoh, implementasi perangkat yang menerapkan dan mematuhi semua deskripsi yang ditemukan di sini akan mematuhi [C-0-1].

9.10. Integritas Perangkat

Persyaratan berikut memastikan adanya transparansi terhadap status integritas perangkat. Implementasi perangkat:

• [C-0-1] HARUS melaporkan dengan benar melalui metode System API PersistentDataBlockManager.getFlashLockState() apakah status bootloader mereka mengizinkan flashing image sistem.

• [C-0-2] HARUS mendukung Booting Terverifikasi untuk integritas perangkat.

Jika implementasi perangkat sudah diluncurkan tanpa mendukung Booting Terverifikasi di versi Android yang lebih lama dan tidak dapat menambahkan dukungan untuk fitur ini dengan update software sistem, perangkat tersebut MUNGKIN dikecualikan dari persyaratan.

Booting Terverifikasi adalah fitur yang menjamin integritas software perangkat. Jika implementasi perangkat mendukung fitur ini, maka:

• [C-1-1] HARUS mendeklarasikan flag fitur platform android.software.verified_boot.
• [C-1-2] HARUS melakukan verifikasi pada setiap urutan booting.
• [C-1-3] HARUS memulai verifikasi dari kunci hardware yang tidak dapat diubah yang merupakan akar kepercayaan dan terus berlanjut hingga ke partisi sistem.
• [C-1-4] HARUS menerapkan setiap tahap verifikasi untuk memeriksa integritas dan keaslian semua byte di tahap berikutnya sebelum menjalankan kode di tahap berikutnya.
• [C-1-5] HARUS menggunakan algoritma verifikasi yang sekuat rekomendasi NIST saat ini untuk algoritma hashing (SHA-256) dan ukuran kunci publik (RSA-2048).
• [C-1-6] TIDAK BOLEH mengizinkan booting selesai saat verifikasi sistem gagal, kecuali jika pengguna menyetujui untuk mencoba booting, dalam hal ini data dari blok penyimpanan yang tidak terverifikasi TIDAK BOLEH digunakan.
• [C-1-7] TIDAK BOLEH mengizinkan partisi terverifikasi di perangkat dimodifikasi kecuali pengguna telah membuka kunci bootloader secara eksplisit.
• [C-1-8] HARUS menggunakan penyimpanan yang tahan terhadap upaya merusak: untuk menyimpan apakah bootloader tidak terkunci. Penyimpanan yang tahan terhadap upaya merusak berarti bootloader dapat mendeteksi apakah penyimpanan telah dirusak dari dalam Android.
• [C-1-9] HARUS meminta pengguna, saat menggunakan perangkat, dan memerlukan konfirmasi fisik sebelum mengizinkan transisi dari mode bootloader terkunci ke mode bootloader tidak terkunci.
• [C-1-10] HARUS menerapkan perlindungan rollback untuk partisi yang digunakan oleh Android (misalnya, partisi boot, sistem) dan menggunakan penyimpanan yang tahan terhadap upaya merusak untuk menyimpan metadata yang digunakan untuk menentukan versi OS minimum yang diizinkan.

• [C-1-11] HARUS menghapus semua data pengguna dengan aman selama pembukaan kunci dan penguncian bootloader, sesuai dengan '9.12. Penghapusan Data' (termasuk partisi userdata dan ruang NVRAM apa pun).

• [C-1-14] HARUS memverifikasi tanda tangan setidaknya sekali per booting untuk paket yang diizinkan yang tercantum sebagai require-strict-signature dalam konfigurasi sistem.

• [C-SR-2] SANGAT DISARANKAN untuk memverifikasi semua file APK aplikasi istimewa dengan rantai kepercayaan yang berakar pada partisi yang dilindungi oleh Booting Terverifikasi.

• [C-SR-3] SANGAT DISARANKAN untuk memverifikasi artefak yang dapat dieksekusi yang dimuat oleh aplikasi istimewa dari luar file APK-nya (seperti kode yang dimuat secara dinamis atau kode yang dikompilasi) sebelum mengeksekusinya atau SANGAT DISARANKAN untuk tidak mengeksekusinya sama sekali.

• HARUS menerapkan perlindungan rollback untuk setiap komponen dengan firmware persisten (misalnya, modem, kamera) dan HARUS menggunakan penyimpanan yang tahan terhadap upaya merusak untuk menyimpan metadata yang digunakan untuk menentukan versi minimum yang diizinkan.

Project Open Source Android upstream menyediakan penerapan pilihan fitur ini di repositori external/avb/, yang dapat diintegrasikan ke dalam bootloader yang digunakan untuk memuat Android.

Jika implementasi perangkat memiliki kemampuan untuk memverifikasi konten file berdasarkan per halaman, maka:

• [C-2-1] mendukung verifikasi konten file secara kriptografis tanpa membaca seluruh file.

• [C-2-2] TIDAK BOLEH mengizinkan permintaan baca pada file yang dilindungi berhasil jika konten yang dibaca tidak diverifikasi sesuai [C-2-1] di atas.

• [C-2-4] HARUS menampilkan checksum file dalam O(1) untuk file yang diaktifkan.

Jika implementasi perangkat sudah diluncurkan tanpa kemampuan untuk memverifikasi konten file terhadap kunci tepercaya pada versi Android yang lebih lama dan tidak dapat menambahkan dukungan untuk fitur ini dengan update software sistem, implementasi tersebut MUNGKIN dikecualikan dari persyaratan. Project Android Open Source upstream menyediakan penerapan pilihan fitur ini berdasarkan fitur fs-verity kernel Linux.

9.11. Kunci dan Kredensial

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

• [C-0-1] HARUS mengizinkan minimal 8.192 kunci diimpor atau dibuat.

• [C-0-2] Autentikasi layar kunci HARUS menerapkan interval waktu di antara upaya yang gagal. Dengan n sebagai jumlah upaya gagal, interval waktu HARUS minimal 30 detik untuk 9 < n < 30. Untuk n > 29, nilai interval waktu HARUS minimal 30*2^floor((n-30)/10) detik atau minimal 24 jam, mana saja yang lebih kecil.

• TIDAK BOLEH membatasi jumlah kunci yang dapat dibuat.

Jika implementasi perangkat mendukung layar kunci yang aman, maka:

• [C-1-1] HARUS mencadangkan penerapan keystore dengan lingkungan eksekusi yang terisolasi.

• [C-1-3] HARUS melakukan autentikasi layar kunci di lingkungan eksekusi yang terisolasi dan hanya jika berhasil, mengizinkan penggunaan kunci yang terikat dengan autentikasi. Kredensial layar kunci HARUS disimpan dengan cara yang hanya memungkinkan lingkungan eksekusi terisolasi melakukan autentikasi layar kunci. Proyek Open Source Android upstream menyediakan Hardware Abstraction Layer (HAL) Gatekeeper dan Trusty, yang dapat digunakan untuk memenuhi persyaratan ini.

• [C-1-4] HARUS mendukung pengesahan kunci dengan kunci penandatanganan pengesahan dilindungi oleh hardware yang aman dan penandatanganan dilakukan di hardware yang aman. Kunci penandatanganan pengesahan TIDAK BOLEH digunakan sebagai ID perangkat permanen.

Perhatikan bahwa jika implementasi perangkat sudah diluncurkan di versi Android sebelumnya, perangkat tersebut dikecualikan dari persyaratan untuk memiliki keystore yang didukung oleh lingkungan eksekusi terisolasi dan mendukung pengesahan kunci, kecuali jika perangkat tersebut mendeklarasikan fitur android.hardware.fingerprint yang memerlukan keystore yang didukung oleh lingkungan eksekusi terisolasi.

• [C-1-5] HARUS memungkinkan pengguna memilih Waktu tunggu tidur untuk transisi dari status tidak terkunci ke status terkunci, dengan waktu tunggu minimum yang diizinkan hingga 15 detik. Perangkat otomotif, yang mengunci layar setiap kali head unit dinonaktifkan atau pengguna dialihkan, MUNGKIN TIDAK memiliki konfigurasi Waktu tunggu tidur.

• [C-1-6] HARUS mendukung IKeymasterDevice 3.0 atau yang lebih tinggi, atau IKeyMintDevice versi 1 atau yang lebih tinggi.

9.11.1. Layar Kunci Aman, Autentikasi, dan Perangkat Virtual

Implementasi AOSP mengikuti model autentikasi bertingkat di mana autentikasi utama berbasis faktor pengetahuan dapat didukung oleh biometrik kuat sekunder, atau oleh modalitas tersier yang lebih lemah.

Implementasi perangkat:

• [C-SR-1] SANGAT DISARANKAN untuk menetapkan hanya salah satu metode berikut sebagai metode autentikasi utama:

  • PIN numerik
  • Sandi alfanumerik
  • Pola geser pada petak yang terdiri dari tepat 3x3 titik

  Perhatikan bahwa metode autentikasi di atas disebut sebagai metode autentikasi utama yang direkomendasikan dalam dokumen ini.

• [C-0-1] HARUS membatasi jumlah upaya autentikasi utama yang gagal.

• [C-SR-5] SANGAT DISARANKAN untuk menerapkan batas atas 20 upaya autentikasi utama yang gagal dan jika pengguna menyetujui dan mengaktifkan fitur tersebut, lakukan "Reset Data Pabrik" setelah melampaui batas upaya autentikasi utama yang gagal.

Jika penerapan perangkat menetapkan PIN numerik sebagai metode autentikasi utama yang direkomendasikan, maka:

• [C-SR-6] PIN SANGAT DISARANKAN untuk memiliki minimal 6 digit, atau setara dengan entropi 20-bit.

• [C-SR-7] PIN dengan panjang kurang dari 6 digit SANGAT TIDAK DISARANKAN untuk mengizinkan entri otomatis tanpa interaksi pengguna guna menghindari pengungkapan panjang PIN.

Jika penerapan perangkat menambahkan atau mengubah metode autentikasi utama yang direkomendasikan dan menggunakan metode autentikasi baru sebagai cara yang aman untuk mengunci layar, metode autentikasi baru:

• [C-2-1] HARUS berupa metode autentikasi pengguna seperti yang dijelaskan dalam Mewajibkan Autentikasi Pengguna untuk Penggunaan Kunci.

Jika implementasi perangkat menambahkan atau mengubah metode autentikasi untuk membuka kunci layar kunci jika didasarkan pada rahasia yang diketahui dan menggunakan metode autentikasi baru agar diperlakukan sebagai cara yang aman untuk mengunci layar:

• [C-3-1] Entropi input dengan panjang terpendek yang diizinkan HARUS lebih besar dari 10 bit.

• [C-3-2] Entropi maksimum dari semua kemungkinan input HARUS lebih besar dari 18 bit.

• [C-3-3] Metode autentikasi baru TIDAK BOLEH menggantikan metode autentikasi utama yang direkomendasikan (yaitu PIN, pola, sandi) yang diterapkan dan disediakan di AOSP.

• [C-3-4] Metode autentikasi baru HARUS dinonaktifkan saat aplikasi Pengontrol Kebijakan Perangkat (DPC) telah menetapkan kebijakan persyaratan sandi melalui DevicePolicyManager.setRequiredPasswordComplexity() dengan konstanta kompleksitas yang lebih ketat daripada PASSWORD_COMPLEXITY_NONE atau melalui metode DevicePolicyManager.setPasswordQuality() dengan konstanta yang lebih ketat daripada PASSWORD_QUALITY_BIOMETRIC_WEAK.

• [C-3-5] Metode autentikasi baru HARUS melakukan penggantian ke metode autentikasi utama yang direkomendasikan (yaitu PIN, pola, sandi) sekali setiap 72 jam atau kurang ATAU mengungkapkan dengan jelas kepada pengguna bahwa beberapa data tidak akan dicadangkan untuk menjaga privasi data mereka.

Jika implementasi perangkat menambahkan atau mengubah metode autentikasi utama yang direkomendasikan untuk membuka kunci layar dan menggunakan metode autentikasi baru yang didasarkan pada biometrik agar diperlakukan sebagai cara yang aman untuk mengunci layar, metode baru tersebut:

• [C-4-1] HARUS memenuhi semua persyaratan yang dijelaskan dalam pasal 7.3.10 untuk Kelas 1 (sebelumnya Praktis).

• [C-4-2] HARUS memiliki mekanisme penggantian untuk menggunakan salah satu metode autentikasi utama yang direkomendasikan yang didasarkan pada rahasia yang diketahui.

• [C-4-3] HARUS dinonaktifkan dan hanya mengizinkan autentikasi utama yang direkomendasikan untuk membuka kunci layar saat aplikasi Pengontrol Kebijakan Perangkat (DPC) telah menetapkan kebijakan fitur keyguard dengan memanggil metode DevicePolicyManager.setKeyguardDisabledFeatures(), dengan salah satu tanda biometrik terkait (yaitu KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE, atau KEYGUARD_DISABLE_IRIS).

Jika metode autentikasi biometrik tidak memenuhi persyaratan untuk Class 3 (sebelumnya Kuat) seperti yang dijelaskan dalam pasal 7.3.10:

• [C-5-1] Metode HARUS dinonaktifkan jika aplikasi Pengontrol Kebijakan Perangkat (DPC) telah menetapkan kebijakan kualitas persyaratan sandi melalui DevicePolicyManager.setRequiredPasswordComplexity() dengan bucket kompleksitas yang lebih ketat daripada PASSWORD_COMPLEXITY_LOW atau menggunakan metode DevicePolicyManager.setPasswordQuality() dengan konstanta kualitas yang lebih ketat daripada PASSWORD_QUALITY_BIOMETRIC_WEAK.

• [C-5-2] Pengguna HARUS diminta untuk melakukan autentikasi utama yang direkomendasikan (seperti PIN, pola, atau sandi) sebagaimana dijelaskan dalam [C-1-7] dan [C-1-8] di bagian 7.3.10.

• [C-5-3] Metode ini TIDAK BOLEH diperlakukan sebagai layar kunci yang aman, dan HARUS memenuhi persyaratan yang dimulai dengan C-8 di bagian di bawah ini.

Jika implementasi perangkat menambahkan atau mengubah metode autentikasi untuk membuka kunci layar kunci dan metode autentikasi baru didasarkan pada token fisik atau lokasi:

• [C-6-1] Mereka HARUS memiliki mekanisme penggantian untuk menggunakan salah satu metode autentikasi utama yang direkomendasikan yang didasarkan pada rahasia yang diketahui dan memenuhi persyaratan untuk diperlakukan sebagai layar kunci yang aman.

• [C-6-2] Metode baru HARUS dinonaktifkan dan hanya mengizinkan salah satu metode autentikasi utama yang direkomendasikan untuk membuka kunci layar saat aplikasi Pengontrol Kebijakan Perangkat (DPC) telah menetapkan kebijakan dengan salah satu dari:

  • Metode DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS).

  • Metode DevicePolicyManager.setPasswordQuality() dengan konstanta kualitas yang lebih ketat daripada PASSWORD_QUALITY_NONE.

  • Metode DevicePolicyManager.setRequiredPasswordComplexity() dengan bucket kompleksitas yang lebih ketat daripada PASSWORD_COMPLEXITY_NONE.

• [C-6-3] Pengguna HARUS diminta untuk menggunakan salah satu metode autentikasi utama yang direkomendasikan (seperti PIN, pola, atau sandi) setidaknya sekali setiap 4 jam atau kurang. Jika token fisik memenuhi persyaratan untuk penerapan TrustAgent di C-X, batasan waktu tunggu yang ditentukan dalam [C-9-5] akan berlaku.

• [C-6-4] Metode baru TIDAK BOLEH diperlakukan sebagai layar kunci yang aman dan HARUS mengikuti batasan yang tercantum dalam C-8 di bawah.

Jika implementasi perangkat memiliki layar kunci yang aman dan menyertakan satu atau beberapa agen tepercaya, yang mengimplementasikan TrustAgentServiceSystem API, maka:

• [C-7-1] HARUS memiliki indikasi yang jelas di menu setelan dan di layar kunci saat kunci perangkat ditangguhkan atau dapat dibuka kuncinya oleh agen tepercaya. Misalnya, AOSP memenuhi persyaratan ini dengan menampilkan deskripsi teks untuk "Setelan kunci otomatis" dan "Tombol daya mengunci secara instan" di menu setelan dan ikon yang dapat dibedakan di layar kunci.

• [C-7-2] HARUS mematuhi dan menerapkan sepenuhnya semua API agen tepercaya di class DevicePolicyManager, seperti konstanta KEYGUARD_DISABLE_TRUST_AGENTS.

• [C-7-3] TIDAK BOLEH mengimplementasikan fungsi TrustAgentService.addEscrowToken() sepenuhnya di perangkat yang digunakan sebagai perangkat pribadi utama (misalnya, perangkat genggam), tetapi BOLEH mengimplementasikan fungsi sepenuhnya di implementasi perangkat yang biasanya digunakan bersama (misalnya, perangkat Android TV atau Otomotif).

• [C-7-4] HARUS mengenkripsi semua token tersimpan yang ditambahkan oleh TrustAgentService.addEscrowToken().

• [C-7-5] TIDAK BOLEH menyimpan kunci enkripsi atau token escrow di perangkat yang sama dengan tempat kunci digunakan. Misalnya, kunci yang disimpan di ponsel diizinkan untuk membuka kunci akun pengguna di TV. Untuk perangkat Otomotif, token escrow tidak boleh disimpan di bagian mana pun kendaraan.

• [C-7-6] HARUS memberi tahu pengguna tentang implikasi keamanan sebelum mengaktifkan token escrow untuk mendekripsi penyimpanan data.

• [C-7-7] HARUS memiliki mekanisme penggantian untuk menggunakan salah satu metode autentikasi utama yang direkomendasikan.

• [C-7-9] Pengguna HARUS diminta untuk menggunakan salah satu metode autentikasi utama yang direkomendasikan (seperti PIN, pola, atau sandi) sebagaimana dijelaskan dalam [C-1-7] dan [C-1-8] di pasal 7.3.10, kecuali jika keselamatan pengguna (misalnya, gangguan pengemudi) menjadi perhatian.

• [C-7-10] TIDAK BOLEH diperlakukan sebagai layar kunci yang aman dan HARUS mengikuti batasan yang tercantum dalam C-8 di bawah.

• [C-7-11] TIDAK BOLEH mengizinkan TrustAgent di perangkat pribadi utama (misalnya: perangkat genggam) untuk membuka kunci perangkat, dan hanya dapat menggunakannya untuk menjaga perangkat yang sudah dibuka kuncinya tetap dalam keadaan tidak terkunci hingga maksimal 4 jam. Penerapan default TrustManagerService di AOSP memenuhi persyaratan ini.

• [C-7-12] HARUS menggunakan saluran komunikasi yang aman secara kriptografis (misalnya UKEY2) untuk meneruskan token escrow dari perangkat penyimpanan ke perangkat target.

Jika implementasi perangkat menambahkan atau mengubah metode autentikasi untuk membuka kunci layar kunci yang bukan layar kunci aman seperti yang dijelaskan di atas, dan menggunakan metode autentikasi baru untuk membuka kunci keyguard:

• [C-8-1] Metode baru HARUS dinonaktifkan saat aplikasi Pengontrol Kebijakan Perangkat (DPC) telah menetapkan kebijakan kualitas sandi melalui metode DevicePolicyManager.setPasswordQuality() dengan konstanta kualitas yang lebih ketat daripada PASSWORD_QUALITY_NONE atau melalui DevicePolicyManager.setRequiredPasswordComplexity() dengan konstanta kompleksitas yang lebih ketat daripada PASSWORD_COMPLEXITY_NONE.

• [C-8-2] Mereka TIDAK BOLEH mereset timer masa berlaku sandi yang ditetapkan oleh DevicePolicyManager.setPasswordExpirationTimeout().

• [C-8-3] Aplikasi tersebut TIDAK BOLEH mengekspos API untuk digunakan oleh aplikasi pihak ketiga guna mengubah status kunci.

Jika implementasi perangkat mengizinkan aplikasi membuat tampilan virtual sekunder dan tidak mendukung peristiwa input terkait, seperti melalui VirtualDeviceManager, maka:

• [C-9-1] HARUS mengunci tampilan virtual sekunder ini saat tampilan default perangkat dikunci, dan membuka kunci tampilan virtual sekunder ini saat tampilan default perangkat dibuka kuncinya.

Jika implementasi perangkat memungkinkan aplikasi membuat tampilan virtual sekunder dan mendukung peristiwa input terkait, seperti melalui VirtualDeviceManager, maka:

• [C-10-1] HARUS mendukung status kunci terpisah per perangkat virtual

• [C-10-2] Persyaratan dihapus di Android 16.

• [C-10-3] Persyaratan dihapus di Android 16.

• [C-10-4] HARUS mengunci semua layar saat pengguna memulai penguncian, termasuk melalui fitur pengguna penguncian yang diperlukan untuk perangkat genggam (lihat Bagian 2.2.5[9.11/H-1-2])

• [C-10-5] HARUS memiliki instance perangkat virtual terpisah per pengguna

• [C-10-6] HARUS menonaktifkan streaming aplikasi seperti yang ditunjukkan oleh DevicePolicyManager.setNearbyAppStreamingPolicy.

• [C-10-7] Persyaratan dihapus di Android 16.

• [C-10-11] HARUS menonaktifkan UI autentikasi di perangkat virtual, termasuk entri faktor pengetahuan dan perintah biometrik

• [C-10-12] Persyaratan dihapus di Android 16.

• [C-10-13] TIDAK BOLEH menggunakan status kunci perangkat virtual sebagai otorisasi autentikasi pengguna dengan Sistem Keystore Android. Lihat KeyGenParameterSpec.Builder.setUserAuthentication*.

• [C-10-14] HARUS menyediakan kemudahan pengguna untuk mengaktifkan berbagi papan klip antar-perangkat sebelum membagikan data papan klip antara perangkat fisik dan virtual jika perangkat menerapkan papan klip bersama.

• [C-10-15] HARUS menampilkan notifikasi saat data papan klip diakses di perangkat yang digunakan untuk mengakses dan di perangkat yang menjadi asal papan klip.

Jika implementasi perangkat memungkinkan pengguna mentransfer faktor pengetahuan autentikasi utama dari perangkat sumber ke perangkat target, seperti untuk penyiapan awal perangkat target, maka:

• [C-11-1] HARUS mengenkripsi faktor pengetahuan dengan jaminan perlindungan yang serupa dengan yang dijelaskan dalam white paper keamanan Layanan Google Cloud Key Vault saat mentransfer faktor pengetahuan dari perangkat sumber ke perangkat target sehingga faktor pengetahuan tidak dapat didekripsi dari jarak jauh atau digunakan untuk membuka kunci kedua perangkat dari jarak jauh.

• [C-11-2] HARUS, di perangkat sumber , meminta pengguna untuk mengonfirmasi faktor pengetahuan perangkat sumber sebelum mentransfer faktor pengetahuan ke perangkat target.

• [C-11-3] HARUS, di perangkat target yang tidak memiliki faktor pengetahuan autentikasi utama, meminta pengguna untuk mengonfirmasi faktor pengetahuan yang ditransfer di perangkat target sebelum menetapkan faktor pengetahuan tersebut sebagai faktor pengetahuan autentikasi utama untuk perangkat target dan sebelum menyediakan data yang ditransfer dari perangkat sumber.

Jika implementasi perangkat memiliki layar kunci yang aman dan menyertakan satu atau beberapa agen tepercaya, yang memanggil TrustAgentService.grantTrust() System API dengan flag FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE, maka:

• [C-12-1] HANYA boleh memanggil grantTrust() dengan tanda saat terhubung ke perangkat fisik terdekat dengan layar kunci sendiri, dan saat pengguna telah mengautentikasi identitasnya terhadap layar kunci tersebut. Perangkat terdekat dapat menggunakan mekanisme deteksi di pergelangan tangan atau di tubuh setelah pengguna membuka kunci satu kali untuk memenuhi persyaratan autentikasi pengguna.

• [C-12-2] HARUS menempatkan implementasi perangkat ke status TrustState.TRUSTABLE saat layar dinonaktifkan (seperti melalui penekanan tombol atau waktu tunggu layar) dan TrustAgent belum mencabut kepercayaan. AOSP memenuhi persyaratan ini.

• [C-12-3] HANYA boleh memindahkan perangkat dari TrustState.TRUSTABLE ke status TrustState.TRUSTED jika TrustAgent masih memberikan kepercayaan berdasarkan persyaratan dalam [C-12-1].

.

• [C-12-5] Penerapan yang mengandalkan pengukuran jarak yang aman dan akurat untuk memenuhi persyaratan [C-12-4] HARUS menggunakan salah satu solusi berikut:

  • Implementasi menggunakan UWB:

    • HARUS memenuhi persyaratan kesesuaian, sertifikasi, akurasi, dan kalibrasi untuk UWB yang dijelaskan dalam 7.4.9.

    • HARUS menggunakan salah satu mode keamanan P-STS yang tercantum di 7.4.9.

  • Implementasi menggunakan Wi-Fi Neighborhood Awareness Networking (NAN):

    • HARUS memenuhi persyaratan akurasi di 2.2.1 [7.4.2.5/H-SR-1], menggunakan bandwidth 160 MHz (atau yang lebih tinggi), dan mengikuti langkah-langkah penyiapan pengukuran yang ditentukan dalam Kalibrasi Kehadiran.

    • HARUS menggunakan LTF Aman seperti yang ditentukan dalam IEEE 802.11az.

Jika implementasi perangkat mengizinkan aplikasi membuat tampilan virtual sekunder dan mendukung peristiwa input terkait seperti melalui VirtualDeviceManager dan tampilan tidak ditandai dengan VIRTUAL_DISPLAY_FLAG_SECURE, maka:

• [C-13-8] HARUS memblokir aktivitas dengan atribut android:canDisplayOnRemoteDevices atau metadata android.activity.can_display_on_remote_devices yang disetel ke salah agar tidak dimulai di perangkat virtual.

• [C-13-9] HARUS memblokir aktivitas yang tidak secara eksplisit mengaktifkan streaming dan yang menunjukkan bahwa aktivitas tersebut menampilkan konten sensitif, termasuk melalui SurfaceView#setSecure dan FLAG_SECURE agar tidak dimulai di perangkat virtual.

Jika implementasi perangkat mendukung status daya tampilan terpisah melalui DeviceStateManager DAN mendukung status kunci tampilan terpisah melalui KeyguardDisplayManager, maka:

• [C-SR-2] SANGAT DISARANKAN untuk menggunakan kredensial yang memenuhi persyaratan yang ditentukan dalam pasal 9.11.1 atau Biometrik yang memenuhi setidaknya spesifikasi Kelas 1 yang ditentukan dalam pasal 7.3.10 untuk mengizinkan pembukaan kunci independen dari tampilan perangkat default.

• [C-SR-3] SANGAT DISARANKAN untuk membatasi pembukaan kunci layar terpisah melalui batas waktu layar yang ditentukan.

• [C-SR-4] SANGAT DISARANKAN untuk mengizinkan pengguna mengunci semua layar secara global melalui penguncian dari perangkat seluler utama.

9.11.2. StrongBox

Sistem Keystore Android memungkinkan developer aplikasi menyimpan kunci kriptografi di prosesor khusus yang aman serta lingkungan eksekusi terisolasi yang dijelaskan di atas. Prosesor aman khusus seperti itu disebut "StrongBox". Persyaratan C-1-3 hingga C-1-11 di bawah ini menentukan persyaratan yang harus dipenuhi perangkat agar memenuhi syarat sebagai StrongBox.

Implementasi perangkat yang memiliki prosesor aman khusus:

• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung StrongBox. StrongBox kemungkinan akan menjadi persyaratan dalam rilis mendatang.

Jika implementasi perangkat mendukung StrongBox, maka:

• [C-1-1] HARUS mendeklarasikan FEATURE_STRONGBOX_KEYSTORE.

• [C-1-2] HARUS menyediakan hardware aman khusus yang digunakan untuk mencadangkan keystore dan mengamankan autentikasi pengguna. Hardware aman khusus juga dapat digunakan untuk tujuan lain.

• [C-1-3] HARUS memiliki CPU terpisah yang tidak berbagi cache, DRAM, koprosesor atau resource inti lainnya dengan prosesor aplikasi (AP).

• [C-1-4] HARUS memastikan bahwa periferal apa pun yang dibagikan dengan AP tidak dapat mengubah pemrosesan StrongBox dengan cara apa pun, atau mendapatkan informasi apa pun dari StrongBox. AP DAPAT menonaktifkan atau memblokir akses ke StrongBox.

• [C-1-5] HARUS memiliki clock internal dengan akurasi yang wajar (+/- 10%) yang tidak dapat dimanipulasi oleh AP.

• [C-1-6] HARUS memiliki generator angka acak sebenarnya yang menghasilkan output yang terdistribusi secara seragam dan tidak dapat diprediksi.

• [C-1-7] HARUS memiliki ketahanan terhadap gangguan, termasuk ketahanan terhadap penetrasi fisik, dan gangguan.

• [C-1-8] HARUS memiliki ketahanan terhadap saluran samping, termasuk ketahanan terhadap kebocoran informasi melalui saluran samping daya, waktu, radiasi elektromagnetik, dan radiasi termal.

• [C-1-9] HARUS memiliki penyimpanan aman yang memastikan kerahasiaan, integritas, keaslian, konsistensi, dan keaktualan konten. Penyimpanan TIDAK BOLEH dapat dibaca atau diubah, kecuali sebagaimana diizinkan oleh StrongBox API.

Untuk memvalidasi kepatuhan terhadap [C-1-3] hingga [C-1-9], penerapan perangkat:

• [C-1-10] HARUS menyertakan hardware yang disertifikasi terhadap Secure IC Protection Profile BSI-CC-PP-0084-2014 atau BSI-CC-PP-0117-2022, atau dievaluasi oleh laboratorium pengujian terakreditasi nasional yang menggabungkan Penilaian kerentanan potensi serangan tinggi sesuai dengan Common Criteria Application of Attack Potential to Smartcards.

• [C-1-11] HARUS menyertakan firmware yang dievaluasi oleh laboratorium pengujian terakreditasi nasional yang menggabungkan penilaian kerentanan Potensi serangan tinggi sesuai dengan Common Criteria Application of Attack Potential to Smartcards.

• [C-SR-2] SANGAT DISARANKAN untuk menyertakan hardware yang dievaluasi menggunakan Target Keamanan, Tingkat Jaminan Evaluasi (EAL) 5, yang ditingkatkan dengan AVA_VAN.5. Sertifikasi EAL 5 kemungkinan akan menjadi persyaratan dalam rilis mendatang.

• [C-SR-3] SANGAT DISARANKAN untuk memberikan ketahanan terhadap serangan orang dalam (IAR), yang berarti bahwa orang dalam dengan akses ke kunci penandatanganan firmware tidak dapat menghasilkan firmware yang menyebabkan StrongBox membocorkan rahasia, untuk melewati persyaratan keamanan fungsional atau memungkinkan akses ke data pengguna yang sensitif. Cara yang direkomendasikan untuk menerapkan IAR adalah dengan mengizinkan update firmware hanya jika sandi pengguna utama diberikan melalui IAuthSecret HAL.

9.11.3. Kredensial Identitas

Sistem Kredensial Identitas ditentukan dan dicapai dengan menerapkan semua API dalam paket android.security.identity.*. API ini memungkinkan developer aplikasi menyimpan dan mengambil dokumen identitas pengguna. Implementasi perangkat:

• [C-SR-1] SANGAT DISARANKAN untuk menerapkan Sistem Kredensial Identitas.

Jika implementasi perangkat menerapkan Sistem Kredensial Identitas, perangkat tersebut:

• [C-1-1] HARUS menampilkan nilai non-null untuk metode IdentityCredentialStore#getInstance().

• [C-1-2] HARUS menerapkan Sistem Kredensial Identitas (misalnya, API android.security.identity.*) dengan kode yang berkomunikasi dengan aplikasi tepercaya di area yang terisolasi secara aman dari kode yang berjalan di kernel dan di atasnya. Isolasi aman HARUS memblokir semua potensi mekanisme yang memungkinkan kode kernel atau ruang pengguna mengakses status internal lingkungan yang diisolasi, termasuk DMA.

• [C-1-3] Operasi kriptografi yang diperlukan untuk menerapkan Sistem Kredensial Identitas (misalnya, API android.security.identity.*) HARUS dilakukan sepenuhnya di aplikasi tepercaya dan materi kunci pribadi TIDAK PERNAH keluar dari lingkungan eksekusi terisolasi kecuali jika secara khusus diperlukan oleh API tingkat yang lebih tinggi (misalnya, metode createEphemeralKeyPair()).

• [C-1-4] Aplikasi tepercaya HARUS diimplementasikan sedemikian rupa sehingga properti keamanannya tidak terpengaruh (misalnya, data kredensial tidak dirilis kecuali jika kondisi kontrol akses terpenuhi, MAC tidak dapat dibuat untuk data arbitrer) meskipun Android berperilaku tidak semestinya atau disusupi.

Project Android Open Source di upstream menyediakan implementasi referensi aplikasi tepercaya (libeic) yang dapat digunakan untuk mengimplementasikan sistem Kredensial Identitas.

9.12. Penghapusan Data

Semua penerapan perangkat:

• [C-0-1] HARUS memberi pengguna mekanisme untuk melakukan "Reset Data Pabrik".
• [C-0-2] HARUS menghapus semua data di sistem file userdata saat melakukan "Reset Data Pabrik".
• [C-0-3] HARUS menghapus data sedemikian rupa sehingga akan memenuhi standar industri yang relevan seperti NIST SP800-88 saat melakukan "Reset Data Pabrik".
• [C-0-4] HARUS memicu proses "Reset Data Pabrik" di atas saat DevicePolicyManager.wipeData() API dipanggil oleh aplikasi Pengontrol Kebijakan Perangkat pengguna utama.
• MAY menyediakan opsi penghapusan data cepat yang hanya melakukan penghapusan data logis.

9.13. Mode Booting Aman

Android menyediakan Mode Boot Aman, yang memungkinkan pengguna melakukan booting ke mode yang hanya mengizinkan aplikasi sistem yang telah diinstal sebelumnya untuk berjalan 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 membahayakan.

Implementasi perangkat adalah:

• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menerapkan Mode Booting Aman.

Jika implementasi perangkat menerapkan Mode Boot Aman, perangkat tersebut:

• [C-1-1] HARUS memberi pengguna opsi untuk memasuki Mode Boot Aman dengan cara yang tidak dapat diinterupsi dari aplikasi pihak ketiga yang diinstal di perangkat, kecuali jika aplikasi pihak ketiga tersebut adalah Pengontrol Kebijakan Perangkat dan telah menetapkan tanda UserManager.DISALLOW_SAFE_BOOT sebagai benar (true).

• [C-1-2] HARUS memberi pengguna kemampuan untuk meng-uninstal aplikasi pihak ketiga apa pun dalam Mode Aman.

• HARUS memberi pengguna opsi untuk memasuki Mode Booting Aman dari menu booting menggunakan alur kerja yang berbeda dari booting normal.

9.14. Isolasi Sistem Kendaraan Otomotif

Perangkat Android Automotive diharapkan bertukar data dengan subsistem kendaraan penting menggunakan HAL kendaraan untuk mengirim dan menerima pesan melalui jaringan kendaraan seperti bus CAN.

Pertukaran data dapat diamankan dengan menerapkan fitur keamanan di bawah lapisan framework Android untuk mencegah interaksi yang berbahaya atau tidak disengaja dengan subsistem ini.

9.15. Paket Langganan

"Paket langganan" mengacu pada detail paket hubungan penagihan yang diberikan oleh operator seluler melalui SubscriptionManager.setSubscriptionPlans().

Semua penerapan perangkat:

• [C-0-1] HARUS menampilkan paket langganan hanya ke aplikasi operator seluler yang awalnya menyediakannya.
• [C-0-2] TIDAK BOLEH mencadangkan atau mengupload paket langganan dari jarak jauh.
• [C-0-3] HANYA boleh mengizinkan penggantian, seperti SubscriptionManager.setSubscriptionOverrideCongested(), dari aplikasi operator seluler yang saat ini menyediakan paket langganan yang valid.

9.16. Migrasi Data Aplikasi

Jika implementasi perangkat menyertakan kemampuan untuk memigrasikan data dari satu perangkat ke perangkat lain dan tidak membatasi data aplikasi yang disalin ke data yang dikonfigurasi oleh developer aplikasi dalam manifes melalui atribut android:fullBackupContent, maka:

• [C-1-1] TIDAK BOLEH memulai transfer data aplikasi dari perangkat yang belum disetel oleh pengguna untuk autentikasi utama seperti yang dijelaskan dalam 9.11.1 Layar Kunci Aman dan Autentikasi.
• [C-1-2] HARUS mengonfirmasi autentikasi utama dengan aman di perangkat sumber dan mengonfirmasi maksud pengguna untuk menyalin data di perangkat sumber sebelum data ditransfer.
• [C-1-3] HARUS menggunakan pengesahan kunci keamanan untuk memastikan bahwa perangkat sumber dan perangkat target dalam migrasi perangkat ke perangkat adalah perangkat Android yang sah dan memiliki bootloader yang terkunci.
• [C-1-4] HANYA boleh memigrasikan data aplikasi ke aplikasi yang sama di perangkat target, dengan nama paket DAN sertifikat penandatanganan yang sama.

• [C-1-5] HARUS menunjukkan indikasi bahwa data perangkat sumber telah dimigrasikan oleh migrasi data antarperangkat di menu setelan. Pengguna TIDAK BOLEH dapat menghapus indikasi ini.

9.17. Framework Virtualisasi Android

API Android Virtualization Framework (AVF) (android.system.virtualmachine.*) memungkinkan aplikasi membuat virtual machine (VM), VM yang dilindungi (pVM), dan VM yang tidak dilindungi (non-pVM) di perangkat yang memuat dan menjalankan biner native sebagai payload.

Jika implementasi perangkat menyetel FEATURE_VIRTUALIZATION_FRAMEWORK ke true, maka:

• [C-1-1] HARUS memastikan bahwa android.system.virtualmachine.VirtualMachineManager.getCapabilities() menampilkan salah satu dari berikut ini:

  • CAPABILITY_PROTECTED_VM
  • CAPABILITY_NON_PROTECTED_VM
  • CAPABILITY_NON_PROTECTED_VM | CAPABILITY_PROTECTED_VM

9.18. Verifikasi Pengembang

Implementasi perangkat yang mendeklarasikan level API 36.1 atau yang lebih tinggi:

• DAPAT mencakup dukungan untuk layanan verifikasi developer guna memastikan bahwa aplikasi berasal dari developer yang dikenal.

Implementasi perangkat yang mendeklarasikan level API 36.1 atau yang lebih tinggi dan mengonfigurasi verifier developer dengan menentukan config_developerVerificationServiceProviderPackageName di config.xml:

• [9.18/C-1-1] HARUS memanggil android.content.pm.verify.developer.DeveloperVerifierService yang dikonfigurasi untuk setiap penginstalan paket aplikasi, yang mencakup penginstalan baru dan update ke aplikasi yang ada.

Implementasi perangkat yang mendeklarasikan level API 36.1 atau yang lebih tinggi:

• JUGA dapat mengonfigurasi penerima tugas untuk menyetel kebijakan aktif dengan menentukan config_developerVerificationPolicyDelegatePackageName di config.xml.

Jika verifier developer dikonfigurasi, penerapan perangkat:

• [9.18/C-2-1] HANYA boleh mengizinkan verifikator developer atau delegasinya yang dikonfigurasi untuk menetapkan kebijakan penginstalan seperti yang ditentukan dalam android.content.pm.PackageInstaller.

Jika verifikator dipanggil sebagai bagian dari sesi penginstalan paket, penerapan perangkat:

• [9.18/C-3-1] HARUS mencegah penginstalan paket aplikasi jika:

  • Penginstalan gagal karena verifikasi identitas developer.

  • Kebijakan verifikasi developer untuk sesi penginstalan disetel ke nilai selain DEVELOPER_VERIFICATION_POLICY_NONE.

  • Kecuali jika 9.18/C-3-2 atau 9.18/C-3-3 berlaku.

• [9.18/C-3-3] TIDAK BOLEH mencegah penginstalan paket aplikasi jika semua kondisi berikut terpenuhi:

  • Kebijakan ditetapkan ke DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_WARN atau DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_OPEN.

  • Verifikasi dilaporkan belum selesai.

  • Penginstal menunjukkan bahwa pengguna secara eksplisit meminta agar penginstalan dilanjutkan dengan melaporkan DEVELOPER_VERIFICATION_USER_RESPONSE_INSTALL_ANYWAY.

10. Pengujian Kompatibilitas Software

Implementasi perangkat HARUS lulus semua pengujian yang dijelaskan di bagian ini. Namun, perhatikan bahwa tidak ada paket pengujian software yang sepenuhnya komprehensif. Oleh karena itu, penerapan perangkat SANGAT DISARANKAN untuk melakukan perubahan sesedikit mungkin pada penerapan referensi dan pilihan Android yang tersedia dari Project Open Source Android. Tindakan ini akan meminimalkan risiko munculnya bug yang menyebabkan ketidakcocokan yang memerlukan pengerjaan ulang dan potensi update perangkat.

10.1. Compatibility Test Suite (CTS)

Implementasi perangkat:

• [C-0-1] HARUS lulus Android Compatibility Test Suite (CTS) yang tersedia dari Android Open Source Project, menggunakan software pengiriman akhir di perangkat.

• [C-0-2] HARUS memastikan kompatibilitas jika ada ambiguitas dalam CTS dan untuk setiap pengimplementasian ulang bagian kode sumber referensi.

CTS dirancang untuk dijalankan di perangkat sebenarnya. Seperti perangkat lunak lainnya, CTS sendiri mungkin berisi bug. CTS akan diberi versi secara terpisah dari Definisi Kompatibilitas ini, dan beberapa revisi CTS dapat dirilis untuk Android 17.

Implementasi perangkat:

• [C-0-3] HARUS lulus CTS versi terbaru yang tersedia pada saat software perangkat selesai.

• SEBAIKNYA menggunakan implementasi referensi di hierarki Android Open Source sebanyak mungkin.

10.2. Pemverifikasi CTS

CTS Verifier disertakan dengan Compatibility Test Suite, dan ditujukan untuk dijalankan oleh operator manusia untuk menguji fungsi yang tidak dapat diuji oleh sistem otomatis, seperti fungsi kamera dan sensor yang benar.

Implementasi perangkat:

• [C-0-1] HARUS menjalankan semua kasus yang berlaku dengan benar di verifier CTS.

CTS Verifier memiliki pengujian untuk berbagai jenis hardware, termasuk beberapa hardware yang bersifat opsional.

Implementasi perangkat:

• [C-0-2] HARUS lulus semua pengujian untuk hardware yang dimilikinya; misalnya, jika perangkat memiliki akselerometer, perangkat tersebut HARUS menjalankan kasus pengujian Akselerometer dengan benar di CTS Verifier.

Kasus pengujian untuk fitur yang ditandai sebagai opsional oleh Dokumen Definisi Kompatibilitas ini DAPAT dilewati atau dihilangkan.

• [C-0-2] Setiap perangkat dan setiap build HARUS menjalankan CTS Verifier dengan benar, seperti yang disebutkan di atas. Namun, karena banyak build yang sangat mirip, pelaksana perangkat tidak diharapkan untuk menjalankan CTS Verifier secara eksplisit pada build yang hanya berbeda dalam hal-hal sepele. Secara khusus, penerapan perangkat yang berbeda dari penerapan yang telah lulus CTS Verifier hanya berdasarkan set lokalitas, branding, dll. yang disertakan, DAPAT menghilangkan pengujian CTS Verifier.

11. Software yang Dapat Diupdate

• [C-0-1] Implementasi perangkat HARUS menyertakan mekanisme untuk mengganti seluruh software sistem. Mekanisme tidak perlu melakukan upgrade "langsung", yaitu, perangkat MUNGKIN perlu dimulai ulang. Metode apa pun dapat digunakan, asalkan dapat menggantikan seluruh software yang telah diinstal sebelumnya di perangkat. Misalnya, salah satu pendekatan berikut akan memenuhi persyaratan ini:

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

• [C-0-2] Mekanisme update yang digunakan HARUS mendukung update tanpa menghapus data pengguna. Artinya, mekanisme update HARUS mempertahankan data pribadi aplikasi dan data bersama aplikasi. Perhatikan bahwa software Android upstream mencakup mekanisme update yang memenuhi persyaratan ini.

• [C-0-3] Seluruh update HARUS ditandatangani dan mekanisme update di perangkat HARUS memverifikasi update dan tanda tangan terhadap kunci publik yang disimpan di perangkat.

• [C-SR-1] Mekanisme penandatanganan SANGAT DISARANKAN untuk meng-hash update dengan SHA-256 dan memvalidasi hash terhadap kunci publik menggunakan ECDSA NIST P-256.

Jika implementasi perangkat mencakup dukungan untuk koneksi data tanpa kuota seperti profil 802.11 atau Bluetooth PAN (Personal Area Network), maka:

• [C-1-1] HARUS mendukung download OTA dengan update offline melalui mulai ulang.

Implementasi perangkat HARUS memverifikasi bahwa image sistem identik secara biner 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.

Selain itu, implementasi perangkat HARUS mendukung update sistem A/B. AOSP menerapkan fitur ini menggunakan HAL kontrol booting.

Jika error ditemukan dalam penerapan perangkat setelah dirilis, tetapi dalam masa pakai produk yang wajar yang ditentukan setelah berkonsultasi dengan Tim Kompatibilitas Android dan memengaruhi kompatibilitas aplikasi pihak ketiga, maka:

• [C-2-1] Penerapan perangkat HARUS memperbaiki error 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. Jika subsistem update sistem untuk perangkat melaporkan android.software.device_admin, maka:

• [C-3-1] HARUS menerapkan perilaku yang dijelaskan dalam class SystemUpdatePolicy.

12. Log Perubahan Dokumen

Mulai Android 16, tidak ada log perubahan yang dikelola secara terpisah. Semua perubahan dari versi sebelumnya ditandai dalam dokumen ini.

13. Hubungi Kami

Anda dapat bergabung ke forum kompatibilitas android dan meminta klarifikasi atau menyampaikan masalah apa pun yang menurut Anda tidak tercakup dalam dokumen ini.