Definisi Kompatibilitas Android 13

1. Pengantar

Dokumen ini menguraikan persyaratan yang harus dipenuhi agar perangkat dapat digunakan agar kompatibel dengan Android 13.

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 13. "Implementasi perangkat" atau "implementasi" adalah solusi perangkat keras/perangkat lunak yang dikembangkan.

Agar dianggap kompatibel dengan Android 13, 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 tanggung jawab implementasi perangkat adalah 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 kisaran 3,3 inci (atau 2,5 inci untuk implementasi perangkat yang dikirimkan pada API level 29 atau sebelumnya) menjadi 8 inci.

Persyaratan tambahan di bagian selanjutnya ini khusus untuk Android Implementasi perangkat genggam.

Catatan: Persyaratan yang tidak berlaku untuk perangkat Tablet Android ditandai dengan *.

2.2.1. Hardware

Implementasi perangkat genggam:

  • [7.1.1.1/H-0-1] HARUS memiliki minimal satu Layar yang kompatibel dengan Android yang memenuhi semua persyaratan yang dijelaskan dalam dokumen.

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

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

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

Jika implementasi perangkat genggam tidak mendukung rotasi layar perangkat lunak, mereka:

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

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, dan VK_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:

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 lama KEYCODE_MEDIA_PLAY_PAUSE atau KEYCODE_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.
  • [7.4.3/H] SEHARUSNYA menyertakan dukungan untuk Bluetooth dan Bluetooth LE.

