1. Pengantar
Dokumen ini mencantumkan persyaratan yang harus dipenuhi agar perangkat kompatibel dengan Android 14.
Penggunaan "HARUS", "TIDAK BOLEH", "WAJIB", "HARUS", "TIDAK BOLEH", "HARUS", "TIDAK BOLEH", "DISARANKAN", "MUNGKIN", dan "OPSIONAL" sesuai dengan standar IETF yang ditentukan dalam RFC2119.
Seperti yang digunakan dalam dokumen ini, "penerapkan perangkat" atau "penerapkan" adalah orang atau organisasi yang mengembangkan solusi hardware/software yang menjalankan Android 14. "Penerapan perangkat" atau "penerapan" adalah solusi hardware/software yang dikembangkan.
Agar dianggap kompatibel dengan Android 14, implementasi perangkat HARUS memenuhi persyaratan yang disajikan dalam Definisi Kompatibilitas ini, termasuk dokumen apa pun yang disertakan melalui referensi.
Jika definisi ini atau pengujian software yang dijelaskan dalam bagian 10 tidak jelas, ambigu, atau tidak lengkap, pelaksana perangkat bertanggung jawab untuk memastikan kompatibilitas dengan implementasi yang ada.
Karena alasan ini, Project Open Source Android adalah referensi dan implementasi Android yang lebih disukai. Implementator perangkat SANGAT DISARANKAN untuk mendasarkan implementasi mereka semaksimal mungkin pada kode sumber "upstream" yang tersedia dari Project Open Source Android. Meskipun secara hipotetis beberapa komponen dapat diganti dengan implementasi alternatif, SANGAT DISARANKAN untuk tidak mengikuti praktik ini, karena lulus pengujian software akan menjadi jauh lebih sulit. Implementer bertanggung jawab untuk memastikan kompatibilitas perilaku penuh dengan implementasi Android standar, termasuk dan di luar Compatibility Test Suite. Terakhir, perhatikan bahwa penggantian dan modikasi komponen tertentu secara eksplisit dilarang oleh dokumen ini.
Banyak referensi yang ditautkan dalam dokumen ini berasal secara langsung atau tidak langsung dari Android SDK dan akan identik secara fungsional dengan informasi dalam dokumentasi SDK tersebut. Jika Definisi Kompatibilitas ini atau Compatibility Test Suite tidak sesuai dengan dokumentasi SDK, dokumentasi SDK dianggap kredibel. Semua detail teknis yang diberikan dalam referensi tertaut di seluruh dokumen ini dianggap sebagai bagian dari Definisi Kompatibilitas ini.
1.1 Struktur Dokumen
1.1.1. Persyaratan menurut Jenis Perangkat
Bagian 2 berisi semua persyaratan yang berlaku untuk jenis perangkat tertentu. Setiap subbagian Bagian 2 didedikasikan untuk jenis perangkat tertentu.
Semua persyaratan lainnya, yang secara universal berlaku untuk implementasi perangkat Android apa pun, tercantum di bagian setelah Bagian 2. Persyaratan ini dirujuk sebagai "Persyaratan Inti" dalam dokumen ini.
1.1.2. ID Persyaratan
ID persyaratan ditetapkan untuk persyaratan MUST.
- ID hanya ditetapkan untuk persyaratan WAJIB.
- Persyaratan yang SANGAT DIUJAMI di tandai sebagai [SR], tetapi ID tidak ditetapkan.
- ID terdiri dari : ID Jenis Perangkat - ID Kondisi - ID Persyaratan (misalnya, C-0-1).
Setiap ID ditentukan sebagai berikut:
- ID Jenis Perangkat (lihat selengkapnya di 2. Jenis Perangkat)
- C: Core (Persyaratan yang diterapkan ke semua implementasi perangkat Android)
- H: Perangkat Genggam Android
- T: Perangkat Android TV
- A: Implementasi Android Automotive
- W: Implementasi Android Watch
- Tab: Implementasi Tablet Android
- ID Kondisi
- Jika persyaratannya tidak bersyarat, ID ini ditetapkan sebagai 0.
- Jika persyaratan bersifat kondisional, 1 ditetapkan untuk kondisi ke-1 dan jumlahnya bertambah 1 dalam bagian yang sama dan jenis perangkat yang sama.
- ID Persyaratan
- ID ini dimulai dari 1 dan bertambah 1 dalam bagian yang sama dan kondisi yang sama.
1.1.3. ID Persyaratan di Bagian 2
ID Persyaratan di Bagian 2 memiliki dua bagian. Yang pertama sesuai dengan ID bagian seperti yang dijelaskan di atas. Bagian kedua mengidentifikasi faktor bentuk dan persyaratan khusus faktor bentuk.
yang diikuti dengan ID Persyaratan yang dijelaskan di atas.
- ID di Bagian 2 terdiri dari: ID Bagian / ID Jenis Perangkat - ID Kondisi - ID Persyaratan (misalnya, 7.4.3/A-0-1).
2. Jenis Perangkat
Proyek Open Source Android menyediakan stack software yang dapat digunakan untuk berbagai jenis perangkat dan faktor bentuk. Untuk mendukung keamanan di perangkat, stack software, termasuk OS pengganti atau implementasi kernel alternatif, diharapkan dijalankan di lingkungan yang aman seperti yang dijelaskan di bagian 9 dan di tempat lain dalam CDD ini. Ada beberapa jenis perangkat yang memiliki ekosistem distribusi aplikasi yang relatif lebih baik.
Bagian ini menjelaskan jenis perangkat tersebut, serta persyaratan dan rekomendasi tambahan yang berlaku untuk setiap jenis perangkat.
Semua implementasi perangkat Android yang tidak sesuai dengan jenis perangkat yang dijelaskan HARUS tetap memenuhi semua persyaratan di bagian lain Definisi Kompatibilitas ini.
2.1 Konfigurasi Perangkat
Untuk mengetahui perbedaan utama dalam konfigurasi hardware menurut jenis perangkat, lihat persyaratan khusus perangkat yang mengikuti di bagian ini.
2.2. Persyaratan Perangkat Genggam
Perangkat Genggam Android mengacu pada implementasi perangkat Android yang biasanya digunakan dengan memegangnya di tangan, seperti pemutar mp3, ponsel, atau tablet.
Implementasi perangkat Android diklasifikasikan sebagai Perangkat Genggam jika memenuhi semua kriteria berikut:
- Memiliki sumber daya yang memberikan mobilitas, seperti baterai.
- Memiliki ukuran layar diagonal fisik dalam rentang
4 inci
3,3 inci (atau 2,5 inci untuk implementasi perangkat yang dikirimkan pada API level 29 atau sebelumnya)hingga 8 inci. - Memiliki antarmuka input layar sentuh.
Persyaratan tambahan di bagian lain ini khusus untuk implementasi perangkat Ponsel Android.
2.2.1. Hardware
Implementasi perangkat genggam:
- [7.1.1.1/H-0-1] HARUS memiliki setidaknya satu
layar yang kompatibel dengan Android dan memenuhi semua persyaratan yang dijelaskan dalam dokumen ini.layar yang berukuran minimal 2,2 inci di tepi pendek dan 3,4 inci di tepi panjang. [7.1.1.3/H-SR-1] SANGAT DISARANKAN untuk memberikan kemampuan kepada pengguna untuk mengubah ukuran tampilan (kepadatan layar).
[7.1.1.1/H-0-2] HARUS mendukung komposisi GPU buffer grafis setidaknya sebesar resolusi tertinggi layar bawaan.
Memulai 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 yang tidak terhalang yang berukuran minimal 2,2 inci di tepi pendek dan 3,4 inci inci di tepi panjang.[7.1.1.3/H-0-1]* HARUS menetapkan nilai
DENSITY_DEVICE_STABLE
menjadi 92% atau lebih besar dari kepadatan fisik yang sebenarnya dari layar yang sesuai.
Akhiri persyaratan baru
Jika implementasi Perangkat genggam mendukung rotasi layar software, perangkat tersebut:
- [7.1.1.1/H-1-1]* HARUS membuat layar logis yang tersedia untuk aplikasi pihak ketiga berukuran minimal 2 inci di sisi pendek dan 2,7 inci di sisi panjang. Perangkat yang dikirimkan dengan Android API level 29 atau yang lebih lama DAPAT dikecualikan dari persyaratan ini.
Jika implementasi perangkat Genggam tidak mendukung rotasi layar software, perangkat tersebut:
- [7.1.1.1/H-2-1]* HARUS membuat layar logis yang tersedia untuk aplikasi pihak ketiga berukuran minimal 2,7 inci di sisi pendek. Perangkat yang dikirimkan dengan Android API level 29 atau yang lebih lama DAPAT dikecualikan dari persyaratan ini.
Memulai persyaratan baru
Jika implementasi perangkat genggam menyertakan dukungan untuk Vulkan, perangkat tersebut:
- [7.1.4.2/H-1-1] HARUS memenuhi persyaratan yang ditentukan oleh profil Dasar Pengukuran Android 2021.
Akhiri persyaratan baru
Jika implementasi perangkat Genggam mengklaim dukungan untuk layar rentang dinamis
tinggi melalui Configuration.isScreenHdr()
, perangkat tersebut:
- [7.1.4.5/H-1-1] HARUS mengiklankan dukungan untuk ekstensi
EGL_EXT_gl_colorspace_bt2020_pq
,EGL_EXT_surface_SMPTE2086_metadata
,EGL_EXT_surface_CTA861_3_metadata
,VK_EXT_swapchain_colorspace
, danVK_EXT_hdr_metadata
.
Implementasi perangkat genggam:
- [7.1.4.6/H-0-1] HARUS melaporkan apakah perangkat
mendukung kemampuan pembuatan profil GPU melalui properti sistem
graphics.gpu.profiler.support
.
Jika implementasi perangkat Genggam mendeklarasikan dukungan melalui properti sistem
graphics.gpu.profiler.support
, implementasi tersebut:
- [7.1.4.6/H-1-1] HARUS melaporkan sebagai output trace protobuf yang mematuhi skema untuk penghitung GPU dan renderstage GPU yang ditentukan dalam dokumentasi Perfetto.
- [7.1.4.6/H-1-2] HARUS melaporkan nilai yang sesuai untuk penghitung GPU perangkat dengan mengikuti proto paket rekaman aktivitas penghitung GPU.
- [7.1.4.6/H-1-3] HARUS melaporkan nilai yang sesuai untuk RenderStages GPU perangkat dengan mengikuti proto paket rekaman aktivitas tahap render.
- [7.1.4.6/H-1-4] HARUS melaporkan tracepoint Frekuensi GPU seperti yang ditentukan oleh format: power/gpu_frequency.
Implementasi perangkat genggam:
- [7.1.5/H-0-1] HARUS menyertakan dukungan untuk mode kompatibilitas aplikasi lama seperti yang diterapkan oleh kode open source Android upstream. Artinya, implementasi perangkat TIDAK BOLEH mengubah pemicu atau nilai minimum saat mode kompatibilitas diaktifkan, dan TIDAK BOLEH mengubah perilaku mode kompatibilitas itu sendiri.
- [7.2.1/H-0-1] HARUS menyertakan dukungan untuk aplikasi Editor Metode Input (IME) pihak ketiga.
- [7.2.3/H-0-2] HARUS mengirim peristiwa tekan lama dan normal
dari fungsi Kembali (
KEYCODE_BACK
) ke aplikasi latar depan. Peristiwa ini TIDAK BOLEH digunakan oleh sistem dan DAPAT dipicu oleh perangkat di luar Android (misalnya, keyboard hardware eksternal yang terhubung ke perangkat Android). - [7.2.3/H-0-3] HARUS menyediakan fungsi Home di semua layar yang kompatibel dengan Android yang menyediakan layar utama.
- [7.2.3/H-0-4] HARUS menyediakan fungsi Kembali di semua layar yang kompatibel dengan Android dan fungsi Terbaru di setidaknya salah satu layar yang kompatibel dengan Android.
- [7.2.4/H-0-1] HARUS mendukung input layar sentuh.
- [7.2.4/H-SR-1] SANGAT DISARANKAN untuk meluncurkan
aplikasi bantuan yang dipilih pengguna, dengan kata lain aplikasi yang mengimplementasikan
VoiceInteractionService, atau aktivitas yang menangani
ACTION_ASSIST
saat menekan lamaKEYCODE_MEDIA_PLAY_PAUSE
atauKEYCODE_HEADSETHOOK
jika aktivitas latar depan tidak menangani peristiwa tekan lama tersebut. - [7.3.1/H-SR-1] SANGAT DIUJAMI untuk menyertakan akselerometer 3 sumbu.
Jika implementasi Perangkat genggam menyertakan akselerometer 3 sumbu, implementasi tersebut:
- [7.3.1/H-1-1] HARUS dapat melaporkan peristiwa hingga frekuensi setidaknya 100 Hz.
Jika implementasi perangkat Genggam menyertakan penerima GPS/GNSS dan melaporkan
kemampuan ke aplikasi melalui tanda
fitur android.hardware.location.gps
, implementasi tersebut:
- [7.3.3/H-2-1] HARUS melaporkan pengukuran GNSS, segera setelah ditemukan, meskipun lokasi yang dihitung dari GPS/GNSS belum dilaporkan.
- [7.3.3/H-2-2] HARUS melaporkan pseudorange dan rasio pseudorange GNSS, yang, dalam kondisi langit terbuka setelah menentukan lokasi, saat diam atau bergerak dengan percepatan kurang dari 0,2 meter per detik kuadrat, cukup untuk menghitung posisi dalam 20 meter, dan kecepatan dalam 0,2 meter per detik, setidaknya 95% dari waktu.
Jika implementasi Perangkat genggam menyertakan giroskop 3 sumbu, perangkat tersebut:
- [7.3.4/H-3-1] HARUS dapat melaporkan peristiwa hingga frekuensi setidaknya 100 Hz.
- [7.3.4/H-3-2] HARUS dapat mengukur perubahan orientasi hingga 1.000 derajat per detik.
Implementasi perangkat genggam yang dapat melakukan panggilan suara dan menunjukkan
nilai apa pun selain PHONE_TYPE_NONE
di getPhoneType
:
- [7.3.8/H] HARUS menyertakan sensor kedekatan.
Implementasi perangkat genggam:
- [7.3.11/H-SR-1] SANGAT DISARANKAN untuk mendukung sensor pose dengan 6 derajat kebebasan.
- [7.4.3/H] HARUS menyertakan dukungan untuk Bluetooth dan Bluetooth LE.
Jika perangkat mendukung protokol WiFi Neighbor Awareness Networking (NAN) dengan
mendeklarasikan PackageManager.FEATURE_WIFI_AWARE
dan Lokasi Wi-Fi (Wi-Fi Round
Trip Time — RTT) dengan mendeklarasikan PackageManager.FEATURE_WIFI_RTT
, perangkat tersebut:
[7.4.2.5/H-1-1] HARUS melaporkan rentang secara akurat hingga +/-1 meter pada bandwidth 160 MHz pada persentil ke-68 (seperti yang dihitung dengan Fungsi Distribusi Kumulatif), +/-2 meter pada bandwidth 80 MHz pada persentil ke-68, +/-4 meter pada bandwidth 40 MHz pada persentil ke-68, dan +/-8 meter pada bandwidth 20 MHz pada persentil ke-68 pada jarak 10 cm, 1 m, 3 m, dan 5 m, seperti yang diamati melalui WifiRttManager#startRanging Android API.
[7.4.2.5/H-SR-1] SANGAT DISARANKAN untuk melaporkan rentang secara akurat dalam +/-1 meter pada bandwidth 160 MHz pada persentil ke-90 (seperti yang dihitung dengan Fungsi Distribusi Kumulatif), +/-2 meter pada bandwidth 80 MHz pada persentil ke-90, +/-4 meter pada bandwidth 40 MHz pada persentil ke-90, dan +/-8 meter pada bandwidth 20 MHz pada persentil ke-90 pada jarak 10 cm, seperti yang diamati melalui WifiRttManager#startRanging Android API.
SANGAT DIUJAMI untuk mengikuti langkah-langkah penyiapan pengukuran yang ditentukan dalam artikel Kalibrasi Kehadiran.
Memulai persyaratan baru
Jika implementasi perangkat Genggam mendeklarasikan FEATURE_BLUETOOTH_LE
, implementasi tersebut:
- [7.4.3/H-1-3] HARUS mengukur dan mengompensasi offset
Rx untuk memastikan median RSSI BLE adalah -50 dBm +/-15 dB pada jarak 1 m dari
perangkat referensi yang mengirimkan pada
ADVERTISE_TX_POWER_HIGH
. - [7.4.3/H-1-4] HARUS mengukur dan mengompensasi offset
Tx untuk memastikan RSSI BLE median adalah -50 dBm +/-15 dB saat memindai dari
perangkat referensi yang diposisikan pada jarak 1 m dan mengirimkan pada
ADVERTISE_TX_POWER_HIGH
.
Akhiri persyaratan baru
Jika implementasi Perangkat genggam menyertakan perangkat kamera logis yang mencantumkan
kemampuan menggunakan
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
,
perangkat tersebut:
- [7.5.4/H-1-1] HARUS memiliki bidang pandang (FOV) normal secara default dan HARUS antara 50 dan derajat.
Implementasi perangkat genggam:
- [7.6.1/H-0-1] HARUS memiliki penyimpanan non-volatil minimal 4 GB yang tersedia untuk data pribadi aplikasi (alias partisi "/data").
- [7.6.1/H-0-2] HARUS menampilkan “true” untuk
ActivityManager.isLowRamDevice()
jika ada memori kurang dari 1 GB yang tersedia untuk kernel dan ruang pengguna.
Jika implementasi perangkat Genggam mendeklarasikan dukungan hanya untuk ABI 32-bit:
[7.6.1/H-1-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 416 MB jika layar default menggunakan resolusi framebuffer hingga qHD (misalnya, FWVGA).
[7.6.1/H-2-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 592 MB jika layar default menggunakan resolusi framebuffer hingga HD+ (misalnya, HD, WSVGA).
[7.6.1/H-3-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 896 MB jika layar default menggunakan resolusi framebuffer hingga FHD (misalnya, WSXGA+).
[7.6.1/H-4-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 1344 MB jika layar default menggunakan resolusi framebuffer hingga QHD (misalnya, QWXGA).
Jika implementasi perangkat Genggam mendeklarasikan dukungan ABI 64-bit (dengan atau tanpa ABI 32-bit):
[7.6.1/H-5-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS setidaknya 816 MB jika layar default menggunakan resolusi framebuffer hingga qHD (misalnya, FWVGA).
[7.6.1/H-6-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 944 MB jika layar default menggunakan resolusi framebuffer hingga HD+ (misalnya, HD, WSVGA).
[7.6.1/H-7-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 1280 MB jika layar default menggunakan resolusi framebuffer hingga FHD (misalnya, WSXGA+).
[7.6.1/H-8-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 1.824 MB jika layar default menggunakan resolusi framebuffer hingga QHD (misalnya, QWXGA).
Perhatikan bahwa "memori yang tersedia untuk kernel dan ruang pengguna" di atas mengacu pada ruang memori yang disediakan selain memori yang sudah dikhususkan untuk komponen hardware seperti radio, video, dan sebagainya yang tidak berada di bawah kontrol kernel pada implementasi perangkat.
Jika implementasi perangkat Genggam menyertakan memori kurang dari atau sama dengan 1 GB yang tersedia untuk kernel dan ruang pengguna, memori tersebut:
- [7.6.1/H-9-1] HARUS mendeklarasikan tombol fitur
android.hardware.ram.low
. - [7.6.1/H-9-2] HARUS memiliki penyimpanan non-volatil minimal 1,1 GB untuk data pribadi aplikasi (alias partisi "/data").
Jika implementasi perangkat Genggam menyertakan lebih dari 1 GB memori yang tersedia untuk kernel dan ruang pengguna, perangkat tersebut:
- [7.6.1/H-10-1] HARUS memiliki setidaknya 4 GB penyimpanan non-volatil yang tersedia untuk data pribadi aplikasi (alias partisi "/data").
- HARUS mendeklarasikan flag fitur
android.hardware.ram.normal
.
Jika implementasi perangkat Genggam menyertakan memori lebih dari atau sama dengan 2 GB dan kurang dari 4 GB yang tersedia untuk kernel dan ruang pengguna, memori tersebut:
- [7.6.1/H-SR-1] SANGAT DISARANKAN untuk hanya mendukung ruang pengguna 32-bit (baik aplikasi maupun kode sistem)
Jika implementasi perangkat Genggam menyertakan memori kurang dari 2 GB yang tersedia untuk kernel dan ruang pengguna, memori tersebut:
- [7.6.1/H-1-1] HARUS hanya mendukung satu ABI (khusus 64-bit atau khusus 32-bit).
Implementasi perangkat genggam:
- [7.6.2/H-0-1] TIDAK BOLEH menyediakan penyimpanan bersama aplikasi yang lebih kecil dari 1 GiB.
- [7.7.1/H] HARUS menyertakan port USB yang mendukung mode periferal.
Jika implementasi perangkat genggam menyertakan port USB yang mendukung mode periferal, port tersebut:
- [7.7.1/H-1-1] HARUS mengimplementasikan API Android Open Accessory (AOA).
Jika implementasi perangkat Genggam menyertakan port USB yang mendukung mode host, perangkat tersebut:
- [7.7.2/H-1-1] HARUS mengimplementasikan class audio USB seperti yang didokumentasikan dalam dokumentasi Android SDK.
Implementasi perangkat genggam:
- [7.8.1/H-0-1] HARUS menyertakan mikrofon.
- [7.8.2/H-0-1] HARUS memiliki output audio dan mendeklarasikan
android.hardware.audio.output
.
Jika implementasi perangkat Genggam mampu memenuhi semua persyaratan performa untuk mendukung mode VR dan menyertakan dukungan untuknya, implementasi tersebut:
- [7.9.1/H-1-1] HARUS mendeklarasikan
tombol fitur
android.hardware.vr.high_performance
. - [7.9.1/H-1-2] HARUS menyertakan aplikasi
yang menerapkan
android.service.vr.VrListenerService
yang dapat diaktifkan oleh aplikasi VR melaluiandroid.app.Activity#setVrModeEnabled
.
Jika implementasi perangkat Genggam menyertakan satu atau beberapa port USB-C dalam mode host dan menerapkan (class audio USB), selain persyaratan dalam bagian 7.7.2, implementasi tersebut:
- [7.8.2.2/H-1-1] HARUS menyediakan pemetaan software kode HID berikut:
Fungsi | Pemetaan | Konteks | Perilaku |
---|---|---|---|
A | Halaman penggunaan HID: 0x0C Penggunaan HID: 0x0CD Kunci kernel: KEY_PLAYPAUSE Kunci Android: KEYCODE_MEDIA_PLAY_PAUSE |
Pemutaran media | Input: Tekan sebentar Output: Putar atau jeda |
Input: Tekan lama Output: Meluncurkan perintah suara Mengirim: android.speech.action.VOICE_SEARCH_HANDS_FREE jika perangkat
terkunci atau layarnya nonaktif. Mengirim
android.speech.RecognizerIntent.ACTION_WEB_SEARCH jika tidak |
|||
Panggilan masuk | Input: Tekan sebentar Output: Menerima panggilan |
||
Input: Tekan lama Output: Menolak panggilan |
|||
Panggilan sedang berlangsung | Input: Tekan sebentar Output: Mengakhiri panggilan |
||
Input: Tekan lama Output: Bisukan atau bunyikan mikrofon |
|||
B | Halaman penggunaan HID: 0x0C Penggunaan HID: 0x0E9 Kunci kernel: KEY_VOLUMEUP Kunci Android: VOLUME_UP |
Pemutaran media, Panggilan sedang berlangsung | Input: Tekan sebentar atau lama Output: Meningkatkan volume sistem atau headset |
C | Halaman penggunaan HID: 0x0C Penggunaan HID: 0x0EA Kunci kernel: KEY_VOLUMEDOWN Kunci Android: VOLUME_DOWN |
Pemutaran media, Panggilan sedang berlangsung | Input: Tekan sebentar atau lama Output: Menurunkan volume sistem atau headset |
D | Halaman penggunaan HID: 0x0C Penggunaan HID: 0x0CF Kunci kernel: KEY_VOICECOMMAND Kunci Android: KEYCODE_VOICE_ASSIST |
Semua. Dapat dipicu di instance mana pun. | Input: Tekan sebentar atau lama Output: Meluncurkan perintah suara |
- [7.8.2.2/H-1-2] HARUS memicu ACTION_HEADSET_PLUG saat steker dimasukkan, tetapi hanya setelah antarmuka dan endpoint audio USB dienumerasi dengan benar untuk mengidentifikasi jenis terminal yang terhubung.
Saat jenis terminal audio USB 0x0302 terdeteksi, terminal tersebut:
- [7.8.2.2/H-2-1] HARUS menyiarkan Intent ACTION_HEADSET_PLUG dengan tambahan "microphone" ditetapkan ke 0.
Saat jenis terminal audio USB 0x0402 terdeteksi, terminal tersebut:
- [7.8.2.2/H-3-1] HARUS menyiarkan Intent ACTION_HEADSET_PLUG dengan "microphone" tambahan ditetapkan ke 1.
Saat API AudioManager.getDevices() dipanggil saat periferal USB terhubung, API tersebut:
[7.8.2.2/H-4-1] HARUS mencantumkan perangkat dengan jenis AudioDeviceInfo.TYPE_USB_HEADSET dan peran isSink() jika kolom jenis terminal audio USB adalah 0x0302.
[7.8.2.2/H-4-2] HARUS mencantumkan perangkat berjenis AudioDeviceInfo.TYPE_USB_HEADSET dan peran isSink() jika kolom jenis terminal audio USB adalah 0x0402.
[7.8.2.2/H-4-3] HARUS mencantumkan perangkat berjenis AudioDeviceInfo.TYPE_USB_HEADSET dan peran isSource() jika kolom jenis terminal audio USB adalah 0x0402.
[7.8.2.2/H-4-4] HARUS mencantumkan perangkat berjenis AudioDeviceInfo.TYPE_USB_DEVICE dan peran isSink() jika kolom jenis terminal audio USB adalah 0x603.
[7.8.2.2/H-4-5] HARUS mencantumkan perangkat berjenis AudioDeviceInfo.TYPE_USB_DEVICE dan peran isSource() jika kolom jenis terminal audio USB adalah 0x604.
[7.8.2.2/H-4-6] HARUS mencantumkan perangkat berjenis AudioDeviceInfo.TYPE_USB_DEVICE dan peran isSink() jika kolom jenis terminal audio USB adalah 0x400.
[7.8.2.2/H-4-7] HARUS mencantumkan perangkat berjenis AudioDeviceInfo.TYPE_USB_DEVICE dan peran isSource() jika kolom jenis terminal audio USB adalah 0x400.
[7.8.2.2/H-SR-1] SANGAT DIUJAMI setelah koneksi periferal audio USB-C, untuk melakukan enumerasi deskripsi USB, mengidentifikasi jenis terminal, dan menyiarkan Intent ACTION_HEADSET_PLUG dalam waktu kurang dari 1.000 milidetik.
Jika implementasi perangkat Genggam mendeklarasikan android.hardware.audio.output
dan
android.hardware.microphone
, implementasi tersebut:
[5.6/H-1-1] HARUS memiliki Latensi Bolak-Balik Kontinu Rata-Rata sebesar 300 milidetik atau kurang selama 5 pengukuran, dengan Deviasi Absolut Rata-Rata kurang dari 30 md, melalui jalur data berikut: "speaker ke mikrofon", adaptor loopback 3,5 mm (jika didukung), loopback USB (jika didukung).
[5.6/H-1-2] HARUS memiliki latensi Ketuk-untuk-nada rata-rata 300 milidetik atau kurang selama minimal 5 pengukuran melalui jalur data speaker ke mikrofon.
Jika implementasi perangkat Genggam menyertakan minimal satu aktuator haptic, perangkat tersebut:
- [7.10/H]* TIDAK BOLEH menggunakan aktuator haptik (vibrator) massa berputar eksentrik (ERM).
- [7.10/H]* HARUS mengimplementasikan semua konstanta publik untuk haptik yang jelas di android.view.HapticFeedbackConstants yaitu (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START, dan GESTURE_END).
- [7.10/H]* HARUS mengimplementasikan semua konstanta publik untuk
haptik yang jelas
di android.os.VibrationEffect
yaitu (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK, dan
EFFECT_DOUBLE_CLICK) serta semua konstanta
PRIMITIVE_*
publik yang memungkinkan untuk haptik yang kaya di android.os.VibrationEffect.Composition yaitu (CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). Beberapa primitif ini, seperti LOW_TICK dan SPIN 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 vibrator dengan benar.
- [7.10/H]* HARUS memosisikan penempatan aktuator di dekat lokasi tempat perangkat biasanya dipegang atau disentuh oleh tangan.
Actuator resonansi linear (LRA) adalah sistem pegas massa tunggal yang memiliki frekuensi resonansi dominan dengan massa yang diterjemahkan ke arah gerakan yang diinginkan.
Jika implementasi Perangkat genggam menyertakan setidaknya satu aktuator resonansi linear 7.10 umum, perangkat tersebut:
Memulai persyaratan baru
- [7.10/H] HARUS memosisikan penempatan aktuator di dekat lokasi tempat perangkat biasanya dipegang atau disentuh dengan tangan.
Akhiri persyaratan baru
- [7.10/H]
HARUS menggerakkan aktuator haptic di sumbu X
(kiri-kanan) dari orientasi alami
potretperangkat.
Jika implementasi perangkat Genggam memiliki aktuator haptik tujuan umum yang merupakan aktuator resonansi linear sumbu X (LRA), perangkat tersebut:
- [7.10/H] HARUS memiliki frekuensi resonansi LRA sumbu X di bawah 200 Hz.
Jika implementasi perangkat genggam mengikuti pemetaan konstanta haptic, implementasi tersebut:
- [7.10/H]* HARUS memverifikasi status implementasi dengan menjalankan android.os.Vibrator.areAllEffectsSupported() dan android.os.Vibrator.arePrimitivesSupported() API.
[7.10/H]* HARUS melakukan penilaian kualitas untuk konstanta haptic.
[7.10/H]* HARUS memverifikasi dan memperbarui jika diperlukan konfigurasi penggantian untuk primitif yang tidak didukung seperti yang dijelaskan dalam panduan implementasi untuk konstanta.
2.2.2. Multimedia
Implementasi perangkat genggam HARUS mendukung format encoding dan decoding audio berikut serta menyediakannya untuk aplikasi pihak ketiga:
- [5.1/H-0-1] AMR-NB
- [5.1/H-0-2] AMR-WB
- [5.1/H-0-3] Profil AAC MPEG-4 (AAC LC)
- [5.1/H-0-4] Profil MPEG-4 HE AAC (AAC+)
- [5.1/H-0-5] AAC ELD (AAC yang ditingkatkan dengan delay rendah)
Implementasi perangkat genggam HARUS mendukung format encoding video berikut dan menyediakannya untuk aplikasi pihak ketiga:
Implementasi perangkat genggam HARUS mendukung format decoding video berikut dan menyediakannya untuk aplikasi pihak ketiga:
2.2.3. Software
Implementasi perangkat genggam:
- [3.2.3.1/H-0-1] HARUS memiliki
aplikasi yang menangani intent
ACTION_GET_CONTENT
,ACTION_OPEN_DOCUMENT
,ACTION_OPEN_DOCUMENT_TREE
, danACTION_CREATE_DOCUMENT
seperti yang dijelaskan dalam dokumen SDK, dan memberikan kemampuan pengguna untuk mengakses data penyedia dokumen menggunakanDocumentsProvider
API. - [3.2.3.1/H-0-2]* HARUS memuat ulang satu atau beberapa aplikasi atau komponen layanan dengan pengendali intent, untuk semua pola filter intent publik yang ditentukan oleh intent aplikasi berikut yang tercantum di sini.
- [3.2.3.1/H-SR-1] SANGAT DIANJURKAN untuk memuat aplikasi email secara otomatis yang dapat menangani intent ACTION_SENDTO atau ACTION_SEND atau ACTION_SEND_MULTIPLE untuk mengirim email.
- [3.4.1/H-0-1] HARUS menyediakan implementasi
android.webkit.Webview
API yang lengkap. - [3.4.2/H-0-1] HARUS menyertakan aplikasi Browser mandiri untuk penjelajahan web pengguna umum.
- [3.8.1/H-SR-1] SANGAT DISARANKAN untuk menerapkan peluncur default yang mendukung penyematan pintasan, widget, dan widgetFeatures dalam aplikasi.
- [3.8.1/H-SR-2] SANGAT DISARANKAN untuk menerapkan peluncur default yang memberikan akses cepat ke pintasan tambahan yang disediakan oleh aplikasi pihak ketiga melalui ShortcutManager API.
- [3.8.1/H-SR-3] SANGAT DISARANKAN untuk menyertakan aplikasi peluncur default yang menampilkan badge untuk ikon aplikasi.
- [3.8.2/H-SR-1] SANGAT DISARANKAN untuk mendukung widget aplikasi pihak ketiga.
- [3.8.3/H-0-1] HARUS mengizinkan aplikasi
pihak ketiga untuk memberi tahu pengguna tentang peristiwa penting melalui class API
Notification
danNotificationManager
. - [3.8.3/H-0-2] HARUS mendukung notifikasi lengkap.
- [3.8.3/H-0-3] HARUS mendukung notifikasi prapering.
- [3.8.3/H-0-4] HARUS menyertakan menu notifikasi, yang memberi pengguna kemampuan untuk mengontrol langsung (misalnya membalas, menunda, menutup, memblokir) notifikasi melalui kemampuan pengguna seperti tombol tindakan atau panel kontrol seperti yang diterapkan di AOSP.
- [3.8.3/H-0-5] HARUS menampilkan pilihan
yang diberikan melalui
RemoteInput.Builder setChoices()
di panel notifikasi. - [3.8.3/H-SR-1] SANGAT DISARANKAN
untuk menampilkan pilihan pertama yang diberikan melalui
RemoteInput.Builder setChoices()
di panel notifikasi tanpa interaksi pengguna tambahan. - [3.8.3/H-SR-2] SANGAT DISARANKAN
untuk menampilkan semua pilihan yang disediakan melalui
RemoteInput.Builder setChoices()
di panel notifikasi saat pengguna meluaskan semua notifikasi di panel notifikasi. - [3.8.3.1/H-SR-1] SANGAT DISARANKAN
untuk menampilkan tindakan yang
Notification.Action.Builder.setContextual
ditetapkan sebagaitrue
yang selaras dengan balasan yang ditampilkan olehNotification.Remoteinput.Builder.setChoices
. - [3.8.4/H-SR-1] SANGAT DISARANKAN untuk menerapkan asisten di perangkat guna menangani Tindakan bantuan.
Jika implementasi perangkat Genggam mendukung notifikasi MediaStyle, perangkat tersebut:
- [3.8.3.1/H-SR-2] SANGAT DISARANKAN
untuk memberikan kemampuan pengguna (misalnya, pengalih output) yang diakses dari
UI sistem yang memungkinkan pengguna beralih di antara rute media
yang tersedia dan sesuai (misalnya, perangkat dan rute Bluetooth yang disediakan untuk
MediaRouter2Manager
) saat aplikasi memposting notifikasiMediaStyle
dengan tokenMediaSession
.
Memulai persyaratan baru
Jika implementasi perangkat termasuk tombol navigasi fungsi terbaru seperti yang dijelaskan di bagian 7.2.3 mengubah antarmuka, tindakan tersebut:
- [3.8.3/H-1-1] HARUS menerapkan perilaku penyematan layar dan memberi pengguna menu setelan untuk mengaktifkan fitur.
Akhiri persyaratan baru
Jika implementasi perangkat Genggam mendukung tindakan Bantuan, perangkat tersebut:
- [3.8.4/H-SR-2] SANGAT DISARANKAN
untuk menggunakan tekan lama pada tombol
HOME
sebagai interaksi yang ditetapkan untuk meluncurkan aplikasi bantuan seperti yang dijelaskan di bagian 7.2.3. HARUS meluncurkan aplikasi bantuan yang dipilih pengguna, dengan kata lain aplikasi yang mengimplementasikanVoiceInteractionService
, atau aktivitas yang menangani intentACTION_ASSIST
.
Jika implementasi Perangkat genggam mendukung conversation notifications
dan mengelompokkan notifikasi tersebut ke dalam bagian terpisah dari notifikasi pemberitahuan dan notifikasi
non-percakapan senyap, notifikasi tersebut:
- [3.8.4/H-1-1]* HARUS menampilkan notifikasi percakapan sebelum notifikasi non-percakapan, kecuali notifikasi layanan latar depan yang sedang berlangsung dan notifikasi importance:high.
Jika implementasi perangkat Genggam Android mendukung layar kunci, perangkat tersebut:
- [3.8.10/H-1-1] HARUS menampilkan Notifikasi layar Kunci termasuk Template Notifikasi Media.
Jika implementasi perangkat Genggam mendukung layar kunci yang aman, implementasi tersebut:
- [3.9/H-1-1] HARUS menerapkan berbagai kebijakan administrasi perangkat yang ditentukan dalam dokumentasi Android SDK.
Jika implementasi perangkat Genggam menyertakan dukungan untuk
ControlsProviderService
dan Control
API serta mengizinkan aplikasi pihak ketiga memublikasikan kontrol perangkat, maka:
- [3.8.16/H-1-1] HARUS mendeklarasikan flag
fitur
android.software.controls
dan menetapkannya ketrue
. - [3.8.16/H-1-2] HARUS memberikan kemampuan
kepada pengguna untuk menambahkan, mengedit, memilih, dan mengoperasikan kontrol
perangkat favorit pengguna dari kontrol yang terdaftar oleh aplikasi
pihak ketiga melalui API
ControlsProviderService
danControl
. - [3.8.16/H-1-3] HARUS memberikan akses ke affordance pengguna ini dalam tiga interaksi dari Peluncur default.
[3.8.16/H-1-4] HARUS merender dengan akurat nama dan ikon setiap aplikasi pihak ketiga yang menyediakan kontrol melalui
ControlsProviderService
API serta kolom yang ditentukan yang disediakan olehControl
API.[3.8.16/H-1-5] HARUS menyediakan kemampuan pengguna untuk memilih tidak ikut kontrol perangkat autentikasi-trivial yang ditetapkan aplikasi dari kontrol yang terdaftar oleh aplikasi pihak ketiga melalui
ControlsProviderService
danControl
Control.isAuthRequired
API.
Memulai persyaratan baru
- [3.8.16/H-1-6] Implementasi perangkat
HARUS merender kemampuan pengguna secara akurat sebagai berikut:
- Jika perangkat telah menetapkan
config_supportsMultiWindow=true
dan aplikasi mendeklarasikan metadataMETA_DATA_PANEL_ACTIVITY
dalam deklarasiControlsProviderService
, termasuk ComponentName dari aktivitas yang valid (seperti yang ditentukan oleh API), aplikasi HARUS menyematkan aktivitas tersebut dalam kemampuan pengguna ini. - Jika aplikasi tidak mendeklarasikan metadata
META_DATA_PANEL_ACTIVITY
, aplikasi HARUS merender kolom yang ditentukan seperti yang disediakan olehControlsProviderService
API serta kolom yang ditentukan yang disediakan oleh Control API.
- Jika perangkat telah menetapkan
- [3.8.16/H-1-7] Jika aplikasi mendeklarasikan metadata
META_DATA_PANEL_ACTIVITY
, aplikasi HARUS meneruskan nilai setelan yang ditentukan dalam [3.8.16/H-1-5] menggunakanEXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS
saat meluncurkan aktivitas tersemat.
Akhiri persyaratan baru
Sebaliknya, jika implementasi perangkat Genggam tidak menerapkan kontrol tersebut, perangkat tersebut:
- [3.8.16/H-2-1] HARUS melaporkan
null
untukControlsProviderService
danControl
API. - [3.8.16/H-2-2] HARUS mendeklarasikan flag
fitur
android.software.controls
dan menetapkannya kefalse
.
Jika implementasi perangkat genggam tidak berjalan dalam mode tugas kunci, saat konten disalin ke papan klip, konten tersebut:
- [3.8.17/H-1-1] HARUS menampilkan konfirmasi kepada pengguna bahwa data telah disalin ke papan klip (misalnya, thumbnail atau notifikasi “Konten disalin”). Selain itu, sertakan di sini indikasi apakah data papan klip akan disinkronkan di seluruh perangkat.
Implementasi perangkat genggam:
- [3.10/H-0-1] HARUS mendukung layanan aksesibilitas pihak ketiga.
- [3.10/H-SR-1] SANGAT DISARANKAN untuk memuat layanan aksesibilitas di perangkat secara default yang sebanding dengan atau melebihi fungsi layanan aksesibilitas Tombol Akses dan TalkBack (untuk bahasa yang didukung oleh mesin Text-to-speech yang diinstal sebelumnya) seperti yang disediakan dalam project open source talkback.
- [3.11/H-0-1] HARUS mendukung penginstalan mesin TTS pihak ketiga.
- [3.11/H-SR-1] SANGAT DISARANKAN untuk menyertakan mesin TTS yang mendukung bahasa yang tersedia di perangkat.
- [3.13/H-SR-1] SANGAT DISARANKAN untuk menyertakan komponen UI Setelan Cepat.
Jika implementasi perangkat genggam Android mendeklarasikan dukungan FEATURE_BLUETOOTH
atau
FEATURE_WIFI
, implementasi tersebut:
- [3.16/H-1-1] HARUS mendukung fitur penyambungan perangkat pendamping.
Jika fungsi navigasi disediakan sebagai tindakan berbasis gestur di layar:
- [7.2.3/H] Zona pengenalan gestur untuk fungsi Home HARUS tidak lebih tinggi dari 32 dp dari bagian bawah layar.
Jika implementasi perangkat Genggam menyediakan fungsi navigasi sebagai gestur dari mana saja di tepi kiri dan kanan layar:
- [7.2.3/H-0-1] Area gestur fungsi navigasi HARUS memiliki lebar kurang dari 40 dp di setiap sisi. Area gestur HARUS berlebar 24 dp secara default.
Jika implementasi perangkat Genggam mendukung layar kunci aman dan memiliki memori lebih besar dari atau sama dengan 2 GB yang tersedia untuk kernel dan ruang pengguna, perangkat tersebut:
- [3.9/H-1-2] HARUS mendeklarasikan dukungan profil terkelola melalui
flag fitur
android.software.managed_users
.
Jika implementasi perangkat genggam Android mendeklarasikan dukungan untuk kamera melalui
android.hardware.camera.any
, perangkat tersebut:
- [7.5.4/H-1-1] HARUS mematuhi intent
android.media.action.STILL_IMAGE_CAMERA
danandroid.media.action.STILL_IMAGE_CAMERA_SECURE
dan meluncurkan kamera dalam mode gambar diam seperti yang dijelaskan dalam SDK. - [7.5.4/H-1-2] HARUS mematuhi intent
android.media.action.VIDEO_CAMERA
untuk meluncurkan kamera dalam mode video seperti yang dijelaskan dalam SDK.
Jika aplikasi setelan implementasi perangkat mengimplementasikan fungsi terpisah, menggunakan penyematan aktivitas, aplikasi tersebut:
- [3.2.3.1/ H-1-1] HARUS memiliki aktivitas yang menangani
intent Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY saat fungsi pemisahan aktif. Aktivitas HARUS dilindungi oleh
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
dan HARUS memulai aktivitas Intent yang diuraikan dari Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.
Memulai persyaratan baru
Jika implementasi perangkat memungkinkan pengguna melakukan panggilan apa pun, mereka
- [7.4.1.2/H-0-1] HARUS mendeklarasikan tombol fitur
android.software.telecom
. - [7.4.1.2/H-0-2] HARUS menerapkan framework telekomunikasi.
Akhiri persyaratan baru
2.2.4. Performa dan Daya
- [8.1/H-0-1] Latensi frame yang konsisten. Latensi frame yang tidak konsisten atau penundaan untuk merender frame TIDAK BOLEH terjadi lebih dari 5 frame dalam satu detik, dan HARUS di bawah 1 frame dalam satu detik.
- [8.1/H-0-2] Latensi antarmuka pengguna. Implementasi perangkat HARUS memastikan pengalaman pengguna latensi rendah dengan men-scroll daftar 10 ribu entri daftar seperti yang ditentukan oleh Android Compatibility Test Suite (CTS) dalam waktu kurang dari 36 detik.
- [8.1/H-0-3] Pengalihan tugas. Saat beberapa aplikasi telah diluncurkan, meluncurkan ulang aplikasi yang sudah berjalan setelah diluncurkan HARUS memerlukan waktu kurang dari 1 detik.
Implementasi perangkat genggam:
- [8.2/H-0-1] HARUS memastikan performa tulis berurutan minimal 5 MB/dtk.
- [8.2/H-0-2] HARUS memastikan performa tulis acak minimal 0,5 MB/s.
- [8.2/H-0-3] HARUS memastikan performa baca terurut minimal 15 MB/dtk.
- [8.2/H-0-4] HARUS memastikan performa pembacaan acak minimal 3,5 MB/s.
Jika implementasi perangkat Genggam menyertakan fitur untuk meningkatkan pengelolaan daya perangkat yang disertakan dalam AOSP atau memperluas fitur yang disertakan dalam AOSP, fitur tersebut:
- [8.3/H-1-1] HARUS memberikan kemampuan pengguna untuk mengaktifkan dan menonaktifkan fitur penghemat baterai.
- [8.3/H-1-2] HARUS memberikan kemampuan pengguna untuk menampilkan semua aplikasi yang dikecualikan dari mode hemat daya Aplikasi Standby dan Istirahatkan.
Implementasi perangkat genggam:
- [8.4/H-0-1] HARUS menyediakan profil daya per komponen yang menentukan nilai konsumsi saat ini untuk setiap komponen hardware dan perkiraan pemakaian baterai yang disebabkan oleh komponen dari waktu ke waktu seperti yang didokumentasikan di situs Android Open Source Project.
- [8.4/H-0-2] HARUS melaporkan semua nilai konsumsi daya dalam miliamper jam (mAh).
- [8.4/H-0-3] HARUS melaporkan konsumsi daya
CPU per UID setiap proses. Project Open Source Android memenuhi
persyaratan melalui implementasi modul kernel
uid_cputime
. - [8.4/H-0-4] HARUS menyediakan penggunaan daya ini
melalui perintah shell
adb shell dumpsys batterystats
kepada developer aplikasi. - [8,4/H] HARUS diatribusikan ke komponen hardware itu sendiri jika tidak dapat mengatribusikan penggunaan daya komponen hardware ke aplikasi.
Jika implementasi Perangkat genggam menyertakan output layar atau video, implementasi tersebut:
- [8.4/H-1-1] HARUS mematuhi
intent
android.intent.action.POWER_USAGE_SUMMARY
dan menampilkan menu setelan yang menunjukkan penggunaan daya ini.
Implementasi perangkat genggam:
- [8.5/H-0-1] HARUS menyediakan
affordance pengguna
di menu Setelanuntuk melihat semua aplikasi dengan layanan latar depan aktif atau tugas yang dimulai pengguna, termasuk durasi setiap layanan ini sejak dimulai seperti yang dijelaskan dalam dokumen SDK.dan kemampuan untuk menghentikan aplikasi yang menjalankan layanan latar depan atau tugas yang dimulai pengguna.dengan kemampuan untuk menghentikan aplikasi yang menjalankan layanan latar depan dan menampilkan semua aplikasi yang memiliki layanan latar depan aktif dan durasi setiap layanan ini sejak dimulai seperti yang dijelaskan dalam dokumen SDK.- Beberapa aplikasi DAPAT dikecualikan dari dihentikan atau dicantumkan dalam affordance pengguna seperti yang dijelaskan dalam dokumen SDK.
Memulai persyaratan baru
- [8.5/H-0-2]HARUS memberikan kemampuan pengguna untuk menghentikan aplikasi yang menjalankan layanan latar depan atau tugas yang dimulai pengguna.
Akhiri persyaratan baru
2.2.5. Model Keamanan
Implementasi perangkat genggam:
- [9/H-0-1] HARUS mendeklarasikan fitur
android.hardware.security.model.compatible
. - [9.1/H-0-1] HARUS mengizinkan aplikasi pihak ketiga mengakses
statistik penggunaan melalui izin
android.permission.PACKAGE_USAGE_STATS
dan menyediakan mekanisme yang dapat diakses pengguna untuk memberikan atau mencabut akses ke aplikasi tersebut sebagai respons terhadap intentandroid.settings.ACTION_USAGE_ACCESS_SETTINGS
.
Memulai persyaratan baru
Jika implementasi perangkat mendeklarasikan dukungan untuk android.hardware.telephony
,
implementasi tersebut:
- [9.5/H-1-1] TIDAK BOLEH menetapkan
UserManager.isHeadlessSystemUserMode
ketrue
.
Akhiri persyaratan baru
Implementasi perangkat genggam:
- [9.11/H-0-2] HARUS mencadangkan implementasi keystore dengan lingkungan eksekusi yang terisolasi.
- [9.11/H-0-3] HARUS memiliki implementasi algoritma kriptografis RSA, AES, ECDSA, dan HMAC serta fungsi hash keluarga MD5, SHA1, dan SHA-2 untuk mendukung algoritma yang didukung sistem Keystore Android dengan benar di area yang terisolasi dengan aman dari kode yang berjalan di kernel dan yang lebih baru. Isolasi aman HARUS memblokir semua mekanisme potensial yang memungkinkan kode kernel atau ruang pengguna mengakses status internal lingkungan terisolasi, termasuk DMA. Project Open Source Android upstream (AOSP) memenuhi persyaratan ini dengan menggunakan implementasi Trusty, tetapi solusi berbasis ARM TrustZone lainnya atau implementasi aman yang ditinjau pihak ketiga dari isolasi berbasis hypervisor yang tepat adalah opsi alternatif.
- [9.11/H-0-4] HARUS melakukan autentikasi layar kunci di lingkungan eksekusi terisolasi dan hanya jika berhasil, izinkan kunci yang terikat autentikasi untuk digunakan. Kredensial layar kunci HARUS disimpan dengan cara yang hanya mengizinkan lingkungan eksekusi terisolasi untuk melakukan autentikasi layar kunci. Project Open Source Android upstream menyediakan Gatekeeper Hardware Abstraction Layer (HAL) dan Trusty, yang dapat digunakan untuk memenuhi persyaratan ini.
- [9.11/H-0-5] HARUS mendukung pengesahan kunci dengan kunci penandatanganan pengesahan dilindungi oleh hardware aman dan penandatanganan dilakukan di hardware aman. Kunci penandatanganan pengesahan HARUS dibagikan di sejumlah perangkat yang cukup besar untuk mencegah kunci digunakan sebagai ID perangkat. Salah satu cara untuk memenuhi persyaratan ini adalah dengan membagikan kunci pengesahan yang sama,kecuali jika setidaknya 100.000 unit SKU tertentu diproduksi. Jika lebih dari 100.000 unit SKU diproduksi, kunci yang berbeda DAPAT digunakan untuk setiap 100.000 unit.
Perhatikan bahwa jika implementasi perangkat sudah diluncurkan pada versi Android
sebelumnya, perangkat tersebut dikecualikan dari persyaratan untuk memiliki keystore
yang didukung oleh lingkungan eksekusi terisolasi dan mendukung pengesahan kunci,
kecuali jika mendeklarasikan fitur android.hardware.fingerprint
yang memerlukan
keystore yang didukung oleh lingkungan eksekusi terisolasi.
Jika implementasi perangkat Genggam mendukung layar kunci yang aman, perangkat tersebut:
- [9.11/H-1-1] HARUS mengizinkan pengguna memilih waktu tunggu tidur terpendek, yaitu waktu transisi dari status tidak terkunci ke terkunci, selama 15 detik atau kurang.
- [9.11/H-1-2] HARUS memberikan kemampuan pengguna untuk menyembunyikan notifikasi dan menonaktifkan semua bentuk autentikasi kecuali untuk autentikasi utama yang dijelaskan dalam 9.11.1 Layar Kunci yang Aman. AOSP memenuhi persyaratan sebagai mode kunci total.
Memulai persyaratan baru
Jika implementasi perangkat memiliki layar kunci yang aman dan menyertakan satu atau beberapa agen kepercayaan, yang mengimplementasikan TrustAgentService
System API, implementasi tersebut:
- [9.11.1/H-1-1] HARUS meminta pengguna untuk menggunakan salah satu metode autentikasi utama yang direkomendasikan (misalnya: PIN, pola, sandi) lebih sering daripada sekali setiap 72 jam.
Akhiri persyaratan baru
Jika implementasi perangkat Genggam menyertakan beberapa pengguna dan
tidak mendeklarasikan tanda fitur android.hardware.telephony
, implementasi tersebut:
- [9.5/H-2-1] HARUS mendukung profil yang dibatasi, fitur yang memungkinkan pemilik perangkat mengelola pengguna tambahan dan kemampuan mereka di perangkat. Dengan profil yang dibatasi, pemilik perangkat dapat dengan cepat menyiapkan lingkungan terpisah bagi pengguna tambahan untuk bekerja, dengan kemampuan untuk mengelola pembatasan yang lebih terperinci di aplikasi yang tersedia di lingkungan tersebut.
Jika implementasi Perangkat genggam menyertakan beberapa pengguna dan
mendeklarasikan tanda fitur android.hardware.telephony
, implementasi tersebut:
- [9.5/H-3-1] TIDAK BOLEH mendukung profil terbatas, tetapi HARUS selaras dengan implementasi kontrol AOSP untuk mengaktifkan /menonaktifkan pengguna lain agar tidak dapat mengakses panggilan suara dan SMS.
Memulai persyaratan baru
Jika implementasi perangkat Genggam menetapkan UserManager.isHeadlessSystemUserMode
ke true
, perangkat tersebut
- [9.5/H-4-1] TIDAK BOLEH menyertakan dukungan untuk eUICC, atau untuk eSIM dengan kemampuan menelepon.
- [9.5/H-4-2] TIDAK BOLEH mendeklarasikan dukungan untuk
android.hardware.telephony
.
Akhiri persyaratan baru
Android, melalui System API VoiceInteractionService, mendukung mekanisme untuk deteksi frasa pengaktif suara yang selalu aktif dan aman tanpa indikasi akses mikrofon dan deteksi kueri yang selalu aktif, tanpa indikasi akses mikrofon atau kamera.
Jika implementasi perangkat Genggam mendukung System API
HotwordDetectionService
atau mekanisme lain untuk deteksi kata panas tanpa
indikasi akses mikrofon, implementasi tersebut:
- [9.8/H-1-1] HARUS memastikan layanan deteksi kata kunci hanya dapat mengirimkan
data ke Sistem,
ContentCaptureService
, atau layanan pengenalan ucapan di perangkat yang dibuat olehSpeechRecognizer#createOnDeviceSpeechRecognizer()
. - [9.8/H-1-2] HARUS memastikan layanan deteksi kata kunci hanya dapat mengirimkan
data audio mikrofon atau data yang berasal darinya ke server sistem melalui
HotwordDetectionService
API, atau keContentCaptureService
melaluiContentCaptureManager
API. - [9.8/H-1-3] TIDAK BOLEH menyediakan audio mikrofon yang berdurasi lebih dari 30 detik untuk setiap permintaan yang dipicu hardware ke layanan deteksi kata kunci panas.
- [9.8/H-1-4] TIDAK BOLEH menyediakan audio mikrofon yang di-buffer yang lebih lama dari 8 detik untuk setiap permintaan ke layanan deteksi frasa pengaktif suara.
- [9.8/H-1-5] TIDAK BOLEH menyediakan audio mikrofon yang di-buffer yang lebih lama dari 30 detik ke layanan interaksi suara atau entitas serupa.
- [9.8/H-1-6] TIDAK BOLEH mengizinkan lebih dari 100 byte data ditransmisikan dari layanan deteksi kata kunci panas pada setiap hasil kata kunci panas yang berhasil kecuali untuk data audio yang diteruskan melalui HotwordAudioStream.
- [9.8/H-1-7] TIDAK BOLEH mengizinkan lebih dari 5 bit data dikirim dari layanan deteksi frasa pengaktif pada setiap hasil frasa pengaktif negatif.
- [9.8/H-1-8] HANYA BOLEH mengizinkan transmisi data dari layanan deteksi hotword pada permintaan validasi hotword dari server sistem.
- [9.8/H-1-9] TIDAK BOLEH mengizinkan aplikasi yang dapat diinstal pengguna untuk menyediakan layanan deteksi kata kunci panas.
- [9.8/H-1-10] TIDAK BOLEH muncul di data kuantitatif UI tentang penggunaan mikrofon oleh layanan deteksi frasa pengaktif.
- [9.8/H-1-11] HARUS mencatat jumlah byte yang disertakan dalam setiap transmisi dari layanan deteksi kata panas untuk memungkinkan pemeriksaan bagi peneliti keamanan.
- [9.8/H-1-12] HARUS mendukung mode debug yang mencatat konten mentah dari setiap transmisi dari layanan deteksi frasa pengaktif untuk memungkinkan pemeriksaan bagi peneliti keamanan.
- [9.8/H-1-14] HARUS menampilkan indikator mikrofon, seperti yang dijelaskan di bagian 9.8.2, saat hasil kata kunci panas yang berhasil dikirim ke layanan interaksi suara atau entitas serupa.
Memulai persyaratan baru
- [9.8/H-1-15] HARUS memastikan bahwa streaming audio yang diberikan pada hasil frasa pengaktif yang berhasil dikirimkan satu arah dari layanan deteksi frasa pengaktif ke layanan interaksi suara.
Akhiri persyaratan baru
- [9.8/H-SR-1] SANGAT DISARANKAN untuk memberi tahu pengguna sebelum menetapkan aplikasi sebagai penyedia layanan deteksi kata kunci panas.
- [9.8/H-SR-2] SANGAT DISARANKAN untuk tidak mengizinkan transmisi data tidak terstruktur dari layanan deteksi kata kunci panas.
- [9.8/H-SR-3] SANGAT DISARANKAN untuk memulai ulang proses yang menghosting layanan deteksi kata kunci panas setidaknya sekali setiap jam atau setiap 30 peristiwa pemicu hardware, mana saja yang lebih dulu.
Jika implementasi perangkat menyertakan aplikasi yang menggunakan System API
HotwordDetectionService
, atau mekanisme serupa untuk deteksi kata panas tanpa
indikasi penggunaan mikrofon, aplikasi:
- [9.8/H-2-1] HARUS memberikan pemberitahuan eksplisit kepada pengguna untuk setiap frasa kata panas yang didukung.
- [9.8/H-2-2] TIDAK BOLEH mempertahankan data audio mentah, atau data yang berasal darinya, melalui layanan deteksi kata kunci panas.
- [9.8/H-2-3] TIDAK BOLEH mengirimkan dari layanan deteksi kata kunci panas, data
audio, data yang dapat digunakan untuk merekonstruksi (secara keseluruhan atau sebagian) audio,
atau konten audio yang tidak terkait dengan kata kunci panas itu sendiri, kecuali ke
ContentCaptureService
atau layanan pengenalan ucapan di perangkat.
Memulai persyaratan baru
Jika implementasi perangkat Genggam mendukung System API
VisualQueryDetectionService
atau mekanisme lain untuk deteksi kueri
tanpa indikasi akses mikrofon dan/atau kamera, perangkat tersebut:
- [9.8/H-3-1] HARUS memastikan layanan deteksi kueri hanya dapat mengirimkan
data ke Sistem, atau
ContentCaptureService
, atau layanan pengenalan ucapan di perangkat (dibuat olehSpeechRecognizer#createOnDeviceSpeechRecognizer()
). - [9.8/H-3-2] TIDAK BOLEH mengizinkan informasi audio atau video apa pun dikirim
ke luar
VisualQueryDetectionService
, kecuali keContentCaptureService
atau layanan pengenalan ucapan di perangkat. - [9.8/H-3-3] HARUS menampilkan pemberitahuan pengguna di UI Sistem saat perangkat mendeteksi intent pengguna untuk berinteraksi dengan Aplikasi Asisten Digital (misalnya dengan mendeteksi kehadiran pengguna melalui kamera).
- [9.8/H-3-4] HARUS menampilkan indikator mikrofon dan menampilkan kueri pengguna yang terdeteksi di UI tepat setelah kueri pengguna terdeteksi.
- [9.8/H-3-5] TIDAK BOLEH mengizinkan aplikasi yang dapat diinstal pengguna untuk menyediakan layanan deteksi kueri visual.
Akhiri persyaratan baru
Jika implementasi perangkat Genggam mendeklarasikan android.hardware.microphone
, implementasi tersebut:
- [9.8.2/H-4-1] HARUS menampilkan indikator mikrofon saat
aplikasi mengakses data audio dari mikrofon, tetapi tidak saat
mikrofon hanya diakses oleh
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
, atau aplikasi yang memiliki peran yang disebut di bagian 9.1 dengan ID CDD [C-4-X]. - [9.8.2/H-4-2] HARUS menampilkan daftar aplikasi Terbaru dan Aktif
yang menggunakan mikrofon seperti yang ditampilkan dari
PermissionManager.getIndicatorAppOpUsageData()
, beserta pesan atribusi apa pun yang terkait dengannya.
Jika implementasi perangkat Genggam mendeklarasikan android.hardware.camera.any
, implementasi tersebut:
- [9.8.2/H-5-1] HARUS menampilkan indikator kamera saat aplikasi mengakses data kamera live, tetapi tidak saat kamera hanya diakses oleh aplikasi yang memiliki peran yang disebutkan dalam bagian 9.1 dengan ID CDD [C-4-X].
- [9.8.2/H-5-2] HARUS menampilkan aplikasi Terbaru dan Aktif menggunakan
kamera seperti yang ditampilkan dari
PermissionManager.getIndicatorAppOpUsageData()
, beserta pesan atribusi apa pun yang terkait dengannya.
2.2.6. Kompatibilitas Alat dan Opsi Developer
Implementasi perangkat genggam (* Tidak berlaku untuk Tablet):
- [6.1/H-0-1]* HARUS mendukung perintah shell
cmd testharness
.
Implementasi perangkat genggam (* Tidak berlaku untuk Tablet):
- Perfetto
- [6.1/H-0-2]* HARUS mengekspos biner
/system/bin/perfetto
ke pengguna shell yang cmdline-nya mematuhi dokumentasi perfetto. - [6.1/H-0-3]* Biner perfetto HARUS menerima sebagai input konfigurasi protobuf yang mematuhi skema yang ditentukan dalam dokumentasi perfetto.
- [6.1/H-0-4]* Biner perfetto HARUS menulis sebagai output rekaman aktivitas protobuf yang mematuhi skema yang ditentukan dalam dokumentasi perfetto.
- [6.1/H-0-5]* HARUS menyediakan, melalui biner perfetto, setidaknya sumber data yang dijelaskan dalam dokumentasi perfetto.
- [6.1/H-0-6]* Daemon pelacakan perfetto HARUS
diaktifkan secara default (properti sistem
persist.traced.enable
).
- [6.1/H-0-2]* HARUS mengekspos biner
2.2.7. Class Performa Media Perangkat Genggam
Lihat Bagian 7.11 untuk mengetahui definisi class performa media.
2.2.7.1. Media
Jika implementasi perangkat Genggam menampilkan android.os.Build.VERSION_CODES.T
untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, maka:
- HARUS memenuhi persyaratan media yang tercantum di bagian 2.2.7.1 CDD Android 13.
Memulai persyaratan baru
Jika implementasi perangkat Genggam menampilkanandroid.os.Build.VERSION_CODES.U
untuk
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, maka:
- [5.1/H-1-1] HARUS mengiklankan jumlah maksimum sesi decoder video hardware
yang dapat dijalankan secara serentak dalam kombinasi codec apa pun melalui
metode
CodecCapabilities.getMaxSupportedInstances()
danVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-2] HARUS mendukung 6 instance sesi decoder video hardware 8-bit (SDR) (AVC, HEVC, VP9, AV1, atau yang lebih baru) dalam kombinasi codec apa pun yang berjalan secara serentak dengan 3 sesi pada resolusi 1080p@30 fps dan 3 sesi pada resolusi 4K@30fps. Codec AV1 hanya diperlukan untuk mendukung resolusi 1080p, tetapi masih diperlukan untuk mendukung 6 instance pada 1080p30fps.
- [5.1/H-1-3] HARUS mengiklankan jumlah maksimum sesi encoder video hardware
yang dapat dijalankan secara serentak dalam kombinasi codec apa pun melalui
metode
CodecCapabilities.getMaxSupportedInstances()
danVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-4] HARUS mendukung 6 instance sesi encoder video hardware 8-bit (SDR) (AVC, HEVC, VP9, AV1, atau yang lebih baru) dalam kombinasi codec apa pun yang berjalan secara serentak dengan 4 sesi pada resolusi 1080p@30 fps dan 2 sesi pada resolusi 4K@30fps. Codec AV1 hanya diperlukan untuk mendukung resolusi 1080p, tetapi masih diperlukan untuk mendukung 6 instance pada 1080p30fps.
- [5.1/H-1-5] HARUS mengiklankan jumlah maksimum sesi encoder dan decoder video hardware yang dapat dijalankan secara serentak dalam kombinasi codec apa pun melalui metode
CodecCapabilities.getMaxSupportedInstances()
danVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-6] HARUS mendukung 6 instance dekoder video hardware 8-bit (SDR) dan sesi encoder video hardware (AVC, HEVC, VP9, AV1, atau yang lebih baru) dalam kombinasi codec apa pun yang berjalan secara serentak dengan 3 sesi pada resolusi 4K@30fps, yang paling banyak 2 adalah sesi encoder dan 3 sesi pada resolusi 1080p. Codec AV1 hanya diperlukan untuk mendukung resolusi 1080p, tetapi masih diperlukan untuk mendukung 6 instance pada 1080p30fps.
- [5.1/H-1-19] HARUS mendukung 3 instance dekoder video hardware 10-bit (HDR) dan sesi encoder video hardware (AVC, HEVC, VP9, AV1, atau yang lebih baru) dalam kombinasi codec apa pun yang berjalan secara serentak pada resolusi 4K@30fps dengan maksimal 1 sesi encoder, yang dapat dikonfigurasi dalam format input RGBA_1010102 melalui platform GL. Pembuatan metadata HDR oleh encoder tidak diperlukan jika encoding dari platform GL. Sesi codec AV1 hanya diperlukan untuk mendukung resolusi 1080p meskipun persyaratan ini memerlukan 4K.
- [5.1/H-1-7] HARUS memiliki latensi inisialisasi codec 40 md atau kurang untuk sesi encoding video 1080p atau lebih kecil untuk semua encoder video hardware saat beban tinggi. Beban di sini didefinisikan sebagai sesi transcoding khusus video 1080p hingga 720p serentak menggunakan codec video hardware bersama dengan inisialisasi perekaman audio-video 1080p. Untuk codec Dolby vision, latensi inisialisasi codec HARUS 50 md atau kurang.
- [5.1/H-1-8] HARUS memiliki latensi inisialisasi codec 30 md atau kurang untuk sesi encoding audio dengan kecepatan bit 128 kbps atau lebih rendah untuk semua encoder audio saat beban tinggi. Beban di sini didefinisikan sebagai sesi transcoding khusus video 1080p hingga 720p serentak menggunakan codec video hardware bersama dengan inisialisasi perekaman audio-video 1080p.
- [5.1/H-1-9] HARUS mendukung 2 instance sesi dekoder video hardware yang aman (AVC, HEVC, VP9, AV1, atau yang lebih baru) dalam kombinasi codec apa pun yang berjalan secara serentak pada resolusi 1080p@30 fps untuk konten HDR 8-bit (SDR) dan 10-bit.
- [5.1/H-1-10] HARUS mendukung 3 instance sesi decoder video hardware yang tidak aman bersama dengan 1 instance sesi decoder video hardware yang aman (total 4 instance) (AVC, HEVC, VP9, AV1, atau yang lebih baru) dalam kombinasi codec apa pun yang berjalan secara serentak dengan 3 sesi pada resolusi 4K@30 fps yang mencakup satu sesi decoder aman dan 1 sesi tidak aman pada resolusi 1080p@30fps dengan maksimal 2 sesi 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 hardware di perangkat.
- [5.1/H-1-12] HARUS memiliki latensi inisialisasi codec 40 md atau kurang untuk sesi decoding video 1080p atau lebih kecil untuk semua dekoder video hardware saat sedang dimuat. Beban di sini didefinisikan sebagai sesi transcoding khusus video 1080p ke 720p serentak menggunakan codec video hardware bersama dengan inisialisasi pemutaran audio-video 1080p. Untuk codec Dolby vision, latensi inisialisasi codec HARUS 50 md atau kurang.
- [5.1/H-1-13] HARUS memiliki latensi inisialisasi codec 30 md atau kurang untuk sesi decoding audio dengan kecepatan bit 128 kbps atau lebih rendah untuk semua decoder audio saat dimuat. Beban di sini didefinisikan sebagai sesi transcoding khusus video 1080p hingga 720p serentak menggunakan codec video hardware bersama dengan inisialisasi pemutaran audio-video 1080p.
- [5.1/H-1-14] HARUS mendukung decoder hardware AV1 Main 10, Level 4.1, dan grain film.
- [5.1/H-1-15] HARUS memiliki minimal 1 decoder video hardware yang mendukung 4K60.
- [5.1/H-1-16] HARUS memiliki minimal 1 encoder video hardware yang mendukung 4K60.
- [5.3/H-1-1] TIDAK BOLEH kehilangan lebih dari 1 frame dalam 10 detik (yaitu kurang dari 0,167 persen penurunan frame) untuk sesi video 4K 60 fps saat dimuat.
- [5.3/H-1-2] TIDAK BOLEH kehilangan lebih dari 1 frame dalam 10 detik selama perubahan resolusi video dalam sesi video 60 fps yang sedang dimuat untuk sesi 4K.
- [5.6/H-1-1] HARUS memiliki latensi ketuk-untuk-nada 80 milidetik atau kurang menggunakan pengujian ketuk-untuk-nada CTS Verifier.
- [5.6/H-1-2] HARUS memiliki latensi audio bolak-balik 80 milidetik atau kurang melalui setidaknya satu jalur data yang didukung.
- [5.6/H-1-3] HARUS mendukung audio >=24-bit untuk output stereo melalui konektor 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, AudioTrack Java harus digunakan oleh
aplikasi. Dalam konfigurasi streaming dan latensi rendah, sink output HAL
harus menerima
AUDIO_FORMAT_PCM_24_BIT
,AUDIO_FORMAT_PCM_24_BIT_PACKED
,AUDIO_FORMAT_PCM_32_BIT
, atauAUDIO_FORMAT_PCM_FLOAT
untuk format output targetnya. - [5.6/H-1-4] HARUS mendukung perangkat audio USB >=4 saluran (Ini digunakan oleh pengontrol DJ untuk melihat pratinjau lagu.)
- [5.6/H-1-5] HARUS mendukung perangkat MIDI yang kompatibel dengan class dan mendeklarasikan flag fitur MIDI.
- [5.6/H-1-9] HARUS mendukung minimal 12 channel mixing. Hal ini menyiratkan kemampuan untuk membuka AudioTrack dengan mask saluran 7.1.4 dan membuat spasial atau mendownmix semua saluran ke stereo dengan benar.
- [5.6/H-SR] SANGAT DIUTAMAKAN untuk mendukung pencampuran 24 saluran dengan setidaknya dukungan untuk mask saluran 9.1.6 dan 22.2.
- [5.7/H-1-2] HARUS mendukung
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL
dengan kemampuan dekripsi konten di bawah.
Ukuran Sampel minimum | 4 MiB |
Jumlah Subsampel Minimum - H264 atau HEVC | 32 |
Jumlah Subsampel Minimum - VP9 | 9 |
Jumlah Subsampel Minimum - AV1 | 288 |
Ukuran buffer sub-sampel minimum | 1 MiB |
Ukuran buffer crypto Generik minimum | 500 KiB |
Jumlah Minimum sesi serentak | 30 |
Jumlah Kunci minimum per sesi | 20 |
Jumlah Total Kunci Minimum (semua sesi) | 80 |
Jumlah Total Minimum Kunci DRM (semua sesi) | 6 |
Ukuran Pesan | 16 KiB |
Frame per Detik yang Didekripsi | 60 fps |
- [5.1/H-1-17] HARUS memiliki minimal 1 decoder gambar hardware yang mendukung Profil Dasar Pengukuran AVIF.
- [5.1/H-1-18] HARUS mendukung encoder AV1 yang dapat mengenkode hingga resolusi 480p pada 30 fps dan 1 Mbps.
[5.12/H-1-1] HARUS[5.12/H-SR] Sangat Direkomendasikan untuk mendukung fiturFeature_HdrEditing
untuk semua encoder AV1 dan HEVC hardware yang ada di perangkat.- [5.12/H-1-2] HARUS mendukung format warna RGBA_1010102 untuk semua encoder HEVC dan AV1 hardware 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 overlay hardware di unit pemrosesan layar (DPU), 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 hardware, maka:
- [5.2/H-2-1] HARUS memenuhi target kualitas minimum yang ditentukan oleh kurva distorsi kecepatan encoder video untuk codec AVC dan HEVC hardware, seperti yang ditentukan dalam Pengujian Run Performance Class 14 (PC14)-Video encoding quality (VEQ).
Akhiri persyaratan baru
2.2.7.2. Kamera
Jika implementasi perangkat Genggam menampilkan android.os.Build.VERSION_CODES.T
untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, maka:
- HARUS memenuhi persyaratan media yang tercantum di bagian 2.2.7.2 CDD Android 13.
Memulai persyaratan baru
Jika implementasi perangkat Genggam menampilkanandroid.os.Build.VERSION_CODES.U
untuk
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, maka:
- [7.5/H-1-1] HARUS memiliki kamera belakang utama dengan resolusi minimal 12 megapiksel yang mendukung perekaman 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 perekaman 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
sebagaiFULL
atau lebih baik untuk kamera utama belakang danLIMITED
atau lebih baik untuk kamera utama depan. - [7.5/H-1-4] HARUS mendukung
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME
untuk kedua kamera utama. - [7.5/H-1-5] HARUS memiliki latensi pengambilan JPEG camera2 < 1000
900ms untuk resolusi 1080p seperti yang diukur oleh PerformanceTest kamera CTS dalam kondisi pencahayaan ITS (3000K) untuk kedua kamera utama. - [7.5/H-1-6] HARUS memiliki latensi startup camera2 (membuka kamera ke frame pratinjau pertama) < 500 md seperti 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 belakang yang mendukung 720p atau 1080p @ 240 fps.
- [7.5/H-1-10] HARUS memiliki ZOOM_RATIO min < 1,0 untuk kamera utama jika ada kamera RGB ultrawide yang menghadap ke arah yang sama.
- [7.5/H-1-11] HARUS menerapkan streaming depan-belakang serentak di kamera utama.
- [7.5/H-1-12] HARUS mendukung
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
untuk kamera depan utama dan kamera belakang utama. - [7.5/H-1-13] HARUS mendukung kemampuan
LOGICAL_MULTI_CAMERA
untuk kamera belakang utama jika ada lebih dari 1 kamera belakang RGB. - [7.5/H-1-14] HARUS mendukung kemampuan
STREAM_USE_CASE
untuk kamera depan utama dan kamera belakang utama. - [7.5/H-1-15] HARUS mendukung
Bokeh &ekstensi mode Malam melalui ekstensi CameraX dan Camera2 untuk kamera utama. - [7.5/H-1-16] HARUS mendukung kemampuan DYNAMIC_RANGE_TEN_BIT untuk kamera utama.
- [7.5/H-1-17] HARUS mendukung CONTROL_SCENE_MODE_FACE_PRIORITY dan deteksi wajah (STATISTICS_FACE_DETECT_MODE_SIMPLE atau STATISTICS_FACE_DETECT_MODE_FULL) untuk kamera utama.
Akhiri persyaratan baru
2.2.7.3. Hardware
Jika implementasi perangkat Genggam menampilkan android.os.Build.VERSION_CODES.T
untuk
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, maka:
- HARUS memenuhi persyaratan media yang tercantum di bagian 2.2.7.3 CDD Android 13.
Memulai persyaratan baru
Jika implementasi perangkat Genggam menampilkanandroid.os.Build.VERSION_CODES.U
untuk
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, maka:
- [7.1.1.1/H-2-1] HARUS memiliki resolusi layar minimal 1080p.
- [7.1.1.3/H-2-1] HARUS memiliki kepadatan layar minimal 400 dpi.
- [7.1.1.3/H-3-1] HARUS memiliki layar HDR yang mendukung rata-rata setidaknya 1.000 nits.
- [7.6.1/H-2-1] HARUS memiliki memori fisik minimal 8 GB.
Akhiri persyaratan baru
2.2.7.4. Performa
Jika implementasi perangkat Genggam menampilkan android.os.Build.VERSION_CODES.T
untuk
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, maka:
- HARUS memenuhi persyaratan performa yang tercantum di bagian 2.2.7.4 CDD Android 13.
Memulai persyaratan baru
Jika implementasi perangkat Genggam menampilkanandroid.os.Build.VERSION_CODES.U
untuk
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, maka:
- [8.2/H-1-1] HARUS memastikan performa tulis berurutan minimal 150 MB/s.
- [8.2/H-1-2] HARUS memastikan performa tulis acak minimal 10 MB/s.
- [8.2/H-1-3] HARUS memastikan performa baca berurutan minimal 250 MB/s.
- [8.2/H-1-4] HARUS memastikan performa pembacaan acak minimal 100 MB/s.
- [8.2/H-1-5] HARUS memastikan performa baca dan tulis berurutan paralel dengan performa baca 2x lipat dan performa tulis 1x lipat minimal 50 MB/s.
Akhiri persyaratan baru
2.3. Persyaratan Televisi
Perangkat Android Television mengacu pada implementasi perangkat Android yang merupakan antarmuka hiburan untuk mengonsumsi media digital, film, game, aplikasi, dan/atau TV live bagi pengguna yang duduk sekitar tiga meter dari perangkat (antarmuka pengguna “santai” atau “10 kaki”).
Implementasi perangkat Android diklasifikasikan sebagai Televisi jika memenuhi semua kriteria berikut:
- Telah menyediakan mekanisme untuk mengontrol antarmuka pengguna yang dirender dari jarak jauh di layar yang mungkin berada tiga meter dari pengguna.
- Memiliki layar tersemat dengan panjang diagonal lebih besar dari 24 inci ATAU menyertakan port output video, seperti VGA, HDMI, DisplayPort, atau port nirkabel untuk ditampilkan.
Persyaratan tambahan di bagian lain ini khusus untuk implementasi perangkat Android Television.
2.3.1. Hardware
Penerapan perangkat televisi:
- [7.2.2/T-0-1] HARUS mendukung D-pad.
- [7.2.3/T-0-1] HARUS menyediakan fungsi Utama dan Kembali.
- [7.2.3/T-0-2] HARUS mengirim peristiwa tekan lama dan normal
dari fungsi Kembali (
KEYCODE_BACK
) ke aplikasi latar depan. - [7.2.6.1/T-0-1] HARUS menyertakan dukungan untuk pengontrol
game dan mendeklarasikan flag fitur
android.hardware.gamepad
. - [7.2.7/T] HARUS menyediakan remote control yang dapat digunakan pengguna untuk mengakses input navigasi non-sentuh dan tombol navigasi inti.
Jika implementasi perangkat Televisi menyertakan giroskop 3 sumbu, perangkat tersebut:
- [7.3.4/T-1-1] HARUS dapat melaporkan peristiwa hingga frekuensi minimal 100 Hz.
- [7.3.4/T-1-2] HARUS dapat mengukur perubahan orientasi hingga 1.000 derajat per detik.
Penerapan perangkat televisi:
- [7.4.3/T-0-1] HARUS mendukung Bluetooth dan Bluetooth LE.
- [7.6.1/T-0-1] HARUS memiliki penyimpanan non-volatil minimal 4 GB yang tersedia untuk data pribadi aplikasi (alias partisi "/data").
Jika implementasi perangkat Televisi menyertakan port USB yang mendukung mode host, perangkat tersebut:
- [7.5.3/T-1-1] HARUS menyertakan dukungan untuk kamera eksternal yang terhubung melalui port USB ini, tetapi tidak harus selalu terhubung.
Jika implementasi perangkat TV adalah 32-bit:
[7.6.1/T-1-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 896 MB jika salah satu kepadatan berikut digunakan:
- 400 dpi atau lebih tinggi pada layar kecil/normal
- xhdpi atau lebih tinggi di layar besar
- tvdpi atau yang lebih tinggi di layar ekstra besar
Jika implementasi perangkat TV adalah 64-bit:
[7.6.1/T-2-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 1280 MB jika salah satu kepadatan berikut digunakan:
- 400 dpi atau lebih tinggi pada layar kecil/normal
- xhdpi atau lebih tinggi di layar besar
- tvdpi atau yang lebih tinggi di layar ekstra besar
Perhatikan bahwa "memori yang tersedia untuk kernel dan ruang pengguna" di atas mengacu pada ruang memori yang disediakan selain memori yang sudah didedikasikan untuk komponen hardware seperti radio, video, dan sebagainya yang tidak dikontrol kernel pada implementasi perangkat.
Penerapan perangkat televisi:
- [7.8.1/T] HARUS menyertakan mikrofon.
- [7.8.2/T-0-1] HARUS memiliki output audio dan mendeklarasikan
android.hardware.audio.output
.
2.3.2. Multimedia
Implementasi perangkat televisi HARUS mendukung format encoding dan decoding audio berikut serta menyediakannya untuk aplikasi pihak ketiga:
- [5.1/T-0-1] Profil MPEG-4 AAC (AAC LC)
- [5.1/T-0-2] MPEG-4 HE AAC Profile (AAC+)
- [5.1/T-0-3] AAC ELD (AAC yang ditingkatkan dengan delay rendah)
Implementasi perangkat televisi HARUS mendukung format encoding video berikut dan menyediakannya untuk aplikasi pihak ketiga:
Penerapan perangkat televisi:
- [5.2.2/T-SR-1] SANGAT DISARANKAN untuk mendukung encoding H.264 video resolusi 720p dan 1080p dengan kecepatan 30 frame per detik.
Implementasi perangkat televisi HARUS mendukung format decoding video berikut dan menyediakannya untuk aplikasi pihak ketiga:
- [5.3.3/T-0-1] MPEG-4 SP
- [5.3.4/T-0-2] H.264 AVC
- [5.3.5/T-0-3] H.265 HEVC
- [5.3.6/T-0-4] VP8
- [5.3.7/T-0-5] VP9
- [5.3.1/T-0-6] MPEG-2
Implementasi perangkat televisi HARUS mendukung dekode MPEG-2, seperti yang dijelaskan dalam Bagian 5.3.1, pada kecepatan frame dan resolusi video standar hingga dan termasuk:
- [5.3.1/T-1-1] HD 1080p dengan kecepatan 29,97 frame per detik dengan Main Profile High Level.
- [5.3.1/T-1-2] HD 1080i dengan kecepatan 59,94 frame per detik dengan Main Profile High Level. Aplikasi ini HARUS mendeinterlace video MPEG-2 interlaced dan menyediakannya untuk aplikasi pihak ketiga.
Implementasi perangkat televisi HARUS mendukung decoding H.264, seperti yang dijelaskan dalam Bagian 5.3.4, pada kecepatan frame dan resolusi video standar hingga dan termasuk:
- [5.3.4/T-1-1] HD 1080p pada 60 frame per detik dengan Profil Dasar Pengukuran
- [5.3.4/T-1-2] HD 1080p pada 60 frame per detik dengan Profil Utama
- [5.3.4/T-1-3] HD 1080p pada 60 frame per detik dengan High Profile Level 4.2
Penerapan perangkat televisi dengan dekoder hardware H.265 HARUS mendukung decoding H.265, seperti yang dijelaskan di Bagian 5.3.5, pada kecepatan frame dan resolusi video standar hingga dan termasuk:
- [5.3.5/T-1-1] HD 1080p pada 60 frame per detik dengan Main Profile Level 4.1
Jika implementasi perangkat Televisi dengan dekoder hardware H.265 mendukung decoding H.265 dan profil decoding UHD, perangkat tersebut:
- [5.3.5/T-2-1] HARUS mendukung profil decoding UHD dengan kecepatan 60 frame per detik dengan profil Tingkat Utama Main10 Level 5
Implementasi perangkat televisi HARUS mendukung dekode VP8, seperti yang dijelaskan dalam Bagian 5.3.6, pada kecepatan frame dan resolusi video standar hingga dan termasuk:
- [5.3.6/T-1-1] Profil decoding HD 1080p pada 60 frame per detik
Penerapan perangkat televisi dengan dekoder hardware VP9 HARUS mendukung dekode VP9, seperti yang dijelaskan di Bagian 5.3.7, pada kecepatan frame dan resolusi video standar hingga dan termasuk:
- [5.3.7/T-1-1] HD 1080p pada 60 frame per detik dengan profil 0 (kedalaman warna 8 bit)
Jika implementasi perangkat Televisi dengan dekoder hardware VP9 mendukung dekode VP9 dan profil dekode UHD, perangkat tersebut:
- [5.3.7/T-2-1] HARUS mendukung profil decoding UHD dengan kecepatan 60 frame per detik dengan profil 0 (kedalaman warna 8 bit).
- [5.3.7/T-SR1] SANGAT DIUJI untuk mendukung profil decoding UHD pada 60 frame per detik dengan profil 2 (kedalaman warna 10 bit).
Penerapan perangkat televisi:
- [5.5/T-0-1] HARUS menyertakan dukungan untuk Volume Utama sistem dan atenuasi volume output audio digital pada output yang didukung, kecuali untuk output passthrough audio terkompresi (jika tidak ada dekode audio yang dilakukan di perangkat).
Jika implementasi perangkat Televisi tidak memiliki layar bawaan, tetapi mendukung layar eksternal yang terhubung melalui HDMI, perangkat tersebut:
- [5.8/T-0-1] HARUS menetapkan mode output HDMI
ke resolusi tertinggi untuk format piksel yang dipilih yang berfungsi
dengan kecepatan refresh 50 Hz atau 60 Hz untuk layar eksternal, bergantung pada kecepatan refresh
video untuk wilayah tempat perangkat dijual.
HARUS menetapkan mode output HDMI untuk memilih resolusi maksimum yang dapat didukung dengan kecepatan refresh 50 Hz atau 60 Hz. - [5.8/T-SR-1] SANGAT DIUJAMI untuk menyediakan pemilih kecepatan refresh HDMI yang dapat dikonfigurasi pengguna.
- [5.8] HARUS menetapkan kecepatan refresh mode output HDMI ke 50 Hz atau 60 Hz, bergantung pada kecepatan refresh video untuk wilayah tempat perangkat dijual.
Jika implementasi perangkat Televisi tidak memiliki layar bawaan, tetapi mendukung layar eksternal yang terhubung melalui HDMI, perangkat tersebut:
- [5.8/T-1-1] HARUS mendukung HDCP 2.2.
Jika implementasi perangkat Televisi tidak mendukung decoding UHD, tetapi mendukung layar eksternal yang terhubung melalui HDMI, perangkat tersebut:
- [5.8/T-2-1] HARUS mendukung HDCP 1.4
2.3.3. Software
Penerapan perangkat televisi:
- [3/T-0-1] HARUS mendeklarasikan fitur
android.software.leanback
danandroid.hardware.type.television
. - [3.2.3.1/T-0-1] HARUS memuat ulang satu atau beberapa aplikasi atau komponen layanan dengan pengendali intent, untuk semua pola filter intent publik yang ditentukan oleh intent aplikasi berikut yang tercantum di sini.
- [3.4.1/T-0-1] HARUS menyediakan implementasi
android.webkit.Webview
API yang lengkap.
Jika implementasi perangkat Android Television mendukung layar kunci,perangkat tersebut:
- [3.8.10/T-1-1] HARUS menampilkan Notifikasi layar Kunci termasuk Template Notifikasi Media.
Penerapan perangkat televisi:
- [3.8.14/T-SR-1] SANGAT DISARANKAN untuk mendukung multi-aplikasi mode picture-in-picture (PIP).
- [3.10/T-0-1] HARUS mendukung layanan aksesibilitas pihak ketiga.
- [3.10/T-SR-1] SANGAT DISARANKAN untuk memuat layanan aksesibilitas di perangkat secara default yang sebanding dengan atau melebihi fungsi layanan aksesibilitas Tombol Akses dan TalkBack (untuk bahasa yang didukung oleh mesin Text-to-speech yang diinstal sebelumnya) seperti yang disediakan di project open source talkback.
Jika implementasi perangkat Televisi melaporkan fitur
android.hardware.audio.output
, perangkat tersebut:
- [3.11/T-SR-1] SANGAT DISARANKAN untuk menyertakan mesin TTS yang mendukung bahasa yang tersedia di perangkat.
- [3.11/T-1-1] HARUS mendukung penginstalan mesin TTS pihak ketiga.
Penerapan perangkat televisi:
- [3.12/T-0-1] HARUS mendukung Framework Input TV.
2.3.4. Performa dan Daya
- [8.1/T-0-1] Latensi frame yang konsisten. Latensi frame yang tidak konsisten atau penundaan untuk merender frame TIDAK BOLEH terjadi lebih dari 5 frame dalam satu detik, dan HARUS di bawah 1 frame dalam satu detik.
- [8.2/T-0-1] HARUS memastikan performa penulisan berurutan minimal 5 MB/dtk.
- [8.2/T-0-2] HARUS memastikan performa tulis acak minimal 0,5 MB/s.
- [8.2/T-0-3] HARUS memastikan performa baca berurutan minimal 15 MB/s.
- [8.2/T-0-4] HARUS memastikan performa pembacaan acak minimal 3,5 MB/s.
Jika implementasi perangkat Televisi menyertakan fitur untuk meningkatkan pengelolaan daya perangkat yang disertakan dalam AOSP atau memperluas fitur yang disertakan dalam AOSP, fitur tersebut:
- [8.3/T-1-1] HARUS memberikan kemampuan pengguna untuk mengaktifkan dan menonaktifkan fitur penghemat baterai.
Jika implementasi perangkat Televisi tidak memiliki baterai, perangkat tersebut:
- [8.3/T-1-2] HARUS mendaftarkan perangkat sebagai perangkat tanpa baterai seperti yang dijelaskan dalam Mendukung Perangkat Tanpa Baterai.
Jika implementasi perangkat Televisi memiliki baterai, perangkat tersebut:
- [8.3/T-1-3] HARUS memberikan kemampuan pengguna untuk menampilkan semua aplikasi yang dikecualikan dari mode hemat daya Aplikasi Standby dan Istirahatkan.
Penerapan perangkat televisi:
- [8.4/T-0-1] HARUS menyediakan profil daya per komponen yang menentukan nilai konsumsi saat ini untuk setiap komponen hardware dan perkiraan pemakaian baterai yang disebabkan oleh komponen dari waktu ke waktu seperti yang didokumentasikan di situs Android Open Source Project.
- [8.4/T-0-2] HARUS melaporkan semua nilai konsumsi daya dalam miliamper jam (mAh).
- [8.4/T-0-3] HARUS melaporkan konsumsi daya
CPU per UID setiap proses. Project Open Source Android memenuhi
persyaratan melalui implementasi modul kernel
uid_cputime
. - [8.4/T] HARUS diatribusikan ke komponen hardware itu sendiri jika tidak dapat mengatribusikan penggunaan daya komponen hardware ke aplikasi.
- [8.4/T-0-4] HARUS menyediakan penggunaan daya ini
melalui perintah shell
adb shell dumpsys batterystats
kepada developer aplikasi.
2.3.5. Model Keamanan
Penerapan perangkat televisi:
- [9/T-0-1] HARUS mendeklarasikan fitur
android.hardware.security.model.compatible
. - [9.11/T-0-1] HARUS mencadangkan implementasi keystore dengan lingkungan eksekusi terisolasi.
- [9.11/T-0-2] HARUS memiliki implementasi algoritma kriptografis RSA, AES, ECDSA, dan HMAC serta fungsi hash keluarga MD5, SHA1, dan SHA-2 untuk mendukung algoritma yang didukung sistem Keystore Android dengan benar di area yang terisolasi dengan aman dari kode yang berjalan di kernel dan yang lebih baru. Isolasi aman HARUS memblokir semua mekanisme potensial yang memungkinkan kode kernel atau ruang pengguna mengakses status internal lingkungan terisolasi, termasuk DMA. Project Open Source Android upstream (AOSP) memenuhi persyaratan ini dengan menggunakan implementasi Trusty, tetapi solusi berbasis ARM TrustZone lainnya atau implementasi aman yang ditinjau pihak ketiga dari isolasi berbasis hypervisor yang tepat adalah opsi alternatif.
- [9.11/T-0-3] HARUS melakukan autentikasi layar kunci di lingkungan eksekusi terisolasi dan hanya jika berhasil, izinkan kunci yang terikat autentikasi untuk digunakan. Kredensial layar kunci HARUS disimpan dengan cara yang hanya mengizinkan lingkungan eksekusi terisolasi untuk melakukan autentikasi layar kunci. Project Open Source Android upstream menyediakan Gatekeeper Hardware Abstraction Layer (HAL) dan Trusty, yang dapat digunakan untuk memenuhi persyaratan ini.
- [9.11/T-0-4] HARUS mendukung pengesahan kunci dengan kunci penandatanganan pengesahan dilindungi oleh hardware aman dan penandatanganan dilakukan di hardware aman. Kunci penandatanganan pengesahan HARUS dibagikan di sejumlah perangkat yang cukup besar untuk mencegah kunci digunakan sebagai ID perangkat. Salah satu cara untuk memenuhi persyaratan ini adalah dengan membagikan kunci pengesahan yang sama,kecuali jika setidaknya 100.000 unit SKU tertentu diproduksi. Jika lebih dari 100.000 unit SKU diproduksi, kunci yang berbeda DAPAT digunakan untuk setiap 100.000 unit.
Perhatikan bahwa jika implementasi perangkat sudah diluncurkan pada versi Android
sebelumnya, perangkat tersebut dikecualikan dari persyaratan untuk memiliki keystore
yang didukung oleh lingkungan eksekusi terisolasi dan mendukung pengesahan kunci,
kecuali jika mendeklarasikan fitur android.hardware.fingerprint
yang memerlukan
keystore yang didukung oleh lingkungan eksekusi terisolasi.
Jika implementasi perangkat Televisi mendukung layar kunci yang aman, perangkat tersebut:
- [9.11/T-1-1] HARUS mengizinkan pengguna memilih waktu tunggu Sleep untuk transisi dari status tidak terkunci ke terkunci, dengan waktu tunggu minimum yang diizinkan hingga 15 detik atau kurang.
Jika implementasi perangkat Televisi menyertakan beberapa pengguna dan
tidak mendeklarasikan flag fitur android.hardware.telephony
, implementasi tersebut:
- [9.5/T-2-1] HARUS mendukung profil yang dibatasi, fitur yang memungkinkan pemilik perangkat mengelola pengguna tambahan dan kemampuan mereka di perangkat. Dengan profil yang dibatasi, pemilik perangkat dapat dengan cepat menyiapkan lingkungan terpisah bagi pengguna tambahan untuk bekerja, dengan kemampuan untuk mengelola pembatasan yang lebih terperinci di aplikasi yang tersedia di lingkungan tersebut.
Jika implementasi perangkat Televisi menyertakan beberapa pengguna dan
mendeklarasikan flag fitur android.hardware.telephony
, implementasi tersebut:
- [9.5/T-3-1] TIDAK BOLEH mendukung profil terbatas, tetapi HARUS selaras dengan implementasi kontrol AOSP untuk mengaktifkan /menonaktifkan pengguna lain agar tidak dapat mengakses panggilan suara dan SMS.
Jika implementasi perangkat Televisi mendeklarasikan android.hardware.microphone
, implementasi tersebut:
- [9.8.2/T-4-1] HARUS menampilkan indikator mikrofon saat aplikasi mengakses data audio dari mikrofon, tetapi tidak saat mikrofon hanya diakses oleh HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService, atau aplikasi yang memiliki peran yang disebutkan dalam Izin Bagian 9.1 dengan ID CDD C-3-X].
- [9.8.2/T-4-2] TIDAK BOLEH menyembunyikan indikator mikrofon untuk aplikasi sistem yang memiliki antarmuka pengguna yang terlihat atau interaksi pengguna langsung.
Jika implementasi perangkat Televisi mendeklarasikan android.hardware.camera.any
, implementasi tersebut:
- [9.8.2/T-5-1] HARUS menampilkan indikator kamera saat aplikasi mengakses data kamera live, tetapi tidak saat kamera hanya diakses oleh aplikasi yang memiliki peran yang disebutkan dalam Izin Bagian 9.1 dengan ID CDD [C-3-X].
- [9.8.2/T-5-2] TIDAK BOLEH menyembunyikan indikator kamera untuk aplikasi sistem yang memiliki antarmuka pengguna yang terlihat atau interaksi pengguna langsung.
2.3.6. Kompatibilitas Alat dan Opsi Developer
Penerapan perangkat televisi:
- Perfetto
- [6.1/T-0-1] HARUS mengekspos biner
/system/bin/perfetto
ke pengguna shell yang cmdline-nya mematuhi dokumentasi perfetto. - [6.1/T-0-2] Biner perfetto HARUS menerima sebagai input konfigurasi protobuf yang mematuhi skema yang ditentukan dalam dokumentasi perfetto.
- [6.1/T-0-3] Biner perfetto HARUS menulis sebagai output rekaman aktivitas protobuf yang mematuhi skema yang ditentukan dalam dokumentasi perfetto.
- [6.1/T-0-4] HARUS menyediakan, melalui biner perfetto, setidaknya sumber data yang dijelaskan dalam dokumentasi perfetto.
- [6.1/T-0-1] HARUS mengekspos biner
2.4. Persyaratan Menonton
Perangkat Android Watch mengacu pada implementasi perangkat Android yang dimaksudkan untuk dipakai di tubuh, mungkin di pergelangan tangan.
Implementasi perangkat Android diklasifikasikan sebagai Smartwatch jika memenuhi semua kriteria berikut:
- Memiliki layar dengan panjang diagonal fisik dalam rentang dari 1,1 hingga 2,5 inci.
- Memiliki mekanisme yang disediakan untuk dikenakan di tubuh.
Persyaratan tambahan di bagian lain ini khusus untuk implementasi perangkat Android Watch.
2.4.1. Hardware
Tonton implementasi perangkat:
[7.1.1.1/W-0-1] HARUS memiliki layar dengan ukuran diagonal fisik dalam rentang dari 1,1 hingga 2,5 inci.
[7.2.3/W-0-1] HARUS memiliki fungsi Home yang tersedia untuk pengguna, dan fungsi Kembali kecuali saat berada di
UI_MODE_TYPE_WATCH
.[7.2.4/W-0-1] HARUS mendukung input layar sentuh.
[7.3.1/W-SR-1] SANGAT DIUJAMI untuk menyertakan akselerometer 3 sumbu.
Jika implementasi perangkat Smartwatch menyertakan penerima GPS/GNSS dan melaporkan
kemampuan ke aplikasi melalui flag
fitur android.hardware.location.gps
, perangkat tersebut:
- [7.3.3/W-1-1] HARUS melaporkan pengukuran GNSS, segera setelah ditemukan, meskipun lokasi yang dihitung dari GPS/GNSS belum dilaporkan.
- [7.3.3/W-1-2] HARUS melaporkan pseudorange dan rasio pseudorange GNSS, yang, dalam kondisi langit terbuka setelah menentukan lokasi, saat diam atau bergerak dengan percepatan kurang dari 0,2 meter per detik kuadrat, cukup untuk menghitung posisi dalam 20 meter, dan kecepatan dalam 0,2 meter per detik, setidaknya 95% dari waktu.
Jika implementasi perangkat Smartwatch menyertakan giroskop 3 sumbu, perangkat tersebut:
- [7.3.4/W-2-1] HARUS dapat mengukur perubahan orientasi hingga 1.000 derajat per detik.
Tonton implementasi perangkat:
[7.4.3/W-0-1] HARUS mendukung Bluetooth.
[7.6.1/W-0-1] HARUS memiliki setidaknya 1 GB penyimpanan non-volatil yang tersedia untuk data pribadi aplikasi (alias partisi "/data").
[7.6.1/W-0-2] HARUS memiliki minimal 416 MB memori yang tersedia untuk kernel dan ruang pengguna.
[7.8.1/W-0-1] HARUS menyertakan mikrofon.
[7.8.2/W] MUNGKIN memiliki output audio.
2.4.2. Multimedia
Tidak ada persyaratan tambahan.
2.4.3. Software
Tonton implementasi perangkat:
- [3/W-0-1] HARUS mendeklarasikan fitur
android.hardware.type.watch
. - [3/W-0-2] HARUS mendukung uiMode = UI_MODE_TYPE_WATCH.
- [3.2.3.1/W-0-1] HARUS memuat ulang satu atau beberapa aplikasi atau komponen layanan dengan pengendali intent, untuk semua pola filter intent publik yang ditentukan oleh intent aplikasi berikut yang tercantum di sini.
Tonton implementasi perangkat:
- [3.8.4/W-SR-1] SANGAT DISARANKAN untuk menerapkan asisten di perangkat guna menangani Tindakan bantuan.
Tonton implementasi perangkat yang mendeklarasikan flag fitur
android.hardware.audio.output
:
- [3.10/W-1-1] HARUS mendukung layanan aksesibilitas pihak ketiga.
- [3.10/W-SR-1] SANGAT DISARANKAN untuk memuat layanan aksesibilitas di perangkat secara default yang sebanding dengan atau melebihi fungsi layanan aksesibilitas Tombol Akses dan TalkBack (untuk bahasa yang didukung oleh mesin Text-to-speech yang diprainstal) seperti yang disediakan dalam project open source talkback.
Jika implementasi perangkat Smartwatch melaporkan fitur android.hardware.audio.output, perangkat tersebut:
[3.11/W-SR-1] SANGAT DISARANKAN untuk menyertakan mesin TTS yang mendukung bahasa yang tersedia di perangkat.
[3.11/W-0-1] HARUS mendukung penginstalan mesin TTS pihak ketiga.
2.4.4. Performa dan Daya
Jika implementasi perangkat Watch menyertakan fitur untuk meningkatkan pengelolaan daya perangkat yang disertakan dalam AOSP atau memperluas fitur yang disertakan dalam AOSP, fitur tersebut:
- [8.3/W-SR-1] SANGAT DIUJAMI untuk memberikan affordance pengguna guna menampilkan semua aplikasi yang dikecualikan dari mode hemat daya Mode Siaga Aplikasi dan Mode Tidur.
- [8.3/W-SR-2] SANGAT DIUJAMI untuk memberikan affordance pengguna guna mengaktifkan dan menonaktifkan fitur penghemat baterai.
Tonton implementasi perangkat:
- [8.4/W-0-1] HARUS menyediakan profil daya per komponen yang menentukan nilai konsumsi saat ini untuk setiap komponen hardware dan perkiraan pemakaian baterai yang disebabkan oleh komponen dari waktu ke waktu seperti yang didokumentasikan di situs Android Open Source Project.
- [8.4/W-0-2] HARUS melaporkan semua nilai konsumsi daya dalam miliamper jam (mAh).
- [8.4/W-0-3] HARUS melaporkan konsumsi daya
CPU per setiap UID proses. Project Open Source Android memenuhi
persyaratan melalui implementasi modul kernel
uid_cputime
. - [8.4/W-0-4] HARUS menyediakan penggunaan daya ini
melalui perintah shell
adb shell dumpsys batterystats
kepada developer aplikasi. - [8,4/W] HARUS diatribusikan ke komponen hardware itu sendiri jika tidak dapat mengatribusikan penggunaan daya komponen hardware ke aplikasi.
2.4.5. Model Keamanan
Tonton implementasi perangkat:
- [9/W-0-1] HARUS mendeklarasikan fitur
android.hardware.security.model.compatible
.
Jika implementasi perangkat Watch menyertakan beberapa pengguna dan
tidak mendeklarasikan flag fitur android.hardware.telephony
, implementasi tersebut:
- [9.5/W-1-1] HARUS mendukung profil yang dibatasi, fitur yang memungkinkan pemilik perangkat mengelola pengguna tambahan dan kemampuan mereka di perangkat. Dengan profil yang dibatasi, pemilik perangkat dapat dengan cepat menyiapkan lingkungan terpisah bagi pengguna tambahan untuk bekerja, dengan kemampuan untuk mengelola pembatasan yang lebih terperinci di aplikasi yang tersedia di lingkungan tersebut.
Jika implementasi perangkat Watch menyertakan beberapa pengguna dan
mendeklarasikan flag fitur android.hardware.telephony
, perangkat tersebut:
- [9.5/W-2-1] TIDAK BOLEH mendukung profil terbatas, tetapi HARUS selaras dengan implementasi kontrol AOSP untuk mengaktifkan /menonaktifkan pengguna lain agar tidak dapat mengakses panggilan suara dan SMS.
Memulai persyaratan baru
Jika implementasi perangkat memiliki layar kunci yang aman dan menyertakan satu atau beberapa agen kepercayaan, yang mengimplementasikan TrustAgentService
System API, implementasi tersebut:
- [9.11.1/W-1-1] HARUS meminta pengguna untuk menggunakan salah satu metode autentikasi utama yang direkomendasikan (misalnya: PIN, pola, sandi) lebih sering dari sekali setiap 72 jam.
Akhiri persyaratan baru
2.5. Persyaratan Otomotif
Implementasi Android Automotive mengacu pada head unit kendaraan yang menjalankan Android sebagai sistem operasi untuk sebagian atau seluruh sistem dan/atau fungsi infotainmen.
Implementasi perangkat Android diklasifikasikan sebagai Otomotif jika mendeklarasikan
fitur android.hardware.type.automotive
atau memenuhi semua kriteria
berikut.
- Disematkan sebagai bagian dari, atau dapat dicolokkan ke, kendaraan otomotif.
- Menggunakan layar di baris kursi pengemudi sebagai layar utama.
Persyaratan tambahan di bagian lain ini khusus untuk implementasi perangkat Android Automotive.
2.5.1. Hardware
Implementasi perangkat otomotif:
- [7.1.1.1/A-0-1] HARUS memiliki layar dengan ukuran diagonal fisik setidaknya 6 inci.
- [7.1.1.1/A-0-2] HARUS memiliki tata letak ukuran layar setidaknya 750 dp x 480 dp.
- [7.2.3/A-0-1] HARUS menyediakan fungsi Beranda dan DAPAT menyediakan fungsi Kembali dan Terbaru.
- [7.2.3/A-0-2] HARUS mengirim peristiwa tekan lama dan normal
dari fungsi Kembali (
KEYCODE_BACK
) ke aplikasi latar depan. - [7.3/A-0-1] HARUS menerapkan dan melaporkan
GEAR_SELECTION
,NIGHT_MODE
,PERF_VEHICLE_SPEED
danPARKING_BRAKE_ON
. - [7.3/A-0-2] Nilai flag
NIGHT_MODE
HARUS konsisten dengan mode siang/malam dasbor dan HARUS didasarkan pada input sensor cahaya sekitar. Sensor cahaya sekitar yang mendasarinya DAPAT sama dengan Photometer. - [7.3/A-0-3] HARUS menyediakan kolom info tambahan sensor
TYPE_SENSOR_PLACEMENT
sebagai bagian dari SensorAdditionalInfo untuk setiap sensor yang disediakan. - [7.3/A-SR1] DAPAT melakukan dead reckoning Lokasi dengan menggabungkan GPS/GNSS dengan sensor tambahan. Jika Lokasi dihitung secara dead reckoning, SANGAT DISARANKAN untuk menerapkan dan melaporkan jenis Sensor dan/atau ID Properti Kendaraan yang sesuai yang digunakan.
[7.3/A-0-4] Location yang diminta melalui LocationManager#requestLocationUpdates() TIDAK BOLEH cocok dengan peta.
[7.3.1/A-0-4] HARUS mematuhi sistem koordinat sensor mobil Android.
[7.3/A-SR-1] SANGAT_DISARANKAN untuk menyertakan akselerometer 3 sumbu dan giroskop 3 sumbu.
[7.3/A-SR-2] SANGAT_DISARANKAN untuk menerapkan dan melaporkan sensor
TYPE_HEADING
.
Jika implementasi perangkat Otomotif mendukung OpenGL ES 3.1, implementasi tersebut:
- [7.1.4.1/A-0-1] HARUS mendeklarasikan OpenGL ES 3.1 atau yang lebih tinggi.
- [7.1.4.1/A-0-2] HARUS mendukung Vulkan 1.1.
- [7.1.4.1/A-0-3] HARUS menyertakan loader Vulkan dan mengekspor semua simbol.
Jika implementasi perangkat Otomotif menyertakan akselerometer, perangkat tersebut:
- [7.3.1/A-1-1] HARUS dapat melaporkan peristiwa hingga frekuensi setidaknya 100 Hz.
Jika implementasi perangkat menyertakan akselerometer 3 sumbu, perangkat tersebut:
- [7.3.1/A-SR-1] SANGAT DISARANKAN untuk menerapkan sensor komposit untuk akselerometer sumbu terbatas.
Jika implementasi perangkat Otomotif menyertakan akselerometer dengan kurang dari 3 sumbu, akselerometer tersebut:
- [7.3.1/A-1-3] HARUS menerapkan dan melaporkan
sensor
TYPE_ACCELEROMETER_LIMITED_AXES
. - [7.3.1/A-1-4] HARUS menerapkan dan melaporkan
sensor
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
.
Jika implementasi perangkat Otomotif menyertakan giroskop, perangkat tersebut:
- [7.3.4/A-2-1] HARUS dapat melaporkan peristiwa hingga frekuensi setidaknya 100 Hz.
- [7.3.4/A-2-3] HARUS dapat mengukur perubahan orientasi hingga 250 derajat per detik.
- [7.3.4/A-SR-1] SANGAT DIUJAMI untuk mengonfigurasi rentang pengukuran giroskop ke +/-250dps guna memaksimalkan resolusi yang memungkinkan.
Jika implementasi perangkat Otomotif menyertakan giroskop 3 sumbu, perangkat tersebut:
- [7.3.4/A-SR-2] SANGAT DISARANKAN untuk menerapkan sensor komposit untuk giroskop sumbu terbatas.
Jika implementasi perangkat Otomotif menyertakan giroskop dengan kurang dari 3 sumbu, perangkat tersebut:
- [7.3.4/A-4-1] HARUS menerapkan dan melaporkan
sensor
TYPE_GYROSCOPE_LIMITED_AXES
. - [7.3.4/A-4-2] HARUS menerapkan dan melaporkan
sensor
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
.
Jika implementasi perangkat Automotive menyertakan penerima GPS/GNSS, tetapi tidak menyertakan konektivitas data berbasis jaringan seluler, perangkat tersebut:
- [7.3.3/A-3-1] HARUS menentukan lokasi saat pertama kali penerima GPS/GNSS diaktifkan atau setelah 4 hari atau lebih dalam waktu 60 detik.
- [7.3.3/A-3-2] HARUS memenuhi kriteria waktu hingga perbaikan pertama seperti dijelaskan dalam 7.3.3/C-1-2 dan 7.3.3/C-1-6 untuk semua permintaan lokasi lainnya (yaitu permintaan yang bukan pertama kali atau setelah 4 hari). Persyaratan 7.3.3/C-1-2 biasanya dipenuhi di kendaraan tanpa konektivitas data berbasis jaringan seluler, dengan menggunakan prediksi orbit GNSS yang dihitung di penerima, atau menggunakan lokasi kendaraan terakhir yang diketahui beserta kemampuan untuk melakukan dead reckoning setidaknya selama 60 detik dengan akurasi posisi yang memenuhi 7.3.3/C-1-3, atau kombinasi keduanya.
Jika implementasi perangkat otomotif menyertakan sensor TYPE_HEADING
, perangkat tersebut:
- [7.3.4/A-4-3] HARUS dapat melaporkan peristiwa hingga frekuensi setidaknya 1 Hz.
- [7.3.4/A-SR-3] SANGAT_DIREKOMENDASIKAN untuk melaporkan peristiwa hingga frekuensi minimal 10 Hz.
- HARUS mengacu pada utara sejati.
- HARUS tersedia meskipun kendaraan diam.
- HARUS memiliki resolusi minimal 1 derajat.
Implementasi perangkat otomotif:
- [7.4.3/A-0-1] HARUS mendukung Bluetooth dan HARUS mendukung Bluetooth LE.
- [7.4.3/A-0-2] Implementasi Android Automotive
HARUS mendukung profil Bluetooth berikut:
- Panggilan telepon melalui Profil Handsfree (HFP).
- Pemutaran media melalui Audio Distribution Profile (A2DP).
- Kontrol pemutaran media melalui Profil Remote Control (AVRCP).
- Berbagi kontak menggunakan Profil Akses Buku Telepon (PBAP).
[7.4.3/A-SR-1] SANGAT DISARANKAN untuk mendukung Message Access Profile (MAP).
[7.4.5/A] HARUS menyertakan dukungan untuk konektivitas data berbasis jaringan seluler.
[7.4.5/A] DAPAT menggunakan konstanta
NetworkCapabilities#NET_CAPABILITY_OEM_PAID
System API untuk jaringan yang harus tersedia untuk aplikasi sistem.
Memulai persyaratan baru
Jika implementasi perangkat menyertakan dukungan untuk radio siaran AM/FM dan mengekspos fungsi ke aplikasi apa pun, implementasi tersebut:
- [7.4
.10/A-0-1] HARUS mendeklarasikan dukungan untukFEATURE_BROADCAST_RADIO
.
Akhiri persyaratan baru
Kamera tampilan eksterior adalah kamera yang mengambil gambar pemandangan di luar penerapan perangkat, seperti kamera belakang.
Implementasi perangkat otomotif:
- HARUS menyertakan satu atau beberapa kamera tampilan luar.
Jika implementasi perangkat Otomotif menyertakan kamera tampilan luar, untuk kamera tersebut, kamera tersebut:
- [7.5/A-1-1] TIDAK BOLEH memiliki kamera tampilan eksterior yang dapat diakses melalui Android Camera API, kecuali jika 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 DISARANKAN untuk memiliki resolusi minimal 1,3 megapiksel.
HARUS memiliki hardware fokus tetap atau EDOF (extended depth of field).
DAPAT memiliki fokus otomatis hardware atau fokus otomatis software yang diterapkan di driver kamera.
Jika implementasi perangkat otomotif menyertakan satu atau beberapa kamera tampilan luar, dan memuat layanan Sistem Tampilan Luar (EVS), maka untuk kamera tersebut, kamera tersebut:
- [7.5/A-2-1] TIDAK BOLEH memutar atau mencerminkan pratinjau kamera secara horizontal.
Implementasi perangkat otomotif:
- DAPAT menyertakan satu atau beberapa kamera yang tersedia untuk aplikasi pihak ketiga.
Jika implementasi perangkat otomotif menyertakan setidaknya satu kamera dan membuatnya tersedia untuk aplikasi pihak ketiga, maka:
- [7.5/A-3-1] HARUS melaporkan flag fitur
android.hardware.camera.any
. - [7.5/A-3-2] TIDAK BOLEH mendeklarasikan kamera sebagai kamera sistem.
- DAPAT mendukung kamera eksternal yang dijelaskan di bagian 7.5.3.
- DAPAT menyertakan fitur (seperti fokus otomatis, dll.) yang tersedia untuk kamera menghadap belakang seperti yang dijelaskan dalam bagian 7.5.1.
Memulai persyaratan baru
Kamera belakang berarti kamera yang menghadap ke dunia yang dapat ditempatkan di mana saja di kendaraan dan menghadap ke luar kabin kendaraan; yaitu, kamera mengambil gambar di sisi jauh bodi kendaraan, seperti kamera belakang.
Kamera depan berarti kamera yang menghadap pengguna yang dapat ditempatkan di mana saja di kendaraan dan menghadap ke dalam kabin kendaraan; yaitu mengambil gambar pengguna, seperti untuk konferensi video dan aplikasi serupa.
Implementasi perangkat otomotif:
- [7.5/A-SR-1] SANGAT DIUJAMI untuk menyertakan satu atau beberapa kamera menghadap dunia.
- DAPAT menyertakan satu atau beberapa kamera yang menghadap pengguna.
- [7.5/A-SR-2] SANGAT DIUTAMAKAN untuk mendukung streaming serentak beberapa kamera.
Jika implementasi perangkat Otomotif menyertakan minimal satu kamera yang menghadap dunia, maka untuk kamera tersebut, kamera tersebut:
- [7.5/A-1-1] HARUS diorientasikan sehingga dimensi panjang kamera sejajar dengan bidang X-Y sumbu sensor otomotif Android.
- [7.5/A-SR-3] SANGAT DIUTAMAKAN untuk memiliki hardware fokus tetap atau EDOF (Extended Depth of Field).
- [7.5/A-1-2] HARUS memiliki kamera belakang (menghadap dunia) utama sebagai kamera belakang (menghadap dunia) dengan ID kamera terendah.
Jika implementasi perangkat Otomotif menyertakan setidaknya satu kamera yang dilihat pengguna, untuk kamera tersebut:
- [7.5/A-2-1] Kamera utama yang menghadap pengguna HARUS berupa kamera yang menghadap pengguna dengan ID kamera terendah.
- DAPAT diorientasikan sehingga dimensi panjang kamera sejajar dengan bidang X-Y sumbu sensor otomotif Android.
Jika implementasi perangkat Otomotif menyertakan kamera yang dapat diakses melalui
android.hardware.Camera
atau android.hardware.camera2
API, maka:
- [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 API android.hardware.Camera
atau android.hardware.camera2
, maka
kamera tersebut:
- [7.5/A-4-1] HARUS dapat diakses melalui layanan Extended View System.
Jika implementasi perangkat Otomotif menyertakan satu atau beberapa kamera yang dapat diakses melalui Layanan Sistem Tampilan yang Diperluas, untuk kamera tersebut, kamera tersebut:
- [7.5/A-5-1] TIDAK BOLEH memutar atau mencerminkan pratinjau kamera secara horizontal.
- [7.5/A-SR-4] SANGAT DIUJAMI untuk memiliki resolusi minimal 1,3 megapiksel.
Jika implementasi perangkat otomotif menyertakan satu atau beberapa kamera yang
dapat diakses melalui Extended View System Service dan android.hardware.Camera
atau android.hardware.Camera2
API, maka untuk kamera tersebut, kamera tersebut:
- [7.5/A-6-1] HARUS melaporkan ID Kamera yang sama.
Jika implementasi perangkat Otomotif menyediakan API kamera eksklusif, API tersebut:
- [7.5/A-7-1] HARUS menerapkan API kamera tersebut menggunakan
android.hardware.camera2
API atau Extended View System API.
Akhiri persyaratan baru
Implementasi perangkat otomotif:
[7.6.1/A-0-1] HARUS memiliki penyimpanan non-volatil minimal 4 GB yang tersedia untuk data pribadi aplikasi (alias partisi "/data").
[7.6.1/A] HARUS memformat partisi data untuk menawarkan performa dan masa pakai yang lebih baik pada penyimpanan flash, misalnya menggunakan sistem file
f2fs
.
Jika implementasi perangkat Otomotif menyediakan penyimpanan eksternal bersama melalui sebagian penyimpanan internal yang tidak dapat dilepas, implementasi tersebut:
- [7.6.1/A-SR-1] SANGAT DIUJAMI untuk mengurangi
overhead I/O pada operasi yang dilakukan di penyimpanan eksternal, misalnya dengan
menggunakan
SDCardFS
.
Jika implementasi perangkat Otomotif adalah 64-bit:
[7.6.1/A-2-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 816 MB jika salah satu kepadatan berikut digunakan:
- 280 dpi atau lebih rendah pada layar kecil/normal
- ldpi atau lebih rendah di layar ekstra besar
- mdpi atau lebih rendah di perangkat layar besar
[7.6.1/A-2-2] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 944 MB jika salah satu kepadatan berikut digunakan:
- xhdpi atau lebih tinggi pada layar kecil/normal
- hdpi atau lebih tinggi di perangkat layar besar
- mdpi atau lebih tinggi di perangkat layar ekstra besar
[7.6.1/A-2-3] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 1280 MB jika salah satu kepadatan berikut digunakan:
- 400 dpi atau lebih tinggi pada layar kecil/normal
- xhdpi atau lebih tinggi di layar besar
- tvdpi atau yang lebih tinggi di layar ekstra besar
[7.6.1/A-2-4] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 1824 MB jika salah satu kepadatan berikut digunakan:
- 560 dpi atau lebih tinggi pada layar kecil/normal
- 400 dpi atau lebih tinggi di perangkat layar besar
- xhdpi atau yang lebih tinggi di layar ekstra besar
Perhatikan bahwa "memori yang tersedia untuk kernel dan ruang pengguna" di atas mengacu pada ruang memori yang disediakan selain memori yang sudah dikhususkan untuk komponen hardware seperti radio, video, dan sebagainya yang tidak berada di bawah kontrol kernel pada implementasi perangkat.
Implementasi perangkat otomotif:
- [7.7.1/A] HARUS menyertakan port USB yang mendukung mode periferal.
Implementasi perangkat otomotif:
- [7.8.1/A-0-1] HARUS menyertakan mikrofon.
Implementasi perangkat otomotif:
- [7.8.2/A-0-1] HARUS memiliki output audio dan mendeklarasikan
android.hardware.audio.output
.
2.5.2. Multimedia
Implementasi perangkat otomotif HARUS mendukung format encoding dan decoding audio berikut serta menyediakannya untuk aplikasi pihak ketiga:
- [5.1/A-0-1] Profil AAC MPEG-4 (AAC LC)
- [5.1/A-0-2] Profil MPEG-4 HE AAC (AAC+)
- [5.1/A-0-3] AAC ELD (AAC yang ditingkatkan dengan delay rendah)
Implementasi perangkat otomotif HARUS mendukung format encoding video berikut dan menyediakannya untuk aplikasi pihak ketiga:
Implementasi perangkat otomotif HARUS mendukung format decoding video berikut dan menyediakannya untuk aplikasi pihak ketiga:
Implementasi perangkat otomotif SANGAT DIUJI untuk mendukung dekode video berikut:
- [5.3/A-SR-1] H.265 HEVC
2.5.3. Software
Implementasi perangkat otomotif:
[3/A-0-1] HARUS mendeklarasikan fitur
android.hardware.type.automotive
.[3/A-0-2] HARUS mendukung uiMode =
UI_MODE_TYPE_CAR
.[3/A-0-3] HARUS mendukung semua API publik di namespace
android.car.*
.
Jika implementasi perangkat Automotive menyediakan API eksklusif menggunakan
android.car.CarPropertyManager
dengan
android.car.VehiclePropertyIds
,
implementasi tersebut:
- [3/A-1-1] TIDAK BOLEH melampirkan hak istimewa khusus ke penggunaan properti ini oleh aplikasi sistem, atau mencegah aplikasi pihak ketiga menggunakan properti ini.
- [3/A-1-2] TIDAK BOLEH mereplikasi properti kendaraan yang sudah ada di SDK.
Implementasi perangkat otomotif:
[3.2.1/A-0-1] HARUS mendukung dan menerapkan semua konstanta izin seperti yang didokumentasikan oleh halaman referensi Izin Otomotif.
[3.2.3.1/A-0-1] HARUS memuat ulang satu atau beberapa aplikasi atau komponen layanan dengan pengendali intent, untuk semua pola filter intent publik yang ditentukan oleh intent aplikasi berikut yang tercantum di sini.
[3.4.1/A-0-1] HARUS menyediakan implementasi
android.webkit.Webview
API yang lengkap.
Memulai persyaratan baru
- [3.8/A-0-1] TIDAK BOLEH mengizinkan pengguna sekunder penuh yang bukan pengguna latar depan saat ini untuk meluncurkan aktivitas dan memiliki akses ke UI di layar apa pun.
Akhiri persyaratan baru
[3.8.3/A-0-1] HARUS menampilkan notifikasi yang menggunakan
Notification.CarExtender
API saat diminta oleh aplikasi pihak ketiga.[3.8.4/A-SR-1] Sangat Direkomendasikan untuk menerapkan asisten di perangkat guna menangani tindakan Bantuan.
Jika implementasi perangkat Otomotif menyertakan tombol tekan untuk bicara, tombol tersebut:
- [3.8.4/A-1-1] HARUS menggunakan penekanan singkat
tombol push-to-talk sebagai interaksi yang ditetapkan untuk meluncurkan
aplikasi bantuan yang dipilih pengguna, dengan kata lain aplikasi yang menerapkan
VoiceInteractionService
.
Implementasi perangkat otomotif:
- [3.8.3.1/A-0-1] HARUS merender resource
dengan benar seperti yang dijelaskan dalam dokumentasi SDK
Notifications on Automotive OS
. - [3.8.3.1/A-0-2] HARUS menampilkan
Putar dan Bisukan untuk tindakan notifikasi sebagai pengganti tindakan yang disediakan melalui
Notification.Builder.addAction()
- [3.8.3.1/A] HARUS membatasi penggunaan tugas pengelolaan yang kaya seperti kontrol per saluran notifikasi. DAPAT menggunakan kemampuan UI per aplikasi untuk mengurangi kontrol.
Jika implementasi perangkat Otomotif mendukung properti HAL Pengguna, implementasi tersebut:
- [3.9.3/A-1-1] HARUS mengimplementasikan semua
Properti siklus proses pengguna
INITIAL_USER_INFO
,SWITCH_USER
,CREATE_USER
,REMOVE_USER
.
Implementasi perangkat otomotif:
- [3.14/A-0-1] HARUS menyertakan framework UI untuk mendukung aplikasi pihak ketiga yang menggunakan API media seperti yang dijelaskan di bagian 3.14.
- [3.14/A-0-2] HARUS memungkinkan pengguna berinteraksi dengan Aplikasi Media secara aman saat mengemudi.
- [3.14/A-0-3] HARUS mendukung
tindakan Intent implisit
CAR_INTENT_ACTION_MEDIA_TEMPLATE
dengan tambahanCAR_EXTRA_MEDIA_PACKAGE
. - [3.14/A-0-4] HARUS menyediakan kemampuan untuk membuka aktivitas preferensi Aplikasi Media, tetapi HARUS hanya mengaktifkannya jika Pembatasan UX Mobil tidak berlaku.
- [3.14/A-0-5] HARUS menampilkan
pesan error
yang ditetapkan oleh Aplikasi Media, dan HARUS mendukung tambahan opsional
ERROR_RESOLUTION_ACTION_LABEL
danERROR_RESOLUTION_ACTION_INTENT
. - [3.14/A-0-6] HARUS mendukung kemampuan penelusuran dalam aplikasi untuk aplikasi yang mendukung penelusuran.
- [3.14/A-0-7] HARUS mematuhi
definisi
CONTENT_STYLE_BROWSABLE_HINT
danCONTENT_STYLE_PLAYABLE_HINT
saat menampilkan hierarki MediaBrowser.
Jika implementasi perangkat Otomotif menyertakan aplikasi peluncur default, aplikasi tersebut:
- [3.14/A-1-1] HARUS menyertakan layanan media dan membukanya
dengan intent
CAR_INTENT_ACTION_MEDIA_TEMPLATE
.
Implementasi perangkat otomotif:
- [3.8/A] DAPAT membatasi permintaan
aplikasi untuk memasuki mode layar penuh seperti yang dijelaskan dalam
immersive documentation
. - [3.8/A] DAPAT membuat status bar dan menu navigasi tetap terlihat setiap saat.
- [3.8/A] DAPAT membatasi permintaan aplikasi untuk mengubah warna di balik elemen UI sistem, untuk memastikan elemen tersebut terlihat jelas setiap saat.
2.5.4. Performa dan Daya
Implementasi perangkat otomotif:
- [8.2/A-0-1] HARUS melaporkan jumlah
byte yang dibaca dan ditulis ke penyimpanan non-volatil per setiap UID proses sehingga
statistik tersedia untuk developer melalui System API
android.car.storagemonitoring.CarStorageMonitoringManager
. Project Open Source Android memenuhi persyaratan melalui modul kerneluid_sys_stats
. - [8.3/A-1-3] HARUS mendukung Mode Garasi.
- [8.3/A] HARUS dalam Mode Garasi setidaknya
15 menit setelah setiap perjalanan, kecuali jika:
- Baterai habis.
- Tidak ada tugas yang tidak ada aktivitas yang dijadwalkan.
- Pengemudi keluar dari Mode Garasi.
- [8.4/A-0-1] HARUS menyediakan profil daya per komponen yang menentukan nilai konsumsi saat ini untuk setiap komponen hardware dan perkiraan pemakaian baterai yang disebabkan oleh komponen dari waktu ke waktu seperti yang didokumentasikan di situs Android Open Source Project.
- [8.4/A-0-2] HARUS melaporkan semua nilai konsumsi daya dalam miliamper jam (mAh).
- [8.4/A-0-3] HARUS melaporkan konsumsi daya
CPU per setiap UID proses. Project Open Source Android memenuhi
persyaratan melalui implementasi modul kernel
uid_cputime
. - [8.4/A] HARUS diatribusikan ke komponen hardware itu sendiri jika tidak dapat mengatribusikan penggunaan daya komponen hardware ke aplikasi.
- [8.4/A-0-4] HARUS menyediakan penggunaan daya ini
melalui perintah shell
adb shell dumpsys batterystats
kepada developer aplikasi.
2.5.5. Model Keamanan
Jika implementasi perangkat Otomotif mendukung beberapa pengguna, implementasi tersebut:
- [9.5/A-1-1] TIDAK BOLEH mengizinkan pengguna berinteraksi dengan atau beralih ke Pengguna Sistem Headless, kecuali untuk penyediaan perangkat.
- [9.5/A-1-2] HARUS beralih ke Pengguna Sekunder
sebelum
BOOT_COMPLETED
. - [9.5/A-1-3] HARUS mendukung kemampuan untuk membuat Pengguna Tamu meskipun jumlah maksimum Pengguna di perangkat telah tercapai.
Memulai persyaratan baru
Jika implementasi perangkat Otomotif mendeklarasikan android.hardware.microphone
,
perangkat tersebut:
- [9.8.2/A-1-1] HARUS menampilkan indikator mikrofon saat
aplikasi mengakses data audio dari mikrofon, tetapi tidak saat
mikrofon hanya diakses oleh
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
, atau aplikasi yang memiliki peran yang disebutkan dalam bagian 9.1 dengan ID CDD [C-4-X]. - [9.8.2/A-1-2] TIDAK BOLEH menyembunyikan indikator mikrofon untuk aplikasi sistem yang memiliki antarmuka pengguna yang terlihat atau interaksi pengguna langsung.
- [9.8.2/A-1-3] HARUS memberikan kemampuan pengguna untuk mengaktifkan mikrofon di aplikasi Setelan.
Akhiri persyaratan baru
Jika implementasi perangkat Otomotif mendeklarasikan android.hardware.camera.any
, maka
perangkat tersebut:
- [9.8.2/A-2-1] HARUS menampilkan indikator kamera saat
aplikasi mengakses data kamera live, tetapi tidak saat kamera hanya
diakses oleh aplikasi yang memiliki peran seperti yang ditentukan
disebutdalam Bagian 9.1 Izin dengan ID CDD [C-4-X][C-3-X]. - [9.8.2/A-2-2] TIDAK BOLEH menyembunyikan indikator kamera untuk aplikasi sistem yang memiliki antarmuka pengguna yang terlihat atau interaksi pengguna langsung.
Memulai persyaratan baru
- [9.8.2/A-2-3] HARUS memberikan kemampuan pengguna untuk mengaktifkan/menonaktifkan kamera di aplikasi Setelan.
- [9.8.2/A-2-4] HARUS menampilkan aplikasi Terbaru dan Aktif menggunakan kamera seperti yang ditampilkan
dari
PermissionManager.getIndicatorAppOpUsageData()
, beserta pesan atribusi yang terkait dengannya.
Akhiri persyaratan baru
Implementasi perangkat otomotif:
- [9/A-0-1] HARUS mendeklarasikan fitur
android.hardware.security.model.compatible
. - [9.11/A-0-1] HARUS mencadangkan implementasi keystore dengan lingkungan eksekusi terisolasi.
- [9.11/A-0-2] HARUS memiliki implementasi algoritma kriptografis RSA, AES, ECDSA, dan HMAC serta fungsi hash keluarga MD5, SHA1, dan SHA-2 untuk mendukung algoritma yang didukung sistem Keystore Android dengan benar di area yang terisolasi dengan aman dari kode yang berjalan di kernel dan yang lebih baru. Isolasi aman HARUS memblokir semua mekanisme potensial yang memungkinkan kode kernel atau ruang pengguna mengakses status internal lingkungan terisolasi, termasuk DMA. Project Open Source Android upstream (AOSP) memenuhi persyaratan ini dengan menggunakan implementasi Trusty, tetapi solusi berbasis ARM TrustZone lainnya atau implementasi aman yang ditinjau pihak ketiga dari isolasi berbasis hypervisor yang tepat adalah opsi alternatif.
- [9.11/A-0-3] HARUS melakukan autentikasi layar kunci di lingkungan eksekusi terisolasi dan hanya jika berhasil, izinkan kunci yang terikat autentikasi untuk digunakan. Kredensial layar kunci HARUS disimpan dengan cara yang hanya mengizinkan lingkungan eksekusi terisolasi untuk melakukan autentikasi layar kunci. Project Open Source Android upstream menyediakan Gatekeeper Hardware Abstraction Layer (HAL) dan Trusty, yang dapat digunakan untuk memenuhi persyaratan ini.
- [9.11/A-0-4] HARUS mendukung pengesahan kunci dengan kunci penandatanganan pengesahan dilindungi oleh hardware aman dan penandatanganan dilakukan di hardware aman. Kunci penandatanganan pengesahan HARUS dibagikan di sejumlah perangkat yang cukup besar untuk mencegah kunci digunakan sebagai ID perangkat. Salah satu cara untuk memenuhi persyaratan ini adalah dengan membagikan kunci pengesahan yang sama,kecuali jika setidaknya 100.000 unit SKU tertentu diproduksi. Jika lebih dari 100.000 unit SKU diproduksi, kunci yang berbeda DAPAT digunakan untuk setiap 100.000 unit.
Perhatikan bahwa jika implementasi perangkat sudah diluncurkan pada versi Android
sebelumnya, perangkat tersebut dikecualikan dari persyaratan untuk memiliki keystore
yang didukung oleh lingkungan eksekusi terisolasi dan mendukung pengesahan kunci,
kecuali jika mendeklarasikan fitur android.hardware.fingerprint
yang memerlukan
keystore yang didukung oleh lingkungan eksekusi terisolasi.
Implementasi perangkat otomotif:
- [9.14/A-0-1] HARUS melakukan gatekeep pesan dari subsistem kendaraan framework Android, misalnya, mengizinkan jenis pesan dan sumber pesan yang diizinkan.
- [9.14/A-0-2] HARUS memantau terhadap serangan denial of service dari framework Android atau aplikasi pihak ketiga. Hal ini melindungi dari software berbahaya yang membanjiri jaringan kendaraan dengan traffic, yang dapat menyebabkan subsistem kendaraan tidak berfungsi.
2.5.6. Kompatibilitas Alat dan Opsi Developer
Implementasi perangkat otomotif:
- Perfetto
- [6.1/A-0-1] HARUS mengekspos biner
/system/bin/perfetto
ke pengguna shell yang cmdline-nya mematuhi dokumentasi perfetto. - [6.1/A-0-2] Biner perfetto HARUS menerima sebagai input konfigurasi protobuf yang mematuhi skema yang ditentukan dalam dokumentasi perfetto.
- [6.1/A-0-3] Biner perfetto HARUS menulis sebagai output rekaman aktivitas protobuf yang mematuhi skema yang ditentukan dalam dokumentasi perfetto.
- [6.1/A-0-4] HARUS menyediakan, melalui biner perfetto, setidaknya sumber data yang dijelaskan dalam dokumentasi perfetto.
- [6.1/A-0-1] HARUS mengekspos biner
2.6. Persyaratan Tablet
Perangkat Tablet Android mengacu pada implementasi perangkat Android yang biasanya memenuhi semua kriteria berikut:
- Digunakan dengan memegang kedua tangan.
- Tidak memiliki konfigurasi clamshell atau konvertibel.
- Implementasi keyboard fisik yang digunakan dengan perangkat terhubung melalui koneksi standar (misalnya, USB, Bluetooth).
Memiliki sumber daya yang memberikan mobilitas, seperti baterai.
Memiliki ukuran tampilan layar lebih besar dari 7 inci dan kurang dari 18 inci, diukur secara diagonal.
Implementasi perangkat tablet memiliki persyaratan yang serupa dengan implementasi perangkat genggam. Pengecualian ditunjukkan dengan * di bagian tersebut dan dicatat untuk referensi di bagian ini.
2.6.1. Hardware
Giroskop
Jika implementasi perangkat Tablet menyertakan giroskop 3 sumbu, perangkat tersebut:
- [7.3.4/Tab-1-1] HARUS dapat mengukur perubahan orientasi hingga 1.000 derajat per detik.
Memori dan Penyimpanan Minimum (Pasal 7.6.1)
Kepadatan layar yang tercantum untuk layar kecil/normal dalam persyaratan perangkat genggam tidak berlaku untuk tablet.
Mode periferal USB (Bagian 7.7.1)
Jika implementasi perangkat tablet menyertakan port USB yang mendukung mode periferal, port tersebut:
- [7.7.1/Tab] DAPAT mengimplementasikan Android Open Accessory (AOA) API.
Mode Virtual Reality (Pasal 7.9.1)
Performa Tinggi Virtual Reality (Pasal 7.9.2)
Persyaratan virtual reality tidak berlaku untuk tablet.
2.6.2. Model Keamanan
Kunci dan Kredensial (Bagian 9.11)
Lihat Bagian [9.11].
Jika implementasi perangkat Tablet menyertakan beberapa pengguna dan
tidak mendeklarasikan flag fitur android.hardware.telephony
, implementasi tersebut:
- [9.5/T-1-1] HARUS mendukung profil yang dibatasi, fitur yang memungkinkan pemilik perangkat mengelola pengguna tambahan dan kemampuan mereka di perangkat. Dengan profil yang dibatasi, pemilik perangkat dapat dengan cepat menyiapkan lingkungan terpisah bagi pengguna tambahan untuk bekerja, dengan kemampuan untuk mengelola pembatasan yang lebih terperinci di aplikasi yang tersedia di lingkungan tersebut.
Jika implementasi perangkat Tablet menyertakan beberapa pengguna dan
mendeklarasikan flag fitur android.hardware.telephony
, perangkat tersebut:
- [9.5/T-2-1] TIDAK BOLEH mendukung profil terbatas, tetapi HARUS selaras dengan implementasi kontrol AOSP untuk mengaktifkan /menonaktifkan pengguna lain agar tidak mengakses panggilan suara dan SMS.
2.6.2. Software
- [3.2.3.1/Tab-0-1] HARUS memuat ulang satu atau beberapa aplikasi atau komponen layanan dengan pengendali intent, untuk semua pola filter intent publik yang ditentukan oleh intent aplikasi berikut yang tercantum di sini.
3. Software
3.1. Kompatibilitas API Terkelola
Lingkungan eksekusi bytecode Dalvik terkelola adalah kendaraan utama untuk aplikasi Android. Application programming interface (API) Android adalah kumpulan antarmuka platform Android yang diekspos ke aplikasi yang berjalan di lingkungan runtime terkelola.
Implementasi perangkat:
[C-0-1] HARUS menyediakan implementasi lengkap, termasuk semua perilaku yang didokumentasikan, dari API yang didokumentasikan yang diekspos oleh Android SDK atau API apa pun yang dihiasi dengan penanda “@SystemApi” dalam kode sumber Android upstream.
[C-0-2] HARUS mendukung/mempertahankan semua class, metode, dan elemen terkait yang ditandai dengan anotasi TestApi (@TestApi).
[C-0-3] TIDAK BOLEH menghilangkan API terkelola, mengubah antarmuka atau tanda tangan API, menyimpang dari perilaku yang terdokumentasi, atau menyertakan no-ops, kecuali jika secara khusus diizinkan oleh Definisi Kompatibilitas ini.
[C-0-4] HARUS tetap mempertahankan API dan berperilaku dengan cara yang wajar, meskipun beberapa fitur hardware yang menyertakan API dihilangkan oleh Android. Lihat bagian 7 untuk mengetahui persyaratan spesifik untuk skenario ini.
[C-0-5] TIDAK BOLEH mengizinkan aplikasi pihak ketiga menggunakan antarmuka non-SDK, yang ditentukan sebagai metode dan kolom dalam paket bahasa Java yang ada di classpath booting di AOSP, dan yang tidak membentuk bagian dari SDK publik. Hal ini mencakup API yang dihiasi dengan anotasi
@hide
, tetapi tidak dengan@SystemAPI
, seperti yang dijelaskan dalam dokumen SDK dan anggota class pribadi dan pribadi paket.[C-0-6] HARUS dikirimkan dengan setiap antarmuka non-SDK di daftar yang dibatasi yang sama seperti yang disediakan melalui tanda sementara dan daftar yang ditolak di jalur
prebuilts/runtime/appcompat/hiddenapi-flags.csv
untuk cabang API level yang sesuai di AOSP.[C-0-7] HARUS mendukung mekanisme update dinamis konfigurasi yang ditandatangani untuk menghapus antarmuka non-SDK dari daftar yang dibatasi dengan menyematkan konfigurasi yang ditandatangani di APK apa pun, menggunakan kunci publik yang ada di AOSP.
Namun, mereka:
- DAPAT, jika API tersembunyi tidak ada atau diterapkan secara berbeda pada implementasi perangkat, pindahkan API tersembunyi ke daftar tolak atau hapus dari semua daftar yang dibatasi.
- BOLEH, jika API tersembunyi belum ada di AOSP, tambahkan API tersembunyi ke daftar yang dibatasi.
Memulai persyaratan baru
- [C-0-8] TIDAK BOLEH mendukung penginstalan aplikasi yang menargetkan API level kurang dari 23.
Akhiri persyaratan baru
3.1.1. Ekstensi Android
Android mendukung perluasan platform API terkelola dari level API tertentu dengan
memperbarui versi ekstensi untuk level API tersebut. API
android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
menampilkan
versi ekstensi apiLevel
yang disediakan, jika ada ekstensi untuk
level API tersebut.
Implementasi perangkat Android:
[C-0-1] HARUS memuat sebelumnya implementasi AOSP dari library bersama
ExtShared
dan layananExtServices
dengan versi yang lebih besar dari atau sama dengan versi minimum yang diizinkan per setiap level API. Misalnya, implementasi perangkat Android 7.0, yang menjalankan API level 24 HARUS menyertakan setidaknya versi 1.[C-0-2] HANYA boleh menampilkan nomor versi ekstensi yang valid yang telah ditentukan oleh AOSP.
[C-0-3] HARUS mendukung semua API yang ditentukan oleh versi ekstensi yang ditampilkan oleh
android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
dengan cara yang sama seperti API terkelola lainnya yang didukung, dengan mengikuti persyaratan di bagian 3.1.
3.1.2. Library Android
Karena penghentian penggunaan klien HTTP Apache, implementasi perangkat:
- [C-0-1] TIDAK BOLEH menempatkan library
org.apache.http.legacy
di bootclasspath. - [C-0-2] HARUS menambahkan library
org.apache.http.legacy
ke classpath aplikasi hanya jika aplikasi memenuhi salah satu kondisi berikut:- Menargetkan API level 28 atau yang lebih rendah.
- Mendeklarasikan dalam manifesnya bahwa aplikasi memerlukan library dengan menetapkan
atribut
android:name
dari<uses-library>
keorg.apache.http.legacy
.
Implementasi AOSP memenuhi persyaratan ini.
3.2. Kompatibilitas Soft API
Selain API terkelola dari bagian 3.1, Android juga menyertakan API “soft” khusus runtime yang signifikan, dalam bentuk hal-hal seperti intent, izin, dan aspek serupa dari aplikasi Android yang tidak dapat diterapkan pada waktu kompilasi aplikasi.
3.2.1. Izin
- [C-0-1] Implementer perangkat HARUS mendukung dan menerapkan semua konstanta izin seperti yang didokumentasikan oleh halaman referensi Izin. Perhatikan bahwa bagian 9 mencantumkan persyaratan tambahan terkait model keamanan Android.
3.2.2. Parameter Build
Android API menyertakan sejumlah konstanta di class android.os.Build yang dimaksudkan untuk mendeskripsikan perangkat saat ini.
- [C-0-1] Untuk memberikan nilai yang konsisten dan bermakna di seluruh implementasi perangkat, tabel di bawah menyertakan batasan tambahan pada format nilai ini yang HARUS sesuai dengan implementasi perangkat.
Parameter | Detail |
---|---|
VERSION.RELEASE | Versi sistem Android yang sedang dieksekusi, dalam format yang dapat dibaca manusia. Kolom ini HARUS memiliki salah satu nilai string yang ditentukan dalam String Versi yang Diizinkan untuk Android 14. |
VERSION.SDK | Versi sistem Android yang sedang dieksekusi, dalam format yang dapat diakses oleh kode aplikasi pihak ketiga. Untuk Android 14, kolom ini HARUS memiliki nilai bilangan bulat 14_INT. |
VERSION.SDK_INT | Versi sistem Android yang sedang dieksekusi, dalam format yang dapat diakses oleh kode aplikasi pihak ketiga. Untuk Android 14, kolom ini HARUS memiliki nilai bilangan bulat 14_INT. |
VERSION.INCREMENTAL | Nilai yang dipilih oleh implementator perangkat yang menetapkan build tertentu dari sistem Android yang sedang dieksekusi, dalam format yang dapat dibaca manusia. Nilai ini TIDAK BOLEH digunakan kembali untuk build yang berbeda yang tersedia bagi pengguna akhir. Penggunaan umum kolom ini adalah untuk menunjukkan nomor build atau ID perubahan kontrol sumber yang digunakan untuk membuat build. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit yang dapat dicetak dan cocok dengan regular expression “^[^ :\/~]+$”. |
PAPAN | Nilai yang dipilih oleh implementator perangkat yang mengidentifikasi hardware internal tertentu yang digunakan oleh perangkat, dalam format yang dapat dibaca manusia. Kemungkinan penggunaan kolom ini adalah untuk menunjukkan revisi tertentu dari board yang memberi daya pada perangkat. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9_-]+$”. |
BRAND | Nilai yang mencerminkan nama merek yang terkait dengan perangkat seperti yang diketahui oleh pengguna akhir. HARUS dalam format yang dapat dibaca manusia dan HARUS mewakili produsen perangkat atau merek perusahaan tempat perangkat dipasarkan. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9_-]+$”. |
SUPPORTED_ABIS | Nama set petunjuk (jenis CPU + konvensi ABI) kode native. Lihat bagian 3.3. Kompatibilitas Native API. |
SUPPORTED_32_BIT_ABIS | Nama set petunjuk (jenis CPU + konvensi ABI) kode native. Lihat bagian 3.3. Kompatibilitas Native API. |
SUPPORTED_64_BIT_ABIS | Nama set petunjuk kedua (jenis CPU + konvensi ABI) dari kode native. Lihat bagian 3.3. Kompatibilitas API Native. |
CPU_ABI | Nama set petunjuk (jenis CPU + konvensi ABI) kode native. Lihat bagian 3.3. Kompatibilitas Native API. |
CPU_ABI2 | Nama set petunjuk kedua (jenis CPU + konvensi ABI) dari kode native. Lihat bagian 3.3. Kompatibilitas API Native. |
PERANGKAT | Nilai yang dipilih oleh implementer perangkat yang berisi nama pengembangan atau nama kode yang mengidentifikasi konfigurasi fitur hardware dan desain industri perangkat. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9_-]+$”. Nama perangkat ini TIDAK BOLEH berubah selama masa aktif produk. |
FINGERPRINT | String yang mengidentifikasi build ini secara unik. File ini HARUS dapat dibaca manusia. Template ini HARUS mengikuti template ini:
$(BRAND)/$(PRODUCT)/ Contoh: acme/myproduct/ Sidik jari TIDAK BOLEH menyertakan karakter spasi kosong. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit. |
PERANGKAT KERAS | Nama hardware (dari command line kernel atau /proc). File ini HARUS dapat dibaca oleh manusia. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9_-]+$”. |
HOST | String yang mengidentifikasi host tempat build dibuat secara unik, dalam format yang dapat dibaca manusia. Tidak ada persyaratan pada format khusus kolom ini, kecuali bahwa kolom ini TIDAK BOLEH null atau string kosong (""). |
ID | ID yang dipilih oleh pengimplementasi perangkat untuk merujuk ke rilis tertentu, dalam format yang dapat dibaca manusia. Kolom ini dapat sama dengan android.os.Build.VERSION.INCREMENTAL, tetapi HARUS berupa nilai yang cukup bermakna bagi pengguna akhir untuk membedakan build software. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9._-]+$”. |
PRODUSEN | Nama dagang Produsen Peralatan Asli (OEM) produk. Tidak ada persyaratan pada format spesifik kolom ini, kecuali bahwa kolom ini TIDAK BOLEH null atau string kosong (""). Kolom ini TIDAK BOLEH berubah selama masa aktif produk. |
SOC_MANUFACTURER | Nama merek produsen sistem di chip (SOC) utama yang digunakan dalam produk. Perangkat dengan produsen SOC yang sama harus menggunakan nilai konstan yang sama. Hubungi produsen SOC untuk mengetahui konstanta yang benar untuk digunakan. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit, HARUS cocok dengan ekspresi reguler “^([0-9A-Za-z ]+)”, TIDAK BOLEH diawali atau diakhiri dengan spasi kosong, dan TIDAK BOLEH sama dengan “unknown”. Kolom ini TIDAK BOLEH berubah selama masa aktif produk. |
SOC_MODEL | Nama model sistem utama di chip (SOC) yang digunakan dalam produk. Perangkat dengan model SOC yang sama harus menggunakan nilai konstan yang sama. Hubungi produsen SOC untuk mengetahui konstanta yang benar untuk digunakan. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^([0-9A-Za-z ._/+-]+)$”, TIDAK BOLEH diawali atau diakhiri dengan spasi kosong, dan TIDAK BOLEH sama dengan “unknown”. Kolom ini TIDAK BOLEH berubah selama masa aktif produk. |
MODEL | Nilai yang dipilih oleh implementator perangkat yang berisi nama perangkat seperti yang diketahui oleh pengguna akhir. Nama ini HARUS sama dengan nama yang digunakan untuk memasarkan dan menjual perangkat kepada pengguna akhir. Tidak ada persyaratan pada format khusus kolom ini, kecuali bahwa kolom ini TIDAK BOLEH null atau string kosong (""). Kolom ini TIDAK BOLEH berubah selama masa aktif produk. |
PRODUK | Nilai yang dipilih oleh implementer perangkat yang berisi nama pengembangan atau nama kode produk tertentu (SKU) yang HARUS unik dalam merek yang sama. HARUS dapat dibaca manusia, tetapi tidak selalu dimaksudkan untuk dilihat oleh pengguna akhir. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9_-]+$”. Nama produk ini TIDAK BOLEH berubah selama masa aktif produk. |
ODM_SKU | Nilai opsional yang dipilih oleh pengimplementasi perangkat yang berisi
SKU (Unit Pengelolaan Stok) yang digunakan untuk melacak konfigurasi
perangkat tertentu, misalnya, periferal apa pun yang disertakan dengan perangkat saat dijual.
Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan
ekspresi reguler ^([0-9A-Za-z.,_-]+)$ . |
SERIAL | HARUS menampilkan "UNKNOWN". |
TAG | Daftar tag yang dipisahkan koma yang dipilih oleh implementer perangkat yang lebih lanjut membedakan build. Tag HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9._-]+” dan HARUS memiliki salah satu nilai yang sesuai dengan tiga konfigurasi penandatanganan platform Android standar: kunci rilis, kunci developer, dan kunci pengujian. |
WAKTU | Nilai yang mewakili stempel waktu saat build terjadi. |
TYPE | Nilai yang dipilih oleh implementator perangkat yang menentukan konfigurasi runtime build. Kolom ini HARUS memiliki salah satu nilai yang sesuai dengan tiga konfigurasi runtime Android standar: user, userdebug, atau eng. |
PENGGUNA | Nama atau ID pengguna pengguna (atau pengguna otomatis) yang membuat build. Tidak ada persyaratan pada format khusus kolom ini, kecuali bahwa kolom ini TIDAK BOLEH null atau string kosong (""). |
SECURITY_PATCH | Nilai yang menunjukkan tingkat patch keamanan build. Hal ini HARUS menunjukkan bahwa build tidak rentan terhadap masalah apa pun yang dijelaskan melalui Android Public Security Bulletin yang ditetapkan. Formatnya HARUS dalam format [YYYY-MM-DD], yang cocok dengan string yang ditentukan dan didokumentasikan dalam Android Public Security Bulletin atau dalam Android Security Advisory, misalnya "2015-11-01". |
BASE_OS | Nilai yang mewakili parameter FINGERPRINT dari build yang identik dengan build ini kecuali untuk patch yang disediakan dalam Android Public Security Bulletin. Ini HARUS melaporkan nilai yang benar dan jika build tersebut tidak ada, laporkan string kosong (""). |
BOOTLOADER | Nilai yang dipilih oleh implementator perangkat yang mengidentifikasi versi bootloader internal tertentu yang digunakan di perangkat, dalam format yang dapat dibaca manusia. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan regular expression “^[a-zA-Z0-9._-]+$”. |
getRadioVersion() | HARUS (menjadi atau menampilkan) nilai yang dipilih oleh implementator perangkat yang mengidentifikasi versi radio/modem internal tertentu yang digunakan dalam perangkat, dalam format yang dapat dibaca manusia. Jika perangkat tidak memiliki radio/modem internal, perangkat HARUS menampilkan NULL. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9._-,]+$”. |
getSerial() | HARUS (menjadi atau menampilkan) nomor seri hardware, yang HARUS tersedia dan unik di seluruh perangkat dengan MODEL dan PRODUSEN yang sama. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9]+$”. |
3.2.3. Kompatibilitas Intent
3.2.3.1. Intent Aplikasi Umum
Intent Android memungkinkan komponen aplikasi meminta fungsi dari komponen Android lainnya. Project upstream Android menyertakan daftar aplikasi yang menerapkan beberapa pola intent untuk melakukan tindakan umum.
Implementasi perangkat:
- [C-SR-1] SANGAT DISARANKAN untuk memuat ulang satu atau beberapa aplikasi atau komponen layanan dengan pengendali intent, untuk semua pola filter intent publik yang ditentukan oleh intent aplikasi berikut yang tercantum di sini dan memberikan fulfillment, yaitu memenuhi ekspektasi developer untuk intent aplikasi umum ini seperti yang dijelaskan dalam SDK.
Lihat Bagian 2 untuk mengetahui intent aplikasi wajib untuk setiap jenis perangkat.
3.2.3.2. Resolusi Maksud
[C-0-1] Karena Android adalah platform yang dapat diperluas, implementasi perangkat HARUS memungkinkan setiap pola intent yang dirujuk dalam bagian 3.2.3.1 , kecuali Setelan, untuk diganti oleh aplikasi pihak ketiga. Implementasi open source Android upstream mengizinkan hal ini secara default.
[C-0-2] Implementer perangkat TIDAK BOLEH melampirkan hak istimewa khusus ke penggunaan pola intent oleh aplikasi sistem, atau mencegah aplikasi pihak ketiga mengikat dan mengambil alih kontrol atas pola ini. Larangan ini khususnya mencakup, tetapi tidak terbatas pada, menonaktifkan antarmuka pengguna "Chooser" yang memungkinkan pengguna memilih di antara beberapa aplikasi yang semuanya menangani pola intent yang sama.
[C-0-3] Implementasi perangkat HARUS menyediakan antarmuka pengguna bagi pengguna untuk mengubah aktivitas default untuk intent.
Namun, implementasi perangkat DAPAT menyediakan aktivitas default untuk pola URI tertentu (misalnya, http://play.google.com) saat aktivitas default menyediakan atribut yang lebih spesifik untuk URI data. Misalnya, pola filter intent yang menentukan URI data “http://www.android.com” lebih spesifik daripada pola intent inti browser untuk “http://”.
Android juga menyertakan mekanisme bagi aplikasi pihak ketiga untuk mendeklarasikan perilaku penautan aplikasi default resmi untuk jenis intent URI web tertentu. Jika deklarasi resmi tersebut ditentukan dalam pola filter intent aplikasi, implementasi perangkat:
- [C-0-4] HARUS mencoba memvalidasi filter intent apa pun dengan melakukan langkah-langkah validasi yang ditentukan dalam spesifikasi Digital Asset Links seperti yang diterapkan oleh Pengelola Paket di Project Open Source Android upstream.
- [C-0-5] HARUS mencoba validasi filter intent selama penginstalan aplikasi dan menetapkan semua filter intent URI yang berhasil divalidasi sebagai pengendali aplikasi default untuk URI-nya.
- DAPAT menetapkan filter intent URI tertentu sebagai pengendali aplikasi default untuk URI-nya, jika filter berhasil diverifikasi, tetapi filter URI kandidat lainnya gagal verifikasi. Jika implementasi perangkat melakukan hal ini, implementasi tersebut HARUS memberikan penggantian pola per URI yang sesuai bagi pengguna di menu setelan.
- HARUS memberikan kontrol Link Aplikasi per aplikasi kepada pengguna di Setelan sebagai
berikut:
- [C-0-6] Pengguna HARUS dapat mengganti perilaku link aplikasi default secara menyeluruh agar aplikasi: selalu terbuka, selalu bertanya, atau tidak pernah terbuka, yang harus berlaku untuk semua filter intent URI kandidat secara setara.
- [C-0-7] Pengguna HARUS dapat melihat daftar filter intent URI kandidat.
- Implementasi perangkat DAPAT memberi pengguna kemampuan untuk mengganti filter intent URI kandidat tertentu yang berhasil diverifikasi, berdasarkan filter per intent.
- [C-0-8] Implementasi perangkat HARUS memberi pengguna kemampuan untuk melihat dan mengganti filter intent URI kandidat tertentu jika implementasi perangkat memungkinkan beberapa filter intent URI kandidat berhasil diverifikasi, sementara beberapa filter lainnya dapat gagal.
3.2.3.3. Namespace Intent
- [C-0-1] Implementasi perangkat TIDAK BOLEH menyertakan komponen Android apa pun yang menghormati intent baru atau pola intent siaran menggunakan ACTION, CATEGORY, atau string kunci lainnya di namespace android.* atau com.android.*.
- [C-0-2] Implementer perangkat TIDAK BOLEH menyertakan komponen Android apa pun yang menghormati intent baru atau pola intent siaran menggunakan ACTION, CATEGORY, atau string kunci lainnya di ruang paket milik organisasi lain.
- [C-0-3] Implementer perangkat TIDAK BOLEH mengubah atau memperluas pola intent apa pun yang tercantum dalam bagian 3.2.3.1.
- Implementasi perangkat DAPAT menyertakan pola intent menggunakan namespace yang dikaitkan dengan organisasinya sendiri secara jelas. Larangan ini analog dengan yang ditentukan untuk class bahasa Java di bagian 3.6.
3.2.3.4. Intent Siaran
Aplikasi pihak ketiga mengandalkan platform untuk menyiarkan intent tertentu guna memberi tahu mereka tentang perubahan di lingkungan hardware atau software.
Implementasi perangkat:
- [C-0-1] HARUS menyiarkan intent siaran publik yang tercantum di sini sebagai respons terhadap peristiwa sistem yang sesuai seperti yang dijelaskan dalam dokumentasi SDK. Perhatikan bahwa persyaratan ini tidak bertentangan dengan bagian 3.5 karena batasan untuk aplikasi latar belakang juga dijelaskan dalam dokumentasi SDK. Selain itu, intent siaran tertentu bersifat kondisional berdasarkan dukungan hardware. Jika perangkat mendukung hardware yang diperlukan, perangkat HARUS menyiarkan intent dan memberikan perilaku yang selaras dengan dokumentasi SDK.
3.2.3.5. Intent Aplikasi Bersyarat
Android menyertakan setelan yang memberikan cara mudah kepada pengguna untuk memilih aplikasi default mereka, misalnya untuk Layar utama atau SMS.
Jika memungkinkan, implementasi perangkat HARUS menyediakan menu setelan yang serupa dan kompatibel dengan pola filter intent dan metode API yang dijelaskan dalam dokumentasi SDK seperti di bawah.
Jika implementasi perangkat melaporkan android.software.home_screen
, implementasi tersebut:
- [C-1-1] HARUS mematuhi intent
android.settings.HOME_SETTINGS
untuk menampilkan menu setelan aplikasi default untuk Layar Utama.
Jika implementasi perangkat melaporkan android.hardware.telephony.calling
, implementasi tersebut:
[C-2-1] HARUS menyediakan menu setelan yang akan memanggil intent
android.provider.Telephony.ACTION_CHANGE_DEFAULT
untuk menampilkan dialog guna mengubah aplikasi SMS default.[C-2-2] HARUS mematuhi intent
android.telecom.action.CHANGE_DEFAULT_DIALER
untuk menampilkan dialog guna memungkinkan pengguna mengubah aplikasi Ponsel default.- HARUS menggunakan UI aplikasi Telepon default yang dipilih pengguna untuk panggilan masuk dan keluar, kecuali untuk panggilan darurat, yang akan menggunakan aplikasi Telepon bawaan.
[C-2-3] HARUS mematuhi intent android.telecom.action.CHANGE_PHONE_ACCOUNTS untuk memberikan kemampuan pengguna guna mengonfigurasi
ConnectionServices
yang terkait denganPhoneAccounts
, serta PhoneAccount default yang akan digunakan penyedia layanan telekomunikasi untuk melakukan panggilan keluar. Implementasi AOSP memenuhi persyaratan ini dengan menyertakan menu "Opsi Akun Panggilan" dalam menu setelan "Panggilan".[C-2-4] HARUS mengizinkan
android.telecom.CallRedirectionService
untuk aplikasi yang memiliki peranandroid.app.role.CALL_REDIRECTION
.[C-2-5] HARUS memberikan kemampuan kepada pengguna untuk memilih aplikasi yang memiliki peran
android.app.role.CALL_REDIRECTION
.[C-2-6] HARUS mematuhi intent android.intent.action.SENDTO dan android.intent.action.VIEW serta menyediakan aktivitas untuk mengirim/menampilkan pesan SMS.
[C-SR-1] SANGAT DISARANKAN untuk mematuhi intent android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW & android.intent.action.DIAL dengan aplikasi dialer yang dimuat sebelumnya yang dapat menangani intent ini dan memberikan fulfillment seperti yang dijelaskan dalam SDK.
Jika implementasi perangkat melaporkan android.hardware.nfc.hce
, implementasi tersebut:
- [C-3-1] HARUS mematuhi intent android.settings.NFC_PAYMENT_SETTINGS untuk menampilkan menu setelan aplikasi default untuk Pembayaran nirsentuh.
- [C-3-2] HARUS mematuhi intent android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT untuk menampilkan aktivitas yang membuka dialog guna meminta pengguna mengubah layanan emulasi kartu default untuk kategori tertentu seperti yang dijelaskan dalam SDK.
Jika implementasi perangkat melaporkan android.hardware.nfc
, implementasi tersebut:
- [C-4-1] HARUS mematuhi intent ini android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED & android.nfc.action.TECH_DISCOVERED, untuk menampilkan aktivitas yang memenuhi ekspektasi developer untuk intent ini seperti yang dijelaskan dalam SDK.
Jika implementasi perangkat melaporkan android.hardware.bluetooth
, implementasi tersebut:
- [C-5-1] HARUS mematuhi intent ‘android.bluetooth.adapter.action.REQUEST_ENABLE’ dan menampilkan aktivitas sistem untuk memungkinkan pengguna mengaktifkan Bluetooth.
- [C-5-2] HARUS mematuhi intent ‘android.bluetooth.adapter.action.REQUEST_DISCOVERABLE’ dan menampilkan aktivitas sistem yang meminta mode yang dapat ditemukan.
Jika implementasi perangkat mendukung fitur DND, perangkat tersebut:
- [C-6-1] HARUS mengimplementasikan aktivitas yang akan merespons intent
ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS
, yang untuk implementasi dengan UI_MODE_TYPE_NORMAL HARUS berupa aktivitas tempat pengguna dapat memberikan atau menolak akses aplikasi ke konfigurasi kebijakan DND.
Jika implementasi perangkat memungkinkan pengguna menggunakan metode input pihak ketiga di perangkat, mereka:
- [C-7-1] HARUS menyediakan mekanisme yang dapat diakses pengguna untuk menambahkan dan mengonfigurasi
metode input pihak ketiga sebagai respons terhadap
intent
android.settings.INPUT_METHOD_SETTINGS
.
Jika implementasi perangkat mendukung layanan aksesibilitas pihak ketiga, implementasi tersebut:
- [C-8-1] HARUS mematuhi intent
android.settings.ACCESSIBILITY_SETTINGS
untuk menyediakan mekanisme yang dapat diakses pengguna guna mengaktifkan dan menonaktifkan layanan aksesibilitas pihak ketiga bersama dengan layanan aksesibilitas yang dimuat sebelumnya.
Jika implementasi perangkat menyertakan dukungan untuk Wi-Fi Easy Connect dan mengekspos fungsi ke aplikasi pihak ketiga, perangkat tersebut:
- [C-9-1] HARUS menerapkan API Intent Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI seperti yang dijelaskan dalam dokumentasi SDK.
Jika implementasi perangkat menyediakan mode penghemat data, implementasi tersebut:
- [C-10-1] HARUS menyediakan antarmuka pengguna di setelan, yang menangani
intent
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
, yang memungkinkan pengguna menambahkan aplikasi ke atau menghapus aplikasi dari daftar yang diizinkan.
Jika implementasi perangkat tidak menyediakan mode penghemat data, implementasi tersebut:
- [C-11-1] HARUS memiliki aktivitas yang menangani
intent
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
, tetapi DAPAT menerapkannya sebagai no-op.
Jika implementasi perangkat mendeklarasikan dukungan untuk kamera melalui
android.hardware.camera.any
, implementasi tersebut:
- [C-12-3] HARUS menangani dan HANYA BOLEH mengizinkan aplikasi Android bawaan
untuk menangani intent berikut
MediaStore.ACTION_IMAGE_CAPTURE
,MediaStore.ACTION_IMAGE_CAPTURE_SECURE
, danMediaStore.ACTION_VIDEO_CAPTURE
seperti yang dijelaskan dalam dokumen SDK.
Jika implementasi perangkat melaporkan android.software.device_admin
, implementasi tersebut:
[C-13-1] HARUS mematuhi intent
android.app.action.ADD_DEVICE_ADMIN
untuk memanggil UI guna memandu pengguna menambahkan administrator perangkat ke sistem (atau mengizinkan mereka menolaknya).[C-13-2] HARUS mematuhi intent android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD & android.app.action.START_ENCRYPTION dan memiliki aktivitas untuk memberikan fulfillment untuk intent ini seperti yang dijelaskan di SDK di sini.
Jika implementasi perangkat mendeklarasikan flag fitur
android.software.autofill
, implementasi tersebut:
- [C-14-1] HARUS menerapkan API
AutofillService
danAutofillManager
secara penuh dan mematuhi intent android.settings.REQUEST_SET_AUTOFILL_SERVICE untuk menampilkan menu setelan aplikasi default guna mengaktifkan dan menonaktifkan isi otomatis serta mengubah layanan isi otomatis default untuk pengguna.
Jika implementasi perangkat menyertakan aplikasi bawaan atau ingin mengizinkan aplikasi pihak ketiga mengakses statistik penggunaan, aplikasi tersebut:
- [C-SR-2] SANGAT DISARANKAN untuk menyediakan mekanisme yang dapat diakses pengguna untuk memberikan
atau mencabut akses ke statistik penggunaan sebagai respons terhadap
intent
android.settings.ACTION_USAGE_ACCESS_SETTINGS untuk aplikasi yang mendeklarasikan izin
android.permission.PACKAGE_USAGE_STATS
.
Jika implementasi perangkat ingin melarang aplikasi apa pun, termasuk aplikasi pra-instal, mengakses statistik penggunaan, implementasi tersebut:
- [C-15-1] HARUS tetap memiliki aktivitas yang menangani pola intent android.settings.ACTION_USAGE_ACCESS_SETTINGS, tetapi HARUS menerapkannya sebagai no-op, yaitu memiliki perilaku yang setara seperti saat pengguna ditolak aksesnya.
Jika implementasi perangkat menampilkan link ke aktivitas yang ditentukan oleh AutofillService_passwordsActivity di Setelan atau link ke sandi pengguna melalui mekanisme serupa, implementasi tersebut:
- [C-16-1] HARUS menampilkan link tersebut untuk semua layanan isi otomatis yang diinstal.
Jika implementasi perangkat mendukung VoiceInteractionService
dan memiliki lebih
dari satu aplikasi yang menggunakan API ini yang diinstal sekaligus, implementasi tersebut:
- [C-18-1] HARUS mematuhi intent
android.settings.ACTION_VOICE_INPUT_SETTINGS
untuk menampilkan menu setelan aplikasi default untuk input suara dan bantuan.
Jika implementasi perangkat melaporkan fitur android.hardware.audio.output
,
perangkat tersebut:
- [C-SR-3] SANGAT DISARANKAN untuk mematuhi intent android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA & android.speech.tts.engine.GET_SAMPLE_TEXT memiliki aktivitas untuk memberikan fulfillment untuk intent ini seperti yang dijelaskan dalam SDK di sini.
Android menyertakan dukungan untuk screensaver interaktif, yang sebelumnya disebut Dreams. Screen Saver memungkinkan pengguna berinteraksi dengan aplikasi saat perangkat yang terhubung ke sumber daya tidak ada aktivitas atau di-dock di dok meja. Penerapan Perangkat:
- HARUS menyertakan dukungan untuk screen saver dan memberikan opsi setelan bagi
pengguna untuk mengonfigurasi screen saver sebagai respons terhadap
intent
android.settings.DREAM_SETTINGS
.
Memulai persyaratan baru
Jika implementasi perangkat melaporkan android.hardware.nfc.uicc
atau android.hardware.nfc.ese
,
implementasi tersebut:
- [C-19-1] HARUS mengimplementasikan Intent API NfcAdapter.ACTION_TRANSACTION_DETECTED (seperti “EVT_TRANSACTION” yang ditentukan oleh spesifikasi teknis GSM Association TS.26 - NFC Handset Requirements).
Akhiri persyaratan baru
3.2.4. Aktivitas di tampilan sekunder/beberapa tampilan
Jika implementasi perangkat memungkinkan peluncuran Aktivitas Android normal di lebih dari satu layar, implementasi tersebut:
- [C-1-1] HARUS menetapkan flag fitur
android.software.activities_on_secondary_displays
. - [C-1-2] HARUS menjamin kompatibilitas API yang mirip dengan aktivitas yang berjalan di layar utama.
- [C-1-3] HARUS menampilkan aktivitas baru di layar yang sama dengan aktivitas yang
meluncurkannya, saat aktivitas baru diluncurkan tanpa menentukan layar
target melalui
ActivityOptions.setLaunchDisplayId()
API. - [C-1-4] HARUS menghancurkan semua aktivitas, saat tampilan dengan
tanda
Display.FLAG_PRIVATE
dihapus. - [C-1-5] HARUS menyembunyikan konten dengan aman di semua layar saat perangkat dikunci
dengan layar kunci yang aman, kecuali jika aplikasi memilih untuk ditampilkan di atas layar
kunci menggunakan
Activity#setShowWhenLocked()
API. - HARUS memiliki
android.content.res.Configuration
yang sesuai dengan tampilan tersebut agar dapat ditampilkan, beroperasi dengan benar, dan mempertahankan kompatibilitas jika aktivitas diluncurkan di layar sekunder.
Jika implementasi perangkat memungkinkan peluncuran Aktivitas Android normal di tampilan sekunder dan tampilan sekunder memiliki tanda android.view.Display.FLAG_PRIVATE:
- [C-3-1] Hanya pemilik layar, sistem, dan aktivitas yang sudah ada di layar tersebut yang HARUS dapat diluncurkan ke layar tersebut. Semua orang dapat meluncurkan ke layar yang memiliki tanda android.view.Display.FLAG_PUBLIC.
3.3. Kompatibilitas API Native
Kompatibilitas kode native sangat sulit. Oleh karena itu, penerapkan perangkat adalah:
- [C-SR-1] SANGAT DISARANKAN untuk menggunakan implementasi library yang tercantum di bawah dari Project Open Source Android upstream.
3.3.1. Antarmuka Biner Aplikasi
Bytecode Dalvik terkelola dapat memanggil kode native yang disediakan dalam file
.apk
aplikasi sebagai file .so
ELF yang dikompilasi untuk arsitektur
hardware perangkat yang sesuai. Karena kode native sangat bergantung pada teknologi prosesor
yang mendasarinya, Android menentukan sejumlah Antarmuka Biner Aplikasi (ABI) di
Android NDK.
Implementasi perangkat:
- [C-0-1] HARUS kompatibel dengan satu atau beberapa Android NDK ABI yang ditentukan.
- [C-0-2] HARUS menyertakan dukungan untuk kode yang berjalan di lingkungan terkelola untuk memanggil kode native, menggunakan semantik Java Native Interface (JNI) standar.
- [C-0-3] HARUS kompatibel dengan sumber (yaitu kompatibel dengan header) dan kompatibel dengan biner (untuk ABI) dengan setiap library yang diperlukan dalam daftar di bawah.
- [C-0-5] HARUS melaporkan Application Binary Interface
(ABI) native yang didukung oleh perangkat secara akurat, melalui parameter
android.os.Build.SUPPORTED_ABIS
,android.os.Build.SUPPORTED_32_BIT_ABIS
, danandroid.os.Build.SUPPORTED_64_BIT_ABIS
, masing-masing adalah daftar ABI yang dipisahkan koma yang diurutkan dari yang paling banyak hingga yang paling tidak disukai. [C-0-6] HARUS melaporkan, melalui parameter di atas, sebagian dari daftar ABI berikut dan TIDAK BOLEH melaporkan ABI apa pun yang tidak ada dalam daftar.
armeabi
(tidak lagi didukung sebagai target oleh NDK)armeabi-v7a
arm64-v8a
x86
x86-64
[C-0-7] HARUS membuat semua library berikut, yang menyediakan API native, tersedia untuk aplikasi yang menyertakan kode native:
- libaaudio.so (dukungan audio native AAudio)
- libamidi.so (dukungan MIDI native, jika fitur
android.software.midi
diklaim seperti yang dijelaskan di Bagian 5.9) - libandroid.so (dukungan aktivitas Android native)
- libc (library C)
- libcamera2ndk.so
- libdl (dynamic linker)
- libEGL.so (pengelolaan platform OpenGL native)
- libGLESv1_CM.so (OpenGL ES 1.x)
- libGLESv2.so (OpenGL ES 2.0)
- libGLESv3.so (OpenGL ES 3.x)
- libicui18n.so
- libicuuc.so
- libjnigraphics.so
- liblog (logging Android)
- libmediandk.so (dukungan API media native)
- libm (library matematika)
- libneuralnetworks.so (Neural Networks API)
- libOpenMAXAL.so (dukungan OpenMAX AL 1.0.1)
- libOpenSLES.so (dukungan audio OpenSL ES 1.0.1)
- libRS.so
- libstdc++ (Dukungan minimal untuk C++)
- libvulkan.so (Vulkan)
- libz (Kompresi Zlib)
- Antarmuka JNI
[C-0-8] TIDAK BOLEH menambahkan atau menghapus fungsi publik untuk library native yang tercantum di atas.
[C-0-9] HARUS mencantumkan library non-AOSP tambahan yang diekspos langsung ke aplikasi pihak ketiga di
/vendor/etc/public.libraries.txt
.[C-0-10] TIDAK BOLEH mengekspos library native lainnya, yang diimplementasikan dan disediakan di AOSP sebagai library sistem, ke aplikasi pihak ketiga yang menargetkan API level 24 atau yang lebih tinggi karena direservasi.
[C-0-11] HARUS mengekspor semua simbol fungsi OpenGL ES 3.1 dan Android Extension Pack, seperti yang ditentukan dalam NDK, melalui library
libGLESv3.so
. Perhatikan bahwa meskipun semua simbol HARUS ada, bagian 7.1.4.1 menjelaskan lebih detail persyaratan untuk waktu penerapan penuh setiap fungsi yang sesuai.[C-0-12] HARUS mengekspor simbol fungsi untuk simbol fungsi
Vulkan 1.0Vulkan 1.1 inti, serta ekstensiVK_KHR_surface
,VK_KHR_android_surface
,VK_KHR_swapchain
,VK_KHR_maintenance1
, danVK_KHR_get_physical_device_properties2
melalui librarylibvulkan.so
. Perhatikan bahwa meskipun semua simbol HARUS ada, bagian 7.1.4.2 menjelaskan secara lebih mendetail persyaratan untuk saat penerapan penuh setiap fungsi yang sesuai diharapkan.HARUS dibuat menggunakan kode sumber dan file header yang tersedia di Project Open Source Android upstream.
Perhatikan bahwa rilis Android mendatang dapat memperkenalkan dukungan untuk ABI tambahan.
3.3.2. Kompatibilitas Kode Native ARM 32-bit
Jika implementasi perangkat melaporkan dukungan ABI armeabi
, implementasi tersebut:
- [C-3-1] JUGA HARUS mendukung
armeabi-v7a
dan melaporkan dukungannya, karenaarmeabi
hanya untuk kompatibilitas mundur dengan aplikasi lama.
Jika implementasi perangkat melaporkan dukungan ABI armeabi-v7a
, untuk aplikasi
yang menggunakan ABI ini, aplikasi tersebut:
[C-2-1] HARUS menyertakan baris berikut di
/proc/cpuinfo
, dan TIDAK BOLEH mengubah nilai di perangkat yang sama, meskipun dibaca oleh ABI lain.Features:
, diikuti dengan daftar fitur CPU ARMv7 opsional yang didukung oleh perangkat.CPU architecture:
, diikuti dengan bilangan bulat yang menjelaskan arsitektur ARM tertinggi yang didukung perangkat (misalnya, "8" untuk perangkat ARMv8).
[C-2-2] HARUS selalu menyediakan operasi berikut, bahkan jika ABI diterapkan pada arsitektur ARMv8, baik melalui dukungan CPU native maupun melalui emulasi software:
- Instruksi SWP dan SWPB.
- Operasi penghalang CP15ISB, CP15DSB, dan CP15DMB.
[C-2-3] HARUS menyertakan dukungan untuk ekstensi Advanced SIMD (alias NEON).
3.4. Kompatibilitas Web
3.4.1. Kompatibilitas WebView
Jika implementasi perangkat menyediakan implementasi lengkap
android.webkit.Webview
API, implementasi tersebut:
- [C-1-1] HARUS melaporkan
android.software.webview
. - [C-1-2] HARUS menggunakan build Project Chromium
dari Project Open Source Android upstream di cabang
Android 14 untuk implementasi
API
android.webkit.WebView
. [C-1-3] String agen pengguna yang dilaporkan oleh WebView HARUS dalam format ini:
Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- Nilai string $(VERSION) HARUS sama dengan nilai untuk android.os.Build.VERSION.RELEASE.
- String $(MODEL) BOLEH kosong, tetapi jika tidak kosong, string tersebut HARUS memiliki nilai yang sama dengan android.os.Build.MODEL.
- "Build/$(BUILD)" DAPAT dihilangkan, tetapi jika ada, string $(BUILD) HARUS sama dengan nilai untuk android.os.Build.ID.
- Nilai string $(CHROMIUM_VER) HARUS berupa versi Chromium di Project Open Source Android upstream.
- Implementasi perangkat DAPAT menghilangkan Seluler dalam string agen pengguna.
Komponen WebView HARUS menyertakan dukungan untuk sebanyak mungkin fitur HTML5 dan jika mendukung fitur tersebut, HARUS sesuai dengan spesifikasi HTML5.
[C-1-4] HARUS merender konten yang disediakan atau konten URL jarak jauh dalam proses yang berbeda dari aplikasi yang membuat instance WebView. Secara khusus, proses perender terpisah HARUS memiliki hak istimewa yang lebih rendah, berjalan sebagai ID pengguna terpisah, tidak memiliki akses ke direktori data aplikasi, tidak memiliki akses jaringan langsung, dan hanya memiliki akses ke layanan sistem yang diperlukan minimum melalui Binder. Penerapan WebView AOSP memenuhi persyaratan ini.
Perhatikan bahwa jika implementasi perangkat adalah 32-bit atau mendeklarasikan flag fitur
android.hardware.ram.low
, implementasi tersebut dikecualikan dari C-1-3.
3.4.2. Kompatibilitas Browser
Jika implementasi perangkat menyertakan aplikasi Browser mandiri untuk penjelajahan web umum, aplikasi tersebut:
- [C-1-1] HARUS mendukung setiap API berikut yang terkait dengan HTML5:
- [C-1-2] HARUS mendukung webstorage API HTML5/W3C dan HARUS mendukung IndexedDB API HTML5/W3C. Perhatikan bahwa karena badan standar pengembangan web bertransisi untuk lebih memilih IndexedDB daripada webstorage, IndexedDB diharapkan menjadi komponen yang diperlukan dalam versi Android mendatang.
- DAPAT mengirimkan string agen pengguna kustom di aplikasi Browser mandiri.
- HARUS menerapkan dukungan untuk HTML5 sebanyak mungkin di aplikasi Browser mandiri (baik berdasarkan aplikasi Browser WebKit upstream maupun penggantian pihak ketiga).
Namun, jika implementasi perangkat tidak menyertakan aplikasi Browser mandiri, implementasi tersebut:
- [C-2-1] HARUS tetap mendukung pola intent publik seperti yang dijelaskan di bagian 3.2.3.1.
3.5. Kompatibilitas Perilaku API
Implementasi perangkat:
- [C-0-9] HARUS memastikan bahwa kompatibilitas perilaku API diterapkan untuk semua aplikasi yang diinstal, kecuali jika dibatasi seperti yang dijelaskan dalam Bagian 3.5.1.
- [C-0-10] TIDAK BOLEH menerapkan pendekatan daftar yang diizinkan yang memastikan kompatibilitas perilaku API hanya untuk aplikasi yang dipilih oleh implementer perangkat.
Perilaku setiap jenis API (terkelola, soft, native, dan web) harus konsisten dengan penerapan Android Open Source Project upstream yang diinginkan. Beberapa area kompatibilitas tertentu adalah:
- [C-0-1] Perangkat TIDAK BOLEH mengubah perilaku atau semantik intent standar.
- [C-0-2] Perangkat TIDAK BOLEH mengubah siklus proses atau semantik siklus proses jenis komponen sistem tertentu (seperti Layanan, Aktivitas, ContentProvider, dll.).
- [C-0-3] Perangkat TIDAK BOLEH mengubah semantik izin standar.
- Perangkat TIDAK BOLEH mengubah batasan yang diterapkan pada aplikasi latar belakang.
Lebih khusus lagi, untuk aplikasi latar belakang:
- [C-0-4] aplikasi HARUS berhenti mengeksekusi callback yang terdaftar oleh
aplikasi untuk menerima output dari
GnssMeasurement
danGnssNavigationMessage
. - [C-0-5] API ini HARUS membatasi frekuensi update yang
disediakan ke aplikasi melalui
class API
LocationManager
atau metodeWifiManager.startScan()
. - [C-0-6] jika aplikasi menargetkan API level 25 atau yang lebih tinggi, aplikasi TIDAK BOLEH
mengizinkan pendaftaran penerima siaran untuk siaran implisit
intent Android standar dalam manifes aplikasi, kecuali jika intent
siaran memerlukan izin
"signature"
atau"signatureOrSystem"
protectionLevel
atau berada dalam daftar pengecualian. - [C-0-7] jika aplikasi menargetkan API level 25 atau yang lebih tinggi, aplikasi HARUS menghentikan
layanan latar belakang aplikasi, sama seperti aplikasi telah memanggil
metode
stopSelf()
layanan, kecuali jika aplikasi ditempatkan di daftar yang diizinkan sementara untuk menangani tugas yang terlihat oleh pengguna. - [C-0-8] jika aplikasi menargetkan API level 25 atau yang lebih tinggi, aplikasi HARUS melepaskan wakelock yang disimpan aplikasi.
- [C-0-4] aplikasi HARUS berhenti mengeksekusi callback yang terdaftar oleh
aplikasi untuk menerima output dari
- [C-0-11] Perangkat HARUS menampilkan penyedia keamanan berikut sebagai tujuh
nilai array pertama dari
metode
Security.getProviders()
, dalam urutan yang diberikan dan dengan nama yang diberikan (seperti yang ditampilkan olehProvider.getName()
) dan class, kecuali jika aplikasi telah mengubah daftar melaluiinsertProviderAt()
atauremoveProvider()
. Perangkat DAPAT menampilkan penyedia tambahan setelah daftar penyedia yang ditentukan di bawah.- AndroidNSSP -
android.security.net.config.NetworkSecurityConfigProvider
- AndroidOpenSSL -
com.android.org.conscrypt.OpenSSLProvider
- CertPathProvider -
sun.security.provider.CertPathProvider
- AndroidKeyStoreBCWorkaround -
android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
- BC -
com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
- HarmonyJSSE -
com.android.org.conscrypt.JSSEProvider
- AndroidKeyStore -
android.security.keystore.AndroidKeyStoreProvider
- AndroidNSSP -
Daftar di atas tidak lengkap. Compatibility Test Suite (CTS) menguji bagian platform yang signifikan untuk kompatibilitas perilaku, tetapi tidak semuanya. Implementer bertanggung jawab untuk memastikan kompatibilitas perilaku dengan Project Open Source Android. Oleh karena itu, implementer perangkat HARUS menggunakan kode sumber yang tersedia melalui Project Open Source Android jika memungkinkan, bukan menerapkan ulang bagian penting sistem.
3.5.1. Pembatasan Aplikasi
Jika implementasi perangkat menerapkan mekanisme eksklusif untuk membatasi aplikasi (misalnya, mengubah atau membatasi perilaku API yang dijelaskan dalam SDK) dan mekanisme tersebut lebih ketat daripada Bucket Aplikasi Standby yang Dibatasi, mekanisme tersebut:
- [C-1-1] HARUS mengizinkan pengguna melihat daftar aplikasi yang dibatasi.
- [C-1-2] HARUS memberikan kemampuan pengguna untuk mengaktifkan / menonaktifkan semua batasan eksklusif ini di setiap aplikasi.
[C-1-3] TIDAK BOLEH menerapkan batasan eksklusif ini secara otomatis tanpa bukti perilaku kesehatan sistem yang buruk, tetapi BOLEH menerapkan batasan pada aplikasi setelah mendeteksi perilaku kesehatan sistem yang buruk seperti wakelock yang macet, layanan yang berjalan lama, dan kriteria lainnya. Kriteria DAPAT ditentukan oleh implementer perangkat, tetapi HARUS terkait dengan dampak aplikasi terhadap kesehatan sistem. Kriteria lain yang tidak sepenuhnya terkait dengan kondisi sistem, seperti kurangnya popularitas aplikasi di pasar, TIDAK BOLEH digunakan sebagai kriteria.
[C-1-4] TIDAK BOLEH secara otomatis menerapkan batasan eksklusif ini untuk aplikasi saat pengguna telah menonaktifkan batasan aplikasi secara manual, dan DAPAT menyarankan pengguna untuk menerapkan batasan eksklusif ini.
[C-1-5] HARUS memberi tahu pengguna jika batasan eksklusif ini diterapkan ke aplikasi secara otomatis. Informasi tersebut HARUS diberikan dalam jangka waktu 24 jam sebelum penerapan batasan eksklusif ini.
[C-1-6] HARUS menampilkan benar untuk metode ActivityManager.isBackgroundRestricted() untuk panggilan API apa pun dari aplikasi.
[C-1-7] TIDAK BOLEH membatasi aplikasi latar depan teratas yang secara eksplisit digunakan oleh pengguna.
[C-1-8] HARUS menangguhkan batasan eksklusif ini pada aplikasi setiap kali pengguna mulai menggunakan aplikasi secara eksplisit, sehingga menjadikannya aplikasi latar depan utama.
[C-1-10] HARUS menyediakan dokumen atau situs publik dan jelas yang menjelaskan cara pembatasan eksklusif diterapkan. Dokumen atau situs ini HARUS dapat ditautkan dari dokumen Android SDK dan HARUS menyertakan:
- Memicu kondisi untuk pembatasan eksklusif.
- Apa dan bagaimana aplikasi dapat dibatasi.
- Cara aplikasi dapat dikecualikan dari batasan tersebut.
- Cara aplikasi dapat meminta pengecualian dari pembatasan eksklusif, jika mendukung pengecualian tersebut untuk aplikasi yang dapat diinstal pengguna.
Jika aplikasi sudah diinstal sebelumnya di perangkat dan belum pernah digunakan secara eksplisit oleh pengguna selama lebih dari 30 hari, [C-1-3] [C-1-5] dikecualikan.
Jika implementasi perangkat memperluas pembatasan aplikasi yang diimplementasikan di AOSP, implementasi tersebut:
- [C-2-1]HARUS mengikuti penerapan yang dijelaskan dalam dokumen ini.
3.5.2. Hibernasi Aplikasi
Jika implementasi perangkat menyertakan Hibernasi Aplikasi yang disertakan dalam AOSP atau memperluas fitur yang disertakan dalam AOSP, maka implementasi tersebut:
- [C-1-1] HARUS memenuhi semua persyaratan di bagian 3.5.1 kecuali [C-1-6] dan [C-1-3].
- [C-1-2] HARUS hanya menerapkan batasan pada aplikasi untuk pengguna jika ada bukti bahwa pengguna belum menggunakan aplikasi selama jangka waktu tertentu. Durasi ini SANGAT DISARANKAN untuk satu bulan atau lebih lama. Penggunaan HARUS ditentukan oleh interaksi pengguna eksplisit melalui UsageStats#getLastTimeVisible() API atau apa pun yang akan menyebabkan aplikasi keluar dari status dipaksa berhenti, termasuk binding layanan, binding penyedia konten, siaran eksplisit, dll., yang akan dilacak oleh API baru UsageStats#getLastTimeAnyComponentUsed().
- [C-1-3] HANYA BOLEH menerapkan batasan yang memengaruhi semua pengguna perangkat jika ada bukti bahwa paket belum digunakan oleh SETIAP pengguna selama beberapa periode waktu. DURASI INI SANGAT DIUJAMI untuk satu bulan atau lebih lama.
- [C-1-4] TIDAK BOLEH membuat aplikasi tidak dapat merespons intent aktivitas, binding layanan, permintaan penyedia konten, atau siaran vulgar.
Hibernasi Aplikasi di AOSP memenuhi persyaratan di atas.
3.6. Namespace API
Android mengikuti konvensi namespace paket dan class yang ditentukan oleh bahasa pemrograman Java. Untuk memastikan kompatibilitas dengan aplikasi pihak ketiga, penerapkan perangkat TIDAK BOLEH melakukan modifikasi yang dilarang (lihat di bawah) pada namespace paket ini:
java.*
javax.*
sun.*
android.*
androidx.*
com.android.*
Artinya, mereka:
- [C-0-1] TIDAK BOLEH mengubah API yang diekspos secara publik di platform Android dengan mengubah tanda tangan metode atau class, atau dengan menghapus class atau kolom class.
- [C-0-2] TIDAK BOLEH menambahkan elemen apa pun yang ditampilkan secara publik (seperti class atau antarmuka, atau kolom atau metode ke class atau antarmuka yang ada) atau API Pengujian atau Sistem ke API di namespace di atas. "Elemen yang ditampilkan secara publik" adalah konstruksi apa pun yang tidak dihiasi dengan penanda "@hide" seperti yang digunakan dalam kode sumber Android upstream.
Implementator perangkat DAPAT mengubah implementasi API yang mendasarinya, tetapi perubahan tersebut:
- [C-0-3] TIDAK BOLEH memengaruhi perilaku yang dinyatakan dan tanda tangan bahasa Java dari API apa pun yang ditampilkan secara publik.
- [C-0-4] TIDAK BOLEH diiklankan atau diekspos kepada developer.
Namun, pengimplementasi perangkat DAPAT menambahkan API kustom di luar namespace Android standar, tetapi API kustom tersebut:
- [C-0-5] TIDAK BOLEH berada dalam namespace yang dimiliki oleh atau merujuk ke organisasi
lain. Misalnya, pengimplementasi perangkat TIDAK BOLEH menambahkan API ke
com.google.*
atau namespace serupa: hanya Google yang dapat melakukannya. Demikian pula, Google TIDAK BOLEH menambahkan API ke namespace perusahaan lain. - [C-0-6] HARUS dikemas dalam library bersama Android sehingga hanya aplikasi yang menggunakannya secara eksplisit (melalui mekanisme <uses-library>) yang terpengaruh oleh peningkatan penggunaan memori API tersebut.
Implementator perangkat DAPAT menambahkan API kustom dalam bahasa native, di luar API NDK, tetapi API kustom:
- [C-1-1] TIDAK BOLEH berada di library NDK atau library yang dimiliki oleh organisasi lain seperti yang dijelaskan di sini.
Jika pengimplementasi perangkat mengusulkan untuk meningkatkan salah satu namespace paket di atas (seperti dengan menambahkan fungsi baru yang berguna ke API yang ada, atau menambahkan API baru), pengimplementasi HARUS mengunjungi source.android.com dan memulai proses untuk berkontribusi pada perubahan dan kode, sesuai dengan informasi di situs tersebut.
Perhatikan bahwa batasan di atas sesuai dengan konvensi standar untuk penamaan API dalam bahasa pemrograman Java; bagian ini hanya bertujuan untuk memperkuat konvensi tersebut dan membuatnya mengikat melalui penyertaan dalam Definisi Kompatibilitas ini.
3.7. Kompatibilitas Runtime
Implementasi perangkat:
[C-0-1] HARUS mendukung format Dalvik Executable (DEX) lengkap dan spesifikasi dan semantik bytecode Dalvik.
[C-0-2] HARUS mengonfigurasi runtime Dalvik untuk mengalokasikan memori sesuai dengan platform Android upstream, dan seperti yang ditentukan oleh tabel berikut. (Lihat bagian 7.1.1 untuk definisi ukuran layar dan kepadatan layar.)
HARUS menggunakan Android RunTime (ART), implementasi upstream referensi Format Eksekusi Dalvik, dan sistem pengelolaan paket implementasi referensi.
HARUS menjalankan pengujian fuzz dalam berbagai mode eksekusi dan arsitektur target untuk memastikan stabilitas runtime. Lihat JFuzz dan DexFuzz di situs Project Open Source Android.
Perhatikan bahwa nilai memori yang ditentukan di bawah dianggap sebagai nilai minimum dan implementasi perangkat DAPAT mengalokasikan lebih banyak memori per aplikasi.
Tata Letak Layar | Kepadatan Layar | Memori Aplikasi Minimum |
---|---|---|
Android Watch | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | ||
160 dpi (mdpi) | ||
180 dpi (180dpi) | ||
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | 36MB | |
240 dpi (hdpi) | ||
280 dpi (280dpi) | ||
320 dpi (xhdpi) | 48MB | |
360 dpi (360dpi) | ||
400 dpi (400dpi) | 56MB | |
420 dpi (420dpi) | 64MB | |
480 dpi (xxhdpi) | 88MB | |
560 dpi (560dpi) | 112MB | |
640 dpi (xxxhdpi) | 154MB | |
kecil/normal | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | ||
160 dpi (mdpi) | ||
180 dpi (180dpi) | 48MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280dpi) | ||
320 dpi (xhdpi) | 80MB | |
360 dpi (360dpi) | ||
400 dpi (400dpi) | 96MB | |
420 dpi (420dpi) | 112MB | |
480 dpi (xxhdpi) | 128MB | |
560 dpi (560dpi) | 192MB | |
640 dpi (xxxhdpi) | 256MB | |
large | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | 48MB | |
160 dpi (mdpi) | ||
180 dpi (180dpi) | 80MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280dpi) | 96MB | |
320 dpi (xhdpi) | 128MB | |
360 dpi (360dpi) | 160MB | |
400 dpi (400dpi) | 192MB | |
420 dpi (420dpi) | 228MB | |
480 dpi (xxhdpi) | 256MB | |
560 dpi (560dpi) | 384MB | |
640 dpi (xxxhdpi) | 512 MB | |
xlarge | 120 dpi (ldpi) | 48MB |
140 dpi (140dpi) | 80MB | |
160 dpi (mdpi) | ||
180 dpi (180dpi) | 96MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280dpi) | 144MB | |
320 dpi (xhdpi) | 192MB | |
360 dpi (360dpi) | 240MB | |
400 dpi (400dpi) | 288MB | |
420 dpi (420dpi) | 336MB | |
480 dpi (xxhdpi) | 384MB | |
560 dpi (560dpi) | 576MB | |
640 dpi (xxxhdpi) | 768MB |
3.8. Kompatibilitas Antarmuka Pengguna
3.8.1. Peluncur (Layar Utama)
Android menyertakan aplikasi peluncur (layar utama) dan dukungan untuk aplikasi pihak ketiga guna menggantikan peluncur perangkat (layar utama).
Jika implementasi perangkat mengizinkan aplikasi pihak ketiga untuk mengganti layar utama perangkat, aplikasi tersebut:
- [C-1-1] HARUS mendeklarasikan fitur platform
android.software.home_screen
. - [C-1-2] HARUS menampilkan objek
AdaptiveIconDrawable
saat aplikasi pihak ketiga menggunakan tag<adaptive-icon>
untuk menyediakan ikonnya, dan metodePackageManager
untuk mengambil ikon dipanggil.
Jika implementasi perangkat menyertakan peluncur default yang mendukung penyematan pintasan dalam aplikasi, peluncur tersebut:
- [C-2-1] HARUS melaporkan
true
untukShortcutManager.isRequestPinShortcutSupported()
. - [C-2-2] HARUS memiliki kemampuan pengguna yang meminta pengguna sebelum menambahkan pintasan yang diminta
oleh aplikasi melalui metode API
ShortcutManager.requestPinShortcut()
. - [C-2-3] HARUS mendukung pintasan yang disematkan serta pintasan dinamis dan statis seperti yang didokumentasikan di halaman Pintasan Aplikasi.
Sebaliknya, jika implementasi perangkat tidak mendukung penyematan pintasan dalam aplikasi, implementasi tersebut:
- [C-3-1] HARUS melaporkan
false
untukShortcutManager.isRequestPinShortcutSupported()
.
Jika implementasi perangkat menerapkan peluncur default yang memberikan akses cepat ke pintasan tambahan yang disediakan oleh aplikasi pihak ketiga melalui ShortcutManager API, aplikasi tersebut:
- [C-4-1] HARUS mendukung semua fitur pintasan yang didokumentasikan (misalnya pintasan statis dan
dinamis, menyematkan pintasan) dan sepenuhnya mengimplementasikan API
class API
ShortcutManager
.
Jika implementasi perangkat menyertakan aplikasi peluncur default yang menampilkan badge untuk ikon aplikasi, aplikasi tersebut:
- [C-5-1] HARUS mematuhi metode API
NotificationChannel.setShowBadge()
. Dengan kata lain, tampilkan kemampuan visual yang terkait dengan ikon aplikasi jika nilai ditetapkan sebagaitrue
, dan jangan tampilkan skema badge ikon aplikasi apa pun saat semua saluran notifikasi aplikasi telah menetapkan nilai sebagaifalse
. - DAPAT mengganti badge ikon aplikasi dengan skema badge eksklusifnya saat
aplikasi pihak ketiga menunjukkan dukungan terhadap skema badge eksklusif
melalui penggunaan API eksklusif, tetapi HARUS menggunakan resource dan nilai
yang disediakan melalui API badge notifikasi yang dijelaskan dalam SDK
, seperti
Notification.Builder.setNumber()
danNotification.Builder.setBadgeIconType()
API.
Jika implementasi perangkat mendukung ikon monokrom, ikon ini:
- [C-6-1] HANYA boleh digunakan jika pengguna mengaktifkannya secara eksplisit (misalnya melalui menu Setelan atau pemilih wallpaper).
3.8.2. Widget
Android mendukung widget aplikasi pihak ketiga dengan menentukan jenis komponen serta API dan siklus proses yang sesuai yang memungkinkan aplikasi mengekspos “AppWidget” kepada pengguna akhir.
Jika implementasi perangkat mendukung widget aplikasi pihak ketiga, widget tersebut:
- [C-1-1] HARUS mendeklarasikan dukungan untuk fitur platform
android.software.app_widgets
. [C-1-2] HARUS menyertakan dukungan bawaan untuk AppWidget dan mengekspos fitur antarmuka pengguna untuk menambahkan, mengonfigurasi, melihat, dan menghapus AppWidget
[C-1-3] HARUS dapat merender widget berukuran 4x4 dalam ukuran petak standar. Lihat Panduan Desain Widget Aplikasi di dokumentasi Android SDK untuk mengetahui detailnya.
DAPAT mendukung widget aplikasi di layar kunci.
Jika implementasi perangkat mendukung widget aplikasi pihak ketiga dan pemasangan pintasan dalam aplikasi, implementasi tersebut:
- [C-2-1] HARUS melaporkan
true
untukAppWidgetManager.html.isRequestPinAppWidgetSupported()
. - [C-2-2] HARUS memiliki kemampuan pengguna yang meminta pengguna sebelum menambahkan pintasan yang diminta
oleh aplikasi melalui metode API
AppWidgetManager.requestPinAppWidget()
.
3.8.3. Notifikasi
Android menyertakan API Notification
dan
NotificationManager
yang memungkinkan developer aplikasi pihak ketiga memberi tahu pengguna tentang peristiwa penting dan
menarik perhatian pengguna menggunakan komponen hardware (misalnya, suara, getaran
dan cahaya) serta fitur software (misalnya, panel notifikasi, panel sistem)
perangkat.
3.8.3.1. Presentasi Notifikasi
Jika implementasi perangkat mengizinkan aplikasi pihak ketiga untuk memberi tahu pengguna tentang peristiwa penting, aplikasi tersebut:
- [C-1-1] HARUS mendukung notifikasi yang menggunakan fitur hardware, seperti yang dijelaskan dalam dokumentasi SDK, dan sejauh mungkin dengan hardware penerapan perangkat. Misalnya, jika implementasi perangkat menyertakan vibrator, implementasi tersebut HARUS mengimplementasikan API getaran dengan benar. Jika implementasi perangkat tidak memiliki hardware, API yang sesuai HARUS diterapkan sebagai no-ops. Perilaku ini dijelaskan lebih lanjut di bagian 7.
- [C-1-2] HARUS merender semua resource (ikon, file animasi, dll.) yang disediakan di API, atau di panduan gaya ikon Status/Bilah Sistem, meskipun aplikasi tersebut DAPAT memberikan pengalaman pengguna alternatif untuk notifikasi daripada yang disediakan oleh implementasi Android Open Source referensi.
- [C-1-3] HARUS mematuhi dan menerapkan dengan benar perilaku yang dijelaskan untuk API guna memperbarui, menghapus, dan mengelompokkan notifikasi.
- [C-1-4] HARUS memberikan perilaku lengkap API NotificationChannel yang didokumentasikan dalam SDK.
- [C-1-5] HARUS memberikan kemampuan pengguna untuk memblokir dan mengubah notifikasi aplikasi pihak ketiga tertentu per setiap saluran dan tingkat paket aplikasi.
- [C-1-6] JUGA HARUS memberikan kemampuan pengguna untuk menampilkan saluran notifikasi yang dihapus.
[C-1-7] HARUS merender semua resource (gambar, stiker, ikon, dll.) dengan benar yang disediakan melalui Notification.MessagingStyle bersama dengan teks notifikasi tanpa interaksi pengguna tambahan. Misalnya, HARUS menampilkan semua resource termasuk ikon yang disediakan melalui android.app.Person dalam percakapan grup yang ditetapkan melalui setGroupConversation.
[C-SR-1] SANGAT DISARANKAN untuk memberikan kemampuan bagi pengguna untuk mengontrol notifikasi yang ditampilkan ke aplikasi yang telah diberi izin Pemroses Notifikasi. Tingkat perincian HARUS sedemikian rupa sehingga pengguna dapat mengontrol untuk setiap pemroses notifikasi tersebut jenis notifikasi apa yang dihubungkan ke pemroses ini. Jenisnya HARUS mencakup notifikasi "percakapan", "peringatan", "senyap", dan "persisten yang penting".
[C-SR-2] SANGAT DIUTAMAKAN untuk memberikan kemampuan bagi pengguna untuk menentukan aplikasi yang akan dikecualikan dari pemberitahuan pemroses notifikasi tertentu.
[C-SR-3] SANGAT DISARANKAN untuk otomatis menampilkan kemampuan pengguna untuk memblokir notifikasi aplikasi pihak ketiga tertentu per setiap saluran dan tingkat paket aplikasi setelah pengguna menutup notifikasi tersebut beberapa kali.
HARUS mendukung notifikasi yang dinamis.
HARUS menampilkan beberapa notifikasi prioritas yang lebih tinggi sebagai notifikasi pendahuluan.
HARUS memiliki kemampuan pengguna untuk menunda notifikasi.
HANYA boleh mengelola visibilitas dan waktu saat aplikasi pihak ketiga dapat memberi tahu pengguna tentang peristiwa penting untuk memitigasi masalah keamanan seperti gangguan pengemudi.
Android 11 memperkenalkan dukungan untuk notifikasi percakapan, yaitu notifikasi yang menggunakan MessagingStyle dan memberikan ID Pintasan Orang yang dipublikasikan.
Implementasi perangkat:
- [C-SR-4] SANGAT DISARANKAN untuk mengelompokkan dan menampilkan
conversation notifications
sebelum notifikasi non-percakapan, kecuali notifikasi layanan latar depan yang sedang berlangsung dan notifikasiimportance:high
.
Jika implementasi perangkat mendukung conversation notifications
dan aplikasi menyediakan data yang diperlukan untuk
bubbles
, keduanya:
- [C-SR-5] SANGAT DISARANKAN untuk menampilkan percakapan ini sebagai balon. Implementasi AOSP memenuhi persyaratan ini dengan UI Sistem, Setelan, dan Peluncur default.
Jika implementasi perangkat mendukung notifikasi lengkap, implementasi tersebut:
- [C-2-1] HARUS menggunakan resource yang sama persis seperti
yang disediakan melalui class API
Notification.Style
dan subclass-nya untuk elemen resource yang ditampilkan. - HARUS menampilkan setiap elemen resource (misalnya
ikon, judul, dan teks ringkasan) yang ditentukan dalam class API
Notification.Style
dan subclass-nya.
Notifikasi peringatan dini adalah notifikasi yang ditampilkan kepada pengguna saat notifikasi tersebut masuk secara terpisah dari platform yang digunakan pengguna. Jika implementasi perangkat mendukung notifikasi pra-notifikasi, perangkat tersebut:
- [C-3-1] HARUS menggunakan tampilan dan resource notifikasi peringatan dini
seperti yang dijelaskan dalam class API
Notification.Builder
saat notifikasi peringatan dini ditampilkan. - [C-3-2] HARUS menampilkan tindakan yang disediakan melalui
Notification.Builder.addAction()
bersama dengan konten notifikasi tanpa interaksi pengguna tambahan seperti yang dijelaskan dalam SDK.
3.8.3.2. Layanan Pemroses Notifikasi
Android menyertakan API NotificationListenerService
yang memungkinkan aplikasi (setelah diaktifkan secara eksplisit oleh pengguna) menerima salinan
semua notifikasi saat diposting atau diperbarui.
Implementasi perangkat:
- [C-0-1] HARUS memperbarui notifikasi secara keseluruhan dengan benar dan segera ke semua layanan pemroses yang diinstal dan diaktifkan pengguna, termasuk semua metadata yang dilampirkan ke objek Notifikasi.
- [C-0-2] HARUS mematuhi panggilan API
snoozeNotification()
, dan menutup notifikasi serta membuat callback setelah durasi tunda yang ditetapkan dalam panggilan API.
Jika implementasi perangkat memiliki kemampuan pengguna untuk menunda notifikasi, perangkat tersebut:
- [C-1-1] HARUS mencerminkan status notifikasi yang ditangguhkan dengan benar
melalui API standar seperti
NotificationListenerService.getSnoozedNotifications()
. - [C-1-2] HARUS menyediakan kemampuan pengguna ini untuk menunda notifikasi dari setiap aplikasi pihak ketiga yang diinstal, kecuali jika berasal dari layanan persisten/latar depan.
3.8.3.3. DND (Jangan Ganggu) / Mode Prioritas
Jika implementasi perangkat mendukung fitur DND (juga disebut Mode Prioritas), perangkat tersebut:
- [C-1-1] HARUS, jika penerapan perangkat telah menyediakan cara bagi pengguna untuk memberikan atau menolak aplikasi pihak ketiga agar dapat mengakses konfigurasi kebijakan DND, tampilkan Aturan DND otomatis yang dibuat oleh aplikasi bersama dengan aturan yang dibuat pengguna dan aturan standar.
- [C-1-3] HARUS mematuhi nilai
suppressedVisualEffects
yang diteruskan melaluiNotificationManager.Policy
dan jika aplikasi telah menetapkan salah satu flag SUPPRESSED_EFFECT_SCREEN_OFF atau SUPPRESSED_EFFECT_SCREEN_ON, aplikasi HARUS menunjukkan kepada pengguna bahwa efek visual dinonaktifkan di menu setelan DND.
3.8.4. Assist API
Android menyertakan Assist API untuk memungkinkan aplikasi memilih jumlah informasi konteks saat ini yang dibagikan dengan asisten di perangkat.
Jika implementasi perangkat mendukung tindakan Bantuan, tindakan tersebut:
- [C-2-1] HARUS menunjukkan dengan jelas kepada pengguna akhir saat konteks dibagikan, dengan
cara:
- Setiap kali aplikasi bantuan mengakses konteks, menampilkan cahaya putih di sekitar tepi layar yang memenuhi atau melebihi durasi dan kecerahan implementasi Project Open Source Android.
- Untuk aplikasi bantuan yang diinstal sebelumnya, memberikan kemampuan pengguna kurang dari dua navigasi dari menu setelan aplikasi asisten dan input suara default, dan hanya membagikan konteks saat aplikasi bantuan dipanggil secara eksplisit oleh pengguna melalui kata kunci panas atau input tombol navigasi bantuan.
- [C-2-2] Interaksi yang ditetapkan untuk meluncurkan aplikasi bantuan seperti yang dijelaskan
di bagian 7.2.3 HARUS meluncurkan aplikasi bantuan
yang dipilih pengguna, dengan kata lain aplikasi yang mengimplementasikan
VoiceInteractionService
, atau aktivitas yang menangani intentACTION_ASSIST
.
3.8.5. Notifikasi dan Toast
Aplikasi dapat menggunakan Toast
API untuk menampilkan string non-modal singkat kepada pengguna akhir yang menghilang setelah
jangka waktu singkat, dan menggunakan API jenis jendela TYPE_APPLICATION_OVERLAY
untuk menampilkan jendela pemberitahuan sebagai overlay di atas aplikasi lain.
Jika implementasi perangkat menyertakan output layar atau video, implementasi tersebut:
[C-1-1] HARUS memberikan kemampuan pengguna untuk memblokir aplikasi agar tidak menampilkan jendela peringatan yang menggunakan
TYPE_APPLICATION_OVERLAY
. Penerapan AOSP memenuhi persyaratan ini dengan memiliki kontrol di panel notifikasi.[C-1-2] HARUS mematuhi Toast API dan menampilkan Toast dari aplikasi kepada pengguna akhir dengan cara yang sangat terlihat.
3.8.6. Tema
Android menyediakan “tema” sebagai mekanisme bagi aplikasi untuk menerapkan gaya di seluruh Aktivitas atau aplikasi.
Android menyertakan keluarga tema “Holo” dan "Material" sebagai kumpulan gaya yang ditentukan untuk digunakan developer aplikasi jika mereka ingin mencocokkan tampilan dan nuansa tema Holo seperti yang ditentukan oleh Android SDK.
Jika implementasi perangkat menyertakan output layar atau video, implementasi tersebut:
- [C-1-1] TIDAK BOLEH mengubah atribut tema Holo yang ditampilkan ke aplikasi.
- [C-1-2] HARUS mendukung keluarga tema “Material” dan TIDAK BOLEH mengubah atribut tema Material atau asetnya yang ditampilkan ke aplikasi.
[C-1-3] HARUS menetapkan jenis font "sans-serif" ke Roboto versi 2.x untuk bahasa yang didukung Roboto, atau memberikan kemampuan pengguna untuk mengubah font yang digunakan untuk jenis font "sans-serif" ke Roboto versi 2.x untuk bahasa yang didukung Roboto.
[C-1-4] HARUS menghasilkan palet tonal warna dinamis seperti yang ditentukan dalam dokumentasi AOSP
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
(lihatandroid.theme.customization.system_palette
danandroid.theme.customization.theme_style
).[C-1-5] HARUS menghasilkan palet tonal warna dinamis menggunakan gaya tema warna yang dihitung dalam dokumentasi
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
(lihatandroid.theme.customization.theme_styles
), yaituTONAL_SPOT
,VIBRANT
,EXPRESSIVE
,SPRITZ
,RAINBOW
,FRUIT_SALAD
, , danMONOCHROMATIC
."Warna sumber" digunakan untuk membuat palet tone warna dinamis saat dikirim dengan
android.theme.customization.system_palette
(seperti yang didokumentasikan dalamSettings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
).[C-1-6] HARUS memiliki nilai kromatik
CAM16
sebesar 5 atau lebih besar.HARUS berasal dari wallpaper melalui
com.android.systemui.monet.ColorScheme#getSeedColors
, yang menyediakan beberapa warna sumber yang valid untuk dipilih.HARUS menggunakan nilai
0xFF1B6EF3
, jika tidak ada warna yang diberikan yang memenuhi persyaratan warna sumber di atas.
Android juga menyertakan keluarga tema “Device Default” sebagai kumpulan gaya yang ditentukan untuk digunakan developer aplikasi jika mereka ingin mencocokkan tampilan dan nuansa tema perangkat seperti yang ditentukan oleh pengimplementasi perangkat.
- Implementasi perangkat DAPAT mengubah Atribut tema Default Perangkat yang ditampilkan ke aplikasi.
Android mendukung tema varian dengan panel sistem transparan, yang memungkinkan developer aplikasi mengisi area di belakang status dan panel navigasi dengan konten aplikasi mereka. Untuk mengaktifkan pengalaman developer yang konsisten dalam konfigurasi ini, gaya ikon status bar harus dipertahankan di seluruh implementasi perangkat yang berbeda.
Jika implementasi perangkat menyertakan status bar sistem, implementasi tersebut:
- [C-2-1] HARUS menggunakan warna putih untuk ikon status sistem (seperti kekuatan sinyal dan tingkat baterai) serta notifikasi yang dikeluarkan oleh sistem, kecuali jika ikon menunjukkan status yang bermasalah atau aplikasi meminta status bar terang menggunakan tanda WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS.
- [C-2-2] Implementasi perangkat Android HARUS mengubah warna ikon status sistem menjadi hitam (untuk mengetahui detailnya, lihat R.style) saat aplikasi meminta status bar terang.
3.8.7. Wallpaper Animasi
Android menentukan jenis komponen serta API dan siklus proses yang sesuai yang memungkinkan aplikasi mengekspos satu atau beberapa “Wallpaper Animasi” kepada pengguna akhir. Wallpaper animasi adalah animasi, pola, atau gambar serupa dengan kemampuan input terbatas yang ditampilkan sebagai wallpaper, di belakang aplikasi lain.
Hardware dianggap mampu menjalankan wallpaper animasi dengan andal jika dapat menjalankan semua wallpaper animasi, tanpa batasan fungsi, pada kecepatan frame yang wajar tanpa efek samping pada aplikasi lain. Jika batasan dalam hardware menyebabkan wallpaper dan/atau aplikasi mengalami error, tidak berfungsi, menggunakan daya CPU atau baterai secara berlebihan, atau berjalan pada kecepatan frame yang tidak dapat diterima, hardware dianggap tidak dapat menjalankan wallpaper hidup. Misalnya, beberapa wallpaper hidup dapat menggunakan konteks OpenGL 2.0 atau 3.x untuk merender kontennya. Wallpaper hidup tidak akan berjalan dengan andal di hardware yang tidak mendukung beberapa konteks OpenGL karena penggunaan wallpaper hidup dari konteks OpenGL dapat bertentangan dengan aplikasi lain yang juga menggunakan konteks OpenGL.
- Implementasi perangkat yang mampu menjalankan wallpaper animasi dengan andal seperti yang dijelaskan di atas HARUS menerapkan wallpaper animasi.
Jika implementasi perangkat menerapkan wallpaper animasi, implementasi tersebut:
- [C-1-1] HARUS melaporkan flag fitur platform android.software.live_wallpaper.
3.8.8. Peralihan Aktivitas
Kode sumber Android upstream menyertakan layar ringkasan, antarmuka pengguna tingkat sistem untuk beralih tugas dan menampilkan aktivitas dan tugas yang baru-baru ini diakses menggunakan gambar thumbnail status grafis aplikasi pada saat pengguna terakhir kali keluar dari aplikasi.
Implementasi perangkat termasuk tombol navigasi fungsi terbaru seperti yang dijelaskan dalam bagian 7.2.3 DAPAT mengubah antarmuka.
Jika implementasi perangkat termasuk tombol navigasi fungsi terbaru seperti yang dijelaskan dalam bagian 7.2.3 mengubah antarmuka, implementasi tersebut:
- [C-1-1] HARUS mendukung minimal hingga 7 aktivitas yang ditampilkan.
- HARUS setidaknya menampilkan judul 4 aktivitas sekaligus.
- [C-1-2] HARUS menerapkan perilaku penyematan layar dan memberi pengguna menu setelan untuk mengaktifkan/menonaktifkan fitur.
- HARUS menampilkan warna sorotan, ikon, judul layar di terbaru.
- HARUS menampilkan kemampuan penutupan ("x") tetapi DAPAT menundanya hingga pengguna berinteraksi dengan layar.
- HARUS menerapkan pintasan untuk beralih dengan mudah ke aktivitas sebelumnya.
- HARUS memicu tindakan pengalihan cepat antara dua aplikasi yang baru saja digunakan, saat tombol fungsi terbaru diketuk dua kali.
- HARUS memicu mode multi-aplikasi layar terpisah, jika didukung, saat tombol fungsi terbaru ditekan lama.
- DAPAT menampilkan video terbaru yang berafiliasi sebagai grup yang bergerak bersama.
- [C-SR-1] SANGAT DISARANKAN untuk menggunakan antarmuka pengguna Android upstream (atau antarmuka berbasis thumbnail serupa) untuk layar ringkasan.
3.8.9. Pengelolaan Input
Android menyertakan dukungan untuk Pengelolaan Input dan dukungan untuk editor metode input pihak ketiga.
Jika implementasi perangkat memungkinkan pengguna menggunakan metode input pihak ketiga di perangkat, mereka:
- [C-1-1] HARUS mendeklarasikan fitur platform android.software.input_methods dan mendukung IME API seperti yang ditentukan dalam dokumentasi Android SDK.
3.8.10. Kontrol Media Layar Kunci
Remote Control Client API tidak digunakan lagi mulai Android 5.0 dan diganti dengan Template Notifikasi Media yang memungkinkan aplikasi media berintegrasi dengan kontrol pemutaran yang ditampilkan di layar kunci.
3.8.11. Screensaver (sebelumnya Dream)
Lihat bagian 3.2.3.5 untuk intent setelan guna mengonfigurasi screen saver.
3.8.12. Lokasi
Jika implementasi perangkat menyertakan sensor hardware (misalnya GPS) yang mampu memberikan koordinat lokasi, perangkat tersebut
- [C-1-2] HARUS menampilkan status lokasi saat ini di menu Lokasi dalam Setelan.
- [C-1-3] TIDAK BOLEH menampilkan mode lokasi di menu Lokasi dalam Setelan.
3.8.13. Unicode dan Font
Android menyertakan dukungan untuk karakter emoji yang ditentukan dalam Unicode 10.0.
Jika implementasi perangkat menyertakan output layar atau video, implementasi tersebut:
- [C-1-1] HARUS dapat merender karakter emoji ini dalam glyph warna.
- [C-1-2] HARUS menyertakan dukungan untuk:
- Font Roboto 2 dengan bobot yang berbeda—sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light untuk bahasa yang tersedia di perangkat.
- Cakupan Unicode 7.0 lengkap untuk Latin, Yunani, dan Sirilik, termasuk rentang Latin Extended A, B, C, dan D, serta semua glyph dalam blok simbol mata uang Unicode 7.0.
- [C-1-3] TIDAK BOLEH menghapus atau mengubah NotoColorEmoji.tff dalam image sistem. (Anda dapat menambahkan font emoji baru untuk mengganti emoji di NotoColorEmoji.tff)
- HARUS mendukung warna kulit dan emoji keluarga yang beragam seperti yang ditentukan dalam Laporan Teknis Unicode #51.
Jika implementasi perangkat menyertakan IME, implementasi tersebut:
- HARUS menyediakan metode input kepada pengguna untuk karakter emoji ini.
Android menyertakan dukungan untuk merender font Myanmar. Myanmar memiliki beberapa font yang tidak mematuhi Unicode, yang umumnya dikenal sebagai “Zawgyi”, untuk merender bahasa Myanmar.
Jika implementasi perangkat menyertakan dukungan untuk bahasa Burma, perangkat tersebut:
- [C-2-1] HARUS merender teks dengan font yang sesuai dengan Unicode sebagai default; font yang tidak sesuai dengan Unicode TIDAK BOLEH ditetapkan sebagai font default kecuali jika pengguna memilih font tersebut di pemilih bahasa.
- [C-2-2] HARUS mendukung font Unicode dan font yang mematuhi non-Unicode jika font yang mematuhi non-Unicode didukung di perangkat. Font yang tidak mematuhi Unicode TIDAK BOLEH menghapus atau menimpa font Unicode.
- [C-2-3] HARUS merender teks dengan font yang tidak mematuhi Unicode HANYA JIKA kode bahasa dengan kode skrip Qaag ditentukan (misalnya, my-Qaag). Tidak ada kode bahasa atau wilayah ISO lainnya (baik ditetapkan, tidak ditetapkan, atau dicadangkan) yang dapat digunakan untuk merujuk ke font yang tidak mematuhi Unicode untuk Myanmar. Developer aplikasi dan penulis halaman web dapat menentukan my-Qaag sebagai kode bahasa yang ditetapkan seperti yang mereka lakukan untuk bahasa lain.
3.8.14. Multi-aplikasi
Jika implementasi perangkat memiliki kemampuan untuk menampilkan beberapa aktivitas secara bersamaan, implementasi tersebut:
- [C-1-1] HARUS mengimplementasikan mode multi-aplikasi tersebut sesuai dengan perilaku aplikasi dan API yang dijelaskan dalam dokumentasi dukungan mode multi-aplikasi Android SDK dan memenuhi persyaratan berikut:
- [C-1-2] HARUS mematuhi
android:resizeableActivity
yang ditetapkan oleh aplikasi dalam fileAndroidManifest.xml
seperti yang dijelaskan dalam SDK ini. - [C-1-3] TIDAK BOLEH menawarkan mode layar terpisah atau bentuk bebas jika tinggi layar kurang dari 440 dp dan lebar layar kurang dari 440 dp.
- [C-1-4] Aktivitas TIDAK BOLEH diubah ukurannya menjadi lebih kecil dari 220dp dalam mode multi-aplikasi selain Picture-in-Picture.
- Implementasi perangkat dengan ukuran layar
xlarge
HARUS mendukung mode bebas.
Jika implementasi perangkat mendukung mode multi-aplikasi, dan mode layar terbagi, implementasi tersebut:
- [C-2-2] HARUS memangkas aktivitas yang di-dock dari multi-aplikasi layar terpisah, tetapi HARUS menampilkan beberapa kontennya, jika aplikasi Peluncur adalah jendela yang difokuskan.
- [C-2-3] HARUS mematuhi nilai
AndroidManifestLayout_minWidth
danAndroidManifestLayout_minHeight
yang dideklarasikan dari aplikasi peluncur pihak ketiga dan tidak mengganti nilai ini selama menampilkan beberapa konten aktivitas yang di-dock.
Jika implementasi perangkat mendukung mode multi-aplikasi dan mode multi-aplikasi Picture-in-Picture, implementasi tersebut:
- [C-3-1] HARUS meluncurkan aktivitas dalam mode multi-aplikasi picture-in-picture
saat aplikasi:
* Menargetkan API level 26 atau yang lebih tinggi dan mendeklarasikan
android:supportsPictureInPicture
* Menargetkan API level 25 atau yang lebih rendah dan mendeklarasikanandroid:resizeableActivity
danandroid:supportsPictureInPicture
. - [C-3-2] HARUS mengekspos tindakan di SystemUI seperti
yang ditentukan oleh aktivitas PIP saat ini melalui
setActions()
API. - [C-3-3] HARUS mendukung rasio aspek yang lebih besar dari atau sama dengan
1:2,39 dan kurang dari atau sama dengan 2,39:1, seperti yang ditentukan oleh aktivitas PIP melalui
setAspectRatio()
API. - [C-3-4] HARUS menggunakan
KeyEvent.KEYCODE_WINDOW
untuk mengontrol jendela PIP; jika mode PIP tidak diterapkan, kunci HARUS tersedia untuk aktivitas latar depan. - [C-3-5] HARUS menyediakan kemampuan pengguna untuk memblokir aplikasi agar tidak ditampilkan dalam mode PIP; implementasi AOSP memenuhi persyaratan ini dengan memiliki kontrol di panel notifikasi.
[C-3-6] HARUS mengalokasikan lebar dan tinggi minimum berikut untuk jendela PIP saat aplikasi tidak mendeklarasikan nilai apa pun untuk
AndroidManifestLayout_minWidth
danAndroidManifestLayout_minHeight
:- Perangkat dengan Configuration.uiMode yang ditetapkan selain
UI_MODE_TYPE_TELEVISION
HARUS mengalokasikan lebar dan tinggi minimum 108 dp. - Perangkat dengan Configuration.uiMode yang disetel ke
UI_MODE_TYPE_TELEVISION
HARUS mengalokasikan lebar minimum 240 dp dan tinggi minimum 135 dp.
- Perangkat dengan Configuration.uiMode yang ditetapkan selain
3.8.15. Potongan Layar
Android mendukung Display Cutout seperti yang dijelaskan
dalam dokumen SDK. DisplayCutout
API menentukan
area di tepi layar yang mungkin tidak berfungsi untuk aplikasi
karena potongan layar atau layar melengkung di tepi.
Jika implementasi perangkat menyertakan potongan layar, implementasi tersebut:
- [C-1-5] TIDAK BOLEH memiliki cutout jika rasio aspek perangkat adalah 1,0(1:1).
- [C-1-2] TIDAK BOLEH memiliki lebih dari satu cutout per tepi.
- [C-1-3] HARUS mematuhi flag cutout layar yang ditetapkan oleh aplikasi melalui
WindowManager.LayoutParams
API seperti yang dijelaskan dalam SDK. - [C-1-4] HARUS melaporkan nilai yang benar untuk semua metrik potongan yang ditentukan dalam
DisplayCutout
API.
3.8.16. Kontrol Perangkat
Android menyertakan API ControlsProviderService
dan Control
untuk memungkinkan aplikasi pihak ketiga memublikasikan kontrol perangkat untuk status
dan tindakan cepat bagi pengguna.
Lihat Bagian 2_2_3 untuk mengetahui persyaratan khusus perangkat.
3.8.17. Papan klip
Implementasi perangkat:
- [C-0-1] TIDAK BOLEH mengirim data papan klip ke komponen, aktivitas, layanan, atau melalui koneksi jaringan apa pun, tanpa tindakan pengguna yang jelas (misalnya, menekan tombol pada overlay) atau indikasi konten yang dikirim, kecuali untuk layanan yang disebutkan dalam 9.8.6 Perekaman Konten dan Penelusuran Aplikasi.
Jika implementasi perangkat menghasilkan pratinjau yang terlihat pengguna saat konten disalin
ke papan klip untuk item ClipData
apa pun dengan
ClipData.getDescription().getExtras()
berisi
android.content.extra.IS_SENSITIVE
, pratinjau tersebut:
- [C-1-1] HARUS menyamarkan pratinjau yang terlihat oleh pengguna
Implementasi referensi AOSP memenuhi persyaratan papan klip ini.
3.9. Administrasi Perangkat
Android menyertakan fitur yang memungkinkan aplikasi yang peka keamanan untuk melakukan fungsi administrasi perangkat di tingkat sistem, seperti menerapkan kebijakan sandi atau melakukan penghapusan total jarak jauh, melalui Android Device Administration API.
Jika implementasi perangkat menerapkan berbagai kebijakan administrasi perangkat yang ditentukan dalam dokumentasi Android SDK, implementasi tersebut:
- [C-1-1] HARUS mendeklarasikan
android.software.device_admin
. - [C-1-2] HARUS mendukung penyediaan pemilik perangkat seperti yang dijelaskan dalam bagian 3.9.1 dan bagian 3.9.1.1.
3.9.1 Penyediaan Perangkat
3.9.1.1 Penyediaan pemilik perangkat
Jika implementasi perangkat mendeklarasikan android.software.device_admin
, implementasi tersebut:
- [C-1-1] HARUS mendukung pendaftaran Klien Kebijakan Perangkat (DPC) sebagai
aplikasi Pemilik Perangkat
seperti yang dijelaskan di bawah:
- Jika implementasi perangkat tidak
mengonfigurasi pengguna maupun
data pengguna, implementasi tersebut:
- [C-1-5] HARUS mendaftarkan aplikasi DPC sebagai aplikasi Pemilik Perangkat
atau mengaktifkan aplikasi DPC untuk memilih apakah
akan menjadi Pemilik Perangkat atau Pemilik Profil,
jika perangkat mendeklarasikan dukungan Near-Field Communications (NFC) melalui
flag fitur
android.hardware.nfc
dan menerima pesan NFC yang berisi data dengan jenis MIMEMIME_TYPE_PROVISIONING_NFC
. - [C-1-8] HARUS mengirim intent ACTION_GET_PROVISIONING_MODE
setelah penyediaan Pemilik Perangkat dipicu sehingga
aplikasi DPC dapat memilih apakah akan menjadi Pemilik Perangkat atau Pemilik
Profil, bergantung pada nilai
android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES
, kecuali jika dapat ditentukan dari konteks bahwa hanya ada satu opsi yang valid. - [C-1-9] HARUS mengirim intent ACTION_ADMIN_POLICY_COMPLIANCE ke aplikasi Pemilik Perangkat jika Pemilik Perangkat dibuat selama penyediaan, terlepas dari metode penyediaan yang digunakan. Pengguna tidak boleh dapat melanjutkan di Wizard Penyiapan hingga aplikasi Pemilik Perangkat selesai.
- [C-1-5] HARUS mendaftarkan aplikasi DPC sebagai aplikasi Pemilik Perangkat
atau mengaktifkan aplikasi DPC untuk memilih apakah
akan menjadi Pemilik Perangkat atau Pemilik Profil,
jika perangkat mendeklarasikan dukungan Near-Field Communications (NFC) melalui
flag fitur
- Jika implementasi perangkat memiliki
pengguna atau
data pengguna, implementasi tersebut:
- [C-1-7] TIDAK BOLEH mendaftarkan aplikasi DPC apa pun sebagai Aplikasi Pemilik Perangkat lagi.
- Jika implementasi perangkat tidak
mengonfigurasi pengguna maupun
data pengguna, implementasi tersebut:
[C-1-2] HARUS menampilkan pemberitahuan pengungkapan yang sesuai (seperti yang dirujuk dalam AOSP) dan mendapatkan izin afirmatif dari pengguna akhir sebelum aplikasi ditetapkan sebagai Pemilik Perangkat, kecuali jika perangkat dikonfigurasi secara terprogram untuk Mode Demo Retail sebelum interaksi pengguna akhir di layar. Jika implementasi perangkat mendeklarasikan
android.software.device_admin
, tetapi juga menyertakan solusi pengelolaan perangkat eksklusif dan menyediakan mekanisme untuk mempromosikan aplikasi yang dikonfigurasi dalam solusi mereka sebagai "Pemilik Perangkat yang setara" dengan "Pemilik Perangkat" standar seperti yang diakui oleh API DevicePolicyManager Android standar, API tersebut:[C-2-1] HARUS memiliki proses untuk memverifikasi bahwa aplikasi tertentu yang dipromosikan adalah milik solusi pengelolaan perangkat perusahaan yang sah dan telah dikonfigurasi dalam solusi eksklusif agar memiliki hak yang setara sebagai "Pemilik Perangkat".
[C-2-2] HARUS menampilkan pengungkapan izin Pemilik Perangkat AOSP yang sama dengan alur yang dimulai oleh
android.app.action.PROVISION_MANAGED_DEVICE
sebelum mendaftarkan aplikasi DPC sebagai "Pemilik Perangkat".[C-2-3] TIDAK BOLEH melakukan hard code izin atau mencegah penggunaan aplikasi pemilik perangkat lainnya.
3.9.1.2 Penyediaan profil terkelola
Jika implementasi perangkat mendeklarasikan android.software.managed_users
, implementasi tersebut:
[C-1-1] HARUS mengimplementasikan API yang memungkinkan aplikasi Pengontrol Kebijakan Perangkat (DPC) menjadi pemilik Profil Terkelola baru.
[C-1-2] Proses penyediaan profil terkelola (alur yang dimulai oleh DPC menggunakan android.app.action.PROVISION_MANAGED_PROFILE) atau oleh platform), layar izin, dan pengalaman pengguna HARUS selaras dengan penerapan AOSP.
[C-1-3] HARUS menyediakan kemampuan pengguna berikut dalam Setelan untuk menunjukkan kepada pengguna saat fungsi sistem tertentu telah dinonaktifkan oleh Pengontrol Kebijakan Perangkat (DPC):
- Ikon yang konsisten atau kemampuan pengguna lainnya (misalnya ikon info AOSP upstream) untuk menunjukkan kapan setelan tertentu dibatasi oleh Pengelola Perangkat.
- Pesan penjelasan singkat, seperti yang diberikan oleh Admin Perangkat melalui
setShortSupportMessage
. - Ikon aplikasi DPC.
[C-1-4] HARUS meluncurkan pengendali untuk intent ACTION_PROVISIONING_SUCCESSFUL di profil kerja jika Pemilik Profil dibuat saat penyediaan dimulai oleh intent android.app.action.PROVISION_MANAGED_PROFILE dan DPC telah menerapkan pengendali.
[C-1-5] HARUS mengirim siaran ACTION_PROFILE_PROVISIONING_COMPLETE ke DPC profil kerja saat penyediaan dimulai oleh intent android.app.action.PROVISION_MANAGED_PROFILE.
[C-1-6] HARUS mengirim intent ACTION_GET_PROVISIONING_MODE setelah penyediaan pemilik profil dipicu sehingga aplikasi DPC dapat memilih apakah akan menjadi Pemilik Perangkat atau Pemilik Profil, kecuali jika penyediaan dipicu oleh intent android.app.action.PROVISION_MANAGED_PROFILE.
[C-1-7] HARUS mengirim intent ACTION_ADMIN_POLICY_COMPLIANCE ke profil kerja saat Pemilik Profil dibuat selama penyediaan, terlepas dari metode penyediaan yang digunakan, kecuali saat penyediaan dipicu oleh intent android.app.action.PROVISION_MANAGED_PROFILE. Pengguna tidak boleh dapat melanjutkan di Wizard Penyiapan hingga aplikasi Pemilik Profil selesai.
[C-1-8] HARUS mengirim siaran ACTION_MANAGED_PROFILE_PROVISIONED ke DPC profil pribadi saat Pemilik Profil dibuat, terlepas dari metode penyediaan yang digunakan.
3.9.2 Dukungan Profil Terkelola
Jika implementasi perangkat mendeklarasikan android.software.managed_users
, implementasi tersebut:
- [C-1-1] HARUS mendukung profil terkelola melalui API
android.app.admin.DevicePolicyManager
. - [C-1-2] HARUS mengizinkan satu dan hanya satu profil terkelola yang dibuat.
- [C-1-3] HARUS menggunakan badge ikon (mirip dengan badge kerja upstream AOSP) untuk mewakili aplikasi dan widget terkelola serta elemen UI berbadge lainnya seperti Terbaru & Notifikasi.
- [C-1-4] HARUS menampilkan ikon notifikasi (mirip dengan badge kerja upstream AOSP) untuk menunjukkan saat pengguna berada dalam aplikasi profil terkelola.
- [C-1-5] HARUS menampilkan toast yang menunjukkan bahwa pengguna berada dalam profil terkelola jika dan saat perangkat aktif (ACTION_USER_PRESENT) dan aplikasi latar depan berada dalam profil terkelola.
- [C-1-6] Jika profil terkelola ada, HARUS menampilkan kemampuan visual di 'Pemilih' Intent untuk memungkinkan pengguna meneruskan intent dari profil terkelola ke pengguna utama atau sebaliknya, jika diaktifkan oleh Pengontrol Kebijakan Perangkat.
- [C-1-7] Jika profil terkelola ada, HARUS mengekspos kemampuan
pengguna berikut untuk pengguna utama dan profil terkelola:
- Akuntansi terpisah untuk penggunaan baterai, lokasi, data seluler, dan penyimpanan untuk pengguna utama dan profil terkelola.
- Pengelolaan Aplikasi VPN independen yang diinstal dalam pengguna utama atau profil terkelola.
- Pengelolaan independen aplikasi yang diinstal dalam pengguna utama atau profil terkelola.
- Pengelolaan akun secara independen dalam profil pengguna utama atau terkelola.
- [C-1-8] HARUS memastikan aplikasi dialer, kontak, dan pesan yang diinstal sebelumnya dapat menelusuri dan mencari informasi pemanggil dari profil terkelola (jika ada) bersama dengan informasi dari profil utama, jika Pengontrol Kebijakan Perangkat mengizinkannya.
- [C-1-9] HARUS memastikan bahwa profil tersebut memenuhi semua persyaratan keamanan yang berlaku untuk perangkat dengan beberapa pengguna yang diaktifkan (lihat bagian 9.5), meskipun profil terkelola tidak dihitung sebagai pengguna lain selain pengguna utama.
Memulai persyaratan baru
- [C-1-10] HARUS memastikan bahwa data screenshot disimpan di penyimpanan
profil kerja saat screenshot diambil dengan
jendela
topActivity
yang memiliki fokus (yang terakhir berinteraksi dengan pengguna di antara semua aktivitas) dan merupakan milik aplikasi profil kerja. - [C-1-11] TIDAK BOLEH mengambil konten layar lainnya (panel sistem, notifikasi, atau konten profil pribadi apa pun) kecuali untuk jendela/jendela aplikasi profil kerja saat menyimpan screenshot ke profil kerja (untuk memastikan bahwa data profil pribadi tidak disimpan di profil kerja).
Akhiri persyaratan baru
Jika implementasi perangkat mendeklarasikan android.software.managed_users
dan
android.software.secure_lock_screen
, implementasi tersebut:
- [C-2-1] HARUS mendukung kemampuan untuk menentukan layar kunci terpisah yang memenuhi
persyaratan berikut untuk memberikan akses ke aplikasi yang hanya berjalan di
profil terkelola.
- Implementasi perangkat HARUS mematuhi intent
DevicePolicyManager.ACTION_SET_NEW_PASSWORD
dan menampilkan antarmuka untuk mengonfigurasi kredensial layar kunci terpisah untuk profil terkelola. - Kredensial layar kunci dari profil terkelola HARUS menggunakan mekanisme penyimpanan dan pengelolaan kredensial yang sama dengan profil induk, seperti yang didokumentasikan di Situs Project Open Source Android.
- Kebijakan sandi DPC
HARUS hanya berlaku untuk kredensial layar kunci profil terkelola, kecuali jika
dipanggil pada instance
DevicePolicyManager
yang ditampilkan oleh getParentProfileInstance.
- Implementasi perangkat HARUS mematuhi intent
- Saat kontak dari profil terkelola ditampilkan dalam log panggilan bawaan, UI dalam panggilan, notifikasi panggilan yang sedang berlangsung dan terlewat, kontak, dan aplikasi pesan, kontak tersebut HARUS diberi badge dengan badge yang sama yang digunakan untuk menunjukkan aplikasi profil terkelola.
3.9.3 Dukungan Pengguna Terkelola
Jika implementasi perangkat mendeklarasikan android.software.managed_users
, implementasi tersebut:
- [C-1-1] HARUS memberikan kemampuan pengguna untuk logout dari pengguna saat ini dan
beralih kembali ke pengguna utama dalam sesi beberapa pengguna saat
isLogoutEnabled
menampilkantrue
. Affordance pengguna HARUS dapat diakses dari layar kunci tanpa membuka kunci perangkat.
Jika implementasi perangkat mendeklarasikan android.software.device_admin
dan menyediakan
affordance pengguna di perangkat untuk menambahkan Pengguna sekunder tambahan, implementasi tersebut:
- [C-SR-1] SANGAT DISARANKAN untuk menampilkan pengungkapan izin Pemilik Perangkat AOSP yang sama dengan yang ditampilkan dalam alur yang dimulai oleh android.app.action.PROVISION_MANAGED_DEVICE, sebelum mengizinkan akun ditambahkan di Pengguna sekunder baru, sehingga pengguna memahami bahwa perangkat dikelola.
3.9.4 Persyaratan Peran Pengelolaan Kebijakan Perangkat
Jika implementasi perangkat melaporkan android.software.device_admin
atau
android.software.managed_users
, implementasi tersebut:
- [C-1-1] HARUS mendukung peran pengelolaan kebijakan perangkat seperti yang ditentukan dalam
bagian 9.1. Aplikasi yang memiliki peran pengelolaan kebijakan perangkat
DAPAT ditentukan dengan menetapkan
config_devicePolicyManagement
ke nama paket. Nama paket HARUS diikuti dengan:
dan sertifikat penandatanganan, kecuali jika aplikasi dipramuat.
Jika nama paket tidak ditentukan untuk config_devicePolicyManagement
seperti
yang dijelaskan di atas:
- [C-2-1] Implementasi perangkat HARUS mendukung penyediaan tanpa aplikasi pemegang peran pengelolaan kebijakan perangkat (AOSP menyediakan implementasi referensi).
Jika nama paket ditentukan untuk config_devicePolicyManagement
seperti yang dijelaskan
di atas:
- [C-3-1] Aplikasi HARUS diinstal di semua profil untuk pengguna.
- [C-3-2] Implementasi perangkat DAPAT menentukan aplikasi yang memperbarui
holder peran pengelolaan kebijakan perangkat sebelum penyediaan dengan menetapkan
config_devicePolicyManagementUpdater
.
Jika nama paket ditentukan untuk config_devicePolicyManagementUpdater
seperti
yang dijelaskan di atas:
- [C-4-1] Aplikasi HARUS diprainstal di perangkat.
- [C-4-2] Aplikasi HARUS menerapkan filter intent yang me-resolve
android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER
.
Memulai persyaratan baru
3.9.5 Framework Penyelesaian Kebijakan Perangkat
Jika implementasi perangkat melaporkan android.software.device_admin
atau
android.software.managed_users
, implementasi tersebut:
- [C-1-1] HARUS menyelesaikan konflik kebijakan perangkat seperti yang didokumentasikan dalam Framework Penyelesaian Kebijakan Perangkat.
Akhiri persyaratan baru
3.10. Aksesibilitas
Android menyediakan lapisan aksesibilitas yang membantu pengguna difabel menavigasi perangkat mereka dengan lebih mudah. Selain itu, Android menyediakan API platform yang memungkinkan implementasi layanan aksesibilitas menerima callback untuk peristiwa pengguna dan sistem serta menghasilkan mekanisme masukan alternatif, seperti teks ke ucapan, masukan haptik, dan navigasi trackball/d-pad.
Jika implementasi perangkat mendukung layanan aksesibilitas pihak ketiga, implementasi tersebut:
- [C-1-1] HARUS menyediakan implementasi framework aksesibilitas Android seperti yang dijelaskan dalam dokumentasi SDK API aksesibilitas.
- [C-1-2] HARUS menghasilkan peristiwa aksesibilitas dan mengirimkan
AccessibilityEvent
yang sesuai ke semua penerapanAccessibilityService
yang terdaftar seperti yang didokumentasikan dalam SDK. - [C-1-4] HARUS memberikan kemampuan pengguna untuk mengontrol layanan aksesibilitas yang mendeklarasikan AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON. Perhatikan bahwa untuk implementasi perangkat dengan menu navigasi sistem, HARUS memungkinkan pengguna memiliki opsi untuk tombol di menu navigasi sistem guna mengontrol layanan ini.
Jika implementasi perangkat menyertakan layanan aksesibilitas bawaan, layanan tersebut:
- [C-2-1] HARUS menerapkan layanan aksesibilitas bawaan ini sebagai aplikasi Direct Boot Aware saat penyimpanan data dienkripsi dengan Enkripsi Berbasis File (FBE).
- HARUS menyediakan mekanisme dalam alur penyiapan siap pakai bagi pengguna untuk mengaktifkan layanan aksesibilitas yang relevan, serta opsi untuk menyesuaikan ukuran font, ukuran tampilan, dan gestur pembesaran.
3.11. Text-to-Speech
Android menyertakan API yang memungkinkan aplikasi menggunakan layanan text-to-speech (TTS) dan memungkinkan penyedia layanan untuk menyediakan implementasi layanan TTS.
Jika implementasi perangkat melaporkan fitur android.hardware.audio.output, perangkat tersebut:
- [C-1-1] HARUS mendukung API framework TTS Android.
Jika implementasi perangkat mendukung penginstalan mesin TTS pihak ketiga, implementasi tersebut:
- [C-2-1] HARUS memberikan kemampuan pengguna untuk memungkinkan pengguna memilih mesin TTS untuk digunakan di tingkat sistem.
3.12. Framework Input TV
Android Television Input Framework (TIF) menyederhanakan pengiriman konten live ke perangkat Android Television. TIF menyediakan API standar untuk membuat modul input yang mengontrol perangkat Android Television.
Jika implementasi perangkat mendukung TIF, implementasi tersebut:
- [C-1-1] HARUS mendeklarasikan fitur platform
android.software.live_tv
. - [C-1-2] HARUS mendukung semua TIF API sehingga aplikasi yang menggunakan API ini dan layanan input berbasis TIF pihak ketiga dapat diinstal dan digunakan di perangkat.
3.13. Setelan Cepat
Android menyediakan komponen UI Setelan Cepat yang memungkinkan akses cepat ke tindakan yang sering digunakan atau sangat diperlukan.
Jika implementasi perangkat menyertakan komponen UI Setelan Cepat dan mendukung Setelan Cepat pihak ketiga, implementasi tersebut:
- [C-1-1] HARUS mengizinkan pengguna menambahkan atau menghapus kartu yang disediakan melalui
API
quicksettings
dari aplikasi pihak ketiga. - [C-1-2] TIDAK BOLEH menambahkan kartu dari aplikasi pihak ketiga secara otomatis langsung ke Setelan Cepat.
- [C-1-3] HARUS menampilkan semua kartu yang ditambahkan pengguna dari aplikasi pihak ketiga bersama dengan kartu setelan cepat yang disediakan sistem.
3.14. UI Media
Jika implementasi perangkat menyertakan aplikasi yang tidak diaktifkan suara (Aplikasi) yang berinteraksi dengan
aplikasi pihak ketiga melalui MediaBrowser
atau MediaSession
,
Aplikasi tersebut:
[C-1-2] HARUS menampilkan ikon yang diperoleh melalui
getIconBitmap()
ataugetIconUri()
dan judul yang diperoleh melaluigetTitle()
dengan jelas seperti yang dijelaskan dalamMediaDescription
. Dapat mempersingkat judul untuk mematuhi peraturan keselamatan (misalnya, gangguan pengemudi).[C-1-3] HARUS menampilkan ikon aplikasi pihak ketiga setiap kali menampilkan konten yang disediakan oleh aplikasi pihak ketiga ini.
[C-1-4] HARUS memungkinkan pengguna berinteraksi dengan seluruh hierarki
MediaBrowser
. DAPAT membatasi akses ke bagian hierarki untuk mematuhi peraturan keamanan (misalnya, gangguan pengemudi), tetapi TIDAK BOLEH memberikan perlakuan istimewa berdasarkan konten atau penyedia konten.[C-1-5] HARUS mempertimbangkan ketuk dua kali
KEYCODE_HEADSETHOOK
atauKEYCODE_MEDIA_PLAY_PAUSE
sebagaiKEYCODE_MEDIA_NEXT
untukMediaSession.Callback#onMediaButtonEvent
.
3.15. Aplikasi Instan
Jika implementasi perangkat mendukung Aplikasi Instan, implementasi tersebut HARUS memenuhi persyaratan berikut:
- [C-1-1] Aplikasi Instan HANYA BOLEH diberi izin yang menetapkan
android:protectionLevel
ke"instant"
. - [C-1-2] Aplikasi Instan TIDAK BOLEH berinteraksi dengan aplikasi terinstal melalui intent implisit
kecuali jika salah satu dari hal berikut benar:
- Filter pola intent komponen diekspos dan memiliki CATEGORY_BROWSABLE
- Tindakannya adalah salah satu dari ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
- Target diekspos secara eksplisit dengan android:visibleToInstantApps
- [C-1-3] Instant App TIDAK BOLEH berinteraksi secara eksplisit dengan aplikasi terinstal kecuali jika komponen diekspos melalui android:visibleToInstantApps.
- [C-1-4] Aplikasi Terinstal TIDAK BOLEH melihat detail tentang Aplikasi Instan di perangkat, kecuali jika Aplikasi Instan terhubung secara eksplisit ke aplikasi terinstal.
Implementasi perangkat HARUS menyediakan kemampuan pengguna berikut untuk berinteraksi dengan Aplikasi Instan. AOSP memenuhi persyaratan dengan UI Sistem, Setelan, dan Peluncur default. Implementasi perangkat:
- [C-1-5] HARUS memberikan kemampuan pengguna untuk melihat dan menghapus Aplikasi Instan yang di-cache secara lokal untuk setiap paket aplikasi.
- [C-1-6] HARUS memberikan notifikasi pengguna persisten yang dapat
ditutup saat Aplikasi Instan berjalan di latar depan. Notifikasi
pengguna ini HARUS menyertakan bahwa Aplikasi Instan tidak memerlukan penginstalan
dan memberikan kemampuan pengguna yang mengarahkan pengguna ke layar
info aplikasi di Setelan. Untuk Aplikasi Instan yang diluncurkan melalui intent web, seperti
yang ditentukan dengan menggunakan intent dengan tindakan yang ditetapkan ke
Intent.ACTION_VIEW
dan dengan skema "http" atau "https", kemampuan pengguna tambahan HARUS memungkinkan pengguna untuk tidak meluncurkan Aplikasi Instan dan meluncurkan link terkait dengan browser web yang dikonfigurasi, jika browser tersedia di perangkat. - [C-1-7] HARUS mengizinkan Aplikasi Instan yang sedang berjalan diakses dari fungsi Terbaru jika fungsi Terbaru tersedia di perangkat.
[C-1-8] HARUS memuat ulang satu atau beberapa aplikasi atau komponen layanan dengan pengendali intent untuk intent yang tercantum dalam SDK di sini dan membuat intent terlihat untuk Aplikasi Instan.
3.16. Penyandingan Perangkat Pendamping
Android menyertakan dukungan untuk penyambungan perangkat pendamping guna mengelola
asosiasi dengan perangkat pendamping secara lebih efektif dan menyediakan CompanionDeviceManager
API bagi aplikasi untuk mengakses fitur ini.
Jika implementasi perangkat mendukung fitur penyambungan perangkat pendamping, implementasi tersebut:
- [C-1-1] HARUS mendeklarasikan flag fitur
FEATURE_COMPANION_DEVICE_SETUP
. - [C-1-2] HARUS memastikan API dalam paket
android.companion
diterapkan sepenuhnya. - [C-1-3] HARUS memberikan kemampuan pengguna bagi pengguna untuk memilih/mengonfirmasi bahwa perangkat pendamping ada dan beroperasi.
3.17. Aplikasi Berat
Jika implementasi perangkat mendeklarasikan fitur FEATURE_CANT_SAVE_STATE
,
maka:
- [C-1-1] HARUS hanya memiliki satu aplikasi terinstal yang menentukan
cantSaveState
yang berjalan di sistem dalam satu waktu. Jika pengguna meninggalkan aplikasi tersebut tanpa keluar secara eksplisit (misalnya dengan menekan tombol layar utama saat meninggalkan aktivitas aktif di sistem, bukan menekan kembali tanpa aktivitas aktif yang tersisa di sistem), maka implementasi perangkat HARUS memprioritaskan aplikasi tersebut di RAM seperti yang dilakukan untuk hal lain yang diharapkan tetap berjalan, seperti layanan latar depan. Saat aplikasi tersebut berada di latar belakang, sistem masih dapat menerapkan fitur pengelolaan daya ke aplikasi tersebut, seperti membatasi CPU dan akses jaringan. - [C-1-2] HARUS menyediakan kemampuan UI untuk memilih aplikasi yang tidak akan
berpartisipasi dalam mekanisme penyimpanan/pemulihan status normal setelah pengguna
meluncurkan aplikasi kedua yang dideklarasikan dengan atribut
cantSaveState
. - [C-1-3] TIDAK BOLEH menerapkan perubahan kebijakan lainnya pada aplikasi yang menentukan
cantSaveState
, seperti mengubah performa CPU atau mengubah prioritas penjadwalan.
Jika implementasi perangkat tidak mendeklarasikan fitur
FEATURE_CANT_SAVE_STATE
,
maka:
- [C-1-1] HARUS mengabaikan atribut
cantSaveState
yang ditetapkan oleh aplikasi dan TIDAK BOLEH mengubah perilaku aplikasi berdasarkan atribut tersebut.
3.18. Kontak
Android menyertakan
Contacts Provider
API untuk memungkinkan aplikasi mengelola informasi kontak yang disimpan di perangkat.
Data kontak yang dimasukkan langsung ke dalam perangkat biasanya disinkronkan
dengan layanan web, tetapi data tersebut JUGA MUNGKIN hanya berada secara lokal di perangkat.
Kontak yang hanya disimpan di perangkat disebut sebagai kontak
lokal.
RawContacts "dikaitkan dengan" atau "disimpan di"
Account
jika kolom
ACCOUNT_NAME
,
dan
ACCOUNT_TYPE
,
untuk kontak mentah cocok dengan kolom
Account.name
dan
Account.type
akun yang sesuai.
Akun lokal default: akun untuk kontak mentah yang hanya disimpan di
perangkat dan tidak dikaitkan dengan Akun di
AccountManager,
yang dibuat dengan nilai null untuk
kolom
ACCOUNT_NAME
,
dan
ACCOUNT_TYPE
.
Akun lokal kustom: akun untuk kontak mentah yang hanya disimpan di
perangkat dan tidak dikaitkan dengan Akun di AccountManager, yang
dibuat dengan setidaknya satu nilai non-null untuk
kolom
ACCOUNT_NAME
,
dan
ACCOUNT_TYPE
.
Implementasi perangkat:
- [C-SR-1] SANGAT DISARANKAN untuk tidak membuat akun lokal kustom.
Jika implementasi perangkat menggunakan akun lokal kustom:
- [C-1-1]
ACCOUNT_NAME
dari akun lokal kustom HARUS ditampilkan olehContactsContract.RawContacts.getLocalAccountName
- [C-1-2]
ACCOUNT_TYPE
dari akun lokal kustom HARUS ditampilkan olehContactsContract.RawContacts.getLocalAccountType
- [C-1-3] Kontak mentah yang disisipkan oleh aplikasi pihak ketiga dengan
akun lokal default (yaitu dengan menetapkan nilai null untuk
ACCOUNT_NAME
danACCOUNT_TYPE
) HARUS disisipkan ke akun lokal kustom. - [C-1-4] Kontak mentah yang disisipkan ke akun lokal kustom TIDAK BOLEH dihapus saat akun ditambahkan atau dihapus.
- [C-1-5] Operasi penghapusan yang dilakukan terhadap akun lokal kustom
HARUS mengakibatkan kontak mentah segera dihapus (seolah-olah
parameter
CALLER_IS_SYNCADAPTER
ditetapkan ke true), meskipun parameterCALLER\_IS\_SYNCADAPTER
ditetapkan ke false atau tidak ditentukan.
4. Kompatibilitas Pengemasan Aplikasi
Implementasi perangkat:
[C-0-1] HARUS dapat menginstal dan menjalankan file ".apk" Android seperti yang dihasilkan oleh alat "aapt" yang disertakan dalam Android SDK resmi.
- Karena persyaratan di atas mungkin sulit, implementasi perangkat DIANJURKAN untuk menggunakan sistem pengelolaan paket implementasi referensi AOSP.
[C-0-2] HARUS mendukung verifikasi file ".apk" menggunakan APK Signature Scheme v3.1, APK Signature Scheme v3, APK Signature Scheme v2 dan penandatanganan JAR.
[C-0-3] TIDAK BOLEH memperluas format .apk, Manifes Android, bytecode Dalvik, atau bytecode RenderScript sedemikian rupa sehingga mencegah file tersebut diinstal dan berjalan dengan benar di perangkat lain yang kompatibel.
[C-0-4] TIDAK BOLEH mengizinkan aplikasi selain "penginstal data" saat ini untuk paket meng-uninstal aplikasi secara diam-diam tanpa konfirmasi pengguna, seperti yang didokumentasikan dalam SDK untuk izin
DELETE_PACKAGE
. Satu-satunya pengecualian adalah aplikasi verifier paket sistem yang menangani intent PACKAGE_NEEDS_VERIFICATION dan aplikasi pengelola penyimpanan yang menangani intent ACTION_MANAGE_STORAGE.[C-0-5] HARUS memiliki aktivitas yang menangani intent
android.settings.MANAGE_UNKNOWN_APP_SOURCES
.[C-0-6] TIDAK BOLEH menginstal paket aplikasi dari sumber yang tidak dikenal, kecuali jika aplikasi yang meminta penginstalan memenuhi semua persyaratan berikut:
- Aplikasi HARUS mendeklarasikan izin
REQUEST_INSTALL_PACKAGES
atau menetapkanandroid:targetSdkVersion
ke 24 atau lebih rendah. - Aplikasi HARUS telah diberi izin oleh pengguna untuk menginstal aplikasi dari sumber yang tidak dikenal.
- Aplikasi HARUS mendeklarasikan izin
HARUS memberikan kemampuan pengguna untuk memberikan/membatalkan izin untuk menginstal aplikasi dari sumber yang tidak dikenal per aplikasi, tetapi DAPAT memilih untuk menerapkan hal ini sebagai tidak ada operasi dan menampilkan
RESULT_CANCELED
untukstartActivityForResult()
, jika implementasi perangkat tidak ingin mengizinkan pengguna memiliki pilihan ini. Namun, meskipun dalam kasus tersebut, aplikasi HARUS menunjukkan kepada pengguna alasan tidak ada pilihan tersebut.[C-0-7] HARUS menampilkan dialog peringatan dengan string peringatan yang disediakan melalui API sistem
PackageManager.setHarmfulAppWarning
kepada pengguna sebelum meluncurkan aktivitas dalam aplikasi yang telah ditandai oleh API sistemPackageManager.setHarmfulAppWarning
yang sama sebagai berpotensi berbahaya.HARUS memberikan kemampuan pengguna untuk memilih meng-uninstal atau meluncurkan aplikasi di dialog peringatan.
[C-0-8] HARUS mengimplementasikan dukungan untuk Sistem File Inkremental seperti yang didokumentasikan di sini.
[C-0-9] HARUS mendukung verifikasi file .apk menggunakan APK Signature Scheme v4 dan APK Signature Scheme v4.1.
5. Kompatibilitas Multimedia
Implementasi perangkat:
- [C-0-1] HARUS mendukung format media, encoder, decoder, jenis file,
dan format penampung yang ditentukan dalam bagian 5.1
untuk setiap codec yang dideklarasikan oleh
MediaCodecList
. - [C-0-2] HARUS mendeklarasikan dan melaporkan dukungan encoder, decoder yang tersedia
untuk aplikasi pihak ketiga melalui
MediaCodecList
. - [C-0-3] HARUS dapat mendekode dengan benar dan menyediakan semua format yang dapat dienkodenya kepada
aplikasi pihak ketiga. Hal ini mencakup semua bitstream yang dihasilkan
encoder dan profil yang dilaporkan dalam
CamcorderProfile
.
Implementasi perangkat:
- HARUS menargetkan latensi codec minimum, dengan kata lain,
- TIDAK BOLEH menggunakan dan menyimpan buffer input serta menampilkan buffer input hanya setelah diproses.
- TIDAK BOLEH menyimpan buffering yang didekode lebih lama dari yang ditentukan oleh standar (misalnya, SPS).
- TIDAK BOLEH menyimpan buffering yang dienkode lebih lama dari yang diperlukan oleh struktur GOP.
Semua codec yang tercantum di bagian bawah disediakan sebagai implementasi software dalam implementasi Android yang diinginkan dari Proyek Open Source Android.
Perlu diperhatikan bahwa baik Google maupun Open Handset Alliance tidak membuat pernyataan apa pun bahwa codec ini bebas dari paten pihak ketiga. Bagi mereka yang ingin menggunakan kode sumber ini dalam produk hardware atau software, sebaiknya implementasi kode ini, termasuk dalam software open source atau shareware, mungkin memerlukan lisensi paten dari pemegang paten yang relevan.
5.1. Codec Media
5.1.1. Encoding Audio
Lihat detail selengkapnya di 5.1.3. Detail Codec Audio.
Jika implementasi perangkat mendeklarasikan android.hardware.microphone
,
perangkat HARUS mendukung encoding format audio berikut dan menyediakannya
ke aplikasi pihak ketiga:
- [C-1-1] PCM/WAVE
- [C-1-2] FLAC
- [C-1-3] Opus
Semua encoder audio HARUS mendukung:
- [C-3-1] Frame audio urutan byte native PCM 16-bit melalui API
android.media.MediaCodec
.
5.1.2. Dekode Audio
Lihat detail selengkapnya di 5.1.3. Detail Codec Audio.
Jika implementasi perangkat mendeklarasikan dukungan untuk
fitur android.hardware.audio.output
, implementasi tersebut harus mendukung decoding
format audio berikut:
- [C-1-1] Profil AAC MPEG-4 (AAC LC)
- [C-1-2] Profil MPEG-4 HE AAC (AAC+)
- [C-1-3] Profil MPEG-4 HE AACv2 (AAC+ yang ditingkatkan)
- [C-1-4] AAC ELD (AAC yang ditingkatkan dengan delay rendah)
- [C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile, yang mencakup Profil Dasar Pengukuran USAC, dan ISO/IEC 23003-4 Dynamic Range Control Profile)
- [C-1-5] FLAC
- [C-1-6] MP3
- [C-1-7] MIDI
- [C-1-8] Vorbis
- [C-1-9] PCM/WAVE termasuk format audio resolusi tinggi hingga 24 bit, frekuensi sampel 192 kHz, dan 8 saluran. Perhatikan bahwa persyaratan ini hanya untuk dekode, dan perangkat diizinkan untuk melakukan downsampling dan downmix selama fase pemutaran.
- [C-1-10] Opus
Jika implementasi perangkat mendukung dekode buffer input AAC dari
streaming multisaluran (yaitu lebih dari dua saluran) ke PCM melalui decoder
audio AAC default di android.media.MediaCodec
API, hal berikut HARUS
didukung:
- [C-2-1] Dekode HARUS dilakukan tanpa downmix (misalnya, streaming AAC 5.0 harus didekode ke lima saluran PCM, streaming AAC 5.1 harus didekode ke enam saluran PCM).
- [C-2-2] Metadata rentang dinamis HARUS seperti yang ditentukan dalam "Dynamic Range Control
(DRC)" di ISO/IEC 14496-3, dan kunci DRC
android.media.MediaFormat
untuk mengonfigurasi perilaku terkait rentang dinamis dari decoder audio. Kunci DRC AAC diperkenalkan di API 21, dan terdiri dari:KEY_AAC_DRC_ATTENUATION_FACTOR
,KEY_AAC_DRC_BOOST_FACTOR
,KEY_AAC_DRC_HEAVY_COMPRESSION
,KEY_AAC_DRC_TARGET_REFERENCE_LEVEL
, danKEY_AAC_ENCODED_TARGET_LEVEL
. - [C-SR-1] SANGAT DISARANKAN agar persyaratan C-2-1 dan C-2-2 di atas dipenuhi oleh semua dekoder audio AAC.
Saat mendekode audio USAC, MPEG-D (ISO/IEC 23003-4):
- [C-3-1] Metadata volume dan DRC HARUS ditafsirkan dan diterapkan sesuai dengan Profil Kontrol Rentang Dinamis MPEG-D DRC Level 1.
- [C-3-2] Dekoder HARUS berperilaku sesuai dengan konfigurasi
yang ditetapkan dengan kunci
android.media.MediaFormat
berikut:KEY_AAC_DRC_TARGET_REFERENCE_LEVEL
danKEY_AAC_DRC_EFFECT_TYPE
.
Dekoder profil MPEG-4 AAC, HE AAC, dan HE AACv2:
- DAPAT mendukung kontrol volume dan rentang dinamis menggunakan Profil Kontrol Rentang Dinamis ISO/IEC 23003-4.
Jika ISO/IEC 23003-4 didukung dan jika metadata ISO/IEC 23003-4 dan ISO/IEC 14496-3 ada dalam bitstream yang didekode, maka:
- Metadata ISO/IEC 23003-4 HARUS diutamakan.
Semua dekoder audio HARUS mendukung output:
- [C-6-1] Frame audio urutan byte native PCM 16-bit melalui API
android.media.MediaCodec
.
Jika implementasi perangkat mendukung dekode buffer input AAC dari
streaming multisaluran (yaitu lebih dari dua saluran) ke PCM melalui decoder
audio AAC default di android.media.MediaCodec
API, hal berikut HARUS
didukung:
- [C-7-1] HARUS dapat dikonfigurasi oleh aplikasi menggunakan decoding
dengan kunci
KEY_MAX_OUTPUT_CHANNEL_COUNT
untuk mengontrol apakah konten didownmix ke stereo (saat menggunakan nilai 2) atau output menggunakan jumlah saluran native (saat menggunakan nilai yang sama dengan atau lebih besar dari angka tersebut). Misalnya, nilai 6 atau lebih akan mengonfigurasi dekoder untuk menghasilkan 6 saluran saat diberi konten 5.1. - [C-7-2] Saat mendekode, dekoder HARUS mengiklankan mask saluran yang digunakan
pada format output dengan
kunci
KEY_CHANNEL_MASK
, menggunakan konstantaandroid.media.AudioFormat
(contoh:CHANNEL_OUT_5POINT1
).
Jika implementasi perangkat mendukung dekoder audio selain dekoder audio AAC default dan mampu menghasilkan output audio multisaluran (yaitu lebih dari 2 saluran) saat diberi konten multisaluran yang dikompresi, maka:
- [C-SR-2] Decoder SANGAT DISARANKAN agar dapat dikonfigurasi oleh
aplikasi yang menggunakan decoding dengan kunci
KEY_MAX_OUTPUT_CHANNEL_COUNT
untuk mengontrol apakah konten didownmix ke stereo (saat menggunakan nilai 2) atau di-output menggunakan jumlah saluran native (saat menggunakan nilai yang sama dengan atau lebih besar dari angka tersebut). Misalnya, nilai 6 atau lebih akan mengonfigurasi dekoder untuk menghasilkan 6 saluran saat diberi konten 5.1. - [C-SR-3] Saat mendekode, dekoder SANGAT DISARANKAN untuk mengiklankan
mask saluran yang digunakan pada format output dengan
kunci
KEY_CHANNEL_MASK
, menggunakan konstanta android.media.AudioFormat (contoh:CHANNEL_OUT_5POINT1
).
5.1.3. Detail Codec Audio
Format/Codec | Detail | Jenis File/Format Penampung yang akan didukung |
---|---|---|
Profil AAC MPEG-4 (AAC LC) |
Dukungan untuk konten mono/stereo/5.0/5.1 dengan frekuensi pengambilan sampel standar dari 8 hingga 48 kHz. |
|
Profil MPEG-4 HE AAC (AAC+) | Dukungan untuk konten mono/stereo/5.0/5.1 dengan frekuensi pengambilan sampel standar dari 16 hingga 48 kHz. |
|
Profil MPEG-4 HE AACv2 (AAC+ ditingkatkan) |
Dukungan untuk konten mono/stereo/5.0/5.1 dengan frekuensi pengambilan sampel standar dari 16 hingga 48 kHz. |
|
AAC ELD (AAC yang ditingkatkan dengan delay rendah) | Dukungan untuk konten mono/stereo dengan frekuensi pengambilan sampel standar dari 16 hingga 48 kHz. |
|
USAC | Dukungan untuk konten mono/stereo dengan frekuensi pengambilan sampel standar dari 7,35 hingga 48 kHz. | MPEG-4 (.mp4, .m4a) |
AMR-NB | 4,75 hingga 12,2 kbps dengan sampel @ 8 kHz | 3GPP (.3gp) |
AMR-WB | 9 frekuensi dari 6,60 kbit/dtk hingga 23,85 kbit/dtk dengan sampel @ 16 kHz, seperti yang ditentukan di AMR-WB, Adaptive Multi-Rate - Wideband Speech Codec | 3GPP (.3gp) |
FLAC | Untuk encoder dan decoder: setidaknya mode Mono dan Stereo HARUS didukung. Frekuensi sampel hingga 192 kHz HARUS didukung; resolusi 16-bit dan 24-bit HARUS didukung. Penanganan data audio FLAC 24-bit HARUS tersedia dengan konfigurasi audio floating point. |
|
MP3 | Mono/Stereo 8-320 Kbps konstan (CBR) atau kecepatan bit variabel (VBR) |
|
MIDI | MIDI Jenis 0 dan 1. DLS Versi 1 dan 2. XMF dan Mobile XMF. Dukungan untuk format nada dering RTTTL/RTX, OTA, dan iMelody |
|
Vorbis | Dekode: Dukungan untuk konten mono, stereo, 5.0, dan 5.1 dengan frekuensi sampling
8.000, 12.000, 16.000, 24.000, dan 48.000 Hz. Encoding: Dukungan untuk konten mono dan stereo dengan frekuensi sampling 8.000, 12.000, 16.000, 24.000, dan 48.000 Hz. |
|
PCM/WAVE | Codec PCM HARUS mendukung PCM linear 16-bit dan float 16-bit. Ekstraktor WAVE harus mendukung PCM linear 16-bit, 24-bit, 32-bit, dan float 32-bit (frekuensi hingga batas hardware). Frekuensi sampel HARUS didukung dari 8 kHz hingga 192 kHz. | WAVE (.wav) |
Opus | Dekode: Dukungan untuk konten mono, stereo, 5.0, dan 5.1
dengan frekuensi sampling 8.000, 12.000, 16.000, 24.000, dan 48.000 Hz.
Encoding: Dukungan untuk konten mono dan stereo dengan frekuensi sampling 8.000, 12.000, 16.000, 24.000, dan 48.000 Hz. |
|
5.1.4. Encoding Gambar
Lihat detail selengkapnya di 5.1.6. Detail Codec Gambar.
Implementasi perangkat HARUS mendukung encoding encoding gambar berikut:
- [C-0-1] JPEG
- [C-0-2] PNG
- [C-0-3] WebP
Memulai persyaratan baru
- [C-0-4] AVIF
- Perangkat harus mendukung
BITRATE_MODE_CQ
dan Profil Dasar Pengukuran.
- Perangkat harus mendukung
Akhiri persyaratan baru
Jika implementasi perangkat mendukung encoding HEIC melalui android.media.MediaCodec
untuk jenis media MIMETYPE_IMAGE_ANDROID_HEIC
,
perangkat tersebut:
- [C-1-1] HARUS menyediakan codec encoder HEVC yang dipercepat hardware yang
mendukung
mode kontrol bitrate
BITRATE_MODE_CQ
, profilHEVCProfileMainStill
, dan ukuran frame 512 x 512 piksel.
5.1.5. Dekode Gambar
Lihat detail selengkapnya di 5.1.6. Detail Codec Gambar.
Implementasi perangkat HARUS mendukung decoding encoding gambar berikut:
- [C-0-1] JPEG
- [C-0-2] GIF
- [C-0-3] PNG
- [C-0-4] BMP
- [C-0-5] WebP
- [C-0-6] Mentah
- [C-0-7] AVIF (Profil Dasar Pengukuran)
Jika implementasi perangkat mendukung decoding video HEVC, implementasi tersebut: * [C-1-1] HARUS mendukung decoding gambar HEIF (HEIC).
Dekoder gambar yang mendukung format kedalaman bit tinggi (9+ bit per saluran):
- [C-2-1] HARUS mendukung output format yang setara 8-bit jika diminta oleh
aplikasi, misalnya, melalui konfigurasi
ARGB_8888
android.graphics.Bitmap
.
5.1.6. Detail Codec Gambar
Format/Codec | Detail | Jenis File/Format Penampung yang Didukung |
---|---|---|
JPEG | Dasar+progresif | JPEG (.jpg) |
GIF | GIF (.gif) | |
PNG | PNG (.png) | |
BMP | BMP (.bmp) | |
WebP | WebP (.webp) | |
Raw | ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw) | |
HEIF | Gambar, Koleksi gambar, Urutan gambar | HEIF (.heif), HEIC (.heic) |
AVIF (Profil Dasar Pengukuran) | Profil Dasar Pengukuran Gambar, Kumpulan gambar, Urutan gambar | Penampung HEIF (.avif) |
Encoder dan decoder gambar yang diekspos melalui MediaCodec API
[C-1-1] HARUS mendukung format warna fleksibel YUV420 8:8:8 (
COLOR_FormatYUV420Flexible
) melaluiCodecCapabilities
.[C-SR-1] SANGAT DIUJAMI untuk mendukung format warna RGB888 untuk mode Surface input.
[C-1-3] HARUS mendukung setidaknya salah satu format warna YUV420 8:8:8 planar atau semiplanar:
COLOR_FormatYUV420PackedPlanar
(setara denganCOLOR_FormatYUV420Planar
) atauCOLOR_FormatYUV420PackedSemiPlanar
(setara denganCOLOR_FormatYUV420SemiPlanar
). Format ini SANGAT DIUJAMI untuk mendukung keduanya.
5.1.7. Codec Video
- Untuk kualitas streaming video web dan layanan konferensi video yang dapat diterima, implementasi perangkat HARUS menggunakan codec VP8 hardware yang memenuhi persyaratan.
Jika implementasi perangkat menyertakan decoder atau encoder video:
[C-1-1] Codec video HARUS mendukung ukuran bytebuffer output dan input yang menampung frame terkompresi dan tidak terkompresi terbesar yang memungkinkan seperti yang ditentukan oleh standar dan konfigurasi, tetapi juga tidak mengalokasikan secara berlebihan.
[C-1-2] Encoder dan decoder video HARUS mendukung format warna fleksibel YUV420 8:8:8 (
COLOR_FormatYUV420Flexible
) melaluiCodecCapabilities
.[C-1-3] Encoder dan dekoder video HARUS mendukung minimal salah satu format warna YUV420 8:8:8 planar atau semiplanar:
COLOR_FormatYUV420PackedPlanar
(setara denganCOLOR_FormatYUV420Planar
) atauCOLOR_FormatYUV420PackedSemiPlanar
(setara denganCOLOR_FormatYUV420SemiPlanar
). Sebaiknya keduanya didukung.[C-SR-1] Encoder dan decoder video SANGAT DIUJUDKAN untuk mendukung setidaknya salah satu format warna YUV420 8:8:8 planar atau semiplanar yang dioptimalkan hardware (YV12, NV12, NV21, atau format yang dioptimalkan vendor yang setara.)
[C-1-5] Dekoder video yang mendukung format kedalaman bit tinggi (9+ bit per saluran) HARUS mendukung output format yang setara dengan 8-bit jika diminta oleh aplikasi. Hal ini HARUS tercermin dengan mendukung format warna YUV420 8:8:8 melalui
android.media.MediaCodecInfo
.
Jika implementasi perangkat mengiklankan dukungan profil HDR melalui
Display.HdrCapabilities
,
perangkat tersebut:
- [C-2-1] HARUS mendukung penguraian dan penanganan metadata statis HDR.
Jika implementasi perangkat mengiklankan dukungan intra refresh melalui
FEATURE_IntraRefresh
di class
MediaCodecInfo.CodecCapabilities
, implementasi tersebut:
- [C-3-1] HARUS mendukung periode refresh dalam rentang 10 - 60 frame dan beroperasi secara akurat dalam 20% periode refresh yang dikonfigurasi.
Kecuali jika aplikasi menentukan sebaliknya menggunakan kunci format
KEY_COLOR_FORMAT
, implementasi decoder video:
- [C-4-1] HARUS ditetapkan secara default ke format warna yang dioptimalkan untuk tampilan hardware jika dikonfigurasi menggunakan output Platform.
- [C-4-2] HARUS ditetapkan secara default ke format warna YUV420 8:8:8 yang dioptimalkan untuk pembacaan CPU jika dikonfigurasi untuk tidak menggunakan output Platform.
5.1.8. Daftar Codec Video
Format/Codec | Detail | Jenis File/Format Penampung yang akan didukung |
---|---|---|
H.263 |
|
|
H.264 AVC | Lihat bagian 5.2 dan 5.3 untuk mengetahui detailnya |
|
H.265 HEVC | Lihat bagian 5.3 untuk mengetahui detailnya |
|
MPEG-2 | Profil Utama |
|
MPEG-4 SP |
|
|
VP8 | Lihat bagian 5.2 dan 5.3 untuk mengetahui detailnya |
|
VP9 | Lihat bagian 5.3 untuk mengetahui detailnya |
|
AV1 | Lihat pasal 5.2 dan pasal 5.3 untuk mengetahui detailnya |
|
5.1.9. Keamanan Codec Media
Implementasi perangkat HARUS memastikan kepatuhan terhadap fitur keamanan codec media seperti yang dijelaskan di bawah.
Android menyertakan dukungan untuk OMX, API akselerasi multimedia lintas platform, serta Codec 2.0, API akselerasi multimedia dengan overhead rendah.
Jika implementasi perangkat mendukung multimedia, implementasi tersebut:
- [C-1-1] HARUS menyediakan dukungan untuk codec media melalui OMX atau Codec 2.0 API (atau keduanya) seperti dalam Project Open Source Android dan tidak menonaktifkan atau mengelakkan perlindungan keamanan. Hal ini secara khusus tidak berarti bahwa setiap codec HARUS menggunakan OMX atau Codec 2.0 API, hanya bahwa dukungan untuk setidaknya salah satu API ini HARUS tersedia, dan dukungan untuk API yang tersedia HARUS menyertakan perlindungan keamanan yang ada.
- [C-SR-1] SANGAT DISARANKAN untuk menyertakan dukungan untuk Codec 2.0 API.
Jika implementasi perangkat tidak mendukung Codec 2.0 API, implementasi tersebut:
- [C-2-1] HARUS menyertakan codec software OMX yang sesuai dari Project Open Source Android (jika tersedia) untuk setiap format dan jenis media (enkoder atau dekoder) yang didukung oleh perangkat.
- [C-2-2] Codec yang memiliki nama yang diawali dengan "OMX.google". HARUS didasarkan pada kode sumber Project Open Source Android.
- [C-SR-2] SANGAT DISARANKAN agar codec software OMX berjalan dalam proses codec yang tidak memiliki akses ke driver hardware selain pemetaan memori.
Jika implementasi perangkat mendukung Codec 2.0 API, implementasi tersebut:
- [C-3-1] HARUS menyertakan codec software Codec 2.0 yang sesuai dari Project Open Source Android (jika tersedia) untuk setiap format dan jenis media (enkoder atau dekoder) yang didukung oleh perangkat.
- [C-3-2] HARUS menyimpan codec software Codec 2.0 dalam proses codec software seperti yang disediakan dalam Project Open Source Android untuk memungkinkan akses yang lebih sempit ke codec software.
- [C-3-3] Codec yang memiliki nama yang diawali dengan "c2.android". HARUS didasarkan pada kode sumber Project Open Source Android.
5.1.10. Karakterisasi Codec Media
Jika implementasi perangkat mendukung codec media, implementasi tersebut:
- [C-1-1] HARUS menampilkan nilai yang benar dari karakterisasi codec media melalui
API
MediaCodecInfo
.
Khususnya:
- [C-1-2] Codec dengan nama yang diawali dengan "OMX". HARUS menggunakan OMX API dan memiliki nama yang sesuai dengan pedoman penamaan OMX IL.
- [C-1-3] Codec dengan nama yang diawali dengan "c2". HARUS menggunakan Codec 2.0 API dan memiliki nama yang sesuai dengan pedoman penamaan Codec 2.0 untuk Android.
- [C-1-4] Codec dengan nama yang diawali dengan "OMX.google." atau "c2.android." TIDAK HARUS dikarakterisasi sebagai vendor atau sebagai hardware-accelerated.
- [C-1-5] Codec yang berjalan dalam proses codec (vendor atau sistem) yang memiliki akses ke driver hardware selain alokator dan pemetaan memori TIDAK BOLEH dikarakterisasi sebagai khusus software.
- [C-1-6] Codec yang tidak ada dalam Project Open Source Android atau tidak didasarkan pada kode sumber dalam project tersebut HARUS dikarakterisasi sebagai vendor.
- [C-1-7] Codec yang menggunakan akselerasi hardware HARUS dikarakterisasi sebagai akselerasi hardware.
- [C-1-8] Nama codec TIDAK BOLEH menyesatkan. Misalnya, codec bernama "decoder" HARUS mendukung decoding, dan codec bernama "encoder" HARUS mendukung encoding. Codec dengan nama yang berisi format media HARUS mendukung format tersebut.
Jika implementasi perangkat mendukung codec video:
- [C-2-1] Semua codec video HARUS memublikasikan data kecepatan frame yang dapat dicapai untuk ukuran berikut jika didukung oleh codec:
SD (kualitas rendah) | SD (kualitas tinggi) | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|---|
Resolusi video |
|
|
|
1920x1080 piksel (selain MPEG4, AV1) | 3840x2160 piksel (HEVC, VP9, AV1) |
- [C-2-2] Codec video yang dikarakterisasi sebagai akselerasi hardware HARUS
memublikasikan informasi poin performa. Setiap API HARUS mencantumkan semua poin performa standar
yang didukung (tercantum dalam
PerformancePoint
API), kecuali jika tercakup dalam poin performa standar lain yang didukung. - Selain itu, mereka HARUS memublikasikan poin performa yang diperluas jika mendukung performa video yang berkelanjutan selain salah satu poin standar yang tercantum.
5.2. Encoding Video
- TIDAK BOLEH, selama dua periode geser, lebih dari 15% dari kecepatan bit antara interval intraframe (I-frame).
- TIDAK BOLEH lebih dari 100% dari kecepatan bit selama periode geser 1 detik.
Memulai persyaratan baru
Jika implementasi perangkat mendukung encoder video dan menyediakannya untuk aplikasi pihak ketiga, serta menetapkanMediaFormat.KEY_BITRATE_MODE
ke
BITRATE_MODE_VBR
sehingga encoder beroperasi dalam mode Kecepatan bit variabel, maka, selama
tidak memengaruhi nilai minimum kualitas,
kecepatan bit yang dienkode :
[C-5-1] HARUSTIDAK BOLEH, selama satu periode geser, lebih dari 15% di atas kecepatan bit antara interval intraframe (I-frame).[C-5-2] HARUSSEHARUSNYA TIDAK lebih dari 100% di atas kecepatan bit selama periode geser 1 detik.
Jika implementasi perangkat mendukung encoder video dan menyediakannya untuk
aplikasi pihak ketiga serta menetapkan
MediaFormat.KEY_BITRATE_MODE
ke
BITRATE_MODE_CBR
sehingga encoder beroperasi dalam mode kecepatan bit konstan, kecepatan bit yang dienkode:
[C-6-1] HARUS[C-SR-2] SANGAT DISARANKAN untuk TIDAK melebihi 15% dari kecepatan bit target selama periode 1 detik.
Akhiri persyaratan baru
Jika implementasi perangkat menyertakan tampilan layar tersemat dengan
panjang diagonal minimal 2,5 inci atau menyertakan port output video atau
mendeklarasikan dukungan kamera melalui flag fitur
android.hardware.camera.any
, perangkat tersebut:
- [C-1-1] HARUS menyertakan dukungan setidaknya salah satu encoder video VP8 atau H.264, dan menyediakannya untuk aplikasi pihak ketiga.
- HARUS mendukung encoder video VP8 dan H.264, serta menyediakannya untuk aplikasi pihak ketiga.
Jika implementasi perangkat mendukung encoder video H.264, VP8, VP9, atau HEVC dan menyediakannya untuk aplikasi pihak ketiga, implementasi tersebut:
- [C-2-1] HARUS mendukung bitrate yang dapat dikonfigurasi secara dinamis.
- HARUS mendukung kecepatan frame variabel, dengan encoder video HARUS menentukan durasi frame instan berdasarkan stempel waktu buffering input, dan mengalokasikan bucket bitnya berdasarkan durasi frame tersebut.
Jika implementasi perangkat mendukung encoder video MPEG-4 SP dan menyediakannya untuk aplikasi pihak ketiga, implementasi tersebut:
- HARUS mendukung kecepatan bit yang dapat dikonfigurasi secara dinamis untuk encoder yang didukung.
Jika implementasi perangkat menyediakan encoder video atau gambar yang dipercepat hardware,
dan mendukung satu atau beberapa kamera hardware yang terpasang atau dapat dicolokkan yang ditampilkan melalui
API android.camera
:
- [C-4-1] semua encoder video dan gambar dengan akselerasi hardware HARUS mendukung frame encoding dari kamera hardware.
- HARUS mendukung frame encoding dari kamera hardware melalui semua encoder video atau gambar.
Jika implementasi perangkat menyediakan encoding HDR, implementasi tersebut:
- [C-SR-1] SANGAT DISARANKAN untuk menyediakan plugin bagi API transcoding yang lancar untuk mengonversi dari format HDR ke format SDR.
5.2.1. H.263
Jika implementasi perangkat mendukung encoder H.263 dan menyediakannya ke aplikasi pihak ketiga, implementasi tersebut:
- [C-1-1] HARUS mendukung resolusi QCIF (176 x 144) menggunakan Profil Dasar Pengukuran Level 45. Resolusi SQCIF bersifat opsional.
HARUS mendukung kecepatan bit yang dapat dikonfigurasi secara dinamis untuk encoder yang didukung.
5.2.2. H.264
Jika penerapan perangkat mendukung codec H.264, perangkat tersebut:
- [C-1-1] HARUS mendukung Profil Dasar Pengukuran Level 3. Namun, dukungan untuk ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering), dan RS (Redundant Slices) bersifat OPSIONAL. Selain itu, untuk mempertahankan kompatibilitas dengan perangkat Android lainnya, sebaiknya ASO, FMO, dan RS tidak digunakan untuk Profil Dasar Pengukuran oleh encoder.
- [C-1-2] HARUS mendukung profil encoding video SD (Definisi Standar) dalam tabel berikut.
- HARUS mendukung Profil Utama Level 4.
- HARUS mendukung profil encoding video HD (High Definition) seperti yang ditunjukkan dalam tabel berikut.
Jika implementasi perangkat melaporkan dukungan encoding H.264 untuk video resolusi 720p atau 1080p melalui API media, implementasi tersebut:
- [C-2-1] HARUS mendukung profil encoding dalam tabel berikut.
SD (Kualitas rendah) | SD (Kualitas tinggi) | HD 720p | HD 1080p | |
---|---|---|---|---|
Resolusi video | 320 x 240 piksel | 720 x 480 piksel | 1280 x 720 px | 1920 x 1080 px |
Frekuensi gambar video | 20 fps | 30 fps | 30 fps | 30 fps |
Kecepatan bit video | 384 Kbps | 2 Mbps | 4 Mbps | 10 Mbps |
5.2.3. VP8
Jika implementasi perangkat mendukung codec VP8, perangkat tersebut:
- [C-1-1] HARUS mendukung profil encoding video SD.
- HARUS mendukung profil encoding video HD (High Definition) berikut.
- [C-1-2] HARUS mendukung penulisan file WebM Matroska.
- HARUS menyediakan codec VP8 hardware yang memenuhi persyaratan coding hardware RTC project WebM, untuk memastikan kualitas streaming video web dan layanan konferensi video yang dapat diterima.
Jika implementasi perangkat melaporkan dukungan encoding VP8 untuk video resolusi 720p atau 1080p melalui API media, implementasi tersebut:
- [C-2-1] HARUS mendukung profil encoding dalam tabel berikut.
SD (Kualitas rendah) | SD (Kualitas tinggi) | HD 720p | HD 1080p | |
---|---|---|---|---|
Resolusi video | 320 x 180 px | 640 x 360 px | 1280 x 720 px | 1920 x 1080 px |
Frekuensi gambar video | 30 fps | 30 fps | 30 fps | 30 fps |
Kecepatan bit video | 800 Kbps | 2 Mbps | 4 Mbps | 10 Mbps |
5.2.4. VP9
Jika implementasi perangkat mendukung codec VP9, perangkat tersebut:
- [C-1-2] HARUS mendukung Profil 0 Level 3.
- [C-1-1] HARUS mendukung penulisan file WebM Matroska.
- [C-1-3] HARUS membuat data CodecPrivate.
- HARUS mendukung profil decoding HD seperti yang ditunjukkan dalam tabel berikut.
- [C-SR-1] SANGAT DISARANKAN untuk mendukung profil decoding HD seperti yang ditunjukkan dalam tabel berikut jika ada encoder hardware.
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
Resolusi video | 720 x 480 piksel | 1280 x 720 px | 1920 x 1080 px | 3840 x 2160 piksel |
Frekuensi gambar video | 30 fps | 30 fps | 30 fps | 30 fps |
Kecepatan bit video | 1,6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
Jika implementasi perangkat mengklaim mendukung Profil 2 atau Profil 3 melalui Media API:
- Dukungan untuk format 12-bit bersifat OPSIONAL.
5.2.5. H.265
Jika implementasi perangkat mendukung codec H.265, perangkat tersebut:
- [C-1-1] HARUS mendukung Profil Utama Level 3 hingga resolusi 512 x 512.
HARUS mendukung profil encoding HD seperti yang ditunjukkan dalam tabel berikut.- [C-SR-1] SANGAT DIUTAMAKAN untuk mendukung profil SD 720x480 dan profil encoding HD seperti yang ditunjukkan dalam tabel berikut jika ada enkoder hardware.
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
Resolusi video | 720 x 480 piksel | 1280 x 720 px | 1920 x 1080 px | 3840 x 2160 piksel |
Frekuensi gambar video | 30 fps | 30 fps | 30 fps | 30 fps |
Kecepatan bit video | 1,6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
Memulai persyaratan baru
5.2.6. AV1
Jika implementasi perangkat mendukung codec AV1, maka:
- [C-1-1] HARUS mendukung Profil Utama termasuk konten 8-bit dan 10-bit.
[C-1-2] HARUS memublikasikan data performa, yaitu melaporkan data performa melalui
getSupportedFrameRatesFor()
ataugetSupportedPerformancePoints()
API untuk resolusi yang didukung dalam tabel di bawah.[C-1-3] HARUS menerima metadata HDR dan menghasilkannya ke bitstream
Jika encoder AV1 diakselerasi dengan hardware, encoder tersebut:
- [C-2-1] HARUS mendukung hingga dan termasuk profil encoding HD1080p dari tabel di bawah:
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
Resolusi video | 720 x 480 piksel | 1280 x 720 px | 1920 x 1080 px | 3840 x 2160 piksel |
Frekuensi gambar video | 30 fps | 30 fps | 30 fps | 30 fps |
Kecepatan bit video | 5 Mbps | 8 Mbps | 16 Mbps | 50 Mbps |
Akhiri persyaratan baru
5.3. Dekode Video
Jika implementasi perangkat mendukung codec VP8, VP9, H.264, atau H.265, implementasi tersebut:
- [C-1-1] HARUS mendukung resolusi video dinamis dan peralihan kecepatan frame melalui API Android standar dalam aliran yang sama untuk semua codec VP8, VP9, H.264, dan H.265 secara real time dan hingga resolusi maksimum yang didukung oleh setiap codec di perangkat.
5.3.1. MPEG-2
Jika implementasi perangkat mendukung decoder MPEG-2, implementasi tersebut:
- [C-1-1] HARUS mendukung Tingkat Tinggi Profil Utama.
5.3.2. H.263
Jika penerapan perangkat mendukung decoder H.263, perangkat tersebut:
- [C-1-1] HARUS mendukung Profil Dasar Pengukuran Level 30 (resolusi CIF, QCIF, dan SQCIF @ 30fps 384 kbps) dan Level 45 (resolusi QCIF dan SQCIF @ 30fps 128 kbps).
5.3.3. MPEG-4
Jika implementasi perangkat dengan dekoder MPEG-4, perangkat tersebut:
- [C-1-1] HARUS mendukung Profil Sederhana Level 3.
5.3.4. H.264
Jika implementasi perangkat mendukung decoder H.264, perangkat tersebut:
- [C-1-1] HARUS mendukung Profil Utama Level 3.1 dan Profil Dasar Pengukuran. Dukungan untuk ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering), dan RS (Redundant Slices) bersifat OPSIONAL.
- [C-1-2] HARUS dapat mendekode video dengan profil SD (Definisi Standar) yang tercantum dalam tabel berikut dan dienkode dengan Profil Dasar Pengukuran dan Profil Utama Level 3.1 (termasuk 720p30).
- HARUS dapat mendekode video dengan profil HD (High Definition) seperti yang ditunjukkan dalam tabel berikut.
Jika tinggi yang dilaporkan oleh metode Display.getSupportedModes()
sama dengan atau lebih besar dari resolusi video, implementasi perangkat:
- [C-2-1] HARUS mendukung profil decoding video HD 720p dalam tabel berikut.
- [C-2-2] HARUS mendukung profil decoding video HD 1080p dalam tabel berikut.
SD (Kualitas rendah) | SD (Kualitas tinggi) | HD 720p | HD 1080p | |
---|---|---|---|---|
Resolusi video | 320 x 240 piksel | 720 x 480 piksel | 1280 x 720 px | 1920 x 1080 px |
Frekuensi gambar video | 30 fps | 30 fps | 60 fps | 30 fps (60 fpsTelevisi) |
Kecepatan bit video | 800 Kbps | 2 Mbps | 8 Mbps | 20 Mbps |
5.3.5. H.265 (HEVC)
Jika penerapan perangkat mendukung codec H.265, perangkat tersebut:
- [C-1-1] HARUS mendukung tingkat Utama Profil Utama Level 3 dan profil decoding video SD seperti yang ditunjukkan dalam tabel berikut.
- HARUS mendukung profil decoding HD seperti yang ditunjukkan dalam tabel berikut.
- [C-1-2] HARUS mendukung profil decoding HD seperti yang ditunjukkan dalam tabel berikut jika ada decoder hardware.
Jika tinggi yang dilaporkan oleh metode Display.getSupportedModes()
sama dengan atau lebih besar dari resolusi video, maka:
- [C-2-1] Implementasi perangkat HARUS mendukung setidaknya salah satu dekode H.265 atau VP9 profil 720, 1080, dan UHD.
SD (Kualitas rendah) | SD (Kualitas tinggi) | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|---|
Resolusi video | 352 x 288 piksel | 720 x 480 piksel | 1280 x 720 px | 1920 x 1080 px | 3840 x 2160 piksel |
Frekuensi gambar video | 30 fps | 30 fps | 30 fps | 30/60 fps (60 fpsTelevisi dengan dekode hardware H.265) | 60 fps |
Kecepatan bit video | 600 Kbps | 1,6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
Jika implementasi perangkat mengklaim mendukung Profil HDR melalui Media API:
- [C-3-1] Implementasi perangkat HARUS menerima metadata HDR yang diperlukan dari aplikasi, serta mendukung ekstraksi dan output metadata HDR yang diperlukan dari bitstream dan/atau penampung.
- [C-3-2] Implementasi perangkat HARUS menampilkan konten HDR dengan benar di layar perangkat atau di port output video standar (misalnya, HDMI).
5.3.6. VP8
Jika implementasi perangkat mendukung codec VP8, perangkat tersebut:
- [C-1-1] HARUS mendukung profil decoding SD dalam tabel berikut.
- HARUS menggunakan codec VP8 hardware yang memenuhi persyaratan.
- HARUS mendukung profil decoding HD dalam tabel berikut.
Jika tinggi seperti yang dilaporkan oleh metode Display.getSupportedModes()
sama
atau lebih besar dari resolusi video, maka:
- [C-2-1] Implementasi perangkat HARUS mendukung profil 720p dalam tabel berikut.
- [C-2-2] Implementasi perangkat HARUS mendukung profil 1080p dalam tabel berikut.
SD (Kualitas rendah) | SD (Kualitas tinggi) | HD 720p | HD 1080p | |
---|---|---|---|---|
Resolusi video | 320 x 180 px | 640 x 360 px | 1280 x 720 px | 1920 x 1080 px |
Frekuensi gambar video | 30 fps | 30 fps | 30 fps (60 fpsTelevisi) | 30 (60 fpsTelevisi) |
Kecepatan bit video | 800 Kbps | 2 Mbps | 8 Mbps | 20 Mbps |
5.3.7. VP9
Jika implementasi perangkat mendukung codec VP9, perangkat tersebut:
- [C-1-1] HARUS mendukung profil decoding video SD seperti yang ditunjukkan dalam tabel berikut.
- HARUS mendukung profil decoding HD seperti yang ditunjukkan dalam tabel berikut.
Jika implementasi perangkat mendukung codec VP9 dan dekoder hardware:
- [C-2-1] HARUS mendukung profil decoding HD seperti yang ditunjukkan dalam tabel berikut.
Jika tinggi yang dilaporkan oleh metode Display.getSupportedModes()
sama dengan atau lebih besar dari resolusi video, maka:
- [C-3-1] Implementasi perangkat HARUS mendukung setidaknya salah satu dekode VP9 atau H.265 dari profil 720, 1080, dan UHD.
SD (Kualitas rendah) | SD (Kualitas tinggi) | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|---|
Resolusi video | 320 x 180 px | 640 x 360 px | 1280 x 720 px | 1920 x 1080 px | 3840 x 2160 piksel |
Frekuensi gambar video | 30 fps | 30 fps | 30 fps | 30 fps (60 fpsTelevisi dengan decoding hardware VP9) | 60 fps |
Kecepatan bit video | 600 Kbps | 1,6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
Jika implementasi perangkat mengklaim mendukung VP9Profile2
atau VP9Profile3
melalui API media
'CodecProfileLevel':
- Dukungan untuk format 12-bit bersifat OPSIONAL.
Jika implementasi perangkat mengklaim mendukung Profil HDR (VP9Profile2HDR
,
VP9Profile2HDR10Plus
, VP9Profile3HDR
, VP9Profile3HDR10Plus
) melalui
API media:
- [C-4-1] Implementasi perangkat HARUS menerima metadata HDR yang diperlukan
(
KEY_HDR_STATIC_INFO
untuk semua profil HDR, serta 'KEY_HDR10_PLUS_INFO' untuk profil HDR10Plus) dari aplikasi. Alat ini juga HARUS mendukung ekstraksi dan output metadata HDR yang diperlukan dari bitstream dan/atau penampung. - [C-4-2] Implementasi perangkat HARUS menampilkan konten HDR dengan benar di layar perangkat atau di port output video standar (misalnya, HDMI).
5.3.8. Dolby Vision
Jika implementasi perangkat mendeklarasikan dukungan untuk dekoder Dolby Vision melalui
HDR_TYPE_DOLBY_VISION
, implementasi tersebut:
- [C-1-1] HARUS menyediakan ekstraktor yang kompatibel dengan Dolby Vision.
- [C-1-2] HARUS menampilkan konten Dolby Vision dengan benar di layar perangkat atau di port output video standar (misalnya, HDMI).
- [C-1-3] HARUS menetapkan ID trek lapisan dasar yang kompatibel dengan versi lama (jika ada) agar sama dengan ID trek lapisan Dolby Vision gabungan.
5.3.9. AV1
- [C-1-1] HARUS mendukung Profil 0 termasuk konten 10-bit.
Memulai persyaratan baru
Jika implementasi perangkat mendukung codec AV1 dan menyediakannya untuk aplikasi pihak ketiga, implementasi tersebut:- [C-1-1] HARUS mendukung Profil Utama termasuk konten 8-bit dan 10-bit.
Jika implementasi perangkat memberikan dukungan untuk codec AV1 dengan decoder yang dipercepat hardware, maka:
- [C-2-1] HARUS dapat mendekode setidaknya profil dekode video HD 720p dari
tabel di bawah jika tinggi yang dilaporkan oleh metode
Display.getSupportedModes()
sama dengan atau lebih besar dari 720p. - [C-2-2] HARUS dapat mendekode setidaknya profil dekode video HD 1080p
dari tabel di bawah jika tinggi yang dilaporkan oleh metode
Display.getSupportedModes()
sama dengan atau lebih besar dari 1080p.
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
Resolusi video | 720 x 480 piksel | 1280 x 720 px | 1920 x 1080 px | 3840 x 2160 piksel |
Frekuensi gambar video | 30 fps | 30 fps | 30 fps | 30 fps |
Kecepatan bit video | 5 Mbps | 8 Mbps | 16 Mbps | 50 Mbps |
Jika implementasi perangkat mendukung Profil HDR melalui Media API, maka perangkat tersebut:
- [C-3-1] HARUS mendukung ekstraksi dan output metadata HDR dari bitstream dan/atau penampung.
- [C-3-2] HARUS menampilkan konten HDR dengan benar di layar perangkat atau di port output video standar (misalnya, HDMI).
Akhiri persyaratan baru
5.4. Perekaman Audio
Meskipun beberapa persyaratan yang diuraikan di bagian ini tercantum sebagai HARUS sejak Android 4.3, Definisi Kompatibilitas untuk versi mendatang direncanakan untuk mengubahnya menjadi HARUS. Perangkat Android yang ada dan baru SANGAT DIANJURKAN untuk memenuhi persyaratan ini yang tercantum sebagai HARUS, atau perangkat tidak akan dapat mencapai kompatibilitas Android saat diupgrade ke versi mendatang.
5.4.1. Rekaman Audio Mentah dan Informasi Mikrofon
Jika implementasi perangkat mendeklarasikan android.hardware.microphone
, implementasi tersebut:
[C-1-1] HARUS mengizinkan pengambilan konten audio mentah untuk streaming INPUT
AudioRecord
atauAAudio
yang berhasil dibuka. Setidaknya, karakteristik berikut HARUS didukung:- Format: PCM Linear, 16-bit
- Frekuensi sampling: 8.000, 11.025, 16.000, 44.100, 48.000 Hz
- Saluran: Mono
- Sumber Audio:
DEFAULT
,MIC
,CAMCORDER
,VOICE_RECOGNITION
,VOICE_COMMUNICATION
,UNPROCESSED
, atauVOICE_PERFORMANCE
. Hal ini juga berlaku untuk Setelan Input yang setara diAAudio
, misalnya,AAUDIO_INPUT_PRESET_CAMCORDER
.
HARUS mengizinkan perekaman konten audio mentah dengan karakteristik berikut:
- Format: PCM Linear, 16-bit, dan 24-bit
- Rasio sampling: 8.000, 11.025, 16.000, 22.050, 24.000, 32.000, 44.100, 48.000 Hz
- Saluran: Sebanyak jumlah mikrofon di perangkat
[C-1-2] HARUS merekam pada frekuensi sampel di atas tanpa up-sampling.
[C-1-3] HARUS menyertakan filter anti-aliasing yang sesuai saat frekuensi sampel yang diberikan di atas diambil dengan downsampling.
HARUS mengizinkan perekaman konten audio mentah dengan kualitas radio AM dan DVD, yang berarti karakteristik berikut:
- Format: PCM Linear, 16-bit
- Frekuensi sampling: 22.050, 48.000 Hz
- Saluran: Stereo
[C-1-4] HARUS mematuhi
MicrophoneInfo
API dan mengisi informasi dengan benar untuk mikrofon yang tersedia di perangkat yang dapat diakses oleh aplikasi pihak ketiga melaluiAudioManager.getMicrophones()
API, untuk AudioRecord aktif yang menggunakanMediaRecorder.AudioSources DEFAULT
,MIC
,CAMCORDER
,VOICE_RECOGNITION
,VOICE_COMMUNICATION
,UNPROCESSED
, atauVOICE_PERFORMANCE
. Jika implementasi perangkat memungkinkan perekaman konten audio mentah berkualitas DVD dan radio AM, perangkat tersebut:[C-2-1] HARUS merekam tanpa up-sampling pada rasio apa pun yang lebih tinggi dari 16.000:22.050 atau 44.100:48.000.
[C-2-2] HARUS menyertakan filter anti-aliasing yang sesuai untuk up-sampling atau down-sampling.
5.4.2. Merekam untuk Pengenalan Suara
Jika implementasi perangkat mendeklarasikan android.hardware.microphone
, implementasi tersebut:
- [C-1-1] HARUS merekam
sumber audio
android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION
pada salah satu frekuensi sampling, 44100 dan 48000. - [C-1-2] HARUS, secara default, menonaktifkan pemrosesan audio pengurangan bising saat
merekam streaming audio dari sumber
audio
AudioSource.VOICE_RECOGNITION
. [C-1-3] HARUS, secara default, menonaktifkan kontrol penguatan otomatis saat merekam streaming audio dari sumber audio
AudioSource.VOICE_RECOGNITION
.HARUS menunjukkan karakteristik amplitudo versus frekuensi yang hampir datar dalam rentang frekuensi menengah: khususnya ±3 dB dari 100 Hz hingga 4.000 Hz untuk setiap dan semua mikrofon yang digunakan untuk merekam sumber audio pengenalan suara.
[C-SR-1] SANGAT DISARANKAN untuk menunjukkan level amplitudo dalam rentang frekuensi rendah: khususnya dari ±20 dB dari 30 Hz hingga 100 Hz dibandingkan dengan rentang frekuensi tengah untuk setiap mikrofon yang digunakan untuk merekam sumber audio pengenalan suara.
[C-SR-2] SANGAT DISARANKAN untuk menunjukkan level amplitudo dalam rentang frekuensi tinggi: secara khusus dari ±30 dB dari 4.000 Hz hingga 22 KHz dibandingkan dengan rentang frekuensi tengah untuk setiap mikrofon yang digunakan untuk merekam sumber audio pengenalan suara.
HARUS menetapkan sensitivitas input audio sehingga sumber nada sinusoid 1000 Hz diputar pada Tingkat Tekanan Suara (SPL) 90 dB (diukur
pada jarak 30 cm daridi samping mikrofon) memberikan respons ideal RMS 2500 dalam rentang 1770 dan 3530 untuk 16 sampel bit (atau -22,35 db ±3dB Skala Penuh untuk sampel presisi ganda/floating point) untuk setiap mikrofon yang digunakan untuk merekam sumber audio pengenalan suara.HARUS merekam streaming audio pengenalan suara sehingga level amplitudo PCM secara linear melacak perubahan SPL input dalam rentang minimal 30 dB dari -18 dB hingga +12 dB re 90 dB SPL di mikrofon.
HARUS merekam streaming audio pengenalan suara dengan distorsi harmoni total (THD) kurang dari 1% untuk 1 kHz pada level input SPL 90 dB di mikrofon.
Jika implementasi perangkat mendeklarasikan teknologi android.hardware.microphone
dan peredam
derau (pengurangan) yang disesuaikan untuk pengenalan ucapan, teknologi tersebut:
- [C-2-1] HARUS mengizinkan efek audio ini dapat dikontrol dengan
android.media.audiofx.NoiseSuppressor
API. - [C-2-2] HARUS mengidentifikasi setiap implementasi teknologi
peredam bising secara unik melalui kolom
AudioEffect.Descriptor.uuid
.
5.4.3. Perekaman untuk Pengalihan Pemutaran
Class android.media.MediaRecorder.AudioSource
menyertakan sumber
audio REMOTE_SUBMIX
.
Jika implementasi perangkat mendeklarasikan android.hardware.audio.output
dan
android.hardware.microphone
, implementasi tersebut:
[C-1-1] HARUS menerapkan sumber audio
REMOTE_SUBMIX
dengan benar sehingga saat aplikasi menggunakanandroid.media.AudioRecord
API untuk merekam dari sumber audio ini, aplikasi akan merekam campuran semua streaming audio kecuali untuk hal berikut:AudioManager.STREAM_RING
AudioManager.STREAM_ALARM
AudioManager.STREAM_NOTIFICATION
5.4.4. Peredam Gema Akustik
Jika implementasi perangkat mendeklarasikan android.hardware.microphone
, implementasi tersebut:
- HARUS menerapkan teknologi Acoustic Echo Canceler
(AEC) yang disesuaikan untuk komunikasi suara dan diterapkan ke jalur pengambilan
saat mengambil gambar menggunakan
AudioSource.VOICE_COMMUNICATION
.
Jika implementasi perangkat menyediakan Acoustic Echo Canceler yang
disisipkan di jalur audio pengambilan saat AudioSource.VOICE_COMMUNICATION
dipilih, implementasi tersebut:
- [C-SR-1] SANGAT_DISARANKAN untuk mendeklarasikannya melalui metode API AcousticEchoCanceler AcousticEchoCanceler.isAvailable()
- [C-SR-2] SANGAT_DISARANKAN untuk memungkinkan efek audio ini dapat dikontrol dengan AcousticEchoCanceler API.
- [C-SR-3] SANGAT_DISARANKAN untuk mengidentifikasi secara unik setiap penerapan teknologi AEC melalui kolom AudioEffect.Descriptor.uuid.
5.4.5. Perekaman Serentak
Jika implementasi perangkat mendeklarasikan android.hardware.microphone
,implementasi tersebut HARUS
menerapkan pengambilan serentak seperti yang dijelaskan dalam dokumen ini. Khususnya:
- [C-1-1] HARUS mengizinkan akses serentak ke mikrofon oleh layanan aksesibilitas
yang merekam dengan
AudioSource.VOICE_RECOGNITION
dan setidaknya satu aplikasi yang merekam denganAudioSource
apa pun. - [C-1-2] HARUS mengizinkan akses serentak ke mikrofon oleh aplikasi bawaan
yang memiliki peran Asisten dan setidaknya satu aplikasi
yang merekam dengan
AudioSource
apa pun kecualiAudioSource.VOICE_COMMUNICATION
atauAudioSource.CAMCORDER
. - [C-1-3] HARUS membisukan perekaman audio untuk aplikasi lain, kecuali
layanan aksesibilitas, saat aplikasi merekam dengan
AudioSource.VOICE_COMMUNICATION
atauAudioSource.CAMCORDER
. Namun, saat aplikasi merekam melaluiAudioSource.VOICE_COMMUNICATION
, aplikasi lain dapat merekam panggilan suara jika merupakan aplikasi khusus (bawaan) dengan izinCAPTURE_AUDIO_OUTPUT
. - [C-1-4] Jika dua atau beberapa aplikasi merekam secara serentak dan jika tidak ada aplikasi yang memiliki UI di bagian atas, aplikasi yang mulai merekam paling baru akan menerima audio.
5.5. Pemutaran Audio
Android menyertakan dukungan untuk memungkinkan aplikasi memutar audio melalui periferal output audio seperti yang ditentukan di bagian 7.8.2.
5.5.1. Pemutaran Audio Mentah
Jika implementasi perangkat mendeklarasikan android.hardware.audio.output
, implementasi tersebut:
[C-1-1] HARUS mengizinkan pemutaran konten audio mentah dengan karakteristik berikut:
- Format sumber: PCM Linear, 16-bit, 8-bit, float
- Saluran: Mono, Stereo, konfigurasi multisaluran yang valid dengan maksimal 8 saluran
- Frekuensi sampling (dalam Hz):
- 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 pada konfigurasi saluran yang tercantum di atas
- 96.000 dalam mono dan stereo
5.5.2. Efek Audio
Android menyediakan API untuk efek audio untuk implementasi perangkat.
Jika implementasi perangkat mendeklarasikan fitur android.hardware.audio.output
,
implementasi tersebut:
- [C-1-1] HARUS mendukung implementasi
EFFECT_TYPE_EQUALIZER
danEFFECT_TYPE_LOUDNESS_ENHANCER
yang dapat dikontrol melalui subclass AudioEffectEqualizer
danLoudnessEnhancer
. - [C-1-2] HARUS mendukung penerapan API visualiser, yang dapat dikontrol melalui
class
Visualizer
. - [C-1-3] HARUS mendukung implementasi
EFFECT_TYPE_DYNAMICS_PROCESSING
yang dapat dikontrol melalui subclass AudioEffectDynamicsProcessing
.
Memulai persyaratan baru
- [C-1-4] HARUS mendukung efek audio dengan input dan output floating point.
- [C-1-5] HARUS memastikan bahwa efek audio mendukung beberapa saluran hingga jumlah saluran mixer yang juga dikenal sebagai FCC_LIMIT.
Akhiri persyaratan baru
- HARUS mendukung implementasi
EFFECT_TYPE_BASS_BOOST
,EFFECT_TYPE_ENV_REVERB
,EFFECT_TYPE_PRESET_REVERB
, danEFFECT_TYPE_VIRTUALIZER
yang dapat dikontrol melalui subclassAudioEffect
BassBoost
,EnvironmentalReverb
,PresetReverb
, danVirtualizer
. - [C-SR-1] SANGAT DISARANKAN untuk mendukung efek dalam floating point dan multisaluran.
5.5.3. Volume Output Audio
Implementasi perangkat otomotif:
- HARUS mengizinkan penyesuaian volume audio
secara terpisah per setiap streaming audio menggunakan jenis konten atau penggunaan seperti yang ditentukan
oleh AudioAttributes
dan penggunaan audio mobil seperti yang ditentukan secara publik di
android.car.CarAudioManager
.
5.5.4. Offload Audio
Jika implementasi perangkat mendukung pemutaran offload audio, implementasi tersebut:
- [C-SR-1] SANGAT DISARANKAN untuk memangkas konten audio tanpa jeda yang diputar antara dua klip dengan format yang sama saat ditentukan oleh AudioTrack gapless API dan penampung media untuk MediaPlayer.
5.6. Latensi Audio
Latensi audio adalah penundaan waktu saat sinyal audio melewati sistem. Banyak class aplikasi mengandalkan latensi singkat, untuk mendapatkan efek suara real-time.
Untuk tujuan bagian ini, gunakan definisi berikut:
- latensi output. Interval antara saat aplikasi menulis frame data yang dienkode PCM dan saat suara yang sesuai ditampilkan ke lingkungan di transduser di perangkat atau sinyal keluar dari perangkat melalui port dan dapat diamati secara eksternal.
- latensi output dingin. Waktu antara memulai aliran output dan waktu presentasi frame pertama berdasarkan stempel waktu, saat sistem output audio tidak ada aktivitas dan dimatikan sebelum permintaan.
- latensi output berkelanjutan. Latensi output untuk frame berikutnya, setelah perangkat memutar audio.
- latensi input. Interval antara saat suara ditampilkan oleh lingkungan ke perangkat pada transduser di perangkat atau sinyal memasuki perangkat melalui port dan saat aplikasi membaca frame data yang dienkode PCM yang sesuai.
- input hilang. Bagian awal sinyal input yang tidak dapat digunakan atau tidak tersedia.
- latensi input dingin. Waktu antara memulai streaming dan saat frame valid pertama diterima, saat sistem input audio tidak ada aktivitas dan dimatikan sebelum permintaan.
latensi input berkelanjutan. Latensi input untuk frame berikutnya, saat perangkat merekam audio.
latensi bolak-balik berkelanjutan. Jumlah latensi input berkelanjutan ditambah latensi output berkelanjutan ditambah satu periode buffering. Periode buffering memungkinkan waktu bagi aplikasi untuk memproses sinyal dan waktu bagi aplikasi untuk mengurangi perbedaan fase antara aliran input dan output.
OpenSL ES PCM buffer queue API. Kumpulan API OpenSL ES terkait PCM dalam Android NDK.
API audio native AAudio. Kumpulan AAudio API dalam Android NDK.
Stempel waktu. Pasangan yang terdiri dari posisi frame relatif dalam streaming dan perkiraan waktu saat frame tersebut memasuki atau keluar dari pipeline pemrosesan audio di endpoint terkait. Lihat juga AudioTimestamp.
Glitch. Gangguan sementara atau nilai sampel yang salah dalam sinyal audio, biasanya disebabkan oleh buffer underrun untuk output, buffer overrun untuk input, atau sumber derau digital atau analog lainnya.
simpangan mutlak rata-rata. Rata-rata nilai absolut dari simpangan dari nilai rata-rata untuk kumpulan nilai.
latensi ketuk-untuk-nada. Waktu antara saat layar diketuk dan saat nada yang dihasilkan sebagai hasil dari ketukan tersebut terdengar di speaker.
Jika implementasi perangkat mendeklarasikan android.hardware.audio.output
, implementasi tersebut
HARUS memenuhi atau melebihi persyaratan berikut:
- [C-1-1] Stempel waktu output yang ditampilkan oleh
AudioTrack.getTimestamp
dan
AAudioStream_getTimestamp
akurat hingga +/- 2 md. [C-1-2] Latensi output cold start 500 milidetik atau kurang.
[C-1-3] Membuka aliran output menggunakan
AAudioStreamBuilder_openStream()
HARUS memerlukan waktu kurang dari 1.000 milidetik.
Jika implementasi perangkat mendeklarasikan android.hardware.audio.output
, perangkat tersebut
SANGAT DISARANKAN untuk memenuhi atau melebihi persyaratan berikut:
- [C-SR-1] Latensi output dingin 100 milidetik atau kurang melalui jalur data speaker.
- [C-SR-2] Latensi ketuk-untuk-nada 80 milidetik atau kurang.
- [C-SR-4] Stempel waktu output yang ditampilkan oleh
AudioTrack.getTimestamp
dan
AAudioStream_getTimestamp
akurat hingga +/- 1 md.
Memulai persyaratan baru
- [C-SR-4] Latensi bolak-balik yang dihitung berdasarkan stempel waktu input dan output
yang ditampilkan oleh
AAudioStream_getTimestamp
SANGAT DISARANKAN agar berada dalam 30 md dari latensi bolak-balik yang diukur untukAAUDIO_PERFORMANCE_MODE_NONE
danAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
untuk speaker, headset berkabel, dan nirkabel.
Akhiri persyaratan baru
Jika implementasi perangkat memenuhi persyaratan di atas, setelah kalibrasi awal, saat menggunakan API audio native AAudio, untuk latensi output berkelanjutan dan latensi output dingin di setidaknya satu perangkat output audio yang didukung, persyaratannya adalah:
- [C-SR-5] SANGAT DIUJAMI untuk melaporkan audio latensi rendah dengan mendeklarasikan
tanda fitur
android.hardware.audio.low_latency
. - [C-SR-6] SANGAT DIUJAMI untuk memenuhi persyaratan audio latensi rendah melalui AAudio API.
- [C-SR-7] SANGAT DISARANKAN untuk memastikan bahwa untuk streaming yang menampilkan
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
dariAAudioStream_getPerformanceMode()
, nilai yang ditampilkan olehAAudioStream_getFramesPerBurst()
kurang dari atau sama dengan nilai yang ditampilkan olehandroid.media.AudioManager.getProperty(String)
untuk kunci propertiAudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER
.
Jika implementasi perangkat tidak memenuhi persyaratan untuk audio latensi rendah melalui API audio native AAudio, implementasi tersebut:
- [C-2-1] TIDAK BOLEH melaporkan dukungan untuk audio latensi rendah.
Jika implementasi perangkat menyertakan android.hardware.microphone
, perangkat
HARUS memenuhi persyaratan audio input berikut:
- [C-3-1] Batasi error dalam stempel waktu input, seperti yang ditampilkan oleh
AudioRecord.getTimestamp
atau
AAudioStream_getTimestamp
, hingga +/- 2 md. "Error" di sini berarti penyimpangan dari nilai yang benar. - [C-3-2] Latensi input cold start 500 milidetik atau kurang.
- [C-3-3] Membuka aliran input menggunakan
AAudioStreamBuilder_openStream()
HARUS memerlukan waktu kurang dari 1.000 milidetik.
Jika implementasi perangkat menyertakan android.hardware.microphone
, perangkat tersebut
SANGAT DISARANKAN untuk memenuhi persyaratan audio input berikut:
[C-SR-8] Latensi input dingin 100 milidetik atau kurang melalui jalur data mikrofon.
[C-SR-11] Batasi error dalam stempel waktu input, seperti yang ditampilkan oleh AudioRecord.getTimestamp atau
AAudioStream_getTimestamp
, hingga +/- 1 md.
Jika implementasi perangkat mendeklarasikan android.hardware.audio.output
dan
android.hardware.microphone
, implementasi tersebut:
- [C-SR-12] SANGAT DIUTAMAKAN untuk memiliki Mean Continuous Round-Trip Latency sebesar 50 milidetik atau kurang selama 5 pengukuran, dengan Mean Absolute Deviation kurang dari 10 md, melalui setidaknya satu jalur yang didukung.
5.7. Protokol Jaringan
Implementasi perangkat HARUS mendukung protokol jaringan media untuk pemutaran audio dan video seperti yang ditentukan dalam dokumentasi Android SDK.
Untuk setiap codec dan format penampung yang harus didukung oleh implementasi perangkat, implementasi perangkat:
[C-1-1] HARUS mendukung codec atau penampung tersebut melalui HTTP dan HTTPS.
[C-1-2] HARUS mendukung format segmen media yang sesuai seperti yang ditunjukkan dalam tabel format segmen media di bawah melalui protokol draf HTTP Live Streaming, Versi 7.
[C-1-3] HARUS mendukung format payload RTSP yang sesuai seperti yang ditunjukkan dalam tabel RTSP di bawah. Untuk pengecualian, lihat catatan kaki tabel di bagian 5.1.
Format Segmen Media
Format segmen | Referensi | Dukungan codec yang diperlukan |
---|---|---|
MPEG-2 Transport Stream | ISO 13818 |
Codec video:
dan MPEG-2. Codec audio:
|
AAC dengan framing ADTS dan tag ID3 | ISO 13818-7 | Lihat bagian 5.1.1 untuk mengetahui detail tentang AAC dan variannya |
WebVTT | WebVTT |
RTSP (RTP, SDP)
Nama profil | Referensi | Dukungan codec yang diperlukan |
---|---|---|
H264 AVC | RFC 6184 | Lihat bagian 5.1.8 untuk mengetahui detail tentang H264 AVC |
MP4A-LATM | RFC 6416 | Lihat bagian 5.1.3 untuk mengetahui detail tentang AAC dan variannya |
H263-1998 |
RFC 3551 RFC 4629 RFC 2190 |
Lihat bagian 5.1.8 untuk mengetahui detail tentang H263 |
H263-2000 | RFC 4629 | Lihat bagian 5.1.8 untuk mengetahui detail tentang H263 |
AMR | RFC 4867 | Lihat bagian 5.1.3 untuk mengetahui detail tentang AMR-NB |
AMR-WB | RFC 4867 | Lihat bagian 5.1.3 untuk mengetahui detail tentang AMR-WB |
MP4V-ES | RFC 6416 | Lihat bagian 5.1.8 untuk mengetahui detail tentang MPEG-4 SP |
mpeg4-generic | RFC 3640 | Lihat bagian 5.1.3 untuk mengetahui detail tentang AAC dan variannya |
MP2T | RFC 2250 | Lihat MPEG-2 Transport Stream di bawah HTTP Live Streaming untuk mengetahui detailnya |
5,8. Media Aman
Jika implementasi perangkat mendukung output video aman dan mampu mendukung platform aman, implementasi tersebut:
- [C-1-1] HARUS mendeklarasikan dukungan untuk
Display.FLAG_SECURE
.
Jika implementasi perangkat mendeklarasikan dukungan untuk Display.FLAG_SECURE
dan mendukung
protokol tampilan nirkabel, implementasi tersebut:
- [C-2-1] HARUS mengamankan link dengan mekanisme yang kuat secara kriptografis seperti HDCP 2.x atau yang lebih tinggi untuk layar yang terhubung melalui protokol nirkabel seperti Miracast.
Jika implementasi perangkat mendeklarasikan dukungan untuk Display.FLAG_SECURE
dan
mendukung layar eksternal berkabel, implementasi tersebut:
- [C-3-1] HARUS mendukung HDCP 1.2 atau yang lebih tinggi untuk semua layar eksternal yang terhubung melalui port berkabel yang dapat diakses pengguna.
5.9. Musical Instrument Digital Interface (MIDI)
Jika implementasi perangkat melaporkan dukungan untuk fitur android.software.midi
melalui
class
android.content.pm.PackageManager
, implementasi tersebut:
[C-1-1] HARUS mendukung MIDI melalui semua transpor hardware yang kompatibel dengan MIDI yang menyediakan konektivitas non-MIDI generik, dengan transpor tersebut adalah:
- Mode host USB, bagian 7.7
- MIDI melalui Bluetooth LE yang bertindak dalam peran sentral, bagian 7.4.3
[C-1-2] HARUS mendukung transpor software MIDI antar-aplikasi (perangkat MIDI virtual)
[C-1-3] HARUS menyertakan libamidi.so (dukungan MIDI native)
HARUS mendukung mode periferal MIDI melalui USB, bagian 7.7
5.10. Audio Profesional
Jika implementasi perangkat melaporkan dukungan untuk fitur
android.hardware.audio.pro
melalui
class
android.content.pm.PackageManager, implementasi tersebut:
- [C-1-1] HARUS melaporkan dukungan untuk fitur
android.hardware.audio.low_latency
. - [C-1-2] HARUS memiliki latensi audio bolak-balik berkelanjutan, seperti yang ditentukan dalam bagian 5.6 Latensi Audio sebesar 25 milidetik atau kurang melalui setidaknya satu jalur yang didukung.
- [C-1-3] HARUS menyertakan port USB yang mendukung mode host USB dan mode periferal USB.
- [C-1-4] HARUS melaporkan dukungan untuk fitur
android.software.midi
. - [C-1-5] HARUS memenuhi latensi dan persyaratan audio USB menggunakan
audio native AAudio
API dan
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
. - [C-1-6] HARUS memiliki latensi output Cold sebesar 200 milidetik atau kurang.
- [C-1-7] HARUS memiliki latensi input Dingin 200 milidetik atau kurang.
[C-1-8] HARUS memiliki latensi Ketuk-untuk-nada rata-rata 80 milidetik atau kurang selama minimal 5 pengukuran melalui jalur data speaker ke mikrofon.
[C-SR-1] SANGAT DISARANKAN untuk memenuhi latensi seperti yang ditentukan dalam bagian 5.6 Latensi Audio, yaitu 20 milidetik atau kurang, selama 5 pengukuran dengan Mean Absolute Deviation kurang dari 5 milidetik di sepanjang jalur speaker ke mikrofon.
[C-SR-2] SANGAT DIUJAMI untuk memenuhi persyaratan Audio Pro untuk latensi audio bolak-balik yang berkelanjutan, latensi input dingin, dan latensi output dingin, serta persyaratan audio USB menggunakan API audio native AAudio di jalur MMAP.
[C-SR-3] SANGAT DIUJAMI untuk memberikan tingkat performa CPU yang konsisten saat audio aktif dan beban CPU bervariasi. Hal ini harus diuji menggunakan aplikasi Android SynthMark. SynthMark menggunakan software synthesizer yang berjalan di framework audio simulasi yang mengukur performa sistem. Lihat dokumentasi SynthMark untuk penjelasan benchmark. Aplikasi SynthMark harus dijalankan menggunakan opsi “Pengujian Otomatis” dan mencapai hasil berikut:
- voicemark.90 >= 32 suara
- latencymark.fixed.little <= 15 mdtk
- latencymark.dynamic.little <= 50 mdtk
HARUS meminimalkan ketidakakuratan dan penyimpangan jam audio relatif terhadap waktu standar.
HARUS meminimalkan drift clock audio relatif terhadap
CLOCK_MONOTONIC
CPU saat keduanya aktif.HARUS meminimalkan latensi audio melalui transduser di perangkat.
HARUS meminimalkan latensi audio melalui audio digital USB.
HARUS mendokumentasikan pengukuran latensi audio di semua jalur.
HARUS meminimalkan jitter dalam waktu entri callback penyelesaian buffer audio, karena hal ini memengaruhi persentase bandwidth CPU penuh yang dapat digunakan oleh callback.
HARUS memberikan nol gangguan audio dalam penggunaan normal pada latensi yang dilaporkan.
HARUS memberikan perbedaan latensi antar-saluran nol.
HARUS meminimalkan latensi rata-rata MIDI di semua transpor.
HARUS meminimalkan variabilitas latensi MIDI saat beban (jitter) di semua transpor.
HARUS memberikan stempel waktu MIDI yang akurat di semua transpor.
HARUS meminimalkan derau sinyal audio melalui transduser di perangkat, termasuk periode segera setelah cold start.
HARUS memberikan perbedaan clock audio nol antara sisi input dan output titik akhir yang sesuai, jika keduanya aktif. Contoh endpoint yang sesuai mencakup mikrofon dan speaker di perangkat, atau input dan output jack audio.
HARUS menangani callback penyelesaian buffer audio untuk sisi input dan output titik akhir yang sesuai pada thread yang sama saat keduanya aktif, dan segera masuk ke callback output setelah kembali dari callback input. Atau, jika tidak memungkinkan untuk menangani callback pada thread yang sama, masukkan callback output segera setelah memasukkan callback input untuk mengizinkan aplikasi memiliki pengaturan waktu yang konsisten pada sisi input dan output.
HARUS meminimalkan perbedaan fase antara buffering audio HAL untuk sisi input dan output dari endpoint yang sesuai.
HARUS meminimalkan latensi sentuh.
HARUS meminimalkan variabilitas latensi sentuh saat beban (jitter).
Jika implementasi perangkat memenuhi semua persyaratan di atas, implementasi tersebut:
- [C-SR-4] SANGAT DISARANKAN untuk melaporkan dukungan untuk fitur
android.hardware.audio.pro
melalui classandroid.content.pm.PackageManager
.
Jika implementasi perangkat menyertakan colokan audio 3,5 mm 4 konduktor, perangkat tersebut:
[C-2-1] HARUS memiliki Latensi Audio Bolak-Balik Kontinu rata-rata, seperti yang ditentukan dalam bagian 5.6 Latensi Audio, sebesar 20 milidetik atau kurang, dari 5 pengukuran dengan Deviasi Absolut Rata-rata kurang dari 5 milidetik melalui jalur jack audio menggunakan Audio Loopback Dongle.
[C-SR-5] SANGAT DISARANKAN untuk mematuhi bagian Spesifikasi perangkat seluler (jack) dari Spesifikasi Headset Audio Berkabel (v1.1).
Jika implementasi perangkat menghilangkan jack audio 3,5 mm 4 konduktor dan menyertakan port USB yang mendukung mode host USB, perangkat tersebut:
- [C-3-1] HARUS menerapkan class audio USB.
- [C-3-2] HARUS memiliki rata-rata Latensi Audio Bolak-Balik Kontinu sebesar 25 milidetik atau kurang, selama 5 pengukuran dengan Mean Absolute Deviation kurang dari 5 milidetik melalui port mode host USB menggunakan class audio USB. (Hal ini dapat diukur menggunakan adaptor USB-3,5 mm dan Dongle Loopback Audio, atau menggunakan antarmuka audio USB dengan kabel patch yang menghubungkan input ke output).
- [C-SR-6] SANGAT DIUJAMI untuk mendukung I/O serentak hingga 8 saluran setiap arah, frekuensi sampel 96 kHz, dan kedalaman 24-bit atau 32-bit, saat digunakan dengan periferal audio USB yang juga mendukung persyaratan ini.
- [C-SR-7] SANGAT DIUJAMI untuk memenuhi kelompok persyaratan ini menggunakan API audio native AAudio melalui jalur MMAP.
Jika implementasi perangkat menyertakan port HDMI, perangkat tersebut:
- HARUS mendukung output dalam stereo dan delapan saluran dengan kedalaman 20-bit atau 24-bit dan 192 kHz tanpa kehilangan kedalaman bit atau pengambilan sampel ulang, dalam setidaknya satu konfigurasi.
5.11. Menangkap untuk Belum Diproses
Android menyertakan dukungan untuk merekam audio yang belum diproses melalui
sumber audio android.media.MediaRecorder.AudioSource.UNPROCESSED
. Di
OpenSL ES, ini dapat diakses dengan preset rekaman
SL_ANDROID_RECORDING_PRESET_UNPROCESSED
.
Jika penerapan perangkat bermaksud mendukung sumber audio yang belum diproses dan menyediakan sumber audio tersebut untuk aplikasi pihak ketiga, penerapan tersebut:
[C-1-1] HARUS melaporkan dukungan melalui properti
android.media.AudioManager
PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.[C-1-2] HARUS menunjukkan karakteristik amplitudo versus frekuensi yang hampir datar dalam rentang frekuensi menengah: khususnya ±10 dB dari 100 Hz hingga 7000 Hz untuk setiap mikrofon yang digunakan untuk merekam sumber audio yang belum diproses.
[C-1-3] HARUS menunjukkan level amplitudo dalam rentang frekuensi rendah: khususnya dari ±20 dB dari 5 z hingga 100 Hz dibandingkan dengan rentang frekuensi menengah untuk setiap mikrofon yang digunakan untuk merekam sumber audio yang belum diproses.
[C-1-4] HARUS menunjukkan level amplitudo dalam rentang frekuensi tinggi: secara khusus dari ±30 dB dari 7.000 Hz hingga 22 KHz dibandingkan dengan rentang frekuensi menengah untuk setiap mikrofon yang digunakan untuk merekam sumber audio yang belum diproses.
[C-1-5] HARUS menyetel sensitivitas input audio sehingga sumber nada sinusoid 1000 Hz yang diputar pada Tingkat Tekanan Suara (SPL) 94 dB menghasilkan respons dengan RMS 520 untuk sampel 16 bit (atau -36 dB Skala Penuh untuk sampel presisi floating point/ganda) untuk setiap mikrofon yang digunakan untuk merekam sumber audio yang belum diproses.
[C-1-6] HARUS memiliki rasio sinyal-ke-derau (SNR) sebesar 60 dB atau lebih tinggi untuk setiap mikrofon yang digunakan untuk merekam sumber audio yang belum diproses. (sedangkan SNR diukur sebagai perbedaan antara 94 dB SPL dan SPL setara dari derau sendiri, dengan bobot A).
[C-1-7] HARUS memiliki total harmonic distortion (THD) kurang dari 1% untuk 1 kHZ pada level input SPL 90 dB di setiap mikrofon yang digunakan untuk merekam sumber audio yang belum diproses.
[C-1-8] TIDAK BOLEH memiliki pemrosesan sinyal lain (misalnya Automatic Gain Control, High Pass Filter, atau Echo cancellation) di jalur selain pengganda level untuk membawa level ke rentang yang diinginkan. Dengan kata lain:
- [C-1-9] Jika pemrosesan sinyal ada dalam arsitektur karena alasan apa pun, pemrosesan sinyal HARUS dinonaktifkan dan secara efektif tidak menimbulkan penundaan atau latensi tambahan ke jalur sinyal.
- [C-1-10] Pengganda level, meskipun diizinkan berada di jalur, TIDAK BOLEH menyebabkan penundaan atau latensi pada jalur sinyal.
Semua pengukuran SPL dilakukan langsung di samping mikrofon yang sedang diuji. Untuk beberapa konfigurasi mikrofon, persyaratan ini berlaku untuk setiap mikrofon.
Jika implementasi perangkat mendeklarasikan android.hardware.microphone
, tetapi tidak
mendukung sumber audio yang belum diproses, implementasi tersebut:
- [C-2-1] HARUS menampilkan
null
untuk metode APIAudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED)
, untuk menunjukkan kurangnya dukungan dengan benar. - [C-SR-1] masih SANGAT DIUJAMI untuk memenuhi sebanyak mungkin persyaratan untuk jalur sinyal untuk sumber rekaman yang belum diproses.
5.12. Video HDR
Android 13 mendukung teknologi HDR seperti yang dijelaskan dalam dokumen mendatang.
Format Piksel
Jika decoder video mengiklankan dukungan untuk COLOR_FormatYUVP010, maka:
[C-1-1] HARUS mendukung format P010 untuk pembacaan CPU (ImageReader, MediaImage, ByteBuffer). Di Android 13, P010 dilonggarkan untuk memungkinkan langkah arbitrer untuk bidang Y dan UV.
[C-1-2] Buffer output P010 HARUS dapat diambil sampelnya oleh GPU (saat dialokasikan dengan penggunaan GPU_SAMPLING). Hal ini memungkinkan komposisi GPU dan pemetaan tone kustom oleh aplikasi.
Jika decoder video mengiklankan dukungan untuk COLOR_Format32bitABGR2101010, decoder tersebut:
- [C-2-1] HARUS mendukung format RGBA_1010102 untuk platform output dan dapat dibaca CPU (output ByteBuffer).
Jika encoder video mengiklankan dukungan untuk COLOR_FormatYUVP010, encoder tersebut:
- [C-3-1] HARUS mendukung format P010 untuk platform input dan input yang dapat ditulis CPU (ImageWriter, MediaImage, ByteBuffer).
Jika encoder video mengiklankan dukungan untuk COLOR_Format32bitABGR2101010, encoder tersebut:
- [C-4-1] HARUS mendukung format RGBA_1010102 untuk platform input dan input yang dapat ditulis CPU (ImageWriter, ByteBuffer). Catatan: Konversi antar-kurva transfer TIDAK diperlukan untuk encoder.
Persyaratan Perekaman HDR
Untuk semua encoder video yang mendukung profil HDR, implementasi perangkat:
[C-5-1] TIDAK BOLEH mengasumsikan bahwa metadata HDR akurat. Misalnya, bingkai yang dienkode dapat memiliki piksel di luar tingkat luminans puncak, atau histogram mungkin tidak mewakili frame.
HARUS menggabungkan metadata dinamis HDR untuk menghasilkan metadata statis HDR yang sesuai untuk streaming yang dienkode, dan harus menghasilkannya di akhir setiap sesi encoding.
Jika implementasi perangkat mendukung pengambilan HDR menggunakan CamcorderProfile API, perangkat tersebut:
[C-6-1] HARUS mendukung perekaman HDR melalui Camera2 API juga.
[C-6-2] HARUS mendukung minimal satu encoder video dengan akselerasi hardware untuk setiap teknologi HDR yang didukung.
[C-6-3] HARUS mendukung (minimal) perekaman HLG.
[C-6-4] HARUS mendukung penulisan metadata HDR (jika berlaku untuk teknologi HDR) ke dalam file video yang direkam. Untuk AV1, HEVC, dan DolbyVision, hal ini berarti menyertakan metadata ke dalam bitstream yang dienkode.
[C-6-5] HARUS mendukung P010 dan COLOR_FormatYUVP010.
[C-6-6] HARUS mendukung pemetaan tone HDR ke SDR di decoder dengan akselerasi hardware default untuk profil yang diambil. Dengan kata lain, jika perangkat dapat merekam HDR10+ HEVC, dekoder HEVC default HARUS dapat mendekode streaming yang direkam dalam SDR.
Persyaratan Pengeditan HDR
Jika implementasi perangkat menyertakan encoder video yang mendukung pengeditan HDR, maka perangkat tersebut:
- HARUS menggunakan latensi minimal untuk membuat metadata HDR jika tidak ada, dan HARUS menangani situasi dengan baik saat metadata ada untuk beberapa frame dan tidak untuk yang lain. Metadata ini HARUS akurat (misalnya, mewakili puncak luminans dan histogram frame yang sebenarnya).
Jika implementasi perangkat menyertakan codec yang mendukung FEATURE_HdrEditing
, codec tersebut:
[C-7-1] HARUS mendukung minimal satu profil HDR.
[C-7-2] HARUS mendukung
FEATURE_HdrEditing
untuk semua profil HDR yang diiklankan oleh codec tersebut. Dengan kata lain, codec HARUS mendukung pembuatan metadata HDR jika tidak ada untuk semua profil HDR yang didukung yang menggunakan metadata HDR.[C-7-3] HARUS mendukung format input encoder video berikut yang sepenuhnya mempertahankan sinyal yang didekode HDR:
- RGBA_1010102 (sudah ada di kurva transfer target) untuk platform input dan ByteBuffer dan HARUS mengiklankan dukungan untuk COLOR_Format32bitABGR2101010.
Jika implementasi perangkat menyertakan codec yang mendukung FEATURE_HdrEditing, perangkat:
- [C-7-4] HARUS mengiklankan dukungan untuk ekstensi OpenGL EXT_YUV_target.
6. Kompatibilitas Alat dan Opsi Developer
6.1. Alat Pengembang
Implementasi perangkat:
- [C-0-1] HARUS mendukung Android Developer Tools yang disediakan di Android SDK.
-
- [C-0-2] HARUS mendukung adb seperti yang didokumentasikan dalam Android SDK dan perintah
shell yang disediakan di AOSP, yang dapat digunakan oleh developer aplikasi,
termasuk
dumpsys
cmd stats
- [C-0-11] HARUS mendukung perintah shell
cmd testharness
. Mengupgrade implementasi perangkat dari versi Android sebelumnya tanpa blok data persisten DAPAT dikecualikan dari C-0-11. - [C-0-3] TIDAK BOLEH mengubah format atau konten peristiwa sistem perangkat (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) yang dicatat ke dalam log melalui perintah dumpsys.
- [C-0-10] HARUS merekam, tanpa kelalaian, dan membuat peristiwa berikut
dapat diakses dan tersedia untuk perintah shell
cmd stats
dan class System APIStatsManager
.- ActivityForegroundStateChanged
- AnomalyDetected
- AppBreadcrumbReported
- AppCrashOccurred
- AppStartOccurred
- BatteryLevelChanged
- BatterySaverModeStateChanged
- BleScanResultReceived
- BleScanStateChanged
- ChargingStateChanged
- DeviceIdleModeStateChanged
- ForegroundServiceStateChanged
- GpsScanStateChanged
- JobStateChanged
- PluggedStateChanged
- ScheduledJobStateChanged
- ScreenStateChanged
- SyncStateChanged
- SystemElapsedRealtime
- UidProcessStateChanged
- WakelockStateChanged
- WakeupAlarmOccurred
- WifiLockStateChanged
- WifiMulticastLockStateChanged
- WifiScanStateChanged
- [C-0-4] HARUS memiliki daemon adb sisi perangkat yang tidak aktif secara default dan HARUS ada mekanisme yang dapat diakses pengguna untuk mengaktifkan Android Debug Bridge.
- [C-0-5] HARUS mendukung adb aman. Android menyertakan dukungan untuk adb aman. adb aman mengaktifkan adb di host terautentikasi yang diketahui.
- [C-0-6] HARUS menyediakan mekanisme yang memungkinkan adb terhubung dari komputer host. Khususnya:
Jika penerapan perangkat tanpa port USB mendukung mode periferal, penerapan tersebut:
- [C-3-1] HARUS menerapkan adb melalui jaringan area lokal (seperti Ethernet atau Wi-Fi).
- [C-3-2] HARUS menyediakan driver untuk Windows 7, 8, dan 10, yang memungkinkan developer terhubung ke perangkat menggunakan protokol adb.
Jika implementasi perangkat mendukung koneksi adb ke mesin host melalui Wi-Fi atau Ethernet, implementasi tersebut:
- [C-4-1] HARUS memiliki metode
AdbManager#isAdbWifiSupported()
yang menampilkantrue
.
Jika implementasi perangkat mendukung koneksi adb ke mesin host melalui Wi-Fi atau Ethernet, dan menyertakan setidaknya satu kamera, implementasi tersebut:
- [C-5-1] HARUS memiliki metode
AdbManager#isAdbWifiQrSupported()
yang menampilkantrue
.
- [C-0-2] HARUS mendukung adb seperti yang didokumentasikan dalam Android SDK dan perintah
shell yang disediakan di AOSP, yang dapat digunakan oleh developer aplikasi,
termasuk
Dalvik Debug Monitor Service (ddms)
- [C-0-7] HARUS mendukung semua fitur ddms seperti yang didokumentasikan dalam Android SDK. Karena ddms menggunakan adb, dukungan untuk ddms HARUS tidak aktif secara default, tetapi HARUS didukung setiap kali pengguna mengaktifkan Android Debug Bridge, seperti di atas.
-
- [C-0-9] HARUS mendukung alat systrace seperti yang didokumentasikan dalam Android SDK. Systrace harus tidak aktif secara default dan HARUS ada mekanisme yang dapat diakses pengguna untuk mengaktifkan Systrace.
-
- [C-SR-1] SANGAT DISARANKAN untuk mengekspos biner
/system/bin/perfetto
ke pengguna shell yang cmdline-nya mematuhi dokumentasi perfetto. - [C-SR-2] Biner perfetto SANGAT DISARANKAN untuk menerima sebagai input konfigurasi protobuf yang mematuhi skema yang ditentukan dalam dokumentasi perfetto.
- [C-SR-3] Biner perfetto SANGAT DISARANKAN untuk menulis sebagai output rekaman aktivitas protobuf yang mematuhi skema yang ditentukan dalam dokumentasi perfetto.
- [C-SR-4] SANGAT DIUJAMI untuk menyediakan, melalui biner perfetto, setidaknya sumber data yang dijelaskan dalam dokumentasi perfetto.
- [C-SR-1] SANGAT DISARANKAN untuk mengekspos biner
-
- [C-0-12] HARUS menulis Atom
LMK_KILL_OCCURRED_FIELD_NUMBER
ke log statsd saat aplikasi dihentikan oleh Pembunuh Memori Rendah.
- [C-0-12] HARUS menulis Atom
Mode Harness Pengujian Jika implementasi perangkat mendukung perintah shell
cmd testharness
dan menjalankancmd testharness enable
, perangkat tersebut:- [C-2-1] HARUS menampilkan
true
untukActivityManager.isRunningInUserTestHarness()
- [C-2-2] HARUS menerapkan Mode Test Harness seperti yang dijelaskan dalam dokumentasi Mode Test Harness.
- [C-2-1] HARUS menampilkan
Informasi pekerjaan GPU
Implementasi perangkat:
- [C-0-13] HARUS menerapkan perintah shell
dumpsys gpu --gpuwork
untuk menampilkan data pekerjaan GPU gabungan yang ditampilkan oleh tracepoint kernelpower/gpu_work_period
, atau tidak menampilkan data jika tracepoint tidak didukung. Implementasi AOSP adalahframeworks/native/services/gpuservice/gpuwork/
.
- [C-0-13] HARUS menerapkan perintah shell
Jika implementasi perangkat melaporkan dukungan Vulkan 1.0 atau yang lebih tinggi melalui
flag fitur android.hardware.vulkan.version
, flag tersebut:
- [C-1-1] HARUS memberikan kemampuan bagi developer aplikasi untuk mengaktifkan/menonaktifkan lapisan debug GPU.
- [C-1-2] HARUS, saat lapisan debug GPU diaktifkan, enumerasi lapisan dalam library yang disediakan oleh alat eksternal (yaitu bukan bagian dari platform atau paket aplikasi) yang ditemukan di direktori dasar aplikasi yang dapat di-debug untuk mendukung metode API vkEnumerateInstanceLayerProperties() dan vkCreateInstance().
6.2. Opsi Developer
Android menyertakan dukungan bagi developer untuk mengonfigurasi setelan terkait pengembangan aplikasi.
Implementasi perangkat HARUS memberikan pengalaman yang konsisten untuk Opsi Developer, yaitu:
- [C-0-1] HARUS mematuhi intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS untuk menampilkan setelan terkait pengembangan aplikasi. Implementasi Android upstream menyembunyikan menu Opsi Developer secara default dan memungkinkan pengguna meluncurkan Opsi Developer setelah menekan tujuh (7) kali pada item menu Setelan > Tentang Perangkat > Nomor Build.
- [C-0-2] HARUS menyembunyikan Opsi Developer secara default.
- [C-0-3] HARUS menyediakan mekanisme yang jelas yang tidak memberikan perlakuan preferensi kepada satu aplikasi pihak ketiga, bukan aplikasi lainnya, untuk mengaktifkan Opsi Developer. HARUS memberikan dokumen atau situs yang dapat dilihat publik yang menjelaskan cara mengaktifkan Opsi Developer. Dokumen atau situs ini HARUS dapat ditautkan dari dokumen Android SDK.
- HARUS memiliki notifikasi visual yang berkelanjutan kepada pengguna saat Opsi Developer diaktifkan dan keamanan pengguna menjadi perhatian.
- DAPAT membatasi akses ke menu Opsi Developer untuk sementara, dengan menyembunyikan atau menonaktifkan menu secara visual, untuk mencegah gangguan pada skenario saat keamanan pengguna menjadi perhatian.
7. Kompatibilitas Hardware
Jika perangkat menyertakan komponen hardware tertentu yang memiliki API yang sesuai untuk developer pihak ketiga:
- [C-0-1] Implementasi perangkat HARUS mengimplementasikan API tersebut seperti yang dijelaskan dalam dokumentasi Android SDK.
Jika API di SDK berinteraksi dengan komponen hardware yang dinyatakan sebagai opsional dan implementasi perangkat tidak memiliki komponen tersebut:
- [C-0-2] Definisi class lengkap (seperti yang didokumentasikan oleh SDK) untuk API komponen HARUS tetap ditampilkan.
- [C-0-3] Perilaku API HARUS diimplementasikan sebagai no-ops dengan cara yang wajar.
- [C-0-4] Metode API HARUS menampilkan nilai null jika diizinkan oleh dokumentasi SDK.
- [C-0-5] Metode API HARUS menampilkan implementasi class tanpa operasi jika nilai null tidak diizinkan oleh dokumentasi SDK.
- [C-0-6] Metode API TIDAK BOLEH menampilkan pengecualian yang tidak didokumentasikan oleh dokumentasi SDK.
- [C-0-7] Implementasi perangkat HARUS secara konsisten melaporkan informasi konfigurasi
hardware yang akurat melalui metode
getSystemAvailableFeatures()
danhasSystemFeature(String)
di class android.content.pm.PackageManager untuk sidik jari build yang sama.
Contoh umum skenario tempat persyaratan ini berlaku adalah API telepon: Bahkan di perangkat non-ponsel, API ini harus diterapkan sebagai no-op yang wajar.
7.1. Layar dan Grafis
Android menyertakan fasilitas yang secara otomatis menyesuaikan aset aplikasi dan tata letak
UI dengan tepat untuk perangkat guna memastikan aplikasi pihak ketiga
berjalan dengan baik di berbagai konfigurasi hardware.
berbagai tampilan dan konfigurasi hardware. Layar
yang kompatibel dengan Android adalah layar tampilan yang mengimplementasikan semua
perilaku dan API yang dijelaskan dalam Android Developers - Ringkasan kompatibilitas
layar, bagian
ini (7.1) dan subbagiannya, serta perilaku khusus
jenis perangkat tambahan yang didokumentasikan dalam bagian 2
CDD ini.
Pada layar yang kompatibel dengan Android tempat semua aplikasi
pihak ketiga yang kompatibel dengan Android dapat berjalan, implementasi perangkat HARUS menerapkan API
dan perilaku ini dengan benar, seperti yang dijelaskan di bagian ini.
Memulai persyaratan baru
Implementasi perangkat:
- [C-0-1] HARUS, secara default, merender aplikasi pihak ketiga hanya ke layar yang kompatibel dengan Android.
Akhiri persyaratan baru
Unit yang dirujuk oleh persyaratan di bagian ini ditentukan sebagai berikut:
- ukuran diagonal fisik. Jarak dalam inci antara dua sudut yang berlawanan dari bagian layar yang diterangi.
Kepadatan titik per inci (dpi). Jumlah piksel yang dicakup oleh rentang horizontal atau vertikal linear sebesar 1 inci, yang dinyatakan sebagai piksel per inci (ppi atau dpi). Jika nilaidpippi dan dpi dicantumkan, dpi horizontal dan vertikal harus berada dalam rentang yang dicantumkan.- rasio aspek. Rasio piksel dimensi yang lebih panjang dengan dimensi layar yang lebih pendek. Misalnya, layar 480x854 piksel akan menjadi 854/480 = 1,779, atau kira-kira “16:9”.
- piksel kepadatan mandiri (dp).
Unit piksel virtualA dinormalisasi kelayar 160 dpikepadatan layar 160. Untuk beberapa kepadatan d, dan sejumlah piksel p, jumlah piksel kepadatan mandiri dp, dihitung sebagai:piksel = dps * (kepadatan/160)dp = (160 / d) * p .
7.1.1. Konfigurasi Layar
7.1.1.1. Ukuran dan Bentuk Layar
Framework UI Android mendukung berbagai ukuran tata letak layar
logis, dan memungkinkan aplikasi mengkueri ukuran tata letak
layar konfigurasi saat ini melalui Configuration.screenLayout
dengan SCREENLAYOUT_SIZE_MASK
dan Configuration.smallestScreenWidthDp
.
Implementasi perangkat:
[C-0-1] HARUS melaporkan ukuran tata letak yang benar untuk
Configuration.screenLayout
seperti yang ditentukan dalam dokumentasi Android SDK. Secara khusus, implementasi perangkat HARUS melaporkan dimensi layar piksel kepadatan mandiri (dp) logis yang benar seperti di bawah ini:- Perangkat dengan
Configuration.uiMode
yang ditetapkan sebagai nilai apa pun selain UI_MODE_TYPE_WATCH, dan melaporkan ukuransmall
untukConfiguration.screenLayout
, HARUS memiliki setidaknya 426 dp x 320 dp. - Perangkat yang melaporkan ukuran
normal
untukConfiguration.screenLayout
, HARUS memiliki minimal 480 dp x 320 dp. - Perangkat yang melaporkan ukuran
large
untukConfiguration.screenLayout
, HARUS memiliki minimal 640 dp x 480 dp. - Perangkat yang melaporkan ukuran
xlarge
untukConfiguration.screenLayout
, HARUS memiliki minimal 960 dp x 720 dp.
- Perangkat dengan
[C-0-2] HARUS mematuhi dukungan yang dinyatakan aplikasi untuk ukuran layar dengan benar melalui atribut <
supports-screens
> di AndroidManifest.xml, seperti yang dijelaskan dalam dokumentasi Android SDK.DAPAT memiliki layar yang kompatibel dengan Android dengan sudut membulat.
Jika implementasi perangkat mendukung layar yang mampu
menggunakan konfigurasi ukuran UI_MODE_TYPE_NORMAL
dan menyertakan layar yang kompatibel dengan Android
menggunakan layar fisik dengan
sudut membulat untuk merender layar ini,
layar tersebut:
[C-1-1] HARUS memastikan bahwa setidaknya salah satu persyaratan berikut terpenuhi untuk setiap tampilan tersebut:
- Radius sudut membulat kurang dari atau sama dengan 38 dp.
- Saat
kotak 1518 dp x1518 dp ditambatkan di setiap sudut tampilan logis, setidaknya satu piksel dari setiap kotak akan terlihat di layar.
HARUS menyertakan kemampuan pengguna untuk beralih ke mode tampilan dengan sudut persegi panjang.
Memulai persyaratan baru
Jika implementasi perangkat hanya mampu melakukan konfigurasi keyboard NO_KEYS
,
dan ingin melaporkan dukungan untuk konfigurasi mode
UI UI_MODE_TYPE_NORMAL
, implementasi tersebut:
- [C-4-1] HARUS memiliki ukuran tata letak, tidak termasuk potongan tampilan, minimal 596 dp x 384 dp atau lebih besar.
Akhiri persyaratan baru
Jika implementasi perangkat menyertakan layar yang kompatibel dengan Android dan dapat dilipat, atau menyertakan engsel lipat di antara beberapa panel layar dan membuat layar tersebut tersedia untuk merender aplikasi pihak ketiga, perangkat tersebut:
- [C-2-1] HARUS menerapkan versi stabil terbaru dari extensions API atau versi stabil sidecar API yang akan digunakan oleh library Window Manager Jetpack.
Jika implementasi perangkat menyertakan layar yang kompatibel dengan Android yang dapat dilipat, atau menyertakan engsel lipat di antara beberapa panel layar, dan jika engsel atau lipatan melintasi jendela aplikasi layar penuh, perangkat tersebut:
- [C-3-1] HARUS melaporkan posisi, batas, dan status engsel atau lipat melalui ekstensi atau API sidecar ke aplikasi.
Untuk mengetahui detail tentang cara menerapkan API sidecar atau ekstensi dengan benar, lihat dokumentasi publik Jetpack Window Manager.
Memulai persyaratan baru
Jika implementasi perangkat menyertakan satu atau beberapa area tampilan yang kompatibel dengan Android dan dapat dilipat, atau menyertakan engsel lipat di antara beberapa area panel tampilan yang kompatibel dengan Android dan menyediakan area tampilan tersebut untuk aplikasi, area tersebut:
- [C-4-1] HARUS menerapkan versi API Ekstensi Window Manager yang benar seperti yang dijelaskan dalam Ekstensi WindowManager.
Akhiri persyaratan baru
7.1.1.2. Rasio Aspek Layar
Meskipun tidak ada batasan untuk rasio aspek tampilan fisik untuk
tampilan yang kompatibel dengan Android, rasio aspek tampilan logis
tempat aplikasi pihak ketiga dirender, yang dapat berasal dari nilai tinggi dan
lebar yang dilaporkan melalui view.Display
API dan Configuration
API, HARUS memenuhi persyaratan berikut:
[C-0-1] Implementasi perangkat dengan
Configuration.uiMode
ditetapkan keUI_MODE_TYPE_NORMAL
HARUS memiliki nilai rasio aspek kurang dari atau sama dengan 1,86 (kira-kira 16:9), kecuali jika aplikasi memenuhi salah satu kondisi berikut:- Aplikasi telah mendeklarasikan bahwa aplikasi mendukung rasio aspek layar yang lebih besar
melalui nilai metadata
android.max_aspect
. - Aplikasi mendeklarasikan bahwa ukurannya dapat diubah melalui atribut android:resizeableActivity.
- Aplikasi menargetkan API level 24 atau yang lebih tinggi dan tidak mendeklarasikan
android:maxAspectRatio
yang akan membatasi rasio aspek yang diizinkan.
- Aplikasi telah mendeklarasikan bahwa aplikasi mendukung rasio aspek layar yang lebih besar
melalui nilai metadata
[C-0-3] Implementasi perangkat dengan
Configuration.uiMode
yang ditetapkan sebagaiUI_MODE_TYPE_WATCH
HARUS memiliki nilai rasio aspek yang ditetapkan sebagai 1,0 (1:1).
7.1.1.3. Kepadatan Layar
Framework UI Android menentukan kumpulan kepadatan logis standar untuk membantu developer aplikasi menargetkan resource aplikasi.
Implementasi Perangkat:
- [C-0-1]
Secara default, implementasi perangkatHARUS melaporkanhanyasalah satu kepadatan framework Android yang tercantum diDisplayMetrics
melaluiDENSITY_DEVICE_STABLE
API dan nilai ini harus berupa nilai statis untuk setiap layar fisik.TIDAK BOLEH berubah kapan saja; namun,Namun perangkat DAPAT melaporkankepadatan arbitrerDisplayMetrics.density
yang berbeda sesuai dengan perubahan konfigurasi tampilan yang dilakukan oleh pengguna (misalnya, ukuran tampilan) yang ditetapkan setelah booting awal.
- Implementasi perangkat HARUS menentukan kepadatan framework Android standar yang secara numerik paling dekat dengan kepadatan fisik layar, kecuali jika kepadatan logis tersebut mendorong ukuran layar yang dilaporkan di bawah minimum yang didukung. Jika kepadatan framework Android standar yang secara numerik paling dekat dengan kepadatan fisik menghasilkan ukuran layar yang lebih kecil dari ukuran layar terkecil yang didukung dan kompatibel (lebar 320 dp), implementasi perangkat HARUS melaporkan kepadatan framework Android standar terendah berikutnya.
Memulai persyaratan baru
- HARUS menentukan kepadatan framework Android standar yang secara numerik paling dekat dengan kepadatan fisik layar, atau nilai yang akan dipetakan ke pengukuran bidang pandang sudut yang setara dari perangkat genggam yang sama.
Akhiri persyaratan baru
Jika implementasi perangkat menyediakan
ada kemampuan untuk
mengubah ukuran tampilan perangkat , :
- [C-1-1]
Ukuran tampilan TIDAK BOLEH diskalakanTIDAK BOLEH menskalakan tampilan lebih besar dari 1,5 kaliDENSITY_DEVICE_STABLE
kepadatan nativeatau menghasilkan dimensi layar minimum efektif yang lebih kecil dari 320dp (setara dengan penentu resource sw320dp), mana saja yang lebih dulu. - [C-1-2]
Ukuran layar TIDAK BOLEH diskalakanTIDAK BOLEH menskalakan layar lebih kecil dari 0,85 kaliDENSITY_DEVICE_STABLE
kepadatan native. - Untuk memastikan kegunaan yang baik dan ukuran font yang konsisten, sebaiknya
opsi penskalaan Tampilan Native berikut disediakan (dengan mematuhi batas
yang ditentukan di atas)
- Kecil: 0,85x
- Default: 1x (Skala tampilan native)
- Besar: 1,15x
- Lebih besar: 1,3x
- Terbesar 1,45x
7.1.2. Metrik Display
Jika implementasi perangkat menyertakan layar atau output video yang kompatibel dengan Android ke layar tampilan yang kompatibel dengan Android, implementasi tersebut:
- [C-1-1] HARUS melaporkan nilai yang benar untuk semua metrik tampilan
yang kompatibel dengan Android yang ditentukan dalam
android.util.DisplayMetrics
API.
Jika implementasi perangkat tidak menyertakan layar tersemat atau output video, implementasi tersebut:
- [C-2-1] HARUS melaporkan nilai yang benar dari layar yang kompatibel dengan Android
seperti yang ditentukan dalam
android.util.DisplayMetrics
API untukview.Display
default yang diemulasi.
7.1.3. Orientasi Layar
Implementasi perangkat:
- [C-0-1] HARUS melaporkan orientasi layar yang didukung
(
android.hardware.screen.portrait
dan/atauandroid.hardware.screen.landscape
) dan HARUS melaporkan setidaknya satu orientasi yang didukung. Misalnya, perangkat dengan layar lanskap orientasi tetap, seperti televisi atau laptop, HANYA HARUS melaporkanandroid.hardware.screen.landscape
. - [C-0-2] HARUS melaporkan nilai yang benar untuk orientasi
perangkat saat ini, setiap kali dikueri melalui
android.content.res.Configuration.orientation
,android.view.Display.getOrientation()
, atau API lainnya.
Jika implementasi perangkat mendukung kedua orientasi layar, implementasi tersebut:
- [C-1-1] HARUS mendukung orientasi dinamis oleh aplikasi ke orientasi layar potret atau lanskap. Artinya, perangkat harus mematuhi permintaan aplikasi untuk orientasi layar tertentu.
- [C-1-2] TIDAK BOLEH mengubah ukuran atau kepadatan layar yang dilaporkan saat mengubah orientasi.
- DAPAT memilih orientasi potret atau lanskap sebagai default.
7.1.4. Akselerasi Grafis 2D dan 3D
7.1.4.1 OpenGL ES
Implementasi perangkat:
- [C-0-1] HARUS mengidentifikasi versi OpenGL ES yang didukung (1.1, 2.0,
3.0, 3.1, 3.2) dengan benar melalui API terkelola (seperti melalui
metode
GLES10.getString()
) dan API native. - [C-0-2] HARUS menyertakan dukungan untuk semua API terkelola dan API native yang sesuai untuk setiap versi OpenGL ES yang diidentifikasi untuk didukung.
Jika implementasi perangkat menyertakan output layar atau video, implementasi tersebut:
- [C-1-1] HARUS mendukung OpenGL ES 1.1 dan 2.0, seperti yang diwujudkan dan dijelaskan dalam dokumentasi Android SDK.
- [C-SR-1] SANGAT DIUJAMI untuk mendukung OpenGL ES 3.1.
- HARUS mendukung OpenGL ES 3.2.
Pengujian dEQP OpenGL ES dipartisi menjadi sejumlah daftar pengujian, masing-masing dengan
tanggal/nomor versi terkait. File ini berada di hierarki sumber Android di
external/deqp/android/cts/main/glesXX-main-YYYY-MM-DD.txt
. Perangkat yang
mendukung OpenGL ES pada level yang dilaporkan sendiri menunjukkan bahwa perangkat tersebut dapat lulus pengujian
dEQP di semua daftar pengujian dari level ini dan yang lebih lama.
Jika implementasi perangkat mendukung salah satu versi OpenGL ES, implementasi tersebut:
- [C-2-1] HARUS melaporkan melalui API yang dikelola OpenGL ES dan API native ekstensi OpenGL ES lainnya yang telah diimplementasikan, dan sebaliknya HARUS TIDAK melaporkan string ekstensi yang tidak didukung.
- [C-2-2] HARUS mendukung ekstensi
EGL_KHR_image
,EGL_KHR_image_base
,EGL_ANDROID_image_native_buffer
,EGL_ANDROID_get_native_client_buffer
,EGL_KHR_wait_sync
,EGL_KHR_get_all_proc_addresses
,EGL_ANDROID_presentation_time
,EGL_KHR_swap_buffers_with_damage
,EGL_ANDROID_recordable
, danEGL_ANDROID_GLES_layers
. - [C-2-3] HARUS melaporkan versi maksimum pengujian dEQP OpenGL ES
yang didukung melalui tanda fitur
android.software.opengles.deqp.level
. - [C-2-4] HARUS setidaknya mendukung versi 132383489 (dari 1 Maret 2020) seperti
dilaporkan dalam flag fitur
android.software.opengles.deqp.level
. - [C-2-5] HARUS lulus semua Pengujian dEQP OpenGL ES dalam daftar pengujian antara versi
132383489 dan versi yang ditentukan dalam
flag fitur
android.software.opengles.deqp.level
, untuk setiap versi OpenGL ES yang didukung. - [C-SR-2] SANGAT DIUJAMI untuk mendukung ekstensi
EGL_KHR_partial_update
danOES_EGL_image_external
. HARUS melaporkan secara akurat melalui metode
getString()
, format kompresi tekstur apa pun yang didukungnya, yang biasanya khusus vendor.HARUS mendukung ekstensi
EGL_IMG_context_priority
danEGL_EXT_protected_content
.
Jika implementasi perangkat mendeklarasikan dukungan untuk OpenGL ES 3.0, 3.1, atau 3.2, implementasi tersebut:
- [C-3-1] HARUS mengekspor simbol fungsi yang sesuai untuk versi ini selain simbol fungsi OpenGL ES 2.0 di library libGLESv2.so.
- [C-SR-3] SANGAT DIUJAMI untuk mendukung ekstensi
OES_EGL_image_external_essl3
.
Jika implementasi perangkat mendukung OpenGL ES 3.2, implementasi tersebut:
- [C-4-1] HARUS mendukung OpenGL ES Android Extension Pack secara keseluruhan.
Jika implementasi perangkat mendukung Android Extension Pack OpenGL ES secara keseluruhan, implementasi tersebut:
- [C-5-1] HARUS mengidentifikasi dukungan melalui flag fitur
android.hardware.opengles.aep
.
Jika implementasi perangkat mengekspos dukungan untuk ekstensi
EGL_KHR_mutable_render_buffer
, implementasi tersebut:
- [C-6-1] JUGA HARUS mendukung ekstensi
EGL_ANDROID_front_buffer_auto_refresh
.
Vulkan 7.1.4.2
Android menyertakan dukungan untuk Vulkan, API lintas platform dengan overhead rendah untuk grafis 3D berperforma tinggi.
Jika implementasi perangkat mendukung OpenGL ES 3.1, implementasi tersebut:
- [C-SR-1] SANGAT DISARANKAN untuk menyertakan dukungan untuk Vulkan 1.3.
- [C-4-1] TIDAK BOLEH mendukung versi varian Vulkan (yaitu bagian varian dari versi inti Vulkan HARUS nol).
Jika implementasi perangkat menyertakan output layar atau video, implementasi tersebut:
- [C-SR-2] SANGAT DIUJAMI untuk menyertakan dukungan untuk Vulkan 1.3.
Pengujian dEQP Vulkan dipartisi menjadi sejumlah daftar pengujian, masing-masing dengan
tanggal/versi terkait. File ini berada di hierarki sumber Android di
external/deqp/android/cts/main/vk-main-YYYY-MM-DD.txt
. Perangkat yang
mendukung Vulkan pada tingkat yang dilaporkan sendiri menunjukkan bahwa perangkat tersebut dapat lulus pengujian
dEQP di semua daftar pengujian dari tingkat ini dan yang lebih lama.
Jika implementasi perangkat menyertakan dukungan untuk Vulkan
1.0 atau yang lebih tinggi, implementasi tersebut:
- [C-1-1] HARUS melaporkan nilai bilangan bulat yang benar dengan flag fitur
android.hardware.vulkan.level
danandroid.hardware.vulkan.version
. - [C-1-2] HARUS menghitung, setidaknya satu
VkPhysicalDevice
untuk API native VulkanvkEnumeratePhysicalDevices()
. - [C-1-3] HARUS sepenuhnya menerapkan
Vulkan 1.0Vulkan 1.1 API untuk setiapVkPhysicalDevice
yang dihitung. - [C-1-4] HARUS menghitung lapisan, yang terdapat dalam library native yang dinamai sebagai
libVkLayer*.so
di direktori library native paket aplikasi, melalui API native VulkanvkEnumerateInstanceLayerProperties()
danvkEnumerateDeviceLayerProperties()
. - [C-1-5] TIDAK BOLEH menghitung lapisan yang disediakan oleh library di luar
paket aplikasi, atau memberikan cara lain untuk melacak atau mencegat
Vulkan API, kecuali jika aplikasi memiliki atribut
android:debuggable
yang ditetapkan sebagaitrue
atau metadatacom.android.graphics.injectLayers.enable
yang ditetapkan ketrue
. - [C-1-6] HARUS melaporkan semua string ekstensi yang didukung melalui API native Vulkan , dan sebaliknya TIDAK BOLEH melaporkan string ekstensi yang tidak didukung dengan benar.
- [C-1-7] HARUS mendukung ekstensi VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, dan VK_KHR_incremental_present.
- [C-1-8] HARUS melaporkan versi maksimum Pengujian dEQP Vulkan
yang didukung melalui flag fitur
android.software.vulkan.deqp.level
. - [C-1-9] HARUS setidaknya mendukung versi
132317953
(mulai 1 Maret 2019) seperti dilaporkan dalam flag fiturandroid.software.vulkan.deqp.level
. - [C-1-10] HARUS lulus semua Pengujian dEQP Vulkan dalam daftar pengujian antara
versi
132317953
dan versi yang ditentukan dalam flag fiturandroid.software.vulkan.deqp.level
. - [C-1-11] TIDAK BOLEH menghitung dukungan untuk ekstensi VK_KHR_video_queue, VK_KHR_video_decode_queue, atau VK_KHR_video_encode_queue.
- [C-SR-3] SANGAT DIUJAMI untuk mendukung ekstensi
VK_KHR_driver_properties
danVK_GOOGLE_display_timing
.
- HARUS mendukung
VkPhysicalDeviceProtectedMemoryFeatures
danVK_EXT_global_priority
.
- [C-1-12] TIDAK BOLEH menghitung dukungan untuk ekstensi VK_KHR_performance_query.
- [C-1-13] HARUS memenuhi persyaratan yang ditentukan oleh profil Dasar Pengukuran Android 2021.
- [C-SR-4] SANGAT DIUTAMAKAN untuk memenuhi persyaratan yang ditentukan oleh profil Dasar Pengukuran Android 2022.
Memulai persyaratan baru
[C-SR-5] SANGAT DISARANKAN untuk mendukung
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory
danVK_EXT_global_priority
.[C-SR-6] SANGAT DISARANKAN untuk menggunakan
SkiaVk
dengan HWUI.
Akhiri persyaratan baru
Jika implementasi perangkat tidak menyertakan dukungan untuk Vulkan 1.0, implementasi tersebut:
- [C-2-1] TIDAK BOLEH mendeklarasikan flag fitur Vulkan apa pun (misalnya
android.hardware.vulkan.level
,android.hardware.vulkan.version
). - [C-2-2] TIDAK BOLEH mengenumerasi
VkPhysicalDevice
apa pun untukvkEnumeratePhysicalDevices()
API native Vulkan.
Jika implementasi perangkat menyertakan dukungan untuk Vulkan 1.1 dan mendeklarasikan salah satu tanda fitur Vulkan yang dijelaskan di sini , implementasi tersebut:
- [C-3-1] HARUS mengekspos dukungan untuk semaphore eksternal
SYNC_FD
dan menangani jenis serta ekstensiVK_ANDROID_external_memory_android_hardware_buffer
.
Memulai persyaratan baru
- [C-SR-7] SANGAT DISARANKAN untuk menyediakan ekstensi
VK_KHR_external_fence_fd
ke aplikasi pihak ketiga dan memungkinkan aplikasi mengekspor payload pagar ke dan mengimpor payload pagar dari deskripsi file POSIX seperti yang dijelaskan di sini.
Akhiri persyaratan baru
7.1.4.3 RenderScript
- [C-0-1] Implementasi perangkat HARUS mendukung Android RenderScript, seperti yang dijelaskan dalam dokumentasi Android SDK.
7.1.4.4 Akselerasi Grafis 2D
Android menyertakan mekanisme bagi aplikasi untuk mendeklarasikan bahwa aplikasi ingin mengaktifkan akselerasi hardware untuk grafis 2D di tingkat Aplikasi, Aktivitas, Jendela, atau Tampilan melalui penggunaan tag manifes android:hardwareAccelerated atau panggilan API langsung.
Implementasi perangkat:
- [C-0-1] HARUS mengaktifkan akselerasi hardware secara default, dan HARUS menonaktifkan akselerasi hardware jika developer memintanya dengan menetapkan android:hardwareAccelerated="false” atau menonaktifkan akselerasi hardware langsung melalui Android View API.
- [C-0-2] HARUS menunjukkan perilaku yang konsisten dengan dokumentasi Android SDK tentang akselerasi hardware.
Android menyertakan objek TextureView yang memungkinkan developer mengintegrasikan tekstur OpenGL ES yang diakselerasi hardware secara langsung sebagai target rendering dalam hierarki UI.
Implementasi perangkat:
- [C-0-3] HARUS mendukung TextureView API, dan HARUS menunjukkan perilaku yang konsisten dengan implementasi Android upstream.
7.1.4.5 Layar Rentang Warna Lebar
Jika implementasi perangkat mengklaim dukungan untuk layar gamut lebar melalui
Configuration.isScreenWideColorGamut()
, implementasi tersebut:
- [C-1-1] HARUS memiliki layar yang dikalibrasi warna.
- [C-1-2] HARUS memiliki layar yang gamutnya mencakup gamut warna sRGB sepenuhnya dalam ruang xyY CIE 1931.
- [C-1-3] HARUS memiliki layar yang gamutnya memiliki area minimal 90% DCI-P3 di ruang xyY CIE 1931.
- [C-1-4] HARUS mendukung OpenGL ES 3.1 atau 3.2 dan melaporkannya dengan benar.
- [C-1-5] HARUS mengiklankan dukungan untuk ekstensi
EGL_KHR_no_config_context
,EGL_EXT_pixel_format_float
,EGL_KHR_gl_colorspace
,EGL_EXT_gl_colorspace_scrgb
,EGL_EXT_gl_colorspace_scrgb_linear
,EGL_EXT_gl_colorspace_display_p3
,EGL_EXT_gl_colorspace_display_p3_linear
, danEGL_EXT_gl_colorspace_display_p3_passthrough
. - [C-SR-1] SANGAT DISARANKAN untuk mendukung
GL_EXT_sRGB
.
Sebaliknya, jika implementasi perangkat tidak mendukung layar gamut lebar, perangkat tersebut:
- [C-2-1] HARUS mencakup 100% atau lebih sRGB dalam ruang xyY CIE 1931, meskipun gamut warna layar tidak ditentukan.
7.1.5. Mode Kompatibilitas Aplikasi Lama
Android menentukan “mode kompatibilitas” tempat framework beroperasi dalam mode ukuran layar 'normal' yang setara (lebar 320 dp) untuk kepentingan aplikasi lama yang tidak dikembangkan untuk Android versi lama yang sudah ada sebelum kemerdekaan ukuran layar.
7.1.6. Teknologi Layar
Platform Android menyertakan API yang memungkinkan aplikasi merender grafis lengkap ke layar yang kompatibel dengan Android. Perangkat HARUS mendukung semua API ini seperti yang ditentukan oleh Android SDK, kecuali jika secara khusus diizinkan dalam dokumen ini.
Semua tampilan yang kompatibel dengan Android dari penerapan perangkat:
- [C-0-1] HARUS dapat merender grafis warna 16-bit.
- HARUS mendukung layar yang mampu menampilkan grafis warna 24-bit.
- [C-0-2] HARUS dapat merender animasi.
- [C-0-3] HARUS memiliki rasio aspek piksel (PAR) antara 0,9 dan 1,15. Artinya, rasio aspek piksel HARUS mendekati persegi (1,0) dengan toleransi 10 ~ 15%.
7.1.7. Layar Sekunder
Android menyertakan dukungan untuk layar sekunder yang kompatibel dengan Android guna mengaktifkan kemampuan berbagi media dan API developer untuk mengakses layar eksternal.
Jika implementasi perangkat mendukung layar eksternal melalui koneksi layar tambahan berkabel, nirkabel, atau tersemat, implementasi tersebut:
- [C-1-1] HARUS menerapkan layanan sistem
dan API
DisplayManager
seperti yang dijelaskan dalam dokumentasi Android SDK.
7.2. Perangkat Masukan
Implementasi perangkat:
- [C-0-1] HARUS menyertakan mekanisme input, seperti layar sentuh atau navigasi non-sentuh, untuk menavigasi di antara elemen UI.
7.2.1. Keyboard
Jika implementasi perangkat menyertakan dukungan untuk aplikasi Editor Metode Masukan (IME) pihak ketiga, implementasi tersebut:
- [C-1-1] HARUS mendeklarasikan flag fitur
android.software.input_methods
. - [C-1-2] HARUS menerapkan
Input Management Framework
sepenuhnya - [C-1-3] HARUS memiliki keyboard software yang telah diinstal sebelumnya.
Implementasi perangkat:
- [C-0-1] TIDAK BOLEH menyertakan keyboard hardware yang tidak cocok dengan salah satu format yang ditentukan dalam android.content.res.Configuration.keyboard (QWERTY atau 12 tombol).
- HARUS menyertakan implementasi keyboard virtual tambahan.
- DAPAT menyertakan keyboard hardware.
7.2.2. Navigasi Non-sentuh
Android menyertakan dukungan untuk d-pad, trackball, dan roda sebagai mekanisme untuk navigasi non-sentuh.
Implementasi perangkat:
- [C-0-1] HARUS melaporkan nilai yang benar untuk android.content.res.Configuration.navigation.
Jika implementasi perangkat tidak memiliki navigasi non-sentuh, perangkat tersebut:
- [C-1-1] HARUS menyediakan mekanisme antarmuka pengguna alternatif yang wajar untuk pemilihan dan pengeditan teks, yang kompatibel dengan Mesin Pengelolaan Input. Implementasi open source Android upstream menyertakan mekanisme pemilihan yang cocok untuk digunakan dengan perangkat yang tidak memiliki input navigasi non-sentuh.
7.2.3. Tombol Navigasi
Fungsi Home, Recents, dan Back biasanya disediakan melalui interaksi dengan tombol fisik khusus atau bagian yang berbeda dari layar sentuh, sangat penting untuk paradigma navigasi Android dan oleh karena itu, implementasi perangkat:
- [C-0-1] HARUS memberikan kemampuan pengguna untuk meluncurkan aplikasi terinstal
yang memiliki aktivitas dengan
<intent-filter>
yang ditetapkan denganACTION=MAIN
danCATEGORY=LAUNCHER
atauCATEGORY=LEANBACK_LAUNCHER
untuk implementasi perangkat Televisi. Fungsi Beranda HARUS menjadi mekanisme untuk kemampuan pengguna ini. - HARUS menyediakan tombol untuk fungsi Terbaru dan Kembali.
Jika fungsi Beranda, Terbaru, atau Kembali disediakan, fungsi tersebut:
- [C-1-1] HARUS dapat diakses dengan satu tindakan (misalnya ketuk, klik dua kali, atau gestur) jika salah satunya dapat diakses.
- [C-1-2] HARUS memberikan indikasi yang jelas tentang tindakan tunggal mana yang akan memicu setiap fungsi. Memiliki ikon yang terlihat dicetak pada tombol, menampilkan ikon software di bagian menu navigasi layar, atau memandu pengguna melalui alur demo langkah demi langkah terpandu selama pengalaman penyiapan siap pakai adalah contoh indikasi tersebut.
Implementasi perangkat:
[C-SR-1] SANGAT DISARANKAN untuk tidak menyediakan mekanisme input untuk Fungsi menu karena tidak digunakan lagi dan diganti dengan panel tindakan sejak Android 4.0.
[C-SR-2] SANGAT DISARANKAN untuk menyediakan semua fungsi navigasi sebagai dapat dibatalkan. 'Dapat dibatalkan' didefinisikan sebagai kemampuan pengguna untuk mencegah fungsi navigasi dijalankan (misalnya, kembali ke layar utama, kembali, dll.) jika geser tidak dilepaskan setelah batas tertentu.
Jika implementasi perangkat menyediakan fungsi Menu, implementasi tersebut:
- [C-2-1] HARUS menampilkan tombol menu tambahan tindakan setiap kali pop-up menu tambahan tindakan tidak kosong dan panel tindakan terlihat.
- [C-2-2] TIDAK BOLEH mengubah posisi pop-up tambahan tindakan yang ditampilkan dengan memilih tombol tambahan di panel tindakan, tetapi DAPAT merender pop-up tambahan tindakan pada posisi yang diubah di layar saat ditampilkan dengan memilih fungsi Menu.
Jika implementasi perangkat tidak menyediakan fungsi Menu, untuk kompatibilitas mundur, implementasi tersebut:
- [C-3-1] HARUS menyediakan fungsi Menu untuk aplikasi jika
targetSdkVersion
kurang dari 10, baik dengan tombol fisik, kunci software, atau gestur. Fungsi Menu ini harus dapat diakses kecuali jika disembunyikan bersama fungsi navigasi lainnya.
Jika implementasi perangkat menyediakan Fungsi bantuan, perangkat tersebut:
- [C-4-1] HARUS membuat fungsi Bantuan dapat diakses dengan satu tindakan (misalnya ketuk, klik dua kali, atau gestur) saat tombol navigasi lainnya dapat diakses.
- [C-SR-3] SANGAT DISARANKAN untuk menggunakan tekan lama pada fungsi HOME sebagai interaksi yang ditetapkan ini.
Jika implementasi perangkat menggunakan bagian layar yang berbeda untuk menampilkan tombol navigasi, implementasi tersebut:
- [C-5-1] Tombol navigasi HARUS menggunakan bagian layar yang berbeda, tidak tersedia untuk aplikasi, dan TIDAK BOLEH mengaburkan atau mengganggu bagian layar yang tersedia untuk aplikasi.
- [C-5-2] HARUS menyediakan sebagian tampilan untuk aplikasi yang memenuhi persyaratan yang ditentukan dalam bagian 7.1.1.
- [C-5-3] HARUS mematuhi tanda yang ditetapkan oleh aplikasi melalui metode API
View.setSystemUiVisibility()
, sehingga bagian layar yang berbeda ini (alias menu navigasi) disembunyikan dengan benar seperti yang didokumentasikan dalam SDK.
Jika fungsi navigasi disediakan sebagai tindakan berbasis gestur di layar:
- [C-6-1]
WindowInsets#getMandatorySystemGestureInsets()
HARUS hanya digunakan untuk melaporkan area pengenalan gestur Home. - [C-6-2] Gestur yang dimulai dalam persegi panjang pengecualian seperti yang disediakan oleh
aplikasi latar depan melalui
View#setSystemGestureExclusionRects()
, tetapi di luarWindowInsets#getMandatorySystemGestureInsets()
, TIDAK BOLEH dicegat untuk fungsi navigasi selama persegi panjang pengecualian diizinkan dalam batas pengecualian maksimum seperti yang ditentukan dalam dokumentasi untukView#setSystemGestureExclusionRects()
. - [C-6-3] HARUS mengirim peristiwa
MotionEvent.ACTION_CANCEL
ke aplikasi latar depan setelah sentuhan mulai dicegat untuk gestur sistem, jika aplikasi latar depan sebelumnya dikirim peristiwaMotionEvent.ACTION_DOWN
. - [C-6-4] HARUS memberikan kemampuan pengguna untuk beralih ke navigasi berbasis tombol di layar (misalnya, di Setelan).
- HARUS menyediakan fungsi Home sebagai geser ke atas dari tepi bawah orientasi layar saat ini.
- HARUS menyediakan fungsi Terbaru sebagai geser ke atas dan tahan sebelum dilepaskan, dari area yang sama dengan gestur Beranda.
- Gestur yang dimulai dalam
WindowInsets#getMandatorySystemGestureInsets()
TIDAK BOLEH terpengaruh oleh rects pengecualian yang disediakan oleh aplikasi latar depan melaluiView#setSystemGestureExclusionRects()
.
Jika fungsi navigasi disediakan dari mana saja di tepi kiri dan kanan orientasi layar saat ini:
- [C-7-1] Fungsi navigasi HARUS Kembali dan disediakan sebagai geser dari tepi kiri dan kanan orientasi layar saat ini.
- [C-7-2] Jika panel sistem geser kustom disediakan di tepi kiri atau kanan, panel tersebut HARUS ditempatkan dalam 1/3 bagian atas layar dengan indikasi visual yang jelas dan persisten bahwa menarik akan memanggil panel yang disebutkan di atas, dan bukan Kembali. Panel sistem DAPAT dikonfigurasi oleh pengguna sehingga berada di bawah 1/3 bagian atas tepi layar, tetapi panel sistem TIDAK BOLEH menggunakan lebih dari 1/3 tepi.
- [C-7-3] Jika aplikasi latar depan memiliki flag View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT, atau WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE yang ditetapkan, geser dari tepi HARUS berperilaku seperti yang diterapkan di AOSP, yang didokumentasikan dalam SDK.
- [C-7-4] Jika aplikasi latar depan memiliki flag View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT, atau WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE yang ditetapkan, panel sistem yang dapat digeser kustom HARUS disembunyikan hingga pengguna menampilkan atau menghilangkan redup pada panel sistem (alias navigasi dan status bar) seperti yang diterapkan di AOSP.
Jika fungsi navigasi kembali disediakan dan pengguna membatalkan gestur Kembali, maka:
- [C-8-1]
OnBackInvokedCallback.onBackCancelled()
HARUS dipanggil. - [C-8-2]
OnBackInvokedCallback.onBackInvoked()
TIDAK BOLEH dipanggil. - [C-8-3] Peristiwa KEYCODE_BACK TIDAK BOLEH dikirim.
Jika fungsi navigasi kembali disediakan, tetapi aplikasi latar depan
TIDAK memiliki OnBackInvokedCallback
yang terdaftar, maka:
- Sistem HARUS menyediakan animasi untuk aplikasi latar depan yang menunjukkan bahwa pengguna akan kembali, seperti yang disediakan di AOSP.
Jika implementasi perangkat memberikan dukungan untuk API sistem setNavBarMode
agar
memungkinkan aplikasi sistem dengan izin android.permission.STATUS_BAR
untuk menetapkan
mode menu navigasi, maka:
- [C-9-1] HARUS memberikan dukungan untuk ikon yang cocok untuk anak-anak atau navigasi berbasis tombol seperti yang disediakan dalam kode AOSP.
7.2.4. Input Layar Sentuh
Android menyertakan dukungan untuk berbagai sistem input pointer, seperti layar sentuh, touchpad, dan perangkat input sentuh palsu. Implementasi perangkat berbasis layar sentuh dikaitkan dengan layar sehingga pengguna memiliki kesan memanipulasi item di layar secara langsung. Karena pengguna langsung menyentuh layar, sistem tidak memerlukan kemampuan tambahan untuk menunjukkan objek yang sedang dimanipulasi.
Implementasi perangkat:
- HARUS memiliki sistem input pointer (seperti mouse atau sentuh).
- HARUS mendukung pointer yang dilacak sepenuhnya secara independen.
Jika implementasi perangkat menyertakan layar sentuh (sentuhan tunggal atau lebih baik) di layar utama yang kompatibel dengan Android, perangkat tersebut:
- [C-1-1] HARUS melaporkan
TOUCHSCREEN_FINGER
untuk kolom APIConfiguration.touchscreen
. - [C-1-2] HARUS melaporkan flag fitur
android.hardware.touchscreen
danandroid.hardware.faketouch
.
Jika implementasi perangkat menyertakan layar sentuh yang dapat melacak lebih dari satu sentuhan pada layar utama yang kompatibel dengan Android, perangkat tersebut:
- [C-2-1] HARUS melaporkan flag fitur yang sesuai
android.hardware.touchscreen.multitouch
,android.hardware.touchscreen.multitouch.distinct
,android.hardware.touchscreen.multitouch.jazzhand
yang sesuai dengan jenis layar sentuh tertentu di perangkat.
Jika implementasi perangkat mengandalkan perangkat input eksternal seperti mouse atau trackball (yaitu tidak menyentuh layar secara langsung) untuk input di layar utama yang kompatibel dengan Android dan memenuhi persyaratan sentuhan palsu di bagian 7.2.5, perangkat tersebut:
- [C-3-1] TIDAK BOLEH melaporkan flag fitur apa pun yang diawali dengan
android.hardware.touchscreen
. - [C-3-2] HARUS hanya melaporkan
android.hardware.faketouch
. - [C-3-3] HARUS melaporkan
TOUCHSCREEN_NOTOUCH
untuk kolom APIConfiguration.touchscreen
.
7.2.5. Input Sentuh Palsu
Antarmuka sentuh palsu menyediakan sistem input pengguna yang mendekati subset kemampuan layar sentuh. Misalnya, mouse atau remote control yang menggerakkan kursor pada layar mendekati sentuhan, tetapi mengharuskan pengguna untuk terlebih dahulu mengarahkan atau memfokuskan, lalu mengklik. Banyak perangkat input seperti mouse, trackpad, mouse virtual berbasis giroskop, pointer giroskop, joystick, dan trackpad multi-sentuh dapat mendukung interaksi sentuh palsu. Android menyertakan konstanta fitur android.hardware.faketouch, yang sesuai dengan perangkat input non-sentuh (berbasis pointer) fidelitas tinggi seperti mouse atau trackpad yang dapat mengemulasi input berbasis sentuh secara memadai (termasuk dukungan gestur dasar), dan menunjukkan bahwa perangkat mendukung subset fungsi layar sentuh yang diemulasi.
Jika implementasi perangkat tidak menyertakan layar sentuh, tetapi menyertakan sistem input kursor lain yang ingin disediakan, implementasi tersebut:
- HARUS mendeklarasikan dukungan untuk flag fitur
android.hardware.faketouch
.
Jika implementasi perangkat mendeklarasikan dukungan untuk android.hardware.faketouch
,
implementasi tersebut:
- [C-1-1] HARUS melaporkan posisi layar X dan Y absolut lokasi pointer dan menampilkan pointer visual di layar.
- [C-1-2] HARUS melaporkan peristiwa sentuh dengan kode tindakan yang menentukan perubahan status yang terjadi pada pointer yang bergerak ke bawah atau ke atas di layar.
- [C-1-3] HARUS mendukung pointer ke bawah dan ke atas pada objek di layar, yang memungkinkan pengguna mengemulasi ketukan pada objek di layar.
- [C-1-4] HARUS mendukung pointer ke bawah, pointer ke atas, pointer ke bawah, lalu pointer ke atas di tempat yang sama pada objek di layar dalam batas waktu, yang memungkinkan pengguna mengemulasi ketuk dua kali pada objek di layar.
- [C-1-5] HARUS mendukung pointer ke bawah pada titik arbitrer di layar, pointer berpindah ke titik arbitrer lainnya di layar, diikuti dengan pointer ke atas, yang memungkinkan pengguna mengemulasi tarik sentuh.
- [C-1-6] HARUS mendukung pointer ke bawah, lalu memungkinkan pengguna dengan cepat memindahkan objek ke posisi lain di layar, lalu pointer ke atas di layar, yang memungkinkan pengguna melempar objek di layar.
Jika implementasi perangkat mendeklarasikan dukungan untuk
android.hardware.faketouch.multitouch.distinct
, implementasi tersebut:
- [C-2-1] HARUS mendeklarasikan dukungan untuk
android.hardware.faketouch
. - [C-2-2] HARUS mendukung pelacakan yang berbeda dari dua atau beberapa input kursor independen.
Jika implementasi perangkat mendeklarasikan dukungan untuk
android.hardware.faketouch.multitouch.jazzhand
, implementasi tersebut:
- [C-3-1] HARUS mendeklarasikan dukungan untuk
android.hardware.faketouch
. - [C-3-2] HARUS mendukung pelacakan yang berbeda dari 5 (melacak tangan jari) atau lebih input pointer secara sepenuhnya independen.
7.2.6. Dukungan Pengontrol Game
7.2.6.1. Pemetaan Tombol
Implementasi perangkat:
- [C-1-1] HARUS dapat memetakan peristiwa HID ke konstanta
InputEvent
yang sesuai seperti yang tercantum dalam tabel di bawah. Implementasi Android upstream memenuhi persyaratan ini.
Jika implementasi perangkat menyematkan pengontrol atau dikirimkan dengan pengontrol terpisah dalam kotak yang akan menyediakan cara untuk memasukkan semua peristiwa yang tercantum dalam tabel di bawah, perangkat tersebut:
- [C-2-1] HARUS mendeklarasikan flag fitur
android.hardware.gamepad
Tombol | Penggunaan HID2 | Tombol Android |
---|---|---|
A1 | 0x09 0x0001 | KEYCODE_BUTTON_A (96) |
B1 | 0x09 0x0002 | KEYCODE_BUTTON_B (97) |
X1 | 0x09 0x0004 | KEYCODE_BUTTON_X (99) |
Y1 | 0x09 0x0005 | KEYCODE_BUTTON_Y (100) |
D-pad atas1 D-pad bawah1 |
0x01 0x00393 | AXIS_HAT_Y4 |
Tombol arah kiri1 Tombol arah kanan1 |
0x01 0x00393 | AXIS_HAT_X4 |
Tombol bahu kiri1 | 0x09 0x0007 | KEYCODE_BUTTON_L1 (102) |
Tombol bahu kanan1 | 0x09 0x0008 | KEYCODE_BUTTON_R1 (103) |
Klik tongkat kiri1 | 0x09 0x000E | KEYCODE_BUTTON_THUMBL (106) |
Klik tongkat kanan1 | 0x09 0x000F | KEYCODE_BUTTON_THUMBR (107) |
Back1 | 0x0c 0x0224 | KEYCODE_BACK (4) |
1 KeyEvent
2 Penggunaan HID di atas harus dideklarasikan dalam CA Gamepad (0x01 0x0005).
3 Penggunaan ini harus memiliki Minimum Logika 0, Maksimum Logika 7, Minimum Fisik 0, Maksimum Fisik 315, Unit dalam Derajat, dan Ukuran Laporan 4. Nilai logika ditentukan sebagai rotasi searah jarum jam dari sumbu vertikal; misalnya, nilai logika 0 mewakili tidak ada rotasi dan tombol atas ditekan, sedangkan nilai logika 1 mewakili rotasi 45 derajat dan tombol atas dan kiri ditekan.
Kontrol Analog1 | Penggunaan HID | Tombol Android |
---|---|---|
Pemicu Kiri | 0x02 0x00C5 | AXIS_LTRIGGER |
Pemicu Kanan | 0x02 0x00C4 | AXIS_RTRIGGER |
Joystick Kiri | 0x01 0x0030 0x01 0x0031 |
AXIS_X AXIS_Y |
Joystick Kanan | 0x01 0x0032 0x01 0x0035 |
AXIS_Z AXIS_RZ |
7.2.7. Remote Control
Lihat Bagian 2.3.1 untuk mengetahui persyaratan khusus perangkat.
7.3. Sensor
Jika implementasi perangkat menyertakan jenis sensor tertentu yang memiliki API yang sesuai untuk developer pihak ketiga, implementasi perangkat HARUS menerapkan API tersebut seperti yang dijelaskan dalam dokumentasi Android SDK dan dokumentasi Android Open Source tentang sensor.
Implementasi perangkat:
- [C-0-1] HARUS melaporkan keberadaan atau ketiadaan sensor secara akurat sesuai dengan
class
android.content.pm.PackageManager
. - [C-0-2] HARUS menampilkan daftar sensor yang didukung secara akurat melalui
SensorManager.getSensorList()
dan metode serupa. - [C-0-3] HARUS berperilaku wajar untuk semua API sensor lainnya (misalnya, dengan
menampilkan
true
ataufalse
sebagaimana mestinya saat aplikasi mencoba mendaftarkan pemroses, tidak memanggil pemroses sensor saat sensor yang sesuai tidak ada; dll.).
Jika implementasi perangkat menyertakan jenis sensor tertentu yang memiliki API yang sesuai untuk developer pihak ketiga, API tersebut:
- [C-1-1] HARUS melaporkan semua pengukuran sensor menggunakan nilai Sistem Satuan Internasional (metrik) yang relevan untuk setiap jenis sensor seperti yang ditentukan dalam dokumentasi Android SDK.
- [C-1-2] HARUS melaporkan data sensor dengan latensi maksimum 100 milidetik + 2 * sample_time untuk kasus aliran sensor dengan latensi maksimum yang diminta 0 md saat prosesor aplikasi aktif. Keterlambatan ini tidak mencakup keterlambatan pemfilteran.
- [C-1-3] HARUS melaporkan sampel sensor pertama dalam waktu 400 milidetik + 2 * sample_time sensor yang diaktifkan. Contoh ini dapat menerima akurasi 0.
- [C-1-4] Untuk API apa pun yang ditunjukkan oleh dokumentasi Android SDK sebagai sensor berkelanjutan, implementasi perangkat HARUS terus menyediakan sampel data berkala yang HARUS memiliki jitter di bawah 3%, dengan jitter didefinisikan sebagai deviasi standar dari perbedaan nilai stempel waktu yang dilaporkan antara peristiwa berturut-turut.
- [C-1-5] HARUS memastikan bahwa aliran peristiwa sensor TIDAK BOLEH mencegah CPU perangkat memasuki status penangguhan atau membangunkan dari status penangguhan.
- [C-1-6] HARUS melaporkan waktu peristiwa dalam nanodetik seperti yang ditentukan dalam dokumentasi Android SDK, yang mewakili waktu terjadinya peristiwa dan disinkronkan dengan jam SystemClock.elapsedRealtimeNano().
- [C-SR-1] SANGAT DISARANKAN untuk memiliki error sinkronisasi stempel waktu di bawah 100 milidetik, dan HARUS memiliki error sinkronisasi stempel waktu di bawah 1 milidetik.
- Saat beberapa sensor diaktifkan, konsumsi daya TIDAK BOLEH melebihi jumlah konsumsi daya yang dilaporkan oleh masing-masing sensor.
Daftar di atas tidak komprehensif; perilaku yang didokumentasikan dari Android SDK dan Dokumentasi Open Source Android tentang sensor harus dianggap otoritatif.
Jika implementasi perangkat menyertakan jenis sensor tertentu yang memiliki API yang sesuai untuk developer pihak ketiga, API tersebut:
- [C-1-6] HARUS menetapkan resolusi non-nol untuk semua sensor, dan melaporkan nilai
melalui metode API
Sensor.getResolution()
.
Beberapa jenis sensor bersifat komposit, yang berarti dapat berasal dari data yang disediakan oleh satu atau beberapa sensor lainnya. (Contohnya mencakup sensor orientasi dan sensor akselerasi linear.)
Implementasi perangkat:
- HARUS menerapkan jenis sensor ini, jika menyertakan sensor fisik prasyarat seperti yang dijelaskan dalam jenis sensor.
Jika implementasi perangkat menyertakan sensor komposit, perangkat tersebut:
- [C-2-1] HARUS mengimplementasikan sensor seperti yang dijelaskan dalam dokumentasi Android Open Source tentang sensor komposit.
Jika implementasi perangkat menyertakan jenis sensor tertentu yang memiliki API yang sesuai untuk developer pihak ketiga dan sensor hanya melaporkan satu nilai, implementasi perangkat:
- [C-3-1] HARUS menetapkan resolusi ke 1 untuk sensor dan melaporkan nilai
melalui metode API
Sensor.getResolution()
.
Jika implementasi perangkat menyertakan jenis sensor tertentu yang mendukung SensorAdditionalInfo#TYPE_VEC3_CALIBRATION dan sensor diekspos ke developer pihak ketiga, mereka:
- [C-4-1] TIDAK BOLEH menyertakan parameter kalibrasi tetap yang ditentukan pabrik dalam data yang diberikan.
Jika implementasi perangkat menyertakan kombinasi akselerometer 3 sumbu, sensor giroskop 3 sumbu, atau sensor magnetometer, implementasi tersebut adalah:
- [C-SR-2] SANGAT DIUJAMI untuk memastikan akselerometer, giroskop, dan magnetometer memiliki posisi relatif tetap, sehingga jika perangkat dapat ditransformasi (misalnya perangkat foldable), sumbu sensor tetap sejajar dan konsisten dengan sistem koordinat sensor di semua kemungkinan status transformasi perangkat.
7.3.1. Akselerometer
Implementasi perangkat:
- [C-SR-1] SANGAT DISARANKAN untuk menyertakan akselerometer 3 sumbu.
Jika implementasi perangkat menyertakan akselerometer, perangkat tersebut:
- [C-1-1] HARUS dapat melaporkan peristiwa hingga frekuensi minimal 50 Hz.
- [C-1-3] HARUS mematuhi sistem koordinat sensor Android seperti yang dijelaskan dalam Android API.
- [C-1-4] HARUS dapat mengukur dari jatuh bebas hingga empat kali gravitasi(4g) atau lebih pada sumbu mana pun.
- [C-1-5] HARUS memiliki resolusi minimal 12-bit.
- [C-1-6] HARUS memiliki deviasi standar tidak lebih dari 0,05 m/s^, dengan deviasi standar harus dihitung berdasarkan per sumbu pada sampel yang dikumpulkan selama minimal 3 detik pada kecepatan sampling tercepat.
- HARUS melaporkan peristiwa hingga minimal 200 Hz.
- HARUS memiliki resolusi minimal 16-bit.
- HARUS dikalibrasi saat digunakan jika karakteristik berubah selama siklus proses dan dikompensasi, serta mempertahankan parameter kompensasi antara mulai ulang perangkat.
- HARUS dikompensasi suhu.
Jika implementasi perangkat menyertakan akselerometer 3 sumbu, perangkat tersebut:
- [C-2-1] HARUS menerapkan dan melaporkan sensor
TYPE_ACCELEROMETER
. - [C-SR-4] SANGAT DISARANKAN untuk menerapkan sensor komposit
TYPE_SIGNIFICANT_MOTION
. - [C-SR-5] SANGAT DISARANKAN untuk menerapkan dan melaporkan
sensor
TYPE_ACCELEROMETER_UNCALIBRATED
. Perangkat Android SANGAT DIANJURKAN untuk memenuhi persyaratan ini sehingga dapat diupgrade ke rilis platform mendatang yang mungkin menjadi WAJIB. - HARUS mengimplementasikan sensor komposit
TYPE_SIGNIFICANT_MOTION
,TYPE_TILT_DETECTOR
,TYPE_STEP_DETECTOR
,TYPE_STEP_COUNTER
seperti yang dijelaskan dalam dokumen Android SDK.
Jika implementasi perangkat menyertakan akselerometer dengan kurang dari 3 sumbu, akselerometer tersebut:
- [C-3-1] HARUS menerapkan dan melaporkan sensor
TYPE_ACCELEROMETER_LIMITED_AXES
. - [C-SR-6] SANGAT_DIREKOMENDASIKAN untuk menerapkan dan melaporkan
sensor
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
.
Jika implementasi perangkat menyertakan akselerometer 3 sumbu dan salah satu
sensor komposit TYPE_SIGNIFICANT_MOTION
, TYPE_TILT_DETECTOR
, TYPE_STEP_DETECTOR
,
TYPE_STEP_COUNTER
diterapkan:
- [C-4-1] Jumlah konsumsi dayanya HARUS selalu kurang dari 4 mW.
- HARUS masing-masing di bawah 2 mW dan 0,5 mW saat perangkat dalam kondisi dinamis atau statis.
Jika implementasi perangkat menyertakan akselerometer 3 sumbu dan sensor giroskop 3 sumbu, perangkat tersebut:
- [C-5-1] HARUS menerapkan sensor komposit
TYPE_GRAVITY
danTYPE_LINEAR_ACCELERATION
. - [C-SR-7] SANGAT DISARANKAN untuk menerapkan
sensor gabungan
TYPE_GAME_ROTATION_VECTOR
.
Jika implementasi perangkat menyertakan akselerometer 3 sumbu, sensor giroskop 3 sumbu, dan sensor magnetometer, perangkat tersebut:
- [C-6-1] HARUS menerapkan sensor komposit
TYPE_ROTATION_VECTOR
.
7.3.2. Magnetometer
Implementasi perangkat:
- [C-SR-1] SANGAT DISARANKAN untuk menyertakan magnetometer 3 sumbu (kompas).
Jika implementasi perangkat menyertakan magnetometer 3 sumbu, perangkat tersebut:
- [C-1-1] HARUS mengimplementasikan sensor
TYPE_MAGNETIC_FIELD
. - [C-1-2] HARUS dapat melaporkan peristiwa hingga frekuensi minimal 10 Hz dan HARUS melaporkan peristiwa hingga minimal 50 Hz.
- [C-1-3] HARUS mematuhi sistem koordinat sensor Android seperti yang dijelaskan dalam Android API.
- [C-1-4] HARUS dapat mengukur antara -900 µT dan +900 µT pada setiap sumbu sebelum jenuh.
- [C-1-5] HARUS memiliki nilai offset besi keras kurang dari 700 µT dan HARUS memiliki nilai di bawah 200 µT, dengan menempatkan magnetometer jauh dari medan magnet dinamis (diinduksi arus) dan statis (diinduksi magnet).
- [C-1-6] HARUS memiliki resolusi yang sama atau lebih padat dari 0,6 µT.
- [C-1-7] HARUS mendukung kalibrasi dan kompensasi online bias hard iron, dan mempertahankan parameter kompensasi di antara mulai ulang perangkat.
- [C-1-8] HARUS menerapkan kompensasi besi lunak—kalibrasi dapat dilakukan saat digunakan atau selama produksi perangkat.
- [C-1-9] HARUS memiliki simpangan baku, yang dihitung berdasarkan setiap sumbu pada sampel yang dikumpulkan selama minimal 3 detik pada kecepatan sampling tercepat, tidak lebih dari 1,5 µT; HARUS memiliki simpangan baku tidak lebih dari 0,5 µT.
- [C-1-10] HARUS mengimplementasikan
sensor
TYPE_MAGNETIC_FIELD_UNCALIBRATED
.
Jika implementasi perangkat menyertakan magnetometer 3 sumbu, sensor akselerometer, dan sensor giroskop 3 sumbu, perangkat tersebut:
- [C-2-1] HARUS menerapkan sensor komposit
TYPE_ROTATION_VECTOR
.
Jika implementasi perangkat menyertakan magnetometer 3 sumbu, akselerometer, perangkat tersebut:
- DAPAT menerapkan sensor
TYPE_GEOMAGNETIC_ROTATION_VECTOR
.
Jika implementasi perangkat menyertakan magnetometer 3 sumbu, akselerometer, dan
sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR
, perangkat tersebut:
- [C-3-1] HARUS mengonsumsi daya kurang dari 10 mW.
- HARUS mengonsumsi kurang dari 3 mW saat sensor didaftarkan untuk mode batch pada 10 Hz.
7.3.3. GPS
Implementasi perangkat:
- [C-SR-1] SANGAT DISARANKAN untuk menyertakan penerima GPS/GNSS.
Jika implementasi perangkat menyertakan penerima GPS/GNSS dan melaporkan kemampuan
ke aplikasi melalui flag fitur android.hardware.location.gps
, perangkat tersebut:
- [C-1-1] HARUS mendukung output lokasi dengan kecepatan minimal 1 Hz saat
diminta melalui
LocationManager#requestLocationUpdate
. - [C-1-2] HARUS dapat menentukan lokasi dalam kondisi langit terbuka
(sinyal kuat, multipath yang dapat diabaikan, HDOP < 2) dalam waktu 10 detik (waktu
cepat untuk mendapatkan fix pertama), saat terhubung ke koneksi internet
kecepatan data 0,5 Mbps atau lebih cepat. Persyaratan ini biasanya dipenuhi dengan penggunaan beberapa
bentuk teknik GPS/GNSS yang Dibantu atau Diprediksi
untuk meminimalkan waktu penguncian GPS/GNSS (Data bantuan mencakup Waktu Referensi,
Lokasi Referensi, dan Ephemeris/Jam Satelit).
- [C-1-6] Setelah melakukan penghitungan lokasi tersebut, implementasi perangkat HARUS menentukan lokasinya, di langit terbuka, dalam waktu 5 detik, saat permintaan lokasi dimulai ulang, hingga satu jam setelah penghitungan lokasi awal, meskipun permintaan berikutnya dilakukan tanpa koneksi data, dan/atau setelah siklus daya.
Dalam kondisi langit terbuka setelah menentukan lokasi, saat diam atau bergerak dengan akselerasi kurang dari 1 meter per detik kuadrat:
- [C-1-3] HARUS dapat menentukan lokasi dalam jarak 20 meter, dan kecepatan dalam 0,5 meter per detik, setidaknya 95% dari waktu.
- [C-1-4] HARUS melacak dan melaporkan secara bersamaan melalui
GnssStatus.Callback
setidaknya 8 satelit dari satu konstelasi. - HARUS dapat melacak setidaknya 24 satelit secara bersamaan, dari beberapa konstelasi (misalnya GPS + setidaknya satu dari Glonass, Beidou, Galileo).
[C-SR-2] SANGAT DISARANKAN untuk terus mengirimkan output lokasi GPS/GNSS normal melalui GNSS Location Provider API selama panggilan telepon darurat.
[C-SR-3] SANGAT DISARANKAN untuk melaporkan pengukuran GNSS dari semua konstelasi yang dilacak (seperti yang dilaporkan dalam pesan GnssStatus), kecuali SBAS.
[C-SR-4] SANGAT DIUJAMI untuk melaporkan AGC, dan Frekuensi pengukuran GNSS.
[C-SR-5] SANGAT DISARANKAN untuk melaporkan semua estimasi akurasi (termasuk Bearing, Kecepatan, dan Vertikal) sebagai bagian dari setiap lokasi GPS/GNSS.
[C-SR-6] SANGAT DISARANKAN untuk melaporkan pengukuran GNSS, segera setelah ditemukan, meskipun lokasi yang dihitung dari GPS/GNSS belum dilaporkan.
[C-SR-7] SANGAT DISARANKAN untuk melaporkan pseudorange dan rasio pseudorange GNSS, yang, dalam kondisi langit terbuka setelah menentukan lokasi, saat diam atau bergerak dengan percepatan kurang dari 0,2 meter per detik kuadrat, cukup untuk menghitung posisi dalam 20 meter, dan kecepatan dalam 0,2 meter per detik, setidaknya 95% dari waktu.
7.3.4. Giroskop
Implementasi perangkat:
- [C-SR-1] SANGAT DISARANKAN untuk menyertakan sensor giroskop.
Jika implementasi perangkat menyertakan giroskop, perangkat tersebut:
- [C-1-1] HARUS dapat melaporkan peristiwa hingga frekuensi minimal 50 Hz.
- [C-1-4] HARUS memiliki resolusi 12-bit atau lebih.
- [C-1-5] HARUS memiliki kompensasi suhu.
- [C-1-6] HARUS dikalibrasi dan dikompensasi saat digunakan, serta mempertahankan parameter kompensasi di antara mulai ulang perangkat.
- [C-1-7] HARUS memiliki varians tidak lebih besar dari 1e-7 rad^2 / s^2 per Hz (varians per Hz, atau rad^2 / s). Varians diizinkan untuk bervariasi dengan frekuensi sampling, tetapi HARUS dibatasi oleh nilai ini. Dengan kata lain, jika Anda mengukur varians giroskop pada frekuensi sampling 1 Hz, nilainya TIDAK BOLEH lebih besar dari 1e-7 rad^2/s^2.
- [C-SR-2] Error kalibrasi SANGAT DISARANKAN agar kurang dari 0,01 rad/s saat perangkat diam pada suhu ruangan.
- [C-SR-3] SANGAT DISARANKAN untuk memiliki resolusi 16-bit atau lebih.
- HARUS melaporkan peristiwa hingga minimal 200 Hz.
Jika implementasi perangkat menyertakan giroskop 3 sumbu, perangkat tersebut:
- [C-2-1] HARUS mengimplementasikan sensor
TYPE_GYROSCOPE
. - [C-SR-4] Sangat Direkomendasikan untuk menerapkan sensor
TYPE_GYROSCOPE_UNCALIBRATED
.
Jika implementasi perangkat menyertakan giroskop dengan kurang dari 3 sumbu, perangkat tersebut:
- [C-3-1] HARUS menerapkan dan melaporkan sensor
TYPE_GYROSCOPE_LIMITED_AXES
. - [C-SR-5] SANGAT_DIREKOMENDASIKAN untuk menerapkan dan melaporkan
sensor
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
.
Jika implementasi perangkat menyertakan giroskop 3 sumbu, sensor akselerometer, dan sensor magnetometer, perangkat tersebut:
- [C-4-1] HARUS mengimplementasikan sensor komposit
TYPE_ROTATION_VECTOR
.
Jika implementasi perangkat menyertakan akselerometer 3 sumbu dan sensor giroskop 3 sumbu, implementasi tersebut:
- [C-5-1] HARUS menerapkan sensor komposit
TYPE_GRAVITY
danTYPE_LINEAR_ACCELERATION
. - [C-SR-6] SANGAT DISARANKAN untuk menerapkan
sensor gabungan
TYPE_GAME_ROTATION_VECTOR
.
7.3.5. Barometer
Implementasi perangkat:
- [C-SR-1] SANGAT DISARANKAN untuk menyertakan barometer (sensor tekanan udara sekitar).
Jika implementasi perangkat menyertakan barometer, perangkat tersebut:
- [C-1-1] HARUS mengimplementasikan dan melaporkan sensor
TYPE_PRESSURE
. - [C-1-2] HARUS dapat mengirimkan peristiwa pada kecepatan 5 Hz atau lebih.
- [C-1-3] HARUS memiliki kompensasi suhu.
- [C-SR-2] SANGAT DIUJAMI untuk dapat melaporkan pengukuran tekanan dalam rentang 300hPa hingga 1100hPa.
- HARUS memiliki akurasi absolut 1hPa.
- HARUS memiliki akurasi relatif 0,12hPa pada rentang 20hPa (setara dengan akurasi ~1 m pada perubahan ~200 m di permukaan laut).
7.3.6. Thermometer
Jika implementasi perangkat menyertakan termometer ambien (sensor suhu), perangkat tersebut:
- [C-1-1] HARUS menentukan
SENSOR_TYPE_AMBIENT_TEMPERATURE
untuk sensor suhu ambien dan sensor HARUS mengukur suhu ambien (kabin ruangan/kendaraan) dari tempat pengguna berinteraksi dengan perangkat dalam derajat Celcius.
Jika implementasi perangkat menyertakan sensor termometer yang mengukur suhu selain suhu ambien, seperti suhu CPU, sensor tersebut:
- [C-2-1] TIDAK BOLEH menentukan
SENSOR_TYPE_AMBIENT_TEMPERATURE
untuk sensor suhu.
Jika implementasi perangkat menyertakan sensor untuk memantau suhu kulit, perangkat tersebut:
- [C-SR-1] SANGAT DIUJUDKAN untuk mendukung PowerManager.getThermalHeadroom API.
7.3.7. Fotometer
- Implementasi perangkat DAPAT menyertakan fotometer (sensor cahaya sekitar).
7.3.8. Sensor Kedekatan
- Implementasi perangkat DAPAT menyertakan sensor kedekatan.
Jika implementasi perangkat menyertakan sensor kedekatan dan hanya melaporkan pembacaan biner “dekat” atau “jauh”, perangkat tersebut:
- [C-1-1] HARUS mengukur kedekatan objek dalam arah yang sama dengan layar. Artinya, sensor kedekatan HARUS diorientasikan untuk mendeteksi objek yang dekat dengan layar, karena intent utama jenis sensor ini adalah mendeteksi ponsel yang digunakan oleh pengguna. Jika implementasi perangkat menyertakan sensor kedekatan dengan orientasi lain, sensor tersebut TIDAK BOLEH diakses melalui API ini.
- [C-1-2] HARUS memiliki akurasi 1-bit atau lebih.
- [C-1-3] HARUS menggunakan 0 sentimeter sebagai pembacaan dekat dan 5 sentimeter sebagai pembacaan jauh.
- [C-1-4] HARUS melaporkan rentang dan resolusi maksimum 5.
7.3.9. Sensor Akurasi Tinggi
Jika implementasi perangkat menyertakan serangkaian sensor berkualitas lebih tinggi seperti yang ditentukan di bagian ini, dan menyediakannya untuk aplikasi pihak ketiga, aplikasi tersebut:
- [C-1-1] HARUS mengidentifikasi kemampuan melalui
flag fitur
android.hardware.sensor.hifi_sensors
.
Jika implementasi perangkat mendeklarasikan android.hardware.sensor.hifi_sensors
,
implementasi tersebut:
[C-2-1] HARUS memiliki sensor
TYPE_ACCELEROMETER
yang:- HARUS memiliki rentang pengukuran antara minimal -8 g dan +8 g, dan SANGAT DISARANKAN untuk memiliki rentang pengukuran antara minimal -16 g dan +16 g.
- HARUS memiliki resolusi pengukuran minimal 2048 LSB/g.
- HARUS memiliki frekuensi pengukuran minimum 12,5 Hz atau lebih rendah.
- HARUS memiliki frekuensi pengukuran maksimum 400 Hz atau lebih tinggi; HARUS
mendukung SensorDirectChannel
RATE_VERY_FAST
. - HARUS memiliki derau pengukuran tidak lebih dari 400 μg/√Hz.
- HARUS mengimplementasikan bentuk non-bangun dari sensor ini dengan kemampuan buffering setidaknya 3.000 peristiwa sensor.
- HARUS memiliki konsumsi daya pengelompokan yang tidak lebih buruk dari 3 mW.
- [C-SR-1] SANGAT DISARANKAN untuk memiliki bandwidth pengukuran 3 dB setidaknya 80% dari frekuensi Nyquist, dan spektrum derau putih dalam bandwidth ini.
- HARUS memiliki random walk akselerasi kurang dari 30 μg √Hz yang diuji pada suhu ruangan.
- HARUS memiliki perubahan bias vs. suhu ≤ +/- 1 mg/°C.
- HARUS memiliki non-linearitas garis yang paling sesuai sebesar ≤ 0,5%, dan perubahan sensitivitas vs. suhu sebesar ≤ 0,03%/C°.
- HARUS memiliki sensitivitas lintas sumbu < 2,5 % dan variasi sensitivitas lintas sumbu < 0,2% dalam rentang suhu operasi perangkat.
[C-2-2] HARUS memiliki
TYPE_ACCELEROMETER_UNCALIBRATED
dengan persyaratan kualitas yang sama denganTYPE_ACCELEROMETER
.[C-2-3] HARUS memiliki sensor
TYPE_GYROSCOPE
yang:- HARUS memiliki rentang pengukuran antara minimal -1.000 dan +1.000 dps.
- HARUS memiliki resolusi pengukuran minimal 16 LSB/dps.
- HARUS memiliki frekuensi pengukuran minimum 12,5 Hz atau lebih rendah.
- HARUS memiliki frekuensi pengukuran maksimum 400 Hz atau lebih tinggi; HARUS
mendukung SensorDirectChannel
RATE_VERY_FAST
. - HARUS memiliki derau pengukuran tidak lebih dari 0,014°/s/√Hz.
- [C-SR-2] SANGAT DISARANKAN untuk memiliki bandwidth pengukuran 3 dB setidaknya 80% dari frekuensi Nyquist, dan spektrum derau putih dalam bandwidth ini.
- HARUS memiliki random walk kecepatan kurang dari 0,001 °/s √Hz yang diuji pada suhu ruangan.
- HARUS memiliki perubahan bias vs. suhu ≤ +/- 0,05 °/ s / °C.
- HARUS memiliki perubahan sensitivitas vs. suhu ≤ 0,02% / °C.
- HARUS memiliki non-linearitas garis yang paling cocok sebesar ≤ 0,2%.
- HARUS memiliki kepadatan derau ≤ 0,007 °/s/√Hz.
- HARUS memiliki error kalibrasi kurang dari 0,002 rad/s dalam rentang suhu 10 ~ 40 ℃ saat perangkat diam.
- HARUS memiliki sensitivitas g kurang dari 0,1°/s/g.
- HARUS memiliki sensitivitas lintas sumbu < 4,0 % dan variasi sensitivitas lintas sumbu < 0,3% dalam rentang suhu operasi perangkat.
[C-2-4] HARUS memiliki
TYPE_GYROSCOPE_UNCALIBRATED
dengan persyaratan kualitas yang sama denganTYPE_GYROSCOPE
.[C-2-5] HARUS memiliki sensor
TYPE_GEOMAGNETIC_FIELD
yang:- HARUS memiliki rentang pengukuran antara minimal -900 dan +900 μT.
- HARUS memiliki resolusi pengukuran minimal 5 LSB/uT.
- HARUS memiliki frekuensi pengukuran minimum 5 Hz atau lebih rendah.
- HARUS memiliki frekuensi pengukuran maksimum 50 Hz atau lebih tinggi.
- HARUS memiliki derau pengukuran tidak lebih dari 0,5 uT.
[C-2-6] HARUS memiliki
TYPE_MAGNETIC_FIELD_UNCALIBRATED
dengan persyaratan kualitas yang sama denganTYPE_GEOMAGNETIC_FIELD
dan selain itu:- HARUS mengimplementasikan bentuk non-bangun dari sensor ini dengan kemampuan buffering setidaknya 600 peristiwa sensor.
- [C-SR-3] SANGAT DIUJAMI untuk memiliki spektrum derau putih dari 1 Hz hingga setidaknya 10 Hz jika kecepatan laporan adalah 50 Hz atau lebih tinggi.
[C-2-7] HARUS memiliki sensor
TYPE_PRESSURE
yang:- HARUS memiliki rentang pengukuran antara minimal 300 dan 1100 hPa.
- HARUS memiliki resolusi pengukuran minimal 80 LSB/hPa.
- HARUS memiliki frekuensi pengukuran minimum 1 Hz atau lebih rendah.
- HARUS memiliki frekuensi pengukuran maksimum 10 Hz atau lebih tinggi.
- HARUS memiliki derau pengukuran tidak lebih dari 2 Pa/√Hz.
- HARUS mengimplementasikan bentuk non-bangun dari sensor ini dengan kemampuan buffering setidaknya 300 peristiwa sensor.
- HARUS memiliki konsumsi daya pengelompokan yang tidak lebih buruk dari 2 mW.
[C-2-8] HARUS memiliki sensor
TYPE_GAME_ROTATION_VECTOR
.[C-2-9] HARUS memiliki sensor
TYPE_SIGNIFICANT_MOTION
yang:- HARUS memiliki konsumsi daya tidak lebih buruk dari 0,5 mW saat perangkat statis dan 1,5 mW saat perangkat bergerak.
[C-2-10] HARUS memiliki sensor
TYPE_STEP_DETECTOR
yang:- HARUS menerapkan bentuk non-bangun dari sensor ini dengan kemampuan buffering setidaknya 100 peristiwa sensor.
- HARUS memiliki konsumsi daya tidak lebih buruk dari 0,5 mW saat perangkat statis dan 1,5 mW saat perangkat bergerak.
- HARUS memiliki konsumsi daya pengelompokan yang tidak lebih buruk dari 4 mW.
[C-2-11] HARUS memiliki sensor
TYPE_STEP_COUNTER
yang:- HARUS memiliki konsumsi daya tidak lebih buruk dari 0,5 mW saat perangkat statis dan 1,5 mW saat perangkat bergerak.
[C-2-12] HARUS memiliki sensor
TILT_DETECTOR
yang:- HARUS memiliki konsumsi daya tidak lebih buruk dari 0,5 mW saat perangkat statis dan 1,5 mW saat perangkat bergerak.
[C-2-13] Stempel waktu peristiwa dari peristiwa fisik yang sama yang dilaporkan oleh Akselerometer, Giroskop, dan Magnetometer HARUS berada dalam jarak 2,5 milidetik dari satu sama lain. Stempel waktu peristiwa dari peristiwa fisik yang sama yang dilaporkan oleh Akselerasi dan Giroskop HARUS dalam jarak 0,25 milidetik satu sama lain.
[C-2-14] HARUS memiliki stempel waktu peristiwa sensor Giroskop pada basis waktu yang sama dengan subsistem kamera dan dalam error 1 milidetik.
[C-2-15] HARUS mengirimkan sampel ke aplikasi dalam waktu 5 milidetik sejak data tersedia di salah satu sensor fisik di atas ke aplikasi.
[C-2-16] TIDAK BOLEH memiliki konsumsi daya lebih tinggi dari 0,5 mW saat perangkat statis dan 2,0 mW saat perangkat bergerak saat kombinasi sensor berikut diaktifkan:
SENSOR_TYPE_SIGNIFICANT_MOTION
SENSOR_TYPE_STEP_DETECTOR
SENSOR_TYPE_STEP_COUNTER
SENSOR_TILT_DETECTORS
[C-2-17] BOLEH memiliki sensor
TYPE_PROXIMITY
, tetapi jika ada, HARUS memiliki kemampuan buffering minimum 100 peristiwa sensor.
Perhatikan bahwa semua persyaratan konsumsi daya di bagian ini tidak mencakup konsumsi daya dari Application Processor. Hal ini mencakup daya yang diambil oleh seluruh rantai sensor—sensor, sirkuit pendukung, sistem pemrosesan sensor khusus, dll.
Jika implementasi perangkat menyertakan dukungan sensor langsung, perangkat tersebut:
- [C-3-1] HARUS mendeklarasikan dukungan jenis saluran langsung dan tingkat
tingkat laporan langsung dengan benar melalui API
isDirectChannelTypeSupported
dangetHighestDirectReportRateLevel
. - [C-3-2] HARUS mendukung setidaknya salah satu dari dua jenis saluran langsung sensor untuk semua sensor yang mendeklarasikan dukungan untuk saluran langsung sensor.
- HARUS mendukung pelaporan peristiwa melalui saluran langsung sensor untuk sensor
utama (varian non-aktif) dari jenis berikut:
TYPE_ACCELEROMETER
TYPE_ACCELEROMETER_UNCALIBRATED
TYPE_GYROSCOPE
TYPE_GYROSCOPE_UNCALIBRATED
TYPE_MAGNETIC_FIELD
TYPE_MAGNETIC_FIELD_UNCALIBRATED
7.3.10. Sensor Biometrik
Untuk latar belakang tambahan tentang Mengukur Keamanan Buka Kunci Biometrik, lihat dokumentasi Mengukur Keamanan Biometrik.
Jika implementasi perangkat menyertakan layar kunci yang aman, perangkat tersebut:
- HARUS menyertakan sensor biometrik
Sensor biometrik dapat diklasifikasikan sebagai Class 3 (sebelumnya Kuat), Class 2 (sebelumnya Lemah), atau Class 1 (sebelumnya Kemudahan) berdasarkan tingkat penerimaan spoof dan penipu, serta keamanan pipeline biometrik. Klasifikasi ini menentukan kemampuan sensor biometrik untuk berinteraksi dengan platform dan dengan aplikasi pihak ketiga. Sensor harus memenuhi persyaratan tambahan seperti yang dijelaskan di bawah jika ingin diklasifikasikan sebagai Kelas 1, Kelas 2, atau Kelas 3. Biometrik Class 2 dan Class 3 mendapatkan kemampuan tambahan seperti yang dijelaskan di bawah.
Jika implementasi perangkat menyediakan sensor biometrik untuk aplikasi pihak ketiga melalui android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt, dan android.provider.Settings.ACTION_BIOMETRIC_ENROLL, aplikasi tersebut:
- [C-4-1] HARUS memenuhi persyaratan untuk biometrik Class 3 atau Class 2 seperti yang ditentukan dalam dokumen ini.
- [C-4-2] HARUS mengenali dan mematuhi setiap nama parameter yang ditentukan sebagai konstanta dalam class Pengautentikasi dan kombinasinya. Sebaliknya, TIDAK BOLEH mematuhi atau mengenali konstanta bilangan bulat yang diteruskan ke metode canAuthenticate(int) dan setAllowedAuthenticators(int) selain yang didokumentasikan sebagai konstanta publik di Authenticators dan kombinasinya.
- [C-4-3] HARUS mengimplementasikan tindakan ACTION_BIOMETRIC_ENROLL di perangkat yang memiliki biometrik Kelas 3 atau Kelas 2. Tindakan ini HANYA BOLEH menampilkan titik entri pendaftaran untuk biometrik Kelas 3 atau Kelas 2.
Jika implementasi perangkat mendukung biometrik pasif, perangkat tersebut:
- [C-5-1] HARUS secara default mewajibkan langkah konfirmasi tambahan (misalnya, penekanan tombol).
- [C-SR-1] SANGAT DISARANKAN untuk memiliki setelan yang memungkinkan pengguna mengganti preferensi aplikasi dan selalu mewajibkan langkah konfirmasi yang menyertainya.
- [C-SR-2] SANGAT DISARANKAN untuk mengamankan tindakan konfirmasi sehingga kompromi sistem operasi atau kernel tidak dapat melakukan spoofing. Misalnya, ini berarti bahwa tindakan konfirmasi berdasarkan tombol fisik diarahkan melalui pin input/output (GPIO) tujuan umum khusus input dari elemen aman (SE) yang tidak dapat didorong oleh cara lain selain menekan tombol fisik.
- [C-5-2] HARUS juga menerapkan alur autentikasi implisit (tanpa langkah konfirmasi) yang sesuai dengan setConfirmationRequired(boolean), yang dapat ditetapkan aplikasi untuk digunakan dalam alur login.
Jika implementasi perangkat memiliki beberapa sensor biometrik, perangkat tersebut:
Memulai persyaratan baru
[C-7-1] HARUS, jika biometrik terkunci (yaitu biometrik dinonaktifkan hingga pengguna membuka kunci dengan autentikasi utama) atau terkunci dalam jangka waktu tertentu (yaitu biometrik dinonaktifkan untuk sementara hingga pengguna menunggu interval waktu) karena terlalu banyak upaya yang gagal, juga kunci semua biometrik lainnya dari class biometrik yang lebih rendah. Dalam kasus penguncian dengan batasan waktu, waktu tunggu untuk verifikasi biometrik HARUS berupa waktu tunggu maksimum dari semua biometrik dalam penguncian dengan batasan waktu.
[C-SR-12] SANGAT DIUJAMI, saat biometrik terkunci (yaitu biometrik dinonaktifkan hingga pengguna membuka kunci dengan autentikasi utama) atau kunci waktu (yaitu biometrik dinonaktifkan untuk sementara hingga pengguna menunggu interval waktu) karena terlalu banyak upaya yang gagal, untuk juga mengunci semua biometrik lain dari class biometrik yang sama. Dalam kasus kunci waktu, waktu tunggu untuk verifikasi biometrik SANGAT DIANJURKAN untuk menjadi waktu tunggu maksimum dari semua biometrik dalam kunci waktu.
[C-7-2] HARUS meminta pengguna untuk memberikan autentikasi utama yang direkomendasikan (misalnya: PIN, pola, sandi) untuk mereset penghitung penguncian untuk biometrik yang terkunci. Biometrik Class 3 DAPAT diizinkan untuk mereset penghitung kunci untuk biometrik terkunci dari class yang sama atau lebih rendah. Biometrik Kelas 2 atau Kelas 1 TIDAK BOLEH diizinkan untuk menyelesaikan operasi kunci ulang untuk biometrik apa pun.
Akhiri persyaratan baru
- [C-SR-3] SANGAT DISARANKAN untuk hanya mewajibkan satu biometrik dikonfirmasi per autentikasi (misalnya, jika sensor sidik jari dan wajah tersedia di perangkat, onAuthenticationSucceeded harus dikirim setelah salah satunya dikonfirmasi).
Agar implementasi perangkat mengizinkan akses ke kunci keystore ke aplikasi pihak ketiga, implementasi tersebut harus:
- [C-6-1] HARUS memenuhi persyaratan untuk Kelas 3 seperti yang ditentukan di bagian ini di bawah.
- [C-6-2] HARUS hanya menampilkan biometrik Class 3 jika autentikasi memerlukan BIOMETRIC_STRONG, atau autentikasi dipanggil dengan CryptoObject.
Jika implementasi perangkat ingin memperlakukan sensor biometrik sebagai Kelas 1 (sebelumnya Kemudahan), implementasi tersebut:
- [C-1-1] HARUS memiliki rasio penerimaan palsu kurang dari 0,002%.
- [C-1-2] HARUS mengungkapkan bahwa mode ini mungkin kurang aman dibandingkan dengan PIN, pola, atau sandi yang kuat dan mencantumkan dengan jelas risiko mengaktifkannya, jika tingkat penerimaan spoof dan penipu lebih tinggi dari 7% seperti yang diukur oleh Protokol Pengujian Biometrik Android.
- [C-1-9] HARUS menantang pengguna untuk autentikasi primer yang direkomendasikan (misalnya, PIN, pola, sandi) setelah tidak lebih dari dua puluh percobaan palsu dan tidak kurang dari waktu tunggu sembilan puluh detik untuk verifikasi biometrik - dengan percobaan palsu adalah percobaan dengan kualitas pengambilan yang memadai (BIOMETRIC_ACQUIRED_GOOD) yang tidak cocok dengan biometrik terdaftar.
- [C-SR-4] SANGAT DISARANKAN untuk menurunkan jumlah total percobaan palsu untuk verifikasi biometrik yang ditentukan dalam [C-1-9] jika rasio penerimaan spoof dan imposte lebih tinggi dari 7% seperti yang diukur oleh Protokol Pengujian Biometrik Android.
- [C-1-3] HARUS membatasi rasio percobaan untuk verifikasi biometrik - dengan
percobaan palsu adalah percobaan dengan kualitas pengambilan yang memadai
(
BIOMETRIC_ACQUIRED_GOOD
) yang tidak cocok dengan biometrik terdaftar. - [C-SR-5] SANGAT DISARANKAN untuk membatasi upaya rating setidaknya 30 detik setelah lima percobaan palsu untuk verifikasi biometrik untuk jumlah maksimum percobaan palsu per [C-1-9] - dengan percobaan palsu adalah percobaan dengan kualitas pengambilan yang memadai (BIOMETRIC_ACQUIRED_GOOD) yang tidak cocok dengan biometrik terdaftar.
- [C-SR-6] SANGAT DISARANKAN untuk memiliki semua logika pembatasan kapasitas di TEE.
[C-1-10] HARUS menonaktifkan biometrik setelah backoff autentikasi utama dipicu pertama kali seperti yang dijelaskan dalam [C-0-2] di bagian 9.11.
[C-1-11] HARUS memiliki tingkat penerimaan spoof dan penipu tidak lebih tinggi dari 30%, dengan (1) tingkat penerimaan spoof dan penipu untuk spesies instrument serangan presentasi (PAI) Level A tidak lebih tinggi dari 30%, dan (2) tingkat penerimaan spoof dan penipu dari spesies PAI Level B tidak lebih tinggi dari 40%, seperti yang diukur oleh Protokol Pengujian Biometrik Android.
[C-1-4] HARUS mencegah penambahan biometrik baru tanpa terlebih dahulu menetapkan rantai kepercayaan dengan meminta pengguna mengonfirmasi kredensial perangkat yang ada atau menambahkan kredensial perangkat baru (PIN/pola/sandi) yang diamankan oleh TEE; implementasi Project Open Source Android menyediakan mekanisme dalam framework untuk melakukannya.
[C-1-5] HARUS menghapus sepenuhnya semua data biometrik yang dapat diidentifikasi untuk pengguna saat akun pengguna dihapus (termasuk melalui reset ke setelan pabrik).
[C-1-6] HARUS mematuhi flag individual untuk biometrik tersebut (yaitu
DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT
,DevicePolicymanager.KEYGUARD_DISABLE_FACE
, atauDevicePolicymanager.KEYGUARD_DISABLE_IRIS
).[C-1-7] HARUS meminta pengguna untuk melakukan autentikasi primer yang direkomendasikan (misalnya, PIN, pola, sandi) sekali setiap 24 jam atau kurang. Catatan: Mengupgrade perangkat yang diluncurkan di Android versi 9 atau yang lebih lama HARUS meminta pengguna untuk melakukan autentikasi utama yang direkomendasikan (misalnya, PIN, pola, sandi) sekali setiap 72 jam atau kurang.
[C-1-8] HARUS meminta pengguna untuk melakukan autentikasi utama yang direkomendasikan (misalnya: PIN, pola, sandi) atau biometrik Class 3 (KUAT) setelah salah satu hal berikut:
- periode waktu tunggu tidak ada aktivitas selama 4 jam, ATAU
- 3 upaya autentikasi biometrik gagal.
- Periode waktu tunggu tidak ada aktivitas dan jumlah autentikasi yang gagal akan direset setelah konfirmasi kredensial perangkat berhasil. Catatan: Mengupgrade perangkat yang diluncurkan di Android versi 9 atau yang lebih lama DAPAT dikecualikan dari C-1-8.
[C-SR-7] SANGAT DISARANKAN untuk menggunakan logika dalam framework yang disediakan oleh Project Open Source Android untuk menerapkan batasan yang ditentukan dalam [C-1-7] dan [C-1-8] untuk perangkat baru.
[C-SR-8] SANGAT DISARANKAN untuk memiliki rasio penolakan palsu kurang dari 10%, seperti yang diukur di perangkat.
[C-SR-9] SANGAT DISARANKAN untuk memiliki latensi di bawah 1 detik, diukur dari saat biometrik terdeteksi, hingga layar dibuka kuncinya, untuk setiap biometrik yang terdaftar.
Memulai persyaratan baru
[C-1-12] HARUS memiliki tingkat penerimaan spoof dan penipu tidak lebih tinggi dari 40% per jenis presentation attack instrument (PAI), seperti yang diukur oleh Protokol Pengujian Biometrik Android.
[C-SR-13] SANGAT DIUJAMI untuk memiliki tingkat penerimaan spoof dan penipu tidak lebih tinggi dari 30% per jenis alat serangan presentasi (PAI), seperti yang diukur oleh Protokol Pengujian Biometrik Android.
[C-SR-14] SANGAT DISARANKAN untuk mengungkapkan class biometrik sensor biometrik dan risiko yang terkait dengan mengaktifkannya.
[C-SR-17] SANGAT DIUTAMAKAN untuk mengimplementasikan antarmuka AIDL baru (seperti,
IFace.aidl
danIFingerprint.aidl
).
Akhiri persyaratan baru
Jika implementasi perangkat ingin memperlakukan sensor biometrik sebagai Kelas 2 (sebelumnya Lemah), implementasi tersebut:
[C-2-1] HARUS memenuhi semua persyaratan untuk Kelas 1 di atas.
[C-2-2] HARUS memiliki tingkat penerimaan spoof dan penipu tidak lebih tinggi dari 20%, dengan (1) tingkat penerimaan spoof dan penipu untuk spesies alat serangan presentasi (PAI) Level A tidak lebih tinggi dari 20%, dan (2) tingkat penerimaan spoof dan penipu dari spesies PAI Level B tidak lebih tinggi dari 30%, seperti yang diukur oleh Protokol Pengujian Biometrik Android.
Memulai persyaratan baru
- [C-SR-15] SANGAT DIUJAMI untuk memiliki tingkat penerimaan spoof dan penipu tidak lebih tinggi dari 20% per jenis instrument serangan presentasi (PAI), seperti yang diukur oleh Protokol Pengujian Biometrik Android.
Akhiri persyaratan baru
- [C-2-3] HARUS melakukan
pencocokan biometrik di lingkungan eksekusi terisolasi di luar ruang kernel atau pengguna
Android, seperti Trusted Execution Environment (TEE),
ataudi chip dengan saluran aman ke lingkungan eksekusi terisolasi atau di Protected Virtual Machine yang memenuhi persyaratan di Bagian 9.17. - [C-2-4] HARUS memiliki semua data yang dapat diidentifikasi yang dienkripsi dan diautentikasi secara kriptografis sehingga tidak dapat diperoleh, dibaca, atau diubah di luar lingkungan eksekusi terisolasi atau chip dengan saluran aman ke lingkungan eksekusi terisolasi seperti yang didokumentasikan dalam panduan penerapan di situs Project Open Source Android atau Virtual Machine yang Dilindungi yang dikontrol oleh hypervisor yang memenuhi persyaratan di Bagian 9.17.
- [C-2-5] Untuk biometrik berbasis kamera, saat autentikasi atau pendaftaran berbasis biometrik sedang berlangsung:
- HARUS mengoperasikan kamera dalam mode yang mencegah frame kamera dibaca atau diubah di luar trusted execution environment atau chip dengan saluran aman ke trusted execution environment atau Protected Virtual Machine yang dikontrol oleh hypervisor yang memenuhi persyaratan di Bagian 9.17.
- Untuk solusi kamera tunggal RGB, frame kamera DAPAT dibaca di luar lingkungan eksekusi terisolasi untuk mendukung operasi seperti pratinjau untuk pendaftaran, tetapi TETAP TIDAK BOLEH diubah.
- [C-2-6] TIDAK BOLEH mengaktifkan aplikasi pihak ketiga untuk membedakan pendaftaran biometrik individual.
- [C-2-7] TIDAK BOLEH mengizinkan akses yang tidak dienkripsi ke data biometrik yang dapat diidentifikasi atau data apa pun yang berasal darinya (seperti penyematan) ke Application Processor di luar konteks TEE atau Virtual Machine yang Dilindungi yang dikontrol oleh hypervisor yang memenuhi persyaratan di Bagian 9.17. Perangkat yang diupgrade yang diluncurkan di Android versi 9 atau yang lebih lama tidak dikecualikan dari C-2-7.
[C-2-8] HARUS memiliki pipeline pemrosesan yang aman sehingga kompromi sistem operasi atau kernel tidak dapat mengizinkan data dimasukkan secara langsung untuk melakukan autentikasi palsu sebagai pengguna. Catatan: Jika implementasi perangkat sudah diluncurkan di Android versi 9 atau yang lebih lama dan tidak dapat memenuhi persyaratan C-2-8 melalui update software sistem, implementasi tersebut DAPAT dikecualikan dari persyaratan.
[C-SR-10] SANGAT DISARANKAN untuk menyertakan deteksi keaktifan untuk semua modalitas biometrik dan deteksi perhatian untuk biometrik Wajah.
[C-2-9] HARUS menyediakan sensor biometrik untuk aplikasi pihak ketiga.
Jika implementasi perangkat ingin memperlakukan sensor biometrik sebagai Kelas 3 (sebelumnya Kuat), implementasi tersebut:
- [C-3-1] HARUS memenuhi semua persyaratan Kelas 2 di atas, kecuali [C-1-7] dan [C-1-8].
- [C-3-2] HARUS memiliki implementasi keystore yang didukung hardware.
- [C-3-3] HARUS memiliki tingkat penerimaan spoof dan penipu tidak lebih tinggi dari 7%, dengan (1) tingkat penerimaan spoof dan penipu untuk spesies alat serangan presentasi (PAI) Level A tidak lebih tinggi dari 7%, dan (2) tingkat penerimaan spoof dan penipu dari spesies PAI Level B tidak lebih tinggi dari 20%, seperti yang diukur oleh Protokol Pengujian Biometrik Android.
- [C-3-4] HARUS meminta pengguna untuk melakukan autentikasi primer yang direkomendasikan (misalnya, PIN, pola, sandi) sekali setiap 72 jam atau kurang.
- [C-3-5] HARUS membuat ulang ID Pengautentikasi untuk semua biometrik Class 3 yang didukung di perangkat jika salah satunya didaftarkan ulang.
- [C-3-6] Harus mengaktifkan kunci keystore yang didukung biometrik ke aplikasi pihak ketiga.
Memulai persyaratan baru
- [C-SR-16] SANGAT DIUJAMI untuk memiliki tingkat penerimaan spoof dan penipu tidak lebih tinggi dari 7% per jenis presentation attack instrument (PAI), seperti yang diukur oleh Protokol Pengujian Biometrik Android.
Akhiri persyaratan baru
Jika implementasi perangkat berisi sensor sidik jari di bawah layar (UDFPS), perangkat tersebut:
- [C-SR-11] SANGAT DIUJAMI untuk mencegah area UDFPS yang dapat disentuh mengganggu navigasi 3 tombol (yang mungkin diperlukan oleh beberapa pengguna untuk tujuan aksesibilitas).
7.3.11. Sensor Pose
Implementasi perangkat:
- DAPAT mendukung sensor pose dengan 6 derajat kebebasan.
Jika implementasi perangkat mendukung sensor pose dengan 6 derajat kebebasan, perangkat tersebut:
- [C-1-1] HARUS mengimplementasikan dan melaporkan sensor
TYPE_POSE_6DOF
. - [C-1-2] HARUS lebih akurat daripada vektor rotasi saja.
7.3.12. Sensor Sudut Engsel
Jika implementasi perangkat mendukung sensor sudut engsel, perangkat tersebut:
- [C-1-1] HARUS menerapkan dan melaporkan
TYPE_HINGLE_ANGLE
. - [C-1-2] HARUS mendukung minimal dua pembacaan antara 0 dan 360 derajat (inklusif, yaitu termasuk 0 dan 360 derajat).
- [C-1-3] HARUS menampilkan sensor bangun
untuk
getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE)
.
7.3.13. IEEE 802.1.15.4 (UWB)
Jika implementasi perangkat menyertakan dukungan untuk 802.1.15.4 dan mengekspos fungsi ke aplikasi pihak ketiga, implementasi tersebut:
Memulai persyaratan baru
- [C-1-2] HARUS melaporkan tanda fitur hardware
android.hardware.uwb
. - [C-1-3] HARUS mendukung semua kumpulan konfigurasi berikut (kombinasi parameter FIRA UCI
yang telah ditentukan sebelumnya)
yang ditentukan dalam penerapan AOSP.
CONFIG_ID_1
: Pengukuran rentangSTATIC STS DS-TWR
unicast yang ditentukan FiRa, mode yang ditangguhkan, interval pengukuran rentang 240 md.CONFIG_ID_2
: Pengukuran rentangSTATIC STS DS-TWR
satu ke banyak yang ditentukan FiRa, mode yang ditangguhkan, interval pengukuran rentang 200 md. Kasus penggunaan umum: smartphone berinteraksi dengan banyak perangkat smart.CONFIG_ID_3
: Sama sepertiCONFIG_ID_1
, kecuali data Sudut kedatangan (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 kontrol individu P-STS diaktifkan.
- [C-1-4] HARUS menyediakan kemampuan pengguna untuk mengizinkan pengguna mengalihkan status radio UWB aktif/nonaktif.
- [C-1-5] HARUS mewajibkan aplikasi yang menggunakan radio UWB memiliki izin
UWB_RANGING
(di bawah grup izinNEARBY_DEVICES
).
Lulus pengujian kepatuhan dan sertifikasi yang relevan yang ditentukan oleh organisasi standar, termasuk FIRA, CCC, dan CSA membantu memastikan 802.1.15.4 berfungsi dengan benar.
Akhiri persyaratan baru
7.4. Konektivitas Data
7.4.1. Telepon
“Telepon” seperti yang digunakan oleh Android API dan dokumen ini secara khusus merujuk pada hardware yang terkait dengan melakukan panggilan suara dan mengirim pesan SMS , atau membuat data seluler melalui jaringan seluler (misalnya GSM, CDMA, LTE, NR) GSM atau CDMA. Perangkat yang mendukung “Telepon” dapat memilih untuk menawarkan beberapa atau semua layanan panggilan, pesan, dan data sesuai dengan produk.
melalui jaringan GSM atau CDMA. Meskipun panggilan suara ini mungkin atau mungkin tidak menggunakan packet-switched,panggilan tersebut untuk tujuan Android dianggap independen dari konektivitas data apa pun yang dapat diterapkan menggunakan jaringan yang sama. Dengan kata lain,fungsi dan API “telepon” Android secara khusus merujuk pada panggilan suara dan SMS. Misalnya, implementasi perangkat yang tidak dapat melakukan panggilan atau mengirim/menerima pesan SMS tidak dianggap sebagai perangkat telepon, terlepas dari apakah perangkat tersebut menggunakan jaringan seluler untuk konektivitas data.
- Android DAPAT digunakan di perangkat yang tidak menyertakan hardware telefoni. Artinya, Android kompatibel dengan perangkat yang bukan ponsel.
Jika implementasi perangkat menyertakan telepon GSM atau CDMA, perangkat tersebut:
- [C-1-1] HARUS mendeklarasikan flag fitur
android.hardware.telephony
dan flag sub-fitur lainnya sesuai dengan teknologi. - [C-1-2] HARUS menerapkan dukungan penuh untuk API untuk teknologi tersebut.
- HARUS mengizinkan semua jenis layanan seluler yang tersedia (2G, 3G, 4G, 5G, dll.)
selama panggilan darurat (terlepas dari jenis jaringan yang ditetapkan oleh
SetAllowedNetworkTypeBitmap()
).
Jika implementasi perangkat tidak menyertakan hardware telefoni, implementasi tersebut:
- [C-2-1] HARUS menerapkan API lengkap sebagai no-ops.
Jika implementasi perangkat mendukung eUICC atau eSIM/SIM tersemat dan menyertakan mekanisme eksklusif untuk menyediakan fungsi eSIM bagi developer pihak ketiga, perangkat tersebut:
- [C-3-1] HARUS mendeklarasikan
flag fitur
android.hardware.telephony.euicc
.
Jika implementasi perangkat tidak menetapkan properti sistem ro.telephony.iwlan\_operation\_mode
ke 'lama', implementasi tersebut:
- [C-4-1] TIDAK BOLEH melaporkan 'NETWORK_TYPE_IWLAN' melalui NetworkRegistrationInfo#getAccessNetworkTechnology() saat NetworkRegistrationInfo#getTransportType() dilaporkan sebagai 'TRANSPORT_TYPE_WWAN' untuk instance NetworkRegistrationInfo yang sama.
Jika implementasi perangkat mendukung satu pendaftaran IP Multimedia Subsystem (IMS) untuk fitur layanan telefoni multimedia (MMTEL) dan rich communication service (RCS) dan diharapkan mematuhi persyaratan operator seluler terkait penggunaan satu pendaftaran IMS untuk semua traffic sinyal IMS, perangkat tersebut:
- [C-5-1] HARUS mendeklarasikan flag fitur
android.hardware.telephony.ims
dan memberikan implementasi lengkap ImsService API untuk MMTEL dan RCS User Capability Exchange API. - [C-5-2] HARUS mendeklarasikan flag fitur
android.hardware.telephony.ims.singlereg
dan memberikan implementasi lengkap SipTransport API, GbaService API, indikasi pembawa khusus menggunakan IRadio 1.6 HAL, dan penyediaan melalui Server Konfigurasi Otomatis (ACS) atau mekanisme penyediaan eksklusif lainnya menggunakan IMS Configuration API.
Jika implementasi perangkat melaporkan fitur android.hardware.telephony
, maka:
- [C-6-1]
SmsManager#sendTextMessage
danSmsManager#sendMultipartTextMessage
HARUS menghasilkan panggilan yang sesuai keCarrierMessagingService
untuk menyediakan fungsi pesan teks.SmsManager#sendMultimediaMessage
danSmsManager#downloadMultimediaMessage
HARUS menghasilkan panggilan yang sesuai keCarrierMessagingService
untuk menyediakan fungsi pesan multimedia. - [C-6-2] Aplikasi yang ditetapkan oleh
android.provider.Telephony.Sms#getDefaultSmsPackage
HARUS menggunakan SmsManager API saat mengirim dan menerima pesan SMS dan MMS. Implementasi referensi AOSP dalam paket/aplikasi/Pesan memenuhi persyaratan ini. - [C-6-3] Aplikasi yang merespons
Intent#ACTION_DIAL
HARUS mendukung entri kode dialer arbitrer yang diformat sebagai*#*#CODE#*#*
dan memicu siaranTelephonyManager#ACTION_SECRET_CODE
yang sesuai. - [C-6-4] Aplikasi yang merespons
Intent#ACTION_DIAL
HARUS menggunakanVoicemailContract.Voicemails#TRANSCRIPTION
untuk menampilkan transkripsi pesan suara visual kepada pengguna jika mendukung transkripsi pesan suara visual. - [C-6-5] HARUS merepresentasikan semua SubscriptionInfo dengan
UUID grup
yang setara sebagai satu langganan di semua kemampuan yang terlihat pengguna yang menampilkan dan
mengontrol informasi kartu SIM. Contoh kemampuan tersebut mencakup antarmuka
setelan yang cocok dengan
Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS
atauEuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS
. - [C-6-6] TIDAK BOLEH menampilkan atau mengizinkan kontrol SubscriptionInfo apa pun dengan UUID grup dan bit oportunistik dalam kemampuan yang terlihat pengguna yang mengizinkan konfigurasi atau kontrol setelan kartu SIM.
Jika implementasi perangkat melaporkan fitur android.hardware.telephony
dan menyediakan status bar sistem, maka:
- [C-7-1] HARUS memilih langganan aktif perwakilan untuk UUID grup tertentu untuk ditampilkan kepada pengguna dalam kemampuan apa pun yang memberikan informasi status SIM. Contoh kemampuan tersebut mencakup ikon sinyal seluler status bar atau kartu setelan cepat.
- [C-SR-1] SANGAT DISARANKAN agar langganan perwakilan dipilih sebagai langganan data aktif kecuali jika perangkat sedang dalam panggilan suara, selama itu SANGAT DISARANKAN agar langganan perwakilan adalah langganan suara aktif.
Jika implementasi perangkat melaporkan fitur android.hardware.telephony
, maka:
- [C-6-7] HARUS dapat membuka dan secara serentak menggunakan jumlah maksimum saluran logis (total 20) untuk setiap UICC per ETSI TS 102 221.
- [C-6-8] TIDAK BOLEH menerapkan salah satu perilaku berikut ke aplikasi operator aktif
(sebagaimana ditetapkan oleh
TelephonyManager#getCarrierServicePackageName
) secara otomatis atau tanpa konfirmasi pengguna yang eksplisit:- Mencabut atau membatasi akses jaringan
- Mencabut izin
- Membatasi eksekusi aplikasi latar belakang atau latar depan di luar fitur pengelolaan daya yang ada dan disertakan dalam AOSP
- Menonaktifkan atau meng-uninstal aplikasi
Jika implementasi perangkat melaporkan fitur android.hardware.telephony
dan
semua langganan non-oportunistik
yang aktif dan berbagi UUID grup dinonaktifkan,
dihapus secara fisik dari perangkat, atau ditandai sebagai oportunistik, perangkat akan:
- [C-8-1] HARUS otomatis menonaktifkan semua langganan opportunistik aktif yang tersisa dalam grup yang sama.
Jika penerapan perangkat menyertakan telepon GSM, tetapi tidak menyertakan telepon CDMA, perangkat tersebut:
- [C-9-1] TIDAK BOLEH mendeklarasikan
PackageManager#FEATURE_TELEPHONY_CDMA
. - [C-9-2] HARUS menampilkan
IllegalArgumentException
saat mencoba menetapkan jenis jaringan 3GPP2 dalam bitmask jenis jaringan yang diinginkan atau diizinkan. - [C-9-3] HARUS menampilkan string kosong dari
TelephonyManager#getMeid
.
Jika implementasi perangkat mendukung eUICC dengan beberapa port dan profil, implementasi tersebut:
- [C-10-1] HARUS mendeklarasikan
flag fitur
android.hardware.telephony.euicc.mep
.
7.4.1.1. Kompatibilitas Pemblokiran Nomor
Jika implementasi perangkat melaporkan fitur android.hardware.telephony.calling
, implementasi tersebut:
- [C-1-1] HARUS menyertakan dukungan pemblokiran nomor
- [C-1-2] HARUS sepenuhnya mengimplementasikan
BlockedNumberContract
dan API yang sesuai seperti yang dijelaskan dalam dokumentasi SDK. [C-1-3] HARUS memblokir semua panggilan dan pesan dari nomor telepon di 'BlockedNumberProvider' tanpa interaksi apa pun dengan aplikasi. Satu-satunya pengecualian adalah saat pemblokiran nomor dicabut untuk sementara seperti yang dijelaskan dalam dokumentasi SDK.
[C-1-4] HARUS menulis ke penyedia log panggilan platform untuk panggilan yang diblokir dan HARUS memfilter panggilan dengan
BLOCKED_TYPE
dari tampilan log panggilan default di aplikasi telepon yang telah diinstal sebelumnya.[C-1-5] TIDAK BOLEH menulis ke Penyedia layanan telepon untuk pesan yang diblokir.
[C-1-6] HARUS menerapkan UI pengelolaan nomor yang diblokir, yang dibuka dengan intent yang ditampilkan oleh metode
TelecomManager.createManageBlockedNumbersIntent()
.[C-1-7] TIDAK BOLEH mengizinkan pengguna sekunder melihat atau mengedit nomor yang diblokir di perangkat karena platform Android mengasumsikan bahwa pengguna utama memiliki kontrol penuh atas layanan telefoni, satu instance, di perangkat. Semua UI terkait pemblokiran HARUS disembunyikan untuk pengguna sekunder dan daftar yang diblokir HARUS tetap dihormati.
HARUS memigrasikan nomor yang diblokir ke penyedia saat perangkat diupdate ke Android 7.0.
HARUS memberikan kemampuan pengguna untuk menampilkan panggilan yang diblokir di aplikasi dialer yang telah diinstal sebelumnya.
7.4.1.2. Telecom API
Jika implementasi perangkat melaporkan android.hardware.telephony.calling
, implementasi tersebut:
- [C-1-1] HARUS mendukung API
ConnectionService
yang dijelaskan dalam SDK. - [C-1-2] HARUS menampilkan panggilan masuk baru dan memberikan kemampuan kepada pengguna untuk
menerima atau menolak panggilan masuk saat pengguna sedang melakukan panggilan
yang dilakukan oleh aplikasi pihak ketiga yang tidak mendukung fitur tahan
yang ditentukan melalui
CAPABILITY_SUPPORT_HOLD
. - [C-1-3] HARUS memiliki aplikasi yang mengimplementasikan InCallService.
[C-SR-1] SANGAT DISARANKAN untuk memberi tahu pengguna bahwa menjawab panggilan masuk akan menghentikan panggilan yang sedang berlangsung.
Implementasi AOSP memenuhi persyaratan ini dengan notifikasi pemberitahuan awal yang menunjukkan kepada pengguna bahwa menjawab panggilan masuk akan menyebabkan panggilan lain dihentikan.
[C-SR-2] SANGAT DISARANKAN untuk memuat aplikasi dialer default secara default yang menampilkan entri log panggilan dan nama aplikasi pihak ketiga dalam log panggilannya saat aplikasi pihak ketiga menetapkan kunci tambahan
EXTRA_LOG_SELF_MANAGED_CALLS
diPhoneAccount
ketrue
.[C-SR-3] SANGAT DIUJAMI untuk menangani peristiwa
KEYCODE_MEDIA_PLAY_PAUSE
danKEYCODE_HEADSETHOOK
headset audio untukandroid.telecom
API seperti di bawah ini:- Panggil
Connection.onDisconnect()
saat penekanan singkat peristiwa tombol terdeteksi selama panggilan berlangsung. - Panggil
Connection.onAnswer()
saat penekanan singkat peristiwa tombol terdeteksi selama panggilan masuk. - Panggil
Connection.onReject()
saat penekanan lama peristiwa tombol terdeteksi selama panggilan masuk. - Alihkan status bisukan
CallAudioState
.
- Panggil
7.4.1.3. Offload Keepalive NAT-T Seluler
Implementasi perangkat:
- HARUS menyertakan dukungan untuk offload keepalive Seluler.
Jika implementasi perangkat menyertakan dukungan untuk offload keepalive Seluler dan mengekspos fungsi ke aplikasi pihak ketiga, perangkat tersebut:
- [C-1-1] HARUS mendukung SocketKeepAlive API.
- [C-1-2] HARUS mendukung minimal satu slot keepalive serentak melalui seluler.
- [C-1-3] HARUS mendukung slot keepalive seluler serentak sebanyak yang didukung oleh HAL Radio Seluler.
- [C-SR-1] SANGAT DIUTAMAKAN untuk mendukung minimal tiga slot keepalive seluler per instance radio.
Jika implementasi perangkat tidak menyertakan dukungan untuk offload keepalive seluler, perangkat tersebut:
- [C-2-1] HARUS menampilkan ERROR_UNSUPPORTED.
7.4.2. IEEE 802.11 (Wi-Fi)
Implementasi perangkat:
- HARUS menyertakan dukungan untuk satu atau beberapa bentuk 802.11.
Jika implementasi perangkat menyertakan dukungan untuk 802.11 dan mengekspos fungsi ke aplikasi pihak ketiga, implementasi tersebut:
- [C-1-1] HARUS mengimplementasikan Android API yang sesuai.
- [C-1-2] HARUS melaporkan tanda fitur hardware
android.hardware.wifi
. - [C-1-3] HARUS menerapkan multicast API seperti yang dijelaskan dalam dokumentasi SDK.
- [C-1-4] HARUS mendukung DNS multicast (mDNS) dan TIDAK BOLEH memfilter paket mDNS
(224.0.0.251 atau ff02::fb)
setiap saat operasi, termasuk saat layar
tidak dalam status aktif, kecuali jika menghapus atau memfilter paket ini
diperlukan agar tetap berada dalam rentang konsumsi daya yang diwajibkan oleh persyaratan
peraturan yang berlaku untuk target pasar.
Untuk implementasi perangkat Android Television, bahkan saat dalam status daya siaga. - [C-1-5] TIDAK BOLEH memperlakukan panggilan metode API
WifiManager.enableNetwork()
sebagai indikasi yang memadai untuk mengalihkanNetwork
yang saat ini aktif dan digunakan secara default untuk traffic aplikasi dan ditampilkan oleh metode APIConnectivityManager
sepertigetActiveNetwork
danregisterDefaultNetworkCallback
. Dengan kata lain, mereka HANYA BOLEH menonaktifkan akses Internet yang disediakan oleh penyedia jaringan lain (misalnya, data seluler) jika mereka berhasil memvalidasi bahwa jaringan Wi-Fi menyediakan akses Internet. - [C-1-6] SANGAT DISARANKAN untuk, saat
metode API
ConnectivityManager.reportNetworkConnectivity()
dipanggil, mengevaluasi ulang akses Internet diNetwork
dan, setelah evaluasi menentukan bahwaNetwork
saat ini tidak lagi menyediakan akses Internet, beralihlah ke jaringan lain yang tersedia (misalnya data seluler) yang menyediakan akses Internet. - [C-1-7] HARUS melakukan pengacakan alamat MAC sumber dan nomor urut frame permintaan probe, sekali di awal setiap pemindaian, saat STA terputus.
- [C-1-8] HARUS menggunakan satu alamat MAC yang konsisten (TIDAK BOLEH mengacak alamat MAC di tengah pemindaian).
- [C-1-9] HARUS melakukan iterasi nomor urutan permintaan probe seperti biasa (secara berurutan) di antara permintaan probe dalam pemindaian.
- [C-1-10] HARUS melakukan pengacakan nomor urutan permintaan Probe antara permintaan probe terakhir dari pemindaian dan permintaan probe pertama dari pemindaian berikutnya.
- [C-SR-1] SANGAT DISARANKAN untuk mengacaukan alamat MAC sumber yang digunakan untuk
semua komunikasi STA ke Titik Akses (AP) saat mengaitkan dan
dikaitkan.
- Perangkat HARUS menggunakan alamat MAC acak yang berbeda untuk setiap SSID (FQDN untuk Passpoint) yang diajak berkomunikasi.
- Perangkat HARUS memberi pengguna opsi untuk mengontrol randomisasi per SSID (FQDN untuk Passpoint) dengan opsi yang tidak acak dan acak, serta HARUS menetapkan mode default untuk konfigurasi Wi-Fi baru agar diacak.
- [C-SR-2] SANGAT DISARANKAN untuk menggunakan BSSID acak untuk AP apa pun yang
dibuatnya.
- Alamat MAC HARUS acak dan dipertahankan per SSID yang digunakan oleh AP.
- PERALATAN DAPAT memberikan opsi kepada pengguna untuk menonaktifkan fitur ini. Jika opsi tersebut disediakan, pengacakan HARUS diaktifkan secara default.
Jika implementasi perangkat menyertakan dukungan untuk mode hemat daya Wi-Fi seperti yang ditentukan dalam standar IEEE 802.11, perangkat tersebut:
- HARUS menonaktifkan mode hemat daya Wi-Fi setiap kali aplikasi memperoleh
kunci
WIFI_MODE_FULL_HIGH_PERF
atau kunciWIFI_MODE_FULL_LOW_LATENCY
melalui APIWifiManager.createWifiLock()
danWifiManager.WifiLock.acquire()
dan kunci aktif. - [C-3-2] Latensi round trip rata-rata antara perangkat
dan titik akses saat perangkat dalam mode Wi-Fi Low Latency Lock
(
WIFI_MODE_FULL_LOW_LATENCY
) HARUS lebih kecil dari latensi selama mode Wi-Fi High Perf Lock (WIFI_MODE_FULL_HIGH_PERF
). - [C-SR-3] SANGAT DIUJAMI untuk meminimalkan latensi bolak-balik Wi-Fi
setiap kali Kunci Latensi Rendah (
WIFI_MODE_FULL_LOW_LATENCY
) diperoleh dan diterapkan.
Jika implementasi perangkat mendukung Wi-Fi dan menggunakan Wi-Fi untuk pemindaian lokasi, perangkat tersebut:
- [C-2-1] HARUS memberikan kemampuan pengguna untuk mengaktifkan/menonaktifkan nilai yang dibaca
melalui metode API
WifiManager.isScanAlwaysAvailable
.
7.4.2.1. Wi-Fi Direct
Implementasi perangkat:
- HARUS menyertakan dukungan untuk Wi-Fi Direct (Wi-Fi peer-to-peer).
Jika implementasi perangkat menyertakan dukungan untuk Wi-Fi Direct, perangkat tersebut:
- [C-1-1] HARUS menerapkan Android API yang sesuai seperti yang dijelaskan dalam dokumentasi SDK.
- [C-1-2] HARUS melaporkan fitur hardware
android.hardware.wifi.direct
. - [C-1-3] HARUS mendukung pengoperasian Wi-Fi reguler.
- [C-1-4] HARUS mendukung operasi Wi-Fi dan Wi-Fi Direct secara serentak.
- [C-SR-1] SANGAT DISARANKAN untuk mengacaukan alamat MAC sumber untuk semua koneksi Wi-Fi Direct yang baru dibuat.
7.4.2.2. Penyiapan Link Langsung Wi-Fi dengan Tunnel
Implementasi perangkat:
- HARUS menyertakan dukungan untuk Wi-Fi Tunneled Direct Link Setup (TDLS) seperti yang dijelaskan dalam Dokumentasi Android SDK.
Jika implementasi perangkat menyertakan dukungan untuk TDLS dan TDLS diaktifkan oleh WiFiManager API, keduanya:
- [C-1-1] HARUS mendeklarasikan dukungan untuk TDLS melalui
WifiManager.isTdlsSupported
. - HARUS menggunakan TDLS hanya jika memungkinkan DAN bermanfaat.
- HARUS memiliki beberapa heuristik dan TIDAK menggunakan TDLS jika performanya mungkin lebih buruk daripada melalui titik akses Wi-Fi.
7.4.2.3. Wi-Fi Aware
Implementasi perangkat:
- HARUS menyertakan dukungan untuk Wi-Fi Aware.
Jika implementasi perangkat menyertakan dukungan untuk Wi-Fi Aware dan mengekspos fungsi ke aplikasi pihak ketiga, maka:
- [C-1-1] HARUS menerapkan API
WifiAwareManager
seperti yang dijelaskan dalam dokumentasi SDK. - [C-1-2] HARUS mendeklarasikan flag fitur
android.hardware.wifi.aware
. - [C-1-3] HARUS mendukung operasi Wi-Fi dan Wi-Fi Aware secara serentak.
- [C-1-4] HARUS melakukan randomisasi alamat antarmuka pengelolaan Wi-Fi Aware dengan interval tidak lebih dari 30 menit dan setiap kali Wi-Fi Aware diaktifkan, kecuali jika operasi pengukuran rentang Aware sedang berlangsung atau jalur data Aware aktif (randomisasi tidak diharapkan selama jalur data aktif).
Jika implementasi perangkat menyertakan dukungan untuk Wi-Fi Aware dan Wi-Fi Location seperti yang dijelaskan di Bagian 7.4.2.5 dan mengekspos fungsi ini ke aplikasi pihak ketiga, maka:
- [C-2-1] HARUS menerapkan API penemuan berbasis lokasi: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm , dan onServiceDiscoveredWithinRange.
7.4.2.4. Passpoint Wi-Fi
Jika implementasi perangkat menyertakan dukungan untuk 802.11 (Wi-Fi), perangkat tersebut:
- [C-1-1] HARUS menyertakan dukungan untuk Wi-Fi Passpoint.
- [C-1-2] HARUS mengimplementasikan API
WifiManager
terkait Passpoint seperti yang dijelaskan dalam dokumentasi SDK. - [C-1-3] HARUS mendukung standar IEEE 802.11u, yang secara khusus terkait dengan Penemuan dan Pemilihan Jaringan, seperti Layanan Iklan Generik (GAS) dan Access Network Query Protocol (ANQP).
- [C-1-4] HARUS mendeklarasikan flag fitur
android.hardware.wifi.passpoint
. - [C-1-5] HARUS mengikuti implementasi AOSP untuk menemukan, mencocokkan, dan mengaitkan ke jaringan Passpoint.
- [C-1-6] HARUS mendukung setidaknya subset protokol penyediaan perangkat berikut seperti yang ditentukan dalam Wi-Fi Alliance Passpoint R2: autentikasi EAP-TTLS dan SOAP-XML.
- [C-1-7] HARUS memproses sertifikat server AAA seperti yang dijelaskan dalam spesifikasi Hotspot 2.0 R3.
- [C-1-8] HARUS mendukung kontrol pengguna atas penyediaan melalui pemilih Wi-Fi.
- [C-1-9] HARUS mempertahankan konfigurasi Passpoint agar tetap ada saat perangkat dimulai ulang.
- [C-SR-1] SANGAT DIUJAMI untuk mendukung fitur persyaratan dan ketentuan.
- [C-SR-2] SANGAT DIUTAMAKAN untuk mendukung fitur Informasi tempat.
Jika tombol kontrol pengguna penonaktifan Passpoint global disediakan, implementasi:
- [C-3-1] HARUS mengaktifkan Passpoint secara default.
7.4.2.5. Lokasi Wi-Fi (Waktu Round Trip Wi-Fi - RTT)
Implementasi perangkat:
- HARUS menyertakan dukungan untuk Lokasi Wi-Fi.
Jika implementasi perangkat menyertakan dukungan untuk Lokasi Wi-Fi dan mengekspos fungsi ke aplikasi pihak ketiga, maka:
- [C-1-1] HARUS menerapkan API
WifiRttManager
seperti yang dijelaskan dalam dokumentasi SDK. - [C-1-2] HARUS mendeklarasikan flag fitur
android.hardware.wifi.rtt
. - [C-1-3] HARUS mengacaukan alamat MAC sumber untuk setiap burst RTT yang dieksekusi saat antarmuka Wi-Fi tempat RTT dieksekusi tidak dikaitkan dengan Titik Akses.
- [C-1-4] HARUS akurat dalam jarak 2 meter pada bandwidth 80 MHz pada persentil ke-68 (seperti yang dihitung dengan Fungsi Distribusi Kumulatif).
- [C-SR-1] SANGAT DIUJAMI untuk melaporkannya secara akurat dalam jarak 1,5 meter pada bandwidth 80 MHz pada persentil ke-68 (seperti yang dihitung dengan Fungsi Distribusi Kumulatif).
7.4.2.6. Wi-Fi Keepalive Offload
Implementasi perangkat:
- HARUS menyertakan dukungan untuk offload keepalive Wi-Fi.
Jika implementasi perangkat menyertakan dukungan untuk offload keepalive Wi-Fi dan mengekspos fungsi ke aplikasi pihak ketiga, implementasi tersebut:
- [C-1-1] HARUS mendukung API SocketKeepAlive.
- [C-1-2] HARUS mendukung minimal tiga slot keepalive serentak melalui Wi-Fi
Jika implementasi perangkat tidak menyertakan dukungan untuk offload keepalive Wi-Fi, perangkat tersebut:
- [C-2-1] HARUS menampilkan
ERROR_UNSUPPORTED
.
7.4.2.7. Wi-Fi Easy Connect (Protokol Penyediaan Perangkat)
Implementasi perangkat:
- HARUS menyertakan dukungan untuk Wi-Fi Easy Connect (DPP).
Jika implementasi perangkat menyertakan dukungan untuk Wi-Fi Easy Connect dan mengekspos fungsi ke aplikasi pihak ketiga, perangkat tersebut:
- [C-1-1] HARUS memiliki metode WifiManager#isEasyConnectSupported()
yang menampilkan
true
.
7.4.2.8. Validasi Sertifikat Server Wi-Fi Perusahaan
Jika sertifikat server Wi-Fi tidak divalidasi atau nama domain server Wi-Fi tidak ditetapkan, implementasi perangkat:
- [C-SR-1] SANGAT DISARANKAN untuk tidak memberikan opsi kepada pengguna untuk menambahkan jaringan Wi-Fi Perusahaan secara manual di aplikasi Setelan.
7.4.2.9. Percayai pada Penggunaan Pertama (TOFU)
Jika implementasi perangkat mendukung Trust on first usage (TOFU) dan memungkinkan pengguna menentukan konfigurasi WPA/WPA2/WPA3-Enterprise, perangkat tersebut:
- [C-4-1] HARUS memberikan opsi kepada pengguna untuk memilih menggunakan TOFU.
7.4.3. Bluetooth
Jika implementasi perangkat mendukung profil Audio Bluetooth, perangkat tersebut:
- HARUS mendukung Advanced Audio Codecs dan Bluetooth Audio Codecs (misalnya, LDAC)
Jika implementasi perangkat mendukung HFP, A2DP, dan AVRCP, perangkat tersebut:
- HARUS mendukung minimal 5 total perangkat terhubung.
Jika implementasi perangkat mendeklarasikan fitur
android.hardware.vr.high_performance
, implementasi tersebut:
- [C-1-1] HARUS mendukung Bluetooth 4.2 dan Ekstensi Panjang Data Bluetooth LE.
Android menyertakan dukungan untuk Bluetooth dan Bluetooth Hemat Energi.
Jika implementasi perangkat menyertakan dukungan untuk Bluetooth dan Bluetooth Low Energy, implementasi tersebut:
- [C-2-1] HARUS mendeklarasikan fitur platform yang relevan
(masing-masing
android.hardware.bluetooth
danandroid.hardware.bluetooth_le
) dan menerapkan API platform. - HARUS mengimplementasikan profil Bluetooth yang relevan seperti A2DP, AVRCP, OBEX, HFP, dll. sesuai untuk perangkat.
Jika implementasi perangkat menyertakan dukungan untuk Bluetooth Hemat Energi (BLE), perangkat tersebut:
- [C-3-1] HARUS mendeklarasikan fitur hardware
android.hardware.bluetooth_le
. - [C-3-2] HARUS mengaktifkan API Bluetooth berbasis GATT (profil atribut generik) seperti yang dijelaskan dalam dokumentasi SDK dan android.bluetooth.
- [C-3-3] HARUS melaporkan nilai yang benar untuk
BluetoothAdapter.isOffloadedFilteringSupported()
guna menunjukkan apakah logika pemfilteran untuk class API ScanFilter diterapkan. - [C-3-4] HARUS melaporkan nilai yang benar untuk
BluetoothAdapter.isMultipleAdvertisementSupported()
guna menunjukkan apakah Iklan Hemat Energi didukung. [C-3-5] HARUS menerapkan waktu tunggu Resolvable Private Address (RPA) tidak lebih dari 15 menit dan merotasi alamat saat waktu tunggu habis untuk melindungi privasi pengguna saat perangkat aktif menggunakan BLE untuk pemindaian atau iklan. Untuk mencegah serangan pengaturan waktu, interval waktu tunggu habis JUGA HARUS acak antara 5 dan 15 menit.
HARUS mendukung offloading logika pemfilteran ke chipset Bluetooth saat menerapkan ScanFilter API.
HARUS mendukung offloading pemindaian batch ke chipset bluetooth.
HARUS mendukung multi-iklan dengan minimal 4 slot.
Jika implementasi perangkat mendukung Bluetooth LE dan menggunakan Bluetooth LE untuk pemindaian lokasi, perangkat tersebut:
- [C-4-1] HARUS memberikan kemampuan pengguna untuk mengaktifkan/menonaktifkan nilai yang dibaca
melalui System API
BluetoothAdapter.isBleScanAlwaysAvailable()
.
Jika implementasi perangkat menyertakan dukungan untuk Bluetooth LE dan Profil Alat Bantu Dengar, seperti yang dijelaskan dalam Dukungan Audio Alat Bantu Dengar Menggunakan Bluetooth LE, perangkat tersebut:
- [C-5-1] HARUS menampilkan
true
untuk BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).
Jika implementasi perangkat menyertakan dukungan untuk Bluetooth atau Bluetooth Hemat Energi, perangkat tersebut:
- [C-6-1] HARUS membatasi akses ke metadata Bluetooth apa pun (seperti hasil
pindaian) yang dapat digunakan untuk memperoleh lokasi perangkat, kecuali
jika aplikasi yang meminta berhasil lulus pemeriksaan izin
android.permission.ACCESS_FINE_LOCATION
berdasarkan status latar depan/latar belakangnya saat ini.
Jika implementasi perangkat menyertakan dukungan untuk Bluetooth atau Bluetooth Hemat Energi dan manifes aplikasi tidak menyertakan deklarasi dari developer yang menyatakan bahwa mereka tidak memperoleh lokasi dari Bluetooth, maka, mereka:
- [C-6-2] HARUS mengontrol akses Bluetooth di balik
android.permission.ACCESS_FINE_LOCATION
.
Jika implementasi perangkat menampilkan true
untuk
BluetoothAdapter.isLeAudioSupported()
API, maka:
- [C-7-1] HARUS mendukung klien unicast.
- [C-7-2] HARUS mendukung PHY 2M.
- [C-7-3] HARUS mendukung iklan LE Extended.
- [C-7-4] HARUS mendukung minimal 2 koneksi CIS dalam CIG.
- [C-7-5] HARUS mengaktifkan klien unicast BAP, koordinator set CSIP, server MCP, pengontrol VCP, server CCP secara bersamaan.
- [C-SR-1] SANGAT DIUTAMAKAN untuk mengaktifkan klien unicast HAP.
Jika implementasi perangkat menampilkan true
untuk
BluetoothAdapter.isLeAudioBroadcastSourceSupported()
API, maka:
- [C-8-1] HARUS mendukung minimal 2 link BIS dalam BIG.
- [C-8-2] HARUS mengaktifkan sumber siaran BAP, asisten siaran BAP secara bersamaan.
- [C-8-3] HARUS mendukung iklan Berkala LE.
Jika implementasi perangkat menampilkan true
untuk
BluetoothAdapter.isLeAudioBroadcastAssistantSupported()
API, maka:
- [C-9-1] HARUS mendukung PAST (Periodic Advertising Sync Transfer).
- [C-9-2] HARUS mendukung iklan Berkala LE.
Jika implementasi perangkat mendeklarasikan FEATURE_BLUETOOTH_LE
, implementasi tersebut:
- [C-10-1] HARUS memiliki pengukuran RSSI dalam +/-9 dB untuk 95% pengukuran pada jarak 1 m dari perangkat referensi yang mengirimkan pada
ADVERTISE_TX_POWER_HIGH
di lingkungan line of sight. [C-10-2] HARUS menyertakan koreksi Rx/Tx untuk mengurangi deviasi per saluran sehingga pengukuran pada setiap 3 saluran, pada setiap antena (jika beberapa digunakan), berada dalam +/-3 dB satu sama lain untuk 95% pengukuran.
[C-SR-2] SANGAT DISARANKAN untuk mengukur dan mengompensasi offset Rx untuk memastikan RSSI BLE median adalah -60 dBm +/-10 dB pada jarak 1 m dari perangkat referensi yang mengirimkan di
ADVERTISE_TX_POWER_HIGH
, dengan perangkat diorientasikan sedemikian rupa sehingga berada di 'bidang paralel' dengan layar menghadap arah yang sama.[C-SR-3] SANGAT DISARANKAN untuk mengukur dan mengompensasi offset Tx untuk memastikan RSSI BLE median adalah -60 dBm +/-10 dB saat memindai dari perangkat referensi yang diposisikan pada jarak 1 m dan mengirimkan pada
ADVERTISE_TX_POWER_HIGH
, dengan perangkat diorientasikan sedemikian rupa sehingga berada di 'bidang paralel' dengan layar menghadap ke arah yang sama.Memindahkan persyaratan [C-10-3] dan [C-10-4] ke 2.2.1. Hardware.
- [C-10-3] HARUS mengukur dan mengompensasi offset Rx untuk
memastikan RSSI BLE median adalah -55dBm +/-10 dB pada jarak 1 m dari
perangkat referensi yang mengirimkan pada
ADVERTISE_TX_POWER_HIGH
. - [C-10-4] HARUS mengukur dan mengompensasi offset Tx untuk
memastikan RSSI BLE median adalah -55dBm +/-10 dB saat memindai dari perangkat
referensi yang diposisikan pada jarak 1 m dan mengirimkan pada
ADVERTISE_TX_POWER_HIGH
.
SANGAT DISARANKAN untuk mengikuti langkah-langkah penyiapan pengukuran yang ditentukan dalam Persyaratan Kalibrasi Kehadiran.
Jika implementasi perangkat mendukung Bluetooth versi 5.0, implementasi tersebut:
- [C-SR-4] SANGAT DISARANKAN untuk memberikan dukungan bagi:
- LE 2M PHY
- PHY Codec LE
- Ekstensi Iklan LE
- Iklan berkala
- Minimal 10 set iklan
- Minimal 8 koneksi serentak LE. Setiap koneksi dapat berada dalam peran topologi koneksi.
- Privasi Lapisan Link LE
- Ukuran "daftar penyelesaian" minimal 8 entri
7.4.4. Komunikasi Nirkabel Jarak Dekat
Implementasi perangkat:
- HARUS menyertakan transceiver dan hardware terkait untuk Komunikasi Jarak Dekat (NFC).
- [C-0-1] HARUS mengimplementasikan API
android.nfc.NdefMessage
danandroid.nfc.NdefRecord
meskipun tidak menyertakan dukungan untuk NFC atau mendeklarasikan fiturandroid.hardware.nfc
karena class mewakili format representasi data yang tidak bergantung pada protokol.
Jika implementasi perangkat menyertakan hardware NFC dan berencana menyediakannya untuk aplikasi pihak ketiga, perangkat tersebut:
- [C-1-1] HARUS melaporkan fitur
android.hardware.nfc
dari metodeandroid.content.pm.PackageManager.hasSystemFeature()
. - HARUS dapat membaca dan menulis pesan NDEF melalui standar NFC berikut seperti di bawah ini:
- [C-1-2] HARUS dapat berfungsi sebagai pembaca/penulis Forum NFC
(sebagaimana ditentukan oleh spesifikasi teknis Forum NFC
NFCForum-TS-DigitalProtocol-1.0) melalui standar NFC berikut:
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NfcF (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- Jenis Tag NFC Forum 1, 2, 3, 4, 5 (ditentukan oleh NFC Forum)
[C-SR-1] SANGAT DISARANKAN agar dapat membaca dan menulis pesan NDEF serta data mentah melalui standar NFC berikut. Perhatikan bahwa meskipun standar NFC dinyatakan sebagai SANGAT DIUJI, Definisi Kompatibilitas untuk versi mendatang direncanakan untuk mengubahnya menjadi HARUS. Standar ini bersifat opsional dalam versi ini, tetapi akan diperlukan dalam versi mendatang. Perangkat lama dan baru yang menjalankan versi Android ini sangat disarankan untuk memenuhi persyaratan ini sekarang sehingga perangkat tersebut dapat diupgrade ke rilis platform mendatang.
[C-1-13] HARUS melakukan polling untuk semua teknologi yang didukung saat dalam mode penemuan NFC.
HARUS dalam mode penemuan NFC saat perangkat aktif dengan layar aktif dan layar kunci tidak terkunci.
HARUS dapat membaca kode batang dan URL (jika dienkode) dari produk Kode Batang NFC Thinfilm.
Perhatikan bahwa link yang tersedia untuk publik tidak tersedia untuk spesifikasi Forum JIS, ISO, dan NFC yang dikutip di atas.
Android menyertakan dukungan untuk mode Host Card Emulation (HCE) NFC.
Jika implementasi perangkat menyertakan chipset pengontrol NFC yang mampu melakukan HCE (untuk NfcA dan/atau NfcB) dan mendukung pemilihan rute ID Aplikasi (AID), perangkat tersebut:
- [C-2-1] HARUS melaporkan konstanta fitur
android.hardware.nfc.hce
. - [C-2-2] HARUS mendukung NFC HCE API seperti yang ditentukan dalam Android SDK.
Jika implementasi perangkat menyertakan chipset pengontrol NFC yang mampu melakukan HCE untuk NfcF, dan mengimplementasikan fitur untuk aplikasi pihak ketiga, perangkat tersebut:
- [C-3-1] HARUS melaporkan konstanta fitur
android.hardware.nfc.hcef
. - [C-3-2] HARUS mengimplementasikan NfcF Card Emulation API seperti yang ditentukan dalam Android SDK.
Jika implementasi perangkat menyertakan dukungan NFC umum seperti yang dijelaskan di bagian ini dan mendukung teknologi MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF di MIFARE Classic) dalam peran pembaca/penulis, perangkat tersebut:
- [C-4-1] HARUS mengimplementasikan API Android yang sesuai seperti yang didokumentasikan oleh Android SDK.
- [C-4-2] HARUS melaporkan fitur
com.nxp.mifare
dari metodeandroid.content.pm.PackageManager.hasSystemFeature
(). Perhatikan bahwa ini bukan fitur Android standar sehingga tidak muncul sebagai konstanta di classandroid.content.pm.PackageManager
.
7.4.5. API dan protokol jaringan
7.4.5.1. Kemampuan Jaringan Minimum
Implementasi perangkat:
- [C-0-1] HARUS menyertakan dukungan untuk satu atau beberapa bentuk jaringan data. Secara khusus, implementasi perangkat HARUS menyertakan dukungan untuk setidaknya satu standar data yang mampu mencapai 200 Kbit/detik atau lebih tinggi. Contoh teknologi yang memenuhi persyaratan ini mencakup EDGE, HSPA, EV-DO, 802.11g, Ethernet, dan Bluetooth PAN.
- HARUS juga menyertakan dukungan untuk setidaknya satu standar data nirkabel umum, seperti 802.11 (Wi-Fi), jika standar jaringan fisik (seperti Ethernet) adalah koneksi data utama.
- DAPAT menerapkan lebih dari satu bentuk konektivitas data.
7.4.5.2. IPv6
Implementasi perangkat:
- [C-0-2] HARUS menyertakan stack jaringan IPv6 dan mendukung komunikasi IPv6
menggunakan API terkelola, seperti
java.net.Socket
danjava.net.URLConnection
, serta API native, seperti soketAF_INET6
. - [C-0-3] HARUS mengaktifkan IPv6 secara default.
- HARUS memastikan bahwa komunikasi IPv6 sama andal dengan IPv4, misalnya:
- [C-0-4] HARUS mempertahankan konektivitas IPv6 dalam mode tidur.
- [C-0-5] Pembatasan kapasitas TIDAK BOLEH menyebabkan perangkat kehilangan koneksi IPv6 di jaringan yang mematuhi IPv6 yang menggunakan masa aktif RA setidaknya 180 detik.
- HARUS memastikan bahwa komunikasi IPv6 sama andal dengan IPv4, misalnya:
- [C-0-6] HARUS menyediakan konektivitas IPv6 langsung
ke jaringan untuk aplikasi pihak ketiga saat terhubung ke jaringan IPv6, tanpa terjemahan alamat atau
port apa pun yang terjadi secara lokal di perangkat. Baik API terkelola seperti
Socket#getLocalAddress
atauSocket#getLocalPort
) dan API NDK sepertigetsockname()
atauIPV6_PKTINFO
HARUS menampilkan alamat dan port IP yang sebenarnya digunakan untuk mengirim dan menerima paket di jaringan dan terlihat sebagai ip dan port sumber ke server internet (web).
Tingkat dukungan IPv6 yang diperlukan bergantung pada jenis jaringan, seperti yang ditunjukkan dalam persyaratan berikut.
Jika implementasi perangkat mendukung Wi-Fi, perangkat tersebut:
- [C-1-1] HARUS mendukung operasi dual-stack dan khusus IPv6 di Wi-Fi.
Jika penerapan perangkat mendukung Ethernet, perangkat tersebut:
- [C-2-1] HARUS mendukung operasi dual-stack dan khusus IPv6 di Ethernet.
Jika implementasi perangkat mendukung Data seluler, perangkat tersebut:
- [C-3-1] HARUS mendukung operasi IPv6 (khusus IPv6 dan mungkin stack ganda) di seluler.
Jika implementasi perangkat mendukung lebih dari satu jenis jaringan (mis., Wi-Fi dan data seluler), mereka:
- [C-4-1] HARUS secara bersamaan memenuhi persyaratan di atas di setiap jaringan saat perangkat terhubung secara bersamaan ke lebih dari satu jenis jaringan.
7.4.5.3. Captive Portal
Captive portal mengacu pada jaringan yang mengharuskan login untuk mendapatkan akses internet.
Jika implementasi perangkat memberikan implementasi lengkap
android.webkit.Webview API
,
implementasi tersebut:
- [C-1-1] HARUS menyediakan aplikasi captive portal untuk menangani intent
ACTION_CAPTIVE_PORTAL_SIGN_IN
dan menampilkan halaman login captive portal, dengan mengirimkan intent tersebut, saat memanggil System APIConnectivityManager#startCaptivePortalApp(Network, Bundle)
. - [C-1-2] HARUS melakukan deteksi captive portal dan mendukung login melalui aplikasi captive portal saat perangkat terhubung ke jenis jaringan apa pun, termasuk jaringan seluler/seluler, Wi-Fi, Ethernet, atau Bluetooth.
- [C-1-3] HARUS mendukung login ke captive portal menggunakan DNS cleartext saat perangkat dikonfigurasi untuk menggunakan mode ketat DNS pribadi.
- [C-1-4] HARUS menggunakan DNS terenkripsi sesuai dengan dokumentasi SDK untuk
android.net.LinkProperties.getPrivateDnsServerName
danandroid.net.LinkProperties.isPrivateDnsActive
untuk semua traffic jaringan yang tidak berkomunikasi secara eksplisit dengan captive portal. - [C-1-5] HARUS memastikan bahwa, saat pengguna login ke portal
terkunci, jaringan default yang digunakan oleh aplikasi (seperti yang ditampilkan oleh
ConnectivityManager.getActiveNetwork
,ConnectivityManager.registerDefaultNetworkCallback
, dan digunakan secara default oleh API jaringan Java seperti java.net.Socket, dan API native seperti connect()) adalah jaringan lain yang tersedia yang menyediakan akses internet, jika tersedia.
7.4.6. Setelan Sinkronisasi
Implementasi perangkat:
- [C-0-1] HARUS mengaktifkan setelan sinkronisasi otomatis master secara default sehingga
metode
getMasterSyncAutomatically()
menampilkan “true”.
7.4.7. Penghemat Data
Jika implementasi perangkat menyertakan koneksi berbayar, koneksi tersebut:
- [C-SR-1] SANGAT DISARANKAN untuk menyediakan mode penghemat data.
Jika implementasi perangkat menyediakan mode penghemat data, implementasi tersebut:
- [C-1-1] HARUS mendukung semua API di class
ConnectivityManager
seperti yang dijelaskan dalam dokumentasi SDK
Jika implementasi perangkat tidak menyediakan mode penghemat data, implementasi tersebut:
- [C-2-1] HARUS menampilkan nilai
RESTRICT_BACKGROUND_STATUS_DISABLED
untukConnectivityManager.getRestrictBackgroundStatus()
- [C-2-2] TIDAK BOLEH menyiarkan
ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED
.
7.4.8. Elemen Pengaman
Jika implementasi perangkat mendukung elemen aman yang kompatibel dengan Open Mobile API dan menyediakannya untuk aplikasi pihak ketiga, implementasi tersebut:
[C-1-1] HARUS menghitung pembaca elemen aman yang tersedia melalui
android.se.omapi.SEService.getReaders()
API.[C-1-2] HARUS mendeklarasikan flag fitur yang benar melalui
android.hardware.se.omapi.uicc
untuk perangkat dengan elemen aman berbasis UICC,android.hardware.se.omapi.ese
untuk perangkat dengan elemen aman berbasis eSE, danandroid.hardware.se.omapi.sd
untuk perangkat dengan elemen aman berbasis SD.
7.4.9. UWB
Jika implementasi perangkat menyertakan dukungan untuk 802.1.15.4 dan mengekspos fungsi ke aplikasi pihak ketiga, maka:
- [C-1-1] HARUS mengimplementasikan Android API yang sesuai di android.uwb.
- [C-1-2] HARUS melaporkan flag fitur hardware android.hardware.uwb.
- [C-1-3] HARUS mendukung semua profil UWB yang relevan yang ditentukan dalam implementasi Android.
- [C-1-4] HARUS menyediakan kemampuan pengguna untuk mengizinkan pengguna mengalihkan status radio UWB aktif/nonaktif.
- [C-1-5] HARUS mewajibkan aplikasi yang menggunakan radio UWB memiliki izin UWB_RANGING (dalam grup izin NEARBY_DEVICES).
- [C-SR-1] SANGAT DISARANKAN untuk lulus uji kepatuhan dan sertifikasi yang relevan yang ditentukan oleh organisasi standar, termasuk FIRA, CCC, dan CSA.
- [C-1-6] HARUS memastikan pengukuran jarak berada dalam +/-15 cm untuk 95% pengukuran di lingkungan garis pandang pada jarak 1 m di kamar non-reflektif.
- [C-1-7] HARUS memastikan bahwa median pengukuran jarak pada 1 m
dari perangkat referensi berada dalam [0,75 m, 1,25 m], dengan jarak truth
bumi diukur dari tepi atas DUT.
dipegang menghadap ke atas dan dimiringkan 45 derajat. - [C-SR-2] SANGAT DISARANKAN untuk mengikuti langkah-langkah penyiapan pengukuran yang ditentukan dalam Persyaratan Kalibrasi Kehadiran.
7.5. Kamera
Jika implementasi perangkat menyertakan minimal satu kamera, perangkat tersebut:
- [C-1-1] HARUS mendeklarasikan flag fitur
android.hardware.camera.any
. - [C-1-2] HARUS memungkinkan aplikasi mengalokasikan 3 bitmap RGBA_8888 secara bersamaan yang sama dengan ukuran gambar yang dihasilkan oleh sensor kamera beresolusi terbesar di perangkat, saat kamera terbuka untuk tujuan pratinjau dasar dan pengambilan gambar diam.
- [C-1-3] HARUS memastikan bahwa aplikasi kamera default bawaan
yang menangani intent
MediaStore.ACTION_IMAGE_CAPTURE
,MediaStore.ACTION_IMAGE_CAPTURE_SECURE
, atauMediaStore.ACTION_VIDEO_CAPTURE
, bertanggung jawab untuk menghapus lokasi pengguna dalam metadata gambar sebelum mengirimnya ke aplikasi penerima jika aplikasi penerima tidak memilikiACCESS_FINE_LOCATION
.
Jika implementasi perangkat mendukung kemampuan output HDR 10-bit, implementasi tersebut:
- [C-2-1] HARUS mendukung setidaknya profil HDR HLG untuk setiap perangkat kamera yang mendukung output 10-bit.
- [C-2-2] HARUS mendukung output 10-bit untuk kamera utama menghadap belakang atau kamera utama menghadap depan.
- [C-SR-1] SANGAT DIUJAMI untuk mendukung output 10-bit untuk kedua kamera utama.
- [C-2-3] HARUS mendukung profil HDR yang sama untuk semua sub-kamera fisik yang kompatibel dengan BACKWARD_COMPATIBLE dari kamera logis, dan kamera logis itu sendiri.
Untuk perangkat kamera Logis yang mendukung HDR 10-bit yang mengimplementasikan
android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO
API, perangkat tersebut:
- [C-3-1] HARUS mendukung pengalihan antara semua kamera fisik
yang kompatibel dengan versi sebelumnya melalui kontrol
CONTROL_ZOOM_RATIO
pada kamera logis.
7.5.1. Kamera Belakang
Kamera belakang adalah kamera yang terletak di sisi perangkat yang berlawanan dengan layar; yaitu, kamera ini mengambil gambar di sisi jauh perangkat, seperti kamera tradisional.
Memulai persyaratan baru
Kamera belakang adalah kamera yang menghadap ke dunia yang mengambil gambar di sisi jauh perangkat, seperti kamera tradisional; pada perangkat genggam, yaitu kamera yang terletak di sisi perangkat yang berlawanan dengan layar.
Akhiri persyaratan baru
Implementasi perangkat:
- HARUS menyertakan kamera belakang.
Jika implementasi perangkat menyertakan minimal satu kamera belakang, perangkat tersebut:
- [C-1-1] HARUS melaporkan flag fitur
android.hardware.camera
danandroid.hardware.camera.any
. - [C-1-2] HARUS memiliki resolusi minimal 2 megapiksel.
- HARUS memiliki fokus otomatis hardware atau fokus otomatis software yang diterapkan di driver kamera (transparan untuk software aplikasi).
- MUNGKIN memiliki hardware fokus tetap atau EDOF (extended depth of field).
- DAPAT menyertakan flash.
Jika kamera dilengkapi dengan flash:
- [C-2-1] lampu flash TIDAK BOLEH menyala saat
instance
android.hardware.Camera.PreviewCallback
telah terdaftar di platform pratinjau Kamera, kecuali jika aplikasi telah mengaktifkan lampu kilat secara eksplisit dengan mengaktifkan atributFLASH_MODE_AUTO
atauFLASH_MODE_ON
objekCamera.Parameters
. Perhatikan bahwa batasan ini tidak berlaku untuk aplikasi kamera sistem bawaan perangkat, tetapi hanya untuk aplikasi pihak ketiga yang menggunakanCamera.PreviewCallback
.
7.5.2. Kamera Depan
Kamera depan adalah kamera yang terletak di sisi perangkat yang sama dengan layar; yaitu, kamera yang biasanya digunakan untuk mengambil gambar pengguna, seperti untuk konferensi video dan aplikasi serupa.
Memulai persyaratan baru
Kamera depan adalah kamera yang menghadap pengguna yang biasanya digunakan untuk mengambil gambar pengguna, seperti untuk konferensi video dan aplikasi serupa; di perangkat genggam, kamera tersebut terletak di sisi perangkat yang sama dengan layar.
Akhiri persyaratan baru
Implementasi perangkat:
- DAPAT menyertakan kamera depan.
Jika implementasi perangkat menyertakan minimal satu kamera depan, perangkat tersebut:
- [C-1-1] HARUS melaporkan flag fitur
android.hardware.camera.any
danandroid.hardware.camera.front
. - [C-1-2] HARUS memiliki resolusi minimal VGA (640x480 piksel).
- [C-1-3] TIDAK BOLEH menggunakan kamera depan sebagai default untuk Camera API dan TIDAK BOLEH mengonfigurasi API untuk memperlakukan kamera depan sebagai kamera belakang default, meskipun itu satu-satunya kamera di perangkat.
- [C-1-4] Pratinjau kamera HARUS dicerminkan secara horizontal relatif terhadap
orientasi yang ditentukan oleh aplikasi saat aplikasi saat ini telah
meminta secara eksplisit agar Layar
kamera diputar melalui panggilan ke
metode
android.hardware.Camera.setDisplayOrientation()
. Sebaliknya, pratinjau HARUS dicerminkan di sepanjang sumbu horizontal default perangkat jika aplikasi saat ini tidak secara eksplisit meminta tampilan Kamera diputar melalui panggilan ke metodeandroid.hardware.Camera.setDisplayOrientation()
. - [C-1-5] TIDAK BOLEH mencerminkan gambar diam atau streaming video akhir yang diambil yang ditampilkan ke callback aplikasi atau di-commit ke penyimpanan media.
- [C-1-6] HARUS mencerminkan gambar yang ditampilkan oleh postview dengan cara yang sama seperti streaming gambar pratinjau kamera.
- DAPAT menyertakan fitur (seperti fokus otomatis, flash, dll.) yang tersedia untuk kamera belakang seperti yang dijelaskan dalam bagian 7.5.1.
Jika implementasi perangkat dapat diputar oleh pengguna (seperti otomatis melalui akselerometer atau secara manual melalui input pengguna):
- [C-2-1] Pratinjau kamera HARUS dicerminkan secara horizontal relatif terhadap orientasi perangkat saat ini.
7.5.3. Kamera Eksternal
Memulai persyaratan baru
Kamera eksternal adalah kamera yang dapat secara fisik dipasang atau dilepas dari implementasi perangkat kapan saja dan dapat menghadap ke arah mana pun; seperti kamera USB.
Akhiri persyaratan baru
Implementasi perangkat:
- DAPAT menyertakan dukungan untuk kamera eksternal yang tidak selalu terhubung.
Jika implementasi perangkat menyertakan dukungan untuk kamera eksternal, implementasi tersebut:
- [C-1-1] HARUS mendeklarasikan flag fitur platform
android.hardware.camera.external
danandroid.hardware camera.any
. - [C-1-2] HARUS mendukung USB Video Class (UVC 1.0 atau yang lebih tinggi) jika kamera eksternal terhubung melalui port host USB.
- [C-1-3] HARUS lulus pengujian CTS kamera dengan perangkat kamera eksternal fisik terhubung. Detail pengujian CTS kamera tersedia di source.android.com.
- HARUS mendukung kompresi video seperti MJPEG untuk memungkinkan transfer streaming yang tidak dienkode berkualitas tinggi (yaitu streaming gambar mentah atau yang dikompresi secara independen).
- DAPAT mendukung beberapa kamera.
- DAPAT mendukung encoding video berbasis kamera.
Jika encoding video berbasis kamera didukung:
- [C-2-1] Streaming tanpa encoding / MJPEG simultan (resolusi QVGA atau lebih tinggi) HARUS dapat diakses oleh implementasi perangkat.
7.5.4. Perilaku Camera API
Android menyertakan dua paket API untuk mengakses kamera, android.hardware.camera2 API yang lebih baru mengekspos kontrol kamera tingkat rendah ke aplikasi, termasuk alur burst/streaming zero-copy yang efisien dan kontrol per frame eksposur, gain, gain white balance, konversi warna, denoising, sharpening, dan lainnya.
Paket API lama,android.hardware.Camera
, ditandai sebagai tidak digunakan lagi di
Android 5.0, tetapi masih tersedia untuk digunakan aplikasi. Implementasi perangkat
Android HARUS memastikan dukungan berkelanjutan API seperti yang dijelaskan di
bagian ini dan di Android SDK.
Semua fitur yang umum antara class android.hardware.Camera yang tidak digunakan lagi dan paket android.hardware.camera2 yang lebih baru HARUS memiliki performa dan kualitas yang setara di kedua API. Misalnya, dengan setelan yang setara, kecepatan dan akurasi fokus otomatis harus sama, dan kualitas gambar yang diambil harus sama. Fitur yang bergantung pada semantik yang berbeda dari kedua API tidak diwajibkan untuk memiliki kecepatan atau kualitas yang cocok, tetapi HARUS cocok sebanyak mungkin.
Implementasi perangkat HARUS menerapkan perilaku berikut untuk API terkait kamera, untuk semua kamera yang tersedia. Implementasi perangkat:
- [C-0-1] HARUS menggunakan
android.hardware.PixelFormat.YCbCr_420_SP
untuk data pratinjau yang diberikan ke callback aplikasi jika aplikasi belum pernah memanggilandroid.hardware.Camera.Parameters.setPreviewFormat(int)
. - [C-0-2] HARUS lebih lanjut dalam format encoding NV21 saat aplikasi
mendaftarkan instance
android.hardware.Camera.PreviewCallback
dan sistem memanggil metodeonPreviewFrame()
dan format pratinjau adalah YCbCr_420_SP, data dalam byte[] diteruskan keonPreviewFrame()
. Artinya, NV21 HARUS menjadi default. - [C-0-3] HARUS mendukung format YV12 (seperti yang ditunjukkan oleh
konstanta
android.graphics.ImageFormat.YV12
) untuk pratinjau kamera untuk kamera depan dan belakang untukandroid.hardware.Camera
. (Encoder video dan kamera hardware dapat menggunakan format piksel native apa pun, tetapi penerapan perangkat HARUS mendukung konversi ke YV12.) - [C-0-4] HARUS mendukung format
android.hardware.ImageFormat.YUV_420_888
danandroid.hardware.ImageFormat.JPEG
sebagai output melaluiandroid.media.ImageReader
API untuk perangkatandroid.hardware.camera2
yang mengumumkan kemampuanREQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE
diandroid.request.availableCapabilities
. - [C-0-5] HARUS tetap mengimplementasikan Camera API lengkap
yang disertakan dalam dokumentasi Android SDK, terlepas dari apakah perangkat
menyertakan fokus otomatis hardware atau kemampuan lainnya. Misalnya, kamera yang
tidak memiliki fokus otomatis HARUS tetap memanggil instance
android.hardware.Camera.AutoFocusCallback
yang terdaftar (meskipun hal ini tidak relevan dengan kamera non-fokus otomatis). Perhatikan bahwa hal ini berlaku untuk kamera depan; misalnya, meskipun sebagian besar kamera depan tidak mendukung fokus otomatis, callback API masih harus "dipalsukan" seperti yang dijelaskan. - [C-0-6] HARUS mengenali dan mematuhi setiap nama parameter
yang ditentukan sebagai konstanta dalam
class
android.hardware.Camera.Parameters
dan classandroid.hardware.camera2.CaptureRequest
. Sebaliknya, implementasi perangkat TIDAK BOLEH mematuhi atau mengenali konstanta string yang diteruskan ke metodeandroid.hardware.Camera.setParameters()
selain yang didokumentasikan sebagai konstanta diandroid.hardware.Camera.Parameters
. Artinya, penerapan perangkat HARUS mendukung semua parameter Kamera standar jika hardware mengizinkan, dan TIDAK BOLEH mendukung jenis parameter Kamera kustom. Misalnya, implementasi perangkat yang mendukung pengambilan gambar menggunakan teknik pencitraan rentang dinamis tinggi (HDR) HARUS mendukung parameter kameraCamera.SCENE_MODE_HDR
. - [C-0-7] HARUS melaporkan tingkat dukungan yang sesuai dengan
properti
android.info.supportedHardwareLevel
seperti yang dijelaskan di Android SDK dan melaporkan flag fitur framework yang sesuai. - [C-0-8] JUGA HARUS mendeklarasikan kemampuan kamera individualnya
android.hardware.camera2
melalui propertiandroid.request.availableCapabilities
dan mendeklarasikan flag fitur yang sesuai; HARUS menentukan flag fitur jika ada perangkat kamera yang terpasang yang mendukung fitur tersebut. - [C-0-9] HARUS menyiarkan intent
Camera.ACTION_NEW_PICTURE
setiap kali gambar baru diambil oleh kamera dan entri gambar telah ditambahkan ke penyimpanan media. - [C-0-10] HARUS menyiarkan intent
Camera.ACTION_NEW_VIDEO
setiap kali video baru direkam oleh kamera dan entri gambar telah ditambahkan ke penyimpanan media. - [C-0-11] HARUS memiliki semua kamera yang dapat diakses melalui API
android.hardware.Camera
yang tidak digunakan lagi, yang juga dapat diakses melalui APIandroid.hardware.camera2
. - [C-0-12] HARUS memastikan bahwa tampilan wajah TIDAK diubah, termasuk
tetapi tidak terbatas pada mengubah geometri wajah, warna kulit wajah, atau
penghalusan kulit wajah untuk API
android.hardware.camera2
atauandroid.hardware.Camera
. - [C-SR-1] Untuk perangkat dengan beberapa kamera RGB yang berada
di 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 kamera RGB yang menghadap ke arah tersebut sebagai sub-perangkat fisik.
Jika implementasi perangkat menyediakan API kamera eksklusif untuk aplikasi pihak ketiga, API tersebut:
- [C-1-1] HARUS menerapkan API kamera tersebut menggunakan API
android.hardware.camera2
. - DAPAT memberikan tag dan/atau ekstensi vendor ke API
android.hardware.camera2
.
7.5.5. Orientasi Kamera
Jika implementasi perangkat memiliki kamera depan atau belakang, kamera tersebut:
- [C-1-1] HARUS diorientasikan sehingga dimensi panjang kamera sejajar dengan dimensi panjang layar. Artinya, saat perangkat dipegang dalam orientasi lanskap, kamera HARUS mengambil gambar dalam orientasi lanskap. Hal ini berlaku terlepas dari orientasi alami perangkat; yaitu, berlaku untuk perangkat utama lanskap serta perangkat utama potret.
Perangkat yang memenuhi semua kriteria berikut dikecualikan dari persyaratan di atas:
- Perangkat menerapkan layar geometri variabel, seperti layar foldable atau dengan engsel.
- Saat status lipat atau engsel perangkat berubah, perangkat akan beralih antara orientasi potret-utama ke lanskap-utama (atau sebaliknya).
Memulai persyaratan baru
- Implementasi perangkat yang tidak dapat diputar oleh pengguna seperti perangkat otomotif.
Akhiri persyaratan baru
7.6. Memori dan Penyimpanan
7.6.1. Memori dan Penyimpanan Minimum
Implementasi perangkat:
- [C-0-1] HARUS menyertakan Pengelola Download yang DAPAT digunakan aplikasi untuk mendownload file data dan HARUS mampu mendownload setiap file berukuran minimal 100 MB ke lokasi "cache" default.
7.6.2. Penyimpanan Bersama Aplikasi
Implementasi perangkat:
- [C-0-1] HARUS menawarkan penyimpanan untuk dibagikan oleh aplikasi, yang juga sering disebut sebagai "penyimpanan eksternal bersama", "penyimpanan bersama aplikasi", atau dengan jalur Linux "/sdcard" tempat penyimpanan tersebut dipasang.
- [C-0-2] HARUS dikonfigurasi dengan penyimpanan bersama yang dipasang secara default, dengan kata lain "langsung pakai", terlepas dari apakah penyimpanan diterapkan di komponen penyimpanan internal atau media penyimpanan yang dapat dilepas (misalnya, slot kartu Digital yang Aman).
- [C-0-3] HARUS memasang penyimpanan bersama aplikasi secara langsung di jalur Linux
sdcard
atau menyertakan link simbolis Linux darisdcard
ke titik mount yang sebenarnya. - [C-0-4] HARUS mengaktifkan
penyimpanan terbatas
secara default untuk semua
aplikasi yang menargetkan API level 29 atau yang lebih tinggi, kecuali dalam situasi berikut:
- Saat aplikasi telah meminta
android:requestLegacyExternalStorage="true"
dalam manifesnya.
- Saat aplikasi telah meminta
- [C-0-5] HARUS menyamarkan metadata lokasi, seperti tag Exif GPS, yang disimpan dalam
file media saat file tersebut diakses melalui
MediaStore
, kecuali jika aplikasi pemanggil memiliki izinACCESS_MEDIA_LOCATION
.
Implementasi perangkat DAPAT memenuhi persyaratan di atas menggunakan salah satu hal berikut:
- Penyimpanan portabel yang dapat diakses pengguna, seperti slot kartu Secure Digital (SD).
- Sebagian penyimpanan internal (tidak dapat dilepas) seperti yang diterapkan di Project Open Source Android (AOSP).
Jika implementasi perangkat menggunakan penyimpanan yang dapat dilepas untuk memenuhi persyaratan di atas, implementasi tersebut:
- [C-1-1] HARUS menerapkan antarmuka pengguna toast atau pop-up yang memperingatkan pengguna saat tidak ada media penyimpanan yang dimasukkan ke dalam slot.
- [C-1-2] HARUS menyertakan media penyimpanan berformat FAT (misalnya kartu SD) atau menunjukkan pada kotak dan materi lain yang tersedia pada saat pembelian bahwa media penyimpanan harus dibeli secara terpisah.
Jika implementasi perangkat menggunakan sebagian penyimpanan yang tidak dapat dilepas untuk memenuhi persyaratan di atas, implementasi tersebut:
- HARUS menggunakan implementasi AOSP untuk penyimpanan bersama aplikasi internal.
- DAPAT berbagi ruang penyimpanan dengan data pribadi aplikasi.
Jika implementasi perangkat memiliki port USB dengan dukungan mode periferal USB, perangkat tersebut:
- [C-3-1] HARUS menyediakan mekanisme untuk mengakses data di penyimpanan bersama aplikasi dari komputer host.
- HARUS mengekspos konten dari kedua jalur penyimpanan secara transparan melalui
layanan pemindai media Android dan
android.provider.MediaStore
. - BOLEH menggunakan penyimpanan massal USB, tetapi HARUS menggunakan Media Transfer Protocol untuk memenuhi persyaratan ini.
Jika implementasi perangkat memiliki port USB dengan mode periferal USB dan mendukung Media Transfer Protocol, perangkat tersebut:
- HARUS kompatibel dengan host MTP Android referensi, Android File Transfer.
- HARUS melaporkan class perangkat USB 0x00.
- HARUS melaporkan nama antarmuka USB 'MTP'.
7.6.3. Penyimpanan yang Dapat Diadopsi
Jika perangkat diharapkan bersifat seluler, tidak seperti Televisi, implementasi perangkat adalah:
- [C-SR-1] SANGAT DISARANKAN untuk menerapkan penyimpanan yang dapat diadopsi di lokasi yang stabil dalam jangka panjang, karena memutuskan koneksinya secara tidak sengaja dapat menyebabkan hilangnya/kerusakan data.
Jika port perangkat penyimpanan yang dapat dilepas berada di lokasi yang stabil dalam jangka panjang, seperti dalam kompartemen baterai atau penutup pelindung lainnya, implementasi perangkat adalah:
- [C-SR-2] SANGAT DIUJAMI untuk menerapkan penyimpanan yang dapat diadaptasi.
7.7. USB
Jika implementasi perangkat memiliki port USB, perangkat tersebut:
- HARUS mendukung mode periferal USB dan HARUS mendukung mode host USB.
- HARUS mendukung penonaktifan sinyal data melalui USB.
7.7.1. Mode periferal USB
Jika implementasi perangkat menyertakan port USB yang mendukung mode periferal:
- [C-1-1] Port HARUS dapat dihubungkan ke host USB yang memiliki port USB type-A atau type-C standar.
- [C-1-2] HARUS melaporkan nilai
iSerialNumber
yang benar dalam deskripsi perangkat standar USB melaluiandroid.os.Build.SERIAL
. - [C-1-3] HARUS mendeteksi pengisi daya 1,5 A dan 3,0 A sesuai standar resistor Type-C dan HARUS mendeteksi perubahan dalam iklan jika mendukung USB Type-C.
- [C-SR-1] Port HARUS menggunakan faktor bentuk USB micro-B, micro-AB, atau Type-C. Perangkat Android yang ada dan baru SANGAT DISARANKAN untuk memenuhi persyaratan ini agar dapat diupgrade ke rilis platform mendatang.
- [C-SR-2] Port HARUS berada di bagian bawah perangkat (sesuai dengan orientasi alami) atau mengaktifkan rotasi layar software untuk semua aplikasi (termasuk layar utama), sehingga layar digambar dengan benar saat perangkat diorientasikan dengan port di bagian bawah. Perangkat Android yang ada dan baru SANGAT DISARANKAN untuk memenuhi persyaratan ini sehingga dapat diupgrade ke rilis platform mendatang.
- [C-SR-3] HARUS menerapkan dukungan untuk menarik arus 1,5 A selama chirp dan traffic HS seperti yang ditentukan dalam spesifikasi Pengisian Daya Baterai USB, revisi 1.2. Perangkat Android yang ada dan baru SANGAT DISARANKAN untuk memenuhi persyaratan ini agar dapat diupgrade ke rilis platform mendatang.
- [C-SR-4] SANGAT DISARANKAN untuk tidak mendukung metode pengisian daya eksklusif yang mengubah voltase Vbus di luar level default, atau mengubah peran sink/sumber sehingga dapat menyebabkan masalah interoperabilitas dengan pengisi daya atau perangkat yang mendukung metode USB Power Delivery standar. Meskipun disebut sebagai "SANGAT DIUJAMI", pada versi Android mendatang, kami mungkin MEWAJIBKAN semua perangkat type-C untuk mendukung interoperabilitas penuh dengan charger type-C standar.
- [C-SR-5] SANGAT DISARANKAN untuk mendukung Pengiriman Daya untuk data dan penggantian peran daya jika mendukung USB Type-C dan mode host USB.
- HARUS mendukung Pengiriman Daya untuk pengisian daya bertegangan tinggi dan dukungan untuk Mode Alternatif seperti tampilan keluar.
- HARUS menerapkan API dan spesifikasi Android Open Accessory (AOA) seperti yang didokumentasikan dalam dokumentasi Android SDK.
Jika implementasi perangkat menyertakan port USB dan menerapkan spesifikasi AOA, perangkat tersebut:
- [C-2-1] HARUS mendeklarasikan dukungan untuk fitur hardware
android.hardware.usb.accessory
. - [C-2-2] Class penyimpanan massal USB HARUS menyertakan string "android" di
akhir string
iInterface
deskripsi antarmuka penyimpanan massal USB
7.7.2. Mode host USB
Jika implementasi perangkat menyertakan port USB yang mendukung mode host, port tersebut:
- [C-1-1] HARUS menerapkan API host USB Android seperti yang didokumentasikan dalam
Android SDK dan HARUS mendeklarasikan dukungan untuk fitur hardware
android.hardware.usb.host
. - [C-1-2] HARUS mengimplementasikan dukungan untuk menghubungkan periferal USB standar,
dengan kata lain, perangkat HARUS:
- Memiliki port type C di perangkat atau dikirimkan dengan kabel yang menyesuaikan port eksklusif di perangkat ke port USB type-C standar (perangkat USB Type-C).
- Memiliki port jenis A di perangkat atau dikirimkan dengan kabel yang menyesuaikan port eksklusif di perangkat ke port USB jenis A standar.
- Memiliki port micro-AB di perangkat, yang HARUS dilengkapi dengan kabel yang beradaptasi dengan port jenis A standar.
- [C-1-3] TIDAK BOLEH dikirimkan dengan adaptor yang mengonversi dari port USB jenis A atau micro-AB ke port jenis C (penampung).
- [C-SR-1] SANGAT DISARANKAN untuk menerapkan class audio USB seperti yang didokumentasikan dalam dokumentasi Android SDK.
- HARUS mendukung pengisian daya perangkat periferal USB yang terhubung saat dalam mode host; mengiklankan arus sumber minimal 1,5 A seperti yang ditentukan di bagian Parameter Penghentian dalam Spesifikasi Konektor dan Kabel USB Type-C Revisi 1.2 untuk konektor USB Type-C atau menggunakan rentang arus output Port Downstream Pengisian Daya (CDP) seperti yang ditentukan dalam Spesifikasi Pengisian Daya Baterai USB, revisi 1.2 untuk konektor Micro-AB.
- HARUS menerapkan dan mendukung standar USB Type-C.
Jika implementasi perangkat menyertakan port USB yang mendukung mode host dan class audio USB, port tersebut:
- [C-2-1] HARUS mendukung class HID USB.
- [C-2-2] HARUS mendukung deteksi dan pemetaan kolom data HID
berikut yang ditentukan dalam Tabel Penggunaan HID USB
dan Permintaan Penggunaan Perintah Suara
ke konstanta
KeyEvent
seperti di bawah ini:- ID Penggunaan Halaman Penggunaan (0xC) (0x0CD):
KEYCODE_MEDIA_PLAY_PAUSE
- Halaman Penggunaan (0xC) ID Penggunaan (0x0E9):
KEYCODE_VOLUME_UP
- ID Penggunaan Halaman Penggunaan (0xC) (0x0EA):
KEYCODE_VOLUME_DOWN
- Halaman Penggunaan (0xC) ID Penggunaan (0x0CF):
KEYCODE_VOICE_ASSIST
- ID Penggunaan Halaman Penggunaan (0xC) (0x0CD):
Jika implementasi perangkat menyertakan port USB yang mendukung mode host dan Storage Access Framework (SAF), port tersebut:
- [C-3-1] HARUS mengenali perangkat MTP (Media Transfer Protocol)
yang terhubung dari jarak jauh dan membuat kontennya dapat diakses melalui intent
ACTION_GET_CONTENT
,ACTION_OPEN_DOCUMENT
, danACTION_CREATE_DOCUMENT
. .
Jika implementasi perangkat menyertakan port USB yang mendukung mode host dan USB Type-C, port tersebut:
- [C-4-1] HARUS menerapkan fungsi Port Peran Ganda seperti yang ditentukan oleh spesifikasi USB Type-C (bagian 4.5.1.3.3). Untuk Port Peran Ganda, Pada perangkat yang menyertakan jack audio 3,5 mm, deteksi sink USB (mode host) DAPAT nonaktif secara default, tetapi pengguna HARUS dapat mengaktifkannya.
- [C-SR-2] SANGAT DISARANKAN untuk mendukung DisplayPort, HARUS mendukung Kecepatan Data SuperSpeed USB, dan SANGAT DISARANKAN untuk mendukung Pengiriman Daya untuk pertukaran peran data dan daya.
- [C-SR-3] SANGAT DISARANKAN untuk TIDAK mendukung Mode Aksesori Adaptor Audio seperti yang dijelaskan dalam Lampiran A dari Spesifikasi Kabel dan Konektor USB Type-C Revisi 1.2.
- HARUS menerapkan model Try.* yang paling sesuai untuk faktor bentuk perangkat. Misalnya, perangkat genggam HARUS menerapkan model Try.SNK.
7.8. Audio
7.8.1. Mikrofon
Jika implementasi perangkat menyertakan mikrofon, mikrofon tersebut:
- [C-1-1] HARUS melaporkan konstanta fitur
android.hardware.microphone
. - [C-1-2] HARUS memenuhi persyaratan perekaman audio di bagian 5.4.
- [C-1-3] HARUS memenuhi persyaratan latensi audio di bagian 5.6.
- [C-SR-1] SANGAT DIUJAMI untuk mendukung perekaman near-ultrasound seperti yang dijelaskan di bagian 7.8.3.
Jika implementasi perangkat menghilangkan mikrofon, implementasi tersebut:
- [C-2-1] TIDAK BOLEH melaporkan konstanta fitur
android.hardware.microphone
. - [C-2-2] HARUS menerapkan API perekaman audio setidaknya sebagai no-ops, sesuai bagian 7.
7.8.2. Output Audio
Jika implementasi perangkat menyertakan speaker atau port output audio/multimedia untuk periferal output audio seperti colokan audio 3,5 mm 4 konduktor atau port mode host USB menggunakan class audio USB, perangkat tersebut:
- [C-1-1] HARUS melaporkan konstanta fitur
android.hardware.audio.output
. - [C-1-2] HARUS memenuhi persyaratan pemutaran audio di bagian 5.5.
- [C-1-3] HARUS memenuhi persyaratan latensi audio di bagian 5.6.
- [C-SR-1] SANGAT DIUJAMI untuk mendukung pemutaran mendekati ultrasonik seperti yang dijelaskan di bagian 7.8.3.
Jika implementasi perangkat tidak menyertakan speaker atau port output audio, implementasi tersebut:
- [C-2-1] TIDAK BOLEH melaporkan fitur
android.hardware.audio.output
. - [C-2-2] HARUS menerapkan API terkait Output Audio setidaknya sebagai no-ops.
Untuk tujuan bagian ini, "port output" adalah antarmuka fisik seperti jack audio 3,5 mm, HDMI, atau port mode host USB dengan class audio USB. Dukungan untuk output audio melalui protokol berbasis radio seperti Bluetooth, Wi-Fi, atau jaringan seluler tidak memenuhi syarat untuk menyertakan "port output".
7.8.2.1. Port Audio Analog
Agar kompatibel dengan headset dan aksesori audio lainnya yang menggunakan steker audio 3,5 mm di seluruh ekosistem Android, jika penerapan perangkat menyertakan satu atau beberapa port audio analog, perangkat tersebut:
- [C-SR-1] SANGAT DISARANKAN untuk menyertakan setidaknya salah satu port audio sebagai jack audio 3,5 mm 4 konduktor.
Jika implementasi perangkat memiliki jack audio 3,5 mm dengan 4 konduktor, perangkat tersebut:
- [C-1-1] HARUS mendukung pemutaran audio ke headphone stereo dan headset stereo dengan mikrofon.
- [C-1-2] HARUS mendukung steker audio TRRS dengan urutan pin CTIA.
- [C-1-3] HARUS mendukung deteksi dan pemetaan ke kode kunci untuk
3 rentang impedansi ekivalen berikut antara konduktor mikrofon dan
ground pada steker audio:
- 70 ohm atau kurang:
KEYCODE_HEADSETHOOK
- 210-290 ohm:
KEYCODE_VOLUME_UP
- 360-680 ohm:
KEYCODE_VOLUME_DOWN
- 70 ohm atau kurang:
- [C-1-4] HARUS memicu
ACTION_HEADSET_PLUG
saat steker dimasukkan, tetapi hanya setelah semua kontak pada steker menyentuh segmen yang relevan di jack. - [C-1-5] HARUS dapat menggerakkan setidaknya 150 mV ± 10% tegangan output pada impedansi speaker 32 ohm.
- [C-1-6] HARUS memiliki voltase bias mikrofon antara 1,8 V ~ 2,9 V.
- [C-1-7] HARUS mendeteksi dan memetakan ke kode kunci untuk rentang
impedansi ekivalen berikut antara mikrofon dan konduktor ground
pada steker audio:
- 110-180 ohm:
KEYCODE_VOICE_ASSIST
- 110-180 ohm:
- [C-SR-2] SANGAT DISARANKAN untuk mendukung steker audio dengan urutan pin OMTP.
- [C-SR-3] SANGAT DISARANKAN untuk mendukung perekaman audio dari headset stereo dengan mikrofon.
Jika implementasi perangkat memiliki jack audio 3,5 mm 4 konduktor dan mendukung
mikrofon, serta menyiarkan android.intent.action.HEADSET_PLUG
dengan
mikrofon nilai tambahan yang ditetapkan sebagai 1, perangkat tersebut:
- [C-2-1] HARUS mendukung deteksi mikrofon pada aksesori audio yang dicolokkan.
7.8.2.2. Port Audio Digital
Lihat Bagian 2.2.1 untuk mengetahui persyaratan khusus perangkat.
7.8.3. Ultrasonografi Dekat
Audio Near-Ultrasound adalah band 18,5 kHz hingga 20 kHz.
Implementasi perangkat:
- HARUS melaporkan dukungan kemampuan audio near-ultrasound dengan benar melalui AudioManager.getProperty API sebagai berikut:
Jika PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND
adalah "true", persyaratan berikut HARUS dipenuhi oleh
sumber audio VOICE_RECOGNITION
dan UNPROCESSED
:
- [C-1-1] Respons daya rata-rata mikrofon dalam band 18,5 kHz hingga 20 kHz HARUS tidak lebih dari 15 dB di bawah respons pada 2 kHz.
- [C-1-2] Rasio sinyal terhadap derau mikrofon yang tidak tertimbang di atas 18,5 kHz hingga 20 kHz untuk nada 19 kHz pada -26 dBFS HARUS tidak lebih rendah dari 50 dB.
Jika PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND
adalah "true":
- [C-2-1] Respons rata-rata speaker dalam 18,5 kHz - 20 kHz HARUS tidak lebih rendah dari 40 dB di bawah respons pada 2 kHz.
7.8.4. Integritas Sinyal
Implementasi perangkat:
- HARUS menyediakan jalur sinyal audio bebas gangguan untuk streaming input dan output di perangkat genggam, seperti yang ditentukan oleh nol gangguan yang diukur selama pengujian satu menit per jalur. Uji menggunakan OboeTester "Automated Glitch Test".
Pengujian ini memerlukan dongle loopback audio, yang digunakan langsung di jack 3,5 mm, dan/atau dalam kombinasi dengan adaptor USB-C ke 3,5 mm. Semua port output audio HARUS diuji.
OboeTester saat ini mendukung jalur AAudio, sehingga kombinasi berikut HARUS diuji untuk menemukan gangguan menggunakan AAudio:
Mode Perf | Berbagi | Frekuensi Sampel Keluar | Dalam Chan | Out Chans |
---|---|---|---|---|
LOW_LATENCY | EKSKLUSIF | BELUM DITENTUKAN | 1 | 2 |
LOW_LATENCY | EKSKLUSIF | BELUM DITENTUKAN | 2 | 1 |
LOW_LATENCY | DIBAGIKAN | BELUM DITENTUKAN | 1 | 2 |
LOW_LATENCY | DIBAGIKAN | BELUM DITENTUKAN | 2 | 1 |
TIDAK ADA | DIBAGIKAN | 48000 | 1 | 2 |
TIDAK ADA | DIBAGIKAN | 48000 | 2 | 1 |
TIDAK ADA | DIBAGIKAN | 44100 | 1 | 2 |
TIDAK ADA | DIBAGIKAN | 44100 | 2 | 1 |
TIDAK ADA | DIBAGIKAN | 16000 | 1 | 2 |
TIDAK ADA | DIBAGIKAN | 16000 | 2 | 1 |
Streaming yang andal HARUS memenuhi kriteria berikut untuk Rasio Sinyal terhadap Kebisingan (SNR) dan Total Harmonic Distortion (THD) untuk sinyal sinus 2.000 Hz.
Transduser | THD | SNR |
---|---|---|
speaker bawaan utama, diukur menggunakan mikrofon referensi eksternal | < 3,0% | >= 50 dB |
mikrofon bawaan utama, diukur menggunakan speaker referensi eksternal | < 3,0% | >= 50 dB |
colokan 3,5 mm analog bawaan, diuji menggunakan adaptor loopback | < 1% | >= 60 dB |
Adaptor USB yang disertakan dengan ponsel, diuji menggunakan adaptor loopback | < 1,0% | >= 60 dB |
7.9. Virtual Reality
Android menyertakan API dan fasilitas untuk mem-build aplikasi "Virtual Reality" (VR) termasuk pengalaman VR seluler berkualitas tinggi. Implementasi perangkat HARUS menerapkan API dan perilaku ini dengan benar, seperti yang dijelaskan di bagian ini.
7.9.1. Mode Virtual Reality
Android menyertakan dukungan untuk Mode VR, fitur yang menangani rendering notifikasi stereoskopik dan menonaktifkan komponen UI sistem monokuler saat aplikasi VR memiliki fokus pengguna.
7.9.2. Mode Virtual Reality - Performa Tinggi
Jika implementasi perangkat mendukung mode VR, implementasi tersebut:
- [C-1-1] HARUS memiliki minimal 2 core fisik.
- [C-1-2] HARUS mendeklarasikan fitur
android.hardware.vr.high_performance
. - [C-1-3] HARUS mendukung mode performa berkelanjutan.
- [C-1-4] HARUS mendukung OpenGL ES 3.2.
- [C-1-5] HARUS mendukung
android.hardware.vulkan.level
0. - HARUS mendukung
android.hardware.vulkan.level
1 atau yang lebih tinggi. - [C-1-6] HARUS mengimplementasikan
EGL_KHR_mutable_render_buffer
,EGL_ANDROID_front_buffer_auto_refresh
,EGL_ANDROID_get_native_client_buffer
,EGL_KHR_fence_sync
,EGL_KHR_wait_sync
,EGL_IMG_context_priority
,EGL_EXT_protected_content
,EGL_EXT_image_gl_colorspace
, dan mengekspos ekstensi dalam daftar ekstensi EGL yang tersedia. - [C-1-8] HARUS mengimplementasikan
GL_EXT_multisampled_render_to_texture2
,GL_OVR_multiview
,GL_OVR_multiview2
,GL_EXT_protected_textures
, dan mengekspos ekstensi dalam daftar ekstensi GL yang tersedia. - [C-SR-1] SANGAT DISARANKAN untuk mengimplementasikan
GL_EXT_external_buffer
,GL_EXT_EGL_image_array
,GL_OVR_multiview_multisampled_render_to_texture
, dan mengekspos ekstensi dalam daftar ekstensi GL yang tersedia. - [C-SR-2] SANGAT DISARANKAN untuk mendukung Vulkan 1.1.
- [C-SR-3] SANGAT DIUJUDKAN untuk mengimplementasikan
VK_ANDROID_external_memory_android_hardware_buffer
,VK_GOOGLE_display_timing
,VK_KHR_shared_presentable_image
, dan mengeksposnya dalam daftar ekstensi Vulkan yang tersedia. - [C-SR-4] SANGAT DIUJAMI untuk mengekspos minimal satu keluarga antrean Vulkan dengan
flags
berisiVK_QUEUE_GRAPHICS_BIT
danVK_QUEUE_COMPUTE_BIT
, danqueueCount
minimal 2. - [C-1-7] GPU dan layar HARUS dapat menyinkronkan akses ke buffering depan umum sehingga rendering mata bergantian konten VR pada 60 fps dengan dua konteks render akan ditampilkan tanpa artefak tearing yang terlihat.
- [C-1-9] HARUS mengimplementasikan dukungan untuk flag
AHardwareBuffer
AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER
,AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA
, danAHARDWAREBUFFER_USAGE_PROTECTED_CONTENT
seperti yang dijelaskan dalam NDK. - [C-1-10] HARUS menerapkan dukungan untuk
AHardwareBuffer
dengan kombinasi flag penggunaanAHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT
,AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE
,AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT
setidaknya untuk format berikut:AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM
,AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM
,AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM
,AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT
. - [C-SR-5] SANGAT DIUJAMI untuk mendukung alokasi
AHardwareBuffer
dengan lebih dari satu lapisan serta flag dan format yang ditentukan dalam C-1-10. - [C-1-11] HARUS mendukung decoding H.264 minimal 3840 x 2160 pada 30 fps, yang dikompresi menjadi rata-rata 40 Mbps (setara dengan 4 instance 1920 x 1080 pada 30 fps-10 Mbps atau 2 instance 1920 x 1080 pada 60 fps-20 Mbps).
- [C-1-12] HARUS mendukung HEVC dan VP9, HARUS mampu mendekode setidaknya 1920x1080 pada 30 fps yang dikompresi menjadi rata-rata 10 Mbps dan HARUS mampu mendekode 3840x2160 pada 30 fps-20 Mbps (setara dengan 4 instance 1920x1080 pada 30 fps-5 Mbps).
- [C-1-13] HARUS mendukung
HardwarePropertiesManager.getDeviceTemperatures
API dan menampilkan nilai yang akurat untuk suhu kulit. - [C-1-14] HARUS memiliki layar tersemat, dan resolusinya HARUS setidaknya 1920x1080.
- [C-SR-6] SANGAT DISARANKAN untuk memiliki resolusi layar minimal 2560x1440.
- [C-1-15] Layar HARUS diperbarui setidaknya 60 Hz saat dalam Mode VR.
- [C-1-17] Layar HARUS mendukung mode persistensi rendah dengan persistensi ≤ 5 milidetik, persistensi didefinisikan sebagai jumlah waktu saat piksel memancarkan cahaya.
- [C-1-18] HARUS mendukung Bluetooth 4.2 dan Bluetooth LE Data Length Extension bagian 7.4.3.
- [C-1-19] HARUS mendukung dan melaporkan
Jenis Saluran Langsung
dengan benar untuk semua jenis sensor default berikut:
TYPE_ACCELEROMETER
TYPE_ACCELEROMETER_UNCALIBRATED
TYPE_GYROSCOPE
TYPE_GYROSCOPE_UNCALIBRATED
TYPE_MAGNETIC_FIELD
TYPE_MAGNETIC_FIELD_UNCALIBRATED
- [C-SR-7] SANGAT DIUJAMI untuk mendukung
jenis saluran langsung
TYPE_HARDWARE_BUFFER
untuk semua Jenis Saluran Langsung yang tercantum di atas. - [C-1-21] HARUS memenuhi persyaratan terkait giroskop, akselerometer, dan magnetometer
untuk
android.hardware.hifi_sensors
, seperti yang ditentukan dalam bagian 7.3.9. - [C-SR-8] SANGAT DIUJI untuk mendukung
fitur
android.hardware.sensor.hifi_sensors
. - [C-1-22] HARUS memiliki latensi gerakan menyeluruh ke foton tidak lebih tinggi dari 28 milidetik.
- [C-SR-9] SANGAT DISARANKAN untuk memiliki latensi gerakan ke foton yang tidak lebih tinggi dari 20 milidetik.
- [C-1-23] HARUS memiliki rasio frame pertama, yaitu rasio antara kecerahan piksel pada frame pertama setelah transisi dari hitam ke putih dan kecerahan piksel putih dalam status stabil, minimal 85%.
- [C-SR-10] SANGAT DISARANKAN untuk memiliki rasio frame pertama minimal 90%.
- DAPAT menyediakan core eksklusif ke aplikasi
latar depan dan DAPAT mendukung
Process.getExclusiveCores
API untuk menampilkan jumlah core CPU yang eksklusif untuk aplikasi latar depan teratas.
Jika core eksklusif didukung, core tersebut:
- [C-2-1] HARUS tidak mengizinkan proses ruang pengguna lain berjalan di dalamnya (kecuali driver perangkat yang digunakan oleh aplikasi), tetapi DAPAT mengizinkan beberapa proses kernel berjalan sesuai kebutuhan.
7.10. Sentuhan
Memulai persyaratan baru
Perangkat yang dimaksudkan untuk dipegang atau dikenakan dapat menyertakan aktuator haptik umum, yang tersedia untuk aplikasi untuk tujuan termasuk mendapatkan perhatian melalui nada dering, alarm, notifikasi, serta respons sentuh umum.
Jika implementasi perangkat TIDAK menyertakan aktuator haptik tujuan umum tersebut, implementasi tersebut:
- [7.10/C] HARUS menampilkan nilai salah (false) untuk
Vibrator.hasVibrator()
.
Jika implementasi perangkat MENYERTAI setidaknya satu aktuator haptik umum tersebut, implementasi tersebut:
- [C-1-1] HARUS menampilkan true untuk
Vibrator.hasVibrator()
. - TIDAK BOLEH menggunakan aktuator haptic (vibrator) massa berputar eksentrik (ERM).
- HARUS menerapkan semua konstanta publik untuk haptik yang jelas
di
android.view.HapticFeedbackConstants
yaitu (CLOCK_TICK
,CONTEXT_CLICK
,KEYBOARD_PRESS
,KEYBOARD_RELEASE
,KEYBOARD_TAP
,LONG_PRESS
,TEXT_HANDLE_MOVE
,VIRTUAL_KEY
,VIRTUAL_KEY_RELEASE
,CONFIRM
,REJECT
,GESTURE_START
, danGESTURE_END
). - HARUS mengimplementasikan semua konstanta publik untuk haptik yang jelas
di
android.os.VibrationEffect
yaitu (EFFECT_TICK
,EFFECT_CLICK
,EFFECT_HEAVY_CLICK
, danEFFECT_DOUBLE_CLICK
) serta semua konstantaPRIMITIVE_*
publik yang memungkinkan untuk haptik yang kaya diandroid.os.VibrationEffect.Composition
yaitu (CLICK
,TICK
,LOW_TICK
,QUICK_FALL
,QUICK_RISE
,SLOW_RISE
,SPIN
,THUD
). Beberapa primitif ini, sepertiLOW_TICK
danSPIN
mungkin hanya dapat dilakukan jika vibrator dapat mendukung frekuensi yang relatif rendah. - HARUS mengikuti panduan untuk memetakan konstanta publik
di
android.view.HapticFeedbackConstants
ke konstantaandroid.os.VibrationEffect
yang direkomendasikan, dengan hubungan amplitudo yang sesuai. - HARUS menggunakan pemetaan konstanta haptic tertaut ini.
- HARUS mengikuti penilaian kualitas
untuk API
createOneShot()
dancreateWaveform()
. - HARUS memverifikasi bahwa hasil API
android.os.Vibrator.hasAmplitudeControl()
publik mencerminkan kemampuan vibratornya dengan benar. - HARUS memverifikasi kemampuan untuk skalabilitas amplitudo dengan menjalankan
android.os.Vibrator.hasAmplitudeControl()
.
Jika implementasi perangkat mengikuti pemetaan konstanta haptic, implementasi tersebut:
- HARUS memverifikasi status penerapan dengan menjalankan API
android.os.Vibrator.areAllEffectsSupported()
danandroid.os.Vibrator.arePrimitivesSupported()
. - HARUS melakukan penilaian kualitas untuk konstanta haptic.
- HARUS memverifikasi dan memperbarui jika diperlukan konfigurasi penggantian untuk primitif yang tidak didukung seperti yang dijelaskan dalam panduan penerapan untuk konstanta.
- HARUS memberikan dukungan penggantian untuk mengurangi risiko kegagalan seperti yang dijelaskan di sini.
Akhiri persyaratan baru
Lihat Bagian 2.2.1 untuk mengetahui persyaratan khusus perangkat.
7.11. Class Performa Media
Class performa media dari implementasi perangkat dapat diperoleh dari
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
API. Persyaratan
untuk class performa media ditentukan untuk setiap versi Android mulai dari
R (versi 30). Nilai khusus 0 menunjukkan bahwa perangkat bukan dari
class performa media.
Jika implementasi perangkat menampilkan nilai bukan nol untuk
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, implementasi tersebut:
[C-1-1] HARUS menampilkan setidaknya nilai
android.os.Build.VERSION_CODES.R
.[C-1-2] HARUS berupa implementasi perangkat genggam.
[C-1-3] HARUS memenuhi semua persyaratan untuk "Class Performa Media" yang dijelaskan di bagian 2.2.7.
Dengan kata lain, class performa media di Android T hanya ditentukan untuk perangkat genggam pada versi T, S, atau R.
Lihat bagian 2.2.7 untuk mengetahui persyaratan khusus perangkat.
8. Performa dan Daya
Beberapa kriteria performa dan daya minimum sangat penting bagi pengalaman pengguna dan memengaruhi asumsi dasar yang akan dimiliki developer saat mengembangkan aplikasi.
8.1. Konsistensi Pengalaman Pengguna
Antarmuka pengguna yang lancar dapat diberikan kepada pengguna akhir jika ada persyaratan minimum tertentu untuk memastikan kecepatan frame dan waktu respons yang konsisten untuk aplikasi dan game. Implementasi perangkat, bergantung pada jenis perangkat, DAPAT memiliki persyaratan yang dapat diukur untuk latensi antarmuka pengguna dan pengalihan tugas seperti yang dijelaskan di bagian 2.
8.2. Performa Akses I/O File
Menyediakan dasar pengukuran umum untuk performa akses file yang konsisten di
penyimpanan data pribadi aplikasi (partisi /data
) memungkinkan developer aplikasi
menetapkan ekspektasi yang tepat yang akan membantu desain software mereka. Implementasi
perangkat, bergantung pada jenis perangkat, MUNGKIN memiliki persyaratan tertentu
yang dijelaskan di bagian 2 untuk operasi baca
dan tulis berikut:
- Performa operasi tulis berurutan. Diukur dengan menulis file 256 MB menggunakan buffer tulis 10 MB.
- Performa operasi tulis acak. Diukur dengan menulis file 256 MB menggunakan buffer penulisan 4 KB.
- Performa baca berurutan. Diukur dengan membaca file 256 MB menggunakan buffer tulis 10 MB.
- Performa baca acak. Diukur dengan membaca file 256 MB menggunakan buffering tulis 4 KB.
8.3. Mode Hemat Daya
Jika implementasi perangkat menyertakan fitur untuk meningkatkan pengelolaan daya perangkat yang disertakan dalam AOSP (misalnya, Bucket Aplikasi Siaga, Istirahatkan) atau memperluas fitur untuk menerapkan pembatasan yang lebih ketat daripada Bucket Aplikasi Siaga RESTRICTED, fitur tersebut:
- [C-1-1] TIDAK BOLEH menyimpang dari penerapan AOSP untuk algoritma pemicu, pemeliharaan, dan pengaktifan serta penggunaan setelan sistem global atau DeviceConfig mode hemat daya Aplikasi Siaga dan Istirahatkan.
- [C-1-2] TIDAK BOLEH menyimpang dari penerapan AOSP untuk penggunaan setelan global atau DeviceConfig guna mengelola throttling tugas, alarm, dan jaringan untuk aplikasi di setiap bucket untuk mode standby Aplikasi.
- [C-1-3] TIDAK BOLEH menyimpang dari implementasi AOSP untuk jumlah Bucket Aplikasi Standby yang digunakan untuk Aplikasi Standby.
- [C-1-4] HARUS menerapkan Bucket Aplikasi Siaga dan Mode Istirahatkan seperti yang dijelaskan dalam Pengelolaan Daya.
- [C-1-5] HARUS menampilkan
true
untukPowerManager.isPowerSaveMode()
saat perangkat dalam mode hemat daya. - [C-1-6] HARUS memberikan kemampuan pengguna untuk menampilkan semua aplikasi yang dikecualikan dari mode hemat daya Standby Aplikasi dan Mode Tidur atau pengoptimalan baterai apa pun dan HARUS menerapkan intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS untuk meminta pengguna mengizinkan aplikasi mengabaikan pengoptimalan baterai.
- [C-SR-1] SANGAT DIUJAMI untuk memberikan kemampuan pengguna untuk mengaktifkan dan menonaktifkan fitur penghemat baterai.
- [C-SR-2] SANGAT DIUJAMI untuk memberikan kemampuan pengguna untuk menampilkan semua aplikasi yang dikecualikan dari mode hemat daya Aplikasi Siaga dan Istirahatkan.
Jika implementasi perangkat memperluas fitur pengelolaan daya yang disertakan dalam AOSP dan ekstensi tersebut menerapkan batasan yang lebih ketat daripada Bucket Aplikasi Standby Rare, lihat bagian 3.5.1.
Selain mode hemat daya, implementasi perangkat Android DAPAT menerapkan salah satu atau semua dari 4 status daya tidur seperti yang ditentukan oleh Advanced Configuration and Power Interface (ACPI).
Jika implementasi perangkat menerapkan status daya S4 seperti yang ditentukan oleh ACPI, implementasi tersebut:
- [C-1-1] HARUS memasuki status ini hanya setelah pengguna melakukan tindakan eksplisit untuk menempatkan perangkat dalam status tidak aktif (misalnya, dengan menutup penutup yang secara fisik merupakan bagian dari perangkat atau mematikan kendaraan atau televisi) dan sebelum pengguna mengaktifkan kembali perangkat (misalnya, dengan membuka penutup atau menyalakan kembali kendaraan atau televisi).
Jika implementasi perangkat menerapkan status daya S3 seperti yang ditentukan oleh ACPI, implementasi tersebut:
[C-2-1] HARUS memenuhi C-1-1 di atas, atau, HARUS memasuki status S3 hanya jika aplikasi pihak ketiga tidak memerlukan resource sistem (misalnya layar, CPU).
Sebaliknya, HARUS keluar dari status S3 saat aplikasi pihak ketiga memerlukan resource sistem, seperti yang dijelaskan di SDK ini.
Misalnya, saat aplikasi pihak ketiga meminta untuk menjaga layar tetap aktif melalui
FLAG_KEEP_SCREEN_ON
atau menjaga CPU tetap berjalan melaluiPARTIAL_WAKE_LOCK
, perangkat TIDAK BOLEH memasuki status S3 kecuali, seperti yang dijelaskan di C-1-1, pengguna telah mengambil tindakan eksplisit untuk menempatkan perangkat dalam status tidak aktif. Sebaliknya, pada saat tugas yang diterapkan aplikasi pihak ketiga melalui JobScheduler dipicu atau Firebase Cloud Messaging dikirim ke aplikasi pihak ketiga, perangkat HARUS keluar dari status S3 kecuali jika pengguna telah menempatkan perangkat dalam status tidak aktif. Ini bukan contoh yang komprehensif dan AOSP menerapkan sinyal bangun yang luas yang memicu bangun dari status ini.
8.4. Akuntansi Konsumsi Daya
Pencatatan dan pelaporan konsumsi daya yang lebih akurat memberikan insentif dan alat kepada developer aplikasi untuk mengoptimalkan pola penggunaan daya aplikasi.
Implementasi perangkat:
- [C-SR-1] SANGAT DISARANKAN untuk memberikan profil daya per komponen yang menentukan nilai konsumsi saat ini untuk setiap komponen hardware dan perkiraan pemakaian baterai yang disebabkan oleh komponen dari waktu ke waktu seperti yang didokumentasikan di situs Android Open Source Project.
- [C-SR-2] SANGAT DIUJAMI untuk melaporkan semua nilai konsumsi daya dalam miliamper jam (mAh).
- [C-SR-3] SANGAT DIUJAMI untuk melaporkan konsumsi daya CPU per UID setiap proses.
Project Open Source Android memenuhi persyaratan melalui
implementasi modul kernel
uid_cputime
. - [C-SR-4] SANGAT DIUJAMI untuk menyediakan penggunaan daya ini melalui
perintah shell
adb shell dumpsys batterystats
ke developer aplikasi. - HARUS diatribusikan ke komponen hardware itu sendiri jika tidak dapat mengatribusikan penggunaan daya komponen hardware ke aplikasi.
8.5. Performa yang Konsisten
Kinerja dapat berfluktuasi secara dramatis untuk aplikasi yang berjalan lama dan berperforma tinggi, baik karena aplikasi lain yang berjalan di latar belakang atau throttling CPU karena batas suhu. Android menyertakan antarmuka terprogram sehingga saat perangkat mampu, aplikasi latar depan teratas dapat meminta sistem untuk mengoptimalkan alokasi resource guna mengatasi fluktuasi tersebut.
Implementasi perangkat:
[C-0-1] HARUS melaporkan dukungan Mode Performa Berkelanjutan secara akurat melalui metode API
PowerManager.isSustainedPerformanceModeSupported()
.HARUS mendukung Mode Performa Berkelanjutan.
Jika implementasi perangkat melaporkan dukungan Mode Performa Berkelanjutan, perangkat tersebut:
- [C-1-1] HARUS memberikan tingkat performa yang konsisten ke aplikasi latar depan teratas selama minimal 30 menit, saat aplikasi memintanya.
- [C-1-2] HARUS mematuhi
Window.setSustainedPerformanceMode()
API dan API terkait lainnya.
Jika implementasi perangkat menyertakan dua core CPU atau lebih, core tersebut:
- HARUS menyediakan minimal satu core eksklusif yang dapat dicadangkan oleh aplikasi latar depan teratas.
Jika implementasi perangkat mendukung reservasi satu core eksklusif untuk aplikasi latar depan teratas, implementasi tersebut:
- [C-2-1] HARUS melaporkan melalui
metode API
Process.getExclusiveCores()
nomor ID core eksklusif yang dapat dicadangkan oleh aplikasi latar depan teratas. - [C-2-2] HARUS tidak mengizinkan proses ruang pengguna apa pun kecuali driver perangkat yang digunakan oleh aplikasi untuk berjalan di core eksklusif, tetapi DAPAT mengizinkan beberapa proses kernel berjalan sesuai kebutuhan.
Jika penerapan perangkat tidak mendukung core eksklusif, penerapan tersebut:
- [C-3-1] HARUS menampilkan daftar kosong melalui metode API
Process.getExclusiveCores()
.
9. Kompatibilitas Model Keamanan
Implementasi perangkat:
[C-0-1] HARUS menerapkan model keamanan yang konsisten dengan model keamanan platform Android seperti yang ditentukan dalam Dokumen referensi Keamanan dan Izin di API dalam dokumentasi developer Android.
[C-0-2] HARUS mendukung penginstalan aplikasi yang ditandatangani sendiri tanpa memerlukan izin/sertifikat tambahan dari pihak ketiga/otoritas mana pun.
Jika implementasi perangkat mendeklarasikan fitur
android.hardware.security.model.compatible
, implementasi tersebut:
- [C-1-1] HARUS mendukung persyaratan yang tercantum dalam subbagian berikut.
9.1. Izin
Implementasi perangkat:
[C-0-1] HARUS mendukung model izin Android dan Model Peran Android seperti yang ditentukan dalam dokumentasi developer Android. Secara khusus, SDK tersebut HARUS menerapkan setiap izin dan peran yang ditentukan seperti yang dijelaskan dalam dokumentasi SDK; tidak ada izin dan peran yang boleh dihilangkan, diubah, atau diabaikan.
DAPAT menambahkan izin tambahan, asalkan string ID izin baru tidak berada dalam namespace
android.\*
.[C-0-2] Izin dengan
protectionLevel
PROTECTION_FLAG_PRIVILEGED
HARUS hanya diberikan ke aplikasi yang diprainstal di jalur dengan hak istimewa image sistem (serta file APEX) dan berada dalam subset izin yang diizinkan secara eksplisit untuk setiap aplikasi. Implementasi AOSP memenuhi persyaratan ini dengan membaca dan mematuhi izin yang diizinkan untuk setiap aplikasi dari file di jaluretc/permissions/
dan menggunakan jalursystem/priv-app
sebagai jalur dengan hak istimewa.
Izin dengan tingkat perlindungan berbahaya adalah izin runtime.
Aplikasi dengan targetSdkVersion
> 22 memintanya saat runtime.
Implementasi perangkat:
- [C-0-3] HARUS menampilkan antarmuka khusus bagi pengguna untuk memutuskan apakah akan memberikan izin runtime yang diminta dan juga menyediakan antarmuka bagi pengguna untuk mengelola izin runtime.
- [C-0-4] HARUS memiliki satu dan hanya satu implementasi dari kedua antarmuka pengguna.
[C-0-5] TIDAK BOLEH memberikan izin runtime apa pun ke aplikasi kecuali jika:
- Aplikasi tersebut diinstal pada saat pengiriman perangkat, DAN
Izin pengguna dapat diperoleh sebelum aplikasi menggunakan izin,
ATAU
Izin runtime diberikan oleh kebijakan pemberian izin default atau untuk memegang peran platform.
[C-0-6] HARUS memberikan izin
android.permission.RECOVER_KEYSTORE
hanya ke aplikasi sistem yang mendaftarkan Agen Pemulihan yang diamankan dengan benar. Agent Pemulihan yang diamankan dengan benar didefinisikan sebagai agen software di perangkat yang disinkronkan dengan penyimpanan jarak jauh di luar perangkat, yang dilengkapi dengan hardware aman dengan perlindungan yang setara atau lebih kuat daripada yang dijelaskan dalam Layanan Google Cloud Key Vault untuk mencegah serangan brute-force pada faktor pengetahuan layar kunci.
Implementasi perangkat:
[C-0-7] HARUS mematuhi properti izin lokasi Android saat aplikasi meminta data lokasi atau aktivitas fisik melalui API Android standar atau mekanisme eksklusif. Data tersebut mencakup, tetapi tidak terbatas pada:
- Lokasi perangkat (misalnya, lintang dan bujur) seperti yang dijelaskan dalam bagian 9.8.8.
- Informasi yang dapat digunakan untuk menentukan atau memperkirakan lokasi perangkat (misalnya SSID, BSSID, ID Sel, atau lokasi jaringan yang terhubung ke perangkat).
- Aktivitas fisik pengguna atau klasifikasi aktivitas fisik.
Lebih spesifiknya, penerapan perangkat:
- [C-0-8] HARUS mendapatkan izin pengguna untuk mengizinkan aplikasi mengakses data lokasi atau aktivitas fisik.
- [C-0-9] HARUS memberikan izin runtime HANYA ke aplikasi yang memiliki
izin yang memadai seperti yang dijelaskan di SDK.
Misalnya,
TelephonyManager#getServiceState
memerlukan
android.permission.ACCESS_FINE_LOCATION
).
Satu-satunya pengecualian untuk properti izin lokasi Android di atas adalah untuk aplikasi yang tidak mengakses Lokasi untuk mendapatkan atau mengidentifikasi lokasi pengguna; khususnya:
- Saat aplikasi memiliki izin
RADIO_SCAN_WITHOUT_LOCATION
. - Untuk tujuan konfigurasi dan penyiapan perangkat, dengan aplikasi sistem memegang
izin
NETWORK_SETTINGS
atauNETWORK_SETUP_WIZARD
.
Izin dapat ditandai sebagai dibatasi sehingga mengubah perilakunya.
[C-0-10] Izin yang ditandai dengan tanda
hardRestricted
TIDAK BOLEH diberikan ke aplikasi kecuali jika:- File APK aplikasi berada di partisi sistem.
- Pengguna menetapkan peran yang terkait dengan izin
hardRestricted
ke aplikasi. - Penginstal memberikan
hardRestricted
ke aplikasi. - Aplikasi diberi
hardRestricted
pada versi Android sebelumnya.
[C-0-11] Aplikasi yang memiliki izin
softRestricted
HARUS hanya mendapatkan akses terbatas dan TIDAK BOLEH mendapatkan akses penuh hingga diizinkan seperti yang dijelaskan dalam SDK, dengan akses penuh dan terbatas ditentukan untuk setiap izinsoftRestricted
(misalnya,READ_EXTERNAL_STORAGE
).[C-0-12] TIDAK BOLEH menyediakan fungsi atau API kustom apa pun untuk mengabaikan batasan izin yang ditentukan dalam API setPermissionPolicy dan setPermissionGrantState.
[C-0-13] HARUS menggunakan AppOpsManager API untuk mencatat dan melacak setiap akses terprogram data yang dilindungi oleh izin berbahaya dari aktivitas dan layanan Android.
[C-0-14] HANYA BOLEH menetapkan peran ke aplikasi dengan fungsi yang memenuhi persyaratan peran.
[C-0-15] TIDAK BOLEH menentukan peran yang merupakan duplikat atau fungsi superset dari peran yang ditentukan oleh platform.
Jika perangkat melaporkan android.software.managed_users
, perangkat tersebut:
- [C-1-1] TIDAK BOLEH memiliki izin berikut yang diberikan secara otomatis oleh admin:
- Lokasi (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
- Kamera (CAMERA)
- Mikrofon (RECORD_AUDIO)
- Sensor tubuh (BODY_SENSORS)
- Aktivitas fisik (ACTIVITY_RECOGNITION)
Jika implementasi perangkat memberikan kemampuan pengguna untuk memilih aplikasi mana yang dapat
menggambar di atas aplikasi lain dengan aktivitas yang menangani
intent
ACTION_MANAGE_OVERLAY_PERMISSION
, aplikasi tersebut:
- [C-2-1] HARUS memastikan bahwa semua aktivitas dengan filter intent untuk
intent
ACTION_MANAGE_OVERLAY_PERMISSION
memiliki layar UI yang sama, terlepas dari aplikasi yang memulai atau informasi apa pun yang diberikannya.
Jika implementasi perangkat melaporkan android.software.device_admin, implementasi tersebut:
- [C-3-1] HARUS menampilkan pernyataan penyangkalan selama penyiapan perangkat yang dikelola sepenuhnya (penyiapan pemilik perangkat) yang menyatakan bahwa admin IT akan memiliki kemampuan untuk mengizinkan aplikasi mengontrol setelan di ponsel, termasuk mikrofon, kamera, dan lokasi, dengan opsi bagi pengguna untuk melanjutkan penyiapan atau keluar dari penyiapan KECUALI admin telah memilih untuk tidak mengontrol izin di perangkat.
Jika implementasi perangkat melakukan pra-penginstalan paket yang menyimpan salah satu peran System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence, atau System Visual Intelligence, paket tersebut:
- [C-4-1] HARUS memenuhi semua persyaratan yang diuraikan untuk implementasi perangkat di
bagian
"9.8.6 Content Capture""9.8.6 OS-level and ambient data and 9.8.15 Sandboxed API implementations".
- [C-4-2] TIDAK BOLEH memiliki izin android.permission.INTERNET. Hal ini lebih ketat daripada SANGAT DISARANKAN yang tercantum di bagian 9.8.6.
- [C-4-3] TIDAK BOLEH terikat dengan aplikasi lain, kecuali untuk aplikasi sistem berikut: Bluetooth, Kontak, Media, Telepon, SystemUI, dan komponen yang menyediakan Internet API. Hal ini lebih ketat daripada SANGAT DISARANKAN yang tercantum di bagian 9.8.6.
Memulai persyaratan baru
Jika implementasi perangkat menyertakan aplikasi default untuk mendukung
VoiceInteractionService
, aplikasi tersebut:
- [C-5-1] TIDAK BOLEH memberikan
ACCESS_FINE_LOCATION
sebagai default untuk aplikasi tersebut.
Akhiri persyaratan baru
9.2. Isolasi UID dan Proses
Implementasi perangkat:
- [C-0-1] HARUS mendukung model sandbox aplikasi Android, dengan setiap aplikasi berjalan sebagai UID gaya Unix unik dan dalam proses terpisah.
- [C-0-2] HARUS mendukung pengoperasian beberapa aplikasi sebagai ID pengguna Linux yang sama, asalkan aplikasi ditandatangani dan dibuat dengan benar, seperti yang ditentukan dalam referensi Keamanan dan Izin.
9.3. Izin Sistem File
Implementasi perangkat:
- [C-0-1] HARUS mendukung model izin akses file Android seperti yang ditentukan dalam referensi Keamanan dan Izin.
9.4. Lingkungan Eksekusi Alternatif
Implementasi perangkat HARUS mempertahankan konsistensi model keamanan dan izin Android, meskipun menyertakan lingkungan runtime yang mengeksekusi aplikasi menggunakan beberapa software atau teknologi lain selain Format Eksekusi Dalvik atau kode native. Dengan kata lain:
[C-0-1] Runtime alternatif HARUS berupa aplikasi Android, dan mematuhi model keamanan Android standar, seperti yang dijelaskan di tempat lain dalam bagian 9.
[C-0-2] Runtime alternatif TIDAK BOLEH diberi akses ke resource yang dilindungi oleh izin yang tidak diminta dalam file
AndroidManifest.xml
runtime melalui mekanisme <uses-permission
>.[C-0-3] Runtime alternatif TIDAK BOLEH mengizinkan aplikasi menggunakan fitur yang dilindungi oleh izin Android yang dibatasi untuk aplikasi sistem.
[C-0-4] Runtime alternatif HARUS mematuhi model sandbox Android dan aplikasi terinstal yang menggunakan runtime alternatif TIDAK BOLEH menggunakan kembali sandbox aplikasi lain yang diinstal di perangkat, kecuali melalui mekanisme Android standar untuk ID pengguna bersama dan sertifikat penandatanganan.
[C-0-5] Runtime alternatif TIDAK BOLEH diluncurkan dengan, memberikan, atau diberi akses ke sandbox yang sesuai dengan aplikasi Android lainnya.
[C-0-6] Runtime alternatif TIDAK BOLEH diluncurkan dengan, diberikan, atau memberikan hak istimewa superuser (root), atau ID pengguna lainnya kepada aplikasi lain.
[C-0-7] Jika file
.apk
runtime alternatif disertakan dalam image sistem implementasi perangkat, file tersebut HARUS ditandatangani dengan kunci yang berbeda dari kunci yang digunakan untuk menandatangani aplikasi lain yang disertakan dengan implementasi perangkat.[C-0-8] Saat menginstal aplikasi, runtime alternatif HARUS mendapatkan izin pengguna untuk izin Android yang digunakan oleh aplikasi.
[C-0-9] Jika aplikasi perlu menggunakan resource perangkat yang memiliki izin Android yang sesuai (seperti Kamera, GPS, dll.), runtime alternatif HARUS memberi tahu pengguna bahwa aplikasi akan dapat mengakses resource tersebut.
[C-0-10] Jika lingkungan runtime tidak mencatat kemampuan aplikasi dengan cara ini, lingkungan runtime HARUS mencantumkan semua izin yang dimiliki oleh runtime itu sendiri saat menginstal aplikasi apa pun menggunakan runtime tersebut.
Runtime alternatif HARUS menginstal aplikasi melalui
PackageManager
ke dalam sandbox Android terpisah (ID pengguna Linux, dll.).Runtime alternatif DAPAT menyediakan satu sandbox Android yang digunakan bersama oleh semua aplikasi yang menggunakan runtime alternatif.
9.5. Dukungan Multi-Pengguna
Android menyertakan dukungan untuk beberapa pengguna
dan memberikan dukungan untuk isolasi pengguna penuh dan meng-clone profil pengguna dengan
isolasi parsial(yaitu satu profil pengguna tambahan dari jenis
android.os.usertype.profile.CLONE
).
- Implementasi perangkat DAPAT tetapi TIDAK BOLEH mengaktifkan multi-pengguna jika menggunakan media yang dapat dilepas untuk penyimpanan eksternal utama.
Jika implementasi perangkat menyertakan dukungan untuk beberapa pengguna, implementasi tersebut:
- [C-1-2] HARUS, untuk setiap pengguna, menerapkan model keamanan yang konsisten dengan model keamanan platform Android seperti yang ditentukan dalam Dokumen referensi Keamanan dan Izin di API.
- [C-1-3] HARUS memiliki direktori penyimpanan aplikasi bersama (alias
/sdcard
) yang terpisah dan terisolasi untuk setiap instance pengguna. - [C-1-4] HARUS memastikan bahwa aplikasi yang dimiliki dan berjalan atas nama pengguna tertentu tidak dapat mencantumkan, membaca, atau menulis ke file yang dimiliki oleh pengguna lain, meskipun data kedua pengguna disimpan di volume atau sistem file yang sama.
- [C-1-5] HARUS mengenkripsi konten kartu SD saat multi-pengguna diaktifkan menggunakan kunci yang hanya disimpan di media yang tidak dapat dilepas dan hanya dapat diakses oleh sistem jika implementasi perangkat menggunakan media yang dapat dilepas untuk API penyimpanan eksternal. Karena hal ini akan membuat media tidak dapat dibaca oleh PC host, implementasi perangkat akan diwajibkan untuk beralih ke MTP atau sistem serupa untuk memberi PC host akses ke data pengguna saat ini.
Jika implementasi perangkat menyertakan dukungan untuk beberapa pengguna, maka untuk semua pengguna kecuali pengguna yang dibuat secara khusus untuk menjalankan instance ganda aplikasi yang sama, mereka:
- [C-2-1] HARUS memiliki direktori penyimpanan aplikasi bersama (alias /sdcard) yang terpisah dan terisolasi untuk setiap instance pengguna.
- [C-2-2] HARUS memastikan bahwa aplikasi yang dimiliki dan berjalan atas nama pengguna tertentu tidak dapat mencantumkan, membaca, atau menulis ke file yang dimiliki oleh pengguna lain, meskipun data kedua pengguna disimpan di volume atau sistem file yang sama.
Implementasi perangkat DAPAT membuat satu profil pengguna tambahan dari jenis
android.os.usertype.profile.CLONE
terhadap pengguna utama (dan hanya terhadap
pengguna utama) untuk tujuan menjalankan instance ganda aplikasi yang sama.
Instance ganda ini berbagi penyimpanan yang terisolasi sebagian, ditampilkan kepada
pengguna akhir di peluncur secara bersamaan dan muncul di tampilan terbaru yang sama.
Misalnya, ini dapat digunakan untuk mendukung pengguna menginstal dua instance
terpisah dari satu aplikasi di perangkat dual-SIM.
Jika implementasi perangkat membuat profil pengguna tambahan yang telah dibahas di atas, profil tersebut:
- [C-3-1] HANYA BOLEH memberikan akses ke penyimpanan atau data yang sudah dapat diakses oleh profil pengguna induk atau dimiliki langsung oleh profil pengguna tambahan ini.
- [C-3-2] TIDAK BOLEH memiliki ini sebagai profil kerja.
- [C-3-3] HARUS memiliki direktori data aplikasi pribadi yang terisolasi dari akun pengguna induk.
- [C-3-4] TIDAK BOLEH mengizinkan profil pengguna tambahan dibuat jika ada Pemilik Perangkat yang disediakan (lihat bagian 3.9.1) atau mengizinkan Pemilik Perangkat disediakan tanpa menghapus profil pengguna tambahan terlebih dahulu.
Memulai persyaratan baru
Jika implementasi perangkat membuat profil pengguna tambahan yang telah dibahas di atas, profil tersebut:
- [C-4-5] HARUS secara visual membedakan ikon aplikasi instance ganda saat ikon ditampilkan kepada pengguna.
- [C-4-6] HARUS menyediakan kemampuan pengguna untuk menghapus seluruh data profil clone.
- [C-4-7] HARUS meng-uninstal semua aplikasi Clone, menghapus direktori data aplikasi pribadi dan kontennya, serta menghapus data profil Clone, saat pengguna memilih untuk menghapus seluruh data profil Clone.
- HARUS meminta pengguna untuk menghapus seluruh data Profil Clone saat aplikasi clone terakhir dihapus.
- [C-4-8] HARUS memberi tahu pengguna bahwa data aplikasi akan dihapus saat aplikasi clone di-uninstal, atau memberikan opsi kepada pengguna untuk menyimpan data aplikasi saat aplikasi di-uninstal dari perangkat.
- [C-4-9] HARUS menghapus direktori data aplikasi pribadi dan kontennya, saat pengguna memilih untuk menghapus data selama proses uninstal.
[C-4-1] HARUS mengizinkan intent di bawah yang berasal dari profil tambahan untuk ditangani oleh aplikasi pengguna utama di perangkat:
Intent.ACTION_VIEW
Intent.ACTION_SENDTO
Intent.ACTION_SEND
Intent.ACTION_EDIT
Intent.ACTION_INSERT
Intent.ACTION_INSERT_OR_EDIT
Intent.ACTION_SEND_MULTIPLE
Intent.ACTION_PICK
Intent.ACTION_GET_CONTENT
MediaStore.ACTION_IMAGE_CAPTURE
MediaStore.ACTION_VIDEO_CAPTURE
[C-4-2] HARUS mewarisi semua batasan pengguna kebijakan perangkat dan batasan non-pengguna yang dipilih(daftar di bawah) yang diterapkan pada pengguna utama perangkat ke profil pengguna tambahan ini.
[C-4-3] HANYA BOLEH mengizinkan penulisan kontak dari profil tambahan ini melalui intent berikut:
[C-4-4] TIDAK BOLEH memiliki sinkronisasi kontak yang berjalan untuk aplikasi yang berjalan di profil pengguna tambahan ini.
- [C-4-14] HARUS memiliki izin dan pengelolaan penyimpanan terpisah untuk aplikasi yang berjalan di profil tambahan ini
- [C-4-5] HARUS hanya mengizinkan aplikasi di profil tambahan yang memiliki aktivitas peluncur untuk mengakses kontak yang sudah dapat diakses oleh profil pengguna induk.
Akhiri persyaratan baru
9.6. Peringatan SMS Premium
Android menyertakan dukungan untuk memperingatkan pengguna tentang pesan SMS premium keluar. Pesan SMS Premium adalah pesan teks yang dikirim ke layanan yang terdaftar dengan operator yang dapat mengakibatkan tagihan kepada pengguna.
Jika implementasi perangkat mendeklarasikan dukungan untuk android.hardware.telephony
,
implementasi tersebut:
- [C-1-1] HARUS memperingatkan pengguna sebelum mengirim pesan SMS ke nomor
yang diidentifikasi oleh ekspresi reguler yang ditentukan dalam file
/data/misc/sms/codes.xml
di perangkat. Project Open Source Android upstream menyediakan penerapan yang memenuhi persyaratan ini.
9.7. Fitur Keamanan
Implementasi perangkat HARUS memastikan kepatuhan terhadap fitur keamanan di kernel dan platform seperti yang dijelaskan di bawah.
Sandbox Android menyertakan fitur yang menggunakan sistem kontrol akses wajib (MAC) Security-Enhanced Linux (SELinux), sandbox seccomp, dan fitur keamanan lainnya di kernel Linux. Implementasi perangkat:
- [C-0-1] HARUS mempertahankan kompatibilitas dengan aplikasi yang ada, meskipun SELinux atau fitur keamanan lainnya diterapkan di bawah framework Android.
- [C-0-2] TIDAK BOLEH memiliki antarmuka pengguna yang terlihat saat pelanggaran keamanan terdeteksi dan berhasil diblokir oleh fitur keamanan yang diterapkan di bawah framework Android, tetapi DAPAT memiliki antarmuka pengguna yang terlihat saat pelanggaran keamanan yang tidak diblokir terjadi sehingga mengakibatkan eksploitasi yang berhasil.
- [C-0-3] TIDAK BOLEH membuat SELinux atau fitur keamanan lainnya yang diterapkan di bawah framework Android dapat dikonfigurasi oleh pengguna atau developer aplikasi.
- [C-0-4] TIDAK BOLEH mengizinkan aplikasi yang dapat memengaruhi aplikasi lain melalui API (seperti Device Administration API) untuk mengonfigurasi kebijakan yang merusak kompatibilitas.
- [C-0-5] HARUS membagi framework media menjadi beberapa proses sehingga akses untuk setiap proses dapat diberikan secara lebih terbatas seperti dijelaskan di situs Android Open Source Project.
- [C-0-6] HARUS menerapkan mekanisme sandboxing aplikasi kernel yang memungkinkan pemfilteran panggilan sistem menggunakan kebijakan yang dapat dikonfigurasi dari program multi-thread. Project Open Source Android upstream memenuhi persyaratan ini dengan mengaktifkan seccomp-BPF dengan sinkronisasi threadgroup (TSYNC) seperti yang dijelaskan di bagian Konfigurasi Kernel di source.android.com.
Integritas kernel dan fitur perlindungan mandiri merupakan bagian integral dari keamanan Android. Implementasi perangkat:
- [C-0-7] HARUS menerapkan mekanisme perlindungan buffer overflow stack kernel.
Contoh mekanisme tersebut adalah
CC_STACKPROTECTOR_REGULAR
danCONFIG_CC_STACKPROTECTOR_STRONG
. - [C-0-8] HARUS menerapkan perlindungan memori kernel yang ketat dengan kode
yang dapat dieksekusi hanya-baca, data hanya-baca tidak dapat dieksekusi dan tidak dapat ditulis, dan
data yang dapat ditulis tidak dapat dieksekusi (misalnya
CONFIG_DEBUG_RODATA
atauCONFIG_STRICT_KERNEL_RWX
). - [C-0-9] HARUS menerapkan pemeriksaan batas ukuran objek statis dan dinamis
dari salinan antara ruang pengguna dan ruang kernel
(misalnya,
CONFIG_HARDENED_USERCOPY
) di perangkat yang awalnya dikirimkan dengan API level 28 atau yang lebih tinggi. - [C-0-10] TIDAK BOLEH mengeksekusi memori ruang pengguna saat dieksekusi
dalam mode kernel (misalnya, PXN hardware, atau diemulasi melalui
CONFIG_CPU_SW_DOMAIN_PAN
atauCONFIG_ARM64_SW_TTBR0_PAN
) di perangkat yang awalnya dikirimkan dengan API level 28 atau yang lebih tinggi. - [C-0-11] TIDAK BOLEH membaca atau menulis memori ruang pengguna di
kernel di luar API akses usercopy normal (misalnya PAN hardware, atau
diemulasikan melalui
CONFIG_CPU_SW_DOMAIN_PAN
atauCONFIG_ARM64_SW_TTBR0_PAN
) di perangkat yang awalnya dikirimkan dengan API level 28 atau yang lebih tinggi. - [C-0-12] HARUS menerapkan isolasi tabel halaman kernel jika hardware
rentan terhadap CVE-2017-5754 di semua perangkat yang awalnya dikirimkan dengan API level
28 atau yang lebih tinggi (misalnya,
CONFIG_PAGE_TABLE_ISOLATION
atauCONFIG_UNMAP_KERNEL_AT_EL0
). [C-0-13] HARUS menerapkan hardening prediksi cabang jika hardware rentan terhadap CVE-2017-5715 di semua perangkat yang awalnya dikirimkan dengan API level 28 atau yang lebih tinggi (misalnya,
CONFIG_HARDEN_BRANCH_PREDICTOR
).[C-SR-1] SANGAT DISARANKAN untuk menyimpan data kernel yang hanya ditulis selama inisialisasi yang ditandai hanya baca setelah inisialisasi (misalnya,
__ro_after_init
).[C-SR-2] SANGAT DIUJAMI untuk melakukan randomisasi tata letak kode kernel dan memori, serta untuk menghindari eksposur yang akan membahayakan randomisasi (misalnya,
CONFIG_RANDOMIZE_BASE
dengan entropi bootloader melalui/chosen/kaslr-seed Device Tree node
atauEFI_RNG_PROTOCOL
).[C-SR-3] SANGAT DISARANKAN untuk mengaktifkan control flow integrity (CFI) di kernel untuk memberikan perlindungan tambahan terhadap serangan penggunaan kembali kode (misalnya,
CONFIG_CFI_CLANG
danCONFIG_SHADOW_CALL_STACK
).[C-SR-4] SANGAT DISARANKAN untuk tidak menonaktifkan Control-Flow Integrity (CFI), Shadow Call Stack (SCS), atau Integer Overflow Sanitization (IntSan) pada komponen yang mengaktifkannya.
[C-SR-5] SANGAT DIUJAMI untuk mengaktifkan CFI, SCS, dan IntSan untuk komponen ruang pengguna sensitif keamanan tambahan seperti yang dijelaskan dalam CFI dan IntSan.
[C-SR-6] SANGAT DISARANKAN untuk mengaktifkan inisialisasi stack di kernel untuk mencegah penggunaan variabel lokal yang tidak diinisialisasi (
CONFIG_INIT_STACK_ALL
atauCONFIG_INIT_STACK_ALL_ZERO
). Selain itu, implementasi perangkat TIDAK BOLEH mengasumsikan nilai yang digunakan oleh compiler untuk melakukan inisialisasi lokal.[C-SR-7] SANGAT DISARANKAN untuk mengaktifkan inisialisasi heap di kernel untuk mencegah penggunaan alokasi heap yang tidak diinisialisasi (
CONFIG_INIT_ON_ALLOC_DEFAULT_ON
) dan TIDAK BOLEH mengasumsikan nilai yang digunakan oleh kernel untuk menginisialisasi alokasi tersebut.
Jika implementasi perangkat menggunakan kernel Linux yang mampu mendukung SELinux, implementasi tersebut:
- [C-1-1] HARUS menerapkan SELinux.
- [C-1-2] HARUS menetapkan SELinux ke mode penerapan global.
- [C-1-3] HARUS mengonfigurasi semua domain dalam mode penerapan. Tidak ada domain mode permisif yang diizinkan, termasuk domain khusus untuk perangkat/vendor.
- [C-1-4] TIDAK BOLEH mengubah, menghapus, atau mengganti aturan neverallow yang ada dalam folder system/sepolicy yang disediakan di Project Open Source Android upstream (AOSP) dan kebijakan HARUS dikompilasi dengan semua aturan neverallow yang ada, baik untuk domain SELinux AOSP maupun domain khusus perangkat/vendor.
- [C-1-5] HARUS menjalankan aplikasi pihak ketiga yang menargetkan API level 28 atau yang lebih tinggi di sandbox SELinux per aplikasi dengan pembatasan SELinux per aplikasi pada setiap direktori data pribadi aplikasi.
- HARUS mempertahankan kebijakan SELinux default yang disediakan di folder system/sepolicy dari Project Open Source Android upstream dan hanya menambahkan lebih lanjut ke kebijakan ini untuk konfigurasi khusus perangkat mereka sendiri.
Jika implementasi perangkat menggunakan kernel selain Linux atau Linux tanpa SELinux, perangkat tersebut:
- [C-2-1] HARUS menggunakan sistem kontrol akses wajib yang setara dengan SELinux.
Jika implementasi perangkat menggunakan perangkat I/O yang mampu melakukan DMA, perangkat tersebut:
- [C-SR-9] SANGAT DISARANKAN untuk mengisolasi setiap perangkat I/O yang mampu melakukan DMA, menggunakan IOMMU (misalnya ARM SMMU).
Android berisi beberapa fitur pertahanan mendalam yang merupakan bagian integral dari keamanan perangkat. Selain itu, Android berfokus untuk mengurangi class utama bug umum yang berkontribusi pada kualitas dan keamanan yang buruk.
Untuk mengurangi bug memori, implementasi perangkat:
- [C-SR-10] SANGAT DISARANKAN untuk diuji menggunakan alat deteksi error memori ruang pengguna seperti MTE untuk perangkat ARMv9, HWASan untuk perangkat ARMv8+, atau ASan untuk jenis perangkat lainnya.
- [C-SR-11] SANGAT DISARANKAN untuk diuji menggunakan alat deteksi error memori kernel seperti KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS untuk perangkat ARMv9, CONFIG_KASAN_SW_TAGS untuk perangkat ARMv8, atau CONFIG_KASAN_GENERIC untuk jenis perangkat lainnya).
- [C-SR-12] SANGAT DISARANKAN untuk menggunakan alat deteksi error memori dalam produksi seperti MTE, GWP-ASan, dan KFENCE.
Jika implementasi perangkat menggunakan TEE berbasis Arm TrustZone, implementasi tersebut:
- [C-SR-13] SANGAT DISARANKAN untuk menggunakan protokol standar untuk berbagi memori, antara Android dan TEE, seperti Arm Firmware Framework untuk Armv8-A (FF-A).
- [C-SR-14] SANGAT DISARANKAN untuk membatasi aplikasi tepercaya agar hanya mengakses memori yang telah dibagikan secara eksplisit kepada mereka melalui protokol di atas. Jika perangkat memiliki dukungan untuk level pengecualian Arm S-EL2, hal ini harus diterapkan oleh pengelola partisi aman. Jika tidak, hal ini harus diberlakukan oleh OS TEE.
Memulai persyaratan baru
Teknologi Keamanan Memori adalah teknologi yang memitigasi setidaknya class bug
berikut dengan probabilitas tinggi (> 90%) dalam aplikasi yang menggunakan
opsi manifes
android:memtagMode
:
- overflow buffer heap
- use after free
- double free
- wild free (bebas dari pointer non-malloc)
Implementasi perangkat:
- [C-SR-15] SANGAT DISARANKAN untuk menetapkan
ro.arm64.memtag.bootctl_supported
.
Jika implementasi perangkat menetapkan properti sistem
ro.arm64.memtag.bootctl_supported
ke benar (true), implementasi tersebut:
[C-3-1] HARUS mengizinkan properti sistem
arm64.memtag.bootctl
untuk menerima daftar nilai berikut yang dipisahkan koma, dengan efek yang diinginkan diterapkan pada mulai ulang berikutnya:memtag
: teknologi Memory Safety seperti yang ditentukan di atas diaktifkanmemtag-once
: teknologi Keamanan Memori seperti yang ditentukan di atas diaktifkan secara sementara, dan otomatis dinonaktifkan setelah reboot berikutnyamemtag-off
: teknologi Keamanan Memori seperti yang ditentukan di atas dinonaktifkan
[C-3-2] HARUS mengizinkan pengguna shell menetapkan
arm64.memtag.bootctl
.[C-3-3] HARUS mengizinkan proses apa pun untuk membaca
arm64.memtag.bootctl
.[C-3-4] HARUS menetapkan
arm64.memtag.bootctl
ke status yang saat ini diminta saat booting, juga HARUS memperbarui properti, jika implementasi perangkat memungkinkan untuk mengubah status tanpa mengubah properti sistem.[C-SR-16] SANGAT DIUJAMI untuk menampilkan Setelan Developer yang menetapkan memtag-once dan memulai ulang perangkat. Dengan bootloader yang kompatibel, Proyek Open Source Android memenuhi persyaratan di atas melalui protokol bootloader MTE.
- [C-SR-17] SANGAT DISARANKAN untuk menampilkan Setelan di menu Setelan
Keamanan yang memungkinkan pengguna mengaktifkan
memtag
.
Akhiri persyaratan baru
9.8. Privasi
9.8.1. Histori Penggunaan
Android menyimpan histori pilihan pengguna dan mengelola histori tersebut dengan UsageStatsManager.
Implementasi perangkat:
- [C-0-1] HARUS mempertahankan periode retensi yang wajar untuk histori pengguna tersebut.
- [C-SR-1] SANGAT DISARANKAN untuk mempertahankan periode retensi 14 hari seperti yang dikonfigurasi secara default dalam penerapan AOSP.
Android menyimpan peristiwa sistem menggunakan ID
StatsLog
, dan mengelola histori tersebut melalui StatsManager
dan
IncidentManager
System API.
Implementasi perangkat:
- [C-0-2] HANYA boleh menyertakan kolom yang ditandai dengan
DEST_AUTOMATIC
dalam laporan insiden yang dibuat oleh class System APIIncidentManager
. - [C-0-3] TIDAK BOLEH menggunakan ID peristiwa sistem untuk mencatat peristiwa lain selain yang dijelaskan dalam dokumen SDK
StatsLog
. Jika peristiwa sistem tambahan dicatat ke dalam log, peristiwa tersebut DAPAT menggunakan ID atom yang berbeda dalam rentang antara 100.000 dan 200.000.
9.8.2. Merekam
Implementasi perangkat:
- [C-0-1] TIDAK BOLEH memuat ulang atau mendistribusikan komponen software bawaan yang mengirim informasi pribadi pengguna (misalnya, penekanan tombol, teks yang ditampilkan di layar, bugreport) dari perangkat tanpa izin pengguna atau menghapus notifikasi yang sedang berlangsung.
- [C-0-2] HARUS menampilkan peringatan pengguna dan mendapatkan izin pengguna eksplisit yang memungkinkan informasi sensitif apa pun yang ditampilkan di layar pengguna untuk direkam
yang diaktifkan yang menyertakan pesan yang sama seperti AOSPsetiap kalisetiap kali sesi untuk merekam transmisi layaratau perekaman layardiaktifkandimulai melaluiMediaProjection.createVirtualDisplay()
,VirtualDeviceManager.createVirtualDisplay()
, atau API eksklusif.TIDAK BOLEH memberikan affordance kepada pengguna untuk menonaktifkan tampilan izin pengguna di masa mendatang. - [C-0-3] HARUS memiliki notifikasi yang sedang berlangsung kepada pengguna saat transmisi layar atau perekaman layar diaktifkan. AOSP memenuhi persyaratan ini dengan menampilkan ikon notifikasi yang sedang berlangsung di status bar.
Memulai persyaratan baru
[C-SR-1] SANGAT DISARANKAN untuk menampilkan peringatan pengguna yang sama persis dengan pesan yang diterapkan di AOSP, tetapi DAPAT diubah selama pesan tersebut dengan jelas memperingatkan pengguna bahwa informasi sensitif apa pun di layar pengguna akan diambil.
[C-0-4] TIDAK BOLEH memberikan kemampuan kepada pengguna untuk menonaktifkan permintaan izin pengguna untuk mengambil screenshot di masa mendatang, kecuali jika sesi dimulai oleh aplikasi sistem yang telah diizinkan pengguna untuk
associate()
denganandroid.app.role.COMPANION_DEVICE_APP_STREAMING
atauandroid.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING
profil perangkat.Akhiri persyaratan baru
Jika implementasi perangkat menyertakan fungsi dalam sistem yang
mengambil konten yang ditampilkan di layar dan/atau merekam streaming audio
yang diputar di perangkat selain melalui ContentCaptureService
System API, atau
cara eksklusif lainnya yang dijelaskan dalam
Bagian 9.8.6 Data tingkat OS dan data standby, implementasi tersebut:
- [C-1-1] HARUS memiliki notifikasi berkelanjutan kepada pengguna setiap kali fungsi ini diaktifkan dan secara aktif mengambil/merekam.
Jika implementasi perangkat menyertakan komponen yang diaktifkan secara default, yang mampu merekam audio sekitar dan/atau merekam audio yang diputar di perangkat untuk menyimpulkan informasi yang berguna tentang konteks pengguna, perangkat tersebut:
- [C-2-1] TIDAK BOLEH menyimpan di penyimpanan persisten di perangkat atau mengirimkan dari perangkat audio mentah yang direkam atau format apa pun yang dapat dikonversi kembali menjadi audio asli atau hampir sama, kecuali dengan izin pengguna yang eksplisit.
“Indikator mikrofon” mengacu pada tampilan di layar, yang terus terlihat oleh pengguna dan tidak dapat dikaburkan, yang dipahami pengguna sebagai mikrofon sedang digunakan(melalui teks, warna, ikon, atau beberapa kombinasi yang unik).
“Indikator kamera” mengacu pada tampilan di layar, yang terus terlihat oleh pengguna dan tidak dapat dikaburkan, yang dipahami pengguna sebagai kamera sedang digunakan (melalui teks, warna, ikon, atau beberapa kombinasi unik).
Setelah satu detik pertama ditampilkan, indikator dapat berubah secara visual, seperti menjadi lebih kecil, dan tidak diwajibkan untuk ditampilkan seperti yang awalnya ditampilkan dan dipahami.
Indikator mikrofon dapat digabungkan dengan indikator kamera yang ditampilkan secara aktif, asalkan teks, ikon, atau warna menunjukkan kepada pengguna bahwa penggunaan mikrofon telah dimulai.
Indikator kamera dapat digabungkan dengan indikator mikrofon yang ditampilkan secara aktif, asalkan teks, ikon, atau warna menunjukkan kepada pengguna bahwa penggunaan kamera telah dimulai.
Jika implementasi perangkat mendeklarasikan android.hardware.microphone
, implementasi tersebut:
- [C-SR-1] SANGAT DISARANKAN untuk menampilkan indikator mikrofon saat aplikasi
mengakses data audio dari mikrofon, tetapi tidak jika mikrofon
hanya diakses oleh
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
, atau aplikasi yang memiliki peran yang disebutkan di Bagian 9.1 Izin dengan ID CDD [C-3-X]. . - [C-SR-2] SANGAT DISARANKAN untuk menampilkan daftar aplikasi Terbaru dan Aktif
menggunakan mikrofon seperti yang ditampilkan dari
PermissionManager.getIndicatorAppOpUsageData()
, beserta pesan atribusi apa pun yang terkait dengannya. - [C-SR-3] SANGAT DISARANKAN untuk tidak menyembunyikan indikator mikrofon untuk aplikasi sistem yang memiliki antarmuka pengguna yang terlihat atau interaksi pengguna langsung.
Jika implementasi perangkat mendeklarasikan android.hardware.camera.any
, implementasi tersebut:
- [C-SR-4] SANGAT DISARANKAN untuk menampilkan indikator kamera saat aplikasi mengakses data kamera langsung, tetapi tidak saat kamera hanya diakses oleh aplikasi yang memiliki peran yang disebutkan di Bagian 9.1 Izin dengan ID CDD [C-3-X].
- [C-SR-5] SANGAT DISARANKAN untuk menampilkan aplikasi Terbaru dan Aktif menggunakan
kamera seperti yang ditampilkan dari
PermissionManager.getIndicatorAppOpUsageData()
, beserta pesan atribusi apa pun yang terkait dengannya. - [C-SR-6] SANGAT DISARANKAN untuk tidak menyembunyikan indikator kamera untuk aplikasi sistem yang memiliki antarmuka pengguna yang terlihat atau interaksi pengguna langsung.
9.8.3. Konektivitas
Jika implementasi perangkat memiliki port USB dengan dukungan mode periferal USB, perangkat tersebut:
- [C-1-1] HARUS menampilkan antarmuka pengguna yang meminta izin pengguna sebelum mengizinkan akses ke konten penyimpanan bersama melalui port USB.
9.8.4. Traffic Jaringan
Implementasi perangkat:
- [C-0-1] HARUS menginstal sebelumnya root certificate yang sama untuk penyimpanan Certificate Authority (CA) tepercaya sistem seperti yang disediakan di Project Open Source Android upstream.
- [C-0-2] HARUS dikirimkan dengan penyimpanan root CA pengguna yang kosong.
- [C-0-3] HARUS menampilkan peringatan kepada pengguna yang menunjukkan bahwa traffic jaringan dapat dipantau, saat CA root pengguna ditambahkan.
Jika traffic perangkat dialihkan melalui VPN, implementasi perangkat:
- [C-1-1] HARUS menampilkan peringatan kepada pengguna yang menunjukkan:
- Traffic jaringan tersebut dapat dipantau.
- Traffic jaringan tersebut dirutekan melalui aplikasi VPN tertentu yang menyediakan VPN.
Jika implementasi perangkat memiliki mekanisme, yang diaktifkan secara default, yang
me-route traffic data jaringan melalui server proxy atau gateway VPN (misalnya,
memuat layanan VPN secara otomatis dengan android.permission.CONTROL_VPN
yang diberikan), mekanisme tersebut:
- [C-2-1] HARUS meminta izin pengguna sebelum mengaktifkan mekanisme tersebut,
kecuali jika VPN tersebut diaktifkan oleh Pengontrol Kebijakan Perangkat melalui
DevicePolicyManager.setAlwaysOnVpnPackage()
. Dalam hal ini, pengguna tidak perlu memberikan izin terpisah, tetapi HARUS diberi tahu.
Jika implementasi perangkat menerapkan kemampuan pengguna untuk mengaktifkan fungsi "VPN yang selalu aktif" dari aplikasi VPN pihak ketiga, implementasi tersebut:
- [C-3-1] HARUS menonaktifkan kemampuan pengguna ini untuk aplikasi yang tidak mendukung
layanan VPN yang selalu aktif dalam file
AndroidManifest.xml
melalui penetapan atributSERVICE_META_DATA_SUPPORTS_ALWAYS_ON
kefalse
.
9.8.5. ID Perangkat
Implementasi perangkat:
- [C-0-1] HARUS mencegah akses ke nomor seri perangkat dan, jika
berlaku, IMEI/MEID, nomor seri SIM, dan International Mobile
Subscriber Identity (IMSI) dari aplikasi, kecuali jika memenuhi salah satu persyaratan
berikut:
- adalah aplikasi operator yang ditandatangani dan diverifikasi oleh produsen perangkat.
- telah diberi izin
READ_PRIVILEGED_PHONE_STATE
. - memiliki hak istimewa operator sebagaimana ditentukan dalam Hak Istimewa Operator UICC.
- adalah pemilik perangkat atau pemilik profil yang telah diberi
izin
READ_PHONE_STATE
. - (Khusus nomor seri SIM/ICCID) memiliki persyaratan peraturan setempat agar aplikasi mendeteksi perubahan identitas pelanggan.
9.8.6. Perekaman Konten dan Penelusuran AplikasiData tingkat OS dan standby
Android, melalui System API , mendukung mekanisme untuk
implementasi perangkat guna menangkap ContentCaptureService
,
AugmentedAutofillService
, AppSearchGlobalManager.query
, atau dengan cara
eksklusif lainnyainteraksi data aplikasi antara aplikasi dan
pengguna
data sensitif berikut:
- Teks dan grafik yang dirender di layar, termasuk, tetapi tidak terbatas pada,
notifikasi dan data bantuan melalui
AssistStructure
API. - Data media, seperti audio atau video, yang direkam atau diputar oleh perangkat.
- Peristiwa input (misalnya tombol, mouse, gestur, suara, video, dan aksesibilitas).
Memulai persyaratan baru
- Layar atau data lainnya yang dikirim melalui
AugmentedAutofillService
ke sistem. - Layar atau data lainnya yang dapat diakses melalui
Content Capture
API. - Layar atau data lain apa pun yang dapat diakses melalui
FieldClassificationService
API - Semua data aplikasi yang diteruskan ke sistem melalui
AppSearchManager
API dan dapat diakses melaluiAppSearchGlobalManager.query
.
Akhiri persyaratan baru
- Peristiwa lain yang disediakan aplikasi ke sistem melalui
Content Capture
API atauAppSearchManager
API, Android yang mampu dan API eksklusif yang serupa.
- Teks atau data lain yang dikirim melalui
TextClassifier API
ke System TextClassifier, yaitu ke layanan sistem untuk memahami arti teks, serta menghasilkan prediksi tindakan berikutnya berdasarkan teks. - Data yang diindeks oleh penerapan AppSearch platform, termasuk, tetapi tidak terbatas pada teks, grafik, data media, atau data serupa lainnya.
Memulai persyaratan baru
- Data audio yang diperoleh sebagai hasil dari penggunaan
SpeechRecognizer#onDeviceSpeechRecognizer()
oleh Penerapan Pengenal Ucapan. - Data audio yang diperoleh di latar belakang (secara terus-menerus) melalui
AudioRecord
,SoundTrigger
, atau Audio API lainnya, dan tidak menghasilkan indikator yang terlihat pengguna - Data kamera diperoleh di latar belakang (secara terus-menerus) melalui CameraManager atau Camera API lainnya, dan tidak menghasilkan indikator yang terlihat pengguna
Akhiri persyaratan baru
Jika implementasi perangkat merekam salah satu data di atas, data tersebut:
- [C-1-1] HARUS mengenkripsi semua data tersebut saat disimpan di perangkat. Enkripsi ini DAPAT dilakukan menggunakan Enkripsi Berbasis File Android, atau cipher apa pun yang tercantum sebagai API versi 26+ yang dijelaskan dalam Cipher SDK.
- [C-1-2] TIDAK BOLEH mencadangkan data mentah atau terenkripsi menggunakan metode pencadangan Android atau metode pencadangan lainnya.
- [C-1-3] HANYA BOLEH mengirim semua data tersebut
dan logdari perangkat menggunakan mekanisme perlindungan privasi, kecuali dengan izin pengguna yang eksplisit setiap kali data dibagikan. Mekanisme perlindungan privasi didefinisikan sebagai “mekanisme yang hanya mengizinkan analisis secara gabungan dan mencegah pencocokan peristiwa yang dicatat dalam log atau hasil turunan ke setiap pengguna”, untuk mencegah data per pengguna dapat di-introspeksi (misalnya, diterapkan menggunakan teknologi privasi diferensial sepertiRAPPOR
). - [C-1-4] TIDAK BOLEH mengaitkan data tersebut dengan identitas pengguna apa pun (seperti
Account
) di perangkat, kecuali dengan izin eksplisit pengguna setiap kali data dikaitkan. - [C-1-5] TIDAK BOLEH membagikan data tersebut kepada komponen OS lain yang tidak
mengikuti persyaratan yang diuraikan di bagian saat ini
(9.8.6
Pengambilan KontenData tingkat OS dan data standby), kecuali dengan izin eksplisit pengguna setiap kali data tersebut dibagikan. Kecuali jika fungsi tersebut di-build sebagai Android SDK API (AmbientContext
,HotwordDetectionService
). - [C-1-6] HARUS memberikan kemampuan pengguna untuk menghapus data tersebut yang
diimplementasikan oleh
atau cara eksklusif mengumpulkanContentCaptureService
jikasaat data disimpan dalam bentuk apa pun di perangkat. Jika pengguna memilih untuk menghapus data, HARUS menghapus semua data historis yang dikumpulkan. - [C-1-7] HARUS memberikan kemampuan pengguna untuk memilih tidak ikut menampilkan data, yang dikumpulkan melalui AppSearch atau cara eksklusif agar tidak ditampilkan di platform Android misalnya peluncur.
- [C-SR-1] SANGAT DISARANKAN untuk TIDAK meminta izin INTERNET.
- [C-SR-2] SANGAT DISARANKAN untuk hanya mengakses internet melalui API terstruktur yang didukung oleh implementasi open source yang tersedia secara publik.
Memulai persyaratan baru
- [C-SR-4] SANGAT DISARANKAN untuk diterapkan dengan Android SDK API atau repositori open source milik OEM serupa; dan / atau dilakukan dalam penerapan dengan Sandbox (lihat 9.8.15 Penerapan API dengan Sandbox).
Akhiri persyaratan baru
Jika implementasi perangkat menyertakan layanan yang mengimplementasikan System API
ContentCaptureService
, AppSearchManager.index
, atau layanan eksklusif
apa pun yang mengambil data seperti yang dijelaskan di atas, layanan tersebut:
- [C-2-1] TIDAK BOLEH mengizinkan pengguna mengganti layanan dengan aplikasi atau layanan yang dapat diinstal pengguna dan HANYA BOLEH mengizinkan layanan yang telah diinstal sebelumnya untuk mengambil data tersebut.
- [C-2-2] TIDAK BOLEH mengizinkan aplikasi apa pun selain mekanisme layanan bawaan agar dapat mengambil data tersebut.
- [C-2-3] HARUS memberikan kemampuan pengguna untuk menonaktifkan layanan.
- [C-2-4] TIDAK BOLEH menghilangkan kemampuan pengguna untuk mengelola izin Android yang dimiliki oleh layanan dan mengikuti model izin Android seperti yang dijelaskan dalam Bagian 9.1. Izin.
[C-SR-3] SANGAT DISARANKAN untuk memisahkan layanan dari komponen sistem lainnya(misalnya, tidak mengikat layanan atau membagikan ID proses) kecuali untuk hal berikut:
- Telepon, Kontak, UI Sistem, dan Media
Android, melalui SpeechRecognizer#onDeviceSpeechRecognizer()
, memberikan kemampuan
untuk melakukan pengenalan ucapan di perangkat, tanpa melibatkan jaringan.
Setiap penerapan SpeechRecognizer di perangkat HARUS mengikuti kebijakan
yang diuraikan di bagian ini.
9.8.7. Akses Papan Klip
Implementasi perangkat:
[C-0-1] TIDAK BOLEH menampilkan data yang dipangkas dari papan klip (misalnya melalui
ClipboardManager
API) kecuali jika aplikasi pihak ketiga adalah IME default atau aplikasi yang saat ini memiliki fokus.[C-0-2] HARUS menghapus data papan klip paling lama 60 menit setelah terakhir kali ditempatkan di papan klip atau dibaca dari papan klip.
9.8.8. Lokasi
Lokasi mencakup informasi di class Lokasi Android( seperti Lintang, Bujur, Ketinggian), serta ID yang dapat dikonversi ke Lokasi. Lokasi dapat sedetail DGPS (Differential Global Positioning System) atau setebal lokasi tingkat negara (seperti lokasi kode negara - MCC - Mobile Country Code).
Berikut adalah daftar jenis lokasi yang secara langsung memperoleh lokasi pengguna atau dapat dikonversi ke lokasi pengguna. Ini bukan daftar lengkap, tetapi harus digunakan sebagai contoh tentang apa yang dapat diperoleh Lokasi secara langsung atau tidak langsung dari:
- GPS/GNSS/DGPS/PPP
- Solusi Pemosisi Global atau Sistem Satelit Navigasi Global atau Solusi Pemosisi Global Diferensial
- Hal ini juga mencakup Pengukuran GNSS Mentah dan Status GNSS
- Lokasi yang Tepat dapat berasal dari Pengukuran GNSS Mentah
- Teknologi Nirkabel dengan ID unik seperti:
- Titik akses Wi-Fi (MAC, BSSID, Nama, atau SSID)
- Bluetooth/BLE (MAC, BSSID, Nama, atau SSID)
- UWB (MAC, BSSID, Nama, atau SSID)
- ID Menara Seluler (3G, 4G, 5G… Termasuk semua teknologi Modem Seluler mendatang yang memiliki ID unik)
Sebagai titik referensi utama, lihat Android API yang memerlukan izin ACCESS_FINE_Location atau ACCESS_COARSE_Location.
Implementasi perangkat:
- [C-0-1] TIDAK BOLEH mengaktifkan/menonaktifkan setelan lokasi perangkat dan setelan pemindaian Wi-Fi/Bluetooth tanpa persetujuan pengguna yang eksplisit atau inisiatif pengguna.
- [C-0-2] HARUS memberikan kemampuan kepada pengguna untuk mengakses informasi terkait lokasi, termasuk permintaan lokasi terbaru, izin tingkat aplikasi, dan penggunaan pemindaian Wi-Fi/Bluetooth untuk menentukan lokasi.
- [C-0-3] HARUS memastikan bahwa aplikasi yang menggunakan Emergency Location Bypass API [LocationRequest.setLocationSettingsIgnored()] adalah sesi darurat yang dimulai pengguna (misalnya, menelepon 911 atau mengirim SMS ke 911). Namun, untuk Otomotif, kendaraan DAPAT memulai sesi darurat tanpa interaksi pengguna aktif jika tabrakan/kecelakaan terdeteksi (misalnya, untuk memenuhi persyaratan eCall).
- [C-0-4] HARUS mempertahankan kemampuan Emergency Location Bypass API untuk mengabaikan setelan lokasi perangkat tanpa mengubah setelan.
- [C-0-5] HARUS menjadwalkan notifikasi yang mengingatkan pengguna setelah aplikasi di
latar belakang mengakses lokasi mereka menggunakan
izin [
ACCESS_BACKGROUND_LOCATION
].
9.8.9. Aplikasi terinstal
Aplikasi Android yang menargetkan API level 30 atau yang lebih tinggi tidak dapat melihat detail tentang aplikasi lain yang diinstal secara default (lihat Visibilitas paket dalam dokumentasi Android SDK).
Implementasi perangkat:
- [C-0-1] TIDAK BOLEH mengekspos detail tentang aplikasi lain yang diinstal ke aplikasi apa pun yang menargetkan API level 30 atau yang lebih tinggi, kecuali jika aplikasi sudah dapat melihat detail tentang aplikasi lain yang diinstal melalui API terkelola. Hal ini mencakup, tetapi tidak terbatas pada detail yang diekspos oleh API kustom apa pun yang ditambahkan oleh penerapkan perangkat, atau dapat diakses melalui sistem file.
- [C-0-2] TIDAK BOLEH memberikan akses baca atau tulis ke file dalam direktori khusus aplikasi
milik aplikasi lain
dalam penyimpanan eksternal kepada aplikasi apa pun. Satu-satunya pengecualian adalah sebagai berikut:
- Otoritas penyedia penyimpanan eksternal (misalnya, aplikasi seperti DocumentsUI).
- Download Provider yang menggunakan otorisasi penyedia “download” untuk mendownload file ke penyimpanan aplikasi.
- Aplikasi media transfer protocol (MTP) yang ditandatangani platform yang menggunakan izin istimewa ACCESS_MTP untuk memungkinkan transfer file ke perangkat lain.
- Aplikasi yang menginstal aplikasi lain dan memiliki izin INSTALL_PACKAGES hanya dapat mengakses direktori “obb” untuk tujuan mengelola file perluasan APK.
9.8.10. Laporan Bug Konektivitas
Jika implementasi perangkat mendeklarasikan flag fitur android.hardware.telephony
,
perangkat tersebut:
- [C-1-1] HARUS mendukung pembuatan laporan bug konektivitas melalui
BUGREPORT_MODE_TELEPHONY
dengan BugreportManager. - [C-1-2] HARUS mendapatkan izin pengguna setiap kali
BUGREPORT_MODE_TELEPHONY
digunakan untuk membuat laporan dan TIDAK BOLEH meminta pengguna untuk menyetujui semua permintaan mendatang dari aplikasi. - [C-1-3] TIDAK BOLEH menampilkan laporan yang dihasilkan ke aplikasi yang meminta tanpa izin pengguna yang jelas.
- [C-1-4] Laporan yang dibuat menggunakan
BUGREPORT_MODE_TELEPHONY
HARUS berisi setidaknya informasi berikut:- Dump
TelephonyDebugService
- Dump
TelephonyRegistry
- Dump
WifiService
- Dump
ConnectivityService
- Dump instance
CarrierService
paket panggilan (jika terikat) - Buffer log radio
- Dump
SubscriptionManagerService
- Dump
- [C-1-5] TIDAK BOLEH menyertakan hal berikut dalam laporan yang dihasilkan:
- Semua jenis informasi yang tidak terkait langsung dengan proses debug konektivitas.
- Semua jenis log traffic aplikasi yang diinstal pengguna atau profil mendetail aplikasi/paket yang diinstal pengguna (UID tidak masalah, nama paket tidak).
- DAPAT menyertakan informasi tambahan yang tidak terkait dengan identitas pengguna apa pun. (misalnya, log vendor).
Jika implementasi perangkat menyertakan informasi tambahan (misalnya log vendor) dalam laporan bug dan informasi tersebut memiliki dampak privasi/keamanan/baterai/penyimpanan/memori, implementasi tersebut:
- [C-SR-1] SANGAT DIUJAMI untuk menetapkan setelan developer secara default ke
dinonaktifkan. Implementasi referensi AOSP memenuhi hal ini dengan menyediakan opsi
Enable verbose vendor logging
di setelan developer untuk menyertakan log vendor khusus perangkat tambahan dalam laporan bug.
9.8.11. Berbagi blob data
Android, melalui BlobStoreManager, memungkinkan aplikasi berkontribusi pada blob data ke Sistem untuk dibagikan dengan kumpulan aplikasi yang dipilih.
Jika implementasi perangkat mendukung blob data bersama seperti yang dijelaskan dalam dokumentasi SDK, implementasi tersebut:
- [C-1-1] TIDAK BOLEH membagikan blob data milik aplikasi di luar yang diizinkan (yaitu cakupan akses default dan mode akses lainnya yang dapat ditentukan menggunakan BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess(), atau BlobStoreManager.session#allowPublicAccess() TIDAK BOLEH diubah). Implementasi referensi AOSP memenuhi persyaratan ini.
- [C-1-2] TIDAK BOLEH mengirim dari perangkat atau membagikan hash blob data yang aman kepada aplikasi lain (yang digunakan untuk mengontrol akses).
9.8.12. Pengenalan Musik
Android, melalui System API MusicRecognitionManager, mendukung mekanisme untuk implementasi perangkat guna meminta pengenalan musik, dengan rekaman audio, dan mendelegasikan pengenalan musik ke aplikasi dengan hak istimewa yang mengimplementasikan MusicRecognitionService API.
Jika implementasi perangkat menyertakan layanan yang mengimplementasikan System API MusicRecognitionManager atau layanan eksklusif apa pun yang melakukan streaming data audio seperti yang dijelaskan di atas, layanan tersebut:
- [C-1-1] HARUS mewajibkan pemanggil MusicRecognitionManager memiliki
izin
MANAGE_MUSIC_RECOGNITION
- [C-1-2] HARUS mewajibkan satu aplikasi pengenalan musik yang telah diinstal sebelumnya untuk menerapkan MusicRecognitionService.
- [C-1-3] TIDAK BOLEH mengizinkan pengguna mengganti MusicRecognitionManagerService atau MusicRecognitionService dengan aplikasi atau layanan yang dapat diinstal pengguna.
- [C-1-4] HARUS memastikan bahwa saat MusicRecognitionManagerService mengakses rekaman audio dan meneruskannya ke aplikasi yang menerapkan MusicRecognitionService, akses audio dilacak melalui pemanggilan AppOpsManager.noteOp / startOp.
Jika implementasi perangkat MusicRecognitionManagerService atau MusicRecognitionService menyimpan data audio yang diambil, data tersebut:
- [C-2-1] TIDAK BOLEH menyimpan audio mentah atau sidik jari audio apa pun di disk, atau di memori selama lebih dari 14 hari.
- [C-2-2] TIDAK BOLEH membagikan data tersebut di luar MusicRecognitionService, kecuali dengan izin pengguna yang eksplisit setiap kali data tersebut dibagikan.
9.8.13. SensorPrivacyManager
Jika implementasi perangkat memberi pengguna kemampuan software untuk menonaktifkan input kamera dan/atau mikrofon untuk implementasi perangkat, pengguna:
- [C-1-1] HARUS menampilkan 'true' secara akurat untuk metode API supportsSensorToggle() yang relevan.
- [C-1-2] HARUS, saat aplikasi mencoba mengakses mikrofon atau kamera yang diblokir, tampilkan kepada pengguna kemampuan pengguna yang tidak dapat ditutup yang dengan jelas menunjukkan bahwa sensor diblokir dan memerlukan pilihan untuk melanjutkan pemblokiran atau membuka blokir sesuai dengan penerapan AOSP yang memenuhi persyaratan ini.
- [C-1-3] HANYA BOLEH meneruskan data kamera dan audio kosong (atau palsu) ke aplikasi dan tidak melaporkan kode error karena pengguna tidak mengaktifkan kamera atau mikrofon melalui kemampuan pengguna yang ditampilkan per [C-1-2] di atas.
Memulai persyaratan baru
9.8.14. Pengelola Kredensial
Dihapus.
9.8.15. Implementasi API dengan Sandbox
Android, melalui serangkaian API delegasi, menyediakan mekanisme untuk memproses data tingkat OS dan data standby yang aman. Pemrosesan tersebut dapat didelegasikan ke apk yang telah diinstal sebelumnya dengan akses istimewa dan kemampuan komunikasi yang dikurangi, yang dikenal sebagai Implementasi API dengan Sandbox.
Implementasi API dengan Sandbox:
- [C-0-1] TIDAK BOLEH meminta izin INTERNET.
- [C-0-2] HANYA BOLEH mengakses internet melalui API terstruktur yang didukung oleh implementasi open source yang tersedia secara publik menggunakan mekanisme penjagaan privasi, atau secara tidak langsung melalui Android SDK API. Mekanisme perlindungan privasi didefinisikan sebagai "mekanisme yang hanya mengizinkan analisis secara gabungan dan mencegah pencocokan peristiwa yang dicatat dalam log atau hasil turunan ke masing-masing pengguna", untuk mencegah data per pengguna dapat di-introspeksi (misalnya, diterapkan menggunakan teknologi privasi diferensial seperti RAPPOR).
- [C-0-3] HARUS memisahkan layanan dari komponen sistem lainnya
(misalnya, tidak mengikat layanan atau membagikan ID proses) kecuali untuk
hal berikut:
- Telepon, Kontak, UI Sistem, dan Media
- [C-0-4] TIDAK BOLEH mengizinkan pengguna mengganti layanan dengan aplikasi atau layanan yang dapat diinstal pengguna
- [C-0-5] HANYA boleh mengizinkan layanan yang diprainstal untuk mengambil data tersebut. Kecuali jika kemampuan penggantian di-build ke dalam AOSP (misalnya untuk Aplikasi Asisten Digital).
- [C-0-6] TIDAK BOLEH mengizinkan aplikasi apa pun selain mekanisme layanan prainstal agar dapat mengambil data tersebut. Kecuali jika kemampuan pengambilan tersebut diimplementasikan dengan Android SDK API.
- [C-0-7] HARUS memberikan kemampuan pengguna untuk menonaktifkan layanan.
- [C-0-8] TIDAK BOLEH menghilangkan kemampuan pengguna untuk mengelola izin Android yang dimiliki oleh layanan dan mengikuti model izin Android seperti yang dijelaskan dalam Bagian 9.1. Izin.
9.8.16. Data Audio dan Kamera Berkelanjutan
Selain persyaratan yang diuraikan dalam 9.8.2 Perekaman, 9.8.6 data level OS dan data standby, serta 9.8.15 implementasi API dengan sandbox, implementasi yang menggunakan data Audio yang diperoleh di latar belakang (secara terus-menerus) melalui AudioRecord, SoundTrigger, atau API Audio lainnya ATAU data Kamera yang diperoleh di latar belakang (secara terus-menerus) melalui CameraManager atau API Kamera lainnya:
- [C-0-1] HARUS menerapkan indikator yang sesuai (kamera dan/atau mikrofon sesuai
dengan bagian 9.8.2 Perekaman), kecuali:
- Akses ini dilakukan dalam implementasi dengan Sandbox (lihat 9.8.15 Implementasi API dengan Sandbox), melalui paket yang memiliki satu atau beberapa peran berikut: System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence, atau System Visual Intelligence.
- Akses dilakukan melalui sandbox, yang diimplementasikan dan
diberlakukan melalui mekanisme di AOSP (
HotwordDetectionService
,WearableSensingService
,VisualQueryDetector
). - Akses audio dilakukan untuk tujuan bantuan oleh aplikasi
Asisten Digital, yang menyediakan
SOURCE_HOTWORD
sebagai sumber audio. - Akses dilakukan oleh sistem dan diimplementasikan dengan kode open source.
- [C-SR-1] SANGAT DISARANKAN untuk mewajibkan izin pengguna untuk setiap fungsi yang menggunakan data tersebut, dan dinonaktifkan secara default.
- [C-SR-2] SANGAT DISARANKAN untuk menerapkan perlakuan yang sama (yaitu mengikuti batasan yang diuraikan dalam 9.8.2 Perekaman, 9.8.6 Data level OS dan standby, 9.8.15 Implementasi API dengan sandbox, dan 9.8.16 Data Audio dan Kamera Kontinu) ke data Kamera yang berasal dari perangkat wearable jarak jauh.
Jika data Kamera disediakan dari perangkat wearable jarak jauh dan diakses dalam
bentuk yang tidak dienkripsi di luar Android OS, implementasi dengan sandbox, atau fungsi
dengan sandbox yang dibuat oleh WearableSensingManager
, data tersebut:
- [C-1-1] HARUS menunjukkan ke perangkat wearable jarak jauh untuk menampilkan indikator tambahan di sana.
Jika perangkat memberikan kemampuan untuk berinteraksi dengan Aplikasi Asisten Digital tanpa kata kunci yang ditetapkan (baik menangani kueri pengguna umum, maupun menganalisis kehadiran pengguna melalui kamera):
- [C-2-1] HARUS memastikan implementasi tersebut disediakan oleh paket yang memiliki
peran
android.app.role.ASSISTANT
. - [C-2-2] HARUS memastikan implementasi tersebut menggunakan
HotwordDetectionService
dan/atauVisualQueryDetectionService
Android API.
9.8.17. Telemetry
Android menyimpan log sistem dan aplikasi menggunakan StatsLog API. Log ini dikelola melalui StatsManager API yang dapat digunakan oleh aplikasi sistem dengan hak istimewa.
StatsManager juga menyediakan cara untuk mengumpulkan data yang dikategorikan sebagai sensitif
privasi dari perangkat dengan mekanisme perlindungan privasi. Secara khusus,
StatsManager::query
API menyediakan kemampuan untuk membuat kueri kategori metrik
terbatas yang ditentukan
di StatsLog.
Setiap implementasi yang membuat kueri dan mengumpulkan metrik yang dibatasi dari StatsManager:
- [C-0-1] HARUS menjadi satu-satunya aplikasi/implementasi di perangkat dan memiliki
izin
READ_RESTRICTED_STATS
. - [C-0-2] HANYA boleh mengirim data telemetri dan log perangkat menggunakan mekanisme perlindungan privasi. Mekanisme perlindungan privasi didefinisikan sebagai "mekanisme yang hanya mengizinkan analisis secara gabungan dan mencegah pencocokan peristiwa yang dicatat ke dalam log atau hasil turunan ke setiap pengguna", untuk mencegah data per pengguna dapat di-introspeksi (misalnya, diterapkan menggunakan teknologi privasi diferensial seperti RAPPOR).
- [C-0-3] TIDAK BOLEH mengaitkan data tersebut dengan identitas pengguna apa pun (seperti Akun) di perangkat.
- [C-0-4] TIDAK BOLEH membagikan data tersebut dengan komponen OS lain yang tidak mengikuti persyaratan yang diuraikan di bagian saat ini (9.8.17 Telemetri yang menjaga privasi).
- [C-0-5] HARUS menyediakan kemampuan pengguna untuk mengaktifkan/menonaktifkan pengumpulan, penggunaan, dan pembagian telemetri yang menjaga privasi.
- [C-0-6] HARUS memberikan kemampuan pengguna untuk menghapus data tersebut yang dikumpulkan oleh implementasi jika data disimpan dalam bentuk apa pun di perangkat. Jika pengguna memilih untuk menghapus data, HARUS menghapus semua data yang saat ini disimpan di perangkat.
- [C-0-7] HARUS mengungkapkan implementasi protokol perlindungan privasi yang mendasarinya di repositori open source.
- [C-0-8 ]HARUS menerapkan kebijakan keluar data di bagian ini untuk mengontrol pengumpulan data dalam kategori metrik yang dibatasi yang ditentukan di StatsLog.
Akhiri persyaratan baru
9.9. Enkripsi Penyimpanan Data
Semua perangkat HARUS memenuhi persyaratan bagian 9.9.1. Perangkat yang diluncurkan pada API level yang lebih awal dari dokumen ini dikecualikan dari persyaratan bagian 9.9.2 dan 9.9.3; sebagai gantinya, perangkat HARUS memenuhi persyaratan di bagian 9.9 dari dokumen Android Compatibility Definition yang sesuai dengan API level tempat perangkat diluncurkan.
9.9.1. Direct Boot
Implementasi perangkat:
[C-0-1] HARUS menerapkan API mode Booting Langsung meskipun tidak mendukung Enkripsi Penyimpanan.
[C-0-2] Intent
ACTION_LOCKED_BOOT_COMPLETED
danACTION_USER_UNLOCKED
HARUS tetap disiarkan untuk memberi sinyal kepada aplikasi yang mengetahui Direct Boot bahwa lokasi penyimpanan yang Dienkripsi Perangkat (DE) dan Dienkripsi Kredensial (CE) tersedia untuk pengguna.
9.9.2. Persyaratan enkripsi
Implementasi perangkat:
- [C-0-1] HARUS mengenkripsi data pribadi
aplikasi (partisi
/data
), serta partisi penyimpanan bersama aplikasi (partisi/sdcard
) jika merupakan bagian permanen dari perangkat yang tidak dapat dilepas. - [C-0-2] HARUS mengaktifkan enkripsi penyimpanan data secara default pada saat pengguna telah menyelesaikan pengalaman penyiapan siap pakai.
[C-0-3] HARUS memenuhi persyaratan enkripsi penyimpanan data di atas dengan menerapkan salah satu dari dua metode enkripsi berikut:
- Enkripsi Berbasis File (FBE) dan Enkripsi Metadata seperti yang dijelaskan di bagian 9.9.3.1.
- Enkripsi Tingkat Blok Per Pengguna seperti yang dijelaskan di bagian 9.9.3.2.
9.9.3. Metode Enkripsi
Jika implementasi perangkat dienkripsi, implementasi tersebut:
- [C-1-1] HARUS melakukan booting tanpa meminta kredensial pengguna dan
memungkinkan aplikasi yang mendukung Direct Boot mengakses penyimpanan yang Dienkripsi Perangkat (DE)
setelah pesan
ACTION_LOCKED_BOOT_COMPLETED
disiarkan. - [C-1-2] HARUS hanya mengizinkan akses ke penyimpanan yang Dienkripsi dengan Kredensial (CE) setelah
pengguna membuka kunci perangkat dengan memberikan kredensial mereka
(misalnya, kode sandi, pin, pola, atau sidik jari) dan pesan
ACTION_USER_UNLOCKED
disiarkan. - [C-1-13] TIDAK BOLEH menawarkan metode apa pun untuk membuka kunci penyimpanan yang dilindungi CE tanpa kredensial yang diberikan pengguna, kunci escrow terdaftar, atau implementasi lanjutkan saat memulai ulang yang memenuhi persyaratan dalam bagian 9.9.4.
- [C-1-4] HARUS menggunakan Booting Terverifikasi.
9.9.3.1. Enkripsi Berbasis File dengan Enkripsi Metadata
Jika implementasi perangkat menggunakan Enkripsi Berbasis File dengan Enkripsi Metadata, perangkat tersebut:
- [C-1-5] HARUS mengenkripsi konten file dan metadata sistem file menggunakan AES-256-XTS atau Adiantum. AES-256-XTS mengacu pada Advanced Encryption Standard dengan panjang kunci cipher 256-bit, yang dioperasikan dalam mode XTS; panjang penuh kunci adalah 512 bit. Adiantum mengacu pada Adiantum-XChaCha12-AES, seperti yang ditentukan di https://github.com/google/adiantum. Metadata sistem file adalah data seperti ukuran file, kepemilikan, mode, dan atribut yang diperluas (xattr).
- [C-1-6] HARUS mengenkripsi nama file menggunakan AES-256-CBC-CTS, AES-256-HCTR2, atau Adiantum.
- [C-1-12] Jika perangkat memiliki petunjuk Advanced Encryption Standard (AES) (seperti ARMv8 Cryptography Extensions pada perangkat berbasis ARM, atau AES-NI pada perangkat berbasis x86), opsi berbasis AES di atas untuk nama file, konten file, dan enkripsi metadata sistem file HARUS digunakan, bukan Adiantum.
- [C-1-13] HARUS menggunakan fungsi turunan kunci yang kuat secara kriptografis dan tidak dapat dibalik (misalnya, HKDF-SHA512) untuk mendapatkan subkunci yang diperlukan (misalnya, kunci per file) dari kunci CE dan DE. "Kriptografis yang kuat dan tidak dapat dibalik" berarti fungsi turunan kunci memiliki kekuatan keamanan setidaknya 256 bit dan berperilaku sebagai keluarga fungsi pseudorandom di atas inputnya.
- [C-1-14] TIDAK BOLEH menggunakan kunci atau subkunci File Based Encryption (FBE) yang sama untuk tujuan kriptografi yang berbeda (misalnya, untuk enkripsi dan turunan kunci, atau untuk dua algoritma enkripsi yang berbeda).
- [C-1-15] HARUS memastikan bahwa semua blok konten file terenkripsi yang tidak dihapus di penyimpanan persisten dienkripsi menggunakan kombinasi kunci enkripsi dan vektor inisialisasi (IV) yang bergantung pada file dan offset dalam file. Selain itu, semua kombinasi tersebut HARUS berbeda, kecuali jika enkripsi dilakukan menggunakan hardware enkripsi inline yang hanya mendukung panjang IV 32 bit.
- [C-1-16] HARUS memastikan bahwa semua nama file terenkripsi yang tidak dihapus di penyimpanan persisten dalam direktori yang berbeda dienkripsi menggunakan kombinasi kunci enkripsi dan vektor inisialisasi (IV) yang berbeda.
[C-1-17] HARUS memastikan bahwa semua blok metadata sistem file terenkripsi di penyimpanan persisten dienkripsi menggunakan kombinasi kunci enkripsi dan vektor inisialisasi (IV) yang berbeda.
Kunci yang melindungi area penyimpanan CE dan DE serta metadata sistem file:
- [C-1-7] HARUS terikat secara kriptografis ke Keystore yang didukung hardware. Keystore ini HARUS terikat dengan Verified Boot dan root of trust hardware perangkat.
- [C-1-8] Kunci CE HARUS terikat dengan kredensial layar kunci pengguna.
- [C-1-9] Kunci CE HARUS terikat dengan kode sandi default saat pengguna belum menentukan kredensial layar kunci.
- [C-1-10] HARUS unik dan berbeda, dengan kata lain, tidak ada kunci CE atau DE pengguna yang cocok dengan kunci CE atau DE pengguna lain.
- [C-1-11] HARUS menggunakan cipher, panjang kunci, dan mode yang didukung secara wajib.
- [C-1-12] HARUS dihapus dengan aman selama membuka kunci dan mengunci bootloader seperti yang dijelaskan di sini.
HARUS membuat aplikasi penting yang diinstal sebelumnya (misalnya, Alarm, Telepon, Messenger) tahu Direct Boot.
Project Open Source Android upstream menyediakan implementasi Enkripsi Berbasis File yang lebih disukai berdasarkan fitur enkripsi "fscrypt" kernel Linux, dan Enkripsi Metadata berdasarkan fitur "dm-default-key" kernel Linux.
9.9.3.2. Enkripsi Tingkat Blok Per Pengguna
Jika implementasi perangkat menggunakan enkripsi tingkat blok per pengguna, implementasi tersebut:
- [C-1-1] HARUS mengaktifkan dukungan multi-pengguna seperti yang dijelaskan di bagian 9.5.
- [C-1-2] HARUS menyediakan partisi per pengguna, baik menggunakan partisi mentah maupun volume logis.
- [C-1-3] HARUS menggunakan kunci enkripsi yang unik dan berbeda per pengguna untuk enkripsi perangkat blok yang mendasarinya.
[C-1-4] HARUS menggunakan AES-256-XTS untuk enkripsi tingkat blok pada partisi pengguna.
Kunci yang melindungi perangkat terenkripsi tingkat blok per pengguna:
- [C-1-5] HARUS terikat secara kriptografis ke Keystore yang didukung hardware. Keystore ini HARUS terikat dengan Verified Boot dan root of trust hardware perangkat.
- [C-1-6] HARUS terikat dengan kredensial layar kunci pengguna yang sesuai.
Enkripsi tingkat blok per pengguna dapat diterapkan menggunakan fitur "dm-crypt" kernel Linux di atas partisi per pengguna.
9.9.4. Melanjutkan saat Mulai Ulang
Lanjutkan saat Mulai Ulang memungkinkan membuka kunci penyimpanan CE semua aplikasi, termasuk aplikasi yang belum mendukung Direct Boot, setelah mulai ulang yang dimulai oleh OTA. Fitur ini memungkinkan pengguna menerima notifikasi dari aplikasi yang diinstal setelah memulai ulang.
Implementasi Resume-on-Reboot harus terus memastikan bahwa saat perangkat jatuh ke tangan penyerang, penyerang tersebut akan sangat kesulitan untuk memulihkan data terenkripsi CE milik pengguna, meskipun perangkat diaktifkan, penyimpanan CE tidak terkunci, dan pengguna telah membuka kunci perangkat setelah menerima OTA. Untuk ketahanan terhadap serangan orang dalam, kami juga mengasumsikan bahwa penyerang mendapatkan akses untuk menyiarkan kunci penandatanganan kriptografis.
Khususnya:
[C-0-1] Penyimpanan CE TIDAK BOLEH dibaca bahkan oleh penyerang yang secara fisik memiliki perangkat, lalu memiliki kemampuan dan batasan berikut:
- Dapat menggunakan kunci penandatanganan dari vendor atau perusahaan mana pun untuk menandatangani pesan arbitrer.
- Dapat menyebabkan OTA diterima oleh perangkat.
- Dapat mengubah operasi hardware apa pun (AP, flash, dll.) kecuali seperti yang dijelaskan di bawah, tetapi modifikasi tersebut melibatkan penundaan setidaknya satu jam dan siklus daya yang menghancurkan konten RAM.
- Tidak dapat mengubah operasi hardware tahan modifikasi (misalnya Titan M).
- Tidak dapat membaca RAM perangkat live.
- Tidak dapat memperoleh kredensial pengguna (PIN, pola, sandi) atau menyebabkan kredensial tersebut dimasukkan.
Sebagai contoh, implementasi perangkat yang menerapkan dan mematuhi semua deskripsi yang ditemukan di sini akan mematuhi [C-0-1].
9.10. Integritas Perangkat
Persyaratan berikut memastikan adanya transparansi terhadap status integritas perangkat. Implementasi perangkat:
[C-0-1] HARUS melaporkan dengan benar melalui metode System API
PersistentDataBlockManager.getFlashLockState()
apakah status bootloader mereka mengizinkan flashing image sistem.[C-0-2] HARUS mendukung Verified Boot untuk integritas perangkat.
Jika implementasi perangkat sudah diluncurkan tanpa mendukung Verified Boot di Android versi sebelumnya dan tidak dapat menambahkan dukungan untuk fitur ini dengan update software sistem, perangkat tersebut DAPAT dikecualikan dari persyaratan.
Verified Boot adalah fitur yang menjamin integritas software perangkat. Jika implementasi perangkat mendukung fitur ini, implementasi tersebut:
- [C-1-1] HARUS mendeklarasikan flag fitur platform
android.software.verified_boot
. - [C-1-2] HARUS melakukan verifikasi pada setiap urutan booting.
- [C-1-3] HARUS memulai verifikasi dari kunci hardware yang tidak dapat diubah yang merupakan root of trust dan terus ke atas hingga partisi sistem.
- [C-1-4] HARUS menerapkan setiap tahap verifikasi untuk memeriksa integritas dan keaslian semua byte di tahap berikutnya sebelum menjalankan kode di tahap berikutnya.
- [C-1-5] HARUS menggunakan algoritma verifikasi yang sekuat rekomendasi saat ini dari NIST untuk algoritma hashing (SHA-256) dan ukuran kunci publik (RSA-2048).
- [C-1-6] TIDAK BOLEH mengizinkan booting selesai saat verifikasi sistem gagal, kecuali jika pengguna mengizinkan untuk mencoba melakukan booting, dalam hal ini data dari blok penyimpanan yang tidak diverifikasi TIDAK BOLEH digunakan.
- [C-1-7] TIDAK BOLEH mengizinkan partisi terverifikasi di perangkat diubah kecuali jika pengguna telah secara eksplisit membuka kunci bootloader.
- [C-SR-1] Jika ada beberapa chip terpisah di perangkat (misalnya, radio, pemroses gambar khusus), proses booting setiap chip tersebut SANGAT DISARANKAN untuk memverifikasi setiap tahap saat booting.
- [C-1-8] HARUS menggunakan penyimpanan yang tahan modifikasi: untuk menyimpan apakah bootloader telah dibuka kuncinya. Penyimpanan yang tahan modifikasi berarti bootloader dapat mendeteksi apakah penyimpanan telah dimodifikasi dari dalam Android.
- [C-1-9] HARUS meminta pengguna, saat menggunakan perangkat, dan memerlukan konfirmasi fisik sebelum mengizinkan transisi dari mode bootloader terkunci ke mode bootloader tidak terkunci.
- [C-1-10] HARUS menerapkan perlindungan rollback untuk partisi yang digunakan oleh Android (misalnya, booting, partisi sistem) dan menggunakan penyimpanan yang tahan modifikasi untuk menyimpan metadata yang digunakan untuk menentukan versi OS minimum yang diizinkan.
- [C-1-11] HARUS menghapus semua data pengguna dengan aman selama membuka kunci dan mengunci bootloader, sesuai dengan '9.12. Penghapusan Data' (termasuk partisi userdata dan ruang NVRAM apa pun).
- [C-SR-2] SANGAT DISARANKAN untuk memverifikasi semua file APK aplikasi dengan hak istimewa dengan rantai kepercayaan yang berakar di partisi yang dilindungi oleh Booting Terverifikasi.
- [C-SR-3] SANGAT DISARANKAN untuk memverifikasi artefak yang dapat dieksekusi yang dimuat oleh aplikasi dengan hak istimewa dari luar file APK-nya (seperti kode yang dimuat secara dinamis atau kode yang dikompilasi) sebelum mengeksekusinya atau SANGAT DISARANKAN untuk tidak mengeksekusinya sama sekali.
- HARUS menerapkan perlindungan rollback untuk komponen apa pun dengan firmware persisten (misalnya modem, kamera) dan HARUS menggunakan penyimpanan yang tahan modifikasi untuk menyimpan metadata yang digunakan untuk menentukan versi minimum yang diizinkan.
Jika implementasi perangkat sudah diluncurkan tanpa mendukung C-1-8 hingga C-1-11 di Android versi sebelumnya dan tidak dapat menambahkan dukungan untuk persyaratan ini dengan update software sistem, perangkat tersebut DAPAT dikecualikan dari persyaratan.
Project Open Source Android upstream menyediakan implementasi
fitur ini yang lebih disukai di repositori
external/avb/
, yang dapat diintegrasikan ke dalam bootloader yang digunakan untuk memuat
Android.
Penerapan perangkat
Jika implementasi perangkat memiliki kemampuan untuk memverifikasi konten file per halaman, implementasi tersebut:
[
C-0-3C-2-1] mendukung verifikasi konten file secara kriptografisdengan kunci tepercayatanpa membaca seluruh file.[
C-0-4C-2-2] TIDAK BOLEH mengizinkan permintaan baca pada file yang dilindungi berhasil jika konten yang dibacatidak diverifikasi terhadap kunci tepercayatidak diverifikasi per [C-2-1] di atas.
Memulai persyaratan baru
- [C-2-4] HARUS menampilkan checksum file dalam O(1) untuk file yang diaktifkan.
Akhiri persyaratan baru
Jika implementasi perangkat sudah diluncurkan tanpa kemampuan untuk memverifikasi konten file dengan kunci tepercaya pada versi Android sebelumnya dan tidak dapat menambahkan dukungan untuk fitur ini dengan update software sistem, implementasi tersebut DAPAT dikecualikan dari persyaratan. Project Open Source Android upstream menyediakan penerapan fitur ini yang lebih disukai berdasarkan fitur fs-verity kernel Linux.
Implementasi perangkat:
- [C-SR-4] SANGAT DIUTAMAKAN untuk mendukung Android Protected Confirmation API.
Jika implementasi perangkat mendukung Android Protected Confirmation API, perangkat tersebut:
[C-3-1] HARUS melaporkan
true
untuk APIConfirmationPrompt.isSupported()
.[C-3-2] HARUS memastikan bahwa kode yang berjalan di Android OS, termasuk kernel-nya, berbahaya atau tidak, tidak dapat menghasilkan respons positif tanpa interaksi pengguna.
[C-3-3] HARUS memastikan bahwa pengguna telah dapat meninjau dan menyetujui pesan yang diminta meskipun OS Android, termasuk kernelnya, disusupi.
9.11. Kunci dan Kredensial
Sistem Android Keystore memungkinkan developer aplikasi menyimpan kunci kriptografis dalam penampung dan menggunakannya dalam operasi kriptografis melalui KeyChain API atau Keystore API. Implementasi perangkat:
- [C-0-1] HARUS mengizinkan minimal 8.192 kunci untuk diimpor atau dibuat.
- [C-0-2] Autentikasi layar kunci HARUS menerapkan interval waktu antara upaya yang gagal. Dengan n sebagai jumlah upaya gagal, interval waktu HARUS minimal 30 detik untuk 9 < n < 30. Untuk n > 29, nilai interval waktu HARUS minimal 30*2^floor((n-30)/10)) detik atau setidaknya 24 jam, mana saja yang lebih kecil.
- HARUS tidak membatasi jumlah kunci yang dapat dibuat
Memulai persyaratan baru
- [C-0-3] HARUS membatasi jumlah upaya autentikasi utama yang gagal.
- [C-SR-2] SANGAT DISARANKAN untuk menerapkan batas atas 20 upaya autentikasi primer yang gagal dan jika pengguna mengizinkan dan memilih untuk mengaktifkan fitur tersebut, lakukan "Reset Data Pabrik" setelah melampaui batas upaya autentikasi primer yang gagal.
Jika implementasi perangkat menambahkan atau mengubah metode autentikasi untuk membuka layar kunci jika didasarkan pada rahasia yang diketahui dan menggunakan metode autentikasi baru untuk diperlakukan sebagai cara aman untuk mengunci layar, maka:
- [C-SR-3] PIN SANGAT DIUJAMI untuk memiliki minimal 6 digit, atau setara dengan entropi 20-bit.
- [C-2-1] PIN dengan panjang kurang dari 6 digit TIDAK BOLEH mengizinkan entri otomatis tanpa interaksi pengguna untuk menghindari pengungkapan panjang PIN.
Akhiri persyaratan baru
Jika implementasi perangkat mendukung layar kunci yang aman, perangkat tersebut:
- [C-1-1] HARUS mencadangkan penerapan keystore dengan lingkungan eksekusi terisolasi.
- [C-1-2] HARUS memiliki implementasi algoritma kriptografis RSA, AES, ECDSA, ECDH (jika IKeyMintDevice didukung), 3DES, dan HMAC serta fungsi hash keluarga MD5, SHA1, dan SHA-2 untuk mendukung algoritma yang didukung sistem Keystore Android dengan benar di area yang terisolasi dengan aman dari kode yang berjalan di kernel dan yang lebih baru. Isolasi aman HARUS memblokir semua mekanisme potensial yang memungkinkan kode kernel atau ruang pengguna mengakses status internal lingkungan terisolasi, termasuk DMA. Project Open Source Android upstream (AOSP) memenuhi persyaratan ini dengan menggunakan implementasi Trusty, tetapi solusi berbasis ARM TrustZone lainnya atau implementasi aman yang ditinjau pihak ketiga dari isolasi berbasis hypervisor yang tepat adalah opsi alternatif.
- [C-1-3] HARUS melakukan autentikasi layar kunci di lingkungan eksekusi terisolasi dan hanya jika berhasil, izinkan kunci terikat autentikasi digunakan. Kredensial layar kunci HARUS disimpan dengan cara yang hanya mengizinkan lingkungan eksekusi terisolasi untuk melakukan autentikasi layar kunci. Project Open Source Android upstream menyediakan Gatekeeper Hardware Abstraction Layer (HAL) dan Trusty, yang dapat digunakan untuk memenuhi persyaratan ini.
- [C-1-4] HARUS mendukung pengesahan kunci dengan kunci penandatanganan pengesahan dilindungi oleh hardware aman dan penandatanganan dilakukan di hardware aman. Kunci penandatanganan pengesahan HARUS dibagikan di sejumlah perangkat yang cukup besar untuk mencegah kunci digunakan sebagai ID perangkat. Salah satu cara untuk memenuhi persyaratan ini adalah dengan membagikan kunci pengesahan yang sama,kecuali jika setidaknya 100.000 unit SKU tertentu diproduksi. Jika lebih dari 100.000 unit SKU diproduksi, kunci yang berbeda DAPAT digunakan untuk setiap 100.000 unit.
Perhatikan bahwa jika implementasi perangkat sudah diluncurkan pada versi Android
sebelumnya, perangkat tersebut dikecualikan dari persyaratan untuk memiliki keystore
yang didukung oleh lingkungan eksekusi terisolasi dan mendukung pengesahan kunci,
kecuali jika mendeklarasikan fitur android.hardware.fingerprint
yang memerlukan
keystore yang didukung oleh lingkungan eksekusi terisolasi.
- [C-1-5] HARUS mengizinkan pengguna memilih waktu tunggu Tidur untuk transisi dari status tidak terkunci ke terkunci, dengan waktu tunggu minimum yang diizinkan hingga 15 detik. Perangkat otomotif, yang mengunci layar setiap kali head unit dinonaktifkan atau pengguna beralih, TIDAK BOLEH memiliki konfigurasi Waktu tunggu tidur.
- [C-1-6] HARUS mendukung salah satu dari hal berikut:
- IKeymasterDevice 3.0,
- IKeymasterDevice 4.0,
- IKeymasterDevice 4.1,
- IKeyMintDevice versi 1, atau
- IKeyMintDevice versi 2.
- [C-SR-1] SANGAT DIUJAMI untuk mendukung IKeyMintDevice versi 1.
9.11.1. Layar Kunci, Autentikasi, dan Perangkat Virtual yang Aman
Implementasi AOSP mengikuti model autentikasi bertingkat, dengan autentikasi utama berbasis knowledge-factory yang dapat didukung oleh biometrik sekunder yang kuat, atau oleh modalitas tersier yang lebih lemah.
Implementasi perangkat:
[C-SR-1] SANGAT DIUJAMI untuk menetapkan hanya salah satu dari hal berikut sebagai metode autentikasi utama:
- PIN numerik
- Sandi alfanumerik
Pola geser pada petak yang terdiri dari 3x3 titik
Perhatikan bahwa metode autentikasi di atas disebut sebagai metode autentikasi primer yang direkomendasikan dalam dokumen ini.
Memulai persyaratan baru
- [C-0-1] HARUS membatasi jumlah upaya autentikasi utama yang gagal.
- [C-SR-5] SANGAT DIUJAMI untuk menerapkan batas atas 20 upaya autentikasi primer yang gagal dan jika pengguna mengizinkan dan memilih untuk mengaktifkan fitur tersebut, lakukan "Reset Data Pabrik" setelah melampaui batas upaya autentikasi primer yang gagal.
Jika implementasi perangkat menetapkan PIN numerik sebagai metode autentikasi utama yang direkomendasikan, maka:
- [C-SR-6] PIN SANGAT DIUJAMI untuk memiliki minimal 6 digit, atau setara dengan entropi 20-bit.
- [C-SR-7] PIN dengan panjang kurang dari 6 digit SANGAT DISARANKAN TIDAK memungkinkan entri otomatis tanpa interaksi pengguna untuk menghindari pengungkapan panjang PIN.
Akhiri persyaratan baru
Jika implementasi perangkat menambahkan atau mengubah metode autentikasi utama yang direkomendasikan dan menggunakan metode autentikasi baru sebagai cara aman untuk mengunci layar, metode autentikasi baru:
- [C-2-1] HARUS berupa metode autentikasi pengguna seperti yang dijelaskan dalam Mewajibkan Autentikasi Pengguna untuk Penggunaan Kunci.
Jika implementasi perangkat menambahkan atau mengubah metode autentikasi untuk membuka kunci layar kunci jika didasarkan pada rahasia yang diketahui dan menggunakan metode autentikasi baru untuk diperlakukan sebagai cara aman untuk mengunci layar:
- [C-3-1] Entropi panjang input terpendek yang diizinkan HARUS lebih besar dari 10 bit.
- [C-3-2] Entropi maksimum dari semua kemungkinan input HARUS lebih besar dari 18 bit.
- [C-3-3] Metode autentikasi baru TIDAK BOLEH menggantikan metode autentikasi primer yang direkomendasikan (yaitu PIN, pola, sandi) yang diimplementasikan dan disediakan di AOSP.
- [C-3-4] Metode autentikasi baru HARUS dinonaktifkan saat aplikasi Pengontrol Kebijakan Perangkat (DPC) telah menetapkan kebijakan persyaratan sandi melalui DevicePolicyManager.setRequiredPasswordComplexity() dengan konstanta kompleksitas yang lebih ketat daripada PASSWORD_COMPLEXITY_NONE atau melalui metode DevicePolicyManager.setPasswordQuality() dengan konstanta yang lebih ketat daripada PASSWORD_QUALITY_BIOMETRIC_WEAK.
- [C-3-5] Metode autentikasi baru HARUS kembali ke metode autentikasi utama yang direkomendasikan (yaitu PIN, pola, sandi) sekali setiap 72 jam atau kurang ATAU mengungkapkan dengan jelas kepada pengguna bahwa beberapa data tidak akan dicadangkan untuk menjaga privasi data mereka.
Jika implementasi perangkat menambahkan atau mengubah metode autentikasi utama yang direkomendasikan untuk membuka kunci layar kunci dan menggunakan metode autentikasi baru yang didasarkan pada biometrik untuk diperlakukan sebagai cara aman untuk mengunci layar, metode baru:
- [C-4-1] HARUS memenuhi semua persyaratan yang dijelaskan dalam bagian 7.3.10 untuk Kelas 1 (sebelumnya Kemudahan).
- [C-4-2] HARUS memiliki mekanisme penggantian untuk menggunakan salah satu metode autentikasi utama yang direkomendasikan yang didasarkan pada secret yang diketahui.
- [C-4-3] HARUS dinonaktifkan dan hanya mengizinkan autentikasi primer
yang direkomendasikan untuk membuka kunci layar saat aplikasi Pengontrol Kebijakan Perangkat (DPC)
telah menetapkan kebijakan fitur kunci layar dengan memanggil metode
DevicePolicyManager.setKeyguardDisabledFeatures()
, dengan tanda biometrik yang terkait (yaituKEYGUARD_DISABLE_BIOMETRICS
,KEYGUARD_DISABLE_FINGERPRINT
,KEYGUARD_DISABLE_FACE
, atauKEYGUARD_DISABLE_IRIS
).
Jika metode autentikasi biometrik tidak memenuhi persyaratan untuk Class 3 (sebelumnya Kuat) seperti yang dijelaskan dalam bagian 7.3.10:
- [C-5-1] Metode HARUS dinonaktifkan jika aplikasi Pengontrol Kebijakan Perangkat (DPC)
telah menetapkan kebijakan kualitas persyaratan sandi melalui
DevicePolicyManager.setRequiredPasswordComplexity()
dengan bucket kompleksitas yang lebih ketat daripada
PASSWORD_COMPLEXITY_LOW
atau menggunakan metode DevicePolicyManager.setPasswordQuality() dengan konstanta kualitas yang lebih ketat daripadaPASSWORD_QUALITY_BIOMETRIC_WEAK
. - [C-5-2] Pengguna HARUS diuji untuk autentikasi primer yang direkomendasikan (misalnya: PIN, pola, sandi) seperti yang dijelaskan dalam [C-1-7] dan [C-1-8] di bagian 7.3.10.
- [C-5-3] Metode TIDAK BOLEH diperlakukan sebagai layar kunci yang aman, dan HARUS memenuhi persyaratan yang dimulai dengan C-8 di bagian ini di bawah.
Jika implementasi perangkat menambahkan atau mengubah metode autentikasi untuk membuka kunci layar kunci dan metode autentikasi baru didasarkan pada token fisik atau lokasi:
- [C-6-1] Layar kunci HARUS memiliki mekanisme penggantian untuk menggunakan salah satu metode autentikasi utama yang direkomendasikan yang didasarkan pada rahasia yang diketahui dan memenuhi persyaratan untuk diperlakukan sebagai layar kunci yang aman.
- [C-6-2] Metode baru HARUS dinonaktifkan dan hanya mengizinkan salah satu
metode autentikasi utama yang direkomendasikan untuk membuka kunci layar saat
aplikasi Pengontrol Kebijakan Perangkat (DPC) telah menetapkan kebijakan dengan:
- Metode
DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS)
- Metode
DevicePolicyManager.setPasswordQuality()
dengan konstanta kualitas yang lebih ketat daripadaPASSWORD_QUALITY_NONE
. - Metode
DevicePolicyManager.setRequiredPasswordComplexity()
dengan bucket kompleksitas yang lebih ketat daripadaPASSWORD_COMPLEXITY_NONE
.
- Metode
- [C-6-3] Pengguna HARUS diminta untuk menggunakan salah satu metode autentikasi primer yang direkomendasikan (misalnya, PIN, pola, sandi) setidaknya sekali setiap 4 jam atau kurang. Jika token fisik memenuhi persyaratan untuk penerapan TrustAgent di C-X, batasan waktu tunggu yang ditentukan di C-9-5 akan berlaku.
- [C-6-4] Metode baru TIDAK BOLEH diperlakukan sebagai layar kunci yang aman dan HARUS mengikuti batasan yang tercantum di C-8 di bawah.
Jika implementasi perangkat memiliki layar kunci yang aman dan menyertakan satu atau beberapa
agen kepercayaan, yang mengimplementasikan TrustAgentService
System API, implementasi tersebut:
- [C-7-1] HARUS memiliki indikasi yang jelas di menu setelan dan di layar kunci saat kunci perangkat ditangguhkan atau dapat dibuka oleh agen kepercayaan. Misalnya, AOSP memenuhi persyaratan ini dengan menampilkan deskripsi teks untuk "Setelan kunci otomatis" dan "Tombol daya langsung mengunci" di menu setelan dan ikon yang dapat dibedakan di layar kunci.
- [C-7-2] HARUS mematuhi dan menerapkan sepenuhnya semua API agen kepercayaan di
class
DevicePolicyManager
, seperti konstantaKEYGUARD_DISABLE_TRUST_AGENTS
. - [C-7-3] TIDAK BOLEH sepenuhnya mengimplementasikan fungsi
TrustAgentService.addEscrowToken()
di perangkat yang digunakan sebagai perangkat pribadi utama (misalnya perangkat genggam), tetapi DAPAT sepenuhnya mengimplementasikan fungsi tersebut pada implementasi perangkat yang biasanya dibagikan (misalnya Android Television atau Perangkat otomotif). - [C-7-4] HARUS mengenkripsi semua token tersimpan yang ditambahkan oleh
TrustAgentService.addEscrowToken()
. - [C-7-5] TIDAK BOLEH menyimpan kunci enkripsi atau token escrow di perangkat yang sama tempat kunci digunakan. Misalnya, kunci yang disimpan di ponsel diizinkan untuk membuka kunci akun pengguna di TV. Untuk perangkat Automotive, token escrow tidak diizinkan untuk disimpan di bagian mana pun pada kendaraan.
- [C-7-6] HARUS memberi tahu pengguna tentang implikasi keamanan sebelum mengaktifkan token escrow untuk mendekripsi penyimpanan data.
- [C-7-7] HARUS memiliki mekanisme penggantian untuk menggunakan salah satu metode autentikasi utama yang direkomendasikan.
[C-7-8] Pengguna HARUS diuji untuk salah satu metode autentikasi utama yang direkomendasikan (misalnya: PIN, pola, sandi) setidaknya sekali setiap 72 jam atau kurang, kecuali jika keamanan pengguna (misalnya, gangguan pengemudi) menjadi masalah.- [C-7-9] Pengguna HARUS diuji untuk salah satu metode autentikasi utama yang direkomendasikan (misalnya: PIN, pola, sandi) seperti yang dijelaskan dalam [C-1-7] dan [C-1-8] di bagian 7.3.10, kecuali jika keselamatan pengguna (misalnya, gangguan pengemudi) menjadi masalah.
- [C-7-10] TIDAK BOLEH diperlakukan sebagai layar kunci yang aman dan HARUS mengikuti batasan yang tercantum di C-8 di bawah.
- [C-7-11] TIDAK BOLEH mengizinkan TrustAgent di perangkat pribadi utama (misalnya: perangkat genggam) untuk membuka kunci perangkat, dan hanya dapat menggunakannya untuk mempertahankan perangkat yang sudah dibuka kuncinya dalam status terbuka hingga maksimum 4 jam. Implementasi default TrustManagerService di AOSP memenuhi persyaratan ini.
- [C-7-12] HARUS menggunakan saluran komunikasi yang aman secara kriptografis (misalnya UKEY2) untuk meneruskan token escrow dari perangkat penyimpanan ke perangkat target.
Jika implementasi perangkat menambahkan atau mengubah metode autentikasi untuk membuka kunci layar kunci yang bukan layar kunci aman seperti yang dijelaskan di atas, dan menggunakan metode autentikasi baru untuk membuka kunci pengaman kunci:
- [C-8-1] Metode baru HARUS dinonaktifkan saat aplikasi Pengontrol Kebijakan Perangkat
(DPC) telah menetapkan kebijakan kualitas sandi melalui
metode
DevicePolicyManager.setPasswordQuality()
dengan konstanta kualitas yang lebih ketat daripadaPASSWORD_QUALITY_NONE
atau melaluiDevicePolicyManager.setRequiredPasswordComplexity()
dengan konstanta kompleksitas yang lebih ketat daripada 'PASSWORD_COMPLEXITY_NONE'. - [C-8-2] Mereka TIDAK BOLEH mereset timer masa berlaku sandi yang ditetapkan oleh
DevicePolicyManager.setPasswordExpirationTimeout()
. - [C-8-3] Aplikasi TIDAK BOLEH mengekspos API untuk digunakan oleh aplikasi pihak ketiga guna mengubah status kunci.
Jika implementasi perangkat memungkinkan aplikasi membuat
layar virtual sekunder
dan tidak mendukung peristiwa input terkait, seperti melalui
VirtualDeviceManager
,
aplikasi tersebut:
- [C-9-1] HARUS mengunci tampilan virtual sekunder ini saat tampilan default perangkat dikunci, dan membuka kunci tampilan virtual sekunder ini saat tampilan default perangkat tidak terkunci.
Jika implementasi perangkat memungkinkan aplikasi membuat tampilan virtual sekunder dan mendukung peristiwa input terkait, seperti melalui VirtualDeviceManager, aplikasi tersebut:
- [C-10-1] HARUS mendukung status kunci terpisah per perangkat virtual
- [C-10-2] HARUS memutuskan koneksi semua perangkat virtual setelah waktu tunggu tidak ada aktivitas habis
- [C-10-3] HARUS memiliki waktu tunggu tidak ada aktivitas
- [C-10-4] HARUS mengunci semua layar saat pengguna memulai lockdown, termasuk melalui kemampuan pengguna lockdown yang diperlukan untuk perangkat genggam (lihat Bagian 2.2.5[9.11/H-1-2])
- [C-10-5] HARUS memiliki instance perangkat virtual terpisah per pengguna
- [C-10-6] HARUS menonaktifkan pembuatan peristiwa input terkait melalui
VirtualDeviceManager
jika ditunjukkan olehDevicePolicyManager.setNearbyAppStreamingPolicy
- [C-10-7] HARUS menggunakan papan klip terpisah hanya untuk setiap perangkat virtual (atau menonaktifkan papan klip untuk perangkat virtual)
- [C-10-11] HARUS menonaktifkan UI autentikasi di perangkat virtual, termasuk entri faktor pengetahuan dan perintah biometrik
- [C-10-12] HARUS membatasi intent yang dimulai dari perangkat virtual agar hanya ditampilkan di perangkat virtual yang sama
- [C-10-13] TIDAK BOLEH menggunakan status kunci perangkat virtual sebagai otorisasi autentikasi
pengguna dengan Sistem Keystore Android. Lihat
KeyGenParameterSpec.Builder.setUserAuthentication*
.
Jika implementasi perangkat memungkinkan pengguna mentransfer faktor pengetahuan autentikasi utama dari perangkat sumber ke perangkat target, seperti untuk penyiapan awal perangkat target, mereka:
- [C-11-1] HARUS mengenkripsi faktor pengetahuan dengan jaminan perlindungan yang serupa dengan yang dijelaskan dalam whitepaper keamanan Layanan Google Cloud Key Vault saat mentransfer faktor pengetahuan dari perangkat sumber ke perangkat target sehingga faktor pengetahuan tidak dapat didekripsi dari jarak jauh atau digunakan untuk membuka kunci salah satu perangkat dari jarak jauh.
- [C-11-2] HARUS, di perangkat sumber , meminta pengguna untuk mengonfirmasi faktor pengetahuan perangkat sumber sebelum mentransfer faktor pengetahuan ke perangkat target.
- [C-11-3] HARUS, di perangkat target yang tidak memiliki faktor pengetahuan autentikasi utama yang ditetapkan, meminta pengguna untuk mengonfirmasi faktor pengetahuan yang ditransfer di perangkat target sebelum menetapkan faktor pengetahuan tersebut sebagai faktor pengetahuan autentikasi utama untuk perangkat target dan sebelum menyediakan data apa pun yang ditransfer dari perangkat sumber.
Jika implementasi perangkat memiliki layar kunci yang aman dan menyertakan satu atau beberapa
agen kepercayaan, yang memanggil TrustAgentService.grantTrust()
System API dengan
tanda FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE
, mereka:
- [C-12-1] HANYA BOLEH memanggil
grantTrust()
dengan flag saat terhubung ke perangkat fisik terdekat dengan layar kuncinya sendiri, dan saat pengguna telah melakukan autentikasi identitasnya terhadap layar kunci tersebut. Perangkat yang dekat dapat menggunakan mekanisme deteksi di pergelangan tangan atau di tubuh setelah pengguna membuka kunci satu kali untuk memenuhi persyaratan autentikasi pengguna. - [C-12-2] HARUS menempatkan implementasi perangkat ke dalam status
TrustState.TRUSTABLE
saat layar dinonaktifkan (seperti melalui penekanan tombol atau waktu layar habis) dan TrustAgent belum mencabut kepercayaan. AOSP memenuhi persyaratan ini. - [C-12-3] HANYA BOLEH memindahkan perangkat dari
TrustState.TRUSTABLE
ke statusTrustState.TRUSTED
jika TrustAgent masih memberikan kepercayaan berdasarkan persyaratan di C-12-1. - [C-12-4] HARUS memanggil
TrustManagerService.revokeTrust()
- Setelah maksimum 24 jam sejak pemberian kepercayaan, atau
- Setelah periode tidak ada aktivitas selama 8 jam, atau
- Jika implementasi tidak menggunakan rentang yang aman secara kriptografis dan akurat seperti yang ditentukan dalam [C-12-5], saat koneksi pokok ke perangkat fisik terdekat hilang.
- [C-12-5] Implementasi yang mengandalkan rentang yang aman dan akurat untuk memenuhi persyaratan [C-12-4] HARUS menggunakan salah satu solusi berikut: