Log perubahan Dokumen Definisi Kompatibilitas Android

Android 14

26 Juni 2024

2. Jenis Perangkat

  • 2.2.1 Hardware:

    Lihat revisi

    • [7.6.1/H-1-1] hanya boleh mendukung ABI tunggal (baik khusus 64-bit atau khusus 32-bit).

    Lihat revisi

    Mulai persyaratan baru

    Jika implementasi perangkat genggam menyertakan dukungan untuk Vulkan, implementasi tersebut:

  • 2.4.1 Hardware:

    Lihat revisi

    Mulai persyaratan baru

    Jika penerapan perangkat Smartwatch menyertakan dukungan untuk Vulkan, penerapan tersebut:

  • 2.5.1 Hardware:

    Lihat revisi

    Mulai persyaratan baru

    Jika penerapan perangkat Automotive menyertakan dukungan untuk Vulkan, penerapan tersebut:

3. Software

  • 3.2.2 Parameter Build:

    Untuk parameter ODM_SKU:

    Lihat revisi

    Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler ^([0-9A-Za-z.,_-]+)$.

5. Kompatibilitas Multimedia

  • 5.1.3. Detail Codec Audio:

    Menambahkan detail untuk format/codec Vorbis:

    Lihat revisi

    Decoding: Dukungan untuk konten mono, stereo, 5.0 dan 5.1 dengan frekuensi pengambilan sampel 8000, 12000, 16000, 24000, dan 48.000 Hz.
    Encoding: Dukungan untuk konten mono dan stereo dengan frekuensi pengambilan sampel 8000, 12000, 2600, 12000, 2600, 4800, 2600

7. Kompatibilitas Hardware

9. Kompatibilitas Model Keamanan

  • 9.7. Fitur Keamanan:

    [C-SR-1] diberi nomor ulang menjadi [C-SR-7] untuk menghapus konten duplikat,dan menghapus [C-SR-8]:

    Lihat revisi

    • [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mempertahankan data kernel yang hanya ditulis selama inisialisasi ditandai sebagai hanya baca setelah inisialisasi (misalnya __ro_after_init).

    • [C-SR-2] SANGAT DIREKOMENDASIKAN untuk mengacak tata letak kode kernel dan memori, serta untuk menghindari eksposur yang dapat mengganggu pengacakan (misalnya CONFIG_RANDOMIZE_BASE dengan entropi bootloader melalui /chosen/kaslr-seed Device Tree node atau EFI_RNG_PROTOCOL).

    • [C-SR-3] 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-4] 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-5] 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-6] SANGAT DIREKOMENDASIKAN untuk mengaktifkan inisialisasi stack dalam kernel untuk mencegah penggunaan variabel lokal yang tidak diinisialisasi (CONFIG_INIT_STACK_ALL atau CONFIG_INIT_STACK_ALL_ZERO). Selain itu, implementasi perangkat SEHARUSNYA TIDAK mengasumsikan nilai yang digunakan oleh compiler untuk melakukan inisialisasi lokal.

    • [C-SR-7] SANGAT DIREKOMENDASIKAN untuk mengaktifkan inisialisasi heap dalam 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.

  • 9.11. Kunci dan Kredensial:

    Lihat revisi

    • [C-1-6] HARUS mendukung salah satu dari hal berikut:
      • IKeymasterDevice 3.0,
      • IKeymasterDevice 4.0,
      • IKeymasterDevice 4.1,
      • IKeyMintDevice versi 1, atau
      • IKeyMintDevice versi 2.

  • 9.11.1. Layar Kunci Aman, Autentikasi, dan Perangkat Virtual:

    Lihat revisi

    • [C-8-3] Modul ini TIDAK BOLEH mengekspos API untuk digunakan oleh aplikasi pihak ketiga guna mengubah status kunci.

    Lihat revisi

    • [C-12-4] HARUS memanggil TrustManagerService.revokeTrust()
      • Setelah maksimum 24 jam sejak pemberian kepercayaan, atau
      • Setelah periode tidak ada aktivitas selama 8 jam, atau
      • Jika implementasinya tidak menggunakan rentang yang aman dan akurat secara kriptografis seperti yang ditetapkan dalam [C-12-5], saat koneksi yang mendasari ke perangkat fisik terdekat hilang.
    • [C-12-5] Implementasi yang mengandalkan rentang yang aman dan akurat untuk memenuhi persyaratan [C-12-4] HARUS menggunakan salah satu solusi berikut:
      • Implementasi menggunakan UWB:
        • HARUS memenuhi persyaratan kesesuaian, sertifikasi, akurasi, dan persyaratan kalibrasi untuk UWB yang dijelaskan dalam 7.4.9.
        • HARUS menggunakan salah satu mode keamanan P-STS yang tercantum di 7.4.9.
      • Implementasi menggunakan Wi-Fi Neighborhood Awareness Networking (NAN):
        • HARUS memenuhi persyaratan akurasi di 2.2.1 [7.4.2.5/H-SR-1], gunakan bandwidth 160 MHz (atau lebih tinggi), dan ikuti langkah-langkah penyiapan pengukuran yang ditentukan dalam Kalibrasi Kehadiran.
        • HARUS menggunakan Secure LTF seperti yang dijelaskan dalam IEEE 802.11az.

8 April 2024

2. Jenis Perangkat

  • 2.2.1 Hardware:

    Lihat revisi

    Mulai persyaratan baru

    Jika implementasi Perangkat genggam mendeklarasikan FEATURE_BLUETOOTH_LE, implementasi tersebut:

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

  • 2.2.5. Model Keamanan:

    Lihat revisi

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

    Lihat revisi

    Ubah [9.8/H-1-13] menjadi:

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

    Lihat revisi

    Menghapus persyaratan [9.8.2/H-4-3], [9.8.2/H-4-4], [9.8.2/H-5-3].

  • 2.2.7.2. Kamera:

    Lihat revisi

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

    • [7.5/H-1-3] HARUS mendukung properti android.info.supportedHardwareLevel sebagai FULL atau lebih baik untuk kamera utama belakang dan LIMITED atau yang lebih baik untuk kamera utama depan.

  • 2.3.2 Multimedia:

    Lihat revisi

    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.

3. Software

5. Kompatibilitas Multimedia

  • 5.3.8. Dolby Vision:

    Lihat revisi

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

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

7. Kompatibilitas Hardware

  • 7.1.1.1 Ukuran dan Bentuk Layar:

    Lihat revisi

    Jika implementasi perangkat mendukung layar yang mendukung konfigurasi ukuran UI_MODE_TYPE_NORMAL dan menggunakan tampilan fisik dengan sudut membulat untuk merender layar ini, implementasi tersebut akan:

    • [C-1-1] HARUS memastikan bahwa setidaknya salah satu dari persyaratan berikut terpenuhi untuk setiap tampilan tersebut:
      • Saat kotak dp berukuran 1518 dp x 1518 dp ditambatkan di setiap sudut tampilan logis, setidaknya satu piksel setiap kotak akan terlihat di layar.

  • 7.4.3. Bluetooth:

    Lihat revisi

    Persyaratan berikut diaktifkan kembali:

    Jika implementasi perangkat mendeklarasikan FEATURE_BLUETOOTH_LE, implementasi tersebut:

    • [C-SR-2] SANGAT DIREKOMENDASIKAN untuk mengukur dan mengompensasi offset Rx guna memastikan BLE RSSI 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 di 'bidang paralel' dengan layar menghadap ke arah yang sama.

    • [C-SR-3] SANGAT DIREKOMENDASIKAN untuk mengukur dan mengompensasi offset Tx guna memastikan BLE RSSI 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.

    Lihat revisi

    Memindahkan persyaratan [C-10-3] dan [C-10-4] ke 2.2.1. Perangkat keras.

    • [C-10-3] HARUS mengukur dan mengompensasi offset Rx untuk memastikan RSSI BLE median adalah -55dBm +/-10 dB pada jarak 1 m dari perangkat referensi yang melakukan transmisi pada ADVERTISE_TX_POWER_HIGH.
    • [C-10-4] HARUS mengukur dan mengompensasi offset Tx untuk memastikan RSSI BLE median adalah -55 dBm +/-10 dB saat memindai dari perangkat referensi yang diposisikan pada jarak 1 m dan mentransmisikan pada ADVERTISE_TX_POWER_HIGH.

20 November 2023

2. Jenis Perangkat

  • 2.2.1 Hardware:

    Lihat revisi

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

  • 2.2.7.2. Kamera:

    Lihat revisi

    • [7.5/H-1-13] HARUS mendukung kemampuan LOGICAL_MULTI_CAMERA untuk kamera belakang utama jika ada lebih dari 1 kamera belakang RGB.

  • 2.3.2 Multimedia:

    Lihat revisi

    • [5.8/T-0-1] HARUS menyetel mode output HDMI ke resolusi tertinggi untuk format SDR atau HDR yang dipilih yang berfungsi dengan kecepatan refresh 50 Hz atau 60 Hz untuk layar eksternal.

      HARUS menyetel mode output HDMI untuk memilih resolusi maksimum yang dapat didukung dengan kecepatan refresh 50 Hz atau 60 Hz.

  • 2.4.5. Model Keamanan:

    Lihat revisi

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

6. Kompatibilitas Opsi dan Developer Tools

  • 6.1 Developer Tools:

    Lihat revisi

    • [C-0-12] HARUS menulis Atom LMK_KILL_OCCURRED_FIELD_NUMBER ke

    Lihat revisi

    • [C-0-13] HARUS mengimplementasikan perintah shell dumpsys gpu --gpuwork untuk menampilkan

9. Kompatibilitas Model Keamanan

  • 9.7. Fitur Keamanan:

    Lihat revisi

    Jika implementasi perangkat menggunakan kernel Linux yang mampu mendukung SELinux, implementasi tersebut:

    Lihat revisi

    Jika implementasi perangkat menggunakan kernel selain Linux atau Linux tanpa SELinux, implementasi tersebut:

4 Oktober 2023

