Definisi Kompatibilitas Android 9

1. Pengantar

Dokumen ini mencantumkan persyaratan yang harus dipenuhi agar perangkat kompatibel dengan Android 9.

Penggunaan “HARUS”, “TIDAK BOLEH”, “WAJIB”, “HARUS”, “TIDAK BOLEH”, “HARUS”, “TIDAK BOLEH”, “DISARANKAN”, “MUNGKIN”, dan “OPSIONAL” sesuai dengan standar IETF yang ditentukan dalam RFC2119.

Seperti yang digunakan dalam dokumen ini, “penerapkan perangkat” atau “penerapkan” adalah orang atau organisasi yang mengembangkan solusi hardware/software yang menjalankan Android 9. “Penerapan perangkat” atau “penerapan” adalah solusi hardware/software yang dikembangkan.

Agar dianggap kompatibel dengan Android 9, implementasi perangkat HARUS memenuhi persyaratan yang disajikan dalam Definisi Kompatibilitas ini, termasuk dokumen apa pun yang disertakan melalui referensi.

Jika definisi ini atau pengujian software yang dijelaskan dalam bagian 10 tidak jelas, ambigu, atau tidak lengkap, implementator perangkat bertanggung jawab untuk memastikan kompatibilitas dengan implementasi yang ada.

Karena alasan ini, Project Open Source Android adalah referensi dan implementasi Android yang lebih disukai. Implementator perangkat SANGAT DISARANKAN untuk mendasarkan implementasi mereka sebanyak mungkin pada kode sumber “upstream” yang tersedia dari Project Open Source Android. Meskipun secara hipotetis beberapa komponen dapat diganti dengan implementasi alternatif, SANGAT DISARANKAN untuk tidak mengikuti praktik ini, karena lulus pengujian software akan menjadi jauh lebih sulit. Implementer bertanggung jawab untuk memastikan kompatibilitas perilaku penuh dengan implementasi Android standar, termasuk dan di luar Compatibility Test Suite. Terakhir, perhatikan bahwa penggantian dan modifikasi komponen tertentu secara eksplisit dilarang oleh dokumen ini.

Banyak referensi yang ditautkan dalam dokumen ini berasal secara langsung atau tidak langsung dari Android SDK dan akan identik secara fungsional dengan informasi dalam dokumentasi SDK tersebut. Jika Definisi Kompatibilitas ini atau Compatibility Test Suite tidak sesuai dengan dokumentasi SDK, dokumentasi SDK dianggap kredibel. Semua detail teknis yang diberikan dalam referensi tertaut di seluruh dokumen ini dianggap sebagai bagian dari Definisi Kompatibilitas ini.

1.1 Struktur Dokumen

1.1.1. Persyaratan menurut Jenis Perangkat

Bagian 2 berisi semua persyaratan yang berlaku untuk jenis perangkat tertentu. Setiap subbagian Bagian 2 ditujukan untuk jenis perangkat tertentu.

Semua persyaratan lainnya, yang berlaku secara universal untuk setiap penerapan perangkat Android, tercantum di bagian setelah Bagian 2. Persyaratan ini dirujuk sebagai "Persyaratan Inti" dalam dokumen ini.

1.1.2. ID Persyaratan

ID persyaratan ditetapkan untuk persyaratan MUST.

  • ID hanya ditetapkan untuk persyaratan HARUS.
  • Persyaratan YANG SANGAT DIUJAMI di tandai sebagai [SR], tetapi ID tidak ditetapkan.
  • ID terdiri dari : ID Jenis Perangkat - ID Kondisi - ID Persyaratan (misalnya, C-0-1).

Setiap ID ditentukan sebagai berikut:

  • ID Jenis Perangkat (lihat selengkapnya di 2. Jenis Perangkat)
    • C: Core (Persyaratan yang diterapkan ke implementasi perangkat Android apa pun)
    • H: Perangkat Genggam Android
    • T: Perangkat Android TV
    • A: Implementasi Android Automotive
    • Tab: Implementasi Tablet Android
  • ID Kondisi
    • Jika persyaratannya tidak bersyarat, ID ini ditetapkan sebagai 0.
    • Jika persyaratan bersifat kondisional, 1 ditetapkan untuk kondisi ke-1 dan jumlahnya bertambah 1 dalam bagian yang sama dan jenis perangkat yang sama.
  • ID Persyaratan
    • ID ini dimulai dari 1 dan bertambah 1 dalam bagian yang sama dan kondisi yang sama.

1.1.3. ID Persyaratan di Bagian 2

ID Persyaratan di Bagian 2 dimulai dengan ID bagian yang sesuai 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

Meskipun Project Open Source Android menyediakan stack software yang dapat digunakan untuk berbagai jenis perangkat dan faktor bentuk, ada beberapa jenis perangkat yang memiliki ekosistem distribusi aplikasi yang relatif lebih baik.

Bagian ini menjelaskan jenis perangkat tersebut, serta persyaratan dan rekomendasi tambahan yang berlaku untuk setiap jenis perangkat.

Semua implementasi perangkat Android yang tidak sesuai dengan jenis perangkat yang dijelaskan HARUS tetap memenuhi semua persyaratan di bagian lain Definisi Kompatibilitas ini.

2.1 Konfigurasi Perangkat

Untuk mengetahui perbedaan utama dalam konfigurasi hardware menurut jenis perangkat, lihat persyaratan khusus perangkat yang akan dijelaskan di bagian ini.

2.2. Persyaratan Perangkat Genggam

Perangkat Genggam Android mengacu pada implementasi perangkat Android yang biasanya digunakan dengan memegangnya di tangan, seperti pemutar mp3, ponsel, atau tablet.

Implementasi perangkat Android diklasifikasikan sebagai Perangkat Genggam jika memenuhi semua kriteria berikut:

  • Memiliki sumber daya yang memberikan mobilitas, seperti baterai.
  • Memiliki ukuran layar diagonal fisik dalam rentang 2,5 hingga 8 inci.

Persyaratan tambahan di bagian lain ini khusus untuk implementasi perangkat Genggam Android.

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 layar dengan ukuran diagonal fisik minimal 2,5 inci.
  • [7.1.1.3/H-SR] SANGAT DISARANKAN untuk memberi pengguna kemampuan untuk mengubah ukuran tampilan.(Kepadatan Layar)

Jika implementasi perangkat Genggam mengklaim dukungan untuk layar rentang dinamis tinggi melalui Configuration.isScreenHdr() , perangkat tersebut:

  • [7.1.4.5/H-1-1] HARUS mengiklankan dukungan untuk ekstensi EGL_EXT_gl_colorspace_bt2020_pq, EGL_EXT_surface_SMPTE2086_metadata, EGL_EXT_surface_CTA861_3_metadata, VK_EXT_swapchain_colorspace, dan VK_EXT_hdr_metadata.

Implementasi perangkat genggam:

  • [7.1.5/H-0-1] HARUS menyertakan dukungan untuk mode kompatibilitas aplikasi lama seperti yang diterapkan oleh kode open source Android upstream. Artinya, implementasi perangkat TIDAK BOLEH mengubah pemicu atau nilai minimum saat mode kompatibilitas diaktifkan, dan TIDAK BOLEH mengubah perilaku mode kompatibilitas itu sendiri.
  • [7.2.1/H-0-1] HARUS menyertakan dukungan untuk aplikasi Editor Metode Input (IME) pihak ketiga.
  • [7.2.3/H-0-1] HARUS menyediakan fungsi Beranda, Terbaru, dan Kembali.
  • [7.2.3/H-0-2] HARUS mengirim peristiwa tekan lama dan normal dari fungsi Kembali (KEYCODE_BACK) ke aplikasi latar depan. Peristiwa ini TIDAK BOLEH digunakan oleh sistem dan DAPAT dipicu oleh perangkat di luar Android (misalnya, keyboard hardware eksternal yang terhubung ke perangkat Android).
  • [7.2.4/H-0-1] HARUS mendukung input layar sentuh.
  • [7.2.4/H-SR] SANGAT DISARANKAN untuk meluncurkan aplikasi bantuan yang dipilih pengguna, dengan kata lain aplikasi yang menerapkan 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] SANGAT DIUJAMI untuk menyertakan akselerometer 3 sumbu.

Jika implementasi Perangkat genggam menyertakan akselerometer 3 sumbu, akselerometer tersebut:

  • [7.3.1/H-1-1] HARUS dapat melaporkan peristiwa hingga frekuensi minimal 100 Hz.

Jika implementasi Perangkat genggam menyertakan giroskop, perangkat tersebut:

  • [7.3.4/H-1-1] HARUS dapat melaporkan peristiwa hingga frekuensi minimal 100 Hz.

Implementasi perangkat genggam yang dapat melakukan panggilan suara dan menunjukkan nilai selain PHONE_TYPE_NONE di getPhoneType:

  • [7.3.8/H] HARUS menyertakan sensor kedekatan.

Implementasi perangkat genggam:

  • [7.3.12/H-SR] DISARANKAN untuk mendukung sensor pose dengan 6 derajat kebebasan.
  • [7.4.3/H] HARUS menyertakan dukungan untuk Bluetooth dan Bluetooth LE.

Jika implementasi Perangkat genggam menyertakan koneksi berbayar, perangkat tersebut:

  • [7.4.7/H-1-1] HARUS menyediakan mode penghemat data.

Implementasi perangkat genggam:

  • [7.6.1/H-0-1] HARUS memiliki penyimpanan non-volatil minimal 4 GB yang tersedia untuk data pribadi aplikasi (alias partisi "/data").
  • [7.6.1/H-0-2] HARUS menampilkan “true” untuk ActivityManager.isLowRamDevice() jika ada memori kurang dari 1 GB yang tersedia untuk kernel dan ruang pengguna.

Jika implementasi perangkat Genggam mendeklarasikan dukungan hanya untuk ABI 32-bit:

  • [7.6.1/H-1-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 416 MB jika layar default menggunakan resolusi framebuffer hingga qHD (misalnya, FWVGA).

  • [7.6.1/H-2-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 592 MB jika layar default menggunakan resolusi framebuffer hingga HD+ (misalnya, HD, WSVGA).

  • [7.6.1/H-3-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 896 MB jika layar default menggunakan resolusi framebuffer hingga FHD (misalnya, WSXGA+).

  • [7.6.1/H-4-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 1344 MB jika layar default menggunakan resolusi framebuffer hingga QHD (misalnya, QWXGA).

Jika implementasi perangkat Genggam mendeklarasikan dukungan ABI 64-bit (dengan atau tanpa ABI 32-bit):

  • [7.6.1/H-5-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 816 MB jika layar default menggunakan resolusi framebuffer hingga qHD (misalnya, FWVGA).

  • [7.6.1/H-6-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 944 MB jika layar default menggunakan resolusi framebuffer hingga HD+ (misalnya, HD, WSVGA).

  • [7.6.1/H-7-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 1280 MB jika layar default menggunakan resolusi framebuffer hingga FHD (misalnya, WSXGA+).

  • [7.6.1/H-8-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 1824 MB jika layar default menggunakan resolusi framebuffer hingga QHD (misalnya, QWXGA).

Perhatikan bahwa "memori yang tersedia untuk kernel dan ruang pengguna" di atas mengacu pada ruang memori yang disediakan selain memori yang sudah dikhususkan untuk komponen hardware seperti radio, video, dan sebagainya yang tidak berada di bawah kontrol kernel pada implementasi perangkat.

Jika implementasi perangkat Genggam menyertakan memori kurang dari atau sama dengan 1 GB yang tersedia untuk kernel dan ruang pengguna, perangkat tersebut:

  • [7.6.1/H-9-1] HARUS mendeklarasikan tombol fitur android.hardware.ram.low.
  • [7.6.1/H-9-2] HARUS memiliki penyimpanan non-volatil minimal 1,1 GB untuk data pribadi aplikasi (alias partisi "/data").

Jika implementasi perangkat Genggam menyertakan lebih dari 1 GB memori yang tersedia untuk kernel dan ruang pengguna, perangkat tersebut:

  • [7.6.1/H-10-1] HARUS memiliki penyimpanan non-volatil minimal 4 GB yang tersedia untuk data pribadi aplikasi (alias partisi "/data").
  • HARUS mendeklarasikan flag fitur android.hardware.ram.normal.

Implementasi perangkat genggam:

  • [7.6.2/H-0-1] TIDAK BOLEH menyediakan penyimpanan bersama aplikasi yang lebih kecil dari 1 GiB.
  • [7.7.1/H] HARUS menyertakan port USB yang mendukung mode periferal.

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

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

Implementasi perangkat genggam:

  • [7.8.1/H-0-1] HARUS menyertakan mikrofon.
  • [7.8.2/H-0-1] HARUS memiliki output audio dan mendeklarasikan android.hardware.audio.output.

Jika implementasi perangkat Genggam mampu memenuhi semua persyaratan performa untuk mendukung mode VR dan menyertakan dukungan untuknya, perangkat tersebut:

  • [7.9.1/H-1-1] HARUS mendeklarasikan tombol fitur android.hardware.vr.high_performance.
  • [7.9.1/H-1-2] HARUS menyertakan aplikasi yang menerapkan android.service.vr.VrListenerService yang dapat diaktifkan oleh aplikasi VR melalui android.app.Activity#setVrModeEnabled.

2.2.2. Multimedia

Implementasi perangkat genggam HARUS mendukung encoding audio berikut:

  • [5.1.1/H-0-1] AMR-NB
  • [5.1.1/H-0-2] AMR-WB
  • [5.1.1/H-0-3] Profil MPEG-4 AAC (AAC LC)
  • [5.1.1/H-0-4] Profil MPEG-4 HE AAC (AAC+)
  • [5.1.1/H-0-5] AAC ELD (AAC yang ditingkatkan dengan delay rendah)

Implementasi perangkat genggam HARUS mendukung dekode audio berikut:

  • [5.1.2/H-0-1] AMR-NB
  • [5.1.2/H-0-2] AMR-WB

Implementasi perangkat genggam HARUS mendukung encoding video berikut dan menyediakannya untuk aplikasi pihak ketiga:

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

Implementasi perangkat genggam HARUS mendukung decoding video berikut:

  • [5.3/H-0-1] H.264 AVC
  • [5.3/H-0-2] H.265 HEVC
  • [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 intent ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE, dan ACTION_CREATE_DOCUMENT seperti yang dijelaskan dalam dokumen SDK, dan memberikan kemampuan kepada pengguna untuk mengakses data penyedia dokumen menggunakan DocumentsProvider API.
  • [3.4.1/H-0-1] HARUS menyediakan implementasi lengkap android.webkit.Webview API.
  • [3.4.2/H-0-1] HARUS menyertakan aplikasi Browser mandiri untuk penjelajahan web pengguna umum.
  • [3.8.1/H-SR] SANGAT DIUJAMI untuk menerapkan peluncur default yang mendukung penyematan pintasan, widget, dan widgetFeatures dalam aplikasi.
  • [3.8.1/H-SR] SANGAT DIUJAMI untuk menerapkan peluncur default yang memberikan akses cepat ke pintasan tambahan yang disediakan oleh aplikasi pihak ketiga melalui ShortcutManager API.
  • [3.8.1/H-SR] SANGAT DISARANKAN untuk menyertakan aplikasi peluncur default yang menampilkan badge untuk ikon aplikasi.
  • [3.8.2/H-SR] SANGAT DIUJI untuk mendukung widget aplikasi pihak ketiga.
  • [3.8.3/H-0-1] HARUS mengizinkan aplikasi pihak ketiga untuk memberi tahu pengguna tentang peristiwa penting melalui class API Notification dan NotificationManager.
  • [3.8.3/H-0-2] HARUS mendukung notifikasi kaya.
  • [3.8.3/H-0-3] HARUS mendukung notifikasi pemberitahuan.
  • [3.8.3/H-0-4] HARUS menyertakan menu notifikasi, yang memberi pengguna kemampuan untuk mengontrol notifikasi secara langsung (misalnya, membalas, menunda, menutup, memblokir) melalui kemampuan pengguna seperti tombol tindakan atau panel kontrol seperti yang diterapkan di AOSP.
  • [3.8.3/H-0-5] HARUS menampilkan pilihan yang diberikan melalui RemoteInput.Builder setChoices() di menu notifikasi.
  • [3.8.3/H-SR] SANGAT DIUJAMI untuk menampilkan pilihan pertama yang diberikan melalui RemoteInput.Builder setChoices() di panel notifikasi tanpa interaksi pengguna tambahan.
  • [3.8.3/H-SR] SANGAT DISARANKAN untuk menampilkan semua pilihan yang disediakan melalui RemoteInput.Builder setChoices() di menu notifikasi saat pengguna meluaskan semua notifikasi di menu notifikasi.
  • [3.8.4/H-SR] SANGAT DISARANKAN untuk menerapkan asisten di perangkat guna menangani tindakan Bantuan.

Jika implementasi perangkat Genggam mendukung tindakan Bantuan, perangkat tersebut:

  • [3.8.4/H-SR] SANGAT DISARANKAN untuk menggunakan tekan lama pada tombol HOME sebagai interaksi yang ditetapkan untuk meluncurkan aplikasi bantuan seperti yang dijelaskan di bagian 7.2.3. HARUS meluncurkan aplikasi bantuan yang dipilih pengguna, dengan kata lain aplikasi yang menerapkan VoiceInteractionService , atau aktivitas yang menangani intent ACTION_ASSIST.

Jika implementasi perangkat Genggam Android mendukung layar kunci, perangkat tersebut:

  • [3.8.10/H-1-1] HARUS menampilkan Notifikasi layar kunci termasuk Template Notifikasi Media.

Jika implementasi Perangkat genggam mendukung layar kunci yang aman, implementasi tersebut:

  • [3.9/H-1-1] HARUS menerapkan berbagai kebijakan administrasi perangkat yang ditentukan dalam dokumentasi Android SDK.
  • [3.9/H-1-2] HARUS mendeklarasikan dukungan profil terkelola melalui flag fitur android.software.managed_users, kecuali jika perangkat dikonfigurasi sehingga melaporkan dirinya sebagai perangkat dengan RAM rendah atau mengalokasikan penyimpanan internal (tidak dapat dilepas) sebagai penyimpanan bersama.

Implementasi perangkat genggam:

  • [3.10/H-0-1] HARUS mendukung layanan aksesibilitas pihak ketiga.
  • [3.10/H-SR] SANGAT DISARANKAN untuk memuat layanan aksesibilitas di perangkat secara otomatis yang sebanding dengan atau melebihi fungsi layanan aksesibilitas Tombol Akses dan TalkBack (untuk bahasa yang didukung oleh mesin Text-to-speech yang diinstal sebelumnya) seperti yang disediakan dalam project open source talkback.
  • [3.11/H-0-1] HARUS mendukung penginstalan mesin TTS pihak ketiga.
  • [3.11/H-SR] SANGAT DISARANKAN untuk menyertakan mesin TTS yang mendukung bahasa yang tersedia di perangkat.
  • [3.13/H-SR] SANGAT DIUJAMI untuk menyertakan komponen UI Setelan Cepat.

Jika implementasi perangkat genggam Android mendeklarasikan dukungan FEATURE_BLUETOOTH atau FEATURE_WIFI, implementasi tersebut:

  • [3.16/H-1-1] HARUS mendukung fitur penyambungan perangkat pendamping.

2.2.4. Performa dan Daya

  • [8.1/H-0-1] Latensi frame yang konsisten. Latensi frame yang tidak konsisten atau penundaan untuk merender frame TIDAK BOLEH terjadi lebih dari 5 frame per detik, dan HARUS di bawah 1 frame per detik.
  • [8.1/H-0-2] Latensi antarmuka pengguna. Implementasi perangkat HARUS memastikan pengalaman pengguna latensi rendah dengan men-scroll daftar 10 ribu entri daftar seperti yang ditentukan oleh Android Compatibility Test Suite (CTS) dalam waktu kurang dari 36 detik.
  • [8.1/H-0-3] Penggantian tugas. Jika beberapa aplikasi telah diluncurkan, meluncurkan ulang aplikasi yang sudah berjalan setelah diluncurkan HARUS memerlukan waktu kurang dari 1 detik.

Implementasi perangkat genggam:

  • [8.2/H-0-1] HARUS memastikan performa operasi tulis berurutan minimal 5 MB/dtk.
  • [8.2/H-0-2] HARUS memastikan performa operasi tulis acak minimal 0,5 MB/s.
  • [8.2/H-0-3] HARUS memastikan performa baca berurutan minimal 15 MB/dtk.
  • [8.2/H-0-4] HARUS memastikan performa pembacaan acak minimal 3,5 MB/s.

Jika implementasi perangkat Genggam menyertakan fitur untuk meningkatkan pengelolaan daya perangkat yang disertakan dalam AOSP atau memperluas fitur yang disertakan dalam AOSP, implementasi tersebut:

  • [8.3/H-1-1] HARUS memberikan kemampuan kepada pengguna untuk mengaktifkan dan menonaktifkan fitur penghemat baterai.
  • [8.3/H-1-2] HARUS memberikan kemampuan pengguna untuk menampilkan semua aplikasi yang dikecualikan dari mode hemat daya Aplikasi Standby dan Istirahatkan.

Implementasi perangkat genggam:

  • [8.4/H-0-1] HARUS menyediakan profil daya per komponen yang menentukan nilai konsumsi saat ini untuk setiap komponen hardware dan perkiraan pemakaian baterai yang disebabkan oleh komponen dari waktu ke waktu seperti yang didokumentasikan di situs Android Open Source Project.
  • [8.4/H-0-2] HARUS melaporkan semua nilai konsumsi daya dalam miliamper jam (mAh).
  • [8.4/H-0-3] HARUS melaporkan konsumsi daya CPU per setiap UID proses. Project Open Source Android memenuhi persyaratan melalui penerapan modul kernel uid_cputime.
  • [8.4/H-0-4] HARUS menyediakan penggunaan daya ini melalui perintah shell adb shell dumpsys batterystats kepada developer aplikasi.
  • [8.4/H] HARUS diatribusikan ke komponen hardware itu sendiri jika tidak dapat mengatribusikan penggunaan daya komponen hardware ke aplikasi.

Jika implementasi Perangkat genggam menyertakan output layar atau video, implementasi tersebut:

2.2.5. Model Keamanan

Implementasi perangkat genggam:

  • [9.1/H-0-1] HARUS mengizinkan aplikasi pihak ketiga mengakses statistik penggunaan melalui izin android.permission.PACKAGE_USAGE_STATS dan menyediakan mekanisme yang dapat diakses pengguna untuk memberikan atau mencabut akses ke aplikasi tersebut sebagai respons terhadap intent android.settings.ACTION_USAGE_ACCESS_SETTINGS.

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

  • [9.11/H-1-1] HARUS mengizinkan pengguna memilih waktu tunggu tidur terpendek, yaitu waktu transisi dari status tidak terkunci ke terkunci, yaitu 15 detik atau kurang.
  • [9.11/H-1-2] HARUS memberikan kemampuan pengguna untuk menyembunyikan notifikasi dan menonaktifkan semua bentuk autentikasi kecuali autentikasi utama yang dijelaskan dalam 9.11.1 Layar Kunci yang Aman. AOSP memenuhi persyaratan sebagai mode kunci total.

2.3. Persyaratan Televisi

Perangkat Android Television mengacu pada implementasi perangkat Android yang merupakan antarmuka hiburan untuk menikmati media digital, film, game, aplikasi, dan/atau TV live bagi pengguna yang duduk sekitar tiga meter dari perangkat (antarmuka pengguna “santai” atau “10 kaki”).

Implementasi perangkat Android diklasifikasikan sebagai Televisi jika memenuhi semua kriteria berikut:

  • Telah menyediakan mekanisme untuk mengontrol antarmuka pengguna yang dirender dari jarak jauh di layar yang mungkin berada tiga meter dari pengguna.
  • Memiliki layar yang disematkan dengan panjang diagonal lebih besar dari 24 inci ATAU menyertakan port output video, seperti VGA, HDMI, DisplayPort, atau port nirkabel untuk layar.

Persyaratan tambahan di bagian lain ini khusus untuk implementasi perangkat Android Television.

2.3.1. Hardware

Penerapan perangkat televisi:

  • [7.2.2/T-0-1] HARUS mendukung D-pad.
  • [7.2.3/T-0-1] HARUS menyediakan fungsi Beranda dan Kembali.
  • [7.2.3/T-0-2] HARUS mengirim peristiwa tekan lama dan normal dari fungsi Kembali (KEYCODE_BACK) ke aplikasi latar depan.
  • [7.2.6.1/T-0-1] HARUS menyertakan dukungan untuk pengontrol game dan mendeklarasikan flag fitur android.hardware.gamepad.
  • [7.2.7/T] HARUS menyediakan kontrol jarak jauh yang dapat digunakan pengguna untuk mengakses input navigasi non-sentuh dan tombol navigasi inti.

Jika implementasi perangkat Televisi menyertakan giroskop, perangkat tersebut:

  • [7.3.4/T-1-1] HARUS dapat melaporkan peristiwa hingga frekuensi minimal 100 Hz.

Penerapan perangkat televisi:

  • [7.4.3/T-0-1] HARUS mendukung Bluetooth dan Bluetooth LE.
  • [7.6.1/T-0-1] HARUS memiliki penyimpanan non-volatil minimal 4 GB yang tersedia untuk data pribadi aplikasi (alias partisi "/data").

Jika implementasi perangkat Televisi menyertakan port USB yang mendukung mode host, port tersebut:

  • [7.5.3/T-1-1] HARUS menyertakan dukungan untuk kamera eksternal yang terhubung melalui port USB ini, tetapi tidak harus selalu terhubung.

Jika implementasi perangkat TV adalah 32-bit:

  • [7.6.1/T-1-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 896 MB jika salah satu kepadatan berikut digunakan:

    • 400 dpi atau lebih tinggi di layar kecil/normal
    • xhdpi atau yang lebih tinggi di layar besar
    • tvdpi atau yang lebih tinggi di layar ekstra besar

Jika implementasi perangkat TV adalah 64-bit:

  • [7.6.1/T-2-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 1280 MB jika salah satu kepadatan berikut digunakan:

    • 400 dpi atau lebih tinggi di layar kecil/normal
    • xhdpi atau yang lebih tinggi di layar besar
    • tvdpi atau yang lebih tinggi di layar ekstra besar

Perhatikan bahwa "memori yang tersedia untuk kernel dan ruang pengguna" di atas mengacu pada ruang memori yang disediakan selain memori yang sudah dikhususkan untuk komponen hardware seperti radio, video, dan sebagainya yang tidak berada di bawah kontrol kernel pada implementasi perangkat.

Penerapan perangkat televisi:

  • [7.8.1/T] HARUS menyertakan mikrofon.
  • [7.8.2/T-0-1] HARUS memiliki output audio dan mendeklarasikan android.hardware.audio.output.

2.3.2. Multimedia

Implementasi perangkat televisi HARUS mendukung format encoding audio berikut:

  • [5.1/T-0-1] Profil MPEG-4 AAC (AAC LC)
  • [5.1/T-0-2] MPEG-4 HE AAC Profile (AAC+)
  • [5.1/T-0-3] AAC ELD (AAC yang ditingkatkan dengan delay rendah)

Implementasi perangkat televisi HARUS mendukung format encoding video berikut:

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

Penerapan perangkat televisi:

  • [5.2.2/T-SR] SANGAT DISARANKAN untuk mendukung encoding H.264 video resolusi 720p dan 1080p dengan kecepatan 30 frame per detik.

Implementasi perangkat televisi HARUS mendukung format decoding video berikut:

Penerapan perangkat televisi SANGAT DISARANKAN untuk mendukung format decoding video berikut:

Implementasi perangkat televisi HARUS mendukung decoding H.264, seperti yang dijelaskan di Bagian 5.3.4, pada resolusi dan kecepatan frame video standar hingga dan termasuk:

  • [5.3.4.4/T-1-1] HD 1080p pada 60 frame per detik dengan Profil Dasar Pengukuran
  • [5.3.4.4/T-1-2] HD 1080p pada 60 frame per detik dengan Profil Utama
  • [5.3.4.4/T-1-3] HD 1080p pada 60 frame per detik dengan High Profile Level 4.2

Penerapan perangkat televisi dengan dekoder hardware H.265 HARUS mendukung decoding H.265, seperti yang dijelaskan di Bagian 5.3.5, pada resolusi dan kecepatan frame video standar hingga dan termasuk:

  • [5.3.5.4/T-1-1] HD 1080p pada 60 frame per detik dengan Main Profile Level 4.1

Jika implementasi perangkat Televisi dengan dekoder hardware H.265 mendukung decoding H.265 dan profil decoding UHD, perangkat tersebut:

  • [5.3.5.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 dekode VP8, seperti yang dijelaskan dalam Bagian 5.3.6, pada resolusi dan kecepatan frame video standar hingga dan termasuk:

  • [5.3.6.4/T-1-1] Profil decoding HD 1080p pada 60 frame per detik

Implementasi perangkat televisi dengan dekoder hardware VP9 HARUS mendukung dekode VP9, seperti yang dijelaskan di Bagian 5.3.7, pada kecepatan frame dan resolusi video standar hingga dan termasuk:

  • [5.3.7.4/T-1-1] HD 1080p pada 60 frame per detik dengan profil 0 (kedalaman warna 8 bit)

Jika implementasi perangkat Televisi dengan dekoder hardware VP9 mendukung dekode VP9 dan profil dekode UHD, perangkat tersebut:

  • [5.3.7.5/T-2-1] HARUS mendukung profil decoding UHD pada 60 frame per detik dengan profil 0 (kedalaman warna 8 bit).
  • [5.3.7.5/T-2-1] SANGAT DISARANKAN untuk mendukung profil decoding UHD pada 60 frame per detik dengan profil 2 (kedalaman warna 10 bit).

Penerapan perangkat televisi:

  • [5.5.3/T-0-1] HARUS menyertakan dukungan untuk Volume Master sistem dan atenuasi volume output audio digital pada output yang didukung, kecuali untuk output passthrough audio terkompresi (jika tidak ada dekode audio yang dilakukan di perangkat).
  • [5.8/T-0-1] HARUS menetapkan mode output HDMI untuk memilih resolusi maksimum yang dapat didukung dengan kecepatan refresh 50 Hz atau 60 Hz untuk semua layar berkabel.
  • [5.8/T-SR] SANGAT DISARANKAN untuk menyediakan pemilih kecepatan refresh HDMI yang dapat dikonfigurasi pengguna untuk semua layar berkabel.
  • [5.8/T-SR] SANGAT DIUTAMAKAN untuk mendukung decoding simultan streaming aman. Setidaknya, dekode simultan dari dua aliran SANGAT DIUJAMI.
  • [5.8] HARUS menetapkan kecepatan refresh mode output HDMI ke 50 Hz atau 60 Hz, bergantung pada kecepatan refresh video untuk wilayah tempat perangkat dijual untuk semua layar berkabel.

Jika implementasi perangkat Televisi mendukung decoding UHD dan memiliki dukungan untuk layar eksternal, perangkat tersebut:

  • [5.8/T-1-1] HARUS mendukung HDCP 2.2.

Jika implementasi perangkat Televisi tidak mendukung decoding UHD, tetapi memiliki dukungan untuk layar eksternal, perangkat tersebut:

  • [5.8/T-2-1] HARUS mendukung HDCP 1.4

2.3.3. Software

Penerapan perangkat televisi:

  • [3/T-0-1] HARUS mendeklarasikan fitur android.software.leanback dan android.hardware.type.television.
  • [3.4.1/T-0-1] HARUS menyediakan implementasi lengkap android.webkit.Webview API.

Jika implementasi perangkat Android Television mendukung layar kunci,perangkat tersebut:

  • [3.8.10/T-1-1] HARUS menampilkan Notifikasi layar kunci termasuk Template Notifikasi Media.

Penerapan perangkat televisi:

  • [3.8.14/T-SR] SANGAT DIUJI untuk mendukung multi-aplikasi mode picture-in-picture (PIP).
  • [3.10/T-0-1] HARUS mendukung layanan aksesibilitas pihak ketiga.
  • [3.10/T-SR] SANGAT DISARANKAN untuk memuat layanan aksesibilitas di perangkat secara otomatis yang sebanding dengan atau melebihi fungsi layanan aksesibilitas Tombol Akses dan TalkBack (untuk bahasa yang didukung oleh mesin Text-to-speech yang diinstal sebelumnya) seperti yang disediakan dalam project open source talkback.

Jika implementasi perangkat Televisi melaporkan fitur android.hardware.audio.output, perangkat tersebut:

  • [3.11/T-SR] SANGAT DISARANKAN untuk menyertakan mesin TTS yang mendukung bahasa yang tersedia di perangkat.
  • [3.11/T-1-1] HARUS mendukung penginstalan mesin TTS pihak ketiga.

Penerapan perangkat televisi:

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

2.3.4. Performa dan Daya

  • [8.1/T-0-1] Latensi frame yang konsisten. Latensi frame yang tidak konsisten atau penundaan untuk merender frame TIDAK BOLEH terjadi lebih dari 5 frame per detik, dan HARUS di bawah 1 frame per detik.
  • [8.2/T-0-1] HARUS memastikan performa operasi tulis berurutan minimal 5 MB/dtk.
  • [8.2/T-0-2] HARUS memastikan performa tulis acak minimal 0,5 MB/s.
  • [8.2/T-0-3] HARUS memastikan performa pembacaan berurutan minimal 15 MB/dtk.
  • [8.2/T-0-4] HARUS memastikan performa pembacaan acak minimal 3,5 MB/s.

Jika implementasi perangkat Televisi menyertakan fitur untuk meningkatkan pengelolaan daya perangkat yang disertakan dalam AOSP atau memperluas fitur yang disertakan dalam AOSP, fitur tersebut:

  • [8.3/T-1-1] HARUS memberikan kemampuan kepada pengguna untuk mengaktifkan dan menonaktifkan fitur penghemat baterai.
  • [8.3/T-1-2] HARUS memberikan kemampuan pengguna untuk menampilkan semua aplikasi yang dikecualikan dari mode hemat daya Aplikasi Standby dan Istirahatkan.

Penerapan perangkat televisi:

  • [8.4/T-0-1] HARUS menyediakan profil daya per komponen yang menentukan nilai konsumsi saat ini untuk setiap komponen hardware dan perkiraan pemakaian baterai yang disebabkan oleh komponen dari waktu ke waktu seperti yang didokumentasikan di situs Project Open Source Android.
  • [8.4/T-0-2] HARUS melaporkan semua nilai konsumsi daya dalam miliamper jam (mAh).
  • [8.4/T-0-3] HARUS melaporkan konsumsi daya CPU per setiap UID proses. Project Open Source Android memenuhi persyaratan melalui penerapan modul kernel uid_cputime.
  • [8.4/T] HARUS diatribusikan ke komponen hardware itu sendiri jika tidak dapat mengatribusikan penggunaan daya komponen hardware ke aplikasi.
  • [8.4/T-0-4] HARUS menyediakan penggunaan daya ini melalui perintah shell adb shell dumpsys batterystats kepada developer aplikasi.

2.4. Persyaratan Menonton

Perangkat Android Watch mengacu pada implementasi perangkat Android yang dimaksudkan untuk dikenakan 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 dipakai di tubuh.

Persyaratan tambahan di bagian lain ini khusus untuk implementasi perangkat Android Watch.

2.4.1. Hardware

Tonton implementasi perangkat:

  • [7.1.1.1/W-0-1] HARUS memiliki layar dengan ukuran diagonal fisik dalam rentang 1,1 hingga 2,5 inci.

  • [7.2.3/W-0-1] HARUS memiliki fungsi Home yang tersedia untuk pengguna, dan fungsi Kembali kecuali saat berada di UI_MODE_TYPE_WATCH.

  • [7.2.4/W-0-1] HARUS mendukung input layar sentuh.

  • [7.3.1/W-SR] SANGAT DIUJAMI untuk menyertakan akselerometer 3 sumbu.

  • [7.4.3/W-0-1] HARUS mendukung Bluetooth.

  • [7.6.1/W-0-1] HARUS memiliki penyimpanan non-volatil minimal 1 GB yang tersedia untuk data pribadi aplikasi (alias partisi "/data").

  • [7.6.1/W-0-2] HARUS memiliki minimal 416 MB memori yang tersedia untuk kernel dan ruang pengguna.

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

  • [7.8.2/W] BOLEH, tetapi TIDAK BOLEH memiliki output audio.

2.4.2. Multimedia

Tidak ada persyaratan tambahan.

2.4.3. Software

Tonton implementasi perangkat:

  • [3/W-0-1] HARUS mendeklarasikan fitur android.hardware.type.watch.
  • [3/W-0-2] HARUS mendukung uiMode = UI_MODE_TYPE_WATCH.

Tonton implementasi perangkat:

  • [3.8.4/W-SR] SANGAT DISARANKAN untuk menerapkan asisten di perangkat guna menangani tindakan Bantuan.

Tonton implementasi perangkat yang mendeklarasikan flag fitur android.hardware.audio.output:

  • [3.10/W-1-1] HARUS mendukung layanan aksesibilitas pihak ketiga.
  • [3.10/W-SR] SANGAT DISARANKAN untuk memuat layanan aksesibilitas di perangkat secara otomatis yang sebanding dengan atau melebihi fungsi layanan aksesibilitas Tombol Akses dan TalkBack (untuk bahasa yang didukung oleh mesin Text-to-speech yang diinstal sebelumnya) seperti yang disediakan dalam project open source talkback.

Jika implementasi perangkat Smartwatch melaporkan fitur android.hardware.audio.output, fitur tersebut:

  • [3.11/W-SR] SANGAT DISARANKAN untuk menyertakan mesin TTS yang mendukung bahasa yang tersedia di perangkat.

  • [3.11/W-0-1] HARUS mendukung penginstalan mesin TTS pihak ketiga.

2.4.4. Performa dan Daya

Jika implementasi perangkat Watch menyertakan fitur untuk meningkatkan pengelolaan daya perangkat yang disertakan dalam AOSP atau memperluas fitur yang disertakan dalam AOSP, fitur tersebut:

  • [8.3/W-SR] SANGAT DISARANKAN untuk memberikan kemampuan pengguna untuk menampilkan semua aplikasi yang dikecualikan dari mode hemat daya Aplikasi Standby dan Mode Tidur.
  • [8.3/W-SR] SANGAT DISARANKAN untuk memberikan kemampuan pengguna untuk mengaktifkan dan menonaktifkan fitur penghemat baterai.

Tonton implementasi perangkat:

  • [8.4/W-0-1] HARUS memberikan profil daya per komponen yang menentukan nilai konsumsi saat ini untuk setiap komponen hardware dan perkiraan pemakaian baterai yang disebabkan oleh komponen dari waktu ke waktu seperti yang didokumentasikan di situs Android Open Source Project.
  • [8.4/W-0-2] HARUS melaporkan semua nilai konsumsi daya dalam miliamper jam (mAh).
  • [8.4/W-0-3] HARUS melaporkan konsumsi daya CPU per setiap UID proses. Project Open Source Android memenuhi persyaratan melalui penerapan modul kernel uid_cputime.
  • [8.4/W-0-4] HARUS menyediakan penggunaan daya ini melalui perintah shell adb shell dumpsys batterystats kepada developer aplikasi.
  • [8,4/W] HARUS diatribusikan ke komponen hardware itu sendiri jika tidak dapat mengatribusikan penggunaan daya komponen hardware ke aplikasi.

2.5. Persyaratan Otomotif

Implementasi Android Automotive mengacu pada head unit kendaraan yang menjalankan Android sebagai sistem operasi untuk sebagian atau semua fungsi sistem dan/atau infotainmen.

Implementasi perangkat Android diklasifikasikan sebagai Otomotif jika mendeklarasikan fitur android.hardware.type.automotive atau memenuhi semua kriteria berikut.

  • Disematkan sebagai bagian dari, atau dapat dicolokkan ke, kendaraan otomotif.
  • Menggunakan layar di baris kursi pengemudi sebagai layar utama.

Persyaratan tambahan di bagian lain ini khusus untuk implementasi perangkat Android Automotive.

2.5.1. Hardware

Implementasi perangkat otomotif:

  • [7.1.1.1/A-0-1] HARUS memiliki layar dengan ukuran diagonal fisik minimal 6 inci.

  • [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 menyediakan fungsi Beranda dan DAPAT menyediakan fungsi Kembali dan Terbaru.

  • [7.2.3/A-0-2] HARUS mengirim peristiwa tekan lama dan normal dari fungsi Kembali (KEYCODE_BACK) ke aplikasi latar depan.

  • [7.3.1/A-SR] SANGAT DIUJAMI untuk menyertakan akselerometer 3 sumbu.

Jika implementasi perangkat Otomotif menyertakan akselerometer 3 sumbu, perangkat tersebut:

Jika implementasi perangkat Otomotif menyertakan giroskop, perangkat tersebut:

  • [7.3.4/A-1-1] HARUS dapat melaporkan peristiwa hingga frekuensi minimal 100 Hz.

Implementasi perangkat otomotif:

  • [7.3.11/A-0-1] HARUS memberikan perlengkapan saat ini sebagai SENSOR_TYPE_GEAR.

Implementasi perangkat otomotif:

  • [7.3.11.2/A-0-1] HARUS mendukung mode siang/malam yang ditentukan sebagai SENSOR_TYPE_NIGHT.
  • [7.3.11.2/A-0-2] Nilai tanda SENSOR_TYPE_NIGHT HARUS konsisten dengan mode siang/malam dasbor dan HARUS didasarkan pada input sensor cahaya sekitar.

  • Sensor cahaya sekitar yang mendasarinya MUNGKIN sama dengan Photometer.

  • [7.3.11.4/A-0-1] HARUS memberikan kecepatan kendaraan seperti yang ditentukan oleh SENSOR_TYPE_CAR_SPEED.

  • [7.3.11.5/A-0-1] HARUS memberikan status rem parkir seperti yang ditentukan oleh SENSOR_TYPE_PARKING_BRAKE.

  • [7.4.3/A-0-1] HARUS mendukung Bluetooth dan HARUS mendukung Bluetooth LE.

  • [7.4.3/A-0-2] Implementasi Android Automotive HARUS mendukung profil Bluetooth berikut:
    • Panggilan telepon melalui Profil Handsfree (HFP).
    • Pemutaran media melalui Profil Distribusi Audio (A2DP).
    • Kontrol pemutaran media melalui Remote Control Profile (AVRCP).
    • Berbagi kontak menggunakan Profil Akses Buku Telepon (PBAP).

  • [7.4.3/A-SR] SANGAT DISARANKAN untuk mendukung Profil Akses Pesan (MAP).

  • [7.4.5/A] HARUS menyertakan dukungan untuk konektivitas data berbasis jaringan seluler.

  • [7.4.5/A] DAPAT menggunakan konstanta NetworkCapabilities#NET_CAPABILITY_OEM_PAID System API untuk jaringan yang harus tersedia untuk aplikasi sistem.

  • [7.6.1/A-0-1] HARUS memiliki penyimpanan non-volatil minimal 4 GB yang tersedia untuk data pribadi aplikasi (alias partisi "/data").

Implementasi perangkat otomotif:

  • [7.6.1/A] HARUS memformat partisi data untuk menawarkan performa dan masa pakai yang lebih baik pada penyimpanan flash, misalnya menggunakan sistem file f2fs.

Jika implementasi perangkat Otomotif menyediakan penyimpanan eksternal bersama melalui sebagian penyimpanan internal yang tidak dapat dilepas, perangkat tersebut:

  • [7.6.1/A-SR] SANGAT DIUJAMI untuk mengurangi overhead I/O pada operasi yang dilakukan di penyimpanan eksternal, misalnya dengan menggunakan SDCardFS.

Jika implementasi perangkat Otomotif adalah 32-bit:

  • [7.6.1/A-1-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 512 MB jika salah satu kepadatan berikut digunakan:

    • 280 dpi atau lebih rendah di layar kecil/normal
    • ldpi atau lebih rendah di perangkat layar ekstra besar
    • mdpi atau lebih rendah di perangkat layar besar

  • [7.6.1/A-1-2] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 608 MB jika salah satu kepadatan berikut digunakan:

    • xhdpi atau lebih tinggi di perangkat berlayar kecil/normal
    • hdpi atau lebih tinggi di perangkat layar besar
    • mdpi atau lebih tinggi di perangkat layar ekstra besar

  • [7.6.1/A-1-3] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 896 MB jika salah satu kepadatan berikut digunakan:

    • 400 dpi atau lebih tinggi di layar kecil/normal
    • xhdpi atau yang lebih tinggi di layar besar
    • tvdpi atau yang lebih tinggi di layar ekstra besar

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

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

Jika implementasi perangkat Otomotif adalah 64-bit:

  • [7.6.1/A-2-1] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 816 MB jika salah satu kepadatan berikut digunakan:

    • 280 dpi atau lebih rendah di layar kecil/normal
    • ldpi atau lebih rendah di perangkat layar ekstra besar
    • mdpi atau lebih rendah di perangkat layar besar

  • [7.6.1/A-2-2] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 944 MB jika salah satu kepadatan berikut digunakan:

    • xhdpi atau lebih tinggi di perangkat berlayar kecil/normal
    • hdpi atau lebih tinggi di perangkat layar besar
    • mdpi atau lebih tinggi di perangkat layar ekstra besar

  • [7.6.1/A-2-3] Memori yang tersedia untuk kernel dan ruang pengguna HARUS minimal 1280 MB jika salah satu kepadatan berikut digunakan:

    • 400 dpi atau lebih tinggi di layar kecil/normal
    • xhdpi atau yang lebih tinggi di layar besar
    • tvdpi atau yang lebih tinggi di layar ekstra besar

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

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

Perhatikan bahwa "memori yang tersedia untuk kernel dan ruang pengguna" di atas mengacu pada ruang memori yang disediakan selain memori yang sudah dikhususkan untuk komponen hardware seperti radio, video, dan sebagainya yang tidak berada di bawah kontrol kernel pada implementasi perangkat.

Implementasi perangkat otomotif:

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

Implementasi perangkat otomotif:

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

Implementasi perangkat otomotif:

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

2.5.2. Multimedia

Implementasi perangkat otomotif HARUS mendukung encoding audio berikut:

  • [5.1/A-0-1] Profil AAC MPEG-4 (AAC LC)
  • [5.1/A-0-2] Profil MPEG-4 HE AAC (AAC+)
  • [5.1/A-0-3] AAC ELD (AAC yang ditingkatkan dengan delay rendah)

Implementasi perangkat otomotif HARUS mendukung encoding video berikut:

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

Implementasi perangkat otomotif HARUS mendukung dekode video berikut:

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

Implementasi perangkat otomotif SANGAT DIUJAMI untuk mendukung decoding video berikut:

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

2.5.3. Software

Implementasi perangkat otomotif:

  • [3/A-0-1] HARUS mendeklarasikan fitur android.hardware.type.automotive.

  • [3/A-0-2] HARUS mendukung uiMode = UI_MODE_TYPE_CAR.

  • [3/A-0-3] HARUS mendukung semua API publik di namespace android.car.*.

  • [3.4.1/A-0-1] HARUS menyediakan implementasi lengkap android.webkit.Webview API.

  • [3.8.3/A-0-1] HARUS menampilkan notifikasi yang menggunakan Notification.CarExtender API saat diminta oleh aplikasi pihak ketiga.

  • [3.8.4/A-SR] Sangat Direkomendasikan untuk menerapkan asisten di perangkat guna menangani tindakan Bantuan.

  • [3.13/A-SR] SANGAT DIUJAMI untuk menyertakan komponen UI Setelan Cepat.

Jika penerapan perangkat Otomotif menyertakan tombol tekan untuk bicara, tombol tersebut:

  • [3.8.4/A-1-1] HARUS menggunakan penekanan singkat tombol push-to-talk sebagai interaksi yang ditetapkan untuk meluncurkan aplikasi bantuan yang dipilih pengguna, dengan kata lain aplikasi yang menerapkan VoiceInteractionService.

Implementasi perangkat otomotif:

  • [3.14/A-0-1] HARUS menyertakan framework UI untuk mendukung aplikasi pihak ketiga yang menggunakan media API seperti yang dijelaskan di bagian 3.14.

2.5.4. Performa dan Daya

Jika implementasi perangkat Automotive menyertakan fitur untuk meningkatkan pengelolaan daya perangkat yang disertakan dalam AOSP atau memperluas fitur yang disertakan dalam AOSP, implementasi tersebut:

  • [8.3/A-1-1] HARUS memberikan kemampuan pengguna untuk mengaktifkan dan menonaktifkan fitur penghemat baterai.
  • [8.3/A-1-2] HARUS memberikan kemampuan pengguna untuk menampilkan semua aplikasi yang dikecualikan dari mode hemat daya Aplikasi Standby dan Istirahatkan.

Implementasi perangkat otomotif:

  • [8.2/A-0-1] HARUS melaporkan jumlah byte yang dibaca dan ditulis ke penyimpanan non-volatil per setiap UID proses sehingga statistik tersedia untuk developer melalui System API android.car.storagemonitoring.CarStorageMonitoringManager. Project Open Source Android memenuhi persyaratan melalui modul kernel uid_sys_stats.
  • [8.4/A-0-1] HARUS memberikan profil daya per komponen yang menentukan nilai konsumsi saat ini untuk setiap komponen hardware dan perkiraan pemakaian baterai yang disebabkan oleh komponen dari waktu ke waktu seperti yang didokumentasikan di situs Project Open Source Android.
  • [8.4/A-0-2] HARUS melaporkan semua nilai konsumsi daya dalam miliamper jam (mAh).
  • [8.4/A-0-3] HARUS melaporkan konsumsi daya CPU per setiap UID proses. Project Open Source Android memenuhi persyaratan melalui penerapan modul kernel uid_cputime.
  • [8.4/A] HARUS diatribusikan ke komponen hardware itu sendiri jika tidak dapat mengatribusikan penggunaan daya komponen hardware ke aplikasi.
  • [8.4/A-0-4] HARUS menyediakan penggunaan daya ini melalui perintah shell adb shell dumpsys batterystats kepada developer aplikasi.

2.5.5. Model Keamanan

Jika implementasi perangkat Otomotif mendukung beberapa pengguna, implementasi tersebut:

  • [9.5/A-1-1] HARUS menyertakan akun tamu yang memungkinkan semua fungsi yang disediakan oleh sistem kendaraan tanpa mengharuskan pengguna login.

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

Implementasi perangkat otomotif:

  • [9.14/A-0-1] HARUS melakukan gatekeep pesan dari subsistem kendaraan framework Android, misalnya, mengizinkan jenis pesan dan sumber pesan yang diizinkan.
  • [9.14/A-0-2] HARUS memantau serangan denial of service dari framework Android atau aplikasi pihak ketiga. Hal ini melindungi dari software berbahaya yang membanjiri jaringan kendaraan dengan traffic, yang dapat menyebabkan subsistem kendaraan tidak berfungsi.

2.6. Persyaratan Tablet

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

  • Biasanya digunakan dengan memegangnya di kedua tangan.
  • Tidak memiliki konfigurasi clamshell atau konvertibel.
  • Setiap implementasi keyboard fisik yang digunakan dengan perangkat HARUS terhubung melalui koneksi standar.
  • Memiliki sumber daya yang memberikan mobilitas, seperti baterai.
  • Memiliki ukuran layar diagonal fisik dalam rentang 7 hingga 18 inci.

Implementasi perangkat tablet memiliki persyaratan yang serupa dengan implementasi perangkat genggam. Pengecualian ditunjukkan dengan * di bagian tersebut dan dicatat untuk referensi di bagian ini.

2.4.1. Hardware

Ukuran Layar

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

Memori dan Penyimpanan Minimum (Pasal 7.6.1)

Kepadatan layar yang tercantum untuk layar kecil/normal dalam persyaratan perangkat genggam tidak berlaku untuk tablet.

Mode periferal USB (Bagian 7.7.1)

Jika implementasi perangkat tablet menyertakan port USB yang mendukung mode periferal, port tersebut:

  • [7.7.1/Tab] DAPAT mengimplementasikan Android Open Accessory (AOA) API.

Mode Virtual Reality (Pasal 7.9.1)

Virtual Reality High Performance (Bagian 7.9.2)

Persyaratan virtual reality tidak berlaku untuk tablet.

3. Software

3.1. Kompatibilitas API Terkelola

Lingkungan eksekusi bytecode Dalvik terkelola adalah kendaraan utama untuk aplikasi Android. Application programming interface (API) Android adalah kumpulan antarmuka platform Android yang diekspos ke aplikasi yang berjalan di lingkungan runtime terkelola.

Implementasi perangkat:

  • [C-0-1] HARUS menyediakan implementasi lengkap, termasuk semua perilaku yang didokumentasikan, dari API yang didokumentasikan yang diekspos oleh Android SDK atau API apa pun yang dihiasi dengan penanda “@SystemApi” di kode sumber Android upstream.

  • [C-0-2] HARUS mendukung/mempertahankan semua class, metode, dan elemen terkait yang ditandai dengan anotasi TestApi (@TestApi).

  • [C-0-3] TIDAK BOLEH menghilangkan API terkelola, mengubah antarmuka atau tanda tangan API, menyimpang dari perilaku yang didokumentasikan, atau menyertakan no-ops, kecuali jika diizinkan secara khusus oleh Definisi Kompatibilitas ini.

  • [C-0-4] HARUS tetap mempertahankan API dan berperilaku dengan cara yang wajar, meskipun beberapa fitur hardware yang menyertakan API di Android dihilangkan. Lihat bagian 7 untuk mengetahui persyaratan spesifik untuk skenario ini.

  • [C-0-5] HARUS membatasi penggunaan API tersembunyi oleh aplikasi pihak ketiga, yang ditentukan sebagai API dalam namespace Android yang dihiasi dengan anotasi @hidden, tetapi tidak dengan @SystemAPI atau @TestApi, seperti yang dijelaskan dalam dokumen SDK dan dikirimkan dengan setiap API tersembunyi di daftar yang dibatasi yang sama seperti yang disediakan melalui daftar sementara dan file daftar tolak di jalur prebuilts/runtime/appcompat/ untuk cabang level API yang sesuai di AOSP. Namun, mereka:

    • BOLEH, jika API tersembunyi tidak ada atau diterapkan secara berbeda pada implementasi perangkat, pindahkan API tersembunyi ke daftar tolak atau hapus dari semua daftar yang dibatasi.
    • BOLEH, jika API tersembunyi belum ada di AOSP, tambahkan API tersembunyi ke daftar yang dibatasi.
    • DAPAT menerapkan mekanisme update dinamis yang memindahkan API tersembunyi dari daftar yang dibatasi ke daftar yang tidak terlalu membatasi, kecuali untuk daftar yang diizinkan.

3.1.1. Ekstensi Android

Android menyertakan dukungan untuk memperluas API terkelola sekaligus mempertahankan versi level API yang sama.

  • [C-0-1] Implementasi perangkat Android HARUS memuat sebelumnya implementasi AOSP dari library bersama ExtShared dan layanan ExtServices dengan versi yang lebih tinggi dari atau sama dengan versi minimum yang diizinkan per setiap level API. Misalnya, implementasi perangkat Android 7.0, yang menjalankan API level 24 HARUS menyertakan setidaknya versi 1.

3.1.2. Library Android

Karena penghentian penggunaan klien HTTP Apache, implementasi perangkat:

  • [C-0-1] TIDAK BOLEH menempatkan library org.apache.http.legacy di bootclasspath.
  • [C-0-2] HARUS menambahkan library org.apache.http.legacy ke classpath aplikasi hanya jika aplikasi memenuhi salah satu kondisi berikut:
    • Menargetkan API level 28 atau yang lebih rendah.
    • Mendeklarasikan dalam manifesnya bahwa aplikasi memerlukan library dengan menetapkan atribut android:name dari <uses-library> ke 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 “soft” khusus runtime yang signifikan, dalam bentuk hal-hal seperti intent, izin, dan aspek serupa dari aplikasi Android yang tidak dapat diterapkan pada waktu kompilasi aplikasi.

3.2.1. Izin

  • [C-0-1] Implementer perangkat HARUS mendukung dan menerapkan semua konstanta izin seperti yang didokumentasikan oleh halaman referensi Izin. Perhatikan bahwa bagian 9 mencantumkan persyaratan tambahan yang terkait dengan model keamanan Android.

3.2.2. Parameter Build

Android API menyertakan sejumlah konstanta di class android.os.Build yang dimaksudkan untuk mendeskripsikan perangkat saat ini.

  • [C-0-1] Untuk memberikan nilai yang konsisten dan bermakna di seluruh implementasi perangkat, tabel di bawah menyertakan batasan tambahan pada format nilai ini yang HARUS sesuai dengan implementasi perangkat.
Parameter Detail
VERSION.RELEASE Versi sistem Android yang sedang dieksekusi, dalam format yang dapat dibaca manusia. Kolom ini HARUS memiliki salah satu nilai string yang ditentukan di 9.
VERSION.SDK Versi sistem Android yang sedang dieksekusi, dalam format yang dapat diakses oleh kode aplikasi pihak ketiga. Untuk Android 9, kolom ini HARUS memiliki nilai bilangan bulat 9_INT.
VERSION.SDK_INT Versi sistem Android yang sedang dieksekusi, dalam format yang dapat diakses oleh kode aplikasi pihak ketiga. Untuk Android 9, kolom ini HARUS memiliki nilai bilangan bulat 9_INT.
VERSION.INCREMENTAL Nilai yang dipilih oleh implementator perangkat yang menetapkan build tertentu dari sistem Android yang sedang dieksekusi, dalam format yang dapat dibaca manusia. Nilai ini TIDAK BOLEH digunakan kembali untuk build yang berbeda yang tersedia bagi pengguna akhir. Penggunaan umum kolom ini adalah untuk menunjukkan nomor build atau ID perubahan kontrol sumber yang digunakan untuk membuat build. Tidak ada persyaratan pada format khusus kolom ini, kecuali bahwa kolom ini TIDAK BOLEH null atau string kosong ("").
PAPAN Nilai yang dipilih oleh implementator perangkat yang mengidentifikasi hardware internal tertentu yang digunakan oleh perangkat, dalam format yang dapat dibaca manusia. Kemungkinan penggunaan kolom ini adalah untuk menunjukkan revisi tertentu dari board yang memberi daya pada perangkat. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9_-]+$”.
BRAND Nilai yang mencerminkan nama merek yang terkait dengan perangkat seperti yang diketahui oleh pengguna akhir. HARUS dalam format yang dapat dibaca manusia dan HARUS merepresentasikan produsen perangkat atau merek perusahaan yang digunakan untuk memasarkan perangkat. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9_-]+$”.
SUPPORTED_ABIS Nama set petunjuk (jenis CPU + konvensi ABI) kode native. Lihat bagian 3.3. Kompatibilitas API Native.
SUPPORTED_32_BIT_ABIS Nama set petunjuk (jenis CPU + konvensi ABI) kode native. Lihat bagian 3.3. Kompatibilitas API Native.
SUPPORTED_64_BIT_ABIS Nama set petunjuk kedua (jenis CPU + konvensi ABI) dari kode native. Lihat bagian 3.3. Kompatibilitas API Native.
CPU_ABI Nama set petunjuk (jenis CPU + konvensi ABI) kode native. Lihat bagian 3.3. Kompatibilitas API Native.
CPU_ABI2 Nama set petunjuk kedua (jenis CPU + konvensi ABI) dari kode native. Lihat bagian 3.3. Kompatibilitas API Native.
PERANGKAT Nilai yang dipilih oleh implementator perangkat yang berisi nama pengembangan atau nama kode yang mengidentifikasi konfigurasi fitur hardware dan desain industri perangkat. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9_-]+$”. Nama perangkat ini TIDAK BOLEH berubah selama masa aktif produk.
SIdik jari String yang mengidentifikasi build ini secara unik. Nama harus dapat dibaca oleh manusia. Template ini HARUS mengikuti template ini:

$(BRAND)/$(PRODUCT)/
    $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)

Contoh:

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

Sidik jari TIDAK BOLEH menyertakan karakter spasi kosong. Jika kolom lain yang disertakan dalam template di atas memiliki karakter spasi kosong, kolom tersebut HARUS diganti dalam sidik jari build dengan karakter lain, seperti karakter garis bawah ("_"). Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit.

PERANGKAT KERAS Nama hardware (dari command line kernel atau /proc). Nama harus dapat dibaca oleh manusia. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9_-]+$”.
PENYELENGGARA String yang mengidentifikasi host tempat build dibuat secara unik, dalam format yang dapat dibaca manusia. Tidak ada persyaratan pada format khusus kolom ini, kecuali bahwa kolom ini TIDAK BOLEH null atau string kosong ("").
ID ID yang dipilih oleh pengimplementasi perangkat untuk merujuk ke rilis tertentu, dalam format yang dapat dibaca manusia. Kolom ini dapat sama dengan android.os.Build.VERSION.INCREMENTAL, tetapi HARUS berupa nilai yang cukup bermakna bagi pengguna akhir untuk membedakan build software. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9._-]+$”.
PRODUSEN Nama dagang Produsen Peralatan Asli (OEM) produk. Tidak ada persyaratan pada format spesifik kolom ini, kecuali bahwa kolom ini TIDAK BOLEH null atau string kosong (""). Kolom ini TIDAK BOLEH berubah selama masa aktif produk.
MODEL Nilai yang dipilih oleh implementator perangkat yang berisi nama perangkat seperti yang diketahui oleh pengguna akhir. Nama ini HARUS sama dengan nama yang digunakan untuk memasarkan dan menjual perangkat kepada pengguna akhir. Tidak ada persyaratan pada format spesifik kolom ini, kecuali bahwa kolom ini TIDAK BOLEH null atau string kosong (""). Kolom ini TIDAK BOLEH berubah selama masa aktif produk.
PRODUK Nilai yang dipilih oleh implementer perangkat yang berisi nama pengembangan atau nama kode produk tertentu (SKU) yang HARUS unik dalam merek yang sama. HARUS dapat dibaca manusia, tetapi tidak harus ditujukan untuk dilihat oleh pengguna akhir. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9_-]+$”. Nama produk ini TIDAK BOLEH berubah selama masa aktif produk.
SERIAL HARUS menampilkan "UNKNOWN".
TAG Daftar tag yang dipisahkan koma yang dipilih oleh implementator perangkat yang lebih lanjut membedakan build. Kolom ini HARUS memiliki salah satu nilai yang sesuai dengan tiga konfigurasi penandatanganan platform Android standar: kunci rilis, kunci developer, kunci pengujian.
WAKTU Nilai yang mewakili stempel waktu saat build terjadi.
TYPE Nilai yang dipilih oleh implementator perangkat yang menentukan konfigurasi runtime build. Kolom ini HARUS memiliki salah satu nilai yang sesuai dengan tiga konfigurasi runtime Android standar: user, userdebug, atau eng.
PENGGUNA Nama atau ID pengguna (atau pengguna otomatis) yang membuat build. Tidak ada persyaratan pada format khusus kolom ini, kecuali bahwa kolom ini TIDAK BOLEH null atau string kosong ("").
SECURITY_PATCH Nilai yang menunjukkan tingkat patch keamanan build. Hal ini HARUS menunjukkan bahwa build tidak rentan terhadap masalah apa pun yang dijelaskan melalui Android Public Security Bulletin yang ditetapkan. Formatnya HARUS [YYYY-MM-DD], yang cocok dengan string yang ditentukan dan didokumentasikan dalam Android Public Security Bulletin atau dalam Android Security Advisory, misalnya "2015-11-01".
BASE_OS Nilai yang mewakili parameter FINGERPRINT dari build yang identik dengan build ini kecuali untuk patch yang disediakan di Android Public Security Bulletin. Nilai ini HARUS melaporkan nilai yang benar dan jika build tersebut tidak ada, laporkan string kosong ("").
BOOTLOADER Nilai yang dipilih oleh implementator perangkat yang mengidentifikasi versi bootloader internal tertentu yang digunakan di perangkat, dalam format yang dapat dibaca manusia. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9._-]+$”.
getRadioVersion() HARUS (berupa atau menampilkan) nilai yang dipilih oleh implementator perangkat yang mengidentifikasi versi radio/modem internal tertentu yang digunakan di perangkat, dalam format yang dapat dibaca manusia. Jika tidak memiliki radio/modem internal, perangkat HARUS menampilkan NULL. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9._-,]+$”.
getSerial() HARUS (berupa atau menampilkan) nomor seri hardware, yang HARUS tersedia dan unik di seluruh perangkat dengan MODEL dan PRODUSEN yang sama. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9._-,]+$”.

3.2.3. Kompatibilitas Intent

3.2.3.1. Intent Aplikasi Inti

Intent Android memungkinkan komponen aplikasi meminta fungsi dari komponen Android lainnya. Project upstream Android menyertakan daftar aplikasi yang dianggap sebagai aplikasi Android inti, yang menerapkan beberapa pola intent untuk melakukan tindakan umum.

  • [C-0-1] Implementasi perangkat HARUS memuat ulang satu atau beberapa aplikasi atau komponen layanan dengan pengendali intent, untuk semua pola filter intent publik yang ditentukan oleh aplikasi Android inti berikut di AOSP:

    • Jam Meja
    • Browser
    • Kalender
    • Kontak
    • Galeri
    • GlobalSearch
    • Peluncur
    • Musik
    • Setelan
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 untuk Setelan, agar dapat diganti oleh aplikasi pihak ketiga. Implementasi open source Android upstream mengizinkan hal ini secara default.

  • [C-0-2] Implementer Dvice TIDAK BOLEH melampirkan hak istimewa khusus ke penggunaan pola intent ini oleh aplikasi sistem, atau mencegah aplikasi pihak ketiga untuk mengikat dan mengambil alih kontrol atas pola ini. Larangan ini secara khusus mencakup, tetapi tidak terbatas pada, menonaktifkan antarmuka pengguna “Chooser” yang memungkinkan pengguna memilih antara beberapa aplikasi yang semuanya menangani pola intent yang sama.

  • [C-0-3] Implementasi perangkat HARUS menyediakan antarmuka pengguna bagi pengguna untuk mengubah aktivitas default untuk intent.

  • Namun, implementasi perangkat DAPAT menyediakan aktivitas default untuk pola URI tertentu (misalnya, http://play.google.com) jika aktivitas default menyediakan atribut yang lebih spesifik untuk URI data. Misalnya, pola filter intent yang menentukan URI data “http://www.android.com” lebih spesifik daripada pola intent inti browser untuk “http://”.

Android juga menyertakan mekanisme bagi aplikasi pihak ketiga untuk mendeklarasikan perilaku penautan aplikasi default yang kredibel untuk jenis intent URI web tertentu. Jika deklarasi resmi tersebut ditentukan dalam pola filter intent aplikasi, implementasi perangkat:

  • [C-0-4] HARUS mencoba memvalidasi filter intent apa pun dengan melakukan langkah-langkah validasi yang ditentukan dalam spesifikasi Digital Asset Links seperti yang diterapkan oleh Pengelola Paket di Project Open Source Android upstream.
  • [C-0-5] HARUS mencoba validasi filter intent selama penginstalan aplikasi dan menetapkan semua filter intent URI yang berhasil divalidasi sebagai pengendali aplikasi default untuk URI-nya.
  • DAPAT menetapkan filter intent URI tertentu sebagai pengendali aplikasi default untuk URI-nya, jika filter tersebut berhasil diverifikasi, tetapi filter URI kandidat lainnya gagal dalam verifikasi. Jika implementasi perangkat melakukan hal ini, implementasi tersebut HARUS memberikan penggantian pola per URI yang sesuai kepada pengguna di menu setelan.
  • HARUS memberikan kontrol Link Aplikasi per aplikasi kepada pengguna di Setelan sebagai berikut:
    • [C-0-6] Pengguna HARUS dapat mengganti perilaku link aplikasi default secara menyeluruh agar aplikasi: selalu terbuka, selalu bertanya, atau tidak pernah terbuka, yang harus berlaku untuk semua filter intent URI kandidat secara setara.
    • [C-0-7] Pengguna HARUS dapat melihat daftar filter intent URI kandidat.
    • Implementasi perangkat DAPAT memberi pengguna kemampuan untuk mengganti filter intent URI kandidat tertentu yang berhasil diverifikasi, berdasarkan filter per intent.
    • [C-0-8] Implementasi perangkat HARUS memberi pengguna kemampuan untuk melihat dan mengganti filter intent URI kandidat tertentu jika implementasi perangkat memungkinkan beberapa filter intent URI kandidat berhasil diverifikasi, sementara beberapa filter lainnya dapat gagal.
3.2.3.3. Namespace Intent
  • [C-0-1] Implementasi perangkat TIDAK BOLEH menyertakan komponen Android apa pun yang mematuhi pola intent baru atau intent siaran menggunakan ACTION, CATEGORY, atau string kunci lainnya di namespace android. atau com.android..
  • [C-0-2] Implementer perangkat TIDAK BOLEH menyertakan komponen Android apa pun yang mematuhi pola intent baru atau intent siaran menggunakan ACTION, CATEGORY, atau string kunci lainnya di ruang paket milik organisasi lain.
  • [C-0-3] Implementer perangkat TIDAK BOLEH mengubah atau memperluas pola intent apa pun yang digunakan oleh aplikasi inti yang tercantum di bagian 3.2.3.1.
  • Implementasi perangkat DAPAT menyertakan pola intent menggunakan namespace yang jelas dan jelas terkait dengan organisasinya sendiri. Larangan ini analog dengan yang ditentukan untuk class bahasa Java di bagian 3.6.
3.2.3.4. Intent Siaran

Aplikasi pihak ketiga mengandalkan platform untuk menyiarkan intent tertentu guna memberi tahu mereka tentang perubahan di lingkungan hardware atau software.

Implementasi perangkat:

  • [C-0-1] HARUS menyiarkan intent siaran publik sebagai respons terhadap peristiwa sistem yang sesuai seperti yang dijelaskan dalam dokumentasi SDK. Perhatikan bahwa persyaratan ini tidak bertentangan dengan bagian 3.5 karena batasan untuk aplikasi latar belakang juga dijelaskan dalam dokumentasi SDK.
3.2.3.5. Setelan Aplikasi Default

Android menyertakan setelan yang memberikan cara mudah kepada pengguna untuk memilih aplikasi default mereka, misalnya untuk Layar utama atau SMS.

Jika memungkinkan, implementasi perangkat HARUS menyediakan menu setelan yang serupa dan kompatibel dengan pola filter intent dan metode API yang dijelaskan dalam dokumentasi SDK seperti di bawah.

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

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

  • [C-2-1] HARUS menyediakan menu setelan yang akan memanggil intent android.provider.Telephony.ACTION_CHANGE_DEFAULT untuk menampilkan dialog guna mengubah aplikasi SMS default.

  • [C-2-2] HARUS mematuhi intent android.telecom.action.CHANGE_DEFAULT_DIALER untuk menampilkan dialog guna memungkinkan pengguna mengubah aplikasi Telepon default.

    • HARUS menggunakan UI aplikasi Telepon default yang dipilih pengguna untuk panggilan masuk dan keluar, kecuali untuk panggilan darurat, yang akan menggunakan aplikasi Telepon bawaan.

  • [C-2-3] HARUS mematuhi intent android.telecom.action.CHANGE_PHONE_ACCOUNTS untuk memberikan kemampuan pengguna guna mengonfigurasi ConnectionServices yang terkait dengan PhoneAccounts, serta PhoneAccount default yang akan digunakan penyedia layanan telekomunikasi untuk melakukan panggilan keluar. Penerapan AOSP memenuhi persyaratan ini dengan menyertakan menu "Opsi Akun Panggilan" dalam menu setelan "Panggilan".

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

Jika implementasi perangkat mendukung VoiceInteractionService dan memiliki lebih dari satu aplikasi yang menggunakan API ini yang diinstal sekaligus, implementasi tersebut:

3.2.4. Aktivitas di layar sekunder

Jika implementasi perangkat memungkinkan peluncuran Aktivitas Android normal di layar sekunder, implementasi tersebut:

  • [C-1-1] HARUS menetapkan flag fitur android.software.activities_on_secondary_displays.
  • [C-1-2] HARUS menjamin kompatibilitas API yang mirip dengan aktivitas yang berjalan di layar utama.
  • [C-1-3] HARUS menampilkan aktivitas baru di layar yang sama dengan aktivitas yang meluncurkannya, saat aktivitas baru diluncurkan tanpa menentukan layar target melalui ActivityOptions.setLaunchDisplayId() API.
  • [C-1-4] HARUS menghancurkan semua aktivitas, saat tampilan dengan tanda Display.FLAG_PRIVATE dihapus.
  • [C-1-5] HARUS mengubah ukuran semua aktivitas di VirtualDisplay jika ukuran layar itu sendiri diubah.
  • DAPAT menampilkan IME (editor metode input, kontrol pengguna yang memungkinkan pengguna memasukkan teks) di layar utama, saat kolom input teks menjadi fokus di layar sekunder.
  • HARUS menerapkan fokus input pada layar sekunder secara terpisah dari layar utama, jika input sentuh atau tombol didukung.
  • HARUS memiliki android.content.res.Configuration yang sesuai dengan layar tersebut agar dapat ditampilkan, beroperasi dengan benar, dan mempertahankan kompatibilitas jika aktivitas diluncurkan di layar sekunder.

Jika implementasi perangkat memungkinkan peluncuran Aktivitas Android normal di layar sekunder dan layar utama dan sekunder memiliki android.util.DisplayMetrics yang berbeda:

  • [C-2-1] Aktivitas yang tidak dapat diubah ukurannya (yang memiliki resizeableActivity=false di AndroidManifest.xml) dan aplikasi yang menargetkan API level 23 atau yang lebih rendah TIDAK BOLEH diizinkan di layar sekunder.

Jika implementasi perangkat memungkinkan peluncuran Aktivitas Android normal di layar sekunder dan layar sekunder memiliki tanda android.view.Display.FLAG_PRIVATE:

  • [C-3-1] Hanya pemilik layar, sistem, dan aktivitas yang sudah ada di layar tersebut yang HARUS dapat meluncurkannya. Semua orang dapat meluncurkan ke layar yang memiliki tanda android.view.Display.FLAG_PUBLIC.

3.3. Kompatibilitas API Native

Kompatibilitas kode native sangat sulit. Oleh karena itu, pengimplementasi perangkat adalah:

  • [SR] SANGAT DISARANKAN untuk menggunakan implementasi library yang tercantum di bawah dari Project Open Source Android upstream.

3.3.1. Antarmuka Biner Aplikasi

Bytecode Dalvik terkelola dapat memanggil kode native yang disediakan dalam file .apk aplikasi sebagai file .so ELF yang dikompilasi untuk arsitektur hardware perangkat yang sesuai. Karena kode native sangat bergantung pada teknologi prosesor yang mendasarinya, Android menentukan sejumlah Antarmuka Biner Aplikasi (ABI) di Android NDK.

Implementasi perangkat:

  • [C-0-1] HARUS kompatibel dengan satu atau beberapa ABI yang ditentukan dan menerapkan kompatibilitas dengan Android NDK.
  • [C-0-2] HARUS menyertakan dukungan untuk kode yang berjalan di lingkungan terkelola untuk memanggil kode native, menggunakan semantik Java Native Interface (JNI) standar.
  • [C-0-3] HARUS kompatibel dengan sumber (yaitu kompatibel dengan header) dan kompatibel dengan biner (untuk ABI) dengan setiap library yang diperlukan dalam daftar di bawah.
  • [C-0-5] HARUS melaporkan Application Binary Interface (ABI) native yang didukung oleh perangkat secara akurat, melalui parameter android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS, dan android.os.Build.SUPPORTED_64_BIT_ABIS, masing-masing adalah daftar ABI yang dipisahkan koma yang diurutkan dari yang paling banyak ke yang paling sedikit disukai.

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

    • armeabi
    • armeabi-v7a
    • arm64-v8a
    • x86
    • x86-64

    • [C-0-7] HARUS menyediakan semua library berikut, yang menyediakan API native, untuk aplikasi yang menyertakan kode native:

    • libaaudio.so (dukungan audio native AAudio)

    • libandroid.so (dukungan aktivitas Android native)
    • libc (library C)
    • libcamera2ndk.so
    • libdl (dynamic linker)
    • libEGL.so (pengelolaan platform OpenGL native)
    • libGLESv1_CM.so (OpenGL ES 1.x)
    • libGLESv2.so (OpenGL ES 2.0)
    • libGLESv3.so (OpenGL ES 3.x)
    • libicui18n.so
    • libicuuc.so
    • libjnigraphics.so
    • liblog (logging Android)
    • libmediandk.so (dukungan API media native)
    • libm (library matematika)
    • libneuralnetworks.so (Neural Networks API)
    • libOpenMAXAL.so (dukungan OpenMAX AL 1.0.1)
    • libOpenSLES.so (dukungan audio OpenSL ES 1.0.1)
    • libRS.so
    • libstdc++ (Dukungan minimal untuk C++)
    • libvulkan.so (Vulkan)
    • libz (Kompresi Zlib)
    • Antarmuka JNI

  • [C-0-8] TIDAK BOLEH menambahkan atau menghapus fungsi publik untuk library native yang tercantum di atas.

  • [C-0-9] HARUS mencantumkan library non-AOSP tambahan yang diekspos langsung ke aplikasi pihak ketiga di /vendor/etc/public.libraries.txt.
  • [C-0-10] TIDAK BOLEH mengekspos library native lainnya, yang diimplementasikan dan disediakan di AOSP sebagai library sistem, ke aplikasi pihak ketiga yang menargetkan API level 24 atau yang lebih tinggi karena direservasi.
  • [C-0-11] HARUS mengekspor semua simbol fungsi OpenGL ES 3.1 dan Android Extension Pack, seperti yang ditentukan dalam NDK, melalui library libGLESv3.so. Perhatikan bahwa meskipun semua simbol HARUS ada, bagian 7.1.4.1 menjelaskan secara lebih mendetail persyaratan untuk waktu penerapan penuh setiap fungsi yang sesuai.
  • [C-0-12] HARUS mengekspor simbol fungsi untuk simbol fungsi inti Vulkan 1.0, serta ekstensi VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1, dan VK_KHR_get_physical_device_properties2 melalui library libvulkan.so. Perhatikan bahwa meskipun semua simbol HARUS ada, bagian 7.1.4.2 menjelaskan secara lebih mendetail persyaratan untuk waktu penerapan penuh setiap fungsi yang sesuai.
  • HARUS dibuat menggunakan kode sumber dan file header yang tersedia di Project Open Source Android upstream

Perhatikan bahwa rilis Android mendatang dapat memperkenalkan dukungan untuk ABI tambahan.

3.3.2. Kompatibilitas Kode Native ARM 32-bit

Jika implementasi perangkat melaporkan dukungan ABI armeabi, implementasi tersebut:

  • [C-3-1] JUGA HARUS mendukung armeabi-v7a dan melaporkan dukungannya, karena armeabi hanya untuk kompatibilitas mundur dengan aplikasi lama.

Jika implementasi perangkat melaporkan dukungan ABI armeabi-v7a, untuk aplikasi yang menggunakan ABI ini, aplikasi tersebut:

  • [C-2-1] HARUS menyertakan baris berikut di /proc/cpuinfo, dan TIDAK BOLEH mengubah nilai di perangkat yang sama, meskipun dibaca oleh ABI lain.

    • Features:, diikuti dengan daftar fitur CPU ARMv7 opsional yang didukung oleh perangkat.
    • CPU architecture:, diikuti dengan bilangan bulat yang menjelaskan arsitektur ARM tertinggi yang didukung perangkat (misalnya, "8" untuk perangkat ARMv8).

  • [C-2-2] HARUS selalu menyediakan operasi berikut, bahkan jika ABI diterapkan pada arsitektur ARMv8, baik melalui dukungan CPU native maupun melalui emulasi software:

    • Instruksi SWP dan SWPB.
    • Petunjuk SETEND.
    • Operasi batasan CP15ISB, CP15DSB, dan CP15DMB.

  • [C-2-3] HARUS menyertakan dukungan untuk ekstensi Advanced SIMD (alias NEON).

3.4. Kompatibilitas Web

3.4.1. Kompatibilitas WebView

Jika implementasi perangkat menyediakan implementasi lengkap android.webkit.Webview API, implementasi tersebut:

  • [C-1-1] HARUS melaporkan android.software.webview.
  • [C-1-2] HARUS menggunakan build Project Chromium dari Project Open Source Android upstream di cabang Android 9 untuk implementasi android.webkit.WebView 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, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

    • Nilai string $(VERSION) HARUS sama dengan nilai untuk android.os.Build.VERSION.RELEASE.
    • String $(MODEL) BOLEH kosong, tetapi jika tidak kosong, string tersebut HARUS memiliki nilai yang sama dengan android.os.Build.MODEL.
    • "Build/$(BUILD)" DAPAT dihilangkan, tetapi jika ada, string $(BUILD) HARUS sama dengan nilai untuk android.os.Build.ID.
    • Nilai string $(CHROMIUM_VER) HARUS berupa versi Chromium di Project Open Source Android upstream.
    • Implementasi perangkat DAPAT menghilangkan Seluler dalam string agen pengguna.

  • Komponen WebView HARUS menyertakan dukungan untuk sebanyak mungkin fitur HTML5 dan jika mendukung fitur tersebut, HARUS sesuai dengan spesifikasi HTML5.

3.4.2. Kompatibilitas Browser

Jika implementasi perangkat menyertakan aplikasi Browser mandiri untuk penjelajahan web umum, aplikasi tersebut:

  • [C-1-1] HARUS mendukung setiap API berikut yang terkait dengan HTML5:
  • [C-1-2] HARUS mendukung webstorage API HTML5/W3C dan HARUS mendukung IndexedDB API HTML5/W3C. Perhatikan bahwa karena badan standar pengembangan web bertransisi untuk lebih menyukai IndexedDB daripada webstorage, IndexedDB diharapkan menjadi komponen yang diperlukan dalam versi Android mendatang.
  • DAPAT mengirimkan string agen pengguna kustom di aplikasi Browser mandiri.
  • HARUS menerapkan dukungan untuk HTML5 sebanyak mungkin di aplikasi Browser mandiri (baik berdasarkan aplikasi Browser WebKit upstream atau pengganti pihak ketiga).

Namun, jika implementasi perangkat tidak menyertakan aplikasi Browser mandiri, implementasi tersebut:

  • [C-2-1] HARUS tetap mendukung pola intent publik seperti yang dijelaskan di bagian 3.2.3.1.

3.5. Kompatibilitas Perilaku API

Implementasi perangkat:

  • [C-0-9] HARUS memastikan bahwa kompatibilitas perilaku API diterapkan untuk semua aplikasi yang diinstal, kecuali jika dibatasi seperti yang dijelaskan dalam Bagian 3.5.1.
  • [C-0-10] TIDAK BOLEH menerapkan pendekatan daftar yang diizinkan yang memastikan kompatibilitas perilaku API hanya untuk aplikasi yang dipilih oleh pengimplementasi perangkat.

Perilaku setiap jenis API (terkelola, soft, native, dan web) harus konsisten dengan penerapan Project Open Source Android upstream yang diinginkan. Beberapa area kompatibilitas tertentu adalah:

  • [C-0-1] Perangkat TIDAK BOLEH mengubah perilaku atau semantik intent standar.
  • [C-0-2] Perangkat TIDAK BOLEH mengubah siklus proses atau semantik siklus proses dari jenis komponen sistem tertentu (seperti Layanan, Aktivitas, ContentProvider, dll.).
  • [C-0-3] Perangkat TIDAK BOLEH mengubah semantik izin standar.
  • Perangkat TIDAK BOLEH mengubah batasan yang diterapkan pada aplikasi latar belakang. Lebih khusus lagi, untuk aplikasi latar belakang:
    • [C-0-4] Aplikasi HARUS berhenti menjalankan callback yang terdaftar oleh aplikasi untuk menerima output dari GnssMeasurement dan GnssNavigationMessage.
    • [C-0-5] API tersebut HARUS membatasi frekuensi update yang diberikan ke aplikasi melalui class API LocationManager atau metode WifiManager.startScan().
    • [C-0-6] jika aplikasi menargetkan API level 25 atau yang lebih tinggi, aplikasi TIDAK BOLEH mengizinkan pendaftaran penerima siaran untuk siaran implisit intent Android standar dalam manifes aplikasi, kecuali jika intent siaran memerlukan izin "signature" atau "signatureOrSystem" protectionLevel atau berada dalam daftar pengecualian.
    • [C-0-7] jika aplikasi menargetkan API level 25 atau yang lebih tinggi, aplikasi HARUS menghentikan layanan latar belakang aplikasi, sama seperti jika aplikasi telah memanggil metode stopSelf() layanan, kecuali jika aplikasi ditempatkan di daftar yang diizinkan sementara untuk menangani tugas yang terlihat oleh pengguna.
    • [C-0-8] jika aplikasi menargetkan API level 25 atau yang lebih tinggi, aplikasi HARUS melepaskan wakelock yang dimilikinya.
  • [C-0-9] Perangkat HARUS menampilkan penyedia keamanan berikut sebagai tujuh nilai array pertama dari metode Security.getProviders(), dalam urutan yang diberikan dan dengan nama yang diberikan (seperti yang ditampilkan 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.
    1. AndroidNSSP - android.security.net.config.NetworkSecurityConfigProvider
    2. AndroidOpenSSL - com.android.org.conscrypt.OpenSSLProvider
    3. CertPathProvider - sun.security.provider.CertPathProvider
    4. AndroidKeyStoreBCWorkaround - android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
    5. BC - 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. Compatibility Test Suite (CTS) menguji sebagian besar platform untuk kompatibilitas perilaku, tetapi tidak semuanya. Implementer bertanggung jawab untuk memastikan kompatibilitas perilaku dengan Project Open Source Android. Oleh karena itu, jika memungkinkan, implementator perangkat HARUS menggunakan kode sumber yang tersedia melalui Project Open Source Android, bukan menerapkan ulang bagian penting sistem.

3.5.1. Pembatasan Latar Belakang

Jika implementasi perangkat menerapkan batasan aplikasi yang disertakan dalam AOSP atau memperluas batasan aplikasi, implementasi tersebut:

  • [C-SR] SANGAT DISARANKAN untuk memberikan kemampuan pengguna agar pengguna dapat melihat daftar aplikasi yang dibatasi.
  • [C-1-2] HARUS memberikan kemampuan pengguna untuk mengaktifkan / menonaktifkan batasan di setiap aplikasi.
  • [C-1-3] TIDAK BOLEH menerapkan batasan secara otomatis tanpa bukti perilaku kondisi sistem yang buruk, tetapi DAPAT menerapkan batasan pada aplikasi setelah mendeteksi perilaku kondisi sistem yang buruk seperti wakelock yang macet, layanan yang berjalan lama, dan kriteria lainnya. Kriteria DAPAT ditentukan oleh pengimplementasi perangkat, tetapi HARUS terkait dengan dampak aplikasi terhadap kesehatan sistem. Kriteria lain yang tidak sepenuhnya terkait dengan kesehatan sistem, seperti kurangnya popularitas aplikasi di pasar, TIDAK BOLEH digunakan sebagai kriteria.
  • [C-1-4] TIDAK BOLEH otomatis menerapkan pembatasan aplikasi untuk aplikasi saat pengguna telah menonaktifkan pembatasan aplikasi secara manual, dan DAPAT menyarankan pengguna untuk menerapkan pembatasan aplikasi.
  • [C-1-5] HARUS memberi tahu pengguna jika pembatasan aplikasi diterapkan ke aplikasi secara otomatis.
  • [C-1-6] HARUS menampilkan true untuk ActivityManager.isBackgroundRestricted() saat aplikasi yang dibatasi memanggil API ini.
  • [C-1-7] TIDAK BOLEH membatasi aplikasi latar depan teratas yang digunakan secara eksplisit oleh pengguna.
  • [C-1-8] HARUS menangguhkan pembatasan pada aplikasi yang menjadi aplikasi latar depan teratas saat pengguna secara eksplisit mulai menggunakan aplikasi yang sebelumnya dibatasi.

3.6. Namespace API

Android mengikuti konvensi namespace paket dan class yang ditentukan oleh bahasa pemrograman Java. Untuk memastikan kompatibilitas dengan aplikasi pihak ketiga, pengimplementasi perangkat TIDAK BOLEH melakukan modifikasi yang dilarang (lihat di bawah) pada namespace paket ini:

  • java.*
  • javax.*
  • sun.*
  • android.*
  • androidx.*
  • com.android.*

Artinya, mereka:

  • [C-0-1] TIDAK BOLEH mengubah API yang diekspos secara publik di platform Android dengan mengubah tanda tangan metode atau class, atau dengan menghapus class atau kolom class.
  • [C-0-2] TIDAK BOLEH menambahkan elemen apa pun yang ditampilkan secara publik (seperti class atau antarmuka, atau kolom atau metode ke class atau antarmuka yang ada) atau API Pengujian atau Sistem ke API di namespace di atas. “Elemen yang ditampilkan secara publik” adalah konstruksi apa pun yang tidak dihiasi dengan penanda “@hide” seperti yang digunakan dalam kode sumber Android upstream.

Implementer perangkat DAPAT mengubah penerapan API yang mendasarinya, tetapi perubahan tersebut:

  • [C-0-3] TIDAK BOLEH memengaruhi perilaku yang dinyatakan dan tanda tangan bahasa Java dari API apa pun yang ditampilkan secara publik.
  • [C-0-4] TIDAK BOLEH diiklankan atau diekspos kepada developer.

Namun, implementator perangkat DAPAT menambahkan API kustom di luar namespace Android standar, tetapi API kustom tersebut:

  • [C-0-5] TIDAK BOLEH berada dalam namespace yang dimiliki oleh atau merujuk ke organisasi lain. Misalnya, pengimplementasi perangkat TIDAK BOLEH menambahkan API ke com.google.* atau namespace serupa: hanya Google yang dapat melakukannya. Demikian pula, Google TIDAK BOLEH menambahkan API ke namespace perusahaan lain.
  • [C-0-6] HARUS dikemas dalam library bersama Android sehingga hanya aplikasi yang menggunakannya secara eksplisit (melalui mekanisme <uses-library>) yang terpengaruh oleh peningkatan penggunaan memori API tersebut.

Jika pengimplementasi perangkat mengusulkan untuk meningkatkan salah satu namespace paket di atas (seperti dengan menambahkan fungsi baru yang berguna ke API yang ada, atau menambahkan API baru), pengimplementasi HARUS mengunjungi source.android.com dan memulai proses untuk berkontribusi pada perubahan dan kode, sesuai dengan informasi di situs tersebut.

Perhatikan bahwa batasan di atas sesuai dengan konvensi standar untuk penamaan API dalam bahasa pemrograman Java; bagian ini hanya bertujuan untuk memperkuat konvensi tersebut dan membuatnya mengikat melalui penyertaan dalam Definisi Kompatibilitas ini.

3.7. Kompatibilitas Runtime

Implementasi perangkat:

  • [C-0-1] HARUS mendukung format Dalvik Executable (DEX) lengkap dan spesifikasi dan semantik bytecode Dalvik.

  • [C-0-2] HARUS mengonfigurasi runtime Dalvik untuk mengalokasikan memori sesuai dengan platform Android upstream, dan seperti yang ditentukan oleh tabel berikut. (Lihat bagian 7.1.1 untuk mengetahui definisi ukuran layar dan kepadatan layar.)

  • HARUS menggunakan Android RunTime (ART), implementasi upstream referensi Format Dalvik Executable, dan sistem pengelolaan paket implementasi referensi.

  • HARUS menjalankan pengujian fuzz dalam berbagai mode eksekusi dan arsitektur target untuk memastikan stabilitas runtime. Lihat JFuzz dan DexFuzz di situs Project Open Source Android.

Perhatikan bahwa nilai memori yang ditentukan di bawah dianggap sebagai nilai minimum dan implementasi perangkat DAPAT mengalokasikan lebih banyak memori per aplikasi.

Tata Letak Layar Kepadatan Layar Memori Aplikasi Minimum
Android Watch 120 dpi (ldpi) 32MB
160 dpi (mdpi)
213 dpi (tvdpi)
240 dpi (hdpi) 36MB
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
160 dpi (mdpi)
213 dpi (tvdpi) 48MB
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
besar 120 dpi (ldpi) 32MB
160 dpi (mdpi) 48MB
213 dpi (tvdpi) 80MB
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
160 dpi (mdpi) 80MB
213 dpi (tvdpi) 96MB
240 dpi (hdpi)
280 dpi (280dpi) 144MB
320 dpi (xhdpi) 192MB
360 dpi (360dpi) 240MB
400 dpi (400dpi) 288MB
420 dpi (420dpi) 336MB
480 dpi (xxhdpi) 384MB
560 dpi (560dpi) 576MB
640 dpi (xxxhdpi) 768MB

3.8. Kompatibilitas Antarmuka Pengguna

3.8.1. Peluncur (Layar Utama)

Android menyertakan aplikasi peluncur (layar utama) dan dukungan untuk aplikasi pihak ketiga guna menggantikan peluncur perangkat (layar utama).

Jika implementasi perangkat mengizinkan aplikasi pihak ketiga untuk mengganti layar utama perangkat, aplikasi tersebut:

  • [C-1-1] HARUS mendeklarasikan fitur platform android.software.home_screen.
  • [C-1-2] HARUS menampilkan objek AdaptiveIconDrawable saat aplikasi pihak ketiga menggunakan tag <adaptive-icon> untuk menyediakan ikonnya, dan metode PackageManager untuk mengambil ikon dipanggil.

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

Sebaliknya, jika penerapan perangkat tidak mendukung penyematan pintasan dalam aplikasi, perangkat tersebut:

Jika implementasi perangkat menerapkan peluncur default yang memberikan akses cepat ke pintasan tambahan yang disediakan oleh aplikasi pihak ketiga melalui API ShortcutManager, implementasi tersebut:

  • [C-4-1] HARUS mendukung semua fitur pintasan yang didokumentasikan (misalnya, pintasan statis dan dinamis, menyematkan pintasan) dan sepenuhnya mengimplementasikan API class API ShortcutManager.

Jika implementasi perangkat menyertakan aplikasi peluncur default yang menampilkan badge untuk ikon aplikasi, aplikasi tersebut:

  • [C-5-1] HARUS mematuhi metode API NotificationChannel.setShowBadge(). Dengan kata lain, tampilkan kemampuan visual yang terkait dengan ikon aplikasi jika nilai ditetapkan sebagai true, dan jangan tampilkan skema badge ikon aplikasi apa pun saat semua saluran notifikasi aplikasi telah menetapkan nilai sebagai false.
  • DAPAT mengganti badge ikon aplikasi dengan skema badge eksklusifnya saat aplikasi pihak ketiga menunjukkan dukungan terhadap skema badge eksklusif melalui penggunaan API eksklusif, tetapi HARUS menggunakan resource dan nilai yang disediakan melalui API badge notifikasi yang dijelaskan dalam SDK, seperti Notification.Builder.setNumber() dan Notification.Builder.setBadgeIconType() API.

3.8.2. Widget

Android mendukung widget aplikasi pihak ketiga dengan menentukan jenis komponen serta API dan siklus proses yang sesuai yang memungkinkan aplikasi mengekspos “AppWidget” kepada pengguna akhir.

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

  • [C-1-1] HARUS mendeklarasikan dukungan untuk fitur platform android.software.app_widgets.
  • [C-1-2] HARUS menyertakan dukungan bawaan untuk AppWidget dan mengekspos kemampuan antarmuka pengguna untuk menambahkan, mengonfigurasi, melihat, dan menghapus AppWidget langsung dalam Peluncur.
  • [C-1-3] HARUS dapat merender widget berukuran 4x4 dalam ukuran petak standar. Lihat Panduan Desain Widget Aplikasi di dokumentasi Android SDK untuk mengetahui detailnya.
  • DAPAT mendukung widget aplikasi di layar kunci.

Jika implementasi perangkat mendukung widget aplikasi pihak ketiga dan penyematan pintasan dalam aplikasi, implementasi tersebut:

3.8.3. Notifikasi

Android menyertakan Notification dan NotificationManager API yang memungkinkan developer aplikasi pihak ketiga memberi tahu pengguna tentang peristiwa penting dan menarik perhatian pengguna menggunakan komponen hardware (misalnya, suara, getaran, dan cahaya) dan fitur software (misalnya, panel notifikasi, panel sistem) perangkat.

3.8.3.1. Presentasi Notifikasi

Jika implementasi perangkat mengizinkan aplikasi pihak ketiga untuk memberi tahu pengguna tentang peristiwa penting, aplikasi tersebut:

  • [C-1-1] HARUS mendukung notifikasi yang menggunakan fitur hardware, seperti yang dijelaskan dalam dokumentasi SDK, dan sejauh mungkin dengan hardware implementasi perangkat. Misalnya, jika implementasi perangkat menyertakan vibrator, implementasi API getaran HARUS dilakukan dengan benar. Jika implementasi perangkat tidak memiliki hardware, API yang sesuai HARUS diterapkan sebagai no-ops. Perilaku ini dijelaskan lebih lanjut di bagian 7.
  • [C-1-2] HARUS merender semua resource (ikon, file animasi, dll.) yang disediakan di API, atau di panduan gaya ikon Status/Bilah Sistem dengan benar, meskipun aplikasi DAPAT memberikan pengalaman pengguna alternatif untuk notifikasi selain yang disediakan oleh implementasi Android Open Source referensi.
  • [C-1-3] HARUS mematuhi dan menerapkan dengan benar perilaku yang dijelaskan untuk API guna memperbarui, menghapus, dan mengelompokkan notifikasi.
  • [C-1-4] HARUS memberikan perilaku lengkap NotificationChannel API yang didokumentasikan dalam SDK.
  • [C-1-5] HARUS memberikan kemampuan pengguna untuk memblokir dan mengubah notifikasi aplikasi pihak ketiga tertentu per setiap saluran dan tingkat paket aplikasi.
  • [C-1-6] JUGA HARUS memberikan kemampuan pengguna untuk menampilkan saluran notifikasi yang dihapus.
  • [C-1-7] HARUS merender semua resource (gambar, stiker, ikon, dll.) yang disediakan melalui Notification.MessagingStyle dengan benar bersama teks notifikasi tanpa interaksi pengguna tambahan. Misalnya, HARUS menampilkan semua resource termasuk ikon yang disediakan melalui android.app.Person dalam percakapan grup yang ditetapkan melalui setGroupConversation.
  • [C-SR] SANGAT DISARANKAN untuk menampilkan kemampuan pengguna secara otomatis untuk memblokir notifikasi aplikasi pihak ketiga tertentu per setiap saluran dan tingkat paket aplikasi setelah pengguna menutup notifikasi tersebut beberapa kali.
  • HARUS mendukung notifikasi yang dinamis.
  • HARUS menampilkan beberapa notifikasi prioritas yang lebih tinggi sebagai notifikasi pendahuluan.
  • HARUS memiliki kemampuan pengguna untuk menunda notifikasi.
  • HANYA BOLEH mengelola visibilitas dan waktu saat aplikasi pihak ketiga dapat memberi tahu pengguna tentang peristiwa penting untuk mengurangi masalah keselamatan seperti gangguan pengemudi.

Jika implementasi perangkat mendukung notifikasi lengkap, implementasi tersebut:

  • [C-2-1] HARUS menggunakan resource yang sama persis seperti yang disediakan melalui class API Notification.Style dan subclass-nya untuk elemen resource yang ditampilkan.
  • HARUS menampilkan setiap elemen resource (misalnya ikon, judul, dan teks ringkasan) yang ditentukan dalam class API Notification.Style dan subclass-nya.

Jika implementasi perangkat mendukung notifikasi pendahuluan: notifikasi tersebut:

  • [C-3-1] HARUS menggunakan tampilan dan resource notifikasi peringatan dini seperti yang dijelaskan dalam class API Notification.Builder saat notifikasi peringatan dini ditampilkan.
  • [C-3-2] HARUS menampilkan tindakan yang disediakan melalui Notification.Builder.addAction() bersama dengan konten notifikasi tanpa interaksi pengguna tambahan seperti yang dijelaskan dalam SDK.
3.8.3.2. Layanan Pemroses Notifikasi

Android menyertakan API NotificationListenerService yang memungkinkan aplikasi (setelah diaktifkan secara eksplisit oleh pengguna) menerima salinan semua notifikasi saat diposting atau diperbarui.

Jika implementasi perangkat melaporkan flag fitur android.hardware.ram.normal, implementasi tersebut:

  • [C-1-1] HARUS memperbarui notifikasi secara keseluruhan dengan benar dan segera ke semua layanan pemroses yang diinstal dan diaktifkan pengguna tersebut, termasuk semua metadata yang dilampirkan ke objek Notifikasi.
  • [C-1-2] HARUS mematuhi panggilan API snoozeNotification(), dan menutup notifikasi serta membuat callback setelah durasi penundaan yang ditetapkan dalam panggilan API.

Jika implementasi perangkat memiliki kemampuan pengguna untuk menunda notifikasi, perangkat tersebut:

  • [C-2-1] HARUS mencerminkan status notifikasi yang ditangguhkan dengan benar melalui API standar seperti NotificationListenerService.getSnoozedNotifications().
  • [C-2-2] HARUS menyediakan kemampuan pengguna ini untuk menunda notifikasi dari setiap aplikasi pihak ketiga yang diinstal, kecuali jika berasal dari layanan persisten/latar depan.
3.8.3.3. DND (Jangan Ganggu)

Jika implementasi perangkat mendukung fitur DND, perangkat tersebut:

  • [C-1-1] HARUS menerapkan aktivitas yang akan merespons intent ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS, yang untuk implementasi dengan UI_MODE_TYPE_NORMAL HARUS berupa aktivitas tempat pengguna dapat memberikan atau menolak akses aplikasi ke konfigurasi kebijakan DND.
  • [C-1-2] HARUS, jika penerapan perangkat telah menyediakan cara bagi pengguna untuk mengizinkan atau menolak aplikasi pihak ketiga mengakses konfigurasi kebijakan DND, tampilkan Aturan DND otomatis yang dibuat oleh aplikasi bersama dengan aturan yang dibuat pengguna dan aturan standar.
  • [C-1-3] HARUS mematuhi nilai suppressedVisualEffects yang diteruskan melalui NotificationManager.Policy dan jika aplikasi telah menetapkan salah satu tanda SUPPRESSED_EFFECT_SCREEN_OFF atau SUPPRESSED_EFFECT_SCREEN_ON, aplikasi HARUS menunjukkan kepada pengguna bahwa efek visual dinonaktifkan di menu setelan DND.

Android menyertakan API yang memungkinkan developer memasukkan penelusuran ke dalam aplikasi mereka dan mengekspos data aplikasi mereka ke dalam penelusuran sistem global. Secara umum, fungsi ini terdiri dari satu antarmuka pengguna seluruh sistem yang memungkinkan pengguna memasukkan kueri, menampilkan saran saat pengguna mengetik, dan menampilkan hasil. Android API memungkinkan developer menggunakan kembali antarmuka ini untuk menyediakan penelusuran dalam aplikasi mereka sendiri dan memungkinkan developer menyediakan hasil ke antarmuka pengguna penelusuran global umum.

  • Implementasi perangkat Android HARUS menyertakan penelusuran global, satu antarmuka pengguna penelusuran bersama di seluruh sistem yang mampu memberikan saran real-time sebagai respons terhadap input pengguna.

Jika implementasi perangkat menerapkan antarmuka penelusuran global, implementasi tersebut:

  • [C-1-1] HARUS menerapkan API yang memungkinkan aplikasi pihak ketiga menambahkan saran ke kotak penelusuran saat dijalankan dalam mode penelusuran global.

Jika tidak ada aplikasi pihak ketiga yang diinstal yang menggunakan penelusuran global:

  • Perilaku default HARUS menampilkan hasil dan saran mesin telusur web.

Android juga menyertakan Assist API untuk memungkinkan aplikasi memilih jumlah informasi konteks saat ini yang dibagikan kepada asisten di perangkat.

Jika implementasi perangkat mendukung tindakan Bantuan, tindakan tersebut:

  • [C-2-1] HARUS menunjukkan dengan jelas kepada pengguna akhir kapan konteks dibagikan, dengan:
    • Setiap kali aplikasi bantuan mengakses konteks, aplikasi akan menampilkan cahaya putih di sekitar tepi layar yang memenuhi atau melebihi durasi dan kecerahan penerapan Project Open Source Android.
    • Untuk aplikasi bantuan yang diinstal sebelumnya, berikan kemampuan pengguna kurang dari dua navigasi dari menu setelan aplikasi asisten dan input suara default, dan hanya bagikan konteks saat aplikasi bantuan dipanggil secara eksplisit oleh pengguna melalui kata kunci panas atau input tombol navigasi bantuan.
  • [C-2-2] Interaksi yang ditetapkan untuk meluncurkan aplikasi bantuan seperti yang dijelaskan dalam bagian 7.2.3 HARUS meluncurkan aplikasi bantuan yang dipilih pengguna, dengan kata lain aplikasi yang mengimplementasikan VoiceInteractionService, atau aktivitas yang menangani intent ACTION_ASSIST.

3.8.5. Notifikasi dan Toast

Aplikasi dapat menggunakan Toast API untuk menampilkan string non-modal singkat kepada pengguna akhir yang menghilang setelah jangka waktu singkat, dan menggunakan API jenis jendela TYPE_APPLICATION_OVERLAY untuk menampilkan jendela pemberitahuan sebagai overlay di atas aplikasi lain.

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

  • [C-1-1] HARUS memberikan kemampuan pengguna untuk memblokir aplikasi agar tidak menampilkan jendela pemberitahuan yang menggunakan TYPE_APPLICATION_OVERLAY . Penerapan AOSP memenuhi persyaratan ini dengan memiliki kontrol di panel notifikasi.

  • [C-1-2] HARUS mematuhi Toast API dan menampilkan Toast dari aplikasi kepada pengguna akhir dengan cara yang sangat terlihat.

3.8.6. Tema

Android menyediakan “tema” sebagai mekanisme bagi aplikasi untuk menerapkan gaya di seluruh Aktivitas atau aplikasi.

Android menyertakan keluarga tema “Holo” dan "Material" sebagai kumpulan gaya yang ditentukan untuk digunakan developer aplikasi jika mereka ingin mencocokkan tampilan dan nuansa tema Holo seperti yang ditentukan oleh Android SDK.

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

  • [C-1-1] TIDAK BOLEH mengubah atribut tema Holo yang ditampilkan ke aplikasi.
  • [C-1-2] HARUS mendukung keluarga tema “Material” dan TIDAK BOLEH mengubah atribut tema Material atau asetnya yang ditampilkan ke aplikasi.

Android juga menyertakan grup tema “Default Perangkat” sebagai serangkaian gaya yang ditentukan untuk digunakan developer aplikasi jika mereka ingin mencocokkan tampilan dan nuansa tema perangkat seperti yang ditentukan oleh pengimplementasi perangkat.

Android mendukung tema varian dengan panel sistem transparan, yang memungkinkan developer aplikasi mengisi area di belakang status dan panel navigasi dengan konten aplikasi mereka. Untuk mengaktifkan pengalaman developer yang konsisten dalam konfigurasi ini, gaya ikon status bar harus dipertahankan di berbagai implementasi perangkat.

Jika implementasi perangkat menyertakan status bar sistem, implementasi tersebut:

  • [C-2-1] HARUS menggunakan warna putih untuk ikon status sistem (seperti kekuatan sinyal dan level baterai) dan notifikasi yang dikeluarkan oleh sistem, kecuali jika ikon menunjukkan status yang bermasalah atau aplikasi meminta status bar terang menggunakan flag SYSTEM_UI_FLAG_LIGHT_STATUS_BAR.
  • [C-2-2] Implementasi perangkat Android HARUS mengubah warna ikon status sistem menjadi hitam (untuk mengetahui detailnya, lihat R.style) saat aplikasi meminta status bar terang.

3.8.7. Wallpaper Animasi

Android menentukan jenis komponen serta API dan siklus proses yang sesuai yang memungkinkan aplikasi mengekspos satu atau beberapa “Wallpaper Animasi” kepada pengguna akhir. Wallpaper hidup adalah animasi, pola, atau gambar serupa dengan kemampuan input terbatas yang ditampilkan sebagai wallpaper, di belakang aplikasi lain.

Hardware dianggap mampu menjalankan wallpaper animasi dengan andal jika dapat menjalankan semua wallpaper animasi, tanpa batasan fungsi, pada kecepatan frame yang wajar tanpa efek samping pada aplikasi lain. Jika batasan pada hardware menyebabkan wallpaper dan/atau aplikasi mengalami error, tidak berfungsi, menggunakan daya CPU atau baterai secara berlebihan, atau berjalan pada kecepatan frame yang tidak dapat diterima, hardware tersebut dianggap tidak dapat menjalankan wallpaper hidup. Misalnya, beberapa wallpaper hidup dapat menggunakan konteks OpenGL 2.0 atau 3.x untuk merender kontennya. Wallpaper hidup tidak akan berjalan dengan andal di hardware yang tidak mendukung beberapa konteks OpenGL karena penggunaan konteks OpenGL oleh wallpaper hidup dapat bertentangan dengan aplikasi lain yang juga menggunakan konteks OpenGL.

  • Implementasi perangkat yang mampu menjalankan wallpaper animasi dengan andal seperti yang dijelaskan di atas HARUS menerapkan wallpaper animasi.

Jika implementasi perangkat menerapkan wallpaper animasi, implementasi tersebut:

  • [C-1-1] HARUS melaporkan flag fitur platform android.software.live_wallpaper.

3.8.8. Peralihan Aktivitas

Kode sumber Android upstream menyertakan layar ringkasan, antarmuka pengguna tingkat sistem untuk beralih tugas dan menampilkan aktivitas dan tugas yang baru-baru ini diakses menggunakan gambar thumbnail status grafis aplikasi pada saat pengguna terakhir kali keluar dari aplikasi.

Implementasi perangkat termasuk tombol navigasi fungsi terbaru seperti yang dijelaskan dalam bagian 7.2.3 DAPAT mengubah antarmuka.

Jika implementasi perangkat termasuk tombol navigasi fungsi terbaru seperti yang dijelaskan di bagian 7.2.3 mengubah antarmuka, implementasi tersebut:

  • [C-1-1] HARUS mendukung minimal hingga 7 aktivitas yang ditampilkan.
  • HARUS setidaknya menampilkan judul 4 aktivitas sekaligus.
  • [C-1-2] HARUS menerapkan perilaku penyematan layar dan memberi pengguna menu setelan untuk mengaktifkan/menonaktifkan fitur.
  • HARUS menampilkan warna sorotan, ikon, judul layar di terbaru.
  • HARUS menampilkan kemampuan penutupan ("x"), tetapi DAPAT menundanya hingga pengguna berinteraksi dengan layar.
  • HARUS menerapkan pintasan untuk beralih dengan mudah ke aktivitas sebelumnya.
  • HARUS memicu tindakan pengalihan cepat antara dua aplikasi yang baru saja digunakan, saat tombol fungsi terbaru diketuk dua kali.
  • HARUS memicu mode multi-aplikasi layar terpisah, jika didukung, saat tombol fungsi terbaru ditekan lama.
  • DAPAT menampilkan video terbaru yang berafiliasi sebagai grup yang bergerak bersama.
  • [SR] SANGAT DISARANKAN untuk menggunakan antarmuka pengguna Android upstream (atau antarmuka berbasis thumbnail serupa) untuk layar ringkasan.

3.8.9. Pengelolaan Input

Android menyertakan dukungan untuk Pengelolaan Input dan dukungan untuk editor metode input pihak ketiga.

Jika implementasi perangkat mengizinkan pengguna menggunakan metode input pihak ketiga di perangkat, mereka:

  • [C-1-1] HARUS mendeklarasikan fitur platform android.software.input_methods dan mendukung IME API seperti yang ditentukan dalam dokumentasi Android SDK.
  • [C-1-2] HARUS menyediakan mekanisme yang dapat diakses pengguna untuk menambahkan dan mengonfigurasi metode input pihak ketiga sebagai respons terhadap intent android.settings.INPUT_METHOD_SETTINGS.

Jika implementasi perangkat mendeklarasikan flag fitur android.software.autofill, implementasi tersebut:

3.8.10. Kontrol Media Layar Kunci

Remote Control Client API tidak digunakan lagi mulai Android 5.0 dan diganti dengan Template Notifikasi Media yang memungkinkan aplikasi media berintegrasi dengan kontrol pemutaran yang ditampilkan di layar kunci.

3.8.11. Screensaver (sebelumnya Mimpi)

Android menyertakan dukungan untuk screensaverinteraktif, yang sebelumnya disebut sebagai Dream. Screensaver memungkinkan pengguna berinteraksi dengan aplikasi saat perangkat yang terhubung ke sumber daya tidak ada aktivitas atau di-dock di dok meja. Perangkat Android Watch DAPAT menerapkan screensaver, tetapi jenis implementasi perangkat lainnya HARUS menyertakan dukungan untuk screensaver dan memberikan opsi setelan bagi pengguna untuk mengonfigurasi screensaver sebagai respons terhadap intent android.settings.DREAM_SETTINGS.

3.8.12. Lokasi

Jika implementasi perangkat menyertakan sensor hardware (misalnya GPS) yang mampu memberikan koordinat lokasi, perangkat tersebut

3.8.13. Unicode dan Font

Android menyertakan dukungan untuk karakter emoji yang ditentukan dalam Unicode 10.0.

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

  • [C-1-1] HARUS dapat merender karakter emoji ini dalam glyph warna.
  • [C-1-2] HARUS menyertakan dukungan untuk:
    • Font Roboto 2 dengan ketebalan yang berbeda—sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light untuk bahasa yang tersedia di perangkat.
    • Cakupan Unicode 7.0 lengkap untuk Latin, Yunani, dan Sirilik, termasuk rentang Latin Extended A, B, C, dan D, serta semua glyph dalam blok simbol mata uang Unicode 7.0.
  • HARUS mendukung warna kulit dan emoji keluarga yang beragam seperti yang ditentukan dalam Laporan Teknis Unicode #51.

Jika implementasi perangkat menyertakan IME, implementasi tersebut:

  • HARUS menyediakan metode input kepada pengguna untuk karakter emoji ini.

3.8.14. Multi-aplikasi

Jika implementasi perangkat memiliki kemampuan untuk menampilkan beberapa aktivitas secara bersamaan, implementasi tersebut:

  • [C-1-1] HARUS menerapkan mode multi-aplikasi tersebut sesuai dengan perilaku aplikasi dan API yang dijelaskan dalam dokumentasi dukungan mode multi-aplikasi Android SDK dan memenuhi persyaratan berikut:
  • [C-1-2] Aplikasi dapat menunjukkan apakah aplikasi tersebut dapat beroperasi dalam mode multi-aplikasi di file AndroidManifest.xml, baik secara eksplisit melalui penetapan atribut android:resizeableActivity ke true atau secara implisit dengan memiliki targetSdkVersion > 24. Aplikasi yang secara eksplisit menetapkan atribut ini ke false dalam manifesnya TIDAK BOLEH diluncurkan dalam mode multi-aplikasi. Aplikasi lama dengan targetSdkVersion < 24 yang tidak menetapkan atribut android:resizeableActivity ini DAPAT diluncurkan dalam mode multi-aplikasi, tetapi sistem HARUS memberikan peringatan bahwa aplikasi mungkin tidak berfungsi seperti yang diharapkan dalam mode multi-aplikasi.
  • [C-1-3] TIDAK BOLEH menawarkan mode layar terpisah atau format bebas jika tinggi layar < 440 dp dan lebar layar < 440 dp.
  • Implementasi perangkat dengan ukuran layar xlarge HARUS mendukung mode bentuk bebas.

Jika implementasi perangkat mendukung mode multi-aplikasi, dan mode layar terpisah, implementasi tersebut:

  • [C-2-1] HARUS memuat peluncur yang dapat diubah ukurannya sebagai default.
  • [C-2-2] HARUS memangkas aktivitas yang di-dock dari multi-aplikasi layar terpisah, tetapi HARUS menampilkan beberapa kontennya, jika aplikasi Peluncur adalah jendela yang difokuskan.
  • [C-2-3] HARUS mematuhi nilai AndroidManifestLayout_minWidth dan AndroidManifestLayout_minHeight yang dideklarasikan dari aplikasi peluncur pihak ketiga dan tidak mengganti nilai ini selama menampilkan beberapa konten aktivitas yang di-dock.

Jika implementasi perangkat mendukung mode multi-aplikasi dan mode multi-aplikasi picture-in-picture, implementasi tersebut:

  • [C-3-1] HARUS meluncurkan aktivitas dalam mode multi-aplikasi picture-in-picture saat aplikasi: * Menargetkan API level 26 atau yang lebih tinggi dan mendeklarasikan android:supportsPictureInPicture * Menargetkan API level 25 atau yang lebih rendah dan mendeklarasikan android:resizeableActivity dan android:supportsPictureInPicture.
  • [C-3-2] HARUS mengekspos tindakan di SystemUI seperti yang ditentukan oleh aktivitas PIP saat ini melalui setActions() API.
  • [C-3-3] HARUS mendukung rasio aspek yang lebih besar dari atau sama dengan 1:2,39 dan kurang dari atau sama dengan 2,39:1, seperti yang ditentukan oleh aktivitas PIP melalui API setAspectRatio().
  • [C-3-4] HARUS menggunakan KeyEvent.KEYCODE_WINDOW untuk mengontrol jendela PIP; jika mode PIP tidak diterapkan, kunci HARUS tersedia untuk aktivitas latar depan.
  • [C-3-5] HARUS menyediakan kemampuan pengguna untuk memblokir aplikasi agar tidak ditampilkan dalam mode PIP; implementasi AOSP memenuhi persyaratan ini dengan memiliki kontrol di panel notifikasi.
  • [C-3-6] HARUS mengalokasikan lebar dan tinggi minimum 108 dp untuk jendela PIP dan lebar minimum 240 dp dan tinggi 135 dp untuk jendela PIP saat Configuration.uiMode dikonfigurasi sebagai UI_MODE_TYPE_TELEVISION.

3.8.15. Potongan Layar

Android mendukung Display Cutout seperti yang dijelaskan dalam dokumen SDK. DisplayCutout API menentukan area di tepi layar yang tidak berfungsi untuk menampilkan konten.

Jika implementasi perangkat menyertakan potongan layar, implementasi tersebut:

  • [C-1-1] HANYA boleh memiliki potongan di tepi pendek perangkat. Sebaliknya, jika rasio aspek perangkat adalah 1,0(1:1), perangkat TIDAK BOLEH memiliki cutout.
  • [C-1-2] TIDAK BOLEH memiliki lebih dari satu cutout per tepi.
  • [C-1-3] HARUS mematuhi flag cutout tampilan yang ditetapkan oleh aplikasi melalui API WindowManager.LayoutParams seperti yang dijelaskan dalam SDK.
  • [C-1-4] HARUS melaporkan nilai yang benar untuk semua metrik potongan yang ditentukan di API DisplayCutout.

3.9. Administrasi Perangkat

Android menyertakan fitur yang memungkinkan aplikasi yang peka keamanan untuk menjalankan fungsi administrasi perangkat di tingkat sistem, seperti menerapkan kebijakan sandi atau melakukan penghapusan total jarak jauh, melalui Android Device Administration API.

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

  • [C-1-1] HARUS mendeklarasikan android.software.device_admin.
  • [C-1-2] HARUS mendukung penyediaan pemilik perangkat seperti yang dijelaskan dalam bagian 3.9.1 dan bagian 3.9.1.1.

3.9.1 Penyediaan Perangkat

3.9.1.1 Penyediaan pemilik perangkat

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

  • [C-1-1] HARUS mendukung pendaftaran Klien Kebijakan Perangkat (DPC) sebagai aplikasi Pemilik Perangkat seperti yang dijelaskan di bawah:
  • [C-1-2] HARUS mewajibkan beberapa tindakan afirmatif selama proses penyediaan untuk mengizinkan aplikasi ditetapkan sebagai Pemilik Perangkat. Izin dapat diberikan melalui tindakan pengguna atau dengan beberapa cara terprogram selama penyediaan, tetapi TIDAK BOLEH di-hardcode atau mencegah penggunaan aplikasi Pemilik Perangkat lainnya.

Jika implementasi perangkat mendeklarasikan android.software.device_admin, tetapi juga menyertakan solusi pengelolaan Pemilik Perangkat eksklusif dan menyediakan mekanisme untuk mempromosikan aplikasi yang dikonfigurasi dalam solusinya sebagai "Pemilik Perangkat yang setara" dengan "Pemilik Perangkat" standar seperti yang diakui oleh DevicePolicyManager API Android standar, implementasi tersebut:

  • [C-2-1] HARUS memiliki proses untuk memverifikasi bahwa aplikasi tertentu yang dipromosikan adalah milik solusi pengelolaan perangkat perusahaan yang sah dan telah dikonfigurasi dalam solusi eksklusif untuk memiliki hak yang setara sebagai "Pemilik Perangkat".
  • [C-2-2] HARUS menampilkan pengungkapan izin Pemilik Perangkat AOSP yang sama dengan alur yang dimulai oleh android.app.action.PROVISION_MANAGED_DEVICE sebelum mendaftarkan aplikasi DPC sebagai "Pemilik Perangkat".
  • DAPAT memiliki data pengguna di perangkat sebelum mendaftarkan aplikasi DPC sebagai "Pemilik Perangkat".
3.9.1.2 Penyediaan profil terkelola

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

  • [C-1-1] HARUS menerapkan API yang memungkinkan aplikasi Pengontrol Kebijakan Perangkat (DPC) menjadi pemilik Profil Terkelola baru.

  • [C-1-2] Pengalaman pengguna proses penyediaan profil terkelola (alur yang dimulai oleh android.app.action.PROVISION_MANAGED_PROFILE) HARUS selaras dengan penerapan AOSP.

  • [C-1-3] HARUS menyediakan kemampuan pengguna berikut dalam Setelan untuk menunjukkan kepada pengguna saat fungsi sistem tertentu telah dinonaktifkan oleh Pengontrol Kebijakan Perangkat (DPC):

    • Ikon yang konsisten atau kemampuan pengguna lainnya (misalnya ikon info AOSP upstream) untuk menunjukkan kapan setelan tertentu dibatasi oleh Admin Perangkat.
    • Pesan penjelasan singkat, seperti yang diberikan oleh Admin Perangkat melalui setShortSupportMessage.
    • Ikon aplikasi DPC.

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 API.
  • [C-1-2] HARUS mengizinkan satu dan hanya satu profil terkelola yang dibuat.
  • [C-1-3] HARUS menggunakan badge ikon (mirip dengan badge kerja upstream AOSP) untuk merepresentasikan aplikasi dan widget terkelola serta elemen UI berbadge lainnya seperti Terbaru & Notifikasi.
  • [C-1-4] HARUS menampilkan ikon notifikasi (mirip dengan badge kerja upstream AOSP) untuk menunjukkan saat pengguna berada dalam aplikasi profil terkelola.
  • [C-1-5] HARUS menampilkan toast yang menunjukkan bahwa pengguna berada dalam profil terkelola jika dan saat perangkat aktif (ACTION_USER_PRESENT) dan aplikasi latar depan berada dalam profil terkelola.
  • [C-1-6] Jika profil terkelola ada, HARUS menampilkan kemampuan visual di 'Pemilih' Intent untuk memungkinkan pengguna meneruskan intent dari profil terkelola ke pengguna utama atau sebaliknya, jika diaktifkan oleh Pengontrol Kebijakan Perangkat.
  • [C-1-7] Jika profil terkelola ada, HARUS mengekspos kemampuan pengguna berikut untuk pengguna utama dan profil terkelola:
    • Akuntansi terpisah untuk penggunaan baterai, lokasi, data seluler, dan penyimpanan untuk pengguna utama dan profil terkelola.
    • Pengelolaan independen Aplikasi VPN yang diinstal dalam pengguna utama atau profil terkelola.
    • Pengelolaan independen aplikasi yang diinstal dalam pengguna utama atau profil terkelola.
    • Pengelolaan akun yang independen dalam profil pengguna utama atau terkelola.
  • [C-1-8] HARUS memastikan aplikasi telepon, kontak, dan pesan bawaan dapat menelusuri dan mencari informasi pemanggil dari profil terkelola (jika ada) bersama dengan informasi dari profil utama, jika Pengontrol Kebijakan Perangkat mengizinkannya.
  • [C-1-9] HARUS memastikan bahwa profil terkelola memenuhi semua persyaratan keamanan yang berlaku untuk perangkat dengan beberapa pengguna yang diaktifkan (lihatbagian 9.5), meskipun profil terkelola tidak dihitung sebagai pengguna lain selain pengguna utama.
  • [C-1-10] HARUS mendukung kemampuan untuk menentukan layar kunci terpisah yang memenuhi persyaratan berikut untuk memberikan akses ke aplikasi yang berjalan dalam profil terkelola.
    • Implementasi perangkat HARUS mematuhi intent DevicePolicyManager.ACTION_SET_NEW_PASSWORD dan menampilkan antarmuka untuk mengonfigurasi kredensial layar kunci terpisah untuk profil terkelola.
    • Kredensial layar kunci profil terkelola HARUS menggunakan mekanisme penyimpanan dan pengelolaan kredensial yang sama dengan profil induk, seperti yang didokumentasikan di Situs Project Open Source Android.
    • Kebijakan sandi DPC HARUS hanya berlaku untuk kredensial layar kunci profil terkelola, kecuali jika dipanggil pada instance DevicePolicyManager yang ditampilkan oleh getParentProfileInstance.
  • Saat kontak dari profil terkelola ditampilkan di log panggilan bawaan, UI dalam panggilan, notifikasi panggilan yang sedang berlangsung dan panggilan tidak terjawab, kontak dan aplikasi pesan HARUS diberi badge dengan badge yang sama yang digunakan untuk menunjukkan aplikasi profil terkelola.

3.9.3 Dukungan Pengguna Terkelola

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

  • [C-1-1] HARUS memberikan kemampuan pengguna untuk logout dari pengguna saat ini dan beralih kembali ke pengguna utama dalam sesi beberapa pengguna saat isLogoutEnabled menampilkan true. Affordance pengguna HARUS dapat diakses dari layar kunci tanpa membuka kunci perangkat.

3.10. Aksesibilitas

Android menyediakan lapisan aksesibilitas yang membantu pengguna difabel untuk menavigasi perangkat mereka dengan lebih mudah. Selain itu, Android menyediakan API platform yang memungkinkan implementasi layanan aksesibilitas menerima callback untuk peristiwa pengguna dan sistem serta menghasilkan mekanisme masukan alternatif, seperti text-to-speech, haptic feedback, dan navigasi trackball/d-pad.

Jika implementasi perangkat mendukung layanan aksesibilitas pihak ketiga, implementasi tersebut:

  • [C-1-1] HARUS menyediakan implementasi framework aksesibilitas Android seperti yang dijelaskan dalam dokumentasi SDK API aksesibilitas.
  • [C-1-2] HARUS menghasilkan peristiwa aksesibilitas dan mengirimkan AccessibilityEvent yang sesuai ke semua implementasi AccessibilityService terdaftar seperti yang didokumentasikan dalam SDK.
  • [C-1-3] HARUS mematuhi intent android.settings.ACCESSIBILITY_SETTINGS untuk menyediakan mekanisme yang dapat diakses pengguna guna mengaktifkan dan menonaktifkan layanan aksesibilitas pihak ketiga bersama dengan layanan aksesibilitas yang telah diinstal sebelumnya.
  • [C-1-4] HARUS menambahkan tombol di menu navigasi sistem yang memungkinkan pengguna mengontrol layanan aksesibilitas saat layanan aksesibilitas yang diaktifkan mendeklarasikan AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON . Perhatikan bahwa untuk implementasi perangkat tanpa menu navigasi sistem, persyaratan ini tidak berlaku, tetapi implementasi perangkat HARUS memberikan kemampuan pengguna untuk mengontrol layanan aksesibilitas ini.

Jika implementasi perangkat menyertakan layanan aksesibilitas bawaan, layanan tersebut:

  • [C-2-1] HARUS menerapkan layanan aksesibilitas bawaan ini sebagai aplikasi Direct Boot Aware saat penyimpanan data dienkripsi dengan Enkripsi Berbasis File (FBE).
  • HARUS menyediakan mekanisme dalam alur penyiapan siap pakai bagi pengguna untuk mengaktifkan layanan aksesibilitas yang relevan, serta opsi untuk menyesuaikan ukuran font, ukuran tampilan, dan gestur pembesaran.

3.11. Text-to-Speech

Android menyertakan API yang memungkinkan aplikasi menggunakan layanan text-to-speech (TTS) dan memungkinkan penyedia layanan menyediakan implementasi layanan TTS.

Jika implementasi perangkat melaporkan fitur android.hardware.audio.output, implementasi tersebut:

Jika implementasi perangkat mendukung penginstalan mesin TTS pihak ketiga, implementasi tersebut:

  • [C-2-1] HARUS memberikan kemampuan pengguna untuk memungkinkan pengguna memilih mesin TTS untuk digunakan di tingkat sistem.

3.12. Framework Input TV

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

Jika implementasi perangkat mendukung TIF, implementasi tersebut:

  • [C-1-1] HARUS mendeklarasikan fitur platform android.software.live_tv.
  • [C-1-2] HARUS mendukung semua TIF API sehingga aplikasi yang menggunakan API ini dan layanan input berbasis TIF pihak ketiga dapat diinstal dan digunakan di perangkat.

3.13. Setelan Cepat

Android menyediakan komponen UI Setelan Cepat yang memungkinkan akses cepat ke tindakan yang sering digunakan atau sangat diperlukan.

Jika implementasi perangkat menyertakan komponen UI Setelan Cepat, implementasi tersebut:

  • [C-1-1] HARUS mengizinkan pengguna menambahkan atau menghapus kartu yang disediakan melalui quicksettings API dari aplikasi pihak ketiga.
  • [C-1-2] TIDAK BOLEH menambahkan kartu dari aplikasi pihak ketiga secara otomatis langsung ke Setelan Cepat.
  • [C-1-3] HARUS menampilkan semua kartu yang ditambahkan pengguna dari aplikasi pihak ketiga bersama dengan kartu setelan cepat yang disediakan sistem.

3.14. UI Media

Jika implementasi perangkat menyertakan framework UI yang mendukung aplikasi pihak ketiga yang bergantung pada MediaBrowser dan MediaSession , implementasi tersebut:

3.15. Aplikasi Instan

Implementasi perangkat HARUS memenuhi persyaratan berikut:

  • [C-0-1] Aplikasi Instan HANYA BOLEH diberi izin yang android:protectionLevel-nya ditetapkan ke "instant".
  • [C-0-2] Aplikasi Instan TIDAK BOLEH berinteraksi dengan aplikasi terinstal melalui intent implisit kecuali jika salah satu hal berikut benar:
    • Filter pola intent komponen diekspos dan memiliki CATEGORY_BROWSABLE
    • Tindakannya adalah salah satu dari ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
    • Target diekspos secara eksplisit dengan android:visibleToInstantApps
  • [C-0-3] Aplikasi Instan TIDAK BOLEH berinteraksi secara eksplisit dengan aplikasi terinstal kecuali jika komponen diekspos melalui android:visibleToInstantApps.
  • [C-0-4] Aplikasi Terinstal TIDAK BOLEH melihat detail tentang Aplikasi Instan di perangkat, kecuali jika Aplikasi Instan terhubung secara eksplisit ke aplikasi yang diinstal.

3.16. Penyandingan Perangkat Pendamping

Android menyertakan dukungan untuk penyambungan perangkat pendamping guna mengelola pengaitan dengan perangkat pendamping secara lebih efektif dan menyediakan CompanionDeviceManager API bagi aplikasi untuk mengakses fitur ini.

Jika implementasi perangkat mendukung fitur penyambungan perangkat pendamping, implementasi tersebut:

  • [C-1-1] HARUS mendeklarasikan flag fitur FEATURE_COMPANION_DEVICE_SETUP .
  • [C-1-2] HARUS memastikan API dalam paket android.companion diterapkan sepenuhnya.
  • [C-1-3] HARUS memberikan kemampuan pengguna bagi pengguna untuk memilih/mengonfirmasi bahwa perangkat pendamping ada dan beroperasi.

3.17. Aplikasi Berat

Jika implementasi perangkat mendeklarasikan fitur FEATURE_CANT_SAVE_STATE, maka:

  • [C-1-1] HARUS hanya memiliki satu aplikasi terinstal yang menentukan cantSaveState yang berjalan di sistem dalam satu waktu. Jika pengguna keluar dari aplikasi tersebut tanpa keluar secara eksplisit (misalnya dengan menekan tombol layar utama saat keluar dari aktivitas aktif sistem, bukan menekan kembali tanpa aktivitas aktif yang tersisa di sistem), implementasi perangkat HARUS memprioritaskan aplikasi tersebut di RAM seperti yang dilakukan untuk hal lain yang diharapkan tetap berjalan, seperti layanan latar depan. Saat aplikasi tersebut berada di latar belakang, sistem masih dapat menerapkan fitur pengelolaan daya ke aplikasi tersebut, seperti membatasi CPU dan akses jaringan.
  • [C-1-2] HARUS menyediakan kemampuan UI untuk memilih aplikasi yang tidak akan berpartisipasi dalam mekanisme penyimpanan/pemulihan status normal setelah pengguna meluncurkan aplikasi kedua yang dideklarasikan dengan atribut cantSaveState.
  • [C-1-3] TIDAK BOLEH menerapkan perubahan kebijakan lainnya pada aplikasi yang menentukan cantSaveState, seperti mengubah performa CPU atau mengubah prioritas penjadwalan.

Jika implementasi perangkat tidak mendeklarasikan fitur FEATURE_CANT_SAVE_STATE, implementasi tersebut:

  • [C-1-1] HARUS mengabaikan atribut cantSaveState yang ditetapkan oleh aplikasi dan TIDAK BOLEH mengubah perilaku aplikasi berdasarkan atribut tersebut.

4. Kompatibilitas Pengemasan Aplikasi

Implementasi perangkat:

  • [C-0-1] HARUS dapat menginstal dan menjalankan file “.apk” Android seperti yang dihasilkan oleh alat “aapt” yang disertakan dalam Android SDK resmi.
  • Karena persyaratan di atas mungkin sulit, implementasi perangkat DISARANKAN untuk menggunakan sistem pengelolaan paket implementasi referensi AOSP.

Implementasi perangkat:

  • [C-0-2] HARUS mendukung verifikasi file “.apk” menggunakan APK Signature Scheme v3, APK Signature Scheme v2, dan penandatanganan JAR.
  • [C-0-3] TIDAK BOLEH memperluas format .apk, Manifes Android, bytecode Dalvik, atau bytecode RenderScript sedemikian rupa sehingga mencegah file tersebut diinstal dan berjalan dengan benar di perangkat lain yang kompatibel.

  • [C-0-4] TIDAK BOLEH mengizinkan aplikasi selain "penginstal data" saat ini untuk paket agar dapat meng-uninstal aplikasi secara diam-diam tanpa konfirmasi pengguna, seperti yang didokumentasikan dalam SDK untuk izin DELETE_PACKAGE. Satu-satunya pengecualian adalah aplikasi verifier paket sistem yang menangani intent PACKAGE_NEEDS_VERIFICATION dan aplikasi pengelola penyimpanan yang menangani intent ACTION_MANAGE_STORAGE.

  • [C-0-5] HARUS memiliki aktivitas yang menangani intent android.settings.MANAGE_UNKNOWN_APP_SOURCES.

  • [C-0-6] TIDAK BOLEH menginstal paket aplikasi dari sumber tidak dikenal, kecuali jika aplikasi yang meminta penginstalan memenuhi semua persyaratan berikut:

    • Aplikasi HARUS mendeklarasikan izin REQUEST_INSTALL_PACKAGES atau menetapkan android:targetSdkVersion ke 24 atau lebih rendah.
    • Aplikasi HARUS telah diberi izin oleh pengguna untuk menginstal aplikasi dari sumber tidak dikenal.

  • HARUS memberikan kemampuan pengguna untuk memberikan/membatalkan izin untuk menginstal aplikasi dari sumber yang tidak dikenal per aplikasi, tetapi DAPAT memilih untuk menerapkannya sebagai tidak ada operasi dan menampilkan RESULT_CANCELED untuk startActivityForResult(), jika implementasi perangkat tidak ingin mengizinkan pengguna memiliki pilihan ini. Namun, meskipun dalam kasus tersebut, aplikasi HARUS menunjukkan kepada pengguna alasan tidak adanya pilihan tersebut.

  • [C-0-7] HARUS menampilkan dialog peringatan dengan string peringatan yang disediakan melalui API sistem PackageManager.setHarmfulAppWarning kepada pengguna sebelum meluncurkan aktivitas dalam aplikasi yang telah ditandai oleh API sistem PackageManager.setHarmfulAppWarning yang sama sebagai berpotensi berbahaya.

  • HARUS memberikan kemampuan pengguna untuk memilih meng-uninstal atau meluncurkan aplikasi di dialog peringatan.

5. Kompatibilitas Multimedia

Implementasi perangkat:

  • [C-0-1] HARUS mendukung format media, encoder, decoder, jenis file, dan format penampung yang ditentukan dalam bagian 5.1 untuk setiap codec yang dideklarasikan oleh MediaCodecList.
  • [C-0-2] HARUS mendeklarasikan dan melaporkan dukungan encoder, decoder yang tersedia untuk aplikasi pihak ketiga melalui MediaCodecList.
  • [C-0-3] HARUS dapat mendekode dan menyediakan semua format yang dapat dienkodenya kepada aplikasi pihak ketiga. Hal ini mencakup semua bitstream yang dihasilkan encoder dan profil yang dilaporkan di CamcorderProfile.

Implementasi perangkat:

  • HARUS menargetkan latensi codec minimum, dengan kata lain, mereka
    • TIDAK BOLEH menggunakan dan menyimpan buffer input serta menampilkan buffer input hanya setelah diproses.
    • TIDAK BOLEH menyimpan buffering yang didekode lebih lama dari yang ditentukan oleh standar (misalnya, SPS).
    • TIDAK BOLEH menyimpan buffering yang dienkode lebih lama dari yang diperlukan oleh struktur GOP.

Semua codec yang tercantum di bagian di bawah disediakan sebagai implementasi software dalam implementasi Android pilihan dari Project Open Source Android.

Perlu diperhatikan bahwa baik Google maupun Open Handset Alliance tidak membuat pernyataan apa pun bahwa codec ini bebas dari paten pihak ketiga. Bagi yang ingin menggunakan kode sumber ini dalam produk hardware atau software, sebaiknya perhatikan bahwa implementasi kode ini, termasuk dalam software open source atau shareware, mungkin memerlukan lisensi paten dari pemegang paten yang relevan.

5.1. Codec Media

5.1.1. Encoding Audio

Lihat detail selengkapnya di 5.1.3. Detail Codec Audio.

Jika implementasi perangkat mendeklarasikan android.hardware.microphone, implementasi tersebut HARUS mendukung encoding audio berikut:

  • [C-1-1] PCM/WAVE

5.1.2. Dekode Audio

Lihat detail selengkapnya di 5.1.3. Detail Codec Audio.

Jika implementasi perangkat mendeklarasikan dukungan untuk fitur android.hardware.audio.output, implementasi tersebut harus mendukung decoding format audio berikut:

  • [C-1-1] Profil AAC MPEG-4 (AAC LC)
  • [C-1-2] Profil MPEG-4 HE AAC (AAC+)
  • [C-1-3] Profil MPEG-4 HE AACv2 (AAC+ ditingkatkan)
  • [C-1-4] AAC ELD (AAC yang ditingkatkan dengan delay rendah)
  • [C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile, yang mencakup Profil Dasar Pengukuran USAC, dan ISO/IEC 23003-4 Dynamic Range Control Profile)
  • [C-1-5] FLAC
  • [C-1-6] MP3
  • [C-1-7] MIDI
  • [C-1-8] Vorbis
  • [C-1-9] PCM/WAVE
  • [C-1-10] Opus

Jika implementasi perangkat mendukung dekode buffer input AAC dari streaming multisaluran (yaitu lebih dari dua saluran) ke PCM melalui dekoder audio AAC default di android.media.MediaCodec API, hal berikut HARUS didukung:

  • [C-2-1] Dekode HARUS dilakukan tanpa downmix (misalnya, streaming AAC 5.0 harus didekode ke lima saluran PCM, streaming AAC 5.1 harus didekode ke enam saluran PCM).
  • [C-2-2] Metadata rentang dinamis HARUS seperti yang ditentukan dalam "Dynamic Range Control (DRC)" di ISO/IEC 14496-3, dan kunci DRC android.media.MediaFormat untuk mengonfigurasi perilaku terkait rentang dinamis dari dekoder audio. Kunci AAC DRC diperkenalkan di API 21, dan terdiri dari: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL, dan KEY_AAC_ENCODED_TARGET_LEVEL.

Saat mendekode audio USAC, MPEG-D (ISO/IEC 23003-4):

  • [C-3-1] Metadata volume dan DRC HARUS ditafsirkan dan diterapkan sesuai dengan Profil Kontrol Rentang Dinamis MPEG-D DRC Level 1.
  • [C-3-2] Dekoder HARUS berperilaku sesuai dengan konfigurasi yang ditetapkan dengan kunci android.media.MediaFormat berikut: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL dan KEY_AAC_DRC_EFFECT_TYPE.

Dekoder profil MPEG-4 AAC, HE AAC, dan HE AACv2:

  • DAPAT mendukung kontrol volume dan rentang dinamis menggunakan Profil Kontrol Rentang Dinamis ISO/IEC 23003-4.

Jika ISO/IEC 23003-4 didukung dan jika metadata ISO/IEC 23003-4 dan ISO/IEC 14496-3 ada dalam bitstream yang didekode, maka:

  • Metadata ISO/IEC 23003-4 HARUS diutamakan.

5.1.3. Detail Codec Audio

Format/Codec Detail Jenis File/Format Penampung yang Didukung
Profil AAC MPEG-4
(AAC LC) 		Dukungan untuk konten mono/stereo/5.0/5.1 dengan frekuensi pengambilan sampel standar dari 8 hingga 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
  • AAC mentah ADTS (.aac, ADIF tidak didukung)
  • MPEG-TS (.ts, tidak dapat digeser)
Profil MPEG-4 HE AAC (AAC+) Dukungan untuk konten mono/stereo/5.0/5.1 dengan frekuensi pengambilan sampel standar dari 16 hingga 48 kHz.
Profil MPEG-4 HE AACv2
(AAC+ ditingkatkan) 		Dukungan untuk konten mono/stereo/5.0/5.1 dengan frekuensi pengambilan sampel standar dari 16 hingga 48 kHz.
AAC ELD (AAC yang ditingkatkan dengan delay rendah) Dukungan untuk konten mono/stereo dengan frekuensi sampling standar dari 16 hingga 48 kHz.
USAC Dukungan untuk konten mono/stereo dengan frekuensi sampling standar dari 7,35 hingga 48 kHz. MPEG-4 (.mp4, .m4a)
AMR-NB 4,75 hingga 12,2 kbps dengan sampel @ 8 kHz 3GPP (.3gp)
AMR-WB 9 frekuensi dari 6,60 kbit/dtk hingga 23,85 kbit/dtk dengan sampel @ 16 kHz
FLAC Mono/Stereo (tanpa multisaluran). Frekuensi sampel hingga 48 kHz (tetapi direkomendasikan hingga 44,1 kHz di perangkat dengan output 44,1 kHz, karena penurun sampel 48 hingga 44,1 kHz tidak menyertakan filter tingkat rendah). 16-bit DIUTAMAKAN; tidak ada dither yang diterapkan untuk 24-bit. Hanya FLAC (.flac)
MP3 Mono/Stereo 8-320 Kbps konstan (CBR) atau kecepatan bit variabel (VBR) MP3 (.mp3)
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
  • Jenis 0 dan 1 (.mid, .xmf, .mxmf)
  • RTTTL/RTX (.rtttl, .rtx)
  • OTA (.ota)
  • iMelody (.imy)
Vorbis
  • Ogg (.ogg)
  • Matroska (.mkv, Android 4.0+)
PCM/WAVE PCM linear 16-bit (frekuensi hingga batas hardware). Perangkat HARUS mendukung frekuensi sampling untuk perekaman PCM mentah pada frekuensi 8000, 11025, 16000, dan 44100 Hz. WAVE (.wav)
Opus Matroska (.mkv), Ogg(.ogg)

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

5.1.5. Dekode Gambar

Lihat detail selengkapnya di 5.1.6. Detail Codec Gambar.

Implementasi perangkat HARUS mendukung decoding encoding gambar berikut:

  • [C-0-1] JPEG
  • [C-0-2] GIF
  • [C-0-3] PNG
  • [C-0-4] BMP
  • [C-0-5] WebP
  • [C-0-6] Mentah
  • [C-0-7] HEIF (HEIC)

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)

5.1.7. Codec Video

  • Untuk kualitas streaming video web dan layanan konferensi video yang dapat diterima, implementasi perangkat HARUS menggunakan codec VP8 hardware yang memenuhi persyaratan.

Jika implementasi perangkat menyertakan decoder atau encoder video:

  • [C-1-1] Codec video HARUS mendukung ukuran bytebuffer output dan input yang mengakomodasi frame terkompresi dan tidak terkompresi terbesar yang memungkinkan seperti yang ditentukan oleh standar dan konfigurasi, tetapi juga tidak mengalokasikan secara berlebihan.

  • [C-1-2] Encoder dan decoder video HARUS mendukung format warna fleksibel YUV420 (COLOR_FormatYUV420Flexible).

Jika implementasi perangkat mengiklankan dukungan profil HDR melalui Display.HdrCapabilities, implementasi tersebut:

  • [C-2-1] HARUS mendukung penguraian dan penanganan metadata statis HDR.

Jika implementasi perangkat mengiklankan dukungan intra refresh melalui FEATURE_IntraRefresh di class MediaCodecInfo.CodecCapabilities, implementasi tersebut:

  • [C-3-1] HARUS mendukung periode refresh dalam rentang 10 - 60 frame dan beroperasi secara akurat dalam 20% periode refresh yang dikonfigurasi.

5.1.8. Daftar Codec Video

Format/Codec Detail Jenis File/Format Penampung
yang Didukung
H.263
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
H.264 AVC Lihat pasal 5.2 dan 5.3 untuk mengetahui detailnya
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • MPEG-2 TS (.ts, AAC hanya audio, tidak dapat digeser, Android 3.0+)
H.265 HEVC Lihat bagian 5.3 untuk mengetahui detailnya MPEG-4 (.mp4)
MPEG-2 Profil Utama MPEG2-TS
MPEG-4 SP 3GPP (.3gp)
VP8 Lihat pasal 5.2 dan 5.3 untuk mengetahui detailnya
VP9 Lihat bagian 5.3 untuk mengetahui detailnya

5.2. Encoding Video

Jika implementasi perangkat mendukung encoder video dan menyediakannya untuk aplikasi pihak ketiga, implementasi tersebut:

  • TIDAK BOLEH, selama dua periode geser, lebih dari ~15% dari kecepatan bit antara interval intraframe (I-frame).
  • TIDAK BOLEH lebih dari ~100% dari kecepatan bit selama periode geser 1 detik.

Jika implementasi perangkat menyertakan tampilan layar tersemat dengan panjang diagonal minimal 2,5 inci atau menyertakan port output video atau mendeklarasikan dukungan kamera melalui flag fitur android.hardware.camera.any, perangkat tersebut:

  • [C-1-1] HARUS menyertakan dukungan setidaknya salah satu encoder video VP8 atau H.264, dan menyediakannya untuk aplikasi pihak ketiga.
  • HARUS mendukung encoder video VP8 dan H.264, serta menyediakannya untuk aplikasi pihak ketiga.

Jika implementasi perangkat mendukung encoder video H.264, VP8, VP9, atau HEVC dan menyediakannya untuk aplikasi pihak ketiga, implementasi tersebut:

  • [C-2-1] HARUS mendukung kecepatan bit yang dapat dikonfigurasi secara dinamis.
  • HARUS mendukung kecepatan frame variabel, dengan encoder video HARUS menentukan durasi frame seketika berdasarkan stempel waktu buffering input, dan mengalokasikan bucket bitnya berdasarkan durasi frame tersebut.

Jika implementasi perangkat mendukung encoder video MPEG-4 SP dan menyediakannya untuk aplikasi pihak ketiga, implementasi tersebut:

  • HARUS mendukung kecepatan bit yang dapat dikonfigurasi secara dinamis untuk encoder yang didukung.

5.2.1. H.263

Jika implementasi perangkat mendukung encoder H.263 dan menyediakannya untuk aplikasi pihak ketiga, implementasi tersebut:

  • [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 penerapan perangkat mendukung codec H.264, perangkat tersebut:

  • [C-1-1] HARUS mendukung Profil Dasar Pengukuran Level 3. Namun, dukungan untuk ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering), dan RS (Redundant Slices) bersifat OPSIONAL. Selain itu, untuk mempertahankan kompatibilitas dengan perangkat Android lainnya, sebaiknya ASO, FMO, dan RS tidak digunakan untuk Profil Dasar Pengukuran oleh encoder.
  • [C-1-2] HARUS mendukung profil encoding video SD (Definisi Standar) dalam tabel berikut.
  • HARUS mendukung Profil Utama Level 4.
  • HARUS mendukung profil encoding video HD (High Definition) seperti yang ditunjukkan dalam tabel berikut.

Jika implementasi perangkat melaporkan dukungan encoding H.264 untuk video beresolusi 720p atau 1080p melalui API media, implementasi tersebut:

  • [C-2-1] HARUS mendukung profil encoding dalam tabel berikut.
SD (Kualitas rendah) SD (Kualitas tinggi) HD 720p HD 1080p
Resolusi video 320 x 240 px 720 x 480 piksel 1280 x 720 px 1920 x 1080 px
Frekuensi gambar video 20 fps 30 fps 30 fps 30 fps
Kecepatan bit video 384 Kbps 2 Mbps 4 Mbps 10 Mbps

5.2.3. VP8

Jika implementasi perangkat mendukung codec VP8, perangkat tersebut:

  • [C-1-1] HARUS mendukung profil encoding video SD.
  • HARUS mendukung profil encoding video HD (High Definition) berikut.
  • HARUS mendukung penulisan file WebM Matroska.
  • HARUS menggunakan codec VP8 hardware yang memenuhi persyaratan coding hardware RTC project WebM, untuk memastikan kualitas streaming video web dan layanan konferensi video yang dapat diterima.

Jika implementasi perangkat melaporkan dukungan encoding VP8 untuk video beresolusi 720p atau 1080p melalui API media, implementasi tersebut:

  • [C-2-1] HARUS mendukung profil encoding dalam tabel berikut.
SD (Kualitas rendah) SD (Kualitas tinggi) HD 720p HD 1080p
Resolusi video 320 x 180 px 640 x 360 px 1280 x 720 px 1920 x 1080 px
Frekuensi gambar video 30 fps 30 fps 30 fps 30 fps
Kecepatan bit video 800 Kbps 2 Mbps 4 Mbps 10 Mbps

5.2.4. VP9

Jika implementasi perangkat mendukung codec VP9, perangkat tersebut:

  • HARUS mendukung penulisan file WebM Matroska.

5.3. Dekode Video

Jika implementasi perangkat mendukung codec VP8, VP9, H.264, atau H.265, implementasi tersebut:

  • [C-1-1] HARUS mendukung resolusi video dinamis dan peralihan kecepatan frame melalui API Android standar dalam aliran yang sama untuk semua codec VP8, VP9, H.264, dan H.265 secara real time dan hingga resolusi maksimum yang didukung oleh setiap codec di perangkat.

Jika implementasi perangkat mendeklarasikan dukungan untuk dekoder Dolby Vision melalui HDR_TYPE_DOLBY_VISION , implementasi tersebut:

  • [C-2-1] HARUS menyediakan ekstraktor yang kompatibel dengan Dolby Vision.
  • [C-2-2] HARUS menampilkan konten Dolby Vision dengan benar di layar perangkat atau di port output video standar (misalnya, HDMI).
  • [C-2-3] HARUS menetapkan indeks trek lapisan dasar yang mendukung kompatibilitas mundur (jika ada) agar sama dengan indeks trek lapisan Dolby Vision gabungan.

5.3.1. MPEG-2

Jika implementasi perangkat mendukung decoder MPEG-2, perangkat tersebut:

  • [C-1-1] HARUS mendukung Profil Utama Tingkat Tinggi.

5.3.2. H.263

Jika penerapan perangkat mendukung decoder H.263, perangkat tersebut:

  • [C-1-1] HARUS mendukung Profil Dasar Pengukuran Level 30 dan Level 45.

5.3.3. MPEG-4

Jika implementasi perangkat dengan dekoder MPEG-4, perangkat tersebut:

  • [C-1-1] HARUS mendukung Profil Sederhana Level 3.

5.3.4. H.264

Jika implementasi perangkat mendukung decoder H.264, perangkat tersebut:

  • [C-1-1] HARUS mendukung Profil Utama Level 3.1 dan Profil Dasar Pengukuran. Dukungan untuk ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering), dan RS (Redundant Slices) bersifat OPSIONAL.
  • [C-1-2] HARUS dapat mendekode video dengan profil SD (Standar Definisi) yang tercantum dalam tabel berikut dan dienkode dengan Profil Dasar Pengukuran dan Profil Utama Level 3.1 (termasuk 720p30).
  • HARUS dapat mendekode video dengan profil HD (High Definition) seperti yang ditunjukkan dalam tabel berikut.

Jika tinggi yang dilaporkan oleh metode Display.getSupportedModes() sama dengan atau lebih besar dari resolusi video, implementasi perangkat:

  • [C-2-1] HARUS mendukung profil decoding video HD 720p dalam tabel berikut.
  • [C-2-2] HARUS mendukung profil decoding video HD 1080p dalam tabel berikut.
SD (Kualitas rendah) SD (Kualitas tinggi) HD 720p HD 1080p
Resolusi video 320 x 240 px 720 x 480 piksel 1280 x 720 px 1920 x 1080 px
Frekuensi gambar video 30 fps 30 fps 60 fps 30 fps (60 fpsTelevisi)
Kecepatan bit video 800 Kbps 2 Mbps 8 Mbps 20 Mbps

5.3.5. H.265 (HEVC)

Jika penerapan perangkat mendukung codec H.265, perangkat tersebut:

  • [C-1-1] HARUS mendukung tingkat Utama Profil Utama Level 3 dan profil decoding video SD seperti yang ditunjukkan dalam tabel berikut.
  • HARUS mendukung profil decoding HD seperti yang ditunjukkan dalam tabel berikut.
  • [C-1-2] HARUS mendukung profil decoding HD seperti yang ditunjukkan dalam tabel berikut jika ada dekoder 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 decoding H.265 atau VP9 dari profil 720, 1080, dan UHD.
SD (Kualitas rendah) SD (Kualitas tinggi) HD 720p HD 1080p UHD
Resolusi video 352 x 288 piksel 720 x 480 piksel 1280 x 720 px 1920 x 1080 px 3840 x 2160 piksel
Frekuensi gambar video 30 fps 30 fps 30 fps 30/60 fps (60 fpsTelevisi dengan dekode hardware H.265) 60 fps
Kecepatan bit video 600 Kbps 1,6 Mbps 4 Mbps 5 Mbps 20 Mbps

5.3.6. VP8

Jika implementasi perangkat mendukung codec VP8, perangkat tersebut:

  • [C-1-1] HARUS mendukung profil decoding SD dalam tabel berikut.
  • HARUS menggunakan codec VP8 hardware yang memenuhi persyaratan.
  • HARUS mendukung profil decoding HD dalam tabel berikut.

Jika tinggi seperti yang dilaporkan oleh metode Display.getSupportedModes() sama dengan atau lebih besar dari resolusi video, maka:

  • [C-2-1] Implementasi perangkat HARUS mendukung profil 720p dalam tabel berikut.
  • [C-2-2] Implementasi perangkat HARUS mendukung profil 1080p dalam tabel berikut.
SD (Kualitas rendah) SD (Kualitas tinggi) HD 720p HD 1080p
Resolusi video 320 x 180 px 640 x 360 px 1280 x 720 px 1920 x 1080 px
Frekuensi gambar video 30 fps 30 fps 30 fps (60 fpsTelevisi) 30 (60 fpsTelevisi)
Kecepatan bit video 800 Kbps 2 Mbps 8 Mbps 20 Mbps

5.3.7. VP9

Jika implementasi perangkat mendukung codec VP9, perangkat tersebut:

  • [C-1-1] HARUS mendukung profil decoding video SD seperti yang ditunjukkan dalam tabel berikut.
  • HARUS mendukung profil decoding HD seperti yang ditunjukkan dalam tabel berikut.

Jika implementasi perangkat mendukung codec VP9 dan dekoder hardware:

  • [C-2-1] HARUS mendukung profil decoding HD seperti yang ditunjukkan dalam tabel berikut.

Jika tinggi yang dilaporkan oleh metode Display.getSupportedModes() sama dengan atau lebih besar dari resolusi video, maka:

  • [C-3-1] Implementasi perangkat HARUS mendukung setidaknya salah satu dekode VP9 atau H.265 dari profil 720, 1080, dan UHD.
SD (Kualitas rendah) SD (Kualitas tinggi) HD 720p HD 1080p UHD
Resolusi video 320 x 180 px 640 x 360 px 1280 x 720 px 1920 x 1080 px 3840 x 2160 piksel
Frekuensi gambar video 30 fps 30 fps 30 fps 30 fps (60 fpsTelevisi dengan decoding hardware VP9) 60 fps
Kecepatan bit video 600 Kbps 1,6 Mbps 4 Mbps 5 Mbps 20 Mbps

5.4. Perekaman Audio

Meskipun beberapa persyaratan yang diuraikan di bagian ini tercantum sebagai HARUS sejak Android 4.3, Definisi Kompatibilitas untuk versi mendatang direncanakan untuk mengubahnya menjadi HARUS. Perangkat Android yang ada dan baru SANGAT DISARANKAN untuk memenuhi persyaratan ini yang tercantum sebagai HARUS, atau perangkat tersebut tidak akan dapat mencapai kompatibilitas Android saat diupgrade ke versi mendatang.

5.4.1. Perekaman Audio Mentah

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

  • [C-1-1] HARUS mengizinkan perekaman konten audio mentah dengan karakteristik berikut:

    • Format: PCM Linear, 16-bit
    • Frekuensi sampling: 8000, 11025, 16000, 44100 Hz
    • Saluran: Mono

  • [C-1-2] HARUS merekam pada frekuensi sampel di atas tanpa upsampling.

  • [C-1-3] HARUS menyertakan filter anti-aliasing yang sesuai saat frekuensi sampel yang diberikan di atas diambil dengan downsampling.

  • HARUS mengizinkan perekaman konten audio mentah dengan kualitas radio AM dan DVD, yang berarti karakteristik berikut:

    • Format: PCM Linear, 16-bit
    • Rasio sampling: 22.050, 48.000 Hz
    • Saluran: Stereo

Jika implementasi perangkat memungkinkan perekaman konten audio mentah dengan kualitas radio AM dan DVD, perangkat tersebut:

  • [C-2-1] HARUS merekam 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 up-sampling atau down-sampling.

5.4.2. Merekam untuk Pengenalan Suara

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

  • [C-1-1] HARUS merekam sumber audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION pada salah satu frekuensi sampling, 44100 dan 48000.
  • [C-1-2] HARUS, secara default, menonaktifkan pemrosesan audio pengurangan bising saat merekam streaming audio dari sumber audio AudioSource.VOICE_RECOGNITION.
  • [C-1-3] HARUS, secara default, menonaktifkan kontrol penguatan otomatis saat merekam streaming audio dari sumber audio AudioSource.VOICE_RECOGNITION.
  • HARUS merekam streaming audio pengenalan suara dengan karakteristik frekuensi versus amplitudo yang kira-kira datar: khususnya, ±3 dB, dari 100 Hz hingga 4.000 Hz.
  • HARUS merekam streaming audio pengenalan suara dengan sensitivitas input yang ditetapkan sehingga sumber level daya suara (SPL) 90 dB pada 1.000 Hz menghasilkan RMS 2.500 untuk sampel 16-bit.
  • HARUS merekam streaming audio pengenalan suara sehingga level amplitudo PCM melacak perubahan SPL input secara linear dalam rentang minimal 30 dB dari -18 dB hingga +12 dB re 90 dB SPL di mikrofon.
  • HARUS merekam streaming audio pengenalan suara dengan total harmonic distortion (THD) kurang dari 1% untuk 1 kHz pada level input SPL 90 dB di mikrofon.

Jika implementasi perangkat mendeklarasikan teknologi android.hardware.microphone dan peredam bising (pengurangan) yang disesuaikan untuk pengenalan ucapan, teknologi tersebut:

  • [C-2-1] HARUS mengizinkan efek audio ini dapat dikontrol dengan android.media.audiofx.NoiseSuppressor API.
  • [C-2-2] HARUS mengidentifikasi setiap penerapan teknologi peredam bising secara unik melalui kolom AudioEffect.Descriptor.uuid.

5.4.3. Perekaman untuk Pemutaran yang Diarahkan Ulang

Class android.media.MediaRecorder.AudioSource menyertakan sumber audio REMOTE_SUBMIX.

Jika implementasi perangkat mendeklarasikan android.hardware.audio.output dan android.hardware.microphone, implementasi tersebut:

  • [C-1-1] HARUS menerapkan sumber audio REMOTE_SUBMIX dengan benar sehingga saat aplikasi menggunakan android.media.AudioRecord API untuk merekam dari sumber audio ini, aplikasi akan merekam campuran semua streaming audio kecuali untuk hal berikut:

    • AudioManager.STREAM_RING
    • AudioManager.STREAM_ALARM
    • AudioManager.STREAM_NOTIFICATION

5.5. Pemutaran Audio

Android menyertakan dukungan untuk memungkinkan aplikasi memutar audio melalui periferal output audio seperti yang ditentukan di bagian 7.8.2.

5.5.1. Pemutaran Audio Mentah

Jika implementasi perangkat mendeklarasikan android.hardware.audio.output, implementasi tersebut:

  • [C-1-1] HARUS mengizinkan pemutaran konten audio mentah dengan karakteristik berikut:

    • Format: PCM Linear, 16-bit, 8-bit, float
    • Saluran: Mono, Stereo, konfigurasi multisaluran yang valid dengan maksimal 8 saluran
    • Frekuensi sampling (dalam Hz):
      • 8000, 11025, 16000, 22050, 32000, 44100, 48000 pada konfigurasi saluran yang tercantum di atas
      • 96.000 dalam mono dan stereo

  • HARUS mengizinkan pemutaran konten audio mentah dengan karakteristik berikut:

    • Rasio sampling: 24.000, 48.000

5.5.2. Efek Audio

Android menyediakan API untuk efek audio untuk implementasi perangkat.

Jika implementasi perangkat mendeklarasikan fitur android.hardware.audio.output, implementasi tersebut:

  • [C-1-1] HARUS mendukung implementasi EFFECT_TYPE_EQUALIZER dan EFFECT_TYPE_LOUDNESS_ENHANCER yang dapat dikontrol melalui subclass AudioEffect Equalizer, LoudnessEnhancer.
  • [C-1-2] HARUS mendukung penerapan API visualiser, yang dapat dikontrol melalui class Visualizer.
  • [C-1-3] HARUS mendukung implementasi EFFECT_TYPE_DYNAMICS_PROCESSING yang dapat dikontrol melalui subclass AudioEffect DynamicsProcessing.
  • HARUS mendukung implementasi EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB, dan EFFECT_TYPE_VIRTUALIZER yang dapat dikontrol melalui subclass AudioEffect BassBoost, EnvironmentalReverb, PresetReverb, dan Virtualizer.

5.5.3. Volume Output Audio

Implementasi perangkat otomotif:

  • HARUS memungkinkan penyesuaian volume audio secara terpisah untuk setiap streaming audio menggunakan jenis konten atau penggunaan seperti yang ditentukan oleh AudioAttributes dan penggunaan audio mobil seperti yang ditentukan secara publik di android.car.CarAudioManager.

5.6. Latensi Audio

Latensi audio adalah penundaan waktu saat sinyal audio melewati sistem. Banyak class aplikasi mengandalkan latensi yang singkat, untuk mencapai efek suara real-time.

Untuk tujuan bagian ini, gunakan definisi berikut:

  • latensi output. Interval antara saat aplikasi menulis frame data yang dienkode PCM dan saat suara yang sesuai ditampilkan ke lingkungan di transduser di perangkat atau sinyal keluar dari perangkat melalui port dan dapat diamati secara eksternal.
  • latensi output dingin. Latensi output untuk frame pertama, saat sistem output audio tidak ada aktivitas dan dimatikan sebelum permintaan.
  • latensi output berkelanjutan. Latensi output untuk frame berikutnya, setelah perangkat memutar audio.
  • latensi input. Interval antara saat suara ditampilkan oleh lingkungan ke perangkat di transduser di perangkat atau sinyal memasuki perangkat melalui port dan saat aplikasi membaca frame data berkode PCM yang sesuai.
  • input hilang. Bagian awal sinyal input yang tidak dapat digunakan atau tidak tersedia.
  • latensi input dingin. Jumlah waktu input yang hilang dan latensi input untuk frame pertama, saat sistem input audio tidak ada aktivitas dan dimatikan sebelum permintaan.
  • latensi input berkelanjutan. Latensi input untuk frame berikutnya, saat perangkat merekam audio.
  • jitter output dingin. Variabilitas di antara pengukuran terpisah dari nilai latensi output dingin.
  • jitter input dingin. Variabilitas di antara pengukuran terpisah dari nilai latensi input dingin.
  • latensi bolak-balik berkelanjutan. Jumlah latensi input berkelanjutan ditambah latensi output berkelanjutan ditambah satu periode buffering. Periode buffering memungkinkan waktu bagi aplikasi untuk memproses sinyal dan waktu bagi aplikasi untuk mengurangi perbedaan fase antara aliran input dan output.
  • OpenSL ES PCM buffer queue API. Kumpulan OpenSL ES API terkait PCM dalam Android NDK.
  • API audio native AAudio. Kumpulan API AAudio dalam Android NDK.
  • Stempel waktu. Pasangan yang terdiri dari posisi frame relatif dalam streaming dan perkiraan waktu saat frame tersebut memasuki atau keluar dari pipeline pemrosesan audio di endpoint terkait. Lihat juga AudioTimestamp.

Jika implementasi perangkat mendeklarasikan android.hardware.audio.output, SEBAIKNYA penuhi atau melebihi persyaratan berikut:

  • [C-SR] Latensi output cold sebesar 100 milidetik atau kurang
  • [C-SR] Latensi output berkelanjutan sebesar 45 milidetik atau kurang
  • [C-SR] Meminimalkan jitter output dingin
  • [C-SR] Stempel waktu output yang ditampilkan oleh AudioTrack.getTimestamp dan AAudioStream_getTimestamp akurat hingga +/- 1 md.

Jika implementasi perangkat memenuhi persyaratan di atas, setelah kalibrasi awal, saat menggunakan antrean buffer PCM OpenSL ES dan API audio native AAudio, untuk latensi output berkelanjutan dan latensi output dingin di setidaknya satu perangkat output audio yang didukung, keduanya adalah:

Jika implementasi perangkat tidak memenuhi persyaratan untuk audio latensi rendah melalui antrean buffer PCM OpenSL ES dan API audio native AAudio, implementasi tersebut:

  • [C-1-1] TIDAK BOLEH melaporkan dukungan untuk audio latensi rendah.

Jika implementasi perangkat menyertakan android.hardware.microphone, SEBAIKNYA implementasi tersebut memenuhi persyaratan audio input berikut:

  • [C-SR] Latensi input cold 100 milidetik atau kurang.
  • [C-SR] Latensi input kontinu sebesar 30 milidetik atau kurang.
  • [C-SR] Latensi bolak-balik berkelanjutan sebesar 50 milidetik atau kurang.
  • [C-SR] Meminimalkan jitter input dingin.
  • [C-SR] Membatasi error dalam stempel waktu input, seperti yang ditampilkan oleh AudioRecord.getTimestamp atau AAudioStream_getTimestamp, menjadi +/- 1 md.

5.7. Protokol Jaringan

Implementasi perangkat HARUS mendukung protokol jaringan media untuk pemutaran audio dan video seperti yang ditentukan dalam dokumentasi Android SDK.

Jika implementasi perangkat menyertakan dekoder audio atau video, implementasi tersebut:

  • [C-1-1] HARUS mendukung semua codec dan format penampung yang diperlukan di bagian 5.1 melalui HTTP(S).

  • [C-1-2] HARUS mendukung format segmen media yang ditampilkan dalam tabel Format Segmen Media di bawah melalui protokol draf HTTP Live Streaming, Versi 7.

  • [C-1-3] HARUS mendukung profil video audio RTP berikut dan codec terkait dalam tabel RTSP di bawah. Untuk pengecualian, lihat catatan kaki tabel di bagian 5.1.

Format Segmen Media

Format segmen Referensi Dukungan codec yang diperlukan
MPEG-2 Transport Stream ISO 13818 Codec video:
  • H264 AVC
  • MPEG-4 SP
  • MPEG-2
Lihat bagian 5.1.3 untuk mengetahui detail tentang H264 AVC, MPEG2-4 SP,
, dan MPEG-2.

Codec audio:

  • AAC
Lihat bagian 5.1.1 untuk mengetahui detail tentang AAC dan variannya.
AAC dengan framing ADTS dan tag ID3 ISO 13818-7 Lihat bagian 5.1.1 untuk mengetahui detail tentang AAC dan variannya
WebVTT WebVTT

RTSP (RTP, SDP)

Nama profil Referensi Dukungan codec yang diperlukan
H264 AVC RFC 6184 Lihat bagian 5.1.3 untuk mengetahui detail tentang H264 AVC
MP4A-LATM RFC 6416 Lihat bagian 5.1.1 untuk mengetahui detail tentang AAC dan variannya
H263-1998 RFC 3551
RFC 4629
RFC 2190 		Lihat bagian 5.1.3 untuk mengetahui detail tentang H263
H263-2000 RFC 4629 Lihat bagian 5.1.3 untuk mengetahui detail tentang H263
AMR RFC 4867 Lihat bagian 5.1.1 untuk mengetahui detail tentang AMR-NB
AMR-WB RFC 4867 Lihat bagian 5.1.1 untuk mengetahui detail tentang AMR-WB
MP4V-ES RFC 6416 Lihat bagian 5.1.3 untuk mengetahui detail tentang MPEG-4 SP
mpeg4-generic RFC 3640 Lihat bagian 5.1.1 untuk mengetahui detail tentang AAC dan variannya
MP2T RFC 2250 Lihat MPEG-2 Transport Stream di bawah HTTP Live Streaming untuk mengetahui detailnya

5,8. Media Aman

Jika implementasi perangkat mendukung output video aman dan mampu mendukung platform aman, perangkat tersebut:

  • [C-1-1] HARUS mendeklarasikan dukungan untuk Display.FLAG_SECURE.

Jika penerapan perangkat mendeklarasikan dukungan untuk Display.FLAG_SECURE dan mendukung protokol tampilan nirkabel, penerapan tersebut:

  • [C-2-1] HARUS mengamankan link dengan mekanisme yang kuat secara kriptografis seperti HDCP 2.x atau yang lebih tinggi untuk layar yang terhubung melalui protokol nirkabel seperti Miracast.

Jika implementasi perangkat mendeklarasikan dukungan untuk Display.FLAG_SECURE dan mendukung layar eksternal berkabel, implementasi tersebut:

  • [C-3-1] HARUS mendukung HDCP 1.2 atau yang lebih baru untuk semua layar eksternal yang terhubung melalui port berkabel yang dapat diakses pengguna.

5.9. Musical Instrument Digital Interface (MIDI)

Jika implementasi perangkat melaporkan dukungan untuk fitur android.software.midi melalui class android.content.pm.PackageManager, implementasi tersebut:

  • [C-1-1] HARUS mendukung MIDI melalui semua transpor hardware yang kompatibel dengan MIDI yang menyediakan konektivitas non-MIDI generik, dengan transpor tersebut adalah:

  • [C-1-2] HARUS mendukung transpor software MIDI antar-aplikasi (perangkat MIDI virtual)

5.10. Audio Profesional

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

  • [C-1-1] HARUS melaporkan dukungan untuk fitur android.hardware.audio.low_latency.
  • [C-1-2] HARUS memiliki latensi audio bolak-balik yang berkelanjutan, seperti yang ditentukan dalam bagian 5.6 Latensi Audio, HARUS 20 milidetik atau kurang dan HARUS 10 milidetik atau kurang melalui setidaknya satu jalur yang didukung.
  • [C-1-3] HARUS menyertakan port USB yang mendukung mode host USB dan mode periferal USB.
  • [C-1-4] HARUS melaporkan dukungan untuk fitur android.software.midi.
  • [C-1-5] HARUS memenuhi latensi dan persyaratan audio USB menggunakan antrean buffer PCM OpenSL ES dan API audio native AAudio.
  • [SR] SANGAT DIUJAMI untuk memberikan tingkat performa CPU yang konsisten saat audio aktif dan beban CPU bervariasi. Ini harus diuji menggunakan commit SimpleSynth 1bd6391. Aplikasi SimpleSynth harus dijalankan dengan parameter di bawah dan mencapai nol underrun setelah 10 menit:
    • Siklus kerja: 200.000
    • Beban variabel: AKTIF (ini akan beralih antara 100% dan 10% dari nilai siklus kerja setiap 2 detik dan dirancang untuk menguji perilaku pengontrol CPU)
    • Beban stabil: NONAKTIF
  • HARUS meminimalkan ketidakakuratan dan penyimpangan jam audio relatif terhadap waktu standar.
  • HARUS meminimalkan drift clock audio relatif terhadap CLOCK_MONOTONIC CPU saat keduanya aktif.
  • HARUS meminimalkan latensi audio melalui transduser di perangkat.
  • HARUS meminimalkan latensi audio melalui audio digital USB.
  • HARUS mendokumentasikan pengukuran latensi audio di semua jalur.
  • HARUS meminimalkan jitter dalam waktu entri callback penyelesaian buffering audio, karena hal ini memengaruhi persentase bandwidth CPU penuh yang dapat digunakan oleh callback.
  • HARUS memberikan nol underrun audio (output) atau overrun (input) dalam penggunaan normal pada latensi yang dilaporkan.
  • HARUS memberikan perbedaan latensi antar-saluran nol.
  • HARUS meminimalkan latensi rata-rata MIDI di semua transpor.
  • HARUS meminimalkan variabilitas latensi MIDI saat beban (jitter) di semua transpor.
  • HARUS memberikan stempel waktu MIDI yang akurat di semua transpor.
  • HARUS meminimalkan derau sinyal audio melalui transduser di perangkat, termasuk periode segera setelah cold start.
  • HARUS memberikan perbedaan clock audio nol antara sisi input dan output dari endpoint yang sesuai, jika keduanya aktif. Contoh endpoint yang sesuai mencakup mikrofon dan speaker di perangkat, atau input dan output jack audio.
  • HARUS menangani callback penyelesaian buffer audio untuk sisi input dan output dari endpoint yang sesuai pada thread yang sama saat keduanya aktif, dan segera masukkan callback output setelah kembali dari callback input. Atau, jika tidak memungkinkan untuk menangani callback pada thread yang sama, masukkan callback output segera setelah memasukkan callback input untuk memungkinkan aplikasi memiliki pengaturan waktu yang konsisten di sisi input dan output.
  • HARUS meminimalkan perbedaan fase antara buffering audio HAL untuk sisi input dan output dari endpoint yang sesuai.
  • HARUS meminimalkan latensi sentuh.
  • HARUS meminimalkan variabilitas latensi sentuh saat beban (jitter).
  • HARUS memiliki latensi dari input sentuh ke output audio kurang dari atau sama dengan 40 md.

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

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

Jika implementasi perangkat menghilangkan jack audio 3,5 mm 4 konduktor dan menyertakan port USB yang mendukung mode host USB, perangkat tersebut:

  • [C-3-1] HARUS menerapkan class audio USB.
  • [C-3-2] HARUS memiliki latensi audio bolak-balik kontinu sebesar 20 milidetik atau kurang melalui port mode host USB menggunakan class audio USB.
  • Latensi audio bolak-balik berkelanjutan HARUS 10 milidetik atau kurang melalui port mode host USB menggunakan class audio USB.

Jika implementasi perangkat menyertakan port HDMI, perangkat tersebut:

  • [C-4-1] HARUS mendukung output dalam stereo dan delapan saluran dengan kedalaman 20-bit atau 24-bit dan 192 kHz tanpa kehilangan kedalaman bit atau pengambilan sampel ulang, dalam minimal satu konfigurasi.

5.11. Capture for Unprocessed

Android menyertakan dukungan untuk merekam audio yang belum diproses melalui sumber audio android.media.MediaRecorder.AudioSource.UNPROCESSED. Di OpenSL ES, ini dapat diakses dengan preset rekaman SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

Jika implementasi perangkat bermaksud mendukung sumber audio yang belum diproses dan menyediakannya untuk aplikasi pihak ketiga, implementasi tersebut:

  • [C-1-1] HARUS melaporkan dukungan melalui properti android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.

  • [C-1-2] HARUS menunjukkan karakteristik amplitudo versus frekuensi yang hampir datar dalam rentang frekuensi menengah: khususnya ±10 dB dari 100 Hz hingga 7.000 Hz untuk setiap mikrofon yang digunakan untuk merekam sumber audio yang belum diproses.

  • [C-1-3] HARUS menunjukkan level amplitudo dalam rentang frekuensi rendah: khususnya dari ±20 dB dari 5 Hz hingga 100 Hz dibandingkan dengan rentang frekuensi menengah untuk setiap mikrofon yang digunakan untuk merekam sumber audio yang belum diproses.

  • [C-1-4] HARUS menunjukkan level amplitudo dalam rentang frekuensi tinggi: khususnya dari ±30 dB dari 7.000 Hz hingga 22 KHz dibandingkan dengan rentang frekuensi menengah untuk setiap mikrofon yang digunakan untuk merekam sumber audio yang belum diproses.

  • [C-1-5] HARUS menyetel sensitivitas input audio sehingga sumber nada sinus 1000 Hz yang diputar pada Tingkat Tekanan Suara (SPL) 94 dB menghasilkan respons dengan RMS 520 untuk sampel 16 bit (atau -36 dB Skala Penuh untuk sampel floating point/presisi ganda) untuk setiap mikrofon yang digunakan untuk merekam sumber audio yang belum diproses.

  • [C-1-6] HARUS memiliki rasio sinyal-ke-derau (SNR) sebesar 60 dB atau lebih tinggi untuk setiap mikrofon yang digunakan untuk merekam sumber audio yang belum diproses. (sedangkan SNR diukur sebagai perbedaan antara 94 dB SPL dan SPL setara dari derau sendiri, dengan bobot A).

  • [C-1-7] HARUS memiliki total harmonic distortion (THD) kurang dari 1% untuk 1 kHz pada level input SPL 90 dB di setiap mikrofon yang digunakan untuk merekam sumber audio yang belum diproses.

  • TIDAK BOLEH memiliki pemrosesan sinyal lain (misalnya Automatic Gain Control, High Pass Filter, atau Echo cancellation) di jalur selain pengganda level untuk membawa level ke rentang yang diinginkan. Dengan kata lain:

  • [C-1-8] Jika ada pemrosesan sinyal dalam arsitektur karena alasan apa pun, pemrosesan sinyal tersebut HARUS dinonaktifkan dan secara efektif tidak menimbulkan penundaan atau latensi tambahan pada jalur sinyal.
  • [C-1-9] Pengganda level, meskipun diizinkan berada di jalur, TIDAK BOLEH menyebabkan penundaan atau latensi pada jalur sinyal.

Semua pengukuran SPL dilakukan langsung di samping mikrofon yang sedang diuji. Untuk beberapa konfigurasi mikrofon, persyaratan ini berlaku untuk setiap mikrofon.

Jika implementasi perangkat mendeklarasikan android.hardware.microphone tetapi tidak mendukung sumber audio yang tidak diproses, implementasi tersebut:

  • [C-2-1] HARUS menampilkan null untuk metode AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) API, untuk menunjukkan kurangnya dukungan dengan benar.
  • [SR] masih SANGAT DIUJI untuk memenuhi sebanyak mungkin persyaratan untuk jalur sinyal untuk sumber rekaman yang belum diproses.

6. Kompatibilitas Alat dan Opsi Developer

6.1. Alat Pengembang

Implementasi perangkat:

  • [C-0-1] HARUS mendukung Android Developer Tools yang disediakan di Android SDK.

  • Android Debug Bridge (adb)

    • [C-0-2] HARUS mendukung adb seperti yang didokumentasikan dalam Android SDK dan perintah shell yang disediakan di AOSP, yang dapat digunakan oleh developer aplikasi, termasuk dumpsys dan cmd stats.
    • [C-0-3] TIDAK BOLEH mengubah format atau konten peristiwa sistem perangkat (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) yang dicatat ke dalam log melalui perintah dumpsys.
    • [C-0-10] HARUS merekam, tanpa kelalaian, dan membuat peristiwa berikut dapat diakses dan tersedia untuk perintah shell cmd stats dan class System API StatsManager.
      • ActivityForegroundStateChanged
      • AnomalyDetected
      • AppBreadcrumbReported
      • AppCrashOccurred
      • AppStartOccurred
      • BatteryLevelChanged
      • BatterySaverModeStateChanged
      • BleScanResultReceived
      • BleScanStateChanged
      • ChargingStateChanged
      • DeviceIdleModeStateChanged
      • ForegroundServiceStateChanged
      • GpsScanStateChanged
      • JobStateChanged
      • PluggedStateChanged
      • ScheduledJobStateChanged
      • ScreenStateChanged
      • SyncStateChanged
      • SystemElapsedRealtime
      • UidProcessStateChanged
      • WakelockStateChanged
      • WakeupAlarmOccurred
      • WifiLockStateChanged
      • WifiMulticastLockStateChanged
      • WifiScanStateChanged
    • [C-0-4] HARUS memiliki daemon adb sisi perangkat yang tidak aktif secara default dan HARUS ada mekanisme yang dapat diakses pengguna untuk mengaktifkan Android Debug Bridge.
    • [C-0-5] HARUS mendukung adb aman. Android menyertakan dukungan untuk adb aman. adb aman mengaktifkan adb di host terautentikasi yang diketahui.

    • [C-0-6] HARUS menyediakan mekanisme yang memungkinkan adb terhubung dari mesin host. Contoh:

      • Implementasi perangkat tanpa port USB yang mendukung mode periferal HARUS menerapkan adb melalui jaringan area lokal (seperti Ethernet atau Wi-Fi).
      • HARUS menyediakan driver untuk Windows 7, 9, dan 10, yang memungkinkan developer terhubung ke perangkat menggunakan protokol adb.

  • Dalvik Debug Monitor Service (ddms)

    • [C-0-7] HARUS mendukung semua fitur ddms seperti yang didokumentasikan di Android SDK. Karena ddm menggunakan adb, dukungan untuk ddm HARUS tidak aktif secara default, tetapi HARUS didukung setiap kali pengguna mengaktifkan Android Debug Bridge, seperti di atas.
  • Monkey
    • [C-0-8] HARUS menyertakan framework Monkey dan menyediakannya untuk digunakan aplikasi.
  • SysTrace
    • [C-0-9] HARUS mendukung alat systrace seperti yang didokumentasikan dalam Android SDK. Systrace harus tidak aktif secara default dan HARUS ada mekanisme yang dapat diakses pengguna untuk mengaktifkan Systrace.

Jika implementasi perangkat melaporkan dukungan Vulkan 1.0 atau yang lebih tinggi melalui flag fitur android.hardware.vulkan.version, implementasi tersebut:

  • [C-1-1] HARUS menyediakan kemampuan bagi developer aplikasi untuk mengaktifkan/menonaktifkan lapisan debug GPU.
  • [C-1-2] HARUS, saat lapisan debug GPU diaktifkan, enumerasi lapisan dalam library yang disediakan oleh alat eksternal (yaitu bukan bagian dari platform atau paket aplikasi) yang ditemukan di direktori dasar aplikasi yang dapat di-debug untuk mendukung metode API vkEnumerateInstanceLayerProperties() dan vkCreateInstance().

6.2. Opsi Developer

Android menyertakan dukungan bagi developer untuk mengonfigurasi setelan terkait pengembangan aplikasi.

Implementasi perangkat HARUS memberikan pengalaman yang konsisten untuk Opsi Developer, yaitu:

  • [C-0-1] HARUS mematuhi intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS untuk menampilkan setelan terkait pengembangan aplikasi. Implementasi Android upstream menyembunyikan menu Opsi Developer secara default dan memungkinkan pengguna meluncurkan Opsi Developer setelah menekan tujuh (7) kali pada item menu Setelan > Tentang Perangkat > Nomor Versi.
  • [C-0-2] HARUS menyembunyikan Opsi Developer secara default.
  • [C-0-3] HARUS menyediakan mekanisme yang jelas yang tidak memberikan perlakuan preferensial kepada satu aplikasi pihak ketiga dibandingkan dengan aplikasi pihak ketiga lainnya untuk mengaktifkan Opsi Developer. HARUS memberikan dokumen atau situs yang dapat dilihat publik yang menjelaskan cara mengaktifkan Opsi Developer. Dokumen atau situs ini HARUS dapat ditautkan dari dokumen Android SDK.
  • HARUS memiliki notifikasi visual yang berkelanjutan kepada pengguna saat Opsi Developer diaktifkan dan keamanan pengguna menjadi perhatian.
  • DAPAT membatasi akses ke menu Opsi Developer untuk sementara, dengan menyembunyikan atau menonaktifkan menu secara visual, untuk mencegah gangguan pada skenario yang menyangkut keamanan pengguna.

7. Kompatibilitas Hardware

Jika perangkat menyertakan komponen hardware tertentu yang memiliki API yang sesuai untuk developer pihak ketiga:

  • [C-0-1] Implementasi perangkat HARUS menerapkan API tersebut seperti yang dijelaskan dalam dokumentasi Android SDK.

Jika API di SDK berinteraksi dengan komponen hardware yang dinyatakan sebagai opsional dan implementasi perangkat tidak memiliki komponen tersebut:

  • [C-0-2] Definisi class lengkap (seperti yang didokumentasikan oleh SDK) untuk API komponen HARUS tetap ditampilkan.
  • [C-0-3] Perilaku API HARUS diterapkan sebagai no-ops dengan cara yang wajar.
  • [C-0-4] Metode API HARUS menampilkan nilai null jika diizinkan oleh dokumentasi SDK.
  • [C-0-5] Metode API HARUS menampilkan implementasi no-op class jika nilai null tidak diizinkan oleh dokumentasi SDK.
  • [C-0-6] Metode API TIDAK BOLEH menampilkan pengecualian yang tidak didokumentasikan oleh dokumentasi SDK.
  • [C-0-7] Implementasi perangkat HARUS secara konsisten melaporkan informasi konfigurasi hardware yang akurat melalui metode getSystemAvailableFeatures() dan hasSystemFeature(String) di class android.content.pm.PackageManager untuk sidik jari build yang sama.

Contoh umum skenario penerapan persyaratan ini adalah API telephony: Bahkan di perangkat non-ponsel, API ini harus diimplementasikan sebagai no-op yang wajar.

7.1. Layar dan Grafis

Android menyertakan fasilitas yang secara otomatis menyesuaikan aset aplikasi dan tata letak UI dengan tepat untuk perangkat guna memastikan aplikasi pihak ketiga berjalan dengan baik di berbagai konfigurasi hardware. Perangkat HARUS menerapkan API dan perilaku ini dengan benar, seperti yang dijelaskan di bagian ini.

Unit yang dirujuk oleh persyaratan di bagian ini ditentukan sebagai berikut:

  • ukuran diagonal fisik. Jarak dalam inci antara dua sudut yang berlawanan dari bagian layar yang diterangi.
  • titik per inci (dpi). Jumlah piksel yang dicakup oleh rentang horizontal atau vertikal linear 1”. Jika nilai dpi tercantum, dpi horizontal dan vertikal harus berada dalam rentang.
  • rasio aspek. Rasio piksel dimensi yang lebih panjang dengan dimensi layar yang lebih pendek. Misalnya, layar 480x854 piksel akan menjadi 854/480 = 1,779, atau kira-kira “16:9”.
  • piksel kepadatan mandiri (dp). Satuan piksel virtual yang dinormalisasi ke layar 160 dpi, dihitung sebagai: piksel = dp * (kepadatan/160).

7.1.1. Konfigurasi Layar

7.1.1.1. Ukuran dan Bentuk Layar

Framework UI Android mendukung berbagai ukuran tata letak layar logis, dan memungkinkan aplikasi mengkueri ukuran tata letak layar konfigurasi saat ini melalui Configuration.screenLayout dengan SCREENLAYOUT_SIZE_MASK dan Configuration.smallestScreenWidthDp.

Implementasi perangkat:

  • [C-0-1] HARUS melaporkan ukuran tata letak yang benar untuk Configuration.screenLayout seperti yang ditentukan dalam dokumentasi Android SDK. Secara khusus, implementasi perangkat HARUS melaporkan dimensi layar piksel kepadatan mandiri (dp) logis yang benar seperti di bawah ini:

    • Perangkat dengan Configuration.uiMode yang ditetapkan sebagai nilai apa pun selain UI_MODE_TYPE_WATCH, dan melaporkan ukuran small untuk Configuration.screenLayout, HARUS memiliki setidaknya 426 dp x 320 dp.
    • Perangkat yang melaporkan ukuran normal untuk Configuration.screenLayout, HARUS memiliki setidaknya 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 mematuhi dukungan yang dinyatakan aplikasi untuk ukuran layar dengan benar melalui atribut <supports-screens> di AndroidManifest.xml, seperti yang dijelaskan dalam dokumentasi Android SDK.

  • DAPAT memiliki layar dengan sudut membulat.

Jika implementasi perangkat mendukung UI_MODE_TYPE_NORMAL dan menyertakan layar dengan sudut membulat, perangkat tersebut:

  • [C-1-1] HARUS memastikan bahwa radius sudut membulat kurang dari atau sama dengan 38 dp.
  • HARUS menyertakan kemampuan pengguna untuk beralih ke mode tampilan dengan sudut persegi panjang.
7.1.1.2. Rasio Aspek Layar

Meskipun tidak ada batasan untuk nilai rasio aspek layar dari tampilan layar fisik, rasio aspek layar dari tampilan logis yang digunakan untuk merender aplikasi pihak ketiga, seperti yang dapat berasal dari nilai tinggi dan lebar yang dilaporkan melalui view.Display API dan Configuration API, HARUS memenuhi persyaratan berikut:

  • [C-0-1] Implementasi perangkat dengan Configuration.uiMode yang ditetapkan sebagai UI_MODE_TYPE_NORMAL HARUS memiliki nilai rasio aspek antara 1,3333 (4:3) dan 1,86 (kira-kira 16:9), kecuali jika aplikasi dapat dianggap siap diregangkan lebih lama dengan memenuhi salah satu kondisi berikut:

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

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

7.1.1.3. Kepadatan Layar

Framework UI Android menentukan serangkaian kepadatan logis standar untuk membantu developer aplikasi menargetkan resource aplikasi.

  • [C-0-1] Secara default, implementasi perangkat HARUS hanya melaporkan salah satu kepadatan framework Android logis berikut melalui API DENSITY_DEVICE_STABLE dan nilai ini TIDAK BOLEH berubah kapan saja; Namun, perangkat DAPAT melaporkan kepadatan arbitrer yang berbeda sesuai dengan perubahan konfigurasi tampilan yang dilakukan oleh pengguna (misalnya, ukuran tampilan) yang ditetapkan setelah booting awal.

    • 120 dpi (ldpi)
    • 160 dpi (mdpi)
    • 213 dpi (tvdpi)
    • 240 dpi (hdpi)
    • 260 dpi (260dpi)
    • 280 dpi (280dpi)
    • 300 dpi (300dpi)
    • 320 dpi (xhdpi)
    • 340 dpi (340dpi)
    • 360 dpi (360dpi)
    • 400 dpi (400dpi)
    • 420 dpi (420dpi)
    • 480 dpi (xxhdpi)
    • 560 dpi (560dpi)
    • 640 dpi (xxxhdpi)

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

Jika ada kemampuan untuk mengubah ukuran tampilan perangkat:

  • [C-1-1] Ukuran tampilan TIDAK BOLEH diskalakan lebih besar dari 1,5 kali kepadatan native atau menghasilkan dimensi layar minimum efektif yang lebih kecil dari 320dp (setara dengan penentu resource sw320dp), mana saja yang lebih dulu.
  • [C-1-2] Ukuran layar TIDAK BOLEH diskalakan lebih kecil dari 0,85 kali kepadatan native.
  • Untuk memastikan kegunaan yang baik dan ukuran font yang konsisten, DISARANKAN agar penskalaan opsi Tampilan Native berikut disediakan (sambil 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 output layar atau video, implementasi tersebut:

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

  • [C-2-1] HARUS melaporkan nilai yang wajar untuk semua metrik tampilan yang ditentukan di 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 orientasi yang didukung. Misalnya, perangkat dengan layar lanskap orientasi tetap, seperti televisi atau laptop, HANYA BOLEH melaporkan android.hardware.screen.landscape.
  • [C-0-2] HARUS melaporkan nilai yang benar untuk orientasi perangkat saat ini, setiap kali dikueri melalui android.content.res.Configuration.orientation, android.view.Display.getOrientation(), atau API lainnya.

Jika implementasi perangkat mendukung kedua orientasi layar, implementasi tersebut:

  • [C-1-1] HARUS mendukung orientasi dinamis oleh aplikasi ke orientasi layar potret atau lanskap. Artinya, perangkat harus mematuhi permintaan aplikasi untuk orientasi layar tertentu.
  • [C-1-2] TIDAK BOLEH mengubah ukuran atau kepadatan layar yang dilaporkan saat mengubah orientasi.
  • DAPAT memilih orientasi potret atau lanskap sebagai default.

7.1.4. Akselerasi Grafis 2D dan 3D

7.1.4.1 OpenGL ES

Implementasi perangkat:

  • [C-0-1] HARUS mengidentifikasi versi OpenGL ES yang didukung (1.1, 2.0, 3.0, 3.1, 3.2) dengan benar melalui API terkelola (seperti melalui metode GLES10.getString()) dan API native.
  • [C-0-2] HARUS menyertakan dukungan untuk semua API terkelola dan API native yang sesuai untuk setiap versi OpenGL ES yang diidentifikasi untuk didukung.

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

  • [C-1-1] HARUS mendukung OpenGL ES 1.1 dan 2.0, seperti yang diwujudkan dan dijelaskan dalam dokumentasi Android SDK.
  • [SR] SANGAT DIUJAMI untuk mendukung OpenGL ES 3.1.
  • HARUS mendukung OpenGL ES 3.2.

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

  • [C-2-1] HARUS melaporkan melalui API yang dikelola OpenGL ES dan API native setiap ekstensi OpenGL ES lain yang telah diimplementasikan, dan sebaliknya TIDAK BOLEH melaporkan string ekstensi yang tidak didukung.
  • [C-2-2] HARUS mendukung ekstensi EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, dan EGL_ANDROID_recordable.
  • [SR] SANGAT DISARANKAN untuk mendukung EGL_KHR_partial_update.
  • HARUS melaporkan secara akurat melalui metode getString(), format kompresi tekstur apa pun yang didukungnya, yang biasanya khusus vendor.

Jika implementasi perangkat mendeklarasikan dukungan untuk OpenGL ES 3.0, 3.1, atau 3.2, implementasi tersebut:

  • [C-3-1] HARUS mengekspor simbol fungsi yang sesuai untuk versi ini selain simbol fungsi OpenGL ES 2.0 di library libGLESv2.so.

Jika implementasi perangkat mendukung OpenGL ES 3.2, implementasi tersebut:

  • [C-4-1] HARUS mendukung OpenGL ES Android Extension Pack secara keseluruhan.

Jika implementasi perangkat mendukung Android Extension Pack OpenGL ES secara keseluruhan, implementasi tersebut:

  • [C-5-1] HARUS mengidentifikasi dukungan melalui flag fitur android.hardware.opengles.aep.

Jika penerapan perangkat mengekspos dukungan untuk ekstensi EGL_KHR_mutable_render_buffer, penerapan tersebut:

  • [C-6-1] JUGA HARUS mendukung ekstensi EGL_ANDROID_front_buffer_auto_refresh.
Vulkan 7.1.4.2

Android menyertakan dukungan untuk Vulkan, API lintas platform dengan overhead rendah untuk grafis 3D berperforma tinggi.

Jika implementasi perangkat mendukung OpenGL ES 3.1, implementasi tersebut:

  • [SR] SANGAT DISARANKAN untuk menyertakan dukungan untuk Vulkan 1.1.

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

  • HARUS menyertakan dukungan untuk Vulkan 1.1.

Jika implementasi perangkat menyertakan dukungan untuk Vulkan 1.0, implementasi tersebut:

  • [C-1-1] HARUS melaporkan nilai bilangan bulat yang benar dengan flag fitur android.hardware.vulkan.level dan android.hardware.vulkan.version.
  • [C-1-2] HARUS mengenumerasi, setidaknya satu VkPhysicalDevice untuk API native Vulkan vkEnumeratePhysicalDevices() .
  • [C-1-3] HARUS menerapkan API Vulkan 1.0 sepenuhnya untuk setiap VkPhysicalDevice yang dihitung.
  • [C-1-4] HARUS menghitung lapisan, yang terdapat dalam library native yang dinamai sebagai libVkLayer*.so di direktori library native paket aplikasi, melalui API native Vulkan vkEnumerateInstanceLayerProperties() dan vkEnumerateDeviceLayerProperties() .
  • [C-1-5] TIDAK BOLEH menghitung lapisan yang disediakan oleh library di luar paket aplikasi, atau memberikan cara lain untuk melacak atau mencegat Vulkan API, kecuali jika aplikasi memiliki atribut android:debuggable yang ditetapkan sebagai true.
  • [C-1-6] HARUS melaporkan semua string ekstensi yang didukung melalui API native Vulkan , dan sebaliknya TIDAK BOLEH melaporkan string ekstensi yang tidak didukung dengan benar.
  • [C-1-7] HARUS mendukung ekstensi VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, dan VK_KHR_incremental_present.

Jika implementasi perangkat tidak menyertakan dukungan untuk Vulkan 1.0, implementasi tersebut:

  • [C-2-1] TIDAK BOLEH mendeklarasikan flag fitur Vulkan apa pun (misalnya, android.hardware.vulkan.level, android.hardware.vulkan.version).
  • [C-2-2] TIDAK BOLEH menghitung VkPhysicalDevice untuk vkEnumeratePhysicalDevices() API native Vulkan.

Jika implementasi perangkat menyertakan dukungan untuk Vulkan 1.1, implementasi tersebut:

  • [C-3-1] HARUS mengekspos dukungan untuk jenis semaphore dan handle eksternal SYNC_FD.
  • [SR] SANGAT DIUJAMI untuk mendukung ekstensi VK_ANDROID_external_memory_android_hardware_buffer.
7.1.4.3 RenderScript
  • [C-0-1] Implementasi perangkat HARUS mendukung Android RenderScript, seperti yang dijelaskan dalam dokumentasi Android SDK.
7.1.4.4 Akselerasi Grafis 2D

Android menyertakan mekanisme bagi aplikasi untuk mendeklarasikan bahwa aplikasi ingin mengaktifkan akselerasi hardware untuk grafis 2D di tingkat Aplikasi, Aktivitas, Jendela, atau Tampilan melalui penggunaan tag manifes android:hardwareAccelerated atau panggilan API langsung.

Implementasi perangkat:

  • [C-0-1] HARUS mengaktifkan akselerasi hardware secara default, dan HARUS menonaktifkan akselerasi hardware jika developer memintanya dengan menetapkan android:hardwareAccelerated="false” atau menonaktifkan akselerasi hardware secara langsung melalui Android View API.
  • [C-0-2] HARUS menunjukkan perilaku yang konsisten dengan dokumentasi Android SDK tentang akselerasi hardware.

Android menyertakan objek TextureView yang memungkinkan developer mengintegrasikan tekstur OpenGL ES yang dipercepat hardware secara langsung sebagai target rendering dalam hierarki UI.

Implementasi perangkat:

  • [C-0-3] HARUS mendukung TextureView API, dan HARUS menunjukkan perilaku yang konsisten dengan implementasi Android upstream.
7.1.4.5 Layar Rentang warna lebar

Jika implementasi perangkat mengklaim dukungan untuk layar wide-gamut melalui Configuration.isScreenWideColorGamut() , implementasi tersebut:

  • [C-1-1] HARUS memiliki layar yang dikalibrasi warna.
  • [C-1-2] HARUS memiliki layar yang gamutnya mencakup gamut warna sRGB sepenuhnya dalam ruang xyY CIE 1931.
  • [C-1-3] HARUS memiliki layar yang gamutnya memiliki area minimal 90% DCI-P3 dalam ruang xyY CIE 1931.
  • [C-1-4] HARUS mendukung OpenGL ES 3.1 atau 3.2 dan melaporkannya dengan benar.
  • [C-1-5] HARUS mengiklankan dukungan untuk ekstensi EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, dan EGL_KHR_gl_colorspace_display_p3.
  • [SR] SANGAT DISARANKAN untuk mendukung GL_EXT_sRGB.

Sebaliknya, jika implementasi perangkat tidak mendukung layar gamut lebar, perangkat tersebut:

  • [C-2-1] HARUS mencakup 100% atau lebih sRGB dalam ruang xyY CIE 1931, meskipun gamut warna layar tidak ditentukan.

7.1.5. Mode Kompatibilitas Aplikasi Lama

Android menentukan “mode kompatibilitas” tempat framework beroperasi dalam mode ukuran layar 'normal' yang setara (lebar 320 dp) untuk kepentingan aplikasi lama yang tidak dikembangkan untuk versi Android lama yang sudah ada sebelum independensi ukuran layar.

7.1.6. Teknologi Layar

Platform Android menyertakan API yang memungkinkan aplikasi merender grafik yang kaya ke layar. Perangkat HARUS mendukung semua API ini seperti yang ditentukan oleh Android SDK, kecuali jika secara khusus diizinkan dalam dokumen ini.

Implementasi perangkat:

  • [C-0-1] HARUS mendukung layar yang mampu merender grafis warna 16-bit.
  • HARUS mendukung layar yang mampu menampilkan grafis warna 24-bit.
  • [C-0-2] HARUS mendukung layar yang mampu merender animasi.
  • [C-0-3] HARUS menggunakan teknologi layar yang memiliki rasio aspek piksel (PAR) antara 0,9 dan 1,15. Artinya, rasio aspek piksel HARUS mendekati persegi (1,0) dengan toleransi 10 ~ 15%.

7.1.7. Layar Sekunder

Android menyertakan dukungan untuk layar sekunder guna mengaktifkan kemampuan berbagi media dan API developer untuk mengakses layar eksternal.

Jika implementasi perangkat mendukung layar eksternal melalui koneksi layar tambahan berkabel, nirkabel, atau tersemat, implementasi tersebut:

  • [C-1-1] HARUS menerapkan API dan layanan sistem DisplayManager seperti yang dijelaskan dalam dokumentasi Android SDK.

7.2. Perangkat Masukan

Implementasi perangkat:

7.2.1. Keyboard

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

Implementasi perangkat: * [C-0-1] TIDAK BOLEH menyertakan keyboard hardware yang tidak cocok dengan salah satu format yang ditentukan dalam android.content.res.Configuration.keyboard (QWERTY atau 12 tombol). * HARUS menyertakan implementasi keyboard virtual tambahan. * DAPAT menyertakan keyboard hardware.

7.2.2. Navigasi Non-sentuh

Android menyertakan dukungan untuk d-pad, trackball, dan roda sebagai mekanisme untuk navigasi non-sentuh.

Implementasi perangkat:

Jika implementasi perangkat tidak memiliki navigasi non-sentuh, perangkat tersebut:

  • [C-1-1] HARUS menyediakan mekanisme antarmuka pengguna alternatif yang wajar untuk pemilihan dan pengeditan teks, yang kompatibel dengan Mesin Pengelolaan Input. Implementasi open source Android upstream menyertakan mekanisme pemilihan yang cocok untuk digunakan dengan perangkat yang tidak memiliki input navigasi non-sentuh.

7.2.3. Tombol Navigasi

Fungsi Beranda, Terbaru, dan Kembali biasanya disediakan melalui interaksi dengan tombol fisik khusus atau bagian layar sentuh yang berbeda, sangat penting untuk paradigma navigasi Android dan oleh karena itu, implementasi perangkat:

  • [C-0-1] HARUS memberikan kemampuan pengguna untuk meluncurkan aplikasi terinstal yang memiliki aktivitas dengan <intent-filter> yang ditetapkan dengan ACTION=MAIN dan CATEGORY=LAUNCHER atau CATEGORY=LEANBACK_LAUNCHER untuk implementasi perangkat Televisi. Fungsi Beranda HARUS menjadi mekanisme untuk kemampuan pengguna ini.
  • HARUS menyediakan tombol untuk fungsi Terbaru dan Kembali.

Jika fungsi Beranda, Terbaru, atau Kembali disediakan, fungsi tersebut:

  • [C-1-1] HARUS dapat diakses dengan satu tindakan (misalnya, ketuk, klik dua kali, atau gestur) jika salah satunya dapat diakses.
  • [C-1-2] HARUS memberikan indikasi yang jelas tentang tindakan tunggal mana yang akan memicu setiap fungsi. Memiliki ikon yang terlihat dicetak pada tombol, menampilkan ikon software di bagian menu navigasi layar, atau memandu pengguna melalui alur demo langkah demi langkah terpandu selama pengalaman penyiapan siap pakai adalah contoh indikasi tersebut.

Implementasi perangkat:

  • [SR] SANGAT DISARANKAN untuk tidak menyediakan mekanisme input untuk Fungsi menu karena tidak digunakan lagi dan diganti dengan panel tindakan sejak Android 4.0.

Jika implementasi perangkat menyediakan fungsi Menu, implementasi tersebut:

  • [C-2-1] HARUS menampilkan tombol menu tambahan tindakan setiap kali pop-up menu tambahan tindakan tidak kosong dan panel tindakan terlihat.
  • [C-2-2] TIDAK BOLEH mengubah posisi pop-up tambahan tindakan yang ditampilkan dengan memilih tombol tambahan di panel tindakan, tetapi DAPAT merender pop-up tambahan tindakan pada posisi yang diubah di layar saat ditampilkan dengan memilih fungsi Menu.

Jika implementasi perangkat tidak menyediakan fungsi Menu, untuk kompatibilitas mundur, implementasi tersebut: * [C-3-1] HARUS menyediakan fungsi Menu untuk aplikasi jika targetSdkVersion kurang dari 10, baik dengan tombol fisik, kunci software, maupun gestur. Fungsi Menu ini harus dapat diakses kecuali jika disembunyikan bersama dengan fungsi navigasi lainnya.

Jika implementasi perangkat menyediakan fungsi Bantuan, implementasi tersebut: * [C-4-1] HARUS membuat fungsi Bantuan dapat diakses dengan satu tindakan (misalnya, ketuk, klik dua kali, atau gestur) saat tombol navigasi lainnya dapat diakses. * [SR] SANGAT DISARANKAN untuk menggunakan fungsi tekan lama di HOME sebagai interaksi yang ditetapkan ini.

Jika implementasi perangkat menggunakan bagian layar yang berbeda untuk menampilkan tombol navigasi, tombol tersebut:

  • [C-5-1] Tombol navigasi HARUS menggunakan bagian layar yang berbeda, tidak tersedia untuk aplikasi, dan TIDAK BOLEH mengaburkan atau mengganggu bagian layar yang tersedia untuk aplikasi.
  • [C-5-2] HARUS menyediakan sebagian layar untuk aplikasi yang memenuhi persyaratan yang ditentukan dalam bagian 7.1.1.
  • [C-5-3] HARUS mematuhi tanda yang ditetapkan oleh aplikasi melalui metode API View.setSystemUiVisibility(), sehingga bagian layar yang berbeda ini (alias menu navigasi) disembunyikan dengan benar seperti yang didokumentasikan dalam SDK.

7.2.4. Input Layar Sentuh

Android menyertakan dukungan untuk berbagai sistem input pointer, seperti layar sentuh, touchpad, dan perangkat input sentuh palsu. Implementasi perangkat berbasis layar sentuh dikaitkan dengan layar sehingga pengguna memiliki kesan bahwa mereka langsung memanipulasi item di layar. Karena pengguna langsung menyentuh layar, sistem tidak memerlukan kemampuan tambahan untuk menunjukkan objek yang sedang dimanipulasi.

Implementasi perangkat:

  • HARUS memiliki sistem input pointer (seperti mouse atau sentuh).
  • HARUS mendukung pointer yang dilacak sepenuhnya secara independen.

Jika implementasi perangkat menyertakan layar sentuh (sentuhan tunggal atau lebih baik), perangkat tersebut:

  • [C-1-1] HARUS melaporkan TOUCHSCREEN_FINGER untuk kolom API Configuration.touchscreen.
  • [C-1-2] HARUS melaporkan flag fitur android.hardware.touchscreen dan android.hardware.faketouch.

Jika implementasi perangkat menyertakan layar sentuh yang dapat melacak lebih dari satu sentuhan, perangkat tersebut:

  • [C-2-1] HARUS melaporkan flag fitur yang sesuai android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand yang sesuai dengan jenis layar sentuh tertentu di perangkat.

Jika implementasi perangkat tidak menyertakan layar sentuh (dan hanya mengandalkan perangkat pointer) serta memenuhi persyaratan sentuh palsu di bagian 7.2.5, implementasi tersebut:

  • [C-3-1] TIDAK BOLEH melaporkan flag fitur apa pun yang diawali dengan android.hardware.touchscreen dan HANYA BOLEH melaporkan android.hardware.faketouch.

7.2.5. Input Sentuh Palsu

Antarmuka sentuh palsu menyediakan sistem input pengguna yang mendekati subset kemampuan layar sentuh. Misalnya, mouse atau remote control yang menggerakkan kursor di layar mendekati sentuhan, tetapi mengharuskan pengguna untuk terlebih dahulu mengarahkan atau memfokuskan, lalu mengklik. Banyak perangkat input seperti mouse, trackpad, mouse udara berbasis giroskop, pointer giroskop, joystick, dan trackpad multi-kontrol dapat mendukung interaksi sentuh palsu. Android menyertakan konstanta fitur android.hardware.faketouch, yang sesuai dengan perangkat input non-sentuh (berbasis pointer) fidelitas tinggi seperti mouse atau trackpad yang dapat mengemulasikan input berbasis sentuh secara memadai (termasuk dukungan gestur dasar), dan menunjukkan bahwa perangkat mendukung subset fungsi layar sentuh yang diemulasikan.

Jika implementasi perangkat tidak menyertakan layar sentuh, tetapi menyertakan sistem input pointer lain yang ingin disediakan, implementasi tersebut:

  • HARUS mendeklarasikan dukungan untuk flag fitur android.hardware.faketouch.

Jika implementasi perangkat mendeklarasikan dukungan untuk android.hardware.faketouch, implementasi tersebut:

  • [C-1-1] HARUS melaporkan posisi layar X dan Y absolut dari lokasi pointer dan menampilkan pointer visual di layar.
  • [C-1-2] HARUS melaporkan peristiwa sentuh dengan kode tindakan yang menentukan perubahan status yang terjadi pada kursor yang bergerak ke bawah atau ke atas di layar.
  • [C-1-3] HARUS mendukung pointer ke bawah dan ke atas pada objek di layar, yang memungkinkan pengguna mengemulasi ketukan pada objek di layar.
  • [C-1-4] HARUS mendukung pointer ke bawah, pointer ke atas, pointer ke bawah, lalu pointer ke atas di tempat yang sama pada objek di layar dalam batas waktu, yang memungkinkan pengguna mengemulasi ketuk dua kali pada objek di layar.
  • [C-1-5] HARUS mendukung pointer ke bawah pada titik arbitrer di layar, pointer berpindah ke titik arbitrer lainnya di layar, diikuti dengan pointer ke atas, yang memungkinkan pengguna mengemulasi tarikan sentuh.
  • [C-1-6] HARUS mendukung pointer ke bawah, lalu memungkinkan pengguna dengan cepat memindahkan objek ke posisi lain di layar, lalu pointer ke atas di layar, yang memungkinkan pengguna melemparkan objek di layar.
  • [C-1-7] HARUS melaporkan TOUCHSCREEN_NOTOUCH untuk kolom API Configuration.touchscreen.

Jika implementasi perangkat mendeklarasikan dukungan untuk android.hardware.faketouch.multitouch.distinct, implementasi tersebut:

  • [C-2-1] HARUS mendeklarasikan dukungan untuk android.hardware.faketouch.
  • [C-2-2] HARUS mendukung pelacakan yang berbeda dari dua atau beberapa input pointer independen.

Jika implementasi perangkat mendeklarasikan dukungan untuk android.hardware.faketouch.multitouch.jazzhand, implementasi tersebut:

  • [C-3-1] HARUS mendeklarasikan dukungan untuk android.hardware.faketouch.
  • [C-3-2] HARUS mendukung pelacakan yang berbeda dari 5 (melacak tangan jari) atau lebih input pointer secara sepenuhnya independen.

7.2.6. Dukungan Pengontrol Game

7.2.6.1. Pemetaan Tombol

Jika implementasi perangkat mendeklarasikan flag fitur android.hardware.gamepad, implementasi tersebut:

  • [C-1-1] HARUS menyematkan pengontrol atau dikirimkan dengan pengontrol terpisah dalam kotak, yang akan menyediakan cara untuk memasukkan semua peristiwa yang tercantum dalam tabel di bawah.
  • [C-1-2] HARUS dapat memetakan peristiwa HID ke konstanta view.InputEvent Android terkait seperti yang tercantum dalam tabel di bawah. Implementasi Android upstream mencakup implementasi untuk pengontrol game yang memenuhi persyaratan ini.
Tombol Penggunaan HID2 Tombol Android
A1 0x09 0x0001 KEYCODE_BUTTON_A (96)
B1 0x09 0x0002 KEYCODE_BUTTON_B (97)
X1 0x09 0x0004 KEYCODE_BUTTON_X (99)
Y1 0x09 0x0005 KEYCODE_BUTTON_Y (100)
D-pad atas1
D-pad bawah1 		0x01 0x00393 AXIS_HAT_Y4
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 tongkat kiri1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
Klik tongkat kanan1 0x09 0x000F KEYCODE_BUTTON_THUMBR (107)
Beranda1 0x0c 0x0223 KEYCODE_HOME (3)
Back1 0x0c 0x0224 KEYCODE_BACK (4)

1 KeyEvent

2 Penggunaan HID di atas harus dideklarasikan dalam CA Gamepad (0x01 0x0005).

3 Penggunaan ini harus memiliki Minimum Logika 0, Maksimum Logika 7, Minimum Fisik 0, Maksimum Fisik 315, Unit dalam Derajat, dan Ukuran Laporan 4. Nilai logika ditentukan sebagai rotasi searah jarum jam dari sumbu vertikal; misalnya, nilai logika 0 mewakili tidak ada rotasi dan tombol atas ditekan, sedangkan nilai logika 1 mewakili rotasi 45 derajat dan tombol atas dan kiri ditekan.

4 MotionEvent

Kontrol Analog1 Penggunaan HID Tombol Android
Pemicu Kiri 0x02 0x00C5 AXIS_LTRIGGER
Pemicu Kanan 0x02 0x00C4 AXIS_RTRIGGER
Joystick Kiri 0x01 0x0030
0x01 0x0031 		AXIS_X
AXIS_Y
Joystick Kanan 0x01 0x0032
0x01 0x0035 		AXIS_Z
AXIS_RZ

1 MotionEvent

7.2.7. Remote Control

Lihat Bagian 2.3.1 untuk mengetahui persyaratan khusus perangkat.

7.3. Sensor

Jika implementasi perangkat menyertakan jenis sensor tertentu yang memiliki API yang sesuai untuk developer pihak ketiga, implementasi perangkat HARUS menerapkan API tersebut seperti yang dijelaskan dalam dokumentasi Android SDK dan dokumentasi Open Source Android tentang sensor.

Implementasi perangkat:

  • [C-0-1] HARUS melaporkan keberadaan atau ketiadaan sensor secara akurat sesuai dengan class android.content.pm.PackageManager.
  • [C-0-2] HARUS menampilkan daftar sensor yang didukung secara akurat melalui SensorManager.getSensorList() dan metode serupa.
  • [C-0-3] HARUS berperilaku wajar untuk semua API sensor lainnya (misalnya, dengan menampilkan true atau false sebagaimana mestinya saat aplikasi mencoba mendaftarkan pemroses, tidak memanggil pemroses sensor saat sensor yang sesuai tidak ada; dll.).

Jika implementasi perangkat menyertakan jenis sensor tertentu yang memiliki API yang sesuai untuk developer pihak ketiga, API tersebut:

  • [C-1-1] HARUS melaporkan semua pengukuran sensor menggunakan nilai Sistem Satuan Internasional (metrik) yang relevan untuk setiap jenis sensor seperti yang ditentukan dalam dokumentasi Android SDK.
  • [C-1-2] HARUS melaporkan data sensor dengan latensi maksimum 100 milidetik + 2 * sample_time untuk kasus sensor yang di-streaming dengan latensi minimum yang diperlukan 5 md + 2 * sample_time saat prosesor aplikasi aktif. Keterlambatan ini tidak mencakup keterlambatan pemfilteran.
  • [C-1-3] HARUS melaporkan sampel sensor pertama dalam waktu 400 milidetik + 2 * sample_time sensor yang diaktifkan. Sampel ini dapat memiliki akurasi 0.

  • [SR] HARUS melaporkan waktu peristiwa dalam nanodetik seperti yang ditentukan dalam dokumentasi Android SDK, yang mewakili waktu terjadinya peristiwa dan disinkronkan dengan jam SystemClock.elapsedRealtimeNano(). Perangkat Android yang ada dan baru SANGAT DISARANKAN untuk memenuhi persyaratan ini sehingga dapat diupgrade ke rilis platform mendatang yang mungkin menjadi komponen WAJIB. Error sinkronisasi HARUS di bawah 100 milidetik.

  • [C-1-4] Untuk API apa pun yang ditunjukkan oleh dokumentasi Android SDK sebagai sensor berkelanjutan, implementasi perangkat HARUS terus memberikan sampel data berkala yang HARUS memiliki jitter di bawah 3%, dengan jitter didefinisikan sebagai deviasi standar perbedaan nilai stempel waktu yang dilaporkan antara peristiwa berturut-turut.

  • [C-1-5] HARUS memastikan bahwa aliran peristiwa sensor TIDAK BOLEH mencegah CPU perangkat memasuki status penangguhan atau aktif dari status penangguhan.

  • Saat beberapa sensor diaktifkan, konsumsi daya TIDAK BOLEH melebihi jumlah konsumsi daya yang dilaporkan oleh masing-masing sensor.

Daftar di atas tidak komprehensif; perilaku yang didokumentasikan dari Android SDK dan Dokumentasi Open Source Android pada sensor harus dianggap kredibel.

Beberapa jenis sensor bersifat komposit, yang berarti dapat berasal dari data yang disediakan oleh satu atau beberapa sensor lainnya. (Contohnya mencakup sensor orientasi dan sensor akselerasi linear.)

Implementasi perangkat:

  • HARUS menerapkan jenis sensor ini, jika menyertakan sensor fisik prasyarat seperti yang dijelaskan dalam jenis sensor.

Jika implementasi perangkat menyertakan sensor komposit, perangkat tersebut:

  • [C-2-1] HARUS menerapkan sensor seperti yang dijelaskan dalam dokumentasi Open Source Android tentang sensor komposit.

7.3.1. Akselerometer

  • Implementasi perangkat HARUS menyertakan akselerometer 3 sumbu.

Jika implementasi perangkat menyertakan akselerometer 3 sumbu, perangkat tersebut:

  • [C-1-1] HARUS dapat melaporkan peristiwa hingga frekuensi minimal 50 Hz.
  • [C-1-2] HARUS menerapkan dan melaporkan sensor TYPE_ACCELEROMETER.
  • [C-1-3] HARUS mematuhi sistem koordinat sensor Android seperti yang dijelaskan dalam Android API.
  • [C-1-4] HARUS dapat mengukur dari jatuh bebas hingga empat kali gravitasi(4g) atau lebih pada sumbu mana pun.
  • [C-1-5] HARUS memiliki resolusi minimal 12-bit.
  • [C-1-6] HARUS memiliki deviasi standar tidak lebih besar dari 0,05 m/s^, dengan deviasi standar harus dihitung berdasarkan per sumbu pada sampel yang dikumpulkan selama minimal 3 detik pada kecepatan sampling tercepat.
  • [SR] SANGAT DISARANKAN untuk menerapkan sensor gabungan TYPE_SIGNIFICANT_MOTION.
  • [SR] SANGAT DISARANKAN untuk menerapkan sensor TYPE_ACCELEROMETER_UNCALIBRATED jika kalibrasi akselerometer online tersedia.
  • HARUS menerapkan sensor komposit TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER seperti yang dijelaskan dalam dokumen Android SDK.
  • HARUS melaporkan peristiwa hingga minimal 200 Hz.
  • HARUS memiliki resolusi minimal 16-bit.
  • HARUS dikalibrasi saat digunakan jika karakteristik berubah selama siklus proses dan dikompensasi, serta mempertahankan parameter kompensasi di antara mulai ulang perangkat.
  • HARUS dikompensasi suhu.
  • JUGA HARUS menerapkan sensor TYPE_ACCELEROMETER_UNCALIBRATED.

Jika implementasi perangkat menyertakan akselerometer 3 sumbu dan salah satu sensor komposit TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER diterapkan:

  • [C-2-1] Jumlah konsumsi dayanya HARUS selalu kurang dari 4 mW.
  • HARUS masing-masing di bawah 2 mW dan 0,5 mW saat perangkat dalam kondisi dinamis atau statis.

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

  • [C-3-1] HARUS menerapkan sensor gabungan TYPE_GRAVITY dan TYPE_LINEAR_ACCELERATION.
  • HARUS menerapkan sensor gabungan TYPE_GAME_ROTATION_VECTOR.
  • [SR] Perangkat Android lama dan baru SANGAT DIUJI untuk menerapkan sensor TYPE_GAME_ROTATION_VECTOR.

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

  • [C-4-1] HARUS menerapkan sensor gabungan TYPE_ROTATION_VECTOR.

7.3.2. Magnetometer

  • Implementasi perangkat HARUS menyertakan magnetometer (kompas) 3 sumbu.

Jika implementasi perangkat menyertakan magnetometer 3 sumbu, perangkat tersebut:

  • [C-1-1] HARUS mengimplementasikan sensor TYPE_MAGNETIC_FIELD.
  • [C-1-2] HARUS dapat melaporkan peristiwa hingga frekuensi minimal 10 Hz dan HARUS melaporkan peristiwa hingga minimal 50 Hz.
  • [C-1-3] HARUS mematuhi sistem koordinat sensor Android seperti yang dijelaskan dalam Android API.
  • [C-1-4] HARUS dapat mengukur antara -900 µT dan +900 µT pada setiap sumbu sebelum jenuh.
  • [C-1-5] HARUS memiliki nilai offset besi keras kurang dari 700 µT dan HARUS memiliki nilai di bawah 200 µT, dengan menempatkan magnetometer jauh dari medan magnet dinamis (yang disebabkan oleh arus) dan statis (yang disebabkan oleh magnet).
  • [C-1-6] HARUS memiliki resolusi yang sama atau lebih padat dari 0,6 µT.
  • [C-1-7] HARUS mendukung kalibrasi dan kompensasi online bias hard iron, serta mempertahankan parameter kompensasi di antara mulai ulang perangkat.
  • [C-1-8] HARUS menerapkan kompensasi besi lunak—kalibrasi dapat dilakukan saat digunakan atau selama produksi perangkat.
  • [C-1-9] HARUS memiliki simpangan baku, yang dihitung berdasarkan setiap sumbu pada sampel yang dikumpulkan selama minimal 3 detik pada kecepatan sampling tercepat, tidak lebih dari 1,5 µT; HARUS memiliki simpangan baku tidak lebih dari 0,5 µT.
  • HARUS menerapkan sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED.
  • [SR] Perangkat Android lama dan baru SANGAT DIUJI untuk menerapkan sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED.

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

  • [C-2-1] HARUS menerapkan sensor gabungan TYPE_ROTATION_VECTOR.

Jika implementasi perangkat menyertakan magnetometer 3 sumbu, akselerometer, perangkat tersebut:

  • DAPAT menerapkan sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Jika implementasi perangkat menyertakan magnetometer 3 sumbu, akselerometer, dan sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR, perangkat tersebut:

  • [C-3-1] HARUS mengonsumsi daya kurang dari 10 mW.
  • HARUS mengonsumsi kurang dari 3 mW saat sensor didaftarkan untuk mode batch pada 10 Hz.

7.3.3. GPS

Implementasi perangkat:

  • HARUS menyertakan penerima GPS/GNSS.

Jika implementasi perangkat menyertakan penerima GPS/GNSS dan melaporkan kemampuannya ke aplikasi melalui flag fitur android.hardware.location.gps, perangkat tersebut:

  • [C-1-1] HARUS mendukung output lokasi dengan kecepatan minimal 1 Hz saat diminta melalui LocationManager#requestLocationUpdate.
  • [C-1-2] HARUS dapat menentukan lokasi dalam kondisi langit terbuka (sinyal kuat, multipath yang dapat diabaikan, HDOP < 2) dalam waktu 10 detik (waktu cepat untuk mendapatkan fix pertama), saat terhubung ke koneksi internet dengan kecepatan data 0,5 Mbps atau lebih cepat. Persyaratan ini biasanya dipenuhi dengan penggunaan beberapa bentuk teknik GPS/GNSS yang Dibantu atau Diprediksi untuk meminimalkan waktu penguncian GPS/GNSS (Data bantuan mencakup Waktu Referensi, Lokasi Referensi, dan Ephemeris/Jam Satelit).
    • [C-1-6] Setelah melakukan penghitungan lokasi tersebut, implementasi perangkat HARUS menentukan lokasinya, di langit terbuka, dalam waktu 5 detik, saat permintaan lokasi dimulai ulang, hingga satu jam setelah penghitungan lokasi awal, meskipun permintaan berikutnya dilakukan tanpa koneksi data, dan/atau setelah siklus daya.

  • Dalam kondisi langit terbuka setelah menentukan lokasi, saat diam atau bergerak dengan akselerasi kurang dari 1 meter per detik kuadrat:

    • [C-1-3] HARUS dapat menentukan lokasi dalam jarak 20 meter, dan kecepatan dalam jarak 0,5 meter per detik, setidaknya 95% dari waktu.
    • [C-1-4] HARUS melacak dan melaporkan secara bersamaan melalui GnssStatus.Callback minimal 8 satelit dari satu konstelasi.
    • HARUS dapat melacak setidaknya 24 satelit secara bersamaan, dari beberapa konstelasi (misalnya GPS + setidaknya satu dari Glonass, Beidou, Galileo).
    • [C-1-5] HARUS melaporkan generasi teknologi GNSS melalui API pengujian 'getGnssYearOfHardware'.
    • [SR] Terus kirim output lokasi GPS/GNSS normal selama panggilan telepon darurat.
    • [SR] Melaporkan pengukuran GNSS dari semua konstelasi yang dilacak (seperti yang dilaporkan dalam pesan GnssStatus), dengan pengecualian SBAS.
    • [SR] Melaporkan AGC, dan Frekuensi pengukuran GNSS.
    • [SR] Melaporkan semua estimasi akurasi (termasuk Bearing, Speed, dan Vertical) sebagai bagian dari setiap lokasi GPS/GNSS.
    • [SR] SANGAT DISARANKAN untuk memenuhi sebanyak mungkin persyaratan wajib tambahan untuk perangkat yang melaporkan tahun "2016" atau "2017" melalui Test API LocationManager.getGnssYearOfHardware().

Jika implementasi perangkat menyertakan penerima GPS/GNSS dan melaporkan kemampuan ke aplikasi melalui flag fitur android.hardware.location.gps dan LocationManager.getGnssYearOfHardware() Test API melaporkan tahun "2016" atau yang lebih baru, perangkat tersebut:

  • [C-2-1] HARUS melaporkan pengukuran GNSS, segera setelah ditemukan, meskipun lokasi yang dihitung dari GPS/GNSS belum dilaporkan.
  • [C-2-2] HARUS melaporkan pseudorange dan kecepatan pseudorange GNSS, yang, dalam kondisi langit terbuka setelah menentukan lokasi, saat diam atau bergerak dengan percepatan kurang dari 0,2 meter per detik kuadrat, cukup untuk menghitung posisi dalam 20 meter, dan kecepatan dalam 0,2 meter per detik, setidaknya 95% dari waktu.

Jika implementasi perangkat menyertakan penerima GPS/GNSS dan melaporkan kemampuannya ke aplikasi melalui flag fitur android.hardware.location.gps dan LocationManager.getGnssYearOfHardware() Test API melaporkan tahun "2017" atau yang lebih baru, perangkat tersebut:

  • [C-3-1] HARUS terus memberikan output lokasi GPS/GNSS normal selama panggilan telepon darurat.
  • [C-3-2] HARUS melaporkan pengukuran GNSS dari semua konstelasi yang dilacak (seperti yang dilaporkan dalam pesan GnssStatus), dengan pengecualian SBAS.
  • [C-3-3] HARUS melaporkan AGC, dan Frekuensi pengukuran GNSS.
  • [C-3-4] HARUS melaporkan semua estimasi akurasi (termasuk Bearing, Speed, dan Vertical) sebagai bagian dari setiap lokasi GPS/GNSS.

Jika implementasi perangkat menyertakan penerima GPS/GNSS dan melaporkan kemampuannya ke aplikasi melalui flag fitur android.hardware.location.gps dan LocationManager.getGnssYearOfHardware() Test API melaporkan tahun "2018" atau yang lebih baru, perangkat tersebut:

  • [C-4-1] HARUS terus mengirimkan output GPS/GNSS normal ke aplikasi selama panggilan sesi darurat yang Dimulai Jaringan Berbasis Mobile Station (Berbasis MS).
  • [C-4-2] HARUS melaporkan posisi dan pengukuran ke API Penyedia Lokasi GNSS.

7.3.4. Giroskop

Implementasi perangkat:

  • HARUS menyertakan giroskop (sensor perubahan sudut).
  • TIDAK BOLEH menyertakan sensor giroskop kecuali jika akselerometer 3 sumbu juga disertakan.

Jika implementasi perangkat menyertakan giroskop, perangkat tersebut:

  • [C-1-1] HARUS dapat melaporkan peristiwa hingga frekuensi minimal 50 Hz.
  • [C-1-2] HARUS menerapkan sensor TYPE_GYROSCOPE dan JUGA HARUS menerapkan sensor TYPE_GYROSCOPE_UNCALIBRATED.
  • [C-1-3] HARUS dapat mengukur perubahan orientasi hingga 1.000 derajat per detik.
  • [C-1-4] HARUS memiliki resolusi 12-bit atau lebih dan HARUS memiliki resolusi 16-bit atau lebih.
  • [C-1-5] HARUS memiliki kompensasi suhu.
  • [C-1-6] HARUS dikalibrasi dan dikompensasi saat digunakan, serta mempertahankan parameter kompensasi di antara mulai ulang perangkat.
  • [C-1-7] HARUS memiliki varians tidak lebih besar dari 1e-7 rad^2 / s^2 per Hz (varians per Hz, atau rad^2 / s). Varians diizinkan untuk bervariasi dengan frekuensi sampling, tetapi HARUS dibatasi oleh nilai ini. Dengan kata lain, jika Anda mengukur varians giroskop pada kecepatan sampling 1 Hz, nilainya TIDAK BOLEH lebih besar dari 1e-7 rad^2/s^2.
  • [SR] Perangkat Android lama dan baru SANGAT DIUJI untuk menerapkan sensor SENSOR_TYPE_GYROSCOPE_UNCALIBRATED.
  • [SR] Error kalibrasi SANGAT DISARANKAN agar kurang dari 0,01 rad/s saat perangkat diam pada suhu ruangan.
  • HARUS melaporkan peristiwa hingga minimal 200 Hz.

Jika implementasi perangkat menyertakan giroskop, sensor akselerometer, dan sensor magnetometer, perangkat tersebut:

  • [C-2-1] HARUS menerapkan sensor gabungan TYPE_ROTATION_VECTOR.

Jika implementasi perangkat menyertakan sensor giroskop dan akselerometer, sensor tersebut:

  • [C-3-1] HARUS menerapkan sensor gabungan TYPE_GRAVITY dan TYPE_LINEAR_ACCELERATION.
  • [SR] Perangkat Android lama dan baru SANGAT DIUJI untuk menerapkan sensor TYPE_GAME_ROTATION_VECTOR.
  • HARUS menerapkan sensor gabungan TYPE_GAME_ROTATION_VECTOR.

7.3.5. Barometer

  • Implementasi perangkat HARUS menyertakan barometer (sensor tekanan udara sekitar).

Jika implementasi perangkat menyertakan barometer, implementasi tersebut:

  • [C-1-1] HARUS menerapkan dan melaporkan sensor TYPE_PRESSURE.
  • [C-1-2] HARUS dapat mengirimkan peristiwa pada kecepatan 5 Hz atau lebih.
  • [C-1-3] HARUS memiliki kompensasi suhu.
  • [SR] SANGAT DIUJAMI untuk dapat melaporkan pengukuran tekanan dalam rentang 300hPa hingga 1100hPa.
  • HARUS memiliki akurasi absolut 1hPa.
  • HARUS memiliki akurasi relatif 0,12hPa pada rentang 20hPa (setara dengan akurasi ~1 m pada perubahan ~200 m di permukaan laut).

7.3.6. Thermometer

Implementasi perangkat: * DAPAT menyertakan termometer ambien (sensor suhu). * BOLEH, tetapi TIDAK BOLEH menyertakan sensor suhu CPU.

Jika implementasi perangkat menyertakan termometer ambien (sensor suhu), perangkat tersebut:

  • [C-1-1] HARUS ditentukan sebagai SENSOR_TYPE_AMBIENT_TEMPERATURE dan HARUS mengukur suhu lingkungan (ruangan/kabin kendaraan) dari tempat pengguna berinteraksi dengan perangkat dalam derajat Celcius.
  • [C-1-2] HARUS ditentukan sebagai SENSOR_TYPE_TEMPERATURE.
  • [C-1-3] HARUS mengukur suhu CPU perangkat.
  • [C-1-4] TIDAK BOLEH mengukur suhu lainnya.

Perhatikan bahwa jenis sensor SENSOR_TYPE_TEMPERATURE tidak digunakan lagi di Android 4.0.

7.3.7. Fotometer

  • Implementasi perangkat DAPAT menyertakan fotometer (sensor cahaya sekitar).

7.3.8. Sensor Kedekatan

  • Implementasi perangkat DAPAT menyertakan sensor kedekatan.

Jika implementasi perangkat menyertakan sensor kedekatan, perangkat tersebut:

  • [C-1-1] HARUS mengukur kedekatan objek dalam arah yang sama dengan layar. Artinya, sensor kedekatan HARUS diorientasikan untuk mendeteksi objek yang dekat dengan layar, karena intent utama jenis sensor ini adalah mendeteksi ponsel yang digunakan oleh pengguna. Jika implementasi perangkat menyertakan sensor kedekatan dengan orientasi lain, sensor tersebut TIDAK BOLEH diakses melalui API ini.
  • [C-1-2] HARUS memiliki akurasi 1-bit atau lebih.

7.3.9. Sensor Akurasi Tinggi

Jika implementasi perangkat menyertakan serangkaian sensor berkualitas lebih tinggi seperti yang ditentukan di bagian ini, dan menyediakannya untuk aplikasi pihak ketiga, perangkat tersebut:

  • [C-1-1] HARUS mengidentifikasi kemampuan melalui flag fitur android.hardware.sensor.hifi_sensors.

Jika implementasi perangkat mendeklarasikan android.hardware.sensor.hifi_sensors, implementasi tersebut:

  • [C-2-1] HARUS memiliki sensor TYPE_ACCELEROMETER yang:

    • HARUS memiliki rentang pengukuran antara minimal -8 g dan +8 g, HARUS memiliki rentang pengukuran antara minimal -16 g dan +16 g.
    • HARUS memiliki resolusi pengukuran minimal 2048 LSB/g.
    • HARUS memiliki frekuensi pengukuran minimum 12,5 Hz atau lebih rendah.
    • HARUS memiliki frekuensi pengukuran maksimum 400 Hz atau lebih tinggi; HARUS mendukung SensorDirectChannel RATE_VERY_FAST.
    • HARUS memiliki derau pengukuran tidak lebih dari 400 μg/√Hz.
    • HARUS menerapkan bentuk non-wake-up sensor ini dengan kemampuan buffering minimal 3.000 peristiwa sensor.
    • HARUS memiliki konsumsi daya pengelompokan yang tidak lebih buruk dari 3 mW.
    • [C-SR] SANGAT DISARANKAN untuk memiliki bandwidth pengukuran 3 dB minimal 80% dari frekuensi Nyquist, dan spektrum derau putih dalam bandwidth ini.
    • HARUS memiliki random walk akselerasi kurang dari 30 μg √Hz yang diuji pada suhu ruangan.
    • HARUS memiliki perubahan bias vs. suhu ≤ +/- 1 mg/°C.
    • HARUS memiliki non-linearitas garis yang paling sesuai sebesar ≤ 0,5%, dan perubahan sensitivitas vs. suhu sebesar ≤ 0,03%/C°.
    • HARUS memiliki sensitivitas sumbu silang < 2,5 % dan variasi sensitivitas sumbu silang < 0,2% dalam rentang suhu pengoperasian perangkat.

  • [C-2-2] HARUS memiliki TYPE_ACCELEROMETER_UNCALIBRATED dengan persyaratan kualitas yang sama dengan TYPE_ACCELEROMETER.

  • [C-2-3] HARUS memiliki sensor TYPE_GYROSCOPE yang:

    • HARUS memiliki rentang pengukuran antara minimal -1.000 dan +1.000 dps.
    • HARUS memiliki resolusi pengukuran minimal 16 LSB/dps.
    • HARUS memiliki frekuensi pengukuran minimum 12,5 Hz atau lebih rendah.
    • HARUS memiliki frekuensi pengukuran maksimum 400 Hz atau lebih tinggi; HARUS mendukung SensorDirectChannel RATE_VERY_FAST.
    • HARUS memiliki derau pengukuran tidak lebih dari 0,014°/s/√Hz.
    • [C-SR] SANGAT DISARANKAN untuk memiliki bandwidth pengukuran 3 dB minimal 80% dari frekuensi Nyquist, dan spektrum derau putih dalam bandwidth ini.
    • HARUS memiliki random walk kecepatan kurang dari 0,001 °/s √Hz yang diuji pada suhu ruangan.
    • HARUS memiliki perubahan bias vs. suhu ≤ +/- 0,05 °/ s / °C.
    • HARUS memiliki perubahan sensitivitas vs. suhu ≤ 0,02% / °C.
    • HARUS memiliki non-linearitas garis yang paling cocok sebesar ≤ 0,2%.
    • HARUS memiliki kepadatan derau ≤ 0,007 °/s/√Hz.
    • HARUS memiliki error kalibrasi kurang dari 0,002 rad/s dalam rentang suhu 10 ~ 40 ℃ saat perangkat tidak bergerak.
    • HARUS memiliki sensitivitas g kurang dari 0,1°/s/g.
    • HARUS memiliki sensitivitas lintas sumbu < 4,0 % dan variasi sensitivitas lintas sumbu < 0,3% dalam rentang suhu operasi perangkat.

  • [C-2-4] HARUS memiliki TYPE_GYROSCOPE_UNCALIBRATED dengan persyaratan kualitas yang sama dengan 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 tidak lebih dari 0,5 uT.

  • [C-2-6] HARUS memiliki TYPE_MAGNETIC_FIELD_UNCALIBRATED dengan persyaratan kualitas yang sama dengan TYPE_GEOMAGNETIC_FIELD dan selain itu:

    • HARUS menerapkan bentuk non-wake-up sensor ini dengan kemampuan buffering minimal 600 peristiwa sensor.
    • [C-SR] SANGAT DIUTAMAKAN untuk memiliki spektrum derau putih dari 1 Hz hingga minimal 10 Hz jika kecepatan laporannya 50 Hz atau lebih tinggi.

  • [C-2-7] HARUS memiliki sensor TYPE_PRESSURE yang:

    • HARUS memiliki rentang pengukuran antara minimal 300 dan 1100 hPa.
    • HARUS memiliki resolusi pengukuran minimal 80 LSB/hPa.
    • HARUS memiliki frekuensi pengukuran minimum 1 Hz atau lebih rendah.
    • HARUS memiliki frekuensi pengukuran maksimum 10 Hz atau lebih tinggi.
    • HARUS memiliki derau pengukuran tidak lebih dari 2 Pa/√Hz.
    • HARUS menerapkan bentuk non-wake-up sensor ini dengan kemampuan buffering minimal 300 peristiwa sensor.
    • HARUS memiliki konsumsi daya pengelompokan yang tidak lebih buruk dari 2 mW.
  • [C-2-8] HARUS memiliki sensor TYPE_GAME_ROTATION_VECTOR yang:
    • HARUS menerapkan bentuk non-wake-up sensor ini dengan kemampuan buffering minimal 300 peristiwa sensor.
    • HARUS memiliki konsumsi daya pengelompokan yang tidak lebih buruk dari 4 mW.
  • [C-2-9] HARUS memiliki sensor TYPE_SIGNIFICANT_MOTION yang:
    • HARUS memiliki konsumsi daya tidak lebih buruk dari 0,5 mW saat perangkat statis dan 1,5 mW saat perangkat bergerak.
  • [C-2-10] HARUS memiliki sensor TYPE_STEP_DETECTOR yang:
    • HARUS menerapkan bentuk non-wake-up sensor ini dengan kemampuan buffering minimal 100 peristiwa sensor.
    • HARUS memiliki konsumsi daya tidak lebih buruk dari 0,5 mW saat perangkat statis dan 1,5 mW saat perangkat bergerak.
    • HARUS memiliki konsumsi daya pengelompokan yang tidak lebih buruk dari 4 mW.
  • [C-2-11] HARUS memiliki sensor TYPE_STEP_COUNTER yang:
    • HARUS memiliki konsumsi daya tidak lebih buruk dari 0,5 mW saat perangkat statis dan 1,5 mW saat perangkat bergerak.
  • [C-2-12] HARUS memiliki sensor TILT_DETECTOR yang:
    • HARUS memiliki konsumsi daya tidak lebih buruk dari 0,5 mW saat perangkat statis dan 1,5 mW saat perangkat bergerak.
  • [C-2-13] Stempel waktu peristiwa dari peristiwa fisik yang sama yang dilaporkan oleh Akselerometer, Giroskop, dan Magnetometer HARUS berada dalam rentang 2,5 milidetik. Stempel waktu peristiwa dari peristiwa fisik yang sama yang dilaporkan oleh Akselerometer dan Giroskop HARUS berada dalam jarak 0,25 milidetik.
  • [C-2-14] HARUS memiliki stempel waktu peristiwa sensor Giroskop pada basis waktu yang sama dengan subsistem kamera dan dalam error 1 milidetik.
  • [C-2-15] HARUS mengirimkan sampel ke aplikasi dalam waktu 5 milidetik sejak data tersedia di salah satu sensor fisik di atas ke aplikasi.
  • [C-2-16] TIDAK BOLEH memiliki konsumsi daya lebih tinggi dari 0,5 mW saat perangkat statis dan 2,0 mW saat perangkat bergerak jika kombinasi sensor berikut diaktifkan:
    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS
  • [C-2-17] BOLEH memiliki sensor TYPE_PROXIMITY, tetapi jika ada, HARUS memiliki kemampuan buffering minimum 100 peristiwa sensor.

Perhatikan bahwa semua persyaratan konsumsi daya di bagian ini tidak mencakup konsumsi daya dari Application Processor. Ini mencakup daya yang diambil oleh seluruh rantai sensor—sensor, sirkuit pendukung, sistem pemrosesan sensor khusus, dll.

Jika implementasi perangkat menyertakan dukungan sensor langsung, perangkat tersebut:

  • [C-3-1] HARUS mendeklarasikan dukungan jenis saluran langsung dan tingkat rasio laporan langsung dengan benar melalui isDirectChannelTypeSupported dan getHighestDirectReportRateLevel 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 utama (varian non-aktif) dari jenis berikut:
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Sensor Biometrik

7.3.10.1. Sensor Sidik Jari

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

  • HARUS menyertakan sensor sidik jari.

Jika implementasi perangkat menyertakan sensor sidik jari dan menyediakan sensor tersebut untuk aplikasi pihak ketiga, implementasi tersebut:

  • [C-1-1] HARUS mendeklarasikan dukungan untuk fitur android.hardware.fingerprint.
  • [C-1-2] HARUS menerapkan sepenuhnya API yang sesuai seperti yang dijelaskan dalam dokumentasi Android SDK.
  • [C-1-3] HARUS memiliki rasio penerimaan palsu tidak lebih tinggi dari 0,002%.
  • [SR] SANGAT DISARANKAN untuk memiliki tingkat penerimaan spoof dan penipu tidak lebih tinggi dari 7%.
  • [C-1-4] HARUS mengungkapkan bahwa mode ini mungkin kurang aman dibandingkan dengan PIN, pola, atau sandi yang kuat dan mencantumkan dengan jelas risiko mengaktifkannya, jika rasio penerimaan spoof dan penipu lebih tinggi dari 7%.
  • [C-1-5] HARUS membatasi frekuensi percobaan selama minimal 30 detik setelah lima percobaan palsu untuk verifikasi sidik jari.
  • [C-1-6] HARUS memiliki implementasi keystore yang didukung hardware, dan melakukan pencocokan sidik jari di Trusted Execution Environment (TEE) atau di chip dengan saluran aman ke TEE.
  • [C-1-7] HARUS memiliki semua data sidik jari yang dapat diidentifikasi yang dienkripsi dan diautentikasi secara kriptografis sehingga tidak dapat diperoleh, dibaca, atau diubah di luar TEE, atau chip dengan saluran aman ke TEE seperti yang didokumentasikan dalam panduan penerapan di situs Android Open Source Project.
  • [C-1-8] HARUS mencegah penambahan sidik jari tanpa terlebih dahulu membuat rantai kepercayaan dengan meminta pengguna mengonfirmasi kredensial perangkat yang ada atau menambahkan kredensial perangkat baru (PIN/pola/sandi) yang diamankan oleh TEE; implementasi Project Open Source Android menyediakan mekanisme dalam framework untuk melakukannya.
  • [C-1-9] TIDAK BOLEH mengizinkan aplikasi pihak ketiga untuk membedakan setiap sidik jari.
  • [C-1-10] HARUS mematuhi flag DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT.
  • [C-1-11] HARUS, saat diupgrade dari versi yang lebih lama dari Android 6.0, memigrasikan data sidik jari dengan aman untuk memenuhi persyaratan di atas atau menghapusnya.
  • [C-1-12] HARUS menghapus sepenuhnya semua data sidik jari yang dapat diidentifikasi untuk pengguna saat akun pengguna dihapus (termasuk melalui reset ke setelan pabrik).
  • [C-1-13] TIDAK BOLEH mengizinkan akses yang tidak dienkripsi ke data sidik jari yang dapat diidentifikasi atau data apa pun yang berasal darinya (seperti penyematan) ke Application Processor.
  • [SR] SANGAT DISARANKAN untuk memiliki rasio penolakan palsu kurang dari 10%, seperti yang diukur di perangkat.
  • [SR] SANGAT DISARANKAN untuk memiliki latensi di bawah 1 detik, diukur dari saat sensor sidik jari disentuh hingga layar dibuka kuncinya, untuk satu jari yang terdaftar.
  • HARUS menggunakan ikon Sidik Jari Android yang disediakan di Project Open Source Android.
7.3.10.2. Sensor Biometrik Lainnya

Jika implementasi perangkat menyertakan satu atau beberapa sensor biometrik non-berbasis sidik jari dan menyediakannya untuk aplikasi pihak ketiga, aplikasi tersebut:

  • [C-1-1] HARUS memiliki rasio penerimaan palsu tidak lebih tinggi dari 0,002%.
  • [C-SR] SANGAT DISARANKAN untuk memiliki tingkat penerimaan spoof dan penipu tidak lebih tinggi dari 7%.
  • [C-1-2] HARUS mengungkapkan bahwa mode ini mungkin kurang aman dibandingkan dengan PIN, pola, atau sandi yang kuat dan mencantumkan dengan jelas risiko mengaktifkannya, jika tingkat penerimaan spoof dan penipu lebih tinggi dari 7%.
  • [C-1-3] HARUS membatasi upaya rating selama minimal 30 detik setelah lima percobaan palsu untuk verifikasi biometrik - dengan percobaan palsu adalah percobaan dengan kualitas pengambilan yang memadai (ACQUIRED_GOOD) yang tidak cocok dengan biometrik terdaftar
  • [C-1-4] HARUS memiliki implementasi keystore yang didukung hardware, dan melakukan pencocokan biometrik di TEE atau di chip dengan saluran aman ke TEE.
  • [C-1-5] HARUS memiliki semua data yang dapat diidentifikasi yang dienkripsi dan diautentikasi secara kriptografis sehingga tidak dapat diperoleh, dibaca, atau diubah di luar TEE, atau chip dengan saluran aman ke TEE seperti yang didokumentasikan dalam pedoman penerapan di situs Android Open Source Project.
  • [C-1-6] HARUS mencegah penambahan biometrik baru tanpa terlebih dahulu membuat rantai kepercayaan dengan meminta pengguna mengonfirmasi kredensial perangkat yang ada atau menambahkan kredensial perangkat baru (PIN/pola/sandi) yang diamankan oleh TEE; implementasi Project Open Source Android menyediakan mekanisme dalam framework untuk melakukannya.
  • [C-1-7] TIDAK BOLEH mengizinkan aplikasi pihak ketiga untuk membedakan pendaftaran biometrik.
  • [C-1-8] HARUS mematuhi flag individual untuk biometrik tersebut (yaitu: DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE, atau DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
  • [C-1-9] HARUS menghapus sepenuhnya semua data biometrik yang dapat diidentifikasi untuk pengguna saat akun pengguna dihapus (termasuk melalui reset ke setelan pabrik).
  • [C-1-10] TIDAK BOLEH mengizinkan akses yang tidak dienkripsi ke data biometrik yang dapat diidentifikasi atau data apa pun yang berasal darinya (seperti penyematan) ke Prosesor Aplikasi di luar konteks TEE.
  • [C-SR] SANGAT DISARANKAN untuk memiliki rasio penolakan palsu kurang dari 10%, seperti yang diukur di perangkat.
  • [C-SR] SANGAT DISARANKAN untuk memiliki latensi di bawah 1 detik, diukur dari saat biometrik terdeteksi, hingga layar dibuka kuncinya, untuk setiap biometrik yang terdaftar.

7.3.11. Sensor khusus Android Automotive

Sensor khusus otomotif ditentukan dalam android.car.CarSensorManager API.

7.3.11.1. Roda Gigi Saat Ini

Lihat Bagian 2.5.1 untuk mengetahui persyaratan khusus perangkat.

7.3.11.2. Mode Siang/Malam

Lihat Bagian 2.5.1 untuk mengetahui persyaratan khusus perangkat.

7.3.11.3. Status Mengemudi

Persyaratan ini tidak digunakan lagi.

7.3.11.4. Kecepatan Roda

Lihat Bagian 2.5.1 untuk mengetahui persyaratan khusus perangkat.

7.3.11.5. Rem Parkir

Lihat Bagian 2.5.1 untuk mengetahui persyaratan khusus perangkat.

7.3.12. Sensor Pose

Implementasi perangkat:

  • DAPAT mendukung sensor pose dengan 6 derajat kebebasan.

Jika implementasi perangkat mendukung sensor pose dengan 6 derajat kebebasan, perangkat tersebut:

  • [C-1-1] HARUS menerapkan dan melaporkan sensor TYPE_POSE_6DOF.
  • [C-1-2] HARUS lebih akurat daripada vektor rotasi saja.

7.4. Konektivitas Data

7.4.1. Telepon

“Telepon” seperti yang digunakan oleh Android API dan dokumen ini secara khusus merujuk pada hardware yang terkait dengan melakukan panggilan suara dan mengirim pesan SMS melalui jaringan GSM atau CDMA. Meskipun panggilan suara ini mungkin atau mungkin tidak menggunakan packet-switched, panggilan tersebut untuk tujuan Android dianggap independen dari konektivitas data apa pun yang dapat diterapkan menggunakan jaringan yang sama. Dengan kata lain, fungsi dan API “telepon” Android secara khusus merujuk pada panggilan suara dan SMS. Misalnya, implementasi perangkat yang tidak dapat melakukan panggilan atau mengirim/menerima pesan SMS tidak dianggap sebagai perangkat telepon, terlepas dari apakah perangkat tersebut menggunakan jaringan seluler untuk konektivitas data.

  • Android DAPAT digunakan di perangkat yang tidak menyertakan hardware telefoni. Artinya, Android kompatibel dengan perangkat yang bukan ponsel.

Jika implementasi perangkat menyertakan telepon GSM atau CDMA, perangkat tersebut:

  • [C-1-1] HARUS mendeklarasikan flag fitur android.hardware.telephony dan flag sub-fitur lainnya sesuai dengan teknologi.
  • [C-1-2] HARUS menerapkan dukungan penuh untuk API untuk teknologi tersebut.

Jika implementasi perangkat tidak menyertakan hardware telefoni, implementasi tersebut:

  • [C-2-1] HARUS menerapkan API lengkap sebagai no-ops.
7.4.1.1. Kompatibilitas Pemblokiran Nomor

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

  • [C-1-1] HARUS menyertakan dukungan pemblokiran nomor
  • [C-1-2] HARUS sepenuhnya menerapkan BlockedNumberContract dan API yang sesuai seperti yang dijelaskan dalam dokumentasi SDK.
  • [C-1-3] HARUS memblokir semua panggilan dan pesan dari nomor telepon di 'BlockedNumberProvider' tanpa interaksi apa pun dengan aplikasi. Satu-satunya pengecualian adalah saat pemblokiran nomor dicabut untuk sementara seperti yang dijelaskan dalam dokumentasi SDK.
  • [C-1-4] TIDAK BOLEH menulis ke penyedia log panggilan platform untuk panggilan yang diblokir.
  • [C-1-5] TIDAK BOLEH menulis ke Penyedia layanan telepon untuk pesan yang diblokir.
  • [C-1-6] HARUS menerapkan UI pengelolaan nomor yang diblokir, yang dibuka dengan intent yang ditampilkan oleh metode TelecomManager.createManageBlockedNumbersIntent().
  • [C-1-7] TIDAK BOLEH mengizinkan pengguna sekunder melihat atau mengedit nomor yang diblokir di perangkat karena platform Android mengasumsikan bahwa pengguna utama memiliki kontrol penuh atas layanan telefoni, satu instance, di perangkat. Semua UI terkait pemblokiran HARUS disembunyikan untuk pengguna sekunder dan daftar yang diblokir HARUS tetap dipatuhi.
  • HARUS memigrasikan nomor yang diblokir ke penyedia saat perangkat diupdate ke Android 7.0.
7.4.1.2. Telecom API

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

  • [C-1-1] HARUS mendukung API ConnectionService yang dijelaskan dalam SDK.
  • [C-1-2] HARUS menampilkan panggilan masuk baru dan memberikan kemampuan pengguna untuk menerima atau menolak panggilan masuk saat pengguna sedang melakukan panggilan yang sedang berlangsung yang dilakukan oleh aplikasi pihak ketiga yang tidak mendukung fitur tahan yang ditentukan melalui CAPABILITY_SUPPORT_HOLD.

  • [C-SR] SANGAT DISARANKAN untuk memberi tahu pengguna bahwa menjawab panggilan masuk akan menghentikan panggilan yang sedang berlangsung.

    Implementasi AOSP memenuhi persyaratan ini dengan notifikasi pemberitahuan yang menunjukkan kepada pengguna bahwa menjawab panggilan masuk akan menyebabkan panggilan lain terputus.

  • [C-SR] SANGAT DISARANKAN untuk memuat aplikasi dialer default secara default yang menampilkan entri log panggilan dan nama aplikasi pihak ketiga di log panggilannya saat aplikasi pihak ketiga menetapkan kunci tambahan EXTRA_LOG_SELF_MANAGED_CALLS di PhoneAccount ke true.

  • [C-SR] SANGAT DIUJAMI untuk menangani peristiwa KEYCODE_MEDIA_PLAY_PAUSE dan KEYCODE_HEADSETHOOK headset audio untuk API android.telecom seperti di bawah ini:

7.4.2. IEEE 802.11 (Wi-Fi)

Implementasi perangkat:

  • HARUS menyertakan dukungan untuk satu atau beberapa bentuk 802.11.

Jika implementasi perangkat menyertakan dukungan untuk 802.11 dan mengekspos fungsi ke aplikasi pihak ketiga, implementasi tersebut:

  • [C-1-1] HARUS mengimplementasikan Android API yang sesuai.
  • [C-1-2] HARUS melaporkan tanda fitur hardware android.hardware.wifi.
  • [C-1-3] HARUS menerapkan multicast API seperti yang dijelaskan dalam dokumentasi SDK.
  • [C-1-4] HARUS mendukung DNS multicast (mDNS) dan TIDAK BOLEH memfilter paket mDNS (224.0.0.251) kapan saja selama operasi, termasuk:
    • Bahkan saat layar tidak dalam status aktif.
    • Untuk penerapan perangkat Android Television, bahkan saat dalam status daya siaga.
  • [C-1-5] TIDAK BOLEH memperlakukan panggilan metode API WifiManager.enableNetwork() sebagai indikasi yang memadai untuk mengalihkan Network yang saat ini aktif yang digunakan secara default untuk traffic aplikasi dan ditampilkan oleh metode API ConnectivityManager seperti getActiveNetwork dan registerDefaultNetworkCallback. Dengan kata lain, mereka HANYA BOLEH menonaktifkan akses Internet yang disediakan oleh penyedia jaringan lain (misalnya, data seluler) jika mereka berhasil memvalidasi bahwa jaringan Wi-Fi menyediakan akses Internet.
  • [C-SR] SANGAT DIUJAMI, saat metode API ConnectivityManager.reportNetworkConnectivity() dipanggil, untuk mengevaluasi ulang akses Internet di Network dan, setelah evaluasi menentukan bahwa Network saat ini tidak lagi menyediakan akses Internet, beralihlah ke jaringan lain yang tersedia (misalnya, data seluler) yang menyediakan akses Internet.
  • [C-SR] SANGAT DISARANKAN untuk mengacaukan alamat MAC sumber dan nomor urutan frame permintaan probe, sekali di awal setiap pemindaian, saat STA terputus.
    • Setiap grup frame permintaan probe yang terdiri dari satu pemindaian harus menggunakan satu alamat MAC yang konsisten (TIDAK BOLEH mengacak alamat MAC di tengah pemindaian).
    • Nomor urutan permintaan probe harus di-iterasi seperti biasa (secara berurutan) di antara permintaan probe dalam pemindaian.
    • Nomor urutan permintaan probe harus diacak antara permintaan probe terakhir dari pemindaian dan permintaan probe pertama dari pemindaian berikutnya.
  • [C-SR] SANGAT DIUJAMI, saat STA terputus, untuk hanya mengizinkan elemen berikut dalam frame permintaan probe:
    • Kumpulan Parameter SSID (0)
    • Set Parameter DS (3)

Jika implementasi perangkat mendukung Wi-Fi dan menggunakan Wi-Fi untuk pemindaian lokasi, perangkat tersebut:

7.4.2.1. Wi-Fi Direct

Implementasi perangkat:

  • HARUS menyertakan dukungan untuk Wi-Fi Direct (Wi-Fi peer-to-peer).

Jika implementasi perangkat menyertakan dukungan untuk Wi-Fi Direct, perangkat tersebut:

  • [C-1-1] HARUS menerapkan Android API yang sesuai seperti yang dijelaskan dalam dokumentasi SDK.
  • [C-1-2] HARUS melaporkan fitur hardware android.hardware.wifi.direct.
  • [C-1-3] HARUS mendukung pengoperasian Wi-Fi reguler.
  • [C-1-4] HARUS mendukung operasi Wi-Fi dan Wi-Fi Direct secara serentak.

Implementasi perangkat:

Jika implementasi perangkat menyertakan dukungan untuk TDLS dan TDLS diaktifkan oleh WiFiManager API, perangkat tersebut:

  • [C-1-1] HARUS mendeklarasikan dukungan untuk TDLS melalui WifiManager.isTdlsSupported.
  • HARUS menggunakan TDLS hanya jika memungkinkan DAN bermanfaat.
  • HARUS memiliki beberapa heuristik dan TIDAK menggunakan TDLS jika performanya mungkin lebih buruk daripada melalui titik akses Wi-Fi.
7.4.2.3. Wi-Fi Aware

Implementasi perangkat:

Jika implementasi perangkat menyertakan dukungan untuk Wi-Fi Aware dan mengekspos fungsi ke aplikasi pihak ketiga, maka:

  • [C-1-1] HARUS menerapkan API WifiAwareManager seperti yang dijelaskan dalam dokumentasi SDK.
  • [C-1-2] HARUS mendeklarasikan flag fitur android.hardware.wifi.aware.
  • [C-1-3] HARUS mendukung operasi Wi-Fi dan Wi-Fi Aware secara serentak.
  • [C-1-4] HARUS melakukan pengacakan alamat antarmuka pengelolaan Wi-Fi Aware dengan interval tidak lebih dari 30 menit dan setiap kali Wi-Fi Aware diaktifkan.

Jika implementasi perangkat menyertakan dukungan untuk Wi-Fi Aware dan Lokasi Wi-Fi seperti yang dijelaskan dalam Bagian 7.4.2.5 dan mengekspos fungsi ini ke aplikasi pihak ketiga, maka:

7.4.2.4. Passpoint Wi-Fi

Implementasi perangkat:

Jika penerapan perangkat menyertakan dukungan untuk Wi-Fi Passpoint, perangkat tersebut:

  • [C-1-1] HARUS menerapkan WifiManager API terkait Passpoint seperti yang dijelaskan dalam dokumentasi SDK.
  • [C-1-2] HARUS mendukung standar IEEE 802.11u, khususnya yang terkait dengan Penemuan dan Pemilihan Jaringan, seperti Layanan Iklan Umum (GAS) dan Access Network Query Protocol (ANQP).

Sebaliknya, jika implementasi perangkat tidak menyertakan dukungan untuk Wi-Fi Passpoint:

  • [C-2-1] Implementasi API WifiManager terkait Passpoint HARUS menampilkan UnsupportedOperationException.
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 fungsi ke aplikasi pihak ketiga, maka:

  • [C-1-1] HARUS menerapkan API WifiRttManager seperti yang dijelaskan dalam dokumentasi SDK.
  • [C-1-2] HARUS mendeklarasikan flag fitur android.hardware.wifi.rtt.
  • [C-1-3] HARUS mengacaukan alamat MAC sumber untuk setiap burst RTT yang dieksekusi saat antarmuka Wi-Fi tempat RTT dieksekusi tidak dikaitkan dengan Titik Akses.

7.4.3. Bluetooth

Jika implementasi perangkat mendukung profil Audio Bluetooth, perangkat tersebut:

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

Jika implementasi perangkat mendukung HFP, A2DP, dan AVRCP, perangkat tersebut:

  • HARUS mendukung minimal 5 total perangkat terhubung.

Jika implementasi perangkat mendeklarasikan fitur android.hardware.vr.high_performance, implementasi tersebut:

  • [C-1-1] HARUS mendukung Bluetooth 4.2 dan Ekstensi Panjang Data Bluetooth LE.

Android menyertakan dukungan untuk Bluetooth dan Bluetooth Hemat Energi.

Jika implementasi perangkat menyertakan dukungan untuk Bluetooth dan Bluetooth Hemat Energi, implementasi tersebut:

  • [C-2-1] HARUS mendeklarasikan fitur platform yang relevan (masing-masing android.hardware.bluetooth dan android.hardware.bluetooth_le) dan menerapkan API platform.
  • HARUS menerapkan profil Bluetooth yang relevan seperti A2DP, AVRCP, OBEX, HFP, dll. sesuai dengan perangkat.

Jika implementasi perangkat menyertakan dukungan untuk Bluetooth Hemat Energi, perangkat tersebut:

  • [C-3-1] HARUS mendeklarasikan fitur hardware android.hardware.bluetooth_le.
  • [C-3-2] HARUS mengaktifkan API Bluetooth berbasis GATT (profil atribut generik) seperti yang dijelaskan dalam dokumentasi SDK dan android.bluetooth.
  • [C-3-3] HARUS melaporkan nilai yang benar untuk BluetoothAdapter.isOffloadedFilteringSupported() guna menunjukkan apakah logika pemfilteran untuk class API ScanFilter diterapkan.
  • [C-3-4] HARUS melaporkan nilai yang benar untuk BluetoothAdapter.isMultipleAdvertisementSupported() guna menunjukkan apakah Iklan Hemat Energi didukung.
  • HARUS mendukung offloading logika pemfilteran ke chipset bluetooth saat menerapkan ScanFilter API.
  • HARUS mendukung offloading pemindaian batch ke chipset bluetooth.

  • HARUS mendukung multi-iklan dengan minimal 4 slot.

  • [SR] SANGAT DISARANKAN untuk menerapkan waktu tunggu Resolvable Private Address (RPA) tidak lebih dari 15 menit dan merotasi alamat saat waktu tunggu habis untuk melindungi privasi pengguna.

Jika implementasi perangkat mendukung Bluetooth LE dan menggunakan Bluetooth LE untuk pemindaian lokasi, perangkat tersebut:

  • [C-4-1] HARUS memberikan kemampuan pengguna untuk mengaktifkan/menonaktifkan nilai yang dibaca melalui BluetoothAdapter.isBleScanAlwaysAvailable() System API.

7.4.4. Komunikasi Nirkabel Jarak Dekat

Implementasi perangkat:

  • HARUS menyertakan transceiver dan hardware terkait untuk Komunikasi Nirkabel Jarak Dekat (NFC).
  • [C-0-1] HARUS mengimplementasikan API android.nfc.NdefMessage dan android.nfc.NdefRecord meskipun tidak menyertakan dukungan untuk NFC atau mendeklarasikan fitur android.hardware.nfc karena class mewakili format representasi data yang tidak bergantung pada protokol.

Jika implementasi perangkat menyertakan hardware NFC dan berencana menyediakannya untuk aplikasi pihak ketiga, perangkat tersebut:

  • [C-1-1] HARUS melaporkan fitur android.hardware.nfc dari metode android.content.pm.PackageManager.hasSystemFeature().
  • HARUS dapat membaca dan menulis pesan NDEF melalui standar NFC berikut seperti di bawah ini:
  • [C-1-2] HARUS dapat bertindak sebagai pembaca/penulis Forum NFC (sebagaimana ditentukan oleh spesifikasi teknis Forum NFC NFCForum-TS-DigitalProtocol-1.0) melalui standar NFC berikut:
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS X 6319-4)
    • IsoDep (ISO 14443-4)
    • Jenis Tag NFC Forum 1, 2, 3, 4, 5 (ditentukan oleh NFC Forum)

  • [SR] SANGAT DISARANKAN agar dapat membaca dan menulis pesan NDEF serta data mentah melalui standar NFC berikut. Perhatikan bahwa meskipun standar NFC dinyatakan sebagai SANGAT DIUJI, Definisi Kompatibilitas untuk versi mendatang direncanakan untuk mengubahnya menjadi HARUS. Standar ini bersifat opsional dalam versi ini, tetapi akan diperlukan dalam versi mendatang. Perangkat lama dan baru yang menjalankan versi Android ini sangat disarankan untuk memenuhi persyaratan ini sekarang sehingga dapat diupgrade ke rilis platform mendatang.

  • [C-1-3] HARUS dapat mengirim dan menerima data melalui standar dan protokol peer-to-peer berikut:

    • ISO 18092
    • LLCP 1.2 (ditentukan oleh NFC Forum)
    • SDP 1.0 (ditentukan oleh NFC Forum)
    • Protokol Push NDEF
    • SNEP 1.0 (ditentukan oleh NFC Forum)
  • [C-1-4] HARUS menyertakan dukungan untuk Android Beam dan HARUS mengaktifkan Android Beam secara default.
  • [C-1-5] HARUS dapat mengirim dan menerima menggunakan Android Beam, saat Android Beam diaktifkan atau mode P2P NFC eksklusif lainnya diaktifkan.
  • [C-1-6] HARUS menerapkan server default SNEP. Pesan NDEF yang valid yang diterima oleh server SNEP default HARUS dikirim ke aplikasi menggunakan intent android.nfc.ACTION_NDEF_DISCOVERED. Menonaktifkan Android Beam di setelan TIDAK BOLEH menonaktifkan pengiriman pesan NDEF yang masuk.
  • [C-1-7] HARUS mematuhi intent android.settings.NFCSHARING_SETTINGS untuk menampilkan setelan berbagi NFC.
  • [C-1-8] HARUS mengimplementasikan server NPP. Pesan yang diterima oleh server NPP HARUS diproses dengan cara yang sama seperti server default SNEP.
  • [C-1-9] HARUS menerapkan klien SNEP dan mencoba mengirim NDEF P2P keluar ke server SNEP default saat Android Beam diaktifkan. Jika tidak ada server SNEP default yang ditemukan, klien HARUS mencoba mengirim ke server NPP.
  • [C-1-10] HARUS mengizinkan aktivitas latar depan untuk menetapkan pesan NDEF P2P keluar menggunakan android.nfc.NfcAdapter.setNdefPushMessage, dan android.nfc.NfcAdapter.setNdefPushMessageCallback, dan android.nfc.NfcAdapter.enableForegroundNdefPush.
  • HARUS menggunakan gestur atau konfirmasi di layar, seperti 'Sentuh untuk Beam', sebelum mengirim pesan NDEF P2P keluar.
  • [C-1-11] HARUS mendukung pengalihan Koneksi NFC ke Bluetooth saat perangkat mendukung Profil Push Objek Bluetooth.
  • [C-1-12] HARUS mendukung pengalihan koneksi ke Bluetooth saat menggunakan android.nfc.NfcAdapter.setBeamPushUris, dengan menerapkan spesifikasi “Connection Handover versi 1.2” dan “Bluetooth Secure Simple Pairing Using NFC versi 1.0” dari NFC Forum. Implementasi tersebut HARUS menerapkan layanan LLCP handover dengan nama layanan “urn:nfc:sn:handover” untuk bertukar permintaan handover/data yang dipilih melalui NFC, dan HARUS menggunakan Profil Push Objek Bluetooth untuk transfer data Bluetooth yang sebenarnya. Untuk alasan lama (agar tetap kompatibel dengan perangkat Android 4.1), penerapan HARUS tetap menerima permintaan GET SNEP untuk bertukar permintaan handover/data tertentu melalui NFC. Namun, implementasi itu sendiri TIDAK BOLEH mengirim permintaan GET SNEP untuk melakukan pengalihan koneksi.
  • [C-1-13] HARUS melakukan polling untuk semua teknologi yang didukung saat dalam mode penemuan NFC.
  • HARUS dalam mode penemuan NFC saat perangkat aktif dengan layar aktif dan layar kunci tidak terkunci.
  • HARUS dapat membaca kode batang dan URL (jika dienkode) produk Kode Batang NFC Thinfilm.

Perhatikan bahwa link yang tersedia untuk publik tidak tersedia untuk spesifikasi JIS, ISO, dan NFC Forum yang dikutip di atas.

Android menyertakan dukungan untuk mode Host Card Emulation (HCE) NFC.

Jika implementasi perangkat menyertakan chipset pengontrol NFC yang mampu melakukan HCE (untuk NfcA dan/atau NfcB) dan mendukung pemilihan rute ID Aplikasi (AID), perangkat tersebut:

  • [C-2-1] HARUS melaporkan konstanta fitur android.hardware.nfc.hce.
  • [C-2-2] HARUS mendukung NFC HCE API seperti yang ditentukan dalam Android SDK.

Jika implementasi perangkat menyertakan chipset pengontrol NFC yang mampu melakukan HCE untuk NfcF, dan menerapkan fitur untuk aplikasi pihak ketiga, perangkat tersebut:

  • [C-3-1] HARUS melaporkan konstanta fitur android.hardware.nfc.hcef.
  • [C-3-2] HARUS mengimplementasikan NfcF Card Emulation API seperti yang ditentukan dalam Android SDK.

Jika implementasi perangkat menyertakan dukungan NFC umum seperti yang dijelaskan di bagian ini dan mendukung teknologi MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF di MIFARE Classic) dalam peran pembaca/penulis, perangkat tersebut:

  • [C-4-1] HARUS mengimplementasikan API Android yang sesuai seperti yang didokumentasikan oleh Android SDK.
  • [C-4-2] HARUS melaporkan fitur com.nxp.mifare dari metode android.content.pm.PackageManager.hasSystemFeature(). Perhatikan bahwa ini bukan fitur Android standar sehingga tidak muncul sebagai konstanta di class android.content.pm.PackageManager.

7.4.5. Kemampuan Jaringan Minimum

Implementasi perangkat:

  • [C-0-1] HARUS menyertakan dukungan untuk satu atau beberapa bentuk jaringan data. Secara khusus, implementasi perangkat HARUS menyertakan dukungan untuk setidaknya satu standar data yang mampu mencapai 200 Kbit/detik atau lebih tinggi. Contoh teknologi yang memenuhi persyaratan ini meliputi EDGE, HSPA, EV-DO, 802.11g, Ethernet, dan Bluetooth PAN.
  • HARUS juga menyertakan dukungan untuk setidaknya satu standar data nirkabel umum, seperti 802.11 (Wi-Fi), jika standar jaringan fisik (seperti Ethernet) adalah koneksi data utama.
  • DAPAT menerapkan lebih dari satu bentuk konektivitas data.
  • [C-0-2] HARUS menyertakan stack jaringan IPv6 dan mendukung komunikasi IPv6 menggunakan API terkelola, seperti java.net.Socket dan java.net.URLConnection, serta API native, seperti soket AF_INET6.
  • [C-0-3] HARUS mengaktifkan IPv6 secara default.
  • HARUS memastikan bahwa komunikasi IPv6 sama andal dengan IPv4, misalnya:
    • [C-0-4] HARUS mempertahankan konektivitas IPv6 dalam mode tidur.
    • [C-0-5] Pembatasan kapasitas TIDAK BOLEH menyebabkan perangkat kehilangan konektivitas IPv6 di jaringan yang mematuhi IPv6 yang menggunakan masa aktif RA minimal 180 detik.
  • [C-0-6] HARUS menyediakan konektivitas IPv6 langsung ke jaringan untuk aplikasi pihak ketiga saat terhubung ke jaringan IPv6, tanpa terjemahan alamat atau port apa pun yang terjadi secara lokal di perangkat. API terkelola seperti Socket#getLocalAddress atau Socket#getLocalPort) dan API NDK seperti getsockname() atau IPV6_PKTINFO HARUS menampilkan alamat IP dan port yang sebenarnya digunakan untuk mengirim dan menerima paket di jaringan.

Tingkat dukungan IPv6 yang diperlukan bergantung pada jenis jaringan, seperti yang ditunjukkan dalam persyaratan berikut.

Jika implementasi perangkat mendukung Wi-Fi, perangkat tersebut:

  • [C-1-1] HARUS mendukung operasi dual-stack dan khusus IPv6 di Wi-Fi.

Jika penerapan perangkat mendukung Ethernet, perangkat tersebut:

  • [C-2-1] HARUS mendukung operasi stack ganda di Ethernet.

Jika implementasi perangkat mendukung Data seluler, perangkat tersebut:

  • HARUS mendukung operasi IPv6 (khusus IPv6 dan mungkin dual-stack) di seluler.

Jika implementasi perangkat mendukung lebih dari satu jenis jaringan (mis., Wi-Fi dan data seluler), mereka:

  • [C-3-1] HARUS secara bersamaan memenuhi persyaratan di atas di setiap jaringan saat perangkat terhubung secara bersamaan ke lebih dari satu jenis jaringan.

7.4.6. Setelan Sinkronisasi

Implementasi perangkat:

  • [C-0-1] HARUS mengaktifkan setelan sinkronisasi otomatis master secara default sehingga metode getMasterSyncAutomatically() menampilkan “true”.

7.4.7. Penghemat Data

Jika implementasi perangkat menyertakan koneksi berbayar, koneksi tersebut:

  • [SR] SANGAT DISARANKAN untuk menyediakan mode penghemat data.

Jika implementasi perangkat menyediakan mode penghemat data, implementasi tersebut:

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

  • [C-2-1] HARUS menampilkan nilai RESTRICT_BACKGROUND_STATUS_DISABLED untuk ConnectivityManager.getRestrictBackgroundStatus()
  • [C-2-2] TIDAK BOLEH menyiarkan ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.
  • [C-2-3] HARUS memiliki aktivitas yang menangani intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, tetapi DAPAT menerapkannya sebagai no-op.

7.4.8. Elemen Pengaman

Jika implementasi perangkat mendukung elemen aman yang kompatibel dengan Open Mobile API dan menyediakannya untuk aplikasi pihak ketiga, implementasi tersebut:

7.5. Kamera

Jika implementasi perangkat menyertakan minimal satu kamera, perangkat tersebut:

  • [C-1-1] HARUS mendeklarasikan flag fitur android.hardware.camera.any.
  • [C-1-2] HARUS memungkinkan aplikasi mengalokasikan 3 bitmap RGBA_8888 secara bersamaan yang sama dengan ukuran gambar yang dihasilkan oleh sensor kamera beresolusi terbesar di perangkat, saat kamera terbuka untuk tujuan pratinjau dasar dan pengambilan gambar diam.

7.5.1. Kamera Belakang

Kamera belakang adalah kamera yang terletak di sisi perangkat yang berlawanan dengan layar; yaitu, kamera ini mengambil gambar di sisi jauh perangkat, seperti kamera tradisional.

Implementasi perangkat:

  • HARUS menyertakan kamera belakang.

Jika implementasi perangkat menyertakan minimal satu kamera belakang, perangkat tersebut:

  • [C-1-1] HARUS melaporkan flag fitur android.hardware.camera dan android.hardware.camera.any.
  • [C-1-2] HARUS memiliki resolusi minimal 2 megapiksel.
  • HARUS memiliki fokus otomatis hardware atau fokus otomatis software yang diterapkan di driver kamera (transparan untuk software aplikasi).
  • MUNGKIN memiliki hardware fokus tetap atau EDOF (extended depth of field).
  • DAPAT menyertakan flash.

Jika kamera dilengkapi dengan flash:

  • [C-2-1] lampu flash TIDAK BOLEH menyala saat instance android.hardware.Camera.PreviewCallback telah terdaftar di platform pratinjau Kamera, kecuali jika aplikasi telah mengaktifkan flash secara eksplisit 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 pihak ketiga yang menggunakan Camera.PreviewCallback.

7.5.2. Kamera Depan

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

Implementasi perangkat:

  • DAPAT menyertakan kamera depan.

Jika implementasi perangkat menyertakan minimal satu kamera depan, perangkat tersebut:

  • [C-1-1] HARUS melaporkan flag fitur android.hardware.camera.any dan android.hardware.camera.front.
  • [C-1-2] HARUS memiliki resolusi minimal VGA (640x480 piksel).
  • [C-1-3] TIDAK BOLEH menggunakan kamera depan sebagai default untuk Camera API dan TIDAK BOLEH mengonfigurasi API untuk memperlakukan kamera depan sebagai kamera belakang default, meskipun itu satu-satunya kamera di perangkat.
  • [C-1-4] Pratinjau kamera HARUS dicerminkan secara horizontal relatif terhadap orientasi yang ditentukan oleh aplikasi saat aplikasi saat ini secara eksplisit meminta agar layar Kamera diputar melalui panggilan ke metode android.hardware.Camera.setDisplayOrientation(). Sebaliknya, pratinjau HARUS dicerminkan di sepanjang sumbu horizontal default perangkat jika aplikasi saat ini tidak secara eksplisit meminta tampilan Kamera diputar melalui panggilan ke metode android.hardware.Camera.setDisplayOrientation().
  • [C-1-5] TIDAK BOLEH mencerminkan gambar diam atau streaming video akhir yang diambil dan ditampilkan ke callback aplikasi atau di-commit ke penyimpanan media.
  • [C-1-6] HARUS mencerminkan gambar yang ditampilkan oleh postview dengan cara yang sama seperti streaming gambar pratinjau kamera.
  • DAPAT mencakup fitur (seperti fokus otomatis, flash, dll.) yang tersedia untuk kamera belakang seperti yang dijelaskan dalam bagian 7.5.1.

Jika implementasi perangkat dapat diputar oleh pengguna (seperti secara otomatis melalui akselerometer atau secara manual melalui input pengguna):

  • [C-2-1] Pratinjau kamera HARUS dicerminkan secara horizontal relatif terhadap orientasi perangkat saat ini.

7.5.3. Kamera Eksternal

Implementasi perangkat:

  • DAPAT menyertakan dukungan untuk kamera eksternal yang tidak selalu terhubung.

Jika implementasi perangkat menyertakan dukungan untuk kamera eksternal, implementasi tersebut:

  • [C-1-1] HARUS mendeklarasikan flag fitur platform android.hardware.camera.external dan android.hardware camera.any.
  • [C-1-2] HARUS mendukung USB Video Class (UVC 1.0 atau yang lebih tinggi) jika kamera eksternal terhubung melalui port host USB.
  • [C-1-3] HARUS lulus pengujian CTS kamera dengan perangkat kamera eksternal fisik yang terhubung. Detail pengujian CTS kamera tersedia di source.android.com.
  • HARUS mendukung kompresi video seperti MJPEG untuk memungkinkan transfer streaming yang tidak dienkode berkualitas tinggi (yaitu streaming gambar mentah atau yang dikompresi secara independen).
  • DAPAT mendukung beberapa kamera.
  • DAPAT mendukung encoding video berbasis kamera.

Jika encoding video berbasis kamera didukung:

  • [C-2-1] Streaming MJPEG / tanpa encoding simultan (resolusi QVGA atau lebih tinggi) HARUS dapat diakses oleh implementasi perangkat.

7.5.4. Perilaku Camera API

Android menyertakan dua paket API untuk mengakses kamera, android.hardware.camera2 API yang lebih baru mengekspos kontrol kamera tingkat rendah ke aplikasi, termasuk alur burst/streaming zero-copy yang efisien dan kontrol per frame eksposur, gain, gain white balance, konversi warna, denoising, sharpening, dan lainnya.

Paket API yang lebih lama,android.hardware.Camera, ditandai sebagai tidak digunakan lagi di Android 5.0, tetapi masih tersedia untuk digunakan aplikasi. Implementasi perangkat Android HARUS memastikan dukungan berkelanjutan API seperti yang dijelaskan di bagian ini dan di Android SDK.

Semua fitur yang umum antara class android.hardware.Camera yang tidak digunakan lagi dan paket android.hardware.camera2 yang lebih baru HARUS memiliki performa dan kualitas yang setara di kedua API. Misalnya, dengan setelan yang setara, kecepatan dan akurasi fokus otomatis harus sama, dan kualitas gambar yang diambil harus sama. Fitur yang bergantung pada semantik yang berbeda dari kedua API tidak diwajibkan untuk memiliki kecepatan atau kualitas yang cocok, tetapi HARUS cocok sedekat mungkin.

Implementasi perangkat HARUS menerapkan perilaku berikut untuk API terkait kamera, untuk semua kamera yang tersedia. Implementasi perangkat:

  • [C-0-1] HARUS menggunakan android.hardware.PixelFormat.YCbCr_420_SP untuk data pratinjau yang diberikan ke callback aplikasi jika aplikasi belum pernah memanggil android.hardware.Camera.Parameters.setPreviewFormat(int).
  • [C-0-2] HARUS lebih lanjut dalam format encoding NV21 saat aplikasi mendaftarkan instance android.hardware.Camera.PreviewCallback dan sistem memanggil metode onPreviewFrame() dan format pratinjau adalah YCbCr_420_SP, data dalam byte[] diteruskan ke onPreviewFrame(). Artinya, NV21 HARUS menjadi default.
  • [C-0-3] HARUS mendukung format YV12 (seperti yang ditunjukkan oleh konstanta android.graphics.ImageFormat.YV12) untuk pratinjau kamera untuk kamera depan dan belakang untuk android.hardware.Camera. (Encoder video dan kamera hardware dapat menggunakan format piksel native apa pun, tetapi implementasi perangkat HARUS mendukung konversi ke YV12.)
  • [C-0-4] HARUS mendukung format android.hardware.ImageFormat.YUV_420_888 dan android.hardware.ImageFormat.JPEG sebagai output melalui android.media.ImageReader API untuk perangkat android.hardware.camera2 yang mengiklankan kemampuan REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE di android.request.availableCapabilities.
  • [C-0-5] HARUS tetap menerapkan Camera API lengkap yang disertakan dalam dokumentasi Android SDK, terlepas dari apakah perangkat menyertakan fokus otomatis hardware atau kemampuan lainnya. Misalnya, kamera yang tidak memiliki fokus otomatis HARUS tetap memanggil instance android.hardware.Camera.AutoFocusCallback yang terdaftar (meskipun hal ini tidak relevan dengan kamera non-fokus otomatis). Perhatikan bahwa hal ini berlaku untuk kamera depan; misalnya, meskipun sebagian besar kamera depan tidak mendukung fokus otomatis, callback API masih harus "dipalsukan" seperti yang dijelaskan.
  • [C-0-6] HARUS mengenali dan mematuhi setiap nama parameter yang ditentukan sebagai konstanta pada class android.hardware.Camera.Parameters. Sebaliknya, implementasi perangkat TIDAK BOLEH mematuhi atau mengenali konstanta string yang diteruskan ke metode android.hardware.Camera.setParameters() selain yang didokumentasikan sebagai konstanta di android.hardware.Camera.Parameters. Artinya, implementasi perangkat HARUS mendukung semua parameter Kamera standar jika hardware mengizinkan, dan TIDAK BOLEH mendukung jenis parameter Kamera kustom. Misalnya, implementasi perangkat yang mendukung pengambilan gambar menggunakan teknik pencitraan rentang dinamis tinggi (HDR) HARUS mendukung parameter kamera Camera.SCENE_MODE_HDR.
  • [C-0-7] HARUS melaporkan tingkat dukungan yang sesuai dengan properti android.info.supportedHardwareLevel seperti yang dijelaskan di Android SDK dan melaporkan flag fitur framework yang sesuai.
  • [C-0-8] JUGA HARUS mendeklarasikan kemampuan kamera individual android.hardware.camera2 melalui properti android.request.availableCapabilities dan mendeklarasikan flag fitur yang sesuai; HARUS menentukan flag fitur jika ada perangkat kamera yang terpasang yang mendukung fitur tersebut.
  • [C-0-9] HARUS menyiarkan intent Camera.ACTION_NEW_PICTURE setiap kali gambar baru diambil oleh kamera dan entri gambar telah ditambahkan ke penyimpanan media.
  • [C-0-10] HARUS menyiarkan intent Camera.ACTION_NEW_VIDEO setiap kali video baru direkam oleh kamera dan entri gambar telah ditambahkan ke penyimpanan media.
  • [C-SR] SANGAT DISARANKAN untuk mendukung perangkat kamera logis yang mencantumkan kemampuan CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, untuk perangkat dengan beberapa kamera yang menghadap ke arah yang sama, yang terdiri dari setiap kamera fisik yang menghadap ke arah tersebut, selama jenis kamera fisik didukung oleh framework dan CameraCharacteristics.INFO_SUPPORTED_HARDWARE_LEVEL untuk kamera fisik adalah LIMITED, FULL, atau LEVEL_3.

7.5.5. Orientasi Kamera

Jika implementasi perangkat memiliki kamera depan atau belakang, kamera tersebut:

  • [C-1-1] HARUS diorientasikan sehingga dimensi panjang kamera sejajar dengan dimensi panjang layar. Artinya, saat perangkat dipegang dalam orientasi lanskap, kamera HARUS mengambil gambar dalam orientasi lanskap. Hal ini berlaku terlepas dari orientasi alami perangkat; yaitu, berlaku untuk perangkat utama lanskap serta perangkat utama potret.

7.6. Memori dan Penyimpanan

7.6.1. Memori dan Penyimpanan Minimum

Implementasi perangkat:

  • [C-0-1] HARUS menyertakan Pengelola Download yang DAPAT digunakan aplikasi untuk mendownload file data dan HARUS dapat mendownload setiap file berukuran minimal 100 MB ke lokasi "cache" default.

7.6.2. Penyimpanan Bersama Aplikasi

Implementasi perangkat:

  • [C-0-1] HARUS menawarkan penyimpanan untuk dibagikan oleh aplikasi, yang juga sering disebut sebagai “penyimpanan eksternal bersama”, "penyimpanan bersama aplikasi", atau dengan jalur Linux "/sdcard" tempat penyimpanan tersebut dipasang.
  • [C-0-2] HARUS dikonfigurasi dengan penyimpanan bersama yang dipasang secara default, dengan kata lain “langsung pakai”, terlepas dari apakah penyimpanan diterapkan pada komponen penyimpanan internal atau media penyimpanan yang dapat dilepas (misalnya slot kartu Secure Digital).
  • [C-0-3] HARUS memasang penyimpanan bersama aplikasi langsung di jalur Linux sdcard atau menyertakan link simbolis Linux dari sdcard ke titik pemasangan yang sebenarnya.
  • [C-0-4] HARUS menerapkan izin android.permission.WRITE_EXTERNAL_STORAGE pada penyimpanan bersama ini seperti yang didokumentasikan dalam SDK. Penyimpanan bersama HARUS dapat ditulis oleh aplikasi apa pun yang mendapatkan izin tersebut.

Implementasi perangkat DAPAT memenuhi persyaratan di atas menggunakan salah satu dari hal berikut:

  • Penyimpanan portabel yang dapat diakses pengguna, seperti slot kartu Secure Digital (SD).
  • Sebagian penyimpanan internal (tidak dapat dilepas) seperti yang diterapkan di Project Open Source Android (AOSP).

Jika implementasi perangkat menggunakan penyimpanan yang dapat dilepas untuk memenuhi persyaratan di atas, implementasi tersebut:

  • [C-1-1] HARUS menerapkan antarmuka pengguna toast atau pop-up yang memperingatkan pengguna saat tidak ada media penyimpanan yang dimasukkan ke dalam slot.
  • [C-1-2] HARUS menyertakan media penyimpanan berformat FAT (misalnya, kartu SD) atau menunjukkan pada kotak dan materi lain yang tersedia pada saat pembelian bahwa media penyimpanan harus dibeli secara terpisah.

Jika implementasi perangkat menggunakan sebagian penyimpanan yang tidak dapat dilepas untuk memenuhi persyaratan di atas, implementasi tersebut:

  • HARUS menggunakan penerapan AOSP untuk penyimpanan bersama aplikasi internal.
  • DAPAT berbagi ruang penyimpanan dengan data pribadi aplikasi.

Jika implementasi perangkat menyertakan beberapa jalur penyimpanan bersama (seperti slot kartu SD dan penyimpanan internal bersama), jalur tersebut:

  • [C-2-1] HARUS hanya mengizinkan aplikasi Android bawaan dan dengan hak istimewa dengan izin WRITE_EXTERNAL_STORAGE untuk menulis ke penyimpanan eksternal sekunder, kecuali saat menulis ke direktori khusus paketnya atau dalam URI yang ditampilkan dengan mengaktifkan intent ACTION_OPEN_DOCUMENT_TREE.

Jika implementasi perangkat memiliki port USB dengan dukungan mode periferal USB, perangkat tersebut:

  • [C-3-1] HARUS menyediakan mekanisme untuk mengakses data di penyimpanan bersama aplikasi dari komputer host.
  • HARUS mengekspos konten dari kedua jalur penyimpanan secara transparan melalui layanan pemindai media Android dan android.provider.MediaStore.
  • DAPAT menggunakan penyimpanan massal USB, tetapi HARUS menggunakan Media Transfer Protocol untuk memenuhi persyaratan ini.

Jika implementasi perangkat memiliki port USB dengan mode periferal USB dan mendukung Media Transfer Protocol, perangkat tersebut:

  • HARUS kompatibel dengan host MTP Android referensi, Android File Transfer.
  • HARUS melaporkan class perangkat USB 0x00.
  • HARUS melaporkan nama antarmuka USB 'MTP'.

7.6.3. Penyimpanan yang Dapat Diadaptasi

Jika perangkat diharapkan bersifat seluler, tidak seperti Televisi, implementasi perangkat adalah:

  • [SR] SANGAT DISARANKAN untuk menerapkan penyimpanan yang dapat diadopsi di lokasi yang stabil dalam jangka panjang, karena jika tidak sengaja terputus, penyimpanan tersebut dapat menyebabkan kehilangan/kerusakan data.

Jika port perangkat penyimpanan yang dapat dilepas berada di lokasi yang stabil dalam jangka panjang, seperti di dalam kompartemen baterai atau penutup pelindung lainnya, implementasi perangkat adalah:

7.7. USB

Jika implementasi perangkat memiliki port USB, perangkat tersebut:

  • HARUS mendukung mode periferal USB dan HARUS mendukung mode host USB.

7.7.1. Mode periferal USB

Jika implementasi perangkat menyertakan port USB yang mendukung mode periferal:

  • [C-1-1] Port HARUS dapat dihubungkan ke host USB yang memiliki port USB type-A atau type-C standar.
  • [C-1-2] HARUS melaporkan nilai iSerialNumber yang benar dalam deskripsi perangkat standar USB melalui android.os.Build.SERIAL.
  • [C-1-3] HARUS mendeteksi pengisi daya 1,5 A dan 3,0 A sesuai standar resistor Type-C dan HARUS mendeteksi perubahan dalam iklan jika mendukung USB Type-C.
  • [SR] Port HARUS menggunakan faktor bentuk USB micro-B, micro-AB, atau Type-C. Perangkat Android yang ada dan baru SANGAT DISARANKAN untuk memenuhi persyaratan ini sehingga dapat diupgrade ke rilis platform mendatang.
  • [SR] Port HARUS berada di bagian bawah perangkat (sesuai dengan orientasi alami) atau mengaktifkan rotasi layar software untuk semua aplikasi (termasuk layar utama), sehingga layar digambar dengan benar saat perangkat diorientasikan dengan port di bagian bawah. Perangkat Android yang ada dan baru SANGAT DISARANKAN untuk memenuhi persyaratan ini agar dapat diupgrade ke rilis platform mendatang.
  • [SR] HARUS menerapkan dukungan untuk menarik arus 1,5 A selama chirp dan traffic HS seperti yang ditentukan dalam spesifikasi Pengisian Daya Baterai USB, revisi 1.2. Perangkat Android yang ada dan baru SANGAT DISARANKAN untuk memenuhi persyaratan ini sehingga dapat diupgrade ke rilis platform mendatang.
  • [SR] SANGAT DISARANKAN untuk tidak mendukung metode pengisian daya eksklusif yang mengubah voltase Vbus di luar level default, atau mengubah peran sink/sumber karena dapat menyebabkan masalah interoperabilitas dengan pengisi daya atau perangkat yang mendukung metode USB Power Delivery standar. Meskipun hal ini disebut sebagai "SANGAT DIUJAMI", pada versi Android mendatang, kami mungkin MEWAJIBKAN semua perangkat tipe C untuk mendukung interoperabilitas penuh dengan pengisi daya tipe C standar.
  • [SR] SANGAT DISARANKAN untuk mendukung Pengiriman Daya untuk pertukaran peran data dan daya jika mendukung USB Type-C dan mode host USB.
  • HARUS mendukung Pengiriman Daya untuk pengisian daya bertegangan tinggi dan dukungan untuk Mode Alternatif seperti output layar.
  • HARUS menerapkan API dan spesifikasi Android Open Accessory (AOA) seperti yang didokumentasikan dalam dokumentasi Android SDK.

Jika implementasi perangkat menyertakan port USB dan menerapkan spesifikasi AOA, implementasi tersebut:

  • [C-2-1] HARUS mendeklarasikan dukungan untuk fitur hardware android.hardware.usb.accessory.
  • [C-2-2] Class penyimpanan massal USB HARUS menyertakan string "android" di akhir string iInterface deskripsi antarmuka penyimpanan massal USB

7.7.2. Mode host USB

Jika implementasi perangkat menyertakan port USB yang mendukung mode host, port tersebut:

  • [C-1-1] HARUS menerapkan API host USB Android seperti yang didokumentasikan di Android SDK dan HARUS mendeklarasikan dukungan untuk fitur hardware android.hardware.usb.host.
  • [C-1-2] HARUS menerapkan dukungan untuk menghubungkan periferal USB standar, dengan kata lain, perangkat HARUS:
    • Memiliki port type C di perangkat atau dikirimkan dengan kabel yang mengadaptasi port eksklusif di perangkat ke port USB type-C standar (perangkat USB Type-C).
    • Memiliki port jenis A di perangkat atau dilengkapi dengan kabel yang mengadaptasi port eksklusif di perangkat ke port USB jenis A standar.
    • Memiliki port micro-AB di perangkat, yang HARUS dilengkapi dengan kabel yang beradaptasi dengan port tipe A standar.
  • [C-1-3] TIDAK BOLEH dikirimkan dengan adaptor yang mengonversi dari port USB tipe A atau micro-AB ke port tipe C (penampung).
  • [SR] SANGAT DIUJAMI untuk menerapkan class audio USB seperti yang didokumentasikan dalam dokumentasi Android SDK.
  • HARUS mendukung pengisian daya perangkat periferal USB yang terhubung saat dalam mode host; mengiklankan arus sumber minimal 1,5 A seperti yang ditentukan di bagian Parameter Penghentian dalam Spesifikasi Konektor dan Kabel USB Type-C Revisi 1.2 untuk konektor USB Type-C atau menggunakan rentang arus output Port Arus Turun Pengisian Daya(CDP) seperti yang ditentukan dalam Spesifikasi Pengisian Daya Baterai USB, revisi 1.2 untuk konektor Micro-AB.
  • HARUS menerapkan dan mendukung standar USB Type-C.

Jika implementasi perangkat menyertakan port USB yang mendukung mode host dan class audio USB, port tersebut:

  • [C-2-1] HARUS mendukung class HID USB.
  • [C-2-2] HARUS mendukung deteksi dan pemetaan kolom data HID berikut yang ditentukan dalam Tabel Penggunaan USB HID dan Permintaan Penggunaan Perintah Suara ke konstanta KeyEvent seperti di bawah ini:
    • ID Penggunaan Halaman Penggunaan (0xC) (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
    • Halaman Penggunaan (0xC) ID Penggunaan (0x0E9): KEYCODE_VOLUME_UP
    • ID Penggunaan Halaman Penggunaan (0xC) (0x0EA): KEYCODE_VOLUME_DOWN
    • Halaman Penggunaan (0xC) ID Penggunaan (0x0CF): KEYCODE_VOICE_ASSIST

Jika implementasi perangkat menyertakan port USB yang mendukung mode host dan Storage Access Framework (SAF), port tersebut:

  • [C-3-1] HARUS mengenali perangkat MTP (Media Transfer Protocol) yang terhubung dari jarak jauh dan membuat kontennya dapat diakses melalui intent ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, dan ACTION_CREATE_DOCUMENT. .

Jika implementasi perangkat menyertakan port USB yang mendukung mode host dan USB Type-C, port tersebut:

  • [C-4-1] HARUS menerapkan fungsi Port Ganda seperti yang ditentukan oleh spesifikasi USB Type-C (bagian 4.5.1.3.3).
  • [SR] SANGAT DISARANKAN untuk mendukung DisplayPort, HARUS mendukung Kecepatan Data SuperSpeed USB, dan SANGAT DISARANKAN untuk mendukung Power Delivery untuk pertukaran peran data dan daya.
  • [SR] SANGAT DISARANKAN untuk TIDAK mendukung Mode Aksesori Adaptor Audio seperti yang dijelaskan dalam Lampiran A Spesifikasi Kabel dan Konektor USB Type-C Revisi 1.2.
  • HARUS menerapkan model Try.* yang paling sesuai untuk faktor bentuk perangkat. Misalnya, perangkat genggam HARUS menerapkan model Try.SNK.

7.8. Audio

7.8.1. Mikrofon

Jika implementasi perangkat menyertakan mikrofon, mikrofon tersebut:

  • [C-1-1] HARUS melaporkan konstanta fitur android.hardware.microphone.
  • [C-1-2] HARUS memenuhi persyaratan perekaman audio di bagian 5.4.
  • [C-1-3] HARUS memenuhi persyaratan latensi audio di bagian 5.6.
  • [SR] SANGAT DIUJAMI 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 menerapkan API perekaman audio setidaknya sebagai no-ops, sesuai bagian 7.

7.8.2. Output Audio

Jika implementasi perangkat menyertakan speaker atau port output audio/multimedia untuk periferal output audio seperti jack audio 3,5 mm 4 konduktor atau port mode host USB menggunakan class audio USB, perangkat tersebut:

  • [C-1-1] HARUS melaporkan konstanta fitur android.hardware.audio.output.
  • [C-1-2] HARUS memenuhi persyaratan pemutaran audio di bagian 5.5.
  • [C-1-3] HARUS memenuhi persyaratan latensi audio di bagian 5.6.
  • [SR] SANGAT DIUJAMI untuk mendukung pemutaran mendekati ultrasonik seperti yang dijelaskan di bagian 7.8.3.

Jika implementasi perangkat tidak menyertakan speaker atau port output audio, implementasi tersebut:

  • [C-2-1] TIDAK BOLEH melaporkan fitur android.hardware.audio.output.
  • [C-2-2] HARUS menerapkan API terkait Output Audio setidaknya sebagai no-ops.

Untuk tujuan bagian ini, "port output" adalah antarmuka fisik seperti jack audio 3,5 mm, HDMI, atau port mode host USB dengan class audio USB. Dukungan untuk output audio melalui protokol berbasis radio seperti Bluetooth, Wi-Fi, atau jaringan seluler tidak memenuhi syarat untuk menyertakan "port output".

7.8.2.1. Port Audio Analog

Agar kompatibel dengan headset dan aksesori audio lainnya yang menggunakan steker audio 3,5 mm di seluruh ekosistem Android, jika implementasi perangkat menyertakan satu atau beberapa port audio analog, port tersebut:

  • [C-SR] SANGAT DISARANKAN untuk menyertakan minimal satu port audio sebagai jack audio 3,5 mm 4 konduktor.

Jika implementasi perangkat memiliki jack audio 3,5 mm dengan 4 konduktor, perangkat tersebut:

  • [C-1-1] HARUS mendukung pemutaran audio ke headphone stereo dan headset stereo dengan mikrofon.
  • [C-1-2] HARUS mendukung steker audio TRRS dengan urutan pin CTIA.
  • [C-1-3] HARUS mendukung deteksi dan pemetaan ke kode kunci untuk 3 rentang impedansi ekivalen berikut antara konduktor mikrofon dan ground pada steker audio:
    • 70 ohm atau kurang: KEYCODE_HEADSETHOOK
    • 210-290 ohm: KEYCODE_VOLUME_UP
    • 360-680 ohm: KEYCODE_VOLUME_DOWN
  • [C-1-4] HARUS memicu ACTION_HEADSET_PLUG saat steker dimasukkan, tetapi hanya setelah semua kontak pada steker menyentuh segmen yang relevan di jack.
  • [C-1-5] HARUS dapat menggerakkan setidaknya 150 mV ± 10% tegangan output pada impedansi speaker 32 ohm.
  • [C-1-6] HARUS memiliki voltase bias mikrofon antara 1,8 V ~ 2,9 V.
  • [C-1-7] HARUS mendeteksi dan memetakan ke kode kunci untuk rentang impedansi ekivalen berikut antara konduktor mikrofon dan ground pada steker audio:
    • 110-180 ohm: KEYCODE_VOICE_ASSIST
  • [C-SR] SANGAT DISARANKAN untuk mendukung steker audio dengan urutan pin OMTP.
  • [C-SR] SANGAT DISARANKAN untuk mendukung perekaman audio dari headset stereo dengan mikrofon.

Jika implementasi perangkat memiliki jack audio 3,5 mm 4 konduktor dan mendukung mikrofon, serta menyiarkan android.intent.action.HEADSET_PLUG dengan mikrofon nilai tambahan yang ditetapkan sebagai 1, perangkat tersebut:

  • [C-2-1] HARUS mendukung deteksi mikrofon pada aksesori audio yang dicolokkan.

7.8.3. Ultrasonografi Dekat

Audio Near-Ultrasound adalah band 18,5 kHz hingga 20 kHz.

Implementasi perangkat:

  • HARUS melaporkan dukungan kemampuan audio near-ultrasound dengan benar melalui API AudioManager.getProperty sebagai berikut:

Jika PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND adalah "true", persyaratan berikut HARUS dipenuhi oleh sumber audio VOICE_RECOGNITION dan UNPROCESSED:

  • [C-1-1] Respons daya rata-rata mikrofon dalam band 18,5 kHz hingga 20 kHz HARUS tidak lebih dari 15 dB di bawah respons pada 2 kHz.
  • [C-1-2] Rasio sinyal terhadap derau mikrofon yang tidak tertimbang di atas 18,5 kHz hingga 20 kHz untuk nada 19 kHz pada -26 dBFS HARUS tidak lebih rendah dari 50 dB.

Jika PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND adalah "true":

  • [C-2-1] Respons rata-rata speaker dalam 18,5 kHz - 20 kHz HARUS tidak lebih rendah dari 40 dB di bawah respons pada 2 kHz.

7.9. Virtual Reality

Android menyertakan API dan fasilitas untuk membuat aplikasi "Virtual Reality" (VR) termasuk pengalaman VR seluler berkualitas tinggi. Implementasi perangkat HARUS menerapkan API dan perilaku ini dengan benar, seperti yang dijelaskan di bagian ini.

7.9.1. Mode Virtual Reality

Android menyertakan dukungan untuk Mode VR, fitur yang menangani rendering stereoskopik notifikasi dan menonaktifkan komponen UI sistem monokular saat aplikasi VR memiliki fokus pengguna.

7.9.2. Mode Virtual Reality - Performa Tinggi

Jika implementasi perangkat mendukung mode VR, implementasi tersebut:

  • [C-1-1] HARUS memiliki minimal 2 core fisik.
  • [C-1-2] HARUS mendeklarasikan fitur android.hardware.vr.high_performance.
  • [C-1-3] HARUS mendukung mode performa berkelanjutan.
  • [C-1-4] HARUS mendukung OpenGL ES 3.2.
  • [C-1-5] HARUS mendukung android.hardware.vulkan.level 0.
  • HARUS mendukung android.hardware.vulkan.level 1 atau yang lebih tinggi.
  • [C-1-6] HARUS 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 mengekspos ekstensi dalam daftar ekstensi EGL yang tersedia.
  • [C-1-8] HARUS mengimplementasikan GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_OVR_multiview_multisampled_render_to_texture, GL_EXT_protected_textures, dan mengekspos ekstensi dalam daftar ekstensi GL yang tersedia.
  • [C-SR] SANGAT DISARANKAN untuk menerapkan GL_EXT_external_buffer, GL_EXT_EGL_image_array, dan mengekspos ekstensi dalam daftar ekstensi GL yang tersedia.
  • [C-SR] SANGAT DISARANKAN untuk mendukung Vulkan 1.1.
  • [C-SR] SANGAT DIUJUDKAN untuk mengimplementasikan VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image, dan mengeksposnya dalam daftar ekstensi Vulkan yang tersedia.
  • [C-SR] SANGAT DIUJAMI untuk mengekspos minimal satu keluarga antrean Vulkan dengan flags berisi VK_QUEUE_GRAPHICS_BIT dan VK_QUEUE_COMPUTE_BIT, serta queueCount minimal 2.
  • [C-1-7] GPU dan layar HARUS dapat menyinkronkan akses ke buffering depan bersama sehingga rendering mata bergantian konten VR pada 60 fps dengan dua konteks render akan ditampilkan tanpa artefak tearing yang terlihat.
  • [C-1-9] HARUS menerapkan dukungan untuk flag AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA, dan AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT seperti yang dijelaskan di NDK.
  • [C-1-10] HARUS menerapkan dukungan untuk AHardwareBuffer dengan kombinasi flag penggunaan AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT untuk setidaknya format berikut: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
  • [C-SR] SANGAT DIUJUDKAN untuk mendukung alokasi AHardwareBuffer dengan lebih dari satu lapisan serta flag dan format yang ditentukan di C-1-10.
  • [C-1-11] HARUS mendukung decoding H.264 minimal 3840 x 2160 pada 30 fps, yang dikompresi menjadi rata-rata 40 Mbps (setara dengan 4 instance 1920 x 1080 pada 30 fps-10 Mbps atau 2 instance 1920 x 1080 pada 60 fps-20 Mbps).
  • [C-1-12] HARUS mendukung HEVC dan VP9, HARUS dapat mendekode setidaknya 1920x1080 pada 30 fps yang dikompresi hingga rata-rata 10 Mbps dan HARUS dapat mendekode 3840x2160 pada 30 fps-20 Mbps (setara dengan 4 instance 1920x1080 pada 30 fps-5 Mbps).
  • [C-1-13] HARUS mendukung HardwarePropertiesManager.getDeviceTemperatures API dan menampilkan nilai yang akurat untuk suhu kulit.
  • [C-1-14] HARUS memiliki layar tersemat, dan resolusinya HARUS minimal 1920x1080.
  • [C-SR] SANGAT DISARANKAN untuk memiliki resolusi layar minimal 2560x1440.
  • [C-1-15] Layar HARUS diperbarui setidaknya 60 Hz saat dalam Mode VR.
  • [C-1-17] Layar HARUS mendukung mode persistensi rendah dengan persistensi ≤ 5 milidetik, persistensi didefinisikan sebagai jumlah waktu piksel memancarkan cahaya.
  • [C-1-18] HARUS mendukung Bluetooth 4.2 dan Bluetooth LE Data Length Extension bagian 7.4.3.
  • [C-1-19] HARUS mendukung dan melaporkan Jenis Saluran Langsung dengan benar untuk semua jenis sensor default berikut:
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED
  • [C-SR] SANGAT DIUTAMAKAN untuk mendukung jenis saluran langsung TYPE_HARDWARE_BUFFER untuk semua Jenis Saluran Langsung yang tercantum di atas.
  • [C-1-21] HARUS memenuhi persyaratan terkait giroskop, akselerometer, dan magnetometer untuk android.hardware.hifi_sensors, seperti yang ditentukan dalam bagian 7.3.9.
  • [C-SR] SANGAT DIUJAMI untuk mendukung fitur android.hardware.sensor.hifi_sensors.
  • [C-1-22] HARUS memiliki latensi gerakan ke foton menyeluruh tidak lebih tinggi dari 28 milidetik.
  • [C-SR] SANGAT DISARANKAN untuk memiliki latensi gerakan ke foton menyeluruh tidak lebih tinggi dari 20 milidetik.
  • [C-1-23] HARUS memiliki rasio frame pertama, yaitu rasio antara kecerahan piksel pada frame pertama setelah transisi dari hitam ke putih dan kecerahan piksel putih dalam status stabil, minimal 85%.
  • [C-SR] SANGAT DISARANKAN untuk memiliki rasio frame pertama minimal 90%.
  • DAPAT menyediakan core eksklusif ke aplikasi latar depan dan DAPAT mendukung Process.getExclusiveCores API untuk menampilkan jumlah core CPU yang eksklusif untuk aplikasi latar depan teratas.

Jika core eksklusif didukung, core tersebut:

  • [C-2-1] HARUS tidak mengizinkan proses ruang pengguna lain berjalan di dalamnya (kecuali driver perangkat yang digunakan oleh aplikasi), tetapi DAPAT mengizinkan beberapa proses kernel berjalan sesuai kebutuhan.

8. Performa dan Daya

Beberapa kriteria performa dan daya minimum sangat penting untuk pengalaman pengguna dan memengaruhi asumsi dasar yang akan dimiliki developer saat mengembangkan aplikasi.

8.1. Konsistensi Pengalaman Pengguna

Antarmuka pengguna yang lancar dapat diberikan kepada pengguna akhir jika ada persyaratan minimum tertentu untuk memastikan kecepatan frame dan waktu respons yang konsisten untuk aplikasi dan game. Implementasi perangkat, bergantung pada jenis perangkat, MUNGKIN memiliki persyaratan yang dapat diukur untuk latensi antarmuka pengguna dan pengalihan tugas seperti yang dijelaskan di bagian 2.

8.2. Performa Akses I/O File

Menyediakan dasar pengukuran umum untuk performa akses file yang konsisten di penyimpanan data pribadi aplikasi (partisi /data) memungkinkan developer aplikasi menetapkan ekspektasi yang tepat yang akan membantu desain software mereka. Implementasi perangkat, bergantung pada jenis perangkat, MUNGKIN memiliki persyaratan tertentu yang dijelaskan di bagian 2 untuk operasi baca dan tulis berikut:

  • Performa operasi tulis berurutan. Diukur dengan menulis file 256 MB menggunakan buffer tulis 10 MB.
  • Performa operasi tulis acak. Diukur dengan menulis file 256 MB menggunakan buffer tulis 4 KB.
  • Performa baca berurutan. Diukur dengan membaca file 256 MB menggunakan buffer tulis 10 MB.
  • Performa baca acak. Diukur dengan membaca file 256 MB menggunakan buffer tulis 4 KB.

8.3. Mode Hemat Daya

Jika implementasi perangkat menyertakan fitur untuk meningkatkan pengelolaan daya perangkat yang disertakan dalam AOSP atau memperluas fitur yang disertakan dalam AOSP, implementasi tersebut:

  • [C-1-1] TIDAK BOLEH menyimpang dari implementasi AOSP untuk algoritma pemicu, pemeliharaan, dan pengaktifan serta penggunaan setelan sistem global untuk mode hemat daya Mode Standby Aplikasi dan Mode Istirahatkan.
  • [C-1-2] TIDAK BOLEH menyimpang dari penerapan AOSP untuk penggunaan setelan global guna mengelola throttling tugas, alarm, dan jaringan untuk aplikasi di setiap bucket untuk mode standby Aplikasi.
  • [C-1-3] TIDAK BOLEH menyimpang dari implementasi AOSP untuk jumlah Bucket Aplikasi Standby yang digunakan untuk Aplikasi Standby.
  • [C-1-4] HARUS menerapkan Bucket Aplikasi Standby dan Mode Istirahatkan seperti yang dijelaskan dalam Pengelolaan Daya.
  • [C-1-5] HARUS menampilkan true untuk PowerManager.isPowerSaveMode() saat perangkat dalam mode hemat daya.
  • [C-SR] SANGAT DIUTAMAKAN untuk memberikan kemampuan pengguna untuk mengaktifkan dan menonaktifkan fitur penghemat baterai.
  • [C-SR] SANGAT DISARANKAN untuk memberikan kemampuan kepada pengguna untuk menampilkan semua Aplikasi yang dikecualikan dari mode hemat daya Aplikasi Standby dan Mode Tidur.

Selain mode hemat daya, implementasi perangkat Android DAPAT menerapkan salah satu atau semua dari 4 status daya tidur seperti yang ditentukan oleh Advanced Configuration and Power Interface (ACPI).

Jika implementasi perangkat menerapkan status daya S4 seperti yang ditentukan oleh ACPI, implementasi tersebut:

  • [C-1-1] HARUS memasuki status ini hanya setelah pengguna melakukan tindakan eksplisit untuk menempatkan perangkat dalam status tidak aktif (misalnya, dengan menutup penutup yang secara fisik merupakan bagian dari perangkat atau mematikan kendaraan atau televisi) dan sebelum pengguna mengaktifkan kembali perangkat (misalnya, dengan membuka penutup atau menyalakan kembali kendaraan atau televisi).

Jika implementasi perangkat menerapkan status daya S3 seperti yang ditentukan oleh ACPI, implementasi tersebut:

  • [C-2-1] HARUS memenuhi C-1-1 di atas, atau, HARUS memasuki status S3 hanya jika aplikasi pihak ketiga tidak memerlukan resource sistem (misalnya, layar, CPU).

    Sebaliknya, HARUS keluar dari status S3 saat aplikasi pihak ketiga memerlukan resource sistem, seperti yang dijelaskan di SDK ini.

    Misalnya, saat aplikasi pihak ketiga meminta untuk tetap mengaktifkan layar melalui FLAG_KEEP_SCREEN_ON atau tetap menjalankan CPU melalui PARTIAL_WAKE_LOCK, perangkat TIDAK BOLEH memasuki status S3 kecuali, seperti yang dijelaskan dalam C-1-1, pengguna telah mengambil tindakan eksplisit untuk menempatkan perangkat dalam status tidak aktif. Sebaliknya, saat tugas yang diterapkan aplikasi pihak ketiga melalui JobScheduler dipicu atau Firebase Cloud Messaging dikirim ke aplikasi pihak ketiga, perangkat HARUS keluar dari status S3 kecuali jika pengguna telah menempatkan perangkat dalam status tidak aktif. Ini bukan contoh yang komprehensif dan AOSP menerapkan sinyal bangun yang ekstensif yang memicu bangun dari status ini.

8.4. Akuntansi Konsumsi Daya

Pencatatan dan pelaporan konsumsi daya yang lebih akurat memberikan insentif dan alat kepada developer aplikasi untuk mengoptimalkan pola penggunaan daya aplikasi.

Implementasi perangkat:

  • [SR] SANGAT DISARANKAN untuk memberikan profil daya per komponen yang menentukan nilai konsumsi saat ini untuk setiap komponen hardware dan perkiraan pemakaian baterai yang disebabkan oleh komponen dari waktu ke waktu seperti yang didokumentasikan di situs Android Open Source Project.
  • [SR] SANGAT DIUJAMI untuk melaporkan semua nilai konsumsi daya dalam miliamper jam (mAh).
  • [SR] SANGAT DIUJAMI untuk melaporkan konsumsi daya CPU per setiap UID proses. Project Open Source Android memenuhi persyaratan melalui penerapan modul kernel uid_cputime.
  • [SR] SANGAT DIUJAMI untuk menyediakan penggunaan daya ini melalui perintah shell adb shell dumpsys batterystats kepada developer aplikasi.
  • HARUS diatribusikan ke komponen hardware itu sendiri jika tidak dapat mengatribusikan penggunaan daya komponen hardware ke aplikasi.

8.5. Performa yang Konsisten

Performa dapat berfluktuasi secara drastis untuk aplikasi berperforma tinggi yang berjalan lama, baik karena aplikasi lain yang berjalan di latar belakang atau throttling CPU karena batas suhu. Android menyertakan antarmuka terprogram sehingga saat perangkat mampu, aplikasi latar depan teratas dapat meminta sistem untuk mengoptimalkan alokasi resource guna mengatasi fluktuasi tersebut.

Implementasi perangkat:

Jika implementasi perangkat melaporkan dukungan Mode Performa Berkelanjutan, implementasi tersebut:

  • [C-1-1] HARUS memberikan tingkat performa yang konsisten kepada aplikasi latar depan teratas selama minimal 30 menit, saat aplikasi memintanya.
  • [C-1-2] HARUS mematuhi Window.setSustainedPerformanceMode() API dan API terkait lainnya.

Jika implementasi perangkat menyertakan dua core CPU atau lebih, core tersebut:

  • HARUS menyediakan minimal satu core eksklusif yang dapat dicadangkan oleh aplikasi latar depan teratas.

Jika implementasi perangkat mendukung reservasi satu core eksklusif untuk aplikasi latar depan teratas, implementasi tersebut:

  • [C-2-1] HARUS melaporkan nomor ID core eksklusif yang dapat dicadangkan oleh aplikasi latar depan teratas melalui metode API Process.getExclusiveCores().
  • [C-2-2] HARUS tidak mengizinkan proses ruang pengguna apa pun kecuali driver perangkat yang digunakan oleh aplikasi untuk berjalan di core eksklusif, tetapi DAPAT mengizinkan beberapa proses kernel berjalan sesuai kebutuhan.

Jika penerapan perangkat tidak mendukung core eksklusif, penerapan tersebut:

9. Kompatibilitas Model Keamanan

Implementasi perangkat:

  • [C-0-1] HARUS menerapkan model keamanan yang konsisten dengan model keamanan platform Android seperti yang ditentukan dalam Dokumen referensi Keamanan dan Izin di API dalam dokumentasi developer Android.

  • [C-0-2] HARUS mendukung penginstalan aplikasi yang ditandatangani sendiri tanpa memerlukan izin/sertifikat tambahan dari pihak ketiga/otoritas mana pun. Secara khusus, perangkat yang kompatibel HARUS mendukung mekanisme keamanan yang dijelaskan di subbagian berikut.

9.1. Izin

Implementasi perangkat:

  • [C-0-1] HARUS mendukung model izin Android seperti yang ditentukan dalam dokumentasi developer Android. Secara khusus, SDK HARUS menerapkan setiap izin yang ditentukan seperti yang dijelaskan dalam dokumentasi SDK; tidak ada izin yang boleh dihilangkan, diubah, atau diabaikan.

  • DAPAT menambahkan izin tambahan, asalkan string ID izin baru tidak berada dalam namespace android.\*.

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

Izin dengan tingkat perlindungan berbahaya adalah izin runtime. Aplikasi dengan targetSdkVersion > 22 memintanya saat runtime.

Implementasi perangkat:

  • [C-0-3] HARUS menampilkan antarmuka khusus bagi pengguna untuk memutuskan apakah akan memberikan izin runtime yang diminta dan juga menyediakan antarmuka bagi pengguna untuk mengelola izin runtime.
  • [C-0-4] HARUS memiliki satu dan hanya satu implementasi dari kedua antarmuka pengguna.
  • [C-0-5] TIDAK BOLEH memberikan izin runtime apa pun ke aplikasi bawaan kecuali jika:
    • Izin pengguna dapat diperoleh sebelum aplikasi menggunakannya.
    • Izin runtime dikaitkan dengan pola intent yang aplikasi bawaannya ditetapkan sebagai pengendali default.
  • [C-0-6] HARUS memberikan izin android.permission.RECOVER_KEYSTORE hanya ke aplikasi sistem yang mendaftarkan Agen Pemulihan yang diamankan dengan benar. Agen Pemulihan yang diamankan dengan benar didefinisikan sebagai agen software di perangkat yang disinkronkan dengan penyimpanan jarak jauh di luar perangkat, yang dilengkapi dengan hardware aman dengan perlindungan yang setara atau lebih kuat daripada yang dijelaskan di Layanan Google Cloud Key Vault untuk mencegah serangan brute force pada faktor pengetahuan layar kunci.

Jika implementasi perangkat menyertakan aplikasi yang diinstal sebelumnya atau ingin mengizinkan aplikasi pihak ketiga mengakses statistik penggunaan, perangkat tersebut:

  • [SR] SANGAT DISARANKAN untuk menyediakan mekanisme yang dapat diakses pengguna untuk memberikan atau mencabut akses ke statistik penggunaan sebagai respons terhadap intent android.settings.ACTION_USAGE_ACCESS_SETTINGS untuk aplikasi yang mendeklarasikan izin android.permission.PACKAGE_USAGE_STATS.

Jika implementasi perangkat ingin melarang aplikasi apa pun, termasuk aplikasi bawaan, mengakses statistik penggunaan, implementasi tersebut:

  • [C-1-1] HARUS tetap memiliki aktivitas yang menangani pola intent android.settings.ACTION_USAGE_ACCESS_SETTINGS, tetapi HARUS menerapkannya sebagai no-op, yaitu memiliki perilaku yang setara seperti saat pengguna ditolak aksesnya.

9.2. Isolasi UID dan Proses

Implementasi perangkat:

  • [C-0-1] HARUS mendukung model sandbox aplikasi Android, dengan setiap aplikasi berjalan sebagai UID gaya Unix yang unik dan dalam proses terpisah.
  • [C-0-2] HARUS mendukung pengoperasian beberapa aplikasi sebagai ID pengguna Linux yang sama, asalkan aplikasi ditandatangani dan dibuat dengan benar, seperti yang ditentukan dalam referensi Keamanan dan Izin.

9.3. Izin Sistem File

Implementasi perangkat:

9.4. Lingkungan Eksekusi Alternatif

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

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

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

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

  • [C-0-4] Runtime alternatif HARUS mematuhi model sandbox Android dan aplikasi terinstal yang menggunakan runtime alternatif TIDAK BOLEH menggunakan kembali sandbox aplikasi lain yang diinstal di perangkat, kecuali melalui mekanisme Android standar untuk ID pengguna bersama dan sertifikat penandatanganan.

  • [C-0-5] Runtime alternatif TIDAK BOLEH diluncurkan dengan, memberikan, atau diberi akses ke sandbox yang sesuai dengan aplikasi Android lainnya.

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

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

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

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

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

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

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

9.5. Dukungan Multi-Pengguna

Android menyertakan dukungan untuk beberapa pengguna dan memberikan dukungan untuk isolasi pengguna penuh.

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

Jika implementasi perangkat menyertakan beberapa pengguna, mereka:

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

Jika implementasi perangkat menyertakan beberapa pengguna dan tidak mendeklarasikan tanda fitur android.hardware.telephony, implementasi tersebut:

  • [C-2-1] HARUS mendukung profil terbatas, fitur yang memungkinkan pemilik perangkat mengelola pengguna tambahan dan kemampuan mereka di perangkat. Dengan profil yang dibatasi, pemilik perangkat dapat dengan cepat menyiapkan lingkungan terpisah untuk digunakan pengguna tambahan, dengan kemampuan untuk mengelola pembatasan yang lebih terperinci di aplikasi yang tersedia di lingkungan tersebut.

Jika implementasi perangkat menyertakan beberapa pengguna dan mendeklarasikan flag fitur android.hardware.telephony, implementasi tersebut:

  • [C-3-1] TIDAK BOLEH mendukung profil terbatas, tetapi HARUS selaras dengan penerapan kontrol AOSP untuk mengaktifkan /menonaktifkan pengguna lain agar tidak dapat mengakses panggilan suara dan SMS.

9.6. Peringatan SMS Premium

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

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

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

9.7. Fitur Keamanan

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

Sandbox Android menyertakan fitur yang menggunakan sistem kontrol akses wajib (MAC) Security-Enhanced Linux (SELinux), sandbox seccomp, dan fitur keamanan lainnya di kernel Linux. Implementasi perangkat:

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

Integritas kernel dan fitur perlindungan mandiri merupakan bagian integral dari keamanan Android. Implementasi perangkat:

  • [C-0-7] HARUS menerapkan perlindungan buffer overflow stack kernel (misalnya, CONFIG_CC_STACKPROTECTOR_STRONG).
  • [C-0-8] HARUS menerapkan perlindungan memori kernel yang ketat dengan kode yang dapat dieksekusi hanya dapat dibaca, data hanya baca tidak dapat dieksekusi dan tidak dapat ditulis, dan data yang dapat ditulis tidak dapat dieksekusi (misalnya, CONFIG_DEBUG_RODATA atau CONFIG_STRICT_KERNEL_RWX).
  • [C-0-9] HARUS menerapkan pemeriksaan batas ukuran objek statis dan dinamis dari salinan antara ruang pengguna dan ruang kernel (misalnya, CONFIG_HARDENED_USERCOPY) di perangkat yang awalnya dikirimkan dengan API level 28 atau yang lebih tinggi.
  • [C-0-10] TIDAK BOLEH mengeksekusi memori ruang pengguna saat dieksekusi dalam mode kernel (misalnya, PXN hardware, atau diemulasi melalui CONFIG_CPU_SW_DOMAIN_PAN atau CONFIG_ARM64_SW_TTBR0_PAN) di perangkat yang awalnya dikirimkan dengan API level 28 atau yang lebih tinggi.
  • [C-0-11] TIDAK BOLEH membaca atau menulis memori ruang pengguna di kernel di luar API akses usercopy normal (misalnya PAN hardware, atau diemulasi melalui CONFIG_CPU_SW_DOMAIN_PAN atau CONFIG_ARM64_SW_TTBR0_PAN) di perangkat yang awalnya dikirimkan dengan API level 28 atau yang lebih tinggi.
  • [C-0-12] HARUS menerapkan isolasi tabel halaman kernel di semua perangkat yang awalnya dikirimkan dengan API level 28 atau yang lebih tinggi (misalnya, CONFIG_PAGE_TABLE_ISOLATION atau `CONFIG_UNMAP_KERNEL_AT_EL0).
  • [SR] SANGAT DIUJAMI untuk menyimpan data kernel yang hanya ditulis selama inisialisasi yang ditandai hanya baca setelah inisialisasi (misalnya, __ro_after_init).
  • [SR] SANGAT DIUJAMI untuk melakukan randomisasi tata letak kode dan memori kernel, serta untuk menghindari eksposur yang akan membahayakan randomisasi (misalnya, CONFIG_RANDOMIZE_BASE dengan entropi bootloader melalui /chosen/kaslr-seed Device Tree node atau EFI_RNG_PROTOCOL).

Jika implementasi perangkat menggunakan kernel Linux, perangkat tersebut:

  • [C-1-1] HARUS menerapkan SELinux.
  • [C-1-2] HARUS menetapkan SELinux ke mode penerapan global.
  • [C-1-3] HARUS mengonfigurasi semua domain dalam mode penerapan. Tidak ada domain mode permisif yang diizinkan, termasuk domain khusus untuk perangkat/vendor.
  • [C-1-4] TIDAK BOLEH mengubah, menghapus, atau mengganti aturan neverallow yang ada dalam folder system/sepolicy yang disediakan di Project Open Source Android (AOSP) upstream dan kebijakan HARUS dikompilasi dengan semua aturan neverallow yang ada, 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 di sandbox SELinux per aplikasi dengan batasan SELinux per aplikasi pada direktori data pribadi setiap aplikasi.
  • HARUS mempertahankan kebijakan SELinux default yang disediakan di folder system/sepolicy dari Project Open Source Android upstream dan hanya menambahkan lebih lanjut ke kebijakan ini untuk konfigurasi khusus perangkat mereka sendiri.

Jika implementasi perangkat sudah diluncurkan pada versi Android sebelumnya dan tidak dapat memenuhi persyaratan [C-1-1] dan [C-1-5] melalui update software sistem, implementasi tersebut DAPAT dikecualikan dari persyaratan ini.

Jika implementasi perangkat menggunakan kernel selain Linux, implementasi tersebut:

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

Android berisi beberapa fitur pertahanan mendalam yang merupakan bagian integral dari keamanan perangkat.

Implementasi perangkat:

  • [C-SR] SANGAT DISARANKAN untuk tidak menonaktifkan Control-Flow Integrity (CFI) atau Integer Overflow Sanitization (IntSan) pada komponen yang mengaktifkannya.
  • [C-SR] SANGAT DISARANKAN untuk mengaktifkan CFI dan IntSan untuk komponen ruang pengguna sensitif keamanan tambahan seperti yang dijelaskan dalam CFI dan IntSan.

9.8. Privasi

9.8.1. Histori Penggunaan

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

Implementasi perangkat:

  • [C-0-1] HARUS mempertahankan periode retensi yang wajar untuk histori pengguna tersebut.
  • [SR] SANGAT DIUJAMI untuk mempertahankan periode retensi 14 hari seperti yang dikonfigurasi secara default dalam penerapan AOSP.

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

Implementasi perangkat:

  • [C-0-2] HANYA boleh menyertakan kolom yang ditandai dengan DEST_AUTOMATIC dalam laporan insiden yang dibuat oleh class System API IncidentManager.
  • [C-0-3] TIDAK BOLEH menggunakan ID peristiwa sistem untuk mencatat peristiwa lain selain yang dijelaskan dalam dokumen SDK StatsLog. Jika peristiwa sistem tambahan dicatat, peristiwa tersebut DAPAT menggunakan ID atom yang berbeda dalam rentang antara 100.000 dan 200.000.

9.8.2. Merekam

Implementasi perangkat:

  • [C-0-1] TIDAK BOLEH memuat ulang atau mendistribusikan komponen software bawaan yang mengirimkan informasi pribadi pengguna (misalnya, penekanan tombol, teks yang ditampilkan di layar) dari perangkat tanpa persetujuan pengguna atau notifikasi yang jelas yang sedang berlangsung.

Jika implementasi perangkat menyertakan fungsi dalam sistem yang merekam konten yang ditampilkan di layar dan/atau merekam streaming audio yang diputar di perangkat, implementasi tersebut:

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

Jika implementasi perangkat menyertakan komponen yang diaktifkan secara default, yang dapat merekam audio standby untuk menyimpulkan informasi yang berguna tentang konteks pengguna, perangkat tersebut:

  • [C-2-1] TIDAK BOLEH menyimpan audio mentah yang direkam atau format apa pun yang dapat dikonversi kembali menjadi audio asli atau hampir sama dengan faksimili, kecuali dengan izin pengguna yang eksplisit, di penyimpanan persisten di perangkat atau mengirimkannya dari perangkat.

9.8.3. Konektivitas

Jika implementasi perangkat memiliki port USB dengan dukungan mode periferal USB, perangkat tersebut:

  • [C-1-1] HARUS menampilkan antarmuka pengguna yang meminta izin pengguna sebelum mengizinkan akses ke konten penyimpanan bersama melalui port USB.

9.8.4. Traffic Jaringan

Implementasi perangkat:

  • [C-0-1] HARUS menginstal sebelumnya root certificate yang sama untuk penyimpanan Certificate Authority (CA) tepercaya sistem seperti yang disediakan di Project Open Source Android upstream.
  • [C-0-2] HARUS dikirimkan dengan penyimpanan root CA pengguna yang kosong.
  • [C-0-3] HARUS menampilkan peringatan kepada pengguna yang menunjukkan bahwa traffic jaringan dapat dipantau, saat CA root pengguna ditambahkan.

Jika traffic perangkat dialihkan melalui VPN, implementasi perangkat:

  • [C-1-1] HARUS menampilkan peringatan kepada pengguna yang menunjukkan:
    • Traffic jaringan tersebut dapat dipantau.
    • Traffic jaringan tersebut dirutekan melalui aplikasi VPN tertentu yang menyediakan VPN.

Jika implementasi perangkat memiliki mekanisme, yang diaktifkan secara default, yang merutekan traffic data jaringan melalui server proxy atau gateway VPN (misalnya, memuat layanan VPN secara otomatis dengan android.permission.CONTROL_VPN yang diberikan), mekanisme tersebut:

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

Jika implementasi perangkat menerapkan kemampuan pengguna untuk mengaktifkan fungsi "VPN yang selalu aktif" dari aplikasi VPN pihak ketiga, implementasi tersebut:

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

9.9. Enkripsi Penyimpanan Data

Jika performa kripto Advanced Encryption Standard (AES), yang diukur dengan teknologi AES berperforma terbaik yang tersedia di perangkat (misalnya, ARM Cryptography Extensions), di atas 50 MiB/detik, implementasi perangkat:

  • [C-1-1] HARUS mendukung enkripsi penyimpanan data data pribadi aplikasi (partisi /data), serta partisi penyimpanan bersama aplikasi (partisi /sdcard) jika merupakan bagian permanen yang tidak dapat dilepas dari perangkat, kecuali untuk implementasi perangkat yang biasanya dibagikan (misalnya, Televisi).
  • [C-1-2] HARUS mengaktifkan enkripsi penyimpanan data secara default pada saat pengguna menyelesaikan pengalaman penyiapan siap pakai, kecuali untuk implementasi perangkat yang biasanya dibagikan (misalnya, Televisi).

Jika performa kripto AES berada di atau di bawah 50 MiB/detik, implementasi perangkat DAPAT menggunakan Adiantum-XChaCha12-AES, bukan bentuk AES yang tercantum dalam salah satu hal berikut: AES-256-XTS di Bagian 9.9.2 [C-1-5]; AES-256 dalam mode CBS-CTS di Bagian 9.9.2 [C-1-6]; AES di Bagian 9.9.3 [C-1-1]; AES di Bagian 9.9.3 [C-1-3].

Jika implementasi perangkat sudah diluncurkan pada versi Android sebelumnya dan tidak dapat memenuhi persyaratan melalui update software sistem, implementasi tersebut DAPAT dikecualikan dari persyaratan di atas.

Implementasi perangkat:

  • HARUS memenuhi persyaratan enkripsi penyimpanan data di atas melalui penerapan Enkripsi Berbasis File (FBE).

9.9.1. Direct Boot

Implementasi perangkat:

  • [C-0-1] HARUS menerapkan API mode Booting Langsung meskipun tidak mendukung Enkripsi Penyimpanan.

  • [C-0-2] Intent ACTION_LOCKED_BOOT_COMPLETED dan ACTION_USER_UNLOCKED HARUS tetap disiarkan untuk memberi sinyal kepada aplikasi yang mendukung Direct Boot bahwa lokasi penyimpanan yang Dienkripsi Perangkat (DE) dan yang Dienkripsi Kredensial (CE) tersedia untuk pengguna.

9.9.2. Enkripsi Berbasis File

Jika implementasi perangkat mendukung FBE, implementasi tersebut:

  • [C-1-1] HARUS melakukan booting tanpa meminta kredensial pengguna dan mengizinkan aplikasi yang mendukung Direct Boot untuk mengakses penyimpanan yang Dienkripsi Perangkat (DE) setelah pesan ACTION_LOCKED_BOOT_COMPLETED disiarkan.
  • [C-1-2] HARUS hanya mengizinkan akses ke penyimpanan yang Dienkripsi dengan Kredensial (CE) setelah pengguna membuka kunci perangkat dengan memberikan kredensial mereka (misalnya, kode sandi, pin, pola, atau sidik jari) dan pesan ACTION_USER_UNLOCKED disiarkan.
  • [C-1-3] TIDAK BOLEH menawarkan metode apa pun untuk membuka kunci penyimpanan yang dilindungi CE tanpa kredensial yang diberikan pengguna atau kunci escrow terdaftar.
  • [C-1-4] HARUS mendukung Verified Boot dan memastikan bahwa kunci DE terikat secara kriptografis ke root of trust hardware perangkat.
  • [C-1-5] HARUS mendukung enkripsi konten file menggunakan AES-256-XTS. AES-256-XTS mengacu pada Advanced Encryption Standard dengan panjang kunci 256-bit, yang dioperasikan dalam mode XTS. Panjang penuh kunci XTS adalah 512 bit.

  • [C-1-6] HARUS mendukung enkripsi nama file menggunakan AES-256 dalam mode CBC-CTS.

  • Kunci yang melindungi area penyimpanan CE dan DE:

  • [C-1-7] HARUS terikat secara kriptografis ke Keystore yang didukung hardware.

  • [C-1-8] Kunci CE HARUS terikat dengan kredensial layar kunci pengguna.
  • [C-1-9] Kunci CE HARUS terikat dengan kode sandi default saat pengguna belum menentukan kredensial layar kunci.

  • [C-1-10] HARUS unik dan berbeda, dengan kata lain tidak ada kunci CE atau DE pengguna yang cocok dengan kunci CE atau DE pengguna lain.

  • [C-1-11] HARUS menggunakan cipher, panjang kunci, dan mode yang didukung secara wajib secara default.

  • [C-SR] SANGAT DISARANKAN untuk mengenkripsi metadata sistem file, seperti ukuran file, kepemilikan, mode, dan Atribut yang diperluas (xattr), dengan kunci yang terikat secara kriptografis ke root of trust hardware perangkat.

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

  • DAPAT mendukung cipher alternatif, panjang kunci, dan mode untuk konten file dan enkripsi nama file.

Project Open Source Android upstream menyediakan implementasi fitur ini yang lebih disukai berdasarkan fitur enkripsi ext4 kernel Linux.

9.9.3. Enkripsi Disk Penuh

Jika implementasi perangkat mendukung enkripsi disk penuh (FDE), implementasi tersebut:

  • [C-1-1] HARUS menggunakan AES dalam mode yang dirancang untuk penyimpanan (misalnya, XTS atau CBC-ESSIV), dan dengan panjang kunci cipher 128 bit atau lebih.
  • [C-1-2] HARUS menggunakan kode sandi default untuk menggabungkan kunci enkripsi dan TIDAK BOLEH menulis kunci enkripsi ke penyimpanan kapan saja tanpa dienkripsi.
  • [C-1-3] HARUS AES mengenkripsi kunci enkripsi secara default, kecuali jika pengguna secara eksplisit memilih tidak ikut, kecuali saat kunci enkripsi sedang digunakan secara aktif, dengan kredensial layar kunci yang diregangkan menggunakan algoritma peregangan lambat (misalnya PBKDF2 atau scrypt).
  • [C-1-4] Algoritma peregangan sandi default di atas HARUS terikat secara kriptografis ke keystore tersebut jika pengguna belum menentukan kredensial layar kunci atau telah menonaktifkan penggunaan kode sandi untuk enkripsi dan perangkat menyediakan keystore yang didukung hardware.
  • [C-1-5] TIDAK BOLEH mengirim kunci enkripsi dari perangkat (meskipun digabungkan dengan kode sandi pengguna dan/atau kunci yang terikat hardware).

Project Open Source Android upstream menyediakan implementasi fitur ini yang lebih disukai, berdasarkan fitur kernel Linux dm-crypt.

9.10. Integritas Perangkat

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

  • [C-0-1] HARUS melaporkan dengan benar melalui metode System API PersistentDataBlockManager.getFlashLockState() apakah status bootloader-nya mengizinkan flashing image sistem. Status FLASH_LOCK_UNKNOWN dicadangkan untuk implementasi perangkat yang diupgrade dari versi Android sebelumnya yang tidak memiliki metode API sistem baru ini.

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

Jika implementasi perangkat sudah diluncurkan tanpa mendukung Verified Boot di Android versi sebelumnya dan tidak dapat menambahkan dukungan untuk fitur ini dengan update software sistem, perangkat tersebut MUNGKIN dikecualikan dari persyaratan.

Booting Terverifikasi adalah fitur yang menjamin integritas software perangkat. Jika implementasi perangkat mendukung fitur ini, implementasi tersebut:

  • [C-1-1] HARUS mendeklarasikan flag fitur platform android.software.verified_boot.
  • [C-1-2] HARUS melakukan verifikasi pada setiap urutan booting.
  • [C-1-3] HARUS memulai verifikasi dari kunci hardware yang tidak dapat diubah yang merupakan root of trust dan terus ke atas hingga partisi sistem.
  • [C-1-4] HARUS menerapkan setiap tahap verifikasi untuk memeriksa integritas dan keaslian semua byte di tahap berikutnya sebelum menjalankan kode di tahap berikutnya.
  • [C-1-5] HARUS menggunakan algoritma verifikasi yang sekuat rekomendasi saat ini dari NIST untuk algoritma hashing (SHA-256) dan ukuran kunci publik (RSA-2048).
  • [C-1-6] TIDAK BOLEH mengizinkan booting selesai saat verifikasi sistem gagal, kecuali jika pengguna mengizinkan untuk mencoba melakukan booting, dalam hal ini data dari blok penyimpanan yang tidak diverifikasi TIDAK BOLEH digunakan.
  • [C-1-7] TIDAK BOLEH mengizinkan partisi terverifikasi di perangkat diubah kecuali jika pengguna telah secara eksplisit membuka kunci bootloader.
  • [C-SR] Jika ada beberapa chip terpisah di perangkat (misalnya, radio, prosesor gambar khusus), proses booting setiap chip tersebut SANGAT DISARANKAN untuk memverifikasi setiap tahap saat booting.
  • [C-1-8] HARUS menggunakan penyimpanan yang tahan modifikasi: untuk menyimpan apakah bootloader telah dibuka kuncinya. Penyimpanan yang tahan modifikasi berarti bahwa bootloader dapat mendeteksi apakah penyimpanan telah dimodifikasi dari dalam Android.
  • [C-1-9] HARUS meminta pengguna, saat menggunakan perangkat, dan mewajibkan konfirmasi fisik sebelum mengizinkan transisi dari mode bootloader terkunci ke mode bootloader tidak terkunci.
  • [C-1-10] HARUS menerapkan perlindungan rollback untuk partisi yang digunakan oleh Android (misalnya, booting, partisi sistem) dan menggunakan penyimpanan yang tahan modifikasi untuk menyimpan metadata yang digunakan untuk menentukan versi OS minimum yang diizinkan.
  • [C-SR] SANGAT DISARANKAN untuk memverifikasi semua file APK aplikasi dengan hak istimewa dengan rantai kepercayaan yang berakar di /system, yang dilindungi oleh Booting Terverifikasi.
  • [C-SR] SANGAT DISARANKAN untuk memverifikasi artefak yang dapat dieksekusi yang dimuat oleh aplikasi dengan hak istimewa dari luar file APK-nya (seperti kode yang dimuat secara dinamis atau kode yang dikompilasi) sebelum mengeksekusinya atau SANGAT DISARANKAN untuk tidak mengeksekusinya sama sekali.
  • HARUS menerapkan perlindungan rollback untuk komponen apa pun dengan firmware persisten (misalnya modem, kamera) dan HARUS menggunakan penyimpanan yang tahan modifikasi untuk menyimpan metadata yang digunakan untuk menentukan versi minimum yang diizinkan.

Jika implementasi perangkat sudah diluncurkan tanpa mendukung C-1-8 hingga C-1-10 di Android versi sebelumnya dan tidak dapat menambahkan dukungan untuk persyaratan ini dengan update software sistem, perangkat tersebut DAPAT dikecualikan dari persyaratan.

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

Implementasi perangkat:

Jika implementasi perangkat mendukung Android Protected Confirmation API, perangkat tersebut:

  • [C-3-1] HARUS melaporkan true untuk API ConfirmationPrompt.isSupported().
  • [C-3-2] HARUS memastikan bahwa hardware aman mengambil kontrol penuh atas layar sedemikian rupa sehingga Android OS tidak dapat memblokirnya tanpa deteksi oleh hardware aman.
  • [C-3-3] HARUS memastikan bahwa hardware aman mengambil kontrol penuh atas layar sentuh.

9.11. Kunci dan Kredensial

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

  • [C-0-1] HARUS mengizinkan minimal 8.192 kunci untuk diimpor atau dibuat.
  • [C-0-2] Autentikasi layar kunci HARUS membatasi kecepatan percobaan dan HARUS memiliki algoritma backoff eksponensial. Setelah 150 upaya gagal, penundaan HARUS minimal 24 jam per upaya.
  • HARUS tidak membatasi jumlah kunci yang dapat dibuat

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

  • [C-1-1] HARUS mencadangkan penerapan keystore dengan lingkungan eksekusi terisolasi.
  • [C-1-2] HARUS memiliki implementasi algoritma kriptografi RSA, AES, ECDSA, dan HMAC serta fungsi hash keluarga MD5, SHA1, dan SHA-2 untuk mendukung algoritma yang didukung sistem Android Keystore dengan benar di area yang terisolasi dengan aman dari kode yang berjalan di kernel dan yang lebih baru. Isolasi aman HARUS memblokir semua mekanisme potensial yang memungkinkan kode kernel atau ruang pengguna mengakses status internal lingkungan terisolasi, termasuk DMA. Project Open Source Android (AOSP) upstream memenuhi persyaratan ini dengan menggunakan implementasi Trusty, tetapi solusi berbasis ARM TrustZone lainnya atau implementasi aman yang ditinjau pihak ketiga dari isolasi berbasis hypervisor yang tepat adalah opsi alternatif.
  • [C-1-3] HARUS melakukan autentikasi layar kunci di lingkungan eksekusi terisolasi dan hanya jika berhasil, izinkan kunci yang terikat autentikasi untuk digunakan. Kredensial layar kunci HARUS disimpan dengan cara yang hanya mengizinkan trusted execution environment terisolasi untuk melakukan autentikasi layar kunci. Project Open Source Android upstream menyediakan Gatekeeper Hardware Abstraction Layer (HAL) dan Trusty, yang dapat digunakan untuk memenuhi persyaratan ini.
  • [C-1-4] HARUS mendukung pengesahan kunci dengan kunci penandatanganan pengesahan dilindungi oleh hardware aman dan penandatanganan dilakukan di hardware aman. Kunci penandatanganan pengesahan HARUS dibagikan di sejumlah perangkat yang cukup besar untuk mencegah kunci digunakan sebagai ID perangkat. Salah satu cara untuk memenuhi persyaratan ini adalah dengan membagikan kunci pengesahan yang sama,kecuali jika setidaknya 100.000 unit SKU tertentu diproduksi. Jika lebih dari 100.000 unit SKU diproduksi, kunci yang berbeda DAPAT digunakan untuk setiap 100.000 unit.
  • [C-1-5] HARUS mengizinkan pengguna memilih waktu tunggu Tidur untuk transisi dari status tidak terkunci ke terkunci, dengan waktu tunggu minimum yang diizinkan hingga 15 detik.

Perhatikan bahwa jika implementasi perangkat sudah diluncurkan pada versi Android sebelumnya, perangkat tersebut dikecualikan dari persyaratan untuk memiliki keystore yang didukung oleh lingkungan eksekusi terisolasi dan mendukung pengesahan kunci, kecuali jika mendeklarasikan fitur android.hardware.fingerprint yang memerlukan keystore yang didukung oleh lingkungan eksekusi terisolasi.

9.11.1. Layar Kunci Aman

Implementasi AOSP mengikuti model autentikasi bertingkat, dengan autentikasi utama berbasis knowledge-factory dapat didukung oleh biometrik sekunder yang kuat, atau oleh modalitas tersier yang lebih lemah.

Implementasi perangkat:

  • [C-SR] SANGAT DISARANKAN untuk menetapkan hanya salah satu dari opsi berikut sebagai metode autentikasi utama:
    • PIN numerik
    • Sandi alfanumerik
    • Pola geser pada petak yang terdiri dari 3x3 titik

Perhatikan bahwa metode autentikasi di atas disebut sebagai metode autentikasi utama yang direkomendasikan dalam dokumen ini.

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

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

  • [C-3-1] Entropi panjang input terpendek yang diizinkan HARUS lebih besar dari 10 bit.
  • [C-3-2] Entropi maksimum dari semua kemungkinan input HARUS lebih besar dari 18 bit.
  • [C-3-3] Metode autentikasi baru TIDAK BOLEH menggantikan metode autentikasi utama yang direkomendasikan (yaitu PIN, pola, sandi) yang diterapkan dan disediakan di AOSP.
  • [C-3-4] Metode autentikasi baru HARUS dinonaktifkan saat aplikasi Pengontrol Kebijakan Perangkat (DPC) telah menetapkan kebijakan kualitas sandi melalui metode DevicePolicyManager.setPasswordQuality() dengan konstanta kualitas yang lebih ketat daripada PASSWORD_QUALITY_SOMETHING.

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

  • [C-4-1] HARUS memenuhi semua persyaratan yang dijelaskan dalam bagian 7.3.10.2.
  • [C-4-2] HARUS memiliki mekanisme penggantian untuk menggunakan salah satu metode autentikasi utama yang direkomendasikan yang didasarkan pada rahasia yang diketahui.
  • [C-4-3] HARUS dinonaktifkan dan hanya mengizinkan autentikasi utama yang direkomendasikan untuk membuka kunci layar saat aplikasi Pengontrol Kebijakan Perangkat (DPC) telah menetapkan kebijakan fitur keguard dengan memanggil metode DevicePolicyManager.setKeyguardDisabledFeatures() , dengan tanda biometrik yang terkait (yaitu KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE, atau KEYGUARD_DISABLE_IRIS).
  • [C-4-4] HARUS meminta pengguna untuk melakukan autentikasi utama yang direkomendasikan (misalnya, PIN, pola, sandi) setidaknya sekali setiap 72 jam atau kurang.
  • [C-4-5] HARUS memiliki rasio penerimaan palsu yang sama atau lebih kuat dari yang diperlukan untuk sensor sidik jari seperti yang dijelaskan di bagian bagian 7.3.10, atau HARUS dinonaktifkan dan hanya mengizinkan autentikasi utama yang direkomendasikan untuk membuka kunci layar saat aplikasi Pengontrol Kebijakan Perangkat (DPC) telah menetapkan kebijakan kualitas sandi melalui metode DevicePolicyManager.setPasswordQuality() dengan konstanta kualitas yang lebih ketat daripada PASSWORD_QUALITY_BIOMETRIC_WEAK.
  • [C-SR] SANGAT DISARANKAN untuk memiliki tingkat penerimaan spoof dan penipu yang sama dengan atau lebih kuat dari yang diperlukan untuk sensor sidik jari seperti yang dijelaskan di bagian 7.3.10.
  • [C-4-6] HARUS memiliki pipeline pemrosesan yang aman sehingga kompromi sistem operasi atau kernel tidak dapat mengizinkan data dimasukkan secara langsung untuk mengautentikasi secara keliru sebagai pengguna.
  • [C-4-7] HARUS disambungkan dengan tindakan konfirmasi eksplisit (misalnya: penekanan tombol) untuk mengizinkan akses ke kunci keystore jika aplikasi menetapkan true untuk KeyGenParameterSpec.Built.setUserAuthenticationRequired() dan biometrik bersifat pasif (misalnya wajah atau iris jika tidak ada sinyal intent eksplisit).
  • [C-SR] Tindakan konfirmasi untuk biometrik pasif SANGAT DISARANKAN untuk diamankan sehingga penyusupan sistem operasi atau kernel tidak dapat melakukan spoofing. Misalnya, ini berarti bahwa tindakan konfirmasi berdasarkan tombol fisik dirutekan melalui pin input/output (GPIO) tujuan umum khusus input dari elemen aman (SE) yang tidak dapat didorong dengan cara lain selain menekan tombol fisik.

Jika metode autentikasi biometrik tidak memenuhi tingkat penerimaan spoof dan penipu seperti yang dijelaskan dalam bagian 7.3.10:

  • [C-5-1] Metode HARUS dinonaktifkan jika aplikasi Pengontrol Kebijakan Perangkat (DPC) telah menetapkan kebijakan kualitas sandi melalui metode DevicePolicyManager.setPasswordQuality() dengan konstanta kualitas yang lebih ketat daripada PASSWORD_QUALITY_BIOMETRIC_WEAK.
  • [C-5-2] Pengguna HARUS diminta untuk melakukan autentikasi primer yang direkomendasikan (misalnya: PIN, pola, sandi) setelah periode waktu tunggu tidak ada aktivitas selama 4 jam. Periode waktu tunggu tidak ada aktivitas akan direset setelah konfirmasi kredensial perangkat berhasil.
  • [C-5-3] Metode TIDAK BOLEH diperlakukan sebagai layar kunci yang aman, dan HARUS memenuhi persyaratan yang dimulai dengan C-8 di bagian ini di bawah.

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

  • [C-6-1] Layar kunci HARUS memiliki mekanisme penggantian untuk menggunakan salah satu metode autentikasi utama yang direkomendasikan yang didasarkan pada rahasia yang diketahui dan memenuhi persyaratan untuk diperlakukan sebagai layar kunci yang aman.
  • [C-6-2] Metode baru HARUS dinonaktifkan dan hanya mengizinkan salah satu metode autentikasi utama yang direkomendasikan untuk membuka kunci layar saat aplikasi Pengontrol Kebijakan Perangkat (DPC) telah menetapkan kebijakan dengan metode DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) atau metode DevicePolicyManager.setPasswordQuality() dengan konstanta kualitas yang lebih ketat daripada PASSWORD_QUALITY_UNSPECIFIED.
  • [C-6-3] Pengguna HARUS diminta untuk memasukkan salah satu metode autentikasi utama yang direkomendasikan (misalnya, PIN, pola, sandi) setidaknya sekali setiap 72 jam atau kurang.
  • [C-6-4] Metode baru TIDAK BOLEH diperlakukan sebagai layar kunci yang aman dan HARUS mengikuti batasan yang tercantum di C-8 di bawah.

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

  • [C-7-1] HARUS memiliki indikasi yang jelas di menu setelan dan di layar kunci saat kunci perangkat ditangguhkan atau dapat dibuka oleh agen tepercaya. Misalnya, AOSP memenuhi persyaratan ini dengan menampilkan deskripsi teks untuk "Setelan kunci otomatis" dan "Tombol daya langsung mengunci" di menu setelan dan ikon yang dapat dibedakan di layar kunci.
  • [C-7-2] HARUS mematuhi dan menerapkan sepenuhnya semua API agen kepercayaan di class DevicePolicyManager, seperti konstanta KEYGUARD_DISABLE_TRUST_AGENTS.
  • [C-7-3] TIDAK BOLEH sepenuhnya menerapkan fungsi TrustAgentService.addEscrowToken() di perangkat yang digunakan sebagai perangkat pribadi utama (misalnya perangkat genggam), tetapi BOLEH sepenuhnya menerapkan fungsi tersebut pada implementasi perangkat yang biasanya dibagikan (misalnya perangkat Android Television atau Automotive).
  • [C-7-4] HARUS mengenkripsi semua token tersimpan yang ditambahkan oleh TrustAgentService.addEscrowToken().
  • [C-7-5] TIDAK BOLEH menyimpan kunci enkripsi di perangkat yang sama dengan tempat kunci digunakan. Misalnya, kunci yang disimpan di ponsel diizinkan untuk membuka kunci akun pengguna di TV.
  • [C-7-6] HARUS memberi tahu pengguna tentang implikasi keamanan sebelum mengaktifkan token escrow untuk mendekripsi penyimpanan data.
  • [C-7-7] HARUS memiliki mekanisme penggantian untuk menggunakan salah satu metode autentikasi utama yang direkomendasikan.
  • [C-7-8] Pengguna HARUS diminta untuk memberikan salah satu metode autentikasi utama yang direkomendasikan (misalnya: PIN, pola, sandi) setidaknya sekali setiap 72 jam atau kurang.
  • [C-7-9] Pengguna HARUS diminta untuk menggunakan salah satu metode autentikasi utama yang direkomendasikan (misalnya: PIN, pola, sandi) setelah periode waktu tunggu tidak ada aktivitas selama 4 jam. Periode waktu tunggu tidak ada aktivitas akan direset setelah konfirmasi kredensial perangkat berhasil.
  • [C-7-10] TIDAK BOLEH diperlakukan sebagai layar kunci yang aman dan HARUS mengikuti batasan yang tercantum di C-8 di bawah.

Jika implementasi perangkat menambahkan atau mengubah metode autentikasi untuk membuka kunci layar yang bukan layar kunci aman seperti yang dijelaskan di atas, dan menggunakan metode autentikasi baru untuk membuka kunci pengaman kunci:

9.11.2. StrongBox

Sistem Android Keystore memungkinkan developer aplikasi menyimpan kunci kriptografis di prosesor aman khusus serta lingkungan eksekusi terisolasi yang dijelaskan di atas.

Implementasi perangkat:

  • [C-SR] SANGAT DISARANKAN untuk mendukung StrongBox.

Jika implementasi perangkat mendukung StrongBox, perangkat tersebut:

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

  • [C-1-2] HARUS menyediakan hardware aman khusus yang digunakan untuk mendukung keystore dan mengamankan autentikasi pengguna.

  • [C-1-3] HARUS memiliki CPU terpisah yang tidak berbagi cache, DRAM, koprosesor, atau resource inti lainnya dengan prosesor aplikasi (AP).

  • [C-1-4] HARUS memastikan bahwa periferal apa pun yang dibagikan ke AP tidak dapat mengubah pemrosesan StrongBox 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 sebenarnya yang menghasilkan output yang didistribusikan secara merata dan tidak dapat diprediksi.

  • [C-1-7] HARUS memiliki ketahanan terhadap modifikasi tidak sah, termasuk ketahanan terhadap penetrasi fisik, dan gangguan.

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

  • [C-1-9] HARUS memiliki penyimpanan aman yang memastikan kerahasiaan, integritas, keaslian, konsistensi, dan kesegaran konten. Penyimpanan TIDAK BOLEH dapat dibaca atau diubah, kecuali jika diizinkan oleh StrongBox API.

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

    • [C-1-10] HARUS menyertakan hardware yang disertifikasi terhadap Profil Perlindungan IC Aman BSI-CC-PP-0084-2014 atau dievaluasi oleh laboratorium pengujian terakreditasi secara nasional yang menggabungkan penilaian kerentanan potensi serangan Tinggi sesuai dengan Common Criteria Application of Attack Potential to Smartcards.
    • [C-1-11] HARUS menyertakan firmware yang dievaluasi oleh laboratorium pengujian terakreditasi secara nasional yang menggabungkan Penilaian kerentanan potensi serangan Tinggi sesuai dengan Common Criteria Application of Attack Potential to Smartcards.
    • [C-SR] SANGAT DISARANKAN untuk menyertakan hardware yang dievaluasi menggunakan Security Target, Evaluation Assurance Level (EAL) 5, yang dilengkapi dengan AVA_VAN.5. Sertifikasi EAL 5 kemungkinan akan menjadi persyaratan dalam rilis mendatang.

  • [C-SR] SANGAT DIUJUDKAN untuk memberikan ketahanan terhadap serangan pihak internal (IAR), yang berarti bahwa pihak internal dengan akses ke kunci penandatanganan firmware tidak dapat menghasilkan firmware yang menyebabkan StrongBox membocorkan rahasia, mengabaikan persyaratan keamanan fungsional, atau mengaktifkan akses ke data pengguna yang sensitif. Cara yang direkomendasikan untuk menerapkan IAR adalah dengan mengizinkan update firmware hanya jika sandi pengguna utama diberikan melalui HAL IAuthSecret.

9.12. Penghapusan Data

Semua implementasi perangkat:

  • [C-0-1] HARUS memberikan mekanisme kepada pengguna untuk melakukan "Reset Data Pabrik".
  • [C-0-2] HARUS menghapus semua data buatan pengguna. Artinya, semua data kecuali hal berikut:
    • Image sistem
    • File sistem operasi apa pun yang diperlukan oleh image sistem
  • [C-0-3] HARUS menghapus data sedemikian rupa sehingga memenuhi standar industri yang relevan seperti NIST SP800-88.
  • [C-0-4] HARUS memicu proses "Reset Data Pabrik" di atas saat DevicePolicyManager.wipeData() API dipanggil oleh aplikasi Pengontrol Kebijakan Perangkat pengguna utama.
  • DAPAT menyediakan opsi penghapusan data cepat yang hanya melakukan penghapusan data logis.

9.13. Mode Booting Aman

Android menyediakan Mode Boot Aman, yang memungkinkan pengguna melakukan booting ke mode yang hanya mengizinkan aplikasi sistem yang telah diinstal sebelumnya untuk berjalan dan semua aplikasi pihak ketiga dinonaktifkan. Mode ini, yang dikenal sebagai "Safe Boot Mode", memberi pengguna kemampuan untuk meng-uninstal aplikasi pihak ketiga yang berpotensi membahayakan.

Implementasi perangkat adalah:

  • [SR] SANGAT DIUJAMI untuk menerapkan Mode Boot Aman.

Jika implementasi perangkat menerapkan Mode Boot Aman, implementasi tersebut:

  • [C-1-1] HARUS memberikan opsi kepada pengguna untuk memasuki Mode Boot Aman sedemikian rupa sehingga tidak dapat diganggu oleh aplikasi pihak ketiga yang diinstal di perangkat, kecuali jika aplikasi pihak ketiga adalah Pengontrol Kebijakan Perangkat dan telah menetapkan tanda UserManager.DISALLOW_SAFE_BOOT sebagai benar.

  • [C-1-2] HARUS memberikan kemampuan kepada pengguna untuk meng-uninstal aplikasi pihak ketiga dalam Mode Aman.

  • HARUS memberikan opsi kepada pengguna untuk memasuki Mode Booting Aman dari menu booting menggunakan alur kerja yang berbeda dengan booting normal.

9.14. Isolasi Sistem Kendaraan Otomotif

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

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

9.15. Paket Langganan

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

Semua implementasi perangkat:

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

10. Pengujian Kompatibilitas Software

Implementasi perangkat HARUS lulus semua pengujian yang dijelaskan di bagian ini. Namun, perlu diperhatikan bahwa tidak ada paket pengujian software yang sepenuhnya komprehensif. Oleh karena itu, pengimplementasi perangkat SANGAT DISARANKAN untuk membuat jumlah perubahan minimum pada referensi dan implementasi Android pilihan yang tersedia dari Project Open Source Android. Tindakan ini akan meminimalkan risiko munculnya bug yang menyebabkan inkompatibilitas yang memerlukan pengerjaan ulang dan potensi update perangkat.

10.1. Compatibility Test Suite (CTS)

Implementasi perangkat:

  • [C-0-1] HARUS lulus Android Compatibility Test Suite (CTS) yang tersedia dari Android Open Source Project, menggunakan software pengiriman akhir di perangkat.

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

CTS dirancang untuk dijalankan di perangkat yang sebenarnya. Seperti software lainnya, CTS itu sendiri mungkin berisi bug. CTS akan diberi versi secara terpisah dari Definisi Kompatibilitas ini, dan beberapa revisi CTS dapat dirilis untuk Android 9.

Implementasi perangkat:

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

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

10.2. Pemverifikasi CTS

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

Implementasi perangkat:

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

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

Implementasi perangkat:

  • [C-0-2] HARUS lulus semua pengujian untuk hardware yang dimilikinya; misalnya, jika perangkat memiliki akselerometer, perangkat HARUS menjalankan kasus pengujian Akselerasi dengan benar di CTS Verifier.

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

  • [C-0-2] Setiap perangkat dan setiap build HARUS menjalankan CTS Verifier dengan benar, seperti yang disebutkan di atas. Namun, karena banyak build yang sangat mirip, pengimplementasi perangkat tidak diharapkan untuk menjalankan Verifikator CTS secara eksplisit pada build yang hanya berbeda dengan cara yang tidak penting. Secara khusus, implementasi perangkat yang berbeda dari implementasi yang telah lulus CTS Verifier hanya dengan kumpulan lokalitas, branding, dll. yang disertakan DAPAT menghilangkan pengujian CTS Verifier.

11. Software yang Dapat Diupdate

  • [C-0-1] Implementasi perangkat HARUS menyertakan mekanisme untuk mengganti seluruh software sistem. Mekanisme ini tidak perlu melakukan upgrade “langsung”—yaitu, memulai ulang perangkat MUNGKIN diperlukan. Metode apa pun dapat digunakan, asalkan dapat menggantikan seluruh software yang diprainstal di perangkat. Misalnya, salah satu pendekatan berikut akan memenuhi persyaratan ini:

    • Download “Over-the-air (OTA)” dengan update offline melalui mulai ulang.
    • Update “Tethered” melalui USB dari PC host.
    • Update “Offline” melalui mulai ulang dan update dari file di penyimpanan yang dapat dilepas.

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

Jika implementasi perangkat menyertakan dukungan untuk koneksi data tanpa kuota seperti profil 802.11 atau Bluetooth PAN (Personal Area Network), maka:

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

Untuk implementasi perangkat yang diluncurkan dengan Android 6.0 dan yang lebih baru, mekanisme update HARUS mendukung verifikasi bahwa image sistem adalah biner yang identik dengan hasil yang diharapkan setelah OTA. Penerapan OTA berbasis blok di Project Open Source Android upstream, yang ditambahkan sejak Android 5.1, memenuhi persyaratan ini.

Selain itu, implementasi perangkat HARUS mendukung update sistem A/B. AOSP menerapkan fitur ini menggunakan HAL kontrol booting.

Jika error ditemukan dalam implementasi perangkat setelah dirilis, tetapi dalam masa aktif produk yang wajar yang ditentukan melalui konsultasi dengan Tim Kompatibilitas Android untuk memengaruhi kompatibilitas aplikasi pihak ketiga, maka:

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

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

12. Log Perubahan Dokumen

Untuk ringkasan perubahan pada Definisi Kompatibilitas dalam rilis ini:

Untuk ringkasan perubahan pada bagian individu:

  1. Pengantar
  2. Jenis Perangkat
  3. Software
  4. Kemasan Aplikasi
  5. Multimedia
  6. Alat dan Opsi Developer
  7. Kompatibilitas Hardware
  8. Performa dan Daya
  9. Model Keamanan
  10. Pengujian Kompatibilitas Software
  11. Software yang Dapat Diupdate
  12. Log Perubahan Dokumen
  13. Hubungi Kami

12.1. Tips Melihat Log Perubahan

Perubahan ditandai sebagai berikut:

  • CDD
    Perubahan substansial pada persyaratan kompatibilitas.

  • Dokumen
    Perubahan terkait kosmetik atau build.

Untuk tampilan terbaik, tambahkan parameter URL pretty=full dan no-merges ke URL log perubahan Anda.

13. Hubungi Kami

Anda dapat bergabung ke forum kompatibilitas Android dan meminta klarifikasi atau menyampaikan masalah yang menurut Anda tidak tercakup dalam dokumen.