Catatan Rilis Definisi Kompatibilitas Android

11 April 2022

2. Jenis Perangkat

  • 2.2.1 Perangkat Keras :

    Pembaruan pada persyaratan protokol WiFi Neighbor Awareness Networking (NAN):

    Lihat revisi

    Jika perangkat mendukung protokol WiFi Neighbor Awareness Networking (NAN), maka perangkat tersebut:

    Panduan pengujian akan segera ditambahkan.

    Pembaruan persyaratan untuk perangkat kamera logis pada perangkat genggam:

    Lihat revisi

    Jika implementasi perangkat Genggam menyertakan perangkat kamera logis yang mencantumkan kemampuan menggunakan CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA , mereka:

    • [ 7.5 .4/H-1-1] HARUS memiliki bidang pandang normal (FOV) secara default dan HARUS antara 50 dan 95 derajat.

  • 2.2.7.1 Media : Pembaruan pada persyaratan Kelas Kinerja Media.

    Lihat revisi

    Jika implementasi perangkat Genggam mengembalikan android.os.Build.VERSION_CODES.T untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , maka mereka:

    • [5.6/H-1-3] HARUS mendukung >= 24-bit audio untuk keluaran stereo melalui jack audio 3,5 mm jika ada dan melalui audio USB jika didukung melalui seluruh jalur data untuk latensi rendah dan konfigurasi streaming. Untuk konfigurasi latensi rendah, AAudio harus digunakan oleh aplikasi dalam mode panggilan balik latensi rendah. Untuk konfigurasi streaming, Java AudioTrack harus digunakan oleh aplikasi. Baik dalam latensi rendah dan konfigurasi streaming, output sink 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 >=4 saluran perangkat audio USB (Ini digunakan oleh pengontrol DJ untuk mempratinjau lagu.)
    • [5.6/H-1-5] HARUS mendukung perangkat MIDI yang sesuai dengan kelas dan mendeklarasikan flag fitur MIDI.
    • [5.7/H-1-1] HARUS mendukung dekoder aman untuk setiap dekoder perangkat keras HEVC, VP9 atau AV1 pada perangkat.
    • [5.7/H-1-2] HARUS mendukung MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL dengan kemampuan dekripsi konten di bawah ini.
    Tingkat Peringkat Sumber Daya 3 - Tinggi
    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 Generik minimum 500 KiB
    Jumlah Minimum sesi bersamaan 30
    Jumlah minimum kunci per sesi 20
    Jumlah Total Kunci Minimum (semua sesi) 80
    Jumlah Total Minimum DRM Keys (semua sesi) 6
    Ukuran Pesan 16 KiB
    Bingkai Terdekripsi per Detik 60fps HD

  • 2.2.7.2 Kamera : Pembaruan pada persyaratan Kelas Performa Media terkait kamera.

    Lihat revisi

    Jika implementasi perangkat Genggam mengembalikan android.os.Build.VERSION_CODES.T untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , maka mereka:

    • [7.5/H-1-9] HARUS mendukung Bokeh, Ekstensi NightMode untuk kamera depan dan belakang utama.
    • [7.5/H-1-10] HARUS memiliki kamera utama menghadap ke belakang yang mendukung 720p atau 1080p @ 240fps.
    • [7.5/H-1-11] 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-12] HARUS menerapkan streaming depan-belakang secara bersamaan pada kamera utama.
    • [7.5/H-1-13] HARUS mendukung CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION untuk kamera depan utama dan belakang utama.
    • [7.5/H-1-14] 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-15] HARUS mendukung kemampuan STREAM_USE_CASE untuk kamera depan dan belakang utama.

3. Perangkat Lunak

  • 3.5.1 Batasan Aplikasi : Perubahan persyaratan pembatasan aplikasi.

    Lihat revisi

    Jika implementasi perangkat menerapkan mekanisme kepemilikan untuk membatasi aplikasi (misalnya mengubah atau membatasi perilaku API yang dijelaskan dalam SDK) dan mekanisme tersebut lebih membatasi daripada Bucket Siaga Aplikasi yang Dibatasi , mereka:

    • [C-1-10] HARUS mendapatkan persetujuan pengguna yang eksplisit atas pembatasan apa pun yang diberlakukan untuk aplikasi yang menjalankan layanan latar depan. Sebaliknya, TIDAK HARUS memberlakukan batasan apa pun untuk aplikasi yang menjalankan layanan latar depan tanpa persetujuan pengguna.

    • [C-1-11] HARUS mendapatkan persetujuan pengguna secara eksplisit jika pembatasan latar belakang diterapkan. Persetujuan tersebut HARUS diperoleh dalam waktu 24 jam sebelum pembatasan tersebut diterapkan.

    • [C-1-12] HARUS menampilkan peringatan pengguna bahwa aplikasi dapat berperilaku tidak semestinya dan mendapatkan persetujuan pengguna yang eksplisit jika pembatasan tersebut adalah untuk menghentikan aplikasi secara paksa. Persetujuan tersebut HARUS diperoleh dalam waktu 24 jam sebelum pembatasan tersebut diterapkan.

      • [SR] SANGAT DIREKOMENDASIKAN untuk tidak membatasi aplikasi dengan menghentikannya secara paksa. Persyaratan ini diharapkan menjadi HARUS di versi Android berikutnya.

    • [C-1-13] Jika mereka mengecualikan aplikasi yang dapat diinstal pengguna dari pembatasan kepemilikan, mereka HARUS menyediakan dokumen atau situs web publik dan jelas yang menjelaskan cara meminta untuk ikut serta dalam pengecualian tersebut. Dokumen atau situs web ini HARUS dapat ditautkan dari dokumen Android SDK.

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

  • 3.8.3.1 Penyajian notifikasi : Melonggarkan beberapa parameter yang sebelumnya diperlukan untuk notifikasi pihak ketiga (kembali ke rekomendasi).

    Lihat revisi

    Jika implementasi perangkat memungkinkan aplikasi pihak ketiga memberi tahu pengguna tentang peristiwa penting , mereka:

    • [C-1-8] HARUS [C-SR] SANGAT DIREKOMENDASIKAN memberikan kemampuan bagi pengguna untuk mengontrol notifikasi yang diekspos ke aplikasi yang telah diberikan izin Notification Listener. Perincian HARUS agar pengguna dapat mengontrol untuk setiap pendengar pemberitahuan tersebut jenis pemberitahuan apa yang dijembatani ke pendengar ini. Jenis HARUS menyertakan pemberitahuan "percakapan", "peringatan", "diam", dan "penting yang sedang berlangsung".
    • [C-1-9] HARUS [C-SR] SANGAT DIREKOMENDASIKAN memberikan kemampuan bagi pengguna untuk menentukan aplikasi yang dikecualikan agar tidak memberi tahu pendengar pemberitahuan tertentu.

5. Kompatibilitas Multimedia

6. Alat Pengembang dan Kompatibilitas Opsi

  • 6.1 Alat Pengembang : Pembaruan persyaratan untuk informasi kerja GPU.

    Lihat revisi

    informasi kerja GPU

    Implementasi perangkat:

    • [C-6-1] HARUS mengimplementasikan perintah shell dumpsys gpu --gpuwork untuk menampilkan data kerja GPU teragregasi yang dikembalikan oleh titik jejak kernel power/gpu_work_period gpu_work_period, atau tidak menampilkan data jika titik jejak tidak didukung. Implementasi AOSP adalah frameworks/native/services/gpuservice/gpuwork/ .

7. Kompatibilitas Perangkat Keras

  • 7.1.4.1 OpenGL ES : Menambahkan rekomendasi untuk perangkat yang mendukung OpenGL ES.

    Lihat revisi

    Jika implementasi perangkat mendukung salah satu versi OpenGL ES, mereka:

    • HARUS mendukung EGL_IMG_context_priority dan EGL_EXT_protected_content .

  • 7.2.3 Tombol Navigasi : Klarifikasi persyaratan untuk bilah navigasi.

    Lihat revisi

    Jika implementasi perangkat memberikan dukungan untuk API sistem setNavBarMode untuk mengizinkan aplikasi sistem apa pun dengan izin android.permission.STATUS_BAR untuk menyetel mode bilah navigasi, maka implementasi tersebut:

    • [C-9-1] HARUS memberikan dukungan untuk ikon ramah anak atau navigasi berbasis tombol seperti yang disediakan dalam kode AOSP.

  • 7.4.2.5. Lokasi Wi-Fi (Waktu Pulang Pergi Wi-Fi - RTT) : Pembaruan persyaratan akurasi lokasi Wi-Fi.

    Lihat revisi

    Jika implementasi perangkat menyertakan dukungan untuk Lokasi Wi-Fi dan mengekspos fungsionalitas ke aplikasi pihak ketiga, maka implementasi tersebut:

    • [C-1-4] HARUS akurat dalam jarak 2 meter pada bandwidth 80 MHz pada persentil ke-68 (sebagaimana dihitung dengan Fungsi Distribusi Kumulatif).
    • [C-SR] SANGAT DIREKOMENDASIKAN untuk melaporkannya secara akurat dalam jarak 1,5 meter pada bandwidth 80 MHz pada persentil ke-68 (sebagaimana dihitung dengan Fungsi Distribusi Kumulatif).

  • 7.4.2.6. Wi-Fi / Seluler NAT-T Keepalive Offload : Pembaruan persyaratan slot Wi-Fi / Seluler keepalive.

    Lihat revisi

    Jika implementasi perangkat menyertakan dukungan untuk Wi-Fi keepalive offload atau Cellular keepalive offload dan memaparkan fungsionalitas ke aplikasi pihak ketiga, mereka:

    • [C-1-3] HARUS mendukung slot keepalive seluler bersamaan sebanyak yang didukung oleh Radio Seluler HAL.
    • [C-SR] SANGAT DIREKOMENDASIKAN untuk mendukung setidaknya tiga slot keepalive seluler.

  • 7.4.2.9 Trust on First Use (TOFU) : Pembaruan pada persyaratan jaringan Wi-Fi Perusahaan untuk TOFU.

    Lihat revisi

    Jika implementasi perangkat mendukung Trust pada penggunaan pertama (TOFU), maka mereka:

    • [C-4-1] TIDAK HARUS memberikan opsi kepada pengguna untuk menambahkan jaringan Wi-Fi Perusahaan berbasis TLS secara manual jika sertifikat server Wi-Fi tidak dikonfigurasi atau nama domain server Wi-Fi tidak disetel.

    • [C-4-1] HARUS memberikan opsi kepada pengguna untuk memilih menggunakan TOFU.

  • 7.4.3 Bluetooth : Pembaruan persyaratan saat menggunakan Bluetooth LE untuk menentukan kedekatan dengan perangkat lain.

    Lihat revisi

    Jika implementasi perangkat mendukung Bluetooth LE dan menggunakan Bluetooth LE untuk pemindaian lokasi guna menentukan kedekatan dengan perangkat lain, mereka:

    • [C-10-1] HARUS memiliki pengukuran RSSI dalam +/-6dBm untuk 95% pengukuran pada jarak 1m dari perangkat referensi yang mentransmisikan pada ADVERTISE_TX_POWER_HIGH dalam lingkungan garis pandang.
    • [C-10-2] HARUS menyertakan koreksi Rx/Tx untuk mengurangi penyimpangan per saluran sehingga pengukuran pada masing-masing dari 3 saluran, pada masing-masing antena (jika digunakan ganda), berada dalam +/-3dBm dari satu lain untuk 95% dari pengukuran.
    • [C-10-3] HARUS mengukur dan mengkompensasi offset Rx untuk memastikan median BLE RSSI adalah -60dBm +/-3 dBm pada jarak 1m dari perangkat referensi yang mentransmisikan pada ADVERTISE_TX_POWER_HIGH , di mana perangkat diorientasikan sedemikian rupa sehingga berada pada 'paralel pesawat 'dengan layar menghadap ke arah yang sama.
    • [C-10-4] HARUS mengukur dan mengkompensasi offset Tx untuk memastikan median BLE RSSI adalah -60dBm +/-3 dBm saat memindai dari perangkat referensi yang diposisikan pada jarak 1m dan mentransmisikan pada ADVERTISE_TX_POWER_HIGH , di mana perangkat diorientasikan sedemikian rupa sehingga mereka berada di 'bidang paralel' dengan layar menghadap ke arah yang sama.

  • 7.4.9 UWB : Klarifikasi persyaratan untuk perangkat yang menyertakan perangkat keras UWB.

    Lihat revisi

    Jika implementasi perangkat menyertakan perangkat keras UWB, maka mereka:

    • [C-1-1] HARUS memastikan pengukuran jarak dalam +/-10cm dan sudut pengukuran kedatangan (jika didukung) berada dalam +/-5 derajat (dalam +/-60 derajat azimuth dari pusat) untuk 95% dari pengukuran di lingkungan garis pandang.
    • [C-1-2] HARUS menerapkan koreksi sehingga median pengukuran pada 10cm dari perangkat referensi sama dengan 10cm +/- 2cm, di mana jarak ground truth diukur dari antena ke antena.

    • [C-1-3 ]HARUS memiliki pengukuran yang sesuai dengan garis tren dengan bias 0 dan kemiringan 1 untuk titik 1m, 3m, dan 5m.

  • 7.5 Kamera : Pembaruan persyaratan dan rekomendasi untuk kemampuan output HDR 10-bit.

    Lihat revisi

    Jika implementasi perangkat mendukung kemampuan output HDR 10-bit, maka mereka:

    • [C-2-2] HARUS mendukung output 10-bit untuk kamera hadap belakang utama atau kamera hadap depan utama.
    • [C-SR] SANGAT DIREKOMENDASIKAN untuk mendukung output 10-bit untuk kedua kamera utama.