2. Jenis Perangkat

  • 2.2 Persyaratan Perangkat Genggam:

    Lihat revisi

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

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

    Mulai persyaratan baru

    • Memiliki antarmuka input layar sentuh.

  • 2.2.1 Hardware:

    Lihat revisi

    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.

    Jika implementasi perangkat genggam mendukung rotasi layar software, implementasi tersebut:

    • [7.1.1.1/H-1-1]* HARUS membuat layar logis yang tersedia untuk aplikasi pihak ketiga setidaknya 2 inci pada tepi pendek dan 2,7 inci pada tepi panjangnya. Perangkat yang dikirim di Android API level 29 atau yang lebih lama MUNGKIN dikecualikan dari persyaratan ini.

    Jika implementasi perangkat genggam tidak mendukung rotasi layar software, implementasi tersebut:

    • [7.1.1.1/H-2-1]* HARUS membuat layar logis yang tersedia untuk aplikasi pihak ketiga setidaknya 2,7 inci di tepi pendek. Perangkat yang dikirim di Android API level 29 atau yang lebih lama MUNGKIN dikecualikan dari persyaratan ini.

    Mulai persyaratan baru

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

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

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

    • [5.6/H-1-1] HARUS memiliki latensi Round-Trip Berkelanjutan Rata-rata 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 dari setidaknya 5 pengukuran pada jalur data speaker ke mikrofon.

    Jika implementasi perangkat genggam menyertakan setidaknya satu aktuator haptik, implementasi tersebut:

    Jika implementasi perangkat genggam menyertakan setidaknya satu aktuator resonansi linear 7.10 linear resonant, akan:

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

    • [7.10/H] HARUS menggerakkan aktuator haptik ke sumbu X (kiri-kanan) pada orientasi standar 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.

  • 2.2.2. Multimedia:

    Lihat revisi

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

    • [5,2/H-0-3] AV1

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

    • [5,3/H-0-6] AV1

  • 2.2.3. Software:

    Lihat revisi

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

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

    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-6] Implementasi perangkat HARUS merender kemampuan pengguna secara akurat sebagai berikut:
      • Jika perangkat telah menetapkan config_supportsMultiWindow=true dan aplikasi mendeklarasikan metadata META_DATA_PANEL_ACTIVITY di deklarasi ControlsProviderService, termasuk ComponentName dari aktivitas yang valid (sebagaimana ditentukan oleh API), aplikasi HARUS menyematkan aktivitas tersebut dalam kemampuan pengguna ini.
      • Jika tidak mendeklarasikan metadata META_DATA_PANEL_ACTIVITY, aplikasi HARUS merender kolom yang ditentukan seperti yang disediakan oleh ControlsProviderService API, serta kolom tertentu yang disediakan oleh Control API.
    • [3.8.16/H-1-7] Jika aplikasi mendeklarasikan metadata META_DATA_PANEL_ACTIVITY, aplikasi HARUS meneruskan nilai setelan yang ditentukan dalam [3.8.16/H-1-5] menggunakan EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS saat meluncurkan aktivitas tersemat.

    Jika implementasi perangkat memungkinkan pengguna melakukan panggilan dalam bentuk apa pun,

  • 2.2.4. Performa dan Keunggulan:

    Lihat revisi

    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.

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

  • 2.2.5. Model Keamanan:

    Lihat revisi

    Jika implementasi perangkat mendeklarasikan dukungan untuk android.hardware.telephony, implementasi perangkat akan:

    • [9.5/H-1-1] TIDAK BOLEH menetapkan UserManager.isHeadlessSystemUserMode ke true.

    Jika implementasi perangkat memiliki layar kunci yang aman dan menyertakan satu atau beberapa trust agent, yang mengimplementasikan TrustAgentService System API, implementasi tersebut:

    • [9.11.1/H-1-1] HARUS menantang pengguna untuk salah satu metode autentikasi utama yang direkomendasikan (misalnya: PIN, pola, sandi) lebih sering dari sekali setiap 72 jam.

    Jika implementasi Perangkat genggam menetapkan UserManager.isHeadlessSystemUserMode ke true, implementasi tersebut

    • [9.5/H-4-1] TIDAK BOLEH menyertakan dukungan untuk eUICC, juga eSIM dengan kemampuan panggilan.
    • [9.5/H-4-2] TIDAK BOLEH mendeklarasikan dukungan untuk android.hardware.telephony.

    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-6] TIDAK BOLEH mengizinkan lebih dari 100 byte data (tidak termasuk streaming audio) dikirim keluar dari layanan deteksi frasa pengaktif pada setiap hasil frasa pengaktif yang berhasil.

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

    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-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 mendukung VisualQueryDetectionService System API atau mekanisme lain untuk deteksi kueri tanpa indikasi akses mikrofon dan/atau kamera, implementasi tersebut:

    • [9.8/H-3-1] HARUS memastikan layanan deteksi kueri hanya dapat mengirimkan data ke Sistem, atau ContentCaptureService, atau layanan pengenalan ucapan di perangkat (yang dibuat oleh SpeechRecognizer#createOnDeviceSpeechRecognizer()).
    • [9.8/H-3-2] TIDAK BOLEH mengizinkan informasi audio atau video apa pun dikirim dari VisualQueryDetectionService, kecuali ke ContentCaptureService atau layanan pengenalan ucapan di perangkat.
    • [9.8/H-3-3] HARUS menampilkan pemberitahuan pengguna di UI Sistem saat perangkat mendeteksi niat pengguna untuk berinteraksi dengan Aplikasi Asisten Digital (misalnya, dengan mendeteksi kehadiran pengguna melalui kamera).
    • [9.8/H-3-4] HARUS menampilkan indikator mikrofon dan menampilkan kueri pengguna yang terdeteksi di UI tepat setelah kueri pengguna terdeteksi.
    • [9.8/H-3-5] TIDAK BOLEH mengizinkan aplikasi yang dapat diinstal pengguna menyediakan layanan deteksi kueri visual.

  • 2.2.7.1 Media:

    Lihat revisi

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

    Mulai persyaratan baru

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

    • [5.1/H-1-1] HARUS mengiklankan jumlah maksimum sesi dekoder video hardware yang dapat dijalankan secara serentak dalam kombinasi codec apa pun melalui metode CodecCapabilities.getMaxSupportedInstances() dan VideoCapabilities.getSupportedPerformancePoints().
    • [5.1/H-1-2] HARUS mendukung 6 instance sesi decoder video hardware 8-bit (SDR) (AVC, HEVC, VP9, AV1, atau yang lebih baru) dalam kombinasi codec apa pun yang berjalan bersamaan dengan 3 sesi pada resolusi 1080p@30 fps dan 3 sesi pada resolusi 4k@30 fps, kecuali AV1. Codec AV1 hanya diperlukan untuk mendukung resolusi 1080p, tetapi tetap harus mendukung 6 instance pada 1080p30fps.
    • [5.1/H-1-3] HARUS mengiklankan jumlah maksimum sesi encoder video hardware yang dapat dijalankan secara serentak dalam kombinasi codec apa pun melalui metode CodecCapabilities.getMaxSupportedInstances() dan VideoCapabilities.getSupportedPerformancePoints().
    • [5.1/H-1-4] HARUS mendukung 6 instance sesi encoder video hardware 8-bit (SDR) (AVC, HEVC, VP9, AV1, atau yang lebih baru) dalam kombinasi codec apa pun yang berjalan bersamaan dengan 4 sesi pada resolusi 1080p@30 fps dan 2 sesi pada resolusi 4k@30 fps, kecuali AV1. Codec AV1 hanya diperlukan untuk mendukung resolusi 1080p, tetapi tetap harus mendukung 6 instance pada 1080p30fps.
    • [5.1/H-1-5] HARUS mengiklankan jumlah maksimum sesi encoder dan decoder video hardware yang dapat dijalankan secara serentak dalam kombinasi codec apa pun melalui metode CodecCapabilities.getMaxSupportedInstances() dan VideoCapabilities.getSupportedPerformancePoints().
    • [5.1/H-1-6] HARUS mendukung 6 instance dekoder video hardware 8-bit (SDR) dan sesi encoder video hardware (AVC, HEVC, VP9, AV1, atau yang lebih baru) dalam kombinasi codec apa pun yang berjalan serentak dengan 3 sesi pada resolusi 4K@30 fps (kecuali AV1), dengan resolusi paling banyak 2 adalah sesi encoder dengan resolusi 10p dan 3 sesi dengan resolusi 4K@30 fps (kecuali AV1). Codec AV1 hanya diperlukan untuk mendukung resolusi 1080p, tetapi tetap harus mendukung 6 instance pada 1080p30fps.
    • [5.1/H-1-19] HARUS mendukung 3 instance dekoder video hardware 10-bit (HDR) dan sesi encoder video hardware (AVC, HEVC, VP9, AV1, atau yang lebih baru) dalam kombinasi codec apa pun yang berjalan bersamaan pada resolusi 4K@30 fps (kecuali AV1) yang paling banyak adalah format input GL0_1 RGB0 yang dapat dikonfigurasi dalam platform encoder1 RGB0, yang dapat dikonfigurasi secara bersamaan pada resolusi 4K@30 fps (kecuali AV1). Pembuatan metadata HDR oleh encoder tidak diperlukan jika encoding dari platform GL. Sesi codec AV1 hanya diperlukan untuk mendukung resolusi 1080p meskipun persyaratan ini memerlukan 4K.
    • [5.1/H-1-7] HARUS memiliki latensi inisialisasi codec sebesar 40 md atau kurang untuk sesi encoding video 1080p atau lebih kecil untuk semua encoder video hardware saat dalam beban. Muat di sini didefinisikan sebagai sesi transcoding khusus video 1080p hingga 720p yang menggunakan codec video hardware bersama dengan inisialisasi perekaman audio-video 1080p. Untuk codec Dolby Vision, latensi inisialisasi codec HARUS 50 md atau kurang.
    • [5.1/H-1-8] HARUS memiliki latensi inisialisasi codec sebesar 30 md atau kurang untuk sesi encoding audio dengan kecepatan bit 128 kbps atau lebih rendah untuk semua encoder audio saat dalam pemuatan. Muat di sini didefinisikan sebagai sesi transcoding khusus video 1080p hingga 720p yang menggunakan codec video hardware bersama dengan inisialisasi perekaman audio-video 1080p.
    • [5.1/H-1-9] HARUS mendukung 2 instance sesi decoder video hardware aman (AVC, HEVC, VP9, AV1, atau yang lebih baru) dalam kombinasi codec apa pun yang berjalan secara serentak pada resolusi 4K@30 fps (kecuali AV1) untuk konten HDR 8-bit (SDR) dan 10-bit. Sesi codec AV1 hanya diperlukan untuk mendukung resolusi 1080p meskipun persyaratan ini memerlukan 4K.
    • [5.1/H-1-10] HARUS mendukung 3 instance sesi decoder video hardware tidak aman bersama dengan 1 instance sesi decoder video hardware aman (total 4 instance) (AVC, HEVC, VP9, AV1, atau yang lebih baru) dalam kombinasi codec apa pun yang berjalan bersamaan dengan 3 sesi pada resolusi 4K@30 fps (kecuali satu decoder 0.1 fps aman pada sesi HDR0.0 fps yang mencakup sesi decoder 0.1 fps aman pada Sesi codec AV1 hanya diperlukan untuk mendukung resolusi 1080p meskipun persyaratan ini memerlukan 4K.
    • [5.1/H-1-11] HARUS mendukung decoder aman untuk setiap decoder AVC, HEVC, VP9, atau AV1 hardware di perangkat.
    • [5.1/H-1-12] HARUS memiliki latensi inisialisasi codec sebesar 40 md atau kurang untuk sesi decoding video 1080p atau lebih kecil untuk semua decoder video hardware saat dalam pemuatan. Muat di sini didefinisikan sebagai sesi transcoding khusus video 1080p hingga 720p yang menggunakan codec video hardware bersama dengan inisialisasi pemutaran audio-video 1080p. Untuk codec Dolby Vision, latensi inisialisasi codec HARUS 50 md atau kurang.
    • [5.1/H-1-13] HARUS memiliki latensi inisialisasi codec sebesar 30 md atau kurang untuk sesi decoding audio dengan kecepatan bit 128 kbps atau lebih rendah untuk semua decoder audio saat dalam pemuatan. Muat di sini didefinisikan sebagai sesi transcoding khusus video 1080p hingga 720p yang menggunakan codec video hardware bersama dengan inisialisasi pemutaran audio-video 1080p.
    • [5.1/H-1-14] HARUS mendukung decoder hardware AV1 Main 10, Level 4.1, dan film grain.
    • [5.1/H-1-15] HARUS memiliki setidaknya 1 hardware video decoder yang mendukung 4K60.
    • [5.1/H-1-16] HARUS memiliki minimal 1 encoder video hardware yang mendukung 4K60.
    • [5.3/H-1-1] TIDAK BOLEH menurunkan lebih dari 1 frame dalam 10 detik (yaitu kurang dari 0,167 persen penurunan frame) untuk sesi video 4K 60 fps saat beban.
    • [5.3/H-1-2] TIDAK BOLEH menurunkan lebih dari 1 frame dalam 10 detik selama perubahan resolusi video dalam sesi video 60 fps yang dimuat untuk sesi 4K.
    • [5.6/H-1-1] HARUS memiliki latensi tap-to-tone 80 milidetik atau kurang menggunakan uji tap-to-tone CTS Verifier.
    • [5.6/H-1-2] HARUS memiliki latensi audio bolak-balik sebesar 80 milidetik atau kurang pada setidaknya satu jalur data yang didukung.
    • [5.6/H-1-3] HARUS mendukung audio >=24-bit untuk output stereo melalui colokan audio 3,5 mm jika ada dan melalui audio USB jika didukung melalui seluruh jalur data untuk konfigurasi streaming dan latensi rendah. Untuk konfigurasi latensi rendah, AAudio harus digunakan oleh aplikasi dalam mode callback latensi rendah. Untuk konfigurasi streaming, Java AudioTrack harus digunakan oleh aplikasi. Dalam konfigurasi streaming dan latensi rendah, sink output HAL harus menerima AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED, AUDIO_FORMAT_PCM_32_BIT, atau AUDIO_FORMAT_PCM_FLOAT untuk format output targetnya.
    • [5.6/H-1-4] HARUS mendukung perangkat audio USB >=4 channel (Ini digunakan oleh pengontrol DJ untuk melihat pratinjau lagu.)
    • [5.6/H-1-5] HARUS mendukung perangkat MIDI yang sesuai dengan class dan mendeklarasikan flag fitur MIDI.
    • [5.6/H-1-9] HARUS mendukung setidaknya 12 pencampuran saluran. Hal ini menyiratkan kemampuan untuk membuka AudioTrack dengan mask saluran 7.1.4 dan spasial atau downmix semua saluran ke stereo dengan benar.
    • [5.6/H-SR] SANGAT DIREKOMENDASIKAN untuk mendukung mixing 24 saluran dengan setidaknya dukungan untuk mask saluran 9.1.6 dan 22.2.
    • [5.7/H-1-2] HARUS mendukung MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL dengan kemampuan dekripsi konten di bawah.
    Ukuran sampel minimum 4 MiB
    Jumlah Minimum Subsampel - H264 atau HEVC 32
    Jumlah Minimum Subsampel - VP9 9
    Jumlah Minimum Subsampel - AV1 288
    Ukuran buffer subsampel minimum 1 MiB
    Ukuran buffer kripto umum minimum 500 KiB
    Jumlah Minimum sesi serentak 30
    Jumlah minimum kunci per sesi 20
    Jumlah Total Kunci Minimum (semua sesi) 80
    Jumlah Total Minimum Kunci DRM (semua sesi) 6
    Ukuran Pesan 16 KiB
    Frame yang Didekripsi per Detik 60 fps
    • [5.1/H-1-17] HARUS memiliki minimal 1 decoder image hardware yang mendukung Profil Dasar Pengukuran AVIF.
    • [5.1/H-1-18] HARUS mendukung encoder AV1 yang dapat mengenkode resolusi hingga 480p pada 30 fps dan 1 Mbps.
    • [5.12/H-1-1] HARUS [5.12/H-SR] Sangat Direkomendasikan untuk mendukung dukungan fitur Feature_HdrEditing untuk semua encoder AV1 dan HEVC hardware yang ada di perangkat.
    • [5.12/H-1-2] HARUS mendukung format warna RGBA_1010102 untuk semua encoder AV1 dan HEVC hardware yang ada di perangkat.
    • [5.12/H-1-3] HARUS mengiklankan dukungan untuk ekstensi EXT_YUV_target untuk mengambil sampel dari tekstur YUV baik pada 8 maupun 10-bit.
    • [7.1.4/H-1-1] HARUS memiliki minimal 6 overlay hardware di Hardware composer (HWC) Unit pemrosesan data (DPU), dengan setidaknya 2 di antaranya mampu menampilkan konten video 10-bit.

    Jika implementasi Perangkat genggam menampilkan android.os.Build.VERSION_CODES.U untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS dan menyertakan dukungan untuk encoder AVC atau HEVC hardware, maka implementasi tersebut:

    • [5.2/H-2-1] HARUS memenuhi target kualitas minimum yang ditentukan oleh kurva distorsi laju encoder video untuk codec AVC dan HEVC hardware, seperti yang ditentukan dalam dokumentasi berikutnya.

  • 2.2.7.2. Kamera:

    Lihat revisi

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

    • [7.5/H-1-1] HARUS memiliki kamera belakang utama dengan resolusi minimal 12 megapiksel yang mendukung perekaman video 4k@30 fps. Kamera belakang utama adalah kamera belakang dengan ID kamera terendah.
    • [7.5/H-1-2] HARUS memiliki kamera depan utama dengan resolusi minimal 6 megapiksel dan mendukung perekaman video 1080p@30 fps. Kamera depan utama adalah kamera depan dengan ID kamera terendah.
    • [7.5/H-1-3] HARUS mendukung properti android.info.supportedHardwareLevel sebagai LENGKAP atau lebih baik untuk kedua kamera utama.
    • [7.5/H-1-4] HARUS mendukung CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME untuk kedua kamera utama.
    • [7.5/H-1-5] HARUS memiliki latensi pengambilan JPEG camera2 < 1.000 900 md untuk resolusi 1080p seperti yang diukur oleh PerformanceTest kamera CTS dalam kondisi pencahayaan ITS (3000K) untuk kedua kamera utama.
    • [7.5/H-1-6] HARUS memiliki latensi pengaktifan kamera2 (membuka kamera ke frame pratinjau pertama) < 500 md seperti yang diukur oleh PerformanceTest kamera CTS dalam kondisi pencahayaan ITS (3.000 K) untuk kedua kamera utama.
    • [7.5/H-1-8] HARUS mendukung CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW dan android.graphics.ImageFormat.RAW_SENSOR untuk kamera belakang utama.
    • [7.5/H-1-9] HARUS memiliki kamera utama hadap belakang yang mendukung 720p atau 1080p @ 240 fps.
    • [7.5/H-1-10] HARUS memiliki ZOOM_RATIO min < 1,0 untuk kamera utama jika ada kamera RGB ultrawide yang menghadap ke arah yang sama.
    • [7.5/H-1-11] HARUS mengimplementasikan streaming depan belakang secara serentak pada kamera utama.
    • [7.5/H-1-12] HARUS mendukung CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION untuk kamera depan dan kamera belakang utama.
    • [7.5/H-1-13] HARUS mendukung kemampuan LOGICAL_MULTI_CAMERA untuk kamera utama jika ada lebih dari 1 kamera RGB yang menghadap ke arah yang sama.
    • [7.5/H-1-14] HARUS mendukung kemampuan STREAM_USE_CASE untuk kamera depan dan kamera belakang utama.
    • [7.5/H-1-15] HARUS mendukung Bokeh & Ekstensi mode malam melalui ekstensi CameraX dan Camera2 untuk kamera utama.
    • [7.5/H-1-16] HARUS mendukung kemampuan DYNAMIC_RANGE_TEN_BIT untuk kamera utama.
    • [7.5/H-1-17] HARUS mendukung CONTROL_SCENE_MODE_FACE_PRIORITY dan deteksi wajah (STATISTICS_FACE_DETECT_MODE_SIMPLE atau STATISTICS_FACE_DETECT_MODE_FULL) untuk kamera utama.

  • 2.2.7.3. Hardware:

    Lihat revisi

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

    • [7.1.1.1/H-2-1] HARUS memiliki resolusi layar minimal 1080p.
    • [7.1.1.3/H-2-1] HARUS memiliki kepadatan layar minimal 400 dpi.
    • [7.1.1.3/H-3-1] HARUS memiliki layar HDR yang mendukung rata-rata setidaknya 1.000 nit.
    • [7.6.1/H-2-1] HARUS memiliki memori fisik minimal 8 GB.

  • 2.2.7.4. Performa:

    Lihat revisi

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

    • [8.2/H-1-1] HARUS memastikan performa operasi tulis sekuensial setidaknya 150 MB/dtk.
    • [8.2/H-1-2] HARUS memastikan performa tulis acak setidaknya 10 MB/s.
    • [8.2/H-1-3] HARUS memastikan performa baca berurutan setidaknya 250 MB/dtk.
    • [8.2/H-1-4] HARUS memastikan kinerja pembacaan acak setidaknya 100 MB/s.
    • [8.2/H-1-5] HARUS memastikan performa baca dan tulis berurutan paralel dengan performa 2x baca dan 1x tulis minimal 50 MB/dtk.

  • 2.3.2 Multimedia:

    Lihat revisi

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

    • [5,2/T-0-3] AV1

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

  • 2.4.5. Model Keamanan:

    Lihat revisi

    Jika implementasi perangkat memiliki layar kunci yang aman dan menyertakan satu atau beberapa trust agent, yang mengimplementasikan TrustAgentService System API, implementasi tersebut:

    • [9.11.1/W-1-1] HARUS menantang pengguna untuk salah satu metode autentikasi utama yang direkomendasikan (misalnya: PIN, pola, sandi) lebih sering dari sekali setiap 72 jam.

  • 2.5.1 Hardware:

    Lihat revisi

    Jika implementasi perangkat menyertakan dukungan untuk radio siaran AM/FM dan menampilkan fungsinya ke aplikasi apa pun, implementasi tersebut:

    • [7.4.10/A-0-1] HARUS mendeklarasikan dukungan untuk FEATURE_BROADCAST_RADIO.

    Kamera tampilan eksterior adalah kamera yang merekam adegan di luar implementasi perangkat, seperti kamera belakang.

    Implementasi perangkat otomotif:

    • HARUS menyertakan satu atau beberapa kamera tampilan eksterior.

    Jika implementasi perangkat Automotive menyertakan kamera tampilan eksterior, untuk kamera tersebut, implementasi perangkat tersebut:

    • [7.5/A-1-1] TIDAK BOLEH memiliki kamera tampilan eksterior yang dapat diakses melalui Android Camera API, kecuali jika kamera tersebut mematuhi persyaratan inti kamera.
    • [7.5/A-SR-1] SANGAT DIREKOMENDASIKAN untuk tidak memutar atau mencerminkan pratinjau kamera secara horizontal.
    • [7.5/A-SR-2] SANGAT DIREKOMENDASIKAN untuk memiliki resolusi minimal 1,3 megapiksel.
    • HARUS memiliki hardware fokus tetap atau EDOF (kedalaman bidang yang diperluas).
    • Mungkin memiliki fokus otomatis hardware atau fokus otomatis software yang diimplementasikan pada driver kamera.

    Jika implementasi perangkat otomotif menyertakan satu atau beberapa kamera tampilan eksterior, dan memuat layanan Exterior View System (EVS), maka untuk kamera tersebut, kamera tersebut:

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

    Implementasi perangkat otomotif:

    • DAPAT mencakup satu atau beberapa kamera yang tersedia untuk aplikasi pihak ketiga.

    Jika penerapan perangkat otomotif menyertakan setidaknya satu kamera dan membuatnya tersedia untuk aplikasi pihak ketiga, penerapan tersebut akan:

    • [7.5/A-3-1] HARUS melaporkan tombol fitur android.hardware.camera.any.
    • [7.5/A-3-2] TIDAK BOLEH mendeklarasikan kamera sebagai kamera sistem.
    • Mungkin mendukung kamera eksternal yang dijelaskan di bagian 7.5.3.
    • DAPAT mencakup fitur (seperti fokus otomatis, dll.) yang tersedia untuk kamera belakang seperti yang dijelaskan di bagian 7.5.1.

    Kamera belakang berarti kamera menghadap dunia yang dapat ditempatkan di mana saja pada kendaraan dan menghadap ke bagian luar kabin kendaraan; yaitu, menggambar pemandangan di sisi jauh bodi kendaraan, seperti kamera belakang.

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

    Implementasi perangkat otomotif:

    • [7.5/A-SR-1] SANGAT DIREKOMENDASIKAN untuk menyertakan satu atau beberapa kamera menghadap dunia.
    • MUNGKIN mencakup satu atau beberapa kamera yang menghadap pengguna.
    • [7.5/A-SR-2] SANGAT DIREKOMENDASIKAN untuk mendukung streaming beberapa kamera secara serentak.

    Jika implementasi perangkat Automotive menyertakan setidaknya satu kamera yang menghadap dunia, maka untuk kamera tersebut, kamera tersebut:

    • [7.5/A-1-1] HARUS diorientasikan agar dimensi panjang kamera sejajar dengan bidang X-Y sumbu sensor otomotif Android.
    • [7.5/A-SR-3] SANGAT DIREKOMENDASIKAN untuk memiliki hardware fokus tetap atau EDOF (Extended Depth of Field).
    • [7.5/A-1-2] HARUS memiliki kamera utama yang menghadap ke dunia sebagai kamera menghadap dunia dengan ID kamera terendah.

    Jika implementasi perangkat Automotive menyertakan setidaknya satu kamera yang menghadap pengguna, untuk kamera tersebut:

    • [7.5/A-2-1] Kamera utama yang menghadap pengguna HARUS merupakan kamera yang menghadap pengguna dengan ID kamera terendah.
    • MUNGKIN diorientasikan sehingga dimensi panjang kamera sejajar dengan bidang X-Y sumbu sensor otomotif Android.

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

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

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

    • [7.5/A-4-1] HARUS dapat diakses melalui layanan Extended View System.

    Jika implementasi perangkat Automotive menyertakan satu atau beberapa kamera yang dapat diakses melalui Extended View System Service, untuk kamera tersebut, kamera tersebut:

    • [7.5/A-5-1] TIDAK BOLEH memutar atau mencerminkan pratinjau kamera secara horizontal.
    • [7.5/A-SR-4] SANGAT DIREKOMENDASIKAN untuk memiliki resolusi minimal 1,3 megapiksel.

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

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

    Jika implementasi perangkat Automotive menyediakan API kamera eksklusif, implementasi tersebut:

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

  • 2.5.3. Software:

    Lihat revisi

    Implementasi perangkat otomotif:

    • [3.8/A-0-1] TIDAK BOLEH mengizinkan pengguna sekunder penuh yang bukan pengguna latar depan saat ini untuk meluncurkan aktivitas dan memiliki akses ke UI di layar apa pun.

  • 2.5.5. Model Keamanan:

    Lihat revisi

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

    • [9.8.2/A-1-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/A-1-2] TIDAK BOLEH menyembunyikan indikator mikrofon untuk aplikasi sistem yang memiliki antarmuka pengguna yang terlihat atau interaksi pengguna langsung.
    • [9.8.2/A-1-3] HARUS memberikan kemampuan pengguna untuk mengaktifkan/menonaktifkan mikrofon di aplikasi Settings.

    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-3] HARUS memberikan kemampuan pengguna untuk mengalihkan kamera di aplikasi Settings.
    • [9.8.2/A-2-4] HARUS menampilkan aplikasi Terbaru dan Aktif menggunakan kamera seperti yang ditampilkan dari PermissionManager.getIndicatorAppOpUsageData(), bersama dengan pesan atribusi apa pun yang terkait dengannya.

    Jika implementasi perangkat memiliki layar kunci yang aman dan menyertakan satu atau beberapa trust agent, yang mengimplementasikan TrustAgentService System API, implementasi tersebut:

    • [9.11.1/A-1-1] HARUS menantang pengguna untuk salah satu metode autentikasi utama yang direkomendasikan (misalnya: PIN, pola, sandi) lebih sering daripada sekali setiap 336 jam.

3. Software

  • 3.1 Kompatibilitas API Terkelola:

    Lihat revisi

    Implementasi perangkat:

    • [C-0-8] TIDAK BOLEH mendukung penginstalan aplikasi yang menargetkan API level kurang dari 23.

  • 3.2.3.5 Intent Aplikasi Bersyarat:

    Lihat revisi

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

  • 3.3.1 Antarmuka Biner Aplikasi:

    Lihat revisi

    Implementasi perangkat:

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

  • 3.8.6. Tema:

    Lihat revisi

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

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

  • 3.8.8. Peralihan Aktivitas:

    Lihat revisi

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

    • [C-1-2] HARUS menerapkan perilaku penyematan ke layar dan menyediakan menu setelan kepada pengguna untuk mengaktifkan/menonaktifkan fitur.

  • 3.9.2 Dukungan Profil Terkelola:

    Lihat revisi

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

    • [C-1-10] HARUS memastikan bahwa data screenshot disimpan di penyimpanan profil kerja saat screenshot diambil dengan jendela topActivity yang memiliki fokus (yang terakhir berinteraksi dengan pengguna di antara semua aktivitas) dan milik aplikasi profil kerja.
    • [C-1-11] TIDAK BOLEH mengambil konten layar lainnya (kolom sistem, notifikasi, atau konten profil pribadi apa pun) kecuali untuk window/jendela aplikasi profil kerja saat menyimpan screenshot ke profil kerja (untuk memastikan bahwa data profil pribadi tidak disimpan di profil kerja).

  • 3.9.5 Device Policy Resolution Framework: Bagian baru

    Lihat revisi

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

    • [C-1-1] HARUS menyelesaikan konflik kebijakan perangkat seperti yang didokumentasikan dalam dokumentasi AOSP.

5. Kompatibilitas Multimedia

  • 5.1.4. Encoding Gambar:

    Lihat revisi

    Implementasi perangkat HARUS mendukung encoding encoding gambar berikut:

    • [C-0-4] AVIF
      • Perangkat harus mendukung BITRATE_MODE_CQ dan Profil Dasar Pengukuran.

  • 5.1.5. Dekode Gambar:

    Lihat revisi

    Implementasi perangkat HARUS mendukung decoding encoding gambar berikut:

    [C-0-7] AVIF (Profil Dasar Pengukuran)

  • 5.1.6. Detail Codec Gambar:

    Lihat revisi

    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)

  • 5.1.8. Daftar Codec Video:

    Lihat revisi

    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
    VP9 Lihat bagian 5.3 untuk mengetahui detailnya
    AV1 Lihat bagian 5.2 dan bagian 5.3 untuk detailnya
    • MPEG-4 (.mp4)
    • Matroska (.mkv, khusus dekode)

  • 5.1.10. Karakteristik Codec Media:

    Lihat revisi

    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)

  • 5.2. Encoding Video:

    Lihat revisi

    Jika implementasi perangkat mendukung encoder video apa pun dan menyediakannya untuk aplikasi pihak ketiga, implementasi tersebut:

    • SEHARUSNYA TIDAK, pada dua jendela geser, lebih dari 15% di atas kecepatan bit antara interval intraframe (I-frame).
    • TIDAK BOLEH lebih dari 100% di atas kecepatan bit pada jendela geser berdurasi 1 detik.

    Jika implementasi perangkat mendukung encoder video dan menyediakannya untuk aplikasi pihak ketiga, serta menyetel
    MediaFormat.KEY_BITRATE_MODE ke BITRATE_MODE_VBR agar encoder beroperasi dalam mode Kecepatan bit variabel, maka, selama hal tersebut tidak memengaruhi nilai minimum kualitas, kecepatan bit yang dienkode :

    • [C-5-1] HARUS TIDAK BOLEH, di atas satu jendela geser, lebih dari 15% di atas kecepatan bit antara interval intraframe (I-frame).
    • [C-5-2] HARUS SEHARUS TIDAK lebih dari 100% di atas kecepatan bit pada jendela geser selama 1 detik.

    Jika implementasi perangkat mendukung encoder video dan menyediakannya untuk aplikasi pihak ketiga serta menyetel MediaFormat.KEY_BITRATE_MODE ke BITRATE_MODE_CBR sehingga encoder beroperasi dalam mode kecepatan bit konstan, maka kecepatan bit yang dienkode:

    • [C-6-1] HARUS [C-SR-2] SANGAT DIREKOMENDASIKAN untuk TIDAK lebih dari 15% di atas kecepatan bit target pada jendela geser 1 detik.

  • 5.2.1. H.263:

    Lihat revisi

    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.5. H.265:

    Lihat revisi

    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.

  • 5.2.6. AV1: bagian baru

    Lihat revisi

    Jika implementasi perangkat mendukung codec AV1, implementasi tersebut:

    • [C-1-1] HARUS mendukung Profil Utama termasuk konten 8-bit dan 10-bit.

    • [C-1-2] HARUS memublikasikan data performa, yaitu melaporkan data performa melalui API getSupportedFrameRatesFor() atau getSupportedPerformancePoints() untuk resolusi yang didukung pada tabel di bawah.

    • [C-1-3] HARUS menerima metadata HDR dan mengeluarkannya ke bitstream

    Jika encoder AV1 mengaktifkan akselerasi hardware, encoder tersebut:

    • [C-2-1] HARUS mendukung hingga dan termasuk profil encoding HD1080p dari tabel di bawah:
    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 5 Mbps 8 Mbps 16 Mbps 50 Mbps

  • 5.3.2. H.263:

    Lihat revisi

    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.9. AV1:

    Lihat revisi

    Jika implementasi perangkat mendukung codec AV1, implementasi tersebut:

    • [C-1-1] HARUS mendukung Profil 0 termasuk konten 10-bit.

    Jika implementasi perangkat mendukung codec AV1 dan menyediakannya untuk aplikasi pihak ketiga, implementasi tersebut:

    • [C-1-1] HARUS mendukung Profil Utama termasuk konten 8-bit dan 10-bit.

    Jika implementasi perangkat memberikan dukungan untuk codec AV1 dengan decoder akselerasi hardware, implementasi tersebut:

    • [C-2-1] HARUS dapat mendekode setidaknya profil decoding video HD 720p dari tabel di bawah jika tinggi yang dilaporkan oleh metode Display.getSupportedModes() sama atau lebih besar dari 720p.
    • [C-2-2] HARUS dapat mendekode setidaknya profil decoding video HD 1080p dari tabel di bawah jika tinggi yang dilaporkan oleh metode Display.getSupportedModes() sama atau lebih besar dari 1080p.
    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 5 Mbps 8 Mbps 16 Mbps 50 Mbps

    Jika implementasi perangkat mendukung Profil HDR melalui Media API, implementasi tersebut:

    • [C-3-1] HARUS mendukung ekstraksi dan pembuatan output metadata HDR dari bitstream dan/atau container.
    • [C-3-2] HARUS menampilkan konten HDR dengan benar pada layar perangkat atau port output video standar (misalnya, HDMI).

  • 5.4.2. Ambil foto untuk Pengenalan Suara:

    Lihat revisi

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

    • ±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

  • 5.5.2. Efek Audio:

    Lihat revisi

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

    • [C-1-4] HARUS mendukung efek audio dengan input dan output floating point.
    • [C-1-5] HARUS memastikan bahwa efek audio mendukung beberapa saluran hingga jumlah saluran mixer yang juga dikenal sebagai FCC_LIMIT.

  • 5.6. Latensi Audio:

    Lihat revisi

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

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

    • [C-SR-4] Latensi bolak-balik yang dihitung berdasarkan stempel waktu input dan output yang ditampilkan oleh AAudioStream_getTimestamp SANGAT DIREKOMENDASIKAN berada dalam waktu 30 mdtk dari latensi dua arah yang diukur untuk AAUDIO_PERFORMANCE_MODE_NONE dan AAUDIO_PERFORMANCE_MODE_LOW_LATENCY untuk speaker, headset berkabel dan nirkabel.

