Android 14
8 April 2024
2. Jenis Perangkat
Lihat revisi
Mulai persyaratan baru
Jika implementasi perangkat Genggam menyatakan
FEATURE_BLUETOOTH_LE
, implementasi tersebut:- [ 7.4 .3/H-1-3] HARUS mengukur dan mengkompensasi offset Rx untuk memastikan median BLE RSSI adalah -50dBm +/-15 dB pada jarak 1m dari perangkat referensi yang mentransmisikan pada
ADVERTISE_TX_POWER_HIGH
. - [ 7.4 .3/H-1-4] HARUS mengukur dan mengkompensasi offset Tx untuk memastikan median BLE RSSI adalah -50dBm +/-15 dB saat memindai dari perangkat referensi yang diposisikan pada jarak 1m dan mentransmisikan pada
ADVERTISE_TX_POWER_HIGH
.
- [ 7.4 .3/H-1-3] HARUS mengukur dan mengkompensasi offset Rx untuk memastikan median BLE RSSI adalah -50dBm +/-15 dB pada jarak 1m dari perangkat referensi yang mentransmisikan pada
Lihat revisi
Jika implementasi perangkat Genggam mendukung System API
HotwordDetectionService
atau mekanisme lain untuk deteksi kata cepat tanpa indikasi akses mikrofon, maka implementasi tersebut:- [9.8/H-1-6] TIDAK BOLEH mengizinkan lebih dari 100 byte data dikirim keluar dari layanan deteksi kata cepat pada setiap hasil kata cepat yang berhasil kecuali untuk data audio yang melewati HotwordAudioStream .
Lihat revisi
Ubah [9.8/H-1-13] menjadi:
- [9.8/H-SR-3] SANGAT DIREKOMENDASIKAN untuk memulai ulang proses yang menghosting layanan deteksi kata cepat setidaknya sekali setiap jam atau setiap 30 peristiwa pemicu perangkat keras, mana saja yang lebih dulu.
Lihat revisi
Persyaratan yang dihapus [9.8.2/H-4-3], [9.8.2/H-4-4], [9.8.2/H-5-3].
Lihat revisi
Jika implementasi perangkat Genggam menampilkan
android.os.Build.VERSION_CODES.U
untukandroid.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, maka implementasi tersebut:- [ 7.5 /H-1-3] HARUS mendukung properti
android.info.supportedHardwareLevel
sebagaiFULL
atau lebih baik untuk kamera utama belakang danLIMITED
atau lebih baik untuk kamera utama depan.
- [ 7.5 /H-1-3] HARUS mendukung properti
Lihat revisi
Jika implementasi perangkat Televisi tidak memiliki layar internal, namun mendukung layar eksternal yang tersambung melalui HDMI, perangkat tersebut:
- [ 5.8 /T-0-1] HARUS mengatur mode output HDMI ke resolusi tertinggi untuk format piksel yang dipilih yang berfungsi dengan kecepatan refresh 50Hz atau 60Hz untuk layar eksternal, tergantung pada kecepatan refresh video untuk wilayah perangkat tersebut dijual masuk.
HARUS mengatur mode output HDMI untuk memilih resolusi maksimum yang dapat didukung dengan kecepatan refresh 50Hz atau 60Hz.
- [ 5.8 /T-0-1] HARUS mengatur mode output HDMI ke resolusi tertinggi untuk format piksel yang dipilih yang berfungsi dengan kecepatan refresh 50Hz atau 60Hz untuk layar eksternal, tergantung pada kecepatan refresh video untuk wilayah perangkat tersebut dijual masuk.
3. Perangkat Lunak
Lihat revisi
- Persyaratan yang dihapus [C-1-9]
5. Kompatibilitas Multimedia
Lihat revisi
Jika penerapan perangkat mendeklarasikan dukungan untuk dekoder Dolby Vision melalui
HDR_TYPE_DOLBY_VISION
, penerapan tersebut:- [C-1-3] HARUS mengatur ID track dari lapisan dasar yang kompatibel ke belakang (jika ada) agar sama dengan ID track gabungan lapisan Dolby Vision.
7. Kompatibilitas Perangkat Keras
7.1.1.1. Ukuran dan Bentuk Layar :
Lihat revisi
Jika implementasi perangkat mendukung layar yang mampu melakukan konfigurasi ukuran
UI_MODE_TYPE_NORMAL
dan menggunakan tampilan fisik dengan sudut membulat untuk merender layar ini, maka implementasi tersebut:- [C-1-1] HARUS memastikan bahwa setidaknya satu dari persyaratan berikut terpenuhi untuk setiap tampilan tersebut:
- Ketika kotak
berukuran 15dan 18 dp kali1518 dp dipasang di setiap sudut tampilan logis, setidaknya satu piksel dari setiap kotak terlihat di layar.
- Ketika kotak
- [C-1-1] HARUS memastikan bahwa setidaknya satu dari persyaratan berikut terpenuhi untuk setiap tampilan tersebut:
Lihat revisi
Menerapkan kembali persyaratan berikut:
Jika implementasi perangkat mendeklarasikan
FEATURE_BLUETOOTH_LE
, implementasi tersebut:[C-SR-2] SANGAT DIREKOMENDASIKAN untuk mengukur dan mengkompensasi offset Rx untuk memastikan median BLE RSSI adalah -60dBm +/-10 dB pada jarak 1m dari perangkat referensi yang bertransmisi pada
ADVERTISE_TX_POWER_HIGH
, di mana perangkat diorientasikan sedemikian rupa sehingga pada 'bidang paralel' dengan layar menghadap ke arah yang sama.[C-SR-3] SANGAT DIREKOMENDASIKAN untuk mengukur dan mengkompensasi offset Tx untuk memastikan median BLE RSSI adalah -60dBm +/-10 dB ketika memindai dari perangkat referensi yang diposisikan pada jarak 1m dan mentransmisikan pada
ADVERTISE_TX_POWER_HIGH
, di mana perangkat berorientasi sedemikian rupa sehingga mereka berada pada 'bidang paralel' dengan layar menghadap ke arah yang sama.
Lihat revisi
Persyaratan [C-10-3] dan [C-10-4] dipindahkan ke 2.2.1. Perangkat keras .
- [C-10-3] HARUS mengukur dan mengkompensasi offset Rx untuk memastikan median BLE RSSI adalah -55dBm +/-10 dB pada jarak 1m dari perangkat referensi yang mentransmisikan pada
ADVERTISE_TX_POWER_HIGH
. - [C-10-4] HARUS mengukur dan mengkompensasi offset Tx untuk memastikan median BLE RSSI adalah -55dBm +/-10 dB ketika memindai dari perangkat referensi yang diposisikan pada jarak 1m dan mentransmisikan pada
ADVERTISE_TX_POWER_HIGH
.
20 November 2023
2. Jenis Perangkat
Lihat revisi
Jika implementasi perangkat Genggam menyatakan dukungan terhadap ABI 64-bit (dengan atau tanpa ABI 32-bit):
Lihat revisi
- [ 7.5 /H-1-13] HARUS mendukung kemampuan
LOGICAL_MULTI_CAMERA
untuk kamera belakang utama jika terdapat lebih dari 1 kamera belakang RGB.
- [ 7.5 /H-1-13] HARUS mendukung kemampuan
Lihat revisi
[ 5.8 /T-0-1] HARUS mengatur mode output HDMI ke resolusi tertinggi untuk format SDR atau HDR yang dipilih yang berfungsi dengan kecepatan refresh 50Hz atau 60Hz untuk layar eksternal.
HARUS mengatur mode output HDMI untuk memilih resolusi maksimum yang dapat didukung dengan kecepatan refresh 50Hz atau 60Hz.
Lihat revisi
- [9/W-0-1] HARUS mendeklarasikan
android.hardware.security.model.compatible feature
.
- [9/W-0-1] HARUS mendeklarasikan
6. Kompatibilitas Alat Pengembang dan Opsi
Lihat revisi
- [C-0-12] HARUS menulis Atom
LMK_KILL_OCCURRED_FIELD_NUMBER
ke
Lihat revisi
- [C-0-13] HARUS mengimplementasikan perintah shell
dumpsys gpu --gpuwork
untuk ditampilkan
- [C-0-12] HARUS menulis Atom
9. Kompatibilitas Model Keamanan
Lihat revisi
Jika implementasi perangkat menggunakan kernel Linux yang mampu mendukung SELinux, maka:
Lihat revisi
Jika implementasi perangkat menggunakan kernel selain Linux atau Linux tanpa SELinux, maka:
4 Oktober 2023
2. Jenis Perangkat
Lihat revisi
Implementasi perangkat Android diklasifikasikan sebagai Genggam jika memenuhi seluruh kriteria berikut:
- Memiliki ukuran layar diagonal fisik dalam kisaran 4 inci
3,3 inci (atau 2,5 inci untuk implementasi perangkat yang dikirimkan pada API level 29 atau lebih lama)hingga 8 inci.
Mulai persyaratan baru
- Memiliki antarmuka input layar sentuh.
- Memiliki ukuran layar diagonal fisik dalam kisaran 4 inci
Lihat revisi
Implementasi perangkat genggam:
- [ 7.1 .1.1/H-0-1] HARUS memiliki setidaknya satu
tampilan yang kompatibel dengan Android yang memenuhi semua persyaratan yang dijelaskan dalam dokumen ini.layar yang berukuran setidaknya 2,2” pada tepi pendek dan 3,4” pada tepi panjang.
Jika implementasi perangkat Genggam mendukung rotasi layar perangkat lunak, maka:
- [ 7.1 .1.1/H-1-1]* HARUS membuat layar logis yang tersedia untuk aplikasi pihak ketiga berukuran minimal 2 inci pada tepi pendek dan 2,7 inci pada tepi panjang. Perangkat yang dikirimkan pada Android API level 29 atau lebih lama MUNGKIN dikecualikan dari persyaratan ini.
Jika implementasi perangkat Genggam tidak mendukung rotasi layar perangkat lunak, maka:
- [ 7.1 .1.1/H-2-1]* HARUS membuat layar logis yang tersedia untuk aplikasi pihak ketiga setidaknya berukuran 2,7 inci pada tepi pendeknya. Perangkat yang dikirimkan pada Android API level 29 atau lebih lama MUNGKIN dikecualikan dari persyaratan ini.
Mulai persyaratan baru
[ 7.1 .1.1/H-0-3]* HARUS memetakan setiap tampilan
UI_MODE_NORMAL
yang tersedia untuk aplikasi pihak ketiga ke area tampilan fisik tanpa halangan yang berukuran minimal 2,2” inci pada tepi pendek dan 3,4” inci pada tepi panjang.[ 7.1 .1.3/H-0-1]* HARUS menyetel nilai
DENSITY_DEVICE_STABLE
menjadi 92% atau lebih besar dari kepadatan fisik sebenarnya dari tampilan terkait.
Jika implementasi perangkat Genggam mendeklarasikan
android.hardware.audio.output
danandroid.hardware.microphone
, keduanya:[ 5.6 /H-1-1] HARUS memiliki latensi Mean Continuous Round-Trip sebesar 300 milidetik atau kurang dalam 5 pengukuran, dengan Mean Absolute Deviation kurang dari 30 md , pada jalur data berikut: "speaker ke mikrofon", 3,5 mm adaptor loopback (jika didukung), loopback USB (jika didukung).
[ 5.6 /H-1-2] HARUS memiliki latensi Tap-to-tone rata-rata 300 milidetik atau kurang selama setidaknya 5 pengukuran melalui jalur data speaker ke mikrofon.
Jika implementasi perangkat Genggam mencakup setidaknya satu aktuator haptik, maka implementasi tersebut:
- [ 7.10 /H]* TIDAK BOLEH menggunakan aktuator haptic (vibrator) massa berputar eksentrik (ERM).
- [ 7.10 /H]* HARUS mengimplementasikan semua konstanta publik untuk haptics yang jelas di android.view.HapticFeedbackConstants yaitu (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE _START dan GESTURE_END).
- [ 7.10 /H]* HARUS mengimplementasikan semua konstanta publik untuk haptics yang jelas di android.os.VibrationEffect yaitu (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK dan EFFECT_DOUBLE_CLICK) dan semua konstanta
PRIMITIVE_*
publik yang layak untuk haptics kaya di android.os.VibrationEffect.Composition yaitu ( KLIK, CENTANG, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). Beberapa dari primitif ini, seperti LOW_TICK dan SPIN mungkin hanya dapat dilakukan jika vibrator dapat mendukung frekuensi yang relatif rendah. - [7.10/H]* HARUS mengikuti panduan untuk memetakan konstanta publik di android.view.HapticFeedbackConstants ke konstanta android.os.VibrationEffect yang direkomendasikan, dengan hubungan amplitudo yang sesuai.
- [ 7.10 /H]* HARUS mengikuti penilaian kualitas untuk API createOneShot() dan createWaveform() .
- [ 7.10 /H]* HARUS memverifikasi bahwa hasil API android.os.Vibrator.hasAmplitudeControl() publik mencerminkan kemampuan vibratornya dengan benar.
- [ 7.10 /H]* HARUS menempatkan penempatan aktuator di dekat lokasi di mana perangkat biasanya dipegang atau disentuh oleh tangan.
Jika implementasi perangkat Genggam mencakup setidaknya satu aktuator resonansi linier tujuan umum 7.10 , maka implementasi tersebut:
- [ 7.10 /H] HARUS menempatkan penempatan aktuator di dekat lokasi di mana perangkat biasanya dipegang atau disentuh oleh tangan.
- [ 7.10 /H] HARUS menggerakkan aktuator haptik pada sumbu X (kiri-kanan) dari orientasi
potretalami perangkat .
Jika implementasi perangkat Genggam memiliki aktuator haptik tujuan umum yaitu aktuator resonansi linier (LRA) sumbu X, maka:
- [ 7.10 /H] HARUS memiliki frekuensi resonansi LRA sumbu X di bawah 200 Hz.
- [ 7.1 .1.1/H-0-1] HARUS memiliki setidaknya satu
Lihat revisi
Implementasi perangkat genggam HARUS mendukung format pengkodean video berikut dan membuatnya tersedia untuk aplikasi pihak ketiga:
- [ 5.2 /H-0-3] AV1
Implementasi perangkat genggam HARUS mendukung format decoding video berikut dan membuatnya tersedia untuk aplikasi pihak ketiga:
- [ 5.3 /H-0-6] AV1
Lihat revisi
Jika implementasi perangkat termasuk tombol navigasi fungsi terkini seperti yang dirinci di bagian 7.2.3 mengubah antarmuka, maka:
- [ 3.8 .3/H-1-1] HARUS menerapkan perilaku penyematan layar dan menyediakan menu pengaturan kepada pengguna untuk mengaktifkan fitur tersebut.
Jika penerapan perangkat Genggam menyertakan dukungan untuk
ControlsProviderService
danControl
API serta mengizinkan aplikasi pihak ketiga untuk memublikasikan kontrol perangkat , maka penerapan tersebut:- [ 3.8 .16/H-1-6] Implementasi perangkat HARUS secara akurat memberikan keterjangkauan pengguna sebagai berikut:
- Jika perangkat telah menyetel
config_supportsMultiWindow=true
dan aplikasi mendeklarasikan metadataMETA_DATA_PANEL_ACTIVITY
dalam deklarasiControlsProviderService
, termasuk ComponentName aktivitas yang valid (sebagaimana ditentukan oleh API), maka aplikasi HARUS menyematkan aktivitas tersebut dalam kemampuan pengguna ini. - Jika aplikasi tidak mendeklarasikan metadata
META_DATA_PANEL_ACTIVITY
, maka aplikasi HARUS merender kolom tertentu seperti yang disediakan olehControlsProviderService
API serta kolom tertentu yang disediakan oleh Control API.
- Jika perangkat telah menyetel
- [ 3.8 .16/H-1-7] Jika aplikasi mendeklarasikan metadata
META_DATA_PANEL_ACTIVITY
, aplikasi HARUS meneruskan nilai pengaturan yang ditentukan di [3.8.16/H-1-5] menggunakanEXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS
saat meluncurkan aktivitas yang disematkan.
Jika implementasi perangkat memungkinkan pengguna melakukan panggilan apa pun, mereka akan
- [ 7.4.1.2 /H-0-1] HARUS mendeklarasikan tanda fitur
android.software.telecom
. - [ 7.4.1.2 /H-0-2] HARUS mengimplementasikan kerangka telekomunikasi .
2.2.4. Performa dan Kekuatan :
Lihat revisi
Implementasi perangkat genggam:
- [ 8.5 /H-0-1] HARUS menyediakan kemampuan pengguna
di menu Pengaturanuntuk melihat semua aplikasi dengan layanan latar depan aktif atau pekerjaan yang dimulai oleh pengguna, termasuk durasi setiap layanan ini sejak dimulai seperti yang dijelaskan dalam dokumen SDK .dan kemampuan untuk menghentikan aplikasi yang menjalankan layanan latar depan atau pekerjaan yang dimulai oleh pengguna.dengan kemampuan untuk menghentikan aplikasi yang menjalankan layanan latar depan dan menampilkan semua aplikasi yang memiliki layanan latar depan aktif dan durasi masing-masing layanan ini sejak dimulai seperti yang dijelaskan dalam dokumen SDK .- Beberapa aplikasi MUNGKIN dikecualikan dari penghentian atau terdaftar dalam keterjangkauan pengguna seperti yang dijelaskan dalam dokumen SDK .
- [ 8.5 /H-0-1] HARUS menyediakan kemampuan pengguna
- [ 8.5 /H-0-2]HARUS memberikan kemampuan kepada pengguna untuk menghentikan aplikasi yang menjalankan layanan latar depan atau pekerjaan yang dimulai oleh pengguna.
Lihat revisi
Jika implementasi perangkat menyatakan dukungan untuk android.hardware.telephony
, implementasi tersebut:
- [ 9.5 /H-1-1] TIDAK HARUS menyetel
UserManager.isHeadlessSystemUserMode
ketrue
.
Jika penerapan perangkat memiliki layar kunci yang aman dan menyertakan satu atau beberapa agen kepercayaan, yang mengimplementasikan TrustAgentService
System API, penerapan tersebut:
- [ 9.11.1 /H-1-1] HARUS menantang pengguna untuk salah satu metode otentikasi utama yang direkomendasikan (misalnya: PIN, pola, kata sandi) lebih dari sekali setiap 72 jam.
Jika implementasi perangkat Genggam menyetel UserManager.isHeadlessSystemUserMode
ke true
, maka implementasi tersebut
Jika implementasi perangkat Genggam mendukung System API HotwordDetectionService
atau mekanisme lain untuk deteksi kata cepat tanpa indikasi akses mikrofon, maka implementasi tersebut:
- [9.8/H-1-1] HARUS memastikan layanan deteksi kata cepat hanya dapat mengirimkan data ke Sistem,
ContentCaptureService
, atau layanan pengenalan ucapan pada perangkat yang dibuat olehSpeechRecognizer#createOnDeviceSpeechRecognizer()
. - [9.8/H-1-6] TIDAK BOLEH mengizinkan lebih dari 100 byte data (tidak termasuk aliran audio) untuk dikirim keluar dari layanan deteksi kata cepat pada setiap hasil kata cepat yang berhasil.
- [9.8/H-1-15] HARUS memastikan bahwa aliran audio yang disediakan pada hasil kata cepat yang berhasil ditransmisikan satu arah dari layanan deteksi kata cepat ke layanan interaksi suara.
Jika implementasi perangkat menyertakan aplikasi yang menggunakan System API HotwordDetectionService
, atau mekanisme serupa untuk deteksi kata cepat tanpa indikasi penggunaan mikrofon, aplikasi tersebut:
- [9.8/H-2-3] TIDAK BOLEH mengirimkan dari layanan deteksi kata cepat, data audio, data yang dapat digunakan untuk merekonstruksi (seluruhnya atau sebagian) audio, atau konten audio yang tidak terkait dengan kata cepat itu sendiri, kecuali ke
ContentCaptureService
atau layanan pengenalan suara pada perangkat.
Jika implementasi perangkat Genggam mendukung System API VisualQueryDetectionService
atau mekanisme lain untuk deteksi kueri tanpa indikasi akses mikrofon dan/atau kamera, maka implementasi tersebut:
- [9.8/H-3-1] HARUS memastikan layanan deteksi kueri hanya dapat mengirimkan data ke Sistem, atau
ContentCaptureService
, atau layanan pengenalan suara pada perangkat (dibuat olehSpeechRecognizer#createOnDeviceSpeechRecognizer()
). - [9.8/H-3-2] TIDAK BOLEH mengizinkan informasi audio atau video apa pun dikirim keluar dari
VisualQueryDetectionService
, kecuali keContentCaptureService
atau layanan pengenalan ucapan pada perangkat. - [9.8/H-3-3] HARUS menampilkan pemberitahuan pengguna di UI Sistem ketika perangkat mendeteksi niat pengguna untuk berinteraksi dengan Aplikasi Asisten Digital (misalnya dengan mendeteksi keberadaan pengguna melalui kamera).
- [9.8/H-3-4] HARUS menampilkan indikator mikrofon dan menampilkan kueri pengguna yang terdeteksi di UI tepat setelah kueri pengguna terdeteksi.
- [9.8/H-3-5] TIDAK BOLEH mengizinkan aplikasi yang dapat diinstal pengguna menyediakan layanan deteksi kueri visual.
Lihat revisi
Jika implementasi perangkat Genggam menampilkan android.os.Build.VERSION_CODES.T
untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, maka implementasi tersebut:
- HARUS memenuhi persyaratan media yang tercantum di CDD Android 13 bagian 2.2.7.1 .
Mulai persyaratan baru
Jika implementasi perangkat Genggam menampilkanandroid.os.Build.VERSION_CODES.U
untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, maka implementasi tersebut:- [5.1/H-1-1] HARUS mengiklankan jumlah maksimum sesi decoder video perangkat keras yang dapat dijalankan secara bersamaan dalam kombinasi codec apa pun melalui metode
CodecCapabilities.getMaxSupportedInstances()
danVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-2] HARUS mendukung 6 contoh sesi decoder video perangkat keras 8-bit (SDR) (AVC, HEVC, VP9, AV1 atau lebih baru) dalam kombinasi codec apa pun yang berjalan bersamaan dengan 3 sesi pada resolusi 1080p@30 fps dan 3 sesi pada resolusi 4k@30fps, kecuali AV1. Codec AV1 hanya diperlukan untuk mendukung resolusi 1080p, namun tetap diperlukan untuk mendukung 6 instance pada 1080p30fps.
- [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()
danVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-4] HARUS mendukung 6 sesi encoder video perangkat keras 8-bit (SDR) (AVC, HEVC, VP9, AV1 atau lebih baru) dalam kombinasi codec apa pun yang berjalan bersamaan dengan 4 sesi pada resolusi 1080p@30 fps dan 2 sesi pada resolusi 4k@30fps, kecuali AV1. Codec AV1 hanya diperlukan untuk mendukung resolusi 1080p, namun tetap diperlukan untuk mendukung 6 instance pada 1080p30fps.
- [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()
danVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-6] HARUS mendukung 6 instance decoder video perangkat keras 8-bit (SDR) dan sesi encoder video perangkat keras (AVC, HEVC, VP9, AV1 atau lebih baru) dalam kombinasi codec apa pun yang berjalan bersamaan dengan 3 sesi pada 4K Resolusi @30fps (kecuali AV1), yang mana paling banyak 2 sesi encoder dan 3 sesi pada resolusi 1080p. Codec AV1 hanya diperlukan untuk mendukung resolusi 1080p, namun tetap diperlukan untuk mendukung 6 instance pada 1080p30fps.
- [5.1/H-1-19] HARUS mendukung 3 instance decoder video perangkat keras 10-bit (HDR) dan sesi encoder video perangkat keras (AVC, HEVC, VP9, AV1 atau lebih baru) dalam kombinasi codec apa pun yang berjalan secara bersamaan pada resolusi 4K@30fps (kecuali AV1) yang paling banyak 1 adalah sesi encoder, yang dapat dikonfigurasi dalam format input RGBA_1010102 melalui permukaan GL. Pembuatan metadata HDR oleh pembuat enkode tidak diperlukan jika pengkodean dari permukaan GL. Sesi codec AV1 hanya diperlukan untuk mendukung resolusi 1080p meskipun persyaratan ini memerlukan 4K.
- [5.1/H-1-7] HARUS memiliki latensi inisialisasi codec 40 ms atau kurang untuk sesi pengkodean video 1080p atau lebih kecil untuk semua pembuat enkode video perangkat keras saat sedang dimuat. Pemuatan di sini didefinisikan sebagai sesi transcoding khusus video 1080p hingga 720p secara bersamaan menggunakan codec video perangkat keras bersama dengan inisialisasi perekaman audio-video 1080p. Untuk codec Dolby vision, latensi inisialisasi codec HARUS 50 ms atau kurang.
- [5.1/H-1-8] HARUS memiliki latensi inisialisasi codec 30 ms atau kurang untuk sesi pengkodean audio kecepatan bit 128 kbps atau lebih rendah untuk semua encoder audio saat sedang dimuat. Pemuatan di sini didefinisikan sebagai sesi transcoding khusus video 1080p hingga 720p secara bersamaan menggunakan codec video perangkat keras bersama dengan inisialisasi perekaman audio-video 1080p.
- [5.1/H-1-9] HARUS mendukung 2 contoh sesi decoder video perangkat keras yang aman (AVC, HEVC, VP9, AV1 atau lebih baru) dalam kombinasi codec apa pun yang berjalan secara bersamaan pada resolusi 4k@30 fps (kecuali AV1) untuk keduanya 8- bit (SDR) dan konten HDR 10-bit. Sesi codec AV1 hanya diperlukan untuk mendukung resolusi 1080p meskipun persyaratan ini memerlukan 4K.
- [5.1/H-1-10] HARUS mendukung 3 contoh sesi dekoder video perangkat keras yang tidak aman bersama dengan 1 contoh sesi dekoder video perangkat keras yang aman (total 4 contoh) (AVC, HEVC, VP9, AV1 atau lebih baru) dalam codec apa pun kombinasi berjalan bersamaan dengan 3 sesi pada resolusi 4K@30 fps (kecuali AV1) yang mencakup satu sesi dekoder aman dan 1 sesi aman pada resolusi 1080p@30fps dengan maksimal 2 sesi dapat dalam HDR 10-bit. Sesi codec AV1 hanya diperlukan untuk mendukung resolusi 1080p meskipun persyaratan ini memerlukan 4K.
- [5.1/H-1-11] HARUS mendukung dekoder aman untuk setiap dekoder AVC, HEVC, VP9, atau AV1 perangkat keras pada perangkat.
- [5.1/H-1-12] HARUS memiliki latensi inisialisasi codec 40 ms atau kurang untuk sesi decoding video 1080p atau lebih kecil untuk semua decoder video perangkat keras saat sedang dimuat. Pemuatan di sini didefinisikan sebagai sesi transcoding khusus video 1080p hingga 720p secara bersamaan menggunakan codec video perangkat keras bersama dengan inisialisasi pemutaran audio-video 1080p. Untuk codec Dolby vision, latensi inisialisasi codec HARUS 50 ms atau kurang.
- [5.1/H-1-13] HARUS memiliki latensi inisialisasi codec 30 ms atau kurang untuk sesi decoding audio kecepatan bit 128 kbps atau lebih rendah untuk semua decoder audio saat sedang dimuat. Pemuatan di sini didefinisikan sebagai sesi transcoding khusus video 1080p hingga 720p secara bersamaan menggunakan codec video perangkat keras bersama dengan inisialisasi pemutaran audio-video 1080p.
- [5.1/H-1-14] HARUS mendukung dekoder perangkat keras AV1 Main 10, Level 4.1 dan butiran film.
- [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 BOLEH menjatuhkan lebih dari 1 frame dalam 10 detik (yaitu kurang dari 0,167 persen penurunan frame) untuk sesi video 4K 60 fps yang sedang dimuat.
- [5.3/H-1-2] TIDAK BOLEH menjatuhkan lebih dari 1 frame dalam 10 detik selama perubahan resolusi video dalam sesi video 60 fps yang dimuat untuk sesi 4K.
- [5.6/H-1-1] HARUS memiliki latensi tap-to-tone 80 milidetik atau kurang menggunakan uji tap-to-tone CTS Verifier.
- [5.6/H-1-2] HARUS memiliki latensi audio bolak-balik sebesar 80 milidetik atau kurang pada setidaknya satu jalur data yang didukung.
- [5.6/H-1-3] HARUS mendukung audio >=24-bit untuk output stereo melalui jack audio 3,5 mm jika ada dan melalui audio USB jika didukung melalui seluruh jalur data untuk konfigurasi streaming dan latensi rendah. Untuk konfigurasi latensi rendah, AAudio harus digunakan oleh aplikasi dalam mode callback latensi rendah. Untuk konfigurasi streaming, Java AudioTrack harus digunakan oleh aplikasi. Dalam konfigurasi latensi rendah dan streaming, sink keluaran HAL harus menerima
AUDIO_FORMAT_PCM_24_BIT
,AUDIO_FORMAT_PCM_24_BIT_PACKED
,AUDIO_FORMAT_PCM_32_BIT
atauAUDIO_FORMAT_PCM_FLOAT
untuk format keluaran targetnya. - [5.6/H-1-4] HARUS mendukung >=4 saluran perangkat audio USB (Ini digunakan oleh pengontrol DJ untuk melihat pratinjau lagu.)
- [5.6/H-1-5] HARUS mendukung perangkat MIDI yang sesuai dengan kelasnya dan mendeklarasikan tanda fitur MIDI.
- [5.6/H-1-9] HARUS mendukung setidaknya 12 saluran pencampuran. Ini menyiratkan kemampuan untuk membuka AudioTrack dengan topeng saluran 7.1.4 dan mengatur spasial atau men-downmix semua saluran ke stereo dengan benar.
- [5.6/H-SR] SANGAT DIREKOMENDASIKAN untuk mendukung pencampuran 24 saluran dengan setidaknya dukungan untuk masker saluran 9.1.6 dan 22.2.
- [5.7/H-1-2] HARUS mendukung
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL
dengan kemampuan dekripsi konten di bawah ini.
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 | 500KiB |
Jumlah Minimum sesi bersamaan | 30 |
Jumlah Minimum kunci per sesi | 20 |
Jumlah Total Kunci Minimum (semua sesi) | 80 |
Jumlah Total Minimum Kunci DRM (semua sesi) | 6 |
Ukuran Pesan | 16KiB |
Frame yang didekripsi per Detik | 60fps |
- [5.1/H-1-17] HARUS memiliki setidaknya 1 dekoder gambar perangkat keras yang mendukung Profil Dasar AVIF.
- [5.1/H-1-18] HARUS mendukung encoder AV1 yang dapat mengkodekan hingga resolusi 480p pada 30fps dan 1Mbps.
-
[5.12/H-1-1] HARUS[5.12/H-SR] Sangat Disarankan untuk mendukung dukungan fiturFeature_HdrEditing
untuk semua encoder AV1 dan HEVC perangkat keras yang ada di perangkat. - [5.12/H-1-2] HARUS mendukung format warna RGBA_1010102 untuk semua encoder AV1 dan HEVC perangkat keras yang ada di perangkat.
- [5.12/H-1-3] HARUS mengiklankan dukungan untuk ekstensi EXT_YUV_target untuk mengambil sampel dari tekstur YUV dalam 8 dan 10-bit.
- [7.1.4/H-1-1] HARUS memiliki minimal 6 hardware overlay di Data processor unit (DPU) Hardware composer (HWC), dengan minimal 2 di antaranya mampu menampilkan konten video 10-bit.
Jika implementasi perangkat Genggam menampilkan android.os.Build.VERSION_CODES.U
untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
dan menyertakan dukungan untuk encoder AVC atau HEVC perangkat keras, maka implementasi tersebut:
- [5.2/H-2-1] HARUS memenuhi target kualitas minimum yang ditentukan oleh kurva distorsi laju encoder video untuk codec AVC dan HEVC perangkat keras, sebagaimana ditentukan dalam dokumentasi yang akan datang.
Lihat revisi
android.os.Build.VERSION_CODES.U
untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, maka implementasi tersebut:- [ 7.5 /H-1-1] HARUS memiliki kamera belakang utama dengan resolusi minimal 12 megapiksel yang mendukung pengambilan video pada 4k@30fps. Kamera belakang utama adalah kamera belakang dengan ID kamera terendah.
- [ 7.5 /H-1-2] HARUS memiliki kamera depan utama dengan resolusi minimal 6 megapiksel dan mendukung pengambilan video pada 1080p@30fps. Kamera depan utama adalah kamera depan dengan ID kamera terendah.
- [ 7.5 /H-1-3] HARUS mendukung properti
android.info.supportedHardwareLevel
sebagai LENGKAP atau lebih baik untuk kedua kamera utama. - [ 7.5 /H-1-4] HARUS mendukung
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME
untuk kedua kamera utama. - [ 7.5 /H-1-5] HARUS memiliki kamera2 latensi pengambilan JPEG < 1000
900ms untuk resolusi 1080p yang diukur dengan kamera CTS PerformanceTest dalam kondisi pencahayaan ITS (3000K) untuk kedua kamera utama. - [ 7.5 /H-1-6] HARUS memiliki latensi pengaktifan kamera2 (buka kamera ke bingkai pratinjau pertama) < 500 ms yang diukur oleh PerformanceTest kamera CTS dalam kondisi pencahayaan ITS (3000K) untuk kedua kamera utama.
- [ 7.5 /H-1-8] HARUS mendukung
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW
danandroid.graphics.ImageFormat.RAW_SENSOR
untuk kamera belakang utama. - [ 7.5 /H-1-9] HARUS memiliki kamera utama menghadap ke belakang yang mendukung 720p atau 1080p @ 240fps.
- [ 7.5 /H-1-10] HARUS memiliki min ZOOM_RATIO < 1.0 untuk kamera utama jika ada kamera RGB ultrawide yang menghadap ke arah yang sama.
- [ 7.5 /H-1-11] HARUS menerapkan streaming depan-belakang secara bersamaan pada kamera utama.
- [ 7.5 /H-1-12] HARUS mendukung
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
untuk kamera depan dan belakang utama. - [ 7.5 /H-1-13] HARUS mendukung kemampuan
LOGICAL_MULTI_CAMERA
untuk kamera utama jika terdapat lebih dari 1 kamera RGB yang menghadap ke arah yang sama. - [ 7.5 /H-1-14] HARUS mendukung kemampuan
STREAM_USE_CASE
untuk kamera depan dan belakang utama. - [ 7.5 /H-1-15] HARUS mendukung ekstensi mode
Bokeh &Malam melalui ekstensi CameraX dan Camera2 untuk kamera utama. - [ 7.5 /H-1-16] HARUS mendukung kemampuan DYNAMIC_RANGE_TEN_BIT untuk kamera utama.
- [ 7.5 /H-1-17] HARUS mendukung CONTROL_SCENE_MODE_FACE_PRIORITY dan deteksi wajah ( STATISTICS_FACE_DETECT_MODE_SIMPLE atau STATISTICS_FACE_DETECT_MODE_FULL ) untuk kamera utama.
Lihat revisi
android.os.Build.VERSION_CODES.U
untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, maka implementasi tersebut:- [7.1.1.1/H-2-1] HARUS memiliki resolusi layar minimal 1080p.
- [7.1.1.3/H-2-1] HARUS memiliki kepadatan layar minimal 400 dpi.
- [7.1.1.3/H-3-1] HARUS memiliki tampilan HDR yang mendukung rata-rata minimal 1000 nits.
- [7.6.1/H-2-1] HARUS memiliki memori fisik minimal 8 GB.
Lihat revisi
android.os.Build.VERSION_CODES.U
untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, maka implementasi tersebut:- [8.2/H-1-1] HARUS memastikan kinerja penulisan berurutan minimal 150 MB/s.
- [8.2/H-1-2] HARUS memastikan kinerja penulisan acak minimal 10 MB/s.
- [8.2/H-1-3] HARUS memastikan kinerja pembacaan berurutan minimal 250 MB/s.
- [8.2/H-1-4] HARUS memastikan kinerja pembacaan acak minimal 100 MB/s.
- [8.2/H-1-5] HARUS memastikan performa baca dan tulis sekuensial paralel dengan performa baca 2x dan 1x tulis minimal 50 MB/s.
Lihat revisi
Implementasi perangkat televisi HARUS mendukung format pengkodean video berikut dan membuatnya tersedia untuk aplikasi pihak ketiga:
- [ 5.2 /T-0-3] AV1
Implementasi perangkat televisi HARUS mendukung format decoding video berikut dan membuatnya tersedia untuk aplikasi pihak ketiga:
- [ 5.3.2 /T-0-7] AV1
Lihat revisi
Jika penerapan perangkat memiliki layar kunci yang aman dan menyertakan satu atau beberapa agen kepercayaan, yang mengimplementasikan TrustAgentService
System API, penerapan tersebut:
- [ 9.11.1 /W-1-1] HARUS menantang pengguna untuk salah satu metode otentikasi utama yang direkomendasikan (misalnya: PIN, pola, kata sandi) lebih dari sekali setiap 72 jam.
Lihat revisi
Jika implementasi perangkat menyertakan dukungan untuk radio siaran AM/FM dan memaparkan fungsionalitasnya ke aplikasi apa pun, maka implementasi tersebut:
- [ 7.4
.10/A-0-1] HARUS mendeklarasikan dukungan untukFEATURE_BROADCAST_RADIO
.
Kamera tampak eksterior adalah kamera yang memotret pemandangan di luar penerapan perangkat, seperti kamera pandangan belakang.
Implementasi perangkat otomotif:
- HARUS menyertakan satu atau lebih kamera tampak luar.
Jika implementasi perangkat Otomotif menyertakan kamera tampilan eksterior, untuk kamera tersebut, mereka:
- [ 7.5 /A-1-1] TIDAK HARUS memiliki kamera tampak luar yang dapat diakses melalui API Kamera Android , kecuali kamera tersebut mematuhi persyaratan inti kamera.
- [ 7.5 /A-SR-1] SANGAT DISARANKAN untuk tidak memutar atau mencerminkan pratinjau kamera secara horizontal.
- [ 7.5 /A-SR-2] SANGAT DIREKOMENDASIKAN memiliki resolusi minimal 1,3 megapiksel.
- HARUS memiliki perangkat keras fokus tetap atau EDOF (kedalaman bidang yang diperluas).
- MUNGKIN memiliki fokus otomatis perangkat keras atau fokus otomatis perangkat lunak yang diterapkan pada driver kamera.
Jika implementasi perangkat otomotif menyertakan satu atau lebih kamera tampilan eksterior, dan memuat layanan Exterior View System (EVS), maka untuk kamera tersebut, mereka:
- [ 7.5 /A-2-1] TIDAK BOLEH memutar atau mencerminkan pratinjau kamera secara horizontal.
Implementasi perangkat otomotif:
- MUNGKIN mencakup satu atau lebih kamera yang tersedia untuk aplikasi pihak ketiga.
Jika implementasi perangkat otomotif menyertakan setidaknya satu kamera dan menyediakannya untuk aplikasi pihak ketiga, maka implementasi tersebut:
- [ 7.5 /A-3-1] HARUS melaporkan tanda fitur
android.hardware.camera.any
. - [ 7.5 /A-3-2] TIDAK HARUS mendeklarasikan kamera sebagai kamera sistem .
- MUNGKIN mendukung kamera eksternal yang dijelaskan di bagian 7.5.3 .
- MUNGKIN mencakup fitur (seperti fokus otomatis, dll.) yang tersedia untuk kamera belakang seperti dijelaskan di bagian 7.5.1 .
Kamera menghadap ke belakang berarti kamera menghadap ke dunia yang dapat ditempatkan di mana saja pada kendaraan dan menghadap ke luar kabin kendaraan; yaitu, memotret pemandangan di sisi jauh bodi kendaraan, seperti kamera tampak belakang.
Kamera yang menghadap ke depan berarti kamera yang menghadap pengguna yang dapat ditempatkan di mana saja pada kendaraan dan menghadap ke dalam kabin kendaraan; yaitu gambar pengguna, seperti untuk konferensi video dan aplikasi sejenis.
Implementasi perangkat otomotif:
- [7.5/A-SR-1] SANGAT DIREKOMENDASIKAN untuk menyertakan satu atau lebih kamera menghadap dunia.
- MUNGKIN mencakup satu atau lebih kamera yang menghadap pengguna.
- [7.5/A-SR-2] SANGAT DIREKOMENDASIKAN untuk mendukung streaming beberapa kamera secara bersamaan.
Jika implementasi perangkat Otomotif mencakup setidaknya satu kamera yang menghadap ke dunia, maka untuk kamera tersebut, mereka:
- [7.5/A-1-1] HARUS diorientasikan agar dimensi panjang kamera sejajar dengan bidang XY sumbu sensor otomotif Android.
- [7.5/A-SR-3] SANGAT DIREKOMENDASIKAN untuk memiliki perangkat keras fokus tetap atau EDOF (Extend Depth of Field).
- [7.5/A-1-2] HARUS memiliki kamera utama yang menghadap ke dunia sebagai kamera yang menghadap ke dunia dengan ID kamera terendah.
Jika implementasi perangkat Otomotif menyertakan setidaknya satu kamera yang menghadap pengguna, maka untuk kamera tersebut:
- [7.5/A-2-1] Kamera utama yang menghadap pengguna HARUS merupakan kamera yang menghadap pengguna dengan ID kamera terendah.
- MUNGKIN diorientasikan agar dimensi panjang kamera sejajar dengan bidang XY sumbu sensor otomotif Android.
Jika implementasi perangkat Otomotif menyertakan kamera yang dapat diakses melalui android.hardware.Camera
atau android.hardware.camera2
API, maka implementasi tersebut:
- [7.5/A-3-1] HARUS mematuhi persyaratan kamera inti di bagian 7.5.
Jika implementasi perangkat Otomotif menyertakan kamera yang tidak dapat diakses melalui android.hardware.Camera
atau android.hardware.camera2
API, maka implementasi tersebut:
- [7.5/A-4-1] HARUS dapat diakses melalui layanan Extended View System.
Jika penerapan perangkat Otomotif menyertakan satu atau lebih kamera yang dapat diakses melalui Layanan Sistem Tampilan Diperluas, untuk kamera tersebut, kamera tersebut:
- [7.5/A-5-1] TIDAK BOLEH memutar atau mencerminkan pratinjau kamera secara horizontal.
- [7.5/A-SR-4] SANGAT DIREKOMENDASIKAN memiliki resolusi minimal 1,3 megapiksel.
Jika implementasi perangkat otomotif menyertakan satu atau lebih kamera yang dapat diakses melalui Extended View System Service dan android.hardware.Camera
atau android.hardware.Camera2
API, maka untuk kamera tersebut:
- [7.5/A-6-1] HARUS melaporkan ID Kamera yang sama.
Jika implementasi perangkat Otomotif menyediakan API kamera berpemilik, implementasi tersebut:
- [7.5/A-7-1] HARUS mengimplementasikan API kamera tersebut menggunakan API
android.hardware.camera2
atau API Sistem Tampilan Diperluas.
Lihat revisi
Implementasi perangkat otomotif:
- [ 3.8 /A-0-1] TIDAK BOLEH mengizinkan pengguna sekunder penuh yang bukan pengguna latar depan saat ini untuk meluncurkan aktivitas dan memiliki akses ke UI pada tampilan apa pun.
Lihat revisi
Jika implementasi perangkat Otomotif mendeklarasikan android.hardware.microphone
, implementasi tersebut akan:
- [ 9.8.2 /A-1-1] HARUS menampilkan indikator mikrofon ketika aplikasi mengakses data audio dari mikrofon, namun tidak ketika mikrofon hanya diakses oleh
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
atau aplikasi yang memegang peran yang disebutkan di bagian 9.1 dengan pengidentifikasi CDD [C-4-X]. - [ 9.8.2 /A-1-2] TIDAK HARUS menyembunyikan indikator mikrofon untuk aplikasi sistem yang memiliki antarmuka pengguna yang terlihat atau interaksi pengguna langsung.
- [ 9.8.2 /A-1-3] HARUS memberikan kemampuan pengguna untuk mengaktifkan mikrofon di aplikasi Pengaturan.
Jika implementasi perangkat Otomotif mendeklarasikan android.hardware.camera.any
, maka implementasi tersebut:
- [ 9.8.2 /A-2-1] HARUS menampilkan indikator kamera saat aplikasi mengakses data kamera langsung, namun tidak saat kamera hanya diakses oleh aplikasi yang memegang peran seperti yang
ditentukandalam Bagian 9.1 Izin dengan pengidentifikasi CDD [C-4-X][C-3-X].
- [ 9.8.2 /A-2-3] HARUS memberikan kemampuan pengguna untuk mengaktifkan kamera di aplikasi Pengaturan.
- [ 9.8.2 /A-2-4] HARUS menampilkan aplikasi Terbaru dan Aktif menggunakan kamera seperti yang dikembalikan dari
PermissionManager.getIndicatorAppOpUsageData()
, bersama dengan pesan atribusi apa pun yang terkait dengannya.
Jika penerapan perangkat memiliki layar kunci yang aman dan menyertakan satu atau beberapa agen kepercayaan, yang mengimplementasikan TrustAgentService
System API, penerapan tersebut:
- [ 9.11.1 /A-1-1] HARUS menantang pengguna untuk salah satu metode otentikasi utama yang direkomendasikan (misalnya: PIN, pola, kata sandi) lebih dari sekali setiap 336 jam.
3. Perangkat Lunak
3.1. Kompatibilitas API Terkelola :
Lihat revisi
Implementasi perangkat:
- [C-0-8] Tidak boleh mendukung pemasangan aplikasi yang menargetkan tingkat API kurang dari 23.
3.2.3.5. Maksud Aplikasi Bersyarat :
Lihat Revisi
Jika implementasi perangkat melaporkan
android.hardware.nfc.uicc
atauandroid.hardware.nfc.ese
, mereka:- [C-19-1] Harus mengimplementasikan API Intent NFCAdapter.Action_Transaction_Detected (sebagai “EVT_TRANSACTION” yang ditentukan oleh Persyaratan Handset Handset Asosiasi GSM Asosiasi Ts.26-NFC) .
3.3.1. Antarmuka Biner Aplikasi :
Lihat Revisi
Implementasi perangkat:
- [C-0-12] Harus mengekspor simbol fungsi untuk simbol fungsi Core
Vulkan 1.0Vulkan 1.1 , sertaVK_KHR_surface
,VK_KHR_android_surface
libvulkan.so
VK_KHR_swapchain
,VK_KHR_maintenance1
, danVK_KHR_get_physical_device_properties2
. Perhatikan bahwa sementara semua simbol harus ada, Bagian 7.1.4.2 menjelaskan secara lebih rinci persyaratan ketika implementasi penuh dari setiap fungsi yang sesuai diharapkan.
- [C-0-12] Harus mengekspor simbol fungsi untuk simbol fungsi Core
Lihat Revisi
Jika implementasi perangkat menyertakan output layar atau video, mereka:
- [C-1-5]
RAINBOW
EXPRESSIVE
palet warna warnaSPRITZ
menggunakan gaya tema warnaFRUIT_SALAD
disebutkan dalamSettings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
dokumentasiVIBRANT
lihatandroid.theme.customization.theme_styles
MONOCHROMATIC
,TONAL_SPOT
.
- [C-1-5]
Lihat Revisi
Jika implementasi perangkat termasuk tombol navigasi fungsi terkini seperti yang dirinci di bagian 7.2.3 mengubah antarmuka, maka:
- [C-1-2] harus mengimplementasikan perilaku pinning layar dan memberi pengguna menu Pengaturan untuk beralih fitur.
3.9.2 Dukungan profil yang dikelola :
Lihat Revisi
Jika implementasi perangkat mendeklarasikan
android.software.managed_users
, mereka:- [C-1-10] harus memastikan bahwa data tangkapan layar disimpan dalam penyimpanan profil kerja ketika tangkapan layar ditangkap dengan jendela
topActivity
yang memiliki fokus (salah satu pengguna berinteraksi dengan terakhir di antara semua kegiatan) dan termasuk dalam profil kerja aplikasi . - [C-1-11] Tidak boleh menangkap konten layar lain (bilah sistem, pemberitahuan atau konten profil pribadi apa pun) kecuali untuk jendela aplikasi profil kerja/windows saat menyimpan tangkapan layar ke profil kerja (untuk memastikan data profil pribadi adalah tidak disimpan di profil kerja).
- [C-1-10] harus memastikan bahwa data tangkapan layar disimpan dalam penyimpanan profil kerja ketika tangkapan layar ditangkap dengan jendela
3.9.5 Kerangka Resolusi Kebijakan Perangkat : Bagian Baru
Lihat Revisi
Jika implementasi perangkat melaporkan
android.software.device_admin
atauandroid.software.managed_users
, maka mereka:- [C-1-1] harus menyelesaikan konflik kebijakan perangkat seperti yang didokumentasikan dalam dokumentasi AOSP.
5. Kompatibilitas Multimedia
Lihat Revisi
Implementasi perangkat harus mendukung pengkodean pengkodean gambar berikut:
- [C-0-4] AVIF
- Perangkat harus mendukung profil
BITRATE_MODE_CQ
dan Baseline.
- Perangkat harus mendukung profil
- [C-0-4] AVIF
Lihat Revisi
Implementasi perangkat harus mendukung decoding pengkodean gambar berikut:
[C-0-7] AVIF (Profil Baseline)
Lihat Revisi
Format/Codec Detail Jenis file/format kontainer yang didukung jpeg Basis+progresif JPEG (.jpg) GIF GIF (.gif) PNG PNG (.png) BMP BMP (.bmp) WebP WebP (.webp) Mentah Arw (.arw), cr2 (.cr2), dng (.dng), nef (.nef), nrw (.nrw), orf (.orf), pef (.pef), raf (.raf), rw2 ( .rw2), srw (.srw) HEIF Gambar, koleksi gambar, urutan gambar Sheif (.heif), heic (.heic) Avif (profil dasar) Gambar, koleksi gambar, profil garis dasar urutan gambar Wadah sapi (.Avif) Lihat Revisi
Format/Codec Detail Jenis file/format wadah yang akan didukung H.263 - 3GPP (.3gp)
- MPEG-4 (.mp4)
- Matroska (.mkv, hanya decode)
H.264 AVC Lihat Bagian 5.2 dan 5.3 untuk detailnya - 3GPP (.3gp)
- MPEG-4 (.mp4)
- Mpeg-2 ts (.ts, tidak dicari)
- Matroska (.mkv, hanya decode)
H.265 HEVC Lihat Bagian 5.3 untuk detailnya - MPEG-4 (.mp4)
- Matroska (.mkv, hanya decode)
MPEG-2 Profil utama - Mpeg2-ts (.ts, tidak dicari)
- MPEG-4 (.mp4, decode saja)
- Matroska (.mkv, hanya decode)
MPEG-4SP - 3GPP (.3gp)
- MPEG-4 (.mp4)
- Matroska (.mkv, hanya decode)
Wakil Presiden8 Lihat Bagian 5.2 dan 5.3 untuk detailnya - WebM (.webm)
- Matroska (.mkv)
Wakil Presiden9 Lihat Bagian 5.3 untuk detailnya - WebM (.webm)
- Matroska (.mkv)
AV1 Lihat Bagian 5.2 dan Bagian 5.3 untuk detailnya - MPEG-4 (.mp4)
- Matroska (.mkv, hanya decode)
5.1.10. Karakterisasi codec media :
Lihat Revisi
Jika implementasi perangkat mendukung codec video:
- [C-2-1] Semua codec video harus mempublikasikan data frame rate yang dapat dicapai untuk ukuran berikut jika didukung oleh codec:
SD (kualitas rendah) SD (kualitas tinggi) HD 720p HD 1080p UHD Resolusi video - 176 x 144 px (H263, MPEG2, MPEG4)
- 352 x 288 px (MPEG4 Encoder, H263, MPEG2)
- 320 x 180 px (VP8, VP8)
- 320 x 240 px (Lainnya)
- 704 x 576 px (H263)
- 640 x 360 px (VP8, VP9)
- 640 x 480 px (encoder MPEG4)
- 720 x 480 px (Lainnya, AV1 )
- 1408 x 1152 px (H263)
- 1280 x 720 px (Lainnya, AV1 )
1920 x 1080 px (selain MPEG4, AV1 ) 3840 x 2160 px (HEVC, VP9, AV1 ) Lihat Revisi
Jika implementasi perangkat mendukung encoder video apa pun dan membuatnya tersedia untuk aplikasi pihak ketiga, mereka:- Seharusnya tidak, lebih dari dua jendela geser, lebih dari 15% di atas bitrate antara interval intraframe (I-frame).
- Seharusnya tidak lebih dari 100% di atas bitrate di atas jendela geser 1 detik.
Jika implementasi perangkat mendukung encoder video apa pun dan membuatnya tersedia untuk aplikasi pihak ketiga, dan mengatur
MediaFormat.KEY_BITRATE_MODE
keBITRATE_MODE_VBR
sehingga encoder beroperasi dalam mode bitrate variabel, kemudian, selama itu tidak mempengaruhi lantai kualitas minimum , bitrate yang dikodekan:-
[C-5-1] tidak boleh, lebih dari satu jendela geser, lebih dari 15% di atas bitrate antara interval intraframe (I-frame). -
[C-5-2] tidak bolehlebih dari 100% di atas bitrate di atas jendela geser 1 detik.
Jika implementasi perangkat mendukung encoder video apa pun dan membuatnya tersedia untuk aplikasi pihak ketiga dan mengatur
MediaFormat.KEY_BITRATE_MODE
keBITRATE_MODE_CBR
sehingga enkoder beroperasi dalam mode bitrate konstan, maka bitrate yang dikodekan:-
[C-6-1] Harus[C-SR-2] sangat disarankan untuk tidak lebih dari 15% di atas bitrate target di atas jendela geser 1 detik.
Lihat Revisi
Jika implementasi perangkat mendukung encoder H.263 dan membuatnya tersedia untuk aplikasi pihak ketiga, mereka:
- [C-1-1] Harus mendukung resolusi QCIF (176 x 144) menggunakan level profil dasar 45. Resolusi SQCIF adalah opsional.
-
Harus mendukung bitrat yang dapat dikonfigurasi secara dinamis untuk enkoder yang didukung.
Lihat Revisi
Jika implementasi perangkat mendukung H.265 codec, mereka:
- [C-1-1] harus mendukung level profil utama 3 hingga 512 x 512 resolusi .
-
Harus mendukung profil pengkodean HD seperti yang ditunjukkan pada tabel berikut. - [C-SR-1] sangat disarankan untuk mendukung profil 720 x 480 SD dan profil pengkodean HD seperti yang ditunjukkan pada tabel berikut jika ada encoder perangkat keras.
5.2.6. AV1 : Bagian Baru
Lihat Revisi
Jika implementasi perangkat mendukung codec AV1 maka, mereka:
- [C-1-1] harus mendukung profil utama termasuk konten 8-bit dan 10-bit.
[C-1-2] Harus mempublikasikan data kinerja IE melaporkan data kinerja melalui
getSupportedFrameRatesFor()
ataugetSupportedPerformancePoints()
API untuk resolusi yang didukung dalam tabel di bawah ini.[C-1-3] Harus menerima metadata HDR dan mengeluarkannya ke bitstream
Jika encoder AV1 dipercepat, maka itu:
- [C-2-1] Harus mendukung dan termasuk profil pengkodean HD1080P dari tabel di bawah ini:
SD HD 720p HD 1080p UHD Resolusi video 720 x 480 px 1280x720 piksel 1920x1080 piksel 3840x2160 piksel Kecepatan bingkai video 30fps 30fps 30fps 30fps Kecepatan bit video 5Mbps 8Mbps 16Mbps 50Mbps Lihat Revisi
Jika implementasi perangkat mendukung decoder H.263, mereka:
- [C-1-1] Harus mendukung level profil dasar 30 (resolusi CIF, QCIF dan SQCIF @ 30fps 384kbps) dan level 45 (resolusi QCIF dan SQCIF @ 30fps 128kbps) .
Lihat Revisi
Jika implementasi perangkat mendukung AV1 codec, mereka:- [C-1-1] Harus mendukung profil 0 termasuk konten 10-bit.
Jika implementasi perangkat mendukung AV1 codec dan membuatnya tersedia untuk aplikasi pihak ketiga, mereka:
- [C-1-1] harus mendukung profil utama termasuk konten 8-bit dan 10-bit.
Jika implementasi perangkat memberikan dukungan untuk AV1 codec dengan dekoder yang dipercepat perangkat keras maka mereka:
- [C-2-1] harus dapat memecahkan kode setidaknya profil decoding video HD 720p dari tabel di bawah ini ketika ketinggian yang dilaporkan oleh
Display.getSupportedModes()
metode sama atau lebih besar dari 720p. - [C-2-2] Harus dapat memecahkan kode setidaknya profil decoding video HD 1080p dari tabel di bawah ini ketika ketinggian yang dilaporkan oleh
Display.getSupportedModes()
metode sama atau lebih besar dari 1080p.
SD HD 720p HD 1080p UHD Resolusi video 720 x 480 px 1280x720 piksel 1920x1080 piksel 3840x2160 piksel Kecepatan bingkai video 30fps 30fps 30fps 30fps Kecepatan bit video 5Mbps 8Mbps 16Mbps 50Mbps Jika implementasi perangkat mendukung profil HDR melalui API media, maka mereka:
- [C-3-1] Harus mendukung pengekstrak dan mengeluarkan metadata HDR dari bitstream dan/atau wadah.
- [C-3-2] harus menampilkan konten HDR dengan benar pada layar perangkat atau pada port output video standar (misalnya, HDMI).
5.4.2. Tangkap untuk pengenalan suara :
Lihat Revisi
Jika implementasi perangkat mendeklarasikan
android.hardware.microphone
, mereka:- Harus mengatur sensitivitas input audio sedemikian rupa sehingga sumber nada sinusoidal 1000 Hz dimainkan pada tingkat tekanan suara 90 dB (SPL) (diukur
pada jarak 30 cm darisebelah mikrofon) menghasilkan respons ideal RMS 2500 dalam kisaran 1770 dan dan 3530 untuk 16 -bit -sampel (atau -22,35 dB ± skala penuh 3dB untuk sampel titik mengambang/presisi ganda) untuk setiap mikrofon yang digunakan untuk merekam sumber audio pengenalan suara.
- Harus mengatur sensitivitas input audio sedemikian rupa sehingga sumber nada sinusoidal 1000 Hz dimainkan pada tingkat tekanan suara 90 dB (SPL) (diukur
Lihat Revisi
Jika implementasi perangkat mendeklarasikan fitur
android.hardware.audio.output
, mereka:- [C-1-4] Harus mendukung efek audio dengan input dan output titik mengambang.
- [C-1-5] harus memastikan bahwa efek audio mendukung beberapa saluran hingga jumlah saluran mixer yang juga dikenal sebagai FCC_LIMIT.
Lihat Revisi
Jika implementasi perangkat mendeklarasikan
android.hardware.audio.output
mereka sangat disarankan untuk memenuhi atau melampaui persyaratan berikut:- [C-SR-4] Cap waktu output yang dikembalikan oleh Audiotrack.gettimestamp dan
AAudioStream_getTimestamp
akurat hingga +/- 1 ms.
- [C-SR-4] Latensi perjalanan bundar yang dihitung berdasarkan cap waktu input dan output yang dikembalikan oleh
AAudioStream_getTimestamp
sangat disarankan untuk berada dalam jarak 30 msec dari latensi perjalanan pulang pergi yang diukur untukAAUDIO_PERFORMANCE_MODE_NONE
danAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
untuk speaker for audio_performance_mode_none dan aaudio_performance_mode_lower for audio_performance_mode dan aaudio_performance_mode_low.
- [C-SR-4] Cap waktu output yang dikembalikan oleh Audiotrack.gettimestamp dan
7. Kompatibilitas perangkat keras
Lihat Revisi
Android mencakup fasilitas yang secara otomatis menyesuaikan aset aplikasi dan tata letak UI secara tepat untuk perangkat untuk memastikan bahwa aplikasi pihak ketiga berjalan dengan baik pada
berbagai konfigurasi perangkat keras .Berbagai tampilan dan konfigurasi perangkat keras. Tampilan yang kompatibel dengan Android adalah layar tampilan yang mengimplementasikan semua perilaku dan API yang dijelaskan dalam tinjauan kompatibilitas pengembang Android-layar , bagian ini (7.1) dan subbagiannya, serta perilaku spesifik tipe perangkat tambahan yang didokumentasikan dalam Bagian 2 dari CDD ini.Pada tampilan yang kompatibel dengan Android di mana semua aplikasi yang kompatibel dengan Android pihak ketiga dapat berjalan, implementasi perangkat harus mengimplementasikan API dan perilaku ini dengan benar, sebagaimana dirinci dalam bagian ini.Mulai persyaratan baru
Implementasi perangkat:
- [C-0-1] Harus, secara default, membuat aplikasi pihak ketiga hanya ke tampilan yang kompatibel dengan Android.
Unit yang dirujuk oleh persyaratan di bagian ini didefinisikan sebagai berikut:
- Ukuran diagonal fisik . Jarak dalam inci antara dua sudut yang berlawanan dari bagian layar yang diterangi.
-
Titik -titik per inci (DPI)kepadatan . Jumlah piksel yang dicakup oleh rentang horizontal atau vertikal linier 1 ” , dinyatakan sebagai piksel per inci (PPI atau DPI) . Di mana nilaiDPIPPI dan DPI terdaftar, baik DPI horizontal dan vertikal harus berada dalam kisaran yang terdaftar . - rasio aspek . Rasio piksel dari dimensi yang lebih panjang dengan dimensi layar yang lebih pendek. Misalnya, tampilan 480x854 piksel adalah 854/480 = 1.779, atau kira -kira “16: 9”.
- Pixel-independen-independen (DP) .
Unitpiksel virtual dinormalisasi ke kepadatan layarlayar 160 dpi160. Untuk beberapa kepadatan D, dan sejumlah piksel P, jumlah piksel piksel-independen, dihitung sebagai:piksel = DP * (kepadatan/160)dp = (160 / d) * p .
7.1.1.1. Ukuran dan bentuk layar :
Lihat Revisi
Jika implementasi perangkat mendukung layar yang mampu melakukan konfigurasi ukuran
UI_MODE_TYPE_NORMAL
danmenyertakan Android-Compatiblemenggunakan tampilan fisik dengan sudut bulat untuk membuat layar ini , mereka:- [C-1-1] harus memastikan bahwa setidaknya satu dari persyaratan berikut dipenuhi untuk setiap tampilan tersebut :
- Jari -jari sudut bundar kurang dari atau sama dengan 38 dp.
Ketika kotak 15 dp x 15 dp berlabuh di setiap sudut tampilan logis, setidaknya satu piksel dari setiap kotak terlihat di layar.
Harus mencakup keterjangkauan pengguna untuk beralih ke mode tampilan dengan sudut persegi panjang.
Mulai persyaratan baru
Jika implementasi perangkat hanya mampu melakukan konfigurasi keyboard
NO_KEYS
, dan bermaksud untuk melaporkan dukungan untuk konfigurasi mode UIUI_MODE_TYPE_NORMAL
, mereka:- [C-4-1] harus memiliki ukuran tata letak, tidak termasuk guntingan tampilan, setidaknya 596 dp x 384 dp atau lebih besar.
Jika implementasi perangkat mencakup tampilan Android-Compatible yang dapat dilipat, atau termasuk engsel lipat antara beberapa panel tampilan dan membuat tampilan tersebut tersedia untuk membuat aplikasi pihak ketiga, mereka:
- [C-2-1] harus mengimplementasikan versi stabil terbaru yang tersedia dari Extensions API atau versi stabil API Sidecar yang akan digunakan oleh Window Manager Jetpack Library.
Jika implementasi perangkat menyertakan tampilan yang kompatibel dengan Android yang dapat dilipat, atau termasuk engsel lipat antara beberapa panel tampilan dan jika engsel atau lipatan melintasi jendela aplikasi layar penuh, mereka:
- [C-3-1] harus melaporkan posisi, batas dan keadaan engsel atau lipat melalui ekstensi atau API sidecar ke aplikasi.
Jika implementasi perangkat mencakup satu atau lebih area tampilan yang kompatibel dengan Android yang dapat dilipat, atau termasuk engsel lipat antara beberapa area panel tampilan yang kompatibel Android dan membuat area tampilan seperti itu tersedia untuk aplikasi, mereka:
- [C-4-1] harus mengimplementasikan versi yang benar dari level API Extensions Window Manager seperti yang dijelaskan dalam dokumentasi yang akan datang.
7.1.1.2. Rasio Aspek Layar : Dihapus
Lihat Revisi
Implementasi Perangkat:
- [C-0-1]
Secara default, implementasi perangkatharus melaporkanhanyasatu dari kerangka kerangka Android yang terdaftar diDisplayMetrics
melalui APIDENSITY_DEVICE_STABLE
dan nilai ini harus menjadi nilai statis untuk setiap tampilan fisiktidak boleh berubah kapan saja; Namun,namun perangkat dapat melaporkanDisplayMetrics.density
yang berbeda dengankepadatan sewenang -wenang.Ketidaksebalan sesuai dengan perubahan konfigurasi tampilan yang dibuat oleh pengguna (misalnya, ukuran tampilan) yang ditetapkan setelah boot awal.
- Implementasi perangkat harus menentukan kerapatan kerangka Android standar yang secara numerik terdekat dengan kepadatan fisik layar, kecuali kepadatan logis itu mendorong ukuran layar yang dilaporkan di bawah minimum yang didukung. Jika kepadatan kerangka Android standar yang paling dekat dengan kepadatan fisik menghasilkan ukuran layar yang lebih kecil dari ukuran layar kompatibel yang kompatibel dengan terkecil (lebar 320 dp), implementasi perangkat harus melaporkan kepadatan kerangka Android standar terendah berikutnya.
Mulai persyaratan baru
- Harus menentukan kerapatan kerangka Android standar yang secara numerik terdekat dengan kepadatan fisik layar, atau nilai yang akan memetakan ke bidang sudut sudut setara yang sama pengukuran perangkat genggam.
Jika implementasi perangkat menyediakan
adaketerjangkauan untuk mengubah ukuran tampilan perangkat , mereka :- [C-1-1]
Ukuran tampilan tidak boleh ditingkatkantidak boleh skala tampilan lebih besar dari 1,5 kaliDENSITY_DEVICE_STABLE
kepadatan asliatau menghasilkan dimensi layar minimum yang efektif lebih kecil dari 320dp (setara dengan kualifikasi sumber daya SW320DP), mana yang lebih dulu. - [C-1-2]
Ukuran tampilan tidak boleh diskalakantidak boleh skala tampilan lebih kecil dari 0,85 kalikepadatan asliDENSITY_DEVICE_STABLE
.
- [C-0-1]
Lihat Revisi
Jika implementasi perangkat mencakup dukungan untuk Vulkan
1.0 atau lebih tinggi, mereka:[C-1-3] harus sepenuhnya mengimplementasikan API
Vulkan 1.0Vulkan 1.1 untuk setiapVkPhysicalDevice
yang disebutkan.[C-1-5] Tidak boleh menyebutkan lapisan yang disediakan oleh perpustakaan di luar paket aplikasi, atau memberikan cara lain untuk menelusuri atau mencegat API Vulkan, kecuali aplikasi memiliki
android:debuggable
ditetapkan sebagaitrue
atau Metadatacom.android.graphics.injectLayers.enable
Set ketrue
.
- Harus mendukung
VkPhysicalDeviceProtectedMemoryFeatures
danVK_EXT_global_priority
.
- [C-1-13] harus memenuhi persyaratan yang ditentukan oleh profil Android Baseline 2021 .
[C-SR-5] sangat disarankan untuk mendukung
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory
danVK_EXT_global_priority
.[C-SR-6] sangat disarankan untuk menggunakan
SkiaVk
dengan hwui.
Jika implementasi perangkat mencakup dukungan untuk Vulkan 1.1 dan mendeklarasikan salah satu bendera fitur Vulkan yang dijelaskan di sini , mereka:
- [C-SR-7] sangat disarankan untuk membuat ekstensi
VK_KHR_external_fence_fd
tersedia untuk aplikasi pihak ketiga dan mengaktifkan aplikasi untuk mengekspor payload pagar ke dan impor payload pagar dari deskriptor file POSIX seperti yang dijelaskan di sini .
Lihat Revisi
Jika implementasi perangkat memiliki beberapa sensor biometrik, mereka:
[C-7-1] Harus, ketika biometrik berada di lockout (yaitu biometrik dinonaktifkan sampai pengguna membuka dengan otentikasi primer) atau penguncian terikat waktu (yaitu biometrik dinonaktifkan sementara sampai pengguna menunggu interval waktu) Karena terlalu banyak upaya yang gagal, juga mengunci semua biometrik lain dari kelas biometrik yang lebih rendah. Dalam hal penguncian terikat waktu, waktu backoff untuk verifikasi biometrik harus menjadi waktu backoff maksimum semua biometrik dalam penguncian terikat waktu.
[C-SR-12] sangat disarankan, ketika biometrik sedang terkunci (yaitu biometrik dinonaktifkan sampai pengguna membuka kunci dengan otentikasi primer) atau penguncian waktu yang terikat (yaitu biometrik untuk sementara dinonaktifkan sampai pengguna menunggu waktu (yaitu biometrik untuk sementara waktu menunggu pengguna Interval) Karena terlalu banyak upaya yang gagal, untuk juga mengunci semua biometrik lain dari kelas biometrik yang sama. Dalam hal penguncian yang terikat waktu, waktu backoff untuk verifikasi biometrik sangat disarankan untuk menjadi waktu backoff maksimum semua biometrik dalam penguncian terikat waktu.
[C-7-2] harus menantang pengguna untuk otentikasi primer yang disarankan (misalnya: pin, pola, kata sandi) untuk mengatur ulang penghitung penguncian untuk biometrik yang dikunci. Biometrik kelas 3 dapat diizinkan untuk mengatur ulang penghitung penguncian untuk biometrik terkunci dari kelas yang sama atau lebih rendah. Biometrik kelas 2 atau kelas 1 tidak boleh diizinkan untuk menyelesaikan operasi penguncian reset untuk biometrik apa pun.
Jika implementasi perangkat ingin memperlakukan sensor biometrik sebagai kelas 1 (sebelumnya kenyamanan ), mereka:
[C-1-12] harus memiliki laju penerimaan spoof dan penipu yang tidak lebih tinggi dari 40% per presentasi instrumen serangan (PAI) spesies , yang diukur dengan protokol uji biometrik Android .
[C-SR-13] sangat disarankan untuk memiliki laju penerimaan spoof dan penipu yang tidak lebih tinggi dari 30% per spesies instrumen serangan presentasi (PAI) , yang diukur dengan protokol uji biometrik Android .
[C-SR-14] sangat disarankan untuk mengungkapkan kelas biometrik dari sensor biometrik dan risiko yang sesuai untuk memungkinkannya.
[C-SR-17] sangat disarankan untuk mengimplementasikan antarmuka AIDL baru (seperti,
IFace.aidl
danIFingerprint.aidl
).
Jika implementasi perangkat ingin memperlakukan sensor biometrik sebagai kelas 2 (sebelumnya lemah ), mereka:
- [C-SR-15] sangat disarankan untuk memiliki laju penerimaan spoof dan penipu yang tidak lebih tinggi dari 20% per spesies instrumen serangan presentasi (PAI) , yang diukur dengan protokol uji biometrik Android .
- [C-2-3] harus melakukan pencocokan biometrik dalam lingkungan eksekusi yang terisolasi di luar pengguna Android atau ruang kernel, seperti lingkungan eksekusi tepercaya (TEE),
ataupada chip dengan saluran yang aman ke lingkungan eksekusi yang terisolasi atau yang dilindungi Mesin virtual yang memenuhi persyaratan di Bagian 9.17 . - [C-2-4] harus memiliki semua data yang dapat diidentifikasi dienkripsi dan secara kriptografis diautentikasi sehingga mereka tidak dapat diperoleh, dibaca atau diubah di luar lingkungan eksekusi yang terisolasi atau chip dengan saluran yang aman ke lingkungan eksekusi yang terisolasi sebagaimana didokumentasikan dalam pedoman implementasi tersebut Di situs proyek Open Source Android atau mesin virtual yang dilindungi yang dikendalikan oleh hypervisor yang memenuhi persyaratan di Bagian 9.17 .
- [C-2-5] Untuk biometrik berbasis kamera, sedangkan otentikasi atau pendaftaran berbasis biometrik sedang terjadi:
- Harus mengoperasikan kamera dalam mode yang mencegah bingkai kamera dibaca atau diubah di luar lingkungan eksekusi yang terisolasi atau chip dengan saluran yang aman ke lingkungan eksekusi yang terisolasi atau mesin virtual yang dilindungi yang dikendalikan oleh hypervisor yang memenuhi persyaratan di bagian 9.17 .
- Untuk solusi kamera tunggal RGB, bingkai kamera dapat dibaca di luar lingkungan eksekusi yang terisolasi untuk mendukung operasi seperti pratinjau untuk pendaftaran, tetapi masih belum dapat diubah.
- [C-2-7] Tidak boleh mengizinkan akses yang tidak terenkripsi ke data biometrik yang dapat diidentifikasi atau data apa pun yang berasal dari TI (seperti embeddings) ke prosesor aplikasi di luar konteks TEE atau mesin virtual yang dilindungi yang dikendalikan oleh hypervisor yang memenuhi persyaratan di bagian bagian 9.17 . Perangkat peningkatan yang diluncurkan pada Android versi 9 atau sebelumnya tidak dibebaskan dari C-2-7.
Jika implementasi perangkat ingin memperlakukan sensor biometrik sebagai kelas 3 (sebelumnya kuat ), mereka:
- [C-SR-16] sangat disarankan untuk memiliki laju penerimaan spoof dan penipu yang tidak lebih tinggi dari 7% per spesies instrumen serangan presentasi (PAI) , yang diukur dengan protokol uji biometrik android .
7.3.13. IEEE 802.1.15.4 (UWB) :
Lihat Revisi
Jika implementasi perangkat mencakup dukungan untuk 802.1.15.4 dan mengekspos fungsionalitas ke aplikasi pihak ketiga, mereka:
- [C-1-2] Harus melaporkan fitur perangkat keras bendera
android.hardware.uwb
. - [C-1-3] Harus mendukung semua set konfigurasi berikut (kombinasi parameter FIRA UCI yang telah ditentukan sebelumnya) yang didefinisikan dalam implementasi AOSP.
-
CONFIG_ID_1
: FIRA-Defined UnicastSTATIC STS DS-TWR
Ranging, Mode Ditangguhkan, Ranging Interval 240 ms. -
CONFIG_ID_2
:STATIC STS DS-TWR
satu-ke-banyak yang ditentukan FIRA, mode ditangguhkan, interval jarak 200 ms. Kasus Penggunaan Khas: Ponsel pintar berinteraksi dengan banyak perangkat pintar. -
CONFIG_ID_3
: Sama sepertiCONFIG_ID_1
, kecuali data Angle-of-Arrival (AOA) tidak dilaporkan. -
CONFIG_ID_4
: Sama sepertiCONFIG_ID_1
, kecuali mode keamanan p-sts diaktifkan. -
CONFIG_ID_5
: Sama sepertiCONFIG_ID_2
, kecuali mode keamanan p-sts diaktifkan. -
CONFIG_ID_6
: Sama sepertiCONFIG_ID_3
, kecuali mode keamanan p-sts diaktifkan. -
CONFIG_ID_7
: Sama sepertiCONFIG_ID_2
, kecuali mode kunci pengontrol individu p-sts diaktifkan.
-
- [C-1-4] harus memberikan keterjangkauan pengguna untuk memungkinkan pengguna untuk mengubah status ON/OFF radio UWB.
- [C-1-5] harus menegakkan bahwa aplikasi menggunakan radio UWB memegang izin
UWB_RANGING
(di bawah grup izinNEARBY_DEVICES
).
Melewati tes kesesuaian dan sertifikasi yang relevan yang ditentukan oleh organisasi standar, termasuk FIRA , CCC dan CSA membantu memastikan fungsi 802.1.15.4 dengan benar.
- [C-1-2] Harus melaporkan fitur perangkat keras bendera
Lihat Revisi
"Telepon" seperti yang digunakan oleh API Android dan dokumen ini mengacu secara khusus pada perangkat keras yang terkait dengan menempatkan panggilan suara dan mengirim pesan SMS , atau membuat data seluler melalui jaringan seluler (misalnya GSM, CDMA, LTE, NR) GSM atau CDMA. Perangkat yang mendukung "telepon" dapat memilih untuk menawarkan beberapa atau semua layanan panggilan, pesan, dan data yang sesuai dengan produk.
melalui jaringan GSM atau CDMA. Meskipun panggilan suara ini mungkin atau mungkin tidak di masukan, mereka untuk keperluan Android yang dianggap independen dari konektivitas data apa pun yang dapat diimplementasikan menggunakan jaringan yang sama. Dengan kata lain, fungsionalitas "telepon" android dan API merujuk secara khusus untuk panggilan suara dan SMS. Misalnya, implementasi perangkat yang tidak dapat melakukan panggilan atau mengirim/menerima pesan SMS tidak dianggap sebagai perangkat telepon, terlepas dari apakah mereka menggunakan jaringan seluler untuk konektivitas data.Lihat Revisi
Jika implementasi perangkat mencakup dukungan untuk 802.11 dan mengekspos fungsionalitas ke aplikasi pihak ketiga, mereka:
- [C-1-4] Harus mendukung multicast DNS (MDNS) dan tidak boleh menyaring paket MDNS (224.0.0.251 atau FF02 :: FB ) setiap saat operasi, termasuk ketika layar tidak dalam keadaan aktif, kecuali menjatuhkan atau menjatuhkan atau menjatuhkan Menyaring paket -paket ini diperlukan untuk tetap berada dalam rentang konsumsi daya yang diperlukan oleh persyaratan peraturan yang berlaku untuk target pasar.
Untuk implementasi perangkat televisi Android, bahkan ketika di negara -negara kekuatan siaga.
- [C-1-4] Harus mendukung multicast DNS (MDNS) dan tidak boleh menyaring paket MDNS (224.0.0.251 atau FF02 :: FB ) setiap saat operasi, termasuk ketika layar tidak dalam keadaan aktif, kecuali menjatuhkan atau menjatuhkan atau menjatuhkan Menyaring paket -paket ini diperlukan untuk tetap berada dalam rentang konsumsi daya yang diperlukan oleh persyaratan peraturan yang berlaku untuk target pasar.
Lihat Revisi
Jika implementasi perangkat mendeklarasikan fitur_bluetooth_le, mereka:
- [C-SR-2] sangat disarankan untuk mengukur dan mengkompensasi offset RX untuk memastikan median BLE RSSI adalah -60dbm +/- 10 dB pada jarak 1m dari perangkat referensi yang mentransmisikan di
ADVERTISE_TX_POWER_HIGH
, di mana perangkat diorientasikan sedemikian rupa sehingga ada Pada 'Parallel Planes' dengan layar menghadap ke arah yang sama. - [C-SR-3] sangat disarankan untuk mengukur dan mengkompensasi offset TX untuk memastikan median BLE RSSI adalah -60dbm +/- 10 dB saat memindai dari perangkat referensi yang diposisikan pada jarak 1m dan mentransmisikan di
ADVERTISE_TX_POWER_HIGH
, di mana perangkat berorientasi berorientasi pada perangkat berorientasi pada perangkat berorientasi pada advertise_tx_power_high, di mana perangkat berorientasi berorientasi pada perangkat berorientasi berorientasi pada advertise_tx_power_high, di mana perangkat berorientasi pada perangkat berorientasi pada perangkat berorientasi pada advertise_tx_power_high. sedemikian rupa sehingga mereka berada di 'pesawat paralel' dengan layar yang menghadap ke arah yang sama.
- [C-10-3] Harus mengukur dan mengkompensasi offset RX untuk memastikan median BLE RSSI adalah -55dBm +/- 10 dB pada jarak 1m dari perangkat referensi yang mentransmisikan di
ADVERTISE_TX_POWER_HIGH
. - [C-10-4] Harus mengukur dan mengkompensasi offset TX untuk memastikan median BLE RSSI adalah -55dBm +/- 10 dB saat memindai dari perangkat referensi yang diposisikan pada jarak 1m dan mentransmisikan di
ADVERTISE_TX_POWER_HIGH
.
Jika implementasi perangkat mendukung Bluetooth Versi 5.0, maka mereka:
- [C-SR-4] sangat disarankan untuk memberikan dukungan untuk:
- LE 2M PHY
- Le codec phy
- Ekstensi Periklanan LE
- Iklan berkala
- Setidaknya 10 set iklan
- Setidaknya 8 koneksi bersamaan. Setiap koneksi dapat berada dalam peran topologi koneksi.
- Privasi Lapisan Tautan LE
- Ukuran "daftar penyelesaian" setidaknya 8 entri
- [C-SR-2] sangat disarankan untuk mengukur dan mengkompensasi offset RX untuk memastikan median BLE RSSI adalah -60dbm +/- 10 dB pada jarak 1m dari perangkat referensi yang mentransmisikan di
Lihat Revisi
- [C-1-7] harus memastikan bahwa median pengukuran jarak pada 1m dari perangkat referensi berada di dalam [0,75m, 1,25m], di mana jarak kebenaran tanah diukur dari tepi atas DUT.
dipegang menghadap ke atas dan miring 45 derajat.
- [C-1-7] harus memastikan bahwa median pengukuran jarak pada 1m dari perangkat referensi berada di dalam [0,75m, 1,25m], di mana jarak kebenaran tanah diukur dari tepi atas DUT.
7.5.1. Kamera yang menghadap ke belakang :
Lihat Revisi
Kamera yang menghadap ke belakang adalah kamera yang terletak di sisi perangkat di seberang layar; Artinya, itu gambar adegan di sisi jauh perangkat, seperti kamera tradisional.
Kamera yang menghadap ke belakang adalah kamera yang menghadap ke dunia yang gambar adegan di sisi jauh perangkat, seperti kamera tradisional; Pada perangkat genggam, itu adalah kamera yang terletak di sisi perangkat di seberang layar.
7.5.2. Kamera yang menghadap ke depan :
Lihat Revisi
Kamera yang menghadap ke depan adalah kamera yang terletak di sisi perangkat yang sama dengan tampilan; Artinya, kamera yang biasanya digunakan untuk membayangkan pengguna, seperti untuk konferensi video dan aplikasi serupa.
Kamera yang menghadap ke depan adalah kamera yang menghadap pengguna yang biasanya digunakan untuk membayangkan pengguna, seperti untuk konferensi video dan aplikasi serupa; Pada perangkat genggam, itu adalah kamera yang terletak di sisi perangkat yang sama dengan tampilan.
Lihat Revisi
Kamera eksternal adalah kamera yang dapat dipasang secara fisik atau terlepas dari implementasi perangkat kapan saja dan dapat menghadapi arah apa pun; seperti kamera USB.
Lihat Revisi
Implementasi perangkat harus mengimplementasikan perilaku berikut untuk API terkait kamera, untuk semua kamera yang tersedia. Implementasi perangkat:
- [C-SR-1] Untuk perangkat dengan beberapa kamera RGB dalam jarak dekat dan menghadap ke arah yang sama, sangat disarankan untuk mendukung perangkat kamera logis yang mencantumkan kemampuan
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
, yang terdiri dari semua RGB Cameras facinger_multi_camera, yang terdiri dari semua RGB Cameras FACINAS_MULTION, yang terdiri dari semua RGB Cameras FACINAS THAGULTI_CAMERA, yang terdiri dari RGB Cameras RGB sebagai sub-perangkat fisik.
- [C-SR-1] Untuk perangkat dengan beberapa kamera RGB dalam jarak dekat dan menghadap ke arah yang sama, sangat disarankan untuk mendukung perangkat kamera logis yang mencantumkan kemampuan
Lihat Revisi
Perangkat yang memenuhi semua kriteria berikut dikecualikan dari persyaratan di atas:
- Implementasi perangkat yang tidak mampu diputar oleh pengguna seperti perangkat otomotif.
Lihat Revisi
Perangkat yang dimaksudkan untuk dipelihara dengan tangan atau dikenakan dapat mencakup aktuator haptic tujuan umum, tersedia untuk aplikasi untuk tujuan termasuk mendapatkan perhatian melalui nada dering, alarm, pemberitahuan, serta umpan balik sentuhan umum.
Jika implementasi perangkat tidak termasuk aktuator haptic tujuan umum seperti itu, mereka:
- [7.10/c] Harus mengembalikan false untuk
Vibrator.hasVibrator()
.
Jika implementasi perangkat mencakup setidaknya satu aktuator haptic tujuan umum tersebut, mereka:
- [C-1-1] harus kembali benar untuk
Vibrator.hasVibrator()
. - Tidak boleh menggunakan aktuator haptic massa rotating eksentrik (ERM) (vibrator).
- SHOULD implement all public constants for clear haptics in
android.view.HapticFeedbackConstants
namely (CLOCK_TICK
,CONTEXT_CLICK
,KEYBOARD_PRESS
,KEYBOARD_RELEASE
,KEYBOARD_TAP
,LONG_PRESS
,TEXT_HANDLE_MOVE
,VIRTUAL_KEY
,VIRTUAL_KEY_RELEASE
,CONFIRM
,REJECT
,GESTURE_START
andGESTURE_END
). - Harus mengimplementasikan semua konstanta publik untuk haptics yang jelas di
android.os.VibrationEffect
yaitu (EFFECT_TICK
,EFFECT_CLICK
,EFFECT_HEAVY_CLICK
danEFFECT_DOUBLE_CLICK
) dan semua konstanta publik yangPRIMITIVE_*
untuk haptics yang kaya diandroid.os.VibrationEffect.Composition
Posisi namely (CLICK
, kutu,TICK
, kutu, kutu,LOW_TICK
.QUICK_FALL
,QUICK_RISE
,SLOW_RISE
,SPIN
,THUD
). Beberapa primitif ini, sepertiLOW_TICK
danSPIN
mungkin hanya layak jika vibrator dapat mendukung frekuensi yang relatif rendah. - Harus mengikuti panduan untuk memetakan konstanta publik di
android.view.HapticFeedbackConstants
ke konstantaandroid.os.VibrationEffect
yang disarankan, dengan hubungan amplitudo yang sesuai. - Harus menggunakan pemetaan konstanta haptic yang terhubung ini.
- Harus mengikuti penilaian kualitas untuk API
createOneShot()
dancreateWaveform()
. - Harus memverifikasi bahwa hasil dari
android.os.Vibrator.hasAmplitudeControl()
API dengan benar mencerminkan kemampuan vibrator mereka. - Harus memverifikasi kemampuan skalabilitas amplitudo dengan menjalankan
android.os.Vibrator.hasAmplitudeControl()
.
Jika implementasi perangkat mengikuti pemetaan konstanta haptic, mereka:
- Harus memverifikasi status implementasi dengan menjalankan
android.os.Vibrator.areAllEffectsSupported()
danandroid.os.Vibrator.arePrimitivesSupported()
API. - Harus melakukan penilaian kualitas untuk konstanta haptic.
- Harus memverifikasi dan memperbarui jika diperlukan konfigurasi fallback untuk primitif yang tidak didukung seperti yang dijelaskan dalam panduan implementasi untuk konstanta.
- Harus memberikan dukungan mundur untuk mengurangi risiko kegagalan seperti yang dijelaskan di sini .
Lihat Bagian 2.2.1 untuk persyaratan khusus perangkat.
- [7.10/c] Harus mengembalikan false untuk
9. Kompatibilitas Model Keamanan
Lihat Revisi
Implementasi perangkat:
- [C-0-4] harus memiliki satu dan hanya satu implementasi dari kedua antarmuka pengguna.
Jika implementasi perangkat sebelum menginstal setiap paket yang menampung semua intelijen sistem UI , intelijen audio ambient sistem , intelijen audio sistem , intelijen pemberitahuan sistem , kecerdasan teks sistem , atau peran intelijen visual sistem , paket tersebut:
- [C-4-1] harus memenuhi semua persyaratan yang diuraikan untuk implementasi perangkat di bagian
"9.8.6 Capture Capture""9.8.6 Data Level dan Ambient OS dan 9.8.15 Implementasi API Sandboxed".
- [C-4-2] tidak boleh memiliki android.permission.internet izin. Ini lebih ketat dari yang sangat direkomendasikan tercantum di Bagian 9.8.6.
- [C-4-3] Tidak boleh mengikat aplikasi lain, kecuali untuk aplikasi sistem berikut: Bluetooth, kontak, media, telepon, Systemui, dan komponen yang menyediakan API Internet. Ini lebih ketat dari yang sangat direkomendasikan tercantum di Bagian 9.8.6.
Jika implementasi perangkat menyertakan aplikasi default untuk mendukung
VoiceInteractionService
mereka:- [C-5-1] Tidak boleh memberikan
ACCESS_FINE_LOCATION
sebagai default untuk aplikasi itu.
9.5. Dukungan multi-pengguna :
Lihat Revisi
Jika implementasi perangkat membuat profil pengguna tambahan yang dibahas di atas, maka mereka:
- [C-4-5] harus secara visual membedakan ikon aplikasi instance ganda ketika ikon disajikan kepada pengguna.
- [C-4-6] MUST provide a user-affordance to delete entire clone profile data.
- [C-4-7] MUST uninstall all Clone apps, delete the private app data directories and their content, and delete Clone profile data, when the user chooses to delete entire Clone profile data.
- SHOULD prompt the user to delete entire Clone Profile data when the last clone app is deleted.
- [C-4-8] MUST inform the user that app data will be deleted when the clone application is uninstalled, or provide an option to users to keep app data when the application is uninstalled from the device.
- [C-4-9] MUST delete the private app data directories and their content, when the user chooses to delete the data during uninstall.
[C-4-1] MUST allow the below intents originating from the additional profile to be handled by applications of the primary user on the device:
-
Intent.ACTION_VIEW
-
Intent.ACTION_SENDTO
-
Intent.ACTION_SEND
-
Intent.ACTION_EDIT
-
Intent.ACTION_INSERT
-
Intent.ACTION_INSERT_OR_EDIT
-
Intent.ACTION_SEND_MULTIPLE
-
Intent.ACTION_PICK
-
Intent.ACTION_GET_CONTENT
-
MediaStore.ACTION_IMAGE_CAPTURE
-
MediaStore.ACTION_VIDEO_CAPTURE
-
[C-4-2] MUST inherit all device policy user restrictions and selected non-user restrictions(list below) applied on the primary user of the device to this additional user profile.
[C-4-3] MUST only allow writing contacts from this additional profile via the following intents:
[C-4-4] MUST NOT have contact syncs running for applications running in this additional user profile.
- [C-4-14] MUST have separate permission and storage management for the applications running in this additional profile
- [C-4-5] MUST only allow applications in the additional profile that have a launcher activity to access contacts that are already accessible to the parent user profile.
See revision
A Memory Safety technology is a technology that mitigates at least the following classes of bugs with a high (> 90%) probability in applications that use the
android:memtagMode
manifest option:- heap buffer overflow
- use after free
- double free
- wild free (free of a non-malloc pointer)
Implementasi perangkat:
- [C-SR-15] Are STRONGLY RECOMMENDED to set
ro.arm64.memtag.bootctl_supported
.
If device implementations set the system property
ro.arm64.memtag.bootctl_supported
to true, they:[C-3-1] MUST allow the system property
arm64.memtag.bootctl
to accept a comma-separated list of the following values, with the desired effect applied on the next subsequent reboot:-
memtag
: a Memory Safety technology as defined above is enabled -
memtag-once
: a Memory Safety technology as defined above is transiently enabled, and is automatically disabled upon, next reboot -
memtag-off
: a Memory Safety technology as defined above is disabled
-
[C-3-2] MUST allow the shell user to set
arm64.memtag.bootctl
.[C-3-3] MUST allow any process to read
arm64.memtag.bootctl
.[C-3-4] MUST set
arm64.memtag.bootctl
to the currently requested state upon boot, it MUST also update the property, if the device implementation allows to modify the state without changing the system property.[C-SR-16] Are STRONGLY RECOMMENDED to show a Developer Setting that sets memtag-once and reboots the device. With a compatible bootloader, the Android Open Source Project meets the above requirements through the MTE bootloader protocol .
- [C-SR-17] Are STRONGLY RECOMMENDED to show a Setting in the Security Settings menu that allows the user to enable
memtag
.
See revision
Implementasi perangkat:
- [C-0-2] MUST display a user warning and obtain explicit user consent allowing any sensitive information that is displayed on the user's screen to be captured
enabled that includes exactly the same message as AOSPwhenevereach and every time a session to capture the screencasting or screen recordingisenabledstarted via theMediaProjection.createVirtualDisplay()
,VirtualDeviceManager.createVirtualDisplay()
, or proprietary APIs.MUST NOT provide users an affordance to disable future display of the user consent.
[C-SR-1] Are STRONGLY RECOMMENDED to display a user warning which is exactly the same message as implemented in AOSP but CAN be altered as long as the message clearly warns the user that any sensitive information on the user's screen is captured.
[C-0-4] MUST NOT provide users an affordance to disable future prompts of the user consent to capture the screen, unless the session is started by a system app that the user has allowed to
associate()
with theandroid.app.role.COMPANION_DEVICE_APP_STREAMING
or theandroid.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING
device profile.
- [C-0-2] MUST display a user warning and obtain explicit user consent allowing any sensitive information that is displayed on the user's screen to be captured
9.8.6. OS-level and ambient data : This section was renamed from Content Capture and App Search to OS-level and ambient data .
See revision
Android, through the System APIs
, supports a mechanism for device implementations to capture the followingContentCaptureService
,AugmentedAutofillService
,AppSearchGlobalManager.query
, or by other proprietary meansapplication data interactions between the applications and the usersensitive data :- Any screen or other data sent via the
AugmentedAutofillService
to the system. - Any screen or other data accessible via
Content Capture
API. - Any screen or other data accessible via
FieldClassificationService
API - Any application data passed to the system via the
AppSearchManager
API and accessible viaAppSearchGlobalManager.query
.
- Any other events that an application provides to the system via the
Content Capture
API or orAppSearchManager
API a similarly capable Android and proprietary API.
- Audio data obtained as a result of using
SpeechRecognizer#onDeviceSpeechRecognizer()
by the Speech Recognizer Implementation. - Audio data obtained in background (continuously) through
AudioRecord
,SoundTrigger
or other Audio APIs, and not resulting in a user-visible indicator - Camera data obtained in background (continuously) through CameraManager or other Camera APIs, and not resulting in a user-visible indicator
If device implementations capture any of the data above, they:
[C-1-3] MUST only send all such data
and the logoff the device using a privacy-preserving mechanism , except with explicit user consent every time the data is shared . The privacy-preserving mechanism is defined as “those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users”, to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such asRAPPOR
).[C-1-5] MUST NOT share such data with other OS components that don't follow requirements outlined in the current section (9.8.6
Content CaptureOS-level and ambient data ), except with explicit user consent every time it is bersama. Unless such functionality is built as an Android SDK API (AmbientContext
,HotwordDetectionService
).[C-1-6] MUST provide user affordance to erase such data that the
implementation or the proprietary means collectsContentCaptureService
ifwhen the data is stored in any form on the device. If the user chooses to erase the data, MUST remove all collected historical data.
- [C-SR-3] Are STRONGLY RECOMMENDED to be implemented with Android SDK API or a similar OEM-owned open-source repository; and / or be performed in a Sandboxed implementation (see 9.8.15 Sandboxed API implementations).
Android, through
SpeechRecognizer#onDeviceSpeechRecognizer()
provides ability to perform speech recognition on the device, without involving the network. Any implementation of on-device SpeechRecognizer MUST follow the policies outlined in this section.- Any screen or other data sent via the
9.8.10. Connectivity Bug Report :
See revision
If device implementations declare the
android.hardware.telephony
feature flag, they:- [C-1-4] Reports generated using
BUGREPORT_MODE_TELEPHONY
MUST contain at least the following information:-
SubscriptionManagerService
dump
-
- [C-1-4] Reports generated using
9.8.14. Credential Manager : Removed
9.8.15. Sandboxed API Implementations : New section
See revision
Android, through a set of delegate APIs provides a mechanism to process secure OS-level and ambient data. Such processing can be delegated to a preinstalled apk with privileged access and reduced communication capabilities, known as a Sandboxed API Implementation.
Any Sandboxed API implementation:
- [C-0-1] MUST NOT request the INTERNET permission.
- [C-0-2] MUST only access the internet through structured APIs backed by publicly available open-source implementations using privacy-preserving mechanisms, or indirectly via Android SDK APIs. The privacy-preserving mechanism is defined as "those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users", to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such as RAPPOR ).
- [C-0-3] MUST keep the services separate from other system components (eg not binding the service or sharing process IDs) except for the following:
- Telephony, Contacts, System UI, and Media
- [C-0-4] MUST NOT allow users to replace the services with a user-installable application or service
- [C-0-5] MUST only allow the preinstalled services to capture such data. Unless the replacement capability is built into AOSP (eg for Digital Assistant Apps).
- [C-0-6] MUST NOT allow any apps other than the preinstalled services mechanism to be able to capture such data. Unless such capture capability is implemented with an Android SDK API.
- [C-0-7] MUST provide user affordance to disable the services.
- [C-0-8] MUST NOT omit user affordance to manage Android permissions that are held by the services and follow the Android permissions model as described in Section 9.1. Izin .
9.8.16. Continuous Audio and Camera data : New section
See revision
In addition to requirements outlined in 9.8.2 Recording, 9.8.6 OS-level and ambient data, and 9.8.15 Sandboxed API implementations, implementations that make use of Audio data obtained in background (continuously) through AudioRecord, SoundTrigger or other Audio APIs OR Camera data obtained in background (continuously) through CameraManager or other Camera APIs:
- [C-0-1] MUST enforce a corresponding indicator (camera and/or microphone as per section 9.8.2 Recording), unless:
- This access is performed in a Sandboxed implementation (see 9.8.15 Sandboxed API implementation), through a package holding one or more of the following roles: System UI Intelligence , System Ambient Audio Intelligence , System Audio Intelligence , System Notification Intelligence , System Text Intelligence , or System Visual Intelligence .
- The access is performed through a sandbox, implemented and enforced via mechanisms in AOSP (
HotwordDetectionService
,WearableSensingService
,VisualQueryDetector
). - Audio access is performed for assistive purposes by the Digital Assistant application, supplying
SOURCE_HOTWORD
as an audio source. - The access is performed by the system and implemented with open-source code.
- [C-SR-1] Is STRONGLY RECOMMENDED to require user consent for every functionality utilizing such data, and be disabled by default.
- [C-SR-2] STRONGLY RECOMMENDED to apply the same treatment (ie follow the restrictions outlined in 9.8.2 Recording, 9.8.6 OS-level and ambient data, 9.8.15 Sandboxed API implementations, and 9.8.16 Continuous Audio and Camera data) to Camera data coming from a remote wearable device.
If the Camera data is supplied from a remote wearable device and accessed in an unencrypted form outside Android OS, sandboxed implementation or a sandboxed functionality built by
WearableSensingManager
, then they:- [C-1-1] MUST indicate to the remote wearable device to display an additional indicator there.
If devices provide capability to engage with a Digital Assistant Application without the assigned keyword (either handling generic user queries, or analyzing user presence through camera):
- [C-2-1] MUST ensure such implementation is provided by a package holding the
android.app.role.ASSISTANT
role. - [C-2-2] MUST ensure such implementation utilizes
HotwordDetectionService
and/orVisualQueryDetectionService
Android APIs.
- [C-0-1] MUST enforce a corresponding indicator (camera and/or microphone as per section 9.8.2 Recording), unless:
9.8.17. Telemetry : New section
See revision
Android stores system and app logs using StatsLog APIs. These logs are managed via StatsManager APIs which can be used by privileged system applications.
StatsManager also provides a way to collect data categorized as privacy sensitive from devices with a privacy preserving mechanism. In particular,
StatsManager::query
API provides the ability to query restricted metric categories defined in StatsLog .Any implementation querying and collecting restricted metrics from StatsManager:
- [C-0-1] MUST be the sole application/implementation on the device and hold the
READ_RESTRICTED_STATS
permission. - [C-0-2] MUST only send telemetry data and the log of the device using a privacy-preserving mechanism. The privacy-preserving mechanism is defined as "those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users", to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such as RAPPOR ).
- [C-0-3] MUST NOT associate such data with any user identity (such as Account ) on the device.
- [C-0-4] MUST NOT share such data with other OS components that don't follow requirements outlined in the current section (9.8.17 Privacy-preserving Telemetry).
- [C-0-5] MUST provide a user affordance to enable/disable privacy-preserving telemetry collection, use, and sharing.
- [C-0-6] MUST provide user affordance to erase such data that the implementation collects if the data is stored in any form on the device. If the user chose to erase the data, MUST remove all data currently stored on the device.
- [C-0-7] MUST disclose underlying privacy-preserving protocol implementation in an open source repository.
- [C-0-8 ]MUST enforce data egress policies in this section to gate collection of data in restricted metric categories defined in StatsLog .
- [C-0-1] MUST be the sole application/implementation on the device and hold the
See revision
Device implementationsIf device implementations have the ability to verify file content on the per-page basis, then they :
[
C-0-3C-2-1 ] support cryptographically verifying file contentagainst a trusted keywithout reading the whole file.[
C-0-4C-2-2 ] MUST NOT allow the read requests on a protected file to succeed when the read contentdo not verify against a trusted keyis not verified per [C-2-1] above .
- [C-2-4] MUST return file checksum in O(1) for enabled files.
See revision
The Android Keystore System allows app developers to store cryptographic keys in a container and use them in cryptographic operations through the KeyChain API or the Keystore API . Implementasi perangkat:
- [C-0-3] MUST limit the number of failed primary authentication attempts.
- [C-SR-2] Are STRONGLY RECOMMENDED to implement an upper bound of 20 failed primary authentication attempts and if users consent and opt-in the feature, perform a "Factory Data Reset" after exceeding the limit of failed primary authentication attempts.
If device implementations add or modify the authentication methods to unlock the lock screen if based on a known secret and use a new authentication method to be treated as a secure way to lock the screen, then:
- [C-SR-3] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
- [C-2-1] A PIN of a length less than 6 digits MUST NOT allow automatic entry without user interaction to avoid revealing the PIN length.
9.11.1. Secure Lock Screen, Authentication and Virtual Devices :
See revision
Implementasi perangkat:
- [C-0-1] MUST limit the number of failed primary authentication attempts.
- [C-SR-5] Are STRONGLY RECOMMENDED to implement an upper bound of 20 failed primary authentication attempts and if users consent and opt-in the feature, perform a "Factory Data Reset" after exceeding the limit of failed primary authentication attempts.
If device implementations set a numerical PIN as the recommended primary authentication method, then:
- [C-SR-6] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
- [C-SR-7] A PIN of a length less than 6 digits is STRONGLY RECOMMENDED NOT to allow automatic entry without user interaction to avoid revealing the PIN length.
Jika implementasi perangkat memiliki layar kunci yang aman dan menyertakan satu atau lebih agen kepercayaan, yang mengimplementasikan API sistem
TrustAgentService
, mereka:[C-7-8] The user MUST be challenged for one of the recommended primary authentication (eg: PIN, pattern, password) methods at least once every 72 hours or less unless the safety of the user (eg driver distraction) is of kekhawatiran.If device implementations allow applications to create secondary virtual displays and support associated input events such as via VirtualDeviceManager and the displays are not marked with VIRTUAL_DISPLAY_FLAG_SECURE, they:
[C-13-10] MUST disable installation of apps initiated from virtual devices.9.17. Android Virtualization Framework :
See revision
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 (pVM) .
- [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 only allow platform signed code & privileged apps
MUST NOT allow untrusted code (eg 3p apps)to create and run aProtected Virtual MachinepVM . Note: This might change in future Android releases.
- [C-1-5] MUST NOT allow a
Protected Virtual MachinepVM 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.
- [C-1-5] MUST only allow a non-debuggable pVM to execute code from the factory image or their platform updates which also includes any updates to privileged apps.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), then anyProtected Virtual MachinepVM instance:- [C-2-1] MUST be able to run all operating systems available in the virtualization APEX in a
Protected Virtual MachinepVM . - [C-2-2] MUST NOT allow a
Protected Virtual MachinepVM 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 MachinepVM 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 MachinepVM defense-in-depth mechanisms (eg SELinux for pVMs) even for non-Microdroid operating systems. - [C-2-6] MUST ensure that the pVM fails
firmware refusesto boot ifit cannot verify the initialimages that the VM will run cannot be verified. Verifikasi HARUS dilakukan di dalam VM. - [C-2-7] MUST ensure that the pVM fails
firmware refusesto 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 ensure that memory pages exclusively owned by a VM (either pVM or host VM) are accessible only to the virtual machine itself or the hypervisor, not by other virtual machines - either protected or non-protected.
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 pVM and before it is returned to the host (eg the pVM is destroyed).
- [C-
3-3SR-1 ] Is STRONGLY RECOMMENDED to ensureMUST ensurethat that the pVM firmware is loaded and executed prior to any code in a pVM. - [C-3-4] MUST ensure that each VM derives a per-VM secret which
{Boot Certificate Chain (BCC) and Compound Device Identifier (CDIs) provided to a pVM instancecan only be derived by that particular VM instance and changes upon factory reset and OTA.
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 be capable to support Isolated Compilation but may disable Isolated Compilation feature on the device shipment
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- SR-2
6-2] Is STRONGLY RECOMMENDED to use DICE as the per-VM secret derivation mechanism.MUST do DICE properly ie provide the correct values.
- [C-1-1] MUST support all the APIs defined by the