Jika perangkat mendukung protokol WiFi Neighbor Awareness Networking (NAN) dengan mendeklarasikan PackageManager.FEATURE_WIFI_AWARE dan Lokasi Wi-Fi (Wi-Fi 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 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 suhunya HARUS antara 50 dan 95 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 resolusi 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.

Jika implementasi perangkat genggam menyertakan port USB yang mendukung periferal tersebut, mereka:

  • [7.7.1/H-1-1] HARUS menerapkan Android Open Accessory (AOA) Compute Engine API.

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

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

  • [5.6/H-1-1] HARUS memiliki Perjalanan bolak-balik Berkelanjutan Rata-rata latensi 500 md atau kurang dari 5 pengukuran, dengan Deviasi Absolut Rata-rata kurang dari 50 md, pada jalur data berikut: "speaker ke mikrofon", Adaptor loopback 3,5 mm (jika didukung), loopback USB (jika didukung).

  • [5.6/H-1-2] HARUS memiliki latensi Ketuk untuk nada rata-rata 500 milidetik atau kurang pada setidaknya 5 pengukuran di atas speaker ke jalur data mikrofon.

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

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 minimal satu resonan linear aktuator, mereka:

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

Jika implementasi perangkat genggam memiliki aktuator haptic yang berupa sumbu X {i>linear resonant Actuator<i} (LRA), yaitu aktuator:

  • [7.10/H]* SEHARUSNYA memiliki frekuensi resonansi sumbu X LRA di bawah 200 Hz.

Jika implementasi perangkat genggam mengikuti pemetaan konstanta haptic, implementasi tersebut:

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:

  • [5,2/H-0-1] AVC H.264
  • [5,2/H-0-2] VP8

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

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, dan ACTION_CREATE_DOCUMENT seperti yang dijelaskan dalam dokumen SDK, dan memberikan kemampuan pengguna untuk mengakses data penyedia dokumen dengan menggunakan DocumentsProvider 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 dan NotificationManager 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 sebagai true sebaris dengan balasan yang ditampilkan oleh Notification.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 notifikasi MediaStyle dengan token MediaSession.

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 mengimplementasikan VoiceInteractionService , atau aktivitas yang menangani intent ACTION_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 ke true.
  • [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 dan Control 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 oleh Control 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 dan Control Control.isAuthRequired API.

Sebaliknya, jika implementasi perangkat genggam tidak menerapkan kontrol tersebut, mereka:

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 pemberitahuan “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:

Jika aplikasi setelan pada implementasi perangkat genggam mengimplementasikan fungsi pemisahan, menggunakan penyematan aktivitas, maka mereka:

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:

Implementasi perangkat genggam:

  • [8.5/H-0-1] HARUS memberikan kemampuan pengguna di menu Setelan dengan kemampuan untuk menghentikan aplikasi yang berjalan di latar depan dan menampilkan semua aplikasi yang memiliki layanan latar depan aktif dan dari setiap layanan ini sejak dimulai seperti yang dijelaskan dalam SDK dokumen.
    • Beberapa aplikasi DAPAT dikecualikan agar tidak dihentikan atau dicantumkan dalam kemampuan pengguna seperti yang dijelaskan dalam dokumen SDK.

2.2.5. Model Keamanan

Implementasi perangkat genggam:

  • [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 memberikan atau mencabut akses ke aplikasi tersebut dalam respons terhadap android.settings.ACTION_USAGE_ACCESS_SETTINGS intent.

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, SHA1, 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.
  • [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 di sejumlah perangkat yang cukup besar untuk mencegah kunci digunakan sebagai ID perangkat. Salah satu cara untuk memenuhi persyaratan ini adalah dengan membagikan kunci pengesahan yang sama kecuali jika setidaknya 100.000 unit SKU tertentu diproduksi. Jika lebih dari 100.000 unit SKU diproduksi, DASAR MUNGKIN digunakan untuk setiap 100.000 unit.
  • [9/H-0-1] HARUS mendeklarasikan 'android.hardware.security.model.compatible' aplikasi 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 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.

Android, melalui System API VoiceInteractionService mendukung mekanisme untuk deteksi frasa pengaktif selalu aktif tanpa indikasi akses mikrofon

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 atau ContentCaptureService
  • [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 ke ContentCaptureService melalui API ContentCaptureManager.
  • [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 non-audio ditransmisikan keluar dari layanan pendeteksian frasa pengaktif pada setiap frasa pengaktif yang berhasil hasil pengujian tersebut.
  • [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 berhasil ditransmisikan ke suara layanan interaksi atau entitas serupa.
  • [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.

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.

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.

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.

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 diterima 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 memberikan, 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 sistem persist.traced.enable).

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.S untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, maka mereka:

  • HARUS memenuhi persyaratan media yang tercantum di CDD Android 12 bagian 2.2.7.1.

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

  • [5.1/H-1-1] HARUS mengiklankan jumlah maksimum hardware video decoder sesi yang dapat dijalankan secara bersamaan dalam kombinasi codec apa pun melalui CodecCapabilities.getMaxSupportedInstances() dan VideoCapabilities.getSupportedPerformancePoints().
  • [5.1/H-1-2] HARUS mendukung 6 instance sesi decoder video hardware (AVC, HEVC, VP9, AV1, atau yang lebih baru) dalam semua kombinasi codec yang berjalan secara serentak pada resolusi 1080p@30 fps.
  • [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 VideoCapabilities.getSupportedPerformancePoints().
  • [5.1/H-1-4] HARUS mendukung 6 instance hardware video encoder sesi (AVC, HEVC, VP9, AV1, atau yang lebih baru) dalam kombinasi codec apa pun yang berjalan secara serentak pada resolusi 1080p@30fps.
  • [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 VideoCapabilities.getSupportedPerformancePoints().
  • [5.1/H-1-6] HARUS mendukung 6 instance hardware video decoder dan hardware sesi encoder video (AVC, HEVC, VP9, AV1, atau yang lebih baru) dalam codec apa pun dan kombinasi berjalan bersamaan dengan resolusi 1080p@30fps.
  • [5.1/H-1-7] HARUS memiliki latensi inisialisasi codec 40 md atau kurang untuk Sesi encoding video 1080p atau lebih kecil untuk semua encoder video hardware saat dalam keadaan termuat. Muatan di sini didefinisikan sebagai 1080p hingga 720p serentak sesi transcoding video saja menggunakan codec video hardware bersama dengan Inisialisasi perekaman audio-video 1080p. Untuk codec Dolby Vision, latensi inisialisasi codec HARUS 50 md atau kurang.
  • [5.1/H-1-8] HARUS memiliki latensi inisialisasi codec 30 md atau kurang untuk Sesi encoding audio dengan kecepatan bit 128 kbps atau lebih rendah untuk semua encoder audio saat 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.
  • [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 serentak pada resolusi 1080p@30 fps.
  • [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 pada resolusi 1080p@30 fps.
  • [5.1/ H-1-11] HARUS mendukung decoder aman untuk setiap hardware AVC, HEVC, decoder VP9 atau 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.
  • [5.1/H-1-14] HARUS mendukung decoder hardware AV1 Main 10, Level 4.1.
  • [5.1/H-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung Film Grain untuk hardware AV1 decoder.
  • [5.1/H-1-15] HARUS memiliki setidaknya 1 hardware video decoder yang mendukung 4K60.
  • [5.1/H-1-16] HARUS memiliki minimal 1 encoder video hardware yang mendukung 4K60.
  • [5.3/H-1-1] TIDAK BOLEH menjatuhkan lebih dari 1 frame dalam 10 detik (yaitu kurang dari 0,167 persen penurunan frame) untuk sesi video 1080p 60 fps dengan beban. Pemuatan didefinisikan sebagai video 1080p hingga 720p saja sesi transcoding menggunakan codec video hardware, serta Pemutaran audio AAC 128 kbps.
  • [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. Beban didefinisikan sebagai sesi transcoding video 1080p hingga 720p saja menggunakan hardware codec video, serta pemutaran audio AAC 128 kbps.
  • [5.6/H-1-1] HARUS memiliki latensi ketuk untuk nada 80 milidetik atau kurang menggunakan uji ketuk untuk nada OboeTester atau uji ketuk untuk nada CTS Verifier.
  • [5.6/H-1-2] HARUS memiliki latensi audio bolak-balik 80 milidetik atau kurang pada minimal 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 melalui keseluruhan jalur data untuk konfigurasi streaming dan latensi rendah. Untuk yang rendah konfigurasi latensi rendah, AAudio harus digunakan oleh aplikasi pada latensi rendah mode callback. Untuk streaming , Java AudioTrack harus digunakan oleh aplikasi. Baik dalam konfigurasi streaming dan latensi, sink output HAL harus menerima baik AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED, AUDIO_FORMAT_PCM_32_BIT atau AUDIO_FORMAT_PCM_FLOAT untuk output targetnya format font.
  • [5.6/H-1-4] HARUS mendukung >= 4 channel perangkat audio USB (Ini digunakan oleh DJ pengontrol untuk melihat pratinjau lagu.)
  • [5.6/H-1-5] HARUS mendukung perangkat MIDI yang sesuai dengan kelas dan mendeklarasikan MIDI tombol fitur.
  • [5.7/H-1-2] HARUS mendukung MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL dengan kemampuan dekripsi konten di bawah.
Ukuran sampel minimum 4 MiB
Jumlah Minimum Subsampel - H264 atau HEVC 32
Jumlah Minimum Subsampel - VP9 9
Jumlah Minimum Subsampel - AV1 288
Ukuran buffer subsampel minimum 1 MiB
Ukuran buffer kripto umum minimum 500 KiB
Jumlah Minimum sesi serentak 30
Jumlah minimum kunci per sesi 20
Jumlah Total Kunci Minimum (semua sesi) 80
Jumlah Total Minimum Kunci DRM (semua sesi) 6
Ukuran Pesan 16 KiB
Frame yang Didekripsi per Detik 60 fps

2.2.7.2. Kamera

Jika implementasi Perangkat genggam menampilkan android.os.Build.VERSION_CODES.S untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, maka mereka:

  • HARUS memenuhi persyaratan kamera yang tercantum di Android 12 CDD pasal 2.2.7.2.

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

  • [7.5/H-1-1] HARUS memiliki kamera belakang utama dengan resolusi memiliki resolusi minimal 12 megapiksel yang mendukung perekaman video dengan kecepatan 4K@30 fps. Utama kamera belakang adalah kamera belakang dengan ID kamera terendah.
  • [7.5/H-1-2] HARUS memiliki kamera depan utama dengan resolusi dengan resolusi minimal 5 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 sebagai FULL atau lebih baik untuk primer belakang dan LIMITED atau lebih baik untuk primer depan kamera.
  • [7,5/H-1-4] HARUS mendukung CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME untuk kampanye utama kamera.
  • [7.5/H-1-5] HARUS memiliki latensi pengambilan JPEG camera2 < 1000 md untuk Resolusi 1080p yang diukur dengan PerformanceTest kamera CTS di bawah ITS kondisi pencahayaan (3000K) untuk kedua kamera utama.
  • [7.5/H-1-6] HARUS memiliki latensi pengaktifan kamera2 (buka kamera untuk 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 dan android.graphics.ImageFormat.RAW_SENSOR untuk kamera belakang utama.
  • [7.5/H-1-9] HARUS memiliki kamera utama hadap belakang yang mendukung 720p atau 1080p @ 240fps.
  • [7.5/H-1-10] HARUS punya 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 kamera belakang utama.
  • [7.5/H-1-13] HARUS mendukung kemampuan LOGICAL_MULTI_CAMERA untuk kamera belakang jika terdapat lebih dari 1 kamera belakang RGB.
  • [7.5/H-1-14] HARUS mendukung kemampuan STREAM_USE_CASE untuk keduanya kamera depan dan belakang utama.

2.2.7.3. Hardware

Jika implementasi Perangkat genggam menampilkan android.os.Build.VERSION_CODES.S untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, lalu mereka:

  • HARUS memenuhi persyaratan hardware yang tercantum di Android 12 CDD pasal 2.2.7.3.

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

  • [7.1.1.1/H-2-1] HARUS memiliki resolusi layar minimal 1080p.
  • [7.1.1.3/H-2-1] HARUS memiliki kepadatan layar minimal 400 dpi.
  • [7.6.1/H-2-1] HARUS memiliki memori fisik minimal 8 GB.

2.2.7.4. Performa

Jika implementasi Perangkat genggam menampilkan android.os.Build.VERSION_CODES.S untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, lalu mereka:

  • HARUS memenuhi persyaratan performa yang tercantum di CDD Android 12 pasal 2.2.7.4.

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

  • [8.2/H-1-1] HARUS memastikan performa operasi tulis sekuensial setidaknya 125 MB/dtk.
  • [8.2/H-1-2] HARUS memastikan performa tulis acak setidaknya 10 MB/s.
  • [8.2/H-1-3] HARUS memastikan performa baca berurutan setidaknya 250 MB/dtk.
  • [8.2/H-1-4] HARUS memastikan kinerja pembacaan acak setidaknya 40 MB/s.

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 output video, seperti VGA, HDMI, DisplayPort, 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:

  • [5,2/T-0-1] H.264
  • [5,2/T-0-2] VP8

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:

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 pilih resolusi maksimum yang dapat didukung dengan 50 Hz atau 60 Hz kecepatan refresh.
  • [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 dan android.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.

Implementasi perangkat televisi:

  • [3.12/T-0-1] HARUS mendukung Framework Input TV.

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:

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.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 kelompok MD5, SHA1, 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.
  • [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 di sejumlah perangkat yang cukup besar untuk mencegah kunci digunakan sebagai ID perangkat. Salah satu cara untuk memenuhi persyaratan ini adalah dengan membagikan kunci pengesahan yang sama kecuali jika setidaknya 100.000 unit SKU tertentu diproduksi. Jika lebih dari 100.000 unit SKU diproduksi, DASAR MUNGKIN digunakan untuk setiap 100.000 unit.
  • [9/T-0-1] HARUS mendeklarasikan 'android.hardware.security.model.compatible' aplikasi 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

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.

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

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.

  • [7.2.3/A-0-1] HARUS memberikan fungsi Home dan MUNGKIN menyediakan fungsi Back dan Recent.

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

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

  • [7.4.3/A-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung {i>Message Access Profile<i} (MAP).

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

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

Implementasi perangkat otomotif:

  • HARUS menyertakan satu atau beberapa kamera tampilan eksterior.

Jika implementasi perangkat Automotive menyertakan kamera tampilan eksterior, misalnya kamera, mereka:

  • [7.5/A-1-1] TIDAK BOLEH memiliki kamera tampilan eksterior yang dapat diakses melalui API Kamera Android, kecuali jika mematuhinya dengan persyaratan inti kamera.

  • [7.5/A-SR-1] SANGAT DIREKOMENDASIKAN untuk tidak merotasi atau mencerminkan pratinjau kamera secara horizontal.

  • [7.5/A-SR-2] SANGAT DIREKOMENDASIKAN untuk memiliki resolusi minimal 1,3 megapiksel.

  • HARUS memiliki hardware fokus tetap atau EDOF (kedalaman bidang yang diperluas).

  • MUNGKIN memiliki fokus otomatis hardware atau fokus otomatis software yang diimplementasikan {i>driver<i} kamera.

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

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

Implementasi perangkat otomotif:

  • MUNGKIN mencakup satu atau beberapa kamera yang tersedia untuk pihak ketiga menggunakan berbagai aplikasi obrolan.

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

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

Implementasi perangkat otomotif:

  • [7.6.1/A-0-1] HARUS memiliki minimal 4 GB penyimpanan non-volatil yang tersedia untuk data pribadi aplikasi (alias 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.

Jika implementasi perangkat Automotive adalah 64-bit:

  • [7.6.1/A-2-1] Memori yang tersedia untuk kernel dan userspace HARUS berukuran minimal 816 MB jika salah satu dari 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 userspace HARUS berukuran minimal 944 MB jika salah satu dari 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 userspace HARUS berukuran minimal 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

  • [7.6.1/A-2-4] Memori yang tersedia untuk kernel dan userspace HARUS berukuran minimal 1824 MB jika salah satu dari kepadatan berikut digunakan:

    • 560 dpi atau lebih tinggi pada layar kecil/normal
    • Layar besar 400 dpi atau lebih
    • 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.

Implementasi perangkat otomotif:

  • [7.7.1/A] HARUS menyertakan port USB yang mendukung mode periferal.

Implementasi perangkat otomotif:

  • [7.8.1/A-0-1] HARUS menyertakan mikrofon.

Implementasi perangkat otomotif:

  • [7.8.2/A-0-1] HARUS memiliki output audio dan mendeklarasikan android.hardware.audio.output.

2.5.2. Multimedia

Implementasi perangkat otomotif HARUS mendukung 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:

  • [5,2/A-0-1] AVC H.264
  • [5,2/A-0-2] VP8

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

  • [5,3/A-0-1] AVC H.264
  • [5,3/A-0-2] MPEG-4 SP
  • [5,3/A-0-3] VP8
  • [5,3/A-0-4] VP9

Implementasi perangkat otomotif SANGAT DIREKOMENDASIKAN untuk mendukung pendekodean video berikut:

  • [5.3/A-SR-1] HEVC H.265

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.

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

Implementasi perangkat otomotif:

Jika implementasi perangkat Automotive menyertakan aplikasi peluncur default, implementasi tersebut:

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 kernel uid_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:

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 memiliki peran yang disebutkan di Izin Pasal 9.1 dengan ID CDD [C-3-X].
  • [9.8.2/A-2-2] TIDAK BOLEH menyembunyikan indikator kamera untuk aplikasi sistem yang memiliki antarmuka pengguna yang terlihat atau interaksi pengguna langsung.

Implementasi perangkat otomotif:

  • [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 kelompok MD5, SHA1, 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.
  • [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 di sejumlah perangkat yang cukup besar untuk mencegah kunci digunakan sebagai ID perangkat. Salah satu cara untuk memenuhi persyaratan ini adalah dengan membagikan kunci pengesahan yang sama kecuali jika setidaknya 100.000 unit SKU tertentu diproduksi. Jika lebih dari 100.000 unit SKU diproduksi, DASAR MUNGKIN digunakan untuk setiap 100.000 unit.
  • [9/A-0-1] HARUS mendeklarasikan 'android.hardware.security.model.compatible' aplikasi 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

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.

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.

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

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 API terdokumentasi yang diekspos oleh Android SDK atau API apa pun yang dilengkapi dengan penanda “@SystemApi” 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.

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 layanan ExtServices 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> hingga org.apache.http.legacy.

Implementasi AOSP memenuhi persyaratan ini.

3.2. Kompatibilitas Soft API

Selain API terkelola dari bagian 3.1, Android juga menyertakan API "lunak" khusus runtime yang signifikan, 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 13.
VERSION.SDK Versi sistem Android yang saat ini dijalankan, dalam format dapat diakses oleh kode aplikasi pihak ketiga. Untuk Android 13, bidang ini HARUS memiliki nilai bilangan bulat 13_INT.
VERSION.SDK_INT Versi sistem Android yang saat ini dijalankan, dalam format dapat diakses oleh kode aplikasi pihak ketiga. Untuk Android 13, bidang ini HARUS memiliki nilai bilangan bulat 13_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 Nama kumpulan petunjuk (jenis CPU + konvensi ABI) native pada kode sumber. Lihat bagian 3.3. API Native Kompatibilitas.
SUPPORTED_32_BIT_ABIS Nama kumpulan petunjuk (jenis CPU + konvensi ABI) native pada kode sumber. Lihat bagian 3.3. API Native Kompatibilitas.
SUPPORTED_64_BIT_ABIS Nama kumpulan petunjuk kedua (jenis CPU + konvensi ABI) kode native 3D. Lihat bagian 3.3. Native Kompatibilitas API.
ABI_CPU 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)/
$(PERANGKAT):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)

Contoh:

acme/myproduct/
mydevice:13/LMYXX/3359:userdebug/test-keys

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_MANUFACTURER 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 dimulai 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.
SKU_ODM 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 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 Buletin Keamanan Publik Android atau dalam Android Security Advisory, misalnya "2015-11-01".
OS_BASIS 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, untuk 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 pengguna 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 menentukan URI data "http://www.android.com" lebih spesifik daripada pola maksud 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:

Jika implementasi perangkat melaporkan android.hardware.telephony.calling, implementasi tersebut:

Jika implementasi perangkat melaporkan android.hardware.nfc.hce, implementasi tersebut:

Jika implementasi perangkat melaporkan android.hardware.nfc, implementasi tersebut:

Jika implementasi perangkat melaporkan android.hardware.bluetooth, implementasi tersebut:

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:

Jika implementasi perangkat menyediakan mode penghemat data, implementasi tersebut:

Jika implementasi perangkat tidak menyediakan mode penghemat data, implementasi tersebut:

Jika implementasi perangkat mendeklarasikan dukungan untuk kamera melalui android.hardware.camera.any, ini:

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

Jika implementasi perangkat mendeklarasikan android.software.autofill tombol fitur, yaitu:

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.

  • [C-17-1] [Dipindahkan ke 2.2.3]

Jika implementasi perangkat mendukung VoiceInteractionService dan memiliki lebih banyak dari satu aplikasi yang menggunakan API ini yang diinstal pada satu waktu, mereka:

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.

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 Parameter android.os.Build.SUPPORTED_64_BIT_ABIS, masing-masing dipisahkan koma daftar ABI yang diurutkan dari yang paling banyak ke yang paling tidak disukai.

  • [C-0-6] HARUS melaporkan, melalui parameter di atas, subkumpulan hal berikut daftar ABI dan TIDAK BOLEH melaporkan ABI yang tidak ada dalam daftar.

  • [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 fungsi Vulkan 1.0 inti simbol, serta VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1, dan VK_KHR_get_physical_device_properties2 ekstensi melalui library libvulkan.so. Perhatikan bahwa meskipun semua simbol HARUS ada, 7.1.4.2 menjelaskan secara lebih rinci persyaratan ketika 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, sebagai armeabi 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 penghalang 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 13 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, IndexedDB 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 dan GnssNavigationMessage.
    • [C-0-5] mereka HARUS membatasi frekuensi update yang yang diberikan ke aplikasi melalui LocationManager Class API atau WifiManager.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 dalam 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-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 oleh Provider.getName()) dan class, kecuali jika aplikasi telah mengubah daftar melalui insertProviderAt() atau removeProvider(). Perangkat DAPAT menampilkan penyedia tambahan setelah daftar penyedia yang ditentukan di bawah ini.
    1. AndroidNSSP - android.security.net.config.NetworkSecurityConfigProvider
    2. AndroidOpenSSL - com.android.org.conscrypt.OpenSSLProvider
    3. CertPathProvider - sun.security.provider.CertPathProvider
    4. AndroidKeyStoreBCSolution - android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
    5. SM - com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
    6. HarmonyJSSE - com.android.org.conscrypt.JSSEProvider
    7. AndroidKeyStore - android.security.keystore.AndroidKeyStoreProvider

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 kesehatan sistem. Yang lain kriteria yang tidak sepenuhnya terkait dengan kesehatan sistem, seperti 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 ditentukan 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. Lihat 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, dan PackageManager metode untuk mengambil ikon dipanggil.

Jika implementasi perangkat menyertakan peluncur default yang mendukung dalam aplikasi penyematan pintasan, yakni:

Sebaliknya, jika implementasi perangkat tidak mendukung penyematan dalam aplikasi pintasan, mereka:

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 sebagai true, dan tidak menampilkan skema badge ikon aplikasi apa pun jika semuanya saluran notifikasi aplikasi telah menyetel nilainya sebagai false.
  • 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() dan Notification.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:

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 dan importance: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 ditentukan sebelumnya.
  • [C-1-3] HARUS mematuhi suppressedVisualEffects nilai yang diteruskan di NotificationManager.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.

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 intent ACTION_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 kami. 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 jenis tema “Material” dan TIDAK BOLEH mengubah salah satu dari 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 (lihat android.theme.customization.system_palette dan android.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 (lihat android.theme.customization.theme_styles), yaitu TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD.

    "Warna sumber" digunakan untuk menghasilkan palet tonal warna dinamis ketika dikirim dengan android.theme.customization.system_palette (seperti yang didokumentasikan dalam Settings.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 kelompok tema “Default Perangkat” sebagai kumpulan gaya yang ditentukan untuk digunakan pengembang aplikasi jika mereka ingin menyesuaikan tampilan dan nuansa tema perangkat seperti yang ditetapkan oleh pengimplementasi perangkat.

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.
  • [C-1-2] HARUS menerapkan perilaku penyematan ke layar dan berikan pengguna menu pengaturan untuk mengaktifkan fitur.
  • 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

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 file AndroidManifest.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 dan AndroidManifestLayout_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 mendeklarasikan android:resizeableActivity dan android: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 dan AndroidManifestLayout_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.

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

Android menyertakan fitur yang memungkinkan aplikasi yang peka keamanan 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.

Jika implementasi perangkat mengimplementasikan berbagai administrasi perangkat kebijakan yang ditentukan dalam dokumentasi Android SDK, kebijakan tersebut:

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

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 MIME MIME_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.
    • Ketika implementasi perangkat memiliki pengguna atau data pengguna, fungsi ini:
      • [C-1-7] HARUS mendaftarkan aplikasi DPC apa pun sebagai Aplikasi Pemilik Perangkat lagi.
  • [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 promo sebelum interaksi pengguna akhir di layar.

Jika implementasi perangkat mendeklarasikan android.software.device_admin, tetapi juga menyertakan solusi pengelolaan perangkat eksklusif dan menyediakan mekanisme untuk mempromosikan aplikasi yang dikonfigurasi dalam solusi mereka sebagai "Pemilik Perangkat 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.
3.9.1.2 Penyediaan profil terkelola

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

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.

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 oleh getParentProfileInstance.
  • 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 menampilkan true. 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:

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.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 terdaftar AccessibilityService 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:

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.

3.12. Framework Input TV

Android Television Input Framework (TIF) menyederhanakan penyampaian video live ke perangkat Android TV. TIF menyediakan API standar untuk membuat modul input yang mengontrol perangkat Android Television.

Jika implementasi perangkat mendukung TIF, implementasi tersebut:

  • [C-1-1] HARUS mendeklarasikan fitur platform android.software.live_tv.
  • [C-1-2] HARUS mendukung semua TIF API sehingga aplikasi yang menggunakan API ini dan input berbasis TIF pihak ketiga {i>service<i} dapat diinstal dan digunakan pada perangkat.

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() atau getIconUri() dan judul dengan jelas diperoleh melalui getTitle() sebagaimana dijelaskan dalam MediaDescription. 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 atau KEYCODE_MEDIA_PLAY_PAUSE sebagai KEYCODE_MEDIA_NEXT untuk MediaSession.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 dikaitkan 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.
  • [C-1-3] HARUS memberikan kemampuan kepada pengguna untuk memilih/mengonfirmasi pendamping perangkat tersedia dan dapat beroperasi.

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 oleh ContactsContract.RawContacts.getLocalAccountName
  • [C-1-2] ACCOUNT_TYPE, dari akun lokal kustom HARUS dikembalikan oleh ContactsContract.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 dan ACCOUNT_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 parameter CALLER\_IS\_SYNCADAPTER disetel salah atau tidak ditentukan.

4. Kompatibilitas Pengemasan Aplikasi

Implementasi perangkat:

  • [C-0-1] HARUS mampu menginstal dan menjalankan file “.apk” Android sebagai yang dihasilkan oleh alat "{i>aapt<i}" yang termasuk 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 file “.apk” menggunakan APK Signature Scheme v3.1, APK Signature Scheme v3, APK Signature Scheme v2 dan penandatanganan JAR.

  • [C-0-3] TIDAK BOLEH memperluas .apk, Manifes Android, Bytecode Dalvik, atau Memformat bytecode RenderScript sedemikian rupa sehingga akan mencegah file tersebut agar tidak diinstal 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 intent dan aplikasi pengelola penyimpanan yang menangani 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 menyetel android:targetSdkVersion pada 24 atau lebih rendah.
    • Aplikasi HARUS diberi izin oleh pengguna untuk menginstal aplikasi dari sumber tidak dikenal.

  • 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 untuk startActivityForResult(), 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 sama PackageManager.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:

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, dan KEY_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 dan KEY_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:

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 konstanta android.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.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
  • ADTS AAC mentah (.aac, ADIF tidak didukung)
  • MPEG-TS (.ts, tidak dapat dicari, hanya dekode)
  • Matroska (.mkv, khusus dekode)
Profil MPEG-4 HE AAC (AAC+) Dukungan untuk konten mono/stereo/5.0/5.1 dengan standar frekuensi sampling antara 16 hingga 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
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.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
AAC ELD (AAC yang ditingkatkan dengan delay rendah) Dukungan untuk konten mono/stereo dengan frekuensi pengambilan sampel standar dari 16 hingga 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
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.
  • FLAC (.flac)
  • MPEG-4 (hanya .mp4, .m4a, dekode)
  • Matroska (.mkv, khusus dekode)
MP3 Konstan Mono/Stereo 8-320 Kbps (CBR) atau kecepatan bit variabel (VBR)
  • MP3 (.mp3)
  • MPEG-4 (hanya .mp4, .m4a, dekode)
  • Matroska (.mkv, khusus dekode)
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
  • Ketik 0 dan 1 (.mid, .xmf, .mxmf)
  • RTTTL/RTX (.rtttl, .rtx)
  • iMelody (.imy)
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.
  • Ogg (.ogg)
  • MPEG-4 (hanya .mp4, .m4a, dekode)
  • Matroska (.mkv)
  • Webm (.webm)
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.
  • Ogg (.ogg)
  • MPEG-4 (hanya .mp4, .m4a, dekode)
  • Matroska (.mkv)
  • Webm (.webm)

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

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

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 konfigurasi android.graphics.Bitmap.

5.1.6. Detail Codec Gambar

Format/Codec Detail Jenis File/Format Penampung yang Didukung
JPEG Dasar+progresif JPEG (.jpg)
GIF GIF (.gif)
PNG PNG (.png)
BMP BMP (.bmp)
WebP WebP (.webp)
Raw ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
HEIF Gambar, Koleksi gambar, Urutan gambar HEIF (.heif), HEIC (.heic)

Encoder dan decoder gambar yang diekspos melalui MediaCodec API

  • [C-1-1] HARUS mendukung YUV420 8:8:8 warna fleksibel (COLOR_FormatYUV420Flexible) hingga CodecCapabilities.

  • [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 dengan COLOR_FormatYUV420Planar) atau COLOR_FormatYUV420PackedSemiPlanar (setara ke COLOR_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) hingga CodecCapabilities.

  • [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 dengan COLOR_FormatYUV420Planar) atau COLOR_FormatYUV420PackedSemiPlanar (setara dengan COLOR_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
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • Matroska (.mkv, khusus dekode)
AVC H.264 Lihat bagian 5.2 dan 5.3 untuk mengetahui detail
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • MPEG-2 TS (.ts, tidak dapat dicari)
  • Matroska (.mkv, khusus dekode)
H.265 HEVC Lihat bagian 5.3 untuk mengetahui detailnya
  • MPEG-4 (.mp4)
  • Matroska (.mkv, khusus dekode)
MPEG-2 Profil Utama
  • MPEG2-TS (.ts, tidak dapat dicari)
  • MPEG-4 (.mp4, dekode saja)
  • Matroska (.mkv, khusus dekode)
MPEG-4 SP
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • Matroska (.mkv, khusus dekode)
VP8 Lihat bagian 5.2 dan 5.3 untuk mengetahui detail
VP9 Lihat bagian 5.3 untuk mengetahui 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
  • 176 x 144 piksel (H263, MPEG2, MPEG4)
  • 352 x 288 piksel (encoder MPEG4, H263, MPEG2)
  • 320 x 180 piksel (VP8, VP8)
  • 320 x 240 piksel (lainnya)
  • 704 x 576 piksel (H263)
  • 640 x 360 piksel (VP8, VP9)
  • 640 x 480 piksel (encoder MPEG4)
  • 720 x 480 piksel (lainnya)
  • 1408 x 1152 piksel (H263)
  • 1280x720 piksel (lainnya)
 1920 x 1080 px (selain MPEG4) 3840 x 2160 piksel (HEVC, VP9)
  • [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

Apakah implementasi perangkat mendukung encoder video dan menyediakannya kepada aplikasi pihak ketiga, mereka:

  • SEHARUSNYA TIDAK, melalui dua jendela geser, lebih dari 15% di atas kecepatan bit di antara interval intraframe (I-frame).
  • TIDAK BOLEH lebih dari 100% di atas kecepatan bit melalui jendela geser selama 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 Profil Dasar Pengukuran Level 45.
  • HARUS mendukung kecepatan bit yang dapat dikonfigurasi secara dinamis untuk encoder yang didukung.

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.
  • HARUS mendukung profil encoding HD seperti yang ditunjukkan dalam tabel berikut.
  • [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung profil encoding 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

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 dan Level 45.

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.
  • [C-1-2] HARUS menampilkan konten Dolby Vision dengan benar pada layar perangkat atau di port output video standar (mis., HDMI).
  • [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, implementasi tersebut:

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

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 atau AAudio INPUT apa pun yang dibuka memulai proyek. Paling tidak, karakteristik berikut HARUS didukung:

  • 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 melalui AudioManager.getMicrophones() untuk AudioRecord aktif yang menggunakan MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED, atau VOICE_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 menggunakan android.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:

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 minimal satu pengambilan aplikasi dengan AudioSource 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 untuk AudioSource.VOICE_COMMUNICATION atau AudioSource.CAMCORDER.
  • [C-1-3] HARUS mematikan suara rekaman audio untuk aplikasi lain, kecuali untuk layanan aksesibilitas, sementara aplikasi menangkap dengan AudioSource.VOICE_COMMUNICATION atau AudioSource.CAMCORDER. Namun, ketika aplikasi merekam melalui AudioSource.VOICE_COMMUNICATION, lalu aplikasi lain dapat merekam panggilan suara jika merupakan aplikasi istimewa (sudah diinstal sebelumnya) dengan izin CAPTURE_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.4.6. Tingkat Penguatan Mikrofon [Dipindahkan ke 5.4.2]

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 Implementasi EFFECT_TYPE_LOUDNESS_ENHANCER yang dapat dikontrol melalui Subclass AudioEffect Equalizer dan LoudnessEnhancer.
  • [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 AudioEffect DynamicsProcessing.
  • HARUS mendukung EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, Penerapan EFFECT_TYPE_PRESET_REVERB, dan EFFECT_TYPE_VIRTUALIZER dapat dikontrol melalui sub-class AudioEffect BassBoost, EnvironmentalReverb, PresetReverb, dan Virtualizer.
  • [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 antara dua klip dengan format yang sama bila 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. Rata-rata nilai absolut penyimpangan dari rerata untuk sekumpulan nilai.
  • latensi ketuk untuk nada. Waktu antara saat layar diketuk dan saat nada yang dihasilkan sebagai akibat dari ketukan terdengar di speaker.

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

  • [C-1-1] Stempel waktu {i>output<i} yang ditampilkan oleh AudioTrack.getTimestamp dan AAudioStream_getTimestamp akurat hingga +/- 2 md.

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

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 pada data speaker .

  • [C-SR-2] Latensi tap-to-tone 80 milidetik atau kurang.

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

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:

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.

Jika implementasi perangkat menyertakan android.hardware.microphone, implementasi tersebut HARUS memenuhi persyaratan audio input ini:

  • [C-3-1] Batasi error dalam stempel waktu input, seperti yang ditampilkan oleh AudioRecord.getTimestamp atau AAudioStream_getTimestamp, hingga +/- 2 md. "Error" di sini berarti penyimpangan dari nilai yang benar.

  • [C-3-2] Latensi input dingin selama 500 milidetik atau kurang.

  • [C-3-3] Membuka streaming input menggunakan AAudioStreamBuilder_openStream() HARUS memerlukan waktu kurang dari 1000 milidetik.

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.

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.

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:
  • AVC H264
  • MPEG-4 SP
  • MPEG-2
Lihat bagian 5.1.8 untuk mengetahui detail tentang H264 AVC, MPEG2-4 SP,
dan MPEG-2.

Codec audio:

  • AAC
Lihat bagian 5.1.3 untuk mengetahui detail tentang AAC dan variannya.
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
MP2T 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 dapat 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:

  • [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.
  • [C-1-2] HARUS memiliki latensi audio bolak-balik berkelanjutan, seperti yang didefinisikan dalam bagian 5.6 Latensi Audio dari 25 milidetik atau kurang pada setidaknya satu jalur yang didukung.
  • [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.
  • [C-1-5] HARUS memenuhi persyaratan latensi dan audio USB dengan Audio native AAudio API dan AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.
  • [C-1-6] HARUS memiliki latensi output Dingin 200 milidetik atau kurang.
  • [C-1-7] HARUS memiliki latensi input Dingin 200 md atau kurang.
  • [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 opsi “Pengujian Otomatis” dan mencapai 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).

Jika implementasi perangkat memenuhi semua persyaratan di atas, implementasi tersebut:

Jika implementasi perangkat menyertakan colokan audio 3,5 mm konduktor 4, implementasi tersebut:

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

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.

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 untuk AudioManager.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)

    • [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
    • [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}.
    • [C-0-10] HARUS merekam, tanpa penghapusan, dan membuat peristiwa berikut dapat diakses dan tersedia untuk perintah shell cmd stats dan Class API Sistem StatsManager.
      • ActivityForegroundStateDiubah
      • Anomali Terdeteksi
      • AppBreadcrumbDilaporkan
      • AppCrashTerjadi
      • AppStartTerjadi
      • TingkatBateraiDiubah
      • BatterySaverModeStateDiubah
      • BleScanResultReceived
      • BleScanStateDiubah
      • PengisianStateDiubah
      • DeviceIdleModeStateDiubah
      • ForegroundServiceStateDiubah
      • GpsScanStateDiubah
      • JobStateDiubah
      • PluggedStateDiubah
      • DijadwalkanJobStateDiubah
      • Status Layar Diubah
      • SyncStateDiubah
      • Real-Time Berlalu Sistem
      • {i>UidProcessStateDiubah<i}
      • WakelockStateDiubah
      • WakeupAlarm Terjadi
      • WifiLockStateDiubah
      • WifiMulticastLockStateDiubah
      • WifiScanStateDiubah
    • [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() tampilkan true.

    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() tampilkan true.

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

  • SysTrace

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

  • Perfetto

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

  • Pemotong Memori Rendah

    • [C-0-12] HARUS menulis Atom LMK_KILL_OCCURRED_FIELD_NUMBER ke statistik saat aplikasi dihentikan oleh Low Memory Killer.

  • Mode Pengujian Harness Jika implementasi perangkat mendukung perintah shell cmd testharness dan menjalankan cmd testharness enable, mereka:

    • [C-2-1] HARUS mengembalikan true untuk ActivityManager.isRunningInUserTestHarness()
    • [C-2-2] HARUS menerapkan Mode Uji Coba seperti yang dijelaskan dalam Dokumentasi Mode Uji Coba.

  • Informasi pekerjaan GPU

    Implementasi perangkat:

    • [C-0-13] HARUS mengimplementasikan perintah shell dumpsys gpu --gpuwork untuk menampilkan data pekerjaan GPU gabungan yang ditampilkan oleh kernel power/gpu_work_period tracepoint, atau tidak menampilkan data jika tracepoint tidak didukung. AOSP implementasinya adalah frameworks/native/services/gpuservice/gpuwork/.

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 metode hasSystemFeature(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 konfigurasi hardware. Di layar yang kompatibel dengan Android yang semua kompatibel dengan Android pihak ketiga aplikasi dapat berjalan, implementasi perangkat HARUS mengimplementasikan API ini dengan benar dan perilaku model, seperti yang dijelaskan dalam bagian ini.

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.
  • titik per inci (dpi). Jumlah piksel yang dicakup oleh garis rentang horizontal atau vertikal 1”. Tempat nilai dpi dicantumkan, baik horizontal dan dpi vertikal harus berada dalam rentang yang ditentukan.
  • rasio aspek. Rasio piksel dimensi yang lebih panjang terhadap dimensi layar yang lebih pendek. Misalnya, tampilan 480x854 piksel akan menjadi 854/480 = 1,779, atau kira-kira “16:9”.
  • piksel kepadatan mandiri (dp). Unit piksel virtual dinormalisasi ke Layar 160 dpi, dihitung sebagai: piksel = dps * (kepadatan/160).

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 ukuran small untuk Configuration.screenLayout, HARUS memiliki minimal 426 dp x 320 dp.
    • Perangkat yang melaporkan ukuran normal untuk Configuration.screenLayout, HARUS memiliki minimal 480 dp x 320 dp.
    • Perangkat yang melaporkan ukuran large untuk Configuration.screenLayout, HARUS memiliki minimal 640 dp x 480 dp.
    • Perangkat yang melaporkan ukuran xlarge untuk Configuration.screenLayout, Harus memiliki minimal 960 dp x 720 dp.

  • [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 UI_MODE_TYPE_NORMAL dan sertakan Layar yang kompatibel dengan Android dengan sudut lengkung:

  • [C-1-1] HARUS memastikan bahwa setidaknya salah satu dari persyaratan berikut terpenuhi:

    • Radius sudut lengkung kurang dari atau sama dengan 38 dp.
    • Saat kotak berukuran 15 dp x 15 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 menyertakan layar yang kompatibel dengan Android yang dapat dilipat, atau menyertakan engsel lipat di antara beberapa panel layar dan tampilan yang tersedia untuk merender aplikasi pihak ketiga, yaitu:

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

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

Untuk mengetahui detail tentang cara menerapkan API file bantuan atau ekstensi dengan benar, lihat ke dokumentasi publik Jetpack Window Manager.

7.1.1.2. Rasio Aspek Layar

Meskipun tidak ada batasan terhadap rasio aspek tampilan fisik untuk tampilan yang kompatibel dengan Android, rasio aspek tampilan logis tempat aplikasi pihak ketiga dirender, yang dapat berasal dari ketinggian dan nilai lebar yang dilaporkan melalui view.Display API dan Konfigurasi API, HARUS memenuhi persyaratan berikut:

  • [C-0-1] Implementasi perangkat dengan Configuration.uiMode ditetapkan ke UI_MODE_TYPE_NORMAL HARUS memiliki nilai rasio aspek kurang dari atau sama dengan ke 1,86 (sekitar 16:9), kecuali jika aplikasi memenuhi salah satu dari yang berikut kondisi:

    • Aplikasi telah menyatakan bahwa aplikasi mendukung rasio aspek layar yang lebih besar melalui android.max_aspect nilai metadata.
    • Aplikasi mendeklarasikan bahwa aplikasi dapat diubah ukurannya melalui android:resizeableActivity .
    • Aplikasi menargetkan API level 24 atau yang lebih tinggi dan tidak mendeklarasikan android:maxAspectRatio yang akan membatasi rasio aspek yang diizinkan.

  • [C-0-3] Implementasi perangkat dengan Configuration.uiMode ditetapkan sebagai UI_MODE_TYPE_WATCH HARUS memiliki nilai rasio aspek yang ditetapkan ke 1,0 (1:1).

7.1.1.3. Kepadatan Layar

Framework UI Android menentukan sekumpulan kepadatan logis standar untuk membantu pengembang aplikasi menargetkan sumber daya aplikasi.

  • [C-0-1] Secara default, implementasi perangkat HARUS melaporkan salah satu dari Kepadatan framework Android yang tercantum di DisplayMetrics melalui DENSITY_DEVICE_STABLE API dan nilai ini TIDAK BOLEH berubah kapan pun; namun, perangkat tersebut MUNGKIN melaporkan kepadatan arbitrer yang berbeda sesuai dengan konfigurasi tampilan perubahan yang dibuat oleh pengguna (misalnya, ukuran tampilan) yang ditetapkan setelah nilai awal booting.

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

Jika ada affordance untuk mengubah ukuran layar perangkat:

  • [C-1-1] Ukuran layar TIDAK BOLEH diskalakan lebih besar dari 1,5 kali kepadatan native 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] Ukuran tampilan TIDAK BOLEH diskalakan lebih kecil dari 0,85 kali kepadatan native.
  • 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 untuk view.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/atau android.hardware.screen.landscape) dan HARUS melaporkan minimal satu yang didukung orientasi. Misalnya, perangkat dengan lanskap orientasi tetap layar, seperti televisi atau laptop, SEHARUSNYA hanya laporkan android.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:

  • [C-1-1] HARUS mendukung OpenGL ES 1.1 dan 2.0, seperti yang disertakan dan mendetail di dokumentasi Android SDK.
  • [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung OpenGL ES 3.1.
  • HARUS mendukung OpenGL ES 3.2.

Pengujian dEQP OpenGL ES dipartisi menjadi sejumlah daftar pengujian, masing-masing dengan tanggal/nomor versi terkait. Ini ada dalam pohon sumber Android di external/deqp/android/cts/main/glesXX-main-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, dan EGL_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 dan OES_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 dan EGL_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-main-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 1.0 atau yang lebih tinggi, implementasi tersebut:

  • [C-1-1] HARUS melaporkan nilai bilangan bulat yang benar dengan android.hardware.vulkan.level dan android.hardware.vulkan.version tombol fitur.
  • [C-1-2] HARUS menghitung, setidaknya satu VkPhysicalDevice untuk Vulkan API native vkEnumeratePhysicalDevices() kami.
  • [C-1-3] HARUS sepenuhnya menerapkan Vulkan 1.0 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 Vulkan vkEnumerateInstanceLayerProperties() dan vkEnumerateDeviceLayerProperties() kami.
  • [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 sebagai true.
  • [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 fitur android.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 fitur android.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 dan VK_GOOGLE_display_timing ekstensi.
  • HARUS mendukung VkPhysicalDeviceProtectedMemoryFeatures dan VK_EXT_global_priority.
  • [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 2021.

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 Vulkan vkEnumeratePhysicalDevices().

Jika implementasi perangkat menyertakan dukungan untuk Vulkan 1.1 dan mendeklarasikan salah satu Tombol fitur Vulkan, yaitu:

  • [C-3-1] HARUS mengekspos dukungan untuk semafor dan handle eksternal SYNC_FD dan ekstensi VK_ANDROID_external_memory_android_hardware_buffer.
7.1.4.3 RenderScript
  • [C-0-1] Penerapan perangkat HARUS mendukung Android RenderScript, seperti yang dijelaskan di 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() , mereka:

  • [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, dan EGL_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” tempat framework 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 mengimplementasikan DisplayManager layanan sistem dan API seperti dijelaskan dalam dokumentasi Android SDK.

7.2. Perangkat Masukan

Implementasi perangkat:

7.2.1. Keyboard

Jika implementasi perangkat menyertakan dukungan untuk pihak ketiga Aplikasi Editor Metode Input (IME), aplikasi:

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:

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 dengan ACTION=MAIN dan CATEGORY=LAUNCHER atau CATEGORY=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 membuat fungsi Menu tersedia 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:

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 pada orientasi layar saat ini.
  • [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 untuk Configuration.touchscreen API.
  • [C-1-2] HARUS melaporkan android.hardware.touchscreen dan tombol fitur android.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 atas Configuration.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 pada 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.

4 MotionEvent

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

1 MotionEvent

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 atau false 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 yang dilaporkan masing-masing sensor.

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 gravitasi(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 hidup dan 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 konsumsi daya mereka 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 menerapkan sensor komposit TYPE_GRAVITY dan TYPE_LINEAR_ACCELERATION.
  • [C-SR-7] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan TYPE_GAME_ROTATION_VECTOR sensor komposit.

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 GNSS Location Provider API 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 dan TYPE_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:

Jika implementasi perangkat menyertakan sensor untuk memantau suhu kulit, maka mereka:

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 pembacaan biner “dekat” atau “jauh”, 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 sebagai TYPE_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 sebagai TYPE_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 seperti TYPE_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 dan getHighestDirectReportRateLevel 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.

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-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 yang diukur oleh Protokol Pengujian Biometrik Android.
  • [C-1-4] HARUS mencegah penambahan biometrik baru tanpa terlebih dahulu menetapkan rantai kepercayaan dengan meminta pengguna mengonfirmasi 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.
  • [C-1-5] HARUS menghapus sepenuhnya semua data biometrik yang dapat diidentifikasi untuk pengguna saat akun pengguna dihapus (termasuk melalui reset ke setelan pabrik).
  • [C-1-6] HARUS menghormati masing-masing bendera untuk biometrik tersebut (yaitu DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE , atau DevicePolicymanager.KEYGUARD_DISABLE_IRIS ).
  • [C-1-7] HARUS menantang pengguna untuk autentikasi primer yang direkomendasikan (misalnya, 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 (mis. PIN, pola, {i>password<i}) sekali setiap 72 jam atau kurang.
  • [C-1-8] HARUS menantang pengguna untuk atribut primer yang direkomendasikan autentikasi (misalnya: 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: Upgrade perangkat yang diluncurkan di Android versi 9 atau yang lebih lama DAPAT dikecualikan dari C-1-8.
  • [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 palsu kurang dari 10%, seperti 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.

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 presentasi Tingkat A spesies serangan instrumen (PAI) tidak lebih tinggi dari 20%, dan (2) spoof dan tingkat penerimaan penipu dari spesies PAI Level B tidak lebih tinggi dari 30%, karena 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 kernel, seperti Trusted Execution Environment (TEE), atau pada {i>chip<i} dengan saluran yang aman ke lingkungan eksekusi yang terisolasi.

  • [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 Proyek Sumber Terbuka Android.

  • [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.
    • 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. Mengupgrade perangkat yang diluncurkan di Android versi 9 atau sebelumnya 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 (misalnya, 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.

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:

7.3.13. IEEE 802.1.15.4 [Pindah ke 7.4.9]

7.4. Konektivitas Data

7.4.1. Telepon

“Telepon” seperti yang digunakan oleh API Android dan dokumen ini secara khusus merujuk ke perangkat keras yang terkait dengan melakukan panggilan suara dan mengirim pesan SMS melalui GSM atau jaringan CDMA. Meskipun panggilan suara ini mungkin atau tidak dapat dialihkan, mereka untuk tujuan Android yang dianggap terpisah dari data apa pun konektivitas yang dapat diimplementasikan menggunakan jaringan yang sama. Dengan kata lain, {i>SUMIF<i} memiliki daftar sel API dan fungsi "telepon" Android secara khusus merujuk ke suara panggilan telepon dan SMS. Misalnya, implementasi perangkat yang tidak bisa melakukan panggilan atau mengirim/menerima pesan SMS tidak dianggap sebagai perangkat telepon, terlepas dari apakah mereka menggunakan jaringan seluler untuk konektivitas data.

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

Jika penerapan perangkat tidak menetapkan properti sistem ro.telephony.iwlan\_operation\_mode ke ‘lama’, penerapan tersebut:

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:

Jika implementasi perangkat melaporkan fitur android.hardware.telephony, maka:

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 dari {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:

Jika implementasi perangkat mendukung eUICC dengan beberapa port dan profil, implementasi tersebut:

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 pada PhoneAccount-nya menjadi true.

  • [C-SR-3] SANGAT DIREKOMENDASIKAN untuk menangani masalah headset audio Peristiwa KEYCODE_MEDIA_PLAY_PAUSE dan KEYCODE_HEADSETHOOK untuk android.telecom API seperti di bawah ini:

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.
  • [C-1-4] HARUS mendukung multicast DNS (mDNS) dan TIDAK BOLEH memfilter paket mDNS (224.0.0.251) setiap saat operasi termasuk:
    • Bahkan saat layar tidak dalam status aktif.
    • Untuk implementasi perangkat Android Televisi, bahkan saat dalam mode standby status daya.
  • [C-1-5] TIDAK BOLEH memperlakukan WifiManager.enableNetwork() Panggilan metode API sebagai indikasi yang memadai untuk mengalihkan mode yang sedang aktif Network yang digunakan secara default untuk traffic aplikasi dan ditampilkan oleh ConnectivityManager Metode API seperti getActiveNetwork dan registerDefaultNetworkCallback. 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 di Network, dan setelah evaluasi menentukan bahwa Network 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 kunci WIFI_MODE_FULL_LOW_LATENCY melalui WifiManager.createWifiLock() dan WifiManager.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:

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.

Implementasi perangkat:

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:

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:

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:

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:

7.4.2.7. Wi-Fi Easy Connect (Protokol Penyediaan Perangkat)

Implementasi perangkat:

Jika implementasi perangkat menyertakan dukungan untuk Wi-Fi Easy Connect dan mengekspos fungsi bagi aplikasi pihak ketiga, mereka:

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) dengan A2DP.

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 dan android.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:

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:

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

Jika implementasi perangkat mendukung Bluetooth versi 5.0, implementasi tersebut:

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

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 dan android.nfc.NdefRecord API meskipun tidak menyertakan dukungan untuk NFC atau mendeklarasikan fitur android.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 Metode android.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 dari android.content.pm.PackageManager.hasSystemFeature() . Perhatikan bahwa ini bukan fitur Android standar dan dengan demikian muncul sebagai konstanta di class android.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 dan java.net.URLConnection, serta API native, seperti AF_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.
  • [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 atau Socket#getLocalPort) dan NDK API seperti getsockname() atau IPV6_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 API ConnectivityManager#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 dan android.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 seperti connect()) adalah jaringan lain yang tersedia yang menyediakan akses internet, jika tersedia.

7.4.6. Setelan Sinkronisasi

Implementasi perangkat:

  • [C-0-1] HARUS mengaktifkan pengaturan sinkronisasi otomatis master secara default agar metode getMasterSyncAutomatically() akan menampilkan nilai "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:

7.4.8. Elemen Pengaman

Jika implementasi perangkat mendukung kemampuan Open Mobile API elemen keamanan dan menyediakannya untuk aplikasi pihak ketiga, mereka:

7.4.9. UWB

Jika implementasi perangkat menyertakan dukungan untuk 802.1.15.4 dan mengekspos fungsionalitas dengan 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 yang dipegang menghadap ke atas dan dimiringkan 45 derajat.
    • [C-SR-2] SANGAT DIREKOMENDASIKAN untuk mengikuti langkah-langkah penyiapan pengukuran ditentukan dalam 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, atau MediaStore.ACTION_VIDEO_CAPTURE, bertanggung jawab untuk menghapus lokasi pengguna dalam metadata gambar sebelum mengirimkannya ke aplikasi penerima ketika aplikasi penerima tidak memiliki ACCESS_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 yang terletak di sisi perangkat di seberang layar; yaitu, gambar adegan di sisi paling jauh perangkat, seperti kamera tradisional.

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 dan android.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 atribut FLASH_MODE_AUTO atau FLASH_MODE_ON dari objek Camera.Parameters. Perhatikan bahwa batasan ini tidak berlaku untuk aplikasi kamera sistem bawaan perangkat, tetapi hanya untuk aplikasi menggunakan Camera.PreviewCallback.

7.5.2. Kamera Depan

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

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 dan android.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 ke android.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

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 dan android.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 memanggil android.hardware.Camera.Parameters.setPreviewFormat(int).
  • [C-0-2] Selanjutnya HARUS dalam format pengkodean NV21 saat aplikasi mendaftarkan android.hardware.Camera.PreviewCallback dan sistem memanggil metode onPreviewFrame() serta pratinjau formatnya adalah YCbCr_420_SP, data dalam byte[] yang diteruskan ke onPreviewFrame(). 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 untuk android.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 dan android.hardware.ImageFormat.JPEG berformat sebagai output melalui android.media.ImageReader API untuk android.hardware.camera2 perangkat yang iklankan REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE yang lebih tinggi di android.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 autofokus, callback API harus tetap "palsu" seperti yang telah dijelaskan.
  • [C-0-6] HARUS mengenali dan mematuhi setiap nama parameter didefinisikan sebagai konstanta di android.hardware.Camera.Parameters dan class android.hardware.camera2.CaptureRequest. Sebaliknya, implementasi perangkat TIDAK BOLEH mengikuti atau mengenali konstanta string diteruskan ke metode android.hardware.Camera.setParameters() selain yang didokumentasikan sebagai konstanta pada android.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 kamera Camera.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 properti android.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 melalui android.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 atau android.hardware.Camera Compute Engine API.
  • [C-SR-1] Untuk perangkat dengan beberapa kamera RGB yang 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:

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

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 dari sdcard 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.
  • [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 izin ACCESS_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:

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 melalui android.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 class 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 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

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 intent ACTION_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
  • [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
  • [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 berisi VK_QUEUE_GRAPHICS_BIT dan VK_QUEUE_COMPUTE_BIT, dan queueCount 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 menandai AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA dan AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT seperti yang dijelaskan dalam NDK.
  • [C-1-10] HARUS mengimplementasikan dukungan untuk AHardwareBuffer dengan kombinasi flag penggunaan AHARDWAREBUFFER_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

Lihat Pasal 2.2.1 untuk mengetahui persyaratan khusus perangkat.

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 yang digunakan untuk Aplikasi Standby.
  • [C-1-4] HARUS menerapkan Bucket Aplikasi Standby dan Istirahatkan sebagai yang dijelaskan dalam Pengelolaan Daya.
  • [C-1-5] HARUS mengembalikan true untuk PowerManager.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 berjalan PARTIAL_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:

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 mematuhi 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:

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 Jalur etc/permissions/ dan menggunakan jalur system/priv-app sebagai jalur hak istimewa.

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-4] HARUS memiliki satu dan hanya satu implementasi dari kedua akun antarmuka. Jika implementasi perangkat itu mendukung perangkat pendamping, perangkat pendamping MUNGKIN menyediakan antarmuka tambahan.

  • [C-0-5] TIDAK BOLEH memberikan izin runtime kepada 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 perangkat (mis. SSID, BSSID, ID Sel, atau lokasi jaringan yang terhubung dengan perangkat).
    • Aktivitas fisik pengguna atau klasifikasi aktivitas fisik.

Lebih khusus lagi, implementasi perangkat:

  • [C-0-8] HARUS mendapatkan persetujuan pengguna untuk mengizinkan aplikasi mengakses lokasi atau aktivitas fisik Anda.
  • [C-0-9] HARUS memberikan izin runtime HANYA untuk aplikasi yang menyimpan izin yang memadai seperti yang dijelaskan di SDK. Misalnya, TelephonyManager#getServiceState memerlukan android.permission.ACCESS_FINE_LOCATION).

Satu-satunya pengecualian untuk properti izin akses lokasi Android di atas adalah untuk aplikasi yang tidak mengakses Lokasi untuk mendapatkan atau mengidentifikasi lokasi pengguna; khususnya:

  • Saat aplikasi memiliki izin RADIO_SCAN_WITHOUT_LOCATION.
  • Untuk tujuan konfigurasi dan penyiapan perangkat, di mana aplikasi sistem memegang Izin NETWORK_SETTINGS atau NETWORK_SETUP_WIZARD.

Izin dapat ditandai sebagai perubahan perilaku yang dibatasi.

  • [C-0-10] Izin yang ditandai dengan tanda hardRestricted TIDAK BOLEH diberikan ke aplikasi kecuali:

    • File APK aplikasi ada di partisi sistem.
    • Pengguna menetapkan peran yang terkait dengan hardRestricted izin akses ke aplikasi.
    • Penginstal memberikan hardRestricted ke aplikasi.
    • Aplikasi diberi hardRestricted pada versi Android sebelumnya.

  • [C-0-11] Aplikasi yang memiliki izin softRestricted HARUS mendapatkan izin terbatas akses dan TIDAK BOLEH mendapatkan akses penuh sampai diizinkan, sebagaimana dijelaskan dalam SDK, yang menentukan akses penuh dan terbatas untuk setiap softRestricted (misalnya, READ_EXTERNAL_STORAGE).

  • [C-0-12] TIDAK BOLEH menyediakan fungsi atau API khusus apa pun untuk mengabaikan batasan izin yang ditentukan dalam setPermissionPolicy dan setPermissionGrantState Google Cloud Platform.

  • [C-0-13] HARUS menggunakan API AppOpsManager untuk merekam dan melacak setiap setiap akses data terprogram yang dilindungi oleh izin berbahaya dari Aktivitas dan layanan Android.

  • [C-0-14] Hanya boleh menetapkan peran ke aplikasi dengan fungsi yang memenuhi persyaratan peran.

  • [C-0-15] TIDAK BOLEH menetapkan peran yang merupakan fungsi duplikat atau superset yang ditetapkan oleh platform.

Jika perangkat melaporkan android.software.managed_users, perangkat:

  • [C-1-1] TIDAK BOLEH memiliki izin berikut secara diam-diam yang diberikan oleh admin:
    • Lokasi (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
    • Kamera (KAMERA)
    • Mikrofon (RECORD_AUDIO)
    • Sensor tubuh (BODY_SENSORS)
    • Aktivitas fisik (ACTIVITY_RECOGNITION)

Jika implementasi perangkat memberikan kemampuan pengguna untuk memilih aplikasi mana yang dapat menggambar di atas aplikasi lain dengan aktivitas yang menangani ACTION_MANAGE_OVERLAY_PERMISSION niat, mereka:

  • [C-2-1] HARUS memastikan bahwa semua aktivitas dengan filter intent untuk ACTION_MANAGE_OVERLAY_PERMISSION intent memiliki layar UI yang sama, terlepas dari aplikasi yang memulai informasi yang diberikannya.

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

  • [C-3-1] HARUS menampilkan pernyataan penyangkalan selama penyiapan perangkat yang terkelola sepenuhnya (penyiapan pemilik perangkat) yang menyatakan bahwa admin IT akan dapat izinkan aplikasi untuk mengontrol setelan di ponsel termasuk mikrofon, kamera, lokasi, dengan opsi bagi pengguna untuk melanjutkan penyiapan atau keluar dari penyiapan KECUALI admin telah menonaktifkan kontrol izin pada perangkat.

Jika implementasi perangkat telah menginstal paket apa pun yang memiliki peran System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence, atau System Visual Intelligence, maka paket tersebut:

  • [C-4-1] HARUS memenuhi semua persyaratan yang diuraikan untuk implementasi perangkat di bagian "9.8.6 Pengambilan Konten".
  • [C-4-2] TIDAK BOLEH memiliki izin android.permission.INTERNET. Ini lebih ketat daripada yang KUAT DIREKOMENDASIKAN yang tercantum dalam pasal 9.8.6.
  • [C-4-3] TIDAK BOLEH mengikat ke aplikasi lain, kecuali untuk aplikasi sistem berikut: Bluetooth, Kontak, Media, Telepon, SystemUI, dan komponen yang menyediakan API Internet.Ini lebih ketat daripada yang SANGAT DIREKOMENDASIKAN tercantum dalam pasal 9.8.6.

9.2. UID dan Isolasi Proses

Implementasi perangkat:

  • [C-0-1] HARUS mendukung aplikasi Android {i>sandbox<i}, di mana setiap aplikasi berjalan sebagai UID Unixstyle unik dan dalam proses terpisah.
  • [C-0-2] HARUS mendukung pengoperasian beberapa aplikasi sebagai ID pengguna Linux yang sama, asalkan aplikasi ditandatangani dengan benar dan dibuat, seperti yang dijelaskan dalam Referensi Keamanan dan Izin.

9.3. Izin Sistem File

Implementasi perangkat:

9.4. Lingkungan Eksekusi Alternatif

Implementasi perangkat HARUS menjaga konsistensi keamanan Android dan yang sama, meskipun model tersebut menyertakan lingkungan runtime yang mengeksekusi aplikasi yang menggunakan beberapa software atau teknologi selain Dalvik Executable Format atau kode native. Dengan kata lain:

  • [C-0-1] Runtime alternatif HARUS berupa aplikasi Android, dan mematuhi model keamanan Android standar, seperti dijelaskan di bagian lain di bagian 9.

  • [C-0-2] Runtime alternatif TIDAK BOLEH diberi akses ke resource dilindungi oleh izin yang tidak diminta dalam AndroidManifest.xml runtime file melalui <uses-permission> mekanisme atensi.

  • [C-0-3] Runtime alternatif TIDAK BOLEH mengizinkan aplikasi menggunakan fitur yang dilindungi oleh izin Android yang terbatas untuk aplikasi sistem.

  • [C-0-4] Runtime alternatif HARUS mematuhi model sandbox Android dan aplikasi yang diinstal menggunakan runtime alternatif TIDAK BOLEH menggunakan kembali {i>sandbox<i} aplikasi lain yang diinstal pada perangkat, kecuali melalui mekanisme Android standar dari ID pengguna bersama dan sertifikat penandatanganan.

  • [C-0-5] Runtime alternatif TIDAK BOLEH diluncurkan dengan, memberikan, atau diberikan akses ke {i>sandbox<i} yang sesuai dengan aplikasi Android lainnya.

  • [C-0-6] Runtime alternatif TIDAK BOLEH diluncurkan dengan, diberikan, atau diberikan ke aplikasi lain hak istimewa dari superuser (root), atau hak istimewa ID pengguna.

  • [C-0-7] Jika file .apk runtime alternatif disertakan dalam image sistem dari implementasi perangkat, maka HARUS ditandatangani dengan kunci dari kunci yang digunakan untuk menandatangani aplikasi lain yang disertakan dengan perangkat implementasi yang tepat.

  • [C-0-8] Saat menginstal aplikasi, runtime alternatif HARUS memperoleh izin pengguna untuk izin Android yang digunakan oleh aplikasi.

  • [C-0-9] Ketika aplikasi perlu memanfaatkan sumber daya perangkat untuk yang memiliki izin Android yang sesuai (seperti Kamera, GPS, dll.), runtime alternatif HARUS memberi tahu pengguna bahwa aplikasi akan dapat mengakses sumber daya tersebut.

  • [C-0-10] Saat lingkungan runtime tidak merekam aplikasi kemampuan dengan cara ini, lingkungan runtime HARUS mencantumkan semua izin yang ditahan oleh runtime itu sendiri saat menginstal aplikasi apa pun menggunakan runtime tersebut.

  • Runtime alternatif HARUS menginstal aplikasi melalui PackageManager ke dalam sandbox Android terpisah (ID pengguna Linux, dll.).

  • Runtime alternatif DAPAT menyediakan satu sandbox Android yang digunakan bersama oleh semua menggunakan runtime alternatif.

9,5. Dukungan Multipengguna

Android menyertakan dukungan untuk beberapa pengguna serta menyediakan dukungan untuk isolasi pengguna penuh dan menggandakan profil pengguna dengan isolasi parsial(yaitu, satu profil pengguna tambahan dari jenis android.os.usertype.profile.CLONE).

  • Implementasi perangkat MUNGKIN, tetapi TIDAK BOLEH mengaktifkan multi-pengguna jika menggunakan media yang dapat dilepas untuk penyimpanan eksternal utama.

Jika implementasi perangkat mencakup dukungan untuk beberapa pengguna, implementasi tersebut:

  • [C-1-2] HARUS, untuk setiap pengguna, menerapkan persyaratan konsisten dengan model keamanan platform Android sebagaimana didefinisikan dalam Dokumen referensi Keamanan dan Izin dalam API.
  • [C-1-3] HARUS memiliki penyimpanan aplikasi bersama yang terpisah dan terisolasi (alias /sdcard) untuk setiap instance pengguna.
  • [C-1-4] HARUS memastikan bahwa aplikasi yang dimiliki oleh dan berjalan atas nama pengguna tertentu tidak dapat mencantumkan, membaca, atau menulis ke file yang dimiliki oleh pengguna lain, meskipun data kedua pengguna disimpan pada volume atau sistem file yang sama.
  • [C-1-5] HARUS mengenkripsi konten kartu SD saat multipengguna diaktifkan menggunakan kunci yang hanya disimpan pada media yang tidak dapat dilepas dan hanya dapat diakses oleh sistem jika implementasi perangkat menggunakan media yang dapat dilepas untuk API penyimpanan eksternal. Karena ini akan membuat media tidak dapat dibaca oleh PC {i>host<i}, implementasi perangkat akan diminta beralih ke MTP atau sistem serupa untuk menyediakan PC {i>host<i} dengan akses ke data pengguna saat ini.

Jika implementasi perangkat mencakup dukungan untuk banyak pengguna, maka untuk semua pengguna kecuali pengguna yang dibuat khusus untuk menjalankan dual instance aplikasi yang sama, mereka:

  • [C-2-1] HARUS memiliki penyimpanan aplikasi bersama yang terpisah dan terisolasi (alias /sdcard) untuk setiap {i>instance<i} pengguna.
  • [C-2-2] HARUS memastikan bahwa aplikasi yang dimiliki dan berjalan di nama pengguna tertentu tidak dapat membuat daftar, membaca, atau menulis ke file yang dimiliki oleh pengguna lain, meskipun data kedua pengguna tersebut disimpan di volume atau sistem file.

Penerapan perangkat DAPAT membuat satu profil pengguna tambahan dari jenis android.os.usertype.profile.CLONE terhadap pengguna utama (dan hanya terhadap pengguna utama) untuk tujuan menjalankan {i> instance<i} ganda dari aplikasi yang sama. Instance ganda ini berbagi penyimpanan yang terisolasi sebagian, disajikan ke pengguna akhir di peluncur secara bersamaan dan muncul dalam tampilan terbaru yang sama. Misalnya, ini dapat digunakan untuk mendukung pengguna yang menginstal dua dari satu aplikasi pada perangkat SIM ganda.

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

  • [C-3-1] HARUS menyediakan akses ke penyimpanan atau data saja yang sudah dapat diakses oleh profil pengguna induk atau dimiliki secara langsung oleh profil ini profil pengguna tambahan.
  • [C-3-2] TIDAK BOLEH memiliki ini sebagai profil kerja.
  • [C-3-3] HARUS memiliki direktori data aplikasi pribadi yang terisolasi dari induknya menggunakan akun layanan.
  • [C-3-4] TIDAK BOLEH mengizinkan pembuatan profil pengguna tambahan jika ada adalah Pemilik Perangkat yang disediakan (lihat bagian 3.9.1) atau mengizinkan Pemilik Perangkat disediakan tanpa menghapus profil pengguna tambahan terlebih dahulu.

9.6. Peringatan SMS Premium

Android menyertakan dukungan untuk memperingatkan pengguna tentang pesan keluar pesan SMS premium. SMS Premium pesan adalah pesan teks yang dikirim ke layanan yang terdaftar pada operator yang mungkin dikenai biaya kepada pengguna.

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

  • [C-1-1] HARUS memperingatkan pengguna sebelum mengirim pesan SMS ke nomor diidentifikasi oleh ekspresi reguler yang ditentukan dalam /data/misc/sms/codes.xml di perangkat. Project Open Source Android upstream menyediakan penerapan yang memenuhi persyaratan ini.

9,7. Fitur Keamanan

Implementasi perangkat HARUS memastikan kepatuhan terhadap fitur keamanan baik dalam dan platform seperti yang dijelaskan di bawah ini.

Android Sandbox menyertakan fitur yang menggunakan Security-Enhanced Linux (SELinux) sistem kontrol akses wajib (MAC), {i>sandbox<i} seccomp, dan fitur keamanan pada {i>kernel<i} Linux. Implementasi perangkat:

  • [C-0-1] HARUS menjaga kompatibilitas dengan aplikasi yang ada, bahkan ketika SELinux atau fitur keamanan lainnya diimplementasikan di bawah Android Google Workspace for Education.
  • [C-0-2] TIDAK BOLEH memiliki antarmuka pengguna yang terlihat saat sistem keamanan pelanggaran terdeteksi dan berhasil diblokir oleh fitur keamanan diimplementasikan di bawah framework Android, tetapi MUNGKIN memiliki antarmuka pengguna yang terlihat ketika terjadi pelanggaran keamanan yang tidak diblokir yang mengakibatkan eksploitasi berhasil.
  • [C-0-3] TIDAK BOLEH menerapkan SELinux atau fitur keamanan lainnya di bawah framework Android yang dapat dikonfigurasi oleh pengguna atau developer aplikasi.
  • [C-0-4] TIDAK BOLEH mengizinkan aplikasi yang dapat memengaruhi aplikasi lain melalui API (seperti Device Administration API) untuk mengonfigurasi kebijakan yang merusak kompatibilitas.
  • [C-0-5] HARUS membagi framework media menjadi beberapa proses sehingga dapat memberikan akses yang lebih sempit untuk setiap proses sebagai dijelaskan di situs Proyek Sumber Terbuka Android.
  • [C-0-6] HARUS menerapkan mekanisme sandbox aplikasi kernel yang memungkinkan pemfilteran panggilan sistem menggunakan kebijakan yang dapat dikonfigurasi dari program multi-thread. Project Open Source Android upstream memenuhi persyaratan ini persyaratan dengan mengaktifkan seccomp-BPF dengan threadgroup sinkronisasi (TSYNC) seperti yang dijelaskan di bagian Konfigurasi Kernel di source.android.com.

Integritas kernel dan fitur perlindungan diri adalah bagian integral dari Android keamanan. Implementasi perangkat:

  • [C-0-7] HARUS menerapkan mekanisme perlindungan overflow buffer stack kernel. Contoh mekanisme tersebut adalah CC_STACKPROTECTOR_REGULAR dan CONFIG_CC_STACKPROTECTOR_STRONG.
  • [C-0-8] HARUS mengimplementasikan perlindungan memori kernel yang ketat di tempat yang dapat dieksekusi kode bersifat hanya-baca, data hanya-baca tidak dapat dieksekusi dan tidak dapat ditulis, data yang dapat ditulis tidak dapat dieksekusi (misalnya CONFIG_DEBUG_RODATA atau CONFIG_STRICT_KERNEL_RWX).
  • [C-0-9] HARUS mengimplementasikan ukuran objek statis dan dinamis batas pemeriksaan salinan antara {i>user-space<i} dan {i>kernel-space<i} (mis. CONFIG_HARDENED_USERCOPY) pada perangkat yang awalnya dikirimkan dengan level API 28 atau lebih tinggi.
  • [C-0-10] TIDAK BOLEH mengeksekusi memori ruang pengguna saat mengeksekusi dalam mode kernel (mis. PXN hardware, atau diemulasikan melalui CONFIG_CPU_SW_DOMAIN_PAN atau CONFIG_ARM64_SW_TTBR0_PAN) di perangkat pada awalnya dikirimkan dengan API level 28 atau yang lebih tinggi.
  • [C-0-11] TIDAK BOLEH membaca atau menulis memori ruang pengguna di di luar API akses salinan pengguna normal (mis. PAN hardware, atau diemulasikan melalui CONFIG_CPU_SW_DOMAIN_PAN atau CONFIG_ARM64_SW_TTBR0_PAN) pada perangkat yang awalnya mengirim dengan API level 28 atau yang lebih tinggi.
  • [C-0-12] HARUS mengimplementasikan isolasi tabel halaman kernel jika perangkat keras rentan terhadap CVE-2017-5754 di semua perangkat yang awalnya dikirimkan dengan level API 28 atau lebih tinggi (mis. CONFIG_PAGE_TABLE_ISOLATION atau CONFIG_UNMAP_KERNEL_AT_EL0).
  • [C-0-13] HARUS mengimplementasikan pengerasan prediksi cabang jika perangkat keras rentan terhadap CVE-2017-5715 di semua perangkat yang awalnya dikirimkan dengan level API 28 atau lebih tinggi (misalnya, CONFIG_HARDEN_BRANCH_PREDICTOR).
  • [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menyimpan data kernel yang hanya ditulis selama inisialisasi dan ditandai sebagai hanya baca setelah inisialisasi (misalnya, __ro_after_init).

  • [C-SR-2] SANGAT DIREKOMENDASIKAN untuk mengacak tata letak kode {i>kernel<i} dan memori, dan untuk menghindari paparan yang akan mengganggu pengacakan (mis. CONFIG_RANDOMIZE_BASE dengan entropi bootloader melalui /chosen/kaslr-seed Device Tree node atau EFI_RNG_PROTOCOL).

  • [C-SR-3] SANGAT DIREKOMENDASIKAN untuk mengaktifkan integritas alur kontrol (CFI) dalam {i>kernel<i} untuk memberikan perlindungan tambahan terhadap serangan penggunaan kembali kode (misalnya, CONFIG_CFI_CLANG dan CONFIG_SHADOW_CALL_STACK).

  • [C-SR-4] SANGAT DIREKOMENDASIKAN untuk tidak menonaktifkan Control-Flow Integrity (CFI), Shadow Call Stack (SCS) atau Integer Overflow Sanitization (IntSan) pada komponen yang mengaktifkannya.

  • [C-SR-5] SANGAT DIREKOMENDASIKAN untuk mengaktifkan CFI, SCS, dan IntSan untuk semua komponen ruang pengguna yang sensitif terhadap keamanan tambahan seperti yang dijelaskan dalam CFI dan IntSan.

  • [C-SR-6] SANGAT DIREKOMENDASIKAN untuk mengaktifkan inisialisasi stack di kernel untuk mencegah penggunaan variabel lokal yang tidak diinisialisasi (CONFIG_INIT_STACK_ALL atau CONFIG_INIT_STACK_ALL_ZERO). Selain itu, implementasi perangkat TIDAK BOLEH mengasumsikan nilai yang digunakan oleh compiler untuk melakukan inisialisasi pada lokalitas.

  • [C-SR-7] SANGAT DIREKOMENDASIKAN untuk mengaktifkan inisialisasi heap di kernel untuk mencegah penggunaan alokasi heap yang tidak diinisialisasi (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) dan mereka TIDAK BOLEH mengasumsikan nilai yang digunakan oleh {i>kernel<i} untuk melakukan inisialisasi alokasi tersebut.

Jika implementasi perangkat menggunakan {i> kernel<i} Linux yang mampu mendukung SELinux, ini:

  • [C-1-1] HARUS mengimplementasikan SELinux.
  • [C-1-2] HARUS menyetel SELinux ke mode penerapan global.
  • [C-1-3] HARUS mengonfigurasi semua domain dalam mode penerapan. Tidak ada mode permisif domain yang diizinkan, termasuk domain khusus untuk perangkat/vendor.
  • [C-1-4] TIDAK BOLEH memodifikasi, menghilangkan, atau mengganti aturan yang tidak diizinkan yang ada dalam folder sistem/sepolicy yang disediakan di Android Open Source upstream Project (AOSP) dan kebijakan HARUS dikompilasi dengan semua aturan yang tidak diizinkan, untuk domain SELinux AOSP serta domain khusus perangkat/vendor.
  • [C-1-5] HARUS menjalankan aplikasi pihak ketiga yang menargetkan API level 28 atau yang lebih tinggi dalam sandbox SELinux per aplikasi dengan batasan SELinux per aplikasi di setiap aplikasi direktori data pribadi aplikasi Anda.
  • HARUS mempertahankan kebijakan SELinux default yang disediakan dalam sistem/sepolicy dari Proyek Open Source Android upstream dan hanya menambahkan kebijakan untuk konfigurasi khusus perangkat mereka sendiri.

Jika implementasi perangkat menggunakan {i>kernel<i} selain Linux atau Linux tanpa SELinux, mereka:

  • [C-2-1] HARUS menggunakan sistem kontrol akses wajib yang setara dengan SELinux.

Jika implementasi perangkat menggunakan perangkat I/O yang mendukung DMA, implementasi tersebut:

  • [C-SR-9] SANGAT DIREKOMENDASIKAN untuk mengisolasi setiap perangkat I/O yang mampu DMA, menggunakan IOMMU (misalnya ARM SMMU).

Android memuat beberapa fitur defense in depth yang integral dengan perangkat keamanan. Selain itu, Android berfokus pada pengurangan kelas utama bug umum yang berkontribusi pada kualitas dan keamanan yang buruk.

Untuk mengurangi bug memori, implementasi perangkat:

  • [C-SR-10] SANGAT DIREKOMENDASIKAN untuk diuji menggunakan error memori userspace alat deteksi seperti MTE untuk perangkat ARMv9, HWASan untuk perangkat ARMv8+, atau ASan untuk jenis perangkat lainnya.
  • [C-SR-11] SANGAT DIREKOMENDASIKAN untuk diuji menggunakan error memori kernel alat deteksi seperti KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS untuk Perangkat ARMv9, CONFIG_KASAN_SW_TAGS untuk perangkat ARMv8 atau CONFIG_KASAN_GENERIC untuk jenis perangkat lainnya).
  • [C-SR-12] SANGAT DIREKOMENDASIKAN untuk menggunakan alat deteksi kesalahan memori dalam produksi seperti MTE, GWP-ASan, dan KFENCE.

Jika implementasi perangkat menggunakan TEE berbasis Arm TrustZone, implementasi tersebut:

  • [C-SR-13] SANGAT DIREKOMENDASIKAN untuk menggunakan protokol standar untuk memori berbagi, antara Android dan TEE, seperti Arm Firmware Framework untuk Armv8-A (FF-A).
  • [C-SR-14] SANGAT DIREKOMENDASIKAN untuk membatasi penggunaan aplikasi tepercaya mengakses memori yang telah secara eksplisit dibagikan dengan mereka melalui metode di atas dan berperforma tinggi karena merupakan protokol biner. Jika perangkat memiliki dukungan untuk level pengecualian Arm S-EL2, harus diberlakukan oleh pengelola partisi yang aman. Jika tidak, ini harus berupa diberlakukan oleh TEE OS.

9.8. Privasi

9.8.1 Histori Penggunaan

Android menyimpan histori pilihan pengguna dan mengelola histori tersebut dengan UsageStatsManager telah dilakukan.

Implementasi perangkat:

  • [C-0-1] HARUS mempertahankan periode retensi yang wajar untuk histori pengguna tersebut.
  • [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mempertahankan periode retensi data 14 hari sebagai dikonfigurasi secara default dalam implementasi AOSP.

Android menyimpan peristiwa sistem menggunakan StatsLog ID, dan mengelola histori tersebut melalui StatsManager dan API Sistem IncidentManager.

Implementasi perangkat:

  • [C-0-2] HARUS menyertakan kolom yang ditandai dengan DEST_AUTOMATIC di kolom laporan insiden yang dibuat oleh class System API IncidentManager.
  • [C-0-3] TIDAK BOLEH menggunakan ID peristiwa sistem untuk mencatat log peristiwa lainnya daripada yang dijelaskan dalam StatsLog Dokumen SDK. Jika peristiwa sistem tambahan dicatat, mereka MUNGKIN menggunakan pengidentifikasi atom yang berbeda dalam rentang antara 100.000 dan 200.000.

9.8.2. Merekam

Implementasi perangkat:

  • [C-0-1] TIDAK BOLEH melakukan pramuat atau mendistribusikan komponen software siap pakai yang mengirim informasi pribadi pengguna (mis. penekanan tombol, teks yang ditampilkan pada layar, laporan bug) keluar dari perangkat tanpa izin pengguna atau menghapus notifikasi berkelanjutan.
  • [C-0-2] HARUS menampilkan dan memperoleh izin eksplisit dari pengguna yang mengizinkan semua informasi yang ditampilkan di layar pengguna agar ditangkap kapan saja {i>screencast <i}atau perekaman layar diaktifkan melalui MediaProjection atau API eksklusif. TIDAK BOLEH memberi pengguna keleluasaan untuk menonaktifkan langganan di masa mendatang tampilan izin pengguna.
  • [C-0-3] HARUS ada notifikasi berkelanjutan kepada pengguna saat transmisi layar atau perekaman layar diaktifkan. AOSP memenuhi persyaratan ini dengan menampilkan ikon notifikasi berkelanjutan di status bar.

Jika implementasi perangkat menyertakan fungsionalitas dalam sistem yang menangkap konten yang ditampilkan di layar dan/atau merekam streaming audio diputar di perangkat selain melalui System API ContentCaptureService, atau cara eksklusif lainnya yang dijelaskan dalam Bagian 9.8.6 Pengambilan Konten, mereka:

  • [C-1-1] HARUS ada notifikasi berkelanjutan kepada pengguna setiap kali diaktifkan dan secara aktif merekam/merekam.

Jika implementasi perangkat menyertakan komponen yang diaktifkan {i>out-of-box<i}, yang mampu merekam audio sekitar dan/atau merekam audio yang diputar di perangkat untuk menyimpulkan informasi yang berguna tentang konteks pengguna, mereka:

  • [C-2-1] TIDAK BOLEH disimpan di penyimpanan perangkat yang persisten atau mengirimkan perangkat audio mentah yang direkam atau format apa pun yang dapat dikonversi kembali menjadi audio asli atau faksimili dekat, kecuali dengan persetujuan eksplisit dari pengguna.

“Indikator mikrofon” mengacu pada tampilan di layar, yang terus terlihat kepada pengguna dan tidak dapat dikaburkan, yang dipahami pengguna sebagai mikrofon gunakan(melalui teks, warna, ikon yang unik, atau kombinasinya).

"Indikator kamera" mengacu pada tampilan di layar, yang terus terlihat oleh pengguna dan tidak dapat dikaburkan, yang dipahami pengguna sebagai kamera sedang digunakan (melalui teks, warna, ikon yang unik, atau kombinasi tertentu).

Setelah detik pertama ditampilkan, indikator dapat berubah secara visual, seperti menjadi lebih kecil, dan tidak diharuskan untuk menunjukkan sebagaimana disajikan dan dipahami.

Indikator mikrofon dapat digabungkan dengan kamera yang aktif ditampilkan asalkan teks, ikon, atau warna menunjukkan kepada pengguna bahwa penggunaan mikrofon telah dimulai.

Indikator kamera dapat digabungkan dengan mikrofon yang ditampilkan secara aktif asalkan teks, ikon, atau warna menunjukkan kepada pengguna bahwa penggunaan kamera telah dimulai.

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

  • [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menampilkan indikator mikrofon saat aplikasi mengakses data audio dari mikrofon, tetapi tidak saat mikrofon hanya diakses oleh HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService, atau aplikasi yang memiliki peran yang disebutkan di Bagian 9.1 Izin dengan pengenal CDD [C-3-X]. .
  • [C-SR-2] SANGAT DIREKOMENDASIKAN untuk menampilkan daftar Terbaru dan Aktif aplikasi yang menggunakan mikrofon seperti yang ditampilkan PermissionManager.getIndicatorAppOpUsageData(), bersama dengan atribusi apa pun pesan yang terkait dengannya.
  • [C-SR-3] SANGAT DIREKOMENDASIKAN untuk tidak menyembunyikan indikator mikrofon untuk aplikasi sistem yang memiliki antarmuka pengguna yang terlihat atau interaksi pengguna langsung.

Jika implementasi perangkat mendeklarasikan android.hardware.camera.any, implementasi tersebut:

  • [C-SR-4] SANGAT DIREKOMENDASIKAN untuk menampilkan indikator kamera saat aplikasi mengakses data kamera live, tetapi tidak saat kamera hanya diakses oleh aplikasi yang memegang peran yang disebutkan di Bagian 9.1 Izin dengan CDD ID [C-3-X].
  • [C-SR-5] SANGAT DIREKOMENDASIKAN untuk menampilkan aplikasi Terbaru dan Aktif menggunakan kamera seperti yang ditampilkan dari PermissionManager.getIndicatorAppOpUsageData(), beserta pesan atribusi apa pun yang terkait.
  • [C-SR-6] SANGAT DIREKOMENDASIKAN untuk tidak menyembunyikan indikator kamera untuk sistem aplikasi yang memiliki antarmuka pengguna yang terlihat atau interaksi pengguna langsung.

9.8.3. Konektivitas

Jika implementasi perangkat memiliki porta USB dengan dukungan mode periferal USB, mereka:

  • [C-1-1] HARUS menampilkan antarmuka pengguna yang meminta persetujuan pengguna sebelum memungkinkan akses ke isi penyimpanan bersama melalui porta USB.

9.8.4. Traffic Jaringan

Implementasi perangkat:

  • [C-0-1] HARUS melakukan prainstal root certificate yang sama untuk sistem tepercaya Toko Certificate Authority (CA) sebagaimana disediakan di Project Open Source Android upstream.
  • [C-0-2] HARUS mengirimkan dengan penyimpanan CA root pengguna kosong.
  • [C-0-3] HARUS menampilkan peringatan kepada pengguna yang menunjukkan traffic jaringan dapat dipantau, ketika CA {i>root<i} pengguna ditambahkan.

Jika traffic perangkat dirutekan melalui VPN, implementasi perangkat akan:

  • [C-1-1] HARUS menampilkan peringatan kepada pengguna yang menunjukkan:
    • Traffic jaringan tersebut mungkin dipantau.
    • Lalu lintas jaringan itu diarahkan melalui VPN khusus aplikasi yang menyediakan VPN.

Jika implementasi perangkat memiliki mekanisme, yang diaktifkan secara {i>default<i}, maka mengarahkan traffic data jaringan melalui server proxy atau gateway VPN (misalnya, melakukan pramuat layanan VPN dengan android.permission.CONTROL_VPN diberikan), tindakan tersebut:

  • [C-2-1] HARUS meminta persetujuan pengguna sebelum mengaktifkan mekanisme tersebut, kecuali jika VPN diaktifkan oleh Pengontrol Kebijakan Perangkat melalui DevicePolicyManager.setAlwaysOnVpnPackage() , dalam hal ini pengguna tidak perlu memberikan izin terpisah, tetapi HARAP diberi tahu saja.

Jika implementasi perangkat menerapkan affordance pengguna untuk mengaktifkan "VPN selalu aktif" aplikasi VPN pihak ketiga, mereka:

  • [C-3-1] HARUS menonaktifkan kemampuan pengguna ini untuk aplikasi yang tidak mendukung layanan VPN yang selalu aktif di file AndroidManifest.xml melalui setelan SERVICE_META_DATA_SUPPORTS_ALWAYS_ON ke false.

9.8.5. ID Perangkat

Implementasi perangkat:

  • [C-0-1] HARUS mencegah akses ke nomor seri perangkat dan, jika IMEI/MEID, nomor seri SIM, dan Perangkat Seluler Internasional Identitas Pelanggan (IMSI) dari aplikasi, kecuali jika memenuhi salah satu persyaratan berikut persyaratan:
    • adalah aplikasi operator bertanda tangan yang diverifikasi oleh produsen perangkat.
    • telah diberi izin READ_PRIVILEGED_PHONE_STATE.
    • memiliki hak istimewa operator seperti yang ditetapkan dalam Hak Istimewa Operator UICC.
    • adalah pemilik perangkat atau pemilik profil yang telah diberi Izin READ_PHONE_STATE.
    • (Hanya untuk nomor seri SIM/ICCID) memiliki persyaratan peraturan setempat aplikasi mendeteksi perubahan identitas pelanggan.

9.8.6. Pengambilan Konten dan Penelusuran Aplikasi

Android, melalui System API ContentCaptureService, AugmentedAutofillService, AppSearchGlobalManager.query, atau oleh berarti eksklusif, mendukung mekanisme implementasi perangkat untuk menangkap interaksi data aplikasi berikut antara aplikasi dan pengguna:

  • Teks dan grafis yang dirender di layar, termasuk, tetapi tidak terbatas pada, notifikasi dan data bantuan melalui AssistStructure Compute Engine API.
  • Data media, seperti audio atau video, yang direkam atau diputar oleh perangkat.
  • Peristiwa input (misalnya, tombol, mouse, gestur, suara, video, dan aksesibilitas).
  • Peristiwa lain yang disediakan aplikasi ke sistem melalui Content Capture API atau AppSearchManager API Android dan API eksklusif.
  • Teks atau data lainnya yang dikirim melalui TextClassifier API ke System TextClassifier, yaitu ke layanan sistem untuk memahami arti teks, serta menghasilkan prediksi tindakan berikutnya berdasarkan teks.
  • Data yang diindeks oleh penerapan AppSearch platform, termasuk, tetapi tidak terbatas pada teks, grafik, data media, atau data serupa lainnya.

Jika implementasi perangkat mengambil data di atas, implementasi tersebut:

  • [C-1-1] HARUS mengenkripsi semua data tersebut saat disimpan di perangkat. Ini enkripsi DAPAT dilakukan dengan menggunakan Enkripsi Berbasis File Android, atau sandi yang tercantum sebagai API versi 26+ yang dijelaskan dalam Cipher SDK.
  • [C-1-2] TIDAK BOLEH mencadangkan data mentah atau terenkripsi dengan Metode pencadangan Android atau metode pencadangan lainnya naik.
  • [C-1-3] Hanya boleh mengirim semua data tersebut dan log perangkat menggunakan mekanisme yang menjaga privasi. Mekanisme yang menjaga privasi didefinisikan sebagai “tindakan yang hanya memungkinkan analisis secara agregat dan mencegah pencocokan peristiwa yang dicatat dalam log atau hasil turunan kepada setiap pengguna”, untuk mencegah data per pengguna dapat dimasukkan (misalnya, diterapkan menggunakan teknologi privasi diferensial seperti RAPPOR).
  • [C-1-4] TIDAK BOLEH mengaitkan data tersebut dengan identitas pengguna apa pun (seperti sebagai Account) di perangkat, kecuali dengan persetujuan eksplisit dari pengguna setiap kali yang terkait.
  • [C-1-5] TIDAK BOLEH berbagi data tersebut dengan komponen OS lain yang tidak mengikuti persyaratan yang diuraikan di bagian saat ini (9.8.6 Pengambilan Konten), kecuali dengan izin eksplisit dari pengguna setiap saat file itu dibagikan.
  • [C-1-6] HARUS memberikan kemampuan pengguna untuk menghapus data yang ContentCaptureService atau sarana eksklusif mengumpulkan jika data disimpan dalam bentuk apa pun di perangkat.
  • [C-1-7] HARUS memberikan keleluasaan pengguna untuk memilih tidak menggunakan data, yang dikumpulkan melalui AppSearch atau sarana eksklusif agar tidak ditampilkan di platform Android misalnya, peluncur.
  • [C-SR-1] SANGAT DIREKOMENDASIKAN UNTUK TIDAK meminta izin INTERNET.
  • [C-SR-2] SANGAT DIREKOMENDASIKAN untuk hanya mengakses internet melalui API terstruktur yang didukung oleh implementasi open source yang tersedia secara publik.

Jika implementasi perangkat menyertakan layanan yang mengimplementasikan System API ContentCaptureService, AppSearchManager.index, atau layanan eksklusif apa pun yang mengambil data seperti yang dijelaskan di atas, mereka:

  • [C-2-1] TIDAK BOLEH mengizinkan pengguna untuk mengganti layanan dengan aplikasi atau layanan yang dapat diinstal pengguna dan HARUS hanya mengizinkan layanan bawaan untuk mengambil data tersebut.
  • [C-2-2] TIDAK BOLEH mengizinkan aplikasi apa pun selain layanan bawaan mekanisme atensi untuk dapat mengambil data tersebut.
  • [C-2-3] HARUS memberikan affordance pengguna untuk menonaktifkan layanan.
  • [C-2-4] TIDAK BOLEH menghilangkan kemampuan pengguna untuk mengelola izin Android yang dimiliki oleh layanan dan mengikuti izin Android seperti yang dijelaskan dalam Bagian 9.1. Izin.

  • [C-SR-3] SANGAT DIREKOMENDASIKAN untuk menjaga agar layanan tetap terpisah dari layanan lainnya komponen sistem(misalnya tidak mengikat layanan atau berbagi ID proses) kecuali untuk hal berikut:

    • Telepon, Kontak, UI Sistem, dan Media

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

9.8.7. Akses Papan Klip

Implementasi perangkat:

  • [C-0-1] TIDAK BOLEH mengembalikan data yang terpotong dari clipboard (mis. melalui ClipboardManager API) kecuali aplikasi pihak ketiga adalah IME default atau aplikasi yang sedang fokus.
  • [C-0-2] HARUS menghapus data papan klip paling lama 60 menit setelah ditempatkan di {i>clipboard<i} atau dibaca dari {i>clipboard<i}.

9.8.8. Lokasi

Lokasi mencakup informasi dalam kelas Lokasi Android( seperti Latitude, Bujur, Ketinggian), serta ID yang dapat dikonversi menjadi Lokasi. Lokasi dapat sebaik DGPS (Sistem Pemosisi Global Diferensial) atau sebesar perkiraan lokasi tingkat negara (seperti lokasi kode negara - MCC - Seluler Kode Negara).

Berikut adalah daftar jenis lokasi yang secara langsung memperoleh lokasi atau dapat dikonversi ke lokasi pengguna. Ini bukanlah tetap saja, tetapi harus digunakan sebagai contoh tentang apa yang dapat langsung dilakukan oleh secara tidak langsung berasal dari:

  • GPS/GNSS/DGPS/PPP
    • Solusi Pemosisi Global atau Sistem Satelit Navigasi Global atau Solusi Pemosisi Global Diferensial
    • Ini juga mencakup Pengukuran GNSS Mentah dan Status GNSS
      • Lokasi terperinci dapat berasal dari Pengukuran GNSS Mentah
  • Teknologi Nirkabel dengan ID unik seperti:
    • Titik akses Wi-Fi (MAC, BSSID, Nama, atau SSID)
    • Bluetooth/BLE (MAC, BSSID, Nama, atau SSID)
    • UWB (MAC, BSSID, Nama, atau SSID)
    • ID Menara Seluler (3G, 4G, 5G... Itermasuk semua Modem Seluler masa depan teknologi yang memiliki ID unik)

Sebagai titik referensi utama, lihat API Android yang memerlukan Izin ACCESS_FINE_Location atau ACCESS_COARSE_Location.

Implementasi perangkat:

  • [C-0-1] TIDAK BOLEH mengaktifkan/menonaktifkan pengaturan lokasi perangkat dan Wi-Fi/Bluetooth setelan pemindaian tanpa izin eksplisit dari pengguna atau inisiasi pengguna.
  • [C-0-2] HARUS memberikan kemampuan kepada pengguna untuk mengakses lokasi terkait informasi, termasuk permintaan lokasi terbaru, izin tingkat aplikasi, dan penggunaan pemindaian Wi-Fi/Bluetooth untuk menentukan lokasi.
  • [C-0-3] HARUS memastikan bahwa aplikasi yang menggunakan Darurat Lokasi Pengabaian API [LocationRequest.setLocationSettingsIgnored()] adalah keadaan darurat yang dimulai oleh pengguna sesi (misalnya, hubungi 911 atau SMS ke 911). Namun, untuk Otomotif, kendaraan MUNGKIN memulai sesi darurat tanpa interaksi pengguna aktif dalam kasus tabrakan/kecelakaan terdeteksi (mis. untuk memenuhi persyaratan eCall).
  • [C-0-4] HARUS mempertahankan kemampuan Darurat Location Pengabaian API untuk mengabaikan setelan lokasi perangkat tanpa mengubah setelan.
  • [C-0-5] HARUS menjadwalkan notifikasi yang mengingatkan pengguna setelah aplikasi di latar belakang telah mengakses lokasi mereka menggunakan [ACCESS_BACKGROUND_LOCATION].

9.8.9. Aplikasi terinstal

Aplikasi Android yang menargetkan API level 30 atau yang lebih tinggi tidak dapat melihat detail tentang aplikasi terinstal secara default (lihat Visibilitas paket di Android dokumentasi SDK).

Implementasi perangkat:

  • [C-0-1] TIDAK BOLEH mengekspos ke detail aplikasi apa pun yang menargetkan API level 30 atau yang lebih tinggi tentang aplikasi terinstal lainnya, kecuali aplikasi tersebut sudah dapat melihat detailnya tentang aplikasi terinstal lainnya melalui API terkelola. Ini mencakup, tetapi tidak terbatas pada detail yang diekspos oleh API kustom apa pun yang ditambahkan oleh perangkat implementasi, atau dapat diakses melalui sistem file.
  • [C-0-2] TIDAK BOLEH memberi kepada aplikasi apa pun, akses baca atau tulis ke file di direktori khusus aplikasi dalam penyimpanan eksternal. Satu-satunya pengecualian adalah sebagai berikut:
    • Otoritas penyedia penyimpanan eksternal (misalnya, aplikasi seperti DocumentsUI).
    • Penyedia Download yang menggunakan otoritas penyedia “download” untuk mengunduh file ke penyimpanan aplikasi.
    • Aplikasi protokol transfer media (MTP) yang ditandatangani platform yang menggunakan izin istimewa ACCESS_MTP untuk memungkinkan transfer file ke perangkat lain.
    • Aplikasi yang menginstal aplikasi lain dan memiliki izin INSTAL_PACKAGES hanya dapat mengakses direktori “obb” untuk tujuan pengelolaan File ekspansi APK.

9.8.10. Laporan Bug Konektivitas

Jika implementasi perangkat mendeklarasikan tombol fitur android.hardware.telephony, mereka:

  • [C-1-1] HARUS mendukung pembuatan laporan bug konektivitas melalui BUGREPORT_MODE_TELEPHONY dengan BugreportManager.
  • [C-1-2] HARUS mendapatkan izin pengguna setiap kali BUGREPORT_MODE_TELEPHONY digunakan untuk membuat laporan dan TIDAK BOLEH meminta pengguna untuk menyetujui semua permintaan berikutnya dari aplikasi.
  • [C-1-3] TIDAK BOLEH menampilkan laporan yang dihasilkan ke aplikasi yang meminta tanpa persetujuan eksplisit dari pengguna.
  • [C-1-4] Laporan yang dibuat menggunakan BUGREPORT_MODE_TELEPHONY HARUS berisi setidaknya informasi berikut:
    • Dump TelephonyDebugService
    • Dump TelephonyRegistry
    • Dump WifiService
    • Dump ConnectivityService
    • Dump instance CarrierService paket panggilan (jika terikat)
    • Buffer log radio
  • [C-1-5] TIDAK BOLEH menyertakan hal berikut dalam laporan yang dihasilkan:
    • Segala jenis informasi yang tidak terkait langsung dengan konektivitas proses debug.
    • Segala jenis log traffic aplikasi yang diinstal pengguna atau profil mendetail aplikasi/paket yang diinstal pengguna (UID tidak apa-apa, nama paket tidak).
  • DAPAT mencakup informasi tambahan yang tidak terkait dengan pengguna mana pun identitas Anda. (misalnya, log vendor).

Jika implementasi perangkat menyertakan informasi tambahan (mis. log vendor) di laporan bug dan informasi tersebut memiliki privasi/keamanan/baterai/penyimpanan/memori dampaknya, mereka:

  • [C-SR-1] SANGAT DIREKOMENDASIKAN agar setelan developer ditetapkan secara default ke dinonaktifkan. Implementasi referensi AOSP memenuhi hal ini dengan menyediakan Enable verbose vendor logging opsi di setelan developer untuk menyertakan log vendor khusus perangkat tambahan di laporan bug.

9.8.11. Berbagi blob data

Android, melalui BlobStoreManager memungkinkan aplikasi memberikan blob data ke Sistem untuk dibagikan ke pengguna yang dipilih sekumpulan aplikasi.

Jika implementasi perangkat mendukung blob data bersama seperti yang dijelaskan dalam Dokumentasi SDK, mereka:

9.8.12. Pengenalan Musik

Android, melalui System API MusicRecognitionManager, mendukung mekanisme untuk implementasi perangkat untuk meminta pengenalan musik, dengan rekaman audio, dan mendelegasikan pengenalan musik ke aplikasi berhak istimewa yang menerapkan MusicRecognitionService API.

Jika implementasi perangkat menyertakan layanan yang mengimplementasikan System API MusicRecognitionManager atau layanan eksklusif apa pun yang mengalirkan data audio sebagai yang dijelaskan di atas, mereka:

  • [C-1-1] HARUS mewajibkan pemanggil MusicRecognitionManager untuk Izin MANAGE_MUSIC_RECOGNITION
  • [C-1-2] HARUS memberlakukan bahwa satu pengenalan musik mengimplementasikan MusicRecognitionService.
  • [C-1-3] TIDAK BOLEH mengizinkan pengguna mengganti MusicRecognitionManagerService atau MusicRecognitionService dengan aplikasi atau layanan yang dapat diinstal pengguna.
  • [C-1-4] HARUS memastikan bahwa saat MusicRecognitionManagerService mengakses rekaman audio dan meneruskannya ke aplikasi yang menerapkan MusicRecognitionService, akses audio dilacak melalui pemanggilan AppOpsManager.noteOp / startOp.

Jika implementasi perangkat MusicRecognitionManagerService atau MusicRecognitionService menyimpan data audio apa pun yang direkam, yaitu:

  • [C-2-1] TIDAK BOLEH menyimpan sidik jari audio atau audio mentah pada disk, atau dalam memori lebih dari 14 hari.
  • [C-2-2] TIDAK BOLEH membagikan data tersebut di luar MusicRecognitionService, kecuali dengan persetujuan pengguna yang eksplisit setiap kali file dibagikan.

9.8.13. SensorPrivacyManager

Jika implementasi perangkat memberikan kemampuan software untuk dinonaktifkan kepada pengguna input kamera dan/atau mikrofon untuk implementasi perangkat, keduanya:

  • [C-1-1] HARUS menampilkan 'true' secara akurat untuk konten supportsSensorRedirect() Metode API.
  • [C-1-2] HARUS, saat aplikasi mencoba mengakses mikrofon atau kamera yang terhalang, menampilkan kemampuan pengguna yang tidak dapat ditutup secara jelas menunjukkan bahwa sensor diblokir dan memerlukan pilihan untuk melanjutkan memblokir atau membatalkan pemblokiran sesuai implementasi AOSP yang memenuhi persyaratan.
  • [C-1-3] Hanya boleh meneruskan data kamera dan audio kosong (atau palsu) ke aplikasi dan tidak melaporkan kode error karena pengguna tidak mengaktifkan kamera maupun mikrofon melalui kemampuan pengguna yang ditampilkan sesuai [C-1-2] di atas.

9,9. Enkripsi Penyimpanan Data

Semua perangkat HARUS memenuhi persyaratan pasal 9.9.1. Perangkat yang diluncurkan pada level API lebih awal dari dokumen ini dikecualikan dari persyaratan pasal 9.9.2 dan 9.9.3; sebagai gantinya, HARUS memenuhi persyaratan dalam pasal 9.9 Kompatibilitas Android Dokumen definisi yang sesuai dengan level API tempat perangkat diluncurkan.

9.9.1 Direct Boot

Implementasi perangkat:

  • [C-0-1] HARUS menerapkan API mode Direct Boot meskipun jika tetapi tidak mendukung Enkripsi Penyimpanan.

  • [C-0-2] ACTION_LOCKED_BOOT_COMPLETED dan ACTION_USER_UNLOCKED {i>Intent<i} harus tetap disiarkan untuk memberi sinyal pada aplikasi yang {i>Direct Boot<i} yang Lokasi penyimpanan yang Dienkripsi Perangkat (DE) dan Enkripsi Kredensial (CE) yang tersedia untuk pengguna.

9.9.2. Persyaratan enkripsi

Implementasi perangkat:

  • [C-0-1] HARUS mengenkripsi aplikasi pribadi data (partisi /data), serta partisi penyimpanan bersama aplikasi (partisi /sdcard) jika merupakan bagian perangkat yang permanen dan tidak dapat dilepas.
  • [C-0-2] HARUS mengaktifkan enkripsi penyimpanan data secara default pada saat pengguna telah menyelesaikan pengalaman pengaturan yang siap pakai.

  • [C-0-3] HARUS memenuhi enkripsi penyimpanan data di atas persyaratan dengan menerapkan salah satu dari dua metode enkripsi berikut:

9.9.3. Metode Enkripsi

Jika implementasi perangkat dienkripsi, implementasi tersebut:

  • [C-1-1] HARUS melakukan booting tanpa menantang pengguna untuk kredensial dan izinkan aplikasi yang mendukung Direct Boot untuk mengakses penyimpanan Device Encrypted (DE) setelah pesan ACTION_LOCKED_BOOT_COMPLETED disiarkan.
  • [C-1-2] HARUS mengizinkan akses ke penyimpanan Enkripsi Kredensial (CE) hanya setelah pengguna telah membuka kunci perangkat dengan memberikan kredensialnya (misalnya, kode sandi, PIN, pola, atau sidik jari) dan ACTION_USER_UNLOCKED pesan disiarkan.
  • [C-1-13] TIDAK BOLEH menawarkan metode apa pun untuk membuka kunci penyimpanan yang dilindungi CE tanpa kredensial yang diberikan pengguna, kunci {i>escrow <i}yang terdaftar, atau melanjutkan implementasi {i>reboot<i} yang memenuhi persyaratan dalam pasal 9.9.4.
  • [C-1-4] HARUS menggunakan Booting Terverifikasi.
9.9.3.1 Enkripsi Berbasis File dengan Enkripsi Metadata

Jika implementasi perangkat menggunakan Enkripsi Berbasis File dengan Enkripsi Metadata, mereka:

  • [C-1-5] HARUS mengenkripsi konten file dan metadata sistem file menggunakan AES-256-XTS atau Adiantum. AES-256-XTS mengacu pada {i>Advanced Encryption Standard<i} dengan panjang kunci penyandian 256-bit, yang dioperasikan dalam mode XTS; dengan lengkap kuncinya adalah 512 bit. Adiantum mengacu kepada Adiantum-XChaCha12-AES, seperti yang https://github.com/google/adiantum? Metadata sistem file adalah data seperti file ukuran, kepemilikan, mode, dan atribut yang diperluas (xattrs).
  • [C-1-6] HARUS mengenkripsi nama file menggunakan AES-256-CBC-CTS atau Adiantum.
  • [C-1-12] Jika perangkat memiliki Advanced Encryption Standard (AES) (seperti Ekstensi Kriptografi ARMv8 pada perangkat berbasis ARM, atau AES-NI di perangkat berbasis x86) lalu opsi berbasis AES di atas untuk nama file, konten file, dan enkripsi metadata sistem file HARUS digunakan, bukan Adiantum.
  • [C-1-13] HARUS menggunakan kunci yang kuat secara kriptografis dan tidak dapat dibalik (mis. HKDF-SHA512) untuk mendapatkan subkunci yang diperlukan (mis. per file) dari kunci CE dan DE. “Kuat secara kriptografis dan tidak dapat dibatalkan" berarti fungsi derivasi kunci memiliki kekuatan keamanan minimal 256 bit dan berperilaku sebagai fungsi pseudorandom keluarga daripada input-nya.
  • [C-1-14] TIDAK BOLEH menggunakan kunci atau subkunci Enkripsi Berbasis File (FBE) yang sama untuk tujuan kriptografi berbeda (mis. untuk enkripsi maupun kunci , atau untuk dua algoritma enkripsi yang berbeda).
  • [C-1-15] HARUS memastikan bahwa semua blok konten file terenkripsi yang tidak dihapus pada penyimpanan persisten dienkripsi menggunakan kombinasi kunci enkripsi dan vektor inisialisasi (IV) yang bergantung pada file dan offset dalam file tersebut. Selain itu, semua kombinasi tersebut HARUS berbeda, kecuali jika enkripsi dilakukan dengan menggunakan perangkat keras enkripsi {i>inline<i} yang hanya mendukung Panjang IV 32 bit.
  • [C-1-16] HARUS memastikan bahwa semua nama file terenkripsi yang tidak dihapus pada penyimpanan di direktori yang berbeda dienkripsi menggunakan kombinasi kunci enkripsi dan initialization vector (IV).

  • [C-1-17] HARUS memastikan bahwa semua blok metadata sistem file terenkripsi pada persistent storage{i> <i}dienkripsi menggunakan kombinasi kunci enkripsi yang berbeda dan initialization vector (IV).

  • Kunci yang melindungi area penyimpanan CE dan DE serta metadata sistem file:

    • [C-1-7] HARUS terikat secara kriptografis ke Keystore yang didukung hardware. Keystore ini HARUS terikat dengan Booting Terverifikasi dan hardware perangkat akar kepercayaan.
    • [C-1-8] Kunci CE HARUS terikat dengan kredensial layar kunci pengguna.
    • [C-1-9] Kunci CE HARUS terikat dengan kode sandi default jika pengguna telah kredensial layar kunci yang tidak ditentukan.
    • [C-1-10] HARUS unik dan berbeda, dengan kata lain, tidak ada CE atau DE pengguna cocok dengan kunci CE atau DE pengguna lainnya.
    • [C-1-11] HARUS menggunakan penyandian, panjang kunci, dan mode.
    • [C-1-12] HARUS dihapus dengan aman selama membuka kunci dan mengunci bootloader sebagaimana dijelaskan di sini.

  • HARUS membuat aplikasi penting yang sudah diinstal sebelumnya (misalnya Alarm, Telepon, Messenger) Mendukung Direct Boot.

Proyek Open Source Android upstream menyediakan implementasi yang lebih disukai dari Enkripsi Berbasis File berdasarkan kernel Linux "fscrypt" fitur enkripsi, dan Enkripsi Metadata berdasarkan kernel Linux "dm-default-key" aplikasi baru.

9.9.3.2. Enkripsi Tingkat Blok Per Pengguna

Jika implementasi perangkat menggunakan enkripsi tingkat blok per pengguna, implementasi tersebut:

  • [C-1-1] HARUS mengaktifkan dukungan multi-pengguna sebagaimana dijelaskan dalam bagian 9.5.
  • [C-1-2] HARUS menyediakan partisi per pengguna, baik menggunakan partisi mentah atau volume logis.
  • [C-1-3] HARUS menggunakan kunci enkripsi yang unik dan berbeda per pengguna untuk enkripsi perangkat blok yang mendasarinya.

  • [C-1-4] HARUS menggunakan AES-256-XTS untuk enkripsi pengguna tingkat blok partisi.

  • Kunci yang melindungi perangkat terenkripsi tingkat blok per pengguna:

    • [C-1-5] HARUS terikat secara kriptografis ke Keystore yang didukung hardware. Keystore ini HARUS terikat dengan Booting Terverifikasi dan hardware perangkat akar kepercayaan.
    • [C-1-6] HARUS terikat ke layar kunci pengguna yang sesuai memiliki kredensial yang lengkap.

Enkripsi tingkat blok per pengguna dapat diimplementasikan menggunakan kernel Linux "dm-crypt" di atas partisi per pengguna.

9.9.4. Lanjutkan saat Mulai Ulang

Lanjutkan saat Mulai Ulang memungkinkan pembukaan kunci penyimpanan CE semua aplikasi, termasuk aplikasi yang belum mendukung Direct Boot, setelah {i>reboot<i} yang dimulai oleh OTA. Ini memungkinkan pengguna menerima notifikasi dari aplikasi terinstal setelah memulai ulang.

Penerapan {i>Resume-on-Reboot <i}harus dilanjutkan untuk memastikan bahwa ketika perangkat jatuh ke tangan penyerang, akan sangat sulit untuk penyerang untuk memulihkan data pengguna yang dienkripsi CE, meskipun perangkat dinyalakan aktif, penyimpanan CE dibuka kuncinya, dan pengguna membuka kunci perangkat setelah menerima OTA. Untuk ketahanan terhadap serangan orang dalam, kita juga berasumsi bahwa penyerang mendapatkan akses untuk menyiarkan kunci penandatanganan kriptografi.

Khususnya:

  • [C-0-1] Penyimpanan CE TIDAK BOLEH dapat dibaca bahkan oleh penyerang yang secara fisik telah perangkat serta memiliki kemampuan dan batasan berikut:

    • Dapat menggunakan kunci penandatanganan vendor atau perusahaan mana pun untuk menandatangani secara arbitrer membuat pesan teks.
    • Dapat menyebabkan OTA diterima oleh perangkat.
    • Dapat memodifikasi operasi perangkat keras apa pun (AP, flash, dll.) kecuali sebagai dijelaskan di bawah, tetapi modifikasi tersebut memerlukan penundaan setidaknya jam dan siklus daya yang menghancurkan isi RAM.
    • Tidak dapat memodifikasi pengoperasian hardware yang tahan perusakan (misalnya, Titan M).
    • Tidak dapat membaca RAM perangkat aktif.
    • Tidak bisa mendapatkan kredensial pengguna (PIN, pola, sandi) atau jika tidak menyebabkan input tersebut.

Misalnya, implementasi perangkat yang mengimplementasikan dan mematuhi semua deskripsi yang ada di sini akan mematuhi [C-0-1].

9.10. Integritas Perangkat

Persyaratan berikut memastikan adanya transparansi terkait status integritas perangkat. Implementasi perangkat:

  • [C-0-1] HARUS melaporkan dengan benar melalui metode System API PersistentDataBlockManager.getFlashLockState() apakah bootloader-nya memungkinkan flash image sistem.

  • [C-0-2] HARUS mendukung Booting Terverifikasi untuk integritas perangkat.

Jika implementasi perangkat sudah diluncurkan tanpa mendukung Booting Terverifikasi pada versi Android yang lebih lama dan tidak dapat menambahkan dukungan untuk update software sistem, mereka DAPAT dikecualikan dari persyaratan.

Booting Terverifikasi adalah fitur yang menjamin integritas perangkat {i>software<i}. Jika implementasi perangkat mendukung fitur tersebut, implementasi tersebut:

  • [C-1-1] HARUS mendeklarasikan tombol fitur platform android.software.verified_boot.
  • [C-1-2] HARUS melakukan verifikasi pada setiap urutan booting.
  • [C-1-3] HARUS memulai verifikasi dari kunci perangkat keras yang tidak bisa diubah yang {i>root of trust<i} dan terus berlanjut ke partisi sistem.
  • [C-1-4] HARUS menerapkan setiap tahap verifikasi untuk memeriksa integritas dan keaslian semua byte di tahap berikutnya sebelum mengeksekusi kode tahap selanjutnya.
  • [C-1-5] HARUS menggunakan algoritma verifikasi yang sekuat saat ini rekomendasi dari NIST untuk algoritma hashing (SHA-256) dan kunci publik (RSA-2048).
  • [C-1-6] TIDAK BOLEH mengizinkan {i>booting<i} untuk diselesaikan ketika verifikasi sistem gagal, kecuali jika pengguna setuju untuk tetap mencoba {i>booting<i}, dalam hal ini data dari blok penyimpanan yang tidak terverifikasi HARUS tidak digunakan.
  • [C-1-7] TIDAK BOLEH mengizinkan partisi terverifikasi di perangkat untuk diubah kecuali pengguna telah secara eksplisit membuka kunci {i>bootloader<i}.
  • [C-SR-1] Jika ada beberapa {i>chip<i} terpisah di perangkat (mis. radio, prosesor gambar khusus), proses {i>booting <i} dari setiap chip tersebut SANGAT DIREKOMENDASIKAN untuk memverifikasi setiap tahap saat booting.
  • [C-1-8] HARUS menggunakan penyimpanan yang tahan perusakan: untuk menyimpan apakah bootloader tidak terkunci. Penyimpanan yang tahan perusakan berarti bahwa {i>bootloader<i} dapat mendeteksi apakah penyimpanan telah dirusak dari dalam Android.
  • [C-1-9] HARUS meminta persetujuan pengguna saat menggunakan perangkat, dan memerlukan konfirmasi fisik sebelum mengizinkan transisi dari bootloader mode terkunci ke mode bootloader tidak terkunci.
  • [C-1-10] HARUS mengimplementasikan perlindungan rollback untuk partisi yang digunakan oleh Android (mis. booting, partisi sistem) dan menggunakan penyimpanan yang tahan perusakan metadata yang digunakan untuk menentukan versi OS minimum yang diizinkan.
  • [C-1-11] HARUS menghapus semua data pengguna dengan aman selama pembukaan kunci bootloader dan kunci, sesuai dengan '9.12. Penghapusan Data' (termasuk partisi {i>userdata<i} dan setiap ruang NVRAM).
  • [C-SR-2] SANGAT DIREKOMENDASIKAN untuk memverifikasi semua file APK aplikasi dengan hak istimewa dengan rantai kepercayaan yang berakar pada partisi yang dilindungi oleh Booting Terverifikasi.
  • [C-SR-3] SANGAT DIREKOMENDASIKAN untuk memverifikasi artefak yang dapat dieksekusi yang dimuat oleh aplikasi dengan hak istimewa dari luar file APK-nya (seperti kode yang dimuat secara dinamis atau kode yang dikompilasi) sebelum mengeksekusinya atau SANGAT DIREKOMENDASIKAN untuk tidak menjalankannya sama sekali.
  • HARUS menerapkan perlindungan rollback untuk komponen apa pun dengan {i>firmware <i}(mis. modem, kamera) dan SEHARUSNYA menggunakan penyimpanan yang tahan perusakan menyimpan metadata yang digunakan untuk menentukan versi minimum yang diizinkan.

Jika implementasi perangkat sudah diluncurkan tanpa mendukung C-1-8 melalui C-1-11 pada versi Android yang lebih lama dan tidak dapat menambahkan dukungan untuk persyaratan ini dengan pembaruan perangkat lunak sistem, mereka DAPAT dikecualikan dari lainnya.

Proyek Open Source Android upstream menyediakan implementasi yang lebih disukai dari fitur ini di external/avb/ repositori, yang dapat diintegrasikan ke bootloader yang digunakan untuk memuat Android.

Implementasi perangkat:

  • [C-0-3] HARUS mendukung verifikasi konten file secara kriptografis terhadap kunci tepercaya tanpa membaca seluruh file.
  • [C-0-4] TIDAK BOLEH mengizinkan permintaan baca pada file yang dilindungi untuk berhasil saat konten yang dibaca tidak diverifikasi terhadap kunci tepercaya.

Jika implementasi perangkat sudah diluncurkan tanpa kemampuan untuk memverifikasi konten file terhadap kunci tepercaya pada versi Android sebelumnya dan tidak dapat menambahkan mendukung fitur ini dengan update software sistem, fitur tersebut MUNGKIN dikecualikan dari persyaratan. Project Open Source Android upstream menyediakan pilihan implementasi fitur ini berdasarkan fitur fs-verity kernel Linux.

Implementasi perangkat:

Jika implementasi perangkat mendukung Konfirmasi Dilindungi oleh Android API tersebut:

  • [C-3-1] HARUS melaporkan true untuk ConfirmationPrompt.isSupported() Compute Engine API.

  • [C-3-2] HARUS memastikan bahwa kode yang berjalan di Android OS termasuk {i>kernel<i}, berbahaya atau sebaliknya, tidak dapat menghasilkan respons positif tanpa interaksi pengguna.

  • [C-3-3] HARUS memastikan bahwa pengguna dapat meninjau dan menyetujui pesan yang diminta bahkan jika Android OS, termasuk {i>kernel<i}-nya, disusupi.

9.11. Kunci dan Kredensial

Sistem Android Keystore memungkinkan developer aplikasi menyimpan kunci kriptografis dalam penampung dan menggunakannya dalam operasi kriptografis melalui KeyChain API atau Keystore API. Implementasi perangkat:

  • [C-0-1] HARUS mengizinkan setidaknya 8.192 kunci untuk diimpor atau dihasilkan.
  • [C-0-2] Autentikasi layar kunci HARUS mengimplementasikan interval waktu di antara upaya yang gagal. Dengan n sebagai jumlah upaya gagal, waktu Interval minimal HARUS 30 detik selama 9 < n < 30. Untuk n > 29, nilai interval waktu minimal HARUS 30*2^floor((n-30)/10)) detik atau minimal 24 jam, mana saja yang lebih kecil.
  • TIDAK BOLEH membatasi jumlah kunci yang dapat dibuat

Jika implementasi perangkat mendukung layar kunci yang aman, implementasi tersebut:

  • [C-1-1] HARUS mencadangkan implementasi keystore dengan elemen dalam lingkungan eksekusi.
  • [C-1-2] HARUS memiliki implementasi RSA, AES, ECDSA, ECDH (jika IKeyMintDevice didukung), 3DES, dan algoritma kriptografi HMAC dan hash MD5, SHA1, dan SHA-2 berfungsi untuk secara benar mendukung sistem Android Keystore 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 penerapan Andal, tetapi solusi berbasis ARM TrustZone lain atau pihak ketiga yang ditinjau aman implementasi isolasi berbasis hypervisor yang tepat adalah alternatif lainnya.
  • [C-1-3] HARUS melakukan otentikasi layar kunci di lingkungan eksekusi dan hanya jika berhasil, izinkan jaringan {i>key<i} yang akan digunakan. Kredensial layar kunci HARUS disimpan di yang hanya memungkinkan lingkungan eksekusi yang terisolasi untuk menjalankan layar kunci autentikasi. Project Open Source Android upstream menyediakan Gatekeeper Hardware Abstraksi Layer (HAL) dan Trusty, yang dapat digunakan untuk memenuhi persyaratan ini.
  • [C-1-4] HARUS mendukung pengesahan kunci di mana kunci penandatanganan pengesahan dilindungi oleh perangkat keras yang aman dan penandatanganan dilakukan dengan perangkat keras yang aman. Kunci penandatanganan pengesahan HARUS dibagikan ke seluruh jaringan yang cukup besar perangkat untuk mencegah kunci digunakan sebagai pengenal perangkat. Sekali jalan memenuhi persyaratan ini adalah berbagi kunci pengesahan yang sama kecuali pada menghasilkan setidaknya 100.000 unit SKU tertentu. Jika lebih dari 100.000 unit SKU dibuat, kunci yang berbeda MUNGKIN digunakan untuk setiap 100.000 unit.

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.

  • [C-1-5] HARUS mengizinkan pengguna untuk memilih Waktu tunggu tidur untuk transisi dari tidak terkunci ke keadaan terkunci, dengan waktu tunggu minimum yang diizinkan hingga 15 detik. Perangkat otomotif, yang mengunci layar setiap kali head unit dimatikan atau pengguna dialihkan, MUNGKIN TIDAK memiliki Waktu tunggu tidur konfigurasi Anda.
  • [C-1-6] HARUS mendukung salah satu hal berikut:
    • IKeymasterDevice 3.0,
    • IKeymasterDevice 4.0,
    • IKeymasterDevice 4.1,
    • IKeyMintDevice versi 1, atau
    • IKeyMintDevice versi 2.
  • [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung IKeyMintDevice versi 1.

9.11.1 Layar Kunci Aman, Autentikasi, dan Perangkat Virtual

Implementasi AOSP mengikuti model otentikasi bertingkat di mana otentikasi utama berbasis pengetahuan dapat didukung oleh biometrik kuat, atau dengan modalitas tersier yang lebih lemah.

Implementasi perangkat:

  • [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menetapkan hanya salah satu hal berikut sebagai autentikasi utama berikut:
    • PIN numerik
    • {i>Password<i} alfanumerik
    • Pola geser pada petak yang berisi titik 3 x 3

Perhatikan, metode autentikasi di atas disebut sebagai metode autentikasi metode otentikasi utama dalam dokumen ini.

Jika implementasi perangkat menambahkan atau mengubah autentikasi utama yang direkomendasikan metode dan menggunakan metode otentikasi baru sebagai cara yang aman untuk mengunci layar, metode autentikasi yang baru:

Jika implementasi perangkat menambahkan atau mengubah metode autentikasi untuk membuka kunci layar kunci jika didasarkan pada rahasia yang diketahui dan menggunakan otentikasi baru agar diperlakukan sebagai cara yang aman untuk mengunci layar:

  • [C-3-1] Entropi panjang input terpendek yang diizinkan HARUS lebih dari 10 bit.
  • [C-3-2] Entropi maksimum dari semua input yang mungkin HARUS lebih besar dari 18 bit.
  • [C-3-3] Metode otentikasi yang baru TIDAK BOLEH menggantikan metode otentikasi apa pun metode autentikasi utama yang direkomendasikan (yaitu PIN, pola, sandi) diimplementasikan dan disediakan dalam AOSP.
  • [C-3-4] Metode otentikasi yang baru HARUS dinonaktifkan bila Aplikasi Pengontrol Kebijakan Perangkat (DPC) telah menetapkan sandi kebijakan persyaratan melalui DeviceHEADING.setRequiredPasswordComplexity() dengan konstanta kompleksitas yang lebih ketat daripada PASSWORD_COMPLExitY_NONE atau melalui DeviceMediation.setPasswordquality() dengan konstanta yang lebih ketat daripada PASSWORD_Kualitas_BIOMETRIC_WEAK.
  • [C-3-5] Metode otentikasi baru HARUS kembali ke metode metode otentikasi utama yang disarankan (yaitu PIN, pola, {i>password<i}) sekali setiap 72 jam atau kurang ATAU mengungkapkan dengan jelas ke beberapa data tidak akan dicadangkan untuk mempertahankan privasi data mereka.

Jika implementasi perangkat menambahkan atau mengubah autentikasi utama yang direkomendasikan metode untuk membuka kunci layar kunci dan menggunakan metode otentikasi baru yang berdasarkan biometrik untuk diperlakukan sebagai cara yang aman untuk mengunci layar, berikut:

  • [C-4-1] HARUS memenuhi semua persyaratan yang diuraikan dalam pasal 7.3.10 untuk Kelas 1 (sebelumnya Kepraktisan).
  • [C-4-2] HARUS memiliki mekanisme cadangan untuk menggunakan metode otentikasi utama yang didasarkan pada rahasia yang diketahui.
  • [C-4-3] HARUS dinonaktifkan dan hanya izinkan jaringan autentikasi untuk membuka kunci layar saat Pengontrol Kebijakan Perangkat (DPC) aplikasi telah mengatur kebijakan fitur keyguard dengan memanggil metode DevicePolicyManager.setKeyguardDisabledFeatures() , dengan tanda biometrik apa pun yang terkait (yaitu KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE, atau KEYGUARD_DISABLE_IRIS).

Jika metode autentikasi biometrik tidak memenuhi persyaratan untuk Kelas 3 (sebelumnya Kuat) seperti yang dijelaskan di pasal 7.3.10:

  • [C-5-1] Metode HARUS dinonaktifkan jika Pengontrol Kebijakan Perangkat (DPC) telah menetapkan kebijakan kualitas persyaratan {i> password<i} melalui DeviceHEADING.setRequiredPasswordComplexity() dengan bucket kompleksitas yang lebih ketat daripada PASSWORD_COMPLEXITY_LOW atau menggunakan Device disusupi.setPasswordKualitas() dengan konstanta kualitas yang lebih ketat daripada PASSWORD_QUALITY_BIOMETRIC_WEAK.
  • [C-5-2] Pengguna HARUS ditantang untuk mendapatkan saran utama (misalnya: PIN, pola, kata sandi) sebagaimana dijelaskan dalam [C-1-7] dan [C-1-8] di bagian 7.3.10.
  • [C-5-3] Metode TIDAK BOLEH diperlakukan sebagai layar kunci yang aman, dan HARUS memenuhi persyaratan yang dimulai dengan C-8 di bagian ini di bawah.

Jika implementasi perangkat menambahkan atau mengubah metode autentikasi untuk membuka kunci layar kunci dan metode otentikasi baru didasarkan pada token fisik atau lokasinya:

  • [C-6-1] Mereka HARUS memiliki mekanisme cadangan untuk menggunakan salah satu metode otentikasi utama berdasarkan rahasia yang diketahui dan memenuhi persyaratan yang harus diperlakukan sebagai layar kunci yang aman.
  • [C-6-2] Metode baru HARUS dinonaktifkan dan hanya mengizinkan salah satu dari metode otentikasi utama yang disarankan untuk membuka kunci layar ketika Aplikasi Pengontrol Kebijakan Perangkat (DPC) telah menetapkan kebijakan dengan:
  • [C-6-3] Pengguna HARUS ditantang untuk mendapatkan salah satu akses utama yang disarankan metode autentikasi (mis. PIN, pola, sandi) setidaknya sekali setiap 4 jam atau kurang. Ketika token fisik memenuhi persyaratan untuk implementasi TrustAgent di C-X, pembatasan waktu tunggu didefinisikan dalam C-9-5 berlaku sebagai gantinya.
  • [C-6-4] Metode baru TIDAK BOLEH diperlakukan sebagai layar kunci yang aman dan HARUS ikuti batasan yang tercantum dalam C-8 di bawah ini.

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

  • [C-7-1] HARUS ada indikasi yang jelas di menu pengaturan dan di kunci layar saat penguncian perangkat ditunda atau dapat dibuka oleh agen tepercaya. Misalnya, AOSP memenuhi persyaratan ini dengan menampilkan deskripsi teks untuk "Setelan kunci otomatis" dan "tombol daya langsung terkunci" di menu pengaturan dan ikon yang mudah dikenali di layar kunci.
  • [C-7-2] HARUS mematuhi dan sepenuhnya menerapkan semua API agen kepercayaan dalam Class DevicePolicyManager, seperti atribut KEYGUARD_DISABLE_TRUST_AGENTS .
  • [C-7-3] TIDAK BOLEH mengimplementasikan TrustAgentService.addEscrowToken() sepenuhnya fungsi pada perangkat yang digunakan sebagai perangkat pribadi utama (misalnya, genggam) tetapi MUNGKIN mengimplementasikan fungsi sepenuhnya pada perangkat implementasi yang biasanya dibagikan (misalnya, Android Television atau Perangkat otomotif).
  • [C-7-4] HARUS mengenkripsi semua token tersimpan yang ditambahkan oleh TrustAgentService.addEscrowToken().
  • [C-7-5] TIDAK BOLEH menyimpan kunci enkripsi atau token {i>escrow<i} pada perangkat yang sama di mana kunci tersebut digunakan. Misalnya, diizinkan untuk kunci yang disimpan di ponsel untuk membuka akun pengguna di TV. Untuk perangkat Otomotif, token dana tidak diizinkan untuk disimpan di bagian mana pun dari kendaraan.
  • [C-7-6] HARUS memberi tahu pengguna tentang implikasi keamanan sebelum mengaktifkan token {i>escrow<i} untuk membongkar enkripsi penyimpanan data.
  • [C-7-7] HARUS memiliki mekanisme cadangan untuk menggunakan metode otentikasi utama.
  • [C-7-8] Pengguna HARUS ditantang untuk mendapatkan salah satu akses utama yang direkomendasikan metode autentikasi (misalnya: PIN, pola, sandi) setidaknya sekali setiap 72 langkah jam atau kurang kecuali jika keselamatan pengguna (misalnya gangguan pengemudi) adalah kekhawatirannya.
  • [C-7-9] Pengguna HARUS ditantang untuk mendapatkan salah satu akses utama yang disarankan metode autentikasi (misalnya: PIN, pola, sandi) seperti yang dijelaskan dalam [C-1-7] dan [C-1-8] dalam pasal 7.3.10, kecuali keselamatan pengguna (misalnya gangguan bagi pengemudi) harus menjadi perhatian.
  • [C-7-10] TIDAK BOLEH diperlakukan sebagai layar kunci yang aman dan HARUS mengikuti batasan yang tercantum dalam C-8 di bawah ini.
  • [C-7-11] TIDAK BOLEH mengizinkan TrustAgent pada perangkat pribadi utama (mis.genggam) untuk membuka kunci perangkat, dan hanya dapat menggunakannya untuk menjaga perangkat yang sudah tidak terkunci dalam keadaan tidak terkunci hingga maksimum 4 jam. Implementasi default dari TrustManagerService di AOSP memenuhi persyaratan ini.
  • [C-7-12] HARUS menggunakan keamanan kriptografis (misalnya UKEY2) untuk meneruskan token {i>escrow <i}dari penyimpanan perangkat ke perangkat target.

Jika implementasi perangkat menambahkan atau mengubah metode autentikasi untuk membuka kunci layar kunci yang bukan layar kunci aman seperti dijelaskan di atas, dan menggunakan metode otentikasi baru untuk membuka {i>keyguard<i}:

Jika implementasi perangkat memungkinkan aplikasi membuat tampilan virtual dan tidak mendukung peristiwa input terkait, seperti melalui VirtualDeviceManager, mereka:

  • [C-9-1] HARUS mengunci tampilan virtual sekunder ini saat layar default dikunci, lalu buka kunci tampilan virtual sekunder ini saat layar default perangkat tidak terkunci.

Jika implementasi perangkat memungkinkan aplikasi membuat tampilan virtual sekunder dan mendukung input terkait peristiwa, seperti melalui VirtualDeviceManager, peristiwa tersebut:

  • [C-10-1] HARUS mendukung status kunci terpisah per perangkat virtual
  • [C-10-2] HARUS memutuskan sambungan semua perangkat virtual saat waktu tunggu tidak ada aktivitas
  • [C-10-3] HARUS memiliki waktu tunggu tidak ada aktivitas
  • [C-10-4] HARUS mengunci semua layar saat pengguna memulai kunci total, termasuk melalui kemampuan pengguna kunci total yang diperlukan untuk perangkat genggam (lihat Bagian 2.2.5[9.11/H-1-2])
  • [C-10-5] HARUS memiliki instance perangkat virtual terpisah per pengguna
  • [C-10-6] HARUS menonaktifkan pembuatan peristiwa input terkait melalui VirtualDeviceManager jika ditunjukkan oleh DevicePolicyManager.setNearbyAppStreamingPolicy
  • [C-10-7] HARUS menggunakan papan klip terpisah semata-mata untuk setiap perangkat virtual (atau menonaktifkan papan klip untuk perangkat virtual)
  • [C-10-11] HARUS menonaktifkan UI autentikasi pada perangkat virtual, termasuk entri faktor pengetahuan dan perintah biometrik
  • [C-10-12] HARUS membatasi intent yang dimulai dari perangkat virtual untuk menampilkan hanya di perangkat virtual yang sama
  • [C-10-13] TIDAK BOLEH menggunakan status penguncian perangkat virtual sebagai autentikasi pengguna pada Sistem Android Keystore. Lihat KeyGenParameterSpec.Builder.setUserAuthentication*.

Saat implementasi perangkat memungkinkan pengguna mentransfer faktor pengetahuan otentikasi dari perangkat sumber ke perangkat target, seperti untuk penyiapan awal perangkat target, mereka:

  • [C-11-1] HARUS mengenkripsi faktor pengetahuan dengan jaminan perlindungan seperti yang dijelaskan dalam Google Cloud Key Vault Service laporan resmi keamanan saat mentransfer faktor pengetahuan dari perangkat sumber ke perangkat target sehingga faktor pengetahuan tidak dapat didekripsi dari jarak jauh atau digunakan untuk membuka kunci dari jarak jauh di kedua perangkat.
  • [C-11-2] HARUS, pada perangkat sumber , minta pengguna untuk mengonfirmasi faktor pengetahuan perangkat sumber sebelum mentransfer faktor pengetahuan ke perangkat target.
  • [C-11-3] HARUS, pada perangkat target yang tidak memiliki autentikasi utama yang ditetapkan faktor pengetahuan, minta pengguna untuk mengkonfirmasi faktor pengetahuan yang ditransfer pada perangkat target sebelum menetapkan faktor pengetahuan tersebut sebagai faktor pengetahuan otentikasi untuk perangkat target dan sebelum membuat tersedia untuk semua data yang ditransfer dari perangkat sumber.

Jika implementasi perangkat memiliki layar kunci yang aman dan menyertakan satu atau beberapa tepercaya, yang memanggil TrustAgentService.grantTrust() System API dengan flag FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE yang:

  • [C-12-1] Hanya boleh memanggil grantTrust() dengan flag saat terhubung ke perangkat fisik jarak dekat dengan layar kunci itu sendiri, dan ketika pengguna memiliki mengotentikasi identitas mereka terhadap layar kunci itu. Perangkat yang dapat mendekati dapat gunakan mekanisme deteksi di pergelangan tangan atau pada tubuh setelah pengguna satu kali membuka kunci untuk memenuhi persyaratan otentikasi pengguna.
  • [C-12-2] HARUS menempatkan implementasi perangkat ke dalam TrustState.TRUSTABLE keadaan saat layar dimatikan (misalnya dengan menekan tombol atau waktu tunggu) dan TrustAgent belum mencabut kepercayaan. AOSP memenuhi persyaratan ini.
  • [C-12-3] Hanya boleh memindahkan perangkat dari TrustState.TRUSTABLE ke TrustState.TRUSTED menyatakan jika TrustAgent masih memberikan kepercayaan berdasarkan persyaratan dalam C-12-1.
  • [C-12-4] HARUS memanggil TrustManagerService.revokeTrust()
    • Setelah maksimum 24 jam sejak pemberian kepercayaan, atau
    • Setelah periode tidak ada aktivitas selama 8 jam, atau
    • Jika implementasinya tidak secara kriptografi aman, rentang yang akurat seperti yang didefinisikan dalam [C-12-5], ketika koneksi yang mendasari ke perangkat fisik terdekat akan hilang.
  • [C-12-5] Implementasi yang mengandalkan rentang yang aman dan akurat untuk memenuhi persyaratan [C-12-4] HARUS menggunakan salah satu solusi berikut:
    • Implementasi menggunakan UWB:
      • HARUS memenuhi persyaratan, sertifikasi, akurasi, dan persyaratan kalibrasi untuk UWB yang dijelaskan dalam 7.4.9.
      • HARUS menggunakan salah satu mode keamanan P-STS yang tercantum dalam 7.4.9.
    • Implementasi menggunakan Wi-Fi Neighborhood Awareness Networking (NAN):
      • HARUS memenuhi persyaratan akurasi dalam 2.2.1 [7.4.2.5/H-SR-1], gunakan bandwidth 160 MHz (atau lebih tinggi), dan ikuti langkah-langkah penyiapan pengukuran yang ditentukan dalam Kalibrasi Kehadiran.
      • HARUS menggunakan LTF Aman sebagaimana didefinisikan dalam IEEE 802.11az.

Jika implementasi perangkat memungkinkan aplikasi membuat tampilan virtual sekunder dan mendukung input terkait peristiwa seperti melalui VirtualDeviceManager dan layar tidak ditandai dengan VIRTUAL_DISPLAY_FLAG_SECURE, berarti layar tersebut:

  • [C-13-8] HARUS memblokir activity dengan atribut android:canDisplayOnRemoteDevices atau meta-data android.activity.can_display_on_remote_devices yang disetel ke false agar tidak dimulai di virtual perangkat seluler.
  • [C-13-9] HARUS memblokir aktivitas yang tidak secara eksplisit mengaktifkan {i>streaming<i} dan yang menunjukkan konten sensitif, termasuk melalui SurfaceView#setSecure, FLAG_SECURE, atau SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS, agar tidak menjadi dimulai di perangkat virtual.

Jika implementasi perangkat mendukung status daya tampilan terpisah melalui DeviceStateManager DAN mendukung status kunci layar terpisah melalui KeyguardDisplayManager, mereka:

  • [C-SR-2] SANGAT DIREKOMENDASIKAN untuk memanfaatkan rapat kredensial persyaratan yang ditentukan dalam pasal 9.11.1 atau Rapat Biometrik setidaknya Spesifikasi kelas 1 yang ditentukan dalam pasal 7.3.10 untuk memungkinkan membuka kunci dari tampilan perangkat {i>default<i}.
  • [C-SR-3] SANGAT DIREKOMENDASIKAN untuk membatasi buka kunci layar terpisah melalui waktu tunggu tampilan yang ditentukan.
  • [C-SR-4] SANGAT DIREKOMENDASIKAN untuk memungkinkan pengguna mengunci semua layar secara global kunci total dari perangkat genggam utama.

9.11.2. StrongBox

Sistem Android Keystore memungkinkan pengembang aplikasi untuk menyimpan kunci kriptografi dalam prosesor aman khusus sebagai serta lingkungan eksekusi yang terisolasi seperti yang dijelaskan di atas. Sungguh prosesor aman khusus disebut "StrongBox". Persyaratan C-1-3 hingga C-1-11 di bawah ini menentukan persyaratan yang harus dipenuhi perangkat untuk memenuhi syarat sebagai StrongBox.

Implementasi perangkat yang memiliki prosesor aman khusus:

  • [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mendukung StrongBox. StrongBox akan kemungkinan akan menjadi persyaratan dalam rilis mendatang.

Jika implementasi perangkat mendukung StrongBox, implementasi tersebut:

  • [C-1-1] HARUS mendeklarasikan FEATURE_STRONGBOX_KEYSTORE.

  • [C-1-2] HARUS menyediakan perangkat keras khusus yang aman yang digunakan untuk kembali keystore dan mengamankan autentikasi pengguna. Keamanan khusus perangkat keras dapat digunakan untuk tujuan lain juga.

  • [C-1-3] HARUS memiliki CPU diskrit yang tidak berbagi cache, DRAM, dan koprosesor atau sumber daya inti lainnya dengan pemroses aplikasi (AP).

  • [C-1-4] HARUS memastikan bahwa setiap periferal yang dibagikan dengan AP tidak dapat mengubah StrongBox memproses dengan cara apa pun, atau mendapatkan informasi apa pun dari StrongBox. AP DAPAT menonaktifkan atau memblokir akses ke StrongBox.

  • [C-1-5] HARUS memiliki jam internal dengan akurasi yang wajar (+-10%) yang kebal terhadap manipulasi oleh AP.

  • [C-1-6] HARUS memiliki generator angka acak yang menghasilkan {i>output<i} yang terdistribusi secara seragam dan tidak dapat diprediksi.

  • [C-1-7] HARUS memiliki ketahanan terhadap perubahan, termasuk ketahanan terhadap penetrasi fisik, dan glitch.

  • [C-1-8] HARUS memiliki ketahanan saluran samping, termasuk ketahanan terhadap kebocoran informasi melalui daya, pengaturan waktu, radiasi elektromagnetik, dan termal saluran samping radiasi.

  • [C-1-9] HARUS memiliki penyimpanan aman yang menjaga kerahasiaan, integritas data, keaslian, konsistensi, dan keaktualan konten. Penyimpanan TIDAK BOLEH dibaca atau diubah, kecuali seperti yang diizinkan oleh StrongBox API.

  • Untuk memvalidasi kepatuhan terhadap [C-1-3] hingga [C-1-9], perangkat implementasi:

    • [C-1-10] HARUS menyertakan perangkat keras yang disertifikasi berdasarkan Secure IC Protection Profile BSI-CC-PP-0084-2014 atau dievaluasi oleh laboratorium pengujian terakreditasi nasional yang menggabungkan Penilaian kerentanan potensi serangan tinggi sesuai dengan Penerapan Kriteria Umum Potensi Serangan untuk Smartcard.
    • [C-1-11] HARUS menyertakan {i>firmware<i} yang dievaluasi oleh laboratorium pengujian terakreditasi nasional yang menggabungkan penilaian kerentanan potensial berdasarkan Penerapan Kriteria Umum Potensi Serangan ke Smartcard.
    • [C-SR-2] SANGAT DIREKOMENDASIKAN untuk menyertakan perangkat keras yang yang dievaluasi menggunakan Target Keamanan, Tingkat Jaminan Evaluasi (EAL) 5, ditambah dengan AVA_VAN.5. Sertifikasi EAL 5 kemungkinan akan menjadi persyaratan dalam rilis mendatang.
    • [C-SR-3] SANGAT DIREKOMENDASIKAN untuk memberikan ketahanan terhadap serangan orang dalam (IAR), yang berarti bahwa orang dalam yang memiliki akses ke penandatanganan {i>firmware<i} kunci tidak dapat menghasilkan firmware yang menyebabkan StrongBox bocor rahasia, untuk mengesampingkan persyaratan keamanan fungsional atau mengaktifkan akses ke data pengguna yang sensitif. Cara yang direkomendasikan untuk menerapkan IAR adalah mengizinkan pembaruan firmware hanya jika {i>password<i} pengguna utama disediakan melalui HAL IAuthSecret.

9.11.3. Kredensial Identitas

Sistem Kredensial Identitas ditetapkan dan dicapai dengan mengimplementasikan semua API di android.security.identity.* paket. API ini memungkinkan developer aplikasi menyimpan dan mengambil identitas pengguna yang informatif serta dipersonalisasi. Implementasi perangkat:

  • [C-SR-1] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan Kredensial Identitas Sistem.

Jika implementasi perangkat menerapkan Identity Credential System, implementasi tersebut:

  • [C-1-1] HARUS menampilkan non-null untuk IdentityCredentialStore#getInstance() .

  • [C-1-2] HARUS mengimplementasikan Identity Credential System (mis. android.security.identity.* API) dengan kode yang berkomunikasi dengan aplikasi di area yang secara aman diisolasi 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.

  • [C-1-3] Operasi kriptografi yang diperlukan untuk mengimplementasikan Identitas Sistem Kredensial (misalnya, android.security.identity.* API) HARUS dijalankan sepenuhnya di aplikasi tepercaya dan materi kunci pribadi HARUS tidak pernah meninggalkan lingkungan eksekusi yang terisolasi kecuali jika diperlukan secara khusus oleh API tingkat yang lebih tinggi (mis. createEphemeralKeyPair() ).

  • [C-1-4] Aplikasi tepercaya HARUS diimplementasikan sedemikian rupa sehingga properti keamanan tidak terpengaruh (mis. data kredensial tidak dirilis kecuali kondisi kontrol akses terpenuhi, MAC tidak dapat dibuat untuk data arbitrer) meskipun Android berperilaku tidak semestinya atau disusupi.

Project Open Source Android upstream menyediakan referensi implementasi aplikasi tepercaya (libeic) yang dapat digunakan untuk mengimplementasikan sistem Identity Credential.

9.12. Penghapusan Data

Semua implementasi perangkat:

  • [C-0-1] HARUS menyediakan mekanisme kepada pengguna untuk melakukan "Reset ke Setelan Pabrik".
  • [C-0-2] HARUS menghapus semua data pada sistem file userdata saat melakukan "Reset ke Setelan Pabrik".
  • [C-0-3] HARUS menghapus data sedemikian rupa sehingga akan memenuhi seperti NIST SP800-88 saat menjalankan perintah "Factory Data" Reset".
  • [C-0-4] HARUS memicu "Reset ke Setelan Pabrik" di atas saat metode DevicePolicyManager.wipeData() API dipanggil oleh aplikasi Pengontrol Kebijakan Perangkat pengguna utama.
  • MUNGKIN menyediakan opsi penghapusan total data cepat yang hanya melakukan penghapusan data logis.

9.13. Mode Booting Aman

Android menyediakan Mode Booting Aman, yang memungkinkan pengguna melakukan booting ke dalam mode tempat hanya aplikasi sistem bawaan yang diizinkan berjalan, dan semua aplikasi pihak ketiga aplikasi akan dinonaktifkan. Mode ini, yang dikenal sebagai “{i>Safe Boot Mode<i}”, memberi pengguna untuk meng-uninstal aplikasi pihak ketiga yang berpotensi membahayakan.

Implementasi perangkat adalah:

  • [C-SR-1] SANGAT DIREKOMENDASIKAN untuk menerapkan Mode Booting Aman.

Jika implementasi perangkat menerapkan Mode Booting Aman, implementasi tersebut:

  • [C-1-1] HARUS memberikan pilihan kepada pengguna untuk masuk ke Mode {i>Booting<i} Aman sedemikian rupa sehingga tidak ada gangguan dari pihak ketiga aplikasi yang diinstal di perangkat, kecuali jika aplikasi pihak ketiga Pengontrol Kebijakan Perangkat dan telah menyetel UserManager.DISALLOW_SAFE_BOOT tandai sebagai true.

  • [C-1-2] HARUS memberikan pengguna kemampuan untuk copot pemasangan aplikasi pihak ketiga apa pun dalam Mode Aman.

  • SEHARUSNYA memberi pengguna opsi untuk masuk ke Mode Booting Aman dari menu {i>booting<i} menggunakan alur kerja yang berbeda dari proses {i>booting<i} biasa.

9.14. Isolasi Sistem Kendaraan Otomotif

Perangkat Android Automotive diharapkan bertukar data dengan kendaraan penting subsistem menggunakan vehicle HAL untuk mengirim dan menerima pesan melalui jaringan kendaraan seperti CAN bus.

Pertukaran data dapat diamankan dengan menerapkan fitur keamanan di bawah Lapisan framework Android untuk mencegah interaksi berbahaya atau tidak disengaja dengan subsistem ini.

9.15. Paket Langganan

"Paket langganan" lihat detail paket hubungan penagihan yang diberikan oleh operator seluler melalui SubscriptionManager.setSubscriptionPlans()

Semua implementasi perangkat:

  • [C-0-1] HARUS mengembalikan paket langganan hanya ke aplikasi operator seluler yang yang awalnya telah menyediakannya.
  • [C-0-2] TIDAK BOLEH mencadangkan atau mengupload paket langganan dari jarak jauh.
  • [C-0-3] HARUS hanya mengizinkan penggantian, seperti SubscriptionManager.setSubscriptionOverrideCongested(), dari aplikasi operator seluler yang saat ini menyediakan paket langganan yang valid.

9.16. Migrasi Data Aplikasi

Jika implementasi perangkat menyertakan kemampuan untuk memigrasikan data dari perangkat ke perangkat lain dan tidak membatasi data aplikasi yang disalin dikonfigurasi oleh pengembang aplikasi dalam manifes melalui android:fullBackupContent , atribut tersebut:

  • [C-1-1] TIDAK BOLEH memulai transfer data aplikasi dari perangkat di mana pengguna belum menetapkan otentikasi utama sebagai dijelaskan dalam 9.11.1 Secure Lock Screen dan Authentication.
  • [C-1-2] HARUS mengonfirmasi autentikasi utama dengan aman di sumber perangkat dan mengonfirmasi dengan maksud pengguna untuk menyalin data pada sumbernya perangkat sebelum data apa pun ditransfer.
  • [C-1-3] HARUS menggunakan pengesahan kunci keamanan untuk memastikan bahwa kedua dan perangkat target dalam migrasi perangkat-ke-perangkat perangkat Android yang sah dan memiliki bootloader yang terkunci.
  • [C-1-4] HARUS memigrasi data aplikasi saja ke aplikasi yang sama di perangkat target, dengan nama paket DAN sertifikat penandatanganan yang sama.
  • [C-1-5] HARUS menunjukkan indikasi bahwa perangkat sumber memiliki data dimigrasikan melalui migrasi data antarperangkat di menu setelan. Pengguna SEHARUSNYA TIDAK dapat menghapus indikasi ini.

9.17. Framework Virtualisasi Android

Jika perangkat mengimplementasikan dukungan untuk Android Virtualization Framework API (android.system.virtualmachine.*), host Android:

  • [C-1-1] HARUS mendukung semua API yang didefinisikan oleh android.system.virtualmachine.*.
  • [C-1-2] TIDAK BOLEH memodifikasi Android SELinux dan model izin untuk pengelolaan VM Protected Virtual Machines.
  • [C-1-3] TIDAK BOLEH memodifikasi, menghilangkan, atau mengganti aturan Neverallow yang ada dalam sistem/sepolicy yang disediakan di Project Open Source Android upstream (AOSP) dan kebijakan HARUS dikompilasi dengan semua aturan yang tidak diizinkan.
  • [C-1-4] TIDAK BOLEH mengizinkan kode yang tidak tepercaya (mis. aplikasi 3p) untuk membuat dan menjalankan Virtual Machine yang Dilindungi. Catatan: Hal ini mungkin berubah dalam rilis Android mendatang.
  • [C-1-5] TIDAK BOLEH mengizinkan Protected Virtual Machine menjalankan kode yang bukan bagian dari setelan pabrik atau pembaruannya. Segala sesuatu yang tidak dicakup oleh Booting Terverifikasi Android (mis. file yang diunduh dari internet atau di-sideload) TIDAK BOLEH diizinkan untuk dijalankan di Protected Virtual Machine.

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

  • [C-2-1] HARUS dapat menjalankan semua sistem operasi yang tersedia di APEX virtualisasi dalam Protected Virtual Machine.
  • [C-2-2] TIDAK BOLEH mengizinkan Protected Virtual Machine menjalankan sistem operasi yang tidak ditandatangani oleh implementasi perangkat atau vendor OS.
  • [C-2-3] TIDAK BOLEH mengizinkan Protected Virtual Machine menjalankan data sebagai kode (misalnya, SELinux Neverallow execmem).
  • [C-2-4] TIDAK BOLEH memodifikasi, menghilangkan, atau mengganti aturan neverallow yang ada dalam sistem/sepolicy/microdroid yang disediakan di Open Source Android upstream Project (AOSP).
  • [C-2-5] HARUS mengimplementasikan mekanisme defense in depth Protected Virtual Machine (misalnya SELinux untuk pVM) bahkan untuk sistem operasi non-Microdroid.
  • [C-2-6] HARUS memastikan bahwa firmware pVM menolak untuk boot jika tidak dapat memverifikasi gambar awal.
  • [C-2-7] HARUS memastikan bahwa firmware pVM menolak untuk {i>booting<i} jika integritas instance.img disusupi.

Jika perangkat mengimplementasikan dukungan untuk Android Virtualization Framework API (android.system.virtualmachine.*), hypervisor:

  • [C-3-1] TIDAK BOLEH mengizinkan pVM apa pun mengakses halaman milik orang lain entitas (yaitu pVM atau hypervisor lain), kecuali jika dibagikan secara eksplisit oleh halaman pemilik situs. Ini termasuk VM host. Hal ini berlaku untuk akses CPU dan DMA.
  • [C-3-2] HARUS menghapus halaman setelah digunakan oleh VM dan sebelum halaman tersebut ditampilkan ke host (misalnya, PVM dihancurkan).
  • [C-3-3] HARUS memastikan bahwa firmware pVM dimuat dan dieksekusi sebelum kode apa pun dalam pVM.
  • [C-3-4] HARUS memastikan bahwa BCC dan CDI yang diberikan ke instance pVM hanya dapat turunan dari instance tertentu.

Jika perangkat mengimplementasikan dukungan untuk Android Virtualization Framework API, lalu di semua area:

  • [C-4-1] TIDAK BOLEH menyediakan fungsionalitas ke pVM yang memungkinkan pengabaian Model Keamanan Android.

Jika perangkat mengimplementasikan dukungan untuk Android Virtualization Framework API, maka:

  • [C-5-1] HARUS mendukung Kompilasi Terisolasi dari update runtime ART.

Jika perangkat mengimplementasikan dukungan untuk Android Virtualization Framework API, maka untuk Key Management:

  • [C-6-1] HARUS root rantai DICE pada titik yang tidak dapat dimodifikasi oleh pengguna, bahkan pada perangkat yang tidak terkunci. (Untuk memastikan konten tidak boleh di-spoofing).
  • [C-6-2] HARUS melakukan DICE dengan benar, yaitu memberikan nilai yang benar.

10. Pengujian Kompatibilitas Software

Implementasi perangkat HARUS lulus semua pengujian yang dijelaskan di bagian ini. Namun, perhatikan bahwa tidak ada paket pengujian perangkat lunak yang sepenuhnya komprehensif. Karena alasan ini, pengimplementasi perangkat SANGAT DIREKOMENDASIKAN untuk sebanyak mungkin perubahan terhadap referensi dan implementasi Android yang tersedia dari Proyek Open Source Android. Tindakan ini akan meminimalkan risiko munculnya bug yang menimbulkan inkompatibilitas membutuhkan pengerjaan ulang dan potensi pembaruan perangkat.

10.1. Compatibility Test Suite (CTS)

Implementasi perangkat:

  • [C-0-1] HARUS lulus Compatibility Test Suite (CTS) Android tersedia dari Proyek Open Source Android, menggunakan pengiriman akhir perangkat lunak pada perangkat.

  • [C-0-2] HARUS memastikan kompatibilitas dalam kasus ambiguitas dalam CTS dan untuk setiap implementasi ulang bagian-bagian kode sumber referensi.

CTS dirancang untuk dijalankan pada perangkat yang sebenarnya. Seperti perangkat lunak lainnya, CTS mungkin saja berisi serangga. CTS akan diversikan secara terpisah dari Definisi Kompatibilitas, dan beberapa revisi CTS dapat dirilis untuk Android 13.

Implementasi perangkat:

  • [C-0-3] HARUS lulus versi CTS terbaru yang tersedia pada saat perangkat perangkat lunak.

  • HARUS menggunakan penerapan referensi di hierarki Open Source Android sebanyak mungkin.

10.2. Pemverifikasi CTS

CTS Verifier disertakan dalam Compatibility Test Suite, dan dimaksudkan untuk dijalankan oleh operator manusia untuk menguji fungsionalitas yang tidak dapat diuji oleh sistem otomatis, seperti fungsi kamera yang benar dan sensor.

Implementasi perangkat:

  • [C-0-1] HARUS mengeksekusi dengan benar semua kasus yang berlaku di pemverifikasi CTS.

CTS Verifier memiliki pengujian untuk berbagai jenis perangkat keras, termasuk beberapa perangkat keras yang bersifat opsional.

Implementasi perangkat:

  • [C-0-2] HARUS lulus semua tes untuk perangkat keras yang mereka miliki; misalnya, jika perangkat memiliki akselerometer, perangkat HARUS mengeksekusi dengan benar Kasus pengujian akselerometer di CTS Verifier.

Kasus pengujian untuk fitur yang ditandai sebagai opsional oleh Definisi Kompatibilitas ini Dokumen MUNGKIN dilewati atau dihilangkan.

  • [C-0-2] Setiap perangkat dan setiap build HARUS menjalankan CTS Verifier dengan benar, sebagaimana disebutkan di atas. Namun, karena banyak build yang sangat mirip, perangkat pengimplementasi tidak diharapkan untuk secara eksplisit menjalankan CTS Verifier di build yang hanya berbeda dalam hal yang sepele. Secara khusus, implementasi perangkat yang berbeda dari implementasi yang telah lulus Pemverifikasi CTS hanya dengan serangkaian lokalitas, branding, dll. yang disertakan. MUNGKIN menghilangkan uji CTS Verifier.

11. Software yang Dapat Diperbarui

  • [C-0-1] Implementasi perangkat HARUS menyertakan mekanisme untuk menggantikan keseluruhan perangkat lunak sistem. Mekanismenya tidak perlu menjalankan "aktif" upgrade—yang berarti perangkat perlu dimulai ulang. Metode apa pun dapat digunakan, asalkan dapat menggantikan keseluruhan perangkat lunak yang sudah terinstal di perangkat. Misalnya, salah satu dari akan memenuhi persyaratan ini:

    • "Melalui udara (OTA)" unduhan dengan pembaruan {i>offline<i} melalui {i>reboot<i}.
    • "Di-tether" pembaruan melalui USB dari PC {i>host<i}.
    • "Offline" pembaruan melalui {i>reboot<i} dan pembaruan dari file pada penyimpanan yang dapat dilepas.

  • [C-0-2] Mekanisme update yang digunakan HARUS mendukung update tanpa menghapus total pengguna layanan otomatis dan data skalabel. Artinya, mekanisme pembaruan HARUS menjaga data pribadi aplikasi dan data aplikasi bersama. Perhatikan, software Android upstream menyertakan mekanisme update yang memenuhi persyaratan ini.

  • [C-0-3] Seluruh update HARUS ditandatangani dan mekanisme update di perangkat HARUS memverifikasi pembaruan dan tanda tangan terhadap kunci publik yang disimpan di perangkat.

  • [C-SR-1] Mekanisme penandatanganan SANGAT DIREKOMENDASIKAN untuk melakukan hashing pada update dengan SHA-256 dan memvalidasi hash terhadap kunci publik menggunakan ECDSA NIST P-256.

Jika implementasi perangkat menyertakan dukungan untuk data tidak berbayar seperti profil 802.11 atau {i> Bluetooth PAN<i} (Jaringan Area Pribadi), lalu, mereka:

  • [C-1-1] HARUS mendukung download OTA dengan update offline melalui reboot.

Implementasi perangkat HARUS memverifikasi bahwa image sistem identik dalam biner ke hasil yang diharapkan setelah menggunakan OTA. OTA berbasis blok di Proyek Open Source Android upstream, yang ditambahkan sejak Android 5.1, memenuhi persyaratan ini.

Selain itu, penerapan perangkat SEHARUSNYA mendukung update sistem A/B. AOSP mengimplementasikan fitur ini menggunakan HAL kontrol booting.

Jika ditemukan kesalahan dalam implementasi perangkat setelah dirilis tetapi dalam masa pakai produk yang wajar yang ditentukan melalui konsultasi dengan Tim Kompatibilitas Android untuk memengaruhi kompatibilitas perangkat aplikasi, lalu:

  • [C-2-1] Implementasi perangkat HARUS memperbaiki error melalui software yang tersedia yang dapat diterapkan sesuai mekanisme yang baru saja dijelaskan.

Android menyertakan fitur yang memungkinkan aplikasi Pemilik Perangkat (jika ada) untuk mengontrol penginstalan pembaruan sistem. Jika subsistem pembaruan sistem untuk perangkat yang melaporkan android.software.device_admin, perangkat tersebut:

12. Log Perubahan Dokumen

Berikut adalah ringkasan perubahan pada Definisi Kompatibilitas dalam rilis:

4 Oktober 2023

2. Jenis Perangkat

  • 2.2.5. Model Keamanan:

    Lihat revisi

    • [9.8/H-1-14] HARUS menampilkan indikator mikrofon, seperti dijelaskan di bagian 9.8.2 [9,8/C-3-1], jika hasil frasa pengaktif yang berhasil dikirimkan ke suara

  • 2.2.7.1 Media:

    Lihat revisi

    • [5.1/H-1-7] HARUS memiliki latensi inisialisasi codec 40 md atau kurang untuk Sesi encoding video 1080p atau lebih kecil untuk semua encoder video hardware saat dalam keadaan termuat. Muatan di sini didefinisikan sebagai 1080p hingga 720p serentak sesi transcoding video saja menggunakan codec video hardware bersama dengan Inisialisasi perekaman audio-video 1080p. Untuk codec Dolby Vision, latensi inisialisasi codec HARUS 50 md atau kurang.

    • [5.1/H-1-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.

7.4. Konektivitas Data

9.11. Kunci dan Kredensial

  • 9.11.2. StrongBox:

    Lihat revisi

    disediakan melalui HAL IAuthSecret.

    Menghapus IAR akan menjadi persyaratan HARUS di Android 14.

26 Juni 2023

2. Jenis Perangkat

  • 2.2.1 Hardware

    • Persyaratan dihapus 7.2.3/H-0-5, 7.2.3/H-0-6, 7.2.3/H-0-7

    • Pembaruan lainnya:

      Lihat revisi

      SANGAT DIREKOMENDASIKAN untuk mengikuti langkah-langkah penyiapan pengukuran yang ditentukan dalam Persyaratan Kalibrasi Kehadiran.

  • 2.5.1 Hardware

    Lihat revisi

    Jika implementasi perangkat Automotive adalah 32-bit:

    • [7.6.1/A-1-1] Memori yang tersedia untuk {i>kernel<i} dan userspace HARUS berukuran minimal 512 MB jika salah satu dari 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-1-2] Memori yang tersedia untuk {i>kernel<i} dan userspace HARUS berukuran minimal 608 MB jika salah satu dari 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-1-3] Memori yang tersedia untuk {i>kernel<i} 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

    • [7.6.1/A-1-4] Memori yang tersedia untuk {i>kernel<i} dan ruang pengguna minimal HARUS 1344 MB jika ada salah satu kepadatan berikut digunakan:

      • 560 dpi atau lebih tinggi pada layar kecil/normal
      • Layar besar 400 dpi atau lebih
      • xhdpi atau lebih tinggi di layar ekstra besar

3. Software

7. Kompatibilitas Hardware

9. Kompatibilitas Model Keamanan

  • 9.1 Izin

    Lihat revisi

    Implementasi perangkat:

    • [C-0-5] TIDAK BOLEH memberikan izin runtime apa pun untuk prainstal aplikasi kecuali:

      • Perangkat ini diinstal pada saat pengiriman perangkat, DAN
      • Izin pengguna dapat diperoleh sebelum aplikasi menggunakan it izin,

      ATAU

      • Izin runtime diberikan oleh kebijakan pemberian izin default atau memiliki peran platform. terkait dengan pola intent untuk aplikasi bawaan yang ditetapkan sebagai pengendali default.

  • 9.11. Kunci dan Kredensial

    • Menghapus persyaratan [C-13-10] dan 9.11.4.

20 Maret 2023

2. Jenis Perangkat

3. Software

  • 3.18. Kontak

    Lihat revisi

    Akun default untuk kontak baru: Penyedia Kontak menyediakan API untuk dikelola pengaturan akun {i>default<i} saat membuat kontak baru.

    Jika implementasi perangkat mempramuat aplikasi kontak, maka kontak yang dipramuat aplikasi:

    • [C-2-1] HARUS menangani intent ini ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT untuk meluncurkan UI bagi pemilihan akun dan simpan pengaturan ke Penyedia Kontak bila akun dipilih.

    • [C-2-2] HARUS mengikuti pengaturan akun default saat menangani Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT untuk ContactsContracts.Contacts.CONTENT_TYPE dan ContactsContract.RawContacts.CONTENT_TYPE dengan memilih terlebih dahulu menggunakan akun layanan.

    Mengakhiri persyaratan baru

  • 3.2.3.5 Intent Aplikasi Bersyarat

    Lihat revisi

    [Dipindahkan ke 2.2.3]

    Jika aplikasi Setelan pada implementasi perangkat mengimplementasikan sebuah fungsi pemisahan, menggunakan penyematan aktivitas, maka mereka:

    Mengakhiri persyaratan baru

6. Kompatibilitas Opsi dan Developer Tools

  • 6.1 Developer Tools

    Lihat revisi

    • monyet
      • [C-0-8] HARUS menyertakan kerangka kerja Monkey dan menyediakannya untuk aplikasi untuk digunakan.

7. Kompatibilitas Hardware

  • 7.3.13. IEEE 802.1.15.4 (UWB)

    Lihat revisi

    [Dipindahkan ke 7.4.9]

    Jika implementasi perangkat menyertakan dukungan untuk 802.1.15.4 dan mengekspos fungsionalitas dengan aplikasi pihak ketiga, 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-1-6] SANGAT DIREKOMENDASIKAN untuk memenuhi kesesuaian yang relevan dan ujian sertifikasi yang ditetapkan oleh organisasi standar, termasuk FIRA, CCC dan CSA.

    Mengakhiri persyaratan baru

  • 7.4.1. Telepon

    Lihat revisi

    Jika implementasi perangkat menyertakan telepon GSM atau CDMAlaporkan fitur android.hardware.telephony, maka:

    Jika implementasi perangkat menyertakan telepon GSM atau CDMAlaporkan android.hardware.telephony fitur dan memberikan status bar sistem, lalu:

    • [C-6-7-1] HARUS memilih perwakilan langganan aktif untuk UUID grup untuk ditampilkan kepada pengguna dalam kemampuan apa pun yang menyediakan status SIM tidak akurat atau tidak sesuai. Contoh dari {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 menyertakan telepon GSM atau CDMAlaporkan android.hardware.telephony fitur, lalu:

    • [C-6-87] HARUS mampu membuka dan secara serentak menggunakan kapasitas maksimum jumlah saluran logis (total 20) untuk setiap UICC per ETSI TS 102 221.
    • [C-6-108] TIDAK BOLEH menerapkan 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 menyertakan telepon GSM atau CDMAlaporkan fitur android.hardware.telephony dan semua langganan non-oportunistik aktif yang berbagi UUID grup,dinonaktifkan secara fisik dihapus dari perangkat, atau ditandai oportunistik, maka perangkat:

    • [C-78-1] HARUS otomatis menonaktifkan semua fitur yang tersisa oportunistik langganan dalam grup yang sama.

    Jika implementasi perangkat mencakup telepon GSM, tetapi bukan telepon CDMA, implementasi tersebut:

    Jika implementasi perangkat mendukung eUICC dengan beberapa port dan profil, implementasi tersebut:

  • 7.4.9. UWB

    Lihat revisi

    Jika penerapan perangkat melaporkan dukungan untuk fitur android.hardware.uwb melalui android.content.pm.PackageManager Jika implementasi perangkat menyertakan dukungan untuk 802.1.15.4 dan mengekspos fungsinya 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-16] HARUS memastikan bahwa pengukuran jarak berada dalam +/-15 cm untuk 95% pengukuran di lingkungan garis pandang pada jarak 1 m dalam non-reflektif.
    • [C-1-27] HARUS memastikan bahwa median pengukuran jarak pada jarak 1 m dari perangkat referensi berada dalam jarak [0,75 m, 1,25 m], di mana kebenaran dasar jarak diukur dari tepi atas DUT yang dipegang menghadap ke atas dan dimiringkan 45 derajat.
    • [C-SR-2] SANGAT DIREKOMENDASIKAN untuk mengikuti langkah-langkah penyiapan pengukuran ditentukan dalam Persyaratan Kalibrasi Kehadiran.

    HARGA SANGAT DIREKOMENDASIKAN untuk mengikuti pengukuran langkah-langkah penyiapan yang ditentukan dalam Persyaratan Kalibrasi Kehadiran.

    Mengakhiri persyaratan baru

  • 7.8.2.2. Port Audio Digital

    Lihat revisi

    Agar kompatibel dengan headset dan perangkat lainnya aksesori audio yang menggunakan konektor USB-C dan implementasinya (class audio USB) di seluruh ekosistem Android seperti yang ditentukan dalam spesifikasi headset USB Android.

19 Oktober 2022

2. Jenis Perangkat

  • 2.2.3 Software

    Lihat revisi

    Jika implementasi perangkat genggam tidak berjalan di mode kunci tugas, ketika konten disalin ke papan klip, konten tersebut:

    • [3.8.17/H-1-1] HARUS memberikan konfirmasi untuk bagi pengguna bahwa data yang disalin ke papan klip (misalnya, thumbnail atau pemberitahuan “Konten disalin”.). Selain itu, sertakan indikasi apakah data papan klip akan disinkronkan di sini di berbagai perangkat.

3. Software

  • 3.2.3.5 Intent Aplikasi Bersyarat

    Lihat revisi

    Jika aplikasi Setelan pada implementasi perangkat menerapkan fungsi terpisah, menggunakan penyematan aktivitas, mereka akan:

    Jika implementasi perangkat mendukung VoiceInteractionService dan memiliki lebih banyak dari satu aplikasi yang menggunakan API ini yang diinstal pada satu waktu, mereka:

  • 3.4.1 Kompatibilitas Webview

    Lihat revisi

    • [C-1-4]HARUS merender' yang menyediakan konten atau konten URL jarak jauh dalam proses yang berbeda dengan aplikasi yang membuat instance WebView. Secara khusus, proses perender terpisah HARUS memiliki hak istimewa yang lebih rendah, dijalankan sebagai ID pengguna terpisah, tidak memiliki akses ke direktori data aplikasi, tidak memiliki akses jaringan langsung, dan hanya memiliki akses ke layanan sistem yang diperlukan melalui Binder minimum. Implementasi AOSP dari WebView memenuhi persyaratan ini.

7. Kompatibilitas Hardware

  • 7.4.2 IEEE 802.11 (Wi-Fi)

    Lihat revisi

    Jika implementasi perangkat menyertakan dukungan untuk mode hemat daya Wi-Fi seperti yang ditentukan dalam standar IEEE 802.11, mereka:

  • 7.4.3 Bluetooth

    Lihat revisi

    Jika implementasi perangkat menyertakan dukungan untuk Bluetooth Hemat Energi (BLE), mereka:

    • [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 saat perangkat aktif menggunakan BLE untuk memindai atau periklanan. Untuk mencegah serangan pengaturan waktu, interval waktu tunggu juga HARUS diacak antara 5 dan 15 menit.

  • 7.5.5 Orientasi Kamera

    Lihat revisi

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

    Mengakhiri persyaratan baru

9. Kompatibilitas Model Keamanan

  • 9.11 Kunci dan Kredensial

    Lihat revisi

    Jika implementasi perangkat mendukung layar kunci yang aman, implementasi tersebut:

    • [C-1-6] HARUS mendukung IKeymasterDevice 4.0, IKeymasterDevice 4.1, IKeyMintDevice versi 1 atau IKeyMintDevice versi 2.

  • Framework Virtualisasi Android 9.17

    Lihat revisi

    Jika perangkat mengimplementasikan dukungan untuk Framework Virtualisasi Android API (android.system.virtualmachine.*), host Android:

    • [C-1-3] TIDAK BOLEH memodifikasi, menghilangkan, atau mengganti aturan neverallow yang ada dalam sistem/sepolicy yang disediakan di Project Open Source Android upstream (AOSP) dan kebijakan HARUS dikompilasi dengan semua aturan Neverallow yang ada.

    Jika perangkat mengimplementasikan dukungan untuk Framework Virtualisasi Android API (android.system.virtualmachine.*), lalu Protected Virtual Machine :

    • [C-2-4] TIDAK BOLEH memodifikasi, menghilangkan, atau mengganti aturan Neverallow yang ada dalam sistem/sepolicy/microdroid yang disediakan di Open Source Android upstream Project (AOSP).

    Jika perangkat mengimplementasikan dukungan untuk Android Virtualization Framework API, maka untuk Key Management:

    • [C-6-2] HARUS melakukan DICE dengan benar, yaitu memberikan nilai yang benar. Namun, mungkin tidak perlu sampai ke tingkat detail.

15 Agustus 2022

2. Jenis Perangkat

  • 2.2.1 Hardware: Perubahan pada persyaratan perangkat keras sebagai berikut.

    • Perangkat input:

      Lihat revisi

      Implementasi perangkat genggam:

      • [7.2.3/H-0-5] HARUS memanggil OnBackInvokedCallback.onBackStarted() pada saat ini jendela yang difokuskan saat gestur kembali dimulai atau tombol kembali (KEYCODE_BACK) ditekan ke BAWAH.
      • [7.2.3/H-0-6] HARUS memanggil OnBackInvokedCallback.onBackInvoked() saat gestur kembali atau tombol Kembali dilepaskan (UP).
      • [7.2.3/H-0-7] HARUS memanggil OnBackInvokedCallback.onBackCancelled() saat gestur kembali tidak dilakukan atau peristiwa KEYCODE_BACK dibatalkan.

      Mengakhiri persyaratan baru

      Jika perangkat mendukung protokol WiFi 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 di urutan ke-68 persentil, dan +/-8 meter pada bandwidth 20 MHz pada persentil ke-68 pada dengan jarak 10 cm, 1 m, 3 m, dan 5 m, seperti yang diamati melalui WifiRttManager#startRanging Android API.

      • [7.4.2.5/H-SR] SANGAT DIREKOMENDASIKAN untuk melaporkan rentang secara akurat dalam +/-1 meter pada bandwidth 160 MHz pada persentil ke-90 (sebagaimana dihitung dengan Fungsi Distribusi Kumulatif), +/-2 meter pada bandwidth 80 MHz pada persentil ke-90, +/-4 meter pada bandwidth persentil ke-90 pada persentil ke-90, dan WifiRttManager#startRanging Android API.

      SANGAT DIREKOMENDASIKAN untuk mengikuti langkah-langkah penyiapan pengukuran yang ditentukan dalam Persyaratan Kalibrasi Kehadiran.

      Mengakhiri persyaratan baru

    • Latensi audio:

      Lihat revisi

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

      • [5.6/H-1-1] HARUS memiliki Perjalanan bolak-balik Berkelanjutan Rata-rata latensi 500 800 milidetik atau kurang dari 5 pengukuran, dengan Deviasi Absolut Rata-rata kurang dari 50 100 md, lebih jalur data berikut: "speaker ke mikrofon", Adaptor loopback 3,5 mm (jika didukung), loopback USB (jika didukung). setidaknya satu yang didukung jalur.

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

      Mengakhiri persyaratan baru

    • Input haptic:

      Lihat revisi

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

      • [7.10/H]* TIDAK BOLEH menggunakan massa berputar eksentrik (ERM) aktuator haptic (vibrator).
      • [7.10/H]* HARUS memosisikan penempatan aktuator di dekat lokasi perangkat biasanya dipegang atau disentuh dengan tangan.
      • [7.10/H]* HARUS mengimplementasikan semua konstanta publik untuk haptic yang jelas di android.view.HapticFeedbackConstants yaitu (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, TOLAK, GESTURE_START, dan GESTURE_END).
      • [7.10/H]* HARUS mengimplementasikan semua konstanta publik untuk haptic yang jelas di android.os.GetbrationEffect yaitu (Effect_TICK, Effect_CLICK, Effect_HEAVY_CLICK, dan Effect_Double_CLICK) dan semua layanan publik yang memungkinkan Konstanta PRIMITIVE_* untuk haptic yang kaya di android.os.VibrationEffect.Composition yaitu (PRIMITIVE_CLICK dan PRIMITIVE_TICK) (KLIK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). Beberapa dari dasar ini, seperti LOW_TICK dan SPIN hanya dapat dijalankan jika vibrator dapat mendukung dengan frekuensi yang relatif rendah.

      Mengakhiri persyaratan baru

      • [7.10/H]* SEHARUSNYA menggunakan konstanta haptik yang ditautkan ini pemetaan.

      Mengakhiri persyaratan baru

      Jika implementasi perangkat genggam menyertakan minimal satu resonan linear aktuator, mereka:

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

      • [7.10/H]* HARUS memverifikasi dan mengupdate jika perlu penggantian untuk primitif yang tidak didukung seperti yang dijelaskan dalam panduan penerapan untuk konstanta.

      • [7.10/H]* SEHARUSNYA memberikan dukungan penggantian untuk mengurangi risiko kegagalan sebagaimana dijelaskan di sini.

  • 2.2.3 Software:

    • Autentik Perangkat Trivial Cotntrols:

      Lihat revisi

      • [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 dan Control Control.isAuthRequired API.

    • Notifikasi MediaStyle:

      Lihat revisi

      Jika penerapan perangkat genggam mendukung notifikasi MediaStyle mereka:

      • [3.8.3.1/H-1-SR] SANGAT DIREKOMENDASIKAN untuk menyediakan kemampuan pengguna(misalnya “pengalih {i>output<i}”) diakses dari UI sistem yang memungkinkan pengguna beralih di antara kolom yang tersedia, rute media(misalnya, perangkat dan rute Bluetooth yang diberikan ke MediaRouter2Manager) saat aplikasi memposting notifikasi MediaStyle dengan token MediaSession.

  • 2.2.4 Performa dan Daya: Persyaratan baru untuk aplikasi yang berjalan dan layanan latar depan.

    Lihat revisi

    Implementasi perangkat genggam:

    • [8.5/H-0-1] HARUS memberikan kemampuan pengguna di menu Setelan dengan kemampuan untuk menghentikan aplikasi yang berjalan di latar depan dan menampilkan semua aplikasi yang memiliki layanan latar depan aktif dan dari setiap layanan ini sejak dimulai seperti yang dijelaskan dalam SDK dokumen.
      • Beberapa aplikasi DAPAT dikecualikan agar tidak dihentikan atau dicantumkan dalam kemampuan pengguna seperti yang dijelaskan dalam dokumen SDK.

    Mengakhiri persyaratan baru

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

    Lihat revisi

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

    • [5.1/H-1-1] HARUS mengiklankan jumlah maksimum hardware video decoder sesi yang dapat dijalankan secara bersamaan dalam kombinasi codec apa pun melalui CodecCapabilities.getMaxSupportedInstances() dan VideoCapabilities.getSupportedPerformancePoints().
    • [5.1/H-1-2] HARUS mendukung 6 instance sesi decoder video hardware (AVC, HEVC, VP9, AV1, atau yang lebih baru) dalam semua kombinasi codec yang berjalan secara serentak pada resolusi 1080p@30 fps.
    • [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 VideoCapabilities.getSupportedPerformancePoints().
    • [5.1/H-1-4] HARUS mendukung 6 instance hardware video encoder sesi (AVC, HEVC, VP9, AV1, atau yang lebih baru) dalam kombinasi codec apa pun yang berjalan secara serentak pada resolusi 1080p@30fps.
    • [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 VideoCapabilities.getSupportedPerformancePoints().
    • [5.1/H-1-6] HARUS mendukung 6 instance hardware video decoder dan hardware sesi encoder video (AVC, HEVC, VP9, AV1, atau yang lebih baru) dalam codec apa pun dan kombinasi berjalan bersamaan dengan resolusi 1080p@30fps.
    • [5.1/H-1-7] HARUS memiliki latensi inisialisasi codec 40 md atau kurang untuk Sesi encoding video 1080p atau lebih kecil untuk semua encoder video hardware saat dalam keadaan termuat. Muatan di sini didefinisikan sebagai 1080p hingga 720p serentak sesi transcoding video saja menggunakan codec video hardware bersama dengan Inisialisasi perekaman audio-video 1080p.
    • [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.
    • [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 serentak pada resolusi 1080p@30 fps.
    • [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 pada resolusi 1080p@30 fps.
    • [5.1/ H-1-11] HARUS mendukung decoder aman untuk setiap hardware AVC, HEVC, decoder VP9 atau AV1 di perangkat.
    • [5.1/H-1-12] HARUS memiliki latensi inisialisasi decoder video kurang dari 40 md.
    • [5.1/H-1-13] HARUS memiliki latensi inisialisasi decoder audio kurang dari 30 md.
    • [5.1/H-1-14] HARUS mendukung decoder hardware AV1 Main 10, Level 4.1.
    • [5.1/H-SR] Sangat Disarankan untuk mendukung Film Grain untuk hardware AV1 decoder.
    • [5.1/H-1-15] HARUS memiliki setidaknya 1 hardware video decoder yang mendukung 4K60.
    • [5.1/H-1-16] HARUS memiliki minimal 1 encoder video hardware yang mendukung 4K60.
    • [5.3/H-1-1] TIDAK BOLEH menjatuhkan lebih dari 1 frame dalam 10 detik (yaitu kurang dari 0,167 persen penurunan frame) untuk sesi video 1080p 60 fps dengan beban. Pemuatan didefinisikan sebagai video 1080p hingga 720p saja sesi transcoding menggunakan codec video hardware, serta Pemutaran audio AAC 128 kbps.
    • [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. Beban didefinisikan sebagai sesi transcoding video 1080p hingga 720p saja menggunakan hardware codec video, serta pemutaran audio AAC 128 kbps.
    • [5.6/H-1-1] HARUS memiliki latensi ketuk untuk nada 80 milidetik atau kurang menggunakan uji ketuk untuk nada OboeTester atau uji ketuk untuk nada CTS Verifier.
    • [5.6/H-1-2] HARUS memiliki latensi audio bolak-balik 80 milidetik atau kurang pada minimal 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 melalui keseluruhan jalur data untuk konfigurasi streaming dan latensi rendah. Untuk yang rendah konfigurasi latensi rendah, AAudio harus digunakan oleh aplikasi pada latensi rendah mode callback. Untuk streaming , Java AudioTrack harus digunakan oleh aplikasi. Baik dalam konfigurasi streaming dan latensi, sink output HAL harus menerima baik AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED, AUDIO_FORMAT_PCM_32_BIT atau AUDIO_FORMAT_PCM_FLOAT untuk output targetnya format font.
    • [5.6/H-1-4] HARUS mendukung >= 4 channel perangkat audio USB (Ini digunakan oleh DJ pengontrol untuk melihat pratinjau lagu.)
    • [5.6/H-1-5] HARUS mendukung perangkat MIDI yang sesuai dengan kelas dan mendeklarasikan MIDI tombol fitur.
    • [5.7/H-1-2] HARUS mendukung MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL dengan kemampuan dekripsi konten di bawah.
    Ukuran sampel minimum 4 MiB
    Jumlah Minimum Subsampel - H264 atau HEVC 32
    Jumlah Minimum Subsampel - VP9 9
    Jumlah Minimum Subsampel - AV1 288
    Ukuran buffer subsampel minimum 1 MiB
    Ukuran buffer kripto umum minimum 500 KiB
    Jumlah Minimum sesi serentak 30
    Jumlah minimum kunci per sesi 20
    Jumlah Total Kunci Minimum (semua sesi) 80
    Jumlah Total Minimum Kunci DRM (semua sesi) 6
    Ukuran Pesan 16 KiB
    Frame yang Didekripsi per Detik 60 fps

    Mengakhiri persyaratan baru

  • 2.2.7.2 Kamera: Update pada persyaratan Kamera Kelas Performa Media.

    Lihat revisi

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

    • [7.5/H-1-1] HARUS memiliki kamera belakang utama dengan resolusi memiliki resolusi minimal 12 megapiksel yang mendukung perekaman video dengan kecepatan 4K@30 fps. Utama kamera belakang adalah kamera belakang dengan ID kamera terendah.
    • [7.5/H-1-2] HARUS memiliki kamera depan utama dengan resolusi dengan resolusi minimal 5 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 sebagai FULL atau lebih baik untuk kedua kamera utama.
    • [7,5/H-1-4] HARUS mendukung CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME untuk kampanye utama kamera.
    • [7.5/H-1-5] HARUS memiliki latensi pengambilan JPEG camera2 < 1000 md untuk Resolusi 1080p yang diukur dengan PerformanceTest kamera CTS di bawah ITS kondisi pencahayaan (3000K) untuk kedua kamera utama.
    • [7.5/H-1-6] HARUS memiliki latensi pengaktifan kamera2 (buka kamera untuk 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 dan android.graphics.ImageFormat.RAW_SENSOR untuk kamera belakang utama.
    • [7.5/H-1-9] HARUS memiliki kamera utama hadap belakang yang mendukung 720p atau 1080p @ 240fps.
    • [7.5/H-1-10] HARUS punya 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 kamera depan dan belakang utama.
    • [7.5/H-1-13] HARUS mendukung kemampuan LOGICAL_MULTI_CAMERA untuk jika ada lebih dari 1 kamera RGB yang menghadap ke arah yang sama.
    • [7.5/H-1-14] HARUS mendukung kemampuan STREAM_USE_CASE untuk keduanya kamera depan dan belakang utama.

    Mengakhiri persyaratan baru

  • 2.2.7.3 Hardware: Pembaruan pada persyaratan Class Performa Media untuk Hardware.

    Lihat revisi

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

    • [7.1.1.1/H-2-1] HARUS memiliki resolusi layar minimal 1080p.
    • [7.1.1.3/H-2-1] HARUS memiliki kepadatan layar minimal 400 dpi.
    • [7.6.1/H-2-1] HARUS memiliki memori fisik minimal 8 GB.

    Mengakhiri persyaratan baru

  • 2.2.7.4 Performa: Pembaruan pada Class Performa Media untuk Performa.

    Lihat revisi

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

    • [8.2/H-1-1] HARUS memastikan performa operasi tulis sekuensial setidaknya 125 MB/dtk.
    • [8.2/H-1-2] HARUS memastikan performa tulis acak setidaknya 10 MB/s.
    • [8.2/H-1-3] HARUS memastikan performa baca berurutan setidaknya 250 MB/dtk.
    • [8.2/H-1-4] HARUS memastikan kinerja pembacaan acak setidaknya 40 MB/s.

    Mengakhiri persyaratan baru

  • 2.5.1 Hardware: Update untuk persyaratan akselerometer 3-sumbu dan giroskop 3-sumbu, serta persyaratan kamera tampilan eksterior.

    Lihat revisi

    Implementasi perangkat otomotif:

    • [7.3.1/A-0-4] HARUS mematuhi Android sistem koordinat sensor mobil.
    • [7.3/A-SR] SANGAT_DIREKOMENDASIKAN untuk menyertakan 3 sumbu akselerometer dan giroskop 3 sumbu.
    • [7.3/A-SR] SANGAT_DIREKOMENDASIKAN untuk mengimplementasikan dan melaporkan Sensor TYPE_HEADING.

    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] 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] SANGAT DIREKOMENDASIKAN untuk mengonfigurasi Rentang pengukuran giroskop hingga +/-250 dp untuk memaksimalkan resolusi sebaik mungkin.

    Mengakhiri persyaratan baru

    Jika implementasi perangkat Automotive menyertakan giroskop 3 sumbu, implementasi tersebut:

    • [7.3.4/A-SR] 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 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] 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.

    Mengakhiri persyaratan baru

    Kamera tampilan eksterior adalah kamera yang merekam pemandangan di luar perangkat penerapan, seperti kamera belakang kamera dasbor .

    Jika implementasi perangkat Automotive menyertakan kamera tampilan eksterior, misalnya kamera, mereka:

    • [7.5.5/A-SR] SANGAT DIREKOMENDASIKAN untuk diorientasikan sehingga dimensi panjang kamera sejajar dengan cakrawala.

    • HARUSKAN dukung Framework sinkronisasi Android.

    • MUNGKIN memiliki fokus otomatis hardware atau fokus otomatis software yang diimplementasikan {i>driver<i} kamera.

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

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

    Implementasi perangkat otomotif:

    • MUNGKIN mencakup satu atau beberapa kamera yang tersedia untuk pihak ketiga menggunakan berbagai aplikasi obrolan.

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

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

    Mengakhiri persyaratan baru

  • 2.5.5 Model Keamanan: Persyaratan baru untuk izin kamera bagi perangkat otomotif.

    Lihat revisi

    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 memiliki peran yang disebutkan di Section 9.1 Izin dengan ID CDD [C-3-X].

    • [9.8.2/A-2-2] TIDAK BOLEH menyembunyikan indikator kamera untuk aplikasi sistem yang memiliki antarmuka pengguna yang terlihat atau interaksi pengguna langsung.

    Mengakhiri persyaratan baru

  • 2.6.1 Persyaratan Tablet — Hardware: Pembaruan pada persyaratan ukuran layar tablet.

    Lihat revisi

    Perangkat Android Tablet mengacu pada implementasi perangkat Android yang biasanya memenuhi semua kriteria berikut:

    • Memiliki ukuran tampilan layar yang lebih besar dari 7 inci dan kurang dari 18", diukur secara diagonal.

    Ukuran Layar

    • [7.1.1.1/Tab-0-1] HARUS memiliki layar dengan kisaran 7 hingga 18 inci.

3. Software

  • 3.2.2 Parameter Build: Memperbarui karakter ASCII di getSerial().

    Lihat revisi

    • [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
    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.5 Intent Aplikasi Bersyarat: Memperbarui persyaratan untuk intent aplikasi bersyarat.

    Lihat revisi

    Jika implementasi perangkat mencakup layar besar (umumnya memiliki lebar dan tinggi tampilan 600 dp+) dan mendukung fungsi pemisahan, maka mereka:

    Mengakhiri persyaratan baru

  • 3.5.1 Pembatasan Aplikasi: Update pada pembatasan aplikasi.

    Lihat revisi

    Jika implementasi perangkat menerapkan mekanisme kepemilikan untuk membatasi aplikasi (mis. mengubah atau membatasi perilaku API yang yang dijelaskan dalam SDK) dan mekanisme tersebut lebih merupakan bersifat membatasi dari Bucket Aplikasi Standby Terbatas, mereka:

    • [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 kesehatan sistem. Yang lain kriteria yang tidak sepenuhnya terkait dengan kesehatan sistem, seperti 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 mengembalikan 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-9] HARUS melaporkan semua peristiwa pembatasan kepemilikan ini melalui UsageStats.

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

    Mengakhiri persyaratan baru

  • 3.8.1 Peluncur (Layar Utama): Update dukungan untuk monochrome/adaptive-icon.

    Lihat revisi

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

    Mengakhiri persyaratan baru

  • 3.8.2 Widgets: Update ke keberadaan widget aplikasi pihak ketiga di Peluncur.

    Lihat revisi

    Jika implementasi perangkat mendukung widget aplikasi pihak ketiga, implementasi tersebut:

    • [C-1-2] HARUS menyertakan dukungan bawaan untuk AppWidgets dan mengekspos kemampuan antarmuka pengguna untuk menambahkan, mengonfigurasi, melihat, dan menghapus AppWidgets langsung di dalam Peluncur.

  • 3.8.3.1 Presentasi Notifikasi: Mengklarifikasi definisi notifikasi peringatan dini.

    Lihat revisi

    Notifikasi awal adalah notifikasi yang ditampilkan kepada pengguna saat mereka masuk secara terpisah dari platform tempat pengguna aktif.

  • 3.8.3.3 DND (Jangan Ganggu) / Mode Prioritas: Update untuk menyertakan Mode Prioritas dalam persyaratan DND (Jangan Ganggu).

    Lihat revisi

    3.8.3.3. DND (Jangan Ganggu) / Mode Prioritas

    Jika implementasi perangkat mendukung fitur DND (juga disebut Mode Prioritas), mereka:

  • 3.8.6 Tema: Baru persyaratan untuk palet tonal warna dinamis.

    Lihat revisi

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

    • [C-1-4] HARUS menghasilkan palet tonal warna dinamis seperti yang ditentukan dalam AOSP dokumentasi Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (lihat android.theme.customization.system_palette dan android.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 (lihat android.theme.customization.theme_styles), yaitu TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD.

      "Warna sumber" digunakan untuk menghasilkan palet tonal warna dinamis ketika dikirim dengan android.theme.customization.system_palette (seperti yang didokumentasikan dalam Settings.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.

    Mengakhiri persyaratan baru

  • 3.8.17 Clipboard: Ditambahkan bagian persyaratan baru untuk konten di {i>clipboard<i}.

    Lihat revisi

    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.

    Mengakhiri persyaratan baru

  • 3.9.1.1 Penyediaan Pemilik Perangkat: Pembaruan pada persyaratan penyediaan pemilik perangkat.

    Lihat revisi

    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 tidak pengguna atau 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 MIME MIME_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. (seperti untuk berbasis NFC penyediaan tempat penyediaan Pemilik Profil tidak didukung).
        • [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.
      • Bila implementasi perangkat memiliki pengguna atau , data tersebut:
        • [C-1-7] HARUS mendaftarkan aplikasi DPC apa pun sebagai Aplikasi Pemilik Perangkat lagi.
    • [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 promo sebelum interaksi pengguna akhir di layar. memerlukan beberapa tindakan afirmatif sebelum atau selama proses penyediaan untuk mengizinkan yang disetel sebagai Pemilik Perangkat. Izin dapat diberikan melalui tindakan pengguna atau oleh cara terprogram tetapi pemberitahuan pengungkapan (sebagaimana dirujuk dalam AOSP) HARUS ditampilkan sebelum pemilik perangkat akan dimulai. Selain itu, izin pemilik perangkat terprogram mekanisme yang digunakan (oleh perusahaan) untuk penyediaan pemilik perangkat TIDAK BOLEH mengganggu Pengalaman {i>Out-of-Box<i} untuk non-perusahaan.
    • [C-1-3] TIDAK BOLEH melakukan hard code persetujuan atau mencegah penggunaan perangkat lain aplikasi pemilik.

    Jika implementasi perangkat mendeklarasikan android.software.device_admin, tetapi juga sertakan hak milik Pemilik Perangkat 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 melakukan hard code izin atau mencegah penggunaan aplikasi pemilik perangkat lain.
    • DAPAT memiliki data pengguna di perangkat sebelum mendaftarkan aplikasi DPC sebagai "Pemilik Perangkat".

  • 3.9.4 Persyaratan Peran Pengelolaan Perangkat: Menambahkan bagian untuk Persyaratan Peran Pengelolaan Perangkat.

    Lihat revisi

    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:

    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.

    Mengakhiri persyaratan baru

  • 3.18 Kontak: Menambahkan informasi kontak baru.

    Lihat revisi

    Akun default untuk kontak baru: Penyedia Kontak menyediakan API untuk dikelola pengaturan akun {i>default<i} saat membuat kontak baru.

    Jika implementasi perangkat mempramuat aplikasi kontak, maka kontak yang dipramuat aplikasi:

    • [C-2-1] HARUS menangani intent ini ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT untuk meluncurkan UI bagi pemilihan akun dan simpan pengaturan ke Penyedia Kontak bila akun dipilih.

    • [C-2-2] HARUS mengikuti pengaturan akun default saat menangani Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT untuk ContactsContracts.Contacts.CONTENT_TYPE dan ContactsContract.RawContacts.CONTENT_TYPE dengan memilih terlebih dahulu menggunakan akun layanan.

    Mengakhiri persyaratan baru

4. Kompatibilitas Pengemasan Aplikasi

5. Kompatibilitas Multimedia

  • Decoding Audio 5.1.2: Menambahkan persyaratan baru untuk decoder yang mampu menghasilkan audio multi-channel.

    Lihat revisi

    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 konstanta android.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] 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] Saat melakukan dekode, decoder SANGAT DIREKOMENDASIKAN untuk memberitahukan channel mask digunakan pada format output dengan KEY_CHANNEL_MASK , menggunakan konstanta android.media.AudioFormat (contoh: CHANNEL_OUT_5POINT1)

    Mengakhiri persyaratan baru

  • 5.4.1 Pengambilan Audio Mentah dan Informasi Mikrofon: Update pada sumber audio yang didukung untuk streaming input audio.

    Lihat revisi

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

  • 5.4.2 Mengambil gambar untuk Pengenalan Suara: Persyaratan yang diperbarui untuk streaming audio pengenalan suara dan persyaratan tambahan untuk tingkat penguatan mikrofon.

    Lihat revisi

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

    • HARUS merekam streaming audio pengenalan suara dengan kecepatan sekitar Karakteristik amplitudo versus frekuensi: khususnya, ±3 dB, dari 100 Hz hingga 4000 Hz.
    • HARUS merekam streaming audio pengenalan suara dengan sensitivitas input yang disetel sedemikian rupa sehingga sumber tingkat daya suara (SPL) 90 dB pada 1000 Hz menghasilkan RMS sebesar 2500 untuk sampel 16-bit.

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

    Mengakhiri persyaratan baru

  • 5.4.6 Tingkat Perolehan Mikrofon: Memindahkan persyaratan untuk Tingkat Perolehan Mikrofon ke bagian 5.4.2.

    Lihat revisi

    5.4.6. Tingkat Penguatan Mikrofon [Dipindahkan ke 5.4.2]

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

    • HARUS menampilkan amplitudo-versus frekuensi kira-kira datar karakteristik di rentang frekuensi menengah: khususnya ±3dB dari 100 Hz hingga 4000 Hz untuk setiap mikrofon yang digunakan untuk merekam suara sumber audio pengenalan.
    • [C-SR] SANGAT DIREKOMENDASIKAN untuk menunjukkan tingkat amplitudo dalam rentang frekuensi: khusus dari ±20 dB dari 5 Hz hingga 100 Hz dibandingkan ke rentang frekuensi menengah untuk setiap mikrofon yang digunakan untuk merekam sumber audio pengenalan suara.
    • [C-SR] SANGAT DIREKOMENDASIKAN untuk menunjukkan tingkat amplitudo dalam Rentang frekuensi tinggi: secara khusus dari ±30 dB dari 4000 Hz hingga 22 KHz dibandingkan dengan rentang frekuensi menengah untuk setiap mikrofon yang digunakan untuk merekam sumber audio pengenalan suara.
    • HARUS mengatur sensitivitas input audio sedemikian rupa sehingga sinusoidal 1000 Hz sumber nada yang diputar pada 90 dB Tingkat Tekanan Suara (SPL) menghasilkan respons dengan RMS 2500 untuk sampel 16 bit (atau Skala Penuh -22,35 dB untuk sampel mengambang sampel presisi titik/ganda) untuk setiap mikrofon yang digunakan merekam sumber audio pengenalan suara.

  • 5.5.4 Offload Audio: Pembaruan pada persyaratan pemutaran pengalihan audio.

    Lihat revisi

    Jika implementasi perangkat mendukung pemutaran pengurangan beban audio, implementasi tersebut:

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

  • 5.6 Latensi Audio: Pembaruan pada persyaratan latensi audio.

    Lihat revisi

    Untuk tujuan bagian ini, gunakan definisi berikut:

    • cold output jitter. Variabilitas di antara pengukuran terpisah dari suhu dingin nilai latensi output.
    • cold input jitter. Variabilitas di antara pengukuran terpisah dari suhu dingin nilai latensi input.

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

    • [C-1-2] Latensi output dingin sebesar 500 milidetik atau kurang.
    • [C-1-3] Membuka stream output menggunakan AAudioStreamBuilder_openStream() HARUS memerlukan waktu kurang dari 1.000 milidetik.

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

    • [C-SR] Latensi output dingin 100 milidetik atau kurang pada data speaker . Perangkat lama dan baru yang menjalankan versi Android ini SANGAT SANGAT DIREKOMENDASIKAN untuk memenuhi persyaratan ini sekarang. Di platform mendatang kita akan memerlukan latensi output Dingin sebesar 200 md atau kurang sebagai WAJIB.
    • [C-SR] Meminimalkan jitter output dingin.

    Jika implementasi perangkat menyertakan android.hardware.microphone, implementasi tersebut HARUS memenuhi persyaratan audio input ini:

    • [C-3-2] Latensi input dingin 500 milidetik atau kurang.
    • [C-3-3] Membuka stream input menggunakan AAudioStreamBuilder_openStream() HARUS memerlukan waktu kurang dari 1.000 milidetik.

    Jika implementasi perangkat menyertakan android.hardware.microphone, implementasi tersebut akan SANGAT DIREKOMENDASIKAN untuk memenuhi persyaratan audio input berikut:

    • [C-SR] Latensi input dingin 100 milidetik atau kurang melalui mikrofon dalam jalur data. Perangkat lama dan baru yang berjalan versi Android ini adalah SANGAT DIREKOMENDASIKAN untuk memenuhi persyaratan ini sekarang. Di masa mendatang rilis platform, kami akan membutuhkan latensi input Cold 200 md atau kurang seperti WAJIB.

    • [C-SR] Latensi input terus-menerus selama 30 milidetik atau kurang.
    • [C-SR] Meminimalkan jitter input dingin.

  • 5.10 Audio Profesional: Pembaruan pada persyaratan latensi audio untuk dukungan audio profesional.

    Lihat revisi

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

    • [C-1-2] HARUS memiliki latensi audio bolak-balik berkelanjutan, seperti yang didefinisikan dalam bagian 5.6 Latensi Audio dari 25 milidetik atau kurang dan SEHARUSNYA 10 milidetik atau lebih sedikit di setidaknya satu jalur yang didukung.
    • [C-1-5] HARUS memenuhi persyaratan latensi dan audio USB dengan Audio native AAudio API dan AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.
    • [C-1-8] HARUS memiliki latensi Ketuk untuk nada rata-rata 80 milidetik atau kurang lebih dari setidaknya 5 pengukuran di atas speaker ke jalur data mikrofon.
    • [C-SR] SANGAT DIREKOMENDASIKAN untuk menyediakan level 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 tolok ukur. SynthMark aplikasi perlu dijalankan menggunakan opsi “Pengujian Otomatis” dan mencapai hasil berikut: * voicemark.90 >= 32 suara * latensimark.fixed.little <= 15 mdtk * latensimark.dynamic.little <= 50 mdtk
    • HARUS memiliki latensi dari input sentuh ke audio output kurang dari atau sama dengan 40 md.

    Jika implementasi perangkat menyertakan colokan audio 3,5 mm konduktor 4, implementasi tersebut:

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

  • Video HDR 5.12: Menambahkan bagian baru untuk persyaratan Video HDR.

6. Kompatibilitas Opsi dan Developer Tools

  • 6.1 Developer Tools: Update untuk persyaratan konektivitas dan Kernel GPU.

    Lihat revisi

    Jika implementasi perangkat mendukung koneksi adb ke mesin host melalui Wi-Fi atau Ethernet:

    • [C-4-1] HARUS memiliki metode AdbManager#isAdbWifiSupported() tampilkan true.

    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() tampilkan true.

    • Informasi pekerjaan GPU

      Implementasi perangkat:

      • [C-6-1] HARUS mengimplementasikan perintah shell dumpsys gpu --gpuwork untuk menampilkan data pekerjaan GPU gabungan yang ditampilkan oleh kernel power/gpu_work_period tracepoint, atau tidak menampilkan data jika tracepoint tidak didukung. AOSP implementasinya adalah frameworks/native/services/gpuservice/gpuwork/.

    Mengakhiri persyaratan baru

7. Kompatibilitas Hardware

  • 7.1.4.1 OpenGL ES: Update dengan ekstensi yang direkomendasikan.

    Lihat revisi

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

    • HARUS mendukung EGL_IMG_context_priority dan EGL_EXT_protected_content ekstensi.

    Mengakhiri persyaratan baru

  • 7.1.4.2 Vulkan: Update untuk versi yang didukung untuk Vulkan.

    Lihat revisi

    Jika implementasi perangkat mendukung OpenGL ES 3.1, implementasi tersebut:

    • [SR] SANGAT DIREKOMENDASIKAN untuk menyertakan dukungan bagi Vulkan 1.3. Vulkan 1.1
    • TIDAK BOLEH mendukung versi Varian Vulkan (yaitu bagian varian dari Versi inti Vulkan HARUS nol).

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

    • [SR] SANGAT DIREKOMENDASIKAN untuk menyertakan dukungan bagi Vulkan 1.3. Vulkan 1.1

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

    • HARUS memberikan dukungan VkPhysicalDeviceProtectedMemoryFeatures dan VK_EXT_global_priority.
    • [C-1-12] TIDAK BOLEH menyebutkan dukungan untuk Ekstensi VK_KHR_performance_query.
    • [C-SR] SANGAT DIREKOMENDASIKAN untuk memenuhi persyaratan yang ditentukan oleh profil Dasar Pengukuran Android 2021.

  • 7.2.3 Tombol Navigasi:

    Lihat revisi

    Implementasi perangkat:

    • [C-SR] 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.

    Mengakhiri persyaratan baru

    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.

    Mengakhiri persyaratan baru

  • 7.3.1 Akselerometer: Pembaruan pada persyaratan sensor untuk akselerometer.

    Lihat revisi

    Jika implementasi perangkat menyertakan akselerometer, akselerometer 3 sumbu, mereka:

    • [C-1-2] HARUS menerapkan dan melaporkan TYPE_ACCELEROMETER sensor.
    • [SR] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan sensor komposit TYPE_SIGNIFICANT_MOTION.
    • [SR] SANGAT DIREKOMENDASIKAN untuk diimplementasikan dan laporan TYPE_ACCELEROMETER_UNCALIBRATED sensor. Perangkat Android SANGAT DIREKOMENDASIKAN untuk memenuhi persyaratan ini sehingga mereka akan dapat meningkatkan ke rilis platform mendatang di mana hal ini mungkin menjadi WAJIB.
    • HARUS mengimplementasikan TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER gabungan seperti yang dijelaskan dalam dokumen Android SDK.

    Jika implementasi perangkat menyertakan akselerometer 3 sumbu, implementasi tersebut:

    • [C-2-1] HARUS menerapkan dan melaporkan sensor TYPE_ACCELEROMETER.
    • [C-SR] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan TYPE_SIGNIFICANT_MOTION sensor komposit.
    • [C-SR] 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] STRONGLY_RECOMMENDED untuk mengimplementasikan dan melaporkan Sensor TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

    Mengakhiri persyaratan baru

    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 konsumsi daya HARUS selalu kurang dari 4 mW.

    Jika implementasi perangkat mencakup akselerometer 3-sumbu dan sensor giroskop 3-sumbu, mereka:

    • [C-5-1] HARUS menerapkan sensor komposit TYPE_GRAVITY dan TYPE_LINEAR_ACCELERATION.

    Jika implementasi perangkat mencakup akselerometer 3-sumbu, sensor giroskop 3-sumbu, dan sensor magnetometer, keduanya:

    • [C-6-1] HARUS menerapkan Sensor komposit TYPE_ROTATION_VECTOR.

  • 7.3.4 Giroskop: Update persyaratan sensor untuk giroskop.

    Lihat revisi

    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] Error kalibrasi SANGAT DIREKOMENDASIKAN agar kurang dari 0,01 rad/dtk saat perangkat diam pada suhu kamar.
    • [C-SR] SANGAT DIREKOMENDASIKAN untuk memiliki resolusi 16-bit atau lebih.
    • HARUS melaporkan peristiwa hingga minimal 200 Hz.

    Mengakhiri persyaratan baru

    Jika implementasi perangkat mencakup giroskop 3 sumbu, mereka:

    • [C-2-1] HARUS menerapkan sensor TYPE_GYROSCOPE.

    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] STRONGLY_RECOMMENDED untuk mengimplementasikan dan melaporkan Sensor TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

    Mengakhiri persyaratan baru

    Jika implementasi perangkat menyertakan giroskop 3-sumbu, sensor akselerometer dan sensor magnetometer, keduanya:

    • [C-4-1] HARUS menerapkan Sensor komposit TYPE_ROTATION_VECTOR.

    Jika implementasi perangkat menyertakan akselerometer 3 sumbu dan giroskop 3 sumbu sensor, fungsi tersebut:

    • [C-5-1] HARUS menerapkan sensor komposit TYPE_GRAVITY dan TYPE_LINEAR_ACCELERATION.

  • 7.3.10 Sensor Biometrik: Pembaruan pada persyaratan sensor untuk sensor biometrik.

    Lihat revisi

    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 yang diuraikan di bawah ini jika ingin diklasifikasikan sebagai Kelas 1, Kelas 2 atau Kelas 3. Sensor diklasifikasikan sebagai Kelas 1 secara default, dan memerlukan untuk memenuhi persyaratan tambahan seperti yang dijelaskan di bawah ini jika ingin diklasifikasikan sebagai Kelas 2 atau Kelas 3. Kelas 2 dan Kelas 3 biometrik mendapatkan kemampuan tambahan seperti yang dijelaskan di bawah ini.

    Jika implementasi perangkat ingin memperlakukan sensor biometrik sebagai Kelas 1. (sebelumnya Kepraktisan), mereka:

    • [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 yang diukur oleh Protokol Pengujian Biometrik Android.

    Mengakhiri persyaratan baru

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

    • [C-2-2] HARUS memiliki tingkat penerimaan spoof dan penipu tidak lebih tinggi dari 20%, dengan (1) tingkat penerimaan spoofing 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.

    Jika implementasi perangkat ingin memperlakukan sensor biometrik sebagai Kelas 3 (sebelumnya Strong), mereka:

    • [C-3-3] HARUS memiliki tingkat penerimaan spoof dan penipu tidak lebih tinggi dari 7%, dengan (1) tingkat penerimaan spoofing 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.

  • 7.3.13 IEEE 802.1.15.4 (UWB): Menambahkan bagian persyaratan baru untuk UWB.

    Lihat revisi

    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-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-1-6] SANGAT DIREKOMENDASIKAN untuk memenuhi kesesuaian yang relevan dan ujian sertifikasi yang ditetapkan oleh organisasi standar, termasuk FIRA, CCC dan CSA.

    Mengakhiri persyaratan baru

  • 7.4.1 Telepon: Update persyaratan telepon untuk telepon GSM dan CDMA, serta penggunaan seluler setelan.

    Lihat revisi

    Jika implementasi perangkat mendukung eUICC atau eSIM/SIM tersemat dan sertakan mekanisme eksklusif untuk menyediakan fungsi eSIM bagi pihak ketiga developer, mereka:

    Jika implementasi perangkat mencakup telepon GSM atau CDMA, maka:

    Jika implementasi perangkat itu meliputi telepon GSM atau CDMA dan menyediakan bilah status sistem, lalu:

    • [C-6-7] 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 dari {i>affordances<i} tersebut termasuk {i>status bar<i} seluler ikon sinyal atau kotak setelan cepat.
    • [C-SR] 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 mencakup telepon GSM atau CDMA, maka:

    • [C-6-8] HARUS mampu membuka dan sekaligus memanfaatkan kapasitas maksimum jumlah saluran logis (total 20) untuk setiap UICC per ETSI TS 102 221.
    • [C-6-10] 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 itu meliputi telepon GSM atau CDMA dan semua aktif, langganan non-oportunistik yang berbagi UUID grup dinonaktifkan, dihapus secara fisik dari perangkat, atau ditandai sebagai oportunistik, lalu perangkat:

    • [C-7-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:

    Jika implementasi perangkat mendukung eUICC dengan beberapa port dan profil, implementasi tersebut:

    Mengakhiri persyaratan baru

  • 7.4.1.1 Kompatibilitas Pemblokiran Nomor: Pembaruan pada persyaratan pemblokiran nomor.

    Lihat revisi

    Jika implementasi perangkat melaporkan android.hardware.telephony feature, mereka:

    • [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.
    • HARUS menyediakan kemampuan pengguna untuk menampilkan panggilan yang diblokir di perangkat yang sudah diinstal aplikasi pemanggil.

    Mengakhiri persyaratan baru

  • 7.4.1.3 Cellular NAT-T Keepalive Offload: Bagian baru untuk Seluler NAT-T Keepalive Offload.

    Lihat revisi

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

    Mengakhiri persyaratan baru

  • 7.4.2.5 Lokasi Wi-Fi (Waktu Round Trip Wi-Fi - RTT): Pembaruan pada akurasi lokasi Wi-Fi.

    Lihat revisi

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

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

    Mengakhiri persyaratan baru

  • 7.4.2.6 Wi-Fi Keepalive Offload: Diperbarui untuk menambahkan persyaratan keepalive offload seluler.

    Lihat revisi

    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
      dan setidaknya satu slot keepalive melalui seluler.

    Jika implementasi perangkat tidak menyertakan dukungan untuk Wi-Fi keepalive offload, mereka:

  • 7.4.2.9 Kepercayaan Saat Penggunaan Pertama (TOFU): Menambahkan bagian persyaratan Kepercayaan pada Penggunaan Pertama.

    Lihat revisi

    7.4.2.9 Kepercayaan Pada Penggunaan Pertama (TOFU)

    Jika implementasi perangkat mendukung Kepercayaan pada penggunaan pertama (TOFU) dan mengizinkan menentukan konfigurasi WPA/WPA2/WPA3-Enterprise, maka mereka:

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

    Mengakhiri persyaratan baru

  • 7.4.3 Bluetooth: Update ke Persyaratan Bluetooth.

    Lihat revisi

    Jika implementasi perangkat mendukung profil Audio Bluetooth, implementasi tersebut:

    • HARUS mendukung Codec Audio Lanjutan dan Codec Audio Bluetooth (misalnya LDAC) dengan A2DP.

    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] 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] 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] SANGAT DIREKOMENDASIKAN untuk mengukur dan mengompensasi offset Tx untuk 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.

    Jika implementasi perangkat mendukung Bluetooth versi 5.0, implementasi tersebut:

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

    Mengakhiri persyaratan baru

  • 7.4.9 UWB: Menambahkan persyaratan untuk perangkat keras UWB.

    Lihat revisi

    7.4.9. UWB

    Jika implementasi perangkat melaporkan dukungan untuk fitur android.hardware.uwb melalui android.content.pm.PackageManager , lalu mereka:

    • [C-1-1] HARUS memastikan pengukuran jarak berada dalam +/-15 cm untuk 95% pengukuran di lingkungan garis pandang pada jarak 1 m dalam non-reflektif.
    • [C-1-2] HARUS memastikan bahwa median pengukuran jarak pada jarak 1 m dari perangkat referensi berada dalam jarak [0,75 m, 1,25 m], di mana kebenaran dasar jarak diukur dari tepi atas DUT yang dipegang menghadap ke atas dan dimiringkan 45 derajat.

    SANGAT DIREKOMENDASIKAN untuk mengikuti langkah-langkah penyiapan pengukuran yang ditentukan dalam Persyaratan Kalibrasi Kehadiran.

    Mengakhiri persyaratan baru

  • 7.5 Kamera: Update pada persyaratan untuk kemampuan output HDR 10-bit.

    Lihat revisi

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

    Mengakhiri persyaratan baru

  • Mode Host USB 7.7.2: Revisi untuk port peran ganda.

    Lihat revisi

    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.

  • 7.11 Kelas Performa Media: Diperbarui untuk menyertakan Android T.

    Lihat revisi

    Jika implementasi perangkat mengembalikan nilai bukan nol untuk android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, ini:

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

    Mengakhiri persyaratan baru

    Lihat bagian 2.2.7 untuk persyaratan khusus perangkat.

9. Kompatibilitas Model Keamanan

  • 9.1 Izin: Memperluas jalur yang diterima untuk daftar izin yang diizinkan bagi aplikasi bawaan ke file APEX.

    Lihat revisi

    • [C-0-2] Izin dengan protectionLevel PROTECTION_FLAG_PRIVILEGED HARUS diberikan hanya ke aplikasi yang diprainstal di jalur dengan hak istimewa image sistem (serta file APEX) dan dalam subkumpulan izin yang diizinkan secara eksplisit untuk setiap . Implementasi AOSP memenuhi persyaratan ini dengan membaca dan mematuhi izin yang diizinkan untuk setiap aplikasi dari file dalam etc/permissions/ dan menggunakan jalur system/priv-app sebagai jalur jalur hak istimewa.

  • 9.7 Fitur Keamanan: Pembaruan pada persyaratan inisialisasi untuk menjaga integritas kernel.

    Lihat revisi

    Integritas kernel dan fitur perlindungan diri merupakan bagian tak terpisahkan dari keamanan Android. Implementasi perangkat:

    • [C-SR] SANGAT DIREKOMENDASIKAN untuk mengaktifkan inisialisasi stack dalam kernel untuk mencegah penggunaan variabel lokal yang tidak diinisialisasi (CONFIG_INIT_STACK_ALL atau CONFIG_INIT_STACK_ALL_ZERO). Selain itu, implementasi perangkat TIDAK BOLEH berasumsi nilai yang digunakan compiler untuk menginisialisasi lokalitas.

    Mengakhiri persyaratan baru

  • 9.8.7 Privasi — Akses Papan Klip: Menghapus data papan klip secara otomatis setelah 60 menit setelah dipotong/disalin/tempel untuk melindungi privasi pengguna.

    Lihat revisi

    Implementasi perangkat:

    • [C-0-1] TIDAK BOLEH mengembalikan data yang terpotong dari clipboard (mis. melalui ClipboardManager API) kecuali pihak ketiga adalah IME default atau aplikasi yang saat ini memiliki fokus.
    • [C-0-2] HARUS menghapus data papan klip paling banyak 60 menit setelah terakhir ditempatkan di papan klip atau dibaca dari papan klip.

  • 9.11 Kunci dan Kredensial: Pembaruan pada persyaratan layar kunci yang aman, termasuk penambahan ECDH dan 3DES ke algoritma kripto.

    Lihat revisi

    Jika implementasi perangkat mendukung layar kunci yang aman, implementasi tersebut:

    • [C-1-2] HARUS memiliki implementasi RSA, AES, ECDSA, ECDH (jika IKeyMintDevice didukung), 3DES, dan algoritma kriptografi HMAC dan hash MD5, SHA1, dan SHA-2 berfungsi untuk secara benar mendukung sistem Android Keystore 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 penerapan Andal, tetapi solusi berbasis ARM TrustZone lain atau pihak ketiga yang ditinjau aman implementasi isolasi berbasis hypervisor yang tepat adalah alternatif lainnya.

  • 9.11.1 Secure Lock Screen, Autentikasi, dan Perangkat Virtual: Menambahkan bagian persyaratan untuk perangkat virtual dan transfer autentikasi.

    Lihat revisi

    Jika implementasi perangkat menambahkan atau mengubah metode autentikasi untuk membuka kunci layar kunci dan metode otentikasi baru didasarkan pada token fisik atau lokasinya:

    • [C-6-3] Pengguna HARUS ditantang untuk mendapatkan salah satu akses utama yang disarankan metode autentikasi (mis. PIN, pola, sandi) setidaknya sekali setiap 4 jam atau kurang. Saat token fisik memenuhi persyaratan untuk implementasi TrustAgent di C-X, pembatasan waktu tunggu didefinisikan dalam C-9-5 berlaku sebagai gantinya.

    Jika implementasi perangkat memungkinkan aplikasi membuat tampilan virtual dan tidak mendukung peristiwa input terkait, seperti melalui VirtualDeviceManager, mereka:

    • [C-9-1] HARUS mengunci tampilan virtual sekunder ini saat layar default dikunci, lalu buka kunci tampilan virtual sekunder ini saat layar default perangkat tidak terkunci.

    Jika implementasi perangkat memungkinkan aplikasi membuat tampilan virtual sekunder dan mendukung peristiwa input terkait, seperti melalui VirtualDeviceManager, mereka:

    • [C-10-1] HARUS mendukung status kunci terpisah per perangkat virtual
    • [C-10-2] HARUS memutuskan sambungan semua perangkat virtual saat waktu tunggu tidak ada aktivitas
    • [C-10-3] HARUS memiliki waktu tunggu tidak ada aktivitas
    • [C-10-4] HARUS mengunci semua layar saat pengguna memulai kunci total, termasuk melalui kemampuan pengguna kunci total yang diperlukan untuk perangkat genggam (lihat Bagian 2.2.5[9.11/H-1-2])
    • [C-10-5] HARUS memiliki instance perangkat virtual terpisah per pengguna
    • [C-10-6] HARUS menonaktifkan pembuatan peristiwa input terkait melalui VirtualDeviceManager jika ditunjukkan oleh DevicePolicyManager.setNearbyAppStreamingPolicy
    • [C-10-7] HARUS menggunakan papan klip terpisah semata-mata untuk setiap perangkat virtual (atau menonaktifkan papan klip untuk perangkat virtual)
    • [C-10-11] HARUS menonaktifkan UI autentikasi pada perangkat virtual, termasuk entri faktor pengetahuan dan perintah biometrik
    • [C-10-12] HARUS membatasi intent yang dimulai dari perangkat virtual untuk menampilkan hanya di perangkat virtual yang sama
    • [C-10-13] TIDAK BOLEH menggunakan status penguncian perangkat virtual sebagai autentikasi pengguna pada Sistem Android Keystore. Lihat KeyGenParameterSpec.Builder.setUserAuthentication*.

    Saat implementasi perangkat memungkinkan pengguna mentransfer faktor pengetahuan otentikasi dari perangkat sumber ke perangkat target, seperti untuk penyiapan awal perangkat target, mereka:

    • [C-11-1] HARUS mengenkripsi faktor pengetahuan dengan jaminan perlindungan seperti yang dijelaskan dalam Google Cloud Key Vault Service laporan resmi keamanan saat mentransfer faktor pengetahuan dari perangkat sumber ke perangkat target sehingga faktor pengetahuan tidak dapat didekripsi dari jarak jauh atau digunakan untuk membuka kunci dari jarak jauh di kedua perangkat.
    • [C-11-2] HARUS, pada perangkat sumber , minta pengguna untuk mengonfirmasi faktor pengetahuan perangkat sumber sebelum mentransfer faktor pengetahuan ke perangkat target.
    • [C-11-3] HARUS, pada perangkat target yang tidak memiliki autentikasi utama yang ditetapkan faktor pengetahuan, minta pengguna untuk mengkonfirmasi faktor pengetahuan yang ditransfer pada perangkat target sebelum menetapkan faktor pengetahuan tersebut sebagai faktor pengetahuan otentikasi untuk perangkat target dan sebelum membuat tersedia untuk semua data yang ditransfer dari perangkat sumber.

    Jika implementasi perangkat memiliki layar kunci yang aman dan menyertakan satu atau beberapa tepercaya, yang memanggil TrustAgentService.grantTrust() System API dengan flag FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE yang:

    • [C-12-1] Hanya boleh memanggil grantTrust() dengan flag saat terhubung ke perangkat fisik jarak dekat dengan layar kunci itu sendiri, dan ketika pengguna memiliki mengotentikasi identitas mereka terhadap layar kunci itu. Perangkat yang dapat mendekati dapat gunakan mekanisme deteksi di pergelangan tangan atau pada tubuh setelah pengguna satu kali membuka kunci untuk memenuhi persyaratan otentikasi pengguna.
    • [C-12-2] HARUS menempatkan implementasi perangkat ke dalam TrustState.TRUSTABLE keadaan saat layar dimatikan (misalnya dengan menekan tombol atau waktu tunggu) dan TrustAgent belum mencabut kepercayaan. AOSP memenuhi persyaratan ini.
    • [C-12-3] Hanya boleh memindahkan perangkat dari TrustState.TRUSTABLE ke TrustState.TRUSTED menyatakan jika TrustAgent masih memberikan kepercayaan berdasarkan persyaratan dalam C-12-1.
    • [C-12-4] HARUS memanggil TrustManagerService.revokeTrust() setelah jumlah maksimum 24 jam sejak memberikan kepercayaan, periode tidak ada aktivitas selama 8 jam, atau saat koneksi ke perangkat fisik di dekat Anda terputus.

    Jika implementasi perangkat memungkinkan aplikasi membuat tampilan virtual sekunder dan mendukung input terkait peristiwa seperti melalui VirtualDeviceManager dan layar tidak ditandai dengan VIRTUAL_DISPLAY_FLAG_SECURE, berarti layar tersebut:

    • [C-13-8] HARUS memblokir aktivitas dengan atribut android:canDisplayOnRemoteDevices atau android.activity.can_display_on_remote_devices yang disetel ke salah (false) agar tidak dimulai di perangkat virtual.
    • [C-13-9] HARUS memblokir aktivitas yang tidak secara eksplisit mengaktifkan {i>streaming<i} dan yang menunjukkan konten sensitif, termasuk melalui SurfaceView#setSecure, FLAG_SECURE, atau SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS, agar tidak menjadi dimulai di perangkat virtual.
    • [C-13-10] HARUS menonaktifkan penginstalan aplikasi yang dimulai dari perangkat virtual.

    Mengakhiri persyaratan baru

  • 9.11.2 Strongbox: Pembuatan {i>Insider Attack Resistance<i} (IAR) adalah persyaratan yang diperlukan.

    Lihat revisi

    Untuk memvalidasi kepatuhan terhadap [C-1-3] hingga [C-1-9], implementasi perangkat:

    • [C-SR] SANGAT DIREKOMENDASIKAN untuk memberikan ketahanan serangan {i>innerr<i} (IAR), yang berarti bahwa orang dalam yang memiliki akses ke kunci penandatanganan {i> firmware<i} tidak dapat menghasilkan firmware yang menyebabkan StrongBox membocorkan secret, untuk melewati keamanan fungsional persyaratan atau mengaktifkan akses ke data pengguna yang sensitif. Tujuan cara yang disarankan untuk mengimplementasikan IAR adalah dengan mengizinkan pembaruan {i>firmware <i}hanya ketika {i>password<i} pengguna utama disediakan melalui HAL IAuthSecret. IAR akan menjadi persyaratan WAJIB dalam Android 14.

  • 9.11.3 Identity Credential: Menambahkan informasi tentang implementasi referensi sistem Identity Credential.

    Lihat revisi

    Sistem Kredensial Identitas ditetapkan dan dicapai dengan mengimplementasikan semua API di android.security.identity.* paket. API ini memungkinkan developer aplikasi menyimpan dan mengambil identitas pengguna yang informatif serta dipersonalisasi. Implementasi perangkat:

    Project Open Source Android upstream menyediakan implementasi referensi aplikasi tepercaya (libeik) yang dapat digunakan untuk mengimplementasikan sistem Identity Credential.

    Mengakhiri persyaratan baru

  • 9.11.4 Pengesahan ID: Menambahkan bagian untuk persyaratan pengesahan ID.

    Lihat revisi

    9.11.4. Pengesahan Tanda Pengenal

    Implementasi perangkat HARUS mendukung pengesahan ID.

    Mengakhiri persyaratan baru

  • Framework Virtualisasi Android 9.17: Menambahkan bagian persyaratan untuk Framework Virtualisasi Android.

    Lihat revisi

    9.17. Framework Virtualisasi Android

    Jika perangkat mengimplementasikan dukungan untuk Android Virtualization Framework API (android.system.virtualmachine.*), host Android:

    • [C-1-1] HARUS mendukung semua API yang didefinisikan oleh android.system.virtualmachine.*.
    • [C-1-2] TIDAK BOLEH memodifikasi Android SELinux dan model izin untuk pengelolaan VM Protected Virtual Machines.
    • [C-1-3] TIDAK BOLEH memodifikasi, menghilangkan, atau mengganti aturan Neverallow yang ada dalam sistem/sepolicy yang disediakan di Project Open Source Android upstream (AOSP) dan kebijakan HARUS dikompilasi dengan semua aturan yang tidak diizinkan.
    • [C-1-4] TIDAK BOLEH mengizinkan kode yang tidak tepercaya (mis. aplikasi 3p) untuk membuat dan menjalankan Virtual Machine yang Dilindungi. Catatan: Hal ini mungkin berubah dalam rilis Android mendatang.
    • [C-1-5] TIDAK BOLEH mengizinkan Protected Virtual Machine menjalankan kode yang bukan bagian dari setelan pabrik atau pembaruannya. Segala sesuatu yang tidak dicakup oleh Booting Terverifikasi Android (mis. file yang diunduh dari internet atau di-sideload) TIDAK BOLEH diizinkan untuk dijalankan di Protected Virtual Machine.

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

    • [C-2-1] HARUS dapat menjalankan semua sistem operasi yang tersedia di APEX virtualisasi dalam Protected Virtual Machine.
    • [C-2-2] TIDAK BOLEH mengizinkan Protected Virtual Machine menjalankan sistem operasi yang tidak ditandatangani oleh implementasi perangkat atau vendor OS.
    • [C-2-3] TIDAK BOLEH mengizinkan Protected Virtual Machine menjalankan data sebagai kode (misalnya, SELinux Neverallow execmem).
    • [C-2-4] TIDAK BOLEH memodifikasi, menghilangkan, atau mengganti aturan neverallow yang ada dalam sistem/sepolicy/microdroid yang disediakan di Open Source Android upstream Project (AOSP).
    • [C-2-5] HARUS mengimplementasikan mekanisme defense in depth Protected Virtual Machine (misalnya SELinux untuk pVM) bahkan untuk sistem operasi non-Microdroid.
    • [C-2-6] HARUS memastikan bahwa firmware pVM menolak untuk boot jika tidak dapat memverifikasi gambar awal.
    • [C-2-7] HARUS memastikan bahwa firmware pVM menolak untuk {i>booting<i} jika integritas instance.img disusupi.

    Jika perangkat mengimplementasikan dukungan untuk Android Virtualization Framework API (android.system.virtualmachine.*), hypervisor:

    • [C-3-1] TIDAK BOLEH mengizinkan pVM apa pun mengakses halaman milik orang lain entitas (yaitu pVM atau hypervisor lain), kecuali jika dibagikan secara eksplisit oleh halaman pemilik situs. Ini termasuk VM host. Hal ini berlaku untuk akses CPU dan DMA.
    • [C-3-2] HARUS menghapus halaman setelah digunakan oleh VM dan sebelum halaman tersebut ditampilkan ke host (misalnya, PVM dihancurkan).
    • [C-3-3] HARUS memastikan bahwa firmware pVM dimuat dan dieksekusi sebelum kode apa pun dalam pVM.
    • [C-3-4] HARUS memastikan bahwa BCC dan CDI yang diberikan ke instance pVM hanya dapat turunan dari instance tertentu.

    Jika perangkat mengimplementasikan dukungan untuk Android Virtualization Framework API, lalu di semua area:

    • [C-4-1] TIDAK BOLEH menyediakan fungsionalitas ke pVM yang memungkinkan pengabaian Model Keamanan Android.

    Jika perangkat mengimplementasikan dukungan untuk Android Virtualization Framework API, maka:

    • [C-5-1] HARUS mendukung Kompilasi Terisolasi dari update runtime ART.

    Jika perangkat mengimplementasikan dukungan untuk Android Virtualization Framework API, maka untuk Key Management:

    • [C-6-1] HARUS root rantai DICE pada titik yang tidak dapat dimodifikasi oleh pengguna, bahkan pada perangkat yang tidak terkunci. (Untuk memastikan konten tidak boleh di-spoofing).
    • [C-6-2] HARUS melakukan DICE dengan benar, yaitu memberikan nilai yang benar. Tapi mungkin tidak perlu mengikuti tingkat detail itu.

    Mengakhiri persyaratan baru

13. Hubungi Kami

Anda dapat bergabung dengan forum kompatibilitas android dan minta klarifikasi atau sampaikan masalah apa pun yang menurut Anda tidak ada dalam dokumen sampul.