7. Kompatibilitas Hardware

  • 7.1. Tampilan dan Grafik:

    Lihat revisi

    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.

    Mulai persyaratan baru

    Implementasi perangkat:

    • [C-0-1] Secara default, HARUS merender aplikasi pihak ketiga hanya ke layar yang kompatibel dengan Android.

    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.1 Ukuran dan Bentuk Layar:

    Lihat revisi

    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 berukuran 15 dp x 15 dp ditambatkan di setiap sudut tampilan logika, setidaknya satu piksel dari setiap kotak akan terlihat di layar.

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

    Mulai persyaratan baru

    Jika implementasi perangkat hanya mampu melakukan konfigurasi keyboard NO_KEYS, dan bermaksud melaporkan dukungan untuk konfigurasi mode UI UI_MODE_TYPE_NORMAL, implementasi tersebut:

    • [C-4-1] HARUS memiliki ukuran tata letak, tidak termasuk potongan layar, minimal 596 dp x 384 dp atau lebih.

    Jika implementasi perangkat menyertakan layar kompatibel dengan Android yang dapat dilipat, atau menyertakan engsel lipat di antara beberapa panel layar dan membuat layar tersebut tersedia untuk merender aplikasi pihak ketiga, implementasi tersebut:

    Jika implementasi perangkat menyertakan layar kompatibel dengan Android yang dapat dilipat, atau menyertakan engsel lipat di antara beberapa panel layar dan jika engsel atau lipatan melintasi jendela aplikasi layar penuh, implementasi tersebut:

    • [C-3-1] HARUS melaporkan posisi, batas, dan status engsel atau lipat melalui ekstensi atau API file bantuan ke aplikasi.

    Jika implementasi perangkat menyertakan satu atau beberapa area tampilan yang kompatibel dengan Android yang dapat dilipat, atau menyertakan engsel lipat di antara beberapa area panel layar yang kompatibel dengan Android dan membuat area tampilan tersebut tersedia untuk aplikasi, maka:

    • [C-4-1] HARUS menerapkan versi API level Ekstensi Window Manager yang benar seperti yang dijelaskan dalam dokumentasi mendatang.

  • 7.1.1.2. Rasio Aspek Layar: dihapus

  • 7.1.1.3. Kepadatan Layar:

    Lihat revisi

    Penerapan Perangkat:

    • [C-0-1] Secara default, implementasi perangkat TIDAK BOLEH 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 saja; namun, ukuran perangkat yang berbedaDisplayMetrics.density

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

    Mulai persyaratan baru

    • HARUS tentukan kepadatan framework Android standar yang secara numerik paling mendekati kepadatan fisik layar, atau nilai yang akan dipetakan ke pengukuran ruang pandang sudut yang setara dengan perangkat genggam.

    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.

  • 7.1.4.2 Vulkan:

    Lihat revisi

    Jika implementasi perangkat menyertakan dukungan untuk Vulkan 1.0 atau yang lebih tinggi, implementasi tersebut:

    • [C-1-3] HARUS sepenuhnya menerapkan Vulkan 1.0 Vulkan 1.1 API untuk setiap VkPhysicalDevice yang dienumerasi.

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

    • HARUS mendukung VkPhysicalDeviceProtectedMemoryFeatures dan VK_EXT_global_priority.

    • [C-SR-5] SANGAT DIREKOMENDASIKAN untuk mendukung VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory dan VK_EXT_global_priority.

    • [C-SR-6] SANGAT DIREKOMENDASIKAN untuk menggunakan SkiaVk dengan HWUI.

    Jika implementasi perangkat menyertakan dukungan untuk Vulkan 1.1 dan mendeklarasikan salah satu flag fitur Vulkan yang dijelaskan di sini , implementasi tersebut:

    • [C-SR-7] SANGAT DIREKOMENDASIKAN untuk menyediakan ekstensi VK_KHR_external_fence_fd bagi aplikasi pihak ketiga serta memungkinkan aplikasi mengekspor payload fence ke dan mengimpor payload fence dari deskripsi file POSIX seperti yang dijelaskan di sini.

  • 7.3.10. Sensor Biometrik:

    Lihat revisi

    Jika implementasi perangkat memiliki beberapa sensor biometrik, implementasi tersebut:

    • [C-7-1] HARUS, saat biometrik sedang terkunci (yaitu, biometrik dinonaktifkan hingga pengguna membuka kunci dengan autentikasi utama) atau penguncian terikat waktu (yaitu, biometrik dinonaktifkan sementara sampai pengguna menunggu interval waktu) karena terlalu banyak upaya yang gagal, juga akan mengunci semua biometrik lain dari kelas biometrik yang lebih rendah. Dalam kasus penguncian terikat waktu, waktu backoff untuk verifikasi biometrik HARUS berupa waktu backoff maksimum dari semua biometrik dalam penguncian terikat waktu.

    • [C-SR-12] SANGAT DIREKOMENDASIKAN, saat biometrik dinonaktifkan (yaitu, biometrik dinonaktifkan hingga pengguna membuka kunci dengan autentikasi utama) atau penguncian terikat waktu (yaitu, biometrik dinonaktifkan untuk sementara hingga pengguna menunggu interval waktu) karena terlalu banyak upaya yang gagal, untuk juga mengunci semua biometrik lain dari class biometrik yang sama. Dalam kasus penguncian terikat waktu, waktu backoff untuk verifikasi biometrik SANGAT DIREKOMENDASIKAN sebagai waktu backoff maksimum dari semua biometrik dalam penguncian terikat waktu.

    • [C-7-2] HARUS menantang pengguna untuk autentikasi utama yang direkomendasikan (misalnya: PIN, pola, sandi) untuk mereset penghitung penguncian agar biometrik terkunci. Biometrik Kelas 3 DAPAT diizinkan untuk mereset penghitung penguncian untuk biometrik terkunci dari class yang sama atau lebih rendah. Biometrik Kelas 2 atau Kelas 1 TIDAK BOLEH diizinkan untuk menyelesaikan operasi penguncian reset untuk semua biometrik.

    Jika implementasi perangkat ingin memperlakukan sensor biometrik sebagai Class 1 (sebelumnya Kemudahan), fungsi tersebut:

    • [C-1-12] HARUS memiliki tingkat penerimaan spoof dan penipu yang tidak lebih tinggi dari 40% spesies instrumen serangan presentasi (PAI), seperti yang diukur oleh Protokol Pengujian Biometrik Android.

    • [C-SR-13] SANGAT DIREKOMENDASIKAN untuk memiliki tingkat penerimaan spoof dan penipu yang tidak lebih dari 30% spesies serangan per presentasi (PAI), seperti yang diukur oleh Protokol Pengujian Biometrik Android.

    • [C-SR-14] SANGAT DIREKOMENDASIKAN untuk mengungkapkan kelas biometrik sensor biometrik dan risiko terkait jika diaktifkan.

    • [C-SR-17] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan antarmuka AIDL baru (seperti, IFace.aidl dan IFingerprint.aidl).

    Jika implementasi perangkat ingin memperlakukan sensor biometrik sebagai Class 2 (sebelumnya Lemah), sensor tersebut:

    • [C-SR-15] SANGAT DIREKOMENDASIKAN untuk memiliki tingkat penerimaan spoofing dan penipu yang tidak lebih tinggi dari 20% spesies instrumen serangan presentasi (PAI), seperti yang diukur oleh Protokol Pengujian Biometrik Android.

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

    Jika implementasi perangkat ingin memperlakukan sensor biometrik sebagai Class 3 (sebelumnya Strong), sensor tersebut:

    • [C-SR-16] SANGAT DIREKOMENDASIKAN untuk memiliki tingkat penerimaan spoof dan penipu yang tidak lebih dari 7% spesies serangan per presentasi (PAI), seperti yang diukur oleh Protokol Pengujian Biometrik Android.

  • 7.3.13. IEEE 802.1.15.4 (UWB):

    Lihat revisi

    Jika implementasi perangkat menyertakan dukungan untuk 802.1.15.4 dan mengekspos fungsionalitas ke aplikasi pihak ketiga, implementasi tersebut:

    • [C-1-2] HARUS melaporkan tombol fitur hardware android.hardware.uwb.
    • [C-1-3] HARUS mendukung semua set konfigurasi berikut (kombinasi parameter FIRA UCI yang telah ditentukan) yang ditentukan dalam implementasi AOSP.
      • CONFIG_ID_1: Rentang STATIC STS DS-TWR unicast yang ditentukan FiRa, mode ditangguhkan, interval rentang 240 md.
      • CONFIG_ID_2: Mode rentang STATIC STS DS-TWR one-to-many yang ditentukan FiRa, dengan interval rentang 200 md. Kasus penggunaan umum: smartphone berinteraksi dengan banyak perangkat smart.
      • CONFIG_ID_3: Sama seperti CONFIG_ID_1, tetapi data Sudut kedatangan (AoA) tidak dilaporkan.
      • CONFIG_ID_4: Sama seperti CONFIG_ID_1, tetapi mode keamanan P-STS diaktifkan.
      • CONFIG_ID_5: Sama seperti CONFIG_ID_2, tetapi mode keamanan P-STS diaktifkan.
      • CONFIG_ID_6: Sama seperti CONFIG_ID_3, tetapi mode keamanan P-STS diaktifkan.
      • CONFIG_ID_7: Sama seperti CONFIG_ID_2, kecuali mode kunci kontrol individu P-STS diaktifkan.
    • [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 (di bawah grup izin NEARBY_DEVICES).

    Lulus pengujian kesesuaian dan sertifikasi relevan yang ditentukan oleh organisasi standar, termasuk FIRA, CCC, dan CSA akan membantu memastikan 802.1.15.4 berfungsi dengan benar.

  • 7.4.1. Telepon:

    Lihat revisi

    “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) GSM 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 tidak bergantung pada konektivitas data apa pun yang dapat 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 aplikasi tersebut menggunakan jaringan seluler untuk konektivitas data atau tidak.

  • 7.4.2. IEEE 802.11 (Wi-Fi):

    Lihat revisi

    Jika implementasi perangkat menyertakan dukungan untuk 802.11 dan menampilkan fungsinya ke aplikasi pihak ketiga, implementasi tersebut:

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

  • 7.4.3. Bluetooth:

    Lihat revisi

    Jika implementasi perangkat mendeklarasikan FEATURE_BLUETOOTH_LE, implementasi tersebut:

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

    • [C-10-3] HARUS mengukur dan mengompensasi offset Rx untuk memastikan RSSI BLE median adalah -55dBm +/-10 dB pada jarak 1 m dari perangkat referensi yang melakukan transmisi pada ADVERTISE_TX_POWER_HIGH.
    • [C-10-4] HARUS mengukur dan mengompensasi offset Tx untuk memastikan RSSI BLE median adalah -55 dBm +/-10 dB saat memindai dari perangkat referensi yang diposisikan pada jarak 1 m dan mentransmisikan pada ADVERTISE_TX_POWER_HIGH.

    Jika implementasi perangkat mendukung Bluetooth versi 5.0, implementasi tersebut:

    • [C-SR-4] SANGAT DIREKOMENDASIKAN untuk memberikan dukungan bagi:
    • LE 2 JT PHY
    • LE Codec PHY
    • Ekstensi LE Advertising
    • Iklan berkala
    • Minimal 10 set iklan
    • Minimal 8 koneksi serentak LE. Setiap koneksi dapat memiliki peran topologi koneksi.
    • Privasi Lapisan LE Link
    • Ukuran "daftar penyelesaian" minimal 8 entri

  • 7.4.9. UWB:

    Lihat revisi

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

  • 7.5.1. Kamera Belakang:

    Lihat revisi

    Kamera belakang adalah kamera yang terletak di sisi perangkat berlawanan dengan layar; yaitu, kamera merekam adegan di sisi jauh perangkat, seperti kamera tradisional.

    Kamera belakang adalah kamera hadap dunia yang mengambil gambar adegan di sisi jauh perangkat, seperti kamera tradisional; pada perangkat genggam, yaitu kamera yang terletak di sisi perangkat berlawanan dengan layar.

  • 7.5.2. Kamera Depan:

    Lihat revisi

    Kamera depan adalah kamera yang terletak di sisi perangkat yang sama dengan layar; yaitu, kamera yang biasanya digunakan untuk mengambil gambar pengguna, seperti untuk konferensi video dan aplikasi serupa.

    Kamera depan adalah kamera yang menghadap pengguna yang biasanya digunakan untuk mengambil gambar pengguna, seperti untuk konferensi video dan aplikasi serupa; pada perangkat genggam, yaitu kamera yang terletak di sisi perangkat yang sama dengan layar.

  • 7.5.3. Kamera Eksternal:

    Lihat revisi

    Kamera eksternal adalah kamera yang dapat dipasang atau dilepas secara fisik dari implementasi perangkat kapan saja dan dapat menghadap ke segala arah, seperti kamera USB.

  • 7.5.4. Perilaku Camera API:

    Lihat revisi

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

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

  • 7.5.5. Orientasi Kamera:

    Lihat revisi

    Perangkat yang memenuhi semua kriteria berikut akan dikecualikan dari persyaratan di atas:

    • Implementasi perangkat yang tidak dapat dirotasi oleh pengguna seperti perangkat otomotif.

  • 7.10. Haptic:

    Lihat revisi

    Perangkat yang ditujukan untuk digenggam atau dipakai dapat mencakup aktuator haptik untuk tujuan umum, yang tersedia bagi aplikasi untuk berbagai tujuan, termasuk menarik perhatian melalui nada dering, alarm, notifikasi, serta respons sentuh umum.

    Jika implementasi perangkat TIDAK menyertakan aktuator haptik tujuan umum tersebut, implementasi perangkat akan:

    • [7.10/C] HARUS menampilkan nilai salah untuk Vibrator.hasVibrator().

    Jika implementasi perangkat TIDAK menyertakan setidaknya satu aktuator haptic tujuan umum tersebut, implementasi tersebut:

    Jika implementasi perangkat mengikuti pemetaan konstanta haptic, implementasi tersebut:

    Lihat Pasal 2.2.1 untuk mengetahui persyaratan khusus perangkat.