8. Performa dan Kekuatan

  • 8.3 Mode Hemat Daya : Klarifikasi ke aplikasi yang dianggap DIBATASI untuk tujuan hemat daya.

    Lihat revisi

    Jika implementasi perangkat menyertakan fitur untuk meningkatkan manajemen daya perangkat yang disertakan dalam AOSP (mis. App Standby Bucket, Doze) atau memperluas fitur untuk menerapkan batasan yang lebih kuat daripada App Standby Bucket RESTRICTED , mereka:

    • [C-1-4] HARUS menerapkan Bucket dan Istirahatkan Aplikasi seperti yang dijelaskan dalam Manajemen Daya .

      Mulai persyaratan baru untuk T (eksperimental AOSP)

      1) Aplikasi ditempatkan di keranjang TERBATAS hanya jika aplikasi tidak digunakan oleh pengguna selama lebih dari 4 jam.

      2) Aplikasi ditempatkan di keranjang TERBATAS hanya jika aplikasi terbukti berdampak signifikan terhadap kesehatan sistem, seperti aplikasi menghabiskan lebih dari 0,1% dari kapasitas baterai yang terisi penuh.

14 Maret 2022

3. Perangkat Lunak

  • 3.8.1 Peluncur (Layar Utama) : Klarifikasi persyaratan baru untuk perangkat yang mendukung monochrome/adaptive-icon .

    Lihat revisi

    Jika implementasi perangkat mendukung monochrome/adaptive-icon , ikon-ikon ini:

    • [C-6-1] HARUS digunakan hanya jika pengguna secara eksplisit mengaktifkannya (mis. melalui Pengaturan atau menu pemilih wallpaper).
    • [C-6-2] TIDAK HARUS mengganti lencana ikon aplikasi dengan skema lencana berpemilik kecuali aplikasi yang terkait dengan ikon aplikasi tersebut menunjukkan dukungan skema lencana berpemilik melalui penggunaan API berpemilik.

  • 3.8.18 Tema Gelap : Klarifikasi persyaratan baru untuk perangkat yang mendukung tema gelap.

    Lihat revisi

    3.8.18.Tema Gelap

    Jika implementasi perangkat mendukung API Sistem UiModeManager.setNightModeCustomType(@NightModeCustomType int nightModeCustomType) dan UiModeManager.setNightModeActivatedForCustomMode(@NightModeCustomType int nightModeCustomType, boolean active) untuk memberikan dukungan bagi tema gelap, maka mereka:

    • [C-1-1] HARUS memberikan keterjangkauan pengguna dalam pengaturan sistem yang memungkinkan pengguna untuk mengikat tema gelap ke jadwal khusus. AOSP memenuhi persyaratan ini dan memberikan kemampuan pengguna default di aplikasi pengaturan sistem untuk mengaktifkan tema gelap pada waktu khusus atau menyalakannya dari matahari terbenam hingga matahari terbit atau tidak mengikuti jadwal apa pun.

  • 3.9.1.1 Penyediaan Pemilik Perangkat : Pembaruan persyaratan untuk perangkat yang menyediakan pemilik perangkat.

    Lihat revisi

    Jika implementasi perangkat mendeklarasikan android.software.device_admin , mereka:

    • [C-1-1] HARUS mendukung pendaftaran Device Policy Client (DPC) sebagai aplikasi Pemilik Perangkat seperti yang dijelaskan di bawah ini:
      • Ketika implementasi perangkat tidak memiliki pengguna atau data pengguna yang dikonfigurasi, itu:
        • [C-1-5] HARUS mendaftarkan aplikasi DPC sebagai aplikasi Device Owner atau mengaktifkan aplikasi DPC untuk memilih menjadi Device Owner atau Profile Owner, jika perangkat menyatakan dukungan Near-Field Communications (NFC) melalui fitur tersebut menandai android.hardware.nfc dan menerima pesan NFC yang berisi catatan dengan tipe MIME MIME_TYPE_PROVISIONING_NFC .
        • [C-1-8] HARUS mengirim maksud ACTION_GET_PROVISIONING_MODE setelah penyediaan pemilik perangkat dipicu sehingga aplikasi DPC dapat memilih apakah akan menjadi Pemilik Perangkat atau Pemilik Profil, bergantung pada nilai android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES , kecuali dapat ditentukan dari konteks bahwa hanya ada satu pilihan yang valid. (seperti untuk penyediaan berbasis NFC di mana penyediaan Pemilik Profil tidak didukung).
        • [C-1-9] HARUS mengirim maksud ACTION_ADMIN_POLICY_COMPLIANCE ke aplikasi Pemilik Perangkat jika Pemilik Perangkat dibuat selama penyediaan terlepas dari metode penyediaan yang digunakan. Pengguna tidak boleh melanjutkan di Wizard Penyiapan hingga aplikasi Pemilik Perangkat selesai.
      • Ketika implementasi perangkat memiliki pengguna atau data pengguna, itu:
        • [C-1-7] TIDAK HARUS mendaftarkan aplikasi DPC apa pun sebagai Aplikasi Pemilik Perangkat lagi.
    • [C-1-2] HARUS menunjukkan pemberitahuan pengungkapan yang sesuai (seperti yang dirujuk dalam AOSP ) dan mendapatkan persetujuan afirmatif dari pengguna akhir sebelum aplikasi ditetapkan sebagai Pemilik Perangkat, kecuali perangkat dikonfigurasikan secara terprogram untuk Mode Demo Ritel sebelum di layar, interaksi pengguna akhir. memerlukan beberapa tindakan afirmatif sebelum atau selama proses penyediaan untuk menyetujui aplikasi yang ditetapkan sebagai Pemilik Perangkat. Persetujuan dapat melalui tindakan pengguna atau dengan beberapa cara terprogram tetapi pemberitahuan pengungkapan yang sesuai (seperti yang dirujuk dalam AOSP) HARUS ditunjukkan sebelum penyediaan pemilik perangkat dimulai. Selain itu, mekanisme persetujuan pemilik perangkat terprogram yang digunakan (oleh perusahaan) untuk penyediaan pemilik perangkat TIDAK HARUS mengganggu Pengalaman Out-Of-Box untuk penggunaan non-perusahaan.
    • [C-1-3] TIDAK HARUS membuat hard code persetujuan atau mencegah penggunaan aplikasi pemilik perangkat lain.

  • 3.9.4 Persyaratan Peran Manajemen Kebijakan Perangkat : Revisi ke bagian Persyaratan Peran Manajemen Kebijakan Perangkat yang baru ditambahkan.

    Lihat revisi

    3.9.4 Persyaratan Peran Manajemen Kebijakan Perangkat

    • [C-1-1] HARUS mendukung peran manajemen kebijakan perangkat seperti yang didefinisikan di bagian 9.1 . Aplikasi yang memegang peran manajemen kebijakan perangkat MUNGKIN ditentukan dengan menyetel config_devicePolicyManagement ke nama paket. Nama paket HARUS diikuti oleh : dan sertifikat penandatanganan kecuali aplikasi dimuat sebelumnya.

    Jika nama paket tidak ditentukan untuk config_devicePolicyManagement seperti yang dijelaskan di atas:

    Jika nama paket didefinisikan untuk config_devicePolicyManagement seperti yang dijelaskan di atas:

    • [C-3-1] Aplikasi HARUS diinstal pada semua profil untuk pengguna .
    • [C-3-2] Implementasi perangkat MUNGKIN menentukan aplikasi yang memperbarui pemegang peran manajemen kebijakan perangkat sebelum menyediakan dengan menyetel config_devicePolicyManagementUpdater .

    Jika nama paket ditentukan untuk config_devicePolicyManagementUpdater seperti dijelaskan di atas:

    • [C-4-1] Aplikasi HARUS diinstal sebelumnya pada perangkat.
    • [C-4-2] Aplikasi HARUS menerapkan filter maksud yang menyelesaikan android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER .

5. Kompatibilitas Multimedia

  • 5.5.4 Audio Offload : Klarifikasi rekomendasi untuk memangkas konten audio gapless.

    Lihat revisi

    Jika implementasi perangkat mendukung pemutaran audio offload , mereka:

    • [C-SR] SANGAT DIREKOMENDASIKAN untuk memangkas konten audio tanpa celah yang diputar antara dua klip dengan format yang sama bila ditentukan oleh API tanpa celah AudioTrack dan wadah media untuk MediaPlayer.

7. Kompatibilitas Perangkat Keras

  • 7.5 Kamera : Pembaruan persyaratan untuk perangkat yang mendukung kemampuan output HDR 10-bit.

    Lihat revisi

    Jika implementasi perangkat mendukung kemampuan output HDR 10-bit, maka mereka:

    • [C-2-1] HARUS mendukung setidaknya profil HLG HDR untuk setiap perangkat kamera yang mendukung output 10-bit.
    • [C-2-2] HARUS mendukung output 10-bit untuk kamera depan utama dan kamera depan utama.
    • [C-2-3] HARUS mendukung profil HDR yang sama untuk semua sub-kamera fisik berkemampuan BACKWARD_COMPATIBLE dari kamera logis, dan kamera logis itu sendiri.
    • [C-2-3] HARUS mendukung kualitas gambar keseluruhan berdasarkan pengaturan pengambilan yang diminta aplikasi dan kasus penggunaan output yang ditentukan aplikasi dan BUKAN pada tujuan output itu.

28 Februari 2022

5. Kompatibilitas Multimedia

  • 5.10 Audio Profesional : Mengoreksi ambang latensi.

    Lihat revisi

    Jika implementasi perangkat melaporkan dukungan untuk fitur android.hardware.audio.pro melalui kelas android.content.pm.PackageManager , mereka:

    • [C-1-2] HARUS memiliki latensi audio bolak-balik berkelanjutan, seperti yang didefinisikan di bagian 5.6 Audio Latency dari 25 250 milidetik atau kurang selama setidaknya satu jalur yang didukung.

