1. Pengantar
Dokumen ini mencantumkan persyaratan yang harus dipenuhi agar perangkat dapat digunakan agar kompatibel dengan Android 15.
Penggunaan kata "HARUS", "TIDAK BOLEH", "WAJIB", "TIDAK BOLEH", "TIDAK BOLEH", "Seharusnya", "TIDAK BOLEH", "DIREKOMENDASIKAN", "MEI", dan "OPSIONAL" sesuai dengan standar IETF didefinisikan dalam RFC2119.
Seperti yang digunakan dalam dokumen ini, "pengimplementasikan perangkat" atau "implementasi" adalah orang atau organisasi yang mengembangkan solusi hardware/software yang menjalankan Android 15. "Implementasi perangkat" atau "implementasi" adalah solusi perangkat keras/perangkat lunak yang dikembangkan.
Agar dianggap kompatibel dengan Android 15, perangkat implementasi HARUS memenuhi persyaratan yang disajikan dalam Kompatibilitas ini Definisi, termasuk dokumen apa pun yang disertakan melalui referensi.
Di mana definisi ini atau pengujian perangkat lunak yang dijelaskan dalam bagian 10 bersifat senyap, ambigu, atau tidak lengkap, maka implementasi perangkat menjadi tanggung jawab untuk memastikan kompatibilitas dengan implementasi yang ada.
Karena alasan ini, Proyek Open Source Android adalah referensi dan implementasi pilihan Android. Perangkat pelaksana DIREKOMENDASIKAN BANYAK untuk mendasarkan implementasi mereka pada sebanyak mungkin di "upstream" yang tersedia dari Project Open Source Android. Sementara beberapa komponen bisa secara hipotesis dengan implementasi alternatif, SANGAT DIREKOMENDASIKAN untuk tidak mengikuti praktik ini, karena lulus tes perangkat lunak akan menjadi akan lebih sulit. Tanggung jawab implementasi adalah memastikan kompatibilitas perilaku dengan implementasi Android standar, termasuk dan di luar Compatibility Test Suite. Terakhir, perhatikan bahwa komponen tertentu substitusi dan modifikasi secara eksplisit dilarang oleh dokumen ini.
Banyak sumber daya yang ditautkan dalam dokumen ini berasal secara langsung atau secara tidak langsung dari Android SDK dan secara fungsional akan lebih lanjut dalam dokumentasi SDK tersebut. Dalam keadaan apa pun ketika Kompatibilitas ini Definisi atau Compatibility Test Suite tidak setuju dengan SDK dokumentasi tambahan, dokumentasi SDK dianggap otoritatif. Semua hal teknis detail yang diberikan dalam referensi yang ditautkan di seluruh dokumen ini yang dipertimbangkan dengan penyertaan 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 dari Bagian 2 merupakan khusus untuk jenis perangkat tertentu.
Semua persyaratan lainnya, yang secara universal berlaku untuk perangkat Android apa pun penerapannya, tercantum di bagian setelah Bagian 2. Persyaratan ini disebut sebagai "Persyaratan Inti" dalam dokumen ini.
1.1.2. ID Persyaratan
ID persyaratan ditetapkan untuk persyaratan HARUS.
- ID ditetapkan hanya untuk persyaratan HARUS.
- Persyaratan yang SANGAT DIREKOMENDASIKAN ditandai sebagai [SR], tetapi ID tidak ditetapkan.
- ID terdiri dari : ID Jenis Perangkat - ID Kondisi - ID Persyaratan (misalnya C-0-1).
Setiap ID didefinisikan sebagai berikut:
- ID Jenis Perangkat (lihat selengkapnya di 2. Jenis Perangkat)
- C: Inti (Persyaratan yang diterapkan untuk semua implementasi perangkat Android)
- H: Perangkat Genggam Android
- T: Perangkat Android Television
- J: Implementasi Android Automotive
- W: Implementasi Android Watch
- Tab: Implementasi Tablet Android
- ID kondisi
- Jika persyaratannya tidak kondisional, ID ini ditetapkan sebagai 0.
- Jika persyaratan bersifat kondisional, 1 ditetapkan untuk yang pertama kondisi dan angka bertambah sebesar 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 Pasal 2
ID Persyaratan di Bagian 2 memiliki dua bagian. Yang pertama sesuai dengan ID bagian sebagaimana dijelaskan di atas. Bagian kedua mengidentifikasi {i>form factor<i} dan persyaratan khusus faktor bentuk.
ID bagian yang diikuti dengan ID Persyaratan yang dijelaskan di atas.
- ID di Bagian 2 terdiri dari : ID Bagian / ID Jenis Perangkat - ID Kondisi - ID Persyaratan (misalnya, 7.4.3/A-0-1).
2. Jenis Perangkat
Proyek Open Source Android menyediakan tumpukan software yang dapat digunakan untuk berbagai jenis perangkat dan faktor bentuk. Untuk mendukung keamanan di perangkat, tumpukan perangkat lunak, termasuk OS pengganti atau {i>kernel<i} alternatif diharapkan untuk dijalankan dalam lingkungan yang aman seperti yang dijelaskan di pasal 9 dan di bagian lain dalam CDD ini. Ada beberapa jenis perangkat yang memiliki ekosistem distribusi aplikasi yang relatif lebih baik.
Bagian ini menjelaskan jenis perangkat tersebut, serta persyaratan tambahan dan rekomendasi yang berlaku untuk setiap jenis perangkat.
Semua implementasi perangkat Android yang tidak sesuai dengan salah satu jenis perangkat HARUS memenuhi semua persyaratan di bagian lain dari Definisi Kompatibilitas.
2.1 Konfigurasi Perangkat
Untuk perbedaan utama dalam konfigurasi perangkat keras berdasarkan 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, telepon, atau tablet.
Implementasi perangkat Android diklasifikasikan sebagai Perangkat Genggam jika memenuhi semua kriteria berikut:
- Memiliki sumber listrik yang dapat memudahkan mobilitas, seperti baterai.
- Memiliki ukuran layar diagonal fisik dalam rentang 4 inci hingga 8 inci.
- Memiliki antarmuka input layar sentuh.
Persyaratan tambahan di bagian selanjutnya ini khusus untuk Android Implementasi perangkat genggam.
2.2.1. Hardware
Implementasi perangkat genggam:
- [7.1.1.1/H-0-1] HARUS memiliki minimal satu Layar yang kompatibel dengan Android dan berukuran setidaknya 2,2" di tepi pendek dan 3,4" di tepi panjang.
[7.1.1.3/H-SR-1] SANGAT DIREKOMENDASIKAN untuk memberi pengguna kemampuan untuk mengubah ukuran tampilan (kepadatan layar).
[7.1.1.1/H-0-2] HARUS mendukung komposisi GPU buffer grafis setidaknya sebesar resolusi tertinggi dari tampilan.
[7.1.1.1/H-0-3]* HARUS memetakan setiap
UI_MODE_NORMAL
tampilan yang disediakan untuk aplikasi pihak ketiga ke tampilan yang tidak terhalang area tampilan fisik setidaknya 2,2" inci pada tepi pendek dan 3,4" inci pada tepi panjang.[7.1.1.3/H-0-1]* HARUS menetapkan nilai
DENSITY_DEVICE_STABLE
menjadi 92% atau lebih besar dari kepadatan fisik yang sebenarnya tampilan yang sesuai.
Jika implementasi perangkat genggam menyertakan dukungan untuk Vulkan, implementasi tersebut:
- [7.1.4.2/H-1-1] HARUS memenuhi persyaratan ditentukan oleh profil Dasar Pengukuran Android 2021.
Jika implementasi perangkat genggam mengklaim dukungan untuk rentang dinamis tinggi
ditampilkan melalui Configuration.isScreenHdr()
,
mereka:
- [7.1.4.5/H-1-1] HARUS mengiklankan dukungan untuk
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
, ini:
- [7.1.4.6/H-1-1] HARUS melaporkan sebagai output protobuf yang sesuai dengan skema untuk penghitung GPU dan GPU rendertahap 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 counter trace GPU.
- [7.1.4.6/H-1-3] HARUS melaporkan nilai yang sesuai untuk RenderStages GPU perangkat dengan mengikuti proto paket rekaman aktivitas stage render.
- [7.1.4.6/H-1-4] HARUS melaporkan Frekuensi GPU tracepoint seperti yang ditentukan oleh format: power/gpu_frequency.
Implementasi perangkat genggam:
- [7.1.5/H-0-1] HARUS menyertakan dukungan untuk versi lama mode kompatibilitas aplikasi seperti yang diimplementasikan oleh Android versi hulu pada kode sumber Anda. Artinya, implementasi perangkat TIDAK BOLEH mengubah pemicu atau minimum tempat mode kompatibilitas diaktifkan, dan TIDAK BOLEH mengubah nilai perilaku mode kompatibilitas itu sendiri.
- [7.2.1/H-0-1] HARUS menyertakan dukungan untuk pihak ketiga Aplikasi Editor Metode Input (IME).
- [7.2.3/H-0-2] HARUS mengirim tombol normal dan tekan lama
peristiwa fungsi Kembali (
KEYCODE_BACK
) ke aplikasi latar depan. Peristiwa ini TIDAK BOLEH digunakan oleh sistem dan BISA dipicu oleh luar perangkat Android (mis. hardware eksternal keyboard yang terhubung ke perangkat Android). - [7.2.3/H-0-3] HARUS menyediakan fungsi Home di semua tampilan yang kompatibel dengan Android yang menyediakan layar beranda.
- [7.2.3/H-0-4] HARUS menyediakan fungsi Kembali pada semua tampilan yang kompatibel dengan Android dan fungsi Terbaru setidaknya pada salah satu layar yang kompatibel dengan Android.
- [7.2.4/H-0-1] HARUS mendukung input layar sentuh.
- [7.2.4/H-SR-1] SANGAT DIREKOMENDASIKAN untuk meluncurkan
aplikasi bantuan yang dipilih pengguna, dengan kata
lain aplikasi yang 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 DIREKOMENDASIKAN untuk menyertakan 3 sumbu akselerometer.
Jika implementasi perangkat genggam menyertakan akselerometer 3 sumbu, implementasi tersebut:
- [7.3.1/H-1-1] HARUS dapat melaporkan peristiwa hingga frekuensi minimal 100 Hz.
Jika implementasi perangkat genggam menyertakan penerima GPS/GNSS dan melaporkan
ke aplikasi melalui fitur android.hardware.location.gps
menandai, mereka:
- [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 pseudorange GNSS tarif, yang, dalam kondisi langit terbuka setelah menentukan lokasi, sementara diam atau bergerak dengan kecepatan kurang dari 0,2 meter per detik kuadrat dari untuk menghitung posisi dalam jarak 20 meter, dan kecepatan dalam 0,2 meter per detik, setidaknya 95% dari waktu.
Jika implementasi perangkat genggam menyertakan giroskop 3 sumbu, implementasi tersebut:
- [7.3.4/H-3-1] HARUS dapat melaporkan peristiwa hingga frekuensi minimal 100 Hz.
- [7.3.4/H-3-2] HARUS mampu mengukur perubahan orientasi hingga 1000 derajat per detik.
Implementasi perangkat genggam yang dapat melakukan panggilan suara dan menunjukkan
nilai apa pun selain PHONE_TYPE_NONE
di getPhoneType
:
- [7.3.8/H] SEHARUSNYA menyertakan sensor kedekatan.
Implementasi perangkat genggam:
- [7.3.11/H-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung sensor pose dengan 6 derajat kebebasan.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Jika perangkat mendukung protokol Wi-Fi Neighbor Awareness Networking (NAN) dengan
mendeklarasikan PackageManager.FEATURE_WIFI_AWARE
dan Lokasi Wi-Fi (Wi-Fi Putaran
Waktu Perjalanan — RTT) dengan mendeklarasikan PackageManager.FEATURE_WIFI_RTT
, lalu:
[7.4.2.5/H-1-1] HARUS melaporkan rentang secara akurat untuk dalam +/-1 meter pada bandwidth 160 MHz pada persentil ke-68 (sebagaimana dihitung dengan Fungsi Distribusi Kumulatif), +/-2 meter pada bandwidth 80 MHz pada persentil ke-68, +/-4 meter pada bandwidth 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 DIREKOMENDASIKAN untuk melaporkan rentang secara akurat dalam +/-1 meter pada bandwidth 160 MHz di 90th persentil (sebagaimana dihitung dengan Fungsi Distribusi Kumulatif), +/-2 meter pada bandwidth 80 MHz pada persentil ke-90, +/-4 meter pada 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 DIREKOMENDASIKAN untuk mengikuti langkah-langkah penyiapan pengukuran yang ditentukan dalam Kalibrasi Kehadiran.
Jika implementasi Perangkat genggam mendeklarasikan FEATURE_BLUETOOTH_LE
, implementasi tersebut:
- [7.4.3/H-1-3] HARUS mengukur dan mengompensasi Rx
offset untuk memastikan median BLE RSSI adalah -50dBm +/-15 dB pada jarak 1 m dari
perangkat referensi yang melakukan transmisi pada
ADVERTISE_TX_POWER_HIGH
. - [7.4.3/H-1-4] HARUS mengukur dan mengompensasi Tx
untuk memastikan median BLE RSSI adalah -50dBm +/-15 dB saat memindai dari
perangkat referensi diposisikan pada jarak 1 m dan mentransmisikan pada
ADVERTISE_TX_POWER_HIGH
.
Jika implementasi perangkat genggam menyertakan perangkat kamera logis yang mencantumkan
kemampuan menggunakan
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
,
mereka:
- [7.5.4/H-1-1] HARUS memiliki ruang pandang normal (FOV) secara default dan HARUS di antara 50 dan derajat.
Implementasi perangkat genggam:
- [7.6.1/H-0-1] HARUS memiliki minimal 4 GB penyimpanan non-volatil yang tersedia untuk data pribadi aplikasi (alias partisi "/data").
- [7.6.1/H-0-2] HARUS menampilkan "true" untuk
ActivityManager.isLowRamDevice()
jika memori kurang dari 1 GB yang tersedia untuk {i> kernel<i} dan {i>userspace<i}.
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 tampilan default menggunakan framebuffer resolusi hingga qHD (misalnya FWVGA).
[7.6.1/H-2-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 592 MB jika tampilan default menggunakan framebuffer resolusi hingga HD+ (misalnya, HD, WSVGA).
[7.6.1/H-3-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 896 MB jika tampilan default menggunakan framebuffer hingga FHD (misalnya WSXGA+).
[7.6.1/H-4-1] Memori yang tersedia untuk kernel dan ruang pengguna minimal HARUS 1344 MB jika tampilan default menggunakan resolusi framebuffer hingga QHD (misalnya QWXGA).
Jika implementasi perangkat genggam mendeklarasikan dukungan untuk ABI 64-bit (dengan atau tanpa ABI 32-bit):
[7.6.1/H-5-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS setidaknya 816 MB jika tampilan default menggunakan resolusi framebuffer ke qHD (misalnya FWVGA).
[7.6.1/H-6-1] Memori yang tersedia untuk kernel dan ruang pengguna minimal HARUS 944 MB jika tampilan default menggunakan resolusi framebuffer hingga HD+ (misalnya, HD, WSVGA).
[7.6.1/H-7-1] Memori yang tersedia untuk kernel dan ruang pengguna minimal HARUS 1.280 MB jika tampilan default menggunakan resolusi framebuffer hingga FHD (misalnya, WSXGA+).
[7.6.1/H-8-1] Memori yang tersedia untuk kernel dan ruang pengguna minimal HARUS 1824 MB jika tampilan default menggunakan resolusi framebuffer hingga QHD (misalnya, QWXGA).
Perhatikan bahwa "memori yang tersedia untuk kernel dan userspace" di atas mengacu pada ruang memori yang disediakan selain memori yang sudah didedikasikan untuk perangkat keras komponen seperti radio, video, dan sebagainya yang tidak berada di bawah mengontrol implementasi perangkat.
Jika implementasi perangkat genggam menyertakan memori kurang dari atau sama dengan 1 GB yang tersedia untuk {i>kernel<i} dan {i>userspace<i}, keduanya:
- [7.6.1/H-9-1] HARUS mendeklarasikan tombol fitur
android.hardware.ram.low
- [7.6.1/H-9-2] HARUS memiliki minimal 1,1 GB penyimpanan non-volatil untuk aplikasi data pribadi (alias partisi "/data").
Jika implementasi perangkat genggam menyertakan memori yang tersedia lebih dari 1 GB ke {i>kernel<i} dan {i>userspace<i}, mereka:
- [7.6.1/H-10-1] HARUS memiliki minimal 4 GB penyimpanan non-volatil tersedia untuk data pribadi aplikasi (alias partisi "/data").
- HARUS mendeklarasikan tombol fitur
android.hardware.ram.normal
.
Jika implementasi perangkat genggam mencakup lebih dari atau sama dengan 2 GB dan kurang dari 4 GB memori yang tersedia untuk {i>kernel<i} dan ruang pengguna, mereka:
- [7.6.1/H-SR-1] SANGAT DIREKOMENDASIKAN untuk hanya mendukung userspace 32-bit (aplikasi dan kode sistem)
Jika implementasi perangkat genggam menyertakan memori kurang dari 2 GB yang tersedia untuk {i>kernel<i} dan {i>userspace<i}, mereka:
- [7.6.1/H-1-1] hanya boleh mendukung ABI tunggal (baik 64-bit saja atau 32-bit saja).
Implementasi perangkat genggam:
- [7.6.2/H-0-1] TIDAK BOLEH menyediakan aplikasi penyimpanan bersama yang lebih kecil dari 1 GiB.
- [7.7.1/H] HARUS menyertakan port USB yang mendukung mode periferal.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Jika implementasi perangkat genggam menyertakan port USB
mendukung
dengan pengontrol yang beroperasi di
mode periferal:
- [7.7.1/H-1-1] HARUS menerapkan Android Open Accessory (AOA) Compute Engine API.
Mengakhiri persyaratan baru
Jika implementasi perangkat genggam menyertakan porta USB yang mendukung mode {i>host<i}, mereka:
- [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 performa persyaratan untuk mendukung mode VR dan menyertakan dukungan untuk mode tersebut, yaitu:
- [7.9.1/H-1-1] HARUS mendeklarasikan
Tombol fitur
android.hardware.vr.high_performance
. - [7.9.1/H-1-2] HARUS menyertakan aplikasi
menerapkan
android.service.vr.VrListenerService
yang dapat diaktifkan oleh VR aplikasi melaluiandroid.app.Activity#setVrModeEnabled
.
Jika implementasi perangkat genggam menyertakan satu atau beberapa port USB-C di host mode dan implementasi (class audio USB), selain persyaratan dalam pasal 7.7.2, ketentuan tersebut:
- [7.8.2.2/H-1-1] HARUS memberikan pemetaan software berikut dari kode HID:
Fungsi | Pemetaan | Konteks | Perilaku |
---|---|---|---|
A | Halaman penggunaan HID: 0x0C Penggunaan HID: 0x0CD Tombol kernel: KEY_PLAYPAUSE Kunci Android: KEYCODE_MEDIA_PLAY_PAUSE |
Pemutaran media | Input: Tekan singkat Output: Memutar atau menjeda |
Input: Tekan lama Output: Meluncurkan perintah suara Mengirim: android.speech.action.VOICE_SEARCH_HANDS_FREE jika perangkat
terkunci atau layarnya mati. Mengirim
android.speech.RecognizerIntent.ACTION_WEB_SEARCH sebaliknya |
|||
Panggilan masuk | Input: Tekan singkat Output: Terima panggilan |
||
Input: Tekan lama Output: Menolak panggilan |
|||
Panggilan sedang berlangsung | Input: Tekan singkat Output: Akhiri panggilan |
||
Input: Tekan lama Output: Membisukan atau membunyikan mikrofon |
|||
B | Halaman penggunaan HID: 0x0C Penggunaan HID: 0x0E9 Tombol kernel: KEY_VOLUMEUP Kunci Android: VOLUME_UP |
Pemutaran media, Panggilan sedang berlangsung | Input: Tekan pendek atau lama Output: Menaikkan volume sistem atau headset |
C | Halaman penggunaan HID: 0x0C Penggunaan HID: 0x0EA Tombol kernel: KEY_VOLUMEDOWN Kunci Android: VOLUME_DOWN |
Pemutaran media, Panggilan sedang berlangsung | Input: Tekan pendek atau lama Output: Menurunkan volume sistem atau headset |
D | Halaman penggunaan HID: 0x0C Penggunaan HID: 0x0CF Tombol kernel: KEY_VOICECOMMAND Kunci Android: KEYCODE_VOICE_ASSIST |
Semua. Dapat dipicu dalam keadaan apa pun. | Input: Tekan pendek atau lama Output: Meluncurkan perintah suara |
- [7.8.2.2/H-1-2] HARUS memicu ACTION_HEADSET_PLUG ke steker, tetapi hanya setelah antarmuka dan ujung audio USB memiliki telah disebutkan dengan benar untuk mengidentifikasi jenis terminal yang terhubung.
Saat terminal audio USB jenis 0x0302 terdeteksi, terminal tersebut akan:
- [7.8.2.2/H-2-1] HARUS menyiarkan Intent ACTION_HEADSET_PLUG dengan "mikrofon" ekstra ditetapkan ke 0.
Saat terminal audio USB jenis 0x0402 terdeteksi, terminal tersebut akan:
- [7.8.2.2/H-3-1] HARUS menyiarkan Intent ACTION_HEADSET_PLUG dengan "mikrofon" ekstra ditetapkan ke 1.
Saat API AudioManager.getDevices() dipanggil saat periferal USB dipanggil terhubung, mereka:
[7.8.2.2/H-4-1] HARUS mencantumkan perangkat jenis AudioDeviceInfo.TYPE_USB_HEADSET dan peran
isSink()
jika isian tipe terminal audio USB adalah 0x0302.[7.8.2.2/H-4-2] HARUS mencantumkan jenis perangkat AudioDeviceInfo.TYPE_USB_HEADSET dan peran
isSink()
jika terminal audio USB isian adalah 0x0402.[7.8.2.2/H-4-3] HARUS mencantumkan jenis perangkat AudioDeviceInfo.TYPE_USB_HEADSET dan peran
isSource()
jika terminal audio USB isian adalah 0x0402.[7.8.2.2/H-4-4] HARUS mencantumkan perangkat jenis AudioDeviceInfo.TYPE_USB_DEVICE dan peran
isSink()
jika isian tipe terminal audio USB adalah 0x603.[7.8.2.2/H-4-5] HARUS mencantumkan jenis perangkat AudioDeviceInfo.TYPE_USB_DEVICE dan peran
isSource()
jika terminal audio USB isian adalah 0x604.[7.8.2.2/H-4-6] HARUS mencantumkan jenis perangkat AudioDeviceInfo.TYPE_USB_DEVICE dan peran
isSink()
jika jenis terminal audio USB adalah 0x400.[7.8.2.2/H-4-7] HARUS mencantumkan jenis perangkat AudioDeviceInfo.TYPE_USB_DEVICE dan peran
isSource()
jika terminal audio USB isian adalah 0x400.[7.8.2.2/H-SR-1] SANGAT DIREKOMENDASIKAN saat menghubungkan periferal audio USB-C, untuk melakukan enumerasi deskriptor USB, mengidentifikasi jenis terminal dan Intent siaran ACTION_HEADSET_PLUG dalam waktu kurang dari 1.000 milidetik.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Jika
Untuk
Implementasi perangkat genggam
yang mendeklarasikan
android.hardware.audio.output
dan android.hardware.microphone
,
mereka:
lihat persyaratan RTL dan TTL di bagian
5,6.
[5.6/H-1-1] HARUS memiliki Perjalanan bolak-balik Berkelanjutan Rata-rata latensi 300 md atau kurang dari 5 pengukuran, dengan Deviasi Absolut Rata-rata kurang dari 30 md, lebih 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 dari 300 md atau kurang dari minimal 5 pengukuran di atas speaker ke jalur data mikrofon.
Mengakhiri persyaratan baru
Aktuator resonansi linier (LRA) adalah sistem pegas bermassa tunggal yang memiliki frekuensi resonan dominan di mana massa diterjemahkan ke arah {i>motion <i}yang diinginkan.
Jika implementasi Perangkat genggam menyertakan setidaknya satu tujuan umum 7.10 aktuator resonansi linear, fungsi ini:
[7.10/H] HARUS menempatkan aktuator di dekat lokasi tempat perangkat biasanya dipegang atau disentuh dengan tangan.
[7,10/J] HARUS memindahkan aktuator haptic ke sumbu X (kiri-kanan) orientasi alami perangkat.
Jika implementasi perangkat genggam memiliki tujuan umum aktuator haptic, yaitu aktuator resonansi linear sumbu X (LRA), mereka:
- [7,10/J] SEHARUSNYA memiliki frekuensi resonansi LRA sumbu X di bawah 200 Hz.
Jika implementasi perangkat genggam mengikuti pemetaan konstanta haptic, implementasi tersebut:
- [7.10/H]* HARUS memverifikasi status penerapan dengan menjalankan android.os.Vibrator.areAllEffectsSupported() dan android.os.Vibrator.arePrimitivesSupported() Google Cloud Platform.
[7.10/H]* HARUS melakukan penilaian kualitas untuk konstanta haptic.
[7.10/H]* HARUS memverifikasi dan mengupdate jika perlu penggantian untuk primitif yang tidak didukung seperti yang dijelaskan dalam panduan penerapan untuk konstanta.
2.2.2. Multimedia
Implementasi perangkat genggam HARUS mendukung encoding audio berikut dan format dekode dan menyediakannya untuk aplikasi pihak ketiga:
- [5.1/H-0-1] AMR-NB
- [5,1/H-0-2] AMR-WB
- [5.1/H-0-3] Profil AAC MPEG-4 (AAC LC)
- [5.1/H-0-4] Profil MPEG-4 HE AAC (AAC+)
- [5.1/H-0-5] AAC ELD (Peningkatan AAC penundaan rendah)
Implementasi perangkat genggam HARUS mendukung encoding video berikut dan menyediakannya untuk aplikasi pihak ketiga:
Implementasi perangkat genggam HARUS mendukung decoding video berikut dan menyediakannya untuk aplikasi pihak ketiga:
- [5,3/H-0-1] AVC H.264
- [5,3/H-0-2] HEVC H.265
- [5,3/H-0-3] MPEG-4 SP
- [5,3/H-0-4] VP8
- [5,3/H-0-5] VP9
- [5,3/H-0-6] AV1
2.2.3. Software
Implementasi perangkat genggam:
- [3.2.3.1/H-0-1] HARUS memiliki
aplikasi yang menangani
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 dengan menggunakanDocumentsProvider
API. - [3.2.3.1/H-0-2]* HARUS melakukan pramuat satu atau lebih aplikasi atau komponen layanan dengan pengendali intent, untuk semua pola filter intent publik yang ditentukan oleh aplikasi berikut intent yang tercantum di sini.
- [3.2.3.1/H-SR-1] SANGAT DIREKOMENDASIKAN untuk melakukan pramuat aplikasi email yang dapat menangani ACTION_SENDTO atau ACTION_SEND atau ACTION_SEND_MULTIPLE untuk mengirim email.
- [3.4.1/H-0-1] HARUS memberikan
implementasi API
android.webkit.Webview
. - [3.4.2/H-0-1] HARUS menyertakan Browser mandiri aplikasi untuk penjelajahan web pengguna umum.
- [3.8.1/H-SR-1] SANGAT DIREKOMENDASIKAN untuk menerapkan peluncur default yang mendukung penyematan pintasan dalam aplikasi, widget dan widgetFeatures.
- [3.8.1/H-SR-2] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan peluncur default yang menyediakan akses cepat ke pintasan yang disediakan oleh aplikasi pihak ketiga melalui ShortcutManager Compute Engine API.
- [3.8.1/H-SR-3] SANGAT DIREKOMENDASIKAN untuk menyertakan aplikasi peluncur default yang menampilkan badge untuk ikon aplikasi.
- [3.8.2/H-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung widget aplikasi pihak ketiga.
- [3.8.3/H-0-1] HARUS mengizinkan pihak ketiga
aplikasi untuk memberi tahu pengguna tentang peristiwa penting melalui
Notification
danNotificationManager
semua class API. - [3.8.3/H-0-2] HARUS mendukung konfigurasi notifikasi.
- [3.8.3/H-0-3] HARUS mendukung peringatan dini notifikasi.
- [3.8.3/H-0-4] HARUS menyertakan menu notifikasi, yang memberi pengguna kemampuan untuk mengontrol secara langsung (mis. balas, tunda, tutup, blokir) notifikasi melalui kemampuan pengguna seperti tombol tindakan atau panel kontrol seperti yang diimplementasikan dalam AOSP.
- [3.8.3/H-0-5] HARUS menampilkan pilihan
disediakan melalui
RemoteInput.Builder setChoices()
di menu notifikasi. - [3.8.3/H-SR-1] SANGAT DIREKOMENDASIKAN
untuk menampilkan pilihan pertama yang disediakan melalui
RemoteInput.Builder setChoices()
di bayangan notifikasi tanpa interaksi pengguna tambahan. - [3.8.3/H-SR-2] SANGAT DIREKOMENDASIKAN
untuk menampilkan semua pilihan yang disediakan di
RemoteInput.Builder setChoices()
di menu notifikasi ketika pengguna meluaskan semua notifikasi di menu notifikasi. - [3.8.3.1/H-SR-1] SANGAT DIREKOMENDASIKAN
untuk menampilkan tindakan untuk
Notification.Action.Builder.setContextual
yang ditetapkan sebagaitrue
sebaris dengan balasan yang ditampilkan olehNotification.Remoteinput.Builder.setChoices
. - [3.8.4/H-SR-1] SANGAT DIREKOMENDASIKAN untuk menerapkan asisten di perangkat guna menangani tindakan Bantuan.
Jika penerapan perangkat genggam mendukung notifikasi MediaStyle mereka:
- [3.8.3.1/H-SR-2] SANGAT DIREKOMENDASIKAN
untuk menyediakan kemampuan pengguna (misalnya, pengalih {i>output<i}) yang diakses dari
UI sistem yang memungkinkan pengguna beralih di antara media yang tersedia
(misalnya, perangkat Bluetooth dan rute yang disediakan untuk
MediaRouter2Manager
) saat aplikasi memposting notifikasiMediaStyle
dengan tokenMediaSession
.
Jika implementasi perangkat menyertakan tombol navigasi fungsi terbaru sebagai yang dijelaskan di bagian 7.2.3 mengubah antarmuka, yaitu:
- [3.8.3/H-1-1] HARUS menerapkan layar perilaku penyematan dan menyediakan menu setelan kepada pengguna untuk aplikasi baru.
Jika implementasi Perangkat genggam mendukung tindakan Assist, implementasi tersebut:
- [3.8.4/H-SR-2] SANGAT DIREKOMENDASIKAN
untuk menggunakan tekan lama pada tombol
HOME
sebagai interaksi yang ditentukan untuk meluncurkan aplikasi bantuan seperti yang dijelaskan dalam bagian 7.2.3. HARUS diluncurkan aplikasi bantuan yang dipilih pengguna, dengan kata lain aplikasi yang mengimplementasikanVoiceInteractionService
, atau aktivitas yang menangani intentACTION_ASSIST
.
Jika penerapan Perangkat genggam mendukung conversation notifications
lalu mengelompokkannya ke dalam bagian terpisah
dari peringatan dan non-percakapan senyap
notifikasi, mereka:
- [3.8.4/H-1-1]* HARUS menampilkan notifikasi percakapan sebelum notifikasi non-percakapan dengan pengecualian notifikasi layanan latar depan yang sedang berlangsung dan nilai penting:tinggi notifikasi.
Jika implementasi perangkat Genggam Android mendukung layar kunci, implementasi tersebut:
- [3.8.10/H-1-1] HARUS menampilkan Kunci termasuk {i>Media Notification Template<i}.
Jika implementasi perangkat genggam mendukung layar kunci yang aman, implementasi tersebut:
- [3.9/H-1-1] HARUS mengimplementasikan rangkaian lengkap administrasi perangkat kebijakan yang ditentukan dalam dokumentasi Android SDK.
Jika implementasi Perangkat genggam menyertakan dukungan untuk
ControlsProviderService
dan Control
API dan memungkinkan aplikasi pihak ketiga memublikasikan kontrol perangkat, kemudian aplikasi tersebut:
- [3.8.16/H-1-1] HARUS mendeklarasikan fitur
laporkan
android.software.controls
dan menyetelnya ketrue
. - [3.8.16/H-1-2] HARUS memberikan pengguna
keterjangkauan dengan kemampuan untuk menambah, mengedit, memilih, dan mengoperasikan
kontrol perangkat favorit dari kontrol yang didaftarkan oleh pihak ketiga
aplikasi melalui
ControlsProviderService
danControl
Google Cloud Platform. - [3.8.16/H-1-3] HARUS memberikan akses ke kemampuan pengguna ini dalam tiga interaksi dari Peluncur default.
[3.8.16/H-1-4] HARUS merender secara akurat dalam hal ini, pengguna memberi nama dan ikon setiap aplikasi pihak ketiga yang menyediakan kontrol melalui
ControlsProviderService
serta kolom tertentu yang disediakan olehControl
Google Cloud Platform.[3.8.16/H-1-5] HARUS memberikan pengguna kemampuan untuk memilih tidak menggunakan kontrol perangkat auth-trivial yang ditetapkan aplikasi dari kontrol yang didaftarkan oleh aplikasi pihak ketiga melalui
ControlsProviderService
danControl
Control.isAuthRequired
API.[3.8.16/H-1-6] Implementasi perangkat HARUS secara akurat merender kemampuan pengguna sebagai berikut:
- Jika perangkat telah menetapkan
config_supportsMultiWindow=true
dan aplikasi mendeklarasikan metadataMETA_DATA_PANEL_ACTIVITY
diControlsProviderService
deklarasi, termasuk ComponentName dari yang valid (sebagaimana didefinisikan oleh API), aplikasi HARUS menyematkan kata kunci tersebut aktivitas dalam kemampuan pengguna ini. - Jika aplikasi tidak mendeklarasikan metadata
META_DATA_PANEL_ACTIVITY
, maka harus merender bidang yang ditentukan seperti yang disediakan olehControlsProviderService
serta kolom tertentu yang disediakan oleh Kontrol API.
- Jika perangkat telah menetapkan
[3.8.16/H-1-7] Jika aplikasi mendeklarasikan metadata
META_DATA_PANEL_ACTIVITY
, Ini HARUS melewati nilai dari pengaturan yang ditentukan dalam [3.8.16/H-1-5] menggunakanEXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS
saat meluncurkan aktivitas tersemat.
Sebaliknya, jika implementasi perangkat genggam tidak menerapkan kontrol tersebut, mereka:
- [3.8.16/H-2-1] HARUS melaporkan
null
untukControlsProviderService
danControl
Google Cloud Platform. - [3.8.16/H-2-2] HARUS mendeklarasikan fitur
laporkan
android.software.controls
dan menyetelnya kefalse
.
Jika implementasi perangkat genggam tidak berjalan dalam mode kunci tugas, saat konten disalin ke papan klip, implementasi tersebut:
- [3.8.17/H-1-1] HARUS memberikan konfirmasi kepada pengguna bahwa data telah disalin ke papan klip (misalnya, thumbnail atau notifikasi "Konten disalin"). Selain itu, sertakan indikasi apakah data papan klip akan disinkronkan di sini lintas perangkat.
Implementasi perangkat genggam:
- [3.10/H-0-1] HARUS mendukung aksesibilitas pihak ketiga layanan IT perusahaan mereka.
- [3.10/H-SR-1] SANGAT DIREKOMENDASIKAN untuk melakukan pramuat layanan aksesibilitas pada perangkat yang sebanding dengan atau melebihi fungsi Tombol Akses dan TalkBack (untuk bahasa yang didukung oleh Layanan aksesibilitas mesin text-to-speech) seperti yang disediakan di bagian talkback open project sumber.
- [3.11/H-0-1] HARUS mendukung penginstalan mesin TTS pihak ketiga.
- [3.11/H-SR-1] SANGAT DIREKOMENDASIKAN untuk menyertakan Mesin TTS mendukung bahasa yang tersedia di perangkat.
- [3.13/H-SR-1] SANGAT DIREKOMENDASIKAN untuk menyertakan Komponen UI Setelan Cepat.
Jika implementasi perangkat genggam Android mendeklarasikan FEATURE_BLUETOOTH
atau
Dukungan FEATURE_WIFI
, mereka:
- [3.16/H-1-1] HARUS mendukung penyambungan perangkat pendamping aplikasi baru.
Jika fungsi navigasi disediakan sebagai tindakan berbasis gestur di layar:
- [7.2.3/H] Zona pengenalan gestur untuk Beranda fungsi SEHARUSNYA tidak lebih tinggi dari 32 dp dari bagian bawah layar.
Jika implementasi perangkat genggam menyediakan fungsi navigasi sebagai gestur dari mana saja di tepi kiri dan kanan layar:
- [7.2.3/H-0-1] Area gestur fungsi navigasi Lebarnya HARUS kurang dari 40 dp di setiap sisi. Area {i>gesture <i}HARUS Lebar 24 dp secara default.
Jika implementasi perangkat genggam mendukung layar kunci yang aman dan memiliki dari atau sama dengan 2 GB memori yang tersedia untuk kernel dan userspace, keduanya:
- [3.9/H-1-2] HARUS menyatakan dukungan profil terkelola melalui
Tombol fitur
android.software.managed_users
.
Jika implementasi perangkat genggam Android mendeklarasikan dukungan untuk kamera melalui
android.hardware.camera.any
mereka:
- [7.5.4/H-1-1] HARUS menghormati
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 menghormati
android.media.action.VIDEO_CAMERA
untuk meluncurkan kamera dalam mode video seperti yang dijelaskan dalam SDK.
Jika aplikasi setelan pada implementasi perangkat mengimplementasikan fungsi pemisahan, menggunakan penyematan aktivitas, maka mereka:
- [3.2.3.1/ H-1-1] HARUS memiliki aktivitas yang menangani
Intent Settings#ACTION_SETTINGS_Setting_DEEP_LINK_ACTIVITY saat fungsi pemisahan aktif. Aktivitas HARUS dilindungi oleh
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
dan HARUS memulai aktivitas Intent yang diuraikan dari Setelan#EXTRA_SETTINGS_SettingDED_DEEP_LINK_INTENT_URI.
Jika implementasi perangkat memungkinkan pengguna melakukan panggilan dalam bentuk apa pun,
- [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.
2.2.4. Performa dan Kekuatan
- [8.1/H-0-1] Latensi frame yang konsisten. Latensi frame yang tidak konsisten atau penundaan untuk merender frame TIDAK BOLEH terjadi lebih sering lebih dari 5 frame dalam satu detik, dan HARUS di bawah 1 frame dalam satu detik.
- [8.1/H-0-2] Latensi antarmuka pengguna. Implementasi perangkat HARUS memastikan pengalaman pengguna berlatensi rendah dengan men-scroll daftar berisi 10 ribu entri daftar seperti yang ditentukan oleh Compatibility Test Suite Android (CTS) dalam waktu kurang dari 36 detik.
- [8.1/H-0-3] Pengalihan tugas. Kapan beberapa aplikasi telah diluncurkan, meluncurkan kembali aplikasi yang sudah berjalan aplikasi setelah diluncurkan HARUS membutuhkan waktu kurang dari 1 detik.
Implementasi perangkat genggam:
- [8.2/H-0-1] HARUS memastikan bahwa performa operasi tulis minimal 5 MB/dtk.
- [8.2/H-0-2] HARUS memastikan penulisan acak memiliki performa minimal 0,5 MB/dtk.
- [8.2/H-0-3] HARUS memastikan pembacaan berurutan berperforma tinggi setidaknya 15 MB/dtk.
- [8.2/H-0-4] HARUS memastikan pembacaan acak performa minimum 3,5 MB/dtk.
Apakah implementasi Perangkat genggam menyertakan fitur untuk meningkatkan daya perangkat manajemen proyek yang disertakan dalam AOSP atau memperluas fitur yang disertakan di 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 memberikan profil daya per komponen yang menentukan nilai konsumsi saat ini untuk setiap komponen perangkat keras dan perkiraan pengurasan baterai yang disebabkan oleh dari waktu ke waktu seperti yang didokumentasikan di situs Proyek Open Source Android.
- [8.4/H-0-2] HARUS melaporkan semua daya nilai konsumsi dalam miliampere jam (mAh).
- [8.4/H-0-3] HARUS melaporkan daya CPU
konsumsi per UID setiap proses. Proyek Open Source Android memenuhi
persyaratan melalui implementasi modul kernel
uid_cputime
. - [8.4/H-0-4] HARUS membuat penggunaan daya ini
tersedia melalui
adb shell dumpsys batterystats
perintah shell kepada developer aplikasi. - [8.4/J] SEHARUSNYA diatribusikan dengan komponen perangkat keras itu sendiri jika tidak dapat mengatribusikan penggunaan daya komponen perangkat keras pada aplikasi.
Jika implementasi perangkat genggam menyertakan output layar atau video, implementasi tersebut:
- [8.4/H-1-1] HARUS menghormati
android.intent.action.POWER_USAGE_SUMMARY
dan menampilkan menu pengaturan yang menunjukkan penggunaan daya ini.
Implementasi perangkat genggam:
[8.5/H-0-1] HARUS menyediakan kemampuan pengguna untuk melihat semua aplikasi dengan layanan latar depan yang aktif atau pekerjaan yang dimulai oleh pengguna, termasuk durasi masing-masing layanan ini karena dimulai seperti yang dijelaskan dalam dokumen SDK.
[8.5/H-0-2]HARUS memberikan kemampuan pengguna untuk menghentikan aplikasi yang menjalankan layanan latar depan atau tugas yang dimulai oleh pengguna.
2.2.5. Model Keamanan
Implementasi perangkat genggam:
- [9/H-0-1] HARUS mendeklarasikan
android.hardware.security.model.compatible
aplikasi baru. - [9.1/H-0-1] HARUS mengizinkan aplikasi pihak ketiga untuk mengakses
statistik penggunaan melalui izin
android.permission.PACKAGE_USAGE_STATS
dan menyediakan mekanisme yang dapat diakses pengguna untuk memberi atau mencabut akses ke aplikasi tersebut sebagai respons terhadapandroid.settings.ACTION_USAGE_ACCESS_SETTINGS
intent.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Implementasi perangkat HARUS mendeklarasikan dukungan untuk
android.software.credentials
dan:
[9/H-0-2] HARUS mematuhi intent
android.settings.CREDENTIAL_PROVIDER
untuk mengizinkan pemilihan penyedia pilihan bagi Pengelola Kredensial. Penyedia ini akan diaktifkan untuk Isi Otomatis dan juga akan menjadi lokasi default untuk menyimpan kredensial baru dimasukkan melalui {i>Credential Manager<i}.[9/H-0-3] HARUS mendukung setidaknya 2 penyedia kredensial serentak dan memberikan kemampuan pengguna di aplikasi Setelan untuk mengaktifkan atau menonaktifkan penyedia.
Mengakhiri persyaratan baru
Jika implementasi perangkat mendeklarasikan dukungan untuk android.hardware.telephony
,
mereka:
- [9.5/H-1-1] TIDAK BOLEH menyetel
UserManager.isHeadlessSystemUserMode
ketrue
.
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 RSA, AES, ECDSA, dan algoritma kriptografi HMAC serta keluarga MD5, SHA-1, dan SHA-2 fungsi hash untuk mendukung sistem Android Keystore yang didukung di area tertentu yang diisolasi secara aman dari kode yang berjalan di {i>kernel<i} dan yang lebih tinggi. Isolasi aman HARUS memblokir semua mekanisme potensial di mana kode {i>kernel<i} atau {i>userspace<i} dapat mengakses status internal lingkungan yang terisolasi, termasuk DMA. Open Source Android upstream Project (AOSP) memenuhi persyaratan ini dengan menggunakan implementasi Trusty, tetapi Solusi berbasis ARM TrustZone atau solusi aman yang ditinjau oleh pihak ketiga implementasi isolasi berbasis hypervisor yang tepat adalah alternatif lainnya.
- [9.11/H-0-4] HARUS menjalankan layar kunci otentikasi di lingkungan eksekusi yang terisolasi dan hanya ketika berhasil, kunci yang terikat otentikasi dapat digunakan. Layar kunci kredensial HARUS disimpan dengan cara yang hanya memungkinkan eksekusi yang terisolasi lingkungan untuk melakukan otentikasi layar kunci. Android upstream Project Open Source menyediakan Gatekeeper Hardware Abstraksi Layer (HAL) dan Trusty, yang dapat digunakan untuk memenuhi persyaratan ini.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
[9.11/H-0-5] HARUS mendukung pengesahan kunci jika penandatanganan pengesahan dilindungi oleh perangkat keras yang aman dan penandatanganan yang dapat dijalankan dengan perangkat keras yang aman. Kunci penandatanganan pengesahan HARUS
dibagikan ke seluruh jumlah perangkat yang cukup besar untuk mencegah kuncidicegah tidak digunakan sebagai permanen 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, tersebut MUNGKIN digunakan untuk setiap 100.000 unit.
Mengakhiri persyaratan baru
Perhatikan bahwa jika implementasi perangkat sudah diluncurkan di Android versi sebelumnya
versi, perangkat tersebut dikecualikan dari persyaratan untuk memiliki keystore
didukung oleh lingkungan eksekusi yang terisolasi
dan mendukung pengesahan kunci,
kecuali jika mendeklarasikan fitur android.hardware.fingerprint
yang memerlukan
keystore yang didukung oleh lingkungan eksekusi yang terisolasi.
Jika implementasi Perangkat genggam mendukung layar kunci yang aman, implementasi tersebut:
- [9.11/H-1-1] HARUS mengizinkan pengguna memilih format terpendek waktu tunggu tidur, yaitu waktu transisi dari mode tidak terkunci ke terkunci status, sebagai 15 detik atau kurang.
- [9.11/H-1-2] HARUS memberikan kemampuan pengguna untuk disembunyikan notifikasi dan menonaktifkan semua bentuk otentikasi kecuali untuk otentikasi utama seperti yang dijelaskan di 9.11.1 Layar Kunci Aman. AOSP memenuhi persyaratan sebagai mode kunci total.
Jika implementasi perangkat memiliki layar kunci yang aman dan menyertakan satu atau beberapa trust agent, yang mengimplementasikan TrustAgentService
System API, implementasi tersebut:
- [9.11.1/H-1-1] HARUS menantang pengguna untuk salah satu metode autentikasi utama yang direkomendasikan (misalnya: PIN, pola, sandi) lebih sering dari sekali setiap 72 jam.
Jika implementasi perangkat genggam
mencakup beberapa pengguna dan
tidak mendeklarasikan tombol fitur android.hardware.telephony
, flag tersebut:
- [9.5/H-2-1] HARUS mendukung profil yang dibatasi, fitur yang memungkinkan pemilik perangkat mengelola pengguna tambahan dan pada perangkat. Dengan profil yang dibatasi, pemilik perangkat dapat mengatur lingkungan terpisah dengan cepat bagi pengguna tambahan untuk bekerja, dengan kemampuan untuk mengelola batasan yang lebih terperinci di aplikasi yang yang tersedia di lingkungan tersebut.
Jika implementasi perangkat genggam
mencakup beberapa pengguna dan
mendeklarasikan tombol fitur android.hardware.telephony
, yaitu:
- [9.5/H-3-1] TIDAK BOLEH mendukung dibatasi profil tetapi HARUS selaras dengan implementasi kontrol AOSP untuk mengaktifkan /menonaktifkan pengguna lain agar tidak dapat mengakses panggilan suara dan SMS.
Jika implementasi Perangkat genggam menetapkan UserManager.isHeadlessSystemUserMode
ke true
, mereka
- [9.5/H-4-1] TIDAK BOLEH menyertakan dukungan untuk eUICC, maupun eSIM dengan kemampuan panggilan.
- [9.5/H-4-2] TIDAK BOLEH menyatakan dukungan untuk
android.hardware.telephony
.
Android, melalui System API VoiceInteractionService mendukung mekanisme untuk deteksi frasa pengaktif selalu aktif tanpa indikasi akses mikrofon dan deteksi kueri yang selalu aktif, tanpa mikrofon atau kamera indikasi akses.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Setelan dibatasi
Setelan yang Dibatasi memberi pengguna peringatan yang terlihat dan meminta konfirmasi pengguna untuk memberikan izin untuk setiap aplikasi yang:
- Diinstal setelah didownload melalui aplikasi
(misalnya, aplikasi pesan atau browser) selain
"app store" aplikasi yang diidentifikasi oleh
PackageManager
sebagaiPACKAGE_DOWNLOADED_FILE
. - Sedang diinstal dari file lokal
(misalnya, aplikasi di-sideload)
diidentifikasi oleh
PackageManager
sebagaiPACKAGE_SOURCE_LOCAL_FILE
.
Untuk setiap Izin yang Diterapkan dan ID terkaitnya yang tercantum di bawah ini:
- Alarm dan pengingat:
AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
- Akses semua file:
AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
- Tampilkan di atas aplikasi lain:
AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
- Instal aplikasi yang tidak dikenal:
AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
- Kelola media:
AppOpsManager.OPSTR_MANAGE_MEDIA
- Ubah setelan sistem:
AppOpsManager.OPSTR_WRITE_SETTINGS
- Picture-in-picture:
AppOpsManager.OPSTR_PICTURE_IN_PICTURE
- Aktifkan layar:
AppOpsManager.OPSTR_TURN_SCREEN_ON
- Notifikasi layar penuh:
AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
- Kontrol Wi-Fi:
AppOpsManager.OPSTR_CHANGE_WIFI_STATE
- Aksesibilitas:
AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
- Pemroses notifikasi:
AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
- Akses penggunaan:
AppOpsManager.OPSTR_GET_USAGE_STATS
- Admin perangkat:
Manifest.permission.BIND_DEVICE_ADMIN
- Jangan ganggu:
Manifest.permission.MANAGE_NOTIFICATIONS
Aplikasi tersebut diberi label "Aplikasi yang Tercakup" untuk persyaratan yang tercantum di bagian ini.
Implementasi perangkat:
[9.8/H-0-1] HARUS menerapkan Setelan Terbatas seperti yang diuraikan di atas untuk hal berikut:
- Izin khusus
- Aksesibilitas (
AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
) - Pemroses notifikasi (
AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
) - Aplikasi admin perangkat (
Manifest.permission.BIND_DEVICE_ADMIN
) - Tampilkan di atas aplikasi lain (
AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
) - Akses penggunaan (
AppOpsManager.OPSTR_GET_USAGE_STATS
)
- Aksesibilitas (
- Peran (Aplikasi default)
- Telepon (
RoleManager.ROLE_DIALER
) - SMS (
RoleManager.ROLE_SMS
)
- Telepon (
- Izin runtime
- Runtime SMS (
Manifest.permission_group.SMS
)
- Runtime SMS (
- Izin khusus
[9,8/H-0-2] HARUS mengaktifkan Setelan Terbatas sebagai default dan SANGAT DIREKOMENDASIKAN untuk tidak memiliki keterjangkauan pengguna yang memungkinkan pengguna untuk menonaktifkan Setelan Terbatas untuk semua aplikasi.
[9,8/H-0-3] HARUS memastikan konfirmasi pengguna untuk setiap Aplikasi yang Tercakup sebelum Izin Diterapkan yang Diberlakukan dapat diberikan.
[9,8/H-0-4] Hanya boleh mengonfirmasi pengguna untuk mengaktifkan pengaturan terbatas yang akan diperoleh dari halaman AppInfo Aplikasi yang Tercakup, menggunakan EnhancedConfirmationManager API.
[9.8/H-0-5] SANGAT DIREKOMENDASIKAN untuk berintegrasi dengan dan memanggil EnhancedConfirmationManager untuk semua izin khusus, untuk menentukan secara dinamis apakah setelan tersebut merupakan setelan yang dibatasi.
- Alarm dan pengingat:
AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
- Akses semua file:
AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
- Tampilkan di atas aplikasi lain:
AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
- Instal aplikasi yang tidak dikenal:
AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
- Kelola media:
AppOpsManager.OPSTR_MANAGE_MEDIA
- Ubah setelan sistem:
AppOpsManager.OPSTR_WRITE_SETTINGS
- Picture-in-picture:
AppOpsManager.OPSTR_PICTURE_IN_PICTURE
- Aktifkan layar:
AppOpsManager.OPSTR_TURN_SCREEN_ON
- Notifikasi layar penuh:
AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
- Kontrol Wi-Fi:
AppOpsManager.OPSTR_CHANGE_WIFI_STATE
- Aksesibilitas:
AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
- Pemroses notifikasi:
AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
- Akses penggunaan:
AppOpsManager.OPSTR_GET_USAGE_STATS
- Admin perangkat:
Manifest.permission.BIND_DEVICE_ADMIN
- Jangan ganggu:
Manifest.permission.MANAGE_NOTIFICATIONS
- Alarm dan pengingat:
Mengakhiri persyaratan baru
Jika implementasi perangkat genggam mendukung System API
HotwordDetectionService
atau mekanisme lainnya untuk mendeteksi frasa pengaktif tanpa
indikasi akses mikrofon, mereka:
- [9,8/H-1-1] HARUS memastikan bahwa layanan deteksi frasa pengaktif hanya dapat mentransmisikan
ke Sistem,
ContentCaptureService
, atau layanan pengenalan ucapan di perangkat yang dibuat olehSpeechRecognizer#createOnDeviceSpeechRecognizer()
. - [9,8/H-1-2] HARUS memastikan bahwa layanan deteksi frasa pengaktif hanya dapat mentransmisikan
data audio mikrofon atau data yang berasal
darinya ke server sistem melalui
HotwordDetectionService
API, atau keContentCaptureService
melalui APIContentCaptureManager
. - [9.8/H-1-3] TIDAK BOLEH memberikan audio mikrofon yang berdurasi lebih dari 30 detik untuk permintaan yang dipicu perangkat keras individu ke layanan deteksi {i>hotword<i}.
- [9.8/H-1-4] TIDAK BOLEH memberikan audio mikrofon buffer yang lebih lama dari 8 detik untuk permintaan individu ke layanan deteksi frasa pengaktif.
- [9.8/H-1-5] TIDAK BOLEH memberikan 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 (tidak termasuk streaming audio) dikirim keluar dari layanan deteksi frasa pengaktif pada setiap hasil frasa pengaktif.
- [9,8/H-1-7] TIDAK BOLEH mengizinkan lebih dari 5 bit data dikirimkan keluar layanan deteksi frasa pengaktif pada setiap hasil frasa pengaktif negatif.
- [9,8/H-1-8] HARUS hanya mengizinkan transmisi data dari frasa pengaktif deteksi pada permintaan validasi kata cepat dari server sistem.
- [9,8/H-1-9] TIDAK BOLEH mengizinkan aplikasi yang dapat diinstal pengguna menyediakan layanan deteksi frasa pengaktif.
- [9.8/H-1-10] TIDAK BOLEH muncul di UI data kuantitatif tentang penggunaan mikrofon oleh layanan deteksi frasa pengaktif.
- [9.8/H-1-11] HARUS mencatat jumlah byte yang disertakan dalam setiap transmisi dari layanan deteksi frasa pengaktif untuk memungkinkan pemeriksaan keamanan peneliti.
- [9.8/H-1-12] HARUS mendukung mode debug yang mencatat log konten mentah dari setiap transmisi dari layanan pendeteksian frasa pengaktif untuk memungkinkan pemeriksaan peneliti keamanan.
[9.8/H-1-14] HARUS menampilkan indikator mikrofon, seperti yang dijelaskan di bagian 9.8.2, jika hasil frasa pengaktif yang berhasil dikirimkan ke suara layanan interaksi atau entitas serupa.
[9.8/H-1-15] HARUS memastikan bahwa streaming audio yang disediakan pada frasa pengaktif yang berhasil hasil ditransmisikan secara satu arah dari layanan pendeteksi kata cepat layanan interaksi suara.
[9.8/H-SR-1] SANGAT DIREKOMENDASIKAN untuk memberi tahu pengguna sebelum mengatur aplikasi sebagai penyedia layanan deteksi frasa pengaktif.
[9.8/H-SR-2] SANGAT DIREKOMENDASIKAN untuk melarang transmisi data tidak terstruktur dari layanan deteksi frasa pengaktif.
[9.8/H-SR-3] SANGAT DIREKOMENDASIKAN untuk memulai kembali proses {i>hosting<i} layanan deteksi frasa pengaktif setidaknya sekali setiap jam atau setiap 30 peristiwa pemicu perangkat keras, mana saja yang lebih dulu.
Jika implementasi perangkat menyertakan aplikasi yang menggunakan System API
HotwordDetectionService
, atau mekanisme serupa untuk deteksi frasa pengaktif tanpa
indikasi penggunaan mikrofon, aplikasi:
- [9.8/H-2-1] HARUS memberikan pemberitahuan eksplisit kepada pengguna untuk setiap frasa frasa pengaktif didukung.
- [9,8/H-2-2] TIDAK BOLEH mempertahankan data audio mentah, atau data yang berasal darinya, melalui layanan deteksi frasa pengaktif.
- [9.8/H-2-3] TIDAK BOLEH mentransmisikan dari layanan deteksi frasa pengaktif, audio
data yang dapat digunakan untuk merekonstruksi (seluruh atau sebagian) audio,
atau audio yang tidak terkait dengan frasa pengaktif itu sendiri, kecuali
ContentCaptureService
atau ucapan di perangkat pengenalan objek.
Jika implementasi perangkat genggam mendukung System API
VisualQueryDetectionService
atau mekanisme lainnya untuk deteksi kueri
tanpa indikasi akses mikrofon dan/atau kamera, mereka:
- [9,8/H-3-1] HARUS memastikan layanan deteksi kueri hanya dapat mengirimkan
ke Sistem, atau
ContentCaptureService
, atau ucapan di perangkat pengenalan layanan (yang dibuat olehSpeechRecognizer#createOnDeviceSpeechRecognizer()
). - [9.8/H-3-2] TIDAK BOLEH mengizinkan informasi audio atau video apa pun dikirimkan
dari
VisualQueryDetectionService
, kecuali hinggaContentCaptureService
atau layanan pengenalan ucapan di perangkat. - [9,8/H-3-3] HARUS menampilkan pemberitahuan pengguna di UI Sistem saat perangkat mendeteksi pengguna niat untuk berinteraksi dengan Aplikasi Asisten Digital (mis.dengan mendeteksi kehadiran pengguna melalui kamera).
- [9,8/H-3-4] HARUS menampilkan indikator mikrofon dan menampilkan kueri pengguna di UI tepat setelah kueri pengguna terdeteksi.
- [9,8/H-3-5] TIDAK BOLEH mengizinkan aplikasi yang dapat diinstal pengguna menyediakan layanan deteksi kueri visual.
Jika implementasi Perangkat genggam mendeklarasikan android.hardware.microphone
, implementasi tersebut:
- [9.8.2/H-4-1] HARUS menampilkan indikator mikrofon saat
sebuah aplikasi mengakses data audio dari mikrofon, tetapi tidak ketika
mikrofon hanya dapat 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 Terbaru dan Aktif
aplikasi yang menggunakan mikrofon seperti yang ditampilkan
PermissionManager.getIndicatorAppOpUsageData()
, bersama dengan atribusi apa pun pesan yang terkait dengannya. - [9.8.2/H-4-3] TIDAK BOLEH menyembunyikan indikator mikrofon untuk aplikasi sistem yang memiliki antarmuka pengguna yang terlihat atau interaksi pengguna langsung.
- [9.8.2/H-4-4] HARUS menampilkan daftar Terbaru dan Aktif
aplikasi yang menggunakan mikrofon seperti yang ditampilkan dari
PermissionManager.getIndicatorAppOpUsageData()
, beserta pesan atribusi apa pun yang terkait.
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 digunakan diakses oleh aplikasi yang memiliki peran yang disebutkan di bagian 9.1 dengan ID CDD [C-4-X].
- [9.8.2/H-5-2] HARUS menampilkan aplikasi Terbaru dan Aktif menggunakan
kamera seperti yang ditampilkan dari
PermissionManager.getIndicatorAppOpUsageData()
, beserta pesan atribusi apa pun yang terkait. - [9.8.2/H-5-3] TIDAK BOLEH menyembunyikan indikator kamera untuk aplikasi sistem yang memiliki antarmuka pengguna yang terlihat atau interaksi pengguna langsung.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Booting Terverifikasi adalah fitur yang memastikan integritas software perangkat. Jika implementasi perangkat mendukung fitur tersebut, implementasi tersebut:
- [9.10/H-1-1] HARUS memverifikasi semua partisi hanya baca yang terpasang selama urutan booting Android, dan harus menyertakan semua partisi terverifikasi ini dalam penghitungannya.
Mengakhiri persyaratan baru
2.2.6. Kompatibilitas Opsi dan Developer Tools
Implementasi perangkat genggam (* Tidak berlaku untuk Tablet):
- [6.1/H-0-1]* HARUS mendukung perintah shell
cmd testharness
.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Implementasi perangkat genggam (* Tidak berlaku untuk Tablet):
- Perfetto
- [6.1/H-0-2]
*HARUS mengekspos/system/bin/perfetto
biner ke pengguna {i>shell<i} yang sesuai dengan {i>cmdline<i} dokumentasi perfetto. - [6,1/H-0-3]
*Biner perfetto HARUS menerima sebagai memasukkan konfigurasi protobuf yang sesuai dengan skema yang ditentukan dalam dokumentasi perfetto. - [6,1/H-0-4]
*Biner perfetto HARUS menulis sebagai membuat output trace protobuf yang sesuai dengan skema yang ditentukan dalam dokumentasi perfetto. - [6,1/H-0-5]
*HARUS menyediakan, melalui perfetto biner, setidaknya sumber data yang dijelaskan dalam dokumentasi perfetto. - [6,1/H-0-6]
*Daemon yang dilacak perfetto HARUS diaktifkan secara default (properti sistempersist.traced.enable
).
- [6.1/H-0-2]
Mengakhiri persyaratan baru
2.2.7. Kelas Performa Media Genggam
Lihat Bagian 7.11 untuk definisi class performa media tersebut.
2.2.7.1. Media
Jika implementasi Perangkat genggam menampilkan android.os.Build.VERSION_CODES.U
untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, iklan tersebut:
- HARUS memenuhi persyaratan media yang tercantum di Android 14 CDD bagian 2.2.7.1.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Jika implementasi Perangkat genggam menampilkan
android.os.Build.VERSION_CODES.V
untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, tombol tersebut:
Mengakhiri persyaratan baru
- [5.1/H-1-1] HARUS mengiklankan jumlah maksimum hardware video decoder
sesi yang dapat dijalankan secara bersamaan dalam
kombinasi codec apa pun melalui
CodecCapabilities.getMaxSupportedInstances()
dan MetodeVideoCapabilities.getSupportedPerformancePoints()
.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [5.1/H-1-2] HARUS mendukung 6 instance decoder video hardware 8-bit (SDR) sesi (AVC, HEVC, VP9, AV1, atau yang lebih baru) dalam kombinasi codec apa pun yang berjalan serentak dengan 3 sesi pada resolusi 1080p@30 fps dan 3 sesi pada resolusi 4k resolusi@30 fps, kecuali AV1. Untuk semua sesi, TIDAK BOLEH ada lebih dari 1 frame menurun per detik. Codec AV1 hanya diperlukan untuk mendukung resolusi 1080p, tetapi tetap harus mendukung 6 instance pada 1080p30fps.
Mengakhiri persyaratan baru
- [5.1/H-1-3] HARUS mengiklankan jumlah maksimum encoder video hardware
sesi yang dapat dijalankan secara bersamaan dalam
kombinasi codec apa pun melalui
CodecCapabilities.getMaxSupportedInstances()
dan MetodeVideoCapabilities.getSupportedPerformancePoints()
.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [5.1/H-1-4] HARUS mendukung 6 instance encoder video hardware 8-bit (SDR) sesi (AVC, HEVC, VP9, AV1, atau yang lebih baru) dalam kombinasi codec apa pun yang berjalan serentak dengan 4 sesi pada resolusi 1080p@30 fps dan 2 sesi pada resolusi 4k resolusi@30 fps, kecuali AV1. Untuk semua sesi, TIDAK BOLEH ada lebih dari 1 frame menurun per detik. Codec AV1 hanya diperlukan untuk mendukung resolusi 1080p, tetapi yang diperlukan untuk mendukung 6 instance pada 1080p30 fps.
Mengakhiri persyaratan baru
- [5.1/H-1-5] HARUS mengiklankan jumlah maksimum hardware video encoder dan
sesi decoder yang dapat dijalankan serentak dalam kombinasi codec apa pun melalui
CodecCapabilities.getMaxSupportedInstances()
dan MetodeVideoCapabilities.getSupportedPerformancePoints()
.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [5.1/H-1-6] HARUS mendukung 6 instance decoder video hardware 8-bit (SDR) sesi encoder video hardware (AVC, HEVC, VP9, AV1, atau yang lebih baru) dalam kombinasi codec berjalan bersamaan dengan 3 sesi pada 4K@30fps resolusi (kecuali AV1), dengan maksimal 2 sesi encoder dan 3 sesi pada resolusi 1080p. Untuk semua sesi, TIDAK BOLEH ada lebih dari 1 frame menurun per detik. Codec AV1 hanya diperlukan untuk mendukung resolusi 1080p, tetapi yang diperlukan untuk mendukung 6 instance pada 1080p30 fps.
Mengakhiri persyaratan baru
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [5.1/H-1-19] HARUS mendukung 3 instance decoder video hardware 10-bit (HDR) sesi encoder video hardware (AVC, HEVC, VP9, AV1, atau yang lebih baru) dalam kombinasi codec berjalan serentak pada resolusi 4K@30fps (kecuali AV1) di mana maksimal 1 di antaranya adalah sesi encoder, yang dapat dikonfigurasi di Format input RGBA_1010102 melalui permukaan GL. Untuk semua sesi, TIDAK BOLEH ada lebih dari 1 frame yang diturunkan per kedua. Pembuatan metadata HDR oleh encoder tidak diperlukan jika encoding dari permukaan GL. Sesi codec AV1 hanya diperlukan untuk mendukung resolusi 1080p meskipun persyaratan ini memanggil untuk resolusi 4K.
Mengakhiri persyaratan baru
- [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 dengan beban. Muat di sini didefinisikan sebagai video 1080p hingga 720p serentak sesi transcoding menggunakan codec video hardware bersama dengan 1080p inisialisasi perekaman audio-video. Untuk codec Dolby Vision, codec latensi inisialisasi 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 dengan beban. Muat di sini didefinisikan sebagai video 1080p hingga 720p serentak sesi transcoding menggunakan codec video hardware bersama dengan 1080p inisialisasi perekaman audio-video.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [5.1/H-1-9] HARUS mendukung 2 instance decoder video hardware aman sesi (AVC, HEVC, VP9, AV1, atau yang lebih baru) dalam kombinasi codec apa pun yang berjalan secara bersamaan pada resolusi 4k@30 fps (kecuali AV1) untuk 8-bit (SDR) dan Konten HDR 10 bit. Untuk semua sesi, TIDAK BOLEH ada lebih dari 1 frame menurun per detik. Sesi codec AV1 hanya diperlukan untuk mendukung resolusi 1080p bahkan saat persyaratan ini memerlukan resolusi 4K.
Mengakhiri persyaratan baru
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [5.1/H-1-10] HARUS mendukung 3 instance decoder video hardware yang tidak aman sesi bersama dengan 1 instance sesi decoder video hardware aman (total 4 instance) (AVC, HEVC, VP9, AV1, atau yang lebih baru) dalam kombinasi codec apa pun berjalan serentak dengan 3 sesi pada resolusi 4K@30 fps (kecuali AV1) yang mencakup satu sesi decoder aman dan 1 sesi nn-secure pada resolusi 1080p @30 fps dengan maksimal 2 sesi dalam HDR 10-bit. Untuk semua sesi, TIDAK BOLEH ada lebih dari 1 frame menurun per detik. Sesi codec AV1 hanya diperlukan untuk mendukung resolusi 1080p bahkan saat persyaratan ini memerlukan resolusi 4K.
Mengakhiri persyaratan baru
- [5.1/H-1-11] HARUS mendukung decoder aman untuk setiap perangkat keras AVC, HEVC, VP9, atau decoder AV1 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 dalam keadaan termuat. Muatan di sini didefinisikan sebagai 1080p hingga 720p serentak sesi transcoding video saja menggunakan codec video hardware bersama dengan Inisialisasi pemutaran audio-video 1080p. Untuk codec Dolby Vision, codec latensi inisialisasi HARUS 50 md atau kurang.
- [5.1/H-1-13] HARUS memiliki latensi inisialisasi codec 30 md atau kurang untuk Sesi dekode audio dengan kecepatan bit 128 kbps atau lebih rendah untuk semua dekoder audio saat dengan beban. Muat di sini didefinisikan sebagai video 1080p hingga 720p serentak sesi transcoding menggunakan codec video hardware bersama dengan 1080p inisialisasi pemutaran audio-video.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [5.1/H-1-14] HARUS mendukung decoder hardware AV1 Main 10, Level 4.1
dan film graindengan efek film grain pada komposisi GPU.
Mengakhiri persyaratan baru
- [5.1/H-1-15] HARUS memiliki setidaknya 1 hardware video decoder yang mendukung 4K60.
- [5.1/H-1-16] HARUS memiliki minimal 1 encoder video hardware yang mendukung 4K60.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [5.1/H-1-21] HARUS mendukung
FEATURE_DynamicColorAspect
untuk semua video hardware decoder (AVC, HEVC, VP9, AV1, atau yang lebih baru). Catatan: Ini berarti aplikasi dapat memperbarui aspek warna konten video selama sesi decoding. Decoder yang mendukung konten 10-bit dan 8-bit HARUS mendukung secara dinamis beralih antara konten 8- dan 10-bit dalam mode Surface. Decoder yang mendukung Fungsi transfer HDR HARUS mendukung peralihan secara dinamis antara SDR dan HDR saat ini.
Mengakhiri persyaratan baru
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [5.1/H-1-22] HARUS mendukung encoding, decoding, pengeditan GPU, dan menampilkan video konten dalam rasio aspek potret, terlepas dari metadata rotasi untuk terbesar yang didukung Kamera atau 4K mana yang lebih kecil. Catatan: ini menyertakan profil HDR jika codec mendukung HDR. Codec AV1 hanya diperlukan untuk mendukung resolusi 1080p. Persyaratan ini hanya untuk codec hardware, GPU dan DPU.
Mengakhiri persyaratan baru
- [5.3/H-1-1] TIDAK BOLEH menjatuhkan lebih dari 1 frame dalam 10 detik (yaitu, kurang dari 0,167 persen penurunan frame) untuk sesi video 4K 60 fps saat dimuat.
- [5.3/H-1-2] TIDAK BOLEH menjatuhkan lebih dari 1 frame dalam 10 detik selama video ditayangkan perubahan resolusi dalam sesi video 60 fps saat dimuat untuk sesi 4K.
- [5.6/H-1-1] HARUS memiliki latensi ketuk-ke-nada 80 milidetik atau kurang menggunakan uji ketuk-to-tone CTS Verifier.
- [5.6/H-1-2] HARUS memiliki latensi audio bolak-balik 80 milidetik atau kurang dari setidaknya satu jalur data yang didukung.
- [5.6/H-1-3] HARUS mendukung audio >= 24-bit untuk output stereo dengan volume lebih dari 3,5 mm
colokan jika ada dan melalui audio USB jika didukung di seluruh data
untuk konfigurasi streaming dan latensi rendah. Untuk latensi rendah
tertentu, AAudio harus digunakan oleh aplikasi dalam callback berlatensi rendah
mode. Untuk konfigurasi streaming, Java AudioTrack harus digunakan oleh
aplikasi. Dalam konfigurasi latensi rendah dan streaming, HAL
sink output akan 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.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [5.6/H-1-4] HARUS mendukung perangkat audio USB >= 4 saluran.
(Ini digunakan oleh pengontrol DJ untuk melihat pratinjau lagu.)
Mengakhiri persyaratan baru
- [5.6/H-1-5] HARUS mendukung perangkat MIDI yang sesuai untuk kelas dan mendeklarasikan Tombol fitur MIDI.
- [5.6/H-1-9] HARUS mendukung setidaknya 12 pencampuran saluran. Hal ini menyiratkan kemampuan untuk membuka AudioTrack dengan topeng saluran 7.1.4 dan spasial atau downmix semua saluran ke stereo.
- [5.6/H-SR] SANGAT DIREKOMENDASIKAN untuk mendukung pencampuran 24 saluran dengan setidaknya mendukung masker saluran 9.1.6 dan 22.2.
- [5.7/H-1-2] HARUS mendukung
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL
dengan di bawah kemampuan dekripsi konten.
Ukuran sampel minimum | 4 MiB |
Jumlah Minimum Subsampel - H264 atau HEVC | 32 |
Jumlah Minimum Subsampel - VP9 | 9 |
Jumlah Minimum Subsampel - AV1 | 288 |
Ukuran buffer subsampel minimum | 1 MiB |
Ukuran buffer kripto umum minimum | 500 KiB |
Jumlah Minimum sesi serentak | 30 |
Jumlah minimum kunci per sesi | 20 |
Jumlah Total Kunci Minimum (semua sesi) | 80 |
Jumlah Total Minimum Kunci DRM (semua sesi) | 6 |
Ukuran Pesan | 16 KiB |
Frame yang Didekripsi per Detik | 60 fps |
- [5.1/H-1-17] HARUS memiliki minimal 1 decoder gambar hardware yang mendukung AVIF Profil Dasar Pengukuran.
- [5.1/H-1-18] HARUS mendukung encoder AV1 yang dapat mengenkode hingga 480p dengan resolusi 30 fps dan 1 Mbps.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [5.1/H-1-20] HARUS mendukung
Feature_HdrEditing
untuk semua encoder AV1 dan HEVC hardware yang ada di perangkat pada resolusi 4K atau resolusi terbesar yang didukung Kamera, mana saja yang lebih kecil.
Mengakhiri persyaratan baru
- [5.12/H-SR] Sangat Disarankan untuk mendukung
Feature_HdrEditing
untuk semua hardware AV1 dan encoder HEVC yang ada pada perangkat. - [5.12/H-1-2] HARUS mendukung format warna RGBA_1010102 untuk semua perangkat keras AV1 dan Encoder HEVC yang ada di perangkat.
- [5.12/H-1-3] HARUS mengiklankan dukungan untuk ekstensi EXT_YUV_target guna sampel dari tekstur YUV dalam 8 dan 10-bit.
- [7.1.4/H-1-1] HARUS memiliki minimal 6 overlay hardware dalam mode Display (DPU), dengan setidaknya 2 di antaranya mampu menampilkan konten video 10-bit.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Jika implementasi Perangkat genggam menampilkan
android.os.Build.VERSION_CODES.V
untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
dan menyertakan
untuk encoder hardware AVC atau HEVC, mereka:
Mengakhiri persyaratan baru
- [5.2/H-2-1] HARUS memenuhi target kualitas minimum yang ditentukan oleh video kurva distorsi laju encoder untuk codec AVC dan HEVC hardware, seperti yang Menjalankan Pengujian Performa Class 14 (PC14)-Pengujian Kualitas encoding video (VEQ).
2.2.7.2. Kamera
Jika implementasi Perangkat genggam menampilkan android.os.Build.VERSION_CODES.U
untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, iklan tersebut:
- HARUS memenuhi persyaratan media yang tercantum di Android 14 CDD bagian 2.2.7.2.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Jika implementasi Perangkat genggam menampilkan
android.os.Build.VERSION_CODES.V
untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, tombol tersebut:
Mengakhiri persyaratan baru
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [7.5/H-1-1] HARUS memiliki kamera belakang utama dengan resolusi setidaknya 12 megapiksel, yang mendukung perekaman video 4k@30fps, 1080p@60fps, dan 720p@60fps. Kamera belakang utama adalah kamera belakang dengan ID kamera terendah.
Mengakhiri persyaratan baru
- [7.5/H-1-2] HARUS memiliki kamera depan utama dengan resolusi sebesar memiliki resolusi minimal 6 megapiksel dan mendukung pengambilan video dengan resolusi 1080p@30 fps. Utama kamera depan adalah kamera depan dengan ID kamera terendah.
- [7.5/H-1-3] HARUS mendukung properti
android.info.supportedHardwareLevel
sebagaiFULL
atau lebih baik untuk primer belakang danLIMITED
atau lebih baik untuk primer depan kamera. - [7.5/H-1-4] HARUS mendukung
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME
untuk kedua kampanye utama kamera. - [7.5/H-1-5] HARUS memiliki latensi pengambilan JPEG camera2 < 1.000 md untuk resolusi 1080p yang diukur oleh kamera CTS di bawah Kondisi pencahayaan ITS (3000K) untuk kedua kamera utama.
- [7.5/H-1-6] HARUS memiliki latensi pengaktifan kamera2 (buka kamera ke pratinjau pertama bingkai) < 500 md yang diukur dengan PerformanceTest kamera CTS di bawah ITS kondisi pencahayaan (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 hadap belakang yang mendukung 720p atau 1080p @ 240fps.
- [7.5/H-1-10] HARUS memiliki min ZOOM_RATIO < 1.0 untuk kamera utama jika ada adalah kamera RGB ultrawide yang menghadap ke arah yang sama.
- [7.5/H-1-11] HARUS mengimplementasikan streaming front-back serentak di kamera.
- [7.5/H-1-12] HARUS mendukung
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
untuk kedua kampanye utama kamera depan dan belakang utama. - [7.5/H-1-13] HARUS mendukung kemampuan
LOGICAL_MULTI_CAMERA
untuk kamera belakang utama jika terdapat lebih dari 1 RGB kamera. - [7.5/H-1-14] HARUS mendukung kemampuan
STREAM_USE_CASE
untuk kamera depan dan belakang utama. - [7.5/H-1-15] HARUS mendukung Ekstensi mode malam melalui ekstensi CameraX dan Camera2 untuk kamera utama kamera.
- [7.5/H-1-16] HARUS mendukung kemampuan DYNAMIC_RANGE_TEN_BIT untuk kamera.
- [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.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [7.5/H-1-18] HARUS mendukung
JPEG_R
untuk bagian belakang utama dan kamera depan utama. - [7.5/H-1-19] HARUS mendukung
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
untuk HLG10 1080p pratinjau dengan JPEG rasio aspek 16:9 maksimum, dan untuk pratinjau HLG10 720p dengan kombinasi streaming JPEG dengan rasio aspek 16:9 maksimum untuk kamera belakang. - [7.5/H-1-20] Secara default, output
JPEG_R
untuk output utama harus kamera depan utama dan belakang di aplikasi kamera native.
Mengakhiri persyaratan baru
2.2.7.3. Hardware
Jika implementasi Perangkat genggam menampilkan android.os.Build.VERSION_CODES.U
untuk
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, mereka:
- HARUS memenuhi persyaratan media yang tercantum di Android 14 CDD bagian 2.2.7.3.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Jika implementasi Perangkat genggam menampilkan
android.os.Build.VERSION_CODES.V
untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, tombol tersebut:
Mengakhiri persyaratan baru
- [7.1.1.1/H-2-1] HARUS memiliki resolusi layar minimal 1080p.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [7.1.1.3/H-2-1] HARUS memiliki kepadatan layar minimal 400 dpi jika lebar layar perangkat < 600 dp.
Mengakhiri persyaratan baru
- [7.1.1.3/H-3-1] HARUS memiliki layar HDR yang mendukung setidaknya 1.000 nit rata-rata.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [7.6.1/H-2-1] HARUS memiliki memori fisik minimal 8 GB,
dengan setidaknya 6,64 GB tersedia untuk {i>kernel<i} seperti yang dilaporkan oleh
android.app.ActivityManager.MemoryInfo.totalMem
.
Mengakhiri persyaratan baru
2.2.7.4. Performa
Jika implementasi Perangkat genggam menampilkan android.os.Build.VERSION_CODES.U
untuk
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, mereka:
- HARUS memenuhi persyaratan performa yang tercantum di Android 14 CDD bagian 2.2.7.4.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Jika implementasi Perangkat genggam menampilkan
android.os.Build.VERSION_CODES.V
untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, tombol tersebut:
Mengakhiri persyaratan baru
- [8.2/H-1-1] HARUS memastikan performa operasi tulis berurutan setidaknya 150 MB/dtk.
- [8.2/H-1-2] HARUS memastikan performa penulisan acak setidaknya 10 MB/dtk.
- [8.2/H-1-3] HARUS memastikan performa baca berurutan setidaknya 250 MB/dtk.
- [8.2/H-1-4] HARUS memastikan performa baca acak setidaknya 100 MB/dtk.
- [8.2/H-1-5] HARUS memastikan performa baca dan tulis berurutan paralel dengan performa 2x baca dan 1x tulis dengan performa minimal 50 MB/dtk.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
2.2.7.5. Grafik
Jika implementasi Perangkat genggam menampilkan android.os.Build.VERSION_CODES.V
untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, iklan tersebut:
- [7.1.4.1/S-1-1] Persyaratan ini dibatalkan dari Android 15 (eksperimen AOSP).
- [7.1.4.1/H-1-2] HARUS mendukung
EGL_IMG_context_priority
danEGL_EXT_protected_content
ekstensi. - [7.1.4.1/H-1-3] HARUS mendukung
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory
danVK_KHR_global_priority
.
Mengakhiri persyaratan baru
2.3. Persyaratan Televisi
Perangkat Android Television mengacu pada implementasi perangkat Android yang adalah antarmuka hiburan untuk menikmati media digital, film, {i>game<i}, aplikasi, dan/atau TV live untuk pengguna yang duduk sekitar sepuluh kaki ("lean back" atau "10-kaki antarmuka pengguna").
Implementasi perangkat Android diklasifikasikan sebagai Televisi jika memenuhi semua kriteria berikut:
- Telah menyediakan mekanisme untuk mengontrol antarmuka pengguna yang dirender dari jarak jauh layar yang mungkin diletakkan sepuluh kaki dari pengguna.
- Memiliki tampilan layar tersemat dengan panjang diagonal lebih besar dari 24 inci ATAU menyertakan porta {i>output<i} video, seperti VGA, HDMI, DisplayPort, atau porta nirkabel untuk display.
Persyaratan tambahan di bagian selanjutnya ini khusus untuk Android Implementasi perangkat televisi.
2.3.1. Hardware
Implementasi perangkat televisi:
- [7.2.2/T-0-1] HARUS mendukung D-pad.
- [7.2.3/T-0-1] HARUS menyediakan Beranda dan Kembali fungsi-fungsi lainnya.
- [7.2.3/T-0-2] HARUS mengirim tombol normal dan tekan lama
peristiwa fungsi Kembali (
KEYCODE_BACK
) ke aplikasi latar depan. - [7.2.6.1/T-0-1] HARUS menyertakan dukungan untuk game
pengontrol dan mendeklarasikan tombol fitur
android.hardware.gamepad
. - [7.2.7/T] HARUS menyediakan remote control yang bisa digunakan pengguna dapat mengakses navigasi non-sentuh dan input tombol navigasi inti.
Jika implementasi perangkat Televisi menyertakan giroskop 3 sumbu, implementasi tersebut:
- [7.3.4/T-1-1] HARUS dapat melaporkan peristiwa hingga dengan frekuensi setidaknya 100 Hz.
- [7.3.4/T-1-2] HARUS mampu mengukur perubahan orientasi hingga 1000 derajat per detik.
Implementasi perangkat televisi:
- [7.4.3/T-0-1] HARUS mendukung Bluetooth dan Bluetooth LE.
- [7.6.1/T-0-1] HARUS memiliki minimal 4 GB penyimpanan non-volatil yang tersedia untuk data pribadi aplikasi (alias partisi "/data").
Jika implementasi perangkat Televisi menyertakan porta USB yang mendukung mode {i>host<i}, mereka:
- [7.5.3/T-1-1] HARUS menyertakan dukungan untuk kamera eksternal yang terhubung melalui porta USB ini tetapi tidak selalu terhubung.
Jika implementasi perangkat TV adalah 32-bit:
[7.6.1/T-1-1] Memori yang tersedia untuk kernel dan userspace HARUS berukuran minimal 896 MB jika salah satu dari kepadatan berikut digunakan:
- 400 dpi atau lebih tinggi pada layar kecil/normal
- xhdpi atau lebih tinggi di perangkat layar besar
- tvdpi atau lebih tinggi di layar ekstra besar
Jika implementasi perangkat TV adalah 64-bit:
[7.6.1/T-2-1] Memori yang tersedia untuk kernel dan ruang pengguna minimal HARUS 1.280 MB jika salah satu dari kepadatan berikut digunakan:
- 400 dpi atau lebih tinggi pada layar kecil/normal
- xhdpi atau lebih tinggi di perangkat layar besar
- tvdpi atau lebih tinggi di layar ekstra besar
Perhatikan bahwa "memori yang tersedia untuk kernel dan userspace" di atas mengacu pada ruang memori yang disediakan selain memori yang sudah khusus untuk komponen perangkat keras seperti radio, video, dan sebagainya yang tidak di bawah kontrol {i>kernel<i} pada implementasi perangkat.
Implementasi perangkat televisi:
- [7.8.1/T] HARUS menyertakan mikrofon.
- [7.8.2/T-0-1] HARUS memiliki output audio dan mendeklarasikan
android.hardware.audio.output
.
2.3.2. Multimedia
Implementasi perangkat televisi HARUS mendukung encoding audio berikut dan decoding formatnya serta menyediakannya untuk aplikasi pihak ketiga:
- [5.1/T-0-1] Profil AAC MPEG-4 (AAC LC)
- [5.1/T-0-2] Profil MPEG-4 HE AAC (AAC+)
- [5.1/T-0-3] AAC ELD (AAC penundaan rendah yang ditingkatkan)
Implementasi perangkat televisi HARUS mendukung encoding video berikut dan menyediakannya untuk aplikasi pihak ketiga:
Implementasi perangkat televisi:
- [5.2.2/T-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung Pengkodean H.264 untuk video beresolusi 720p dan 1080p dengan kecepatan 30 frame per detik.
Implementasi perangkat televisi HARUS mendukung decoding video berikut dan menyediakannya untuk aplikasi pihak ketiga:
- [5.3.3/T-0-1] MPEG-4 SP
- [5.3.4/T-0-2] AVC H.264
- [5.3.5/T-0-3] HEVC H.265
- [5.3.6/T-0-4] VP8
- [5.3.7/T-0-5] VP9
- [5.3.1/T-0-6] MPEG-2
- [5.3.2/T-0-7] AV1
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 Profil Utama Tingkat Tinggi.
- [5.3.1/T-1-2] HD 1080i dengan 59,94 frame per detik dengan Profil Utama Tingkat Tinggi. Keduanya HARUS menguraikan video MPEG-2 yang bertautan dan menyediakannya untuk aplikasi pihak ketiga.
Implementasi perangkat televisi HARUS mendukung dekode H.264, seperti yang dijelaskan di Bagian 5.3.4, pada kecepatan frame dan resolusi video standar hingga dan termasuk:
- [5.3.4/T-1-1] HD 1080p dengan 60 frame per detik dengan Profil Dasar Pengukuran
- [5.3.4/T-1-2] HD 1080p dengan 60 frame per detik dengan Profil Utama
- [5.3.4/T-1-3] HD 1080p dengan 60 frame per detik dengan Profil Tinggi Level 4.2
Implementasi perangkat televisi dengan decoder hardware H.265 HARUS mendukung Dekode H.265, sebagaimana diuraikan dalam Bagian 5.3.5, pada kecepatan frame video standar dan resolusi hingga dan termasuk:
- [5.3.5/T-1-1] HD 1080p dengan 60 frame per detik dengan Profil Utama Level 4.1
Jika implementasi perangkat Televisi dengan decoder hardware H.265 mendukung Dekode H.265 dan profil decoding UHD, keduanya:
- [5.3.5/T-2-1] HARUS mendukung profil decoding UHD pada 60 frame per detik dengan profil Tingkat Utama Main10 Level 5
Implementasi perangkat televisi HARUS mendukung decoding 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] HD 1080p dengan profil decoding 60 frame per detik
Implementasi perangkat televisi dengan decoder hardware VP9 HARUS mendukung VP9 seperti yang dijelaskan dalam Pasal 5.3.7, pada kecepatan frame video standar dan hingga dan termasuk:
- [5.3.7/T-1-1] HD 1080p dengan 60 frame per detik dengan profil 0 (kedalaman warna 8 bit)
Jika implementasi perangkat Televisi dengan decoder hardware VP9 mendukung VP9 decoding dan profil decoding UHD, keduanya:
- [5.3.7/T-2-1] HARUS mendukung profil decoding UHD pada 60 frame per detik dengan profil 0 (kedalaman warna 8 bit).
- [5.3.7/T-SR1] SANGAT DIREKOMENDASIKAN untuk mendukung Profil decoding UHD pada 60 frame per detik dengan profil 2 (kedalaman warna 10 bit).
Implementasi perangkat televisi:
- [5.5/T-0-1] HARUS menyertakan dukungan untuk Master sistem Redaman volume output audio digital dan volume pada output yang didukung, kecuali untuk output passthrough audio terkompresi (saat tidak ada decoding audio yang dilakukan di perangkat).
Jika implementasi perangkat Televisi tidak memiliki layar bawaan, tetapi sebagai gantinya mendukung layar eksternal yang terhubung melalui HDMI, mereka:
- [5.8/T-0-1] HARUS menyetel mode output HDMI ke resolusi tertinggi untuk format piksel pilihan yang bekerja dengan 50 Hz atau 60 Hz kecepatan refresh untuk layar eksternal, bergantung pada kecepatan refresh video untuk wilayah tempat perangkat dijual.
- [5.8/T-SR-1] SANGAT DIREKOMENDASIKAN untuk menyediakan layanan bagi pengguna Pemilih kecepatan refresh HDMI yang dapat dikonfigurasi.
- [5.8] SEHARUSNYA menyetel kecepatan refresh mode output HDMI ke 50 Hz atau 60 Hz, bergantung pada kecepatan refresh video untuk wilayah perangkat dijual.
Jika implementasi perangkat Televisi tidak memiliki layar bawaan, tetapi sebagai gantinya mendukung layar eksternal yang terhubung melalui HDMI, mereka:
- [5.8/T-1-1] HARUS mendukung HDCP 2.2.
Jika implementasi perangkat Televisi tidak mendukung decoding UHD, namun sebagai gantinya mendukung layar eksternal yang disambungkan melalui HDMI, perangkat tersebut:
- [5.8/T-2-1] HARUS mendukung HDCP 1.4
2.3.3. Software
Implementasi perangkat televisi:
- [3/T-0-1] HARUS mendeklarasikan fitur
android.software.leanback
danandroid.hardware.type.television
. - [3.2.3.1/T-0-1] HARUS melakukan pramuat satu atau lebih banyak aplikasi atau komponen layanan dengan pengendali intent, untuk semua pola filter intent publik yang ditentukan oleh intent aplikasi berikut tercantum di sini.
- [3.4.1/T-0-1] HARUS memberikan
implementasi API
android.webkit.Webview
.
Jika implementasi perangkat Android Television mendukung layar kunci,implementasi tersebut:
- [3.8.10/T-1-1] HARUS menampilkan Kunci termasuk {i>Media Notification Template<i}.
Implementasi perangkat televisi:
- [3.8.14/T-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung multi-aplikasi mode picture-in-picture (PIP).
- [3.10/T-0-1] HARUS mendukung aksesibilitas pihak ketiga layanan IT perusahaan mereka.
- [3.10/T-SR-1] SANGAT DIREKOMENDASIKAN untuk memuat layanan aksesibilitas di perangkat yang sebanding dengan atau melebihi fungsi Tombol Akses dan TalkBack (untuk bahasa yang didukung oleh layanan aksesibilitas mesin Text-to-speech bawaan) sebagaimana disediakan dalam proyek open source Talkback.
Jika implementasi perangkat Televisi melaporkan fitur
android.hardware.audio.output
, ini:
- [3.11/T-SR-1] SANGAT DIREKOMENDASIKAN untuk menyertakan Mesin TTS mendukung bahasa yang tersedia di perangkat.
- [3.11/T-1-1] HARUS mendukung penginstalan mesin TTS pihak ketiga.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Implementasi perangkat televisi:
- [3.12/T-0-1] HARUS mendukung Framework Input TV.
Mengakhiri persyaratan baru
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Android Television Input Framework (TIF) menyederhanakan penayangan konten live ke perangkat Android Televisi. TIF menyediakan standar API untuk membuat modul input yang mengontrol perangkat Android Television.
Implementasi perangkat televisi:
- [3/T-0-2] HARUS mendeklarasikan fitur platform
android.software.live_tv
. - [3/T-0-3] HARUS mendukung semua TIF API sehingga aplikasi yang menggunakan API ini dan input berbasis TIF pihak ketiga {i>service<i} dapat diinstal dan digunakan pada perangkat.
Android Television Tuner Framework (TF) menyatukan penanganan konten live dari Tuner dengan konten streaming dari IP di perangkat Android Televisi. Framework Turner menyediakan API standar untuk membuat layanan input yang menggunakan Android Television Tuner.
Jika implementasi perangkat mendukung Tuner, implementasi tersebut:
- [3/T-1-1] HARUS mendukung semua Tuner Framework API sehingga aplikasi yang menggunakan API ini dapat diinstal dan digunakan di perangkat.
Mengakhiri persyaratan baru
2.3.4. Performa dan Kekuatan
- [8.1/T-0-1] Latensi frame yang konsisten. Latensi frame yang tidak konsisten atau penundaan untuk merender frame TIDAK BOLEH terjadi lebih sering lebih dari 5 frame dalam satu detik, dan HARUS di bawah 1 frame dalam satu detik.
- [8.2/T-0-1] HARUS memastikan bahwa performa operasi tulis minimal 5 MB/dtk.
- [8.2/T-0-2] HARUS memastikan penulisan acak kecepatan transfer data minimal 0,5 MB/dtk.
- [8.2/T-0-3] HARUS memastikan bahwa kinerja membaca setidaknya 15 MB/dtk.
- [8.2/T-0-4] HARUS memastikan pembacaan acak setidaknya 3,5 MB/dtk.
Jika implementasi perangkat Televisi menyertakan fitur untuk meningkatkan daya perangkat manajemen proyek yang disertakan dalam AOSP atau memperluas fitur yang disertakan di 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, implementasi tersebut:
- [8.3/T-1-2] HARUS mendaftarkan perangkat sebagai perangkat tanpa baterai seperti yang dijelaskan dalam Mendukung Perangkat Tanpa Baterai.
Jika implementasi perangkat Televisi memiliki baterai, implementasi tersebut:
- [8.3/T-1-3] HARUS memberikan kemampuan pengguna untuk menampilkan semua aplikasi yang dikecualikan dari mode hemat daya Aplikasi Standby dan Istirahatkan.
Implementasi perangkat televisi:
- [8.4/T-0-1] HARUS memberikan profil daya per komponen yang menentukan nilai konsumsi saat ini untuk setiap komponen perangkat keras dan perkiraan pengurasan baterai yang disebabkan oleh dari waktu ke waktu seperti yang didokumentasikan di situs Proyek Open Source Android.
- [8.4/T-0-2] HARUS melaporkan semua daya nilai konsumsi dalam miliampere jam (mAh).
- [8.4/T-0-3] HARUS melaporkan daya CPU
konsumsi per UID setiap proses. Proyek Open Source Android memenuhi
persyaratan melalui implementasi modul kernel
uid_cputime
. - [8.4/T] SEHARUSNYA diatribusikan dengan komponen perangkat keras itu sendiri jika tidak dapat mengatribusikan penggunaan daya komponen perangkat keras pada aplikasi.
- [8.4/T-0-4] HARUS membuat penggunaan daya ini
tersedia melalui
adb shell dumpsys batterystats
perintah shell kepada developer aplikasi.
2.3.5. Model Keamanan
Implementasi perangkat televisi:
- [9/T-0-1] HARUS mendeklarasikan
android.hardware.security.model.compatible
aplikasi baru. - [9.11/T-0-1] HARUS mencadangkan implementasi keystore dengan lingkungan eksekusi yang terisolasi.
- [9.11/T-0-2] HARUS memiliki implementasi RSA, AES, Algoritma kriptografi ECDSA dan HMAC serta keluarga MD5, SHA-1, dan SHA-2 fungsi hash untuk mendukung sistem Android Keystore yang didukung di area tertentu yang diisolasi secara aman dari kode yang berjalan di {i>kernel<i} dan yang lebih tinggi. Isolasi aman HARUS memblokir semua mekanisme potensial di mana kode {i>kernel<i} atau {i>userspace<i} dapat mengakses status internal lingkungan yang terisolasi, termasuk DMA. Open Source Android upstream Project (AOSP) memenuhi persyaratan ini dengan menggunakan implementasi Trusty, tetapi Solusi berbasis ARM TrustZone atau solusi aman yang ditinjau oleh pihak ketiga implementasi isolasi berbasis hypervisor yang tepat adalah alternatif lainnya.
- [9.11/T-0-3] HARUS menjalankan layar kunci otentikasi di lingkungan eksekusi yang terisolasi dan hanya ketika berhasil, kunci yang terikat otentikasi dapat digunakan. Layar kunci kredensial HARUS disimpan dengan cara yang hanya memungkinkan eksekusi yang terisolasi lingkungan untuk melakukan otentikasi layar kunci. Android upstream Project Open Source menyediakan Gatekeeper Hardware Abstraksi Layer (HAL) dan Trusty, yang dapat digunakan untuk memenuhi persyaratan ini.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
[9.11/T-0-4] HARUS mendukung pengesahan kunci jika penandatanganan pengesahan dilindungi oleh perangkat keras yang aman dan penandatanganan yang dapat dijalankan dengan perangkat keras yang aman. Kunci penandatanganan pengesahan HARUS
dibagikan ke seluruh jumlah perangkat yang cukup besar untuk mencegah kuncidicegah tidak digunakan sebagai permanen 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, tersebut MUNGKIN digunakan untuk setiap 100.000 unit.
Mengakhiri persyaratan baru
Perhatikan bahwa jika implementasi perangkat sudah diluncurkan di Android versi sebelumnya
versi, perangkat tersebut dikecualikan dari persyaratan untuk memiliki keystore
didukung oleh lingkungan eksekusi yang terisolasi
dan mendukung pengesahan kunci,
kecuali jika mendeklarasikan fitur android.hardware.fingerprint
yang memerlukan
keystore yang didukung oleh lingkungan eksekusi yang terisolasi.
Jika implementasi perangkat Televisi mendukung layar kunci yang aman, implementasi tersebut:
- [9.11/T-1-1] HARUS mengizinkan pengguna memilih mode Tidur waktu tunggu untuk transisi dari keadaan tidak terkunci ke keadaan terkunci, dengan waktu tunggu minimum yang diizinkan hingga 15 detik atau kurang.
Jika implementasi perangkat Televisi mencakup
beberapa pengguna dan
tidak mendeklarasikan tombol fitur android.hardware.telephony
, flag tersebut:
- [9.5/T-2-1] HARUS mendukung profil yang dibatasi, fitur yang memungkinkan pemilik perangkat mengelola pengguna tambahan dan pada perangkat. Dengan profil yang dibatasi, pemilik perangkat dapat mengatur lingkungan terpisah dengan cepat bagi pengguna tambahan untuk bekerja, dengan kemampuan untuk mengelola batasan yang lebih terperinci di aplikasi yang yang tersedia di lingkungan tersebut.
Jika implementasi perangkat Televisi mencakup
beberapa pengguna dan
mendeklarasikan tombol fitur android.hardware.telephony
, yaitu:
- [9.5/T-3-1] TIDAK BOLEH mendukung dibatasi profil tetapi HARUS selaras dengan implementasi kontrol AOSP untuk mengaktifkan /menonaktifkan pengguna lain agar tidak dapat mengakses panggilan suara dan SMS.
Jika implementasi perangkat TV mendeklarasikan android.hardware.microphone
, implementasi tersebut:
- [9.8.2/T-4-1] HARUS menampilkan indikator mikrofon saat sebuah aplikasi mengakses data audio dari mikrofon, tetapi tidak ketika hanya dapat diakses oleh HotwordDeteksiionService, SOURCE_HOTWORD, ContentCaptureService, atau aplikasi yang memiliki peran yang disebutkan di Pasal 9.1 Izin dengan ID CDD C-3-X.
- [9.8.2/T-4-2] TIDAK BOLEH menyembunyikan indikator mikrofon untuk aplikasi sistem yang memiliki antarmuka pengguna yang terlihat atau interaksi pengguna langsung.
Jika implementasi perangkat TV mendeklarasikan android.hardware.camera.any
, implementasi tersebut:
- [9.8.2/T-5-1] HARUS menampilkan indikator kamera saat aplikasi mengakses data kamera live, tetapi tidak saat kamera hanya diakses oleh aplikasi yang memegang peran yang disebutkan dalam Pasal 9.1 Izin dengan ID CDD [C-3-X].
- [9.8.2/T-5-2] TIDAK BOLEH menyembunyikan indikator kamera untuk aplikasi sistem yang memiliki antarmuka pengguna yang terlihat atau interaksi pengguna langsung.
2.3.6. Kompatibilitas Opsi dan Developer Tools
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Implementasi perangkat televisi:
- Perfetto
- [6.1/T-0-1] HARUS mengekspos
/system/bin/perfetto
biner ke pengguna {i>shell<i} yang sesuai dengan {i>cmdline<i} dokumentasi perfetto. - [6.1/T-0-2] Biner perfetto HARUS diterima sebagai memasukkan konfigurasi protobuf yang sesuai dengan skema yang ditentukan dalam dokumentasi perfetto.
- [6.1/T-0-3] Biner perfetto HARUS menulis sebagai membuat output trace protobuf yang sesuai dengan skema yang ditentukan dalam dokumentasi perfetto.
- [6.1/T-0-4] HARUS memberikan, melalui perfetto biner, setidaknya sumber data yang dijelaskan dalam dokumentasi perfetto.
- [6.1/T-0-5] Daemon yang dilacak perfetto
HARUS diaktifkan secara default (properti sistem
persist.traced.enable
).
- [6.1/T-0-1] HARUS mengekspos
Mengakhiri persyaratan baru
2.4. Persyaratan Tontonan
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 1,1 hingga 2,5 inci.
- Memiliki mekanisme yang disediakan untuk dikenakan pada tubuh.
Persyaratan tambahan di bagian selanjutnya ini khusus untuk Android Implementasi perangkat smartwatch.
2.4.1. Hardware
Implementasi perangkat smartwatch:
[7.1.1.1/W-0-1] HARUS memiliki layar dengan ukuran diagonal fisik dalam kisaran 1,1 hingga 2,5 inci.
[7.2.3/W-0-1] HARUS menyediakan fungsi Beranda kepada pengguna, dan fungsi Kembali kecuali jika berada dalam
UI_MODE_TYPE_WATCH
.[7.2.4/W-0-1] HARUS mendukung input layar sentuh.
[7.3.1/W-SR-1] SANGAT DIREKOMENDASIKAN untuk menyertakan 3 sumbu akselerometer.
Jika penerapan perangkat Smartwatch menyertakan dukungan untuk Vulkan, penerapan tersebut:
- [7.1.4.2/W-1-1] HARUS memenuhi persyaratan ditentukan oleh profil Dasar Pengukuran Android 2021.
Jika implementasi perangkat Smartwatch menyertakan penerima GPS/GNSS dan melaporkan
ke aplikasi melalui fitur android.hardware.location.gps
menandai, mereka:
- [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 pseudorange GNSS tarif, yang, dalam kondisi langit terbuka setelah menentukan lokasi, sementara diam atau bergerak dengan kecepatan kurang dari 0,2 meter per detik kuadrat dari untuk menghitung posisi dalam jarak 20 meter, dan kecepatan dalam 0,2 meter per detik, setidaknya 95% dari waktu.
Jika implementasi perangkat Smartwatch menyertakan giroskop 3 sumbu, implementasi tersebut:
- [7.3.4/W-2-1] HARUS mampu mengukur perubahan orientasi hingga 1000 derajat per detik.
Implementasi perangkat smartwatch:
[7.4.3/W-0-1] HARUS mendukung Bluetooth.
[7.6.1/W-0-1] HARUS memiliki minimal 1 GB penyimpanan non-volatil yang tersedia untuk data pribadi aplikasi (alias partisi "/data").
[7.6.1/W-0-2] HARUS memiliki memori minimal 416 MB yang tersedia untuk {i> kernel<i} dan {i>userspace<i}.
[7.8.1/W-0-1] HARUS menyertakan mikrofon.
[7.8.2/W] MUNGKIN memiliki output audio.
2.4.2. Multimedia
Tidak ada persyaratan tambahan.
2.4.3. Software
Implementasi perangkat smartwatch:
- [3/W-0-1] HARUS mendeklarasikan fitur
android.hardware.type.watch
. - [3/W-0-2] HARUS mendukung uiMode = UI_MODE_TYPE_WATCH.
- [3.2.3.1/W-0-1] HARUS melakukan pramuat satu atau lebih aplikasi atau komponen layanan dengan pengendali intent, untuk semua pola filter intent publik yang ditentukan oleh aplikasi berikut intent yang tercantum di sini.
Implementasi perangkat smartwatch:
- [3.8.4/W-SR-1] SANGAT DIREKOMENDASIKAN untuk menerapkan asisten di perangkat guna menangani tindakan Bantuan.
Implementasi perangkat smartwatch yang mendeklarasikan android.hardware.audio.output
tombol fitur:
- [3.10/W-1-1] HARUS mendukung aksesibilitas pihak ketiga layanan IT perusahaan mereka.
- [3.10/W-SR-1] SANGAT DIREKOMENDASIKAN untuk melakukan pramuat layanan aksesibilitas pada perangkat yang sebanding dengan atau melebihi fungsi Tombol Akses dan TalkBack (untuk bahasa yang didukung oleh Layanan aksesibilitas mesin text-to-speech) seperti yang disediakan dalam project open source Talkback.
Jika implementasi perangkat Watch melaporkan fitur android.hardware.audio.output, mereka:
[3.11/W-SR-1] SANGAT DIREKOMENDASIKAN untuk menyertakan Mesin TTS mendukung bahasa yang tersedia di perangkat.
[3.11/W-0-1] HARUS mendukung penginstalan mesin TTS pihak ketiga.
2.4.4. Performa dan Kekuatan
Jika implementasi perangkat Smartwatch menyertakan fitur untuk meningkatkan daya perangkat manajemen proyek yang disertakan dalam AOSP atau memperluas fitur yang disertakan di AOSP, fitur tersebut:
- [8.3/W-SR-1] SANGAT DIREKOMENDASIKAN untuk menyediakan kemampuan pengguna untuk menampilkan semua aplikasi yang dikecualikan dari Aplikasi Standby dan Istirahatkan mode hemat daya.
- [8.3/W-SR-2] SANGAT DIREKOMENDASIKAN untuk menyediakan kemampuan pengguna untuk mengaktifkan dan menonaktifkan fitur penghemat baterai.
Implementasi perangkat smartwatch:
- [8.4/W-0-1] HARUS memberikan profil daya per komponen yang menentukan nilai konsumsi saat ini untuk setiap komponen perangkat keras dan perkiraan pengurasan baterai yang disebabkan oleh dari waktu ke waktu seperti yang didokumentasikan di situs Proyek Open Source Android.
- [8.4/W-0-2] HARUS melaporkan semua daya nilai konsumsi dalam miliampere jam (mAh).
- [8.4/W-0-3] HARUS melaporkan daya CPU
konsumsi per UID setiap proses. Proyek Open Source Android memenuhi
persyaratan melalui implementasi modul kernel
uid_cputime
. - [8.4/W-0-4] HARUS membuat penggunaan daya ini
tersedia melalui
adb shell dumpsys batterystats
perintah shell kepada developer aplikasi. - [8,4/W] SEHARUSNYA diatribusikan dengan komponen perangkat keras itu sendiri jika tidak dapat mengatribusikan penggunaan daya komponen perangkat keras pada aplikasi.
2.4.5. Model Keamanan
Implementasi perangkat smartwatch:
- [9/W-0-1] HARUS mendeklarasikan
android.hardware.security.model.compatible
aplikasi baru.
Jika penerapan perangkat Smartwatch mencakup beberapa pengguna dan
tidak mendeklarasikan tombol fitur android.hardware.telephony
, flag tersebut:
- [9.5/W-1-1] HARUS mendukung profil yang dibatasi, fitur yang memungkinkan pemilik perangkat mengelola pengguna tambahan dan pada perangkat. Dengan profil yang dibatasi, pemilik perangkat dapat mengatur lingkungan terpisah dengan cepat bagi pengguna tambahan untuk bekerja, dengan kemampuan untuk mengelola batasan yang lebih terperinci di aplikasi yang yang tersedia di lingkungan tersebut.
Jika penerapan perangkat Smartwatch mencakup beberapa pengguna dan
mendeklarasikan tombol fitur android.hardware.telephony
, yaitu:
- [9.5/W-2-1] TIDAK BOLEH mendukung dibatasi profil tetapi HARUS selaras dengan implementasi kontrol AOSP untuk mengaktifkan /menonaktifkan pengguna lain agar tidak dapat mengakses panggilan suara dan SMS.
Jika implementasi perangkat memiliki layar kunci yang aman dan menyertakan satu atau beberapa trust agent, yang mengimplementasikan TrustAgentService
System API, implementasi tersebut:
- [9.11.1/W-1-1] HARUS menantang pengguna untuk salah satu metode autentikasi utama yang direkomendasikan (misalnya: PIN, pola, sandi) lebih sering dari sekali setiap 72 jam.
2.5. Persyaratan Otomotif
Implementasi Android Automotive mengacu pada head unit kendaraan yang berjalan Android sebagai sistem operasi untuk sebagian atau seluruh sistem dan/atau fungsi infotainmen.
Implementasi perangkat Android diklasifikasikan sebagai Automotive jika implementasi tersebut mendeklarasikan
fitur android.hardware.type.automotive
atau penuhi semua kriteria berikut
kriteria.
- Disematkan sebagai bagian dari, atau dapat dicocokkan dengan, kendaraan otomotif.
- Menggunakan layar di baris kursi pengemudi sebagai tampilan utama.
Persyaratan tambahan di bagian selanjutnya ini khusus untuk Android Implementasi perangkat otomotif.
2.5.1. Hardware
Implementasi perangkat otomotif:
- [7.1.1.1/A-0-1] HARUS memiliki layar minimal 6 inci dalam ukuran diagonal fisik.
- [7.1.1.1/A-0-2] HARUS memiliki tata letak ukuran layar minimal 750 dp x 480 dp.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Jika implementasi perangkat Automotive mendukung Multi-pengguna Serentak
(di mana beberapa pengguna Android bisa berinteraksi
dengan perangkat secara serentak,
masing-masing menggunakan tampilannya sendiri
config_multiuserVisibleBackgroundUsers
diaktifkan), mereka:
- [7.1.1.1/A-1-1] HARUS memiliki layar terpisah
setidaknya 6 inci dalam ukuran diagonal fisik untuk setiap zona penghuni
layar utama. Ini harus diberi tag sebagai
CarOccupantZoneManager.DISPLAY_TYPE_MAIN
untuk setiap zona penghuni. - [7.1.1.1/A-1-2] HARUS memiliki tata letak ukuran layar minimal 750 dp x 480 dp untuk setiap tampilan utama.
Mengakhiri persyaratan baru
Jika implementasi perangkat Automotive mendukung OpenGL ES 3.1, implementasi tersebut:
- [7.1.4.1/A-0-1] HARUS menyatakan OpenGL ES 3.1 atau yang lebih baru.
- [7.1.4.1/A-0-2] HARUS mendukung Vulkan 1.1.
- [7.1.4.1/A-0-3] HARUS menyertakan loader Vulkan dan ekspor semua simbol.
Jika penerapan perangkat Automotive menyertakan dukungan untuk Vulkan, penerapan tersebut:
- [7.1.4.2/A-1-1] HARUS memenuhi persyaratan ditentukan oleh profil Dasar Pengukuran Android 2021.
Implementasi perangkat otomotif:
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [7.1.7/A-0-1] HARUS mengonfigurasi
layar sekunder
dalam garis pandang
pengemudi sebagai
FLAG_PRIVATE
.
Mengakhiri persyaratan baru
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [7.2.3/A-0-1] HARUS menyediakan
Beranda dan Kembali, dan DAPAT menyediakanKembali danyang Fungsi terbaru.
Mengakhiri persyaratan baru
- [7.2.3/A-0-2] HARUS mengirim tombol tekan lama dan normal
peristiwa 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 parameter
NIGHT_MODE
panji HARUS konsisten dengan mode siang/malam dasbor dan SEHARUSNYA didasarkan pada input sensor cahaya sekitar. Sensor cahaya sekitar yang mendasarinya MUNGKIN sama sebagai Photometer. - [7.3/A-0-3] HARUS memberikan kolom info tambahan sensor
TYPE_SENSOR_PLACEMENT
sebagai bagian dari SensorAdditionalInfo untuk setiap sensor yang disediakan. - [7.3/A-SR1] MUNGKIN! Lokasi dengan menggabungkan GPS/GNSS dengan sensor tambahan. Jika Lokasi dianggap sudah mati, SANGAT DIREKOMENDASIKAN untuk menerapkan dan melaporkan Sensor yang sesuai jenis dan/atau ID Properti Kendaraan data
[7.3/A-0-4] Lokasi diminta melalui LocationManager#requestLocationUpdates() TIDAK BOLEH dicocokkan dengan peta.
[7.3.1/A-0-4] HARUS mematuhi Android sistem koordinat sensor mobil.
[7.3/A-SR-1] SANGAT_DIREKOMENDASIKAN untuk menyertakan 3 sumbu akselerometer dan giroskop 3 sumbu.
[7.3/A-SR-2] SANGAT_DIREKOMENDASIKAN untuk mengimplementasikan dan melaporkan Sensor
TYPE_HEADING
.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Jika implementasi perangkat Automotive mendukung Multi-pengguna Serentak
(di mana beberapa pengguna Android bisa berinteraksi
dengan perangkat secara serentak,
masing-masing menggunakan tampilannya sendiri
config_multiuserVisibleBackgroundUsers
diaktifkan), mereka:
- [7.3/A-1-1] HARUS menyetel
NIGHT_MODE
nilai flag secara konsisten dengan mode dasbor siang/malam di semua layar, termasuk layar kursi belakang.
Mengakhiri persyaratan baru
Jika implementasi perangkat Automotive menyertakan akselerometer, implementasi tersebut:
- [7.3.1/A-1-1] HARUS dapat melaporkan peristiwa hingga frekuensi minimal 100 Hz.
Jika implementasi perangkat menyertakan akselerometer 3 sumbu, implementasi tersebut:
- [7.3.1/A-SR-1] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan sensor komposit untuk akselerometer sumbu terbatas.
Jika implementasi perangkat Automotive menyertakan akselerometer dengan nilai kurang dari 3 sumbu, yaitu:
- [7.3.1/A-1-3] HARUS menerapkan dan melaporkan
Sensor
TYPE_ACCELEROMETER_LIMITED_AXES
. - [7.3.1/A-1-4] HARUS menerapkan dan melaporkan
Sensor
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
.
Jika implementasi perangkat Automotive menyertakan giroskop, implementasi tersebut:
- [7.3.4/A-2-1] HARUS dapat melaporkan peristiwa hingga frekuensi minimal 100 Hz.
- [7.3.4/A-2-3] HARUS mampu mengukur perubahan orientasi hingga 250 derajat per detik.
- [7.3.4/A-SR-1] SANGAT DIREKOMENDASIKAN untuk mengonfigurasi rentang pengukuran giroskop hingga +/-250 dp untuk memaksimalkan resolusi sebaik mungkin.
Jika implementasi perangkat Automotive menyertakan giroskop 3 sumbu, implementasi tersebut:
- [7.3.4/A-SR-2] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan sensor komposit untuk giroskop sumbu terbatas.
Jika implementasi perangkat Automotive menyertakan giroskop dengan kurang dari 3 sumbu, implementasi tersebut:
- [7.3.4/A-4-1] HARUS menerapkan dan melaporkan
Sensor
TYPE_GYROSCOPE_LIMITED_AXES
. - [7.3.4/A-4-2] HARUS menerapkan dan melaporkan
Sensor
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
.
Jika implementasi perangkat Automotive menyertakan penerima GPS/GNSS, tetapi jangan mencakup konektivitas data berbasis jaringan seluler, yaitu:
- [7.3.3/A-3-1] HARUS menentukan lokasi pertama kali penerima GPS/GNSS diaktifkan atau setelah 4 hari lebih dalam waktu 60 detik.
- [7.3.3/A-3-2] HARUS memenuhi kriteria waktu untuk perbaikan pertama sebagai dijelaskan dalam 7.3.3/C-1-2 dan 7.3.3/C-1-6 untuk semua permintaan lokasi lainnya (yaitu permintaan yang bukan permintaan lokasi pertama kali sama sekali atau setelah 4 hari lebih). Persyaratan 7.3.3/C-1-2 adalah biasanya ditemui di kendaraan tanpa konektivitas data berbasis jaringan seluler, dengan menggunakan prediksi orbit GNSS yang dihitung pada penerima, atau menggunakan lokasi kendaraan terakhir yang diketahui bersama dengan kemampuan untuk mematikan setidaknya 60 detik dengan akurasi posisi yang memuaskan 7.3.3/C-1-3, atau kombinasi keduanya.
Jika implementasi perangkat otomotif menyertakan sensor TYPE_HEADING
, implementasi tersebut:
- [7.3.4/A-4-3] HARUS dapat melaporkan peristiwa hingga frekuensi minimal 1 Hz.
- [7.3.4/A-SR-3] STRONGLY_RECOMMENDED untuk melaporkan peristiwa hingga dengan frekuensi setidaknya 10 Hz.
- HARUS merujuk ke utara sejati.
- SEHARUSNYA tersedia meskipun kendaraan berhenti digunakan.
- HARUS memiliki resolusi minimal 1 derajat.
Implementasi perangkat otomotif:
- [7.4.3/A-0-1] HARUS mendukung Bluetooth dan SEHARUSNYA mendukung Bluetooth LE.
- [7.4.3/A-0-2] Implementasi Android Automotive
HARUS mendukung profil Bluetooth berikut:
- Panggilan telepon melalui Profil Hands-Free (HFP).
- Pemutaran media melalui Profil Distribusi Audio (A2DP).
- Kontrol pemutaran media atas Profil Remote Control (AVRCP).
- Berbagi kontak menggunakan Profil Akses Buku Telepon (PBAP).
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [7.4.3/A-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung Message Access Profile (MAP) jika perangkat memiliki zona penumpang pengemudi.
Mengakhiri persyaratan baru
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Jika implementasi perangkat Automotive mendukung Multi-pengguna Serentak
(di mana beberapa pengguna Android bisa berinteraksi
dengan perangkat secara serentak,
masing-masing menggunakan tampilannya sendiri
config_multiuserVisibleBackgroundUsers
diaktifkan), mereka:
- [7.4.3/A-1-1] HARUS independen dan TIDAK mengganggu dengan pengguna lain Pengalaman BT.
Mengakhiri persyaratan baru
Implementasi perangkat otomotif:
- [7.4.5/A] SEHARUSNYA menyertakan dukungan untuk jaringan konektivitas data berbasis jaringan.
- [7.4.5/A] DAPAT menggunakan System API
Konstanta
NetworkCapabilities#NET_CAPABILITY_OEM_PAID
untuk jaringan yang harus tersedia untuk aplikasi sistem.
Apakah implementasi perangkat menyertakan dukungan untuk siaran radio AM/FM dan mengekspos fungsionalitasnya untuk aplikasi apa pun, mereka:
- [7,4/A-1-1]
HARUS mendeklarasikan dukungan untuk
FEATURE_BROADCAST_RADIO
.
Kamera belakang berarti kamera menghadap ke dunia yang dapat ditempatkan di mana saja diletakkan di atas kendaraan dan menghadap ke bagian luar kabin kendaraan; artinya, itu gambar pemandangan di sisi jauh bodi kendaraan, seperti kamera belakang.
Kamera depan berarti kamera yang menghadap pengguna yang dapat ditempatkan di ditempatkan di kendaraan dan menghadap ke dalam kabin kendaraan; itu dia gambar pengguna, seperti untuk konferensi video dan aplikasi serupa.
Implementasi perangkat otomotif:
- [7.5/A-SR-1] SANGAT DIREKOMENDASIKAN untuk mencakup satu atau lebih produk yang kamera.
- MUNGKIN mencakup satu atau beberapa kamera yang menghadap pengguna.
- [7.5/A-SR-2] SANGAT DIREKOMENDASIKAN untuk mendukung streaming serentak beberapa kamera.
Jika implementasi perangkat Automotive menyertakan setidaknya satu kamera yang menghadap ke dunia luar, kemudian untuk kamera seperti itu, mereka:
- [7.5/A-1-1] HARUS diorientasikan agar dimensi panjang kamera sejajar dengan bidang X-Y sumbu sensor otomotif Android.
- [7.5/A-SR-3] SANGAT DIREKOMENDASIKAN untuk memiliki fokus tetap atau EDOF (Extended Depth of Field).
- [7.5/A-1-2] HARUS memiliki kamera utama yang menghadap ke dunia dengan ID kamera terendah.
Jika implementasi perangkat Automotive menyertakan setidaknya satu kamera yang menghadap pengguna, untuk kamera tersebut:
- [7.5/A-2-1] Kamera utama yang menghadap pengguna HARUS merupakan kamera yang menghadap pengguna dengan ID kamera terendah.
- MUNGKIN diorientasikan sehingga dimensi panjang kamera sejajar dengan X-Y bidang sumbu sensor otomotif Android.
Jika implementasi perangkat Automotive menyertakan kamera yang dapat diakses melalui
android.hardware.Camera
atau android.hardware.camera2
API, maka keduanya:
- [7.5/A-3-1] HARUS mematuhi persyaratan kamera inti dalam bagian 7.5.
Jika implementasi perangkat Automotive menyertakan kamera yang tidak dapat diakses
melalui API android.hardware.Camera
atau android.hardware.camera2
, lalu
mereka:
- [7.5/A-4-1] HARUS dapat diakses melalui layanan Extended View System.
Jika implementasi perangkat Automotive menyertakan satu atau beberapa kamera yang dapat diakses melalui Extended View System Service, untuk kamera semacam itu, akan:
- [7.5/A-5-1] TIDAK BOLEH memutar atau mencerminkan pratinjau kamera secara horizontal.
- [7.5/A-SR-4] SANGAT DIREKOMENDASIKAN untuk memiliki resolusi minimal 1,3 megapiksel.
Jika implementasi perangkat otomotif
menyertakan satu atau beberapa kamera yang
dapat diakses melalui Extended View System Service dan android.hardware.Camera
atau android.hardware.Camera2
API, kemudian untuk kamera tersebut, keduanya:
- [7.5/A-6-1] HARUS melaporkan ID Kamera yang sama.
Jika implementasi perangkat Automotive menyediakan API kamera eksklusif, implementasi tersebut:
- [7.5/A-7-1] HARUS mengimplementasikan API kamera tersebut menggunakan
android.hardware.camera2
atau Extended View System API.
Implementasi perangkat otomotif:
[7.6.1/A-0-1] HARUS memiliki minimal 4 GB penyimpanan non-volatil yang tersedia untuk data pribadi aplikasi (partisi
/data
).[7.6.1/A] HARUS memformat partisi data untuk menawarkan peningkatan performa dan ketahanan pada penyimpanan flash (misalnya, menggunakan sistem file
f2fs
).
Jika implementasi perangkat Automotive menyediakan penyimpanan eksternal bersama melalui dari penyimpanan internal yang tidak dapat dilepas, mereka:
- [7.6.1/A-SR-1] SANGAT DIREKOMENDASIKAN untuk mengurangi
Overhead I/O pada operasi yang dilakukan pada penyimpanan eksternal, misalnya dengan
menggunakan
SDCardFS
.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Jika implementasi perangkat Automotive mendukung Multi-pengguna Serentak
(di mana beberapa pengguna Android bisa berinteraksi
dengan perangkat secara serentak,
masing-masing menggunakan tampilannya sendiri
config_multiuserVisibleBackgroundUsers
diaktifkan), mereka:
- [7.6.1/A-1-1] HARUS memiliki, pada satu instance AAOS,
setidaknya 4 GB untuk setiap pengguna Android serentak pada penyimpanan non-volatil
tersedia untuk data pribadi aplikasi (partisi
/data
).
Mengakhiri persyaratan baru
Jika implementasi perangkat Automotive adalah 64-bit:
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
[7.6.1/A-2-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 816 MB per layar utama 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 per layar utama 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 layar ekstra besar
[7.6.1/A-2-3] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 1.280 MB per layar utama jika salah satu kepadatan berikut digunakan:
- 400 dpi atau lebih tinggi pada layar kecil/normal
- xhdpi atau lebih tinggi di perangkat layar besar
- tvdpi atau lebih tinggi di layar ekstra besar
[7.6.1/A-2-4] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 1824 MB per layar utama 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 lebih tinggi di layar ekstra besar
Perhatikan bahwa "memori yang tersedia untuk kernel dan userspace" di atas mengacu pada ruang memori yang disediakan selain memori yang sudah didedikasikan untuk perangkat keras komponen seperti radio, video, dan sebagainya yang tidak berada di bawah mengontrol implementasi perangkat.
Mengakhiri persyaratan baru
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
.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Jika implementasi perangkat Automotive mendukung Multi-pengguna Serentak
(di mana beberapa pengguna Android bisa berinteraksi
dengan perangkat secara serentak,
masing-masing menggunakan tampilannya sendiri
config_multiuserVisibleBackgroundUsers
diaktifkan), mereka:
- [7.8.2/A-1-1] HARUS memiliki perangkat output audio untuk setiap tampilan untuk beberapa sistem pengguna secara serentak.
- [7.8.2/A-1-2] HARUS memiliki zona audio Driver yang mencakup speaker kabinetnya. Zona penumpang depan dapat membagikan audio pengemudi atau dapat memiliki output audionya sendiri.
Mengakhiri persyaratan baru
2.5.2. Multimedia
Implementasi perangkat otomotif HARUS mendukung encoding audio berikut dan decoding formatnya serta menyediakannya untuk aplikasi pihak ketiga:
- [5.1/A-0-1] Profil AAC MPEG-4 (AAC LC)
- [5.1/A-0-2] Profil MPEG-4 HE AAC (AAC+)
- [5.1/A-0-3] AAC ELD (Peningkatan AAC penundaan rendah)
Implementasi perangkat otomotif HARUS mendukung encoding video berikut dan menyediakannya untuk aplikasi pihak ketiga:
Implementasi perangkat otomotif HARUS mendukung decoding video berikut dan menyediakannya untuk aplikasi pihak ketiga:
Implementasi perangkat otomotif SANGAT DIREKOMENDASIKAN untuk mendukung pendekodean video berikut:
- [5.3/A-SR-1] HEVC H.265
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Jika implementasi perangkat Automotive mendukung Multi-pengguna Serentak
(di mana beberapa pengguna Android bisa berinteraksi
dengan perangkat secara serentak,
masing-masing menggunakan tampilannya sendiri
config_multiuserVisibleBackgroundUsers
diaktifkan), mereka:
- [5.5.3/A-1-1] HARUS menentukan kurva volume yang identik untuk semua streaming output audio yang dipetakan ke grup volume yang sama seperti ditentukan dalam file konfigurasi audio mobil.
Mengakhiri persyaratan baru
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
android.car.*
namespace.
Jika implementasi perangkat Automotive menyediakan API eksklusif menggunakan
android.car.CarPropertyManager
dengan
android.car.VehiclePropertyIds
,
mereka:
- [3/A-1-1] TIDAK BOLEH memberikan hak istimewa khusus ke sistem penggunaan properti tersebut oleh aplikasi, 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 seperti yang didokumentasikan oleh halaman referensi Izin Otomotif.
[3.2.3.1/A-0-1] HARUS melakukan pramuat satu atau lebih banyak aplikasi atau komponen layanan dengan pengendali intent, untuk semua pola filter intent publik yang ditentukan oleh intent aplikasi berikut tercantum di sini.
[3.4.1/A-0-1] HARUS memberikan implementasi API
android.webkit.Webview
.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [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 tampilan apa pun.
Jika implementasi perangkat Automotive mendukung Multi-pengguna Serentak
(di mana beberapa pengguna Android bisa berinteraksi
dengan perangkat secara serentak,
masing-masing menggunakan tampilannya sendiri
config_multiuserVisibleBackgroundUsers
diaktifkan),
untuk pengguna sekunder penuh yang bukan pengguna latar depan saat ini
tetapi memiliki akses UI ke layar, keduanya:
[3,8/A-1-1] HARUS implementasikan daftar
UserRestrictions
yang telah ditentukan berikut:[3.8/A-1-2] TIDAK BOLEH mengizinkan pengguna tersebut untuk mengubah pengaturan berikut untuk pengguna lain, melalui setelan atau API:
- mode siang/malam
- locale
- tanggal
- waktu
- zona waktu
- fitur warna layar (termasuk Kecerahan, Cahaya Malam, Kesehatan Digital hitam putih, dan Kurangi Warna Cerah)
Mengakhiri persyaratan baru
Implementasi perangkat otomotif:
[3.8.3/A-0-1] HARUS menampilkan notifikasi yang menggunakan
Notification.CarExtender
API jika 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 Automotive menyertakan tombol push-to-talk, implementasi tersebut:
- [3.8.4/A-1-1] HARUS menggunakan penekanan singkat pada
tombol {i>push-to-talk<i} sebagai interaksi
yang ditunjuk untuk meluncurkan
aplikasi bantuan yang dipilih pengguna, dengan kata
lain aplikasi yang mengimplementasikan
VoiceInteractionService
Implementasi perangkat otomotif:
- [3.8.3.1/A-0-1] HARUS dengan benar
merender resource seperti yang dijelaskan dalam
Notifications on Automotive OS
dokumentasi SDK. - [3.8.3.1/A-0-2] HARUS menampilkan
PLAY dan MUTE untuk tindakan notifikasi sebagai pengganti tindakan yang diberikan melalui
Notification.Builder.addAction()
- [3.8.3.1/A] HARUS membatasi penggunaan tugas pengelolaan yang beragam, seperti kontrol per-notifikasi saluran. MUNGKIN menggunakan kemampuan UI per aplikasi untuk mengurangi kontrol.
Jika implementasi perangkat Automotive mendukung properti HAL Pengguna, implementasi tersebut:
- [3.9.3/A-1-1] HARUS menerapkan semua
Properti siklus proses pengguna
INITIAL_USER_INFO
,SWITCH_USER
,CREATE_USER
,REMOVE_USER
.
Implementasi perangkat otomotif:
- [3.14/A-0-1] HARUS menyertakan framework UI untuk mendukung aplikasi pihak ketiga yang menggunakan API media seperti yang dijelaskan dalam bagian 3.14.
- [3.14/A-0-2] HARUS memungkinkan pengguna berinteraksi dengan aman dengan Aplikasi Media saat mengemudi.
- [3.14/A-0-3] HARUS mendukung
CAR_INTENT_ACTION_MEDIA_TEMPLATE
tindakan Intent implisit denganCAR_EXTRA_MEDIA_PACKAGE
tambahan. - [3.14/A-0-4] HARUS memberikan affordance untuk digunakan di sebuah Aplikasi Media preferensi aktivitas Anda, tetapi HARUS mengaktifkannya hanya jika Pembatasan UX Mobil tidak diberlakukan.
- [3.14/A-0-5] HARUS menampilkan
pesan error
disetel 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 yang mendukung penelusuran.
- [3.14/A-0-7] HARUS mematuhi
CONTENT_STYLE_BROWSABLE_HINT
danCONTENT_STYLE_PLAYABLE_HINT
saat menampilkan MediaBrowser hierarki sebelumnya.
Jika implementasi perangkat Automotive menyertakan aplikasi peluncur default, implementasi tersebut:
- [3.14/A-1-1] HARUS menyertakan layanan media dan membukanya
dengan
CAR_INTENT_ACTION_MEDIA_TEMPLATE
intent.
Implementasi perangkat otomotif:
- [3.8/A] MUNGKIN membatasi aplikasi tersebut
permintaan untuk memasuki mode layar penuh seperti yang dijelaskan dalam
immersive documentation
. - [3.8/A] MUNGKIN mempertahankan status bar dan bilah navigasi yang selalu terlihat.
- [3.8/A] MUNGKIN membatasi aplikasi tersebut permintaan untuk mengubah warna di belakang elemen UI sistem, untuk memastikan elemen-elemen tersebut terlihat jelas setiap saat.
2.5.4. Performa dan Kekuatan
Implementasi perangkat otomotif:
- [8.2/A-0-1] HARUS melaporkan jumlah
byte yang dibaca dan ditulis ke penyimpanan non-volatil per UID setiap proses sehingga
statistik tersedia untuk developer melalui System API
android.car.storagemonitoring.CarStorageMonitoringManager
. Android Open Project Sumber memenuhi persyaratan melalui modul kerneluid_sys_stats
. - [8.3/A-1-3] HARUS mendukung Mode Garasi.
- [8.3/A] SEHARUSNYA berada dalam Mode Garasi setidaknya selama
15 menit setelah setiap perjalanan, kecuali:
- Baterai habis.
- Tidak ada tugas tidak ada aktivitas yang dijadwalkan.
- Pengemudi keluar dari Mode Garasi.
- [8.4/A-0-1] HARUS memberikan profil daya per komponen yang menentukan nilai konsumsi saat ini untuk setiap komponen perangkat keras dan perkiraan pengurasan baterai yang disebabkan oleh dari waktu ke waktu seperti yang didokumentasikan di situs Proyek Open Source Android.
- [8.4/A-0-2] HARUS melaporkan semua daya nilai konsumsi dalam miliampere jam (mAh).
- [8.4/A-0-3] HARUS melaporkan daya CPU
konsumsi per UID setiap proses. Proyek Open Source Android memenuhi
persyaratan melalui implementasi modul kernel
uid_cputime
. - [8.4/A] SEHARUSNYA diatribusikan dengan komponen perangkat keras itu sendiri jika tidak dapat mengatribusikan penggunaan daya komponen perangkat keras pada aplikasi.
- [8.4/A-0-4] HARUS membuat penggunaan daya ini
tersedia melalui
adb shell dumpsys batterystats
perintah shell kepada developer aplikasi.
2.5.5. Model Keamanan
Jika implementasi perangkat Automotive mendukung beberapa pengguna, implementasi perangkat tersebut:
- [9.5/A-1-1] TIDAK BOLEH mengizinkan pengguna untuk berinteraksi dengan atau beralih ke Headless System User, kecuali untuk penyediaan perangkat.
- [9.5/A-1-2] HARUS beralih ke Pengguna Sekunder
sebelum
BOOT_COMPLETED
. - [9.5/A-1-3] HARUS mendukung kemampuan untuk membuat Pengguna Tamu meskipun jumlah maksimum Pengguna di perangkat telah tercapai.
Jika implementasi perangkat Automotive mendeklarasikan android.hardware.microphone
,
mereka:
- [9.8.2/A-1-1] HARUS menampilkan indikator mikrofon saat
sebuah aplikasi mengakses data audio dari mikrofon, tetapi tidak ketika
mikrofon hanya dapat diakses oleh
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
atau aplikasi yang memiliki peran yang disebutkan di bagian 9.1 dengan ID CDD [C-4-X]. - [9.8.2/A-1-2] TIDAK BOLEH menyembunyikan indikator mikrofon untuk aplikasi sistem yang memiliki antarmuka pengguna yang terlihat atau interaksi pengguna langsung.
- [9.8.2/A-1-3] HARUS memberikan kemampuan pengguna untuk mengaktifkan/menonaktifkan mikrofon di aplikasi Setelan.
Jika implementasi perangkat Automotive mendeklarasikan android.hardware.camera.any
, maka
mereka:
- [9.8.2/A-2-1] HARUS menampilkan indikator kamera saat aplikasi mengakses data kamera live, tetapi tidak saat kamera hanya digunakan diakses oleh aplikasi yang memegang peran seperti yang ditentukan dalam Izin Pasal 9.1 dengan ID CDD [C-4-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.
- [9.8.2/A-2-3] HARUS memberikan kemampuan pengguna untuk mengalihkan kamera di aplikasi Settings.
- [9.8.2/A-2-4] HARUS menampilkan aplikasi Terbaru dan Aktif menggunakan kamera seperti yang ditampilkan
dari
PermissionManager.getIndicatorAppOpUsageData()
, beserta semua pesan atribusi yang terkait dengannya.
Implementasi perangkat otomotif:
- [9/A-0-1] HARUS mendeklarasikan
android.hardware.security.model.compatible
aplikasi baru. - [9.11/A-0-1] HARUS mencadangkan implementasi keystore dengan lingkungan eksekusi yang terisolasi.
- [9.11/A-0-2] HARUS memiliki implementasi RSA, AES, Algoritma kriptografi ECDSA dan HMAC serta keluarga MD5, SHA-1, dan SHA-2 fungsi hash untuk mendukung sistem Android Keystore yang didukung di area tertentu yang diisolasi secara aman dari kode yang berjalan di {i>kernel<i} dan yang lebih tinggi. Isolasi aman HARUS memblokir semua mekanisme potensial di mana kode {i>kernel<i} atau {i>userspace<i} dapat mengakses status internal lingkungan yang terisolasi, termasuk DMA. Open Source Android upstream Project (AOSP) memenuhi persyaratan ini dengan menggunakan implementasi Trusty, tetapi Solusi berbasis ARM TrustZone atau solusi aman yang ditinjau oleh pihak ketiga implementasi isolasi berbasis hypervisor yang tepat adalah alternatif lainnya.
- [9.11/A-0-3] HARUS menjalankan layar kunci otentikasi di lingkungan eksekusi yang terisolasi dan hanya ketika berhasil, kunci yang terikat otentikasi dapat digunakan. Layar kunci kredensial HARUS disimpan dengan cara yang hanya memungkinkan eksekusi yang terisolasi lingkungan untuk melakukan otentikasi layar kunci. Android upstream Project Open Source menyediakan Gatekeeper Hardware Abstraksi Layer (HAL) dan Trusty, yang dapat digunakan untuk memenuhi persyaratan ini.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
[9.11/A-0-4] HARUS mendukung pengesahan kunci jika penandatanganan pengesahan dilindungi oleh perangkat keras yang aman dan penandatanganan yang dapat dijalankan dengan perangkat keras yang aman. Kunci penandatanganan pengesahan HARUS
dibagikan ke seluruh jumlah perangkat yang cukup besar untuk mencegah kuncidicegah tidak digunakan sebagai permanen 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, tersebut MUNGKIN digunakan untuk setiap 100.000 unit.
Mengakhiri persyaratan baru
Perhatikan bahwa jika implementasi perangkat sudah diluncurkan di Android versi sebelumnya
versi, perangkat tersebut dikecualikan dari persyaratan untuk memiliki keystore
didukung oleh lingkungan eksekusi yang terisolasi
dan mendukung pengesahan kunci,
kecuali jika mendeklarasikan fitur android.hardware.fingerprint
yang memerlukan
keystore yang didukung oleh lingkungan eksekusi yang terisolasi.
Implementasi perangkat otomotif:
- [9.14/A-0-1] HARUS melakukan gatekeep pesan dari subsistem kendaraan framework Android, misalnya, mengizinkan pesan yang diizinkan jenis dan sumber pesan.
- [9.14/A-0-2] HARUS mengawasi serangan denial of service dari framework Android atau aplikasi pihak ketiga. Ini perlindungan terhadap perangkat lunak berbahaya yang membanjiri jaringan kendaraan dengan lalu lintas, yang dapat menyebabkan kerusakan subsistem kendaraan.
2.5.6. Kompatibilitas Opsi dan Developer Tools
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Implementasi perangkat otomotif:
- Perfetto
- [6.1/A-0-1] HARUS mengekspos
/system/bin/perfetto
biner ke pengguna {i>shell<i} yang sesuai dengan {i>cmdline<i} dokumentasi perfetto. - [6.1/A-0-2] Biner perfetto HARUS diterima sebagai memasukkan konfigurasi protobuf yang sesuai dengan skema yang ditentukan dalam dokumentasi perfetto.
- [6.1/A-0-3] Biner perfetto HARUS menulis sebagai membuat output trace protobuf yang sesuai dengan skema yang ditentukan dalam dokumentasi perfetto.
- [6.1/A-0-4] HARUS memberikan, melalui perfetto biner, setidaknya sumber data yang dijelaskan dalam dokumentasi perfetto.
- [6.1/A-0-5] Daemon yang dilacak perfetto
HARUS diaktifkan secara default (properti sistem
persist.traced.enable
).
- [6.1/A-0-1] HARUS mengekspos
Mengakhiri persyaratan baru
2.6. Persyaratan Tablet
Perangkat Android Tablet mengacu pada implementasi perangkat Android yang biasanya memenuhi semua kriteria berikut:
- Digunakan dengan menggenggam di kedua tangan.
- Tidak memiliki konfigurasi laptop konvensional atau konvertibel.
- Implementasi {i>keyboard<i} fisik yang digunakan dengan perangkat yang dihubungkan dengan sarana koneksi standar (misalnya USB, Bluetooth).
Memiliki sumber listrik yang menyediakan mobilitas, seperti baterai.
Memiliki ukuran tampilan layar yang lebih besar dari 7 inci dan kurang dari 18", yang diukur secara diagonal.
Implementasi perangkat tablet memiliki persyaratan serupa dengan perangkat genggam implementasi yang tepat. Pengecualian ditunjukkan dengan * pada bagian tersebut dan dicatat sebagai referensi dalam bagian ini.
2.6.1. Hardware
Giroskop
Jika implementasi perangkat Tablet menyertakan giroskop 3 sumbu, penerapan tersebut:
- [7.3.4/Tab-1-1] HARUS mampu mengukur orientasi berubah hingga 1000 derajat per detik.
Memori dan Penyimpanan Minimum (Bagian 7.6.1)
Kepadatan layar tercantum untuk layar kecil/normal di perangkat genggam persyaratan ini tidak berlaku untuk tablet.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Mode periferal USB (Bagian 7.7.1)
Jika implementasi perangkat tablet menyertakan port USB yang mendukung periferal tersebut, mereka:
- [7.7.1/Tab] MUNGKIN menerapkan Android Open Accessory API (AOA).
Mengakhiri persyaratan baru
Mode Virtual Reality (Bagian 7.9.1)
Performa Tinggi Virtual Reality (Bagian 7.9.2)
Persyaratan virtual reality tidak berlaku untuk tablet.
2.6.2. Model Keamanan
Kunci dan Kredensial (Bagian 9.11)
Lihat Bagian [9.11].
Jika implementasi perangkat Tablet mencakup
beberapa pengguna dan
tidak mendeklarasikan tombol fitur android.hardware.telephony
, flag tersebut:
- [9.5/T-1-1] HARUS mendukung profil yang dibatasi, fitur yang memungkinkan pemilik perangkat mengelola pengguna tambahan dan pada perangkat. Dengan profil yang dibatasi, pemilik perangkat dapat mengatur lingkungan terpisah dengan cepat bagi pengguna tambahan untuk bekerja, dengan kemampuan untuk mengelola batasan yang lebih terperinci di aplikasi yang yang tersedia di lingkungan tersebut.
Jika implementasi perangkat Tablet mencakup
beberapa pengguna dan
mendeklarasikan tombol fitur android.hardware.telephony
, yaitu:
- [9.5/T-2-1] TIDAK BOLEH mendukung dibatasi profil tetapi HARUS selaras dengan implementasi kontrol AOSP untuk mengaktifkan /menonaktifkan pengguna lain agar tidak dapat mengakses panggilan suara dan SMS.
2.6.2. Software
- [3.2.3.1/Tab-0-1] HARUS melakukan pramuat satu kali atau lebih aplikasi atau komponen layanan dengan pengendali intent, untuk semua pola filter intent publik yang ditentukan oleh intent aplikasi berikut tercantum di sini.
3. Software
3.1. Kompatibilitas API Terkelola
Lingkungan eksekusi bytecode Dalvik terkelola adalah sarana utama bagi aplikasi Android. Android application programming interface (API) adalah satu set antarmuka platform Android yang terekspos ke aplikasi yang berjalan di lingkungan runtime terkelola.
Implementasi perangkat:
[C-0-1] HARUS memberikan implementasi yang lengkap, termasuk semua terdokumentasi perilaku model, dari API terdokumentasi yang diekspos oleh SDK Android atau API apa pun yang didekorasi dengan "@SystemApi" penanda di Android upstream pada kode sumber Anda.
[C-0-2] HARUS mendukung/mempertahankan semua class, metode, dan elemen terkait ditandai dengan anotasi TestApi (@TestApi).
[C-0-3] TIDAK BOLEH menghilangkan API terkelola apa pun, mengubah antarmuka API atau tanda tangan, menyimpang dari perilaku yang didokumentasikan, atau menyertakan tanpa pengoperasian, kecuali secara khusus diizinkan oleh Definisi Kompatibilitas ini.
[C-0-4] HARUS menjaga API yang ada dan berperilaku dengan cara yang wajar, bahkan ketika beberapa fitur perangkat keras yang tidak dapat menyertakan API, dihilangkan. Lihat bagian 7 untuk persyaratan khusus skenario ini.
[C-0-5] TIDAK BOLEH mengizinkan aplikasi pihak ketiga menggunakan antarmuka non-SDK, yang didefinisikan sebagai metode dan kolom dalam paket bahasa Java yang di classpath booting di AOSP, dan yang tidak menjadi bagian dari publik SDK. Ini termasuk API yang didekorasi dengan anotasi
@hide
, tetapi tidak dengan@SystemAPI
, seperti yang dijelaskan dalam dokumen SDK dan anggota kelas privat dan pribadi paket.[C-0-6] HARUS mengirim dengan setiap antarmuka non-SDK di saluran seperti yang disediakan melalui tanda sementara dan daftar tolak di
prebuilts/runtime/appcompat/hiddenapi-flags.csv
cabang untuk cabang API level yang sesuai di AOSP.[C-0-7] HARUS mendukung konfigurasi bertanda tangan mekanisme update dinamis untuk menghapus antarmuka non-SDK dari daftar yang dibatasi dengan menyematkan konfigurasi bertanda tangan dalam APK apa pun, menggunakan kunci publik yang ada yang ada di AOSP.
Namun demikian:
- MUNGKIN, jika API tersembunyi tidak ada atau diterapkan secara berbeda pada perangkat memindahkan API tersembunyi ke dalam daftar tolak atau menghilangkannya dari semua daftar yang dibatasi.
- MUNGKIN, jika API tersembunyi belum ada di AOSP, tambahkan API API ke daftar yang dibatasi.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [C-0-8] TIDAK BOLEH mendukung penginstalan aplikasi yang menargetkan level API
kurang dari
2324.
Mengakhiri persyaratan baru
3.1.1. Ekstensi Android
Android mendukung perluasan platform API terkelola pada level API tertentu dengan
dan mengupdate versi ekstensi untuk API level tersebut. Tujuan
android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
API menampilkan
versi ekstensi dari apiLevel
yang disediakan, jika ada ekstensi untuk
level API.
Implementasi perangkat Android:
[C-0-1] HARUS melakukan pramuat implementasi AOSP dari kedua library bersama
ExtShared
dan layananExtServices
dengan versi lebih besar dari atau sama dengan versi minimum yang diizinkan untuk setiap level API. Misalnya, Android 7.0 implementasi perangkat, menjalankan API level 24 HARUS menyertakan setidaknya versi 1.[C-0-2] Hanya boleh mengembalikan nomor versi ekstensi valid yang telah yang telah ditentukan oleh AOSP.
[C-0-3] HARUS mendukung semua API yang ditentukan oleh versi ekstensi dikembalikan oleh
android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
dengan cara yang sama seperti API terkelola lainnya didukung, dengan mengikuti persyaratan di pasal 3.1.
3.1.2. Library Android
Karena penghentian 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 aplikasi classpath hanya jika aplikasi memenuhi salah satu kondisi berikut:- Menargetkan API level 28 atau lebih rendah.
- Mendeklarasikan dalam manifesnya bahwa ia memerlukan library dengan menyetel atribut
Atribut
android:name
dari<uses-library>
hinggaorg.apache.http.legacy
.
Implementasi AOSP memenuhi persyaratan ini.
3.2. Kompatibilitas Soft API
Selain API terkelola dari bagian 3.1, Android juga menyertakan "soft" khusus runtime yang signifikan API, dalam bentuk seperti maksud, izin, dan aspek serupa dari aplikasi Android yang tidak dapat diterapkan pada waktu kompilasi aplikasi.
3.2.1. Izin
- [C-0-1] Pengimplementasikan perangkat HARUS mendukung dan menerapkan semua izin seperti yang didokumentasikan oleh Halaman referensi izin. Perlu diperhatikan bahwa pasal 9 mencantumkan tambahan persyaratan yang terkait dengan model keamanan Android.
3.2.2 Parameter Build
Android API menyertakan sejumlah konstanta pada Class android.os.Build yang dimaksudkan untuk menggambarkan perangkat saat ini.
- [C-0-1] Untuk memberikan nilai yang konsisten dan bermakna di seluruh perangkat penerapan, tabel di bawah ini menyertakan pembatasan tambahan pada format dari nilai ini yang HARUS sesuai dengan implementasi perangkat.
Parameter | Detail |
---|---|
VERSION.RELEASE | Versi sistem Android yang saat ini dijalankan, dalam versi yang dapat dibaca manusia format font. Bidang ini HARUS memiliki salah satu nilai {i>string<i} yang ditentukan di String Versi yang Diizinkan untuk Android 15. |
VERSION.SDK | Versi sistem Android yang saat ini dijalankan, dalam format dapat diakses oleh kode aplikasi pihak ketiga. Untuk Android 15, bidang ini HARUS memiliki nilai bilangan bulat 15_INT. |
VERSION.SDK_INT | Versi sistem Android yang saat ini dijalankan, dalam format dapat diakses oleh kode aplikasi pihak ketiga. Untuk Android 15, bidang ini HARUS memiliki nilai bilangan bulat 15_INT. |
VERSION.INCREMENTAL | Nilai yang dipilih oleh pengimplementasi perangkat yang menentukan build tertentu
dari sistem Android yang saat ini dijalankan, dalam format yang dapat dibaca manusia. Ini
nilai TIDAK BOLEH digunakan kembali untuk build berbeda yang tersedia bagi pengguna akhir. J
penggunaan yang umum dari isian ini adalah
untuk menunjukkan nomor {i>build<i} atau
ID perubahan kontrol sumber digunakan untuk membuat build. Nilainya
isian ini HARUS dapat dikodekan sebagai ASCII 7-bit yang dapat dicetak dan cocok dengan
ekspresi reguler ^[^ :\/~]+$ . |
PAPAN | Nilai yang dipilih oleh pengimplementasi perangkat yang mengidentifikasi
perangkat keras internal yang digunakan oleh perangkat, dalam format yang dapat dibaca manusia. Kemungkinan
penggunaan isian ini adalah untuk menunjukkan
revisi spesifik dari dewan yang mendukung
perangkat. Nilai isian 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 serta diketahui
pengguna akhir. HARUS dalam format yang dapat dibaca manusia dan SEHARUSNYA mewakili
produsen perangkat atau merek
perusahaan yang mendasari
dipasarkan. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok
ekspresi reguler ^[a-zA-Z0-9_-]+$ . |
DIDUKUNG&ABI;ABI | Nama kumpulan petunjuk (jenis CPU + konvensi ABI) native pada kode sumber. Lihat bagian 3.3. API Native Kompatibilitas. |
DIDUKUNG_32_BIT_ABI | Nama kumpulan petunjuk (jenis CPU + konvensi ABI) native pada kode sumber. Lihat bagian 3.3. API Native Kompatibilitas. |
DIDUKUNG_64_BIT_ABI | Nama kumpulan petunjuk kedua (jenis CPU + konvensi ABI) kode native 3D. Lihat bagian 3.3. Native Kompatibilitas API. |
CPU_ABI | Nama kumpulan petunjuk (jenis CPU + konvensi ABI) native pada kode sumber. Lihat bagian 3.3. API Native Kompatibilitas. |
CPU_ABI2 | Nama kumpulan petunjuk kedua (jenis CPU + konvensi ABI) kode native 3D. Lihat bagian 3.3. Native Kompatibilitas API. |
PERANGKAT | Nilai yang dipilih oleh pengimplementasi perangkat yang berisi nama pengembangan
atau nama kode yang mengidentifikasi konfigurasi
fitur perangkat keras dan
desain industri perangkat. Nilai kolom ini HARUS dapat dienkode
sebagai ASCII 7-bit dan cocok dengan ekspresi reguler
^[a-zA-Z0-9_-]+$ . Nama perangkat ini TIDAK BOLEH berubah selama
masa pakai produk. |
CETAK JARI | String yang mengidentifikasi build ini secara unik. Seharusnya sudah masuk akal
dapat dibaca manusia. URL HARUS mengikuti {i>template<i} ini:
$(BRAND)/$(PRODUCT)/ Contoh: acme/myproduct/ Sidik jari TIDAK BOLEH berisi karakter spasi kosong. Nilai dari bidang ini HARUS dapat dienkode sebagai ASCII 7-bit. |
PERANGKAT KERAS | Nama perangkat keras (dari baris perintah {i>kernel<i} atau {i> /proc<i}. Ini
HARUS dapat dibaca oleh manusia. Nilai bidang ini HARUS
dapat dienkripsi sebagai ASCII 7-bit dan cocok dengan ekspresi reguler
^[a-zA-Z0-9_-]+$ . |
HOST | String yang secara unik mengidentifikasi {i>host<i} tempat build dibuat, di dapat dibaca manusia. Tidak ada persyaratan mengenai format tertentu dari kolom ini, kecuali bahwa TIDAK BOLEH berupa null atau string kosong (""). |
ID | ID yang dipilih oleh pengimplementasi perangkat untuk merujuk ke
dirilis, dalam format yang dapat dibaca manusia. Bidang ini bisa sama dengan
android.os.Build.VERSION.INCREMENTAL, tetapi SEHARUSNYA memiliki nilai yang cukup
berguna bagi pengguna akhir untuk
membedakan pembuatan perangkat lunak. Nilainya
isian ini HARUS dapat dikodekan sebagai ASCII 7-bit dan cocok dengan
ekspresi ^[a-zA-Z0-9._-]+$ . |
Produsen | Nama dagang Produsen Peralatan Asli (OEM) dari Google. Tidak ada persyaratan untuk format khusus {i>field<i} ini, kecuali bahwa variabel tersebut TIDAK BOLEH berupa nol atau string kosong (""). Kolom ini TIDAK BOLEH berubah selama masa pakai produk. |
SOC_MANUFAKTUR | Perdagangan nama produsen
sistem utama di
(SOC) yang digunakan dalam produk. Perangkat dengan produsen SOC yang sama
harus menggunakan
nilai konstanta yang sama. Harap tanyakan kepada produsen SOC
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 "tidak diketahui". Bidang ini TIDAK BOLEH berubah selama
masa pakai produk. |
SOC_MODEL | Nama model sistem utama pada chip (SOC) yang digunakan di
produk. Perangkat dengan model SOC yang sama harus menggunakan konstanta yang sama
dengan sejumlah nilai. Mintalah konstanta yang benar kepada produsen SOC untuk digunakan.
Nilai isian ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan
ekspresi reguler ^([0-9A-Za-z ._/+-]+)$ , TIDAK BOLEH memulai atau
diakhiri dengan spasi kosong, dan TIDAK BOLEH sama dengan "unknown". Kolom ini
TIDAK BOLEH berubah selama masa pakai produk. |
MODEL | Nilai yang dipilih oleh pengimplementasi perangkat yang berisi nama perangkat yang dikenal oleh pengguna akhir. Nama ini HARUS sama dengan nama perangkat dipasarkan dan dijual kepada pengguna akhir. Tidak ada persyaratan di format tertentu untuk {i>field<i} ini, kecuali bahwa itu TIDAK BOLEH nol atau string kosong (""). Bidang ini TIDAK BOLEH berubah selama masa pakai produk. |
PRODUK | Nilai yang dipilih oleh pengimplementasi perangkat yang berisi nama pengembangan
atau nama kode produk tertentu (SKU) yang HARUS unik dalam
merek yang sama. HARUS dapat dibaca manusia, tetapi tidak dimaksudkan untuk dilihat
oleh pengguna akhir. Nilai isian ini HARUS dapat dienkode sebagai ASCII 7-bit dan
cocok dengan ekspresi reguler ^[a-zA-Z0-9_-]+$ . Produk ini
Nama TIDAK BOLEH berubah selama masa pakai produk. |
ODM_SKU | Nilai opsional yang dipilih oleh pengimplementasi perangkat yang berisi
SKU (Unit Penyimpanan Persediaan) yang digunakan untuk melacak konfigurasi tertentu dari
perangkat Anda, misalnya, periferal apa pun yang disertakan dengan perangkat saat dijual.
Nilai isian ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan
ekspresi reguler ^([0-9A-Za-z.,_-]+)$ . |
SERI | HARUS menampilkan "UNKNOWN". |
TAG | Daftar tag yang dipisahkan koma yang dipilih
oleh pengimplementasi perangkat yang
akan semakin membedakan build. Tag HARUS dapat dienkode sebagai ASCII 7-bit
dan cocokkan dengan ekspresi reguler ^[a-zA-Z0-9._-]+ dan HARUS
memiliki salah satu nilai yang sesuai dengan tiga platform Android biasa
konfigurasi penandatanganan: kunci rilis, kunci dev, dan kunci pengujian. |
WAKTU | Nilai yang mewakili stempel waktu saat build terjadi. |
TYPE | Nilai yang dipilih oleh pengimplementasi perangkat yang menentukan runtime konfigurasi build-nya. Kolom ini HARUS memiliki salah satu nilai sesuai dengan tiga konfigurasi waktu proses Android umum: pengguna, userdebug, atau eng. |
PENGGUNA | Nama atau ID pengguna pengguna (atau pengguna otomatis) yang membuat buat. Tidak ada persyaratan untuk format khusus {i>field<i} ini, kecuali bahwa variabel tersebut TIDAK BOLEH berupa nol atau string kosong (""). |
PATCH KEAMANAN&lowbar | Nilai yang menunjukkan level patch keamanan build. HARI INI HARUS menandakan bahwa build tersebut sama sekali tidak rentan terhadap masalah yang dijelaskan melalui Buletin Keamanan Publik Android yang ditunjuk. Harus dalam format [YYYY-MM-DD], yang cocok dengan string yang ditentukan yang didokumentasikan dalam Keamanan Publik Android Buletin atau di 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 Buletin Keamanan Publik Android. {i>Function<i} ini HARUS melaporkan nilai yang benar dan jika build tersebut tidak ada, laporkan string kosong (""). |
BOOTLOADER | Nilai yang dipilih oleh pengimplementasi perangkat yang mengidentifikasi
versi bootloader internal yang digunakan di perangkat, dalam format yang dapat dibaca manusia.
Nilai isian ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan
ekspresi reguler ^[a-zA-Z0-9._-]+$ . |
getRadioVersion() | HARUS (menjadi atau menampilkan) nilai yang dipilih oleh pengimplementasi perangkat
yang mengidentifikasi versi radio/modem
internal yang digunakan dalam perangkat,
dalam format yang dapat dibaca manusia. Jika perangkat tidak memiliki
radio/modem, maka HARUS mengembalikan NULL. Nilai bidang ini HARUS
dapat dienkripsi sebagai ASCII 7-bit dan cocok dengan ekspresi reguler
^[a-zA-Z0-9._-,]+$ . |
getSerial() |
HARUS (atau mengembalikan) nomor seri hardware, yang HARUS tersedia
dan unik di seluruh perangkat dengan MODEL dan MANUFACTURER yang sama. Nilai dari
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 fungsionalitas dari komponen Android lainnya. Project upstream Android menyertakan daftar aplikasi yang mengimplementasikan beberapa pola intent untuk melakukan tindakan umum.
Implementasi perangkat:
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk melakukan pramuat satu atau beberapa aplikasi atau komponen layanan dengan pengendali intent, untuk semua filter intent publik pola yang ditentukan oleh intent aplikasi berikut yang tercantum di sini dan memberikan pemenuhan, yaitu memenuhi ekspektasi developer untuk seperti yang dijelaskan dalam SDK.
Lihat Bagian 2 untuk intent aplikasi wajib untuk setiap jenis perangkat.
3.2.3.2 Resolusi Maksud
[C-0-1] Karena Android adalah platform yang dapat diperluas, implementasi perangkat HARUS mengizinkan setiap pola intent yang dirujuk di bagian 3.2.3.1, kecuali Setelan, yang akan diganti oleh aplikasi pihak ketiga. Tujuan Implementasi open source Android upstream memungkinkan hal ini secara default.
[C-0-2] Implementasi perangkat TIDAK BOLEH memberikan hak istimewa khusus ke sistem pola intent tersebut, atau mencegah aplikasi pihak ketiga dari mengikat ke dan mengasumsikan kontrol atas pola-pola ini. Larangan ini secara khusus mencakup, tetapi tidak terbatas pada, menonaktifkan opsi "Chooser" nama 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 memodifikasi aktivitas default untuk intent.
Namun, implementasi perangkat MUNGKIN menyediakan aktivitas default untuk Pola URI (mis., http://play.google.com) saat aktivitas default memberikan yang lebih spesifik untuk URI data. Misalnya, pola filter intent yang menentukan URI data "http://www.android.com" lebih spesifik dibandingkan pola intent inti browser untuk "http://".
Android juga menyertakan mekanisme bagi aplikasi pihak ketiga untuk mendeklarasikan perilaku penautan aplikasi default yang kredibel untuk jenis intent URI web tertentu. Ketika deklarasi otoritatif tersebut yang ditentukan dalam pola filter intent aplikasi, implementasi perangkat:
- [C-0-4] HARUS mencoba memvalidasi filter intent apa pun dengan menjalankan langkah validasi yang ditentukan dalam spesifikasi Digital Asset Links seperti yang diimplementasikan oleh Pengelola Paket di Open Source Android upstream Proyek.
- [C-0-5] HARUS mencoba validasi filter intent selama penginstalan aplikasi dan menyetel semua filter intent URI yang berhasil divalidasi sebagai pengendali aplikasi default untuk URI-nya.
- MUNGKIN menetapkan filter intent URI tertentu sebagai pengendali aplikasi default untuk URI-nya, jika berhasil diverifikasi tetapi filter URI kandidat lainnya gagal verifikasi. Jika implementasi perangkat melakukan ini, implementasi harus menyediakan sesuai kebutuhan pengguna di menu setelan.
- HARUS memberi pengguna kontrol Link Aplikasi per aplikasi di Setelan sebagai
berikut ini:
- [C-0-6] Pengguna HARUS dapat mengganti aplikasi default secara menyeluruh perilaku tautan untuk aplikasi: selalu terbuka, selalu bertanya, atau tidak pernah membuka, yang harus berlaku untuk semua filter intent URI kandidat secara merata.
- [C-0-7] Pengguna HARUS dapat melihat daftar intent URI kandidat filter.
- Implementasi perangkat MUNGKIN memberi pengguna kemampuan untuk mengganti filter intent URI kandidat tertentu yang berhasil diverifikasi, berdasarkan filter per intent.
- [C-0-8] Implementasi perangkat HARUS memberikan pengguna kemampuan untuk dan mengganti filter intent URI kandidat tertentu jika perangkat memungkinkan beberapa filter intent URI kandidat berhasil verifikasi sementara beberapa yang lain bisa gagal.
3.2.3.3. Namespace Intent
- [C-0-1] Implementasi perangkat TIDAK BOLEH menyertakan komponen Android yang akan mematuhi pola intent siaran atau intent baru menggunakan ACTION, CATEGORY, atau string kunci lainnya di namespace android.* atau com.android.*.
- [C-0-2] Pengimplementasi perangkat TIDAK BOLEH menyertakan komponen Android yang mematuhi pola intent siaran atau intent baru menggunakan ACTION, CATEGORY, atau {i>string<i} kunci lainnya dalam ruang paket milik organisasi lain.
- [C-0-3] Pengimplementasikan perangkat TIDAK BOLEH mengubah atau memperluas intent apa pun pola yang tercantum di bagian 3.2.3.1.
- Implementasi perangkat DAPAT menyertakan pola intent menggunakan namespace dengan jelas dan jelas terkait dengan organisasi mereka sendiri. Larangan ini sama dengan yang ditetapkan untuk class bahasa Java di bagian 3.6.
3.2.3.4. Intent Siaran
Aplikasi pihak ketiga mengandalkan platform untuk menyiarkan intent tertentu ke memberi tahu mereka tentang perubahan dalam lingkungan perangkat keras atau perangkat lunak.
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 pasal 3.5 karena batasan untuk aplikasi latar belakang juga dijelaskan dalam SDK dokumentasi tambahan. Maksud siaran tertentu juga bergantung pada perangkat keras jika perangkat mendukung perangkat keras yang diperlukan, mereka HARUS menyiarkan dan menyediakan perilaku yang sesuai dengan dokumentasi SDK.
3.2.3.5. Intent Aplikasi Bersyarat
Android menyertakan setelan yang menyediakan cara mudah bagi pengguna untuk memilih aplikasi default, misalnya untuk Layar utama atau SMS.
Jika memungkinkan, implementasi perangkat HARUS memberikan setelan yang serupa dan kompatibel dengan pola filter intent dan metode API yang dijelaskan dalam dokumentasi SDK seperti di bawah ini.
Jika implementasi perangkat melaporkan android.software.home_screen
, implementasi tersebut:
- [C-1-1] HARUS mematuhi
android.settings.HOME_SETTINGS
guna menampilkan menu setelan aplikasi default untuk Layar Utama.
Jika implementasi perangkat melaporkan android.hardware.telephony.calling
, implementasi tersebut:
[C-2-1] HARUS menyediakan menu pengaturan yang akan memanggil
android.provider.Telephony.ACTION_CHANGE_DEFAULT
guna menampilkan dialog untuk mengubah aplikasi SMS default.[C-2-2] HARUS mematuhi
android.telecom.action.CHANGE_DEFAULT_DIALER
maksud menampilkan dialog yang memungkinkan pengguna mengubah setelan Telepon default aplikasi.- HARUS menggunakan UI aplikasi Telepon default pilihan pengguna untuk panggilan masuk dan panggilan keluar kecuali untuk panggilan darurat, yang akan menggunakan aplikasi Telepon yang sudah terinstal.
[C-2-3] HARUS mematuhi android.telecom.action.CHANGE_PHONE_ACCOUNTS niat untuk memberikan affordance pengguna guna mengonfigurasi
ConnectionServices
yang terkait denganPhoneAccounts
, seperti serta PhoneAccount{i> default <i}yang akan digunakan oleh gunakan untuk melakukan panggilan keluar. Implementasi AOSP memenuhi persyaratan ini dengan termasuk "opsi Akun Panggilan" pada menu "Panggilan" menu setelan.[C-2-4] HARUS mengizinkan
android.telecom.CallRedirectionService
untuk aplikasi yang menyimpanandroid.app.role.CALL_REDIRECTION
peran.[C-2-5] HARUS memberikan kemampuan kepada pengguna untuk memilih aplikasi yang memiliki
android.app.role.CALL_REDIRECTION
peran.[C-2-6] HARUS mematuhi android.intent.action.SENDTO dan android.intent.action.VIEW dan menyediakan aktivitas untuk mengirim/menampilkan pesan SMS.
[C-SR-1] SANGAT DIREKOMENDASIKAN untuk memenuhi android.intent.action.ANSWER, android.intent.action.CALL android.intent.action.CALL_BUTTON, android.intent.action.VIEW & android.intent.action.DIAL dengan aplikasi dialer bawaan yang dapat menangani intent ini dan menyediakan fulfillment sebagaimana dijelaskan dalam SDK.
Jika implementasi perangkat melaporkan android.hardware.nfc.hce
, implementasi tersebut:
- [C-3-1] HARUS mematuhi android.settings.NFC_PAYMENT_SETTINGS guna menampilkan menu setelan aplikasi {i>default<i} untuk pembayaran Nirsentuh.
- [C-3-2] HARUS mematuhi android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT untuk menampilkan aktivitas yang membuka dialog untuk 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 menerima intent ini android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED & android.nfc.action.TECH_DISCOVERED, untuk menampilkan aktivitas yang memenuhi harapan developer untuk intent ini sebagai yang dijelaskan dalam SDK.
Jika implementasi perangkat melaporkan android.hardware.bluetooth
, implementasi tersebut:
- [C-5-1] HARUS mematuhi 'android.bluetooth.adapter.action.REQUEST_ENABLE' dan menampilkan aktivitas sistem agar pengguna dapat mengaktifkan Bluetooth.
- [C-5-2] HARUS menghormati 'android.bluetooth.adapter.action.REQUEST_DISCOVERABLE' dan menampilkan aktivitas sistem yang meminta mode dapat ditemukan.
Jika implementasi perangkat mendukung fitur DND, implementasi tersebut:
- [C-6-1] HARUS mengimplementasikan aktivitas yang akan merespons intent tersebut
ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS
, yang untuk implementasi dengan UI_MODE_TYPE_NORMAL HARUS berupa aktivitas di mana 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 menambah dan mengonfigurasi
metode input pihak ketiga sebagai respons terhadap
android.settings.INPUT_METHOD_SETTINGS
intent.
Jika implementasi perangkat mendukung layanan aksesibilitas pihak ketiga, implementasi tersebut:
- [C-8-1] HARUS mematuhi
android.settings.ACCESSIBILITY_SETTINGS
untuk menyediakan mekanisme yang dapat diakses pengguna guna mengaktifkan dan menonaktifkan layanan aksesibilitas pihak ketiga beserta aksesibilitas bawaan layanan IT perusahaan mereka.
Jika implementasi perangkat menyertakan dukungan untuk Wi-Fi Easy Connect dan mengekspos fungsi bagi aplikasi pihak ketiga, mereka:
- [C-9-1] HARUS menerapkan Setelan#ACTION_PROGRESS_WiFi_EASY_CONNECT_URI Intent API seperti yang dijelaskan dalam dokumentasi SDK.
Jika implementasi perangkat menyediakan mode penghemat data, implementasi tersebut:
- [C-10-1] HARUS menyediakan antarmuka pengguna di pengaturan, yang menangani
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
memungkinkan pengguna menambah atau menghapus aplikasi dari daftar 'izinkan'.
Jika implementasi perangkat tidak menyediakan mode penghemat data, implementasi tersebut:
- [C-11-1] HARUS memiliki aktivitas yang menangani
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
tapi MUNGKIN menerapkannya sebagai tanpa pengoperasian.
Jika implementasi perangkat mendeklarasikan dukungan untuk kamera melalui
android.hardware.camera.any
, ini:
- [C-12-3] HARUS menangani dan hanya HARUS 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
memanggil UI guna membawa pengguna melalui penambahan administrator perangkat ke sistem (atau mengizinkan mereka menolaknya).[C-13-2] HARUS mengikuti intent android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD & android.app.action.START_ENCRYPTION dan memiliki aktivitas untuk menyediakan fulfillment untuk intent ini seperti yang dijelaskan di SDK di sini.
Jika implementasi perangkat mendeklarasikan android.software.autofill
tombol fitur, yaitu:
- [C-14-1] HARUS sepenuhnya mengimplementasikan
AutofillService
danAutofillManager
API dan mematuhi android.settings.REQUEST_SET_AUTOFILL_SERVICE guna menampilkan menu setelan aplikasi default untuk mengaktifkan dan menonaktifkan isi otomatis dan mengubah layanan isi otomatis default untuk pengguna.
Jika implementasi perangkat menyertakan aplikasi bawaan atau ingin mengizinkan aplikasi pihak ketiga untuk mengakses statistik penggunaan, aplikasi tersebut:
- [C-SR-2] SANGAT DIREKOMENDASIKAN menyediakan mekanisme yang dapat diakses pengguna untuk memberikan
atau mencabut akses ke statistik penggunaan sebagai tanggapan atas
android.settings.ACTION_USAGE_ACCESS_SETTINGS
intent untuk aplikasi yang mendeklarasikan
android.permission.PACKAGE_USAGE_STATS
izin akses.
Jika implementasi perangkat bermaksud melarang aplikasi apa pun, termasuk yang sudah diinstal aplikasi, dari mengakses statistik penggunaan, aplikasi:
- [C-15-1] HARUS masih memiliki aktivitas yang menangani android.settings.ACTION_USAGE_ACCESS_SETTINGS tetapi HARUS mengimplementasikannya sebagai {i>no-op<i}, yaitu memiliki perilaku pengguna seperti saat akses pengguna ditolak.
Jika implementasi perangkat menampilkan link ke aktivitas yang ditentukan oleh AutofillService_passwordsActivity di Setelan atau menautkan ke sandi pengguna melalui mekanisme serupa, keduanya:
- [C-16-1] HARUS menampilkan link tersebut untuk semua layanan isi otomatis yang terinstal.
Jika implementasi perangkat mendukung VoiceInteractionService
dan memiliki lebih banyak
dari satu aplikasi yang menggunakan API ini yang diinstal pada satu waktu, mereka:
- [C-18-1] HARUS mematuhi
android.settings.ACTION_VOICE_INPUT_SETTINGS
guna menampilkan menu setelan aplikasi default untuk masukan suara dan bantuan.
Jika implementasi perangkat melaporkan fitur android.hardware.audio.output
,
mereka:
- [C-SR-3] SANGAT DIREKOMENDASIKAN untuk mematuhi android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA & Intent 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 sebagai Dreams. Penghemat Layar memungkinkan pengguna berinteraksi dengan aplikasi saat perangkat yang terhubung ke sumber listrik tidak ada aktivitas atau terpasang di dok meja. Implementasi Perangkat:
- HARUS menyertakan dukungan untuk screensaver dan menyediakan opsi setelan untuk
pengguna untuk mengonfigurasi
screensaver sebagai respons terhadap
android.settings.DREAM_SETTINGS
.
Jika implementasi perangkat melaporkan android.hardware.nfc.uicc
atau android.hardware.nfc.ese
,
mereka:
- [C-19-1] HARUS menerapkan NfcAdapter.ACTION_TRANSACTION_DETECTED Intent API (sebagai "EVT_TRANSACTION" yang ditentukan oleh Spesifikasi teknis GSM Association TS.26 - NFC Handset Requirements).
3.2.4 Aktivitas di beberapa tampilan sekunder/beberapa tampilan
Jika implementasi perangkat memungkinkan peluncuran Aktivitas Android normal pada lebih dari satu tampilan, mereka:
- [C-1-1] HARUS menyetel
android.software.activities_on_secondary_displays
tombol fitur. - [C-1-2] HARUS menjamin kompatibilitas API yang mirip dengan aktivitas yang berjalan di layar utama.
- [C-1-3] HARUS menempatkan aktivitas baru di tampilan yang sama dengan aktivitas yang
meluncurkannya, saat aktivitas baru diluncurkan tanpa menentukan target
ditampilkan melalui
ActivityOptions.setLaunchDisplayId()
Compute Engine API. - [C-1-4] HARUS menghancurkan semua aktivitas, jika layar dengan
Display.FLAG_PRIVATE
tanda dihapus. - [C-1-5] HARUS menyembunyikan konten dengan aman di semua layar saat perangkat terkunci
dengan layar kunci yang aman, kecuali aplikasi memilih untuk menampilkan di atas kunci
layar menggunakan
Activity#setShowWhenLocked()
Compute Engine API. - HARUS memiliki
android.content.res.Configuration
yang sesuai dengan tampilan itu agar dapat ditampilkan, beroperasi dengan benar, dan mempertahankan kompatibilitas jika suatu aktivitas diluncurkan pada tampilan sekunder.
Jika implementasi perangkat memungkinkan peluncuran Aktivitas Android normal pada platform sekunder dan tampilan sekunder memiliki atribut android.view.Display.FLAG_PRIVATE tanda:
- [C-3-1] Hanya pemilik tampilan, sistem, dan aktivitas yang yang sudah ada di layar itu HARUS dapat diluncurkan. Semua orang dapat meluncurkan ke tampilan yang memiliki android.view.Display.FLAG_PUBLIC penanda.
3.3. Kompatibilitas Native API
Kompatibilitas kode native sulit dilakukan. Karena alasan ini, pengimplementasi perangkat adalah:
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menggunakan implementasi library yang tercantum di bawah ini dari Project Open Source Android upstream.
3.3.1 Antarmuka Biner Aplikasi
Bytecode Dalvik terkelola dapat memanggil kode native yang disediakan di aplikasi
File .apk
sebagai file .so
ELF yang dikompilasi untuk hardware perangkat yang sesuai
tentang arsitektur ini. Karena kode native sangat bergantung pada pemroses yang mendasarinya,
Android dalam teknologinya, Android mendefinisikan sejumlah
Antarmuka Biner Aplikasi (ABI) di
Android NDK.
Implementasi perangkat:
- [C-0-1] HARUS kompatibel dengan satu atau beberapa ABI Android NDK yang telah ditetapkan.
- [C-0-2] HARUS menyertakan dukungan untuk kode yang berjalan di lingkungan terkelola untuk memanggil kode native, menggunakan Java Native Interface (JNI) standar semantik.
- [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 ini.
- [C-0-5] HARUS melaporkan Antarmuka Biner Aplikasi native secara akurat
(ABI) yang didukung oleh perangkat, melalui
android.os.Build.SUPPORTED_ABIS
,android.os.Build.SUPPORTED_32_BIT_ABIS
dan Parameterandroid.os.Build.SUPPORTED_64_BIT_ABIS
, masing-masing dipisahkan koma daftar ABI yang diurutkan dari yang paling banyak ke yang paling tidak disukai.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [C-0-6] HARUS melaporkan, melalui parameter di atas, subkumpulan hal berikut
daftar ABI dan TIDAK BOLEH melaporkan ABI yang tidak ada dalam daftar.
armeabi
(tidak lagi didukung sebagai target oleh NDK)armeabi-v7a
arm64-v8a
x86
x86-64
riscv64
Mengakhiri persyaratan baru
[C-0-7] HARUS membuat semua library berikut, menyediakan API native, yang tersedia untuk aplikasi yang menyertakan kode native:
- libaaudio.so (Dukungan audio native AAudio)
- libamidi.so (dukungan MIDI native, jika fitur
android.software.midi
diklaim sebagaimana dijelaskan dalam Pasal 5.9) - libandroid.so (dukungan aktivitas Android native)
- libc (library C)
- libcamera2ndk.so
- libdl (penaut dinamis)
- libEGL.so (pengelolaan platform OpenGL native)
- libGLESv1_CM.so (OpenGL ES 1.x)
- libGLESv2.so (OpenGL ES 2.0)
- libGLESv3.so (OpenGL ES 3.x)
- libicui18n.so
- libicuuc.so
- {i>libjnigraphics.so<i}
- liblog (logging Android)
- libmediandk.so (dukungan API media native)
- libm (perpustakaan matematika)
- libneuralnetworks.so (Neural Networks API)
- libOpenMAXAL.so (dukungan OpenMAX AL 1.0.1)
- libOpenSLES.so (Dukungan audio OpenSL ES 1.0.1)
- libRS.so
- mdpi++ (Dukungan minimal untuk C++)
- libvulkan.so (Vulkan)
- libz (Kompresi zlib)
- Antarmuka JNI
[C-0-8] TIDAK BOLEH menambahkan atau menghapus fungsi publik untuk library native yang tercantum di atas.
[C-0-9] HARUS mencantumkan library non-AOSP tambahan yang langsung diekspos ke aplikasi pihak ketiga di
/vendor/etc/public.libraries.txt
.[C-0-10] TIDAK BOLEH mengekspos library native lainnya, diimplementasikan dan yang disediakan dalam AOSP sebagai library sistem, kepada aplikasi pihak ketiga yang menarget API 24 atau lebih tinggi karena telah dipesan.
[C-0-11] HARUS mengekspor semua OpenGL ES 3.1 dan Android Extension Pack simbol fungsi sebagaimana didefinisikan dalam NDK, melalui library
libGLESv3.so
. Perhatikan bahwa meskipun semua simbol HARUS ada, bagian 7.1.4.1 menjelaskan persyaratan secara lebih rinci ketika diimplementasikan secara penuh dari masing-masing fungsi-fungsi yang sesuai.[C-0-12] HARUS mengekspor simbol fungsi untuk inti Fungsi Vulkan 1.1 simbol, serta
VK_KHR_surface
,VK_KHR_android_surface
,VK_KHR_swapchain
,VK_KHR_maintenance1
, danVK_KHR_get_physical_device_properties2
ekstensi melalui librarylibvulkan.so
. Perhatikan bahwa meskipun semua simbol HARUS ada, pasal 7.1.4.2 menjelaskan secara lebih mendetail persyaratan kapan implementasi dari setiap fungsi yang sesuai.HARUS dibangun menggunakan kode sumber dan file {i>header<i} yang tersedia di Project Open Source Android upstream.
Perlu diketahui bahwa rilis Android mendatang mungkin memperkenalkan dukungan untuk ABI.
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, sebagaiarmeabi
hanya untuk kompatibilitas mundur dengan aplikasi lama.
Jika implementasi perangkat melaporkan dukungan ABI armeabi-v7a
, untuk aplikasi
menggunakan ABI ini, mereka:
[C-2-1] HARUS menyertakan baris berikut di
/proc/cpuinfo
, dan SEHARUSNYA TIDAK mengubah nilai pada perangkat yang sama, bahkan saat nilai dibaca oleh ABI lain.Features:
, diikuti dengan daftar fitur CPU ARMv7 opsional didukung oleh perangkat.CPU architecture:
, diikuti dengan bilangan bulat yang menjelaskan arsitektur ARM tertinggi yang didukung (misalnya, "8" untuk perangkat ARMv8).
[C-2-2] HARUS selalu menyediakan operasi berikut, bahkan dalam di mana ABI diimplementasikan pada arsitektur ARMv8, baik melalui dukungan CPU native atau melalui emulasi software:
- Petunjuk SWP dan SWPB.
- Operasi barrier CP15ISB, CP15DSB, dan CP15DMB.
[C-2-3] HARUS menyertakan dukungan untuk SIMD Lanjutan (alias neon).
3.4 Kompatibilitas Web
3.4.1 Kompatibilitas WebView
Jika implementasi perangkat menyediakan implementasi lengkap dari
android.webkit.Webview
API, ini:
- [C-1-1] HARUS melaporkan
android.software.webview
. - [C-1-2] HARUS menggunakan build Project Chromium
dari Proyek Open Source Android upstream di Android
15 cabang untuk implementasi
android.webkit.WebView
Compute Engine API. [C-1-3] String agen pengguna yang dilaporkan oleh WebView HARUS dalam format ini:
Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, seperti Gecko) Version/4.0 $(CHROMIUM_VER) Seluler Safari/537,36
- Nilai string $(VERSION) HARUS sama dengan nilai untuk android.os.Build.VERSION.RELEASE.
- String $(MODEL) MUNGKIN kosong, tetapi jika tidak kosong, string tersebut HARUS memiliki nilai yang sama dengan android.os.Build.MODEL.
- "Build/$(BUILD)" MUNGKIN dihilangkan, tetapi jika disertakan, $(BUILD) string HARUS sama dengan nilai untuk android.os.Build.ID.
- Nilai string $(CHROMIUM_VER) HARUS berupa versi Chromium di Project Open Source Android upstream.
- Penerapan perangkat MUNGKIN menghilangkan Seluler dalam string agen pengguna.
Komponen WebView HARUS menyertakan dukungan untuk fitur HTML5 sebanyak dan jika mendukung fitur tersebut SEHARUSNYA mematuhi Spesifikasi HTML5.
[C-1-4] HARUS merender konten yang disediakan atau konten URL jarak jauh dalam suatu proses yang berbeda dari aplikasi yang membuat instance WebView. Secara khusus proses perender terpisah HARUS memiliki hak istimewa yang lebih rendah, jalankan sebagai ID pengguna terpisah, tidak memiliki akses ke direktori data aplikasi, tidak memiliki akses jaringan langsung, dan hanya memiliki akses ke jaringan lokal layanan sistem melalui Binder. Implementasi AOSP dari WebView memenuhi persyaratan ini.
Perhatikan bahwa jika implementasi perangkat adalah 32-bit atau deklarasikan flag fitur
android.hardware.ram.low
, pengguna tersebut dikecualikan dari C-1-3.
3.4.2 Kompatibilitas Browser
Jika implementasi perangkat mencakup aplikasi Browser mandiri untuk pengguna penjelajahan web, mereka:
- [C-1-1] HARUS mendukung masing-masing API yang terkait dengan HTML5:
- [C-1-2] HARUS mendukung HTML5/W3C webstorage API dan SEHARUSNYA mendukung HTML5/W3C UI API. Perhatikan bahwa karena web badan standar pengembangan beralih untuk mendukung IndexedDB daripada webstorage, Responden diharapkan akan menjadi komponen yang diperlukan dalam Android versi mendatang.
- DAPAT mengirimkan string agen pengguna kustom dalam aplikasi Browser mandiri.
- HARUS menerapkan dukungan untuk sebanyak mungkin HTML5 secara mandiri Aplikasi browser (baik berdasarkan Browser WebKit upstream aplikasi atau penggantian pihak ketiga).
Namun, jika implementasi perangkat tidak menyertakan Browser mandiri aplikasi, mereka:
- [C-2-1] Masih harus mendukung pola niat publik seperti yang dijelaskan dalam bagian 3.2.3.1.
3.5. Kompatibilitas Perilaku API
Implementasi perangkat:
- [C-0-9] HARUS memastikan bahwa kompatibilitas perilaku API diterapkan untuk semua aplikasi terinstal kecuali jika dibatasi seperti yang dijelaskan di Bagian 3.5.1.
- [C-0-10] TIDAK BOLEH menerapkan pendekatan daftar yang diizinkan yang memastikan API kompatibilitas perilaku hanya untuk aplikasi yang dipilih oleh perangkat pelaku implementasi.
Perilaku setiap jenis API (terkelola, sementara, native, dan web) harus konsisten dengan implementasi upstream yang lebih disukai Project Open Source Android. Beberapa area spesifik kompatibilitas 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 diberlakukan pada aplikasi latar belakang.
Lebih khususnya, untuk aplikasi latar belakang:
- [C-0-4] mereka HARUS menghentikan eksekusi callback yang didaftarkan oleh
aplikasi untuk menerima output dari
GnssMeasurement
danGnssNavigationMessage
. - [C-0-5] mereka HARUS membatasi frekuensi update yang
yang disediakan ke aplikasi melalui
LocationManager
API atau classWifiManager.startScan()
. - [C-0-6] jika aplikasi menargetkan API level 25 atau yang lebih tinggi, aplikasi TIDAK BOLEH
memungkinkan untuk mendaftarkan penerima siaran
untuk siaran implisit dari
intent Android standar dalam manifes aplikasi, kecuali jika siaran
intent memerlukan
"signature"
atau"signatureOrSystem"
protectionLevel
izin atau berada di daftar pengecualian. - [C-0-7] jika aplikasi menargetkan API level 25 atau yang lebih tinggi, aplikasi HARUS berhenti
layanan latar belakang aplikasi, seolah-olah aplikasi telah memanggil
layanan
stopSelf()
, kecuali aplikasi ditempatkan dalam daftar yang diizinkan sementara untuk menangani tugas yang terlihat oleh pengguna. - [C-0-8] jika aplikasi menargetkan API level 25 atau lebih tinggi, aplikasi HARUS melepas wakelock yang ditahan aplikasi.
- [C-0-4] mereka HARUS menghentikan eksekusi callback yang didaftarkan oleh
aplikasi untuk menerima output dari
- [C-0-11] Perangkat HARUS menampilkan penyedia keamanan berikut sebagai yang pertama
tujuh nilai array dari
Security.getProviders()
dalam urutan tertentu 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 ini.- AndroidNSSP -
android.security.net.config.NetworkSecurityConfigProvider
- AndroidOpenSSL -
com.android.org.conscrypt.OpenSSLProvider
- CertPathProvider -
sun.security.provider.CertPathProvider
- AndroidKeyStoreBCSolution -
android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
- SM -
com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
- HarmonyJSSE -
com.android.org.conscrypt.JSSEProvider
- AndroidKeyStore -
android.security.keystore.AndroidKeyStoreProvider
- AndroidNSSP -
Daftar di atas tidak lengkap. Pengujian Compatibility Test Suite (CTS) bagian yang signifikan dari platform untuk kompatibilitas perilaku, tetapi tidak semuanya. Pelaksana bertanggung jawab untuk memastikan kompatibilitas perilaku dengan Proyek Open Source Android. Karena alasan ini, implementasi perangkat HARUS menggunakan kode sumber yang tersedia melalui Proyek Open Source Android dengan mungkin, daripada mengimplementasikan kembali bagian sistem yang signifikan.
3.5.1 Pembatasan Aplikasi
Jika implementasi perangkat menerapkan mekanisme kepemilikan untuk membatasi aplikasi (mis. mengubah atau membatasi perilaku API yang yang dijelaskan dalam SDK) dan mekanisme tersebut lebih ketat daripada Bucket Aplikasi Standby Terbatas, yaitu:
- [C-1-1] HARUS mengizinkan pengguna melihat daftar aplikasi yang dibatasi.
- [C-1-2] HARUS memberikan kemampuan pengguna untuk mengaktifkan / menonaktifkan semua ini batasan kepemilikan pada setiap aplikasi.
[C-1-3] TIDAK BOLEH menerapkan pembatasan kepemilikan ini secara otomatis tanpa bukti perilaku kesehatan sistem yang buruk, tetapi DAPAT menerapkan pembatasan pada aplikasi setelah deteksi perilaku kesehatan sistem yang buruk seperti penguncian layar yang macet, penguncian layar yang berjalan lama layanan, dan kriteria lainnya. Kriteria tersebut DAPAT ditentukan oleh perangkat tetapi HARUS terkait dengan dampak aplikasi terhadap kondisi sistem. Yang lain kriteria yang tidak sepenuhnya terkait dengan kesehatan sistem, seperti kriteria kurangnya popularitas di pasar, TIDAK BOLEH digunakan sebagai kriteria.
[C-1-4] TIDAK BOLEH menerapkan pembatasan kepemilikan ini secara otomatis untuk aplikasi saat pengguna telah menonaktifkan pembatasan aplikasi secara manual, dan MUNGKIN menyarankan pengguna untuk menerapkan pembatasan kepemilikan ini.
[C-1-5] HARUS memberi tahu pengguna jika pembatasan kepemilikan ini diterapkan pada aplikasi secara otomatis. Informasi tersebut HARUS diberikan dalam periode 24 jam sebelum penerapan pembatasan kepemilikan ini.
[C-1-6] HARUS menampilkan true untuk ActivityManager.isBackgroundRestricted() untuk panggilan API apa pun dari aplikasi.
[C-1-7] TIDAK BOLEH membatasi aplikasi latar depan atas yang secara eksplisit digunakan oleh pengguna.
[C-1-8] HARUS menangguhkan pembatasan eksklusif ini pada aplikasi setiap kali pengguna mulai menggunakan aplikasi secara eksplisit, membuatnya menjadi latar depan teratas aplikasi.
[C-1-10] HARUS menyediakan dokumen atau {i>website<i} yang jelas dan terbuka untuk mendeskripsikan cara penerapan pembatasan eksklusif. Dokumen atau situs web ini HARUS dapat ditautkan dari dokumen Android SDK dan HARUS menyertakan:
- Kondisi pemicu untuk pembatasan kepemilikan.
- Apa dan bagaimana aplikasi dapat dibatasi.
- Cara aplikasi dikecualikan dari pembatasan tersebut.
- Cara aplikasi meminta pengecualian dari pembatasan eksklusif, jika memenuhi mendukung pengecualian tersebut untuk aplikasi yang dapat diinstal pengguna.
Jika aplikasi telah diinstal sebelumnya pada perangkat dan tidak pernah digunakan secara eksplisit oleh pengguna selama lebih dari 30 hari, [C-1-3] [C-1-5] dikecualikan.
Jika implementasi perangkat memperluas batasan aplikasi yang diimplementasikan di AOSP, fitur 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, lalu fitur tersebut:
- [C-1-1] HARUS memenuhi semua persyaratan dalam pasal 3.5.1 kecuali untuk [C-1-6] dan [C-1-3].
- [C-1-2] HARUS menerapkan batasan pada aplikasi saja untuk pengguna jika ada bukti bahwa pengguna tidak menggunakan aplikasi untuk beberapa waktu. Ini SANGAT DIREKOMENDASIKAN menjadi satu bulan atau lebih. Penggunaan HARUS didefinisikan oleh interaksi pengguna yang eksplisit melalui UsageStats#getLastTimeVisible() API atau apa pun yang akan menyebabkan aplikasi berhenti paksa, termasuk binding layanan, binding penyedia konten, siaran eksplisit, dll., yang akan dilacak oleh API UsageStats#getLastTimeAnyComponentUsed() API yang baru.
- [C-1-3] HARUS menerapkan batasan yang memengaruhi semua pengguna perangkat jika ada adalah bukti bahwa paket tersebut tidak digunakan oleh pengguna mana pun selama beberapa waktu baik. Durasi ini SANGAT DIREKOMENDASIKAN menjadi satu bulan atau lebih.
- [C-1-4] TIDAK BOLEH merender aplikasi yang tidak dapat merespons intent aktivitas, binding layanan, permintaan penyedia konten, atau siaran eksplisit.
Hibernasi Aplikasi di AOSP memenuhi persyaratan di atas.
3.6. Namespace API
Android mengikuti konvensi namespace class dan paket yang ditentukan oleh Java yang berpusat pada data (data-centric). Untuk memastikan kompatibilitas dengan aplikasi pihak ketiga, pengimplementasi perangkat TIDAK BOLEH membuat modifikasi terlarang (lihat di bawah) untuk namespace paket berikut:
java.*
javax.*
sun.*
android.*
androidx.*
com.android.*
Artinya, mereka:
- [C-0-1] TIDAK BOLEH memodifikasi API yang diekspos secara publik di platform Android dengan mengubah tanda tangan class atau metode, atau dengan menghapus class atau class kolom.
- [C-0-2] TIDAK BOLEH menambahkan elemen yang diekspos secara publik (seperti class atau antarmuka, atau kolom, atau metode ke class atau antarmuka yang sudah ada) atau atau System API ke API dalam namespace di atas. "diekspos secara publik " adalah konstruksi yang tidak dihiasi dengan karakter "@hide" penanda sebagai digunakan dalam kode sumber Android upstream.
Pengimplementasi perangkat DAPAT memodifikasi implementasi dasar API, tetapi modifikasi tersebut:
- [C-0-3] TIDAK BOLEH mempengaruhi perilaku yang dinyatakan dan tanda tangan bahasa Java semua API yang terekspos secara publik.
- [C-0-4] TIDAK BOLEH diiklankan atau ditampilkan kepada developer.
Namun, pengimplementasi perangkat DAPAT menambahkan API kustom di luar Android standar khusus, namun API kustomnya:
- [C-0-5] TIDAK BOLEH berada dalam namespace yang dimiliki oleh atau merujuk ke penyedia lain
organisasi/pengaturan. 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 perusahaan lain namespace. - [C-0-6] HARUS dikemas dalam library bersama Android sehingga hanya aplikasi yang secara eksplisit menggunakannya (melalui mekanisme <uses-library>) penggunaan memori oleh API tersebut yang meningkat.
Pengimplementasi perangkat DAPAT menambahkan API kustom dalam bahasa native, di luar NDK API, tetapi API kustomnya:
- [C-1-1] TIDAK BOLEH ada di library NDK atau library milik pihak lain organisasi seperti yang dijelaskan di sini.
Jika pengimplementasi perangkat mengusulkan untuk memperbaiki salah satu namespace paket di atas (seperti dengan menambahkan fungsionalitas baru yang berguna ke API yang ada, atau menambahkan API), pengimplementasi HARUS mengunjungi source.android.com dan memulai proses untuk menyampaikan perubahan dan sesuai dengan informasi di situs tersebut.
Perhatikan bahwa pembatasan 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 Kompatibilitas ini Definisi.
3,7 Kompatibilitas Runtime
Implementasi perangkat:
[C-0-1] HARUS mendukung format penuh Dalvik Executable (DEX) serta semantik dan spesifikasi bytecode Dalvik.
[C-0-2] HARUS mengonfigurasi waktu proses Dalvik untuk mengalokasikan memori di sesuai dengan platform Android upstream, dan seperti yang ditetapkan oleh pada tabel berikut. (Lihat bagian 7.1.1 untuk definisi ukuran layar dan kepadatan layar.)
HARUS menggunakan Android RunTime (ART), referensi upstream implementasi Format Dalvik Executable, dan menerapkan referensi implementasi sistem manajemen paket.
HARUS menjalankan uji fuzz dalam berbagai mode eksekusi dan target arsitektur untuk memastikan stabilitas runtime. Rujuk ke JFuzz dan DexFuzz di situs web Proyek Open Source Android.
Perhatikan bahwa nilai memori yang ditentukan di bawah ini dianggap sebagai nilai minimum dan implementasi perangkat DAPAT mengalokasikan lebih banyak memori per aplikasi.
Tata Letak Layar | Kepadatan Layar | Memori Aplikasi Minimum |
---|---|---|
Smartwatch Android | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | ||
160 dpi (mdpi) | ||
180 dpi (180dpi) | ||
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | 36MB | |
240 dpi (hdpi) | ||
280 dpi (280dpi) | ||
320 dpi (xhdpi) | 48MB | |
360 dpi (360dpi) | ||
400 dpi (400dpi) | 56MB | |
420 dpi (420dpi) | 64MB | |
480 dpi (xxhdpi) | 88MB | |
560 dpi (560dpi) | 112MB | |
640 dpi (xxxhdpi) | 154MB | |
kecil/normal | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | ||
160 dpi (mdpi) | ||
180 dpi (180dpi) | 48MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280dpi) | ||
320 dpi (xhdpi) | 80MB | |
360 dpi (360dpi) | ||
400 dpi (400dpi) | 96MB | |
420 dpi (420dpi) | 112MB | |
480 dpi (xxhdpi) | 128MB | |
560 dpi (560dpi) | 192MB | |
640 dpi (xxxhdpi) | 256MB | |
large | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | 48MB | |
160 dpi (mdpi) | ||
180 dpi (180dpi) | 80MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280dpi) | 96MB | |
320 dpi (xhdpi) | 128MB | |
360 dpi (360dpi) | 160MB | |
400 dpi (400dpi) | 192MB | |
420 dpi (420dpi) | 228MB | |
480 dpi (xxhdpi) | 256MB | |
560 dpi (560dpi) | 384MB | |
640 dpi (xxxhdpi) | 512 MB | |
xlarge | 120 dpi (ldpi) | 48MB |
140 dpi (140dpi) | 80MB | |
160 dpi (mdpi) | ||
180 dpi (180dpi) | 96MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280dpi) | 144MB | |
320 dpi (xhdpi) | 192MB | |
360 dpi (360dpi) | 240MB | |
400 dpi (400dpi) | 288MB | |
420 dpi (420dpi) | 336MB | |
480 dpi (xxhdpi) | 384MB | |
560 dpi (560dpi) | 576MB | |
640 dpi (xxxhdpi) | 768MB |
3,8. Kompatibilitas Antarmuka Pengguna
3.8.1 Peluncur (Layar Utama)
Android menyertakan aplikasi peluncur (layar beranda) dan dukungan untuk aplikasi pihak ketiga untuk menggantikan peluncur perangkat (layar beranda).
Jika implementasi perangkat memungkinkan aplikasi pihak ketiga mengganti perangkat layar utama, mereka:
- [C-1-1] HARUS mendeklarasikan fitur platform
android.software.home_screen
. - [C-1-2] HARUS menampilkan
AdaptiveIconDrawable
saat aplikasi pihak ketiga menggunakan tag<adaptive-icon>
untuk memberikan ikon mereka, danPackageManager
metode untuk mengambil ikon dipanggil.
Jika implementasi perangkat menyertakan peluncur default yang mendukung dalam aplikasi penyematan pintasan, yakni:
- [C-2-1] HARUS melaporkan
true
untukShortcutManager.isRequestPinShortcutSupported()
. - [C-2-2] HARUS memiliki kemampuan pengguna untuk menanyakan kepada pengguna sebelum menambahkan pintasan yang diminta
oleh aplikasi melalui
ShortcutManager.requestPinShortcut()
Metode API. - [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 dalam aplikasi pintasan, mereka:
- [C-3-1] HARUS melaporkan
false
untukShortcutManager.isRequestPinShortcutSupported()
.
Jika implementasi perangkat mengimplementasikan peluncur default yang menyediakan akses ke pintasan tambahan yang disediakan oleh aplikasi pihak ketiga melalui ShortcutManager API, fungsi-fungsi tersebut:
- [C-4-1] HARUS mendukung semua fitur pintasan yang didokumentasikan (mis. statis dan
pintasan dinamis, penyematan pintasan) dan menerapkan
ShortcutManager
API.
Jika implementasi perangkat menyertakan aplikasi peluncur default yang menampilkan badge untuk ikon aplikasi, mereka:
- [C-5-1] HARUS mematuhi
NotificationChannel.setShowBadge()
Metode API. Dengan kata lain, tunjukkan kemampuan visual yang terkait dengan ikon aplikasi jika disetel sebagaitrue
, dan tidak menampilkan skema badge ikon aplikasi apa pun jika semuanya saluran notifikasi aplikasi telah menyetel nilainya sebagaifalse
. - DAPAT mengganti badge ikon aplikasi dengan skema badge eksklusif mereka saat
aplikasi pihak ketiga menunjukkan dukungan skema badge eksklusif
melalui penggunaan API eksklusif, tetapi SEHARUSNYA menggunakan resource dan nilai
disediakan melalui API badge notifikasi yang dijelaskan dalam SDK,
seperti
Notification.Builder.setNumber()
danNotification.Builder.setBadgeIconType()
Compute Engine API.
Jika implementasi perangkat mendukung monokrom ikon, ikon ini:
- [C-6-1] HARUS digunakan hanya jika pengguna secara eksplisit mengaktifkannya (mis. melalui Setelan atau menu pemilih wallpaper).
3.8.2 Widget
Android mendukung widget aplikasi pihak ketiga dengan menentukan jenis komponen dan API dan siklus proses yang sesuai yang memungkinkan aplikasi mengekspos "AppWidget" kepada pengguna akhir.
Jika implementasi perangkat mendukung widget aplikasi pihak ketiga, implementasi tersebut:
- [C-1-1] HARUS menyatakan dukungan untuk fitur platform
android.software.app_widgets
. - [C-1-2] HARUS menyertakan dukungan bawaan untuk AppWidgets dan mengekspos kemampuan antarmuka pengguna untuk menambahkan, mengonfigurasi, melihat, dan menghapus AppWidgets
- [C-1-3] HARUS mampu merender widget berukuran 4 x 4 dalam ukuran grid standar. Lihat Panduan Desain Widget Aplikasi di dokumentasi Android SDK untuk mengetahui detailnya.
- MUNGKIN mendukung widget aplikasi di layar kunci.
Jika implementasi perangkat mendukung widget aplikasi pihak ketiga dan dalam aplikasi penyematan pintasan, yakni:
- [C-2-1] HARUS melaporkan
true
untukAppWidgetManager.html.isRequestPinAppWidgetSupported()
. - [C-2-2] HARUS memiliki kemampuan pengguna untuk menanyakan kepada pengguna sebelum menambahkan pintasan yang diminta
oleh aplikasi melalui
AppWidgetManager.requestPinAppWidget()
Metode API.
3.8.3 Notifikasi
Android menyertakan Notification
dan
NotificationManager
API yang memungkinkan developer aplikasi pihak ketiga memberi tahu pengguna tentang peristiwa penting dan
menarik pengguna perhatian pengguna menggunakan komponen perangkat keras (mis. suara, getaran
dan cahaya) dan fitur perangkat lunak (mis. menu notifikasi, bilah sistem)
perangkat seluler.
3.8.3.1 Presentasi Notifikasi
Jika implementasi perangkat memungkinkan aplikasi pihak ketiga untuk memberi tahu pengguna tentang peristiwa penting, aplikasi tersebut:
- [C-1-1] HARUS mendukung notifikasi yang menggunakan fitur hardware, seperti dijelaskan dalam dokumentasi SDK, dan sebisa mungkin dengan penerapan perangkat perangkat keras. Misalnya, jika implementasi perangkat menyertakan vibrator, implementasi itu HARUS menerapkan API vibrasi dengan benar. Jika implementasi perangkat tidak perangkat keras, API terkait HARUS diimplementasikan sebagai tanpa pengoperasian. Perilaku ini dijelaskan lebih lanjut di bagian 7.
- [C-1-2] HARUS merender semua resource dengan benar (ikon, file animasi, dll.) yang disediakan dalam API, atau dalam Panduan gaya ikon Status/Bar Sistem, meskipun mereka MUNGKIN memberikan pengalaman pengguna alternatif untuk notifikasi daripada yang disediakan oleh penerapan Open Source Android referensi.
- [C-1-3] HARUS menghormati dan menerapkan dengan benar perilaku yang dijelaskan untuk API untuk memperbarui, menghapus, dan mengelompokkan notifikasi.
- [C-1-4] HARUS memberikan perilaku lengkap NotificationChannel API yang didokumentasikan dalam SDK.
- [C-1-5] HARUS menyediakan {i>affordance<i} pengguna untuk memblokir dan memodifikasi notifikasi aplikasi pihak ketiga per tingkat paket aplikasi dan saluran.
- [C-1-6] Juga HARUS menyediakan affordance pengguna untuk menampilkan notifikasi yang dihapus saluran TV Anda.
[C-1-7] HARUS merender semua resource dengan benar (gambar, stiker, ikon, dll.) yang diberikan melalui Notification.MessagingStyle di samping teks notifikasi tanpa interaksi pengguna tambahan. Sebagai contoh, HARUS menampilkan semua sumber daya termasuk ikon yang disediakan melalui android.app.Person dalam percakapan grup yang diatur melalui setGroupPercakapan.
[C-SR-1] SANGAT DIREKOMENDASIKAN untuk menyediakan {i>affordance<i} bagi pengguna untuk mengontrol notifikasi yang diekspos ke aplikasi yang telah diberi Izin Pemroses Notifikasi. Perincian tersebut HARUS sedemikian rupa sehingga pengguna dapat kontrol untuk setiap pemroses notifikasi tersebut, jenis notifikasi apa di-jembatani ke pemroses ini. Jenisnya HARUS mencakup "percakapan", "pemberitahuan", "senyap", dan "sedang berlangsung yang penting" notifikasi.
[C-SR-2] SANGAT DIREKOMENDASIKAN menyediakan kemampuan bagi pengguna untuk menentukan aplikasi yang dikecualikan agar tidak memberi tahu pemroses notifikasi tertentu.
[C-SR-3] SANGAT DIREKOMENDASIKAN untuk secara otomatis menampilkan kemampuan pengguna untuk memblokir notifikasi aplikasi pihak ketiga tertentu per setiap saluran dan aplikasi level paket setelah pengguna menutup notifikasi itu beberapa kali.
SEHARUSNYA mendukung notifikasi yang beragam.
HARUS menyajikan beberapa notifikasi dengan prioritas yang lebih tinggi sebagai notifikasi pendahuluan.
SEHARUSNYA memiliki kemampuan pengguna untuk menunda notifikasi.
MUNGKIN hanya mengelola visibilitas dan waktu kapan aplikasi pihak ketiga dapat memberi tahu pengguna peristiwa penting untuk mengurangi masalah keselamatan seperti gangguan pengemudi.
Android 11 memperkenalkan dukungan untuk notifikasi percakapan, yang notifikasi yang menggunakan MessagingStyle dan memberikan ID Pintasan Orang yang dipublikasikan.
Implementasi perangkat:
- [C-SR-4] SANGAT DIREKOMENDASIKAN untuk mengelompokkan dan menampilkan
conversation notifications
sebelum notifikasi non-percakapan dengan pengecualian notifikasi layanan latar depan berkelanjutan danimportance:high
notifikasi.
Jika implementasi perangkat mendukung conversation notifications
dan aplikasi menyediakan data
yang diperlukan untuk
bubbles
, iklan tersebut:
- [C-SR-5] SANGAT DIREKOMENDASIKAN untuk menampilkan percakapan ini sebagai balon. Implementasi AOSP memenuhi persyaratan ini dengan UI Sistem default, Setelan, dan Peluncur.
Jika implementasi perangkat mendukung notifikasi lengkap, implementasi tersebut:
- [C-2-1] HARUS menggunakan sumber daya yang tepat sebagai
disediakan melalui
Notification.Style
Class API dan subclass-nya untuk elemen resource yang disajikan. - HARUS menyajikan setiap dan setiap elemen sumber daya (mis.
ikon, judul, dan teks ringkasan) yang ditentukan dalam
Notification.Style
Class API dan subclass-nya.
Notifikasi pendahuluan adalah notifikasi yang ditampilkan kepada pengguna saat mereka masuk secara terpisah dari platform tempat pengguna kueri. Jika implementasi perangkat mendukung peringatan dini notifikasi, maka mereka:
- [C-3-1] HARUS menggunakan tampilan notifikasi peringatan dini dan resource
sebagaimana dijelaskan dalam
Notification.Builder
Class API saat notifikasi pendahuluan ditampilkan. - [C-3-2] HARUS menampilkan tindakan yang diberikan melalui
Notification.Builder.addAction()
bersama dengan konten notifikasi tanpa interaksi pengguna tambahan sebagaimana dijelaskan dalam SDK.
3.8.3.2. Layanan Pendengar Notifikasi
Android menyertakan NotificationListenerService
API yang memungkinkan aplikasi (yang sekali secara eksplisit diaktifkan oleh pengguna) untuk menerima salinan
semua notifikasi saat diposting atau diperbarui.
Implementasi perangkat:
- [C-0-1] HARUS memperbarui notifikasi dengan benar dan segera secara keseluruhan untuk semua layanan pemroses yang diinstal dan diaktifkan pengguna, termasuk setiap dan semua metadata yang dilampirkan ke objek Notification.
- [C-0-2] HARUS mematuhi
snoozeNotification()
Panggilan API, dan menutup notifikasi serta melakukan callback setelah penundaan yang disetel dalam panggilan API.
Jika implementasi perangkat memiliki kemampuan pengguna untuk menunda notifikasi, implementasi tersebut:
- [C-1-1] HARUS mencerminkan status notifikasi yang ditunda dengan benar
melalui API standar seperti
NotificationListenerService.getSnoozedNotifications()
- [C-1-2] HARUS menyediakan kemampuan pengguna ini untuk menunda notifikasi dari setiap aplikasi pihak ketiga yang terinstal, kecuali jika aplikasi tersebut berasal dari persisten/layanan latar depan.
3.8.3.3. DND (Jangan Ganggu) / Mode Prioritas
Jika implementasi perangkat mendukung fitur DND (juga disebut Mode Prioritas), mereka:
- [C-1-1] HARUS, karena ketika implementasi perangkat telah menyediakan sarana bagi pengguna untuk memberikan atau menolak aplikasi pihak ketiga untuk mengakses konfigurasi kebijakan DND, tampilkan Aturan DND otomatis dibuat oleh aplikasi bersama dengan aturan yang dibuat pengguna dan yang telah ditetapkan.
- [C-1-3] HARUS mematuhi
suppressedVisualEffects
nilai yang diteruskan diNotificationManager.Policy
dan jika aplikasi telah menyetel salah satu opsi SUPPRESSED_Effect_SCREEN_OFF atau SUPPRESSED_EXTERNAL_SCREEN_ON, ini SEHARUSNYA menunjukkan kepada pengguna bahwa efek visual disembunyikan di menu setelan DND.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
3.8.3.4. Perlindungan Notifikasi Sensitif
Informasi notifikasi sensitif mencakup konten seperti sandi sekali pakai, kode konfirmasi satu kali, dan kode otentikasi atau pengaturan ulang serupa yang dapat muncul di notifikasi kepada pengguna.
Jika implementasi perangkat mengizinkan aplikasi pihak ketiga untuk memberi tahu pengguna tentang peristiwa penting, mereka:
[C-1-1] HARUS menyamarkan informasi notifikasi sensitif agar tidak diteruskan ke pemroses notifikasi, kecuali jika layanan pemroses adalah salah satu dari:
- Aplikasi yang ditandatangani sistem dengan
uid
< 10.000 - UI Sistem
- Shell
- Aplikasi Perangkat Pendamping yang Ditetapkan (ditentukan oleh
CompanionDeviceManager
) SYSTEM_AUTOMOTIVE_PROJECTION
peranSYSTEM_NOTIFICATION_INTELLIGENCE
peran- Peran HOME
- Aplikasi yang ditandatangani sistem dengan
Implementasi AOSP dari
NotificationAssistantServices
contoh dan memenuhi persyaratan tersebut. Lihat
android.ext.services.notification
sebagai contoh.
Mengakhiri persyaratan baru
3.8.4. Assist API
Android menyertakan Assist API untuk memungkinkan aplikasi memilih berapa banyak informasi dari konteks saat ini dibagikan dengan asisten di perangkat.
Jika implementasi perangkat mendukung tindakan Assist, implementasi tersebut:
- [C-2-1] HARUS menunjukkan dengan jelas kepada pengguna akhir ketika konteks dibagikan, dengan
antara:
- Setiap kali aplikasi bantuan mengakses konteks, menampilkan pesan putih cahaya di sekitar tepi layar yang sesuai atau melebihi durasi dan kecerahan implementasi Project Open Source Android.
- Untuk aplikasi bantuan bawaan, yang memberikan kemampuan pengguna lebih sedikit dari dua navigasi yang jauh dari menu setelan input suara dan aplikasi asisten default, dan hanya membagikan konteks ketika aplikasi bantuan secara eksplisit dipanggil oleh pengguna melalui kata cepat atau membantu input tombol navigasi.
- [C-2-2] Interaksi yang ditunjuk untuk meluncurkan aplikasi bantuan seperti yang dijelaskan
di bagian 7.2.3 HARUS meluncurkan properti
aplikasi bantuan, dengan kata lain aplikasi yang mengimplementasikan
VoiceInteractionService
, atau aktivitas yang menangani intentACTION_ASSIST
.
3.8.5. Pemberitahuan dan Toast
Aplikasi dapat menggunakan Toast
API untuk menampilkan string non-modal pendek kepada pengguna akhir yang menghilang setelah
jangka waktu singkat, dan menggunakan TYPE_APPLICATION_OVERLAY
window type API untuk menampilkan jendela peringatan sebagai overlay di atas aplikasi lain.
Jika implementasi perangkat menyertakan output layar atau video, implementasi tersebut:
[C-1-1] HARUS menyediakan affordance pengguna untuk memblokir aplikasi agar tidak menampilkan pemberitahuan jendela yang menggunakan
TYPE_APPLICATION_OVERLAY
. Implementasi AOSP memenuhi persyaratan ini dengan memiliki kontrol di menu notifikasi.[C-1-2] HARUS mematuhi Toast API dan menampilkan Toast dari aplikasi kepada pengguna akhir dengan terlihat.
3.8.6. Tema
Android menyediakan "tema" sebagai mekanisme bagi aplikasi untuk menerapkan gaya di seluruh seluruh Aktivitas atau aplikasi.
Android menyertakan "Holo" dan "Material" keluarga tema sebagai kumpulan gaya yang ditentukan untuk digunakan pengembang aplikasi jika mereka ingin mencocokkan Tampilan dan nuansa tema Holo seperti yang ditetapkan oleh Android SDK.
Jika implementasi perangkat menyertakan output layar atau video, implementasi tersebut:
- [C-1-1] TIDAK BOLEH mengubah atribut tema Holo apa pun yang diekspos menggunakan berbagai aplikasi obrolan.
- [C-1-2] HARUS mendukung "Material" kelompok tema dan TIDAK BOLEH mengubah Atribut tema Material atau aset mereka yang terekspos aplikasi.
[C-1-3] HARUS mengatur "sans-serif" jenis font menjadi Roboto versi 2.x untuk bahasa yang didukung Roboto, atau menyediakan kemampuan pengguna untuk mengubah {i>font<i} yang digunakan untuk "sans-serif" jenis font menjadi Roboto versi 2.x untuk bahasa yang didukung Roboto.
[C-1-4] HARUS menghasilkan palet tonal warna dinamis seperti yang ditentukan dalam AOSP dokumentasi
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 disebutkan dalam
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
dokumentasi (lihatandroid.theme.customization.theme_styles
), yaituTONAL_SPOT
,VIBRANT
,EXPRESSIVE
,SPRITZ
,RAINBOW
,FRUIT_SALAD
, danMONOCHROMATIC
."Warna sumber" digunakan untuk menghasilkan palet tonal warna dinamis ketika dikirim dengan
android.theme.customization.system_palette
(seperti yang didokumentasikan dalamSettings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
).[C-1-6] HARUS memiliki nilai kroma
CAM16
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 disediakan yang sesuai persyaratan warna sumber di atas.
Android juga menyertakan "Default Perangkat" keluarga tema sebagai kumpulan gaya yang ditentukan untuk digunakan pengembang aplikasi jika mereka ingin menyesuaikan tampilan dan nuansa tema perangkat seperti yang ditetapkan oleh pengimplementasi perangkat.
- Implementasi perangkat DAPAT mengubah Atribut tema default Perangkat yang diekspos menggunakan berbagai aplikasi obrolan.
Android mendukung tema varian dengan bilah sistem transparan, yang memungkinkan developer aplikasi Anda untuk mengisi area di belakang status dan menu navigasi dengan konten aplikasi mereka. Untuk memberikan pengalaman developer yang konsisten dalam besar, gaya ikon {i>status bar<i} harus dipertahankan di seluruh implementasi perangkat yang berbeda.
Jika implementasi perangkat menyertakan status bar sistem, implementasi tersebut:
- [C-2-1] HARUS gunakan warna putih untuk ikon status sistem (seperti kekuatan sinyal dan level baterai) dan notifikasi yang dikeluarkan oleh sistem, kecuali jika ikon menunjukkan status bermasalah atau aplikasi meminta status bar lampu menggunakan kode WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS penanda.
- [C-2-2] Implementasi perangkat Android HARUS mengubah warna sistem ikon status menjadi hitam (untuk detailnya, lihat R.style) saat aplikasi meminta {i>status bar<i} lampu.
3.8.7. Wallpaper Animasi
Android mendefinisikan jenis komponen dan API serta siklus proses terkait yang memungkinkan aplikasi untuk mengekspos satu atau lebih "Wallpaper Animasi" kepada pengguna akhir. Wallpaper animasi adalah animasi, pola, atau gambar yang serupa dengan kemampuan input terbatas yang ditampilkan sebagai wallpaper, di balik menggunakan berbagai aplikasi obrolan.
Hardware dianggap mampu menjalankan wallpaper animasi dengan andal jika dapat dijalankan semua wallpaper animasi, tanpa batasan fungsi, pada bingkai yang wajar tingkat tinggi tanpa adanya efek samping pada aplikasi lain. Jika batasan dalam hardware menyebabkan wallpaper dan/atau aplikasi error, gagal berfungsi, mengonsumsi daya CPU atau baterai yang berlebihan, atau beroperasi pada kecepatan {i>frame<i} yang sangat rendah, hardware dianggap tidak mampu menjalankan wallpaper animasi. Sebagai contoh, beberapa wallpaper animasi dapat menggunakan konteks OpenGL 2.0 atau 3.x untuk merender kontennya. Wallpaper animasi tidak akan berfungsi dengan baik pada hardware yang tidak mendukung banyak Konteks OpenGL karena penggunaan wallpaper animasi dari konteks OpenGL mungkin mengalami konflik dengan aplikasi lain yang juga menggunakan konteks OpenGL.
- Implementasi perangkat yang mampu menjalankan wallpaper animasi secara andal seperti yang dijelaskan di atas HARUS menerapkan wallpaper animasi.
Jika implementasi perangkat menerapkan wallpaper animasi, implementasi tersebut:
- [C-1-1] HARUS melaporkan tanda fitur platform android.software.live_wallpaper.
3.8.8. Pengalihan Aktivitas
Kode sumber Android upstream menyertakan layar ringkasan, antarmuka pengguna tingkat sistem untuk pengalihan tugas dan menampilkan akses yang baru saja diakses aktivitas dan tugas menggunakan gambar thumbnail dari pada saat pengguna terakhir kali meninggalkan aplikasi.
Implementasi perangkat termasuk tombol navigasi fungsi terbaru seperti yang dijelaskan dalam bagian 7.2.3 DAPAT mengubah antarmuka.
Jika implementasi perangkat menyertakan tombol navigasi fungsi terbaru seperti yang dijelaskan dalam bagian 7.2.3 mengubah antarmuka, yaitu:
- [C-1-1] HARUS mendukung setidaknya hingga 7 aktivitas yang ditampilkan.
- Setidaknya HARUS menampilkan judul 4 aktivitas sekaligus.
- HARUS menampilkan warna sorotan, ikon, judul layar dalam terbaru.
- SEHARUSNYA menampilkan kemampuan penutup ("x") tetapi MUNGKIN menundanya hingga pengguna berinteraksi dengan layar.
- HARUS terapkan pintasan untuk beralih dengan mudah ke aktivitas sebelumnya.
- SEHARUSNYA memicu tindakan beralih cepat di antara dua opsi yang terakhir digunakan aplikasi, saat tombol fungsi terbaru diketuk dua kali.
- HARUS memicu mode multi-aplikasi layar terpisah, jika didukung, saat tombol fungsi terbaru ditekan lama.
- DAPAT menampilkan konten terbaru yang berafiliasi sebagai kelompok yang bergerak bersama.
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menggunakan pengguna Android upstream (atau antarmuka berbasis thumbnail yang 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_Method dan mendukung IME API seperti yang didefinisikan dalam dokumentasi Android SDK.
3.8.10. Kontrol Media Layar Kunci
Remote Control Client API tidak digunakan lagi dari Android 5.0 untuk mendukung Template Notifikasi Media yang memungkinkan aplikasi media berintegrasi dengan kontrol pemutaran yang yang ditampilkan di layar kunci.
3.8.11. Screensaver (sebelumnya Dreams)
Lihat bagian 3.2.3.5 untuk mengetahui setelan untuk menggabungkan screensaver.
3.8.12. Lokasi
Jika implementasi perangkat menyertakan sensor hardware (mis. GPS) yang mendukung untuk memberikan koordinat lokasi, aplikasi ini
- [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 mampu merender karakter emoji ini dalam glyph warna.
- [C-1-2] HARUS menyertakan dukungan untuk:
- Font Roboto 2 dengan ketebalan yang berbeda—sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-hitam, sans-serif-kondensasi, sans-serif-kondensasi-light untuk bahasa yang tersedia pada perangkat.
- Cakupan Unicode 7.0 lengkap dari bahasa Latin, Yunani, dan Cyrillic, termasuk Rentang Perluasan A, B, C, dan D Latin, dan semua glyph dalam mata uang simbol Unicode 7.0.
- [C-1-3] TIDAK BOLEH menghapus atau mengubah NotoColorEmoji.tff di image sistem. (Anda dapat menambahkan font emoji baru untuk mengganti emoji NotoColorEmoji.tff)
- HARUS mendukung warna kulit dan beragam emoji keluarga sebagaimana ditentukan dalam Laporan Teknis Unicode #51.
Jika implementasi perangkat menyertakan IME, implementasi tersebut:
- HARUS menyediakan metode input kepada pengguna untuk karakter emoji ini.
Android menyertakan dukungan untuk merender font Myanmar. Myanmar memiliki beberapa font yang tidak sesuai dengan Unicode, umumnya dikenal sebagai "Zawgyi", untuk merender Myanmar bahasa.
Jika implementasi perangkat menyertakan dukungan untuk Burma, implementasi tersebut:
- [C-2-1] HARUS merender teks dengan font Unicode sesuai standar sebagai default; font yang tidak sesuai dengan Unicode TIDAK BOLEH ditetapkan sebagai font default kecuali jika memilihnya di pemilih bahasa.
- [C-2-2] HARUS mendukung font Unicode dan font yang tidak sesuai dengan Unicode jika font yang tidak sesuai dengan Unicode didukung di perangkat. Bukan Unicode yang sesuai TIDAK BOLEH menghapus atau menimpa font Unicode.
- [C-2-3] HARUS merender teks dengan font yang tidak sesuai dengan Unicode HANYA JIKA kode bahasa dengan Qaag kode skrip ditentukan (mis. my-Qaag). Tidak ada bahasa ISO atau kode wilayah lain (baik ditetapkan, tidak ditetapkan, atau dicadangkan) dapat digunakan untuk merujuk ke font yang mematuhi kebijakan untuk Myanmar. Pengembang aplikasi dan penulis laman web dapat menentukan my-Qaag sebagai kode bahasa yang ditentukan seperti yang dilakukan bahasa lain.
3.8.14. Multi-aplikasi
Jika implementasi perangkat memiliki kemampuan untuk menampilkan beberapa aktivitas dengan pada saat yang sama, mereka:
- [C-1-1] HARUS mengimplementasikan mode multi-aplikasi tersebut sesuai dengan perilaku aplikasi dan API yang dijelaskan dalam Android SDK dokumentasi dukungan mode multi-aplikasi dan persyaratan berikut:
- [C-1-2] HARUS mematuhi
android:resizeableActivity
yang disetel oleh aplikasi dalam fileAndroidManifest.xml
seperti yang dijelaskan dalam SDK ini. - [C-1-3] TIDAK BOLEH menawarkan mode layar terpisah atau format bebas jika tinggi layar kurang dari 440 dp dan lebar layar kurang dari 440 dp.
- [C-1-4] Aktivitas TIDAK BOLEH diubah ukurannya ke ukuran yang lebih kecil dari 220 dp mode multi-aplikasi selain Picture-in-Picture.
- Penerapan perangkat dengan ukuran layar
xlarge
SEHARUSNYA mendukung bentuk bebas mode.
Jika implementasi perangkat mendukung mode multi-aplikasi, dan layar terpisah tersebut, mereka:
- [C-2-2] HARUS memangkas aktivitas yang dipasang ke dok dari multi-aplikasi layar terpisah tetapi SEHARUSNYA menampilkan sebagian kontennya, jika aplikasi Peluncur adalah jendela yang difokuskan.
- [C-2-3] HARUS mematuhi
AndroidManifestLayout_minWidth
yang dinyatakan danAndroidManifestLayout_minHeight
aplikasi peluncur pihak ketiga dan tidak mengganti nilai ini selama menampilkan beberapa konten dari aktivitas yang dipasang ke dok.
Jika implementasi perangkat mendukung mode multi-aplikasi dan Picture-in-Picture mode multi-aplikasi, mode tersebut:
- [C-3-1] HARUS meluncurkan aktivitas dalam mode multi-aplikasi picture-in-picture
saat aplikasi:
* Menargetkan API level 26 atau 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 dalam SystemUI mereka sebagai
ditentukan oleh aktivitas PIP saat ini melalui
setActions()
Compute Engine 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 ditetapkan oleh aktivitas PIP melalui
setAspectRatio()
Compute Engine API. - [C-3-4] HARUS menggunakan
KeyEvent.KEYCODE_WINDOW
untuk mengontrol jendela PIP; jika mode PIP tidak diterapkan, tombol HARUS yang tersedia untuk aktivitas latar depan. - [C-3-5] HARUS memberikan kemampuan pengguna untuk memblokir aplikasi agar tidak ditampilkan di Mode PIP; implementasi AOSP memenuhi persyaratan ini dengan memiliki di menu notifikasi.
[C-3-6] HARUS mengalokasikan lebar dan tinggi minimum berikut untuk PIP saat aplikasi tidak mendeklarasikan nilai apa pun
AndroidManifestLayout_minWidth
danAndroidManifestLayout_minHeight
:- Perangkat dengan Configuration.uiMode yang disetel selain
UI_MODE_TYPE_TELEVISION
HARUS mengalokasikan lebar dan tinggi minimum 108 dp. - Perangkat dengan Configuration.uiMode yang disetel ke
UI_MODE_TYPE_TELEVISION
HARUS mengalokasikan lebar minimum 240 dp dan tinggi minimum 135 dp.
- Perangkat dengan Configuration.uiMode yang disetel selain
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Jika implementasi perangkat menyertakan lebih dari satu yang kompatibel dengan Android area tampilan dan membuat area tersebut tersedia untuk aplikasi, yaitu:
- [C-4-1] HARUS mendukung mode multi-aplikasi.
Jika implementasi perangkat mendukung mode multi-aplikasi, implementasi tersebut:
- [C-5-1] HARUS menerapkan versi Ekstensi Window Manager yang benar
level API seperti yang dijelaskan dalam
WindowManager
Ekstensi.
Mengakhiri persyaratan baru
3.8.15. Potongan Layar
Android mendukung Cutout Layar seperti yang dijelaskan
dalam dokumen SDK. DisplayCutout
API menentukan
area di tepi layar yang mungkin tidak berfungsi untuk aplikasi
karena potongan layar atau tampilan melengkung di tepi.
Jika implementasi perangkat menyertakan potongan layar, implementasi tersebut:
- [C-1-5] TIDAK BOLEH memiliki potongan jika rasio aspek perangkat adalah 1,0 (1:1).
- [C-1-2] TIDAK BOLEH memiliki lebih dari satu potongan per tepi.
- [C-1-3] HARUS mematuhi flag potongan layar yang ditetapkan oleh aplikasi melalui
WindowManager.LayoutParams
seperti yang dijelaskan dalam SDK. - [C-1-4] HARUS melaporkan nilai yang benar untuk semua metrik potongan yang ditentukan dalam
API
DisplayCutout
.
3.8.16. Kontrol Perangkat
Android menyertakan ControlsProviderService
dan Control
API untuk memungkinkan aplikasi pihak ketiga memublikasikan kontrol perangkat untuk
status dan tindakan untuk pengguna.
Lihat Pasal 2_2_3 untuk mengetahui persyaratan khusus perangkat.
3.8.17. Papan klip
Implementasi perangkat:
- [C-0-1] TIDAK BOLEH mengirim data papan klip ke komponen, aktivitas, layanan, atau di seluruh koneksi jaringan apa pun, tanpa tindakan eksplisit dari pengguna (misalnya, menekan di overlay), kecuali untuk layanan yang disebutkan dalam 9.8.6 Pengambilan Konten dan Penelusuran Aplikasi.
Jika implementasi perangkat menghasilkan pratinjau yang terlihat oleh pengguna saat konten disalin
ke papan klip untuk item ClipData
apa pun dengan
ClipData.getDescription().getExtras()
berisi
android.content.extra.IS_SENSITIVE
, mereka:
- [C-1-1] HARUS menyamarkan pratinjau yang terlihat oleh pengguna
Implementasi referensi AOSP memenuhi persyaratan papan klip ini.
3,9. Administrasi Perangkat
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Android menyertakan fitur yang memungkinkan keamanan sadar
aplikasi aktifkan
aplikasi pengontrol kebijakan perangkat untuk melakukan
fungsi administrasi perangkat pada tingkat sistem, seperti menerapkan {i>password<i}
atau menghapus total data dari jarak jauh, melalui
Android Device Administration API
Device Policy Manager API.
- [C-1-1] HARUS mendeklarasikan
android.software.device_admin
. - [C-1-2] HARUS mendukung penyediaan pemilik perangkat sebagaimana dijelaskan dalam pasal 3.9.1 dan bagian 3.9.1.1.
Mengakhiri persyaratan baru
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
sebagaimana dijelaskan di bawah ini:
- Ketika implementasi perangkat memiliki
baik pengguna maupun
data pengguna yang dikonfigurasi, maka:
- [C-1-5] HARUS mendaftarkan aplikasi DPC sebagai aplikasi Pemilik Perangkat
atau mengaktifkan aplikasi DPC untuk memilih apakah
menjadi Pemilik Perangkat atau Pemilik Profil,
jika perangkat mendeklarasikan dukungan Komunikasi Nirkabel Jarak Dekat (NFC) melalui
tombol fitur
android.hardware.nfc
dan menerima pesan NFC berisi kumpulan data dengan jenis MIMEMIME_TYPE_PROVISIONING_NFC
. - [C-1-8] HARUS mengirim ACTION_GET_PROVISIONING_MODE
setelah penyediaan pemilik perangkat dipicu sehingga
Aplikasi DPC dapat memilih apakah akan menjadi Pemilik Perangkat atau Profil
Pemilik, 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 mengirimkan ACTION_ADMIN_POLICY_COMPLIANCE ke aplikasi Pemilik Perangkat jika Pemilik Perangkat telah dibuat selama penyediaan, apa pun metode penyediaan yang digunakan. Tujuan pengguna tidak boleh 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
menjadi Pemilik Perangkat atau Pemilik Profil,
jika perangkat mendeklarasikan dukungan Komunikasi Nirkabel Jarak Dekat (NFC) melalui
tombol fitur
- Ketika implementasi perangkat memiliki
pengguna atau
data pengguna, fungsi ini:
- [C-1-7] HARUS mendaftarkan aplikasi DPC apa pun sebagai Aplikasi Pemilik Perangkat lagi.
- Ketika implementasi perangkat memiliki
baik pengguna maupun
data pengguna yang dikonfigurasi, maka:
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
[C-1-2] HARUS menunjukkan pemberitahuan pengungkapan yang sesuai (seperti seperti yang direferensikan dalam AOSP) dan mendapatkan izin afirmatif dari pengguna akhir sebelum aplikasi digunakan 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 sertakan hak milik solusi pengelolaan perangkat dan menyediakan mekanisme untuk mempromosikan aplikasi yang dikonfigurasi dalam solusi mereka sebagai "Pemilik Perangkat setara" ke "Device Owner" standar seperti yang diakui oleh Perangkat melakukannya API, keduanya:[C-2-1] HARUS memiliki proses untuk memverifikasi bahwa aplikasi tertentu dipromosikan milik pengelolaan perangkat perusahaan yang sah dan telah dikonfigurasi dalam solusi eksklusif agar memiliki hak yang setara sebagai "Pemilik Perangkat".
[C-2-2] HARUS menampilkan pengungkapan izin Pemilik Perangkat AOSP yang sama dengan alur yang dimulai oleh
android.app.action.PROVISION_MANAGED_DEVICE
sebelum mendaftarkan aplikasi DPC sebagai "Device Owner".[C-2-3] TIDAK BOLEH meng-hardcode persetujuan atau mencegah penggunaan aplikasi pemilik perangkat lainnya.
Mengakhiri persyaratan baru
3.9.1.2 Penyediaan profil terkelola
Jika implementasi perangkat mendeklarasikan android.software.managed_users
, implementasi tersebut:
- [C-1-1] HARUS menerapkan API memungkinkan aplikasi {i>Device Policy Controller<i} (DPC) menjadi pemilik Profil Terkelola baru.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [C-1-2] Proses penyediaan profil terkelola (alur yang dimulai oleh DPC menggunakan android.app.action.PROVISION_MANAGED_PROFILE) atau platform), layar izin dan pengalaman pengguna HARUS selaras dengan implementasi AOSP.
Mengakhiri persyaratan baru
[C-1-3] HARUS memberikan kemampuan pengguna berikut dalam Pengaturan untuk menunjukkan kepada pengguna ketika fungsi sistem tertentu telah dinonaktifkan oleh {i>Device Policy Controller<i} (DPC):
- Ikon yang konsisten atau kemampuan pengguna lainnya (misalnya upstream ikon info AOSP) untuk mewakili saat setelan tertentu dibatasi oleh Admin Perangkat.
- Pesan penjelasan singkat, sebagaimana diberikan oleh Admin Perangkat melalui
setShortSupportMessage
- Ikon aplikasi DPC.
[C-1-4] HARUS meluncurkan pengendali untuk ACTION_PROVISIONING_SUCCESSFUL di profil kerja jika Pemilik Profil ditetapkan saat dimulai oleh android.app.action.PROVISION_MANAGED_PROFILE dan DPC telah menerapkan pengendali.
[C-1-5] HARUS mengirim ACTION_PROFILE_PROVISIONING_SELESAI disiarkan ke DPC profil kerja jika penyediaan dimulai oleh android.app.action.PROVISION_MANAGED_PROFILE intent.
[C-1-6] HARUS mengirim ACTION_GET_PROVISIONING_MODE setelah penyediaan pemilik profil dipicu sehingga aplikasi DPC dapat memilih apakah akan menjadi Pemilik Perangkat atau Pemilik Profil, kecuali jika akan dipicu oleh intent android.app.action.PROVISION_MANAGED_PROFILE.
[C-1-7] HARUS mengirimkan ACTION_ADMIN_POLICY_COMPLIANCE ke profil kerja saat Pemilik Profil dibuat selama Penyediaan, apa pun metode penyediaan yang digunakan kecuali saat penyediaan dipicu oleh intent android.app.action.PROVISION_MANAGED_PROFILE. Pengguna tidak boleh melanjutkan di Wizard Penyiapan hingga Profil Aplikasi pemilik selesai.
[C-1-8] HARUS mengirim ACTION_MANAGED_PROFILE_PROVISIONED menyiarkan ke DPC profil pribadi ketika Pemilik Profil sudah 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
android.app.admin.DevicePolicyManager
Google Cloud Platform. - [C-1-2] HARUS mengizinkan pembuatan satu profil dan hanya satu profil terkelola.
- [C-1-3] HARUS menggunakan badge ikon (mirip dengan badge kerja upstream AOSP) untuk menunjukkan aplikasi dan widget terkelola serta elemen UI dengan badge lainnya seperti Terbaru & Notifikasi.
- [C-1-4] HARUS menampilkan ikon notifikasi (mirip dengan pekerjaan upstream AOSP badge) untuk menunjukkan saat pengguna berada dalam aplikasi profil terkelola.
- [C-1-5] HARUS menampilkan toast yang menunjukkan bahwa pengguna berada di bucket membuat profil jika dan saat perangkat aktif (ACTION_USER_PRESENT) dan aplikasi latar depan berada dalam profil terkelola.
- [C-1-6] Jika ada profil terkelola, HARUS menunjukkan kemampuan visual di 'Pemilih' Intent memungkinkan pengguna meneruskan intent dari antarmuka ke pengguna utama atau sebaliknya, jika diaktifkan oleh Kebijakan Perangkat. Pengontrol.
- [C-1-7] Apabila ada profil terkelola, HARUS memperlihatkan pengguna berikut
kemampuan untuk pengguna utama dan profil terkelola:
- Pencatatan terpisah untuk baterai, lokasi, data seluler, dan penggunaan penyimpanan untuk pengguna utama dan profil terkelola.
- Pengelolaan independen atas Aplikasi VPN yang diinstal di dalam instance pengguna atau profil terkelola.
- Pengelolaan independen atas aplikasi yang diinstal dalam pengguna utama atau profil terkelola.
- Pengelolaan independen atas akun dalam pengguna utama atau akun terkelola untuk profil.
- [C-1-8] HARUS memastikan aplikasi telepon, kontak, dan pesan bawaan dapat menelusuri dan mencari informasi penelepon dari nomor telepon terkelola (jika ada) di samping profil utama, jika Pengontrol Kebijakan Perangkat mengizinkannya.
- [C-1-9] HARUS memastikan bahwa solusi ini memenuhi semua persyaratan keamanan berlaku untuk perangkat dengan beberapa pengguna yang diaktifkan (lihat bagian 9.5), meskipun profil terkelola tidak dihitung sebagai pengguna lain selain pengguna utama.
- [C-1-10] HARUS memastikan bahwa data screenshot disimpan di profil kerja
saat tangkapan layar diambil dengan
topActivity
jendela yang memiliki fokus (yang terakhir berinteraksi dengan pengguna di antara semua aktivitas) dan termasuk aplikasi profil kerja. - [C-1-11] TIDAK BOLEH merekam konten layar lainnya (kolom sistem, notifikasi atau konten profil pribadi apa pun) kecuali untuk profil kerja window/jendela aplikasi saat menyimpan screenshot ke profil kerja (untuk memastikan bahwa data profil tidak disimpan di profil kerja).
Jika implementasi perangkat mendeklarasikan android.software.managed_users
dan
android.software.secure_lock_screen
, mereka:
- [C-2-1] HARUS mendukung kemampuan untuk menentukan rapat layar kunci yang terpisah
persyaratan berikut untuk memberikan akses ke aplikasi yang berjalan di
khusus profil bisnis Anda.
- Implementasi perangkat HARUS mematuhi
DevicePolicyManager.ACTION_SET_NEW_PASSWORD
dan menampilkan antarmuka untuk mengonfigurasi layar kunci terpisah untuk profil terkelola. - Kredensial layar kunci dari profil terkelola HARUS menggunakan kredensial yang sama mekanisme penyimpanan dan pengelolaan kredensial sebagai profil induk, seperti yang didokumentasikan dalam Situs Project Open Source Android.
- Kebijakan sandi DPC
HARUS berlaku hanya untuk kredensial layar kunci profil terkelola, kecuali jika
dipanggil ke instance
DevicePolicyManager
yang ditampilkan olehgetParentProfileInstance
.
- Implementasi perangkat HARUS mematuhi
- Kapan kontak dari profil terkelola ditampilkan di log panggilan bawaan, UI dalam panggilan, sedang berlangsung dan panggilan tak terjawab notifikasi, kontak, dan aplikasi pesan yang SEHARUSNYA diberi lencana 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 menyediakan kemampuan pengguna untuk keluar dari pengguna saat ini dan
beralih kembali ke pengguna utama
dalam sesi multi-pengguna ketika
isLogoutEnabled
akan menampilkantrue
. Kemampuan pengguna HARUS dapat diakses dari layar kunci tanpa membuka kunci perangkat.
Jika implementasi perangkat mendeklarasikan android.software.device_admin
dan menyediakan
kemampuan pengguna di perangkat untuk menambahkan Pengguna sekunder tambahan, mereka:
- [C-SR-1] SANGAT DIREKOMENDASIKAN menunjukkan izin Pemilik Perangkat AOSP yang sama pengungkapan yang ditampilkan dalam alur yang dimulai oleh android.app.action.PROVISION_MANAGED_DEVICE, sebelum mengizinkan akun ditambahkan di Pengguna sekunder baru, agar pengguna memahami bahwa perangkat itu dikelola.
3.9.4. Persyaratan Peran Pengelolaan Kebijakan Perangkat
Jika implementasi perangkat melaporkan android.software.device_admin
atau
android.software.managed_users
, lalu mereka:
- [C-1-1] HARUS mendukung peran pengelolaan kebijakan perangkat seperti yang didefinisikan dalam
pasal 9.1. Aplikasi yang memiliki peran pengelolaan kebijakan perangkat
DAPAT ditentukan dengan menyetel
config_devicePolicyManagement
ke nama paket. Nama paket HARUS diikuti dengan:
dan sertifikat penandatanganan, kecuali jika aplikasi sudah dipramuat.
Jika nama paket tidak ditentukan untuk config_devicePolicyManagement
sebagai
dijelaskan di atas:
- [C-2-1] Implementasi perangkat HARUS mendukung penyediaan tanpa perangkat aplikasi pemegang peran pengelolaan kebijakan (AOSP menyediakan implementasi referensi).
Jika nama paket ditetapkan untuk config_devicePolicyManagement
seperti yang dijelaskan
di atas:
- [C-3-1] Aplikasi HARUS diinstal pada semua profil untuk pengguna.
- [C-3-2] Implementasi perangkat MUNGKIN menentukan aplikasi yang mengupdate
pemegang peran pengelolaan kebijakan perangkat sebelum penyediaan dengan menyetel
config_devicePolicyManagementUpdater
.
Jika nama paket ditetapkan untuk config_devicePolicyManagementUpdater
sebagai
dijelaskan di atas:
- [C-4-1] Aplikasi HARUS diprainstal pada perangkat.
- [C-4-2] Aplikasi HARUS mengimplementasikan filter intent yang mengatasi
android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER
.
3.9.5. Framework Resolusi Kebijakan Perangkat
Jika implementasi perangkat melaporkan android.software.device_admin
atau
android.software.managed_users
, lalu mereka:
- [C-1-1] HARUS menyelesaikan konflik kebijakan perangkat seperti yang didokumentasikan dalam Framework Resolusi Kebijakan Perangkat.
3.10. Aksesibilitas
Android menyediakan lapisan aksesibilitas yang membantu pengguna difabel untuk menavigasi perangkat mereka dengan lebih mudah. Selain itu, Android menyediakan API platform yang memungkinkan implementasi layanan aksesibilitas untuk menerima callback untuk pengguna dan peristiwa sistem serta menghasilkan mekanisme umpan balik alternatif, seperti text-to-speech, respons haptik, dan navigasi trackball/d-pad.
Jika implementasi perangkat mendukung layanan aksesibilitas pihak ketiga, implementasi tersebut:
- [C-1-1] HARUS menyediakan implementasi aksesibilitas Android seperti yang dijelaskan dalam accessibility API dokumentasi SDK.
- [C-1-2] HARUS menghasilkan peristiwa aksesibilitas dan memberikan
AccessibilityEvent
untuk semua yang terdaftarAccessibilityService
seperti yang didokumentasikan dalam SDK. - [C-1-4] HARUS menyediakan kemampuan pengguna untuk mengontrol aksesibilitas layanan yang mendeklarasikan AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON. Perhatikan bahwa untuk implementasi perangkat dengan menu navigasi sistem, SEHARUSNYA berikan pilihan kepada pengguna untuk sebuah tombol di di bilah navigasi untuk mengontrol layanan ini.
Jika implementasi perangkat menyertakan layanan aksesibilitas bawaan, implementasi tersebut:
- [C-2-1] HARUS mengimplementasikan layanan aksesibilitas bawaan ini Direct Boot Aware aplikasi jika 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 {i>font<i}, ukuran layar dan gestur pembesaran.
3.11. Text-to-Speech
Android menyertakan API yang memungkinkan aplikasi menggunakan text-to-speech (TTS) dan memungkinkan penyedia layanan menyediakan implementasi TTS layanan IT perusahaan mereka.
Jika implementasi perangkat melaporkan fitur android.hardware.audio.output, mereka:
- [C-1-1] HARUS mendukung Framework TTS Android Google Cloud Platform.
Jika implementasi perangkat mendukung penginstalan mesin TTS pihak ketiga, implementasi tersebut:
- [C-2-1] HARUS memberikan kemampuan pengguna untuk memungkinkan pengguna memilih TTS untuk digunakan di tingkat sistem.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
3.12. Framework Input TV
Android Television Input Framework (TIF) menyederhanakan penayangan konten live ke perangkat Android Televisi. TIF menyediakan standar API 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 input berbasis TIF pihak ketiga {i>service<i} dapat diinstal dan digunakan pada perangkat.
Mengakhiri persyaratan baru
3.13. Setelan Cepat
Android menyediakan komponen UI Setelan Cepat yang memungkinkan akses cepat ke tindakan yang sering digunakan atau diperlukan segera.
Jika implementasi perangkat menyertakan komponen UI Setelan Cepat dan mendukung pihak ketiga Setelan Cepat, fungsi ini:
- [C-1-1] HARUS mengizinkan pengguna menambah atau menghapus petak peta yang disediakan melalui
quicksettings
API dari aplikasi pihak ketiga. - [C-1-2] TIDAK BOLEH menambahkan kartu secara otomatis dari aplikasi pihak ketiga secara langsung ke Setelan Cepat.
- [C-1-3] HARUS menampilkan semua kartu yang ditambahkan pengguna dari aplikasi pihak ketiga di samping kartu pengaturan 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:
[C-1-2] HARUS menampilkan ikon yang diperoleh melalui
getIconBitmap()
ataugetIconUri()
dan judul dengan jelas diperoleh melaluigetTitle()
sebagaimana dijelaskan dalamMediaDescription
. Dapat mempersingkat judul untuk mematuhi peraturan keselamatan (misalnya gangguan bagi pengemudi).[C-1-3] HARUS tampilkan ikon aplikasi pihak ketiga setiap kali menampilkan konten yang disediakan oleh aplikasi pihak ketiga ini.
[C-1-4] HARUS mengizinkan pengguna untuk berinteraksi dengan seluruh
MediaBrowser
hierarki sebelumnya. DAPAT membatasi akses ke bagian hierarki untuk mematuhi peraturan keamanan (misalnya gangguan bagi pengemudi), tetapi TIDAK BOLEH memberikan perlakuan istimewa berdasarkan konten atau penyedia konten lainnya.[C-1-5] HARUS mempertimbangkan ketukan dua kali pada
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 persyaratan:
- [C-1-1] Aplikasi Instan hanya HARUS diberi izin yang memiliki
android:protectionLevel
disetel ke"instant"
. - [C-1-2] Aplikasi Instan TIDAK BOLEH berinteraksi dengan aplikasi terinstal melalui intent implisit
kecuali jika salah satu kondisi berikut terpenuhi:
- Filter pola intent komponen terekspos dan memiliki CATEGORY_BROWSABLE
- Tindakan adalah salah satu dari ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
- Target secara eksplisit diekspos dengan android:visibleToInstantApps
- [C-1-3] Aplikasi Instan TIDAK BOLEH berinteraksi secara eksplisit dengan aplikasi terinstal kecuali jika ditampilkan melalui android:visibleToInstantApps.
- [C-1-4] Aplikasi Terinstal TIDAK BOLEH melihat detail tentang Aplikasi Instan di perangkat kecuali Aplikasi Instan secara eksplisit tersambung ke aplikasi yang telah diinstal.
Implementasi perangkat HARUS memberikan kemampuan pengguna berikut untuk berinteraksi dengan Aplikasi Instan. AOSP memenuhi persyaratan dengan {i>System UI<i}, Setelan, dan Peluncur {i>default<i}. Implementasi perangkat:
- [C-1-5] HARUS memberikan kemampuan pengguna untuk melihat dan menghapus Aplikasi Instan di-cache secara lokal untuk setiap paket aplikasi.
- [C-1-6] HARUS memberikan notifikasi pengguna persisten yang dapat
diciutkan saat Aplikasi Instan berjalan di latar depan. Pengguna ini
notifikasi HARUS menyertakan bahwa Aplikasi Instan tidak memerlukan penginstalan
dan menyediakan affordance pengguna yang mengarahkan pengguna ke aplikasi
layar info di Setelan. Untuk Aplikasi Instan yang diluncurkan melalui intent web, seperti
ditentukan menggunakan intent dengan tindakan yang ditetapkan ke
Intent.ACTION_VIEW
dan dengan skema "http" atau "https", {i>affordance<i} tambahan HARUS memungkinkan pengguna untuk tidak meluncurkan Aplikasi Instan dan meluncurkan tautan yang terkait dengan browser web yang terkonfigurasi, jika sebuah {i>browser<i} yang tersedia di perangkat. - [C-1-7] HARUS mengizinkan aplikasi Instan berjalan untuk diakses dari tab Terbaru jika fungsi Terbaru tersedia di perangkat.
[C-1-8] HARUS melakukan pramuat satu atau beberapa aplikasi atau komponen layanan dengan pengendali intent untuk intent yang tercantum dalam SDK di sini dan membuat intent terlihat untuk Aplikasi Instan.
3.16. Penyandingan Perangkat Pendamping
Android menyertakan dukungan untuk penyambungan perangkat pendamping agar dapat mengelola dengan lebih efektif
atribusi dengan perangkat pendamping dan memberikan CompanionDeviceManager
API untuk aplikasi untuk mengakses fitur ini.
Jika implementasi perangkat mendukung fitur penyambungan perangkat pendamping, implementasi tersebut:
- [C-1-1] HARUS mendeklarasikan tombol fitur
FEATURE_COMPANION_DEVICE_SETUP
kami. - [C-1-2] HARUS memastikan API di
android.companion
paket diimplementasikan sepenuhnya.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [C-1-3] HARUS memberikan kemampuan pengguna bagi pengguna untuk memilih/mengonfirmasi perangkat pendamping ada dan dapat digunakan, yang HARUS menggunakan pesan yang sama seperti yang diimplementasikan dalam AOSP tanpa penambahan atau modifikasi.
Mengakhiri persyaratan baru
3.17. Aplikasi Berat
Jika implementasi perangkat mendeklarasikan fitur FEATURE_CANT_SAVE_STATE
,
maka mereka:
- [C-1-1] HARUS memiliki satu aplikasi terinstal saja yang menentukan
cantSaveState
yang berjalan di dalam sistem pada satu waktu. Jika pengguna keluar dari aplikasi tersebut tanpa keluar secara eksplisit (misalnya dengan menekan ketika keluar dari aktivitas aktif sistem, bukan menekan tombol kembali tanpa aktivitas aktif tersisa dalam sistem), maka implementasi perangkat HARUS memprioritaskan aplikasi itu di RAM seperti halnya untuk hal-hal yang diharapkan tetap berjalan, seperti layanan latar depan. Saat aplikasi tersebut berada di latar belakang, sistem tetap dapat menerapkan daya akses ke jaringan Anda, seperti membatasi akses CPU dan jaringan. - [C-1-2] HARUS menyediakan affordance UI untuk memilih aplikasi yang tidak
berpartisipasi dalam mekanisme penyimpanan/pemulihan status normal setelah pengguna
meluncurkan aplikasi kedua yang dideklarasikan dengan
cantSaveState
. - [C-1-3] TIDAK BOLEH menerapkan perubahan kebijakan lain untuk aplikasi yang menentukan
cantSaveState
, seperti mengubah performa CPU atau mengubah prioritas penjadwalan.
Jika implementasi perangkat tidak mendeklarasikan fitur
FEATURE_CANT_SAVE_STATE
,
maka mereka:
- [C-1-1] HARUS mengabaikan
cantSaveState
yang disetel oleh aplikasi dan TIDAK BOLEH mengubah perilaku aplikasi berdasarkan .
3.18. Kontak
Android menyertakan
Contacts Provider
API untuk memungkinkan aplikasi mengelola informasi kontak yang disimpan di perangkat.
Data kontak yang dimasukkan langsung ke perangkat biasanya disinkronkan
dengan layanan web, tetapi datanya MUNGKIN hanya berada secara lokal di perangkat.
Kontak yang hanya disimpan di perangkat disebut sebagai kontak
kontak.
RawContacts
"dikaitkan dengan" atau "disimpan di" sebuah
Akun
ketika
ACCOUNT_NAME
,
dan
ACCOUNT_TYPE
,
kolom untuk kontak mentah cocok dengan
Nama.akun
dan
Account.type
kolom akun.
Akun lokal default: akun untuk kontak mentah yang hanya disimpan di
perangkat dan tidak terkait dengan Akun di
AccountManager,
yang dibuat dengan nilai null untuk
ACCOUNT_NAME
,
dan
ACCOUNT_TYPE
,
seperti baris dan kolom.
Akun lokal kustom: akun untuk kontak mentah yang hanya disimpan di
perangkat Anda dan tidak terkait dengan Akun
di {i>AccountManager<i}, yang
dibuat dengan setidaknya satu nilai non-null untuk
ACCOUNT_NAME
,
dan
ACCOUNT_TYPE
,
seperti baris dan kolom.
Implementasi perangkat:
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk tidak membuat akun lokal kustom.
Jika penerapan perangkat menggunakan akun lokal kustom:
- [C-1-1]
ACCOUNT_NAME
, dari akun lokal kustom HARUS dikembalikan olehContactsContract.RawContacts.getLocalAccountName
- [C-1-2]
ACCOUNT_TYPE
, dari akun lokal kustom HARUS dikembalikan olehContactsContract.RawContacts.getLocalAccountType
- [C-1-3] Kontak mentah yang dimasukkan oleh aplikasi pihak ketiga dengan
akun lokal default (yaitu dengan menyetel nilai null untuk
ACCOUNT_NAME
danACCOUNT_TYPE
) HARUS disisipkan ke lokal kustom menggunakan akun layanan. - [C-1-4] Kontak mentah yang dimasukkan ke akun lokal kustom TIDAK BOLEH dihapus saat akun ditambahkan atau dihapus.
- [C-1-5] Menghapus operasi yang dilakukan pada akun lokal kustom
HARUS mengakibatkan kontak mentah langsung dihapus (seolah-olah
CALLER_IS_SYNCADAPTER
param disetel ke true), meskipun parameterCALLER\_IS\_SYNCADAPTER
disetel salah atau tidak ditentukan.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
3.19. Setelan Bahasa
Implementasi perangkat:
- [C-0-1] TIDAK BOLEH memberikan kemampuan kepada pengguna untuk memilih berdasarkan gender perlakuan bahasa untuk bahasa yang tidak mendukung spesifik per gender penerjemahan mesin. Lihat referensi tata bahasa untuk informasi selengkapnya.
Mengakhiri persyaratan baru
4. Kompatibilitas Pengemasan Aplikasi
Implementasi perangkat:
[C-0-1] HARUS mampu menginstal dan menjalankan ".apk" Android file sebagai yang dihasilkan oleh perintah "aapt" yang disertakan dalam Android SDK resmi.
- Karena persyaratan di atas mungkin sulit, implementasi perangkat DIREKOMENDASIKAN untuk menggunakan manajemen paket implementasi referensi AOSP sistem file.
[C-0-2] HARUS mendukung verifikasi ".apk" file menggunakan APK Signature Scheme v3.1, APK Signature Scheme v3, APK Signature Scheme v2 dan penandatanganan JAR.
[C-0-3] TIDAK BOLEH memperluas .apk, Manifes Android, Bytecode Dalvik, atau Memformat bytecode RenderScript sedemikian rupa sehingga akan mencegah file tersebut agar tidak menginstal dan berjalan dengan benar pada perangkat lain yang kompatibel.
[C-0-4] TIDAK BOLEH mengizinkan aplikasi selain yang saat ini "installer data" agar paket diam-diam meng-uninstal aplikasi tanpa konfirmasi pengguna, seperti yang didokumentasikan dalam SDK untuk
DELETE_PACKAGE
izin akses. Satu-satunya pengecualian adalah penanganan aplikasi pemverifikasi paket sistem PACKAGE_NEEDS_VERIFICATION dan penanganan aplikasi pengelola penyimpanan ACTION_MANAGE_STORAGE intent.[C-0-5] HARUS memiliki aktivitas yang menangani
android.settings.MANAGE_UNKNOWN_APP_SOURCES
intent.[C-0-6] TIDAK BOLEH menginstal paket aplikasi dari aplikasi yang tidak dikenal sumber, kecuali aplikasi yang meminta penginstalan memenuhi semua persyaratan berikut:
- ID tersebut HARUS mendeklarasikan
REQUEST_INSTALL_PACKAGES
izin atau menyetelandroid:targetSdkVersion
pada 24 atau lebih rendah. - Aplikasi HARUS diberi izin oleh pengguna untuk menginstal aplikasi dari sumber tidak dikenal.
- ID tersebut HARUS mendeklarasikan
HARUS menyediakan kemampuan pengguna untuk memberikan/mencabut izin untuk menginstal aplikasi dari sumber tidak dikenal per aplikasi, tetapi BISA memilih untuk menerapkannya ini sebagai tanpa pengoperasian dan tampilkan
RESULT_CANCELED
untukstartActivityForResult()
jika implementasi perangkat tidak ingin pengguna memiliki pilihan ini. Namun, bahkan dalam kasus tersebut, tanda itu HARUS menunjukkan kepada pengguna mengapa tidak ada pilihan tersebut disajikan.[C-0-7] HARUS menampilkan dialog peringatan dengan string peringatan yang disediakan melalui API sistem
PackageManager.setHarmfulAppWarning
kepada pengguna sebelum meluncurkan aktivitas dalam aplikasi yang telah ditandai oleh API sistem yang samaPackageManager.setHarmfulAppWarning
dengan berbahaya.SEHARUSNYA memberi pengguna pilihan untuk meng-uninstal atau meluncurkan aplikasi pada dialog peringatan.
[C-0-8] HARUS menerapkan 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 di bagian 5.1
untuk setiap codec yang dideklarasikan oleh
MediaCodecList
. - [C-0-2] HARUS mendeklarasikan dan melaporkan dukungan encoder, decoder yang tersedia
ke aplikasi pihak ketiga melalui
MediaCodecList
- [C-0-3] HARUS dapat mendekode dengan benar dan menyediakannya untuk pihak ketiga
aplikasi semua format yang dapat dienkode. Ini mencakup semua bitstream yang
yang dihasilkan encoder dan profil yang dilaporkan dalam
CamcorderProfile
Implementasi perangkat:
- SEHARUSNYA mengincar latensi codec minimum, dengan kata lain,
- TIDAK BOLEH menggunakan dan menyimpan buffer input dan hanya menampilkan buffer input setelah diproses.
- TIDAK BOLEH menyimpan buffer hasil dekode lebih lama dari yang ditentukan oleh standar (mis. SPS).
- TIDAK BOLEH berpegang pada buffer yang dienkode, lebih lama dari yang dibutuhkan oleh GOP karena ada berbagai struktur penetapan harga.
Semua codec yang tercantum pada bagian di bawah ini disediakan sebagai perangkat lunak implementasi dalam implementasi Android pilihan dari proses Project Sumber.
Harap perhatikan bahwa baik Google maupun Open Handset Alliance menyatakan bahwa codec ini bebas dari paten pihak ketiga. Mereka berniat untuk menggunakan kode sumber ini dalam produk perangkat keras atau perangkat lunak disarankan implementasi kode ini, termasuk dalam perangkat lunak {i>open source<i} 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
,
modul ini 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
android.media.MediaCodec
Compute Engine API.
5.1.2 Dekode Audio
Lihat detail selengkapnya di 5.1.3. Detail Codec Audio.
Jika implementasi perangkat mendeklarasikan dukungan untuk
android.hardware.audio.output
, 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 (Peningkatan AAC+)
- [C-1-4] AAC ELD (Peningkatan AAC penundaan rendah)
- [C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile, yang mencakup Profil Dasar Pengukuran USAC, dan Dynamic Range ISO/IEC 23003-4 Profil Kontrol)
- [C-1-5] FLAC
- [C-1-6] MP3
- MIDI [C-1-7]
- [C-1-8] Vorbis
- [C-1-9] PCM/WAVE termasuk audio resolusi tinggi memformat hingga 24 bit, frekuensi sampel 192 kHz, dan 8 saluran. Perhatikan bahwa persyaratan ini hanya untuk decoding, dan bahwa perangkat diizinkan untuk mengurangi sampel dan {i>downmix<i} selama fase pemutaran.
- [C-1-10] Opus
Jika implementasi perangkat mendukung decoding buffer input AAC pada
streaming multisaluran (yaitu lebih dari dua saluran) ke PCM melalui
Decoder audio AAC di android.media.MediaCodec
API, berikut ini HARUS
didukung:
- [C-2-1] Decoding HARUS dilakukan tanpa downmixing (misalnya 5.0 AAC streaming harus didekode ke lima saluran PCM, streaming 5.1 AAC harus didekode hingga enam saluran PCM).
- [C-2-2] Metadata rentang dinamis HARUS seperti yang didefinisikan dalam "Kontrol Rentang Dinamis
(RDK)" di ISO/IEC 14496-3, dan kunci DRC
android.media.MediaFormat
ke mengonfigurasi perilaku terkait rentang dinamis pada decoder audio. Tujuan Kunci DRC AAC diperkenalkan di API 21, dan meliputi: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 DIREKOMENDASIKAN bahwa persyaratan C-2-1 dan C-2-2 di atas adalah dipenuhi oleh semua decoder audio AAC.
Saat mendekode audio USAC, MPEG-D (ISO/IEC 23003-4):
- [C-3-1] Metadata DRC dan Loudness HARUS ditafsirkan dan diterapkan menurut MPEG-D DRC Dynamic Range Control Profile Level 1.
- [C-3-2] Decoder HARUS berperilaku sesuai dengan konfigurasi
ditetapkan dengan kunci
android.media.MediaFormat
berikut:KEY_AAC_DRC_TARGET_REFERENCE_LEVEL
danKEY_AAC_DRC_EFFECT_TYPE
.
Decoder profil MPEG-4 AAC, HE AAC, dan HE AACv2:
- Mungkin mendukung kontrol kenyaringan dan rentang dinamis menggunakan ISO/IEC 23003-4 Profil Kontrol Rentang Dinamis.
Jika ISO/IEC 23003-4 didukung dan jika ISO/IEC 23003-4 dan Metadata ISO/IEC 14496-3 ada dalam bitstream yang didekode, maka:
- Metadata ISO/IEC 23003-4 AKAN diutamakan.
Semua dekoder audio HARUS mendukung pembuatan output:
- [C-6-1] Frame audio urutan byte native PCM 16-bit melalui
android.media.MediaCodec
Compute Engine API.
Jika implementasi perangkat mendukung decoding buffer input AAC pada
streaming multisaluran (yaitu lebih dari dua saluran) ke PCM melalui
Decoder audio AAC di android.media.MediaCodec
API, maka yang berikut HARUS
didukung:
- [C-7-1] HARUS dapat dikonfigurasi oleh aplikasi menggunakan decoding
dengan kunci
KEY_MAX_OUTPUT_CHANNEL_COUNT
mengontrol apakah konten di-downmix ke stereo (saat menggunakan nilai 2) atau merupakan output menggunakan jumlah saluran native (saat menggunakan nilai yang sama dengan lebih besar dari angka tersebut). Misalnya nilai 6 atau lebih besar akan mengkonfigurasi sebuah decoder untuk menghasilkan 6 saluran saat diberi makan konten 5.1. - [C-7-2] Saat melakukan dekode, decoder HARUS mengiklankan mask saluran yang digunakan
format output dengan
KEY_CHANNEL_MASK
kunci, menggunakan konstantaandroid.media.AudioFormat
(contoh:CHANNEL_OUT_5POINT1
).
Jika implementasi perangkat mendukung decoder audio selain AAC default decoder audio dan dapat menghasilkan output audio multi-channel (yaitu lebih dari 2 saluran) saat menerima konten multi-saluran terkompresi, lalu:
- [C-SR-2] Decoder SANGAT DIREKOMENDASIKAN agar dapat dikonfigurasi oleh
aplikasi menggunakan decoding dengan kunci
KEY_MAX_OUTPUT_CHANNEL_COUNT
mengontrol apakah konten di-downmix ke stereo (saat menggunakan nilai 2) atau merupakan output menggunakan jumlah saluran native (saat menggunakan nilai yang sama dengan lebih besar dari angka tersebut). Misalnya nilai 6 atau lebih besar akan mengkonfigurasi sebuah decoder untuk menghasilkan 6 saluran saat diberi makan konten 5.1. - [C-SR-3] Saat melakukan dekode, decoder SANGAT DIREKOMENDASIKAN untuk mengiklankan
channel mask digunakan pada format output dengan
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 standar frekuensi sampling antara 8 hingga 48 kHz. |
|
Profil MPEG-4 HE AAC (AAC+) | Dukungan untuk konten mono/stereo/5.0/5.1 dengan standar frekuensi sampling antara 16 hingga 48 kHz. |
|
MPEG-4 HE AACv2 Profil (AAC+ yang ditingkatkan) |
Dukungan untuk konten mono/stereo/5.0/5.1 dengan standar frekuensi sampling antara 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. |
|
Amerika Serikat (ASC) | Dukungan untuk konten mono/stereo dengan frekuensi pengambilan sampel standar mulai 7,35 hingga 48 kHz. | MPEG-4 (.mp4, .m4a) |
AMR-NB | 4,75 hingga 12,2 kbps dengan sampel @ 8 kHz | 3GPP (.3gp) |
AMR-WB | 9 kecepatan dari 6,60 kbit/dtk hingga 23,85 kbit/dtk dengan sampel @ 16 kHz, sebagaimana didefinisikan pada AMR-WB, Adaptive Multi-Rate - Codec Ucapan Wideband | 3GPP (.3gp) |
FLAC | Untuk encoder dan decoder: setidaknya mode Mono dan Stereo HARUS didukung. Frekuensi sampel hingga 192 kHz HARUS didukung; 16 bit dan 24 bit resolusi HARUS didukung. Penanganan data audio FLAC 24-bit HARUS yang tersedia dengan konfigurasi audio floating point. |
|
MP3 | Konstan Mono/Stereo 8-320 Kbps (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 | Decoding: Dukungan untuk konten mono, stereo, 5.0 dan 5.1 dengan pengambilan sampel
frekuensi 8000, 12000, 16000, 24000, dan 48.000 Hz. Encoding: Dukungan untuk konten mono dan stereo dengan frekuensi pengambilan sampel sebesar 8000, 12000, 16000, 24000, dan 48.000 Hz. |
|
PCM/WAVE | Codec PCM HARUS mendukung PCM linear 16-bit dan float 16-bit. GELANG ekstraktor harus mendukung PCM linear 16-bit, 24-bit, 32-bit, dan float 32-bit (tarif hingga batas hardware). Frekuensi pengambilan sampel HARUS didukung dari 8 kHz hingga 192 kHz. | WAVE (.wav) |
Opus | Decoding: Dukungan untuk konten mono, stereo, 5.0 dan 5.1
dengan frekuensi pengambilan sampel 8000, 12000, 16000, 24000, dan 48000 Hz.
Encoding: Dukungan untuk konten mono dan stereo dengan frekuensi pengambilan sampel 8000, 12000, 16000, 24000, dan 48000 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
- [C-0-4] AVIF
- Perangkat harus mendukung
BITRATE_MODE_CQ
dan Profil Dasar Pengukuran.
- Perangkat harus mendukung
Jika implementasi perangkat mendukung encoding HEIC melalui android.media.MediaCodec
untuk jenis media MIMETYPE_IMAGE_ANDROID_HEIC
,
mereka:
- [C-1-1] HARUS menyediakan codec HEVC encoder akselerasi hardware yang
mendukung
BITRATE_MODE_CQ
mode kontrol kecepatan bit,HEVCProfileMainStill
profil dan ukuran bingkai 512 x 512 px.
5.1.5. Dekode Gambar
Lihat detail selengkapnya di 5.1.6. Detail Codec Gambar.
Implementasi perangkat HARUS mendukung decoding encoding gambar berikut:
- [C-0-1] JPEG
- [C-0-2] GIF
- [C-0-3] PNG
- [C-0-4] BMP
- [C-0-5] WebP
- [C-0-6] Mentah
- [C-0-7] AVIF (Profil Dasar Pengukuran)
Jika implementasi perangkat mendukung decoding video HEVC, implementasi tersebut:
- [C-1-1] HARUS mendukung decoding gambar HEIF (HEIC).
Decoder gambar yang mendukung format kedalaman bit tinggi (9+ bit per saluran):
- [C-2-1] HARUS mendukung penghasil format ekuivalen 8-bit jika diminta oleh
aplikasi, misalnya, melalui
ARGB_8888
konfigurasiandroid.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) | Gambar, Pengumpulan gambar, Profil Dasar Pengukuran Urutan gambar | Penampung HEIF (.avif) |
Encoder dan decoder gambar yang diekspos melalui MediaCodec API
[C-1-1] HARUS mendukung YUV420 8:8:8 warna fleksibel (
COLOR_FormatYUV420Flexible
) hinggaCodecCapabilities
.[C-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung format warna RGB888 untuk Permukaan input mode.
[C-1-3] HARUS mendukung setidaknya salah satu planar atau semiplanar Format warna YUV420 8:8:8:
COLOR_FormatYUV420PackedPlanar
(setara denganCOLOR_FormatYUV420Planar
) atauCOLOR_FormatYUV420PackedSemiPlanar
(setara keCOLOR_FormatYUV420SemiPlanar
). Model tersebut SANGAT DIREKOMENDASIKAN untuk mendukung keduanya.
5.1.7 Codec Video
- Untuk kualitas streaming video web dan konferensi video yang dapat diterima implementasi perangkat SEHARUSNYA menggunakan codec VP8 perangkat keras yang persyaratan.
Jika implementasi perangkat menyertakan dekoder video atau encoder:
[C-1-1] Codec video HARUS mendukung ukuran bytebuffer output dan input yang mengakomodasi {i>frame<i} yang dikompresi dan tidak terkompresi terbesar sebagaimana ditentukan oleh standar dan konfigurasi tetapi juga tidak dialokasikan secara berlebihan.
[C-1-2] Video encoder dan decoder HARUS mendukung YUV420 8:8:8 warna fleksibel format file (
COLOR_FormatYUV420Flexible
) hinggaCodecCapabilities
.[C-1-3] Encoder dan decoder video HARUS mendukung setidaknya salah satu konfigurasi planar atau semiplanar YUV420 format warna 8:8:8:
COLOR_FormatYUV420PackedPlanar
(setara denganCOLOR_FormatYUV420Planar
) atauCOLOR_FormatYUV420PackedSemiPlanar
(setara denganCOLOR_FormatYUV420SemiPlanar
). REKOMENDASI SANGAT DIREKOMENDASIKAN untuk mendukung keduanya.[C-SR-1] Encoder dan decoder video SANGAT DIREKOMENDASIKAN untuk mendukung setidaknya salah satu perangkat keras yang dioptimalkan planar atau semiplanar YUV420 8:8:8 warna format (YV12, NV12, NV21 atau format yang dioptimalkan vendor yang setara.)
[C-1-5] Decoder video yang mendukung format kedalaman bit tinggi (9+ bit per saluran) HARUS mendukung pembuatan format ekuivalen 8-bit jika yang diminta oleh aplikasi. Hal ini HARUS dicerminkan dengan mendukung Format warna YUV420 8:8:8 melalui
android.media.MediaCodecInfo
.
Jika implementasi perangkat mengiklankan dukungan profil HDR melalui
Display.HdrCapabilities
,
mereka:
- [C-2-1] HARUS mendukung penguraian dan penanganan metadata statis HDR.
Jika implementasi perangkat mengiklankan dukungan refresh intra
FEATURE_IntraRefresh
di MediaCodecInfo.CodecCapabilities
, mereka akan:
- [C-3-1] HARUS mendukung periode refresh dalam rentang 10 - 60 frame dan beroperasi secara akurat dalam 20% periode pembaruan yang dikonfigurasi.
Kecuali jika aplikasi menentukan sebaliknya menggunakan KEY_COLOR_FORMAT
kunci 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 default ke format warna YUV420 8:8:8 yang dioptimalkan untuk CPU membaca 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 |
|
|
AVC H.264 | Lihat bagian 5.2 dan 5.3 untuk mengetahui detail |
|
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 detail |
|
VP9 | Lihat bagian 5.3 untuk mengetahui detailnya |
|
AV1 | Lihat bagian 5.2 dan bagian 5.3 untuk detailnya |
|
5.1.9 Keamanan Codec Media
Implementasi perangkat HARUS memastikan kepatuhan terhadap fitur keamanan codec media sebagaimana dijelaskan di bawah ini.
Android menyertakan dukungan untuk OMX, API akselerasi multimedia lintas platform, serta Codec 2.0, API akselerasi multimedia overhead rendah.
Jika implementasi perangkat mendukung multimedia, implementasi tersebut:
- [C-1-1] HARUS menyediakan dukungan untuk codec media baik melalui OMX atau Codec 2.0 API (atau keduanya) seperti dalam Proyek Open Source Android dan tidak menonaktifkan atau mengakali perlindungan keamanan. Secara khusus ini tidak berarti bahwa codec HARUS menggunakan OMX atau Codec 2.0 API, hanya yang mendukung setidaknya salah satu API ini HARUS tersedia, dan dukungan untuk API yang tersedia HARUS mencakup perlindungan keamanan yang ada.
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menyertakan dukungan bagi Codec 2.0 API.
Jika implementasi perangkat tidak mendukung Codec 2.0 API, implementasi tersebut:
- [C-2-1] HARUS menyertakan codec software OMX yang sesuai dari Android Proyek Open Source (jika tersedia) untuk setiap format dan jenis media (encoder atau decoder) yang didukung oleh perangkat.
- [C-2-2] Codec yang memiliki nama dimulai dengan "OMX.google." HARUS didasarkan pada kode sumber Proyek Open Source Android.
- [C-SR-2] SANGAT DIREKOMENDASIKAN bahwa codec software OMX berjalan di codec proses yang tidak memiliki akses ke {i>driver<i} perangkat keras selain mapper memori.
Jika implementasi perangkat mendukung Codec 2.0 API, implementasi tersebut:
- [C-3-1] HARUS menyertakan codec perangkat lunak Codec 2.0 yang sesuai dari Proyek Open Source Android (jika tersedia) untuk setiap format dan jenis media (encoder atau decoder) yang didukung oleh perangkat.
- [C-3-2] HARUS memiliki codec perangkat lunak Codec 2.0 dalam codec perangkat lunak seperti yang disediakan dalam Proyek Open Source Android untuk memungkinkan untuk memberikan akses yang lebih spesifik ke codec perangkat lunak.
- [C-3-3] Codec yang memiliki nama dimulai dengan "c2.android." HARUS didasarkan pada kode sumber Proyek Open Source Android.
5.1.10. Karakteristik Codec Media
Jika implementasi perangkat mendukung codec media, implementasi tersebut:
- [C-1-1] HARUS mengembalikan nilai karakterisasi codec media yang benar melalui
MediaCodecInfo
Compute Engine API.
Khususnya:
- [C-1-2] Codec dengan nama yang dimulai dengan "OMX". HARUS menggunakan API OMX dan memiliki nama yang sesuai dengan pedoman penamaan IL OMX.
- [C-1-3] Codec dengan nama yang dimulai 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 dimulai dengan "OMX.google." atau "c2.android". HARUS TIDAK dianggap sebagai vendor atau sebagai perangkat dengan akselerasi hardware.
- [C-1-5] Codec yang berjalan dalam proses codec (vendor atau sistem) yang memiliki akses ke driver hardware selain alokator memori dan mapper TIDAK BOLEH digolongkan sebagai khusus perangkat lunak.
- [C-1-6] Codec tidak ada dalam Proyek Open Source Android atau tidak berbasis pada kode sumber dalam proyek itu HARUS dicirikan sebagai vendor.
- [C-1-7] Codec yang menggunakan akselerasi hardware HARUS memiliki karakteristik dengan akselerasi perangkat keras.
- [C-1-8] Nama codec TIDAK BOLEH menyesatkan. Misalnya, codec bernama "decoder" HARUS mendukung decoding, dan yang disebut "encoder" HARUS mendukung encoding. Codec dengan nama yang berisi format media HARUS mendukung format font.
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 |
|
|
|
1920 x 1080 px (selain MPEG4, AV1) | 3840 x 2160 piksel (HEVC, VP9, AV1) |
- [C-2-2] Codec video yang dicirikan sebagai akselerasi hardware HARUS MEMILIKI
memublikasikan informasi poin performa. Setiap kolom HARUS mencantumkan semua file yang didukung
poin performa standar (tercantum di
PerformancePoint
API), kecuali jika item tersebut tercakup dalam poin performa standar lain yang didukung. - Selain itu, mereka HARUS memublikasikan poin performa tambahan jika mendukung kinerja video berkelanjutan selain salah satu yang standar yang tercantum.
5.2. Encoding Video
Jika implementasi perangkat mendukung encoder video dan menyediakannya untuk
aplikasi pihak ketiga, dan menyetel
MediaFormat.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 :
- TIDAK BOLEH, lebih dari satu jendela geser, lebih dari 15% di atas kecepatan bit antara intraframe (I-frame) dengan interval tertentu.
- SEHARUSNYA TIDAK lebih dari 100% di atas kecepatan bit dalam jangka waktu 1 detik.
Jika implementasi perangkat mendukung encoder video dan menyediakannya untuk
aplikasi pihak ketiga dan menyetel
MediaFormat.KEY_BITRATE_MODE
ke
BITRATE_MODE_CBR
agar encoder beroperasi dalam mode kecepatan bit konstan, maka kecepatan bit yang dienkode:
- [C-SR-2] SANGAT DIREKOMENDASIKAN untuk TIDAK lebih dari 15% di atas kecepatan bit target pada jendela geser 1 detik.
Jika implementasi perangkat menyertakan tampilan layar tersemat dengan
diagonal minimal 2,5 inci atau termasuk porta output video atau
mendeklarasikan dukungan kamera melalui android.hardware.camera.any
tombol fitur, yaitu:
- [C-1-1] HARUS menyertakan dukungan dari setidaknya salah satu video VP8 atau H.264 encoder-decoder, dan menyediakannya untuk aplikasi pihak ketiga.
- HARUS mendukung encoder video VP8 dan H.264, dan menyediakannya untuk aplikasi pihak ketiga.
Jika implementasi perangkat mendukung video H.264, VP8, VP9, atau HEVC encoder dan menyediakannya untuk aplikasi pihak ketiga, mereka:
- [C-2-1] HARUS mendukung kecepatan bit yang dapat dikonfigurasi secara dinamis.
- HARUS mendukung kecepatan frame variabel, di mana encoder video HARUS menentukan durasi frame instan berdasarkan stempel waktu buffer input, dan mengalokasikan bucket bit-nya berdasarkan durasi {i>frame<i} tersebut.
Jika implementasi perangkat mendukung encoder video MPEG-4 SP dan untuk aplikasi pihak ketiga, mereka:
- HARUS mendukung kecepatan bit yang dapat dikonfigurasi secara dinamis untuk encoder yang didukung.
Jika implementasi perangkat menyediakan encoder
video atau gambar dengan akselerasi hardware,
dan mendukung satu atau beberapa kamera hardware terpasang atau yang dapat dicolokkan yang diekspos melalui
API android.camera
:
- [C-4-1] semua encoder video dan gambar dengan akselerasi hardware HARUS didukung frame encoding dari kamera hardware.
- HARUS mendukung frame encoding dari kamera hardware hingga semua video atau encoder gambar.
Jika implementasi perangkat menyediakan encoding HDR, implementasi tersebut:
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menyediakan plugin bagi transcoding API yang lancar untuk mengonversi dari format HDR ke format SDR.
5.2.1 H.263
Jika implementasi perangkat mendukung encoder H.263 dan menyediakannya kepada aplikasi pihak ketiga, mereka:
- [C-1-1] HARUS mendukung resolusi QCIF (176 x 144) menggunakan Profil Dasar Pengukuran Level 45. Resolusi SQCIF bersifat opsional.
5.2.2. H.264
Jika implementasi perangkat mendukung codec H.264, implementasi tersebut:
- [C-1-1] HARUS mendukung Profil Dasar Pengukuran Level 3. Namun, dukungan untuk ASO (Pemesanan Slice Arbitrer), FMO (FMO (Fleksibel) Pengurutan Macroblock) dan RS (Slice Redundan) adalah OPSIONAL. Selain itu, untuk mempertahankan kompatibilitas dengan perangkat Android lain, DIREKOMENDASIKAN bahwa ASO, FMO, dan RS tidak digunakan untuk Profil Dasar Pengukuran oleh encoder.
- [C-1-2] HARUS mendukung profil encoding video SD (Definisi Standar) pada tabel berikut.
- HARUS mendukung Profil Utama Level 4.
- SEHARUSNYA mendukung profil encoding video HD (Definisi Tinggi) sebagai ditunjukkan dalam tabel berikut.
Jika implementasi perangkat melaporkan dukungan encoding H.264 untuk 720p atau 1080p resolusi video melalui API media, video tersebut akan:
- [C-2-1] HARUS mendukung profil encoding dalam tabel berikut.
SD (Kualitas rendah) | SD (Kualitas tinggi) | HD 720p | HD 1080p | |
---|---|---|---|---|
Resolusi video | 320x240 piksel | 720x480 piksel | 1280 x 720 px | 1920 x 1080 px |
Frekuensi gambar video | 20 fps | 30 fps | 30 fps | 30 fps |
Kecepatan bit video | 384 Kbps | 2 Mbps | 4 Mbps | 10 Mbps |
5.2.3. VP8
Jika implementasi perangkat mendukung codec VP8, implementasi tersebut:
- [C-1-1] HARUS mendukung profil encoding video SD.
- HARUS mendukung profil encoding video HD (Definisi Tinggi) berikut.
- [C-1-2] HARUS mendukung penulisan file Matroska WebM.
- HARUS menyediakan codec VP8 perangkat keras yang memenuhi Persyaratan coding hardware RTC project WebM, untuk memastikan kualitas layanan streaming video web dan konferensi video yang dapat diterima.
Jika implementasi perangkat melaporkan dukungan encoding VP8 untuk 720p atau 1080p resolusi video melalui API media, video tersebut akan:
- [C-2-1] HARUS mendukung profil encoding dalam tabel berikut.
SD (Kualitas rendah) | SD (Kualitas tinggi) | HD 720p | HD 1080p | |
---|---|---|---|---|
Resolusi video | 320 x 180 px | 640 x 360 px | 1280 x 720 px | 1920 x 1080 px |
Frekuensi gambar video | 30 fps | 30 fps | 30 fps | 30 fps |
Kecepatan bit video | 800 Kbps | 2 Mbps | 4 Mbps | 10 Mbps |
5.2.4. VP9
Jika implementasi perangkat mendukung codec VP9, implementasi tersebut:
- [C-1-2] HARUS mendukung Profil 0 Level 3.
- [C-1-1] HARUS mendukung penulisan file Matroska WebM.
- [C-1-3] HARUS menghasilkan data CodecPrivate.
- HARUS mendukung profil decoding HD seperti yang ditunjukkan dalam tabel berikut.
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung profil decoding HD sebagai ditunjukkan dalam tabel berikut jika ada encoder hardware.
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
Resolusi video | 720x480 piksel | 1280 x 720 px | 1920 x 1080 px | 3840x2160 piksel |
Frekuensi gambar video | 30 fps | 30 fps | 30 fps | 30 fps |
Kecepatan bit video | 1,6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
Jika implementasi perangkat mengklaim mendukung Profil 2 atau Profil 3 melalui API Media:
- Dukungan untuk format 12-bit bersifat OPSIONAL.
5.2.5. H.265
Jika implementasi perangkat mendukung codec H.265, implementasi tersebut:
- [C-1-1] HARUS mendukung Profil Utama Level 3 hingga Resolusi 512 x 512.
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung profil SD 720 x 480 dan Profil encoding HD seperti ditunjukkan dalam tabel berikut, jika terdapat encoder hardware.
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
Resolusi video | 720x480 piksel | 1280 x 720 px | 1920 x 1080 px | 3840x2160 piksel |
Frekuensi gambar video | 30 fps | 30 fps | 30 fps | 30 fps |
Kecepatan bit video | 1,6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
5.2.6. AV1
Jika implementasi perangkat mendukung codec AV1, implementasi tersebut:
- [C-1-1] HARUS mendukung Profil Utama termasuk konten 8-bit dan 10-bit.
[C-1-2] HARUS mempublikasikan data kinerja, yaitu melaporkan data kinerja melalui
getSupportedFrameRatesFor()
ataugetSupportedPerformancePoints()
API untuk resolusi yang didukung dalam tabel di bawah.[C-1-3] HARUS menerima metadata HDR dan mengeluarkannya ke bitstream
Jika encoder AV1 mengaktifkan akselerasi hardware, encoder tersebut:
- [C-2-1] HARUS mendukung hingga dan termasuk profil encoding HD1080p dari tabel di bawah ini:
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
Resolusi video | 720x480 piksel | 1280 x 720 px | 1920 x 1080 px | 3840x2160 piksel |
Frekuensi gambar video | 30 fps | 30 fps | 30 fps | 30 fps |
Kecepatan bit video | 5 Mbps | 8 Mbps | 16 Mbps | 50 Mbps |
5.3. Dekode Video
Jika implementasi perangkat mendukung codec VP8, VP9, H.264, atau H.265, implementasi tersebut:
- [C-1-1] HARUS mendukung resolusi video dinamis dan pengalihan kecepatan frame melalui API Android standar dalam aliran yang sama untuk semua VP8, VP9, Codec H.264, dan H.265 secara real time dan mencapai resolusi maksimum yang didukung berdasarkan setiap codec pada perangkat.
5.3.1 MPEG-2
Jika implementasi perangkat mendukung decoder MPEG-2, implementasi tersebut:
- [C-1-1] HARUS mendukung Tingkat Tinggi Profil Utama.
5.3.2 H.263
Jika implementasi perangkat mendukung decoder H.263, implementasi tersebut:
- [C-1-1] HARUS mendukung Profil Dasar Pengukuran Level 30 (resolusi CIF, QCIF, dan SQCIF @ 30fps 384 kbps) dan Tingkat 45 (QCIF dan Resolusi SQCIF @ 30 fps 128 kbps).
5.3.3. MPEG-4
Jika implementasi perangkat dengan decoder MPEG-4, implementasi tersebut:
- [C-1-1] HARUS mendukung Simple Profile Level 3.
5.3.4. H.264
Jika implementasi perangkat mendukung decoder H.264, implementasi tersebut:
- [C-1-1] HARUS mendukung Profil Utama Level 3.1 dan Profil Dasar Pengukuran. Dukungan untuk ASO (Pemesanan Slice Arbitrer), FMO (Pemesanan Macroblock Fleksibel), dan RS (Slice yang redundan) adalah OPSIONAL.
- [C-1-2] HARUS dapat mendekode video dengan SD (Definisi Standar) profil yang tercantum dalam tabel berikut dan dienkode dengan Profil Dasar Pengukuran dan Profil Utama Level 3.1 (termasuk 720p30).
- HARUS mampu mendekode video dengan profil HD (Definisi Tinggi) seperti yang ditunjukkan dalam tabel berikut.
Jika tinggi yang dilaporkan oleh metode Display.getSupportedModes()
sama atau lebih besar dari resolusi video, implementasi perangkat:
- [C-2-1] HARUS mendukung profil decoding video HD 720p sebagai berikut tabel sementara.
- [C-2-2] HARUS mendukung profil decoding video HD 1080p sebagai berikut tabel sementara.
SD (Kualitas rendah) | SD (Kualitas tinggi) | HD 720p | HD 1080p | |
---|---|---|---|---|
Resolusi video | 320x240 piksel | 720x480 piksel | 1280 x 720 px | 1920 x 1080 px |
Frekuensi gambar video | 30 fps | 30 fps | 60 fps | 30 fps (60 fpsTelevisi) |
Kecepatan bit video | 800 Kbps | 2 Mbps | 8 Mbps | 20 Mbps |
5.3.5. H.265 (HEVC)
Jika implementasi perangkat mendukung codec H.265, implementasi tersebut:
- [C-1-1] HARUS mendukung tingkat Utama Profil Utama Level 3 dan video SD profil dekode 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 berikut ini jika tersedia 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 H.265 atau VP9 decoding profil 720, 1080, dan UHD.
SD (Kualitas rendah) | SD (Kualitas tinggi) | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|---|
Resolusi video | 352 x 288 piksel | 720x480 piksel | 1280 x 720 px | 1920 x 1080 px | 3840x2160 piksel |
Frekuensi gambar video | 30 fps | 30 fps | 30 fps | 30/60 fps (60 fpsTelevisi dengan decoding hardware H.265) | 60 fps |
Kecepatan bit video | 600 Kbps | 1,6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
Jika implementasi perangkat mengklaim mendukung Profil HDR melalui Media API:
- [C-3-1] Implementasi perangkat HARUS menerima metadata HDR yang diperlukan dari aplikasi, serta mendukung ekstraksi dan pembuatan output HDR yang diperlukan metadata dari bitstream dan/atau container.
- [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, implementasi tersebut:
- [C-1-1] HARUS mendukung profil decoding SD dalam tabel berikut.
- HARUS menggunakan codec VP8 perangkat keras yang memenuhi persyaratan.
- HARUS mendukung profil decoding HD dalam tabel berikut.
Jika tinggi yang dilaporkan oleh metode Display.getSupportedModes()
sama
atau lebih besar dari resolusi video, maka:
- [C-2-1] Implementasi perangkat HARUS mendukung profil 720p di tabel berikut.
- [C-2-2] Implementasi perangkat HARUS mendukung profil 1080p di tabel berikut.
SD (Kualitas rendah) | SD (Kualitas tinggi) | HD 720p | HD 1080p | |
---|---|---|---|---|
Resolusi video | 320 x 180 px | 640 x 360 px | 1280 x 720 px | 1920 x 1080 px |
Frekuensi gambar video | 30 fps | 30 fps | 30 fps (60 fpsTelevisi) | 30 (60 fpsTelevisi) |
Kecepatan bit video | 800 Kbps | 2 Mbps | 8 Mbps | 20 Mbps |
5.3.7. VP9
Jika implementasi perangkat mendukung codec VP9, implementasi tersebut:
- [C-1-1] HARUS mendukung profil decoding video SD seperti yang ditunjukkan dalam tabel berikut.
- HARUS mendukung profil decoding HD seperti yang ditunjukkan dalam tabel berikut.
Jika implementasi perangkat mendukung codec VP9 dan decoder hardware:
- [C-2-1] HARUS mendukung profil decoding HD seperti yang ditunjukkan berikut ini tabel sementara.
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 dari VP9 atau H.265 decoding profil 720, 1080 dan UHD.
SD (Kualitas rendah) | SD (Kualitas tinggi) | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|---|
Resolusi video | 320 x 180 px | 640 x 360 px | 1280 x 720 px | 1920 x 1080 px | 3840x2160 piksel |
Frekuensi gambar video | 30 fps | 30 fps | 30 fps | 30 fps (60 fpsTelevisi dengan decoding hardware VP9) | 60 fps |
Kecepatan bit video | 600 Kbps | 1,6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
Jika implementasi perangkat mengklaim mendukung VP9Profile2
atau VP9Profile3
melalui 'CodecProfileLevel'
API media:
- 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. Tabel itu juga HARUS mendukung pengekstrakan dan {i>output<i} metadata HDR yang diperlukan dari bitstream dan/atau container. - [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
,
mereka:
- [C-1-1] HARUS menyediakan ekstraktor berkemampuan Dolby Vision.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [C-1-2] HARUS menampilkan konten Dolby Vision dengan benar salah satu di perangkat layar atau pada layar eksternal yang terpasang melalui port output video standar (mis., HDMI).
Mengakhiri persyaratan baru
- [C-1-3] HARUS menetapkan ID trek lapisan dasar yang kompatibel dengan versi sebelumnya (jika ada) agar sama dengan ID pelacakan lapisan Dolby Vision gabungan.
5.3.9. AV1
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 hardware decoder yang dipercepat, maka mereka:
- [C-2-1] HARUS dapat mendekode profil decoding video HD 720p dari
tabel di bawah saat tinggi dilaporkan oleh
Display.getSupportedModes()
sama dengan atau lebih besar dari 720p. - [C-2-2] Harus dapat mendekode setidaknya profil decoding video HD 1080p
dari tabel di bawah saat tinggi dilaporkan oleh
Display.getSupportedModes()
sama dengan atau lebih besar dari 1080p.
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
Resolusi video | 720x480 piksel | 1280 x 720 px | 1920 x 1080 px | 3840x2160 piksel |
Frekuensi gambar video | 30 fps | 30 fps | 30 fps | 30 fps |
Kecepatan bit video | 5 Mbps | 8 Mbps | 16 Mbps | 50 Mbps |
Jika implementasi perangkat mendukung Profil HDR melalui Media API, mereka:
- [C-3-1] HARUS mendukung ekstraksi dan pembuatan output metadata HDR dari bitstream dan/atau container.
- [C-3-2] HARUS menampilkan konten HDR dengan benar pada layar perangkat atau port output video standar (misalnya, HDMI).
5.4 Perekaman Audio
Meskipun beberapa persyaratan yang diuraikan dalam bagian ini tercantum sebagai SEHARUSNYA sejak Android 4.3, Definisi Kompatibilitas untuk versi mendatang telah direncanakan untuk mengubahnya menjadi HARUS. Perangkat Android yang sudah ada dan yang baru SANGAT BANYAK DIREKOMENDASIKAN untuk memenuhi persyaratan yang tercantum sebagai SEHARUSNYA, atau mereka tidak akan dapat mencapai kompatibilitas Android saat diupgrade ke masa mendatang .
5.4.1. Informasi Mikrofon dan Pengambilan Audio Mentah
Jika implementasi perangkat mendeklarasikan android.hardware.microphone
, implementasi tersebut:
[C-1-1] HARUS memungkinkan penangkapan konten audio mentah untuk streaming
AudioRecord
atauAAudio
INPUT apa pun yang dibuka memulai proyek. Paling tidak, karakteristik berikut HARUS didukung:- Format: PCM Linear, 16-bit
- Frekuensi pengambilan sampel: 8000, 11025, 16000, 44100, 48000 Hz
- Saluran: Mono
- Sumber Audio:
DEFAULT
,MIC
,CAMCORDER
VOICE_RECOGNITION
,VOICE_COMMUNICATION
,UNPROCESSED
, atauVOICE_PERFORMANCE
. Ini juga berlaku untuk Preset Input yang setara diAAudio
, untuk contoh,AAUDIO_INPUT_PRESET_CAMCORDER
.
HARUS mengizinkan perekaman konten audio mentah dengan hal berikut karakteristik:
- Format: PCM Linear, 16-bit dan 24-bit
- Frekuensi pengambilan sampel: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48.000 Hz
- Saluran: Sebanyak jumlah saluran dengan mikrofon di alat
[C-1-2] HARUS mengambil sampel dengan frekuensi sampel di atas tanpa up-sampling.
[C-1-3] HARUS menyertakan filter anti-aliasing yang sesuai saat frekuensi sampel yang diberikan di atas ditangkap dengan pengurangan sampel.
HARUS mengizinkan pengambilan kualitas radio AM dan DVD dari konten audio mentah, yang memiliki karakteristik berikut:
- Format: PCM Linear, 16-bit
- Frekuensi pengambilan sampel: 22050, 48000 Hz
- Saluran: Stereo
[C-1-4] HARUS mematuhi
MicrophoneInfo
API dan mengisi informasi mikrofon yang tersedia dengan benar di perangkat dapat diakses oleh aplikasi pihak ketiga melaluiAudioManager.getMicrophones()
untuk AudioRecord aktif yang menggunakanMediaRecorder.AudioSources DEFAULT
,MIC
,CAMCORDER
,VOICE_RECOGNITION
,VOICE_COMMUNICATION
,UNPROCESSED
, atauVOICE_PERFORMANCE
. Jika implementasi perangkat memungkinkan pengambilan kualitas radio AM dan DVD audio mentah tersebut, mereka:[C-2-1] HARUS mengambil screenshot tanpa up-sampling pada rasio apa pun yang lebih tinggi dari 16000:22050 atau 44100:48000.
[C-2-2] HARUS menyertakan filter anti-aliasing yang sesuai untuk setiap pengambilan sampel atau down-sampling.
5.4.2. Ambil foto untuk Pengenalan Suara
Jika implementasi perangkat mendeklarasikan android.hardware.microphone
, implementasi tersebut:
- [C-1-1] HARUS menangkap
android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION
sumber audio di frekuensi sampling, yaitu 44100 dan 48000. - [C-1-2] Secara default, HARUS menonaktifkan pemrosesan audio pengurangan bising saat
merekam streaming audio dari audio
AudioSource.VOICE_RECOGNITION
sumber. [C-1-3] Secara default, HARUS menonaktifkan semua kontrol penguatan otomatis saat merekam streaming audio dari sumber audio
AudioSource.VOICE_RECOGNITION
.HARUS menunjukkan karakteristik amplitudo-versus frekuensi yang kira-kira datar pada rentang frekuensi menengah: khususnya ±3dB dari 100 Hz hingga 4000 Hz untuk masing-masing dan setiap mikrofon yang digunakan untuk merekam sumber audio pengenalan suara.
[C-SR-1] SANGAT DIREKOMENDASIKAN untuk menunjukkan tingkat amplitudo dalam rentang frekuensi: khusus dari ±20 dB dari 30 Hz hingga 100 Hz dibandingkan dengan rentang frekuensi menengah untuk setiap mikrofon yang digunakan untuk merekam suara sumber audio pengenalan.
[C-SR-2] SANGAT DIREKOMENDASIKAN untuk menunjukkan tingkat amplitudo di rentang frekuensi: khusus dari ±30 dB dari 4000 Hz hingga 22 KHz dibandingkan dengan rentang frekuensi menengah untuk setiap mikrofon yang digunakan untuk merekam suara sumber audio pengenalan.
HARUS mengatur sensitivitas input audio sehingga sumber nada sinusoidal 1000 Hz diputar pada Level Tekanan Suara (SPL) 90 dB (diukur di samping mikrofon) menghasilkan respons ideal RMS 2500 dalam kisaran 1770 dan 3530 untuk 16 bit-sampel (atau -22,35 db ±3dB Skala Penuh untuk presisi floating point/double untuk setiap mikrofon yang digunakan untuk merekam pengenalan suara sumber audio.
HARUS merekam streaming audio pengenalan suara agar amplitudo PCM level secara linear melacak perubahan input SPL minimal dalam rentang 30 dB dari -18 dB ke +12 dB untuk 90 dB SPL di mikrofon.
HARUS merekam streaming audio pengenalan suara dengan harmonik total distorsi (THD) kurang dari 1% untuk 1 kHz pada level input SPL 90 dB pada mikrofon.
Jika implementasi perangkat mendeklarasikan android.hardware.microphone
dan derau
teknologi penyembunyian (pengurangan) yang disesuaikan untuk pengenalan ucapan, yaitu teknologi:
- [C-2-1] HARUS mengizinkan efek audio ini untuk dikontrol dengan
API
android.media.audiofx.NoiseSuppressor
. - [C-2-2] HARUS secara unik mengidentifikasi setiap teknologi peredam bising
melalui kolom
AudioEffect.Descriptor.uuid
.
5.4.3. Ambil untuk Mengubah Rute Pemutaran
Class android.media.MediaRecorder.AudioSource
menyertakan REMOTE_SUBMIX
sumber audio.
Jika implementasi perangkat mendeklarasikan android.hardware.audio.output
dan
android.hardware.microphone
, mereka:
[C-1-1] HARUS menerapkan sumber audio
REMOTE_SUBMIX
dengan benar sehingga saat aplikasi menggunakanandroid.media.AudioRecord
API untuk merekam dari sumber audio, kode ini merekam campuran semua streaming audio kecuali untuk yang 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 Penghilang Echo Akustik
Teknologi (AEC) yang disesuaikan untuk komunikasi suara dan diterapkan ke jalur penangkapan
saat mengambil gambar menggunakan
AudioSource.VOICE_COMMUNICATION
.
Jika implementasi perangkat menyediakan {i>
acoustic Echo Canceler<i} yang
disisipkan di jalur rekam audio saat AudioSource.VOICE_COMMUNICATION
dipilih, mereka:
- [C-SR-1] SANGAT_DIREKOMENDASIKAN untuk menyatakan hal ini melalui AcousticEchoCanceler Metode API AcousticEchoCanceler.isAvailable()
- [C-SR-2] STRONGLY_RECOMMENDED untuk memungkinkan efek audio ini dapat dikontrol dengan AcousticEchoCanceler Compute Engine API.
- [C-SR-3] STRONGLY_RECOMMENDED untuk mengidentifikasi setiap teknologi AEC secara unik implementasi melalui AudioEffect.Descriptor.uuid kolom tersebut.
5.4.5. Pengambilan Serentak
Jika implementasi perangkat mendeklarasikan android.hardware.microphone
,implementasi tersebut HARUS
mengimplementasikan pengambilan serentak seperti yang dijelaskan dalam dokumen ini. Khususnya:
- [C-1-1] HARUS mengizinkan akses serentak ke mikrofon dengan aksesibilitas
pengambilan layanan dengan
AudioSource.VOICE_RECOGNITION
dan setidaknya satu pengambilan aplikasi denganAudioSource
apa pun. - [C-1-2] HARUS mengizinkan akses serentak ke mikrofon dengan perangkat
aplikasi yang memiliki peran Asisten dan setidaknya satu aplikasi
mengambil dengan
AudioSource
apa pun kecuali untukAudioSource.VOICE_COMMUNICATION
atauAudioSource.CAMCORDER
. - [C-1-3] HARUS mematikan suara rekaman audio untuk aplikasi lain, kecuali untuk
layanan aksesibilitas, sementara
aplikasi menangkap dengan
AudioSource.VOICE_COMMUNICATION
atauAudioSource.CAMCORDER
. Namun, ketika aplikasi merekam melaluiAudioSource.VOICE_COMMUNICATION
, lalu aplikasi lain dapat merekam panggilan suara jika merupakan aplikasi istimewa (sudah diinstal sebelumnya) dengan izinCAPTURE_AUDIO_OUTPUT
. - [C-1-4] Jika dua atau lebih aplikasi menangkap secara bersamaan dan jika tidak ada aplikasi yang memiliki UI di atasnya, aplikasi yang mulai menangkap menerima audio.
5.5. Pemutaran Audio
Android menyertakan dukungan yang memungkinkan aplikasi memutar audio melalui audio periferal output sebagaimana didefinisikan dalam bagian 7.8.2.
5.5.1 Pemutaran Audio Raw
Jika implementasi perangkat mendeklarasikan android.hardware.audio.output
, implementasi tersebut:
[C-1-1] HARUS mengizinkan pemutaran konten audio mentah dengan karakteristik:
- Format sumber: PCM Linear, 16-bit, 8-bit, float
- Saluran: Konfigurasi multisaluran, Stereo, Mono yang valid dengan maksimal 8 channel
- Frekuensi pengambilan sampel (dalam Hz):
- 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 di saluran konfigurasi 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
,
mereka:
- [C-1-1] HARUS mendukung
EFFECT_TYPE_EQUALIZER
dan ImplementasiEFFECT_TYPE_LOUDNESS_ENHANCER
yang dapat dikontrol melalui Subclass AudioEffectEqualizer
danLoudnessEnhancer
. - [C-1-2] HARUS mendukung implementasi API visualizer, yang dapat dikontrol melalui
class
Visualizer
. - [C-1-3] HARUS mendukung implementasi
EFFECT_TYPE_DYNAMICS_PROCESSING
dapat dikontrol melalui subclass AudioEffectDynamicsProcessing
.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [C-1-4] HARUS mendukung efek audio dengan input dan output floating point, jika efek dikembalikan ke pipeline audio framework. Hal ini mengacu pada sisipan atau efek tambahan seperti equalizer. Perilaku yang setara sangat direkomendasikan jika hasil efek tidak terlihat oleh audio framework pipeline Anda (seperti efek pascapemrosesan atau yang dialihkan).
Mengakhiri persyaratan baru
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [C-1-5] HARUS memastikan bahwa efek audio mendukung beberapa saluran hingga jumlah saluran mixer yang juga dikenal sebagai FCC_LIMIT, saat hasil efek dikembalikan ke pipeline audio framework. Ini mengacu pada penyisipan atau efek tambahan yang khas, tetapi tidak termasuk efek khusus seperti seperti efek downmix, upmix, dan spasial yang mengubah jumlah saluran. Perilaku yang setara disarankan bila efek tidak terlihat oleh pipeline audio framework (seperti, pascapemrosesan atau mengalihkan beban efek).
Mengakhiri persyaratan baru
- HARUS mendukung
EFFECT_TYPE_BASS_BOOST
,EFFECT_TYPE_ENV_REVERB
, PenerapanEFFECT_TYPE_PRESET_REVERB
, danEFFECT_TYPE_VIRTUALIZER
dapat dikontrol melalui sub-classAudioEffect
BassBoost
,EnvironmentalReverb
,PresetReverb
, danVirtualizer
. - [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung efek dalam floating point dan multisaluran.
5.5.3. Volume Output Audio
Implementasi perangkat otomotif:
- SEHARUSNYA mengizinkan penyesuaian volume audio
secara terpisah untuk setiap streaming audio menggunakan jenis atau penggunaan konten sebagaimana ditentukan
oleh AudioAttributes
dan penggunaan audio mobil seperti yang didefinisikan secara publik di
android.car.CarAudioManager
.
5.5.4. Offload Audio
Jika implementasi perangkat mendukung pemutaran pengurangan beban audio, implementasi tersebut:
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk memangkas konten audio tanpa jeda yang diputar di antara dua klip dengan format yang sama jika ditentukan oleh API tanpa celah AudioTrack dan penampung media untuk MediaPlayer.
5.6. Latensi Audio
Latensi audio adalah tunda waktu saat sinyal audio melewati sistem. Banyak class aplikasi yang mengandalkan latensi pendek untuk mencapai real-time efek suara.
Untuk tujuan bagian ini, gunakan definisi berikut:
- latensi output. Interval antara saat aplikasi menulis sebuah frame data berkode PCM dan saat suara yang sesuai disajikan ke pada transduser di perangkat atau sinyal meninggalkan perangkat melalui porta dan dapat diamati secara eksternal.
- latensi cold output. Waktu antara memulai streaming output dan waktu penyajian frame pertama berdasarkan stempel waktu, saat output audio sedang tidak ada aktivitas dan dimatikan sebelum permintaan dibuat.
- latensi output berkelanjutan. Latensi output untuk frame berikutnya, setelah perangkat memutar audio.
- latensi input. Interval antara saat suara diucapkan oleh ke perangkat pada transduser atau sinyal yang masuk ke perangkat melalui porta dan ketika aplikasi membaca {i>frame<i} yang sesuai dari data yang berkode PCM.
- kehilangan input. Bagian awal dari sinyal input yang tidak dapat digunakan atau tidak tersedia.
- latensi input cold. Waktu antara memulai streaming dan saat frame valid pertama diterima, ketika sistem input audio tidak ada aktivitas dan dimatikan sebelum dibuatnya permintaan.
- latensi input berkelanjutan. Latensi input untuk frame berikutnya, saat perangkat merekam audio.
- latensi bolak-balik berkelanjutan. Jumlah latensi input berkelanjutan ditambah latensi output berkelanjutan ditambah satu periode buffer. Periode {i>buffer<i} memungkinkan waktu bagi aplikasi untuk memproses sinyal dan waktu bagi aplikasi untuk melakukan fase mitigasi perbedaan antara stream input dan output.
- API antrean buffer OpenSL ES PCM. Kumpulan terkait PCM OpenSL ES API dalam Android NDK.
- API audio native AAudio. Himpunan AAudio API dalam Android NDK.
- Stempel waktu. Sepasang yang terdiri dari posisi {i>frame<i} relatif dalam streaming dan estimasi waktu saat frame masuk atau keluar dari pipeline pemrosesan audio pada endpoint terkait. Lihat juga AudioTimestamp.
- gangguan. Gangguan sementara atau nilai sampel yang salah pada sinyal audio, yang biasanya disebabkan oleh underrun buffer untuk output, {i>buffer overrun<i} untuk input, atau sumber derau digital atau analog lainnya.
- rata-rata deviasi absolut (MAD). Rata-rata nilai absolut penyimpangan dari rerata untuk sekumpulan nilai.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
latensi tap-to-tone (TTL), yang diukur dengan CTS Verifier, adalah waktunya antara saat layar diketuk dan saat nada yang dihasilkan sebagai hasilnya suara ketukan terdengar di speaker. Ini dirata-ratakan dari 5 pengukuran menggunakan API audio native AAudio untuk output.
Latensi Round-Trip (RTL), yang diukur dengan CTS Verifier, adalah Rata-rata Latensi berkelanjutan selama 5 kali pengukuran, yang diukur melalui jalur loopback yang memberikan feed output kembali ke input, menggunakan API audio native AAudio. Jalur loopback adalah:
- Speaker/mik: Speaker bawaan ke mikrofon bawaan.
- Analog: Colokan analog 3,5 mm dan adaptor loopback.
- USB: adaptor USB ke 3,5 mm dan adaptor loopback atau audio USB antarmuka dan kabel loopback.
FEATURE_AUDIO_PRO. Fitur
android.hardware.audio.pro
dideklarasikan.MPC. Class Performa Media
Mengakhiri persyaratan baru
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- latensi pelacakan kepala. Waktu mengambil dari gerakan kepala yang ditangkap oleh unit pengukuran inersia (IMU) ke transduser headphone deteksi perubahan suara yang disebabkan oleh {i>motion <i}ini.
Mengakhiri persyaratan baru
Jika implementasi perangkat mendeklarasikan android.hardware.audio.output
, implementasi tersebut
HARUS memenuhi atau melebihi persyaratan berikut:
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [C-1-1] Stempel waktu {i>output<i} yang ditampilkan oleh
AudioTrack.getTimestamp
dan
AAudioStream_getTimestamp
akurat hingga +/- 2 md.
Mengakhiri persyaratan baru
[C-1-2] Latensi output dingin 500 milidetik atau kurang.
[C-1-3] Membuka streaming output menggunakan
AAudioStreamBuilder_openStream()
HARUS memerlukan waktu kurang dari 1000 milidetik.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [C-1-4] Latensi bolak-balik yang dihitung berdasarkan input dan output
stempel waktu yang ditampilkan oleh
AAudioStream_getTimestamp
HARUS dalam waktu 200 mdtk dari latensi dua arah yang diukur untukAAUDIO_PERFORMANCE_MODE_NONE
danAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
untuk speaker, berkabel dan nirkabel {i>headset<i}.
Mengakhiri persyaratan baru
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Jika implementasi perangkat mendeklarasikan android.hardware.audio.output
,
SANGAT DIREKOMENDASIKAN untuk memenuhi atau melebihi persyaratan berikut:
[C-SR-1] Latensi output dingin 100 milidetik atau kurang melalui speaker dalam jalur data.
[C-SR-2] Latensi tap-to-tone 80 milidetik atau kurang.
[C-SR-4] Latensi bolak-balik yang dihitung berdasarkan input dan output stempel waktu yang ditampilkan oleh
AAudioStream_getTimestamp
SANGAT DIREKOMENDASIKAN dalam 30 mdtk dari latensi dua arah yang diukur untukAAUDIO_PERFORMANCE_MODE_NONE
danAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
untuk speaker, headset berkabel dan nirkabel.
Mengakhiri persyaratan baru
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Jika implementasi perangkat memenuhi persyaratan di atas, setelah implementasi awal kalibrasi, saat menggunakan API audio native AAudio, untuk output berkelanjutan latensi dan latensi output cold pada minimal satu audio yang didukung perangkat output, yaitu:
- [C-SR-5] SANGAT DIREKOMENDASIKAN untuk melaporkan audio latensi rendah dengan mendeklarasikan
Tombol fitur
android.hardware.audio.low_latency
. - [C-SR-6] SANGAT DIREKOMENDASIKAN untuk memenuhi persyaratan latensi rendah audio melalui API AAudio.
- [C-SR-7] SANGAT DIREKOMENDASIKAN untuk memastikan bahwa 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
.
Mengakhiri persyaratan baru
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Jika implementasi perangkat tidak memenuhi persyaratan audio latensi rendah melalui API audio native AAudio, fungsi ini akan:
- [C-2-1] TIDAK BOLEH melaporkan dukungan untuk audio latensi rendah.
Mengakhiri persyaratan baru
Jika implementasi perangkat menyertakan android.hardware.microphone
, implementasi tersebut
HARUS memenuhi persyaratan audio input ini:
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [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.
Mengakhiri persyaratan baru
- [C-3-2] Latensi input dingin selama 500 milidetik atau kurang.
- [C-3-3] Membuka streaming input menggunakan
AAudioStreamBuilder_openStream()
HARUS memerlukan waktu kurang dari 1000 milidetik.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Jika implementasi perangkat menyertakan android.hardware.microphone
, implementasi tersebut akan
SANGAT DIREKOMENDASIKAN untuk memenuhi persyaratan audio input berikut:
- [C-SR-8] Latensi input dingin 100 milidetik atau kurang melalui mikrofon dalam jalur data.
- [C-SR-11] Batasi error dalam stempel waktu input, seperti yang ditampilkan oleh
AudioRecord.getTimestamp
atau
AAudioStream_getTimestamp
, hingga +/- 1 md.
Mengakhiri persyaratan baru
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Jika implementasi perangkat mendeklarasikan android.hardware.audio.output
dan
android.hardware.microphone
, mereka:
- [C-SR-12] SANGAT DIREKOMENDASIKAN untuk memiliki Latensi Round-Trip Berkelanjutan Rata-rata 50 milidetik atau kurang lebih dari 5 pengukuran, dengan Deviasi Absolut Rata-rata kurang dari 10 md, pada setidaknya satu jalur yang didukung.
Mengakhiri persyaratan baru
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Tabel berikut menentukan persyaratan RTL untuk Perangkat Genggam
implementasi seperti yang ditetapkan dalam 2.2.1 yang mendeklarasikan
android.hardware.audio.output
dan android.hardware.microphone
.
Perangkat dan Deklarasi | RTL (md) | MAD (md) | Jalur Loopback |
---|---|---|---|
Genggam | 250 | 30 | speaker/mikrofon, analog 3,5 mm (jika didukung), USB (jika didukung) |
>= MPC_T (14) | 80 | 15 | setidaknya satu jalur |
FEATURE_AUDIO_LOW_LATENCY | 50 | 10 | setidaknya satu jalur |
FITUR_AUDIO_PRO | 25 | 5 | setidaknya satu jalur |
FITUR_AUDIO_PRO | 20 | 5 | analog (jika didukung) |
FITUR_AUDIO_PRO | 25 | 5 | USB (jika analog tidak didukung) |
Mengakhiri persyaratan baru
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Tabel berikut menentukan persyaratan TTL untuk Perangkat genggam
implementasi seperti yang ditetapkan dalam 2.2.1 yang mendeklarasikan
android.hardware.audio.output
dan android.hardware.microphone
.
Perangkat dan Deklarasi | TTL (md) |
---|---|
Genggam | 250 |
>= MPC_T (14) | 80 |
MPC_S (13) | 100 |
FITUR_AUDIO_PRO | 80 |
Mengakhiri persyaratan baru
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Jika implementasi perangkat
menyertakan dukungan untuk
spatial audio
dengan pelacakan gerakan kepala
dan mendeklarasikan PackageManager.FEATURE_AUDIO_SPATIAL_HEADTRACKING_LOW_LATENCY
menandai, mereka:
- [C-4-1] HARUS menunjukkan pelacakan kepala maksimum ke latensi pembaruan audio 300 md.
Mengakhiri persyaratan baru
5.7 Protokol Jaringan
Implementasi perangkat HARUS mendukung protokol jaringan media untuk pemutaran audio dan video seperti yang ditetapkan dalam dokumentasi Android SDK.
Untuk setiap codec dan format penampung yang implementasi perangkat diperlukan implementasi perangkat:
[C-1-1] HARUS mendukung codec atau container tersebut melalui HTTP dan HTTPS.
[C-1-2] HARUS mendukung format segmen media yang sesuai sebagaimana ditunjukkan dalam tabel format segmen media di bawah ini Protokol draf HTTP Live Streaming, Versi 7.
[C-1-3] HARUS mendukung format payload RTSP terkait seperti yang ditunjukkan dalam seperti tabel RTSP di bawah. Untuk pengecualian, lihat catatan kaki tabel di bagian 5.1.
Format Segmen Media
Format segmen | Referensi | Dukungan codec yang diperlukan |
---|---|---|
Aliran Transpor MPEG-2 | ISO 13818 |
Codec video:
dan MPEG-2. Codec audio:
|
AAC dengan penyesuaian frame ADTS dan tag ID3 | ISO 13818-7 | Lihat bagian 5.1.1 untuk mengetahui detail tentang AAC dan variannya |
WebVTT | WebVTT |
RTSP (RTP, SDP)
Nama profil | Referensi | Dukungan codec yang diperlukan |
---|---|---|
AVC H264 | RFC 6184 | Lihat bagian 5.1.8 untuk mengetahui detail tentang AVC H264 |
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-generik | RFC 3640 | Lihat bagian 5.1.3 untuk mengetahui detail tentang AAC dan variannya |
MP2 triliun | RFC 2250 | Lihat MPEG-2 Transport Stream di bawah HTTP Live Streaming untuk mengetahui detailnya |
5.8. Media yang Aman
Jika implementasi perangkat mendukung output video yang aman dan mampu mendukung platform aman, mereka:
- [C-1-1] HARUS mendeklarasikan dukungan untuk
Display.FLAG_SECURE
.
Jika implementasi perangkat mendeklarasikan dukungan untuk Display.FLAG_SECURE
dan dukungan
protokol layar nirkabel, yaitu:
- [C-2-1] HARUS mengamankan tautan dengan mekanisme kriptografi yang kuat seperti seperti HDCP 2.x atau 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, yaitu:
- [C-3-1] HARUS mendukung HDCP 1.2 atau yang lebih tinggi untuk semua layar eksternal yang terhubung melalui porta berkabel yang dapat diakses pengguna.
5.9. Musical Instrument Digital Interface (MIDI)
Jika implementasi perangkat melaporkan dukungan untuk fitur android.software.midi
melalui
android.content.pm.PackageManager
, mereka akan:
[C-1-1] HARUS mendukung MIDI pada semua transport hardware yang mendukung MIDI untuk yang menyediakan konektivitas non-MIDI generik, di mana 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 transportasi software MIDI antar-aplikasi (perangkat MIDI virtual)
[C-1-3] HARUS menyertakan libamidi.so (dukungan MIDI asli)
HARUS mendukung mode periferal MIDI melalui USB, bagian 7.7
5.10. Audio Profesional
Jika implementasi perangkat melaporkan dukungan untuk fitur
android.hardware.audio.pro
melalui
android.content.pm.PackageManager
, mereka akan:
- [C-1-1] HARUS melaporkan dukungan untuk fitur
android.hardware.audio.low_latency
.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [C-1-2] HARUS
memiliki audio bolak-balik berkelanjutan latensi, memenuhi latensi persyaratan untukFEATURE_AUDIO_PRO
seperti yang ditentukan di bagian 5.6 Latensi Audiodari 25 milidetik atau kurang dari setidaknya satu yang didukung jalur funnel tetapan.
Mengakhiri persyaratan baru
- [C-1-3] HARUS menyertakan port USB yang mendukung mode host USB dan USB mode periferal.
- [C-1-4] HARUS melaporkan dukungan untuk fitur
android.software.midi
.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [C-1-5] HARUS memenuhi
latensi danaudio USB Persyaratan latensi menggunakan Audio native AAudio API danAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
.
Mengakhiri persyaratan baru
- [C-1-6] HARUS memiliki latensi output Cold 200 md atau kurang.
- [C-1-7] HARUS memiliki latensi input Dingin 200 md atau kurang.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [C-1-8] HARUS memiliki rata-rata latensi Ketuk untuk nada 80 milidetik atau kurang minimal 5 pengukuran melalui speaker ke jalur data mikrofon.
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk memenuhi latensi sebagaimana didefinisikan dalam bagian 5.6 Latensi Audio, dari 20 milidetik atau kurang, lebih dari 5 pengukuran dengan Deviasi Absolut Rata-rata kurang dari 5 dalam milidetik.
- [C-SR-2] SANGAT DIREKOMENDASIKAN untuk memenuhi persyaratan Pro Audio untuk latensi audio bolak-balik berkelanjutan, latensi input cold, dan output cold persyaratan audio USB dan latensi menggunakan API audio native AAudio melalui jalur MMAP.
[C-SR-3] SANGAT DIREKOMENDASIKAN untuk menyediakan tingkat CPU yang konsisten performa saat audio aktif dan beban CPU bervariasi. Ini harus diuji menggunakan aplikasi Android SynthMark. SynthMark menggunakan synthesizer software yang berjalan di framework audio yang disimulasikan yang mengukur performa sistem. Lihat Dokumentasi SynthMark untuk mendapatkan penjelasan tentang benchmark. SynthMark aplikasi perlu dijalankan menggunakan "Pengujian Otomatis" dan mendapatkan hasil berikut:
- voicemark.90 >= 32 suara
- latensimark.fixed.little <= 15 mdtk
- latensimark.dynamic.little <= 50 mdtk
HARUS minimalkan ketidakakuratan jam audio dan penyimpangan relatif terhadap waktu standar.
HARUS meminimalkan penyimpangan jam audio relatif terhadap CPU
CLOCK_MONOTONIC
saat keduanya aktif.HARUS minimalkan latensi audio pada transduser di perangkat.
HARUS minimalkan latensi audio melalui audio digital USB.
HARUS mendokumentasikan pengukuran latensi audio pada semua jalur.
HARUS meminimalkan jitter dalam waktu entri callback penyelesaian buffer audio, karena hal ini memengaruhi persentase bandwidth CPU penuh yang dapat digunakan oleh callback.
HARUS menyediakan nol gangguan audio dalam penggunaan normal pada latensi yang dilaporkan.
HARUS menyediakan nol perbedaan latensi antar-saluran.
HARUS meminimalkan latensi rata-rata MIDI pada semua transpor.
HARUS meminimalkan variabilitas latensi MIDI di bawah beban (jitter) pada semua transpor.
HARUS memberikan stempel waktu MIDI yang akurat pada semua transpor.
HARUS minimalkan derau sinyal audio pada transduser di perangkat, termasuk periode segera setelah cold start.
HARUS menyediakan nol perbedaan jam audio antara sisi input dan output endpoint yang sesuai, jika keduanya aktif. Contoh pencocokan titik akhir mencakup mikrofon dan speaker di perangkat, atau input colokan audio dan output-nya.
HARUS menangani callback penyelesaian buffer audio untuk sisi input dan output titik akhir yang sesuai pada thread yang sama saat keduanya aktif, dan masukkan callback output segera setelah ditampilkan dari callback input. Atau jika tidak memungkinkan untuk menangani callback pada thread yang sama, maka masukkan callback output segera setelah memasukkan callback input untuk mengizinkan aplikasi untuk memiliki waktu yang konsisten di sisi input dan {i>output<i}.
HARUS minimalkan perbedaan fase antara buffering audio HAL untuk input dan output dari endpoint yang sesuai.
HARUS minimalkan latensi sentuh.
HARUS meminimalkan variabilitas latensi sentuh saat terjadi beban (jitter).
Mengakhiri persyaratan baru
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Jika implementasi perangkat memenuhi semua persyaratan di atas, implementasi tersebut:
- [C-SR-4] SANGAT DIREKOMENDASIKAN untuk melaporkan dukungan fitur
android.hardware.audio.pro
melaluiandroid.content.pm.PackageManager
.
Mengakhiri persyaratan baru
Jika implementasi perangkat menyertakan colokan audio 3,5 mm konduktor 4, implementasi tersebut:
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [C-2-1] HARUS memiliki rata-rata Latensi Audio bolak-balik Berkelanjutan, seperti yang didefinisikan dalam pasal 5.6 Latensi Audio, dalam waktu 20 milidetik atau kurang, lebih dari 5 pengukuran dengan Rata-rata Deviasi Absolut kurang dari 5 milidetik selama jalur colokan audio menggunakan Dongle Loopback Audio.
Mengakhiri persyaratan baru
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [P-2-2]
[C-SR-5]REKOMENDASI YANG SANGAT DIREKOMENDASIKAN untukHARUS bagian patuhi Spesifikasi perangkat seluler (colokan) dari Spesifikasi Headset Audio Berkabel (v1.1).
Mengakhiri persyaratan baru
Jika implementasi perangkat menghilangkan colokan audio 3,5 mm konduktor 4 dan menyertakan port USB yang mendukung mode host USB, yaitu:
- [C-3-1] HARUS mengimplementasikan class audio USB.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [C-3-2] HARUS memiliki rata-rata Latensi Audio bolak-balik Berkelanjutan 25 milidetik atau kurang, lebih dari 5 pengukuran dengan Deviasi Absolut Rata-rata kurang dari 5 milidetik melalui porta mode host USB menggunakan kelas audio USB. (Ini dapat diukur menggunakan adaptor USB-3,5 mm dan Audio Loopback Dongle, atau menggunakan antarmuka audio USB dengan kabel patch yang menghubungkan input ke output).
- [C-SR-6] SANGAT DIREKOMENDASIKAN untuk mendukung I/O simultan hingga 8 saluran setiap arah, frekuensi sampel 96 kHz, dan kedalaman 24-bit atau 32-bit, saat digunakan dengan periferal audio USB yang juga mendukung persyaratan ini.
- [C-SR-7] SANGAT DIREKOMENDASIKAN untuk memenuhi kelompok persyaratan ini menggunakan API audio native AAudio melalui jalur MMAP.
Mengakhiri persyaratan baru
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Jika implementasi perangkat menyertakan port HDMI, implementasi tersebut:
- HARUS mendukung output dalam stereo dan delapan saluran pada 20-bit atau Kedalaman 24-bit dan 192 kHz tanpa kehilangan kedalaman bit atau resampling, setidaknya dalam satu konfigurasi.
Mengakhiri persyaratan baru
5.11. Ambil untuk Belum Diproses
Android menyertakan dukungan untuk perekaman audio yang belum diproses melalui
Sumber audio android.media.MediaRecorder.AudioSource.UNPROCESSED
. Di beberapa
OpenSL ES, dapat diakses dengan preset rekaman
SL_ANDROID_RECORDING_PRESET_UNPROCESSED
.
Jika implementasi perangkat ditujukan untuk mendukung sumber audio yang belum diproses dan yang tersedia untuk aplikasi pihak ketiga, mereka:
[C-1-1] HARUS melaporkan dukungan melalui
android.media.AudioManager
properti PROPERTI_SUPPORT_AUDIO_SOURCE_UNRATINGED.[C-1-2] HARUS menunjukkan kira-kira amplitudo-versus-frekuensi datar karakteristik pada rentang frekuensi menengah: khususnya ±10 dB dari 100 Hz hingga 7.000 Hz untuk setiap mikrofon yang digunakan untuk merekam video yang belum diproses sumber audio.
[C-1-3] HARUS menunjukkan tingkat amplitudo dalam frekuensi rendah jarak jauh: secara khusus 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 tingkat amplitudo dalam frekuensi tinggi rentang: khususnya dari ±30 dB dari 7000 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 sedemikian rupa sehingga sinusoidal 1000 Hz sumber nada yang diputar pada Level Tekanan Suara (SPL) 94 dB menghasilkan respons dengan RMS 520 untuk sampel 16 bit (atau Skala Penuh -36 dB untuk floating point/double sampel presisi) untuk setiap mikrofon yang digunakan untuk merekam audio yang belum diproses sumber audio.
[C-1-6] HARUS memiliki rasio sinyal-terhadap-noise (SNR) pada 60 dB atau lebih tinggi untuk setiap mikrofon yang digunakan untuk merekam sumber audio yang belum diproses. (sedangkan SNR diukur sebagai selisih antara 94 dB SPL dan SPL ekuivalen SPL noise mandiri, A-weighted).
[C-1-7] HARUS memiliki total distorsi harmonik (THD) kurang dari 1% untuk 1 kHZ pada level input SPL 90 dB di setiap mikrofon yang digunakan merekam sumber audio yang belum diproses.
[C-1-8] HARUS tidak memiliki pemrosesan sinyal lainnya (mis. Perolehan Otomatis Control, High Pass Filter, atau Echo cancel) di jalur selain pengganda tingkat untuk membawa level tersebut ke rentang yang diinginkan. Dengan kata lain:
- [C-1-9] Jika terdapat pemrosesan sinyal pada arsitektur untuk alasan ini HARUS dinonaktifkan dan secara efektif memberikan penundaan nol atau latensi tambahan ke jalur sinyal.
- [C-1-10] Pengganda level, meskipun diizinkan berada di jalur, TIDAK BOLEH menambah penundaan atau latensi ke jalur sinyal.
Semua pengukuran SPL dilakukan langsung di sebelah mikrofon yang diuji. Untuk beberapa konfigurasi mikrofon, persyaratan ini berlaku untuk setiap mikrofon.
Jika implementasi perangkat mendeklarasikan android.hardware.microphone
, tetapi tidak
mendukung sumber audio yang belum diproses, yaitu:
- [C-2-1] HARUS menampilkan
null
untukAudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED)
Metode API, untuk menunjukkan kurangnya dukungan dengan benar. - [C-SR-1] masih SANGAT DIREKOMENDASIKAN untuk memenuhi persyaratan bagi 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 dekoder video mengiklankan dukungan untuk Color_FormatYUVP010, maka:
[C-1-1] HARUS mendukung format P010 untuk pembacaan CPU (ImageReader, MediaImage, ByteBuffer). Di Android 13, P010 dilonggarkan agar memungkinkan langkah arbitrer untuk Y dan bidang UV.
[C-1-2] Buffering output P010 HARUS dapat diambil sampelnya oleh GPU (jika dialokasikan dengan penggunaan GPU_SAMPLING). Hal ini memungkinkan komposisi GPU dan pemetaan nada oleh aplikasi.
Jika dekoder video mengiklankan dukungan untuk Color_Format32bitABGR2101010, maka:
- [C-2-1] HARUS mendukung format RGBA_1010102 untuk permukaan output dan Dapat dibaca oleh CPU (output ByteBuffer).
Jika encoder video mengiklankan dukungan untuk Color_FormatYUVP010, maka:
- [C-3-1] HARUS mendukung format P010 untuk permukaan input dan CPU-yang dapat ditulis (ImageWriter, MediaImage, ByteBuffer).
Jika encoder video mengiklankan dukungan untuk Color_Format32bitABGR2101010, maka:
- [C-4-1] HARUS mendukung format RGBA_1010102 untuk permukaan input dan dapat ditulis oleh CPU (ImageWriter, ByteBuffer). Catatan: Mengonversi antara berbagai transfer kurva TIDAK diperlukan untuk encoder.
Persyaratan Pengambilan Gambar HDR
Untuk semua encoder video yang mendukung profil HDR, implementasi perangkat:
[C-5-1] TIDAK BOLEH berasumsi bahwa metadata HDR sudah tepat. Misalnya, {i>frame <i}yang dienkode dapat memiliki {i>pixel<i} yang melebihi tingkat luminans puncak, atau histogram mungkin tidak mewakili frame.
HARUS menggabungkan metadata dinamis HDR untuk menghasilkan aset HDR statis yang sesuai metadata untuk streaming yang dienkode, dan output tersebut harus dihasilkan di akhir sesi encoding.
Jika implementasi perangkat mendukung perekaman HDR menggunakan CamcorderProfile API maka mereka:
[C-6-1] juga HARUS mendukung pengambilan gambar HDR melalui Camera2 API.
[C-6-2] HARUS mendukung setidaknya satu encoder video dengan akselerasi hardware untuk setiap teknologi HDR yang didukung.
[C-6-3] HARUS mendukung (minimal) penangkapan HLG.
[C-6-4] HARUS mendukung penulisan metadata HDR (jika berlaku untuk HDR ) ke dalam file video yang direkam. Untuk AV1, HEVC, dan DolbyVision artinya termasuk metadata ke dalam bitstream yang dienkode.
[C-6-5] HARUS mendukung P010 dan Color_FormatYUVP010.
[C-6-6] HARUS mendukung pemetaan nada HDR ke SDR dalam setelan default decoder dengan akselerasi hardware untuk profil yang direkam. Dengan kata lain, {i>SUMIF<i} memiliki daftar sel jika perangkat dapat menangkap HEVC HDR10+, dekoder HEVC default HARUS dapat untuk mendekode streaming yang direkam di SDR.
Persyaratan Pengeditan HDR
Jika implementasi perangkat menyertakan encoder video yang mendukung pengeditan HDR, maka mereka:
- HARUS menggunakan latensi minimal untuk menghasilkan metadata HDR jika tidak ada, dan HARUS menangani dengan baik situasi ketika {i>metadata <i}ada untuk beberapa {i>frame<i} dan bukan untuk yang lain. {i>Metadata<i} ini HARUS tepat (misalnya, mewakili luminans puncak dan histogram frame yang sebenarnya).
Jika implementasi perangkat menyertakan codec yang mendukung FEATURE_HdrEditing
, maka
codec itu:
[C-7-1] HARUS mendukung setidaknya satu profil HDR.
[C-7-2] HARUS mendukung
FEATURE_HdrEditing
untuk semua profil HDR yang diiklankan oleh codec itu. Dengan kata lain, mereka HARUS mendukung pembuatan metadata HDR saat tidak ada untuk semua profil HDR yang didukung dan menggunakan metadata HDR.[C-7-3] HARUS mendukung format input encoder video berikut yang sepenuhnya mempertahankan sinyal hasil dekode HDR:
- RGBA_1010102 (sudah ada di kurva transfer target) untuk kedua input platform dan ByteBuffer, dan HARUS mengiklankan dukungan untuk Color_Format32bitABGR2101010.
Jika implementasi perangkat menyertakan codec yang mendukung FEATURE_HdrEditing, maka perangkat:
- [C-7-4] HARUS mengiklankan dukungan untuk ekstensi OpenGL EXT_YUV_target.
6. Kompatibilitas Opsi dan Developer Tools
6.1. Alat Pengembang
Implementasi perangkat:
- [C-0-1] HARUS mendukung Android Developer Tools yang disediakan di Android SDK.
- Android Debug Bridge (adb)
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [C-0-2] HARUS mendukung adb seperti yang didokumentasikan dalam Android SDK dan shell
yang disediakan dalam AOSP, yang
dapat digunakan oleh pengembang aplikasi,
termasuk
dumpsys
,cmd stats
, dan Simpleperf.
Mengakhiri persyaratan baru
- [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 isi sistem perangkat peristiwa (Batterystats, diskstats, sidik jari, graphicsstats, netstats, notifikasi, procstats) yang dicatat melalui perintah {i>dumpsys<i}.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [C-0-10] HARUS merekam, tanpa penghapusan, dan membuat peristiwa berikut
dapat diakses dan tersedia untuk perintah shell
cmd stats
dan Class API SistemStatsManager
.- ActivityForegroundStateDiubah
- Anomali Terdeteksi
- AppBreadcrumbDilaporkan
- AppCrashTerjadi
- AppStartTerjadi
- TingkatBateraiDiubah
- BatterySaverModeStateDiubah
- BleScanResultReceived
- BleScanStateDiubah
- PengisianStateDiubah
- DeviceIdleModeStateDiubah
- ForegroundServiceStateDiubah
- GpsScanStateDiubah
- InputDeviceUsageReports
- JobStateDiubah
- KeyboardDikonfigurasi
- KeyboardSystemsEventDilaporkan
- PluggedStateDiubah
- DijadwalkanJobStateDiubah
- Status Layar Diubah
- SyncStateDiubah
- Real-Time Berlalu Sistem
- Penggunaan Touchpad
- {i>UidProcessStateDiubah<i}
- WakelockStateDiubah
- WakeupAlarm Terjadi
- WifiLockStateDiubah
- WifiMulticastLockStateDiubah
- WifiScanStateDiubah
Mengakhiri persyaratan baru
- [C-0-4] HARUS menonaktifkan daemon adb sisi perangkat secara default dan HARUS ada mekanisme yang dapat diakses oleh pengguna untuk mengaktifkan Android Debug Jembatan.
- [C-0-5] HARUS mendukung adb aman. Android menyertakan dukungan untuk adb. adb aman memungkinkan adb pada host terautentikasi yang dikenal.
- [C-0-6] HARUS menyediakan mekanisme yang memungkinkan adb terhubung dari mesin host. Khususnya:
Jika implementasi perangkat tanpa port USB mendukung mode periferal, implementasi tersebut:
- [C-3-1] HARUS mengimplementasikan adb melalui jaringan area lokal (seperti Ethernet atau Wi-Fi).
- [C-3-2] HARUS menyediakan {i>driver<i} untuk Windows 7, 8 dan 10, memungkinkan developer untuk terhubung ke perangkat menggunakan protokol adb.
Jika implementasi perangkat mendukung koneksi adb ke mesin host melalui Wi-Fi atau Ethernet:
- [C-4-1] HARUS memiliki metode
AdbManager#isAdbWifiSupported()
tampilkantrue
.
Jika implementasi perangkat mendukung koneksi adb ke mesin host melalui Wi-Fi atau Ethernet, dan menyertakan setidaknya satu kamera, yaitu:
- [C-5-1] HARUS memiliki metode
AdbManager#isAdbWifiQrSupported()
tampilkantrue
.
Layanan Pemantau Debug Dalvik (ddms)
- [C-0-7] HARUS mendukung semua fitur ddms seperti yang didokumentasikan dalam Android SDK. Karena ddms menggunakan adb, dukungan untuk ddms SEHARUSNYA tidak aktif secara default, namun HARUS didukung setiap kali pengguna telah mengaktifkan Android Debug Bridge, seperti di atas.
-
- [C-0-9] HARUS mendukung alat systrace seperti yang didokumentasikan di Android SDK. Systrace harus tidak aktif secara default dan HARUS ada yang dapat diakses oleh pengguna mekanisme untuk mengaktifkan Systrace.
-
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mengekspos
/system/bin/perfetto
biner ke pengguna {i>shell<i} yang sesuai dengan {i>cmdline<i} dokumentasi perfetto. - [C-SR-2] Biner perfetto SANGAT DIREKOMENDASIKAN untuk diterima sebagai input konfigurasi protobuf yang sesuai dengan skema yang ditentukan dalam dokumentasi perfetto.
- [C-SR-3] Biner perfetto SANGAT DIREKOMENDASIKAN untuk menulis sebagai output protobuf yang sesuai dengan skema yang ditentukan dalam dokumentasi perfetto.
- [C-SR-4] SANGAT DIREKOMENDASIKAN untuk menyediakan, melalui biner perfetto, setidaknya sumber data yang dijelaskan dalam dokumentasi perfetto.
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mengekspos
-
- [C-0-12] HARUS menulis Atom
LMK_KILL_OCCURRED_FIELD_NUMBER
ke statistik saat aplikasi dihentikan oleh Low Memory Killer.
- [C-0-12] HARUS menulis Atom
Mode Pengujian Harness Jika implementasi perangkat mendukung perintah shell
cmd testharness
dan menjalankancmd testharness enable
, mereka:- [C-2-1] HARUS mengembalikan
true
untukActivityManager.isRunningInUserTestHarness()
- [C-2-2] HARUS menerapkan Mode Uji Coba seperti yang dijelaskan dalam Dokumentasi Mode Uji Coba.
- [C-2-1] HARUS mengembalikan
Informasi pekerjaan GPU
Implementasi perangkat:
- [C-0-13] HARUS mengimplementasikan perintah shell
dumpsys gpu --gpuwork
untuk menampilkan data pekerjaan GPU gabungan yang ditampilkan oleh kernelpower/gpu_work_period
tracepoint, atau tidak menampilkan data jika tracepoint tidak didukung. AOSP implementasinya adalahframeworks/native/services/gpuservice/gpuwork/
.
- [C-0-13] HARUS mengimplementasikan perintah shell
Jika implementasi perangkat melaporkan dukungan Vulkan 1.0 atau yang lebih tinggi melalui
android.hardware.vulkan.version
tombol fitur, yaitu:
- [C-1-1] HARUS menyediakan affordance bagi developer aplikasi untuk mengaktifkan/menonaktifkan Lapisan debug GPU.
- [C-1-2] HARUS, saat lapisan debug GPU diaktifkan, menghitung lapisan di yang disediakan oleh alat eksternal (bukan bagian dari platform atau paket aplikasi) yang ditemukan di aplikasi yang dapat di-debug direktori dasar ke mendukung vkEnumerateInstanceLayerProperties() dan vkCreateInstance() Metode API.
6.2. Opsi Developer
Android menyertakan dukungan bagi developer untuk mengonfigurasi aplikasi yang terkait dengan pengembangan.
Implementasi perangkat HARUS memberikan pengalaman yang konsisten untuk Opsi Developer, yaitu:
- [C-0-1] HARUS menghormati android.settings.APPLICATION_DEVELOPMENT_SETTINGS untuk menampilkan setelan terkait pengembangan aplikasi. Android upstream menyembunyikan menu {i>Developer Options<i} secara {i>default<i} dan memungkinkan pengguna untuk luncurkan Opsi Developer setelah menekan tujuh (7) kali pada Settings > Tentang Perangkat > Item menu Build Number.
- [C-0-2] HARUS menyembunyikan Opsi Developer secara default.
- [C-0-3] HARUS menyediakan mekanisme yang jelas yang tidak memberikan preferensi perlakuan kepada satu aplikasi pihak ketiga, bukan aplikasi lain untuk memungkinkan Developer Opsi. HARUS menyediakan dokumen atau situs web yang terlihat oleh publik yang menjelaskan cara mengaktifkan Opsi Developer. Dokumen atau situs web ini HARUS dapat ditautkan dari dokumen Android SDK.
- SEHARUSNYA memiliki notifikasi visual berkelanjutan kepada pengguna saat Developer Opsi diaktifkan dan keamanan pengguna menjadi hal yang harus diutamakan.
- MUNGKIN membatasi akses ke menu Opsi Developer untuk sementara, dengan cara menyembunyikan atau menonaktifkan menu, untuk mencegah gangguan bagi skenario ketika keamanan pengguna juga harus diperhatikan.
7. Kompatibilitas Perangkat Keras
Jika perangkat menyertakan komponen perangkat keras tertentu yang memiliki API untuk developer pihak ketiga:
- [C-0-1] Implementasi perangkat HARUS mengimplementasikannya seperti yang dijelaskan dalam dokumentasi Android SDK.
Jika API di SDK berinteraksi dengan komponen perangkat keras yang dinyatakan opsional dan implementasi perangkat tidak memiliki komponen tersebut:
- [C-0-2] Definisi class lengkap (sebagaimana didokumentasikan oleh SDK) untuk komponen API HARUS tetap ditampilkan.
- [C-0-3] Perilaku API HARUS diimplementasikan sebagai tanpa pengoperasian dalam beberapa mode.
- [C-0-4] Metode API HARUS menampilkan nilai null jika diizinkan oleh SDK dokumentasi tambahan.
- [C-0-5] Metode API HARUS menampilkan implementasi class tanpa pengoperasian dengan nilai null tidak diizinkan oleh dokumentasi SDK.
- [C-0-6] Metode API TIDAK BOLEH menampilkan pengecualian yang tidak didokumentasikan oleh SDK dokumentasi tambahan.
- [C-0-7] Penerapan perangkat HARUS secara konsisten melaporkan hardware yang akurat
informasi konfigurasi melalui
getSystemAvailableFeatures()
dan metodehasSystemFeature(String)
pada android.content.pm.PackageManager untuk sidik jari build yang sama.
Contoh umum skenario di mana persyaratan ini berlaku adalah model telepon API: Bahkan di perangkat non-ponsel, API ini harus diterapkan secara wajar tanpa pengoperasian.
7.1. Tampilan dan Grafis
Android menyertakan fasilitas yang otomatis menyesuaikan aset dan UI aplikasi tata letak yang tepat untuk perangkat guna memastikan bahwa aplikasi pihak ketiga berjalan dengan baik di berbagai tampilan dan konfigurasi perangkat keras. Channel Tampilan yang kompatibel dengan Android adalah layar tampilan yang mengimplementasikan semua perilaku dan API yang dijelaskan dalam Developer Android - Kompatibilitas layar ringkasan, hal ini (7.1) dan subpasalnya, serta setiap jenis perangkat tambahan perilaku tertentu yang didokumentasikan dalam bagian 2 dokumen ini CDD.
Implementasi perangkat:
- [C-0-1] Secara default, HARUS merender aplikasi pihak ketiga hanya ke Layar yang kompatibel dengan Android.
Unit yang dirujuk oleh persyaratan di bagian ini didefinisikan sebagai berikut:
- ukuran diagonal fisik. Jarak dalam inci antara dua sisi yang berlawanan sudut bagian layar yang diterangi cahaya.
- kepadatan. Jumlah piksel yang dicakup oleh garis rentang horizontal atau vertikal 1", dinyatakan sebagai piksel per inci (ppi atau dpi). Di mana nilai ppi dan dpi dicantumkan, dpi horizontal dan vertikal harus berada dalam rentang yang tercantum.
- rasio aspek. Rasio piksel dimensi yang lebih panjang terhadap dimensi layar yang lebih pendek. Misalnya, tampilan 480x854 piksel akan 854/480 = 1,779, atau kira-kira "16:9".
- piksel kepadatan mandiri (dp). Unit piksel virtual yang dinormalisasi ke kepadatan layar 160. Untuk beberapa kepadatan d, dan jumlah piksel p, jumlah piksel kepadatan mandiri dp, adalah dihitung sebagai berikut: dp = (160 / d) * p.
7.1.1 Konfigurasi Layar
7.1.1.1 Ukuran dan Bentuk Layar
Framework UI Android mendukung berbagai tata letak layar logis yang berbeda
dan memungkinkan aplikasi meng-kueri layar konfigurasi saat ini
ukuran tata letak 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 metode dimensi layar piksel kepadatan mandiri (dp) seperti di bawah ini:- Perangkat dengan
Configuration.uiMode
yang ditetapkan sebagai nilai selain UI_MODE_TYPE_WATCH, dan melaporkan ukuransmall
untukConfiguration.screenLayout
, HARUS memiliki minimal 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 memenuhi permintaan dengan benar dinyatakan dukungan untuk ukuran layar melalui <
supports-screens
> di AndroidManifest.xml, seperti yang dijelaskan di dokumentasi Android SDK.MUNGKIN memiliki layar yang kompatibel dengan Android dengan sudut membulat.
Jika implementasi perangkat mendukung layar yang mampu
Konfigurasi ukuran UI_MODE_TYPE_NORMAL
dan menggunakan tampilan fisik dengan
sudut tumpul untuk merender layar ini,
mereka:
[C-1-1] HARUS memastikan bahwa setidaknya salah satu dari persyaratan berikut terpenuhi untuk setiap tampilan tersebut:
- Radius sudut lengkung kurang dari atau sama dengan 38 dp.
- Saat kotak berukuran 18 dp x 18 dp ditambatkan di setiap sudut kotak logis tampilan, setidaknya satu piksel dari setiap kotak terlihat di layar.
HARUS menyertakan kemampuan pengguna untuk beralih ke mode tampilan dengan sudut persegi panjang.
Jika implementasi perangkat hanya mampu melakukan NO_KEYS
konfigurasi keyboard,
dan bermaksud melaporkan dukungan untuk mode UI UI_MODE_TYPE_NORMAL
konfigurasi, mereka:
- [C-4-1] HARUS memiliki ukuran tata letak, tidak termasuk potongan layar, setidaknya 596 dp x 384 dp atau lebih.
Untuk mengetahui detail tentang cara menerapkan API file bantuan atau ekstensi dengan benar, lihat ke dokumentasi publik Jetpack Window Manager.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Jika implementasi perangkat menyertakan satu atau beberapa area tampilan yang kompatibel dengan Android yang dapat dilipat, atau termasuk engsel lipat di antara beberapa Area panel layar yang kompatibel dengan Android dan menyediakan area tampilan tersebut untuk aplikasi tersebut, yaitu:
- [C-4-1] HARUS menerapkan versi Ekstensi Window Manager yang benar Level API seperti yang dijelaskan di Ekstensi WindowManager.
Mengakhiri persyaratan baru
7.1.1.2. Rasio Aspek Layar
Bagian ini dihapus di Android 14.
7.1.1.3. Kepadatan Layar
Framework UI Android menentukan sekumpulan kepadatan logis standar untuk membantu pengembang aplikasi menargetkan sumber daya aplikasi.
Implementasi Perangkat:
[C-0-1] HARUS melaporkan salah satu kepadatan framework Android yang tercantum pada
DisplayMetrics
melaluiDENSITY_DEVICE_STABLE
API dan nilai ini harus berupa nilai statis untuk setiap tampilan fisik. Namun, perangkat MUNGKIN melaporkanDisplayMetrics.density
yang berbeda sesuai dengan perubahan konfigurasi tampilan yang dilakukan oleh pengguna (untuk (misalnya, ukuran tampilan) yang disetel setelah booting awal.HARUS tentukan kepadatan framework Android standar yang dihitung secara numerik yang paling dekat dengan kepadatan fisik layar, atau nilai yang akan dipetakan ke pengukuran ruang pandang bersudut pandang yang sama dengan perangkat genggam.
Jika implementasi perangkat menyediakan {i>affordance<i} untuk mengubah ukuran layar perangkat, mereka:
- [C-1-1] TIDAK BOLEH menskalakan layar lebih dari 1,5 kali
DENSITY_DEVICE_STABLE
atau menghasilkan dimensi layar minimum efektif yang lebih kecil dari 320 dp (setara ke penentu resource sw320dp), mana saja yang lebih dulu. - [C-1-2] TIDAK BOLEH menskalakan layar
lebih kecil dari 0,85 kali lipat
DENSITY_DEVICE_STABLE
. - Untuk memastikan kegunaan yang baik dan ukuran {i>font<i} yang konsisten, DIREKOMENDASIKAN bahwa
penskalaan opsi Tampilan Native berikut tersedia (sekaligus mematuhi batas
yang ditentukan di atas)
- Kecil: 0,85x
- Default: 1x (Skala tampilan native)
- Besar: 1,15x
- Lebih besar: 1,3x
- Terbesar 1,45x
7.1.2. Metrik Display
Jika implementasi perangkat menyertakan layar yang kompatibel dengan Android atau output video ke layar tampilan yang kompatibel dengan Android:
- [C-1-1] HARUS melaporkan nilai yang benar untuk semua layar yang kompatibel dengan Android
yang ditentukan dalam
API
android.util.DisplayMetrics
.
Jika implementasi perangkat tidak menyertakan layar atau {i>output<i} video yang disematkan, mereka:
- [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 minimal satu yang didukung orientasi. Misalnya, perangkat dengan lanskap orientasi tetap layar, seperti televisi atau laptop, SEHARUSNYA hanya laporkanandroid.hardware.screen.landscape
. - [C-0-2] HARUS melaporkan nilai yang benar untuk
orientasinya, kapan pun 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, baik ke layar potret atau lanskap orientasi. Artinya, perangkat harus mengikuti permintaan aplikasi untuk layar tertentu orientasi.
- [C-1-2] TIDAK BOLEH mengubah kepadatan atau ukuran layar yang dilaporkan saat mengubah orientasi.
- MUNGKIN memilih orientasi potret atau lanskap sebagai default.
7.1.4. Akselerasi Grafis 2D dan 3D
7.1.4.1. OpenGL ES
Implementasi perangkat:
- [C-0-1] HARUS mengidentifikasi dengan benar versi OpenGL ES yang didukung (1.1, 2.0,
3.0, 3.1, 3.2) melalui API yang dikelola (seperti melalui
GLES10.getString()
) dan API native. - [C-0-2] HARUS menyertakan dukungan untuk semua API terkelola yang terkait dan untuk setiap versi OpenGL ES yang diidentifikasi untuk didukung.
Jika implementasi perangkat menyertakan output layar atau video, implementasi tersebut:
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [C-1-1] HARUS mendukung
keduanyaOpenGL ES 1.1,dan2.0, 3.0, dan 3.1, sebagaimana yang disertakan dan mendetail di dokumentasi Android SDK.
Mengakhiri persyaratan baru
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung OpenGL ES 3.1.
Mengakhiri persyaratan baru
- HARUS mendukung OpenGL ES 3.2.
Pengujian dEQP OpenGL ES dipartisi menjadi sejumlah daftar pengujian, masing-masing dengan
tanggal/nomor versi terkait. Ini ada dalam pohon sumber Android di
external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt
. Perangkat yang
mendukung OpenGL ES pada tingkat yang dilaporkan sendiri menunjukkan bahwa ia dapat meneruskan dEQP
pengujian di semua daftar pengujian
dari level ini dan level sebelumnya.
Jika implementasi perangkat mendukung salah satu versi OpenGL ES, implementasi tersebut:
- [C-2-1] HARUS melaporkan melalui API native dan API terkelola OpenGL ES setiap ekstensi OpenGL ES lain yang telah mereka terapkan, dan sebaliknya HARUS JANGAN melaporkan string ekstensi yang tidak didukung.
- [C-2-2] HARUS mendukung
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
didukung melalui tombol fitur
android.software.opengles.deqp.level
. - [C-2-4] Setidaknya HARUS mendukung versi 132383489 (mulai 1 Maret 2020) sebagai
dilaporkan dalam tombol fitur
android.software.opengles.deqp.level
. - [C-2-5] HARUS lulus semua Pengujian dEQP OpenGL ES dalam daftar pengujian antar-versi
132383489 dan versi yang ditentukan dalam
Tombol fitur
android.software.opengles.deqp.level
, untuk setiap tombol yang didukung Versi OpenGL ES. - [C-SR-2] SANGAT DIREKOMENDASIKAN untuk mendukung
EGL_KHR_partial_update
danOES_EGL_image_external
ekstensi. HARUS melaporkan secara akurat melalui metode
getString()
, tekstur apa pun format kompresi yang mereka dukung, yang biasanya khusus vendor.HARUS mendukung
EGL_IMG_context_priority
danEGL_EXT_protected_content
ekstensi.
Jika implementasi perangkat mendeklarasikan dukungan untuk OpenGL ES 3.0, 3.1, atau 3.2, mereka:
- [C-3-1] HARUS mengekspor simbol fungsi yang sesuai untuk versi ini di selain simbol fungsi OpenGL ES 2.0 di library libGLESv2.so.
- [C-SR-3] SANGAT DIREKOMENDASIKAN untuk mendukung
OES_EGL_image_external_essl3
.
Jika implementasi perangkat mendukung OpenGL ES 3.2, implementasi tersebut:
- [C-4-1] HARUS mendukung Paket Ekstensi Android OpenGL ES secara keseluruhan.
Jika implementasi perangkat mendukung Android Extension Pack OpenGL ES dalam keseluruhan, mereka:
- [C-5-1] HARUS mengidentifikasi dukungan melalui
android.hardware.opengles.aep
tombol fitur.
Jika implementasi perangkat mengekspos dukungan untuk EGL_KHR_mutable_render_buffer
ekstensi tersebut, mereka:
- [C-6-1] juga HARUS mendukung
EGL_ANDROID_front_buffer_auto_refresh
.
7.1.4.2. Vulkan
Android menyertakan dukungan untuk Vulkan, API lintas platform dengan overhead rendah untuk grafis 3D berperforma tinggi.
Jika implementasi perangkat mendukung OpenGL ES 3.1, implementasi tersebut:
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menyertakan dukungan bagi Vulkan 1.3.
- [C-4-1] TIDAK BOLEH mendukung versi varian Vulkan (yaitu varian bagian dari versi inti Vulkan HARUS nol).
Jika implementasi perangkat menyertakan output layar atau video, implementasi tersebut:
- [C-SR-2] SANGAT DIREKOMENDASIKAN untuk menyertakan dukungan bagi Vulkan 1.3.
Pengujian dEQP Vulkan dipartisi menjadi sejumlah daftar pengujian, masing-masing dengan
tanggal/versi terkait. Ini ada dalam pohon sumber Android di
external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt
. Perangkat yang
mendukung Vulkan di tingkat yang dilaporkan sendiri menunjukkan bahwa Vulkan dapat meneruskan dEQP
pengujian di semua daftar pengujian
dari level ini dan level sebelumnya.
Jika implementasi perangkat menyertakan dukungan untuk Vulkan, implementasi tersebut:
- [C-1-1] HARUS melaporkan nilai bilangan bulat yang benar dengan
android.hardware.vulkan.level
danandroid.hardware.vulkan.version
tombol fitur. - [C-1-2] HARUS menghitung, setidaknya satu
VkPhysicalDevice
untuk Vulkan API nativevkEnumeratePhysicalDevices()
. - [C-1-3] HARUS sepenuhnya menerapkan Vulkan 1.1 API untuk setiap enumerasi yang disebutkan
VkPhysicalDevice
. - [C-1-4] HARUS menghitung layer, yang terdapat dalam library native yang diberi nama sebagai
libVkLayer*.so
dalam direktori library native paket aplikasi, melalui API native VulkanvkEnumerateInstanceLayerProperties()
danvkEnumerateDeviceLayerProperties()
. - [C-1-5] TIDAK BOLEH menghitung lapisan yang disediakan oleh perpustakaan di luar
paket aplikasi Anda, atau menyediakan cara lain untuk melacak atau mencegat
Vulkan API, kecuali jika aplikasi memiliki atribut
android:debuggable
ditetapkan sebagaitrue
atau metadatacom.android.graphics.injectLayers.enable
ditetapkan ketrue
. - [C-1-6] HARUS melaporkan semua string ekstensi yang didukungnya melalui API native Vulkan , dan sebaliknya TIDAK BOLEH melaporkan string ekstensi yang tidak didukung dengan benar.
- [C-1-7] HARUS mendukung VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, dan VK_KHR_inkremental_present.
- [C-1-8] HARUS melaporkan versi maksimum Pengujian dEQP Vulkan
didukung melalui tombol fitur
android.software.vulkan.deqp.level
. - [C-1-9] Setidaknya HARUS mendukung versi
132317953
(mulai 1 Maret 2019) sebagai dilaporkan dalam tombol fiturandroid.software.vulkan.deqp.level
. - [C-1-10] HARUS lulus semua Pengujian dEQP Vulkan dalam daftar pengujian di antara
versi
132317953
dan versi yang ditentukan dalam Tombol fiturandroid.software.vulkan.deqp.level
. - [C-1-11] TIDAK BOLEH menghitung dukungan untuk VK_KHR_video_queue, VK_KHR_video_decode_queue, atau ekstensi VK_KHR_video_encode_queue.
- [C-SR-3] SANGAT DIREKOMENDASIKAN untuk mendukung
VK_KHR_driver_properties
danVK_GOOGLE_display_timing
ekstensi. - [C-1-12] TIDAK BOLEH menghitung dukungan untuk ekstensi VK_KHR_performance_query.
- [C-SR-4] SANGAT DIREKOMENDASIKAN untuk memenuhi persyaratan yang ditentukan oleh profil Dasar Pengukuran Android 2022.
- [C-SR-5] SANGAT DIREKOMENDASIKAN untuk mendukung
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory
danVK_EXT_global_priority
. - [C-SR-6] SANGAT DIREKOMENDASIKAN untuk menggunakan
SkiaVk
dengan HWUI.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
Jika implementasi perangkat menyertakan dukungan untuk Vulkan, implementasi tersebut:
- [C-SR-8] SANGAT DIREKOMENDASIKAN untuk tidak memodifikasi loader Vulkan.
- [C-1-14] TIDAK BOLEH menghitung ekstensi Perangkat Vulkan jenis "KHR",
"GOOGLE", atau "ANDROID" kecuali jika ekstensi ini disertakan dalam
Tombol fitur
android.software.vulkan.deqp.level
.
Mengakhiri persyaratan baru
Jika implementasi perangkat tidak menyertakan dukungan untuk Vulkan 1.0, implementasi tersebut:
- [C-2-1] TIDAK BOLEH mendeklarasikan tanda fitur Vulkan apa pun (mis.
android.hardware.vulkan.level
,android.hardware.vulkan.version
). - [C-2-2] TIDAK BOLEH menghitung
VkPhysicalDevice
untuk API native VulkanvkEnumeratePhysicalDevices()
.
Jika implementasi perangkat menyertakan dukungan untuk Vulkan 1.1 dan mendeklarasikan salah satu Tombol fitur Vulkan yang dijelaskan di sini, mereka:
[C-3-1] HARUS mengekspos dukungan untuk semafor dan handle eksternal
SYNC_FD
dan ekstensiVK_ANDROID_external_memory_android_hardware_buffer
.[C-SR-7] SANGAT DIREKOMENDASIKAN untuk membuat
VK_KHR_external_fence_fd
ekstensi tersedia untuk aplikasi pihak ketiga dan mengaktifkan aplikasi untuk mengekspor payload fence ke dan mengimpor payload pagar dari file POSIX seperti yang dideskripsikan di sini.
7.1.4.3. RenderScript
Implementasi perangkat:
- [C-0-1] HARUS mendukung Android RenderScript, seperti dijelaskan dalam dokumentasi Android SDK.
7.1.4.4. Akselerasi Grafis 2D
Android menyertakan mekanisme bagi aplikasi untuk mendeklarasikan bahwa mereka ingin memungkinkan akselerasi perangkat keras untuk grafis 2D pada Aktivitas, Tingkat 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 perangkat keras jika pengembang memintanya dengan mengatur 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 secara langsung tekstur OpenGL ES dengan akselerasi hardware sebagai target rendering dalam hierarki UI.
Implementasi perangkat:
- [C-0-3] HARUS mendukung TextureView API, dan HARUS menunjukkan perilaku yang konsisten dengan implementasi Android upstream.
7.1.4.5. Layar Wide-gamut
Jika implementasi perangkat mengklaim dukungan untuk tampilan gamut lebar melalui
Configuration.isScreenWideColorGamut()
, tindakan tersebut:
- [C-1-1] HARUS memiliki layar dengan kalibrasi warna.
- [C-1-2] HARUS memiliki layar yang gamutnya mencakup gamut warna sRGB sepenuhnya di ruang CIE 1931 xyY.
- [C-1-3] HARUS memiliki layar yang gamutnya memiliki area minimal 90% dari DCI-P3 dalam ruang CIE 1931 xyY.
- [C-1-4] HARUS mendukung OpenGL ES 3.1 atau 3.2 dan melaporkannya dengan benar.
- [C-1-5] HARUS mengiklankan dukungan untuk
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
ekstensi. - [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung
GL_EXT_sRGB
.
Sebaliknya, jika implementasi perangkat tidak mendukung layar gamut lebar, implementasi tersebut:
- [C-2-1] HARUS mencakup 100% atau lebih sRGB di ruang CIE 1931 xyY, meskipun gamut warna layar tidak terdefinisi.
7.1.5. Mode Kompatibilitas Aplikasi Lama
Android menentukan "mode kompatibilitas" di mana kerangka kerja beroperasi dalam 'normal' mode setara ukuran layar (lebar 320 dp) untuk mendapatkan manfaat dari fitur lama aplikasi yang tidak dikembangkan untuk Android versi lama yang sebelum independensi ukuran layar.
7.1.6. Teknologi Layar
Platform Android menyertakan API yang memungkinkan aplikasi merender ke layar yang kompatibel dengan Android. Perangkat HARUS mendukung semua fitur ini API seperti yang ditetapkan oleh Android SDK, kecuali jika secara khusus diizinkan dalam dokumen ini.
Semua tampilan yang kompatibel dengan Android dalam implementasi perangkat:
- [C-0-1] HARUS mampu merender grafis berwarna 16-bit.
- HARUS dukung layar yang mampu menampilkan grafis berwarna 24-bit.
- [C-0-2] HARUS mampu merender animasi.
- [C-0-3] HARUS memiliki rasio aspek piksel (PAR) antara 0,9 dan 1,15. Artinya, rasio aspek piksel HARUS mendekati persegi (1.0) dengan toleransi 10 ~ 15%.
7.1.7 Layar Sekunder
Android menyertakan dukungan untuk tampilan sekunder yang kompatibel dengan Android guna mengaktifkan kemampuan berbagi media dan API developer untuk mengakses layar eksternal.
Jika implementasi perangkat mendukung layar eksternal melalui kabel, nirkabel, atau koneksi layar tambahan tersemat, perangkat tersebut:
- [C-1-1] HARUS menerapkan
DisplayManager
layanan sistem dan API seperti dijelaskan dalam dokumentasi Android SDK.
7.2. Perangkat Masukan
Implementasi perangkat:
- [C-0-1] HARUS mencakup mekanisme input, seperti layar sentuh atau navigasi non-sentuh, untuk menavigasi antarelemen UI.
7.2.1. Keyboard
Jika implementasi perangkat menyertakan dukungan untuk pihak ketiga Aplikasi Editor Metode Input (IME), aplikasi:
- [C-1-1] HARUS mendeklarasikan
android.software.input_methods
tombol fitur. - [C-1-2] HARUS mengimplementasikan
Input Management Framework
sepenuhnya - [C-1-3] HARUS memiliki keyboard software bawaan.
Implementasi perangkat:
- [C-0-1] TIDAK BOLEH menyertakan keyboard fisik yang tidak sesuai dengan salah satu format yang ditentukan dalam android.content.res.Configuration.keyboard (QWERTY atau 12 tombol).
- HARUS menyertakan implementasi soft keyboard tambahan.
- MUNGKIN menyertakan keyboard hardware.
7.2.2. Navigasi Non-sentuh
Android menyertakan dukungan untuk d-pad, trackball, dan wheel sebagai mekanisme untuk navigasi non-sentuh.
Implementasi perangkat:
- [C-0-1] HARUS melaporkan nilai yang benar untuk android.content.res.Configuration.navigation.
Jika implementasi perangkat tidak memiliki navigasi non-sentuh, implementasi tersebut:
- [C-1-1] HARUS menyediakan mekanisme antarmuka pengguna alternatif yang masuk akal untuk pemilihan dan pengeditan teks, kompatibel dengan Input Management Engine. Tujuan implementasi open source Android upstream menyertakan mekanisme pemilihan cocok untuk digunakan dengan perangkat yang tidak memiliki input navigasi non-sentuh.
7.2.3. Tombol Navigasi
Beranda, Terbaru, dan Back fungsi yang biasanya disediakan melalui interaksi dengan tombol fisik khusus atau bagian layar sentuh yang berbeda, sangat penting bagi Android paradigma navigasi, dan karenanya, implementasi perangkat:
- [C-0-1] HARUS menyediakan kemampuan pengguna untuk meluncurkan aplikasi terinstal
yang memiliki aktivitas dengan
<intent-filter>
yang ditetapkan denganACTION=MAIN
danCATEGORY=LAUNCHER
atauCATEGORY=LEANBACK_LAUNCHER
untuk perangkat Televisi implementasi yang tepat. Fungsi Beranda SEHARUSNYA menjadi mekanisme untuk kemampuan pengguna ini. - HARUS menyediakan tombol untuk fungsi Recents dan Back.
Jika fungsi Beranda, Terbaru, atau Kembali disediakan, fungsi tersebut:
- [C-1-1] HARUS dapat diakses dengan satu tindakan (mis. ketuk, klik dua kali, atau {i>gesture <i}), jika salah satunya dapat diakses.
- [C-1-2] HARUS memberikan indikasi yang jelas tentang tindakan tunggal mana yang akan memicu tiap fungsi. Memiliki ikon yang terlihat tercetak pada tombol, yang menunjukkan software pada bagian bilah navigasi layar, atau memandu pengguna melalui alur demo langkah demi langkah yang dipandu selama pengalaman penyiapan siap pakai contoh dari indikasi tersebut.
Implementasi perangkat:
[C-SR-1] SANGAT DIREKOMENDASIKAN untuk tidak menyediakan mekanisme input bagi Fungsi menu karena tidak digunakan lagi dan digantikan oleh bilah tindakan sejak Android 4.0.
[C-SR-2] SANGAT DIREKOMENDASIKAN untuk menyediakan semua fungsi navigasi sebagai dapat dibatalkan. 'Dapat dibatalkan' didefinisikan sebagai kemampuan pengguna untuk mencegah fungsi navigasi dari mengeksekusi (mis. kembali ke beranda, kembali, dll.) jika geser tidak dilepaskan melewati batas tertentu.
Jika implementasi perangkat menyediakan fungsi Menu, implementasi tersebut:
- [C-2-1] HARUS menampilkan tombol tindakan tambahan setiap kali tindakan pop-up menu tambahan tidak kosong dan panel tindakan terlihat.
- [C-2-2] TIDAK BOLEH mengubah posisi pop-up tindakan tambahan ditampilkan dengan memilih tombol tambahan di panel tindakan, tetapi MUNGKIN merender pop-up tindakan tambahan pada posisi yang dimodifikasi di layar saat yang ditampilkan dengan memilih fungsi Menu.
Jika implementasi perangkat tidak menyediakan fungsi Menu, untuk fungsi mundur kompatibilitas, mereka:
- [C-3-1] HARUS menyediakan fungsi Menu untuk aplikasi saat
targetSdkVersion
kurang dari 10, baik dengan tombol fisik, kunci software, atau {i>gestures.<i} Fungsi Menu ini harus dapat diakses kecuali jika disembunyikan bersama dengan fungsi navigasi lainnya.
Jika penerapan perangkat menyediakan fungsi Bantuan, mereka:
- [C-4-1] HARUS membuat fungsi Assist dapat diakses dengan satu tindakan (misalnya, mengetuk, klik dua kali, atau gestur) saat tombol navigasi lain dapat diakses.
- [C-SR-3] SANGAT DIREKOMENDASIKAN untuk menggunakan fungsi tekan lama pada fungsi HOME karena ini interaksi yang ditentukan.
Jika implementasi perangkat menggunakan bagian layar yang berbeda untuk menampilkan tombol navigasi, mereka:
- [C-5-1] Tombol navigasi HARUS menggunakan bagian layar yang berbeda, bukan yang tersedia untuk aplikasi, dan TIDAK BOLEH mengaburkan atau mengganggu bagian dari layar yang tersedia untuk aplikasi.
- [C-5-2] HARUS menyediakan sebagian tampilan untuk aplikasi yang memenuhi persyaratan yang didefinisikan dalam pasal 7.1.1.
- [C-5-3] HARUS mengikuti flag yang ditetapkan oleh aplikasi melalui
View.setSystemUiVisibility()
metode API Anda, sehingga bagian layar yang berbeda ini (alias bilah 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 digunakan untuk melaporkan area pengenalan gestur Beranda. - [C-6-2] Gerakan yang dimulai dalam rect pengecualian seperti yang disediakan dalam
aplikasi latar depan melalui
View#setSystemGestureExclusionRects()
, tapi di luarWindowInsets#getMandatorySystemGestureInsets()
, TIDAK BOLEH disadap untuk fungsi navigasi selama pengecualian rect diizinkan berada dalam batas pengecualian maksimum sebagaimana ditentukan dalam dokumentasi untukView#setSystemGestureExclusionRects()
. - [C-6-3] HARUS mengirim aplikasi latar depan
MotionEvent.ACTION_CANCEL
setelah sentuhan mulai disadap untuk {i>gesture <i}sistem, jika aplikasi latar depan sebelumnya mengirimMotionEvent.ACTION_DOWN
peristiwa. - [C-6-4] HARUS menyediakan {i>affordance<i} pengguna untuk beralih ke {i>on-screen<i}, navigasi berbasis tombol (misalnya, di Setelan).
- HARUS menyediakan fungsi Beranda dengan menggeser ke atas dari tepi bawah orientasi layar saat ini.
- HARUS menyediakan fungsi Terbaru sebagai geser ke atas dan tahan sebelum pelepas, dari area yang sama dengan gestur Beranda.
- {i>Gesture <i}yang dimulai dari
WindowInsets#getMandatorySystemGestureInsets()
TIDAK BOLEH terpengaruh oleh rect pengecualian yang disediakan oleh latar depan aplikasi 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 saat ini layar.
- [C-7-2] Jika panel sistem kustom yang dapat digeser tersedia di sebelah kiri atau tepi kanan, mereka HARUS ditempatkan di 1/3 atas layar dengan indikasi visual yang jelas dan persisten bahwa penarikan akan memanggil panel tersebut, kemudian bukan Kembali. Panel sistem DAPAT dikonfigurasi oleh pengguna sehingga mendarat di bawah 1/3 bagian atas layar tepi tetapi panel sistem TIDAK BOLEH menggunakan lebih dari 1/3 dari tepi.
- [C-7-3] Jika aplikasi latar depan memiliki View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT, atau flag WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE disetel, menggeser dari tepi HARUS berperilaku seperti diimplementasikan dalam AOSP, yaitu yang didokumentasikan dalam SDK.
- [C-7-4] Jika aplikasi latar depan memiliki View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT, atau flag WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE disetel, panel sistem khusus yang dapat digeser HARUS disembunyikan sampai pengguna memasukkan atau meredupkan bilah sistem (alias navigasi dan bilah status) seperti yang diimplementasikan dalam AOSP.
Jika fungsi navigasi kembali disediakan dan pengguna membatalkan tombol Kembali lalu:
- [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 melakukannya
TIDAK mendaftarkan OnBackInvokedCallback
, maka:
- Sistem HARUS menyediakan animasi untuk aplikasi latar depan yang menunjukkan bahwa pengguna akan kembali, seperti yang disebutkan dalam AOSP.
Jika implementasi perangkat memberikan dukungan untuk API sistem setNavBarMode
guna
mengizinkan aplikasi sistem apa pun dengan izin android.permission.STATUS_BAR
untuk menyetel
mode menu navigasi, lalu mereka:
- [C-9-1] HARUS memberikan dukungan untuk ikon yang cocok untuk anak atau 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, {i>touch pad<i}, dan perangkat input sentuh palsu. Penerapan perangkat berbasis layar sentuh dikaitkan dengan tampilan sedemikian rupa, sehingga pengguna memiliki tayangan memanipulasi item di layar. Karena pengguna langsung menyentuh layar, sistem tidak memerlukan affordance tambahan untuk menunjukkan objek sedang dimanipulasi.
Implementasi perangkat:
- SEHARUSNYA memiliki sistem input {i> pointer<i} semacam itu (seperti mouse atau sentuh).
- HARUS mendukung pointer yang dilacak secara independen sepenuhnya.
Jika implementasi perangkat menyertakan layar sentuh (satu sentuhan atau lebih baik) pada layar utama yang kompatibel dengan Android, keduanya:
- [C-1-1] HARUS melaporkan
TOUCHSCREEN_FINGER
untukConfiguration.touchscreen
API. - [C-1-2] HARUS melaporkan
android.hardware.touchscreen
dan tombol fiturandroid.hardware.faketouch
.
Jika implementasi perangkat menyertakan layar sentuh yang dapat melacak lebih dari dengan satu sentuhan pada layar utama yang kompatibel dengan Android, mereka:
- [C-2-1] HARUS melaporkan tombol fitur yang sesuai
android.hardware.touchscreen.multitouch
,android.hardware.touchscreen.multitouch.distinct
,android.hardware.touchscreen.multitouch.jazzhand
sesuai dengan jenis layar sentuh tertentu pada perangkat.
Jika implementasi perangkat bergantung pada perangkat input eksternal seperti mouse atau trackball (yaitu tidak langsung menyentuh layar) untuk input pada Layar yang kompatibel dengan Android dan memenuhi persyaratan sentuhan palsu di pasal 7.2.5, ketentuan tersebut:
- [C-3-1] TIDAK BOLEH melaporkan tombol fitur apa pun yang dimulai dengan
android.hardware.touchscreen
. - [C-3-2] HARUS melaporkan
android.hardware.faketouch
saja. - [C-3-3] HARUS melaporkan
TOUCHSCREEN_NOTOUCH
atasConfiguration.touchscreen
API.
7.2.5. Input Sentuhan Palsu
Antarmuka sentuh palsu menyediakan sistem input pengguna yang mendekati subset dengan kemampuan layar sentuh. Misalnya, {i>mouse<i} atau {i>remote control<i} yang menggerakkan kursor pada layar mendekati sentuhan, tetapi mengharuskan pengguna untuk mengarahkan atau fokus, lalu klik. Berbagai perangkat input seperti mouse, trackpad, dan berbasis giroskop mouse udara, gyro-pointer, joystick, dan trackpad multi-sentuh dapat mendukung interaksi sentuh. Android menyertakan konstanta fitur android.hardware.faketouch, yang berkaitan dengan non-sentuh dengan fidelitas tinggi (berbasis pointer) seperti mouse atau trackpad yang cukup dapat mengemulasi input berbasis sentuhan (termasuk dukungan gestur dasar), dan menunjukkan bahwa perangkat mendukung subset fungsi layar sentuh yang diemulasikan.
Jika implementasi perangkat tidak menyertakan layar sentuh, tetapi menyertakan layar sentuh sistem input pointer yang ingin mereka sediakan, mereka:
- HARUS mendeklarasikan dukungan untuk tombol fitur
android.hardware.faketouch
.
Jika implementasi perangkat mendeklarasikan dukungan untuk android.hardware.faketouch
,
mereka:
- [C-1-1] HARUS melaporkan posisi layar X dan Y absolut lokasi {i>pointer<i} dan menampilkan {i>pointer<i} visual di layar.
- [C-1-2] HARUS melaporkan peristiwa sentuh dengan kode tindakan yang menentukan perubahan status yang terjadi pada pointer turun atau naik di layar.
- [C-1-3] HARUS mendukung pointer ke bawah dan ke atas pada suatu 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 sebuah 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 bergerak ke titik arbitrer lain di layar, diikuti oleh pointer ke atas, yang memungkinkan pengguna mengemulasikan gestur sentuh.
- [C-1-6] HARUS mendukung pointer ke bawah kemudian memungkinkan pengguna untuk dengan cepat memindahkan ke posisi yang berbeda di layar dan kemudian pointer ke atas di layar, yang memungkinkan pengguna melemparkan objek di layar.
Jika implementasi perangkat mendeklarasikan dukungan untuk
android.hardware.faketouch.multitouch.distinct
, ini:
- [C-2-1] HARUS mendeklarasikan dukungan untuk
android.hardware.faketouch
. - [C-2-2] HARUS mendukung pelacakan yang berbeda dari dua atau beberapa pointer independen input.
Jika implementasi perangkat mendeklarasikan dukungan untuk
android.hardware.faketouch.multitouch.jazzhand
, ini:
- [C-3-1] HARUS mendeklarasikan dukungan untuk
android.hardware.faketouch
. - [C-3-2] HARUS mendukung pelacakan 5 yang berbeda (melacak tangan jari) atau lebih input pointer sepenuhnya secara independen.
7.2.6. Dukungan Pengontrol Game
7.2.6.1. Pemetaan Tombol
Implementasi perangkat:
- [C-1-1] HARUS mampu memetakan peristiwa HID ke konstanta
InputEvent
terkait seperti yang tercantum dalam tabel di bawah. Implementasi Android upstream memenuhi persyaratan ini.
Jika implementasi perangkat menyematkan pengontrol atau menyertakan pengontrol terpisah dalam kotak yang akan menyediakan sarana untuk memasukkan semua peristiwa yang tercantum dalam tabel di bawah, penerapan tersebut akan:
- [C-2-1] HARUS mendeklarasikan tombol fitur
android.hardware.gamepad
Tombol | Penggunaan HID2 | Tombol Android |
---|---|---|
J1 | 0x09 0x0001 | KEYCODE_BUTTON_A (96) |
B1 | 0x09 0x0002 | KEYCODE_BUTTON_B (97) |
X1 | 0x09 0x0004 | KEYCODE_BUTTON_X (99) |
Y1 | 0x09 0x0005 | KEYCODE_BUTTON_Y (100) |
D-pad atas1 D-pad bawah1 |
0x01 0x00393 | AXIS_HAT_Y4 |
D-pad kiri1 D-pad kanan1 |
0x01 0x00393 | AXIS_HAT_X4 |
Tombol bahu kiri1 | 0x09 0x0007 | KEYCODE_BUTTON_L1 (102) |
Tombol bahu kanan1 | 0x09 0x0008 | KEYCODE_BUTTON_R1 (103) |
Klik stik kiri1 | 0x09 0x000E | KEYCODE_BUTTON_THUMBL (106) |
Klik stik kanan1 | 0x09 0x000F | KEYCODE_BUTTON_THUMBR (107) |
Kembali1 | 0x0c 0x0224 | KEYCODE_BACK (4) |
1 KeyEvent
2 Penggunaan HID di atas harus dideklarasikan dalam Game pad CA (0x01 0x0005).
3 Penggunaan ini harus memiliki Logis Minimum 0, a Maksimum Logis 7, Minimum Fisik 0, Maksimum Fisik 315, Unit dalam Derajat, dan Ukuran Laporan 4. Nilai logika didefinisikan sebagai rotasi searah jarum jam dari sumbu vertikal; misalnya, nilai logika 0 menunjukkan tidak ada rotasi dan tombol atas yang ditekan, sedangkan nilai logis dari 1 mewakili rotasi 45 derajat dan kedua tombol atas dan kiri menjadi ditekan.
Kontrol Analog1 | Penggunaan HID | Tombol Android |
---|---|---|
Pemicu Kiri | Info tambahan 0x02 0x00C5 | AXIS_LTRIGGER |
Pemicu Kanan | 0x02 0x00C4 | AXIS_RTRIGGER |
Joystick Kiri | 0x01 0x0030 0x01 0x0031 |
AXIS_X AKSI_Y |
Joystick Kanan | 0x01 0x0032 0x01 0x0035 |
AXIS_Z RZ_AXIS |
7.2.7. Remote Control
Lihat Bagian 2.3.1 untuk mengetahui persyaratan untuk perangkat tertentu.
7.3. Sensor
Jika implementasi perangkat menyertakan jenis sensor tertentu yang memiliki API yang sesuai untuk developer pihak ketiga, implementasi perangkat HARUS mengimplementasikan API tersebut seperti yang dijelaskan dalam dokumentasi Android SDK dan dokumentasi Open Source Android tentang sensor.
Implementasi perangkat:
- [C-0-1] HARUS secara akurat melaporkan ada atau tidaknya sensor sesuai
android.content.pm.PackageManager
. - [C-0-2] HARUS mengembalikan daftar akurat dari sensor yang didukung melalui
SensorManager.getSensorList()
dan metode serupa. - [C-0-3] HARUS berperilaku wajar untuk semua API sensor lainnya (misalnya, dengan
menampilkan
true
ataufalse
yang sesuai saat aplikasi mencoba mendaftar pemroses, tidak memanggil pemroses sensor saat sensor yang sesuai sekarang; dll.).
Jika implementasi perangkat menyertakan jenis sensor tertentu yang memiliki API yang sesuai untuk developer pihak ketiga, mereka:
- [C-1-1] HARUS melaporkan semua pengukuran sensor menggunakan nilai Sistem Satuan Internasional (metrik) yang relevan untuk masing-masing seperti yang dijelaskan 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. Penundaan ini tidak termasuk penundaan pemfilteran.
- [C-1-3] HARUS melaporkan sampel sensor pertama dalam waktu 400 milidetik + 2 * sample_time sensor yang diaktifkan. Sampel ini bisa diterima memiliki akurasi 0.
- [C-1-4] Untuk setiap API yang ditunjukkan oleh dokumentasi Android SDK sebagai sensor berkelanjutan, implementasi perangkat HARUS terus memberikan sampel data periodik yang SEHARUSNYA memiliki {i>jitter<i} di bawah 3%, di mana jitter didefinisikan sebagai standar deviasi dari selisih nilai stempel waktu yang dilaporkan di antara peristiwa berturut-turut.
- [C-1-5] HARUS memastikan bahwa streaming peristiwa sensor TIDAK BOLEH mencegah CPU perangkat memasuki status ditangguhkan atau aktif dari status ditangguhkan.
- [C-1-6] HARUS melaporkan waktu acara dalam nanodetik seperti yang didefinisikan dalam dokumentasi Android SDK, yang mewakili waktu peristiwa terjadi dan disinkronkan dengan Jam SystemClock.elapsedRealtimeNano().
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mengalami error sinkronisasi stempel waktu di bawah 100 milidetik, dan SEHARUSNYA memiliki error sinkronisasi stempel waktu di bawah 1 milidetik.
- Ketika beberapa sensor diaktifkan, konsumsi daya TIDAK BOLEH melebihi jumlah konsumsi daya masing-masing sensor yang dilaporkan.
Daftar di atas tidak komprehensif; perilaku Android SDK yang didokumentasikan dan Dokumentasi Open Source Android tentang sensor akan dianggap otoritatif.
Jika implementasi perangkat menyertakan jenis sensor tertentu yang memiliki API yang sesuai untuk developer pihak ketiga, mereka:
- [C-1-6] HARUS menyetel resolusi bukan nol untuk semua sensor, dan melaporkan nilainya
melalui
Sensor.getResolution()
Metode API.
Beberapa jenis sensor bersifat komposit, artinya sensor tersebut dapat diperoleh dari data yang disediakan oleh satu atau beberapa sensor lainnya. (Contohnya termasuk sensor orientasi dan sensor akselerasi linear.)
Implementasi perangkat:
- HARUS menerapkan jenis sensor ini, jika jenis sensor tersebut termasuk sensor fisik prasyarat seperti yang dijelaskan di jenis sensor.
Jika implementasi perangkat menyertakan sensor komposit, implementasi tersebut:
- [C-2-1] HARUS mengimplementasikan sensor seperti yang dijelaskan dalam Panduan Open Source Android dokumentasi tentang sensor gabungan.
Jika implementasi perangkat menyertakan jenis sensor tertentu yang memiliki API yang sesuai untuk developer pihak ketiga dan sensor hanya melaporkan satu nilai tertentu, maka implementasi perangkat:
- [C-3-1] HARUS menyetel resolusi ke 1 untuk sensor dan melaporkan nilainya
melalui
Sensor.getResolution()
Metode API.
Jika implementasi perangkat menyertakan jenis sensor tertentu yang mendukung SensorInfoTambahan#TYPE_VEC3_CALIBRATION dan sensor terekspos ke developer pihak ketiga, mereka:
- [C-4-1] TIDAK BOLEH menyertakan semua kalibrasi tetap yang ditentukan oleh pabrik parameter dalam data yang diberikan.
Jika implementasi perangkat menyertakan kombinasi akselerometer 3-sumbu, Sensor giroskop 3 sumbu, atau sensor magnetometer, adalah:
- [C-SR-2] SANGAT DIREKOMENDASIKAN untuk memastikan akselerometer, giroskop, dan magnetometer memiliki posisi relatif tetap, sehingga jika perangkat dapat ditransformasi (mis. perangkat foldable), sumbu sensor tetap sejajar dan konsisten dengan sistem koordinat sensor di seluruh perangkat yang memungkinkan status transformasi.
7.3.1. Akselerometer
Implementasi perangkat:
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menyertakan akselerometer 3 sumbu.
Jika implementasi perangkat menyertakan akselerometer, implementasi tersebut:
- [C-1-1] HARUS dapat melaporkan peristiwa hingga frekuensi setidaknya 50 Hz.
- [C-1-3] HARUS mematuhi Sistem koordinat sensor Android sebagaimana dijelaskan dalam API Android.
- [C-1-4] HARUS mampu mengukur dari jatuh bebas hingga empat kali
gravity(4g)
atau lebih pada sumbu apa pun. - [C-1-5] HARUS memiliki resolusi minimal 12-bit.
- [C-1-6] HARUS memiliki deviasi standar tidak lebih besar dari 0,05 m/s^, di mana standar deviasi harus dihitung per sumbu pada sampel dikumpulkan selama minimal 3 detik dengan frekuensi sampling tercepat.
- HARUS melaporkan peristiwa hingga minimal 200 Hz.
- HARUS memiliki resolusi minimal 16-bit.
- HARUS dikalibrasi saat digunakan jika karakteristiknya berubah siklus proses dan menerima kompensasi, dan mempertahankan parameter kompensasi setelah memulai ulang perangkat.
- HARUS diberi kompensasi suhu.
Jika implementasi perangkat menyertakan akselerometer 3 sumbu, implementasi tersebut:
- [C-2-1] HARUS menerapkan dan melaporkan sensor
TYPE_ACCELEROMETER
. - [C-SR-4] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan
TYPE_SIGNIFICANT_MOTION
sensor komposit. - [C-SR-5] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan dan melaporkan
Sensor
TYPE_ACCELEROMETER_UNCALIBRATED
. Perangkat Android SANGAT DIREKOMENDASIKAN untuk memenuhi persyaratan ini sehingga mereka dapat melakukan upgrade ke rilis platform mendatang, yang mungkin WAJIB. - HARUS mengimplementasikan
TYPE_SIGNIFICANT_MOTION
,TYPE_TILT_DETECTOR
,TYPE_STEP_DETECTOR
,TYPE_STEP_COUNTER
sensor gabungan seperti yang dijelaskan dalam dokumen Android SDK.
Jika implementasi perangkat menyertakan akselerometer dengan kurang dari 3 sumbu, maka:
- [C-3-1] HARUS menerapkan dan melaporkan sensor
TYPE_ACCELEROMETER_LIMITED_AXES
. - [C-SR-6] STRONGLY_RECOMMENDED untuk mengimplementasikan dan melaporkan
Sensor
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
.
Jika implementasi perangkat mencakup akselerometer 3-sumbu dan salah satu
TYPE_SIGNIFICANT_MOTION
, TYPE_TILT_DETECTOR
, TYPE_STEP_DETECTOR
,
Sensor gabungan TYPE_STEP_COUNTER
diterapkan:
- [C-4-1] Jumlah dari konsumsi daya HARUS selalu kurang dari 4 mW.
- Masing-masing harus di bawah 2 mW dan 0,5 mW saat perangkat dalam kondisi statis.
Jika implementasi perangkat mencakup akselerometer 3-sumbu dan sensor giroskop 3-sumbu, mereka:
- [C-5-1] HARUS mengimplementasikan
TYPE_GRAVITY
danTYPE_LINEAR_ACCELERATION
sensor komposit. - [C-SR-7] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan
Sensor komposit
TYPE_GAME_ROTATION_VECTOR
.
Jika implementasi perangkat mencakup akselerometer 3-sumbu, sensor giroskop 3-sumbu, dan sensor magnetometer, keduanya:
- [C-6-1] HARUS mengimplementasikan sensor komposit
TYPE_ROTATION_VECTOR
.
7.3.2. Magnetometer
Implementasi perangkat:
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menyertakan magnetometer 3-sumbu (kompas).
Jika implementasi perangkat menyertakan magnetometer 3-sumbu, implementasi tersebut:
- [C-1-1] HARUS mengimplementasikan sensor
TYPE_MAGNETIC_FIELD
. - [C-1-2] HARUS dapat melaporkan peristiwa hingga frekuensi setidaknya 10 Hz dan HARUS melaporkan peristiwa hingga setidaknya 50 Hz.
- [C-1-3] HARUS mematuhi sistem koordinat sensor Android seperti yang dijelaskan dalam Android API.
- [C-1-4] HARUS mampu mengukur antara -900 μT dan +900 μT pada masing-masing sebelum saturasi.
- [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 online dan kompensasi untuk setrika keras bias data, dan mempertahankan parameter kompensasi antara {i>reboot <i}perangkat.
- [C-1-8] HARUS menerapkan kompensasi besi lunak—kalibrasi dapat dilakukan saat perangkat digunakan atau selama produksi.
- [C-1-9] HARUS memiliki deviasi standar, dihitung berdasarkan per sumbu sampel yang dikumpulkan selama jangka waktu minimal 3 detik dengan pengambilan sampel tercepat laju, tidak lebih besar dari 1,5 μT; HARUS memiliki deviasi standar tidak lebih dari 0,5 μT.
- [C-1-10] HARUS mengimplementasikan
TYPE_MAGNETIC_FIELD_UNCALIBRATED
sensor.
Jika implementasi perangkat menyertakan magnetometer 3-sumbu, akselerometer sensor, dan sensor giroskop 3 sumbu, yaitu:
- [C-2-1] HARUS mengimplementasikan sensor komposit
TYPE_ROTATION_VECTOR
.
Jika implementasi perangkat menyertakan magnetometer 3-sumbu, akselerometer, implementasi tersebut:
- DAPAT menerapkan sensor
TYPE_GEOMAGNETIC_ROTATION_VECTOR
.
Jika implementasi perangkat mencakup magnetometer 3-sumbu, akselerometer, dan
Sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR
, keduanya:
- [C-3-1] HARUS mengkonsumsi kurang dari 10 mW.
- SEHARUSNYA kurang dari 3 mW saat sensor didaftarkan untuk mode batch pada 10 Hz.
7.3.3. GPS
Implementasi perangkat:
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menyertakan penerima GPS/GNSS.
Jika implementasi perangkat menyertakan penerima GPS/GNSS dan melaporkan kemampuan
ke aplikasi melalui tombol fitur android.hardware.location.gps
, yaitu:
- [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, multijalur yang dapat diabaikan, HDOP < 2) dalam 10 detik (cepat
waktu ke perbaikan pertama), saat tersambung ke kecepatan data 0,5 Mbps atau lebih cepat
koneksi internet. Persyaratan ini biasanya dipenuhi
dengan menggunakan beberapa
bentuk teknik GPS/GNSS yang Dipandu atau yang Diprediksi
untuk meminimalkan waktu penguncian GPS/GNSS (data Bantuan termasuk Waktu Referensi,
Lokasi Referensi dan Ephemeris/Jam Satelit).
- [C-1-6] Setelah melakukan perhitungan lokasi tersebut, perangkat HARUS menentukan lokasinya, di mana pun, di dalam 5 detik, saat permintaan lokasi dimulai ulang, hingga satu jam setelahnya penghitungan lokasi awal, bahkan ketika permintaan berikutnya dibuat tanpa sambungan data, dan/atau setelah siklus daya.
Dalam kondisi langit terbuka setelah menentukan lokasi, saat diam atau bergerak dengan percepatan 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 rasi bintang. - HARUS dapat melacak setidaknya 24 satelit secara bersamaan, dari banyak rasi bintang (mis. GPS + setidaknya salah satu dari Glonass, Beidou, Galileo).
[C-SR-2] SANGAT DIREKOMENDASIKAN untuk terus memberikan GPS/GNSS normal output lokasi melalui API Penyedia Lokasi GNSS selama ponsel darurat panggilan telepon.
[C-SR-3] SANGAT DIREKOMENDASIKAN untuk melaporkan pengukuran GNSS dari semua konstelasi yang dilacak (seperti yang dilaporkan dalam pesan GnssStatus), dengan pengecualian dari SBAS.
[C-SR-4] SANGAT DIREKOMENDASIKAN untuk melaporkan AGC, dan Frekuensi GNSS pengukuran.
[C-SR-5] SANGAT DIREKOMENDASIKAN untuk melaporkan semua perkiraan akurasi (termasuk Bearing, Kecepatan, dan Vertikal) sebagai bagian dari setiap lokasi GPS/GNSS.
[C-SR-6] SANGAT DIREKOMENDASIKAN untuk melaporkan pengukuran GNSS, segera setelah mereka ditemukan, meskipun lokasi yang dihitung dari GPS/GNSS belum dilaporkan.
[C-SR-7] SANGAT DIREKOMENDASIKAN untuk melaporkan pseudorange GNSS dan tingkat pseudorange, yang, dalam kondisi langit terbuka setelah menentukan lokasi, ketika diam atau bergerak dengan kecepatan kurang dari 0,2 meter per detik kuadrat dari untuk menghitung posisi dalam jarak 20 meter, dan kecepatan dalam 0,2 meter per detik, setidaknya 95% dari waktu.
7.3.4. Giroskop
Implementasi perangkat:
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menyertakan sensor giroskop.
Jika implementasi perangkat menyertakan giroskop, implementasi tersebut:
- [C-1-1] HARUS dapat melaporkan peristiwa hingga frekuensi setidaknya 50 Hz.
- [C-1-4] HARUS memiliki resolusi 12-bit atau lebih.
- [C-1-5] HARUS diberi kompensasi suhu.
- [C-1-6] HARUS dikalibrasi dan dikompensasi saat digunakan, dan menjaga parameter kompensasi antar-reboot perangkat.
- [C-1-7] HARUS memiliki varians tidak lebih besar dari 1e-7 rad^2 / s^2 per Hz (varian per Hz, atau rad^2 / s). Varian diperbolehkan untuk frekuensi sampling, tetapi HARUS dibatasi oleh nilai ini. Dengan kata lain, jika Anda mengukur varians giroskop pada frekuensi sampling 1 Hz SEHARUSNYA tidak lebih dari 1e-7 rad^2/s^2.
- [C-SR-2] Error kalibrasi SANGAT DIREKOMENDASIKAN agar kurang dari 0,01 rad/dtk saat perangkat diam pada suhu kamar.
- [C-SR-3] SANGAT DIREKOMENDASIKAN untuk memiliki resolusi 16-bit atau lebih.
- HARUS melaporkan peristiwa hingga minimal 200 Hz.
Jika implementasi perangkat menyertakan giroskop 3 sumbu, implementasi tersebut:
- [C-2-1] HARUS mengimplementasikan sensor
TYPE_GYROSCOPE
. - [C-SR-4] Sangat Direkomendasikan untuk mengimplementasikan
TYPE_GYROSCOPE_UNCALIBRATED
sensor.
Jika implementasi perangkat menyertakan giroskop dengan kurang dari 3 sumbu, implementasi tersebut:
- [C-3-1] HARUS menerapkan dan melaporkan sensor
TYPE_GYROSCOPE_LIMITED_AXES
. - [C-SR-5] STRONGLY_RECOMMENDED untuk mengimplementasikan dan melaporkan
Sensor
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
.
Jika implementasi perangkat menyertakan giroskop 3-sumbu, sensor akselerometer dan sensor magnetometer, keduanya:
- [C-4-1] HARUS mengimplementasikan sensor komposit
TYPE_ROTATION_VECTOR
.
Jika implementasi perangkat menyertakan akselerometer 3 sumbu dan giroskop 3 sumbu sensor, fungsi tersebut:
- [C-5-1] HARUS mengimplementasikan
TYPE_GRAVITY
danTYPE_LINEAR_ACCELERATION
sensor komposit. - [C-SR-6] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan
TYPE_GAME_ROTATION_VECTOR
sensor komposit.
7.3.5. Barometer
Implementasi perangkat:
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menyertakan barometer (tekanan udara sekitar sensor).
Jika implementasi perangkat menyertakan barometer, implementasi tersebut:
- [C-1-1] HARUS menerapkan dan melaporkan sensor
TYPE_PRESSURE
. - [C-1-2] HARUS dapat mengirimkan event pada 5 Hz atau lebih.
- [C-1-3] HARUS diberi kompensasi suhu.
- [C-SR-2] SANGAT DIREKOMENDASIKAN untuk dapat melaporkan pengukuran tekanan di berkisar 300 hPa hingga 1100 hPa.
- HARUS memiliki akurasi 1hPa.
- HARUS memiliki akurasi relatif 0,12 hPa di atas rentang 20 hPa (setara dengan ~ 1 m akurasi lebih dari ~ 200 m perubahan di permukaan laut).
7.3.6. Thermometer
Jika implementasi perangkat menyertakan termometer sekitar (sensor suhu), mereka:
- [C-1-1] HARUS menentukan
SENSOR_TYPE_AMBIENT_TEMPERATURE
untuk sensor suhu sekitar dan sensor HARUS mengukur keadaan sekitar suhu (kamar/kabin kendaraan) dari tempat pengguna berinteraksi dengan perangkat dalam derajat Celsius.
Jika implementasi perangkat menyertakan sensor termometer yang mengukur selain suhu sekitar, misalnya suhu CPU, komponen-komponen ini akan:
- [C-2-1] TIDAK BOLEH menentukan
SENSOR_TYPE_AMBIENT_TEMPERATURE
untuk sensor suhu.
Jika implementasi perangkat menyertakan sensor untuk memantau suhu kulit, maka mereka:
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung PowerManager.getThermalHeadroom Compute Engine API.
7.3.7. Fotometer
- Implementasi perangkat MUNGKIN menyertakan fotometer (sensor cahaya sekitar).
7.3.8. Sensor Kedekatan
- Implementasi perangkat MUNGKIN mencakup sensor kedekatan.
Jika implementasi perangkat menyertakan sensor kedekatan dan aplikasi tersebut hanya melaporkan biner "dekat" atau "jauh" membacanya, mereka:
- [C-1-1] HARUS mengukur kedekatan suatu objek dalam arah yang sama dengan layar. Artinya, sensor kedekatan HARUS diorientasikan untuk mendeteksi objek dekat dengan layar, karena tujuan utama jenis sensor ini adalah untuk mendeteksi ponsel yang sedang digunakan oleh pengguna. Jika implementasi perangkat mencakup sensor kedekatan dengan orientasi lain, TIDAK BOLEH dapat diakses melalui API ini.
- [C-1-2] HARUS memiliki akurasi 1-bit atau lebih.
- [C-1-3] HARUS menggunakan 0 cm sebagai titik baca dekat dan 5 cm sebagai membaca jauh.
- [C-1-4] HARUS melaporkan rentang dan resolusi maksimum 5.
7.3.9. Sensor Fidelitas Tinggi
Jika implementasi perangkat menyertakan serangkaian sensor berkualitas lebih tinggi seperti yang ditentukan di bagian ini, dan menyediakannya untuk aplikasi pihak ketiga, mereka akan:
- [C-1-1] HARUS mengidentifikasi kemampuan melalui
Tombol fitur
android.hardware.sensor.hifi_sensors
.
Jika implementasi perangkat mendeklarasikan android.hardware.sensor.hifi_sensors
,
mereka:
[C-2-1] HARUS memiliki sensor
TYPE_ACCELEROMETER
yang:- HARUS memiliki rentang pengukuran antara minimal -8g dan +8g, dan SANGAT DIREKOMENDASIKAN untuk memiliki rentang pengukuran minimal antara -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; SEHARUSNYA
mendukung SensorDirectChannel
RATE_VERY_FAST
. - HARUS memiliki derau pengukuran yang tidak di atas 400 μg/✓Hz.
- HARUS mengimplementasikan bentuk non-bangun dari sensor ini dengan buffering minimal 3000 kejadian sensor.
- HARUS memiliki konsumsi daya pengelompokan tidak lebih buruk dari 3 mW.
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk memiliki bandwidth pengukuran 3 dB sebesar setidaknya 80% dari frekuensi Nyquist, dan spektrum {i>white noise<i} {i>bandwidth<i}.
- HARUS memiliki akselerasi acak berjalan kurang dari 30 μg ✓Hz yang diuji pada suhu ruangan.
- HARUS memiliki perubahan bias vs. suhu ≤ +/- 1 mg/°C.
- HARUS memiliki garis non-linearitas terbaik ≤ 0,5%, dan perubahan sensitivitas vs. suhu ≤ 0,03%/C°.
- HARUS memiliki sensitivitas lintas sumbu < 2,5 % dan variasi sensitivitas lintas sumbu < 0,2% dalam rentang suhu pengoperasian perangkat.
[C-2-2] HARUS memiliki
TYPE_ACCELEROMETER_UNCALIBRATED
dengan atribut persyaratan kualitas sebagaiTYPE_ACCELEROMETER
.[C-2-3] HARUS memiliki sensor
TYPE_GYROSCOPE
yang:- HARUS memiliki rentang pengukuran antara minimal -1.000 dan +1.000 dp.
- HARUS memiliki resolusi pengukuran minimal 16 LSB/dp.
- HARUS memiliki frekuensi pengukuran minimum 12,5 Hz atau lebih rendah.
- HARUS memiliki frekuensi pengukuran maksimum 400 Hz atau lebih tinggi; SEHARUSNYA
mendukung SensorDirectChannel
RATE_VERY_FAST
. - HARUS memiliki derau pengukuran yang tidak di atas 0,014 °/s/{4}Hz.
- [C-SR-2] SANGAT DIREKOMENDASIKAN untuk memiliki bandwidth pengukuran 3 dB sebesar setidaknya 80% dari frekuensi Nyquist, dan spektrum {i>white noise<i} {i>bandwidth<i}.
- HARUS memiliki kecepatan berjalan acak kurang dari 0,001 °/dtk }Hz yang diuji di kamar temperatur harian.
- HARUS memiliki perubahan bias vs. suhu ≤ +/- 0,05 °/ s / °C.
- HARUS memiliki perubahan sensitivitas vs. suhu ≤ 0,02% / °C.
- HARUS memiliki garis non-linearitas terbaik ≤ 0,2%.
- SEHARUSNYA memiliki kepadatan kebisingan ≤ 0,007 °/s/✓Hz.
- HARUS memiliki kesalahan kalibrasi kurang dari 0,002 rad/s di rentang suhu 10 ~ 40 °C saat perangkat diam.
- HARUS memiliki sensitivitas g kurang dari 0,1 °/dtk/g.
- HARUS memiliki sensitivitas lintas sumbu < 4,0 % dan sensitivitas sumbu silang variasi < 0,3% dalam rentang suhu pengoperasian perangkat.
[C-2-4] HARUS memiliki
TYPE_GYROSCOPE_UNCALIBRATED
dengan kualitas yang sama persyaratannya sebagaiTYPE_GYROSCOPE
.[C-2-5] HARUS memiliki sensor
TYPE_GEOMAGNETIC_FIELD
yang:- HARUS memiliki rentang pengukuran antara minimal -900 dan +900 μT.
- HARUS memiliki resolusi pengukuran minimal 5 LSB/uT.
- HARUS memiliki frekuensi pengukuran minimum 5 Hz atau lebih rendah.
- HARUS memiliki frekuensi pengukuran maksimum 50 Hz atau lebih tinggi.
- HARUS memiliki derau pengukuran yang tidak di atas 0,5 uT.
[C-2-6] HARUS memiliki
TYPE_MAGNETIC_FIELD_UNCALIBRATED
dengan kualitas yang sama persyaratan layanan sepertiTYPE_GEOMAGNETIC_FIELD
dan sebagai tambahan:- HARUS mengimplementasikan bentuk non-bangun dari sensor ini dengan buffering minimal 600 kejadian sensor.
- [C-SR-3] SANGAT DIREKOMENDASIKAN untuk memiliki spektrum white noise dari 1 Hz hingga setidaknya 10 Hz saat rasio laporan 50 Hz atau lebih tinggi.
[C-2-7] HARUS memiliki sensor
TYPE_PRESSURE
yang:- HARUS memiliki rentang pengukuran minimal antara 300 dan 1100 hPa.
- HARUS memiliki resolusi pengukuran minimal 80 LSB/hPa.
- HARUS memiliki frekuensi pengukuran minimum 1 Hz atau lebih rendah.
- HARUS memiliki frekuensi pengukuran maksimum 10 Hz atau lebih tinggi.
- HARUS memiliki derau pengukuran yang tidak lebih dari 2 Pa/✓Hz.
- HARUS mengimplementasikan bentuk non-bangun dari sensor ini dengan buffering minimal 300 kejadian sensor.
- HARUS memiliki konsumsi daya pengelompokan tidak lebih buruk dari 2 mW.
[C-2-8] HARUS memiliki sensor
TYPE_GAME_ROTATION_VECTOR
.[C-2-9] HARUS memiliki sensor
TYPE_SIGNIFICANT_MOTION
yang:- HARUS memiliki konsumsi daya tidak lebih buruk dari 0,5 mW saat perangkat statis dan 1,5 mW saat perangkat bergerak.
[C-2-10] HARUS memiliki sensor
TYPE_STEP_DETECTOR
yang:- HARUS mengimplementasikan bentuk non-bangun dari sensor ini dengan buffering minimal 100 kejadian sensor.
- HARUS memiliki konsumsi daya tidak lebih buruk dari 0,5 mW saat perangkat statis dan 1,5 mW saat perangkat bergerak.
- HARUS memiliki konsumsi daya pengelompokan tidak lebih buruk dari 4 mW.
[C-2-11] HARUS memiliki sensor
TYPE_STEP_COUNTER
yang:- HARUS memiliki konsumsi daya tidak lebih buruk dari 0,5 mW saat perangkat statis dan 1,5 mW saat perangkat bergerak.
[C-2-12] HARUS memiliki sensor
TILT_DETECTOR
yang:- HARUS memiliki konsumsi daya tidak lebih buruk dari 0,5 mW saat perangkat statis dan 1,5 mW saat perangkat bergerak.
[C-2-13] Stempel waktu peristiwa dari peristiwa fisik yang sama yang dilaporkan oleh Akselerometer, Giroskop, dan Magnetometer HARUS dalam waktu 2,5 milidetik satu sama lain. Stempel waktu peristiwa dari peristiwa fisik yang sama yang dilaporkan oleh Akselerometer dan Giroskop SEHARUSNYA berada dalam waktu 0,25 milidetik dari masing-masing lainnya.
[C-2-14] HARUS memiliki stempel waktu peristiwa sensor Giroskop pada waktu yang sama sebagai subsistem kamera dan dalam waktu 1 milidetik error.
[C-2-15] HARUS mengirimkan sampel ke aplikasi dalam waktu 5 milidetik dari waktu ketika data tersedia pada salah satu sensor fisik di atas kepada aplikasi.
[C-2-16] TIDAK BOLEH memiliki konsumsi daya yang lebih tinggi dari 0,5 mW saat perangkat statis dan 2,0 mW saat perangkat bergerak saat kombinasi apa pun dari sensor berikut diaktifkan:
SENSOR_TYPE_SIGNIFICANT_MOTION
SENSOR_TYPE_STEP_DETECTOR
SENSOR_TYPE_STEP_COUNTER
SENSOR_TILT_DETECTORS
[C-2-17] MUNGKIN memiliki sensor
TYPE_PROXIMITY
, tetapi jika ada, HARUS memiliki kemampuan buffer minimum 100 peristiwa sensor.
Perhatikan bahwa semua persyaratan konsumsi daya di bagian ini tidak mencakup konsumsi daya Prosesor Aplikasi. Hal ini mencakup kemampuan yang digambar oleh seluruh rantai sensor—sensor, sirkuit pendukung, sistem pemrosesan sensor khusus, dll.
Jika implementasi perangkat menyertakan dukungan sensor langsung, implementasi tersebut:
- [C-3-1] HARUS mendeklarasikan dengan benar dukungan jenis saluran langsung dan
tingkat rasio laporan melalui
isDirectChannelTypeSupported
dangetHighestDirectReportRateLevel
Compute Engine API. - [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 (varian non-bangun) dari jenis berikut:
TYPE_ACCELEROMETER
TYPE_ACCELEROMETER_UNCALIBRATED
TYPE_GYROSCOPE
TYPE_GYROSCOPE_UNCALIBRATED
TYPE_MAGNETIC_FIELD
TYPE_MAGNETIC_FIELD_UNCALIBRATED
7.3.10. Sensor Biometrik
Untuk latar belakang tambahan tentang Mengukur Keamanan Buka Kunci Biometrik, harap lihat Dokumentasi Mengukur Keamanan Biometrik.
Jika implementasi perangkat menyertakan layar kunci yang aman, implementasi tersebut:
- HARUS menyertakan sensor biometrik
Sensor biometrik dapat diklasifikasikan sebagai Class 3 (sebelumnya Strong), Kelas 2 (sebelumnya Lemah), atau Kelas 1 (sebelumnya Kepraktisan) berdasarkan tingkat penerimaan spoof dan penipu mereka, serta keamanan pipeline biometrik. Klasifikasi ini menentukan kemampuan sensor biometrik harus berinteraksi dengan platform dan dengan pihak ketiga menggunakan berbagai aplikasi obrolan. Sensor harus memenuhi persyaratan tambahan seperti yang dijelaskan di bawah jika ingin diklasifikasikan sebagai Kelas 1, Kelas 2, atau Kelas 3. Biometrik Kelas 2 dan Kelas 3 mendapatkan kemampuan tambahan sebagai dijelaskan di bawah ini.
Jika implementasi perangkat menyediakan sensor biometrik untuk pihak ketiga aplikasi melalui android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt, dan android.provider.Settings.ACTION_BIOMETRIC_ENROLL, mereka:
- [C-4-1] HARUS memenuhi persyaratan biometrik untuk Kelas 3 atau Kelas 2 seperti yang dijelaskan dalam dokumen ini.
- [C-4-2] HARUS mengenali dan mematuhi setiap nama parameter yang didefinisikan sebagai konstanta di Authenticator dan semua kombinasinya. Sebaliknya, TIDAK BOLEH menghormati atau mengenali konstanta bilangan bulat yang diteruskan ke canAuthenticate(int) dan setAllowedAuthenticators(int) metode selain yang didokumentasikan sebagai konstanta publik dalam Pengautentikasi beserta kombinasinya.
- [C-4-3] HARUS menerapkan ACTION_BIOMETRIC_ENROLL tindakan di perangkat yang memiliki biometrik Kelas 3 atau Kelas 2. Tindakan ini HARUS menunjukkan titik entri pendaftaran untuk Kelas 3 saja atau biometrik Kelas 2.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [C-4-4] HARUS mengizinkan aplikasi menambahkan konten kustom ke
BiometricPrompt
menggunakan format tampilan kontenPromptContentView
. Tampilan konten TIDAK BOLEH diperluas agar gambar, tautan, konten interaktif, atau bentuk media lain yang belum menjadi bagian dariBiometricPrompt
Compute Engine API. Penyesuaian gaya yang tidak mengubah, mengaburkan, atau memotongnya konten dapat dibuat (seperti mengubah posisi, padding, margin, dan tipografi).
Mengakhiri persyaratan baru
Jika implementasi perangkat mendukung biometrik pasif, implementasi tersebut:
- [C-5-1] Secara default HARUS memerlukan langkah konfirmasi tambahan (misalnya, penekanan tombol).
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk memiliki setelan yang memungkinkan pengguna mengganti preferensi aplikasi dan selalu memerlukan konfirmasi.
- [C-SR-2] SANGAT DIREKOMENDASIKAN untuk mendapatkan tindakan konfirmasi yang aman sehingga sistem operasi atau {i>kernel<i} tidak dapat melakukan spoofing. Misalnya, ini berarti tindakan konfirmasi berdasarkan tombol fisik disalurkan melalui pin input/output umum tujuan umum (GPIO) khusus input {i>secure element<i} (SE) yang tidak dapat digerakkan dengan cara lain selain penekanan tombol fisik.
- [C-5-2] Selain itu HARUS mengimplementasikan alur autentikasi implisit (tanpa langkah konfirmasi) yang sesuai dengan setConfirmationRequired(boolean), aplikasi mana yang dapat digunakan untuk alur login.
Jika implementasi perangkat memiliki beberapa sensor biometrik, implementasi tersebut:
[C-7-1] HARUS, saat biometrik sedang terkunci (yaitu, biometrik dinonaktifkan hingga pengguna membuka kuncinya dengan autentikasi utama) atau penguncian terikat waktu (yaitu, biometrik dinonaktifkan untuk sementara hingga pengguna menunggu beberapa saat interval) karena terlalu banyak upaya yang gagal, juga kunci semua upaya lainnya biometrik dengan kelas biometrik yang lebih rendah. Dalam kasus {i> lockout<i} yang terikat waktu, waktu backoff untuk verifikasi biometrik HARUS berupa waktu backoff maksimum dari semua biometrik dalam penguncian terikat waktu (time-bound).
[C-SR-12] SANGAT DIREKOMENDASIKAN, saat biometrik terkunci (yaitu biometrik dinonaktifkan hingga pengguna membuka kuncinya dengan autentikasi utama) atau {i>time-bound lockout<i} (yaitu biometrik dinonaktifkan sementara hingga pengguna menunggu interval waktu) karena terlalu banyak upaya yang gagal, untuk juga mengunci semua biometrik lain dari kelas biometrik yang sama. Dalam kasus penguncian berbatas waktu, waktu backoff untuk verifikasi biometrik SANGAT DIREKOMENDASIKAN sebagai waktu backoff maksimum dari semua biometrik dalam batas waktu terkunci secara otomatis.
[C-7-2] HARUS menantang pengguna untuk autentikasi primer yang direkomendasikan (misalnya: PIN, pola, sandi) untuk mereset penghitung penguncian biometrik karena terkunci dari luar. Biometrik Kelas 3 DAPAT diizinkan untuk mereset penguncian untuk biometrik terkunci dari kelas yang sama atau lebih rendah. Kelas 2 atau Biometrik Kelas 1 TIDAK BOLEH diizinkan untuk menyelesaikan penguncian reset operasi untuk biometrik apa pun.
[C-SR-3] SANGAT DIREKOMENDASIKAN untuk hanya memerlukan konfirmasi biometrik per autentikasi (mis. jika sensor sidik jari dan wajah tersedia di perangkat, onAuthenticationSucceeded harus dikirim setelah salah satunya dikonfirmasi).
Agar implementasi perangkat memungkinkan akses ke kunci keystore untuk aplikasi pihak ketiga, mereka:
- [C-6-1] HARUS memenuhi persyaratan untuk Kelas 3 seperti yang didefinisikan dalam di bawah ini.
- [C-6-2] HARUS menampilkan biometrik Kelas 3 saja saat autentikasi memerlukan BIOMETRIC_STRONG, atau autentikasi dipanggil dengan CryptoObject.
Jika implementasi perangkat ingin memperlakukan sensor biometrik sebagai Kelas 1. (sebelumnya Kepraktisan), mereka:
- [C-1-1] HARUS memiliki tingkat penerimaan palsu kurang dari 0,002%.
- [C-1-2] HARUS mengungkapkan bahwa mode ini mungkin kurang aman dibandingkan PIN yang kuat, pola, atau {i>password<i} dan secara jelas menghitung risiko pengaktifannya, jika tingkat penerimaan palsu dan penipu lebih tinggi dari 7% yang diukur oleh Protokol Pengujian Biometrik Android.
- [C-1-9] HARUS menantang pengguna untuk autentikasi primer yang direkomendasikan (mis., PIN, pola, sandi) setelah tidak lebih dari dua puluh uji coba palsu dan tidak waktu backoff kurang dari sembilan puluh detik untuk verifikasi biometrik - di mana dengan kualitas tangkapan yang memadai (BIOMETRIC_ACQUIRED_GOOD) yang tidak cocok dengan biometrik yang terdaftar.
- [C-SR-4] SANGAT DIREKOMENDASIKAN untuk menurunkan jumlah total uji coba palsu untuk verifikasi biometrik yang disebutkan dalam [C-1-9] jika spoofing dan penipu tingkat penerimaan lebih tinggi dari 7% sebagai ukuran oleh Biometrik Android Protokol Pengujian.
- [C-1-3] Percobaan pembatasan kapasitas untuk verifikasi biometrik - jika
dengan kualitas tangkapan yang memadai
(
BIOMETRIC_ACQUIRED_GOOD
) yang tidak sesuai dengan biometrik yang terdaftar. - [C-SR-5] SANGAT DIREKOMENDASIKAN untuk upaya pembatasan kapasitas setidaknya selama 30 detik setelah lima uji coba palsu untuk verifikasi biometrik untuk jumlah maksimum uji coba palsu per [C-1-9] - di mana uji coba palsu adalah satu dengan kualitas tangkapan yang memadai (BIOMETRIC_ACQUIRED_GOOD) yang tidak cocok dengan biometrik yang terdaftar.
- [C-SR-6] SANGAT DIREKOMENDASIKAN untuk memiliki semua logika pembatasan kapasitas di TEE.
- [C-1-10] HARUS menonaktifkan biometrik setelah backoff otentikasi primer pertama kali dipicu sebagaimana dijelaskan dalam [C-0-2] pasal 9.11.
- [C-1-11] HARUS memiliki tingkat penerimaan spoof dan penipu tidak lebih tinggi dari 30%, dengan (1) tingkat penerimaan spoof dan penipu untuk presentasi Tingkat A spesies serangan instrumen (PAI) tidak lebih tinggi dari 30%, dan (2) spoof dan tingkat penerimaan penipu dari spesies PAI Level B tidak lebih tinggi dari 40%, karena diukur oleh Android Biometrics Test Protocol.
- [C-1-4] HARUS mencegah penambahan biometrik baru tanpa terlebih dahulu menetapkan rantai kepercayaan dengan meminta pengguna mengonfirmasi sudah ada atau menambahkan perangkat baru kredensial (PIN/pola/{i>password<i}) yang dilindungi oleh TEE; pelatihan Android Open Implementasi Proyek Sumber menyediakan mekanisme dalam kerangka kerja untuk melakukan begitu.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [C-1-5] HARUS menghapus sepenuhnya semua data biometrik yang dapat diidentifikasi untuk pengguna saat akun pengguna dihapus (termasuk melalui reset ke setelan pabrik) atau saat autentikasi utama yang direkomendasikan (misalnya, PIN, pola, sandi) dihapus.
Mengakhiri persyaratan baru
- [C-1-6] HARUS menghormati masing-masing bendera untuk biometrik tersebut (yaitu
DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT
,DevicePolicymanager.KEYGUARD_DISABLE_FACE
, atauDevicePolicymanager.KEYGUARD_DISABLE_IRIS
).
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [C-1-7] HARUS menantang pengguna untuk autentikasi primer yang direkomendasikan
(seperti PIN, pola, sandi) sekali setiap 24 jam atau kurang.
Catatan: Upgrade perangkat yang diluncurkan di Android versi 9 atau yang lebih lama HARUS menantang pengguna untuk otentikasi utama yang disarankan (seperti PIN, pola, sandi) sekali setiap 72 jam atau kurang.
Mengakhiri persyaratan baru
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [C-1-8] HARUS menantang pengguna untuk atribut primer yang direkomendasikan
autentikasi (seperti PIN, pola, sandi) atau biometrik Kelas 3 (KUAT)
setelah salah satu hal berikut:
- periode waktu tunggu tidak ada aktivitas 4 jam, ATAU
- 3 upaya autentikasi biometrik gagal.
- Periode waktu tunggu tidak ada aktivitas dan jumlah autentikasi yang gagal direset
setelah konfirmasi
kredensial perangkat yang berhasil.
Catatan: Mengupgrade perangkat yang diluncurkan di Android versi 9 atau sebelumnya MUNGKIN dikecualikan dari C-1-8.
Mengakhiri persyaratan baru
- [C-SR-7] SANGAT DIREKOMENDASIKAN untuk menggunakan logika dalam kerangka kerja yang disediakan oleh Proyek Open Source Android untuk memberlakukan batasan yang [C-1-7] dan [C-1-8] untuk perangkat baru.
- [C-SR-8] SANGAT DIREKOMENDASIKAN untuk memiliki rasio penolakan yang salah kurang dari 10%, yang diukur di perangkat.
- [C-SR-9] SANGAT DIREKOMENDASIKAN untuk memiliki latensi di bawah 1 detik, yang diukur mulai dari saat biometrik terdeteksi, hingga layar dibuka kuncinya, untuk setiap biometrik yang terdaftar.
- [C-1-12] HARUS memiliki tingkat penerimaan spoof dan penipu tidak lebih tinggi dari 40% spesies serangan perangkat presentasi (PAI), yang diukur dengan Protokol Pengujian Biometrik Android.
- [C-SR-13] SANGAT DIREKOMENDASIKAN untuk memiliki spoof dan tingkat penerimaan penipu tidak lebih dari 30% spesies serangan perangkat presentasi (PAI), yang diukur dengan Protokol Pengujian Biometrik Android.
- [C-SR-8] SANGAT DIREKOMENDASIKAN untuk memiliki rasio penolakan yang salah kurang dari 10%, yang diukur di perangkat.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [C-1-15] HARUS mengizinkan pengguna untuk menghapus satu atau beberapa biometrik pendaftaran.
Mengakhiri persyaratan baru
[C-SR-14] SANGAT DIREKOMENDASIKAN untuk mengungkapkan kelas biometrik dari sensor biometrik dan risiko pengaktifannya.
[C-SR-17] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan antarmuka AIDL baru (seperti,
IFace.aidl
danIFingerprint.aidl
).
Jika implementasi perangkat ingin memperlakukan sensor biometrik sebagai Kelas 2. (sebelumnya Lemah), fitur 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 instrumen serangan presentasi Level A (PAI) tidak lebih tinggi dari 20%, dan (2) tingkat penerimaan spoofing dan penipu dari spesies PAI Level B yang lebih dari 30%, yang diukur dengan Protokol Pengujian Biometrik Android.
- [C-SR-15] SANGAT DIREKOMENDASIKAN untuk memiliki spoofing dan penipu tingkat penerimaan tidak lebih dari 20% spesies serangan perangkat presentasi (PAI), yang diukur dengan Protokol Pengujian Biometrik Android.
- [C-2-3] HARUS melakukan pencocokan biometrik di lingkungan eksekusi yang terisolasi di luar Android ruang pengguna atau {i>kernel<i}, seperti {i>Trusted Execution Environment<i} (TEE), pada {i>chip<i} dengan saluran aman ke lingkungan eksekusi yang terisolasi atau di Protected Virtual Machine yang memenuhi persyaratan dalam Pasal 9.17.
- [C-2-4] HARUS memiliki semua data identitas yang dienkripsi dan secara kriptografis diotentikasi sehingga tidak dapat diperoleh, dibaca, atau diubah di luar lingkungan eksekusi yang terisolasi, atau sebuah {i> chip<i} dengan saluran yang aman ke lingkungan eksekusi yang terisolasi seperti yang didokumentasikan dalam implementasi panduan di situs Project Open Source Android atau Protected Virtual Machine dikontrol oleh hypervisor yang memenuhi persyaratan dalam Pasal 9.17.
- [C-2-5] Untuk biometrik berbasis kamera, sedangkan autentikasi berbasis biometrik
atau pendaftaran sedang berlangsung:
- HARUS mengoperasikan kamera dalam mode yang mencegah frame kamera dibaca atau diubah di luar lingkungan eksekusi yang terisolasi atau {i>chip<i} dengan saluran aman ke lingkungan eksekusi yang terisolasi atau Virtual Machine yang dikontrol oleh hypervisor yang memenuhi persyaratan di Bagian 9.17.
- Untuk solusi kamera tunggal RGB, bingkai kamera DAPAT dapat dibaca di luar lingkungan eksekusi yang terisolasi untuk mendukung operasi seperti pratinjau untuk pendaftaran, tetapi TIDAK BOLEH diubah.
- [C-2-6] TIDAK BOLEH mengaktifkan aplikasi pihak ketiga untuk membedakan antara pendaftaran biometrik individual.
- [C-2-7] TIDAK BOLEH mengizinkan akses yang tidak terenkripsi ke data biometrik yang dapat diidentifikasi atau data apa pun yang berasal darinya (seperti embedding) ke Prosesor Aplikasi di luar konteks TEE atau Protected Virtual Machine yang dikontrol oleh hypervisor yang memenuhi persyaratan dalam Pasal 9.17. Upgrade perangkat 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 jaringan penyusupan sistem atau {i>kernel<i} tidak memungkinkan data untuk dimasukkan secara langsung ke melakukan otentikasi secara tidak benar sebagai pengguna. Catatan: Jika implementasi perangkat sudah diluncurkan di Android versi 9 atau sebelumnya dan tidak dapat memenuhi persyaratan C-2-8 melalui sistem memperbarui, mereka DAPAT dikecualikan dari persyaratan tersebut.
[C-SR-10] SANGAT DIREKOMENDASIKAN untuk menyertakan deteksi keaktifan bagi semua modalitas biometrik dan deteksi perhatian untuk biometrik Wajah.
[C-2-9] HARUS menyediakan sensor biometrik untuk pihak ketiga menggunakan berbagai aplikasi obrolan.
Jika implementasi perangkat ingin memperlakukan sensor biometrik sebagai Kelas 3 (sebelumnya Strong), mereka:
- [C-3-1] HARUS memenuhi semua persyaratan Kelas 2 di atas, kecuali untuk [C-1-7] dan [C-1-8].
- [C-3-2] HARUS memiliki implementasi keystore yang didukung hardware.
- [C-3-3] HARUS memiliki tingkat penerimaan spoof dan penipu tidak lebih tinggi dari 7%, dengan (1) tingkat penerimaan spoof dan penipu untuk Spesies serangan presentasi level A (PAI) tidak lebih tinggi dari 7%, dan (2) tingkat penerimaan spoofing dan penipu spesies PAI Level B tidak lebih tinggi dari 20%, yang diukur dengan Protokol Pengujian Biometrik Android.
- [C-3-4] HARUS menantang pengguna untuk perintah primer yang direkomendasikan autentikasi (seperti PIN, pola, sandi) setiap 72 jam sekali atau kurang.
- [C-3-5] ID Authenticator HARUS membuat ulang untuk semua biometrik Kelas 3 yang didukung di perangkat jika ada didaftarkan ulang.
- [C-3-6] Harus mengaktifkan kunci keystore yang didukung biometrik untuk pihak ketiga menggunakan berbagai aplikasi obrolan.
[C-SR-16] SANGAT DIREKOMENDASIKAN untuk memiliki spoofing dan penipu tingkat penerimaan tidak lebih dari 7% per spesies eksistensi serangan presentasi (PAI), yang diukur dengan Protokol Pengujian Biometrik Android. Jika penerapan perangkat berisi sensor sidik jari di bawah layar (UDFPS), mereka:
[C-SR-11] SANGAT DIREKOMENDASIKAN untuk mencegah area yang dapat disentuh pada UDFPS dari mengganggu navigasi 3 tombol( yang mungkin dibutuhkan beberapa pengguna aksesibilitas).
7.3.11. Sensor Pose
Implementasi perangkat:
- MUNGKIN mendukung sensor pose dengan 6 derajat kebebasan.
Jika implementasi perangkat mendukung sensor pose dengan 6 derajat kebebasan, implementasi tersebut:
- [C-1-1] HARUS menerapkan dan melaporkan
TYPE_POSE_6DOF
sensor. - [C-1-2] HARUS lebih akurat daripada vektor rotasi saja.
7.3.12. Sensor Sudut Engsel
Jika implementasi perangkat mendukung sensor sudut engsel, implementasi tersebut:
- [C-1-1] HARUS menerapkan dan melaporkan
TYPE_HINGLE_ANGLE
. - [C-1-2] HARUS mendukung setidaknya dua pembacaan antara 0 dan 360 derajat (termasuk, termasuk 0 dan 360 derajat).
- [C-1-3] HARUS mengembalikan bangun
sensor 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 fungsionalitas dengan aplikasi pihak ketiga, mereka:
- [C-1-2] HARUS melaporkan tombol fitur hardware
android.hardware.uwb
. - [C-1-3] HARUS mendukung semua set konfigurasi berikut (yang telah ditentukan
kombinasi parameter FIRA UCI)
yang didefinisikan dalam implementasi AOSP.
CONFIG_ID_1
: RentangSTATIC STS DS-TWR
unicast yang ditentukan FiRa, mode ditangguhkan, rentang interval 240 md.CONFIG_ID_2
: RentangSTATIC STS DS-TWR
one-to-many yang ditentukan FiRa, mode ditangguhkan, dengan interval rentang 200 md. Kasus penggunaan umum: smartphone berinteraksi dengan banyak perangkat pintar.CONFIG_ID_3
: Sama sepertiCONFIG_ID_1
, kecuali Sudut kedatangan (AoA) data tidak dilaporkan.CONFIG_ID_4
: Sama sepertiCONFIG_ID_1
, tetapi mode keamanan P-STS adalah mengaktifkan pembuatan versi.CONFIG_ID_5
: Sama sepertiCONFIG_ID_2
, tetapi mode keamanan P-STS adalah mengaktifkan pembuatan versi.CONFIG_ID_6
: Sama sepertiCONFIG_ID_3
, tetapi mode keamanan P-STS adalah mengaktifkan pembuatan versi.CONFIG_ID_7
: Sama sepertiCONFIG_ID_2
, kecuali kontrol individu P-STS mode tombol diaktifkan.
- [C-1-4] HARUS menyediakan affordance pengguna untuk memungkinkan pengguna mengaktifkan/menonaktifkan UWB status aktif/nonaktif radio.
- [C-1-5] HARUS mewajibkan aplikasi yang menggunakan radio UWB menyimpan
UWB_RANGING
(dalam grup izinNEARBY_DEVICES
).
Lulus uji kesesuaian dan sertifikasi yang relevan yang ditentukan oleh standar organisasi, termasuk FIRA, CCC dan CSA membantu memastikan 802.1.15.4 berfungsi dengan benar.
7.4. Konektivitas Data
7.4.1. Telepon
"Telepon" sebagaimana digunakan oleh Android API dan dokumen ini secara khusus merujuk ke perangkat keras yang terkait dengan melakukan panggilan suara dan mengirim pesan SMS, atau membuat data seluler melalui perangkat seluler (misalnya GSM, CDMA, LTE, NR) GSM atau CDMA jaringan. Perangkat yang mendukung "Telepon" dapat memilih untuk menawarkan beberapa atau semua layanan telepon, pesan, dan data yang sesuai dengan produk tersebut.
- Android MUNGKIN digunakan pada perangkat yang tidak termasuk hardware telepon. Bahwa adalah, Android kompatibel dengan perangkat selain ponsel.
Jika implementasi perangkat mencakup telepon GSM atau CDMA, implementasi tersebut:
- [C-1-1] HARUS mendeklarasikan tombol fitur
android.hardware.telephony
dan penanda sub-fitur lainnya sesuai dengan teknologi. - [C-1-2] HARUS menerapkan dukungan penuh untuk API untuk teknologi tersebut.
- HARAP mengizinkan semua jenis layanan seluler yang tersedia (2G, 3G, 4G, 5G, dll.)
selama panggilan darurat (terlepas dari jenis jaringan yang disetel oleh
SetAllowedNetworkTypeBitmap()
).
Jika implementasi perangkat tidak menyertakan hardware telepon, implementasi tersebut:
- [C-2-1] HARUS mengimplementasikan API lengkap sebagai tanpa pengoperasian.
Jika implementasi perangkat mendukung eUICC atau eSIM/SIM tersemat dan sertakan mekanisme eksklusif untuk menyediakan fungsi eSIM bagi pihak ketiga developer, mereka:
- [C-3-1] HARUS mendeklarasikan
android.hardware.telephony.euicc
tombol fitur.
Jika penerapan perangkat tidak menetapkan properti sistem ro.telephony.iwlan\_operation\_mode
ke 'lama', penerapan tersebut:
- [C-4-1] TIDAK BOLEH melaporkan 'NETWORK_TYPE_IWLAN' melalui NetworkRegistrationInfo#getAccessNetworkTechnology() saat NetworkRegistrationInfo#getTransportType() dilaporkan sebagai 'TRANSPORT_TYPE_WWAN' untuk instance NetworkRegistrationInfo yang sama.
Jika implementasi perangkat mendukung satu IP Multimedia Subsystem (IMS) pendaftaran untuk layanan telepon multimedia (MMTEL) dan fitur Rich Communication Service (RCS) dan diharapkan mematuhi dengan persyaratan operator seluler terkait penggunaan satu Pendaftaran IMS untuk semua lalu lintas sinyal IMS, yaitu:
- [C-5-1] HARUS mendeklarasikan
android.hardware.telephony.ims
tombol fitur dan menyediakan implementasi lengkap dari ImsService API untuk User Capability Exchange API MMTEL dan RCS. - [C-5-2] HARUS mendeklarasikan
android.hardware.telephony.ims.singlereg
tombol fitur dan menyediakan implementasi lengkap SipTransport API, GbaService API, indikasi pembawa khusus yang menggunakan IRadio 1.6 HAL, dan penyediaan melalui Server Konfigurasi Otomatis (ACS) atau 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] Permohonan yang ditetapkan oleh
android.provider.Telephony.Sms#getDefaultSmsPackage
HARUS menggunakan SmsManager API saat mengirim dan menerima pesan SMS dan MMS. Referensi AOSP implementasi dalam paket/aplikasi/Pesan memenuhi persyaratan ini. - [C-6-3] Aplikasi yang merespons
Intent#ACTION_DIAL
HARUS mendukung entri kode telepon arbitrer yang diformat sebagai*#*#CODE#*#*
dan memicu responsTelephonyManager#ACTION_SECRET_CODE
. - [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. - [C-6-5] HARUS mewakili semua SubscriptionInfo dengan yang setara
UUID grup
sebagai satu langganan di semua kemampuan yang terlihat oleh pengguna yang menampilkan dan
mengontrol informasi kartu SIM. Contoh kemampuan tersebut mencakup setelan
antarmuka yang sesuai
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 non-null dan bit oportunistik dalam setiap kemampuan yang terlihat oleh pengguna yang mengizinkan konfigurasi atau kontrol setelan kartu SIM.
Jika implementasi perangkat melaporkan fitur android.hardware.telephony
dan berikan status bar sistem, lalu:
- [C-7-1] HARUS memilih langganan aktif yang representatif untuk UUID grup untuk ditampilkan kepada pengguna dalam kemampuan apa pun yang menyediakan status SIM tidak akurat atau tidak sesuai. Contoh {i>affordances<i} tersebut termasuk {i>status bar<i} seluler ikon sinyal atau kotak setelan cepat.
- [C-SR-1] SANGAT DIREKOMENDASIKAN bahwa langganan representatif terpilih menjadi langganan data aktif kecuali perangkat memberi suara panggilan, dan dalam hal ini SANGAT DIREKOMENDASIKAN bahwa perwakilan adalah langganan {i>active voice<i}.
Jika implementasi perangkat melaporkan fitur android.hardware.telephony
, maka:
- [C-6-7] HARUS mampu membuka dan sekaligus memanfaatkan kapasitas maksimum jumlah saluran logis (total 20) untuk setiap UICC per ETSI TS 102 221.
- [C-6-8] TIDAK BOLEH menerapkan salah satu perilaku berikut untuk aplikasi operator yang aktif
(sebagaimana ditetapkan oleh
TelephonyManager#getCarrierServicePackageName
) secara otomatis atau tanpa konfirmasi eksplisit dari pengguna:- Mencabut atau membatasi akses jaringan
- Mencabut izin
- Membatasi eksekusi aplikasi latar belakang atau latar depan di luar fitur pengelolaan daya yang sudah ada dan disertakan dalam AOSP
- Menonaktifkan atau meng-uninstal aplikasi
Jika implementasi perangkat melaporkan fitur android.hardware.telephony
dan
semua yang aktif,
langganan non-oportunistik
yang berbagi UUID grup dinonaktifkan,
dihapus secara fisik dari perangkat, atau ditandai sebagai oportunistik, lalu perangkat:
- [C-8-1] HARUS otomatis menonaktifkan semua fitur yang masih aktif oportunistik langganan dalam grup yang sama.
Jika implementasi perangkat mencakup telepon GSM, tetapi bukan telepon CDMA, implementasi tersebut:
- [C-9-1] TIDAK BOLEH mendeklarasikan
PackageManager#FEATURE_TELEPHONY_CDMA
. - [C-9-2] HARUS menampilkan
IllegalArgumentException
pada upaya untuk menyetel Jenis jaringan 3GPP2 dalam bitmask jenis jaringan yang disukai atau diizinkan. - [C-9-3] HARUS menampilkan string kosong dari
TelephonyManager#getMeid
Jika implementasi perangkat mendukung eUICC dengan beberapa port dan profil, implementasi tersebut:
- [C-10-1] HARUS mendeklarasikan
android.hardware.telephony.euicc.mep
tombol fitur.
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 mengimplementasikan
BlockedNumberContract
sepenuhnya 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 dihentikan untuk sementara seperti yang dijelaskan dalam SDK dokumentasi tambahan.
[C-1-4] HARUS menulis ke penyedia log panggilan platform untuk panggilan yang diblokir dan HARUS memfilter panggilan dengan
BLOCKED_TYPE
dari tampilan log panggilan default dalam aplikasi telepon yang telah diinstal sebelumnya.[C-1-5] TIDAK BOLEH menulis ke Penyedia telepon untuk pesan yang diblokir.
[C-1-6] HARUS mengimplementasikan UI pengelolaan nomor yang diblokir, yang dibuka dengan intent yang ditampilkan oleh
TelecomManager.createManageBlockedNumbersIntent()
.[C-1-7] TIDAK BOLEH mengizinkan pengguna sekunder melihat atau mengedit nomor yang diblokir pada perangkat karena platform Android mengasumsikan pengguna utama memiliki mengontrol layanan telepon, dalam satu instance, pada perangkat. Semua pemblokiran UI terkait HARUS disembunyikan untuk pengguna sekunder dan daftar yang diblokir HARUS tetap dihormati.
HARUS memigrasikan nomor yang diblokir ke penyedia saat perangkat diperbarui ke Android 7.0.
HARUS menyediakan kemampuan pengguna untuk menampilkan panggilan yang diblokir di perangkat yang sudah diinstal aplikasi pemanggil.
7.4.1.2. API Telekomunikasi
Jika implementasi perangkat melaporkan android.hardware.telephony.calling
, implementasi tersebut:
- [C-1-1] HARUS mendukung
ConnectionService
API yang dijelaskan dalam SDK. - [C-1-2] HARUS menampilkan sebuah panggilan masuk baru dan memberikan keleluasaan kepada pengguna untuk
menerima atau menolak panggilan masuk saat pengguna sedang melakukan panggilan
yang dibuat oleh aplikasi pihak ketiga yang tidak mendukung fitur pembekuan
ditentukan melalui
CAPABILITY_SUPPORT_HOLD
- [C-1-3] HARUS memiliki aplikasi yang mengimplementasikan InCallService yang disediakan.
[C-SR-1] SANGAT DIREKOMENDASIKAN untuk memberi tahu pengguna bahwa menjawab panggilan masuk akan menghentikan panggilan yang sedang berlangsung.
Implementasi AOSP memenuhi persyaratan ini dengan notifikasi pendahuluan yang menunjukkan kepada pengguna bahwa menjawab panggilan masuk akan menyebabkan atau panggilan lainnya.
[C-SR-2] SANGAT DIREKOMENDASIKAN untuk melakukan pramuat aplikasi dialer {i>default<i} yang menampilkan entri log panggilan dan nama aplikasi pihak ketiga dalam log panggilannya saat aplikasi pihak ketiga menyetel
EXTRA_LOG_SELF_MANAGED_CALLS
tombol tambahan padaPhoneAccount
-nya menjaditrue
.[C-SR-3] SANGAT DIREKOMENDASIKAN untuk menangani masalah headset audio Peristiwa
KEYCODE_MEDIA_PLAY_PAUSE
danKEYCODE_HEADSETHOOK
untukandroid.telecom
API seperti di bawah ini:- Panggil
Connection.onDisconnect()
saat penekanan singkat peristiwa tombol terdeteksi selama panggilan yang sedang berlangsung. - Panggil
Connection.onAnswer()
ketika penekanan singkat peristiwa tombol terdeteksi selama panggilan masuk. - Panggil
Connection.onReject()
ketika peristiwa tombol ditekan lama selama panggilan masuk. - Alihkan status nonaktif
CallAudioState
.
- Panggil
7.4.1.3. Offload Keepalive NAT-T Seluler
Implementasi perangkat:
- HARUS menyertakan dukungan untuk Cellular keepalive offload.
Jika implementasi perangkat mencakup dukungan untuk Cellular keepalive offload dan menampilkan fungsi tersebut kepada aplikasi pihak ketiga, mereka:
- [C-1-1] HARUS mendukung SocketKeepAlive API.
- [C-1-2] HARUS mendukung setidaknya satu slot keepalive serentak melalui seluler.
- [C-1-3] HARUS mendukung slot keepalive seluler sebanyak mungkin didukung oleh Cellular Radio HAL.
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung setidaknya tiga keepalive seluler setiap slot per instance radio.
Jika implementasi perangkat tidak menyertakan dukungan untuk seluler keepalive offload, mereka:
- [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 fungsionalitas dengan aplikasi pihak ketiga, mereka:
- [C-1-1] HARUS mengimplementasikan Android API yang sesuai.
- [C-1-2] HARUS melaporkan tombol fitur hardware
android.hardware.wifi
. - [C-1-3] HARUS mengimplementasikan multicast API seperti yang dijelaskan dalam dokumentasi SDK.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
- [C-1-4] HARUS mendukung multicast DNS (mDNS) dan TIDAK BOLEH memfilter paket mDNS (224.0.0.251 atau ff02::fb) kapan saja saat beroperasi, termasuk saat layar tidak dalam keadaan aktif, kecuali bila paket tersebut turun atau menyaring paket ini yang diperlukan agar tetap dalam rentang konsumsi daya yang diwajibkan oleh persyaratan yang berlaku untuk pasar target.
- [C-1-4] HARUS mendukung mDNS dan TIDAK BOLEH memfilter paket mDNS (224.0.0.251 atau ff02::fb) setiap saat operasi, termasuk ketika layar tidak dalam keadaan aktif, kecuali jika kunci multicast tidak ditahan dan paket-paket itu disaring oleh APF. Paket tidak diperlukan untuk memenuhi Operasi mDNS yang saat ini diminta oleh aplikasi melalui NsdManager Google Cloud Platform. Namun, perangkat DAPAT memfilter paket mDNS jika diperlukan agar tetap berada dalam rentang konsumsi daya yang diwajibkan oleh persyaratan peraturan berlaku untuk pasar target.
Mengakhiri persyaratan baru
- [C-1-5] TIDAK BOLEH memperlakukan
WifiManager.enableNetwork()
Panggilan metode API sebagai indikasi yang memadai untuk mengalihkan mode yang sedang aktifNetwork
yang digunakan secara default untuk traffic aplikasi dan ditampilkan olehConnectivityManager
Metode API sepertigetActiveNetwork
danregisterDefaultNetworkCallback
. Dengan kata lain, mereka MUNGKIN hanya menonaktifkan akses Internet yang disediakan oleh penyedia jaringan lain (misalnya data seluler) jika mereka berhasil memvalidasi bahwa jaringan Wi-Fi menyediakan akses Internet. - [C-1-6] SANGAT DIREKOMENDASIKAN untuk, ketika
ConnectivityManager.reportNetworkConnectivity()
Metode API dipanggil, evaluasi ulang akses Internet diNetwork
, dan setelah evaluasi menentukan bahwaNetwork
saat ini tidak lagi memberikan Akses internet, beralihlah ke jaringan lain yang tersedia (misalnya, seluler (data) yang menyediakan akses Internet. - [C-1-7] HARUS mengacak alamat MAC sumber dan nomor urut pemeriksaan frame permintaan, sekali di awal setiap pemindaian, sementara STA terputus.
- [C-1-8] HARUS menggunakan satu alamat MAC yang konsisten (TIDAK BOLEH mengacak MAC alamat setengah dari pemindaian).
- [C-1-9] HARUS mengiterasi nomor urut permintaan pemeriksaan seperti biasa (secara berurutan) di antara permintaan penyelidikan dalam suatu pemindaian.
- [C-1-10] HARUS mengacak nomor urut permintaan Probe antara pemeriksaan terakhir permintaan pemindaian dan permintaan penyelidikan pertama untuk pemindaian berikutnya.
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mengacak alamat MAC sumber yang digunakan untuk
semua komunikasi STA ke Titik Akses (AP) saat mengaitkan dan
yang terkait.
- Perangkat HARUS menggunakan alamat MAC acak yang berbeda untuk setiap SSID (FQDN untuk Passpoint) yang berkomunikasi dengannya.
- Perangkat HARUS memberikan opsi kepada pengguna untuk mengontrol pengacakan per SSID (FQDN untuk Passpoint) dengan metode non-acak dan opsi acak, dan HARUS menetapkan mode {i>default<i} untuk Wi-Fi baru konfigurasinya akan diacak.
- [C-SR-2] SANGAT DIREKOMENDASIKAN untuk menggunakan BSSID acak untuk setiap AP yang mereka
buat.
- Alamat MAC HARUS diacak dan disimpan per SSID yang digunakan oleh AP.
- PERANGKAT DAPAT memberikan opsi kepada pengguna untuk menonaktifkan fitur ini. Jika opsi seperti itu diberikan, pengacakan HARUS diaktifkan secara default.
Jika implementasi perangkat menyertakan dukungan untuk mode hemat daya Wi-Fi seperti yang ditentukan dalam standar IEEE 802.11, mereka:
- HARUS nonaktifkan mode hemat daya Wi-Fi setiap kali aplikasi beralih
Kunci
WIFI_MODE_FULL_HIGH_PERF
atau kunciWIFI_MODE_FULL_LOW_LATENCY
melaluiWifiManager.createWifiLock()
danWifiManager.WifiLock.acquire()
API dan kunci aktif. - [C-3-2] Rata-rata latensi dua arah antara perangkat
dan titik akses saat perangkat berada dalam mode Kunci Latensi Rendah Wi-Fi
(
WIFI_MODE_FULL_LOW_LATENCY
) HARUS lebih kecil dari latensi selama mode Penguncian Performa Tinggi (WIFI_MODE_FULL_HIGH_PERF
) Wi-Fi. - [C-SR-3] SANGAT DIREKOMENDASIKAN untuk meminimalkan latensi dua arah Wi-Fi
setiap kali Kunci Latensi Rendah (
WIFI_MODE_FULL_LOW_LATENCY
) diperoleh dan berlaku.
Jika implementasi perangkat mendukung Wi-Fi dan menggunakan Wi-Fi untuk pemindaian lokasi, mereka:
- [C-2-1] HARUS menyediakan kemampuan pengguna untuk mengaktifkan/menonaktifkan pembacaan nilai
melalui
WifiManager.isScanAlwaysAvailable
Metode API.
7.4.2.1. Wi-Fi Direct
Implementasi perangkat:
- HARUS menyertakan dukungan untuk Wi-Fi Langsung (Wi-Fi peer-to-peer).
Jika implementasi perangkat menyertakan dukungan untuk Wi-Fi Langsung, implementasi tersebut:
- [C-1-1] HARUS menerapkan Android API yang sesuai seperti yang dijelaskan dalam dokumentasi SDK.
- [C-1-2] HARUS melaporkan fitur hardware
android.hardware.wifi.direct
. - [C-1-3] HARUS mendukung operasi Wi-Fi reguler.
- [C-1-4] HARUS mendukung operasi Wi-Fi dan Wi-Fi Langsung secara serentak.
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mengacak alamat MAC sumber untuk semua koneksi Wi-Fi Langsung yang baru dibuat.
7.4.2.2. Pengaturan Wi-Fi Tunneled Direct Link
Implementasi perangkat:
- HARUS menyertakan dukungan untuk Wi-Fi Tunneled Direct Link Setup (TDLS) seperti yang dijelaskan dalam Dokumentasi Android SDK.
Jika 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.
- SEHARUSNYA heuristik dan TIDAK menggunakan TDLS ketika performanya mungkin lebih buruk dibandingkan dengan 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 fungsionalitas dengan aplikasi pihak ketiga, maka aplikasi tersebut akan:
- [C-1-1] HARUS mengimplementasikan
WifiAwareManager
API seperti yang dijelaskan dalam Dokumentasi SDK. - [C-1-2] HARUS mendeklarasikan tombol fitur
android.hardware.wifi.aware
. - [C-1-3] HARUS mendukung operasi Wi-Fi dan Wi-Fi Aware secara serentak.
- [C-1-4] HARUS mengacak alamat antarmuka pengelolaan Wi-Fi Aware secara berkala tidak lebih dari 30 menit dan setiap kali Wi-Fi Aware diaktifkan, kecuali jika operasi ranging sedang berlangsung atau jalur data Aware aktif (pengacakan tidak yang diharapkan selama jalur data aktif).
Jika implementasi perangkat mencakup dukungan untuk Wi-Fi Aware dan Lokasi Wi-Fi seperti yang dijelaskan di Bagian 7.4.2.5 dan menampilkan fungsi ini ke aplikasi pihak ketiga, lalu:
- [C-2-1] HARUS menerapkan API penemuan berbasis lokasi: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm, dan onServiceDiscovered DalamRange.
7.4.2.4. Passpoint Wi-Fi
Jika implementasi perangkat menyertakan dukungan untuk 802.11 (Wi-Fi), implementasi tersebut:
- [C-1-1] HARUS menyertakan dukungan untuk Passpoint Wi-Fi.
- [C-1-2] HARUS menerapkan
WifiManager
API terkait Passpoint sebagai yang dijelaskan dalam dokumentasi SDK. - [C-1-3] HARUS mendukung standar IEEE 802.11u, yang terkait secara khusus ke Penemuan dan Seleksi Jaringan, seperti Iklan Generik Service (GAS) dan Access Network Query Protocol (ANQP).
- [C-1-4] HARUS mendeklarasikan tombol 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 penyediaan perangkat berikut protokol seperti yang ditetapkan dalam Wi-Fi Alliance Passpoint R2: EAP-TTLS dan SOAP-XML.
- [C-1-7] HARUS memproses sertifikat server AAA seperti yang dijelaskan dalam Spesifikasi Hotspot 2.0 R3.
- [C-1-8] HARUS mendukung kontrol pengguna untuk penyediaan melalui pemilih Wi-Fi.
- [C-1-9] HARUS menjaga konfigurasi Passpoint tetap persisten setiap kali dimulai ulang.
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung persyaratan dan ketentuan penerimaan situs.
- [C-SR-2] SANGAT DIREKOMENDASIKAN untuk mendukung fitur informasi Tempat.
Jika tombol kontrol pengguna penonaktifan Passpoint global disediakan, implementasinya:
- [C-3-1] HARUS mengaktifkan Passpoint secara default.
7.4.2.5. Lokasi Wi-Fi (Waktu Round Trip Wi-Fi - RTT)
Implementasi perangkat:
- HARUS menyertakan dukungan untuk Lokasi Wi-Fi.
Jika implementasi perangkat menyertakan dukungan untuk Lokasi Wi-Fi dan mengekspos fungsionalitas dengan aplikasi pihak ketiga, maka aplikasi tersebut akan:
- [C-1-1] HARUS mengimplementasikan
WifiRttManager
API seperti yang dijelaskan dalam Dokumentasi SDK. - [C-1-2] HARUS mendeklarasikan tombol fitur
android.hardware.wifi.rtt
. - [C-1-3] HARUS mengacak alamat MAC sumber untuk setiap burst RTT yang dijalankan ketika antarmuka Wi-Fi tempat RTT yang dieksekusi tidak terkait dengan Titik Akses.
- [C-1-4] HARUS akurat dalam jarak 2 meter pada bandwidth 80 MHz pada band ke-68 persentil (sebagaimana dihitung dengan Fungsi Distribusi Kumulatif).
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk melaporkannya secara akurat dalam jarak 1,5 meter pada bandwidth 80 MHz pada persentil ke-68 (sebagaimana dihitung dengan Fungsi Distribusi Kumulatif).
7.4.2.6. Offload Keepalive Wi-Fi
Implementasi perangkat:
- HARUS menyertakan dukungan untuk Wi-Fi keepalive offload.
Jika implementasi perangkat menyertakan dukungan untuk Wi-Fi keepalive offload dan mengekspos fungsinya kepada aplikasi pihak ketiga, mereka:
- [C-1-1] HARUS mendukung SocketKeepAlive API.
- [C-1-2] HARUS mendukung setidaknya tiga slot keepalive serentak melalui Wi-Fi
Jika implementasi perangkat tidak menyertakan dukungan untuk Wi-Fi keepalive offload, mereka:
- [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 bagi aplikasi pihak ketiga, mereka:
- [C-1-1] HARUS memiliki WifiManager#isEasyConnectSupported()
menampilkan
true
.
7.4.2.8. Validasi Sertifikat Server Wi-Fi Perusahaan
Jika sertifikat server Wi-Fi tidak divalidasi atau server Wi-Fi nama domain tidak ditetapkan, implementasi perangkat:
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk tidak memberikan pilihan kepada pengguna menambahkan jaringan Wi-Fi Enterprise secara manual di aplikasi Setelan.
7.4.2.9. Kepercayaan Saat Penggunaan Pertama (TOFU)
Jika implementasi perangkat mendukung Kepercayaan pada penggunaan pertama (TOFU) dan izinkan pengguna untuk mendefinisikan konfigurasi WPA/WPA2/WPA3-Enterprise, maka mereka:
- [C-4-1] HARUS memberikan pilihan kepada pengguna untuk menggunakan TOFU.
7.4.3. Bluetooth
Jika implementasi perangkat mendukung profil Audio Bluetooth, implementasi tersebut:
- HARUS mendukung Codec Audio Lanjutan dan Codec Audio Bluetooth (misalnya LDAC)
Jika implementasi perangkat mendukung HFP, A2DP, dan AVRCP, implementasi tersebut:
- HARUS mendukung setidaknya 5 total perangkat terhubung.
Jika implementasi perangkat mendeklarasikan android.hardware.vr.high_performance
tersebut, mereka:
- [C-1-1] HARUS mendukung Ekstensi Panjang Data Bluetooth 4.2 dan Bluetooth LE.
Android menyertakan dukungan untuk Bluetooth dan Bluetooth Energi Rendah.
Jika implementasi perangkat menyertakan dukungan untuk Bluetooth dan Bluetooth Rendah Energi, fitur ini:
- [C-2-1] HARUS menyatakan fitur platform yang relevan
(
android.hardware.bluetooth
danandroid.hardware.bluetooth_le
masing-masing) dan menerapkan API platform. - HARUS menerapkan profil Bluetooth yang relevan seperti A2DP, AVRCP, OBEX, HFP, dll. yang sesuai untuk perangkat.
Jika implementasi perangkat menyertakan dukungan untuk Bluetooth Hemat Energi (BLE), implementasi tersebut:
- [C-3-1] HARUS mendeklarasikan fitur hardware
android.hardware.bluetooth_le
. - [C-3-2] HARUS mengaktifkan Bluetooth berbasis GATT (profil atribut generik) Google Cloud API seperti yang dijelaskan dalam dokumentasi SDK dan android.bluetooth.
- [C-3-3] HARUS melaporkan nilai yang benar untuk
BluetoothAdapter.isOffloadedFilteringSupported()
untuk menunjukkan apakah logika pemfilteran untuk ScanFilter Class API diimplementasikan. - [C-3-4] HARUS melaporkan nilai yang benar untuk
BluetoothAdapter.isMultipleAdvertisementSupported()
untuk menunjukkan apakah Iklan Hemat Energi didukung. [C-3-5] HARUS menerapkan waktu tunggu Alamat Pribadi Resolvable (RPA) tidak lagi lebih dari 15 menit dan merotasi alamat pada waktu tunggu untuk melindungi privasi pengguna ketika perangkat aktif menggunakan BLE untuk pemindaian atau iklan. Untuk mencegah serangan pengaturan waktu, interval waktu tunggu juga HARUS diacak antara 5 dan 15 menit.
HARUS mendukung pemindahan logika pemfilteran ke chipset Bluetooth saat menerapkan ScanFilter API.
HARUS mendukung pemindahan beban pemindaian batch ke chipset Bluetooth.
HARUS mendukung multi-iklan dengan minimal 4 slot.
Jika implementasi perangkat mendukung Bluetooth LE dan gunakan Bluetooth LE untuk pemindaian lokasi, fitur ini:
- [C-4-1] HARUS menyediakan kemampuan pengguna untuk mengaktifkan/menonaktifkan pembacaan nilai
melalui System API
BluetoothAdapter.isBleScanAlwaysAvailable()
.
Jika implementasi perangkat menyertakan dukungan untuk Bluetooth LE dan Alat Bantu Dengar Profil, sebagaimana dijelaskan dalam Dukungan Audio Alat Bantu Dengar dengan Bluetooth LE, alat ini:
- [C-5-1] HARUS mengembalikan
true
untuk BluetoothAdapter.getProfileProxy(konteks, pemroses, BluetoothProfile.HEARING_AID).
Jika implementasi perangkat mencakup dukungan untuk Bluetooth atau Bluetooth Hemat Energi, mereka:
- [C-6-1] HARUS membatasi akses ke metadata Bluetooth apa pun (seperti pemindaian
hasil) yang dapat digunakan untuk memperoleh lokasi perangkat, kecuali
aplikasi yang meminta berhasil meneruskan
android.permission.ACCESS_FINE_LOCATION
pemeriksaan izin berdasarkan status latar depan/latar belakangnya saat ini.
Jika penerapan perangkat menyertakan dukungan untuk Bluetooth atau Bluetooth Hemat Energi dan manifes aplikasi tidak menyertakan deklarasi dari developer yang menyatakan bahwa mereka tidak berasal dari {i>Bluetooth<i}, lalu, mereka:
- [C-6-2] HARUS membatasi akses Bluetooth di belakang
android.permission.ACCESS_FINE_LOCATION
.
Jika implementasi perangkat menampilkan true
untuk
BluetoothAdapter.isLeAudioSupported()
API, lalu:
- [C-7-1] HARUS mendukung klien unicast.
- [C-7-2] HARUS mendukung 2M PHY.
- [C-7-3] HARUS mendukung Iklan LE Extended.
- [C-7-4] HARUS mendukung setidaknya 2 koneksi CIS dalam CIG.
- [C-7-5] HARUS mengaktifkan klien unicast BAP, koordinator set CSIP, server MCP, pengontrol VCP, server CCP secara bersamaan.
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mengaktifkan klien unicast HAP.
Jika implementasi perangkat menampilkan true
untuk
BluetoothAdapter.isLeAudioBroadcastSourceSupported()
API, lalu:
- [C-8-1] HARUS mendukung setidaknya 2 link BIS di BIG.
- [C-8-2] HARUS mengaktifkan sumber siaran BAP, asisten siaran BAP secara bersamaan.
- [C-8-3] HARUS mendukung Iklan berkala LE.
Jika implementasi perangkat menampilkan true
untuk
BluetoothAdapter.isLeAudioBroadcastAssistantSupported()
API, lalu:
- [C-9-1] HARUS mendukung MASA DEPAN (Transfer Sinkronisasi Iklan Berkala).
- [C-9-2] HARUS mendukung Iklan berkala LE.
Jika implementasi perangkat mendeklarasikan FEATURE_BLUETOOTH_LE
, implementasi tersebut:
- [C-10-1] HARUS memiliki RSSI pengukuran dalam +/-9dB untuk 95% dari
pengukuran pada jarak 1 m dari perangkat referensi yang mentransmisikan pada
ADVERTISE_TX_POWER_HIGH
di lingkungan yang saling terlihat. - [C-10-2] HARUS menyertakan koreksi Rx/Tx untuk mengurangi penyimpangan per saluran sehingga pengukuran pada masing-masing dari 3 saluran, pada masing-masing antena (jika lebih dari satu digunakan), berada dalam +/-3 dB satu sama lain selama 95% pengukuran.
- [C-SR-2] SANGAT DIREKOMENDASIKAN untuk mengukur dan mengompensasi offset Rx ke
memastikan median BLE RSSI adalah -60dBm +/-10 dB pada jarak 1 m dari
perangkat referensi yang melakukan transmisi pada
ADVERTISE_TX_POWER_HIGH
, saat perangkat berada diorientasikan sedemikian rupa sehingga berada di 'bidang sejajar' dengan layar yang menghadap arah. - [C-SR-3] SANGAT DIREKOMENDASIKAN untuk mengukur dan mengompensasi offset Tx ke
pastikan median BLE RSSI adalah -60dBm +/-10 dB saat memindai dari referensi
perangkat diposisikan pada jarak 1 m dan mentransmisikan pada
ADVERTISE_TX_POWER_HIGH
, dengan orientasi perangkat sedemikian rupa sehingga berada di posisi aktif 'bidang sejajar' dengan layar yang menghadap ke arah yang sama.
SANGAT DIREKOMENDASIKAN untuk mengikuti langkah-langkah penyiapan pengukuran yang ditentukan dalam Persyaratan Kalibrasi Kehadiran.
7.4.4. Komunikasi Nirkabel Jarak Dekat
Implementasi perangkat:
- HARUS menyertakan pengirim dan penerima sinyal dan perangkat keras terkait untuk Komunikasi (NFC).
- [C-0-1] HARUS mengimplementasikan
android.nfc.NdefMessage
danandroid.nfc.NdefRecord
API meskipun tidak menyertakan dukungan untuk NFC atau mendeklarasikan fiturandroid.hardware.nfc
sebagai class yang mewakili format representasi data yang tidak bergantung pada protokol.
Jika implementasi perangkat menyertakan hardware NFC dan berencana untuk membuatnya tersedia untuk aplikasi pihak ketiga, mereka:
- [C-1-1] HARUS melaporkan fitur
android.hardware.nfc
dari Metodeandroid.content.pm.PackageManager.hasSystemFeature()
. - HARUS mampu membaca dan menulis pesan NDEF melalui NFC berikut standar seperti di bawah ini:
- [C-1-2] HARUS mampu bertindak sebagai pembaca/penulis Forum NFC
(sebagaimana didefinisikan oleh spesifikasi teknis Forum NFC
NFCForum-TS-DigitalProtocol-1.0) melalui standar NFC berikut:
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NfcF (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- Tag Forum NFC Jenis 1, 2, 3, 4, 5 (ditentukan oleh Forum NFC)
[C-SR-1] SANGAT DIREKOMENDASIKAN untuk dapat membaca dan menulis NDEF pesan serta data mentah melalui standar NFC berikut. Perlu diketahui bahwa walaupun standar NFC dinyatakan sebagai SANGAT DIREKOMENDASIKAN, Definisi Kompatibilitas untuk versi mendatang direncanakan untuk mengubah menjadi HARUS. Standar ini bersifat opsional dalam versi ini tetapi akan diwajibkan pada versi mendatang. Perangkat baru dan lama yang menjalankan versi ini Android sangat dianjurkan untuk memenuhi persyaratan ini sekarang, jadi mereka akan dapat meningkatkan ke rilis platform mendatang.
[C-1-13] HARUS mengadakan polling untuk semua teknologi yang didukung saat dalam penemuan NFC mode.
HARUS berada dalam mode penemuan NFC saat perangkat aktif dengan layar aktif dan layar kunci terbuka.
HARUS mampu membaca kode batang dan URL (jika dikodekan) dari Kode Batang NFC Thinkfilm Google.
Perhatikan bahwa link yang tersedia secara publik tidak tersedia untuk JIS, ISO, dan NFC Spesifikasi forum yang disebutkan di atas.
Android menyertakan dukungan untuk mode NFC Host Card Emulation (HCE).
Jika implementasi perangkat menyertakan chipset pengontrol NFC yang mendukung HCE (untuk NfcA dan/atau NfcB) serta mendukung perutean ID Aplikasi (AID), mereka:
- [C-2-1] HARUS melaporkan konstanta fitur
android.hardware.nfc.hce
. - [C-2-2] HARUS mendukung NFC HCE API sebagai yang ditentukan dalam Android SDK.
Jika implementasi perangkat menyertakan chipset pengontrol NFC yang mendukung HCE untuk NfcF, dan menerapkan fitur tersebut untuk aplikasi pihak ketiga, mereka:
- [C-3-1] HARUS melaporkan konstanta fitur
android.hardware.nfc.hcef
. - [C-3-2] HARUS menerapkan NfcF Card Emulation API seperti yang didefinisikan dalam Android SDK.
Jika implementasi perangkat menyertakan dukungan NFC umum seperti yang dijelaskan dalam dan mendukung teknologi MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF di MIFARE Classic) dalam peran pembaca/penulis, mereka:
- [C-4-1] HARUS mengimplementasikan Android API yang sesuai seperti yang didokumentasikan oleh Android SDK.
- [C-4-2] HARUS melaporkan fitur
com.nxp.mifare
dariandroid.content.pm.PackageManager.hasSystemFeature
() . Perhatikan bahwa ini bukan fitur Android standar dan dengan demikian muncul sebagai konstanta di classandroid.content.pm.PackageManager
.
7.4.5. Protokol dan API jaringan
7.4.5.1. Kemampuan Jaringan Minimum
Implementasi perangkat:
- [C-0-1] HARUS menyertakan dukungan untuk satu atau lebih bentuk jaringan data. Secara khusus, implementasi perangkat HARUS menyertakan dukungan untuk paling tidak satu standar data yang mampu hingga 200 Kbit/dtk atau lebih. Contoh yang memenuhi persyaratan ini mencakup EDGE, HSPA, EV-DO, 802.11g, Ethernet dan PAN Bluetooth.
- HARUS menyertakan dukungan untuk setidaknya satu data nirkabel umum standar, seperti 802.11 (Wi-Fi), ketika standar jaringan fisik (seperti Eternet) adalah koneksi data utama.
- MUNGKIN mengimplementasikan lebih dari satu bentuk konektivitas data.
7.4.5.2. IPv6
Implementasi perangkat:
- [C-0-2] HARUS menyertakan stack jaringan IPv6 dan mendukung IPv6
komunikasi menggunakan API terkelola, seperti
java.net.Socket
danjava.net.URLConnection
, serta API native, sepertiAF_INET6
. - [C-0-3] HARUS mengaktifkan IPv6 secara default.
- HARUS memastikan bahwa komunikasi IPv6 dapat diandalkan seperti IPv4, misalnya:
- [C-0-4] HARUS mempertahankan konektivitas IPv6 dalam mode istirahat.
- [C-0-5] Pembatasan kapasitas TIDAK BOLEH menyebabkan perangkat kehilangan IPv6 konektivitas pada jaringan yang mematuhi IPv6 yang menggunakan masa aktif RA setidaknya 180 detik.
- HARUS memastikan bahwa komunikasi IPv6 dapat diandalkan seperti IPv4, misalnya:
- [C-0-6] HARUS menyediakan aplikasi pihak ketiga dengan konektivitas IPv6 langsung
ke jaringan ketika terhubung ke jaringan
IPv6, tanpa bentuk alamat apa pun atau
terjemahan porta yang terjadi
secara lokal di perangkat. Kedua API terkelola seperti
Socket#getLocalAddress
atauSocket#getLocalPort
) dan NDK API sepertigetsockname()
atauIPV6_PKTINFO
HARUS menampilkan IP alamat dan porta yang sebenarnya digunakan untuk mengirim dan menerima paket pada jaringan dan terlihat sebagai IP sumber dan porta ke server internet (web).
Tingkat dukungan IPv6 yang dibutuhkan bergantung pada jenis jaringan, seperti yang ditunjukkan di persyaratan berikut.
Jika implementasi perangkat mendukung Wi-Fi, implementasi tersebut:
- [C-1-1] HARUS mendukung operasi dual-stack dan IPv6 saja pada Wi-Fi.
Jika implementasi perangkat mendukung Ethernet, implementasi tersebut:
- [C-2-1] HARUS mendukung operasi dual-stack dan IPv6 saja pada Eternet.
Jika implementasi perangkat mendukung data Seluler, implementasi tersebut:
- [C-3-1] HARUS mendukung operasi IPv6 (hanya IPv6 dan mungkin dual-stack) pada seluler.
Jika implementasi perangkat mendukung lebih dari satu jenis jaringan (misalnya, Wi-Fi dan data seluler), mereka:
- [C-4-1] HARUS memenuhi persyaratan di atas secara bersamaan di masing-masing jaringan saat perangkat tersambung ke lebih dari satu jenis jaringan secara bersamaan.
7.4.5.3. Tawanan Portal
Portal tawanan mengacu pada jaringan yang memerlukan login untuk mendapatkan akses internet.
Jika implementasi perangkat menyediakan implementasi lengkap dari
android.webkit.Webview API
,
mereka:
- [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, di panggilan ke 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 ketika 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 lalu lintas jaringan yang tidak berkomunikasi secara eksplisit dengan portal tawanan. - [C-1-5] HARUS memastikan bahwa, selagi pengguna masuk ke captive
jaringan default yang digunakan aplikasi (seperti yang ditampilkan oleh
ConnectivityManager.getActiveNetwork
,ConnectivityManager.registerDefaultNetworkCallback
, dan digunakan secara {i>default<i} oleh API jaringan Java seperti java.net.Socket, dan API native seperticonnect()
) adalah jaringan lain yang tersedia yang menyediakan akses internet, jika tersedia.
7.4.6. Setelan Sinkronisasi
Implementasi perangkat:
- [C-0-1] HARUS mengaktifkan pengaturan sinkronisasi otomatis master secara default agar
metode
getMasterSyncAutomatically()
akan menampilkan "true".
7.4.7. Penghemat Data
Jika implementasi perangkat menyertakan koneksi berkuota, implementasi tersebut adalah:
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menyediakan mode penghemat data.
Jika implementasi perangkat menyediakan mode penghemat data, implementasi tersebut:
- [C-1-1] HARUS mendukung semua API di
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 kemampuan Open Mobile API elemen keamanan dan menyediakannya untuk aplikasi pihak ketiga, mereka:
[C-1-1] HARUS menghitung pembaca elemen aman yang tersedia melalui API
android.se.omapi.SEService.getReaders()
.[C-1-2] HARUS mendeklarasikan tombol fitur yang benar melalui
android.hardware.se.omapi.uicc
untuk perangkat dengan elemen aman berbasis UICC,android.hardware.se.omapi.ese
untuk perangkat dengan elemen pengaman berbasis eSE danandroid.hardware.se.omapi.sd
untuk perangkat dengan elemen pengaman berbasis SD.
7.4.9. UWB
Jika implementasi perangkat menyertakan dukungan untuk 802.1.15.4 dan mengekspos fungsionalitas ke aplikasi pihak ketiga, maka mereka:
- [C-1-1] HARUS mengimplementasikan Android API yang sesuai di android.uwb.
- [C-1-2] HARUS melaporkan tanda fitur hardware android.hardware.uwb.
- [C-1-3] HARUS mendukung semua profil UWB relevan yang ditentukan di Android terlepas dari implementasi layanan.
- [C-1-4] HARUS menyediakan affordance pengguna untuk memungkinkan pengguna mengaktifkan/menonaktifkan UWB status aktif/nonaktif radio.
- [C-1-5] HARUS memberlakukan bahwa aplikasi yang menggunakan radio UWB memiliki izin UWB_RANGING (di bagian grup izin NEARBY_devices).
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk memenuhi kesesuaian yang relevan dan ujian sertifikasi yang ditetapkan oleh organisasi standar, termasuk FIRA, CCC dan CSA.
- [C-1-6] HARUS memastikan pengukuran jarak berada dalam +/-15 cm untuk 95% pengukuran di lingkungan garis pandang pada jarak 1 m dalam non-reflektif.
- [C-1-7] HARUS memastikan bahwa median pengukuran jarak pada jarak 1 meter dari perangkat referensi berada dalam jarak [0,75 m, 1,25 m], di mana kebenaran dasar jarak diukur dari tepi atas DUT.
- [C-SR-2] SANGAT DIREKOMENDASIKAN untuk mengikuti langkah-langkah penyiapan pengukuran ditentukan dalam Persyaratan Kalibrasi Kehadiran.
7.5. Kamera
Jika implementasi perangkat menyertakan setidaknya satu kamera, implementasi tersebut:
- [C-1-1] HARUS mendeklarasikan tombol fitur
android.hardware.camera.any
. - [C-1-2] HARUS memungkinkan aplikasi untuk mengalokasikan 3 RGBA_8888 bitmap sama dengan ukuran gambar yang dihasilkan oleh dengan resolusi terbesar di perangkat, saat kamera dibuka dari pratinjau dasar dan tetap akan menangkap gambar tersebut.
- [C-1-3] HARUS memastikan bahwa aplikasi kamera default bawaan
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 mengirimkannya ke aplikasi penerima ketika aplikasi penerima tidak memilikiACCESS_FINE_LOCATION
.
Jika implementasi perangkat mendukung kemampuan output HDR 10-bit, implementasi tersebut:
- [C-2-1] HARUS mendukung setidaknya profil HLG HDR untuk setiap perangkat kamera yang mendukung output 10-bit.
- [C-2-2] HARUS mendukung output 10-bit baik untuk kamera utama atau kamera depan utama.
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung output 10-bit untuk kamera.
- [C-2-3] HARUS mendukung profil HDR yang sama untuk semua Sub-kamera fisik yang berkemampuan BACKWARD_COMPATIBLE dari kamera logis, dan kamera logis itu sendiri.
Untuk perangkat kamera Logis yang mendukung HDR 10-bit yang mengimplementasikan
android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO
API, ini:
- [C-3-1] HARUS mendukung peralihan di antara semua perangkat fisik yang kompatibel dengan versi sebelumnya
kamera melalui kontrol
CONTROL_ZOOM_RATIO
pada kamera logis.
7.5.1 Kamera Belakang
Kamera belakang adalah kamera menghadap ke dunia yang mengambil gambar pemandangan di sisi jauh perangkat, seperti kamera tradisional; pada perangkat genggam, yaitu kamera yang terletak di sisi perangkat di seberang layar.
Implementasi perangkat:
- HARUS dilengkapi dengan kamera belakang.
Jika implementasi perangkat menyertakan setidaknya satu kamera belakang, implementasi tersebut:
- [C-1-1] HARUS melaporkan tombol fitur
android.hardware.camera
danandroid.hardware.camera.any
. - [C-1-2] HARUS memiliki resolusi minimal 2 megapiksel.
- HARUS menerapkan fokus otomatis hardware atau fokus otomatis software di driver kamera (transparan untuk software aplikasi).
- MUNGKIN memiliki hardware fokus tetap atau EDOF (extended depth of field).
- MUNGKIN menyertakan flash.
Jika kamera menyertakan flash:
- [C-2-1] lampu flash TIDAK BOLEH menyala saat
android.hardware.Camera.PreviewCallback
instance telah didaftarkan di platform pratinjau Kamera, kecuali jika aplikasi telah mengaktifkan secara eksplisit flash dengan mengaktifkan atributFLASH_MODE_AUTO
atauFLASH_MODE_ON
dari objekCamera.Parameters
. Perhatikan bahwa batasan ini tidak berlaku untuk aplikasi kamera sistem bawaan perangkat, tetapi hanya untuk pihak ketiga, aplikasi menggunakanCamera.PreviewCallback
.
7.5.2. Kamera Depan
Kamera depan adalah kamera yang menghadap pengguna yang biasanya digunakan untuk mengambil pengguna, seperti untuk melakukan konferensi video dan aplikasi serupa; di perangkat genggam perangkat, yaitu kamera yang terletak di sisi perangkat yang sama dengan layar.
Implementasi perangkat:
- Mungkin menyertakan kamera depan.
Jika implementasi perangkat menyertakan setidaknya satu kamera depan, implementasi tersebut:
- [C-1-1] HARUS melaporkan tombol fitur
android.hardware.camera.any
danandroid.hardware.camera.front
. - [C-1-2] HARUS memiliki resolusi minimal VGA (640x480 piksel).
- [C-1-3] TIDAK BOLEH menggunakan kamera depan sebagai kamera default untuk Camera API dan TIDAK BOLEH mengonfigurasi API untuk memperlakukan kamera depan sebagai kamera belakang default, meskipun kamera tersebut adalah satu-satunya kamera di perangkat.
- [C-1-4] Pratinjau kamera HARUS dicerminkan secara horizontal sesuai dengan
orientasi yang ditetapkan oleh aplikasi ketika aplikasi saat ini memiliki
secara eksplisit meminta agar Kamera
layar diputar melalui panggilan ke
android.hardware.Camera.setDisplayOrientation()
. Sebaliknya, pratinjau HARUS dicerminkan di sepanjang sumbu horizontal ketika aplikasi saat ini tidak secara eksplisit meminta layar Kamera diputar melalui panggilan keandroid.hardware.Camera.setDisplayOrientation()
. - [C-1-5] TIDAK BOLEH mencerminkan streaming video atau gambar diam akhir yang diambil dikembalikan ke callback aplikasi atau diserahkan ke penyimpanan media.
- [C-1-6] HARUS mencerminkan gambar yang ditampilkan oleh tampilan pos dengan cara yang sama sebagai streaming gambar pratinjau kamera.
- MUNGKIN mencakup fitur (seperti fokus otomatis, flash, dll.) yang tersedia untuk kamera belakang seperti dijelaskan di bagian 7.5.1.
Jika implementasi perangkat dapat diputar oleh pengguna (seperti secara otomatis melalui akselerometer atau secara manual melalui input pengguna):
- [C-2-1] Pratinjau kamera HARUS dicerminkan secara horizontal sesuai dengan orientasi perangkat saat ini.
7.5.3. Kamera Eksternal
Kamera eksternal adalah kamera yang dapat dipasang atau dilepas secara fisik implementasi perangkat kapan saja dan dapat menghadap ke segala arah; seperti USB kamera.
Implementasi perangkat:
- Mungkin mencakup dukungan untuk kamera eksternal yang belum tentu selalu terhubung.
Jika implementasi perangkat menyertakan dukungan untuk kamera eksternal, implementasi tersebut:
- [C-1-1] HARUS mendeklarasikan tombol fitur platform
android.hardware.camera.external
danandroid.hardware camera.any
. - [C-1-2] HARUS mendukung USB Video Class (UVC 1.0 atau lebih tinggi) jika kamera terhubung melalui porta {i>host<i} USB.
- [C-1-3] HARUS lulus uji CTS kamera dengan perangkat kamera eksternal fisik terhubung. Detail pengujian CTS kamera tersedia di source.android.com.
- HARUS mendukung kompresi video, seperti MJPEG untuk mengaktifkan transfer streaming yang tidak dienkode berkualitas tinggi (yaitu gambar mentah atau terkompresi secara independen feed).
- MUNGKIN mendukung beberapa kamera.
- Mungkin mendukung encoding video berbasis kamera.
Jika encoding video berbasis kamera didukung:
- [C-2-1] Operasi yang simultan streaming yang tidak dienkode / MJPEG (resolusi QVGA atau lebih besar) HARUS dapat diakses dalam implementasi perangkat.
7.5.4. Perilaku Camera API
Android menyertakan dua paket API untuk mengakses kamera, API android.hardware.camera2 mengekspos kontrol kamera tingkat rendah ke aplikasi, termasuk alur burst/streaming zero-copy yang efisien dan kontrol per frame eksposur, penambahan, penambahan white balance, konversi warna, denoise, mempertajam, dan lain-lain.
Paket API lama,android.hardware.Camera
, ditandai sebagai tidak digunakan lagi di
Android 5.0, tetapi masih harus tersedia untuk digunakan oleh aplikasi. Perangkat Android
HARUS memastikan dukungan berkelanjutan terhadap API seperti yang dijelaskan dalam
bagian ini dan di Android SDK.
Semua fitur yang umum di antara class android.hardware.Camera yang tidak digunakan lagi dan paket android.hardware.camera2 yang lebih baru HARUS memiliki performa yang setara dan kualitas di kedua API. Misalnya, dengan pengaturan yang setara, kecepatan dan akurasi fokus otomatis harus sama, serta kualitas gambar yang diambil harus sama. Fitur yang bergantung pada semantik yang berbeda dari kedua API tidak harus memiliki kecepatan atau kualitas yang sama, tetapi HARUS memiliki kecocokan mungkin.
Implementasi perangkat HARUS menerapkan perilaku berikut untuk terkait kamera, untuk semua kamera yang tersedia. Implementasi perangkat:
- [C-0-1] HARUS menggunakan
android.hardware.PixelFormat.YCbCr_420_SP
untuk pratinjau data yang diberikan ke callback aplikasi saat aplikasi tidak pernah memanggilandroid.hardware.Camera.Parameters.setPreviewFormat(int)
. - [C-0-2] Selanjutnya HARUS dalam format pengkodean NV21 saat aplikasi
mendaftarkan
android.hardware.Camera.PreviewCallback
dan sistem memanggil metodeonPreviewFrame()
serta pratinjau formatnya adalah YCbCr_420_SP, data dalam byte[] yang diteruskan keonPreviewFrame()
. Artinya, NV21 HARUS menjadi default. - [C-0-3] HARUS mendukung format YV12 (sebagaimana dinyatakan dalam
Konstanta
android.graphics.ImageFormat.YV12
) untuk pratinjau kamera untuk keduanya kamera depan dan belakang untukandroid.hardware.Camera
. (Perangkat keras encoder dan kamera video dapat menggunakan format piksel native apa pun, tetapi perangkat HARUS mendukung konversi ke YV12.) - [C-0-4] HARUS mendukung
android.hardware.ImageFormat.YUV_420_888
danandroid.hardware.ImageFormat.JPEG
berformat sebagai output melaluiandroid.media.ImageReader
API untukandroid.hardware.camera2
perangkat yang iklankanREQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE
yang lebih tinggi diandroid.request.availableCapabilities
. - [C-0-5] Tetap harus menerapkan Camera API penuh
disertakan dalam dokumentasi Android SDK, terlepas dari apakah perangkat
mencakup fokus otomatis hardware atau kemampuan lainnya. Misalnya, kamera yang
tidak memiliki fokus otomatis HARUS tetap memanggil
android.hardware.Camera.AutoFocusCallback
instance (meskipun tidak memiliki relevansi terhadap kamera non-fokus otomatis.) Perhatikan bahwa ini berlaku untuk mode depan kamera; misalnya, meskipun sebagian besar kamera depan tidak mendukung fokus otomatis, callback API harus tetap "palsu" sebagaimana telah dijelaskan. - [C-0-6] HARUS mengenali dan mematuhi setiap nama parameter
didefinisikan sebagai konstanta di
android.hardware.Camera.Parameters
dan classandroid.hardware.camera2.CaptureRequest
. Sebaliknya, implementasi perangkat TIDAK BOLEH mengikuti atau mengenali konstanta string diteruskan ke metodeandroid.hardware.Camera.setParameters()
selain yang didokumentasikan sebagai konstanta padaandroid.hardware.Camera.Parameters
. Yaitu, perangkat HARUS mendukung semua parameter Kamera standar jika diizinkan oleh hardware, 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 tepat dengan
android.info.supportedHardwareLevel
seperti yang dijelaskan dalam Android SDK dan melaporkan flag fitur framework. - [C-0-8] juga HARUS menyatakan kemampuan kameranya masing-masing sebesar
android.hardware.camera2
melalui propertiandroid.request.availableCapabilities
dan mendeklarasikan tombol fitur yang sesuai; HARUS menentukan tombol fitur jika ada perangkat kamera yang terpasang yang mendukung fitur tersebut. - [C-0-9] HARUS menyiarkan
Camera.ACTION_NEW_PICTURE
setiap kali gambar baru diambil oleh kamera dan entri gambar telah ditambahkan ke penyimpanan media. - [C-0-10] HARUS menyiarkan
Camera.ACTION_NEW_VIDEO
setiap kali video baru direkam oleh kamera dan entri gambar telah ditambahkan ke penyimpanan media. - [C-0-11] HARUS memiliki semua kamera yang dapat diakses melalui
android.hardware.Camera
API juga dapat diakses melaluiandroid.hardware.camera2
Compute Engine API. - [C-0-12] HARUS memastikan bahwa tampilan wajah TIDAK diubah, termasuk
tetapi tidak terbatas pada mengubah geometri wajah, warna kulit wajah, atau
pelembutan kulit untuk
android.hardware.camera2
apa pun atauandroid.hardware.Camera
Compute Engine API. - [C-SR-1] Untuk perangkat dengan beberapa kamera RGB di
jarak yang dekat dan
menghadap ke arah yang sama,
SANGAT DIREKOMENDASIKAN untuk mendukung perangkat kamera logis yang mencantumkan
kapabilitas
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
, yang terdiri dari semua kamera RGB yang menghadap ke arah itu sebagai sub-perangkat fisik.
Jika implementasi perangkat menyediakan API kamera eksklusif untuk aplikasi pihak ketiga, mereka:
- [C-1-1] HARUS mengimplementasikan API kamera tersebut menggunakan
android.hardware.camera2
Compute Engine API. - MUNGKIN menyediakan tag dan/atau ekstensi vendor untuk
android.hardware.camera2
Compute Engine API.
7.5.5. Orientasi Kamera
Jika implementasi perangkat memiliki kamera depan atau belakang, kamera tersebut:
- [C-1-1] HARUS diorientasikan sehingga dimensi panjang kamera sejajar dengan dimensi panjang layar. Artinya, saat perangkat dipegang dalam mode lanskap kamera HARUS mengambil gambar dalam orientasi lanskap. Ini berlaku terlepas dari orientasi alami perangkat; yaitu, berlaku untuk perangkat utama lanskap serta perangkat utama potret.
Perangkat yang memenuhi semua kriteria berikut akan dikecualikan dari persyaratan di atas:
- Perangkat menerapkan layar geometri variabel, seperti perangkat foldable atau berengsel layar.
- Saat status lipatan atau engsel perangkat berubah, perangkat akan beralih orientasi potret-utama menjadi lanskap-utama (atau sebaliknya).
- Implementasi perangkat yang tidak dapat dirotasi oleh pengguna seperti sebagai perangkat otomotif.
7.6. Memori dan Penyimpanan
7.6.1 Memori dan Penyimpanan Minimum
Implementasi perangkat:
- [C-0-1] HARUS menyertakan Pengelola Download yang MUNGKIN digunakan aplikasi untuk mengunduh file data dan aplikasi itu HARUS mampu mengunduh file individual yang berukuran minimal 100MB ke default "cache" lokasi HTTP/HTTPS.
7.6.2. Penyimpanan Bersama Aplikasi
Implementasi perangkat:
- [C-0-1] HARUS menawarkan penyimpanan untuk digunakan bersama oleh aplikasi, yang juga sering disebut sebagai "penyimpanan eksternal bersama", "penyimpanan bersama aplikasi" atau oleh Linux jalur "/sdcard" tempatnya dipasang.
- [C-0-2] HARUS dikonfigurasi dengan penyimpanan bersama yang dipasang secara default, di kata-kata "siap pakai", terlepas dari apakah penyimpanan diimplementasikan di komponen penyimpanan internal atau media penyimpanan yang dapat dilepas (misalnya, Secure Slot kartu digital).
- [C-0-3] HARUS memasang penyimpanan bersama aplikasi langsung di jalur Linux
sdcard
atau menyertakan link simbolis Linux darisdcard
ke pemasangan sebenarnya poin. - [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 meminta
android:requestLegacyExternalStorage="true"
dalam manifesnya.
- Saat aplikasi meminta
- [C-0-5] HARUS menyamarkan metadata lokasi, misalnya tag Exif GPS, yang disimpan di
file media saat file tersebut diakses melalui
MediaStore
, kecuali jika aplikasi pemanggil memiliki izinACCESS_MEDIA_LOCATION
.
Implementasi perangkat MUNGKIN memenuhi persyaratan di atas menggunakan salah satu berikut ini:
- Penyimpanan yang dapat dilepas yang dapat diakses pengguna, seperti slot kartu Secure Digital (SD).
- Sebagian penyimpanan internal (tidak dapat dilepas) seperti yang diimplementasikan dalam Proyek Open Source Android (AOSP).
Jika implementasi perangkat menggunakan penyimpanan yang dapat dilepas untuk memenuhi persyaratan di atas persyaratan tersebut, mereka:
- [C-1-1] HARUS menerapkan toast atau antarmuka pengguna pop-up yang memperingatkan pengguna bila tidak ada media penyimpan yang dimasukkan ke dalam slot.
- [C-1-2] HARUS menyertakan media penyimpanan berformat FAT (mis. kartu SD) atau acara pada kotak dan bahan lain yang tersedia saat pembelian di mana penyimpanan media harus dibeli secara terpisah.
Jika implementasi perangkat menggunakan sebagian dari penyimpanan tak dapat dilepas untuk memenuhi persyaratan di atas, mereka:
- HARUS menggunakan implementasi AOSP dari aplikasi internal bersama Storage.
- DAPAT berbagi ruang penyimpanan dengan data pribadi aplikasi.
Jika implementasi perangkat memiliki porta USB dengan dukungan mode periferal USB, mereka:
- [C-3-1] HARUS menyediakan mekanisme untuk mengakses data pada aplikasi penyimpanan bersama dari komputer {i>host<i}.
- HARUS mengekspos konten dari kedua jalur penyimpanan secara transparan melalui
Layanan pemindai media Android dan
android.provider.MediaStore
. - MUNGKIN menggunakan penyimpanan massal USB, tetapi HARUS menggunakan Media Transfer Protocol untuk memenuhi persyaratan ini.
Jika implementasi perangkat memiliki port USB dengan dukungan dan mode periferal USB Media Transfer Protocol, keduanya:
- SEHARUSNYA kompatibel dengan {i>host<i} MTP Android referensi, Transfer File Android.
- HARUS melaporkan kelas perangkat USB 0x00.
- HARUS melaporkan nama antarmuka USB 'MTP'.
7.6.3. Penyimpanan yang Dapat Diadopsi
Jika perangkat tersebut dirancang untuk bersifat seluler tidak seperti Televisi, implementasi perangkat adalah:
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan penyimpanan yang dapat diadopsi di dalam jangka panjang yang stabil, karena secara tidak sengaja memutuskan sambungan dapat menyebabkan kehilangan/kerusakan data.
Jika porta perangkat penyimpanan yang dapat dilepas berada di lokasi stabil jangka panjang, seperti di dalam kompartemen baterai atau penutup pelindung lainnya, implementasi perangkat adalah:
- [C-SR-2] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan penyimpanan yang dapat diadaptasi.
7.7. USB
Jika implementasi perangkat memiliki port USB, implementasi tersebut:
- HARUS mendukung mode periferal USB dan SEHARUSNYA mendukung mode host USB.
- HARUS mendukung penonaktifan sinyal data melalui USB.
7.7.1 Mode periferal USB
Jika implementasi perangkat menyertakan port USB yang mendukung mode periferal:
- [C-1-1] Porta HARUS dapat dihubungkan ke host USB yang memiliki porta USB tipe-A atau tipe-C.
- [C-1-2] HARUS melaporkan nilai
iSerialNumber
yang benar dalam standar USB deskripsi perangkat melaluiandroid.os.Build.SERIAL
. - [C-1-3] HARUS mendeteksi pengisi daya 1,5A dan 3,0A per resistor Tipe-C standar dan HARUS mendeteksi perubahan di iklan jika perubahan didukung USB Type-C.
- [C-SR-1] Port SEHARUSNYA menggunakan faktor bentuk USB mikro-B, mikro-AB, atau Tipe-C. Perangkat Android lama dan baru DIREKOMENDASIKAN UNTUK memenuhi persyaratan ini persyaratan layanan agar mereka dapat mengupgrade ke rilis platform mendatang.
- [C-SR-2] Port SEHARUSNYA berada di bagian bawah perangkat (sesuai dengan orientasi alami) atau mengaktifkan rotasi layar software untuk semua aplikasi (termasuk layar utama), sehingga tampilan tergambar dengan benar saat perangkat diorientasikan dengan porta di bagian bawah. Android lama dan baru perangkat SANGAT DIREKOMENDASIKAN untuk memenuhi persyaratan ini sehingga akan dapat mengupgrade ke rilis platform mendatang.
- [C-SR-3] HARUS mengimplementasikan dukungan untuk menggambar arus 1,5 A selama chirp HS dan traffic seperti yang ditentukan dalam spesifikasi Pengisian Daya Baterai USB, revisi 1.2. Perangkat Android lama dan baru DIREKOMENDASIKAN UNTUK memenuhi persyaratan ini persyaratan layanan agar mereka dapat mengupgrade ke rilis platform mendatang.
- [C-SR-4] SANGAT DIREKOMENDASIKAN untuk tidak mendukung eksklusif metode pengisian daya yang memodifikasi tegangan Vbus di luar tingkat default, atau mengubah peran sink/sumber seperti itu dapat mengakibatkan masalah interoperabilitas dengan pengisi daya atau perangkat yang mendukung metode Pengiriman Daya USB standar. Meskipun hal ini disebut sebagai "SANGAT DIREKOMENDASIKAN", di versi Android mendatang kami mungkin MEMERLUKAN semua perangkat tipe-C untuk mendukung interoperabilitas penuh dengan pengisi daya tipe-C.
- [C-SR-5] SANGAT DIREKOMENDASIKAN untuk mendukung Pengiriman Daya untuk data dan menukar peran daya saat perangkat mendukung mode host USB dan USB Tipe-C.
- HARUS mendukung Pengiriman Daya untuk pengisian tegangan tinggi dan dukungan untuk Mode Alternatif seperti tampilan keluar.
- HARUS mengimplementasikan Android Open Accessory API (AOA) API dan spesifikasi sebagai didokumentasikan dalam dokumentasi Android SDK.
Jika implementasi perangkat menyertakan port USB dan menerapkan AOA spesifikasi, mereka:
- [C-2-1] HARUS mendeklarasikan dukungan untuk fitur hardware
android.hardware.usb.accessory
- [C-2-2] Kelas penyimpanan massal USB HARUS menyertakan string "android" di
akhir string deskripsi antarmuka
iInterface
dari penyimpanan massal USB
7.7.2. Mode host USB
Jika implementasi perangkat menyertakan port USB yang mendukung mode host, implementasi tersebut:
- [C-1-1] HARUS mengimplementasikan Android USB host API seperti yang didokumentasikan dalam
Android SDK dan HARUS mendeklarasikan dukungan untuk fitur hardware
android.hardware.usb.host
- [C-1-2] HARUS menerapkan dukungan untuk menyambungkan periferal USB standar,
dengan kata lain, mereka HARUS:
- Memiliki port tipe C di perangkat atau dikirimkan dengan kabel yang menyesuaikan dengan perangkat port eksklusif ke port USB type-C standar (perangkat USB Type-C).
- Memiliki tipe A di perangkat atau dilengkapi dengan kabel yang sesuai di perangkat port eksklusif ke porta USB tipe-A standar.
- Memiliki port micro-AB di perangkat, yang HARUS dikirimkan dengan adaptasi kabel ke porta tipe A standar.
- [C-1-3] TIDAK BOLEH mengirim dengan adaptor yang dikonversi dari USB tipe A atau port micro-AB ke port tipe-C (receptacle).
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan Kelas audio USB seperti yang didokumentasikan dalam dokumentasi Android SDK.
- HARUS mendukung pengisian daya perangkat periferal USB yang terhubung saat berada di host mode; mengiklankan arus sumber minimal 1,5A sebagaimana ditentukan dalam Parameter Penghentian dari Kabel USB Type-C dan Spesifikasi Konektor Revisi 1.2 untuk USB Type-C atau menggunakan rentang arus output Porta Pengisian Daya Downstream (CDP) sebagai 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 USB, kelas audio, mereka dapat:
- [C-2-1] HARUS mendukung class USB HID.
- [C-2-2] HARUS mendukung deteksi dan pemetaan data HID berikut
kolom yang ditentukan dalam Tabel Penggunaan HID USB
dan Permintaan Penggunaan Perintah Suara
ke
KeyEvent
konstanta seperti di bawah ini:- ID Penggunaan Halaman Penggunaan (0xC):
KEYCODE_MEDIA_PLAY_PAUSE
- ID Penggunaan Halaman Penggunaan (0xC) (0x0E9):
KEYCODE_VOLUME_UP
- ID Penggunaan Halaman Penggunaan (0xC):
KEYCODE_VOLUME_DOWN
- ID Penggunaan Halaman Penggunaan (0xC):
KEYCODE_VOICE_ASSIST
- ID Penggunaan Halaman Penggunaan (0xC):
Jika implementasi perangkat menyertakan porta USB yang mendukung mode {i>host<i} dan Storage Access Framework (SAF), yaitu:
- [C-3-1] HARUS mengenali MTP (Media Transfer Protocol) yang terhubung dari jarak jauh
perangkat Anda dan membuat kontennya
dapat diakses melalui
ACTION_GET_CONTENT
,ACTION_OPEN_DOCUMENT
, dan intentACTION_CREATE_DOCUMENT
. .
Jika implementasi perangkat menyertakan port USB yang mendukung mode host dan USB Tipe-C, {i>tool <i}ini:
- [C-4-1] HARUS menerapkan fungsi Dual Role Port seperti yang didefinisikan oleh USB Spesifikasi Tipe-C (bagian 4.5.1.3.3). Untuk Dual Port Peran, Pada perangkat yang menyertakan colokan audio 3,5 mm, sink USB deteksi (mode {i>host<i}) MUNGKIN dimatikan secara {i>default<i} tetapi HARUS memungkinkan untuk mengaktifkannya.
- [C-SR-2] SANGAT DIREKOMENDASIKAN untuk mendukung DisplayPort, HARUS mendukung USB Tarif Data Kecepatan Super, dan SANGAT DIREKOMENDASIKAN untuk mendukung Pengiriman Daya untuk pertukaran peran data dan daya.
- [C-SR-3] SANGAT DIREKOMENDASIKAN untuk TIDAK mendukung Mode Aksesori Adaptor Audio sebagai yang dijelaskan di Apendiks A Kabel USB Type-C dan Spesifikasi Konektor Revisi 1.2.
- HARUS menerapkan model Coba.* yang paling sesuai untuk faktor bentuk perangkat. Misalnya, perangkat genggam SEHARUSNYA mengimplementasikan Coba model SNK.
7.8. Audio
7.8.1. Mikrofon
Jika implementasi perangkat menyertakan mikrofon, implementasi tersebut:
- [C-1-1] HARUS melaporkan konstanta fitur
android.hardware.microphone
. - [C-1-2] HARUS memenuhi persyaratan perekaman audio dalam bagian 5.4.
- [C-1-3] HARUS memenuhi persyaratan latensi audio dalam pasal 5.6.
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung perekaman mendekati ultrasonik 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 mengimplementasikan API perekaman audio setidaknya sebagai tanpa pengoperasian, sesuai bagian 7.
7.8.2. Output Audio
Jika implementasi perangkat menyertakan speaker atau output audio/multimedia untuk periferal output audio seperti colokan audio 3,5 mm 4 konduktor atau Port mode host USB menggunakan class audio USB, yaitu:
- [C-1-1] HARUS melaporkan konstanta fitur
android.hardware.audio.output
. - [C-1-2] HARUS memenuhi persyaratan pemutaran audio dalam bagian 5.5.
- [C-1-3] HARUS memenuhi persyaratan latensi audio dalam pasal 5.6.
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung pemutaran mendekati ultrasonik seperti dijelaskan di bagian 7.8.3.
Jika implementasi perangkat tidak menyertakan port output speaker atau audio, implementasi tersebut:
- [C-2-1] TIDAK BOLEH melaporkan fitur
android.hardware.audio.output
. - [C-2-2] HARUS mengimplementasikan API terkait Output Audio setidaknya sebagai tanpa operasi.
Untuk tujuan bagian ini, "port output" adalah antarmuka fisik seperti colokan audio 3,5 mm, HDMI, atau port mode host USB dengan kelas audio USB. Dukungan untuk {i>output<i} audio melalui protokol berbasis radio seperti Bluetooth, Wi-Fi atau jaringan seluler tidak memenuhi syarat sebagai termasuk "port output".
7.8.2.1. Port Audio Analog
Agar kompatibel dengan headset dan aksesori audio lainnya menggunakan colokan audio 3,5 mm di seluruh ekosistem Android, jika perangkat implementasinya mencakup satu atau beberapa port audio analog, yaitu:
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menyertakan setidaknya salah satu dari port audio menjadi colokan audio 3,5 mm konduktor 4 konduktor.
Jika implementasi perangkat memiliki colokan audio 3,5 mm konduktor 4, implementasi tersebut:
- [C-1-1] HARUS mendukung pemutaran audio ke headphone stereo dan headset stereo dengan mikrofon.
- [C-1-2] HARUS mendukung steker audio TRRS dengan urutan pin-out CTIA.
- [C-1-3] HARUS mendukung deteksi dan pemetaan ke kode tombol untuk
mengikuti 3 rentang impedansi setara antara mikrofon dan ground
konduktor 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 memasukkan, tetapi hanya setelah semua kontak di steker menyentuh segmen mereka yang relevan pada colokan. - [C-1-5] HARUS mampu mengemudi setidaknya 150mV ± 10% dari tegangan output impedansi speaker 32 ohm.
- [C-1-6] HARUS memiliki tegangan bias mikrofon antara 1.8V ~ 2.9V.
- [C-1-7] HARUS mendeteksi dan memetakan ke kode tombol untuk hal berikut
rentang impedansi setara antara mikrofon dan konduktor tanah
pada steker audio:
- 110-180 ohm:
KEYCODE_VOICE_ASSIST
- 110-180 ohm:
- [C-SR-2] SANGAT DIREKOMENDASIKAN untuk mendukung steker audio dengan OMTP urutan {i>pin-out<i}.
- [C-SR-3] SANGAT DIREKOMENDASIKAN untuk mendukung perekaman audio dari stereo headset dengan mikrofon.
Jika implementasi perangkat memiliki 4 konduktor colokan audio 3,5 mm dan mendukung
mikrofon, dan siarkan android.intent.action.HEADSET_PLUG
dengan
mikrofon dengan nilai ekstra yang ditetapkan sebagai 1, yaitu:
- [C-2-1] HARUS mendukung deteksi mikrofon pada audio yang dicolokkan aksesori.
7.8.2.2. Port Audio Digital
Lihat Pasal 2.2.1 untuk mengetahui persyaratan khusus perangkat.
7.8.3. Dekat Ultrasonik
Audio Near-Ultrasonik adalah pita 18,5 kHz hingga 20 kHz.
Implementasi perangkat:
- HARUS melaporkan dukungan dengan benar kemampuan audio yang mendekati ultrasonik 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] Sinyal tertimbang mikrofon terhadap rasio kebisingan lebih dari 18,5 kHz hingga 20 kHz untuk nada 19 kHz pada -26 dBFS HARUS tidak lebih rendah dari 50 dB.
Jika PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND
adalah "benar":
- [C-2-1] Respon rata-rata speaker dalam rentang 18,5 kHz - 20 kHz HARUS tidak lebih rendah dari 40 dB di bawah respons pada 2 kHz.
7.8.4. Integritas Sinyal
Implementasi perangkat:
- HARUS menyediakan jalur sinyal audio bebas gangguan untuk kedua input dan output di perangkat genggam, seperti yang didefinisikan oleh nol gangguan yang diukur selama pengujian selama satu menit per jalur. Menguji menggunakan OboeTester "Pengujian Glitch Otomatis".
Pengujian ini memerlukan dongle loopback audio, digunakan langsung dalam colokan 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 gangguan menggunakan AAudio:
Mode Performa | Berbagi | Frekuensi Sampel Keluar | Dalam Chans | Channel Keluar |
---|---|---|---|---|
RENDAH_LATENSI | EKSKLUSIF | BELUM DITENTUKAN | 1 | 2 |
RENDAH_LATENSI | EKSKLUSIF | BELUM DITENTUKAN | 2 | 1 |
RENDAH_LATENSI | DIBAGIKAN | BELUM DITENTUKAN | 1 | 2 |
RENDAH_LATENSI | DIBAGIKAN | BELUM DITENTUKAN | 2 | 1 |
TIDAK ADA | DIBAGIKAN | 48000 | 1 | 2 |
TIDAK ADA | DIBAGIKAN | 48000 | 2 | 1 |
TIDAK ADA | DIBAGIKAN | 44100 | 1 | 2 |
TIDAK ADA | DIBAGIKAN | 44100 | 2 | 1 |
TIDAK ADA | DIBAGIKAN | 16000 | 1 | 2 |
TIDAK ADA | DIBAGIKAN | 16000 | 2 | 1 |
Aliran data andal SEHARUSNYA memenuhi kriteria berikut untuk Sinyal Kebisingan Ratio (SNR) dan Total Harmonic Distortion (THD) untuk sinus 2000 Hz.
Transduser | THD | SNR |
---|---|---|
speaker bawaan utama, diukur menggunakan mikrofon referensi eksternal | < 3,0% | >= 50 dB |
mikrofon bawaan utama, diukur menggunakan speaker referensi eksternal | < 3,0% | >= 50 dB |
colokan analog 3,5 mm bawaan, diuji menggunakan adaptor loopback | < 1% | >= 60 dB |
Adaptor USB yang disertakan dengan ponsel, diuji menggunakan adaptor loopback | < 1,0% | >= 60 dB |
7.9. Virtual Reality
Android menyertakan API dan fasilitas untuk membangun "Virtual Reality" (VR) aplikasi, termasuk pengalaman VR seluler berkualitas tinggi. 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 stereoskopis notifikasi dan menonaktifkan komponen UI sistem monokular, sementara 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 menerapkan
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 ekspos ekstensi dalam daftar ekstensi EGL yang tersedia. - [C-1-8] HARUS menerapkan
GL_EXT_multisampled_render_to_texture2
,GL_OVR_multiview
,GL_OVR_multiview2
,GL_EXT_protected_textures
, dan menampilkan ekstensi dalam daftar ekstensi GL yang tersedia. - [C-SR-1] SANGAT DIREKOMENDASIKAN untuk diimplementasikan
GL_EXT_external_buffer
,GL_EXT_EGL_image_array
,GL_OVR_multiview_multisampled_render_to_texture
, dan menampilkan ekstensi dalam daftar ekstensi GL yang tersedia. - [C-SR-2] SANGAT DIREKOMENDASIKAN untuk mendukung Vulkan 1.1.
- [C-SR-3] SANGAT DIREKOMENDASIKAN untuk diimplementasikan
VK_ANDROID_external_memory_android_hardware_buffer
,VK_GOOGLE_display_timing
,VK_KHR_shared_presentable_image
, dan menampilkannya dalam daftar ekstensi Vulkan yang tersedia. - [C-SR-4] SANGAT DIREKOMENDASIKAN untuk mengekspos setidaknya satu kelompok antrean Vulkan tempat
flags
berisiVK_QUEUE_GRAPHICS_BIT
danVK_QUEUE_COMPUTE_BIT
, danqueueCount
setidaknya 2. - [C-1-7] GPU dan layar HARUS dapat menyinkronkan akses ke GPU buffer depan sehingga rendering konten VR alternatif pada 60 fps dengan dua konteks render akan ditampilkan tanpa artefak sobekan yang terlihat.
- [C-1-9] HARUS mengimplementasikan dukungan untuk
AHardwareBuffer
menandaiAHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER
,AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA
danAHARDWAREBUFFER_USAGE_PROTECTED_CONTENT
seperti yang dijelaskan dalam NDK. - [C-1-10] HARUS mengimplementasikan 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 DIREKOMENDASIKAN untuk mendukung alokasi
AHardwareBuffer
dengan lebih dari satu lapisan dan penanda serta format yang ditentukan dalam C-1-10. - [C-1-11] HARUS mendukung decoding H.264 setidaknya 3840 x 2160 pada 30 fps, dikompresi ke rata-rata 40Mbps (setara dengan 4 instance 1920 x1080 pada 30 fps-10 Mbps atau 2 instance dari 1920 x 1080 pada 60 fps-20 Mbps).
- [C-1-12] HARUS mendukung HEVC dan VP9, minimal harus dapat mendekode 1920 x 1080 pada 30 fps dikompresi hingga rata-rata 10 Mbps dan HARUS mampu mendekode 3840 x 2160 pada 30 fps-20 Mbps (setara dengan 4 instance 1920 x 1080 pada 30 fps-5 Mbps).
- [C-1-13] HARUS mendukung
HardwarePropertiesManager.getDeviceTemperatures
API dan mengembalikan nilai yang akurat untuk suhu kulit. - [C-1-14] HARUS memiliki layar yang tertanam, dan resolusinya minimal HARUS memiliki 1920 x 1080.
- [C-SR-6] SANGAT DIREKOMENDASIKAN untuk memiliki resolusi layar minimal 2560 x 1440.
- [C-1-15] Layar HARUS diperbarui minimal 60 Hz saat berada dalam Mode VR.
- [C-1-17] Layar HARUS mendukung mode persistensi rendah dengan ≤ 5 milidetik persistensi, persistensi didefinisikan sebagai jumlah waktu yaitu sebuah piksel yang memancarkan cahaya.
- [C-1-18] HARUS mendukung Ekstensi Panjang Data Bluetooth 4.2 dan Bluetooth LE pasal 7.4.3.
- [C-1-19] HARUS memberikan dukungan dan melaporkan dengan benar
Jenis Saluran Langsung
untuk semua jenis sensor default berikut:
TYPE_ACCELEROMETER
TYPE_ACCELEROMETER_UNCALIBRATED
TYPE_GYROSCOPE
TYPE_GYROSCOPE_UNCALIBRATED
TYPE_MAGNETIC_FIELD
TYPE_MAGNETIC_FIELD_UNCALIBRATED
- [C-SR-7] SANGAT DIREKOMENDASIKAN untuk mendukung
TYPE_HARDWARE_BUFFER
jenis saluran langsung untuk semua Jenis Saluran Langsung yang tercantum di atas. - [C-1-21] HARUS memenuhi persyaratan terkait giroskop, akselerometer, dan magnetometer
persyaratan untuk
android.hardware.hifi_sensors
, sebagaimana ditentukan dalam pasal 7.3.9. - [C-SR-8] SANGAT DIREKOMENDASIKAN untuk mendukung
android.hardware.sensor.hifi_sensors
. - [C-1-22] HARUS memiliki gerakan end-to-end ke latensi foton tidak lebih tinggi dari 28 milidetik.
- [C-SR-9] SANGAT DIREKOMENDASIKAN untuk memiliki gerakan end-to-end terhadap latensi foton tidak lebih dari 20 milidetik.
- [C-1-23] HARUS memiliki rasio frame pertama, yang merupakan rasio antara kecerahan piksel pada {i>frame<i} pertama setelah transisi dari hitam ke putih dan kecerahan piksel putih dalam keadaan stabil, minimal 85%.
- [C-SR-10] SANGAT DIREKOMENDASIKAN untuk memiliki rasio frame pertama minimal 90%.
- DAPAT memberikan core eksklusif di latar depan
aplikasi dan MUNGKIN mendukung API
Process.getExclusiveCores
untuk ditampilkan jumlah inti cpu yang eksklusif untuk latar depan atas aplikasi.
Jika inti eksklusif didukung, maka inti:
- [C-2-1] HARUS tidak mengizinkan proses userspace lainnya untuk berjalan di dalamnya (kecuali {i>driver <i}perangkat yang digunakan oleh aplikasi), namun MUNGKIN mengizinkan beberapa {i>kernel<i} proses untuk berjalan sesuai kebutuhan.
7.10. Sentuhan
Perangkat yang ditujukan untuk digenggam atau dipakai dapat mencakup fitur haptic tujuan umum aktuator, tersedia untuk aplikasi untuk tujuan termasuk menarik perhatian melalui nada dering, alarm, pemberitahuan, serta umpan balik sentuh umum.
Jika implementasi perangkat TIDAK menyertakan aktuator haptik tujuan umum tersebut, mereka:
- [7.10/C] HARUS menampilkan nilai salah untuk
Vibrator.hasVibrator()
.
Jika implementasi perangkat JANGAN sertakan setidaknya satu haptic tujuan umum tersebut aktuator, mereka:
- [C-1-1] HARUS menampilkan true untuk
Vibrator.hasVibrator()
. - TIDAK BOLEH menggunakan aktuator haptik (vibrator) massa berputar eksentrik (ERM).
- HARUS mengimplementasikan semua konstanta publik untuk haptic yang jelas
dalam
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 haptic yang jelas
dalam
android.os.VibrationEffect
yaitu (EFFECT_TICK
,EFFECT_CLICK
,EFFECT_HEAVY_CLICK
, danEFFECT_DOUBLE_CLICK
) dan semua konstantaPRIMITIVE_*
publik yang layak untuk haptic 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 memungkinkan jika vibrator dapat mendukung performa yang relatif rendah dengan frekuensi yang sama. - HARUS mengikuti panduan untuk memetakan konstanta publik
dalam
android.view.HapticFeedbackConstants
keandroid.os.VibrationEffect
yang direkomendasikan , dengan hubungan amplitudo yang sesuai. - HARUS menggunakan pemetaan haptic yang ditautkan ini.
- HARUS mengikuti penilaian kualitas
untuk
createOneShot()
dancreateWaveform()
Google Cloud Platform. - HARUS memverifikasi bahwa hasil dari permintaan publik
android.os.Vibrator.hasAmplitudeControl()
API mencerminkan kemampuan vibrator-nya 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
android.os.Vibrator.areAllEffectsSupported()
danandroid.os.Vibrator.arePrimitivesSupported()
Google Cloud Platform. - HARUS melakukan penilaian kualitas untuk konstanta haptic.
- HARUS memverifikasi dan memperbarui konfigurasi penggantian untuk sistem dasar yang tidak didukung seperti yang dijelaskan dalam panduan penerapan untuk konstanta.
- HARUS memberikan dukungan penggantian untuk mengurangi risiko kegagalan seperti yang dijelaskan di sini.
7.11. Class Performa Media
Kelas kinerja media dari implementasi perangkat dapat diperoleh dari
API android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
. Persyaratan
untuk class performa media ditentukan untuk setiap versi Android,
R (versi 30). Nilai khusus 0 menunjukkan bahwa perangkat bukan milik
class performa media tersebut.
Jika implementasi perangkat mengembalikan nilai
bukan nol untuk
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, ini:
[C-1-1] HARUS menampilkan setidaknya nilai
android.os.Build.VERSION_CODES.R
.[C-1-2] HARUS merupakan implementasi perangkat genggam.
[C-1-3] HARUS memenuhi semua persyaratan untuk "Media Performance Class" 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 perangkat tertentu lainnya.
8. Performa dan Kekuatan
Beberapa kriteria performa dan daya minimum sangat penting untuk pengalaman pengguna dan memengaruhi asumsi dasar pengukuran yang akan dimiliki developer saat mengembangkan .
8.1. Konsistensi Pengalaman Pengguna
Antarmuka pengguna yang mulus dapat diberikan kepada pengguna akhir jika ada persyaratan minimum untuk memastikan kecepatan frame dan waktu respons yang konsisten aplikasi dan game. Implementasi perangkat, tergantung pada jenis perangkat, MUNGKIN memiliki persyaratan yang terukur untuk latensi dan tugas antarmuka pengguna peralihan seperti yang dijelaskan di bagian 2.
8.2. Performa Akses I/O File
Memberikan dasar umum untuk performa akses file yang konsisten di
penyimpanan data pribadi aplikasi (partisi /data
) memungkinkan developer aplikasi
untuk menetapkan ekspektasi yang sesuai guna
membantu mereka dalam mendesain perangkat lunak. Perangkat
implementasinya, bergantung pada jenis perangkat, MUNGKIN memiliki persyaratan tertentu
yang dijelaskan di bagian 2 untuk bacaan berikut
dan operasi tulis:
- Performa operasi tulis berurutan. Diukur dengan menulis file berukuran 256 MB menggunakan Buffering tulis sebesar 10 MB.
- Performa penulisan acak. Diukur dengan menulis file 256 MB menggunakan 4 KB buffer tulis.
- Performa pembacaan berurutan. Diukur dengan membaca file 256 MB menggunakan Buffering tulis sebesar 10 MB.
- Performa baca acak. Diukur dengan membaca file 256 MB menggunakan 4 KB buffer tulis.
8.3. Mode Hemat Daya
Apakah implementasi perangkat menyertakan fitur untuk meningkatkan pengelolaan daya perangkat yang disertakan dalam AOSP (misalnya, Bucket Aplikasi Standby, Istirahatkan) atau memperluas fitur untuk menerapkan pembatasan yang lebih kuat daripada Bucket Aplikasi Standby yang DIBATASI, yaitu:
- [C-1-1] TIDAK BOLEH menyimpang dari implementasi AOSP untuk memicu, pemeliharaan, algoritma bangun, dan penggunaan pengaturan sistem global atau DeviceConfig mode hemat daya Aplikasi Standby dan Istirahatkan.
- [C-1-2] TIDAK BOLEH menyimpang dari implementasi AOSP untuk penggunaan pengaturan atau DeviceConfig untuk mengelola throttling tugas, alarm, dan jaringan aplikasi di setiap bucket untuk Aplikasi standby.
- [C-1-3] TIDAK BOLEH menyimpang dari implementasi AOSP untuk jumlah Bucket Aplikasi Standby digunakan untuk Aplikasi Standby.
- [C-1-4] HARUS menerapkan Bucket Aplikasi Standby dan Istirahatkan seperti yang dijelaskan dalam Pengelolaan Daya.
- [C-1-5] HARUS mengembalikan
true
untukPowerManager.isPowerSaveMode()
saat perangkat dalam mode hemat daya. - [C-1-6] HARUS memberikan affordance pengguna untuk menampilkan semua aplikasi yang dikecualikan dari mode hemat daya Aplikasi Standby dan Istirahatkan atau pengoptimalan baterai apa pun dan HARUS menerapkan ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS maksud untuk meminta pengguna mengizinkan aplikasi mengabaikan baterai pengoptimalan.
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menyediakan kemampuan pengguna dalam mengaktifkan dan menonaktifkan fitur penghemat baterai.
- [C-SR-2] SANGAT DIREKOMENDASIKAN untuk menyediakan kemampuan pengguna dalam menampilkan semua aplikasi yang dikecualikan dari mode hemat daya Aplikasi Standby dan Istirahatkan.
Jika implementasi perangkat memperluas fitur pengelolaan daya yang disertakan dalam AOSP dan ekstensi itu menerapkan pembatasan yang lebih ketat daripada Bucket Aplikasi Standby Langka, lihat bagian 3.5.1.
Selain mode hemat daya, implementasi perangkat Android MUNGKIN mengimplementasikan salah satu atau semua 4 status daya tidur seperti yang didefinisikan oleh Konfigurasi dan Antarmuka Daya (ACPI).
Jika implementasi perangkat menerapkan status daya S4 seperti yang ditentukan oleh ACPI, mereka:
- [C-1-1] HARUS memasuki status ini hanya setelah pengguna melakukan tindakan yang jelas untuk menempatkan perangkat dalam keadaan tidak aktif (mis. dengan menutup penutup yang sebagian perangkat atau mematikan kendaraan atau televisi) dan sebelum pengguna mengaktifkan kembali perangkat (misalnya dengan membuka penutup atau memutar kendaraan atau televisi kembali menyala).
Jika implementasi perangkat menerapkan status daya S3 seperti yang ditentukan oleh ACPI, mereka:
[C-2-1] HARUS memenuhi C-1-1 di atas, atau, HARUS memasuki status S3 hanya jika pihak ketiga aplikasi tidak memerlukan sumber daya sistem (misalnya layar, CPU).
Sebaliknya, HARUS keluar dari status S3 ketika aplikasi pihak ketiga memerlukan resource sistem, seperti yang dijelaskan dalam SDK ini.
Misalnya, saat aplikasi pihak ketiga meminta untuk mempertahankan layar sampai
FLAG_KEEP_SCREEN_ON
atau biarkan CPU tetap berjalanPARTIAL_WAKE_LOCK
, perangkat TIDAK BOLEH memasuki status S3 kecuali, sebagaimana dijelaskan di C-1-1, pengguna telah mengambil tindakan eksplisit untuk menempatkan perangkat di status tidak aktif. Sebaliknya, pada saat tugas yang dilakukan oleh aplikasi pihak ketiga terapkan melalui JobScheduler akan dipicu atau Firebase Cloud Messaging dikirim ke aplikasi pihak ketiga, perangkat HARUS keluar dari status S3 kecuali telah menetapkan perangkat dalam status tidak aktif. Pernyataan ini tidak komprehensif dan AOSP menerapkan sinyal bangun ekstensif yang memicu bangun dari status ini.
8.4. Akuntansi Pemakaian Daya
Pencatatan dan pelaporan konsumsi daya yang lebih akurat memberikan developer aplikasi baik insentif maupun alat untuk mengoptimalkan penggunaan daya listrik yang sesuai dengan pola aplikasi.
Implementasi perangkat:
- [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menyediakan profil daya per komponen yang menentukan nilai konsumsi saat ini untuk setiap komponen perangkat keras dan perkiraan pengurasan baterai yang disebabkan oleh dari waktu ke waktu seperti yang didokumentasikan di situs Proyek Open Source Android.
- [C-SR-2] SANGAT DIREKOMENDASIKAN untuk melaporkan semua nilai konsumsi daya dalam miliampere jam (mAh).
- [C-SR-3] SANGAT DIREKOMENDASIKAN untuk melaporkan konsumsi daya CPU per UID setiap proses.
Proyek Open Source Android memenuhi persyaratan melalui
Implementasi modul kernel
uid_cputime
. - [C-SR-4] SANGAT DIREKOMENDASIKAN untuk membuat penggunaan daya ini tersedia melalui
adb shell dumpsys batterystats
perintah shell kepada developer aplikasi. - HARUS dikaitkan dengan komponen perangkat keras itu sendiri jika tidak dapat atribut penggunaan daya komponen perangkat keras ke aplikasi.
8.5. Performa yang Konsisten
Kinerja dapat berfluktuasi secara dramatis untuk aplikasi berperforma tinggi yang berjalan lama, baik karena aplikasi lain berjalan di latar belakang atau throttling CPU karena adanya batas suhu. Android menyertakan antarmuka terprogram sehingga saat kemampuan perangkat, aplikasi latar depan atas dapat meminta agar mengoptimalkan alokasi sumber daya untuk mengatasi fluktuasi tersebut.
Implementasi perangkat:
[C-0-1] HARUS melaporkan dukungan Mode Performa Berkelanjutan secara akurat melalui
PowerManager.isSustainedPerformanceModeSupported()
Metode API.SEHARUSNYA mendukung Mode Performa Berkelanjutan.
Jika implementasi perangkat melaporkan dukungan Mode Performa Berkelanjutan, implementasi tersebut:
- [C-1-1] HARUS menyediakan aplikasi latar depan tingkat atas dengan tingkat selama minimal 30 menit, saat aplikasi memintanya.
- [C-1-2] HARUS menghormati
Window.setSustainedPerformanceMode()
API dan API terkait lainnya.
Jika implementasi perangkat menyertakan dua core CPU atau lebih, implementasi tersebut:
- HARUS menyediakan setidaknya satu inti eksklusif yang dapat dipesan oleh bagian atas aplikasi latar depan.
Jika implementasi perangkat mendukung reservasi satu inti eksklusif untuk yang teratas aplikasi latar depan, mereka:
- [C-2-1] HARUS melaporkan melalui
Process.getExclusiveCores()
Metode API nomor ID dari core eksklusif yang dapat dipesan oleh aplikasi latar depan atas. - [C-2-2] HARUS tidak mengizinkan proses ruang pengguna apa pun kecuali driver perangkat digunakan oleh aplikasi untuk dijalankan pada inti eksklusif, tetapi MUNGKIN memungkinkan beberapa proses {i>kernel<i} untuk berjalan sesuai kebutuhan.
Jika implementasi perangkat tidak mendukung inti eksklusif, implementasi tersebut:
- [C-3-1] HARUS mengembalikan daftar kosong melalui
Process.getExclusiveCores()
Metode API.
9. Kompatibilitas Model Keamanan
Implementasi perangkat:
[C-0-1] HARUS menerapkan model keamanan yang konsisten dengan model keamanan platform Android seperti yang dijelaskan dalam Dokumen referensi Keamanan dan Izin di API di dokumentasi developer Android.
[C-0-2] HARUS mendukung penginstalan software yang ditandatangani sendiri aplikasi tanpa memerlukan izin/sertifikat tambahan dari pihak ketiga/otoritas.
Jika implementasi perangkat mendeklarasikan android.hardware.security.model.compatible
tersebut, mereka:
- [C-1-1] HARUS mendukung persyaratan yang tercantum dalam subpasal berikut.
9.1. Izin
Implementasi perangkat:
[C-0-1] HARUS mendukung model izin Android dan Model Peran Android seperti yang dijelaskan dalam dokumentasi developer Android. Secara khusus, mereka HARUS memberlakukan setiap izin dan peran yang didefinisikan sebagaimana dijelaskan dalam Dokumentasi SDK; tidak ada izin dan tidak ada peran yang dapat dihilangkan, diubah, atau diabaikan.
MUNGKIN menambahkan izin tambahan, asalkan string ID izin baru tidak ada dalam namespace
android.\*
.[C-0-2] Izin dengan
protectionLevel
PROTECTION_FLAG_PRIVILEGED
HARUS diberikan hanya ke aplikasi yang diprainstal di jalur dengan hak istimewa dari image sistem (serta file APEX) dan dalam subkumpulan izin yang diizinkan secara eksplisit untuk setiap aplikasi. Implementasi AOSP memenuhi persyaratan ini dengan membaca dan mematuhi daftar izin akses yang diizinkan untuk setiap aplikasi dari file di Jaluretc/permissions/
dan menggunakan jalursystem/priv-app
sebagai jalur hak istimewa.
Memulai persyaratan baru untuk 15 (Eksperimental AOSP)
[C-SR-1] Izin dengan
protectionLevel
dariPROTECTION_SIGNATURE
SANGAT DIREKOMENDASIKAN untuk hanya diberikan kepada:- Aplikasi yang telah diinstal lebih dulu pada image sistem (serta File APEX).
- Aplikasi yang diizinkan dengan izin yang diizinkan jika tidak disertakan dalam image sistem.
Mengakhiri persyaratan baru
Izin dengan tingkat perlindungan berbahaya adalah izin runtime.
Aplikasi dengan targetSdkVersion
> 22 meminta mereka saat runtime.
Implementasi perangkat:
[C-0-3] HARUS menunjukkan antarmuka khusus bagi pengguna untuk memutuskan apakah akan memberikan izin runtime yang diminta dan juga menyediakan antarmuka bagi pengguna untuk mengelola izin runtime.
[C-0-5] TIDAK BOLEH memberikan izin runtime apa pun ke aplikasi kecuali:
- Alat ini diinstal pada saat pengiriman perangkat, DAN
Izin pengguna dapat diperoleh sebelum aplikasi menggunakan izin akses,
ATAU
Izin runtime diberikan oleh kebijakan pemberian izin default atau memiliki peran platform.
[C-0-6] HARUS memberikan izin ke
android.permission.RECOVER_KEYSTORE
hanya untuk aplikasi sistem yang mendaftarkan Agen Pemulihan yang diamankan dengan benar. J Agen Pemulihan yang diamankan dengan benar didefinisikan sebagai agen software di perangkat yang disinkronkan dengan penyimpanan jarak jauh di luar perangkat, yang dilengkapi dengan perangkat keras aman dengan perlindungan yang setara atau lebih kuat dijelaskan dalam Google Cloud Key Vault Service untuk mencegah serangan {i>brute force<i} pada faktor pengetahuan layar kunci.
Implementasi perangkat:
[C-0-7] HARUS mematuhi properti izin akses lokasi Android saat aplikasi meminta data lokasi atau aktivitas fisik melalui Android API standar atau mekanisme eksklusif. Data tersebut mencakup, tetapi tidak terbatas pada:
- Lokasi perangkat (mis. lintang dan bujur) seperti yang dijelaskan di pasal 9.8.8.
- Informasi yang dapat digunakan untuk menentukan atau memperkirakan daya perangk