9. Kompatibilitas Model Keamanan

  • 9.1 Izin:

    Lihat revisi

    Implementasi perangkat:

    • [C-0-4] HARUS memiliki satu dan hanya satu implementasi untuk kedua antarmuka pengguna.

    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".

    • [C-4-2] TIDAK BOLEH memiliki izin android.permission.INTERNET. Tindakan ini lebih ketat daripada yang SANGAT DIREKOMENDASIKAN sebagaimana tercantum dalam pasal 9.8.6.
    • [C-4-3] TIDAK BOLEH mengikat ke aplikasi lain, kecuali untuk aplikasi sistem berikut: Bluetooth, Kontak, Media, Telepon, SystemUI, dan komponen yang menyediakan Internet API. Tindakan ini lebih ketat daripada yang SANGAT DIREKOMENDASIKAN sebagaimana tercantum dalam pasal 9.8.6.

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

    • [C-5-1] TIDAK BOLEH memberikan ACCESS_FINE_LOCATION sebagai default untuk aplikasi tersebut.

  • 9.5. Dukungan Multipengguna:

    Lihat revisi

    Jika implementasi perangkat membuat profil pengguna tambahan yang dibahas di atas, implementasi perangkat tersebut:

    • [C-4-5] HARUS membedakan ikon aplikasi dual instance secara visual saat ikon tersebut ditampilkan kepada pengguna.
    • [C-4-6] HARUS memberikan kemampuan pengguna untuk menghapus seluruh data profil clone.
    • [C-4-7] HARUS meng-uninstal semua aplikasi Clone, menghapus direktori data aplikasi pribadi dan kontennya, serta menghapus data profil Clone, jika pengguna memilih untuk menghapus seluruh data profil Clone.
    • HARUS meminta pengguna untuk menghapus seluruh data Profil Clone saat aplikasi clone terakhir dihapus.
    • [C-4-8] HARUS memberi tahu pengguna bahwa data aplikasi akan dihapus jika aplikasi clone di-uninstal, atau memberikan opsi kepada pengguna untuk menyimpan data aplikasi saat aplikasi di-uninstal dari perangkat.
    • [C-4-9] HARUS menghapus direktori data aplikasi pribadi dan kontennya, jika pengguna memilih untuk menghapus data selama uninstal.

    • [C-4-14] HARUS memiliki izin dan pengelolaan penyimpanan terpisah untuk aplikasi yang berjalan di profil tambahan ini

    • [C-4-5] Hanya boleh mengizinkan aplikasi di profil tambahan yang memiliki aktivitas peluncur untuk mengakses kontak yang sudah dapat diakses oleh profil pengguna induk.

  • 9.7. Fitur Keamanan:

    Lihat revisi

    Teknologi Keamanan Memori adalah teknologi yang mengurangi setidaknya class bug berikut dengan probabilitas tinggi (> 90%) dalam aplikasi yang menggunakan opsi manifes android:memtagMode:

    • luapan buffer heap
    • gunakan setelah tersedia
    • bebas ganda
    • bebas liar (bebas dari pointer non-malloc)

    Implementasi perangkat:

    • [C-SR-15] SANGAT DIREKOMENDASIKAN untuk menetapkan ro.arm64.memtag.bootctl_supported.

    Jika implementasi perangkat menetapkan properti sistem ro.arm64.memtag.bootctl_supported ke benar (true), implementasi tersebut:

    • [C-3-1] HARUS mengizinkan properti sistem arm64.memtag.bootctl untuk menerima daftar yang dipisahkan koma dari nilai berikut, dengan efek yang diinginkan diterapkan pada mulai ulang berikutnya:

      • memtag: teknologi Keamanan Memori seperti yang dijelaskan di atas diaktifkan
      • memtag-once: teknologi Keamanan Memori seperti yang dijelaskan di atas diaktifkan sementara, dan otomatis dinonaktifkan saat, reboot berikutnya
      • memtag-off: teknologi Keamanan Memori seperti yang dijelaskan di atas dinonaktifkan

    • [C-3-2] HARUS mengizinkan pengguna shell menyetel arm64.memtag.bootctl.

    • [C-3-3] HARUS mengizinkan semua proses membaca arm64.memtag.bootctl.

    • [C-3-4] HARUS menetapkan arm64.memtag.bootctl ke status yang diminta saat ini saat booting, properti juga HARUS mengupdate properti, jika implementasi perangkat memungkinkan untuk mengubah status tanpa mengubah properti sistem.

    • [C-SR-16] SANGAT DIREKOMENDASIKAN untuk menampilkan Setelan Developer yang menyetel memtag-sekali dan memulai ulang perangkat. Dengan bootloader yang kompatibel, Project Open Source Android memenuhi persyaratan di atas melalui protokol bootloader MTE.

    • [C-SR-17] SANGAT DIREKOMENDASIKAN untuk menampilkan Setelan di menu Setelan Keamanan yang memungkinkan pengguna mengaktifkan memtag.

  • 9.8.2. Perekaman:

    Lihat revisi

    Implementasi perangkat:

    • [C-0-2] HARUS menampilkan peringatan pengguna dan mendapatkan izin pengguna eksplisit yang memungkinkan informasi sensitif apa pun yang ditampilkan di layar pengguna dapat ditangkapdiaktifkan yang menyertakan pesan yang sama persis dengan AOSP kapan pun setiap kali setiap kali sesi untuk merekam layar pemancaran atau perekaman layar {1010 , diaktifkan MediaProjection.createVirtualDisplay()VirtualDeviceManager.createVirtualDisplay() TIDAK BOLEH memberi pengguna kemampuan untuk menonaktifkan tampilan izin pengguna di masa mendatang.

    • [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menampilkan peringatan pengguna yang sama persis dengan yang diimplementasikan dalam AOSP, tetapi DAPAT diubah selama pesan tersebut dengan jelas memperingatkan pengguna bahwa setiap informasi sensitif di layar pengguna telah diambil.

    • [C-0-4] TIDAK BOLEH memberi pengguna affordance untuk menonaktifkan perintah izin pengguna di masa mendatang untuk merekam layar, kecuali jika sesi dimulai oleh aplikasi sistem yang telah diizinkan pengguna untuk associate() dengan android.app.role.COMPANION_DEVICE_APP_STREAMING atau profil perangkat android.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING.

  • 9.8.6. Data tingkat OS dan data standby: Bagian ini diganti namanya dari Pengambilan Konten dan Penelusuran Aplikasi menjadi data tingkat OS dan data standby.

    Lihat revisi

    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:

    • Layar atau data lain apa pun yang dikirim melalui AugmentedAutofillService ke sistem.
    • Semua layar atau data lain yang dapat diakses melalui Content Capture API.
    • Semua layar atau data lain yang dapat diakses melalui FieldClassificationService API
    • Data aplikasi apa pun yang diteruskan ke sistem melalui AppSearchManager API dan dapat diakses melalui AppSearchGlobalManager.query.

    • Peristiwa lain yang disediakan aplikasi ke sistem melalui API Content Capture atau API AppSearchManager atau API Android dan eksklusif yang memiliki kemampuan serupa.

    • Data audio yang diperoleh sebagai hasil penggunaan SpeechRecognizer#onDeviceSpeechRecognizer() oleh Implementasi Pengenal Ucapan.
    • Data audio yang diperoleh di latar belakang (terus-menerus) melalui AudioRecord, SoundTrigger, atau API Audio lainnya, dan tidak menghasilkan indikator yang terlihat oleh pengguna
    • Data kamera yang diperoleh di latar belakang (terus-menerus) melalui CameraManager atau API Kamera lainnya, dan tidak menghasilkan indikator yang terlihat oleh pengguna

    Jika implementasi perangkat mengambil salah satu data di atas, implementasi tersebut:

    • [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 “Mekanisme yang hanya memungkinkan analisis secara gabungan dan mencegah pencocokan peristiwa yang dicatat ke dalam log atau hasil turunan terhadap masing-masing pengguna”, untuk mencegah data per pengguna agar tidak dapat diintegrasikan (mis., diterapkan menggunakan teknologi privasi diferensial seperti RAPPOR).

    • [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 Content Capture 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 sehingga implementasi ContentCaptureService atau sarana kepemilikan 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-SR-3] SANGAT DIREKOMENDASIKAN untuk diimplementasikan dengan Android SDK API atau repositori open source milik OEM yang serupa; dan / atau dilakukan dalam implementasi dengan sandbox (lihat 9.8.15 Penerapan API dengan sandbox).

    Android, melalui SpeechRecognizer#onDeviceSpeechRecognizer() menyediakan kemampuan untuk melakukan pengenalan ucapan di perangkat, tanpa melibatkan jaringan. Setiap penerapan SpeechKenalir di perangkat HARUS mengikuti kebijakan yang diuraikan di bagian ini.

  • 9.8.10. Laporan Bug Konektivitas:

    Lihat revisi

    Jika implementasi perangkat mendeklarasikan flag fitur android.hardware.telephony, implementasi tersebut:

    • [C-1-4] Laporan yang dihasilkan menggunakan BUGREPORT_MODE_TELEPHONY HARUS berisi setidaknya informasi berikut:
      • File dump SubscriptionManagerService

  • 9.8.14. Pengelola Kredensial: Dihapus

  • 9.8.15. Implementasi API dengan Sandbox: Bagian baru

    Lihat revisi

    Android, melalui serangkaian API delegasi menyediakan mekanisme untuk memproses data tingkat OS dan data standby yang aman. Pemrosesan tersebut dapat didelegasikan ke apk prainstal dengan akses istimewa dan kemampuan komunikasi yang lebih rendah, yang dikenal sebagai Implementasi API dengan Sandbox.

    Semua Implementasi API dengan Sandbox:

    • [C-0-1] TIDAK BOLEH meminta izin INTERNET.
    • [C-0-2] HARUS mengakses internet hanya melalui API terstruktur yang didukung oleh implementasi open source yang tersedia untuk publik menggunakan mekanisme yang menjaga privasi, atau secara tidak langsung melalui Android SDK API. Mekanisme yang menjaga privasi didefinisikan sebagai "tindakan 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-0-3] HARUS memisahkan layanan dari komponen sistem lainnya (misalnya tidak mengikat layanan atau berbagi ID proses), kecuali untuk hal berikut:
      • Telepon, Kontak, UI Sistem, dan Media
    • [C-0-4] TIDAK BOLEH mengizinkan pengguna mengganti layanan dengan aplikasi atau layanan yang dapat diinstal pengguna
    • [C-0-5] hanya boleh mengizinkan layanan prainstal untuk mengambil data tersebut. Kecuali jika kemampuan penggantian terintegrasi dalam AOSP (mis. untuk Aplikasi Asisten Digital).
    • [C-0-6] TIDAK BOLEH mengizinkan aplikasi apa pun selain mekanisme layanan bawaan untuk dapat mengambil data tersebut. Kecuali jika kemampuan pengambilan tersebut diimplementasikan dengan Android SDK API.
    • [C-0-7] HARUS memberikan affordance pengguna untuk menonaktifkan layanan.
    • [C-0-8] TIDAK BOLEH menghilangkan kemampuan pengguna untuk mengelola izin Android yang dipegang oleh layanan dan mengikuti model izin Android seperti yang dijelaskan di Bagian 9.1. Izin.

  • 9.8.16. Data Audio dan Kamera berkelanjutan: Bagian baru

    Lihat revisi

    Selain persyaratan yang diuraikan dalam 9.8.2 Perekaman, data tingkat OS dan data standby 9.8.6, serta implementasi API dengan Sandbox 9.8.15, implementasi yang menggunakan data Audio yang diperoleh di latar belakang (berkelanjutan) melalui AudioRecord, SoundTrigger, atau data Audio API ATAU data Kamera lainnya yang diperoleh di latar belakang (berkelanjutan) melalui CameraManager atau API Kamera lainnya:

    • [C-0-1] HARUS menerapkan indikator yang sesuai (kamera dan/atau mikrofon sebagaimana per pasal 9.8.2 Perekaman), kecuali:
    • [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mewajibkan izin pengguna bagi setiap fungsi yang menggunakan data tersebut, dan dinonaktifkan secara default.
    • [C-SR-2] SANGAT DIREKOMENDASIKAN untuk menerapkan perlakuan yang sama (yaitu, ikuti pembatasan yang diuraikan dalam 9.8.2 Perekaman, data level OS 9.8.6 dan data standby, Implementasi API dengan sandbox 9.8.15, dan data Audio dan Kamera Berkelanjutan 9.8.16) ke data Kamera yang berasal dari perangkat wearable jarak jauh.

    Jika data Kamera disediakan dari perangkat wearable jarak jauh dan diakses dalam bentuk yang tidak terenkripsi di luar Android OS, implementasi yang di-sandbox, atau fungsi yang di-sandbox yang dibangun oleh WearableSensingManager, data tersebut:

    • [C-1-1] HARUS menunjukkan ke perangkat wearable jarak jauh untuk menampilkan indikator tambahan di sana.

    Jika perangkat menyediakan kemampuan untuk berinteraksi dengan Aplikasi Asisten Digital tanpa kata kunci yang ditetapkan (baik menangani kueri pengguna umum atau menganalisis kehadiran pengguna melalui kamera):

    • [C-2-1] HARUS memastikan implementasi tersebut disediakan oleh paket yang memiliki peran android.app.role.ASSISTANT.
    • [C-2-2] HARUS memastikan penerapan tersebut menggunakan API Android HotwordDetectionService dan/atau VisualQueryDetectionService.

  • 9.8.17. Telemetri: Bagian baru

    Lihat revisi

    Android menyimpan log sistem dan aplikasi menggunakan StatsLog API. Log ini dikelola melalui StatsManager API yang dapat digunakan oleh aplikasi sistem dengan hak istimewa.

    StatsManager juga menyediakan cara untuk mengumpulkan data yang dikategorikan sebagai sensitif terhadap privasi dari perangkat dengan mekanisme yang menjaga privasi. Secara khusus, API StatsManager::query memberikan kemampuan untuk membuat kueri kategori metrik yang dibatasi yang ditentukan di StatsLog.

    Semua penerapan yang membuat kueri dan mengumpulkan metrik yang dibatasi dari StatsManager:

    • [C-0-1] HARUS menjadi satu-satunya aplikasi/implementasi di perangkat dan memiliki izin READ_RESTRICTED_STATS.
    • [C-0-2] HARUS hanya mengirim data telemetri dan log perangkat menggunakan mekanisme yang menjaga privasi. Mekanisme yang menjaga privasi didefinisikan sebagai "fitur 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 dapat dimasukkan (mis., diterapkan menggunakan teknologi privasi diferensial seperti RAPPOR).
    • [C-0-3] TIDAK BOLEH mengaitkan data tersebut dengan identitas pengguna apa pun (seperti Akun) di perangkat.
    • [C-0-4] TIDAK BOLEH membagikan data tersebut dengan komponen OS lainnya yang tidak mengikuti persyaratan yang diuraikan di bagian saat ini (9.8.17 Telemetri yang menjaga Privasi).
    • [C-0-5] HARUS menyediakan kemampuan pengguna untuk mengaktifkan/menonaktifkan pengumpulan, penggunaan, dan berbagi telemetri yang menjaga privasi.
    • [C-0-6] HARUS memberikan kemampuan pengguna untuk menghapus data tersebut, yang dikumpulkan oleh implementasi jika data disimpan dalam bentuk apa pun di perangkat. Jika pengguna memilih untuk menghapus data, HARUS menghapus semua data yang saat ini tersimpan di perangkat.
    • [C-0-7] HARUS mengungkapkan penerapan protokol yang menjaga privasi dasar di repositori open source.
    • [C-0-8 ]HARUS memberlakukan kebijakan traffic keluar data di bagian ini untuk membatasi pengumpulan data dalam kategori metrik yang dibatasi yang ditetapkan di StatsLog.

  • 9.10. Integritas Perangkat:

    Lihat revisi

    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.

    • [C-2-4] HARUS mengembalikan checksum file di O(1) untuk file yang diaktifkan.

  • 9.11. Kunci dan Kredensial:

    Lihat revisi

    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-3] HARUS membatasi jumlah upaya autentikasi utama yang gagal.
    • [C-SR-2] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan batas atas 20 upaya autentikasi utama yang gagal, dan jika pengguna mengizinkan dan memilih ikut serta dalam fitur tersebut, lakukan "Reset ke Setelan Pabrik" setelah melebihi batas upaya autentikasi utama yang gagal.

    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, maka:

    • [C-SR-3] PIN SANGAT DIREKOMENDASIKAN untuk memiliki minimal 6 digit, atau setara dengan entropi 20-bit.
    • [C-2-1] PIN yang panjangnya kurang dari 6 digit TIDAK BOLEH memungkinkan entri otomatis tanpa interaksi pengguna untuk menghindari pengungkapan panjang PIN.

  • 9.11.1. Layar Kunci Aman, Autentikasi, dan Perangkat Virtual:

    Lihat revisi

    Implementasi perangkat:

    • [C-0-1] HARUS membatasi jumlah upaya autentikasi utama yang gagal.
    • [C-SR-5] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan batas atas 20 upaya autentikasi utama yang gagal. Jika pengguna mengizinkan dan memilih ikut serta dalam fitur tersebut, lakukan "Reset ke Setelan Pabrik" setelah melebihi batas upaya autentikasi utama yang gagal.

    Jika implementasi perangkat menetapkan PIN numerik sebagai metode autentikasi utama yang direkomendasikan, maka:

    • [C-SR-6] PIN SANGAT DIREKOMENDASIKAN untuk memiliki minimal 6 digit, atau setara dengan entropi 20-bit.
    • [C-SR-7] PIN dengan panjang kurang dari 6 digit SANGAT DIREKOMENDASIKAN TIDAK untuk memungkinkan entri otomatis tanpa interaksi pengguna untuk menghindari pengungkapan panjang PIN.

    Jika implementasi perangkat memiliki layar kunci yang aman dan menyertakan satu atau beberapa agen tepercaya, yang mengimplementasikan TrustAgentService System API, implementasi tersebut akan:

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

    Jika implementasi perangkat memungkinkan 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-10] HARUS menonaktifkan penginstalan aplikasi yang dimulai dari perangkat virtual.

  • 9.17. Framework Virtualisasi Android:

    Lihat revisi

    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-3] TIDAK BOLEH memodifikasi, menghilangkan, atau mengganti aturan tidak pernah ada dalam sistem/sepolicy yang disediakan di Project Open Source Android upstream (AOSP) dan kebijakan HARUS dikompilasi dengan semua aturan yang tidak diizinkan.

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

    • [C-1-5] TIDAK BOLEH mengizinkan Protected Virtual Machine pVM untuk mengeksekusi kode yang bukan bagian dari setelan pabrik atau update-nya. Apa pun yang tidak tercakup oleh Booting Terverifikasi Android (misalnya, file yang didownload dari Internet atau di-sideload) TIDAK BOLEH diizinkan untuk dijalankan di Protected Virtual Machine .

    • [C-1-5] Hanya boleh mengizinkan pVM yang tidak dapat di-debug untuk mengeksekusi kode dari image factory atau update platformnya yang juga menyertakan update apa pun untuk aplikasi dengan hak istimewa.

    Jika perangkat menerapkan dukungan untuk Android Virtualization Framework API (android.system.virtualmachine.*), semua instance Protected Virtual Machine pVM :

    • [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-4] TIDAK BOLEH memodifikasi, menghilangkan, atau mengganti aturan Neverallow yang ada dalam system/sepolicy/microdroid yang disediakan dalam Project Open Source Android upstream (AOSP).

    • [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-6-1] HARUS melakukan root DICE rantai pada titik yang tidak dapat diubah pengguna, bahkan pada perangkat yang tidak terkunci. (Untuk memastikan konten tidak boleh di-spoofing).

    • [C-SR-26-2] SANGAT DIREKOMENDASIKAN untuk menggunakan DICE sebagai mekanisme turunan rahasia per VM. HARUS DICE dengan benar, yaitu memberikan nilai yang benar.

Kembali ke atas