7. Kompatibilitas Perangkat Keras

  • 7.4.1 Telepon : Persyaratan tambahan mengenai konfirmasi pengguna eksplisit untuk perilaku tertentu dalam aplikasi operator aktif.

    Lihat revisi

    Jika implementasi perangkat termasuk telepon GSM atau CDMA, maka:

    • [C-6-10] TIDAK HARUS menerapkan perilaku berikut ke aplikasi operator aktif (sebagaimana ditentukan oleh TelephonyManager#getCarrierServicePackageName ) secara otomatis atau tanpa konfirmasi pengguna yang eksplisit:
      • Cabut atau batasi akses jaringan
      • Cabut izin
      • Batasi eksekusi aplikasi latar belakang atau latar depan di luar fitur manajemen daya yang ada yang disertakan dalam AOSP
      • Nonaktifkan atau hapus instalan aplikasi

  • 7.4.3 Bluetooth : Pembaruan persyaratan Bluetooth sebagai berikut.

    • Mengklarifikasi persyaratan dan rekomendasi untuk klien unicast HAP.

      Lihat revisi

      Jika implementasi perangkat mengembalikan true untuk BluetoothAdapter.isLeAudioSupported() API, maka implementasi tersebut:

      • [C-7-5] HARUS mengaktifkan BAP /TERJADI klien unicast, koordinator set CSIP, server MCP,
      • [C-SR] SANGAT DIREKOMENDASIKAN untuk mengaktifkan klien unicast HAP.

    • Memperbarui ambang batas RSSI BLE median.

      Lihat revisi

      Jika implementasi perangkat mendukung Bluetooth LE dan menggunakan Bluetooth LE untuk pemindaian lokasi guna menentukan kedekatan dengan perangkat lain, mereka:

      • [C-10-3] HARUS menyertakan kalibrasi Rx untuk memastikan median BLE RSSI adalah -60dB -69dB pada jarak 1m dari perangkat referensi yang mentransmisikan pada ADVERTISE_TX_POWER_HIGH .
      • [C-10-4] HARUS menyertakan kalibrasi Tx untuk memastikan median BLE RSSI adalah -60dB -69dB saat memindai dari perangkat referensi yang diposisikan pada jarak 1m dan mentransmisikan pada ADVERTISE_TX_POWER_HIGH .

9. Kompatibilitas Model Keamanan

  • 9.11.2 Strongbox : Mengembalikan persyaratan C-1-12 kembali ke rekomendasi kuat.

    Lihat revisi

    • [C-1-12] HARUS [C-SR] SANGAT DIREKOMENDASIKAN untuk memberikan insider attack resistance (IAR), yang berarti bahwa orang dalam dengan akses ke kunci penandatanganan firmware tidak dapat menghasilkan firmware yang menyebabkan StrongBox membocorkan rahasia, melewati persyaratan keamanan fungsional, atau mengaktifkan akses ke data sensitif data pengguna. Cara yang disarankan untuk menerapkan IAR adalah dengan mengizinkan pembaruan firmware hanya jika kata sandi pengguna utama diberikan melalui IAuthSecret HAL. IAR akan menjadi persyaratan HARUS di Android U (AOSP eksperimental).

14 Februari 2022

2. Jenis Perangkat

  • 2.2.1 Perangkat Keras : Perubahan kebutuhan perangkat keras sebagai berikut.

    • Latensi audio:

      Lihat revisi

      • [ 5.6 /H-1-1] HARUS memiliki Latensi Pulang Pergi Berkelanjutan Rata-rata 500 800 milidetik atau kurang selama 5 pengukuran, dengan Deviasi Mutlak Rata-rata kurang dari 50 100 ms, melalui jalur data berikut: "speaker ke mikrofon", adaptor loopback 3,5 mm (jika didukung), loopback USB (jika didukung). setidaknya satu jalur yang didukung.

      • [ 5.6 /H-1-1] HARUS memiliki latensi Ketuk-ke-nada rata-rata 500 milidetik atau kurang selama setidaknya 5 pengukuran melalui jalur data speaker ke mikrofon.

    • Perangkat masukan:

      Lihat revisi

      Implementasi perangkat genggam:

      • [ 7.2 .3/H-0-5] HARUS memanggil OnBackInvokedCallback.onBackStarted() pada jendela fokus saat ini ketika gerakan kembali dimulai atau tombol kembali (KEYCODE_BACK) ditekan BAWAH.
      • [ 7.2 .3/H-0-6] HARUS memanggil OnBackInvokedCallback.onBackInvoked() ketika gerakan kembali dilakukan atau tombol Kembali dilepaskan (UP).
      • [ 7.2 .3/H-0-7] HARUS memanggil OnBackInvokedCallback.onBackCancelled() ketika gerakan kembali tidak dilakukan atau acara KEYCODE_BACK dibatalkan.

      Jika implementasi perangkat menegaskan WifiRttManager.isAvailable() , maka mereka:

      Panduan pengujian akan segera ditambahkan.

    • Masukan haptik:

      Lihat revisi

      Jika implementasi perangkat Genggam menyertakan setidaknya satu aktuator haptic, mereka:

      Jika implementasi perangkat Genggam mencakup setidaknya satu aktuator resonansi linier, mereka:

      • [ 7.10 /H]* HARUS memindahkan aktuator haptik dalam sumbu X (kiri-kanan) dari orientasi potret.

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

      • [7.10/H]* HARUS memberikan dukungan mundur untuk mengurangi risiko kegagalan seperti yang dijelaskan di sini .

  • 2.2.3 Perangkat Lunak :

    • Pemberitahuan MediaStyle:

      Lihat revisi

      Jika implementasi perangkat Genggam mendukung pemberitahuan MediaStyle , mereka:

      • HARUS memberikan keterjangkauan pengguna ("pengalih keluaran") di UI sistem yang memungkinkan pengguna untuk beralih di antara keluaran media saat aplikasi memposting pemberitahuan MediaStyle dengan token MediaSession .
      • HARUS menggunakan MediaRouter2Manager dan Bluetooth API untuk menampilkan (dan mengizinkan peralihan antara) rute media yang tersedia yang mencakup rute Cast dan Bluetooth.

    • Kontrol Perangkat Trivial Auth:

      Lihat revisi

      • [ 3.8 .16/H-1-5] HARUS memberikan kemampuan kepada pengguna untuk memilih keluar dari kontrol perangkat auth-trivial yang ditunjuk aplikasi dari kontrol yang didaftarkan oleh aplikasi pihak ketiga melalui ControlsProviderService dan Control Control.isAuthRequired API.

  • 2.2.5 Model Keamanan : Perbarui ke jalur akses mikrofon.

    Lihat revisi

    Jika implementasi perangkat Genggam mendeklarasikan android.hardware.microphone , mereka:

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

  • 2.2.7.1 Media : Pembaruan pada bagian Media Persyaratan Genggam sebagai berikut:

    • Pembaruan Kelas Kinerja Media:

      Lihat revisi

      Jika implementasi perangkat Genggam mengembalikan android.os.Build.VERSION_CODES.T untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , maka mereka:

      • [5.1/H-1-1] HARUS mengiklankan jumlah maksimum sesi dekoder video perangkat keras yang dapat dijalankan secara bersamaan dalam kombinasi codec apa pun melalui metode CodecCapabilities.getMaxSupportedInstances() dan VideoCapabilities.getSupportedPerformancePoints() .
      • [5.1/H-1-2] HARUS mendukung 6 contoh sesi dekoder video perangkat keras (AVC, HEVC, VP9, ​​AV1 atau lebih baru) dalam kombinasi codec apa pun yang berjalan secara bersamaan pada resolusi 1080p@30 fps.
      • [5.1/H-1-3] HARUS mengiklankan jumlah maksimum sesi encoder video perangkat keras yang dapat dijalankan secara bersamaan dalam kombinasi codec apa pun melalui metode CodecCapabilities.getMaxSupportedInstances() dan VideoCapabilities.getSupportedPerformancePoints() .
      • [5.1/H-1-4] HARUS mendukung 6 sesi sesi encoder video perangkat keras (AVC, HEVC, VP9, ​​AV1 atau yang lebih baru) dalam kombinasi codec apa pun yang berjalan secara bersamaan pada resolusi 1080p@30fps.
      • [5.1/H-1-5] HARUS mengiklankan jumlah maksimum sesi encoder dan decoder video perangkat keras yang dapat dijalankan secara bersamaan dalam kombinasi codec apa pun melalui metode CodecCapabilities.getMaxSupportedInstances() dan VideoCapabilities.getSupportedPerformancePoints() .
      • [5.1/H-1-6] HARUS mendukung 6 instans dekoder video perangkat keras dan sesi encoder video perangkat keras (AVC, HEVC, VP9, ​​AV1 atau lebih baru) dalam kombinasi codec apa pun yang berjalan secara bersamaan pada resolusi 1080p@30fps.
      • [5.1/H-1-7] HARUS memiliki latensi inisialisasi codec 40 ms atau kurang untuk sesi encoding video 1080p atau lebih kecil untuk semua encoder video perangkat keras saat sedang dimuat. Muat di sini didefinisikan sebagai sesi transcoding video saja 1080p ke 720p bersamaan menggunakan codec video perangkat keras bersama dengan inisialisasi perekaman audio-video 1080p.
      • [5.1/H-1-8] HARUS memiliki latensi inisialisasi codec 30 ms atau kurang untuk sesi encoding audio 128 kbps atau bitrate lebih rendah untuk semua encoder audio saat dimuat. Muat di sini didefinisikan sebagai sesi transcoding video saja 1080p ke 720p bersamaan menggunakan codec video perangkat keras bersama dengan inisialisasi perekaman audio-video 1080p.
      • [5.1/H-1-9] HARUS mendukung 2 contoh sesi dekoder video perangkat keras yang aman (AVC, HEVC, VP9, ​​AV1 atau yang lebih baru) dalam kombinasi codec apa pun yang berjalan secara bersamaan pada resolusi 1080p@30 fps.
      • [5.1/H-1-10] HARUS mendukung 3 instans sesi dekoder video perangkat keras yang tidak aman bersama dengan 1 sesi dekoder video perangkat keras yang aman (total 4 instans) (AVC, HEVC, VP9, ​​AV1 atau lebih baru) di codec apa pun kombinasi berjalan secara bersamaan pada resolusi 1080p@30fps.
      • [5.1/ H-1-11] HARUS mendukung dekoder aman untuk setiap dekoder video tidak aman yang didukung (AVC, HEVC, VP9, ​​AV1 atau lebih baru).
      • [5.1/H-1-12] HARUS memiliki latensi inisialisasi dekoder video 40 ms atau kurang.
      • [5.1/H-1-13] HARUS memiliki latensi inisialisasi dekoder audio 30 ms atau kurang.
      • [5.1/H-1-14] HARUS mendukung dekoder perangkat keras AV1 Main 10, Level 4.1, Film Grain.
      • [5.1/H-1-15] HARUS memiliki setidaknya 1 dekoder video perangkat keras yang mendukung 4K60.
      • [5.1/H-1-16] HARUS memiliki setidaknya 1 encoder video perangkat keras yang mendukung 4K60.
      • [5.3/H-1-1] TIDAK HARUS menjatuhkan lebih dari 1 bingkai dalam 10 detik (yaitu kurang dari 0,167 persen penurunan bingkai) untuk sesi video 1080p 60 fps di bawah beban. Beban didefinisikan sebagai sesi transcoding video saja 1080p hingga 720p secara bersamaan menggunakan codec video perangkat keras, serta pemutaran audio AAC 128 kbps.
      • [5.3/H-1-2] TIDAK HARUS menjatuhkan lebih dari 1 frame dalam 10 detik selama perubahan resolusi video dalam sesi video 60 fps di bawah beban. Load is defined as a concurrent 1080p to 720p video-only transcoding session using hardware video codecs, as well as a 128 kbps AAC audio playback.
      • [5.6/H-1-1] MUST have a tap-to-tone latency of 80 milliseconds or less using the OboeTester tap-to-tone test or CTS Verifier tap-to-tone test.
      • [5.6/H-1-2] MUST have a round-trip audio latency of 80 milliseconds or less over at least one supported data path.
      • [5.6/H-1-3] MUST support >=24-bit audio output over 3.5 mm audio jacks if present and over USB audio if supported through the entire data path for low latency and streaming configurations. For the low latency configuration, AAudio should be used in low-latency callback mode with AAUDIO_FORMAT_PCM_FLOAT . For the streaming configuration, a Java AudioTrack should be used with one of the high resolution formats, ie AUDIO_FORMAT_PCM_24_BIT , AUDIO_FORMAT_PCM_24_BIT_PACKED , AUDIO_FORMAT_PCM_32_BIT or AUDIO_FORMAT_PCM_FLOAT . In both the low latency and streaming configurations, the HAL output sink should accept one of those high-resolution formats for its target output format.
      • [5.6/H-1-4] MUST support >=4 channel USB audio devices (This is used by DJ controllers for previewing songs.)
      • [5.6/H-1-5] MUST support class compliant MIDI devices and declare the MIDI feature flag.
      • [5.7/ H-1-1] MUST support Widevine L1 OEMCrypto Tier 3.
      • [5.7/H-1-2] MUST support Widevine CDM version 17.x
      • [5.7/H-1-3] MUST support OEMCrypto version 17.x

      • [5.7/H-1-4] MUST support a secure decoder for every hardware HEVC, VP9 or AV1 hardware decoder on the device.

  • 2.2.7.2 Camera : Updates to the Media Performance Class Camera requirements.

    See revision

    If Handheld device implementations return android.os.Build.VERSION_CODES.T for android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , then they:

    • [7.5/H-1-1] MUST have a primary rear facing camera with a resolution of at least 12 megapixels supporting video capture at 4k@30fps. The primary rear-facing camera is the rear-facing camera with the lowest camera ID.
    • [7.5/H-1-2] MUST have a primary front facing camera with a resolution of at least 5 megapixels and support video capture at 1080p@30fps. The primary front-facing camera is the front-facing camera with the lowest camera ID.
    • [7.5/H-1-3] MUST support android.info.supportedHardwareLevel property as FULL or better for both primary cameras.
    • [7.5/H-1-4] MUST support CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME for both primary cameras.
    • [7.5/H-1-5] MUST have camera2 JPEG capture latency < 1000 ms for 1080p resolution as measured by the CTS camera PerformanceTest under ITS lighting conditions (3000K) for both primary cameras.
    • [7.5/H-1-6] MUST have camera2 startup latency (open camera to first preview frame) < 500 ms as measured by the CTS camera PerformanceTest under ITS lighting conditions (3000K) for both primary cameras.
    • [7.5/H-1-8] MUST support CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW and android.graphics.ImageFormat.RAW_SENSOR for the primary back camera.
    • [7.5/H-1-9] MUST support Bokeh, NightMode Extensions.
    • [7.5/H-1-10] MUST have a rear facing camera supporting 720p or 1080p @ 240fps.
    • [7.5/H-1-11] MUST have min ZOOM_RATIO < 1.0 if there is an ultrawide camera.
    • [7.5/H-1-12] Must implement concurrent front-back streaming.
    • [7.5/H-1-13] MUST support CONTROL_VIDEO_STABILIZATION_MODE_ON_PREVIEW if CONTROL_VIDEO_STABILIZATION_MODE_ON is supported.
    • [7.5/H-1-14] MUST support LOGICAL_MULTI_CAMERA if there are greater than 1 RGB cameras per facing.
    • [7.5/H-1-15] MUST support 10 Bit HDR video recording.
    • [7.5/H-1-16] MUST support STREAM_USE_CASE capability.

  • 2.2.7.3 Hardware : Updates to the Media Performance Class requirements for Hardware.

    See revision

    If Handheld device implementations return android.os.Build.VERSION_CODES.T for android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , then they:

    • [7.1.1.1/H-2-1] MUST have screen resolution of at least 1080p.
    • [7.1.1.3/H-2-1] MUST have screen density of at least 400 dpi.
    • [7.6.1/H-2-1] MUST have at least 8 GB of physical memory.

  • 2.2.7.4 Performance : Updates to the Media Performance Class for Performance.

    See revision

    If Handheld device implementations return android.os.Build.VERSION_CODES.T for android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , then they:

    • [8.2/H-1-1] MUST ensure a sequential write performance of at least 125 MB/s.
    • [8.2/H-1-2] MUST ensure a random write performance of at least 10 MB/s.
    • [8.2/H-1-3] MUST ensure a sequential read performance of at least 250 MB/s.
    • [8.2/H-1-4] MUST ensure a random read performance of at least 40 MB/s.

  • 2.5.1 Hardware : Updates to the 3-axis accelerometer and 3-axis gyroscope requirements, as well as the exterior-view camera requirements.

    See revision

    Automotive device implementations:

    • [ 7.3 .1/A-0-4] MUST comply with the Android car sensor coordinate system .
    • [ 7.3 /A-SR] Are STRONGLY_RECOMMENDED to include a 3-axis accelerometer and 3-axis gyroscope.
    • [ 7.3 /A-SR] Are STRONGLY_RECOMMENDED to implement and report TYPE_HEADING sensor.

    If Automotive device implementations include an accelerometer, they:

    • [ 7.3 .1/A-1-1] MUST be able to report events up to a frequency of at least 100 Hz.

    If device implementations include a 3-axis accelerometer, they:

    • [ 7.3 .1/A-SR] Are STRONGLY RECOMMENDED to implement the composite sensor for limited axes accelerometer.

    If Automotive device implementations include an accelerometer with less than 3 axes, they:

    • [ 7.3 .1/A-1-3] MUST implement and report TYPE_ACCELEROMETER_LIMITED_AXES sensor.
    • [ 7.3 .1/A-1-4] MUST implement and report TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED sensor.

    If Automotive device implementations include a gyroscope, they:

    • [ 7.3 .4/A-2-1] MUST be able to report events up to a frequency of at least 100 Hz.
    • [ 7.3 .4/A-2-3] MUST be capable of measuring orientation changes up to 250 degrees per second.
    • [ 7.3 .4/A-SR] Are STRONGLY RECOMMENDED to configure the gyroscope's measurement range to +/-250dps in order to maximize the resolution possible.

    If Automotive device implementations include a 3-axis gyroscope, they:

    • [ 7.3 .4/A-SR] Are STRONGLY RECOMMENDED to implement the composite sensor for limited axes gyroscope.

    If Automotive device implementations include a gyroscope with less than 3-axes, they:

    • [ 7.3 .4/A-4-1] MUST implement and report TYPE_GYROSCOPE_LIMITED_AXES sensor.
    • [ 7.3 .4/A-4-2] MUST implement and report TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED sensor.

    If automotive device implementations include a TYPE_HEADING sensor, they:

    • [ 7.3 .4/A-4-3] MUST be able to report events up to a frequency of at least 1 Hz.
    • [ 7.3 .4/A-SR] STRONGLY_RECOMMENDED to report events up to a frequency of at least 10 Hz.
    • SHOULD be in reference to true north.
    • SHOULD be available even when the vehicle is still.
    • SHOULD have a resolution of at least 1 degree.

    An exterior view camera is a camera that images scenes outside of the device implementation, like the rearview camera a dashcam .

    If Automotive device implementations include an exterior view camera, for such a camera, they:

    If automotive device implementations include one or more exterior view cameras, and load Exterior View System (EVS) service, then for such a camera, they:

    • [ 7.5 /A-2-1] MUST NOT rotate or horizontally mirror the camera preview.

  • 2.6.1 Tablet Requirements — Hardware : Update to tablet screen size requirements.

    See revision

    • Has a screen display size greater than 7” and less than 18", measured diagonally.

      Screen Size

    • [ 7.1 .1.1/Tab-0-1] MUST have a screen in the range of 7 to 18 inches.

3. Software

  • 3.2.2 Build Parameters : Updated ASCII characters in getSerial() .

    See revision

    • [C-0-1] To provide consistent, meaningful values across device implementations, the table below includes additional restrictions on the formats of these values to which device implementations MUST conform.
    Parameter Details
    getSerial() MUST (be or return) a hardware serial number, which MUST be available and unique across devices with the same MODEL and MANUFACTURER. The value of this field MUST be encodable as 7-bit ASCII and match the regular expression “^[a-zA-Z0-9]+$” .

  • 3.2.3.5 Conditional Application Intents : Update to requirements for conditional application intents.

    See revision

    If device implementations include a large display (generally having display width and height of 600dp+) and supports split functionality , then they:

  • 3.5.1 Application Restriction : Updates to application restrictions.

    See revision

    If device implementations implement a proprietary mechanism to restrict apps (eg changing or restricting API behaviors that are described in the SDK) and that mechanism is more restrictive than the Restricted App Standby Bucket , they:

    • [C-1-2] MUST provide user affordance to turn on / off all of these restrictions on each app.

    Poor system health behavior is generally defined as:

    • For devices with isLowRamDevice = False :

      1. Drawing over 2% battery over last 24 hours when it's in background state
      2. Holding wakelocks over 1 hour over last 24 hours when it's in background state
      3. Total outgoing broadcasts/binding requests are more than 10,000 over last 24 hours when it's in background state

    • For devices with isLowRamDevice = True :

      1. Drawing over 4% battery over last 24 hours when it's in background state
      2. Holding wakelocks over 2 hour over last 24 hours when it's in background state
      3. Total outgoing broadcasts/binding requests are more than 5,000 over last 24 hours when it's in background state
      4. The aforementioned "background state" should conform to the definition of background work in Guide to background processing .

    MAY exempt user-installable apps from these restrictions. * [C-1-12] If they exempt user-installable apps from these restrictions, they MUST provide a public and clear document or website that describes how to request to be opted-in for such an exemption.This document or website MUST be linkable from the Android SDK documents.

    • [C-1-10] MUST NOT allow an app to be automatically placed in the RESTRICTED bucket within 4 hours of the most recent usage by a user, unless it's proven related to the app's significant impact on the system health .

    • [C-1-11] MUST obtain a user consent upon any restrictions being imposed for an app that is running foreground services. Conversely, MUST NOT impose any restrictions for an app that is running foreground services without a user consent.

  • 3.8.1 Launcher (Home Screen) : Updates to support for monochrome/adaptive-icon .

    See revision

    If device implementations support monochrome/adaptive-icon :

    • [C-6-1] these icons MUST be used only when a user explicitly enables them (eg via Settings or wallpaper picker menu).

  • 3.8.2 Widgets : Update to third-party app widget presence in the Launcher.

    See revision

    If device implementations support third-party app widgets, they:

    • [C-1-2] MUST include built-in support for AppWidgets and expose user interface affordances to add, configure, view, and remove AppWidgets directly within the Launcher.

  • 3.8.3.1 Presentation of Notifications : Changing strongly recommended requirements to necessary requirements and clarifying the definition of heads-up notifications.

    See revision

    • [C-SR] are STRONGLY RECOMMENDED
      [C-1-8] MUST provide an affordance for the user to control the notifications that are exposed to apps that have been granted the Notification Listener permission. The granularity MUST be so that the user can control for each such notification listener what notification types are bridged to this listener. The types MUST include "conversations", "alerting", "silent", and "important ongoing" notifications.
    • [C-SR] are STRONGLY RECOMMENDED
      [C-1-9] MUST provide an affordance for users to specify apps to exclude from notifying any specific notification listener.

    Heads up notifications are notifications that are presented to the user as they come in independently of the surface the user is on.

  • 3.8.3.3 DND (Do not Disturb) / Priority Mode : Update to include Priority Mode in DND (Do Not Disturb) requirements.

    See revision

    3.8.3.3. DND (Do not Disturb) / Priority Mode

    If device implementations support the DND feature (also called Priority Mode), they:

  • 3.8.6 Themes : New requirements for dynamic color tonal palettes.

    See revision

    If device implementations include a screen or video output, they:

    • [C-1-4] MUST generate dynamic color tonal palettes as specified in the AOSP documentation of Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (see android.theme.customization.system_palette and android.theme.customization.theme_style ).

    • [C-1-5] MUST generate dynamic color tonal palettes using color theme styles enumerated in the Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES documentation (see android.theme.customization.theme_styles ), namely TONAL_SPOT , VIBRANT , EXPRESSIVE , SPRITZ , RAINBOW , FRUIT_SALAD .

      "Source color" used to generate dynamic color tonal palettes when sent with android.theme.customization.system_palette (as documented in Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES ).

    • [C-1-6] MUST have a CAM16 chroma value of 5 or larger.

      • SHOULD be derived from the wallpaper via com.android.systemui.monet.ColorScheme#getSeedColors , which provides multiple valid source colors to pick one from.

      • SHOULD use the value 0xFF1B6EF3 , if none of the provided colors meet the above source color requirement.

  • 3.8.7.1 Wallpaper Dimming : New requirements for wallpaper dimming.

    See revision

    3.8.7.1. Wallpaper Dimming

    If device implementations support the system API's WallpaperManager.setWallpaperDimAmount() and WallpaperManager.getWallpaperDimAmount() for wallpaper dimming, then they:

    • [C-1-1] MUST recompute and change the lock screen and the home screen text color to ensure that the text color and wallpaper has a minimum contrast ratio of 4.5:1 .
    • [C-1-2] MUST persist the settings for dimming after a new wallpaper is set and after restarting the device.

  • 3.8.17 Clipboard : Added new requirements section for content on the clipboard.

    See revision

    3.8.17. Clipboard

    If device implementations are not running in lock task mode , when content is copied to the clipboard they:

    • [C-1-1] MUST display a UI overlay that shows a user-visible confirmation of clipping (eg, a thumbnail) of the clipboard content and a button (or other affordance) that provides an action for the user to edit textual clipboard content (saving it back to the clipboard).
    • [C-SR] Are STRONGLY RECOMMENDED to provide a button on the displayed UI overlay that provides an affordance for the user to edit image-based clipboard content(saving it back to the clipboard).
    • [C-SR] Are STRONGLY RECOMMENDED to redact the user visible preview (if generated) for sensitive content like passwords.

    Device implementations:

    • [C-0-1] MUST NOT send clipboard data to any component, activity, service, or across any network connection, without explicit user action (eg, pressing a button on the overlay), except for services mentioned in 9.8.6 Content Capture and App Search .

    The AOSP reference implementation satisfies these clipboard requirements.

  • 3.8.18 Dark Theme : Added new requirements section for devices with dark theme support.

    See revision

    3.8.18.Dark Theme

    If device implementations support the System API's UiModeManager.setNightModeCustomType(@NightModeCustomType int nightModeCustomType) and UiModeManager.setNightModeActivatedForCustomMode(@NightModeCustomType int nightModeCustomType, boolean active) to provide support for dark theme, then they:

    • [C-1-1] MUST provide user affordance in the system settings allowing the user to tie the dark theme to a custom schedule.

  • 3.9.1.1 Device Owner Provisioning : Updates to device owner provisioning requirements.

    See revision

    If device implementations declare android.software.device_admin , they:

    • [C-1-1] MUST support enrolling a Device Policy Client (DPC) as a Device Owner app as described below:

      • When the device implementation has no users or user data configured yet, it:

        • [C-1-5] If the device declares Near-Field Communications (NFC) support via the feature flag android.hardware.nfc and receives an NFC message containing a record with MIME type MIME_TYPE_PROVISIONING_NFC , MUST conform to [C-1-8] and [C-1-9].
        • [C-1-5] MUST enroll the DPC application as the Device Owner app if the device declares Near-Field Communications (NFC) support via the feature flag android.hardware.nfc and receives an NFC message containing a record with MIME type MIME_TYPE_PROVISIONING_NFC .
        • [C-1-8] MUST send the ACTION_GET_PROVISIONING_MODE intent after device owner provisioning is triggered so that the DPC app can choose whether to become a Device Owner or a Profile Owner, depending on the values of android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES , unless it can be determined from context that there is only one valid option. (such as for NFC based provisioning where Profile Owner provisioning is not supported).

      • When the device implementation has users or user data, it:

        • [C-1-7] MUST not enroll any DPC application as the Device Owner App any more.

    • [C-1-2] MUST show appropriate disclosure notice (as referenced in AOSP) and require some affirmative action before provisioning or during the provisioning process to confirm consent to an app being set as Device Owner. Consent can be via user action or by some programmatic means but appropriate disclosure notice (as referenced in AOSP) MUST be shown before device owner provisioning is initiated. Also, the programmatic device owner consent mechanism used (by enterprises) for device owner provisioning MUST NOT interfere with the Out-Of-Box Experience for non-enterprise use.

    • [C-1-3] MUST NOT hard code the consent or prevent the use of other device owner apps.

    If device implementations declare android.software.device_admin , but also include a proprietary Device Owner device management solution and provide a mechanism to promote an application configured in their solution as a "Device Owner equivalent" to the standard "Device Owner" as recognized by the standard Android DevicePolicyManager APIs, they:

    • [C-2-3] MUST NOT hard code the consent or prevent the use of other device owner apps.
    • MAY have user data on the device prior to enrolling the DPC application as "Device Owner".

  • 3.9.4 Device Management Role Requirements : Added a section for Device Management Role Requirements.

    See revision

    3.9.4 Device Management Role Requirements

    If device implementations report android.software.device_admin or android.software.managed_users , then they:

    • [C-1-1] MUST support a device management role. The application that holds the device management role MAY be defined by setting config_deviceManager to the package name, followed by : and the signing certificate.

    If a device management role holder application is defined, an application that updates the device management role holder, then, it:

    • [C-2-1] MUST be preinstalled on the device.
    • MAY be defined with config_deviceManagerRoleHolderUpdaterPackageName .
    • [C-2-2] MUST define intent filters for the intent actions android.app.action.ROLE_HOLDER_PROVISION_MANAGED_DEVICE_FROM_TRUSTED_SOURCE , android.app.action.ROLE_HOLDER_PROVISION_MANAGED_PROFILE and android.app.action.ROLE_HOLDER_PROVISION_FINALIZATION . They MUST be protected by the android.permission.LAUNCH_DEVICE_MANAGER_SETUP permission, which MUST be held by the application that launches them.

    If a package name is not defined for the device management role, device implementations:

    • [C-3-1] MUST support provisioning without the device management role holder.

    If a device management role holder updater application is defined on the device then it:,

    • [C-4-1] MUST attempt to establish an internet connection during setup prior to provisioning. If internet connection could not be established, provisioning MUST fail unless android.app.extra.PROVISIONING_ALLOW_OFFLINE_PROVISIONING is explicitly set to true , in which case provisioning MUST continue without using the device management role holder.
    • [C-4-2] MUST have an intent filter which resolves android.app.action.UPDATE_DEVICE_MANAGEMENT_ROLE_HOLDER . That intent filter MUST be protected by the android.permission.LAUNCH_DEVICE_MANAGER_SETUP permission, which MUST be held by the application that launches it. The handler of that intent filter MUST handle the device management role holder application update and return an intent with a result set to either:
      • Activity#RESULT_OK if the update was successful.
      • DevicePolicyManager#RESULT_UPDATE_DEVICE_MANAGEMENT_ROLE_HOLDER_RECOVERABLE_ERROR if it encounters a problem that may be solved by relaunching it again (such as a temporary network issue).
      • DevicePolicyManager#RESULT_UPDATE_DEVICE_MANAGEMENT_ROLE_HOLDER_UNRECOVERABLE_ERROR if it encounters a problem that cannot be resolved by relaunching it.

    If a device management role holder application and a device management role holder updater application are defined, and an internet connection has been established, then device implementations:

    • [C-5-1] MUST update the device management role holder application prior to provisioning by launching the device management role holder updater application using the android.app.action.UPDATE_DEVICE_MANAGEMENT_ROLE_HOLDER intent.

    If devices report android.software.device_admin or android.software.managed_users and a device management role holder application is defined, and provisioning is initiated with one of the following intent actions, then the role holder must be invoked as follows:

    If provisioning is initiated with android.app.action.PROVISION_MANAGED_DEVICE_FROM_TRUSTED_SOURCE , it:

    • [C-6-1] MUST start the device management role holder with an intent with action android.app.action.ROLE_HOLDER_PROVISION_MANAGED_DEVICE_FROM_TRUSTED_SOURCE and with the same intent extras that were passed to the provisioning intent.

    If provisioning is initiated with android.app.action.PROVISION_MANAGED_PROFILE , it:

    • [C-7-1] MUST start the device management role holder with an intent with action android.app.action.ROLE_HOLDER_PROVISION_MANAGED_PROFILE and with the same intent extras that were passed to the provisioning intent.

    If provisioning is initiated with android.app.action.PROVISION_FINALIZATION , it:

    • [C-8-1] MUST start the device management role holder with an intent with action android.app.action.ROLE_HOLDER_PROVISION_FINALIZATION .

    If provisioning is initiated with an intent action not defined above, then:

    • [C-9-1] provisioning MUST continue without using the device management role holder.

    When the device management role holder is installed on a given user, it:

    • [C-10-1] must be installed on all profiles for that user.

  • 3.18 Contacts : Adding information for new contacts.

    See revision

    Default account for new contacts: Contacts Provider provides APIs to manage the setting of the default account when creating a new contact.

    Device implementations:

    • [C-2-1] Preloaded Contacts app MUST handle the intent ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT to launch a UI for account selection and save the setting to Contacts Provider when an account is selected.

    • [C-2-2] MUST honor the default account setting in the application that handles Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT for the ContactsContracts.Contacts.CONTENT_TYPE and ContactsContract.RawContacts.CONTENT_TYPE by initially selecting the account.

4. Application Packaging Compatibility

5. Multimedia Compatibility

  • 5.1.2 Audio Decoding : Added new requirements for decoders capable of outputting mutli-channel audio.

    See revision

    If device implementations include support for decoders capable of outputting multi-channel audio (ie more than 2 channels) when fed compressed multi-channel content, then the following MUST be supported:

    • [C-7-1] MUST be able to be configured by the application using the decoding with the key KEY_MAX_OUTPUT_CHANNEL_COUNT to control whether the content is downmixed to stereo (when using a value of 2) or is output using the native number of channels (when using a value equal or greater to that number). For instance a value of 6 or greater would configure a decoder to output 6 channels when fed 5.1 content.
    • [C-7-2] When decoding, the decoder MUST advertise the channel mask being used on the output format with the KEY_CHANNEL_MASK key, using the android.media.AudioFormat constants (example: CHANNEL_OUT_5POINT1 ).

  • 5.4.1 Raw Audio Capture and Microphone Information : Updates to supported audio sources for audio input streams.

    See revision

    If device implementations declare android.hardware.microphone , they:

  • 5.4.2 Capture for Voice Recognition : Updated requirements for voice recognition audio stream.

    See revision

    If device implementations declare android.hardware.microphone , they:

    • SHOULD record the voice recognition audio stream with approximately flat amplitude versus frequency characteristics: specifically, ±3 dB, from 100 Hz to 4000 Hz.
    • SHOULD record the voice recognition audio stream with input sensitivity set such that a 90 dB sound power level (SPL) source at 1000 Hz yields RMS of 2500 for 16-bit samples.

    • SHOULD exhibit approximately flat amplitude-versus-frequency characteristics in the mid-frequency range: specifically ±3dB from 100 Hz to 4000 Hz for each and every microphone used to record the voice recognition audio source.
    • [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the low frequency range: specifically from ±20 dB from 30 Hz to 100 Hz compared to the mid-frequency range for each and every microphone used to record the voice recognition audio source.
    • [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the high frequency range: specifically from ±30 dB from 4000 Hz to 22 KHz compared to the mid-frequency range for each and every microphone used to record the voice recognition audio source.
    • SHOULD set audio input sensitivity such that a 1000 Hz sinusoidal tone source played at 90 dB Sound Pressure Level (SPL) (measured next to the microphone) yields an ideal response of RMS 2500 within a range of 1770 and 3530 for 16 bit-samples (or -22.35 db ±3dB Full Scale for floating point/double precision samples) for each and every microphone used to record the voice recognition audio source.

  • 5.4.6 Microphone Gain Levels : Removed requirements for Microphone Gain Levels.

    See revision

    5.4.6. Microphone Gain Levels

    If device implementations declare android.hardware.microphone , they:

    • SHOULD exhibit approximately flat amplitude-versus-frequency characteristics in the mid-frequency range: specifically ±3dB from 100 Hz to 4000 Hz for each and every microphone used to record the voice recognition audio source.
    • SHOULD set audio input sensitivity such that a 1000 Hz sinusoidal tone source played at 90 dB Sound Pressure Level (SPL) yields a response with RMS of 2500 for 16 bit-samples (or -22.35 dB Full Scale for floating point/double precision samples) for each and every microphone used to record the voice recognition audio source.
    • [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the low frequency range: specifically from ±20 dB from 5 Hz to 100 Hz compared to the mid-frequency range for each and every microphone used to record the voice recognition audio source.
    • [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the high frequency range: specifically from ±30 dB from 4000 Hz to 22 KHz compared to the mid-frequency range for each and every microphone used to record the voice recognition audio source.

  • 5.5.4 Audio Offload : Updates to the audio offload playback requirements.

    See revision

    If device implementations support audio offload playback , they:

    • [C-1-1] MUST trim the played gapless audio content for MP3 and AAC when specified by the AudioTrack gapless API and the media container for MediaPlayer.
    • [C-SR] Are STRONGLY RECOMMENDED to trim the played gapless audio content for all supported compressed audio formats when specified by the AudioTrack gapless API and the media container for MediaPlayer.

  • 5.6 Audio Latency : Updates to the audio latency requirements.

    See revision

    For the purposes of this section, use the following definitions:

    • cold output jitter . The variability among separate measurements of cold output latency values.
    • cold input jitter . The variability among separate measurements of cold input latency values.

    If device implementations declare android.hardware.audio.output they MUST meet or exceed the following requirements:

    • [C-1-2] Mean cold output latency of 500 milliseconds or less over 5 measurements, with a Mean Absolute Deviation less than 100 msec.

    • [C-1-3] Opening an output stream using AAudioStreamBuilder_openStream() MUST take less than 1000 milliseconds.

    If device implementations declare android.hardware.audio.output they are STRONGLY RECOMMENDED to meet or exceed the following requirements:

    • [C-SR] Cold output latency of 100 milliseconds or less over the speaker data path. Existing and new devices that run this version of Android are VERY STRONGLY RECOMMENDED to meet these requirements now. In a future platform release, we will require Cold output latency of 200 ms or less as a MUST.

    • [C-SR] Minimize the cold output jitter.

    If device implementations include android.hardware.microphone , they MUST meet these input audio requirements:

    • [C-3-2] Mean cold input latency of 500 milliseconds or less over 5 measurements, with a Mean Absolute Deviation less than 100 msec.

    • [C-3-3] Opening an input stream using AAudioStreamBuilder_openStream() MUST take less than 1000 milliseconds.

    If device implementations include android.hardware.microphone , they are STRONGLY RECOMMENDED to meet these input audio requirements:

    • [C-SR] Cold input latency of 100 milliseconds or less over the microphone data path. Existing and new devices that run this version of Android are VERY STRONGLY RECOMMENDED to meet these requirements now. In a future platform release we will require Cold input latency of 200 ms or less as a MUST.

    • [C-SR] Continuous input latency of 30 milliseconds or less.
    • [C-SR] Minimize the cold input jitter.

  • 5.10 Professional Audio : Updates to audio latency requirements for professional audio support.

    See revision

    If device implementations report support for feature android.hardware.audio.pro via the android.content.pm.PackageManager class, they:

    • [C-1-2] MUST have the continuous round-trip audio latency, as defined in section 5.6 Audio Latency of 250 milliseconds or less and SHOULD be 10 milliseconds or less over at least one supported path.
    • [C-1-5] MUST meet latencies and USB audio requirements using the AAudio native audio API and AAUDIO_PERFORMANCE_MODE_LOW_LATENCY .
    • [C-1-8] MUST have an average Tap-to-tone latency of 80 milliseconds or less over at least 5 measurements over the speaker to microphone data path.
    • [C-SR] Are STRONGLY RECOMMENDED to provide a consistent level of CPU performance while audio is active and CPU load is varying. This should be tested using the Android app SynthMark . SynthMark uses a software synthesizer running on a simulated audio framework that measures system performance. See the SynthMark documentation for an explanation of the benchmarks. The SynthMark app needs to be run using the “Automated Test” option and achieve the following results: * voicemark.90 >= 32 voices * latencymark.fixed.little <= 15 msec * latencymark.dynamic.little <= 50 msec
    • SHOULD have a latency from touch input to audio output of less than or equal to 40 ms.

    If device implementations include a 4 conductor 3.5mm audio jack, they:

    • [C-2-1] MUST have a mean Continuous Round-trip Audio Latency, as defined in section 5.6 Audio Latency , of 20 milliseconds or less, over 5 measurements with a Mean Absolute Deviation less than 5 milliseconds over the audio jack path using an Audio Loopback Dongle .

6. Developer Tools and Options Compatibility

  • 6.1 Developer Tools : Updates to connectivity and GPU Kernel requirements.

    See revision

    If device implementations support adb connections to a host machine via Wi-Fi or Ethernet , they:

    • [C-4-1] MUST have the AdbManager#isAdbWifiSupported() method return true .

    If device implementations support adb connections to a host machine via Wi-Fi or Ethernet , and includes at least one camera, they:

    • [C-5-1] MUST have the AdbManager#isAdbWifiQrSupported() method return true .

    • GPU Kernel Tracepoint If device implementations support the power/gpu_work_period kernel tracepoint API, they:
      • [C-6-1] MUST implement the shell command gpu -gpuwork and display the GpuPerUidFrequencyTime information returned by the tracepoint.

7. Hardware Compatibility

  • 7.1.4.1 OpenGL ES : Update to recommended extensions.

    See revision

    If device implementations support any of the OpenGL ES versions, they:

    • SHOULD support the EGL_IMG_context_priority and EGL_EXT_protected_content extensions.

  • 7.1.4.2 Vulkan : Updates to version supported for Vulkan.

    See revision

    If device implementations support OpenGL ES 3.1, they:

    • [SR] Are STRONGLY RECOMMENDED to include support for Vulkan 1.3 . Vulkan 1.1
    • MUST NOT support a Vulkan Variant version (ie the variant part of the Vulkan core version MUST be zero).

    If device implementations include a screen or video output, they:

    • [SR] Are STRONGLY RECOMMENDED to include support for Vulkan 1.3 . Vulkan 1.1

    If device implementations include support for Vulkan 1.0 or higher, they:

    • SHOULD support VkPhysicalDeviceProtectedMemoryFeatures and VK_EXT_global_priority .
    • [C-1-12] MUST NOT enumerate support for the VK_KHR_performance_query extension.
    • [C-SR] Are STRONGLY RECOMMENDED to satisfy the requirements specified by the Android Baseline 2021 profile.

  • 7.2.3 Navigation Keys :

    See revision

    Device implementations:

    • [C-SR] Are STRONGLY RECOMMENDED to provide all navigation functions as cancellable. 'Cancellable' is defined as the user's ability to prevent the navigation function from executing (eg going home, going back, etc.) if the swipe is not released past a certain threshold.

    If the back navigation function is provided and the user cancels the Back gesture, then:

    • [C-8-1] OnBackInvokedCallback.onBackCancelled() MUST be called.
    • [C-8-2] OnBackInvokedCallback.onBackInvoked() MUST NOT be called.
    • [C-8-3] KEYCODE_BACK event MUST NOT be dispatched.

    If the back navigation function is provided but the foreground application does NOT have an OnBackInvokedCallback registered, then:

    • The system SHOULD provide an animation for the foreground application that suggests that the user is going back, as provided in AOSP.

    If device implementations provide support for the system API calls setNavBarModeOverride to override the navigation bar, then they:

    • [C-9-1] MUST provide support for kid friendly icons or button-based navigation.

  • 7.3.1 Accelerometer : Updates to sensor requirements for accelerometers.

    See revision

    If device implementations include a 3-axis accelerometer, they:

    • [C-2-1] MUST implement and report TYPE_ACCELEROMETER sensor.
    • [C-SR] Are STRONGLY RECOMMENDED to implement the TYPE_SIGNIFICANT_MOTION composite sensor.
    • [C-SR] Are STRONGLY RECOMMENDED to implement and report TYPE_ACCELEROMETER_UNCALIBRATED sensor. Android devices are STRONGLY RECOMMENDED to meet this requirement so they will be able to upgrade to the future platform release where this might become REQUIRED.
    • SHOULD implement the TYPE_SIGNIFICANT_MOTION , TYPE_TILT_DETECTOR , TYPE_STEP_DETECTOR , TYPE_STEP_COUNTER composite sensors as described in the Android SDK document.

    If device implementations include an accelerometer with less than 3 axes, they:

    • [C-3-1] MUST implement and report TYPE_ACCELEROMETER_LIMITED_AXES sensor.
    • [C-SR] Are STRONGLY_RECOMMENDED to implement and report TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED sensor.

    If device implementations include a 3-axis accelerometer and any of the TYPE_SIGNIFICANT_MOTION , TYPE_TILT_DETECTOR , TYPE_STEP_DETECTOR , TYPE_STEP_COUNTER composite sensors are implemented:

    • [C-4-1] The sum of their power consumption MUST always be less than 4 mW.

    If device implementations include a 3-axis accelerometer and a 3-axis gyroscope sensor, they:

    • [C-5-1] MUST implement the TYPE_GRAVITY and TYPE_LINEAR_ACCELERATION composite sensors.

    If device implementations include a 3-axis accelerometer, a 3-axis gyroscope sensor, and a magnetometer sensor, they:

    • [C-6-1] MUST implement a TYPE_ROTATION_VECTOR composite sensor.

  • 7.3.4 Gyroscopes : Updates to sensor requirements for gyroscopes.

    See revision

    If device implementations include a gyroscope, they:

    • [C-1-1] MUST be able to report events up to a frequency of at least 50 Hz.
    • [C-1-4] MUST have a resolution of 12-bits or more.
    • [C-1-5] MUST be temperature compensated.
    • [C-1-6] MUST be calibrated and compensated while in use, and preserve the compensation parameters between device reboots.
    • [C-1-7] MUST have a variance no greater than 1e-7 rad^2 / s^2 per Hz (variance per Hz, or rad^2 / s). The variance is allowed to vary with the sampling rate, but MUST be constrained by this value. In other words, if you measure the variance of the gyro at 1 Hz sampling rate it SHOULD be no greater than 1e-7 rad^2/s^2.
    • [C-SR] Calibration error is STRONGLY RECOMMENDED to be less than 0.01 rad/s when device is stationary at room temperature.
    • [C-SR] Are STRONGLY RECOMMENDED to have a resolution of 16-bits or more.
    • SHOULD report events up to at least 200 Hz.

    If device implementations include a 3-axis gyroscope, they:

    • [C-2-1] MUST implement the TYPE_GYROSCOPE sensor.

    If device implementations include a gyroscope with less than 3 axes, they:

    • [C-3-1] MUST implement and report TYPE_GYROSCOPE_LIMITED_AXES sensor.
    • [C-SR] Are STRONGLY_RECOMMENDED to implement and report TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED sensor.

    If device implementations include a 3-axis gyroscope, an accelerometer sensor and a magnetometer sensor, they:

    • [C-4-1] MUST implement a TYPE_ROTATION_VECTOR composite sensor.

    If device implementations include a 3-axis accelerometer and a 3-axis gyroscope sensor, they:

    • [C-5-1] MUST implement the TYPE_GRAVITY and TYPE_LINEAR_ACCELERATION composite sensors.

  • 7.3.10 Biometric Sensors : Updates to sensor requirements for biometric sensors.

    See revision

    Biometric sensors can be classified as Class 3 (formerly Strong ), Class 2 (formerly Weak ), or Class 1 (formerly Convenience ) based on their spoof and imposter acceptance rates, and on the security of the biometric pipeline. This classification determines the capabilities the biometric sensor has to interface with the platform and with third-party applications. Sensors need to meet additional requirements as detailed below if they wish to be classified as either Class 1 , Class 2 or Class 3 . Sensors are classified as Class 1 by default, and need to meet additional requirements as detailed below if they wish to be classified as either Class 2 or Class 3 . Both Class 2 and Class 3 biometrics get additional capabilities as detailed below.

    If device implementations wish to treat a biometric sensor as Class 1 (formerly Convenience ), they:

    • [C-1-11] MUST have a spoof and imposter acceptance rate not higher than 30%, with (1) a spoof and imposter acceptance rate for Level A presentation attack instrument (PAI) species not higher than 30%, and (2) a spoof and imposter acceptance rate of Level B PAI species not higher than 40%, as measured by the Android Biometrics Test Protocols.

    If device implementations wish to treat a biometric sensor as Class 2 (formerly Weak ), they:

    • [C-2-2] MUST have a spoof and imposter acceptance rate not higher than 20%, with (1) a spoof and imposter acceptance rate for Level A presentation attack instrument (PAI) species not higher than 20%, and (2) a spoof and imposter acceptance rate of Level B PAI species not higher than 30%, as measured by the Android Biometrics Test Protocols .

    If device implementations wish to treat a biometric sensor as Class 3 (formerly Strong ), they:

    • [C-3-3] MUST have a spoof and imposter acceptance rate not higher than 7%, with (1) a spoof and imposter acceptance rate for Level A presentation attack instrument (PAI) species not higher than 7%, and (2) a spoof and imposter acceptance rate of Level B PAI species not higher than 20%, as measured by the Android Biometrics Test Protocols .

  • 7.3.13 IEEE 802.1.15.4 (UWB) : Added a new requirements section for UWB.

    See revision

    7.3.13. IEEE 802.1.15.4 (UWB)

    If device implementations include support for 802.1.15.4 and expose the functionality to a third-party application, they:

    • [C-1-1] MUST implement the corresponding Android API in android.uwb.
    • [C-1-2] MUST report the hardware feature flag android.hardware.uwb.
    • [C-1-3] MUST support all the relevant UWB profiles defined in Android implementation.
    • [C-1-4] MUST provide a user affordance to allow the user to toggle the UWB radio on/off state.
    • [C-1-5] MUST enforce that apps using UWB radio hold UWB_RANGING permission (under NEARBY_DEVICES permission group).
    • [C-1-6] Are STRONGLY RECOMMENDED to pass the relevant conformance and certification tests defined by standard organizations, including FIRA , CCC and CSA .

  • 7.4.1 Telephony : Updates to telephony requirements for GSM and CDMA telephony, and cellular usage settings.

    See revision

    If device implementations support eUICCs or eSIMs/embedded SIMs and include a proprietary mechanism to make eSIM functionality available for third-party developers, they:

    If device implementations include GSM or CDMA telephony, then:

    If the device device implementations include GSM or CDMA telephony and provides a system status bar, then they:

    • [C-SR] it is STRONGLY RECOMMENDED that the representative subscription is chosen to be the active data subscription unless the device is in a voice call, during which it is STRONGLY RECOMMENDED that the representative subscription is the active voice subscription.

    If device implementations include GSM or CDMA telephony, then:

    • [C-6-8] MUST be capable of opening and concurrently utilizing the maximum number of logical channels (20 in total) for each UICC per ETSI TS 102 221.
    • [C-6-9] MUST declare the android.hardware.telephony feature flag and other sub-feature flags according to the technology and features to be supported. The sub-feature flags include android.hardware.telephony.radio.access, android.hardware.telephony.subscription, android.hardware.telephony.cdma, android.hardware.telephony.gsm, android.hardware.telephony.calling, android.hardware.telephony.data, android.hardware.telephony.messaging. The standard set of telephony features for GSM phone, CDMA phone, data-only devices, etc. can be found from the config files under platform/frameworks/native/data/etc/.

    If the device device implementations include GSM or CDMA telephony and all active, non-opportunistic subscriptions that share a group UUID are disabled, physically removed from the device, or marked opportunistic, then the device:

    • [C-7-1] MUST automatically disable all remaining active opportunistic subscriptions in the same group.

    If device implementations include GSM telephony but not CDMA telephony, they:

    If device implementations report FEATURE_TELEPHONY_IMS and supports cellular usage setting configuration, then they:

    • [C-9-1] MUST set CarrierConfigManager#KEY_CELLULAR_USAGE_SETTING_INT to value SubscriptionManager#USAGE_SETTING_VOICE_CENTRIC .

    If device implementations report FEATURE_TELEPHONY_DATA and supports cellular usage setting configuration, then they:

    • [C-10-1] MUST set CarrierConfigManager#KEY_CELLULAR_USAGE_SETTING_INT to value SubscriptionManager#USAGE_SETTING_DATA_CENTRIC .

    If the device implementations support eUICCs with multiple ports and profiles, they:

    • [C-11-1] MUST declare the android.hardware.telephony.euicc feature flag.

  • 7.4.1.1 Number Blocking Compatibility : Updates to the number blocking requirements.

    See revision

    If device implementations report the android.hardware.telephony feature , they:

    • [C-1-4] MUST write to the platform call log provider for a blocked call and MUST filter calls with BLOCKED_TYPE out of the default call log view in the pre-installed dialer app.
    • SHOULD provide a user affordance to show blocked calls in the pre-installed dialer app.

  • 7.4.2.5 Wi-Fi Location (Wi-Fi Round Trip Time - RTT) : Updates to Wi-Fi location accuracy.

    See revision

    If device implementations include support for Wi-Fi Location and expose the functionality to third-party apps, then they:

    • [C-1-4] MUST be accurate to within 2 meters [C-SR] Are STRONGLY RECOMMENDED to report it accurately to within 1.5 meters at 80 MHz bandwidth at the 68th percentile (as calculated with the Cumulative Distribution Function).

  • 7.4.2.6 Wi-Fi / Cellular NAT-T Keepalive Offload : Updated to add cellular keepalive offload requirements.

    See revision

    Device implementations:

    • SHOULD include support for Wi-Fi keepalive offload and Cellular keepalive offload.

    If device implementations include support for Wi-Fi keepalive offload or Cellular keepalive offload and expose the functionality to third-party apps,they:

    • [C-1-1] MUST support the SocketKeepAlive API.
    • [C-1-2] MUST support at least three concurrent keepalive slots over Wi-Fi and at least one keepalive slot over cellular.

    If device implementations do not include support for Wi-Fi keepalive offload or cellular keepalive offload , they:

  • 7.4.2.9 Trust On First Use (TOFU) : Added Trust on First Use requirements section.

    See revision

    7.4.2.9 Trust On First Use (TOFU)

    If device implementations support Trust on first usage (TOFU), then they:

    • [C-4-1] MUST NOT provide the user an option to manually add a TLS-based Enterprise Wi-Fi network if the Wi-Fi server certificate is not configured or the Wi-Fi server domain name is not set.
    • [C-4-2] MUST provide the user an option to select to use TOFU.

  • 7.4.3 Bluetooth : Update to Bluetooth requirements.

    See revision

    If device implementations support Bluetooth Audio profile, they:

    • SHOULD support Advanced Audio Codecs and Bluetooth Audio Codecs (eg LDAC) with A2DP.

    If device implementations return true for the BluetoothAdapter.isLeAudioSupported() API, then they:

    • [C-7-1] MUST support unicast client.
    • [C-7-2] MUST support 2M PHY.
    • [C-7-3] MUST support LE Extended advertising.
    • [C-7-4] MUST support at least 2 CIS connections in a CIG.
    • [C-7-5] MUST enable BAP/HAP unicast client, CSIP set coordinator, MCP server, VCP controller, CCP server simultaneously.

    If device implementations return true for the BluetoothAdapter.isLeAudioBroadcastSourceSupported() API, then they:

    • [C-8-1] MUST support at least 2 BIS links in a BIG.
    • [C-8-2] MUST enable BAP broadcast source, BAP broadcast assistant simultaneously.
    • [C-8-3] MUST support LE Periodic advertising.

    If device implementations return true for the BluetoothAdapter.isLeAudioBroadcastAssistantSupported() API, then they:

    • [C-9-1] MUST support PAST (Periodic Advertising Sync Transfer).
    • [C-9-2] MUST support LE Periodic advertising.

    If device implementations support Bluetooth LE and use Bluetooth LE for location scanning to determine nearness to other devices, they:

    • [C-10-1] MUST have variance of RSSI measurements be within +/-6dB at 95% confidence level at 1m distance from a reference device transmitting at ADVERTISE_TX_POWER_HIGH .
    • [C-10-2] MUST include Rx calibration to reduce per-channel deviations so that the measurements on each of the 3 channels, on each of the antennas (if multiple are used), are within +-2db of one another.
    • [C-10-3] MUST include Rx calibration to ensure the median BLE RSSI is -69dB at 1m distance from a reference device transmitting at ADVERTISE_TX_POWER_HIGH .
    • [C-10-4] MUST include Tx calibration to ensure the median BLE RSSI is -69dB when scanning from a reference device positioned at 1m distance and transmitting at ADVERTISE_TX_POWER_HIGH .

  • 7.4.9 UWB : Added a requirements section for UWB hardware.

    See revision

    7.4.9. UWB

    If device implementations include UWB hardware, then they:

    • [C-1-1] MUST ensure the variance of distance measurements is under +/-10cm, and the variance of angle of arrival measurements is under +/-5 degrees.
    • [C-1-2] MUST apply corrections so that the median of the measurements at 10cm from the reference device is equal to 10cm.
    • [C-1-3 ]MUST have measurements fit a trend line with bias of 0 and slope of 1 for the 1m, 3m, and 5m points.

  • 7.5 Cameras : Updates to the requirements for HDR 10-bit output capability.

    See revision

    If device implementations support HDR 10-bit output capability, then they:

    • [C-2-1] MUST support the same set of HDR profiles for the primary rear-facing and primary front-facing cameras.
    • [C-2-2] MUST support the same HDR profiles for all BACKWARD_COMPATIBLE-capable physical sub-cameras of a logical camera, and the logical camera itself.
    • [C-2-3] MUST support the overall image quality based on the application-requested capture settings and the application-specified usecase of the output and NOT on the destination of that output.

    For Logical camera devices which support 10-bit HDR that implement the android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO API, they:

    • [C-3-1] MUST support switching between all the backwards-compatible physical cameras via the CONTROL_ZOOM_RATIO control on the logical camera.

  • 7.7.2 USB Host Mode : Revisions for dual role ports.

    See revision

    If device implementations include a USB port supporting host mode and USB Type-C, they:

    • [C-4-1] MUST implement Dual Role Port functionality as defined by the USB Type-C specification (section 4.5.1.3.3). For Dual Role Ports, On devices that include a 3.5mm audio jack, the USB sink detection (host mode) MAY be off by default but it MUST be possible for the user to enable it.

  • 7.11 Media Performance Class : Updated to include Android T.

    See revision

    If device implementations return non-zero value for android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , they:

    • [C-1-3] MUST meet all requirements for "Media Performance Class" described in section 2.2.7 .

    In other words, media performance class in Android T is only defined for handheld devices at version T, S or R.

    See section 2.2.7 for device-specific requirements.

8. Performance and Power

  • 8.5 Consistent Performance : Update to user-facing requirements for foreground service management.

    See revision

    Device implementations:

    • [C-0-2] MUST provide a user affordance in the Settings menu with the ability to stop an active foreground service as described in a forthcoming document and display all apps that have active foreground services along with the number of services per app and the duration of each of these services since it started.
      • Foreground services from apps that fulfill predefined roles that are listed in a forthcoming document MAY not be displayed in this area.

9. Security Model Compatibility

  • 9.1 Permissions : Extend accepted paths for permissions allowlists for preinstalled apps to APEX files.

    See revision

    • [C-0-2] Permissions with a protectionLevel of PROTECTION_FLAG_PRIVILEGED MUST only be granted to apps preinstalled in the privileged path(s) of the system image (as well as APEX files ) and be within the subset of the explicitly allowlisted permissions for each app. The AOSP implementation meets this requirement by reading and honoring the allowlisted permissions for each app from the files in the etc/permissions/ path and using the system/priv-app path as the privileged path.

  • 9.7 Security Features : Updates to initialization requirements to maintain kernel integrity.

    See revision

    Kernel integrity and self-protection features are integral to Android security. Device implementations:

    • [C-0-14] MUST enable stack initialization in the kernel to prevent uses of uninitialized local variables ( CONFIG_INIT_STACK_ALL or CONFIG_INIT_STACK_ALL_ZERO ). Also, device implementations MUST NOT assume the value used by the compiler to initialize the locals.

  • 9.8.7 Privacy — Clipboard Access : Automatically clear clipboard data after 60 minutes following a cut/copy/paste activity to protect user privacy.

    See revision

    • [C-0-2] MUST clear clipboard data at most 60 minutes after it has last been placed in a clipboard or read from a clipboard.

  • 9.11 Keys and Credentials : Updates to the secure lock screen requirements, including the addition of ECDH and 3DES to crypto algorithms and attestation key provisioning.

    See revision

    When the device implementation supports a secure lock screen, it:

    • [C-1-2] MUST have implementations of RSA, AES, ECDSA, ECDH, 3DES, and HMAC cryptographic algorithms and MD5, SHA1, and SHA-2 family hash functions to properly support the Android Keystore system's supported algorithms in an area that is securely isolated from the code running on the kernel and above. Secure isolation MUST block all potential mechanisms by which kernel or userspace code might access the internal state of the isolated environment, including DMA. The upstream Android Open Source Project (AOSP) meets this requirement by using the Trusty implementation, but another ARM TrustZone-based solution or a third-party reviewed secure implementation of a proper hypervisor-based isolation are alternative options.
    • [C-1-4] MUST support key attestation where the attestation signing key is protected by secure hardware and signing is performed in secure hardware. The attestation keys MUST be generated on device, in the isolated environment, and attestation key certificates MUST be remotely provisioned to the device after the device authenticates with a device-unique authentication key. The attestation signing keys MUST be shared across large enough number of devices to prevent the keys from being used as device identifiers. One way of meeting this requirement is to share the same attestation key unless at least 100,000 units of a given SKU are produced. If more than 100,000 units of an SKU are produced, a different key MAY be used for each 100,000 units.

    • [C-SR] is STRONGLY RECOMMENDED that the device have an attestation key provisioned by the vendor factory for use in the event there is a problem with remotely-provisioned keys. The factory-provisioned attestation signing keys MUST be shared across large enough number of devices to prevent the keys from being used as device identifiers. One way of meeting this requirement is to share the same attestation key unless at least 100,000 units of a given SKU are produced. If more than 100,000 units of an SKU are produced, a different key MAY be used for each 100,000 units.

    Note that if a device implementation is already launched on an earlier Android version, such a device is exempted from the requirement to have a keystore backed by an isolated execution environment and support the key attestation, unless it declares the android.hardware.fingerprint feature which requires a keystore backed by an isolated execution environment. If a device implementation is already launched on an earlier Android version, such a device is also exempted from the requirement to remotely provision attestation keys.

  • 9.11.1 Secure Lock Screen, Authentication, and Virtual Devices : Added requirements section for virtual devices and authentication transfers.

    See revision

    If device implementations add or modify the authentication methods to unlock the lock screen and a new authentication method is based on a physical token or the location:

    • [C-6-3] The user MUST be challenged for one of the recommended primary authentication methods (egPIN, pattern, password) at least once every 4 hours or less. When a physical token meets the requirements for TrustAgent implementations in CX, timeout restrictions defined in C-9-5 apply instead.

    If device implementations allow applications to create secondary virtual displays and do not support associated input events, such as via VirtualDeviceManager , they:

    • [C-9-1] MUST lock these secondary virtual display(s) when the device's default display is locked, and unlock these secondary virtual display(s) when the device's default display is unlocked.

    If device implementations allow applications to create secondary virtual displays and support associated input events, such as via VirtualDeviceManager [will be linked to API at developer.android.com API], they:

    • [C-10-1] MUST support separate lock states per virtual device
    • [C-10-2] MUST disconnect all virtual devices upon idle timeout
    • [C-10-3] MUST have an idle timeout
    • [C-10-4] MUST lock all displays when the user initiates a lockdown , including via the lockdown user affordance required for handheld devices (see Section 2.2.5[9.11/H-1-2] )
    • [C-10-5] MUST have separate virtual device instances per user
    • [C-10-6] MUST disable the creation of associated input events via VirtualDeviceManager when indicated by DevicePolicyManager.setNearbyAppStreamingPolicy
    • [C-10-7] MUST use a separate clipboard solely for each virtual device (or disable the clipboard for virtual devices)
    • [C-10-8] MUST block activities with the attribute android:canDisplayOnRemoteDevices or the meta-data android.activity.can_display_on_remote_devices set to true from being started on the virtual device.
    • [C-10-9] MUST block activities which do not explicitly enable streaming and which indicate they show sensitive content, including via SurfaceView#setSecure , FLAG_SECURE , or SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS , from being started on the virtual device.
    • [C-10-10] MUST disable installation of apps initiated from virtual devices
    • [C-10-11] MUST disable authentication UI on virtual devices, including knowledge factor entry and biometric prompt
    • [C-10-12] MUST restrict intents initiated from a virtual device to display only on the same virtual device
    • [C-10-13] MUST not use a virtual device lock state as user authentication authorization with the Android Keystore System. See KeyGenParameterSpec.Builder.setUserAuthentication* .

    When device implementations allow the user to transfer the primary authentication knowledge-factor from a source device to a target device, such as for initial setup of the target device, they:

    • [C-11-1] MUST encrypt the knowledge-factor with protection guarantees similar to those described in this security whitepaper when transferring the knowledge-factor from the source device to the target device such that the knowledge-factor cannot be remotely decrypted or used to remotely unlock either device.
    • [C-11-2] MUST, on the source device , ask the user to confirm the knowledge-factor of the source device before transferring the knowledge-factor to the target device.
    • [C-11-3] MUST, on a target device lacking any set primary authentication knowledge-factor, ask the user to confirm a transferred knowledge-factor on the target device before setting that knowledge-factor as the primary authentication knowledge-factor for the target device and before making available any data transferred from a source device.

    If device implementations have a secure lock screen and include one or more trust agents, which call the TrustAgentService.grantTrust() System API with the FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE flag they:

    • [C-12-1] MUST only call grantTrust() with the flag when connected to a proximate physical device with a lockscreen of its own, and when the user has authenticated their identity against that lockscreen. Proximate devices can use on-wrist or on-body detection mechanisms after a one-time user unlock to satisfy the user authentication requirement.
    • [C-12-2] MUST put the device implementation into the TrustState.TRUSTABLE state when the screen is turned off (such as via a button press or display time out) and the TrustAgent has not revoked trust. The AOSP satisfies this requirement.
    • [C-12-3] MUST only move the device from TrustState.TRUSTABLE to the TrustState.TRUSTED state if the TrustAgent is still granting trust based on the requirements in C-12-1.
    • [C-12-4] MUST call TrustManagerService.revokeTrust() after a maximum of 24 hours from granting trust, an 8 hour idle window, or when the underlying connection to the proximate physical device is lost.

  • 9.11.2 Strongbox : Making insider attack resistance (IAR) a necessary requirement.

    See revision

    • [C-SR] are STRONGLY RECOMMENDED [C-1-12] MUST provide insider attack resistance (IAR), which means that an insider with access to firmware signing keys cannot produce firmware that causes the StrongBox to leak secrets, to bypass functional security requirements or otherwise enable access to sensitive user data. The recommended way to implement IAR is to allow firmware updates only when the primary user password is provided via the IAuthSecret HAL. IAR will likely become a requirement in a future release.

  • 9.11.3 Identity Credential : Added information about the Identity Credential system reference implementation.

    See revision

    The Identity Credential System is defined and achieved by implementing all APIs in the android.security.identity.* package. These APIs allows app developers to store and retrieve user identity documents. Device implementations:

    • [C-0-5] The upstream Android Open Source Project provides a reference implementation of a trusted application ( libeic ) that can be used to implement the Identity Credential system.

  • 9.11.4 ID Attestation : Added a section for ID attestation requirement.

    See revision

    9.11.4. ID Attestation

    Device implementations MUST support ID attestation .

  • 9.17 Android Virtualization Framework : Added a requirements section for Android Virtualization Framework.

    See revision

    9.17. Android Virtualization Framework

    If the device implements support for the Android Virtualization Framework APIs ( android.system.virtualmachine.* ), the Android host:

    • [C-1-1] MUST support all the APIs defined by the android.system.virtualmachine.* package.
    • [C-1-2] MUST NOT modify the Android SELinux and permission model for the management of Protected Virtual Machines.
    • [C-1-3] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy provided in the upstream Android Open Source Project (AOSP) and the policy MUST compile with all neverallow rules present.
    • [C-1-4] MUST NOT allow untrusted code (eg 3p apps) to create and run a Protected Virtual Machine. Note: This might change in future Android releases.
    • [C-1-5] MUST NOT allow a Protected Virtual Machine to execute code that is not part of the factory image or their updates. Anything that is not covered by Android Verified Boot (eg files downloaded from the Internet or sideloaded) MUST NOT be allowed to be run in a Protected Virtual Machine.

    If the device implements support for the Android Virtualization Framework APIs ( android.system.virtualmachine.* ), then any Protected Virtual Machine instance:

    • [C-2-1] MUST be able to run all operating systems available in the virtualization APEX in a Protected Virtual Machine.
    • [C-2-2] MUST NOT allow a Protected Virtual Machine to run an operating system that is not signed by the device implementor or OS vendor.
    • [C-2-3] MUST NOT allow a Protected Virtual Machine to execute data as code (eg SELinux neverallow execmem).
    • [C-2-4] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy/microdroid provided in the upstream Android Open Source Project (AOSP).
    • [C-2-5] MUST implement Protected Virtual Machine defense-in-depth mechanisms (eg SELinux for pVMs) even for non-Microdroid operating systems.
    • [C-2-6] MUST ensure that the pVM firmware refuses to boot if it cannot verify the initial image.
    • [C-2-7] MUST ensure that the pVM firmware refuses to boot if the integrity of the instance.img is compromised.

    If the device implements support for the Android Virtualization Framework APIs ( android.system.virtualmachine.* ), then the hypervisor:

    • [C-3-1] MUST NOT allow any pVM to have access to a page belonging to another entity (ie other pVM or hypervisor), unless explicitly shared by the page owner. This includes the host VM. This applies to both CPU and DMA accesses.
    • [C-3-2] MUST wipe a page after it is used by a VM and before it is returned to the host (eg the pVM is destroyed).
    • [C-3-3] MUST ensure that the pVM firmware is loaded and executed prior to any code in a pVM.
    • [C-3-4] MUST ensure that BCC and CDIs provided to a pVM instance can only be derived by that particular instance.

    If the device implements support for the Android Virtualization Framework APIs, then across all areas:

    • [C-4-1] MUST NOT provide functionality to a pVM that allows bypassing the Android Security Model.

    If the device implements support for the Android Virtualization Framework APIs, then:

    • [C-5-1] MUST support Isolated Compilation of an ART runtime update.

    If the device implements support for the Android Virtualization Framework APIs, then for Key Management:

    • [C-6-1] MUST root DICE chain at a point that the user cannot modify, even on unlocked devices. (To ensure it cannot be spoofed).
    • [C-6-2] MUST do DICE properly ie provide the correct values. But it might not have to go to that level of detail.

Back to top