Definisi Kompatibilitas Android 14

1. Pengantar

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

Penggunaan "HARUS", "HARUS NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", dan "OPTIONAL" sesuai dengan standar IETF yang ditentukan dalam RFC2119.

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

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

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

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

Banyak resource yang ditautkan dalam dokumen ini berasal langsung atau tidak langsung dari Android SDK dan secara fungsional akan identik dengan informasi dalam dokumentasi SDK tersebut. Jika Definisi Kompatibilitas ini atau Compatibility Test Suite tidak sesuai dengan dokumentasi SDK, dokumentasi SDK akan dianggap otoritatif. Setiap detail teknis yang disediakan dalam resource 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 subbagian Bagian 2 dikhususkan untuk jenis perangkat tertentu.

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

1.1.2. ID Persyaratan

ID persyaratan ditetapkan untuk persyaratan HARUS.

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

Setiap ID didefinisikan sebagai berikut:

• ID Jenis Perangkat (lihat selengkapnya di 2. Jenis Perangkat)
  • C: Inti (Persyaratan yang diterapkan untuk semua implementasi perangkat Android)
  • H: Perangkat Genggam Android
  • T: Perangkat Android Television
  • J: Implementasi Android Automotive
  • W: Implementasi Android Watch
  • Tab: Implementasi Tablet Android
• ID Kondisi
  • Jika persyaratannya tidak kondisional, ID ini ditetapkan sebagai 0.
  • Jika persyaratan tersebut bersifat bersyarat, 1 ditetapkan untuk kondisi pertama dan angkanya akan bertambah sebesar 1 dalam bagian dan jenis perangkat yang sama.
• ID Persyaratan
  • ID ini dimulai dari 1 dan bertambah dengan 1 dalam bagian yang sama dan kondisi yang sama.

1.1.3 ID Persyaratan di Pasal 2

ID Persyaratan di Bagian 2 memiliki dua bagian. Bagian pertama terkait 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 (misalnya, 7.4.3/A-0-1).

2. Jenis Perangkat

Project Open Source Android menyediakan stack software 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 pasal 9 dan di bagian lain dalam CDD ini. Ada beberapa jenis perangkat yang memiliki ekosistem distribusi aplikasi yang relatif lebih baik.

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 jenis perangkat apa pun yang dijelaskan HARUS memenuhi semua persyaratan di bagian lain dari Definisi Kompatibilitas ini.

2.1 Konfigurasi Perangkat

Untuk 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 implementasi perangkat Android yang biasanya digunakan dengan memegangnya di tangan, seperti pemutar mp3, ponsel, atau tablet.

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

• Memiliki sumber listrik yang dapat memudahkan mobilitas, seperti baterai.
• Memiliki ukuran layar diagonal fisik dalam rentang 4 inci 3,3 inci (atau 2,5 inci untuk implementasi perangkat yang disertakan pada API level 29 atau yang lebih lama) hingga 8 inci.
• Memiliki antarmuka input layar sentuh.

Persyaratan tambahan di bagian selanjutnya ini khusus untuk implementasi 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 memenuhi semua persyaratan yang dijelaskan pada dokumen ini. layar yang berukuran minimal 2,2 inci untuk tepi pendek dan 3,4” di tepi panjang.

• [7.1.1.3/H-SR-1] SANGAT DIREKOMENDASIKAN untuk memberi pengguna kemampuan untuk mengubah ukuran tampilan (kepadatan layar).

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

Jika implementasi Perangkat genggam mengklaim dukungan untuk tampilan rentang dinamis tinggi hingga Configuration.isScreenHdr() , implementasi tersebut:

• [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 mendeklarasikan dukungan melalui properti sistem graphics.gpu.profiler.support, implementasi tersebut:

• [7.1.4.6/H-1-1] HARUS melaporkan rekaman aktivitas protobuf sebagai output yang sesuai dengan skema untuk penghitung GPU dan tahap render GPU yang ditentukan dalam dokumentasi Perfetto.
• [7.1.4.6/H-1-2] HARUS melaporkan nilai yang sesuai untuk penghitung GPU perangkat setelah proto paket pelacakan penghitung GPU.
• [7.1.4.6/H-1-3] HARUS melaporkan nilai yang sesuai untuk RenderStage GPU perangkat setelah proto paket rekaman aktivitas tahap render.
• [7.1.4.6/H-1-4] HARUS melaporkan tracepoint Frekuensi GPU sebagaimana ditentukan oleh format: power/gpu_frequency.

Implementasi perangkat genggam:

• [7.1.5/H-0-1] HARUS menyertakan dukungan untuk mode kompatibilitas aplikasi lama seperti yang diterapkan oleh kode open source Android upstream. Artinya, implementasi perangkat TIDAK BOLEH mengubah pemicu atau batas tempat 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 mengirim peristiwa tekan lama dan normal dari fungsi Kembali (KEYCODE_BACK) ke aplikasi latar depan. Peristiwa ini TIDAK BOLEH digunakan oleh sistem dan DAPAT dipicu oleh luar perangkat Android (mis. keyboard hardware eksternal yang terhubung ke perangkat Android).
• [7.2.3/H-0-3] HARUS menyediakan fungsi Layar utama di semua layar yang kompatibel dengan Android yang menyediakan layar utama.
• [7.2.3/H-0-4] HARUS menyediakan fungsi Kembali pada 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 DIREKOMENDASIKAN 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 DIREKOMENDASIKAN untuk menyertakan akselerometer 3 sumbu.

Jika implementasi perangkat genggam menyertakan akselerometer 3 sumbu, implementasi tersebut:

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

Jika implementasi perangkat genggam menyertakan penerima GPS/GNSS dan melaporkan kemampuan ke aplikasi melalui flag 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 pseudorange dan laju pseudorange GNSS, yang, dalam kondisi langit terbuka setelah menentukan lokasi, sementara tetap atau bergerak dengan akselerasi kurang dari 0,2 meter per detik kuadrat , cukup untuk menghitung posisi dalam jarak 20 meter, dan kecepatan dalam 0,2 meter per detik, minimal 95%

Jika implementasi perangkat genggam menyertakan giroskop 3 sumbu, implementasi tersebut:

• [7.3.4/H-3-1] HARUS dapat melaporkan peristiwa hingga frekuensi setidaknya 100 Hz.
• [7.3.4/H-3-2] HARUS mampu mengukur perubahan orientasi hingga 1.000 derajat per detik.

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

• [7.3.8/H] SEHARUSNYA menyertakan sensor kedekatan.

Implementasi perangkat genggam:

• [7.3.11/H-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung sensor pose dengan 6 derajat kebebasan.
• [7.4.3/H] SEHARUSNYA menyertakan dukungan untuk Bluetooth dan Bluetooth LE.

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

• [7.4.2.5/H-1-1] HARUS melaporkan rentang secara akurat ke dalam +/-1 meter MHz pada bandwidth 160 MHz pada persentil ke-68 (sebagaimana dihitung dengan Fungsi Distribusi Kumulatif), +/-2 meter pada bandwidth 80 MHz pada persentil ke-68, +/-4 meter pada bandwidth persentil ke-40 MHz pada

• [7.4.2.5/H-SR-1] SANGAT DIREKOMENDASIKAN untuk melaporkan rentang secara akurat dalam +/-1 meter pada bandwidth 160 MHz pada persentil ke-90 MHz (sebagaimana dihitung dengan Fungsi Distribusi Kumulatif), +/-2 meter pada bandwidth 80 MHz pada bandwidth ke-90, +/-4 MHz pada persentil ke-90 MHz pada persentil 90 MHz, dan +/-4 meter pada bandwidth 80 MHz pada persentil ke-90, +/-4 MHz pada persentil 40 MHz

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

Jika implementasi perangkat genggam menyertakan perangkat kamera logis yang mencantumkan kemampuan menggunakan CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, implementasi tersebut:

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

Implementasi perangkat genggam:

• [7.6.1/H-0-1] HARUS memiliki minimal 4 GB penyimpanan non-volatil 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 tampilan default menggunakan resolusi framebuffer hingga qHD (mis. FWVGA).

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

• [7.6.1/H-3-1] Memori yang tersedia untuk kernel dan userspace HARUS berukuran minimal 896 MB jika tampilan default menggunakan resolusi framebuffer hingga FHD (mis. WSXGA+).

• [7.6.1/H-4-1] Memori yang tersedia untuk kernel dan userspace HARUS berukuran minimal 1.344 MB jika tampilan default menggunakan resolusi framebuffer hingga QHD (mis. QWXGA).

Jika implementasi perangkat genggam mendeklarasikan dukungan untuk ABI 64-bit (dengan atau tanpa ABI 32-bit):

• [7.6.1/H-5-1] Memori yang tersedia untuk kernel dan userspace HARUS minimal 816 MB jika tampilan default menggunakan resolusi framebuffer hingga qHD (mis. FWVGA).

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

• [7.6.1/H-7-1] Memori yang tersedia untuk kernel dan userspace HARUS minimal 1.280 MB jika layar default menggunakan resolusi framebuffer hingga FHD (mis. WSXGA+).

• [7.6.1/H-8-1] Memori yang tersedia untuk kernel dan userspace HARUS minimal 1824 MB jika tampilan default menggunakan resolusi framebuffer hingga QHD (mis. QWXGA).

Perlu diperhatikan bahwa "memori yang tersedia untuk kernel dan userspace" di atas mengacu pada ruang memori yang disediakan selain memori yang telah dikhususkan untuk komponen hardware seperti radio, video, dan sebagainya yang tidak berada di bawah kontrol kernel pada implementasi perangkat.

Jika implementasi perangkat genggam menyertakan memori kurang dari atau sama dengan 1 GB yang tersedia untuk kernel dan userspace, implementasi tersebut:

• [7.6.1/H-9-1] HARUS mendeklarasikan tombol fitur android.hardware.ram.low.
• [7.6.1/H-9-2] HARUS memiliki setidaknya 1,1 GB penyimpanan non-volatil untuk data pribadi aplikasi (alias partisi "/data").

Jika implementasi perangkat genggam menyertakan memori lebih dari 1 GB yang tersedia untuk kernel dan userspace, implementasi tersebut:

• [7.6.1/H-10-1] HARUS memiliki setidaknya 4 GB penyimpanan non-volatil yang tersedia untuk data pribadi aplikasi (alias partisi "/data").
• HARUS mendeklarasikan tombol fitur android.hardware.ram.normal.

Jika implementasi perangkat genggam menyertakan memori lebih besar dari atau sama dengan 2 GB dan kurang dari 4 GB yang tersedia untuk kernel dan userspace, implementasi tersebut:

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

Jika implementasi perangkat genggam menyertakan memori kurang dari 2 GB yang tersedia untuk kernel dan userspace, implementasi tersebut:

• [7.6.1/H-1-1] HARUS mendukung ABI 32-bit saja.

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 yang mendukung mode periferal, implementasi tersebut:

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

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

• [7.7.2/H-1-1] HARUS mengimplementasikan 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 implementasi perangkat genggam mampu memenuhi semua persyaratan performa untuk mendukung mode VR dan menyertakan dukungan untuknya, implementasi tersebut:

• [7.9.1/H-1-1] HARUS mendeklarasikan tombol fitur android.hardware.vr.high_performance.
• [7.9.1/H-1-2] HARUS menyertakan aplikasi yang mengimplementasikan 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 implementasi (class audio USB), selain persyaratan di bagian 7.7.2, implementasi tersebut:

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

Fungsi	Pemetaan	Konteks	Perilaku
J	Halaman penggunaan HID: 0x0C Penggunaan HID: 0x0CD Kunci kernel: KEY_PLAYPAUSE Kunci Android: KEYCODE_MEDIA_PLAY_PAUSE	Pemutaran media	Input: Tekan singkat Output: Putar atau jeda
			Input: Tekan lama Output: Meluncurkan perintah suara Mengirim: android.speech.action.VOICE_SEARCH_HANDS_FREE jika perangkat terkunci atau layarnya nonaktif. Jika tidak, mengirimkan android.speech.RecognizerIntent.ACTION_WEB_SEARCH
		Panggilan masuk	Input: Tekan singkat Output: Terima panggilan
			Input: Tekan lama Output: Menolak panggilan
		Panggilan sedang berlangsung	Input: Tekan singkat Output: Akhiri panggilan
			Input: Tekan lama Output: Bisukan atau bunyikan mikrofon
M	Halaman penggunaan HID: 0x0C Penggunaan HID: 0x0E9 Kunci kernel: KEY_VOLUMEUP Kunci Android: VOLUME_UP	Pemutaran media, Panggilan sedang berlangsung	Input: Tekan singkat 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 singkat 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 dalam keadaan apa pun.	Input: Tekan pendek atau lama Output: Meluncurkan perintah suara

• [7.8.2.2/H-1-2] HARUS memicu ACTION_HEADSET_PLUG di atas steker steker, 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 akan:

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

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

• [7.8.2.2/H-3-1] HARUS menyiarkan Intent ACTION_HEADSET_PLUG dengan tambahan "mikrofon" yang disetel ke 1.

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

• [7.8.2.2/H-4-1] HARUS mencantumkan perangkat jenis 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 jenis AudioDeviceInfo.TYPE_USB_HEADSET dan role isSink() jika kolom jenis terminal audio USB adalah 0x0402.

• [7.8.2.2/H-4-3] HARUS mencantumkan perangkat jenis 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 jenis 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 jenis 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 jenis 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 jenis AudioDeviceInfo.TYPE_USB_DEVICE dan peran isSource() jika kolom jenis terminal audio USB adalah 0x400.

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

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

• [5.6/H-1-1] HARUS memiliki latensi Rata-rata Round-Trip Berkelanjutan 300 milidetik atau kurang dari 5 pengukuran, dengan Deviasi Absolut Rata-rata kurang dari 30 md, pada jalur data berikut: "speaker ke mikrofon", adaptor loopback 3,5 mm (jika didukung), loopback USB (jika didukung).

• [5.6/H-1-2] HARUS memiliki latensi Ketuk untuk nada rata-rata 300 milidetik atau kurang pada setidaknya 5 pengukuran pada jalur data speaker ke mikrofon.

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

Jika implementasi perangkat genggam menyertakan setidaknya satu aktuator resonansi linear tujuan umum 7.10 , implementasi tersebut:

• [7.10/H] HARAP pindahkan aktuator haptik ke sumbu X (kiri-kanan) orientasi alami potret perangkat.

Jika implementasi perangkat genggam memiliki aktuator haptik tujuan umum yaitu aktuator resonant linear sumbu X (LRA), implementasi tersebut:

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

Jika implementasi perangkat genggam mengikuti pemetaan konstanta haptic, implementasi tersebut:

• [7.10/H]* HARUS memverifikasi status implementasi 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 mengupdate jika diperlukan, konfigurasi penggantian untuk primitif yang tidak didukung seperti yang dijelaskan dalam panduan penerapan untuk konstanta.

2.2.2. Multimedia

Implementasi 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 (Peningkatan AAC penundaan rendah)

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

• [5,2/H-0-1] AVC H.264
• [5,2/H-0-2] VP8

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

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

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, serta memberikan kemampuan pengguna untuk mengakses data penyedia dokumen dengan menggunakan DocumentsProvider API.
• [3.2.3.1/H-0-2]* HARUS melakukan pramuat 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.2.3.1/H-SR-1] SANGAT DIREKOMENDASIKAN untuk melakukan pramuat aplikasi email yang dapat menangani ACTION_SENDTO atau ACTION_SEND atau ACTION_SEND_MULTIPLE untuk mengirim email.
• [3.4.1/H-0-1] HARUS memberikan 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 DIREKOMENDASIKAN untuk menerapkan peluncur default yang mendukung penyematan pintasan, widget, dan widgetFeatures dalam aplikasi.
• [3.8.1/H-SR-2] SANGAT DIREKOMENDASIKAN untuk menerapkan peluncur default yang menyediakan akses cepat ke pintasan tambahan yang disediakan oleh aplikasi pihak ketiga melalui ShortcutManager API.
• [3.8.1/H-SR-3] SANGAT DIREKOMENDASIKAN untuk menyertakan aplikasi peluncur default yang menampilkan badge untuk ikon aplikasi.
• [3.8.2/H-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung widget aplikasi pihak ketiga.
• [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 yang beragam.
• [3.8.3/H-0-3] HARUS mendukung notifikasi pendahuluan.
• [3.8.3/H-0-4] HARUS menyertakan menu notifikasi, sehingga pengguna dapat mengontrol secara langsung (misalnya membalas, menunda, menutup, memblokir) notifikasi melalui kemampuan pengguna seperti tombol tindakan atau panel kontrol seperti yang diimplementasikan dalam AOSP.
• [3.8.3/H-0-5] HARUS menampilkan pilihan yang diberikan melalui RemoteInput.Builder setChoices() di menu notifikasi.
• [3.8.3/H-SR-1] SANGAT DIREKOMENDASIKAN untuk menampilkan pilihan pertama yang disediakan melalui RemoteInput.Builder setChoices() di menu notifikasi tanpa interaksi pengguna tambahan.
• [3.8.3/H-SR-2] SANGAT DIREKOMENDASIKAN untuk menampilkan semua pilihan yang diberikan melalui RemoteInput.Builder setChoices() di menu notifikasi saat pengguna memperluas semua notifikasi di menu notifikasi.
• [3.8.3.1/H-SR-1] SANGAT DIREKOMENDASIKAN untuk menampilkan tindakan dengan Notification.Action.Builder.setContextual ditetapkan sebagai true inline dengan balasan yang ditampilkan oleh Notification.Remoteinput.Builder.setChoices.
• [3.8.4/H-SR-1] SANGAT DIREKOMENDASIKAN untuk menerapkan asisten di perangkat guna menangani tindakan Bantuan.

Jika implementasi perangkat genggam mendukung notifikasi MediaStyle, implementasi tersebut:

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

Jika implementasi Perangkat genggam mendukung tindakan Assist, implementasi tersebut:

• [3.8.4/H-SR-2] SANGAT DIREKOMENDASIKAN untuk menggunakan tekan lama tombol HOME sebagai 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 mengimplementasikan VoiceInteractionService , atau aktivitas yang menangani intent ACTION_ASSIST.

Jika implementasi Perangkat genggam mendukung conversation notifications dan mengelompokkannya ke dalam bagian yang terpisah dari pemberitahuan dan notifikasi non-percakapan diam, implementasi tersebut:

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

Jika implementasi perangkat Genggam Android mendukung layar kunci, implementasi tersebut:

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

Jika implementasi perangkat genggam mendukung layar kunci yang aman, implementasi tersebut:

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

Jika implementasi perangkat genggam menyertakan dukungan untuk ControlsProviderService dan Control API serta memungkinkan aplikasi pihak ketiga memublikasikan kontrol perangkat, implementasi tersebut:

• [3.8.16/H-1-1] HARUS mendeklarasikan tanda fitur android.software.controls dan menyetelnya ke true.
• [3.8.16/H-1-2] HARUS memberi pengguna 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 memberikan 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 memberikan kontrol melalui ControlsProviderService API serta kolom tertentu yang disediakan oleh Control API.

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

Sebaliknya, jika implementasi perangkat genggam tidak menerapkan kontrol tersebut, implementasi tersebut:

• [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 implementasi perangkat genggam tidak berjalan dalam mode kunci tugas, saat konten disalin ke papan klip, implementasi tersebut:

• [3.8.17/H-1-1] HARUS memberikan 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 DIREKOMENDASIKAN untuk melakukan pramuat layanan aksesibilitas di perangkat yang sebanding dengan atau melebihi fungsi Tombol Akses dan TalkBack (untuk bahasa yang didukung oleh mesin Text-to-speech bawaan) seperti yang disediakan dalam project open source talkback.
• [3.11/H-0-1] HARUS mendukung penginstalan mesin TTS pihak ketiga.
• [3.11/H-SR-1] SANGAT DIREKOMENDASIKAN untuk menyertakan mesin TTS yang mendukung bahasa yang tersedia di perangkat.
• [3.13/H-SR-1] SANGAT DIREKOMENDASIKAN untuk menyertakan komponen UI Setelan Cepat.

Jika implementasi perangkat genggam Android mendeklarasikan dukungan FEATURE_BLUETOOTH atau FEATURE_WIFI, implementasi tersebut:

• [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] Zona pengenalan gestur untuk fungsi Beranda SEHARUSNYA tidak lebih tinggi dari 32 dp dari bagian bawah layar.

Jika implementasi 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 di setiap sisi. Secara default, area gestur HARUS memiliki lebar 24 dp.

Jika implementasi perangkat genggam mendukung layar kunci yang aman dan memiliki memori yang tersedia lebih dari atau sama dengan 2 GB untuk kernel dan userspace, implementasi tersebut:

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

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

• [7.5.4/H-1-1] HARUS menjalankan intent android.media.action.STILL_IMAGE_CAMERA dan android.media.action.STILL_IMAGE_CAMERA_SECURE serta meluncurkan kamera dalam mode gambar diam seperti yang dijelaskan dalam SDK.
• [7.5.4/H-1-2] HARUS mematuhi intent android.media.action.VIDEO_CAMERA untuk meluncurkan kamera dalam mode video seperti yang dijelaskan dalam SDK.

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

• [3.2.3.1/ H-1-1] HARUS memiliki aktivitas yang menangani intent Settings#ACTION_SETTINGS_Setting_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 Setelan#EXTRA_SETTINGS_SettingDED_DEEP_LINK_INTENT_URI.

2.2.4. Performa dan Kekuatan

• [8.1/H-0-1] Latensi frame yang konsisten. Latensi frame yang tidak konsisten atau penundaan untuk merender frame TIDAK BOLEH terjadi lebih dari 5 frame dalam satu detik, dan HARUS di bawah 1 frame dalam satu detik.
• [8.1/H-0-2] Latensi antarmuka pengguna. Implementasi perangkat HARUS memastikan pengalaman pengguna berlatensi rendah dengan men-scroll daftar 10 ribu entri daftar seperti yang ditentukan oleh Android Compatibility Test Suite (CTS) dalam waktu kurang dari 36 detik.
• [8.1/H-0-3] Pengalihan tugas. Jika beberapa aplikasi telah diluncurkan, meluncurkan kembali aplikasi yang sudah berjalan setelah diluncurkan HARUS memakan waktu kurang dari 1 detik.

Implementasi perangkat genggam:

• [8.2/H-0-1] HARUS memastikan performa penulisan berurutan setidaknya 5 MB/dtk.
• [8.2/H-0-2] HARUS memastikan performa penulisan acak setidaknya 0,5 MB/dtk.
• [8.2/H-0-3] HARUS memastikan performa baca berurutan setidaknya 15 MB/dtk.
• [8.2/H-0-4] HARUS memastikan performa baca acak setidaknya 3,5 MB/dtk.

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

• [8.3/H-1-1] HARUS memberikan kemampuan pengguna untuk mengaktifkan dan menonaktifkan fitur penghemat baterai.
• [8.3/H-1-2] HARUS memberikan kemampuan pengguna untuk menampilkan semua aplikasi yang dikecualikan dari mode hemat daya Aplikasi Standby dan Istirahatkan.

Implementasi perangkat genggam:

• [8.4/H-0-1] HARUS menyediakan profil daya per komponen yang menentukan nilai konsumsi saat ini untuk setiap komponen hardware dan perkiraan pengurasan baterai yang disebabkan oleh komponen dari waktu ke waktu, seperti yang didokumentasikan di situs Project Open Source Android.
• [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 implementasi 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 menyertakan output layar atau video, implementasi tersebut:

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

Implementasi perangkat genggam:

• [8.5/H-0-1] HARUS memberikan kemampuan pengguna di menu Setelan 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. dan kemampuan untuk menghentikan aplikasi yang menjalankan layanan latar depan atau aplikasi yang dimulai oleh pengguna.
  • Beberapa aplikasi mungkin dikecualikan dari penghentian atau dicantumkan dalam kemampuan pengguna seperti yang dijelaskan dalam dokumen SDK.

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 intent android.settings.ACTION_USAGE_ACCESS_SETTINGS.

Implementasi perangkat genggam:

• [9.11/H-0-2] HARUS mencadangkan implementasi keystore dengan lingkungan eksekusi yang terisolasi.
• [9.11/H-0-3] HARUS memiliki implementasi algoritma kriptografi RSA, AES, ECDSA, dan HMAC, serta fungsi hash kelompok MD5, SHA1, 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 mekanisme potensial yang digunakan kode kernel atau userspace untuk mengakses status internal lingkungan yang terisolasi, termasuk DMA. Project Open Source Android (AOSP) upstream memenuhi persyaratan ini dengan menggunakan implementasi Trusty, tetapi solusi berbasis ARM TrustZone lain atau implementasi aman yang ditinjau oleh pihak ketiga dari isolasi berbasis hypervisor yang tepat merupakan opsi alternatif.
• [9.11/H-0-4] HARUS melakukan autentikasi layar kunci di lingkungan eksekusi yang terisolasi dan hanya jika berhasil, biarkan kunci yang terikat autentikasi dapat digunakan. Kredensial layar kunci HARUS disimpan dengan cara yang hanya memungkinkan lingkungan eksekusi yang terisolasi untuk melakukan autentikasi layar kunci. Project Open Source Android upstream menyediakan Gatekeeper Hardware Abstraksi Layer (HAL) 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 yang aman dan penandatanganan dilakukan dalam hardware yang aman. Kunci penandatanganan pengesahan HARUS dibagikan ke seluruh perangkat dalam jumlah yang cukup besar untuk mencegah kunci digunakan sebagai ID perangkat. Salah satu cara untuk memenuhi persyaratan ini adalah dengan berbagi kunci pengesahan yang sama kecuali jika menghasilkan minimal 100.000 unit SKU tertentu. Jika lebih dari 100.000 unit SKU dihasilkan, kunci yang berbeda DAPAT digunakan untuk setiap 100.000 unit.

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

Jika implementasi Perangkat genggam mendukung layar kunci yang aman, implementasi tersebut:

• [9.11/H-1-1] HARUS mengizinkan pengguna untuk 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 memberikan kemampuan pengguna untuk menyembunyikan notifikasi dan menonaktifkan semua bentuk autentikasi kecuali untuk autentikasi utama yang dijelaskan dalam 9.11.1 Layar Kunci Aman. AOSP memenuhi persyaratan sebagai mode kunci total.

Jika implementasi perangkat genggam menyertakan beberapa pengguna dan tidak mendeklarasikan tombol fitur android.hardware.telephony, implementasi tersebut:

• [9.5/H-2-1] HARUS mendukung profil yang dibatasi, yaitu 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 batasan yang lebih terperinci pada aplikasi yang tersedia di lingkungan tersebut.

Jika implementasi perangkat genggam menyertakan beberapa pengguna dan mendeklarasikan tombol fitur android.hardware.telephony, implementasi tersebut:

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

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

Jika implementasi perangkat genggam mendukung HotwordDetectionService System API atau mekanisme lain untuk deteksi frasa pengaktif tanpa indikasi akses mikrofon, implementasi tersebut:

• [9.8/H-1-1] HARUS memastikan layanan deteksi frasa pengaktif 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 frasa pengaktif 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 berdurasi lebih dari 30 detik untuk setiap permintaan yang dipicu hardware ke layanan deteksi frasa pengaktif.
• [9.8/H-1-4] TIDAK BOLEH menyediakan audio mikrofon yang di-buffer yang berdurasi lebih dari 8 detik untuk satu permintaan ke layanan deteksi frasa pengaktif.
• [9.8/H-1-5] TIDAK BOLEH menyediakan audio mikrofon yang di-buffer yang lebih lama dari 30 detik ke layanan interaksi suara atau entitas serupa.
• [9.8/H-1-6] TIDAK BOLEH mengizinkan lebih dari 100 byte data dikirim keluar dari layanan deteksi frasa pengaktif pada setiap hasil frasa pengaktif yang berhasil kecuali untuk data audio yang diteruskan melalui HotwordAudioStream.
• [9.8/H-1-7] TIDAK BOLEH mengizinkan lebih dari 5 bit data dikirim keluar dari layanan deteksi frasa pengaktif pada setiap hasil frasa pengaktif negatif.
• [9.8/H-1-8] HARUS mengizinkan transmisi data saja dari layanan deteksi frasa pengaktif pada permintaan validasi frasa pengaktif dari server sistem.
• [9.8/H-1-9] TIDAK BOLEH mengizinkan aplikasi yang dapat diinstal pengguna menyediakan layanan deteksi frasa pengaktif.
• [9.8/H-1-10] TIDAK BOLEH ditampilkan di data kuantitatif UI tentang penggunaan mikrofon oleh layanan deteksi frasa pengaktif.
• [9.8/H-1-11] HARUS mencatat jumlah byte yang disertakan dalam setiap transmisi dari layanan deteksi frasa pengaktif agar dapat melakukan pemeriksaan bagi peneliti keamanan.
• [9.8/H-1-12] HARUS mendukung mode debug yang mencatat konten mentah setiap transmisi dari layanan deteksi frasa pengaktif guna memungkinkan pemeriksaan bagi peneliti keamanan.
• [9.8/H-1-14] HARUS menampilkan indikator mikrofon, seperti yang dijelaskan di bagian 9.8.2, saat hasil frasa pengaktif yang berhasil dikirim ke layanan interaksi suara atau entitas serupa.

• [9.8/H-SR-1] SANGAT DIREKOMENDASIKAN untuk memberi tahu pengguna sebelum menyetel aplikasi sebagai penyedia layanan deteksi frasa pengaktif.
• [9.8/H-SR-2] SANGAT DIREKOMENDASIKAN untuk melarang transmisi data tidak terstruktur keluar dari layanan deteksi frasa pengaktif.
• [9.8/H-SR-3] SANGAT DIREKOMENDASIKAN untuk memulai ulang proses hosting layanan deteksi frasa pengaktif 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 frasa pengaktif tanpa indikasi penggunaan mikrofon, aplikasi akan:

• [9.8/H-2-1] HARUS memberikan pemberitahuan eksplisit kepada pengguna untuk setiap frasa frasa pengaktif yang didukung.
• [9.8/H-2-2] TIDAK BOLEH mempertahankan data audio mentah, atau data yang berasal darinya, melalui layanan deteksi frasa pengaktif.
• [9.8/H-2-3] TIDAK BOLEH mentransmisikan dari layanan deteksi frasa pengaktif, data audio, data yang dapat digunakan untuk merekonstruksi (seluruhnya atau sebagian) konten audio, atau audio yang tidak terkait dengan frasa pengaktif itu sendiri, kecuali untuk ContentCaptureService atau layanan pengenalan ucapan di perangkat.

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

• [9.8.2/H-4-1] HARUS menampilkan indikator mikrofon saat aplikasi sedang mengakses data audio dari mikrofon, tetapi tidak saat mikrofon hanya diakses oleh HotwordDetectionService, SOURCE_HOTWORD,ContentCaptureService atau aplikasi yang memegang 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 menggunakan mikrofon seperti yang ditampilkan dari PermissionManager.getIndicatorAppOpUsageData(), bersama dengan pesan atribusi apa pun 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(), beserta pesan atribusi apa pun yang terkait.

2.2.6. Kompatibilitas Opsi dan Developer Tools

Implementasi perangkat genggam (* Tidak berlaku untuk Tablet):

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

Implementasi perangkat genggam (* Tidak berlaku untuk Tablet):

• Perfetto
  • [6.1/H-0-2]* HARUS mengekspos biner /system/bin/perfetto ke pengguna shell yang mematuhi cmdline 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 yang dilacak perfetto HARUS diaktifkan secara default (properti sistem persist.traced.enable).

2.2.7. Kelas Performa Media Genggam

Lihat Bagian 7.11 untuk mengetahui definisi class performa media.

2.2.7.1. Media

Jika implementasi Perangkat genggam menampilkan android.os.Build.VERSION_CODES.T untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, implementasi tersebut:

• HARUS memenuhi persyaratan media yang tercantum di Android 13 CDD bagian 2.2.7.1.

2.2.7.2. Kamera

Jika implementasi Perangkat genggam menampilkan android.os.Build.VERSION_CODES.T untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, implementasi tersebut:

• HARUS memenuhi persyaratan media yang tercantum di Android 13 CDD bagian 2.2.7.2.

2.2.7.3. Hardware

Jika implementasi Perangkat genggam menampilkan android.os.Build.VERSION_CODES.T untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, implementasi tersebut:

• HARUS memenuhi persyaratan media yang tercantum di Android 13 CDD bagian 2.2.7.3.

2.2.7.4. Performa

Jika implementasi Perangkat genggam menampilkan android.os.Build.VERSION_CODES.T untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, implementasi tersebut:

• HARUS memenuhi persyaratan performa yang tercantum di CDD Android 13 bagian 2.2.7.4.

2.3. Persyaratan Televisi

Perangkat Android Televisi mengacu pada penerapan perangkat Android yang merupakan antarmuka hiburan untuk menonton media digital, film, game, aplikasi, dan/atau TV live bagi pengguna yang duduk sekitar 10 meter (“lean back” atau “antarmuka pengguna 10 kaki”).

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

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

Persyaratan tambahan di bagian lainnya ini khusus untuk implementasi 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 mengirim 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 tombol fitur android.hardware.gamepad.
• [7.2.7/T] HARUS menyediakan remote control tempat pengguna dapat mengakses input navigasi non-sentuh dan tombol navigasi inti.

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

• [7.3.4/T-1-1] HARUS dapat melaporkan peristiwa hingga frekuensi setidaknya 100 Hz.
• [7.3.4/T-1-2] HARUS mampu mengukur perubahan orientasi hingga 1.000 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 minimal 4 GB penyimpanan non-volatil yang tersedia untuk data pribadi aplikasi (alias partisi "/data").

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

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

Jika implementasi perangkat TV adalah 32-bit:

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

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

Jika implementasi perangkat TV adalah 64-bit:

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

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

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 implementasi perangkat.

Implementasi perangkat televisi:

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

2.3.2. Multimedia

Implementasi 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] Profil MPEG-4 HE AAC (AAC+)
• [5.1/T-0-3] AAC ELD (AAC penundaan rendah yang ditingkatkan)

Implementasi 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

Implementasi perangkat televisi:

• [5.2.2/T-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung encoding H.264 untuk video beresolusi 720p dan 1080p pada kecepatan 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] AVC H.264
• [5.3.5/T-0-3] HEVC H.265
• [5.3.6/T-0-4] VP8
• [5.3.7/T-0-5] VP9
• [5.3.1/T-0-6] MPEG-2

Implementasi perangkat televisi HARUS mendukung dekode MPEG-2, seperti yang dijelaskan di Bagian 5.3.1, pada kecepatan frame dan resolusi video standar hingga dan termasuk:

• [5.3.1/T-1-1] HD 1080p pada 29,97 frame per detik dengan Tingkat Tinggi Profil Utama.
• [5.3.1/T-1-2] HD 1080i dengan kecepatan 59,94 frame per detik dengan Tingkat Tinggi Profil Utama. Modul ini HARUS mengurai video MPEG-2 yang bertautan dan menyediakannya untuk aplikasi pihak ketiga.

Implementasi perangkat televisi HARUS mendukung dekode H.264, seperti yang dijelaskan di Bagian 5.3.4, pada kecepatan frame dan resolusi video standar hingga dan termasuk:

• [5.3.4/T-1-1] HD 1080p dengan 60 frame per detik dengan Profil Dasar Pengukuran
• [5.3.4/T-1-2] HD 1080p dengan 60 frame per detik dengan Profil Utama
• [5.3.4/T-1-3] HD 1080p pada 60 frame per detik dengan Level Profil Tinggi 4.2

Implementasi perangkat televisi dengan decoder hardware H.265 HARUS mendukung dekode H.265, sebagaimana dijelaskan dalam Pasal 5.3.5, pada kecepatan frame dan resolusi video standar hingga dan termasuk:

• [5.3.5/T-1-1] HD 1080p dengan 60 frame per detik dengan Profil Utama Level 4.1

Jika implementasi perangkat Televisi dengan decoder hardware H.265 mendukung dekode H.265 dan profil decoding UHD, implementasi tersebut:

• [5.3.5/T-2-1] HARUS mendukung profil decoding UHD pada 60 frame per detik dengan profil Tingkat Utama Main10 Level 5

Implementasi perangkat televisi HARUS mendukung dekode VP8, seperti yang dijelaskan di Bagian 5.3.6, pada kecepatan frame dan resolusi video standar hingga dan termasuk:

• [5.3.6/T-1-1] HD 1080p dengan profil decoding 60 frame per detik

Implementasi perangkat televisi dengan decoder hardware VP9 HARUS mendukung decoding VP9, seperti dijelaskan dalam Pasal 5.3.7, pada kecepatan frame dan resolusi video standar hingga dan termasuk:

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

Jika implementasi perangkat Televisi dengan decoder hardware VP9 mendukung dekode VP9 dan profil decoding UHD, implementasi tersebut:

• [5.3.7/T-2-1] HARUS mendukung profil decoding UHD pada 60 frame per detik dengan profil 0 (kedalaman warna 8 bit).
• [5.3.7/T-SR1] SANGAT DIREKOMENDASIKAN untuk mendukung profil decoding 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 Volume Master sistem dan pelemahan volume output audio digital pada output yang didukung, kecuali untuk output passthrough audio terkompresi (jika tidak ada decoding audio yang dilakukan pada perangkat).

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

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

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

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

• [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 melakukan pramuat 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 memberikan implementasi lengkap android.webkit.Webview API.

Jika implementasi perangkat Android Television mendukung layar kunci,implementasi tersebut:

• [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 DIREKOMENDASIKAN 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 DIREKOMENDASIKAN untuk melakukan pramuat 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 bawaan) sebagaimana disediakan dalam project open source Talkback.

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

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

Implementasi perangkat televisi:

• [3.12/T-0-1] HARUS mendukung Framework Input TV.

2.3.4. Performa dan Kekuatan

• [8.1/T-0-1] Latensi frame yang konsisten. Latensi frame yang tidak konsisten atau penundaan untuk merender frame TIDAK BOLEH terjadi lebih dari 5 frame dalam satu detik, dan HARUS di bawah 1 frame dalam satu detik.
• [8.2/T-0-1] HARUS memastikan performa penulisan berurutan setidaknya 5 MB/dtk.
• [8.2/T-0-2] HARUS memastikan performa penulisan acak setidaknya 0,5 MB/dtk.
• [8.2/T-0-3] HARUS memastikan performa baca berurutan setidaknya 15 MB/dtk.
• [8.2/T-0-4] HARUS memastikan performa baca acak setidaknya 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 memberikan kemampuan pengguna untuk mengaktifkan dan menonaktifkan fitur penghemat baterai.

Jika implementasi perangkat Televisi tidak memiliki baterai, implementasi tersebut:

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

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

Implementasi perangkat televisi:

• [8.4/T-0-1] HARUS menyediakan profil daya per komponen yang menentukan nilai konsumsi saat ini untuk setiap komponen hardware dan perkiraan pengurasan baterai yang disebabkan oleh komponen dari waktu ke waktu, seperti yang didokumentasikan di situs Project Open Source Android.
• [8.4/T-0-2] HARUS melaporkan semua nilai konsumsi daya dalam miliampere jam (mAh).
• [8.4/T-0-3] HARUS melaporkan konsumsi daya CPU per UID setiap proses. Project Open Source Android memenuhi persyaratan melalui implementasi 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.
• [9.11/T-0-1] HARUS mencadangkan implementasi keystore dengan lingkungan eksekusi yang terisolasi.
• [9.11/T-0-2] HARUS memiliki implementasi algoritma kriptografi RSA, AES, ECDSA, dan HMAC serta fungsi hash kelompok MD5, SHA1, 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 mekanisme potensial yang digunakan kode kernel atau userspace untuk mengakses status internal lingkungan yang terisolasi, termasuk DMA. Project Open Source Android (AOSP) upstream memenuhi persyaratan ini dengan menggunakan implementasi Trusty, tetapi solusi berbasis ARM TrustZone lain atau implementasi aman yang ditinjau oleh pihak ketiga dari isolasi berbasis hypervisor yang tepat merupakan opsi alternatif.
• [9.11/T-0-3] HARUS melakukan autentikasi layar kunci di lingkungan eksekusi yang terisolasi dan hanya jika berhasil, izinkan kunci yang terikat autentikasi untuk digunakan. Kredensial layar kunci HARUS disimpan dengan cara yang hanya memungkinkan lingkungan eksekusi yang terisolasi untuk melakukan autentikasi layar kunci. Project Open Source Android upstream menyediakan Gatekeeper Hardware Abstraksi 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 yang aman dan penandatanganan dilakukan dalam hardware yang aman. Kunci penandatanganan pengesahan HARUS dibagikan ke seluruh perangkat dalam jumlah yang cukup besar untuk mencegah kunci digunakan sebagai ID perangkat. Salah satu cara untuk memenuhi persyaratan ini adalah dengan berbagi kunci pengesahan yang sama kecuali jika menghasilkan minimal 100.000 unit SKU tertentu. Jika lebih dari 100.000 unit SKU dihasilkan, kunci yang berbeda DAPAT digunakan untuk setiap 100.000 unit.

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

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

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

Jika implementasi perangkat TV menyertakan beberapa pengguna dan tidak mendeklarasikan tombol fitur android.hardware.telephony, implementasi tersebut:

• [9.5/T-2-1] HARUS mendukung profil yang dibatasi, yaitu 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 batasan yang lebih terperinci pada aplikasi yang tersedia di lingkungan tersebut.

Jika implementasi perangkat TV menyertakan beberapa pengguna dan mendeklarasikan tombol fitur android.hardware.telephony, implementasi tersebut:

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

Jika implementasi perangkat TV mendeklarasikan android.hardware.microphone, implementasi tersebut:

• [9.8.2/T-4-1] HARUS menampilkan indikator mikrofon saat aplikasi sedang mengakses data audio dari mikrofon, tetapi tidak saat mikrofon hanya diakses oleh HotworddetectionService, SOURCE_HOTWORD, ContentCaptureService, atau aplikasi yang memegang peran yang disebutkan di Pasal 9.1 Izin 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 TV mendeklarasikan android.hardware.camera.any, implementasi tersebut:

• [9.8.2/T-5-1] HARUS menampilkan indikator kamera saat aplikasi sedang mengakses data kamera live, tetapi tidak saat kamera hanya diakses oleh aplikasi yang memiliki peran yang disebutkan di Pasal 9.1 Izin 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 Opsi dan Developer Tools

Implementasi perangkat televisi:

• Perfetto
  • [6.1/T-0-1] HARUS mengekspos biner /system/bin/perfetto ke pengguna shell yang mematuhi cmdline 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.

2.4. Persyaratan Tontonan

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

Implementasi 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 dikenakan pada tubuh.

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

2.4.1. Hardware

Implementasi perangkat smartwatch:

• [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 bagi pengguna, dan fungsi Kembali, kecuali jika berada dalam UI_MODE_TYPE_WATCH.

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

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

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

• [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 frekuensi pseudorange dan pseudorange GNSS, yang, dalam kondisi langit terbuka setelah menentukan lokasi, sementara tetap atau bergerak dengan akselerasi kurang dari 0,2 meter per detik kuadrat , cukup untuk menghitung posisi dalam jarak 20 meter, dan kecepatan dalam 0,2 meter per detik, minimal 95%

Jika implementasi perangkat Smartwatch menyertakan giroskop 3 sumbu, implementasi tersebut:

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

Implementasi perangkat smartwatch:

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

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

• [7.6.1/W-0-2] HARUS memiliki memori minimal 416 MB 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

Implementasi perangkat smartwatch:

• [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 melakukan pramuat 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.

Implementasi perangkat smartwatch:

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

Implementasi perangkat smartwatch 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 DIREKOMENDASIKAN untuk melakukan pramuat layanan aksesibilitas di perangkat yang sebanding dengan atau melebihi fungsi Tombol Akses dan TalkBack (untuk bahasa yang didukung oleh mesin Text-to-speech bawaan) seperti yang disediakan dalam project open source Talkback.

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

• [3.11/W-SR-1] SANGAT DIREKOMENDASIKAN 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 Kekuatan

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

• [8.3/W-SR-1] SANGAT DIREKOMENDASIKAN untuk memberikan kemampuan pengguna kepada pengguna untuk menampilkan semua aplikasi yang dikecualikan dari mode hemat daya Aplikasi Standby dan Istirahatkan.
• [8.3/W-SR-2] SANGAT DIREKOMENDASIKAN untuk memberikan kemampuan pengguna pada pengaktifan dan penonaktifan fitur penghemat baterai.

Implementasi perangkat smartwatch:

• [8.4/W-0-1] HARUS menyediakan profil daya per komponen yang menentukan nilai konsumsi saat ini untuk setiap komponen hardware dan perkiraan pengurasan baterai yang disebabkan oleh komponen dari waktu ke waktu, seperti yang didokumentasikan di situs Project Open Source Android.
• [8.4/W-0-2] HARUS melaporkan semua nilai konsumsi daya dalam miliampere jam (mAh).
• [8.4/W-0-3] HARUS melaporkan konsumsi daya CPU per UID setiap proses. Project Open Source Android memenuhi persyaratan melalui implementasi 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

Implementasi perangkat smartwatch:

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

Jika implementasi perangkat Smartwatch menyertakan beberapa pengguna dan tidak mendeklarasikan tombol fitur android.hardware.telephony, implementasi tersebut:

• [9.5/W-1-1] HARUS mendukung profil yang dibatasi, yaitu 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 batasan yang lebih terperinci pada aplikasi yang tersedia di lingkungan tersebut.

Jika implementasi perangkat Smartwatch menyertakan beberapa pengguna dan mendeklarasikan tombol fitur android.hardware.telephony, implementasi tersebut:

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

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 Automotive jika mendeklarasikan fitur android.hardware.type.automotive atau memenuhi semua kriteria berikut.

• Disematkan sebagai bagian dari, atau dapat dicocokkan dengan, kendaraan otomotif.
• Menggunakan layar di baris kursi pengemudi sebagai tampilan utama.

Persyaratan tambahan di bagian selanjutnya ini khusus untuk implementasi perangkat Android Automotive.

2.5.1. Hardware

Implementasi perangkat otomotif:

• [7.1.1.1/A-0-1] HARUS memiliki layar minimal 6 inci dalam ukuran diagonal fisik.
• [7.1.1.1/A-0-2] HARUS memiliki tata letak ukuran layar minimal 750 dp x 480 dp.
• [7.2.3/A-0-1] HARUS menyediakan fungsi Beranda dan DAPAT menyediakan fungsi Kembali dan Terbaru.
• [7.2.3/A-0-2] HARUS mengirim peristiwa tekan lama dan normal dari fungsi Kembali (KEYCODE_BACK) ke aplikasi latar depan.
• [7.3/A-0-1] HARUS mengimplementasikan dan melaporkan GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED dan PARKING_BRAKE_ON.
• [7.3/A-0-2] Nilai tanda NIGHT_MODE HARUS konsisten dengan mode siang/malam dasbor dan HARUS didasarkan pada input sensor cahaya sekitar. Sensor cahaya sekitar yang mendasari MUNGKIN sama dengan Photometer.
• [7.3/A-0-3] HARUS memberikan kolom info tambahan sensor TYPE_SENSOR_PLACEMENT sebagai bagian dari SensorAdditionalInfo untuk setiap sensor yang disediakan.
• [7.3/A-SR1] Lokasi ini mungkin mematikan dengan menggabungkan GPS/GNSS dengan sensor tambahan. Jika Lokasi tidak diperhitungkan, SANGAT DIREKOMENDASIKAN untuk menerapkan dan melaporkan jenis Sensor dan/atau ID Properti Kendaraan yang sesuai yang digunakan.

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

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

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

• [7.3/A-SR-2] SANGAT_DIREKOMENDASIKAN untuk mengimplementasikan dan melaporkan sensor TYPE_HEADING.

Jika implementasi perangkat Automotive mendukung OpenGL ES 3.1, implementasi tersebut:

• [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 loader Vulkan dan mengekspor semua simbol.

Jika implementasi perangkat Automotive menyertakan akselerometer, implementasi tersebut:

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

Jika implementasi perangkat menyertakan akselerometer 3 sumbu, implementasi tersebut:

• [7.3.1/A-SR-1] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan sensor gabungan untuk akselerometer sumbu terbatas.

Jika implementasi perangkat Automotive menyertakan akselerometer dengan kurang dari 3 sumbu, implementasi tersebut:

• [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 Automotive menyertakan giroskop, implementasi tersebut:

• [7.3.4/A-2-1] HARUS dapat melaporkan peristiwa hingga frekuensi setidaknya 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 DIREKOMENDASIKAN untuk mengonfigurasi rentang pengukuran giroskop ke +/-250 dp untuk memaksimalkan resolusi.

Jika implementasi perangkat Automotive menyertakan giroskop 3 sumbu, implementasi tersebut:

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

Jika implementasi perangkat Automotive menyertakan giroskop dengan kurang dari 3 sumbu, implementasi tersebut:

• [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 penerapan perangkat Automotive menyertakan penerima GPS/GNSS, tetapi tidak menyertakan konektivitas data berbasis jaringan seluler, penerapan tersebut:

• [7.3.3/A-3-1] HARUS menentukan lokasi saat pertama kali penerima GPS/GNSS diaktifkan atau setelah 4 hari lebih dalam 60 detik.
• [7.3.3/A-3-2] HARUS memenuhi kriteria waktu 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 kalinya atau setelah 4 hari lebih). Persyaratan 7.3.3/C-1-2 biasanya dipenuhi di kendaraan tanpa konektivitas data berbasis jaringan seluler, dengan menggunakan prediksi orbit GNSS yang dihitung pada penerima, atau menggunakan lokasi kendaraan terakhir yang diketahui bersama dengan kemampuan untuk mematikan reckon setidaknya selama 60 detik dengan akurasi posisi yang memuaskan 7.3.3/C-1-3, atau kombinasi keduanya.

Jika implementasi perangkat otomotif menyertakan sensor TYPE_HEADING, implementasi tersebut:

• [7.3.4/A-4-3] HARUS dapat melaporkan peristiwa hingga frekuensi setidaknya 1 Hz.
• [7.3.4/A-SR-3] STRONGLY_RECOMMENDED untuk melaporkan peristiwa hingga frekuensi setidaknya 10 Hz.
• HARUS merujuk ke utara sejati.
• SEHARUSNYA tersedia meskipun kendaraan berhenti digunakan.
• HARUS memiliki resolusi minimal 1 derajat.

Implementasi perangkat otomotif:

• [7.4.3/A-0-1] HARUS mendukung Bluetooth dan SEHARUS mendukung Bluetooth LE.
• [7.4.3/A-0-2] Implementasi Android Automotive HARUS mendukung profil Bluetooth berikut:
  • Panggilan telepon melalui Profil Hands-Free (HFP).
  • Pemutaran media melalui Profil Distribusi Audio (A2DP).
  • Kontrol pemutaran media atas Profil Remote Control (AVRCP).
  • Berbagi kontak menggunakan Profil Akses Buku Telepon (PBAP).

• [7.4.3/A-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung Message Access Profile (MAP).

• [7.4.5/A] SEHARUSNYA menyertakan dukungan untuk konektivitas data berbasis jaringan seluler.

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

Implementasi perangkat otomotif:

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

• [7.6.1/A] HARUS memformat partisi data agar menawarkan performa dan ketahanan yang lebih baik pada penyimpanan flash, misalnya menggunakan sistem file f2fs.

Jika implementasi perangkat Automotive menyediakan penyimpanan eksternal bersama melalui sebagian penyimpanan internal tidak dapat dilepas, implementasi tersebut:

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

Jika implementasi perangkat Automotive adalah 64-bit:

• [7.6.1/A-2-1] Memori yang tersedia untuk kernel dan userspace HARUS berukuran minimal 816 MB jika salah satu kepadatan berikut digunakan:

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

• [7.6.1/A-2-2] Memori yang tersedia untuk kernel dan userspace HARUS berukuran minimal 944 MB jika salah satu dari kepadatan berikut digunakan:

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

• [7.6.1/A-2-3] Memori yang tersedia untuk kernel dan userspace HARUS berukuran minimal 1.280 MB jika salah satu kepadatan berikut digunakan:

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

• [7.6.1/A-2-4] Memori yang tersedia untuk kernel dan userspace HARUS berukuran minimal 1824 MB jika salah satu kepadatan berikut digunakan:

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

Perlu diperhatikan bahwa "memori yang tersedia untuk kernel dan userspace" di atas mengacu pada ruang memori yang disediakan selain memori yang telah dikhususkan untuk komponen hardware seperti radio, video, dan sebagainya yang tidak berada di bawah kontrol kernel pada implementasi perangkat.

Implementasi perangkat otomotif:

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

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 mendeklarasikan android.hardware.audio.output.

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 (Peningkatan AAC penundaan rendah)

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

• [5,2/A-0-1] AVC H.264
• [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] AVC H.264
• [5,3/A-0-2] MPEG-4 SP
• [5,3/A-0-3] VP8
• [5,3/A-0-4] VP9

Implementasi perangkat otomotif SANGAT DIREKOMENDASIKAN untuk mendukung dekode video berikut:

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

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 Automotive menyediakan API eksklusif menggunakan android.car.CarPropertyManager dengan android.car.VehiclePropertyIds, implementasi tersebut:

• [3/A-1-1] TIDAK BOLEH memberikan hak istimewa khusus untuk 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 melakukan pramuat 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/A-0-1] HARUS memberikan implementasi lengkap android.webkit.Webview API.

• [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 Bantuan.

Jika implementasi perangkat Automotive menyertakan tombol push-to-talk, implementasi tersebut:

• [3.8.4/A-1-1] HARUS menekan singkat tombol push-to-talk 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 MUTE untuk tindakan notifikasi sebagai pengganti tindakan yang disediakan melalui Notification.Builder.addAction()
• [3.8.3.1/A] SEHARUSNYA membatasi penggunaan tugas pengelolaan lengkap seperti kontrol per-notifikasi saluran. MUNGKIN menggunakan kemampuan UI per aplikasi untuk mengurangi kontrol.

Jika implementasi perangkat Automotive mendukung properti HAL Pengguna, implementasi tersebut:

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

Implementasi perangkat otomotif:

• [3.14/A-0-1] HARUS menyertakan framework UI untuk mendukung aplikasi pihak ketiga yang menggunakan API media seperti yang dijelaskan di pasal 3.14.
• [3.14/A-0-2] HARUS memungkinkan pengguna berinteraksi secara aman dengan Aplikasi Media saat mengemudi.
• [3.14/A-0-3] HARUS mendukung tindakan Intent implisit CAR_INTENT_ACTION_MEDIA_TEMPLATE dengan tambahan CAR_EXTRA_MEDIA_PACKAGE.
• [3.14/A-0-4] HARUS menyediakan affordance untuk membuka aktivitas preferensi Aplikasi Media, tetapi HARUS mengaktifkannya hanya jika Pembatasan UX Mobil tidak berlaku.
• [3.14/A-0-5] HARUS menampilkan pesan error yang ditetapkan oleh Aplikasi Media, dan HARUS mendukung tambahan opsional ERROR_RESOLUTION_ACTION_LABEL dan ERROR_RESOLUTION_ACTION_INTENT.
• [3.14/A-0-6] HARUS mendukung kemampuan penelusuran dalam aplikasi untuk aplikasi yang mendukung penelusuran.
• [3.14/A-0-7] HARUS mematuhi definisi CONTENT_STYLE_BROWSABLE_HINT dan CONTENT_STYLE_PLAYABLE_HINT saat menampilkan hierarki MediaBrowser.

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

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

Implementasi perangkat otomotif:

• [3.8/A] DAPAT membatasi permintaan aplikasi untuk memasuki mode layar penuh seperti yang dijelaskan dalam immersive documentation.
• [3.8/A] MUNGKIN menjaga status bar dan menu navigasi tetap terlihat setiap saat.
• [3.8/A] MUNGKIN membatasi permintaan aplikasi untuk mengubah warna di balik elemen UI sistem, untuk memastikan elemen tersebut terlihat jelas setiap saat.

2.5.4. Performa dan Kekuatan

Implementasi perangkat otomotif:

• [8.2/A-0-1] HARUS melaporkan jumlah byte yang dibaca dan ditulis ke penyimpanan non-volatil per UID setiap proses sehingga statistiknya tersedia bagi developer melalui System API android.car.storagemonitoring.CarStorageMonitoringManager. Project Open Source Android memenuhi persyaratan melalui modul kernel uid_sys_stats.
• [8.3/A-1-3] HARUS mendukung Mode Garasi.
• [8.3/A] SEHARUSNYA berada dalam Mode Garasi selama minimal 15 menit setelah setiap berkendara, kecuali:
  • Baterai habis.
  • Tidak ada tugas tidak ada aktivitas yang dijadwalkan.
  • Pengemudi keluar dari Mode Garasi.
• [8.4/A-0-1] HARUS menyediakan profil daya per komponen yang menentukan nilai konsumsi saat ini untuk setiap komponen hardware dan perkiraan pengurasan baterai yang disebabkan oleh komponen dari waktu ke waktu, seperti yang didokumentasikan di situs Project Open Source Android.
• [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 implementasi 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 Automotive mendukung beberapa pengguna, implementasi perangkat tersebut:

• [9.5/A-1-1] TIDAK BOLEH mengizinkan pengguna berinteraksi dengan atau beralih ke Pengguna Sistem Headless, kecuali untuk penyediaan 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 meskipun jumlah maksimum Pengguna di perangkat telah tercapai.

Jika implementasi perangkat Automotive mendeklarasikan android.hardware.camera.any, implementasi perangkat Automotive:

• [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 seperti yang ditentukan dipanggil di Pasal 9.1 Izin dengan ID CDD [C-4-X][C-3-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.

Implementasi perangkat otomotif:

• [9/A-0-1] HARUS mendeklarasikan fitur android.hardware.security.model.compatible.
• [9.11/A-0-1] HARUS mencadangkan implementasi keystore dengan lingkungan eksekusi yang terisolasi.
• [9.11/A-0-2] HARUS memiliki implementasi algoritma kriptografi RSA, AES, ECDSA, dan HMAC serta fungsi hash kelompok MD5, SHA1, 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 mekanisme potensial yang digunakan kode kernel atau userspace untuk mengakses status internal lingkungan yang terisolasi, termasuk DMA. Project Open Source Android (AOSP) upstream memenuhi persyaratan ini dengan menggunakan implementasi Trusty, tetapi solusi berbasis ARM TrustZone lain atau implementasi aman yang ditinjau oleh pihak ketiga dari isolasi berbasis hypervisor yang tepat merupakan opsi alternatif.
• [9.11/A-0-3] HARUS melakukan autentikasi layar kunci di lingkungan eksekusi yang terisolasi dan hanya jika berhasil, izinkan kunci yang terikat autentikasi untuk digunakan. Kredensial layar kunci HARUS disimpan dengan cara yang hanya memungkinkan lingkungan eksekusi yang terisolasi untuk melakukan autentikasi layar kunci. Project Open Source Android upstream menyediakan Gatekeeper Hardware Abstraksi Layer (HAL) 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 dalam hardware yang aman. Kunci penandatanganan pengesahan HARUS dibagikan ke seluruh perangkat dalam jumlah yang cukup besar untuk mencegah kunci digunakan sebagai ID perangkat. Salah satu cara untuk memenuhi persyaratan ini adalah dengan berbagi kunci pengesahan yang sama kecuali jika menghasilkan minimal 100.000 unit SKU tertentu. Jika lebih dari 100.000 unit SKU dihasilkan, kunci yang berbeda DAPAT digunakan untuk setiap 100.000 unit.

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

Implementasi perangkat otomotif:

• [9.14/A-0-1] HARUS melakukan gatekeep pesan dari subsistem kendaraan framework Android, misalnya, mengizinkan jenis pesan dan sumber pesan yang diizinkan.
• [9.14/A-0-2] HARUS mengawasi terhadap serangan penolakan layanan dari framework Android atau aplikasi pihak ketiga. Tindakan ini melindungi jaringan kendaraan dari software berbahaya yang membanjiri jaringan kendaraan, yang dapat menyebabkan kegagalan fungsi subsistem kendaraan.

2.5.6. Kompatibilitas Opsi dan Developer Tools

Implementasi perangkat otomotif:

• Perfetto
  • [6.1/A-0-1] HARUS mengekspos biner /system/bin/perfetto ke pengguna shell yang mematuhi cmdline 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.

2.6. Persyaratan Tablet

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

• Digunakan dengan menggenggam di kedua tangan.
• Tidak memiliki konfigurasi laptop konvensional atau konvertibel.
• Implementasi keyboard fisik yang digunakan dengan perangkat terhubung melalui koneksi standar (mis. USB, Bluetooth).

• Memiliki sumber listrik yang menyediakan mobilitas, seperti baterai.

• Memiliki ukuran tampilan layar yang lebih besar dari 7 inci dan kurang dari 18", yang diukur secara diagonal.

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

2.6.1. Hardware

Giroskop

Jika implementasi perangkat Tablet menyertakan giroskop 3 sumbu, penerapan tersebut:

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

Memori dan Penyimpanan Minimum (Bagian 7.6.1)

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

Mode periferal USB (Bagian 7.7.1)

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

• [7.7.1/Tab] MUNGKIN menerapkan Android Open Accessory API (AOA).

Mode Virtual Reality (Bagian 7.9.1)

Performa Tinggi Virtual Reality (Bagian 7.9.2)

Persyaratan virtual reality tidak berlaku untuk tablet.

2.6.2. Model Keamanan

Kunci dan Kredensial (Bagian 9.11)

Lihat Bagian [9.11].

Jika implementasi perangkat Tablet menyertakan beberapa pengguna dan tidak mendeklarasikan tombol fitur android.hardware.telephony, implementasi tersebut:

• [9.5/T-1-1] HARUS mendukung profil yang dibatasi, yaitu 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 batasan yang lebih terperinci pada aplikasi yang tersedia di lingkungan tersebut.

Jika implementasi perangkat Tablet menyertakan beberapa pengguna dan mendeklarasikan tombol fitur android.hardware.telephony, implementasi tersebut:

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

2.6.2. Software

• [3.2.3.1/Tab-0-1] HARUS melakukan pramuat 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 kendaraan utama untuk aplikasi Android. Android application programming interface (API) adalah serangkaian antarmuka platform Android yang diekspos ke aplikasi yang berjalan di lingkungan runtime terkelola.

Implementasi perangkat:

• [C-0-1] HARUS memberikan penerapan lengkap, termasuk semua perilaku yang didokumentasikan, dari API terdokumentasi apa pun yang diekspos oleh Android SDK atau API apa pun yang dilengkapi dengan penanda “@SystemApi” di kode sumber Android upstream.

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

• [C-0-3] TIDAK BOLEH menghilangkan API terkelola apa pun, mengubah antarmuka atau tanda tangan API, menyimpang dari perilaku yang didokumentasikan, atau menyertakan tanpa pengoperasian, kecuali jika secara khusus diizinkan oleh Compatibility Definition ini.

• [C-0-4] HARUS tetap mempertahankan API dan berperilaku dengan cara yang wajar, meskipun beberapa fitur hardware yang menyertakan API 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 didefinisikan sebagai metode dan kolom dalam paket bahasa Java yang ada di classpath booting di AOSP, dan yang tidak menjadi bagian dari SDK publik. Ini termasuk API yang didekorasi dengan anotasi @hide, tetapi tidak dengan @SystemAPI, seperti yang dijelaskan dalam dokumen SDK serta anggota class pribadi dan paket pribadi.

• [C-0-6] HARUS mengirim dengan setiap antarmuka non-SDK pada daftar terbatas yang sama seperti yang disediakan melalui flag daftar sementara dan daftar tolak di jalur prebuilts/runtime/appcompat/hiddenapi-flags.csv untuk cabang API level 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 dalam APK apa pun, menggunakan kunci publik yang ada yang ada di AOSP.

  Namun demikian:

  • MUNGKIN, jika API tersembunyi tidak ada atau diterapkan secara berbeda pada implementasi perangkat, pindahkan API tersembunyi ke dalam daftar tolak atau hapus dari semua daftar yang dibatasi.
  • MUNGKIN, jika API tersembunyi belum ada di AOSP, tambahkan API tersembunyi tersebut ke salah satu daftar yang dibatasi.

3.1.1. Ekstensi Android

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

Implementasi perangkat Android:

• [C-0-1] HARUS melakukan pramuat 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 API level 24 HARUS menyertakan setidaknya versi 1.

• [C-0-2] HARUS menampilkan nomor versi ekstensi yang valid saja 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 yang didukung, dengan mengikuti persyaratan di bagian 3.1.

3.1.2. Library Android

Karena penghentian klien HTTP Apache, penerapan 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 subclass aplikasi hanya jika aplikasi memenuhi salah satu kondisi berikut:
  • Menargetkan API level 28 atau lebih rendah.
  • Mendeklarasikan dalam manifesnya bahwa library tersebut memerlukan library dengan menyetel atribut android:name dari <uses-library> ke org.apache.http.legacy.

Implementasi AOSP memenuhi persyaratan ini.

3.2. Kompatibilitas Soft API

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

3.2.1. Izin

• [C-0-1] Pengimplementasikan perangkat HARUS mendukung dan menerapkan semua konstanta izin seperti yang didokumentasikan oleh halaman Referensi izin. Perlu diperhatikan bahwa bagian 9 mencantumkan persyaratan tambahan yang terkait dengan model keamanan Android.

3.2.2 Parameter Build

Android API menyertakan sejumlah konstanta di class android.os.Build yang ditujukan untuk menjelaskan perangkat saat ini.

• [C-0-1] Untuk memberikan nilai yang konsisten dan bermakna di seluruh implementasi perangkat, tabel di bawah ini menyertakan batasan tambahan pada format nilai ini yang HARUS sesuai dengan implementasi perangkat.

Parameter	Detail
VERSION.RELEASE	Versi sistem Android yang saat ini dijalankan, dalam format yang dapat dibaca manusia. Kolom ini HARUS memiliki salah satu nilai string yang ditentukan dalam String Versi yang Diizinkan untuk Android 14.
VERSION.SDK	Versi sistem Android yang saat ini dijalankan, dalam format yang dapat diakses oleh kode aplikasi pihak ketiga. Untuk Android 14, kolom ini HARUS memiliki nilai bilangan bulat 14_INT.
VERSION.SDK_INT	Versi sistem Android yang saat ini dijalankan, dalam format yang dapat diakses oleh kode aplikasi pihak ketiga. Untuk Android 14, kolom ini HARUS memiliki nilai bilangan bulat 14_INT.
VERSION.INCREMENTAL	Nilai yang dipilih oleh pengimplementasi perangkat yang menentukan build spesifik dari sistem Android yang saat ini dijalankan, dalam format yang dapat dibaca manusia. Nilai ini TIDAK BOLEH digunakan kembali untuk build berbeda yang disediakan bagi pengguna akhir. Penggunaan standar kolom ini adalah untuk menunjukkan nomor build atau ID perubahan kontrol sumber yang digunakan untuk membuat build. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit yang dapat dicetak dan cocok dengan ekspresi reguler “^[^ :\/~]+$”.
PAPAN	Nilai yang dipilih oleh pengimplementasi perangkat yang mengidentifikasi hardware internal tertentu yang digunakan oleh perangkat, dalam format yang dapat dibaca manusia. Kolom ini mungkin digunakan untuk menunjukkan revisi khusus board yang menjalankan perangkat. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7 bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9_-]+$”.
BRAND	Nilai yang mencerminkan nama merek yang terkait dengan perangkat sebagaimana diketahui oleh pengguna akhir. HARUS dalam format yang dapat dibaca manusia dan HARUS mewakili produsen perangkat atau merek perusahaan tempat perangkat dipasarkan. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7 bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9_-]+$”.
DIDUKUNG_ABI	Nama kumpulan petunjuk (jenis CPU + konvensi ABI) kode native. Lihat bagian 3.3. Kompatibilitas Native API.
SUPPORTED_32_BIT_ABIS	Nama kumpulan petunjuk (jenis CPU + konvensi ABI) kode native. Lihat bagian 3.3. Kompatibilitas Native API.
SUPPORTED_64_BIT_ABIS	Nama kumpulan petunjuk kedua (jenis CPU + konvensi ABI) kode native. Lihat bagian 3.3. Kompatibilitas Native API.
ABI_CPU	Nama kumpulan petunjuk (jenis CPU + konvensi ABI) kode native. Lihat bagian 3.3. Kompatibilitas Native API.
CPU_ABI2	Nama kumpulan petunjuk kedua (jenis CPU + konvensi ABI) kode native. Lihat bagian 3.3. Kompatibilitas Native API.
PERANGKAT	Nilai yang dipilih oleh pengimplementasi perangkat yang berisi nama pengembangan atau nama kode yang mengidentifikasi konfigurasi fitur hardware dan desain industri perangkat. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9_-]+$”. Nama perangkat ini TIDAK BOLEH berubah selama masa pakai produk.
CETAK JARI	String yang mengidentifikasi build ini secara unik. harus dapat dibaca oleh manusia. URL HARUS mengikuti {i>template<i} ini: $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Contoh: acme/myproduct/ mydevice:14/LMYXX/3359:userdebug/test-keys Sidik jari TIDAK BOLEH berisi karakter spasi kosong. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit.
PERANGKAT KERAS	Nama perangkat keras (dari baris perintah {i>kernel<i} atau {i>/proc<i}. Entri SEHARUSNYA dapat dibaca manusia. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9_-]+$”.
HOST	String yang secara unik mengidentifikasi host tempat build dibuat, dalam format yang dapat dibaca manusia. Tidak ada persyaratan tentang format spesifik kolom ini, kecuali bahwa format tersebut TIDAK BOLEH berupa null atau string kosong ("").
ID	ID yang dipilih oleh pengimplementasikan perangkat untuk merujuk pada rilis tertentu, dalam format yang dapat dibaca manusia. Kolom ini boleh sama dengan android.os.Build.VERSION.INCREMENTAL, tetapi SEHARUSNYA menjadi nilai yang cukup berarti bagi pengguna akhir agar dapat membedakan berbagai build software. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7 bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9._-]+$”.
Produsen	Nama dagang Produsen Peralatan Asli (OEM) produk. Tidak ada persyaratan tentang format tertentu kolom ini, kecuali bahwa format ini TIDAK BOLEH berupa null atau string kosong (""). Kolom ini TIDAK BOLEH berubah selama masa pakai produk.
SOC_MANUFACTURER	Perdagangan nama produsen sistem utama pada chip (SOC) yang digunakan dalam produk. Perangkat dengan produsen SOC yang sama harus menggunakan nilai konstanta yang sama. Mintalah konstanta yang benar kepada produsen SOC untuk digunakan. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit, HARUS cocok dengan ekspresi reguler “^([0-9A-Za-z ]+)”, TIDAK BOLEH diawali atau diakhiri dengan spasi kosong, dan TIDAK BOLEH sama dengan “unknown”. Kolom ini TIDAK BOLEH berubah selama masa pakai produk.
SOC_MODEL	Nama model sistem utama pada chip (SOC) yang digunakan dalam produk. Perangkat dengan model SOC yang sama harus menggunakan nilai konstanta yang sama. Mintalah konstanta yang benar kepada produsen SOC untuk digunakan. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7 bit dan cocok dengan ekspresi reguler “^([0-9A-Za-z ._/+-]+)$”, TIDAK BOLEH diawali atau diakhiri dengan spasi kosong, dan TIDAK BOLEH sama dengan “unknown”. Kolom ini TIDAK BOLEH berubah selama masa pakai produk.
MODEL	Nilai yang dipilih oleh pengimplementasi perangkat yang berisi nama perangkat seperti yang diketahui oleh pengguna akhir. Nama ini HARUS sama dengan nama perangkat dipasarkan dan dijual kepada pengguna akhir. Tidak ada persyaratan tentang format tertentu kolom ini, kecuali bahwa format tersebut TIDAK BOLEH berupa null atau string kosong (""). Kolom ini TIDAK BOLEH berubah selama masa pakai produk.
PRODUK	Nilai yang dipilih oleh pengimplementasi perangkat yang berisi nama pengembangan atau nama kode produk tertentu (SKU) yang HARUS unik dalam brand yang sama. HARUS dapat dibaca manusia, tetapi tidak dimaksudkan untuk dilihat oleh pengguna akhir. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9_-]+$”. Nama produk ini TIDAK BOLEH berubah selama masa pakai produk.
SKU_ODM	Nilai opsional yang dipilih oleh pengimplementasi perangkat yang berisi SKU (Unit Penyimpanan Persediaan) yang digunakan untuk melacak konfigurasi tertentu dari perangkat, misalnya, periferal apa pun yang disertakan dengan perangkat saat dijual. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “[0-9A-Za-z.,_-])"
SERI	HARUS menampilkan "UNKNOWN".
TAG	Daftar tag yang dipisahkan koma yang dipilih oleh pengimplementasi perangkat yang akan lebih membedakan build. Tag HARUS dapat dienkode sebagai ASCII 7 bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9._-]+” dan HARUS memiliki salah satu nilai yang sesuai dengan tiga konfigurasi penandatanganan platform Android standar: kunci rilis, tombol dev, dan kunci pengujian.
WAKTU	Nilai yang mewakili stempel waktu saat build terjadi.
TYPE	Nilai yang dipilih oleh pengimplementasi perangkat yang menentukan konfigurasi runtime build. Kolom ini HARUS memiliki salah satu nilai yang sesuai dengan tiga konfigurasi runtime Android umum: user, userdebug, atau eng.
PENGGUNA	Nama atau ID pengguna pengguna (atau pengguna otomatis) yang membuat build. Tidak ada persyaratan tentang format spesifik kolom ini, kecuali bahwa format tersebut TIDAK BOLEH berupa null atau string kosong ("").
PATCH_KEAMANAN	Nilai yang menunjukkan level patch keamanan build. Pernyataan ini HARUS menunjukkan bahwa build tersebut tidak rentan terhadap masalah apa pun yang dijelaskan melalui Buletin Keamanan Publik Android yang ditetapkan. Nilai ini HARUS dalam format [YYYY-MM-DD], yang cocok dengan string yang ditentukan dan didokumentasikan dalam Android Public Security Buletin atau dalam Android Security Advisory, misalnya "2015-11-01".
OS_BASIS	Nilai yang mewakili parameter FINGERPRINT build yang identik dengan build ini, kecuali untuk patch yang disediakan dalam Buletin Keamanan Publik Android. Aplikasi HARUS melaporkan nilai yang benar dan jika build tersebut tidak ada, laporkan string kosong ("").
BOOTLOADER	Nilai yang dipilih oleh pengimplementasi perangkat yang mengidentifikasi versi bootloader internal tertentu yang digunakan pada perangkat, dalam format yang dapat dibaca manusia. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7 bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9._-]+$”.
getRadioVersion()	HARUS (menjadi atau menampilkan) nilai yang dipilih oleh pengimplementasi perangkat yang mengidentifikasi versi radio/modem internal spesifik yang digunakan di perangkat, dalam format yang dapat dibaca manusia. Jika perangkat tidak memiliki radio/modem internal, perangkat HARUS menampilkan NULL. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9._-,]+$”.
getSerial()	HARUS (atau menampilkan) nomor seri hardware, yang HARUS tersedia dan unik di seluruh perangkat dengan MODEL dan MANUFACTURER yang sama. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7 bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9]+$”.

3.2.3 Kompatibilitas Intent

3.2.3.1 Intent Aplikasi Umum

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

Implementasi perangkat:

• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk melakukan pramuat 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 menyediakan fulfillment, yaitu memenuhi harapan developer untuk intent aplikasi umum ini seperti yang dijelaskan dalam SDK.

Lihat Bagian 2 untuk intent aplikasi wajib untuk setiap jenis perangkat.

3.2.3.2 Resolusi Maksud

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

• [C-0-2] Pengimplementasikan perangkat TIDAK BOLEH memberikan hak istimewa khusus untuk penggunaan pola intent ini oleh aplikasi sistem, atau mencegah aplikasi pihak ketiga mengikat ke dan mengasumsikan kontrol atas pola tersebut. Larangan ini secara khusus mencakup, tetapi tidak terbatas pada, menonaktifkan antarmuka pengguna “Chooser” yang memungkinkan pengguna memilih di antara beberapa aplikasi yang semuanya menangani pola intent yang sama.

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

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

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

• [C-0-4] HARUS mencoba memvalidasi filter intent apa pun dengan melakukan langkah validasi yang ditentukan dalam spesifikasi Digital Asset Links seperti yang diterapkan oleh Pengelola Paket di Project Open Source Android upstream.
• [C-0-5] HARUS mencoba memvalidasi 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 URI berhasil diverifikasi, tetapi filter URI kandidat lainnya gagal verifikasi. Jika melakukan hal ini, implementasi perangkat HARUS menyediakan penggantian pola per URI yang sesuai pengguna di menu setelan.
• HARUS memberi pengguna kontrol Link Aplikasi per aplikasi di Setelan sebagai berikut:
  • [C-0-6] Pengguna HARUS dapat mengganti secara menyeluruh perilaku link aplikasi default agar aplikasi selalu terbuka, selalu bertanya, atau tidak pernah terbuka, yang harus diterapkan pada semua filter intent URI kandidat.
  • [C-0-7] Pengguna HARUS dapat melihat daftar filter intent URI kandidat.
  • Implementasi perangkat MUNGKIN memberi pengguna kemampuan untuk mengganti filter intent URI kandidat tertentu yang berhasil diverifikasi, berdasarkan filter per intent.
  • [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 verifikasi sementara yang lainnya bisa gagal.

3.2.3.3. Namespace Intent

• [C-0-1] Implementasi perangkat TIDAK BOLEH menyertakan komponen Android apa pun yang mengikuti pola intent siaran atau intent baru menggunakan ACTION, CATEGORY, atau string kunci lainnya di namespace android.* atau com.android.*.
• [C-0-2] Pengimplementasikan perangkat TIDAK BOLEH menyertakan komponen Android apa pun yang mengikuti pola intent siaran atau intent baru menggunakan ACTION, CATEGORY, atau string kunci lainnya dalam ruang paket milik organisasi lain.
• [C-0-3] Pengimplementasikan perangkat TIDAK BOLEH mengubah atau memperluas pola intent apa pun yang tercantum di bagian 3.2.3.1.
• Implementasi perangkat MUNGKIN menyertakan pola intent menggunakan namespace yang jelas dan terkait dengan organisasinya sendiri. Larangan ini mirip dengan yang ditetapkan untuk class bahasa Java di bagian 3.6.

3.2.3.4. Intent Siaran

Aplikasi pihak ketiga mengandalkan platform untuk menyiarkan intent tertentu guna memberi tahu tentang perubahan dalam 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. Perlu diperhatikan bahwa persyaratan ini tidak bertentangan dengan pasal 3.5 karena batasan untuk aplikasi latar belakang juga dijelaskan dalam dokumentasi SDK. Selain itu, intent siaran tertentu bergantung pada dukungan hardware, jika perangkat mendukung hardware yang diperlukan, intent tersebut HARUS menyiarkan intent dan memberikan perilaku yang 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 ini.

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

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

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

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

• [C-2-2] HARUS mematuhi intent 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 untuk panggilan darurat, yang akan menggunakan aplikasi Telepon bawaan.

• [C-2-3] HARUS mematuhi intent android.telecom.action.CHANGE_PHONE_ACCOUNTS untuk memberikan kemampuan pengguna untuk 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 memberikan kemampuan kepada 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 memberikan aktivitas untuk mengirim/menampilkan pesan SMS.

• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk memenuhi intent android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW & android.intent.action.DIAL dengan aplikasi telepon bawaan yang dapat menangani intent ini dan memberikan fulfillment seperti yang dijelaskan dalam SDK.

Jika implementasi perangkat melaporkan android.hardware.nfc.hce, implementasi 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 yang meminta pengguna mengubah layanan emulasi kartu default untuk kategori tertentu seperti yang dijelaskan dalam SDK.

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

• [C-4-1] HARUS mematuhi intent ini 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, implementasi tersebut:

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

Jika implementasi perangkat mendukung fitur DND, implementasi tersebut:

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

Jika implementasi perangkat memungkinkan 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 intent android.settings.INPUT_METHOD_SETTINGS.

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

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

Jika implementasi perangkat menyertakan dukungan untuk Wi-Fi Easy Connect dan menampilkan fungsi ke aplikasi pihak ketiga, implementasi 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, implementasi tersebut:

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

Jika implementasi perangkat tidak menyediakan mode penghemat data, implementasi tersebut:

• [C-11-1] HARUS memiliki aktivitas yang menangani intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, tetapi DAPAT menerapkannya sebagai tanpa pengoperasian.

Jika implementasi perangkat mendeklarasikan dukungan untuk kamera melalui android.hardware.camera.any, implementasi tersebut:

• [C-12-3] HARUS menangani dan HARUS 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, implementasi tersebut:

• [C-13-1] HARUS mematuhi intent android.app.action.ADD_DEVICE_ADMIN untuk memanggil UI guna mengarahkan pengguna dengan 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 menyediakan fulfillment untuk intent ini dalam hal yang dijelaskan. di sini.

Jika implementasi perangkat mendeklarasikan flag fitur android.software.autofill, implementasi tersebut:

• [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 untuk pengguna.

Jika implementasi perangkat menyertakan aplikasi bawaan atau ingin mengizinkan aplikasi pihak ketiga mengakses statistik penggunaan, implementasi tersebut:

• [C-SR-2] SANGAT DIREKOMENDASIKAN 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 untuk melarang aplikasi apa pun, termasuk aplikasi yang sudah diinstal sebelumnya, mengakses statistik penggunaan, aplikasi tersebut:

• [C-15-1] Masih harus memiliki aktivitas yang menangani pola intent android.settings.ACTION_USAGE_ACCESS_SETTINGS, tetapi HARUS menerapkannya sebagai tanpa pengoperasian, yaitu memiliki perilaku yang setara seperti saat pengguna ditolak untuk mendapatkan akses.

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

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

Jika implementasi perangkat mendukung VoiceInteractionService dan memiliki lebih dari satu aplikasi yang menggunakan API ini yang diinstal dalam satu waktu, implementasi tersebut:

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

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

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

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

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

3.2.4 Aktivitas di beberapa tampilan sekunder/beberapa tampilan

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

• [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 layar utama.
• [C-1-3] HARUS menempatkan aktivitas baru di tampilan yang sama dengan aktivitas yang meluncurkannya, saat aktivitas baru diluncurkan tanpa menentukan tampilan target melalui ActivityOptions.setLaunchDisplayId() API.
• [C-1-4] HARUS menghancurkan semua aktivitas, jika tampilan dengan flag 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 Activity#setShowWhenLocked() API.
• HARUS memiliki android.content.res.Configuration yang sesuai dengan tampilan tersebut agar dapat ditampilkan, beroperasi dengan benar, dan mempertahankan kompatibilitas jika suatu aktivitas diluncurkan di tampilan sekunder.

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

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

3.3. Kompatibilitas Native API

Kompatibilitas kode native sulit dilakukan. Karena alasan ini, implementasi perangkat adalah:

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

3.3.1 Antarmuka Biner Aplikasi

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

Implementasi perangkat:

• [C-0-1] HARUS kompatibel dengan satu atau beberapa ABI Android NDK yang telah ditetapkan.
• [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 secara akurat melaporkan Antarmuka Biner Aplikasi native (ABI) yang didukung perangkat, melalui parameter android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS, dan android.os.Build.SUPPORTED_64_BIT_ABIS, masing-masing daftar ABI yang dipisahkan koma yang diurutkan dari yang paling banyak ke yang paling tidak disukai.

• [C-0-6] HARUS melaporkan, melalui parameter di atas, subset dari daftar ABI berikut dan TIDAK BOLEH melaporkan ABI yang tidak ada dalam daftar.

  • armeabi (tidak lagi didukung sebagai target oleh NDK)
  • armeabi-v7a
  • arm64-v8a
  • x86
  • x86-64

• [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 sebagaimana dijelaskan dalam Pasal 5.9)
  • libandroid.so (dukungan aktivitas Android native)
  • libc (library C)
  • libcamera2ndk.so
  • libdl (penaut dinamis)
  • libEGL.so (pengelolaan platform OpenGL native)
  • libGLESv1_CM.so (OpenGL ES 1.x)
  • libGLESv2.so (OpenGL ES 2.0)
  • libGLESv3.so (OpenGL ES 3.x)
  • libicui18n.so
  • libicuuc.so
  • {i>libjnigraphics.so<i}
  • liblog (logging Android)
  • libmediandk.so (dukungan API media native)
  • libm (perpustakaan matematika)
  • libneuralnetworks.so (Neural Networks API)
  • libOpenMAXAL.so (dukungan OpenMAX AL 1.0.1)
  • libOpenSLES.so (Dukungan audio OpenSL ES 1.0.1)
  • libRS.so
  • mdpi++ (Dukungan minimal untuk C++)
  • libvulkan.so (Vulkan)
  • libz (Kompresi zlib)
  • Antarmuka JNI

• [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 dalam AOSP sebagai library sistem, untuk aplikasi pihak ketiga yang menargetkan API level 24 atau yang lebih tinggi, jika aplikasi tersebut sudah dicadangkan.

• [C-0-11] HARUS mengekspor semua simbol fungsi OpenGL ES 3.1 dan Android Extension Pack, seperti yang ditentukan dalam NDK, melalui library libGLESv3.so. Perhatikan bahwa meskipun semua simbol HARUS ada, bagian 7.1.4.1 menjelaskan secara lebih mendetail persyaratan saat implementasi penuh dari setiap fungsi terkait diharapkan.

• [C-0-12] HARUS mengekspor simbol fungsi untuk simbol fungsi Vulkan 1.0 Vulkan 1.1, 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 saat diharapkan implementasi penuh dari setiap fungsi yang sesuai.

• HARUS dibuat menggunakan kode sumber dan file header yang tersedia di Project Open Source Android upstream.

Perlu diperhatikan bahwa rilis Android mendatang mungkin memperkenalkan dukungan untuk ABI tambahan.

3.3.2 Kompatibilitas Kode Native ARM 32-bit

Jika implementasi perangkat melaporkan dukungan ABI armeabi, implementasi tersebut:

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

• [C-2-1] HARUS menyertakan baris berikut di /proc/cpuinfo, dan TIDAK BOLEH mengubah nilai di perangkat yang sama, meskipun nilai tersebut 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 diimplementasikan pada arsitektur ARMv8, baik melalui dukungan CPU native maupun melalui emulasi software:

  • Petunjuk SWP dan SWPB.
  • Operasi barrier 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 dari API android.webkit.Webview, implementasi tersebut:

• [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 14 untuk implementasi android.webkit.WebView API.

• [C-1-3] String agen pengguna yang dilaporkan oleh WebView HARUS dalam format ini:

  Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, seperti Gecko) Versi/4.0 $(CHROMIUM_VER) Seluler Safari/537.36

  • Nilai string $(VERSION) HARUS sama dengan nilai untuk android.os.Build.VERSION.RELEASE.
  • String $(MODEL) MUNGKIN kosong, tetapi jika tidak kosong, string tersebut HARUS memiliki nilai yang sama dengan android.os.Build.MODEL.
  • "Build/$(BUILD)" MUNGKIN dihilangkan, tetapi jika ada, string $(BUILD) HARUS sama dengan nilai untuk android.os.Build.ID.
  • Nilai string $(CHROMIUM_VER) HARUS berupa versi Chromium di Project Open Source Android upstream.
  • Penerapan perangkat MUNGKIN menghilangkan Seluler dalam string agen pengguna.

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

• [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, dijalankan sebagai ID pengguna terpisah, tidak memiliki akses ke direktori data aplikasi, tidak memiliki akses jaringan langsung, dan hanya memiliki akses ke layanan sistem yang disyaratkan minimum melalui Binder. Implementasi AOSP dari WebView memenuhi persyaratan ini.

Perhatikan bahwa jika implementasi perangkat adalah 32-bit atau mendeklarasikan tombol fitur android.hardware.ram.low, implementasi tersebut akan dikecualikan dari C-1-3.

3.4.2 Kompatibilitas Browser

Jika implementasi perangkat menyertakan aplikasi Browser mandiri untuk penjelajahan web umum, implementasi tersebut:

• [C-1-1] HARUS mendukung setiap API berikut yang terkait dengan HTML5:
  • operasi offline/cache aplikasi
  • Tag<video>
  • geolokasi
• [C-1-2] HARUS mendukung webstorage API HTML5/W3C dan SEHARUSNYA mendukung tensorflow API HTML5/W3C. Perhatikan bahwa karena badan standar pengembangan web bertransisi agar lebih mendukung IndexedDB daripada webstorage, IndexedDB diharapkan menjadi komponen yang diperlukan dalam versi Android yang akan datang.
• DAPAT mengirimkan string agen pengguna kustom dalam aplikasi Browser mandiri.
• HARUS mengimplementasikan dukungan untuk HTML5 sebanyak mungkin di aplikasi Browser mandiri (baik berdasarkan aplikasi Browser WebKit upstream atau penggantian pihak ketiga).

Namun, jika implementasi perangkat tidak menyertakan aplikasi Browser mandiri, implementasi tersebut:

• [C-2-1] HARUS tetap mendukung pola intent 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 terinstal kecuali jika aplikasi tersebut dibatasi seperti yang dijelaskan dalam Bagian 3.5.1.
• [C-0-10] TIDAK BOLEH menerapkan pendekatan pemberian izin yang memastikan kompatibilitas perilaku API hanya untuk aplikasi yang dipilih oleh pengimplementasi perangkat.

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

• [C-0-1] Perangkat TIDAK BOLEH mengubah perilaku atau semantik intent standar.
• [C-0-2] Perangkat TIDAK BOLEH mengubah semantik siklus proses atau siklus proses dari 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 diberlakukan pada aplikasi latar belakang. Lebih khususnya, untuk aplikasi latar belakang:
  • [C-0-4] fungsi ini HARUS berhenti mengeksekusi callback yang didaftarkan oleh aplikasi untuk menerima output dari GnssMeasurement dan GnssNavigationMessage.
  • [C-0-5] modul HARUS membatasi kapasitas frekuensi update yang disediakan untuk aplikasi melalui class API LocationManager atau metode WifiManager.startScan().
  • [C-0-6] jika aplikasi menargetkan API level 25 atau yang lebih tinggi, aplikasi TIDAK BOLEH mengizinkan pendaftaran penerima siaran untuk siaran implisit 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 menargetkan API level 25 atau yang lebih tinggi, aplikasi HARUS menghentikan layanan latar belakang aplikasi, sama seperti jika aplikasi telah memanggil metode stopSelf() layanan, kecuali aplikasi ditempatkan dalam daftar yang diizinkan sementara untuk menangani tugas yang terlihat oleh pengguna.
  • [C-0-8] jika aplikasi menargetkan API level 25 atau yang lebih tinggi, aplikasi HARUS melepaskan penguncian layar saat aktif 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 yang diberikan (seperti yang ditampilkan oleh Provider.getName()) serta 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. AndroidKeyStoreBCSolution - android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
  5. SM - 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 mengetahui kompatibilitas perilaku, tetapi tidak semuanya. Pelaksana bertanggung jawab untuk memastikan kompatibilitas perilaku dengan Project Open Source Android. Karena alasan ini, pengimplementasi perangkat HARUS menggunakan kode sumber yang tersedia melalui Project Open Source Android jika memungkinkan, daripada menerapkan kembali bagian sistem yang signifikan.

3.5.1 Pembatasan Aplikasi

Jika implementasi perangkat menerapkan mekanisme kepemilikan untuk membatasi aplikasi (misalnya, mengubah atau membatasi perilaku API yang dijelaskan dalam SDK) dan mekanisme tersebut lebih ketat daripada Bucket Aplikasi Standby Terbatas, penerapan tersebut akan:

• [C-1-1] HARUS mengizinkan pengguna melihat daftar aplikasi yang dibatasi.
• [C-1-2] HARUS memberikan kemampuan pengguna untuk mengaktifkan / menonaktifkan semua batasan eksklusif ini pada setiap aplikasi.

• [C-1-3] HARUS menerapkan pembatasan kepemilikan ini secara otomatis tanpa bukti perilaku kesehatan sistem yang buruk, tetapi MUNGKIN menerapkan pembatasan pada aplikasi saat mendeteksi perilaku kesehatan sistem yang buruk seperti wakelock bermasalah, layanan berjalan lama, dan kriteria lainnya. Kriteria ini DAPAT ditentukan oleh pelaksana perangkat, tetapi HARUS terkait dengan dampak aplikasi terhadap kondisi sistem. Kriteria lain yang tidak sepenuhnya terkait dengan kesehatan sistem, seperti kurangnya popularitas aplikasi di pasar, TIDAK BOLEH digunakan sebagai kriteria.

• [C-1-4] HARUS menerapkan pembatasan kepemilikan ini secara otomatis untuk aplikasi saat pengguna menonaktifkan pembatasan aplikasi secara manual, dan MUNGKIN menyarankan pengguna untuk menerapkan pembatasan kepemilikan ini.

• [C-1-5] HARUS memberi tahu pengguna jika pembatasan eksklusif ini diterapkan ke aplikasi secara otomatis. Informasi tersebut HARUS diberikan dalam periode 24 jam sebelum penerapan pembatasan eksklusif ini.

• [C-1-6] HARUS menampilkan true untuk metode ActivityManager.isBackgroundRestricted() untuk setiap panggilan API dari aplikasi.

• [C-1-7] TIDAK BOLEH membatasi aplikasi latar depan teratas yang secara eksplisit digunakan oleh pengguna.

• [C-1-8] HARUS menangguhkan pembatasan eksklusif ini pada aplikasi setiap kali pengguna mulai menggunakan aplikasi secara eksplisit, menjadikannya aplikasi latar depan teratas.

• [C-1-10] HARUS memberikan dokumen atau situs yang jelas dan bersifat publik yang mendeskripsikan cara penerapan pembatasan eksklusif. Dokumen atau situs ini HARUS dapat ditautkan dari dokumen Android SDK dan HARUS menyertakan:

  • Kondisi pemicu untuk pembatasan kepemilikan.
  • Apa dan bagaimana aplikasi dapat dibatasi.
  • Cara aplikasi dikecualikan dari pembatasan tersebut.
  • Cara aplikasi meminta pengecualian dari pembatasan eksklusif, jika aplikasi mendukung pengecualian tersebut untuk aplikasi yang dapat diinstal pengguna.

Jika aplikasi sudah diinstal sebelumnya pada perangkat dan tidak pernah digunakan secara eksplisit oleh pengguna selama lebih dari 30 hari, [C-1-3] [C-1-5] akan dikecualikan.

Jika implementasi perangkat memperluas pembatasan aplikasi yang diimplementasikan 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, implementasi tersebut:

• [C-1-1] HARUS memenuhi semua persyaratan dalam pasal 3.5.1 kecuali untuk [C-1-6] dan [C-1-3].
• [C-1-2] HARUS menerapkan batasan pada aplikasi untuk pengguna saja jika ada bukti bahwa pengguna tersebut tidak menggunakan aplikasi selama jangka waktu tertentu. Durasi ini SANGAT DIREKOMENDASIKAN untuk satu bulan atau lebih. Penggunaan HARUS ditentukan oleh interaksi pengguna yang eksplisit melalui UsageStats#getLastTimeVisible() API atau apa pun yang akan menyebabkan aplikasi keluar dari status paksa berhenti, termasuk binding layanan, binding penyedia konten, siaran eksplisit, dll., yang akan dilacak oleh UsageStats API UsageStats#getLastTimeAnyComponentUsed() API yang baru.
• [C-1-3] HARUS menerapkan pembatasan yang hanya memengaruhi semua pengguna perangkat jika ada bukti bahwa paket tersebut tidak digunakan oleh pengguna mana pun selama jangka waktu tertentu. Durasi ini SANGAT DIREKOMENDASIKAN menjadi satu bulan atau lebih.
• [C-1-4] TIDAK BOLEH merender aplikasi yang 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 class dan paket yang ditentukan oleh bahasa pemrograman Java. Untuk memastikan kompatibilitas dengan aplikasi pihak ketiga, 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 memodifikasi API yang ditampilkan secara publik pada platform Android dengan mengubah metode atau tanda tangan 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 Test atau System API ke API di namespace di atas. "Elemen yang ditampilkan secara publik" adalah konstruksi apa pun yang tidak didekorasi dengan penanda "@hide" seperti yang digunakan dalam kode sumber Android upstream.

Pengimplementasi perangkat DAPAT memodifikasi implementasi yang mendasari API, tetapi modifikasi seperti ini:

• [C-0-3] TIDAK BOLEH memengaruhi perilaku yang dinyatakan dan tanda tangan bahasa Java dari semua API yang diekspos secara publik.
• [C-0-4] TIDAK BOLEH diiklankan atau ditampilkan kepada developer.

Namun, pengimplementasi perangkat DAPAT menambahkan API kustom di luar namespace Android standar, tetapi API kustom:

• [C-0-5] TIDAK BOLEH berada dalam namespace yang dimiliki oleh atau merujuk ke organisasi lain. Misalnya, pengimplementasi perangkat TIDAK BOLEH menambahkan API ke com.google.* atau namespace serupa: hanya Google yang dapat melakukannya. Demikian pula, Google TIDAK TIDAK BOLEH menambahkan API ke namespace perusahaan lain.
• [C-0-6] HARUS dikemas dalam library bersama Android sehingga hanya aplikasi yang secara eksplisit menggunakannya (melalui mekanisme <uses-library>) yang terpengaruh oleh peningkatan penggunaan memori API tersebut.

Pengimplementasi perangkat DAPAT menambahkan API kustom dalam bahasa native, di luar NDK API, tetapi API kustom:

• [C-1-1] TIDAK BOLEH ada di library NDK atau library milik organisasi lain seperti yang dijelaskan di sini.

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

Perlu diperhatikan bahwa pembatasan di atas sesuai dengan konvensi standar untuk menamai API dalam bahasa pemrograman Java; bagian ini hanya bertujuan untuk memperkuat konvensi tersebut dan membuatnya mengikat melalui penyertaan dalam Definisi Kompatibilitas ini.

3,7 Kompatibilitas Runtime

Implementasi perangkat:

• [C-0-1] HARUS mendukung format penuh Dalvik Executable (DEX) serta spesifikasi dan semantik bytecode Dalvik.

• [C-0-2] HARUS mengonfigurasi runtime Dalvik untuk mengalokasikan memori sesuai dengan platform Android upstream, dan seperti yang ditetapkan oleh tabel berikut. (Lihat bagian 7.1.1 untuk definisi ukuran layar dan kepadatan layar.)

• HARUS menggunakan Android RunTime (ART), implementasi upstream referensi untuk Format Dalvik Executable, dan sistem pengelolaan paket implementasi referensi.

• HARUS menjalankan uji fuzz dalam berbagai mode eksekusi dan arsitektur target untuk memastikan stabilitas runtime. Lihat JFuzz dan DexFuzz di situs Project Open Source Android.

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

Tata Letak Layar	Kepadatan Layar	Memori Aplikasi Minimum
Smartwatch Android	120 dpi (ldpi)	32MB
	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)	32MB
	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)	128MB
	560 dpi (560dpi)	192MB
	640 dpi (xxxhdpi)	256MB
large	120 dpi (ldpi)	32MB
	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)	128MB
	360 dpi (360dpi)	160MB
	400 dpi (400dpi)	192MB
	420 dpi (420dpi)	228MB
	480 dpi (xxhdpi)	256MB
	560 dpi (560dpi)	384MB
	640 dpi (xxxhdpi)	512 MB
xlarge	120 dpi (ldpi)	48MB
	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 Utama)

Android menyertakan aplikasi peluncur (layar utama) dan dukungan untuk aplikasi pihak ketiga yang menggantikan peluncur perangkat (layar utama).

Jika implementasi perangkat memungkinkan aplikasi pihak ketiga mengganti layar utama perangkat, implementasi 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 menyediakan 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 kemampuan pengguna untuk menanyakan kepada pengguna sebelum menambahkan pintasan yang diminta oleh aplikasi melalui metode API ShortcutManager.requestPinShortcut().
• [C-2-3] HARUS mendukung pintasan yang disematkan serta pintasan dinamis dan statis seperti yang didokumentasikan di halaman Pintasan Aplikasi.

Sebaliknya, jika penerapan perangkat tidak mendukung penyematan pintasan dalam aplikasi, penerapan tersebut:

• [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 ShortcutManager API, implementasi tersebut akan:

• [C-4-1] HARUS mendukung semua fitur pintasan yang didokumentasikan (mis., pintasan statis dan dinamis, penyematan pintasan) serta menerapkan sepenuhnya API class API ShortcutManager.

Jika implementasi perangkat menyertakan aplikasi peluncur default yang menampilkan badge untuk ikon aplikasi, implementasi tersebut:

• [C-5-1] HARUS mematuhi metode API NotificationChannel.setShowBadge(). Dengan kata lain, tampilkan kemampuan visual yang terkait dengan ikon aplikasi jika nilai ditetapkan sebagai true, dan jangan tampilkan skema badge ikon aplikasi apa pun saat semua saluran notifikasi aplikasi telah menetapkan nilai sebagai false.
• MUNGKIN mengganti badge ikon aplikasi dengan skema badge eksklusifnya jika aplikasi pihak ketiga menunjukkan dukungan skema badge eksklusif melalui penggunaan API eksklusif, tetapi HARUS menggunakan resource dan nilai yang diberikan melalui API badge notifikasi yang dijelaskan di SDK , seperti Notification.Builder.setNumber() dan Notification.Builder.setBadgeIconType() API.

Jika implementasi perangkat mendukung ikon monokrom, ikon ini:

• [C-6-1] HARUS digunakan hanya jika pengguna mengaktifkannya secara eksplisit (mis., melalui Setelan atau menu pemilih wallpaper).

3.8.2 Widget

Android mendukung widget aplikasi pihak ketiga dengan menentukan jenis komponen serta API dan siklus proses yang sesuai yang memungkinkan aplikasi menampilkan “AppWidget” kepada pengguna akhir.

Jika implementasi perangkat mendukung widget aplikasi pihak ketiga, implementasi tersebut:

• [C-1-1] HARUS mendeklarasikan dukungan untuk fitur platform android.software.app_widgets.

• [C-1-2] HARUS menyertakan dukungan bawaan untuk AppWidgets dan menampilkan kemampuan antarmuka pengguna untuk menambahkan, mengonfigurasi, melihat, dan menghapus AppWidget

• [C-1-3] HARUS mampu merender widget yang berukuran 4 x 4 dalam ukuran petak standar. Lihat Pedoman Desain Widget Aplikasi di dokumentasi Android SDK untuk mengetahui detailnya.

• MUNGKIN mendukung widget aplikasi di layar kunci.

Jika implementasi perangkat mendukung widget aplikasi pihak ketiga dan penyematan pintasan dalam aplikasi, implementasi tersebut:

• [C-2-1] HARUS melaporkan true untuk AppWidgetManager.html.isRequestPinAppWidgetSupported().
• [C-2-2] HARUS memiliki kemampuan pengguna untuk menanyakan kepada 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 menu notifikasi, kolom sistem) perangkat.

3.8.3.1 Presentasi Notifikasi

Jika implementasi perangkat memungkinkan aplikasi pihak ketiga untuk memberi tahu pengguna tentang peristiwa penting, aplikasi tersebut akan:

• [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 implementasi perangkat menyertakan vibrator, implementasi tersebut HARUS menerapkan API getaran dengan benar. Jika implementasi perangkat tidak memiliki hardware, API terkait HARUS diimplementasikan sebagai tanpa pengoperasian. Perilaku ini diperinci lebih lanjut di bagian 7.
• [C-1-2] HARUS merender dengan benar semua resource (ikon, file animasi, dll.) yang disediakan dalam API, atau di panduan gaya ikon Panel Status/Panel Sistem, meskipun resource tersebut MUNGKIN memberikan pengalaman pengguna alternatif untuk notifikasi daripada yang disediakan oleh penerapan Open Source Android referensi.
• [C-1-3] HARUS mematuhi dan menerapkan dengan benar perilaku yang dijelaskan untuk API guna mengupdate, menghapus, dan mengelompokkan notifikasi.
• [C-1-4] HARUS memberikan perilaku lengkap NotificationChannel API yang didokumentasikan dalam SDK.
• [C-1-5] HARUS menyediakan affordance pengguna untuk memblokir dan mengubah notifikasi aplikasi pihak ketiga tertentu per setiap saluran dan level paket aplikasi.
• [C-1-6] HARUS menyediakan juga kemampuan pengguna untuk menampilkan saluran notifikasi yang dihapus.

• [C-1-7] HARUS merender semua resource (gambar, stiker, ikon, dll.) dengan benar melalui Notification.MessagingStyle 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 setGrouphasil.

• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk memberikan kemampuan bagi pengguna agar dapat mengontrol notifikasi yang diekspos ke aplikasi yang telah diberi izin Pemroses Notifikasi. Perincian harus disetel agar pengguna dapat mengontrol jenis notifikasi yang dihubungkan ke pemroses ini untuk setiap pemroses notifikasi. Jenis ini HARUS mencakup notifikasi "percakapan", "pemberitahuan", "senyap", dan "berkelanjutan penting".

• [C-SR-2] SANGAT DIREKOMENDASIKAN menyediakan kemampuan bagi pengguna untuk menentukan aplikasi yang akan dikecualikan agar tidak memberi tahu pemroses notifikasi tertentu.

• [C-SR-3] SANGAT DIREKOMENDASIKAN untuk secara otomatis menampilkan kemampuan pengguna guna memblokir notifikasi aplikasi pihak ketiga tertentu per setiap saluran dan level paket aplikasi setelah pengguna menutup notifikasi tersebut beberapa kali.

• SEHARUSNYA mendukung notifikasi yang beragam.

• HARUS menyajikan beberapa notifikasi dengan prioritas yang lebih tinggi sebagai notifikasi pendahuluan.

• SEHARUSNYA memiliki kemampuan pengguna untuk menunda notifikasi.

• DAPAT hanya mengelola visibilitas dan waktu kapan aplikasi pihak ketiga dapat memberi tahu pengguna tentang peristiwa penting untuk mengurangi masalah keamanan seperti gangguan pengemudi.

Android 11 memperkenalkan dukungan untuk notifikasi percakapan, yang merupakan notifikasi yang menggunakan MessagingStyle dan memberikan ID Pintasan Orang yang dipublikasikan.

Implementasi perangkat:

• [C-SR-4] SANGAT DIREKOMENDASIKAN untuk mengelompokkan dan menampilkan conversation notifications menjelang notifikasi non-percakapan, kecuali notifikasi layanan latar depan yang sedang berlangsung dan notifikasi importance:high.

Jika implementasi perangkat mendukung conversation notifications dan aplikasi memberikan data yang diperlukan untuk bubbles, implementasi tersebut:

• [C-SR-5] SANGAT DIREKOMENDASIKAN untuk menampilkan percakapan ini sebagai balon. Implementasi AOSP memenuhi persyaratan ini dengan UI Sistem, Setelan, dan Peluncur default.

Jika implementasi perangkat mendukung notifikasi lengkap, implementasi 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 menyajikan setiap elemen resource (mis. ikon, judul, dan teks ringkasan) yang ditentukan dalam class API Notification.Style dan subclass-nya.

Notifikasi pendahuluan adalah notifikasi yang ditampilkan kepada pengguna saat muncul secara terpisah dari platform yang digunakan pengguna. Jika implementasi perangkat mendukung notifikasi pendahuluan, implementasi tersebut:

• [C-3-1] HARUS menggunakan tampilan dan resource notifikasi pendahuluan seperti yang dijelaskan dalam class API Notification.Builder saat notifikasi pendahuluan 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) untuk 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 pemroses yang diinstal dan diaktifkan pengguna, termasuk setiap dan semua metadata yang dilampirkan ke objek Notification.
• [C-0-2] HARUS mematuhi panggilan API snoozeNotification(), menutup notifikasi, dan melakukan callback setelah durasi penundaan yang ditetapkan dalam panggilan API.

Jika implementasi perangkat memiliki kemampuan pengguna untuk menunda notifikasi, implementasi tersebut:

• [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 aplikasi 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), implementasi tersebut:

• [C-1-1] HARUS, karena jika implementasi perangkat telah menyediakan cara bagi pengguna untuk mengizinkan atau menolak aplikasi pihak ketiga mengakses konfigurasi kebijakan DND, menampilkan Aturan DND otomatis yang dibuat oleh aplikasi bersama aturan yang dibuat pengguna dan telah ditentukan sebelumnya.
• [C-1-3] HARUS mengikuti nilai suppressedVisualEffects yang diteruskan di sepanjang NotificationManager.Policy dan jika aplikasi telah menyetel salah satu tanda SUPPRESSED_Effect_SCREEN_OFF atau SUPPRESSED_EXTERNAL_SCREEN_ON, hal ini SEHARUS menunjukkan kepada pengguna bahwa efek visual disembunyikan di menu setelan DND.

3.8.4. Assist API

Android menyertakan Assist API agar aplikasi dapat memilih banyaknya informasi konteks saat ini yang dibagikan kepada asisten di perangkat.

Jika implementasi perangkat mendukung tindakan Assist, implementasi tersebut:

• [C-2-1] HARUS menunjukkan dengan jelas kepada pengguna akhir ketika konteks dibagikan, oleh salah satu cara berikut:
  • Setiap kali aplikasi bantuan mengakses konteks, menampilkan cahaya putih di sekitar tepi layar yang memenuhi atau melebihi durasi dan kecerahan penerapan Project Open Source Android.
  • Untuk aplikasi bantuan bawaan, memberikan kemampuan pengguna kurang dari dua navigasi dari menu setelan input suara dan aplikasi asisten default, dan hanya membagikan konteks saat aplikasi bantuan secara eksplisit dipanggil oleh pengguna melalui frasa pengaktif atau input tombol navigasi bantuan.
• [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 menghilang setelah jangka waktu singkat, dan menggunakan API jenis jendela TYPE_APPLICATION_OVERLAY untuk menampilkan jendela pemberitahuan sebagai overlay di atas aplikasi lain.

Jika implementasi perangkat menyertakan output layar atau video, implementasi tersebut:

• [C-1-1] HARUS memberikan affordance pengguna untuk memblokir aplikasi agar tidak menampilkan jendela pemberitahuan yang menggunakan TYPE_APPLICATION_OVERLAY . Implementasi AOSP memenuhi persyaratan ini dengan memiliki kontrol di menu 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 kelompok tema “Holo” dan "Material" sebagai kumpulan gaya yang ditentukan untuk digunakan developer aplikasi jika ingin mencocokkan tampilan dan nuansa tema Holo seperti yang ditentukan oleh Android SDK.

Jika implementasi perangkat menyertakan output layar atau video, implementasi tersebut:

• [C-1-1] TIDAK BOLEH mengubah atribut tema Holo apa pun yang diekspos ke aplikasi.
• [C-1-2] HARUS mendukung jenis tema “Material” dan TIDAK BOLEH mengubah atribut tema Material atau aset apa pun yang diekspos ke aplikasi.

• [C-1-3] HARUS menyetel jenis font "sans-serif" ke Roboto versi 2.x untuk bahasa yang didukung Roboto, atau memberikan kemampuan pengguna untuk mengubah font yang digunakan bagi jenis font "sans-serif" menjadi Roboto versi 2.x untuk bahasa yang didukung Roboto.

• [C-1-4] HARUS menghasilkan palet tonal warna 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 menghasilkan palet tonal warna dinamis menggunakan gaya tema warna yang dienumerasi dalam dokumentasi Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (lihat android.theme.customization.theme_styles), yaitu TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD, danMONOCHROMATIC.

  "Warna sumber" digunakan untuk menghasilkan palet tonal 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 kroma CAM16 5 atau lebih besar.

  • HARUS diambil 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 disediakan yang memenuhi persyaratan warna sumber di atas.

Android juga menyertakan kelompok tema “Default Perangkat” sebagai serangkaian gaya yang ditentukan untuk digunakan oleh developer aplikasi jika ingin menyesuaikan tampilan dan nuansa tema perangkat seperti yang ditetapkan oleh pengimplementasi perangkat.

• Implementasi perangkat DAPAT mengubah atribut tema Default Perangkat yang diekspos ke aplikasi.

Android mendukung tema varian dengan kolom sistem transparan, yang memungkinkan developer aplikasi mengisi area di belakang status dan menu navigasi dengan konten aplikasi mereka. Untuk memungkinkan pengalaman developer yang konsisten dalam konfigurasi ini, gaya ikon status bar harus dipertahankan di berbagai implementasi perangkat.

Jika implementasi perangkat menyertakan status bar sistem, implementasi tersebut:

• [C-2-1] HARUS menggunakan warna putih untuk ikon status sistem (seperti kekuatan sinyal dan tingkat baterai) dan notifikasi yang dikeluarkan oleh sistem, kecuali jika ikon tersebut menunjukkan status bermasalah atau aplikasi meminta status bar lampu menggunakan tanda WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS.
• [C-2-2] Implementasi perangkat Android HARUS mengubah warna ikon status sistem menjadi hitam (untuk detailnya, lihat R.style) saat aplikasi meminta status bar lampu.

3.8.7. Wallpaper Animasi

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

Hardware dianggap mampu menjalankan wallpaper animasi dengan andal jika dapat menjalankan semua wallpaper animasi, tanpa batasan fungsinya, pada kecepatan frame yang wajar tanpa efek buruk pada aplikasi lain. Jika batasan dalam hardware menyebabkan wallpaper dan/atau aplikasi error, gagal fungsi, mengonsumsi CPU atau daya baterai yang berlebihan, atau berjalan pada kecepatan frame yang sangat rendah, hardware tersebut dianggap tidak dapat menjalankan wallpaper animasi. Sebagai contoh, beberapa wallpaper animasi mungkin menggunakan konteks OpenGL 2.0 atau 3.x untuk merender kontennya. Wallpaper animasi tidak akan berjalan dengan andal pada hardware yang tidak mendukung beberapa konteks OpenGL karena penggunaan wallpaper animasi dari konteks OpenGL dapat mengalami konflik dengan aplikasi lain yang juga menggunakan konteks OpenGL.

• Implementasi perangkat yang mampu menjalankan wallpaper animasi secara andal seperti yang dijelaskan di atas HARUS menerapkan wallpaper animasi.

Jika implementasi perangkat menerapkan wallpaper animasi, implementasi tersebut:

• [C-1-1] HARUS melaporkan tanda fitur platform android.software.live_wallpaper.

3.8.8. Pengalihan Aktivitas

Kode sumber Android upstream menyertakan layar ringkasan, yaitu antarmuka pengguna tingkat sistem untuk pengalihan tugas serta menampilkan aktivitas dan tugas yang baru-baru ini diakses menggunakan gambar thumbnail dari status grafis aplikasi saat pengguna terakhir kali meninggalkan aplikasi.

Implementasi perangkat termasuk tombol navigasi fungsi terbaru seperti yang dijelaskan di bagian 7.2.3 DAPAT mengubah antarmuka.

Jika implementasi perangkat termasuk tombol navigasi fungsi terbaru seperti yang dijelaskan di bagian 7.2.3 mengubah antarmuka, implementasi tersebut:

• [C-1-1] HARUS mendukung setidaknya hingga 7 aktivitas yang ditampilkan.
• Setidaknya HARUS menampilkan judul 4 aktivitas sekaligus.

• HARUS menampilkan warna sorotan, ikon, judul layar dalam terbaru.
• SEHARUSNYA menampilkan kemampuan penutup ("x") tetapi MUNGKIN menundanya hingga pengguna berinteraksi dengan layar.
• HARUS terapkan pintasan untuk beralih dengan mudah ke aktivitas sebelumnya.
• HARUS memicu tindakan beralih cepat antara dua aplikasi yang terakhir digunakan, saat tombol fungsi terbaru diketuk dua kali.
• HARUS memicu mode multi-aplikasi layar terpisah, jika didukung, saat tombol fungsi terbaru ditekan lama.
• DAPAT menampilkan konten terbaru yang berafiliasi sebagai kelompok yang bergerak bersama.
• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menggunakan antarmuka pengguna Android upstream (atau antarmuka berbasis thumbnail serupa) bagi layar ringkasan.

3.8.9. Pengelolaan Input

Android menyertakan dukungan untuk Pengelolaan Input dan dukungan untuk editor metode input pihak ketiga.

Jika implementasi perangkat memungkinkan 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 dijelaskan dalam dokumentasi Android SDK.

3.8.10. Kontrol Media Layar Kunci

Remote Control Client API tidak digunakan lagi di Android 5.0 dan digantikan oleh Template Notifikasi Media yang memungkinkan aplikasi media berintegrasi dengan kontrol pemutaran yang ditampilkan di layar kunci.

3.8.11. Screensaver (sebelumnya Dreams)

Lihat bagian 3.2.3.5 untuk setelan yang dimaksudkan untuk menggabungkan screensaver.

3.8.12. Lokasi

Jika implementasi perangkat menyertakan sensor hardware (mis. GPS) yang mampu memberikan koordinat lokasi, implementasi tersebut akan

• [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 di Unicode 10.0.

Jika implementasi perangkat menyertakan output layar atau video, implementasi tersebut:

• [C-1-1] HARUS mampu merender karakter emoji ini dalam glyph warna.
• [C-1-2] HARUS menyertakan dukungan untuk:
  • Font Roboto 2 dengan bobot berbeda—sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-kondensasi, sans-serif-condensed-light untuk bahasa yang tersedia di perangkat.
  • Cakupan Unicode 7.0 lengkap dari bahasa Latin, Yunani, dan Sirilik, termasuk rentang Latin Extended A, B, C, dan D, serta semua glyph dalam blok simbol mata uang Unicode 7.0.
• [C-1-3] TIDAK BOLEH menghapus atau mengubah NotoColorEmoji.tff di image sistem. (Anda dapat menambahkan font emoji baru untuk mengganti emoji di NotoColorEmoji.tff)
• HARUS mendukung warna kulit dan beragam emoji keluarga seperti yang ditentukan dalam Laporan Teknis Unicode #51.

Jika implementasi perangkat menyertakan IME, implementasi tersebut:

• HARUS menyediakan metode input kepada pengguna untuk karakter emoji ini.

Android menyertakan dukungan untuk merender font Myanmar. Myanmar memiliki beberapa font yang tidak sesuai dengan Unicode, umumnya dikenal sebagai “Zawgyi”, untuk merender bahasa Myanmar.

Jika implementasi perangkat menyertakan dukungan untuk Burma, implementasi tersebut:

• [C-2-1] HARUS merender teks dengan font yang sesuai dengan Unicode sebagai default; font yang tidak sesuai dengan Unicode TIDAK BOLEH disetel sebagai font default, kecuali jika pengguna memilihnya di pemilih bahasa.
• [C-2-2] HARUS mendukung font Unicode dan font yang tidak sesuai dengan Unicode jika font yang tidak sesuai dengan Unicode didukung pada perangkat. Font yang tidak mematuhi Unicode TIDAK BOLEH menghapus atau menimpa font Unicode.
• [C-2-3] HARUS merender teks dengan font yang tidak sesuai dengan 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 sesuai dengan Unicode untuk Myanmar. Developer aplikasi dan penulis halaman web dapat menentukan my-Qaag sebagai kode bahasa yang ditetapkan seperti yang digunakan untuk bahasa lain.

3.8.14. Multi-aplikasi

Jika implementasi perangkat memiliki kemampuan untuk menampilkan beberapa aktivitas secara bersamaan, implementasi tersebut:

• [C-1-1] HARUS mengimplementasikan mode multi-aplikasi tersebut sesuai dengan perilaku aplikasi dan API yang dijelaskan dalam dokumentasi dukungan mode multi-aplikasi Android SDK dan memenuhi persyaratan berikut:
• [C-1-2] HARUS mematuhi android:resizeableActivity yang disetel oleh aplikasi dalam file AndroidManifest.xml seperti yang dijelaskan dalam SDK ini.
• [C-1-3] TIDAK BOLEH menawarkan mode layar terpisah atau mode bentuk bebas jika tinggi layar kurang dari 440 dp dan lebar layar kurang dari 440 dp.
• [C-1-4] Aktivitas TIDAK BOLEH diubah ukurannya ke ukuran yang lebih kecil dari 220 dp dalam mode multi-aplikasi selain Picture-in-Picture.
• Implementasi perangkat dengan ukuran layar xlarge SEHARUSNYA mendukung mode bentuk bebas.

Jika implementasi perangkat mendukung mode multi-aplikasi, dan mode layar terpisah, implementasi tersebut:

• [C-2-2] HARUS memangkas aktivitas multi-aplikasi layar terpisah yang dipasang ke dok, tetapi HARUS menampilkan beberapa kontennya, jika aplikasi Peluncur adalah jendela yang difokuskan.
• [C-2-3] HARUS menerima nilai AndroidManifestLayout_minWidth dan AndroidManifestLayout_minHeight yang dideklarasikan aplikasi peluncur pihak ketiga dan tidak mengganti nilai ini selama menampilkan beberapa konten aktivitas yang dipasang ke dok.

Jika implementasi perangkat mendukung mode multi-aplikasi dan mode multi-aplikasi Picture-in-Picture, implementasi tersebut:

• [C-3-1] HARUS meluncurkan aktivitas dalam mode multi-aplikasi picture-in-picture jika aplikasi sedang: * Menargetkan API level 26 atau yang lebih tinggi dan mendeklarasikan android:supportsPictureInPicture * Menargetkan API level 25 atau yang lebih rendah dan mendeklarasikan android:resizeableActivity dan android:supportsPictureInPicture.
• [C-3-2] HARUS mengekspos tindakan dalam SystemUI-nya seperti yang ditentukan oleh aktivitas PIP saat ini melalui setActions() API.
• [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 setAspectRatio() API.
• [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 memberikan kemampuan pengguna untuk memblokir aplikasi agar tidak ditampilkan dalam mode PII; implementasi AOSP memenuhi persyaratan ini dengan memiliki kontrol di menu 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.

3.8.15. Potongan Layar

Android mendukung Potongan Tampilan seperti yang dijelaskan dalam dokumen SDK. DisplayCutout API menentukan area di tepi layar yang mungkin tidak berfungsi untuk aplikasi karena potongan layar atau tampilan melengkung di tepi.

Jika implementasi perangkat menyertakan potongan layar, implementasi 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 mengikuti tanda potongan layar yang ditetapkan oleh aplikasi melalui WindowManager.LayoutParams API seperti yang dijelaskan di SDK.
• [C-1-4] HARUS melaporkan nilai yang benar untuk semua metrik potongan yang ditentukan di DisplayCutout API.

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 Pasal 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 semua koneksi jaringan apa pun, tanpa tindakan eksplisit dari pengguna (misalnya, menekan tombol di overlay), kecuali untuk layanan yang disebutkan dalam 9.8.6 Pengambilan Konten dan Penelusuran Aplikasi.

Jika implementasi perangkat menghasilkan pratinjau yang terlihat oleh pengguna saat konten disalin ke papan klip untuk item ClipData apa pun dengan ClipData.getDescription().getExtras() berisi android.content.extra.IS_SENSITIVE, implementasi tersebut:

• [C-1-1] HARUS menyamarkan pratinjau yang terlihat oleh pengguna

Implementasi referensi AOSP memenuhi persyaratan papan klip ini.

3,9. Administrasi Perangkat

Android menyertakan fitur yang memungkinkan aplikasi yang peka keamanan untuk menjalankan fungsi administrasi perangkat di tingkat sistem, seperti menerapkan kebijakan sandi atau melakukan penghapusan total dari jarak jauh, melalui Android Device Administration API.

Jika implementasi perangkat menerapkan berbagai kebijakan administrasi perangkat yang ditentukan dalam dokumentasi Android SDK, implementasi tersebut:

• [C-1-1] HARUS mendeklarasikan android.software.device_admin.
• [C-1-2] HARUS mendukung penyediaan pemilik perangkat seperti yang dijelaskan di pasal 3.9.1 dan pasal 3.9.1.1.

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 Klien Kebijakan Perangkat (DPC) sebagai aplikasi Pemilik Perangkat seperti yang dijelaskan di bawah ini:
  • Jika tidak memiliki pengguna atau data pengguna yang dikonfigurasi, implementasi perangkat:
    • [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 mendeklarasikan 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 melanjutkan di Wizard Penyiapan hingga aplikasi Pemilik Perangkat selesai.
  • Jika implementasi perangkat memiliki pengguna atau data pengguna, implementasi tersebut:
    • [C-1-7] HARUS mendaftarkan aplikasi DPC apa pun sebagai Aplikasi Pemilik Perangkat lagi.

• [C-1-2] HARUS menampilkan pemberitahuan pengungkapan yang sesuai (seperti seperti yang dirujuk dalam AOSP) dan mendapatkan izin afirmatif dari pengguna akhir sebelum aplikasi ditetapkan sebagai Pemilik Perangkat, kecuali jika perangkat dikonfigurasi secara terprogram untuk Mode Demo Retail sebelum interaksi pengguna akhir di layar. Jika implementasi perangkat mendeklarasikan android.software.device_admin, tetapi juga menyertakan solusi pengelolaan perangkat eksklusif dan menyediakan mekanisme untuk mempromosikan aplikasi yang dikonfigurasi dalam solusinya sebagai "setara Pemilik Perangkat" dengan "Pemilik Perangkat" standar seperti yang dikenali oleh Android Device disusupi API standar:

• [C-2-1] HARUS memiliki proses untuk memverifikasi bahwa aplikasi tertentu yang sedang dipromosikan adalah milik solusi pengelolaan perangkat perusahaan yang sah dan telah dikonfigurasi dalam solusi eksklusif agar memiliki hak yang setara sebagai "Pemilik Perangkat".

• [C-2-2] HARUS menampilkan pengungkapan izin Pemilik Perangkat AOSP yang sama dengan alur yang dimulai oleh android.app.action.PROVISION_MANAGED_DEVICE sebelum mendaftarkan aplikasi DPC sebagai "Device Owner".

• [C-2-3] TIDAK BOLEH melakukan hard code izin atau mencegah penggunaan aplikasi pemilik perangkat lain.

3.9.1.2 Penyediaan profil terkelola

Jika implementasi perangkat mendeklarasikan android.software.managed_users, implementasi tersebut:

• [C-1-1] HARUS menerapkan API yang memungkinkan aplikasi Pengontrol Kebijakan Perangkat (DPC) menjadi pemilik Profil Terkelola baru.

• [C-1-2] Proses penyediaan profil terkelola (alur yang dimulai oleh DPC menggunakan android.app.action.PROVISION_MANAGED_PROFILE) atau oleh platform), layar izin dan pengalaman pengguna HARUS selaras dengan implementasi AOSP.

• [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 mewakili saat setelan tertentu dibatasi oleh Device Admin.
  • Pesan penjelasan singkat, seperti yang diberikan oleh Admin Perangkat melalui setShortSupportMessage.
  • Ikon aplikasi DPC.

• [C-1-4] HARUS meluncurkan pengendali 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 pengendali.

• [C-1-5] HARUS mengirim siaran ACTION_PROFILE_PROVISIONING_SELESAI ke DPC profil kerja saat penyediaan dimulai oleh intent android.app.action.PROVISION_MANAGED_PROFILE.

• [C-1-6] HARUS mengirim 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 mengirim intent ACTION_ADMIN_POLICY_COMPLIANCE ke profil kerja saat Pemilik Profil ditetapkan selama penyediaan, apa pun 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 android.app.admin.DevicePolicyManager API.
• [C-1-2] HARUS mengizinkan pembuatan satu profil dan hanya satu profil terkelola.
• [C-1-3] HARUS menggunakan badge ikon (mirip dengan badge kerja upstream AOSP) untuk menampilkan aplikasi dan widget terkelola serta elemen UI dengan badge lainnya seperti Terbaru & Notifikasi.
• [C-1-4] HARUS menampilkan ikon notifikasi (mirip dengan badge kerja upstream AOSP) untuk menunjukkan kapan pengguna berada dalam aplikasi profil terkelola.
• [C-1-5] HARUS menampilkan toast yang menunjukkan bahwa pengguna berada dalam profil terkelola jika dan saat perangkat aktif (ACTION_USER_PRESENT) dan aplikasi latar depan berada dalam profil terkelola.
• [C-1-6] Jika ada profil terkelola, HARUS menunjukkan kemampuan visual dalam Intent 'Chooser' agar pengguna dapat meneruskan intent dari profil terkelola ke pengguna utama atau sebaliknya, jika diaktifkan oleh Pengontrol Device Policy.
• [C-1-7] Jika ada profil terkelola, HARUS memperlihatkan kemampuan pengguna berikut untuk pengguna utama dan profil terkelola:
  • Penghitungan terpisah untuk baterai, lokasi, data seluler, dan penggunaan penyimpanan untuk pengguna utama dan profil terkelola.
  • Pengelolaan independen atas Aplikasi VPN yang diinstal dalam pengguna utama atau profil terkelola.
  • Pengelolaan independen atas aplikasi yang diinstal dalam pengguna utama atau profil terkelola.
  • Pengelolaan akun independen dalam pengguna utama atau profil terkelola.
• [C-1-8] HARUS memastikan aplikasi telepon, kontak, dan pesan yang sudah terinstal dapat menelusuri dan mencari informasi penelepon dari profil terkelola (jika ada) bersama dengan profil utama, jika Pengontrol Kebijakan Perangkat mengizinkannya.
• [C-1-9] HARUS memastikan bahwa profil tersebut memenuhi semua persyaratan keamanan yang berlaku untuk perangkat dengan beberapa pengguna yang aktif (lihat pasal 9.5), meskipun profil terkelola tidak dihitung sebagai pengguna lain selain pengguna utama.

Jika implementasi perangkat mendeklarasikan android.software.managed_users dan android.software.secure_lock_screen, implementasi tersebut:

• [C-2-1] HARUS mendukung kemampuan untuk menentukan layar kunci terpisah yang memenuhi persyaratan berikut untuk memberikan akses hanya ke aplikasi yang berjalan di profil terkelola.
  • Implementasi perangkat HARUS mematuhi intent 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 penyimpanan dan pengelolaan kredensial yang sama dengan profil induk, seperti yang didokumentasikan di Situs Project Open Source Android.
  • Kebijakan sandi DPC HARUS berlaku hanya untuk kredensial layar kunci profil terkelola, kecuali dipanggil instance DevicePolicyManager yang ditampilkan oleh getParentProfileInstance.
• Jika kontak dari profil terkelola ditampilkan di log panggilan bawaan, UI dalam panggilan, notifikasi panggilan yang sedang berlangsung dan tidak terjawab, kontak, dan aplikasi pesan, kontak tersebut SEHARUSNYA diberi badge dengan badge yang sama dengan 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 memberikan kemampuan pengguna untuk logout dari pengguna saat ini dan beralih kembali ke pengguna utama dalam sesi multi-pengguna saat isLogoutEnabled menampilkan true. Kemampuan pengguna HARUS dapat diakses dari layar kunci tanpa membuka kunci perangkat.

Jika implementasi perangkat mendeklarasikan android.software.device_admin dan menyediakan kemampuan pengguna di perangkat untuk menambahkan Pengguna sekunder tambahan, implementasi tersebut:

• [C-SR-1] SANGAT DIREKOMENDASIKAN menampilkan pengungkapan izin Pemilik Perangkat AOSP yang sama seperti yang ditunjukkan dalam alur yang dimulai oleh android.app.action.PROVISION_MANAGED_DEVICE, sebelum mengizinkan akun ditambahkan di Pengguna sekunder baru, sehingga pengguna memahami bahwa perangkat tersebut dikelola.

3.9.4 Persyaratan Peran Pengelolaan Kebijakan Perangkat

Jika implementasi perangkat melaporkan android.software.device_admin atau android.software.managed_users, implementasi tersebut:

• [C-1-1] HARUS mendukung peran pengelolaan kebijakan perangkat seperti yang ditetapkan di pasal 9.1. Aplikasi yang memiliki peran pengelolaan kebijakan perangkat DAPAT ditentukan dengan menyetel config_devicePolicyManagement ke nama paket. Nama paket HARUS diikuti dengan : dan sertifikat penandatanganan, kecuali jika aplikasi sudah dipramuat.

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 ditetapkan untuk config_devicePolicyManagement seperti yang dijelaskan di atas:

• [C-3-1] Aplikasi HARUS diinstal pada semua profil untuk pengguna.
• [C-3-2] Implementasi perangkat DAPAT menentukan aplikasi yang mengupdate holder peran pengelolaan kebijakan perangkat sebelum penyediaan dengan menyetel config_devicePolicyManagementUpdater.

Jika nama paket ditentukan untuk config_devicePolicyManagementUpdater seperti yang dijelaskan di atas:

• [C-4-1] Aplikasi HARUS diprainstal pada perangkat.
• [C-4-2] Aplikasi HARUS mengimplementasikan filter intent yang me-resolve android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER.

3.10. Aksesibilitas

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

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

• [C-1-1] HARUS menyediakan implementasi framework aksesibilitas Android seperti yang dijelaskan dalam dokumentasi SDK API aksesibilitas.
• [C-1-2] HARUS menghasilkan peristiwa aksesibilitas dan mengirimkan AccessibilityEvent yang sesuai ke semua implementasi AccessibilityService yang terdaftar seperti yang didokumentasikan di SDK.
• [C-1-4] HARUS menyediakan kemampuan pengguna untuk mengontrol layanan aksesibilitas yang mendeklarasikan AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON. Perhatikan bahwa untuk penerapan perangkat dengan menu navigasi sistem, penerapan tersebut HARUS memungkinkan pengguna memiliki opsi pada tombol di menu navigasi sistem untuk mengontrol layanan ini.

Jika implementasi perangkat menyertakan layanan aksesibilitas bawaan, implementasi tersebut:

• [C-2-1] HARUS menerapkan layanan aksesibilitas bawaan ini sebagai aplikasi Direct Boot Aware saat penyimpanan data dienkripsi dengan Enkripsi Berbasis File (FBE).
• HARUS menyediakan mekanisme dalam alur penyiapan siap pakai bagi pengguna untuk mengaktifkan layanan aksesibilitas yang relevan, serta opsi untuk menyesuaikan ukuran font, ukuran layar, dan gestur pembesaran.

3.11. Text-to-Speech

Android menyertakan API yang memungkinkan aplikasi menggunakan layanan text-to-speech (TTS) dan memungkinkan penyedia layanan menyediakan implementasi layanan TTS.

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

• [C-1-1] HARUS mendukung framework Android TTS API.

Jika implementasi perangkat mendukung penginstalan mesin TTS pihak ketiga, implementasi tersebut:

• [C-2-1] HARUS memberikan kemampuan pengguna untuk memungkinkan pengguna memilih mesin TTS untuk digunakan di tingkat sistem.

3.12. Framework Input TV

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

Jika implementasi perangkat mendukung TIF, implementasi tersebut:

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

3.13. Setelan Cepat

Android menyediakan komponen UI Setelan Cepat yang memungkinkan akses cepat ke tindakan yang sering digunakan atau sangat dibutuhkan.

Jika implementasi perangkat menyertakan komponen UI Setelan Cepat dan mendukung Setelan Cepat pihak ketiga, implementasi tersebut:

• [C-1-1] HARUS mengizinkan pengguna menambahkan atau menghapus kartu yang disediakan melalui API quicksettings dari aplikasi pihak ketiga.
• [C-1-2] TIDAK BOLEH menambahkan kartu secara otomatis dari aplikasi pihak ketiga langsung ke Setelan Cepat.
• [C-1-3] HARUS menampilkan semua kartu yang ditambahkan pengguna dari aplikasi pihak ketiga bersama kartu setelan cepat yang disediakan sistem.

3.14. UI Media

Jika implementasi perangkat menyertakan aplikasi yang tidak diaktifkan dengan suara (Aplikasi) yang berinteraksi dengan aplikasi pihak ketiga melalui MediaBrowser atau MediaSession, Aplikasi:

• [C-1-2] HARUS menampilkan dengan jelas ikon yang diperoleh melalui getIconBitmap() atau getIconUri() dan judul yang diperoleh melalui getTitle() seperti dijelaskan dalam MediaDescription. Dapat mempersingkat judul untuk mematuhi peraturan keselamatan (misalnya gangguan bagi 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 untuk berinteraksi dengan seluruh hierarki MediaBrowser. DAPAT membatasi akses ke bagian hierarki untuk mematuhi peraturan keselamatan (misalnya, gangguan bagi pengemudi), tetapi TIDAK BOLEH memberikan perlakuan istimewa berdasarkan konten atau penyedia konten.

• [C-1-5] HARUS mempertimbangkan mengetuk dua kali 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 HARUS diberi izin dengan android:protectionLevel yang 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 terekspos dan memiliki CATEGORY_BROWSABLE
  • Tindakan adalah salah satu dari ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
  • Target secara eksplisit diekspos dengan android:visibleToInstantApps
• [C-1-3] Aplikasi Instan TIDAK BOLEH berinteraksi secara eksplisit dengan aplikasi terinstal, kecuali komponen diekspos melalui android:visibleToInstantApps.
• [C-1-4] Aplikasi Terinstal TIDAK BOLEH melihat detail tentang Aplikasi Instan di perangkat, kecuali jika Aplikasi Instan secara eksplisit terhubung ke aplikasi yang diinstal.

• Implementasi perangkat HARUS memberikan kemampuan pengguna berikut untuk berinteraksi dengan Aplikasi Instan. AOSP memenuhi persyaratan dengan UI, Setelan, dan Peluncur Sistem default. Implementasi perangkat:

  • [C-1-5] HARUS menyediakan affordance 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 Settings. Untuk Aplikasi Instan yang diluncurkan melalui intent web, seperti yang ditentukan menggunakan intent dengan tindakan yang ditetapkan ke Intent.ACTION_VIEW dan dengan skema "http" atau "https", kemampuan pengguna tambahan SEHARUS 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 berjalan untuk diakses dari fungsi Recents jika fungsi Terbaru tersedia di perangkat.

• [C-1-8] HARUS melakukan pramuat satu atau beberapa aplikasi atau komponen layanan dengan pengendali intent untuk intent yang tercantum dalam SDK di sini dan membuat intent terlihat untuk Aplikasi Instan.

3.16. Penyandingan Perangkat Pendamping

Android menyertakan dukungan untuk penyambungan perangkat pendamping agar dapat mengelola asosiasi dengan perangkat pendamping secara lebih efektif dan menyediakan CompanionDeviceManager API agar aplikasi dapat mengakses fitur ini.

Jika implementasi perangkat mendukung fitur penyambungan perangkat pendamping, implementasi tersebut:

• [C-1-1] HARUS mendeklarasikan tombol fitur FEATURE_COMPANION_DEVICE_SETUP .
• [C-1-2] HARUS memastikan API dalam paket android.companion diimplementasikan sepenuhnya.
• [C-1-3] HARUS memberikan kemampuan kepada pengguna agar pengguna dapat memilih/mengonfirmasi bahwa perangkat pendamping tersedia dan dapat digunakan.

3.17. Aplikasi Berat

Jika implementasi perangkat mendeklarasikan fitur FEATURE_CANT_SAVE_STATE, implementasi tersebut:

• [C-1-1] HARUS memiliki satu aplikasi terinstal saja yang menentukan cantSaveState yang berjalan di sistem pada satu waktu. Jika pengguna keluar dari aplikasi tersebut tanpa keluar secara eksplisit (misalnya dengan menekan layar utama sambil keluar dari aktivitas aktif sistem, bukan menekan kembali tanpa aktivitas aktif tersisa di sistem), maka implementasi perangkat HARUS memprioritaskan aplikasi tersebut di RAM seperti halnya untuk hal-hal lain yang diperkirakan akan tetap berjalan, seperti layanan latar depan. Meskipun aplikasi semacam itu berada di latar belakang, sistem masih dapat menerapkan fitur pengelolaan daya padanya, seperti membatasi akses CPU dan jaringan.
• [C-1-2] HARUS menyediakan affordance UI untuk memilih aplikasi yang tidak akan berpartisipasi dalam mekanisme simpan/pulihkan 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, implementasi tersebut:

• [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 agar aplikasi dapat 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 "diatribusikan dengan" atau "disimpan di" Akun saat kolom ACCOUNT_NAME, dan ACCOUNT_TYPE, untuk kontak mentah cocok dengan kolom Account.name dan Account.type yang sesuai pada akun.

Akun lokal default: akun untuk kontak mentah yang hanya disimpan di perangkat dan tidak terkait 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 terkait dengan Akun di AccountManager, yang dibuat dengan setidaknya satu nilai non-null untuk kolom ACCOUNT_NAME, dan ACCOUNT_TYPE.

Implementasi perangkat:

• [C-SR-1] SANGAT DIREKOMENDASIKAN 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 dari akun lokal kustom HARUS ditampilkan oleh ContactsContract.RawContacts.getLocalAccountType
• [C-1-3] Kontak mentah yang disisipkan oleh aplikasi pihak ketiga dengan akun lokal default (yaitu, dengan menetapkan nilai null untuk ACCOUNT_NAME dan ACCOUNT_TYPE) HARUS disisipkan ke 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 mengakibatkan kontak mentah langsung dihapus permanen (seolah-olah parameter CALLER_IS_SYNCADAPTER disetel ke true), meskipun parameter CALLER\_IS\_SYNCADAPTER ditetapkan ke salah (false) atau tidak ditentukan.

4. Kompatibilitas Pengemasan Aplikasi

Implementasi perangkat:

• [C-0-1] HARUS dapat menginstal dan menjalankan file ".apk" Android seperti yang dihasilkan oleh alat "aapt" yang disertakan dalam Android SDK resmi.

  • Karena persyaratan di atas mungkin sulit, implementasi perangkat DIREKOMENDASIKAN untuk menggunakan sistem pengelolaan paket implementasi referensi AOSP.

• [C-0-2] HARUS mendukung verifikasi file ".apk" menggunakan APK Signature Scheme v3.1, APK Signature Scheme v3, APK Signature Scheme v2, dan penandatanganan JAR.

• [C-0-3] TIDAK BOLEH memperluas format .apk, Manifes Android, Dalvik bytecode, atau byte RenderScript sedemikian rupa sehingga akan mencegah file tersebut diinstal dan berjalan dengan benar di perangkat lain yang kompatibel.

• [C-0-4] TIDAK BOLEH mengizinkan aplikasi selain "installer data" saat ini agar paket dapat meng-uninstal aplikasi secara otomatis tanpa konfirmasi pengguna, seperti yang didokumentasikan di SDK untuk izin DELETE_PACKAGE. Satu-satunya pengecualian adalah intent pemverifikasi paket sistem yang menangani intent PACKAGE_NEEDS_VERIFICATION dan intent penanganan aplikasi pengelola penyimpanan aplikasi 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:

  • Aplikasi HARUS mendeklarasikan izin REQUEST_INSTALL_PACKAGES atau menyetel android:targetSdkVersion ke 24 atau lebih rendah.
  • Aplikasi HARUS diberi izin oleh pengguna untuk menginstal aplikasi dari sumber tidak dikenal.

• HARUS menyediakan kemampuan pengguna untuk memberikan/mencabut izin penginstalan aplikasi dari sumber tidak dikenal per aplikasi, tetapi DAPAT memilih untuk menerapkannya sebagai tanpa pengoperasian dan menampilkan RESULT_CANCELED untuk startActivityForResult(), jika implementasi perangkat tidak ingin memungkinkan pengguna memiliki pilihan ini. Namun, meskipun dalam kasus tersebut, nilai tersebut HARUS menunjukkan kepada pengguna mengapa tidak ada pilihan tersebut yang ditampilkan.

• [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 yang sama PackageManager.setHarmfulAppWarning sebagai berpotensi berbahaya.

• HARUS menyediakan kemampuan pengguna untuk memilih meng-uninstal atau meluncurkan aplikasi pada dialog peringatan.

• [C-0-8] HARUS mengimplementasikan dukungan untuk Sistem File Inkremental 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 container yang ditentukan di bagian 5.1 untuk setiap codec yang dideklarasikan oleh MediaCodecList.
• [C-0-2] HARUS mendeklarasikan dan melaporkan dukungan encoder, decoder yang tersedia untuk aplikasi pihak ketiga melalui MediaCodecList.
• [C-0-3] HARUS dapat mendekode dengan benar dan menyediakan semua format yang dapat dienkode oleh aplikasi pihak ketiga. Ini mencakup semua bitstream yang dihasilkan encoder-nya dan profil yang dilaporkan dalam CamcorderProfile-nya.

Implementasi perangkat:

• HARUS menargetkan latensi codec minimum, dengan kata lain,
  • TIDAK BOLEH menggunakan dan menyimpan buffer input, dan menampilkan buffer input hanya setelah diproses.
  • TIDAK BOLEH menyimpan buffer hasil dekode lebih lama dari yang ditentukan oleh standar (mis. SPS).
  • TIDAK BOLEH mempertahankan buffer yang dienkode dengan waktu lebih lama dari yang dibutuhkan oleh struktur GOP.

Semua codec yang tercantum di bagian di bawah ini disediakan sebagai implementasi software dalam implementasi Android pilihan dari Project Open Source Android.

Perlu diketahui bahwa baik Google maupun Open Handset Alliance tidak membuat pernyataan apa pun bahwa codec ini bebas dari paten pihak ketiga. Mereka yang ingin 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, implementasi perangkat 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 PCM 16-bit melalui android.media.MediaCodec API.

5.1.2 Dekode Audio

Lihat detail selengkapnya di 5.1.3. Detail Codec Audio.

Jika implementasi perangkat mendeklarasikan dukungan untuk fitur android.hardware.audio.output, implementasi tersebut harus mendukung dekode 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 (Peningkatan AAC+)
• [C-1-4] AAC ELD (Peningkatan AAC penundaan rendah)
• [C-1-11] xHE-AAC (Profil Kontrol Extended HE ISO/IEC 23003-3, yang mencakup Profil Dasar Pengukuran USAC, dan Profil Kontrol Rentang Dinamis ISO/IEC 23003-4)
• [C-1-5] FLAC
• [C-1-6] MP3
• MIDI [C-1-7]
• [C-1-8] Vorbis
• [C-1-9] PCM/WAVE termasuk format audio resolusi tinggi hingga 24 bit, frekuensi sampel 192 kHz, dan 8 saluran. Perhatikan bahwa persyaratan ini hanya untuk decoding, dan bahwa perangkat diizinkan untuk melakukan downsampling dan downmix selama fase pemutaran.
• [C-1-10] Opus

Jika implementasi perangkat mendukung dekode buffer input AAC pada streaming multisaluran (yaitu lebih dari dua saluran) ke PCM melalui dekoder audio AAC default di android.media.MediaCodec API, hal berikut HARUS didukung:

• [C-2-1] Decoding HARUS dilakukan tanpa downmixing (misalnya streaming 5.0 AAC harus didekode ke lima saluran PCM, streaming 5.1 AAC harus didekode ke enam saluran PCM).
• [C-2-2] Metadata rentang dinamis HARUS seperti yang ditentukan dalam "Dynamic Range Control (DRC)" dalam ISO/IEC 14496-3, dan kunci DRC android.media.MediaFormat untuk mengonfigurasi perilaku terkait rentang dinamis dari 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 DIREKOMENDASIKAN bahwa persyaratan C-2-1 dan C-2-2 di atas dipenuhi oleh semua decoder audio AAC.

Saat mendekode audio USAC, MPEG-D (ISO/IEC 23003-4):

• [C-3-1] Metadata DRC dan Loudness HARUS ditafsirkan dan diterapkan sesuai dengan Profil Kontrol Rentang Dinamis DRC MPEG-D Level 1.
• [C-3-2] Decoder 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:

• Mungkin mendukung kontrol kenyaringan dan rentang dinamis 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 AKAN diutamakan.

Semua dekoder audio HARUS mendukung pembuatan output:

• [C-6-1] Frame audio urutan byte native PCM 16-bit melalui android.media.MediaCodec API.

Jika implementasi perangkat mendukung dekode buffer input AAC pada streaming multisaluran (yaitu lebih dari dua saluran) ke PCM melalui dekoder audio AAC default di android.media.MediaCodec API, berikut ini 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 menjadi output menggunakan jumlah saluran native (jika menggunakan nilai yang sama atau lebih besar untuk angka tersebut). Misalnya, nilai 6 atau lebih besar akan mengonfigurasi decoder untuk menghasilkan 6 saluran saat memasukkan konten 5.1.
• [C-7-2] Saat melakukan dekode, decoder HARUS mengiklankan mask saluran yang digunakan pada format output dengan kunci KEY_CHANNEL_MASK, menggunakan konstanta android.media.AudioFormat (contoh: CHANNEL_OUT_5POINT1).

Jika implementasi perangkat mendukung dekoder audio selain decoder audio AAC default dan mampu menghasilkan output audio multi-channel (yaitu lebih dari 2 saluran) saat memasukkan konten multi-saluran yang dikompresi, maka:

• [C-SR-2] Decoder SANGAT DIREKOMENDASIKAN 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 merupakan output menggunakan jumlah saluran native (saat menggunakan nilai yang sama atau lebih besar dari angka tersebut). Misalnya, nilai 6 atau lebih besar akan mengonfigurasi decoder untuk menghasilkan 6 saluran saat memasukkan konten 5.1.
• [C-SR-3] Saat melakukan dekode, decoder SANGAT DIREKOMENDASIKAN untuk memberitahukan mask 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

Format/Codec	Detail	Jenis File/Format Penampung yang akan didukung
Profil AAC MPEG-4 (AAC LC)	Dukungan untuk konten mono/stereo/5.0/5.1 dengan frekuensi pengambilan sampel standar dari 8 hingga 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS AAC mentah (.aac, ADIF tidak didukung) MPEG-TS (.ts, tidak dapat dicari, hanya dekode) Matroska (.mkv, khusus dekode)
Profil MPEG-4 HE AAC (AAC+)	Dukungan untuk konten mono/stereo/5.0/5.1 dengan frekuensi pengambilan sampel standar dari 16 hingga 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
MPEG-4 HE AACv2 Profil (AAC+ yang ditingkatkan)	Dukungan untuk konten mono/stereo/5.0/5.1 dengan frekuensi pengambilan sampel standar dari 16 hingga 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
AAC ELD (AAC yang ditingkatkan dengan delay rendah)	Dukungan untuk konten mono/stereo dengan frekuensi pengambilan sampel standar dari 16 hingga 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
Amerika Serikat (ASC)	Dukungan untuk konten mono/stereo dengan frekuensi pengambilan sampel standar dari 7,35 hingga 48 kHz.	MPEG-4 (.mp4, .m4a)
AMR-NB	4,75 hingga 12,2 kbps dengan sampel @ 8 kHz	3GPP (.3gp)
AMR-WB	9 kecepatan mulai dari 6,60 kbit/dtk hingga 23,85 kbit/dtk dengan sampel @ 16 kHz, sebagaimana didefinisikan pada AMR-WB, Adaptive Multi-Rate - Codec Ucapan Wideband	3GPP (.3gp)
FLAC	Untuk encoder dan decoder: setidaknya mode Mono dan Stereo HARUS didukung. Frekuensi sampel hingga 192 kHz HARUS didukung; resolusi 16-bit dan 24-bit HARUS didukung. Penanganan data audio FLAC 24-bit HARUS tersedia dengan konfigurasi audio floating point.	FLAC (.flac) MPEG-4 (hanya .mp4, .m4a, dekode) Matroska (.mkv, khusus dekode)
MP3	Konstan Mono/Stereo 8-320 Kbps (CBR) atau kecepatan bit variabel (VBR)	MP3 (.mp3) MPEG-4 (hanya .mp4, .m4a, dekode) Matroska (.mkv, khusus dekode)
MIDI	MIDI Jenis 0 dan 1. DLS Versi 1 dan 2. XMF dan Mobile XMF. Dukungan untuk format nada dering RTTTL/RTX, OTA, dan iMelody	Ketik 0 dan 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) iMelody (.imy)
Vorbis		Ogg (.ogg) MPEG-4 (hanya .mp4, .m4a, dekode) Matroska (.mkv) Webm (.webm)
PCM/WAVE	Codec PCM HARUS mendukung PCM linear 16-bit dan float 16-bit. Ekstraktor WAVE harus mendukung PCM linear 16-bit, 24-bit, 32-bit, dan float 32-bit (frekuensi hingga batas hardware). Frekuensi pengambilan sampel HARUS didukung dari 8 kHz hingga 192 kHz.	WAVE (.wav)
Opus	Decoding: Dukungan untuk konten mono, stereo, 5.0, dan 5.1 dengan frekuensi sampling 8000, 12000, 16000, 24000, dan 48.000 Hz. Encoding: Dukungan untuk konten mono dan stereo dengan frekuensi pengambilan sampel 8000, 12000, dan 16000 Hz	Ogg (.ogg) MPEG-4 (hanya .mp4, .m4a, dekode) Matroska (.mkv) Webm (.webm)

5.1.4 Encoding Gambar

Lihat detail selengkapnya di 5.1.6. Detail Codec Gambar.

Implementasi perangkat HARUS mendukung encoding encoding gambar berikut:

• [C-0-1] JPEG
• [C-0-2] PNG
• [C-0-3] WebP

Jika implementasi perangkat mendukung encoding HEIC melalui android.media.MediaCodec untuk jenis media MIMETYPE_IMAGE_ANDROID_HEIC, implementasi tersebut:

• [C-1-1] HARUS menyediakan codec encoder HEVC dengan akselerasi hardware yang mendukung mode kontrol kecepatan bit 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.

Implementasi 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] Mentah
• [C-0-7] AVIF (Profil Dasar Pengukuran)

Jika implementasi perangkat mendukung decoding video HEVC, implementasi tersebut: * [C-1-1] HARUS mendukung decoding gambar HEIF (HEIC).

Decoder gambar yang mendukung format kedalaman bit tinggi (9+ bit per saluran):

• [C-2-1] HARUS mendukung output format setara 8-bit jika diminta oleh aplikasi, misalnya, melalui konfigurasi ARGB_8888 dari 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)	Gambar, Pengumpulan gambar, Profil Dasar Pengukuran Urutan gambar	Penampung 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) hingga CodecCapabilities.

• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung format warna RGB888 untuk mode Platform input.

• [C-1-3] HARUS mendukung setidaknya salah satu format warna planar atau semiplanar YUV420 8:8:8: COLOR_FormatYUV420PackedPlanar (setara dengan COLOR_FormatYUV420Planar) atau COLOR_FormatYUV420PackedSemiPlanar (setara dengan COLOR_FormatYUV420SemiPlanar). Keduanya REKOMENDASI 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 menyertakan dekoder video atau encoder:

• [C-1-1] Codec video HARUS mendukung ukuran bytebuffer output dan input yang mengakomodasi frame terbesar yang dikompresi dan tidak dikompresi sebagaimana ditentukan oleh standar dan konfigurasi, tetapi juga tidak dialokasikan secara berlebihan.

• [C-1-2] Encoder dan decoder video HARUS mendukung format warna fleksibel YUV420 8:8:8 (COLOR_FormatYUV420Flexible) hingga CodecCapabilities.

• [C-1-3] Encoder dan decoder video HARUS mendukung setidaknya salah satu format warna planar atau semiplanar YUV420 8:8:8: COLOR_FormatYUV420PackedPlanar (setara dengan COLOR_FormatYUV420Planar) atau COLOR_FormatYUV420PackedSemiPlanar (setara dengan COLOR_FormatYUV420SemiPlanar). Mereka SANGAT DIREKOMENDASIKAN untuk mendukung keduanya.

• [C-SR-1] Encoder dan decoder video SANGAT DIREKOMENDASIKAN untuk mendukung setidaknya salah satu format warna planar atau semiplanar YUV420 8:8:8 yang dioptimalkan dengan hardware (YV12, NV12, NV21, atau format yang dioptimalkan vendor yang setara.)

• [C-1-5] Decoder video yang mendukung format kedalaman bit tinggi (9+ bit per saluran) HARUS mendukung output format setara 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, implementasi tersebut:

• [C-2-1] HARUS mendukung penguraian dan penanganan metadata statis HDR.

Jika implementasi perangkat mengiklankan dukungan refresh intra melalui FEATURE_IntraRefresh di class MediaCodecInfo.CodecCapabilities, implementasi tersebut:

• [C-3-1] HARUS mendukung periode refresh dalam rentang 10 - 60 frame dan beroperasi secara akurat dalam 20% periode refresh yang dikonfigurasi.

Kecuali jika aplikasi menentukan sebaliknya menggunakan kunci format KEY_COLOR_FORMAT, penerapan decoder video:

• [C-4-1] HARUS ditetapkan secara default ke format warna yang dioptimalkan untuk tampilan hardware jika dikonfigurasi menggunakan output Surface.
• [C-4-2] HARUS default ke format warna YUV420 8:8:8 yang dioptimalkan untuk pembacaan CPU jika dikonfigurasi agar 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, khusus dekode)
AVC H.264	Lihat bagian 5.2 dan 5.3 untuk mengetahui detailnya	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, tidak dapat dicari) Matroska (.mkv, khusus dekode)
H.265 HEVC	Lihat bagian 5.3 untuk mengetahui detailnya	MPEG-4 (.mp4) Matroska (.mkv, khusus dekode)
MPEG-2	Profil Utama	MPEG2-TS (.ts, tidak dapat dicari) MPEG-4 (.mp4, dekode saja) Matroska (.mkv, khusus dekode)
MPEG-4 SP		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, khusus dekode)
VP8	Lihat bagian 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 bagian 5.2 dan bagian 5.3 untuk detailnya	MPEG-4 (.mp4) Matroska (.mkv, khusus dekode)

5.1.9 Keamanan Codec Media

Implementasi perangkat HARUS memastikan kepatuhan terhadap fitur keamanan codec media seperti yang dijelaskan di bawah ini.

Android menyertakan dukungan untuk OMX, API akselerasi multimedia lintas platform, serta Codec 2.0, API akselerasi multimedia dengan overhead rendah.

Jika implementasi perangkat mendukung multimedia, implementasi tersebut:

• [C-1-1] HARUS memberikan dukungan untuk codec media baik melalui OMX atau Codec 2.0 API (atau keduanya) seperti dalam Proyek Open Source Android dan tidak menonaktifkan atau mengakali perlindungan keamanan. Secara khusus, hal ini tidak berarti bahwa setiap codec HARUS menggunakan OMX atau Codec 2.0 API, hanya dukungan tersebut untuk setidaknya salah satu API ini HARUS tersedia, dan dukungan untuk API yang tersedia HARUS mencakup perlindungan keamanan yang ada.
• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menyertakan dukungan bagi Codec 2.0 API.

Jika implementasi perangkat tidak mendukung Codec 2.0 API, implementasi tersebut:

• [C-2-1] HARUS menyertakan codec software OMX yang sesuai dari Project Open Source Android (jika tersedia) untuk setiap format dan jenis media (encoder atau decoder) yang didukung oleh perangkat.
• [C-2-2] Codec yang memiliki nama dimulai dengan "OMX.google." HARUS didasarkan pada kode sumber Project Open Source Android.
• [C-SR-2] SANGAT DIREKOMENDASIKAN bahwa codec software OMX berjalan dalam proses codec yang tidak memiliki akses ke driver hardware selain mapper memori.

Jika implementasi perangkat mendukung Codec 2.0 API, implementasi tersebut:

• [C-3-1] HARUS menyertakan codec software Codec 2.0 yang sesuai dari Project Open Source Android (jika tersedia) untuk setiap format dan jenis media (encoder atau decoder) yang didukung oleh perangkat.
• [C-3-2] HARUS menyimpan codec software Codec 2.0 dalam proses codec software seperti yang disediakan dalam Project Open Source Android untuk memungkinkan memberikan akses secara lebih sempit ke codec software.
• [C-3-3] Codec yang memiliki nama dimulai dengan "c2.android." HARUS didasarkan pada kode sumber Project Open Source Android.

5.1.10. Karakteristik Codec Media

Jika implementasi perangkat mendukung codec media, implementasi tersebut:

• [C-1-1] HARUS menampilkan nilai karakterisasi codec media yang benar melalui MediaCodecInfo API.

Khususnya:

• [C-1-2] Codec dengan nama yang dimulai dengan "OMX". HARUS menggunakan API OMX dan memiliki nama yang sesuai dengan panduan penamaan OMX IL.
• [C-1-3] Codec dengan nama yang dimulai 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 dimulai dengan "OMX.google." atau "c2.android." TIDAK BOLEH dicirikan sebagai vendor atau sebagai berakselerasi hardware.
• [C-1-5] Codec yang berjalan dalam proses codec (vendor atau sistem) yang memiliki akses ke driver hardware selain alokator memori dan mapper TIDAK BOLEH dicirikan sebagai khusus software.
• [C-1-6] Codec yang tidak ada dalam Project Open Source Android atau tidak didasarkan pada kode sumber dalam project tersebut HARUS ditandai 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 dekode, dan yang bernama "encoder" HARUS mendukung encoding. Codec dengan nama yang berisi format media HARUS mendukung format tersebut.

Jika implementasi 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 piksel (H263, MPEG2, MPEG4) 352 x 288 piksel (encoder MPEG4, H263, MPEG2) 320 x 180 piksel (VP8, VP8) 320 x 240 piksel (lainnya)	704 x 576 piksel (H263) 640 x 360 piksel (VP8, VP9) 640 x 480 piksel (encoder MPEG4) 720 x 480 piksel (lainnya, AV1)	1408 x 1152 piksel (H263) 1280 x 720 piksel (lainnya, AV1)	1920 x 1080 piksel (selain MPEG4, AV1)	3840 x 2160 piksel (HEVC, VP9, AV1)

• [C-2-2] Codec video yang ditandai sebagai akselerasi hardware HARUS memublikasikan informasi poin performa. Setiap kolom HARUS mencantumkan semua poin performa standar yang didukung (tercantum dalam PerformancePoint API), kecuali jika poin tersebut tercakup dalam poin performa standar lain yang didukung.
• Selain itu, opsi ini HARUS memublikasikan poin performa tambahan jika mendukung performa video berkelanjutan selain salah satu yang tercantum.

5.2. Encoding Video

Jika implementasi perangkat menyertakan tampilan layar tersemat dengan panjang diagonal minimal 2,5 inci atau menyertakan port output video atau mendeklarasikan dukungan kamera melalui tombol fitur android.hardware.camera.any, implementasi tersebut:

• [C-1-1] HARUS menyertakan dukungan dari minimal satu encoder video VP8 atau H.264, dan menyediakannya untuk aplikasi pihak ketiga.
• HARUS mendukung encoder video VP8 dan H.264, dan menyediakannya untuk aplikasi pihak ketiga.

Jika implementasi perangkat mendukung encoder video H.264, VP8, VP9, atau HEVC yang mana pun dan menyediakannya untuk aplikasi pihak ketiga, implementasi tersebut:

• [C-2-1] HARUS mendukung kecepatan bit yang dapat dikonfigurasi secara dinamis.
• HARUS mendukung kecepatan frame variabel, yang mana encoder video HARUS menentukan durasi frame instan berdasarkan stempel waktu buffer input, dan alokasikan bucket bit-nya berdasarkan durasi frame tersebut.

Jika implementasi perangkat mendukung encoder video MPEG-4 SP dan menyediakannya untuk aplikasi pihak ketiga, implementasi tersebut:

• HARUS mendukung kecepatan bit yang dapat dikonfigurasi secara dinamis untuk encoder yang didukung.

Jika implementasi perangkat menyediakan encoder video atau gambar dengan akselerasi hardware, dan mendukung satu atau beberapa kamera hardware yang terpasang atau dapat dicolokkan melalui API android.camera:

• [C-4-1] Semua encoder video dan gambar dengan akselerasi hardware HARUS mendukung encoding frame dari kamera hardware.
• HARUS mendukung frame encoding dari kamera hardware melalui semua encoder video atau gambar.

Jika implementasi perangkat menyediakan encoding HDR, implementasi tersebut:

• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menyediakan plugin bagi transcoding API 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, implementasi tersebut:

• [C-1-1] HARUS mendukung resolusi QCIF (176 x 144) menggunakan Profil Dasar Pengukuran Level 45. Resolusi SQCIF bersifat opsional.
• HARUS mendukung kecepatan bit yang dapat dikonfigurasi secara dinamis untuk encoder yang didukung.

5.2.2. H.264

Jika implementasi perangkat mendukung codec H.264, implementasi tersebut:

• [C-1-1] HARUS mendukung Profil Dasar Pengukuran Level 3. Namun, dukungan untuk ASO (Pemesanan Slice Arbitrer), FMO (Pengurutan Macroblock Fleksibel), dan RS (Slice Redundan) bersifat OPSIONAL. Selain itu, untuk mempertahankan kompatibilitas dengan perangkat Android lain, DIREKOMENDASIKAN bahwa ASO, FMO, dan RS tidak digunakan untuk Profil Dasar Pengukuran oleh encoder.
• [C-1-2] HARUS mendukung profil encoding video SD (Definisi Standar) dalam tabel berikut.
• HARUS mendukung Profil Utama Level 4.
• HARUS mendukung profil encoding video HD (Definisi Tinggi) seperti yang ditunjukkan dalam tabel berikut.

Jika implementasi perangkat melaporkan dukungan encoding H.264 untuk video beresolusi 720p atau 1080p melalui API media, implementasi tersebut:

• [C-2-1] HARUS mendukung profil encoding dalam tabel berikut.

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

5.2.3. VP8

Jika implementasi perangkat mendukung codec VP8, implementasi tersebut:

• [C-1-1] HARUS mendukung profil encoding video SD.
• HARUS mendukung profil encoding video HD (Definisi Tinggi) berikut.
• [C-1-2] HARUS mendukung penulisan file Matroska WebM.
• 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 implementasi perangkat melaporkan dukungan encoding VP8 untuk video resolusi 720p atau 1080p melalui API media, implementasi tersebut:

• [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 implementasi perangkat mendukung codec VP9, implementasi tersebut:

• [C-1-2] HARUS mendukung Profil 0 Level 3.
• [C-1-1] HARUS mendukung penulisan file Matroska WebM.
• [C-1-3] HARUS menghasilkan data CodecPrivate.
• HARUS mendukung profil decoding HD seperti yang ditunjukkan dalam tabel berikut.
• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung profil decoding HD seperti yang ditunjukkan dalam tabel berikut jika terdapat encoder hardware.

	SD	HD 720p	HD 1080p	UHD
Resolusi video	720x480 piksel	1280 x 720 px	1920 x 1080 px	3840x2160 piksel
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 implementasi perangkat mendukung codec H.265, implementasi tersebut:

• [C-1-1] HARUS mendukung Profil Utama Level 3 hingga resolusi 512 x 512.
• HARUS mendukung profil encoding HD seperti yang ditunjukkan dalam tabel berikut.
• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung profil SD 720 x 480 dan profil encoding HD seperti yang ditunjukkan pada tabel berikut jika terdapat encode hardware.

	SD	HD 720p	HD 1080p	UHD
Resolusi video	720x480 piksel	1280 x 720 px	1920 x 1080 px	3840x2160 piksel
Frekuensi gambar video	30 fps	30 fps	30 fps	30 fps
Kecepatan bit video	1,6 Mbps	4 Mbps	5 Mbps	20 Mbps

5.3. Dekode Video

Jika implementasi perangkat mendukung codec VP8, VP9, H.264, atau H.265, implementasi tersebut:

• [C-1-1] HARUS mendukung resolusi video dinamis dan pengalihan kecepatan frame melalui API Android standar dalam streaming yang sama untuk semua codec VP8, VP9, H.264, dan H.265 secara real time dan hingga resolusi maksimum yang didukung oleh setiap codec pada perangkat.

5.3.1 MPEG-2

Jika implementasi perangkat mendukung decoder MPEG-2, implementasi tersebut:

• [C-1-1] HARUS mendukung Tingkat Tinggi Profil Utama.

5.3.2 H.263

Jika implementasi perangkat mendukung decoder H.263, implementasi tersebut:

• [C-1-1] HARUS mendukung Profil Dasar Pengukuran Level 30 (resolusi CIF, QCIF, dan SQCIF @ 30fps 384 kbps) dan Level 45 (resolusi QCIF dan SQCIF @ 30 fps 128 kbps).

5.3.3. MPEG-4

Jika implementasi perangkat dengan decoder MPEG-4, implementasi tersebut:

• [C-1-1] HARUS mendukung Simple Profile Level 3.

5.3.4. H.264

Jika implementasi perangkat mendukung decoder H.264, implementasi tersebut:

• [C-1-1] HARUS mendukung Profil Utama Level 3.1 dan Profil Dasar Pengukuran. Dukungan untuk ASO (Pemesanan Slice Arbitrer), FMO (Pengurutan Macroblock Fleksibel), dan RS (Slice Redundan) bersifat OPSIONAL.
• [C-1-2] HARUS mampu mendekode video dengan profil SD (Definisi Standar) yang tercantum dalam tabel berikut dan dienkode dengan Profil Dasar Pengukuran dan Profil Utama Level 3.1 (termasuk 720p30).
• HARUS dapat mendekode video dengan profil HD (Definisi Tinggi) seperti yang ditunjukkan dalam tabel berikut.

Jika tinggi yang dilaporkan oleh metode Display.getSupportedModes() sama 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	320x240 piksel	720x480 piksel	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 implementasi perangkat mendukung codec H.265, implementasi 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 decoding HD seperti yang ditunjukkan dalam tabel berikut jika ada decoder hardware.

Jika tinggi yang dilaporkan oleh metode Display.getSupportedModes() sama dengan atau lebih besar dari resolusi video, maka:

• [C-2-1] Implementasi perangkat HARUS mendukung setidaknya satu decoding H.265 atau VP9 untuk 720, 1080, dan profil UHD.

	SD (Kualitas rendah)	SD (Kualitas tinggi)	HD 720p	HD 1080p	UHD
Resolusi video	352 x 288 piksel	720x480 piksel	1280 x 720 px	1920 x 1080 px	3840x2160 piksel
Frekuensi gambar video	30 fps	30 fps	30 fps	30/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 container.
• [C-3-2] Implementasi perangkat HARUS menampilkan konten HDR dengan benar pada layar perangkat atau pada port output video standar (mis., HDMI).

5.3.6. VP8

Jika implementasi perangkat mendukung codec VP8, implementasi tersebut:

• [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 seperti yang dilaporkan oleh metode Display.getSupportedModes() sama 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 implementasi perangkat mendukung codec VP9, implementasi 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 implementasi perangkat mendukung codec VP9 dan decoder hardware:

• [C-2-1] HARUS mendukung profil decoding 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] Implementasi perangkat HARUS mendukung setidaknya satu dekode VP9 atau H.265 untuk 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	3840x2160 piksel
Frekuensi gambar video	30 fps	30 fps	30 fps	30 fps (60 fpsTelevisi dengan decoding 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. Modul ini 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 pada layar perangkat atau pada port output video standar (mis., HDMI).

5.3.8. Dolby Vision

Jika implementasi perangkat mendeklarasikan dukungan untuk decoder Dolby Vision melalui HDR_TYPE_DOLBY_VISION , implementasi tersebut:

• [C-1-1] HARUS menyediakan ekstraktor berkemampuan Dolby Vision.
• [C-1-2] HARUS menampilkan konten Dolby Vision dengan benar di layar perangkat atau di port output video standar (mis., HDMI).
• [C-1-3] HARUS menyetel ID trek dari lapisan dasar yang kompatibel dengan versi lama (jika ada) agar sama dengan ID trek lapisan Dolby Vision gabungan.

5.3.9. AV1

5.4 Perekaman Audio

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

5.4.1. Informasi Mikrofon dan Pengambilan Audio Mentah

Jika implementasi perangkat mendeklarasikan android.hardware.microphone, implementasi tersebut:

• [C-1-1] HARUS mengizinkan perekaman konten audio mentah untuk streaming AudioRecord atau AAudio INPUT yang berhasil dibuka. Paling tidak, karakteristik berikut HARUS didukung:

  • Format: PCM Linear, 16-bit
  • Frekuensi pengambilan sampel: 8000, 11025, 16000, 44100, 48000 Hz
  • Saluran: 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 pengambilan sampel: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 Hz
  • Saluran: Sebanyak saluran sebanyak jumlah mikrofon di perangkat

• [C-1-2] HARUS mengambil sampel dengan frekuensi sampel di atas tanpa up-sampling.

• [C-1-3] HARUS menyertakan filter anti-aliasing yang sesuai saat frekuensi sampel yang diberikan di atas ditangkap dengan down-sampling.

• HARUS mengizinkan pengambilan gambar konten audio mentah dengan kualitas radio AM dan DVD, yang memiliki karakteristik berikut:

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

• [C-1-4] HARUS mematuhi MicrophoneInfo API dan mengisi informasi dengan benar untuk mikrofon yang tersedia di perangkat yang dapat diakses oleh aplikasi pihak ketiga melalui AudioManager.getMicrophones() API, untuk AudioRecord aktif yang menggunakan MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED, atau VOICE_PERFORMANCE. Jika implementasi perangkat memungkinkan perekaman kualitas radio AM dan DVD dari konten audio mentah, implementasi tersebut:

• [C-2-1] HARUS mengambil pengambilan tanpa up-sampling pada rasio apa pun yang lebih tinggi dari 16000:22050 atau 44100:48000.

• [C-2-2] HARUS menyertakan filter anti-aliasing yang sesuai untuk setiap up-sampling atau down-sampling.

5.4.2. Ambil foto untuk Pengenalan Suara

Jika implementasi perangkat mendeklarasikan android.hardware.microphone, implementasi tersebut:

• [C-1-1] HARUS mengambil sumber audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION di salah satu frekuensi pengambilan sampel, 44100 dan 48000.
• [C-1-2] Secara default, HARUS menonaktifkan pemrosesan audio pengurangan derau saat merekam streaming audio dari sumber audio AudioSource.VOICE_RECOGNITION.

• [C-1-3] Secara default, HARUS menonaktifkan semua 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 menengah: khususnya ±3 dB dari 100 Hz hingga 4.000 Hz untuk setiap dan setiap mikrofon yang digunakan untuk merekam sumber audio pengenalan suara.

• [C-SR-1] SANGAT DIREKOMENDASIKAN 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 DIREKOMENDASIKAN untuk menunjukkan tingkat amplitudo dalam rentang frekuensi tinggi: khususnya dari ±30 dB dari 4.000 Hz hingga 22 KHz dibandingkan dengan rentang frekuensi menengah untuk setiap mikrofon yang digunakan untuk merekam sumber audio pengenalan suara.

• ±BUSAT menyetel sensitivitas input audio sehingga sumber nada sinusoidal 1.000 Hz diputar pada 90 dB Tingkat Tekanan Suara (SPL) (diukur pada jarak 30 cm dari di samping mikrofon) menghasilkan respons ideal RMS 2500 dalam rentang 1770 dan 13530 sampel audio mengambang-2 untuk

• HARUS merekam streaming audio pengenalan suara sehingga tingkat amplitudo PCM melacak perubahan SPL input secara linear, minimal dalam rentang 30 dB dari -18 dB ke +12 dB untuk 90 dB SPL di mikrofon.

• HARUS merekam streaming audio pengenalan suara dengan total harmonic distortion (THD) kurang dari 1% untuk 1 kHz pada level input SPL 90 dB di mikrofon.

Jika implementasi perangkat mendeklarasikan android.hardware.microphone dan teknologi peredam bising (pengurangan) yang disesuaikan untuk pengenalan ucapan, implementasi tersebut akan:

• [C-2-1] HARUS mengizinkan efek audio ini untuk dapat dikontrol dengan android.media.audiofx.NoiseSuppressor API.
• [C-2-2] HARUS secara unik mengidentifikasi setiap implementasi teknologi peredam bising melalui kolom AudioEffect.Descriptor.uuid.

5.4.3. Ambil untuk Mengubah Rute Pemutaran

Class android.media.MediaRecorder.AudioSource menyertakan sumber audio REMOTE_SUBMIX.

Jika implementasi perangkat mendeklarasikan android.hardware.audio.output dan android.hardware.microphone, implementasi tersebut:

• [C-1-1] HARUS mengimplementasikan sumber audio REMOTE_SUBMIX dengan benar sehingga saat menggunakan android.media.AudioRecord API untuk merekam dari sumber audio ini, aplikasi akan merekam campuran semua streaming audio kecuali:

  • 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 mengimplementasikan teknologi Acoustic Echo Canceler (AEC) yang disetel untuk komunikasi suara dan diterapkan ke jalur pengambilan saat merekam menggunakan AudioSource.VOICE_COMMUNICATION.

Jika implementasi perangkat menyediakan Acoustic Echo Canceler yang disisipkan di jalur audio perekaman saat AudioSource.VOICE_COMMUNICATION dipilih, implementasi tersebut:

• [C-SR-1] SANGAT_DIREKOMENDASIKAN untuk mendeklarasikan hal ini melalui metode API AcousticEchoCanceler AcousticEchoCanceler.isAvailable()
• [C-SR-2] STRONGLY_RECOMMENDED untuk memungkinkan efek audio ini dapat dikontrol dengan AcousticEchoCanceler API.
• [C-SR-3] SANGAT_DIREKOMENDASIKAN untuk mengidentifikasi setiap implementasi teknologi AEC secara unik melalui kolom AudioEffect.Descriptor.uuid.

5.4.5. Pengambilan Serentak

Jika implementasi perangkat mendeklarasikan android.hardware.microphone,implementasi tersebut HARUS mengimplementasikan pengambilan serentak seperti yang dijelaskan dalam dokumen ini. Khususnya:

• [C-1-1] HARUS mengizinkan akses serentak ke mikrofon oleh pengambilan layanan aksesibilitas menggunakan AudioSource.VOICE_RECOGNITION dan setidaknya satu perekaman aplikasi dengan AudioSource.
• [C-1-2] HARUS mengizinkan akses serentak ke mikrofon oleh aplikasi bawaan yang memiliki peran Asisten dan setidaknya satu aplikasi yang menangkap dengan AudioSource apa pun kecuali untuk AudioSource.VOICE_COMMUNICATION atau AudioSource.CAMCORDER.
• [C-1-3] HARUS menonaktifkan 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 dengan hak istimewa (sudah diinstal sebelumnya) dengan izin CAPTURE_AUDIO_OUTPUT.
• [C-1-4] Jika dua atau beberapa aplikasi melakukan perekaman secara serentak dan jika tidak ada aplikasi yang memiliki UI di atasnya, aplikasi yang mulai merekam aplikasi yang terakhir menerima audio.

5.5. Pemutaran Audio

Android menyertakan dukungan yang memungkinkan aplikasi memutar audio melalui periferal output audio seperti yang ditentukan dalam bagian 7.8.2.

5.5.1 Pemutaran Audio Raw

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: Konfigurasi multisaluran, Stereo, Mono, yang valid dengan maksimal 8 saluran
  • Frekuensi pengambilan sampel (dalam Hz):
    • 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 pada konfigurasi saluran yang tercantum di atas
    • 96.000 dalam mono dan stereo

5.5.2. Efek Audio

Android menyediakan API untuk efek audio untuk implementasi perangkat.

Jika implementasi perangkat mendeklarasikan fitur android.hardware.audio.output, implementasi perangkat akan:

• [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 implementasi visualizer API, yang dapat dikontrol melalui class Visualizer.
• [C-1-3] HARUS mendukung implementasi EFFECT_TYPE_DYNAMICS_PROCESSING yang dapat dikontrol melalui subclass AudioEffect DynamicsProcessing.

• HARUS mendukung implementasi EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB, dan EFFECT_TYPE_VIRTUALIZER yang dapat dikontrol melalui sub-class AudioEffect BassBoost, EnvironmentalReverb, PresetReverb, dan Virtualizer.
• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung efek dalam floating point dan multisaluran.

5.5.3. Volume Output Audio

Implementasi perangkat otomotif:

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

5.5.4. Offload Audio

Jika implementasi perangkat mendukung pemutaran pengurangan beban audio, implementasi tersebut:

• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk memangkas konten audio tanpa jeda yang diputar antara dua klip dengan format yang sama jika ditentukan oleh AudioTrack gapless API dan penampung media untuk MediaPlayer.

5.6. Latensi Audio

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

Untuk tujuan bagian ini, gunakan definisi berikut:

• latensi output. Interval antara saat aplikasi menulis frame data berkode PCM dan saat suara yang sesuai disajikan ke lingkungan pada transduser di perangkat atau saat sinyal keluar dari perangkat melalui port dan dapat diamati secara eksternal.
• latensi cold output. Waktu antara memulai streaming output dan waktu presentasi frame pertama berdasarkan stempel waktu, saat sistem output audio tidak ada aktivitas dan dimatikan sebelum permintaan.
• latensi output berkelanjutan. Latensi output untuk frame berikutnya, setelah perangkat memutar audio.
• latensi input. Interval antara saat suara disajikan oleh lingkungan ke perangkat pada transduser atau sinyal di perangkat, memasuki perangkat melalui port dan saat aplikasi membaca frame yang sesuai dari data berkode PCM.
• kehilangan input. Bagian awal sinyal input yang tidak dapat digunakan atau tidak tersedia.
• latensi input cold. Waktu antara memulai streaming dan saat frame pertama yang valid diterima, saat sistem input audio tidak ada aktivitas 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 memberikan waktu bagi aplikasi untuk memproses sinyal dan waktu bagi aplikasi untuk mengurangi perbedaan fase antara stream input dan output.

• API antrean buffer OpenSL ES PCM. Kumpulan OpenSL ES API terkait PCM dalam Android NDK.

• API audio native AAudio. Kumpulan AAudio API dalam Android NDK.

• Stempel waktu. Pasangan yang terdiri dari posisi frame relatif dalam sebuah streaming dan estimasi waktu saat frame tersebut masuk atau keluar dari pipeline pemrosesan audio pada endpoint terkait. Lihat juga AudioTimestamp.

• gangguan. Gangguan sementara atau nilai sampel yang salah dalam sinyal audio, biasanya disebabkan oleh underrun buffer untuk output, buffering yang melebihi batas untuk input, atau sumber derau digital atau analog lainnya.

• rata-rata deviasi absolut. Rata-rata nilai absolut deviasi dari rata-rata untuk sekumpulan nilai.

• latensi ketuk untuk nada. Waktu antara saat layar diketuk dan saat nada yang dihasilkan sebagai hasil ketukan tersebut terdengar di speaker.

Jika implementasi perangkat mendeklarasikan android.hardware.audio.output, implementasi perangkat tersebut HARUS memenuhi atau melebihi persyaratan berikut:

• [C-1-1] Stempel waktu output yang ditampilkan oleh AudioTrack.getTimestamp dan AAudioStream_getTimestamp akurat hingga +/- 2 md.

• [C-1-2] Latensi output dingin sebesar 500 milidetik atau kurang.

• [C-1-3] Membuka stream output menggunakan AAudioStreamBuilder_openStream() HARUS memerlukan waktu kurang dari 1.000 milidetik.

Jika implementasi perangkat mendeklarasikan android.hardware.audio.output, implementasi perangkat tersebut SANGAT DIREKOMENDASIKAN untuk memenuhi atau melebihi persyaratan berikut:

• [C-SR-1] Latensi cold output 100 milidetik atau kurang pada jalur data speaker.
• [C-SR-2] Latensi tap-to-tone 80 milidetik atau kurang.

Jika implementasi perangkat memenuhi persyaratan di atas, setelah kalibrasi awal, saat menggunakan API audio native AAudio, untuk latensi output berkelanjutan dan latensi cold output pada setidaknya satu perangkat output audio yang didukung, yaitu:

• [C-SR-5] SANGAT DIREKOMENDASIKAN untuk melaporkan audio latensi rendah dengan mendeklarasikan flag fitur android.hardware.audio.low_latency.
• [C-SR-6] SANGAT DIREKOMENDASIKAN untuk memenuhi persyaratan audio berlatensi rendah melalui AAudio API.
• [C-SR-7] SANGAT DIREKOMENDASIKAN untuk memastikan bahwa untuk aliran data yang menampilkan AAUDIO_PERFORMANCE_MODE_LOW_LATENCY dari AAudioStream_getPerformanceMode(), nilai yang ditampilkan oleh AAudioStream_getFramesPerBurst() kurang dari atau sama dengan nilai yang ditampilkan oleh android.media.AudioManager.getProperty(String) untuk kunci properti AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

Jika implementasi perangkat tidak memenuhi persyaratan audio latensi rendah melalui API audio native AAudio, implementasi tersebut:

• [C-2-1] TIDAK BOLEH melaporkan dukungan untuk audio latensi rendah.

Jika implementasi perangkat menyertakan android.hardware.microphone, implementasi tersebut HARUS memenuhi persyaratan audio input berikut:

• [C-3-1] Batasi error dalam stempel waktu input, seperti yang ditampilkan oleh AudioRecord.getTimestamp atau AAudioStream_getTimestamp, hingga +/- 2 md. "Error" di sini berarti penyimpangan dari nilai yang benar.
• [C-3-2] Latensi input dingin selama 500 milidetik atau kurang.
• [C-3-3] Membuka stream input menggunakan AAudioStreamBuilder_openStream() HARUS memerlukan waktu kurang dari 1.000 milidetik.

Jika implementasi perangkat menyertakan android.hardware.microphone, implementasi perangkat tersebut SANGAT DIREKOMENDASIKAN untuk memenuhi persyaratan audio input berikut:

• [C-SR-8] Latensi input dingin 100 milidetik atau kurang melalui jalur data mikrofon.

• [C-SR-11] Batasi error dalam stempel waktu input, seperti yang ditampilkan oleh AudioRecord.getTimestamp atau AAudioStream_getTimestamp, ke +/- 1 md.

Jika implementasi perangkat mendeklarasikan android.hardware.audio.output dan android.hardware.microphone, implementasi tersebut:

• [C-SR-12] SANGAT DIREKOMENDASIKAN untuk memiliki Rata-rata Latensi Pulang Terus Berkelanjutan 50 milidetik atau kurang lebih dari 5 pengukuran, dengan Simpangan Absolut Rata-rata kurang dari 10 milidetik, pada setidaknya satu jalur yang didukung.

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 format codec dan penampung yang perlu didukung oleh implementasi perangkat, implementasi 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 ditunjukkan dalam tabel format segmen media di bawah melalui protokol draf HTTP Live Streaming, Versi 7.

• [C-1-3] HARUS mendukung format payload RTSP terkait seperti ditunjukkan dalam tabel RTSP di bawah. Untuk pengecualian, lihat catatan kaki tabel di bagian 5.1.

Format Segmen Media

Format segmen	Referensi	Dukungan codec yang diperlukan
Aliran Transpor MPEG-2	ISO 13818	Codec video: AVC H264 MPEG-4 SP MPEG-2 Lihat bagian 5.1.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 penyesuaian frame ADTS dan tag ID3	ISO 13818-7	Lihat bagian 5.1.1 untuk mengetahui detail tentang AAC dan variannya
WebVTT	WebVTT

RTSP (RTP, SDP)

Nama profil	Referensi	Dukungan codec yang diperlukan
AVC H264	RFC 6184	Lihat bagian 5.1.8 untuk mengetahui detail tentang H264 AVC
MP4A-LATM	RFC 6416	Lihat bagian 5.1.3 untuk detail tentang AAC dan variannya
H263-1998	RFC 3551 RFC 4629 RFC 2190	Lihat bagian 5.1.8 untuk detail tentang H263
H263-2000	RFC 4629	Lihat bagian 5.1.8 untuk 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 detail tentang MPEG-4 SP
mpeg4-generik	RFC 3640	Lihat bagian 5.1.3 untuk detail tentang AAC dan variannya
MP2T	RFC 2250	Lihat MPEG-2 Transport Stream di bawah HTTP Live Streaming untuk mengetahui detailnya

5.8. Media yang Aman

Jika implementasi perangkat mendukung output video yang aman dan mampu mendukung platform aman, implementasi tersebut:

• [C-1-1] HARUS mendeklarasikan dukungan untuk Display.FLAG_SECURE.

Jika implementasi perangkat mendeklarasikan dukungan untuk Display.FLAG_SECURE dan mendukung protokol layar nirkabel, implementasi tersebut:

• [C-2-1] HARUS mengamankan link dengan mekanisme yang kuat secara kriptografis seperti HDCP 2.x atau yang lebih baru untuk layar yang terhubung melalui protokol nirkabel seperti Miracast.

Jika implementasi perangkat mendeklarasikan dukungan untuk Display.FLAG_SECURE dan mendukung layar eksternal berkabel, implementasi tersebut:

• [C-3-1] HARUS mendukung HDCP 1.2 atau yang lebih baru untuk semua layar 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, implementasi tersebut:

• [C-1-1] HARUS mendukung MIDI pada semua transport hardware yang mendukung MIDI yang menyediakan konektivitas non-MIDI generik, dengan transport tersebut adalah:

  • Mode host USB, bagian 7.7
  • MIDI melalui Bluetooth LE yang bertindak dalam peran sentral, 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 asli)

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

• [C-1-1] HARUS melaporkan dukungan untuk fitur android.hardware.audio.low_latency.
• [C-1-2] HARUS memiliki latensi audio bolak-balik berkelanjutan, seperti yang ditetapkan di bagian 5.6 Latensi Audio 25 milidetik atau kurang di setidaknya satu jalur yang didukung.
• [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 dan audio USB menggunakan API audio native AAudio 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 md atau kurang.

• [C-1-8] HARUS memiliki latensi Tap-to-tone rata-rata 80 milidetik atau kurang pada minimal 5 pengukuran melalui jalur data speaker ke mikrofon.

• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk memenuhi latensi seperti yang ditentukan di bagian 5.6 Latensi Audio, yaitu 20 milidetik atau kurang, lebih dari 5 pengukuran dengan Deviasi Absolut Rata-Rata kurang dari 5 milidetik melalui jalur speaker ke mikrofon.

• [C-SR-2] SANGAT DIREKOMENDASIKAN untuk memenuhi persyaratan Audio Pro terkait latensi audio bolak-balik yang berkelanjutan, latensi input cold, latensi cold output, dan persyaratan audio USB menggunakan audio native AAudio melalui jalur MMAP.

• [C-SR-3] SANGAT DIREKOMENDASIKAN untuk memberikan tingkat performa CPU yang konsisten saat audio aktif dan beban CPU bervariasi. Aplikasi ini harus diuji menggunakan aplikasi Android SynthMark. SynthMark menggunakan synthesizer software yang berjalan pada simulasi framework audio yang mengukur performa sistem. Lihat dokumentasi SynthMark untuk penjelasan tentang benchmark. Aplikasi SynthMark harus dijalankan menggunakan opsi “Pengujian Otomatis” dan mencapai hasil berikut:

  • voicemark.90 >= 32 suara
  • latensimark.fixed.little <= 15 mdtk
  • latensimark.dynamic.little <= 50 mdtk

• HARUS minimalkan ketidakakuratan jam audio dan penyimpangan relatif terhadap waktu standar.

• HARUS meminimalkan penyimpangan jam audio relatif terhadap CLOCK_MONOTONIC CPU saat keduanya aktif.

• HARUS minimalkan latensi audio pada transduser di perangkat.

• HARUS minimalkan latensi audio melalui audio digital USB.

• HARUS mendokumentasikan pengukuran latensi audio pada semua jalur.

• HARUS minimalkan jitter dalam waktu masuk callback penyelesaian buffer audio, karena hal ini memengaruhi persentase bandwidth CPU penuh yang dapat digunakan oleh callback.

• HARUS menyediakan nol gangguan audio dalam penggunaan normal pada latensi yang dilaporkan.

• HARUS menyediakan nol perbedaan latensi antar-saluran.

• HARUS meminimalkan latensi rata-rata MIDI pada semua transpor.

• HARUS meminimalkan variabilitas latensi MIDI di bawah beban (jitter) pada semua transpor.

• HARUS memberikan stempel waktu MIDI yang akurat pada semua transpor.

• HARUS minimalkan derau sinyal audio pada transduser di perangkat, termasuk periode segera setelah cold start.

• HARUS menyediakan nol perbedaan jam audio antara sisi input dan output titik akhir yang sesuai, jika keduanya aktif. Contoh endpoint yang sesuai mencakup mikrofon dan speaker di perangkat, atau input dan output colokan audio.

• HARUS menangani callback penyelesaian buffer audio untuk sisi input dan output titik akhir yang sesuai pada thread yang sama saat keduanya aktif, dan masukkan callback output segera setelah ditampilkan dari callback input. Atau jika tidak memungkinkan untuk menangani callback di thread yang sama, masukkan callback output segera setelah memasukkan callback input untuk mengizinkan aplikasi memiliki pengaturan waktu yang konsisten untuk sisi input dan output.

• HARUS minimalkan perbedaan fase antara buffering audio HAL untuk sisi input dan output dari titik akhir yang terkait.

• HARUS minimalkan latensi sentuh.

• HARUS meminimalkan variabilitas latensi sentuh saat terjadi beban (jitter).

Jika implementasi perangkat memenuhi semua persyaratan di atas, implementasi tersebut:

• [C-SR-4] SANGAT DIREKOMENDASIKAN untuk melaporkan dukungan bagi fitur android.hardware.audio.pro melalui class android.content.pm.PackageManager.

Jika implementasi perangkat menyertakan colokan audio 3,5 mm konduktor 4, implementasi tersebut:

• [C-2-1] HARUS memiliki rata-rata Latensi Audio bolak-balik Berkelanjutan, seperti yang ditetapkan di bagian 5.6 Latensi Audio, sebesar 20 milidetik atau kurang, lebih dari 5 pengukuran dengan Penyimpangan Absolut Rata-rata kurang dari 5 milidetik dari jalur colokan audio menggunakan Dongle Loopback Audio.

• [C-SR-5] SANGAT DIREKOMENDASIKAN untuk mematuhi bagian Spesifikasi perangkat seluler (colokan) dalam Spesifikasi Headset Audio Berkabel (v1.1).

Jika implementasi perangkat menghilangkan 4 colokan audio 3,5 mm konduktor dan menyertakan port USB yang mendukung mode host USB, implementasi tersebut:

• [C-3-1] HARUS mengimplementasikan class audio USB.
• [C-3-2] HARUS memiliki rata-rata Latensi Audio bolak-balik Berkelanjutan 25 milidetik atau kurang, lebih dari 5 pengukuran dengan Rata-rata Deviasi Absolut kurang dari 5 milidetik terhadap port mode host USB yang menggunakan class audio USB. (Hal ini dapat diukur menggunakan adaptor USB-3,5 mm dan Dongle Loopback Audio, atau menggunakan antarmuka audio USB dengan kabel patch yang menghubungkan input ke output).
• [C-SR-6] SANGAT DIREKOMENDASIKAN untuk mendukung I/O simultan hingga 8 saluran di setiap arah, frekuensi sampel 96 kHz, dan kedalaman 24-bit atau 32-bit, saat digunakan dengan periferal audio USB yang juga mendukung persyaratan ini.
• [C-SR-7] SANGAT DIREKOMENDASIKAN untuk memenuhi kelompok persyaratan ini menggunakan API audio native AAudio melalui jalur MMAP.

Jika implementasi perangkat menyertakan port HDMI, implementasi tersebut:

• HARUS mendukung output di stereo dan delapan saluran pada kedalaman 20-bit atau 24-bit dan 192 kHz tanpa kehilangan kedalaman bit atau resampling, setidaknya dalam satu konfigurasi.

5.11. Ambil untuk Belum Diproses

Android menyertakan dukungan untuk perekaman audio yang belum diproses melalui sumber audio android.media.MediaRecorder.AudioSource.UNPROCESSED. Di OpenSL ES, akses dapat diakses dengan preset rekaman SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

Jika implementasi perangkat ditujukan untuk mendukung sumber audio yang belum diproses dan menyediakannya untuk aplikasi pihak ketiga, implementasi tersebut akan:

• [C-1-1] HARUS melaporkan dukungan melalui properti android.media.AudioManager PROPERTI_SUPPORT_AUDIO_SOURCE_UNPROGRESSED.

• [C-1-2] HARUS menunjukkan karakteristik amplitudo-versus frekuensi rata-rata dalam rentang frekuensi menengah: khususnya ±10 dB dari 100 Hz hingga 7.000 Hz untuk setiap mikrofon yang digunakan untuk merekam sumber audio yang belum 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 1.000 Hz yang diputar pada Level Tekanan Suara (SPL) 94 dB akan menghasilkan respons dengan RMS 520 untuk sampel 16 bit (atau Skala Penuh -36 dB untuk sampel floating point/audio yang tidak diproses) untuk setiap mikrofon yang digunakan untuk merekam sumber yang tidak diproses

• [C-1-6] HARUS memiliki rasio sinyal terhadap gangguan (SNR) sebesar 60 dB atau lebih tinggi untuk setiap mikrofon yang digunakan untuk merekam sumber audio yang belum diproses. (sedangkan SNR diukur sebagai perbedaan antara 94 dB SPL dan SPL noise mandiri yang setara, A-weighted).

• [C-1-7] HARUS memiliki total distorsi harmonik (THD) kurang dari 1% untuk 1 kHZ pada level input SPL 90 dB pada setiap mikrofon yang digunakan untuk merekam sumber audio yang belum diproses.

• [C-1-8] HARUS tidak memiliki pemrosesan sinyal lainnya (misalnya Kontrol Penguatan Otomatis, Filter Tingkat Tinggi, atau Pembatalan Echo) di jalur selain pengganda level untuk membawa level ke rentang yang diinginkan. Dengan kata lain:

  • [C-1-9] Jika ada pemrosesan sinyal di arsitektur karena alasan apa pun, pemrosesan sinyal HARUS dinonaktifkan dan secara efektif menyebabkan penundaan nol atau latensi tambahan ke jalur sinyal.
  • [C-1-10] Pengganda level, meskipun diizinkan berada di jalur, TIDAK BOLEH menyebabkan penundaan atau latensi ke jalur sinyal.

Semua pengukuran SPL dilakukan langsung di sebelah mikrofon yang 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, implementasi tersebut:

• [C-2-1] HARUS menampilkan null untuk metode API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED), untuk menunjukkan kurangnya dukungan dengan benar.
• [C-SR-1] masih SANGAT DIREKOMENDASIKAN untuk memenuhi sebanyak mungkin persyaratan jalur sinyal bagi sumber perekaman yang belum diproses.

5.12. Video HDR

Android 13 mendukung teknologi HDR seperti yang dijelaskan dalam dokumen mendatang.

Format Piksel

Jika dekoder video mengiklankan dukungan untuk Color_FormatYUVP010, maka:

• [C-1-1] HARUS mendukung format P010 untuk pembacaan 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 berdasarkan aplikasi.

Jika dekoder video mengiklankan dukungan untuk Color_Format32bitABGR2101010, maka:

• [C-2-1] HARUS mendukung format RGBA_1010102 untuk permukaan output dan yang dapat dibaca CPU (output ByteBuffer).

Jika encoder video mengiklankan dukungan untuk Color_FormatYUVP010, maka:

• [C-3-1] HARUS mendukung format P010 untuk platform input dan input yang dapat ditulis oleh CPU (ImageWriter, MediaImage, ByteBuffer).

Jika encoder video mengiklankan dukungan untuk Color_Format32bitABGR2101010, maka:

• [C-4-1] HARUS mendukung format RGBA_1010102 untuk platform input dan input yang dapat ditulis oleh CPU (ImageWriter, ByteBuffer). Catatan: Konversi antara berbagai kurva transfer TIDAK diperlukan untuk encoder.

Persyaratan Pengambilan Gambar HDR

Untuk semua encoder video yang mendukung profil HDR, implementasi perangkat:

• [C-5-1] TIDAK BOLEH berasumsi bahwa metadata HDR sudah tepat. Misalnya, frame yang dienkode mungkin memiliki piksel yang melebihi 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 metadata tersebut akan menghasilkan output di akhir setiap sesi encoding.

Jika implementasi perangkat mendukung perekaman HDR menggunakan CamcorderProfile API maka implementasi tersebut:

• [C-6-1] juga HARUS mendukung pengambilan gambar HDR melalui Camera2 API.

• [C-6-2] HARUS mendukung setidaknya satu encoder video dengan akselerasi hardware untuk setiap teknologi HDR yang didukung.

• [C-6-3] HARUS mendukung (minimal) penangkapan 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 nada HDR ke SDR dalam dekoder dengan akselerasi hardware default untuk profil yang diambil. Dengan kata lain, jika perangkat dapat merekam HDR10+ HEVC, decoder HEVC default HARUS dapat mendekode streaming yang direkam di SDR.

Persyaratan Pengeditan HDR

Jika implementasi perangkat menyertakan encoder video yang mendukung pengeditan HDR, penerapan tersebut:

• HARUS menggunakan latensi minimal untuk menghasilkan metadata HDR jika tidak ada, dan SEBAIKNYA menangani situasi saat metadata ada untuk beberapa frame, dan tidak untuk frame lainnya. Metadata ini HARUS akurat (misalnya, representasikan luminans puncak dan histogram frame yang sebenarnya).

Jika implementasi perangkat menyertakan codec yang mendukung FEATURE_HdrEditing, 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, profil ini HARUS mendukung pembuatan metadata HDR jika tidak ada untuk semua profil HDR yang didukung dan 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 permukaan input dan ByteBuffer, serta HARUS mengiklankan dukungan untuk Color_Format32bitABGR2101010.

Jika implementasi perangkat menyertakan codec yang mendukung FEATURE_HdrEditing, berarti perangkat:

• [C-7-4] HARUS mengiklankan dukungan untuk ekstensi OpenGL EXT_YUV_target.

6. Kompatibilitas Opsi dan Developer Tools

6.1. Developer Tools

Implementasi perangkat:

• [C-0-1] HARUS mendukung Android Developer Tools yang disediakan di Android SDK.

• Android Debug Bridge (adb)

  • [C-0-2] HARUS mendukung adb seperti yang didokumentasikan di Android SDK dan perintah shell yang disediakan dalam AOSP, yang dapat digunakan oleh developer aplikasi, termasuk dumpsys cmd stats
  • [C-0-11] HARUS mendukung perintah shell cmd testharness. Mengupgrade penerapan perangkat dari versi Android sebelumnya tanpa blok data persisten DAPAT dikecualikan dari C-0-11.
  • [C-0-3] TIDAK BOLEH mengubah format atau konten peristiwa sistem perangkat (Batterystats , diskstats, sidik jari, grafisstats, netstats, notifikasi, procstats) yang dicatat melalui perintah dumpsys.
  • [C-0-10] HARUS merekam, tanpa menghapus, dan membuat peristiwa berikut dapat diakses dan tersedia untuk perintah shell cmd stats dan class API System StatsManager.
    • ActivityForegroundStateDiubah
    • Anomali Terdeteksi
    • AppBreadcrumbDilaporkan
    • AppCrashTerjadi
    • AppStartTerjadi
    • TingkatBateraiDiubah
    • BatterySaverModeStateDiubah
    • BleScanResultReceived
    • BleScanStateDiubah
    • PengisianStateDiubah
    • DeviceIdleModeStateDiubah
    • ForegroundServiceStateDiubah
    • GpsScanStateDiubah
    • JobStateDiubah
    • PluggedStateDiubah
    • DijadwalkanJobStateDiubah
    • Status Layar Diubah
    • SyncStateDiubah
    • Real-Time Berlalu Sistem
    • {i>UidProcessStateDiubah<i}
    • WakelockStateDiubah
    • WakeupAlarm Terjadi
    • WifiLockStateDiubah
    • WifiMulticastLockStateDiubah
    • WifiScanStateDiubah
  • [C-0-4] HARUS menonaktifkan daemon adb sisi perangkat secara default, dan HARUS ada mekanisme yang dapat diakses pengguna untuk mengaktifkan Android Debug Bridge.
  • [C-0-5] HARUS mendukung adb aman. Android menyertakan dukungan untuk adb aman. adb aman memungkinkan adb pada host terautentikasi yang dikenal.
  • [C-0-6] HARUS menyediakan mekanisme yang memungkinkan adb terhubung dari mesin host. Khususnya:

  Jika implementasi perangkat tanpa port USB mendukung mode periferal, implementasi tersebut:

  • [C-3-1] HARUS mengimplementasikan adb melalui jaringan area lokal (seperti Ethernet atau Wi-Fi).
  • [C-3-2] HARUS menyediakan driver untuk Windows 7, 8, dan 10, sehingga developer dapat terhubung ke perangkat menggunakan protokol adb.

  Jika implementasi perangkat mendukung koneksi adb ke mesin host melalui Wi-Fi atau Ethernet, implementasi tersebut:

  • [C-4-1] Metode AdbManager#isAdbWifiSupported() HARUS menampilkan true.

  Jika implementasi perangkat mendukung koneksi adb ke mesin host melalui Wi-Fi atau Ethernet, dan menyertakan setidaknya satu kamera, implementasi tersebut:

  • [C-5-1] Metode AdbManager#isAdbWifiQrSupported() HARUS menampilkan true.

• Layanan Pemantau Debug Dalvik (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 di Android SDK. Systrace harus tidak aktif secara default dan HARUS ada mekanisme yang dapat diakses pengguna untuk mengaktifkan Systrace.

• Perfetto

  • [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mengekspos biner /system/bin/perfetto ke pengguna shell yang mematuhi cmdline dengan dokumentasi perfetto.
  • [C-SR-2] Biner perfetto SANGAT DIREKOMENDASIKAN untuk menerima sebagai input konfigurasi protobuf yang mematuhi skema yang didefinisikan dalam dokumentasi perfetto.
  • [C-SR-3] Biner perfetto SANGAT DIREKOMENDASIKAN untuk menulis sebagai output rekaman aktivitas protobuf yang mematuhi skema yang ditentukan dalam dokumentasi perfetto.
  • [C-SR-4] SANGAT DIREKOMENDASIKAN untuk menyediakan setidaknya sumber data yang dijelaskan dalam dokumentasi perfetto melalui biner perfetto.

• Pemotong Memori Rendah

  • [C-0-12] HARUS menulis Atom LMK_KILL_OCCURRED_FIELD_NUMBER ke log statistik saat aplikasi dihentikan oleh Low Memory Killer.

• Mode Memanfaatkan Pengujian Jika implementasi perangkat mendukung perintah shell cmd testharness dan menjalankan cmd testharness enable, implementasi tersebut:

  • [C-2-1] HARUS menampilkan true untuk ActivityManager.isRunningInUserTestHarness()
  • [C-2-2] HARUS mengimplementasikan Mode Uji Coba seperti yang dijelaskan dalam dokumentasi Mode Uji Coba.

• Informasi pekerjaan GPU

  Implementasi perangkat:

  • [C-0-13] HARUS menerapkan perintah shell dumpsys gpu --gpuwork untuk menampilkan data kerja GPU gabungan yang ditampilkan oleh tracepoint kernel power/gpu_work_period, atau tidak menampilkan data jika tracepoint tidak didukung. Implementasi AOSP adalah frameworks/native/services/gpuservice/gpuwork/.

Jika implementasi perangkat melaporkan dukungan Vulkan 1.0 atau yang lebih tinggi melalui tombol fitur android.hardware.vulkan.version, implementasi tersebut:

• [C-1-1] HARUS menyediakan affordance bagi developer aplikasi untuk mengaktifkan/menonaktifkan lapisan debug GPU.
• [C-1-2] HARUS, saat lapisan debug GPU diaktifkan, menghitung lapisan di library yang disediakan oleh alat eksternal (yaitu bukan bagian dari platform atau paket aplikasi) yang ditemukan dalam direktori dasar aplikasi yang dapat di-debug untuk mendukung metode API vkCreateEnumerateInstanceLayerProperties() 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 pada item menu Settings > About Device > Build Number.
• [C-0-2] HARUS menyembunyikan Opsi Developer secara default.
• [C-0-3] HARUS menyediakan mekanisme yang jelas yang tidak memberikan perlakuan preferensi pada satu aplikasi pihak ketiga, bukan aplikasi lain untuk mengaktifkan Opsi Developer. HARUS menyediakan dokumen atau situs yang dapat dilihat oleh publik, yang menjelaskan cara mengaktifkan Opsi Developer. Dokumen atau situs ini HARUS dapat ditautkan dari dokumen Android SDK.
• SEHARUSNYA memiliki notifikasi visual berkelanjutan kepada pengguna saat Opsi Developer diaktifkan dan keamanan pengguna harus menjadi perhatian.
• MUNGKIN membatasi akses ke menu Opsi Developer untuk sementara, dengan menyembunyikan atau menonaktifkan menu secara visual, untuk mencegah gangguan bagi skenario yang memperhatikan keselamatan pengguna.

7. Kompatibilitas Perangkat Keras

Jika perangkat menyertakan komponen hardware tertentu yang memiliki API yang sesuai untuk developer pihak ketiga:

• [C-0-1] Implementasi perangkat HARUS mengimplementasikan API tersebut seperti yang dijelaskan dalam dokumentasi Android SDK.

Jika API di SDK berinteraksi dengan komponen hardware yang dinyatakan opsional dan implementasi perangkat tidak memiliki komponen tersebut:

• [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 tanpa pengoperasian 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 class tanpa pengoperasian jika nilai null 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 secara konsisten melaporkan informasi konfigurasi hardware yang akurat melalui metode getSystemAvailableFeatures() dan hasSystemFeature(String) di class android.content.pm.PackageManager untuk sidik jari build yang sama.

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

7.1. Tampilan dan Grafis

Android menyertakan fasilitas yang otomatis menyesuaikan aset aplikasi dan tata letak UI dengan tepat untuk perangkat guna memastikan bahwa aplikasi pihak ketiga berjalan dengan baik di berbagai konfigurasi hardware. berbagai tampilan dan konfigurasi hardware. Tampilan yang kompatibel dengan Android adalah layar tampilan yang menerapkan semua perilaku dan API yang dijelaskan dalam Developer Android - Ringkasan kompatibilitas layar, bagian ini (7.1) dan subbagiannya, serta semua perilaku khusus jenis perangkat tambahan yang didokumentasikan dalam bagian 2 CDD ini. Pada layar yang kompatibel dengan Android, tempat semua aplikasi pihak ketiga yang kompatibel dengan Android dapat berjalan, implementasi perangkat HARUS menerapkan API dan perilaku ini dengan benar, seperti yang dijelaskan di bagian ini.

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

• ukuran diagonal fisik. Jarak dalam inci antara dua sudut yang berlawanan dari bagian layar yang diterangi.
• titik per inci (dpi)kepadatan. Jumlah piksel yang dicakup oleh rentang horizontal atau vertikal linear berukuran 1 inci, yang dinyatakan sebagai piksel per inci (ppi atau dpi). Jika nilai dpi ppi dan dpi dicantumkan, dpi horizontal dan vertikal harus berada dalam rentang yang tercantum.
• rasio aspek. Rasio piksel dimensi yang lebih panjang terhadap dimensi layar yang lebih pendek. Misalnya, tampilan 480x854 piksel akan menjadi 854/480 = 1,779, atau kira-kira “16:9”.
• piksel kepadatan mandiri (dp). Unit piksel virtual A dinormalisasi ke layar 160 dpi kepadatan layar 160. Untuk d kepadatan tertentu, dan sejumlah piksel p, jumlah dp piksel kepadatan mandiri, dihitung sebagai: piksel = dps * (kepadatan/160) 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, dan memungkinkan aplikasi membuat kueri 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 seperti yang ditentukan dalam dokumentasi Android SDK. Secara khusus, implementasi perangkat HARUS melaporkan dimensi layar piksel kepadatan mandiri (dp) logis yang benar seperti di bawah ini:

  • Perangkat dengan Configuration.uiMode yang ditetapkan sebagai nilai selain UI_MODE_TYPE_WATCH, dan melaporkan ukuran small untuk Configuration.screenLayout, HARUS memiliki minimal 426 dp x 320 dp.
  • Perangkat yang melaporkan ukuran normal untuk Configuration.screenLayout, HARUS memiliki 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 menerima dengan benar dukungan yang dinyatakan aplikasi untuk ukuran layar melalui atribut <supports-screens> di AndroidManifest.xml, seperti yang dijelaskan dalam dokumentasi Android SDK.

• MUNGKIN memiliki layar yang kompatibel dengan Android dengan sudut membulat.

Jika implementasi perangkat mendukung layar yang mendukung UI_MODE_TYPE_NORMAL konfigurasi ukuran dan menyertakan layar yang kompatibel dengan Android gunakan tampilan fisik dengan sudut membulat untuk merender layar ini, layar tersebut:

• [C-1-1] HARUS memastikan bahwa minimal salah satu persyaratan berikut terpenuhi untuk setiap tampilan tersebut:

  • Radius sudut lengkung kurang dari atau sama dengan 38 dp.
  • Saat kotak dp berukuran 1518 dp x 1518 dp ditambatkan di setiap sudut tampilan logis, minimal satu piksel setiap kotak akan terlihat di layar.

• HARUS menyertakan kemampuan pengguna untuk beralih ke mode tampilan dengan sudut persegi panjang.

Untuk mengetahui detail tentang cara menerapkan API file bantuan atau ekstensi dengan benar, lihat dokumentasi publik Jetpack Window Manager.

7.1.1.3. Kepadatan Layar

Framework UI Android menentukan sekumpulan kepadatan logis standar untuk membantu developer aplikasi menargetkan resource aplikasi.

Penerapan Perangkat:

• [C-0-1] Secara default, implementasi perangkat HARUS melaporkan hanya 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. TIDAK BOLEH berubah kapan pun; namun, Namun, perangkat DAPAT melaporkan kepadatan arbitrer DisplayMetrics.density yang berbeda sesuai dengan perubahan konfigurasi tampilan yang dibuat oleh pengguna (misalnya, ukuran layar) yang disetel setelah booting awal.

Jika implementasi perangkat menyediakan ada affordance untuk mengubah ukuran layar perangkat , ukuran tersebut:

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

7.1.2. Metrik Display

Jika implementasi perangkat menyertakan tampilan atau output video yang kompatibel dengan Android ke layar tampilan 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 android.util.DisplayMetrics API.

Jika implementasi perangkat tidak menyertakan output video atau layar tersemat, implementasi tersebut:

• [C-2-1] HARUS melaporkan nilai yang benar dari tampilan 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 orientasi tetap, seperti televisi atau laptop, SEHARUSNYA hanya 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, implementasi tersebut:

• [C-1-1] HARUS mendukung orientasi dinamis oleh aplikasi untuk orientasi layar potret atau lanskap. Artinya, perangkat harus mengikuti permintaan aplikasi untuk orientasi layar tertentu.
• [C-1-2] TIDAK BOLEH mengubah kepadatan atau ukuran layar yang dilaporkan saat mengubah orientasi.
• MUNGKIN 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 dengan benar versi OpenGL ES yang didukung (1.1, 2.0, 3.0, 3.1, 3.2) melalui API yang dikelola (seperti melalui metode GLES10.getString()) dan API native.
• [C-0-2] HARUS menyertakan dukungan untuk semua API terkelola dan API native yang sesuai untuk setiap versi OpenGL ES yang diidentifikasi untuk didukung.

Jika implementasi perangkat menyertakan output layar atau video, implementasi tersebut:

• [C-1-1] HARUS mendukung OpenGL ES 1.1 dan 2.0, seperti yang dinyatakan dan dijelaskan dalam dokumentasi Android SDK.
• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung OpenGL ES 3.1.
• HARUS mendukung OpenGL ES 3.2.

Pengujian dEQP OpenGL ES dibagi menjadi beberapa daftar pengujian, masing-masing dengan tanggal/nomor versi terkait. Semuanya ada dalam hierarki sumber Android di external/deqp/android/cts/main/glesXX-main-YYYY-MM-DD.txt. Perangkat yang mendukung OpenGL ES pada tingkat yang dilaporkan sendiri menunjukkan bahwa perangkat tersebut dapat lulus pengujian dEQP di semua daftar pengujian dari level ini dan sebelumnya.

Jika implementasi perangkat mendukung salah satu versi OpenGL ES, implementasi tersebut:

• [C-2-1] HARUS melaporkan ekstensi OpenGL ES lain melalui API yang dikelola OpenGL ES dan API native ekstensi OpenGL ES lain yang telah mereka terapkan, dan sebaliknya TIDAK BOLEH melaporkan string ekstensi yang tidak didukung.
• [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 tombol fitur android.software.opengles.deqp.level.
• [C-2-4] Setidaknya HARUS mendukung versi 132383489 (mulai 1 Maret 2020) seperti yang dilaporkan dalam tombol fitur android.software.opengles.deqp.level.
• [C-2-5] HARUS lulus semua Pengujian dEQP OpenGL ES dalam daftar pengujian antara versi 132383489 dan versi yang ditentukan dalam tombol fitur android.software.opengles.deqp.level, untuk setiap versi OpenGL ES yang didukung.
• [C-SR-2] SANGAT DIREKOMENDASIKAN 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 spesifik per vendor.

• HARUS mendukung ekstensi EGL_IMG_context_priority dan EGL_EXT_protected_content.

Jika implementasi perangkat mendeklarasikan dukungan untuk OpenGL ES 3.0, 3.1, atau 3.2, mereka:

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

• [C-4-1] HARUS mendukung Paket Ekstensi Android OpenGL ES secara keseluruhan.

Jika implementasi perangkat mendukung Android Extension Pack OpenGL ES secara keseluruhan, implementasi tersebut:

• [C-5-1] HARUS mengidentifikasi dukungan melalui tombol fitur android.hardware.opengles.aep.

Jika implementasi perangkat mengekspos dukungan untuk ekstensi EGL_KHR_mutable_render_buffer, implementasi tersebut:

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

• [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 menyertakan output layar atau video, implementasi tersebut:

• [C-SR-2] SANGAT DIREKOMENDASIKAN untuk menyertakan dukungan bagi Vulkan 1.3.

Pengujian dEQP Vulkan dipartisi menjadi beberapa daftar pengujian, masing-masing dengan tanggal/versi terkait. Semuanya ada dalam hierarki sumber Android di external/deqp/android/cts/main/vk-main-YYYY-MM-DD.txt. Perangkat yang mendukung Vulkan pada tingkat yang dilaporkan sendiri menunjukkan bahwa perangkat tersebut dapat lulus pengujian dEQP di semua daftar pengujian dari level ini dan sebelumnya.

Jika implementasi perangkat menyertakan dukungan untuk Vulkan 1.0 atau yang lebih tinggi, implementasi tersebut:

• [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 menghitung, setidaknya satu VkPhysicalDevice untuk API native Vulkan vkEnumeratePhysicalDevices().
• [C-1-3] HARUS sepenuhnya menerapkan Vulkan 1.0 Vulkan 1.1 API untuk setiap VkPhysicalDevice yang dienumerasi.
• [C-1-4] HARUS menghitung lapisan, yang terdapat dalam library native yang diberi nama libVkLayer*.so dalam direktori library native paket aplikasi, melalui API native Vulkan vkEnumerateInstanceLayerProperties() dan vkEnumerateDeviceLayerProperties().
• [C-1-5] TIDAK BOLEH menghitung lapisan yang disediakan oleh library di luar paket aplikasi, atau memberikan cara lain untuk melacak atau mengintersepsi Vulkan API, kecuali jika aplikasi tersebut memiliki atribut android:debuggable yang ditetapkan sebagai true atau metadata com.android.graphics.injectLayers.enable yang ditetapkan ke true .
• [C-1-6] HARUS melaporkan semua string ekstensi yang didukungnya melalui API native Vulkan , dan sebaliknya TIDAK BOLEH melaporkan string ekstensi yang tidak didukung dengan benar.
• [C-1-7] HARUS mendukung ekstensi VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, dan ekstensi VK_KHR_inkremental_present.
• [C-1-8] HARUS melaporkan versi maksimum Pengujian dEQP Vulkan yang didukung melalui tombol fitur android.software.vulkan.deqp.level.
• [C-1-9] Setidaknya HARUS mendukung versi 132317953 (mulai 1 Maret 2019) seperti yang dilaporkan dalam tombol 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 tombol fitur android.software.vulkan.deqp.level.
• [C-1-11] TIDAK BOLEH menghitung dukungan untuk ekstensi VK_KHR_video_queue, VK_KHR_video_decode_queue, atau VK_KHR_video_encode_queue.
• [C-SR-3] SANGAT DIREKOMENDASIKAN untuk mendukung ekstensi VK_KHR_driver_properties dan VK_GOOGLE_display_timing.

• [C-1-12] TIDAK BOLEH menghitung dukungan untuk ekstensi VK_KHR_performance_query.

• [C-SR-4] SANGAT DIREKOMENDASIKAN untuk memenuhi persyaratan yang ditentukan oleh profil Dasar Pengukuran Android 2022.

Jika implementasi perangkat tidak menyertakan dukungan untuk Vulkan 1.0, implementasi tersebut:

• [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 menghitung VkPhysicalDevice untuk API native Vulkan vkEnumeratePhysicalDevices().

Jika implementasi perangkat menyertakan dukungan untuk Vulkan 1.1 dan mendeklarasikan salah satu flag fitur Vulkan yang dijelaskan di sini , implementasi tersebut:

• [C-3-1] HARUS mengekspos dukungan untuk semaphore eksternal SYNC_FD dan jenis handle serta ekstensi VK_ANDROID_external_memory_android_hardware_buffer.

7.1.4.3 RenderScript

• [C-0-1] Implementasi perangkat HARUS mendukung Android RenderScript, seperti yang dijelaskan dalam dokumentasi Android SDK.

7.1.4.4 Akselerasi Grafis 2D

Android menyertakan mekanisme bagi aplikasi untuk mendeklarasikan bahwa aplikasi ingin mengaktifkan akselerasi hardware untuk grafis 2D pada 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 secara langsung tekstur OpenGL ES dengan akselerasi hardware 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 tampilan gamut lebar melalui Configuration.isScreenWideColorGamut() , implementasi tersebut:

• [C-1-1] HARUS memiliki layar dengan kalibrasi warna.
• [C-1-2] HARUS memiliki layar yang gamutnya mencakup gamut warna sRGB seluruhnya di ruang CIE 1931 xyY.
• [C-1-3] HARUS memiliki layar yang gamutnya memiliki area minimal 90% dari DCI-P3 di ruang CIE 1931 xyY.
• [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, implementasi tersebut:

• [C-2-1] HARUS mencakup 100% atau lebih sRGB di ruang xyY CIE 1931, meskipun color gamut layar tidak ditentukan.

7.1.5. Mode Kompatibilitas Aplikasi Lama

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

7.1.6. Teknologi Layar

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

Semua tampilan yang kompatibel dengan Android dalam implementasi perangkat:

• [C-0-1] HARUS mampu merender grafis berwarna 16-bit.
• HARUS dukung layar yang mampu menampilkan grafis berwarna 24-bit.
• [C-0-2] HARUS mampu 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 guna mengaktifkan kemampuan berbagi media dan API developer untuk mengakses tampilan eksternal.

Jika implementasi perangkat mendukung layar eksternal baik melalui koneksi berkabel, nirkabel, atau koneksi layar tambahan yang tersemat, implementasi tersebut:

• [C-1-1] HARUS mengimplementasikan layanan sistem dan API DisplayManager seperti yang dijelaskan dalam dokumentasi Android SDK.

7.2. Perangkat Input

Implementasi perangkat:

• [C-0-1] HARUS menyertakan mekanisme input, seperti layar sentuh atau navigasi non-sentuh, untuk menavigasi antar-elemen UI.

7.2.1. Keyboard

Jika implementasi perangkat menyertakan dukungan untuk aplikasi Editor Metode Input (IME) pihak ketiga, implementasi tersebut:

• [C-1-1] HARUS mendeklarasikan tombol fitur android.software.input_methods.
• [C-1-2] HARUS mengimplementasikan Input Management Framework sepenuhnya
• [C-1-3] HARUS punya keyboard software bawaan.

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 implementasi soft keyboard tambahan.
• MUNGKIN menyertakan keyboard hardware.

7.2.2. Navigasi Non-sentuh

Android menyertakan dukungan untuk d-pad, trackball, dan wheel 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, implementasi tersebut:

• [C-1-1] HARUS menyediakan mekanisme antarmuka pengguna alternatif yang wajar untuk pemilihan dan pengeditan teks, yang kompatibel dengan Input Management Engine. Implementasi open source Android upstream menyertakan mekanisme pemilihan yang sesuai untuk digunakan dengan perangkat yang tidak memiliki input navigasi non-sentuh.

7.2.3. Tombol Navigasi

Fungsi Beranda, Terbaru, dan Kembali biasanya disediakan melalui interaksi dengan tombol fisik khusus atau bagian layar sentuh yang berbeda, sangat penting bagi paradigma navigasi Android, dan oleh karena itu, implementasi perangkat:

• [C-0-1] HARUS memberikan kemampuan pengguna untuk meluncurkan aplikasi terinstal yang memiliki aktivitas dengan <intent-filter> yang disetel dengan ACTION=MAIN dan CATEGORY=LAUNCHER atau CATEGORY=LEANBACK_LAUNCHER untuk implementasi perangkat Televisi. Fungsi Beranda SEHARUSNYA menjadi mekanisme untuk kemampuan pengguna ini.
• HARUS menyediakan tombol untuk fungsi Recents dan Back.

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) jika ada yang dapat diakses.
• [C-1-2] HARUS memberikan indikasi yang jelas tentang satu tindakan yang akan memicu setiap fungsi. Contoh indikasi tersebut menunjukkan ikon yang terlihat pada tombol, menampilkan ikon software di bagian menu navigasi layar, atau memandu pengguna melalui alur demo langkah demi langkah terpandu selama proses penyiapan siap pakai.

Implementasi perangkat:

• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk tidak menyediakan mekanisme input bagi fungsi Menu karena sudah tidak digunakan lagi dan digantikan oleh panel tindakan sejak Android 4.0.

• [C-SR-2] SANGAT DIREKOMENDASIKAN untuk menyediakan semua fungsi navigasi sebagai dapat dibatalkan. 'Cancellable' didefinisikan sebagai kemampuan pengguna untuk mencegah fungsi navigasi dijalankan (mis. kembali ke layar utama, kembali, dll.) jika geser tidak dilepaskan melewati nilai minimum tertentu.

Jika implementasi perangkat menyediakan fungsi Menu, implementasi tersebut:

• [C-2-1] HARUS menampilkan tombol tindakan tambahan setiap kali pop-up menu tambahan tindakan tidak kosong dan panel tindakan terlihat.
• [C-2-2] TIDAK BOLEH mengubah posisi pop-up tindakan tambahan yang ditampilkan dengan memilih tombol tambahan di panel tindakan, namun DAPAT merender pop-up tindakan tambahan 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 implementasi perangkat menyediakan fungsi Bantuan, implementasi perangkat akan:

• [C-4-1] HARUS membuat fungsi Assist dapat diakses dengan satu tindakan (misalnya, ketuk, klik dua kali, atau gestur) jika tombol navigasi lain dapat diakses.
• [C-SR-3] SANGAT DIREKOMENDASIKAN untuk menggunakan fungsi tekan lama pada fungsi HOME sebagai interaksi yang ditetapkan ini.

Jika implementasi perangkat menggunakan bagian layar yang berbeda untuk menampilkan tombol navigasi, implementasi tersebut:

• [C-5-1] Tombol navigasi HARUS menggunakan bagian layar yang berbeda, tidak tersedia untuk aplikasi, dan TIDAK BOLEH mengaburkan atau mengganggu bagian layar yang tersedia untuk aplikasi.
• [C-5-2] HARUS menyediakan sebagian tampilan untuk aplikasi yang memenuhi persyaratan yang ditetapkan dalam pasal 7.1.1.
• [C-5-3] HARUS mematuhi flag yang ditetapkan oleh aplikasi melalui metode API View.setSystemUiVisibility(), sehingga bagian layar yang berbeda ini (alias menu navigasi) disembunyikan dengan benar seperti yang didokumentasikan dalam 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 rect pengecualian seperti yang disediakan oleh aplikasi latar depan melalui View#setSystemGestureExclusionRects(), tetapi di luar WindowInsets#getMandatorySystemGestureInsets(), TIDAK BOLEH ditangkap untuk fungsi navigasi selama rect pengecualian diizinkan dalam batas pengecualian maksimum seperti yang ditentukan dalam dokumentasi untuk View#setSystemGestureExclusionRects().
• [C-6-3] HARUS mengirimkan peristiwa MotionEvent.ACTION_CANCEL ke aplikasi latar depan setelah sentuhan mulai ditangkap untuk gestur sistem, jika aplikasi latar depan sebelumnya telah mengirim peristiwa MotionEvent.ACTION_DOWN.
• [C-6-4] HARUS menyediakan affordance pengguna untuk beralih ke navigasi berbasis tombol di layar (misalnya, di Setelan).
• HARUS menyediakan fungsi Beranda sebagai geser ke atas dari tepi bawah orientasi layar saat ini.
• HARUS menyediakan fungsi Recents 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 rect 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 kustom yang dapat digeser disediakan di tepi kiri atau kanan, panel tersebut HARUS ditempatkan di 1/3 bagian atas layar dengan indikasi visual yang jelas dan persisten bahwa menarik masuk akan memanggil panel yang disebutkan di atas, sehingga bukan Kembali. Panel sistem DAPAT dikonfigurasi oleh pengguna sedemikian rupa sehingga mendarat di bawah 1/3 atas tepi layar, tetapi panel sistem TIDAK BOLEH menggunakan lebih dari 1/3 tepi.
• [C-7-3] Jika aplikasi latar depan memiliki flag View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT, atau WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE yang disetel, berperilaku dari tepi di SDK MUST berperilaku.
• [C-7-4] Jika aplikasi latar depan memiliki flag View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT, atau WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE yang disetel, panel sistem navigasi yang dapat digeser dan panel sistem yang dapat digeser.

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 dalam AOSP.

Jika implementasi perangkat memberikan dukungan untuk setNavBarMode API sistem agar aplikasi sistem apa pun dengan izin android.permission.STATUS_BAR dapat menetapkan mode menu navigasi, aplikasi tersebut:

• [C-9-1] HARUS memberikan dukungan untuk ikon yang cocok untuk anak atau navigasi berbasis tombol seperti yang diberikan dalam kode AOSP.

7.2.4. Input Layar Sentuh

Android menyertakan dukungan untuk berbagai sistem input pointer, seperti layar sentuh, touchpad, dan perangkat input sentuh palsu. Implementasi perangkat berbasis layar sentuh dikaitkan dengan tampilan sedemikian rupa sehingga pengguna memiliki kesan memanipulasi item secara langsung di layar. Karena pengguna langsung menyentuh layar, sistem tidak memerlukan kemampuan tambahan untuk menunjukkan objek yang sedang dimanipulasi.

Implementasi perangkat:

• SEHARUSNYA memiliki sistem input pointer (baik seperti mouse atau sentuh).
• HARUS mendukung pointer yang dilacak secara independen sepenuhnya.

Jika implementasi perangkat menyertakan layar sentuh (satu sentuhan atau lebih baik) pada layar utama yang kompatibel dengan Android, implementasi tersebut:

• [C-1-1] HARUS melaporkan TOUCHSCREEN_FINGER untuk kolom Configuration.touchscreen API.
• [C-1-2] HARUS melaporkan tombol fitur android.hardware.touchscreen dan android.hardware.faketouch.

Jika implementasi perangkat menyertakan layar sentuh yang dapat melacak lebih dari satu sentuhan pada layar utama yang kompatibel dengan Android, implementasi tersebut:

• [C-2-1] HARUS melaporkan tombol fitur yang sesuai android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand yang sesuai dengan jenis layar sentuh tertentu pada perangkat.

Jika implementasi perangkat mengandalkan perangkat input eksternal seperti mouse atau trackball (yaitu tidak langsung menyentuh layar) untuk mendapatkan input pada layar utama yang kompatibel dengan Android dan memenuhi persyaratan sentuh palsu di bagian 7.2.5, implementasi tersebut akan:

• [C-3-1] TIDAK BOLEH melaporkan tombol fitur apa pun yang dimulai dengan android.hardware.touchscreen.
• [C-3-2] HARUS melaporkan android.hardware.faketouch saja.
• [C-3-3] HARUS melaporkan TOUCHSCREEN_NOTOUCH untuk kolom Configuration.touchscreen API.

7.2.5. Input Sentuhan Palsu

Antarmuka sentuh palsu menyediakan sistem input pengguna yang mendekati subset kemampuan layar sentuh. Misalnya, mouse atau remote control yang mendorong kursor pada layar mendekati sentuhan, tetapi mengharuskan pengguna untuk terlebih dahulu menunjuk atau memfokuskan kemudian mengklik. Banyak perangkat input seperti mouse, trackpad, mouse udara berbasis giroskop, gyro-pointer, joystick, dan trackpad multi-sentuh dapat mendukung interaksi sentuh palsu. Android menyertakan konstanta fitur android.hardware.faketouch, yang sesuai dengan perangkat input non-sentuh (berbasis pointer) dengan fidelitas tinggi seperti mouse atau trackpad yang dapat secara memadai mengemulasi input berbasis sentuh (termasuk dukungan gestur dasar), dan menunjukkan bahwa perangkat mendukung subset fungsi layar sentuh yang diemulasikan.

Jika implementasi perangkat tidak menyertakan layar sentuh, tetapi menyertakan sistem input pointer lain yang ingin disediakan, implementasi tersebut:

• HARUS mendeklarasikan dukungan untuk tombol fitur android.hardware.faketouch.

Jika implementasi perangkat mendeklarasikan dukungan untuk android.hardware.faketouch, implementasi perangkat akan:

• [C-1-1] HARUS melaporkan posisi layar X dan Y absolut 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 pointer yang turun atau naik di layar.
• [C-1-3] HARUS mendukung pointer ke bawah dan ke atas pada objek di layar, yang memungkinkan pengguna mengemulasikan ketukan pada objek di layar.
• [C-1-4] HARUS mendukung pointer ke bawah, pointer ke atas, mengarahkan ke bawah, lalu mengarahkan ke atas di tempat yang sama pada suatu objek di layar dalam batas waktu, yang memungkinkan pengguna untuk mengemulasikan ketukan dua kali pada suatu objek di layar.
• [C-1-5] HARUS mendukung pointer ke bawah pada titik arbitrer di layar, pointer bergerak ke titik arbitrer lainnya di layar, diikuti dengan pointer ke atas, yang memungkinkan pengguna mengemulasikan tarik sentuh.
• [C-1-6] HARUS mendukung pointer ke bawah agar pengguna dapat dengan cepat memindahkan objek ke posisi yang berbeda pada layar, kemudian pointer ke atas di layar, yang memungkinkan pengguna melempar sebuah objek ke layar.

Jika implementasi perangkat mendeklarasikan dukungan untuk android.hardware.faketouch.multitouch.distinct, implementasi tersebut:

• [C-2-1] HARUS mendeklarasikan dukungan untuk android.hardware.faketouch.
• [C-2-2] HARUS mendukung pelacakan yang berbeda untuk dua atau beberapa input pointer independen.

Jika implementasi perangkat mendeklarasikan dukungan untuk android.hardware.faketouch.multitouch.jazzhand, implementasi tersebut:

• [C-3-1] HARUS mendeklarasikan dukungan untuk android.hardware.faketouch.
• [C-3-2] HARUS mendukung pelacakan 5 yang berbeda (melacak tangan jari) atau lebih banyak input pointer secara independen sepenuhnya.

7.2.6. Dukungan Pengontrol Game

7.2.6.1. Pemetaan Tombol

Implementasi perangkat:

• [C-1-1] HARUS mampu memetakan peristiwa HID ke konstanta InputEvent terkait seperti yang tercantum dalam tabel di bawah. Implementasi Android upstream memenuhi persyaratan ini.

Jika implementasi perangkat menyematkan pengontrol atau menyertakan pengontrol terpisah dalam kotak yang akan menyediakan sarana untuk memasukkan semua peristiwa yang tercantum dalam tabel di bawah, penerapan tersebut akan:

• [C-2-1] HARUS mendeklarasikan tombol fitur android.hardware.gamepad

Tombol	Penggunaan HID2	Tombol Android
J1	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)
Kembali1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

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

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

4 MotionEvent

Kontrol Analog1	Penggunaan HID	Tombol Android
Pemicu Kiri	Info tambahan 0x02 0x00C5	AXIS_LTRIGGER
Pemicu Kanan	0x02 0x00C4	AXIS_RTRIGGER
Joystick Kiri	0x01 0x0030 0x01 0x0031	AXIS_X 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 untuk perangkat tertentu.

7.3. Sensor

Jika implementasi perangkat menyertakan jenis sensor tertentu yang memiliki API yang sesuai untuk developer pihak ketiga, implementasi perangkat HARUS mengimplementasikan API tersebut seperti yang dijelaskan dalam dokumentasi Android SDK dan dokumentasi Open Source Android tentang sensor.

Implementasi perangkat:

• [C-0-1] HARUS melaporkan ada atau tidak adanya sensor secara akurat per class 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 yang sesuai saat aplikasi mencoba mendaftarkan pemroses, tidak memanggil pemroses sensor saat sensor yang sesuai tidak ada; dll.).

Jika implementasi perangkat menyertakan jenis sensor tertentu yang memiliki API yang sesuai untuk developer pihak ketiga, implementasi tersebut:

• [C-1-1] HARUS melaporkan semua pengukuran sensor menggunakan nilai International System of Units (metrik) yang relevan untuk setiap jenis sensor seperti yang dijelaskan 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 sebesar 0 milidetik saat prosesor aplikasi aktif. Penundaan ini tidak termasuk penundaan pemfilteran.
• [C-1-3] HARUS melaporkan sampel sensor pertama dalam waktu 400 milidetik + 2 * sample_time sensor yang diaktifkan. Sampel ini bisa saja memiliki akurasi 0.
• [C-1-4] Untuk setiap API yang ditunjukkan oleh dokumentasi Android SDK sebagai sensor berkelanjutan, implementasi perangkat HARUS terus memberikan sampel data berkala yang SEHARUSNYA memiliki jitter di bawah 3%, dengan jitter didefinisikan sebagai simpangan baku dari perbedaan nilai stempel waktu yang dilaporkan di antara peristiwa berturut-turut.
• [C-1-5] HARUS memastikan bahwa aliran peristiwa sensor TIDAK BOLEH mencegah CPU perangkat memasuki status ditangguhkan atau bangun dari status ditangguhkan.
• [C-1-6] HARUS melaporkan waktu peristiwa dalam nanodetik seperti yang ditentukan dalam dokumentasi Android SDK, yang menunjukkan waktu terjadinya peristiwa dan disinkronkan dengan jam SystemClock.elapsedRealtimeNano().
• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mengalami error sinkronisasi stempel waktu di bawah 100 milidetik, dan SEHARUSNYA memiliki error sinkronisasi stempel waktu di bawah 1 milidetik.
• Jika beberapa sensor diaktifkan, konsumsi daya TIDAK BOLEH melebihi jumlah konsumsi daya masing-masing sensor yang dilaporkan.

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

Jika implementasi perangkat menyertakan jenis sensor tertentu yang memiliki API yang sesuai untuk developer pihak ketiga, implementasi tersebut:

• [C-1-6] HARUS menetapkan resolusi bukan nol untuk semua sensor, dan melaporkan nilai melalui metode API Sensor.getResolution().

Beberapa jenis sensor bersifat komposit, artinya dapat diperoleh dari data yang disediakan oleh satu atau beberapa sensor lain. (Contohnya mencakup sensor orientasi dan sensor akselerasi linear.)

Implementasi perangkat:

• HARUS menerapkan jenis sensor ini, jika jenis tersebut menyertakan sensor fisik prasyarat seperti yang dijelaskan dalam jenis sensor.

Jika implementasi perangkat menyertakan sensor komposit, implementasi tersebut:

• [C-2-1] HARUS menerapkan sensor seperti yang dijelaskan dalam dokumentasi Open Source Android tentang sensor komposit.

Jika implementasi perangkat menyertakan jenis sensor tertentu yang memiliki API yang sesuai untuk developer pihak ketiga dan sensor hanya melaporkan satu nilai, 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 diekspos ke developer pihak ketiga, implementasi tersebut:

• [C-4-1] TIDAK BOLEH menyertakan parameter kalibrasi tetap yang ditentukan pabrik dalam data yang diberikan.

Jika implementasi perangkat menyertakan kombinasi akselerometer 3 sumbu, sensor giroskop 3 sumbu, atau sensor magnetometer, implementasi tersebut adalah:

• [C-SR-2] SANGAT DIREKOMENDASIKAN untuk memastikan akselerometer, giroskop, dan magnetometer memiliki posisi relatif yang tetap, sehingga jika perangkat dapat ditransformasi (mis. 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 DIREKOMENDASIKAN untuk menyertakan akselerometer 3 sumbu.

Jika implementasi perangkat menyertakan akselerometer, implementasi tersebut:

• [C-1-1] HARUS dapat melaporkan peristiwa hingga frekuensi setidaknya 50 Hz.
• [C-1-3] HARUS mematuhi sistem koordinat sensor Android seperti yang dijelaskan dalam API Android.
• [C-1-4] HARUS mampu mengukur dari jatuh bebas hingga empat kali gravitasi(4g) atau lebih pada sumbu apa pun.
• [C-1-5] HARUS memiliki resolusi minimal 12-bit.
• [C-1-6] HARUS memiliki simpangan baku tidak lebih dari 0,05 m/dtk^, dengan simpangan baku harus dihitung per sumbu pada sampel yang dikumpulkan selama jangka waktu minimal 3 detik pada frekuensi pengambilan sampel tercepat.
• HARUS melaporkan peristiwa hingga minimal 200 Hz.
• HARUS memiliki resolusi minimal 16-bit.
• HARUS dikalibrasi saat digunakan jika karakteristiknya berubah selama siklus proses dan mendapatkan kompensasi, serta mempertahankan parameter kompensasi saat perangkat dimulai ulang.
• HARUS diberi kompensasi suhu.

Jika implementasi perangkat menyertakan akselerometer 3 sumbu, implementasi tersebut:

• [C-2-1] HARUS menerapkan dan melaporkan sensor TYPE_ACCELEROMETER.
• [C-SR-4] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan sensor komposit TYPE_SIGNIFICANT_MOTION.
• [C-SR-5] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan dan melaporkan sensor TYPE_ACCELEROMETER_UNCALIBRATED. Perangkat Android SANGAT DIREKOMENDASIKAN untuk memenuhi persyaratan ini sehingga dapat diupgrade ke rilis platform mendatang yang mungkin WAJIB dalam 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_DIREKOMENDASIKAN untuk mengimplementasikan dan melaporkan sensor TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

Jika implementasi perangkat menyertakan akselerometer 3 sumbu dan salah satu sensor komposit TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER akan diterapkan:

• [C-4-1] Jumlah konsumsi dayanya HARUS selalu kurang dari 4 mW.
• Masing-masing harus di bawah 2 mW dan 0,5 mW saat perangkat dalam kondisi dinamis atau statis.

Jika implementasi perangkat menyertakan akselerometer 3 sumbu dan sensor giroskop 3 sumbu, mereka akan:

• [C-5-1] HARUS menerapkan sensor gabungan TYPE_GRAVITY dan TYPE_LINEAR_ACCELERATION.
• [C-SR-7] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan sensor komposit TYPE_GAME_ROTATION_VECTOR.

Jika implementasi perangkat menyertakan akselerometer 3 sumbu, sensor giroskop 3 sumbu, dan sensor magnetometer, implementasi tersebut:

• [C-6-1] HARUS mengimplementasikan sensor komposit TYPE_ROTATION_VECTOR.

7.3.2. Magnetometer

Implementasi perangkat:

• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menyertakan magnetometer 3-sumbu (kompas).

Jika implementasi perangkat menyertakan magnetometer 3-sumbu, implementasi tersebut:

• [C-1-1] HARUS mengimplementasikan sensor TYPE_MAGNETIC_FIELD.
• [C-1-2] HARUS dapat melaporkan peristiwa hingga frekuensi setidaknya 10 Hz dan HARUS melaporkan peristiwa hingga setidaknya 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 disaturasi.
• [C-1-5] HARUS memiliki nilai offset besi keras kurang dari 700 μT dan SEHARUSNYA memiliki nilai di bawah 200 μT, dengan menempatkan magnetometer jauh dari bidang magnet dinamis (diinduksi arus) dan statis (diinduksi magnet).
• [C-1-6] HARUS memiliki resolusi yang sama atau lebih padat dari 0,6 μT.
• [C-1-7] HARUS mendukung kalibrasi online dan kompensasi bias hard iron, serta mempertahankan parameter kompensasi di antara perangkat dimulai ulang.
• [C-1-8] HARUS menerapkan kompensasi soft iron—kalibrasi dapat dilakukan saat digunakan atau selama produksi perangkat.
• [C-1-9] HARUS memiliki deviasi standar, yang dihitung per sumbu pada sampel yang dikumpulkan selama minimal 3 detik pada frekuensi sampling tercepat, tidak lebih dari 1,5 μT; HARUS memiliki standar deviasi tidak lebih besar dari 0,5 μT.
• [C-1-10] HARUS mengimplementasikan sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED.

Jika implementasi perangkat menyertakan magnetometer 3 sumbu, sensor akselerometer, dan sensor giroskop 3 sumbu, implementasi tersebut:

• [C-2-1] HARUS mengimplementasikan sensor komposit TYPE_ROTATION_VECTOR.

Jika implementasi perangkat menyertakan magnetometer 3-sumbu, akselerometer, implementasi tersebut:

• DAPAT menerapkan sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Jika implementasi perangkat menyertakan magnetometer 3 sumbu, akselerometer, dan sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR, implementasi tersebut:

• [C-3-1] HARUS mengkonsumsi kurang dari 10 mW.
• HARUS menggunakan kurang dari 3 mW saat sensor didaftarkan untuk mode batch pada 10 Hz.

7.3.3. GPS

Implementasi perangkat:

• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menyertakan penerima GPS/GNSS.

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

• [C-1-1] HARUS mendukung output lokasi pada kecepatan minimal 1 Hz saat diminta melalui LocationManager#requestLocationUpdate.
• [C-1-2] HARUS dapat menentukan lokasi dalam kondisi langit terbuka (sinyal kuat, multijalur yang dapat diabaikan, HDOP < 2) dalam 10 detik (waktu cepat untuk perbaikan pertama), saat terhubung ke koneksi internet 0,5 Mbps atau kecepatan data yang lebih cepat. Persyaratan ini biasanya dipenuhi dengan penggunaan beberapa bentuk teknik GPS/GNSS Terbantu atau Prediksi untuk meminimalkan waktu penguncian GPS/GNSS (Data Bantuan mencakup Waktu Referensi, Lokasi Referensi, dan Ephemeris/Jam Satelit).
  • [C-1-6] Setelah melakukan perhitungan 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, bahkan saat permintaan berikutnya dibuat tanpa koneksi data, dan/atau setelah penyalaan ulang.

• Dalam kondisi langit terbuka setelah menentukan lokasi, saat diam atau bergerak dengan akselerasi kurang dari 1 meter per detik kuadrat:

  • [C-1-3] HARUS dapat menentukan lokasi dalam jarak 20 meter, dan kecepatan berada dalam rentang 0,5 meter per detik, setidaknya 95% dari waktu.
  • [C-1-4] HARUS melacak dan melaporkan secara bersamaan melalui GnssStatus.Callback setidaknya 8 satelit dari satu konstelasi.
  • HARUS dapat melacak minimal 24 satelit secara bersamaan, dari beberapa rasi bintang (misalnya GPS + setidaknya salah satu dari Glonass, Beidou, Galileo).

• [C-SR-2] SANGAT DIREKOMENDASIKAN untuk terus mengirimkan output lokasi GPS/GNSS normal melalui GNSS Location Provider API selama panggilan telepon darurat.

• [C-SR-3] SANGAT DIREKOMENDASIKAN untuk melaporkan pengukuran GNSS dari semua konstelasi yang dilacak (seperti yang dilaporkan dalam pesan GnssStatus), dengan pengecualian SBAS.

• [C-SR-4] SANGAT DIREKOMENDASIKAN untuk melaporkan AGC dan Frekuensi pengukuran GNSS.

• [C-SR-5] SANGAT DIREKOMENDASIKAN untuk melaporkan semua perkiraan akurasi (termasuk Bearing, Kecepatan, dan Vertikal) sebagai bagian dari setiap lokasi GPS/GNSS.

• [C-SR-6] SANGAT DIREKOMENDASIKAN untuk melaporkan pengukuran GNSS, segera setelah ditemukan, meskipun lokasi yang dihitung dari GPS/GNSS belum dilaporkan.

• [C-SR-7] SANGAT DIREKOMENDASIKAN untuk melaporkan pseudorange dan laju pseudorange GNSS, yang, dalam kondisi langit terbuka setelah menentukan lokasi, saat diam atau bergerak dengan akselerasi kurang dari 0,2 meter per detik kuadrat kuadrat, cukup untuk menghitung posisi dalam jarak 20 meter, dan kecepatan dalam 0,2 meter per detik, setidaknya 95% dari waktu.

7.3.4. Giroskop

Implementasi perangkat:

• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menyertakan sensor giroskop.

Jika implementasi perangkat menyertakan giroskop, implementasi tersebut:

• [C-1-1] HARUS dapat melaporkan peristiwa hingga frekuensi setidaknya 50 Hz.
• [C-1-4] HARUS memiliki resolusi 12-bit atau lebih.
• [C-1-5] HARUS diberi kompensasi suhu.
• [C-1-6] HARUS dikalibrasi dan diberi kompensasi saat digunakan, dan mempertahankan parameter kompensasi di antara perangkat dimulai ulang.
• [C-1-7] HARUS memiliki varians tidak lebih dari 1e-7 rad^2 / s^2 per Hz (varian per Hz, atau rad^2 / s). Varians boleh bervariasi sesuai frekuensi pengambilan sampel, tetapi HARUS dibatasi oleh nilai ini. Dengan kata lain, jika Anda mengukur varian giroskop pada frekuensi sampling 1 Hz, varian tersebut SEHARUS tidak lebih dari 1e-7 rad^2/dtk^2.
• [C-SR-2] Error kalibrasi SANGAT DIREKOMENDASIKAN untuk kurang dari 0,01 rad/dtk saat perangkat tidak bergerak pada suhu kamar.
• [C-SR-3] SANGAT DIREKOMENDASIKAN untuk memiliki resolusi 16-bit atau lebih.
• HARUS melaporkan peristiwa hingga minimal 200 Hz.

Jika implementasi perangkat menyertakan giroskop 3 sumbu, implementasi tersebut:

• [C-2-1] HARUS mengimplementasikan sensor TYPE_GYROSCOPE.
• [C-SR-4] Sangat Direkomendasikan untuk mengimplementasikan sensor TYPE_GYROSCOPE_UNCALIBRATED.

Jika implementasi perangkat menyertakan giroskop dengan kurang dari 3 sumbu, implementasi tersebut:

• [C-3-1] HARUS menerapkan dan melaporkan sensor TYPE_GYROSCOPE_LIMITED_AXES.
• [C-SR-5] SANGAT_DIREKOMENDASIKAN untuk mengimplementasikan dan melaporkan sensor TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

Jika implementasi perangkat menyertakan giroskop 3 sumbu, sensor akselerometer, dan sensor magnetometer, implementasi tersebut:

• [C-4-1] HARUS mengimplementasikan sensor komposit TYPE_ROTATION_VECTOR.

Jika implementasi perangkat menyertakan akselerometer 3 sumbu dan sensor giroskop 3 sumbu, implementasi tersebut:

• [C-5-1] HARUS menerapkan sensor gabungan TYPE_GRAVITY dan TYPE_LINEAR_ACCELERATION.
• [C-SR-6] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan sensor komposit TYPE_GAME_ROTATION_VECTOR.

7.3.5. Barometer

Implementasi perangkat:

• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menyertakan barometer (sensor tekanan udara sekitar).

Jika implementasi perangkat menyertakan barometer, implementasi tersebut:

• [C-1-1] HARUS menerapkan dan melaporkan sensor TYPE_PRESSURE.
• [C-1-2] HARUS dapat mengirimkan event pada 5 Hz atau lebih.
• [C-1-3] HARUS diberi kompensasi suhu.
• [C-SR-2] SANGAT DIREKOMENDASIKAN untuk dapat melaporkan pengukuran tekanan dalam rentang 300 hPa hingga 1100 hPa.
• HARUS memiliki akurasi 1hPa.
• HARUS memiliki akurasi relatif 0,12 hPa di atas rentang 20 hPa (setara dengan ~1 m akurasi lebih dari ~ 200 m perubahan di permukaan laut).

7.3.6. Thermometer

Jika implementasi perangkat menyertakan termometer ruangan (sensor suhu), implementasi tersebut:

• [C-1-1] HARUS menentukan SENSOR_TYPE_AMBIENT_TEMPERATURE untuk sensor suhu sekitar dan sensor HARUS mengukur suhu sekitar (kamar/kabin kendaraan) tempat pengguna berinteraksi dengan perangkat dalam derajat Celsius.

Jika implementasi perangkat menyertakan sensor termometer yang mengukur suhu selain suhu sekitar, seperti suhu CPU, implementasi tersebut:

• [C-2-1] TIDAK BOLEH menentukan SENSOR_TYPE_AMBIENT_TEMPERATURE untuk sensor suhu.

Jika implementasi perangkat menyertakan sensor untuk memantau suhu kulit, implementasi perangkat akan:

• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung PowerManager.getThermalHeadroom API.

7.3.7. Fotometer

• Implementasi perangkat MUNGKIN menyertakan fotometer (sensor cahaya sekitar).

7.3.8. Sensor Kedekatan

• Implementasi perangkat MUNGKIN mencakup sensor kedekatan.

Jika implementasi perangkat menyertakan sensor kedekatan dan hanya melaporkan pembacaan biner "dekat" atau "jauh", maka:

• [C-1-1] HARUS mengukur kedekatan suatu objek dalam arah yang sama dengan layar. Artinya, sensor kedekatan HARUS diorientasikan untuk mendeteksi objek yang dekat dengan layar, karena intent utama jenis sensor ini adalah untuk mendeteksi ponsel yang digunakan oleh pengguna. Jika implementasi perangkat menyertakan sensor kedekatan dengan orientasi lainnya, implementasi tersebut TIDAK BOLEH dapat diakses melalui API ini.
• [C-1-2] HARUS memiliki akurasi 1-bit atau lebih.
• [C-1-3] HARUS menggunakan 0 cm sebagai nilai dekat dan 5 cm sebagai bacaan jauh.
• [C-1-4] HARUS melaporkan rentang dan resolusi maksimum 5.

7.3.9. Sensor Fidelitas Tinggi

Jika implementasi perangkat menyertakan serangkaian sensor berkualitas lebih tinggi seperti yang ditentukan di bagian ini, dan menyediakannya untuk aplikasi pihak ketiga, implementasi tersebut akan:

• [C-1-1] HARUS mengidentifikasi kemampuan melalui flag fitur android.hardware.sensor.hifi_sensors.

Jika implementasi perangkat mendeklarasikan android.hardware.sensor.hifi_sensors, implementasi perangkat akan:

• [C-2-1] HARUS memiliki sensor TYPE_ACCELEROMETER yang:

  • HARUS memiliki rentang pengukuran antara minimal -8 g dan +8 g, dan SANGAT DIREKOMENDASIKAN untuk memiliki rentang pengukuran antara minimal -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 yang tidak di atas 400 μg/✓Hz.
  • HARUS mengimplementasikan bentuk non-bangun dari sensor ini dengan kemampuan buffering minimal 3.000 peristiwa sensor.
  • HARUS memiliki konsumsi daya pengelompokan tidak lebih buruk dari 3 mW.
  • [C-SR-1] SANGAT DIREKOMENDASIKAN untuk memiliki bandwidth pengukuran 3 dB minimal 80% dari frekuensi Nyquist, dan spektrum white noise dalam bandwidth ini.
  • HARUS memiliki jalan acak dengan percepatan kurang dari 30 μg ✓Hz yang diuji pada suhu kamar.
  • HARUS memiliki perubahan bias vs. suhu ≤ +/- 1 mg/°C.
  • HARUS memiliki garis non-linearitas 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 dengan TYPE_ACCELEROMETER.

• [C-2-3] HARUS memiliki sensor TYPE_GYROSCOPE yang:

  • HARUS memiliki rentang pengukuran antara minimal -1.000 dan +1.000 dp.
  • HARUS memiliki resolusi pengukuran minimal 16 LSB/dp.
  • HARUS memiliki frekuensi pengukuran minimum 12,5 Hz atau lebih rendah.
  • HARUS memiliki frekuensi pengukuran maksimum 400 Hz atau lebih tinggi; HARUS mendukung SensorDirectChannel RATE_VERY_FAST.
  • HARUS memiliki derau pengukuran yang tidak di atas 0,014 °/s/{4}Hz.
  • [C-SR-2] SANGAT DIREKOMENDASIKAN untuk memiliki bandwidth pengukuran 3 dB minimal 80% dari frekuensi Nyquist, dan spektrum white noise dalam bandwidth ini.
  • HARUS memiliki kecepatan berjalan acak kurang dari 0,001 °/dtk }Hz yang diuji pada suhu kamar.
  • HARUS memiliki perubahan bias vs. suhu ≤ +/- 0,05 °/ s / °C.
  • HARUS memiliki perubahan sensitivitas vs. suhu ≤ 0,02% / °C.
  • HARUS memiliki garis non-linearitas terbaik ≤ 0,2%.
  • SEHARUSNYA memiliki kepadatan kebisingan ≤ 0,007 °/s/✓Hz.
  • HARUS memiliki error kalibrasi kurang dari 0,002 rad/dtk dalam rentang suhu 10 ~ 40 °C saat perangkat diam.
  • HARUS memiliki sensitivitas g kurang dari 0,1 °/dtk/g.
  • HARUS memiliki sensitivitas lintas sumbu < 4,0 % dan variasi sensitivitas sumbu silang < 0,3% dalam rentang suhu pengoperasian perangkat.

• [C-2-4] HARUS memiliki TYPE_GYROSCOPE_UNCALIBRATED dengan persyaratan kualitas yang sama seperti 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 yang tidak di atas 0,5 uT.

• [C-2-6] HARUS memiliki TYPE_MAGNETIC_FIELD_UNCALIBRATED dengan persyaratan kualitas yang sama seperti TYPE_GEOMAGNETIC_FIELD, dan sebagai tambahan:

  • HARUS mengimplementasikan bentuk non-bangun dari sensor ini dengan kemampuan buffering minimal 600 peristiwa sensor.
  • [C-SR-3] SANGAT DIREKOMENDASIKAN untuk memiliki spektrum white noise dari 1 Hz hingga setidaknya 10 Hz jika kecepatan laporannya 50 Hz atau lebih tinggi.

• [C-2-7] HARUS memiliki sensor TYPE_PRESSURE yang:

  • HARUS memiliki rentang pengukuran minimal antara 300 dan 1100 hPa.
  • HARUS memiliki resolusi pengukuran minimal 80 LSB/hPa.
  • HARUS memiliki frekuensi pengukuran minimum 1 Hz atau lebih rendah.
  • HARUS memiliki frekuensi pengukuran maksimum 10 Hz atau lebih tinggi.
  • HARUS memiliki derau pengukuran yang tidak lebih dari 2 Pa/✓Hz.
  • HARUS mengimplementasikan bentuk non-bangun dari sensor ini dengan kemampuan buffering minimal 300 peristiwa sensor.
  • HARUS memiliki konsumsi daya pengelompokan tidak lebih buruk dari 2 mW.

• [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 mengimplementasikan bentuk non-bangun dari sensor ini dengan kemampuan buffering minimal 100 peristiwa sensor.
  • HARUS memiliki konsumsi daya tidak lebih buruk dari 0,5 mW saat perangkat statis dan 1,5 mW saat perangkat bergerak.
  • HARUS memiliki konsumsi daya pengelompokan tidak lebih buruk dari 4 mW.

• [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 untuk peristiwa fisik yang sama yang dilaporkan oleh Akselerometer, Giroskop, dan Magnetometer HARUS dalam waktu 2,5 milidetik satu sama lain. Stempel waktu peristiwa untuk peristiwa fisik yang sama yang dilaporkan oleh Akselerometer dan Giroskop HARUS dalam waktu 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 dalam waktu 1 milidetik jika terjadi error.

• [C-2-15] HARUS mengirimkan sampel ke aplikasi dalam waktu 5 milidetik sejak data tersedia pada salah satu sensor fisik di atas ke aplikasi.

• [C-2-16] TIDAK BOLEH memiliki konsumsi daya yang lebih tinggi dari 0,5 mW saat perangkat statis dan 2,0 mW saat perangkat bergerak jika kombinasi apa pun dari sensor berikut diaktifkan:

  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_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 diambil oleh seluruh rantai sensor—sensor, sirkuit pendukung apa pun, sistem pemrosesan sensor khusus apa pun, dll.

Jika implementasi perangkat menyertakan dukungan sensor langsung, implementasi tersebut:

• [C-3-1] HARUS mendeklarasikan dukungan jenis saluran langsung dan tingkat rasio laporan 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 mendeklarasikan dukungan untuk saluran langsung sensor.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• HARUS mendukung pelaporan peristiwa melalui saluran langsung sensor untuk sensor utama (varian non-bangun) 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 latar belakang tambahan tentang Mengukur Keamanan Buka Kunci Biometrik, lihat dokumentasi Mengukur Keamanan Biometrik.

Jika implementasi perangkat menyertakan layar kunci yang aman, implementasi tersebut:

• HARUS menyertakan sensor biometrik

Sensor biometrik dapat diklasifikasikan sebagai Class 3 (sebelumnya Kuat), Class 2 (sebelumnya Lemah), atau Class 1 (sebelumnya Kepraktisan) berdasarkan tingkat penerimaan spoof dan penipu, serta pada keamanan pipeline biometrik. Klasifikasi ini menentukan kemampuan sensor biometrik untuk berinteraksi dengan platform dan 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 Kelas 2 dan Kelas 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, aplikasi tersebut:

• [C-4-1] HARUS memenuhi persyaratan biometrik untuk Kelas 3 atau Kelas 2 sebagaimana ditetapkan dalam dokumen ini.
• [C-4-2] HARUS mengenali dan mematuhi setiap nama parameter yang ditetapkan sebagai konstanta dalam class Authenticator dan semua kombinasinya. Sebaliknya, TIDAK BOLEH menerima atau mengenali konstanta bilangan bulat yang diteruskan ke metode canAuthenticate(int) dan setAllowedAuthenticators(int) selain yang didokumentasikan sebagai konstanta publik di Authenticator dan kombinasinya.
• [C-4-3] HARUS menerapkan tindakan ACTION_BIOMETRIC_ENROLL pada perangkat yang memiliki biometrik Class 3 atau Class 2. Tindakan ini HARUS menunjukkan titik entri pendaftaran untuk biometrik Kelas 3 atau Kelas 2.

Jika implementasi perangkat mendukung biometrik pasif, implementasi tersebut:

• [C-5-1] Secara default HARUS memerlukan langkah konfirmasi tambahan (misalnya, menekan tombol).
• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk memiliki setelan yang memungkinkan pengguna mengganti preferensi aplikasi dan selalu mengharuskan langkah konfirmasi yang menyertainya.
• [C-SR-2] SANGAT DIREKOMENDASIKAN untuk mendapatkan tindakan konfirmasi yang aman sehingga sistem operasi atau kernel tidak dapat melakukan spoofing. Misalnya, hal ini berarti tindakan konfirmasi berdasarkan tombol fisik dirutekan melalui pin input/output tujuan umum (GPIO) khusus input dari secure element (SE) yang tidak dapat didorong dengan cara lain selain penekanan tombol fisik.
• [C-5-2] Selain itu HARUS menerapkan alur autentikasi implisit (tanpa langkah konfirmasi) yang sesuai dengan setConfirmationRequired(boolean), yang dapat ditetapkan oleh aplikasi untuk alur login.

Jika implementasi perangkat memiliki beberapa sensor biometrik, implementasi tersebut:

• [C-SR-3] SANGAT DIREKOMENDASIKAN untuk hanya mewajibkan satu biometrik yang dikonfirmasi per autentikasi (misalnya, jika sensor sidik jari dan wajah tersedia di perangkat, onAuthenticationSucceeded harus dikirim setelah salah satu dari keduanya dikonfirmasi).

Agar implementasi perangkat mengizinkan akses ke kunci keystore untuk aplikasi pihak ketiga, implementasi tersebut:

• [C-6-1] HARUS memenuhi persyaratan untuk Kelas 3 seperti yang didefinisikan di bagian ini di bawah.
• [C-6-2] HARUS menampilkan biometrik Class 3 saja saat autentikasi memerlukan BIOMETRIC_STRONG, atau autentikasi dipanggil dengan CryptoObject.

Jika implementasi perangkat ingin memperlakukan sensor biometrik sebagai Class 1 (sebelumnya Kemudahan), fungsi tersebut:

• [C-1-1] HARUS memiliki tingkat penerimaan palsu kurang dari 0,002%.
• [C-1-2] HARUS mengungkapkan bahwa mode ini mungkin kurang aman dibandingkan PIN, pola, atau sandi yang kuat, dan dengan jelas menyebutkan risiko pengaktifannya, jika tingkat penerimaan spoofing dan penipu lebih tinggi dari 7% seperti yang diukur oleh Protokol Pengujian Biometrik Android.
• [C-1-9] HARUS menantang pengguna untuk autentikasi utama yang direkomendasikan (misalnya PIN, pola, sandi) setelah tidak lebih dari dua puluh uji coba palsu dan tidak kurang dari waktu backoff sembilan puluh detik untuk verifikasi biometrik - dengan uji coba palsu adalah uji coba dengan kualitas gambar yang memadai (BIOMETRIC_ACQUIRED_GOOD) yang tidak cocok dengan biometrik yang terdaftar.
• [C-SR-4] SANGAT DIREKOMENDASIKAN untuk menurunkan jumlah total uji coba palsu untuk verifikasi biometrik yang ditentukan dalam [C-1-9] jika tingkat penerimaan spoof dan penipu lebih tinggi dari 7% dengan pengukuran oleh Protokol Pengujian Biometrik Android.
• [C-1-3] Percobaan pembatasan kapasitas untuk verifikasi biometrik - jika uji coba palsu adalah percobaan dengan kualitas rekaman yang memadai (BIOMETRIC_ACQUIRED_GOOD) yang tidak cocok dengan biometrik yang terdaftar.
• [C-SR-5] SANGAT DIREKOMENDASIKAN untuk mencoba pembatasan kapasitas minimal 30 detik setelah lima uji coba palsu untuk verifikasi biometrik untuk jumlah maksimum uji coba palsu per [C-1-9] - di mana uji coba palsu adalah uji coba dengan kualitas tangkapan yang memadai (BIOMETRIC_ACQUIRED_GOOD) yang tidak cocok dengan biometrik yang terdaftar.
• [C-SR-6] SANGAT DIREKOMENDASIKAN untuk memiliki semua logika pembatasan kapasitas di TEE.

• [C-1-10] HARUS menonaktifkan biometrik setelah backoff autentikasi utama dipicu terlebih dahulu, seperti dijelaskan dalam [C-0-2] pasal 9.11.

• [C-1-11] HARUS memiliki tingkat penerimaan spoof dan penipu tidak lebih tinggi dari 30%, dengan (1) tingkat penerimaan spoof dan imposter untuk spesies instrumen serangan presentasi Level A (PAI) tidak lebih tinggi dari 30%, dan (2) tingkat penerimaan spoof dan imposter untuk spesies Biometrik Level B tidak lebih tinggi dari 40%, sebagaimana diukur berdasarkan Android.

• [C-1-4] HARUS mencegah penambahan biometrik baru tanpa terlebih dahulu membuat rantai kepercayaan dengan meminta pengguna mengonfirmasi keberadaan atau menambahkan kredensial perangkat baru (PIN/pola/sandi) yang diamankan oleh TEE; implementasi Project Open Source Android menyediakan mekanisme dalam framework untuk melakukannya.

• [C-1-5] HARUS menghapus sepenuhnya semua data biometrik yang dapat diidentifikasi untuk pengguna saat akun pengguna tersebut dihapus (termasuk melalui reset ke setelan pabrik).

• [C-1-6] HARUS mematuhi masing-masing tanda untuk biometrik tersebut (yaitu DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE , atau DevicePolicymanager.KEYGUARD_DISABLE_IRIS ).

• [C-1-7] HARUS menantang pengguna untuk autentikasi utama yang direkomendasikan (misalnya PIN, pola, sandi) sekali setiap 24 jam atau kurang. Catatan: Mengupgrade perangkat yang diluncurkan di Android versi 9 atau yang lebih lama HARUS menantang pengguna untuk meminta autentikasi utama yang direkomendasikan (misalnya, PIN, pola, sandi) setiap 72 jam atau kurang.

• [C-1-8] HARUS menantang pengguna untuk autentikasi utama yang direkomendasikan (misalnya: PIN, pola, sandi) atau biometrik Kelas 3 (KUAT) setelah salah satu hal berikut:

  • periode waktu tunggu tidak ada aktivitas 4 jam, ATAU
  • 3 upaya autentikasi biometrik gagal.
  • Periode waktu tunggu tidak ada aktivitas dan jumlah autentikasi yang gagal direset setelah konfirmasi kredensial perangkat berhasil. Catatan: Perangkat upgrade yang diluncurkan di Android versi 9 atau yang lebih lama DAPAT dikecualikan dari C-1-8.

• [C-SR-7] SANGAT DIREKOMENDASIKAN untuk menggunakan logika dalam framework yang disediakan oleh Project Open Source Android guna menerapkan batasan yang ditentukan di [C-1-7] dan [C-1-8] untuk perangkat baru.

• [C-SR-8] SANGAT DIREKOMENDASIKAN untuk memiliki rasio penolakan palsu kurang dari 10%, seperti yang diukur di perangkat.

• [C-SR-9] SANGAT DIREKOMENDASIKAN untuk memiliki latensi di bawah 1 detik, yang diukur dari saat biometrik terdeteksi, hingga layar tidak terkunci, untuk setiap biometrik yang terdaftar.

Jika implementasi perangkat ingin memperlakukan sensor biometrik sebagai Class 2 (sebelumnya Lemah), sensor tersebut:

• [C-2-1] HARUS memenuhi semua persyaratan untuk Kelas 1 di atas.

• [C-2-2] HARUS memiliki tingkat penerimaan spoof dan penipu tidak lebih tinggi dari 20%, dengan (1) tingkat penerimaan spoof dan imposter untuk spesies instrumen serangan presentasi Level A (PAI) yang tidak lebih tinggi dari 20%, dan (2) tingkat penerimaan spoof dan imposter spesies Biometrik Level B tidak lebih tinggi dari 30 , yang diukur oleh Protokol Biometrik Level B .

• [C-2-3] HARUS melakukan pencocokan biometrik di lingkungan eksekusi yang terisolasi di luar ruang kernel atau pengguna Android, seperti Trusted Execution Environment (TEE), atau pada chip dengan saluran aman ke lingkungan eksekusi yang terisolasi atau di Protected Virtual Machine yang memenuhi persyaratan dalam Pasal 9.17.
• [C-2-4] HARUS memiliki semua data yang dapat diidentifikasi yang dienkripsi dan diautentikasi secara kriptografis sehingga tidak dapat diperoleh, dibaca, atau diubah di luar lingkungan eksekusi yang terisolasi atau chip dengan saluran aman ke lingkungan eksekusi terpisah seperti yang didokumentasikan dalam panduan implementasi di situs Proyek Open Source Android atau Mesin Virtual Terlindungi 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 berlangsung:
  • 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 Protected Virtual Machine yang dikontrol oleh hypervisor yang memenuhi persyaratan dalam Pasal 9.17.
  • Untuk solusi kamera tunggal RGB, frame kamera DAPAT dibaca di luar lingkungan eksekusi yang terisolasi untuk mendukung operasi seperti pratinjau untuk pendaftaran, tetapi TIDAK BOLEH diubah.
• [C-2-6] TIDAK BOLEH memungkinkan aplikasi pihak ketiga membedakan antara pendaftaran biometrik individual.
• [C-2-7] TIDAK BOLEH mengizinkan akses tidak terenkripsi ke data biometrik yang dapat diidentifikasi atau data apa pun yang berasal darinya (seperti embedding) ke Pemroses Aplikasi di luar konteks TEE atau Protected Virtual Machine yang dikontrol oleh hypervisor yang memenuhi persyaratan dalam Pasal 9.17. Perangkat yang diupgrade 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 sistem operasi atau kernel yang disusupi tidak dapat mengizinkan data dimasukkan secara langsung untuk mengautentikasi secara keliru sebagai pengguna. Catatan: Jika implementasi perangkat sudah diluncurkan di Android versi 9 atau yang lebih lama dan tidak dapat memenuhi persyaratan C-2-8 melalui update software sistem, implementasi tersebut DAPAT dikecualikan dari persyaratan tersebut.

• [C-SR-10] SANGAT DIREKOMENDASIKAN untuk menyertakan deteksi keaktifan bagi 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 Strong), sensor tersebut:

• [C-3-1] HARUS memenuhi semua persyaratan Kelas 2 di atas, kecuali untuk [C-1-7] dan [C-1-8].
• [C-3-2] HARUS memiliki implementasi keystore yang didukung hardware.
• [C-3-3] HARUS memiliki tingkat penerimaan spoof dan penipu tidak lebih tinggi dari 7%, dengan (1) tingkat penerimaan spoof dan imposter untuk spesies instrumen serangan presentasi Level A (PAI) tidak lebih tinggi dari 7%, dan (2) tingkat penerimaan spoof dan imposter untuk spesies PAI Level B tidak lebih tinggi dari 20%, yang diukur oleh Protokol Android, yang diukur oleh Protokol Android.
• [C-3-4] HARUS menantang pengguna untuk autentikasi utama yang direkomendasikan (misalnya PIN, pola, sandi) sekali setiap 72 jam atau kurang.
• [C-3-5] HARUS membuat ulang ID Authenticator untuk semua biometrik Kelas 3 yang didukung di perangkat jika ada yang didaftarkan ulang.
• [C-3-6] Harus mengaktifkan kunci keystore yang didukung biometrik untuk aplikasi pihak ketiga.

Jika implementasi perangkat berisi sensor sidik jari di bawah layar (UDFPS), penerapan tersebut:

• [C-SR-11] SANGAT DIREKOMENDASIKAN untuk mencegah area yang dapat disentuh pada UDFPS mengganggu navigasi 3 tombol( yang mungkin diperlukan beberapa pengguna untuk tujuan aksesibilitas).

7.3.11. Sensor Pose

Implementasi perangkat:

• MUNGKIN mendukung sensor pose dengan 6 derajat kebebasan.

Jika implementasi perangkat mendukung sensor pose dengan 6 derajat kebebasan, implementasi tersebut:

• [C-1-1] HARUS mengimplementasikan dan melaporkan sensor TYPE_POSE_6DOF.
• [C-1-2] HARUS lebih akurat daripada vektor rotasi saja.

7.3.12. Sensor Sudut Engsel

Jika implementasi perangkat mendukung sensor sudut engsel, implementasi tersebut:

• [C-1-1] HARUS menerapkan dan melaporkan TYPE_HINGLE_ANGLE.
• [C-1-2] HARUS mendukung setidaknya dua pembacaan antara 0 dan 360 derajat (termasuk 0 dan 360 derajat).
• [C-1-3] HARUS menampilkan sensor bangun untuk getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

7.3.13. IEEE 802.1.15.4 (UWB)

Jika implementasi perangkat menyertakan dukungan untuk 802.1.15.4 dan mengekspos fungsinya ke aplikasi pihak ketiga, implementasi tersebut:

7.4. Konektivitas Data

7.4.1. Telepon

“Telepon” seperti yang digunakan oleh Android API dan dokumen ini secara khusus merujuk pada hardware yang terkait dengan melakukan panggilan suara dan mengirim pesan SMS , atau membuat data seluler melalui jaringan seluler (misalnya, GSM, CDMA, LTE, NR) atau CDMA. Perangkat yang mendukung "Telepon" dapat memilih untuk menawarkan beberapa atau semua layanan panggilan, pesan, dan data yang sesuai dengan produk tersebut.

melalui jaringan GSM atau CDMA. Meskipun panggilan suara ini mungkin atau tidak dialihkan,panggilan tersebut ditujukan untuk tujuan Android yang dianggap independen dari konektivitas data apa pun yang mungkin diimplementasikan menggunakan jaringan yang sama. Dengan kata lain,API dan fungsi "telepon" Android secara khusus merujuk ke panggilan suara dan SMS. Misalnya, implementasi perangkat yang tidak dapat melakukan panggilan atau mengirim/menerima pesan SMS tidak dianggap sebagai perangkat telepon, terlepas dari apakah perangkat tersebut menggunakan jaringan seluler untuk konektivitas data atau tidak.

• Android MUNGKIN digunakan pada perangkat yang tidak termasuk hardware telepon. Artinya, Android kompatibel dengan perangkat selain ponsel.

Jika implementasi perangkat mencakup telepon GSM atau CDMA, implementasi tersebut:

• [C-1-1] HARUS mendeklarasikan tombol fitur android.hardware.telephony dan flag sub-fitur lainnya sesuai dengan teknologi tersebut.
• [C-1-2] HARUS menerapkan dukungan penuh untuk API untuk teknologi tersebut.
• HARUS mengizinkan semua jenis layanan seluler yang tersedia (2G, 3G, 4G, 5G, dll.) selama panggilan darurat (terlepas dari jenis jaringan yang disetel oleh SetAllowedNetworkTypeBitmap()).

Jika implementasi perangkat tidak menyertakan hardware telepon, implementasi tersebut:

• [C-2-1] HARUS mengimplementasikan API lengkap sebagai tanpa pengoperasian.

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 tombol fitur android.hardware.telephony.euicc.

Jika penerapan perangkat tidak menetapkan properti sistem ro.telephony.iwlan\_operation\_mode ke 'lama', penerapan tersebut:

• [C-4-1] TIDAK BOLEH melaporkan 'NETWORK_TYPE_IWLAN' melalui NetworkRegistrationInfo#getAccessNetworkTechnology() saat 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 layanan komunikasi lengkap (RCS), implementasi perangkat tersebut diharapkan memenuhi persyaratan operator seluler terkait penggunaan satu pendaftaran IMS untuk semua traffic sinyal IMS, implementasi tersebut:

• [C-5-1] HARUS mendeklarasikan tombol fitur android.hardware.telephony.ims dan memberikan implementasi lengkap ImsService API untuk User Capability Exchange API MMTEL dan RCS.
• [C-5-2] HARUS mendeklarasikan tombol fitur android.hardware.telephony.ims.singlereg dan memberikan implementasi lengkap SipTransport API, GbaService API, indikasi pemilik khusus menggunakan IRadio 1.6 HAL, dan menyediakan 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 SmsManager API saat mengirim dan menerima pesan SMS dan MMS. Implementasi referensi AOSP dalam paket/aplikasi/Pesan memenuhi persyaratan ini.
• [C-6-3] Aplikasi yang merespons Intent#ACTION_DIAL HARUS mendukung entri kode telepon 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 mewakili semua SubscriptionInfo dengan UUID grup yang setara sebagai satu langganan di semua kemampuan yang terlihat oleh pengguna yang menampilkan dan mengontrol informasi kartu SIM. Contoh kemampuan tersebut mencakup antarmuka setelan yang cocok Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS atau EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS.
• [C-6-6] TIDAK BOLEH menampilkan atau mengizinkan kontrol atas SubscriptionInfo apa pun dengan UUID grup dan bit oportunistik non-null dalam kemampuan yang terlihat oleh pengguna yang memungkinkan konfigurasi atau kontrol setelan kartu SIM.

Jika implementasi perangkat melaporkan fitur android.hardware.telephony dan memberikan status bar sistem, maka:

• [C-7-1] HARUS memilih langganan aktif yang representatif untuk UUID grup tertentu untuk ditampilkan kepada pengguna dalam kemampuan apa pun yang menyediakan informasi status SIM. Contoh kemampuan tersebut mencakup ikon sinyal seluler status bar atau kartu setelan cepat.
• [C-SR-1] SANGAT DIREKOMENDASIKAN bahwa langganan representatif dipilih untuk menjadi langganan data aktif kecuali jika perangkat melakukan panggilan suara, dan selama itu SANGAT DIREKOMENDASIKAN bahwa langganan perwakilan adalah langganan Voice aktif.

Jika implementasi perangkat melaporkan fitur android.hardware.telephony, maka:

• [C-6-7] HARUS mampu membuka dan secara serentak memanfaatkan jumlah maksimum saluran logis (total 20) untuk setiap UICC per ETSI TS 102 221.
• [C-6-8] TIDAK BOLEH menerapkan salah satu perilaku berikut pada aplikasi operator aktif (sebagaimana ditetapkan oleh TelephonyManager#getCarrierServicePackageName) secara otomatis atau tanpa konfirmasi pengguna secara eksplisit:
  • Mencabut atau membatasi akses jaringan
  • Mencabut izin
  • Membatasi eksekusi aplikasi latar belakang atau latar depan di luar fitur pengelolaan daya yang sudah ada dan disertakan dalam AOSP
  • Menonaktifkan atau meng-uninstal aplikasi

Jika implementasi perangkat melaporkan fitur android.hardware.telephony dan semua aktif, langganan non-oportunistik yang berbagi UUID grup akan dinonaktifkan, dihapus secara fisik dari perangkat, atau ditandai oportunistik, maka perangkat:

• [C-8-1] HARUS otomatis menonaktifkan semua langganan oportunistik aktif yang tersisa dalam grup yang sama.

Jika implementasi perangkat mencakup telepon GSM, tetapi bukan telepon CDMA, implementasi tersebut:

• [C-9-1] TIDAK BOLEH mendeklarasikan PackageManager#FEATURE_TELEPHONY_CDMA.
• [C-9-2] HARUS menampilkan IllegalArgumentException pada upaya menetapkan jenis jaringan 3GPP2 apa pun dalam bitmask jenis jaringan yang disukai atau diizinkan.
• [C-9-3] HARUS menampilkan string kosong dari TelephonyManager#getMeid.

Jika implementasi perangkat mendukung eUICC dengan beberapa port dan profil, implementasi tersebut:

• [C-10-1] HARUS mendeklarasikan tombol fitur android.hardware.telephony.euicc.mep.

7.4.1.1. Kompatibilitas Pemblokiran Nomor

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

• [C-1-1] HARUS menyertakan dukungan pemblokiran nomor
• [C-1-2] HARUS sepenuhnya mengimplementasikan BlockedNumberContract dan API yang sesuai 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 ketika 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 dalam aplikasi telepon yang diinstal sebelumnya.

• [C-1-5] TIDAK BOLEH menulis ke Penyedia telepon untuk pesan yang diblokir.

• [C-1-6] HARUS mengimplementasikan UI pengelolaan angka 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 berasumsi bahwa pengguna utama memiliki kontrol penuh atas layanan telepon, satu instance, pada perangkat. Semua UI terkait pemblokiran HARUS disembunyikan untuk pengguna sekunder dan daftar yang diblokir HARUS tetap dipatuhi.

• HARUS migrasikan nomor yang diblokir ke penyedia saat perangkat diupdate ke Android 7.0.

• HARUS menyediakan kemampuan pengguna untuk menampilkan panggilan yang diblokir di aplikasi dialer yang telah diinstal sebelumnya.

7.4.1.2. API Telekomunikasi

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

• [C-1-1] HARUS mendukung ConnectionService API yang dijelaskan dalam SDK.
• [C-1-2] HARUS menampilkan panggilan masuk baru dan memberikan kemampuan pengguna untuk menerima atau menolak panggilan masuk saat pengguna sedang dalam panggilan yang dilakukan oleh aplikasi pihak ketiga yang tidak mendukung fitur penangguhan yang ditentukan melalui CAPABILITY_SUPPORT_HOLD.
• [C-1-3] HARUS memiliki aplikasi yang mengimplementasikan InCallService.

• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk memberi tahu pengguna bahwa menjawab panggilan masuk akan menghentikan panggilan yang sedang berlangsung.

  Implementasi AOSP memenuhi persyaratan ini dengan notifikasi pendahuluan yang menunjukkan kepada pengguna bahwa menjawab panggilan masuk akan menyebabkan panggilan lainnya dihentikan.

• [C-SR-2] SANGAT DIREKOMENDASIKAN untuk melakukan pramuat aplikasi telepon default yang menampilkan entri log panggilan dan nama aplikasi pihak ketiga dalam log panggilannya saat aplikasi pihak ketiga menetapkan kunci tambahan EXTRA_LOG_SELF_MANAGED_CALLS pada PhoneAccount-nya ke true.

• [C-SR-3] SANGAT DIREKOMENDASIKAN untuk menangani peristiwa KEYCODE_MEDIA_PLAY_PAUSE dan KEYCODE_HEADSETHOOK headset audio untuk android.telecom API seperti di bawah ini:

  • Panggil Connection.onDisconnect() saat penekanan singkat pada peristiwa tombol terdeteksi selama panggilan yang sedang berlangsung.
  • Panggil Connection.onAnswer() saat penekanan singkat pada peristiwa tombol terdeteksi selama panggilan masuk.
  • Panggil Connection.onReject() jika penekanan lama peristiwa tombol terdeteksi selama panggilan masuk.
  • Alihkan status nonaktif CallAudioState.

7.4.1.3. Offload Keepalive NAT-T Seluler

Implementasi perangkat:

• HARUS menyertakan dukungan untuk Cellular keepalive offload.

Jika implementasi perangkat menyertakan dukungan untuk keepalive offload Cellular dan menampilkan fungsi tersebut ke aplikasi pihak ketiga, implementasi tersebut:

• [C-1-1] HARUS mendukung SocketKeepAlive API.
• [C-1-2] HARUS mendukung setidaknya satu slot keepalive serentak melalui seluler.
• [C-1-3] HARUS mendukung slot keepalive seluler serentak sebanyak yang didukung oleh Cellular Radio HAL.
• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung setidaknya tiga slot keepalive seluler per instance radio.

Jika implementasi perangkat tidak menyertakan dukungan untuk keepalive offload seluler, penerapan tersebut:

• [C-2-1] HARUS menampilkan ERROR_UNSUPPORTED.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementasi perangkat:

• HARUS menyertakan dukungan untuk satu atau beberapa bentuk 802.11.

Jika implementasi perangkat menyertakan dukungan untuk 802.11 dan menampilkan fungsinya ke aplikasi pihak ketiga, implementasi tersebut:

• [C-1-1] HARUS mengimplementasikan Android API yang sesuai.
• [C-1-2] HARUS melaporkan tombol fitur hardware android.hardware.wifi.
• [C-1-3] HARUS mengimplementasikan multicast API seperti yang dijelaskan dalam dokumentasi SDK.
• [C-1-4] HARUS mendukung multicast DNS (mDNS) dan TIDAK BOLEH memfilter paket mDNS (224.0.0.251 atau ff02::fb) kapan saja operasi, termasuk saat layar tidak dalam status aktif, kecuali menghapus atau memfilter paket ini diperlukan agar tetap berada dalam rentang konsumsi daya yang diwajibkan oleh peraturan yang berlaku untuk target pasar. Untuk implementasi perangkat Android Televisi, bahkan saat dalam status daya standby.
• [C-1-5] TIDAK BOLEH memperlakukan panggilan metode API WifiManager.enableNetwork() sebagai indikasi yang memadai untuk mengganti Network yang sedang aktif yang digunakan secara default untuk traffic aplikasi dan ditampilkan oleh ConnectivityManager metode API seperti getActiveNetwork dan registerDefaultNetworkCallback. Dengan kata lain, mereka MUNGKIN hanya menonaktifkan akses Internet yang disediakan oleh penyedia jaringan lain (misalnya data seluler) jika mereka berhasil memvalidasi bahwa jaringan Wi-Fi menyediakan akses Internet.
• [C-1-6] SANGAT DIREKOMENDASIKAN 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, beralihlah ke jaringan lain yang tersedia (mis. data seluler) yang menyediakan akses Internet.
• [C-1-7] HARUS mengacak alamat MAC sumber dan nomor urut frame permintaan pemeriksaan, sekali di awal setiap pemindaian, sementara STA terputus.
• [C-1-8] HARUS menggunakan satu alamat MAC yang konsisten (TIDAK BOLEH mengacak alamat MAC di tengah proses pemindaian).
• [C-1-9] HARUS mengiterasi nomor urut permintaan pemeriksaan seperti biasa (secara berurutan) di antara permintaan pemeriksaan dalam pemindaian.
• [C-1-10] HARUS mengacak nomor urut permintaan Satelit antara permintaan pemeriksaan terakhir dari pemindaian dan permintaan pemeriksaan pertama dari pemindaian berikutnya.
• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mengacak alamat MAC sumber yang digunakan untuk semua komunikasi STA ke Titik Akses (AP) saat mengaitkan dan mengaitkannya.
  • Perangkat HARUS menggunakan alamat MAC acak yang berbeda untuk setiap SSID (FQDN untuk Passpoint) yang berkomunikasi dengannya.
  • Perangkat HARUS memberikan opsi kepada pengguna untuk mengontrol pengacakan per SSID (FQDN untuk Passpoint) dengan opsi yang tidak diacak dan diacak, dan HARUS menetapkan mode default bagi konfigurasi Wi-Fi baru agar diacak.
• [C-SR-2] SANGAT DIREKOMENDASIKAN untuk menggunakan BSSID acak untuk setiap AP yang mereka buat.
  • Alamat MAC HARUS diacak dan dipertahankan per SSID yang digunakan oleh AP.
  • PERANGKAT DAPAT memberikan opsi kepada pengguna untuk menonaktifkan fitur ini. Jika opsi seperti itu diberikan, pengacakan HARUS diaktifkan secara default.

Jika implementasi perangkat menyertakan dukungan untuk mode hemat daya Wi-Fi seperti yang ditentukan dalam standar IEEE 802.11, implementasi tersebut:

• HARUS nonaktifkan mode hemat daya Wi-Fi setiap kali aplikasi mendapatkan kunci WIFI_MODE_FULL_HIGH_PERF atau kunci WIFI_MODE_FULL_LOW_LATENCY melalui WifiManager.createWifiLock() dan WifiManager.WifiLock.acquire() API dan kunci aktif.
• [C-3-2] Latensi dua arah rata-rata antara perangkat dan titik akses saat perangkat berada dalam mode Wi-Fi Low Latency Lock (WIFI_MODE_FULL_LOW_LATENCY) HARUS lebih kecil daripada latensi selama mode Wi-Fi High Perf Lock (WIFI_MODE_FULL_HIGH_PERF).
• [C-SR-3] SANGAT DIREKOMENDASIKAN untuk meminimalkan latensi dua arah Wi-Fi setiap kali Kunci Latensi Rendah (WIFI_MODE_FULL_LOW_LATENCY) diperoleh dan berlaku.

Jika implementasi perangkat mendukung Wi-Fi dan menggunakan Wi-Fi untuk pemindaian lokasi, implementasi perangkat akan:

• [C-2-1] HARUS menyediakan affordance pengguna untuk mengaktifkan/menonaktifkan nilai yang dibaca melalui metode API WifiManager.isScanAlwaysAvailable.

7.4.2.1. Wi-Fi Direct

Implementasi perangkat:

• HARUS menyertakan dukungan untuk Wi-Fi Langsung (Wi-Fi peer-to-peer).

Jika implementasi perangkat menyertakan dukungan untuk Wi-Fi Langsung, implementasi 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 Langsung secara serentak.
• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mengacak alamat MAC sumber untuk semua koneksi Wi-Fi Langsung yang baru dibuat.

7.4.2.2. Pengaturan Wi-Fi Tunneled Direct Link

Implementasi perangkat:

• HARUS menyertakan dukungan untuk Wi-Fi Tunneled Direct Link Setup (TDLS) seperti yang dijelaskan dalam Dokumentasi Android SDK.

Jika penerapan perangkat menyertakan dukungan untuk TDLS dan TDLS yang diaktifkan oleh WiFiManager API, penerapan tersebut:

• [C-1-1] HARUS mendeklarasikan dukungan untuk TDLS melalui WifiManager.isTdlsSupported.
• HARUS menggunakan TDLS hanya jika memungkinkan DAN bermanfaat.
• SEHARUSNYA menggunakan TDLS heuristik, dan TIDAK menggunakan TDLS jika performanya mungkin lebih buruk daripada melalui titik akses Wi-Fi.

7.4.2.3. Wi-Fi Aware

Implementasi perangkat:

• HARUS menyertakan dukungan untuk Wi-Fi Aware.

Jika implementasi perangkat menyertakan dukungan untuk Wi-Fi Aware dan menampilkan fungsi ke aplikasi pihak ketiga, implementasi tersebut:

• [C-1-1] HARUS mengimplementasikan WifiAwareManager API seperti yang dijelaskan dalam dokumentasi SDK.
• [C-1-2] HARUS mendeklarasikan tombol fitur android.hardware.wifi.aware.
• [C-1-3] HARUS mendukung operasi Wi-Fi dan Wi-Fi Aware secara serentak.
• [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 operasi rentang 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 Lokasi Wi-Fi seperti yang dijelaskan di Bagian 7.4.2.5 dan mengekspos fungsi ini ke aplikasi pihak ketiga, maka aplikasi tersebut:

• [C-2-1] HARUS mengimplementasikan API penemuan berbasis lokasi: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm , dan onServiceDiscovered DalamRange.

7.4.2.4. Passpoint Wi-Fi

Jika implementasi perangkat menyertakan dukungan untuk 802.11 (Wi-Fi), implementasi tersebut:

• [C-1-1] HARUS menyertakan dukungan untuk Passpoint Wi-Fi.
• [C-1-2] HARUS menerapkan API WifiManager terkait Passpoint seperti yang dijelaskan dalam dokumentasi SDK.
• [C-1-3] HARUS mendukung standar IEEE 802.11u, khususnya yang terkait dengan Penemuan dan Pemilihan Jaringan, seperti Layanan Iklan Generik (GAS) dan Protokol Kueri Jaringan Akses (ANQP).
• [C-1-4] HARUS mendeklarasikan tombol fitur android.hardware.wifi.passpoint.
• [C-1-5] HARUS mengikuti implementasi AOSP untuk menemukan, mencocokkan, dan mengaitkan dengan jaringan Passpoint.
• [C-1-6] HARUS mendukung setidaknya subset protokol penyediaan perangkat berikut seperti yang ditetapkan dalam Wi-Fi Alliance Passpoint R2: 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 untuk penyediaan melalui pemilih Wi-Fi.
• [C-1-9] HARUS menjaga konfigurasi Passpoint tetap persisten setiap kali dimulai ulang.
• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung fitur persetujuan persyaratan dan ketentuan.
• [C-SR-2] SANGAT DIREKOMENDASIKAN untuk mendukung fitur informasi Tempat.

Jika tombol kontrol pengguna penonaktifan Passpoint global disediakan, implementasinya:

• [C-3-1] HARUS mengaktifkan Passpoint secara default.

7.4.2.5. Lokasi Wi-Fi (Waktu Round Trip Wi-Fi - RTT)

Implementasi perangkat:

• HARUS menyertakan dukungan untuk Lokasi Wi-Fi.

Jika implementasi perangkat menyertakan dukungan untuk Lokasi Wi-Fi dan menampilkan fungsi ke aplikasi pihak ketiga, implementasi tersebut:

• [C-1-1] HARUS mengimplementasikan WifiRttManager API seperti yang dijelaskan dalam dokumentasi SDK.
• [C-1-2] HARUS mendeklarasikan tombol fitur android.hardware.wifi.rtt.
• [C-1-3] HARUS mengacak alamat MAC sumber untuk setiap burst RTT yang dijalankan sementara antarmuka Wi-Fi tempat RTT dijalankan tidak terkait dengan Titik Akses.
• [C-1-4] HARUS akurat dalam jarak 2 meter pada bandwidth 80 MHz pada persentil ke-68 (sebagaimana dihitung dengan Fungsi Distribusi Kumulatif).
• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk melaporkannya secara akurat dalam jarak 1,5 meter pada bandwidth 80 MHz pada persentil ke-68 (sebagaimana dihitung dengan Fungsi Distribusi Kumulatif).

7.4.2.6. Offload Keepalive Wi-Fi

Implementasi perangkat:

• HARUS menyertakan dukungan untuk Wi-Fi keepalive offload.

Jika implementasi perangkat menyertakan dukungan untuk Wi-Fi keepalive offload dan menampilkan fungsi tersebut ke aplikasi pihak ketiga, implementasi tersebut:

• [C-1-1] HARUS mendukung SocketKeepAlive API.
• [C-1-2] HARUS mendukung setidaknya tiga slot keepalive serentak melalui Wi-Fi

Jika implementasi perangkat tidak menyertakan dukungan untuk Wi-Fi keepalive offload, implementasi tersebut:

• [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 implementasi perangkat menyertakan dukungan untuk Wi-Fi Easy Connect dan menampilkan fungsi ke aplikasi pihak ketiga, implementasi tersebut:

• [C-1-1] HARUS meminta 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 akan:

• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk tidak memberikan opsi kepada pengguna untuk menambahkan jaringan Wi-Fi Perusahaan secara manual di aplikasi Setelan.

7.4.2.9. Kepercayaan Saat Penggunaan Pertama (TOFU)

Jika implementasi perangkat mendukung Kepercayaan pada penggunaan pertama (TOFU) dan memungkinkan pengguna menentukan konfigurasi WPA/WPA2/WPA3-Enterprise, maka aplikasi ini:

• [C-4-1] HARUS memberikan pilihan kepada pengguna untuk menggunakan TOFU.

7.4.3. Bluetooth

Jika implementasi perangkat mendukung profil Audio Bluetooth, implementasi tersebut:

• HARUS mendukung Codec Audio Lanjutan dan Codec Audio Bluetooth (misalnya LDAC)

Jika implementasi perangkat mendukung HFP, A2DP, dan AVRCP, implementasi tersebut:

• HARUS mendukung setidaknya 5 total perangkat terhubung.

Jika implementasi perangkat mendeklarasikan fitur android.hardware.vr.high_performance, implementasi tersebut:

• [C-1-1] HARUS mendukung Ekstensi Panjang Data Bluetooth 4.2 dan Bluetooth LE.

Android menyertakan dukungan untuk Bluetooth dan Bluetooth Energi Rendah.

Jika implementasi perangkat menyertakan dukungan untuk Bluetooth dan Bluetooth Rendah Energi, implementasi tersebut:

• [C-2-1] HARUS mendeklarasikan fitur platform yang relevan (masing-masing android.hardware.bluetooth dan android.hardware.bluetooth_le) dan menerapkan API platform.
• HARUS menerapkan profil Bluetooth yang relevan seperti A2DP, AVRCP, OBEX, HFP, dll. yang sesuai untuk perangkat.

Jika implementasi perangkat menyertakan dukungan untuk Bluetooth Hemat Energi (BLE), implementasi tersebut:

• [C-3-1] HARUS mendeklarasikan fitur hardware android.hardware.bluetooth_le.
• [C-3-2] HARUS mengaktifkan Bluetooth API berbasis GATT (profil atribut umum) seperti yang dijelaskan dalam dokumentasi SDK dan android.bluetooth.
• [C-3-3] HARUS melaporkan nilai yang benar untuk BluetoothAdapter.isOffloadedFilteringSupported() guna menunjukkan apakah logika pemfilteran untuk class ScanFilter API telah diimplementasikan.
• [C-3-4] HARUS melaporkan nilai yang benar untuk BluetoothAdapter.isMultipleAdvertisementSupported() guna menunjukkan apakah Iklan Hemat Energi didukung atau tidak.

• [C-3-5] HARUS mengimplementasikan waktu tunggu Resolvable Private Address (RPA) tidak lebih dari 15 menit dan merotasi alamat pada waktu tunggu untuk melindungi privasi pengguna saat perangkat aktif menggunakan BLE untuk pemindaian atau iklan. Untuk mencegah serangan pengaturan waktu, interval waktu tunggu juga HARUS diacak antara 5 dan 15 menit.

• HARUS mendukung pemindahan logika pemfilteran ke chipset Bluetooth saat menerapkan ScanFilter API.

• HARUS mendukung pemindahan beban pemindaian batch ke chipset Bluetooth.

• HARUS mendukung multi-iklan dengan minimal 4 slot.

Jika implementasi perangkat mendukung Bluetooth LE dan menggunakan Bluetooth LE untuk pemindaian lokasi, implementasi tersebut:

• [C-4-1] HARUS menyediakan affordance pengguna untuk mengaktifkan/menonaktifkan nilai yang dibaca melalui System API BluetoothAdapter.isBleScanAlwaysAvailable().

Jika implementasi perangkat menyertakan dukungan untuk Profil Bluetooth LE dan Alat Bantu Dengar, seperti yang dijelaskan dalam Dukungan Audio Alat Bantu Dengar Menggunakan Bluetooth LE, implementasi tersebut:

• [C-5-1] HARUS menampilkan true untuk BluetoothAdapter.getProfileProxy(context, pemroses, BluetoothProfile.HEARING_AID).

Jika implementasi perangkat menyertakan dukungan untuk Bluetooth atau Bluetooth Hemat Energi, implementasi tersebut:

• [C-6-1] HARUS membatasi akses ke metadata Bluetooth apa pun (seperti hasil pemindaian) yang dapat digunakan untuk memperoleh lokasi perangkat, kecuali jika aplikasi yang meminta berhasil melewati pemeriksaan izin android.permission.ACCESS_FINE_LOCATION berdasarkan status latar depan/latar belakangnya saat ini.

Jika implementasi perangkat menyertakan dukungan untuk Bluetooth atau Bluetooth Hemat Energi dan manifes aplikasi tidak menyertakan deklarasi dari developer yang menyatakan bahwa mereka tidak mengambil lokasi dari Bluetooth, maka manifes aplikasi:

• [C-6-2] HARUS membatasi akses Bluetooth di belakang android.permission.ACCESS_FINE_LOCATION.

Jika implementasi perangkat menampilkan true untuk BluetoothAdapter.isLeAudioSupported() API, implementasi tersebut:

• [C-7-1] HARUS mendukung klien unicast.
• [C-7-2] HARUS mendukung 2M PHY.
• [C-7-3] HARUS mendukung Iklan LE Extended.
• [C-7-4] HARUS mendukung setidaknya 2 koneksi CIS dalam CIG.
• [C-7-5] HARUS mengaktifkan klien unicast BAP, koordinator kumpulan CSIP, server MCP, pengontrol VCP, server CCP secara bersamaan.
• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mengaktifkan klien unicast HAP.

Jika implementasi perangkat menampilkan true untuk BluetoothAdapter.isLeAudioBroadcastSourceSupported() API, implementasi tersebut:

• [C-8-1] HARUS mendukung setidaknya 2 link BIS di 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, implementasi tersebut:

• [C-9-1] HARUS mendukung MASA DEPAN (Transfer Sinkronisasi Iklan Berkala).
• [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 dalam jarak pandang.

• [C-10-2] HARUS menyertakan koreksi Rx/Tx untuk mengurangi penyimpangan per saluran sehingga pengukuran pada masing-masing 3 saluran, pada setiap antena (jika beberapa digunakan), berada dalam +/-3 dB satu sama lain untuk 95% pengukuran.

• [C-SR-2] SANGAT DIREKOMENDASIKAN untuk mengukur dan mengompensasi offset Rx guna memastikan RSSI BLE median 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 pada 'bidang paralel' dengan layar menghadap ke arah yang sama.

• [C-SR-3] SANGAT DIREKOMENDASIKAN untuk mengukur dan mengompensasi offset Tx guna 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 orientasi perangkat sehingga berada pada 'bidang paralel' dengan layar menghadap ke arah yang sama.

  Memindahkan persyaratan [C-10-3] dan [C-10-4] ke 2.2.1. Hardware.

SANGAT DIREKOMENDASIKAN untuk mengikuti langkah-langkah penyiapan pengukuran yang ditentukan dalam Persyaratan Kalibrasi Kehadiran.

7.4.4. Komunikasi Nirkabel Jarak Dekat

Implementasi perangkat:

• HARUS menyertakan pengirim dan hardware terkait untuk Komunikasi Nirkabel Jarak Dekat (NFC).
• [C-0-1] HARUS mengimplementasikan API android.nfc.NdefMessage dan android.nfc.NdefRecord meskipun keduanya tidak menyertakan dukungan untuk NFC atau mendeklarasikan fitur android.hardware.nfc sebagai class yang mewakili format representasi data tanpa protokol protokol.

Jika implementasi perangkat menyertakan hardware NFC dan berencana untuk menyediakannya untuk aplikasi pihak ketiga, implementasi tersebut akan:

• [C-1-1] HARUS melaporkan fitur android.hardware.nfc dari metode android.content.pm.PackageManager.hasSystemFeature().
• HARUS mampu membaca dan menulis pesan NDEF melalui standar NFC berikut seperti di bawah:
• [C-1-2] HARUS mampu bertindak sebagai pembaca/penulis Forum NFC (sebagaimana ditentukan oleh spesifikasi teknis Forum NFC NFCForum-TS-DigitalProtocol-1.0) melalui standar NFC berikut:
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • Tag Forum NFC Jenis 1, 2, 3, 4, 5 (ditentukan oleh Forum NFC)

• [C-SR-1] SANGAT DIREKOMENDASIKAN agar mampu membaca dan menulis pesan NDEF serta data mentah melalui standar NFC berikut. Perlu diketahui bahwa meskipun standar NFC dinyatakan SANGAT DIREKOMENDASIKAN, Definisi Kompatibilitas untuk versi mendatang direncanakan untuk mengubahnya menjadi HARUS. Standar ini bersifat opsional dalam versi ini, tetapi akan diwajibkan dalam versi mendatang. Perangkat yang sudah ada dan yang baru yang menjalankan versi Android ini sangat dianjurkan untuk memenuhi persyaratan tersebut sekarang agar perangkat tersebut dapat melakukan upgrade ke rilis platform mendatang.

• [C-1-13] HARUS melakukan polling untuk semua teknologi yang didukung saat dalam mode penemuan NFC.

• HARUS berada dalam mode penemuan NFC saat perangkat aktif dengan layar aktif dan layar kunci tidak terkunci.

• HARUS mampu membaca kode batang dan URL (jika dienkode) produk Thinfilm NFC Barcode.

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

Android menyertakan dukungan untuk mode NFC Host Card Emulation (HCE).

Jika penerapan perangkat menyertakan chipset pengontrol NFC yang mendukung HCE (untuk NfcA dan/atau NfcB) dan mendukung perutean ID Aplikasi (AID), penerapan tersebut akan:

• [C-2-1] HARUS melaporkan konstanta fitur android.hardware.nfc.hce.
• [C-2-2] HARUS mendukung NFC HCE API seperti yang ditentukan di Android SDK.

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

• [C-3-1] HARUS melaporkan konstanta fitur android.hardware.nfc.hcef.
• [C-3-2] HARUS menerapkan NfcF Card Emulation API seperti yang ditetapkan di 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, implementasi tersebut:

• [C-4-1] HARUS mengimplementasikan Android API yang sesuai seperti yang didokumentasikan oleh Android SDK.
• [C-4-2] HARUS melaporkan com.nxp.mifare fitur dari metode android.content.pm.PackageManager.hasSystemFeature(). Perhatikan bahwa ini bukan fitur Android standar, sehingga tidak muncul sebagai konstanta dalam class android.content.pm.PackageManager.

7.4.5. Protokol dan API jaringan

7.4.5.1. Kemampuan Jaringan Minimum

Implementasi perangkat:

• [C-0-1] HARUS menyertakan dukungan untuk satu atau beberapa bentuk jaringan data. Secara khusus, implementasi perangkat HARUS menyertakan dukungan untuk setidaknya satu standar data yang mampu mencapai 200 Kbit/dtk atau lebih besar. Contoh teknologi yang memenuhi persyaratan ini mencakup EDGE, HSPA, EV-DO, 802.11g, Ethernet, dan Bluetooth PAN.
• HARUS menyertakan dukungan untuk setidaknya satu standar data nirkabel yang umum, seperti 802.11 (Wi-Fi), jika standar jaringan fisik (seperti Ethernet) adalah koneksi data utama.
• MUNGKIN mengimplementasikan 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 yang dikelola, 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 dapat diandalkan seperti IPv4, misalnya:
    • [C-0-4] HARUS mempertahankan konektivitas IPv6 dalam mode istirahat.
    • [C-0-5] Pembatasan kapasitas TIDAK BOLEH menyebabkan perangkat kehilangan konektivitas IPv6 di jaringan yang mematuhi IPv6 yang menggunakan masa aktif RA setidaknya 180 detik.
• [C-0-6] HARUS menyediakan aplikasi pihak ketiga dengan konektivitas IPv6 langsung ke jaringan saat terhubung ke jaringan IPv6, tanpa segala bentuk alamat atau penerjemahan 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 benar-benar digunakan untuk mengirim dan menerima paket di jaringan serta terlihat sebagai port dan IP 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, implementasi tersebut:

• [C-1-1] HARUS mendukung operasi dual-stack dan IPv6 saja pada Wi-Fi.

Jika implementasi perangkat mendukung Ethernet, implementasi tersebut:

• [C-2-1] HARUS mendukung operasi dual-stack dan IPv6 saja di Ethernet.

Jika implementasi perangkat mendukung data Seluler, implementasi tersebut:

• [C-3-1] HARUS mendukung operasi IPv6 (khusus IPv6 dan mungkin dual-stack) pada seluler.

Jika implementasi perangkat mendukung lebih dari satu jenis jaringan (misalnya, Wi-Fi dan data seluler), mereka:

• [C-4-1] HARUS memenuhi persyaratan di atas secara bersamaan pada setiap jaringan jika perangkat terhubung ke lebih dari satu jenis jaringan secara bersamaan.

7.4.5.3. Tawanan Portal

Portal tawanan mengacu pada jaringan yang memerlukan login untuk mendapatkan akses internet.

Jika implementasi perangkat menyediakan implementasi android.webkit.Webview API lengkap, 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 memanggil 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/seluler, Wi-Fi, Ethernet atau Bluetooth.
• [C-1-3] HARUS mendukung login ke captive portal menggunakan DNS cleartext jika perangkat dikonfigurasi untuk menggunakan mode ketat DNS pribadi.
• [C-1-4] HARUS menggunakan DNS terenkripsi sesuai dengan dokumentasi SDK untuk android.net.LinkProperties.getPrivateDnsServerName dan android.net.LinkProperties.isPrivateDnsActive untuk semua traffic jaringan yang tidak berkomunikasi secara eksplisit dengan captive portal.
• [C-1-5] HARUS memastikan bahwa saat pengguna login ke captive portal, 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 dan menyediakan akses internet, jika tersedia.

7.4.6. Setelan Sinkronisasi

Implementasi perangkat:

• [C-0-1] HARUS mengaktifkan setelan sinkronisasi otomatis master secara default agar metode getMasterSyncAutomatically() menampilkan “true”.

7.4.7. Penghemat Data

Jika implementasi perangkat menyertakan koneksi berkuota, implementasi tersebut adalah:

• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menyediakan mode penghemat data.

Jika implementasi perangkat menyediakan mode penghemat data, implementasi tersebut:

• [C-1-1] HARUS mendukung semua API di class ConnectivityManager seperti yang dijelaskan dalam dokumentasi SDK

Jika implementasi perangkat tidak menyediakan mode penghemat data, implementasi tersebut:

• [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 Pengaman

Jika implementasi perangkat mendukung elemen aman yang mendukung Open Mobile API dan menyediakannya untuk aplikasi pihak ketiga, implementasi tersebut:

• [C-1-1] HARUS menghitung pembaca elemen aman yang tersedia melalui android.se.omapi.SEService.getReaders() API.

• [C-1-2] HARUS mendeklarasikan tombol fitur yang benar melalui android.hardware.se.omapi.uicc untuk perangkat dengan elemen aman berbasis UICC, android.hardware.se.omapi.ese untuk perangkat dengan elemen aman berbasis eSE, dan android.hardware.se.omapi.sd untuk perangkat dengan elemen aman berbasis SD.

7.4.9. UWB

Jika implementasi perangkat menyertakan dukungan untuk 802.1.15.4 dan mengekspos fungsi tersebut ke aplikasi pihak ketiga, maka implementasi tersebut:

• [C-1-1] HARUS mengimplementasikan Android API yang sesuai di android.uwb.
• [C-1-2] HARUS melaporkan tanda fitur hardware android.hardware.uwb.
• [C-1-3] HARUS mendukung semua profil UWB relevan yang ditentukan dalam implementasi Android.
• [C-1-4] HARUS menyediakan affordance pengguna agar pengguna dapat mengaktifkan/menonaktifkan status aktif/nonaktif radio UWB.
• [C-1-5] HARUS memberlakukan bahwa aplikasi yang menggunakan radio UWB memiliki izin UWB_RANGING (pada grup izin NEARBY_devices).
• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk lulus pengujian 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 di lingkungan garis pandang pada jarak 1 m dalam ruang non-reflektif.
• [C-1-7] HARUS memastikan bahwa median pengukuran jarak pada jarak 1 m dari perangkat referensi adalah dalam jarak [0,75 m, 1,25 m], dengan jarak kebenaran dasar diukur dari tepi atas DUT. diangkat menghadap ke atas dan dimiringkan 45 derajat.
• [C-SR-2] SANGAT DIREKOMENDASIKAN untuk mengikuti langkah-langkah penyiapan pengukuran yang ditentukan dalam Persyaratan Kalibrasi Kehadiran.

7.5. Kamera

Jika implementasi perangkat menyertakan setidaknya satu kamera, implementasi tersebut:

• [C-1-1] HARUS mendeklarasikan tombol fitur android.hardware.camera.any.
• [C-1-2] HARUS memungkinkan aplikasi untuk secara bersamaan mengalokasikan 3 bitmap RGBA_8888 yang sama dengan ukuran gambar yang dihasilkan oleh sensor kamera beresolusi terbesar di perangkat, saat kamera terbuka untuk tujuan pratinjau dasar dan diam.
• [C-1-3] HARUS memastikan bahwa intent penanganan aplikasi kamera default bawaan MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE, atau MediaStore.ACTION_VIDEO_CAPTURE, bertanggung jawab untuk menghapus lokasi pengguna dalam metadata gambar sebelum mengirimnya ke aplikasi penerima saat aplikasi penerima tidak memiliki ACCESS_FINE_LOCATION.

Jika implementasi perangkat mendukung kemampuan output HDR 10-bit, implementasi tersebut:

• [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 DIREKOMENDASIKAN untuk mendukung output 10-bit untuk kedua kamera utama.
• [C-2-3] HARUS mendukung profil HDR yang sama untuk semua sub-kamera fisik berkemampuan BACKWARD_COMPATIBLE dari kamera logis, dan kamera logis itu sendiri.

Untuk perangkat kamera Logis yang mendukung HDR 10-bit yang mengimplementasikan android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO API, perangkat tersebut:

• [C-3-1] HARUS mendukung peralihan antara semua kamera fisik yang kompatibel dengan versi lama melalui kontrol CONTROL_ZOOM_RATIO pada kamera logis.

7.5.1. Kamera Belakang

Implementasi perangkat:

• HARUS dilengkapi dengan kamera belakang.

Jika implementasi perangkat menyertakan setidaknya satu kamera belakang, implementasi tersebut:

• [C-1-1] HARUS melaporkan tombol fitur android.hardware.camera dan android.hardware.camera.any.
• [C-1-2] HARUS memiliki resolusi minimal 2 megapiksel.
• HARUS menerapkan fokus otomatis hardware atau fokus otomatis software di driver kamera (transparan untuk software aplikasi).
• MUNGKIN memiliki hardware fokus tetap atau EDOF (extended depth of field).
• MUNGKIN menyertakan flash.

Jika kamera menyertakan flash:

• [C-2-1] lampu flash TIDAK BOLEH menyala saat instance android.hardware.Camera.PreviewCallback telah didaftarkan di platform pratinjau Kamera, kecuali aplikasi telah secara eksplisit mengaktifkan flash dengan mengaktifkan atribut FLASH_MODE_AUTO atau FLASH_MODE_ON objek Camera.Parameters. Perhatikan bahwa batasan ini tidak berlaku untuk aplikasi kamera sistem bawaan perangkat, tetapi hanya untuk aplikasi pihak ketiga yang menggunakan Camera.PreviewCallback.

7.5.2. Kamera Depan

Implementasi perangkat:

• Mungkin menyertakan kamera depan.

Jika implementasi perangkat menyertakan setidaknya satu kamera depan, implementasi tersebut:

• [C-1-1] HARUS melaporkan tombol 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 sesuai dengan orientasi yang ditentukan oleh aplikasi saat aplikasi saat ini secara eksplisit telah meminta agar tampilan Kamera diputar melalui panggilan ke metode android.hardware.Camera.setDisplayOrientation(). Sebaliknya, pratinjau HARUS dicerminkan di sepanjang sumbu horizontal default perangkat jika aplikasi saat ini tidak secara eksplisit meminta agar layar Kamera diputar melalui panggilan ke metode android.hardware.Camera.setDisplayOrientation().
• [C-1-5] TIDAK BOLEH mencerminkan streaming video atau gambar diam akhir yang diambil, yang dikembalikan ke callback aplikasi atau di-commit ke penyimpanan media.
• [C-1-6] HARUS mencerminkan gambar yang ditampilkan oleh tampilan postingan dengan cara yang sama seperti streaming gambar pratinjau kamera.
• DAPAT mencakup fitur (seperti fokus otomatis, flash, dll.) yang tersedia untuk kamera belakang seperti yang dijelaskan dalam bagian 7.5.1.

Jika implementasi perangkat dapat dirotasi oleh pengguna (seperti secara otomatis melalui akselerometer atau secara manual melalui input pengguna):

• [C-2-1] Pratinjau kamera HARUS dicerminkan secara horizontal sesuai dengan orientasi perangkat saat ini.

7.5.3. Kamera Eksternal

Implementasi perangkat:

• Mungkin mencakup dukungan untuk kamera eksternal yang tidak selalu selalu terhubung.

Jika implementasi perangkat menyertakan dukungan untuk kamera eksternal, implementasi tersebut:

• [C-1-1] HARUS mendeklarasikan tombol 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 baru) jika kamera eksternal terhubung melalui port host USB.
• [C-1-3] HARUS lulus uji 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 mengaktifkan transfer streaming tidak berenkode berkualitas tinggi (yaitu streaming gambar mentah atau yang dikompresi secara independen).
• MUNGKIN mendukung beberapa kamera.
• Mungkin mendukung encoding video berbasis kamera.

Jika encoding video berbasis kamera didukung:

• [C-2-1] Streaming yang tidak dienkode / MJPEG secara bersamaan (QVGA atau resolusi lebih besar) HARUS dapat diakses oleh implementasi perangkat.

7.5.4. Perilaku Camera API

Android menyertakan dua paket API untuk mengakses kamera. API android.hardware.camera2 yang lebih baru menampilkan kontrol kamera tingkat rendah ke aplikasi, termasuk alur burst/streaming tanpa salinan yang efisien dan kontrol eksposur, penguatan, perolehan white balance, konversi warna, penghilang noise, penajaman, dan banyak lagi.

Paket API lama, android.hardware.Camera, ditandai sebagai tidak digunakan lagi di Android 5.0, tetapi masih harus 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 umum di 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 yang berbeda dari kedua API tidak diharuskan memiliki kecepatan atau kualitas yang cocok, tetapi HARUS memiliki kecocokan 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] Selanjutnya HARUS dalam format encoding NV21 saat aplikasi mendaftarkan instance android.hardware.Camera.PreviewCallback dan sistem memanggil metode onPreviewFrame() dan format pratinjaunya 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 bagi kamera depan dan belakang untuk android.hardware.Camera. (Encoder dan kamera video 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 android.media.ImageReader API untuk perangkat android.hardware.camera2 yang mengiklankan kemampuan REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE di android.request.availableCapabilities.
• [C-0-5] Tetap harus menerapkan Camera API lengkap yang disertakan dalam dokumentasi Android SDK, terlepas dari apakah perangkat menyertakan fokus otomatis hardware atau kemampuan lainnya. Misalnya, kamera yang tidak memiliki fokus otomatis HARUS memanggil instance android.hardware.Camera.AutoFocusCallback yang terdaftar (meskipun tidak memiliki 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 "palsu" seperti yang dijelaskan.
• [C-0-6] HARUS mengenali dan mematuhi setiap nama parameter yang ditetapkan sebagai konstanta di class android.hardware.Camera.Parameters dan class android.hardware.camera2.CaptureRequest. Sebaliknya, implementasi perangkat TIDAK BOLEH mengikuti atau mengenali konstanta string yang diteruskan ke metode android.hardware.Camera.setParameters() selain yang didokumentasikan sebagai konstanta di android.hardware.Camera.Parameters. Artinya, implementasi perangkat HARUS mendukung semua parameter Kamera standar jika hardware memungkinkan, dan TIDAK BOLEH mendukung jenis parameter Kamera kustom. Misalnya, implementasi perangkat yang mendukung pengambilan gambar menggunakan teknik pencitraan rentang dinamis tinggi (HDR) HARUS mendukung parameter kamera Camera.SCENE_MODE_HDR.
• [C-0-7] HARUS melaporkan tingkat dukungan yang tepat dengan properti android.info.supportedHardwareLevel seperti yang dijelaskan dalam Android SDK dan melaporkan tanda fitur framework yang sesuai.
• [C-0-8] Juga HARUS mendeklarasikan kemampuan kamera masing-masing android.hardware.camera2 melalui properti android.request.availableCapabilities dan mendeklarasikan tombol fitur yang sesuai; HARUS menentukan tombol fitur jika salah satu perangkat kamera yang terpasang mendukung fitur tersebut.
• [C-0-9] HARUS menyiarkan intent Camera.ACTION_NEW_PICTURE setiap kali gambar baru diambil oleh kamera dan entri gambar telah ditambahkan ke penyimpanan media.
• [C-0-10] HARUS menyiarkan intent 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 android.hardware.Camera API yang tidak digunakan lagi, juga dapat diakses melalui android.hardware.camera2 API.
• [C-0-12] HARUS memastikan bahwa tampilan wajah TIDAK diubah, termasuk, tetapi tidak terbatas pada, mengubah 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 dekat dan menghadap ke arah yang sama, SANGAT DIREKOMENDASIKAN 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 mengimplementasikan API kamera tersebut menggunakan android.hardware.camera2 API.
• MUNGKIN menyediakan 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 selaras dengan dimensi panjang layar. Artinya, saat perangkat dipegang dalam orientasi lanskap, kamera HARUS mengambil gambar dalam orientasi lanskap. Ini berlaku apa pun orientasi alami perangkat; yaitu, berlaku untuk perangkat utama lanskap serta perangkat utama potret.

Perangkat yang memenuhi semua kriteria berikut akan dikecualikan dari persyaratan di atas:

• Perangkat menerapkan layar geometri variabel, seperti layar perangkat foldable atau berengsel.
• Saat status lipat atau engsel perangkat berubah, perangkat akan beralih dari orientasi potret-utama ke orientasi utama lanskap (atau sebaliknya).

7.6. Memori dan Penyimpanan

7.6.1 Memori dan Penyimpanan Minimum

Implementasi perangkat:

• [C-0-1] HARUS menyertakan Pengelola Download yang MUNGKIN digunakan aplikasi untuk mendownload file data, dan aplikasi HARUS mampu mendownload setiap file berukuran minimal 100 MB ke lokasi "cache" default.

7.6.2. Penyimpanan Bersama Aplikasi

Implementasi perangkat:

• [C-0-1] HARUS menawarkan penyimpanan untuk digunakan bersama oleh aplikasi, yang juga sering disebut sebagai "penyimpanan eksternal bersama", "penyimpanan bersama aplikasi", atau dengan jalur Linux "/sdcard" tempat penyimpanannya.
• [C-0-2] HARUS dikonfigurasi dengan penyimpanan bersama yang dipasang secara default, dengan kata lain "siap pakai", terlepas dari apakah penyimpanan tersebut diterapkan pada komponen penyimpanan internal atau media penyimpanan yang dapat dilepas (mis. Slot kartu Digital Aman).
• [C-0-3] HARUS memasang penyimpanan bersama aplikasi secara langsung di jalur Linux sdcard atau menyertakan link simbolis Linux dari sdcard ke titik pemasangan yang sebenarnya.
• [C-0-4] HARUS mengaktifkan penyimpanan terbatas secara default untuk semua aplikasi yang menargetkan level API 29 atau yang lebih tinggi, kecuali dalam situasi berikut:
  • Saat aplikasi telah meminta android:requestLegacyExternalStorage="true" dalam manifesnya.
• [C-0-5] HARUS menyamarkan metadata lokasi, seperti tag Exif GPS, yang disimpan di file media jika file tersebut diakses melalui MediaStore, kecuali saat aplikasi panggilan memiliki izin ACCESS_MEDIA_LOCATION.

Implementasi perangkat MUNGKIN memenuhi persyaratan di atas menggunakan salah satu hal berikut:

• Penyimpanan yang dapat dilepas yang dapat diakses pengguna, seperti slot kartu Secure Digital (SD).
• Sebagian penyimpanan internal (tidak dapat dilepas) seperti yang diimplementasikan dalam Project Open Source Android (AOSP).

Jika implementasi perangkat menggunakan penyimpanan yang dapat dilepas untuk memenuhi persyaratan di atas, implementasi tersebut:

• [C-1-1] HARUS menerapkan antarmuka pengguna toast atau pop-up yang memperingatkan pengguna saat tidak ada media penyimpanan yang dimasukkan dalam slot.
• [C-1-2] HARUS menyertakan media penyimpanan berformat FAT (misalnya, kartu SD) atau ditunjukkan di kotak dan bahan lain yang tersedia pada saat pembelian bahwa media penyimpanan harus dibeli secara terpisah.

Jika implementasi perangkat menggunakan sebagian dari penyimpanan tidak dapat dilepas untuk memenuhi persyaratan di atas, implementasi tersebut:

• HARUS menggunakan implementasi AOSP dari penyimpanan bersama aplikasi internal.
• DAPAT berbagi ruang penyimpanan dengan data pribadi aplikasi.

Jika implementasi perangkat memiliki port USB dengan dukungan mode periferal USB, implementasi 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.
• MUNGKIN menggunakan penyimpanan massal USB, tetapi HARUS menggunakan Media Transfer Protocol untuk memenuhi persyaratan ini.

Jika implementasi perangkat memiliki port USB dengan mode periferal USB dan mendukung Media Transfer Protocol, implementasi tersebut:

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

7.6.3. Penyimpanan yang Dapat Diadopsi

Jika perangkat diharapkan bersifat seluler tidak seperti Televisi, implementasi perangkat adalah:

• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan penyimpanan yang dapat diadopsi di lokasi stabil jangka panjang, karena tidak sengaja memutuskan koneksi dapat menyebabkan kehilangan/kerusakan data.

Jika port perangkat penyimpanan yang dapat dilepas berada di lokasi stabil jangka panjang, seperti di dalam kompartemen baterai atau penutup pelindung lainnya, implementasi perangkat adalah:

• [C-SR-2] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan penyimpanan yang dapat diadopsi.

7.7. USB

Jika implementasi perangkat memiliki port USB, implementasi tersebut:

• HARUS mendukung mode periferal USB dan SEHARUSNYA mendukung mode host USB.
• HARUS mendukung penonaktifan sinyal data melalui USB.

7.7.1 Mode periferal USB

Jika implementasi perangkat menyertakan port USB yang mendukung mode periferal:

• [C-1-1] Port HARUS dapat dihubungkan ke host USB yang memiliki port USB tipe A atau tipe-C standar.
• [C-1-2] HARUS melaporkan nilai iSerialNumber yang benar dalam deskripsi perangkat standar USB melalui android.os.Build.SERIAL.
• [C-1-3] HARUS mendeteksi pengisi daya 1,5A dan 3,0 A per standar resistor Type-C dan HARUS mendeteksi perubahan dalam iklan jika mendukung USB Tipe-C.
• [C-SR-1] Port SEHARUSNYA menggunakan faktor bentuk USB mikro-B, mikro-AB, atau Tipe-C. Perangkat Android yang ada dan baru DIREKOMENDASIKAN untuk memenuhi persyaratan ini sehingga dapat diupgrade ke rilis platform mendatang.
• [C-SR-2] Port SEHARUSNYA berada di bagian bawah perangkat (sesuai dengan orientasi alami) atau mengaktifkan rotasi layar software untuk semua aplikasi (termasuk layar utama), sehingga layar menggambar dengan benar saat perangkat diorientasikan dengan port di bagian bawah. Perangkat Android lama dan baru DIREKOMENDASIKAN untuk memenuhi persyaratan ini sehingga dapat diupgrade ke rilis platform mendatang.
• [C-SR-3] HARUS mengimplementasikan dukungan untuk menggambar arus 1,5 A selama chirp dan traffic HS seperti yang ditentukan dalam spesifikasi Pengisian Daya Baterai USB, revisi 1.2. Perangkat Android yang ada dan baru DIREKOMENDASIKAN untuk memenuhi persyaratan ini sehingga dapat diupgrade ke rilis platform mendatang.
• [C-SR-4] SANGAT DIREKOMENDASIKAN untuk tidak mendukung metode pengisian daya eksklusif yang mengubah voltase Vbus di luar level default, atau mengubah peran sink/sumber sehingga dapat mengakibatkan masalah interoperabilitas dengan pengisi daya atau perangkat yang mendukung metode Pengiriman Daya USB standar. Meskipun hal ini disebut "SANGAT DIREKOMENDASIKAN", dalam versi Android mendatang, kami mungkin MEMERLUKAN semua perangkat tipe-C untuk mendukung interoperabilitas penuh dengan pengisi daya tipe-C standar.
• [C-SR-5] SANGAT DIREKOMENDASIKAN untuk mendukung Pengiriman Daya untuk pertukaran peran data dan daya jika mendukung mode host USB dan USB Type-C.
• HARUS mendukung Pengiriman Daya untuk pengisian daya voltase tinggi dan dukungan untuk Mode Alternatif seperti layar keluar.
• HARUS menerapkan Android Open Accessory API (AOA) API dan spesifikasi seperti yang didokumentasikan dalam dokumentasi Android SDK.

Jika implementasi perangkat menyertakan port USB dan menerapkan spesifikasi AOA, implementasi tersebut:

• [C-2-1] HARUS mendeklarasikan dukungan untuk fitur hardware android.hardware.usb.accessory.
• [C-2-2] Kelas penyimpanan massal USB HARUS menyertakan string "android" di akhir string deskripsi antarmuka iInterface dari penyimpanan massal USB
• TIDAK BOLEH mengimplementasikan audio AOAv2 yang didokumentasikan dalam dokumentasi Android Open Accessory Protocol 2.0. Audio AOAv2 tidak digunakan lagi mulai Android versi 8.0 (level API 26).

7.7.2. Mode host USB

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

• [C-1-1] HARUS mengimplementasikan API host USB Android seperti yang didokumentasikan dalam Android SDK dan HARUS mendeklarasikan dukungan untuk fitur hardware android.hardware.usb.host.
• [C-1-2] HARUS mengimplementasikan dukungan untuk menghubungkan periferal USB standar, dengan kata lain, periferal HARUS:
  • Memiliki port tipe C di perangkat atau dikirimkan dengan kabel yang menyesuaikan port eksklusif di perangkat ke port USB type-C standar (perangkat USB Type-C).
  • Memiliki tipe A di perangkat atau yang dikirimkan dengan kabel yang menyesuaikan port eksklusif di perangkat ke port USB type-A standar.
  • Memiliki port micro-AB di perangkat, yang HARUS dikirimkan dengan kabel yang beradaptasi dengan port type-A standar.
• [C-1-3] TIDAK BOLEH mengirim dengan adaptor yang mengonversi dari port USB tipe A atau micro-AB ke port tipe-C (receptacle).
• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan class audio USB seperti yang didokumentasikan dalam dokumentasi Android SDK.
• SEHARUSNYA mendukung pengisian daya perangkat periferal USB yang terhubung saat dalam mode host; mengiklankan arus sumber minimal 1, 5A sebagaimana ditentukan di bagian Parameter Penghentian dari Revisi Spesifikasi Kabel USB Type-C dan Spesifikasi Konektor 1.2 untuk konektor USB Type-C atau menggunakan rentang arus output Pengisian Daya Port Downstream(CDP) sebagaimana ditentukan dalam spesifikasi konektor Pengisian Daya Baterai Micro-2.
• HARUS menerapkan dan mendukung standar USB Type-C.

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

• [C-2-1] HARUS mendukung class USB HID.
• [C-2-2] HARUS mendukung deteksi dan pemetaan kolom data HID berikut yang ditentukan dalam Tabel Penggunaan HID USB dan Permintaan Penggunaan Perintah Voice ke konstanta KeyEvent seperti di bawah:
  • ID Penggunaan Halaman Penggunaan (0xC): KEYCODE_MEDIA_PLAY_PAUSE
  • ID Penggunaan Halaman Penggunaan (0xC) (0x0E9): KEYCODE_VOLUME_UP
  • ID Penggunaan Halaman Penggunaan (0xC): KEYCODE_VOLUME_DOWN
  • ID Penggunaan Halaman Penggunaan (0xC): KEYCODE_VOICE_ASSIST

Jika implementasi perangkat menyertakan port USB yang mendukung mode host dan Storage Access Framework (SAF), implementasi tersebut:

• [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 menyertakan port USB yang mendukung mode host dan USB Type-C, implementasi tersebut:

• [C-4-1] HARUS menerapkan fungsi Port Peran Ganda sebagaimana ditetapkan oleh spesifikasi USB Type-C (bagian 4.5.1.3.3). Untuk Port Peran Ganda, Pada perangkat yang menyertakan colokan audio 3,5 mm, deteksi sink USB (mode host) MUNGKIN dinonaktifkan secara default, tetapi HARUS memungkinkan pengguna mengaktifkannya.
• [C-SR-2] SANGAT DIREKOMENDASIKAN untuk mendukung DisplayPort, HARUS mendukung Kecepatan Data SuperSpeed USB, dan SANGAT DIREKOMENDASIKAN untuk mendukung Pengiriman Daya untuk pertukaran peran data dan daya.
• [C-SR-3] SANGAT DIREKOMENDASIKAN untuk TIDAK mendukung Mode Aksesori Adaptor Audio seperti yang dijelaskan di Lampiran A Revisi Spesifikasi Konektor dan Kabel USB Type-C 1.2.
• HARUS menerapkan model Coba.* yang paling sesuai untuk faktor bentuk perangkat. Misalnya, perangkat genggam HARUS menerapkan modelTry.SNK.

7.8. Audio

7.8.1. Mikrofon

Jika implementasi perangkat menyertakan mikrofon, implementasi tersebut:

• [C-1-1] HARUS melaporkan konstanta fitur android.hardware.microphone.
• [C-1-2] HARUS memenuhi persyaratan perekaman audio di pasal 5.4.
• [C-1-3] HARUS memenuhi persyaratan latensi audio di pasal 5.6.
• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung perekaman mendekati ultrasonik seperti yang dijelaskan dalam bagian 7.8.3.

Jika implementasi perangkat menghilangkan mikrofon, implementasi tersebut:

• [C-2-1] TIDAK BOLEH melaporkan konstanta fitur android.hardware.microphone.
• [C-2-2] HARUS mengimplementasikan API perekaman audio setidaknya sebagai tanpa pengoperasian, sesuai dengan bagian 7.

7.8.2. Output Audio

Jika implementasi perangkat menyertakan speaker atau port output audio/multimedia untuk periferal output audio seperti colokan audio 3,5 mm konduktor atau port mode host USB yang menggunakan class audio USB, implementasi tersebut:

• [C-1-1] HARUS melaporkan konstanta fitur android.hardware.audio.output.
• [C-1-2] HARUS memenuhi persyaratan pemutaran audio di pasal 5.5.
• [C-1-3] HARUS memenuhi persyaratan latensi audio di pasal 5.6.
• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung pemutaran mendekati ultrasonik seperti dijelaskan dalam bagian 7.8.3.

Jika implementasi perangkat tidak menyertakan port output speaker atau audio, implementasi tersebut:

• [C-2-1] TIDAK BOLEH melaporkan fitur android.hardware.audio.output.
• [C-2-2] HARUS mengimplementasikan API terkait Output Audio setidaknya sebagai tanpa operasi.

Untuk keperluan 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 steker audio 3,5 mm di seluruh ekosistem Android, jika implementasi perangkat menyertakan satu atau beberapa port audio analog, implementasi tersebut:

• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menyertakan setidaknya salah satu port audio yang menjadi colokan audio 3,5 mm konduktor 4 konduktor.

Jika implementasi perangkat memiliki colokan audio 3,5 mm konduktor 4, implementasi tersebut:

• [C-1-1] HARUS mendukung pemutaran audio untuk headphone stereo dan headset stereo dengan mikrofon.
• [C-1-2] HARUS mendukung steker audio TRRS dengan urutan pin-out CTIA.
• [C-1-3] HARUS mendukung deteksi dan pemetaan ke kode tombol untuk 3 rentang impedansi ekuivalen berikut antara mikrofon dan konduktor bumi 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 pada steker steker, tetapi hanya setelah semua kontak pada steker menyentuh segmen terkaitnya pada steker.
• [C-1-5] HARUS mampu mengemudi setidaknya 150 mV ± 10% dari tegangan output pada impedansi speaker 32 ohm.
• [C-1-6] HARUS memiliki tegangan bias mikrofon antara 1.8V ~ 2.9V.
• [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 DIREKOMENDASIKAN untuk mendukung steker audio dengan urutan pin-out OMTP.
• [C-SR-3] SANGAT DIREKOMENDASIKAN untuk mendukung perekaman audio dari headphone stereo dengan mikrofon.

Jika implementasi perangkat memiliki colokan audio 3,5 mm konduktor 4 dan mendukung mikrofon, serta menyiarkan android.intent.action.HEADSET_PLUG dengan mikrofon bernilai tambahan yang disetel sebagai 1, penerapan tersebut:

• [C-2-1] HARUS mendukung deteksi mikrofon pada aksesori audio yang dicolokkan.

7.8.2.2. Port Audio Digital

Lihat Pasal 2.2.1 untuk mengetahui persyaratan khusus perangkat.

7.8.3. Dekat Ultrasonik

Audio Near-Ultrasonik adalah pita 18,5 kHz hingga 20 kHz.

Implementasi perangkat:

• HARUS melaporkan dukungan kemampuan audio mendekati ultrasonik dengan benar melalui AudioManager.getProperty API sebagai berikut:

Jika PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND adalah "benar", persyaratan berikut HARUS dipenuhi oleh sumber audio VOICE_RECOGNITION dan UNPROCESSED:

• [C-1-1] Respons daya rata-rata mikrofon dalam band 18,5 kHz hingga 20 kHz HARUS tidak lebih dari 15 dB di bawah respons pada 2 kHz.
• [C-1-2] Rasio sinyal tanpa bobot terhadap derau 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 "benar":

• [C-2-1] Respon 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 streaming input dan output pada perangkat genggam, seperti yang didefinisikan oleh nol gangguan yang diukur selama pengujian satu menit per jalur. Uji menggunakan OboeTester "Pengujian Glitch Otomatis".

Pengujian ini memerlukan dongle loopback audio, yang digunakan langsung dalam colokan 3,5 mm, dan/atau dikombinasikan dengan adaptor USB-C ke 3,5 mm. Semua port output audio HARUS diuji.

OboeTester saat ini mendukung jalur AAudio, sehingga kombinasi berikut HARUS diuji untuk glitch menggunakan AAudio:

Mode Performa	Berbagi	Frekuensi Sampel Keluar	Dalam Chans	Channel Keluar
RENDAH_LATENSI	EKSKLUSIF	BELUM DITENTUKAN	1	2
RENDAH_LATENSI	EKSKLUSIF	BELUM DITENTUKAN	2	1
RENDAH_LATENSI	DIBAGIKAN	BELUM DITENTUKAN	1	2
RENDAH_LATENSI	DIBAGIKAN	BELUM 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

Aliran data andal HARUS memenuhi kriteria berikut untuk Signal to Noise Ratio (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 di bagian ini.

7.9.1. Mode Virtual Reality

Android menyertakan dukungan untuk Mode VR, fitur yang menangani rendering notifikasi stereoskopis 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, implementasi 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 mengimplementasikan 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 menampilkan ekstensi EGL yang tersedia.
• [C-1-8] HARUS mengimplementasikan GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_EXT_protected_textures, dan menampilkan ekstensi dalam daftar ekstensi GL yang tersedia.
• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan GL_EXT_external_buffer, GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture, dan menampilkan ekstensi dalam daftar ekstensi GL yang tersedia.
• [C-SR-2] SANGAT DIREKOMENDASIKAN untuk mendukung Vulkan 1.1.
• [C-SR-3] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan 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 DIREKOMENDASIKAN untuk mengekspos setidaknya satu kelompok antrean Vulkan dengan 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 konten VR alternatif pada konten VR pada 60 fps dengan dua konteks rendering akan ditampilkan tanpa artefak sobek yang terlihat.
• [C-1-9] HARUS mengimplementasikan dukungan untuk AHardwareBuffer flag AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA, dan AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT seperti yang dijelaskan dalam NDK.
• [C-1-10] HARUS mengimplementasikan dukungan untuk AHardwareBuffer dengan kombinasi tanda penggunaan AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT setidaknya untuk 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 serta flag dan format yang ditentukan dalam C-1-10.
• [C-1-11] HARUS mendukung dekode H.264 minimal 3840 x 2160 pada 30 fps, yang dikompresi ke rata-rata 40 Mbps (setara dengan 4 instance sebesar 1920 x1080 pada 30 fps-10 Mbps atau 2 instance 1920 fps-2 Mbps pada 60 fps-20 Mbps).
• [C-1-12] HARUS mendukung HEVC dan VP9, HARUS mampu mendekode minimal 1920 x 1080 pada 30 fps yang dikompresi ke rata-rata 10 Mbps dan HARUS mampu mendekode 3840 x 2160 pada 30 fps-10 Mbps Mbps-20 Mbps (equival fps-20 Mbps).
• [C-1-13] HARUS mendukung HardwarePropertiesManager.getDeviceTemperatures API dan menampilkan nilai yang akurat untuk suhu kulit.
• [C-1-14] HARUS memiliki layar tersemat, dan resolusinya HARUS minimal 1920 x 1080.
• [C-SR-6] SANGAT DIREKOMENDASIKAN untuk memiliki resolusi layar minimal 2560x1440 piksel.
• [C-1-15] Layar HARUS diperbarui minimal 60 Hz saat berada dalam Mode VR.
• [C-1-17] Layar HARUS mendukung mode persistensi rendah dengan persistensi ≤ 5 milidetik, persistensi ditentukan sebagai lama waktu piksel memancarkan cahaya.
• [C-1-18] HARUS mendukung Ekstensi Panjang Data Bluetooth 4.2 dan Bluetooth LE bagian 7.4.3.
• [C-1-19] HARUS mendukung dan melaporkan Jenis Saluran Langsung dengan benar 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, seperti yang ditentukan dalam bagian 7.3.9.
• [C-SR-8] SANGAT DIREKOMENDASIKAN untuk mendukung fitur android.hardware.sensor.hifi_sensors.
• [C-1-22] HARUS memiliki gerakan end-to-end ke latensi foton yang tidak lebih tinggi dari 28 milidetik.
• [C-SR-9] SANGAT DIREKOMENDASIKAN untuk memiliki gerakan end-to-end pada latensi foton yang tidak lebih tinggi dari 20 milidetik.
• [C-1-23] HARUS memiliki rasio frame pertama, yang merupakan rasio antara kecerahan piksel pada frame pertama setelah transisi dari hitam ke putih dan kecerahan piksel putih dalam keadaan stabil, minimal 85%.
• [C-SR-10] SANGAT DIREKOMENDASIKAN untuk memiliki rasio frame pertama minimal 90%.
• DAPAT menyediakan core eksklusif ke aplikasi latar depan dan DAPAT mendukung Process.getExclusiveCores API untuk menampilkan jumlah core CPU yang eksklusif untuk aplikasi latar depan atas.

Jika inti eksklusif didukung, maka inti:

• [C-2-1] HARUS tidak mengizinkan proses userspace lain untuk dijalankan di dalamnya (kecuali driver perangkat yang digunakan oleh aplikasi), tetapi MUNGKIN memungkinkan beberapa proses kernel berjalan sesuai kebutuhan.

7.10. Sentuhan

7.11. Class Performa Media

Class performa media dari implementasi perangkat dapat diperoleh dari android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS API. Persyaratan untuk class performa media ditentukan untuk setiap versi Android yang dimulai dengan R (versi 30). Nilai khusus 0 menunjukkan bahwa perangkat bukan class performa media.

Jika implementasi perangkat menampilkan nilai bukan nol untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, implementasi tersebut:

• [C-1-1] HARUS menampilkan setidaknya nilai android.os.Build.VERSION_CODES.R.

• [C-1-2] HARUS merupakan implementasi perangkat genggam.

• [C-1-3] HARUS memenuhi semua persyaratan untuk "Kelas Performa Media" yang dijelaskan di pasal 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 Kekuatan

Beberapa kriteria performa dan daya minimum sangat penting untuk pengalaman pengguna dan memengaruhi asumsi dasar pengukuran 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 terukur untuk latensi antarmuka pengguna dan pengalihan tugas seperti yang dijelaskan di bagian 2.

8.2. Performa Akses I/O File

Memberikan 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 operasi tulis berurutan. Diukur dengan menulis file 256 MB menggunakan buffer tulis 10 MB.
• Performa penulisan acak. Diukur dengan menulis file 256 MB menggunakan buffer tulis 4 KB.
• Performa pembacaan berurutan. Diukur dengan membaca file 256 MB menggunakan buffer tulis 10 MB.
• Performa baca acak. Diukur dengan membaca file berukuran 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 (mis. Bucket Aplikasi Standby, Istirahatkan) atau memperluas fitur untuk menerapkan pembatasan yang lebih kuat daripada Bucket Aplikasi Standby yang DIBATASI, fitur tersebut akan:

• [C-1-1] TIDAK BOLEH menyimpang dari implementasi AOSP untuk pemicuan, pemeliharaan, algoritme bangun, dan penggunaan setelan sistem global atau DeviceConfig dari mode hemat daya Aplikasi Standby dan Istirahatkan.
• [C-1-2] TIDAK BOLEH menyimpang dari implementasi AOSP untuk penggunaan setelan global atau DeviceConfig guna mengelola throttling tugas, alarm, dan jaringan untuk aplikasi di setiap bucket untuk Aplikasi standby.
• [C-1-3] TIDAK BOLEH menyimpang dari implementasi AOSP untuk jumlah Bucket Aplikasi Standby yang digunakan untuk Aplikasi Standby.
• [C-1-4] HARUS menerapkan Bucket Aplikasi Standby dan 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 memberikan kemampuan kepada pengguna untuk menampilkan semua aplikasi yang dikecualikan dari mode hemat daya Aplikasi Standby dan Istirahatkan atau pengoptimalan baterai apa pun dan HARUS mengimplementasikan intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS untuk meminta pengguna mengizinkan aplikasi mengabaikan pengoptimalan baterai.
• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menyediakan kemampuan pengguna guna mengaktifkan dan menonaktifkan fitur penghemat baterai.
• [C-SR-2] SANGAT DIREKOMENDASIKAN untuk menyediakan kemampuan pengguna guna menampilkan semua aplikasi yang dikecualikan dari mode hemat daya Aplikasi Standby dan Istirahatkan.

Jika implementasi perangkat memperluas fitur pengelolaan daya yang disertakan dalam AOSP dan ekstensi tersebut menerapkan pembatasan yang lebih ketat daripada Bucket Aplikasi Standby yang Langka, lihat bagian 3.5.1.

Selain mode hemat daya, implementasi perangkat Android DAPAT menerapkan salah satu atau semua 4 status daya tidur seperti yang ditentukan oleh Antarmuka Konfigurasi dan Daya Lanjutan (ACPI).

Jika implementasi perangkat menerapkan status daya S4 seperti yang ditentukan oleh ACPI, implementasi tersebut:

• [C-1-1] HARUS memasuki status ini hanya setelah pengguna melakukan tindakan eksplisit untuk menyetel perangkat dalam keadaan tidak aktif (misalnya dengan menutup penutup yang secara fisik merupakan bagian perangkat atau mematikan kendaraan atau televisi) dan sebelum pengguna mengaktifkan kembali perangkat (misalnya dengan membuka penutup atau menyalakan kendaraan atau televisi kembali).

Jika implementasi perangkat menerapkan status daya S3 seperti yang ditentukan oleh ACPI, implementasi tersebut:

• [C-2-1] HARUS memenuhi C-1-1 di atas, atau, HARUS memasukkan 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, meskipun aplikasi pihak ketiga meminta untuk membuat layar tetap aktif melalui FLAG_KEEP_SCREEN_ON atau menjaga CPU tetap berjalan melalui PARTIAL_WAKE_LOCK, perangkat TIDAK BOLEH memasuki status S3 kecuali, seperti yang dijelaskan dalam C-1-1, pengguna telah mengambil tindakan eksplisit untuk menempatkan perangkat dalam status tidak aktif. Sebaliknya, pada saat tugas yang diterapkan oleh aplikasi pihak ketiga melalui JobScheduler dipicu atau Firebase Cloud Messaging dikirim ke aplikasi pihak ketiga, perangkat HARUS keluar dari status S3 kecuali jika pengguna telah menempatkan perangkat dalam status tidak aktif. Ini bukan contoh lengkap dan AOSP mengimplementasikan sinyal bangun ekstensif yang memicu bangun dari status ini.

8.4. Akuntansi Pemakaian Daya

Pencatatan dan pelaporan konsumsi daya yang lebih akurat memberi developer aplikasi insentif dan alat untuk mengoptimalkan pola penggunaan daya aplikasi.

Implementasi perangkat:

• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menyediakan profil daya per komponen yang menentukan nilai konsumsi saat ini untuk setiap komponen hardware dan perkiraan pengurasan baterai yang disebabkan oleh komponen dari waktu ke waktu, seperti yang didokumentasikan di situs Project Open Source Android.
• [C-SR-2] SANGAT DIREKOMENDASIKAN untuk melaporkan semua nilai konsumsi daya dalam miliampere jam (mAh).
• [C-SR-3] SANGAT DIREKOMENDASIKAN untuk melaporkan konsumsi daya CPU per UID setiap proses. Project Open Source Android memenuhi persyaratan melalui implementasi modul kernel uid_cputime.
• [C-SR-4] SANGAT DIREKOMENDASIKAN untuk menyediakan penggunaan daya ini melalui perintah shell adb shell dumpsys batterystats bagi developer aplikasi.
• HARUS diatribusikan ke 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 berjalan di latar belakang atau throttling CPU karena batas suhu. Android menyertakan antarmuka terprogram sehingga jika perangkat mendukung, aplikasi latar depan teratas dapat meminta agar sistem mengoptimalkan alokasi resource untuk mengatasi fluktuasi tersebut.

Implementasi perangkat:

• [C-0-1] HARUS melaporkan dukungan Mode Performa Berkelanjutan secara akurat melalui metode PowerManager.isSustainedPerformanceModeSupported() API.

• SEHARUSNYA mendukung Mode Performa Berkelanjutan.

Jika implementasi perangkat melaporkan dukungan Mode Performa Berkelanjutan, implementasi tersebut:

• [C-1-1] HARUS memberikan tingkat performa yang konsisten untuk aplikasi latar depan teratas setidaknya selama 30 menit, saat aplikasi memintanya.
• [C-1-2] HARUS mematuhi Window.setSustainedPerformanceMode() API dan API terkait lainnya.

Jika implementasi perangkat menyertakan dua core CPU atau lebih, implementasi tersebut:

• HARUS menyediakan setidaknya satu inti eksklusif yang dapat dicadangkan oleh aplikasi latar depan teratas.

Jika implementasi perangkat mendukung pemesanan satu inti eksklusif untuk aplikasi latar depan teratas, implementasi tersebut:

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

Jika implementasi perangkat tidak mendukung inti eksklusif, implementasi tersebut:

• [C-3-1] HARUS menampilkan daftar kosong melalui metode API Process.getExclusiveCores().

9. Kompatibilitas Model Keamanan

Implementasi perangkat:

• [C-0-1] HARUS menerapkan model keamanan yang konsisten dengan model keamanan platform Android seperti yang dijelaskan dalam dokumen referensi Keamanan dan Izin dalam API di dokumentasi developer Android.

• [C-0-2] HARUS mendukung penginstalan aplikasi yang ditandatangani sendiri tanpa memerlukan izin/sertifikat tambahan dari pihak/otoritas ketiga mana pun.

Jika implementasi perangkat mendeklarasikan fitur android.hardware.security.model.compatible, implementasi tersebut:

• [C-1-1] HARUS mendukung persyaratan yang tercantum dalam subpasal 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. Secara khusus, peran ini HARUS menerapkan setiap izin dan peran yang ditentukan seperti yang dijelaskan dalam dokumentasi SDK; tidak ada izin dan tidak ada peran yang dapat dihilangkan, diubah, atau diabaikan.

• MUNGKIN menambahkan izin tambahan, asalkan string ID izin baru tidak berada dalam namespace android.\*.

• [C-0-2] Izin dengan protectionLevel PROTECTION_FLAG_PRIVILEGED hanya boleh diberikan ke aplikasi yang telah diinstal sebelumnya di jalur dengan hak istimewa dari image sistem (serta file APEX) dan berada dalam subset izin yang diizinkan secara eksplisit untuk setiap aplikasi. Implementasi AOSP memenuhi persyaratan ini dengan membaca dan mematuhi izin yang diizinkan untuk setiap aplikasi dari file di jalur etc/permissions/ dan menggunakan system/priv-app dengan hak istimewa di jalur etc/permissions/.

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:

  • Alat ini diinstal pada saat pengiriman perangkat, DAN

  • Izin pengguna dapat diperoleh sebelum aplikasi menggunakan izin tersebut,

    ATAU

  • Izin runtime diberikan oleh kebijakan pemberian izin default atau untuk menyimpan peran platform.

• [C-0-6] HARUS memberikan izin ke android.permission.RECOVER_KEYSTORE hanya untuk aplikasi sistem yang mendaftarkan Agen Pemulihan yang diamankan dengan benar. Agen Pemulihan yang diamankan dengan tepat 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 dari yang dijelaskan dalam Google Cloud Key Vault Service 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 Android API standar atau mekanisme eksklusif. Data tersebut mencakup, tetapi tidak terbatas pada:

  • Lokasi perangkat (mis. lintang dan bujur) sebagaimana dijelaskan dalam bagian 9.8.8.
  • Informasi yang dapat digunakan untuk menentukan atau memperkirakan lokasi perangkat (mis. SSID, BSSID, ID Sel, atau lokasi jaringan yang terhubung ke perangkat).
  • Aktivitas fisik pengguna atau klasifikasi aktivitas fisik.

Lebih khusus lagi, implementasi 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 ke 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 akses lokasi Android di atas adalah bagi aplikasi yang tidak mengakses Lokasi untuk mendapatkan atau mengidentifikasi lokasi pengguna; khususnya:

• Saat aplikasi memiliki izin RADIO_SCAN_WITHOUT_LOCATION.
• Untuk tujuan penyiapan dan konfigurasi perangkat, saat aplikasi sistem memiliki izin NETWORK_SETTINGS atau NETWORK_SETUP_WIZARD.

Izin dapat ditandai sebagai perubahan perilaku yang dibatasi.

• [C-0-10] Izin yang ditandai dengan tanda hardRestricted TIDAK BOLEH diberikan ke aplikasi, kecuali:

  • File APK aplikasi ada 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 HARUS mendapatkan akses terbatas saja dan TIDAK BOLEH mendapatkan akses penuh sampai diizinkan sebagaimana dijelaskan di SDK. Aplikasi yang memiliki akses penuh dan terbatas untuk setiap izin softRestricted (misalnya, READ_EXTERNAL_STORAGE) ditentukan.

• [C-0-12] TIDAK BOLEH menyediakan fungsi atau API kustom apa pun untuk mengabaikan batasan izin yang ditentukan dalam API setPermissionPolicy dan setPermissionGrantState.

• [C-0-13] HARUS menggunakan AppOpsManager API untuk merekam dan melacak setiap akses terprogram atas data 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 menetapkan peran yang merupakan fungsi duplikat atau superset dari peran yang ditentukan oleh platform.

Jika perangkat melaporkan android.software.managed_users, perangkat:

• [C-1-1] TIDAK BOLEH memiliki izin berikut secara otomatis yang diberikan oleh admin:
  • Lokasi (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
  • Kamera (KAMERA)
  • Mikrofon (RECORD_AUDIO)
  • Sensor tubuh (BODY_SENSORS)
  • Aktivitas fisik (ACTIVITY_RECOGNITION)

Jika implementasi perangkat memberikan kemampuan pengguna untuk memilih aplikasi mana yang dapat menggunakan 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 apa pun yang disediakannya.

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

• [C-3-1] HARUS menampilkan pernyataan penyangkalan selama penyiapan perangkat yang terkelola sepenuhnya (penyiapan pemilik perangkat) yang menyatakan bahwa admin IT akan dapat mengizinkan aplikasi mengontrol setelan di ponsel, termasuk mikrofon, kamera, dan lokasi, dengan opsi bagi pengguna untuk melanjutkan penyiapan atau keluar dari penyiapan KECUALI admin telah menonaktifkan kontrol izin di perangkat.

Jika implementasi perangkat telah menginstal paket apa pun yang memiliki peran System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence, atau System Visual Intelligence, maka paket tersebut:

• [C-4-1] HARUS memenuhi semua persyaratan yang diuraikan untuk implementasi perangkat di bagian "9.8.6 Content Capture" "9.8.6 OS-level data dan standby data serta 9.8.15 Implementasi API dengan sandbox".

9.2. UID dan Isolasi Proses

Implementasi perangkat:

• [C-0-1] HARUS mendukung model sandbox aplikasi Android, dengan setiap aplikasi berjalan sebagai UID Unixstyle unik dan dalam proses terpisah.
• [C-0-2] HARUS mendukung pengoperasian beberapa aplikasi sebagai ID pengguna Linux yang sama, asalkan aplikasi ditandatangani dan dibuat dengan benar, seperti yang ditetapkan dalam referensi Keamanan dan Izin.

9.3. Izin Sistem File

Implementasi perangkat:

• [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 izin dan keamanan Android, meskipun menyertakan lingkungan runtime yang mengeksekusi aplikasi menggunakan beberapa software atau teknologi selain Format Dalvik Executable atau kode native. Dengan kata lain:

• [C-0-1] Runtime alternatif HARUS berupa aplikasi Android, dan mematuhi model keamanan Android standar, seperti yang dijelaskan di bagian lain dalam bagian 9.

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

• [C-0-3] Runtime alternatif TIDAK BOLEH mengizinkan aplikasi menggunakan fitur yang dilindungi oleh izin Android yang dibatasi untuk aplikasi sistem.

• [C-0-4] Runtime alternatif HARUS mematuhi model sandbox Android dan aplikasi terinstal yang menggunakan runtime alternatif TIDAK BOLEH menggunakan kembali sandbox aplikasi lain yang diinstal di perangkat, kecuali melalui mekanisme Android standar untuk ID pengguna bersama dan sertifikat penandatanganan.

• [C-0-5] Runtime alternatif TIDAK BOLEH diluncurkan dengan, memberikan, atau diberi akses ke sandbox yang terkait dengan aplikasi Android lainnya.

• [C-0-6] Runtime alternatif TIDAK BOLEH diluncurkan dengan, diberikan, atau memberikan hak istimewa apa pun kepada aplikasi lain dari superuser (root), atau ID pengguna lainnya.

• [C-0-7] Jika file .apk runtime alternatif disertakan dalam image sistem implementasi perangkat, file HARUS ditandatangani dengan kunci yang berbeda dengan 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 terkait (seperti Kamera, GPS, dll.), runtime alternatif HARUS memberi tahu pengguna bahwa aplikasi akan dapat mengakses resource tersebut.

• [C-0-10] Jika lingkungan runtime tidak merekam kemampuan aplikasi dengan cara ini, lingkungan runtime HARUS mencantumkan semua izin yang dimiliki oleh runtime itu sendiri saat menginstal aplikasi apa pun yang menggunakan runtime tersebut.

• Runtime alternatif HARUS menginstal aplikasi melalui PackageManager ke sandbox Android terpisah (ID pengguna Linux, dll.).

• Runtime alternatif MUNGKIN menyediakan satu sandbox Android yang digunakan bersama oleh semua aplikasi yang menggunakan runtime alternatif.

9,5. Dukungan Multipengguna

Android menyertakan dukungan untuk beberapa pengguna dan menyediakan dukungan untuk isolasi pengguna penuh serta meng-clone profil pengguna dengan isolasi sebagian(yaitu, profil pengguna tambahan tunggal dengan jenis android.os.usertype.profile.CLONE).

• Implementasi perangkat MUNGKIN, tetapi TIDAK BOLEH 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 seperti yang ditetapkan 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 dijalankan atas nama pengguna tertentu tidak dapat mencantumkan, membaca, atau menulis ke file milik pengguna lain, meskipun data kedua pengguna disimpan pada volume atau sistem file yang sama.
• [C-1-5] HARUS mengenkripsi konten kartu SD saat multipengguna diaktifkan menggunakan kunci yang hanya disimpan pada media yang tidak dapat dilepas dan 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 diperlukan untuk beralih ke MTP atau sistem serupa untuk memberi PC host akses ke data pengguna saat ini.

Jika implementasi perangkat menyertakan dukungan untuk beberapa pengguna, maka untuk semua pengguna kecuali pengguna yang dibuat 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 dijalankan atas nama pengguna tertentu tidak dapat mencantumkan, membaca, atau menulis ke file milik pengguna lain, meskipun data kedua pengguna tersebut disimpan pada volume atau sistem file yang sama.

Implementasi perangkat DAPAT membuat satu profil pengguna tambahan dari jenis android.os.usertype.profile.CLONE terhadap pengguna utama (dan hanya terhadap pengguna utama) untuk tujuan menjalankan instance ganda dari aplikasi yang sama. Dua instance ini berbagi penyimpanan yang terisolasi sebagian, disajikan kepada pengguna akhir di peluncur secara bersamaan, dan muncul di tampilan terbaru yang sama. Misalnya, ini dapat digunakan untuk mendukung pengguna menginstal dua instance terpisah dari satu aplikasi pada perangkat SIM ganda.

Jika implementasi perangkat membuat profil pengguna tambahan yang dibahas di atas, implementasi perangkat tersebut:

• [C-3-1] HARUS memberikan akses ke penyimpanan atau data saja 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 memiliki direktori data aplikasi pribadi yang terisolasi dari akun pengguna induk.
• [C-3-4] TIDAK BOLEH mengizinkan pembuatan profil pengguna tambahan jika ada Pemilik Perangkat yang disediakan (lihat bagian 3.9.1) atau mengizinkan Pemilik Perangkat untuk disediakan tanpa menghapus profil pengguna tambahan terlebih dahulu.

9.6. Peringatan SMS Premium

Android menyertakan dukungan untuk memperingatkan pengguna tentang setiap pesan SMS premium keluar. Pesan SMS Premium adalah pesan teks yang dikirim ke layanan yang terdaftar dengan operator yang dapat mengenakan biaya kepada pengguna.

Jika implementasi perangkat mendeklarasikan dukungan untuk android.hardware.telephony, implementasi perangkat akan:

• [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 implementasi 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.

Android Sandbox menyertakan 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, meskipun SELinux atau fitur keamanan lainnya diimplementasikan 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 terjadi pelanggaran keamanan yang dibatalkan pemblokirannya sehingga berhasil dieksploitasi.
• [C-0-3] TIDAK BOLEH membuat SELinux atau fitur keamanan lainnya yang diimplementasikan di bawah framework Android agar 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 Anda dapat memberikan akses secara lebih sempit untuk setiap proses seperti dijelaskan di situs Project Open Source Android.
• [C-0-6] HARUS mengimplementasikan mekanisme sandbox aplikasi kernel yang memungkinkan pemfilteran panggilan sistem menggunakan kebijakan yang dapat dikonfigurasi dari program multi-thread. Project Open Source Android upstream memenuhi persyaratan ini dengan mengaktifkan seccomp-BPF dengan sinkronisasi threadgroup (TSYNC) seperti yang dijelaskan di bagian Konfigurasi Kernel di source.android.com.

Integritas kernel dan fitur perlindungan diri merupakan bagian tak terpisahkan dari keamanan Android. Implementasi perangkat:

• [C-0-7] HARUS menerapkan mekanisme perlindungan overflow buffer stack kernel. Contoh mekanisme tersebut adalah CC_STACKPROTECTOR_REGULAR dan CONFIG_CC_STACKPROTECTOR_STRONG.
• [C-0-8] HARUS mengimplementasikan perlindungan memori kernel yang ketat jika 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 CONFIG_DEBUG_RODATA atau CONFIG_STRICT_KERNEL_RWX).
• [C-0-9] HARUS mengimplementasikan batas ukuran objek statis dan dinamis pemeriksaan salinan antara ruang pengguna dan ruang kernel (misalnya, CONFIG_HARDENED_USERCOPY) pada perangkat yang awalnya dikirim dengan level API 28 atau yang lebih tinggi.
• [C-0-10] TIDAK BOLEH mengeksekusi memori ruang pengguna saat mengeksekusi dalam mode kernel (misalnya PXN hardware, atau diemulasi melalui CONFIG_CPU_SW_DOMAIN_PAN atau CONFIG_ARM64_SW_TTBR0_PAN) pada perangkat yang pada 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 salinan pengguna normal (misalnya, PAN hardware, atau diemulasikan melalui CONFIG_CPU_SW_DOMAIN_PAN atau CONFIG_ARM64_SW_TTBR0_PAN) pada perangkat yang awalnya dikirimkan dengan API level 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 mengimplementasikan hardening 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 DIREKOMENDASIKAN untuk mengaktifkan inisialisasi stack dalam kernel guna mencegah penggunaan variabel lokal yang tidak diinisialisasi (CONFIG_INIT_STACK_ALL atau CONFIG_INIT_STACK_ALL_ZERO). Selain itu, implementasi perangkat TIDAK BOLEH mengasumsikan nilai yang digunakan oleh compiler untuk melakukan inisialisasi pada lokalitas.

• [C-SR-2] SANGAT DIREKOMENDASIKAN untuk mempertahankan data kernel yang hanya ditulis selama inisialisasi ditandai sebagai hanya baca setelah inisialisasi (misalnya __ro_after_init).

• [C-SR-3] SANGAT DIREKOMENDASIKAN untuk mengacak tata letak kode kernel dan memori, serta untuk menghindari eksposur yang dapat membahayakan pengacakan (misalnya CONFIG_RANDOMIZE_BASE dengan entropi bootloader melalui /chosen/kaslr-seed Device Tree node atau EFI_RNG_PROTOCOL).

• [C-SR-4] SANGAT DIREKOMENDASIKAN untuk mengaktifkan integritas alur kontrol (CFI) di kernel guna memberikan perlindungan tambahan terhadap serangan penggunaan kembali kode (misalnya CONFIG_CFI_CLANG dan CONFIG_SHADOW_CALL_STACK).

• [C-SR-5] SANGAT DIREKOMENDASIKAN untuk tidak menonaktifkan Control-Flow Integrity (CFI), Shadow Call Stack (SCS), atau Integer Overflow Sanitization (IntSan) pada komponen yang telah mengaktifkannya.

• [C-SR-6] SANGAT DIREKOMENDASIKAN untuk mengaktifkan CFI, SCS, dan IntSan bagi komponen userspace tambahan yang sensitif terhadap keamanan seperti yang dijelaskan dalam CFI dan IntSan.

• [C-SR-7] SANGAT DIREKOMENDASIKAN untuk mengaktifkan inisialisasi stack dalam kernel guna mencegah penggunaan variabel lokal yang tidak diinisialisasi (CONFIG_INIT_STACK_ALL atau CONFIG_INIT_STACK_ALL_ZERO). Selain itu, implementasi perangkat TIDAK BOLEH mengasumsikan nilai yang digunakan oleh compiler untuk melakukan inisialisasi lokal.

• [C-SR-8] SANGAT DIREKOMENDASIKAN untuk mengaktifkan inisialisasi heap pada kernel guna mencegah penggunaan alokasi heap yang tidak diinisialisasi (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) dan TIDAK BOLEH mengasumsikan nilai yang digunakan oleh kernel untuk melakukan inisialisasi alokasi tersebut.

Jika implementasi perangkat menggunakan kernel Linux yang mampu mendukung SELinux, implementasi tersebut:

• [C-1-1] HARUS mengimplementasikan SELinux.
• [C-1-2] HARUS menyetel SELinux ke mode penerapan global.
• [C-1-3] HARUS mengonfigurasi semua domain dalam mode penerapan. Domain mode permisif tidak diizinkan, termasuk domain khusus untuk perangkat/vendor.
• [C-1-4] TIDAK BOLEH memodifikasi, menghilangkan, atau mengganti aturan tidak pernah yang ada dalam folder sistem/sepolicy yang disediakan di Project Open Source Android upstream (AOSP) dan kebijakan HARUS dikompilasi dengan semua aturan yang ada, untuk domain SELinux AOSP serta domain khusus perangkat/vendor.
• [C-1-5] HARUS menjalankan aplikasi pihak ketiga yang menargetkan API level 28 atau yang lebih tinggi dalam sandbox SELinux per aplikasi dengan pembatasan SELinux per aplikasi di direktori data pribadi setiap aplikasi.
• HARUS mempertahankan kebijakan SELinux default yang disediakan di folder sistem/sepolicy Project Open Source Android upstream dan hanya menambahkan kebijakan ini lagi ke kebijakan ini untuk konfigurasi khusus perangkatnya sendiri.

Jika implementasi perangkat menggunakan kernel selain Linux atau Linux tanpa SELinux, implementasi tersebut:

• [C-2-1] HARUS menggunakan sistem kontrol akses wajib yang setara dengan SELinux.

Jika implementasi perangkat menggunakan perangkat I/O yang mendukung DMA, implementasi tersebut:

• [C-SR-9] SANGAT DIREKOMENDASIKAN untuk mengisolasi setiap perangkat I/O yang mendukung DMA, menggunakan IOMMU (mis. ARM SMMU).

Android memuat beberapa fitur defense in depth yang tidak terpisahkan dengan keamanan perangkat. Selain itu, Android berfokus untuk mengurangi kelas utama bug umum yang berkontribusi pada kualitas dan keamanan yang buruk.

Untuk mengurangi bug memori, implementasi perangkat:

• [C-SR-10] SANGAT DIREKOMENDASIKAN untuk diuji menggunakan alat deteksi error memori userspace seperti MTE untuk perangkat ARMv9, HWASan untuk perangkat ARMv8+, atau ASan untuk jenis perangkat lainnya.
• [C-SR-11] SANGAT DIREKOMENDASIKAN 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 DIREKOMENDASIKAN 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 DIREKOMENDASIKAN untuk menggunakan protokol standar untuk berbagi memori, antara Android dan TEE, seperti Arm Firmware Framework for Armv8-A (FF-A).
• [C-SR-14] SANGAT DIREKOMENDASIKAN untuk membatasi aplikasi tepercaya hanya untuk mengakses memori yang telah dibagikan secara eksplisit kepada aplikasi melalui protokol di atas. Jika perangkat memiliki dukungan untuk level pengecualian Arm S-EL2, hal ini harus diberlakukan oleh pengelola partisi yang aman. Jika tidak, tindakan ini harus diterapkan oleh TEE OS.

9.8. Privasi

9.8.1 Histori Penggunaan

Android menyimpan histori pilihan pengguna dan mengelola histori tersebut melalui UsageStatsManager.

Implementasi perangkat:

• [C-0-1] HARUS mempertahankan periode retensi yang wajar untuk histori pengguna tersebut.
• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mempertahankan periode retensi data 14 hari seperti yang dikonfigurasi secara default dalam implementasi 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 System API IncidentManager.
• [C-0-3] TIDAK BOLEH menggunakan ID peristiwa sistem untuk mencatat peristiwa 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 melakukan pramuat atau mendistribusikan komponen software secara langsung yang akan mengirimkan informasi pribadi pengguna (misalnya penekanan tombol, teks yang ditampilkan di layar, laporan bug) dari perangkat tanpa persetujuan pengguna atau menghapus notifikasi yang berkelanjutan.
• [C-0-2] HARUS menampilkan peringatan pengguna dan mendapatkan izin eksplisit dari pengguna, sehingga informasi sensitif yang ditampilkan di layar pengguna dapat diambildiaktifkan, yang menyertakan pesan yang sama persis dengan AOSP kapan pun setiap kali setiap kali sesi untuk merekam layar casting atau perekaman layar diaktifkan, dimulai MediaProjection.createVirtualDisplay() VirtualDeviceManager.createVirtualDisplay() TIDAK BOLEH memberi pengguna kemampuan untuk menonaktifkan tampilan izin pengguna di masa mendatang.
• [C-0-3] HARUS memiliki notifikasi berkelanjutan kepada pengguna saat transmisi layar atau perekaman layar diaktifkan. AOSP memenuhi persyaratan ini dengan menampilkan ikon notifikasi yang sedang berlangsung di status bar.

Jika implementasi perangkat menyertakan fungsi dalam sistem yang merekam konten yang ditampilkan di layar dan/atau merekam streaming audio yang diputar di perangkat selain melalui ContentCaptureService System API, atau cara eksklusif lainnya yang dijelaskan di Pasal 9.8.6 data standby dan level OS, aplikasi tersebut:

• [C-1-1] HARUS memiliki notifikasi berkelanjutan kepada pengguna setiap kali fungsi ini diaktifkan dan merekam/merekam secara aktif.

Jika implementasi perangkat menyertakan komponen yang diaktifkan di luar kotak, yang mampu merekam audio standby dan/atau merekam audio yang diputar pada perangkat untuk menyimpulkan informasi yang berguna tentang konteks pengguna, implementasi tersebut:

• [C-2-1] TIDAK BOLEH menyimpan rekaman audio mentah atau format apa pun yang dapat dikonversi kembali ke audio asli atau faksimili di dekat perangkat, kecuali dengan persetujuan eksplisit dari pengguna.

“Indikator mikrofon” mengacu pada tampilan di layar, yang terus terlihat oleh pengguna dan tidak dapat dikaburkan, yang dipahami pengguna saat mikrofon sedang digunakan(melalui teks, warna, ikon yang unik, atau kombinasi lainnya).

"Indikator kamera" mengacu pada tampilan di layar, yang terus terlihat oleh pengguna dan tidak dapat dikaburkan, yang dipahami pengguna saat kamera sedang digunakan (melalui teks, warna, ikon, atau kombinasi yang unik).

Setelah detik pertama ditampilkan, indikator dapat berubah secara visual, misalnya menjadi lebih kecil, dan tidak perlu ditampilkan seperti yang ditampilkan dan dipahami.

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 DIREKOMENDASIKAN untuk menampilkan indikator mikrofon saat aplikasi mengakses data audio dari mikrofon, tetapi tidak ketika mikrofon hanya diakses oleh HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService, atau aplikasi yang memegang peran yang disebutkan di Pasal 9.1 Izin dengan ID CDD [C-3-X]. .
• [C-SR-2] SANGAT DIREKOMENDASIKAN untuk menampilkan daftar aplikasi Terbaru dan Aktif menggunakan mikrofon seperti yang ditampilkan dari PermissionManager.getIndicatorAppOpUsageData(), bersama dengan pesan atribusi apa pun yang terkait dengannya.
• [C-SR-3] SANGAT DIREKOMENDASIKAN agar 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 DIREKOMENDASIKAN untuk menampilkan indikator kamera saat aplikasi mengakses data kamera live, tetapi tidak ketika kamera hanya diakses oleh aplikasi yang memiliki peran yang disebutkan di Pasal 9.1 Izin dengan ID CDD [C-3-X].
• [C-SR-5] SANGAT DIREKOMENDASIKAN untuk menampilkan aplikasi Terbaru dan Aktif menggunakan kamera seperti yang ditampilkan dari PermissionManager.getIndicatorAppOpUsageData(), beserta pesan atribusi apa pun yang terkait.
• [C-SR-6] SANGAT DIREKOMENDASIKAN agar tidak menyembunyikan indikator kamera untuk aplikasi sistem yang memiliki antarmuka pengguna yang terlihat atau interaksi pengguna langsung.

9.8.3. Konektivitas

Jika implementasi perangkat memiliki port USB dengan dukungan mode periferal USB, implementasi tersebut:

• [C-1-1] HARUS menampilkan antarmuka pengguna yang meminta persetujuan pengguna sebelum mengizinkan akses ke konten penyimpanan bersama melalui port USB.

9.8.4. Traffic Jaringan

Implementasi perangkat:

• [C-0-1] HARUS menginstal root certificate yang sama untuk penyimpanan Certificate Authority (CA) yang tepercaya sistem seperti yang disediakan di Project Open Source Android upstream.
• [C-0-2] HARUS mengirimkan dengan penyimpanan CA root pengguna kosong.
• [C-0-3] HARUS menampilkan peringatan kepada pengguna yang menunjukkan bahwa traffic jaringan mungkin dipantau, saat root CA pengguna ditambahkan.

Jika traffic perangkat dirutekan melalui VPN, implementasi perangkat akan:

• [C-1-1] HARUS menampilkan peringatan kepada pengguna yang menunjukkan:
  • Traffic jaringan tersebut mungkin dipantau.
  • Lalu lintas jaringan diarahkan melalui aplikasi VPN khusus yang menyediakan VPN.

Jika penerapan perangkat memiliki mekanisme yang diaktifkan secara default dan merutekan traffic data jaringan melalui server proxy atau gateway VPN (misalnya, pramuat layanan VPN dengan pemberian android.permission.CONTROL_VPN), implementasi tersebut:

• [C-2-1] HARUS meminta persetujuan pengguna sebelum mengaktifkan mekanisme tersebut, kecuali jika VPN diaktifkan oleh Pengontrol Kebijakan Perangkat melalui DevicePolicyManager.setAlwaysOnVpnPackage() , dalam hal ini pengguna tidak perlu memberikan izin terpisah, tetapi HARUS diberi tahu hanya.

Jika implementasi perangkat menerapkan kemampuan pengguna untuk mengaktifkan fungsi "VPN selalu aktif" aplikasi VPN pihak ketiga, implementasi tersebut:

• [C-3-1] HARUS menonaktifkan kemampuan pengguna ini untuk aplikasi yang tidak mendukung layanan VPN selalu aktif di file AndroidManifest.xml dengan menetapkan 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 bertanda tangan yang diverifikasi oleh produsen perangkat.
  • telah diberi izin READ_PRIVILEGED_PHONE_STATE.
  • memiliki hak istimewa operator seperti yang ditetapkan dalam Hak Istimewa Operator UICC.
  • adalah pemilik perangkat atau pemilik profil yang telah diberi izin READ_PHONE_STATE.
  • (Hanya untuk nomor seri SIM/ICCID) memiliki persyaratan peraturan setempat bahwa aplikasi dapat mendeteksi perubahan pada identitas pelanggan.

9.8.6. Pengambilan Konten dan Penelusuran AplikasiData tingkat OS dan standby

Android, melalui API Sistem ContentCaptureService, AugmentedAutofillService, AppSearchGlobalManager.query, atau dengan cara eksklusif lainnya, mendukung mekanisme implementasi perangkat untuk menangkap interaksi data aplikasi antara aplikasi dan data sensitif pengguna berikut:

• Teks dan grafis yang dirender di layar, termasuk, tetapi tidak terbatas pada, notifikasi dan data bantuan melalui AssistStructure API.
• Data media, seperti audio atau video, yang direkam atau diputar oleh perangkat.
• Peristiwa input (misalnya, tombol, mouse, gestur, suara, video, dan aksesibilitas).

• Teks atau data lain apa pun yang dikirim melalui TextClassifier API ke System TextClassifier, yaitu ke layanan sistem untuk memahami arti teks, serta menghasilkan prediksi tindakan berikutnya berdasarkan teks.
• Data yang diindeks oleh penerapan AppSearch platform, termasuk, tetapi tidak terbatas pada teks, grafik, data media, atau data serupa lainnya.

Jika implementasi perangkat mengambil salah satu data di atas, implementasi tersebut:

• [C-1-1] HARUS mengenkripsi semua data tersebut saat disimpan di perangkat. Enkripsi ini DAPAT dilakukan menggunakan Enkripsi Berbasis File Android, atau cipher apa pun yang tercantum sebagai API versi 26+ yang dijelaskan dalam Cipher SDK.
• [C-1-2] TIDAK BOLEH mencadangkan data mentah atau terenkripsi menggunakan metode pencadangan Android atau metode pencadangan lainnya.
• [C-1-3] Hanya boleh mengirim semua data tersebut dan log dari perangkat menggunakan mekanisme yang menjaga privasi, kecuali dengan izin eksplisit dari pengguna setiap kali data dibagikan. Mekanisme yang menjaga privasi didefinisikan sebagai "fungsi yang hanya memungkinkan analisis secara gabungan dan mencegah pencocokan peristiwa yang dicatat ke dalam log atau hasil turunan dengan masing-masing pengguna", untuk mencegah data per pengguna agar tidak dapat diintegrasikan (misalnya, diterapkan menggunakan teknologi privasi diferensial seperti RAPPOR).
• [C-1-4] TIDAK BOLEH mengaitkan data tersebut dengan identitas pengguna apa pun (seperti Account) di perangkat, kecuali dengan izin eksplisit dari pengguna setiap kali data dikaitkan.
• [C-1-5] TIDAK BOLEH membagikan data tersebut dengan komponen OS lain yang tidak mengikuti persyaratan yang diuraikan di bagian saat ini (9.8.6 Pengambilan Konten Data level OS dan standby), kecuali dengan izin eksplisit dari pengguna setiap kali data tersebut dibagikan. Kecuali fungsi tersebut dibangun sebagai Android SDK API (AmbientContext, HotwordDetectionService).
• [C-1-6] HARUS memberikan kemampuan pengguna untuk menghapus data sedemikian rupa sehingga implementasi ContentCaptureService atau cara eksklusif mengumpulkan jika saat data disimpan dalam bentuk apa pun di perangkat. Jika pengguna memilih untuk menghapus data, HARUS menghapus semua data historis yang dikumpulkan.
• [C-1-7] HARUS memberikan kemampuan pengguna untuk memilih tidak menerima data, yang dikumpulkan melalui AppSearch atau sarana eksklusif agar tidak ditampilkan di platform Android, misalnya peluncur.
• [C-SR-1] SANGAT DIREKOMENDASIKAN UNTUK TIDAK meminta izin INTERNET.
• [C-SR-2] SANGAT DIREKOMENDASIKAN untuk hanya mengakses internet melalui API terstruktur yang didukung oleh implementasi open source yang tersedia untuk publik.

Jika implementasi perangkat menyertakan layanan yang menerapkan System API ContentCaptureService, AppSearchManager.index, atau layanan eksklusif apa pun yang mengambil data seperti yang dijelaskan di atas, implementasi tersebut:

• [C-2-1] TIDAK BOLEH mengizinkan pengguna mengganti layanan dengan aplikasi atau layanan yang dapat diinstal pengguna dan HARUS mengizinkan layanan bawaan untuk mengambil data tersebut.
• [C-2-2] TIDAK BOLEH mengizinkan aplikasi apa pun selain mekanisme layanan bawaan untuk mengambil data tersebut.
• [C-2-3] HARUS memberikan affordance pengguna untuk menonaktifkan layanan.
• [C-2-4] TIDAK BOLEH menghilangkan affordance pengguna untuk mengelola izin Android yang dipegang oleh layanan dan mengikuti model izin Android seperti yang dijelaskan di Bagian 9.1. Izin.

• [C-SR-3] SANGAT DIREKOMENDASIKAN untuk menjaga agar layanan tetap terpisah dari komponen sistem lainnya(misalnya tidak mengikat layanan atau berbagi ID proses), kecuali untuk hal berikut:

  • Telepon, Kontak, UI Sistem, dan Media

9.8.7. Akses Papan Klip

Implementasi perangkat:

• [C-0-1] TIDAK BOLEH menampilkan data yang terpotong dari papan klip (mis., melalui ClipboardManager API) kecuali jika aplikasi pihak ketiga adalah IME default atau merupakan aplikasi yang saat ini memiliki fokus.

• [C-0-2] HARUS menghapus data papan klip paling lama 60 menit setelah data terakhir ditempatkan dalam papan klip atau dibaca dari papan klip.

9.8.8. Lokasi

Lokasi mencakup informasi dalam kelas Lokasi Android( seperti Lintang, Bujur, Ketinggian), serta ID yang dapat dikonversi ke Lokasi. Lokasi dapat semulus DGPS (Sistem Pemosisi Global Diferensial) atau seluas lokasi tingkat negara (seperti lokasi kode negara - MCC - Kode Negara Seluler).

Berikut adalah daftar jenis lokasi yang secara langsung memperoleh lokasi pengguna atau dapat dikonversi menjadi lokasi pengguna. Ini bukanlah daftar lengkap, tetapi harus digunakan sebagai contoh tentang potensi manfaat Lokasi secara langsung atau tidak langsung:

• GPS/GNSS/DGPS/PPP
  • Solusi Pemosisi Global atau Sistem Satelit Navigasi Global atau Solusi Pemosisi Global Diferensial
  • Hal ini juga mencakup Pengukuran GNSS Mentah dan Status GNSS
    • Lokasi terperinci dapat berasal 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 BTS (3G, 4G, 5G... Termasuk semua teknologi Modem Seluler masa depan 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 pengguna atau inisiasi pengguna secara eksplisit.
• [C-0-2] HARUS memberikan kemampuan kepada 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 Darurat Lokasi Pengabaian API [LocationRequest.setLocationSettingsIgnored()] adalah sesi darurat yang dimulai pengguna (misalnya, telepon 911 atau kirim pesan ke 911). Namun, untuk Automotive, kendaraan DAPAT memulai sesi darurat tanpa interaksi pengguna aktif jika tabrakan/kecelakaan terdeteksi (mis. untuk memenuhi persyaratan eCall).
• [C-0-4] HARUS mempertahankan kemampuan Darurat Location Pengabaian API untuk mengabaikan setelan lokasi perangkat tanpa mengubah setelan.
• [C-0-5] HARUS menjadwalkan notifikasi yang mengingatkan pengguna setelah aplikasi di latar belakang mengakses lokasinya menggunakan izin [ACCESS_BACKGROUND_LOCATION].

9.8.9. Aplikasi terinstal

Aplikasi Android yang menargetkan API level 30 atau yang lebih tinggi tidak dapat melihat detail tentang aplikasi terinstal lainnya secara default (lihat Visibilitas paket dalam dokumentasi Android SDK).

Implementasi perangkat:

• [C-0-1] TIDAK BOLEH mengekspos aplikasi apa pun yang menargetkan API level 30 atau yang lebih tinggi tentang aplikasi terinstal lainnya, kecuali 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 pengimplementasi perangkat, atau dapat diakses melalui sistem file.
• [C-0-2] TIDAK BOLEH memberi aplikasi apa pun, akses baca, atau tulis ke file di direktori khusus aplikasi khusus aplikasi lain dalam penyimpanan eksternal. Satu-satunya pengecualian adalah sebagai berikut:
  • Otoritas penyedia penyimpanan eksternal (misalnya, aplikasi seperti DocumentsUI).
  • Penyedia download yang menggunakan otoritas penyedia “download” untuk mendownload file ke penyimpanan aplikasi.
  • Aplikasi protokol transfer media (MTP) yang ditandatangani platform yang menggunakan izin hak istimewa ACCESS_MTP untuk memungkinkan transfer file ke perangkat lain.
  • Aplikasi yang menginstal aplikasi lain dan memiliki izin INSTALL_PACKAGES hanya dapat mengakses direktori “obb” untuk mengelola file ekspansi APK.

9.8.10. Laporan Bug Konektivitas

Jika implementasi perangkat mendeklarasikan flag fitur android.hardware.telephony, implementasi tersebut:

• [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 berikutnya dari aplikasi.
• [C-1-3] TIDAK BOLEH menampilkan laporan yang dihasilkan ke aplikasi yang meminta tanpa izin eksplisit dari pengguna.
• [C-1-4] Laporan yang dihasilkan menggunakan BUGREPORT_MODE_TELEPHONY HARUS berisi setidaknya informasi berikut:
  • Dump TelephonyDebugService
  • Dump TelephonyRegistry
  • Dump WifiService
  • Dump ConnectivityService
  • Dump instance CarrierService paket panggilan (jika terikat)
  • Buffer log radio
  • File dump SubscriptionManagerService
• [C-1-5] TIDAK BOLEH menyertakan hal berikut dalam laporan yang dihasilkan:
  • Semua jenis informasi yang tidak terkait langsung dengan proses debug konektivitas.
  • Segala jenis log traffic aplikasi yang diinstal pengguna atau profil mendetail aplikasi/paket yang diinstal pengguna (UID dapat digunakan, tetapi nama paket tidak dapat digunakan).
• DAPAT menyertakan informasi tambahan yang tidak terkait dengan identitas pengguna apa pun. (misalnya, log vendor).

Jika implementasi perangkat menyertakan informasi tambahan (misalnya log vendor) dalam laporan bug dan informasi tersebut memiliki dampak privasi/keamanan/baterai/penyimpanan/memori, implementasi tersebut:

• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menyetel setelan developer secara default ke dinonaktifkan. Implementasi referensi AOSP memenuhi hal ini dengan menyediakan opsi Enable verbose vendor logging di setelan developer untuk menyertakan log vendor khusus perangkat tambahan dalam laporan bug.

9.8.11. Berbagi blob data

Android, melalui BlobStoreManager memungkinkan aplikasi menyumbangkan blob data ke Sistem untuk dibagikan ke sekumpulan aplikasi yang dipilih.

Jika implementasi perangkat mendukung blob data bersama seperti yang dijelaskan dalam dokumentasi SDK, implementasi tersebut akan:

• [C-1-1] TIDAK BOLEH membagikan blob data milik aplikasi selain yang ingin diizinkan (yaitu cakupan akses default dan mode akses lain 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 perangkat atau membagikan hash aman blob data ke aplikasi lain (yang digunakan untuk mengontrol akses).

9.8.12. Pengenalan Musik

Android, melalui System API MusicRecognitionManager, mendukung mekanisme penerapan perangkat untuk meminta pengenalan musik, dengan rekaman audio, dan mendelegasikan pengenalan musik ke aplikasi dengan hak istimewa yang menerapkan MusicRecognitionService API.

Jika implementasi perangkat menyertakan layanan yang menerapkan MusicRecognitionManager System API atau layanan eksklusif apa pun yang melakukan streaming data audio seperti dijelaskan di atas, penerapan tersebut:

• [C-1-1] HARUS memberlakukan bahwa pemanggil MusicRecognitionManager memiliki izin MANAGE_MUSIC_RECOGNITION
• [C-1-2] HARUS menerapkan bahwa satu aplikasi pengenalan musik yang telah diinstal sebelumnya akan mengimplementasikan 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 data audio dan meneruskannya ke aplikasi yang menerapkan MusicRecognitionService, akses audio akan dilacak melalui panggilan AppOpsManager.noteOp / startOp.

Jika implementasi perangkat MusicRecognitionManagerService atau MusicRecognitionService menyimpan data audio yang direkam, implementasi tersebut:

• [C-2-1] TIDAK BOLEH menyimpan sama sekali sidik jari audio atau audio mentah di disk, atau di memori lebih dari 14 hari.
• [C-2-2] TIDAK BOLEH membagikan data tersebut di luar MusicRecognitionService, kecuali dengan izin pengguna yang eksplisit setiap kali data tersebut dibagikan.

9.8.13. SensorPrivacyManager

Jika implementasi perangkat memberi pengguna affordance software untuk menonaktifkan input kamera dan/atau mikrofon untuk implementasi perangkat, implementasi tersebut akan:

• [C-1-1] HARUS menampilkan 'true' secara akurat untuk metode API supportsSensorRedirect() yang relevan.
• [C-1-2] HARUS, saat aplikasi mencoba mengakses mikrofon atau kamera yang diblokir, memberi pengguna kemampuan pengguna yang tidak dapat ditutup yang dengan jelas menunjukkan bahwa sensor diblokir dan memerlukan pilihan untuk terus memblokir atau berhenti memblokir sesuai dengan implementasi AOSP yang memenuhi persyaratan ini.
• [C-1-3] Hanya boleh meneruskan data kamera dan audio yang kosong (atau palsu) ke aplikasi dan tidak melaporkan kode error karena pengguna tidak mengaktifkan kamera atau mikrofon melalui kemampuan pengguna yang ditampilkan sesuai [C-1-2] di atas.

9,9. Enkripsi Penyimpanan Data

Semua perangkat HARUS memenuhi persyaratan pasal 9.9.1. Perangkat yang diluncurkan pada level API yang lebih lama dari dokumen ini dikecualikan dari persyaratan bagian 9.9.2 dan 9.9.3; sebagai gantinya, perangkat tersebut HARUS memenuhi persyaratan pasal 9.9 dalam dokumen Definisi Kompatibilitas Android terkait dengan level API tempat perangkat diluncurkan.

9.9.1 Direct Boot

Implementasi perangkat:

• [C-0-1] HARUS menerapkan API mode Direct Boot meskipun API tersebut tidak mendukung Storage Encryption.

• [C-0-2] Intent ACTION_LOCKED_BOOT_COMPLETED dan ACTION_USER_UNLOCKED masih harus disiarkan untuk memberi sinyal pada aplikasi yang mendukung Direct Boot bahwa lokasi penyimpanan Device Encrypted (DE) dan Credential Encrypted (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 perangkat yang permanen dan tidak dapat dilepas.
• [C-0-2] HARUS mengaktifkan enkripsi penyimpanan data secara default pada saat pengguna menyelesaikan pengalaman penyiapan otomatis.

• [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 dalam pasal 9.9.3.1.
  • Enkripsi Tingkat Blok Per Pengguna sebagaimana dijelaskan dalam pasal 9.9.3.2.

9.9.3. Metode Enkripsi

Jika implementasi perangkat dienkripsi, implementasi tersebut:

• [C-1-1] HARUS melakukan booting tanpa meminta kredensial pengguna dan mengizinkan aplikasi yang mendukung Direct Boot untuk mengakses penyimpanan Device Encrypted (DE) setelah pesan ACTION_LOCKED_BOOT_COMPLETED disiarkan.
• [C-1-2] HARUS mengizinkan akses ke penyimpanan yang Dienkripsi Kredensial (CE) hanya setelah pengguna membuka kunci perangkat dengan memberikan kredensial (misalnya, kode sandi, PIN, pola, atau sidik jari) dan pesan ACTION_USER_UNLOCKED disiarkan.
• [C-1-13] TIDAK BOLEH menawarkan metode apa pun untuk membuka kunci penyimpanan yang dilindungi CE tanpa kredensial yang disediakan pengguna, kunci dana jaminan terdaftar, atau resume implementasi mulai ulang yang memenuhi persyaratan di pasal 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, implementasi tersebut:

• [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 kunci sepenuhnya adalah 512 bit. Adiantum merujuk ke Adiantum-XChaCha12-AES, seperti yang 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 ARMv8 Cryptography Extensions pada perangkat berbasis ARM, atau AES-NI pada perangkat berbasis x86), opsi berbasis AES di atas untuk nama file, konten file, dan enkripsi metadata sistem file HARUS digunakan, bukan Adiantum.
• [C-1-13] HARUS menggunakan fungsi derivasi kunci yang kuat secara kriptografis dan non-reversibel (misalnya, HKDF-SHA512) untuk mendapatkan subkunci yang diperlukan (misalnya kunci per file) dari kunci CE dan DE. "Kuat secara kriptografis dan non-reversibel" berarti fungsi derivasi kunci memiliki kekuatan keamanan minimal 256 bit dan berperilaku sebagai kelompok fungsi pseudorandom pada 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 penurunan kunci, atau untuk dua algoritma enkripsi yang berbeda).
• [C-1-15] HARUS memastikan bahwa semua blok konten file terenkripsi yang tidak dihapus pada 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 pada penyimpanan persisten di direktori yang berbeda dienkripsi menggunakan kombinasi kunci enkripsi dan initialization vector (IV).

• [C-1-17] HARUS memastikan bahwa semua blok metadata sistem file yang dienkripsi pada penyimpanan persisten dienkripsi menggunakan kombinasi kunci enkripsi dan initialization vector (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 dengan Booting Terverifikasi dan root kepercayaan hardware perangkat.
  • [C-1-8] Kunci CE HARUS terikat dengan kredensial layar kunci pengguna.
  • [C-1-9] Kunci CE HARUS terikat dengan kode 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 lainnya.
  • [C-1-11] HARUS menggunakan cipher, panjang kunci, dan mode yang didukung secara wajib.
  • [C-1-12] HARUS dihapus dengan aman selama membuka kunci dan mengunci bootloader seperti yang dijelaskan di sini.

• HARUS membuat aplikasi penting yang sudah diinstal lebih dulu (misalnya Alarm, Telepon, Messenger) yang mendukung Direct Boot.

Project Open Source Android upstream menyediakan implementasi yang lebih disukai dari 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, implementasi tersebut:

• [C-1-1] HARUS mengaktifkan dukungan multi-pengguna sebagaimana dijelaskan dalam 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 block-level 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 dengan Booting Terverifikasi dan root kepercayaan hardware perangkat.
  • [C-1-6] HARUS terikat dengan kredensial layar kunci pengguna yang sesuai.

Enkripsi tingkat blok per pengguna dapat diimplementasikan menggunakan fitur "dm-crypt" kernel Linux melalui partisi per pengguna.

9.9.4. Lanjutkan saat Mulai Ulang

Lanjutkan saat Reboot memungkinkan pembukaan kunci penyimpanan CE semua aplikasi, termasuk yang belum mendukung Direct Boot, setelah mulai ulang yang dimulai oleh OTA. Fitur ini memungkinkan pengguna menerima notifikasi dari aplikasi terinstal setelah memulai ulang.

Implementasi Lanjutkan-saat-Mulai Ulang harus terus memastikan bahwa saat perangkat jatuh ke tangan penyerang, akan sangat sulit bagi penyerang untuk memulihkan data pengguna yang dienkripsi dengan CE, meskipun perangkat dinyalakan, penyimpanan CE tidak terkunci, dan pengguna telah membuka kunci perangkat setelah menerima OTA. Untuk ketahanan terhadap serangan orang dalam, kami juga berasumsi bahwa penyerang mendapatkan akses untuk menyiarkan kunci penandatanganan kriptografis.

Khususnya:

• [C-0-1] Penyimpanan CE TIDAK BOLEH dapat dibaca sekalipun penyerang yang secara fisik memiliki perangkat lalu memiliki kemampuan dan batasan ini:

  • 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 memodifikasi pengoperasian hardware yang tahan perusakan (misalnya, Titan M).
  • Tidak dapat membaca RAM perangkat aktif.
  • Tidak dapat memperoleh kredensial pengguna (PIN, pola, sandi) atau menyebabkannya dimasukkan.

Sebagai contoh, implementasi perangkat yang mengimplementasikan dan mematuhi semua deskripsi yang ada 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 nya memungkinkan flash image sistem.

• [C-0-2] HARUS mendukung Booting Terverifikasi untuk integritas perangkat.

Jika implementasi perangkat telah diluncurkan tanpa mendukung Booting Terverifikasi pada versi Android yang lebih lama dan tidak dapat menambahkan dukungan untuk fitur ini dengan update software sistem, implementasi tersebut DAPAT dikecualikan dari persyaratan.

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

• [C-1-1] HARUS mendeklarasikan tombol 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 root kepercayaan, dan berlanjut hingga ke partisi sistem.
• [C-1-4] HARUS menerapkan setiap tahap verifikasi untuk memeriksa integritas dan keaslian semua byte di tahap berikutnya sebelum mengeksekusi kode di tahap berikutnya.
• [C-1-5] HARUS menggunakan algoritma verifikasi yang sekuat rekomendasi saat ini dari NIST untuk algoritma hashing (SHA-256) dan ukuran kunci publik (RSA-2048).
• [C-1-6] TIDAK BOLEH memungkinkan booting selesai jika verifikasi sistem gagal, kecuali jika pengguna setuju untuk mencoba melakukan booting, dalam hal ini data dari blok penyimpanan yang tidak terverifikasi TIDAK BOLEH digunakan.
• [C-1-7] TIDAK BOLEH mengizinkan partisi terverifikasi pada perangkat untuk dimodifikasi kecuali jika pengguna telah membuka kunci bootloader secara eksplisit.
• [C-SR-1] Jika ada beberapa chip terpisah dalam perangkat (mis. radio, prosesor gambar khusus), proses booting setiap chip tersebut SANGAT DIREKOMENDASIKAN untuk memverifikasi setiap tahap saat booting.
• [C-1-8] HARUS menggunakan penyimpanan yang tahan perusakan: untuk menyimpan apakah bootloader tidak terkunci. Dengan penyimpanan yang tahan perusakan, bootloader dapat mendeteksi jika penyimpanan telah dimodifikasi dari dalam Android.
• [C-1-9] HARUS meminta pengguna, selagi menggunakan perangkat, dan memerlukan konfirmasi fisik sebelum mengizinkan transisi dari mode terkunci bootloader ke mode tidak terkunci bootloader.
• [C-1-10] HARUS mengimplementasikan perlindungan rollback untuk partisi yang digunakan oleh Android (misalnya, booting, partisi sistem) dan menggunakan penyimpanan yang tahan perusakan untuk menyimpan metadata yang digunakan untuk menentukan versi OS minimum yang diizinkan.
• [C-1-11] HARUS menghapus semua data pengguna dengan aman selama membuka kunci dan mengunci bootloader, sesuai dengan '9.12. Penghapusan Data' (termasuk partisi data pengguna dan ruang NVRAM apa pun).
• [C-SR-2] SANGAT DIREKOMENDASIKAN untuk memverifikasi semua file APK aplikasi dengan hak istimewa dengan rantai kepercayaan yang di-root di partisi yang dilindungi oleh Booting Terverifikasi.
• [C-SR-3] SANGAT DIREKOMENDASIKAN untuk memverifikasi artefak yang dapat dieksekusi yang dimuat oleh aplikasi dengan hak istimewa dari luar file APK-nya (seperti kode yang dimuat secara dinamis atau kode yang dikompilasi) sebelum mengeksekusinya atau SANGAT DIREKOMENDASIKAN untuk tidak mengeksekusinya sama sekali.
• HARUS menerapkan perlindungan rollback untuk komponen apa pun dengan firmware persisten (mis. modem, kamera) dan SEHARUSNYA menggunakan penyimpanan yang tahan perusakan untuk menyimpan metadata yang digunakan dalam menentukan versi minimum yang diizinkan.

Jika implementasi perangkat sudah diluncurkan tanpa mendukung C-1-8 hingga C-1-11 pada versi Android yang lebih lama dan tidak dapat menambahkan dukungan untuk persyaratan ini dengan update software sistem, implementasi tersebut DAPAT dikecualikan dari persyaratan ini.

Project Open Source Android upstream menyediakan implementasi yang lebih disukai dari fitur ini di repositori external/avb/, yang dapat diintegrasikan ke bootloader yang digunakan untuk memuat Android.

Penerapan perangkat

Jika implementasi perangkat memiliki kemampuan untuk memverifikasi konten file berbasis per halaman, implementasi tersebut:

• [C-0-3 C-2-1] mendukung verifikasi konten file secara kriptografis terhadap kunci tepercaya tanpa membaca seluruh file.

• [C-0-4 C-2-2] TIDAK BOLEH mengizinkan permintaan baca pada file yang dilindungi berhasil jika konten yang dibaca tidak diverifikasi terhadap kunci tepercaya tidak diverifikasi per [C-2-1] di atas.

Jika implementasi perangkat sudah diluncurkan tanpa kemampuan untuk memverifikasi konten file terhadap kunci tepercaya pada versi Android sebelumnya dan tidak dapat menambahkan dukungan fitur ini dengan update software sistem, implementasi tersebut DAPAT dikecualikan dari persyaratan tersebut. Project Open Source Android upstream menyediakan implementasi fitur yang lebih disukai berdasarkan fitur fs-verity kernel Linux.

Implementasi perangkat:

• [C-SR-4] SANGAT DIREKOMENDASIKAN untuk mendukung Android Protected Confirmation API.

Jika implementasi perangkat mendukung Protected Confirmation API Android, implementasi tersebut:

• [C-3-1] HARUS melaporkan true untuk ConfirmationPrompt.isSupported() API.

• [C-3-2] HARUS memastikan bahwa kode yang berjalan di Android OS termasuk kernel-nya, berbahaya atau sebaliknya, tidak dapat menghasilkan respons positif tanpa interaksi pengguna.

• [C-3-3] HARUS memastikan bahwa pengguna dapat meninjau dan menyetujui pesan yang diminta, meskipun Android OS, termasuk kernelnya, disusupi.

9.11. Kunci dan Kredensial

Android Keystore System memungkinkan developer aplikasi menyimpan kunci kriptografis dalam penampung dan menggunakannya dalam operasi kriptografi melalui KeyChain API atau Keystore API. Implementasi perangkat:

• [C-0-1] HARUS mengizinkan setidaknya 8.192 kunci untuk diimpor atau dihasilkan.
• [C-0-2] Autentikasi layar kunci HARUS mengimplementasikan interval waktu antar-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 minimal HARUS 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, implementasi tersebut:

• [C-1-1] HARUS mencadangkan implementasi keystore dengan lingkungan eksekusi yang terisolasi.
• [C-1-2] HARUS memiliki implementasi algoritma kriptografis RSA, AES, ECDSA, ECDH (jika IKeyMintDevice didukung), 3DES, dan HMAC, serta fungsi hash kelompok MD5, SHA1, 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 mekanisme potensial yang digunakan kode kernel atau userspace untuk mengakses status internal lingkungan yang terisolasi, termasuk DMA. Proyek Open Source Android (AOSP) upstream memenuhi persyaratan ini dengan menggunakan implementasi Trusty, tetapi solusi berbasis ARM TrustZone lain atau implementasi aman yang ditinjau oleh pihak ketiga dari isolasi berbasis hypervisor yang tepat merupakan opsi alternatif.
• [C-1-3] HARUS melakukan autentikasi layar kunci di lingkungan eksekusi yang terisolasi dan hanya jika berhasil, izinkan kunci yang terikat autentikasi untuk digunakan. Kredensial layar kunci HARUS disimpan dengan cara yang hanya memungkinkan lingkungan eksekusi yang terisolasi untuk melakukan autentikasi layar kunci. Project Open Source Android upstream menyediakan Gatekeeper Hardware Abstraksi Layer (HAL) 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 dalam hardware yang aman. Kunci penandatanganan pengesahan HARUS dibagikan ke seluruh perangkat dalam jumlah yang cukup besar untuk mencegah kunci digunakan sebagai ID perangkat. Salah satu cara memenuhi persyaratan ini adalah dengan berbagi kunci pengesahan yang sama kecuali jika setidaknya 100.000 unit SKU tertentu dihasilkan. Jika lebih dari 100.000 unit SKU dihasilkan, kunci yang berbeda MUNGKIN digunakan untuk setiap 100.000 unit.

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

• [C-1-5] HARUS mengizinkan pengguna memilih Waktu tunggu tidur untuk transisi dari status tidak terkunci ke terkunci, dengan waktu tunggu minimum yang diizinkan hingga 15 detik. Perangkat Automotive, yang mengunci layar setiap kali head unit dinonaktifkan atau pengguna dialihkan, MUNGKIN TIDAK memiliki konfigurasi Waktu tunggu tidur.
• [C-1-6] HARUS mendukung IKeymasterDevice 4.0, IKeymasterDevice 4.1, IKeyMintDevice versi 1, atau IKeyMintDevice versi 2.
• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung IKeyMintDevice versi 1.

9.11.1. Layar Kunci Aman, Autentikasi, dan Perangkat Virtual

Implementasi AOSP mengikuti model autentikasi bertingkat dengan autentikasi utama berbasis pengetahuan yang dapat didukung oleh biometrik yang kuat sekunder, atau dengan modalitas tersier yang lebih lemah.

Implementasi perangkat:

• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menetapkan hanya salah satu hal berikut sebagai metode autentikasi utama:

  • PIN numerik
  • {i>Password<i} alfanumerik

  • Pola geser pada petak yang berisi titik 3 x 3

    Perhatikan bahwa metode autentikasi di atas disebut sebagai metode autentikasi utama yang direkomendasikan dalam dokumen ini.

Jika implementasi perangkat menambahkan atau mengubah metode autentikasi utama yang direkomendasikan dan menggunakan metode autentikasi baru sebagai cara yang aman untuk mengunci layar, metode autentikasi baru tersebut:

• [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 panjang input terpendek yang diizinkan HARUS lebih besar dari 10 bit.
• [C-3-2] Entropi maksimum dari semua input yang memungkinkan HARUS lebih besar dari 18 bit.
• [C-3-3] Metode autentikasi yang baru TIDAK BOLEH menggantikan metode autentikasi utama apa pun yang direkomendasikan (yaitu PIN, pola, sandi) yang diimplementasikan dan disediakan dalam AOSP.
• [C-3-4] Metode autentikasi yang baru HARUS dinonaktifkan jika aplikasi Pengontrol Kebijakan Perangkat (DPC) telah menetapkan kebijakan persyaratan sandi melalui DeviceDependencies.setRequiredPasswordComplexity() dengan konstanta kompleksitas yang lebih ketat daripada PASSWORD_COMPLExitY_NONE atau melalui metode DeviceSettings.setPasswordKualitas() dengan konstanta yang lebih ketat daripada METRIC_METRIC_quality_B.
• [C-3-5] Metode autentikasi baru HARUS kembali ke metode autentikasi utama yang direkomendasikan (yaitu PIN, pola, sandi) setiap 72 jam atau kurang ATAU dengan jelas mengungkapkan kepada pengguna bahwa sebagian data tidak akan dicadangkan untuk menjaga privasi datanya.

Jika implementasi perangkat menambahkan atau mengubah metode autentikasi utama yang direkomendasikan untuk membuka kunci layar kunci dan menggunakan metode autentikasi baru yang berdasarkan biometrik untuk diperlakukan sebagai cara yang aman untuk mengunci layar, metode baru ini:

• [C-4-1] HARUS memenuhi semua persyaratan yang dijelaskan di pasal 7.3.10 untuk Kelas 1 (sebelumnya Kemudahan).
• [C-4-2] HARUS memiliki mekanisme fallback untuk menggunakan salah satu metode autentikasi utama yang direkomendasikan berdasarkan 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 flag 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 Strong) seperti yang dijelaskan di bagian 7.3.10:

• [C-5-1] Metode HARUS dinonaktifkan jika aplikasi Pengontrol Kebijakan Perangkat (DPC) telah menetapkan kebijakan kualitas persyaratan sandi melalui DeviceDependencies.setRequiredPasswordComplexity() dengan bucket kompleksitas yang lebih ketat daripada PASSWORD_COMPLEXITY_LOW atau menggunakan metode DeviceSettings.setPasswordquality() dengan konstanta kualitas yang lebih ketat daripada PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-5-2] Pengguna HARUS ditantang untuk autentikasi utama yang direkomendasikan (misalnya: PIN, pola, sandi) seperti yang dijelaskan dalam [C-1-7] dan [C-1-8] di bagian 7.3.10.
• [C-5-3] Metode TIDAK BOLEH diperlakukan sebagai layar kunci yang aman, dan HARUS memenuhi persyaratan yang dimulai dengan C-8 di bagian ini di bawah.

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] Metode ini HARUS memiliki mekanisme fallback 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 menyetel kebijakan dengan:
  • 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 ditantang untuk salah satu metode autentikasi utama yang direkomendasikan (misalnya PIN, pola, sandi) setidaknya sekali setiap 4 jam atau kurang. Jika token fisik memenuhi persyaratan implementasi 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 di C-8 di bawah.

Jika implementasi perangkat memiliki layar kunci yang aman dan menyertakan satu atau beberapa agen tepercaya, yang mengimplementasikan TrustAgentService System API, implementasi tersebut:

• [C-7-1] HARUS memiliki indikasi yang jelas di menu setelan dan di layar kunci saat penguncian perangkat ditunda atau dapat dibuka oleh agen tepercaya. Misalnya, AOSP memenuhi persyaratan ini dengan menampilkan deskripsi teks untuk "Setelan kunci otomatis" dan "Tombol daya akan langsung terkunci" di menu setelan dan ikon yang dapat dibedakan di layar kunci.
• [C-7-2] HARUS mematuhi dan sepenuhnya menerapkan semua API agen kepercayaan dalam class DevicePolicyManager, seperti konstanta KEYGUARD_DISABLE_TRUST_AGENTS.
• [C-7-3] TIDAK BOLEH mengimplementasikan fungsi TrustAgentService.addEscrowToken() sepenuhnya pada perangkat yang digunakan sebagai perangkat pribadi utama (misalnya, perangkat genggam), tetapi MUNGKIN menerapkan fungsi tersebut sepenuhnya pada implementasi perangkat yang biasanya digunakan bersama (misalnya, Android Television atau perangkat Automotive).
• [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 tempat kunci tersebut digunakan. Misalnya, kunci yang disimpan di ponsel diizinkan untuk membuka kunci akun pengguna di TV. Untuk perangkat Automotive, token escrow tidak diizinkan untuk disimpan di bagian mana pun dari 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 fallback untuk menggunakan salah satu metode autentikasi utama yang direkomendasikan.
• [C-7-8] Pengguna HARUS ditantang untuk salah satu metode autentikasi utama yang direkomendasikan (misalnya, PIN, pola, sandi) setidaknya sekali setiap 72 jam atau kurang, kecuali jika keselamatan pengguna (misalnya gangguan pengemudi) menjadi perhatian.
• [C-7-9] Pengguna HARUS ditantang untuk salah satu metode autentikasi utama yang direkomendasikan (misalnya: PIN, pola, sandi) seperti yang 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 TrustAgents di perangkat pribadi utama (misalnya, genggam) untuk membuka kunci perangkat, dan hanya dapat menggunakannya untuk menyimpan perangkat yang sudah tidak terkunci dalam keadaan tidak terkunci hingga maksimum 4 jam. Implementasi 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 jika 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 disetel oleh DevicePolicyManager.setPasswordExpirationTimeout().
• [C-8-3] Modul ini TIDAK BOLEH mengekspos API untuk digunakan oleh aplikasi pihak ketiga guna menentukan status kunci.

Jika implementasi perangkat memungkinkan aplikasi membuat tampilan virtual sekunder dan tidak mendukung peristiwa input terkait, seperti melalui VirtualDeviceManager, aplikasi tersebut:

• [C-9-1] HARUS mengunci tampilan virtual sekunder ini saat layar default perangkat terkunci, dan membuka kunci layar virtual sekunder ini saat layar default perangkat tidak terkunci.

Jika penerapan perangkat mengizinkan aplikasi membuat tampilan virtual sekunder dan mendukung peristiwa input terkait, seperti melalui VirtualDeviceManager, penerapan tersebut:

• [C-10-1] HARUS mendukung status kunci terpisah per perangkat virtual
• [C-10-2] HARUS memutuskan sambungan semua perangkat virtual saat waktu tunggu tidak ada aktivitas
• [C-10-3] HARUS memiliki waktu tunggu tidak ada aktivitas
• [C-10-4] HARUS mengunci semua layar saat pengguna memulai penguncian total, termasuk melalui kemampuan pengguna kunci total 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 pembuatan peristiwa input terkait melalui VirtualDeviceManager jika ditunjukkan oleh DevicePolicyManager.setNearbyAppStreamingPolicy
• [C-10-7] HARUS menggunakan papan klip terpisah semata-mata untuk setiap perangkat virtual (atau menonaktifkan papan klip untuk perangkat virtual)
• [C-10-11] HARUS menonaktifkan UI autentikasi di perangkat virtual, termasuk entri faktor pengetahuan dan perintah biometrik
• [C-10-12] HARUS membatasi intent yang dimulai dari perangkat virtual untuk hanya menampilkan di perangkat virtual yang sama
• [C-10-13] TIDAK BOLEH menggunakan status penguncian perangkat virtual sebagai otorisasi autentikasi pengguna dengan Sistem Android Keystore. Lihat KeyGenParameterSpec.Builder.setUserAuthentication*.

Jika implementasi perangkat memungkinkan pengguna mentransfer faktor pengetahuan autentikasi utama dari perangkat sumber ke perangkat target, seperti untuk penyiapan awal perangkat target, perangkat tersebut:

• [C-11-1] HARUS mengenkripsi faktor pengetahuan dengan jaminan perlindungan seperti yang dijelaskan dalam laporan resmi keamanan Google Cloud Key Vault Service saat mentransfer faktor pengetahuan dari perangkat sumber ke perangkat target sehingga faktor pengetahuan tidak dapat didekripsi dari jarak jauh atau digunakan untuk membuka kunci perangkat dari jarak jauh.
• [C-11-2] HARUS, pada perangkat sumber , minta pengguna untuk mengonfirmasi faktor pengetahuan perangkat sumber sebelum mentransfer faktor pengetahuan ke perangkat target.
• [C-11-3] HARUS, pada perangkat target yang tidak memiliki faktor pengetahuan autentikasi utama yang telah ditetapkan, minta 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 apa pun 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, artinya:

• [C-12-1] HARUS memanggil grantTrust() dengan flag tersebut saat terhubung ke perangkat fisik terdekat yang memiliki layar kunci sendiri, dan saat pengguna mengautentikasi identitasnya di layar kunci tersebut. Perangkat didekatkan dapat menggunakan mekanisme deteksi di pergelangan tangan atau pada tubuh setelah kunci pengguna satu kali dibuka untuk memenuhi persyaratan autentikasi pengguna.
• [C-12-2] HARUS menempatkan implementasi perangkat ke dalam status TrustState.TRUSTABLE saat layar dinonaktifkan (seperti melalui penekanan tombol atau waktu tunggu tampilan) 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 di C-12-1.
• [C-12-4] HARUS memanggil TrustManagerService.revokeTrust() setelah maksimal 24 jam sejak memberikan kepercayaan, periode tidak ada aktivitas selama 8 jam, atau saat koneksi yang mendasarinya ke perangkat fisik proksim hilang.

Jika implementasi perangkat mengizinkan aplikasi membuat tampilan virtual sekunder dan mendukung peristiwa input terkait seperti melalui VirtualDeviceManager dan layar tidak ditandai dengan VIRTUAL_DISPLAY_FLAG_SECURE, peristiwa tersebut:

• [C-13-8] HARUS memblokir activity dengan atribut android:canDisplayOnRemoteDevices atau meta-data android.activity.can_display_on_remote_devices yang disetel ke false agar tidak dimulai di perangkat virtual.
• [C-13-9] HARUS memblokir aktivitas yang tidak secara eksplisit mengaktifkan streaming dan yang menunjukkannya menampilkan konten sensitif, termasuk melalui SurfaceView#setSecure, FLAG_SECURE, atau SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS, agar tidak dimulai di perangkat virtual.
• [C-13-10] HARUS menonaktifkan penginstalan aplikasi yang dimulai dari perangkat virtual.

Jika implementasi perangkat mendukung status daya tampilan terpisah melalui DeviceStateManager DAN mendukung status kunci layar terpisah melalui KeyguardDisplayManager, implementasi tersebut:

• [C-SR-2] SANGAT DIREKOMENDASIKAN untuk memanfaatkan persyaratan rapat kredensial yang ditentukan dalam pasal 9.11.1 atau Rapat Biometrik setidaknya spesifikasi Kelas 1 yang ditentukan dalam pasal 7.3.10 untuk memungkinkan pembukaan kunci independen dari layar perangkat default.
• [C-SR-3] SANGAT DIREKOMENDASIKAN untuk membatasi buka kunci layar terpisah melalui waktu tunggu tampilan yang ditentukan.
• [C-SR-4] SANGAT DIREKOMENDASIKAN untuk memungkinkan pengguna mengunci semua layar secara global melalui kunci total dari perangkat genggam utama.

9.11.2. StrongBox

Android Keystore System memungkinkan developer aplikasi untuk menyimpan kunci kriptografis dalam pemroses khusus yang aman serta lingkungan eksekusi terisolasi yang dijelaskan di atas. Prosesor aman khusus tersebut 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, implementasi tersebut:

• [C-1-1] HARUS mendeklarasikan FEATURE_STRONGBOX_KEYSTORE.

• [C-1-2] HARUS menyediakan hardware aman khusus yang digunakan untuk mendukung keystore dan mengamankan autentikasi pengguna. Hardware khusus yang aman juga dapat digunakan untuk tujuan lain.

• [C-1-3] HARUS memiliki CPU terpisah yang tidak membagikan cache, DRAM, koprosesor, atau resource inti lainnya dengan pemroses aplikasi (AP).

• [C-1-4] HARUS memastikan bahwa setiap periferal 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 jam internal dengan akurasi yang wajar (+-10%) yang kebal terhadap manipulasi oleh AP.

• [C-1-6] HARUS memiliki generator angka acak sesungguhnya yang menghasilkan output yang terdistribusi secara seragam dan tidak dapat diprediksi.

• [C-1-7] HARUS memiliki ketahanan terhadap modifikasi tidak sah, termasuk ketahanan terhadap penetrasi fisik dan glitching.

• [C-1-8] HARUS memiliki ketahanan saluran samping, termasuk ketahanan terhadap kebocoran informasi melalui daya, pengaturan waktu, radiasi elektromagnetik, dan saluran samping 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 jika diizinkan oleh StrongBox API.

• Untuk memvalidasi kepatuhan terhadap [C-1-3] hingga [C-1-9], implementasi perangkat:

  • [C-1-10] HARUS menyertakan hardware yang disertifikasi berdasarkan Secure IC Protection Profile BSI-CC-PP-0084-2014 atau dievaluasi oleh laboratorium pengujian terakreditasi secara nasional yang menggabungkan penilaian potensi kerentanan serangan tinggi sesuai dengan Common Criteria Application of Attack Potential to Smartcard.
  • [C-1-11] HARUS menyertakan firmware yang dievaluasi oleh laboratorium pengujian yang terakreditasi secara nasional, yang menggabungkan penilaian kerentanan potensi serangan Tinggi sesuai dengan Common Criteria Application of Attack Potential to Smartcard.
  • [C-SR-2] SANGAT DIREKOMENDASIKAN untuk menyertakan hardware yang dievaluasi menggunakan Target Keamanan, Evaluation Assurance Level (EAL) 5, yang ditingkatkan dengan AVA_VAN.5. Sertifikasi EAL 5 kemungkinan akan menjadi persyaratan dalam rilis mendatang.
  • [C-SR-3] SANGAT DIREKOMENDASIKAN untuk memberikan ketahanan terhadap serangan orang dalam (IAR), yang berarti orang dalam yang memiliki akses ke kunci penandatanganan firmware tidak dapat menghasilkan firmware yang menyebabkan StrongBox membocorkan rahasia, untuk mengabaikan persyaratan keamanan fungsional, atau mengaktifkan akses ke data pengguna yang sensitif. Cara yang direkomendasikan untuk menerapkan IAR adalah mengizinkan update firmware hanya jika sandi pengguna utama diberikan melalui HAL IAuthSecret.

9.11.3. Kredensial Identitas

Sistem Kredensial Identitas ditentukan dan dicapai dengan mengimplementasikan semua API dalam paket android.security.identity.*. API ini memungkinkan developer aplikasi menyimpan dan mengambil dokumen identitas pengguna. Implementasi perangkat:

• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan Sistem Kredensial Identitas.

Jika implementasi perangkat menerapkan Identity Credential System, implementasi tersebut:

• [C-1-1] HARUS menampilkan non-null untuk metode IdentityCredentialStore#getInstance().

• [C-1-2] HARUS mengimplementasikan Sistem Kredensial Identitas (misalnya, android.security.identity.* API) dengan kode yang berkomunikasi dengan aplikasi tepercaya di area yang diisolasi secara aman dari kode yang berjalan pada kernel dan di atasnya. Isolasi aman HARUS memblokir semua mekanisme potensial yang digunakan kode kernel atau userspace untuk mengakses status internal lingkungan yang terisolasi, termasuk DMA.

• [C-1-3] Operasi kriptografi yang diperlukan untuk mengimplementasikan Sistem Kredensial Identitas (misalnya, API android.security.identity.*) HARUS dijalankan sepenuhnya di aplikasi tepercaya dan materi kunci pribadi TIDAK BOLEH keluar dari lingkungan eksekusi yang terisolasi kecuali jika secara khusus diperlukan oleh API dengan 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 kondisi kontrol akses terpenuhi, MAC tidak dapat dihasilkan untuk data arbitrer) meskipun Android berperilaku tidak semestinya atau disusupi.

Project Open Source Android upstream menyediakan implementasi referensi aplikasi tepercaya (libeic) yang dapat digunakan untuk mengimplementasikan sistem Identity Credential.

9.12. Penghapusan Data

Semua implementasi perangkat:

• [C-0-1] HARUS menyediakan mekanisme kepada pengguna untuk melakukan "Reset ke Setelan Pabrik".
• [C-0-2] HARUS menghapus semua data pada sistem file userdata saat melakukan "Reset ke Setelan Pabrik".
• [C-0-3] HARUS menghapus data dengan cara sedemikian rupa sehingga akan memenuhi standar industri yang relevan, seperti NIST SP800-88 saat melakukan "Reset ke Setelan Pabrik".
• [C-0-4] HARUS memicu proses "Reset ke Setelan Pabrik" di atas saat DevicePolicyManager.wipeData() API dipanggil oleh aplikasi Pengontrol Kebijakan Perangkat pengguna utama.
• MUNGKIN menyediakan opsi penghapusan total data cepat yang hanya melakukan penghapusan data logis.

9.13. Mode Booting Aman

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

Implementasi perangkat adalah:

• [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menerapkan Mode Booting Aman.

Jika implementasi perangkat menerapkan Mode Booting Aman, implementasi tersebut:

• [C-1-1] HARUS memberikan opsi kepada pengguna untuk memasuki Mode Booting Aman dengan cara yang tidak terganggu dari aplikasi pihak ketiga yang diinstal di perangkat, kecuali jika aplikasi pihak ketiga adalah Pengontrol Kebijakan Perangkat dan telah menyetel tanda UserManager.DISALLOW_SAFE_BOOT sebagai true.

• [C-1-2] HARUS memberi pengguna kemampuan untuk meng-uninstal aplikasi pihak ketiga dalam Mode Aman.

• HARUS menyediakan opsi kepada pengguna untuk masuk ke 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" adalah detail paket hubungan penagihan yang disediakan oleh operator seluler melalui SubscriptionManager.setSubscriptionPlans().

Semua implementasi perangkat:

• [C-0-1] HARUS mengembalikan paket langganan hanya ke aplikasi operator seluler yang sudah 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 perangkat ke perangkat lain dan tidak membatasi data aplikasi yang disalin ke yang dikonfigurasi oleh developer aplikasi dalam manifes melalui atribut android:fullBackupContent, hal tersebut:

• [C-1-1] TIDAK BOLEH memulai transfer data aplikasi dari perangkat yang belum ditetapkan autentikasi utama pengguna seperti yang dijelaskan dalam 9.11.1 Secure Lock Screen dan Authentication.
• [C-1-2] HARUS mengonfirmasi autentikasi utama dengan aman pada perangkat sumber dan mengonfirmasi dengan intent pengguna untuk menyalin data di perangkat sumber sebelum data apa pun ditransfer.
• [C-1-3] HARUS menggunakan pengesahan kunci keamanan untuk memastikan bahwa perangkat sumber dan perangkat target dalam migrasi antar-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 melalui migrasi data antarperangkat dalam menu setelan. Pengguna SEHARUSNYA TIDAK dapat menghapus indikasi ini.

9.17. Framework Virtualisasi Android

Jika perangkat mengimplementasikan dukungan untuk Android Virtualization Framework API (android.system.virtualmachine.*), host Android:

• [C-1-1] HARUS mendukung semua API yang ditentukan oleh paket android.system.virtualmachine.
• [C-1-2] TIDAK BOLEH mengubah Android SELinux dan model izin untuk pengelolaan Protected Virtual Machines (pVM).

• [C-1-4] HARUS hanya mengizinkan kode yang ditandatangani platform & aplikasi dengan hak istimewaTIDAK BOLEH mengizinkan kode yang tidak tepercaya (misalnya aplikasi 3p) untuk membuat dan menjalankan pVM Protected Virtual Machine . Catatan: Hal ini mungkin berubah dalam rilis Android mendatang.

Jika perangkat menerapkan dukungan untuk Android Virtualization Framework API (android.system.virtualmachine.*), setiap instance Protected Virtual Machine pVM apa pun:

• [C-2-1] HARUS dapat menjalankan semua sistem operasi yang tersedia di APEX virtualisasi dalam Protected Virtual Machine pVM .
• [C-2-2] TIDAK BOLEH mengizinkan Mesin Virtual yang Dilindungi pVM menjalankan sistem operasi yang tidak ditandatangani oleh pengimplementasi perangkat atau vendor OS.
• [C-2-3] TIDAK BOLEH mengizinkan Mesin Virtual yang Dilindungi pVM untuk mengeksekusi data sebagai kode (mis. SELinux tidak pernah mengizinkan execm).

• [C-2-5] HARUS mengimplementasikan mekanisme pertahanan mendalam Protected Virtual Machine pVM (misalnya, SELinux untuk pVM), bahkan untuk sistem operasi non-Microdroid.
• [C-2-6] HARUS memastikan bahwa pVM gagal firmware menolak untuk melakukan booting jika firmware menolak image awal tidak dapat memverifikasi yang akan dijalankan, tidak dapat diverifikasi. Verifikasi HARUS dilakukan di dalam VM.
• [C-2-7] HARUS memastikan bahwa pVM gagal firmware menolak untuk melakukan booting jika integritas instance.img disusupi.

Jika perangkat mengimplementasikan dukungan untuk Android Virtualization Framework API (android.system.virtualmachine.*), hypervisor:

• [C-3-1] HARUS memastikan bahwa halaman memori yang dimiliki secara eksklusif oleh VM (baik pVM maupun host VM) hanya dapat diakses oleh virtual machine itu sendiri atau hypervisor, bukan oleh virtual machine lain, baik yang dilindungi maupun tidak. TIDAK BOLEH mengizinkan pVM apa pun mengakses halaman yang menjadi milik entitas lain (yaitu pVM atau hypervisor lain), kecuali jika dibagikan secara eksplisit oleh pemilik halaman. Ini termasuk VM host. Hal ini berlaku untuk akses CPU dan DMA.
• [C-3-2] HARUS menghapus total halaman setelah digunakan oleh pVM dan sebelum halaman tersebut ditampilkan ke host (misalnya, PVM dihancurkan).
• [C-3-3SR-1] SANGAT DIREKOMENDASIKAN untuk memastikan HARUS memastikan bahwa firmware pVM dimuat dan dieksekusi sebelum kode apa pun di pVM.
• [C-3-4] HARUS memastikan bahwa setiap VM menghasilkan secret per VM yang {Boot Certificate Chain (BCC) dan Compound Device Identifier (CDI) yang diberikan ke instance pVM hanya dapat diperoleh oleh instance VM tersebut dan berubah saat reset ke setelan pabrik dan OTA.

Jika perangkat mengimplementasikan dukungan untuk Android Virtualization Framework API, di semua area:

• [C-4-1] TIDAK BOLEH menyediakan fungsi ke pVM yang memungkinkan pengabaian Model Keamanan Android.

Jika perangkat mengimplementasikan dukungan untuk Android Virtualization Framework API, maka:

• [C-5-1] HARUS mampu mendukung Kompilasi Terisolasi tetapi dapat menonaktifkan fitur Kompilasi Terisolasi pada pengiriman perangkat update runtime ART.

Jika perangkat mengimplementasikan dukungan untuk Android Virtualization Framework API, maka untuk Key Management:

• [C-SR-26-2] SANGAT DIREKOMENDASIKAN untuk menggunakan DICE sebagai mekanisme turunan rahasia per VM. HARUS DICE dengan benar, yaitu memberikan nilai yang benar.

10. Pengujian Kompatibilitas Software

Implementasi perangkat HARUS lulus semua pengujian yang dijelaskan di bagian ini. Namun, perhatikan bahwa tidak ada paket pengujian perangkat lunak yang sepenuhnya komprehensif. Karena alasan ini, pengimplementasi perangkat DIREKOMENDASIKAN untuk membuat sejumlah minimum mungkin perubahan pada referensi dan implementasi pilihan Android yang tersedia dari Proyek Open Source Android. Hal ini akan meminimalkan risiko timbulnya bug yang menimbulkan inkompatibilitas yang memerlukan pengerjaan ulang dan potensi update perangkat.

10.1. Compatibility Test Suite (CTS)

Implementasi perangkat:

• [C-0-1] HARUS lulus Compatibility Test Suite (CTS) Android yang tersedia dari Project Open Source Android, menggunakan software pengiriman final di perangkat.

• [C-0-2] HARUS memastikan kompatibilitas jika terjadi ambiguitas dalam CTS dan untuk setiap implementasi ulang bagian-bagian kode sumber referensi.

CTS dirancang untuk dijalankan pada perangkat yang sebenarnya. Seperti perangkat lunak lainnya, CTS mungkin memiliki bug. CTS akan dibuat versi terpisah dari Definisi Kompatibilitas ini, dan beberapa revisi CTS dapat dirilis untuk Android 14.

Implementasi perangkat:

• [C-0-3] HARUS lulus versi CTS terbaru yang tersedia pada saat software perangkat diselesaikan.

• HARUS menggunakan penerapan referensi di hierarki Open Source Android sebanyak mungkin.

10.2. Pemverifikasi CTS

CTS Verifier disertakan dengan Compatibility Test Suite, dan ditujukan untuk dijalankan oleh operator manusia guna menguji fungsi yang tidak dapat diuji oleh sistem otomatis, seperti fungsi kamera dan sensor yang benar.

Implementasi perangkat:

• [C-0-1] HARUS mengeksekusi dengan benar semua kasus yang berlaku di pemverifikasi CTS.

CTS Verifier memiliki pengujian untuk berbagai jenis hardware, termasuk beberapa hardware yang bersifat opsional.

Implementasi perangkat:

• [C-0-2] HARUS lulus semua pengujian hardware yang dimilikinya; misalnya, jika perangkat memiliki akselerometer, perangkat HARUS menjalankan kasus pengujian Akselerometer dengan benar di CTS Verifier.

Kasus pengujian untuk fitur yang dianggap opsional oleh Dokumen Definisi Kompatibilitas ini MUNGKIN 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 sangat mirip, pengimplementasi perangkat tidak diharapkan untuk secara eksplisit menjalankan CTS Verifier pada build yang hanya berbeda dalam hal sederhana. Secara khusus, implementasi perangkat yang berbeda dari implementasi yang telah lulus CTS Verifier hanya dengan kumpulan lokalitas, branding, dll. yang disertakan. MUNGKIN menghilangkan uji CTS Verifier.

11. Software yang Dapat Diperbarui

• [C-0-1] Implementasi perangkat HARUS menyertakan mekanisme untuk menggantikan seluruh software sistem. Mekanismenya tidak perlu melakukan upgrade "live"—artinya, perangkat dimulai ulang MUNGKIN diperlukan. Metode apa pun dapat digunakan, asalkan dapat menggantikan keseluruhan software yang telah diinstal sebelumnya pada perangkat. Misalnya, salah satu pendekatan berikut akan memenuhi persyaratan ini:

  • Download "Over-the-air (OTA)" dengan update offline melalui reboot.
  • Pembaruan "Tethered" melalui USB dari PC host.
  • Pembaruan "Offline" melalui mulai ulang dan pembaruan dari file pada penyimpanan yang dapat dicopot.

• [C-0-2] Mekanisme update yang digunakan HARUS mendukung update tanpa menghapus total data pengguna. Artinya, mekanisme update HARUS mempertahankan data pribadi aplikasi dan data bersama aplikasi. Perlu diperhatikan bahwa software Android upstream menyertakan 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 DIREKOMENDASIKAN untuk melakukan hashing update dengan SHA-256 dan memvalidasi hash tersebut dengan kunci publik menggunakan ECDSA NIST P-256.

Jika implementasi perangkat menyertakan dukungan untuk koneksi data tidak berbayar seperti profil 802.11 atau Bluetooth PAN (Personal Area Network), maka implementasi tersebut:

• [C-1-1] HARUS mendukung download OTA dengan update offline melalui reboot.

Implementasi perangkat HARUS memverifikasi bahwa image sistem memiliki biner yang identik dengan hasil yang diharapkan setelah OTA. Implementasi OTA berbasis blok di Project Open Source Android upstream, yang ditambahkan sejak Android 5.1, memenuhi persyaratan ini.

Selain itu, penerapan perangkat SEHARUSNYA mendukung update sistem A/B. AOSP mengimplementasikan fitur ini menggunakan HAL kontrol booting.

Jika ditemukan error dalam implementasi perangkat setelah dirilis, tetapi dalam masa aktif produk yang wajar yang ditentukan melalui konsultasi dengan Tim Kompatibilitas Android untuk memengaruhi kompatibilitas aplikasi pihak ketiga, maka:

• [C-2-1] Implementasi perangkat HARUS memperbaiki error melalui update software yang dapat diterapkan sesuai mekanisme yang baru saja dijelaskan.

Android menyertakan fitur yang memungkinkan aplikasi Pemilik Perangkat (jika ada) untuk mengontrol penginstalan update sistem. Jika subsistem update sistem untuk perangkat melaporkan android.software.device_admin, perangkat tersebut:

• [C-3-1] HARUS menerapkan perilaku yang dijelaskan dalam class SystemUpdatePolicy.

12. Log Perubahan Dokumen

Untuk ringkasan perubahan pada Compatibility Definition dalam rilis ini:

• Log perubahan dokumen

13. Hubungi Kami

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